@yunhozz/arc 0.1.9 → 0.2.0

package/claude/skill/references/commit.md

@@ -6,18 +6,18 @@ Stage exactly the accepted task paths; inspect staged scope and content to exclu
 After acceptance, Orchestrator creates the focused local commit without additional user commit approval.
 After Orchestrator accepts a task, the next action is the required Git state/scope checks, staging, and focused commit.
 Do not commit before task acceptance or defer the task commit until the plan ends.
-Only Orchestrator accepts the task and executes its focused commit; Coder completion does not replace acceptance.
+Only Orchestrator accepts the task and executes its focused commit; Implementer completion does not replace acceptance.
 Existing plan-skip paths have no new automatic commit obligation; their commits follow applicable guidance and user requests.
 Commit one logical task promptly, using Conventional Commits with a concise English description.
 Task acceptance/commit is distinct from final plan acceptance; remaining final checks and Reviewer timing follow verification.
-Planning documents have their own batch docs commit before Coder handoff.
+Planning documents have their own batch docs commit before Implementer handoff.
 
 After commit, verify exact SHA, subject, included paths, branch/HEAD and remaining index/worktree state.
 Preserve unrelated changes; never automatically unstage, amend, reset, clean, stash, or delete branches.
 On failure, stop dependent work and report actual state and completed steps.
 MUST NOT blindly repeat a commit or staging command.
 Push, merge, publish, deploy, and install still follow their separate guidance and approval rules.
-Coder must not commit, even when explicitly assigned.
+Implementer must not commit, even when explicitly assigned.
 
 Hold the task commit for unmet or unresolved criteria, failed or not-run required checks, undispositioned findings or
 evidence gaps, scope expansion, ownership or staged scope/content mismatch, unexpected workspace/branch/HEAD/Git state,
