@openrig/cli 0.5.4 → 0.5.6

package/daemon/docs/reference/refocus-channel.md

@@ -12,17 +12,22 @@ it is the mechanism that makes shipped chain files (see
 
 | event | Claude Code | Codex | why |
 |---|---|---|---|
-| SessionStart | ✓ | ✓ | fresh orientation |
-| UserPromptSubmit | ✓ | ✓ | growth check at each turn boundary |
-| Stop | ✓ | ✓ | catches the long single turn |
-| PostCompact | ✓ | — (no compact hook) | a compacted seat's picture is lossy |
-
-The firing signal is **transcript growth** — not turns (one turn can burn 200k
-tokens across fifty tool calls) and not wall-clock (the failure is sustained
-work, not elapsed time). Default threshold ~2.6MB of JSONL growth (≈300k
-tokens); tune with `OPENRIG_REFOCUS_BYTES`. SessionStart and PostCompact
-always fire. Otherwise the hook is a silent no-op, and it degrades to silence
-on unrelated hook errors. A configured REF resolution failure instead degrades
+| UserPromptSubmit | ✓ | ✓ | deliver due or on-demand context at a model-visible boundary |
+| Stop | ✓ | — | catch a long Claude turn crossing the growth threshold |
+| PostCompact | ✓ | ✓ | retain exact compaction due-state; deliver on the next prompt |
+
+Claude's additional firing signal is **transcript growth** — not turns (one turn
+can burn 200k tokens across fifty tool calls) and not wall-clock (the failure is
+sustained work, not elapsed time). Its default threshold is ~2.6MB of JSONL
+growth (≈300k tokens); tune with `OPENRIG_REFOCUS_BYTES`. Codex never uses that
+threshold: its exact `PostCompact` lifecycle hook is the trigger, avoiding a
+redundant double-fire around Codex's own compaction cadence. Set
+`OPENRIG_REFOCUS_NOW=1` for an on-demand refocus and
+`OPENRIG_REFOCUS_ENABLED=0` to disable the feature. Fresh `SessionStart` is
+always a no-op: the default onboarding pack owns fresh orientation. Both
+runtimes retain `PostCompact` due-state for the next prompt. Otherwise the hook
+is a silent no-op, and it degrades to silence on unrelated hook errors. A
+configured REF resolution failure instead degrades
 loudly in the delivered payload while still completing the hook — a refocus
 must never break a seat's turn.
 
@@ -42,9 +47,10 @@ Resolution order:
 2. `OPENRIG_REFOCUS_CONTENT_FILE` — an operator-authored file (per-seat or
    per-rig via spec env).
 3. `$OPENRIG_HOME/refocus/REFOCUS.md` — the instance's standing content.
-4. The generic default baked into the hook: three project-neutral orientation
-   questions plus the pointer to the seat's topology chain
-   (`rig context trace … --name CRAFT.md`) and the LEARNED-ownership warning.
+4. The generic default at
+   `skills/refocusing/references/refocus.md`: three project-neutral orientation
+   questions, the ladder itself, and a pointer to the separately shipped
+   onboarding assets.
 
 The hook names a resolved REF in the delivered payload. If REF resolution
 fails, the payload starts with `REFOCUS CONTENT REF FAILED`, the exact ref, and
@@ -60,6 +66,13 @@ exactly this defect: a hardcoded per-box distillation-tool path. The
 promotion removed it; the grep for project residue is part of the slice's
 proof contract.)
 
+Every delivered refocus pairs its content with the public `refocusing` skill's
+path-only trace. Configure `OPENRIG_REFOCUS_TREES=topology|work|both` and
+`OPENRIG_REFOCUS_DEPTH=light|full`; optional `OPENRIG_REFOCUS_TOPOLOGY_NODE`
+and `OPENRIG_REFOCUS_WORK_NODE` select starts that cannot be derived. The
+script resolves `topology.root` and `workspace.root` through live config and
+reports broken links as gaps rather than following pointers.
+
 This automatic hook path is additive to one-shot manual injection through
 `rig send --context`; neither mode substitutes for the other.
 

package/daemon/docs/reference/release-boundary.md

