@yunhozz/arc 0.1.3 → 0.1.5

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,18 +264,11 @@ 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.
 
+
+
 [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.
-- [role.orchestrator-boundary] Assign design/spec/plan/brainstorming drafts ONLY to Planner and implementation/configuration/test edits to Coder. Orchestrator saves complete drafts and owns approval requests, preparation, scheduling, evidence, acceptance and completion. Direct implementation is limited to the existing small, low-risk direct path; this policy does not expand it.
-- [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.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.
 - [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.

package/codex/skill/references/verification.md

@@ -5,30 +5,81 @@ QA and
 Reviewer contracts are in their profiles; they read this file only for sections the brief explicitly cites.
 Visual companion design discussion is distinct from QA UI acceptance.
 
+For Orchestrator, **Evidence verdict**: each criterion is proven, unmet, or unverified; passing runs, reports, or disposition never turn unverified into proven; reports keep unverified scope visible.
+
 ## Risk-scaled execution
 
-SKILL.md Risk-scaled execution holds the risk table, risk definitions, evidence-reuse rule, and role order,
+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.
+
+| Risk | Minimum flow |
+|---|---|
+| Small, low risk | Coder, or Orchestrator direct path → Orchestrator's focused checks → acceptance |
+| Ordinary behavior | Coder → independent QA → acceptance |
+| Significant/high risk | Coder → QA → independent Reviewer of the final full change → acceptance; with a plan, each plan task Coder → FRESH QA → acceptance/commit satisfies the QA step, then independent Reviewer once on the final full change after all plan tasks |
+
+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
+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.
+
+Do not add per-task QA or review gates solely because a task boundary exists. Reviewer is never a plan-task acceptance
+prerequisite; for significant work with a plan, it reviews the final full change once after all plan tasks are accepted
+with their risk-scaled checks, following the last plan task's required checks and any QA recheck at the final relevant
+state; significant work without a plan keeps Reviewer after QA before acceptance. Preserve specific approved
+obligations. If the next task depends on a still-unverified risky contract, complete applicable QA at that dependency
+boundary and resolve or explicitly disposition findings before dependent implementation.
+Reuse evidence only when scope, relevant state, independence, freshness, and flow
+position satisfy each covered requirement; changes, failures, or missing/conflicting evidence invalidate affected reuse.
+QA checks independently without edits; Reviewer reviews without QA, planning, edits, delegation, or completion
+decisions. Orchestrator routes fixes to Coder (a failed direct-path check returns to the normal flow),
+obtains affected QA rechecks outside the final plan Reviewer correction exception and required final review, and accepts after findings/evidence gaps are resolved or
+explicitly dispositioned.
+
+Criterion verdicts follow the Evidence verdict.
+
+### 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.
+
+
+
+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 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
@@ -45,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
@@ -70,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.
@@ -90,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.
 
@@ -119,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,
@@ -145,16 +174,7 @@ actual unmet condition and report what is needed to resume. Structural evidence
 
 [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.
-- [role.orchestrator-boundary] Assign design/spec/plan/brainstorming drafts ONLY to Planner and implementation/configuration/test edits to Coder. Orchestrator saves complete drafts and owns approval requests, preparation, scheduling, evidence, acceptance and completion. Direct implementation is limited to the existing small, low-risk direct path; this policy does not expand it.
-- [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.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.
 - [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.

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/installer/global-config.mjs

@@ -1,4 +1,3 @@
-import{defaultRolePolicy,renderPolicySection}from'../policy/render.mjs';
 import{languagePolicy}from'./language.mjs';
 import{isDeepStrictEqual}from'node:util';import{parseToml}from'../models/config.mjs';
 export class GlobalConfigurationError extends Error{constructor(message,options){super(message,options);this.name='GlobalConfigurationError';this.code='ARC_GLOBAL_CONFIGURATION';}}
@@ -40,4 +39,4 @@ export function renderWaitSettings(original){
  return{content:Buffer.from(updated),action:'set ARC wait settings'};
 }
 export function agentsBlockBody(home,userHome,language='en',platform='codex'){const skill=home+'/skills/arc/SKILL.md',within=skill.startsWith(userHome+'/'),shown=within?'~/'+skill.slice(userHome.length+1):skill;return '- '+languagePolicy(language)+'\n'+'- For requests requiring substantive multi-step research, analysis, or implementation, configuration, or test work, and for design, spec, plan, and brainstorming requests (these are NOT standalone document writing), load and follow `'+shown+'`; keep following it in relevant follow-up turns of the same chat without re-reading it unless it changed.'+(within?" Resolve `~` to the current user's home directory.":'')+' ARC subagents (depth 2) follow their role profile and brief instead and do not load `SKILL.md`.\n'+'- Design, spec, plan, and brainstorming drafts are authored ONLY by the Planner. Orchestrator MUST NEVER author them; route drafting skills to the Planner.\n'+
-'- For repository implementation, configuration, or test work, Orchestrator owns coordination and acceptance; assign file edits and other work to the other roles according to their defined responsibilities. Orchestrator must not edit implementation, configuration, or test-code files directly, except under the ARC Orchestrator direct path for small, low-risk tasks.\n'+'\n[ARC role policy: global begin]\n'+renderPolicySection(defaultRolePolicy,{platform,audience:'orchestrator',section:'contract',skillPath:shown})+'\n[ARC role policy: global end]\n';}
+'- For repository implementation, configuration, or test work, Orchestrator owns coordination and acceptance; assign file edits and other work to the other roles according to their defined responsibilities. Orchestrator must not edit implementation, configuration, or test-code files directly, except under the ARC Orchestrator direct path for small, low-risk tasks.\n';}

package/lib/policy/placement.mjs

@@ -0,0 +1,25 @@
+// Instruction placement only; runtime policy and role authority remain canonical.
+const reviews = ['review.significant-no-plan', 'review.significant-plan', 'review.final-plan-recheck'];
+export const POLICY_PROJECTIONS = Object.freeze(Object.fromEntries(Object.entries({
+  core: ['scope.non-escalation', 'external.explicit-user-authority', 'role.orchestrator-boundary'],
+  assignment: ['git.specialists-deny', 'role.scouter-read-only', 'role.planner-draft-only', 'role.coder-implementation', 'role.qa-verification', 'role.reviewer-independent'],
+  planning: ['git.orchestrator-accept-commit', ...reviews],
+  handoff: ['git.specialists-deny', 'role.coder-implementation', ...reviews],
+  preparation: ['scope.non-escalation', 'git.specialists-deny', 'git.orchestrator-accept-commit', 'external.explicit-user-authority'],
+  verification: ['git.orchestrator-accept-commit', ...reviews],
+  commit: ['scope.non-escalation', 'git.orchestrator-accept-commit', 'external.explicit-user-authority'],
+}).map(([name, ids]) => [name, Object.freeze(ids)])));
+
+export function validatePolicyProjections(policy, projections = POLICY_PROJECTIONS) {
+  const canonical = new Set(policy.rules.map(rule => rule.id));
+  const covered = new Set();
+  for (const [name, ids] of Object.entries(projections)) {
+    const seen = new Set();
+    for (const id of ids) {
+      if (!canonical.has(id)) throw new Error(`Role policy: unknown projection rule ${id} in ${name}`);
+      if (seen.has(id)) throw new Error(`Role policy: duplicate projection rule ${id} in ${name}`);
+      seen.add(id); covered.add(id);
+    }
+  }
+  for (const id of canonical) if (!covered.has(id)) throw new Error(`Role policy: uncovered projection rule ${id}`);
+}

package/lib/policy/render.mjs

@@ -1,4 +1,5 @@
 import {renderSourceClaudeHook} from './claude-hook.mjs';
+import {POLICY_PROJECTIONS, validatePolicyProjections} from './placement.mjs';
 import {validateGitPolicy} from '../../claude/skill/hooks/role-git-guard.mjs';
 import source from './role-policy.json' with {type: 'json'};
 const ROLES = ['orchestrator','scouter','planner','coder','qa','reviewer'];
@@ -28,15 +29,22 @@ export function validateRolePolicy(input) {
 }
 export const defaultRolePolicy = source;
 export const POLICY_TARGETS = ['codex','claude'].flatMap(platform => [
-  {path:`${platform}/skill/SKILL.md`,platform,audience:'orchestrator'},
+  {path:`${platform}/skill/SKILL.md`,platform,audience:'orchestrator',projection:'core'},
   ...ROLES.slice(1).map(audience=>({path:`${platform}/agents/arc-${audience}.${platform==='codex'?'toml':'md'}`,platform,audience})),
-  ...['planning','handoff','handoff-prep','commit','verification'].map(name=>({path:`${platform}/skill/references/${name}.md`,platform,audience:'orchestrator'})),
+  ...Object.entries({coordination:'assignment',planning:'planning',handoff:'handoff','handoff-prep':'preparation',commit:'commit',verification:'verification'}).map(([name,projection])=>({path:`${platform}/skill/references/${name}.md`,platform,audience:'orchestrator',projection})),
 ]);
 POLICY_TARGETS.splice(POLICY_TARGETS.length-1,0,{path:'claude/skill/hooks/git-policy.json',platform:'claude',audience:'specialists',asset:'git'});
-export function renderPolicySection(policy, {platform, audience, section = 'contract', skillPath} = {}) {
+export function renderPolicySection(policy, {platform, audience, section = 'contract', skillPath, projection = 'full'} = {}) {
   validateRolePolicy(policy);
   if (!['codex','claude'].includes(platform) || !ROLES.includes(audience) || !['contract','global'].includes(section)) fail('unknown render target');
-  const rules = policy.rules.filter(rule=>section === 'global' || audience === 'orchestrator' || rule.roles.includes(audience));
+  let selected;
+  if (projection !== 'full') {
+    if (!Object.hasOwn(POLICY_PROJECTIONS, projection)) fail('unknown policy projection');
+    if (audience !== 'orchestrator') fail('specialist rendering requires full projection');
+    validatePolicyProjections(policy);
+    selected = new Set(POLICY_PROJECTIONS[projection]);
+  }
+  const rules = policy.rules.filter(rule=>selected ? selected.has(rule.id) : section === 'global' || audience === 'orchestrator' || rule.roles.includes(audience));
   const lines = ['Generated from lib/policy/role-policy.json; do not edit this managed section manually.', ...rules.map(rule=>`- [${rule.id}] ${rule.text}`), ...(section === 'global' ? [] : [`- [platform.${platform}] ${policy.platforms[platform].notice}`])];
   if (skillPath !== undefined) { if(typeof skillPath !== 'string' || !skillPath || /[\r\n]/.test(skillPath)) fail('invalid skill path'); lines.push(`- Policy details: \`${skillPath}\`.`); }
   return lines.join('\n');

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@yunhozz/arc",
-  "version": "0.1.3",
+  "version": "0.1.5",
   "publishConfig": {
     "access": "public",
     "registry": "https://registry.npmjs.org/"