@yunhozz/arc 0.1.4 → 0.1.6

package/codex/skill/references/handoff.md

@@ -1,8 +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
+in the brief under the Coder 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).
 
@@ -11,8 +10,7 @@ the Coder profile and reads this file only for sections the brief explicitly cit
 ### Checkout approval
 
 Before every Coder 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,
+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.
 
@@ -28,9 +26,8 @@ drafting or preparation and does not require document completion. Never fall bac
 After initial design approval, obtain and record an explicit user choice for the first start under 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.
+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.
 
 ### Coder handoff gate
 
@@ -51,13 +48,11 @@ Orchestrator may start or restart Coder only after all of these conditions are v
    failure or partial completion.
 7. The brief includes these preparation and final-verification facts and evidence.
 
-Before a Orchestrator direct edit, Orchestrator verifies the same conditions, with the approved scope record as the
-applicable approval,
-and records them in the brief.
+Before an Orchestrator direct edit, Orchestrator verifies the same conditions, with the approved scope record as the
+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,
+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.
 
@@ -79,12 +74,10 @@ 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
-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.
+restart. Give all five roles (Coder, 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.
 
 ### Task readiness at every assignment
 
@@ -107,8 +100,7 @@ Unexpected HEAD or ownership changes stop affected work for Orchestrator resolut
 
 For the same approved scope, workspace, repository, and execution target, reuse the initial explicit choice only
 when its evidence is accessible and still valid. On every first start and restart, Orchestrator rechecks actual Git
-state
-against the current brief: absolute workspace and repository identity, branch or detached HEAD, HEAD,
+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
@@ -119,14 +111,12 @@ verify that they match approved work, ownership, and the intended target. A work
 evidence; target HEAD need not remain at that base; source preservation and unexpected-state checks still apply.
 Link the approved plan version, task ID and commit SHA/content/validity with current Git state and edit ownership in
 the restart brief under Orchestrator's full handoff gate. Verify/reuse successful task commits without duplication and
-keep planning-document preparation
-evidence distinct; task commits do not require repeating valid document preparation.
+keep planning-document preparation evidence distinct; task commits do not require repeating valid document preparation.
 
 If scope, workspace, repository, target, or approved branch candidate changes, obtain a fresh explicit choice before dependent drafting or preparation; reselection does not require document completion. If an invalidating failure means the old target cannot be trusted,
 obtain a fresh explicit choice after Orchestrator resolves preparation. State mismatches and unresolved failures block
 editing until Orchestrator resolves and revalidates the full gate; resolution does not automatically require a new
-choice
-unless it invalidates the old target. Do not fall back automatically; apply the Explicit choice rule.
+choice unless it invalidates the old target. Do not fall back automatically; apply the Explicit choice rule.
 
 Keep one canonical initial handoff record accessible to each assigned role, containing the approved scope/version,
 repository/workspace identity, and the Handoff evidence fields above; do not create a separate storage service.
@@ -135,8 +125,7 @@ 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 Coder 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
@@ -166,8 +155,8 @@ Before any exception judgment, Orchestrator reads [Risk-scaled execution](verifi
 
 ## Common handoff gate
 
-Before every Coder first start/restart, Orchestrator passes the full gate in
-[handoff](handoff.md): applicable approvals/artifacts or valid omissions, explicit execution-target choice
+Before every Coder 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
@@ -175,7 +164,7 @@ resolution and full revalidation. Handoff owns the evidence fields, canonical ha
 and reuse. Coder 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 a Orchestrator direct edit.
+branches. The same conditions apply before an Orchestrator direct edit.
 For a selected worktree, handoff requires common directory, registration, app-managed current-chat attachment,
 approved branch, and source preservation; prepare only through the selected managed-worktree contract.
 
@@ -200,12 +189,10 @@ 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,
-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.
+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.
 
 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
@@ -213,23 +200,19 @@ why every criterion holds, acceptance criteria, and focused verification. Apply
 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,
-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.
+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
 `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
+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.
 
 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/Coder flow with Coder 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.
 

package/codex/skill/references/limits.md

@@ -30,7 +30,7 @@ Serialize work when a batch does not fit. There are no reserved role slots.
 
 Preserve the ledger through continuation, resume and context compaction; reconcile actual instance
 IDs before dispatch. Ledger loss must never reset counters to zero. If reconstruction is incomplete,
-hold creation and report the unknown budget; use a conservative bound only with sufficient evidence.
+hold creation and report the unknown budget; use a conservative upper bound only when the reconstructed records support it.
 Completion frees confirmed active capacity; it does not restore the total-created budget. Exhaustion holds new
 creation and requires reporting remaining work and budgets. It does not authorize skipping required
 QA or Reviewer, role freshness, approval, ownership, dependency or same-file edit gates.

package/codex/skill/references/planning.md

@@ -29,11 +29,12 @@ a well-supported infeasibility result can complete it. Probe-only authorization
 or subsequent implementation. Record question, method/scope, criteria, and constraints; a sufficiently specific probe
 request can supply that approval. Match checks to probe purpose/risk and do not report probe evidence as product proof.
 
-If the user explicitly requests both a probe and implementation and the whole scope is sufficiently specified,
-classify the entire scope. When the entire scope meets Bounded conditions, the probe is an internal investigation
-with no new approval boundary at its report. Unknown implementation is not blanket authorization: hold affected
-implementation if findings materially change scope, method, or risk, or leave a new material decision. Reassess depth
-and obtain any required design/spec/plan approvals before that implementation. A probe-only request remains separate.
+If the user explicitly requests both a probe and implementation and the whole scope is sufficiently specified, classify
+the entire scope. When the entire scope meets the Bounded path criteria in Design path and plan depth, the probe is an
+internal investigation with no new approval boundary at its report. Unknown implementation is not blanket authorization:
+hold affected implementation if findings materially change scope, method, or risk, or leave a new material decision.
+Reassess depth and obtain any required design/spec/plan approvals before that implementation. A probe-only request
+remains separate.
 
 ## Formal drafting boundary
 
@@ -69,7 +70,7 @@ call cap; never accept an incomplete draft to minimize calls. Do not add call-co
 
 `brainstorming` and `writing-plans` are instructions for existing roles, not extra agents. This ARC controls
 routing/approval gates even if a called skill names another executor. Follow local ARC reference instructions and user
-constraints; report missing required local references before that stage. Integrate means save, route, and obtain approval;
+constraints; report a missing required skill or local reference before that stage; it blocks that stage. Integrate means save, route, and obtain approval;
 never author.
 
 When the request or task brief is in Korean, Planner writes spec and plan titles and explanatory prose in Korean unless
@@ -83,15 +84,15 @@ approved obligations separately.
 
 1. Before software feature, design, or behavior changes, Orchestrator assigns Planner the local `brainstorming`
    skill with
-   the brief/evidence. Planner explores context and proposes the spike/bounded/architectural path (Orchestrator
-   decides), design/options,
+   the brief/evidence. Planner explores context. Planner proposes, Orchestrator decides the spike/bounded/architectural path; Planner also
+   proposes design/options,
    trade-offs, acceptance criteria, assumptions, and focused questions. Orchestrator integrates, announces scope,
    routes user
    answers/revisions back, 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 a Orchestrator direct edit (Planner's design
+   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
    design, then Planner returns complete spec draft and self-review findings; Orchestrator integrates, saves,
    self-reviews, and obtains written-spec approval
@@ -110,17 +111,15 @@ approved obligations separately.
    self-reviews,
    then obtains plan approval before Coder.
 5. Every Coder first start and restart requires all applicable design/spec/plan approvals and passing
-   the common handoff gate in SKILL.md and handoff.md, with approved artifacts, brief, and relevant findings.
+   the Common handoff gate in SKILL.md and handoff.md, with approved artifacts, brief, and relevant findings.
    Non-behavior
    configuration/documentation may skip inapplicable design/planning stages, but still requires the handoff gate.
-   A Orchestrator direct edit requires its approved scope record and the same gate conditions before the first edit.
+   An Orchestrator direct edit requires its approved scope record and the same gate conditions before the first edit.
 
 When a Bounded written spec is required by Orchestrator's recorded plan-depth judgment, record that necessity and scope
-and
-use the approved short design as its basis. Planner returns a proportional complete spec draft and self-review;
+and use the approved short design as its basis. Planner returns a proportional complete spec draft and self-review;
 Orchestrator integrates, saves, self-reviews, and obtains individual written-spec approval before dependent plan
-drafting
-and execution preparation. This applies that judgment, not a new spec-necessity rule.
+drafting and execution preparation. This applies that judgment, not a new spec-necessity rule.
 
 Design, spec, plan, and brainstorming drafts are authored only by Planner.
 Orchestrator must not substitute an independently authored spec or plan for Planner's complete draft.
@@ -134,13 +133,11 @@ implementation goal/scope and target files, preceding tasks and dependencies, ac
 checks and evidence before acceptance, and hold conditions; each task independently implementable, verifiable and
 acceptable, with changes that cannot be independently verified (including policy/profile/tests/manifest sharing one
 contract) in one task from the outset; and final overall plan verification stated separately from task acceptance
-prerequisites, with scope and timing. Never list Reviewer as a per-task required check (Reviewer timing: SKILL.md
-Risk-scaled execution). RED/GREEN and individual
+prerequisites, with scope and timing. Never list Reviewer as a per-task required check (Reviewer timing: [Risk-scaled execution](verification.md#risk-scaled-execution)). RED/GREEN and individual
 commands do not create commit units; one task is one focused commit under commit.md, which also covers no-change, hold
 and resume. Do not combine different approved tasks into one commit during execution; if inseparability appears later,
 stop affected work and have Orchestrator handle revised scope, planning and applicable approvals.
-These requirements apply to
-required plans; existing plan-omission paths gain no new plan obligation.
+These requirements apply to required plans; existing plan-omission paths gain no new plan obligation.
 
 ### Dependency and readiness record
 
@@ -156,13 +153,16 @@ A task is ready only when all applicable approvals and execution preparation are
 are available and settled, predecessors have required evidence and Orchestrator acceptance plus verified focused
 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. Report runtime limits. Start all ready independent tasks with fresh Coders concurrently within capacity;
-record each hold or serialization reason instead of silently following list order. Preserve existing risk gates.
+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
+silently following list order. Preserve existing risk gates, risk-scaled QA/Reviewer timing and execution-target
+restrictions.
 
 Update the map on completion, check evidence, acceptance, commit, slot return and new conflicts. Completion reports
 alone do not release dependents. Reevaluate newly ready tasks immediately without waiting for unrelated batch members;
 failed or ambiguous predecessors hold their dependent chain, while unaffected ready tasks may proceed. Dispatch still
-passes handoff.md for each task; commits and shared Git mutations follow commit.md. This record does not authorize
+passes [handoff](handoff.md) for each task, refreshing assignment evidence there; commits, shared-checkout Git
+coordination and shared Git mutations follow [commit](commit.md). This record does not authorize
 Orchestrator to rewrite Planner's approved task boundaries or waive approvals.
 
 For example, with A → B → C and independent D and two slots, start A and D. After A's required checks,
@@ -194,14 +194,12 @@ If evidence is missing or mismatched in either gate, stop the affected save and
 
 The applicable document set means all specs and plans required for the current approved execution scope, not future
 project work. Orchestrator records scope, design/plan depth, absolute document paths and coverage, approved
-versions/status,
-plan dependencies and execution order, skipped stages with rationale, and documents still awaiting writing or approval
+versions/status, plan dependencies and execution order, skipped stages with rationale, and documents still awaiting writing or approval
 in the shared brief. The set is complete only when every required document is written and individually approved and
 no unresolved scope or dependency decision requires another document. Do not omit required documents from the list.
 
 A required plan does not itself require a written spec. Bounded uses Orchestrator's recorded plan-depth judgment to
-determine
-whether a written spec is required; do not infer one from plan necessity. Spec steps apply only to Architectural and
+determine whether a written spec is required; do not infer one from plan necessity. Spec steps apply only to Architectural and
 required Bounded specs, and plan steps only to required plans. These gates add no new spec obligation to Spike,
 Bounded plan-skip, or non-behavior documentation/configuration paths; preserve existing omission rationales.
 
@@ -225,17 +223,16 @@ are not permission for document commits during planning or for starting Coder.
 
 | Path | Applicable approvals and preparation |
 |------|--------------------------------------|
-| Spike probe | Approve the feasibility question, probe method/scope, acceptance criteria, and constraints. Do not force specs/plans for still-unknown implementation; no new spec obligation is added by this gate. If Coder executes the probe, pass the common handoff gate after probe approval. Read-only Orchestrator/Planner investigation without Coder does not trigger that gate. |
-| Bounded, plan skipped | Approve the short design and record the existing plan-skip criteria/rationale; this gate adds no new spec obligation. Complete applicable approvals, select the target, prepare any actual approved documents, or record valid document absence, then pass the common gate. |
-| Bounded, plan required | Approve the short design and every required plan; write a spec only when Orchestrator's recorded plan-depth judgment requires it, then obtain its individual written-spec approval before dependent plan drafting. Select and prepare the target before formal drafting; complete all applicable artifacts before one docs batch and the common gate. |
-| Architectural | Approve design, then written spec, then every required plan using `writing-plans`; select and prepare the target before formal drafting; complete the document set before batch preparation, final verification, and the common gate. |
-| Non-behavior documentation/configuration | Record scope, acceptance criteria, and why design/planning stages are inapplicable; this gate adds no new spec obligation. Still select the target, verify Git state, prepare actual approved documents or record absence, and pass the common gate. |
+| Spike probe | Approve the feasibility question, probe method/scope, acceptance criteria, and constraints. Do not force specs/plans for still-unknown implementation; no new spec obligation is added by this gate. If Coder executes the probe, pass the Common handoff gate after probe approval. Read-only Orchestrator/Planner investigation without Coder does not trigger that gate. |
+| Bounded, plan skipped | Approve the short design and record the existing plan-skip criteria/rationale; this gate adds no new spec obligation. Complete applicable approvals, select the target, prepare any actual approved documents, or record valid document absence, then pass the Common handoff gate. |
+| Bounded, plan required | Approve the short design and every required plan; write a spec only when Orchestrator's recorded plan-depth judgment requires it, then obtain its individual written-spec approval before dependent plan drafting. Select and prepare the target before formal drafting; complete all applicable artifacts before one docs batch and the Common handoff gate. |
+| Architectural | Approve design, then written spec, then every required plan using `writing-plans`; select and prepare the target before formal drafting; complete the document set before batch preparation, final verification, and the Common handoff gate. |
+| Non-behavior documentation/configuration | Record scope, acceptance criteria, and why design/planning stages are inapplicable; this gate adds no new spec obligation. Still select the target, verify Git state, prepare actual approved documents or record absence, and pass the Common handoff gate. |
 
 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 explicit
-execution-target
-choice, Git state/ownership checks, or handoff evidence.
+execution-target choice, Git state/ownership checks, or handoff evidence.
 
 If planning reveals new scope, reassess the list, depth, and dependencies and obtain additional required approvals
 before dependent drafting or commit. Changed approved documents require approval of the revised version. If implementation reveals new
@@ -248,9 +245,9 @@ lifetime and restart record in [handoff.md](handoff.md).
 
 Missing or mismatched evidence, unfinished approvals, unclear ownership, or unresolved failure blocks the affected
 save, execution-target request, Git mutation, or Coder handoff: stop and report to Orchestrator.
-Orchestrator resolves the issue and
-reverifies affected evidence before resumption. Reverify evidence when scope, approved versions, paths, target, or
-relevant Git state changes. Preserve unrelated changes under handoff rules; read-only investigation remains allowed.
+Orchestrator resolves the issue and reverifies affected evidence before resumption. Reverify evidence when scope,
+approved versions, paths, target, or relevant Git state changes. Preserve unrelated changes under handoff rules;
+read-only investigation remains allowed.
 
 Do not retroactively treat an early save or commit as satisfying these gates or as user approval. Record the actual
 order and any evidence gap. Structural checks prove only the repository's written policy contract, not consuming-agent
@@ -259,7 +256,7 @@ compliance unverified. Do not add runtime infrastructure or modify external skil
 
 ### Managed worktree preparation
 
-See [handoff-worktree.md](handoff-worktree.md) for the third-path managed worktree contract.
+See [handoff-worktree.md](handoff-worktree.md) for the managed worktree contract.
 
 ## Local planning references
 
@@ -267,30 +264,6 @@ Orchestrator briefs absolute ARC paths `references/superpowers/brainstorming/SKI
 `references/superpowers/writing-plans/SKILL.md`. Planner reads them directly; resolve relative references within each
 skill. Missing files stop the stage; report paths without global fallback. Keep ARC approval and ownership gates.
 
-## Dependency analysis and parallel dispatch
-
-Before the first Coder assignment for an approved plan, Orchestrator records its dependency/readiness map and
-initial ready batch under [planning](planning.md), which owns record fields and readiness conditions.
-File separation alone never proves independence. Pass the full approval/preparation and handoff gates for every
-assignment; unresolved dependencies, shared contracts, or ownership conflicts hold affected work.
-Start all ready independent tasks concurrently with fresh Coders within capacity under [limits](limits.md)
-and any lower actual runtime limit; record capacity and serialization reasons. Same-file concurrent Coder edits are
-prohibited, even on different lines. ARC's cap is not a claim of runtime capability.
-
-Reassess readiness after completion reports, new check evidence, acceptance, commit, slot return, or a new conflict.
-Coder completion alone does not release dependents: require predecessor checks, Orchestrator acceptance and verified
-focused commit, or accepted no-change evidence under [commit](commit.md). Start newly ready tasks without
-waiting for unrelated batch members; failures hold affected dependents while unaffected ready work may continue.
-Preserve risk-scaled QA/Reviewer timing and execution-target restrictions. Shared-checkout Git coordination belongs to
-commit.md; refresh assignment evidence under [handoff](handoff.md).
-
-
-Design and plan depth are independent of verification risk. Planner alone uses local brainstorming/writing-plans
-(Role gate); Planner proposes, Orchestrator decides the path and plan depth;
-Orchestrator integrates complete drafts and obtains applicable approvals. Architectural specs and Bounded written specs
-required by Orchestrator's recorded plan-depth judgment (planning item 3) use planning save gates; a required plan alone
-does not require a spec. Obtain explicit execution-target choice and verify actual target preparation before formal drafting
-and saving. Complete all current-scope individual document approvals before the batch docs commit. A missing required skill blocks its stage.
 
 
 [ARC role policy: contract begin]

package/codex/skill/references/verification.md

@@ -10,8 +10,7 @@ For Orchestrator, **Evidence verdict**: each criterion is proven, unmet, or unve
 ## Risk-scaled execution
 
 Orchestrator assigns edits exclusively to Coder except under the Orchestrator direct path in [handoff](handoff.md#orchestrator-direct-path-for-small-tasks), and determines affected
-behavior, risk,
-and smallest meaningful verification.
+behavior, risk, and smallest meaningful verification.
 
 | Risk | Minimum flow |
 |---|---|
@@ -21,9 +20,8 @@ and smallest meaningful verification.
 
 Ordinary and significant plan tasks need a FRESH QA before acceptance; only small, low-risk tasks may be accepted on
 Orchestrator focused checks. Small, low risk means narrow, understood, readily reversible, and verifiable by focused
-checks. Ordinary behavior
-fails those conditions without a significant-risk trigger. Significant risk includes shared role/behavior contracts,
-shared state, lifecycle/integration order, security/permissions, data loss/migration, public interfaces, or costly
+checks. Ordinary behavior fails those conditions without a significant-risk trigger. Significant risk includes shared
+role/behavior contracts, shared state, lifecycle/integration order, security/permissions, data loss/migration, public interfaces, or costly
 installation/deployment/rollback. Substantial behavior or contract changes are significant regardless of file count.
 When risk is unclear, investigate or use the higher flow. Environment failure does not waive checks or determine design depth.
 
@@ -59,33 +57,29 @@ report only checks actually performed, their actor, target state, results and re
 
 Authorization evidence and probe/combined scope are owned by [planning](planning.md#authorization-and-scope);
 valid reuse and actual-state refresh by [handoff](handoff.md#authorization-continuity).
-After gates hold, continue approved no-doc scope through required checks and Orchestrator acceptance under
-[verification](verification.md#completion-continuity); a role report alone does not complete the work.
+After gates hold, continue approved scope without saved documents through required checks and Orchestrator acceptance under
+Completion continuity below; a role report alone does not complete the work.
 
 
 
 The Risk-scaled execution section above holds the risk table, risk definitions, evidence-reuse rule, and role order,
 including Reviewer timing. Product/test edits belong exclusively to Coder except under the Orchestrator direct path;
-Orchestrator may inspect/run checks but
-routes code corrections to Coder. Determine the minimum
+Orchestrator may inspect/run checks but routes code corrections to Coder. Determine the minimum
 flow from risk and any specific instruction or approved commitment, and record which requirements each check or review
 satisfies. For small, low-risk work with clear scope and acceptance evidence and no such requirement,
-Orchestrator's focused
-checks suffice; do not call QA or Reviewer automatically. Significant/high-risk work requires independent review of the
-full change at the final relevant state after the required QA/focused checks and any QA recheck.
+Orchestrator's focused checks suffice; do not call QA or Reviewer automatically. Significant/high-risk work requires
+independent review of the full change at the final relevant state after the required QA/focused checks and any QA recheck.
 
 Many known metadata files are not significant solely because there are many, and a one-file permission or data-loss
 rule may be. A vague request to delete unnecessary files does not establish low risk; reclassify when installer,
 manifest, or other contracts are affected. For a verified ignore-pattern or metadata cleanup, confirm the targets are
 unused, required project materials are unaffected, ignore patterns cover only intended paths, and the diff matches the
 approved scope; Orchestrator's focused checks then suffice without automatically calling QA or Reviewer.
-An environment failure
-is distinct from a code failure; report the exact limitation and any remaining evidence gap to Orchestrator.
+An environment failure is distinct from a code failure; report the exact limitation and any remaining evidence gap to Orchestrator.
 
 Use additional Planner/Scouter only for unresolved planning/discovery questions. Reviewer covers substantial changes and
 correctness, factual, security, data, or interface risks. Orchestrator may use Planner/Scouter/Reviewer when justified
-and assigns
-all Coder/QA work. Specialists report unresolved questions to Orchestrator, who assigns support only when needed.
+and assigns all Coder/QA work. Specialists report unresolved questions to Orchestrator, who assigns support only when needed.
 
 QA runs applicable existing functional/test checks, or approved structural/consistency checks for policy and
 configuration changes. Reviewer reads the assigned diff/source for correctness, factual accuracy, and security. Outside the final plan Reviewer correction exception, after a
@@ -102,14 +96,13 @@ completion, a Coder report or passing commands alone do not establish acceptance
 
 Task acceptance and its focused commit require only the task's risk-scaled evidence: a FRESH QA instance per task that
 needs QA (same-task rechecks may reuse), or Orchestrator focused checks for small, low-risk tasks;
-Reviewer timing and task-boundary gates follow SKILL.md Risk-scaled execution. For an independently acceptable task,
+Reviewer timing and task-boundary gates follow the Risk-scaled execution section above. For an independently acceptable task,
 do not delay its acceptance/commit solely for later final plan verification. Currently required task checks must not
 be deferred to final verification to accept early. State the scope and timing of final-only integration criteria in
 the plan; with a plan, the required final whole-change review is final plan verification.
 
 A task commit record does not mark unperformed final verification complete. Orchestrator still decides final plan
-acceptance
-using final QA/Reviewer/integration evidence and findings, preserving unverified scope and explicit dispositions.
+acceptance using final QA/Reviewer/integration evidence and findings, preserving unverified scope and explicit dispositions.
 Valid evidence may cover both task and plan requirements only under the existing scope/state/independence/freshness/flow
 rules. 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
@@ -127,10 +120,8 @@ required account and test-data scope, and permitted interactions, QA may use the
 to launch the app or open the URL with available approved browser tools. Follow tool instructions and any applicable
 installed browser skill. This permission does not authorize source/document/test/configuration editing, installing
 dependencies, or changing environment configuration. Report missing prerequisites to Orchestrator and leave affected
-criteria
-unverified. For each criterion record the command or URL, test state and viewport (or not applicable),
-interaction steps,
-expected and observed results, and accessible evidence. App startup, page load, and static checks alone do not prove
+criteria unverified. For each criterion record the command or URL, test state and viewport (or not applicable),
+interaction steps, expected and observed results, and accessible evidence. App startup, page load, and static checks alone do not prove
 complete UI behavior. For unavailable test environment or browser tools, report the exact limitation and affected
 unverified criteria. Clean up only QA-created processes and sessions; preserve existing shared services and sessions.
 When assigning UI acceptance criteria, Orchestrator cites this section with its accessible path in the QA brief.
@@ -147,23 +138,17 @@ verdicts.
 Structural checks prove structural criteria only; they do not prove actual behavior, installation, or live agent runtime
 compliance.
 
-For QA execution failure or an unmet criterion, Orchestrator assigns Coder correction and obtains a QA recheck before
-Reviewer.
-Do not enter Reviewer until QA reports the finding as resolved, unresolved, or unverified with evidence; unresolved
-execution failures or unmet criteria require correction and another QA recheck before that stage. QA rechecks the defect
-reproduction path and related checks invalidated by the fix. Environment blocks, missing checks, and out-of-scope
-criteria
-are evidence gaps, not presumed code defects; Orchestrator handles those gaps under the existing disposition policy
-without
-substituting Reviewer review for QA evidence.
+For QA execution failure or an unmet criterion, Orchestrator assigns Coder correction and a QA recheck of the
+reproduction path and invalidated related checks before Reviewer; QA reports the prior finding resolved, unresolved, or
+unverified with evidence. An unresolved finding returns to Coder correction and another QA recheck before Reviewer.
+Environment blocks, missing checks, and out-of-scope criteria are evidence gaps, not presumed code defects; Orchestrator
+handles those gaps under the existing disposition policy without substituting Reviewer review for QA evidence.
 
 For an acceptance-linked behavior finding, Reviewer reports the criterion, expected behavior, observed problem, related
 source, reproduction conditions and steps, and evidence to Orchestrator, distinguishing source-inferred reproduction
-from
-execution-observed results without running QA tests. Outside the final plan Reviewer correction exception, Orchestrator routes it to Coder correction and QA post-fix recheck.
-Outside that exception, for significant/high-risk work, Reviewer then reviews the final full change once after QA recheck (the same Reviewer
-rechecks the same scope after a fix), or, for already committed
-plan work, rechecks only the affected findings when warranted. Reviewer continues handling
+from execution-observed results without running QA tests. Outside the final plan Reviewer correction exception,
+Orchestrator routes it to Coder correction and QA post-fix recheck. Outside the required final plan correction loop,
+Orchestrator decides when a Reviewer recheck is warranted by the changed scope and independence. Reviewer continues handling
 structure, design, factual, and security findings that execution checks cannot settle; observable security/interface
 issues may require both QA verification and Reviewer source review.
 
@@ -176,19 +161,6 @@ For low-risk work without QA, Orchestrator's focused checks likewise connect eac
 Read brief-cited `references/superpowers/test-driven-development/SKILL.md`; retain ARC exceptions.
 
 
-### Final plan Reviewer correction loop
-
-For a plan's final overall Reviewer findings, including behavior findings, Orchestrator assigns
-Coder → Reviewer recheck with no QA reassignment. Repeat corrections and Reviewer rechecks until findings are resolved;
-the initial single full review does not prohibit necessary rechecks. Before the initial final overall Reviewer,
-risk-required checks and QA execution failures or unmet criteria still require Coder correction → QA recheck.
-This exception applies only to findings from the final overall Reviewer of work with a plan.
-Work without a plan retains its existing verification flow. Scope expansion, separate mandatory obligations,
-or unresolved evidence gaps hold affected work for Orchestrator to resolve and obtain required approvals.
-Orchestrator assigns corrections/rechecks and decides acceptance. Reviewer remains read-only, must not run QA
-checks or decide acceptance. Previous QA evidence must not be presented as post-fix execution evidence;
-report only checks actually performed, their actor, target state, results and remaining limits.
-
 ## Completion continuity
 
 Once applicable authorization, document-depth, execution-target, and handoff conditions hold for the approved scope,

package/codex/skill/references/visual-companion.md

@@ -8,14 +8,12 @@ Visual companion design discussion is distinct from QA UI acceptance checks unde
 
 Planner identifies a genuinely visual question, explains why a visual helps, and returns options, the user decision,
 and a complete content draft; Planner does not write screens, start a server, operate a browser, or request approval.
-Orchestrator makes a just-in-time
-offer as its own message only when a question is clearer visually, then waits for acceptance. If declined, continue in
-text and do not offer again unless the user raises it. If accepted, decide per question whether to use the companion.
-Orchestrator owns its guide, server/browser, workspace paths, live-session checks, complete keyed URL, screens,
-session state,
-feedback/events, stale-screen clearing when returning to text, and cleanup. Check the server before showing a screen;
-after the user's reply, treat terminal text as primary and events as supplemental. A UI topic or accepted companion
-alone does not route every question through a browser.
+Orchestrator makes a just-in-time offer as its own message only when a question is clearer visually, then waits for
+acceptance. If declined, continue in text and do not offer again unless the user raises it. If accepted, decide per
+question whether to use the companion. Orchestrator owns its guide, server/browser, workspace paths, live-session
+checks, complete keyed URL, screens, session state, feedback/events, stale-screen clearing when returning to text, and
+cleanup. Check the server before showing a screen; after the user's reply, treat terminal text as primary and events as
+supplemental. A UI topic or accepted companion alone does not route every question through a browser.
 
 
 Upstream guide/scripts: `<installed ARC>/references/superpowers/brainstorming/visual-companion.md` and adjacent `scripts/`.

package/lib/cli/choices.mjs

@@ -13,10 +13,10 @@ export async function selectChoices(options,{input=process.stdin,output=process.
  try{return await new Promise((resolve,reject)=>{
   abort=()=>reject(cancelled());onEnd=abort;onError=reject;
   onKey=(str,key={})=>{try{if(key.name==='c'&&key.ctrl||key.name==='d'&&key.ctrl)return abort();if(key.name==='up'||key.name==='down'){index=(index+(key.name==='up'?-1:1)+menus[menu][1].length)%menus[menu][1].length;draw(true);}else if(key.name==='return'||key.name==='enter'){const [name,,values]=menus[menu];options[name]=values[index];output.write('\n');if(++menu===menus.length){keys.removeListener('keypress',onKey);resolve(options);}else{index=menus[menu][3];draw();}}}catch(error){reject(error);}};
-  keys.on('keypress',onKey);readline.emitKeypressEvents(keys);onData=chunk=>keys.emit('data',chunk);input.on('data',onData);input.once('end',onEnd);input.once('error',onError);process.once('SIGINT',abort);
+  keys.on('keypress',onKey);readline.emitKeypressEvents(keys);onData=chunk=>keys.emit('data',chunk);input.on('data',onData);input.once('end',onEnd);input.once('close',onEnd);input.once('error',onError);process.once('SIGINT',abort);process.once('SIGTERM',abort);
   if(input.setRawMode)input.setRawMode(true);input.resume();draw();
  });}finally{
-  keys.removeAllListeners();input.removeListener('data',onData);input.removeListener('end',onEnd);input.removeListener('error',onError);process.removeListener('SIGINT',abort);
+  keys.removeAllListeners();input.removeListener('data',onData);input.removeListener('end',onEnd);input.removeListener('close',onEnd);input.removeListener('error',onError);process.removeListener('SIGINT',abort);process.removeListener('SIGTERM',abort);
   for(const [event,before]of listeners)for(const listener of input.listeners(event))if(!before.includes(listener))input.removeListener(event,listener);
   if(input.setRawMode)input.setRawMode(Boolean(wasRaw));if(wasFlowing!==true)input.pause();
  }
@@ -36,9 +36,9 @@ export async function selectLimits(options,selections,{input=process.stdin,outpu
    if(name==='maxConcurrentSubagents')options.concurrentSelected=true;output.write('\n');value='';if(++index===fields.length){input.removeListener('keypress',onKey);resolve(options);}else draw();
   }else if(key.name==='backspace'){value=value.slice(0,-1);output.write('\b \b');}else if(str&&!key.ctrl&&!key.meta){value+=str;output.write(str);}};
   onData=chunk=>{for(const character of chunk.toString()){if(index===fields.length)break;const name=character==='\r'||character==='\n'?'return':character==='\x03'?'c':character==='\x04'?'d':character==='\x7f'||character==='\b'?'backspace':undefined;onKey(character,{name,ctrl:character==='\x03'||character==='\x04'});}};
-  input.on('data',onData);input.once('end',onEnd);input.once('error',onError);process.once('SIGINT',abort);if(input.setRawMode)input.setRawMode(true);input.resume();draw();
+  input.on('data',onData);input.once('end',onEnd);input.once('close',onEnd);input.once('error',onError);process.once('SIGINT',abort);process.once('SIGTERM',abort);if(input.setRawMode)input.setRawMode(true);input.resume();draw();
  });}finally{
-  input.removeListener('data',onData);input.removeListener('end',onEnd);input.removeListener('error',onError);process.removeListener('SIGINT',abort);
+  input.removeListener('data',onData);input.removeListener('end',onEnd);input.removeListener('close',onEnd);input.removeListener('error',onError);process.removeListener('SIGINT',abort);process.removeListener('SIGTERM',abort);
   for(const[event,before]of listeners)for(const listener of input.listeners(event))if(!before.includes(listener))input.removeListener(event,listener);
   if(input.setRawMode)input.setRawMode(Boolean(wasRaw));if(wasFlowing!==true)input.pause();
  }