@openrig/cli 0.5.9 → 0.5.11

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

@@ -27,11 +27,30 @@ All other skills are cross-runtime by design.
 
 ## Distribution
 
-**At v0 (today):** the vendored copy inside the OpenRig npm package is the source of truth. When you install `@openrig/cli` (or run the daemon), `openrig-core/` is copied to `~/.openrig/plugins/openrig-core/` on first run. This is the offline-safe baseline and is always available.
-
-**Auto-fetch from GitHub at v0:** the OpenRig daemon probes `github.com/mvschwarz/openrig-plugins/releases/latest/download/openrig-core.tar.gz` on launch with a 5s timeout. **At v0 the success path only logs the response and does NOT extract a tarball, compare versions, or update the local copy** — extraction + version-compare + update are scoped to a later marketplace-consumption phase (mission slice 3.6). 404 (the expected normal-state response while the GitHub repo is empty), network errors, and timeouts are all tolerated silently with the vendored copy remaining authoritative.
-
-**Future (slice 3.6, marketplace-consumption phase):** when the GitHub releases workflow is set up and authorization to publish lands, the daemon will start extracting fetched tarballs + comparing versions + updating the local copy as the "hot update" path that skips OpenRig CLI version bumps.
+The npm package includes an offline baseline under the daemon's
+`assets/plugins/openrig-core/`. The daemon resolves local plugin authority before
+attempting a network fetch, using the configured OpenRig home (normally
+`~/.openrig/plugins/openrig-core/` for the installed copy):
+
+| Installed state | Local vendoring behavior |
+| --- | --- |
+| Absent | Seed the bundled plugin. |
+| Older manifest version | Advance files from the newer bundled version. |
+| Equal manifest version | Preserve installed content; executable modes may be reconciled on byte-identical files. |
+| Newer manifest version | Preserve the installed copy. |
+
+Version authority comes from the plugin manifests. An existing directory without
+a manifest is left unchanged; invalid or disagreeing manifest versions are
+reported rather than guessed. Updating the CLI therefore does not unconditionally
+overwrite an equal/newer or independently managed plugin copy.
+
+After local resolution, the daemon attempts the GitHub release endpoint for
+`openrig-core.tar.gz` with a five-second timeout. This path currently fetches and
+logs the response only: it does not extract the archive, compare its version, or
+install its content. Fetch failures, including 404 and network errors, leave the
+resolved local copy in place. A successful fetch also leaves it unchanged.
+This describes the fetch implementation, not a claim that a release artifact is
+currently available at the external repository.
 
 You can also install directly via Claude Code or Codex's own plugin commands if you prefer to manage plugins outside OpenRig.
 

package/daemon/assets/plugins/openrig-core/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/assets/plugins/openrig-core/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/assets/plugins/openrig-core/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

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

@@ -84,14 +84,14 @@ you should know which pillar you're operating in:
 
 | Pillar | What it is | Where it lives |
 |---|---|---|
-| **Ontology** | What exists. Curated knowledge — facts, code maps, as-built docs. | Corpus (planned future system). Today: substrate prose docs. |
+| **Ontology** | What exists. Curated knowledge — facts, code maps, as-built docs. | Shipped public context packs plus project-authored docs; discover with `rig context list`. |
 | **Epistemology** | Why an agent believes what it believes — reasoning, instincts, decisions. | Transcripts (auto-captured). Session logs. ADRs. |
 | **Topology** | How agents are connected — pods, edges, communication paths. | OpenRig itself. RigSpec YAML. |
 
-OpenRig **manages the topology pillar**. The other two are filled by Corpus
-(future) and transcripts (now). Most of your work probably touches multiple
-pillars; knowing which one you're operating in helps you reach for the right
-artifacts.
+OpenRig manages topology and exposes public context through `rig context`.
+Project-authored sources supply project-specific knowledge; transcripts retain
+recorded work. These sources already coexist. Discover the configured library
+and selected task context rather than assuming a particular private corpus.
 
 ---
 
@@ -174,14 +174,15 @@ cost when you reach for one.
 | Home | Purpose |
 |---|---|
 | `<rig-cwd>/.claude/skills/`, `<rig-cwd>/.agents/skills/` | Where the harness actually loads from. Populated by `rig up`. |
