Scope negotiation

Conversation

• pm
  ## System Architecture & Technical Specifications ``` +-------------------------------------------------------+ | Next.js Fullstack | | (App Router + Tailwind + shadcn/ui + TypeScript) | +---------------------------+---------------------------+ | +------------------------------------+-----------------------------------+ | | | v v v +-------------------+ +--------------------+ +-------------------+ | Ingestion Engine | | Consensus Engine | | Cloud & Storage | | - File Parsing | | - LLM Provider API | | - Google Drive API| | (PDF/CSV/TXT/ | | (Gemini, OpenAI, | | (Service Account| | Images) | | Grok Adapter) | | Auth) | | - PDF Renamer | | - Multi-Round Loop | | - SQLite Database | +-------------------+ +--------------------+ +-------------------+ ``` --- ## 1. Complete Feature Matrix ### Ingestion & Processing Pipeline * **Multi-Format Ingestion:** Drag-and-drop / file picker on the landing page accepting `.pdf`, `.png`, `.jpg`, `.jpeg`, `.csv`, `.txt`, and `.md`. * **Universal Normalization:** Text/CSV/Image inputs are parsed into text representations and normalized into a standard PDF artifact for archiving. * **Smart Renaming Engine:** Generates target PDF file names following the strict pattern: `ddmmyyyy-sender-sequence.pdf` (e.g., `22082026-AcmeCorp-001.pdf`), extracting the sender and date via the AI consensus or falling back to user input. ### Multi-LLM Consensus Engine (Extensible) * **Provider Abstraction Interface:** Standardized `BaseLLMProvider` contract (`generateResponse`, `streamResponse`, `modelName`) allowing zero-friction addition of new models (OpenAI, Gemini, Grok, Claude). * **Sequential Peer Review Loop (Option A):** * **Round 1:** Model A (e.g., Gemini 1.5 Pro) reads the raw document and produces an initial structured assessment and tag recommendations. * **Round 2:** Model B (e.g., OpenAI GPT-4o) critiques Model A's extraction, flags discrepancies, and refines key data points. * **Rounds 3–10 (Configurable):** Iterative refinement between models until both models signal consensus or the 10-round cap is reached. * **Synthesis Step:** A unified assessment report (Markdown format) is generated and delivered to the chat window. * **Tag Suggestion Mechanism:** Models return candidate tags based on document analysis; suggestions are displayed as clickable chips in the UI without modifying the database. ### Tag & Metadata Management * **Dynamic User-Driven Tags:** Clean-slate tag system with zero hardcoded tags. * **Manual Tag Creation:** Dedicated "Create Tag" modal/button in the chat interface allowing custom tag creation on the fly. * **Tag Assignment:** Documents can hold multiple user-confirmed tags, stored relationally in SQLite. ### Chat & Interactive Workspace * **ChatGPT/Gemini-Style UI:** Responsive interface featuring a collapsible left sidebar (recent uploads and conversations) and a central chat stream. * **Post-Assessment Interactivity:** User can ask follow-up questions, request specific recalculations, or instruct the models to re-evaluate sections. * **Assessment Preview:** Split-screen or toggle view to see the source document alongside the generated Markdown assessment. * **Session Reset / Logout:** Clears current active session state and resets the workspace to the landing state. ### Google Drive & Database Persistence * **Headless Service Account Integration:** Authenticates automatically using a root-level `service_account.json` credential file to access a designated Drive folder. * **Database Archival:** Persists document metadata, UUIDs, full chat transcripts, tag relationships, and Markdown/PDF assessment reports in a local SQLite database. --- ## 2. Dependency & Stack Assessment This stack is selected for optimal compatibility with **Cursor** (TypeScript end-to-end type safety, unified Next.js App Router, zero-boilerplate ORM). ### Recommended Tech Stack * **Framework:** Next.js 14/15 (App Router, Server Actions, Route Handlers) * **Styling & Components:** Tailwind CSS + `shadcn/ui` + `lucide-react` * **Database & ORM:** SQLite via `@libsql/client` or `better-sqlite3` + `drizzle-orm` (lightweight, zero external server requirement) * **File & PDF Processing:** `pdf-parse`, `pdf-lib`, `papaparse`, `tesseract.js` (or LLM Vision API for OCR) ### Core Dependencies & Environment Configuration | Package | Purpose | Version Spec | | --- | --- | --- | | `googleapis` | Google Drive API v3 Service Account Client | `^140.0.0` | | `@google/genai` | Google Gemini SDK | Latest | | `openai` | OpenAI & Grok (xAI API is OpenAI-compatible) | `^4.50.0` | | `drizzle-orm` / `drizzle-kit` | SQLite Database Schema & Query Builder | Latest | | `better-sqlite3` | Local database engine | `^9.0.0` | | `pdf-lib` | Client/Server PDF creation & metadata manipulation | `^1.17.1` | | `papaparse` | CSV data parsing | `^5.4.1` | | `zod` | Runtime validation for LLM structured outputs | `^3.23.0` | #### Environment Variables (`.env.local`) ```env # AI Providers GEMINI_API_KEY="AIzaSy..." OPENAI_API_KEY="sk-proj-..." GROK_API_KEY="xai-..." DEFAULT_MAX_DEBATE_ROUNDS=10 # Google Drive Configuration GOOGLE_APPLICATION_CREDENTIALS="./service_account.json" GOOGLE_DRIVE_FOLDER_ID="1A2B3C4D5E6F7G8H9I0J" # Database DATABASE_URL="file:./data/app.db" ``` --- ## 3. Database Schema Design (SQLite / Drizzle) ```sql -- Documents Table CREATE TABLE documents ( id TEXT PRIMARY KEY, -- UUIDv4 original_filename TEXT NOT NULL, gdrive_filename TEXT, gdrive_file_id TEXT, mime_type TEXT NOT NULL, local_file_path TEXT NOT NULL, sender TEXT, sequence_number INTEGER, status TEXT CHECK(status IN ('uploaded', 'analyzing', 'ready', 'exported', 'failed')) DEFAULT 'uploaded', created_at DATETIME DEFAULT CURRENT_TIMESTAMP, updated_at DATETIME DEFAULT CURRENT_TIMESTAMP ); -- Tags Table (User-created only) CREATE TABLE tags ( id TEXT PRIMARY KEY, -- UUIDv4 name TEXT UNIQUE NOT NULL, color TEXT DEFAULT '#3B82F6', created_at DATETIME DEFAULT CURRENT_TIMESTAMP ); -- Document <-> Tags Junction Table CREATE TABLE document_tags ( document_id TEXT NOT NULL REFERENCES documents(id) ON DELETE CASCADE, tag_id TEXT NOT NULL REFERENCES tags(id) ON DELETE CASCADE, PRIMARY KEY (document_id, tag_id) ); -- Assessments Table CREATE TABLE assessments ( id TEXT PRIMARY KEY, -- UUIDv4 document_id TEXT NOT NULL REFERENCES documents(id) ON DELETE CASCADE, final_markdown TEXT NOT NULL, debate_rounds_count INTEGER NOT NULL, raw_debate_transcript TEXT, -- JSON Array of internal model exchanges created_at DATETIME DEFAULT CURRENT_TIMESTAMP ); -- Chat Transcript Messages CREATE TABLE chat_messages ( id TEXT PRIMARY KEY, -- UUIDv4 document_id TEXT NOT NULL REFERENCES documents(id) ON DELETE CASCADE, sender_role TEXT CHECK(sender_role IN ('user', 'assistant', 'system', 'gemini', 'openai', 'grok')) NOT NULL, content TEXT NOT NULL, created_at DATETIME DEFAULT CURRENT_TIMESTAMP ); ``` --- ## 4. Extensible LLM Provider Interface ```typescript // lib/llm/types.ts export interface LLMMessage { role: 'system' | 'user' | 'assistant'; content: string; } export interface LLMResponse { content: string; suggestedTags?: string[]; metadata?: { sender?: string; date?: string; }; } export interface BaseLLMProvider { name: string; analyzeDocument(content: string | Buffer, mimeType: string, prompt: string): Promise<LLMResponse>; critiqueAssessment(documentContent: string, previousAssessment: string, roundNumber: number): Promise<LLMResponse>; chat(messages: LLMMessage[]): Promise<string>; } ``` --- ## 5. Comprehensive User Stories Catalog ### Epic 1: Document Upload & Ingestion * **US-1.1: Multi-Format Ingestion** * **As a** user, * **I want to** drag and drop or upload PDF, Image, CSV, TXT, or Markdown files on the landing page, * **So that** I can process any document regardless of its source format. * **Acceptance Criteria:** * Landing page shows a clean upload dropzone. * Supported file formats (`.pdf`, `.png`, `.jpg`, `.jpeg`, `.csv`, `.txt`, `.md`) are accepted; all others show an error toast. * File is assigned a unique UUID and stored in local temporary storage. * **US-1.2: Transition to Active Workspace** * **As a** user, * **I want to** be automatically transitioned to the chat workspace once a file is uploaded, * **So that** I can monitor the analysis and begin interacting immediately. * **Acceptance Criteria:** * Landing page smoothly transitions to the ChatGPT/Gemini-style dual-panel workspace upon upload completion. * Document status indicators update from "Processing" to "Analyzing" to "Ready". --- ### Epic 2: Multi-LLM Collaborative Review Engine * **US-2.1: Sequential Peer Review (Gemini & OpenAI)** * **As a** user, * **I want** Gemini and OpenAI to collaboratively review the document up to a maximum of 10 rounds, * **So that** I receive a highly accurate, audited assessment report. * **Acceptance Criteria:** * Model A generates initial extraction and summary. * Model B reviews Model A's output against the raw file content, pointing out corrections or omissions. * The process repeats sequentially until models reach agreement or hit 10 rounds maximum. * Final consolidated Markdown report is rendered in the main chat viewport. * **US-2.2: Third-Party Model Extensibility (Grok / Claude)** * **As a** developer/user, * **I want** the LLM engine to follow an abstracted interface, * **So that** I can plug in Grok (xAI) or other providers without rewriting the core workflow. * **Acceptance Criteria:** * Adding a new provider requires only implementing the `BaseLLMProvider` interface and registering it in a factory map. --- ### Epic 3: Tagging & Metadata Control * **US-3.1: Zero-Seed Dynamic Tag Creation** * **As a** user, * **I want to** create custom tags manually whenever needed with no predefined seed tags, * **So that** my taxonomy matches my personal organization requirements. * **Acceptance Criteria:** * Initial database contains 0 tags. * "Create Tag" button opens a quick modal with tag name and color selection. * Newly created tag is immediately available for document association. * **US-3.2: AI Tag Suggestions (Read-Only)** * **As a** user, * **I want to** see tag recommendations from the AI without them being auto-created, * **So that** I maintain complete control over my tag taxonomy. * **Acceptance Criteria:** * LLM consensus response includes suggested tags rendered as clickable chips. * Clicking a suggestion checks if the tag exists; if not, it prompts the user to confirm creation before applying. --- ### Epic 4: Interactive Chat & Post-Assessment * **US-4.1: Assessment Discussion** * **As a** user, * **I want to** ask follow-up questions about the assessment in the chat interface, * **So that** I can clarify specific clauses, values, or calculations. * **Acceptance Criteria:** * Chat input accepts questions and responds with context from both the document and consensus report. * Full message history is appended to `chat_messages` in the database. * **US-4.2: Recent Conversations & File Sidebar** * **As a** user, * **I want** a sidebar listing recent uploads and past conversations, * **So that** I can switch back to previous documents and review their state. * **Acceptance Criteria:** * Left sidebar displays chronological list of uploaded documents with assigned tags. * Clicking a historical item loads its chat transcript, assessment, and metadata. --- ### Epic 5: Google Drive Archival & Database Storage * **US-5.1: File Renaming & Standardized PDF Export** * **As a** user, * **I want** the uploaded file converted to PDF and renamed as `ddmmyyyy-sender-sequence.pdf`, * **So that** all stored documents have consistent, predictable file names. * **Acceptance Criteria:** * Non-PDF documents are converted to PDF format. * Sender name is extracted from AI metadata (or requested from user if missing). * Date format is strictly `ddmmyyyy`. Sequence number increments based on existing records in the database. * **US-5.2: Service Account Google Drive Upload** * **As a** system/user, * **I want** the renamed PDF uploaded to Google Drive via a local `service_account.json` file, * **So that** I do not have to perform interactive OAuth logins. * **Acceptance Criteria:** * Server loads `service_account.json` from the root directory. * File uploads to the specified Google Drive target folder. * Returned Google Drive File ID and web view link are recorded in the database. * **US-5.3: Database Transcript & Assessment Persistence** * **As a** user, * **I want** the original filename, generated report, and full chat transcript persisted in the database, * **So that** I have a permanent local audit trail. * **Acceptance Criteria:** * `assessments` and `chat_messages` tables are updated at the end of each session. * Database stores the original file name alongside the renamed Drive file name.
