# Tier 1: The Top-Level Orchestrator (Product Manager)

**Designated Models:** Gemini 3.1 Pro, Claude 3.5 Sonnet.
**Execution Frequency:** Low (Start of feature, Macro-merge resolution).
**Core Role:** Epic planning, architecture enforcement, and cross-module task delegation.

The Tier 1 Orchestrator is the most capable and expensive model in the hierarchy. It operates strictly on metadata, summaries, and executive-level directives. It **never** sees raw implementation code.

## Memory Context & Paths

### Path A: Epic Initialization (Project Planning)
*   **Trigger:** User drops a massive new feature request or architectural shift into the main UI.
*   **What it Sees (Context):**
    *   **The User Prompt:** The raw feature request.
    *   **Project Meta-State:** `project.toml` (rules, allowed languages, dependencies).
    *   **Repository Map:** A strict, file-tree outline (names and paths only).
    *   **Global Architecture Docs:** High-level markdown files (e.g., `docs/guide_architecture.md`).
*   **What it Ignores:** All source code, all AST skeletons, and all previous micro-task histories.
*   **Output Format:** A JSON array (Godot ECS Flat List format) of `Tracks` (Jira Epics), identifying which modules will be affected, the required Tech Lead persona, and the severity level.

### Path B: Track Delegation (Sprint Kickoff)
*   **Trigger:** The PM is handing a defined Track down to a Tier 2 Tech Lead.
*   **What it Sees (Context):**
    *   **The Target Track:** The specific goal and Acceptance Criteria generated in Path A.
    *   **Module Interfaces (Skeleton View):** Strict AST skeleton (just class/function definitions) *only* for the modules this specific Track is allowed to touch.
    *   **Track Roster:** A list of currently active or completed Tracks to prevent duplicate work.
*   **What it Ignores:** Unrelated module docs, original massive user prompt, implementation details.
*   **Output Format:** A compiled "Track Brief" (system prompt + curated file list) passed to instantiate the Tier 2 Tech Lead panel.

### Path C: Macro-Merge & Acceptance Review (Severity Resolution)
*   **Trigger:** A Tier 2 Tech Lead reports "Track Complete" and submits a pull request/diff for a "High Severity" task.
*   **What it Sees (Context):**
    *   **Original Acceptance Criteria:** The Track's goals.
    *   **Tech Lead's Executive Summary:** A ~200-word explanation of the chosen implementation algorithm.
    *   **The Macro-Diff:** Actual changes made to the codebase.
    *   **Curated Implementation View:** For boundary files, ensuring the merge doesn't break foreign modules.
*   **What it Ignores:** Tier 3 Worker trial-and-error histories, Tier 4 error logs, raw bodies of unchanged functions.
*   **Output Format:** "Approved" (commits to memory) OR "Rejected" with specific architectural feedback for Tier 2.