update progress snapshot

- Updated metadata.json status to completed
- Fixed corrupted plan.md (was damaged by earlier loop)
- Cleaned up duplicate Goal line in tracks.md

Checkpoint: 02abfc4

.claude/commands/conductor-setup.md

@@ -22,7 +22,7 @@ Bootstrap a Claude Code session with full conductor context. Run this at session
    - Identify the track with `[~]` in-progress tasks
 
 3. **Check Session Context:**
-   - Read `TASKS.md` if it exists — check for IN_PROGRESS or BLOCKED tasks
+   - Read `conductor/tracks.md` if it exists — check for IN_PROGRESS or BLOCKED tasks
    - Read last 3 entries in `JOURNAL.md` for recent activity
    - Run `git log --oneline -10` for recent commits
 

.opencode/agents/explore.md

@@ -2,8 +2,7 @@
 description: Fast, read-only agent for exploring the codebase structure
 mode: subagent
 model: MiniMax-M2.5
-temperature: 0.0
-steps: 8
+temperature: 0.2
 permission:
   edit: deny
   bash:
@@ -22,6 +21,7 @@ You are a fast, read-only agent specialized for exploring codebases. Use this wh
 You MUST use Manual Slop's MCP tools. Native OpenCode tools are unreliable.
 
 ### Read-Only MCP Tools (USE THESE)
+
 | Native Tool | MCP Tool |
 |-------------|----------|
 | `read` | `manual-slop_read_file` |
@@ -34,12 +34,14 @@ You MUST use Manual Slop's MCP tools. Native OpenCode tools are unreliable.
 | - | `manual-slop_get_tree` (directory structure) |
 
 ## Capabilities
+
 - Find files by name patterns or glob
 - Search code content with regex
 - Navigate directory structures
 - Summarize file contents
 
 ## Limitations
+
 - **READ-ONLY**: Cannot modify any files
 - **NO EXECUTION**: Cannot run tests or scripts
 - **EXPLORATION ONLY**: Use for discovery, not implementation
@@ -62,7 +64,9 @@ Use: `manual-slop_get_tree` or `manual-slop_list_directory`
 Use: `manual-slop_get_file_summary` for heuristic summary
 
 ## Report Format
+
 Return concise findings with file:line references:
+
 ```
 ## Findings
 
@@ -74,4 +78,4 @@ Return concise findings with file:line references:
 
 ### Summary
 [One-paragraph summary of findings]
-```
+```

.opencode/agents/general.md

@@ -2,8 +2,7 @@
 description: General-purpose agent for researching complex questions and executing multi-step tasks
 mode: subagent
 model: MiniMax-M2.5
-temperature: 0.2
-steps: 15
+temperature: 0.3
 ---
 
 A general-purpose agent for researching complex questions and executing multi-step tasks. Has full tool access (except todo), so it can make file changes when needed.
@@ -13,6 +12,7 @@ A general-purpose agent for researching complex questions and executing multi-st
 You MUST use Manual Slop's MCP tools. Native OpenCode tools are unreliable.
 
 ### Read MCP Tools (USE THESE)
+
 | Native Tool | MCP Tool |
 |-------------|----------|
 | `read` | `manual-slop_read_file` |
@@ -26,6 +26,7 @@ You MUST use Manual Slop's MCP tools. Native OpenCode tools are unreliable.
 | - | `manual-slop_get_tree` (directory structure) |
 
 ### Edit MCP Tools (USE THESE)
+
 | Native Tool | MCP Tool |
 |-------------|----------|
 | `edit` | `manual-slop_edit_file` (find/replace, preserves indentation) |
@@ -35,11 +36,13 @@ You MUST use Manual Slop's MCP tools. Native OpenCode tools are unreliable.
 | `edit` | `manual-slop_py_set_var_declaration` (replace variable) |
 
 ### Shell Commands
+
 | Native Tool | MCP Tool |
 |-------------|----------|
 | `bash` | `manual-slop_run_powershell` |
 
 ## Capabilities
+
 - Research and answer complex questions
 - Execute multi-step tasks autonomously
 - Read and write files as needed
@@ -47,13 +50,22 @@ You MUST use Manual Slop's MCP tools. Native OpenCode tools are unreliable.
 - Coordinate multiple operations
 
 ## When to Use
+
 - Complex research requiring multiple file reads
 - Multi-step implementation tasks
 - Tasks requiring autonomous decision-making
 - Parallel execution of related operations
 
+## Code Style (for Python)
+
+- 1-space indentation
+- NO COMMENTS unless explicitly requested
+- Type hints where appropriate
+
 ## Report Format
+
 Return detailed findings with evidence:
+
 ```
 ## Task: [Original task]
 
@@ -69,4 +81,4 @@ Return detailed findings with evidence:
 
 ### Recommendations
 - [Suggested next steps if applicable]
-```
+```

.opencode/agents/tier1-orchestrator.md

@@ -2,8 +2,7 @@
 description: Tier 1 Orchestrator for product alignment, high-level planning, and track initialization
 mode: primary
 model: MiniMax-M2.5
-temperature: 0.4
-steps: 50
+temperature: 0.5
 permission:
   edit: ask
   bash:
@@ -17,6 +16,12 @@ STRICT SYSTEM DIRECTIVE: You are a Tier 1 Orchestrator.
 Focused on product alignment, high-level planning, and track initialization.
 ONLY output the requested text. No pleasantries.
 
+## Context Management
+
+**MANUAL COMPACTION ONLY** — Never rely on automatic context summarization.
+Use `/compact` command explicitly when context needs reduction.
+Preserve full context during track planning and spec creation.
+
 ## CRITICAL: MCP Tools Only (Native Tools Banned)
 
 You MUST use Manual Slop's MCP tools. Native OpenCode tools are unreliable.
@@ -60,16 +65,16 @@ Before ANY other action:
 2. [ ] Read `conductor/tech-stack.md`
 3. [ ] Read `conductor/product.md`, `conductor/product-guidelines.md`
 4. [ ] Read relevant `docs/guide_*.md` for current task domain
-5. [ ] Check `TASKS.md` for active tracks
+5. [ ] Check `conductor/tracks.md` for active tracks
 6. [ ] Announce: "Context loaded, proceeding to [task]"
 
 **BLOCK PROGRESS** until all checklist items are confirmed.
 
 ## Primary Context Documents
 
-Read at session start: 
+Read at session start:
 
-- All immediate files in ./conductor, a listing of all direcotires within ./conductor/tracks, ./conductor/archive.
+- All immediate files in ./conductor, a listing of all directories within ./conductor/tracks, ./conductor/archive.
 - All docs in ./docs
 - AST Skeleton summaries of: ./src, ./simulation, ./tests, ./scripts python files.
 
@@ -90,20 +95,26 @@ When planning tracks that touch core systems, consult the deep-dive docs:
 - Set up the project environment (`/conductor-setup`)
 - Delegate track execution to the Tier 2 Tech Lead
 
-## The Surgical Methodology
+## The Surgical Methodology (MANDATORY)
 
 ### 1. MANDATORY: Audit Before Specifying
 
 NEVER write a spec without first reading actual code using MCP tools.
-Use `manual-slop_py_get_code_outline`, `manual-slop_py_get_definition`, 
+Use `manual-slop_py_get_code_outline`, `manual-slop_py_get_definition`,
 `manual-slop_py_find_usages`, and `manual-slop_get_git_diff` to build a map.
-Document existing implementations with file:line references in a 
+Document existing implementations with file:line references in a
 "Current State Audit" section in the spec.
 
+**FAILURE TO AUDIT = TRACK FAILURE** — Previous tracks failed because specs
+asked to implement features that already existed.
+
 ### 2. Identify Gaps, Not Features
 
 Frame requirements around what's MISSING relative to what exists.
 
+GOOD: "The existing `_render_mma_dashboard` (gui_2.py:2633-2724) has a token usage table but no cost column."
+BAD: "Build a metrics dashboard with token and cost tracking."
+
 ### 3. Write Worker-Ready Tasks
 
 Each plan task must be executable by a Tier 3 worker:
@@ -162,6 +173,6 @@ Focus: {One-sentence scope}
 - Do NOT batch commits - commit per-task
 - Do NOT skip phase verification
 - Do NOT use native `edit` tool - use MCP tools
-- DO NOT SKIP A TEST IN PYTEST JUSTS BECAUSE ITS BROKEN AND HAS NO TRIVIAL SOLUTION OR FIX.
-- DO NOT SIMPLIFY A TEST JUST BECAUSE IT HAS NO TRIVAL SOLUTION TO FIX.
-- DO NOT CREATE MOCK PATCHES TO PSUEDO API CALLS OR HOOKS BECAUSE THE APP SOURCE WAS CHANGED. ADAPT TESTS PROPERLY.
+- DO NOT SKIP A TEST IN PYTEST JUST BECAUSE ITS BROKEN AND HAS NO TRIVIAL SOLUTION OR FIX.
+- DO NOT SIMPLIFY A TEST JUST BECAUSE IT HAS NO TRIVIAL SOLUTION TO FIX.
+- DO NOT CREATE MOCK PATCHES TO PSEUDO API CALLS OR HOOKS BECAUSE THE APP SOURCE WAS CHANGED. ADAPT TESTS PROPERLY.

.opencode/agents/tier2-tech-lead.md

@@ -2,8 +2,7 @@
 description: Tier 2 Tech Lead for architectural design and track execution with persistent memory
 mode: primary
 model: MiniMax-M2.5
-temperature: 0.2
-steps: 100
+temperature: 0.4
 permission:
   edit: ask
   bash: ask
@@ -13,6 +12,12 @@ STRICT SYSTEM DIRECTIVE: You are a Tier 2 Tech Lead.
 Focused on architectural design and track execution.
 ONLY output the requested text. No pleasantries.
 
+## Context Management
+
+**MANUAL COMPACTION ONLY** — Never rely on automatic context summarization.
+Use `/compact` command explicitly when context needs reduction.
+You maintain PERSISTENT MEMORY throughout track execution — do NOT apply Context Amnesia to your own session.
+
 ## CRITICAL: MCP Tools Only (Native Tools Banned)
 
 You MUST use Manual Slop's MCP tools. Native OpenCode tools are unreliable.
@@ -84,6 +89,16 @@ Before ANY other action:
 3. Delegate to Tier 3 via Task tool
 4. Verify result
 
+## Pre-Delegation Checkpoint (MANDATORY)
+
+Before delegating ANY dangerous or non-trivial change to Tier 3:
+
+```powershell
+git add .
+```
+
+**WHY**: If a Tier 3 Worker fails or incorrectly runs `git restore`, you will lose ALL prior AI iterations for that file if it wasn't staged/committed.
+
 ## Architecture Fallback
 
 When implementing tracks that touch core systems, consult the deep-dive docs:
@@ -92,6 +107,7 @@ When implementing tracks that touch core systems, consult the deep-dive docs:
 - `docs/guide_tools.md`: MCP Bridge security, 26-tool inventory, Hook API endpoints
 - `docs/guide_mma.md`: Ticket/Track data structures, DAG engine, ConductorEngine
 - `docs/guide_simulations.md`: live_gui fixture, Puppeteer pattern, mock provider
+- `docs/guide_meta_boundary.md`: Clarification of ai agent tools making the application vs the application itself.
 
 ## Responsibilities
 