• po
  Thanks for the detailed breakdown! This gives us a solid foundation. To clarify the MVP scope, could you please confirm which of the following user stories are essential for the initial launch? 1. **US-1.1: Multi-Format Ingestion** (Drag and drop/upload PDF, Image, CSV, TXT, or Markdown files) 2. **US-1.2: Transition to Active Workspace** (Auto-transition to chat workspace upon upload) 3. **US-2.1: Sequential Peer Review (Gemini & OpenAI)** (Collaborative review up to 10 rounds) 4. **US-3.1: Zero-Seed Dynamic Tag Creation** (Manually create custom tags) 5. **US-5.1: File Renaming & Standardized PDF Export** (Convert to PDF, rename `ddmmyyyy-sender-sequence.pdf`) 6. **US-5.2: Service Account Google Drive Upload** (Upload renamed PDF to Drive via `service_account.json`) 7. **US-5.3: Database Transcript & Assessment Persistence** (Persist original filename, report, chat transcript) Once we confirm these, regarding **US-2.2: Third-Party Model Extensibility (Grok / Claude)**, for the MVP, is it sufficient to have the `BaseLLMProvider` interface defined and implemented *only* for Gemini and OpenAI, with the explicit goal of adding Grok/Claude in a later release? Or is the ability to easily plug in *any* new provider (e.g., Grok/Claude) an MVP requirement?
