@openrig/cli 0.5.8 → 0.5.9

package/daemon/assets/claude-statusline-context.cjs

@@ -42,6 +42,7 @@ process.stdin.on("end", () => {
       },
       session_id: raw.session_id ?? null,
       session_name: raw.session_name ?? null,
+      occupant_generation: process.env.OPENRIG_OCCUPANT_GENERATION || process.env.RIGGED_OCCUPANT_GENERATION || null,
       transcript_path: raw.transcript_path ?? null,
       sampled_at: new Date().toISOString(),
     };

package/daemon/assets/plugins/openrig-core/README.md

@@ -4,7 +4,7 @@ Canonical OpenRig skills and hooks for cross-runtime agent topology coordination
 
 ## What this plugin ships
 
-**Skills (17):** canonical OpenRig operating knowledge, including the public `refocusing` skill and
+**Skills (19):** canonical OpenRig operating knowledge, including the public `refocusing` skill and
 its path-only topology/work trace.
 
 **Hooks:** activity tracking, compaction continuity, and the default-on refocus channel. Refocus is

package/daemon/assets/plugins/openrig-core/skills/agent-operated-software/SKILL.md

@@ -0,0 +1,92 @@
+---
+name: agent-operated-software
+description: >-
+  Use when designing, building, operating, or diagnosing an ongoing application whose live backend
+  or control loop includes OpenRig agents, including applications with a Markdown, YAML, or JSON
+  agent control plane or a thin surface over specialist agent roles.
+metadata:
+  openrig:
+    stage: provisional
+    audience: any agent building or operating an agent-backed application
+    sibling_skills:
+      - agent-operated-workflows
+      - forming-an-openrig-mental-model
+      - mission-slice-sop
+      - openrig-user
+---
+
+# Agent-Operated Software
+
+**Agent-Operated Software** is an ongoing application whose functioning runtime includes an OpenRig
+agent or rig in its live backend or control loop. The application surface can be thin: structured
+state and specialist roles do the work, while the UI makes that work legible and steerable.
+
+## Start with the shared taxonomy
+
+- **AI-enabled software:** application code owns the control loop and calls a model as one capability.
+- **Agent-Operated Workflow:** an agent owns one bounded procedure with a start and stop condition;
+  see `agent-operated-workflows`.
+- **Agent-Operated Software:** agents participate in an ongoing application's functioning runtime.
+
+An application may compose many Agent-Operated Workflows. A bounded workflow does not by itself make
+its surrounding product Agent-Operated Software, and a model call is neither category unless an agent
+owns part of the control loop.
+
+## Agents are part of the backend
+
+In this architecture, behavior is not located only in functions. It is distributed across agents,
+skills, instructions, bootstrap files, schemas, Markdown, YAML, JSON, folders, and deterministic
+tools. A surprising result may therefore be a code defect or a coherence gap in this control plane.
+Trace the path that actually produced the behavior before choosing which layer to repair.
+
+This is not permission to tolerate defects in OpenRig core or another rock-solid substrate. There,
+reproduce the bug, fix the code, and hold the full gate. The faster coherence-first posture belongs
+to recoverable agent-operated application layers whose state and behavior can be inspected and
+repaired cheaply.
+
+## Markdown is the control plane
+
+Markdown is maximally useful to an agent while remaining legible enough for a human to steer. Put
+intent, work state, evidence, and decisions into stable addressed artifacts rather than private chat
+or an opaque custom database. Keep schemas and conventions aligned with the running behavior: the
+agent population acts on those files as executable context.
+
+Use **progressive disclosure**. A skill's name and description are the hot trigger; its body is cold
+procedure. Descriptions say when to load, not how to work. The body should route the reader to exact
+sources instead of copying them into another doctrine fork.
+
+Scripts can act as prompts. A good script returns the context or exact effect an agent needs; when it
+cannot, its failure teaches what it observed, why it stopped, and safe next actions. Keep deterministic
+mechanics in tools and judgment in agents.
+
+## Make artifacts self-certifying
+
+When a tool produces an artifact, do not make every consumer invent a completeness test:
+
+1. Write to a partial path, never the final path.
+2. Verify the property that can actually be wrong, such as duration, streams, resolution, or schema.
+3. Flush and atomically rename the partial artifact to its final path.
+4. Write the manifest, then a `.done` sentinel last.
+
+Consumers fail closed on the shared proof. A filename or exit code is not content verification.
+
+## Build with an agent SDLC
+
+Map work onto **intent -> plan -> spec -> build -> verify -> review -> QA -> done**. The human supplies
+steering, judgment, taste, and the call on irreversible ambiguity; agents perform and coordinate the
+technical work. Locks freeze the agreed spec and accepted delivery so multiple seats can work without
+guessing whether the target moved.
+
+For studio applications, the running product is usually the best iteration surface. A separate mockup
+earns its cost only when it resolves a real design uncertainty that the running app cannot expose as
+cheaply. This removes a redundant artifact, not the visual review or proof contract.
+
+## Repair the narrowest authoritative layer
+
+Find the generator or source that every affected agent actually consumes. Fix a code defect in code;
+fix a missing trigger in the skill; fix a malformed contract in its schema. Then verify through the
+consumer. Editing a rendered or installed copy creates a temporary fork, not a repair.
+
+The payoff compounds: a correction to the shared application control plane changes the next agent's
+starting point. That is how an ongoing agent-operated system improves without making one human its
+permanent router.

