MMA_Support draft

MMA_Support/Tier1_Orchestrator.md

@@ -1,30 +1,38 @@
-# Tier 1: User-Facing Model (Orchestrator/Router)
+# Tier 1: The Top-Level Orchestrator (Product Manager)
 
-The User-Facing Model is the entry point for all user interactions. It serves as the "brain" that understands what the user wants and decides how the system should respond.
+**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.
 
-## Key Responsibilities
+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.
 
-### 1. Intent Recognition
-*   Analyze the user's natural language input.
-*   Classify the request into one or more categories (e.g., "request for code", "general inquiry", "data analysis").
-*   Extract key parameters and constraints from the user's query.
+## Memory Context & Paths
 
-### 2. Routing
-*   Map recognized intents to specific Tier 2 models or tools.
-*   Determine if multiple specialized tools need to be called in sequence or parallel.
-*   Handle tool dispatching and manage the flow of data between tiers.
+### 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.
 
-### 3. Context Management
-*   Maintain the history of the conversation.
-*   Decide what information from the history is relevant to the current turn.
-*   Synthesize a coherent prompt for downstream models based on the current context.
+### 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.
 
-### 4. Response Synthesis
-*   Integrate the raw outputs from Tier 2 models into a final, user-friendly response.
-*   Ensure the tone and style are consistent with user expectations.
-*   Validate that the final response directly addresses the user's original intent.
-
-## Characteristics
-*   **High Reasoning:** Needs to be strong at logic and instruction following.
-*   **General Purpose:** While not necessarily a domain expert, it must be broad enough to understand any valid user input.
-*   **Speed:** Should ideally be responsive to minimize perceived latency.
+### 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.