@@ -0,0 +1,88 @@
+# The release boundary — housekeeping run once per fence
+
+A CHECKLIST OF JUDGMENT GUIDES, not gates: every item says WHY, most items are one
+act, and anything situational expires at the next boundary. Runs once per release
+fence, after the prior release's ceremony completes. Graduated 2026-08-28 from the
+working SOP; the graduating team's seat-specific ceremony details stay in its
+playbook.
+
+## 1. Seats — reset or re-prime, per each seat's continuity needs
+
+- **Builder, QA, and reviewer seats: FRESH GENERATIONS.** Graceful exit with a
+  deposit (recap where provisioned), then relaunch. Why, twice proven: accumulated
+  release context becomes noise that reads as knowledge, and long-running seats
+  carry stale injected catalogs — only a fresh launch carries current skills and
+  canon.
+- **Planning seats: MANAGED COMPACTION + RE-PRIME,** not fresh — planning continuity
+  is the seat's point; the post-compaction restore is exactly the width-restore case
+  the context machinery exists for.
+- **The continuity-bearing orchestration seat: STAYS.** Its memory is the release's
+  memory and the ceremony's custody. Known cost, accepted: its injected catalog
+  stays stale until its own next generation — the capability delta covers the gap by
+  content.
+- **Re-prime = the world walk + the current capability delta + the mission install**
+  per the mission-install convention (`docs/reference/mission-install.md`): the world
+  half restores where-you-are; the project half (five layers, two depth profiles,
+  paced pointer-walk) restores what-you-are-doing. Composing the packet by
+  improvisation is the trap this convention closed.
+- **THE CEREMONY IS THE EXPERIMENT.** Every act above runs on the product's own
+  primitives, so the ceremony doubles as their live test. Observe passively: what did
+  each re-primed seat's first natural turns reach for, and what broke? Findings land
+  in one dated observations file beside the boundary record.
+
+## 2. Memory — distill, never accumulate
+
+- Per-seat learned files: a distillation pass. The cut test: "has this changed a
+  decision recently?" Keep those; move the rest to a dated archive section in the
+  same file. A learned file at volume stops constraining and starts justifying.
+- Any shared agent memory: same pass, same test; retire entries the release
+  falsified.
+- The finished release's mission notes: SEALED AS RECORD, carried as nothing. The
+  new mission starts thin. Rules do not migrate; requirements do, via the plan.
+
+## 3. Queue — sweep by destination, disposition everything
+
+- Every seat sweeps its DESTINATION for open rows (wakes are unreliable; the sweep
+  is the read). Each open row from the finished release gets exactly one of:
+  done-with-receipt · carried-to-the-new-mission (re-filed against the new plan,
+  never dragged) · closed-superseded. Ghost obligations accumulate silently without
+  this — the measured specimen was a dozen cold rows against one seat.
+- Verify every closing-paper inheritance has a live intake row with an owner. Zero
+  orphans.
+
+## 4. Substrate — teardown as its own atom
+
+- Prune worktrees; remove session-scoped scratch trees; verify merged branches
+  deleted (merge receipts authorize).
+- Scratch homes and scenario roots in temp directories: swept.
+- Runtime installs: keep LIVE + LAST-KNOWN-GOOD; archive the hotfix chain;
+  disposition launcher backups.
+- Mid-release vendored-file backups removed once the release containing the real
+  fix is live.
+- Snapshots of torn-down topology: indexed in one line each, or deleted.
+
+## 5. Instruments and boards
+
+- The finished release's tracking and planning boards: FROZEN as records, labeled
+  so. The new mission gets fresh boards — source-of-truth markdown first, board
+  derived.
+- Frozen review criteria: archived beside their evidence, marked "available,
+  unweakened, not gates."
+- Capture ONE clean-box baseline receipt at mission start (load, process counts,
+  health tail latency) — the next performance question deserves a before.
+
+## 6. The capability-delta lifecycle (standing law)
+
+Each release's capability delta is authored at the fence and bound to the exact
+published cut. Canon absorbs its named items; the canon header then names the delta,
+which EXPIRES it — verify the expiry fired, and never cite an expired delta. The new
+release's delta obligations start at ITS cut. A delta that outlives its absorption
+is a stale teaching site wearing a version number.
+
+## 7. What deliberately does NOT happen at the boundary
+
+- No process migration: situational rules expired at the fence. The standing corpus
+  is the four checking principles — verify by effect · evidence at source · honest
+  verdicts including against yourself · never fabricate.
+- No re-litigating the finished release's verdicts; the sealed paper is the record.
+- No additions to this checklist without a lived specimen attached.

package/daemon/docs/reference/sdlc-conventions.md

@@ -1,64 +1,53 @@
 # SDLC conventions — the markdown control plane
 
-> **Succession rule (source of truth):** this document was derived from the
-> corrective review-surface redesign spec
-> (`CORRECTIVE-REDESIGN-review-surface-2026-07-05`, DRAFT v0.2, §2–§6,
-> grounded against openrig main `c27f2aff`, 2026-07-05/06). **Once shipped,
-> THIS repo document is the living SSOT for the SDLC conventions going
-> forward**; the corrective spec is the historical design record. Scaffold
-> templates, the advisory scope audit, the `mission-slice-sop` skill, and the
-> shipped bootstrap overlay all point HERE — they must not restate this
-> document in full (restatement is how drift is born).
+> **Source of truth:** this repo document is the living SSOT for the SDLC
+> conventions. Scaffold templates, the advisory scope audit, the
+> `mission-slice-sop` skill, and the shipped bootstrap overlay all point HERE —
+> they must not restate this document in full (restatement is how drift is born).
 
 OpenRig is a software factory the human steers from a high altitude. The human
 records intent; agents turn intent into a plan, the plan into a build, the
