Implement

Use the available user-question mechanism for decisions; unattended, the documented fallbacks in each step govern. EnterPlanMode and ExitPlanMode are banned because Arc owns its planning and execution process.

1. references/implementation-assurance.md — posture, ownership, review, verification ladder
2. references/task-granularity.md — normative XML and legacy compatibility
3. references/testing-patterns.md — seams and work-kind evidence
4. references/checkpoint-patterns.md — genuine human gates
5. references/subagent-statuses.md — result-to-state mapping
6. references/arc-paths.md — artifact locations
7. references/plan-lifecycle.md — baseline, drift, resumption, index writes

Load when relevant:

• references/model-strategy.md before delegating.
• disciplines/subagent-driven-development.md before using slice owners.
• disciplines/verification-before-completion.md before completion claims.
• disciplines/finishing-a-development-branch.md before shipping.
• references/index.md — the full reference catalogue, when the work needs background you can't name a file for.

All build agents live in agents/build/; specialists in agents/review/. Read an agent file before dispatching it. Never run multiple mutating owners in parallel when their declared paths or dependencies overlap.

0. Load or create the plan

If the user provided a saved plan or an approved plan in conversation, use it. Otherwise:

• check the plan index, then canonical/legacy plan locations;
• use skills/detail/SKILL.md for a full plan when the change needs durable cross-session work;
• create an inline plan for bounded work using the same header, seam registry, and XML task representation as a saved plan.

An environment-blocked <verify> command (missing dependencies, no network) is recorded as environment-blocked in the receipt and reported as a prerequisite — it neither blocks the task nor silently passes. A task may be marked done with unsatisfied <done> clauses only when every unsatisfied clause is environment-blocked and recorded in the decision log and index Notes; any other unsatisfied clause keeps the task open.

Do not invent a separate small-scope schema. Before implementation, ensure new auto tasks have valid kinds and evidence, checkpoint tasks require human input, dependencies resolve, and verify commands are concrete. When validation fails: fix the plan field in place if the correction is mechanical (recording it in the decision log); bounce to the detail skill when the fix would change intent.

Legacy plans

Plans with Plan schema: 2 validate modern tasks strictly. An absent schema header or schema 1 uses the legacy path. Legacy plans without assurance receive Planned assurance: Standard, then undergo a fresh risk assessment. Legacy auto tasks without kind use their existing <verify> and advisory <test_code>; do not force a seam or red run merely because classification is absent. Infer and record a modern kind only when intent is unambiguous. Legacy checkpoints remain exempt.

1. Select effective assurance

Use references/implementation-assurance.md. Announce Planned assurance, Effective assurance, and the concrete rationale before edits. Reassess after drift inspection. Highest applicable risk wins. Automatic reassessment only raises effective assurance; a user-confirmed downgrade cannot cross a Guarded floor. When assurance rises, update Effective assurance in the plan header before risky execution and append the rationale to the decision log. Never change Planned assurance during execution.

2. Establish execution authority and baseline

Check project rules and the current branch. Do not alter unrelated user changes.

Ask once whether per-slice commits are authorized. If the user already gave explicit commit instructions, follow them. If the user declines — or no user is available to ask — leave work uncommitted. Never infer push, PR, amend, or history-rewrite authority.

When a plan finishes with its work uncommitted, say so prominently in the report and the index Notes: the implementation exists only in the worktree, one reset away from loss, even though the index says DONE.

Persist the Implementation baseline in ## Implementation state before edits:

• starting HEAD;
• all declared task paths;
• pre-existing dirty paths and their initial fingerprints;
• plan/index metadata paths excluded from implementation evidence.

Also persist commit posture and last coherent commit. If a legacy in_progress plan has no baseline, return NEEDS_CONTEXT rather than guessing attribution.

If a task overlaps a pre-existing dirty path, report NEEDS_CONTEXT; never overwrite, discard, or guess ownership. Run affected baseline checks only. Stop on unexplained affected failures unless fixing them is the task.

For saved plans, run the canonical drift check and mark the owned index row IN PROGRESS before persisting the baseline below — the row claim is what signals ownership to concurrent writers — using the per-row write discipline.

3. Execute coherent slices

Follow dependencies. Legacy adjacent tasks may share one owner while retaining every task ID.

For each ready slice:

1. Write status="in_progress" before dispatch or local execution.
2. Give one owner the task, scene-setting context, applicable rules, implementation baseline, effective assurance, and commit posture.
3. The owner reads first, searches for existing patterns, creates work-kind evidence, implements vertically at the same seam, runs focused checks, self-reviews, and reports a canonical result.
4. The controller inspects the attributable diff and command evidence; an agent summary cannot mint a verification receipt.
5. Map the result through references/subagent-statuses.md, update the task status, update the index row, and log only drift, escalation, deviations, legacy normalization, dirty-path decisions, or other non-obvious choices.
6. Create the proposed coherent commit only when commit authority exists.

