bigpowers 2.73.9 → 2.74.1

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

@@ -3,6 +3,8 @@ description: "PLANNING SPINE STEP 3 of 3 — Plan the work: write detailed imple
 ---
 
 
+# story: e45s29
+
 # Plan Work
 
 > **Spine position:** Step 3 — scope-work → slice-tasks → plan-work.
@@ -44,14 +46,45 @@ If this plan touches an existing module, run `assess-impact` first to understand
 
 3. **Write capsule story spec + tasks** — Output two files inside the active epic capsule. See [REFERENCE.md](REFERENCE.md) for file formats and the plan-template. Each task MUST include a `risk:` field (`P0` | `P1` | `P2` | `P3`) based on BCP + story type heuristics (see REFERENCE.md). If a test plan artifact (`specs/tech-architecture/eNN-TEST_PLAN_LATEST.md`) exists, read it and inherit its P0/P1 risk classifications and scenario IDs (`SC-eNNsYY-P0-NN`). Each task optionally includes a `security:` field (`none` / `low` / `medium` / `high`) sourced from the epic's `specs/security/epics/<id>/THREAT_MODEL.md`. Tasks with `security: medium` or `security: high` MUST include "no new security findings in affected paths" in their verify steps.
 
+   **Requirement delta tags (e45s29):** When a story modifies existing behavior, the story spec § Requirements MUST use OpenSpec-style delta tags with mandatory before/after content:
+
+   | Tag | When | Required content |
+   |-----|------|------------------|
+   | `ADDED` | New requirement | Full requirement text |
+   | `MODIFIED` | Changed behavior | **Before:** prior behavior · **After:** new behavior |
+   | `REMOVED` | Retired requirement | **Before:** what existed · **After:** (removed) + rationale |
+   | `RENAMED` | ID or title change only | **Before:** old ID/title · **After:** new ID/title |
+
+   Net-new stories (greenfield) use `ADDED` only. `MODIFIED`/`REMOVED`/`RENAMED` without before/after blocks fail the plan-work gate.
+
 4. **Verify step format** — Every step MUST follow: `N. <What to do> → verify: <runnable command>`. See [REFERENCE.md](REFERENCE.md) for good/bad examples.
 
+4a. **Cross-artifact consistency pass (HARD GATE — e45s04)** — Before handoff, run:
+
+```bash
+bash scripts/lib/plan-consistency-check.sh specs/epics/<capsule>/
+```
+
+Print CRITICAL / HIGH / MED findings. **CRITICAL or HIGH blocks code generation** — fix capsule artifacts first. MED requires explicit user acknowledgment.
+
+4b. **tasks.yaml failing ledger (e45s06)** — Every new task entry starts with `status: failing`. Only flip to `status: passing` after its `verify:` command exits 0 during `develop-tdd` or `verify-work`. Never pre-mark passing at plan time.
+
 5. **Review with user** — Confirm step order, granularity, and that verify commands are runnable in this project.
 
+## Lifecycle Gates (e45s09)
+
+| Gate | When | Pass condition |
+|------|------|----------------|
+| **Pre-Implementation** | Before `kickoff-branch` / first RED commit | Root-cause stated for bugs; `assess-impact` done for module changes; plan-consistency-check PASS |
+| **Validation** | Story marked done | All tasks `status: passing`; verify evidence in `specs/verifications/` |
+| **Reopen-don't-refile** | Regression on shipped story | Reopen existing story/bug — do not create duplicate capsule entries |
+
 After writing capsule tasks, suggest `kickoff-branch` (if not already on a feature branch) then `build-epic`, `execute-plan`, or `develop-tdd`.
 
 ## Verify
 
+→ verify: `test -f scripts/lib/plan-consistency-check.sh && bash scripts/lib/plan-consistency-check.sh specs/epics/e45-quality-core/ 2>&1 | head -5`
+
 
 
 ## Handoff