-| `~/.claude/skills/`, `~/.agents/skills/` | Your personal / user-installed global skills, loaded by the harness itself (independent of OpenRig). NOT where OpenRig's own bootstrap skills live — those ship in the product (below) and project into the cwd `.claude/skills/` at `rig up`. |
+| `~/.claude/skills/`, `~/.agents/skills/` | User-level harness skill directories. Inspect the current projection and harness configuration to determine which skills are installed and where they came from. |
 | `openrig/packages/daemon/{specs/agents/shared/skills,assets/plugins/*/skills}/` | Product skills that ship with OpenRig — the spec pool + the bundled plugin assets (openrig-user, openrig-operator, openrig-architect, forming-an-openrig-mental-model, queue-handoff, claude-compaction-restore, …). |
-| `~/.openrig/skills/` | Future runtime install home for OpenRig-shipped skills. |
 | the skills authoring workspace | Skill authoring source (not runtime-loaded). |
 
-The harness only sees the first two. Other locations are authoring,
-shipping, and source-of-truth — they reach the harness via projection or
-NPM install, not directly.
+The product already discovers its installed shared skill pool and serves
+packaged context through `rig context list/get`. Discovery and retrieval do
+not prove that every skill was projected into every harness. Inspect the
+selected profile and actual runtime directories; do not assume a universal
+home/bootstrap installation from this table.
 
 ---
 

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

@@ -1,98 +1,85 @@
 ---
 name: messaging-the-human
-description: "Use when a human decision, access grant, external action, or escalation must survive the operator's absence, or when an orchestrator or PM has a judgment-worthy update for the operator."
+description: "Use when project policy calls for a human decision or update, a human delivery is pending or failed, or a reply must resume the right work."
 metadata:
   cli_surfaces_referenced:
-    - gateway human add
     - gateway human list
-    - queue block
-    - queue handoff
+    - gateway human show
+    - queue create
     - queue transitions
+    - queue block
     - send
   openrig:
     stage: provisional
     audience: all agents
     sibling_skills:
       - queue-handoff
-      - human-in-the-loop
       - openrig-user
 ---
 
 # Messaging the Human
 
-The human is an addressable participant, but their attention is scarce and they
-may not be at a terminal. Anything that must survive their absence needs a
-durable queue row; the gateway turns the human blocker on that row into the
-external notification.
-
-Any seat may contact the human directly for a real escalation. Orchestrators
-and product managers may also send updates they judge the human would want to
-know. Do not add a routing intermediary merely because of your role.
+Project World supplies **when and why** to contact a human. This skill supplies
+transport-neutral mechanics; installing it does not create an approval gate or
+choose a connector. If policy leaves a material decision ambiguous, identify the
+missing authority. Do not convert a solvable technical failure into a human gate.
 
-## The supported route
+## Discover, check, send, inspect
 
-First discover the registered human identity. Never invent or remember an
-address:
+Discover the registered participants and inspect the chosen human:
 
 ```bash
 rig gateway human list --json
+rig gateway human show <entityId> --json
 ```
 
-Use `humans[].entityId` to derive the durable blocker as `<entityId>@host`.
-The entity id must use the human-seat prefix (`human` or `human-...`); if it
-does not, stop and repair the registration rather than guessing. The returned
-`humans[].address` is the gateway delivery address, not the `--on` value. If no
-unambiguous registered human is returned, stop: registration is lifecycle work
-(`rig gateway human add --help`), not an address to guess.
+Use the returned `address` (`<entityId>@external`), not a username, remembered
+seat, connector handle, or guessed kernel address. Where several humans exist,
+use the decision ownership in Project World. An absent or ambiguous registration
+needs a named registration correction, not a fallback address.
 
-Keep the work row owned by the agent who must resume it, then park that row on
-the registered human:
+Check readiness: configured, enabled, active, ready, reason, and next action.
+`indeterminate` is not ready. Follow the reported next inspection; do not enable
+or reconfigure a connector merely to make the check pass.
+
+Write the decision, evidence, and continuation in a body file. The sole outbound
+human-message primitive is:
 
 ```bash
-rig queue block <qitem-id> --on <entityId>@host \
-  --summary "<decision owed>" \
-  --evidence-ref "<durable artifact the human should judge>" \
-  --continuation "<what resumes after the answer>"
+rig queue create --destination <entityId>@external \
+  --summary "<decision or update>" --body-file <packet-file> \
+  --evidence-ref <durable-evidence> --verify --json
 ```
 
