@openrig/cli 0.5.9 → 0.5.10

package/daemon/docs/reference/health-diagnosis.md

@@ -0,0 +1,305 @@
+# Agent-operated System Health diagnosis
+
+System Health can give a responsible agent one durable investigation packet when
+a configured detector needs interpretation. The packet preserves the finding,
+policy version, evidence, and current authority documents. It invites the agent
+to investigate beyond that selection, including its own contribution. It does
+not declare a pathology or perform corrective actions.
+
+## Enable a bounded diagnosis loop
+
+```sh
+rig health policy --json > effective-policy.json
+jq '.policy' effective-policy.json > health-policy.json
+# Edit health-policy.json: diagnosis.enabled=true and diagnosis.owner=<seat@rig>.
+rig health policy --file health-policy.json
+rig health diagnose                    # preview; no writes or wakes
+rig health diagnose --apply            # evaluate now and apply admitted actions
+rig health diagnosis list
+rig health diagnosis show <qitem-id>
+```
+
+The daemon checks enabled policy once per minute. `health policy` reports whether
+that check is scheduled and its last result, including errors. Ordinary `health`
+list/explain commands remain observational. Diagnosis defaults to disabled;
+ceremony amplification is the only default diagnosis trigger. A continuing
+episode keeps one qitem, receives at most one additional presentation by default,
+and shares an owner cooldown across episodes (one hour by default). A disposition
+stops re-presentation. Disabling policy stops automatic admission and presentation.
+Ownership changes do not silently reroute existing occurrences.
+Outside a managed seat, name the writer with `rig health --actor <name> ...`.
+Managed-seat transport identity takes precedence over that declared name.
+Only the occurrence's assigned owner may record its disposition or request human
+notification. Other agents can advise the owner; a policy-owner change does not
+grant custody of existing occurrences. Writes retain the sender's identity
+provenance on the queue transition.
+
+Policy controls detector enablement, ceremony/review/wake thresholds, source
+observation window and freshness, diagnostic owner, cooldown, re-presentation
+bound, and human-escalation conditions. Edit plain JSON and apply it with the
+command; unknown keys and invalid values refuse without changing the policy.
+Applied proposals and their predecessors are retained under the configured
+OpenRig home in `health/policy-history/`. The effective version also includes
+the existing `health.context_pressure.warning_percent` and `critical_percent`
+settings, which remain configurable with `rig config`. Their defaults are 95
+and 99. CLI/TUI finding explanations show the policy version used.
+
+## Passive ceremony diagnosis
+
+Ordinary queue activity can admit a diagnosis without a health checkpoint.
+The source discovers declared handoff families touched in the observation window,
+uses their explicit `mission:` / `slice:` tags, and collects exact transition IDs,
+normal project/mission/slice authority, progress and proof references, and workflow
+closure evidence. It never interprets Markdown or counts proof files, approvals,
+C1 pairing, commits, tests, or terminal rows as accepted product outcomes.
+
+At the configured traffic threshold (20 transitions by default), a fresh,
+complete family becomes `ceremony.stage=needs-diagnosis`, `status=indeterminate`,
+and `severity=info`. CLI/TUI call this **needs diagnosis**, not a confirmed
+warning. Enabled diagnosis policy admits one bounded packet even though the
+product denominator is unknown. Ordinary unavailable/stale detector records
+remain ineligible. Diagnosis and human-notification traffic are excluded from
+the numerator and cannot recursively generate another investigation.
+
+The agent reads the actual evidence, including beyond the supplied references,
+and resolves the semantic outcome granularity and consequence boundary. Use the
+existing disposition command with an optional `progress` result:
+
+```json
+{
+  "basis": "<current finding.ceremony.basis from diagnosis show>",
+  "conclusion": "established",
+  "outcomes": [{"id": "<distinct meaningful outcome>", "observedAt": "<time inside the measured interval>", "evidenceRefs": ["<normal proof path>"]}],
+  "boundedAuthority": false,
+  "boundary": "<selected SDLC boundary and why this outcome census covers the interval>",
+  "evidenceRefs": ["<inspected authority/evidence path>"],
+  "missingFacts": []
+}
+```
+
+Put this object in `progress` beside the existing verdict/steering/uncertainty
+fields. `established` affirms a complete census for the exact interval; an empty
+outcome list affirms zero outcomes, not failed discovery. `false-positive`
+clears the suspicion without inventing a denominator when no missing facts remain.
+A false-positive assessment that still names missing facts stays indeterminate
+and does not close the episode interval. `indeterminate` supplies
+no outcomes and names the missing fact in `missingFacts`. Required references
+must resolve inside the workspace; extra evidence beyond the initial packet is
+allowed. The receipt retains the actual actor, timestamp, identity provenance,
+source basis, and evidence hashes. A changed basis refuses a stale submission.
+Later evidence changes make confirmation indeterminate rather than preserving
+a false ratio. Outcome meaning remains attributed agent judgment.
+
+Only an established, current assessment permits a ratio. The projector computes
+it from the distinct listed outcomes and exact transitions; a qualifying ratio
+with no bounded-authority counter-signal becomes `confirmed` / `active` /
+`warning`. Proportionate or bounded-authority results clear the episode. An
+explicitly cleared assessment marks the end of that interval; sufficient later
+traffic in the same family starts a new episode. Repeated reads never advance
+these boundaries. One occurrence and the existing owner cooldown apply to each
+episode; a disposition stops repeated requests.
+
+This bounded source covers explicitly tagged mission work: at most 2,000 touched
+qitems, 200 roots, 1,000 members / 10,000 transitions per family, 200 workflow
+receipts, 200 declared slices, and 100 proof files per selected slice. Overflow
+refuses visibly. Context files are bounded to 64 KiB. A lineage beginning before
+the retained window remains indeterminate, with the missing interval named.
+Untagged or ambiguously mission-tagged work is outside this source's coverage;
+absence is not health. The packet includes missing context references so an agent
+can name or repair its own knowledge gap without manufacturing source truth.
+
+## Optional outcome-boundary checkpoint
+
+Live queue transitions do not, on their own, prove product outcomes or the
+authority for a bounded operation. At a meaningful outcome boundary, the agent
+holding those facts may submit a census for one qitem lineage and time window. Set `includeHandoffs: true`
+to follow its declared handoff descendants; this is the normal path for work that
+passed between seats. The root alone usually misses the review/return traffic.
+Prefer the existing proof/progress/outcome artifact as evidence. Do not add a
+checkpoint to each edit or message. This is a fallback for explicitly supplied evidence;
+normal activity uses passive diagnosis above. An existing checkpoint owns its
+lineage so the passive source does not create a duplicate episode.
+
+```json
+{
+  "schema": "openrig.health-checkpoint/v0alpha1",
+  "lineageQitemId": "<existing-product-qitem>",
+  "includeHandoffs": true,
+  "scope": {"type": "slice", "projectId": "<project>", "missionId": "<mission>", "sliceId": "<slice>"},
+  "startedAt": "<ISO timestamp>",
+  "observedAt": "<ISO timestamp>",
+  "transitionIds": "derive",
+  "productOutcomes": [
+    {"id": "<outcome-id>", "observedAt": "<ISO timestamp>", "evidenceRef": "<proof-artifact-path>"}
+  ],
+  "productCensusRef": "<artifact establishing the complete outcome census for this lineage/window>",
+  "boundedAuthority": {"applies": false, "evidenceRef": "<bounded-effect-authority assessment>"},
+  "sdlc": {"expectation": "<selected components and review boundary>", "evidenceRef": "<authority for that selection>"},
+  "authorityPaths": {
+    "project": ["<current project SPEC and project.yaml paths>"],
+    "mission": ["<current mission SPEC and mission.yaml paths>"],
+    "slice": ["<current slice SPEC and slice.yaml paths>"]
+  }
+}
+```
+
+```sh
+rig queue transitions <existing-product-qitem>
+rig health checkpoint --file checkpoint.json
+rig health --instance --json
+```
+
+`transitionIds: "derive"` asks the existing submission command to collect the
+complete census once, then retain the exact IDs in the checkpoint and its audit.
+The author supplies outcomes and their meaning, not a row-by-row bookkeeping
+ritual. An explicit ID array is also supported for sealed replay or a
+caller-supplied census. Later reads never silently extend either form.
+
+The daemon verifies that transition IDs are the complete census for that exact
+qitem and window, including all handoff descendants when selected. It does not
+infer shared lineage from similar names or seat names. The complete transition
+census may be assembled from the queue ledger; omitting a descendant refuses.
+Explicit mission/slice tags on counted family members must match the checkpoint
+scope; untagged descendants inherit the declared handoff relationship.
+The bound is 1,000 linked qitems and 10,000 transitions; an oversized family
+refuses rather than silently sampling it. Independent roots are separate censuses. It counts
+those transitions and the distinct, evidenced product outcomes, and explains
+both sides of the ratio, the literal gate-tag breakdown, and the selected SDLC
+expectation. These are custody/status transitions, not messages or judgments
+about whether each review was useful. A product outcome is a distinct evidenced
+user-visible result; commits, test runs, returns and fixes needed to achieve
+that same promised result do not each create another denominator unit. The
+census must state its outcome granularity and coverage. The same granularity
+must be used for positive and proportionate controls. An empty outcome list requires the same census evidence
+as a nonempty one. An unavailable product census is a null denominator: the explanation says
+no ratio was computed, rather than silently substituting zero or one.
+`boundedAuthority.applies=null` means unknown, never false.
+Missing SDLC selection (including an older checkpoint without `sdlc`) makes a
+qualifying signal indeterminate. Cite the authority effective for the measured
+window, not a later correction. The ratio flags an inspection; an agent compares
+it with that selection and consequence evidence before diagnosing amplification.
+Product-outcome meaning, selected SDLC and bounded-effect authority remain attributed authored
+evidence; they are not proven merely by ingestion. Findings label that source
+and use medium confidence. Required evidence references must resolve to nonempty,
+readable local files (at most 1 MiB) inside the configured workspace. Absolute
+paths and paths relative to that workspace are supported; other reference kinds
+(including section addresses) remain unavailable. Resolved evidence records carry
+a SHA-256; missing files and symlink escapes remain attributed claims but force
+indeterminate source truth and cannot admit a diagnosis. Availability is checked
+again on every projection; presence does not certify the artifact's meaning.
+This authority assessment is distinct from the
+project/mission/slice documents supplied to the diagnosing agent. Embedded
+context is limited to canonical `SPEC.md` and project/mission/slice YAML files
+at their corresponding work-tree nodes, at most 64 KiB each. Other paths and
+symlink aliases are reported unavailable without embedding their contents.
+Each entry retains its authority level. Project files must be at the configured
+project root; mission files must belong to the finding's mission; slice files
+must also have a sibling `SPEC.md` declaring the finding's slice ID (and matching
+mission when declared). A sibling slice or another mission is unavailable even
+when its filename is canonical. Without mission/slice scope, those authority
+levels remain unavailable.
+
+Checkpoints are audited under `health/checkpoints/history/`; replaying identical
+bytes writes nothing. Later censuses advance observation time. High-to-high
+observations retain episode identity; a clearing checkpoint and later recurrence
+produce a cleared episode and a new ID. Reads never update checkpoint state.
+Stale, unavailable, contradictory, clipped, or missing evidence cannot admit a
+diagnosis. No findings is not a healthy assertion. The current source bounds are
+200 lineages, 10,000 transitions and 1,000 product outcomes per checkpoint, and
+1 MiB per input. Unsupported or invalid sources fail visibly.
+
+## Investigate and record a disposition
+
+Read the exact evidence and the current authority. Trace where the pattern
+began, test whether your own actions amplified it, and distinguish another seat
+or stale guidance. A second opinion is optional. The packet is a starting point,
+not a closed evidence set.
+
+```json
+{
+  "verdict": "insufficient evidence",
+  "causalStart": null,
+  "steering": "Inspect the product-outcome census before changing work.",
+  "uncertainty": "The cited artifact does not yet establish the denominator.",
+  "evidenceRefs": ["<inspected-evidence-path>"]
+}
+```
+
+```sh
+rig health diagnosis record <qitem-id> --file disposition.json
+rig health diagnosis show <qitem-id>
+```
+
+Verdicts are `false positive`, `early real condition`, `established pathology`,
+`insufficient evidence`, or `resolved`. The disposition is retained on the
+diagnostic qitem's transitions and visible in CLI output and the queue. Recording
+it does not close or alter the underlying product work. Changed dispositions
+retain earlier testimony; exact replay is a no-op. A detector clearing is
+recorded separately from an agent declaring the problem resolved.
+
+## Human delivery
+
+An assigned agent may explicitly request human escalation:
+
+```sh
+rig health diagnosis notify <qitem-id>
+```
+
+It requires a registered `human.address` and an admitted `human.conditions`
+entry (`critical`, `established pathology`, or `confirmed ceremony`). The connector must be enabled
+and pass live readiness checks. The current connector implementation verifies
+Slack scopes and channel membership; the diagnosis service itself uses a
+transport-neutral readiness port. The existing gateway owns delivery policy
+and posting. One human request is retained per episode, and its actual delivery
+outcome comes from queue receipts. `pending` is never presented as `posted`.
+Inspect the returned qitem's transitions for the connector receipt. No periodic
+health check performs remediation. With `human.conditions=["confirmed ceremony"]`,
+the enabled diagnosis loop automatically requests one notification for an active,
+confirmed passive ceremony episode. Provisional, indeterminate, cleared, and stale
+episodes never notify. The existing readiness/gateway path owns the effect; an
+unready connector leaves a visible, deduplicated readiness receipt. Later checks
+may retry readiness but never create a second request for an existing episode.
+Read-only list/explain/preview commands never send.
+
+## Read-only consumers and calibration
+
+A consumer such as a later Herder plugin reads `GET /api/health` and
+`GET /api/health/:findingId`, or the identical `rig health --json` and
+`rig health explain <finding-id> --json` records. The record schema is
+`openrig.health/v0alpha1`; list metadata is `openrig.health-list/v0alpha1`.
+Preserve ID, status, policy version, time window, freshness, evidence and
+threshold together. There is no health score or implicit remediation authority.
+The default list excludes cleared records; explicit cleared queries and exact
+ID reads retain them while the source can still project them. A recurrence after
+clear receives a new episode ID. This is an on-demand projection, not a history
+store; a detail 404 does not prove resolution.
+
+Lists default to 100 and cap at 200, with `total` and `truncated` explicit.
+Ceremony findings take precedence before the cap so context pressure cannot
+hide the primary signal. Narrow a truncated query; do not certify the unseen
+remainder. Empty is not healthy, unavailable is not empty, and an indeterminate
+finding cannot authorize a diagnostic occurrence except the explicit, fresh
+`needs-diagnosis` passive candidate described above. An existing occurrence may
+receive one status-observation receipt when its source becomes indeterminate;
+that does not create another obligation or wake.
+
+Live sources supply context pressure, passive ceremony candidates and attributed
+assessments, plus optional ceremony checkpoints.
+Behavioral and epistemic categories intentionally have no detector. Review
+carousel, redundant wakes, stale directives and scope admission have typed
+evaluators and replay controls, but the live source does not infer their missing
+candidate-change, rescue, directive-conflict or admission-authority facts.
+Untagged work and undeclared relationships remain outside passive ceremony
+coverage; normal tagged work no longer requires a special outcome census. A small lineage below the configured threshold may still deserve an
+agent's inspection; the threshold is a conservative admission rule, not a
+definition of good process.
+
+`packages/daemon/scripts/probe-health-calibration.mjs` accepts a sealed replay
+export and output directory after daemon/CLI/TUI builds. It drives the compiled
+checkpoint/list/explain/diagnosis commands, renders the TUI, retains exact
+records and screens, compares database and filesystem effects around reads,
+and measures query cost against declared budgets. Every write uses a disposable
+home and database. Historical expected states must be grounded independently
+of the detector formula; incomplete outcome evidence is an indeterminate case,
+not a denominator of one. A calibration report describes its selected corpus
+and remaining blind spots, not a fleet-wide false-positive rate.

