@openrig/cli 0.5.10 → 0.5.12

package/daemon/docs/reference/health-diagnosis.md

@@ -19,6 +19,32 @@ rig health diagnosis list
 rig health diagnosis show <qitem-id>
 ```
 
+`diagnosis list` and `diagnosis show` default to summaries in both text and
+JSON. The detailed text summary shows queue state, owner, blocker, disposition,
+uncertainty, finding identity and authority references. Summary JSON also keeps
+the ceremony basis and current receipt identities. It keeps its object/array
+shape and adds `readView`: `complete`, `omittedFields` (paths,
+JSON byte counts and array counts), `fullJsonBytes`, and the exact `fullCommand`.
+Packet copies, authority contents, evidence arrays and the diagnostic receipt ledger
+are omitted explicitly. Current workflow-receipt envelopes remain, with
+`evidenceIdentity` carrying recognized cut/candidate, verdict and evidence-reference
+strings; their opaque evidence is omitted. These identity labels do not validate
+a receipt. A summary is not the complete evidence. Byte counts describe
+compact JSON serialization without the trailing newline, not model token counts.
+
+For investigation or existing consumers that need the former complete JSON:
+
+```sh
+rig health diagnosis show <qitem-id> --full --json > diagnosis.json
+rig health diagnosis list --full --json > diagnoses.json
+```
+
+`--full` without `--json` prints the complete record as formatted JSON. These
+expansions may be large. Plain `--json` no longer includes all evidence fields;
+migrate consumers of those fields to `--full --json`. HTTP API responses and
+mutation-result JSON are unchanged. Full context remains necessary before an
+agent acts on a diagnosis; the generated investigation packet names that command.
+
 The daemon checks enabled policy once per minute. `health policy` reports whether
 that check is scheduled and its last result, including errors. Ordinary `health`
 list/explain commands remain observational. Diagnosis defaults to disabled;

package/daemon/docs/reference/legacy-topology-migration.md

@@ -2,8 +2,7 @@
 
 For rigs whose hand-authored context predates the chain-file convention and
 lives at the legacy location (`~/.openrig/shared-docs/rigs/<rig>/`, or
-`$OPENRIG_SHARED_DOCS_ROOT/rigs/<rig>/`). The parent-host reconciliation
-campaign is the first consumer of this path. Nothing here is destructive: the
+`$OPENRIG_SHARED_DOCS_ROOT/rigs/<rig>/`). Nothing here is destructive: the
 legacy tree is left in place, reads keep working throughout (the walker's
 advisory-emitting fallback), and every copy is no-clobber.
 

package/daemon/docs/reference/mission-install.md

@@ -3,18 +3,12 @@ doc: reference
 title: The mission install — the project half of agent onboarding
 stage: established
 warrant: >-
-  Minted 2026-08-28 from three lived installs run before this convention was written
-  (receipts preserved in the minting slice's proof directory): a full five-layer seat
-  rebuild with a verified correction round, a release-boundary re-prime of a whole team
-  at two depths, and a successor install composed entirely from a mission's own
-  artifacts. Confirmed by a three-leg research round: the anatomy maps 1:1 onto the
-  shipped three-source composition contract, push-composition is convergent practice in
-  independent agent systems, and the only measured causal evidence available supports
-  composing authored artifacts over generating summaries.
+  Compose project context from authored, addressable artifacts so a joining agent
+  can recover purpose, source precedence, current responsibility and facts to derive.
+  Paced delivery and a checked delta make consumption and unresolved facts visible.
 sources:
-  - the minting slice's SPEC design-contract block (recorded direction, decisions, prototypes)
-  - the minting slice's research synthesis (machinery table, tensions, evidence weights)
-  - docs/reference/sdlc-conventions.md (the build conventions this composes with)
+  - docs/reference/sdlc-conventions.md
+  - docs/reference/product-journey-sdlc.md
 ---
 
 # The mission install
@@ -196,6 +190,11 @@ The layers compose from surfaces that already exist; no new mechanism is require
   project/mission/role/task → coverage map; `guided` keeps the fuller authored
   walk separately selectable. Both select from the same source graph.
 - Position: the `--rig`/`--seat` grant serves the seat's lessons and recap.
+- Runtime: `context profile` and `context work-install` both accept
+  `--runtime claude-code` (alias `claude`) or `--runtime codex`. Profile
+  composition retains the `claude` manifest/output key; skill projection
+  retains `claude-code`. Profile defaults from `OPENRIG_RUNTIME`, otherwise
+  Claude; work-install requires the flag to inspect or apply skills.
 - Delivery: `rig walk <seat> --through-profile world-public --profile <profile>
   --situation <situation> ...` applies the already-inspected profile;
   `--through <files> --pace <interval>` remains the raw byte-walk path. Paced

package/daemon/docs/reference/planning-dial.md

@@ -1,10 +1,9 @@
 # The planning dial — how much rigor a plan gets, chosen per piece
 
-Planning is a spectrum, not a binary. The build phase prices its care by wave
-composition; planning needs the same flexibility, or every piece gets one protocol —
-over-working the trivial and under-working the hard. Graduated 2026-08-28 from the
-working SOP that ran a full release; the lived examples behind each rung stay in the
-originating team's playbook.
+Planning is a spectrum, not a binary. When the wave model is selected, build care
+varies by wave composition; planning needs the same flexibility, or every piece gets
+one protocol — over-working the trivial and under-working the hard. Choose the rung
+from the work's uncertainty and consequences.
 
 ## The rungs — dial up by what the piece is
 
@@ -42,14 +41,13 @@ substrate where a plausible, self-consistent plan would ship the exact disease i
 exists to kill. The discriminator is "would a wrong plan be expensive, hard to undo,
 and invisible from inside" — never "is this piece central." Importance without an
 unclosable unknown or an author-blind failure mode stays at P1. Planning is text-only
-work, so the dial's cost stays proportional: a targeted P2 can take minutes; a full
-P3 an hour or two — cheap against a wrong plan built.
+work; keep its scope proportional to the unresolved question and the cost of a wrong
+plan, rather than assuming a fixed duration for a rung.
 
-## Cost calibration (dated observations from the graduating team, 2026-08)
+## Cost calibration
 
-A P2+P3 pass on the most load-bearing piece of a release took about two hours end to
-end and produced the most-attacked spec in the release before a line of its code
-existed. A P3 alone ran ~70 minutes and returned six findings, two behavior-changing.
-A targeted P2 resolved a feasibility door in ~5 minutes against primary sources and
-caught two defects in an already-in-flight candidate. The recurring lesson the rungs
-carry: run the research BEFORE the build dispatches, not during.
+Scope research to the unknown that could change the plan; scope an adversarial
+pass to the failure modes the author may miss. Record the questions resolved and
+the resulting design changes so the owner can judge the value of the selected
+rung. Run planned research before build dispatch, while its answers can still
+shape the spec.

package/daemon/docs/reference/project-release-profile.yaml

@@ -0,0 +1,86 @@
+schema: openrig.project/v0alpha1
+kind: project
+metadata: { id: example }
+missions: { root: missions }
+lifecycle:
+  profile: release-boundary-v0
+  profiles:
+    release-boundary-v0:
+      required_steps:
+        - mission-outcome
+        - exact-release-candidate
+        - capability-delta
+        - exact-cut-substance
+        - release-verification
+        - git-canonicalization
+        - public-release
+        - parent-adoption
+        - record-shipped
+        - release-boundary
+      workflow:
+        entry: { role: orchestrator }
+        # Entry/ordinary custody and exception selection are separate decisions.
+        # Replace the example target with a declared member (rig ps --nodes --json).
+        # Inspect with workflow compile/show; adopt later corrections with workflow revise.
+        exception_routing: { orchestrator_role: orchestrator }
+        roles:
+          orchestrator: { preferred_targets: [orch@example] }
+        steps:
+          - id: mission-outcome
+            actor_role: orchestrator
+            depends_on: []
+            objective: Judge the mission's promised outcomes against retained evidence; name remaining gaps.
+            allowed_exits: [handoff, waiting, failed]
+          - id: exact-release-candidate
+            actor_role: orchestrator
+            depends_on: [mission-outcome]
+            objective: Establish the exact candidate and tree to which subsequent receipts apply.
+            allowed_exits: [handoff, waiting, failed]
+          - id: capability-delta
+            actor_role: orchestrator
+            depends_on: [exact-release-candidate]
+            objective: Reconcile the shipped capability description with this candidate's actual behavior.
+            allowed_exits: [handoff, waiting, failed]
+          - id: exact-cut-substance
+            actor_role: orchestrator
+            depends_on: [capability-delta]
+            objective: Obtain and judge independent substance admission for the exact release cut.
+            allowed_exits: [handoff, waiting, failed]
+          - id: release-verification
+            actor_role: orchestrator
+            depends_on: [exact-cut-substance]
+            objective: Judge privacy, package shape, conventions and mirrors, builds, tests, and clean-tree evidence for the exact admitted release candidate.
+            allowed_exits: [handoff, waiting, failed]
+          - id: git-canonicalization
+            actor_role: orchestrator
+            depends_on: [release-verification]
+            objective: Obtain the authorized canonical Git identity and reconcile it with the verified candidate.
+            allowed_exits: [handoff, waiting, failed]
+          - id: public-release
+            actor_role: orchestrator
+            depends_on: [git-canonicalization]
+            objective: Obtain publication authorization and the release owner's exact public artifact receipt.
+            allowed_exits: [handoff, waiting, failed]
+          - id: parent-adoption
+            actor_role: orchestrator
+            depends_on: [public-release]
+            objective: Obtain separately authorized parent adoption and judge its effect receipt.
+            allowed_exits: [handoff, waiting, failed]
+          - id: record-shipped
+            actor_role: orchestrator
+            depends_on: [parent-adoption]
+            objective: Record durable shipped truth after judging ceremony receipts; the post-release boundary follows.
+            allowed_exits: [handoff, waiting, failed]
+          - id: release-boundary
+            actor_role: orchestrator
+            depends_on: [record-shipped]
+            objective: >-
+              After the release ceremony, author one attributed disposition record
+              covering seat renewal and re-prime, memory distillation, destination
+              queue sweep, substrate teardown or retention, board freeze and clean-box
+              baseline, capability-delta absorption and expiry, and packaged-product
+              discoverability. These are agent-judged guides, not seven daemon gates.
+              Inspect beyond this packet when useful. Record reasoned not-applicable
+              or deferred dispositions and wait on live dependencies. Finish after
+              this boundary when no successor is authored.
+            allowed_exits: [done, waiting, failed]

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

@@ -61,10 +61,7 @@ unset, the existing FILE and generic paths are unchanged.
 Mission-, project-, or box-specific refocus text belongs in a context-library
 entry or one of those FILES on the instance that needs it. **It must never be committed into product
 source** — the shipped default carries no path, seat name, mission, or
-practice that is not generally applicable. (The pre-promotion lab hook had
-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.)
+practice that is not generally applicable.
 
 Every delivered refocus pairs its content with the public `refocusing` skill's
 path-only trace. Configure `OPENRIG_REFOCUS_TREES=topology|work|both` and

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

@@ -2,29 +2,27 @@
 
 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.
+fence, after the prior release's ceremony completes. The project and seat owners
+select the applicable actions and preserve their reasons in the boundary record.
 
 ## 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.
+- **Choose continuity per seat, with its owner.** Fresh launch, managed compaction
+  with re-prime, or retaining the current session serve different needs. Role names
+  alone do not select one. Record the choice, the reason and custody of open work;
+  selecting a procedure does not itself authorize a lifecycle action.
+- **Fresh launch** can clear accumulated context and load current startup guidance.
+  Before an authorized exit, preserve the seat's earned knowledge and continuation
+  (recap where provisioned); verify the new occupant's actual identity and install.
+- **Managed compaction with re-prime** can retain planning continuity while
+  restoring the context needed for the next phase. **Retaining the current session**
+  can preserve ongoing custody. In either case, inspect which guidance is stale and
+  deliver the selected current context; an edit on disk is not delivery to a session.
 - **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.
+  paced pointer-walk) restores what-you-are-doing. Composing from named artifacts
+  keeps source precedence visible.
 - **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
@@ -45,13 +43,18 @@ playbook.
 - 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.
+  never dragged) · closed-superseded. The sweep exposes obligations that a missed
+  wake or a stale remembered work list can hide.
 - Verify every closing-paper inheritance has a live intake row with an owner. Zero
   orphans.
 
 ## 4. Substrate — teardown as its own atom
 
+- Retain the current release and the immediately previous release. At a boundary
+  for release N, worktrees and other release-scoped substrate from N-2 and older
+  are eligible for cleanup. Eligibility is not permission to discard unique dirty
+  bytes: archive or otherwise disposition those first. Identify live `main` and
+  runtime state by their actual refs and identity, never by a stale directory name.
 - Prune worktrees; remove session-scoped scratch trees; verify merged branches
   deleted (merge receipts authorize).
 - Scratch homes and scenario roots in temp directories: swept.
@@ -74,17 +77,22 @@ playbook.
 ## 6. The capability-delta lifecycle (standing law)
 
 Each release's capability delta is authored at the fence and bound to the exact
-published cut. Its baseline is the canon's actual last-absorbed marker, not an
-assumption that the immediately prior semver was absorbed. When canon is behind, the
-new delta is a cumulative synthesis of every intervening delta, preserving
-supersessions and pivots rather than concatenating old prose.
-
-Canon absorbs the kept public-product truths; the canon header then names the delta,
-which EXPIRES it — verify the expiry fired, and never cite an expired delta. Private
-project topology, host practice, and release ownership go to the versioned project
-world instead of leaking into the public package. 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.
+candidate, then reconciled to the published cut. Its baseline is the canon's actual
+last-absorbed marker, not an assumption that the immediately prior semver was
+absorbed. When canon is behind, the new delta is a cumulative synthesis of every
+intervening delta, preserving supersessions and pivots rather than concatenating
+old prose.
+
+Canon absorbs the kept public-product truths. Expiry requires BOTH the canon header
+naming that exact delta AND a distinct successor delta file existing. A header alone
+does not expire it; missing or unreadable inputs remain unknown/live. At the actual
+boundary, verify the event before recording expiry, then stop citing the expired
+delta. Do not create a successor merely to make the condition true. Candidate
+absorption is not proof of publication or served production adoption.
+
+Private project topology, host practice, and release ownership go to the versioned
+project world instead of leaking into the public package. The new release's delta
+obligations start at ITS cut.
 
 ## 7. World absorption and discoverability
 

package/daemon/docs/reference/rig-spec.md

@@ -174,7 +174,7 @@ edges:
 | `name` | string | yes | — | Rig name. Used in session naming (`{pod}-{member}@{name}`), snapshot identification, and spec library lookup. |
 | `summary` | string | no | — | Human-readable description. Shown in spec library, review surfaces, and `rig specs show`. |
 | `culture_file` | string | no | — | Relative path to a rig-wide culture/constitution file. Must be a safe relative path (no `..`, no absolute). |
-| `permission_policy` | string | no | — | Permission policy attached to the rig. Either a built-in (`builtin:locked`, `builtin:standard`, `builtin:open`, `builtin:operator`) or a safe relative path to a custom policy file (resolved from this spec's directory; no `..`, no absolute). Absent leaves the default floor. A member may set its own `permission_policy`, which takes precedence over the rig-level one. See "Attaching a permission policy" below. |
+| `permission_policy` | string | no | — | Permission policy attached to the rig. Either a built-in (`builtin:locked`, `builtin:standard`, `builtin:open`, `builtin:yolo`) or a safe relative path to a custom policy file (resolved from this spec's directory; no `..`, no absolute). Absent leaves the default floor. A member may set its own `permission_policy`, which takes precedence over the rig-level one. See "Attaching a permission policy" below. |
 | `docs` | Doc[] | no | — | Documentation files that should travel with the rig. Included in rig bundles. Each entry has a `path` field (safe relative path). The engine does not consume these — they are for humans and agents setting up the environment before launch. |
 | `startup` | StartupBlock | no | — | Rig-level startup files and actions. Applied to all members via the startup layering model. |
 | `services` | ServicesBlock | no | — | Optional managed services (Docker Compose). When present, services boot before any agent launches. |
@@ -193,7 +193,7 @@ permission_policy: builtin:standard
 permission_policy: policies/my-cautious-dev.policy.md
 ```
 
