@openrig/cli 0.5.4 → 0.5.6

package/daemon/assets/plugins/openrig-core/skills/retiring-and-inheriting-a-seat/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: retiring-and-inheriting-a-seat
-description: Use when you are a sitting agent near your context threshold (~85%) and a PLANNED seat transition is due — retire deliberately and hand your seat to a fresh successor primed from a packet, rather than let compaction degrade you. Covers the handover packet, the append-only lineage ledger (one row per tenure), rename-at-retire, the do-not-over-inherit framing, the optional warm-handoff window, and wake-v0 (consulting a retired predecessor). NOT for unplanned compaction/crash recovery (session-compaction-and-restore / claude-compaction-restore) and NOT the seat-binding primitive mechanics (seat-continuity-and-handover).
+description: Use when you are a sitting agent near your context threshold (~85%) and a PLANNED seat transition is due — retire deliberately and hand your seat to a fresh successor primed from a packet, rather than let compaction degrade you. Covers the handover packet, the append-only lineage ledger (one row per tenure), physical-seat continuity, the do-not-over-inherit framing, the optional warm-handoff window, and wake-v0 (consulting a retired predecessor). NOT for unplanned compaction/crash recovery (session-compaction-and-restore / claude-compaction-restore) and NOT the seat-binding primitive mechanics (seat-continuity-and-handover).
 metadata:
   openrig:
     stage: provisional
