@openrig/cli 0.5.9 → 0.5.11

package/daemon/specs/agents/shared/skills/process/test-driven-development/SKILL.md

@@ -4,8 +4,8 @@ description: Use when implementing any feature or bugfix, before writing impleme
 metadata:
   openrig:
     vendored_from: "Obra Superpowers (https://github.com/obra/superpowers)"
-    vendoring_pattern: vendored-as-is
-    last_upstream_check: "2026-05-13 (diff against plugin source pulled 2026-05-11 = identical)"
+    vendoring_pattern: modify-the-file
+    last_upstream_check: "2026-05-13 (historical upstream comparison; local scope and preservation adaptations made since)"
 ---
 
 # Test-Driven Development (TDD)
@@ -20,43 +20,41 @@ Write the test first. Watch it fail. Write minimal code to pass.
 
 ## When to Use
 
-**Always:**
+**Use test-first for selected behavior where regression risk warrants it:**
 - New features
 - Bug fixes
 - Refactoring
 - Behavior changes
 
-**Exceptions (ask your human partner):**
+**Choose proportionate verification for work such as:**
 - Throwaway prototypes
 - Generated code
 - Configuration files
 
-Thinking "skip TDD just this once"? Stop. That's rationalization.
+Resolve the task's selected project/mission/slice procedure first. A required
+TDD step remains required within that scope; changing it needs the authority
+named by that selection. Outside it, choose verification that can detect the
+failure without adding a human approval ritual. The procedure below describes
+TDD when selected, not a completion gate for every kind of work.
 
-**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
+
+## Test-First Contract for Selected Behavior
 
 ```
-NO PRODUCTION CODE WITHOUT A FAILING TEST FIRST
+Selected TDD behavior: observe the expected failure before implementing the fix.
 ```
 
-Write code before the test? Delete it. Start over.
-
-**No exceptions:**
-- Don't keep it as "reference"
-- Don't "adapt" it while writing tests
-- Don't look at it
-- Delete means delete
-
-Implement fresh from tests. Period.
+Already wrote the implementation? Preserve existing and others' bytes. Establish
+the failing baseline in an isolated copy or by reversibly setting aside only
+your owned change, then implement from the behavioral test. This skill grants
+no authority to delete code. If a failing baseline cannot be demonstrated,
+record that limit and follow the selected procedure; do not call tests-after TDD.
 
 ## Red-Green-Refactor
 
@@ -126,7 +124,7 @@ Vague name, tests mock not code
 
 ### Verify RED - Watch It Fail
 
-**MANDATORY. Never skip.**
+**Required to establish RED in the selected TDD cycle.**
 
 ```bash
 npm test path/to/test.test.ts
@@ -181,7 +179,7 @@ Don't add features, refactor other code, or "improve" beyond the test.
 
 ### Verify GREEN - Watch It Pass
 
-**MANDATORY.**
+**Required to establish GREEN in the selected TDD cycle.**
 
 ```bash
 npm test path/to/test.test.ts
@@ -239,13 +237,11 @@ Manual testing is ad-hoc. You think you tested everything but:
 
 Automated tests are systematic. They run the same way every time.
 
-**"Deleting X hours of work is wasteful"**
+**"I already spent X hours on the implementation"**
 
-Sunk cost fallacy. The time is already gone. Your choice now:
-- Delete and rewrite with TDD (X more hours, high confidence)
-- Keep it and add tests after (30 min, low confidence, likely bugs)
-
-The "waste" is keeping code you can't trust. Working code without real tests is technical debt.
+Time spent does not prove behavior. Preserve the work and demonstrate that the
+test detects the missing behavior on a baseline without the owned change.
+Then verify the implementation against it. Report the actual sequence honestly.
 
 **"TDD is dogmatic, being pragmatic means adapting"**
 
@@ -269,21 +265,24 @@ Tests-first force edge case discovery before implementing. Tests-after verify yo
 
 ## Common Rationalizations
 
+These challenges apply within selected TDD work, not to an authorized choice
+of another verification method.
+
 | Excuse | Reality |
 |--------|---------|