-build into proof. The Living Notes UI is a **plain projection of well-formed
+build into proof. The TUI is a **plain projection of well-formed
 markdown on disk** — agents change the files, the UI re-projects. These
 conventions define "well-formed." Everything here is **advisory / fail-open
 for agents**: nothing below blocks a write; the audit records and advises.
 
 
-## WHERE YOU ARE DECIDES WHICH LOOP YOU RUN — the VM inner loop vs the host outer loop
-
-The parent host's SDLC was being applied wholesale to the VM. **They are different worlds with
-different responsibilities**, and conflating them is what turned this document into friction.
-
-| | **INNER LOOP — the VM** | **OUTER LOOP — the parent host** |
-|---|---|---|
-| **question it answers** | *does it actually work?* | *does what was delivered match what was intended?* |
-| **method** | ground → fix → upgrade in place → **run it and look** → iterate | intent-vs-delivered comparison, commit-message review, privacy/leak scrub, release management, publish |
-| **definition of done** | to the best of our knowledge the code is **completely functional and works**, and needs **no heavy refactoring** to be release-ready | the release is shippable and honest |
-| **ceremony** | **Part A only.** Part B is not the default here. | **Part B applies.** The release itself earns it. |
-
-**WHY the ceremony belongs there and not here — the rule that makes this self-enforcing:** the
-proof ceremony is a **protocol for transmitting confidence to someone who was not there.**
-Plan-lock, proof contracts, C1 drops and intent-vs-delivered all exist so a reader who did NOT
-watch the work happen can verify that it did. On the host that is exactly the situation, so the
-artifacts must carry the confidence. **On the VM the builder IS there** — they ran it and looked at
-it. Running the ceremony there re-encodes, at high cost, something already known, for an audience
-standing in the room.
-
-**WHERE A FIX GOES — go where the validation is POSSIBLE, not where the ceremony lives:**
-
-- **Needs a live daemon to verify → the VM.** That is the only place it CAN be verified. (Worked
-  example: proving the ACTIVITY telemetry was really fixed required cutting the runtime over and
-  reading real values; no amount of host-side review could establish it.)
-- **Verifiable by reading — docs, comment scrubs, message hygiene → the host.**
-
-**The VM's north star for a release:** hand the host code that, to the best of our knowledge, is
-completely functional and works. Not a proof pack. **Effect-verified functionality.**
-
-
 ## HOW TO READ THIS DOCUMENT — two parts, and only one of them is the default
 
 | | applies | contents |
 |---|---|---|
 | **PART A — THE SIMPLE SDLC** | **ALWAYS. This is the default.** | artifact conventions, proportionality, the advisory audit, the honesty rails |
-| **PART B — THE RIGOROUS OVERLAY** | **ONLY when the founder, or an orchestrator relaying the founder, ASSIGNS the heavy path to a NAMED piece of work** | the proof-contract format, the two locks, C1 proof drops, the locked role contracts |
+| **PART B — THE RIGOROUS OVERLAY** | **ONLY when the human operator, or an orchestrator relaying that decision, ASSIGNS the heavy path to a NAMED piece of work** | the proof-contract format, the two locks, C1 proof drops, the locked role contracts |
 
 **You may not select Part B for yourself.** If you believe something earns it, say so in ONE
 sentence and continue on Part A until told otherwise. Part A corresponds to the `mission-slice-sop`
