docs(check-cross-repo-closer-outcome): repair two evidence citations, and stop hand-counting the battery

[os-zhuang]

Fixes: #9917

Two evidence citations in the cross-repo-closer harness were wrong or stale. Both are comments. No behaviour, no assertion, no scenario and no mutation changes — the extracted subject is byte-identical, which the check reports itself (19729-char script, same as on origin/main).

1. A pull request was cited as the closed-ISSUE example

scripts/check-cross-repo-closer-outcome.mjs carried, at two sites, the claim that objectstack-ai/objectui#4478 is a closed issue answering state_reason: null. That number is a pull request, and it answers nullbecause it is one — so the file offered a single observation as evidence for two opposite scenarios: L9 ("a closed issue really does answer null") and L13, which exists to pin that a merged pull request answering state: 'closed' / state_reason: null is refused before the already-closed branch.

Repaired by taking the contract option rather than re-sampling:

• L9's fixture comment now states the null is modelled from the endpoint's contract and cites no object at all, and records why — the objects that most dependably answer state: 'closed' with state_reason: nullare pull requests, so hunting a specimen for this fixture walks into L13's subject. It ends with an instruction not to "improve" it by finding a real issue to name.
• makeDoubles' issues.get default (the same citation, second site) likewise models the null from the contract.
• L13's cross-reference is sharpened from "the very fixture L9 uses" to "the very fixture SHAPE L9 uses — the shape, not the observation", so the two scenarios visibly rest on separate footings while the shared shape stays what makes L13 the ordering test.

This was chosen over sampling a real closed issue deliberately: a sampled citation goes stale the moment the sampled object changes, and this one already had. objectstack-ai/objectui is out of this session's repo scope and the repair does not depend on re-measuring #4478 — the number now appears only as the withdrawn claim, labelled a pull request, so the next reader cannot reinstate it by accident.

L13's own citation was checked and holds: objectstack-ai/objectstack#9143 is a pull request in this repo, state: closed, closed_at 2026-08-16T14:56:58Z — the exact merged_at its fixture pins. It is left as the only cited object in the pair.

2. Both hand-counts in lint.yml's step comment were wrong

The Cross-repo closer outcome contract step claimed "Ten scenarios" and "seven ways". Measured 2026-08-20 from the check's own output: eighteen scenarios and fifteen mutations.

Rather than refreshing 18/15 into the comment — which repairs today's instance of a defect whose class is "these numbers are hand-maintained" — both counts are replaced by the mutation classes, the shape the objectui port chose: a verdict downgraded, the loop's bookkeeping deleted, isolation abandoned mid-loop, the target parse narrowed, a guard removed, idempotency eroded. Prose classes survive an M16; a count does not. The totals now live only where they are computed — ${SCENARIOS.length} on the OK line and ${MUTATIONS.length} on the --self-test line — and the comment says so, pointing readers at --list.

The one number kept is a dated historical statement of the drift itself ("measured 2026-08-20 ... eighteen and fifteen against a comment claiming ten and seven"), which cannot rot for the same reason the 52/105 records below cannot.

Bounded in-place fix, declared

The same stale enumeration sits in this script's own header (--self-test mutates "the extracted source -- drop the setFailed, ... stop recording which half was lost", naming ten of the fifteen and reading as exhaustive). Same defect class, same file, same gate family, mechanical, no new verification surface — repaired the same way rather than left to contradict the comment one file over. No new file enters the diff.

Deliberately NOT touched

• :71 / :276all 52 assertions stayed green and :416all 105 assertions stayed green — historical records of the cross-repo-issue-closer.yml: an already-closed foreign issue is skipped whole, so it never gets the backlink the workflow exists to leave #9643 and The repo's two closing-keyword parsers disagree about Fixes: — duplicate-fix-guard accepts the colon, cross-repo-issue-closer silently does not #9755 incidents, each already tense-anchored to the change it was measured on ("adding listComments …", "adding :? …"). Refreshing them would falsify the record that justifies the unstubbed-API guard. Verified untouched: git diff matches nothing on those lines.
• The shipped cross-repo-issue-closer.yml — the subject under test, unchanged.