-Built-in policies (`locked` / `standard` / `open` / `operator`) are read-only and are
+Built-in policies (`locked` / `standard` / `open` / `yolo`) are read-only and are
 referenced as `builtin:<name>`. A custom policy lives in your own project and is
 referenced by a safe relative path (no `..`, no absolute). A shipped example of the
 custom shape is `packages/daemon/policies/examples/my-cautious-dev.policy.md` — copy it
@@ -343,12 +343,51 @@ Startup blocks can appear at three levels: rig, pod, and member. They are merged
 
 | Field | Type | Required | Default | Description |
 |-------|------|----------|---------|-------------|
-| `type` | string | yes | — | Action type. One of: `slash_command`, `send_text`. Note: `shell` is explicitly NOT supported in v1. |
-| `value` | string | yes | — | The command or text to send. |
-| `phase` | string | no | `after_files` | When to execute. One of: `after_files` (after startup files are delivered), `after_ready` (after harness readiness check passes). |
+| `type` | string | yes | — | Action type. One of: `slash_command`, `send_text`, `startup_proof`. Note: `shell` is explicitly NOT supported in v1. |
+| `value` | string | yes | — | Command/text to send, or `authenticated` / `none` for `startup_proof`. |
+| `phase` | string | no | `after_files` | When to execute text/commands. One of: `after_files` (after startup files are delivered), `after_ready` (after harness readiness check passes). Proof selection is resolved before projection regardless of phase. |
 | `idempotent` | boolean | yes | — | Whether this action is safe to replay on restore. **Required field.** Non-idempotent actions must NOT include `restore` in `applies_on`. |
 | `applies_on` | string[] | no | `[fresh_start, restore]` | When this action runs. Subset of: `fresh_start`, `restore`. |
 
