rsc-universal 0.1.1

package/skills/vercel/scripts/verify.sh

@@ -0,0 +1,168 @@
+#!/usr/bin/env bash
+# verify.sh — lint a target vercel.json against the 2025-2026 platform rules.
+#
+# Usage:
+#   bash scripts/verify.sh [path/to/vercel.json]
+#
+# With no arg it discovers ./vercel.json (then a shallow search). If no vercel.json
+# exists anywhere in range, that is NOT a failure — exit 0 (read-only, no false alarm).
+#
+# Checks (FAIL = exit 1; WARN = advisory, still exit 0 if nothing failed):
+#   1. valid JSON
+#   2. FAIL if both `builds` and `functions` are present (mutually exclusive)
+#   3. FAIL if any `functions.*.memory` is set (Fluid caveat — memory is a dashboard setting)
+#   4. WARN if `$schema` is missing (lose autocomplete/validation)
+#   5. for each `crons[]`: FAIL if `path` is missing or does not start with `/`, or `schedule` missing
+#
+# Pure jq/node/python3 — no network, no auth, no mutation. Runs on macOS bash 3.2 and CI bash 5.
+set -euo pipefail
+
+if [[ -n "${NO_COLOR:-}" ]]; then YEL=""; GRN=""; RED=""; RST=""
+else YEL=$'\033[33m'; GRN=$'\033[32m'; RED=$'\033[31m'; RST=$'\033[0m'; fi
+warn() { printf '%s[warn]%s %s\n' "$YEL" "$RST" "$*"; }
+ok()   { printf '%s[ ok ]%s %s\n' "$GRN" "$RST" "$*"; }
+fail() { printf '%s[fail]%s %s\n' "$RED" "$RST" "$*"; }
+
+have() { command -v "$1" >/dev/null 2>&1; }
+
+# Resolve target.
+TARGET="${1:-}"
+if [[ -z "$TARGET" ]]; then
+  if [[ -f vercel.json ]]; then
+    TARGET="vercel.json"
+  else
+    TARGET=$(find . -maxdepth 2 -name 'vercel.json' -not -path '*/node_modules/*' 2>/dev/null | head -n1 || true)
+  fi
+fi
+
+if [[ -z "$TARGET" || ! -f "$TARGET" ]]; then
+  ok "no vercel.json found in range — nothing to verify"
+  exit 0
+fi
+
+# Need a JSON engine. Prefer node (rich logic), then python3. jq optional fallback for validity only.
+ENGINE=""
+if have node; then ENGINE="node"
+elif have python3; then ENGINE="python3"
+elif have jq; then ENGINE="jq"
+else
+  warn "no node/python3/jq available — cannot lint $TARGET (skipping, not a failure)"
+  exit 0
+fi
+
+FAILED=0
+
+if [[ "$ENGINE" == "jq" ]]; then
+  # jq-only: can only confirm validity. Use -e (some jq builds exit 0 on parse error without it).
+  if jq -e . "$TARGET" >/dev/null 2>&1; then
+    ok "valid JSON ($TARGET)"
+    warn "only jq available — skipping builds/memory/crons rules (install node or python3 for full lint)"
+  else
+    fail "not valid JSON ($TARGET)"; FAILED=1
+  fi
+  if [[ $FAILED -eq 0 ]]; then ok "all checks passed"; else fail "checks failed"; fi
+  exit "$FAILED"
+fi
+
+# Full lint via node or python3. The runner prints lines: "OK …", "WARN …", "FAIL …".
+run_node() {
+node - "$TARGET" <<'JS'
+const fs = require("fs");
+const path = process.argv[2];
+let cfg;
+try { cfg = JSON.parse(fs.readFileSync(path, "utf8")); }
+catch (e) { console.log("FAIL not valid JSON: " + e.message); process.exit(0); }
+console.log("OK valid JSON (" + path + ")");
+
+const hasBuilds = Object.prototype.hasOwnProperty.call(cfg, "builds");
+const hasFns = Object.prototype.hasOwnProperty.call(cfg, "functions");
+if (hasBuilds && hasFns) console.log("FAIL `builds` and `functions` are mutually exclusive — remove `builds`");
+
+if (hasFns && cfg.functions && typeof cfg.functions === "object") {
+  for (const [glob, val] of Object.entries(cfg.functions)) {
+    if (val && typeof val === "object" && Object.prototype.hasOwnProperty.call(val, "memory")) {
+      console.log("FAIL functions[\"" + glob + "\"].memory is set — under Fluid, memory is a dashboard setting, not vercel.json");
+    }
+  }
+}
+
+if (!Object.prototype.hasOwnProperty.call(cfg, "$schema")) {
+  console.log("WARN missing `$schema` — add \"https://openapi.vercel.sh/vercel.json\" for validation");
+}
+
+if (Object.prototype.hasOwnProperty.call(cfg, "crons")) {
+  const crons = cfg.crons;
+  if (!Array.isArray(crons)) {
+    console.log("FAIL `crons` must be an array");
+  } else {
+    crons.forEach((c, i) => {
+      if (!c || typeof c !== "object") { console.log("FAIL crons[" + i + "] is not an object"); return; }
+      if (typeof c.path !== "string" || c.path.length === 0) console.log("FAIL crons[" + i + "] missing `path`");
+      else if (c.path[0] !== "/") console.log("FAIL crons[" + i + "] path must start with `/` (got \"" + c.path + "\")");
+      if (typeof c.schedule !== "string" || c.schedule.length === 0) console.log("FAIL crons[" + i + "] missing `schedule`");
+    });
+  }
+}
+JS
+}
+
+run_python() {
+python3 - "$TARGET" <<'PY'
+import json, sys
+path = sys.argv[1]
+try:
+    with open(path) as f:
+        cfg = json.load(f)
+except Exception as e:
+    print("FAIL not valid JSON: %s" % e); sys.exit(0)
+print("OK valid JSON (%s)" % path)
+
+has_builds = "builds" in cfg
+has_fns = "functions" in cfg
+if has_builds and has_fns:
+    print("FAIL `builds` and `functions` are mutually exclusive — remove `builds`")
+
+if has_fns and isinstance(cfg.get("functions"), dict):
+    for glob, val in cfg["functions"].items():
+        if isinstance(val, dict) and "memory" in val:
+            print('FAIL functions["%s"].memory is set — under Fluid, memory is a dashboard setting, not vercel.json' % glob)
+
+if "$schema" not in cfg:
+    print('WARN missing `$schema` — add "https://openapi.vercel.sh/vercel.json" for validation')
+
+if "crons" in cfg:
+    crons = cfg["crons"]
+    if not isinstance(crons, list):
+        print("FAIL `crons` must be an array")
+    else:
+        for i, c in enumerate(crons):
+            if not isinstance(c, dict):
+                print("FAIL crons[%d] is not an object" % i); continue
+            p = c.get("path")
+            if not isinstance(p, str) or not p:
+                print("FAIL crons[%d] missing `path`" % i)
+            elif not p.startswith("/"):
+                print('FAIL crons[%d] path must start with `/` (got "%s")' % (i, p))
+            if not isinstance(c.get("schedule"), str) or not c.get("schedule"):
+                print("FAIL crons[%d] missing `schedule`" % i)
+PY
+}
+
+if [[ "$ENGINE" == "node" ]]; then OUT=$(run_node); else OUT=$(run_python); fi
+
+# Render results and set exit status.
+while IFS= read -r line; do
+  [[ -z "$line" ]] && continue
+  case "$line" in
+    OK\ *)   ok   "${line#OK }" ;;
+    WARN\ *) warn "${line#WARN }" ;;
+    FAIL\ *) fail "${line#FAIL }"; FAILED=1 ;;
+    *)       printf '%s\n' "$line" ;;
+  esac
+done <<EOF
+$OUT
+EOF
+
+if [[ $FAILED -eq 0 ]]; then ok "all checks passed (warnings are not failures)"
+else fail "one or more checks failed"; fi
+exit "$FAILED"

