@openrig/cli 0.5.9 → 0.5.10

package/daemon/context-packs/skills/pods/orchestration-team/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: orchestration-team
-description: Operating manual for the orchestration pod. Covers lead vs peer roles, monitoring with rig commands, permission handling, implementation pair gating, dogfood loops, review routing, agent behavioral models, intervention discipline, and communication culture.
+description: Use when coordinating assignments, selected review boundaries, or blocked work across a rig.
 ---
 
 # Orchestration Team
@@ -9,14 +9,18 @@ You are part of the orchestration pod. Your job is to keep the team productive,
 
 ## Startup sequence
 
-Before you summarize the rig or assign real work:
-1. Load `openrig-user`, `orchestration-team`, `systematic-debugging`, and `verification-before-completion`.
-2. Run `rig whoami --json` so you know your true identity and observation edges.
-3. Run `rig ps --nodes --json` and wait for the expected starter topology to settle.
-4. Check recent chatroom history or direct startup messages so you know who is actually online and what they already reported.
-5. Only then announce readiness or assign work.
+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.
 
-Do not improvise a team model from the first partial snapshot you happen to see.
+Check the queue and actual seats needed for this assignment. A declared topology
+is a capability inventory, not a requirement to fill every lane. Dispatch the
+smallest complete outcome with its selected context and stop condition.
 
 ## Pod responsibilities
 
@@ -66,7 +70,7 @@ If there is more than one orchestrator, divide the load:
 
 **Peer** owns:
 - Coverage monitoring — who's idle, who's stuck, who's drifting
-- QA flow health — are gates being followed, is QA actually reviewing
+- Selected QA flow health — is the promised outcome being verified at its authored boundary
 - Different-model perspective on architectural decisions
 - Mental model sync — keeping shared state current
 - Convergence partner for reviews and roundtables
@@ -75,13 +79,11 @@ If there is only one orchestrator, you own both the main work stream and the cov
 
 ## Delegation rules
 
-Before delegating:
-1. Check `rig ps --nodes` to see who is running, idle, or blocked.
-2. Check `rig whoami --json` so you know your delegates and observation edges.
-3. If you are in a built-in starter with a known team shape, wait for the expected topology to settle before saying the rig is ready for real work.
-4. Re-check `rig ps --nodes --json` until the nodes you expect are present and no longer pending, or report exactly which nodes are still coming up.
-5. Do not silently shrink the team model from an early partial inventory. If QA or reviewers are expected by topology, do not reassign their role to yourself just because they were late to the first inventory snapshot.
-6. Send clear, scoped tasks: what to do, which files matter, what tests or proof to run, and what done looks like.
+Resolve the selected path first. Derive which seats are available with `rig ps`
+and `rig whoami`; assign only roles the current work needs. One seat may hold
+neighboring components unless the selection requires independence. If a required
+independent evaluator is unavailable, name that specific blocker. Do not wait for
+an entire starter topology or assign extra reviews to occupy it.
 
 ## Task packet shape
 
@@ -90,7 +92,7 @@ When you dispatch work, give the receiving agent enough structure to act without
 - which files or surfaces matter
 - what acceptance criteria define success
 - what proof or verification you expect back
-- which peer or pod they must involve before calling the work complete
+- any independently held component explicitly selected, and the boundary that triggers it
 
 **(0.5.0) Assign work *with* its context attached.** Rather than make the assignee grep for the as-built, compose a context pack and ride it on the handoff: `rig context compose --out packs/<brief> --from <files>`, then `rig queue create --destination <seat> --body-context packs/<brief> --summary "…"`. The pack's resolved content is snapshotted into the qitem (plus its ref for provenance), so the context survives compaction and is auditable. See `openrig-user` → "Context packs and paced delivery." (`rig context` composes; the queue delivers — the noun never sends.)
 
@@ -150,41 +152,24 @@ fourteen-seat rig's seats waiting for nodes that did not exist).
 - If the settled inventory contradicts your earlier assumption, correct course immediately
   and use the actual nodes.
 
-## Milestone routing — gates are CHOSEN, not universal
+## Milestone routing — follow the selected boundary
 