Progress summaries are informational and never wait on a fixed cadence.

Apply the work-kind evidence matrix in references/testing-patterns.md; do not restate or reinterpret it locally.

Run the focused test after meaningful red/green cycles. At stable slice boundaries, run affected package type, lint, and boundary checks. Before an authorized commit, run scoped non-mutating checks. Do not run broad workspace gates per slice.

Result handling

• DONE and resolved/accepted DONE_WITH_CONCERNS become done.
• NEEDS_CONTEXT and AUTH_GATE remain in_progress; change conditions and redispatch the same task.
• Only irrecoverable BLOCKED becomes blocked and rolls the plan to BLOCKED.

For interrupted in_progress work, inspect declared paths, implementation baseline, last coherent commit, decision log, and attributable diff. Re-run focused evidence before continuing. Never assume completion or discard the diff.

4. Human and external-action gates

Use checkpoint:verify for subjective judgment and checkpoint:decide for unresolved direction. Authentication creates a dynamic checkpoint:action: verify auth, then redispatch the same task.

Read-only deployment checks may be automatic. Any external mutation or destructive command needs authority in the current request or a dynamic action checkpoint immediately before execution. Missing mutation consent is NEEDS_CONTEXT, not an authentication failure. AUTH_GATE is reserved for credentials or authorization errors encountered while performing an already authorized action.

Unattended instructions suppress routine waits only; they never bypass these gates.

For UI slices, consume the feature spec, existing project pattern, or supplied visual source. When a required visual decision has no source, request direction; do not invent independent visual direction.

5. Regenerate and review the attributable implementation

After all slices are built:

1. Regenerate required packaging/generated artifacts from root sources.
2. Capture one review target from the implementation base through current HEAD plus attributable worktree changes — including non-ignored untracked files — excluding unchanged pre-existing dirty paths.
3. Run spec-reviewer and code-reviewer in parallel against that same target. (On a platform without delegation, run the same roles locally in sequence from their agent files — owner work first, then each review axis; sequential local review substitutes for parallel dispatch.)
4. Guarded work adds the relevant security, data, performance, Mastra, daniel-product-engineer, or accessibility-engineer specialist and rechecks Guarded signals against the actual diff.
5. Return findings to an implementation owner, fix root sources, regenerate artifacts, and rerun both axes. Rerun affected specialists when their scope changes.

Any in-scope source, test, documentation, configuration, or generated change invalidates both whole-implementation axes.

When an owner returns DONE_WITH_CONCERNS, the acceptance or resolution of each concern is recorded in the plan's decision log — that is the canonical location; mirror a one-line note in the index row when the concern survives to DONE.

6. Fresh closeout gate

After final review fixes and regeneration, run one fresh repository verification set on the unchanged target — the repository's own gate scripts (check/test/typecheck/build, whichever exist) plus the plan's verify commands. Name the exact commands in the closeout record. When environment limits collapse the set to nothing beyond the slice-level commands already run, record Closeout: passed (degenerate gate) so the weaker assurance stays visible. Run a separate production build once when applicable and not already part of that set. Run targeted E2E/browser/smoke checks only when the feature or Guarded risk justifies them.

A failed closeout command may be fixed and rerun. Any in-scope fix returns through both review axes before the next planned green closeout attempt.

Record a session-local verification receipt using references/implementation-assurance.md. Immediate completion/branch workflows may reuse it only while the exact command, cwd, HEAD, configuration, and attributable fingerprint remain unchanged in the same uninterrupted session. After the gate succeeds, persist Closeout: passed with the date, target fingerprint (sha256 over the sorted list of path:file-sha256 pairs for the attributable target — the one fingerprint convention, so runs stay comparable), and exact commands in ## Implementation state. The marker records that closeout occurred but never substitutes for a valid session-local receipt.

7. Close plan and offer shipping

Set the plan DONE only when every durable task is done and the fresh closeout target passes. Update only the owned index row and Last touched. Report the attributable files, evidence, review axes, specialist results, and closeout commands.

Ask how the user wants to ship: push and open a PR, keep authorized commits local, or stop here. Never push or open a PR without explicit authority.

• Planned/effective assurance and rationale are explicit.
• Implementation baseline and pre-existing dirty paths are captured.
• Every slice has one owner and evidence appropriate to its kind.
• Durable state and resumption follow the shared lifecycle.
• No routine fixed-cadence wait or broad per-slice workspace gate occurs.
• Generated artifacts precede whole-implementation review.
• Both review axes approve the exact final attributable target; Guarded specialists approve their scope.
• One fresh repository gate passes after review fixes.
• Commits, push, and PR actions have explicit authority.