package/daemon/docs/reference/product-journey-sdlc.md

@@ -52,9 +52,10 @@ mission YAML to change.
   implementation momentum.
 - **Skip when:** the current agent can independently state the user outcome,
   starting candidate, and boundaries from primary sources.
-- **Input:** world install, mission/slice YAML, and the addresses it names.
-- **Action:** start or clear a session, load only the selected context, and
-  derive current identity and source state.
+- **Input:** identity, project/mission/slice YAML, and the selected addresses.
+- **Action:** load the selected context into a fresh session, or reorient the
+  current session from live sources. Clearing a seat requires its separate
+  continuity decision; selecting this component does not authorize it.
 - **Output:** a one-paragraph readiness statement naming role, user outcome,
   starting candidate, and boundaries.
 - **Stop:** do not reconstruct old queue lore merely because it exists.
@@ -213,7 +214,8 @@ possible explanation.
 
 ## Composition rules
 
-1. `mission.yaml` may declare the catalog and mission defaults.
+1. `project.yaml` may declare project defaults; `mission.yaml` may select the
+   catalog and override those defaults for the mission.
 2. `slice.yaml` selects or overrides the components for that slice.
 3. Edges are explicit data. Array order is presentation, not dependency.
 4. Select the fewest components that honestly fit the work.
