bigpowers 2.85.2 → 2.86.1

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

@@ -20,6 +20,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:
@@ -29,3 +38,7 @@ For each failing criterion:
 4. Re-run the suite to confirm it still passes
 
 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/.pi/prompts/gate-trace.md

@@ -85,3 +85,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/.pi/prompts/migrate-spec.md

@@ -57,7 +57,7 @@ List every artifact found matching the detected framework. Present the list to t
 
 See [REFERENCE.md](REFERENCE.md) — `Detected: GSD...`
 
-→ verify: `find . -maxdepth 4 \( -name "ROADMAP.md" -o -name "spec.md" -o -name "prd.md" -o -name "REQUIREMENTS.md" \) 2>/dev/null | grep -v ".git" | head -15`
+→ verify: `test -d specs && test -w specs`
 
 ### Step 3 — Transform (one artifact at a time, show diffs)
 
@@ -93,9 +93,9 @@ See [REFERENCE.md — REQUIREMENTS_TRACE.yaml format](./REFERENCE.md#requirement
 
 > **HARD GATE** — Never overwrite an existing `specs/` file without explicit user confirmation. Merge into it if it exists; don't clobber.
 >
-> → verify: `git diff --name-only HEAD -- specs/ 2>/dev/null | head -20`
+> → verify: `git rev-parse --git-dir >/dev/null 2>&1 && test -d specs`
 
-→ verify: `ls specs/*.md 2>/dev/null | head -15`
+→ verify: `test -d specs && [ "$(ls specs/*.md specs/*.yaml 2>/dev/null | wc -l | tr -d " ")" -gt 0 ]`
 
 ### Step 4 — Generate state.yaml
 

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

@@ -83,7 +83,7 @@ After writing capsule tasks, suggest `kickoff-branch` (if not already on a featu
 
 ## 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`
+→ verify: `test -f scripts/lib/plan-consistency-check.sh && EPIC=$(ls -d specs/epics/*/ 2>/dev/null | grep -v archive | sort | head -1) && test -n "$EPIC" && bash scripts/lib/plan-consistency-check.sh "$EPIC" >/dev/null 2>&1`
 
 
 

package/.pi/prompts/smoke-test.md

@@ -9,61 +9,76 @@ description: "Post-deploy health-check against a live URL. Validates HTTP status
 >
 > **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)
-
-Checks can also be specified inline via environment variables or CLI arguments for ad-hoc use.
+Smoke checks live in `smoke-checks.yaml` at the project root:
 
-### 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`
+
 ---
 
 # Smoke Test — Reference

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

@@ -31,7 +31,7 @@ Look for `// story: X.Y` or `# story: X.Y` comments in source files and tests:
 grep -rn "story: " . --include="*.ts" --include="*.js" --include="*.py" --include="*.sh" | grep -v node_modules
 ```
 
-→ verify: `grep -rn "story: " . --include="*.ts" --include="*.sh" | wc -l`
+→ verify: `[ "$(grep -rl "story: " . --include="*.ts" --include="*.sh" --include="*.py" 2>/dev/null | wc -l | tr -d " ")" -gt 0 ]`
 
 ### 3. Build the matrix
 

package/.pi/prompts/validate-contracts.md

@@ -9,60 +9,30 @@ description: "Assert data shape consistency across system boundaries — live AP
 >
 > **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`)
-
-Define expected API response shapes and validate live endpoints against them:
+All contract files live in `specs/contracts/` as YAML. See [REFERENCE.md](REFERENCE.md) for extended examples.
 
-See [REFERENCE.md](REFERENCE.md) for examples.
+### Key-set example
 
-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
@@ -72,29 +42,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
 
@@ -105,10 +66,17 @@ 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`
+
 ---
 
 # Validate Contracts — Reference

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

@@ -4,7 +4,7 @@ description: "Prove a fix works before declaring done — re-run the failing tes
 ---
 
 # 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.
@@ -62,10 +62,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
 
@@ -103,3 +106,41 @@ Mechanical verification (tests passing) is only half the fix. You must prove **b
 - **The verify command from specs/bugs/BUG-*.md or the active epic task `verify` field must pass**
 
 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`
+
+---
+
+# 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/.pi/skills/develop-tdd/SKILL.md

@@ -55,7 +55,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.
 
