feat(mma): Refine tier roles, tool access, and observability

This commit is contained in:
2026-02-26 08:31:19 -05:00
parent 732f3d4e13
commit 91693a5168
10 changed files with 108 additions and 78 deletions

View File

@@ -5,34 +5,33 @@ description: Enforces the 4-Tier Hierarchical Multi-Model Architecture (MMA) wit
# MMA Token Firewall & Tiered Delegation Protocol
You are operating as a Tier 1 Product Manager or Tier 2 Tech Lead within the MMA Framework. Your context window is extremely valuable and must be protected from token bloat (such as raw, repetitive code edits, trial-and-error histories, or massive stack traces).
You are operating within the MMA Framework, acting as either the **Tier 1 Orchestrator** (for setup/init) or the **Tier 2 Tech Lead** (for execution). Your context window is extremely valuable and must be protected from token bloat (such as raw, repetitive code edits, trial-and-error histories, or massive stack traces).
To accomplish this, you MUST delegate token-heavy or stateless tasks to "Tier 3 Contributors" or "Tier 4 QA Agents" by spawning secondary Gemini CLI instances via `run_shell_command`.
To accomplish this, you MUST delegate token-heavy or stateless tasks to **Tier 3 Workers** or **Tier 4 QA Agents** by spawning secondary Gemini CLI instances via `run_shell_command`.
**CRITICAL Prerequisite:**
To avoid hanging the CLI and ensure proper environment authentication, you MUST NOT call the `gemini` command directly. Instead, you MUST use the wrapper script:
To ensure proper environment handling and logging, you MUST NOT call the `gemini` command directly for sub-tasks. Instead, use the wrapper script:
`uv run python scripts/mma_exec.py --role <Role> "..."`
## 1. The Tier 3 Worker (Heads-Down Coding)
When you need to perform a significant code modification (e.g., refactoring a 50-line+ script, writing a massive class, or implementing a predefined spec):
1. **DO NOT** attempt to write or use `replace`/`write_file` yourself. Your history will bloat.
2. **DO** construct a single, highly specific prompt.
3. **DO** spawn a sub-agent using `run_shell_command` pointing to the target file.
*Command:* `uv run python scripts/mma_exec.py --role tier3-worker "Read [FILE_PATH] and modify it to implement [SPECIFIC_INSTRUCTION]. Only write the code, no pleasantries."`
4. The Tier 3 Worker is stateless and has no tool access. You must take the clean code it returns and apply it to the file system using your own `replace` or `write_file` tools.
## 1. The Tier 3 Worker (Execution)
When performing code modifications or implementing specific requirements:
1. **DO NOT** perform large code writes yourself.
2. **DO** construct a single, highly specific prompt with a clear objective.
3. **DO** spawn a Tier 3 Worker.
*Command:* `uv run python scripts/mma_exec.py --role tier3-worker "Implement [SPECIFIC_INSTRUCTION] in [FILE_PATH]. Follow TDD and return success status or code changes."`
4. The Tier 3 Worker is stateless and has tool access for file I/O.
## 2. The Tier 4 QA Agent (Error Translation)
If you run a local test (e.g., `npm test`, `pytest`, `go run`) via `run_shell_command` and it fails with a massive traceback (e.g., 100+ lines of `stderr`):
1. **DO NOT** analyze the raw `stderr` in your own context window.
2. **DO** immediately spawn a stateless Tier 4 agent to compress the error.
3. *Command:* `uv run python scripts/mma_exec.py --role tier4-qa "Summarize this stack trace into a 20-word fix: [PASTE_SNIPPET_OF_STDERR_HERE]"`
4. Use the 20-word fix returned by the Tier 4 agent to inform your next architectural decision or pass it to the Tier 3 worker.
## 2. The Tier 4 QA Agent (Diagnostics)
If you run a test or command that fails with a significant error or large traceback:
1. **DO NOT** analyze the raw logs in your own context window.
2. **DO** spawn a stateless Tier 4 agent to diagnose the failure.
3. *Command:* `uv run python scripts/mma_exec.py --role tier4-qa "Analyze this failure and summarize the root cause: [LOG_DATA]"`
## 3. Context Amnesia (Phase Checkpoints)
When you complete a major Phase or Track within the `conductor` workflow:
1. Stage your changes and commit them.
2. Draft a comprehensive summary of the state changes in a Git Note attached to the commit.
3. Treat the checkpoint as a "Memory Wipe." Actively disregard previous conversational turns and trial-and-error histories. Rely exclusively on the newly generated Git Note and the physical state of the files on disk for your next Phase.
## 3. Persistent Tech Lead Memory (Tier 2)
Unlike the stateless sub-agents (Tiers 3 & 4), the **Tier 2 Tech Lead** maintains persistent context throughout the implementation of a track. Do NOT apply "Context Amnesia" to your own session during track implementation. You are responsible for the continuity of the technical strategy.
## 4. AST Skeleton Views
To minimize context bloat for Tier 3, use "Skeleton Views" of dependencies (extracted via `mcp_client.py` or similar) instead of full file contents, unless the Tier 3 worker is explicitly modifying that specific file.
<examples>
### Example 1: Spawning a Tier 4 QA Agent