@yunhozz/arc 0.1.4 → 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,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/package.json

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