feat(mma): Refine tier roles, tool access, and observability
This commit is contained in:
@@ -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
|
||||
|
||||
Reference in New Issue
Block a user