v0.10.0

Multi-model runs enforced on a single receipt. On v0.9.0 and earlier,
a run given more than one model in inputs.models produced one receipt per
model and then decided the job from exactly one of them - the one whose
filename sorted first, which is a property of the model id and not of the run.
A skill that regressed on a model that did not sort first was reported as
a pass: a green check, and a brightgreen "passing" badge naming the other
model. The failure message, when it did fire, named every model that had been
requested rather than the ones that actually regressed. A run that measured
nothing at all (NOT_MEASURED) also exited 0, indistinguishable from a pass.
Fixed in this release: the decision is taken over every receipt a run
produced, a receipt count below the requested model count fails closed, the
badge renders the worst decision and names the model it came from, and the job
summary carries one row per model. inconclusive and not measured never
render as success on the badge, the summary or the check title.
If you pin this action, move your pin. If a Driftproof check has been
green on a multi-model run, that result was only ever about one of your
models; re-run it on this version before relying on it.

Also fixed: a receipt edited after it was sealed was rendered and enforced as
though it verified. driftproof badge has refused a receipt whose
receipt_hash does not verify since v0.9.0 (spec 026); the multi-model
decision path added in this release went through a new command that did not,
so a hand-edited receipt could produce a green check and a passing badge.
driftproof decide now verifies every receipt in the set before any decision
is taken and before anything is written, naming the file it refused.
This path was added in this release, and no published version carried the defect.

Also fixed: npm run gate on a clean clone of the published tag died with an
unhandled ENOENT instead of reporting a verdict, because the publish step
silently dropped force-added files from the commit. The build now refuses to
publish a tree that does not carry what it copied.

Also in this release: the plugin self-test workflow that ships in this repository runs the published tree's own gate, node tests/gate.js --scan-root ., rather than a self-test file that exists only outside the published tree, so CI on this repository checks the same files you install the plugin from (spec 028, A-028-34).
The four checks that keep governance files, state/, reports/pending-publish.md and internal reports out of the published tree now decide from what the tree actually contains rather than from a command-line flag, so a published tree carrying any of those files fails its own gate however the gate is invoked (spec 028, A-028-35 and A-028-36).

Provenance

• Published commit: 607303240896708b502ee1ef0a754c6033bc37bd
• Tag: v0.10.0, annotated tag object 4eb98b8a3ef574095f9d74751fe53a5fb7af4006
• Tracked files: 725
• Published-tree gate: npm run gate on a depth-1 clone of the published v0.10.0 tag, run with no network: 621/621 passed, 0 failed, 1 not applicable; the one row not applicable because this checkout carries no refs/heads/main (a shallow or tag-only clone), so the merge range this rule is about does not exist here
• Built from source commit: d133cfc7fe938ed1704ffe7969c02f92c422bf36