This page lists every gate in the deterministic battery. It explains the invariant each gate proves and identifies the script behind it. Three per-OS Python-stack workflows run in parallel, alongside a fourth Go-daemon workflow with its own three-OS matrix (see the Quick Reference table and the aggregate note below). Run the deterministic subset locally in one command before you commit:

bash scripts/check-all.sh

Worktree-native flow (ratified 2026-07-06): the full battery gates on pull_request, not on a plain push to main. The main branch only merges a PR after its required checks pass. A plain push to main runs almost nothing. In tests-linux.yml, the single syntax job (bash -n and AST-parsing every .ps1) runs unconditionally. Every other job in all three per-OS workflows gates on github.event_name == 'pull_request', workflow_dispatch, or the nightly workflow_call. This includes the install-smoke job in both tests-mac.yml and tests-windows.yml. The [T] CI All aggregate badge workflow carries no push trigger at all. It runs only on pull_request. The pull_request trigger itself carries no paths-ignore filter. A trigger-level filter that skips a required check would block the merge of a docs-only PR forever. The docs/wiki diet returns as a job-level no-op instead.

The aggregate polls four workflows now, and a name missing from that list gates nothing. [T] CI All's aggregate job doesn't run tests itself — it polls tests-linux, tests-mac, tests-windows, and, since 2026-09-05, daemon (the Go daemon's own three-OS matrix, in the Quick Reference table below), requiring success from each before it reports green. Before that date daemon.yml existed but wasn't in the polled list, so its result was invisible to the merge gate: PR #554 merged with the Go suite red because the one required check never looked at it. scripts/test_ci_consistency.py (see check-ci-consistency below) now pins the polled workflow list, so a workflow can't go back to silently gating nothing.

This script checks the V4 #23 kernel-owned auto-orchestration contracts. It runs the real scripts via their CLIs against a throwaway scratch vault and asserts deterministic outputs. It acts as the integration complement to the per-function unit suite. We trimmed it to 85 lines at V5-5 / LC-9 when we extracted the PM-half and Developer-half.

This script checks the PM-owned orchestration signals extracted from verify-v4.sh at V5-5 / LC-9. It will travel to the crickets PM-trigger plan when that ships. It runs agentm-side until then.

verify-v4.sh segment E only asserted the idle chain's dry-run plan. That tests planning order and leaves every step free to no-op silently — the V4 #39 shape. This script closes the gap (issue #71): it runs the same chain without --dry-run and asserts what changed on disk.

Every assertion pins to observed reality — a file that exists, a literal from the fixture, a count from find. None recompute an expectation with the implementation's own formula, because a check that derives its expectation from the code under test only proves the two agree.

gh run list --workflow "[T] Linux Tests"    --limit 3
gh run list --workflow "[T] Mac Tests"       --limit 3
gh run list --workflow "[T] Windows Tests"   --limit 3
gh run view <run-id> --log-failed             # drill into the failing step

A red run on Windows but a green run on POSIX indicates a path-separator or pwsh-host assumption regression. A red run across all operating systems indicates a canonical-spec or adapter-parity drift. Try running bash scripts/check-parity.sh locally to verify.

Not every red run is a failure. A run can be marked failure having dispatched no work at all, and it reads exactly like a broken build until you look closer.

The signature. The run completed within a few seconds of being created, and its jobs sit at status: queued with an empty steps list — GitHub accepted the run and never assigned it a runner. A genuine failure has a job with conclusion: failure and a named failing step.

# created and updated seconds apart => suspect an orphan, not a failure
gh api repos/<owner>/<repo>/actions/runs/<run-id> \
  --jq '{created: .created_at, updated: .updated_at, attempt: .run_attempt}'

# zero failed jobs on a "failed" run confirms it
gh api repos/<owner>/<repo>/actions/runs/<run-id>/jobs \
  --jq '[.jobs[] | select(.conclusion=="failure")] | length'

Why it blocks the PR. Those undispatched jobs stay pinned to the pull request as pending forever. They are not slow; nothing will ever report them. The PR sits BLOCKED on checks that cannot complete, and ci-all fails honestly, because from its side a run that never ran and a run that failed look identical.

Recovery, in order.

1. gh run rerun <run-id> — but verify it took. It can no-op silently; the run should move to run_attempt: 2. A run still reporting attempt=1 after a rerun did not restart.
2. If the rerun does not take, close and reopen the pull request. That fires fresh pull_request events and produces new run IDs, which is the reliable fix. Note it also clears auto-merge, so re-arm with gh pr merge --auto afterwards.
3. Re-run ci-all last, never alongside the OS workflows. It polls tests-linux/tests-mac/tests-windows and requires success from each, so starting it while they are queued makes it fail waiting on its own inputs.

Reading the aftermath. GitHub keeps orphaned runs in the commit's history, so the PR page shows old red beside new green. Trust gh pr checks and mergeStateStatus over the run list — and compare run IDs: the fresh set shares a higher ID prefix than the abandoned one.

Why there is no concurrency: block anywhere, and why adding one would not help here: the orphaned runs are the current head's, and concurrency only cancels superseded runs. It would not have prevented any of this. It would also turn every routine force-push into an aggregate failure, since a cancelled run is not success and that is the only value the poller accepts. The push: trigger is filtered to branches: [main], so PR pushes do not double-fire either — there is no duplication to collapse.

The [H] Health Nightly workflow (.github/workflows/health-nightly.yml, R1.8 Task 4) runs daily at 06:00 UTC and on manual workflow_dispatch. It layers heavier checks on top of the fast tier this page documents. These heavier checks are too slow or dependency-heavy to run on every push. They include real-embedding recall (no stub mode), a live MCP daemon round-trip over real HTTP, a report of every VERIFY_*_FAULT=1 mode's outcome, and a cold-install dogfood pass. The job renders the scorecard and uploads it (HTML and the raw JSONL records) as a build artifact named health-scorecard-ubuntu with a 14-day retention. It never commits or pushes. The V8 proving Lane S on 2026-07-13 retired the branch/PR/workflow_dispatch/--admin merge machinery this job used to run. The job acts purely as a clean-runner regression signal.

R1.8 Task 5 added a health-nightly-macos job (macos-latest). This job runs the same heavy tier as a conformance leg. It uploads its own JSONL output as a build artifact named health-heavy-tier-macos with a 14-day retention. Task 5 also folds the static scripts/health/dark-checks.jsonl registry (5 designed-not-built capabilities) into the render pipeline. The scorecard carries a "Dark checks" section that lists them separately from the scored families.

You do not read this CI artifact day to day. A local health-pass runner job (templates/jobs/health-pass.yaml, a daily agentm-runner.sh tick) appends to the vault-resolved history ledger and renders ~/.cache/agentm/telemetry/scorecard.html. The /console and the morning brief link to this local file. See Health scorecard for details on that half.

AA4 (2026-07-08) — the ⑫ Hardening-II cold-install acceptance, per the B3 ruling in ROADMAP-TAIL-ADJUDICATIONS.md. We added two more checks to the cold-install dogfood step rather than creating a separate job. (5) dashboard honest-dark on a bare install — an observability-console render over a rollup built from zero telemetry events, and a Health-Scorecard render over only the static dark-checks registry (zero live records). Neither check may fabricate a number when nothing has actually run yet. (6) fan-out/budget gates fail CLOSED with no config — a scratch .harness/ with no budget.yaml must still throttle a fleet that reports large spend. It must not skip the ceiling check outright. As built today, check 5's observability-console half passes. Its Health-Scorecard half and check 6 both FAIL. The render_markdown function shows a fabricated Health Index: 0.0/100 🟢 headline on zero live records. The runner/cycle.py _read_daily_ceiling function returns None on a missing budget.yaml. This disables the ceiling gate rather than applying a safe default. We filed both as queued bugfix plans instead of fixing them inline. An acceptance pass reports findings; it doesn't fix them.

This workflow never blocks a merge. The fast tier above (tests-linux.yml/tests-mac.yml) serves as the only merge gate. The nightly run can go red without stopping development.

One command runs the deterministic battery. It executes unit tests, every check-* gate, the integration checks (verify-v4, verify-orchestration-briefing, verify-idle-chain, verify-hook-resolution, verify-state-routing, verify-reflection, verify-dreaming, verify-declare-a-type, verify-auto-org-meters, verify-phases, verify-memory-roundtrip), and run-ablation-baseline. It prints a PASS/FAIL table and exits non-zero on any failure. The scripts/check-all.sh script acts as the living source of truth for the exact gate count. A restated number here drifts as gates merge or land. Count the gate "<name>" ... lines in the script if you need the current figure:

bash scripts/check-all.sh

The script deliberately omits the heavier smoke-install and gitleaks checks. CI runs those slower external tools on every push. Run them directly if you need them: bash scripts/smoke-install-bash.sh (POSIX) or pwsh -NoProfile -File scripts/smoke-install-pwsh.ps1 (Windows). The check-all.sh script acts as the maintained source of truth for the local battery. Add a gate line to it as the project grows.

scripts/probe-round-trip.sh reads the memory system's end-to-end claim: save a fact, come back in a fresh process, ask sideways, get it back. It captures through the real agentmd, optionally runs one enrichment call, and asks three questions that share no content word with the note, against twelve distractors, with a control question that must not return the target.

It is not in check-all.sh and should not be added. It needs a running embedder, and --enrich spends a model call. A gate with those dependencies is a gate somebody turns off, and the battery has to stay something you can run on any machine at any time.

Three properties are worth knowing before you read a result from it. The dense arm is required — fusion is lexical only, asking sideways is the case the dense arm exists for, and a run without an embedder exits 2 (cannot run) rather than passing. Sideways is checked rather than asserted: a question reusing the note's own words is refused, because that proves the index can find a string, not that a memory can be recalled. And the rank the target achieves is reported but not gated, since ranking belongs to the retrieval track rather than to this check.

bash scripts/probe-round-trip.sh --embedder-url http://127.0.0.1:8901 --embed-model embeddinggemma-300M-Q8_0

Add --enrich for the whole arc. Exit codes: 0 every bar met, 1 a bar missed, 2 could not run.

• Releasing Conventions — CI must be green before you invoke ship-release.
• How to refresh an installed harness — what a re-run touches vs. leaves alone.
• Vault write protocol — the protocol the check-vendored-parity gate's vault-lock mode keeps byte-identical across its two copies.
• Foundations HLD — the installer-boundary rule the gates enforce.