46 lines
3.7 KiB
Markdown
46 lines
3.7 KiB
Markdown
# Tier 2: The Track Conductor (Tech Lead)
|
|
|
|
**Designated Models:** Gemini 3.0 Flash, Gemini 2.5 Pro.
|
|
**Execution Frequency:** Medium.
|
|
**Core Role:** Module-specific planning, code review, spawning Worker agents, and Topological Dependency Graph management.
|
|
|
|
The Tech Lead bridges the gap between high-level architecture and actual code syntax. It operates in a "need-to-know" state, utilizing AST parsing (`file_cache.py`) to keep token counts low while maintaining structural awareness of its assigned modules.
|
|
|
|
## Memory Context & Paths
|
|
|
|
### Path A: Sprint Planning (Task Delegation)
|
|
* **Trigger:** Tier 1 (PM) assigns a Track (Epic) and wakes up the Tech Lead.
|
|
* **What it Sees (Context):**
|
|
* **The Track Brief:** Acceptance Criteria from Tier 1.
|
|
* **Curated Implementation View (Target Modules):** AST-extracted class structures, docstrings, and `# [HOT]` function bodies for the 1-3 files this Track explicitly modifies.
|
|
* **Skeleton View (Foreign Modules):** Only function signatures and return types for external dependencies.
|
|
* **What it Ignores:** The rest of the repository, the PM's overarching project-planning logic, raw line-by-line code of non-hot functions.
|
|
* **Output Format:** A JSON array (Godot ECS Flat List format) of discrete Tier 3 `Tickets` (e.g., Ticket 1: *Write DB migration script*, Ticket 2: *Update core API endpoints*), including `depends_on` pointers to construct an execution DAG.
|
|
|
|
### Path B: Code Review (Local Integration)
|
|
* **Trigger:** A Tier 3 Contributor completes a Ticket and submits a diff, OR Tier 4 (QA) flags a persistent failure.
|
|
* **What it Sees (Context):**
|
|
* **Specific Ticket Goal:** What the Contributor was instructed to do.
|
|
* **Proposed Diff:** The exact line changes submitted by Tier 3.
|
|
* **Test/QA Output:** Relevant logs from Tier 4 compiler checks.
|
|
* **Curated Implementation View:** To cross-reference the proposed diff against the existing architecture.
|
|
* **What it Ignores:** The Contributor's internal trial-and-error chat history. It only sees the final submission.
|
|
* **Output Format:** *Approve* (merges diff into working branch and updates Curated View) or *Reject* (sends technical critique back to Tier 3).
|
|
|
|
### Path C: Track Finalization (Upward Reporting)
|
|
* **Trigger:** All Tier 3 Tickets assigned to this Track are marked "Approved."
|
|
* **What it Sees (Context):**
|
|
* **Original Track Brief:** To verify requirements were met.
|
|
* **Aggregated Track Diff:** The sum total of all changes made across all Tier 3 Tickets.
|
|
* **Dependency Delta:** A list of any new foreign modules or libraries imported.
|
|
* **What it Ignores:** The back-and-forth review cycles, original AST Curated View.
|
|
* **Output Format:** An Executive Summary and the final Macro-Diff, sent back to Tier 1.
|
|
|
|
### Path D: Contract-First Delegation (Stub-and-Resolve)
|
|
* **Trigger:** Tier 2 evaluates a Track and detects a cross-module dependency (or a single massive refactor) requiring an undefined signature.
|
|
* **Role:** Force Interface-Driven Development (IDD) to prevent hallucination.
|
|
* **Execution Flow:**
|
|
1. **Contract Definition:** Splits requirement into a `Stub Ticket`, `Consumer Ticket`, and `Implementation Ticket`.
|
|
2. **Stub Generation:** Spawns a cheap Tier 3 worker (e.g., DeepSeek V3 `contract_stubber` archetype) to generate the empty function signature, type hints, and docstrings.
|
|
3. **Skeleton Broadcast:** The stub merges, and the system instantly re-runs Tree-sitter to update the global Skeleton View.
|
|
4. **Parallel Implementation:** Tier 2 simultaneously spawns the `Consumer` (codes against the skeleton) and the `Implementer` (fills the stub logic) in isolated contexts. |