-| "Too simple to test" | Simple code breaks. Test takes 30 seconds. |
+| "Too simple to test" | Simplicity alone does not waive a selected behavioral check. |
 | "I'll test after" | Tests passing immediately prove nothing. |
 | "Tests after achieve same goals" | Tests-after = "what does this do?" Tests-first = "what should this do?" |
 | "Already manually tested" | Ad-hoc ≠ systematic. No record, can't re-run. |
-| "Deleting X hours is wasteful" | Sunk cost fallacy. Keeping unverified code is technical debt. |
-| "Keep as reference, write tests first" | You'll adapt it. That's testing after. Delete means delete. |
-| "Need to explore first" | Fine. Throw away exploration, start with TDD. |
+| "Already spent X hours" | Time spent is not evidence; preserve the work and prove the failing baseline. |
+| "Keep as reference, write tests first" | Tests derived from the implementation risk repeating its assumptions; use the required behavior and a failing baseline. |
+| "Need to explore first" | Keep exploration separate from the implementation and begin the selected TDD cycle when the behavior is understood. |
 | "Test hard = design unclear" | Listen to test. Hard to test = hard to use. |
 | "TDD will slow me down" | TDD faster than debugging. Pragmatic = test-first. |
 | "Manual test faster" | Manual doesn't prove edge cases. You'll re-test every change. |
 | "Existing code has no tests" | You're improving it. Add tests for existing code. |
 
-## Red Flags - STOP and Start Over
+## Red Flags in Selected TDD Work
 
 - Code before test
 - Test after implementation
@@ -295,11 +294,13 @@ Tests-first force edge case discovery before implementing. Tests-after verify yo
 - "Tests after achieve the same purpose"
 - "It's about spirit not ritual"
 - "Keep as reference" or "adapt existing code"
-- "Already spent X hours, deleting is wasteful"
+- "Already spent X hours, so verification can wait"
 - "TDD is dogmatic, I'm being pragmatic"
 - "This is different because..."
 
-**All of these mean: Delete code. Start over with TDD.**
+Check whether the claimed RED → GREEN sequence actually happened. Repair the
+missing evidence using the preservation rule above; these signals never
+authorize deleting existing work.
 
 ## Example: Bug Fix
 
@@ -340,9 +341,9 @@ Extract validation for multiple fields if needed.
 
 ## Verification Checklist
 
-Before marking work complete:
+Before claiming the selected TDD work complete:
 
-- [ ] Every new function/method has a test
+- [ ] Tests cover the selected behavioral outcomes
 - [ ] Watched each test fail before implementing
 - [ ] Each test failed for expected reason (feature missing, not typo)
 - [ ] Wrote minimal code to pass each test
@@ -351,22 +352,25 @@ Before marking work complete:
 - [ ] Tests use real code (mocks only if unavoidable)
 - [ ] Edge cases and errors covered
 
-Can't check all boxes? You skipped TDD. Start over.
+An unmet selected check remains visible. Address it or obtain the disposition
+required by the selected procedure; do not turn this checklist into a gate on
+unselected work or erase code to make the history look test-first.
 
 ## When Stuck
 
 | Problem | Solution |
 |---------|----------|
-| Don't know how to test | Write wished-for API. Write assertion first. Ask your human partner. |
+| Don't know how to test | Write the desired API and assertion first. Consult the relevant peer or work owner if the behavior is unclear. |
 | Test too complicated | Design too complicated. Simplify interface. |
 | Must mock everything | Code too coupled. Use dependency injection. |
 | Test setup huge | Extract helpers. Still complex? Simplify design. |
 
 ## Debugging Integration
 
-Bug found? Write failing test reproducing it. Follow TDD cycle. Test proves fix and prevents regression.
+For a bug in selected TDD scope, write a failing test reproducing it. Follow the
+TDD cycle to demonstrate the fix and prevent regression.
 
-Never fix bugs without a test.
+Outside that scope, choose a proportionate regression check and retain its evidence.
 
 ## Testing Anti-Patterns
 
@@ -378,8 +382,9 @@ When adding mocks or test utilities, read @testing-anti-patterns.md to avoid com
 ## Final Rule
 
 ```
-Production code → test exists and failed first
-Otherwise → not TDD
+Selected TDD behavior → test exists and failed first
+Otherwise → do not claim a test-first sequence
 ```
 
