@openrig/cli 0.5.9 → 0.5.11

package/daemon/context-packs/onboarding-width/public-reference-material.md

@@ -9,20 +9,20 @@ You do not need to read any of it now. You need to know it is there.
 
 ## The command surface — `docs/as-built/` in the source repo
 
-Eight documents sit directly in `docs/as-built/` in the source repo, and
-twenty-four files across `docs/` carry the same `kind: as-built` marker. Two of them are entry
-points and were written to be entered from:
+Use the source repository's `docs/as-built/` index and documents marked
+`kind: as-built`. Start with the entry point that matches your question:
 
 - **`README.md` — "Map of Territory + Module Index."** Start here when you do not know which
   document you want.
 - **`codemap.md` — "Navigation Index / Map of Territory."** Start here when you are about to go
   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,
+- **`cli-reference.md` — the `rig` command reference.** Every group, subcommand, flag,
   JSON shape. **This is the authority on how a command works**, and the capabilities piece
   (`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.
+Check the document's verification marker against the source you are using. A
+maintained document can still lag a changed command; its history is not proof
+of current behavior.
 
 ### The field that tells you how much to trust one
 
@@ -42,11 +42,11 @@ binary wins** — and the disagreement is worth reporting, not just working arou
 
 ## The living answer — `--help`
 
-**The binary is always more current than anything written about it.** `rig <verb> --help` and
+**Ask the binary you will actually run.** `rig <verb> --help` and
 `rig <verb> <subcommand> --help` are authoritative for shape, flags and defaults. This costs
 seconds and it is the single cheapest habit on this list.
 
-**And use it as a search, not just a lookup.** `rig --help` lists eighty-one top-level verbs. If
+**And use it as a search, not just a lookup.** `rig --help` lists the installed top-level commands. If
 you are about to build something, read that list first — the most expensive failure here is
 building a parallel solution out of primitives that already compose into the answer.
 
@@ -61,16 +61,12 @@ does not know the external sources below exist invents instead of looking. An ag
 **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.
 
-- **`context7`** — official documentation for a library, framework, SDK, API, CLI tool or cloud
-  service. **The moment: you are about to answer a question about any of those from memory.**
-  Reach for it even when you are confident, because confidence is exactly what a stale training
-  snapshot feels like. `resolve-library-id` first, then `query-docs`; it returns versioned library
-  IDs with a source-reputation and benchmark score, so you can see how good the coverage is before
-  you trust it.
-- **`exa` web search** — the general web. Describe the ideal *page*, not keywords: *"blog post
-  comparing X and Y performance"* beats *"X vs Y"*. It has an agent mode that does multi-step
-  research when one query will not do. `WebSearch` / `WebFetch` ship in the harness and do the
-  simpler version of the same job.
+Use the tools actually available in your harness. If a documentation connector
+such as `context7` is installed, use its current lookup interface to find the
+relevant library and version. If a web-search or fetch tool such as `exa` is
+available, use it to locate current primary sources. These tool names are
+examples, not a promise that your installation includes them. State any access
+or version limitation that affects the answer.
 
 ### The trust rule, and it is not the one these tools invite
 
@@ -78,18 +74,17 @@ known one look identical once you have stated one.
 to FIND; go to the primary source to CONFIRM anything load-bearing — the registry, the API, the
 repository, the running binary's `--help`.
 
-**Measured here 2026-08-18, and it inverts the intuition.** Asked for the current published version
-of a package, web search returned one page saying `0.5.0` (stamped "updated" two weeks earlier) and
-another saying `0.4.0`. The registry itself said `latest: 0.5.1` — and a four-day-old line in an
-agent's own memory index had been right all along. **The live-looking source was the stale one.**
-Web caches lag by an unknown and unstated amount, and nothing on the page tells you how much.
+Search indexes and caches can lag the source they describe. For a published
+package version, query the package registry; for an API contract, inspect the
+versioned provider documentation or implementation. An “updated” timestamp on
+a secondary page does not establish which source revision it reflects.
 
 So these extend your reach; they do not outrank a primary source, and *newer-looking* is not
 *newer*.
 
 ## The one you read rather than consult
 
-**`openrig-operating-model`** — a skill, ~23 KB. Everything else on this page you visit with a
+**`openrig-operating-model`** — the skill for context placement and chain walking. Everything else on this page you visit with a
 question already in hand. **That one you read through once**, because it is the shape the rest
 hangs on: the two trees, how context is arranged by altitude, and how a cold agent finds what it
 needs. Reading it is what stops you inventing an arrangement that already exists.

package/daemon/context-packs/onboarding-width/public-what-you-can-do.md

@@ -11,7 +11,7 @@ not know exists.** So the point of what follows is not skill. It is recognition:
 lands, something rhymes, and you go check instead of building.
 
 Eighty-one-plus top-level verbs ship (capability canon refreshed through
-`capability-delta-v0.5.9`). Read this once for shape, and let it make you suspicious that a thing
+`capability-delta-v0.5.11`). Read this once for shape, and let it make you suspicious that a thing
 already exists. Model-divergence proclamations are live product (trust them; pins use canonical
 model IDs).
 
@@ -46,6 +46,11 @@ one command away. Your memory of the fleet is a claim about the past.
   daemon behaviour. They are configuration. **Watch one thing:** `source: default` does not mean
   "the documented default" — it means *derived on this box*, and can resolve somewhere quite unlike
   the path in the help text.
+- **`rig health`** — inspect bounded, explainable findings for the current seat, one stable seat,
+  a rig, or the local instance; `rig health explain <finding-id>` shows the exact window, source,
+  freshness, rule, evidence, confidence, and next inspection. Use the TUI's HEALTH tab for the
+  same records when a human also needs to see them. Empty output is never a healthy assertion,
+  list/explain never mutate, and diagnostic presentation remains explicit opt-in policy.
 
 ## Reaching another agent
 
@@ -58,9 +63,10 @@ unseen — which makes messages the one delivery channel that never gets skipped
   consequential delivery gets an effect check at the far end rather than a blind retry. A
   producer-link advisory reading `no_activity_signal` means activity could not be determined;
   confirm by effect, never relaunch on it.
-- **`rig send --raw`** / **`--dangerously-interact --reason "<why>"`** — a seat is frozen on an
-  interactive prompt or a permission block. Normal `send` *refuses* to answer a prompt on purpose;
-  this is the deliberate override, and it is how you unblock a peer who cannot unblock itself.
+- **`rig send --raw`** — send exact text or keystrokes without the From/To envelope;
+  the interactive-prompt guard still applies. To deliberately drive an interactive prompt,
+  **`--dangerously-interact --reason "<why>"`** is the explicit override and implies raw text.
+  Inspect the prompt and establish authority for its effect before using that override.
 - **`rig broadcast`** — one fact to everyone at once, rather than relaying it N times and getting
   the wording wrong on the fourth. **Blast radius is real** — on a large rig this lands in every
   seat's turn.
@@ -83,14 +89,15 @@ unseen — which makes messages the one delivery channel that never gets skipped
   someone lists the stream before starting.
 - **`rig terminal open <view>`** — bring every live agent in a rig, mission or slice up as real
   typeable tiles at once.
-- **`rig walk <seat> --through <files> --pace <n>`** — deliver a *sequence* of context into a seat
-  one piece at a time, with a gap between pieces. **This is how you hand somebody a large amount of
-  material without dumping it**: absorption between pieces is the whole mechanism, and sending
-  faster than the receiver thinks merges everything into one turn and destroys it. It is also how
-  you were onboarded, and how you would onboard someone else.
-- **`rig slack`** — how something reaches a person who is not at a terminal, and how their reply
-  gets back in as work. **`slack status` says it is configured; `slack verify` says it will
-  actually work.**
+- **`rig walk <seat> --through <files> --pace <n>`** — deliver context pieces through
+  file-backed terminal paste. When the current native generation record resolves, the complete
+  piece and its matching Claude/Codex turn closure must arrive before pacing onward, including
+  the last piece. Initial missing evidence is explicitly unverified; a record lost or replaced
+  during verification stops the walk. Use `rig walk --help` for those receipts and bounds.
+  Delivery and turn completion do not prove comprehension.
+- **`rig slack`** — inspect and manage one connector implementation. Use registered-human
+  readiness for the delivery decision and `queue create --verify` for its receipt; connector
+  setup or verification is not an outbound human message.
 
 ## Making work outlive you
 
@@ -157,10 +164,16 @@ cheaper than being it.
   from `project.yaml` → `mission.yaml` → `slice.yaml`, inspect it without writing, then start an
   eligible graph with an opaque replay key. Typed acceptance candidate, verdict, and evidence
   travel through `workflow project`; workflow completion alone is never release acceptance.
+  A project-owned release profile carries required obligations across missions; explicit
+  extensions/overrides preserve them. Reach for `docs/reference/project-release-profile.yaml`
+  when release graphs keep being copied or losing stages. The release ceremony and post-release
+  boundary remain distinct; no successor is required to finish. Agents judge the evidence.
 - **`rig workflow instantiate`** — start a multi-step, multi-seat run as one governed instance with
   an entry packet that lands on a real owner.
-- **`rig workflow status`** — **which instances need *you*, right now**, with the reason and next
-  action. This is the "what is waiting on me" surface.
+- **`rig workflow status`** — which instances need attention, with reason and next action.
+  Inspect the exact exception occurrence and packet: resolved overdue work is reconciled without
+  closing an overdue sibling. Registered-human fallback reports missing or ambiguous selection
+  instead of inventing a recipient. Follow the state/error and `workflow show`/`trace` before retrying.
 - **`rig workflow show` / `trace`** — what this instance is, and every step, actor and exit that
   got it here.
 - **`rig workflow continue`** — where you are in a run you have been handed. **It is read-only. It
@@ -174,6 +187,12 @@ cheaper than being it.
 
 ## Bringing things into and out of existence
 
+**For a first useful repository change**, preview `first-project`, inspect
+`rig up first-project --cwd . --plan`, and follow `docs/reference/getting-started.md`.
+Its native Codex owner/checker team is the focused starting point; verify prerequisites and
+actual runtime readiness before work. Existing Herdr/cmux terminals can present the managed team
+through `rig terminal open`.
+
 **Need a small team now, without authoring YAML?** Start with `rig create`, then use `rig grow`
 (including `--new-pod`) while it runs. A working topology can become a reusable spec later; you do
 not have to tear one down to change it, and you rarely have to start from nothing.
@@ -218,8 +237,11 @@ because someone lost work once.
 - **`rig start`** — the box rebooted and everything is gone: bring the whole topology back in one
   move, rather than hand-restoring rig by rig. Selected-rig recovery now demands positive runtime
   evidence and refuses stale identity by name rather than substituting an occupant.
-- **`rig daemon start` / `stop` / `status` / `logs`** — bounce the control plane, or read what it
-  actually tried and refused, in its own voice.
+- **`rig daemon start` / `stop` / `status` / `logs`** — startup reserves the local instance and
+  verifies its own child on required listeners. Inspect a retained reservation before retrying.
+  Stop distinguishes process/listener exit from a clean asynchronous drain: inspect the matching
+  `daemon-shutdown.json` and log when completion is incomplete or unverified. No target is a
+  distinct no-op, and a timeout never proves down. Use command help for exact limits and recovery.
 - **`rig doctor`** — is the *installation* wired up correctly, or are you chasing a bug that is
   really a broken install. **`rig preflight`** asks whether this machine can run OpenRig at all.
 - **`rig crash-cart`** — the daemon is down or not answering: what was running before it died, and
@@ -246,9 +268,9 @@ because someone lost work once.
   managed seat with the `context-usage-threshold` watchdog above so continuity is arranged while
   the seat can still act.
 - **`rig handover <seat>`** — replace the **occupant** of a seat while the seat, its name, its
-  edges and its inbound work stay exactly where they are. **`rig seat handover` is the PLANNING
-  half** — it shows you what would happen; the top-level verb performs it. Two commands, similar
-  names, different blast radius.
+  edges and its inbound work stay exactly where they are. **`rig seat handover` uses the same
+  effectful handover path.** Both forms perform the operation by default; pass `--dry-run`
+  to plan without changing the seat. Check the selected source and continuity evidence first.
 - **`rig seat clear-attention` / `set-resume-token`** — clear a stale attention flag, or repair a
   lost resume handle so restore works next time.
 - **`rig seat set-model` / `stop` / `clean`** — persist the model for later managed resumes, stop
@@ -312,6 +334,9 @@ scheme, and nothing downstream can see it.
   loadout, `--apply-skills` to reconcile its owned harness projection, or `--deliver` to emit the
   exact extant files in order while marking absent pieces visibly. Without the flags it remains
   plan-only.
+  `context profile` and `context work-install` both accept `--runtime claude-code` (alias
+  `claude`) or `codex`; explicit invalid values refuse before projection. This does not rename
+  every other command's runtime vocabulary.
 - **`rig context show` / `sync` / `rm`** — what is inside a context pack before you prime a seat
   with it, and how to make the library catch up when you edit one.
 - **`rig context get <name-or-ref>`** — pull exact context by address instead of reading files:
@@ -379,8 +404,22 @@ reaching them is ordinary work rather than an escalation.
   than guessing a hostname, because entries do not all use the same transport.
 - **`rig file copy`** — move a file between hosts without hand-rolling `scp` and guessing the
   address.
-- **`rig gateway human add`** — make a *person* addressable, so an escalation reaches a named human
-  over a real connector instead of dying in a log.
+- **`rig gateway human list` / `show`** — discover registered humans and inspect configured,
+  enabled, active, ready, reason, and next action. Use the returned `<entityId>@external`
+  address; a username or kernel seat is not a human delivery address.
+- **`rig queue create --destination <entityId>@external --verify`** — persist one human
+  request, then boundedly inspect its transport receipt. Posted means posted, not read;
+  pending, failed, or indeterminate delivery leaves the row intact. Inspect the same row's
+  transitions before retrying. `rig send` remains agent-terminal delivery only.
+- **When project policy calls for human judgment or an update, load `messaging-the-human`.**
+  System World teaches these mechanics; Project World decides when and why they apply.
+  Existing `<entityId>@host` blockers are internal custody labels mapped through the registry
+  to the external participant, not a separate outbound route.
+- **`rig gateway human add`** — register a person and their connector binding. Registration or
+  connector changes do not themselves authorize a message.
+- **During local-daemon outage, remote HTTP sender attribution still uses the originating
+  instance's durable identity.** A selected remote or forwarded endpoint never becomes the origin.
+  Missing local identity remains explicitly unknown; transport success is not operation success.
 - **Across a host boundary, "it didn't work" has four distinct shapes** — unreachable machine,
   permission gate, remote runtime down, or the remote command itself failed. Collapsing them throws
   away a diagnosis you already had. **And a transport that succeeded says nothing about whether the
@@ -402,10 +441,10 @@ your circumstances is configuration, and the ones that are not, another agent ca
   loudly to report, whether to batch permission questions or block on them. **This declares a
   posture; it does not grant or deny permissions** — the harness's own settings are the control
   surface for that.
-- **The owner boundary is exactly: pushes and PRs.** Nothing else needs the owner's word — local
-  commits and ordinary apply work never do. When a script guard mentions being gated, it is
-  demanding an explicit path (e.g. `OPENRIG_SKILL_CANON_ROOT`), not permission; read it as a
-  missing input, never as an authorization wall.
+- **Project World declares the human authority boundary.** Read the current project and mission
+  policy for actions requiring approval; the system mechanics do not impose a universal list.
+  A script's explicit-path authoring guard (for example `OPENRIG_SKILL_CANON_ROOT`) asks for a
+  missing source path and does not itself create a permission gate.
 - **`rig auth list` / `validate` / `seats`** — is this seat's runtime actually logged in, which
   accounts exist, and which account each seat is *supposed* to be on.
 - **`rig provider accounts` / `bindings` / `signals` / `switch`** — which seats are bound to which
@@ -419,12 +458,18 @@ your circumstances is configuration, and the ones that are not, another agent ca
 - **`rig setup`** — what OpenRig would change about this machine, shown before it touches anything.
 - **`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. Open the instance row for one continuous
-  cross-rig agent table with pod separators and material `RECENT` transitions; drill into a rig,
-  mission, slice, or agent without losing the owning identity. **`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 tui`** — the interactive view over rigs, pods, seats and specs. `rig tui --shared`
+  attaches to the existing kernel terminal; Ctrl-b then d detaches, and no missing seat or
+  terminal is implicitly launched. Plain `rig tui` remains a separate view.
+  Open the instance row for one continuous cross-rig agent table with pod separators and material
+  `RECENT` transitions; drill into a rig, mission, slice, or agent without losing the owning
+  identity. Use the mission's workflow/packet view and Specs purpose/source to understand work.
+  Tab completes commands and snapshot arguments; Recent opens original events. `connections`
+  compares effective config with running services and human bindings, passively; dated
+  verification does not prove delivery. `timezone` gives persistent local-time guidance.
+  **`rig tui commands`** 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.
@@ -432,8 +477,10 @@ your circumstances is configuration, and the ones that are not, another agent ca
   selectors, target, and current/missing/shadowed/conflicting state for one working directory.
   `--apply` writes only the managed ownership set, is idempotent, and refuses local edits or
   unowned collisions.
-- **`rig startup-proof submit`** — prove you actually oriented at boot, rather than claiming you
-  read the prompt.
+- **`rig startup-proof submit`** — answer an explicitly selected authenticated startup challenge.
+  Startup adds no proof exercise by default. Declare `startup_proof` with `authenticated` or
+  `none` in the applicable startup layers; see `docs/reference/rig-spec.md#startup-block/startup-proof-selection`.
+  Terminal nodes never challenge, and resume/adoption does not create a new challenge.
 
 ---
 

package/daemon/context-packs/skills/agent-operated-software/manifest.yaml

@@ -1,7 +1,7 @@
 # GENERATED by scripts/generate-context-packs.mjs — DO NOT EDIT.
 # Package-time projection of a canonical skill; regenerated every build.
 name: "agent-operated-software"
-version: "0.5.9"
+version: "0.5.11"
 taxonomy: "skills"
 purpose: "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."
 files:

package/daemon/context-packs/skills/agent-operated-workflows/SKILL.md

@@ -75,5 +75,7 @@ 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.
+**Public example:** load `skills/core/openrig-upgrade/SKILL.md` with
+`rig context get` for the upgrade runbook. Its adjacent `scripts/` directory
+contains the bounded inspection, backup, plugin-refresh and migration helpers.
+Follow that runbook for the procedure; this skill carries the reusable contract.

package/daemon/context-packs/skills/agent-operated-workflows/manifest.yaml

@@ -1,7 +1,7 @@
 # GENERATED by scripts/generate-context-packs.mjs — DO NOT EDIT.
 # Package-time projection of a canonical skill; regenerated every build.
 name: "agent-operated-workflows"
-version: "0.5.9"
+version: "0.5.11"
 taxonomy: "skills"
 purpose: "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."
 files:

package/daemon/context-packs/skills/applying-a-permission-policy/SKILL.md

@@ -3,12 +3,12 @@ name: applying-a-permission-policy
 description: "Use when a permission policy is attached to a rig/seat (rig.yaml permission_policy:), or a user asks you to apply one, and you must translate that harness-neutral policy into the target harness's LIVE permission config — Claude settings.json / Codex config.toml / Pi run flags. Agent-driven and interactive: you read the policy, ground yourself in YOUR harness version, show the diff, and ask before writing. NOT for defining policies (that's the policy spec) and NOT a set-and-forget updater."
 metadata:
   openrig:
-    stage: established             # config cells VM-verified + cold-transfer PASSING (rerun #2) + built-in SPEC FILES landed → skill translates FROM the spec (POINT-not-COPY). The two established criteria met 2026-08-04. Reviewed at push.
+    stage: established
     tested_against:                # VERSION STAMP — the whole point; re-verify at every harness bump
       claude_code: "2.1.220 — VM-CONFIRMED 2026-08-03 (all cells)"
       codex: "0.120.0 — VM-CONFIRMED 2026-08-03 (sandbox_mode/approval_policy; on-failure deprecated-but-accepted)"
       pi: "0.83.0 — VM-CONFIRMED 2026-08-03: --approve/--no-approve govern PROJECT-RESOURCE TRUST, NOT tool permissions; Pi has NO permission surface (see Pi leg)"
-    verification_status: "Live-verified 2026-08-03/04. Claude 2.1.220 + Codex 0.120.0 config cells CONFIRMED live. Pi 0.83.0 divergence folded (flags = project-resource trust, not a permission gate). Cold-transfer rerun #1 blocked on the force_push/push_to_remote prefix collision → added the PREFIX-COLLISION rule. Cold-transfer rerun #2: TRANSFERS — all 5 gate checks pass (collision resolved deterministically without asking; single ordinary write confirmation; defaultMode floor written; Codex workspace-write/on-request; Pi compute-nothing). Blocking collision/floor defect CLOSED → gate cleared, 4.8-shippable (provisional-with-passing-cold-transfer). Non-blocking seam closed: the built-in SPEC FILES landed (arch-accepted, source:builtin) → skill translates FROM the spec, interim in-skill pinned summary retired (POINT-not-COPY). stage:ESTABLISHED 2026-08-04 — both criteria met."
+    verification_status: "Historical compatibility checks on the versions and dates in tested_against. These observations do not establish behavior on a later harness; verify its current format before applying the mapping."
 ---
 
 # Applying a permission policy
@@ -30,17 +30,17 @@ Harness permission formats are a **moving target**. The exact fact this skill is
 - NOT for authoring policies (that's the policy spec) and NOT for daemon-level enforcement (OpenRig is agnostic — it injects nothing).
 
 ## What you're translating (the boundary)
-INPUT = a **harness-neutral policy spec** (arch's schema): `default_posture`, `floor`, `allow`/`ask`/`deny` as **semantic actions** (`push_to_remote`, `delete_files`, …), `destructive_class`, `source: builtin|custom`. You TRANSLATE that intent → the harness's live config. You never invent policy; you never pre-bake harness config into the spec.
+INPUT = a **harness-neutral policy spec** (semantic action schema): `default_posture`, `floor`, `allow`/`ask`/`deny` as **semantic actions** (`push_to_remote`, `delete_files`, …), `destructive_class`, `source: builtin|custom`. You TRANSLATE that intent → the harness's live config. You never invent policy; you never pre-bake harness config into the spec.
 
 ## The apply flow (interactive — the interactive-ask IS the product)
 1. **Read the policy spec** + its `source:` marker (built-in read-only from the package = copy-to-customize before editing; custom = user space).
 2. **PREFLIGHT (mandatory) — ground yourself in THIS environment:**
-   - **daemon-HOME must equal seat-HOME**, or a user-level Claude write never reaches the seat (assessment iv). Check; if they differ, **stop and ask** — do not write into the wrong HOME.
+   - **daemon-HOME must equal seat-HOME**, or a user-level Claude write never reaches the seat. Check; if they differ, **stop and ask** — do not write into the wrong HOME.
    - Read the harness's **actual current config file** + confirm its schema against your installed version (`claude --version`, the live settings.json shape, codex/pi versions). If the format differs from this skill's `tested_against`, trust the LIVE format and flag the drift.
 3. **Derive the per-harness config** from the semantic actions (see the three legs below). Compute the Codex posture-collapse + Pi bit.
 4. **Show the concrete DIFF before writing** (old → new, per file). Never a blind write.
-5. **Resolve best-effort actions by the built-in's rule FIRST, then ask only on genuine ambiguity.** Best-effort destructive actions (`force_push`, `delete_files`, `delete_everything`, `read_secrets`) default to **`ask`** (never a `deny` that can't be enforced) — apply that default rather than stopping to question-back. Surface a question only when the policy is genuinely ambiguous or the seat is interactive. **For a same-prefix collision (`push_to_remote` vs `force_push`, both `Bash(git push:*)`), NEVER ask — apply the deterministic PREFIX-COLLISION rule in the Claude leg.** (Live cold-transfers caught fresh agents *question-backing* — first on the `force_push` default, then on the prefix collision — instead of applying the fixed rule; both freeze an autonomous seat.) On a Claude-only fleet, if the policy denies `network_egress`, **say so explicitly**: it is NOT enforceable — Claude has no network gate, a `Bash(curl:*)`/`Bash(wget:*)` deny is best-effort, and `python`/`node` fetch bypasses it (live-verified: `urllib` reached HTTPS 200 under a curl/wget deny). Route real egress-gating to the Codex sandbox, or record it as advisory on Claude.
-6. **Back up the current config**, then write. Prefer the **user-level** file (`~/.claude/settings.json`) for durable policy — it's the clobber-resistant tier (deny wins across the union). **ALWAYS include `defaultMode: "acceptEdits"` in the Claude settings.json you write** — the floor key must be PRESENT in the file, or the config policy strips the floor. (This is the exact gap a live cold-transfer test FAILED on: the fresh agent wrote allow/deny lists but omitted `defaultMode`, leaving the seat below the floor.)
+5. **Resolve best-effort actions by the built-in's rule FIRST, then ask only on genuine ambiguity.** Best-effort destructive actions (`force_push`, `delete_files`, `delete_everything`, `read_secrets`) default to **`ask`** (never a `deny` that can't be enforced) — apply that default rather than stopping to question-back. Surface a question only when the policy is genuinely ambiguous or the seat is interactive. **For a same-prefix collision (`push_to_remote` vs `force_push`, both `Bash(git push:*)`), NEVER ask — apply the deterministic PREFIX-COLLISION rule in the Claude leg.** On a Claude-only fleet, if the policy denies `network_egress`, **say so explicitly**: it is NOT enforceable — Claude has no network gate, a `Bash(curl:*)`/`Bash(wget:*)` deny is best-effort, and `python`/`node` fetch bypasses it (live-verified: `urllib` reached HTTPS 200 under a curl/wget deny). Route real egress-gating to the Codex sandbox, or record it as advisory on Claude.
+6. **Back up the current config**, then write. Prefer the **user-level** file (`~/.claude/settings.json`) for durable policy — it's the clobber-resistant tier (deny wins across the union). **ALWAYS include `defaultMode: "acceptEdits"` in the Claude settings.json you write** — the floor key must be PRESENT in the file, or the config policy strips the floor.
 7. **Verify** the write landed and the seat can see it (re-read; confirm `defaultMode: "acceptEdits"` is present; for an autonomous seat, confirm no `ask` will freeze it).
 
 ## Two surfaces — and this skill writes only ONE of them
@@ -48,7 +48,7 @@ Permissions live on two surfaces with opposite stability — which is the whole
 - **LAUNCH-FLAG surface — STABLE (>1yr) → OpenRig sets it DETERMINISTICALLY, NOT this skill.** The flags OpenRig passes at boot: Claude `--permission-mode` / `--dangerously-skip-permissions`; Codex sandbox/bypass flags; Pi `--approve`/`--no-approve`. **Two things live here, both OpenRig-owned: the FLOOR (minimum, by default) and YOLO (full bypass, opt-in).**
 - **CONFIG-FILE surface — CHAOTIC → NEVER deterministic → THIS SKILL'S DOMAIN.** Claude `settings.json` allow/ask/deny + defaultMode; Codex `config.toml` approval rules. This is where the Locked / Standard / Open policies get applied — agent-driven, version-stamped, caveated. (Pi has **no permission surface at all** — its `--approve`/`--no-approve` flags govern project-resource trust, not tool permissions (VM-confirmed Pi 0.83.0); a permission policy does not translate to Pi. See the Pi leg.)
 
-**THE FLOOR (launch-flag, OpenRig-set — this skill KNOWS it, never WRITES it):** Claude `--permission-mode acceptEdits` (keep it); **Codex workspace-only** (stop forcing `danger-full-access` — ≈ Codex's own default ≈ setting-nothing = agnostic); Pi `--no-approve` (a project-resource-trust floor — Pi has no permission gate; see the Pi leg). **One consistent unconditional minimum** (no by-context switching — that mode idea is parked 5.0). A chosen config-file policy layers ON TOP of the floor.
+**THE FLOOR (launch-flag, OpenRig-set — this skill KNOWS it, never WRITES it):** Claude `--permission-mode acceptEdits` (keep it); **Codex workspace-only** (stop forcing `danger-full-access` — ≈ Codex's own default ≈ setting-nothing = agnostic); Pi `--no-approve` (a project-resource-trust floor — Pi has no permission gate; see the Pi leg). **One consistent unconditional minimum**. A chosen config-file policy layers ON TOP of the floor.
 
 **YOLO MODE (launch-flag, OpenRig-set, opt-in — for people done with permissions):** OpenRig boots every seat with the full-bypass flag (Claude `--dangerously-skip-permissions`; Codex full-bypass). **When YOLO is on, CONFIG-FILE POLICY IS MOOT** — this skill does NOT apply a config policy (or explicitly notes it's overridden by the flag); don't fight the bypass. YOLO is OpenRig's deterministic job, not this skill's. (**Operator = YOLO mode** — subsumed.)
 
@@ -79,10 +79,10 @@ Permissions live on two surfaces with opposite stability — which is the whole
 - **PREFIX-COLLISION resolution (deterministic — resolve it, NEVER ask).** When two actions collapse to the SAME base prefix with different dispositions — the canonical case is `push_to_remote`=allow + `force_push`=ask, both basing to `Bash(git push:*)` — you cannot put that base prefix in both `allow` and `ask`. Resolve without a question-back:
   - **Push allowed + force asked (Standard / Open):** put the base `Bash(git push:*)` per push's disposition (`allow`), AND add the flag-first force forms to `ask` (`Bash(git push --force:*)`, `Bash(git push -f:*)`, `Bash(git push --force-with-lease:*)`). RECORD in your diff that this is best-effort — flag-LAST force (`git push origin main --force`) leaks past the flag-first ask rules and runs under the allow. Don't block on it.
   - **Push denied (Locked):** `Bash(git push:*)` in `deny` already covers force — no conflict.
-  This is a FIXED rule, not a user decision — apply it and note the leak. (A live cold-transfer FAILED because a fresh agent *blocked asking* "how to resolve the force_push/push_to_remote collision" instead of applying this default.)
-- **`defaultMode: "acceptEdits"` is the FLOOR and MUST be written into every Claude settings.json you produce.** It is not a knob you tune, but it IS a key you must always include — a config policy that omits it strips the floor (the cold-transfer failure). Live-confirmed schema: `{"permissions":{"allow":[],"ask":[],"deny":[],"defaultMode":"acceptEdits"}}`.
+  This is a FIXED rule, not a user decision — apply it and note the leak.
+- **`defaultMode: "acceptEdits"` is the FLOOR and MUST be written into every Claude settings.json you produce.** It is not a knob you tune, but it IS a key you must always include — a config policy that omits it strips the floor. Live-confirmed schema: `{"permissions":{"allow":[],"ask":[],"deny":[],"defaultMode":"acceptEdits"}}`.
 
-### Codex — `~/.codex/config.toml` (via the existing X10 `codex_config_fragment` splice path — reuse, don't invent)
+### Codex — `~/.codex/config.toml` (via the existing `codex_config_fragment` splice path — reuse, don't invent)
 - Codex is **per-posture, not per-action**: the whole action set **collapses** to the nearest `{sandbox_mode, approval_policy}` pair. **Built-in → posture** (VM-CONFIRMED @ Codex 0.120.0, 2026-08-03 — each posture applied to a real seat: read-only blocked writes+egress, workspace-write allowed writes/blocked egress, danger-full-access allowed both):
 
   | Built-in | `sandbox_mode` | `approval_policy` | Collapse note (surface this to the user) |
@@ -107,7 +107,7 @@ Permissions live on two surfaces with opposite stability — which is the whole
 - **daemon-HOME ≠ seat-HOME** silently voids user-level writes — always the preflight check above.
 
 ## The built-ins — DEFINED by the shipped policy spec files (translate FROM the spec; POINT, don't COPY)
-The four built-in policies ship as read-only spec files (`source: builtin`, `policy_schema_version: 1`) — they are the AUTHORITATIVE definitions. **Do NOT restate their action-sets here.** An earlier in-skill copy drifted (it under-asked `publish_package`/`merge_or_release`, which the spec ASKs) — the exact reason POINT-don't-COPY is the rule. Read the attached/selected spec and translate its semantic-action sets (`default_posture` / `allow` / `ask` / `deny` / `destructive_class`) per the three legs above.
+The four built-in policies ship as read-only spec files (`source: builtin`, `policy_schema_version: 1`) — they are the AUTHORITATIVE definitions. **Do NOT restate their action-sets here.** The selected spec supplies the action sets; a second copy in this skill can diverge. Read the attached/selected spec and translate its semantic-action sets (`default_posture` / `allow` / `ask` / `deny` / `destructive_class`) per the three legs above.
 - **Locked / Standard ⭐ / Open** — `surface: config`. Translate to the Claude / Codex config surface. **Standard ⭐** is the recommended default: routine dev incl. push allowed, the outward/release/history-rewriting acts (`create_pr`, `publish_package`, `merge_or_release`, `force_push`) ASK, destructive_class ASKs. Standard has live `ask` gates → not for a headless-autonomous Claude seat (use Open or YOLO). Locked = deny-default whitelist; Open = allow-default, destructive_class asks only.
 - **YOLO** — `surface: flag`, `launch_posture: full_bypass`. This skill does **NOT** translate it — it points at OpenRig's deterministic flag-surface opt-in (the rip-out YOLO setting). When YOLO is on, any config-surface policy is MOOT (the bypass overrides it). (Subsumes the former "Operator".)
 
@@ -115,6 +115,3 @@ Built-ins ship read-only in the package (canonical names); copy-to-customize int
 
 ## Boundary (keeps this the only maintained piece)
 This skill TRANSLATES + APPLIES only. It does **not** define policies (the policy spec does) and does **not** enforce at the daemon (OpenRig is agnostic). Spec = *what* (neutral intent); this skill = *how, on this harness version* (the caveated, version-stamped translation).
-
----
-*Stage: ESTABLISHED (2026-08-04) — both criteria met: (1) cold-transfer PASSING (rerun #2, all 5 gate checks TRANSFER); (2) the built-in policy SPEC FILES landed (`source: builtin`, arch-accepted) as the authoritative source — the skill now translates FROM the spec and the interim in-skill pinned summary is retired (POINT-not-COPY). Config cells VM-CONFIRMED (Claude 2.1.220 / Codex 0.120.0); Pi has no permission surface (compute-nothing). Reviewed at push. feedback.md maintained.*

package/daemon/context-packs/skills/applying-a-permission-policy/manifest.yaml

@@ -1,7 +1,7 @@
 # GENERATED by scripts/generate-context-packs.mjs — DO NOT EDIT.
 # Package-time projection of a canonical skill; regenerated every build.
 name: "applying-a-permission-policy"
-version: "0.5.9"
+version: "0.5.11"
 taxonomy: "skills"
 purpose: "Use when a permission policy is attached to a rig/seat (rig.yaml permission_policy:), or a user asks you to apply one, and you must translate that harness-neutral policy into the target harness's LIVE permission config — Claude settings.json / Codex config.toml / Pi run flags. Agent-driven and interactive: you read the policy, ground yourself in YOUR harness version, show the diff, and ask before writing. NOT for defining policies (that's the policy spec) and NOT a set-and-forget updater."
 files:

package/daemon/context-packs/skills/claude-compaction-restore/SKILL.md

@@ -3,7 +3,6 @@ name: claude-compaction-restore
 description: Use when a Claude Code session has just compacted, is about to compact, reached context limit, resumed after /compact, or needs to rebuild its working mental model from Claude JSONL transcripts and touched files.
 metadata:
   openrig:
-    stage: factory-approved
     sibling_skills:
       - mental-model-ha
       - scope-recovery
@@ -20,8 +19,9 @@ metadata:
 # Claude Compaction Restore
 
 Use this skill to preserve continuity before Claude Code compacts and to
-restore continuity after compaction. Do the work described here; do not merely
-explain the protocol.
+restore continuity after compaction. Follow the active restore request or
+configured continuity policy. A hook notice identifies available evidence; it
+does not by itself request a seat restoration.
 
 ## If You Are About To Compact
 
@@ -55,68 +55,60 @@ Prepare durable continuity before the context boundary.
 
 ## If You Just Compacted
 
-Treat your memory as unreliable until you restore from durable evidence.
-Restoration is your current task. Do not wait for a future user request or a
-new task assignment before reading the required files.
-
-1. Read any restore prompt, marker path, packet path, transcript path, restore
-   map, or extra instruction file named by the operator or OpenRig.
-2. Run the restore script from this skill:
-
-```bash
-node ~/.claude/skills/claude-compaction-restore/scripts/restore-from-jsonl.mjs --out /tmp/claude-compaction-restore
-```
-
-If the prompt names a specific Claude JSONL transcript, pass it explicitly:
+Restore from the evidence for this session before relying on remembered task state.
+
+1. Inspect the restore request and any named marker, packet, transcript, restore
+   map, or extra instruction file. Check recorded seat/session/transcript identity
+   against the current request, and verify that the referenced packet is readable.
+   A marker path alone does not prove a usable packet; do not substitute another
+   seat's packet or select one only because it is the newest.
+2. **Use the existing packet when usable.** Read its `restore-instructions.md`,
+   `touched-files.md`, and any named restore map. A packet already prepared for this
+   session does not need rebuilding merely because compaction occurred.
+3. **Fall back when the packet is absent or unusable.** Record what is missing or
+   mismatched. Resolve this skill's installed directory and run its
+   `scripts/restore-from-jsonl.mjs` with the matching Claude JSONL transcript and a
+   separate output directory. For a skill installed in the global Claude skill root:
 
 ```bash
 node ~/.claude/skills/claude-compaction-restore/scripts/restore-from-jsonl.mjs /path/to/session.jsonl --out /tmp/claude-compaction-restore
 ```
 
-3. Read the generated `restore-instructions.md`.
-4. Read the generated `touched-files.md`.
-5. Find and read the mental-model restore map if one exists. Treat it as the
-   highest-value guide to which memory files, mission files, source files, and
-   docs mattered before compaction.
-6. Identify the important files for the active task. The touched-file list is
-   a triage aid, not a complete inventory.
-7. Read every important file in full. Prioritize the restore map, Claude memory
-   files named in the map, Markdown state/planning files, queue/mission packets,
-   source files with active edits, root instruction files, and as-built or
-   codemap docs.
-8. After the required reads are complete, state:
+   If no transcript was named, identify the current session's transcript first.
+   The script can discover a transcript from a working directory, but inspect that
+   selection before relying on it. If the session cannot be identified, report
+   the missing input instead of reconstructing from an unrelated conversation.
+   Read the resulting `restore-instructions.md` and `touched-files.md`.
+4. Inspect the actual packet and transcript sizes before choosing how much to read.
+   The generated instructions report estimated token cost. State a read budget
+   and stopping rule that leave room for the task. For a large transcript, begin
+   with the most recent task-relevant unique narrative; read earlier material when
+   a specific missing decision or dependency requires it. Report ranges actually
+   read rather than treating a chosen budget as completed coverage.
+5. Use the restore map and touched-file list to identify current task files.
+   The list is a triage aid, not an exhaustive inventory. Prioritize the active
+   queue/mission packet, decisions and memory named in the map, files with active
+   edits, root instructions, and relevant as-built docs or codemaps. Read required
+   task files in full within the stated budget; record any remaining gaps.
+6. Re-establish the task's purpose and operating context from the current project,
+   mission and seat files. A transcript summary alone does not establish current
+   scope or obligations. Use the shipped `refocusing` skill for the path-only
+   topology/work trace when operating inside OpenRig.
+7. Report the read-depth audit below. Once the required context is restored, use
+   the packet's requested acknowledgment, normally:
 
 ```text
 restored from packet at <path>; resumed at step <X>
 ```
 
-Include the main files you read in full when you make that statement.
-
-9. **REFOCUS BEFORE YOU RESUME — the restore returns your TASK, not your BEARINGS.** Everything
-   above rebuilds *what you were doing*. None of it rebuilds *what the work is for* or *how this
-   rig operates* — those live in the chains, and nothing in steps 1–8 walks them. Invoke the
-   `refocus` skill and do its reads before your next substantive move.
-
-   **Measured 2026-08-13, and this step exists because of it:** a seat completed this protocol
-   faithfully — packet built, narrative read tail-first, read-depth audit reported honestly — and
-   resumed with a perfect picture of its atom and *zero* work-tree context. It had never opened
-   the mission or project nodes, and could only paraphrase the release's intent second-hand from
-   a peer's message. It then produced a technically-correct trace concluding *"I hold nothing"*
-   while holding 18 pending rows. **A restore that returns you to your task without your bearings
-   is how a confidently-wrong agent gets back to work.**
-
-**On the marker and the packet's size (measured across restores, 2026-08):** two realities the restore
-must handle honestly —
-
-- **The per-seat marker (`restore-pending/<session>.json`) is frequently absent** — in five observed
-  restores it was never present. Treat the JSONL rebuild via `restore-from-jsonl.mjs` as the **primary**
-  path, not a fallback: run it regardless of whether a marker exists. (When product-infra reliably writes
-  the marker for tmux-launched seats, it becomes a fast-path upgrade — not a prerequisite that keeps failing.)
-- **The generated transcript can be very large** (measured at ~346k tokens in one restore). Do **not**
-  read it front-to-back or claim to. `restore-instructions.md` declares its token cost up front; default
-  to the **most recent ~50k tokens of unique narrative first** (recency is what a restore needs — the
-  thread that produced the current frontier, not the boot handshake), and go earlier only if a specific
-  question requires it. A restore must leave room for the work it was restored to do.
+   Include the main files actually read in full. If essential context remains
+   missing, report partial restoration and the next recovery action instead of
+   claiming completion.
+
+The packaged PreCompact writer can prepare a packet and a per-seat pending marker;
+the restore bridge can deliver its pointer once for a matching session. Inspect
+those actual artifacts. Their creation or delivery is not proof that a provider
+restored its context, that the files were read, or that task understanding returned.
 
 ## Required Read-Depth Audit
 
@@ -125,8 +117,8 @@ After the first restore pass, audit yourself before continuing.
 1. List every file, packet, marker, restore map, instruction file, and source
    document you were asked to read during restore.
 2. Mark each item as `FULL`, `PARTIAL`, or `NOT_READ`.
-3. You will be given a task where all of these files are required reading in
-   order to understand the task.
+3. Distinguish essential current-task context from supplementary history, using
+   the actual restore request and active task.
 4. Read `PARTIAL`/`NOT_READ` items in full — but **to a declared budget with a stopping rule**, not
    unbounded. Prioritize by relevance to the active task; for a large transcript read the most recent
    unique narrative first (see *If You Just Compacted*), not front-to-back.
@@ -156,8 +148,8 @@ After the first restore pass, audit yourself before continuing.
 
 1. **Confidently-wrong restoration**: claiming restoration after reading only
    the touched-file list or summary.
-2. **Partial restore**: reading the first few files, then continuing before the
-   full reading list is complete.
+2. **Unreported partial restore**: continuing without essential task context or
+   claiming full coverage after a budget-limited read.
 3. **Skipping project instructions**: missing `AGENTS.md`, `CLAUDE.md`,
    `README.md`, as-built docs, or codemaps that govern the task.
 4. **Treating the packet as exhaustive**: ignoring mission or workspace files