+### Startup proof selection
+
+Startup adds no orientation exercise by default. To select the authenticated
+startup challenge, declare an action in an agent, profile, rig, pod, member, or
+operator startup block:
+
+```yaml
+startup:
+  actions:
+    - type: startup_proof
+      value: authenticated
+      idempotent: true
+```
+
+Use `value: none` in a later layer to select lean startup explicitly. The last
+applicable declaration wins in agent → profile → rig → pod → member → operator
+order. Culture contributes files, not a proof selection. With no applicable
+declaration, the result is `none`; the number of startup files never selects
+proof. Invalid values and non-idempotent proof declarations fail validation,
+including declarations overridden later. These actions declare policy and are
+never typed into a terminal.
+
+An authenticated selection challenges only a fresh or fresh-fallback managed
+agent launch. Resumed, forked, rebuilt, and adopted sessions receive no new
+challenge; terminal nodes never receive one. `applies_on` follows the requested
+startup context, so a fresh fallback during restore uses `restore` selections.
+Keep the default `[fresh_start, restore]` to cover both fresh launch paths.
+
+Identity delivery, projection, readiness, and ordinary startup actions still
+run. `startup_status: ready` means startup completed, while `oriented: missing`
+means a selected proof awaits authenticated submission. Omission/`none` yields
+`oriented: n-a` on a new fresh launch and retires an older challenge without
+deleting its audit history. Retirement follows successful harness launch,
+before readiness checks, so attention, timeout, or a readiness exception cannot
+retain the preceding proof. A replacement that fails to launch does not retire
+the current proof; resume/adoption also preserves existing proof history.
+The effective selection is recorded on `node.startup_pending`; actions are
+persisted in startup context for restore and fresh relaunch.
+
 ---
 
 ## Services Block
