/foundry:certify-local <release>

The release train's first certification step (CONSTITUTION.md §V factory mode: spec → plan → build → integrate → certify locally → operator acceptance → staging). One deploy, one real run of every atom's already-merged E2E journeys, the runner's own output as the evidence — no new evidence format, no re-judged verdict.

When to trigger

• "certify <release> locally", "/foundry:certify-local <release>", after a release's atoms are all merged and before recording operator acceptance (/foundry:release accept, see skills/release/SKILL.md's tail).
• NEVER as a substitute for the operator's own test pass — this is the machine-derived evidence that pass exists to consult, not the sign-off itself (see the Anti-patterns section below).

Procedure

python3 "${CLAUDE_PLUGIN_ROOT}/skills/certify-local/certify_local.py" <release-id> \
  [--project-dir <dir>] [--plugin-root <dir>] [--boot-wait <seconds>] [--timeout <seconds>] [--json]

1. Resolve the release manifest (scripts/foundry_release.py's load_release — the SAME loader /foundry:release drives). An unknown/malformed <release-id> is a hard error, no emission.
2. Collect every atom's journeys[] tags (context/feat-spec-template.md's Journeys section — the AC-tagged E2E-suite source) and union them into ONE --grep regex. REFUSE ("no journey suite") if no atom in the release declares any tag — nothing to certify.
3. Resolve the release's target repo — EVERY atom's target_repo, resolved through the SAME _resolve_repo multi-repo pin every other release primitive uses, then asserted to AGREE (compared by resolved directory, not the raw config string). REFUSE, naming the split, if atoms resolve to differing repos — a release deploys as ONE unit, certify-local cannot boot more than one. Then look for a playwright.config.* at that repo's root. REFUSE ("no journey suite") if none exists — journeys are declared but there is no Playwright suite to run them.
4. Resolve the boot recipe — project declaration first, the stack profile as fallback (feat-foundry-boot-recipe-precedence, AC-BRP-1..7). The release's resolved venue's repos.<key>.boot_command in .claude/foundry-project.json wins whenever it is a non-empty string — the active stack profile is not consulted at all. Otherwise, resolves the active stack profile's app_exercise_binding.boot — via the SAME resolution scripts/foundry-verify.py uses (foundry-stack-profile.py's read_lock/resolve_lock, imported read-only, never redefined). A malformed/unreadable manifest degrades to the profile path (never raises) but is reported on its own line, distinct from "declared nothing" (AC-BRP-4/5). REFUSE ("no boot recipe") if NEITHER source yields a recipe — naming declaring boot_command as the always-actionable remedy, and "activate a different stack profile" only when a .foundry/stack-profile.lock already exists (AC-BRP-3).
5. Deploy ONCE. Launch the boot command as a single background process, cwd = the target repo root. This is the SAME make dev-analog every stack profile already declares — no new deploy mechanism.
6. Run the FULL tagged journey suite — plain npx playwright test --grep <pattern> --reporter=json against that one running instance. The JSON reporter is Playwright's OWN evidence format; nothing here re-implements or re-formats it.
7. Tear the boot process down (SIGTERM, SIGKILL after a grace period) regardless of the suite's outcome.
8. Report per-atom pass/fail — a GROUPING VIEW over Playwright's own per-test ok verdicts: for each atom's declared tags, every test whose TITLE contains that tag (the classic title-tag --grep convention — no separate tag API) contributes its own outcome; a tag with zero matching titles is a named miss (declared coverage that was never written), not silently dropped. The runner's raw stdout/stderr/JSON report is the evidence attached alongside the per-atom table — never a custom score, never a re-judged pass.

Inputs / Outputs

