docs(conductor): Add Token Firewalling and Model Switching Strategy

This commit is contained in:
2026-02-24 22:45:17 -05:00
parent f76054b1df
commit 10c5705748

View File

@@ -358,3 +358,16 @@ A task is complete when:
- Document lessons learned - Document lessons learned
- Optimize for user happiness - Optimize for user happiness
- Keep things simple and maintainable - Keep things simple and maintainable
## Conductor Token Firewalling & Model Switching Strategy
To emulate the 4-Tier MMA Architecture within the standard Conductor extension without requiring a custom fork, adhere to these strict workflow policies:
### 1. Active Model Switching (Simulating the 4 Tiers)
- **Phase Planning & Macro Merges (Tier 1):** Use high-reasoning models (e.g., Gemini 1.5 Pro or Claude 3.5 Sonnet) when running \/conductor:setup\ or when reviewing a major phase checkpoint.
- **Track Delegation & Implementation (Tier 2/3):** Switch your CLI to a mid-tier model (e.g., Gemini 1.5 Flash) before invoking \/conductor:implement\. This reserves the expensive model for architecture decisions while letting Flash handle the heads-down coding.
- **QA/Fixing (Tier 4):** If a test fails with a massive traceback, **DO NOT** paste the traceback into the main conductor thread. Instead, switch to a fast/cheap model in a separate, isolated CLI instance, ask for the fix, and then manually apply the fix or provide the 20-word solution to the Conductor thread.
### 2. Context Checkpoints (The Token Firewall)
- The **Phase Completion Verification and Checkpointing Protocol** is the project's primary defense against token bloat.
- When a Phase is marked complete and a checkpoint commit is created, the AI Agent must actively interpret this as a **"Context Wipe"** signal. It should summarize the outcome in its git notes and move forward treating the checkpoint as absolute truth, deliberately dropping earlier conversational history and trial-and-error logs to preserve token bandwidth for the next phase.