mdyeasinsamadarnob/bfiu_app_web

1. This is a Next.js App Router application, not just a static site. The top-level shell is in app/layout.tsx, global styling is in app/globals.css, and theme support is wired through components/ThemeProvider.tsx and components/ThemeToggle.tsx.

2. The app has three main user-facing surfaces: the landing page at app/page.tsx, an architecture browser at app/architecture/page.tsx, and a timeline view at app/timeline/page.tsx. These pages are mostly composition layers that assemble reusable components around preloaded content.

3. The architecture content is file-backed and organized as structured datasets under data/architecture.json, data/architecture_eaip-langgraph.json, data/architecture_eaip-orch.json, and data/architecture_eaip-rag.json, with TypeScript helpers in data/architectureData.ts. This suggests multiple architecture variants or scenarios are first-class in the UI.

4. The architecture visualization itself is componentized in components/architecture/ArchitectureNode.tsx, ArchitectureGroupNode.tsx, and likely uses components/HighlightableText.tsx for emphasis/search highlighting. The architectural diagram is therefore a presentational tree/group rendering layer over static model data, rather than a live modeling backend.

5. The timeline subsystem is similarly data-driven: data/timeline.json and data/timelineData.ts feed components/TimelineView.tsx and the app/timeline route. This is a separate content domain from the architecture model, but the same app shell and styling system are reused.

6. There is a chat assistant subsystem exposed through components/ChatInterface.tsx and app/api/chat/route.ts. That route is a server boundary for message processing, so the UI can talk to backend logic without embedding model calls directly in the client.

7. The presence of app/api/ollama-status/route.ts and lib/config.ts indicates the chat layer depends on an Ollama runtime being reachable and configurable. In architecture terms, Ollama is an external local/sidecar AI service that the app probes and likely uses for generation.

8. Additional API routes expose structured content to the frontend: app/api/architecture/route.ts, app/api/timeline/route.ts, and app/api/rules/route.ts. This makes the content model available through server endpoints as well as direct imports, creating a clear separation between content storage and UI consumption.

9. The repo also includes extraction and parsing tooling: extract-docx.js, extract-pdf.js, parse-rules.js, and extracted-content.txt. These scripts imply an ingestion pipeline that converts source documents into normalized text/rules, which then feed the app’s rule or architecture datasets.

10. Supporting content is modeled as reusable domain widgets: components/UseCaseCard.tsx plus data/useCases.json/data/useCases.ts. This suggests the app presents curated use cases alongside architecture and timeline information, likely as part of the same storytelling or knowledge-exploration flow.

11. The overall boundary pattern is: static/domain data and extracted content in data/ and scripts, server API routes in app/api/, and interactive presentation in components/ and app/* pages. There is no evidence of a traditional database or auth layer; the architecture is centered on file-based content, serverless route handlers, and a local AI backend.

12. Tooling is standard Next.js/TypeScript/Tailwind: next.config.ts, tailwind.config.ts, postcss.config.mjs, eslint.config.mjs, and tsconfig.json. These affect implementation, but the architecture is dominated by content-driven UI, lightweight server routes, and an external Ollama model service.