• pm
  All of them in the scope for MVP, also a new folder in Google drive should be created or if it is available should be used, the user must mention which folder. regarding **US-2.2: the ability to easily plug in *any* new provider
• po
  Thanks for confirming all the listed user stories are MVP. That's very helpful! You also clarified that for **US-2.2: Third-Party Model Extensibility**, "the ability to easily plug in *any* new provider" is an MVP requirement. To make this concrete for delivery: 1. For MVP, is it sufficient to have the `BaseLLMProvider` interface fully implemented and functional for **Gemini and OpenAI only**, demonstrating the extensibility architecture, with the integration of Grok/Claude (or other providers) explicitly planned for a later release? Or do we need to have Grok/Claude *also integrated and working* in the MVP? Additionally, regarding the Google Drive folder, your latest comment states "a new folder in Google drive should be created or if it is available should be used, the user must mention which folder." This introduces a new interaction compared to the initial spec's `GOOGLE_DRIVE_FOLDER_ID` environment variable. 2. For MVP, could you clarify the Google Drive folder behavior: a. Will the user specify an *existing* Google Drive folder (e.g., by ID or name) in the UI for each upload/session? b. Will the system allow the user to *create a new folder* in Google Drive via the UI, and then use that for uploads? c. Or will we still rely on a *single, pre-configured folder* defined by the `GOOGLE_DRIVE_FOLDER_ID` environment variable, with the user *not* interacting with folder selection in the UI for MVP?
