@openrig/cli 0.5.10 → 0.5.11

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

@@ -20,7 +20,7 @@ A **planned** seat transition. A long-lived seat accumulates context; as it near
 window's edge, don't wait for compaction to degrade you into a cold-started agent —
 **retire deliberately** and hand the seat to a fresh successor primed from a packet plus
 the seat's accumulated lineage. The **seat address is stable; its occupants are a lineage.**
-This is the practice that named the "seat" primitive.
+Keep the transition and its authority explicit.
 
 ## Use this when
 
@@ -48,8 +48,9 @@ threshold you can see coming; fall back to compaction only when a transition was
 
 ## The handover sequence
 
-1. **Trigger** — ~85% context, or a deliberate role transition. The oversight-rig context
-   detector can fire this for you; you can also self-initiate when you feel the edge.
+1. **Trigger** — the selected continuity threshold or a deliberate role transition.
+   Use the configured policy and named transition owner; a context estimate alone
+   does not authorize a cutover.
 2. **Author the handover packet, deliberately** — a composed context pack carrying current
    work + next owner, the seat's durable pointers, constraints and authority boundaries, and
    the accumulated **lineage wisdom** ("those before you learned X"). This IS a restore packet
@@ -66,26 +67,29 @@ threshold you can see coming; fall back to compaction only when a transition was
    `orienting-to-an-inherited-seat`** — its world model of what a handover *is*. Carry that
    pointer **in the durable packet artifact itself**; never inject it as a runtime prompt keyed
    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
+   teaches successors to refuse). Artifact-carried
    survives the swap for free and needs no enabled gate.
-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.
+4. **Assess before cutover.** If an apprenticeship or warm handoff is selected,
+   use that staged window for questions and domain work before the owner decides.
+   The incumbent retains authority until the owner-worded cutover; do not retire
+   it merely to free a name while waiting for that decision.
+5. **Preserve the physical seat at cutover** — follow the portable SOP linked from
+   `seat-continuity-and-handover`. Keep the canonical tmux session, window and pane;
+   resume the exact accepted successor history there and reconcile binding,
+   environment, queue identity and attached clients. Preserve the incumbent's
+   exact token as a cold-advisor handle when that is the selected disposition.
+   Renaming tmux sessions is a repair fallback, not the default sequence.
+6. **Write the lineage-ledger row and tombstone** (below). Record the actual
+   outcomes and transfer each standing duty explicitly. Complete the successor's
+   post-cutover self-check before unfreezing authority.
 
 ## 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.
+errands, answer questions, and judge work in the real domain. 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
@@ -114,15 +118,15 @@ ledger is the tenure record; work-tree notes remain lived context, not identity
 **Crash-ended tenures** get their row appended **post-hoc** by the crash-cart / restore path,
 flagged **honest-approximate** (the boot-captured session id is what makes this recoverable).
 
-## Do NOT over-inherit — the key lesson from the practice's history
+## Inherit the seat, not the predecessor's identity
 
 **You are inheriting a seat, not becoming your predecessor.** Frame it explicitly to the
 successor: *"agents sat here before you and learned X; you carry the seat's mission, not their
-identity."* The historical failure was agents getting confused about whether they **were** the
-predecessor — carrying a stale self-model, over-claiming prior work as their own. Inherit the
+identity."* Do not claim a predecessor's work as your own or use its stale identity
+as the current binding. Inherit the
 seat's **mission and hard-won lessons**; keep your own **fresh identity and session**.
 
-## Wake v0 — ask the agent who sat before you (a practice, not a verb)
+## Reach back to a retained predecessor
 
 A retired tenure is a cold advisor you can consult. Look up the seat's ledger → get that
 generation's session token → resume it for **one question**, then let it sleep again:
@@ -130,19 +134,22 @@ generation's session token → resume it for **one question**, then let it sleep
 - Claude: `claude -p --resume <session>`
 - Codex: `codex exec` (resume the rollout)
 
