@rryando/arcs 3.4.0 → 3.4.2

package/opencode/arcs/skills/quick-dev/SKILL.md

@@ -17,7 +17,7 @@ flowchart TD
     K --> B{Fully bounded?}
     B -->|Yes| C[Execute change directly]
     B -->|No| D[Escalate to code-agent or brainstorming]
-    C --> E[Verify: typecheck + lint + affected tests]
+    C --> E[Verify scoped: tsc --noEmit + lint + tests for touched files]
     E --> F[Done — commit only when asked]
 ```
 
@@ -33,13 +33,13 @@ Check for patterns, gotchas, and lessons before implementing. Skip only if the c
 
 1. Orient with ARCS context + search if pattern-related
 2. Execute directly — no planning doc, no brainstorming, no TDD ritual
-3. Run focused verification (not full suite unless pervasive)
+3. Scoped verification only — run the dispatch VERIFY command (tests + lint for files you touched). NEVER the full suite. Pervasive change (shared types, config, build) or failures in out-of-scope files → report under BLOCKED_BY, never fix; full-project verification belongs to the devil-advocate completion gate.
 
 ## Escalation
 
 If hidden complexity surfaces mid-task — **pause immediately**, state the issue, offer to switch to `code-agent` or `brainstorming`. Do not silently expand scope.
 
-If self-confidence drops below 80% per `confidence-gate` (open decision, unverified assumption, sibling pattern unclear), escalate to `code-agent` — `quick-dev` does not permit exploration loops; `code-agent` does.
+If self-confidence drops below 80% (open decision, unverified assumption, sibling pattern unclear), escalate to `code-agent` — `quick-dev` does not permit exploration loops; `code-agent` does.
 
 ## NOT for
 

package/opencode/arcs/skills/requesting-code-review/SKILL.md

@@ -18,9 +18,9 @@ flowchart TD
     C --> D[Fill code-reviewer.md template]
     D --> E[Dispatch arcs:code-reviewer subagent]
     E --> F{Review results}
-    F -->|Critical| G[Fix immediately]
-    F -->|Important| H[Fix before proceeding]
-    F -->|Minor| I[Note for later]
+    F -->|CRITICAL| G[Fix immediately]
+    F -->|HIGH| H[Fix before proceeding]
+    F -->|MEDIUM/LOW| I[Note for later]
     G --> E
     H --> E
 ```
@@ -30,18 +30,22 @@ flowchart TD
 - `{WHAT_WAS_IMPLEMENTED}` — what you built
 - `{PLAN_OR_REQUIREMENTS}` — what it should do
 - `{BASE_SHA}` / `{HEAD_SHA}` — commit range
-- `{PROJECT_CONVENTIONS}` — CLAUDE.md / linter configs / style guides
+- `{PROJECT_CONVENTIONS}` — CLAUDE.md / linter configs / style guides (gather once per session, reuse across dispatches)
 
 ## When to Request
 