• pm
  For MVP, could you clarify the Google Drive folder behavior: c. Or will we still rely on a *single, pre-configured folder* defined by the `GOOGLE_DRIVE_FOLDER_ID` environment variable, with the user *not* interacting with folder selection in the UI for MVP
• po
  Thanks for clarifying the Google Drive folder behavior for MVP – we'll stick to a single, pre-configured folder via `GOOGLE_DRIVE_FOLDER_ID` with no user interaction for folder selection. To summarize the confirmed MVP scope so far: * **US-1.1: Multi-Format Ingestion** (Drag and drop/upload PDF, Image, CSV, TXT, or Markdown files) - MVP * **US-1.2: Transition to Active Workspace** (Auto-transition to chat workspace upon upload) - MVP * **US-2.1: Sequential Peer Review (Gemini & OpenAI)** (Collaborative review up to 10 rounds) - MVP * **US-2.2: Third-Party Model Extensibility** (Ability to plug in any new provider) - MVP * **US-3.1: Zero-Seed Dynamic Tag Creation** (Manually create custom tags) - MVP * **US-5.1: File Renaming & Standardized PDF Export** (Convert to PDF, rename `ddmmyyyy-sender-sequence.pdf`) - MVP * **US-5.2: Service Account Google Drive Upload** (Upload renamed PDF to Drive via `service_account.json`) - MVP * **US-5.3: Database Transcript & Assessment Persistence** (Persist original filename, report, chat transcript) - MVP Now, regarding **US-2.2: Third-Party Model Extensibility**, you confirmed "the ability to easily plug in *any* new provider" is an MVP requirement. To ensure we're aligned on what "ability" means for MVP delivery: For MVP, is it sufficient to have the `BaseLLMProvider` interface fully implemented and functional for **Gemini and OpenAI only**, demonstrating the extensibility architecture, with the integration of Grok/Claude (or other providers) explicitly planned for a later release? Or do we need to have Grok/Claude *also integrated and working* in the MVP?
