feat(engine): VERIFY-COMMAND — the one command a stranger has instead of CI

The forge has no Actions runners, so this org publishes no CI badge; the
stated substitute is one command runnable from a clean clone. A repo with
something runnable and no such command in its README is a WARN — and the
finding names what the repo already has, so the remedy is one line.

The subject is MEASURED, never read off a class. Five of 21 clones have
nothing runnable at all and answer VERIFY-NONE at OK; they span plugin,
shared-asset AND standalone, so every class-level phrasing of this rule
would fail a correct repository somewhere. Measured: 10 document a
command, 6 do not, 5 have no subject.

Two things bound the rule. It adds no API call, so it has no SKIP at all
— copying the null-input guard from every check since PIN-DEAD would
print a false "not run". And it runs nothing, so its OK says documented,
never passing.

Not built, with distinct reasons recorded as invariants: RELEASE-ASSETS
is rejected permanently for having NO SUBJECT (0 of 21 READMEs mention an
asset download; the 18/18 fire rate is a proxy and must not be quoted as
the reason). TAG-SIGNED is BLOCKED ON AN OPERATOR DECISION, not rejected
— filing it with the rejections would read as settled when it is one
yes/no from acquiring its whole subject.

Also fixes this repo's own surface, which had drifted behind its engine:
four checks had shipped without a row in the README check table, and
Requirements still said "two network calls" after the third was added.

230 tests (from 213).

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01LwZeAZ8cHmGZofM9dryuT9

CHANGELOG.md

@@ -6,8 +6,43 @@ versioning is [Semantic Versioning](https://semver.org/spec/v2.0.0.html).
 
 ## [Unreleased]
 
+## [0.10.0] — 2026-08-12
+
 ### Added
 
+- **`VERIFY-COMMAND` — can a stranger check that this repository works?** The
+  forge has no Actions runners registered, so this org publishes no CI badge;
+  the stated substitute is one command a stranger can run from a clean clone. A
+  repository with something runnable and no such command in its README is a
+  `WARN` in the `missing` bucket, and the finding names what the repo already
+  has, so the remedy is one line.
+
+  | outcome | level | code |
+  |---|---|---|
+  | the README shows a verification command | `OK` | `VERIFY-COMMAND` |
+  | nothing runnable exists in the repository | `OK` | `VERIFY-NONE` |
+  | a suite exists and the README shows no command | `WARN` | `VERIFY-MISSING` |
+
+  The subject is **measured**, never read off a class: a `scripts.test` entry, or
+  a tracked file that is unambiguously an executable test — not merely a file
+  living under `tests/`, which counted golden transcripts and fixtures and would
+  have made "you have tests a stranger cannot run" false on the loudest findings
+  it produced. Measured across all 21 registered clones: 10 document a command,
+  6 do not, and 5 have nothing runnable at all. Those five span three different
+  classes, so every class-level phrasing of this rule fails a correct repository
+  somewhere.
+
+  The 6-of-21 rate is acceptable for a reason that travels with the rule: the
+  org publishes exactly one stance on verification, so an undocumented suite is
+  not a second legitimate convention the way bump-first vs bump-at-release was
+  for the rejected `VERSION-DRIFT`.
+
+  It adds **no API call** — it reads the README and `package.json` — and so has
+  no `SKIP` at all, unlike every check added since `PIN-DEAD`. It can only ever
+  fell a MISSING command: nothing here runs anything, so its `OK` says
+  *documented*, never *passing*.
+
+
 - **`RELEASE-CURRENT` — does the release page show the version the code is on?**
   A stranger who wants a version they can name lands on the forge's release
   page, and it is the one surface refs cannot answer: a release is not a ref, so
@@ -75,6 +110,25 @@ versioning is [Semantic Versioning](https://semver.org/spec/v2.0.0.html).
   different limiters or the older figure is wrong, and the note cannot tell them
   apart. One API-axis figure this repo can stand behind was recorded instead: 22
   sequential `/api/v1/` calls at 2s pacing, anonymous, zero 429.
+- **The README's own surface, which had drifted behind the engine.** Four checks
+  had shipped with no row in the check table (`PIN-DEAD`, `TAG-ANNOTATED`,
+  `RELEASE-CURRENT`, `REMOTE-SYNC`), and the Requirements section still said
+  "two network calls" after the third had been added. A stale count on the
+  README of the repo whose job is presentation is the defect this gate exists to
+  find, one file over.
+
+### Not built
+
+- **`RELEASE-ASSETS` — rejected permanently, for having no subject.** No release
+  in the org carries an asset, but the deciding measurement is the other one: 0
+  of 21 READMEs mention an asset download at all. Every install path here runs
+  through `marketplace add`, `plugin install`, `pip`/`uv` or a clone, so no
+  reader is harmed and no remedy would ever be performed. The fire rate alone
+  (18 of 18) is a proxy and must not be quoted as the reason.
+- **`TAG-SIGNED` — blocked on an operator decision, which is not the same as
+  rejected.** No repo signs its tags today. If the operator decides this org
+  signs them, the check acquires its entire subject the same day; a rejection is
+  permanent, and this is one yes/no away.
 
 ## [0.9.0] — 2026-08-09