@@ -290,16 +292,52 @@ build.minimal-gap → qa.public-journey → qa.installed-smoke?`
 The recurrence admits one causal descent. It does not authorize a general
 platform rewrite.
 
+## Resolve the selected path
+
+On a fresh start, restore, or new assignment:
+
+1. Derive identity with `rig whoami --json`. Resolve the project's work root from
+   the assignment/workspace binding; `rig config get workspace.root` locates the
+   configured work tree, which may differ from the seat's code checkout.
+2. Read `project.yaml` and its project-authority context. Follow its mission root
+   to the assigned `mission.yaml`, then its composition ref to the active
+   `slice.yaml`. Read the current intent and acceptance files those records name.
+   Do not choose a mission from an old onboarding packet or a folder's recency.
+3. Resolve SDLC selection in order: project defaults, mission defaults, then the
+   active slice's explicit selection/override. A narrower explicit selection
+   replaces the broader component list; it does not append every ancestor's
+   gates. Follow an addressed wave map for its membership, review model and
+   boundary; an explicit named-slice exception applies only to that slice.
+4. Read only the selected components and additional addressed context. Repository
+   references resolve from the code repository root; installed references from
+   `$OPENRIG_HOME/reference`; context-pack refs use `rig context get`. For a
+   Markdown `#section` address, use `loading-addressable-markdown` rather than
+   loading an entire unrelated manual. Expand the investigation when the task's
+   evidence requires it: the address map is a starting point, not a search limit.
+5. State briefly the user outcome, current role, candidate, selected path and
+   next completion boundary. No composition means the light Part A flow in
+   `sdlc-conventions.md#a1-the-flow-in-one-pass`. Do not author a
+   composition merely to have one, or mint QA, guard, review, lock or proof gates
+   because those roles exist. On a tiny change the builder can verify the whole
+   outcome; independent review happens only when selected.
+
+A missing referenced file is a named gap, not evidence of no selection. Inspect
+or ask the owner to resolve a consequential ambiguity; do not silently fall back
+from an explicitly selected rigorous path. An owner can explicitly amend the
+selection for named work; record that decision at the work's authority. Current
+command/source reality outranks stale YAML as a factual claim: record the
+mismatch, re-derive, and preserve the distinction between scope and observed state.
+
+Startup overlays, role guidance, available seats, old mode names and historical
+packets cannot add steps to this selection. They supply capabilities. Skills load
+when the selected work calls for them; there is no quiz, per-file ACK gate or
+universal preloading requirement.
+
 ## Blank-agent start
 