• pm
  No, we do not need to add LLM in MVP, but the architecture should be designed in a way that it does not lock the application for only these 2 models.
• po
  Thanks for clarifying that the *architecture* for LLM extensibility (US-2.2) is an MVP requirement, and for the MVP, we will implement and integrate Gemini and OpenAI (as per US-2.1), but we don't need to integrate additional LLMs like Grok/Claude yet. This helps us focus. To summarize the confirmed MVP scope so far: * **US-1.1: Multi-Format Ingestion** (Drag and drop/upload PDF, Image, CSV, TXT, or Markdown files) - MVP * **US-1.2: Transition to Active Workspace** (Auto-transition to chat workspace upon upload) - MVP * **US-2.1: Sequential Peer Review (Gemini & OpenAI)** (Collaborative review up to 10 rounds, both models functional) - MVP * **US-2.2: Third-Party Model Extensibility** (Architecture for plugging in new providers) - MVP * **US-3.1: Zero-Seed Dynamic Tag Creation** (Manually create custom tags) - MVP * **US-5.1: File Renaming & Standardized PDF Export** (Convert to PDF, rename `ddmmyyyy-sender-sequence.pdf`) - MVP * **US-5.2: Service Account Google Drive Upload** (Upload renamed PDF to Drive via `service_account.json` to a single, pre-configured folder) - MVP * **US-5.3: Database Transcript & Assessment Persistence** (Persist original filename, report, chat transcript) - MVP To ensure we have a complete picture, could you please confirm the MVP status for these remaining user stories from your initial catalog? 1. **US-3.2: AI Tag Suggestions (Read-Only)**: Displaying AI-suggested tags as clickable chips without auto-creating them. 2. **US-4.1: Assessment Discussion**: Allowing users to ask follow-up questions about the assessment in the chat interface. 3. **US-4.2: Recent Conversations & File Sidebar**: A left sidebar listing recent uploads and past conversations.
