theshafcodes/logivshaf

1. This repository is organized as a single main application: quotation-extractor, built with Next.js and TypeScript. The rest of the repo is mostly guidance/specification material rather than separate deployable services.

2. The runtime boundary is the Next.js app under quotation-extractor/app. app/page.tsx is the user-facing entry point, with app/layout.tsx and app/globals.css providing the shell and styling. This suggests a browser-driven upload/analysis workflow.

3. The backend surface is implemented as App Router API routes:

- app/api/extract/route.ts for the primary end-to-end quotation extraction flow

- app/api/extract-raw/route.ts for a lower-level/raw extraction path

These routes are the main orchestration layer and likely the only HTTP APIs exposed by the app.

4. The core integration with document processing lives in lib/adobe-extract.ts. This is the external-service boundary and appears to handle PDF/document extraction via Adobe’s extraction tooling or API.

5. lib/parse-quotation.ts is the domain transformation layer. It likely converts extracted document text/structure into a normalized quotation model, separating vendor-specific PDF extraction from business-specific parsing.

6. lib/pdf-config.ts holds extraction-related configuration for PDFs. That makes PDF handling a first-class concern, and it likely controls page/input settings used by the extraction pipeline.

7. The domain contract is centralized in types/quotation.ts, with a second quotation.ts file at the repo root suggesting shared quotation schema or domain definitions outside the app folder. This is the shape that API responses and parsing logic should agree on.

8. The main data flow is:

browser/UI upload or request → /api/extract or /api/extract-raw → Adobe-based document extraction → quotation parsing/normalization → typed JSON response back to the UI or caller.

The raw route likely exposes an intermediate stage for debugging or inspection.

9. There is no evidence of a database, queue, or background worker. The architecture looks stateless and request/response driven, with processing happening synchronously inside the API route handlers.

10. Tooling and framework files (next.config.ts, tsconfig.json, eslint.config.mjs, postcss.config.mjs, package.json) indicate a standard Next.js/TypeScript frontend-plus-API deployment model, probably suitable for serverless or Node hosting.

11. The top-level docs (QUICKSTART.md, TECHNICAL_PROMPT.md, FRAGILITY_CLASSIFICATION_PLAN.md, van-calculation.md) suggest the repo also contains implementation guidance and adjacent domain notes. They are useful for understanding intended behavior, but they are not part of the runtime call graph.