@@ -114,16 +130,18 @@ Before implementing:
 
 ### 2. Red Phase: Write Failing Tests
 
-- Pre-delegation checkpoint: Stage current progress (`git add .`)
+- **Pre-delegation checkpoint**: Stage current progress (`git add .`)
 - Zero-assertion ban: Tests MUST have meaningful assertions
 - Delegate test creation to Tier 3 Worker via Task tool
 - Run tests and confirm they FAIL as expected
+- **CONFIRM FAILURE** — this is the Red phase
 
 ### 3. Green Phase: Implement to Pass
 
-- Pre-delegation checkpoint: Stage current progress
+- **Pre-delegation checkpoint**: Stage current progress (`git add .`)
 - Delegate implementation to Tier 3 Worker via Task tool
 - Run tests and confirm they PASS
+- **CONFIRM PASS** — this is the Green phase
 
 ### 4. Refactor Phase (Optional)
 
@@ -134,12 +152,12 @@ Before implementing:
 
 After completing each task:
 
-1. Stage changes: `git add .`
+1. Stage changes: `manual-slop_run_powershell` with `git add .`
 2. Commit with clear message: `feat(scope): description`
 3. Get commit hash: `git log -1 --format="%H"`
 4. Attach git note: `git notes add -m "summary" <hash>`
 5. Update plan.md: Mark task `[x]` with commit SHA
-6. Commit plan update
+6. Commit plan update: `git add plan.md && git commit -m "conductor(plan): Mark task complete"`
 
 ## Delegation via Task Tool
 
@@ -193,6 +211,6 @@ When all tasks in a phase are complete:
 - Do NOT batch commits - commit per-task
 - Do NOT skip phase verification
 - Do NOT use native `edit` tool - use MCP tools
-- DO NOT SKIP A TEST IN PYTEST JUSTS BECAUSE ITS BROKEN AND HAS NO TRIVIAL SOLUTION OR FIX.
-- DO NOT SIMPLIFY A TEST JUST BECAUSE IT HAS NO TRIVAL SOLUTION TO FIX.
-- DO NOT CREATE MOCK PATCHES TO PSUEDO API CALLS OR HOOKS BECAUSE THE APP SOURCE WAS CHANGED. ADAPT TESTS PROPERLY.
+- DO NOT SKIP A TEST IN PYTEST JUST BECAUSE ITS BROKEN AND HAS NO TRIVIAL SOLUTION OR FIX.
+- DO NOT SIMPLIFY A TEST JUST BECAUSE IT HAS NO TRIVIAL SOLUTION TO FIX.
+- DO NOT CREATE MOCK PATCHES TO PSEUDO API CALLS OR HOOKS BECAUSE THE APP SOURCE WAS CHANGED. ADAPT TESTS PROPERLY.

.opencode/agents/tier3-worker.md

@@ -2,8 +2,7 @@
 description: Stateless Tier 3 Worker for surgical code implementation and TDD
 mode: subagent
 model: MiniMax-M2.5
-temperature: 0.1
-steps: 20
+temperature: 0.3
 permission:
   edit: allow
   bash: allow
@@ -13,11 +12,17 @@ STRICT SYSTEM DIRECTIVE: You are a stateless Tier 3 Worker (Contributor).
 Your goal is to implement specific code changes or tests based on the provided task.
 Follow TDD and return success status or code changes. No pleasantries, no conversational filler.
 
+## Context Amnesia
+
+You operate statelessly. Each task starts fresh with only the context provided.
+Do not assume knowledge from previous tasks or sessions.
+
 ## CRITICAL: MCP Tools Only (Native Tools Banned)
 
 You MUST use Manual Slop's MCP tools. Native OpenCode tools are unreliable.
 
 ### Read MCP Tools (USE THESE)
+
 | Native Tool | MCP Tool |
 |-------------|----------|
 | `read` | `manual-slop_read_file` |
@@ -30,6 +35,7 @@ You MUST use Manual Slop's MCP tools. Native OpenCode tools are unreliable.
 | - | `manual-slop_get_file_slice` (read specific line range) |
 
 ### Edit MCP Tools (USE THESE - BAN NATIVE EDIT)
+
 | Native Tool | MCP Tool |
 |-------------|----------|
 | `edit` | `manual-slop_edit_file` (find/replace, preserves indentation) |
@@ -39,17 +45,15 @@ You MUST use Manual Slop's MCP tools. Native OpenCode tools are unreliable.
 | `edit` | `manual-slop_py_set_var_declaration` (replace variable) |
 
 ### Shell Commands
+
 | Native Tool | MCP Tool |
 |-------------|----------|
 | `bash` | `manual-slop_run_powershell` |
 
-## Context Amnesia
-You operate statelessly. Each task starts fresh with only the context provided.
-Do not assume knowledge from previous tasks or sessions.
-
 ## Task Start Checklist (MANDATORY)
 
 Before implementing:
+
 1. [ ] Read task prompt - identify WHERE/WHAT/HOW/SAFETY
 2. [ ] Use skeleton tools for files >50 lines (`manual-slop_py_get_skeleton`, `manual-slop_get_file_summary`)
 3. [ ] Verify target file and line range exists
@@ -58,19 +62,24 @@ Before implementing:
 ## Task Execution Protocol
 
 ### 1. Understand the Task
+
 Read the task prompt carefully. It specifies:
+
 - **WHERE**: Exact file and line range to modify
 - **WHAT**: The specific change required
 - **HOW**: Which API calls, patterns, or data structures to use
 - **SAFETY**: Thread-safety constraints if applicable
 
 ### 2. Research (If Needed)
+
 Use MCP tools to understand the context:
+
 - `manual-slop_read_file` - Read specific file sections
 - `manual-slop_py_find_usages` - Search for patterns
 - `manual-slop_search_files` - Find files by pattern
 
 ### 3. Implement
+
 - Follow the exact specifications provided
 - Use the patterns and APIs specified in the task
 - Use 1-space indentation for Python code
@@ -78,31 +87,39 @@ Use MCP tools to understand the context:
 - Use type hints where appropriate
 
 ### 4. Verify
+
 - Run tests if specified: `manual-slop_run_powershell` with `uv run pytest ...`
 - Check for syntax errors: `manual-slop_py_check_syntax`
 - Verify the change matches the specification
 
 ### 5. Report
+
 Return a concise summary:
+
 - What was changed
 - Where it was changed
 - Any issues encountered
 
 ## Code Style Requirements
+
 - **NO COMMENTS** unless explicitly requested
 - 1-space indentation for Python code
 - Type hints where appropriate
 - Internal methods/variables prefixed with underscore
 
 ## Quality Checklist
+
 Before reporting completion:
+
 - [ ] Change matches the specification exactly
 - [ ] No unintended modifications
 - [ ] No syntax errors
 - [ ] Tests pass (if applicable)
 
 ## Blocking Protocol
+
 If you cannot complete the task:
+
 1. Start your response with `BLOCKED:`
 2. Explain exactly why you cannot proceed
 3. List what information or changes would unblock you
@@ -110,11 +127,10 @@ If you cannot complete the task:
 
 ## Anti-Patterns (Avoid)
 
-- Do NOT implement code directly - delegate to Tier 3 Workers
-- Do NOT skip TDD phases
-- Do NOT batch commits - commit per-task
-- Do NOT skip phase verification
 - Do NOT use native `edit` tool - use MCP tools
-- DO NOT SKIP A TEST IN PYTEST JUSTS BECAUSE ITS BROKEN AND HAS NO TRIVIAL SOLUTION OR FIX.
-- DO NOT SIMPLIFY A TEST JUST BECAUSE IT HAS NO TRIVAL SOLUTION TO FIX.
-- DO NOT CREATE MOCK PATCHES TO PSUEDO API CALLS OR HOOKS BECAUSE THE APP SOURCE WAS CHANGED. ADAPT TESTS PROPERLY.
+- Do NOT read full large files - use skeleton tools first
+- Do NOT add comments unless requested
+- Do NOT modify files outside the specified scope
+- DO NOT SKIP A TEST IN PYTEST JUST BECAUSE ITS BROKEN AND HAS NO TRIVIAL SOLUTION OR FIX.
+- DO NOT SIMPLIFY A TEST JUST BECAUSE IT HAS NO TRIVIAL SOLUTION TO FIX.
+- DO NOT CREATE MOCK PATCHES TO PSEUDO API CALLS OR HOOKS BECAUSE THE APP SOURCE WAS CHANGED. ADAPT TESTS PROPERLY.

.opencode/agents/tier4-qa.md

@@ -2,8 +2,7 @@
 description: Stateless Tier 4 QA Agent for error analysis and diagnostics
 mode: subagent
 model: MiniMax-M2.5
-temperature: 0.0
-steps: 5
+temperature: 0.2
 permission:
   edit: deny
   bash:
@@ -17,11 +16,17 @@ STRICT SYSTEM DIRECTIVE: You are a stateless Tier 4 QA Agent.
 Your goal is to analyze errors, summarize logs, or verify tests.
 ONLY output the requested analysis. No pleasantries.
 
+## Context Amnesia
+
+You operate statelessly. Each analysis starts fresh.
+Do not assume knowledge from previous analyses or sessions.
+
 ## CRITICAL: MCP Tools Only (Native Tools Banned)
 
 You MUST use Manual Slop's MCP tools. Native OpenCode tools are unreliable.
 
 ### Read-Only MCP Tools (USE THESE)
+
 | Native Tool | MCP Tool |
 |-------------|----------|
 | `read` | `manual-slop_read_file` |
@@ -35,17 +40,15 @@ You MUST use Manual Slop's MCP tools. Native OpenCode tools are unreliable.
 | - | `manual-slop_get_file_slice` (read specific line range) |
 
 ### Shell Commands
+
 | Native Tool | MCP Tool |
 |-------------|----------|
 | `bash` | `manual-slop_run_powershell` |
 
-## Context Amnesia
-You operate statelessly. Each analysis starts fresh.
-Do not assume knowledge from previous analyses or sessions.
-
 ## Analysis Start Checklist (MANDATORY)
 
 Before analyzing:
+
 1. [ ] Read error output/test failure completely
 2. [ ] Identify affected files from traceback
 3. [ ] Use skeleton tools for files >50 lines (`manual-slop_py_get_skeleton`)
@@ -54,16 +57,20 @@ Before analyzing:
 ## Analysis Protocol
 
 ### 1. Understand the Error
+
 Read the provided error output, test failure, or log carefully.
 
 ### 2. Investigate
+
 Use MCP tools to understand the context:
+
 - `manual-slop_read_file` - Read relevant source files
 - `manual-slop_py_find_usages` - Search for related patterns
 - `manual-slop_search_files` - Find related files
 - `manual-slop_get_git_diff` - Check recent changes
 
 ### 3. Root Cause Analysis
+
 Provide a structured analysis:
 
 ```
@@ -86,28 +93,30 @@ Provide a structured analysis:
 ```
 
 ## Limitations
+
 - **READ-ONLY**: Do NOT modify any files
 - **ANALYSIS ONLY**: Do NOT implement fixes
 - **NO ASSUMPTIONS**: Base analysis only on provided context and tool output
 
 ## Quality Checklist
+
 - [ ] Analysis is based on actual code/file content
 - [ ] Root cause is specific, not generic
 - [ ] Evidence includes file:line references
 - [ ] Recommendations are actionable but not implemented
 
 ## Blocking Protocol
