@openrig/cli 0.5.5 → 0.5.7

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

@@ -1,14 +1,9 @@
 # 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
@@ -18,47 +13,48 @@ 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) · **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. |
+| **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 product-journey component catalog —
+> `product-journey-sdlc.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.
+
+Mission and slice YAML may select component IDs from
+`product-journey-sdlc.md` and record explicit edges between them. That YAML is
+an address map and execution dashboard prototype, not an enforcement engine.
+If it is absent, Part A remains the complete default; agents do not invent a
+composition merely to make one exist.
 
 # PART A — THE SIMPLE SDLC (applies always)
 
@@ -92,7 +88,7 @@ Each slice directory carries:
   - **`## 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.
@@ -149,21 +145,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
@@ -217,16 +201,15 @@ reported as unknown, not failure.
   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.
-- **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.
+- **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
@@ -346,9 +329,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:
 
@@ -364,6 +344,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/apps/vault-specialist/agent.yaml

@@ -11,7 +11,7 @@ imports:
 profiles:
   default:
     uses:
-      skills: [using-superpowers, systematic-debugging, verification-before-completion, vault-user]
+      skills: [systematic-debugging, verification-before-completion, vault-user]
       guidance: []
       subagents: []
       plugins: [shared:openrig-core]

package/daemon/specs/agents/apps/vault-specialist/guidance/role.md

@@ -26,7 +26,6 @@ You are the Vault specialist agent for this managed app. You are the domain expe
 
 You have the following skills loaded:
 
-- `using-superpowers` — general agent capabilities
 - `openrig-user` — OpenRig CLI and topology operations
 - `systematic-debugging` — structured debugging approach
 - `verification-before-completion` — evidence before claims

package/daemon/specs/agents/conveyor/builder/agent.yaml

@@ -11,7 +11,7 @@ imports:
 profiles:
   default:
     uses:
-      skills: [development-team, test-driven-development, systematic-debugging, executing-plans, verification-before-completion]
+      skills: [development-team, test-driven-development, systematic-debugging, verification-before-completion]
       guidance: []
       subagents: []
       plugins: [shared:openrig-core]

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

@@ -11,7 +11,6 @@ reviewer can inspect.
 - `development-team`
 - `test-driven-development`
 - `systematic-debugging`
-- `executing-plans`
 - `verification-before-completion`
 
 ## Responsibilities

package/daemon/specs/agents/conveyor/lead/agent.yaml

@@ -11,7 +11,7 @@ imports:
 profiles:
   default:
     uses:
-      skills: [orchestration-team, backlog-capture, writing-plans, executing-plans, verification-before-completion, brainstorming]
+      skills: [orchestration-team, backlog-capture, verification-before-completion]
       guidance: []
       subagents: []
       plugins: [shared:openrig-core]

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

@@ -11,10 +11,7 @@ ready.
 - `mission-slice-sop`
 - `orchestration-team`
 - `backlog-capture`
-- `writing-plans`
-- `executing-plans`
 - `verification-before-completion`
-- `brainstorming`
 
 ## Responsibilities
 

package/daemon/specs/agents/conveyor/planner/agent.yaml

@@ -11,7 +11,7 @@ imports:
 profiles:
   default:
     uses:
-      skills: [requirements-writer, context-builder, writing-plans, verification-before-completion]
+      skills: [requirements-writer, context-builder, verification-before-completion]
       guidance: []
       subagents: []
       plugins: [shared:openrig-core]

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

@@ -10,7 +10,6 @@ execute without guessing.
 - `mission-slice-sop`
 - `requirements-writer`
 - `context-builder`
-- `writing-plans`
 - `verification-before-completion`
 
 ## Responsibilities

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

@@ -11,7 +11,7 @@ imports:
 profiles:
   default:
     uses:
