@yunhozz/arc 0.1.7 → 0.1.10

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,112 @@ 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
+`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.

package/claude/skill/references/planning.md

@@ -42,7 +42,7 @@ and records the actual absolute workspace/repository, branch or detached HEAD, H
 explicit choice and preparation evidence, and absolute document paths inside that target. Planner drafts for that
 verified workspace; Orchestrator saves directly in the selected target. Missing or mismatched evidence stops the
 affected drafting or save and is reported to Orchestrator. Planned scope and paths do not establish actual preparation.
-Initial target preparation does not authorize Coder; the complete handoff gate still applies.
+Initial target preparation does not authorize Implementer; the complete handoff gate still applies.
 
 Orchestrator classifies scope before implementation. The Orchestrator direct path for small tasks is defined only in
 [handoff](handoff.md#orchestrator-direct-path-for-small-tasks); follow it there and stop and reclassify if scope or risk changes.
@@ -75,6 +75,15 @@ Initial design, required spec approval, and formal plan drafting/approval remain
 Allow additional Planner calls for substantive omissions or user-approved scope/evidence changes. There is no fixed
 call cap; never accept an incomplete draft to minimize calls. Do not add call-count conditions to Planner profiles.
 
+The complete initial brief identifies original user requirements, criteria IDs, approved decisions and open decisions;
+current behavior and connected source, generated, runtime, installer and documentation surfaces; conflicting rules and
+resolution direction; exact current-stage deliverable and absolute output path. Keep the shared brief's fixed field order
+in [coordination](coordination.md). Link accessible evidence and needed ranges instead of full dialogue or raw logs.
+Consolidated feedback contains changed fields only and marks remaining fields `unchanged` relative to the received brief.
+Do not call Planner again for already resolved questions. Missing target preparation or required decisions holds formal
+drafting; initial design proposals may still precede target selection. Written-spec approval precedes dependent plan drafting.
+
+
 ## Design path and plan depth
 
 Record design and plan depth separately from verification risk. Risk determines checks and review, not the design path;
@@ -86,12 +95,12 @@ a bounded path or document omission does not imply low risk, and architectural d
    answers/revisions, and obtains approvals; Orchestrator never runs brainstorming or writing-plans itself (SKILL.md
    Role gate); the direct path uses only a scope record.
 2. Spike: apply Probe scope above; distinguish probe-only authorization from a sufficiently specified combined scope.
-   Bounded: approve a short design before Coder or an Orchestrator direct edit (Planner's design before
-   Coder; a direct edit uses only an approved scope record). Architectural: approve the design, then Planner returns a
+   Bounded: approve a short design before Implementer or an Orchestrator direct edit (Planner's design before
+   Implementer; a direct edit uses only an approved scope record). Architectural: approve the design, then Planner returns a
    complete spec draft and self-review; Orchestrator integrates, saves (user's path or
    `docs/superpowers/specs/YYYY-MM-DD-<topic>-design.md`), self-reviews, and obtains written-spec approval before
    implementation planning. Planner is read-only and cannot request approval.
-3. After approved design/spec and before Coder, Orchestrator assesses plan depth separately from file count, LOC,
+3. After approved design/spec and before Implementer, Orchestrator assesses plan depth separately from file count, LOC,
    or bounded scope. Architectural work always uses `writing-plans` and a written plan approval, regardless of locality,
    risk, or size. For Bounded work skip the plan only for one local change with no dependent stages, cross-component
    shared state, lifecycle or integration-order concerns, and one focused verification path; otherwise require a draft.
@@ -99,9 +108,9 @@ a bounded path or document omission does not imply low risk, and architectural d
    this assessment, including any Bounded written spec requirement, recorded in the brief.
 4. Record dependencies and any plan-depth rationale in the brief. Planner returns the complete proportional plan,
    assumptions/open decisions, verification requirements, and self-review. Orchestrator integrates, saves to the user's
-   path or `docs/superpowers/plans/YYYY-MM-DD-<feature-name>.md`, self-reviews, and obtains plan approval before Coder.
+   path or `docs/superpowers/plans/YYYY-MM-DD-<feature-name>.md`, self-reviews, and obtains plan approval before Implementer.
    Planner cannot save, implement, or request approval.
-5. Every Coder first start and restart requires all applicable approvals and the Common handoff gate (SKILL.md,
+5. Every Implementer first start and restart requires all applicable approvals and the Common handoff gate (SKILL.md,
    handoff). Non-behavior configuration/documentation may skip inapplicable design/planning stages but not the gate.
 
 When Orchestrator's recorded plan-depth judgment requires a Bounded written spec, record that and its scope,
@@ -129,12 +138,12 @@ and approved obligations. No-change, hold, and resume follow [commit](commit.md)
 
 ## Dependency and readiness record
 
-After plan approval and before the first Coder assignment, Orchestrator records all top-level task IDs in the
+After plan approval and before the first Implementer assignment, Orchestrator records all top-level task IDs in the
 accessible canonical handoff record, linked to the approved plan version. For each task record explicit and implicit
 predecessors, required inputs, outputs and shared contracts, owned files, conflicting shared resources, required
 checks/QA path, ready/held status and reasons. Record the initial ready batch and capacity/serialization reasons.
 Analyze shared APIs, contracts, generated artifacts and resources even when tasks edit different files. Unresolved
-shared contracts or insufficient dependency information block the affected tasks; same-file concurrent Coder edits
+shared contracts or insufficient dependency information block the affected tasks; same-file concurrent Implementer edits
 are blocked even for different lines. Do not infer independence from file separation or plan listing order.
 
 A task is ready only when all applicable approvals and execution preparation are complete, required inputs/contracts
@@ -142,7 +151,7 @@ are available and settled, predecessors have required evidence and Orchestrator
 commits (or accepted no-change records), ownership/resources do not conflict, its required check/QA path is available,
 and a subagent slot exists under both the configured ARC full-tree cap shared by all roles and any lower actual runtime
 limit (see [limits](limits.md)). Report runtime limits; ARC's cap is not a claim of runtime capability. Start all ready
-independent tasks with fresh Coders concurrently within capacity; record each hold or serialization reason instead of
+independent tasks with fresh Implementers concurrently within capacity; record each hold or serialization reason instead of
 silently following list order. Preserve existing risk gates, risk-scaled QA/Reviewer timing and execution-target
 restrictions.
 
@@ -190,23 +199,23 @@ Claude v1 uses the current checkout or an approved task branch there; managed wo
 Normal order: initial design approval → execution-target choice → target preparation and verification →
 formal spec drafting (when required), saving and self-review → written-spec approval → formal plan drafting
 (when required), saving and self-review → individual plan approvals → complete applicable set → existing-commit
-verification and one batch docs commit of remaining approved documents → final Git verification → Coder handoff.
+verification and one batch docs commit of remaining approved documents → final Git verification → Implementer handoff.
 Written-spec approval precedes dependent plan drafting. On document-omission paths skip only the inapplicable document
-steps; preserve target choice, preparation, state/ownership checks and Coder gates.
+steps; preserve target choice, preparation, state/ownership checks and Implementer gates.
 
 While documents are being written, reviewed, or approved, do not stage documents or commit planning documents.
 Selection and initial target preparation happen before formal drafting; document completion is a staging/commit gate,
-not an initial preparation gate. An incomplete set or missing applicable approval blocks document commit and Coder,
-not the initial choice request. No early Coder work is authorized by approval of only some documents.
+not an initial preparation gate. An incomplete set or missing applicable approval blocks document commit and Implementer,
+not the initial choice request. No early Implementer work is authorized by approval of only some documents.
 
 This ARC defers the local brainstorming early spec commit: save and self-review the spec, obtain written-spec
 approval without committing, then write and approve all plans; commit the spec only in the final batch.
-`writing-plans` commit steps do not permit document commits during planning or start Coder.
+`writing-plans` commit steps do not permit document commits during planning or start Implementer.
 Do not modify external skills.
 
 | Path | Approvals and preparation |
 |---|---|
-| Spike probe | Approve question, method/scope, criteria, constraints; no spec/plan forced. If Coder runs the probe, pass the Common handoff gate after approval. Read-only investigation needs no gate. |
+| Spike probe | Approve question, method/scope, criteria, constraints; no spec/plan forced. If Implementer runs the probe, pass the Common handoff gate after approval. Read-only investigation needs no gate. |
 | Bounded, plan skipped | Approve the short design and record plan-skip criteria; select target, prepare any documents or record absence, pass the gate. |
 | Bounded, plan required | Approve short design and every required plan; a spec only when the depth judgment requires it, approved before dependent plans. One preparation batch, then the gate. |
 | Architectural | Approve design, then spec, then every plan; select and prepare the target before formal drafting; complete the set before batch commit, final verification, and the gate. |
@@ -215,14 +224,43 @@ Do not modify external skills.
 Apply Authorization and scope above to probe-only and combined requests; preserve required design/spec/plan gates.
 These gates add no new spec obligation for Spike, Bounded plan-skip, or non-behavior documentation/configuration paths.
 Document omission skips only document obligations, never target choice, Git/ownership checks,
-or handoff evidence. New scope found in planning requires reassessing the list and additional approvals before dependent drafting or commit; revised approved documents need renewed approval. New scope found during implementation stops dependent
-execution (a running Coder stops before edits dependent on new plans) until its documents, approvals,
-and preparation are complete; do not amend old commits to cover it.
+or handoff evidence. New scope found in planning requires reassessing the list and additional approvals before dependent drafting or commit; revised approved document bodies need renewed approval except mechanical execution records defined below. New scope found during implementation stops dependent
+execution (a running Implementer stops before edits dependent on new plans) until its documents, approvals,
+and preparation are complete. Then reflect the approved plan version in its original planning-document commit under the update contract below; never retroactively authorize work before actual approval.
+
+## Plan updates during execution
+
+Mechanical execution records may be recorded without new user approval: checkbox completion, actual results, evidence
+links and task completion state that preserve the approved execution contract. Record their classification, reason and
+actual recording time in the canonical handoff record. Required checks' removal, invented success, unsupported acceptance
+or scope changes mixed with a completion mark are not mechanical records.
+
+Changes to goals, task scope or boundaries, acceptance criteria, method, risk, dependencies or required verification
+require revised-version approval before affected work. Hold affected execution, obtain necessary design/spec/plan approvals
+in order, and complete target, ownership, checks and handoff preparation before resuming. Other approved body corrections
+follow the document-version approval rules; classify typos, paths, commands and explanations by their semantic effect.
+
+Both mechanical records and approved contract revisions amend the original planning-document commit at a safe checkpoint.
+Make no separate document commit or fixup commit, including for newly approved scope. Preserve implementation task commits.
+This history update does not make actual approval time retroactive: the latest plan in the original commit is not evidence
+that its contents were approved from the outset. Never use rewritten history to justify work started before approval.
+
+In the canonical handoff record preserve plan absolute/Git paths; before and after content hashes and versions; prior and
+revised approval references and actual times; change reason and classification; affected tasks and hold/preparation/resume
+evidence. For mechanical records explain why no new approval is needed and record the time. Preserve recoverable document
+contents, not hashes alone, and each old-to-new SHA mapping for the original document commit and descendant task commits.
+Do not overwrite earlier approval references or the contents they approved.
+
+Orchestrator alone performs the safe rewrite in [handoff-prep](handoff-prep.md#execution-time-plan-amendment) and
+[commit](commit.md#execution-time-plan-document-updates). Shared/published or unknown history, merges, unclear ownership,
+unexpected HEAD/dirty state and replay conflicts stop affected work. No force push or fallback document commit.
+After rewriting, connect evidence to the new state under [verification](verification.md#evidence-after-plan-history-rewrite).
+This contract adds no Git automation, runtime enforcement, authority or exemption from required checks/QA/Reviewer gates.
 
 ## Evidence refresh and limits
 
 Missing or mismatched evidence, unfinished approvals, unclear ownership, or unresolved failure blocks the affected save,
-target request, Git mutation, or Coder handoff; Orchestrator resolves it and reverifies.
+target request, Git mutation, or Implementer handoff; Orchestrator resolves it and reverifies.
 Reverify when scope, approved versions, paths, target, or Git state changes. Never treat an early save or commit as
 satisfying a gate or as approval; record the actual order and gaps. Structural checks prove only the written policy,
 not agent runtime compliance; without execution records for role returns, approvals, saves, and Git actions,
@@ -239,8 +277,21 @@ skill. Missing files stop the stage; report paths without global fallback. Keep
 [ARC role policy: contract begin]
 Generated from lib/policy/role-policy.json; do not edit this managed section manually.
 - [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.
-- [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.
+- [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.
+- [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.
+- [planning.planner-brief] Before formal drafting, Orchestrator supplies one complete stage-specific brief with original requirements and criteria IDs, approved/open decisions, verified target and ownership, document paths and preceding approved versions, current behavior and connected source/generated/runtime/installer/documentation surfaces, policy conflicts, depth, dependencies, checks, holds and exact deliverable. Preserve shared brief field order. Review the complete draft once and consolidate substantive feedback as changed fields with other fields marked unchanged. Preserve sequential design, spec and plan approvals; no fixed call cap or incomplete drafts, and no calls for already resolved questions.
 - [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]
+
+## Approved cooperative execution path within the repository
+
+The explicitly approved `arc workflow` CLI in this repository connects document commits to the initial Implementer assignment in plan mode.
+Its scope is decisions and records within the repository's cooperative path. It adds no authority to install native hooks/providers/installers or block direct tool calls.
+`no-plan`/omission is unsupported by this CLI, and this boundary remains in Phases 2 and 3. This does not imply an omission policy violation or a new obligation to write documents.
+
+Orchestrator records the SHA-256 values of the user-approved spec and plan, their shared docs-only commit, document version and approval version.
+The CLI verifies the exact changed paths in actual Git objects and the current document bytes before persisting an assignment intent.
+A new workflow or late document commit cannot prove earlier execution was compliant. Earlier agent history and execution outside this path remain unverified.
+Approval attestations and native returns are `operator-attested`; an agent ID is not an authenticated identity.