Implement

Deliver the agreed behavior with the smallest repository-specific change: short plan and approval → implement → review → repair if needed → verify and report. Stop on the feature branch without merging, opening a PR, or invoking another review workflow. Use /tracer-autopilot for delivery through a branch-finishing choice.

Scope and simplicity

Acceptance requirements and explicit user decisions are binding. Planner-generated code, class boundaries, and mechanisms are proposals: simplify them when existing commands or libraries satisfy the same requirements. Record the changed approach; ask only when it changes acceptance, an explicit decision, or a material safety limit.

Before introducing custom parsing, a generic process runner, a permission evaluator, concurrency guarantees, or persisted recovery machinery that the user has not explicitly chosen, explain the concrete need and the simpler alternative, then ask. Safe reruns do not by themselves imply concurrent execution or automatic crash recovery. Preserve required data/security safeguards; expose a trade-off rather than quietly weakening them.

Default to one implementation context for a cohesive change, normally the controller itself. Multiple files or commits do not require multiple agents. Delegate only a named investigation or separable implementation unit whose benefit exceeds the handoff cost. Reuse its context for follow-up work. Helpers return results without spawning more agents.

1. Workspace and evidence plan

1. Inspect the branch and working tree. Stay on an existing feature branch. On main or master, follow /tracer-worktrees; ask about detached HEAD or ambiguous ownership. Preserve unrelated changes.
2. Ensure .tracer/ is ignored before writing workflow artifacts; commit a needed ignore rule before recording the base.
3. On a fresh run, record the starting SHA in .tracer/implement/progress.md. On resume, read that ledger and verify its scope, base, commits, running workers, and saved reports against Git before continuing the unfinished step. Recover existing work rather than restarting it. Ask about an invalid base or unexplained changes.
4. Select the smallest checks that establish the changed behavior and material failure paths. Run relevant existing tests as a baseline when available. An unrelated failing suite is not a work order; report it. A baseline failure that prevents assessing this change needs clarification.