manual_slop/MMA_Support/Tier2_TechLead.md

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.