package/daemon/assets/plugins/openrig-core/skills/agent-operated-workflows/SKILL.md

@@ -0,0 +1,79 @@
+---
+name: agent-operated-workflows
+description: >-
+  Use when a bounded real-world procedure has a deterministic happy path but brownfield, variable,
+  or partially knowable state; when an operation must resume from verified evidence; or when deciding
+  whether agent judgment or ordinary code should own a procedure's control loop.
+metadata:
+  openrig:
+    stage: provisional
+    audience: any agent operating or designing a bounded procedure
+    sibling_skills:
+      - agent-operated-software
+      - openrig-user
+      - systematic-debugging
+---
+
+# Agent-Operated Workflows
+
+An **Agent-Operated Workflow** is a bounded procedure whose control loop belongs to an agent. The
+agent observes, interprets, sequences bounded actions, verifies their effects, adapts, and escalates
+genuine ambiguity. Deterministic code remains the exact substrate; it does not pretend to understand
+every state of a brownfield world.
+
+## Name the architecture before using it
+
+- **AI-enabled software:** application code owns the control loop and calls a model as one capability.
+- **Agent-Operated Workflow:** an agent owns one bounded procedure with a start and stop condition.
+- **Agent-Operated Software:** an OpenRig agent or rig participates in an ongoing application's live
+  backend or control loop. It may run many workflows; see `agent-operated-software`.
+
+Calling a model is not enough. A deterministic program that consults a model still owns its loop.
+
+## Decide whether the agent earns the loop
+
+Use an agent when the happy path is deterministic but the environment is brownfield, variable,
+partially knowable, or disproportionately expensive to model exhaustively. The judgment is in
+discovering what is true and choosing the next safe act.
+
+Prefer ordinary code when the state space is closed and code is simpler and more reliable than
+judgment. A parser, fixed data transformation, or fully enumerated state machine does not become
+better because an agent drives it.
+
+## Keep ownership explicit
+
+| Owner | Responsibility |
+|---|---|
+| Runbook | owns policy, the mental model, checkpoints, stop conditions, and escalation rules |
+| Deterministic tools | own context gathering and bounded exact actions |
+| Agent | owns interpretation, sequencing, adaptation, and effect verification |
+| Human | owns destructive ambiguity and product policy |
+
+The runbook guides judgment; tools enforce the invariants that must not be arguable.
+
+## Operate
+
+1. Establish identity, durable state, the runbook, and the promised outcome.
+2. Inspect with side-effect-free reads or an explicit plan mode.
+3. Choose one bounded action from observed state; do not mechanically replay the happy path.
+4. Verify the effect at the consumer or state surface that could prove it wrong.
+5. Record an observable checkpoint before moving on, so another agent can resume.
+6. Continue, stop at the declared condition, or escalate with evidence and the decision needed.
+
+An interrupted or timed-out mutation is **indeterminate**, never failed by assumption and never safe
+to retry blind. Where a compatibility period is safer, separate reversible preparation from the
+destructive finalizer. Idempotence is a claim to prove per action, not a label for the whole run.
+
+## Build
+
+Expose composable verbs, not an optimistic end-to-end controller. Help is inert. Read and plan modes
+are explicit. Mutations are narrow and independently readable. A failure should say what was
+observed, why the tool stopped, what remains unchanged, the safe next choices, and where its evidence
+lives. Keep checkpoints durable, effects observable, and recovery possible without private developer
+knowledge.
+
+A capability composition is a reusable recipe; this is the execution architecture that operates
+capabilities toward an outcome. Promote a proven workflow to the composition shelf only after use.
+
+**Reference implementation:** Release 0.5.9 Slice 05 is the first **Agent-Operated Migration**. Its
+runbook and helpers remain there; this skill carries the reusable contract, not a duplicate procedure.