-skill; Part B to `mission-slice-intent-proof-sop`.
+skill; Part B is defined below and applies only when assigned.
+
+
+## THE COMPONENT MENU — this document is a menu, not a pipeline
+
+The SDLC is assembled from **components chosen per mission**, not a single mandated flow.
+This document describes the components and carries recommendations; a mission (or the team
+running it) picks per phase. Multiple valid options can exist for the same phase — choosing
+one does not deprecate the others. Nothing below deletes or overrides an existing component.
+
+| phase | components available today |
+|---|---|
+| **PRODUCT / MISSION PREPARATION** | **The product-management pass** — the layer above planning, run by the advisor/PM seat before planners touch a mission. The build is a lossy compression pipeline (PM intent → planner spec → builder code); nothing leaks downward by proximity, so this pass grounds in the raw sources, synthesizes ONE scope of record, presents owner decisions decision-ready, mints slices at plan time, deposits the full design contract INLINE in each design-bearing spec (owner words verbatim, settled decisions, evidence, shape of done, anti-goals), routes the complete reading list and internet-research assignments from the spec itself, frames each slice's planning-dial rung with its reason, and rereads every spec as the narrow downstream reader. The measuring stick: SPEC.md alone, plus what it explicitly routes to, reproduces the intent in a reader with none of the author's context. Full reference: `product-management-pass.md`. |
+| **PLAN** | **The planning dial** — planning rigor is a spectrum chosen per piece: P0 mini-requirements and pointers (simple, reversible work) · P1 an authored spec with a proof contract (the default) · P2 plus a research round before the spec freezes, run BEFORE build dispatch · P3 plus an adversarial pass by a non-author, judged against product goals, landing amendments with proof-contract teeth · P4 plus a blind from-scratch design diffed against priors before proceeding. Dial up by what the piece is, exactly as build care is priced below. Full reference: `planning-dial.md`. |
+| **BUILD** | **Part A, the simple flow** (below — the default) · **the wave model** — slices build in parallel in disjoint file territories, an integrator merges serially, and independent review fires once per wave (two reviewers with different vantages, never the writers; fix rounds re-earn verdicts at one final revision; per-slice discipline stays failing-test-first and verify-by-effect). The wave IS the care dial: what shares a wave decides how much review each piece gets · **Part B, the rigorous overlay** (below — only when assigned). These combine: a wave can carry one Part-B piece. Full wave reference: `wave-sdlc.md`. |
+| **DISPATCH DATA** | **The execution-data conventions (S27)** — three tiny data disciplines that make execution state derivable instead of hand-tabulated, consumed by `rig view show execution`. **EC-1, edges in frontmatter:** every open slice carries its hard edges in `depends_on:` (an inline JSON array; an explicit `[]` is a statement, absence is INDETERMINATE); soft/serialization edges are one machine-readable Territory line, exactly `SOFT-AFTER: [ids] — reason`. **EC-2, wave-as-data:** wave composition + review model live on a durable queue row tagged `wave-map` + `format:wave-map-v1` whose body carries one fenced ```json block (`{format:"wave-map-v1", mission, waves:[{id, slices, serialized_order?, review_model?}]}`) — composition only, never status labels (status derives at read time); the planning dial recorded at lock surfaces as the frontmatter field `approved-spec-dial:` beside the approve stamp. **EC-3, dispatch names the worktree:** build batons carry the exact body line `worktree_path=<path>` from dispatch onward — it is Q1's join key; batons without it join by naming only and the view marks them `fragile_join`. Existing batons are never rewritten. |
+| **RELEASE** | The release ceremony conventions (publication identity, honest release notes) and the CAPABILITY-DELTA LIFECYCLE LAW: each release's delta is authored at the fence, bound to the exact published cut; canon absorbs its named items; the canon header then names the delta, which expires it — verify the expiry fired, and never cite an expired delta. Full statement: `release-boundary.md` §6. |
+| **BOUNDARY** | **The release boundary** — housekeeping run once per fence so the next release starts clean: seats reset or re-primed per their continuity needs, memory distilled (keep what changed a decision recently), every queue swept by destination and dispositioned, substrate torn down, boards frozen as records, a clean-box baseline captured. A checklist of judgment guides, not gates. Full reference: `release-boundary.md`. |
+
+> Full reference documents for each component (graduated 2026-08-28): the
+> product-management pass — `product-management-pass.md` · the
+> planning dial — `planning-dial.md` · the wave model — `wave-sdlc.md` · the release
+> boundary (including the capability-delta lifecycle law) — `release-boundary.md` ·
+> the mission install — `mission-install.md` (lands with its own slice). The
+> summaries above remain the one-glance description; this document remains the SSOT
+> pointer for the whole menu.
 
 # PART A — THE SIMPLE SDLC (applies always)
 
@@ -84,21 +73,30 @@ force unless assigned.**
 
 Each slice directory carries:
 
-- **`README.md`** (or the slice body) opening with the three convention
-  sections, in this order and with these exact headings:
+- **`SPEC.md`** — the one authored node file. Its frontmatter carries
+  `intent:` and may carry `depends_on:` as a list of sibling work-node IDs;
+  `depends_on` orders siblings and is never followed by the path-only context
+  trace. The body opens with the three convention sections, in this order and
+  with these exact headings:
   - **`## Intent`** — the recorded intent, verbatim. The UI projects this
     text as the INTENT section.
   - **`## Mini-requirements`** — the concise, one-glance requirement tier
-    (numbered list). This is the founder's first structured catchpoint;
+    (numbered list). This is the human operator's first structured catchpoint;
     approval starts here.
   - **`## Proof contract`** — a checkbox list of promised deliverables (see
     §3). The UI's DELIVERED section pairs each item with its proof.
-- **`IMPLEMENTATION-PRD.md`** — the full PRD. It OPENS with the
-  mini-requirements; everything between intent and proof is **elastic**
-  (see §7 — for a small slice the mini-requirements may BE the whole PRD).
+- **`PROGRESS.md`** — the slice's acceptance checklist: the durable
+  mission/slice-level to-do checked at acceptance. In-process steps stay in
+  the working agent's own todo tool.
+- **`PROOF.md`** — the retained proof summary, explicitly paired to the
+  `SPEC.md` proof contract.
 - **`proof/`** — the proof-artifact directory. Curated canonical evidence
   lands here via `rig proof` with valid C1 headers (§5).
 
+Legacy `README.md`, `IMPLEMENTATION-PRD.md`, and pre-convention trees remain
+readable indefinitely. New scaffolds do not create or mirror them, and repair
+is additive: it never deletes, renames, or rewrites legacy bytes.
+
 The three sections project into the UI's one review structure: a vertical
 stack of **INTENT → PLAN → DELIVERED**. A slice missing a section still
 renders (the projection degrades to a muted "—", never invents content) —
