Nothing runs `check-half-states.mjs --self-test` in this repo — add one step to the build job

[os-zhuang]

Filed by the repo:objectos seat (objectstack#9831) at the ACCEPT of PR #237 (#165), answering an open question that PR's dev raised and correctly declined to act on. Graded pm:queue and adjudicated — the option is chosen, so this is transcription, not a design question.

The gap, confirmed empirically rather than by reading

PR #237 landed scripts/pm/check-half-states.mjs, which declares --self-test and carries 1551 cases. Nothing in this repo runs them.

The self-test registry is tools/ci-scripts/run-self-tests.mjs. It sets const SCRIPTS = join(ROOT, '.github/scripts') and scans that directory top level only (readdirSync without recursive, plus an isFile() filter). A script at scripts/pm/ is outside it by construction.

Proven by running it, not by inspection: after #237 landed, pnpm turbo run test still prints ✓ 4 self-test(s) passed — not 5.

This cuts both ways, and both halves matter:

• Good: ci: install the parameterised half-state patrol from objectstack #237 does not trip this repo's rule that a .github/scripts/*.mjs declaring an unregistered --self-test reddens the required build job.
• Bad: Install the parameterised half-state patrol (sweeper + workflow pair from objectstack PR #11294) #165's own executable acceptance criterion — --self-test green — is enforced by nothing from now on.

Direction, adjudicated — option B. Do not re-open it

Add a single step to the existing build job: node scripts/pm/check-half-states.mjs --self-test. One line, about a second, touching no registry and no scan surface.

The two rejected options and why, so nobody re-litigates:

• ⛔ Not "teach the registry about scripts/pm/." The registry's top-level-only scan is load-bearing — it is what lets .github/scripts/lib/ exist without tripping the unregistered-self-test rule. Widening the scan surface is a change to this repo's gate topology and is not worth taking on for one script.
• ⛔ Not "leave it unenforced." The argument for leaving it is real — the file is authored upstream under a single-writer rule, objectstack runs the 1551 cases on every change there, and this copy is byte-identical by policy. But that depends on the copy staying byte-identical, and nothing here checks that either. The two silences compound: a hand-edit to this copy would be caught by no gate in either repo.

Why B buys more than it looks like

PR #237's own ablation is the evidence. Mutating DEFAULT_SWEEP_REPO in the copy turned the self-test red (2 of 1551 cases). So running these cases here is a drift detector for the class of edits that change behaviour — not a complete hash-pin, but it collapses the compounding silence above into one much narrower gap.

Scope

One step in .github/workflows/ci.yml's existing build job. ⛔ Do not touch tools/ci-scripts/run-self-tests.mjs. ⛔ Do not touch the three files #237 landed — they are verbatim upstream copies and their blob OIDs must keep matching objectstack origin/main.

Explicitly out of scope: the hash-pin

A true drift check — asserting this copy still matches upstream byte for byte — would require objectos CI to read objectstack's tree, which is a cross-repo credential question. That is a design decision deserving its own card, not a rider on this one. Not filed yet; file it if the drift half turns out to matter in practice.

Verification

The step should be demonstrated to actually run: after the change, the build job's log must show the self-test's own verdict line (✓ check-half-states self-test: 1551 cases pass.). A green build alone does not prove the step executed — quote the line.

Re-check

git show origin/main:.github/workflows/ci.yml | grep -n 'check-half-states'
pnpm turbo run test --force   # does it still say 4 self-test(s), or 5?

Related: #165 (the install), PR #237 (where the gap was measured and the ablation run), #242 (the maintainer's anchor-variable step).