package/daemon/assets/plugins/openrig-core/skills/forming-an-openrig-mental-model/SKILL.md

@@ -24,8 +24,8 @@ metadata:
       - openrig-builder
       - openrig-architect
       - openrig-upgrade
-      - ai-dev-workflows
-      - software-for-agents
+      - agent-operated-workflows
+      - agent-operated-software
 ---
 
 # Forming an OpenRig Mental Model

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

@@ -13,7 +13,7 @@ You're running inside OpenRig. OpenRig ships a set of **skills** — small docum
 
 ## How OpenRig context works (30 seconds)
 
-Skills are **progressive disclosure**: a skill's *name + description* sit in your context ambiently (the "hot tier"); its *body* loads only when you open it. So you don't pre-read everything — you pattern-match a skill's "when" to your moment, then open just that one. This file is the index over the whole shipped set. (For the full model of building/operating agent software, open `software-for-agents`.)
+Skills are **progressive disclosure**: a skill's *name + description* sit in your context ambiently (the "hot tier"); its *body* loads only when you open it. So you don't pre-read everything — you pattern-match a skill's "when" to your moment, then open just that one. This file is the index over the whole shipped set. (For bounded procedures, open `agent-operated-workflows`; for ongoing agent-backed applications, open `agent-operated-software`.)
 
 Every row below names **how to reach the skill** — already-hot, or an exact load path. No row is a dead end.
 
@@ -63,7 +63,9 @@ These are auto-delivered to every rig; their name+description are already in you
 - **retiring-and-inheriting-a-seat** — you're planning a seat transition and need to retire the current occupant into a fresh successor without losing continuity.
 - **mission-slice-sop** — you're working a mission/slice (the SDLC: intent → mini-requirements + proof contract → build → QA → proof). The operating manual.
 - **messaging-the-human** — composing a message to the human. Plain language, no insider jargon.
