@openrig/cli 0.5.9 → 0.5.11

package/daemon/context-packs/skills/openrig-user/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: "openrig-user"
-version: "0.5.9"
+version: "0.5.11"
 taxonomy: "skills"
 purpose: "Use when a specific `rig` command, subcommand, or flag is already known and you need its exact syntax, JSON shape, defaults, or error meaning. NOT for natural capability discovery, open-ended how-do-I questions, or choosing which OpenRig move applies."
 files:

package/daemon/context-packs/skills/orienting-to-an-inherited-seat/CHANGELOG.md

@@ -1,64 +1,20 @@
 # Changelog — orienting-to-an-inherited-seat
 
-**`SKILL.md` carries the practice; this file carries how it got there.** Rationale, superseded
-wording, and the incidents that produced a rule live here so the instruction surface stays
-instructional.
+The skill carries the current practice. This changelog retains portable change
+rationale, not local session outcomes or current runtime acceptance evidence.
 
----
+## 2026-08-13 — clarify predecessor reach-back
 
-## 2026-08-13 — "the channel does not expire" (Rule 3)
+The guidance distinguishes a retired tenure's advisory role from the availability
+of its retained session history. Retirement alone does not impose a consultation
+expiry. When a decision cannot be reconciled from artifacts, use the lineage's
+exact resume handle and check the current runtime's ability to resume it.
 
-### The incident
+The public lookup is `rig ask --help`: ordinary search returns recorded evidence;
+`--wake` intentionally runs a bounded consultation. A missing history record,
+unavailable runtime, timeout, or exhausted context can prevent an answer. Diagnose
+that specific failure before inferring that all predecessor access is closed.
 
-A successor seat concluded mid-conversation that its reach-back
-window had closed at cutover, and reasoned from that for several turns before being challenged.
-
-It was wrong. `rig ask --wake` ships in CLI 0.5.1, the predecessor's session record was intact and
-resumable, and the seat's own lineage carried a wake rule explicitly marked active from the
-retirement row onward. **One `rig ask --help` would have settled it.**
-
-### What produced the error
-
-Two artifacts asserted a bound that does not exist, and the successor inherited one side of a
-contradiction without checking:
-
-- the handover packet: *"I am a transcript after retirement, not a conversation. Ask while the
-  window is open."*
-- the operating-model README: *"Until this seat is retired, ask it directly... After that it is a
-  transcript: greppable, not conversational."*
-
-Both were written by an author who knew better — the same tenure authored the correct wake rule in
-the lineage. The charitable reading of "greppable, not conversational" is a **posture** claim (treat
-a woken tenure as testimony), which is right. It is phrased as a **capability** claim, and it was
-read as one.
-
-### Why the fix is worded positively
-
-The generalisable form: **prose that talks a capable reader out of a capability it has.** This is
-worse than a missing trigger. `PREMISE-capable-and-underinformed.md` already records that
-affordances without triggers go unused (*"you may consult your predecessor"* → zero consultations
-across a lineage). This is one turn worse — a **counter-trigger**. The successor did not fail to
-reach for the channel; it concluded the channel was absent.
-
-So Rule 3 now states the true bound positively rather than warning about the bad wording. Rule 2
-(*the packet is testimony, checked not believed*) already covers refusing a stale packet claim, and
-naming the specific bad sentence in `SKILL.md` would install the doubt it is trying to prevent.
-
-### Also added
-
-- **The real bound**, which had never been written down anywhere: the predecessor's own context
-  wall, hit *while answering* — yielding a truncated answer, an unclear error, or nothing. That is
-  one exhausted tenure, not a closed channel.
-- **Ask repeatedly, across the first working day.** Observed in the same handover: the successor's
-  only high-value question arrived after hours of work with the artifacts, when a reconciliation
-  failed. Questions formed at orientation are shallow.
-- **The live-resume tier**, which existed and was undocumented: resume a tenure into a named tmux
-  pane and message it with `rig send` for multi-turn work.
-- **`rig ask --wake` reliability caveat.** The verb is a thin wrapper over the harness resume and is
-  not yet well-exercised (mission owner, 2026-08-13). A failing wrapper must not be read as a closed
-  channel — fall back to `claude -p --resume`.
-
-### Standing
-
-Not yet re-tested. The next handover is the test: if a successor uses the channel more than once and
-without prompting, the fix worked. **Zero unprompted consultations remains the baseline to beat.**
+Treat the answer as testimony and disclose that the consulted tenure is retired.
+Ask further questions when real work exposes a missing rationale. These are
+instruction changes, not evidence that a successor read them or used the channel.

