coder-eval-create-plan

Context

• Current git status: !git status --short
• Current branch: !git branch --show-current
• Recent commits: !git log --oneline -5

Your task

Produce a detailed, phased plan that a fresh session with no memory of this conversation can execute via /coder-eval-implement-plan. The plan is the contract between you and the implementer — it must be self-contained. The implementer drives directly off these parts, so each must be concrete:

• Per phase: Changes, Edge Cases, Tests to Write, Tests to Run (real scoped uv run pytest … commands), Acceptance Criteria (verifiable, with checkboxes), and a Risk tag (Low / High — sets the implementer's review depth).
• Global: Patterns to Mirror (actual code snippets from this repo, not descriptions), Design Context, Master Acceptance Checklist, Confidence Score.

The input may be a feature description, a file path to a spec/design doc (read it first), a bug list, or a combination.

Follow these steps:

1. Gather input — If the user references a file, read it in full first. If it's a bug list, enumerate each item. If it's a direct description, use it as-is.

2. Understand & classify — Restate the goal in one or two sentences. If there are multiple items, summarize scope and list each. Then classify:

   Level	Indicators
   Small	1-3 files, follows existing patterns, <100 new lines, single phase
   Medium	3-10 files, one new criterion / one CLI flag group / one model addition, 2-4 phases
   Large	10+ files, new agent or cross-module interaction (orchestrator + models + criteria), 5+ phases
   XL	Architectural change, new subsystem, migration of an existing contract — split into multiple plans

   For Small, collapse to one phase (or a flat task list). For XL, stop now — present the classification rationale and a proposed split, and wait for user confirmation before any further research or planning.

3. Research the codebase — Read all relevant files to understand the current state. Implement by mirroring and re-using existing patterns, not inventing. Pay special attention to:

   • coder_eval/models/ — Pydantic data models (all importable from coder_eval.models; declared once, consumed everywhere — SSOT)
   • coder_eval/criteria/ — Plugin registry with auto-discovery via @register_criterion; SuccessCriterion discriminated union in models/criteria.py
   • coder_eval/agents/ + coder_eval/plugins.py — Agent ABC implementations registered through the coder_eval.plugins entry-point SPI against AgentRegistry. agent.type is an open string; Orchestrator._create_agent delegates to the registry's create_agent() factory (agents/registry.py) instead of dispatching by kind, so you add an agent via a register(registry) hook — not by editing _create_agent or the AgentKind enum (models/enums.py, which lists only the known built-in kinds)
   • coder_eval/orchestration/ — Batch execution, experiment resolution, and the single declarative merge resolver (config_merge.py::resolve_root)
   • coder_eval/cli/ — Typer + Rich CLI commands; generic -D/--set overrides (orchestration/overrides.py)
   • coder_eval/streaming/ — Real-time agent event streaming; the agent is the sole emitter and EventCollector is the single TurnRecord capture seam
   • tests/lint/rules/ — custom architectural lint rules (CE001–CExxx), the project's harness for mechanically-enforced invariants