@@ -119,6 +125,10 @@ 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/.pi/skills/diagnose-root/SKILL.md

@@ -21,4 +21,4 @@ Four phases — do not skip. Update the active `specs/bugs/BUG-*.md` file at eac
 
 ## Verify
 
-→ verify: `BUG_FILE=$(ls -t specs/bugs/BUG-*.md 2>/dev/null | head -1); test -n "$BUG_FILE" && [ "$(grep -cE 'Reproduce|Isolate|Hypothesize|Verify' "$BUG_FILE")" -ge 4 ]`
+→ verify: `[ "$(grep -lE 'Reproduce' specs/bugs/BUG-*.md 2>/dev/null | grep -cv "\.okf\.md$")" -ge 1 ]`

package/.pi/skills/enforce-first/SKILL.md

@@ -21,6 +21,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:
@@ -30,3 +39,7 @@ For each failing criterion:
 4. Re-run the suite to confirm it still passes
 
 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/.pi/skills/gate-trace/SKILL.md

@@ -86,3 +86,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/.pi/skills/migrate-spec/SKILL.md

@@ -58,7 +58,7 @@ List every artifact found matching the detected framework. Present the list to t
 
 See [REFERENCE.md](../../../skills/migrate-spec/REFERENCE.md) — `Detected: GSD...`
 
-→ verify: `find . -maxdepth 4 \( -name "ROADMAP.md" -o -name "spec.md" -o -name "prd.md" -o -name "REQUIREMENTS.md" \) 2>/dev/null | grep -v ".git" | head -15`
+→ verify: `test -d specs && test -w specs`
 
 ### Step 3 — Transform (one artifact at a time, show diffs)
 
@@ -94,9 +94,9 @@ See [REFERENCE.md — REQUIREMENTS_TRACE.yaml format](../../../skills/migrate-sp
 
 > **HARD GATE** — Never overwrite an existing `specs/` file without explicit user confirmation. Merge into it if it exists; don't clobber.
 >
-> → verify: `git diff --name-only HEAD -- specs/ 2>/dev/null | head -20`
+> → verify: `git rev-parse --git-dir >/dev/null 2>&1 && test -d specs`
 
-→ verify: `ls specs/*.md 2>/dev/null | head -15`
+→ verify: `test -d specs && [ "$(ls specs/*.md specs/*.yaml 2>/dev/null | wc -l | tr -d " ")" -gt 0 ]`
 
 ### Step 4 — Generate state.yaml
 

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

@@ -84,7 +84,7 @@ After writing capsule tasks, suggest `kickoff-branch` (if not already on a featu
 
 ## 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`
+→ verify: `test -f scripts/lib/plan-consistency-check.sh && EPIC=$(ls -d specs/epics/*/ 2>/dev/null | grep -v archive | sort | head -1) && test -n "$EPIC" && bash scripts/lib/plan-consistency-check.sh "$EPIC" >/dev/null 2>&1`
 
 
 

package/.pi/skills/smoke-test/SKILL.md

@@ -10,61 +10,76 @@ description: "Post-deploy health-check against a live URL. Validates HTTP status
 >
 > **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](../../../skills/smoke-test/REFERENCE.md)
-
-Checks can also be specified inline via environment variables or CLI arguments for ad-hoc use.
+Smoke checks live in `smoke-checks.yaml` at the project root:
 
-### 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](../../../skills/smoke-test/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](../../../skills/smoke-test/REFERENCE.md)
+The runner performs curl requests per check, records pass/fail per assertion, and prints a summary.
 
 ### 3. Assert results
 
-See [REFERENCE.md](../../../skills/smoke-test/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](../../../skills/smoke-test/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`
+
 ---
 
 # Smoke Test — Reference

package/.pi/skills/trace-requirement/SKILL.md

@@ -32,7 +32,7 @@ Look for `// story: X.Y` or `# story: X.Y` comments in source files and tests:
 grep -rn "story: " . --include="*.ts" --include="*.js" --include="*.py" --include="*.sh" | grep -v node_modules
 ```
 
-→ verify: `grep -rn "story: " . --include="*.ts" --include="*.sh" | wc -l`
+→ verify: `[ "$(grep -rl "story: " . --include="*.ts" --include="*.sh" --include="*.py" 2>/dev/null | wc -l | tr -d " ")" -gt 0 ]`
 
 ### 3. Build the matrix