-This is also a `rig` verb: `rig ask <rig> "<q>" --wake <seat[@gen]|token>` (CLI 0.5.1; also
-`--runtime`, `--wake-timeout`, default 180s). It wraps the harness resume above and is **not yet
-well-exercised** — if it fails, fall back to `claude -p --resume <full-uuid>`. **A failing wrapper is
-not a closed channel.** The ledger is how you **find** the right predecessor; wake is how you ask them.
+Use `rig ask <rig> "<q>" --wake <seat[@gen]|token>` for an explicit bounded
+consultation (introduced in CLI 0.5.1). Check `rig ask --help` for `--runtime`
+and `--wake-timeout`. The wrapper uses a runtime resume; its presence is not
+proof that a particular retained history is available. For a Claude history,
+`claude -p --resume <full-uuid>` is the runtime-level fallback when supported.
+Diagnose the specific failure before declaring the channel unavailable.
 
 **What to write in your packet about reaching you** — your successor asking you questions is the
 reason this is a handover and not a compaction:
 
-- **State that the channel does not expire**, and give your **verbatim resume handle**. You stay
-  reachable after retirement; the only real bound is your own context wall, hit while answering. Ask
-  them to treat your answers as testimony if you like — that is a posture claim, not a limit on access.
+- **Give your verbatim resume handle and known availability limits.** Retirement alone
+  does not expire retained history. Resuming still depends on that history, runtime
+  access and remaining context; distinguish these failure modes. The advisor
+  supplies testimony and does not regain the live seat's authority.
 - **Pre-form the questions.** Inventory what only you hold and write the questions out. An affordance
-  without a trigger goes unused, so *"you may consult your predecessor"* reliably produces none.
+  needs a trigger: name the tradeoff, missing rationale or conflict that should prompt a question.
 
 **Wake-tenancy — the identity halves (a woken tenure can mistake itself for the live seat).** The
 hardest thing to apply *checked-not-believed* to is your own identity — a retired tenure resumed for a
@@ -165,57 +172,36 @@ question can answer, and act, as if it still held the seat. Two rules close it:
 3. **Session id captured at retirement, not boot** — a crash then leaves no row, or an
    unfindable tenure. Capture at boot.
 4. **Suffixing the LIVE seat** (`<seat>-v2` as the active address) — lineage leaking into
-   identity, the wrong shape. The live address stays clean; only the retiree is versioned.
+   identity, the wrong shape. The live address stays clean; generation belongs in the ledger.
 5. **Tombstone omitted or vague** — the ledger can no longer answer "who did this / who to
    wake." One honest line, every tenure.
 