@@ -477,7 +516,7 @@ These rules are enforced by the validator. A spec that violates any of these wil
 19. Each wait target must define exactly one of: `service`, `url`, `tcp`.
 20. `condition` is only valid on `service` targets and must be `healthy`.
 21. Startup file `delivery_hint` must be one of: `auto`, `guidance_merge`, `skill_install`, `send_text`.
-22. Startup action `type` must be one of: `slash_command`, `send_text`. (`shell` is explicitly rejected.)
+22. Startup action `type` must be one of: `slash_command`, `send_text`, `startup_proof`. (`shell` is explicitly rejected.) Proof selection requires `value: authenticated` or `none` and `idempotent: true`.
 23. Startup action `phase` must be one of: `after_files`, `after_ready`.
 24. Startup action `idempotent` is a required boolean.
 25. Non-idempotent actions must not include `restore` in `applies_on`.
@@ -491,8 +530,8 @@ These are the built-in specs shipped with OpenRig. Read them as worked examples.
 
 | Spec | Location | Pods | Members | Services |
 |------|----------|------|---------|----------|
-| `product-team` | `packages/daemon/specs/rigs/product-team.yaml` | orch, dev, rev | 7 (lead, peer, impl, qa, design, r1, r2) | no |
-| `implementation-pair` | `packages/daemon/specs/rigs/implementation-pair.yaml` | dev | 2 (impl, qa) | no |
-| `adversarial-review` | `packages/daemon/specs/rigs/adversarial-review.yaml` | orch, rev | 3 (lead, r1, r2) | no |
-| `research-team` | `packages/daemon/specs/rigs/research-team.yaml` | orch, research | 3 (lead, analyst, synthesizer) | no |
+| `product-team` | `packages/daemon/specs/rigs/preview/product-team/rig.yaml` | orch1, dev1, rev1 | 7 (lead, peer, impl, qa, design, r1, r2) | no |
+| `implementation-pair` | `packages/daemon/specs/rigs/launch/implementation-pair/rig.yaml` | dev | 2 (impl, qa) | no |
+| `adversarial-review` | `packages/daemon/specs/rigs/focused/adversarial-review/rig.yaml` | orch, review | 3 (lead, r1, r2) | no |
+| `research-team` | `packages/daemon/specs/rigs/focused/research-team/rig.yaml` | orch, research | 3 (lead, analyst, synthesizer) | no |
 | `secrets-manager` | `packages/daemon/specs/rigs/launch/secrets-manager/rig.yaml` | vault | 1 (specialist) | yes (Vault) |

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