+
 If you cannot analyze the error:
+
 1. Start your response with `CANNOT ANALYZE:`
 2. Explain what information is missing
 3. List what would be needed to complete the analysis
 
 ## Anti-Patterns (Avoid)
 
-- Do NOT implement code directly - delegate to Tier 3 Workers
-- Do NOT skip TDD phases
-- Do NOT batch commits - commit per-task
-- Do NOT skip phase verification
-- DO NOT SKIP A TEST IN PYTEST JUSTS BECAUSE ITS BROKEN AND HAS NO TRIVIAL SOLUTION OR FIX.
-- DO NOT SIMPLIFY A TEST JUST BECAUSE IT HAS NO TRIVAL SOLUTION TO FIX.
-- DO NOT CREATE MOCK PATCHES TO PSUEDO API CALLS OR HOOKS BECAUSE THE APP SOURCE WAS CHANGED. ADAPT TESTS PROPERLY.
+- Do NOT implement fixes - analysis only
+- Do NOT read full large files - use skeleton tools first
+- DO NOT SKIP A TEST IN PYTEST JUST BECAUSE ITS BROKEN AND HAS NO TRIVIAL SOLUTION OR FIX.
+- DO NOT SIMPLIFY A TEST JUST BECAUSE IT HAS NO TRIVIAL SOLUTION TO FIX.
+- DO NOT CREATE MOCK PATCHES TO PSEUDO API CALLS OR HOOKS BECAUSE THE APP SOURCE WAS CHANGED. ADAPT TESTS PROPERLY.

.opencode/commands/conductor-setup.md

@@ -24,7 +24,7 @@ Bootstrap the session with full conductor context. Run this at session start.
    - Identify the track with `[~]` in-progress tasks
 
 3. **Check Session Context:**
-   - Read `TASKS.md` if it exists — check for IN_PROGRESS or BLOCKED tasks
+   - Read `conductor/tracks.md` if it exists — check for IN_PROGRESS or BLOCKED tasks
    - Read last 3 entries in `JOURNAL.md` for recent activity
    - Run `git log --oneline -10` for recent commits
 

.opencode/commands/conductor-status.md

@@ -20,7 +20,7 @@ Display comprehensive status of the conductor system.
    - Read `plan.md` for task progress
    - Count completed vs total tasks
 
-3. **Check TASKS.md:**
+3. **Check conductor/tracks.md:**
    - List IN_PROGRESS tasks
    - List BLOCKED tasks
    - List pending tasks by priority
@@ -38,7 +38,7 @@ Display comprehensive status of the conductor system.
    |-------|--------|----------|--------------|
    | ... | ... | N/M tasks | ... |
 
-   ### Task Registry (TASKS.md)
+   ### Task Registry (conductor/tracks.md)
    **In Progress:**
    - [ ] Task description
 

.opencode/commands/mma-tier1-orchestrator.md

@@ -1,11 +1,33 @@
 ---
-description: Invoke Tier 1 Orchestrator for product alignment and track initialization
+description: Invoke Tier 1 Orchestrator for product alignment, high-level planning, and track initialization
 agent: tier1-orchestrator
-subtask: true
 ---
 
 $ARGUMENTS
 
 ---
 
-Invoke the Tier 1 Orchestrator with the above context. Focus on product alignment, high-level planning, and track initialization. Follow the Surgical Methodology: audit existing code before specifying, identify gaps not features, and write worker-ready tasks.
+## Context
+
+You are now acting as Tier 1 Orchestrator.
+
+### Primary Responsibilities
+- Product alignment and strategic planning
+- Track initialization (`/conductor-new-track`)
+- Session setup (`/conductor-setup`)
+- Delegate execution to Tier 2 Tech Lead
+
+### The Surgical Methodology (MANDATORY)
+
+1. **AUDIT BEFORE SPECIFYING**: Never write a spec without first reading actual code using MCP tools. Document existing implementations with file:line references.
+
+2. **IDENTIFY GAPS, NOT FEATURES**: Frame requirements around what's MISSING.
+
+3. **WRITE WORKER-READY TASKS**: Each task must specify WHERE/WHAT/HOW/SAFETY.
+
+4. **REFERENCE ARCHITECTURE DOCS**: Link to `docs/guide_*.md` sections.
+
+### Limitations
+- READ-ONLY: Do NOT write code or edit files (except track spec/plan/metadata)
+- Do NOT execute tracks — delegate to Tier 2
+- Do NOT implement features — delegate to Tier 3 Workers

.opencode/commands/mma-tier2-tech-lead.md

@@ -7,4 +7,67 @@ $ARGUMENTS
 
 ---
 
-Invoke the Tier 2 Tech Lead with the above context. Follow TDD protocol (Red -> Green -> Refactor), delegate implementation to Tier 3 Workers, and maintain persistent memory throughout track execution. Commit atomically per-task.
+## Context
+
+You are now acting as Tier 2 Tech Lead.
+
+### Primary Responsibilities
+- Track execution (`/conductor-implement`)
+- Architectural oversight
+- Delegate to Tier 3 Workers via Task tool
+- Delegate error analysis to Tier 4 QA via Task tool
+- Maintain persistent memory throughout track execution
+
+### Context Management
+
+**MANUAL COMPACTION ONLY** — Never rely on automatic context summarization.
+You maintain PERSISTENT MEMORY throughout track execution — do NOT apply Context Amnesia to your own session.
+
+### Pre-Delegation Checkpoint (MANDATORY)
+
+Before delegating ANY dangerous or non-trivial change to Tier 3:
+
+```
+git add .
+```
+
+**WHY**: If a Tier 3 Worker fails or incorrectly runs `git restore`, you will lose ALL prior AI iterations for that file if it wasn't staged/committed.
+
+### TDD Protocol (MANDATORY)
+
+1. **Red Phase**: Write failing tests first — CONFIRM FAILURE
+2. **Green Phase**: Implement to pass — CONFIRM PASS
+3. **Refactor Phase**: Optional, with passing tests
+
+### Commit Protocol (ATOMIC PER-TASK)
+
+After completing each task:
+1. Stage: `git add .`
+2. Commit: `feat(scope): description`
+3. Get hash: `git log -1 --format="%H"`
+4. Attach note: `git notes add -m "summary" <hash>`
+5. Update plan.md: Mark `[x]` with SHA
+6. Commit plan update: `git add plan.md && git commit -m "conductor(plan): Mark task complete"`
+
+### Delegation Pattern
+
+**Tier 3 Worker** (Task tool):
+```
+subagent_type: "tier3-worker"
+description: "Brief task name"
+prompt: |
+ WHERE: file.py:line-range
+ WHAT: specific change
+ HOW: API calls/patterns
+ SAFETY: thread constraints
+ Use 1-space indentation.
+```
+
+**Tier 4 QA** (Task tool):
+```
+subagent_type: "tier4-qa"
+description: "Analyze failure"
+prompt: |
+ [Error output]
+ DO NOT fix - provide root cause analysis only.
+```

.opencode/commands/mma-tier3-worker.md

@@ -7,4 +7,49 @@ $ARGUMENTS
 
 ---
 
-Invoke the Tier 3 Worker with the above task. Operate statelessly with context amnesia. Implement the specified change exactly as described. Use 1-space indentation for Python code. Do NOT add comments unless requested.
+## Context
+
+You are now acting as Tier 3 Worker.
+
+### Key Constraints
+
+- **STATELESS**: Context Amnesia — each task starts fresh
+- **MCP TOOLS ONLY**: Use `manual-slop_*` tools, NEVER native tools
+- **SURGICAL**: Follow WHERE/WHAT/HOW/SAFETY exactly
+- **1-SPACE INDENTATION**: For all Python code
+
+### Task Execution Protocol
+
+1. **Read Task Prompt**: Identify WHERE/WHAT/HOW/SAFETY
+2. **Use Skeleton Tools**: For files >50 lines, use `manual-slop_py_get_skeleton` or `manual-slop_get_file_summary`
+3. **Implement Exactly**: Follow specifications precisely
+4. **Verify**: Run tests if specified via `manual-slop_run_powershell`
+5. **Report**: Return concise summary (what, where, issues)
+
+### Edit MCP Tools (USE THESE - BAN NATIVE EDIT)
+
+| Native Tool | MCP Tool |
+|-------------|----------|
+| `edit` | `manual-slop_edit_file` (find/replace, preserves indentation) |
+| `edit` | `manual-slop_py_update_definition` (replace function/class) |
+| `edit` | `manual-slop_set_file_slice` (replace line range) |
+| `edit` | `manual-slop_py_set_signature` (replace signature only) |
+| `edit` | `manual-slop_py_set_var_declaration` (replace variable) |
+
+**CRITICAL**: The native `edit` tool DESTROYS 1-space indentation. ALWAYS use MCP tools.
+
+### Blocking Protocol
+
+If you cannot complete the task:
+
+1. Start response with `BLOCKED:`
+2. Explain exactly why you cannot proceed
+3. List what information or changes would unblock you
+4. Do NOT attempt partial implementations that break the build
+
+### Code Style (Python)
+
+- 1-space indentation
+- NO COMMENTS unless explicitly requested
+- Type hints where appropriate
+- Internal methods/variables prefixed with underscore

.opencode/commands/mma-tier4-qa.md

@@ -1,5 +1,5 @@
 ---
-description: Invoke Tier 4 QA for error analysis and diagnostics
+description: Invoke Tier 4 QA Agent for error analysis
 agent: tier4-qa
 ---
 
@@ -7,4 +7,69 @@ $ARGUMENTS
 
 ---
 
-Invoke the Tier 4 QA Agent with the above context. Analyze errors, summarize logs, or verify tests. Provide root cause analysis with file:line evidence. DO NOT implement fixes - analysis only.
+## Context
+
+You are now acting as Tier 4 QA Agent.
+
+### Key Constraints
+
+- **STATELESS**: Context Amnesia — each analysis starts fresh
+- **READ-ONLY**: Do NOT modify any files
+- **ANALYSIS ONLY**: Do NOT implement fixes
+
+### Read-Only MCP Tools (USE THESE)
+
+| Native Tool | MCP Tool |
+|-------------|----------|
+| `read` | `manual-slop_read_file` |
+| `glob` | `manual-slop_search_files` or `manual-slop_list_directory` |
+| `grep` | `manual-slop_py_find_usages` |
+| - | `manual-slop_get_file_summary` (heuristic summary) |
+| - | `manual-slop_py_get_code_outline` (classes/functions with line ranges) |
+| - | `manual-slop_py_get_skeleton` (signatures + docstrings only) |
+| - | `manual-slop_py_get_definition` (specific function/class source) |
+| - | `manual-slop_get_git_diff` (file changes) |
+| - | `manual-slop_get_file_slice` (read specific line range) |
+
+### Analysis Protocol
+
+1. **Read Error Completely**: Understand the full error/test failure
+2. **Identify Affected Files**: Parse traceback for file:line references
+3. **Use Skeleton Tools**: For files >50 lines, use `manual-slop_py_get_skeleton` first
+4. **Announce**: "Analyzing: [error summary]"
+
+### Structured Output Format
+
+```
+## Error Analysis
+
+### Summary
+[One-sentence description of the error]
+
+### Root Cause
+[Detailed explanation of why the error occurred]
+
+### Evidence
+[File:line references supporting the analysis]
+
+### Impact
+[What functionality is affected]
+
+### Recommendations
+[Suggested fixes or next steps - but DO NOT implement them]
+```
+
+### Quality Checklist
+
+- [ ] Analysis based on actual code/file content
+- [ ] Root cause is specific, not generic
+- [ ] Evidence includes file:line references
+- [ ] Recommendations are actionable but not implemented
+
+### Blocking Protocol
+
+If you cannot analyze the error:
+
+1. Start response with `CANNOT ANALYZE:`
+2. Explain what information is missing
+3. List what would be needed to complete the analysis

