Skip to content

test(gates): give the two document-count pins an in-file positive control (objectui#7914) - #7943

Merged
os-sam merged 1 commit into
mainfrom
claude/issue-7914-count-pin-in-file-controls
Sep 6, 2026
Merged

test(gates): give the two document-count pins an in-file positive control (objectui#7914)#7943
os-sam merged 1 commit into
mainfrom
claude/issue-7914-count-pin-in-file-controls

Conversation

@claude

@claude claude Bot commented Sep 6, 2026

Copy link
Copy Markdown
Contributor

Fixes #7914

Clause-②: no — the fixtures live inside the two test files. No schema accept/reject behaviour moves, and no gate's scanned population moves: nothing here is a new scan surface.

The defect, reproduced

Both count pins read a workflow header that carries no document count today, so each asserted [] toEqual [] exactly once. They passed — and they would have passed identically with the pattern deleted, reversed, or narrowed back to adjacency. That is why objectui#7888 had to demonstrate its own widening out of band, in a pull request description this repository does not hold.

This is not inferred. In every ablation below the two pins (its header states the population and never counts it) stayed green while the pattern was broken underneath them. Only the two new controls went red.

The shape carried, not invented

scripts/__tests__/check-links-workflow.test.ts — the third copy — already carries this control: a rotted array asserted not.toEqual([]) and a legitimate array asserted toEqual([]). That block is carried onto both twins verbatim in structure, naming and assertion wording. That file is not touched; neither is any workflow header, nor either gate script.

The pattern is lifted to module scope (POPULATION_COUNT + documentCounts, the third copy's names) so each pin and its control read one definition rather than two free to drift. Its source is unchanged character for character:

$ grep -h -o THE_PATTERN_LITERAL THREE_TEST_FILES | sort | uniq -c
      3 /(?NOTBEHIND[#\w.])\d+(?:,\d{3})*\s+(?:[A-Za-z][\w-]*\s+){0,2}`?(?:\.mdx|\.md|documents?|pages?|docs?|files?)\b/

One distinct pattern across all three copies, before and after.

NOTBEHIND above stands in for the two characters that open a negative lookbehind. They are spelled as a placeholder on purpose: GitHub's body sanitizer strips that byte pair even inside a fenced code block, so writing the literal here would have published a different regex than the one in the files — which this pull request read back and caught after its first publish. Read the real literal in the source; it is byte-identical in all three copies.

Every control proves it can fail — three directions, both files

Each direction mutates the pattern in both test files at once, proves the mutation landed on disk (anchor count 1 to 0, injected marker present, non-empty git diff --stat), runs vitest from the repo root, then restores. Exit codes captured by redirect-then-read, never through a pipe.

direction mutation EXIT failures which tests
adjacency delete (?:[A-Za-z][\w-]*\s+){0,2} — the objectui#7888 regression 1 2 failed, 80 passed both new controls; both pins green
lookbehind delete the negative lookbehind (NOTBEHIND above) — the false-positive direction 1 2 failed, 80 passed both new controls; both pins green
neuter replace the noun set with one that matches nothing 1 2 failed, 80 passed both new controls; both pins green

Each failure names the pin and the surface it reads, not merely expected [] to deeply equal [...]:

adjacency:
  AssertionError: doc-fence-languages.yml's count pin must fire on: every TypeScript block in
    227 covered documents is fenced ts/tsx/typescript: expected [] to not deeply equal []
  AssertionError: doc-component-types.yml's count pin must fire on: the repo-root `docs/**`,
    which holds 15 INTERNAL documents (ADRs, audits), while: expected [] to not deeply equal []

lookbehind:
  AssertionError: doc-fence-languages.yml's count pin must NOT fire on: #7448 documents the
    rule this gate enforces: expected [ '7448 documents' ] to deeply equal []
  AssertionError: doc-component-types.yml's count pin must NOT fire on: #7448 documents the
    rule this gate enforces: expected [ '7448 documents' ] to deeply equal []

neuter:
  AssertionError: doc-fence-languages.yml's count pin must fire on: the same 222 documents
    `check-doc-snippet-types` covers: expected [] to not deeply equal []

The lookbehind figure [ '7448 documents' ] is the exact false positive objectui#7914 reported, reproduced here rather than quoted. Measured against the pre-objectui#7888 pattern recovered from 797b39f68^:

["7448 documents"] <- #7448 documents the rule this gate enforces
[]                 <- the repo-root `docs/**`, which holds 15 INTERNAL documents (ADRs, audits), while

Both halves of objectui#7888's finding, in one reading: the old pattern invented a count from an issue reference, and missed a real one behind a single adjective.

Restores, proven by state — never by an exit code

Restore is git checkout HEAD -- ABSOLUTE_PATH (never a bare git checkout -- PATH, which reads the index the first checkout just wrote), driven from a trap ... EXIT INT TERM with REPO_ROOT resolved absolutely before any mutation. After each of the three directions:

check-doc-fence-languages.test.ts:  HEAD blob 19f6f316a10368e787d80d499e3a16645dcfd7c6 == on-disk 19f6f316a10368e787d80d499e3a16645dcfd7c6  [MATCH]
check-doc-component-types.test.ts:  HEAD blob 0c204e823f2bb34092efaa500508ebdaa97d6b5b == on-disk 0c204e823f2bb34092efaa500508ebdaa97d6b5b  [MATCH]
git diff HEAD: empty

Identical blob hashes after all three, and git status --porcelain empty at the end.

The direction that matters most: a number that is CORRECT TODAY

A control that only rejects stale figures waves the same trap through on the day the figure happens to be right — which is the day it starts rotting. Both gates were run to get their live verdict lines, and those live numbers are fixtured as rotted:

check:doc-fences  EXIT=0  ->  every TypeScript block in 227 document(s) is fenced ts/tsx/typescript
check:doc-types   EXIT=0  ->  Scanned 188 doc file(s) (.mdx + .md), 1105 code block(s), ...

Applying the pattern read back out of the committed file:

REJECTED ["227 covered documents"] <- every TypeScript block in 227 covered documents is fenced ts/tsx/typescript
REJECTED ["227 documents"]         <- the same 227 documents `check-doc-snippet-types` covers
REJECTED ["188 doc file"]          <- Scanned 188 doc file(s) (.mdx + .md)

227 and 188 are exactly right today and are rejected anyway. The rule governs the writing, not one wrong number. The adjacency ablation lands its fence-side failure on this very fixture, so the claim is enforced, not merely stated.

Readings — all at 403755fd4, the final commit

check exit reading
npx vitest run scripts/__tests__ 0 RUN v4.1.10 /home/user/objectui-issue-7914107 test files, 3222 tests passed, 180.73s
tsc -p tsconfig.scripts.json --listFiles 0 no errors; both edited files confirmed present in the program (2 hits), so this is a measurement and not an empty one
pnpm lint:root 0 32 problems, 0 errors; neither edited file appears in the output. Full sweep, not a narrowing
pnpm lint:coverage 0 46/46 packages linted, 0 with outstanding errors
pnpm type-check:coverage 0 45/46 via type-check, 0 known-broken; 42/42 packages compile their tests
pnpm check:control-bytes 0 scanned 6407 tracked text file(s); skipped 85 binary
pnpm check:vi-mock-specifiers 0 4336 tracked source file(s), 2613 test-named
pnpm check:vi-mock-inherit 0 132 call site(s) judged (132 inherit, 0 auto-mocked)
pnpm check:shell-escape-residue 0 206 file(s) and 1309 fenced block(s) examined
pnpm check:entry-guard 0 69 scripts/ file(s) — no entry guard outside the baseline
pnpm check:doc-fences 0 227 document(s)
pnpm check:doc-types 0 Scanned 188 doc file(s)

The vitest run is from the repository rootRUN v4.1.10 /home/user/objectui-issue-7914 with 107 files, not a pnpm --filter invocation that would silently run apps/console instead (objectui#3378).

pnpm check:skill-examples returned EXIT=2 — NOT MEASURED, neither red nor green. Its own words: PRECONDITION NOT MET (exit 2) — the example program was NOT run: the packages it resolves against are not built. It is outside this diff's gate family in any case: this change adds no skills/ content, and the only link between them is a prose mention of this file's name in a comment inside check-skill-examples.test.ts, which passed as part of the 107-file run.

Changeset

node scripts/check-changeset-presence.mjs — EXIT=0, quoted verbatim rather than reasoned about:

Compared the working tree with b8e3f8379 (merge-base with origin/main): 2 file(s) changed,
0 of them published source of a package the release covers, 0 of them a manifest whose
published contract moved, 0 under a package changesets ignores, 0 changeset(s) added.
✅  No source or published contract of a released package changed in this range, so no changeset is owed.

No changeset is owed — not even an empty one.

Scope

Two files, scripts/__tests__/check-doc-fence-languages.test.ts and scripts/__tests__/check-doc-component-types.test.ts. No workflow header, no gate script, and no edit to the third copy. objectui#7901, the coverage half, is out of scope here and remains open — it was deliberately sequenced behind this card so its census is computed with an instrument that can now be shown to go red.

Worked by an os-dev agent seat, session https://claude.ai/code/session_01KbJQ1y1J12nZxYzFWhP8Q3.


Generated by Claude Code


Generated by Claude Code

…trol (objectui#7914)

Both pins read a workflow header that carries no count today, so each asserted
`[] toEqual []` exactly once. They passed, and they would have passed identically
with the pattern deleted, reversed, or narrowed back to adjacency — which is why
objectui#7888 had to demonstrate its own widening out of band, in a PR
description this repository does not hold.

Carries the third copy's control block (`check-links-workflow.test.ts`,
objectui#7825) onto both twins verbatim in structure: a `rotted` array asserted
`not.toEqual([])` and a `legitimate` array asserted `toEqual([])`. The pattern is
lifted to module scope so the pin and its control read one definition rather than
two that can drift; its source is unchanged character for character, and all
three copies still hold one identical pattern.

Fixtures include numbers that are CORRECT TODAY (the gates print 227 document(s)
and 188 doc file(s)) and are rejected anyway — the rule governs the writing, not
one wrong figure — and the measured false positive of the pre-objectui#7888
pattern, which read `#7448 documents the rule` as `["7448 documents"]`.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01KbJQ1y1J12nZxYzFWhP8Q3
@github-actions github-actions Bot added the tests label Sep 6, 2026
@os-sam
os-sam marked this pull request as ready for review September 6, 2026 04:17
@os-sam
os-sam added this pull request to the merge queue Sep 6, 2026
Merged via the queue into main with commit d39ede2 Sep 6, 2026
31 checks passed
@os-sam
os-sam deleted the claude/issue-7914-count-pin-in-file-controls branch September 6, 2026 04:33
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Projects

None yet

2 participants