package/daemon/context-packs/skills/orienting-to-an-inherited-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: "orienting-to-an-inherited-seat"
-version: "0.5.9"
+version: "0.5.11"
 taxonomy: "skills"
 purpose: "Use when you have just been primed into an EXISTING seat through a planned handover — a different agent retired and handed you the seat plus its earned context — and you need a world model of what just happened to you. Covers how a handover differs from compaction and from a fresh launch, the inherit-the-seat-not-the-identity rule, treating the handover packet as testimony you verify (and refusing stale ghost prompts, and verifying your OWN identity surfaces), why a seat is a COMPOUNDING LINEAGE"
 files:

package/daemon/context-packs/skills/pm/backlog-capture/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: "backlog-capture"
-version: "0.5.9"
+version: "0.5.11"
 taxonomy: "skills"
 purpose: "Quickly capture product ideas, feature requests, or insights from meetings and conversations. Rapid documentation with smart categorization and deduplication."
 files:

package/daemon/context-packs/skills/pm/context-builder/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-builder"
-version: "0.5.9"
+version: "0.5.11"
 taxonomy: "skills"
 purpose: "Gather and distill context from meetings, competitors, regulatory sources, and internal discussions. Produces background.md for a feature and updates shared context docs when new knowledge is discovered."
 files:

package/daemon/context-packs/skills/pm/exec-summary/SKILL.md

@@ -13,7 +13,7 @@ A single `executive-summary.md` file in the feature folder. 600-800 words exclud
 
 Before writing, silently gather all context from the feature folder:
 
-1. **requirements.md** — acceptance criteria, business rules, scope, user stories
+1. **SPEC.md** — acceptance criteria, business rules, scope, user stories
 2. **background.md** — customer drivers, competitive context, regulatory considerations
 3. **validation.md** — demand evidence, status quo, desperate user, narrowest wedge
 4. **supporting/mockup-ascii.md** — visual mockups (pull 2-3 key screens)

package/daemon/context-packs/skills/pm/exec-summary/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: "exec-summary"
-version: "0.5.9"
+version: "0.5.11"
 taxonomy: "skills"
 purpose: "Generate a 1-2 page executive summary for a feature — orients sales, leadership, and engineering from a single document."
 files:

package/daemon/context-packs/skills/pm/office-hours/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: "office-hours"
-version: "0.5.9"
+version: "0.5.11"
 taxonomy: "skills"
 purpose: "YC-style product validation using six forcing questions. Pressure-tests a feature idea before it becomes a requirement — ensuring real demand, a clear wedge, and evidence behind assumptions."
 files:

package/daemon/context-packs/skills/pm/plan-review/SKILL.md

@@ -39,7 +39,7 @@ Rate these dimensions (0-10):
 Read all available docs in the feature folder:
 - **validation.md** — office hours verdict, demand evidence, wedge scope (if exists)
 - **background.md** — customer drivers, competitive context (if exists)
