bigpowers 2.71.0 → 2.72.0

package/.pi/package.json

@@ -1,6 +1,6 @@
 {
   "name": "bigpowers",
-  "version": "2.71.0",
+  "version": "2.72.0",
   "description": "75 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

@@ -49,7 +49,8 @@ Run this self-review before asking anyone else to look at the code. The goal is
 - [ ] Changes are limited to what was asked — nothing extra refactored or reorganized
 - [ ] No speculative features added
 - [ ] No files touched outside the stated scope
-- [ ] Changes are surgical: only code strictly required for the task; no refactoring, reorganization, or cleanup outside task scope (Boy Scout Rule applied surgically, not broadly)
+- [ ] **Discovered defects:** Reproducible gate failures (Preflight, CI, golden suite) require fix-or-log — `quick-fix` or `fix-bug` — even when "outside" the story scope. Scope-minimization does not waive Always Green.
+- [ ] Boy Scout Rule applies to files opened to fix a gate failure; it does not excuse skipping red Preflight
 
 ### Boy Scout Rule
 

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

@@ -27,6 +27,8 @@ If you catch yourself thinking these, stop and reconsider — you are likely dev
 | "I'm just fixing a small bug." | Small bugs often indicate deep interface flaws. Investigate root cause. |
 | "I need to mock this internal class." | Mocking internals couples tests to implementation. Mock only I/O. |
 | "This refactor is out of scope." | Leave the code cleaner than you found it (Boy Scout Rule). |
+| "Preflight failed but it's unrelated." | **Always Green:** any reproducible gate failure routes **quick-fix → fix-bug** before forward work. Session boundaries do not waive Preflight. |
+| "I'll note the red gate and continue." | Narrating a failure is banned. fix-or-log is mandatory per CONVENTIONS § Discovered Defects. |
 
 ## Workflow
 

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

@@ -9,7 +9,7 @@ description: Benchmark-gated skill evolution — consume bigpowers-benchmark rep
 
 ## Loop
 
-1. **Regression gate** — Run `bash scripts/run-golden-suite.sh` to catch mechanical regressions (compliance, sync pipeline, size budget) before spending time on benchmark evals. If golden suite fails, fix regressions first — they are pre-requisites for any capability improvement.
+1. **Regression gate** — Run `bash scripts/run-verification-gates.sh` to catch mechanical regressions (compliance, sync pipeline, size budget) before spending time on benchmark evals. If golden suite fails, fix regressions first — they are pre-requisites for any capability improvement.
 2. **Establish baseline** — Run `run-benchmark <skill> --baseline`. If no definition exists at `specs/benchmarks/<skill>.yaml`, create one following `specs/benchmarks/SCHEMA.md` first. Save report path in `state.yaml`. If `specs/benchmarks/reports/BASELINE-<skill>.yaml` already exists, skip this step.
 
 3. **Identify gap** — Read the baseline report (`specs/benchmarks/reports/BASELINE-<skill>.yaml`). Find scenarios with `result: FAIL` or low `pass_at_k`. This is the measurable gap.

package/.pi/prompts/fix-bug.md

@@ -11,6 +11,16 @@ Orchestrates **fix_bug** flow without mixing epic build state.
 
 > **HARD GATE** — Set `specs/state.yaml` `active_flow: fix_bug` and `bug_cycle.current_step: 1` before starting.
 
+## Discovered gate failures (e51s04)
+
+Valid entry **without a user-reported bug** when:
+
+- **Preflight** or **CI** is red at kickoff or verify-work
+- **Golden suite** or project baseline is red (`bash scripts/run-verification-gates.sh` or equivalent)
+- A reproducible gate failure during unrelated epic work exceeds quick-fix guardrails
+
+Create `specs/bugs/BUG-*.md` via `investigate-bug` (or inline in fix-bug step 1) describing the gate failure, then run the standard fix_bug chain.
+
 ## Five steps (`bug_cycle` in state.yaml)
 
 | Step | Skill / action |

package/.pi/prompts/kickoff-branch.md

@@ -7,9 +7,9 @@ description: Create a git worktree and feature branch, then verify a clean test
 
 > **HARD GATE** — Direct work on `main` or `master` is PROHIBITED. Every task MUST start with this skill to create a feature branch or worktree.
 >
-> **HARD GATE** — Do NOT proceed with development until a clean test baseline is verified. If the current base branch is failing tests, stop and fix the baseline before creating a new worktree.
+> **HARD GATE** — Do NOT proceed with development until **Preflight** passes on the default branch. Red Preflight blocks branch creation and all forward work — invoke `quick-fix` or `fix-bug` per CONVENTIONS § Discovered Defects.
 
-Create an isolated working environment before touching any code. A clean baseline proves tests pass before you start — so any failure you see later was caused by your changes, not pre-existing issues.
+Create an isolated working environment before touching any code. **Preflight must be green** before you write feature code — solo-default owns the whole tree, not just the current task diff.
 
 ## Process
 
@@ -112,32 +112,25 @@ fi
 
 If locked: abort. If unlocked: entry added, proceed.
 
-Run the full test suite and confirm it passes before writing any code:
+Run **Preflight** (from `CLAUDE.md` Commands table, or `BP_PREFLIGHT` from `bash scripts/bp-read-agents.sh`) and confirm green before writing any code:
 
 ```bash
-# Use the project's test command from CLAUDE.md or package.json
-npm test    # or: pytest, go test ./..., cargo test, etc.
+# Preflight — project's full local verification stack
+# bigpowers example:
+npm run compliance && bash scripts/run-verification-gates.sh
+
+# Or project-specific from CLAUDE.md / AGENTS.md
 ```
 
-- [ ] All tests pass
-- [ ] No type errors (`npm run typecheck` or equivalent)
-- [ ] No lint errors (`npm run lint` or equivalent)
+- [ ] Preflight passes (all chained gates green)
+- [ ] No type errors (`npm run typecheck` or equivalent, if not in Preflight)
+- [ ] No lint errors (`npm run lint` or equivalent, if not in Preflight)
 
-If the baseline is broken, **stop and tell the user**. Do not proceed with development on a broken baseline.
+If Preflight is red, **stop** — route to `quick-fix` or `fix-bug`. Fix before kickoff continues.
 
 ### 5. Confirm readiness
 
-Report the baseline result:
-```
-✓ Baseline clean: 42 tests passed, 0 failed
-Branch: <task-slug>
-Worktree: ../<task-slug>
-Ready to develop.
-```
-
-Suggest next skill: `develop-tdd` to start the TDD loop, or `execute-plan` if `specs/release-plan.yaml + epic capsule directories` already exists.
-
-
+Report: `✓ Preflight green` + branch + worktree. Suggest next: `develop-tdd` or `execute-plan`.
 
 ## Handoff
 

package/.pi/prompts/quick-fix.md

@@ -12,6 +12,10 @@ Fast-track for trivial data-only fixes that do not require the full bug-fix chai
 
 When a bug fix is purely data — an add-missing-key, a typo correction, a config value update — the standard 6-skill chain (investigate-bug → diagnose-root → develop-tdd → kickoff-branch → verify-work → release-branch) is wasteful overhead. Quick-fix collapses it to 2 skills: **quick-fix** then **release-branch**.
 
+## Discovered gate failures (e51s04)
+
+A **Preflight**, **golden suite**, or **baseline red** failure discovered during unrelated work is valid quick-fix entry when the root cause is a data-only gap (missing key, typo, stale config) — **no user-reported bug required**. If guardrails abort (logic change, >1 file, >5 lines), fall back to `fix-bug` instead of narrating and continuing.
+
 ## Entry Criteria (ALL must be true)
 
 Before invoking quick-fix, evaluate every item in this checklist:

package/.pi/prompts/seed-conventions.md

@@ -24,12 +24,12 @@ Ask the user these questions (one at a time, wait for each answer):
 2. **Stack** — "What language, framework, and runtime? (e.g. TypeScript / Next.js / Node 22)"
 2b. **Stack profile (optional)** — Offer: `swift`, `typescript-vue`, `node-service`, or none. If chosen, merge the matching fragment from `profiles/<name>.md` into generated `CONVENTIONS.md`.
 3. **Commands** — "What commands do you use for: run, test, build, lint?"
+3b. **Preflight (optional)** — "What single command runs your full local green stack (test + lint + build)? If you don't have one, we'll chain your Test + Lint + Build answers into a **Preflight** row in the Commands table."
 4. **Architecture** — "Key modules and relationships in 1–2 sentences."
 5. **Conventions** — "Any naming, file organization, or patterns all agents must follow?"
 6. **Never-do list** — "What are the hard stops? Things an agent must never touch?"
 7. **Defensive code categories** — "Which apply? (Rate limit / Retry / Circuit breaker / Timeout / Graceful degradation)"
 8. **Local tool wiring (optional)** — "Wire bigpowers skills for project-local tools that global install can't reach? (Cursor + OpenCode only)" If yes, generate the local wiring artifacts described in [REFERENCE.md](REFERENCE.md) §Local tool wiring. If no, skip — the standard seed output is unchanged.
-8. **Local tool wiring (optional)** — "Wire bigpowers skills for project-local tools that global install can't reach? (Cursor + OpenCode only)" If yes, generate the local wiring artifacts described in [REFERENCE.md](REFERENCE.md) §Local tool wiring. If no, skip — the standard seed output is unchanged.
 
 ## Generate files
 
@@ -54,7 +54,9 @@ echo "# Specs\n\nAll planning documents for this project." > specs/README.md
 
 **Note:** `specs/state.yaml.lock` is NOT pre-created — acquired/released dynamically.
 
-`specs/state.yaml` carries a top-level `workflow_mode` key (`team-pr` | `solo-git`, default `team-pr`). This is the **canonical integrate-mode signal** for all skills — set it once here and skills such as `release-branch` read it from this file instead of sniffing profile files.
+`specs/state.yaml` carries a top-level `workflow_mode` key (`team-pr` | `solo-git`, default `solo-git`). This is the **canonical integrate-mode signal** for all skills — set it once here and skills such as `release-branch` read it from this file instead of sniffing profile files.
+
+When generating `CLAUDE.md`, if the user did not name a Preflight command, chain the Test + Lint + Build interview answers into one **Preflight** row (e.g. `npm test && npm run lint && npm run build`).
 
 
 
@@ -69,6 +71,7 @@ echo "# Specs\n\nAll planning documents for this project." > specs/README.md
 
 ---
 
+# story: e51s02
 # Seed Conventions — Reference Templates
 
 ## Agent config template (CLAUDE.md / GEMINI.md / AGENTS.md)
@@ -94,6 +97,8 @@ Stack: [language, framework, runtime]
 | Test   | `[cmd]` |
 | Build  | `[cmd]` |
 | Lint   | `[cmd]` |
+| Preflight | `[test && lint && build chain — or user-named full-green cmd]` |
+| CI     | `gh pr checks` (when a PR is open) |
 
 ## Architecture
 [1–2 sentences. Key modules and their relationships.]
@@ -103,15 +108,17 @@ Stack: [language, framework, runtime]
 - [convention 2]
 
 ## Never
+- Never dismiss reproducible gate failures as pre-existing or out of scope
+- Never proceed on red Preflight or red CI — invoke quick-fix or fix-bug first
 - [hard stop 1]
 - [hard stop 2]
 
 ## Agent Rules
 - **Workflow Mandate:** You MUST use the bigpowers skills (e.g. `plan-work`, `develop-tdd`, `orchestrate-project`) to perform tasks. DO NOT write code directly in response to a user prompt like "build this feature".
+- **Always Green:** Preflight and CI must be green before forward work. Reproducible gate failures require **fix-or-log** (quick-fix → fix-bug) per CONVENTIONS § Discovered Defects.
 - Read specs/ before writing code.
 - All planning and specifications MUST be written to `specs/` (`product/SCOPE_LATEST.yaml`, `release-plan.yaml`, `epics/`) before any code is generated.
 - Write the minimum code that solves the stated problem. Nothing extra.
-- Never refactor, rename, or reorganize code outside the task scope.
 - Run tests after every change. Show evidence before declaring done.
 - One clarifying question beats a wrong assumption baked into 200 lines.
 ```
@@ -129,6 +136,12 @@ Stack: [language, framework, runtime]
 
 Use the standard bigpowers CONVENTIONS.md as the base. Fill in the project-specific defensive code categories from the interview answers.
 
+**Always embed** these doctrine sections from bigpowers (adapt commands only):
+
+- **§ Always Green / Shift Left** — 1-10-100 rationale, Preflight + CI green definitions
+- **§ Discovered Defects** — fix-or-log ladder (quick-fix → fix-bug), separate commits for discovered fixes
+- **Banned dismissive phrases** table — pre-existing, unrelated to session, not introduced by my changes, out of scope (ignoring a red gate)
+
 ## Stack profile fragments
 
 If the user selected a stack profile, merge the matching `profiles/<name>.md` fragment into the generated `CONVENTIONS.md` under a `## Stack Conventions` section. Profiles supply language-specific commands, architecture patterns, and never-do additions.

package/.pi/prompts/verify-work.md

@@ -31,6 +31,8 @@ Review answers "is the code good?"; Verify answers "does the built thing do what
 
 0. **Branch check** — must not be `main`/`master`.
 
+0a. **Preflight / CI green (HARD GATE — e51s03)** — Run Preflight from `CLAUDE.md` or `BP_PREFLIGHT` (`bp-read-agents.sh`). If PR open: `gh pr checks` (**CI green**). Failure blocks all phases → `quick-fix` or `fix-bug`.
+
 1. Read active story tasks from `specs/epics/<capsule>/eNNsYY-tasks.yaml` and story spec from `specs/epics/<capsule>/eNNsYY-<slug>.md` (countable-story-format, Gherkin in §17). Note the `risk:` level (`P0`–`P3`).
 1a. **Pre-UAT verify validation** — for each task's `verify:` command, run it and detect pattern mismatches before UAT begins. If a grep/awk/jq command fails, check whether the pattern is wrong vs. a genuine failure:
     ```bash
@@ -39,7 +41,7 @@ Review answers "is the code good?"; Verify answers "does the built thing do what
     ```
     Report: `"Pattern 'X' not found. Nearest match: 'Y' at line N"` and ask `"Update verify command? [Y/n]"`. Fix before proceeding — a mismatched verify command produces false failures during UAT.
 2. **Cold-start smoke** (if app; skip if P3): stop server, clear caches, boot from scratch.
-3. **AGENTS.md preflight** — before running default checks, call `bash scripts/bp-read-agents.sh` to detect project-specific commands. If `BP_PREFLIGHT` is set, run it instead of the default mechanical gates (or in addition to them if the project requires both). Output: `"Using preflight from AGENTS.md: <cmd>"`. Fall back to `CLAUDE.md` commands if AGENTS.md is absent.
+3. **AGENTS.md preflight** — if 0a skipped BP_PREFLIGHT, run `bash scripts/bp-read-agents.sh` and use detected command.
 4. Mechanical gates: build → typecheck → lint → tests (from `CLAUDE.md` or AGENTS.md). Skip tests if P2/P3.
 5. **Security scan** (skip if P2/P3) — run `security-review` against the git diff (working tree vs merge-base). Parse findings report. If any HIGH findings with confidence ≥ 8 exist → **block the gate**. Write findings to `specs/security/REVIEW.md`. Allow documented exceptions via `specs/security/EXCEPTIONS.md`. MEDIUM/LOW findings warn but don't block.
 5a. **Blind-spot check** — run `bash scripts/check-blind-spots.sh`. This detects structural quality gaps (verify-gap, test-gap, stale-tag, etc.) beyond percentage coverage. If any HIGH-severity findings exist → **block the verify-work PASS gate**. Findings are written to `specs/blind-spots.json`. MEDIUM/LOW findings warn but don't block.
@@ -51,14 +53,7 @@ Review answers "is the code good?"; Verify answers "does the built thing do what
 
 ### Cold-Start Smoke (absorbed)
 
-For applications, verify correctness from a clean state:
-
-- Stop the running server (if any)
-- Clear any caches (browser, application caches, compiled artifacts)
-- Boot the application from scratch
-- Verify that no stale artifacts or configuration are affecting the behavior
-
-This catches environment-specific bugs and ensures the build is reproducible.
+Stop server, clear caches, boot from scratch; confirm no stale config affects behavior.
 
 ### Gaps Loop (absorbed)
 

package/.pi/skills/audit-code/SKILL.md

@@ -51,7 +51,8 @@ Run this self-review before asking anyone else to look at the code. The goal is
 - [ ] Changes are limited to what was asked — nothing extra refactored or reorganized
 - [ ] No speculative features added
 - [ ] No files touched outside the stated scope
-- [ ] Changes are surgical: only code strictly required for the task; no refactoring, reorganization, or cleanup outside task scope (Boy Scout Rule applied surgically, not broadly)
+- [ ] **Discovered defects:** Reproducible gate failures (Preflight, CI, golden suite) require fix-or-log — `quick-fix` or `fix-bug` — even when "outside" the story scope. Scope-minimization does not waive Always Green.
+- [ ] Boy Scout Rule applies to files opened to fix a gate failure; it does not excuse skipping red Preflight
 
 ### Boy Scout Rule
 

package/.pi/skills/develop-tdd/SKILL.md

@@ -29,6 +29,8 @@ If you catch yourself thinking these, stop and reconsider — you are likely dev
 | "I'm just fixing a small bug." | Small bugs often indicate deep interface flaws. Investigate root cause. |
 | "I need to mock this internal class." | Mocking internals couples tests to implementation. Mock only I/O. |
 | "This refactor is out of scope." | Leave the code cleaner than you found it (Boy Scout Rule). |
+| "Preflight failed but it's unrelated." | **Always Green:** any reproducible gate failure routes **quick-fix → fix-bug** before forward work. Session boundaries do not waive Preflight. |
+| "I'll note the red gate and continue." | Narrating a failure is banned. fix-or-log is mandatory per CONVENTIONS § Discovered Defects. |
 
 ## Workflow
 

package/.pi/skills/evolve-skill/SKILL.md

@@ -11,7 +11,7 @@ model: opus
 
 ## Loop
 
-1. **Regression gate** — Run `bash scripts/run-golden-suite.sh` to catch mechanical regressions (compliance, sync pipeline, size budget) before spending time on benchmark evals. If golden suite fails, fix regressions first — they are pre-requisites for any capability improvement.
+1. **Regression gate** — Run `bash scripts/run-verification-gates.sh` to catch mechanical regressions (compliance, sync pipeline, size budget) before spending time on benchmark evals. If golden suite fails, fix regressions first — they are pre-requisites for any capability improvement.
 2. **Establish baseline** — Run `run-benchmark <skill> --baseline`. If no definition exists at `specs/benchmarks/<skill>.yaml`, create one following `specs/benchmarks/SCHEMA.md` first. Save report path in `state.yaml`. If `specs/benchmarks/reports/BASELINE-<skill>.yaml` already exists, skip this step.
 
 3. **Identify gap** — Read the baseline report (`specs/benchmarks/reports/BASELINE-<skill>.yaml`). Find scenarios with `result: FAIL` or low `pass_at_k`. This is the measurable gap.

package/.pi/skills/fix-bug/SKILL.md

@@ -13,6 +13,16 @@ Orchestrates **fix_bug** flow without mixing epic build state.
 
 > **HARD GATE** — Set `specs/state.yaml` `active_flow: fix_bug` and `bug_cycle.current_step: 1` before starting.
 
+## Discovered gate failures (e51s04)
+
+Valid entry **without a user-reported bug** when:
+
+- **Preflight** or **CI** is red at kickoff or verify-work
+- **Golden suite** or project baseline is red (`bash scripts/run-verification-gates.sh` or equivalent)
+- A reproducible gate failure during unrelated epic work exceeds quick-fix guardrails
+
+Create `specs/bugs/BUG-*.md` via `investigate-bug` (or inline in fix-bug step 1) describing the gate failure, then run the standard fix_bug chain.
+
 ## Five steps (`bug_cycle` in state.yaml)
 
 | Step | Skill / action |

package/.pi/skills/kickoff-branch/SKILL.md

@@ -9,9 +9,9 @@ model: haiku
 
 > **HARD GATE** — Direct work on `main` or `master` is PROHIBITED. Every task MUST start with this skill to create a feature branch or worktree.
 >
-> **HARD GATE** — Do NOT proceed with development until a clean test baseline is verified. If the current base branch is failing tests, stop and fix the baseline before creating a new worktree.
+> **HARD GATE** — Do NOT proceed with development until **Preflight** passes on the default branch. Red Preflight blocks branch creation and all forward work — invoke `quick-fix` or `fix-bug` per CONVENTIONS § Discovered Defects.
 
-Create an isolated working environment before touching any code. A clean baseline proves tests pass before you start — so any failure you see later was caused by your changes, not pre-existing issues.
+Create an isolated working environment before touching any code. **Preflight must be green** before you write feature code — solo-default owns the whole tree, not just the current task diff.
 
 ## Process
 
@@ -114,32 +114,25 @@ fi
 
 If locked: abort. If unlocked: entry added, proceed.
 
-Run the full test suite and confirm it passes before writing any code:
+Run **Preflight** (from `CLAUDE.md` Commands table, or `BP_PREFLIGHT` from `bash scripts/bp-read-agents.sh`) and confirm green before writing any code:
 
 ```bash
-# Use the project's test command from CLAUDE.md or package.json
-npm test    # or: pytest, go test ./..., cargo test, etc.
+# Preflight — project's full local verification stack
+# bigpowers example:
+npm run compliance && bash scripts/run-verification-gates.sh
+
+# Or project-specific from CLAUDE.md / AGENTS.md
 ```
 
-- [ ] All tests pass
-- [ ] No type errors (`npm run typecheck` or equivalent)
-- [ ] No lint errors (`npm run lint` or equivalent)
+- [ ] Preflight passes (all chained gates green)
+- [ ] No type errors (`npm run typecheck` or equivalent, if not in Preflight)
+- [ ] No lint errors (`npm run lint` or equivalent, if not in Preflight)
 
-If the baseline is broken, **stop and tell the user**. Do not proceed with development on a broken baseline.
+If Preflight is red, **stop** — route to `quick-fix` or `fix-bug`. Fix before kickoff continues.
 
 ### 5. Confirm readiness
 
-Report the baseline result:
-```
-✓ Baseline clean: 42 tests passed, 0 failed
-Branch: <task-slug>
-Worktree: ../<task-slug>
-Ready to develop.
-```
-
-Suggest next skill: `develop-tdd` to start the TDD loop, or `execute-plan` if `specs/release-plan.yaml + epic capsule directories` already exists.
-
-
+Report: `✓ Preflight green` + branch + worktree. Suggest next: `develop-tdd` or `execute-plan`.
 
 ## Handoff
 

package/.pi/skills/quick-fix/SKILL.md

@@ -14,6 +14,10 @@ Fast-track for trivial data-only fixes that do not require the full bug-fix chai
 
 When a bug fix is purely data — an add-missing-key, a typo correction, a config value update — the standard 6-skill chain (investigate-bug → diagnose-root → develop-tdd → kickoff-branch → verify-work → release-branch) is wasteful overhead. Quick-fix collapses it to 2 skills: **quick-fix** then **release-branch**.
 
+## Discovered gate failures (e51s04)
+
+A **Preflight**, **golden suite**, or **baseline red** failure discovered during unrelated work is valid quick-fix entry when the root cause is a data-only gap (missing key, typo, stale config) — **no user-reported bug required**. If guardrails abort (logic change, >1 file, >5 lines), fall back to `fix-bug` instead of narrating and continuing.
+
 ## Entry Criteria (ALL must be true)
 
 Before invoking quick-fix, evaluate every item in this checklist:

package/.pi/skills/seed-conventions/SKILL.md

@@ -26,12 +26,12 @@ Ask the user these questions (one at a time, wait for each answer):
 2. **Stack** — "What language, framework, and runtime? (e.g. TypeScript / Next.js / Node 22)"
 2b. **Stack profile (optional)** — Offer: `swift`, `typescript-vue`, `node-service`, or none. If chosen, merge the matching fragment from `profiles/<name>.md` into generated `CONVENTIONS.md`.
 3. **Commands** — "What commands do you use for: run, test, build, lint?"
+3b. **Preflight (optional)** — "What single command runs your full local green stack (test + lint + build)? If you don't have one, we'll chain your Test + Lint + Build answers into a **Preflight** row in the Commands table."
 4. **Architecture** — "Key modules and relationships in 1–2 sentences."
 5. **Conventions** — "Any naming, file organization, or patterns all agents must follow?"
 6. **Never-do list** — "What are the hard stops? Things an agent must never touch?"
 7. **Defensive code categories** — "Which apply? (Rate limit / Retry / Circuit breaker / Timeout / Graceful degradation)"
 8. **Local tool wiring (optional)** — "Wire bigpowers skills for project-local tools that global install can't reach? (Cursor + OpenCode only)" If yes, generate the local wiring artifacts described in [REFERENCE.md](REFERENCE.md) §Local tool wiring. If no, skip — the standard seed output is unchanged.
-8. **Local tool wiring (optional)** — "Wire bigpowers skills for project-local tools that global install can't reach? (Cursor + OpenCode only)" If yes, generate the local wiring artifacts described in [REFERENCE.md](REFERENCE.md) §Local tool wiring. If no, skip — the standard seed output is unchanged.
 
 ## Generate files
 
@@ -56,7 +56,9 @@ echo "# Specs\n\nAll planning documents for this project." > specs/README.md
 
 **Note:** `specs/state.yaml.lock` is NOT pre-created — acquired/released dynamically.
 
-`specs/state.yaml` carries a top-level `workflow_mode` key (`team-pr` | `solo-git`, default `team-pr`). This is the **canonical integrate-mode signal** for all skills — set it once here and skills such as `release-branch` read it from this file instead of sniffing profile files.
+`specs/state.yaml` carries a top-level `workflow_mode` key (`team-pr` | `solo-git`, default `solo-git`). This is the **canonical integrate-mode signal** for all skills — set it once here and skills such as `release-branch` read it from this file instead of sniffing profile files.
+
+When generating `CLAUDE.md`, if the user did not name a Preflight command, chain the Test + Lint + Build interview answers into one **Preflight** row (e.g. `npm test && npm run lint && npm run build`).
 
 
 
@@ -71,6 +73,7 @@ echo "# Specs\n\nAll planning documents for this project." > specs/README.md
 
 ---
 
+# story: e51s02
 # Seed Conventions — Reference Templates
 
 ## Agent config template (CLAUDE.md / GEMINI.md / AGENTS.md)
@@ -96,6 +99,8 @@ Stack: [language, framework, runtime]
 | Test   | `[cmd]` |
 | Build  | `[cmd]` |
 | Lint   | `[cmd]` |
+| Preflight | `[test && lint && build chain — or user-named full-green cmd]` |
+| CI     | `gh pr checks` (when a PR is open) |
 
 ## Architecture
 [1–2 sentences. Key modules and their relationships.]
@@ -105,15 +110,17 @@ Stack: [language, framework, runtime]
 - [convention 2]
 
 ## Never
+- Never dismiss reproducible gate failures as pre-existing or out of scope
+- Never proceed on red Preflight or red CI — invoke quick-fix or fix-bug first
 - [hard stop 1]
 - [hard stop 2]
 
 ## Agent Rules
 - **Workflow Mandate:** You MUST use the bigpowers skills (e.g. `plan-work`, `develop-tdd`, `orchestrate-project`) to perform tasks. DO NOT write code directly in response to a user prompt like "build this feature".
+- **Always Green:** Preflight and CI must be green before forward work. Reproducible gate failures require **fix-or-log** (quick-fix → fix-bug) per CONVENTIONS § Discovered Defects.
 - Read specs/ before writing code.
 - All planning and specifications MUST be written to `specs/` (`product/SCOPE_LATEST.yaml`, `release-plan.yaml`, `epics/`) before any code is generated.
 - Write the minimum code that solves the stated problem. Nothing extra.
-- Never refactor, rename, or reorganize code outside the task scope.
 - Run tests after every change. Show evidence before declaring done.
 - One clarifying question beats a wrong assumption baked into 200 lines.
 ```
@@ -131,6 +138,12 @@ Stack: [language, framework, runtime]
 
 Use the standard bigpowers CONVENTIONS.md as the base. Fill in the project-specific defensive code categories from the interview answers.
 
+**Always embed** these doctrine sections from bigpowers (adapt commands only):
+
+- **§ Always Green / Shift Left** — 1-10-100 rationale, Preflight + CI green definitions
+- **§ Discovered Defects** — fix-or-log ladder (quick-fix → fix-bug), separate commits for discovered fixes
+- **Banned dismissive phrases** table — pre-existing, unrelated to session, not introduced by my changes, out of scope (ignoring a red gate)
+
 ## Stack profile fragments
 
 If the user selected a stack profile, merge the matching `profiles/<name>.md` fragment into the generated `CONVENTIONS.md` under a `## Stack Conventions` section. Profiles supply language-specific commands, architecture patterns, and never-do additions.

package/.pi/skills/verify-work/SKILL.md

@@ -33,6 +33,8 @@ Review answers "is the code good?"; Verify answers "does the built thing do what
 
 0. **Branch check** — must not be `main`/`master`.
 
+0a. **Preflight / CI green (HARD GATE — e51s03)** — Run Preflight from `CLAUDE.md` or `BP_PREFLIGHT` (`bp-read-agents.sh`). If PR open: `gh pr checks` (**CI green**). Failure blocks all phases → `quick-fix` or `fix-bug`.
+
 1. Read active story tasks from `specs/epics/<capsule>/eNNsYY-tasks.yaml` and story spec from `specs/epics/<capsule>/eNNsYY-<slug>.md` (countable-story-format, Gherkin in §17). Note the `risk:` level (`P0`–`P3`).
 1a. **Pre-UAT verify validation** — for each task's `verify:` command, run it and detect pattern mismatches before UAT begins. If a grep/awk/jq command fails, check whether the pattern is wrong vs. a genuine failure:
     ```bash
@@ -41,7 +43,7 @@ Review answers "is the code good?"; Verify answers "does the built thing do what
     ```
     Report: `"Pattern 'X' not found. Nearest match: 'Y' at line N"` and ask `"Update verify command? [Y/n]"`. Fix before proceeding — a mismatched verify command produces false failures during UAT.
 2. **Cold-start smoke** (if app; skip if P3): stop server, clear caches, boot from scratch.
-3. **AGENTS.md preflight** — before running default checks, call `bash scripts/bp-read-agents.sh` to detect project-specific commands. If `BP_PREFLIGHT` is set, run it instead of the default mechanical gates (or in addition to them if the project requires both). Output: `"Using preflight from AGENTS.md: <cmd>"`. Fall back to `CLAUDE.md` commands if AGENTS.md is absent.
+3. **AGENTS.md preflight** — if 0a skipped BP_PREFLIGHT, run `bash scripts/bp-read-agents.sh` and use detected command.
 4. Mechanical gates: build → typecheck → lint → tests (from `CLAUDE.md` or AGENTS.md). Skip tests if P2/P3.
 5. **Security scan** (skip if P2/P3) — run `security-review` against the git diff (working tree vs merge-base). Parse findings report. If any HIGH findings with confidence ≥ 8 exist → **block the gate**. Write findings to `specs/security/REVIEW.md`. Allow documented exceptions via `specs/security/EXCEPTIONS.md`. MEDIUM/LOW findings warn but don't block.
 5a. **Blind-spot check** — run `bash scripts/check-blind-spots.sh`. This detects structural quality gaps (verify-gap, test-gap, stale-tag, etc.) beyond percentage coverage. If any HIGH-severity findings exist → **block the verify-work PASS gate**. Findings are written to `specs/blind-spots.json`. MEDIUM/LOW findings warn but don't block.
@@ -53,14 +55,7 @@ Review answers "is the code good?"; Verify answers "does the built thing do what
 
 ### Cold-Start Smoke (absorbed)
 
-For applications, verify correctness from a clean state:
-
-- Stop the running server (if any)
-- Clear any caches (browser, application caches, compiled artifacts)
-- Boot the application from scratch
-- Verify that no stale artifacts or configuration are affecting the behavior
-
-This catches environment-specific bugs and ensures the build is reproducible.
+Stop server, clear caches, boot from scratch; confirm no stale config affects behavior.
 
 ### Gaps Loop (absorbed)
 

package/CHANGELOG.md

@@ -1,3 +1,10 @@
+# [2.72.0](https://github.com/danielvm-git/bigpowers/compare/v2.71.0...v2.72.0) (2026-07-06)
+
+
+### Features
+
+* **gates:** Always Green — preflight hard block & fix-or-log ([cfd572d](https://github.com/danielvm-git/bigpowers/commit/cfd572db09315895273466a72c55c0e7ab3d2b64))
+
 # [2.71.0](https://github.com/danielvm-git/bigpowers/compare/v2.70.1...v2.71.0) (2026-07-06)
 
 

package/CLAUDE.md

@@ -1,4 +1,5 @@
 # story: e38s08
+# story: e51s05
 
 # bigpowers — Claude Code
 
@@ -22,15 +23,17 @@ Stack: Markdown / Bash (documentation-based; skills integrate with Claude Code,
 | Typecheck | N/A (Markdown / Bash project) |
 | CI platform | GitHub Actions (`.github/workflows/publish.yml`, `sync-skills.yml`) |
 | Compliance | `npm run compliance` |
-| Golden Suite | `bash scripts/run-golden-suite.sh` |
+| Verification Gates | `bash scripts/run-verification-gates.sh` |
 | Traceability | `bash scripts/trace-stories.sh --strict` | grep for story tags (traceability check) |
+| Preflight | `npm run compliance && bash scripts/run-verification-gates.sh && bash scripts/sync-skills.sh && bash scripts/trace-stories.sh --strict` | Full local green stack before forward work |
+| CI | `gh pr checks` | Remote CI green when a PR is open |
 
 ### Pre-Merge Checklist
 
 Before opening a PR or landing a branch, run:
 
 ```bash
-npm run compliance && bash scripts/run-golden-suite.sh
+npm run compliance && bash scripts/run-verification-gates.sh
 ```
 
 If any gate fails, fix before merging. Run `--baseline` after any intentional increase in skill count or structure.
@@ -85,9 +88,9 @@ Before any task, run this sequence — not optional:
 ## Agent Rules
 
 - **Workflow Mandate:** You MUST use the bigpowers skills (e.g., `plan-work`, `develop-tdd`, `craft-skill`) to perform tasks. DO NOT write code directly in response to a user prompt like "build this feature".
+- **Always Green / fix-or-log:** Preflight and CI must be green before forward work. Any reproducible gate failure during unrelated work requires **quick-fix** or **fix-bug** — see CONVENTIONS § Discovered Defects. Never dismiss failures as pre-existing or out of scope.
 - Read specs/ and CONVENTIONS.md before writing code.
 - Write the minimum code that solves the stated problem. Nothing extra.
-- Never refactor, rename, or reorganize code outside the task scope.
 - Run tests after every change. Show evidence before declaring done.
 - One clarifying question beats a wrong assumption baked into 200 lines.
 - All written output (plans, specs, investigations) goes in specs/.

package/CONVENTIONS.md

@@ -1,6 +1,7 @@
 # story: e30s02
 # story: e30s03
 # story: e38s08
+# story: e51s01
 
 # Conventions
 
@@ -32,12 +33,12 @@ All changes to this repository MUST follow the [Conventional Commits 1.0.0](http
 - Never call GitHub REST API directly (curl, fetch, etc.)
 - Never create GitHub issues from automated workflows — produce local .md files in specs/ instead
 
-### Pre-Merge Golden Gate
+### Pre-Merge Verification Gates
 
-Before merging any branch, run the deterministic golden suite:
+Before merging any branch, run the deterministic verification gates:
 
 ```bash
-bash scripts/run-golden-suite.sh
+bash scripts/run-verification-gates.sh
 ```
 
 This runs compliance → G-04 self-test. If any gate fails, the merge is blocked.
@@ -59,6 +60,43 @@ You are operating within the `bigpowers` spec-driven development methodology.
 - **Scenario ID Format (e46s04+):** When a `specs/tech-architecture/eNN-TEST_PLAN_LATEST.md` exists for the epic, critical-path scenarios use the format `SC-eNNsYY-P{0|1|2|3}-NN` (e.g. `SC-e46s04-P0-01`). These IDs are referenced inside test files as `// scenario: SC-eNNsYY-P0-NN` comments alongside the existing `// story: eNNsNN` tag. SC gaps detected via check-blind-spots.sh; no separate SC tracing script required. gate-trace treats a P0 story with zero `SC-*-P0-*` references in test files as a CONCERNS finding (waivable via `state.yaml`). P2/P3 epics may set `test_plan: waived` in `state.yaml` to skip the `plan-tests` skill.
 - **Stream Continuity:** When writing large files or long documents, you MUST output continuously in chunks of ~200 lines. Do not pause between sections. Continue immediately until complete. If you need time to process, emit a placeholder comment or heading rather than going silent to prevent stream idle timeouts.
 
+## Always Green / Shift Left
+
+Solo developers own the whole codebase. **Always Green** means Preflight and CI are green before any forward work — not "green enough for this task."
+
+**Shift Left (1-10-100):** Defects cost roughly 1× to fix in development, 10× in integration, 100× in production (IBM Systems Sciences Institute; CloudQA benchmarks). Fixing a red gate now is cheaper than shipping and debugging later.
+
+**Preflight** — the project's full local verification stack (chained from test, lint, typecheck, and build commands recorded in `CLAUDE.md`). Preflight MUST pass before kickoff, develop, or verify phases advance.
+
+**CI green** — when a PR exists or remote CI applies, `gh pr checks` (or equivalent) MUST show passing before merge or land.
+
+**Existing projects:** Projects seeded before e51 do not receive these sections automatically. Re-run `seed-conventions` and merge the Always Green blocks, or copy § Always Green and § Discovered Defects from bigpowers `CONVENTIONS.md` manually.
+
+## Discovered Defects
+
+Any **reproducible gate failure** encountered during unrelated work is a discovered defect — not optional background noise.
+
+**fix-or-log ladder (mandatory):**
+
+1. **quick-fix** — trivial, data-only, or single-file fixes within guardrails.
+2. **fix-bug** — when quick-fix guardrails abort, or the failure needs investigation (`specs/bugs/BUG-*.md` + TDD).
+3. **Log** — only when reproduction is blocked after good-faith attempt; write a BUG spec and stop forward work on the original task until triaged.
+
+Discovered fixes ship in the **same PR** as the original work but in **separate commits** (Conventional Commits). Never narrate a failure and continue.
+
+**Hard block:** Red Preflight or red CI blocks kickoff-branch, develop-tdd, and verify-work forward progress until fix-or-log produces green.
+
+### Banned dismissive phrases
+
+Agents MUST NOT use these phrases (or close paraphrases) to ignore reproducible failures:
+
+| Banned phrase | Required behavior instead |
+|---------------|---------------------------|
+| Pre-existing / pre-existing issues | Run fix-or-log; if truly unrelated, prove with a passing repro after revert |
+| unrelated to this session | Same — session boundaries do not waive green gates |
+| not introduced by my changes | Bisect or fix anyway; solo-default owns the whole tree |
+| out of scope (ignoring a red gate) | Invoke quick-fix or fix-bug; scope-minimization never overrides Always Green |
+
 ## specs/ — All Planning Output Goes Here
 
 Every skill that produces written output writes to `specs/` at the project root.

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "bigpowers",
-  "version": "2.71.0",
+  "version": "2.72.0",
   "description": "73 agent skills synthesizing 17 years of software engineering discipline into a prescriptive methodology for solo developers",
   "main": "index.js",
   "scripts": {