@openrig/cli 0.5.4 → 0.5.5

package/daemon/assets/plugins/openrig-core/skills/mission-slice-sop/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: mission-slice-sop
-description: "Use when working a mission or slice: the canonical files (README / IMPLEMENTATION-PRD / PROGRESS / MISSION_NOTES / MISSION_BRIEF / PROOF), who owns what and when, how planning feeds building + review + QA, how to hand off through the queue, and how to survive compaction. This is the LIGHT default. It does NOT include the intent/plan-lock/proof-lock ceremony — that is a separate assigned overlay, `mission-slice-intent-proof-sop`."
+description: "Use when working on a mission or slice; editing SPEC.md, NOTES.md, PROGRESS.md, or PROOF.md; defining a proof contract or plan-lock/proof-lock; running rig proof; making a handoff; or preparing for compaction."
 metadata:
   openrig:
     stage: shipped
@@ -39,39 +39,34 @@ These three are a division of labour, not a chain of gates. One agent may hold a
 
 > These files are the **operating surface of the work** — you track on them, record on them, hand off through them, and survive compaction on them. Keep them current because that is what lets the work survive. But they **serve** the product; they are not the product. If you're polishing files while the actual thing isn't shipping, you've inverted it: go build, then update them.
 
-- **README.md** (mission + slice) — the overview. The **mission README carries this SOP at its bottom.**
-- **IMPLEMENTATION-PRD.md** — the plan, at whatever depth the work actually needs. For a small slice this may be a few lines. Elastic by design.
-- **PROGRESS.md** — the live delivery state. One line per outcome; links down for detail.
-- **MISSION_NOTES.md** — the accruing handoff + tribal-knowledge doc. Blank-slate onboarding and **compaction-restore** read it. `§1` top-of-mind + per-seat `§A–§X`.
-- **MISSION_BRIEF.md** — the steering doc (the UI "Steering" tab). The 7-section schema.
+- **SPEC.md** (mission + slice) — the one authored node file. `intent:` lives in frontmatter; the slice body specifies through `## Intent`, `## Mini-requirements`, and `## Proof contract`. Advisory sibling build-order edges live in `depends_on:`.
+- **PROGRESS.md** — the durable mission/slice acceptance checklist. In-process steps stay in the working agent's todo tool.
+- **NOTES.md** — lived context and observations that help the mission without changing its contract.
 - **PROOF.md** (+ `proof/`) — what you actually verified, stated honestly. A couple of honest, LOOKed-at lines beat an elaborate contract.
 
 ## Per-file rules — WHO / WHEN / HOW
 
 ### PROGRESS.md
-- **WHO:** the orchestrator owns `§1` (current state); every agent logs its own outcomes.
-- **WHEN:** after every slice-done **and every commit**; on any material state change.
-- **HOW:** one line per outcome (checkbox), link down for detail; keep frontmatter `stage`/`verified` honest.
+- **WHO:** the mission/slice owner keeps acceptance honest.
+- **WHEN:** when an acceptance outcome changes, especially at handoff and close.
+- **HOW:** one checkbox per durable outcome. Do not copy in-process todo steps into it.
 
 ### PROOF.md + proof/
 - **WHO:** the impl/QA pair that worked the slice.
 - **WHEN:** before you call a slice done.
 - **HOW:** say what you verified and how you verified it — **by effect**: you ran it and looked at the result. Put supporting media under `proof/`. State plainly what is proven and what is **not**; an honest "this half is untested" is worth more than a checkmark. If a drop verb is in play for this slice, prefer it over hand-placing files so the artifact carries its own provenance.
 
-### MISSION_NOTES.md
-- **WHO:** any agent updates `§1` (top-of-mind); each seat owns and appends to its own `§A–§X`.
-- **WHEN:** on any material change; a compacting agent **files its state here BEFORE compaction and reads it on restore.**
-- **HOW:** accruing tribal knowledge — `§1` ≤ 5–15 lines (gates, open decisions, surprises); per-seat continuation entries (latest = truth; other seats read-only). Pointer-first; don't duplicate.
+### NOTES.md
+- **WHO:** whoever did or observed the work.
+- **WHEN:** when lived context will help the next worker but does not belong in the contract.
+- **HOW:** write raw observations freely; point to durable artifacts instead of copying them.
 
