bigpowers 2.85.1 → 2.86.0

package/scripts/verify-generalize-sweep.sh

@@ -0,0 +1,55 @@
+#!/usr/bin/env bash
+# story: e80s04
+# Validates generalize-fix sweep artifact exists and has required fields.
+# Usage:
+#   bash scripts/verify-generalize-sweep.sh [--self-test]
+#   bash scripts/verify-generalize-sweep.sh specs/verifications/generalize-sweep-BUG-*.json
+set -euo pipefail
+
+REPO_ROOT="$(cd "$(dirname "${BASH_SOURCE[0]}")/.." && pwd)"
+cd "$REPO_ROOT"
+
+validate_artifact() {
+  local file="$1"
+  [[ -f "$file" ]] || { echo "FAIL: missing $file"; return 1; }
+  grep -q '"defect_class"' "$file" || { echo "FAIL: $file missing defect_class"; return 1; }
+  grep -q '"grep_pattern"' "$file" || { echo "FAIL: $file missing grep_pattern"; return 1; }
+  grep -q '"match_count"' "$file" || { echo "FAIL: $file missing match_count"; return 1; }
+  echo "PASS: $file"
+}
+
+self_test() {
+  local dir="$REPO_ROOT/specs/verifications/fixtures"
+  mkdir -p "$dir"
+  local sample="$dir/generalize-sweep-selftest.json"
+  cat > "$sample" <<'JSON'
+{
+  "defect_class": "fail-open-verify",
+  "grep_pattern": "|| echo",
+  "match_count": 0,
+  "sweep_scope": "skills/*/SKILL.md",
+  "notes": "self-test fixture for verify-generalize-sweep.sh"
+}
+JSON
+  validate_artifact "$sample"
+  grep -q 'generalize-fix' skills/validate-fix/SKILL.md
+  echo "verify-generalize-sweep: self-test OK"
+}
+
+if [[ "${1:-}" == "--self-test" ]]; then
+  self_test
+  exit 0
+fi
+
+if [[ $# -gt 0 ]]; then
+  for f in "$@"; do validate_artifact "$f"; done
+  exit 0
+fi
+
+shopt -s nullglob
+artifacts=(specs/verifications/generalize-sweep-*.json)
+if [[ ${#artifacts[@]} -eq 0 ]]; then
+  echo "FAIL: no specs/verifications/generalize-sweep-*.json artifact (generalize-fix not evidenced)"
+  exit 1
+fi
+for f in "${artifacts[@]}"; do validate_artifact "$f"; done

package/scripts/verify-tdd-red-commit.sh

@@ -0,0 +1,91 @@
+#!/usr/bin/env bash
+# story: e80s01 e80s03
+# Mechanical gate: test-only (RED) commit must fail when checked out in isolation.
+# Usage:
+#   bash scripts/verify-tdd-red-commit.sh [--self-test]
+#   TDD_VERIFY_CMD='npm test' bash scripts/verify-tdd-red-commit.sh
+set -euo pipefail
+
+REPO_ROOT="$(cd "$(dirname "${BASH_SOURCE[0]}")/.." && pwd)"
+cd "$REPO_ROOT"
+
+self_test() {
+  local tmp
+  tmp=$(mktemp -d)
+  trap 'rm -rf "$tmp"' RETURN
+  cd "$tmp"
+  git init -q
+  git config user.email "tdd-verify@bigpowers.local"
+  git config user.name "tdd-verify"
+
+  mkdir -p test
+  cat > package.json <<'JSON'
+{"name":"tdd-fixture","scripts":{"test":"node test/run.js"}}
+JSON
+  cat > test/run.js <<'JS'
+const fs = require('fs');
+const impl = fs.existsSync('src/impl.js');
+process.exit(impl ? 0 : 1);
+JS
+  git add .
+  git commit -q -m "test(scope): red — expect failure without impl"
+
+  git checkout -q HEAD
+  if node test/run.js; then
+    echo "FAIL: RED commit passed in isolation (expected failure)"
+    return 1
+  fi
+  echo "PASS: RED commit fails in isolation"
+
+  mkdir -p src
+  echo 'module.exports = {};' > src/impl.js
+  git add src/impl.js
+  git commit -q -m "fix(scope): green — implementation"
+  if ! node test/run.js; then
+    echo "FAIL: GREEN commit should pass"
+    return 1
+  fi
+  echo "PASS: GREEN commit passes"
+  echo "verify-tdd-red-commit: self-test OK"
+}
+
+if [[ "${1:-}" == "--self-test" ]]; then
+  self_test
+  exit $?
+fi
+
+if ! git rev-parse --git-dir >/dev/null 2>&1; then
+  echo "ERROR: not a git repository"
+  exit 1
+fi
+
+if [[ "$(git rev-list --count HEAD 2>/dev/null || echo 0)" -lt 2 ]]; then
+  echo "SKIP: need at least 2 commits (test-only RED then fix GREEN)"
+  exit 0
+fi
+
+VERIFY_CMD="${TDD_VERIFY_CMD:-}"
+if [[ -z "$VERIFY_CMD" ]]; then
+  if [[ -f package.json ]] && grep -q '"test"' package.json 2>/dev/null; then
+    VERIFY_CMD="npm test --if-present"
+  elif [[ -f Cargo.toml ]]; then
+    VERIFY_CMD="cargo test"
+  else
+    echo "SKIP: set TDD_VERIFY_CMD for this repo"
+    exit 0
+  fi
+fi
+
+RED_SHA=$(git rev-parse HEAD~1)
+WORKTREE=$(mktemp -d)
+trap 'git worktree remove -f "$WORKTREE" 2>/dev/null || rm -rf "$WORKTREE"' EXIT
+
+git worktree add -q --detach "$WORKTREE" "$RED_SHA"
+(
+  cd "$WORKTREE"
+  if bash -c "$VERIFY_CMD"; then
+    echo "FAIL: test-only commit $RED_SHA passed in isolation — RED gate violated"
+    exit 1
+  fi
+  echo "PASS: test-only commit $RED_SHA fails in isolation"
+)

package/skills/assess-impact/SKILL.md

@@ -35,7 +35,7 @@ git log --oneline -10 -- [file-path]
 
 Read `specs/release-plan.yaml + epic capsule directories` (if it exists). For each dependent found in Step 2, identify which story owns that module. List stories that will be affected by the change.
 
-→ verify: `grep -c "Story" specs/release-plan.yaml 2>/dev/null || echo "no release plan"`
+→ verify: `test -f specs/release-plan.yaml && grep -ci "stor" specs/release-plan.yaml`
 
 ### 4. List test coverage
 

package/skills/develop-tdd/SKILL.md

@@ -1,3 +1,5 @@
+# story: e80s01
+# story: e80s03
 # story: e51s04
 # story: e45s06
 # story: e45s08
@@ -60,7 +62,13 @@ GREEN:  Write minimal code to pass → test passes → commit: feat(<scope>): ..
 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.
+> **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. Before proceeding, run the mechanical RED isolation check:
+
+```bash
+bash scripts/verify-tdd-red-commit.sh
+```
+
+Show `git log -2 --oneline` **and** the script output as evidence. If the test-only commit passes in isolation, the RED gate is violated — stop and fix before GREEN.
 
 > **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.
 
@@ -124,5 +132,9 @@ Writes: state.yaml handoff.next_skill = verify-work
 
 At story completion, if the story was sized with BCP Plus (13-dimension breakdown), log the `bcp_plus.total` alongside the standard `bcps:` count in the story's tasks.yaml. The breakdown is available from the epic capsule's `bcp_plus_breakdown` field. See `docs/references/bcp-plus.md` for the full methodology and NFR Gate pattern.
 
+## Verify
+
+→ verify: `test -x scripts/verify-tdd-red-commit.sh && bash scripts/verify-tdd-red-commit.sh --self-test && grep -q 'verify-tdd-red-commit' skills/develop-tdd/SKILL.md && echo OK`
+
 
 <!-- story: e02s04 -->

package/skills/enforce-first/SKILL.md

@@ -1,3 +1,4 @@
+# story: e80s01
 ---
 name: enforce-first
 model: haiku
@@ -22,6 +23,15 @@ This skill is typically invoked internally by `develop-tdd` during the test-writ
 
 See CONVENTIONS.md §Tests for the canonical F.I.R.S.T rubric definition, checklists, and fix patterns.
 
+Mechanical self-check (runs before reporting audit complete):
+
+```bash
+grep -q '## Tests (F.I.R.S.T' CONVENTIONS.md
+grep -qE 'Fast|Independent|Repeatable|Self-Validating|Timely' CONVENTIONS.md
+```
+
+Each criterion must be explicitly addressed in the audit report with pass/fail per test file reviewed.
+
 ## Applying the rubric
 
 For each failing criterion:
@@ -32,3 +42,7 @@ For each failing criterion:
 
 Report: "F.I.R.S.T audit complete. X criteria passed, Y fixed."
 
+## Verify
+
+→ verify: `grep -q '## Tests (F.I.R.S.T' CONVENTIONS.md && grep -qE 'Self-Validating|Repeatable' skills/enforce-first/SKILL.md && echo OK`
+

package/skills/gate-trace/SKILL.md

@@ -1,3 +1,4 @@
+# story: e80s01
 # story: e45s05
 ---
 name: gate-trace
@@ -90,3 +91,7 @@ gate_trace:
 
 Gate: READY → next: release-branch (final step before merge)
 Writes: state.yaml handoff.next_skill = release-branch
+
+## Verify
+
+→ verify: `test -x scripts/run-gate-trace-verify.sh && bash scripts/run-gate-trace-verify.sh --self-test && echo OK`

package/skills/security-review/fixtures/CWE-fail-open-verify-negative.sh

@@ -0,0 +1,5 @@
+#!/usr/bin/env bash
+# story: e80s05
+# Negative fixture: proper exit-code propagation (must NOT be flagged as fail-open)
+set -euo pipefail
+test -f scripts/run-skill-verify.sh

package/skills/security-review/fixtures/CWE-fail-open-verify-positive.sh

@@ -0,0 +1,5 @@
+#!/usr/bin/env bash
+# story: e80s05
+# Positive fixture: fail-open verify directive (must be flagged)
+# Vulnerable: exit 0 even when check fails via || echo
+grep -q 'bigpowers' /nonexistent/path 2>/dev/null || echo "FAIL: missing artifact"

package/skills/smoke-test/SKILL.md

@@ -1,5 +1,7 @@
+# story: e80s02
 ---
 name: smoke-test
+phase: verify
 description: "Post-deploy health-check against a live URL. Validates HTTP status, response content, and critical endpoints. Runnable standalone OR as the final step of the deploy skill."
 model: sonnet
 effort: standard
@@ -11,58 +13,72 @@ effort: standard
 >
 > **HARD GATE** — A failed smoke test means the deployment is broken. Do NOT mark a deploy as successful until all smoke checks pass.
 
-Validate a deployed application is healthy by running a configurable set of HTTP checks against live URLs. Each check asserts:
-- HTTP status code (e.g., 200 for success, 404 for expected-not-found)
-- Response body content signal (regex or jq expression)
-- Response time threshold (optional)
-
-Can be run standalone for quick health checks or chained as the final step of the `deploy` skill.
+Validate a deployed application is healthy by running HTTP checks against live URLs. Each check asserts HTTP status, optional body signal (regex), and optional response-time threshold.
 
 ## Configuration
 
-Smoke checks are defined in `smoke-checks.yaml` at the project root:
-
-See [REFERENCE.md](REFERENCE.md)
+Smoke checks live in `smoke-checks.yaml` at the project root:
 
-Checks can also be specified inline via environment variables or CLI arguments for ad-hoc use.
-
-### Check Schema
+```yaml
+base_url: "https://example.com"
+checks:
+  - name: "Homepage"
+    path: "/"
+    expected_status: 200
+    content_signal: "welcome|ok"
+    max_response_time_ms: 3000
+```
 
 | Field | Required | Default | Description |
 |-------|----------|---------|-------------|
-| `name` | Yes | — | Human-readable check name (used in report) |
+| `name` | Yes | — | Human-readable check name |
 | `path` | Yes | `/` | URL path relative to base_url |
 | `method` | No | `GET` | HTTP method |
 | `expected_status` | No | `200` | Expected HTTP status code |
-| `content_signal` | No | — | Regex or string to find in response body |
-| `max_response_time_ms` | No | — | Fail if response slower than this threshold (ms) |
+| `content_signal` | No | — | Regex or string in response body |
+| `max_response_time_ms` | No | — | Fail if slower than threshold (ms) |
+
+Ad-hoc single-URL mode: `DEPLOY_URL=https://host bash scripts/run-smoke.sh`
 
 ## Process
 
-### 1. Load smoke checks
+### 1. Load checks
 
-See [REFERENCE.md](REFERENCE.md)
+```bash
+SMOKE_CHECKS_FILE="${SMOKE_CHECKS_FILE:-smoke-checks.yaml}"
+BASE_URL="${DEPLOY_URL:-$BASE_URL}"
+test -f "$SMOKE_CHECKS_FILE" || test -n "$BASE_URL" || { echo "ERROR: no checks file or URL"; exit 1; }
+```
 
 ### 2. Run each check
 
-For each check in the configuration, perform an HTTP request:
+```bash
+bash scripts/run-smoke.sh "${DEPLOY_URL:-}" "${SMOKE_CHECKS_FILE:-smoke-checks.yaml}"
+```
 
-See [REFERENCE.md](REFERENCE.md)
+The runner performs curl requests per check, records pass/fail per assertion, and prints a summary.
 
 ### 3. Assert results
 
-See [REFERENCE.md](REFERENCE.md)
+- Any HTTP status mismatch → FAIL
+- Missing `content_signal` when configured → FAIL
+- Response time over `max_response_time_ms` → FAIL
+- Exit code non-zero → deployment not healthy
 
 ### 4. Generate report
 
-See [REFERENCE.md](REFERENCE.md)
+Capture stdout from `run-smoke.sh` as evidence. Persist to `specs/verifications/smoke-<date>.log` for release-branch.
 
 ## Integration with deploy skill
 
-The `deploy` skill references `smoke-test` as its final verification step:
-
 ```bash
-# In deploy workflow — after successful deploy
 DEPLOY_URL="$DEPLOY_URL" bash scripts/run-smoke.sh
 ```
 
+## Verify arc
+
+Part of **★ VERIFY ★**: `verify-work` → `validate-contracts` → `smoke-test` → `run-evals` → `audit-code`
+
+## Verify
+
+→ verify: `test -x scripts/run-smoke.sh && grep -q 'run-smoke.sh' skills/smoke-test/SKILL.md && grep -qv 'See \[REFERENCE.md\]' skills/smoke-test/SKILL.md && echo OK`

package/skills/validate-contracts/SKILL.md

@@ -1,5 +1,7 @@
+# story: e80s02
 ---
 name: validate-contracts
+phase: verify
 description: "Assert data shape consistency across system boundaries — live API responses against JSON Schema, key-set comparison across layers, data shape validation for migrations and exports. Catches silent data corruption before deploy."
 model: sonnet
 effort: standard
@@ -11,60 +13,30 @@ effort: standard
 >
 > **HARD GATE** — Contract files MUST be version-controlled alongside code. Outdated contracts are worse than no contracts. If a contract hasn't been reviewed in 30 days, flag it as stale.
 
-Validate that data structures stay in sync across system boundaries — front-end vs
-back-end, API responses vs expected schemas, config files vs code assumptions,
-migration output vs target shape.
+Validate that data structures stay in sync across system boundaries — front-end vs back-end, API responses vs expected schemas, config files vs code assumptions, migration output vs target shape.
 
 ## Contract types
 
-Three modes of validation:
-
 | Mode | What it catches | When to use |
 |------|----------------|-------------|
-| **Schema** | API response shape mismatches (missing field, wrong type) | Before every deploy, after API changes |
+| **Schema** | API response shape mismatches | Before every deploy, after API changes |
 | **Key-set** | Missing/unexpected keys across two data sources | Translation files, configs, enum definitions |
-| **Shape** | Column type or format violations in data files | After migrations, before consuming exports |
+| **Shape** | Column type or format violations | After migrations, before consuming exports |
 
 ## Contract file convention
 
-All contract files live in `specs/contracts/` and use YAML:
-
-See [REFERENCE.md](REFERENCE.md) for examples.
-
-### 1. API Response Contracts (`--schema`)
+All contract files live in `specs/contracts/` as YAML. See [REFERENCE.md](REFERENCE.md) for extended examples.
 
-Define expected API response shapes and validate live endpoints against them:
+### Key-set example
 
-See [REFERENCE.md](REFERENCE.md) for examples.
-
-Usage:
-
-```bash
-validate-contracts --schema specs/contracts/users.schema.yaml --url https://api.example.com/users
-# → PASS: /api/users matches expected schema (3/3 fields, types ok)
-# → FAIL: /api/users — field 'email' has type null (expected string)
+```yaml
+# specs/contracts/i18n-keys.yaml
+sources:
+  reference: src/locales/en.json
+  target: src/messages/en.json
+mode: subset
 ```
 
-### 2. Key-Set Contracts (`--key-set`)
-
-Assert that two data sources share a consistent set of keys:
-
-See [REFERENCE.md](REFERENCE.md) for examples.
-
-Usage:
-
-See [REFERENCE.md](REFERENCE.md) for examples.
-
-### 3. Data Shape Contracts (`--shape`)
-
-Validate that a data file matches expected column types and constraints:
-
-See [REFERENCE.md](REFERENCE.md) for examples.
-
-Usage:
-
-See [REFERENCE.md](REFERENCE.md) for examples.
-
 ## Process
 
 ### 1. Define contract
@@ -74,29 +46,20 @@ Create a YAML file in `specs/contracts/` following the schema for the mode.
 ### 2. Run validation
 
 ```bash
-bash scripts/validate-contracts.sh <contract-file>
+bash scripts/validate-contracts.sh specs/contracts/<contract>.yaml
 ```
 
-The runner auto-detects the contract type from the file content (presence of `schema:`,
-`sources:`, or `file:` + `fields:` keys).
+The runner auto-detects key-set contracts (`sources:` block). Schema and shape modes are documented in REFERENCE.md for consumer projects.
 
 ### 3. Read the report
 
-Output is JSON Lines (one event per line) plus a human-readable summary:
-
 ```
-{"event":"pass","check":"users.schema","detail":"3/3 fields match types"}
-{"event":"warn","check":"users.schema","detail":"field 'avatar' has format: uri (unexpected)"}
-{"event":"fail","check":"i18n-keys","detail":"missing: 2 keys in target"}
+PASS: key-set contract
+# or
+FAIL: key-set — N keys in reference missing from target
 ```
 
-Final summary:
-
-```
-=== Validate Contracts Summary ===
-Schema: 3/3 pass | Key-set: 1/1 fail | Shape: 2/2 pass
-FAILED: 1 contract has divergence
-```
+JSON Lines output for CI is planned for schema/shape modes; key-set failures exit non-zero.
 
 ### 4. Fix divergence
 
@@ -107,7 +70,13 @@ FAILED: 1 contract has divergence
 ### 5. Re-validate
 
 ```bash
-bash scripts/validate-contracts.sh <contract-file>
-# → All pass → ready to deploy
+bash scripts/validate-contracts.sh specs/contracts/<contract>.yaml
 ```
 
+## Verify arc
+
+Part of **★ VERIFY ★**: `verify-work` → `validate-contracts` → `smoke-test` → `run-evals` → `audit-code`
+
+## Verify
+
+→ verify: `test -x scripts/validate-contracts.sh && bash scripts/validate-contracts.sh --self-test && grep -q 'validate-contracts.sh' skills/validate-contracts/SKILL.md && echo OK`

package/skills/validate-fix/REFERENCE-generalize-fix.md

@@ -0,0 +1,31 @@
+# Generalize-fix (e80s04 / GH #98)
+
+After local hardening in `validate-fix`, sweep the **defect class** across the codebase.
+
+## Steps
+
+1. **Classify** — name the pattern (e.g. `unscoped org query`, `fail-open verify`, `hardcoded package manager`).
+2. **Sweep** — grep for sibling instances; record `match_count` and `grep_pattern`.
+3. **Resolve** — patch all matches in this PR **or** file one tracking issue listing every remaining instance.
+4. **Artifact** — write sweep evidence before declaring done:
+
+```bash
+cat > specs/verifications/generalize-sweep-BUG-YYYY-MM-DD-slug.json <<EOF
+{
+  "defect_class": "fail-open-verify",
+  "grep_pattern": "\\\\|\\\\| echo",
+  "match_count": 0,
+  "sweep_scope": "skills/*/SKILL.md",
+  "patched_in_pr": [],
+  "tracked_issues": []
+}
+EOF
+bash scripts/verify-generalize-sweep.sh specs/verifications/generalize-sweep-*.json
+```
+
+## Security classes
+
+When the defect class is security- or gate-relevant:
+
+- Add a row to `security-review` CWE fixture table (see `skills/security-review/SKILL.md` § CWE mapping mandate).
+- If security-impact was MEDIUM+: add regression test, false-positive exclusion rule, and threat-model update (HIGH+).

package/skills/validate-fix/SKILL.md

@@ -1,3 +1,5 @@
+# story: e80s01
+# story: e80s04
 # story: e45s08
 ---
 name: validate-fix
@@ -7,7 +9,7 @@ description: Prove a fix works before declaring done — re-run the failing test
 ---
 
 # Validate Fix
-> **HARD GATE** — **HARD GATE** — Fix must not regress. Run full test suite and manual UAT before declaring success. A fix that passes tests but breaks something else is a failure.
+> **HARD GATE** — Fix must not regress. Run full test suite and manual UAT before declaring success.
 
 
 Prove the fix works. "I think it works" is not evidence. Run the suite, show the output, then harden against recurrence.
@@ -65,10 +67,13 @@ For every bug fixed, add at least one prevention layer:
 - [ ] At least one hardening mechanism added
 - [ ] Hardening mechanism is tested
 
-> **Security recurrence hardening** — If the bug's security-impact assessment (from investigate-bug) was MEDIUM or higher, additionally check:
-> - [ ] Security regression test added (covers the exploit path)
-> - [ ] False-positive exclusion rule added (if applicable)
-> - [ ] Threat model updated (if impact was HIGH+)
+### 5b. Generalize-fix (HARD GATE — e80s04 / GH #98)
+
+Sweep the **defect class** across the codebase after local hardening — see [REFERENCE-generalize-fix.md](REFERENCE-generalize-fix.md).
+
+- [ ] Defect class documented (not just the one-line root cause)
+- [ ] Grep sweep run and `match_count` recorded
+- [ ] `verify-generalize-sweep.sh` passes on the artifact
 
 ### 6. Update the bug file and registry.yaml
 
@@ -107,3 +112,7 @@ Mechanical verification (tests passing) is only half the fix. You must prove **b
 
 Suggest next skill: `audit-code` → `commit-message`.
 
+## Verify
+
+→ verify: `grep -q 'generalize-fix' skills/validate-fix/SKILL.md && test -x scripts/verify-generalize-sweep.sh && bash scripts/verify-generalize-sweep.sh --self-test && echo OK`
+

package/skills-lock.json

@@ -8,7 +8,7 @@
     },
     "assess-impact": {
       "description": "Analyze the blast radius of a proposed change before any code is written. Maps dependents, affected stories, and test coverage. Produces specs/IMPACT_LATEST.md. Use before plan-work on any non-trivial change, when touching a shared module, or when the user asks \"what does this break?\".",
-      "sha256": "5a443f358b8a2369",
+      "sha256": "4168a9484c4e7d30",
       "path": "skills/assess-impactSKILL.md"
     },
     "audit-code": {
@@ -83,7 +83,7 @@
     },
     "develop-tdd": {
       "description": "Test-driven development with red-green-refactor loop using vertical slices. Use for features (epic tasks) or bugs (specs/bugs/BUG-*.md).",
-      "sha256": "91928da1d9757094",
+      "sha256": "8b3934e2291b863d",
       "path": "skills/develop-tddSKILL.md"
     },
     "diagnose-root": {
@@ -113,7 +113,7 @@
     },
     "enforce-first": {
       "description": "Apply the F.I.R.S.T test quality rubric (per CONVENTIONS.md §Tests) to a test suite or individual tests. Use when develop-tdd is writing tests, when test quality needs to be checked, or when user mentions F.I.R.S.T or \"test quality\".",
-      "sha256": "64cde2c5f741c77f",
+      "sha256": "1ec1183ee6377917",
       "path": "skills/enforce-firstSKILL.md"
     },
     "evolve-skill": {
@@ -143,7 +143,7 @@
     },
     "gate-trace": {
       "description": "\"Deterministic traceability quality gate — reads coverage matrix + blind-spot data, applies decision rules with oracle confidence downgrade, emits PASS/CONCERNS/FAIL/WAIVED verdict. Use before release-branch to gate merges on traceability.\"",
-      "sha256": "dd52baa85ff939e8",
+      "sha256": "87e0c49ff90ec34c",
       "path": "skills/gate-traceSKILL.md"
     },
     "generate-allure-report": {
@@ -333,7 +333,7 @@
     },
     "smoke-test": {
       "description": "\"Post-deploy health-check against a live URL. Validates HTTP status, response content, and critical endpoints. Runnable standalone OR as the final step of the deploy skill.\"",
-      "sha256": "664c11f36df51da8",
+      "sha256": "f75e9e57d4003209",
       "path": "skills/smoke-testSKILL.md"
     },
     "spike-prototype": {
@@ -368,12 +368,12 @@
     },
     "validate-contracts": {
       "description": "\"Assert data shape consistency across system boundaries — live API responses against JSON Schema, key-set comparison across layers, data shape validation for migrations and exports. Catches silent data corruption before deploy.\"",
-      "sha256": "7d944527859c3c14",
+      "sha256": "d93c9ae2953ac457",
       "path": "skills/validate-contractsSKILL.md"
     },
     "validate-fix": {
       "description": "Prove a fix works before declaring done — re-run the failing test, run the full suite, typecheck, lint, and harden against recurrence. Use after implementing a bug fix, when user says \"is this fixed?\", or before closing an investigation.",
-      "sha256": "e3a38b117a7f3b2d",
+      "sha256": "f94972af3fd48e3e",
       "path": "skills/validate-fixSKILL.md"
     },
     "verify-work": {