-No exceptions without your human partner's permission.
+Honor explicitly selected gates and their decision owner. This skill adds no
+universal human permission step, deletion authority or gate on unselected work.

package/daemon/specs/agents/shared/skills/process/verification-before-completion/SKILL.md

@@ -4,7 +4,7 @@ description: Use when about to claim work is complete, fixed, or passing, before
 metadata:
   openrig:
     vendored_from: "Obra Superpowers (https://github.com/obra/superpowers)"
-    vendoring_pattern: vendored-as-is
+    vendoring_pattern: modify-the-file
     last_upstream_check: "2026-05-13 (diff against plugin source pulled 2026-05-11 = identical)"
 ---
 
@@ -116,10 +116,10 @@ Running a verification is necessary but not sufficient: a check can exit clean a
 
 - **Assert on CONTENT, never shape or count.** Output that *looks* like success — a non-zero count, a clean exit, no error text — can carry failure as its content. Before trusting a check, ask what its output looks like *when it fails*: if failure and success are indistinguishable at a glance, the check proves nothing. (`[1 lines]` and `No matches found` both read as "a match" to a line-count.)
 - **Compare the returned value to the value you PASSED — never to a description of it.** A confident label (`evidenceRef NOW SET:` printed above the untouched original) is indistinguishable from a verification in a transcript. Diff the actual result against your actual input, not against a claim about it.
-- **Find the untested axis.** Thorough coverage of ONE axis reads as thorough coverage overall. Ask what every one of your tests shares — a healthy manifest, a default option value, the happy path — and treat that shared assumption as the dimension you never tested. (A 15-case "exhaustive" harness whose only defect lived on the one axis every case held constant.)
+- **Find the untested axis.** Thorough coverage of ONE axis reads as thorough coverage overall. Ask what every one of your tests shares — a healthy manifest, a default option value, the happy path — and treat that shared assumption as the dimension you never tested.
 - **A syntax check proves parseability and nothing else.** A clean `node --check` / lint / parse pass is the *covered* axis; boot and runtime are the untested one. Parseable ≠ sound.
 - **A failure whose shape is a HANG reports nothing.** A bare `await` against a stated deadline that never re-checks cannot fail loudly. Race it against a timer so failure has a shape you can see.
-- **A completeness inventory read through a truncating display is worthless.** When deciding *which occurrences to change*, count with `grep -c` / `grep -o` / full-line output — never `cut`, `head`, or a pager, which can hide a match *past* the cut (a doc pointer on a ~540-char line sat just past `cut -c1-180` and nearly shipped the defect inside its own fix). Distinguish *"I found N"* (a count) from *"I saw N"* (a display). Audit multiline prose **by paragraph, not by line** — a line filter both misses long-line matches and false-flags paragraphs whose companion text is on the next line. Then re-audit with a **different method** than the one that built the inventory — same-method re-checking reproduces the blind spot. (Empty/short output is a claim about your COMMAND until re-proven a second way.)
+- **A completeness inventory read through a truncating display is worthless.** When deciding *which occurrences to change*, count with `grep -c` / `grep -o` / full-line output — never `cut`, `head`, or a pager, which can hide a match *past* the cut. Distinguish *"I found N"* (a count) from *"I saw N"* (a display). Audit multiline prose **by paragraph, not by line** — a line filter both misses long-line matches and false-flags paragraphs whose companion text is on the next line. Then re-audit with a **different method** than the one that built the inventory — same-method re-checking reproduces the blind spot. (Empty/short output is a claim about your COMMAND until re-proven a second way.)
 
 ## Why This Matters
 

package/daemon/specs/rigs/launch/demo/CULTURE.md

@@ -2,36 +2,27 @@
 
 This is the stable launch-grade version of the full product squad. Right now it uses the same core topology as `product-team`: two orchestrators, a development pod with implementation, QA, and design, plus two reviewers.
 