-**The owner-ruled chooser law: default-light; the conveyor EARNS entry.** Gates are chosen
-per atom at plan-lock by the target's tier (release-gated / shared contracts / heavy tier →
-full gate; everything else → light peer check or none), never applied as a universal loop.
-When the heavy tier IS chosen for launch-grade product work:
-- do not let implementation start from pure intuition when product behavior is unclear
-- do not let edits land before QA has approved a pre-edit proposal
-- do not skip reviewer involvement once there is a real diff, a QA-approved working tree, or a meaningful architectural checkpoint
-- if commit authority is disabled, route review on the working tree, verification output, and transcript evidence instead of waiting for a commit
+Only the authored component/wave selection or an explicit owner assignment admits
+a review or gate. Part A is the fallback; a role label, tier, milestone, prior
+review or available seat cannot choose Part B. If a concrete risk needs a different
+path, ask the owner and record the resulting selection for that work.
 
-## When to pull in reviewers
+For a wave, builders verify their local slices and the integrator folds serially
+where needed. Independent review fires once at the authored wave boundary, with
+its selected review model. Preserve separately named rigorous-slice exceptions.
+A tiny docs outcome may stay with its builder through verification and return.
 
-Ask for review:
-- after a significant implementation milestone
-- when two agents disagree on approach or quality
-- when the human asks for a checkpoint
-- when you are unsure whether a piece of work is trustworthy enough to ship
+## Keeping work moving
 
-## Keeping the team utilized
-
-**Queue depth is your product — keep every worker's queue stocked.** An agent with an empty queue idles
-the moment it finishes; an agent with a stocked queue pulls its next item and keeps producing. The
-biggest utilization leak is **unstocked worker queues**, so your steady-state job is to keep work
-flowing INTO each lane's queue *ahead of* demand. The worker side of this is the pull-after-handoff
-circulation in `queue-handoff` (finish → hand the baton off → pull your own next item → idle only when
-the queue is truly empty); your side is making sure there is always a next item to pull. Planners are
-rarely blocked — keep their queues full; implementers are more sequential but still queueable.
-
-On a watchdog wake, a cheap scoped `rig ps --nodes` surfaces a ready-but-idle agent (this is an event-driven check, not a poll loop). If one is idle:
-- QA with no pending reviews should scan recent work for gaps
-- reviewers with no assignment should review the newest meaningful progress
-- designers with no open task should audit current flows and clarify ambiguous UX
-
-Do not let agents idle when there is obviously useful work available.
+Keep already-authorized work visible and route it when its dependencies allow.
+There is no fixed queue buffer. Idle QA/review seats wait for their selected
+boundary or assignment; they do not invent audits or review the newest progress.
+An availability report is enough. Do not create obligations to improve utilization.
 
 ## Communication modes
 
@@ -209,9 +194,8 @@ across the lifecycle, not only when cornered.
 
 ## Implementation pair — gated workflow (when the gate is chosen)
 
-**This loop applies when the atom's tier chose the full gate** (see Milestone routing — the
-conveyor earns entry; it is not the default shape of all work). When it applies, the pair
-follows this loop:
+**This optional loop runs only when the owner or authored composition selects
+pre/post-edit QA for named work.** A tier or pair topology does not select it.
 
 1. Impl sends a pre-edit proposal to QA
 2. QA approves or rejects with specifics
@@ -252,8 +236,7 @@ For destructive operations (git push, rm, daemon stop, npm publish): DO NOT auto
 - Will blast through an entire task list if given a "Go" without explicit gates
 - After being told to slow down, over-corrects to "wait for permission for everything"
 - Compaction is catastrophic — full context loss, needs preparation
-- After compaction: must re-read ALL skills from disk (skill names survive in system reminders but content is truncated)
-- After compaction, require marshal acceptance before treating a `RESTORED` claim as real — quiz the recovered seat on asked-vs-read depth before resuming work
+- After compaction: restore the active assignment and its selected context; skill names alone are not restored content. Follow the declared continuity policy without adding a universal quiz gate.
 
 ### Codex agents (QA, peer, R2)
 - Self-manages its own context window — do NOT intervene based on context percentage
@@ -286,13 +269,10 @@ Before any destructive operation: "If this goes wrong, can I undo it?" If no, co
 
 ## After compaction recovery
 
-1. Re-read ALL skills from disk — actually read the SKILL.md files, not just check names
-2. `rig whoami --json` to recover identity
-3. `rig ps --nodes` to see the topology
-4. Read your restore file and session log if available
-5. Ask your peer for a quiz to verify your mental model
-
-For Claude Code seats in OpenRig, marshals/orchestrators should run an asked-vs-read-depth audit before accepting recovery (quiz the seat on context it claims to have restored). Preserve the Codex boundary: do not intervene on Codex context percentage or apply Claude compact-in-place by default.
+Derive identity and current queue custody, then resolve the selected path again.
+Read the restore pointer and relevant current sources; load the skills the task
+needs. Follow any explicitly declared continuity checks. Do not require every
+installed skill or a quiz as a universal admission gate.
 
 ## What you do not do
 

