howells/arc/implement

<tool_restrictions>

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.

</tool_restrictions>

<arc_runtime> Requires the full Arc bundle. Arc-owned paths (agents/, references/, disciplines/, templates/, scripts/, rules/, skills/) resolve from the plugin root — the directory containing agents/ and skills/. Everything else is the user's repository. </arc_runtime>

<required_reading> Read before execution:

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.

</required_reading>

<available_agents>

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. </available_agents>

<process>

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.

1. 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.

1. The controller inspects the attributable diff and command evidence; an agent summary cannot

mint a verification receipt.

1. 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.

1. 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: