The smoke suite a module runs against itself. Derived from the checklist at the bottom of module-surface.md, expanded into checks that name what they exercise, how, and what counts as passing.

Until a runnable suite exists per language, this table is the contract. A module claiming conformance states which rows it passes.

Audience: someone building a module and wanting to know whether it is done, or reviewing one and wanting to know what to try.

How to read the status column#

The runner column records versable-runner (services-api) as of 2026-08-17. It is the most complete instance and still fails closer to half of this, which is the point of writing the table down.

• pass: verified, by a live call or by reading the code that decides it
• fail: verified absent or wrong
• n/r: not runnable without a mutating call, which this pass did not make

Live probes were unauthenticated GETs against https://services-api-gvpyoxqxja-uc.a.run.app. No POST was issued, so every row needing a job creation is n/r rather than assumed.

Witnesses, added 2026-08-18, and why they do not move the tally#

services-api gained a test suite (tests/, 9 files, 59 tests) at f46d894. Run in a scratch copy of the repo, all 59 pass in 0.6 s. Rows below cite a witness test where one exists.

A witness is not a pass. This document's own closing section requires a conformance check to run against a deployed module over HTTP, because "a module that passes in-process and fails deployed has passed nothing". Every one of those 59 tests runs in-process against a FastAPI test client. So a witness raises confidence about the code, changes no verdict, and the tally stands unchanged at 11 pass, 20 fail, 11 n/r of the original 42 (the earlier 13/19/10 in this paragraph was a stale count; the table is the truth). Reading a witness as a pass re-creates the [collect-not-run] trap the closing section warns about.

What the 2026-08-18 pass did change is two rows whose stated REASON was wrong after f46d894, B3 and B6, corrected below.

A. Health, identity, discovery#

B. Auth and tenancy#

C. Submit#

D. Reading results#

E. Lifecycle#

F. Callbacks#

G. Local and safety#

H. The manifest against the behaviour#

A manifest is a promise. These rows are the ones that read it back and check the module keeps it, so none of them can run until a module serves /manifest (A7). Every row here is n/r for versable-runner for that one reason, and they do not enter the tally above until the route exists.

Where versable-runner stands#

The result column is versable-runner's scorecard, not a property of the checks. A row reads n/r because running it against a deployed service would need a credential, a mutating call, or a redeploy, not because the check is unrunnable in principle. A module built on the runner template runs every row in-process, where pointing a bucket at a nonexistent name is a config change rather than a deploy, so its acceptance bar is every row executed and every row passing.

Of the original 42 checks: 11 pass, 20 fail, 11 not runnable without a mutating call or a redeploy. Eight rows were added on 2026-08-18 (B9 to B14, D8, D9), all n/r for versable-runner, so the table now holds 50 rows outside section H: 11 pass, 20 fail, 19 n/r. (A: 8 rows, B: 14, C: 7, D: 9, E: 4, F: 4, G: 4. Anyone adding a row should re-tally rather than trusting this line; an earlier version of it was wrong on three of the four numbers.)

The table is the floor, not the ceiling. It stops at the job core plus auth, callbacks and local safety. It does not reach: outputs beyond D9's existence check, the review queue's grouping (?group_by=reason), usage events' shape and idempotency (usage-event.md), reference-data version reporting, cache behaviour (canon/06), or any capability's own quality. A module supplies its own eval group for the last one (see below); the rest are rows to add when a module serves them.

Module-supplied checks (group M, out of tally). A module ships its own capability evals (patterns/05, the fixtures and judges of its payload) as a group this CLI runs after the contract rows and reports separately; they are never counted in the contract tally, because they measure the capability, not conformance.

foundry-runner's own column is written by the CLI against the local runner (runner step 1, ../PLAN.md forge-1) and lives in ../instances/foundry-runner.md, not here; this table's result column stays versable-runner's scorecard. A8 moved from pass to fail when the prose guide became /guide: the guide exists and is good, but it answers at /usage, and a route the contract does not name is not a passing check.

The failures cluster, and the clusters are the same ones canon calls open: everything in F (callbacks), most of B (per-caller identity and tenancy), and the manifest-dependent rows across A, C and D. Nothing in the fail column is a bug in versable-runner. They are places the contract asks for something the instance predates.

Two rows are near-misses worth fixing cheaply. A1 returns {"ok":true} where the contract says {status:"ok"}; that is a one-line change. C2 reports enqueuing where the contract says expanding; also one line, and worth aligning before other modules copy the name.

One observation the table does not capture: the first GET /health timed out after 15 seconds and the second returned instantly. The service scales to zero and its cold start exceeds a naive client timeout. Any conformance runner needs a warm-up call before it times anything, or C1's "under a second" will fail for a reason that has nothing to do with submit.

How this will run#

Not built. The intended shape, so nobody invents a different one:

A single executable per language, foundry-conform <base_url>, taking a credential and a tenant from the environment, running the table top to bottom, and emitting one line per check plus a JSON summary. Checks that mutate (everything marked n/r above) run only with --allow-writes and against a non-prod base URL, refusing to run otherwise.

Three properties matter more than coverage:

• It runs against a deployed module over HTTP, not against an import. A module that passes in-process and fails deployed has passed nothing.
• Each check names the contract line it enforces, so a failure is a pointer into this tree rather than a number.
• It distinguishes fail from not-run. A suite reporting "32 of 50" without saying that 10 of those never executed is the [collect-not-run] trap wearing a percentage.

Until it exists, a module states its row-by-row status in its own README and this table is what it states them against.