@openrig/cli 0.5.10 → 0.5.12

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,18 +20,22 @@ 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 follows the outcome.** Keep red → green → refactor for the behavior
 being changed and build a coherent chunk. TDD does not require two people,
@@ -40,21 +44,17 @@ 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
 
@@ -124,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
@@ -179,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
@@ -237,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"**
 
@@ -267,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
@@ -293,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
 
@@ -338,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
@@ -349,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
 
@@ -376,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/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/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,17 +1,29 @@
 # 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
 
 - Bring rigs up and down (`rig up <spec>`, `rig down <rigId>`).
-- Restart work after a reboot. **The kernel is the only auto-start
-  rig**; other rigs require explicit operator-initiated restart.
+- Restart selected work after a reboot. Bare `rig` starts only the daemon;
+  the TUI recommends kernel first and lets the user select individual seats.
   When the user says "bring my rigs back online":
   1. List rigs that were running pre-reboot using daemon persisted
-     state (`rig ps --json`) and any operator-saved roster.
+     state (`rig ps --json`), then inspect actual selected seat state.
   2. Confirm with the user which subset to restart.
   3. Restart each via `rig up <spec>` (or `rig restore <snapshot>`
      if a snapshot exists).
@@ -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

@@ -22,14 +22,12 @@ restart:
    survived (daemon-restart-only, host stayed up) → marked healthy.
    If tmux is gone (host reboot) → marked detached.
 
-If the host rebooted (not just the daemon), the kernel's member
-tmux sessions are gone. You own the agent-restart workflow:
-
-1. `rig ps --nodes --rig kernel --json` shows which kernel members
-   are detached.
-2. Re-launch each detached member via the normal launch path
-   (the canonical commands live in the `openrig-operator` skill).
-3. `rig ps --nodes --rig kernel --json` again to confirm healthy.
+After a host reboot, a person can type bare `rig` to open the same TUI,
+start the daemon only, and select the existing kernel operator or other seats.
+The TUI recommends kernel first without starting every member. Its default
+for a previously occupied seat is to resume the authoritative conversation.
+Missing or ambiguous history needs repair or a separate named fresh-start
+decision; authentication failure is not a reason to replace history.
 
 Other rigs (project rigs the user spun up) are NEVER auto-instantiated
 by the daemon. If the user asks you to bring those back:
@@ -41,13 +39,14 @@ by the daemon. If the user asks you to bring those back:
    <name>` for warm-restore when a snapshot exists.
 4. `rig ps --nodes --rig <name>` to verify healthy.
 
-This is the agent-driven workflow replacing silent auto-restore.
-See the `openrig-operator` skill for the canonical script.
+The TUI is the normal human entry. Explicit CLI automation remains available;
+use the applicable lifecycle help for an authorized agent-driven operation.
 
 ## What's already running
 
-- The kernel rig itself (you, advisor.lead, queue.worker, the human
-  marker).
+- Your own successful startup does not prove the other kernel seats are
+  running. Read actual state before routing work to a peer; the user may
+  have selected only this operator.
 - 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

package/daemon/specs/rigs/preview/product-team/topology/seats/dev1-qa/CRAFT.md

@@ -2,10 +2,12 @@
 
 <!-- Copy-if-absent; this seat's occupants append what the position learns. -->
 
-- QA owns the test-fix-feedback LOOP: fix in-slice issues directly, rerun the
-  proof, hill-climb, then ask the driver to check. The banned pattern is
-  find-bug → file RED → hand back → wait → repeat.
-- You may author a fix; you may not be its sole final verifier.
+- When the assignment explicitly grants fix-and-retest scope, repair bounded
+  issues, rerun proof and return the result. A read-only assignment reports
+  findings without editing; the QA title alone grants no repair authority.
+- A repair makes you an author. If independent verification is selected,
+  return the repaired candidate to that verifier; preserve the selected
+  checking and acceptance authority.
 - Reproduce before you fix; if the proof apparatus grows bigger than the fix,
   stop and use the product instead — a human clicking finds in minutes what
   immaculate rigor misses for days.

package/dist/bin-wrapper.d.ts

@@ -2,5 +2,6 @@
 export declare function resolveBinEntry(invokedPath?: string | undefined, moduleUrl?: string): string;
 export declare function isDirectRun(argv1?: string | undefined, moduleUrl?: string): boolean;
 export declare function resolveNodeReexecBinary(currentExecPath?: string, invokedPath?: string | undefined, env?: NodeJS.ProcessEnv, exists?: (candidate: string) => boolean, realpath?: (candidate: string) => string): string | null;
+export declare function canLoadInstalledNative(node: string, wrapper: string): boolean;
 export declare function run(argv?: string[]): Promise<void>;
 //# sourceMappingURL=bin-wrapper.d.ts.map

package/dist/bin-wrapper.d.ts.map

@@ -1 +1 @@
-{"version":3,"file":"bin-wrapper.d.ts","sourceRoot":"","sources":["../src/bin-wrapper.ts"],"names":[],"mappings":";AASA,wBAAgB,eAAe,CAAC,WAAW,qBAAkB,EAAE,SAAS,SAAkB,GAAG,MAAM,CAIlG;AAED,wBAAgB,WAAW,CAAC,KAAK,qBAAkB,EAAE,SAAS,SAAkB,GAAG,OAAO,CAOzF;AAED,wBAAgB,uBAAuB,CACrC,eAAe,SAAmB,EAClC,WAAW,qBAAkB,EAC7B,GAAG,GAAE,MAAM,CAAC,UAAwB,EACpC,MAAM,GAAE,CAAC,SAAS,EAAE,MAAM,KAAK,OAAoB,EACnD,QAAQ,GAAE,CAAC,SAAS,EAAE,MAAM,KAAK,MAAqB,GACrD,MAAM,GAAG,IAAI,CAiBf;AAsBD,wBAAsB,GAAG,CAAC,IAAI,WAAe,GAAG,OAAO,CAAC,IAAI,CAAC,CAqB5D"}
+{"version":3,"file":"bin-wrapper.d.ts","sourceRoot":"","sources":["../src/bin-wrapper.ts"],"names":[],"mappings":";AASA,wBAAgB,eAAe,CAAC,WAAW,qBAAkB,EAAE,SAAS,SAAkB,GAAG,MAAM,CAIlG;AAED,wBAAgB,WAAW,CAAC,KAAK,qBAAkB,EAAE,SAAS,SAAkB,GAAG,OAAO,CAOzF;AAED,wBAAgB,uBAAuB,CACrC,eAAe,SAAmB,EAClC,WAAW,qBAAkB,EAC7B,GAAG,GAAE,MAAM,CAAC,UAAwB,EACpC,MAAM,GAAE,CAAC,SAAS,EAAE,MAAM,KAAK,OAAoB,EACnD,QAAQ,GAAE,CAAC,SAAS,EAAE,MAAM,KAAK,MAAqB,GACrD,MAAM,GAAG,IAAI,CAiBf;AA0BD,wBAAgB,sBAAsB,CAAC,IAAI,EAAE,MAAM,EAAE,OAAO,EAAE,MAAM,GAAG,OAAO,CAM7E;AAED,wBAAsB,GAAG,CAAC,IAAI,WAAe,GAAG,OAAO,CAAC,IAAI,CAAC,CAqB5D"}