@@ -140,21 +138,9 @@ either being wrong (for example, one over the frontmatter block and one over
 the whole file). Coverage is what makes a cited hash verifiable rather than
 merely impressive.
 
-**Canonical convention (the ONE origin — cite it, do not restate it here),
-cited in the form that convention itself prescribes — path + section anchor +
-dated whole-file hash:**
-
-- **path:** `artifact-cross-citation-path-plus-lineage.md` (internal authoring convention — not shipped in this public repo)
-- **anchor:** *A cited hash STATES ITS COVERAGE — span is part of the definition*
-  (2026-08-08)
-- **hash:** `sha256 14d9a273d542648ab1e0a82c7fd98e8a8c59cb02a83be76b8af9abfb717b34d2`
-  — **coverage: WHOLE FILE, bytes as stored, INCLUDING the trailing newline**
-  (0x0a terminal byte verified), 229 lines, as-of 2026-08-08.
-
-The **path + anchor is the AUTHORITY**; the whole-file hash **DATES** the
-citation. That artifact is a living doc: the hash goes stale at the next
-legitimate append, the anchor does not — the CURRENT-line convention applied to
-a citation.
+**Use path + anchor as the authority and a whole-file hash only to date the
+citation.** The address survives legitimate content changes; the digest does not.
+
 ## A4. When implementation finds the intent rested on something that does not exist
 
 A slice's intent can only be honoured to the extent its assumptions hold. Sometimes implementation
@@ -188,7 +174,7 @@ Do not over-engineer this. The entire goal is an accurate story for whoever read
 The SDLC has exactly three fixed capture points: **intent** → a
 **proportional structured requirement** → **proof**. Everything between is
 elastic. For a small slice (a bug fix, a research note), the
-mini-requirements may BE the whole PRD — the convention sections must be
+mini-requirements may BE the whole specification — the convention sections must be
 present so the slice projects, but their contents scale to the work. Gates
 are losslessness checks on the decompression from intent to delivery, not
 paperwork. Scaffolding emits the sections; it must never mint ceremony.
@@ -203,19 +189,20 @@ reported as unknown, not failure.
 ## A7. Where the knowledge lives (the four pointers)
 
 - **This document** — the SSOT.
-- **Scaffold**: `rig scope slice create` emits the convention sections +
-  `proof/` + an `IMPLEMENTATION-PRD.md` skeleton for every template kind;
-  `rig scope mission create` emits the convention pointer.
-- **Skills — TWO, matching this document's two parts**: `mission-slice-sop`
-  teaches **Part A**, the light default; `mission-slice-intent-proof-sop`
-  teaches **Part B**, the assigned overlay. Assigned-only, never self-selected.
+- **Scaffold**: `rig scope slice create` emits `SPEC.md` + `PROGRESS.md` +
+  `PROOF.md` + `proof/` for every template kind; `rig scope mission create`
+  emits an intent-bearing `SPEC.md` + `NOTES.md`. Core emits only this
+  mode-neutral shape; mode plugins add richer material through the extension
+  seam rather than teaching core a mode.
+- **Skill**: `mission-slice-sop` teaches **Part A**, the light default. **Part B**
+  is defined below and applies only when assigned — never self-selected.
 - **Bootstrap**: the shipped agent overlay points fresh seats at the skill
   and this document at boot.
 
 # PART B — THE RIGOROUS OVERLAY (assigned only)
 
-> **ENTRY CONDITION:** everything below applies **only** when the founder — or an orchestrator
-> explicitly relaying the founder — has assigned the heavy path to a **named** piece of work.
+> **ENTRY CONDITION:** everything below applies **only** when the human operator — or an orchestrator
+> explicitly relaying that decision — has assigned the heavy path to a **named** piece of work.
 > If you arrived here without an assignment, stop and use Part A.
 >
 > **Rails:** the locks are **two, and only two**. Nothing here authorizes a second gate round on
@@ -264,9 +251,9 @@ Two deliberate stamps, both written by the SAME shipped verb
 (`rig scope slice approve`, one daemon-side write path: frontmatter stamp +
 append-only audit row land together):
 
-- **Plan-lock:** `rig scope slice approve <slice> --scope spec` — "the PRD
-  matches my intent; THIS artifact set is what gets built." Pins the locked
-  artifact set (spec/PRD/mockups) out of everything else in the folder.
+- **Plan-lock:** `rig scope slice approve <slice> --scope spec` — "the spec
+  matches my intent; THIS artifact set is what gets built." Pins `SPEC.md`
+  (and planned mockups, when present) out of everything else in the folder.
 - **Proof-lock:** `rig scope slice approve <slice> --scope delivery`
   (the default scope) — the terminal "this is done" sign-off; fires the
   freeze.