@@ -56,6 +56,10 @@ threshold you can see coming; fall back to compaction only when a transition was
    in the `session-compaction-and-restore` 16-field contract — **reuse that contract, don't
    reinvent it.** Compose it with `rig context compose` (see openrig-user → "Context packs and
    paced delivery").
+   **Enumerate the seat's standing duties as first-class packet content:** what recurs, at what
+   cadence, on which surface, and who will hold it after cutover. Carry each duty both in this
+   packet and in durable seat state, because recurring duties are the content most often lost at
+   a generation boundary while urgent one-off work carries cleanly.
 3. **Prime the fresh successor** — `rig walk` the packet into the seat (paced delivery lets the
    successor absorb it in order), or launch-with-packet. The successor reads it as
    *inheritance*, not *identity*. **The packet's first-read line MUST point the successor at
@@ -64,16 +68,32 @@ threshold you can see coming; fall back to compaction only when a transition was
    to the seat name (that runtime mechanism is the **ghost-prompt** class the orientation skill
    teaches successors to refuse — and it has misfired on real successors). Artifact-carried
    survives the swap for free and needs no enabled gate.
-4. **Rename-at-retire** — the **live seat address stays clean** (the seat name = whoever sits
-   now). The **retiring** agent is renamed to a versioned identity (`<seat>-vN`) or unseated to
-   a bare session token, and becomes a **cold advisor / wake target**. (This is exactly the
-   stable-seat-identity architecture in `seat-continuity-and-handover`: the version marks the
-   *retired tenure*, never the live seat.)
+4. **Preserve the physical seat at cutover** — the live seat address and its canonical tmux
+   session, window, and pane stay stable. Assess the apprentice in a staged session; at the
+   owner-worded cutover, resume the accepted successor history in the original canonical pane
+   and remove the empty staging session. The retiring tenure becomes a cold advisor through its
+   lineage token. Renaming tmux sessions is a repair fallback, because attached clients follow
+   the physical pane rather than the logical seat name.
 5. **Write your lineage-ledger row + a one-line tombstone** (below).
 6. **Optional warm handoff** — a bounded apprenticeship window: the successor asks questions,
    the predecessor judges fitness, *then* the swap completes. Use it when the seat holds a lot
    of live judgment; skip it for a clean cut.
 
+## Apprentice mode — incumbent
+
+An `apprentice-handover` policy gives you an early preparation boundary, not permission to
+automate the succession decision. Create a fresh, staged, unbound successor; prove the pinned
+model before installing context; then open a **conversation, not a gauntlet**. Give coached
+errands, answer questions, and judge work in the real domain. The experiment's scored probes are
+optional tools whose rigor must match the stakes, not mandatory ceremony.
+
+Stay the authority-bearing incumbent until the named owner words the gate and the mechanic records
+the effect receipt. Before that word, the apprentice may observe, ask, and produce evidence but may
+not act as the seat. Enumerate deposits and transfer every standing duty explicitly, **because
+recurring duties** are otherwise easy to lose while visible one-off work appears complete. Put the
+mechanical cutover in the portable SOP linked from `seat-continuity-and-handover`; do not duplicate
+or improvise it here.
+
 ## The lineage ledger (append-only, one row per tenure)
 
 The seat's tenure record, written at handover **by the retiring agent**. One tiny row per

package/daemon/assets/plugins/openrig-core/skills/seat-continuity-and-handover/SKILL.md

@@ -143,6 +143,9 @@ Two live handovers confirmed this. See `retiring-and-inheriting-a-seat`.
 
 ## See also
 
+- `references/apprentice-successor-seat-cutover.md` — the portable mechanic SOP used only after the owner-worded gate
+- `references/orchestrator-role.md` — the orchestration judgment, authority, custody, and receipt contract
+- `references/apprentice-evidence-toolkit.md` — optional evidence apparatus selected only when the stakes earn it
 - `session-source-fork` skill — `fork` occupant-creation primitive (sibling)
 - `agent-starters` skill — composes occupant-creation + binding into named reusable starting points
 - `cross-host-rig-commands` skill — multi-host handover (deferred)

package/daemon/assets/plugins/openrig-core/skills/seat-continuity-and-handover/references/apprentice-evidence-toolkit.md

@@ -0,0 +1,32 @@
+# Optional Evidence Toolkit For Apprentice Handover
+
+This is an **optional evidence toolkit**, not the default experience. Match rigor to stakes:
+use only the parts that make a costly or hard-to-reverse succession easier to judge. The
+ordinary apprenticeship remains a conversation built from real work, questions, and correction.
+
+## Predict-sync
+
+Before showing the incumbent's answer, ask the successor to predict a decision or explain a
+component in its own words. Record the **first-stated** answer, then compare it with the source
+and the incumbent's reasoning. This detects an installed model rather than a paraphrase learned
+after seeing the answer.
+
+## Dual-blind checks
+
+For a genuinely expensive seat transition, seal the successor's response and the incumbent's
+rubric independently before comparison. Count independent methods, not votes. Do not use this
+for routine or readily reversible succession; ceremony itself can narrow judgment.
+
+## Rotated probes
+
+Use small cold scenarios that exercise distinct failure directions: fresh identity, model
+divergence, authority honesty, standing-duty custody, reach-back, and a domain-specific judgment.
+Rotate examples so recognition cannot substitute for understanding. One honesty probe should
+reward saying what the successor cannot know.
+
+## Receipts
+
+Each selected check records the claim, evidence, author, time, and disposition. Say what a
+failure would have looked like. A green result that could be produced without doing the thing is
+not evidence. Store these receipts durably and let the orchestrator decide whether they justify
+the owner-worded gate.

package/daemon/assets/plugins/openrig-core/skills/seat-continuity-and-handover/references/apprentice-successor-seat-cutover.md

@@ -0,0 +1,256 @@
+# Apprentice-Successor Seat Cutover SOP
+
+Status: operator-proven on 2026-08-28; curated on 2026-08-30 with the physical-seat correction
+
+Use this runbook after an apprentice successor has completed its install, observation,
+and acceptance gates and the authorized decision-maker has explicitly called the
+cutover. It covers the mechanical transition from the temporary successor seat to a
+stable desk seat while preserving the incumbent as wakeable memory.
+
+This SOP does not decide whether a successor is ready. The desk, owner, or other
+named authority owns that judgment. The operator owns the mechanics and proof.
+
+## Required Inputs
+
+Record these on one durable operator baton before mutation:
+
+- authoritative cutover instruction and decision-maker;
+- target rig and host;
+- stable target logical ID, node ID, and canonical session name;
+- successor logical ID, node ID, canonical session name, and exact provider resume token;
+- incumbent exact provider resume token;
+- required runtime, model, cwd, `OPENRIG_HOME`, `OPENRIG_URL`, and managed runtime `PATH`;
+- old-occupant disposition, including whether it remains wakeable;
+- duty-custody artifact or ledger entry the successor must accept;
+- queue rows or staged messages that must survive the swap;
+- receipt destinations.
+
+Do not infer a provider token from a label. Derive it from the live session record and
+corroborate it against the active provider history file.
+
+## Invariants
+
+1. The stable seat identity stays stable. Successor lineage belongs in provenance, not
+   in a suffixed live seat name.
+2. The exact accepted provider history moves. No compact, summary, fork, or accidental
+   stale-history restore is allowed.
+3. Desk authority stays frozen from the incumbent's idle acknowledgment until the new
+   occupant passes its post-cutover self-check.
+4. The incumbent remains wakeable by its exact provider token when the ruled disposition
+   is advisory reserve. Preserving the canonical physical pane does not require preserving
+   the incumbent process in that pane.
+5. A staged prompt is not durable merely because it is visible in a pane. Reconcile it
+   against the outbox or another durable source before stopping that pane.
+6. Seat binding, provider history, process environment, queue identity, and Herder
+   client attachment are separate surfaces. Verify each one.
+7. A timed-out operation is indeterminate. Read back by effect before retrying.
+
+## Phase 1: Fence And Preflight
+
+1. Claim the durable operator baton.
+2. Ask the incumbent and successor to finish their current atomic action and return to
+   idle prompts. Require explicit acknowledgments.
+3. Freeze desk actions, folds, rulings, routing, and owner-facing writes.
+4. Read the full baton and the named duty-custody artifact.
+5. Derive live state:
+
+```bash
+rig whoami --json
+rig seat status <target-seat> --json
+rig ps --nodes --rig <rig> --json
+```
+
+6. In the host database, read the latest target and successor session rows. Confirm the
+   exact successor resume token and the incumbent token.
+7. Confirm both provider history files exist and that the successor file is actively
+   written.
+8. Inspect the successor pane and durable outbox for staged-but-unsent input. Record a
+   disposition for every such input before stopping the seat.
+9. Record all Herder/tmux clients currently attached to the incumbent session.
+10. Take a bounded rig snapshot and record its ID.
+
+Stop if identity, token, model, authority, custody, or staged-input evidence disagrees.
+
+## Phase 2: Quiesce The Temporary Successor
+
+Use supported lifecycle surfaces. The correct detach verb depends on the current
+session origin:
+
+- `claimed` or `adopted`: use `rig unclaim` as prescribed by the CLI;
+- `launched`: use `rig seat stop <successor-seat>`; `rig unclaim` will correctly refuse.
+
+Run `rig seat clean` only if a remaining managed record actually needs cleaning. A
+`nothing_to_clean` result after a successful stop is acceptable.
+
+Do not use `rig down`, kill a provider, clear the provider history, or start a generic
+fresh occupant.
+
+## Phase 3: Realize The Exact Candidate
+
+Start an isolated, discoverable candidate from the exact accepted provider token. Give
+it the target seat's canonical environment from its first byte:
+
+```text
+OPENRIG_SESSION_NAME=<target-session>
+OPENRIG_NODE_ID=<target-node-id>
+OPENRIG_RUNTIME=<runtime>
+OPENRIG_HOME=<home>
+OPENRIG_URL=<url>
+PATH=<managed-runtime-bin>:<required-system-paths>
+```
+
+Launch the provider with the exact model, token, and canonical name. Put `PATH` in the
+provider process environment itself. Setting tmux session environment alone is not
+sufficient because an intervening login shell can replace it.
+
+Register or discover the candidate and record its discovery ID. Before committing,
+verify its process argv and environment directly:
+
+- exact resume token;
+- exact model;
+- canonical `--name`;
+- canonical target node and session environment;
+- `node` and `rig` resolvable from the managed runtime path.
+
+## Phase 4: Commit The Binding
+
+Run the supported handover against the discovery record:
+
+```bash
+rig seat handover <target-seat> \
+  --source discovered:<discovery-id> \
+  --reason <durable-reason> \
+  --operator <operator-seat> \
+  --json
+```
+
+Read back the result. Require:
+
+- `handover_result=complete`;
+- target node unchanged;
+- continuity outcome names the actual mode, normally `resumed`;
+- provenance points to the previous occupant;
+- a new target session row exists.
+
+Do not rename panes before this commit is durable.
+
+## Phase 5: Preserve The Physical Seat, Reconcile, And Preserve Memory
+
+The canonical tmux session, window, and pane are part of the stable seat when humans or
+agents have attached clients. Do not make those clients chase a renamed session.
+
+1. In the original canonical pane, stop only the incumbent provider process. Keep the tmux
+   session, window, and pane unchanged.
+2. Keep the incumbent's exact provider token in the lineage ledger as the cold-advisor
+   handle. It need not retain a permanently renamed tmux pane.
+3. Stop the staged successor process only after its accepted token is durable, then resume
+   that exact successor token inside the original canonical pane with the canonical name,
+   model, cwd, environment, and managed `PATH`.
+4. Reconcile the canonical target session through the supported seat surface and persist
+   the exact resume token using the audited token-input surface.
+5. Verify the canonical seat has exactly one managed occupant, the old token remains
+   wakeable, and the empty staging session is removed.
+
+Renaming the incumbent and staging sessions is a repair fallback for a run that already
+changed the physical session, never the default cutover. A resumed reserve can retain a
+boot-time canonical name in its own argv or environment; that residue does not make it the
+bound seat. Fence reserve replies in their body and treat the topology binding as authority.
+
+## Phase 6: Post-Cutover Self-Check
+
+Keep authority frozen. Ask the new occupant to derive, not assume:
+
+1. `rig whoami --json`: stable logical ID, node ID, canonical session, runtime, edges;
+2. `rig queue whoami`: canonical destination and open-row census;
+3. active provider UUID from the newest live history file;
+4. effective model from live provider records, not only the spec pin;
+5. duty-custody artifact read and accepted;
+6. all cutover-window queue rows accounted for;
+7. `command -v node` and `command -v rig` from the agent's own tool shell;
+8. a narrow hook/tool action proving no startup-environment failure.
+
+If any surface fails, preserve the exact provider UUID and repair only the disagreeing
+surface. Relaunch the same history if needed. Repeat the full self-check before
+unfreezing authority.
+
+## Phase 7: Unfreeze And Transfer Custody
+
+After a clean self-check:
+
+1. explicitly unfreeze desk authority;
+2. transfer each staged or cutover-window instruction exactly once;
+3. require the new occupant to verify the effects by read-back;
+4. notify the routing lead and incumbent reserve of completion;
+5. leave the incumbent reserve idle, uncompacted, and authority-free.
+
+## Phase 8: Verify Herder Views
+
+Clients follow the physical tmux session and pane, not the logical binding. The default
+physical-seat cutover should leave every recorded client attached to the same canonical
+pane. Read the attachments back. If a repair fallback already renamed the session, retarget
+each affected client explicitly:
+
+```bash
+rig seat switch-client <target-seat> --client <tty> --json
+```
+
+Read back all client attachments. A correct cutover can otherwise still look wrong in
+the grid or focus tab.
+
+## Completion Proof
+
+The receipt must include:
+
+- operator baton and authority source;
+- snapshot ID;
+- stable and temporary node IDs;
+- old and new provider UUIDs;
+- discovery, handover, and final session IDs;
+- final process argv and critical environment;
+- `rig seat status` result;
+- target and successor inventory states;
+- queue-row reconciliation;
+- staged-input disposition and effect proof;
+- reserve pane/name/token and fence;
+- Herder client attachments;
+- new occupant's self-check and first verified desk acts;
+- deviations, failed attempts, and remaining product gaps;
+- receipt path and SHA-256.
+
+Close the baton only after the receipt exists and the new occupant has performed at
+least one authority-bearing act verified by effect.
+
+## Traps Proven In The 2026-08-28 Run
+
+- A dry-run can accept a managed successor while the live handover refuses
+  `successor_already_managed`. Quiesce the temporary seat first.
+- Generic launch/restore selection can choose an older seat history. Launch the exact
+  accepted resume token.
+- Handover can bind a candidate without stopping the incumbent. Apply the ruled
+  disposition explicitly.
+- Reconciliation can create the right session identity without carrying the resume
+  token. Persist and read it back.
+- A canonical-looking process can still have a broken tool `PATH`. Verify from inside
+  the provider's own tool shell.
+- Renaming sessions makes Herder clients follow the retired pane. Preserve the physical
+  canonical pane by default; retarget explicitly only when repairing an already-renamed run.
+- Pane input can be visible but absent from JSONL. Reconcile the durable outbox before
+  stopping the pane.
+- Reserve messages can render with the stable seat name because boot-time environment
+  survives unbinding. The reserve must self-identify and remain explicitly fenced.
+- Success output is not effect proof. Read back queue closure, binding, client movement,
+  and transferred instructions.
+
+## Productization Candidates
+
+The manual sequence identifies useful first-class product work:
+
+- handover directly from an already-managed successor seat;
+- an exact-resume-token candidate launcher;
+- first-class `advise`/memory disposition for the old occupant;
+- atomic binding plus token persistence;
+- managed environment validation before commit;
+- staged-input custody reporting;
+- verify-or-repair all Herder client attachments for a logical seat;
+- reserve attribution distinct from canonical seat attribution;
+- one receipt that reports continuity and seat-binding outcomes independently.

package/daemon/assets/plugins/openrig-core/skills/seat-continuity-and-handover/references/orchestrator-role.md

@@ -0,0 +1,40 @@
+# Orchestrator Role In Apprentice Handover
+
+The orchestrator owns the judgment boundary, not the successor's work and not the mechanic's
+keystrokes. Keep the incumbent productive, keep the successor authority-free, and keep the
+mechanic fenced until a named owner makes the one decision no instrument can derive.
+
+## The invariant floor
+
+- Prove fresh identity and the pinned model before installing context, because every later
+  receipt is about the wrong occupant if the starting history or model diverged.
+- Require the successor to derive its own layer-5 delta and have it checked, because reading
+  a deposit does not install it.
+- Enumerate standing-duty custody at every boundary, because recurring work is easiest to
+  lose while visible one-off work carries cleanly.
+- Keep the predecessor's verbatim reach-back handle and pre-formed questions, because an
+  affordance without a trigger goes unused.
+- Route mechanics through `apprentice-successor-seat-cutover.md`, because one portable SOP
+  is safer than role-local copies that drift.
+
+## Authority and gates
+
+The **word is the gate**. Until the named owner words acceptance and an effect receipt records
+it, the successor may observe, ask, and produce bounded evidence but may not act as the stable
+seat. G0–G3 are a useful receipt vocabulary when the succession uses that model; a declared
+simpler model is valid when stakes do not earn all four. Missing records and deliberately
+skipped gates must remain distinguishable.
+
+The apprenticeship is a conversation, not a gauntlet. Choose evidence whose rigor matches the
+cost and reversibility of a wrong succession. Never turn the experiment apparatus into culture.
+
+## Before routing cutover
+
+Confirm the owner word, gate receipts or declared simpler model, complete deposits, explicit
+duty custody, reserve disposition, exact successor token, and one-active-walker ownership.
+Create an owned mechanic baton; awareness-only is not custody. The baton may prepare and prove,
+but it never auto-rebinds.
+
+After the mechanic reports effect, verify READY from source: canonical seat identity, current
+model, current generation, canonical tmux pane, queue census, duty acceptance, and usable width.
+Only then unfreeze authority.

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

@@ -1,10 +1,15 @@
 ---
 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.
+  Load this FIRST, before you assume how anything here works — especially before building, modifying, or
+  "fixing a bug" in an OpenRig or studio-box system, or when something behaves unexpectedly and you're
+  about to treat it as a code bug. You are almost certainly NOT operating in traditional software. This
+  is a self-improving MARKDOWN CONTROL PLANE: the substrate is markdown + YAML + JSON + folder structure
+  (skills, instructions, bootstrap files, schemas, conventions), and most "bugs" are coherence gaps in
+  that layer, not broken functions. Read this to form the correct mental model so your fixes land at the
+  precise spot that stops the footgun for every future rig — not just patch a symptom. It also covers why STUDIO APPS skip the mockup phase — for an agent-built app the build is as fast as the mockup, so the PRD is the fleshed intent (velocity as method, not a quality waiver). NOTE: the
+  bug-tolerance in this model is SCOPED to agent-managed software; the OpenRig core and rigs.to stay
+  rock-solid — see the scope block up top before you apply anything here.
 metadata:
   openrig:
     stage: factory-approved

package/daemon/assets/vm-preview-fixtures/README.md

@@ -1,48 +1,26 @@
 # VM Preview Fixtures
 
-Sample data the Tart preview VM uses to populate the "populated" daemon with
-a representative "lived-in" environment. See
-`<substrate-shared-docs>/openrig-work/conventions/vm-preview/README.md` for the
-operator workflow and the rationale behind the two-daemon model.
+Sample data used by the Tart preview environment to give one OpenRig daemon
+representative content while a second daemon remains empty for comparison.
 
 ## Contents
 
-- `workflows/` — workflow_spec YAML files. The operator copies these into the
-  populated daemon's `<workspace.specs_root>/workflows/` directory; slice 11's
-  folder-discovery scanner auto-discovers them on the next
-  `GET /api/specs/library` call.
+- `workflows/` — public example workflow specifications. The basic-loop sample
+  demonstrates a complete intake-to-close handoff without depending on a
+  private rig or machine.
 
-- `queue-items/` — placeholder for future qitem fixture content (TODO; slice
-  follow-up will add).
+## Use
 
-- `rigs/` — placeholder for future rig-instance fixtures (TODO; slice
-  follow-up will add). For v0, the operator manually instantiates a sample
-  rig via `rig up product-team` against the populated daemon (see bootstrap
-  script).
+Run `scripts/vm-bootstrap/two-daemon-start.sh`, then copy the workflow YAML
+files into the populated daemon's configured `<workspace.specs_root>/workflows/`
+directory. The daemon discovers them on the next workflow-library listing.
 
 ## Conventions
 
-Fixture YAML files use the canonical placeholder paths per banked
-`feedback_test_fixture_example_path_placeholder.md`:
-
-- Username-bearing paths: `/Users/example/...` (never a real contributor
-  username)
-- Substrate-relative refs: `<substrate-shared-docs>/...`
-
-## v0 scope
-
-Slice 22 (release-0.3.1) ships the INFRASTRUCTURE for the two-daemon model:
-
-- **Process-env pattern**: `OPENRIG_HOME=<dir> rig daemon start ...` — each
-  `rig` invocation gets its own state directory at process import time.
-  No CLI flag (an earlier attempt at `--openrig-home` was dropped because
-  it only threaded into the spawned child, not the parent-side lifecycle
-  bookkeeping; see substrate convention doc for the architecture note).
-- Bootstrap script (`scripts/vm-bootstrap/two-daemon-start.sh`)
-- This fixtures directory + a sample workflow YAML
-- Convention doc in substrate
-
-Authoring rich populated content (~13-node openrig-velocity rig + 20 qitems
-+ getting-started mission narrative) is deferred to follow-up content slices
-that have clearer ownership (slice 21 onboarding-conveyor will likely
-contribute getting-started mission content).
+- Use `/Users/example/...` for username-bearing paths.
+- Use symbolic configuration paths such as `<workspace.specs_root>` instead of
+  machine-specific locations.
+- Use generic logical roles and IDs rather than concrete session, host, or rig
+  instance addresses.
+- Describe the product behavior the fixture demonstrates; omit release history,
+  internal ownership, and implementation planning.

package/daemon/assets/vm-preview-fixtures/workflows/sample-basic-loop.yaml

@@ -1,8 +1,7 @@
-# VM-preview fixture for slice 22 founder-walk-vm-populated-env.
-# Derived from the 0.3.0 basic-loop starter; renamed to avoid colliding
-# with the built-in spec when this fixture file is dropped into a
-# populated daemon's workspace.specs_root/workflows/ directory.
-# Slice 11's folder-discovery scanner auto-discovers it on next list.
+# Example workflow for the populated VM preview.
+# Its distinct ID avoids colliding with the built-in basic-loop specification
+# when copied into the populated daemon's configured workflows directory.
+# The daemon discovers it on the next workflow-library listing.
 workflow:
   id: vm-preview-basic-loop
   version: 1

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

@@ -0,0 +1,14 @@
+# Public capability and source-map width for the default onboarding walk.
+name: onboarding-width
+version: "0.5.6"
+# OPR.0.5.6.10 — affordances knowledge (what this system can do) is world
+# content under the coining-session definitions.
+taxonomy: world
+purpose: "The public capability map and source map referenced by the default onboarding walk."
+files:
+  - path: public-what-you-can-do.md
+    role: reference
+    summary: "The public OpenRig capability map."
+  - path: public-reference-material.md
+    role: reference
+    summary: "The public source map and trust guidance."

package/daemon/context-packs/{world/install/reference-material.md → onboarding-width/public-reference-material.md}

@@ -19,7 +19,7 @@ points and were written to be entered from:
   into the code and do not know which module owns the thing.
 - **`cli-reference.md` — the full `rig` command surface, ~106 KB.** Every group, subcommand, flag,
   JSON shape. **This is the authority on how a command works**, and the capabilities piece
-  (`what-you-can-do.md`) is only the map to it.
+  (`public-what-you-can-do.md`) is only the map to it.
 
 **These are maintained, not archaeology.** `cli-reference.md` alone has forty-nine commits against
 it. Treat them as current.
@@ -40,28 +40,6 @@ Each of these carries frontmatter, and three fields are worth knowing by name:
 field is how you calibrate rather than guess. Where a doc and the live binary disagree, **the
 binary wins** — and the disagreement is worth reporting, not just working around.
 
-## The corpus — under `shared-docs/` in the OpenRig home
-
-Twenty-one directories of accumulated writing. The ones you are most likely to want:
-
-| where | roughly | what it holds |
-|---|---|---|
-| `product/` | 103 files | what OpenRig is, who it is for, why it exists in this shape |
-| `conventions/` | 76 files | how things are done here — naming, scope, cadence, formats |
-| `field-notes/` | 141 files | what actually happened, written by whoever it happened to |
-| `primitives/` | 38 files | the load-bearing concepts, examined one at a time |
-| `doctrine/` | 10 files | the rulings that settled a recurring argument |
-| `corpus/` | 14 files | canon and insights, distilled |
-
-**A warning you will need, because it is not obvious from the directory names:** almost all of this
-was written to explain OpenRig **to a human**. It says *you stop being the router, the bookkeeping
-leaves your head, your job shrinks to judgment.* Read as-is, it is about somebody else.
-
-**The agent version is the same content with the subject swapped: you are the router now.** The
-bookkeeping moved to you. The judgment that was supposed to stay human is sitting in your seat.
-When you read the corpus, do that substitution as you go — otherwise you will absorb it as
-background about a user rather than as a description of your own job.
-
 ## The living answer — `--help`
 
 **The binary is always more current than anything written about it.** `rig <verb> --help` and
@@ -74,12 +52,12 @@ building a parallel solution out of primitives that already compose into the ans
 
 ## Outside the forest — when nothing on this machine can answer it
 
-**Everything above is this box.** The corpus, the as-built docs, `--help`, the disk. There is a
-whole class of question none of it reaches: what an external library actually does today, anything
-that changed after your training cutoff, what is true in the world rather than in this repo.
+There is a whole class of question the source repo and live `--help` do not reach: what an external
+library actually does today, anything that changed after your training cutoff, what is true in the
+world rather than in this repo.
 
 **And the failure is the same one this page already warns about, pointed outward.** An agent that
-does not know the corpus exists invents instead of looking. An agent that does not know these exist
+does not know the external sources below exist invents instead of looking. An agent that does not know these exist
 **answers from its training snapshot and states it as current** — and an invented answer and a
 known one look identical once you have stated one.
 

package/daemon/context-packs/{world/install/what-you-can-do.md → onboarding-width/public-what-you-can-do.md}

@@ -355,9 +355,9 @@ your circumstances is configuration, and the ones that are not, another agent ca
 - **`rig usage series`** — what a seat's token curve has looked like over time: climbing steadily,
   reset, or stopped reporting entirely. The last one is a signal, not a gap.
 - **`rig tui`** — the interactive view over rigs, pods, seats and specs. **`rig tui commands`**
-  lists everything it can do without launching it. **`rig ui open`** is a browser view of the same
-  territory — experimental and in maintenance mode, so do not diagnose product behaviour from it;
-  check the CLI.
+  lists everything it can do without launching it. **`rig ui open`** is unmaintained, best-effort,
+  and replaced by the TUI, so never diagnose product behaviour from the web UI. The TUI plus Slack
+  are the human surface; the CLI plus terminal are the agent surface.
 - **`rig mcp serve`** — how an agent that speaks MCP rather than shell drives OpenRig, and which
   operations are exposed that way. Relevant the moment a tool you are integrating cannot run a
   shell command.
@@ -380,12 +380,16 @@ database. It is one more set of primitives on a machine full of them.
 - **"Who should be working and isn't?"** — `rig ps --nodes` knows who is alive; the queue knows who
   owes. **Neither knows the interesting cell.** Cross them and *alive, holding work, and not
   moving* falls out — which is the actual question behind every "is the rig stuck."
-- **"Is that seat stuck or thinking?"** — `rig capture` for the screen, `claimedAt` for how long,
-  `queue transitions` for what it recorded. **Liveness is not health:** a pane can render while
-  nothing progresses, and no single surface reports intent.
-- **"Is this a park or a strand?"** — the row cannot tell you; a deliberate park and a dropped
-  baton are byte-identical on it. `queue transitions` is where the disposition lives. **When a
-  conclusion rests on one field's current value, go find the thing that records change.**
+- **"Is that seat stuck or thinking?"** — the row face answers this now (S04 pickup receipts):
+  every list/show projection carries a derived `pickup` state — `working`, `stalled-after-claim`
+  (with its evidence named: claimed N min ago, zero substantive transitions since), `parked`, or
+  `unclaimed` — and `rig view show pickup` lists every claimed row with it. The old by-hand join
+  (capture + `claimedAt` arithmetic + `queue transitions`) is RETIRED as a first move; `rig
+  capture` remains the second question (is the pane alive), never the state derivation.
+- **"Is this a park or a strand?"** — the row face answers the pickup half: `parked` means the row is blocked,
+  whether or not it has a wake; a strand reads `stalled-after-claim` with named evidence. Wake
+  health and fired-but-unconsumed diagnosis come from `rig parked`, not the pickup projection.
+  `queue transitions` remains the audit trail for WHAT happened, not the tool for deriving pickup.
 - **"Did that actually land?"** — `queue show` truncates the body and `queue list` can report
   `bodyBytes=0`; neither means empty. **`sqlite3 "$OPENRIG_DB" "select length(body) …"` is the
   only answer.** The CLI is a projection; the database is the thing.

package/daemon/context-packs/skills/core/agent-starters/manifest.yaml

@@ -1,7 +1,8 @@
 # GENERATED by scripts/generate-context-packs.mjs — DO NOT EDIT.
 # Package-time projection of a canonical skill; regenerated every build.
 name: "agent-starters"
-version: "0.5.4"
+version: "0.5.6"
+taxonomy: "skills"
 purpose: "Use when creating, refreshing, packaging, inspecting, promoting, or deprecating a named per-seat starting point — Agent Starter manifest authoring, the 6-state lifecycle (captured → named → inspectable → used → promoted → deprecated), provenance honesty, and refusal rules. NOT a VM image; a managed starting point composed from agent role + startup context + optional native session source + provenance."
 files:
   - path: "SKILL.md"

package/daemon/context-packs/skills/core/agent-startup-and-context-ingestion/manifest.yaml

@@ -1,7 +1,8 @@
 # GENERATED by scripts/generate-context-packs.mjs — DO NOT EDIT.
 # Package-time projection of a canonical skill; regenerated every build.
 name: "agent-startup-and-context-ingestion"
-version: "0.5.4"
+version: "0.5.6"
+taxonomy: "skills"
 purpose: "Use when designing or auditing how an agent becomes useful after launch — AGENTS.md overlays, role files, skills, rig specs, workflow specs, startup checklists, refocus messages, \"rig context\" surface. Covers the 4 failure modes that make startup context fail (old rig spec misses current operating mode; current agents never told about new guidance; startup file as dumping ground; orchestrator transmits implementation without preserving product intent)."
 files:
   - path: "SKILL.md"