@rune-kit/rune 2.15.0 → 2.16.0

package/README.md

@@ -83,7 +83,19 @@ _Methodology: Claude Code CLI headless mode (`claude -p --output-format json`),
 
 ---
 
-## What's New (v2.15.0 — Second Opinion + Cross-Provider + Routing Clarity)
+## What's New (v2.16.0 — Skill Enrichment + Triage Workflow + Output Modes)
+
+- **`debug` v1.2.0 — Step 0: Build Feedback Loop** — 10-rank ladder (failing test → curl → CLI snapshot → headless browser → trace replay → throwaway harness → fuzz → bisection → differential → HITL script). Codifies "the loop is the speed limit" — a fast deterministic pass/fail signal turns debugging into mechanical bisection. Skip if repro is already < 5s and deterministic; > 10 min loop construction triggers 3-Fix Escalation (architecture is the problem).
+- **`plan` v1.6.0 — Vertical Slice Mode** — tracer-bullet task decomposition. Each task = end-to-end path through schema + API + UI + test, demoable on its own. AFK / HITL classification. Stops "horizontal layer" planning that blocks on the slowest layer.
+- **`context-engine` v1.2.0 — Caveman Output Mode** — auto-activates on context ORANGE / RED (or `/caveman`). Strips filler / articles / hedging / pleasantries while preserving full technical accuracy (~75% output reduction). Auto-clarity exceptions for security warnings, destructive-action confirmations, multi-step sequences, root-cause diagnosis.
+- **`ba` v0.13.0 — Synthesis Mode + Out-of-Scope WRITE** — when prior conversation has rich context (pasted spec, > 1000 words, continuation session), extract Requirements Document with source citations and confirm instead of re-interviewing. Step 1.6 closes the `.out-of-scope/` write loop: explicit mid-elicitation rejections produce a durable `.out-of-scope/<slug>.md` record so future sessions don't re-litigate.
+- **`context-pack` v0.3.0 — Agent Brief Variant** — durable handoff format for AFK agents (issue tracker queues, autopilot multi-session work). Behavioral over procedural; type names over file:line. Survives codebase drift between handoff and execution.
+- **`review-intake` v1.3.0 — Issue Triage Mode** — new mode for issue tracker items (PR Review remains default). State machine: needs-triage → needs-info / ready-for-agent / ready-for-human / wontfix. Repro-first HARD-GATE for bugs (calls `debug` Step 0 if multi-component). Vague issues route to `ba` Synthesis Mode for grilling. AGENT-BRIEF emission for `ready-for-agent`.
+- **5 new mesh signals** — `output.density.set`, `triage.classified`, `agent.brief.ready`, `outofscope.recorded` + `EXTERNAL_TRIGGER_SIGNALS` whitelist concept (symmetric to `INTENTIONAL_BROADCAST_SIGNALS`).
+- **Validator cleanups** — `validate-skills.js` Done-When regex relaxed (scope-aware, supports mode-based subsections); 9 pre-existing validation errors cleaned. `validate-signals.js` gained `EXTERNAL_TRIGGER_SIGNALS` set.
+- **Provenance** — second graft pass from [`mattpocock/skills`](https://github.com/mattpocock/skills) (MIT). Round 1 had silently grafted 7 patterns (improve-architecture, CONTEXT.md, design-it-twice, zoom-out, oracle-mode, grill, out-of-scope); Round 2 + 2b documented + extended.
+
+### Previous (v2.15.0 — Second Opinion + Cross-Provider + Routing Clarity)
 
 - **`adversary` v0.2.0 — Mode: oracle** — when `agent.stuck` fires from `debug` (3 disproved hypotheses) or `fix` (2+ failed attempts), oracle-mode dispatches a stateless second-model pass with explicit "no prior context" framing. Bundle format is regex-validated (`[SYSTEM]` invariant role-priming + `[USER]` template + `### File N`), token-capped (100k bundle, 4k per file, 12 files max), citation-required reply contract. Secrets auto-redacted. Breaks the confirmation-bias loop that scout's zoom-out (structural pivot) cannot.
 - **`session-bridge` v0.8.0 — Detach Mode** — async escalation primitive. Heavy-model second-opinion calls (1-10 min wall time) no longer block the primary agent. `.rune/oracle-pending/<sessionId>.json` is the rendezvous file; idempotent dispatch (bundleHash-keyed); 10min default timeout; 24h orphan cleanup on session start. `cook` Phase 4 and `team` Phase 3 reattach via filesystem poll between adjacent tasks.

package/compiler/__tests__/skill-description-quality.test.js

@@ -12,10 +12,12 @@
 
 import assert from 'node:assert';
 import { readdirSync, readFileSync, statSync } from 'node:fs';
-import { join, resolve } from 'node:path';
+import { dirname, join, resolve } from 'node:path';
 import { describe, test } from 'node:test';
+import { fileURLToPath } from 'node:url';
 
-const SKILLS_DIR = resolve(import.meta.dirname, '../..', 'skills');
+const __dirname = dirname(fileURLToPath(import.meta.url));
+const SKILLS_DIR = resolve(__dirname, '../..', 'skills');
 
 function listSkills() {
   return readdirSync(SKILLS_DIR).filter((name) => {

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@rune-kit/rune",
-  "version": "2.15.0",
+  "version": "2.16.0",
   "description": "63-skill mesh for AI coding assistants — runtime auto-discipline via native hooks (Claude/Cursor/Windsurf/Antigravity), 5-layer architecture, 215+ connections, multi-platform compiler.",
   "type": "module",
   "bin": {
@@ -16,6 +16,7 @@
     "format": "biome format --write .",
     "ci": "biome check . && node --test compiler/__tests__/*.test.js scripts/__tests__/*.test.js && node compiler/bin/rune.js doctor",
     "version-check": "node scripts/version-sync-check.js",
+    "version-bump": "node scripts/bump-version.js",
     "prepublishOnly": "node scripts/version-sync-check.js"
   },
   "keywords": [

package/skills/ba/SKILL.md

@@ -3,12 +3,12 @@ name: ba
 description: "Business Analyst agent. Use when starting a new feature requiring requirements elicitation BEFORE plan or cook. Asks probing questions, identifies hidden requirements, maps stakeholders, defines scope boundaries, and produces a structured Requirements Document that plan and cook consume."
 metadata:
   author: runedev
-  version: "0.11.0"
+  version: "0.13.0"
   layer: L2
   model: opus
   group: creation
-  tools: "Read, Glob, Grep"
-  emit: outofscope.match
+  tools: "Read, Write, Glob, Grep"
+  emit: outofscope.match, outofscope.recorded
 ---
 
 # ba
@@ -73,7 +73,26 @@ If Refactor → light version (Step 1 + Step 4 only). Skip Steps 2, 2.5, 3, 5, 6
 
 If existing codebase → invoke `rune:scout` for context before proceeding.
 
-### Step 1.5 — Out-of-Scope Match Check
+### Step 1.4 — Synthesis Trigger Check
+<MUST-READ path="references/synthesis-mode.md" trigger="when prior conversation already contains rich requirement context (pasted spec, > 1000 words discussion, continuation session, filled issue template)"/>
+
+Before proceeding to elicitation, check whether the requirements are **already in context**. Re-asking what the user already told you is the second-most expensive bug.
+
+Activate **Synthesis Mode** instead of standard elicitation if ANY of:
+
+| Signal | Threshold |
+|--------|-----------|
+| User pasted a spec / PRD / brief | > 200 words describing the feature |
+| Conversation has > 1000 words on this feature | Sufficient context already gathered |
+| User said "synthesize" / "I already explained" / "just write the spec" | Explicit synthesis request |
+| Continuation — `.rune/features/<name>/requirements.md` exists with prior answers | Re-elicitation would duplicate |
+| Issue tracker has filled-in template (problem, story, acceptance criteria) | Source already structured |
+
+In Synthesis Mode: extract answers from existing context, draft the Requirements Document with **source citations** for every section, then **confirm** rather than re-interview. Ask follow-ups ONLY on the 1-2 dimensions with genuine gaps. Skip steps 2, 2.5 if all 5 dimensions are filled or partial-but-acceptable.
+
+Workflow detail + anti-patterns: [references/synthesis-mode.md](references/synthesis-mode.md).
+
+### Step 1.5 — Out-of-Scope Match Check (READ)
 
 Before any elicitation, check whether the request matches a concept previously rejected.
 
@@ -99,6 +118,50 @@ If verdict is exact-match AND user accepts the prior rejection → end the BA se
 
 Format reference: [references/out-of-scope-format.md](references/out-of-scope-format.md).
 
+### Step 1.6 — Mid-Elicitation Reject WRITE Path
+
+If the user **explicitly rejects** the feature at any point during elicitation (Steps 2-3) — common phrases: "scrap it", "actually nah, don't build this", "we won't do this", "kill the feature", "drop it" — STOP elicitation and **write a `.out-of-scope/<slug>.md` record** before ending the session.
+
+Without this WRITE path, oral rejections vanish — the next session re-asks the same questions and the user has to re-reject. Step 1.5 (READ) only catches matches against existing files; Step 1.6 (WRITE) is what produces those files in the first place.
+
+<HARD-GATE>
+Mid-elicitation rejection MUST produce a `.out-of-scope/<slug>.md` file before session end.
+A rejection without a written record is a rejection that didn't happen.
+</HARD-GATE>
+
+**Procedure**:
+
+1. **Confirm rejection is durable, not deferral**. Ask one clarifier:
+   > "Just to record this correctly: is this **out of scope** (project doesn't want this), or **deferred** (not now but maybe later)? Out-of-scope gets recorded so we don't re-litigate; deferred goes to backlog instead."
+
+   - If **deferred** → route to backlog (no `.out-of-scope/` write), end session with a one-line note
+   - If **out-of-scope** → continue to step 2
+
+2. **Capture the durable reason**. Ask:
+   > "What's the reason this is out of scope? (project scope, technical constraint, strategic decision — not a temporary circumstance)"
+
+   If the user gives a temporary reason ("we're busy"), reframe: "That's a deferral — should I route to backlog instead?"
+
+3. **Generate slug** (kebab-case, ≤40 chars, recognizable without opening the file).
+
+4. **Lexical-similarity check**: `Glob` `.out-of-scope/*.md`, parse each frontmatter's `concept` + `aliases`, compute overlap. If any existing concept has ≥0.7 overlap → APPEND to that file's `prior_requests` list and mark `rejected_by: ba` for this round. Do NOT create a duplicate.
+
+5. **Write the file** using the format in [`references/out-of-scope-format.md`](references/out-of-scope-format.md):
+   - YAML frontmatter (`concept`, `aliases`, `decision: rejected`, `rejected_at`, `rejected_by: ba`, `prior_requests`, optional `revisit_if`)
+   - Markdown body: concept name, "Why out of scope" (substantive reasoning from step 2), "What would change our mind" (if user volunteered signals)
+
+6. **Emit `outofscope.recorded`** signal carrying `{slug, rejected_by: ba, prior_requests_count}` so downstream skills know a new rejection landed.
+
+7. **End BA session** with one-line summary:
+   > "Recorded as out of scope in `.out-of-scope/<slug>.md`. Future similar requests will surface this. Override anytime by editing the file."
+
+**When NOT to write**:
+
+- User merely defers ("not now") → backlog, not `.out-of-scope/`
+- User rejects a single requirement within a larger feature → adjust requirements doc Boundaries section, don't write a whole rejection file (the feature is still in scope)
+- Bug rejections (already fixed, not reproducible) → not BA's job; route to incident or close the issue
+- The match was already exact (≥0.8) and Step 1.5 surfaced it — user accepting the prior rejection just appends to `prior_requests` of the existing file (handled in Step 1.5 path)
+
 ### Step 2.0 — Explore-First Pre-Check (HARD-GATE)
 
 Before emitting ANY of the 5 elicitation questions, run the 4-item pre-check on each intended question:
@@ -663,6 +726,11 @@ Known failure modes for this skill. Check these before declaring done.
 | User asserts behavior; agent records user's version without grep verification | HIGH | Step 2.6 HARD-GATE: every "the system does X" assertion gets grep'd; conflicts surface to user before recording |
 | Silently re-defining an existing CONTEXT.md term | HIGH | Step 7.5 conflict gate: ≥0.7 overlap → user chooses merge/rename/keep-distinct |
 | Auto-creating an empty CONTEXT.md when no terms emerged | LOW | Lazy creation rule: only write when there's a non-trivial term to record |
+| Mid-elicitation rejection ("scrap it") that ends the session without writing `.out-of-scope/` | CRITICAL | Step 1.6 HARD-GATE: explicit rejection MUST produce `.out-of-scope/<slug>.md` before session end — oral rejections vanish, force re-litigation next session |
+| Writing `.out-of-scope/` for a deferral instead of routing to backlog | MEDIUM | Step 1.6 procedure step 1: confirm "out of scope" vs "deferred" — temporary reasons go to backlog, not the rejection KB |
+| Running 5-question elicitation when conversation already contains rich context | HIGH | Step 1.4: synthesis-trigger check fires before Step 2 — pasted spec / >1000 words / continuation / explicit "synthesize" → switch to Synthesis Mode (extract + cite + confirm), don't re-interview |
+| Synthesizing requirements without source citations | HIGH | Synthesis Mode requires citing source for every dimension (user message N, pasted doc, continuation file). User cannot verify interpretation without citations |
+| Auto-handoff to plan after synthesis without explicit user "go"/"locked" confirmation | HIGH | Synthesis is interpretation, not transcription. Without explicit confirmation, drift becomes a downstream bug |
 | Asking inferable questions ("what stack are you using?") without first checking package.json | HIGH | Step 2.0 HARD-GATE — every question requires prior tool-call evidence (Read/Glob/Grep) or explicit unavailability declaration |
 | Re-asking a question already answered earlier in the conversation | MEDIUM | Step 2.0 check 4 — cache and reuse, never re-ask |
 

package/skills/ba/references/synthesis-mode.md

@@ -0,0 +1,105 @@
+# Synthesis Mode (Chat → Requirements Without Re-Interview)
+
+When the conversation already contains rich context — user described the feature in detail, pasted a spec, or worked through requirements iteratively — running the 5 Questions again wastes attention and breaks rapport. Synthesis mode extracts the Requirements Document from existing context, then **confirms** rather than re-interviewing.
+
+> Re-asking what the user already told you is the second-most expensive bug after wrong requirements. The first is wrong requirements shipped correctly.
+
+## When to use synthesis (skip the 5 Questions)
+
+Trigger synthesis instead of elicitation if ANY of:
+
+| Signal | Threshold |
+|--------|-----------|
+| User pasted a spec / PRD / brief | Any document > 200 words describing the feature |
+| Conversation has > 1000 words discussing this feature | Sufficient context already gathered |
+| User said "I already explained — just write the spec" / "synthesize" / "build the requirements" | Explicit synthesis request |
+| Session is a continuation — prior session captured most answers in `.rune/features/<name>/requirements.md` | Re-elicitation would duplicate |
+| Issue tracker / external ticket has filled-in template (problem, user story, acceptance criteria) | Source already structured |
+
+If NONE match → fall back to standard elicitation (Step 2 — 5 Questions).
+
+## Synthesis workflow
+
+### Step S1 — Sweep context
+
+Pull from in this order:
+1. The current conversation (every message from user, in order)
+2. Pasted documents (spec, PRD, ticket body)
+3. `.rune/features/<feature>/requirements.md` if continuation
+4. Codebase signals (only if needed for inference — `package.json`, `README.md`)
+
+### Step S2 — Extract answers to the 5 dimensions
+
+Map existing context onto the same 5 dimensions used in elicitation:
+
+| Dimension | Where to look |
+|-----------|---------------|
+| **WHO** (user, technical level, surrounding workflow) | "users who...", personas, role mentions |
+| **WHAT** (specific outcome, definition of done) | Acceptance criteria, "should", "must", success metrics |
+| **WHY** (problem, consequence of not building) | "because", "to avoid", problem statement, motivation |
+| **BOUNDARIES** (out of scope) | "not", "won't", "later", "v2", "future" |
+| **CONSTRAINTS** (tech, perf, security, deadline) | Tech stack mentions, perf targets, deadlines, integrations |
+
+For each dimension, mark **filled** | **partial** | **gap**.
+
+### Step S3 — Identify ONLY the gaps
+
+If all 5 dimensions are **filled** or **partial-but-acceptable** → skip directly to Step S4. No questions.
+
+If 1-2 dimensions are **gap** → ask ONLY those questions, single round, multiple-choice format. Never ask all 5 over again.
+
+If 3+ dimensions are **gap** → synthesis context wasn't actually rich; fall back to standard elicitation (Step 2).
+
+### Step S4 — Draft Requirements Document
+
+Use the standard Requirements Document format (same as elicitation output). For every dimension, cite the source:
+
+```markdown
+### Who
+[Synthesized statement]
+
+> _Source: user message at [timestamp/turn], "..."_
+```
+
+Citations are mandatory in synthesis mode — they let the user verify nothing was misread or invented.
+
+### Step S5 — Confirm, don't re-elicit
+
+Present the Requirements Document with this exact framing:
+
+> "I synthesized requirements from our conversation. **Read each section** — if anything is wrong or missing, tell me which line. If it's correct, say 'go' and I'll lock it for plan."
+
+Wait for explicit confirmation. Do NOT auto-proceed to plan handoff.
+
+User responses:
+- `"go"` / `"locked"` / `"correct"` → emit Requirements Document, hand off to plan
+- `"section X is wrong"` → revise that section only, re-confirm
+- `"add Y"` / `"actually..."` → treat as additional gap; ask multiple-choice if specific, otherwise add to Open Questions
+
+## Anti-patterns
+
+| Anti-pattern | Why it fails |
+|--------------|--------------|
+| Running 5 Questions after user pasted a 500-word spec | Burns trust — user already gave you the answers |
+| Synthesizing without citations | User can't verify; one misread becomes a downstream bug |
+| Auto-proceeding to plan after synthesis without confirmation | Synthesis is interpretation, not transcription. Confirmation prevents drift. |
+| Asking all 5 questions even when 4 dimensions are filled | Defeats the purpose. Ask 1, not 5. |
+| Treating "looks fine" as confirmation | Need explicit "go" or "locked" — vague approval = ambiguous handoff |
+
+## Integration with Step 1 (Intake & Classify)
+
+After classifying requirement type, branch:
+
+```
+Feature Request | Greenfield | Integration:
+  → Check synthesis triggers
+    → All filled (S2): synthesize + confirm (S4-S5)
+    → Partial (1-2 gaps): synthesize + targeted questions (S3-S5)
+    → Mostly empty (3+ gaps): fall back to standard elicitation (Step 2)
+Bug Fix:
+  → Skip BA entirely
+Refactor:
+  → Light BA (synthesis usually fits)
+```
+
+Synthesis mode is **opt-in via context detection**, not via user flag — the trigger is "rich context exists", not "user asked for it". The user shouldn't have to know which mode is active.

package/skills/context-engine/SKILL.md

@@ -4,12 +4,12 @@ description: "Context window management. Auto-triggered when context is filling
 user-invocable: false
 metadata:
   author: runedev
-  version: "1.1.0"
+  version: "1.2.0"
   layer: L3
   model: haiku
   group: state
   tools: "Read, Glob, Grep"
-  emit: context.preview
+  emit: context.preview, output.density.set
 ---
 
 # context-engine
@@ -103,9 +103,11 @@ Emit recommendation to the calling orchestrator:
 
 Identify the next safe boundary (end of current loop iteration, end of current file being processed) and flag it.
 
+**Auto-activate Caveman Output Mode** (see `references/caveman-mode.md`) — emit `output.density.set` with `mode=caveman, scope=session, source=context-orange`. Reduces output token cost ~75% with no information loss; persists until /compact returns context to GREEN. Manual override (`/caveman` or "stop caveman") always wins.
+
 ### Step 5 — If RED
 
-Immediately trigger state save via `rune:session-bridge` (Save Mode) before any compaction occurs.
+Immediately trigger state save via `rune:session-bridge` (Save Mode) before any compaction occurs. If caveman mode was not already active from ORANGE, emit `output.density.set` with `mode=caveman, scope=session, source=context-red` now.
 
 Pass to session-bridge:
 - Current task and phase description
@@ -377,6 +379,33 @@ When Context Budget Warning fires, append to Context Health report:
 - **Recommendation**: Disable [server] to save ~[N]k tokens
 ```
 
+## Output Density Mode (Caveman)
+<MUST-READ path="references/caveman-mode.md" trigger="when context reaches ORANGE/RED OR user says 'caveman'/'be brief'/'less tokens'"/>
+
+Caveman is a terse output mode that strips filler, articles, hedging, and pleasantries while preserving full technical accuracy. ~75% output token reduction with no information loss when applied per the rules in `references/caveman-mode.md`.
+
+### Activation triggers
+
+| Trigger | Source | Persistence |
+|---------|--------|-------------|
+| Context health = ORANGE or RED | Auto from Step 4-5 above | Until `/compact` returns to GREEN |
+| User says "caveman" / "/caveman" / "be brief" / "less tokens" | Explicit user signal | Until "stop caveman" / "normal mode" |
+| Per-workstream override (e.g., `team` worker exceeds output budget) | Per-workstream scope | Scoped to that workstream only |
+
+Auto-activation emits `output.density.set` signal carrying `{mode: caveman, scope, source}`. Orchestrators (cook, team, rescue) honor the signal for the duration of their session.
+
+### Auto-clarity exceptions (revert ONE response, then resume)
+
+- Security warnings (data loss, credential exposure)
+- Confirmations of irreversible actions (`rm -rf`, force-push, drop table, prod deploy)
+- Multi-step sequences where fragment ordering risks misreading
+- User says "explain" / "clarify" / repeats the same question
+- Root-cause diagnosis where cause-and-effect chains need grammatical structure
+
+### Anti-pattern
+
+Caveman in the FIRST response of a task. The user can't calibrate severity from a single output yet — verbose first response is fine. Caveman starts on response 2+.
+
 ## Mode: preview (v1.1.0)
 
 Pre-flight cost check for expensive escalations. Caller (`adversary` oracle-mode, `team` workstream spawn, `review` multi-file, `audit` cross-pack) MUST emit `context.preview` BEFORE building the bundle, so context-engine can estimate token cost and gate the dispatch against a per-caller threshold.
@@ -477,6 +506,10 @@ Known failure modes for this skill. Check these before declaring done.
 | Mid-loop compaction without flushing state first | HIGH | session-bridge + neural-memory MUST run before compaction — losing unsaved decisions is worse than hitting context limit |
 | (preview) Caller bundles before requesting preview | HIGH | Constraint 4 enforces order; reject preview-after-build calls with explicit error |
 | (preview) Estimated tokens off by 2x for non-English content | LOW | Document calibration in `references/preview-gate.md`; safe both directions (block-too-eager or block-too-late but hard cap at dispatch saves us) |
+| Caveman activated in first response of a task | MEDIUM | First response = user calibration baseline. Verbose first; caveman from response 2+ (see `references/caveman-mode.md`) |
+| Caveman compresses code blocks or error messages | CRITICAL | Caveman strips filler ONLY. Code, errors, paths, technical terms stay verbatim. Compression of those = wrong fix |
+| Caveman drift back to verbose mid-session | MEDIUM | Once activated, persists every response until explicit deactivation. Drift defeats the token savings |
+| Caveman during destructive-action confirmation | HIGH | Auto-clarity exception: revert ONE response for security/irreversible-action confirmations, then resume |
 
 ## Done When
 

package/skills/context-engine/references/caveman-mode.md

@@ -0,0 +1,107 @@
+# Caveman Output Mode
+
+A terse output mode that strips filler, articles, and pleasantries while preserving full technical accuracy. Reduces output token cost by ~75% with no information loss when applied correctly.
+
+> "All technical substance stays. Only fluff dies."
+
+## When to activate
+
+| Trigger | Source | Persistence |
+|---------|--------|-------------|
+| User says "caveman", "caveman mode", "be brief", "less tokens" | Explicit user signal | Until user says "stop caveman" / "normal mode" |
+| Context health = ORANGE or RED | Auto from `context-engine` Step 4-5 | Until context returns to GREEN after compaction |
+| Output budget exceeded for a workstream (e.g., team parallel worker) | Per-workstream override | Scoped to that workstream |
+
+Once active, **every response stays in caveman mode** until explicit deactivation. No drift back to verbose mid-session.
+
+## What dies
+
+- Articles: `a`, `an`, `the`
+- Filler: `just`, `really`, `basically`, `actually`, `simply`, `essentially`, `you can see that`
+- Pleasantries: `Sure!`, `Certainly`, `Of course`, `Happy to help`, `Great question`, `Let me`
+- Hedging: `I think`, `it seems`, `probably`, `might want to consider`
+- Connective bloat: `In order to`, `with regard to`, `at this point in time`
+- Restating the user's question
+
+## What stays (untouched)
+
+- Code blocks — exact, unmodified
+- Error messages — quoted verbatim
+- Technical terms — full names, no abbreviation if ambiguous
+- File paths and identifiers
+- Numbers, units, version strings
+
+## Techniques allowed
+
+| Technique | Example |
+|-----------|---------|
+| Sentence fragments | `Fixed.` instead of `I have fixed it.` |
+| Short synonyms | `big` not `extensive`, `use` not `utilize` |
+| Common abbreviations | `DB`, `auth`, `config`, `req`/`res`, `fn`, `impl`, `repo`, `env` |
+| Arrow notation for causality | `null input → crash at line 42 → fix: validate before parse` |
+| Skeleton pattern | `[thing] [action] [reason]. [next step].` |
+| Bullet over paragraph | List 3 things instead of writing a paragraph about them |
+
+## Auto-clarity exceptions (revert temporarily)
+
+Drop caveman for ONE response, then resume. Triggers:
+
+| Situation | Why revert |
+|-----------|------------|
+| Security warning (data loss, credential exposure, destructive command) | Fragments risk underweighting severity |
+| Confirming an irreversible action (`rm -rf`, force-push, drop table, deploy to prod) | User must understand what they're approving |
+| Multi-step sequence where order matters | Fragment ordering can be misread |
+| User says "explain" / "clarify" / repeats the same question | They want more, not less |
+| Diagnosis of a hard bug — root cause needs grammatical structure to be unambiguous | Cause-and-effect chains break in fragments |
+
+## Token savings (calibration)
+
+| Mode | Sample output for "explain X" | Tokens |
+|------|-------------------------------|--------|
+| Verbose | `Sure! So basically, the X function is responsible for handling the case where...` | ~80 |
+| Caveman | `X handles [case]. Fails on [edge]. Fix: [action].` | ~20 |
+
+Expect 60-80% reduction on conversational responses. Code/docs/error messages are unaffected (they were already pure information).
+
+## Examples
+
+### Verbose
+> Sure! So I've taken a look at the auth middleware and it seems like the issue might be that the token validation function is being called before the token is actually parsed. Basically what's happening is that we're trying to validate something that doesn't exist yet, which is causing the null reference error you're seeing.
+
+### Caveman
+> Auth middleware: `validate(token)` called before parse → null ref. Fix: parse first, then validate.
+
+### Verbose
+> Great question! Let me explain how this works. The retry logic is implemented using exponential backoff, which means that each retry waits longer than the previous one.
+
+### Caveman
+> Retry uses exponential backoff. Each attempt waits longer than last.
+
+### Caveman with security exception
+> Caveman normally — but for this one: **Warning**: `git push --force` will overwrite the remote `main` branch. This destroys any commits other developers have pushed in the meantime. Confirm explicitly before I run it.
+> 
+> [next response resumes caveman]
+
+## Integration with context-engine
+
+Auto-activation flow (Step 4 ORANGE / Step 5 RED):
+
+```
+1. context-engine detects ORANGE/RED
+2. Emit advisory: "Context [X]%. Activating caveman output mode."
+3. Set session flag: caveman_active = true
+4. All subsequent responses honor caveman rules
+5. On /compact + return to GREEN: emit "Caveman mode released" — back to normal
+```
+
+Manual override always wins: if user says "/caveman" while GREEN, activate; if user says "stop caveman" while RED, respect it (but emit warning that context is critical).
+
+## Anti-patterns
+
+| Anti-pattern | Why it fails |
+|--------------|--------------|
+| Compressing code or error messages | Information loss → wrong fix |
+| Using rare abbreviations the user might not know | Saves tokens, costs comprehension |
+| Caveman during security/destructive confirmation | User skips reading because format signals "low importance" |
+| Drifting back to verbose after a few turns | Mode must persist — drift defeats the purpose |
+| Caveman in the FIRST response of a task | User can't calibrate severity from the first output yet — verbose first response is fine |

package/skills/context-pack/SKILL.md

@@ -4,7 +4,7 @@ description: "Creates structured handoff briefings between agents. Use when dele
 user-invocable: false
 metadata:
   author: runedev
-  version: "0.2.0"
+  version: "0.3.0"
   layer: L3
   model: haiku
   group: state
@@ -134,6 +134,24 @@ When a parent agent delegates work to a subagent, critical context gets lost —
 
 Full template + worked examples: [references/brief-template.md](references/brief-template.md).
 
+## Variant: Agent Brief (Async / Durable Handoff)
+<MUST-READ path="references/agent-brief.md" trigger="when handing off to an AFK agent, an issue tracker queue, autopilot, or any receiver that may execute hours/days later"/>
+
+The standard packet (above) is for **immediate** sub-agent dispatch in the same session. When the handoff target is async — issue tracker, scheduled cron agent, `rune:autopilot` (Pro) for multi-session work, or any receiver that may execute hours or days later — switch to the **agent brief** variant.
+
+Agent brief adds two durability principles on top of the standard packet:
+
+1. **Durability over precision** — describe interfaces, types, and behavioral contracts. NEVER reference line numbers in narrative. File paths only in `### Files Touched` (locator-only, may rename).
+2. **Behavioral, not procedural** — describe WHAT the system should do, not HOW to implement it. The async agent will explore the codebase fresh.
+
+Additional BLOCK-tier checks for agent briefs (on top of the standard smell tests):
+- `**Category:**` line present (`bug` / `enhancement` / `refactor`)
+- Both `**Current behavior:**` and `**Desired behavior:**` sections present
+- Acceptance criteria are independently testable (each pass/fail alone)
+- `**Key interfaces:**` names types/functions, not file paths
+
+Full template + worked examples: [references/agent-brief.md](references/agent-brief.md).
+
 ## Returns
 
 | Field | Type | Description |
@@ -169,6 +187,9 @@ Full template + worked examples: [references/brief-template.md](references/brief
 | Missing Type Surface section for non-trivial task | HIGH | Mandatory for tasks >= 300 tokens; the durable spine is what survives file moves |
 | Missing Out of scope section | HIGH | Always required (even "(none)"); completion-gate rejects briefs without it |
 | Acceptance Criteria using shape verbs ("is defined", "has property") | MEDIUM | Rewrite to behavior verbs from the whitelist |
+| Async handoff (issue tracker / autopilot / scheduled run) emitted as standard packet | HIGH | Switch to agent-brief variant (`references/agent-brief.md`) — standard packet rots when receiver runs hours/days later. Brief adds durability rules: behavioral not procedural, no line numbers in narrative |
+| Agent brief with file:line references in narrative ("change `auth.ts:42`") | CRITICAL | Brief BLOCK gate — line numbers go stale on first edit. Reference type names, function signatures, contracts instead. File paths only in `### Files Touched` |
+| Agent brief without `**Current behavior:**` AND `**Desired behavior:**` split | HIGH | Brief BLOCK gate — without the delta explicit, async agent cannot verify when work is done |
 
 ## Self-Validation
 

package/skills/context-pack/references/agent-brief.md

@@ -0,0 +1,194 @@
+# Agent Brief (Durable Handoff Variant)
+
+A context-pack variant designed for **async handoff to AFK agents** — one-shot agents that pick up work hours or days later, without the live conversation context. The standard context-pack is for immediate sub-agent dispatch; the agent brief is for the handoff that may sit in a queue (issue tracker, task board, scheduled run).
+
+> The standard packet is a system prompt. The agent brief is a contract. Both must survive without the originating conversation; the brief must also survive code drift.
+
+## When to use agent-brief vs standard packet
+
+| Variant | Use when |
+|---------|----------|
+| **Standard packet** (`Output Format` in SKILL.md) | Immediate dispatch — sub-agent runs in the same session, < 1 hour delay, codebase will not drift |
+| **Agent brief** (this file) | Async dispatch — task posted to issue tracker, scheduled run, or external worker. May sit for days. Codebase may rename/move files in the meantime. |
+
+Both share the same compression discipline. Agent brief adds **durability rules** to survive drift.
+
+## The two extra principles
+
+### 1. Durability over precision
+
+The brief may execute days later. Files renamed, moved, refactored. Write so the brief stays useful.
+
+| Do | Don't |
+|----|-------|
+| Describe interfaces, types, behavioral contracts | Reference file paths in narrative ("change `src/auth/login.ts`") |
+| Name specific types, function signatures, config shapes the agent should look for | Reference line numbers ("on line 42") |
+| Describe what to find ("the function that validates JWT tokens") | Assume current implementation structure stays the same |
+
+File paths can appear in `### Files Touched` (locator-only, may rename). They cannot appear in narrative.
+
+### 2. Behavioral, not procedural
+
+Describe **what** the system should do, not **how** to implement it. The agent will explore the codebase fresh and make implementation decisions.
+
+| Behavioral (good) | Procedural (bad) |
+|-------------------|------------------|
+| `SkillConfig` should accept an optional `schedule: CronExpression` field | Open `src/types/skill.ts` and add a `schedule` field on line 42 |
+| When user runs `/triage` with no args, show a summary of issues needing attention | Add a switch statement in the main handler |
+| Truncated descriptions end at last word boundary before 1024 chars and append `...` | Modify the `truncate()` function to check word boundaries |
+
+## Template
+
+```markdown
+## Agent Brief
+
+**Category:** bug | enhancement | refactor
+**Summary:** one-line description of what needs to happen
+
+**Current behavior:**
+What happens now. For bugs: the broken behavior. For enhancements: the status quo.
+
+**Desired behavior:**
+What should happen after the work is complete. Be specific about edge cases and error conditions.
+
+**Key interfaces:**
+- `TypeName` — what needs to change and why
+- `functionName(input: T): Result<O, E>` — current contract vs desired contract
+- Config shape — any new options needed
+
+**Acceptance criteria:**
+- [ ] Specific, independently testable criterion 1
+- [ ] Specific, independently testable criterion 2
+- [ ] Specific, independently testable criterion 3
+
+**Out of scope:**
+- Thing that should NOT be changed
+- Adjacent feature that might seem related but is separate
+- (or "(none)" if explicitly empty)
+
+**Files Touched (locator hints, may rename):**
+- `path/to/file.ts` (`TypeName`, `functionName`) — behavioral hint
+```
+
+## Worked example — bug
+
+```markdown
+## Agent Brief
+
+**Category:** bug
+**Summary:** Skill description truncation drops mid-word, producing broken output
+
+**Current behavior:**
+When a skill description exceeds 1024 characters, it is truncated at exactly 1024
+characters regardless of word boundaries. Output ends mid-word
+(e.g. "Use when the user wants to confi").
+
+**Desired behavior:**
+Truncation should break at the last word boundary before 1024 characters and
+append "..." to indicate truncation. Total length including "..." must not
+exceed 1024 chars.
+
+**Key interfaces:**
+- The `SkillMetadata` type's `description` field — no type change, but the
+  validation/processing logic that populates it needs to respect word boundaries
+- Any function that reads SKILL.md frontmatter and extracts the description
+
+**Acceptance criteria:**
+- [ ] Descriptions under 1024 chars are unchanged
+- [ ] Descriptions over 1024 chars are truncated at the last word boundary before 1024 chars
+- [ ] Truncated descriptions end with "..."
+- [ ] Total length including "..." does not exceed 1024 chars
+
+**Out of scope:**
+- Changing the 1024 char limit itself
+- Multi-line description support
+
+**Files Touched:**
+- `compiler/parser.js` (`extractDescription`) — likely truncation site
+- `compiler/__tests__/skill-description-quality.test.js` — add coverage
+```
+
+## Worked example — enhancement
+
+```markdown
+## Agent Brief
+
+**Category:** enhancement
+**Summary:** Add `.out-of-scope/` directory support for tracking rejected feature requests
+
+**Current behavior:**
+Rejected feature requests are closed with a `wontfix` label and a comment.
+No persistent record of decision or reasoning. Future similar requests require
+the maintainer to recall or search prior discussion.
+
+**Desired behavior:**
+Rejected feature requests are documented in `.out-of-scope/<concept>.md` files
+capturing decision, reasoning, and links to all issues that requested the
+feature. New issues are matched against these files during triage.
+
+**Key interfaces:**
+- Markdown file format in `.out-of-scope/` — each file has a `# Concept Name`
+  heading, `**Decision:**` line, `**Reason:**` line, `**Prior requests:**` list
+- The triage workflow reads all `.out-of-scope/*.md` files early and matches
+  incoming issues by concept similarity
+
+**Acceptance criteria:**
+- [ ] Closing a feature as wontfix creates/updates a file in `.out-of-scope/`
+- [ ] File includes the decision, reasoning, link to the closed issue
+- [ ] If a matching `.out-of-scope/` file already exists, the new issue is appended
+      to its "Prior requests" list rather than creating a duplicate
+- [ ] During triage, existing `.out-of-scope/` files are checked and surfaced
+      when a new issue matches a prior rejection
+
+**Out of scope:**
+- Automated matching (human confirms the match)
+- Reopening previously rejected features
+- Bug reports (only enhancement rejections go to `.out-of-scope/`)
+```
+
+## Anti-pattern (what makes a brief rot)
+
+```markdown
+## Agent Brief
+
+**Summary:** Fix the triage bug
+
+**What to do:**
+The triage thing is broken. Look at the main file and fix it.
+The function around line 150 has the issue.
+
+**Files to change:**
+- src/triage/handler.ts (line 150)
+- src/types.ts (line 42)
+```
+
+Rots because:
+- No category
+- Vague summary ("the triage thing")
+- Line numbers in narrative — go stale on first edit
+- File paths in narrative without behavioral hint
+- No acceptance criteria
+- No scope boundaries
+- No current vs desired behavior split
+
+## Smell test additions for agent-brief
+
+In addition to the BLOCK-tier smell tests in `context-pack/SKILL.md`, agent briefs MUST also pass:
+
+| Check | Tier | Reason |
+|-------|------|--------|
+| Has `**Category:**` line with `bug`, `enhancement`, or `refactor` | BLOCK | Agent uses category for routing decisions |
+| Has `**Current behavior:**` AND `**Desired behavior:**` sections | BLOCK | Without both, agent can't verify the delta |
+| Acceptance criteria are independently testable (each can pass/fail alone) | BLOCK | Bundled criteria hide partial completion |
+| `**Key interfaces:**` names actual types/functions, not file paths | BLOCK | The whole point of the brief — drift survival |
+| `**Out of scope:**` present (even `(none)`) | BLOCK | Prevents gold-plating |
+
+## Integration
+
+Use agent-brief when delegating to:
+- An issue tracker (GitHub issue, Linear, Jira) for an AFK agent to pick up
+- `rune:autopilot` (Pro) for autonomous multi-session work
+- A scheduled cron agent (`/schedule` for one-time follow-up)
+- Any handoff where the receiver may not see the originating conversation
+
+Use the standard packet for in-session subagent dispatch (cook → fix, team → workstream).

package/skills/cook/SKILL.md

@@ -217,7 +217,7 @@ Auto-trigger: no `.rune/` dir (first run) OR build just failed with env-looking
 
 1. Create TodoWrite with all applicable phases for this task
 2. Mark Phase 1 as `in_progress`
-3. **BA gate**: Feature Request / Integration / Greenfield → invoke `rune:ba`. Task > 50 words or business terms (users, revenue, workflow) → invoke `rune:ba`. Bug Fix / simple Refactor → skip. BA produces `.rune/features/<name>/requirements.md` for Phase 2.
+3. **BA gate**: Feature Request / Integration / Greenfield → invoke `rune:ba`. Task > 50 words or business terms (users, revenue, workflow) → invoke `rune:ba`. Bug Fix / simple Refactor → skip. BA produces `.rune/features/<name>/requirements.md` for Phase 2. **Synthesis-mode auto-trigger**: if user pasted a spec > 200 words, conversation has > 1000 words on this feature, `.rune/features/<name>/requirements.md` already exists (continuation), or user said "synthesize"/"just write the spec" → BA Step 1.4 activates Synthesis Mode (extract + cite sources + confirm), skipping the 5-question elicitation. Cook does NOT need to choose mode — BA detects automatically.
 4. **Decision enforcement**: `Glob` for `.rune/decisions.md`; if exists, `Read` + extract constraints for Phase 2. Plan MUST NOT contradict active decisions without explicit user override.
 4b. **Contract enforcement**: If `.rune/contract.md` was loaded in Phase 0.6, list applicable contract sections for this task (e.g., `contract.security` for auth work, `contract.data` for database changes). These rules constrain Phase 2 planning and Phase 4 implementation.
 
@@ -766,7 +766,7 @@ Mentally track tool call fingerprints. 3 identical calls → WARN. 5 identical c
 | 5 | `scope-guard` | L3 | Verify changed files match approved plan scope (flag out-of-scope files before commit) |
 | 5 | `perf` | L2 | Performance regression check (optional) |
 | 5 | `audit` | L2 | Project health audit when scope warrants |
-| 5 | `review-intake` | L2 | Structured review intake for complex PRs |
+| 5 | `review-intake` | L2 | Structured review intake for complex PRs OR Issue Triage Mode for issue tracker items (state machine: needs-triage / needs-info / ready-for-agent / ready-for-human / wontfix). When external feedback source is an issue (not PR comment), review-intake auto-detects and runs Issue Triage Mode — emits `triage.classified` + `agent.brief.ready` (for AFK pickup) |
 | 5 | `sast` | L3 | Static analysis security testing |
 | 5d | `completion-gate` | L3 | Validate agent claims against evidence trail |
 | 5 | `constraint-check` | L3 | Audit HARD-GATE compliance across workflow |

package/skills/debug/SKILL.md

@@ -3,7 +3,7 @@ name: debug
 description: "Root cause analysis for bugs and unexpected behavior. Traces errors through code, uses structured reasoning, and hands off to fix when cause is found. Core of the debug↔fix mesh."
 metadata:
   author: runedev
-  version: "1.1.0"
+  version: "1.2.0"
   layer: L2
   model: sonnet
   group: development
@@ -63,6 +63,17 @@ If root cause cannot be identified after 3 hypothesis cycles:
 
 ## Execution
 
+### Step 0: Build a Feedback Loop (the actual skill)
+<MUST-READ path="references/feedback-loop-ladder.md" trigger="when current repro is not a single command returning pass/fail in <5s, or when bug is intermittent/multi-component"/>
+
+**The loop is the speed limit.** A fast, deterministic, agent-runnable pass/fail signal turns debugging into mechanical bisection. Without one, hypotheses just consume noise.
+
+Skip Step 0 only if the existing repro is already one command, deterministic, and runs in < 5s.
+
+Otherwise, before Step 1: pick the highest viable rung from `references/feedback-loop-ladder.md` (10-rank ladder: failing test → curl → CLI snapshot → headless browser → trace replay → throwaway harness → fuzz → bisection → differential → HITL script). Construct it. Verify it currently FAILS (proves it measures the bug, not noise). Only then proceed.
+
+If loop construction takes > 10 minutes, that itself is the diagnosis: the bug surface is too large or the system too coupled. Trigger the 3-Fix Escalation Rule (Step 6) — architecture is the problem, not the bug.
+
 ### Step 1: Reproduce
 
 Understand and confirm the error described in the request.
@@ -349,6 +360,7 @@ ALL of these mean: STOP. Return to Step 2 (Gather Evidence).
 7. MUST NOT say "I know what's wrong" without citing file:line evidence
 8. For deep stack errors: MUST use backward tracing (Step 2) — never fix at the crash site
 9. For multi-component systems: MUST instrument boundaries before hypothesizing
+10. MUST run Step 0 (Build Feedback Loop) before forming hypotheses on non-trivial bugs — skipping the loop = guessing
 
 ## Output Format
 
@@ -415,7 +427,7 @@ Append to Debug Report when invoked standalone. Suppress when called as sub-skil
 ```yaml
 chain_metadata:
   skill: "rune:debug"
-  version: "1.1.0"
+  version: "1.2.0"
   status: "[DONE | DONE_WITH_CONCERNS | NEEDS_CONTEXT | BLOCKED]"
   domain: "[area debugged]"
   files_changed: []  # debug never changes files
@@ -449,6 +461,8 @@ chain_metadata:
 | Debug report recommends touching 5+ unrelated files | HIGH | Symptom of fixing at crash sites instead of source. Backward trace (Step 2) to find origin. If truly 5+ files → likely architectural issue → escalate via 3-Fix Rule |
 | Re-investigating known error patterns from scratch | MEDIUM | Step 2d: match error against Known Error Pattern Catalog first — skip hypothesis cycling for recognized patterns |
 | Same error fingerprint across cycles treated as different errors | MEDIUM | Step 2d: normalize line numbers, paths, variable names before comparison — same fingerprint = same error |
+| Forming hypotheses with a slow / non-deterministic / manual repro | CRITICAL | Step 0: build a fast deterministic pass/fail signal first — see `references/feedback-loop-ladder.md` 10-rank ladder. Hypothesis testing on a slow loop wastes 10x the cycles |
+| Skipping loop construction "to save time" on non-trivial bugs | HIGH | The loop IS the time-saver. 10 min on the loop saves hours of cycling. If construction takes > 10 min, escalate via 3-Fix Rule — bug is architectural |
 
 ## Done When
 

package/skills/debug/references/feedback-loop-ladder.md

@@ -0,0 +1,62 @@
+# Feedback Loop Ladder
+
+**The loop is the skill.** A fast, deterministic, agent-runnable pass/fail signal converts debugging into a mechanical bisection problem. Without one, no amount of file-reading will save you.
+
+> "The rate of feedback is your speed limit." Spend disproportionate effort on the loop itself — bisection, hypothesis testing, and instrumentation all just consume that signal.
+
+## When to invest in a better loop
+
+Run the ladder before Step 3 (Form Hypotheses) when ANY of these are true:
+
+| Signal | Threshold |
+|--------|-----------|
+| Repro is "click around in browser, then check" | Always — slowest possible loop |
+| Cycle 1 hypotheses ruled out, no faster signal exists | Required before cycle 2 |
+| Reproduction is intermittent (flaky) | Required — non-deterministic loop wastes cycles |
+| Bug spans 3+ components and you can't isolate where it fails | Build component-boundary instrumentation FIRST |
+| Manual repro takes > 30 seconds | Auto-script it before forming hypotheses |
+
+**Skip if:** repro is already a single command returning exit code 0/1 in < 5s. The loop is already optimal.
+
+## The ladder (try in order — stop at first viable rung)
+
+| # | Loop | Speed | Determinism | When |
+|---|------|-------|-------------|------|
+| 1 | **Failing test at the bug's seam** (unit, integration, e2e) | Fast | Hard pass/fail | Default — bug already has a test infrastructure |
+| 2 | **curl / HTTP script** against running dev server | Fast | Snapshot-diffable | API or backend bugs |
+| 3 | **CLI invocation with fixture input**, diff stdout vs known-good snapshot | Fast | Snapshot-diffable | CLI tools, parsers, formatters |
+| 4 | **Headless browser script** (Playwright / `rune:browser-pilot`) — drives UI, asserts on DOM/console/network | Medium | Reliable | UI bugs, JS errors, network failures |
+| 5 | **Replay a captured trace** — save real network request / payload / event log to disk; replay through code path in isolation | Fast | Deterministic | Bugs reproducible only with specific data |
+| 6 | **Throwaway harness** — minimal subset of system (one service, mocked deps), exercise bug code path with single function call | Fast | Isolated | Bug deep inside framework or service stack |
+| 7 | **Property / fuzz loop** — 1000 random inputs, look for failure mode | Slow | Probabilistic | "Sometimes wrong output", race conditions, edge cases |
+| 8 | **Bisection harness** — automate "boot at state X, check, repeat" so `git bisect run` works | Medium | Hard pass/fail | Bug appeared between two known commits / dataset versions |
+| 9 | **Differential loop** — same input through old vs new (or two configs), diff outputs | Medium | Diff-based | Regression vs reference implementation |
+| 10 | **HITL bash script** — last resort. Drive the human with a structured script | Slow | Human-error-prone | All else fails — at least the loop has structure |
+
+## What "good loop" looks like
+
+- One command, one second to run, one bit of output (pass / fail)
+- Deterministic — same input → same output, every time
+- Captures the bug, not a proxy ("test passes when bug present" is a broken loop)
+- Cleanup-safe — re-runnable without manual reset
+
+## Anti-patterns
+
+| Anti-pattern | Why it fails |
+|--------------|--------------|
+| "I'll just print and check the console" | Stateless, manual, slow — degrades to staring at logs |
+| "Let me read the code one more time" | Reading is not a loop. Loop = pass/fail signal. |
+| "It works on my machine, not in CI" | Build a loop in the CI environment FIRST |
+| Skipping loop construction because "it's complicated" | The loop is the skill. Skipping it = guessing for the next 5 cycles |
+
+## Integration with Step 0
+
+Add Step 0 (before Reproduce) when invoked on a non-trivial bug:
+
+```
+0. Build feedback loop — pick the highest rung from the ladder that you can construct
+   in < 10 minutes. Make it deterministic. Verify it currently FAILS (proves it's
+   measuring the bug, not noise). Only then proceed to Step 1.
+```
+
+If loop construction takes > 10 minutes, that itself is the diagnosis: the bug surface is too large or the system is too coupled. Escalate via 3-Fix Rule (architecture is the problem, not the bug).

package/skills/plan/SKILL.md

@@ -3,7 +3,7 @@ name: plan
 description: "Create structured implementation plans from requirements. Produces master plan + phase files for enterprise-scale project management. Master plan = overview (<80 lines). Phase files = execution detail (<150 lines each). Each session handles 1 phase. Uses opus for deep reasoning."
 metadata:
   author: runedev
-  version: "1.5.0"
+  version: "1.6.0"
   layer: L2
   model: opus
   group: creation
@@ -149,9 +149,12 @@ If ANY "Master + Phase Files" criterion is true → produce master plan + phase
 
 ### Step 3 — Decompose into Phases
 <MUST-READ path="references/wave-planning.md" trigger="when writing wave-structured task lists inside any phase"/>
+<MUST-READ path="references/vertical-slice.md" trigger="when decomposing a feature into tasks/issues — ALWAYS prefer vertical (end-to-end) slices over horizontal (single-layer) ones"/>
 
 Group work into phases. Each phase: completable in one session, clear "done when", produces testable output, independent enough to run without other phases loaded.
 
+**Vertical slices over horizontal layers**: each task within a phase MUST be a tracer-bullet slice (schema + API + UI + test, end-to-end), NOT a single-layer chunk. Horizontal slicing ("all models → all APIs → all UI") looks organized but blocks on the slowest layer. See `references/vertical-slice.md` for slice rules, AFK vs HITL classification, and the per-task slice template.
+
 <HARD-GATE>
 Each phase MUST be completable by ANY coder model (including Haiku) with ONLY the phase file loaded.
 If the coder would need to read the master plan or other phase files to execute → the phase file is missing detail.
@@ -163,7 +166,7 @@ Phase decomposition rules:
 - **Dependencies before consumers**: create what's imported before the importer
 - **Test alongside**: each phase includes its own test tasks
 - **Max 5-7 tasks per phase**: if more, split the phase
-- **Vertical slices over horizontal layers**: prefer "auth end-to-end" over "all models → all APIs → all UI"
+- **Vertical slices over horizontal layers**: prefer "auth end-to-end" over "all models → all APIs → all UI" (see `references/vertical-slice.md` for tracer-bullet template, AFK/HITL labels, granularity rules)
 
 Tasks within each phase MUST be organized into waves (parallel-safe groupings). See `references/wave-planning.md`.
 
@@ -346,7 +349,7 @@ Append to plan output when invoked standalone. Suppress when called as sub-skill
 ```yaml
 chain_metadata:
   skill: "rune:plan"
-  version: "1.5.0"
+  version: "1.6.0"
   status: "[DONE | DONE_WITH_CONCERNS | NEEDS_CONTEXT | BLOCKED]"
   domain: "[area planned]"
   files_changed:
@@ -385,7 +388,9 @@ chain_metadata:
 | Phase with zero test tasks | CRITICAL | HARD-GATE rejects it |
 | 10+ phases overwhelming the master plan | MEDIUM | Max 8 phases — split into sub-projects if more |
 | Task without File path or Verify command | HIGH | Every task MUST have File + Test + Verify + Commit fields — no vague "implement the feature" tasks |
-| Horizontal layer planning (all models → all APIs → all UI) | HIGH | Vertical slices parallelize better. Use wave-based grouping: independent tasks in same wave, dependent tasks in later waves |
+| Horizontal layer planning (all models → all APIs → all UI) | HIGH | Vertical slices parallelize better. Use wave-based grouping AND vertical-slice template (`references/vertical-slice.md`): each task = end-to-end path through schema/API/UI/test, demoable on its own |
+| Slice not demoable on its own ("just the migration", "just the UI shell") | HIGH | Per `references/vertical-slice.md` — every slice produces a verifiable outcome. Layer-only fragments block downstream slices and hide partial completion |
+| HITL slices marked liberally to enable "review" friction | MEDIUM | HITL is for hard blockers (OAuth setup, design decision, paid third-party access), not soft preferences. Default to AFK; use post-merge review for soft signals |
 | Tasks without `depends_on` in Wave 2+ | MEDIUM | Implicit dependencies break parallel dispatch. Every Wave 2+ task MUST declare `depends_on` |
 | Plan ignores locked Decisions from BA | CRITICAL | Decision Compliance section cross-checks requirements.md — locked decisions are non-negotiable |
 | Complex feature missing Workflow Registry — components planned but never wired | HIGH | Step 4.5: 4-view registry catches orphaned components, unphased workflows, and missing state transitions before phase files are written |

package/skills/plan/references/vertical-slice.md

@@ -0,0 +1,79 @@
+# Vertical Slice (Tracer-Bullet) Decomposition
+
+**Each slice is a thin path through ALL layers** — schema, API, UI, tests — that produces a demoable, verifiable outcome on its own. Prefer many thin slices over few thick ones.
+
+> Horizontal layers ("all models → all APIs → all UI") look organized but block on the slowest layer. Vertical slices ship in parallel and verify continuously.
+
+## Slice rules
+
+1. **End-to-end, not end-of-end** — every slice touches every layer it needs (schema migration + handler + UI + test). A slice that only adds a database column is not a slice; it's a fragment.
+2. **Demoable on its own** — when the slice is merged, you can demo it (or run a single command to verify). If demoing requires "and now switch to the other PR", the slices were drawn wrong.
+3. **Narrow but complete** — one user story, one happy path, minimal error handling. Edge cases are *separate slices*, not bigger versions of the same slice.
+4. **Independently grabbable** — any developer or agent should be able to pick up Slice N without reading Slice N+1. Dependencies declared explicitly, not implicit.
+
+## Slice types
+
+| Type | Definition | When |
+|------|------------|------|
+| **AFK** | Can be implemented and merged without human interaction. Spec is concrete enough that an agent (or the weakest model) executes it correctly. | Default — prefer wherever possible |
+| **HITL** | Requires human input mid-execution: architectural decisions, design review, copy approval, third-party access (OAuth setup, DNS, payment provider). | Only when AFK is genuinely impossible |
+
+**Bias toward AFK.** A slice marked HITL is friction — every HITL slice blocks the parallel queue. Before marking HITL, ask: can the human input be done ONCE upfront and then the slice is AFK?
+
+## Slice template (per task in a phase file)
+
+```markdown
+### Slice: [verb-led title]
+- **Type**: AFK | HITL
+- **Story**: As a [persona], I want to [action] so that [benefit]
+- **Path through layers**:
+  - Schema: [migration / type addition]
+  - API: [endpoint or function signature]
+  - UI: [component or surface]
+  - Test: [verification approach]
+- **Demoable**: [exact command or click-path that shows it works]
+- **Blocked by**: [slice IDs] | None — can start immediately
+- **Out of scope** (explicit): [what this slice does NOT cover]
+```
+
+## Granularity
+
+Right-sized slice:
+- Fits in one phase file (under the Amateur-Proof 200-line cap)
+- Completable in one session by Sonnet/Haiku
+- Touches 3-7 files total across all layers
+- Has exactly ONE acceptance criterion that proves the path works end-to-end
+
+If a slice has 5+ acceptance criteria → split it. If a slice touches 10+ files → split it. If two slices share 3+ files → merge or sequence them (file overlap = race condition in parallel execution).
+
+## Decomposition checklist
+
+Before approving a slice breakdown, verify:
+
+- [ ] Every slice can be demoed independently
+- [ ] No slice requires another in-flight slice to be merged first (declared deps OK; in-flight overlap NOT OK)
+- [ ] AFK / HITL labels are accurate — HITL slices have a specific blocking input named
+- [ ] Slice count matches granularity rule (3-7 slices for a typical feature; if 1 or 2, slice is too thick; if 15+, too thin)
+- [ ] First slice is the **smallest valuable end-to-end path** — proves the architecture works before scaling
+
+## Anti-patterns
+
+| Anti-pattern | Why it fails |
+|--------------|--------------|
+| Layer-1 slice ("just the database changes") | Not demoable, not verifiable, blocks every downstream slice |
+| Slice with "and the admin UI for it" appended | Hidden second slice — split |
+| 10 acceptance criteria on one slice | Granularity miss — slice is actually a feature |
+| Slice marked HITL because "I might want to review the design" | HITL is for hard blockers, not soft preferences. Use AFK + post-merge review. |
+| First slice is the most complex one ("let's build the hardest part first") | Wrong order. First slice proves architecture; complexity comes later when foundation is verified. |
+
+## Integration with phase planning
+
+Vertical slices map cleanly to phase wave structure:
+
+```
+Phase 1, Wave 1: Slice A (foundation slice — proves architecture end-to-end)
+Phase 1, Wave 2: Slice B, C (parallel — depend on A's contract, not on each other)
+Phase 2, Wave 1: Slice D, E (next layer of slices)
+```
+
+Each slice = one task in a wave. Use `touches[]` / `provides[]` / `requires[]` metadata (see Change Stacking in `plan/SKILL.md`) to detect file overlap between slices in the same wave.

package/skills/review-intake/SKILL.md

@@ -1,13 +1,14 @@
 ---
 name: review-intake
-description: "Use when receiving code review feedback, PR comments, or external suggestions before implementing any changes. Prevents blind implementation, enforces verification-first discipline."
+description: "Use when receiving external input that needs structured intake before action — PR review feedback, code review comments, OR issue tracker items (bug reports, feature requests). PR Review Mode (default) verifies suggestions before implementing. Issue Triage Mode classifies issues into a state machine (ready-for-agent / ready-for-human / needs-info / wontfix) and emits AGENT-BRIEFs for AFK execution. Prevents blind implementation, enforces verification-first discipline."
 metadata:
   author: runedev
-  version: "1.2.0"
+  version: "1.3.0"
   layer: L2
   model: sonnet
   group: quality
-  tools: "Read, Write, Edit, Glob, Grep"
+  tools: "Read, Write, Edit, Bash, Glob, Grep"
+  emit: triage.classified, agent.brief.ready
   listen: outofscope.match
 ---
 
@@ -17,11 +18,23 @@ metadata:
 
 The counterpart to `review`. While `review` finds issues in code, `review-intake` handles the response when someone finds issues in YOUR code. Enforces a verification-first discipline: understand fully, verify against codebase reality, then act. Prevents the common failure mode of blindly implementing suggestions that break things or don't apply.
 
+## Modes
+
+| Mode | When | Workflow |
+|------|------|----------|
+| **PR Review Mode** (default) | Input is PR comments / code review feedback / external suggestions | Phases 1-6 below — absorb, comprehend, verify, evaluate, respond, implement |
+| **Issue Triage Mode** | Input is issue tracker item (`gh-42`, URL, pasted issue body), or user says "triage" / "process the inbox" | See `references/issue-triage.md` — state machine (needs-triage → ready-for-agent / ready-for-human / needs-info / wontfix) + repro-first for bugs + AGENT-BRIEF emission |
+
+Both modes share Phase 4.5 (Rejection KB Write) — `wontfix-enhancement` from Issue Triage and OUT OF SCOPE from PR Review both write `.out-of-scope/<slug>.md`.
+
 ## Triggers
 
-- `/rune review-intake` — manual invocation when processing feedback
-- Auto-trigger: when `cook` or `fix` receives PR review comments
-- Auto-trigger: when user pastes review feedback into session
+- `/rune review-intake` — manual invocation, PR Review Mode by default
+- `/rune review-intake <issue-ref>` — Issue Triage Mode (issue number, URL, or path)
+- `/rune review-intake --inbox` — Issue Triage Mode batch sweep (unlabeled + needs-triage + needs-info-with-activity)
+- Auto-trigger: when `cook` or `fix` receives PR review comments → PR Review Mode
+- Auto-trigger: when user pastes review feedback into session → PR Review Mode
+- Auto-trigger: when user pastes an issue body or references a ticket → Issue Triage Mode
 
 ## Calls (outbound)
 
@@ -36,7 +49,10 @@ The counterpart to `review`. While `review` finds issues in code, `review-intake
 - `cook` (L1): Phase 5 quality gate when external review arrives
 - `review` (L2): when self-review surfaces issues to address
 
-## Workflow
+## Workflow (PR Review Mode)
+
+For Issue Triage Mode, see [references/issue-triage.md](references/issue-triage.md). Both modes converge at Phase 4.5 for rejection KB writes.
+<MUST-READ path="references/issue-triage.md" trigger="when input is an issue tracker item, batch inbox sweep, or user explicitly says 'triage' / 'process the inbox'"/>
 
 ### Phase 1 — ABSORB
 
@@ -245,6 +261,10 @@ How to push back:
 | OUT OF SCOPE verdict with no `.out-of-scope/` file written | HIGH | Phase 4.5 HARD-GATE — oral-only rejections force re-litigation in future sessions |
 | Writing a deferral ("busy this quarter") to `.out-of-scope/` | MEDIUM | Deferrals belong in backlog, not the rejection KB. KB entries must cite durable reasons (scope, tech constraint, strategy) |
 | Creating duplicate `.out-of-scope/` files for the same concept | MEDIUM | Lexical-similarity gate (≥0.7 overlap) — append to existing file's `prior_requests` instead of duplicating |
+| Marking issue `ready-for-agent` without confirmed repro (bugs) | CRITICAL | Issue Triage Mode Step T4 HARD-GATE: bugs MUST attempt reproduction before `ready-for-agent` label. Confirmed repro = strong agent-brief; failed repro = `needs-info` |
+| Auto-applying `wontfix` to an issue without maintainer confirmation | HIGH | Triage recommends, maintainer decides. State changes (label + comment + close) confirmed via Step T3 before Step T6 acts |
+| Posting triage comments without the AI-disclaimer line | MEDIUM | Issue Triage Mode requires `> *This was generated by AI during triage.*` disclaimer prefix on every comment — trust degrades when reporter discovers AI authorship after the fact |
+| Writing `.out-of-scope/` for a `wontfix-bug` (not enhancement) | MEDIUM | Format spec: only enhancement rejections produce KB files. Bug rejections (already fixed, not reproducible, not a bug) get a comment, not a file |
 
 ## Done When
 

package/skills/review-intake/references/issue-triage.md

@@ -0,0 +1,202 @@
+# Issue Triage Mode
+
+A second mode for `review-intake`. The default mode (PR comments) processes inbound review feedback. **Issue Triage Mode** processes inbound issue tracker items (GitHub Issues, Linear tickets, bug reports, feature requests) and routes them through a state machine.
+
+> The standard PR mode answers "should I implement this suggestion?". Issue Triage Mode answers "what state is this issue in, and who should pick it up next?".
+
+## When to use Issue Triage Mode
+
+Activate when input is an **issue** (not a PR review). Triggers:
+
+| Signal | Threshold |
+|--------|-----------|
+| User passes an issue reference (`/rune review-intake gh-42`, URL, or path) | Always |
+| User says "triage", "intake this issue", "process the inbox" | Explicit |
+| User pastes an issue body + comments rather than PR review feedback | Auto-detect — issue has reporter, not reviewer |
+| Batch mode: `/rune review-intake --inbox` queries unlabeled + needs-triage issues | Inbox sweep |
+
+Skip if input is PR review comments → use default PR Review Mode.
+
+## State machine
+
+Two dimensions per issue:
+
+| Category (1 of) | State (1 of) |
+|-----------------|--------------|
+| `bug` | `needs-triage` (unlabeled, never evaluated) |
+| `enhancement` | `needs-info` (waiting on reporter for more detail) |
+|  | `ready-for-agent` (fully specified, AFK agent can execute) |
+|  | `ready-for-human` (specified but needs human judgment — design decision, OAuth setup, copy approval) |
+|  | `wontfix` (explicit decision not to action) |
+
+Every triaged issue carries exactly one category and one state. Conflicts → flag and ask the maintainer before acting.
+
+State transitions (typical):
+
+```
+unlabeled  →  needs-triage  →  needs-info  →  needs-triage (after reporter replies)
+                            →  ready-for-agent
+                            →  ready-for-human
+                            →  wontfix
+```
+
+Maintainer can override at any time (quick state override below).
+
+## Workflow
+
+### Step T1 — Inbox view (if batch mode)
+
+Query the issue tracker for three buckets, oldest first:
+
+1. **Unlabeled** — never triaged
+2. **`needs-triage`** — evaluation in progress
+3. **`needs-info` with reporter activity since last triage notes** — needs re-evaluation
+
+Show counts + one-line summary per issue. Maintainer picks one.
+
+### Step T2 — Gather context (per-issue)
+
+Read the full issue: body, comments, labels, reporter, dates. Parse any prior triage notes so you don't re-ask resolved questions.
+
+Then scan:
+- `CONTEXT.md` — apply project glossary terms in your understanding
+- `docs/adr/` — respect Architecture Decision Records in the affected area
+- `.out-of-scope/*.md` — check for prior rejection that resembles this issue
+
+If the issue matches a prior `.out-of-scope/` entry (≥0.7 lexical overlap), surface it: *"This matches a prior rejection (`<slug>`). Recommend `wontfix` unless circumstances changed."* Wait for maintainer direction.
+
+### Step T3 — Recommend
+
+Tell the maintainer your category + state recommendation with reasoning. Include a brief codebase summary relevant to the issue. Wait for direction. Do not act unilaterally.
+
+### Step T4 — Reproduce (bugs only — HARD-GATE)
+
+<HARD-GATE>
+Bugs MUST attempt reproduction before being marked `ready-for-agent`. A confirmed repro is what makes the agent-brief strong; without it, the agent will guess.
+</HARD-GATE>
+
+Process:
+1. Read the reporter's repro steps
+2. Trace the relevant code via `rune:scout` / `rune:debug`
+3. If the repro is a HTTP request / CLI invocation / browser flow → run it
+4. Report outcome:
+   - **Confirmed repro** with code path → strong `ready-for-agent` signal
+   - **Failed repro** → likely `needs-info` (ask for env, version, exact steps)
+   - **Insufficient detail** → `needs-info` with specific questions
+
+If the bug is multi-component or intermittent, route to `rune:debug` Step 0 (build a feedback loop) instead of guessing.
+
+### Step T5 — Grill (if vague)
+
+If the issue lacks specifics for both bug and enhancement paths, run a grilling pass via `rune:ba` synthesis-mode (Step 1.4):
+- Synthesis-mode reads the issue body + comments as the "rich context"
+- Asks targeted follow-ups ONLY on dimensions with genuine gaps
+- Produces a Requirements Document the agent-brief can cite
+
+### Step T6 — Apply outcome
+
+Match state to action:
+
+| State | Action |
+|-------|--------|
+| `ready-for-agent` | Post AGENT-BRIEF comment on issue (use `rune:context-pack` agent-brief variant — see `context-pack/references/agent-brief.md`). Apply `ready-for-agent` label. |
+| `ready-for-human` | Post AGENT-BRIEF + explicit "why this can't be delegated" reason (judgment call, external access, design decision, manual testing). Apply `ready-for-human` label. |
+| `needs-info` | Post triage notes (template below). Apply `needs-info` label. |
+| `wontfix` (bug) | Post a polite explanation comment, then close. **No `.out-of-scope/` write** — bug rejections (already fixed, not reproducible, not a bug) get a comment, not a KB file. |
+| `wontfix` (enhancement) | Trigger Phase 4.5 (existing) — write `.out-of-scope/<slug>.md`, link from a comment, then close. |
+| `needs-triage` | Apply the role. Optional comment if there's partial progress. |
+
+Every comment posted by triage MUST start with the disclaimer:
+
+```
+> *This was generated by AI during triage.*
+```
+
+### Step T7 — Quick state override
+
+If the maintainer says "move #42 to ready-for-agent", trust them and apply the state directly. Confirm what you're about to do (label changes, comment, close), then act. Skip grilling. If moving to `ready-for-agent` without a grilling session, ask whether they want to write an agent-brief.
+
+## Templates
+
+### Needs-info comment
+
+```markdown
+> *This was generated by AI during triage.*
+
+## Triage Notes
+
+**What we've established so far:**
+- [point 1]
+- [point 2]
+
+**What we still need from you (@reporter):**
+- [specific, actionable question 1]
+- [specific, actionable question 2]
+```
+
+Capture everything resolved during grilling under "established so far" so the work isn't lost. Questions must be specific and actionable, not "please provide more info".
+
+### Ready-for-agent comment
+
+```markdown
+> *This was generated by AI during triage.*
+
+(AGENT-BRIEF block — see `context-pack/references/agent-brief.md`)
+```
+
+### Wontfix-bug comment
+
+```markdown
+> *This was generated by AI during triage.*
+
+Closing as wontfix:
+- [Reason: already fixed in #X / not reproducible / not a bug — explain briefly]
+- [If "not reproducible": link the failed repro evidence]
+- [If user disagrees: reopen and provide new details]
+```
+
+### Wontfix-enhancement comment (links to .out-of-scope/)
+
+```markdown
+> *This was generated by AI during triage.*
+
+Closing as wontfix. Recorded in `.out-of-scope/<slug>.md` for future reference.
+
+[1-line summary of the durable reason — full reasoning lives in the file]
+```
+
+## Resuming a previous triage session
+
+If prior triage notes exist on the issue, read them, check whether the reporter has answered any outstanding questions, and present an updated picture before continuing. Don't re-ask resolved questions.
+
+## State machine output (per issue triaged)
+
+```yaml
+issue: <id>
+category: bug | enhancement
+state: needs-triage | needs-info | ready-for-agent | ready-for-human | wontfix
+repro: confirmed | failed | insufficient-info | n/a   # bugs only
+agent_brief_posted: true | false
+out_of_scope_written: <slug>.md | null
+```
+
+This payload travels alongside the existing Verdicts table when emit `triage.classified` fires.
+
+## Anti-patterns
+
+| Anti-pattern | Why it fails |
+|--------------|--------------|
+| Marking `ready-for-agent` without confirmed repro (bugs) | Agent guesses, fixes wrong thing, bug returns |
+| Auto-applying `wontfix` without maintainer confirmation | Triage recommends; only maintainer decides |
+| Re-asking questions already answered in prior triage notes | Wastes reporter trust; read existing notes first |
+| Writing `.out-of-scope/` for bug rejections | Per format spec, only enhancement rejections produce KB files |
+| Posting triage comments without the AI-generated disclaimer | Reporter assumes human voice; trust degrades when caught |
+| Quick state override without confirmation summary | "Move to ready-for-agent" can mean "label only" or "label + brief" — confirm before acting |
+
+## Integration with Phase 4.5 (existing)
+
+Phase 4.5 (Rejection KB Write) already exists in `review-intake/SKILL.md` for OUT OF SCOPE verdicts in PR Mode. In Issue Triage Mode, `wontfix-enhancement` outcome triggers the **same** Phase 4.5 — no duplicate logic. The slug, lexical-similarity check, and write procedure are identical.
+
+## Required external tools
+
+- `gh` CLI (GitHub Issues) OR Linear MCP — without an issue-tracker integration, Issue Triage Mode falls back to local-only mode: maintainer pastes the issue body, triage produces classification + draft comments, maintainer copies the comments back to the tracker manually.

package/skills/surgeon/SKILL.md

@@ -93,6 +93,8 @@ Use `Edit` for all code changes. Rules:
 - Never change more than 5 files total in this session
 - If a change reveals a hidden bug, stop and call `rune:debug` before continuing
 
+**Multi-layer refactors**: when the deepening or extraction touches 2+ layers within the module (e.g., types + logic + interface), decompose into **vertical-slice tracer-bullet edits** rather than horizontal layer passes. Each slice = one end-to-end edit chain that produces a verifiable outcome (one Edit per layer, immediately tested). See `plan/references/vertical-slice.md` for slice rules and granularity. Horizontal "all-types-then-all-logic-then-all-interface" passes are forbidden inside surgeon — they break the "test after each Edit" discipline (Step 4) by leaving intermediate states untestable.
+
 For **Strangler Fig**: Create the new module file first, then update one consumer at a time.
 
 For **Branch by Abstraction**: Create the interface first (commit), wrap legacy (commit), build new impl (commit), switch (commit). Four commits minimum.

package/skills/team/SKILL.md

@@ -286,6 +286,8 @@ Mark todo[1] `completed`.
 
 Mark todo[2] `in_progress`.
 
+**3a-pre0. Output density honoring.** During Phase 2 dispatch, any worker that hits context ORANGE / RED has emitted `output.density.set` with `mode=caveman, scope=workstream` (auto from `rune:context-engine`). Coordination output respects per-workstream density: when summarizing a caveman-active worker's report into the merge plan, preserve its terse format rather than re-expanding to verbose. If 3+ workers are caveman-active simultaneously, the team-level summary itself should adopt caveman until merge completes (announce to user once: "Team output in caveman mode — N workers under context pressure"). Reverts to normal after Phase 5.
+
 **3a-pre. Oracle reattach sweep.** Before merge coordination, glob `.rune/oracle-pending/*.json`. For any worker stream that emitted `oracle.dispatched` during Phase 2, invoke `session-bridge --reattach <sessionId>`. Worker streams with `status=pending` past their `timeoutAt` are unblocked via `oracle.failed` so coordination can proceed. Workers with `status=complete` consume the response before merge.
 
 **3a. Check for file conflicts.**