package/skills/verify/SKILL.md

@@ -0,0 +1,188 @@
+---
+name: verify
+description: "Use when implementation is finished and someone is about to say it's done, shipped, working, or ready to merge in the rsc-sdd flow — the post-implementation GATE that demands evidence before any 'done' claim. Triggers: 'verify this feature', 'is it done?', 'run the checks', 'lint/type/test before merge', 'did the acceptance criteria pass', 'confirm the tasks are complete', 'gate before review', 'audit the change', 'are we green', 'prove it works'. Runs the relevant stack skill's scripts/verify.sh (lint, type-check, tests, coverage, dependency/vuln audit), then walks every task done-check and every spec acceptance criterion, attaching the actual command output as evidence. Writes the verification record under 02-DOCS/wiki/sdd/ and points to the review phase. NOT writing tests or features (that is implement), NOT adversarial code reading (that is review), NOT root-cause diagnosis of a failing test (that is debug). Honors the harness accompaniment dial."
+tags: [sdd, verify, test]
+recommends: [review]
+profiles: [core, full]
+origin: risco
+---
+
+# verify — the evidence gate before "done"
+
+`verify` is the post-implementation **gate** in the rsc-sdd chain. Implementation just finished; nobody is allowed to call it *done*, *fixed*, *working*, or *ready to merge* until the evidence exists and has been read. This skill produces that evidence: it runs the project's real quality gate, walks every task's done-check and every acceptance criterion from the spec, and records the result. Pass or fail, the verdict is grounded in command output you actually saw — never in a hunch.
+
+The one rule everything else serves: **a claim of done is a claim about evidence. No evidence, no claim.** A green feeling is not green output.
+
+This is a process skill. It does not own the lint/type/test tooling — the **stack skills do** (`../fastapi/SKILL.md`, `../go/SKILL.md`, `../nextjs/SKILL.md`, `../flutter/SKILL.md`, each shipping `scripts/verify.sh`; data-layer checks come from `../postgresdb/SKILL.md`, security from `../secure-coding/SKILL.md`). `verify` orchestrates them and judges the whole against the spec.
+
+## When to use / when not to
+
+Use when:
+
+- Implementation of a task or feature is complete and you (or the user) are about to say so.
+- A fix has been applied and you need to confirm it actually resolves the issue, with the app's own checks.
+- You're at the gate before the `review` phase, or before a merge / PR.
+- Someone asks "is it done?", "are we green?", "did it pass?", "can I merge?".
+
+Do NOT use when:
+
+- You're still writing tests or production code → that's the `implement` phase (TDD lives there).
+- A check is failing and you need to find out *why* → that's `debug` (reproduce → isolate → fix). `verify` reports the failure and hands off; it does not diagnose.
+- You're reading the diff adversarially for design/correctness smells a test can't catch → that's `review`.
+- There is no spec or task list to verify against → you're earlier in the chain; go to `specify`/`plan`/`tasks` first.
+
+## Read the room first (accompaniment dial)
+
+Before running anything, read `02-DOCS/wiki/harness/user-profile.md` for the technical + accompaniment level and adapt:
+
+- **L0** — run the gate, show pass/fail and the one-line failing summary. Minimal words.
+- **L1** — add one line of *why* per failing check.
+- **L2** — narrate each gate (what lint/type/test/audit checks and why it matters here).
+- **L3** — explain every result, what each acceptance criterion means in plain language, and what the user should decide next.
+
+If no profile exists yet, default to non-technical framing and keep the verdict legible. The verdict itself (pass / fail per item) never changes with the dial — only how much you explain around it.
+
+## The gate (run in this order)
+
+```text
+LOCATE  → find the spec, the task done-checks, and which stack(s) changed
+RUN     → execute the relevant stack scripts/verify.sh (lint, type, test+coverage, audit)
+WALK    → check every task done-check and every spec acceptance criterion against real output
+RECORD  → write the verification record under 02-DOCS/wiki/sdd/, index it
+VERDICT → PASS only if every item has passing evidence; otherwise FAIL with the gaps + handoff
+```
+
+Never collapse a step. Never write the verdict before RUN and WALK have produced output you read.
+
+### 1 — LOCATE
+
+- Read `02-DOCS/wiki/sdd/config.yaml` if present. Prefer `testing.commands.verify`
+  from config for repo-level gates. If config is missing and the change is
+  non-trivial, mark that as a verification risk and recommend `sdd-init`.
+- Read the spec at `02-DOCS/wiki/sdd/specs/<slug>.md` for its **acceptance criteria**.
+- Read the plan/task list at `02-DOCS/wiki/sdd/plans/<slug>.md` for each task's **done-check**.
+- Read `02-DOCS/wiki/sdd/progress/<slug>.md` if present for apply evidence and
+  completed tasks. Missing progress does not automatically fail, but it is a
+  traceability gap to record.
+- Determine which subprojects/stacks the change touched (from `git status`/`git diff --name-only` and the manifests). That tells you *which* stack `verify.sh` to run — possibly more than one in a monorepo.
+- If the constitution exists (`02-DOCS/wiki/sdd/constitution.md`), note its quality bars (coverage floor, lint level) — they are part of the gate.
+
+If the spec or task list is missing, stop: there is nothing to verify against. Say so and point back up the chain.
+
+### 2 — RUN the stack gate
+
+For each touched stack, run that stack skill's gate and **capture the output verbatim**:
+
+```bash
+# delegate to the stack that owns the tooling; do not reinvent it
+./scripts/verify.sh            # from the subproject root the stack skill documents
+```
+
+If `config.yaml` provides `testing.commands.verify`, run those commands first or explain why a stack-specific `verify.sh` supersedes them. Do not silently invent a different command when the config already says what to run.
+
+| Stack | Gate command (owned by the stack skill) | Covers |
+| --- | --- | --- |
+| FastAPI / async Python | `./scripts/verify.sh` (`../fastapi`) | ruff/black, mypy, pytest+coverage, pip-audit |
+| Go module | `./scripts/verify.sh` (`../go`, run in the module root) | gofmt, vet, staticcheck, golangci-lint, `test -race -cover`, govulncheck |
+| Next.js / React | `./scripts/verify.sh` (`../nextjs`) | eslint, tsc --noEmit, test, build |
+| Flutter / Dart | `./scripts/verify.sh` (`../flutter`) | `dart format`, `flutter analyze`, `flutter test` |
+| Postgres / data layer | migration + query checks (`../postgresdb`) | schema/migration apply, constraint + query checks |
+| Security-sensitive change | audit per `../secure-coding` | input/authz/secrets review, dependency vuln scan |
+
+Rules for RUN:
+
+- The stack `verify.sh` **skips missing tools** (yellow SKIP) rather than failing on them — so a SKIP is not a pass. Note every SKIP; a skipped test suite means that criterion is **unverified**, which is not the same as verified-passing.
+- A non-zero exit from a tool that actually ran is a hard FAIL. Record the failing tool and its output.
+- Run from the directory the stack skill documents (Go runs from the module root; others from the subproject root). Don't guess paths.
+- If no `scripts/verify.sh` exists for a touched stack, that's a gap — say the gate is incomplete and recommend the user add the stack skill, rather than hand-rolling a one-off check that drifts from the real gate.
+
+### 3 — WALK the done-checks and acceptance criteria
+
+The stack gate proves the code is *clean and tested*. It does **not** prove the feature does what the spec asked. Walk both lists explicitly:
+
+- **Task done-checks** — for each task in the plan, confirm its done-check is satisfiable from evidence (a passing test, a file that exists, an endpoint that returns the documented shape). Mark each ✅ with the evidence or ❌ with what's missing.
+- **Acceptance criteria** — for each criterion in the spec, point at the concrete evidence that satisfies it. A criterion with no test and no observable proof is **unverified** — treat it as a FAIL item, not a pass, until there is evidence.
+
+Where a criterion needs runtime proof (a page renders, a command produces output), drive it through the relevant tool — defer browser/app runtime to the stack skill's own runtime guidance rather than inventing a check here.
+
+A criterion you "reviewed by reading the code" is not verified. Reading is `review`; verifying needs an observable result.
+
+### 4 — RECORD
+
+Write a dated verification record to `02-DOCS/wiki/sdd/verifications/<slug>-YYYY-MM-DD.md` so the project's living knowledge carries the proof, then ensure it's indexed in the root `CLAUDE.md` `## Knowledge map` under the `sdd/` topic. Keep it short and factual:
+
+```markdown
+# Verification — <slug> — YYYY-MM-DD
+
+## Stack gate
+- fastapi/scripts/verify.sh → PASS (ruff ok, mypy ok, pytest 142 passed, coverage 87% ≥ 80 floor, pip-audit ok)
+- nextjs/scripts/verify.sh  → FAIL (tsc: 2 type errors in app/checkout/page.tsx) — handed to debug
+
+## Task done-checks
+- [x] T1 create /orders endpoint — evidence: test_orders.py::test_create passed
+- [ ] T4 idempotency key — done-check NOT met: no test exercises the duplicate-POST path
+
+## Acceptance criteria (spec)
+- [x] AC1 user can place an order — evidence: e2e test green
+- [ ] AC3 duplicate submit is a no-op — UNVERIFIED: no observable proof
+
+## Verdict: FAIL — 2 open items (T4 done-check, AC3). Not ready for review.
+```
+
+Append-only spirit: don't overwrite a prior run's record; a new run is a new dated file. The record is the receipt the `review` and `ship` phases trust.
+
+### 5 — VERDICT
+
+- **PASS** only when *every* stack gate that ran is green (no FAILs), *every* task done-check is met with evidence, and *every* acceptance criterion has observable proof. Then, and only then, say it's verified — and point to `review`.
+- **FAIL** the moment any item lacks passing evidence. List the open items precisely (which check, which criterion, what's missing). Do not soften it. A single unverified acceptance criterion fails the whole gate.
+- Hand each failing kind to the right place: a failing test/type error → `debug`; a missing test for a criterion → back to `implement`; a spec ambiguity that surfaced → `clarify`.
+
+## Anti-patterns → STOP
+
+| Rationalization | Reality |
+| --- | --- |
+| "The tests passed last run, I'll trust that." | Re-run now. Code changed since; stale green is not green. Evidence is current, or it isn't evidence. |
+| "verify.sh printed SKIP for the tests — close enough." | A SKIP is *unverified*, not passing. The criterion it covers is still open until a real run passes. |
+| "I read the code and the criterion is obviously satisfied." | Reading is `review`. Verifying needs an observable result — a test, a response, a rendered page. |
+| "Lint and types are green, so it's done." | The stack gate proves clean code, not correct behavior. Walk the acceptance criteria too. |
+| "Coverage dipped below the floor but the feature works." | The constitution's coverage bar is part of the gate. Below floor = FAIL, not a footnote. |
+| "One acceptance criterion is unproven; ship the rest." | The gate is all-or-nothing. One unverified criterion fails the whole verdict. |
+| "A test is failing — let me just fix it real quick." | That's `debug`, a different discipline. `verify` reports the failure and hands off; it does not patch mid-gate. |
+| "I'll write the verdict, then run the checks to confirm." | Backwards. RUN and WALK first; the verdict is the *consequence* of output you already read. |
+
+## Red flags — abort the verdict
+
+- You're about to type "done"/"passing"/"works" and you cannot point to a specific line of command output that proves it. Stop; go run it.
+- The stack `verify.sh` for a touched stack doesn't exist or didn't run — the gate is incomplete; say so instead of declaring PASS.
+- An acceptance criterion has no test and no observable proof — it's unverified; the verdict is FAIL.
+- A failing check tempts you to fix it inline — that's scope drift into `debug`; record the failure and hand off.
+
+## Result envelope
+
+End with:
+
+```json result-envelope
+{
+  "status": "complete|failed",
+  "executive_summary": "Verification PASS/FAIL with open evidence gaps.",
+  "artifact": "02-DOCS/wiki/sdd/verifications/<slug>-YYYY-MM-DD.md",
+  "next_recommended": "review|debug|implement|clarify",
+  "risk": "low|medium|high",
+  "skill_resolution": {
+    "used": ["verify"],
+    "missing": [],
+    "fallback": [],
+    "compact_rules": ["Run configured verify commands.", "Acceptance criteria need observable proof."]
+  },
+  "evidence": ["command outputs", "done-check walk", "acceptance walk"]
+}
+```
+
+## Next in the chain
+
+A **PASS** record is the entry ticket to the next phase: **`review`** (adversarial read of the diff for what the gate can't catch), then **`ship`** (PR/merge with Eric-only authorship). A **FAIL** routes back: failing checks to **`debug`**, missing coverage to **`implement`**, surfaced ambiguity to **`clarify`**. Either way the verification record under `02-DOCS/wiki/sdd/verifications/` travels with the work as its proof.
+
+## Orientación (siempre)
+
+Cierra cada turno con el **bloque-brújula** (📍 dónde estás · ✅ qué hiciste · 🧭 por qué · ➡️ siguiente, terminando en pregunta), calibrado al dial de `02-DOCS/wiki/harness/user-profile.md`. **Nunca termines en seco.** Protocolo completo: skill `orient` → `skills/orient/references/orientation-contract.md`. (Defiere a `suggest` el "¿instalo la skill que falta?".)
+

package/skills/verify/evals/README.md

@@ -0,0 +1,78 @@
+# Eval harness — `verify` skill
+
+`verify` is the rsc-sdd post-implementation **gate**. These evals check two
+things: that it **triggers** at the right moment (someone is about to claim
+"done"/"green"/"ready to merge") and stays quiet on near-misses, and that it
+**measurably changes the behavior** — running the real stack gate, walking the
+done-checks and acceptance criteria, and refusing to claim done without
+evidence. Cases live in `cases.yaml`. Grading is done by an **agent harness** (a
+Claude Code agent with skills loaded) plus a human spot-check, because both
+routing and "did it actually demand evidence" are judgment calls — there is no
+pure shell runner.
+
+## What's in `cases.yaml`
+
+- `should_trigger` — prompts that MUST load `verify` (8 cases, incl. non-obvious
+  phrasings like "are we ready for review yet?" and "prove the fix works").
+- `should_not_trigger` — near-misses that must route to a real sibling
+  (`route_to`): writing tests (`fastapi`), debugging a flaky test (`go`),
+  building the gate script (`nextjs`), security audit (`secure-coding`),
+  migration/constraint checks (`postgresdb`). The recurring trap: anything that
+  WRITES or RUNS code, or OWNS the tooling, is a stack skill — `verify` only
+  orchestrates and judges.
+- `capability` — one end-to-end scenario with a `must_include` rubric to grade
+  WITH vs WITHOUT the skill.
+
+## Triggering eval
+
+Goal: the skill fires when a "done" claim is imminent and never on a near-miss.
+
+1. Configure an agent with the **full catalog of skill descriptions** available
+   for routing (verify + the rsc-sdd phase skills it chains to — implement,
+   debug, review, clarify, ship — plus the stack/process skills: fastapi, go,
+   nextjs, flutter, postgresdb, secure-coding, deployment, harness, init) so
+   routing competes realistically.
+2. For each `should_trigger` prompt: feed it cold, record whether `verify` is
+   the skill the agent loads. Run **3–5 trials** per prompt (fresh context).
+3. For each `should_not_trigger` prompt: confirm `verify` does NOT load and that
+   the chosen skill matches `route_to`. Same 3–5 trials.
+4. Score: `triggered_correctly / total_trials` across both lists.
+
+**Pass bar: ≥ 90% trigger accuracy** over all prompts and trials, with **zero
+systematic false-positives** on the "write the tests" / "debug the failing
+test" / "build the gate script" near-misses — those are the known traps. A
+prompt about *producing* tests or *fixing* a failure must not pull in `verify`.
+
+## Capability eval
+
+Goal: prove the skill changes the answer, not just the routing.
+
+1. For the `capability` scenario, run it **twice**:
+   - **WITHOUT** the skill (base agent, no `verify` loaded).
+   - **WITH** the `verify` skill loaded.
+2. Grade each output against the scenario's `must_include` checklist — one point
+   per checkable item covered. A human or grading agent marks each present /
+   absent.
+3. Compute coverage = `items_covered / total_items` for each run.
+
+**Pass bar: WITH the skill covers ≥ 80% of `must_include`; WITHOUT clearly
+lower** (target a ≥ 30-point gap). The discriminating behaviors are the ones a
+base agent skips: actually *running* the stack `verify.sh` (not trusting a
+prior run), treating a tool SKIP as unverified, walking *every* acceptance
+criterion for observable proof, refusing to fix a failing check inline, and the
+all-or-nothing verdict (one unverified criterion ⇒ FAIL). If the base answer
+already scores ~80%, the case isn't discriminating — tighten the rubric.
+
+## Notes on honesty
+
+- Trials are stochastic; report the raw fraction, not a rounded "pass".
+- The highest-signal capability check is the **verdict discipline**: a correct
+  answer refuses to call the feature done while one acceptance criterion is
+  unproven, and hands a failing check to `debug` instead of patching it. Treat a
+  confident "looks done, merge it" with no command output as a **capability
+  failure** even if the reasoning reads well.
+- The skill ships **no `scripts/verify.sh` of its own** — it is a process gate
+  that *delegates* to the stack skills' gates. Do not eval it as if it owned the
+  tooling; eval whether it correctly orchestrates and judges.
+- Re-run after any edit to `SKILL.md` — wording changes shift both triggering
+  and rubric coverage.

package/skills/verify/evals/cases.yaml

@@ -0,0 +1,74 @@
+skill: verify
+
+# Prompts that MUST load the `verify` skill. `verify` is the rsc-sdd
+# post-implementation GATE: run the relevant stack scripts/verify.sh
+# (lint/type/test/audit), walk every task done-check and every spec acceptance
+# criterion, and produce an evidence-backed PASS/FAIL verdict before anyone
+# claims "done". It does NOT write tests/features (implement), diagnose a
+# failing check (debug), or read the diff adversarially (review).
+should_trigger:
+  - prompt: "I finished the orders feature — can you confirm it's actually done before I merge?"
+    why: "Confirming 'done' before a merge is the gate's whole job: run the stack gate, walk the done-checks and acceptance criteria, and produce evidence."
+
+  - prompt: "Run the lint, type-check and tests on this change and tell me if we're green."
+    why: "Running the project's lint/type/test gate and reporting pass/fail is exactly what verify orchestrates via the stack scripts/verify.sh."
+
+  - prompt: "Did all the acceptance criteria from the spec actually pass?"
+    why: "Checking spec acceptance criteria against real evidence is a core WALK step of the verify gate, not implementation or review."
+
+  - prompt: "Are we ready for review yet?"
+    why: "The transition into the review phase is gated by verify; readiness means every check is green and every criterion is proven."
+
+  - prompt: "Prove the fix works — I don't want to just take your word for it."
+    why: "Demanding observable evidence rather than a claim is the skill's founding rule ('no evidence, no claim'); verify produces that proof."
+
+  - prompt: "Walk every task's done-check and show me what's still open."
+    why: "Enumerating task done-checks with evidence (met / not met) is the explicit WALK step verify performs and records."
+
+  - prompt: "Before I say this is shipped, gate it: checks plus criteria, with the receipts."
+    why: "A pre-ship gate that ties stack checks to acceptance criteria with recorded evidence is precisely verify, the phase that precedes review and ship."
+
+  - prompt: "Coverage and the audit need to be green for this PR — can you check and record the result?"
+    why: "Running coverage/dependency-audit through the stack gate and writing a verification record under 02-DOCS/wiki/sdd/ is verify's RUN+RECORD behavior."
+
+# NEAR-MISS prompts that must NOT load `verify`. Each routes to a sibling that
+# actually exists in this repo. The recurring trap: anything that WRITES or
+# RUNS code, or owns the lint/test tooling itself, belongs to a stack skill or
+# another phase — verify only orchestrates and judges.
+should_not_trigger:
+  - prompt: "Write the pytest cases and coverage config for this FastAPI service."
+    route_to: "fastapi"
+    why: "Authoring the actual tests and tooling is owned by the fastapi stack skill (which ships scripts/verify.sh); verify runs that gate, it does not write the suite."
+
+  - prompt: "Our `go test -race` is failing intermittently — find out why and fix it."
+    route_to: "go"
+    why: "Diagnosing and fixing a flaky Go test is root-cause work owned by the go stack skill's testing guidance; verify reports the FAIL and hands off, it does not debug."
+
+  - prompt: "Set up the verify.sh quality gate (eslint, tsc, build) for our Next.js app."
+    route_to: "nextjs"
+    why: "Building/owning the stack gate script itself is the nextjs skill's job; verify consumes that script, it does not create the stack's tooling."
+
+  - prompt: "Audit this auth endpoint for injection and broken access control before we trust it."
+    route_to: "secure-coding"
+    why: "A security audit of code is owned by secure-coding; verify may invoke that audit as part of the gate but the hands-on review belongs to the security skill."
+
+  - prompt: "Check that this migration applies cleanly and the CHECK constraint behaves as expected."
+    route_to: "postgresdb"
+    why: "Schema/migration and constraint verification is data-layer work owned by postgresdb; verify delegates to it rather than hand-rolling SQL checks."
+
+# Concrete tasks verify should guide, with a rubric to grade WITH vs WITHOUT
+# the skill loaded. A skill-guided answer runs the real gate, walks both lists,
+# and refuses to call it done without evidence; an ungrounded answer tends to
+# eyeball the code, trust stale results, or declare success prematurely.
+capability:
+  - scenario: "Implementation of the 'duplicate-submit is a no-op' order feature just finished in a FastAPI service. The user says 'it's done, let's merge'. Verify it."
+    must_include:
+      - "Reads the accompaniment level from 02-DOCS/wiki/harness/user-profile.md and adapts verbosity (verdict legibility unchanged by the dial)."
+      - "LOCATES the spec acceptance criteria and the task done-checks, and identifies the FastAPI subproject as the touched stack from git diff/manifests."
+      - "RUNS the fastapi stack scripts/verify.sh (ruff/black, mypy, pytest+coverage, pip-audit) from the documented root and captures the output verbatim rather than reusing a previous run."
+      - "Treats any tool SKIP (missing tool) as UNVERIFIED, not as a pass, and notes the constitution's coverage floor as part of the gate."
+      - "WALKS every task done-check and every acceptance criterion, marking each with concrete evidence (a passing test / observable result) or as an open FAIL item — specifically flags the duplicate-submit criterion as UNVERIFIED if no test exercises the duplicate-POST path."
+      - "Does NOT fix a failing test inline; if a check fails it records it and hands off to debug, and refuses to fix-then-claim."
+      - "RECORDS a dated verification file under 02-DOCS/wiki/sdd/verifications/ and indexes it in the root CLAUDE.md Knowledge map."
+      - "Returns a VERDICT that is PASS only if EVERY item has passing evidence; a single unverified acceptance criterion makes the whole verdict FAIL — and refuses to call it 'done' otherwise."
+      - "On PASS, points to the review phase; on FAIL, routes failing checks to debug and missing coverage back to implement."