-An agent with only the base world install should:
-
-1. Read `mission.yaml`, then the active `slice.yaml`.
-2. Resolve the catalog address and only the additional addresses those files
-   name.
-3. State: **my role; the user outcome; the starting candidate; the
-   boundaries**.
-4. Follow the selected component edges and their stop conditions.
-5. If no composition exists, use Part A in `mission-slice-sop`.
-6. If current reality contradicts the YAML, stop treating the YAML as fact,
-   record the discrepancy, and re-derive from the public journey and source.
+Follow **Resolve the selected path** above before choosing work. For an authored
+wave, build and verify each slice with its local discipline and integrate serially
+where required; request independent review once when the authored wave boundary
+arrives. Do not start per-slice reviews while waiting. A separately selected
+rigorous slice retains its named checks. Review findings justify bounded repairs,
+not an automatic increase in process for the next round.

package/daemon/docs/reference/sdlc-conventions.md

@@ -68,10 +68,12 @@ intent (what is this for, what does done look like)
       → hand off (rig queue handoff) or stop
 ```
 
-One full-breadth review at the end, not per increment. Bring work when it is **done**. The human
-should almost never see something that doesn't match what was planned — QA catches mismatches and
-kicks them back. When the human looks, they map intent → plan → delivered at a glance, mostly by
-scanning screenshots down a single column, and give the final 1% approval.
+Verify the whole outcome at completion, not through a review chain per increment.
+For a tiny change the builder may hold this check. Independent QA/review runs only
+when selected by the project/mission/slice composition or an explicit owner
+assignment; for a wave, at its authored boundary. Available roles never add gates.
+The authority lookup is `product-journey-sdlc.md#resolve-the-selected-path`.
+Bring work with evidence that its promised user outcome actually works.
 
 For a release mission, `mission.yaml` also names the Git strategy before build
 work starts: the branch/ref that is cumulative integration truth, its base, and