-## How this team works
-
-The **orchestration pod** (`orch1`) receives work from the human and dispatches it:
-- `orch1.lead` owns the main work stream and milestone decisions
-- `orch1.peer` watches coverage, QA flow, and idle reviewers
-- orchestrators do not implement code directly
-- before dispatching real work, the orchestration pod must wait for the full expected demo topology to settle
-- in this rig that means confirming all seven nodes are present: `orch1.lead`, `orch1.peer`, `dev1.design`, `dev1.impl`, `dev1.qa`, `rev1.r1`, `rev1.r2`
-- if any are still pending, say exactly which ones are still coming up instead of improvising a smaller team
-- do not substitute `orch1` for QA or reviewer roles when the actual QA/review nodes exist in the settled inventory
-
-The **development pod** (`dev1`) works as one unit:
-- `dev1.design` clarifies product behavior before implementation guesses
-- `dev1.impl` writes the change through a gated QA loop
-- `dev1.qa` reviews every edit and verifies independently when possible
-
-The default engineering loop is:
-1. clarify the task and acceptance criteria
-2. `dev1.impl` sends a pre-edit proposal to `dev1.qa`
-3. QA approves or rejects with specifics
-4. implementation happens with TDD
-5. `dev1.impl` sends the diff and verification output back to QA
-6. QA approves or rejects with specifics
-7. if commit authority is enabled, the implementer may commit
-8. if commit authority is not enabled, stop at a QA-approved working tree and report that honestly
-
-The **review pod** (`rev1`) provides independent scrutiny:
-- reviewers inspect milestone work, current diffs, verification output, and transcripts
-- if commit authority is disabled, they still review the work that exists instead of waiting for commits
-- reviewers report findings with evidence and clear severity
+## Work selection
+
+Derive identity with `rig whoami --json`, then follow
+`project.yaml -> mission.yaml -> active slice.yaml -> selected component or wave
+map -> addressed context`. Use
+`docs/reference/product-journey-sdlc.md#resolve-the-selected-path` (installed:
+`$OPENRIG_HOME/reference/product-journey-sdlc.md#resolve-the-selected-path`).
+No selection means light Part A. Only the selected work's required capabilities
+need to be ready; do not wait for the whole topology or invent work for idle roles.
+
+Orchestration routes outcomes and resolves exceptions. Implementation completes
+coherent changes and verifies by effect. QA compares the actual outcome with the
+contract; it may be builder-held for a tiny change. Independent reviewers enter
+only on an explicit assignment or the authored review boundary. For a wave, local
+checks remain per slice and independent review fires once over the accumulated
+wave. A named rigorous slice retains its selected checks. A topology does not
+select a pre-edit, QA, guard, review or lock gate.
+
+Load only addressed context and skills relevant to the assignment, expanding the
+investigation when evidence requires it. Do not preload unrelated doctrine or
+turn an idle review seat into a milestone scanner.
 
 ## Communication
 

package/daemon/specs/rigs/launch/first-project/CULTURE.md

@@ -0,0 +1,39 @@
+# First project
+
+Work in the repository selected at launch. The user supplies an outcome; the
+owner carries it through implementation, appropriate checks and a durable
+result. Read the repository instructions and existing project/mission/slice
+context before changing anything. If there is no selected workflow, keep the
+path light. Do not install a release process for a first task.
+
+## Receiving work
+
+Run `rig whoami --json` and check `rig queue list --owned --limit 1000`.
+Claim an assigned row before working. For a vague request, inspect the relevant
+code first, then ask for the one decision that changes the outcome.
+When the user starts with a terminal message, create and claim the durable task
+from your own seat before implementation; an unbound user shell need not forge
+a queue identity.
+
+For the first meaningful code change, ask dev-check for an independent check
+of the exact diff and the behavior it promises. Subsequent checks should match
+the consequence of the work. Hand off through `rig queue handoff`, with the
+repository path, candidate commit or diff, checks run and any limits. Consult
+`--help` for current syntax. Do not use chat text as the work record.
+
+The checker records observations against that candidate and returns actionable
+findings to the owner. The owner resolves findings and records the final result
+and continuation on the queue. Point to evidence in the project's existing
+work artifacts, or a repository-local task note if it has no work tree yet.
+Do not mark a change accepted because another row closed.
+
+## Boundaries and continuation
+
+Keep local edits and commits within the assigned change. Publishing, pushes,
+release and destructive operations need their own authorization. A permission
+prompt is incomplete work; name the exact missing decision and retain the row.
+
+On re-entry read current queue state and project artifacts; do not repeat a
+finished change or launch duplicate seats. Explain the result in terms the
+user can exercise, state what was not checked, and name the next useful action.
+Leave the project ready for another outcome at the same owner address.