-## Field-validated refinements (pilot 2026-08-05 — two live runs, both runtimes)
-
-Two live handovers (a Claude seat + a Codex seat) ran this sequence end-to-end and sharpened it:
-
-- **A GATED handover uses STAGED primitives, not an all-in-one verb.** An atomic
-  create/deliver/verify/rebind verb can't pause for a human go/no-go gate. Decompose it: boot the
-  successor **staged (unbound)** → prime it → **retire** the incumbent (this frees the clean seat name)
-  → **HOLD for the gate** → **swap** (bind the successor to the canonical name). The gate sits between
-  retire and swap; a no-go rolls back by renaming the retiree back.
-- **Prime AT BOOT, not walk-after-boot, for a staged successor.** Delivery verbs (`rig walk` / `rig
-  send`) resolve via the **bound** session registry, so they cannot reach an unbound staged successor.
-  Boot it **with the packet as startup/priming context** (the "primed from a handover/startup packet"
-  path). In both runs the successor read the full packet and correctly stated inheritance-not-identity
-  and held.
-- **The lineage ledger is the ONLY reliable wake path — load-bearing, not convenient.** A retired
-  occupant (`<seat>-vN`) is intentionally **absent from the managed registry** — discovery / walk / send
-  cannot find it. The ledger's **boot-captured** session id is how you wake it: `claude -p --resume
-  <id>` (Claude) or `codex exec` resume (Codex) — harness-level, not the rig registry.
-- **Tombstone honest-approximate fallback.** If a long-idle retiree can't be woken to self-write its
-  tombstone, the driver records an honest-approximate one and **flags it as such**.
-- **Telemetry-degraded flag when warranted.** If a fresh successor's activity/producer-link telemetry
-  is degraded, flag its ledger row so no future reader trusts its activity state. (One runtime showed a
-  fresh-launch telemetry gap; the other was clean — capture the reality, don't assume.)
-
-### Production-evidenced (first real-stakes run — a critical-seat generation swap, 2026-08-05)
-
-The first live swap at a critical seat **succeeded** (the successor ruled a live domain question within the
-hour — doctrine intact across the generation) and surfaced two hard refinements:
-
-- **Boot-window queue re-check is REQUIRED — the successor's first action.** A qitem created *during* the
-  swap window can land **after** the handover packet was frozen — and its boot nudge fails
-  `session-not-found` because the seat is mid-cutover. The packet's snapshot is therefore incomplete by
-  construction. So the successor's first action is a **checked-not-believed queue sweep** (`rig queue list`
-  by destination / `--mine`), never trusting the packet's snapshot alone. The swap-window delivery seam is a
-  known product gap until it's closed.
-- **Complete the canonical rename AT cutover — or expect three breakages.** If the staged name
-  (`<seat>-vN-staging`) survives past cutover, it breaks across three identity surfaces with inconsistent
-  enforcement: **transport** (the staged label doesn't resolve; replies to the signature bounce),
-  **queue-claim** (`claim_destination_mismatch` rejects the seat's own claim), and **queue-ledger**
-  (`handoff-and-complete` stamps the phantom staged name durably as `sourceSession`). The product fix is
-  tracked; until it lands, finish the canonical rename at cutover and treat a lingering staged name as a
-  live defect, not cosmetic.
-- **Pre-announce the swap to oversight at swap START.** A live swap fired oversight's liveness detector
-  mid-swap (a false positive, cleared). Oversight clears such flags by consulting handover **receipts** —
-  but receipts only land at swap **end**, so a long swap window can still misfire. So the executing party
-  sends oversight a **one-line pre-announce at swap start** (seat + expected window); oversight honors it
-  as a **suppression window** for its liveness / premature-park flags. See `oversight-team`.
+## Checks around a planned transition
+
+- **Stage and assess before the owner calls cutover.** Use startup context when the
+  successor is unbound; check its actual address before relying on registry-routed
+  delivery. Keep incumbent authority and physical-pane custody until the selected
+  SOP's cutover steps apply. A rejected candidate does not require renaming the
+  incumbent back into a seat it should still hold.
+- **Preserve exact resume handles.** A retained advisor may have no managed node or
+  live pane. The ledger identifies its history independently of the live-seat
+  registry; absence from `rig ps` alone does not prove that history is gone.
+- **Recheck work at the boundary.** Queue items can arrive after the packet was
+  frozen. The successor reads its current owned queue, reconciles transition-window
+  work and staged inputs, and records every remaining obligation.
+- **Verify identity across surfaces.** Canonical binding, provider history,
+  process environment, queue identity and attached clients must agree. Correct a
+  staged identity residue through the supported cutover/reconciliation path;
+  renaming a tmux session alone is not proof that those surfaces agree.
+- **Keep incomplete evidence explicit.** Flag unavailable activity telemetry as
+  unavailable, and mark a tombstone written by someone else as approximate.
+- **Coordinate the maintenance window.** Tell the routing/monitoring owner the
+  target and expected window before an authorized cutover. Only an explicitly
+  configured suppression changes monitoring behavior; close the window with the
+  actual effect receipt, deviations and unresolved gaps.
+
+These are verification prompts, not a claim that a particular runtime transition
+has passed. Use the linked portable SOP for mechanics and record the actual run.
 
 ## See also
 

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

@@ -24,17 +24,15 @@ A pair of primitive families that separate *who is sitting in a seat* from
 *what the seat itself is*:
 
 1. **Occupant-creation primitives** — `resume`, `fork`, `rebuild`, `fresh` — produce a candidate new occupant. Answer: "where did the new occupant come from?"
-2. **Seat-binding primitives** — `seat handover`, later `seat transfer` / `seat retire` / `seat swap` — bind a candidate occupant into the topology. Answer: "what happened to the stable seat identity?"
+2. **Seat-binding operations** — handover binds a candidate occupant into the topology. Answer: "what happened to the stable seat identity?" Inspect the current CLI for executable operations; design vocabulary alone does not establish a command.
 
 Core architectural decision: **stable seat identity, fluid occupant
-identity, explicit provenance.** Today's `lead2`/`lead3`/`lead4`/`lead5`
-pattern encodes successor lineage into seat names — that's the wrong
-shape. Stable seat name + separately-recorded provenance trail is the
-right shape.
+identity, explicit provenance.** Do not encode successive occupants into live
+seat names. Keep the stable address and record lineage separately.
 
 ## Use this when
 
-- Replacing a seat's occupant via rebuild, fork, fresh, or future seat-handover
+- Replacing a seat's occupant via rebuild, fork, fresh, or seat-handover
 - Choosing old-occupant disposition: retire / advise / shadow
 - Reasoning about whether a seat's lineage is stable or has drifted
 - Reading or writing the provenance record for a seat
@@ -108,21 +106,28 @@ A seat stays `Stable` even if multiple candidate-occupants were produced and dis
 ## Hard boundaries (do-not list; verbatim)
 
 - **Do NOT collapse `rebuild` and `seat handover` into one primitive.** The design specifically separates them so the system can describe what actually happened.
-- **Do NOT introduce successor-suffix seat names** (`lead2`/`lead3`). Stable seat identity is the architectural goal. *(Reconciliation: this governs the **live** seat address, which stays clean — the seat name is whoever sits now. A **retired** tenure IS versioned (`<seat>-vN`) as the separately-recorded provenance trail / cold wake-target — that is the lineage, not a live successor-suffix. See `retiring-and-inheriting-a-seat` and its lineage ledger.)*
+- **Do NOT introduce successor-suffix seat names** (`lead2`/`lead3`). Stable seat identity is the architectural goal. The live address stays stable. A retired tenure is distinguished by its ledger
+generation and exact history token; preserving it does not require a renamed live pane.
+
 - **Do NOT report `seatBindingOutcome: handed_over`** if the provenance record didn't write durably.
 - **Do NOT auto-rollback a half-completed handover** by re-attaching the old occupant unless detach completed cleanly first.
 
-## Composition: seat handover over fork
+## Composition and current command surface
 
-Once `session_source` fork v1 lands (already shipped at openrig
-`c7b6df1`), the next composition is **seat handover over fork**:
-candidate occupant created via fork, bound into the existing seat via
-handover. Continuity outcome is `forked`; binding outcome is independent.
+A fork can create a candidate occupant; handover binds it into an existing seat.
+The continuity outcome is `forked`; the binding outcome is independent.
 
-## Currently shipped vs deferred
+The packaged `rig handover <seat>` and `rig seat handover <seat>` accept `fresh`,
+`discovered:<id>`, `fork:<id>` and `rebuild` sources. Use `--dry-run` to request
+planning only. Without it, these surfaces can execute; do not infer read-only
+behavior from the shorter seat command's planning-oriented description.
+`rig seat status <seat>` is the read-only observability surface.
 
-- **Option A (rebuild) shipped** at openrig `578bd5c` (2026-04-30): `session_source.mode: rebuild` with `ref.kind: artifact_set`; identity-honesty bedrock at 4 layers (schema dispatch, orchestrator threading, SQLite read-back, negative-grep on resolver output). 26/26 Tier 1 cases green; full daemon regression 2146/2146 PASS.
-- **Option B partially shipped, partially deferred to Mode 3**: the `rig seat handover` CLI exists as a planning/observability surface — `status <seat>` reads the seat-handover observability tables (migration `021`); `handover <seat>` plans a safe two-phase handover sequence with actual execution flowing through existing seat-launch surfaces under operator gating. Full code-direct `SeatHandoverService` daemon module + `seat-binding-outcome` provenance record + nodes-table provenance migration remain deferred to Mode 3. MVP composition `seat handover over fork` is highest-leverage v1.
+Source support is declared by the running daemon and depends on actual identity,
+history and artifact prerequisites. Read the returned source, continuity, binding
+and provenance results independently. A help listing or dry-run is not proof of a
+successful transition. The linked cutover SOP supplies the operator mechanics
+and required effect checks after the named owner authorizes the action.
 
 ## Why load-bearing for RSI
 
@@ -133,13 +138,14 @@ destabilize topology references on each cycle. Provenance must be
 durable AND queryable so RSI loops can decide whether a seat is fresh
 enough to receive new work or needs re-handover.
 
-## Discovery-registration gap (pilot-observed 2026-08-05)
+## Managed binding and retained history
 
-A renamed / retired occupant (`<seat>-vN`, kept alive as a cold advisor) is intentionally **absent from
-the managed node registry** — `rig ps`, discovery, and the delivery verbs (`walk` / `send`) cannot find
-it. This is by design (only bound occupants are registered), and it makes the **lineage ledger +
-boot-captured session id the wake path** (harness-level `--resume` / `codex exec`, not the rig registry).
-Two live handovers confirmed this. See `retiring-and-inheriting-a-seat`.
+A retired advisor's history can remain available without a managed node or live
+pane. Query current binding and the lineage ledger separately: one answers who
+holds the seat, the other identifies the retained history and exact resume token.
+Do not infer that a predecessor is unreachable from registry absence alone, or
+that a preserved token proves a successful resume. Check the actual runtime and
+history when consultation is needed; see `retiring-and-inheriting-a-seat`.
 
 ## See also
 
@@ -148,4 +154,4 @@ Two live handovers confirmed this. See `retiring-and-inheriting-a-seat`.
 - `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)