@@ -335,9 +322,6 @@ an append-only pile where the human can't tell final from superseded.
 
 ## Scratch-daemon hermeticity: the DB a scratch daemon opens is the one you named
 
-*(Desk-ruled 2026-08-25, row qitem-20260825005846-7960f4dd; 0.5.3-era doctrine — a harness rule,
-not product behavior.)*
-
 A scratch daemon launch **strips the inherited environment's `OPENRIG_DB` and names an explicit
 scratch DB path under the scratch `OPENRIG_HOME`** — both halves, every launch:
 
@@ -353,6 +337,6 @@ the scratch context read or wrote state it never owned, and whether anything vis
 luck, not hermeticity.
 
 **The discriminator that keeps this rule honest:** an explicit `OPENRIG_DB` still WINS by design
-(`daemon-db-path.ts`; prior ruling 00c4ab76) — deliberate split-path configuration is legitimate
-and untouched. This rule governs **inheritance into scratch contexts**, where nobody decided
-anything: strip what you did not choose, then choose.
+(`daemon-db-path.ts`) — deliberate split-path configuration remains legitimate and
+untouched. This rule governs **inheritance into scratch contexts**, where nobody
+decided anything: strip what you did not choose, then choose.

package/daemon/docs/reference/wave-sdlc.md

@@ -0,0 +1,113 @@
+# The wave SDLC — parallel build, wave-level review, composition as the care dial
+
+Graduated 2026-08-28 from the working playbook of the team that proved it live; the
+team-specific custody mechanics stay in that team's playbook. Lock stamps in this
+model are ADDITIVE: approval appends metadata and never rewrites authored bytes, so
+a candidate's identity survives its own approval.
+
+## The model in one paragraph
+
+Slices build IN PARALLEL across every build-class seat, each in a DISJOINT FILE
+TERRITORY, each merged serially by one integrator the moment its candidate freezes
+with builder-proven receipts. Independent review happens ONCE PER WAVE over the wave's
+whole accumulated range — two reviewers with different vantages (ideally different
+runtimes), never the writers — and their findings drive fix rounds that re-earn both
+verdicts at the round's final revision. Checks stay per-slice (failing-test-first
+proof, verify-by-effect, honest receipts); rounds happen per-wave.
+
+## The mechanics
+
+1. **PLAN:** wave entries in the plan of record; the planner shapes specs; the plan
+   authority locks them. Every slice gets a real workspace or proof has no home.
+2. **DISPATCH:** batons fan out with EXCLUSIVE file territories. THE BRIEF IS THE
+   UNIT: every assignment carries the goal, the acceptance criteria, the complete
+   context routes (exact paths), the territory — and this standing grant: "Navigate
+   the implementation yourself: derive what you need, research, spawn readers,
+   decide your own build order. Ask when stuck; the orchestrator is here to help."
+   DEFAULT SCOPE IS THE WHOLE SPEC, built in one sustained run to ONE frozen
+   candidate. Handing out anything smaller requires naming the reason on the brief
+   itself (an unresolved decision, a live territory conflict, a genuine
+   fork-in-the-road risk) — an unexplained small chunk is a dispatch defect.
+   Territory overlap = serialize. Conflict discovered mid-build = STOP AND RULE.
+   Why: the builder holds the spec and the code; decisions about how to build
+   belong where the building context lives. Detailed sequencing instructions were
+   scaffolding when models were weak; today they are a cage, and per-command
+   routing is the failure mode, not diligence.
+   THE BRIEF IS A MAP, NOT THE TERRITORY. Distillation is welcome — for a minimal
+   slice the brief may honestly be richer than the spec — but it is never the
+   receiver's ONLY context: the builder's first act is self-onboarding from the
+   routed reading list (the mission-install pattern at slice scale), then checking
+   the map against the ground it actually stands on. Nobody knows the ground floor
+   better than the builder; the wide angle lives a layer up. When the ground
+   disagrees with the map, that is a finding to raise — not a reason to follow
+   the map off a cliff.
+3. **BUILD:** failing-test-first against a pristine base with committed final test
+   bytes; freeze a single candidate revision; receipts cite the FINAL revision
+   (re-earned after any rebase).
+4. **MERGE:** integrator-only, serially, verified at source each time (candidate
+   parent equals pre-merge tip; changed files equal declared territory). Merge
+   announcements are REBASE TRIGGERS for every open candidate.
+5. **WAVE REVIEW:** fires when the wave's build completes. Two independent reviewers,
+   base-scoped at the tip, writers excluded from reviewing their own work. The two
+   gates ask DIFFERENT questions — does the structure hold, versus does each claim
+   survive contact with source. That is the design, not redundancy.
+   Reviewers also review for DRIFT, not only defects: does the built thing still
+   match the acceptance criteria the brief stated — is this still the doghouse the
+   owner asked for, or did locally-defensible steps accrete toward a moon base?
+   Plot-loss is a first-class finding with the same standing as a logic defect.
+   Reviews also DISPOSE each miss by cause: CONTEXT-GAP — the spec or its routes
+   lacked what the moment needed (a planning finding; the fix lands in the spec) —
+   versus JUDGMENT-GAP — the context was there and the call was wrong (a builder
+   finding; the fix is a check). One word in the verdict artifact. The rate this
+   produces is the calibration the dispatch shape tunes on.
+6. **FIX ROUNDS:** findings become forward-fix candidates (merges stand; merged is
+   not running). One re-review pass per round re-earns both legs at the final
+   revision. Narrow rechecks for narrow corrections.
+7. **SEAL:** both legs clear at one revision = wave sealed; the next slot opens.
+
+## THE WAVE IS THE CARE DIAL
+
+Wave COMPOSITION is the control surface for how carefully a piece is handled: a
+large, complicated, or load-bearing slice gets a wave OF ITS OWN (its review ceremony
+fires for it alone); a big piece can even split across waves. This decouples what an
+older model conflated: mission and slice workspaces stay flexible organizational
+containers; waves are the separate layer that sequences work, assigns it, and prices
+its handling care. Care is a per-piece property, never a per-mission one.
+
+## When to use it
+
+Many small-to-medium, root-caused, evidence-backed slices; enough seats to
+parallelize; territories that partition cleanly; an integrator who can merge serially
+and verify fast.
+
+## When NOT to use it
+
+Design-uncertain or shared-region work (one slice, classic two-leg review, or a
+design session first). Anything irreversible within the hour (publish, cutover,
+destructive operations) — that is the heavy path. And when no independent non-writing
+reviewers exist: nothing ever self-reviews; without them the wave gate is theater.
+
+## Failure modes, with the mitigations that worked (dated observations, 2026-08)
+
+- **Freeze-merge races:** a candidate freezes seconds before a merge moves the tip.
+  Mitigation: zero-overlap restack with content-identity proof (stable patch-id) in
+  an isolated worktree; builder-side self-catch on merge announcements.
+- **Evidence theater:** a failing test that fails for the wrong reason reads
+  identical to a real one. Mitigation: reviewers re-derive the failures
+  independently; false characterizations retire to a correction history, never a
+  silent rewrite.
+- **Presence-not-absence tests:** asserting the true line exists while the false
+  line still prints. Rule: pin the ABSENCE of the false claim in every encoding.
+- **Phantom checkout status:** merge-by-reference leaves a shared checkout's index
+  stale. Never build or commit from a shared checkout; sync its index at fences.
+
+## Measured outcome from the proving run (dated, one team, 2026-08)
+
+Eight slices plus five fix candidates plus two addenda built and merged in ~2.5 hours
+across five writing seats; two wave passes plus three fix-round passes replaced ~20
+per-slice review rounds. Defect yield went UP: the reviewers' findings never
+overlapped once across three consecutive verdicts, and the builders' green suites had
+missed every one of them — wave-level review sees cross-slice seams per-slice review
+structurally cannot. Correction latency: one live defect went found→root-caused→
+specced→locked→built→merged in 24 minutes, because no review round stood between a
+locked spec and a building seat.

