cleanup: remove legacy .opencode/ directory (18 agent/command .md files + package.json + package-lock.json)

Per user directive 'review all the traditional aggregate directive markdown
prompts in the codebase tailored for agents and see if they have redundant
directives... lets do a clean pass on them' (2026-07-05).

REDUNDANT DIRECTIVES REMOVED:
- All 18 files in .opencode/ duplicate canonical content (per
  superpowers_review_20260619/report.md §16.2 'Legacy .opencode/ and
  .gemini/ directories' documented the directory as legacy).
- 10 agent files (.opencode/agents/*.md) duplicate .agents/skills/mma-*/
  SKILL.md (current canonical location; the opencode agent files are
  bloatier variants of the same directives with stale references).
- 8 command files (.opencode/commands/*.md) are legacy Gemini CLI slash
  commands; OpenCode does not use them.

CANONICAL LOCATIONS (UNTOUCHED):
- .agents/skills/mma-orchestrator/SKILL.md
- .agents/skills/mma-tier1-orchestrator/SKILL.md
- .agents/skills/mma-tier2-tech-lead/SKILL.md
- .agents/skills/mma-tier3-worker/SKILL.md
- .agents/skills/mma-tier4-qa/SKILL.md
- conductor/tier2/agents/tier2-autonomous.md (Tier 2 sandbox canonical)
- conductor/tier2/agents/tier2-autonomous.warm.md (Tier 2 sandbox warm)
- .opencode/node_modules/ was already gitignored (npm install artifact)

PRESERVED REDUNDANCIES (audit found, kept intentionally):
- AGENTS.md + conductor/workflow.md + .agents/skills/mma-tier2-tech-lead/
  SKILL.md + conductor/tier2/agents/tier2-autonomous.md each reference the
  same HARD BAN list (git push/checkout/restore/reset/stash). Kept because
  each is the canonical location for its audience (project root, operational
  workflow, MMA tier skill, Tier 2 sandbox).
- conductor/tier2/agents/tier2-autonomous.md (174 lines) is a SUPERSET of
  .opencode/agents/tier2-tech-lead.md (254 lines) with sandbox-specific
  operational contracts. Both are valid for their target audience.

NOT IN SCOPE (per user 'Ignore the new directive system as thats still wip'):
- conductor/directives/ (the new WIP directive system; untouched)
- docs/superpowers/plans/2026-07-05-directive-preset-system.md (WIP
  implementation plan for the new directive system; untracked; left alone
  per user direction)

VERIFICATION:
- All 20 tracked files in .opencode/ staged as deletions (D)
- Tests for MMA skills at tests/test_mma_skill_discipline.py still pass
- conductor/workflow.md Session Start Checklist unchanged
- .agents/skills/mma-*/SKILL.md files unchanged
This commit is contained in:
ed
2026-07-05 14:34:56 -04:00
parent ad8ba4d001
commit f63769ac1a
20 changed files with 0 additions and 2974 deletions
-109
View File
@@ -1,109 +0,0 @@
---
description: Resume or start track implementation following TDD protocol
agent: tier2-tech-lead
---
# /conductor-implement
Resume or start implementation of the active track following TDD protocol.
## Prerequisites
- Run `/conductor-setup` first to load context
- Ensure a track is active (has `[~]` tasks)
## CRITICAL: Use MCP Tools Only
All research and file operations must use Manual Slop's MCP tools:
- `manual-slop_py_get_code_outline` - structure analysis
- `manual-slop_py_get_skeleton` - signatures + docstrings
- `manual-slop_py_find_usages` - find references
- `manual-slop_get_git_diff` - recent changes
- `manual-slop_run_powershell` - shell commands
## Implementation Protocol
1. **Identify Current Task:**
- Read active track's `plan.md` via `manual-slop_read_file`
- Find the first `[~]` (in-progress) or `[ ]` (pending) task
- If phase has no pending tasks, move to next phase
2. **Research Phase (MANDATORY):**
Before implementing, use MCP tools to understand context:
- `manual-slop_py_get_code_outline` on target files
- `manual-slop_py_get_skeleton` on dependencies
- `manual-slop_py_find_usages` for related patterns
- `manual-slop_get_git_diff` for recent changes
- Audit `__init__` methods for existing state
3. **TDD Cycle:**
### Red Phase (Write Failing Tests)
- Stage current progress: `manual-slop_run_powershell` with `git add .`
- Delegate test creation to @tier3-worker:
```
@tier3-worker
Write tests for: [task description]
WHERE: tests/test_file.py:line-range
WHAT: Test [specific functionality]
HOW: Use pytest, assert [expected behavior]
SAFETY: [thread-safety constraints]
Use 1-space indentation. Use MCP tools only.
```
- Run tests: `manual-slop_run_powershell` with `uv run pytest tests/test_file.py -v`
- **CONFIRM TESTS FAIL** - this is the Red phase
### Green Phase (Implement to Pass)
- Stage current progress: `manual-slop_run_powershell` with `git add .`
- Delegate implementation to @tier3-worker:
```
@tier3-worker
Implement: [task description]
WHERE: src/file.py:line-range
WHAT: [specific change]
HOW: [API calls, patterns to use]
SAFETY: [thread-safety constraints]
Use 1-space indentation. Use MCP tools only.
```
- Run tests: `manual-slop_run_powershell` with `uv run pytest tests/test_file.py -v`
- **CONFIRM TESTS PASS** - this is the Green phase
### Refactor Phase (Optional)
- With passing tests, refactor for clarity
- Re-run tests to verify
4. **Commit Protocol (ATOMIC PER-TASK):**
Use `manual-slop_run_powershell`:
```powershell
git add .
git commit -m "feat(scope): description"
$hash = git log -1 --format="%H"
git notes add -m "Task: [summary]" $hash
```
- Update `plan.md`: Change `[~]` to `[x]` with commit SHA
- Commit plan update: `git add plan.md && git commit -m "conductor(plan): Mark task complete"`
5. **Repeat for Next Task**
## Error Handling
If tests fail after Green phase:
- Delegate analysis to @tier4-qa:
```
@tier4-qa
Analyze this test failure:
[test output]
DO NOT fix - provide analysis only. Use MCP tools only.
```
- Maximum 2 fix attempts before escalating to user
## Phase Completion
When all tasks in a phase are `[x]`:
- Run `/conductor-verify` for checkpoint
-147
View File
@@ -1,147 +0,0 @@
---
description: Create a new conductor track with spec, plan, and metadata
agent: tier1-orchestrator
subtask: true
---
# /conductor-new-track
Create a new conductor track following the Surgical Methodology.
## Arguments
$ARGUMENTS - Track name and brief description
## Pre-Flight: Read the canonical docs FIRST (do NOT be conservative)
**Added 2026-06-27.** This project has extensive canonical documentation. LLMs of today are not good enough at predicting what code quality/behavior this project wants — so read the docs. Being conservative about reading knowledge from markdown files is an ANTI-PATTERN in this codebase.
Before writing the spec, read:
1. `AGENTS.md` — the project-root agent-facing rules; especially the HARD BANs (git restore/checkout/reset, opaque types in non-boundary code)
2. `conductor/workflow.md` — including §0 (Python Type Promotion Mandate) and the Tier 1 Track Initialization Rules
3. `conductor/tech-stack.md` — including the Core Value reference at the top
4. `conductor/product.md` — product vision + primary use cases
5. `conductor/product-guidelines.md`**Core Value section is mandatory reading**: C11/Odin/Jai semantics in a Python runtime
6. `conductor/code_styleguides/data_oriented_design.md` §8.5 — the Python Type Promotion Mandate
7. `conductor/code_styleguides/python.md` §17 — the LLM Default Anti-Patterns (banned patterns)
8. `conductor/code_styleguides/type_aliases.md` — Metadata is the boundary type
9. `conductor/code_styleguides/error_handling.md` — Result[T] + NIL_T sentinels
10. The relevant `docs/guide_*.md` for the layers the track touches
11. `conductor/tracks.md` — check existing tracks for similar work (don't re-invent)
## Protocol
1. **Audit Before Specifying (MANDATORY):**
Before writing any spec, research the existing codebase:
- Use `py_get_code_outline` on relevant files
- Use `py_get_definition` on target classes
- Use `grep` to find related patterns
- Use `get_git_diff` to understand recent changes
Document findings in a "Current State Audit" section.
2. **Apply the Python Type Promotion Mandate (workflow.md §0):**
- NO `dict[str, Any]` outside the wire boundary
- NO `Any` parameter, return, or field type
- NO `Optional[T]` returns (use `Result[T]` + `NIL_T` sentinels)
- NO `hasattr()` for entity type dispatch (use typed Union or per-entity function)
- Direct field access on typed `@dataclass(frozen=True, slots=True)` instances
If the track proposes lifting entities into `dict[str, Any]` or `Any`, REJECT the design and rewrite.
3. **Generate Track ID:**
Format: `{name}_{YYYYMMDD}`
Example: `async_tool_execution_20260303`
4. **Create Track Directory:**
`conductor/tracks/{track_id}/`
5. **Create spec.md:**
```markdown
# Track Specification: {Title}
## Overview
[One-paragraph description]
## Current State Audit (as of {commit_sha})
### Already Implemented (DO NOT re-implement)
- [Existing feature with file:line reference]
### Gaps to Fill (This Track's Scope)
- [What's missing that this track will address]
## Goals
- [Specific, measurable goals]
## Functional Requirements
- [Detailed requirements]
## Non-Functional Requirements
- [Performance, security, etc.]
## Architecture Reference
- docs/guide_architecture.md#section
- docs/guide_tools.md#section
- `conductor/code_styleguides/data_oriented_design.md` §8.5 (the Python Type Promotion Mandate)
## Out of Scope
- [What this track will NOT do]
```
6. **Create plan.md:**
```markdown
# Implementation Plan: {Title}
## Phase 1: {Name}
Focus: {One-sentence scope}
- [ ] Task 1.1: {Surgical description with file:line refs}
- [ ] Task 1.2: ...
- [ ] Task 1.N: Write tests for Phase 1 changes
- [ ] Task 1.X: Conductor - User Manual Verification
## Phase 2: {Name}
...
```
7. **Create metadata.json:**
```json
{
"id": "{track_id}",
"title": "{title}",
"type": "feature|fix|refactor|docs",
"status": "planned",
"priority": "high|medium|low",
"created": "{YYYY-MM-DD}",
"depends_on": [],
"blocks": []
}
```
8. **Update tracks.md:**
Add entry to `conductor/tracks.md` registry.
9. **Report:**
```
## Track Created
**ID:** {track_id}
**Location:** conductor/tracks/{track_id}/
**Files Created:**
- spec.md
- plan.md
- metadata.json
**Next Steps:**
1. Review spec.md for completeness
2. Run `/conductor-implement` to begin execution
```
## Surgical Methodology Checklist
- [ ] Audited existing code before writing spec
- [ ] Documented existing implementations with file:line refs
- [ ] Framed requirements as gaps, not features
- [ ] Tasks are worker-ready (WHERE/WHAT/HOW/SAFETY)
- [ ] Referenced architecture docs
- [ ] Mapped dependencies in metadata
- [ ] Applied the Python Type Promotion Mandate (workflow.md §0) — no dict[str, Any], no Any, no Optional[T], no hasattr() for entity dispatch
-47
View File
@@ -1,47 +0,0 @@
---
description: Initialize conductor context — read product docs, verify structure, report readiness
agent: tier1-orchestrator
subtask: true
---
# /conductor-setup
Bootstrap the session with full conductor context. Run this at session start.
## Steps
1. **Read Core Documents:**
- `conductor/index.md` — navigation hub
- `conductor/product.md` — product vision
- `conductor/product-guidelines.md` — UX/code standards
- `conductor/tech-stack.md` — technology constraints
- `conductor/workflow.md` — task lifecycle (skim; reference during implementation)
2. **Check Active Tracks:**
- List all directories in `conductor/tracks/`
- Read each `metadata.json` for status
- Read each `plan.md` for current task state
- Identify the track with `[~]` in-progress tasks
3. **Check Session Context:**
- 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
4. **Report Readiness:**
Present a session startup summary:
```
## Session Ready
**Active Track:** {track name} — Phase {N}, Task: {current task description}
**Recent Activity:** {last journal entry title}
**Last Commit:** {git log -1 oneline}
Ready to:
- `/conductor-implement` — resume active track
- `/conductor-status` — full status overview
- `/conductor-new-track` — start new work
```
## Important
- This is READ-ONLY — do not modify files
-59
View File
@@ -1,59 +0,0 @@
---
description: Display full status of all conductor tracks and tasks
agent: tier1-orchestrator
subtask: true
---
# /conductor-status
Display comprehensive status of the conductor system.
## Steps
1. **Read Track Index:**
- `conductor/tracks.md` — track registry
- `conductor/index.md` — navigation hub
2. **Scan All Tracks:**
For each track in `conductor/tracks/`:
- Read `metadata.json` for status and timestamps
- Read `plan.md` for task progress
- Count completed vs total tasks
3. **Check conductor/tracks.md:**
- List IN_PROGRESS tasks
- List BLOCKED tasks
- List pending tasks by priority
4. **Recent Activity:**
- `git log --oneline -5`
- Last 2 entries from `JOURNAL.md`
5. **Report Format:**
```
## Conductor Status
### Active Tracks
| Track | Status | Progress | Current Task |
|-------|--------|----------|--------------|
| ... | ... | N/M tasks | ... |
### Task Registry (conductor/tracks.md)
**In Progress:**
- [ ] Task description
**Blocked:**
- [ ] Task description (reason)
### Recent Commits
- `abc1234` commit message
### Recent Journal
- YYYY-MM-DD: Entry title
### Recommendations
- [Next action suggestion]
```
## Important
- This is READ-ONLY — do not modify files
-92
View File
@@ -1,92 +0,0 @@
---
description: Verify phase completion and create checkpoint commit
agent: tier2-tech-lead
---
# /conductor-verify
Execute phase completion verification and create checkpoint.
## Prerequisites
- All tasks in the current phase must be marked `[x]`
- All changes must be committed
## CRITICAL: Use MCP Tools Only
All operations must use Manual Slop's MCP tools:
- `manual-slop_read_file` - read files
- `manual-slop_get_git_diff` - check changes
- `manual-slop_run_powershell` - shell commands
## Verification Protocol
1. **Announce Protocol Start:**
Inform user that phase verification has begun.
2. **Determine Phase Scope:**
- Find previous phase checkpoint SHA in `plan.md` via `manual-slop_read_file`
- If no previous checkpoint, scope is all changes since first commit
3. **List Changed Files:**
Use `manual-slop_run_powershell`:
```powershell
git diff --name-only <previous_checkpoint_sha> HEAD
```
4. **Verify Test Coverage:**
For each code file changed (exclude `.json`, `.md`, `.yaml`):
- Check if corresponding test file exists via `manual-slop_search_files`
- If missing, create test file via @tier3-worker
5. **Execute Tests in Batches:**
**CRITICAL**: Do NOT run full suite. Run max 4 test files at a time.
Announce command before execution:
```
I will now run: uv run pytest tests/test_file1.py tests/test_file2.py -v
```
Use `manual-slop_run_powershell` to execute.
If tests fail with large output:
- Pipe to log file
- Delegate analysis to @tier4-qa
- Maximum 2 fix attempts before escalating
6. **Present Results:**
```
## Phase Verification Results
**Phase:** {phase name}
**Files Changed:** {count}
**Tests Run:** {count}
**Tests Passed:** {count}
**Tests Failed:** {count}
[Detailed results or failure analysis]
```
7. **Await User Confirmation:**
**PAUSE** and wait for explicit user approval before proceeding.
8. **Create Checkpoint:**
Use `manual-slop_run_powershell`:
```powershell
git add .
git commit --allow-empty -m "conductor(checkpoint): Phase {N} complete"
$hash = git log -1 --format="%H"
git notes add -m "Verification: [report summary]" $hash
```
9. **Update Plan:**
- Add `[checkpoint: {sha}]` to phase heading in `plan.md`
- Use `manual-slop_set_file_slice` or `manual-slop_read_file` + write
- Commit: `git add plan.md && git commit -m "conductor(plan): Mark phase complete"`
10. **Announce Completion:**
Inform user that phase is complete with checkpoint created.
## Error Handling
- If any verification fails: HALT and present logs
- Do NOT proceed without user confirmation
- Maximum 2 fix attempts per failure
@@ -1,65 +0,0 @@
---
description: Invoke Tier 1 Orchestrator for product alignment, high-level planning, and track initialization
agent: tier1-orchestrator
---
$ARGUMENTS
---
## Context
You are now acting as Tier 1 Orchestrator in the **META-TOOLING** domain (per `docs/guide_meta_boundary.md`). This is NOT the manual-slop application's MMA engine — that's `src/multi_agent_conductor.py` in the APPLICATION domain.
### Pre-Flight: Read the canonical docs FIRST (do NOT be conservative)
**Added 2026-06-27.** This project has extensive canonical documentation. Read the docs. Don't skim.
Before ANY planning or track initialization, read:
1. `AGENTS.md` — project-root rules; especially the HARD BANs
2. `conductor/workflow.md` — including §0 (Python Type Promotion Mandate)
3. `conductor/tech-stack.md` — Core Value reference at top
4. `conductor/product-guidelines.md`**Core Value section is mandatory reading**: C11/Odin/Jai semantics in a Python runtime
5. `conductor/code_styleguides/data_oriented_design.md` §8.5 — the Python Type Promotion Mandate
6. `conductor/code_styleguides/python.md` §17 — LLM Default Anti-Patterns (banned patterns)
7. `conductor/code_styleguides/type_aliases.md` — Metadata is the boundary type
8. `conductor/tracks.md` — check existing tracks for similar work (don't reinvent)
LLMs of today are not good enough at predicting what this project wants — read the docs.
### Primary Responsibilities
- Product alignment and strategic planning
- Track initialization (`/conductor-new-track`)
- Session setup (`/conductor-setup`)
- Delegate execution to Tier 2 Tech Lead via the OpenCode Task tool
- Write an end-of-session report (`docs/reports/SESSION_<date>.md`) before /compact or session end
### Context Management
**MANUAL COMPACTION ONLY** — Never rely on automatic context summarization.
Preserve full context during track planning and spec creation.
**Before /compact or session end:** write `docs/reports/SESSION_<date>.md` capturing what was done, what remains, the current branch.
**Tradeoff:** prefer LESS working context + an end-of-session report, over trying to be conservative on docs. The user explicitly rejected LLM conservatism.
### 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.
5. **APPLY THE PYTHON TYPE PROMOTION MANDATE** (conductor/workflow.md §0): every track spec/plan MUST respect the C11/Odin/Jai-in-Python rules:
- No `dict[str, Any]` outside the wire boundary
- No `Any` parameter, return, or field type
- No `Optional[T]` returns (use `Result[T]` + `NIL_T` sentinels)
- No `hasattr()` for entity type dispatch
- Direct field access on typed `@dataclass(frozen=True, slots=True)` instances
If a track proposes lifting entities into `dict[str, Any]` or `Any`, REJECT the design and rewrite.
### 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
-115
View File
@@ -1,115 +0,0 @@
---
description: Invoke Tier 2 Tech Lead for architectural design and track execution
agent: tier2-tech-lead
---
$ARGUMENTS
---
## Context
You are now acting as Tier 2 Tech Lead in the **META-TOOLING** domain (per `docs/guide_meta_boundary.md`). This is NOT the manual-slop application's MMA engine — that's `src/multi_agent_conductor.py` in the APPLICATION domain.
### Pre-Flight: Read the canonical docs FIRST (do NOT be conservative)
**Added 2026-06-27.** This project has extensive canonical documentation. Read the docs. Don't skim.
Before ANY planning, design, or delegation, read:
1. `AGENTS.md` — project-root rules; especially the HARD BANs
2. `conductor/workflow.md` — including §0 (Python Type Promotion Mandate)
3. `conductor/tech-stack.md` — Core Value reference at top
4. `conductor/product-guidelines.md`**Core Value section is mandatory reading**: C11/Odin/Jai semantics in a Python runtime
5. `conductor/code_styleguides/data_oriented_design.md` §8.5 — the Python Type Promotion Mandate
6. `conductor/code_styleguides/python.md` §17 — LLM Default Anti-Patterns (banned patterns)
7. `conductor/code_styleguides/type_aliases.md` — Metadata is the boundary type
8. The relevant `docs/guide_*.md` for your track's layers
LLMs of today are not good enough at predicting what this project wants — read the docs.
### Primary Responsibilities
- Track execution (`/conductor-implement`)
- Architectural oversight
- Delegate to Tier 3 Workers via the OpenCode Task tool (`subagent_type: "tier3-worker"`)
- Delegate error analysis to Tier 4 QA via the OpenCode Task tool (`subagent_type: "tier4-qa"`)
- Maintain persistent memory throughout track execution
- Write an end-of-session report (`docs/reports/SESSION_<date>.md`) before /compact or session end
### 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.
**Before /compact or session end:** write `docs/reports/SESSION_<date>.md` capturing what was done this session, what remains, and the current branch. This allows the next session to re-warm context.
**Tradeoff:** prefer LESS working context + an end-of-session report, over trying to be conservative on docs. The user explicitly rejected LLM conservatism on this project.
### 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. (Per AGENTS.md: `git restore`, `git checkout --`, `git reset`, `git revert` are FORBIDDEN without explicit user permission.)
### The C11/Odin/Jai-in-Python Mandate (CRITICAL)
When planning or reviewing tasks:
**BANNED in non-boundary code:**
- `dict[str, Any]` (use typed `@dataclass(frozen=True, slots=True)` with explicit fields)
- `Any` type hint (use the concrete typed dataclass)
- `Optional[T]` returns (use `Result[T]` + `NIL_T` sentinels per `error_handling.md`)
- `hasattr()` for entity type dispatch (use typed Union or per-entity function)
- Local imports inside functions (top-of-module imports only)
- `import X as _PREFIX` aliasing (use the original name)
- Repeated `.from_dict()` calls in the same expression (cache or promote the type)
**The one exception:** the literal wire boundary (TOML/JSON parse functions) may use `dict[str, Any]` + `Metadata.from_dict(...)`.
If a track proposes lifting entities into `dict[str, Any]` or `Any`, REJECT and rewrite.
### 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 (OpenCode Task tool — replaces legacy mma_exec.py)
**Tier 3 Worker** (OpenCode 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.
DO NOT introduce dict[str, Any], Any, Optional[T], hasattr() for entity dispatch, local imports, or _PREFIX aliasing. See conductor/code_styleguides/python.md §17.
```
**Tier 4 QA** (OpenCode Task tool):
```
subagent_type: "tier4-qa"
description: "Analyze failure"
prompt: |
[Error output]
DO NOT fix - provide root cause analysis only.
```
**NOTE:** the legacy `mma_exec.py` and `claude_mma_exec.py` bridge scripts are DEPRECATED as of 2026-06-27. All sub-agent delegation now goes through the OpenCode Task tool.
-83
View File
@@ -1,83 +0,0 @@
---
description: Invoke Tier 3 Worker for surgical code implementation
agent: tier3-worker
---
$ARGUMENTS
---
## Context
You are now acting as Tier 3 Worker in the **META-TOOLING** domain (per `docs/guide_meta_boundary.md`). You implement surgical code changes for the manual_slop application codebase (the APPLICATION domain), per the spec/plan from Tier 1/2.
### Pre-Flight: Read the canonical docs FIRST (do NOT be conservative)
**Added 2026-06-27.** This project has extensive canonical documentation. Read the docs. Don't skim.
Before ANY implementation, read:
1. `AGENTS.md` — project-root rules; especially the HARD BANs
2. `conductor/code_styleguides/python.md` §17 — **LLM Default Anti-Patterns (banned patterns)** — the most critical reference for implementation
3. `conductor/code_styleguides/data_oriented_design.md` §8.5 — the Python Type Promotion Mandate
4. `conductor/code_styleguides/type_aliases.md` — Metadata is the boundary type
5. `conductor/code_styleguides/error_handling.md` — Result[T] + NIL_T sentinels
6. The relevant `docs/guide_*.md` for the layer your task touches
### 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
### The Banned Patterns (DO NOT INTRODUCE)
From `conductor/code_styleguides/python.md` §17. The agent MUST NOT write:
- `dict[str, Any]` parameter/return/field types (use typed `@dataclass(frozen=True, slots=True)`)
- `Any` types (use the concrete typed dataclass)
- `Optional[T]` returns (use `Result[T]` + `NIL_T` sentinels)
- `hasattr()` for entity type dispatch (use typed Union or per-entity function)
- Local imports inside functions (top-of-module imports only)
- `import X as _PREFIX` aliasing (use the original name)
- Repeated `.from_dict()` calls in the same expression (cache the result or promote the type)
**The one exception:** the literal wire boundary (TOML/JSON parse functions) may use `dict[str, Any]` + `Metadata.from_dict(...)`.
### 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; do NOT introduce banned patterns
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 required
- Internal methods/variables prefixed with underscore
- NEVER use `git restore`, `git checkout --`, `git reset`, or `git revert` (per AGENTS.md HARD BAN)
-75
View File
@@ -1,75 +0,0 @@
---
description: Invoke Tier 4 QA Agent for error analysis
agent: tier4-qa
---
$ARGUMENTS
---
## 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