@@ -63,6 +96,17 @@ Writes: state.yaml handoff.next_skill = kickoff-branch
 
 # Plan Work — Reference
 
+## Navigation
+
+| Lines | Section |
+|-------|---------|
+| 1 | Title |
+| 3–14 | Navigation |
+| 16–38 | Output file formats |
+| 40–71 | Plan template |
+| 73–91 | Verify step format rules |
+| 93–131 | Sub-operations (risk, define-success, zoom-out, slopcheck, delta tags) |
+
 ## Output file formats
 
 ### Story spec: `specs/epics/<capsule>/eNNsYY-<slug>.md`
@@ -74,14 +118,14 @@ Populated countable-story-format with all 20 sections. Minimum maturity: 3 (Coun
 ```yaml
 story_id: e01s01
 title: Login
-status: todo
+status: failing
 bcps: 3
 tasks:
   - id: 1
     description: "Add login form component tests"
     verify: "npm test -- login-form.test.tsx"
     risk: P1
-    status: todo
+    status: failing   # flip to passing only after verify exits 0 (e45s06)
 ```
 
 Update `specs/epics/<capsule>/epic.yaml` manifest to list the story and its BCPs. Run `bash scripts/sync-status-from-epics.sh` after structural changes.
@@ -152,6 +196,22 @@ Every task and story MUST be assigned a `risk:` level (P0, P1, P2, P3). When `sp
 
 `verify-work` scales its UAT depth based on this field.
 
+### Requirement delta tags (e45s29)
+
+When modifying existing behavior in story spec § Requirements:
+
+```markdown
+#### MODIFIED: User can reset password via email link
+**Before:** Password reset required admin approval.
+**After:** Self-service reset via signed email link (expires 1h).
+
+#### REMOVED: Legacy OAuth1 login
+**Before:** OAuth1 provider supported for enterprise SSO.
+**After:** (removed) — provider deprecated; OAuth2 only.
+```
+
+Tags: `ADDED`, `MODIFIED`, `REMOVED`, `RENAMED`. `MODIFIED`/`REMOVED`/`RENAMED` without before/after → plan-work gate FAIL.
+
 ### Define Success
 
 Before planning, convert task statements into observable "step → verify: <cmd>" pairs:

package/.pi/prompts/publish-package.md

@@ -77,6 +77,17 @@ See [REFERENCE.md](REFERENCE.md)
 
 # Publish Package — Reference
 
+## Navigation
+
+| Lines | Section |
+|-------|---------|
+| 1 | Title |
+| 3–18 | Navigation |
+| 20–28 | Options |
+| 30–60 | Examples |
+| 62–72 | Integration with release-branch |
+| 74–252 | Reference blocks 1–8 |
+
 ## Options
 
 | Flag | Description |

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

@@ -3,6 +3,13 @@ description: Make the merge/PR/keep/discard decision for a feature branch, verif
 ---
 
 
+<!-- story: e38s07 -->
+<!-- story: e45s15 -->
+<!-- story: e45s32 -->
+<!-- story: e45s39 -->
+<!-- story: e20s02 -->
+
+
 # Release Branch
 
 > **HARD GATE** — Do NOT merge or release if tests fail or if coverage gates are not met. If the branch is red, return to `develop-tdd` to fix regressions or add missing tests before proceeding.
@@ -52,6 +59,8 @@ If REVIEW.md is missing or stale → run `security-review` inline. Findings bloc
 
 Run `gate-trace` before merge. FAIL blocks merge; CONCERNS requires explicit override in `specs/state.yaml` (`traceability_override: CONCERNS accepted, reason: <explanation>`). WAIVED if no matrix available.
 
+> **Adversarial refute framing (e45s32):** The final pre-merge check is **refute, not rubber-stamp**. Before declaring ready, actively try to disprove traceability completeness — missing story tags, absent verify evidence, stale security review. Only proceed when refutation fails.
+
 ### 3. Diff review
 
 - [ ] All commits intentional, no secrets, CONVENTIONS.md compliance
@@ -72,9 +81,26 @@ bash scripts/land-branch.sh <task-slug> "feat(scope): description"
 
 ### 6. Create PR (team-pr only)
 
-Create the pull request, then merge via `gh`:
+Create the pull request with a **literal provenance marker** in the body so agent-generated PRs are identifiable and do not rot silently:
+
+```markdown
+<!-- bigpowers-provenance: agent-generated -->
+```
+
+Place the marker on its own line immediately after the `## Summary` heading. Then merge via `gh`:
 
 ```bash
+gh pr create --title "..." --body "$(cat <<'EOF'
+## Summary
+<!-- bigpowers-provenance: agent-generated -->
+
+- ...
+
+## Test plan
+- [ ] ...
+
+EOF
+)"
 gh pr merge --squash --delete-branch
 ```
 
@@ -90,55 +116,18 @@ mv specs/epics/eNN-slug specs/epics/archive/
 
 ### 7b. CI verification & agent lock release (e39s02)
 
-> **HARD GATE** — Do NOT declare success until CI completes. A push that fails CI is a regression, not a release.
-
-After push, run CI polling:
+> **HARD GATE** — Do NOT declare success until CI completes. **Three-independent-facts** (e45s15): commit landed, workflow green, registry visible — see [REFERENCE.md](REFERENCE.md#three-independent-facts-release).
 
 ```bash
 bash scripts/wait-for-ci.sh --timeout 600 --interval 30
 ```
 
-Then release the story lock:
-
-```bash
-LOCK="specs/agent-locks.yaml"; STORY="<story-id>"
-[ -f "$LOCK" ] && python3 -c "
-import yaml
-d=yaml.safe_load(open('$LOCK'))
-if d:d['locks']=[l for l in d['locks'] if l.get('story_id')!='$STORY']
-yaml.dump(d,open('$LOCK','w'),default_flow_style=False)
-print(f'LOCK RELEASED: $STORY')
-"||echo "No lock for $STORY — idempotent"
-```
-
-- [ ] CI workflow passes after push (wait-for-ci.sh exit 0)
-- [ ] `release.ci_verified: true` documented in state.yaml
-- On failure: `handoff.next_skill = fix-bug` with CI failure URL
-
-### 8. Clean up worktree
-
-```bash
-git worktree prune
-git worktree remove ../<branch-name> 2>/dev/null || true
-git branch -d <branch-name>
-```
-
-### 8a. Cycle-time recording
-
-After landing, record delivery metrics with the git-derived, additive script:
-
-```bash
-bash scripts/record-cycle-time.sh append \
-  --story <story_id> --bcps <bcps> \
-  --range "$(git merge-base main HEAD)..HEAD" \
-  --file specs/metrics/cycle-times.yaml
-```
+- [ ] CI passes; `release.ci_verified: true` in state.yaml
+- On failure: `handoff.next_skill = fix-bug`
 
-### 9. Return to main
+### 8. Clean up & return
 
-```bash
-git checkout main && git status && pwd
-```
+Worktree prune, branch delete, `git checkout main`. Cycle-time: see [REFERENCE.md](REFERENCE.md#cycle-time).
 
 Report: "Branch released."
 
@@ -150,6 +139,20 @@ Report: "Branch released."
 
 # Release Branch — Reference
 
+## Navigation
+
+| Lines | Section |
+|-------|---------|
+| 1–3 | Title |
+| 5–16 | Navigation |
+| 18–41 | PR body template |
+| 43–54 | Worktree cleanup |
+| 56–96 | Cycle-time recording |
+| 98–119 | CI verification |
+| 121–126 | Solo-local fallback |
+| 128–134 | Handoff |
+| 136–155 | Reference block 1 (manual squash) |
+
 # Release Branch — Reference
 
 ## PR body template (team-pr mode)

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

@@ -3,21 +3,44 @@ description: Dispatch a fresh reviewer agent with a clean context to critique th
 ---
 
 
+# story: e45s28
+
 # Request Review
 
-Dispatch a fresh reviewer agent with a clean context. The reviewer has no shared state — it can give a genuine second opinion because it hasn't been involved in writing the code.
+Dispatch fresh reviewer agents with clean contexts. Reviewers have no shared state — they find what the coding agent missed.
+
+**Distinct from `audit-code`:** `audit-code` is self-review (internal). This skill dispatches external agents.
+
+**Solo developer note:** Reviewer agents replace the human reviewer.
+
+**Run `audit-code` first.** Don't waste reviewer attention on hygiene issues you could have caught yourself.
+
+## Santa Method — Dual-Blind AND Gate (e45s07)
+
+Use **two independent reviewers** (Reviewer A and Reviewer B) with **no shared context** between them or the coding agent.
+
+| Parameter | Value |
+|-----------|-------|
+| Reviewers | 2 (mandatory) |
+| `MAX_REVIEW_ITERATIONS` | **5** (hard cap — e45s28; iteration 6 forbidden) |
+| Pass rule | **AND-gate** — both reviewers must pass independently |
+| Blindness | Neither reviewer sees the other's report until both complete |
 
-**Distinct from `audit-code`:** `audit-code` is the coding agent checking its own work (internal). This skill dispatches an external agent whose job is to find what the coding agent missed.
+**Iteration loop (max `MAX_REVIEW_ITERATIONS`):**
 
-**Solo developer note:** This replaces the human reviewer. The reviewer agent IS the reviewer.
+1. Dispatch Reviewer A and Reviewer B in parallel with identical briefs but separate contexts.
+2. Collect both reports. Each categorizes findings: must-fix / should-fix / consider.
+3. **AND-gate:** If **either** reviewer has must-fix findings → FAIL round. Run `respond-review`, fix, re-dispatch both reviewers.
+4. If both pass (zero must-fix, score ≥ 94% each) → review complete.
+5. After **5** iterations without dual pass → **stop**; report "Review cap exhausted (5/5). Human decision required." Do not merge.
 
-**Run `audit-code` first.** This skill assumes `audit-code` has already passed. Don't waste a reviewer's attention on hygiene issues you could have caught yourself.
+> **HARD GATE** — Single-reviewer pass is insufficient. Partial agreement does not satisfy the AND-gate.
 
 ## Process
 
 ### 1. Prepare the review brief
 
-Write a self-contained brief for the reviewer agent. Include:
+Write a self-contained brief for each reviewer. Include:
 
 - What was built (feature description, not implementation)
 - Which files changed (the diff context)
@@ -27,12 +50,25 @@ Write a self-contained brief for the reviewer agent. Include:
 - What you're most uncertain about (where you want fresh eyes)
 - **Security focus** — If the epic has a `specs/security/epics/<id>/THREAT_MODEL.md`, include the relevant vulnerability categories as reviewer focal points. Also include the false-positive exclusion rules so the reviewer avoids known-safe patterns. Tag the review as `security-sensitive: true` if THREAT_MODEL risk is HIGH+.
 
-### 2. Dispatch the reviewer agent
+### 2. Fan-out parallel reviewers (e45s17)
 
-Use the Agent tool with a completely fresh context. The agent prompt must be self-contained — no references to "our conversation" or "what we discussed."
+Beyond the mandatory dual-blind pair (e45s07), optionally dispatch **N dimension-specific subagents in one message** — one check per agent for broader coverage (OpenAI Codex `code-review-*` pattern):
+
+| Agent | Focus |
+|-------|-------|
+| R-correctness | Logic, edge cases, verify command result |
+| R-conventions | CONVENTIONS.md, test quality (F.I.R.S.T) |
+| R-security | Injection, auth, secrets (when `security-sensitive`) |
+| R-design | Simpler alternatives, API shape |
+
+Santa Method still applies: each agent is blind; AND-gate uses Reviewer A + B scores. Fan-out agents feed findings into `respond-review` but do not replace the dual-blind pair.
+
+### 2b. Dispatch both reviewer agents (parallel)
+
+Use the Agent tool twice with completely fresh contexts. Each prompt must be self-contained — no references to "our conversation" or "what we discussed."
 
 ```
-You are a code reviewer. Review the following code changes.
+You are code reviewer [A|B]. Review the following code changes independently.
 
 Context: [feature description]
 CONVENTIONS.md rules: [paste relevant sections]
@@ -54,18 +90,22 @@ For each finding, categorize as: must-fix / should-fix / consider.
 Run the verify command and report the result.
 ```
 
-### 3. Collect the report
+### 3. Collect both reports
 
-When the reviewer returns:
-- Read every finding before acting on any
-- Note the verify command result
-- Compute the quality score: `100 × (total_items − must_fix − should_fix) / total_items`
-- Report the score to the user
+When reviewers return:
+- Read every finding from **both** reports before acting on any
+- Note each verify command result
+- Compute quality score per reviewer: `100 × (total_items − must_fix − should_fix) / total_items`
+- **AND-gate check:** both scores ≥ 94% and zero must-fix from **both**?
 
-> **HARD GATE** — If score < 94%, do NOT merge. Run `respond-review` to resolve must-fix and should-fix findings first. The 94% threshold also applies to the compliance SCORE computed by `npm run compliance` (scripts/audit-compliance.sh): SCORE = passing Gherkin scenarios / total × 100.
+> **HARD GATE** — If either score < 94% or either has must-fix → FAIL round. Run `respond-review` first. The 94% threshold also applies to `npm run compliance` (scripts/audit-compliance.sh).
 
 ### 4. Hand off to respond-review
 
-Pass the reviewer's report to `respond-review` to categorize findings and apply fixes.
+Pass combined findings to `respond-review` to categorize and apply fixes. Increment iteration counter. Re-dispatch both reviewers until AND-gate passes or iteration 3 exhausted.
+
+Report to user: "Review round [N/3]. Reviewer A: [score], Reviewer B: [score]. AND-gate: [PASS|FAIL]."
+
+## Verify
 
-Report to user: "Review complete. [N] findings: [X] must-fix, [Y] should-fix, [Z] consider. Running respond-review."
+→ verify: `grep -q 'AND-gate' skills/request-review/SKILL.md && grep -q 'max 3' skills/request-review/SKILL.md && echo OK`

package/.pi/prompts/research-first.md

@@ -3,6 +3,9 @@ description: Look-before-build — search registries, repo, existing skills, and
 ---
 
 
+# story: e03s01
+# story: e21s02
+
 # Research First
 
 > **HARD GATE** — Do NOT implement until prior art is searched. Minimum outcome: adopt, extend, compose, or build — with evidence.

package/.pi/prompts/run-benchmark.md

@@ -27,9 +27,9 @@ Benchmark definitions partition scenarios into two sets:
 ## Usage
 
 ```bash
-run-benchmark <skill-name>           # benchmark single skill
-run-benchmark --all                  # benchmark all with definitions
-run-benchmark <skill-name> --baseline # pin results as baseline
+bash scripts/run-benchmark.sh <skill-name>           # benchmark single skill
+bash scripts/run-benchmark.sh --all                  # benchmark all with definitions
+bash scripts/run-benchmark.sh <skill-name> --baseline # pin results as baseline
 ```
 
 ## Process

package/.pi/prompts/run-evals.md

@@ -14,8 +14,18 @@ description: Eval-Driven Development — define capability and regression evals
    - **Capability evals** (does it do the job?)
    - **Regression evals** (did we break anything?)
 3. Assign grader type per eval: `code` (shell verify) or `model` (rubric).
-4. Run evals; log results table with pass@k (e.g. 3/3 runs).
-5. Block BUILD phase until capability evals pass at agreed k.
+4. Assign **strictness tier** per eval (graduated promotion — e45s37):
+
+   | Tier | Meaning | Promotion rule |
+   |------|---------|------------------|
+   | `EXPERIMENTAL` | New eval, may flake | Not gating |
+   | `USUALLY_PASSES` | Stable in dev; ≥2/3 recent runs pass | Blocks BUILD only when combined with ALWAYS_PASSES suite |
+   | `ALWAYS_PASSES` | Zero tolerance; required for release | Any single failure blocks BUILD and merge |
+
+   Promote: `EXPERIMENTAL → USUALLY_PASSES` after 3 consecutive passes; `USUALLY_PASSES → ALWAYS_PASSES` after 5 consecutive passes with zero flakes documented in `specs/state.yaml`.
+
+5. Run evals; log results table with pass@k (e.g. 3/3 runs) and tier per eval.
+6. Block BUILD phase until all `ALWAYS_PASSES` evals pass at agreed k. `USUALLY_PASSES` failures warn; `EXPERIMENTAL` failures log only.
 
 ## Artefact
 
@@ -29,16 +39,26 @@ description: Eval-Driven Development — define capability and regression evals
 
 # Run Evals — Reference
 
+## Strictness tiers (e45s37)
+
+Add a `tier:` column to each eval row:
+
+| Tier | Gate behaviour |
+|------|----------------|
+| `EXPERIMENTAL` | Log only — does not block |
+| `USUALLY_PASSES` | Warn on failure; blocks only when paired with failing `ALWAYS_PASSES` |
+| `ALWAYS_PASSES` | Hard block on any failure |
+
 ## EVALS template
 
 ```markdown
 # EVALS: <feature>
 
 ## Capability
-| ID | Eval | Grader | verify / rubric |
-|----|------|--------|-----------------|
-| C1 | ... | code | `verify: npm test -- <file>` |
-| C2 | ... | model | Rubric: [ ] criterion A [ ] criterion B |
+| ID | Eval | Grader | Tier | verify / rubric |
+|----|------|--------|------|-----------------|
+| C1 | ... | code | ALWAYS_PASSES | `verify: npm test -- <file>` |
+| C2 | ... | model | USUALLY_PASSES | Rubric: [ ] criterion A [ ] criterion B |
 
 ## Regression
 | ID | Eval | Grader | verify / rubric |

package/.pi/prompts/run-planning.md

@@ -2,6 +2,7 @@
 description: "DISCOVER-PHASE ADVANCER — Drive the discover-phase checklist (specs/planning-status.yaml) through survey-context → scope-work → research-first → elaborate-spec → plan-release → slice-tasks. NOT a duplicate of plan-work or the planning spine; it orchestrates the pre-coding discover phase only."
 ---
 
+# story: e24s03
 
 # Run Planning
 

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

@@ -3,6 +3,9 @@ description: "PLANNING SPINE STEP 1 of 3 — Scope the work: define what is in a
 ---
 
 
+# story: e03s01
+# story: e24s02
+
 # Scope Work
 
 > **Spine position:** Step 1 — scope-work → slice-tasks → plan-work.

package/.pi/prompts/search-skills.md

@@ -3,6 +3,9 @@ description: Find the right bigpowers skill from natural-language intent using a
 ---
 
 
+# story: e09s01
+# story: e21s01
+
 # Search Skills
 
 > **HARD GATE** — Search results must be ranked by relevance. Do NOT return all matches without prioritization. Use skill metadata (phase, purpose, frequency) to rank.

package/.pi/prompts/security-review.md

@@ -3,12 +3,33 @@ description: >
 ---
 
 
+# story: e45s41
+<!-- story: e45s18 -->
+# story: e26s01
+# story: e26s02
+# story: e26s03
+# story: e26s04
+# story: e26s05
+# story: e26s06
+# story: e26s07
+# story: e45s26
+
 # Security Review
 
 > **HARD GATE** — Requires git context (branch with merge-base or diff). Never
 > writes files outside `specs/security/`. Findings below confidence 8/10 are
 > suppressed. **→ verify:** `git rev-parse HEAD >/dev/null 2>&1 && echo "ok" || echo "BLOCKED"`
 
+## Parallel worktree mode (e45s18)
+
+When running alongside `audit-code`, use isolated worktrees so scans do not race on the same index:
+
+```bash
+bash scripts/lib/parallel-review-worktrees.sh security-review
+```
+
+Each check gets a detached worktree at `.bigpowers/worktrees/review-<name>/`; reports still write only under `specs/security/`.
+
 ## 5-phase scan
 
 | # | Phase | What |
@@ -23,6 +44,37 @@ description: >
 
 Covered: SQLi, XSS, SSRF, command injection, auth bypass, unsafe deserialization, path traversal, IDOR, crypto flaws, secrets exposure, template injection, NoSQLi
 
+## CWE mapping mandate (e45s26)
+
+Every **new detection rule** added to this skill MUST:
+
+1. Map to a [CWE](https://cwe.mitre.org/) ID in `REFERENCE-vuln-categories.md` (e.g. SQLi → CWE-89, XSS → CWE-79).
+2. Ship **two fixture pairs** under `skills/security-review/fixtures/`:
+   - **Positive** — minimal code the rule MUST flag (vulnerable pattern present).
+   - **Negative** — structurally similar code the rule MUST NOT flag (safe pattern / false-positive guard).
+
+| Rule | CWE | Positive fixture | Negative fixture |
+|------|-----|------------------|------------------|
+| SQL injection | CWE-89 | `fixtures/CWE-89-sqli-positive.py` | `fixtures/CWE-89-sqli-negative.py` |
+| XSS (DOM) | CWE-79 | `fixtures/CWE-79-xss-positive.js` | `fixtures/CWE-79-xss-negative.js` |
+
+Before merging a new category, run both fixtures through the detection guidance and confirm positive flags / negative passes.
+
+## SQL-safety doctrine (e45s41 — proven authorship)
+
+Formal rule for SQL injection classification:
+
+| SQL source | Attacker-reachable input? | Verdict |
+|------------|---------------------------|---------|
+| Hardcoded / compile-time constant string | N/A | **Safe** — proven authorship |
+| Developer-authored query with bound parameters only | No dynamic fragments from user input | **Safe** |
+| String concatenation / template with user-controlled values | Yes | **Unsafe** — report as SQLi |
+| ORM query builder with user input in WHERE/JOIN | Yes | **Unsafe** unless parameterized |
+| Stored procedure call with bound args | Args from trusted constants only | **Safe** |
+| Stored procedure with dynamic SQL inside | User input reaches EXEC | **Unsafe** |
+
+**Provenance test:** If the agent cannot prove the query string was authored entirely by the developer (no attacker-reachable interpolation), treat as vulnerable. Hardcoded SQL in migrations, seeds, and admin scripts is safe; anything reachable from HTTP/CLI/user input is not.
+
 ## BCP Plus Integration
 
 This skill maps to **BCP Plus dimension 12 (Security & Compliance)**. When BCP Plus sizing is active, the threat model categories above correspond to sub-elements within dimension 12. The NFR Gate rule applies: standard-expectation items (e.g., "use HTTPS", "hash passwords") score 0 with a one-line rationale; only above-standard security requirements contribute to the dimension 12 count. See `docs/references/bcp-plus.md` for the full 13-dimension framework and NFR Gate pattern.
@@ -56,11 +108,8 @@ Each finding: **`File:Line` — Severity — Category**
 
 ## Verify
 
-
-
 ```bash
-test -d specs/security && echo "OK: specs/security/ exists" || mkdir -p specs/security
-grep -q "Merge-base\|merge.base\|git diff" SKILL.md && echo "OK: git context verified"
+test -d specs/security && echo "OK: specs/security/ exists" || mkdir -p specs/security; grep -q "Merge-base\|merge.base\|git diff" SKILL.md && echo "OK: git context verified"
 ```
 
 ---
@@ -174,14 +223,15 @@ Automatically exclude findings matching these patterns:
 | 8 | **Race conditions / timing attacks** that are theoretical | Only report if concretely problematic |
 | 9 | **Outdated third-party libraries** | Managed separately by dependency scanners |
 | 10 | **Memory safety** in Rust or other memory-safe languages | Impossible by language guarantees |
-| 11 | **Unit test files only** | Not production risk |
-| 12 | **Log spoofing** | Outputting unsanitized input to logs is not a vuln |
-| 13 | **SSRF that only controls path** | Only host/protocol control is exploitable |
-| 14 | **User-controlled content in AI system prompts** | Not a security vulnerability |
-| 15 | **Regex injection** | Injecting untrusted content into regex is not a vuln |
-| 16 | **Regex DOS** | Excluded alongside general DOS |
-| 17 | **Documentation files** (.md, .txt) | Insecure docs are not code vulnerabilities |
-| 18 | **Lack of audit logs** | Not a vulnerability |
+| 11 | **Hardcoded SQL with proven authorship** — migrations, seeds, static admin queries with no user interpolation | Developer-authored SQL is safe per SQL-safety doctrine (e45s41) |
+| 12 | **Unit test files only** | Not production risk |
+| 13 | **Log spoofing** | Outputting unsanitized input to logs is not a vuln |
+| 14 | **SSRF that only controls path** | Only host/protocol control is exploitable |
+| 15 | **User-controlled content in AI system prompts** | Not a security vulnerability |
+| 16 | **Regex injection** | Injecting untrusted content into regex is not a vuln |
+| 17 | **Regex DOS** | Excluded alongside general DOS |
+| 18 | **Documentation files** (.md, .txt) | Insecure docs are not code vulnerabilities |
+| 19 | **Lack of audit logs** | Not a vulnerability |
 
 ## Precedent Rules
 
@@ -233,6 +283,8 @@ Each category: vulnerable pattern → safe pattern → code example.
 | Aspect | Detail |
 |--------|--------|
 | **Vulnerable** | String interpolation in SQL queries: `f"SELECT * FROM users WHERE id = {uid}"` |
+| **CWE** | CWE-89 (SQL Injection) |
+| **Fixtures** | `fixtures/CWE-89-sqli-positive.py` (flag) · `fixtures/CWE-89-sqli-negative.py` (pass) |
 | **Safe** | Parameterized queries / ORM: `cursor.execute("SELECT * FROM users WHERE id = %s", (uid,))` |
 | **Look for** | f-strings, `+` concatenation, `format()` in query builders; raw SQL in ORM `.raw()` / `.execute()` |
 | **False-positive guard** | Not a FP if the input is user-controlled (HTTP param, file, env var, CLI arg). Env vars are trusted (see exclusion rules). |
@@ -242,6 +294,8 @@ Each category: vulnerable pattern → safe pattern → code example.
 | Aspect | Detail |
 |--------|--------|
 | **Vulnerable** | `element.innerHTML = userInput`, `dangerouslySetInnerHTML={{__html: userInput}}` |
+| **CWE** | CWE-79 (Cross-site Scripting) |
+| **Fixtures** | `fixtures/CWE-79-xss-positive.js` (flag) · `fixtures/CWE-79-xss-negative.js` (pass) |
 | **Safe** | `element.textContent = userInput`, React JSX (auto-escaped), template engines with auto-escaping |
 | **Look for** | `.innerHTML`, `document.write()`, `dangerouslySetInnerHTML`, `v-html` (Vue), `bypassSecurityTrustHtml` (Angular) |
 | **False-positive guard** | React/Angular components without unsafe methods are NOT vulnerable (see exclusion rules). |