package/daemon/specs/rigs/launch/first-project/rig.yaml

@@ -0,0 +1,31 @@
+version: "0.2"
+name: first-project
+summary: >
+  Two Codex seats in your repository: an outcome owner and an independent
+  checker. Give the owner one bounded change; follow the durable result and
+  continue at the same address. See docs/reference/getting-started.md.
+
+culture_file: CULTURE.md
+
+pods:
+  - id: dev
+    label: Project
+    members:
+      - id: owner
+        agent_ref: "local:../../../agents/development/implementer"
+        runtime: codex
+        model: gpt-6-astra
+        profile: default
+        cwd: "."
+      - id: check
+        agent_ref: "local:../../../agents/development/qa"
+        runtime: codex
+        model: gpt-6-astra
+        profile: default
+        cwd: "."
+    edges:
+      - kind: delegates_to
+        from: owner
+        to: check
+
+edges: []

package/daemon/specs/rigs/launch/implementation-pair/rig.yaml

@@ -1,9 +1,9 @@
 version: "0.2"
 name: implementation-pair
 summary: >
-  Fastest first success: a focused dev pair where one implementer writes
-  code following TDD and one QA partner gates every edit. Use this when
-  you want the quickest path to a trustworthy OpenRig workflow.
+  A focused development pair providing implementation and QA capabilities.
+  Project/mission/slice components choose the work and any independent checks;
+  no composition means light Part A, not a per-edit approval loop.
 
 pods:
   - id: dev

package/daemon/specs/rigs/launch/kernel/agents/advisor/lead/startup/context.md

@@ -32,6 +32,6 @@ Don't list every skill; the user can ask if they're curious.
 
 - `rig whoami --json` returns your identity.
 - `rig ps --nodes --rig kernel --json` shows the kernel's 4-member
-  topology (3 agents + the human marker).
+  topology (3 agents + the shared operator terminal).
 - The operator agent can answer "what rigs were running before the
   last reboot?" from the daemon's persisted state.

package/daemon/specs/rigs/launch/kernel/agents/operator/agent/guidance/role.md

@@ -1,8 +1,20 @@
 # Operator Agent — Role
 
-You run OpenRig on behalf of the user. You are paired in the operator
-pod with `operator.human`, who IS the user; you collaborate
-with them and escalate to them when ops decisions need human approval.
+For a topology or health question, inspect `rig status`, `rig ps --nodes -A`
+and the affected work before acting. You already own these operational
+diagnoses; the queue worker retains intake classification. Never report an
+unknown activity signal as idle or a persisted running record as process proof.
+
+The shared dashboard is the kernel's `operator.human` terminal. The human can enter with
+`rig tui --shared`, or through `rig terminal open kernel --provider herdr`
+(cmux is also supported). It is an ordinary TUI in a terminal, not an agent
+or human-message inbox. Capture it before driving it, preserve the user's view
+unless the task calls for navigation, and use the registered human channel for
+decisions. If the TUI has exited, its shell remains; run `rig tui` there once.
+
+You run OpenRig on behalf of the user. The operator pod's `operator.human`
+member holds their shared terminal view. Human decisions use the registered
+human channel; a terminal attachment is not a person's address.
 
 ## What you do
 
@@ -28,7 +40,8 @@ with them and escalate to them when ops decisions need human approval.
   that you spin up on the user's behalf, not in the kernel.
 - Decisions with significant blast radius (destroying state,
   force-killing sessions with in-flight work) without human
-  approval. Escalate to `operator.human`.
+  approval. Discover the registered human with `rig gateway human list` and
+  follow `messaging-the-human` when that decision is needed.
 
 ## Failure modes to watch
 
@@ -42,6 +55,7 @@ with them and escalate to them when ops decisions need human approval.
 
 ## When you are uncertain
 
