# 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.