-### MISSION_BRIEF.md
-- **WHO:** product/design (steering owner). **WHEN:** when steering changes. **HOW:** the 7-section steering schema.
-
-### README.md
-- **WHO:** the author at creation; refreshed on rescope. **WHEN:** at creation + when scope/theme changes. **HOW:** overview + honest frontmatter (`id`/`stage`/`verified`); the mission README carries this SOP at its bottom.
+### SPEC.md
+- **WHO:** the node owner. **WHEN:** at creation and on a real rescope. **HOW:** keep `intent:` and advisory `depends_on:` in frontmatter; only slice bodies specify buildable work.
 
 ## The lifecycle (4 legs)
 
-**SCAFFOLD** (`rig scope` creates the files from templates) → **POPULATE** (agents fill them as work happens) → **PROJECT** (the Living Notes UI reads them into INTENT → PLAN → DELIVERED) → **VERIFY** (`rig scope audit`, advisory). "Loose freeform write + deterministic verify."
+**SCAFFOLD** (`rig scope` creates the files from templates) → **POPULATE** (agents fill them as work happens) → **PROJECT** (scope readers and the TUI derive the current view) → **VERIFY** (`rig scope audit`, advisory). "Loose freeform write + deterministic verify."
 
 ## Hot-potato (handoffs)
 
@@ -94,7 +89,7 @@ When you `rig capture` a pane, **greyed / ghost autocomplete suggestions are NOT
 ## Moment-of-truth checklist
 
 - **Starting a slice?** → do you know what it's for and what done looks like? mockups attached (UI slices)? **Are you on the light path?** (You are, unless the mission owner assigned the overlay.)
-- **Finishing a slice?** → does PROOF.md say what you actually verified, by effect, including what is NOT covered? PROGRESS updated? MISSION_NOTES `§1` refreshed? handed off via `rig queue handoff`?
-- **Committing?** → PROGRESS updated?
-- **Compacting?** → filed your state in MISSION_NOTES?
-- **Starting on a mission?** → read the mission README (incl. this SOP) + MISSION_NOTES + the conventions SSOT.
+- **Finishing a slice?** → does PROOF.md say what you actually verified, by effect, including what is NOT covered? Acceptance updated in PROGRESS? handed off via `rig queue handoff`?
+- **Rescoping?** → update SPEC.md; ordinary implementation steps do not belong there.
+- **Compacting?** → deposit seat continuity in the seat's restore surface; NOTES.md holds only work-tree lived context.
+- **Starting on a mission?** → read the mission SPEC.md + NOTES.md + the conventions SSOT.

package/daemon/assets/plugins/openrig-core/skills/openrig-operating-model/CHANGELOG.md