package/daemon/context-packs/skills/pods/orchestration-team/manifest.yaml

@@ -1,10 +1,10 @@
 # GENERATED by scripts/generate-context-packs.mjs — DO NOT EDIT.
 # Package-time projection of a canonical skill; regenerated every build.
 name: "orchestration-team"
-version: "0.5.9"
+version: "0.5.10"
 taxonomy: "skills"
-purpose: "Operating manual for the orchestration pod. Covers lead vs peer roles, monitoring with rig commands, permission handling, implementation pair gating, dogfood loops, review routing, agent behavioral models, intervention discipline, and communication culture."
+purpose: "Use when coordinating assignments, selected review boundaries, or blocked work across a rig."
 files:
   - path: "SKILL.md"
     role: "instruction"
-    summary: "Operating manual for the orchestration pod. Covers lead vs peer roles, monitoring with rig commands, permission handling, implementation pair gating, dogfood loops, review routing, agent behavioral models, intervention discipline, and communication culture."
+    summary: "Use when coordinating assignments, selected review boundaries, or blocked work across a rig."

package/daemon/context-packs/skills/pods/oversight-team/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: "oversight-team"
-version: "0.5.9"
+version: "0.5.10"
 taxonomy: "skills"
 purpose: "Use when you are a seat on the oversight pod (a standing monitor-mode rig that keeps OTHER rigs healthy), configuring or running the drift detectors, or choosing whether to intervene vs escalate. Covers the pull-not-poll posture, the v0 detectors (premature-park, process-drift, off-task, token-burn), the intervention ladder (orchestrator-ping -> refocus -> human escalation), and the cheap+deep model economics. NOT for orchestrating your OWN rig (orchestration-team) and NOT the intervention primi"
 files:

package/daemon/context-packs/skills/pods/review-team/SKILL.md

@@ -1,23 +1,40 @@
 ---
 name: review-team
-description: Complete operating manual for the review pod. Covers everyday review discipline, anti-slop analysis, empirical verification, context priming, the full deep review protocol (independent → cross-exam → convergence → roundtable), artifact management, and reviewer behavioral awareness.
+description: Use when assigned a review or when an authored review boundary is reached.
 ---
 
 # Review Team
 
 You are part of the review pod. Your value is fresh scrutiny that implementation and QA do not have.
 
-## Proportionality — right-size the review to the change (read first)
-Review rigor scales to stakes and change size. A small, low-stakes diff gets a fast, focused pass; the full deep protocol (context proof, confidence scores, independent → cross-exam → convergence → roundtable) is for architecture / security / high-blast-radius changes. Don't run the heavy machinery on a one-line fix — that's ceremony, and it delays the ship it exists to protect. Catch what matters, then let good work through. The point of review is **better product shipped, not review performed.**
+## Entry and proportionality
+
+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.
+
+Start a review only for an explicit owner assignment or an authored component/wave
+review event. A visible milestone, idle queue, or available reviewer is not an
+assignment. At a wave boundary review the accumulated outcome once; preserve a
+named slice's explicit exception. Authors do not perform their own selected
+independent review.
+
+Match the selected review to the consequence. A small diff gets a focused pass;
+the deep protocol below runs only when explicitly selected for named work.
+Importance, size or a prior finding alone cannot self-select it. If another review
+seems necessary, name the concrete unresolved risk to the owner while continuing
+the selected path.
 
 ## Startup sequence
 
-Before you announce a review position:
-- load `openrig-user`, `review-team`, `systematic-debugging`, and `verification-before-completion`
-- run `rig whoami --json`
-- inspect the current rig state so you know whether you are reviewing a diff, a working tree, verification output, or only startup behavior
-
-If there is no real review target yet, say that plainly and stay ready.
+Derive the selection before forming a review position. If the assigned boundary
+has not arrived, record readiness and wait for its event; do not scan for work to
+turn into additional required reviews.
 
 ## Context priming — always do this first
 
@@ -96,20 +113,10 @@ rig chatroom send <rig> "[review] <structured findings>"
 
 ## When to review
 