AGENTS.md

@@ -1,5 +1,9 @@
 # Manual Slop - OpenCode Configuration
 
+## MCP TOOL PARAMETERS - CRITICAL
+- **ALWAYS use snake_case**: `old_string`, `new_string`, `replace_all`
+- **NEVER use camelCase**: `oldString`, `newString`, `replaceAll`
+
 ## Project Overview
 
 **Manual Slop** is a local GUI application designed as an experimental, "manual" AI coding assistant. It allows users to curate and send context (files, screenshots, and discussion history) to AI APIs (Gemini and Anthropic). The AI can then execute PowerShell scripts within the project directory to modify files, requiring explicit user confirmation before execution.
@@ -78,7 +82,7 @@ When uncertain about threading, event flow, data structures, or module interacti
 ## Development Workflow
 
 1. Run `/conductor-setup` to load session context
-2. Pick active track from `TASKS.md` or `/conductor-status`
+2. Pick active track from `./condcutor/tracks.md` or `/conductor-status`
 3. Run `/conductor-implement` to resume track execution
 4. Follow TDD: Red (failing tests) -> Green (pass) -> Refactor
 5. Delegate implementation to Tier 3 Workers, errors to Tier 4 QA

CLAUDE.md

@@ -3,6 +3,10 @@
 
 This file provides guidance to Claude Code when working with this repository.
 
+## MCP TOOL PARAMETERS - CRITICAL
+- **ALWAYS use snake_case**: `old_string`, `new_string`, `replace_all`
+- **NEVER use camelCase**: `oldString`, `newString`, `replaceAll`
+
 ## Critical Context (Read First)
 - **Tech Stack**: Python 3.11+, Dear PyGui / ImGui, FastAPI, Uvicorn
 - **Main File**: `gui_2.py` (primary GUI), `ai_client.py` (multi-provider LLM abstraction)
@@ -80,7 +84,7 @@ uv run python scripts\claude_mma_exec.py --role tier4-qa "Error analysis prompt"
 
 ## Development Workflow
 1. Run `/conductor-setup` to load session context
-2. Pick active track from `TASKS.md` or `/conductor-status`
+2. Pick active track from `conductor/tracks.md` or `/conductor-status`
 3. Run `/conductor-implement` to resume track execution
 4. Follow TDD: Red (failing tests) → Green (pass) → Refactor
 5. Delegate implementation to Tier 3 Workers, errors to Tier 4 QA
@@ -112,7 +116,7 @@ Update JOURNAL.md after:
 Format: What/Why/How/Issues/Result structure
 
 ## Task Management Integration