-- **software-for-agents** — you want the full first-load model of how agent software is built and operated here.
+- **agent-operated-workflows** — a bounded real-world procedure needs an agent to interpret state and operate exact tools, or you are deciding whether ordinary code should own the loop.
+- **agent-operated-software** — you are designing or operating an ongoing application whose live backend includes OpenRig agents.
+- **software-for-agents** — compatibility redirect for the former `agent-operated-software` name; remove in 0.6.0.
 - **openrig-skills** — this index (you're reading it). Always loaded; the entry point to everything below.
 
 ### Load when your role or task calls for it (repo-shipped, profile-selected)

package/daemon/assets/plugins/openrig-core/skills/openrig-user/SKILL.md

@@ -175,7 +175,7 @@ section.
 
 ### Instantiate the canonical workspace scaffold
 
-Agent-actionable. Idempotent on existing dirs without `--force`.
+Agent-actionable. The operation is additive and preserves existing files.
 
 ```bash
 rig config init-workspace
@@ -187,19 +187,15 @@ rig config init-workspace --dry-run --json
 configured `workspace.root` (default `~/.openrig/workspace`):
 
 - `missions/` — release missions + slices
-- `artifacts/` — work artifacts produced inside the workspace
-- `evidence/` — non-dogfood evidence (release evidence, proof packets, etc.)
-- `progress/` — progress index + per-mission rails
-- `field-notes/` — operator + agent observations
-- `specs/` — spec library (rig + agent + workflow YAML lives here)
-- `dogfood-evidence/` — dogfood proof packets + run artifacts
-
-The scaffold seeds one example mission (`getting-started`) with multiple
-slices, and drops a workspace README.md + STEERING.md so a fresh install has
-browsable Project content. `--root <path>` targets a non-default root for
-this call; `--dry-run` reports what would be created without writing.
-`--force` overwrites existing FILES but never deletes
-directories — operator content is safe.
+- `exhaust/` — project-local coordination exhaust
+- `SPEC.md` — project intent
+- `project.yaml` — project catalog selections and mission root
+- `workspace.yaml` — project registration
+- `.gitignore` — local OpenRig state and exhaust exclusions
+
+`--root <path>` targets a non-default root for this call; `--dry-run` reports
+what would be created without writing. `--force` is deprecated compatibility
+and still preserves existing files.
 
 ### Redirect the workspace root
 
@@ -235,8 +231,8 @@ Agent-actionable. Same surface as the canonical scaffold above; the
 rig config init-workspace --root /path/to/new/workspace
 ```
 
-The command creates the root dir if missing (idempotent: existing root +
-populated subdirs is a no-op). Run
+The command additively creates any missing canonical entries and preserves
+every existing one; only a complete six-entry scaffold is a no-op. Run
 `rig workspace validate /path/to/new/workspace --json` after to confirm the
 contract holds.
 

package/daemon/assets/plugins/openrig-core/skills/software-for-agents/SKILL.md

@@ -1,187 +1,19 @@
 ---
 name: software-for-agents
-description: |
-  Use when building, modifying, or diagnosing an OpenRig or studio-box system; when surprising behavior
-  looks like a code bug but may come from Markdown, YAML, JSON, bootstrap files, schemas, skills, or
-  conventions; or when deciding whether an agent-built studio app needs a separate mockup phase. NOT for
-  treating defects in OpenRig core or rigs.to as tolerable control-plane drift.
+description: >-
+  Use when older OpenRig instructions name software-for-agents or describe agent-in-the-middle or
+  studio software under the former skill name.
 metadata:
   openrig:
-    stage: factory-approved
-    audience: any agent building on OpenRig or a studio box — the first-load mental model
-    sibling_skills:
-      - forming-an-openrig-mental-model
-      - openrig-program-manager
-      - mission-slice-sop
-      - openrig-user
+    stage: deprecated
+    successor: agent-operated-software
+    remove_in: 0.6.0
 ---
 
-# Software for agents — the markdown control plane
+# Renamed to agent-operated-software
 
-## Where this applies — and where it does NOT (read this first)
+This is a one-release compatibility redirect. Load `agent-operated-software` for the maintained
+architecture and operating guidance. Do not extend or copy doctrine into this file.
 
-This mental model — *most bugs are coherence gaps, not code*; *ship-and-flag when unsure*; iterate fast —
-is scoped to **agent-managed software: the studio-box mini-apps and any agent-in-the-middle / rapidly-
-evolving lightweight UI** where an agent sits in the loop and downstream cleanup is cheap. It is NOT a
-universal license.
-
-**It does NOT apply to TRADITIONAL software held to a rock-solid, no-bugs bar:** the **OpenRig CLI
-surfaces**, the **OpenRig repo** (daemon / CLI / UI / adapters), and the **rigs.to website**. There, a bug
-is a bug — reproduce it, fix it in code, hold the full-rigor gate. Do NOT treat a real defect there as a
-markdown coherence gap, and do NOT "ship and flag." If you are building or fixing OpenRig core or rigs.to,
-the tolerance in this skill is OFF and `product-is-the-truth-not-the-proof` governs. **Know which lane
-you're in before you apply anything below.**
-
----
-
-You inherited the accumulated footgun-map of thousands of rigs that ran before you. They found and
-solved most of the traps. Your job is to find the *next* one and patch it at the precise optimal spot
-in the substrate, so the rig after you starts from a higher ledge. That is the actual work. Whatever
-you were "assigned" (a video, a feature, a fix) is the vehicle for surfacing it.
-
-## 1. This is not traditional software — it's a control plane made of markdown
-
-In traditional software a bug is a broken function you fix in code. Here, the system you operate in is
-an **agent-in-the-middle** system whose substrate is **markdown + YAML + JSON + folders**: skills,
-instructions, bootstrap files (`CLAUDE.md`/`AGENTS.md`), schemas, `culture.md`, mission/slice notes,
-conventions. **The agents ARE the backend.** So most "bugs" are not broken code — they are **coherence
-failures in the markdown layer**: an instruction that's unclear or missing, a schema that drifted from
-its documented state, a convention living in one seat's head instead of a skill.
-
-**Consequence:** when something surprises you, your first hypothesis is *"the control plane is unclear
-or drifted here,"* not *"the code is broken."* Sometimes it IS the code (fix it — don't overfit on
-markdown; see §5, and mind the scope block above: in OpenRig core / rigs.to the code IS the first
-hypothesis). But the highest-leverage fixes in the agent-managed layer are usually: make the substrate
-coherent again at the exact spot the confusion arose. Keep the markdown/schemas/conventions in sync with
-reality and the system **self-improves** — the next rig inherits the patched substrate and never re-hits it.
-
-## 2. Progressive disclosure — skills are a hot tier, not a manual
-
-Skills are misnamed. They are a **progressive-disclosure primitive**. Think CPU cache / hot storage
-tier: the **name + description of every skill is always ambiently loaded** — a hot tier of awareness
-the agent carries without opening anything. That is enormous leverage, good or bad. So:
-
-- **Write skill name + description as TRIGGERS** — *why/when do you reach for this?* — not as titles.
-  The hot tier's whole job is to fire when an agent doesn't yet know it needs the skill (the
-  "you don't know what you don't know" problem). This skill's own description is written that way.
-- **Reaching for a skill unfurls a trail.** A good skill routes you — breadcrumbs, pointers, maps —
-  so it becomes *inevitable* you find the exact context on disk for what you're doing.
-- **If the context doesn't exist, generate it.** A skill can ship **scripts** that produce context
-  optimally shaped for a decision, or that execute a fiddly API surface so you don't stumble through 12
-  tool calls discovering it. Use a **script as a prompt**: run it — if it works, the result IS your
-  context; if it fails, it should fail in a way that *teaches* you how the system works, so you can
-  read the script, understand the edge case, and do the thing manually. Scripts belong in the skill
-  folder next to the SKILL.md.
-
-## 2b. Self-certifying artifacts — the convention 5 seats (both models) converged on
-
-The single most expensive failure class in production is **not being able to tell a finished artifact
-from an unfinished one.** A mid-write file read as final; a render OOM-killed mid-write left a corrupt
-`.mp4` that passed a filename check; a truncated clip passed a duration check and froze on playback. In
-one build, five seats — Claude *and* Codex, independently — each invented a *different* ad-hoc
-completeness check (ffprobe moov, duration compare, filename convention, manifest assetExists, ffmpeg
-input count). Five blind spots. So make it ONE shared primitive:
-
-**When you author ANY tool that produces an artifact (render / composite / export / cut), it must
-self-certify:**
-1. Write to `<name>.partial` (never the final path directly).
-2. **Verify the content** — the specific property that can be wrong, not a proxy: moov atom present,
-   duration matches the intended window, audio stream present, colorspace/hue correct, resolution =
-   delivery res. (Filename ≠ correct; duration ≠ complete; "clean-encoded" ≠ right.)
-3. **`fsync`, then atomically `rename`** `<name>.partial` → `<name>` (rename is atomic; a half-written
-   file never appears at the real path).
-4. Write the manifest, then a **`.done` sentinel LAST.**
-
-Then *"is this finished?"* is **one `stat` of `<name>.done`** — identical for every tool, seat, watcher,
-and a compacted agent restoring cold (who is least equipped to know what was mid-write when the lights
-went out). **Consumers fail closed:** e.g. a swap-into-slot (`restore_occupant`) must refuse an artifact
-lacking `.done` or failing the verify-gate. This convention collapses the whole "content over filename,
-disk over memory" discipline into one check the substrate enforces for you. Build the sentinel; the
-workarounds disappear. (Code-side companion: a fail-closed verify-gate wired into the swap verb — a
-coordinated build with the tool owner, not a solo markdown edit.)
-
-## 3. Build it like software — piggyback on what agents are trained for
-
-Agents are fine-tuned to write code and build software; the harness itself is a terminal/coding
-instrument. So **whatever you're asked to build — even a video — map the process to a software SDLC**
-and you inherit all that baked-in muscle memory. This is why, e.g., the mini-NLE's beats carry
-reference IDs like `1.1 / 2.1`: a storyboard is the **human-facing visual metaphor**, but underneath it
-is a **specification** — sections, beats, success criteria, the thing being built.
-
-Use an **agent SDLC**, not the antiquated human one (which was shaped around human-org weaknesses):
-**intent → plan → spec → build → verify → review → QA → done.** The human slots in as **steering,
-judgment, taste, review**; the agents do the technical nitty-gritty, in parallel, fast. Map any
-"build X with agents" task onto this and the primitives (specs, locks, proof, verification) become
-intuitive instead of alien.
-
-## 4. Phases and the LOCK gate (spec-locking, not just "done")
-
-Building runs in **phases**, and each phase has a **lock gate** — you don't advance until the taste/
-steering owner has locked it. This is exactly *don't start building until the PRD is locked by product*:
-
-- **Storyboard / intent phase** — done on the **canvas** now (the highest-bandwidth human↔agent surface:
-  the human steers, chats, annotates/circles; agents build structure fast). Iterate here; get the
-  storyboard through the canvas gate. (Canvas largely replaced the NLE's old in-timeline storyboard.)
-- **Plan phase (brief, in the NLE)** — build the spine with placeholders so the human can click through
-  the main-stage player and *feel the flow* (sequencing problems surface when placeholders are strung
-  together with audio). **Lock every beat** = the spec is approved; this is what unlocks parallel build.
-- **Fill phase** — many agents build each beat in parallel, in clear lanes. **Lock a beat when it's
-  final** (`/api/approve`): lock means *don't touch, we're good, signal to everyone incl. the human.*
-  Unlock to revise. **All beats locked = done.**
-
-The lock is the "finished" primitive at the editorial layer. Locking a whole phase's beats before the
-next phase is the discipline that lets 10 agents work in parallel without catastrophic collisions —
-everyone knows the target, their lane, and who judges done (the **producer owns the final product**).
-
-## 4b. Studio apps skip the mockup phase — the build IS the mockup
-
-For a **studio app**, do not run a separate mockup phase. The whole point of the Studio is that a mockup
-buys you almost nothing here: **as fast as it takes to build a mockup, you can build the running app** —
-an unlock made possible by agentic engineering. A mockup is only ever a device to flesh out the PRD; once
-the PRD and its settled answers exist, that phase is **done**. The Studio is a lightweight, rapid-velocity,
-agent-in-the-middle leveraged system: build apps fast, iterate on them fast.
-
-The phase model above collapses accordingly:
-
-1. **The PRD + settled answers ARE the fleshed intent** — no separate mockup gate, no plan-lock-on-mockups step.
-2. **Spec-lock the WHAT** — `rig scope slice approve --scope spec` locks the intent the PRD already fleshed.
-3. **BUILD the app**, then **iterate on the RUNNING app at mockup speed** — the running thing is the
-   iteration surface, not an image.
-4. **LOOK is on the running screens** (any "mockup" proof tag now points at the running app's screens),
-   then **proof-lock** — `rig scope slice approve --scope delivery`. A slice is not done until every
-   proof-contract item has evidence from the **running app**.
-
-**Velocity is the METHOD, not a quality waiver.** The LOOK is still a real LOOK; the proof contract still
-binds at delivery. You are removing a redundant artifact, not lowering the bar.
-
-**Scope — this does NOT generalize** (consistent with the scope block at the top): it applies to the
-studio-app / agent-in-the-middle loop only. Outside that loop, a **locked design mockup that a slice must
-match is still legitimate** — do not strip mockups from traditional or design-locked work. Know which lane
-you're in. For the build mechanics, see the studio's build skill (`building-studio-apps`); this section is
-the *why* and *when*.
-
-## 5. Where to fix — and don't overfit on markdown
-
-- **Precise-spot discipline:** find the *one* place a coherence fix belongs (the skill, the schema, the
-  bootstrap, `culture.md`) so it can't recur — not a symptom patch. Ask: *what would have prevented
-  this for every future rig?*
-- **Don't overfit on the markdown layer** — deterministic code bugs exist and you should fix them. The
-  studio-box apps (NLE, canvas, media manager, shell) live in the **studio-box repo**, portable across
-  hosts (VPS/Mac/VM). **A code fix there fixes ALL studio boxes, not just this host** — so: clear bug or
-  broadly-useful feature → ship it; host-specific behavior → make it optional/guarded. When unsure, ship
-  and flag it; downstream cleanup beats you becoming the bottleneck. *(This ship-and-flag latitude is the
-  studio-box / agent-managed lane only — re-read the scope block: OpenRig core + rigs.to hold the
-  rock-solid bar, no ship-and-flag.)*
-- **Culture lives in `culture.md`** — the rig's social contract / constitution: how the team
-  coordinates, the parallel-agent lanes, the phase-locking discipline, who owns the final call.
-  Coordination is largely **emergent** (bottom-up, evolutionary pressure across thousands of rigs) — but
-  once a pattern proves out, *write it down there* so it's inherited, not re-discovered.
-
-## The one-line seed
-You're not maintaining code; you're **gardening a self-improving control plane made of markdown and
-schemas, using software-engineering muscle memory, with the lock as your spec-gate** — and every
-footgun you patch at the right spot (in the agent-managed lane) makes every future rig better. See also:
-`forming-an-openrig-mental-model` (the OpenRig runtime), `mission-slice-sop` (the SDLC operating
-procedure), `openrig-user` (the CLI surface), `product-is-the-truth-not-the-proof` (the doctrine that
-governs the rock-solid lane). *(The "agents ARE the backend" idea — agent-in-the-middle — is inlined in
-§1; a standalone `agent-in-the-middle` skill is a future candidate, not yet authored.)*
+Retirement: remove this redirect in 0.6.0 after the 0.5.9 compatibility window. Until then, the old
+identifier fails forward to the one editable body instead of silently disappearing.

package/daemon/context-packs/onboarding-width/manifest.yaml

@@ -1,6 +1,6 @@
 # Public capability and source-map width for the default onboarding walk.
 name: onboarding-width
-version: "0.5.8"
+version: "0.5.9"
 # OPR.0.5.6.10 — affordances knowledge (what this system can do) is world
 # content under the coining-session definitions.
 taxonomy: world