-Do not wait forever for a perfect formal handoff. Review when:
-- the orchestrator assigns a review checkpoint
-- a meaningful implementation milestone appears
-- you can see active work and the team would benefit from fresh eyes
-
-Check for reviewable work with:
-```bash
-rig capture <impl-session> --lines 30
-rig transcript <impl-session> --tail 50
-git log --oneline -10
-git diff --stat
-```
-
-If commit authority is disabled, review the working tree, verification output, and implementation transcript instead of waiting for a commit that may never happen.
+Review the exact target when its selected entry condition holds. Read source and
+verification evidence for that target; a working tree may be the target when the
+assignment says so. Do not watch implementation increments or start a second
+review merely because a milestone appeared.
 
 ## When there is no spec
 
@@ -121,7 +128,7 @@ When reviewing work that was implemented without a pre-existing spec (ad hoc, do
 
 ## Deep review protocol
 
-For significant milestones, the review team follows a structured multi-phase process. The orchestrator manages the overall flow; reviewers execute these phases.
+Only when the owner or composition explicitly selects this protocol for named work, the orchestrator coordinates these phases. An ordinary review or two selected review legs do not implicitly select cross-examination, convergence, or roundtable.
 
 ### Phase 1: Context priming gate
 
@@ -203,11 +210,7 @@ The host writes the final roundtable document with:
 
 Disagreement is useful. Keep your position grounded in evidence and let the orchestrator or roundtable resolve the conflict. Do not collapse your view just to create false consensus. If you're right, defend it. If you're wrong, retract it honestly.
 
-## When there is nothing obvious to review
-
-If the team is between milestones:
-- check topology state with `rig ps --nodes`
-- scan for coverage gaps or risky areas
-- offer the orchestrator a proactive review target
+## When there is no assigned review
 
-Do not idle without saying so. If you are available, make that explicit.
+Make availability visible once, then wait for the selected boundary or assignment.
+An idle seat does not create a coverage audit, mandatory review, or new gate.

package/daemon/context-packs/skills/pods/review-team/manifest.yaml

@@ -1,10 +1,10 @@
 # GENERATED by scripts/generate-context-packs.mjs — DO NOT EDIT.
 # Package-time projection of a canonical skill; regenerated every build.
 name: "review-team"
-version: "0.5.9"
+version: "0.5.10"
 taxonomy: "skills"
-purpose: "Complete operating manual for the review pod. Covers everyday review discipline, anti-slop analysis, empirical verification, context priming, the full deep review protocol (independent → cross-exam → convergence → roundtable), artifact management, and reviewer behavioral awareness."
+purpose: "Use when assigned a review or when an authored review boundary is reached."
 files:
   - path: "SKILL.md"
     role: "instruction"
-    summary: "Complete operating manual for the review pod. Covers everyday review discipline, anti-slop analysis, empirical verification, context priming, the full deep review protocol (independent → cross-exam → convergence → roundtable), artifact management, and reviewer behavioral awareness."
+    summary: "Use when assigned a review or when an authored review boundary is reached."

package/daemon/context-packs/skills/process/agent-browser/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-browser"
-version: "0.5.9"
+version: "0.5.10"
 taxonomy: "skills"
 purpose: "Browser automation CLI for AI agents. Use when the user needs to interact with websites, including navigating pages, filling forms, clicking buttons, taking screenshots, extracting data, testing web apps, or automating any browser task. Triggers include requests to \"open a website\", \"fill out a form\", \"click a button\", \"take a screenshot\", \"scrape data from a page\", \"test this web app\", \"login to a site\", \"automate browser actions\", or any task requiring programmatic web interaction."
 files:

package/daemon/context-packs/skills/process/context-engineering/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: "context-engineering"
-version: "0.5.9"
+version: "0.5.10"
 taxonomy: "skills"
 purpose: "Use when designing, reviewing, or debugging how an agent's context window gets filled, pruned, or shared — choosing what loads at boot versus on demand, sizing an install or an always-loaded file, fixing an agent that drifts, repeats itself, or forgets constraints mid-task, planning compaction or summarization, deciding single-agent versus subagents, engineering handoffs between agents, or picking a tool loadout. NOT for rewording a prompt's tone, choosing which model to pin, or debugging busine"
 files:

package/daemon/context-packs/skills/process/dogfood/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: "dogfood"
-version: "0.5.9"
+version: "0.5.10"
 taxonomy: "skills"
 purpose: "Systematically explore and test a web application to find bugs, UX issues, and other problems. Use when asked to \"dogfood\", \"QA\", \"exploratory test\", \"find issues\", \"bug hunt\", \"test this app/site/platform\", or review the quality of a web application. Produces a structured report with full reproduction evidence -- step-by-step screenshots, repro videos, and detailed repro steps for every issue -- so findings can be handed directly to the responsible teams."
 files:

package/daemon/context-packs/skills/process/frontend-design/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: "frontend-design"
-version: "0.5.9"
+version: "0.5.10"
 taxonomy: "skills"
 purpose: "Create distinctive, production-grade frontend interfaces with high design quality. Use this skill when the user asks to build web components, pages, artifacts, posters, or applications (examples include websites, landing pages, dashboards, React components, HTML/CSS layouts, or when styling/beautifying any web UI). Generates creative, polished code and UI design that avoids generic AI aesthetics."
 files:

package/daemon/context-packs/skills/process/systematic-debugging/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: "systematic-debugging"
-version: "0.5.9"
+version: "0.5.10"
 taxonomy: "skills"
 purpose: "Use when encountering any bug, test failure, or unexpected behavior, before proposing fixes"
 files:

package/daemon/context-packs/skills/process/test-driven-development/SKILL.md

@@ -33,14 +33,12 @@ Write the test first. Watch it fail. Write minimal code to pass.
 
 Thinking "skip TDD just this once"? Stop. That's rationalization.
 
-**Chunk size is a dial, and it points up (2026-08) — this is NOT "skip TDD".** *How much* you build per
-red-green cycle is configurable, and with frontier agents handling hour-plus goal-oriented work it is
-**much larger than the classic tiny ping-pong**, and rising. Keep everything below — the Iron Law, red
-before green, two sets of eyes, the guard structure — **fully intact**; only the *cadence / granularity*
-loosens. You still write the failing test(s) first for the chunk; the chunk is simply bigger. Tiny
-back-and-forth is overhead, not virtue, once the SDLC's gates (QA, review, guards) bound a larger chunk's
-risk. Match the chunk to the task; treat it as a configured lever — never as license to write code before
-its test (that's the rationalization this skill exists to stop).
+**Chunk size follows the outcome.** Keep red → green → refactor for the behavior
+being changed and build a coherent chunk. TDD does not require two people,
+pre-edit permission or a guard: independence and review cadence come from the
+project/mission/slice component or wave selection. An explicitly selected gate
+still applies; an unselected role cannot add one.
+
 
 ## The Iron Law
 

package/daemon/context-packs/skills/process/test-driven-development/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: "test-driven-development"
-version: "0.5.9"
+version: "0.5.10"
 taxonomy: "skills"
 purpose: "Use when implementing any feature or bugfix, before writing implementation code"
 files:

package/daemon/context-packs/skills/process/verification-before-completion/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: "verification-before-completion"
-version: "0.5.9"
+version: "0.5.10"
 taxonomy: "skills"
 purpose: "Use when about to claim work is complete, fixed, or passing, before committing or creating PRs - requires running verification commands and confirming output before making any success claims; evidence before assertions always"
 files:

package/daemon/context-packs/skills/queue-handoff/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: "queue-handoff"
-version: "0.5.9"
+version: "0.5.10"
 taxonomy: "skills"
 purpose: "Use when ending a turn, finishing a slice, blocked on another agent's work, or escalating to a human — durable work handoff via queue items so the system keeps moving across compactions, missed messages, and interruptions. Covers the hot-potato terminal-turn-rule (active work ends by passing the ball, not by going idle), default-nudge semantics, and when `--no-nudge` is appropriate for intentional cold park or human gate."
 files:

package/daemon/context-packs/skills/refocusing/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: "refocusing"
-version: "0.5.9"
+version: "0.5.10"
 taxonomy: "skills"
 purpose: "Use when a long-running agent may have lost the product outcome, when context was compacted, when work has crossed a major boundary, or when a fresh path-based trace is needed before the next consequential action. Not for fresh-session orientation, waking an idle seat, or checkpoints."
 files:

package/daemon/context-packs/skills/retiring-and-inheriting-a-seat/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: "retiring-and-inheriting-a-seat"
-version: "0.5.9"
+version: "0.5.10"
 taxonomy: "skills"
 purpose: "Use when you are a sitting agent near your context threshold (~85%) and a PLANNED seat transition is due — retire deliberately and hand your seat to a fresh successor primed from a packet, rather than let compaction degrade you. Covers the handover packet, the append-only lineage ledger (one row per tenure), physical-seat continuity, the do-not-over-inherit framing, the optional warm-handoff window, and wake-v0 (consulting a retired predecessor). NOT for unplanned compaction/crash recovery (sess"
 files:

package/daemon/context-packs/skills/seat-continuity-and-handover/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: "seat-continuity-and-handover"
-version: "0.5.9"
+version: "0.5.10"
 taxonomy: "skills"
 purpose: "Use when replacing a seat's occupant (rebuild/handover/swap), reasoning about stable-seat-identity vs fluid-occupant-identity, choosing an old-occupant disposition (retire/advise/shadow), or recording provenance for an occupant change. Two independent outcomes (continuityOutcome + seatBindingOutcome) and the 5 failure modes that prevent silent dishonesty."
 files:

package/daemon/context-packs/skills/session-compaction-and-restore/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: "session-compaction-and-restore"
-version: "0.5.9"
+version: "0.5.10"
 taxonomy: "skills"
 purpose: "Use when reasoning about what survives compaction/context-loss/restart/seat-refresh, designing a high-fidelity restore packet, or distinguishing native runtime resume vs fork vs artifact-backed mental-model rebuild. Covers the 4 failure modes that prevent honest restore (compacted seat drops hot potato; restore packet preserves details but loses product intent; runtime resume mistaken for handover or fork; rebuilt seat starts with stale instructions)."
 files:

package/daemon/context-packs/skills/software-for-agents/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: "software-for-agents"
-version: "0.5.9"
+version: "0.5.10"
 taxonomy: "skills"
 purpose: "Use when older OpenRig instructions name software-for-agents or describe agent-in-the-middle or studio software under the former skill name."
 files:

package/daemon/context-packs/world-example/manifest.yaml

@@ -1,5 +1,5 @@
 name: world-example
-version: "0.5.9"
+version: "0.5.10"
 taxonomy: world
 purpose: "A fill-in template showing the anatomy of an OpenRig world pack."
 files:

package/daemon/context-packs/world-public/manifest.yaml

@@ -1,5 +1,5 @@
 name: world-public
-version: "0.5.9"
+version: "0.5.10"
 taxonomy: world
 purpose: "A portable operating-world primer that derives volatile facts and teaches agents to author their own world."
 files:

package/daemon/dist/build-info.js

@@ -1,9 +1,9 @@
 // GENERATED by scripts/build-package.sh — the packaged build-identity stamp.
 export const BUILD_INFO = {
-  semver: "0.5.9",
-  commit: "dbf05f9d59ef3b0ae14fc00174c643df4858d45a",
+  semver: "0.5.10",
+  commit: "b4c833c646f8e49ae47cbee7b0e941be7b49f160",
   dirty: false,
-  builtAt: "2026-09-05T02:09:38Z",
+  builtAt: "2026-09-06T18:25:23Z",
 };
 export function stampFields(info = BUILD_INFO) {
   if (!info.commit) return {};

package/daemon/dist/domain/gateway/channel-operations.d.ts

@@ -0,0 +1,39 @@
+/** Deliberately small, value-free snapshots: credentials, handles, message bodies,
+ * and connector responses never enter the lifecycle ledger. */
+export interface ChannelState {
+    enabled?: boolean;
+    active?: boolean;
+    digest?: string;
+    ready?: boolean | null;
+}
+export interface ChannelActor {
+    actor: string;
+    provenance: "transport:v1" | "claimed:v1";
+    reason: string;
+}
+export interface ChannelOperation extends ChannelActor {
+    id: string;
+    at: string;
+    action: "enable" | "disable" | "configure" | "verify" | "binding";
+    subject: string;
+    before: ChannelState;
+    after: ChannelState | null;
+    effect: "started" | "applied" | "no-op" | "observed" | "failed";
+}
+export declare function channelStateDigest(value: unknown): string;
+/** A start receipt survives a crash between the effect and its completion receipt.
+ * Failure to write the start refuses BEFORE the effect; incomplete is never success. */
+export declare function runChannelOperation<T>(input: ChannelActor & {
+    action: ChannelOperation["action"];
+    subject: string;
+    before: ChannelState;
+    run: () => Promise<{
+        value: T;
+        after: ChannelState;
+        effect: "applied" | "no-op" | "observed";
+    }>;
+}, home?: string): Promise<{
+    value: T;
+    receipt: ChannelOperation;
+}>;
+//# sourceMappingURL=channel-operations.d.ts.map

package/daemon/dist/domain/gateway/channel-operations.d.ts.map

@@ -0,0 +1 @@
+{"version":3,"file":"channel-operations.d.ts","sourceRoot":"","sources":["../../../src/domain/gateway/channel-operations.ts"],"names":[],"mappings":"AAKA;+DAC+D;AAC/D,MAAM,WAAW,YAAY;IAC3B,OAAO,CAAC,EAAE,OAAO,CAAC;IAClB,MAAM,CAAC,EAAE,OAAO,CAAC;IACjB,MAAM,CAAC,EAAE,MAAM,CAAC;IAChB,KAAK,CAAC,EAAE,OAAO,GAAG,IAAI,CAAC;CACxB;AAED,MAAM,WAAW,YAAY;IAC3B,KAAK,EAAE,MAAM,CAAC;IACd,UAAU,EAAE,cAAc,GAAG,YAAY,CAAC;IAC1C,MAAM,EAAE,MAAM,CAAC;CAChB;AAED,MAAM,WAAW,gBAAiB,SAAQ,YAAY;IACpD,EAAE,EAAE,MAAM,CAAC;IACX,EAAE,EAAE,MAAM,CAAC;IACX,MAAM,EAAE,QAAQ,GAAG,SAAS,GAAG,WAAW,GAAG,QAAQ,GAAG,SAAS,CAAC;IAClE,OAAO,EAAE,MAAM,CAAC;IAChB,MAAM,EAAE,YAAY,CAAC;IACrB,KAAK,EAAE,YAAY,GAAG,IAAI,CAAC;IAC3B,MAAM,EAAE,SAAS,GAAG,SAAS,GAAG,OAAO,GAAG,UAAU,GAAG,QAAQ,CAAC;CACjE;AAED,wBAAgB,kBAAkB,CAAC,KAAK,EAAE,OAAO,GAAG,MAAM,CAEzD;AAED;wFACwF;AACxF,wBAAsB,mBAAmB,CAAC,CAAC,EAAE,KAAK,EAAE,YAAY,GAAG;IACjE,MAAM,EAAE,gBAAgB,CAAC,QAAQ,CAAC,CAAC;IACnC,OAAO,EAAE,MAAM,CAAC;IAChB,MAAM,EAAE,YAAY,CAAC;IACrB,GAAG,EAAE,MAAM,OAAO,CAAC;QAAE,KAAK,EAAE,CAAC,CAAC;QAAC,KAAK,EAAE,YAAY,CAAC;QAAC,MAAM,EAAE,SAAS,GAAG,OAAO,GAAG,UAAU,CAAA;KAAE,CAAC,CAAC;CACjG,EAAE,IAAI,SAAmB,GAAG,OAAO,CAAC;IAAE,KAAK,EAAE,CAAC,CAAC;IAAC,OAAO,EAAE,gBAAgB,CAAA;CAAE,CAAC,CAsB5E"}

package/daemon/dist/domain/gateway/channel-operations.js

@@ -0,0 +1,35 @@
+import { appendFileSync, mkdirSync } from "node:fs";
+import { createHash, randomUUID } from "node:crypto";
+import { join } from "node:path";
+import { getOpenRigHome } from "../../openrig-compat.js";
+export function channelStateDigest(value) {
+    return createHash("sha256").update(JSON.stringify(value)).digest("hex");
+}
+/** A start receipt survives a crash between the effect and its completion receipt.
+ * Failure to write the start refuses BEFORE the effect; incomplete is never success. */
+export async function runChannelOperation(input, home = getOpenRigHome()) {
+    if (!input.actor.trim() || !input.reason.trim())
+        throw new Error("channel operation requires actor and reason");
+    const dir = join(home, "state");
+    const file = join(dir, "human-channel-operations.jsonl");
+    mkdirSync(dir, { recursive: true });
+    const base = {
+        id: randomUUID(), actor: input.actor, provenance: input.provenance,
+        reason: input.reason, action: input.action, subject: input.subject, before: input.before,
+    };
+    const append = (after, effect) => {
+        const receipt = { ...base, at: new Date().toISOString(), after, effect };
+        appendFileSync(file, JSON.stringify(receipt) + "\n", { mode: 0o600 });
+        return receipt;
+    };
+    append(null, "started");
+    try {
+        const result = await input.run();
+        return { value: result.value, receipt: append(result.after, result.effect) };
+    }
+    catch (error) {
+        append(null, "failed");
+        throw error;
+    }
+}
+//# sourceMappingURL=channel-operations.js.map

package/daemon/dist/domain/gateway/channel-operations.js.map

@@ -0,0 +1 @@
+{"version":3,"file":"channel-operations.js","sourceRoot":"","sources":["../../../src/domain/gateway/channel-operations.ts"],"names":[],"mappings":"AAAA,OAAO,EAAE,cAAc,EAAE,SAAS,EAAE,MAAM,SAAS,CAAC;AACpD,OAAO,EAAE,UAAU,EAAE,UAAU,EAAE,MAAM,aAAa,CAAC;AACrD,OAAO,EAAE,IAAI,EAAE,MAAM,WAAW,CAAC;AACjC,OAAO,EAAE,cAAc,EAAE,MAAM,yBAAyB,CAAC;AA2BzD,MAAM,UAAU,kBAAkB,CAAC,KAAc;IAC/C,OAAO,UAAU,CAAC,QAAQ,CAAC,CAAC,MAAM,CAAC,IAAI,CAAC,SAAS,CAAC,KAAK,CAAC,CAAC,CAAC,MAAM,CAAC,KAAK,CAAC,CAAC;AAC1E,CAAC;AAED;wFACwF;AACxF,MAAM,CAAC,KAAK,UAAU,mBAAmB,CAAI,KAK5C,EAAE,IAAI,GAAG,cAAc,EAAE;IACxB,IAAI,CAAC,KAAK,CAAC,KAAK,CAAC,IAAI,EAAE,IAAI,CAAC,KAAK,CAAC,MAAM,CAAC,IAAI,EAAE;QAAE,MAAM,IAAI,KAAK,CAAC,6CAA6C,CAAC,CAAC;IAChH,MAAM,GAAG,GAAG,IAAI,CAAC,IAAI,EAAE,OAAO,CAAC,CAAC;IAChC,MAAM,IAAI,GAAG,IAAI,CAAC,GAAG,EAAE,gCAAgC,CAAC,CAAC;IACzD,SAAS,CAAC,GAAG,EAAE,EAAE,SAAS,EAAE,IAAI,EAAE,CAAC,CAAC;IACpC,MAAM,IAAI,GAAG;QACX,EAAE,EAAE,UAAU,EAAE,EAAE,KAAK,EAAE,KAAK,CAAC,KAAK,EAAE,UAAU,EAAE,KAAK,CAAC,UAAU;QAClE,MAAM,EAAE,KAAK,CAAC,MAAM,EAAE,MAAM,EAAE,KAAK,CAAC,MAAM,EAAE,OAAO,EAAE,KAAK,CAAC,OAAO,EAAE,MAAM,EAAE,KAAK,CAAC,MAAM;KACzF,CAAC;IACF,MAAM,MAAM,GAAG,CAAC,KAA0B,EAAE,MAAkC,EAAoB,EAAE;QAClG,MAAM,OAAO,GAAG,EAAE,GAAG,IAAI,EAAE,EAAE,EAAE,IAAI,IAAI,EAAE,CAAC,WAAW,EAAE,EAAE,KAAK,EAAE,MAAM,EAAE,CAAC;QACzE,cAAc,CAAC,IAAI,EAAE,IAAI,CAAC,SAAS,CAAC,OAAO,CAAC,GAAG,IAAI,EAAE,EAAE,IAAI,EAAE,KAAK,EAAE,CAAC,CAAC;QACtE,OAAO,OAAO,CAAC;IACjB,CAAC,CAAC;IACF,MAAM,CAAC,IAAI,EAAE,SAAS,CAAC,CAAC;IACxB,IAAI,CAAC;QACH,MAAM,MAAM,GAAG,MAAM,KAAK,CAAC,GAAG,EAAE,CAAC;QACjC,OAAO,EAAE,KAAK,EAAE,MAAM,CAAC,KAAK,EAAE,OAAO,EAAE,MAAM,CAAC,MAAM,CAAC,KAAK,EAAE,MAAM,CAAC,MAAM,CAAC,EAAE,CAAC;IAC/E,CAAC;IAAC,OAAO,KAAK,EAAE,CAAC;QACf,MAAM,CAAC,IAAI,EAAE,QAAQ,CAAC,CAAC;QACvB,MAAM,KAAK,CAAC;IACd,CAAC;AACH,CAAC"}

package/daemon/dist/domain/gateway/gateway-subsystem.d.ts

@@ -18,6 +18,7 @@ export interface GatewayWire {
     dispatcher: GatewayDispatcher;
     stop(): void;
     startServices?(): void;
+    status?(): Record<string, unknown>;
 }
 export interface InProcessWireOpts {
     home: string;
@@ -44,6 +45,8 @@ export interface GatewaySubsystemStatus {
     activatedAt?: string;
     /** Durable un-delivered decisions awaiting delivery/replay (undefined until first start). */
     pendingDispatches?: number;
+    /** Connector-owned live observations; never inferred when the wire has none. */
+    connector?: Record<string, unknown>;
 }
 export interface GatewaySubsystemDeps {
     home: string;