@@ -0,0 +1,92 @@
+# Changelog — openrig-operating-model
+
+Why the model is shaped the way it is. **`SKILL.md` carries the model; this file carries how it
+got there.** Rationale, superseded designs, and the incidents that produced a rule live here so
+the instruction surface stays instructional.
+
+---
+
+## 2026-08-12/13 — the simplification
+
+### `NOTES.md` was retired and restored the next day — a measurement error worth keeping
+
+Retired 2026-08-12 on the evidence that **`NOTES.md` had zero instances anywhere.** That number was
+correct and the conclusion was wrong: the function was adopted **55 times as `MISSION_NOTES.md`**
+(35 at mission root). **The name was searched for; the function was not.**
+
+Restored as the work tree's **lived** file — the counterpart to `LEARNED.md` on the topology tree,
+never generated, never projected, written by whoever is doing the work. `MISSION_NOTES.md` stays
+resolvable as the legacy spelling, but the chain name is `NOTES.md`: `MISSION_` is
+altitude-specific, and a chain uses one name at every altitude.
+
+The general form, since it recurred all week: **a scoped search reported as a global absence.**
+Asking "does this filename exist" answers a different question from "does this job have a home."
+
+### Five chains became three
+
+Superseded: `INTENT.md`, `SPEC.md`, `NOTES.md`, `PROGRESS.md` as separate work-tree chains, plus
+`SOP.md` on the topology tree.
+
+Now: **`LEARNED.md`** (topology) and **`SPEC.md`** (work), with `intent:` in `SPEC.md`'s
+frontmatter.
+
+- The four-chain work tree was designed and never adopted — `INTENT.md` existed **twice** across
+  1,051 files. The design asked for four files where the work only ever produced one.
+- Intent is a *chain* (every altitude) and spec is a *leaf* (missions organise, they do not
+  specify), which argues for two files right until intent moves into frontmatter. Then one file
+  serves both: the walk composes the **field**, the body is read only when you stand on that node.
+- `README.md` → `SPEC.md` because names are prompts. README says "background reading"; what is
+  actually there is a node definition with machine-read frontmatter. Legacy `README.md` stays
+  valid indefinitely and the resolver prefers `SPEC.md`, so nothing is ever forced to migrate.
+- `PROOF.md` was kept. It is the one check that reliably goes unmade.
+
+### `SOP.md` left the tree
+
+It is knowledge about a *kind*, and kinds are what plugins package. It now ships as a skill inside
+the rig's mode plugin. The chains kept only what is true of a *position*.
+
+This also fixed a packaging bug: `openrig-core` shipped the factory's `mission-slice-sop` alongside
+genuine primitives, so **every rig installing "core" inherited the factory's operating model
+whether it was a factory or not.** This VM felt like a factory before anyone chose one.
+
+### `instance` entered the taxonomy
+
+`fleet → instance → rig → pod → seat`.
+
+Every hardware-flavoured word failed because the altitude is not hardware — it is one daemon and
+the rigs it manages. `host` failed specifically because substrate *nests* (a VM runs on a host runs
+in a datacentre), so a reader can resolve it to the wrong rung; **that conflation once sent a real
+upgrade to the wrong machine.** `topology` was demoted: the code already uses it for the
+arrangement of pods and seats within one rig, which is the natural reading.
+
+### Shelves stopped being nodes
+
+Directories that hold instances of an altitude (`rigs/`, `missions/`, `slices/`) carry no chain
+file. Briefly they did here — added to make a walk report a clean 5/5, which inflated a checkmark
+by writing a *definition of the kind* into a *position* chain, duplicated from `SKILL.md`.
+
+### Audience and maturity were separated
+
+They had been quietly multiplied into one axis: a tempting model where climbing the tree *was*
+climbing the epistemic ladder. It is wrong. Pod-level content can be raw observation; seat-level
+content can be canon. Audience decides the file; maturity is an attribute of a line inside it, and
+promotion to canon can happen at any altitude.
+
+### Tooling caught up
+
+- `compose.py --field` composes one frontmatter field up a chain.
+- `compose.py --prefer` treats `--name` as a precedence list resolved per level, so a tree
+  mid-rename walks instead of reading as broken, and the map names which file answered.
+- `scaffold.sh` was **generating the superseded design** — `work) FILES=(INTENT.md NOTES.md)` —
+  for a day after the docs changed. Docs that lie are annoying; tools that lie rebuild what you
+  removed. **Check what generates a convention before what describes it.**
+
+---
+
+## Known gaps
+
+- The walk map renders a **shelf** and a real **gap** identically (`✗ absent`). It wants a third
+  state; until then correct-and-expected screams as loudly as a genuine hole.
+- The topology tree has no configuration key, so a shipped script cannot resolve it portably the
+  way the work tree resolves from `workspace.root`.
+- `LEARNED` distillation has a designed trigger (deposit boundaries) and no implementation.

package/daemon/assets/plugins/openrig-core/skills/openrig-operating-model/REVISION-GUIDE.md

