verify

/foundry:verify

The executor the frozen stack-profile recipe was authored for. It runs SDLC step 7 (static validation) and step 8 (tests + coverage) for the active stack — resolving the recipe from the stack-profile lock and dispatching the profile-declared commands fail-closed, so a forgotten typecheck / coverage step or a wrong-stack command set is caught by construction, not by memory.

It is a dispatcher, not a definer: it does NOT define recipes and implements NO linter / formatter / test runner of its own. Every command it runs is a profile-declared string from schema/stack-profile.schema.json's static_validation + test_recipe.

When to trigger

• "verify", "/foundry:verify", "run the static-validation + tests", or before cutting a PR / at the software-delivery verify step, to run the active stack's step-7/step-8 recipe.

Procedure (advisory, ordered)

1. Resolve the active profile. Read .foundry/stack-profile.lock under CLAUDE_PROJECT_DIR and call the merged loader's resolve_lock() (scripts/foundry-stack-profile.py, imported read-only). resolve_lock() returns a LIST of resolved profile docs.
   • No lock present (read_lock() is None) => SKIP (no active stack) — a distinct, reasoned skip, never a pass.
   • Resolution raises (unpinned / sha-drifted / version-mismatch / core-incompatible / malformed lock) => FAIL (a present lock that won't resolve is a broken build contract, not "nothing to do").
   • Zero resolved profiles => FAIL ("nothing to run" is never green). More than one with no selection mechanism => FAIL (ambiguous active profile; selection over N is deferred).
   • Exactly one => use it.
2. Read the recipe BY NAME (do not redefine). From the single resolved profile, read the schema-shaped command strings: static_validation.{format, lint, typecheck, build} then test_recipe.{unit, integration, e2e} — these seven strings are the ordered command set. test_recipe.coverage_gate is a NUMBER: surface it in the run record (the declared threshold); do NOT dispatch it as a command — the test commands enforce the threshold themselves (e.g. pytest --cov-fail-under=N), and verify catches their non-zero exit.
3. Dispatch in declared order. Run each command string under a shell, cwd = the project/repo dir, full utf-8 stdout/stderr capture, with a timeout. Any non-zero exit or launch failure => that record's passed=False.
4. Report the verdict (fail-closed). Return the ordered {phase, key, command, exit_code, passed} records, the surfaced coverage_gate, and an overall verdict:
   • pass iff a lock is active, resolution yields exactly one profile, AND every dispatched command exits zero.
   • fail if any command exits non-zero (or fails to launch), OR resolution raised, OR the resolved count is not exactly one.
   • skip only when no lock is present. The process exit code mirrors the verdict: pass->0, fail->non-zero, skip->a distinct non-pass status (never 0 masquerading as a green run).