@@ -7,10 +7,10 @@
 
 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 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.
+build into proof. The TUI projects authored work on disk and, where an owning
+proof policy is selected, derives readiness from recorded judgments. These
+authoring conventions are **advisory / fail-open for agents**: the audit
+records and advises; the selected proof policy separately governs who may judge.
 
 
 ## HOW TO READ THIS DOCUMENT — two parts, and only one of them is the default
@@ -38,7 +38,7 @@ one does not deprecate the others. Nothing below deletes or overrides an existin
 | **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) · **product-journey components** — a mission-selectable menu for greenfield work, drift recovery, public journey probes, one evidence-gated look at the layer below, minimal repair, independent QA/review, integration, and installed smoke; compose only what the work needs in mission/slice YAML, never as a new mode or mandatory pipeline. Full reference: `product-journey-sdlc.md` · **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. |
+| **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 and bound to the exact candidate, then reconciled to the published cut. Expiry requires both the canon header naming the absorbed delta and a distinct successor delta existing; a draft header alone is insufficient. Verify the actual boundary event and stop citing 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
@@ -112,6 +112,17 @@ 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.
 
+When the owning scope selects `proofPolicy.judges`, use `rig proof judge` to
+record an attributed accept, reject or withdraw decision on a contract item,
+and `rig proof show` to read derived readiness up through slice, mission and
+project. The nearest slice, mission or project policy selects authorized judges;
+`rig proof --help` describes setup, selectors and evidence requirements. A
+correction preserves history and unrelated judgments without editing ancestor
+status checklists. An artifact can identify non-code work without a fabricated
+commit. Evidence capture (`proof add`), policy acceptance, higher outcome
+judgment and publication are distinct. This optional component does not select
+Part B or add a mandatory review gate.
+
 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) —

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

