FX_Checker app with AI Assistant

What are you most proud of, and what would you do differently next time?

I am particularly proud of the feature-driven architecture engineered for this project. Built around strict module isolation, the codebase cleanly separates responsibilities across five distinct layers:

• app: Route composition and page-level orchestration.
• infra: Core business logic, data models, and persistence setup.
• features: Domain-isolated application modules with zero cross-dependencies.
• shared: Reusable UI primitives, design tokens, and common utility functions.
• tests: Centralized Playwright E2E test specs and global test helpers.

Co-locating Stories definitions inside each feature's internal __testing__ directory and ai tools in utils/tools was immensely satisfying. It makes domain features completely self-contained, highly portable, and seamless to orchestrate in end-to-end test suites or ai orchestration.

What challenges did you encounter, and how did you overcome them?

1. Keyboard Accessibility in Continuous Marquee Animations

• The Challenge: Infinite horizontal tickers create severe WCAG accessibility barriers. CSS animations keep off-screen and duplicated elements inside the document tab order, resulting in keyboard focus traps and confusing screen reader output for hidden items.
• The Solution: I developed a custom useMarqueeVisibility hook powered by IntersectionObserver. By tracking when ticker links cross the visible viewport boundary, the hook dynamically updates tabIndex (0 when visible, -1 when hidden) and aria-hidden (false / true). This guarantees that keyboard navigation (Tab / Shift+Tab) and screen readers strictly interact with elements currently on screen.

2. Managing Cross-Feature Interdependencies Without Tight Coupling

• The Challenge: Domain modules like converter and compare frequently required capabilities from favorites and logs. Attempting to handle this via pure page-level orchestration in app/ caused severe prop drilling and bloated the shared/ directory with cross-domain type definitions just for reuse.
• The Solution: I refactored the interaction model to use Slot Injection (Inversion of Control). By passing generic component slot wrappers (such as FavoriteToggleWrapper), the underlying business logic remains strictly encapsulated within its home feature module (features/favorites), while consumer components remain completely decoupled from neighboring domain internals.

What specific areas of your project would you like help with?

The codebase has been designed with strict architectural boundaries. For a thorough code review, I would appreciate feedback particularly on the following areas:

• FINBOT AI assistant: Review the Finebot ai feature... I have given it quite some tools to cover almost all interactions in the app when the user is logged in. Try it and see if it is usable.
• Marquee Accessibility Implementation: Review the useMarqueeVisibility hook and IntersectionObserver logic used to manage tabIndex and aria-hidden attributes on the live market ticker.
• E2E Test & Story Co-location Pattern: Examine how feature story are defined inside individual __testing__ directories and orchestrated from centralized Playwright test specs.
• shared/ Folder Purity: Audit utility functions, custom hooks, and shared UI primitives to ensure they remain domain-neutral and clean.
• Infrastructure Layer (infra/): Evaluate the separation, structure, and error-handling footprint of the persistence and external service integrations.
• General Code Audit: Feel free to flag any architectural edge cases, performance bottlenecks, or cleaner design patterns across the rest of the application.