• In: <release-id> (resolved via CLAUDE_PROJECT_DIR/.foundry/releases/<id>/release.yaml), .claude/foundry-project.json's repos.<key>.boot_command (first-precedence) / the active .foundry/stack-profile.lock (fallback), the target repo's playwright.config.* + journey spec files.
• Out: {"verdict": "pass"|"fail", "release_id", "profile_id", "repo_root", "grep_pattern", "boot_recipe": {"command", "provenance", "repos_key"}, "playwright": {...the runner's own output...}, "atoms": {<id>: {"verdict", "tags"}}}, or a CertifyError in one of two distinguishable message classes: REFUSED (nothing dispatched): … for every PRE-DISPATCH precondition above (no journey suite / no boot recipe / an unknown release / the release's atoms resolving to differing target repos), and ERRORED mid-run: … for a failure AFTER the boot process was launched (it died before the suite ran, or the suite itself timed out/failed to launch) — the booted process is always torn down before either raises.

Native plugin eval

certify-local (above) certifies the product repo journeys. The plugin itself — this repo, agentic-foundry — has its own native certify path (autonomy-continuation R4 plugin-eval-suite), independent of certify-local and never a substitute for the pytest suite:

claude plugin eval . --trust-plugin --json results.json --threshold 0.8 --max-cost-usd 20

Run from the plugin root (this repo). . targets "every case under its eval directory, with that plugin loaded" (the primary doc, "Test plugins with evals"). Every eval run and every llm/ baseline grader is a REAL model call billed against the operator's own plan or API key — never run this unattended in CI without the operator enabling it (see docs/how-to/plugin-evals.md).

Exit codes (the primary doc's own table, quoted):

Subtraction candidates. Each case's report carries an Ablation Δ — the with-plugin score minus the no-plugin baseline score. A case whose Ablation Δ is ≤ 0 across two consecutive runs is a subtraction candidate for the next wave: the plugin isn't what made that case pass, so the skill or hook it exercises is not pulling its weight. The report (report.html / aggregate-result.json's cases[].aggregates.delta) is the evidence a follow-up atom cites — never a re-judged verdict on top of it.

Anti-patterns

• Treating a certify-local PASS as the delivery sign-off. It is the machine-derived evidence the operator's own test pass consults — the constitution's "operator sign-off is the terminal gate" principle (context/constitution-template.md §I.5), "Delivery sign-off — operator-held, the terminal step" states plainly that the operator tests every release themselves and gives the final judgement LAST; no gate or CI job asserts that practice ran, and none should. certify-local feeds that judgement, it does not replace it.
• A vacuous pass when there is nothing to run. No journeys declared, or no boot recipe resolvable, is always a named REFUSE — never a silent green.
• Re-implementing Playwright's own reporter/assertion engine. The evidence IS the runner's own JSON report + stdout/stderr; the per-atom table is a grouping view over it, never an independently computed verdict.
• Booting more than once / leaving the boot process running. One deploy, one run, always torn down — matching the charter's "deploy the release once locally" framing exactly.

Certify by re-measure

A second, self-contained certify path (certify-by-remeasure, autonomy-continuation R4) for the programme's OWN exit criteria — not a release's journey suite, and not run by this skill's driver above, and not something this or any other skill invokes automatically: per the permission floor map, foundry-autonomy-instrument.py ships with NO standing allow-row precisely because the operator runs this report-only CLI manually, granting it per-invocation themselves — it is intentionally absent from every fenced command block in this tree.

The operator runs it directly (never pasted into a fenced block here, on purpose): the script is scripts/foundry-autonomy-instrument.py under the plugin root, invoked with --since <release-date> --projects-dir ~/.claude/projects --certify against their own ~/.claude/projects (or wherever their transcripts live), with --since set to the release date being re-measured against (e.g. the tag date of the release that shipped the change being certified). The instrument prints its usual report — the six ratios plus the three turn-end counts (human_resumed/harness_resumed/session_end) — and, because --certify was given, one more line: CERTIFY-PASS, or CERTIFY-OPEN: <ratio> <value> vs <threshold>, ... naming every ratio that misses the programme's thresholds (context/autonomy-thresholds.yaml, overridden by a workspace copy at docs/programs/autonomy-continuation/thresholds.yaml when one exists). This CLI is report-only and always exits 0 whether the verdict is PASS or OPEN — it gates nothing, exactly like the rest of the instrument.

A CERTIFY-OPEN names what stays open; it is not a failure to fix inside this skill, it is a finding to carry back to the programme's own state — see docs/programs/autonomy-continuation/PROGRAM.md for what each named ratio means and what closes it. As with certify-local above, this verdict is machine-derived evidence, never the delivery sign-off itself: per CLAUDE.md's "Delivery sign-off — operator-held, the terminal step," the operator's own test pass over the real 30-day window remains the terminal judgement that closes the programme, whichever way this verdict reads.