From bd7ab04aaf6c543a256d451a05d0d7aefee46dff Mon Sep 17 00:00:00 2001 From: Karan Bosamiya Date: Thu, 2 Jul 2026 20:30:22 +0530 Subject: [PATCH] [FIX] More detailed description about phases --- HACKATHON_TEAM_PLAN.md | 253 +++++++++++++++++++---------------------- 1 file changed, 117 insertions(+), 136 deletions(-) diff --git a/HACKATHON_TEAM_PLAN.md b/HACKATHON_TEAM_PLAN.md index cd85c17..31ccb08 100644 --- a/HACKATHON_TEAM_PLAN.md +++ b/HACKATHON_TEAM_PLAN.md @@ -27,201 +27,182 @@ --- -## 9. Phased Module Plan — Named Assignments +## 1. Squad Structure (Quick Reference) -This is the concrete, name-level version of §2–§5: six named modules, three phases, everyone's responsibility spelled out so nothing falls through at integration time. Read each module's row across all three phases to see one person's/pair's full arc through the hackathon. +| Squad | Module | Members | +|---|---|---| +| **A** | Core Engine (AI Service, RAG, Auth) | Karan Bosamiya (lead), Prit Chavda, Tarun Nagpal | +| **B** | Knowledge Hub | Ishit Desai (lead), Aman Rajput, Arjun Mulagapaka | +| **C** | Planning Engine | Meet Shah (lead), Devansh Jagatiya, Parth Harpal | +| **D** | Meetings & Risk Intelligence | Parth Shah (lead), Smit Thakkar | +| **E** | Frontend Experience | Khushal Batham (lead), Bhargav Valani | +| **F** | DevOps & Quality | Shubham Nayak (lead), Chaitanya Vekaria, Chandresh Thakkar | -### The Six Modules +A squad "lead" means: final call on that squad's technical decisions, the person other squads' blockers get routed to, and the one who reviews every trainee PR on their squad before merge (§7 — trainee review gate). -| Module | Maps to Squad | Owns | -|---|---|---| -| **M1 — Core Engine** (AI Service + RAG + Auth) | A | §4, §7, §8, §13 | -| **M2 — Knowledge Hub** (ingestion, chunking, connectors) | B | §6 | -| **M3 — Planning Engine** (requirements → stories → sprints) | C | §8.6.1–8.6.3, §9.4–9.5 | -| **M4 — Meetings & Risk Intelligence** | D | §8.6.4–8.6.5, §9.6–9.7 | -| **M5 — Frontend Experience** | E | §12.3, all UI | -| **M6 — DevOps & Quality** | F | §10, §14, §17 | +--- + +## 2. How to Read This Document as a Leader + +Section 3 below is organized **Phase → Squad → Person**. For every phase, every person on the roster has a named block listing: what they're doing, what file(s) they touch, what "done" looks like, and who they're blocked by or blocking. You can lift any person's block directly into a ticket/task tracker without rewriting it. Read a single person's blocks across all three phases to see their whole hackathon arc; read a single phase across all squads to see what should be true of the whole system at that checkpoint. --- -### Phase 1 — Foundation & Interface Freeze (Hours 0–3) +## 3. Phase 1 — Foundation & Interface Freeze (Hours 0–3) -Goal: every module has a working skeleton and a frozen contract to build against. Nobody starts real feature work until M1's stub interfaces are published — this is the one moment the whole team is synchronized. +**Phase goal**: every module has a running skeleton, and Squad A has published a frozen `AIService`/`rag_service` contract that every other squad can build against without waiting for the real implementation. Nobody in Squads B–F should be blocked past hour 1.5 waiting on Squad A — that is the one deadline in this phase that cannot slip. -- **M1 — Core Engine**: scaffold `app/core/*`, DB connection, GitHub/Microsoft OAuth + JWT skeleton, **publish stub `AIService.call_claude()` and `rag_service.retrieve()` signatures by hour 1.5** *(Karan Bosamiya — Sr SE Python, lead; Prit Chavda — SE Machine Learning; Tarun Nagpal — Trainee AI/ML)* -- **M2 — Knowledge Hub**: scaffold `SourceConnector` protocol, stub `GitHubConnector`, read M1's stub contracts *(Ishit Desai — SE Python, lead; Aman Rajput — Trainee Data Engineering; Arjun Mulagapaka — Trainee Python)* -- **M3 — Planning Engine**: scaffold Pydantic schemas for work packages/stories/sprints, requirements upload endpoint shell *(Meet Shah — SE Python, lead; Devansh Jagatiya — Trainee Python; Parth Harpal — Trainee Python)* -- **M4 — Meetings & Risk**: scaffold meeting/risk schemas, transcript submission endpoint shell *(Parth Shah — SE Python, lead; Smit Thakkar — Trainee Python)* -- **M5 — Frontend Experience**: app shell, routing, login screen, shared component library kickoff (data table, form panel, status badge) *(Khushal Batham — Sr SE React, lead; Bhargav Valani — SE React)* -- **M6 — DevOps & Quality**: `docker-compose.yml`, CI skeleton (lint + test on PR), `.env.example`, draft test plan against §9's endpoint tables *(Chaitanya Vekaria — Trainee DevOps; Shubham Nayak — QA Engineer, lead; Chandresh Thakkar — Trainee QA)* +### Squad A — Core Engine -**Phase 1 exit checkpoint**: a user can log in, M1's stub `AIService`/`rag_service` are merged to `main`, and every other module compiles against them. +- **Karan Bosamiya (Sr SE Python, lead)** — Owns `app/core/config.py`, `database.py`, `deps.py`. Stands up the FastAPI skeleton, Postgres connection, and GitHub OAuth login flow (§13.2) end to end. **By hour 1.5**, publishes the stub `AIService.call_claude()` and `rag_service.retrieve()` signatures (§8.1, §7.1) into `main` — this is the single most time-critical deliverable in the whole hackathon; every other squad's Phase 1 work depends on this file existing. **Done when**: a user can hit `/auth/github/login`, get redirected, and land back authenticated; `ai_service.py` and `rag_service.py` exist with correct signatures and stub bodies. **Blocks**: every other squad's real feature work in Phase 2. +- **Prit Chavda (SE Machine Learning)** — Works alongside Karan on the stub design, specifically making sure the stub `retrieve()` return shape (`RetrievedChunk`) and `call_claude()`'s `response_schema` parameter match what real retrieval/generation will eventually need — designing the contract right the first time avoids a breaking change in Phase 2. Also starts wiring the Voyage AI / OpenAI embeddings API clients (no real calls yet, just auth/connectivity check). **Done when**: stub contract is reviewed and agreed with Karan; embedding API keys are verified working via a one-off test call. +- **Tarun Nagpal (Trainee AI/ML)** — Paired with Prit. Sets up `app/ai/prompts.py` file structure and drafts the first prompt template skeleton (`WORK_PACKAGE_EXTRACTION_PROMPT_V1`) so Squad C has something concrete to look at when they start story/requirements work in Phase 2. **Done when**: `prompts.py` exists with at least one drafted (not yet tuned) prompt template, reviewed by Prit. ---- +### Squad B — Knowledge Hub -### Phase 2 — Core Feature Build (Hours 3–14) +- **Ishit Desai (SE Python, lead)** — Scaffolds `app/services/knowledge_hub/` folder structure (§12.2): `connectors/base.py` with the `SourceConnector` protocol (§6.2) defined, empty chunker files stubbed out. Reviews Squad A's stub `retrieve()` signature as soon as it lands to confirm it supports the `chunk_types`/`repository_id` filters Knowledge Hub needs. **Done when**: `SourceConnector` protocol is defined and committed; folder skeleton exists for connectors and chunkers. +- **Aman Rajput (Trainee Data Engineering)** — Paired with Ishit. Starts on `GitHubConnector` — `list_files()` and `fetch_content()` using `PyGithub` against a real test repo, no chunking yet. **Done when**: can authenticate to a GitHub repo and list its files programmatically, verified with a quick script. +- **Arjun Mulagapaka (Trainee Python)** — Reads Squad A's published stub contract and Section 5's `knowledge_chunks` schema (§5.3.6). Drafts the SQLAlchemy model for `knowledge_chunks`, `repositories`, `ingestion_jobs` (not yet migrated — just the model classes). **Done when**: model files exist matching §5.3.6's column list, ready for Karan to fold into the migration sequence. -Goal: each module builds its real feature set in parallel against M1's contracts, swapping stubs for real implementations without breaking anyone downstream. +### Squad C — Planning Engine -- **M1 — Core Engine**: swap in real Claude calls (retry/backoff, §8.5), real ChromaDB retrieval, prompt caching; build `chat_service.py` backend (SSE + citation resolution) *(Karan Bosamiya — Sr SE Python; Prit Chavda — SE Machine Learning; Tarun Nagpal — Trainee AI/ML)* -- **M2 — Knowledge Hub**: markdown/YAML/ticket chunkers, then tree-sitter code chunker, initial full-index pipeline, `POST /knowledge/repositories` *(Ishit Desai — SE Python; Aman Rajput — Trainee Data Engineering; Arjun Mulagapaka — Trainee Python)* -- **M3 — Planning Engine**: work-package extraction + dedup, story generation + INVEST critique, greedy sprint bin-packing + dependency inference *(Meet Shah — SE Python; Devansh Jagatiya — Trainee Python owns requirements extraction; Parth Harpal — Trainee Python owns story CRUD/sprint endpoints)* -- **M4 — Meetings & Risk**: meeting summarization (text path first, audio via faster-whisper if time allows), non-LLM risk checks (overloaded sprints, slipping action items) + LLM risk digest, Slack alert *(Parth Shah — SE Python; Smit Thakkar — Trainee Python owns meeting endpoint + action-item CRUD)* -- **M5 — Frontend Experience**: project/dashboard screens, requirements/stories UI, sprint Kanban (`@dnd-kit`), chat UI with SSE streaming — in that priority order per §6's frontend risk note *(Khushal Batham — Sr SE React; Bhargav Valani — SE React)* -- **M6 — DevOps & Quality**: integration tests landing as each module's endpoints ship, deploy to demo host, nginx SSE config, manual scenario testing begins on completed features *(Chaitanya Vekaria — Trainee DevOps; Shubham Nayak — QA Engineer; Chandresh Thakkar — Trainee QA)* +- **Meet Shah (SE Python, lead)** — Scaffolds `app/schemas/requirements.py`, `stories.py`, `sprints.py` matching §4.8/§5.3.2's field definitions. Stubs out the `POST /requirements` endpoint (accepts upload, returns `202` — no extraction logic yet). **Done when**: schemas are committed and the upload endpoint accepts a file and returns a placeholder response. +- **Devansh Jagatiya (Trainee Python)** — Paired with Meet. Implements `pdfplumber`/`python-docx` text extraction as a standalone function (not yet wired into the endpoint) — given a file, return raw text. **Done when**: a unit test passes extracting text from a sample PDF and a sample DOCX. +- **Parth Harpal (Trainee Python)** — Drafts the `stories` and `sprint_assignments` SQLAlchemy models per §5.3.2/§5.3.3, and the Pydantic `StoryOut`/`SprintPlanRequest` schemas per §4.8. **Done when**: models and schemas exist and import cleanly, ready to be included in Karan's migration sequence. -**Phase 2 exit checkpoint**: each module's demo checkpoint from §16.3–16.5 passes in isolation — story generation works, a connected repo answers chat questions with citations, a meeting produces a linked risk register entry. +### Squad D — Meetings & Risk Intelligence ---- +- **Parth Shah (SE Python, lead)** — Scaffolds `app/schemas/meetings.py`, `risks.py`. Stubs `POST /meetings` (accepts transcript text or audio upload, returns `202`, no summarization yet). **Done when**: endpoint accepts input and returns a placeholder `meeting_id` + `status: processing`. +- **Smit Thakkar (Trainee Python)** — Drafts `meetings`, `meeting_decisions`, `action_items`, `risk_register_snapshots`, `risks` SQLAlchemy models per §5.3.4/§5.3.5. **Done when**: models exist and match the column lists in Section 5, ready for the migration sequence. + +### Squad E — Frontend Experience -### Phase 3 — Integration, Polish & Demo Prep (Hours 14–24) +- **Khushal Batham (Sr SE React, lead)** — Sets up the Vite + React + Tailwind project skeleton, routing (`react-router`), and the login screen wired to Squad A's OAuth redirect. Kicks off the shared component library: a data table component and a status badge component, since every later screen needs both. **Done when**: `npm run dev` serves a working login screen that redirects to GitHub OAuth and lands back on an authenticated placeholder dashboard. +- **Bhargav Valani (SE React)** — Builds the second and third shared components: a form panel (used by requirements upload, meeting submission) and a loading/streaming indicator (used later by chat). Sets up the typed API client folder (`src/api/`) with one stub module per router matching §9's endpoint list, even before backend endpoints are real. **Done when**: shared component library has 4 components ready (table, badge, form panel, loading indicator); `src/api/` has stub functions for every planned endpoint. -Goal: modules stop working in isolation and start working *together* — this is where "everyone gets work" turns into "the system actually holds together end to end." +### Squad F — DevOps & Quality -- **M1 — Core Engine**: architecture diagram generation (stretch, only if ahead), then float to unblock whichever module is stuck *(Karan Bosamiya; Prit Chavda; Tarun Nagpal)* -- **M2 — Knowledge Hub**: index health endpoint, incremental webhook re-index (stretch), pair with M5 on chat citation rendering end to end *(Ishit Desai; Aman Rajput; Arjun Mulagapaka)* -- **M3 — Planning Engine**: story export to GitHub Issues (stretch), pair with M5 to finish Kanban drag-and-drop wiring *(Meet Shah; Devansh Jagatiya; Parth Harpal)* -- **M4 — Meetings & Risk**: meeting-to-story linking (rapidfuzz), `story_events` review flags, pair with M3 since linking writes to the same `stories` table *(Parth Shah; Smit Thakkar)* -- **M5 — Frontend Experience**: risk register UI, knowledge hub management UI (only if the golden path is already solid — see §6), final polish on golden-path screens *(Khushal Batham; Bhargav Valani)* -- **M6 — DevOps & Quality**: end-to-end smoke tests across all six modules together, freeze the deploy, drive **two full demo dress rehearsals**, final regression pass *(Chaitanya Vekaria; Shubham Nayak — leads rehearsal checklist; Chandresh Thakkar)* +- **Chaitanya Vekaria (Trainee DevOps)** — Writes `docker-compose.yml` (Postgres, Redis, backend skeleton, per §14.3) and a `.github/workflows/ci.yml` running `ruff` + `pytest` on every PR. Paired with Shubham for review since this is foundational infrastructure everyone else depends on. **Done when**: `docker-compose up` brings up Postgres + Redis + a health-check-passing backend container; a test PR shows CI running. +- **Shubham Nayak (QA Engineer, lead)** — Reviews Chaitanya's CI/compose setup. Drafts the master test scenario list from Section 9's endpoint error tables (happy path / 401 / 403 / 422 / 503 per endpoint) as a shared checklist document every squad can reference when writing their own tests. **Done when**: test scenario checklist is shared with all squad leads. +- **Chandresh Thakkar (Trainee QA)** — Paired with Shubham. Sets up the `tests/` folder structure (§12.2) and writes the first integration test (`test_auth.py`'s happy-path login test) against Karan's auth endpoint as soon as it's live. **Done when**: one real integration test passes in CI. -**Phase 3 exit checkpoint**: the full golden-path demo runs start to finish without a live engineer intervening — upload requirements → generate stories → plan sprint → connect a repo → ask a cited onboarding question → submit a meeting → see a risk register entry and a Slack alert. +**Phase 1 exit checkpoint (hour 3, all-hands standup)**: Karan confirms `AIService`/`rag_service` stubs are in `main`. Every squad lead confirms their scaffold compiles and their people know their Phase 2 assignment below. --- -### Cross-Module Pairing at Integration Points (Why Nobody Works in a Silo) +## 4. Phase 2 — Core Feature Build (Hours 3–14) -- **M1 ↔ M2/M3/M4**: every module's Phase 2 work depends on M1's real implementation landing on schedule — Karan's squad is the one that must not slip, since a delay there delays all three. -- **M2 ↔ M5**: chat citations only render correctly if M2's `knowledge_chunks` metadata and M1's `chat_service.py` citation format agree — Ishit and Khushal's squads should sync directly at the Phase 2→3 boundary, not just via the general standup. -- **M3 ↔ M4**: `story_events` (meeting-driven story flags, FR-5.5) is written by M4 but displayed against M3's story records — Parth Shah and Meet Shah should agree on the `story_events` schema by end of Phase 1, not discover the mismatch in Phase 3. -- **M5 ↔ everyone**: every backend module ships its API before the corresponding frontend screen can be finished — Khushal/Bhargav should get read access to each module's Pydantic response schemas (§4.8) as soon as they're drafted in Phase 1, not wait for the endpoint to be fully working. +**Phase goal**: each module's real functionality gets built in parallel against Squad A's contract. Squad A swaps its stubs for real implementations without changing signatures, so nobody downstream needs to change their code when that swap lands. -## 1. Your Roster +### Squad A — Core Engine -| # | Role | Level | -|---|---|---| -| 1 | Software Engineer — Python | Sr | -| 2 | Software Engineer — Python | Mid | -| 3 | Software Engineer — Python | Mid | -| 4 | Software Engineer — Python | Mid | -| 5 | Software Engineer — Machine Learning | Mid | -| 6 | Software Engineer — React | Sr | -| 7 | Software Engineer — React | Mid | -| 8 | QA Engineer | Mid | -| 9 | Trainee — AI/ML | Jr | -| 10 | Trainee — Data Engineering | Jr | -| 11 | Trainee — DevOps | Jr | -| 12 | Trainee — Python | Jr | -| 13 | Trainee — Python | Jr | -| 14 | Trainee — Python | Jr | -| 15 | Trainee — Python | Jr | -| 16 | Trainee — QA | Jr | - -**Skill distribution that shapes this plan**: 4 experienced Python engineers (1 Sr + 3 Mid) is enough to lead one backend module each. 1 ML engineer is a strong, deliberate fit for the AI/RAG core rather than a generic backend slot. Frontend has exactly 2 people (1 Sr, 1 Mid) for the entire UI surface — this is the tightest resource in the roster and is called out explicitly in §6. 6 trainees (4 Python, 1 AI/ML, 1 Data Engineering) need pairing with a senior/mid on their squad, not independent ownership of a module. +- **Karan Bosamiya** — Implements the real `AIService.call_claude()`: retry/backoff policy (§8.5), per-project semaphore (§4.7.2), structured-output validation against Pydantic schemas. Runs the Alembic migration sequence (§17.2), pulling in the model files drafted by Arjun, Parth Harpal, and Smit in Phase 1. **Done when**: a real Claude API call succeeds end to end through `AIService`, and `alembic upgrade head` runs clean with all squads' tables present. +- **Prit Chavda** — Implements the real `rag_service.retrieve()` against a live ChromaDB instance: embedding the query, similarity search, the re-ranking heuristics from §7.4 (file-proximity dedup, recency boost). **Done when**: a test query against a manually-seeded Chroma collection returns correctly ranked, deduplicated results. +- **Tarun Nagpal** — Builds out the real prompt templates in `prompts.py` for story generation, INVEST critique, and risk digest (§8.3), in close collaboration with Meet Shah (Squad C) and Parth Shah (Squad D) who know exactly what output shape their services need. Starts on `chat_service.py`'s citation-resolution logic (§7.6) — matching Claude's inline `[chunk_id]` tags back to `knowledge_chunks` rows. **Done when**: at least 3 prompt templates are drafted and validated against real Claude calls; citation resolution passes a manual test against sample chunk IDs. ---- +### Squad B — Knowledge Hub -## 2. Squad Structure (16 people, 6 squads) +- **Ishit Desai** — Builds the `tree-sitter` code chunker (§6.4.1) — the hardest chunking task, appropriately given to the squad lead. Wires the full ingestion pipeline (§6.3): connector → chunker → embed (via Squad A's now-real `AIService`) → Chroma upsert. **Done when**: a real repository can be connected and its Python/JS files show up as syntactically-chunked, embedded vectors in Chroma. +- **Aman Rajput** — Finishes `GitHubConnector` fully (Issues/PRs fetch per §6.2, `list_changed_files` for incremental diffing per §6.5). Builds the ticket chunker (§6.4.4). **Done when**: issues and PRs from a connected repo are fetched and chunked correctly. +- **Arjun Mulagapaka** — Builds the markdown chunker (§6.4.2) and YAML/CI chunker (§6.4.3) — the two simpler chunkers, good scope for a Phase 1→2 ramp-up. Wires `POST /knowledge/repositories` to actually kick off the background ingestion job (§10.2). **Done when**: connecting a repo triggers a real background ingestion job visible in `ingestion_jobs`. -Squad boundaries follow the folder/service ownership lines in §12.2 and §4.4.3, and every squad with trainees has at least one experienced engineer to pair with — a squad is never all-trainee. +### Squad C — Planning Engine -| Squad | Members | Owns (folder paths) | Sections | -|---|---|---|---| -| **A — Platform & AI Core** | Sr SE Python (lead), SE Machine Learning, Trainee AI/ML | `app/core/*`, `ai_service.py`, `rag_service.py`, `ai/prompts.py`, `chat_service.py`, `arch_diagram_service.py`, auth, early migrations | §4, §5, §7, §8, §13 | -| **B — Knowledge Hub** | SE Python #1 (lead), Trainee Data Engineering, Trainee Python #1 | `services/knowledge_hub/*`, `api/v1/knowledge.py`, `api/v1/webhooks.py` | §6 | -| **C — Planning Engine** | SE Python #2 (lead), Trainee Python #2, Trainee Python #3 | `requirements_service.py`, `story_service.py`, `sprint_service.py`, `api/v1/{requirements,stories,sprints}.py` | §8.6.1–8.6.3, §9.4–9.5 | -| **D — Meetings & Risk** | SE Python #3 (lead), Trainee Python #4 | `meeting_service.py`, `risk_service.py`, `whisper_service.py`, `api/v1/{meetings,risks}.py` | §8.6.4–8.6.5, §9.6–9.7 | -| **E — Frontend** | Sr SE React (lead), SE React | `frontend/*` — entire UI surface | §12.3, all FR UI requirements | -| **F — DevOps/QA** | Trainee DevOps, QA Engineer (lead), Trainee QA | `infra/*`, `.github/workflows/*`, `tests/integration/*`, deploy pipeline, demo environment | §10, §14, §17 | +- **Meet Shah** — Wires the real work-package extraction flow end to end (upload → text extraction → Claude call via Squad A → duplicate detection via cosine similarity, §2.5's FR). Builds story generation + INVEST critique two-pass flow (§8.6.2). **Done when**: uploading a requirements doc produces real extracted work packages, and generating stories from them produces stories plus INVEST critiques. +- **Devansh Jagatiya** — Finishes text-extraction wiring into the live endpoint (connects Phase 1's standalone function to the real upload flow). Then owns the `work_packages` CRUD endpoints (accept/reject/edit, FR-2.4) end to end. **Done when**: a user can upload a doc, see extracted work packages, and accept/reject/edit each one via the API. +- **Parth Harpal** — Owns the sprint side: greedy bin-packing algorithm (plain Python, FR-4.2) and the dependency-inference Claude call (via Squad A, FR-4.3) wired together into `POST /sprints/plan`. **Done when**: a sprint plan request returns sprints with stories allocated respecting velocity, and a dependency graph applied. -### Why the ML engineer goes to Squad A, not a generic backend squad +### Squad D — Meetings & Risk Intelligence -Embedding model selection (Voyage vs. OpenAI, §11.2), retrieval quality (re-ranking heuristics, chunk-type filtering, §7.4), and prompt template design for structured output (§8.3) are the parts of this system where ML judgment matters more than general backend skill. Pairing the ML engineer with the Sr Python engineer on `rag_service.py`/`ai_service.py`, and pairing the AI/ML trainee under the ML engineer, concentrates the one ML-specific skill set exactly where the architecture needs it most — and gives the trainee real mentorship instead of being dropped into a generic Python squad where nobody can review their embedding/prompt-quality decisions. +- **Parth Shah** — Wires meeting summarization end to end for the **text transcript path** first (audio/Whisper is a stretch item, only attempt after text path works): transcript in → Claude summary out → decisions/action items/risks/open questions persisted. Builds the risk digest flow (§8.6.5): non-LLM checks (overloaded sprints, slipping action items) merged with the LLM-derived risks. **Done when**: submitting a text transcript produces a real structured summary, and running risk assessment on a project with at least one story and one meeting produces a populated, severity-sorted risk register. +- **Smit Thakkar** — Owns `rapidfuzz` fuzzy-matching of meeting decisions/action items against story titles (FR-5.4, 80% threshold) and the `action_items` CRUD endpoint (owner/due-date assignment, FR-5.6). **Done when**: a meeting mentioning an existing story title by name gets correctly linked, and an action item with no owner shows the expected warning flag. -### Why Data Engineering trainee goes to Knowledge Hub +### Squad E — Frontend Experience -The ingestion pipeline (§6.3) — connectors pulling from GitHub/Azure DevOps, chunking, batch embedding, incremental re-indexing — is structurally an ETL pipeline. This is the one trainee-role-to-module match in the roster that's almost exact; use it. +- **Khushal Batham** — Builds the project dashboard screen (FR-1.5) and the sprint Kanban board with `@dnd-kit` drag-and-drop (FR-4.6–4.7), wired to Squad C's real sprint API as it comes online. **Done when**: dashboard shows live project data, and stories can be dragged between sprint columns with the change persisted via the API. +- **Bhargav Valani** — Builds the requirements/stories screens (upload, extracted work-package review, generated story list with INVEST critique display) and starts the chat UI shell with SSE consumption wired to Squad A's `chat_service.py` as it comes online. **Done when**: a user can upload a requirements doc, review/accept work packages, see generated stories, and the chat screen streams tokens from a real backend response. + +### Squad F — DevOps & Quality + +- **Shubham Nayak** — As each squad's endpoints land, writes/reviews the integration tests for them against the scenario checklist from Phase 1 — prioritize auth, project CRUD, and story generation first since those are the most-depended-on paths. **Done when**: integration tests exist and pass in CI for at least Squads A, B, and C's core endpoints. +- **Chaitanya Vekaria** — Deploys the growing backend to the demo host, configures nginx with the SSE-critical settings from §14.4 (`proxy_buffering off` on chat routes) — this is easy to get wrong and breaks chat streaming silently, so test it explicitly against Squad E's chat UI once both exist. **Done when**: the demo host serves the API behind nginx and a chat SSE request streams correctly through the proxy, not buffered. +- **Chandresh Thakkar** — Runs manual test passes against each squad's newly-landed features as they ship (paired with Shubham's automated tests, covering what's awkward to automate quickly — e.g., "does the Kanban drag-and-drop actually feel right"). Logs bugs directly to the responsible squad's channel. **Done when**: a running bug log exists and is triaged with each squad lead at every standup. + +**Phase 2 exit checkpoint (hour 14, all-hands standup)**: each module's own demo checkpoint (§16.3–16.5) passes in isolation — story generation works, a connected repo answers a chat question with a citation, a meeting produces a linked risk register entry with a Slack alert firing on a high-severity risk. --- -## 3. The Interface-Freeze Strategy (Load-Bearing Idea) +## 5. Phase 3 — Integration, Polish & Demo Prep (Hours 14–24) -The biggest risk is Squads B, C, D all needing `AIService.call_claude()` and `rag_service.retrieve()` before Squad A has a real implementation. Squad A's Sr Python engineer publishes both function signatures plus Pydantic schemas in the **first 90 minutes**, backed by a stub: +**Phase goal**: stop treating modules as islands. Every remaining task in this phase either connects two modules together or hardens the golden-path demo flow. This is where the leader (you) should be actively watching the cross-module pairings in §6, not just individual squad progress. -```python -# Hour 0–1.5 deliverable from Squad A — merged to main immediately -class AIService: - async def call_claude(self, project_id, prompt_template, variables, model="sonnet", - response_schema=None, stream=False, cache_key=None): - # STUB: returns canned responses matching response_schema - ... +### Squad A — Core Engine -async def retrieve(project_id, query, collection_name, chunk_types=None, - repository_id=None, top_k=10) -> list[RetrievedChunk]: - # STUB: returns fixed fake RetrievedChunk objects - ... -``` +- **Karan Bosamiya** — Floats across squads as the designated unblocker — checks in with Squad B/C/D leads at hour 15 specifically to catch any remaining `AIService`/`rag_service` gaps before they become late-stage fire drills. Only starts the architecture-diagram stretch goal (§8.6.6) if all squads report green by hour 16. +- **Prit Chavda** — Tunes retrieval quality based on real chat testing from Squad E — adjusting `top_k`, chunk-type filters, re-ranking weights (§7.4) using actual queries run against the actual connected demo repo, not synthetic tests. +- **Tarun Nagpal** — Finishes citation resolution end to end with Squad E's live chat UI (§6, M2↔M5 pairing below) — sits with Bhargav directly rather than working from a spec, since citation format mismatches are exactly the kind of bug that only shows up in integration. -- Squads B/C/D build their entire feature against the stub using real Pydantic schemas (§4.8, §5), so code compiles and tests pass against realistic shapes from hour 2 onward. -- The ML engineer and Sr Python engineer swap in the real implementation (real Claude calls, real Chroma retrieval, retry/caching per §8.4–§8.5) over the following hours **without changing the signature** — downstream squads' code doesn't change when the swap lands. -- **Non-negotiable rule**: nobody outside Squad A edits `ai_service.py` or `rag_service.py`. Requests for new capability go to Squad A as a ticket, not a PR. +### Squad B — Knowledge Hub -This matters even more with a trainee-heavy roster than it would with 16 senior engineers — trainees in Squads B/C/D need a stable, documented contract to build against; they're not the ones who should be debugging a half-finished `rag_service.py` while also learning the codebase. +- **Ishit Desai** — Builds the index health endpoint (§6.8, FR-7.9) and, only if ahead of schedule, incremental webhook re-indexing (§6.5). Pairs directly with Bhargav Valani (Squad E) to verify citations render correctly end to end against real ingested chunks. +- **Aman Rajput** — Supports Ishit on webhook re-indexing if attempted; otherwise focuses on hardening the initial-index path against the actual demo repository the team will use live (test it early, not for the first time during rehearsal). +- **Arjun Mulagapaka** — Finishes the markdown/YAML chunker edge cases found during real ingestion testing; supports integration testing with Squad F. ---- +### Squad C — Planning Engine -## 4. Mentorship Pairing (Explicit, Not Assumed) +- **Meet Shah** — Story export to GitHub Issues stretch goal (FR-3.6) if time allows; otherwise focuses on hardening story generation against edge-case requirements docs (very short docs, very long docs) found during QA testing. +- **Devansh Jagatiya** — Pairs with Khushal Batham (Squad E) to finish the requirements/stories UI wiring completely — every state (processing, extracted, accepted, rejected) needs to render correctly. +- **Parth Harpal** — Pairs with Khushal on Kanban drag-and-drop final wiring (§6, M3↔M5 pairing) — the sprint capacity-exceeded warning (§9.5) needs to actually show up in the UI, not just return correctly from the API. -Every squad with a trainee pairs them with a named senior/mid for code review and unblocking — call this out at the very first standup so it's not left implicit: +### Squad D — Meetings & Risk Intelligence -| Trainee | Paired with | What they own under supervision | -|---|---|---| -| Trainee AI/ML | SE Machine Learning | Prompt template drafts (§8.3), embedding call wiring, citation-resolution logic (§7.6) | -| Trainee Data Engineering | SE Python #1 (Squad B lead) | Connector implementation (`GitHubConnector`, §6.2), incremental re-index logic (§6.5) | -| Trainee Python #1 | SE Python #1 (Squad B lead) | Chunkers (§6.4) — start with markdown/YAML chunkers, simpler than tree-sitter code chunking | -| Trainee Python #2, #3 | SE Python #2 (Squad C lead) | Requirements extraction endpoint, story CRUD endpoints — split by sub-feature, not by pairing both on everything | -| Trainee Python #4 | SE Python #3 (Squad D lead) | Meeting submission endpoint, action-item CRUD | -| Trainee DevOps | QA Engineer + whoever is free in Squad A after hour 3 | `docker-compose.yml`, CI pipeline steps (§14.6) — devops trainee should NOT be solely responsible for the demo environment going live; treat as paired work | -| Trainee QA | QA Engineer (Squad F lead) | Manual test pass execution against each squad's endpoints as they land, following the integration test scenarios in §9's error tables | +- **Parth Shah** — Finalizes the risk digest quality against real test data (a realistic project with several stories, an overloaded sprint, and a couple of meetings) — this is the scenario that will actually run during the demo, so test it directly, not with toy data. +- **Smit Thakkar** — Pairs directly with Meet Shah (Squad C) on `story_events` — since meeting-driven story flags are written by Squad D but displayed against Squad C's story records, this pairing (§6, M3↔M4) needs to happen face-to-face, not just via shared schema docs. -**Every PR from a trainee is reviewed by their pair before merge** — this is a review-cadence rule, not a suggestion, since a trainee-authored PR merged straight to `main` in a 6-squad hackathon is exactly how a silent `project_id` filter omission (the #1 risk called out in §13.5) slips through. +### Squad E — Frontend Experience ---- +- **Khushal Batham** — Owns final polish on the golden-path screens only, per §7's frontend risk note: dashboard → stories → Kanban → chat. Risk register and knowledge hub management screens get the simplest possible UI (a plain table) if time is short — make this call explicitly at the hour-16 standup, not silently at hour 23. +- **Bhargav Valani** — Finishes chat UI citation rendering and Mermaid diagram rendering (if Squad A's stretch goal lands). Runs a full pass on loading states and error states across every screen (§4.6's error codes need to show something sensible in the UI, not a blank screen). + +### Squad F — DevOps & Quality -## 5. Parallel Timeline (24–36 hour hackathon) +- **Shubham Nayak** — Leads the end-to-end smoke test across all six modules together, then leads the demo dress rehearsal checklist (§8) — run it at least twice. +- **Chaitanya Vekaria** — Freezes the deploy once rehearsal #1 passes; only takes new deploys for critical bug fixes found during rehearsal #2, not for new features. +- **Chandresh Thakkar** — Executes the full golden-path scenario manually at least three times before the real demo, timing each run, and flags anything that feels slow or confusing to the relevant squad lead immediately. -| Hours | A (Platform/AI) | B (Knowledge Hub) | C (Planning) | D (Meetings/Risk) | E (Frontend) | F (DevOps/QA) | -|---|---|---|---|---|---|---| -| 0–1.5 | Repo scaffold, DB connection, auth skeleton, **publish `AIService`/`rag_service` stubs** | Read interfaces, scaffold `SourceConnector` | Read interfaces, scaffold schemas | Read interfaces, scaffold schemas | Frontend shell, routing, auth screens | CI skeleton, Docker images, `.env.example` | -| 1.5–3 | OAuth + JWT (§13.2), migrations 0001/0002/0010 (§17); ML engineer starts embedding integration | Trainee Data Eng + SE: `GitHubConnector`, file tree walk | Trainee pair: requirements upload + extraction against stub | Trainee: meeting transcript submission against stub | Project CRUD screens, dashboard shell | CI running tests on every PR | -| 3–8 | Swap in real `call_claude`; ML engineer + trainee AI/ML build real `retrieve()` against live Chroma | Chunkers (markdown/YAML first, then code); initial index pipeline | Story generation + INVEST critique end to end | Meeting summarization (text path) end to end | Chat UI + SSE consumption (against Squad A's now-real chat backend) | Integration tests: auth + project CRUD; nginx SSE config draft (§14.4) | -| 8–14 | Chat backend (`chat_service.py`) + citation resolution; support other squads | Chat retrieval smoke test with Squad E; tree-sitter code chunking | Sprint bin-packing + dependency inference + Kanban API | Risk digest (LLM + non-LLM checks), Slack alert | Kanban drag-and-drop (with Squad C); citation rendering | Deploy to demo host; QA begins scenario testing on landed features | -| 14–20 | Architecture diagram service (`arch_diagram_service.py`) — stretch, only if ahead of schedule | Index health endpoint; incremental webhook re-index if time allows | Story export (stretch) | Meeting-to-story linking (rapidfuzz), story_events | **Focus period — see §6 frontend risk**: prioritize dashboard, stories, kanban, chat over risk register/knowledge hub UI if behind | End-to-end smoke tests across all modules; trainee QA executes manual scenarios | -| 20–24+ | Bugfix rotation — floats to whichever squad is blocked | Bugfix rotation | Bugfix rotation | Bugfix rotation | Final UI polish on the golden-path screens only | Freeze deploy; QA Engineer runs final regression pass | +**Phase 3 exit checkpoint**: the full golden-path demo — upload requirements → generate stories → plan sprint → connect a repo → ask a cited onboarding question → submit a meeting → see a risk register entry and Slack alert — runs start to finish with no engineer intervening live. --- -## 6. Explicit Risk: Frontend Has Only 2 People +## 6. Cross-Module Pairing Points (Watch These Directly) -Two React engineers (1 Sr, 1 Mid) against seven UI surfaces (dashboard, requirements/stories, sprint Kanban, meetings, risk register, knowledge hub, chat with SSE+Mermaid) is the tightest ratio in this roster — tighter than any backend squad. Mitigations: +These are the specific moments where two squads' work has to agree exactly, and where "everyone did their own task correctly" can still add up to a broken integration if the pairing doesn't happen deliberately: -1. **Build one shared component library first** (data table, form panel, status badge, loading/streaming indicator) in the first few hours — every subsequent page assembles from these instead of each screen being bespoke. -2. **Prioritize by demo path, not by module parity.** The golden-path demo (§16.3–16.5's checkpoints) needs: dashboard → requirements/stories → sprint Kanban → chat with citations. Risk register and knowledge hub management screens can be simpler (a table, no fancy interaction) if time runs short — say this explicitly at the hour-8 standup, don't let it be a surprise at hour 20. -3. **Do not pull a Python trainee into React work as a rescue plan** — context-switching a Python trainee into an unfamiliar frontend stack under time pressure produces worse output than 2 focused React engineers cutting scope deliberately. If truly desperate late in the timeline, the QA engineer or DevOps trainee doing static HTML/CSS for a low-interactivity screen (e.g., a read-only risk table) is a safer fallback than pulling a backend trainee. +- **M1 ↔ M2/M3/M4** (hour 3 and hour 14 checkpoints): Karan Bosamiya's Phase 1 stub deadline and Phase 2 real-implementation swap are the two moments every other squad either gets unblocked or doesn't — as the leader, confirm this explicitly at both standups rather than assuming it happened. +- **M2 ↔ M5** (Phase 3): Ishit Desai and Bhargav Valani must sit together to verify a real citation (`file_path`, `line_range`, `repo_name`) renders correctly end to end — this is a two-person, same-room task, not something that can be verified by each squad testing separately. +- **M3 ↔ M4** (end of Phase 1, revisited Phase 3): Meet Shah and Parth Shah agree on the `story_events` schema early, then Smit Thakkar and Devansh Jagatiya/Parth Harpal verify the write-then-display flow works together in Phase 3. +- **M5 ↔ everyone** (continuous): Khushal Batham and Bhargav Valani need each backend squad's Pydantic response schema the moment it's drafted (Phase 1), not the moment the endpoint is fully working — give frontend read access to schema files early so they're never the last ones building against a moving target. --- -## 7. Coordination Mechanics +## 7. Trainee Review Gate -- **Standups**: 15 min, every 3–4 hours. One rep per squad: done / blocked / needs-from-another-squad. -- **`#blockers` channel**, separate from each squad's working channel. -- **Branching**: `main` + one branch per squad, PRs merge after CI passes (§14.6). Rebase off `main` at each standup. -- **Schema/migration ownership**: Squad A owns `app/models/` and the Alembic sequence (§17.2) — other squads request changes, they don't write their own migrations, avoiding numbering collisions across 6 branches. -- **Merge order**: matches FK dependency order (§5.5/§17.2) — A's auth/DB tables first, then C's traceability chain, then B's knowledge hub tables, then D's meetings/risk tables. -- **Trainee PR review gate** (§4): a trainee's PR needs their named pair's approval before merge — make this a branch protection rule in the repo, not a verbal agreement, given the pace of a hackathon. +Every PR authored by a trainee (Tarun Nagpal, Aman Rajput, Chaitanya Vekaria, Arjun Mulagapaka, Devansh Jagatiya, Parth Harpal, Smit Thakkar, Chandresh Thakkar) requires approval from their named pair/lead before merging to `main` — set this as a branch protection rule, not a verbal agreement. This is what catches a missing `project_id` filter (§13.5's top multi-tenancy risk) or a schema mismatch before it reaches `main` in a fast-moving 16-person hackathon. --- -## 8. Demo Rehearsal (Final 2–3 Hours) +## 8. Demo Rehearsal Checklist (Final 2–3 Hours) + +Run twice, minimum. Shubham Nayak drives the checklist; one representative per squad stands by to fix their part live if something breaks during rehearsal (not during the actual demo). Assign a single narrator — suggest Karan Bosamiya or Khushal Batham, whoever is more comfortable presenting — to walk the golden path end to end: + +1. Log in via GitHub OAuth +2. Create a project, upload a requirements document +3. Review and accept extracted work packages +4. Generate stories, show the INVEST critique +5. Plan a sprint, show the Kanban board, drag a story between sprints +6. Connect a GitHub repository, wait for indexing to complete +7. Ask the onboarding assistant a question, show the streamed answer with a working citation +8. Submit a meeting transcript, show the generated summary and a linked story +9. Run risk assessment, show the severity-sorted risk register and the Slack alert firing -Run the full dress rehearsal at least twice. QA Engineer drives the checklist; one person per squad is on standby to fix their module live if something breaks during rehearsal. Assign a single demo narrator (could be the Sr Python or Sr React engineer, or a non-coding team lead if one exists) walking the golden path end to end: upload requirements → generate stories → plan sprint → connect a repo → ask the onboarding assistant a cited question → submit a meeting → run risk assessment → see a Slack alert. This is the real test of whether the interface-freeze strategy in §3 held up under integration — if it didn't, this rehearsal is where you find out with time left to fix it, not during the actual demo. +If any step breaks during rehearsal, the responsible squad lead fixes it before rehearsal #2 — this is the actual test of whether the whole plan held together, not just whether each squad finished their own tasks.