package/daemon/policies/builtin/standard.policy.md

@@ -16,10 +16,10 @@ destructive_class: [delete_everything, drop_persistent_store, reset_or_discard_v
 The everyday software-factory posture for INTERACTIVE dev. Routine work runs without prompts; the consequential outward and history-rewriting acts defer to the human.
 
 - **default_posture: allow** — routine dev (toolchain, arbitrary shell, install deps, scoped file deletion, network, topology) runs without a prompt.
-- **allow: [push_to_remote]** — routine `git push` is allowed (pinned explicitly; the founder rejected gating push as a default).
-- **ask: [create_pr, publish_package, merge_or_release, force_push]** — outward/release/history-rewriting acts ASK the human. **ASK ≠ deny**: OpenRig bakes no block; ASK = defer to the human, the founder's explicit beyond-floor default. `force_push` is additionally best-effort on Claude (prefix rules can't reliably split `git push --force`), so ASK is the honest disposition, not a can't-enforce deny.
+- **allow: [push_to_remote]** — routine `git push` is allowed (pinned explicitly; the policy design rejects gating push as a default).
+- **ask: [create_pr, publish_package, merge_or_release, force_push]** — outward/release/history-rewriting acts ASK the human. **ASK ≠ deny**: OpenRig bakes no block; ASK = defer to the human, the policy's explicit beyond-floor default. `force_push` is additionally best-effort on Claude (prefix rules can't reliably split `git push --force`), so ASK is the honest disposition, not a can't-enforce deny.
 - **destructive_class → ask** — `delete_everything`, `drop_persistent_store`, `reset_or_discard_vcs` default to ASK, never a silent block (best-effort-safe).
 
 **INTERACTIVE-dev posture:** an `ask` freezes an autonomous seat by design — autonomous fleets use Open or YOLO, not Standard.
 