package/daemon/specs/agents/development/implementer/agent.yaml

@@ -27,12 +27,4 @@ startup:
     - path: guidance/role.md
       delivery_hint: send_text
       required: true
-  actions:
-    - type: send_text
-      value: >-
-        A task is coming. BEFORE you do anything else, load and invoke your process skills NOW
-        using your runtime's supported skill mechanism: test-driven-development,
-        systematic-debugging, verification-before-completion. Load them first, then begin the work.
-      phase: after_ready
-      applies_on: [fresh_start, restore]
-      idempotent: true
+  actions: []

package/daemon/specs/agents/development/implementer/guidance/role.md

@@ -1,45 +1,23 @@
 # Role: Implementer
 
-You are the implementation side of a dev pair. Your job is to write code, not to free-run.
-
-## Startup checklist
-
-Load these packaged skills now before editing:
-- `openrig-user`
-- `mission-slice-sop`
-- `development-team`
-- `test-driven-development`
-- `systematic-debugging`
-- `verification-before-completion`
-
-Then run `rig whoami --json` and wait for the orchestrator + QA loop before making changes.
-
-## Responsibilities
-
-- Propose approaches before writing code
-- Follow TDD: write the failing test first, then implement the minimum to pass
-- Run verification after every change: format, lint, type-check, test
-- Submit post-edit review bundles to QA after completing work
-- Commit only after QA approves
-
-## Working rhythm
-
-1. Pre-edit proposal (what you plan to do, which files, what tests)
-2. Wait for QA approval
-3. Implement with TDD (RED -> GREEN -> REFACTOR)
-4. Post-edit review bundle (what changed, verification output)
-5. Wait for QA approval
-6. Commit
-
-## Principles
-
-- Quality over speed. There is no rush.
-- If a test is hard to write, the design needs work.
-- Minimal changes only. Don't refactor code you weren't asked to touch.
-- If the spec seems wrong, raise it. Don't silently diverge.
-
-## Common failure modes
-
-- **Racing through tasks:** Do NOT implement multiple tasks without QA gating each one. Even if you have a clear task list and feel confident, the first action for every task is sending a pre-edit to QA. Not after you've started. Before.
-- **Arguing with QA rejections:** If QA rejects, read the exact feedback, fix the issue, and resubmit with changes called out. Do not argue around it or re-explain why your original approach was fine.
-- **Waiting for orchestrator permission:** You do not need the orchestrator's permission to proceed through a task list. The gated workflow is between you and QA. Only escalate PUSHBACK (genuine architectural disagreements) to the orchestrator.
+Build the assigned complete user outcome and prove it by effect.
+
+## Start from the assignment
+
+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.
+
+## Working contract
+
+Read the relevant seam before editing. Reproduce defects, make the smallest
+coherent correction, and run checks appropriate to the changed behavior. Return
+exact candidate/evidence and uncertainty. Pre-edit approval and independent QA
+are required only when selected; do not ask an idle QA seat to authorize each
+increment. When a selected check finds a defect, repair it and recheck the affected
+outcome without adding a generic second review ladder.

package/daemon/specs/agents/development/qa/agent.yaml

@@ -1,6 +1,6 @@
 name: qa
 version: "1.0"
-description: QA agent — gates every edit with adversarial but cooperative review
+description: QA agent — verifies assigned user outcomes by effect
 
 defaults:
   runtime: codex
@@ -27,13 +27,4 @@ startup:
     - path: guidance/role.md
       delivery_hint: send_text
       required: true
-  actions:
-    - type: send_text
-      value: >-
-        A task is coming. BEFORE you do anything else, load and invoke your process skills NOW
-        using your runtime's supported skill mechanism: test-driven-development,
-        systematic-debugging, verification-before-completion, agent-browser, dogfood. Load them
-        first, then begin the work.
-      phase: after_ready
-      applies_on: [fresh_start, restore]
-      idempotent: true
+  actions: []

package/daemon/specs/agents/development/qa/guidance/role.md

@@ -1,75 +1,23 @@
 # Role: QA
 
-You are the quality assurance side of a dev pair. You gate every edit the implementer makes.
-
-## Startup checklist
-
-Load these packaged skills now before reviewing work or dogfooding:
-- `test-driven-development`
-- `openrig-user`
-- `mission-slice-sop`
-- `development-team`
-- `systematic-debugging`
-- `verification-before-completion`
-- `agent-browser`
-- `dogfood`
-
-Then run `rig whoami --json` and be ready to gate the implementer's first proposal before any edit lands.
-
-## Responsibilities
-
-- Review every pre-edit proposal before the implementer writes code
-- Read actual diffs, not just summaries
-- Run verification independently
-- Check that tests prove the contract, not just the implementation
-- Approve or reject with specific, line-referenced feedback
-
-## What to check
-
-- Does the diff match the approved scope?
-- Are the tests testing the right thing?
-- Are there boundary bugs hiding in the happy path?
-- Does the public contract match what was agreed?
-- Are failure branches honestly handled?
-
-## Dogfood mode
-
-When you are dogfooding (testing existing features, not gating new code):
-- You have full autonomy. Find issues and fix them yourself.
-- Test the fix, then move to the next issue.
-- Only escalate architecture-level concerns to the orchestrator.
-- Report findings to the chatroom so the rig has visibility.
-- Do not wait for approval to fix obvious bugs.
-
-### Browser and UI testing
-
-For UI dogfooding, load the `/agent-browser` and `/dogfood` skills. These give you:
-- `agent-browser open <url>` — navigate to the daemon UI
-- `agent-browser snapshot -i` — get interactive element refs
-- `agent-browser screenshot --annotate` — capture annotated screenshots as proof
-- `agent-browser record start/stop` — record repro videos for issues
-- The `/dogfood` skill provides a structured exploration workflow with a report template
-
-### Dogfood report format
-
-When reporting findings, use:
-- `PASS :: <command or flow> :: <short note>`
-- `FAIL :: <command or flow> :: <exact error or confusing behavior>`
-- `GAP :: <behavior> :: <why it seems wrong or unclear>`
-
-Report to the chatroom so the whole rig has visibility.
-
-## Permission awareness
-
-If the implementer's pane shows a permission prompt or approval dialog and they appear stuck:
-- Call it out immediately via `rig send`
-- Do not treat a blocked pane as "in progress" or "thinking"
-- Permission prompts are the #1 mechanical blocker in the rig
-
-## Principles
-
-- You are not a rubber stamp. Push back when something is wrong.
-- Be specific. "This looks wrong" is not useful. "Line 42 silently drops the error" is.
-- Quality over speed. A rejected edit that gets fixed is better than a merged bug.
-- If you're unsure, ask. Don't approve uncertainty.
-- You are a product voice, not just a test gate. If you see naming, UX, or workflow issues, those are product contributions worth raising.
+Verify the assigned user outcome against its actual contract.
+
+## Start from the assignment
+
+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.
+
+## Working contract
+
+Read the relevant diff and exercise the public journey. Compare promised and
+observed effects, including material failure cases; record what was not checked.
+A tiny change can have builder-held verification. When independent QA is selected,
+the evaluator must not be the author. Load browser/dogfood skills only for a
+relevant UI journey. Respect a read-only assignment; fix-and-retest requires that
+scope, and changes make you an author of the repaired candidate.

package/daemon/specs/agents/orchestration/orchestrator/agent.yaml

@@ -27,12 +27,4 @@ startup:
     - path: guidance/role.md
       delivery_hint: send_text
       required: true
-  actions:
-    - type: send_text
-      value: >-
-        A task is coming. BEFORE you do anything else, load and invoke your process skills NOW
-        using your runtime's supported skill mechanism: systematic-debugging,
-        verification-before-completion. Load them first, then begin the work.
-      phase: after_ready
-      applies_on: [fresh_start, restore]
-      idempotent: true
+  actions: []