-- **TASKS.md**: Quick-read pointer to active conductor tracks
+- **conductor/tracks.md**: Quick-read pointer to active conductor tracks
 - **conductor/tracks/*/plan.md**: Detailed task state (source of truth)
 - **JOURNAL.md**: Completed work history with `|TASK:ID|` tags
 - **ERRORS.md**: P0/P1 error tracking

CONDUCTOR.md

@@ -1,511 +0,0 @@
-# CONDUCTOR.md
-<!-- Generated by Claude Conductor v2.0.0 -->
-
-> _Read me first. Every other doc is linked below._
-
-## Critical Context (Read First)
-- **Tech Stack**: [List core technologies]
-- **Main File**: [Primary code file and line count]
-- **Core Mechanic**: [One-line description]
-- **Key Integration**: [Important external services]
-- **Platform Support**: [Deployment targets]
-- **DO NOT**: [Critical things to avoid]
-
-## Table of Contents
-1. [Architecture](ARCHITECTURE.md) - Tech stack, folder structure, infrastructure
-2. [Design Tokens](DESIGN.md) - Colors, typography, visual system
-3. [UI/UX Patterns](UIUX.md) - Components, interactions, accessibility
-4. [Runtime Config](CONFIG.md) - Environment variables, feature flags
-5. [Data Model](DATA_MODEL.md) - Database schema, entities, relationships
-6. [API Contracts](API.md) - Endpoints, request/response formats, auth
-7. [Build & Release](BUILD.md) - Build process, deployment, CI/CD
-8. [Testing Guide](TEST.md) - Test strategies, E2E scenarios, coverage
-9. [Operational Playbooks](PLAYBOOKS/DEPLOY.md) - Deployment, rollback, monitoring
-10. [Contributing](CONTRIBUTING.md) - Code style, PR process, conventions
-11. [Error Ledger](ERRORS.md) - Critical P0/P1 error tracking
-12. [Task Management](TASKS.md) - Active tasks, phase tracking, context preservation
-
-## Quick Reference
-**Main Constants**: `[file:lines]` - Description  
-**Core Class**: `[file:lines]` - Description  
-**Key Function**: `[file:lines]` - Description  
-[Include 10-15 most accessed code locations]
-
-## Current State
-- [x] Feature complete
-- [ ] Feature in progress
-- [ ] Feature planned
-[Track active work]
-
-## Development Workflow
-[5-6 steps for common workflow]
-
-## Task Templates
-### 1. [Common Task Name]
-1. Step with file:line reference
-2. Step with specific action
-3. Test step
-4. Documentation update
-
-[Include 3-5 templates]
-
-## Anti-Patterns (Avoid These)
-❌ **Don't [action]** - [Reason]  
-[List 5-6 critical mistakes]
-
-## Version History
-- **v1.0.0** - Initial release
-- **v1.1.0** - Feature added (see JOURNAL.md YYYY-MM-DD)  
-[Link major versions to journal entries]
-
-## Continuous Engineering Journal <!-- do not remove -->
-
-Claude, keep an ever-growing changelog in [`JOURNAL.md`](JOURNAL.md).
-
-### What to Journal
-- **Major changes**: New features, significant refactors, API changes
-- **Bug fixes**: What broke, why, and how it was fixed
-- **Frustration points**: Problems that took multiple attempts to solve
-- **Design decisions**: Why we chose one approach over another
-- **Performance improvements**: Before/after metrics
-- **User feedback**: Notable issues or requests
-- **Learning moments**: New techniques or patterns discovered
-
-### Journal Format
-\```
-## YYYY-MM-DD HH:MM
-
-### [Short Title]
-- **What**: Brief description of the change
-- **Why**: Reason for the change
-- **How**: Technical approach taken
-- **Issues**: Any problems encountered
-- **Result**: Outcome and any metrics
-
-### [Short Title] |ERROR:ERR-YYYY-MM-DD-001|
-- **What**: Critical P0/P1 error description
-- **Why**: Root cause analysis
-- **How**: Fix implementation
-- **Issues**: Debugging challenges
-- **Result**: Resolution and prevention measures
-
-### [Task Title] |TASK:TASK-YYYY-MM-DD-001|
-- **What**: Task implementation summary
-- **Why**: Part of [Phase Name] phase
-- **How**: Technical approach and key decisions
-- **Issues**: Blockers encountered and resolved
-- **Result**: Task completed, findings documented in ARCHITECTURE.md
-\```
-
-### Compaction Rule
-When `JOURNAL.md` exceeds **500 lines**:
-1. Claude summarizes the oldest half into `JOURNAL_ARCHIVE/<year>-<month>.md`
-2. Remaining entries stay in `JOURNAL.md` so the file never grows unbounded
-
-> ⚠️ Claude must NEVER delete raw history—only move & summarize.
-
-### 2. ARCHITECTURE.md
-**Purpose**: System design, tech stack decisions, and code structure with line numbers.
-
-**Required Elements**:
-- Technology stack listing
-- Directory structure diagram
-- Key architectural decisions with rationale
-- Component architecture with exact line numbers
-- System flow diagram (ASCII art)
-- Common patterns section
-- Keywords for search optimization
-
-**Line Number Format**:
-\```
-#### ComponentName Structure <!-- #component-anchor -->
-\```typescript
-// Major classes with exact line numbers
-class MainClass { /* lines 100-500 */ }    // <!-- #main-class -->
-class Helper { /* lines 501-600 */ }       // <!-- #helper-class -->
-\```
-\```
-
-### 3. DESIGN.md
-**Purpose**: Visual design system, styling, and theming documentation.
-
-**Required Sections**:
-- Typography system
-- Color palette (with hex values)
-- Visual effects specifications
-- Character/entity design
-- UI/UX component styling
-- Animation system
-- Mobile design considerations
-- Accessibility guidelines
-- Keywords section
-
-### 4. DATA_MODEL.md
-**Purpose**: Database schema, application models, and data structures.
-
-**Required Elements**:
-- Database schema (SQL)
-- Application data models (TypeScript/language interfaces)
-- Validation rules
-- Common queries
-- Data migration history
-- Keywords for entities
-
-### 5. API.md
-**Purpose**: Complete API documentation with examples.
-
-**Structure for Each Endpoint**:
-\```
-### Endpoint Name
-
-\```http
-METHOD /api/endpoint
-\```
-
-#### Request
-\```json
-{
-  "field": "type"
-}
-\```
-
-#### Response
-\```json
-{
-  "field": "value"
-}
-\```
-
-#### Details
-- **Rate limit**: X requests per Y seconds
-- **Auth**: Required/Optional
-- **Notes**: Special considerations
-\```
-
-### 6. CONFIG.md
-**Purpose**: Runtime configuration, environment variables, and settings.
-
-**Required Sections**:
-- Environment variables (required and optional)
-- Application configuration constants
-- Feature flags
-- Performance tuning settings
-- Security configuration
-- Common patterns for configuration changes
-
-### 7. BUILD.md
-**Purpose**: Build process, deployment, and CI/CD documentation.
-
-**Include**:
-- Prerequisites
-- Build commands
-- CI/CD pipeline configuration
-- Deployment steps
-- Rollback procedures
-- Troubleshooting guide
-
-### 8. TEST.md
-**Purpose**: Testing strategies, patterns, and examples.
-
-**Sections**:
-- Test stack and tools
-- Running tests commands
-- Test structure
-- Coverage goals
-- Common test patterns
-- Debugging tests
-
-### 9. UIUX.md
-**Purpose**: Interaction patterns, user flows, and behavior specifications.
-
-**Cover**:
-- Input methods
-- State transitions
-- Component behaviors
-- User flows
-- Accessibility patterns
-- Performance considerations
-
-### 10. CONTRIBUTING.md
-**Purpose**: Guidelines for contributors.
-
-**Include**:
-- Code of conduct
-- Development setup
-- Code style guide
-- Commit message format
-- PR process
-- Common patterns
-
-### 11. PLAYBOOKS/DEPLOY.md
-**Purpose**: Step-by-step operational procedures.
-
-**Format**:
-- Pre-deployment checklist
-- Deployment steps (multiple options)
-- Post-deployment verification
-- Rollback procedures
-- Troubleshooting
-
-### 12. ERRORS.md (Critical Error Ledger)
-**Purpose**: Track and resolve P0/P1 critical errors with full traceability.
-
-**Required Structure**:
-\```
-# Critical Error Ledger <!-- auto-maintained -->
-
-## Schema
-| ID | First seen | Status | Severity | Affected area | Link to fix |
-|----|------------|--------|----------|---------------|-------------|
-
-## Active Errors
-[New errors added here, newest first]
-
-## Resolved Errors
-[Moved here when fixed, with links to fixes]
-\```
-
-**Error ID Format**: `ERR-YYYY-MM-DD-001` (increment for multiple per day)
-
-**Severity Definitions**:
-- **P0**: Complete outage, data loss, security breach
-- **P1**: Major functionality broken, significant performance degradation
-- **P2**: Minor functionality (not tracked in ERRORS.md)
-- **P3**: Cosmetic issues (not tracked in ERRORS.md)
-
-**Claude's Error Logging Process**:
-1. When P0/P1 error occurs, immediately add to Active Errors
-2. Create corresponding JOURNAL.md entry with details
-3. When resolved:
-   - Move to Resolved Errors section
-   - Update status to "resolved"
-   - Add commit hash and PR link
-   - Add `|ERROR:<ID>|` tag to JOURNAL.md entry
-   - Link back to JOURNAL entry from ERRORS.md
-
-### 13. TASKS.md (Active Task Management)
-**Purpose**: Track ongoing work with phase awareness and context preservation between sessions.
-
-**IMPORTANT**: TASKS.md complements Claude's built-in todo system - it does NOT replace it:
-- Claude's todos: For immediate task tracking within a session
-- TASKS.md: For preserving context and state between sessions
-
-**Required Structure**:
-```
-# Task Management
-
-## Active Phase
-**Phase**: [High-level project phase name]
-**Started**: YYYY-MM-DD
-**Target**: YYYY-MM-DD
-**Progress**: X/Y tasks completed
-
-## Current Task
-**Task ID**: TASK-YYYY-MM-DD-NNN
-**Title**: [Descriptive task name]
-**Status**: PLANNING | IN_PROGRESS | BLOCKED | TESTING | COMPLETE
-**Started**: YYYY-MM-DD HH:MM
-**Dependencies**: [List task IDs this depends on]
-
-### Task Context
-<!-- Critical information needed to resume this task -->
-- **Previous Work**: [Link to related tasks/PRs]
-- **Key Files**: [Primary files being modified with line ranges]
-- **Environment**: [Specific config/versions if relevant]
-- **Next Steps**: [Immediate actions when resuming]
-
-### Findings & Decisions
-- **FINDING-001**: [Discovery that affects approach]
-- **DECISION-001**: [Technical choice made] → Link to ARCHITECTURE.md
-- **BLOCKER-001**: [Issue preventing progress] → Link to resolution
-
-### Task Chain
-1. ✅ [Completed prerequisite task] (TASK-YYYY-MM-DD-001)
-2. 🔄 [Current task] (CURRENT)
-3. ⏳ [Next planned task]
-4. ⏳ [Future task in phase]
-```
-
-**Task Management Rules**:
-1. **One Active Task**: Only one task should be IN_PROGRESS at a time
-2. **Context Capture**: Before switching tasks, capture all context needed to resume
-3. **Findings Documentation**: Record unexpected discoveries that impact the approach
-4. **Decision Linking**: Link architectural decisions to ARCHITECTURE.md
-5. **Completion Trigger**: When task completes:
-   - Generate JOURNAL.md entry with task summary
-   - Archive task details to TASKS_ARCHIVE/YYYY-MM/TASK-ID.md
-   - Load next task from chain or prompt for new phase
-
-**Task States**:
-- **PLANNING**: Defining approach and breaking down work
-- **IN_PROGRESS**: Actively working on implementation
-- **BLOCKED**: Waiting on external dependency or decision
-- **TESTING**: Implementation complete, validating functionality
-- **COMPLETE**: Task finished and documented
-
-**Integration with Journal**:
-- Each completed task auto-generates a journal entry
-- Journal references task ID for full context
-- Critical findings promoted to relevant documentation
-
-## Documentation Optimization Rules
-
-### 1. Line Number Anchors
-- Add exact line numbers for every class, function, and major code section
-- Format: `**Class Name (Lines 100-200)**`
-- Add HTML anchors: `<!-- #class-name -->`
-- Update when code structure changes significantly
-
-### 2. Quick Reference Card
-- Place in CLAUDE.md after Table of Contents
-- Include 10-15 most common code locations
-- Format: `**Feature**: `file:lines` - Description`
-
-### 3. Current State Tracking
-- Use checkbox format in CLAUDE.md
-- `- [x] Completed feature`
-- `- [ ] In-progress feature`
-- Update after each work session
-
-### 4. Task Templates
-- Provide 3-5 step-by-step workflows
-- Include specific line numbers
-- Reference files that need updating
-- Add test/verification steps
-
-### 5. Keywords Sections
-- Add to each major .md file
-- List alternative search terms
-- Format: `## Keywords <!-- #keywords -->`
-- Include synonyms and related terms
-
-### 6. Anti-Patterns
-- Use ❌ emoji for clarity
-- Explain why each is problematic
-- Include 5-6 critical mistakes
-- Place prominently in CLAUDE.md
-
-### 7. System Flow Diagrams
-- Use ASCII art for simplicity
-- Show data/control flow
-- Keep visual and readable
-- Place in ARCHITECTURE.md
-
-### 8. Common Patterns
-- Add to relevant docs (CONFIG.md, ARCHITECTURE.md)
-- Show exact code changes needed
-- Include before/after examples
-- Reference specific functions
-
-### 9. Version History
-- Link to JOURNAL.md entries
-- Format: `v1.0.0 - Feature (see JOURNAL.md YYYY-MM-DD)`
-- Track major changes only
-
-### 10. Cross-Linking
-- Link between related sections
-- Use relative paths: `[Link](./FILE.md#section)`
-- Ensure bidirectional linking where appropriate
-
-## Journal System Setup
-
-### JOURNAL.md Structure
-\```
-# Engineering Journal
-
-## YYYY-MM-DD HH:MM
-
-### [Descriptive Title]
-- **What**: Brief description of the change
-- **Why**: Reason for the change
-- **How**: Technical approach taken
-- **Issues**: Any problems encountered
-- **Result**: Outcome and any metrics
-
----
-
-[Entries continue chronologically]
-\```
-
-### Journal Best Practices
-1. **Entry Timing**: Add entry immediately after significant work
-2. **Detail Level**: Include enough detail to understand the change months later
-3. **Problem Documentation**: Especially document multi-attempt solutions
-4. **Learning Moments**: Capture new techniques discovered
-5. **Metrics**: Include performance improvements, time saved, etc.
-
-### Archive Process
-When JOURNAL.md exceeds 500 lines:
-1. Create `JOURNAL_ARCHIVE/` directory
-2. Move oldest 250 lines to `JOURNAL_ARCHIVE/YYYY-MM.md`
-3. Add summary header to archive file
-4. Keep recent entries in main JOURNAL.md
-
-## Implementation Steps
-
-### Phase 1: Initial Setup (30-60 minutes)
-1. **Create CLAUDE.md** with all required sections
-2. **Fill Critical Context** with 6 essential facts
-3. **Create Table of Contents** with placeholder links
-4. **Add Quick Reference** with top 10-15 code locations
-5. **Set up Journal section** with formatting rules
-
-### Phase 2: Core Documentation (2-4 hours)
-1. **Create each .md file** from the list above
-2. **Add Keywords section** to each file
-3. **Cross-link between files** where relevant
-4. **Add line numbers** to code references
-5. **Create PLAYBOOKS/ directory** with DEPLOY.md
-6. **Create ERRORS.md** with schema table
-
-### Phase 3: Optimization (1-2 hours)
-1. **Add Task Templates** to CLAUDE.md
-2. **Create ASCII system flow** in ARCHITECTURE.md
-3. **Add Common Patterns** sections
-4. **Document Anti-Patterns**
-5. **Set up Version History**
-
-### Phase 4: First Journal Entry
-Create initial JOURNAL.md entry documenting the setup:
-\```
-## YYYY-MM-DD HH:MM
-
-### Documentation Framework Implementation
-- **What**: Implemented CLAUDE.md modular documentation system
-- **Why**: Improve AI navigation and code maintainability
-- **How**: Split monolithic docs into focused modules with cross-linking
-- **Issues**: None - clean implementation
-- **Result**: [Number] documentation files created with full cross-referencing
-\```
-
-## Maintenance Guidelines
-
-### Daily
-- Update JOURNAL.md with significant changes
-- Mark completed items in Current State
-- Update line numbers if major refactoring
-
-### Weekly
-- Review and update Quick Reference section
-- Check for broken cross-links
-- Update Task Templates if workflows change
-
-### Monthly
-- Review Keywords sections for completeness
-- Update Version History
-- Check if JOURNAL.md needs archiving
-
-### Per Release
-- Update Version History in CLAUDE.md
-- Create comprehensive JOURNAL.md entry
-- Review all documentation for accuracy
-- Update Current State checklist
-
-## Benefits of This System
-
-1. **AI Efficiency**: Claude can quickly navigate to exact code locations
-2. **Modularity**: Easy to update specific documentation without affecting others
-3. **Discoverability**: New developers/AI can quickly understand the project
-4. **History Tracking**: Complete record of changes and decisions
-5. **Task Automation**: Templates reduce repetitive instructions
-6. **Error Prevention**: Anti-patterns prevent common mistakes

JOURNAL.md

@@ -26,7 +26,7 @@
 - **What**: Per-agent filtering for MMA observability panels (comms, tool calls, discussion, token budget)
 - **Why**: All panels are global/session-scoped; in MMA mode with 4 tiers, data from all agents mixes. No way to isolate what a specific tier is doing.
 - **Gap**: `_comms_log` and `_tool_log` have no tier/agent tag. `mma_streams` stream_id is the only per-agent key that exists.
-- **See**: TASKS.md for full audit and implementation intent.
+- **See**: conductor/tracks.md for full audit and implementation intent.
 
 ---
 
@@ -42,7 +42,7 @@
 - **More Tracks**: Initialized 'tech_debt_and_test_cleanup_20260302' and 'conductor_workflow_improvements_20260302' to harden TDD discipline, resolve test tech debt (false-positives, dupes), and mandate AST-based codebase auditing.
 - **Final Track**: Initialized 'architecture_boundary_hardening_20260302' to fix the GUI HITL bypass allowing direct AST mutations, patch token bloat in `mma_exec.py`, and implement cascading blockers in `dag_engine.py`.
 - **Testing Consolidation**: Initialized 'testing_consolidation_20260302' track to standardize simulation testing workflows around the pytest `live_gui` fixture and eliminate redundant `subprocess.Popen` wrappers.
-- **Dependency Order**: Added an explicit 'Track Dependency Order' execution guide to `TASKS.md` to ensure safe progression through the accumulated tech debt.
+- **Dependency Order**: Added an explicit 'Track Dependency Order' execution guide to `conductor/tracks.md` to ensure safe progression through the accumulated tech debt.
 - **Documentation**: Added guide_meta_boundary.md to explicitly clarify the difference between the Application's strict-HITL environment and the autonomous Meta-Tooling environment, helping future Tiers avoid feature bleed.
 - **Heuristics & Backlog**: Added Data-Oriented Design and Immediate Mode architectural heuristics (inspired by Muratori/Acton) to product-guidelines.md. Logged future decoupling and robust parsing tracks to a 'Future Backlog' in TASKS.md.
 

MMA_UX_SPEC.md

@@ -1,36 +0,0 @@
-# MMA Observability & UX Specification
-
-## 1. Goal
-Implement the visible surface area of the 4-Tier Hierarchical Multi-Model Architecture within `gui_2.py`. This ensures the user can monitor, control, and debug the multi-agent execution flow.
-
-## 2. Core Components
-
-### 2.1 MMA Dashboard Panel
-- **Visibility:** A new dockable panel named "MMA Dashboard".
-- **Track Status:** Display the current active `Track` ID and overall progress (e.g., "3/10 Tickets Complete").
-- **Ticket DAG Visualization:** A list or simple graph representing the `Ticket` queue.
-    - Each ticket shows: `ID`, `Target`, `Status` (Pending, Running, Paused, Complete, Blocked).
-    - Visual indicators for dependencies (e.g., indented or linked).
-
-### 2.2 The Execution Clutch (HITL)
-- **Step Mode Toggle:** A global or per-track checkbox to enable "Step Mode".
-- **Pause Points:**
-    - **Pre-Execution:** When a Tier 3 worker generates a tool call (e.g., `write_file`), the engine pauses.
-    - **UI Interaction:** The GUI displays the proposed script/change and provides:
-        - `[Approve]`: Proceed with execution.
-        - `[Edit Payload]`: Open the Memory Mutator.
-        - `[Abort]`: Mark the ticket as Blocked/Cancelled.
-- **Visual Feedback:** Tactile/Arcade-style blinking or color changes when the engine is "Paused for HITL".
-
-### 2.3 Memory Mutator (The "Debug" Superpower)
-- **Functionality:** A modal or dedicated text area that allows the user to edit the raw JSON conversation history of a paused worker.
-- **Use Case:** Fixing AI hallucinations or providing specific guidance mid-turn without restarting the context window.
-- **Integration:** After editing, the "Approve" button sends the *modified* history back to the engine.
-
-### 2.4 Tiered Metrics & Logs
-- **Observability:** Show which model (Tier 1, 2, 3, or 4) is currently active.
-- **Sub-Agent Logs:** Provide quick links to open the timestamped log files generated by `mma_exec.py`.
-
-## 3. Technical Integration
-- **Event Bus:** Use the existing `AsyncEventQueue` to push `StateUpdateEvents` from the `ConductorEngine` to the GUI.
-- **Non-Blocking:** Ensure the UI remains responsive (FPS > 60) even when multiple tickets are processing or the engine is waiting for user input.

Readme.md

@@ -1,14 +1,56 @@
-# Sloppy
+# Manual Slop
 
 ![img](./gallery/splash.png)
 
-A GUI orchestrator for local LLM-driven coding sessions. Manual Slop bridges high-latency AI reasoning with a low-latency ImGui render loop via a thread-safe asynchronous pipeline, ensuring every AI-generated payload passes through a human-auditable gate before execution.
+A high-density GUI orchestrator for local LLM-driven coding sessions. Manual Slop bridges high-latency AI reasoning with a low-latency ImGui render loop via a thread-safe asynchronous pipeline, ensuring every AI-generated payload passes through a human-auditable gate before execution.
 
-**Tech Stack**: Python 3.11+, Dear PyGui / ImGui, FastAPI, Uvicorn
-**Providers**: Gemini API, Anthropic API, DeepSeek, Gemini CLI (headless)
+**Design Philosophy**: Full manual control over vendor API metrics, agent capabilities, and context memory usage. High information density, tactile interactions, and explicit confirmation for destructive actions.
+
+**Tech Stack**: Python 3.11+, Dear PyGui / ImGui Bundle, FastAPI, Uvicorn, tree-sitter
+**Providers**: Gemini API, Anthropic API, DeepSeek, Gemini CLI (headless), MiniMax
 **Platform**: Windows (PowerShell) — single developer, local use
 
-![img](./gallery/python_2026-03-01_23-45-34.png)
+![img](./gallery/python_2026-03-11_00-37-21.png)
+
+---
+
+## Key Features
+
+### Multi-Provider Integration
+- **Gemini SDK**: Server-side context caching with TTL management, automatic cache rebuilding at 90% TTL
+- **Anthropic**: Ephemeral prompt caching with 4-breakpoint system, automatic history truncation at 180K tokens
+- **DeepSeek**: Dedicated SDK for code-optimized reasoning
+- **Gemini CLI**: Headless adapter with full functional parity, synchronous HITL bridge
+- **MiniMax**: Alternative provider support
+
+### 4-Tier MMA Orchestration
+Hierarchical task decomposition with specialized models and strict token firewalling:
+- **Tier 1 (Orchestrator)**: Product alignment, epic → tracks
+- **Tier 2 (Tech Lead)**: Track → tickets (DAG), persistent context
+- **Tier 3 (Worker)**: Stateless TDD implementation, context amnesia
+- **Tier 4 (QA)**: Stateless error analysis, no fixes
+
+### Strict Human-in-the-Loop (HITL)
+- **Execution Clutch**: All destructive actions suspend on `threading.Condition` pending GUI approval
+- **Three Dialog Types**: ConfirmDialog (scripts), MMAApprovalDialog (steps), MMASpawnApprovalDialog (workers)
+- **Editable Payloads**: Review, modify, or reject any AI-generated content before execution
+
+### 26 MCP Tools with Sandboxing
+Three-layer security model: Allowlist Construction → Path Validation → Resolution Gate
+- **File I/O**: read, list, search, slice, edit, tree
+- **AST-Based (Python)**: skeleton, outline, definition, signature, class summary, docstring
+- **Analysis**: summary, git diff, find usages, imports, syntax check, hierarchy
+- **Network**: web search, URL fetch
+- **Runtime**: UI performance metrics
+
+### Parallel Tool Execution
+Multiple independent tool calls within a single AI turn execute concurrently via `asyncio.gather`, significantly reducing latency.
+
+### AST-Based Context Management
+- **Skeleton View**: Signatures + docstrings, bodies replaced with `...`
+- **Curated View**: Preserves `@core_logic` decorated functions and `[HOT]` comment blocks
+- **Targeted View**: Extracts only specified symbols and their dependencies
+- **Heuristic Summaries**: Token-efficient structural descriptions without AI calls
 
 ---
 
@@ -26,35 +68,12 @@ The **MMA (Multi-Model Agent)** system decomposes epics into tracks, tracks into
 
 | Guide | Scope |
 |---|---|
+| [Readme](./docs/Readme.md) | Documentation index, GUI panel reference, configuration files, environment variables |
 | [Architecture](./docs/guide_architecture.md) | Threading model, event system, AI client multi-provider architecture, HITL mechanism, comms logging |
-| [Tools & IPC](./docs/guide_tools.md) | MCP Bridge security model, all 26 native tools, Hook API endpoints, ApiHookClient reference, shell runner |
-| [MMA Orchestration](./docs/guide_mma.md) | 4-tier hierarchy, Ticket/Track data structures, DAG engine, ConductorEngine execution loop, worker lifecycle |
-| [Simulations](./docs/guide_simulations.md) | `live_gui` fixture, Puppeteer pattern, mock provider, visual verification patterns, ASTParser / summarizer |
-
----
-
-## Module Map
-
-Core implementation resides in the `src/` directory.
-
-| File | Role |
-|---|---|
-| `src/gui_2.py` | Primary ImGui interface — App class, frame-sync, HITL dialogs |
-| `src/ai_client.py` | Multi-provider LLM abstraction (Gemini, Anthropic, DeepSeek, Gemini CLI) |
-| `src/mcp_client.py` | 26 MCP tools with filesystem sandboxing and tool dispatch |
-| `src/api_hooks.py` | HookServer — REST API for external automation on `:8999` |
-| `src/api_hook_client.py` | Python client for the Hook API (used by tests and external tooling) |
-| `src/multi_agent_conductor.py` | ConductorEngine — Tier 2 orchestration loop with DAG execution |
-| `src/conductor_tech_lead.py` | Tier 2 ticket generation from track briefs |
-| `src/dag_engine.py` | TrackDAG (dependency graph) + ExecutionEngine (tick-based state machine) |
-| `src/models.py` | Ticket, Track, WorkerContext dataclasses |
-| `src/events.py` | EventEmitter, AsyncEventQueue, UserRequestEvent |
-| `src/project_manager.py` | TOML config persistence, discussion management, track state |
-| `src/session_logger.py` | JSON-L + markdown audit trails (comms, tools, CLI, hooks) |
-| `src/shell_runner.py` | PowerShell execution with timeout, env config, QA callback |
-| `src/file_cache.py` | ASTParser (tree-sitter) — skeleton and curated views |
-| `src/summarize.py` | Heuristic file summaries (imports, classes, functions) |
-| `src/outline_tool.py` | Hierarchical code outline via stdlib `ast` |
+| [Tools & IPC](./docs/guide_tools.md) | MCP Bridge 3-layer security, 26 tool inventory, Hook API endpoints, ApiHookClient reference, shell runner |
+| [MMA Orchestration](./docs/guide_mma.md) | 4-tier hierarchy, Ticket/Track data structures, DAG engine, ConductorEngine, worker lifecycle, abort propagation |
+| [Simulations](./docs/guide_simulations.md) | `live_gui` fixture, Puppeteer pattern, mock provider, visual verification, ASTParser / summarizer |
+| [Meta-Boundary](./docs/guide_meta_boundary.md) | Application vs Meta-Tooling domains, inter-domain bridges, safety model separation |
 
 ---
 
@@ -105,6 +124,151 @@ uv run pytest tests/ -v
 
 ---
 
+## MMA 4-Tier Architecture
+
+The Multi-Model Agent system uses hierarchical task decomposition with specialized models at each tier:
+
+| Tier | Role | Model | Responsibility |
+|------|------|-------|----------------|
+| **Tier 1** | Orchestrator | `gemini-3.1-pro-preview` | Product alignment, epic → tracks, track initialization |
+| **Tier 2** | Tech Lead | `gemini-3-flash-preview` | Track → tickets (DAG), architectural oversight, persistent context |
+| **Tier 3** | Worker | `gemini-2.5-flash-lite` / `deepseek-v3` | Stateless TDD implementation per ticket, context amnesia |
+| **Tier 4** | QA | `gemini-2.5-flash-lite` / `deepseek-v3` | Stateless error analysis, diagnostics only (no fixes) |
+
+**Key Principles:**
+- **Context Amnesia**: Tier 3/4 workers start with `ai_client.reset_session()` — no history bleed
+- **Token Firewalling**: Each tier receives only the context it needs
+- **Model Escalation**: Failed tickets automatically retry with more capable models
+- **WorkerPool**: Bounded concurrency (default: 4 workers) with semaphore gating
+
+---
+
+## Module by Domain
+
+### src/ — Core implementation
+
+| File | Role |
+|---|---|
+| `src/gui_2.py` | Primary ImGui interface — App class, frame-sync, HITL dialogs, event system |
+| `src/ai_client.py` | Multi-provider LLM abstraction (Gemini, Anthropic, DeepSeek, MiniMax) |
+| `src/mcp_client.py` |       26 MCP tools with filesystem sandboxing and tool dispatch |
+| `src/api_hooks.py`  |          HookServer — REST API on `127.0.0.1:8999 for external automation |
+| `src/api_hook_client.py` |       Python client for the Hook API (used by tests and external tooling) |
+| `src/multi_agent_conductor.py` |   ConductorEngine — Tier 2 orchestration loop with DAG execution  |
+| `src/conductor_tech_lead.py`  |   Tier 2 ticket generation from track briefs |
+| `src/dag_engine.py`  |       TrackDAG (dependency graph) + ExecutionEngine (tick-based state machine) |
+| `src/models.py`  |       Ticket, Track, WorkerContext, Metadata, Track state |
+| `src/events.py`  |           EventEmitter, AsyncEventQueue, UserRequestEvent |
+| `src/project_manager.py`  |       TOML config persistence, discussion management, track state |
+| `src/session_logger.py`  |       JSON-L + markdown audit trails (comms, tools, CLI, hooks) |
+| `src/shell_runner.py`  |       PowerShell execution with timeout, env config, QA callback |
+| `src/file_cache.py`  |       ASTParser (tree-sitter) — skeleton, curated, and targeted views |
+| `src/summarize.py`  |       Heuristic file summaries (imports, classes, functions) |
+| `src/outline_tool.py`  |       Hierarchical code outline via stdlib `ast` |
+| `src/performance_monitor.py`  |       FPS, frame time, CPU, input lag tracking |
+| `src/log_registry.py`  |       Session metadata persistence |
+| `src/log_pruner.py`  |       Automated log cleanup based on age and whitelist |
+| `src/paths.py`  |       Centralized path resolution with environment variable overrides |
+| `src/cost_tracker.py`  |       Token cost estimation for API calls |
+| `src/gemini_cli_adapter.py`  |       CLI subprocess adapter with session management |
+| `src/mma_prompts.py`  |       Tier-specific system prompts for MMA orchestration |
+| `src/theme_*.py` |        UI theming (dark, light modes) |
+
+Simulation modules in `simulation/`:
+| File | Role |
+|---|--- |
+| `simulation/sim_base.py` |       BaseSimulation class with setup/teardown lifecycle |
+| `simulation/workflow_sim.py` |       WorkflowSimulator — high-level GUI automation |
+| `simulation/user_agent.py` |        UserSimAgent — simulated user behavior (reading time, thinking delays) |
+
+---
+
+## Setup
+The MCP Bridge implements a three-layer security model in `mcp_client.py`:
+
+Every tool accessing the filesystem passes through `_resolve_and_check(path)` before any I/O.
+
+### Layer 1: Allowlist Construction (`configure`)
+Called by `ai_client` before each send cycle:
+1. Resets `_allowed_paths` and `_base_dirs` to empty sets
+2. Sets `_primary_base_dir` from `extra_base_dirs[0]`
+3. Iterates `file_items`, resolving paths, adding to allowlist
+4. Blacklist check: `history.toml`, `*_history.toml`, `config.toml`, `credentials.toml` are NEVER allowed
+
+### Layer 2: Path Validation (`_is_allowed`)
+Checks run in order:
+1. **Blacklist**: `history.toml`, `*_history.toml` → hard deny
+2. **Explicit allowlist**: Path in `_allowed_paths` → allow
+3. **CWD fallback**: If no base dirs, allow `cwd()` subpaths
+4. **Base containment**: Must be subpath of `_base_dirs`
+5. **Default deny**: All other paths rejected
+
+### Layer 3: Resolution Gate (`_resolve_and_check`)
+1. Convert raw path string to `Path`
+2. If not absolute, prepend `_primary_base_dir`
+3. Resolve to absolute (follows symlinks)
+4. Call `_is_allowed()`
+5. Return `(resolved_path, "")` on success or `(None, error_message)` on failure
+
+All paths are resolved (following symlinks) before comparison, preventing symlink-based traversal attacks.
+
+### Security Model
+
+The MCP Bridge implements a three-layer security model in `mcp_client.py`. Every tool accessing the filesystem passes through `_resolve_and_check(path)` before any I/O.
+
+### Layer 1: Allowlist Construction (`configure`)
+Called by `ai_client` before each send cycle:
+1. Resets `_allowed_paths` and `_base_dirs` to empty sets.
+2. Sets `_primary_base_dir` from `extra_base_dirs[0]` (resolved) or falls back to cwd().
+3. Iterates `file_items`, resolving each path to an absolute path, adding to `_allowed_paths`; its parent directory is added to `_base_dirs`.
+4. Any entries in `extra_base_dirs` that are valid directories are also added to `_base_dirs`.
+
+### Layer 2: Path Validation (`_is_allowed`)
+Checks run in this exact order:
+1. **Blacklist**: `history.toml`, `*_history.toml`, `config`, `credentials` → hard deny
+2. **Explicit allowlist**: Path in `_allowed_paths` → allow
+7. **CWD fallback**: If no base dirs, any under `cwd()` is allowed (fail-safe for projects without explicit base dirs)
+8. **Base containment**: Must be a subpath of at least one entry in `_base_dirs` (via `relative_to()`)
+9. **Default deny**: All other paths rejected
+All paths are resolved (following symlinks) before comparison, preventing symlink-based traversal attacks.
+
+### Layer 3: Resolution Gate (`_resolve_and_check`)
+Every tool call passes through this:
+1. Convert raw path string to `Path`.
+2. If not absolute, prepend `_primary_base_dir`.
+3. Resolve to absolute.
+4. Call `_is_allowed()`.
+5. Return `(resolved_path, "")` on success, `(None, error_message)` on failure
+All paths are resolved (following symlinks) before comparison, preventing symlink-based traversal attacks.
+
+---
+
+## Conductor SystemThe project uses a spec-driven track system in `conductor/` for structured development:
+
+```
+conductor/
+├── workflow.md           # Task lifecycle, TDD protocol, phase verification
+├── tech-stack.md         # Technology constraints and patterns
+├── product.md            # Product vision and guidelines
+├── product-guidelines.md # Code standards, UX principles
+└── tracks/
+    └── <track_name>_<YYYYMMDD>/
+        ├── spec.md       # Track specification
+        ├── plan.md       # Implementation plan with checkbox tasks
+        ├── metadata.json # Track metadata
+        └── state.toml    # Structured state with task list
+```
+
+**Key Concepts:**
+- **Tracks**: Self-contained implementation units with spec, plan, and state
+- **TDD Protocol**: Red (failing tests) → Green (pass) → Refactor
+- **Phase Checkpoints**: Verification gates with git notes for audit trails
+- **MMA Delegation**: Tracks are executed via the 4-tier agent hierarchy
+
+See `conductor/workflow.md` for the full development workflow.
+
+---
+
 ## Project Configuration
 
 Projects are stored as `<name>.toml` files. The discussion history is split into a sibling `<name>_history.toml` to keep the main config lean.