@@ -1,9 +1,9 @@
 # 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.
+This is a selectable build and review model from `sdlc-conventions.md`'s component
+menu. The mission owner decides whether it fits the work. 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
 
@@ -87,7 +87,7 @@ 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)
+## Failure modes and mitigations
 
 - **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
@@ -100,14 +100,3 @@ reviewers exist: nothing ever self-reviews; without them the wave gate is theate
   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/docs/reference/worktree-builds.md

@@ -21,11 +21,11 @@ A worktree can therefore report green against code it does not contain.
 
 ## Rules
 
-1. **Run `npm install` in each worktree** (~4s, one time). It is not the slow path; it is the
-   only path that resolves workspace packages to the worktree's own source.
+1. **Run `npm install` in each worktree** so workspace packages resolve to the
+   worktree's own source.
 2. **Never symlink `node_modules` from the primary checkout.** It appears to work — builds pass,
    typechecks pass — which is exactly the danger.
-3. **`npx tsc` with no `node_modules` installs an unrelated 12-year-old `tsc` package** and prints
+3. **`npx tsc` with no `node_modules` installs an unrelated `tsc` package** and prints
    "This is not the tsc command you are looking for". That message means *no install*, not a
    TypeScript error.
 4. **Build `@openrig/daemon` before typechecking `@openrig/cli`** in a fresh worktree: cli imports