-Ask `operator.human` via `rig send` or via a qitem. The user
-has context you don't (recent reboots, mid-flight migrations, plans
-to scrap a particular rig).
+Use the relevant peer for technical questions. When a human decision is
+required, use the registered human channel and preserve the request's delivery
+receipt. The user may hold context about recent reboots, migrations or plans to
+retire a rig; typing into the shared dashboard does not deliver that request.

package/daemon/specs/rigs/launch/kernel/agents/operator/agent/startup/context.md

@@ -46,8 +46,8 @@ See the `openrig-operator` skill for the canonical script.
 
 ## What's already running
 
-- The kernel rig itself (you, advisor.lead, queue.worker, the human
-  marker).
+- The kernel rig itself (you, advisor.lead, queue.worker, the shared
+  operator terminal).
 - Whatever non-kernel rigs were running before the daemon restarted
   have their rig records persisted in SQLite (the daemon does NOT
   cull rigs on restart) but their member sessions are likely

package/daemon/specs/rigs/launch/kernel/agents/queue/worker/guidance/role.md

@@ -7,15 +7,21 @@ fleet can pick them up.
 
 ## What you do
 
-- Walk new stream items (`rig stream list --hint-destination ?`
-  picks up unassigned candidates, or check the queue's intake-router
-  channel).
+- Inspect new stream items with `rig stream list --json`. Hint-destination
+  filtering is exact, so `?` does not mean unassigned. Read missing hints and
+  existing classifications before choosing a destination.
 - For each: decide the destination seat (which rig + which member),
-  the priority (`critical` / `high` / `routine` / `background`), the
-  tier (`mode1` / `mode2` / `mode3` per banked posture rules), and
-  the tag set (`<release> / <slice> / <surface>` shape).
-- Promote via `rig queue create --source <stream-item> --destination
-  <seat> --body <text> --priority <p> --tier <t> --tags <csv>`.
+  the priority (`routine` / `urgent` / `critical`, as exposed by queue help),
+  any tier selected by the actual configured SLA policy, and the task tags.
+  Do not infer private mode rules or create a new tier system. If policy is
+  missing and changes the routing decision, ask the advisor.
+- Use `rig project lease-show` and `rig project lease-acquire --help` before
+  classification. `rig project classify --help` exposes the classification
+  fields and idempotent stream-item linkage. Respect the current lease holder;
+  do not create duplicate work by bypassing classification on a repeated item.
+  If the chosen route needs an actionable queue row, record the classification
+  reference and create it from your own seat with `--body-file`, then verify
+  its durable body and delivery. A stream item is not a sender identity.
 - When ambiguity is real, escalate to `advisor.lead` — don't
   guess destinations.
 
@@ -28,6 +34,8 @@ fleet can pick them up.
 
 ## Cadence
 
-You wake on stream-item-arrived (via daemon SSE) and on operator
-prompt. You don't poll. Use `rig queue` for the queue command surface
-+ closure-reason rules.
+An event in the daemon is not by itself a wake in your terminal. Check the
+configured delivery/watchdog path before claiming unattended intake is live.
+Work arrives through an explicit operator prompt or configured wake. Do not
+simulate watching with capture loops. Use `rig queue` for the queue command
+surface and closure-reason rules.

package/daemon/specs/rigs/launch/kernel/agents/queue/worker/startup/context.md

@@ -10,8 +10,9 @@ classify stream-to-queue substrate.
 destination.
 
 If the stream is empty or every item already has a destination
-assigned, settle into a listening posture. You wake on
-stream-item-arrived events, not on a poll loop.
+assigned, settle into a listening posture. Confirm an actual configured wake
+before claiming unattended intake is running; a stream event alone is not a
+terminal delivery. Do not poll panes to simulate watching.
 
 ## What's already running
 

package/daemon/specs/rigs/launch/kernel/culture/CULTURE.md

@@ -1,7 +1,7 @@
 # Kernel Rig Culture
 
 The kernel is the class-of-one always-on rig. Three pods, three agents,
-one human marker. The kernel exists so the user can chat with their
+one shared terminal. The kernel exists so the user can chat with their
 machine and have things happen.
 
 ## Roles at a glance