• pm
  US-3.2, 4.1 and 4.2 confirmed
• po
  Thanks for confirming all remaining user stories are also MVP. This means we have a clear and comprehensive MVP scope! Based on our discussion, the scope is now clear enough to story-split. I'm ready to propose a brief summary of the MVP stories for your confirmation. This will help us align on the initial development tasks. Here's a proposed story breakdown: * **Front-end: Core UI & Interaction** * Landing page: multi-format file upload UI (drag-and-drop/picker, error handling) * Chat workspace UI: auto-transition, status indicators, chat input/display * Left sidebar: recent uploads/conversations (display, load historical data) * Tag management UI: 'Create Tag' modal/button, display AI-suggested tags * Render final Markdown assessment report in chat viewport * **Back-end: File Ingestion & Processing** * File upload endpoint & temporary storage * Multi-format parsing engine (PDF, Image OCR, CSV, TXT, MD to text) * Non-PDF to PDF conversion for archiving * Smart renaming engine: `ddmmyyyy-sender-sequence.pdf` (AI sender/date extraction) * **AI Engineer: LLM Core & Orchestration** * Define/implement `BaseLLMProvider` interface (extensibility) * Integrate/implement `GeminiLLMProvider` * Integrate/implement `OpenAILLMProvider` * Sequential peer review orchestration logic (up to 10 rounds) * LLM: return suggested tags * Chat interaction logic (follow-up questions, context) * **Data Engineer: Database & Persistence** * Design/implement SQLite DB schema (Drizzle ORM) * Persistence: document metadata, filenames, assessment reports, chat transcripts * API endpoints: tag management, recent documents/conversations * **Cloud Engineer: Google Drive Integration** * Google Drive API setup (`service_account.json`) * Upload renamed PDFs to pre-configured GDrive folder * Persist GDrive File ID/link in DB Please confirm if this summary accurately reflects our agreed-upon MVP scope.
• pm
  Confirm the scope
• po
  Thanks for confirming the scope summary! That's great. Here is the initial story list based on our discussion, categorized as MVP and with proposed roles. Please review and let me know if this looks good for us to start with. To ensure we have a complete understanding for these stories, could you please clarify the acceptance criteria for the following: 1. **Landing page: Multi-format file upload UI**: What specific error messages should be displayed for unsupported file formats? 2. **Sequential peer review orchestration logic (up to 10 rounds)**: What should happen if the models do not reach consensus within the 10 rounds? Should the last assessment be returned, or is there a fallback mechanism? 3. **Smart renaming engine**: How should the system handle cases where the sender name cannot be extracted from the AI metadata or user input for the `ddmmyyyy-sender-sequence.pdf` format?
• pm
  1. **Landing page: Multi-format file upload UI**: What specific error messages should be displayed for unsupported file formats? Unsupported file, make sure you upload image, pdf, CSV, txt or markdown files. 2. **Sequential peer review orchestration logic (up to 10 rounds)**: What should happen if the models do not reach consensus within the 10 rounds? Should the last assessment be returned, or is there a fallback mechanism? Show open points to the user, ask for their feedback, and get permission to continue 10 more rounds. 3. **Smart renaming engine**: How should the system handle cases where the sender name cannot be extracted from the AI metadata or user input for the `ddmmyyyy-sender-sequence.pdf` format? Ask the user by mentioning the sender cannot be determined; write the sender name in chat.
• po
  Thanks for those clear clarifications! 1. **Landing page: Multi-format file upload UI**: We'll display "Unsupported file, make sure you upload image, pdf, CSV, txt or markdown files." for invalid formats. 2. **Sequential peer review orchestration logic**: If no consensus after 10 rounds, we'll show open points to the user, ask for feedback, and get permission to continue for 10 more rounds. 3. **Smart renaming engine**: If the sender cannot be determined, we'll prompt the user in the chat to provide the sender name. With these details, the MVP scope is now fully clear. I'm ready to propose the detailed story list with roles and MVP status.