@@ -27,11 +27,11 @@ commit. If commit creation is unclear, stop and inspect before any retry (see gi
 For a no-change task make no empty commit; record acceptance evidence and no change.
 On resume verify the same task's existing commit SHA, content, and validity and reuse it; never duplicate a successful
 task commit. For final Reviewer findings on already committed plan work, Orchestrator defines a follow-up task and required
-planning/approvals. Coder leaves corrections uncommitted during rechecks. Orchestrator refreshes the latest committed
+planning/approvals. Implementer leaves corrections uncommitted during rechecks. Orchestrator refreshes the latest committed
 state plus uncommitted diff and changed-file list in the Reviewer artifact/brief. Reuse an independent Reviewer or
-assign another independent Reviewer as needed. Repeat Coder → Reviewer without QA reassignment until findings are
+assign another independent Reviewer as needed. Repeat Implementer → Reviewer without QA reassignment until findings are
 resolved; Orchestrator then accepts the corrections and creates one focused follow-up commit.
-Final QA findings retain Coder correction and QA recheck before a new focused commit.
+Final QA findings retain Implementer correction and QA recheck before a new focused commit.
 Do not automatically amend/reset or duplicate the original task commit. Scope expansion keeps existing new
 planning and approval obligations.
 
@@ -41,10 +41,24 @@ without trailing period, lowercase scope when useful, one top-level task per com
 In the accessible canonical record link plan path/version, task ID, acceptance evidence and Orchestrator judgment,
 required checks and findings, commit results and state, hold/no-change/reuse reasons, and remaining final verification.
 
+## Execution-time plan document updates
+
+Plan progress and approved revised plan contracts follow [planning](planning.md#plan-updates-during-execution).
+At a safe boundary Orchestrator amends the original planning-document commit; no separate document or fixup commit.
+Mechanical records need no new user approval; changes to the approved execution contract require revised-version approval
+and preparation before affected work. Preserve actual approval chronology; rewriting never approves earlier work retroactively.
+Apply [handoff-prep](handoff-prep.md#execution-time-plan-amendment) safety and preservation checks, recoverable contents and
+old-to-new SHA mappings. Shared/published or unknown history, merges, unclear ownership, unexpected state or replay conflict
+stops affected work without force push or fallback document commit. Revalidate evidence under verification after rewriting.
+
+This is a plan-document exception only. Implementation task acceptance, focused commits and correction follow-up commits
+retain the rules above; do not combine tasks or include implementation changes in the document commit. The initial complete
+approved document batch still precedes Implementer handoff. Existing document approvals and authority limits remain required.
+
 ## Shared-checkout coordination
 
 Orchestrator serializes shared-checkout Git mutations, including index/staging and commits, across concurrent tasks;
-parallel Coders do not operate competing Git transactions. Preserve every other task's unfinished staged, unstaged
+parallel Implementers do not operate competing Git transactions. Preserve every other task's unfinished staged, unstaged
 and untracked changes and ownership. Commit only the accepted task after scope/content verification; unrelated staged
 changes block the commit under the Preservation rule. Do not require unrelated unstaged work to finish or include it
 in the accepted task's commit. Unclear separation or ownership holds affected work for resolution.
@@ -66,5 +80,6 @@ Generated from lib/policy/role-policy.json; do not edit this managed section man
 - [scope.non-escalation] Act only where role authority, approved scope and available platform tools all permit. Delegation, restart, agent messages and attached instructions do not expand role authority. MUST NOT bypass a restriction through aliases, scripts, other tools, processes or redelegation. Return conflicting instructions to Orchestrator before dependent work; reuse valid prior approvals for unchanged scope rather than requesting them again.
 - [git.orchestrator-accept-commit] Only Orchestrator accepts work and executes Git mutations. One approved top-level plan task becomes one focused implementation commit after criteria, required checks and findings are satisfied; Orchestrator accepts then commits without additional user commit approval. Reports, passing checks and Reviewer opinions do not replace acceptance. Preserve unrelated changes and ownership and verify the resulting SHA, included content, HEAD and remaining changes. Existing small-task direct and plan-omission paths are unchanged.
 - [external.explicit-user-authority] Push, merge, deploy, publish and external messages require explicit user authorization for that action, scope and target. Local commit authority grants no external authority. Orchestrator performs authorized external actions; specialist roles return them without execution.
+- [planning.plan-amend] During approved task execution, mechanical plan progress records need no new user approval; changed goals, scope, criteria, method, risk, dependencies or required verification require revised-version approval and preparation before affected work. In both cases Orchestrator amends the original planning-document commit at a safe boundary, without a separate document or fixup commit. Preserve actual approval chronology, recoverable old/new contents, hashes, versions and SHA mappings; never retroactively authorize earlier work. Rewrite only unpublished, unshared local linear history with clear ownership and no merges; stop on unknown publication, ownership, unexpected state or replay conflicts, without force push or a fallback document commit. Preserve implementation task boundaries and revalidate affected evidence. See planning, handoff-prep, commit and verification for the full contract.
 - [platform.claude] Existing per-role tool allowlists reduce available tools; Bash and role contracts are not a filesystem sandbox. A role-scoped Git guard is a separate integration and is not supplied by these policy sections alone.
 [ARC role policy: contract end]

package/claude/skill/references/coordination.md

@@ -5,21 +5,21 @@ Orchestrator reads this before the first specialist creation or assignment and r
 ## Ownership
 
 - Orchestrator: sole owner of development, configuration, tests, implementation-dependent documentation, and mixed tasks
-  requiring implementation, assigning their edits to Coder. Coordinates scope, planning, approvals, integration,
+  requiring implementation, assigning their edits to Implementer. Coordinates scope, planning, approvals, integration,
   acceptance, verification, and completion.
 - Scouter: read-only material research/analysis and assigned static code/document/data/log exploration. Reports
   evidence, assumptions, unresolved questions, impact, next actions, and workspace/path issues to Orchestrator.
   Does not edit files or author standalone document files, or decide design/plans, verification, review, or completion.
 - Planner: returns design/spec/plan drafts.
-- Coder edits assigned, approved implementation/configuration/test-code files and assigned dependent docs.
+- Implementer edits assigned, approved implementation/configuration/test-code files and assigned dependent docs.
   Orchestrator does not edit
   them directly except under the Orchestrator direct path for small tasks.
 - QA: verifies without edits.
 - Reviewer: independently reviews the final full change.
-- All five roles report directly to Orchestrator at depth 2: Scouter, Planner, Coder, QA, and Reviewer.
+- All five roles report directly to Orchestrator at depth 2: Scouter, Planner, Implementer, QA, and Reviewer.
   Orchestrator is depth 1.
   Depth-2 roles cannot create agents or delegate tasks to another role. Reviewer remains independent.
-- Claude native subagent names: Scouter=`arc-scouter`, Planner=`arc-planner`, Coder=`arc-coder`, QA=`arc-qa`,
+- Claude native subagent names: Scouter=`arc-scouter`, Planner=`arc-planner`, Implementer=`arc-implementer`, QA=`arc-qa`,
   Reviewer=`arc-reviewer`.
 - Across the full tree, obey configured limits for simultaneous subagents, including Scouter; there are no reserved slots.
   Before first creation, read `references/limits.md` and installed `limits.toml`; maintain its cumulative ledger and reservations.
@@ -43,7 +43,7 @@ adds no agents or authority. Map executor requests such as `superpowers:executin
 `superpowers:subagent-driven-development` to Orchestrator's dependency-aware coordination and risk-scaled verification;
 this replaces executor mechanics and any separate execution-method choice, including prompts in an existing local reference.
 Preserve plan approval, workspace, design, spec, and other applicable requirements, including TDD subject to the
-explicit ARC exception in [handoff](handoff.md#coder-tdd-and-constraints). Adapt local `brainstorming` role, save, and early spec commit instructions to
+explicit ARC exception in [handoff](handoff.md#implementer-tdd-and-constraints). Adapt local `brainstorming` role, save, and early spec commit instructions to
 ARC Planner ownership and evidence gates in planning/handoff; preserve upstream reference content. Report conflicts or
 missing required local references before dependent work.
 
@@ -51,13 +51,13 @@ Planner, Reviewer, and Scouter return findings, relevant questions, next actions
 Orchestrator. Planner preserves complete requested drafts. Orchestrator integrates results (save, route,
 obtain approval; never author), routes decisions and required approvals,
 and owns development acceptance and completion. Orchestrator coordinates dependent implementation tasks sequentially and
-starts a fresh Coder for each top-level task (Role gate); reuse the current Coder only for corrections, rework,
+starts a fresh Implementer for each top-level task (Role gate); reuse the current Implementer only for corrections, rework,
 or rechecks of the same task while the approved scope, workspace, ownership, and relevant assignment context remain valid;
-default to the current Coder for same-task QA corrections. A QA finding within the current task does not itself create
-a new task. Before sending corrections or rework to a reused Coder, Orchestrator rechecks workspace, branch/HEAD and change state against the brief.
+default to the current Implementer for same-task QA corrections. A QA finding within the current task does not itself create
+a new task. Before sending corrections or rework to a reused Implementer, Orchestrator rechecks workspace, branch/HEAD and change state against the brief.
 Replace or restart a role only when its context is invalid or unavailable, or the task boundary changes, subject to the
-amendment exception below. A fresh Coder for the next task is a restart under handoff (choice reuse and restart brief rules are in handoff).
-After an approved plan or acceptance-criteria amendment, start a fresh Coder for
+amendment exception below. A fresh Implementer for the next task is a restart under handoff (choice reuse and restart brief rules are in handoff).
+After an approved plan or acceptance-criteria amendment, start a fresh Implementer for
 the remaining work even within the same task; it is also a restart under handoff. Do not add per-task QA or
 review gates solely because a task boundary exists; apply risk requirements and specific approved obligations. If the
 next task depends on a still-unverified risky contract, complete applicable QA at that dependency boundary and
@@ -84,15 +84,22 @@ resolve or explicitly disposition findings before dependent implementation. This
   never use a context-inheriting fork (such as the `fork` subagent type) for an ARC role; do not claim fresh context
   isolation without evidence. Reuse an existing specialist for related follow-up with only changed facts/objective when
   its context
-  remains relevant; start fresh for unrelated or bloated context. Coder and QA freshness follow the Role gate.
-- Cite in the brief the absolute path of each required local ARC reference's SKILL.md (`test-driven-development` for Coder,
+  remains relevant; start fresh for unrelated or bloated context. Implementer and QA freshness follow the Role gate.
+- Cite in the brief the absolute path of each required local ARC reference's SKILL.md (`test-driven-development` for Implementer,
   `brainstorming`/`writing-plans` for Planner); the role Reads it before dependent work.
 - For Reviewer, Orchestrator writes the final base..HEAD diff plus changed-file list to
   `<git-common-dir>/arc/review/<slug>.diff` (same slug as the handoff record; base is the approved base HEAD recorded at
   handoff; inline when small or write denied) and cites its absolute path in the brief; Reviewer reads it and states
   limits. See verification.
-- In Coder briefs, cite the plan/spec path with the task section's line range and include only the needed excerpts,
-  acceptance criteria, and constraints; do not ask Coder to read whole plans or specs.
+- In Implementer briefs, cite the plan/spec path with the task section's line range and include only the needed excerpts,
+  acceptance criteria, and constraints; do not ask Implementer to read whole plans or specs.
+- Before formal Planner drafting, complete the stage brief using
+  [planning](planning.md#planner-drafting-preparation-and-consolidated-feedback): original requirements/criteria IDs,
+  approved and open decisions, actual target/ownership, preceding approved versions and document paths, current behavior
+  and connected policy/source/generated/runtime/installer/documentation surfaces, depth, dependencies, checks, holds and
+  exact stage deliverable. Preserve the shared brief field order. Review completeness and conflicts together; send one
+  consolidated feedback request with changed fields and `unchanged` for the rest. Preserve separate sequential design,
+  spec and plan approvals; no fixed call cap, incomplete draft acceptance or extra calls for resolved questions.
 - Before optional calls, name the unresolved question and expected artifact. Skip calls whose questions are resolved
   by available evidence or direct inspection.
 - Run each ARC role as a foreground Agent call and use its returned result, or run it in the background and wait for the
@@ -116,7 +123,7 @@ resolve or explicitly disposition findings before dependent implementation. This
 
 Orchestrator briefs absolute paths under the selected installed ARC directory: Planner reads
 `references/superpowers/brainstorming/SKILL.md` and `references/superpowers/writing-plans/SKILL.md`;
-Coder reads `references/superpowers/test-driven-development/SKILL.md`, including required relative references.
+Implementer reads `references/superpowers/test-driven-development/SKILL.md`, including required relative references.
 Resolve paths within each skill directory. Runtime needs no global discovery, external Skill invocation, or automatic download.
 Missing/damaged local files stop dependent work: report exact paths to Orchestrator, without global fallback.
 ARC approval, ownership, TDD exceptions and executor adapters still apply.
@@ -125,7 +132,7 @@ ARC approval, ownership, TDD exceptions and executor adapters still apply.
 ## Models
 
 `models.toml` beside this skill is the source of truth for role model and reasoning-effort settings.
-Configuration keys `arc_scouter`, `arc_planner`, `arc_coder`, `arc_qa`, and `arc_reviewer` map to the hyphenated
+Configuration keys `arc_scouter`, `arc_planner`, `arc_implementer`, `arc_qa`, and `arc_reviewer` map to the hyphenated
 Claude native subagent names above; they are not tool-call names.
 Orchestrator uses the current conversation model. Use configured role settings without substitution or effort
 reduction; report unavailable settings.
@@ -144,8 +151,8 @@ Generated from lib/policy/role-policy.json; do not edit this managed section man
 - [git.specialists-deny] Specialist roles MUST NOT change Git state: no stage, commit, push, merge, rebase, reset, branch creation/switching or worktree creation/removal, during normal implementation or recovery. Even an explicit Orchestrator assignment cannot authorize these actions; return them to Orchestrator. Read-only Git inspection remains allowed within the assigned scope.
 - [role.scouter-read-only] Research assigned static sources and report findings, evidence and limits. Do not edit files, install, execute checks, prepare execution targets, inspect live operational state, change external state or decide design, verification, review or acceptance.
 - [role.planner-draft-only] Return design/spec/plan drafts and dependencies, criteria, hold conditions and verification needs in the response. MUST NOT save documents, implement, run checks, prepare targets, request user approval or decide acceptance. Stop formal target-dependent drafting if actual prepared target evidence is missing; route decisions to Orchestrator.
-- [role.coder-implementation] Edit only assigned, approved files and run focused checks under the existing TDD contract. Report changed files, RED/GREEN or authorized exception evidence, results, limits and follow-up. Do not plan, independently QA/review your own work, accept the task or declare overall completion. Git changes remain forbidden even when implementation succeeds.
-- [role.qa-verification] Run approved checks and report commands, observations, reproduction, evidence and limits. Create only essential temporary data/logs/reports in the brief-authorized location and lifetime. Do not edit product source, tests, fixtures or configuration to pass checks, deploy or accept work. Persistent product-state checks require explicit scope and cleanup ownership. Return failures for Coder correction and required QA recheck.
+- [role.implementer-implementation] Edit only assigned, approved files and run focused checks under the existing TDD contract. Report changed files, RED/GREEN or authorized exception evidence, results, limits and follow-up. Do not plan, independently QA/review your own work, accept the task or declare overall completion. Git changes remain forbidden even when implementation succeeds.
+- [role.qa-verification] Run approved checks and report commands, observations, reproduction, evidence and limits. Create only essential temporary data/logs/reports in the brief-authorized location and lifetime. Do not edit product source, tests, fixtures or configuration to pass checks, deploy or accept work. Persistent product-state checks require explicit scope and cleanup ownership. Return failures for Implementer correction and required QA recheck.
 - [role.reviewer-independent] Independently inspect the assigned final changes and evidence and report actionable findings and limits. Remain read-only. MUST NOT execute QA tests, edit files, perform Git mutations or decide acceptance.
 - [platform.claude] Existing per-role tool allowlists reduce available tools; Bash and role contracts are not a filesystem sandbox. A role-scoped Git guard is a separate integration and is not supplied by these policy sections alone.
 [ARC role policy: contract end]

package/claude/skill/references/git-recovery.md

@@ -20,7 +20,7 @@ recovery material.
 ## Branch collision and invalid names
 
 For an invalid name, branch creation/switch failure, lookup error, or unexpected current branch, inspect and record the
-error and actual Git state, then stop Coder handoff. A branch created without a successful switch is partial completion:
+error and actual Git state, then stop Implementer handoff. A branch created without a successful switch is partial completion:
 report it, never delete it automatically, and do not treat preparation as complete.
 Do not fall back to another branch or checkout. A new collision suffix requires fresh user approval of the candidate
 (handoff-prep). Existing staged/unstaged/untracked changes stay preserved; if they block a switch or ownership is

package/claude/skill/references/handoff-prep.md

@@ -40,11 +40,11 @@ After branch creation/switch verify actual absolute path, branch, HEAD and prese
 After staging verify index paths and diff before commit; unrelated staged files block the mutation. Stop and inspect
 on failure or partial completion, record actual state and completed steps, and revalidate affected gates after resolution.
 
-Batch-commit all remaining approved planning documents together in one focused docs commit before the first Coder
+Batch-commit all remaining approved planning documents together in one focused docs commit before the first Implementer
 handoff. Stage only those document paths and verify the staged content and scope.
 Verify the resulting SHA, subject, paths, branch, HEAD and remaining state. Already committed approved documents need no
 duplicate commit. Record the actual preparation order and deviations, then complete the handoff gate before the
-next Coder start. User authorization persists for the unchanged approved target and scope; do not repeatedly ask for the
+next Implementer start. User authorization persists for the unchanged approved target and scope; do not repeatedly ask for the
 same choice.
 
 ## New task branch naming
@@ -85,11 +85,34 @@ Never amend, reset, or recommit past commits to merge them. Skip the commit only
 produced, recording the depth rationale; uncommitted documents are not absent. Never include implementation files.
 After success verify SHA, message, paths, HEAD, branch, and remaining state; the commit is not push approval.
 
+## Execution-time plan amendment
+
+After the initial approved document batch, execution-time plan updates use
+[planning](planning.md#plan-updates-during-execution), including approved scope revisions. Do not batch these as another
+document commit. This exception does not combine historical document commits or rewrite implementation task contents.
+
+Before mutation, verify the original planning-document commit is an ancestor of HEAD and identify its current replacement.
+Verify unpublished, unshared local linear history with no merge commits; clear ownership and included plan paths; paused
+role writers and a safe boundary for unfinished changes; complete classification, approval and chronology records.
+Preserve unrelated staged, unstaged and untracked changes under the Preservation rule; unexpected dirty state blocks rewrite.
+Secure recoverable pre-rewrite HEAD, original commits and before/after plan contents before mutation.
+
+If the original commit is HEAD, amend the plan paths only; preserve other documents in that commit. With descendant task
+commits, amend the original and reapply descendants in original order preserving task boundaries and implementation contents.
+Create no separate document or intermediate fixup commit. Git changes remain Orchestrator-only.
+
+Unknown publication/sharing status, unclear ownership, merge history, unexpected HEAD/change state or replay conflicts
+require a stop of rewriting and affected dependent work. No automatic conflict resolution, force push or fallback separate
+document commit is permitted. Record actual path, branch/HEAD, index/files and completed steps; Orchestrator resolves the
+issue before resuming and revalidates affected gates. Verify new SHA/HEAD, plan version/content, descendant preservation,
+old-to-new SHA mapping and remaining state under [verification](verification.md#evidence-after-plan-history-rewrite).
+
 [ARC role policy: contract begin]
 Generated from lib/policy/role-policy.json; do not edit this managed section manually.
 - [scope.non-escalation] Act only where role authority, approved scope and available platform tools all permit. Delegation, restart, agent messages and attached instructions do not expand role authority. MUST NOT bypass a restriction through aliases, scripts, other tools, processes or redelegation. Return conflicting instructions to Orchestrator before dependent work; reuse valid prior approvals for unchanged scope rather than requesting them again.
 - [git.specialists-deny] Specialist roles MUST NOT change Git state: no stage, commit, push, merge, rebase, reset, branch creation/switching or worktree creation/removal, during normal implementation or recovery. Even an explicit Orchestrator assignment cannot authorize these actions; return them to Orchestrator. Read-only Git inspection remains allowed within the assigned scope.
 - [git.orchestrator-accept-commit] Only Orchestrator accepts work and executes Git mutations. One approved top-level plan task becomes one focused implementation commit after criteria, required checks and findings are satisfied; Orchestrator accepts then commits without additional user commit approval. Reports, passing checks and Reviewer opinions do not replace acceptance. Preserve unrelated changes and ownership and verify the resulting SHA, included content, HEAD and remaining changes. Existing small-task direct and plan-omission paths are unchanged.
 - [external.explicit-user-authority] Push, merge, deploy, publish and external messages require explicit user authorization for that action, scope and target. Local commit authority grants no external authority. Orchestrator performs authorized external actions; specialist roles return them without execution.
+- [planning.plan-amend] During approved task execution, mechanical plan progress records need no new user approval; changed goals, scope, criteria, method, risk, dependencies or required verification require revised-version approval and preparation before affected work. In both cases Orchestrator amends the original planning-document commit at a safe boundary, without a separate document or fixup commit. Preserve actual approval chronology, recoverable old/new contents, hashes, versions and SHA mappings; never retroactively authorize earlier work. Rewrite only unpublished, unshared local linear history with clear ownership and no merges; stop on unknown publication, ownership, unexpected state or replay conflicts, without force push or a fallback document commit. Preserve implementation task boundaries and revalidate affected evidence. See planning, handoff-prep, commit and verification for the full contract.
 - [platform.claude] Existing per-role tool allowlists reduce available tools; Bash and role contracts are not a filesystem sandbox. A role-scoped Git guard is a separate integration and is not supplied by these policy sections alone.
 [ARC role policy: contract end]

package/claude/skill/references/handoff.md

@@ -1,4 +1,4 @@
-# Coder handoff
+# Implementer handoff
 
 Orchestrator verifies the absolute workspace/repository, branch or detached HEAD, HEAD, staged/unstaged/untracked state,
 ownership, document approvals and committed planning documents before first start and restart.
@@ -6,7 +6,7 @@ The approved execution target must remain valid. Claude v1 supports current chec
 ARC-managed worktrees.
 
 Execution-target choice and actual preparation precede formal drafting and saving of required specs/plans.
-Initial design proposals may precede choice. Initial target preparation does not authorize Coder; all applicable
+Initial design proposals may precede choice. Initial target preparation does not authorize Implementer; all applicable
 approvals, complete documents, verified batch docs commits or valid absence, and final Git verification remain required.
 Record planned document scope/paths and actual preparation separately, followed by actual drafting/save/approval and
 commit results; preserve actual order and evidence gaps. Reuse a valid choice during document drafting and subsequent
@@ -23,18 +23,18 @@ explicit target choice; prior and resulting Git state; document commit SHA/subje
 checks and limits. If a gate or record was late, record actual order and resolve forward; never claim retroactive
 compliance.
 
-The Coder brief supplies absolute workspace, verified branch/HEAD, canonical record path, approved task/criteria,
+The Implementer brief supplies absolute workspace, verified branch/HEAD, canonical record path, approved task/criteria,
 exact file ownership, expected tests, dependency limits and blocked conditions. Restart brief: supply only verified
-deltas and mark unchanged fields; `unchanged` means unchanged relative to the record file the fresh Coder reads,
-and every other brief field is in full. Coder trusts Orchestrator verified prep rather than independently repeating
+deltas and mark unchanged fields; `unchanged` means unchanged relative to the record file the fresh Implementer reads,
+and every other brief field is in full. Implementer trusts Orchestrator verified prep rather than independently repeating
 approval/Git evidence checks, reads fields marked unchanged, and stops on an actual observed conflict.
-Tell Coder that others share the repository and unrelated work MUST be preserved.
+Tell Implementer that others share the repository and unrelated work MUST be preserved.
 
 Roles report directly to Orchestrator. Do not delegate at depth 2. Orchestrator sequences dependent work,
 resolves actual blockers and revalidates affected gates before resume. No automatic retry after unexpected Git or tool
 failure.
 
-If the record write is denied or unavailable, Orchestrator carries the full record inline in every Coder brief (no
+If the record write is denied or unavailable, Orchestrator carries the full record inline in every Implementer brief (no
 delta, no record-file `unchanged`) and states why; that satisfies the accessible-record requirement.
 Do not delete it automatically.
 
@@ -48,7 +48,7 @@ cannot bypass its approval gate.
 
 Before assignment, apply every readiness condition in
 [planning.md, Dependency and readiness record](planning.md#dependency-and-readiness-record), including predecessor
-checks, Orchestrator acceptance and verified focused commit or accepted no-change evidence. A Coder completion report
+checks, Orchestrator acceptance and verified focused commit or accepted no-change evidence. A Implementer completion report
 alone is insufficient. Verify the linked record is current and capacity and file ownership permit assignment.
 Readiness supplements the full handoff gate and execution-target restrictions; it never waives them.
 For authorized HEAD or state changes, refresh this record and affected briefs, verify preservation and ownership,
@@ -76,7 +76,7 @@ its scope, criteria, constraints, and valid document-depth omissions alongside e
 Reuse valid authorization for the same approved scope and target. A restart or new role assignment does not require
 repeat approval. Reuse never waives verification of actual workspace/repository, branch or detached HEAD, HEAD,
 changes, preservation, ownership, applicable documents, and preparation evidence by Orchestrator. Refresh actual state
-and affected briefs for authorized changes; they alone do not invalidate approval. Coder trusts the verified brief
+and affected briefs for authorized changes; they alone do not invalidate approval. Implementer trusts the verified brief
 under its profile. Material scope/method/risk changes and invalid target evidence hold affected work; resolve using
 planning and the choice-lifetime rules above. Report the missing condition and resume evidence rather than asking
 for an approval already valid for that scope.
@@ -85,13 +85,13 @@ Before any exception judgment, Orchestrator reads [Risk-scaled execution](verifi
 
 ## Common handoff gate
 
-Before every Coder first start/restart, Orchestrator passes the full gate:
+Before every Implementer first start/restart, Orchestrator passes the full gate:
 applicable approvals/artifacts or valid omissions, explicit execution-target choice
 or verified reuse, intended accessible repository/workspace, actual Git identity/state, preservation/ownership,
 verified document commits or valid absence, and no unresolved failure/partial completion.
 Missing evidence, mismatches, unclear ownership or unresolved preparation block handoff and require Orchestrator
 resolution and full revalidation. Handoff owns the evidence fields, canonical handoff record, restart brief, choice lifetime
-and reuse. Coder trusts the Orchestrator-verified brief and reports actual conflicts under its self-contained profile;
+and reuse. Implementer trusts the Orchestrator-verified brief and reports actual conflicts under its self-contained profile;
 never replace its local guards with a requirement to load Orchestrator procedures.
 Depth-2 roles use the supplied workspace and report path/state conflicts; they cannot create/switch workspaces or
 branches. The same conditions apply before an Orchestrator direct edit.
@@ -100,12 +100,12 @@ approved document preparation under [handoff-prep](handoff-prep.md).
 ARC-managed worktree execution is unsupported; report an isolated worktree request before dependent work.
 
 
-## Coder TDD and constraints
+## Implementer TDD and constraints
 
-Before feature, bug-fix, or behavior edits, Coder follows local `test-driven-development` unless the explicit
-ARC exception applies; the Coder profile holds Coder's full TDD rules. TDD is waived only when every small,
+Before feature, bug-fix, or behavior edits, Implementer follows local `test-driven-development` unless the explicit
+ARC exception applies; the Implementer profile holds Implementer's full TDD rules. TDD is waived only when every small,
 low-risk criterion (Risk-scaled execution) and every plan-skip criterion (Orchestrator direct path) holds.
-Before Coder starts,
+Before Implementer starts,
 Orchestrator records the scope, why every criterion is met, acceptance criteria, and focused verification in the brief.
 An explicit user or task-specific TDD request overrides
 this waiver. For qualifying tasks only, this exception takes precedence over the generic trigger in the local reference;
@@ -122,7 +122,7 @@ generalize it to behavior work.
 Orchestrator may edit directly only when every small, low-risk criterion (Risk-scaled execution) holds.
 Every plan-skip criterion must also hold: one local change, no dependent stages, no cross-component shared state,
 lifecycle, or integration-order concerns, and one focused verification path. Significant, architectural,
-ordinary-behavior, unclear-risk work and edits overlapping a running Coder's assigned files are ineligible.
+ordinary-behavior, unclear-risk work and edits overlapping a running Implementer's assigned files are ineligible.
 
 Significant risk is defined in Risk-scaled execution and excludes work from the Orchestrator direct path;
 do not infer eligibility from a small file count.
@@ -132,30 +132,122 @@ why every criterion holds, acceptance criteria, and focused verification. Apply
 [planning](planning.md#authorization-and-scope): an existing sufficiently specific user request can approve
 that scope; no duplicate approval is needed. Otherwise present the scope record to the user and obtain explicit
 approval before editing. Silence, an ambiguous response, or approval of other work is not approval.
-Orchestrator then verifies the same handoff gate as a Coder first start: explicit execution-target choice or valid
+Orchestrator then verifies the same handoff gate as a Implementer first start: explicit execution-target choice or valid
 reuse, accessible intended workspace and repository, branch or detached HEAD, HEAD, staged/unstaged/untracked state,
 preservation and ownership, and no unresolved failure or partial completion. Read this reference
 and [handoff preparation](handoff-prep.md) before checking this gate.
 
 Orchestrator edits only the approved files, preserves others' edits, and makes surgical changes without unrelated
-refactoring or unapproved dependencies. Behavior edits follow the Coder TDD rules and applicable recorded waiver
+refactoring or unapproved dependencies. Behavior edits follow the Implementer TDD rules and applicable recorded waiver
 criteria; an explicit user or task-specific TDD request still requires test-driven-development.
 Do not claim TDD under a waiver. After editing, Orchestrator records changed files, runs focused checks,
 connects each acceptance criterion to evidence, and reports unverified scope. Orchestrator is not an independent
 reviewer of its own edits; assign QA when evidence is incomplete. If scope expands, risk becomes unclear,
-or any criterion fails, stop editing, record completed changes, and return subsequent edits to the normal Planner/Coder
-flow. A failed focused check or a QA finding routes the correction to Coder, and it is rechecked; Orchestrator does not
+or any criterion fails, stop editing, record completed changes, and return subsequent edits to the normal Planner/Implementer
+flow. A failed focused check or a QA finding routes the correction to Implementer, and it is rechecked; Orchestrator does not
 self-correct.
 
 Like other plan-skip paths, there is no automatic task commit; commits follow applicable guidance and user requests.
 
 
+## Cooperative CLI verification handoff
+
+For the supported spec+plan path, the verification handoff includes the registered task contract, exact check descriptor,
+task/final scope, `status.changeFingerprints`, independent actor attestations, intent ID, result messageRef and verdict.
+An externally authorized role performs each check/review after `prepare`, and records the actual result through `result`.
+CLI records do not authenticate identities or prove actual agent policy compliance.
+
+When scope, documents or approvals change, inspect `affectedTaskIds` and the dependency chain, preserve earlier approval and
+result records, and hand off new approvals and contracts for affected tasks. Do not reuse an old passing check for a different fingerprint.
+Link failed findings to the assigned Implementer's resolution evidence and QA rechecks for that change version. Only final overall Reviewer
+findings use Implementer→Reviewer revalidation. Do not add Reviewer as a prerequisite for individual task acceptance or commits.
+Follow [verification.md](verification.md#verification-lifecycle-in-the-cooperative-cli) for detailed fields and hold conditions.
+An unsupported no-plan/omission path does not imply a policy violation or a requirement to write documents.
+
 [ARC role policy: contract begin]
 Generated from lib/policy/role-policy.json; do not edit this managed section manually.
 - [git.specialists-deny] Specialist roles MUST NOT change Git state: no stage, commit, push, merge, rebase, reset, branch creation/switching or worktree creation/removal, during normal implementation or recovery. Even an explicit Orchestrator assignment cannot authorize these actions; return them to Orchestrator. Read-only Git inspection remains allowed within the assigned scope.
-- [role.coder-implementation] Edit only assigned, approved files and run focused checks under the existing TDD contract. Report changed files, RED/GREEN or authorized exception evidence, results, limits and follow-up. Do not plan, independently QA/review your own work, accept the task or declare overall completion. Git changes remain forbidden even when implementation succeeds.
-- [review.significant-no-plan] For significant/high-risk work without a plan: Coder → QA and required QA rechecks → Reviewer of the final full change → Orchestrator acceptance. MUST NOT omit Reviewer merely because no plan exists. This creates no new plan obligation.
-- [review.significant-plan] For significant/high-risk plan work: each task uses Coder → fresh QA as required → Orchestrator acceptance and focused commit. After all tasks are accepted and required QA is complete, Reviewer reviews the final full change once. Reviewer is NOT a per-task or per-commit required gate. Preserve required checks and necessary finding rechecks.
-- [review.final-plan-recheck] For final overall Reviewer findings on plan work, including behavior findings, use Coder → Reviewer without QA reassignment; repeat until resolved. This exception applies only at the final plan stage. Preserve required QA and QA failure rechecks before initial final review and outside this exception.
+- [role.implementer-implementation] Edit only assigned, approved files and run focused checks under the existing TDD contract. Report changed files, RED/GREEN or authorized exception evidence, results, limits and follow-up. Do not plan, independently QA/review your own work, accept the task or declare overall completion. Git changes remain forbidden even when implementation succeeds.
+- [review.significant-no-plan] For significant/high-risk work without a plan: Implementer → QA and required QA rechecks → Reviewer of the final full change → Orchestrator acceptance. MUST NOT omit Reviewer merely because no plan exists. This creates no new plan obligation.
+- [review.significant-plan] For significant/high-risk plan work: each task uses Implementer → fresh QA as required → Orchestrator acceptance and focused commit. After all tasks are accepted and required QA is complete, Reviewer reviews the final full change once. Reviewer is NOT a per-task or per-commit required gate. Preserve required checks and necessary finding rechecks.
+- [review.final-plan-recheck] For final overall Reviewer findings on plan work, including behavior findings, use Implementer → Reviewer without QA reassignment; repeat until resolved. This exception applies only at the final plan stage. Preserve required QA and QA failure rechecks before initial final review and outside this exception.
 - [platform.claude] Existing per-role tool allowlists reduce available tools; Bash and role contracts are not a filesystem sandbox. A role-scoped Git guard is a separate integration and is not supplied by these policy sections alone.
 [ARC role policy: contract end]
+
+## Initial Implementer assignment through the cooperative CLI
+
+In approved plan mode, Orchestrator performs the following sequence. All mutation commands pass JSON through stdin with
+`node "$ARC_RUNTIME_ENTRY" <command> --cwd "$ARC_CHECKOUT" --workflow "$ARC_WORKFLOW_ID" --input -`.
+Resolve `ARC_RUNTIME_ENTRY` from the actual ARC skill directory selected by the installation resolver:
+`<target-home>/skills/arc/runtime/cli.mjs`. Use the loaded skill's location, including a custom target home;
+do not guess the default home or use a package, checkout or cache entry. Pass the resolved path, checkout and
+workflow ID as separate argv values when using a process API. In a shell, assign values safely and double-quote
+these variables; never interpolate paths into executable shell text or use `eval`.
+Query `status` without `--input`.
+
+The entry preserves the cooperative state path in the selected checkout's Git common directory. Installing or
+updating the entry does not migrate state or renew approvals. Runtime/hash, target, actor and revision checks still
+apply: runtime drift holds existing evidence; obtain the required current evidence and approval through the
+existing recovery procedure. A new workflow cannot retroactively validate earlier execution.
+
+1. Prepare the docs-only commit of the approved spec and plan, and verify the exact document set, objects and current files.
+   Perform `init`, approval `record` and `prepare` only after this commit verification, even when user approval preceded the document commit.
+2. After document commit verification, pass `mode: "plan"`, `actor: {id: "operator"}` and `selection: {messageRef, contentHash}` to `init` at the final target HEAD.
+3. Use `record` to persist the user approval attestation already confirmed. The input is
+   `{requestId, expectedRevision, actor, evidence: {kind: "approval", messageRef, data: {approvalVersion, documentVersion, documents}}}`.
+   `documents` contains exactly the spec and plan, each with `{kind, path, gitPath, contentHash, approvalRef, commit}`.
+   `contentHash` is `sha256:<hex>`, and `approvalRef` must match the approval `messageRef`.
+   On HEAD drift, record a fresh target observation and renewed approval instead of reconnecting an earlier intent.
+4. Pass `{requestId, expectedRevision, actor, operation: "assign-agent", taskId, arguments: {role: "implementer", paths, operations: ["edit"], documents, approvalRef, approvalVersion, documentVersion, correlation}}` to `prepare`.
+   Absolute `paths` must be inside the checkout. Confirm `allow`, `persisted: true` and the persisted intent.
+5. Invoke the native assignment with the task, scope and correlation from the persisted intent.
+6. Pass `{requestId, expectedRevision, actor, intentId, result: {status, messageRef, data: {correlation, taskId, agentId}}}` to `result`.
+   `intentId` is the prepare requestId. Distinguish success as `succeeded`, failure as `failed`, uncertain execution as `unknown` and a response mismatch as `mismatch`.
+   Success requires the returned agent ID. `unknown`/`mismatch` causes a hold; stop duplicate assignments and investigate the actual result.
+
+Approval and assignment results on this path are `operator-attested`. They do not authenticate native identities or verify platform events.
+The CLI cannot block direct calls outside it, and a new workflow cannot legitimize omitted past execution. Existing trusted adapter provenance requirements remain in force.
+
+
+## External operations and recovery in the cooperative CLI
+
+The three phases support state, documents and assignment; scope, verification, acceptance and focused commits; and external approval, results and audit recovery.
+Use `status.support` to inspect all nine areas and their limits. The supported mode is `plan` with spec+plan; no-plan and omission are unsupported. The CLI does not execute native/provider calls or push, merge, deploy or publish.
+User approvals and execution results confirmed by the operator are `operator-attested`, with `nativeVerified: false` and
+`remoteVerified: false`. Blocking direct calls outside the CLI and independent remote verification are not provided.
+
+Orchestrator records an explicit approval it has already confirmed through `record` with
+`evidence: {kind: "external-approval", messageRef, data: {operation, scope, descriptor}}`.
+`scope` is an array of unique absolute paths within the checkout. Local commit approval does not authorize external operations.
+Include the exact action, scope and target in the approval, and record every descriptor field below.
+
+| operation | descriptor fields |
+|---|---|
+| push | repository, destination, refspec, sourceOid, expectedRemoteOid |
+| merge | repository, changeRef, targetRef, expectedTargetOid |
+| deploy | service, project, environment, artifactId, destination |
+| publish | service, namespace, name, version, artifactHash, destination |
+
+Git OIDs are full 40/64-character lowercase hex values; artifactHash is `sha256:<64-hex>`. Without a remote observation,
+an OID is an expected value asserted by the user, not verified remote state. destination must be an identifier without secrets.
+Do not submit URL userinfo, query or fragment components, or authentication information such as passwords, tokens or credentials.
+The CLI rejects recognized credential inputs before persistence, but cannot determine whether every arbitrary string contains a secret.
+
+Pass `{requestId, expectedRevision, actor: {id, role: "orchestrator"}, operation,
+arguments: {approvalRef, scope, descriptor}}` to `prepare`. approvalRef matches the external approval messageRef.
+An intent is persisted only when the exact approval, scope/target versions and runtime version match and no effect is unresolved.
+After confirming `allow` and `persisted: true`, Orchestrator performs the external operation within its separately approved scope.
+This CLI does not expand that execution authority.
+
+`result`/`reconcile` accepts `{requestId, expectedRevision, actor, intentId,
+result: {status, messageRef, data: {operation, scope, descriptor}}}`. intentId is the prepare requestId.
+Target mismatches, unknown outcomes and stale results cause a hold while preserving earlier attestations. After an interruption,
+use `status` to inspect the intent, `state.requests`, `state.audit` and `state.results`, and investigate whether the effect occurred.
+Reconcile the investigation result against the same intent rather than preparing again or reusing the same approval to execute again.
+Cancellation additionally requires a `notExecutedEvidence: {messageRef}` attestation that the operation was not executed.
+The approval remains consumed after cancellation. Do not resolve version drift through automatic updates, migration or renewed permission.
+Report the cause of the hold to Orchestrator.
+
+Even succeeded results are operator attestations, not independent remote verification. `audit` retains the
+request→decision→intent→result→resolution linkage, but is a locally editable record rather than tamper-proof security evidence.
+Do not retry while the actual external outcome is uncertain.