Verification at ec095fb99

Gate families derived from the real changeset, node scripts/pm/dispatch-gates.mjs with no paths passed (it reads the merge base itself): 12 families, all run. Exit codes captured before any pipe.

gate	verdict line
check-cross-repo-closer-outcome.mjs --self-test	✓ 81 assertions, 15 mutations of the shipped script each driven to red.
check-cross-repo-closer-outcome.mjs	OK (107 assertions over 18 scenarios, driving the 19729-char script …)
check-closing-keyword-parity.mjs	OK (3 parsers agree on all 9 keywords and both measured separators …)
check-nul-bytes.mjs	OK (scanned 6124 text file(s) … no raw ASCII control bytes)
check:cross-package-test-inputs	OK: 12 package(s) read outside themselves, all declared …
check:node-version	green
check:required-contexts	green
check:shard-attestation	✓ 2 aggregate gate(s) count 3 declared leg(s) …
check:workflow-status-functions	OK (scanned 26 workflow file(s), 45 job(s) …)
check:type-check-coverage	OK — 64/77 workspace packages type-checked …
eslint scripts/check-cross-repo-closer-outcome.mjs	clean

Every number written into a comment by this PR came from running the thing, not from counting entries. Counting by hand is what produced the defect: grep -c "id: 'L" yields 13 for a population of 18 (the array also holds P0 P1 N1 N2 N3), and reading the highest mutation id is wrong by construction — M15 sits between M5 and M6, and M7 is last. Both traps were reproduced here before writing anything.

One declared narrowing:check:type-check-debt was not run to completion. It refuses to run without a built workspace closure and says so loudly (--re-measure cannot run: 55 workspace dependenc(ies) … have no built type entry point on disk, remedy named in its own error). That is an environment precondition, not a verdict on this diff, which contains zero TypeScript; its sibling check:type-check-coverage is green at this HEAD. CI runs it with the closure built.

skip-changeset: the diff is scripts/** + .github/workflows/**, which publish nothing. Re-derived at diff time — no published file entered the diff.

Fence check: neither file is on the governed surface, and .github/workflows/lint.yml is outside epic #9465's declared territory (.changeset/**, changeset scripts, cut-rc.yml, release.yml, pr-automation.yml changeset steps, root package.json). PR #10429's new block-comment rule does not reach these edits — they are // line comments and # YAML comments, not block-comment spans; eslint is clean regardless.

---

Generated by Claude Code

[os-zhuang]

CI triage (PM):Lint & Repo Gates is red here for a reason that is not this PR's, and I am deliberately not pushing anything at it.

✗ check-query-options-erasure-ratchet: 1 parse failure(s) inside the population this gate measures:
• packages/spec/src/migrations/registry.ts:0:0 — Parsing error: Maximum call stack size exceeded

This PR's diff is .github/workflows/lint.yml and scripts/check-cross-repo-closer-outcome.mjs — comments only, in neither case a file that can influence how packages/spec/src/migrations/registry.ts parses. The gate is behaving correctly: it refuses to report a count it did not measure.

Root cause is filed and now dispatched as #10449 — the ratchets run ESLint in-process (import { ESLint } from 'eslint') and so never get the --stack-size=4000 headroom that package.json:31 gives pnpm lint. Intermittent at ~25–35% per run (#10451), so this will likely go green on a re-run — which is exactly why it has been washing out of the record all day rather than getting fixed.

Test Core (1/6) was red on the same head for a second unrelated environmental defect — the sdui port-contention issue, BUSY_HELD=no on port 5180 — which is #10370, also now dispatched.

⇒ Both blockers are in flight. Holding this PR as-is; nothing about the two comment edits needs changing. Will re-check once #10449 lands.

---

Generated by Claude Code