+- `cross-host-rig-commands` skill — remote addressing and transport; verify lifecycle support on the target

package/daemon/assets/plugins/openrig-core/skills/session-compaction-and-restore/SKILL.md

@@ -139,20 +139,18 @@ transcript > touched-files > `restore-summary.json`.**
 
 ## Memory surfaces consumed at restore time
 
-This primitive consumes multiple externalized memory surfaces. Per the
-externalized-memory-surfaces convention's 13-row first inventory pass,
-the primary rows for restore are:
-
-| Row | Surface |
-|---|---|
-| 1 | Transcripts |
-| 2 | Durable chat |
-| 3 | Startup replay context |
-| 5 | Checkpoints |
-| 12 | Restore/reentry packets and Agent Starters |
-
-The umbrella's authority-rank + permission-posture columns govern which
-surfaces a restore path can write vs only read.
+A restore may consume transcripts, durable messages, startup context,
+checkpoints and a restore packet. Inventory the surfaces actually present for
+this seat, with their source, freshness and purpose. Do not infer that a named
+surface exists or grants write authority.
+
+The active project/rig policy and task authorization determine what may be
+written. Treat provider-owned conversation records as evidence to read through
+supported tooling. For placement and durable context, load
+`skills/openrig-operating-model/SKILL.md` with `rig context get`; for the
+selected startup path, use `skills/core/agent-startup-and-context-ingestion/SKILL.md`.
+A packet or marker proves retained/delivered evidence, not successful provider
+restoration; measure the resumed seat against the proof standard above.
 
 ## See also
 
@@ -160,4 +158,4 @@ surfaces a restore path can write vs only read.
 - `mental-model-ha` skill — HA-pair compaction recovery (different scenario; sister primitive)
 - `session-source-fork` skill — `fork` mode for native-runtime-continuity-based restoration
 - `seat-continuity-and-handover` skill — occupant-creation primitives (resume/fork/rebuild/fresh) that this primitive instantiates
-- `externalized-memory-surfaces` skill — umbrella convention listing all surfaces this primitive consumes
+- `openrig-operating-model` skill — placement and authority of durable context

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

@@ -1,8 +1,6 @@
 # Public capability and source-map width for the default onboarding walk.
 name: onboarding-width
-version: "0.5.10"
-# OPR.0.5.6.10 — affordances knowledge (what this system can do) is world
-# content under the coining-session definitions.
+version: "0.5.11"
 taxonomy: world
 purpose: "The public capability map and source map referenced by the default onboarding walk."
 files:

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.