-The gateway resolves the registered human to the configured connector, sends
-the Slack notification, and records its receipt on the same row. Confirm the
-effect from the append-only history:
+If an existing agent-owned row must wait, block it on the **new live qitem ID**
+(`rig queue block <work-id> --on <human-qitem-id> ...`), not on the human address.
+Completion of the human qitem resumes its dependants. Blocking on the human as
+well would issue another notification for the same decision.
+
+The row persists before bounded delivery verification. Read its qitem ID and
+verification result; `posted` proves connector posting, **not human readership**.
+`transport-failed`, `never-posted`, or a pending/indeterminate result leaves the
+row intact. Inspect that same row and its next action; never create a second row
+or blindly resend because verification timed out.
 
 ```bash
 rig queue transitions <qitem-id>
 ```
 
-The row is the obligation and the audit trail. Slack is the attention leg. A
-reply resolves the durable blocker and wakes the row owner; it does not create
-a second private work stream.
-
-## When to use it
-
-Escalate directly when only the human can supply the missing capability:
-
-- a decision or irreversible judgment only they own;
-- access, credentials, authority, or capacity only they can grant;
-- an external action only they can perform;
-- a security-class or provider/model-fallback event they need to know about.
-
-Orchestrators and product managers may additionally send meaningful milestone,
-environment, or completion updates. Prefer signal over routine narration.
-
-## Boundaries
+A correlated reply binds to that exact human and qitem and records the resolution
+that resumes the owner. Check the recorded result before claiming the decision
+arrived; a delivery receipt alone is not acceptance.
 
-- `rig send` sends text to an agent's terminal. It is not the Slack route and
-  does not create a durable human obligation.
-- An unregistered or ambiguous human identity must fail loudly. Register or
-  repair the identity; never downgrade it to an agent seat or a guessed
-  `@external` address.
-- Agent-to-agent work that needs closure uses `rig queue handoff`, not this
-  human-blocker path.
-- Deferred work that is not imminent belongs in the mission workspace, not on
-  the queue.
+## Existing blockers and other channels
 
-## Writing the escalation
+An existing agent-owned row may be blocked on `<entityId>@host`. That is an
+internal custody label resolved through the human registry to the same external
+participant; it is not a second delivery address. Keep the owner and continuation
+on that row. Inspect its existing delivery receipt before considering another
+request, so a legacy blocker does not produce a duplicate message. Never derive
+`@host` from the current rig name.
 
-Lead with what is blocked and the exact decision or action needed. Point at the
-durable evidence instead of pasting a second copy, and name the continuation so
-the system can resume the right work when the answer arrives.
+`rig send` reaches an agent's terminal only. It is not a human transport or a
+durable human obligation. Agent-to-agent work uses the queue handoff path.
+Connector-specific configuration and handles belong to registry/readiness tools,
+not to project-independent message instructions.

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

@@ -17,11 +17,25 @@ Use this skill to actually **do** mission/slice work: track on the canonical fil
 
 **Full convention SSOT:** repo `docs/reference/sdlc-conventions.md`; installed `$OPENRIG_HOME/reference/sdlc-conventions.md`. This skill is the concise Part-A teaching surface and does not replace the full convention.
 
-## THIS IS THE LIGHT DEFAULT — read this before anything else
-
-**The default for any slice is the inner loop:** ground yourself → build → **test with your own eyes** → iterate → **ONE** full-breadth review at the end. That is the whole process. It is not a reduced form of a better process; it IS the process.
-
-**Part B is defined in the SSOT above and applies only when the human operator — or an orchestrator explicitly relaying that decision — assigns it to a named piece of work.** You may not select it yourself. If you believe something earns it, say so in one sentence and **continue on Part A** until told otherwise.
+## Resolve the work first
+
+Run `rig whoami --json`, then resolve `project.yaml -> mission.yaml -> active
+slice.yaml -> selected component or wave map -> addressed context`. The complete
+lookup and precedence rule is `docs/reference/product-journey-sdlc.md#resolve-the-selected-path`
+(installed: `$OPENRIG_HOME/reference/product-journey-sdlc.md#resolve-the-selected-path`).
+Read the selected addresses and source needed for this task; skills available in
+your profile are capabilities, not a mandatory reading list. No composition means
+light Part A. Role names and idle seats add no gates. Explicit rigor and authored
+wave boundaries retain their named checks.
+
+The light inner loop is ground yourself → build → test with your own eyes →
+iterate → record and return the whole outcome. The builder may hold this check
+on a tiny change. Independent review runs only when selected, and once at an
+authored wave boundary rather than once per slice.
+
+Part B is defined in the conventions SSOT and runs only when explicitly assigned
+to named work. If you believe it is needed, state the reason to the owner and
+continue on the selected path until that choice changes.
 
 ## Proportionality — this SOP serves shipping; it is not the work itself