@yunhozz/arc 0.1.9 → 0.1.10

package/codex/skill/references/commit.md

@@ -11,8 +11,8 @@ acceptance criteria, currently required checks (Reviewer timing:
 creates its focused local Git 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.
-Substeps and checkboxes are progress records, not separate commit units. Checkbox completion, Coder reports, and
+Only Orchestrator accepts the task and executes its focused commit; Implementer completion does not replace acceptance.
+Substeps and checkboxes are progress records, not separate commit units. Checkbox completion, Implementer reports, and
 passing checks alone do not establish task acceptance: connect criteria's conditions and expected results to actual
 evidence. Existing plan-skip paths have no new plan obligation; their commits follow applicable guidance and user
 requests. Push, merge, publish, deploy, and install still follow their separate guidance and approval rules.
@@ -42,25 +42,39 @@ fresh state and ownership checks. Task acceptance/commit is distinct from final
 QA/Reviewer/integration checks still apply with the timing in verification.
 
 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.
 
-Local commit authority does not authorize early planning-document commits: pre-Coder document approvals,
+Local commit authority does not authorize early planning-document commits: pre-Implementer document approvals,
 explicit execution-target choice and batch preparation remain unchanged. Historical spec/plan records are not changed
 retroactively. Structural checks of this contract do not prove actual agent runtime compliance.
 Follow Conventional Commits with the message form `<type>(<scope>): <description>`. Use a concise, specific English
 description without a trailing period, a lowercase scope when useful, one top-level task's logical change per commit,
 and body/footer only when needed while preserving Git trailer syntax.
 
+## 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.
@@ -82,5 +96,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.
-- [platform.codex] Role restrictions are prompt-level contracts, not a filesystem sandbox. No documented role-specific Git hook or generic per-agent tool allowlist is assumed. Existing shell capabilities are retained because static read access after shell reduction has not been verified; Coder and QA need shell for approved checks.
+- [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.codex] Role restrictions are prompt-level contracts, not a filesystem sandbox. No documented role-specific Git hook or generic per-agent tool allowlist is assumed. Existing shell capabilities are retained because static read access after shell reduction has not been verified; Implementer and QA need shell for approved checks.
 [ARC role policy: contract end]

package/codex/skill/references/coordination.md

@@ -5,27 +5,27 @@ 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
   (save, route, obtain approval; never author), 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.
-- Aliases: Scouter=`arc_scouter`, Planner=`arc_planner`, Coder=`arc_coder`, QA=`arc_qa`, Reviewer=`arc_reviewer`.
+- Aliases: 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.
   Parallelize independent tasks only; dependent handoffs are sequential and editing scopes cannot overlap.
 - After each read-only role returns (Scouter, Planner, Reviewer), Orchestrator checks `git status` against a pre-spawn
   snapshot for unexpected changes; on any change Orchestrator stops and reports under the Preservation rule.
-  Limit: concurrent Coder edits and ignored or out-of-repo paths are not attributable/detectable.
+  Limit: concurrent Implementer edits and ignored or out-of-repo paths are not attributable/detectable.
   Their read-only status rests on prompt-level guards, not sandbox enforcement.
 
 
@@ -41,7 +41,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.
 
@@ -50,20 +50,20 @@ missing required local references before dependent work.
 
 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.
 
 Orchestrator integrates role results, 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. Task-boundary gates
 follow [Risk-scaled execution](verification.md#risk-scaled-execution).
 
@@ -86,10 +86,17 @@ follow [Risk-scaled execution](verification.md#risk-scaled-execution).
   complete. Cite paths/lines/pages/commands/links instead of logs; investigate gaps only.
 - Every specialist spawn sets `fork_turns="none"`; full-history forks are not allowed. Supply that brief.
   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.
+  remains relevant; start fresh for unrelated or bloated context. Implementer and QA freshness follow the Role gate.
 - `request_user_input` questions use only `title` and `options` fields, never `question`.
-- 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.
 - Wait for a specialist with `wait_agent` using the maximum supported timeout, repeating only until it completes; a
@@ -124,8 +131,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.codex] Role restrictions are prompt-level contracts, not a filesystem sandbox. No documented role-specific Git hook or generic per-agent tool allowlist is assumed. Existing shell capabilities are retained because static read access after shell reduction has not been verified; Coder and QA need shell for approved checks.
+- [platform.codex] Role restrictions are prompt-level contracts, not a filesystem sandbox. No documented role-specific Git hook or generic per-agent tool allowlist is assumed. Existing shell capabilities are retained because static read access after shell reduction has not been verified; Implementer and QA need shell for approved checks.
 [ARC role policy: contract end]

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

@@ -39,7 +39,7 @@ If existing changes prevent switching or ownership is unclear, stop handoff unti
 scope.
 
 For an invalid name, branch creation or switching 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
+record the error and actual Git state, then stop Implementer handoff. A branch created without a successful switch is partial
 completion: report it, do not automatically delete it, and do not treat preparation as complete. Do not automatically
 fall back to the current checkout path after an operational failure. Both operational failure and missing
 execution-target choice block handoff. Orchestrator resolves the problem and rechecks preparation before handoff.
@@ -48,7 +48,7 @@ execution-target choice block handoff. Orchestrator resolves the problem and rec
 ### Worktree failures and partial completion
 
 Worktree creation, registration, attachment, identity/base verification, checkout, document transfer, staging,
-or commit failure means stop dependent work and Coder handoff. Partial completion includes branch-only creation, partial
+or commit failure means stop dependent work and Implementer handoff. Partial completion includes branch-only creation, partial
 path creation, registration/actual-path mismatch, wrong base or branch, and partial document transfer. Record source and
 target exact command, error, branch, HEAD, Git common directory, registration, index and files, including target dirty
 state and source preservation. Before any authorized retry, inspect actual state and completed work under the Stop and

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

@@ -2,7 +2,7 @@
 
 Orchestrator reads before an execution-target choice request and each preparation Git mutation (branch creation/switch,
 staging, commit). The new managed worktree option's selection target is listed in the Execution-target request gate.
-The [Coder handoff gate](handoff.md#coder-handoff-gate), handoff evidence and choice lifetime are in [handoff.md](handoff.md).
+The [Implementer handoff gate](handoff.md#implementer-handoff-gate), handoff evidence and choice lifetime are in [handoff.md](handoff.md).
 
 ## Workspace handoff
 
@@ -126,6 +126,28 @@ Skip this commit only when no planning documents were required and none were pro
 rules; record that fact and the applicable depth rationale. Uncommitted documents cannot be treated as absent.
 This does not require new documents or bypass checkout choice or any other handoff-gate condition.
 
+### 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).
+
 ### Recovery prerequisite
 
 On branch collisions, Git preparation failures, partial completion, or metadata write denial, read
@@ -137,5 +159,6 @@ 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.
 - [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.
-- [platform.codex] Role restrictions are prompt-level contracts, not a filesystem sandbox. No documented role-specific Git hook or generic per-agent tool allowlist is assumed. Existing shell capabilities are retained because static read access after shell reduction has not been verified; Coder and QA need shell for approved checks.
+- [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.codex] Role restrictions are prompt-level contracts, not a filesystem sandbox. No documented role-specific Git hook or generic per-agent tool allowlist is assumed. Existing shell capabilities are retained because static read access after shell reduction has not been verified; Implementer and QA need shell for approved checks.
 [ARC role policy: contract end]

package/codex/skill/references/handoff-worktree.md

@@ -10,7 +10,7 @@ branch work or document transfer. Apply [handoff-prep.md](handoff-prep.md) and [
 Before formal drafting and saving, complete actual creation, managed registration, current-chat attachment,
 repository/common directory and base verification, approved branch verification, and source preservation checks below.
 The normal new-document path drafts and saves directly in the verified target. Planned destination paths are not
-preparation evidence. Initial preparation does not authorize Coder or a document commit.
+preparation evidence. Initial preparation does not authorize Implementer or a document commit.
 
 Only an explicit user choice of this third path authorizes preparation. Its selection target is the one verified
 under the Execution-target request gate in handoff-prep.md.
@@ -45,7 +45,7 @@ use mcp__codex_app__get_worktree_creation_status until completed. Preparing/crea
 success.
 For registration failure only, retry the returned workspace with mcp__codex_app__attach_worktree. Before completed
 managed registration, current-chat attachment and approved branch verification, perform no formal drafting, saving, document transfer, staging,
-commit or Coder start. If tools are unavailable, reattachment fails or results mismatch, stop and record actual state.
+commit or Implementer start. If tools are unavailable, reattachment fails or results mismatch, stop and record actual state.
 Do not fall back to raw Git worktree creation, automatically retry other name/ref/path/branch inputs,
 or perform automatic cleanup, delete, prune or archive. See git-recovery.md before dependent recovery.
 
@@ -62,7 +62,7 @@ handoff-prep.md). Do not move a branch pointer, choose another branch or use --f
 or -B.
 If the app initially returns the approved branch, verify it and its base rather than repeating completed work.
 Unexpected branch or mismatched HEAD means stop. Verify final approved branch and HEAD before formal drafting, saving, document transfer,
-the batch docs commit, final Git verification and Coder handoff.
+the batch docs commit, final Git verification and Implementer handoff.
 
 The tool does not copy uncommitted changes. The following transfer rules apply only to legacy or restart cases
 with existing approved documents (including an explicitly selected target change), not the normal new-document path. For untracked approved documents, source HEAD and index paths must be
@@ -88,4 +88,4 @@ also be absent at the destination. For unexpected changes, do not overwrite; sto
 For identical content, verify approved bytes before reuse. After transfer verify bytes match the approved version.
 The canonical record includes each document approval/version/evidence, source and target absolute paths and the common
 relative path plus content verification. Changed content or approval scope requires approval of the revised version.
-Transfer no other files. Failure or partial transfer blocks all dependent staging, commit and Coder handoff.
+Transfer no other files. Failure or partial transfer blocks all dependent staging, commit and Implementer handoff.

package/codex/skill/references/handoff.md

@@ -1,7 +1,7 @@
 # Handoff contract
 
-Orchestrator reads before every Coder first start or restart preparation. Coder trusts the Orchestrator-verified facts
-in the brief under the Coder profile and reads this file only for sections the brief explicitly cites. First-start preparation
+Orchestrator reads before every Implementer first start or restart preparation. Implementer trusts the Orchestrator-verified facts
+in the brief under the Implementer profile and reads this file only for sections the brief explicitly cites. First-start preparation
 (execution-target choice request, preparation Git mutations, planning-document commit) is in
 [handoff-prep.md](handoff-prep.md); the new managed worktree path is in [handoff-worktree.md](handoff-worktree.md).
 
@@ -9,13 +9,13 @@ in the brief under the Coder profile and reads this file only for sections the b
 
 ### Checkout approval
 
-Before every Coder first start and restart, Orchestrator confirms the supplied absolute workspace is accessible and
+Before every Implementer first start and restart, Orchestrator confirms the supplied absolute workspace is accessible and
 belongs to the intended Git repository; record its actual absolute path, current branch or detached HEAD, HEAD, and staged,
 unstaged, and untracked changes. Stop if the workspace is inaccessible, is not the intended repository, or HEAD
 cannot be resolved. Do not initialize Git or switch to another repository automatically.
 
 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
@@ -27,14 +27,14 @@ After initial design approval, obtain and record an explicit user choice for the
 Explicit choice rule: use the current checkout, create a new task branch from the verified base HEAD in that same
 checkout, or create a new managed worktree and task branch (selection target under handoff-prep.md; contract in
 handoff-worktree.md after selection). Without an explicit execution-target choice or verified valid reuse under the
-choice-lifetime rules below, wait and do not start or restart Coder.
+choice-lifetime rules below, wait and do not start or restart Implementer.
 
-### Coder handoff gate
+### Implementer handoff gate
 
-Orchestrator may start or restart Coder only after all of these conditions are verified:
+Orchestrator may start or restart Implementer only after all of these conditions are verified:
 
 1. All applicable design/spec/plan approvals are recorded with approved artifact paths or valid depth-omission reasons.
-   For a Coder Spike probe, record its approved question, method/scope, acceptance criteria, and constraints.
+   For a Implementer Spike probe, record its approved question, method/scope, acceptance criteria, and constraints.
    The complete current-scope document list, approved versions, plan dependencies/order, and absence of unfinished
    applicable documents are verified. Future implementation artifacts are not part of the probe scope or approved by it.
 2. The user explicitly selected the execution target initially, or that initial choice remains valid under the restart
@@ -52,9 +52,9 @@ Before an Orchestrator direct edit, Orchestrator verifies the same conditions, w
 applicable approval, and records them in the brief.
 
 A missing or failed condition blocks handoff. Orchestrator may continue read-only investigation and authorized
-preparation or recovery, but cannot start Coder early. Reverify affected evidence when approved content, execution target, branch,
-HEAD, or relevant state changes. Coder's conflict reporting is in its profile; Orchestrator
-resolves preparation and passes the gate again before Coder resumes.
+preparation or recovery, but cannot start Implementer early. Reverify affected evidence when approved content, execution target, branch,
+HEAD, or relevant state changes. Implementer's conflict reporting is in its profile; Orchestrator
+resolves preparation and passes the gate again before Implementer resumes.
 
 ### Handoff evidence
 
@@ -74,7 +74,7 @@ Record the Complete planning-document set fields from planning.md, confirming no
 writing/approval.
 Distinguish reused commits from the batch preparation commit, or record valid document absence.
 Record applicable approvals and the initial explicit execution-target choice or verified reuse for each first start or
-restart. Give all five roles (Coder, QA, Planner, Reviewer, Scouter) the same actual workspace and selected execution checkout or absolute
+restart. Give all five roles (Implementer, QA, Planner, Reviewer, Scouter) the same actual workspace and selected execution checkout or absolute
 worktree path, preparation evidence, and absolute artifact paths. Each role stays in the supplied workspace, reports
 missing, inaccessible, or conflicting paths and unexpected branch state to Orchestrator before dependent work, and does
 not create or switch workspaces or branches.
@@ -89,7 +89,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,
@@ -103,7 +103,7 @@ when its evidence is accessible and still valid. On every first start and restar
 state against the current brief: absolute workspace and repository identity, branch or detached HEAD, HEAD,
 staged/unstaged/untracked changes, preservation and edit ownership, applicable approvals and artifacts,
 planning-document SHA/message/paths/content or valid no-document rationale, and Orchestrator's final state verification
-(Coder handoff gate items 1-7); a reused choice never waives any gate. A restart without document changes reuses
+(Implementer handoff gate items 1-7); a reused choice never waives any gate. A restart without document changes reuses
 verified valid planning-document commits without recommitting them and a still-valid initial choice, with fresh
 actual-state checks. Normal authorized HEAD and dirty-state changes, including accepted task commits, docs commits,
 implementation, and approved worktree document transfer, do not by themselves invalidate the choice; record them and
@@ -125,11 +125,11 @@ Markdown file at `<git-common-dir>/arc/handoff/<plan-or-task-slug>.md` (slug uni
 stem, or a spec/task slug when no plan exists; never overwrite another plan's record; resolve with
 `git rev-parse --path-format=absolute --git-common-dir`; outside the working tree and shared by linked worktrees; not a
 Git mutation, never staged or committed; contains no secrets), gives its absolute path in every brief, and restart
-briefs cite it. If the write is denied or unavailable, each Coder brief states why and includes the full record inline, with no delta;
+briefs cite it. If the write is denied or unavailable, each Implementer brief states why and includes the full record inline, with no delta;
 that inline record satisfies the accessible record requirement. Do not delete it automatically.
 
 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. Include: initial record location,
+file the fresh Implementer reads, and every other brief field is in full. Include: initial record location,
 next objective and edit ownership, changed decisions,
 approvals, documents and scope (or explicit no-change confirmation), current Git state and differences, choice
 validity and reuse verification, refreshed commit/artifact checks, Orchestrator final verification, and remaining
@@ -146,7 +146,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.
@@ -155,13 +155,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.
@@ -169,12 +169,12 @@ For a selected worktree, handoff requires common directory, registration, app-ma
 approved branch, and source preservation; prepare only through the selected managed-worktree contract.
 
 
-## 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;
@@ -188,41 +188,123 @@ generalize it to behavior work.
 
 ## Orchestrator direct path for small tasks
 
-Orchestrator may make a task's edits directly, without Planner brainstorming or Coder, only when every small,
+Orchestrator may make a task's edits directly, without Planner brainstorming or Implementer, only when every small,
 low-risk criterion holds, every plan-skip criterion holds (one local change, no dependent stages, no cross-component shared state,
 lifecycle, or integration-order concerns, and one focused verification path), and no significant-risk trigger applies.
 Spike, architectural, ordinary-behavior, significant/high-risk, unclear-risk work, and edits overlapping files assigned
-to a running Coder are not eligible.
+to a running Implementer are not eligible.
 
 Before editing, Orchestrator records a scope record (not a brainstorming design) with scope and files,
 why every criterion holds, acceptance criteria, and focused verification. Apply authorization in
 [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 passes the Coder handoff gate in handoff,
+Orchestrator then passes the Implementer handoff gate in handoff,
 with the approved scope record as the applicable approval, before the first edit. Orchestrator edits only the approved files,
 preserves others' edits, makes surgical edits in the local style without unrelated refactoring or speculative additions,
 and does not install dependencies without authorization.
 
-Behavior edits follow Coder TDD and constraints; when TDD applies, Orchestrator follows local
+Behavior edits follow Implementer TDD and constraints; when TDD applies, Orchestrator follows local
 `test-driven-development`.
 After editing, Orchestrator records the changed files, runs the focused checks, connects each acceptance criterion to
 evidence, and preserves unverified scope. Orchestrator is not independent of its own edit; assign QA when the evidence is
 incomplete.
-After a failed focused check or a QA finding, Orchestrator routes the correction to Coder and obtains a recheck.
+After a failed focused check or a QA finding, Orchestrator routes the correction to Implementer and obtains a recheck.
 
 If scope expands, risk becomes unclear, or a criterion stops holding, Orchestrator stops editing, records the changes
-already made, and reclassifies; further work follows the normal Planner/Coder flow with Coder owning subsequent edits. Do not
+already made, and reclassifies; further work follows the normal Planner/Implementer flow with Implementer owning subsequent edits. Do not
 automatically revert, reset, stash, or clean those changes. 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.
-- [platform.codex] Role restrictions are prompt-level contracts, not a filesystem sandbox. No documented role-specific Git hook or generic per-agent tool allowlist is assumed. Existing shell capabilities are retained because static read access after shell reduction has not been verified; Coder and QA need shell for approved checks.
+- [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.codex] Role restrictions are prompt-level contracts, not a filesystem sandbox. No documented role-specific Git hook or generic per-agent tool allowlist is assumed. Existing shell capabilities are retained because static read access after shell reduction has not been verified; Implementer and QA need shell for approved checks.
 [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
+`arc workflow <command> --cwd <absolute-checkout> --workflow <id> --input -`.
+Query `status` without `--input`.
+
+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.