@@ -134,3 +298,31 @@ run_powershell = true
 read_file = true
 # ... 26 tool flags
 ```
+
+---
+
+## Quick Reference
+
+### Hook API Endpoints (port 8999)
+
+| Endpoint | Method | Description |
+|----------|--------|-------------|
+| `/status` | GET | Health check |
+| `/api/project` | GET/POST | Project config |
+| `/api/session` | GET/POST | Discussion entries |
+| `/api/gui` | POST | GUI task queue |
+| `/api/gui/mma_status` | GET | Full MMA state |
+| `/api/gui/value/<tag>` | GET | Read GUI field |
+| `/api/ask` | POST | Blocking HITL dialog |
+
+### MCP Tool Categories
+
+| Category | Tools |
+|----------|-------|
+| **File I/O** | `read_file`, `list_directory`, `search_files`, `get_tree`, `get_file_slice`, `set_file_slice`, `edit_file` |
+| **AST (Python)** | `py_get_skeleton`, `py_get_code_outline`, `py_get_definition`, `py_update_definition`, `py_get_signature`, `py_set_signature`, `py_get_class_summary`, `py_get_var_declaration`, `py_set_var_declaration`, `py_get_docstring` |
+| **Analysis** | `get_file_summary`, `get_git_diff`, `py_find_usages`, `py_get_imports`, `py_check_syntax`, `py_get_hierarchy` |
+| **Network** | `web_search`, `fetch_url` |
+| **Runtime** | `get_ui_performance` |
+
+---

TASKS.md

@@ -128,3 +128,31 @@
 - **Status:** Planned
 - **Priority:** Medium
 - **Goal:** Interactive human-in-the-loop track to review and adjust GUI UX, animations, popups, and layout structures.
+
+---
+
+### C/C++ Language Support
+
+#### 25. ts_cpp_tree_sitter_20260308
+- **Status:** Planned
+- **Priority:** High
+- **Goal:** Add tree-sitter C and C++ grammars. Extend ASTParser to support C/C++ skeleton and outline extraction. Add MCP tools ts_c_get_skeleton, ts_cpp_get_skeleton, ts_c_get_code_outline, ts_cpp_get_code_outline.
+
+#### 26. gencpp_python_bindings_20260308
+- **Status:** Planned
+- **Priority:** Medium
+- **Goal:** Bootstrap standalone Python project with CFFI bindings for gencpp C library. Provides foundation for richer C++ AST parsing in future (beyond tree-sitter syntax).
+
+---
+
+### Path Configuration
+
+#### 27. project_conductor_dir_20260308
+- **Status:** Planned
+- **Priority:** High
+- **Goal:** Make conductor directory per-project. Each project TOML can specify custom conductor dir for isolated track/state management. Extends existing global path config.
+
+#### 28. gui_path_config_20260308
+- **Status:** Planned
+- **Priority:** High
+- **Goal:** Add path configuration UI to Context Hub. Allow users to view and edit configurable paths (conductor, logs, scripts) directly from the GUI.

conductor/archive/nerv_ui_theme_20260309/index.md

@@ -0,0 +1,5 @@
+# Track nerv_ui_theme_20260309 Context
+
+- [Specification](./spec.md)
+- [Implementation Plan](./plan.md)
+- [Metadata](./metadata.json)

conductor/archive/nerv_ui_theme_20260309/metadata.json

@@ -0,0 +1,8 @@
+{
+    "description":  "Implement a NERV UI theme for ImGui/Dear PyGui, inspired by technical/military consoles, with CRT effects and a black-void aesthetic.",
+    "track_id":  "nerv_ui_theme_20260309",
+    "type":  "feature",
+    "created_at":  "2026-03-09T00:35:48Z",
+    "status":  "new",
+    "updated_at":  "2026-03-09T00:35:48Z"
+}

conductor/archive/nerv_ui_theme_20260309/plan.md

@@ -0,0 +1,43 @@
+# Implementation Plan: NERV UI Theme
+
+## Phase 1: Research & Theme Infrastructure [checkpoint: 4b78e77]
+- [x] Task: Research existing theme implementation in src/theme.py and src/theme_2.py. 3fa4f64
+- [x] Task: Create a new src/theme_nerv.py to house the NERV color constants and theme application logic. 3fa4f64
+- [x] Task: Conductor - User Manual Verification 'Phase 1: Research & Theme Infrastructure' (Protocol in workflow.md) 4b78e77
+
+## Phase 2: Base NERV Theme Implementation (Colors & Geometry) [checkpoint: 9c38ea7]
+- [x] Task: Implement the "Black Void" and "Phosphor" color palette in src/theme_nerv.py. 3fa4f64
+- [x] Task: Implement "Hard Edges" by setting all rounding parameters to 0.0 in the NERV theme. 3fa4f64
+- [x] Task: Write unit tests to verify that the NERV theme correctly applies colors and geometry settings. de0d9f3
+- [x] Task: Conductor - User Manual Verification 'Phase 2: Base NERV Theme Implementation' (Protocol in workflow.md) 9c38ea7
+
+## Phase 3: Visual Effects (Scanlines & Status Flickering) [checkpoint: ceb0c7d]
+- [x] Task: Research how to implement a scanline overlay in ImGui (e.g., using a full-screen transparent texture or a custom draw list). 05a2b8e
+- [x] Task: Implement the subtle scanline overlay (6% opacity). 05a2b8e
+- [x] Task: Implement "Status Flickering" logic for active system indicators (e.g., a periodic alpha modification for specific text elements). 05a2b8e
+- [x] Task: Write tests to verify the visual effect triggers (e.g., checking if the scanline overlay is rendered). 4f4fa10
+- [x] Task: Conductor - User Manual Verification 'Phase 3: Visual Effects' (Protocol in workflow.md) ceb0c7d
+
+## Phase 4: Alert Pulsing & Error States [checkpoint: d9495f6]
+- [x] Task: Implement "Alert Pulsing" logic that can be triggered by application error events. d9495f6
+- [x] Task: Integrate Alert Pulsing with the NERV theme (shifting borders/background to Alert Red). d9495f6
+- [x] Task: Write tests to verify that an error state triggers the pulsing effect in the NERV theme. d9495f6
+- [x] Task: Conductor - User Manual Verification 'Phase 4: Alert Pulsing & Error States' (Protocol in workflow.md) d9495f6
+
+## Phase 5: Integration & Theme Selector [checkpoint: afcb1bf]
+- [x] Task: Add "NERV" to the theme selection dropdown in src/gui_2.py. afcb1bf
+- [x] Task: Ensure that switching to the NERV theme correctly initializes all visual effects (scanlines, etc.). afcb1bf
+- [x] Task: Final UX verification and performance check of the NERV theme. afcb1bf
+- [x] Task: Conductor - User Manual Verification 'Phase 5: Integration & Theme Selector' (Protocol in workflow.md) afcb1bf
+
+## Phase 6: NERV Theme Refinement (Contrast & Readability) [checkpoint: 9facecb]
+- [x] Task: Fix text readability by ensuring high-contrast text on bright backgrounds (e.g., black text on orange title bars). 9facecb
+- [x] Task: Adjust the NERV palette to use Data Green or Steel for standard text, reserving Orange for accents and backgrounds. 9facecb
+- [x] Task: Update gui_2.py to push/pop style colors for headers if necessary to maintain readability. 9facecb
+- [x] Task: Conductor - User Manual Verification 'Phase 6: NERV Theme Refinement' (Protocol in workflow.md) 9facecb
+
+## Phase 7: CRT Filter Implementation [checkpoint: e635c29]
+- [x] Task: Research and implement a more sophisticated "CRT Filter" beyond simple scanlines (e.g., adding a vignette, noise, or subtle color aberration). e635c29
+- [x] Task: Implement a "CRT Filter" toggle in the theme settings. e635c29
+- [x] Task: Integrate the new CRT filter into the gui_2.py rendering loop. e635c29
+- [x] Task: Conductor - User Manual Verification 'Phase 7: CRT Filter Implementation' (Protocol in workflow.md) e635c29

conductor/archive/nerv_ui_theme_20260309/spec.md

@@ -0,0 +1,37 @@
+# Specification: NERV UI Theme Integration
+
+## Overview
+This track aims to implement a new "NERV" visual theme for the manual_slop application, inspired by the aesthetic of technical/military consoles (e.g., Evangelion's NERV UI). The theme will be added as a selectable option within the application, allowing users to switch between the existing theme and the new NERV style without altering the core user experience or layout.
+
+## Functional Requirements
+- **Theme Selection:** Integrate a "NERV" theme option into the existing UI (e.g., in the configuration or theme settings).
+- **Color Palette:** Implement the "Black Void" aesthetic using absolute black (#000000) for the background and CRT-inspired phosphor colors:
+    - **NERV Orange (#FF9830):** Primary accents, headers, active borders.
+    - **Data Green (#50FF50):** Terminal output, "Nominal" status, standard data.
+    - **Wire Cyan (#20F0FF):** Structural separators, inactive borders.
+    - **Alert Red (#FF4840):** Error states, critical alerts.
+    - **Steel (#E0E0D8):** Secondary text, timestamps.
+- **Hard Edges:** Configure all UI elements (windows, frames, buttons) to have zero rounded corners (Rounding = 0.0).
+- **Typography:** Utilize a monospace font (e.g., IBM Plex Mono or the project's current monospace font) for all text to maintain a technical look.
+- **Visual Effects:**
+    - **Scanline Overlay:** Implement a subtle CRT-style scanline overlay (approx. 6% opacity).
+    - **Status Flickering:** Add subtle flickering effects to active system status indicators.
+    - **Alert Pulsing:** Implement red background or border pulsing during error or critical system states.
+
+## Non-Functional Requirements
+- **Performance:** Ensure the scanline overlay and status flickering do not significantly degrade UI responsiveness or increase CPU usage.
+- **Maintainability:** The theme should be implemented in a way that is consistent with the existing theme.py or theme_2.py architecture.
+
+## Acceptance Criteria
+- [ ] Users can select "NERV" from the theme selector.
+- [ ] The background is solid black (#000000).
+- [ ] All borders and buttons have zero rounded corners.
+- [ ] The NERV color palette is correctly applied to all UI elements.
+- [ ] The scanline overlay is visible and subtle.
+- [ ] Active status indicators exhibit the "Status Flickering" effect.
+- [ ] Errors trigger the "Alert Pulsing" effect.
+
+## Out of Scope
+- **Bilingual Labels:** Japanese sub-labels will not be implemented.
+- **Layout Changes:** No radical changes to window positioning or spacing.
+- **New Features:** This track is purely visual and does not add new application functionality.

conductor/archive/opencode_config_overhaul_20260310/metadata.json

@@ -0,0 +1,10 @@
+{
+  "id": "opencode_config_overhaul_20260310",
+  "title": "OpenCode Configuration Overhaul",
+  "type": "fix",
+  "status": "completed",
+  "priority": "high",
+  "created": "2026-03-10",
+  "depends_on": [],
+  "blocks": []
+}

conductor/archive/opencode_config_overhaul_20260310/plan.md

@@ -0,0 +1,23 @@
+# Implementation Plan: OpenCode Configuration Overhaul
+
+## Phase 1: Core Config and Agent Temperature/Step Fixes [checkpoint: 02abfc4]
+
+- [x] Task 1.1: Update `opencode.json` - set `compaction.auto: false`, `compaction.prune: false`
+- [x] Task 1.2: Update `.opencode/agents/tier1-orchestrator.md` - remove `steps: 50`, change `temperature: 0.4` to `0.5`, add "Context Management" section
+- [x] Task 1.3: Update `.opencode/agents/tier2-tech-lead.md` - remove `steps: 100`, change `temperature: 0.2` to `0.4`, add "Context Management" and "Pre-Delegation Checkpoint" sections
+- [x] Task 1.4: Update `.opencode/agents/tier3-worker.md` - remove `steps: 20`, change `temperature: 0.1` to `0.3`
+- [x] Task 1.5: Update `.opencode/agents/tier4-qa.md` - remove `steps: 5`, change `temperature: 0.0` to `0.2`
+- [x] Task 1.6: Update `.opencode/agents/general.md` - remove `steps: 15`, change `temperature: 0.2` to `0.3`
+- [x] Task 1.7: Update `.opencode/agents/explore.md` - remove `steps: 8`, change `temperature: 0.0` to `0.2`
+- [x] Task 1.8: Conductor - User Manual Verification (verified)
+
+## Phase 2: MMA Tier Command Expansion [checkpoint: 02abfc4]
+
+- [x] Task 2.1: Expand `.opencode/commands/mma-tier1-orchestrator.md` - add full Surgical Methodology, limitations, context section
+- [x] Task 2.2: Expand `.opencode/commands/mma-tier2-tech-lead.md` - add TDD protocol, Pre-Delegation Checkpoint, delegation patterns
+- [x] Task 2.3: Expand `.opencode/commands/mma-tier3-worker.md` - add key constraints, task execution, blocking protocol
+- [x] Task 2.4: Expand `.opencode/commands/mma-tier4-qa.md` - add key constraints, analysis protocol, structured output format
+- [x] Task 2.5: Conductor - User Manual Verification (verified)
+
+## Phase: Review Fixes
+- [x] Task: Apply review suggestions 8c5b5d3

conductor/archive/opencode_config_overhaul_20260310/spec.md

@@ -0,0 +1,54 @@
+# Track Specification: OpenCode Configuration Overhaul
+
+## Overview
+Fix critical gaps in OpenCode agent configuration that cause MMA workflow failures. Remove step limits that prematurely terminate complex tracks, disable automatic context compaction that loses critical session state, raise temperature for better problem-solving, and expand thin command wrappers into full protocol documentation.
+
+## Current State Audit (as of HEAD)
+
+### Already Implemented (DO NOT re-implement)
+- OpenCode MCP integration working (`opencode.json:17-25`)
+- Agent persona files exist for all 4 MMA tiers (`.opencode/agents/tier*.md`)
+- Conductor commands exist (`.opencode/commands/conductor-*.md`)
+- MMA tier commands exist but are thin wrappers (`.opencode/commands/mma-tier*.md`)
+
+### Gaps to Fill (This Track's Scope)
+
+1. **Step Limits**: All agents have restrictive `steps` limits:
+   - tier1: 50, tier2: 100, tier3: 20, tier4: 5
+   - These terminate complex track implementations prematurely
+
+2. **Auto-Compaction**: `opencode.json` has `compaction.auto: true` which loses session context without user control
+
+3. **Temperature Too Low**: 
+   - tier2: 0.2, tier3: 0.1, tier4: 0.0
+   - Reduces creative problem-solving for complex tracks
+
+4. **Thin Command Wrappers**: `mma-tier*.md` commands are 3-4 lines, lacking:
+   - Pre-delegation checkpoint protocol
+   - TDD phase confirmation requirements
+   - Blocking protocol
+   - Context management guidance
+
+## Goals
+- Remove all step limits from agent configurations
+- Disable automatic compaction, enforce manual-only via `/compact`
+- Raise temperatures to 0.2-0.5 range for better reasoning
+- Expand MMA tier commands with full protocol documentation
+
+## Functional Requirements
+- All 6 agent files updated with removed `steps` and adjusted `temperature`
+- `opencode.json` updated with `compaction.auto: false, prune: false`
+- All 4 MMA tier commands expanded with context, protocols, and patterns
+
+## Non-Functional Requirements
+- No functional changes to MCP tool usage or permissions
+- Maintain backward compatibility with existing workflow
+
+## Architecture Reference
+- `docs/guide_mma.md` - 4-tier architecture, worker lifecycle, context amnesia
+- `docs/guide_meta_boundary.md` - Application vs Meta-Tooling distinction
+
+## Out of Scope
+- Model tiering (using different models per tier)
+- Changes to Gemini CLI configuration
+- Changes to conductor workflow itself