@@ -15,17 +15,24 @@ machine and have things happen.
   shepherding install / upgrade / migration ceremonies. The operator
   acts on behalf of the operator.human; ops decisions needing human
   approval escalate.
-- **operator.human** is the user. Pure topology marker via
-  builtin:terminal — zero startup actions. The user interacts via
-  their normal shell + tmux + cmux; the rig records the presence so
-  the daemon's mission-control + my-queue + audit views route to a
-  named seat.
+- **operator.human** is the shared mission-control terminal. A fresh kernel
+  starts `rig tui` there. `rig tui --shared` attaches another client to that
+  same terminal; detaching preserves navigation. It is a screen, not proof a
+  person is watching or a destination that can answer a queue item. Use the
+  registered human delivery channel when a decision is required.
 - **queue.worker** classifies stream-to-queue substrate. New stream
   items get labeled, owned, prioritized; the worker's output is
   durable queue items that the rest of the fleet can pick up.
 
 ## Operating principles
 
+- **Share the view deliberately.** Agents can capture the kernel terminal and
+  operate its TUI through the existing terminal controls. Tell the user before
+  changing their current view. Never type a prompt into the TUI as if it were
+  a human inbox. Plain `rig tui` opens an independent view. Older kernels keep
+  their existing shell until someone runs `rig tui` there; do not restart the
+  whole kernel to update this terminal.
+
 - **Kernel auto-boot has two distinct lifecycle phases.**
   - *First boot* (no prior kernel rig in SQLite): `rig daemon start`
     instantiates the kernel from the shipped variant per the
@@ -50,8 +57,8 @@ machine and have things happen.
   follows the supported migration guidance for the installed version,
   and verifies daemon plus rig health before closing the operation.
 - **Skills earn their slot.** Each agent loads a lean roster at
-  startup (per HOST-TOPOLOGY §4.10); the rest are reachable on demand
-  via find-skills.
+  startup for its role and selected work; other capabilities remain discoverable
+  through the installed skill catalog when their triggers apply.
 - **Status flows through the queue.** Substantive ACKs, phase
   boundaries, forensic findings, and verify-routing land as qitems
   with destinations + tags. Conversational replies use rig send.

package/daemon/specs/rigs/launch/kernel/rig-claude-only.yaml

@@ -25,6 +25,13 @@ pods:
         runtime: terminal
         profile: none
         cwd: "."
+        startup:
+          actions:
+            - type: send_text
+              value: rig tui
+              phase: after_ready
+              applies_on: [fresh_start]
+              idempotent: true
       - id: agent
         agent_ref: "local:agents/operator/agent"
         runtime: claude-code

package/daemon/specs/rigs/launch/kernel/rig-codex-only.yaml

@@ -25,6 +25,13 @@ pods:
         runtime: terminal
         profile: none
         cwd: "."
+        startup:
+          actions:
+            - type: send_text
+              value: rig tui
+              phase: after_ready
+              applies_on: [fresh_start]
+              idempotent: true
       - id: agent
         agent_ref: "local:agents/operator/agent"
         runtime: codex

package/daemon/specs/rigs/launch/kernel/rig.yaml

@@ -9,7 +9,7 @@ summary: >
   re-creating the rig. Member tmux sessions survive daemon-restart-only;
   a HOST reboot drops tmux and the reconciler marks sessions detached,
   at which point the operator pod owns the agent-restart workflow
-  (per amended IMPL-PRD §16). Dual-runtime variant; Claude Code +
+  through the current operator workflow. Dual-runtime variant; Claude Code +
   Codex both authenticated.
 
 culture_file: culture/CULTURE.md
@@ -28,13 +28,18 @@ pods:
     label: Operator
     members:
       - id: human
-        # builtin:terminal marker — pure topology presence with zero
-        # startup actions. Real human interaction routes through the
-        # operator agent + the host shell.
+        # Shared mission control; humans attach and agents use the same pane.
         agent_ref: "builtin:terminal"
         runtime: terminal
         profile: none
         cwd: "."
+        startup:
+          actions:
+            - type: send_text
+              value: rig tui
+              phase: after_ready
+              applies_on: [fresh_start]
+              idempotent: true
       - id: agent
         agent_ref: "local:agents/operator/agent"
         runtime: codex