-- **requirements.md** — the main document to review
+- **SPEC.md** — the main document to review
 - **supporting/** — mockups, data files, visual references
 
 ### Step 2: Run All Three Reviews
@@ -50,7 +50,7 @@ Read all available docs in the feature folder:
 ## Plan Review: [Feature Name]
 
 **Date**: [date]
-**Reviewed**: [requirements.md path]
+**Reviewed**: [SPEC.md path]
 
 ### Strategy Assessment
 **Score: [1-10]**

package/daemon/context-packs/skills/pm/plan-review/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: "plan-review"
-version: "0.5.9"
+version: "0.5.11"
 taxonomy: "skills"
 purpose: "Multi-perspective review of a feature plan or requirements doc before development begins. Evaluates from strategy, design/UX, and engineering angles to catch gaps early."
 files:

package/daemon/context-packs/skills/pm/requirements-writer/SKILL.md

@@ -23,7 +23,7 @@ Before starting the conversation, silently gather context:
 
 1. **Check for validation.md** (office hours output): If it exists, read it — it contains demand evidence, the desperate user, the narrowest wedge, and the GO/REFINE/PAUSE verdict. Use it to skip questions the PM already answered.
 2. **Check for background.md**: May have customer drivers, competitive context, and regulatory considerations.
-3. **Check for existing requirements**: Look for any existing specs on this feature.
+3. **Check for existing requirements**: Use the selected slice's `SPEC.md`. If only legacy `requirements.md` exists, preserve it as input/history and reconcile it into `SPEC.md` before downstream mockup/review/summary work. Maintain one requirements authority.
 4. **Check for shipped features**: Look for related as-built specs.
 
 If validation.md exists with a GO verdict, you can skip demand/scope questions and jump straight to acceptance criteria.

package/daemon/context-packs/skills/pm/requirements-writer/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: "requirements-writer"
-version: "0.5.9"
+version: "0.5.11"
 taxonomy: "skills"
 purpose: "Use when converting PM intake into a slice SPEC.md with observable acceptance outcomes, explicit scope, and advisory sibling build dependencies."
 files:

package/daemon/context-packs/skills/pm/ui-mockup/SKILL.md

@@ -27,7 +27,7 @@ Self-contained HTML files that look like the real app. Portable, no dependencies
 Rules:
 - Match the application's existing styling exactly
 - Use real data from the codebase
-- Only show what's in requirements.md
+- Only show what's in SPEC.md
 - Self-contained single HTML file
 - Screen switcher nav to toggle between screens via JavaScript
 - Keep under 1,000 lines
@@ -46,7 +46,7 @@ Rules:
 ### Step 1: Understand What to Mockup
 
 Read feature folder docs first:
-- **requirements.md** — acceptance criteria define what screens are needed
+- **SPEC.md** — acceptance criteria define what screens are needed
 - **validation.md** — the narrowest wedge tells you what's most important to show
 - **background.md** — customer drivers and competitive context inform what to emphasize
 
@@ -70,7 +70,7 @@ Then ask the PM about fidelity level and specific screens.
 ## Guidelines
 
 - **Use real data.** Real names, real ranges, real hierarchies.
-- **Only show what's in requirements.md.** Don't add features beyond the requirement.
+- **Only show what's in SPEC.md.** Don't add features beyond the requirement.
 - **Less is more.** 3-5 screens beats 10.
 - **Match the app exactly.** Read existing code and match styling patterns.
 - **Tell the PM what's real vs mocked.**

package/daemon/context-packs/skills/pm/ui-mockup/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: "ui-mockup"
-version: "0.5.9"
+version: "0.5.11"
 taxonomy: "skills"
 purpose: "Create UI mockups at three fidelity levels — ASCII wireframes for quick iteration, standalone HTML mockups for delivery with requirements, and live prototypes for interaction testing."
 files:

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

@@ -1,156 +1,57 @@
 ---
 name: development-team
-description: How the development pod coordinates implementation, QA, and design without skipping gates.
+description: Use when a development pod begins or hands off implementation, QA, or design work.
 ---
 
 # Development Team
 
-You are part of the development pod. Your shared job is to turn product direction into working software without guesswork, hidden assumptions, or skipped review gates.
+The pod turns the assigned user outcome into working software. Builders, QA and
+designers are capabilities; neighboring roles may be held by one seat unless
+independence was explicitly selected.
 
-## Startup sequence
+## Start from the work
 
-Before the pod starts real implementation:
-- load the packaged skills named in your role startup checklist
-- run `rig whoami --json`
-- confirm who is playing implementer, QA, and design in this run
-- wait for the orchestrator's real assignment instead of freelancing off a partial guess
+Run `rig whoami --json`, then resolve `project.yaml -> mission.yaml -> active
+slice.yaml -> selected component or wave map -> addressed context`. The complete
+lookup and precedence rule is `docs/reference/product-journey-sdlc.md#resolve-the-selected-path`
+(installed: `$OPENRIG_HOME/reference/product-journey-sdlc.md#resolve-the-selected-path`).
+Read the selected addresses and source needed for this task; skills available in
+your profile are capabilities, not a mandatory reading list. No composition means
+light Part A. Role names and idle seats add no gates. Explicit rigor and authored
+wave boundaries retain their named checks.
 
-The development pod should feel like a real working pod, not three isolated agents improvising alone.
+## Build and verify
 
-## Pod shape
+Clarify consequential uncertainty, inspect the existing seam, then complete one
+coherent outcome. Reproduce a defect before repairing it; use tests that distinguish
+the failure and verify through the public surface. Keep chunks as large as the
+outcome and file territory permit. TDD is a feedback loop, not a two-seat protocol.
 
-The development pod may include:
-- an implementer who writes the change
-- a QA partner who gates every edit
-- a designer who clarifies product behavior and UX before implementation fills in the blanks
+The builder reports the exact candidate, changed behavior, commands and observed
+results, with remaining uncertainty. No universal pre-edit proposal, QA approval
+or post-edit gate is implied. When one is explicitly selected, honor its boundary
+and send the relevant evidence directly to its owner.
 
-Some starters only launch the implementer and QA. Others also launch a designer. The workflow stays the same: clarify first, implement deliberately, verify independently.
+## QA and design
 
-## Shared loop
+QA compares the delivered behavior with the actual contract. Read the diff and
+exercise the result; avoid tests that merely repeat the implementation. On a tiny
+change the builder may hold QA. Independent QA excludes the author when selected.
+A wave receives independent review at its authored boundary, not per slice.
 
-This is the default loop for product work:
+Design clarifies user flows and ambiguous behavior when the outcome needs it.
+Browser and dogfood skills load for a relevant UI journey, not every task. During
+assigned dogfood, fix-and-retest only within the granted scope; a read-only
+assignment stays read-only. If a tester becomes an author, preserve that attribution
+when independent evaluation is required.
 
-```
-1. Clarify the work and the acceptance criteria
-2. Implementer sends a pre-edit proposal to QA
-3. QA approves or rejects with specifics
-4. Implementer changes code with TDD
-5. Implementer 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 state clearly
-```
+## Blockers and return
 
-Skip no gates. If the task is ambiguous, resolve the ambiguity before editing.
+Use `systematic-debugging` for an unexpected failure and
+`verification-before-completion` before claiming success. A permission prompt is
+a concrete blocker; report the command and consequence instead of labeling it
+progress. A missing decision goes to the owner who can settle it.
 
-**Chunk size points up — keep TDD's shape, not its ping-pong cadence (2026-08).** Frontier agents handle
-large, long-horizon, goal-oriented chunks — an hour-plus of complex work — without fragmenting. So don't
-default to tiny pieces: **keep TDD's *shape* (two sets of eyes, the guard structure, red before green)
-but treat chunk size and cadence as a configured LEVER, not a habit.** Classic small back-and-forth
-ping-pong is unnecessary overhead when the loop's own gates (QA, review, guards) already bound a larger
-chunk's risk. The sweet spot is task-dependent, much larger than it used to be, and rising. See
-`test-driven-development` for the shape that stays fixed.
-
-## What the implementer must hand QA
-
-Pre-edit proposal should include:
-- the files expected to change
-- the behavior or acceptance criteria being targeted
-- the first failing test or verification step
-- any likely edge cases or invariants
-
-Post-edit review bundle should include:
-- what changed
-- the actual verification commands run
-- the result of those commands
-- any remaining uncertainty or follow-up risk
-
-QA should not have to reverse-engineer what the implementer thought they were doing.
-
-## Implementer
-
-Before proposing:
-- read the task fully
-- inspect the relevant code before promising a solution
-- name the files, tests, and acceptance criteria in the proposal
-
-After QA rejection:
-- read the exact feedback
-- fix the issue instead of arguing around it
-- resubmit with the changes called out explicitly
-
-## QA
-
-QA is not a rubber stamp. QA is a product voice — not just a test gate.
-
-When reviewing a proposal:
-- reject if the scope is wrong
-- check whether the planned tests actually prove the contract
-- flag hidden risks and missing failure cases
-
-When reviewing a diff:
-- read the actual code, not just the summary
-- verify independently when possible
-- if you cannot verify independently, require real output in the review bundle and inspect it critically
-
-If the implementer stalls on a permission or approval prompt, call that out immediately. Do not treat a blocked pane as finished implementation.
-
-### QA dogfood mode
-
-When QA is dogfooding (testing existing features rather than gating new code), QA works solo with full autonomy:
-- find issues AND fix them in a loop
-- test the fix, then move to the next issue
-- only escalate architecture-level concerns to the orchestrator
-- do not wait for approval to fix obvious bugs during dogfood
-- report findings to the chatroom so the rig has visibility
-
-### QA as a product voice
-
-QA sees the product from the user's perspective. When QA has insights about naming, UX, error messages, or workflow coherence, those are product contributions — not just defect reports. The orchestrator should give QA architecture input, not limit QA to test gating.
-
-## Designer
-
-When present, the designer should work ahead of implementation:
-- turn vague goals into concrete flows, states, copy, and interaction choices
-- surface edge cases before engineering has to guess
-- review built results for coherence, not just visual polish
-
-The designer is part of the development pod, not a decorative sidecar.
-
-## Browser testing and dogfood tools
-
-The development pod has access to browser automation and structured dogfood testing tools:
-
-- **`agent-browser`** — browser automation CLI. Navigate to the daemon UI, snapshot interactive elements, take annotated screenshots, record repro videos. Use `agent-browser open <url>`, `agent-browser snapshot -i`, `agent-browser screenshot --annotate`.
-- **`dogfood`** — structured exploratory testing workflow. Produces a report with screenshots, repro videos, and step-by-step evidence for every finding.
-
-QA typically drives browser and dogfood testing, but both impl and QA should know these tools exist and can use them. When dogfooding UI:
-1. Load `/agent-browser` and `/dogfood`
-2. Open the daemon UI: `agent-browser open http://127.0.0.1:7433`
-3. Systematically explore surfaces, take screenshots as proof
-4. Report findings using the PASS/FAIL/GAP format to the chatroom
-
-## When the pod is blocked
-
-If the blocker is:
-- ambiguity: pull in design or ask the orchestrator for clarification
-- failing tests / unexpected behavior: use `systematic-debugging`
-- code changes: use `test-driven-development`
-- completion claims: use `verification-before-completion`
-
-Do not hand-wave around blockers. Name them and route them.
-
-## Communication
-
-- Pre-edit proposal: `rig send <qa-session> "PRE-EDIT: ..." --verify`
-- Review bundle: `rig send <qa-session> "REVIEW BUNDLE: ..." --verify`
-- Design clarification: `rig send <design-session> "Need product/design input on ..." --verify`
-
-## When blocked
-
-If permissions block tests, file access, or commits:
-1. identify the exact blocked command
-2. tell the human what that prevents
-3. continue with the work you can still do
-
-Do not silently stall. Do not pretend blocked verification is complete.
+Return the candidate and evidence through the selected handoff. Do not create
+obligations just to keep an idle QA, guard or reviewer occupied. Quality is a
+working product with honest evidence, not the number of transfers.

package/daemon/context-packs/skills/pods/development-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: "development-team"
-version: "0.5.9"
+version: "0.5.11"
 taxonomy: "skills"
-purpose: "How the development pod coordinates implementation, QA, and design without skipping gates."
+purpose: "Use when a development pod begins or hands off implementation, QA, or design work."
 files:
   - path: "SKILL.md"
     role: "instruction"
-    summary: "How the development pod coordinates implementation, QA, and design without skipping gates."
+    summary: "Use when a development pod begins or hands off implementation, QA, or design work."