-**Mandatory:** after each subagent task, after major features, before merge to main.
+**Mandatory:** after major features, before merge to main.
+**Already scheduled:** when `subagent-driven-development` drives the loop, its pipeline dispatches this review as stage 2 (code-quality-reviewer applies this template's checklist but returns the SDD JSON envelope) — do not schedule it twice for the same task.
 **Optional:** when stuck, before refactoring, after complex bugfix.
 
 ## Red Flags
 
 - Never skip because "it's simple"
-- Never ignore Critical issues
-- Never proceed with unfixed Important issues
+- Never ignore CRITICAL findings
+- Never proceed with unfixed HIGH findings
 - Always include project conventions in reviewer context
+- CRITICAL/HIGH fixes route to the owning implementer — never fix files outside your own scope
 
 See template at: `requesting-code-review/code-reviewer.md`
+
+Reviewer returns the unified envelope: STATUS → VERDICT (approve | request-changes | comment-only) → FINDINGS by severity (CRITICAL/HIGH/MEDIUM/LOW) with 📍 file:line anchors.

package/opencode/arcs/skills/requesting-code-review/code-reviewer.md

@@ -1,14 +1,14 @@
 # Code Review Agent
 
-You are reviewing code changes for production readiness. Write your findings like a thoughtful teammate, not a linter.
+You are reviewing code changes for production readiness. Your output is consumed by the orchestrator (an LLM) — structured, terse, evidence-backed findings.
 
 **Your task:**
 1. Read the project conventions below **before judging anything**
 2. Review {WHAT_WAS_IMPLEMENTED}
 3. Compare against {PLAN_OR_REQUIREMENTS}
 4. Check code quality, architecture, testing
-5. Categorize issues by severity with inline diff anchors
-6. Assess production readiness
+5. Categorize findings by severity with 📍 file:line anchors
+6. Deliver VERDICT: approve | request-changes | comment-only
 
 ## Project Conventions
 
@@ -57,7 +57,7 @@ git diff {BASE_SHA}..{HEAD_SHA}
 - Tests actually test logic (not mocks)?
 - Edge cases covered?
 - Integration tests where needed?
-- All tests passing?
+- Scoped verification passing — the dispatch VERIFY command only? Do NOT run the full suite — the completion gate owns it.
 
 **Requirements:**
 - All plan requirements met?
@@ -73,107 +73,67 @@ git diff {BASE_SHA}..{HEAD_SHA}
 
 ## Output Format
 
-### Strengths
-[What's well done? Be specific. Sound like a colleague giving genuine praise, not a form response.]
+No prose narrative. No "Overall this looks..." — open with the Standard Return Envelope, then VERDICT, then FINDINGS grouped by severity.
 
-### Issues
+When dispatched via subagent-driven-development, return its JSON envelope instead (see code-quality-reviewer-prompt.md).
 
-All issues must include a **file:line anchor** pointing to the specific diff line. Write in a collegial tone — direct but not harsh.
-
-#### Critical (Must Fix)
-[Bugs, security issues, data loss risks, broken functionality]
-
-#### Important (Should Fix)
-[Architecture problems, missing features, poor error handling, test gaps]
+```
+STATUS: done | blocked | partial
 
-#### Minor (Nice to Have)
-[Code style, optimization opportunities, documentation improvements]
+FILES_TOUCHED: none   (review-only — you never edit)
 
-**For each issue:**
-```
-📍 path/to/file.ts:42
-  Change: [what changed — show old → new if helpful]
-  Finding: [what looks off]
-  Why it matters: [practical impact]
-  Suggested direction: [concrete fix or question]
-```
+VERIFY: <scoped VERIFY command from dispatch> → pass|fail   (omit when the dispatch provides none)
 
-**Tone guide:**
-- "Heads up — this can throw if X is null (line 42), since you removed the guard"
-- "Worth double-checking: the fallback here (line 88) looks unreachable given the condition above"
-- "Minor nit: this magic number (line 130) could be a named constant for readability"
+BLOCKED_BY: <only when blocked/partial — what prevented a complete review>
 
-Not:
-- "VIOLATION: null check missing"
-- "This is wrong"
+VERDICT: approve | request-changes | comment-only
 
-### Recommendations
-[Improvements for code quality, architecture, or process — written as suggestions, not mandates]
+FINDINGS:
+- [CRITICAL] 📍 <file:line> — <issue> — <why it matters> — <suggested fix>
+- [HIGH] 📍 <file:line> — <issue> — <why it matters> — <suggested fix>
+- [MEDIUM] 📍 <file:line> — <issue> — <suggested fix>
+- [LOW] 📍 <file:line> — <issue>
 
-### Assessment
+TASKS: <none | suggested follow-up tasks for orchestrator>
 
-**Ready to merge?** [Yes/No/With fixes]
+YAGNI: <none | speculative code identified with file:line>
+```
 
-**Reasoning:** [Technical assessment in 1-2 sentences]
+Every finding carries a **📍 file:line anchor** pointing to the specific diff line. Severity guide: CRITICAL (bugs, security, data loss, broken functionality) → HIGH (architecture problems, missing features, poor error handling, test gaps) → MEDIUM (convention deviations) → LOW (style, optimization opportunities, documentation).
 
 ## Critical Rules
 
 **DO:**
 - Read project conventions before evaluating style or patterns
-- Categorize by actual severity (not everything is Critical)
-- Be specific with file:line anchors
+- Categorize by actual severity (not everything is CRITICAL)
+- Be specific with 📍 file:line anchors
 - Explain WHY issues matter
-- Acknowledge strengths
-- Give clear verdict
-- Sound like a teammate, not a linter
+- Give a clear VERDICT
 
 **DON'T:**
 - Flag something as wrong if it matches the project's own conventions
 - Say "looks good" without checking
-- Mark nitpicks as Critical
+- Mark nitpicks as CRITICAL
 - Give feedback on code you didn't review
 - Be vague ("improve error handling")
-- Avoid giving a clear verdict
-- Use harsh or robotic phrasing
+- Omit the VERDICT
+- Wrap the envelope in prose narrative
 
 ## Example Output
 
 ```
-### Strengths
-- Clean database schema with proper migrations (db.ts:15-42) — easy to follow
-- Comprehensive test coverage (18 tests, all edge cases hit)
-- Good error handling with fallbacks (summarizer.ts:85-92)
-
-### Issues
-
-#### Important
-
-1. 📍 index-conversations:1-31
-   Change: Added CLI wrapper without help flag
-   Finding: No --help flag; users won't discover --concurrency
-   Why it matters: Discoverability — first-time users will hit a wall
-   Suggested direction: Add `--help` case with a short usage example
-
-2. 📍 search.ts:25-27
-   Change: Added date filtering without validation
-   Finding: Invalid dates silently return no results instead of erroring
-   Why it matters: Silent failures are hard to debug
-   Suggested direction: Validate ISO format and throw with an example date
-
-#### Minor
+STATUS: done
 
-1. 📍 indexer.ts:130
-   Change: Added batch loop with no progress output
-   Finding: Long operations give no feedback
-   Suggested direction: A simple "X of Y" counter would help
+FILES_TOUCHED: none
 
-### Recommendations
-- Consider a config file for excluded projects — hardcoded list will grow
-- Progress reporting would meaningfully improve UX for large repos
+VERDICT: request-changes
 
-### Assessment
+FINDINGS:
+- [HIGH] 📍 index-conversations:1-31 — no --help flag; users won't discover --concurrency — first-time users hit a discoverability wall — add a `--help` case with a short usage example
+- [HIGH] 📍 search.ts:25-27 — invalid dates silently return no results instead of erroring — silent failures are hard to debug — validate ISO format and throw with an example date
+- [LOW] 📍 indexer.ts:130 — batch loop gives no progress feedback on long runs — a simple "X of Y" counter would help
 
-**Ready to merge: With fixes**
+TASKS: config file for excluded projects — hardcoded list will grow
 
-**Reasoning:** Core implementation is solid with good architecture and tests. The Important issues (help text, date validation) are quick fixes and don't affect core functionality.
+YAGNI: none
 ```

package/opencode/arcs/skills/subagent-driven-development/SKILL.md

@@ -44,10 +44,15 @@ flowchart TD
     R -->|yes| T[Mark task done]
     T --> U{More tasks?}
     U -->|yes| B
-    U -->|no| V[Dispatch final cross-task reviewer]
-    V --> W[Load skill: finishing-a-development-branch]
+    U -->|no| V[Dispatch devil-advocate PHASE: completion — the single full-project pass]
+    V -->|PASS| W[Report completion]
+    V -->|BLOCK| X[Re-dispatch scoped fixes per FAILURES] --> V
 ```
 
+**Gate cap:** two consecutive completion BLOCKs → stop and escalate to human; never loop the V→X cycle a third time.
+
+**Under the ARCS orchestrator:** the orchestrator's devil-advocate PHASE: execute gate replaces the code-quality reviewer step (the gate runs the scoped VERIFY and the drift check); spec review remains. Running standalone, keep both reviewer stages as drawn.
+
 ## Retry & Escalation
 
 ```mermaid
@@ -84,8 +89,9 @@ Every implementer subagent prompt MUST include:
 | **Context** | Where this task fits in the plan; what came before |
 | **Scope** | File boundaries — what to touch, what NOT to touch |
 | **Acceptance** | Done criteria copied verbatim from plan/diagram |
-| **Verify** | Exact command to run before claiming done |
+| **Verify** | Exact command to run before claiming done — scoped to the task's files, never the full suite |
 | **Skill** | Which work-mode skill to load (from diagram metadata or inferred) |
+| **Return** | Structured Return envelope (below) — brief prose findings first, JSON block last |
 
 Do NOT make the subagent read the plan file. Provide full text in the prompt.
 
@@ -102,15 +108,25 @@ Do NOT make the subagent read the plan file. Provide full text in the prompt.
 - `./implementer-prompt.md`
 - `./spec-reviewer-prompt.md`
 - `./code-quality-reviewer-prompt.md`
-- `./return-schema.md` — structured output format (inject into every dispatch)
 
 ## Structured Return
 
-All sub-agents MUST return a JSON block as the final thing in their message, per `./return-schema.md`.
-Orchestrator parses `status` for routing, `payload` for action. Free-form prose above is fine.
+All sub-agents MUST return a JSON block as the LAST thing in their message — brief prose findings first, JSON block last, nothing after it:
+
+```json
+{
+  "status": "DONE | DONE_WITH_CONCERNS | BLOCKED | NEEDS_CONTEXT",
+  "summary": "<1-2 sentences>",
+  "payload": { "<role-specific fields per prompt template>": "..." }
+}
+```
+
+Role payloads: implementer → `filesChanged`/`filesCreated`/`verification{command,result,scopeReason}`/`concerns`/`scopeChanges`; spec reviewer → `compliant`/`issues`; quality reviewer → `approved`/`issues`.
+Orchestrator parses `status` for routing, `payload` for action.
+Mapping to the orchestrator's Standard Return Envelope: DONE→done, DONE_WITH_CONCERNS→done + concerns surfaced, BLOCKED→blocked, NEEDS_CONTEXT→blocked.
 
 Include in every dispatch prompt:
-> "Return format: JSON envelope with status + typed payload. See return-schema.md for your role's schema."
+> "Return format: brief prose findings first, then the JSON envelope (status + typed payload) from your role's prompt template as the LAST thing in your message — nothing after it."
 
 ## Git State Discipline
 
@@ -129,10 +145,13 @@ Sub-agents lint and test **only files they touched**:
 |-------|---------|----------|
 | Lint | `biome check src/changed.ts` | `biome check .` |
 | Test | `vitest run test/changed.test.ts` | `vitest run` / `npm test` |
-| Type check | `tsc --noEmit` (whole-project — exception) | — |
+| Type check | `tsc --noEmit` — read-only signal; out-of-scope errors are report-only | fixing type errors outside your scope |
 
-Full suite justified ONLY when change is pervasive (shared types, config, build).
-Sub-agent must state `scopeReason` in return payload.
+Sub-agents NEVER run the full suite — not even for pervasive changes. If a change is pervasive
+(shared types, config, build), record it in `scopeChanges`/`concerns`; the orchestrator defers
+full-project verification to the devil-advocate completion gate. Type errors or test failures in
+files outside your scope are report-only — never fix them; the authoritative project-wide tsc run
+belongs to that gate. Sub-agent must state `scopeReason` in return payload.
 
 ## Parallelism Rules
 
@@ -140,7 +159,7 @@ Parallel implementers are allowed when tasks touch **zero shared files**.
 
 1. **Independence check:** Orchestrator verifies no file overlap before dispatch. If overlap → serialize.
 2. **Batch limit:** Maximum 4 concurrent subagents per round. Queue remaining.
-3. **Prompt construction:** Each subagent gets: Scope, Goal, Context, Constraints, Output format — all required.
+3. **Prompt construction:** Per the Sub-Agent Prompt Construction table above — all rows required.
 4. **Conflict detection:** After fan-out completes, check for conflicting edits before committing.
 5. **Shared context:** Fetch once (e.g., project brief), inject into all subagent prompts — don't make each agent re-fetch.
 

package/opencode/arcs/skills/subagent-driven-development/code-quality-reviewer-prompt.md

@@ -8,7 +8,8 @@ Use this template when dispatching a code quality reviewer subagent.
 
 ```
 Task tool (arcs:code-reviewer):
-  Use template at requesting-code-review/code-reviewer.md
+  Apply the review dimensions/checklist from requesting-code-review/code-reviewer.md.
+  Output format: the JSON envelope defined below — NOT the template's envelope+VERDICT format.
 
   WHAT_WAS_IMPLEMENTED: [from implementer's report]
   PLAN_OR_REQUIREMENTS: Task N from [plan-file]
@@ -25,7 +26,7 @@ Task tool (arcs:code-reviewer):
 
 ## Report Format (MANDATORY)
 
-Return prose explanation followed by this EXACT JSON block as the LAST thing in your message:
+Return brief prose findings FIRST, then this EXACT JSON block as the LAST thing in your message — nothing after it:
 
 ```json
 {

package/opencode/arcs/skills/subagent-driven-development/implementer-prompt.md

@@ -18,13 +18,9 @@ Task tool (general-purpose):
 
     ## Before You Begin
 
-    If you have questions about:
-    - The requirements or acceptance criteria
-    - The approach or implementation strategy
-    - Dependencies or assumptions
-    - Anything unclear in the task description
-
-    **Ask them now.** Raise any concerns before starting work.
+    If the requirements, acceptance criteria, approach, dependencies, or anything in the
+    task description is unclear or insufficient: do NO work — immediately return status
+    NEEDS_CONTEXT listing the specific questions.
 
     ## Your Job
 
@@ -38,8 +34,8 @@ Task tool (general-purpose):
 
     Work from: [directory]
 
-    **While you work:** If you encounter something unexpected or unclear, **ask questions**.
-    It's always OK to pause and clarify. Don't guess or make assumptions.
+    **While you work:** If you encounter something unexpected or unclear, don't guess or
+    make assumptions — stop and return BLOCKED or NEEDS_CONTEXT with the specific question.
 
     ## Git Rules
 
@@ -55,10 +51,14 @@ Task tool (general-purpose):
     Lint and test ONLY the files you touched:
     - Lint: `biome check src/your-file.ts` (NOT `biome check .`)
     - Test: `vitest run test/your-file.test.ts` (NOT `vitest run` or `npm test`)
-    - Type check: `tsc --noEmit` (this one is whole-project — exception)
+    - Type check: `tsc --noEmit` is allowed as a read-only signal — if it reports errors
+      in files OUTSIDE your scope, do NOT fix them; record them under `concerns` and
+      proceed. The authoritative project-wide tsc run belongs to the devil-advocate gate.
 
-    Full suite only when your change is pervasive (shared types, config, build).
-    You MUST state why your verification scope is sufficient in your report.
+    NEVER run the full suite — not even for pervasive changes. If your change is pervasive
+    (shared types, config, build), record it in `scopeChanges`. Failures you observe in
+    files outside your scope are report-only — leave them untouched.
+    You MUST state why your verification scope is sufficient in your report (`scopeReason`).
 
     ## Code Organization
 
@@ -118,7 +118,7 @@ Task tool (general-purpose):
 
     ## Report Format (MANDATORY)
 
-    When done, return prose explanation followed by this EXACT JSON block as the LAST thing in your message:
+    When done, return brief prose findings FIRST, then this EXACT JSON block as the LAST thing in your message — nothing after it:
 
     ```json
     {

package/opencode/arcs/skills/subagent-driven-development/spec-reviewer-prompt.md

@@ -57,7 +57,7 @@ Task tool (general-purpose):
 
     ## Report Format (MANDATORY)
 
-    Return prose explanation followed by this EXACT JSON block as the LAST thing in your message:
+    Return brief prose findings FIRST, then this EXACT JSON block as the LAST thing in your message — nothing after it:
 
     ```json
     {

package/opencode/arcs/skills/systematic-debugging/SKILL.md

@@ -43,7 +43,7 @@ flowchart TD
 
     Fix --> WriteFail[Write failing test]
     WriteFail --> Implement[Single targeted fix]
-    Implement --> Green{Tests pass?}
+    Implement --> Green{Scoped tests pass?}
     Green -->|Yes| Capture[Capture as ARCS knowledge]
     Green -->|No| FailCount
 
@@ -78,8 +78,8 @@ flowchart TD
 
 - Write a failing test FIRST (proves the bug exists)
 - Implement a single targeted fix
-- Verify all tests pass
-- If fix introduces new failures, revert and return to Phase 2
+- Verify the scoped tests for the files you changed pass (your dispatch VERIFY command — never the full suite; the devil-advocate completion gate owns that)
+- If your fix introduces new failures in YOUR scoped tests, revert and return to Phase 2. Failures in files outside your scope are report-only (BLOCKED_BY) — likely a sibling agent's in-flight work; never fix or revert it
 
 ## Log Triage Protocol
 

package/opencode/arcs/skills/systematic-debugging/root-cause-tracing.md

@@ -84,9 +84,9 @@ async function gitInit(directory: string) {
 
 **Critical:** Use `console.error()` in tests (not logger - may not show)
 
-**Run and capture:**
+**Run and capture (scoped to the suspect test file — never the full suite):**
 ```bash
-npm test 2>&1 | grep 'DEBUG git init'
+npm test -- path/to/suspect.test.ts 2>&1 | grep 'DEBUG git init'
 ```
 
 **Analyze stack traces:**

package/opencode/arcs/skills/test-driven-development/SKILL.md

@@ -21,11 +21,11 @@ flowchart TD
     B -->|Passes immediately| D[Test is wrong — fix or delete]
     D --> A
     C --> E{Run test}
-    E -->|All pass| F[Refactor — keep green]
+    E -->|Your tests pass| F[Refactor — keep green]
     E -->|Fails| C
     F --> G{More behavior needed?}
     G -->|Yes| A
-    G -->|No| H[Done — verify all green]
+    G -->|No| H[Done — your test files green, scoped VERIFY passes]
 ```
 
 ## Iron Law
@@ -35,12 +35,12 @@ Code written before a test? **Delete it.** No "reference", no "adapting". Start
 ## RED — Write Failing Test
 
 - One behavior per test, clear name, real code (no mocks unless unavoidable)
-- Run: `npm test path/to/test.test.ts` — confirm fails for the right reason
+- Run: `npm test -- path/to/test.test.ts` — confirm fails for the right reason
 
 ## GREEN — Minimal Code
 
 - Simplest code to pass. Nothing beyond what the test requires.
-- Run: confirm all tests pass, output pristine
+- Run: re-run YOUR test file(s) (`npm test -- path/to/test.test.ts`) — confirm they pass, output pristine. Never the unscoped suite; the devil-advocate completion gate owns full-project verification.
 
 ## REFACTOR — Clean Up
 

package/opencode/arcs/skills/test-driven-development/tdd-rationalizations-and-examples.md

@@ -66,7 +66,7 @@ test('rejects empty email', async () => {
 
 ### Verify RED
 ```bash
-$ npm test
+$ npm test -- submitForm.test.ts
 FAIL: expected 'Email required', got undefined
 ```
 
@@ -82,7 +82,7 @@ function submitForm(data: FormData) {
 
 ### Verify GREEN
 ```bash
-$ npm test
+$ npm test -- submitForm.test.ts
 PASS
 ```
 

package/opencode/arcs/skills/to-diagram/SKILL.md

@@ -142,6 +142,8 @@ Between plan-level header and `flowchart TD` declaration:
 
 **Required:** node, title, status, skill, scope, acceptance. **Optional:** files, verify, blocked-by, delegate.
 
+`verify` must name a command scoped to the node's files (e.g. `npm test -- --testPathPattern=orders`, `vitest run test/orders.test.ts`) — never the bare full suite (`npm test`, `vitest run`). The devil-advocate completion gate owns the single full-project pass.
+
 ## Plan-Level Header Comments
 
 ```
@@ -182,7 +184,7 @@ Plans with 15+ nodes: cluster into `subgraph` blocks by phase. If unreadable, sp
 - **Ownership:** Only orchestrator/coordinator writes .mmd files. Sub-agents read only and report status back
 - **Presentation:** Internal skill — never narrate conventions to user. Show rendered diagram or URL only
 - **Determinism:** Same metadata must produce byte-identical .mmd output (nodes ordered by ID, edges by source→target, fields in fixed order)
-- **Confidence gate:** Self-score ≥80% via confidence-gate skill before writing .mmd files
+- **Confidence gate:** Self-score ≥80% before writing .mmd files
 - **Validation before write:** unique IDs, valid edges, all 4 classDef present, valid :::class suffixes
 - **Backward compat:** Plans without .mmd remain valid; diagrams without rich metadata upgraded during SYNC
 

package/opencode/arcs/skills/writing-plans/SKILL.md

@@ -138,6 +138,8 @@ Diagrams are **agentic execution maps** in separate `.mmd` files — never embed
 
 All nodes start `:::backlog` but metadata must be fully populated at creation time for diagram-first execution.
 
+Per-node `verify` commands MUST be scoped to that task's files (e.g. `npm test -- tests/exact/path/test.py`, `vitest run test/orders.test.ts`) — never the bare full suite (`npm test`, `vitest run`, `biome check .`). The devil-advocate completion gate owns the single full-project pass.
+
 ## Plan Review Loop
 
 ```mermaid
@@ -153,7 +155,7 @@ flowchart TD
 
 - Chunk boundaries: `## Chunk N: <name>`, ≤1000 lines each
 - Same agent fixes (preserves context). Max 5 iterations, then surface to human.
-- Reviewer must announce confidence score per `confidence-gate`. Score <80% loops back to "Fix chunk" — never proceed past a sub-threshold review.
+- Reviewer must announce a confidence score (0-100). Score <80% loops back to "Fix chunk" — never proceed past a sub-threshold review.
 
 ## Storage
 

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@rryando/arcs",
-  "version": "3.4.0",
+  "version": "3.4.2",
   "description": "ARCS — DAG-based task orchestration for AI agents. Persistent workflow continuity via graph-structured context.",
   "type": "module",
   "main": "dist/index.js",

package/scripts/arcs-init.mjs

@@ -76,6 +76,7 @@ if (!isCommandAvailable("gh")) {
 
 if (!isCommandAvailable("rtk")) {
   console.warn(`WARNING: rtk not found.`);
-  console.warn(`  RTK improves AI command usage tracking: https://github.com/rtk-ai/rtk`);
-  console.warn(`  Install: rtk init -g  (or rtk init -g --opencode for OpenCode)`);
+  console.warn(`  RTK cuts agent token usage on shell commands: https://github.com/rtk-ai/rtk`);
+  console.warn(`  Install: brew install rtk`);
+  console.warn(`  Then wire it up: rtk init -g  (add --opencode to also wire OpenCode)`);
 }