-**FLOOR (always on, flag surface):** Claude `acceptEdits` + Codex `workspace-write` (the edit/sandbox floor); Pi `--no-approve` is a resource-TRUST posture, not a permission floor (Pi has no permission surface). **Translation is the skill's job** (harness-neutral intent → per-harness format, caveated). Grounded in schema `a8dba0d9`; the ask-set is pinned per cold-transfer `627abbb6`.
+**FLOOR (always on, flag surface):** Claude `acceptEdits` + Codex `workspace-write` (the edit/sandbox floor); Pi `--no-approve` is a resource-TRUST posture, not a permission floor (Pi has no permission surface). **Translation is the skill's job** (harness-neutral intent → per-harness format, caveated).

package/daemon/policies/builtin/yolo.policy.md

@@ -11,10 +11,15 @@ description: Full-bypass posture — the flag-surface YOLO opt-in. Everything ru
 
 The maximum-permissive built-in. The seat runs the harness with its full-bypass launch flag: Claude `--dangerously-skip-permissions`, Codex full-bypass, Pi `--approve`. Nothing prompts; nothing is denied. Use only for fully-trusted autonomous work where any pause is unacceptable.
 
-**APPLICATION is deterministic, NOT skill-translated.** YOLO is a `surface: flag` policy: it resolves to a stable launch flag, so it is applied by the deterministic flag-surface opt-in — the rip-out slice's YOLO setting (OPR.0.4.8.2). The `applying-a-permission-policy` skill does **NOT** translate this policy; it simply points at that setting. This is the two-surface distinction: the flag surface is stable enough for deterministic code, so it does not pay the skill-indirection tax.
+**APPLICATION is deterministic, NOT skill-translated.** YOLO is a `surface: flag`
+policy: it resolves to a stable launch flag and is applied directly by the runtime
+flag-surface opt-in. The `applying-a-permission-policy` skill does **NOT** translate
+this policy; it points at that setting. The flag surface is stable enough for
+deterministic code, so it does not pay the skill-indirection tax.
 
 **Config policies are MOOT when YOLO is on.** The full-bypass launch flag overrides any Claude prefix rules / Codex posture, so an attached config-surface policy (Locked/Standard/Open) has no effect while YOLO is active. Pick YOLO OR a config policy, not both.
 
 **Guardrails come from skills + starter markdown, not permission-blocking** — a YOLO seat is bounded by what its skills and operating context tell it to do, since the permission layer imposes nothing.
 
-**Naming lineage:** the founder's FINAL DESIGN named the fourth built-in **Operator**. The two-surface refinement (2026-08-03) subsumed Operator into this flag-surface full-bypass built-in and renamed it **YOLO** to name the posture plainly; the picker presents all four named postures (Locked / Standard / Open / YOLO) uniformly. Grounded in schema `a8dba0d9`.
+**Naming:** YOLO names the full-bypass posture plainly; the picker presents all four
+named postures (Locked / Standard / Open / YOLO) uniformly.

package/daemon/specs/agents/shared/skills/core/cross-host-rig-commands/SKILL.md

@@ -30,11 +30,8 @@ operator pattern (`ssh <host> rig <cmd>`) with declared host identity,
 explicit cross-host invocation path, preserved `--verify` semantics, and
 4 named failure modes.
 
-**Current-host note (2026-07-14):** this skill still preserves the original
-SSH-v0 doctrine below, but the live host registry may also contain HTTP
-read-through/tunnel entries such as `your-vm` and `your-other-vm`. Use the
-host registry entry as ground truth for transport shape, and use
-`conventions/multi-host-naming/README.md` for host-id naming. HTTP entries
+The live host registry may contain SSH or HTTP read-through/tunnel entries.
+Use each registry entry as ground truth for transport shape. HTTP entries
 require `url` plus exactly one of `bearer_file` or `bearer_env`.
 
 **v0 is CLI-side shell-out only — `packages/daemon/` is NOT touched.**
@@ -73,24 +70,20 @@ differs from the interactive verbs (`send`/`capture`/`ps`/`whoami`):
 
 ## Host registry shape (`~/.openrig/hosts.yaml`)
 
-Host ids should follow the OpenRig-work multi-host naming convention:
-`conventions/multi-host-naming/README.md`. In this environment that means
-physical hosts such as `your-vm`, local OpenRig development VMs such as
-`your-vm`, persistent product VMs such as `your-other-vm`, and VPS hosts such
-as `your-vps`. Keep old aliases during migration until no live routing
-depends on them.
+Host ids must be non-empty and unique. Choose stable, operator-meaningful ids
+that describe the destination without depending on transient network details.
 
 ```yaml
 hosts:
   - id: a-test-vm
     transport: ssh                       # v0 supports "ssh" only
     target: a-test-vm.local         # DNS name, SSH config alias, or IP
-    user: wrandom                        # optional
+    user: example-user                   # optional
     notes: "Tart VM"                     # optional
   - id: laptop-b
     transport: ssh
     target: laptop-b.tail-scale-net
-    user: wrandom
+    user: example-user
 ```
 
 Validation rules: