bigpowers 2.73.8 → 2.74.0

package/.pi/package.json

@@ -1,7 +1,7 @@
 {
   "name": "bigpowers",
-  "version": "2.73.8",
-  "description": "75 skills — 73 agent skills synthesizing 17 years of software engineering discipline into a prescriptive methodology for solo developers",
+  "version": "2.74.0",
+  "description": "77 skills — 73 agent skills synthesizing 17 years of software engineering discipline into a prescriptive methodology for solo developers",
   "keywords": [
     "pi-package"
   ],

package/.pi/prompts/audit-code.md

@@ -11,11 +11,27 @@ Run this self-review before asking anyone else to look at the code. The goal is
 
 **Distinct from `request-review`:** This is the coding agent checking its own work. No second agent is involved. Run this first; run `request-review` after this passes.
 
+## Look-here-first (churn heuristic)
+
+Before the checklist, rank changed files by git churn and review **high-churn hotspots first** — they carry the most latent risk regardless of diff size.
+
+```bash
+bash scripts/bp-churn-rank.sh --since 90.days --limit 15
+```
+
+Apply the full checklist to churn-ranked files in descending order. Files with zero recent commits but large diffs still get reviewed; churn only sets priority, not scope.
+
 ## Modes
 
 - Default: full checklist
 - --quick: Run only Supply Chain and Test Coverage. Use for changes under 50 LOC.
 - --gate: Non-interactive mode for automated CI gating (used by build-epic step 6). Exit with non-zero status code (`exit 1`) on ANY checklist failure; `exit 0` only if ALL items pass. Produces a compact pass/fail summary to stderr. On failure, list every ✗ item with reason.
+- --parallel: Run checklist sections in **isolated git worktrees** (e45s18) so concurrent checks cannot corrupt each other's working tree. See [REFERENCE.md](REFERENCE.md) or:
+
+```bash
+bash scripts/lib/parallel-review-worktrees.sh audit-code
+```
+
 
 ## Checklist
 
@@ -107,24 +123,12 @@ Report the checklist with ✓ / ✗ per item. For each ✗, describe what needs
 If all items pass: suggest running `request-review` for an independent second opinion.
 If any items fail: fix them before proceeding.
 
-### Gate mode output (`--gate`)
-
-In `--gate` mode, print one summary line per checklist section:
-
-```
-PASS Supply Chain & Security
-FAIL Provenance & Metadata (2 items)
-PASS Law of Demeter
-...
-```
-
-Aggregate exit code: `0` if all sections PASS, `1` (non-zero) if any section FAILs. Write the full audit report to `specs/verifications/AUDIT-<epic>-<story>.md` as a permanent record.
+In `--gate` mode, print one summary line per checklist section (`PASS Supply Chain` / `FAIL Provenance (2 items)`). Exit `0` only if all PASS. Write full report to `specs/verifications/AUDIT-<epic>-<story>.md`.
 
 ## Verify
 
 → verify: `test -f CONVENTIONS.md && test -d skills/enforce-first && test -d skills/request-review && echo "OK: audit-code dependencies present" || echo "FAIL"`
 
-
 ## Handoff
 
 Gate: READY -> next: commit-message

package/.pi/prompts/change-request.md

@@ -3,6 +3,8 @@ description: Add a new requirement or reorder epics by WSJF against specs/releas
 ---
 
 
+# story: e45s29
+
 # Change Request
 
 > **HARD GATE** — `specs/release-plan.yaml` must exist before running either mode. If it doesn't, run `plan-release` first.
@@ -17,7 +19,7 @@ Intake a new requirement mid-flight without disrupting work in progress.
 
 1. **Capture**: What is the change? What problem does it solve?
 2. **Locate**: Which existing stories in `specs/epics/` does it affect or replace?
-3. **Draft**: Add story + `tasks[]` with Gherkin-style AC in epic YAML (each task has `verify`).
+3. **Draft**: Add story + `tasks[]` with Gherkin-style AC in epic YAML (each task has `verify`). Tag requirement deltas: `ADDED` / `MODIFIED` / `REMOVED` / `RENAMED` with before/after for non-`ADDED` changes (e45s29).
 4. **Place**: Append story under existing epic capsule, or create `specs/epics/eNN-slug.yaml` and register in `release-plan.yaml` `epics[]`.
 5. **Score**: Compute WSJF; note if it outranks in-progress work.
 

package/.pi/prompts/compose-workflow.md

@@ -3,6 +3,8 @@ description: Chain multiple bigpowers skills into a custom workflow recipe saved
 ---
 
 
+# story: e45s27
+
 # Compose Workflow
 > **HARD GATE** — **HARD GATE** — Workflows are orchestration, not automation. Do NOT create workflows for tasks that should be single skills. Workflow complexity must be justified.
 
@@ -19,6 +21,19 @@ description: Chain multiple bigpowers skills into a custom workflow recipe saved
 > **Prefer the YAML recipe format** over the legacy `specs/WORKFLOW-<name>.md` markdown format.
 > YAML recipes are command-mappable, machine-readable, and listed in the Standard Recipe Library.
 
+## Terminal-state taxonomy (e45s27)
+
+Every workflow step and `/loop` tick MUST exit with exactly one terminal state:
+
+| State | Meaning | Next action |
+|-------|---------|-------------|
+| `success` | Step verify passed; artifacts written | Advance to next skill in recipe |
+| `no-op` | Nothing to do (already green / already applied) | Skip step; advance |
+| `blocked` | External gate (approval, red CI, missing dep) | `diagnose-stall` or escalate to user |
+| `exhausted` | Max iterations/cycles reached (review cap, dispatch cycles) | Stop; human decision required |
+
+Record terminal state in `specs/state.yaml` `handoff.last_terminal_state` when a recipe step completes. `/loop` ticks that produce no progress for two consecutive wakes → invoke `diagnose-stall`.
+
 ## Standard Recipe Library
 
 Pre-built recipes in `specs/workflows/` map agentic stack commands to skill chains.

package/.pi/prompts/context7-mcp.md

@@ -0,0 +1,54 @@
+---
+description: Fetch current library docs via Context7 MCP instead of training data. Use when user asks about frameworks, APIs, setup, or code examples for React, Next.js, Prisma, etc.
+---
+
+
+# Context7 MCP
+
+> **HARD GATE** — Max **3** Context7 tool calls per user question (`resolve-library-id` + `query-docs` count toward the cap). On quota/rate-limit errors, emit an explicit **CONTEXT7_UNAVAILABLE** block — do NOT silently answer from training data.
+>
+> **HARD GATE** — Before HTTP fetch, check `bash scripts/lib/doc-fetch-cache.sh get "<libraryId>:<query>"`. Cache hit within TTL → use cached body (no round-trip). On ETag mismatch after conditional refresh, replace cache entry.
+
+## When to Use
+
+- Setup/configuration questions ("How do I configure Next.js middleware?")
+- Code involving libraries ("Write a Prisma query for…")
+- API references ("What are the Supabase auth methods?")
+- User mentions specific frameworks (React, Vue, Svelte, Express, Tailwind, etc.)
+
+## Bounded Retry (max 3x)
+
+| Attempt | Action |
+|---------|--------|
+| 1 | `resolve-library-id` → pick best match |
+| 2 | `query-docs` with selected `libraryId` |
+| 3 | Retry `query-docs` once with refined query (narrower scope) |
+
+After 3 failures, stop and print:
+
+```
+CONTEXT7_UNAVAILABLE
+Reason: <quota|rate-limit|no-match|timeout>
+Action: Ask user to retry later, paste official docs URL, or run `bts docs <lib>`.
+Do NOT substitute training-data answers without labeling them UNVERIFIED.
+```
+
+## Fetch Cache (ETag-revalidated)
+
+1. **Cache key:** `"<libraryId>:<normalized-query>"` (lowercase, trimmed).
+2. **Read:** `bash scripts/lib/doc-fetch-cache.sh get "<key>"` — exit 0 → use cached body.
+3. **Miss / stale:** call `query-docs`; store via `doc-fetch-cache.sh put`.
+4. **TTL:** 300s default (`DOC_CACHE_TTL`). Stale entries refresh on next fetch; honor `ETag` when MCP returns it.
+
+`bts docs <lib>` shares the same cache helper when invoked from this skill.
+
+## Process
+
+1. `resolve-library-id` with `libraryName` + full user `query`.
+2. Select match: name similarity, reputation, benchmark score; prefer version-specific IDs when user names a version.
+3. `query-docs` with `libraryId` + specific question (one concept per call).
+4. Answer using fetched docs; cite library/version when relevant.
+
+## Verify
+
+→ verify: `test -f scripts/lib/doc-fetch-cache.sh && grep -q CONTEXT7_UNAVAILABLE skills/context7-mcp/SKILL.md && echo OK || echo FAIL`

package/.pi/prompts/craft-skill.md

@@ -7,6 +7,19 @@ description: Create new bigpowers skills with proper structure, progressive disc
 
 > **HARD GATE** — Do NOT name a skill without a two-word verb-noun pair. Do NOT merge a new skill without running `sync-skills.sh` — the generated `.cursor/rules/` and `.gemini/` artifacts must match the source SKILL.md.
 
+## CSO Description Discipline (e45s02)
+
+The YAML `description` is the **Catalog Selection Object** — the only field agents see when picking a skill.
+
+| Rule | Limit |
+|------|-------|
+| Max length | 1024 characters |
+| Voice | Third person |
+| Content | Capability + `Use when …` triggers only |
+| Forbidden | Workflow steps, phase chains, numbered lists, `→ verify:`, HARD GATE prose |
+
+Move process detail into the SKILL.md body or REFERENCE.md — never into `description`.
+
 ## Process
 
 1. **Gather requirements** — ask user about:
@@ -38,6 +51,12 @@ description: Create new bigpowers skills with proper structure, progressive disc
    - Anything missing or unclear?
    - Should any section be more/less detailed?
 
+6. **Completion-honesty gate (HARD GATE — e45s02)** — Before declaring done:
+   - Run `bash scripts/validate-skill-description.sh skills/<name>/SKILL.md` — must exit 0
+   - Run `bash scripts/sync-skills.sh` — must complete without error
+   - Run `bash scripts/run-skill-verify.sh <name>` if the skill defines a verify command
+   - Show terminal output for each — narration without evidence is rejected
+
 ## Naming Rules
 
 Every skill name must be a **two-word verb-noun pair**. See [REFERENCE.md](REFERENCE.md) for full rules, examples, and documented exceptions.
@@ -51,12 +70,21 @@ If the skill produces written output, it goes in `specs/` at the project root. D
 After drafting, verify:
 
 - [ ] Name is a two-word verb-noun pair (or follows grill-me exception)
+- [ ] Description < 1024 chars, triggers only, no workflow-summary leakage
 - [ ] Description includes triggers ("Use when...")
 - [ ] SKILL.md under 100 lines
 - [ ] No time-sensitive info
 - [ ] Consistent terminology with CONVENTIONS.md
 - [ ] specs/ output documented if applicable
+- [ ] `validate-skill-description.sh` exits 0
 - [ ] `sync-skills.sh` run to propagate to Cursor/Gemini
+- [ ] `bash scripts/validate-skill-catalog.sh` passes for the new skill (HARD GATE — completion honesty)
+
+> **HARD GATE** — Do NOT declare the skill done until `bash scripts/validate-skill-catalog.sh --strict --skill <name>` exits 0. Validator enforces verb-noun name, HARD GATE block, description ≤1024 chars, and `→ verify:` command.
+
+## Verify
+
+→ verify: `bash scripts/validate-skill-catalog.sh --strict --skill craft-skill && bash scripts/validate-skill-description.sh skills/craft-skill/SKILL.md && echo OK || echo FAIL`
 
 ---
 

package/.pi/prompts/deepen-architecture.md

@@ -43,6 +43,12 @@ Read existing documentation first:
 
 If any of these files don't exist, proceed silently — don't flag their absence or suggest creating them upfront.
 
+**Look-here-first (churn heuristic):** Before organic exploration, rank candidate modules by recent commit frequency. High-churn files are architectural friction magnets — start there.
+
+```bash
+bash scripts/bp-churn-rank.sh --since 90.days --limit 20
+```
+
 Then use the Agent tool with `subagent_type=Explore` to walk the codebase. Don't follow rigid heuristics — explore organically and note where you experience friction:
 
 - Where does understanding one concept require bouncing between many small modules?
@@ -91,6 +97,20 @@ Side effects happen inline as decisions crystallize:
 - **User rejects the candidate with a load-bearing reason?** Offer an ADR, framed as: _"Want me to record this as an ADR so future architecture reviews don't re-suggest it?"_ Only offer when the reason would actually be needed by a future explorer. See [ADR-FORMAT.md](../model-domain/ADR-FORMAT.md).
 - **Want to explore alternative interfaces for the deepened module?** See [INTERFACE-DESIGN.md](INTERFACE-DESIGN.md).
 
+### 5. Import-boundary hygiene (e45s14)
+
+When a deepening move **splits or merges modules**, update `specs/import-boundaries.json` (Playwright `DEPS.list` pattern) — declare which `scripts/lib/*.sh` files may `source` which peers. CI enforces via:
+
+```bash
+bash scripts/check-import-boundaries.sh
+```
+
+Run the check before proposing cross-module `source` edges. Convention docs alone do not authorize new imports; the allowlist must list them.
+
+## Verify
+
+→ verify: `test -f specs/import-boundaries.json && bash scripts/check-import-boundaries.sh && echo OK || echo FAIL`
+
 ---
 
 # Deepening

package/.pi/prompts/delegate-task.md

@@ -3,6 +3,8 @@ description: Delegate one complex task to a single subagent, review its work in
 ---
 
 
+# story: e45s30
+
 # Delegate Task
 > **HARD GATE** — **HARD GATE** — Delegated work must have clear success criteria and verification commands. The delegate must be able to verify completion independently.
 
@@ -11,6 +13,18 @@ Delegate a single complex task to a subagent with a two-stage review gate before
 
 **Distinct from `dispatch-agents`:** This skill runs one subagent sequentially with a mandatory review. `dispatch-agents` runs multiple subagents in parallel without inter-task review gates.
 
+## Subagent depth tiers (e45s30)
+
+Select brief depth from task `risk:` and skill `effort:` before spawning:
+
+| Tier | When | Brief includes |
+|------|------|----------------|
+| `full_maturity` | P0 stories, multi-file refactors, security work | Full template + CONVENTIONS excerpts + threat model if present |
+| `standard` | Default implementation tasks | Goal, scope, out-of-bounds, constraints, verify, prior decisions |
+| `minimal_decisive` | Light probes, read-only audits | Goal, verify, explicit file list (≤15 lines total) |
+
+State `depth: <tier>` in the Agent tool description field.
+
 ## Process
 
 ### 1. Define the task

package/.pi/prompts/deploy.md

@@ -103,6 +103,14 @@ For comprehensive health-checking, chain to the `smoke-test` skill:
 bash scripts/run-smoke.sh "$DEPLOY_URL"
 ```
 
+### 7. Three-independent-facts verification (e45s15)
+
+Before declaring deploy success, verify **three independent facts** — build artifact, platform accept, live/registry reachability. See [REFERENCE.md](REFERENCE.md#three-independent-facts).
+
+## Verify
+
+→ verify: `command -v curl >/dev/null 2>&1 && grep -qi 'three-independent-facts' skills/deploy/SKILL.md && echo OK || echo FAIL`
+
 ---
 
 # Deploy — Reference

package/.pi/prompts/develop-tdd.md

@@ -49,16 +49,27 @@ Apply the **enforce-first** F.I.R.S.T rubric: Fast, Independent, Repeatable, Sel
 Write ONE test that confirms ONE thing about the system:
 
 ```
-RED:    Write test for first behavior → test fails → commit: test(<scope>): ...
-GREEN:  Write minimal code to pass → test passes → commit: feat(<scope>): ...
+RED:    Write test for first behavior → test fails → commit: test(<scope>): ...  (test-only; red in CI)
+GREEN:  Write minimal code to pass → test passes → commit: feat(<scope>): ...   (fix commit; green)
 REFACTOR (optional): clean up → commit: refactor(<scope>): ...
 ```
 
+> **Two-commit red/green policy (HARD GATE — e45s08)** — Each behavior cycle requires **two separate commits**: (1) test-only commit that fails in CI (RED), then (2) implementation commit that makes it pass (GREEN). Never combine test + fix in one commit. Show `git log -2 --oneline` as evidence before proceeding to the next behavior.
+
+> **tasks.yaml ledger (e45s06)** — After each task's `verify:` exits 0, update `eNNsYY-tasks.yaml`: set that task's `status: passing`. Story-level `status: passing` only when all tasks pass.
+
 ### 3. Incremental Loop
 
-> **STREAM CONTINUITY** — When writing file content, output in continuous chunks of ~200 lines. Do not pause. Emit a placeholder comment rather than going silent.
+> **Snapshot-before-transition (e45s34):** Before each RED → GREEN or GREEN → REFACTOR transition, create a checkpoint so a failed transition can be rolled back cleanly:
+
+```bash
+bash scripts/bp-yaml-snapshot.sh specs/state.yaml   # if state changed this cycle
+git stash push -m "tdd-checkpoint-$(git rev-parse --short HEAD)-red" --keep-index 2>/dev/null || true
+```
+
+After GREEN passes and is committed, drop the stash (`git stash drop` if empty). Never refactor while RED.
 
-For each remaining behavior: RED → GREEN → REFACTOR (optional). One test at a time. Commit after every GREEN phase.
+For each remaining behavior: RED → GREEN → REFACTOR (optional). One test at a time. **Two commits per behavior** (test-only RED, then fix GREEN). Commit after every GREEN phase.
 
 ### 4. Visual Slices (UI alternate workflow)
 

package/.pi/prompts/diagnose-stall.md

@@ -0,0 +1,53 @@
+---
+description: Diagnose why agent orchestration stopped producing progress — silent stalls in /loop, dispatch-agents, or execute-plan. Use when work appears hung, no output for several minutes, or a subagent never returned.
+---
+
+
+# Diagnose Stall
+
+> **HARD GATE** — Do NOT restart work blindly. Run this diagnostic first when orchestration goes quiet without an explicit terminal state.
+
+Explicit handler for silent stalls in long-running agent workflows (`/loop`, `dispatch-agents`, `execute-plan`, `build-epic` resume mode).
+
+## Stall signals
+
+| Signal | Likely cause |
+|--------|----------------|
+| No stdout for >5 min on a monitored loop tick | Sleep/watcher misconfigured or prompt never re-armed |
+| Subagent dispatched but no completion message | Agent hung, blocked on approval, or scope too large |
+| `dispatch-agents` cycle 3 reached with gaps | Circuit exhausted — needs human escalation |
+| Verify command running >15 min | Missing timeout or waiting on external service |
+| `handoff.next_skill` unchanged across turns | Prior skill never wrote handoff |
+
+## Process
+
+1. **Read state** — `specs/state.yaml`: `handoff.next_skill`, `active_flow`, `metrics.story_start`, open decisions.
+2. **Check locks** — `bash scripts/check-stale-locks.sh` if present; read `specs/agent-locks.yaml`.
+3. **Inspect terminals** — list background shells; note PIDs, last output timestamp, exit codes.
+4. **Classify stall type:**
+   - **waiting_approval** — tool blocked on user consent
+   - **blocked_dependency** — prior task incomplete or red gate
+   - **agent_exhausted** — max iterations/cycles reached
+   - **misconfigured_loop** — duplicate sentinel, wrong regex, or sleeper not re-armed
+   - **external_io** — network, CI, or deploy wait without timeout
+   - **unknown** — escalate with evidence bundle
+5. **Recommend recovery** — one action only (resume, kill PID, re-dispatch with smaller brief, escalate to user).
+6. **Write report** — `specs/verifications/STALL-<timestamp>.md` with classification, evidence, and recommended next skill.
+
+## Integration
+
+| Caller | When to invoke |
+|--------|----------------|
+| `/loop` (Cursor) | After two consecutive ticks with no observable progress |
+| `dispatch-agents` | When a wave exceeds expected duration with zero returns |
+| `execute-plan` | When a step checkpoint is overdue |
+| User | "Why did this stop?" / "Nothing is happening" |
+
+## Verify
+
+→ verify: `test -f specs/state.yaml && echo "OK: diagnose-stall can read session state" || echo "WARN: no state.yaml — diagnostic limited"`
+
+## Handoff
+
+Gate: READY → next: survey-context (if state unclear) or resume prior skill from `state.yaml`
+Writes: `specs/verifications/STALL-*.md`

package/.pi/prompts/dispatch-agents.md

@@ -3,6 +3,8 @@ description: Dispatch multiple subagents in parallel on independent tasks. No wa
 ---
 
 
+# story: e45s30
+
 # Dispatch Agents
 > **HARD GATE** — **HARD GATE** — Agent work must be parallelizable and have explicit synchronization points. Do NOT dispatch work that has hidden dependencies between agents.
 
@@ -34,30 +36,57 @@ Before dispatching, verify each task pair is truly independent:
 
 If any two tasks conflict, sequence them with `delegate-task` or `execute-plan` instead.
 
-### 2. Write task briefs
+## Subagent depth tiers (e45s30)
 
-Before writing briefs, read `specs/state.yaml` if it exists — each agent gets only the decisions relevant to its task, nothing else.
+Map `effort:` frontmatter and story `risk:` to prompt depth — do not send `minimal_decisive` agents a `full_maturity` brief.
 
-For each task, use this minimal template (each agent starts cold — brief size directly controls token cost and hallucination risk):
+| Tier | When | Brief shape | Token budget |
+|------|------|-------------|----------------|
+| `full_maturity` | `effort: heavy`, `risk: P0`, security-sensitive diffs | Full `task_brief` + CONVENTIONS excerpts + threat model if present | Full envelope |
+| `standard` | `effort: standard`, `risk: P1`–`P2` | Standard `task_brief` fields below | Default |
+| `minimal_decisive` | `effort: light`, `risk: P3`, read-only exploration | `goal` + `verify` + `in_scope` only | ≤15 lines |
 
+Record `depth: <tier>` in the Agent tool description when dispatching.
+
+### 2. Write typed task briefs (Orca message protocol)
+
+Before writing briefs, read `specs/state.yaml` if it exists — each agent gets only the decisions relevant to its task, nothing else.
+
+Every inter-agent message uses a **typed envelope** — no freeform prose between waves:
+
+| `type` | When | Required fields |
+|--------|------|-----------------|
+| `task_brief` | Dispatch | `task_id`, `goal`, `in_scope`, `out_of_bounds`, `verify`, `prior_decisions` |
+| `checkpoint` | Mid-wave progress | `task_id`, `status` (`running`\|`blocked`), `comment` (one line) |
+| `result` | Agent return | `task_id`, `exit` (`pass`\|`fail`), `summary`, `verify_output` |
+| `circuit_open` | 3 consecutive failures | `task_id`, `failures` (3), `escalate_to` (`user`) |
+
+Example `task_brief` (each agent starts cold — brief size directly controls token cost and hallucination risk):
+
+```yaml
+type: task_brief
+task_id: agent-1
+goal: [one sentence — what success looks like]
+in_scope: [explicit file or module list]
+out_of_bounds: [what NOT to touch]
+verify: [runnable command]
+prior_decisions: [relevant entries from specs/state.yaml — omit if none]
 ```
-Goal: [one sentence — what success looks like]
-In scope: [explicit file or module list]
-Out of bounds: [what NOT to touch]
-Verify: [runnable command]
-Prior decisions: [relevant entries from specs/state.yaml — omit section if none apply]
-```
+
+Emit **`checkpoint`** comments when an agent is slow or blocked — one line, no stack traces. Parent reads checkpoints before spawning follow-ups.
 
 Do not include the full conversation, full file contents, or decisions unrelated to this agent's task.
 
-### 3. Iterative retrieval (max 3 cycles)
+### 3. Circuit breaker + iterative retrieval (max 3 cycles)
+
+Track **consecutive failures per `task_id`**. On the **3rd consecutive `result.exit: fail`** for the same task, emit `type: circuit_open` and **stop dispatching** that task — escalate to user with the three failure summaries. Reset counter on any `pass`.
 
 After each wave completes:
-1. **Dispatch** — run parallel agents with briefs.
-2. **Evaluate** — read outputs; list gaps vs goal.
+1. **Dispatch** — run parallel agents with typed `task_brief` envelopes.
+2. **Evaluate** — read `result` messages; list gaps vs goal; honor open circuits.
 3. **Refine** — tighten briefs or spawn follow-up agents (max **3 cycles** total).
 
-Stop when gaps empty or cycle 3 reached — escalate to user.
+Stop when gaps empty, circuit opens, or cycle 3 reached — escalate to user. If agents go silent without returning, invoke `diagnose-stall` before spawning another wave.
 
 ### 4. Dispatch in parallel
 
@@ -71,13 +100,14 @@ Agent 3: brief for task C
 
 ### 5. Collect and review results
 
-When all agents return:
-- Review each result independently
-- Run all verify commands
-- Check diffs for scope violations or CONVENTIONS.md breaches
+When all agents return: review each result, run verify commands, check diffs for scope violations.
 
 ### 6. Integrate
 
-Merge accepted results. If any agent's result conflicts with another, resolve manually and note the conflict.
+Merge accepted results. Resolve conflicts manually; note in summary.
+
+Report: which tasks succeeded, which need revision, overall verify status.
+
+## Verify
 
-Report a summary: which tasks succeeded, which need revision, and overall verify status.
+→ verify: `grep -q 'circuit_open' skills/dispatch-agents/SKILL.md && grep -q 'task_brief' skills/dispatch-agents/SKILL.md && echo OK || echo FAIL`

package/.pi/prompts/gate-trace.md

@@ -36,7 +36,15 @@ TEA-inspired: if trace links rely on heuristics rather than explicit tags, confi
 5. Apply oracle confidence downgrade based on the heuristic link ratio from the matrix's `oracle_stats`.
 6. **Drift check (e39s03):** If `specs/drift-report.json` exists and has suspect links, mark verdict as CONCERNS with note: "Drift detected — some implementing files are newer than their specs. Run scripts/check-spec-drift.sh for details."
 7. Output verdict + rationale to stdout.
-7. Update `specs/execution-status.yaml` with gate-trace result.
+8. **Adversarial refute check (e45s32):** Before emitting PASS, attempt to **refute** the verdict — list at least one concrete traceability gap that would block merge if it were real. If the gap is real, downgrade the verdict. Rubber-stamping is prohibited; every PASS must survive one refutation attempt.
+9. **Completeness critic (e45s05)** — Run adversarial gap-finding:
+
+```bash
+bash scripts/lib/completeness-critic.sh
+```
+
+Classify output as **BLOCKER / WARNING / FILLED**. **BLOCKER overrides any PASS verdict → FAIL.** Append critic summary to rationale.
+10. Update `specs/execution-status.yaml` with gate-trace result.
 
 ## Verdict Semantics
 

package/.pi/prompts/guard-git.md

@@ -46,6 +46,20 @@ Full JSON examples, merge rules, Antigravity deny-list entries, and test command
 
 # Git guardrails — reference
 
+## Navigation
+
+| Lines | Section |
+|-------|---------|
+| 1 | Title |
+| 3–14 | Navigation |
+| 16–24 | Secret patterns |
+| 26–44 | Copy layout |
+| 46–72 | Claude Code |
+| 74–92 | Cursor and Cursor CLI |
+| 94–120 | Gemini CLI |
+| 122–135 | Google Antigravity |
+| 137–178 | Verify (local tests) |
+
 ## Secret patterns (audit + pre-commit)
 
 Agents must not commit files containing:

package/.pi/prompts/migrate-spec.md

@@ -238,6 +238,18 @@ These GSD artifacts are not migrated — they are execution records, not plannin
 
 # Migrate Spec — Reference
 
+## Navigation
+
+| Lines | Section |
+|-------|---------|
+| 1 | Title |
+| 3–22 | Navigation |
+| 24–62 | spec-kit → bigpowers Mapping |
+| 64–130 | BMAD → bigpowers Mapping |
+| 132–154 | Learnings to Adopt |
+| 156–350 | Output Formats + state.yaml template |
+| 352–620 | Reference blocks 1–2 + extended mappings |
+
 # migrate-spec Reference — spec-kit, BMAD, Learnings
 
 Transformation rules for spec-kit and BMAD projects, plus learnings to adopt and output formats.