@@ -0,0 +1,34 @@
+# Revision guide — for agents improving this skill
+
+Authored in one sitting by the seat that held the full design context
+(product-team generation 4, 2026-08-09, owner-ordered sole authorship to avoid dilution).
+Revise freely WITHIN these boundaries; the authoring seat (or its successor)
+checks every change.
+
+## LOAD-BEARING — do not change the meaning (wording tweaks fine)
+- Two trees + uniform-filename law (one name per chain; folder=context; path=instance).
+- The axis (template/learned) + per-chain amendment clocks.
+- The trace laws: read-receipts-not-recitation · report-broken-links-never-obey ·
+  chains inform, never enforce.
+- The trace principle + its taught failure mode (§5): identical scheduled prompts decay and idle seats accumulate ritual — teach the principle, allow scheduling where context fits; the due-check script is the preferred gate, not a law.
+- LEARNED size is SOFT guidance (attention budget + Deuteronomy warning as a taught antipattern) — never reintroduce a hard cap.
+- Composed views generated-never-edited; approvals that freeze content record the hash of a render (§7). Plain language — no 'seal'/'fold' jargon; those were seat-local terms and are banned from this skill.
+- Placement rule (§8) + the dual-home interim rule (ROLLOUT.md): do NOT drain skills before the registry.
+- Seeding-as-audit + never-bulk-seed + wave pacing (all in ROLLOUT.md).
+- The write principles (§6, exactly two — resist re-complicating them into protocol tables; an over-specified write protocol was cut from v1 for breaking the model's own cheap-to-update law).
+- "fleet" not "host".
+
+## IMPROVABLE — expected revision surface
+- Script robustness (portability: `date -r` vs `stat -f` is macOS-flavored;
+  Linux needs `stat -c %Y`; add tests).
+- Template wording, more worked examples, a rendered example LEARNED.md.
+- scaffold.sh ergonomics (node discovery from a rig spec instead of --node args).
+- compose.py: ordering options, front-matter-aware rendering, seal-hash helper.
+- Frontmatter/metadata conformance to the skill-factory's current schema.
+
+## PROCESS
+1. Propose changes as a diff (queue item to the authoring seat).
+2. Load-bearing changes need the authoring seat's explicit OK before landing.
+3. When this skill ships to source (target: 0.5.1 skill+scripts, doc 0.5.4),
+   the shipped copy is generic: keep host-specific anything OUT (placement law —
+   host specifics live in the tree this skill bootstraps, never in the skill).

package/daemon/assets/plugins/openrig-core/skills/openrig-operating-model/ROADMAP.md

@@ -0,0 +1,23 @@
+# ROADMAP — what gets formalized in product code, and when
+
+SKILL.md teaches the model as it works TODAY (markdown + scripts only). This
+file tracks what later ships in OpenRig product code. Verbose on purpose;
+none of this belongs in the SOP.
+
+| Piece | Interim (now) | Formalization target |
+|---|---|---|
+| The skill + scripts themselves | this folder, host-level projection | ship with 0.5.1 (zero product code — skill and scripts only; every new install gets the fallback-design version) |
+| Work-triggered trace | manual + trace-due.sh under watchdog | 0.5.4 — the drift-correction spec (FROZEN) formalizes the trigger on the per-seat usage series and the delivery as durable queue items |
+| STEERING→INTENT naming | files renamed at rollout; pointer files at old names | 0.5.4 — conform-amendment to the frozen spec's steering-substrate unit (its owner sweeps every narrative surface) |
+| Seat scaffolds + boot order | scaffold.sh + convention (read SOP/LEARNED before any handover packet) | 0.5.4–0.5.5 — seat-create scaffolds the pair; launcher/boot integration |
+| SPEC render + lock semantics | new work may fragment; compose.py renders; locks hash the render by convention | 0.5.5 — `rig scope spec render <node>`; plan-lock records the render hash natively (a lock-semantics change; needs its own spec) |
+| Render verb family + trunk diff | compose.py / trunk-diff.sh | 0.5.5 — `rig render <tree> <node>` |
+| Hot/cold skill pool | de-facto hot tier (profile-selected ambient projection); cold = context packs + library, separate indexes | 0.6 — one registry, multi-source cold pool, per-seat tier assignment in specs; THE DRAIN of mis-shelved skill content into the trees happens here, not before |
+| Compaction-restore + handover restore-map | today: full-context salvage (crude blunt instrument) + rich packet; dual-rail per owner ruling 2026-08-10 | 0.5.4 REVISIT (owner-directed): once the ontology walk works live, the restore map SHRINKS — ontology rebuilds via the seat's own trace (SOP/LEARNED/INTENT chains), so restore artifacts reduce to slim SESSION NOTES carrying the earned nuance/epistemology the files can't (judgment traces, in-flight reasoning). Old machinery retires only after migration + demonstrated confidence, per the dual-rail ruling. |
+| The Operating Model document | the workspace artifact + this skill | 0.5.4 — ships in source as the operating-model doc; absorbs/supersedes sdlc-conventions.md and the overlapping parts of mission-slice-sop |
+| PROGRESS roll-up | already shipped machinery + re-surfacing spec | 0.5.2 (in build) — proof-item checkbox as the single mark level |
+
+Release-ladder context at the time of writing: 0.5.1 = test system
+(stabilization, at its cut) · 0.5.2 = human layer · 0.5.3 = maintenance/
+dogfood of 0.5.2 · 0.5.4 = drift-correction system · later = renders,
+registry. The ladder is the design authority's; entries here move when it moves.

package/daemon/assets/plugins/openrig-core/skills/openrig-operating-model/ROLLOUT.md

@@ -0,0 +1,234 @@
+# ROLLOUT — adopting the Operating Model on a live fleet
+
+This file is deliberately verbose. It is the adoption plan, the interim
+practices, and the reasoning — everything time-bound that does NOT belong in
+SKILL.md (which teaches the model itself, timelessly).
+
+## Why a rollout plan exists at all
+
+This model was designed after a measured failure: several consecutive
+generations of critical seats onboarded through handover documents alone and
+each lost most of the operational knowledge of its predecessor — without
+knowing it (the Dunning-Kruger shape: the loss is invisible from inside).
+The fleet also has real rate limits: fifty seats reading a large skill
+simultaneously is a provider incident, not a rollout. Both facts shape
+everything below.
+
+## The three pieces
+
+1. **The markdown** — files must exist before anyone can walk them.
+2. **The rolling upgrade** — seats adopt in small waves, top-down.
+3. **The enforcement floor** — watchdog-fired due-checks keep the trace habit
+   alive without any new product code.
+
+## Piece 1 — the markdown layer (create/rename/map; migrate nothing finished)
+
+- **Rule zero: no migration of finished work.** Completed missions, closed
+  specs, historical notes stay untouched forever. The model starts with work
+  IN FLIGHT and everything new.
+- **Renames:** the old `STEERING.md` files become `INTENT.md` (same content,
+  new name — "steering" predated the fleet's settled use of the word intent).
+  Leave a one-line pointer file at the old name for one transition period.
+  The frozen drift-correction spec (0.5.4) refers to the steering substrate;
+  its owner amends the naming there (see ROADMAP.md).
+- **Mappings, not moves:** today's standalone slice PRD IS the slice-level
+  `SPEC.md`, as-is, no edits. `MISSION_NOTES.md` keeps serving every mission
+  that already uses it; new missions start with `NOTES.md`.
+- **Creation:** `scripts/scaffold.sh` places missing chain files as UNSEEDED
+  templates. It never overwrites, never deletes.
+- **Topology-tree root, RULED (pm-lead wave-1 review, 2026-08-10):** the
+  canonical on-disk root for topology chain files is the existing rig home —
+  `shared-docs/rigs/<rig>/` — so a seat's files live at
+  `shared-docs/rigs/<rig>/seats/<seat>/`. That shelf already holds each rig's
+  `rig.yaml`, rig-level `CULTURE.md`, and `state/`, so the chain composes with
+  what exists instead of minting a parallel tree. Seat instances never live
+  inside this skill's directory (the skill is distribution canon, not runtime
+  state; the two early seeds that diverged were reconciled here: pm-openrig's
+  provisional placement confirmed, pm-lead's moved to match).
+- **Seat files:** created by scaffold, but their CONTENT is seeded only by the
+  protocol below — never mass-produced.
+
+## Piece 2 — the rolling upgrade
+
+**Wave order and why:** those who review others must hold the model first.
+
+- **Wave 1 — coordinators:** the PMs, the operator agent, the oversight lead,
+  rig orchestrators. Small group, immediately; they will be reviewing every
+  later seed.
+- **Wave 2 — the priority rig.** (At the time of writing: the build VM — the
+  current unblock focus.) Its orchestrator paces its own seats: a few at a
+  time, as their work allows, never all at once.
+- **Wave 3 — the next rig.** (At the time of writing: the studio rig.)
+- **Wave 4 — everyone else, on contact:** a seat reads the skill the first
+  time work reaches it under the model. No seat is interrupted just to read.
+
+**Pacing law:** waves are small and self-paced BY DESIGN — this is a
+rate-limit safety rule, not a preference. An orchestrator rolling its rig
+staggers reads. If a wave would put more than a handful of seats into
+simultaneous heavy reading, split the wave.
+
+**The adoption receipt is the seed.** A seat has adopted when its
+`LEARNED.md` v1 exists, written BY THAT SEAT in its own words (distilled from
+whatever records it has — handover documents, its runtime memory, its queue
+history), and reviewed by its orchestrator or PM. Reading without seeding is
+not adoption; there is deliberately no other receipt to fake.
+
+**Seeding doubles as the capability audit.** A seat that cannot write its own
+MY JOB HERE section has just revealed precisely what its handover lineage
+lost. That discovery is a SUCCESS of the rollout, not a failure — it converts
+an invisible capability gap into a named, fixable one. Orchestrators: when a
+seed comes back thin or confused, that seat needs re-onboarding against its
+SOP, not a rewrite of its seed by someone else.
+
+**Hierarchy-seeded exceptions:** empty seats, broken seats, and seats being
+re-staffed get their files written by whoever is responsible for them, with
+those lines marked as written-for-the-instance. The next real occupant
+rewrites them in its own words as a first act.
+
+## Piece 3 — the enforcement floor (no product code required)
+
+Register a watchdog (or any scheduler) per adopted seat that fires
+`scripts/trace-due.sh` on a modest cadence. The script no-ops silently unless
+enough has actually changed since the seat's last trace, so the schedule can
+be dumb while the action stays evidence-gated. When it reports DUE, the seat
+runs the trace per SKILL.md §5 and stamps (`scripts/trace-stamp.sh`).
+Schedulers, files, and two tiny scripts — that is the entire interim
+enforcement system, and it degrades gracefully: if every scheduler dies, the
+model still works, just without reminders.
+
+## The dual-home interim (skills are NOT drained yet)
+
+Much altitude-specific knowledge currently lives in the skill layer (pod
+handbooks, seat SOPs, fleet doctrine) because the skill layer was the only
+durable shelf that existed. The placement rule says that knowledge belongs in
+the trees — AND the drain does not happen now. During rollout:
+
+- existing skills remain exactly where they are and remain authoritative;
+- the new tree files are built USING them as reference material;
+- the same knowledge deliberately lives in both places for a while;
+- the drain happens later, deliberately, when the unified skill registry
+  lands (see ROADMAP.md) — never as a side effect of the rollout.
+
+## SOP authoring plan (owner-approved 2026-08-10; product team owns)
+
+**Composition (owner-ruled 2026-08-10):** pod SOP = the general layer ·
+seat SOP = a TYPE fragment, shared/projected across same-type seats (byte-
+identical; occupant edits go to LEARNED, never the fragment; divergence is a
+parity scream) · LEARNED = the lived instance. Fragments are authored per TYPE
+(roughly ten fleet-wide), never per seat.
+
+**Round 1 — type fragments, by the three-hands pattern:**
+1. *Incumbents* of the type dump raw seat-truth to a `SOP-STASH-raw.md`
+   (facts as learned, not doctrine), including a **drift-check line**: which
+   skills they actually consult vs what their `agent.yaml` declares.
+2. *A fresh one-shot author* (single-purpose agent, no continuity required —
+   all state lives in files, so the step is robust to handover/compaction
+   failures) distills the fragment from a **named reading list**, pinned at
+   dispatch with an existence check on every path:
+   exemplar fragments (the accepted product-manager fragment + the PM pod
+   layer) → the seat's `agents/<role>/agent.yaml` (its `uses.skills` list IS
+   the derived canon list) + `guidance/role.md` (the fragment's direct
+   ancestor — read AGE-STAMPED; where it disagrees with the STASH, record
+   drift, don't resolve) → the 2–4 declared team/role skills →
+   `state/onboarding/` material and ADRs where the rig has them → the STASH.
+   Constraints inline: ~1 page · type-level only (instance→LEARNED candidates,
+   rig-wide→pod/rig layer — the author routes, never dumps) · `Sources:` line ·
+   flag gaps, never invent.
+3. *Type occupants verify* ("does this describe my job?") and the rig
+   orchestrator/PM holds the coherence + placement review.
+   **Criterion upgrade (from the wave-1 outside-lineage cold read, 2026-08-11):**
+   beyond voice/duties/scars/gaps, review for **SELF-CONSISTENCY** — does the
+   file obey its own stated rules? (the wave-1 misses were all files breaking
+   their own rule: cached doctrine beside a read-at-source rule; a volatile
+   snapshot beside a presence-check rule; an expiry with no trigger beside a
+   remembered-follow-up-is-not-a-mechanism rule) — and **POST-SEED ALIVENESS**:
+   a one-sitting seed legitimately wears the dated-ledger form, but reviewers
+   re-read at ~+2 weeks; a LEARNED that never gains a post-seed entry is a
+   monument, not a rail.
+   Old artifacts (role.md, agent.yaml, team skills) stay exactly where they
+   are and stay authoritative — dual-home until the deliberate drain.
+   Order: wave-2 build-VM types first, then oversight, kernel/ops, studio.
+   skills-architect spends ZERO tokens now (context-constrained + handover in
+   process); their batched consistency pass rides the 0.6 registry drain.
+
+**Binding inputs registered for round-1 fragments** (owner-flagged content
+that MUST land in the named fragment; a draft missing its binding input fails
+review — this list is read at every one-shot dispatch and at every review):
+- **DRIVER type (build VM)** — owner recurrence flag 2026-08-10 (~100th
+  correction, zero uptake while it lived only in chat): on the VM, the DEFAULT
+  for a runtime defect is the **inner loop** — ground → fix → upgrade the
+  daemon in place → test with your own eyes → iterate; ship-rigor once at the
+  end; rollback only for a VM that cannot work. The conveyor is not the
+  default for a one-mechanism defect.
+- **ORCHESTRATOR type (build VM)** — same flag: before routing any defect
+  into the conveyor, ask first whether ONE grounded agent with its own
+  feedback loop can fix and verify it in place. Conveyor only for what ships
+  beyond the VM or touches locked contracts.
+- **THE CHOOSER (owner root diagnosis, same conversation, addendum 2026-08-11):**
+  the incoherence under the recurrence is that every task gets the identical
+  SDLC regardless of shape. Carried as ONE principle, not a rubric: **default =
+  the lightest thing that could work** (one agent, own judgment, own feedback
+  loop); the conveyor must be EARNED by a stated one-line reason (ships beyond
+  VM / public / locked contract / security boundary / multi-hand scope); no
+  reason line = light path. The orchestrator fragment carries the triage
+  question; the driver fragment carries the inner loop. Deliberately NOT a
+  classification taxonomy — a taxonomy would be new ceremony.
+- **SHARPER FORM (orch-advisor's self-seeded fold — use this shape):**
+  (1) SCAR-vs-LAW — a lesson stated only negatively teaches fear of one
+  mistake, and occupants drift back UP because ceremony always FEELS like
+  rigor at zero visible cost; the fragment must state the POSITIVE default
+  (light; conveyor earns entry with a reason line) because that is what makes
+  the choice decidable. (2) THE COROLLARY — a tier chosen correctly once does
+  not stay correct; the tier is a function of the atom, not a property the
+  atom keeps; RE-CHOOSE whenever the surface changes (specimen: P18 judged
+  conveyor-worthy with a config surface, descoped to mostly-deletion, old
+  tier = ceremony inherited by momentum). Both belong in the ORCHESTRATOR
+  fragment, verbatim-substance.
+- **ALL-TYPES binding input (triple-confirmed 2026-08-11: dev50-driver ×4 in
+  one night, orch-advisor ×3, pm-openrig desk ×2): THE SCOPED-READ LAW —
+  "a scoped read that does not name its scope manufactures a false absence."**
+  Every list/show/ps/send resolves against SOME scope (rig, daemon, host,
+  registry, filter); a negative result is only evidence within the named
+  scope. Every seat-type fragment carries this; reviewers enforce it like the
+  chooser.
+(Companion folds already in flight at the implicated seats' LEARNED files:
+product planning done; operator a947ed35 and advisor 1f89e5d6 owner-directed.)
+
+**Round 2 — ontology backfill per seat, pod, and rig (owner-directed
+2026-08-10):** after a node's SOP/LEARNED pair exists, one deliberate
+audit pass folds the rest of its scattered wisdom into the walkable layer:
+- **Claude memory files** (`~/.claude/projects/*/memory/` per seat) — tribal
+  wisdom that is written but almost never re-read (the "learning banked, then
+  never consulted again" failure mode this model exists to kill). Each memory
+  item either folds into LEARNED/SOP at its altitude or is explicitly
+  left as session-scoped; LEARNED folds are executed by the seat itself
+  (self-seeded law), playbook-layer folds by the fragment's owner.
+- **openrig-work core** — doctrines, `conventions/`, and skills content that
+  is really seat/pod/rig practice — same routing, same dual-home rule:
+  originals stay in place and authoritative; the trees gain the walkable copy;
+  the drain stays a later deliberate act.
+
+## Current status (update this section as waves complete)
+
+- Design locked by the owner: 2026-08-09.
+- Skill authored (sole-context authorship) and projected on the primary host:
+  2026-08-09. VM projection: operator's leg, with wave 2.
+- Wave 1 COMPLETE 2026-08-10: all five coordinator seats seeded + reviewed
+  (pm-openrig, pm-lead, watch-lead, pm-studiobox, operator-agent). Wave 2
+  (build VM) released the same day; its orchestrator paces.
+- First SOPs exist: PM pod layer + product-manager type fragment
+  (projected to both product-PM seats) + program-manager type fragment.
+- STEERING→INTENT rename: openrig-platform done (owner) · factory anchor +
+  openrig-work root done 2026-08-10 (pointers at old names) · studio-boxes =
+  pm-studiobox's to execute · idea-ledger-gstack pending its owner.
+- The factory is unparked (wave-1 adoption complete).
+- NAMING RULED (owner, 2026-08-11): PLAYBOOK.md -> **SOP.md** fleet-wide
+  (names are prompts; SOP = the consult-and-follow trigger, factory-native).
+  All seven existing files renamed with one-transition pointers at old names;
+  LEARNED keeps its name (it is the maturity PIPELINE, and the low-friction
+  write-prompt is load-bearing). Projection recipes are **maps** (codemaps,
+  the name's prior holder, retire into this system). The corpus/canon
+  distribution program = skill **openrig-corpus-canon** (design of record:
+  product/DESIGN-context-distribution-2026-08-10.html); round-2's
+  hand-fold-canon leg is SUPERSEDED by it — round-2's lived-side leg
+  (claude-memory -> LEARNED, seat-executed) continues unchanged.