-      skills: [using-superpowers, development-team, frontend-design, verification-before-completion, writing-plans, brainstorming]
+      skills: [development-team, frontend-design, verification-before-completion]
       guidance: []
       subagents: []
       plugins: [shared:openrig-core]
@@ -31,9 +31,8 @@ startup:
     - 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: using-superpowers, frontend-design,
-        verification-before-completion, writing-plans, brainstorming. Load them first, then begin
-        the work.
+        using your runtime's supported skill mechanism: frontend-design,
+        verification-before-completion. Load them first, then begin the work.
       phase: after_ready
       applies_on: [fresh_start, restore]
       idempotent: true

package/daemon/specs/agents/design/product-designer/guidance/role.md

@@ -5,13 +5,10 @@ You are the design side of the product team. Your job is to turn rough product i
 ## Startup checklist
 
 Load these packaged skills now before giving product direction:
-- `using-superpowers`
 - `openrig-user`
 - `mission-slice-sop`
 - `development-team`
 - `frontend-design`
-- `brainstorming`
-- `writing-plans`
 - `verification-before-completion`
 
 Then run `rig whoami --json` and look for the first ambiguity the development pod should not have to guess through.

package/daemon/specs/agents/development/implementer/agent.yaml

@@ -11,7 +11,7 @@ imports:
 profiles:
   default:
     uses:
-      skills: [using-superpowers, development-team, test-driven-development, systematic-debugging, verification-before-completion, writing-plans, executing-plans]
+      skills: [development-team, test-driven-development, systematic-debugging, verification-before-completion]
       guidance: []
       subagents: []
       plugins: [shared:openrig-core]
@@ -31,9 +31,8 @@ startup:
     - 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: using-superpowers, test-driven-development,
-        systematic-debugging, verification-before-completion, writing-plans, executing-plans. Load
-        them first, then begin the work.
+        using your runtime's supported skill mechanism: test-driven-development,
+        systematic-debugging, verification-before-completion. Load them first, then begin the work.
       phase: after_ready
       applies_on: [fresh_start, restore]
       idempotent: true

package/daemon/specs/agents/development/implementer/guidance/role.md

@@ -5,14 +5,11 @@ You are the implementation side of a dev pair. Your job is to write code, not to
 ## Startup checklist
 
 Load these packaged skills now before editing:
-- `using-superpowers`
 - `openrig-user`
 - `mission-slice-sop`
 - `development-team`
 - `test-driven-development`
 - `systematic-debugging`
-- `writing-plans`
-- `executing-plans`
 - `verification-before-completion`
 
 Then run `rig whoami --json` and wait for the orchestrator + QA loop before making changes.

package/daemon/specs/agents/development/qa/agent.yaml

@@ -11,7 +11,7 @@ imports:
 profiles:
   default:
     uses:
-      skills: [using-superpowers, test-driven-development, development-team, systematic-debugging, verification-before-completion, agent-browser, dogfood, writing-plans, executing-plans]
+      skills: [test-driven-development, development-team, systematic-debugging, verification-before-completion, agent-browser, dogfood]
       guidance: []
       subagents: []
       plugins: [shared:openrig-core]
@@ -31,9 +31,9 @@ startup:
     - 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: using-superpowers, test-driven-development,
-        systematic-debugging, verification-before-completion, agent-browser, dogfood, writing-plans,
-        executing-plans. Load them first, then begin the work.
+        using your runtime's supported skill mechanism: test-driven-development,
+        systematic-debugging, verification-before-completion, agent-browser, dogfood. Load them
+        first, then begin the work.
       phase: after_ready
       applies_on: [fresh_start, restore]
       idempotent: true

package/daemon/specs/agents/development/qa/guidance/role.md

@@ -5,17 +5,14 @@ You are the quality assurance side of a dev pair. You gate every edit the implem
 ## Startup checklist
 
 Load these packaged skills now before reviewing work or dogfooding:
-- `using-superpowers`
 - `test-driven-development`
 - `openrig-user`
 - `mission-slice-sop`
 - `development-team`
 - `systematic-debugging`