package/daemon/policies/examples/my-cautious-dev.policy.md

@@ -35,6 +35,6 @@ permission_policy: policies/my-cautious-dev.policy.md
 ```
 
 Copy it, rename it, and edit the lists to taste — it's yours to change. The built-in
-policies (locked / standard / open / operator) stay read-only and are referenced as
+policies (locked / standard / open / yolo) stay read-only and are referenced as
 `builtin:<name>`; a custom policy like this one lives in your project and is referenced
 by path.

package/daemon/specs/agents/conveyor/planner/guidance/role.md

@@ -1,6 +1,6 @@
 # Role: Conveyor Planner
 
-You are the planning station for the `conveyor` starter rig. Your job is to
+You are a reusable planning station for the selected rig. Your job is to
 convert an accepted work packet into a bounded plan that the build station can
 execute without guessing.
 
@@ -17,8 +17,10 @@ execute without guessing.
 - Read the packet, identify the concrete outcome, and name any missing input.
 - Produce a short plan with expected files, commands, and verification.
 - Keep the plan small enough for one build turn.
-- Hand off to `build-builder@conveyor` with the plan and any constraints the
-  builder must preserve.
+- Derive your seat from `rig whoami --json` and the next role/target from the
+  assigned packet and selected workflow. Return the plan and constraints through
+  the workflow's selected projection/exit when it owns routing; otherwise hand
+  off to the packet's resolved destination. Do not hard-code a starter address.
 - Mark blockers honestly if the packet cannot be planned from available input.
 
 ## Principles

package/daemon/specs/agents/conveyor/planner/startup/context.md

@@ -1,12 +1,21 @@
 # Startup Context
 
-Run `rig whoami --json` before making topology claims. Confirm that your
-session is `plan-planner@conveyor`.
+Run `rig whoami --json` before making topology claims. Derive your actual seat
+and rig from that result; this planner is reused by multiple rigs.
 
 Default workflow role: `planner`.
 
-Receive packets from `intake-lead@conveyor`. Send executable plans to
-`build-builder@conveyor`.
+Read the assigned packet and selected workflow to identify the sender, current
+step and next role/target. An active workflow owns the inner-loop routing:
+return the plan through its selected projection/exit, without a parallel queue
+handoff. Outside a workflow, use the packet's destination resolved against the
+actual rig. Missing routing context is an input to resolve, not a reason to
+guess an address.
+
+For example, the shipped `conveyor` uses `plan-planner@conveyor` and
+`build-builder@conveyor`; `factory-rsi` uses `plan-planner@factory-rsi`
+and routes the plan to its implementer through the workflow. These examples
+do not set the identity or destination of a reused planner.
 
 Keep planning outputs concise: objective, assumptions, steps, verification, and
 handoff notes.

package/daemon/specs/agents/design/product-designer/agent.yaml

@@ -30,9 +30,10 @@ startup:
   actions:
     - type: send_text
       value: >-
-        A task is coming. BEFORE you do anything else, load and invoke your process skills NOW
-        using your runtime's supported skill mechanism: frontend-design,
-        verification-before-completion. Load them first, then begin the work.
+        Resolve the assigned outcome and its selected procedure. Use frontend-design
+        when shaping an interface and verification-before-completion when validating
+        a result. Load relevant skills when their task arises; this startup action
+        adds no blanket preload or review gate.
       phase: after_ready
       applies_on: [fresh_start, restore]
       idempotent: true