• pm
  Ok, Happy that all points are clear, propose the detailed story list with roles and MVP status
• po
  Excellent! I'm happy we've reached full clarity on the MVP scope. Here is the detailed story list with proposed roles and MVP status, incorporating all the confirmed features and clarifications, including the acceptance criteria. Please take a look and confirm if this aligns with your expectations for the initial development phase. ### Proposed Story List **1. Front-end: Core UI & Interaction** * **Landing page: Multi-format file upload UI** (MVP) * *Acceptance Criteria:* Display "Unsupported file, make sure you upload image, pdf, CSV, txt or markdown files." for invalid formats. * **Chat workspace: Auto-transition on upload & status indicators** (MVP) * **Chat workspace: Display LLM assessment report (Markdown)** (MVP) * **Chat workspace: Chat input and message display** (MVP) * **Left sidebar: Display recent uploads/conversations & load historical data** (MVP) * **Tag management UI: 'Create Tag' modal/button** (MVP) * **Tag management UI: Display AI-suggested tags as clickable chips** (MVP) * **Tag management UI: Apply/associate tags to document** (MVP) * **Chat interaction: Prompt user for sender name** (if AI cannot determine) (MVP) * **Chat interaction: Prompt user to continue LLM rounds** (if no consensus after 10) (MVP) **2. Back-end: File Ingestion & Processing** * **API: File upload endpoint & temporary storage** (MVP) * **File processing: Multi-format parsing** (PDF, Image OCR, CSV, TXT, MD to text) (MVP) * **File processing: Non-PDF to PDF conversion for archiving** (MVP) * **File processing: Smart renaming engine** (`ddmmyyyy-sender-sequence.pdf`) (MVP) * *Acceptance Criteria:* If sender cannot be determined, trigger chat prompt to user. * **API: Tag creation and management** (MVP) * **API: Document metadata and chat history retrieval** (MVP) * **API: Chat interaction endpoint** (for follow-up questions) (MVP) **3. AI Engineer: LLM Core & Orchestration** * **LLM Core: Define `BaseLLMProvider` interface** (extensibility) (MVP) * **LLM Core: Implement `GeminiLLMProvider`** (MVP) * **LLM Core: Implement `OpenAILLMProvider`** (MVP) * **LLM Orchestration: Sequential peer review logic** (up to 10 rounds) (MVP) * *Acceptance Criteria:* If no consensus after 10 rounds, show open points and trigger user prompt for more rounds. * **LLM: Extract sender and date for renaming** (MVP) * **LLM: Generate suggested tags** (MVP) * **LLM: Generate initial structured assessment** (MVP) * **LLM: Critique previous assessment** (MVP) * **LLM: Handle follow-up questions in chat** (contextual) (MVP) **4. Data Engineer: Database & Persistence** * **DB Schema: Design & implement SQLite schema** (Drizzle ORM) (MVP) * **DB Persistence: Store document metadata** (original/gdrive filename, IDs, status) (MVP) * **DB Persistence: Store tags and document-tag relationships** (MVP) * **DB Persistence: Store assessment reports** (final markdown, debate transcript) (MVP) * **DB Persistence: Store chat messages** (MVP) * **DB Persistence: Manage sequence numbers for renaming** (MVP) **5. Cloud Engineer: Google Drive Integration** * **Google Drive: Service account authentication setup** (MVP) * **Google Drive: Upload renamed PDFs to pre-configured folder** (MVP) * **Google Drive: Store GDrive file ID and link in DB** (MVP) **6. QA Engineer: Testing** * **QA: End-to-end testing of document ingestion, processing, and chat flow** (MVP) * **QA: Testing of tag management and persistence** (MVP) * **QA: Testing of Google Drive archival** (MVP)
• system
  MVP scope locked. Chat is read-only. Linear stories and docs/MVP-scope.md were written from the agreed draft.