Files
manual_slop/MMA_Support/Tier1_Orchestrator.md
2026-02-24 19:11:15 -05:00

2.8 KiB

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.