+- `verification-before-completion`
 - `agent-browser`
 - `dogfood`
-- `writing-plans`
-- `executing-plans`
-- `verification-before-completion`
 
 Then run `rig whoami --json` and be ready to gate the implementer's first proposal before any edit lands.
 

package/daemon/specs/agents/factory-rsi/dogfood/agent.yaml

@@ -11,7 +11,7 @@ imports:
 profiles:
   default:
     uses:
-      skills: [using-superpowers, dogfood, systematic-debugging, verification-before-completion]
+      skills: [dogfood, systematic-debugging, verification-before-completion]
       guidance: []
       subagents: []
       plugins: [shared:openrig-core]

package/daemon/specs/agents/factory-rsi/release-manager/agent.yaml

@@ -11,7 +11,7 @@ imports:
 profiles:
   default:
     uses:
-      skills: [using-superpowers, verification-before-completion]
+      skills: [verification-before-completion]
       guidance: []
       subagents: []
       plugins: [shared:openrig-core]

package/daemon/specs/agents/orchestration/orchestrator/agent.yaml

@@ -11,7 +11,7 @@ imports:
 profiles:
   default:
     uses:
-      skills: [using-superpowers, orchestration-team, systematic-debugging, verification-before-completion, writing-plans, executing-plans, brainstorming]
+      skills: [orchestration-team, systematic-debugging, verification-before-completion]
       guidance: []
       subagents: []
       plugins: [shared:openrig-core]
@@ -31,9 +31,8 @@ startup:
     - 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: using-superpowers, systematic-debugging,
-        verification-before-completion, writing-plans, executing-plans, brainstorming. Load them
-        first, then begin the work.
+        using your runtime's supported skill mechanism: systematic-debugging,
+        verification-before-completion. Load them first, then begin the work.
       phase: after_ready
       applies_on: [fresh_start, restore]
       idempotent: true

package/daemon/specs/agents/orchestration/orchestrator/guidance/role.md

@@ -5,14 +5,10 @@ You are the orchestrator. You coordinate the work of other agents in this rig, m
 ## Startup checklist
 
 Load these packaged skills now before doing substantive work:
-- `using-superpowers`
 - `openrig-user`
 - `mission-slice-sop`
 - `orchestration-team`
 - `systematic-debugging`
-- `brainstorming`
-- `writing-plans`
-- `executing-plans`
 - `verification-before-completion`
 
 Then run:

package/daemon/specs/agents/review/independent-reviewer/agent.yaml

@@ -11,7 +11,7 @@ imports:
 profiles:
   default:
     uses:
-      skills: [using-superpowers, review-team, systematic-debugging, verification-before-completion, writing-plans, brainstorming]
+      skills: [review-team, systematic-debugging, verification-before-completion]
       guidance: []
       subagents: []
       plugins: [shared:openrig-core]
@@ -31,9 +31,8 @@ startup:
     - 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: using-superpowers, systematic-debugging,
-        verification-before-completion, writing-plans, brainstorming. Load them first, then begin
-        the work.
+        using your runtime's supported skill mechanism: systematic-debugging,
+        verification-before-completion. Load them first, then begin the work.
       phase: after_ready
       applies_on: [fresh_start, restore]
       idempotent: true

package/daemon/specs/agents/review/independent-reviewer/guidance/role.md

@@ -5,13 +5,10 @@ You are an independent code reviewer. You analyze code on your own merits withou
 ## Startup checklist
 
 Load these packaged skills now before reviewing:
-- `using-superpowers`
 - `openrig-user`
 - `mission-slice-sop`
 - `review-team`
 - `systematic-debugging`
-- `brainstorming`
-- `writing-plans`
 - `verification-before-completion`
 
 Then run `rig whoami --json`, inspect the current rig state, and stay ready for the first meaningful milestone or working-tree review.