Repository navigation
test(types): give the inert comment projection a subject that reddens (objectui#9768) - #9814
Merged
Merged
Conversation
… (objectui#9768) The comment projection at `overlay-node-slot-doc-types-7082`, `alert-dialog-read-dialect-7104` and `overlay-trigger-union-7081` was correct and inert: over the whole population those three readers project, the member map built with `scripts/js-comment-mask.mjs` and the map built with no projection at all are identical, so nothing would have noticed the guard being deleted, weakened, or reverted to a hand-rolled regex. Each reader now declares `CommentProjectionForcingSubject`, whose body carries a member-shaped row inside an ORDINARY block comment -- no `*` gutter, so the row sits on the two-space anchor `members()` matches -- and pins the member list it reads off that subject. The subject is read off disk and extracted the same way a declaration is, so it is a subject rather than a synthetic string handed to the reader. It is declared per file because each reader carries its own copy of `members()`. Co-Authored-By: Claude <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_015h79niBMyoB1xcaQje3uiz
Contributor
✅ Console Performance Budget
The eager closure is every chunk the entry reaches through static imports — what the browser fetches and parses before the app renders. The entry chunk on its own is a small fraction of it. 📦 Bundle Size Report
Size Limits
|
os-try-charles
marked this pull request as ready for review
September 18, 2026 07:03
os-try-charles
deleted the
claude/issue-9768-inert-comment-projection
branch
September 18, 2026 07:25
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Fixes #9768
The comment projection at the three
packages/typesreaders was correct and inert. This gives it a subject it actually defends.Population first — the card's number was not re-derived, it was re-measured
⛔ The card asserted inertness over "16 interface bodies" and I could not reproduce that figure, so I established the population mechanically rather than inheriting it. Method: instrument
stripCommentsinscripts/js-comment-mask.mjsto record every input plus its calling test file, run the three readers, restore the module fromHEADand verify the restore by blob hash, then replay each captured body through the readers' own member regex twice — once through the projection, once with no projection at all.Reading (this run, on
6a0d1a435):stripCommentscalls across the three readersmembers()The 10 declarations are the nine overlay interfaces the
7081reader enumerates plusEmptySchemainfeedback.ts; the 10 fences are their docs pages plusfeedback/empty.mdx. The projection is doing real work — it removes 11,754 bytes of prose from theAlertDialogSchemabody alone — it simply never changes the answer.Triage's escalation condition: NOT met
⭐ No real subject reads differently with and without the projection (0 of 20), so there is no live defect, the three readers get nothing wrong today, and the grade does not move to p2. The fixture stays the right deliverable.
JSDoc stripping does not eat real rowsprobe inoverlay-node-slot-doc-types-7082.test.ts. Its member-shaped line sits behind a docblock gutter (three spaces and a star) whilemembers()anchors on exactly two spaces followed by an identifier, so it passes identically with the projection removed. Before this change nothing in the tree, subject or literal, could force the guard.What this lands
Each of the three readers declares
CommentProjectionForcingSubjectand pins the member list it reads off it. The body carries a member-shaped row inside an ordinary block comment — no*gutter, so the row sits on the two-space anchor — and the pin reads the file off disk and extracts that body exactly as it extracts a declaration.tsconfig.test.jsoncovers these files, and two type-level legs per reader assert the declared rows), and the extraction path is the readers' owninterfaceBody+members.members(), so a pin living in one file cannot red for a projection dropped in another.scripts/js-comment-mask.mjsis untouched.Red before green — the ablation, both legs
The mutation is the same in both legs:
const bare = stripComments(body);becomesconst bare = body;in all three readers, proven on disk (3 markers injected, 0 surviving calls) before anything is read. Restoration isgit checkout HEAD -- ...under atrap, verified by comparing each file's blob hash with itsHEADblob and bygit diff HEADcoming back empty.6a0d1a435, the three readers as they were), projection removed:Test Files 3 passed (3),Tests 155 passed (155), exit 0. ⇒ the guard was inert.Test Files 3 failed (3),Tests 3 failed | 158 passed (161), exit 1. One failure per reader, all on the same assertion:⛔ Not a count that happened to move: the assertion that moved names the member LIST, and the subject is added rather than an existing one altered, so a grep count over the tree would read the same in both legs.
Verification
Heavy legs through the shared lock at
../objectstack/scripts/pm/os-verify-lock.sh, verdict lines quoted:pnpm --filter @object-ui/types type-check—os-verify-lock: VERDICT command-exit 0 · held the lock 33s · waited 0s(three programs:tsc --noEmit,tsconfig.examples.json,tsconfig.test.json)pnpm --filter @object-ui/types test—os-verify-lock: VERDICT command-exit 0 · held the lock 26s · waited 0s;Test Files 204 passed (204),Tests 4777 passed (4777)Tests 161 passed (161)(155 before this change)Gates, run by POPULATION rather than by name — each of these reads this diff while naming none of its paths:
check:comment-mask-corpusexit 0 —5078 files, 1 disagree (0 comment bytes read as code, 1517 code bytes read as comment), i.e. the objectui#7882 residue unchanged and inside its declared ceilingscripts/check-hand-rolled-comment-mask.mjsexit 0 —6 private comment projection(s) in 5 file(s); DEBT names 5; this diff adds no carrier and the DEBT ratchet does not move (the one regex added is a LOOKUP for the row, not a removal position)check:pending-changeset-literalsexit 0,markdown-test-inputs --auditexit 0 (102 candidate test files, all adjudicated)check:control-bytesexit 0 (7890 tracked text files),check:test-path-rootsexit 0 — the new read is rooted at the test file itself, never at the cwdcheck:new-line-citationsexit 0 (0 new citation(s)),check:changeset-claimsexit 0,check-changeset-presenceexit 0 — the empty-frontmatter changeset is the declared exemptionnode scripts/check-lint-coverage.mjsexit 0 (46/46 packages linted, 0 with outstanding errors);pnpm --filter @object-ui/types lint0 errors (the two warnings printed againstoverlay-trigger-union-7081.test.tsare pre-existingdata?: anyrows, untouched by this diff)⛔
check:node-esm-loadis not coupled to this diff: nothing under any package's publishedfiles[]moves —tsconfig.jsonexcludes**/__tests__/**from the build — so no dist artefact changes. It is named here as a deliberate omission rather than left unsaid.Acceptance notes
16 interface bodiesfigure on the card is not reproducible against the readers' actual subject lists. It is consistent with a count over one reader's docs pages plus the declarations (10 + 6), but that is a reconstruction, not a reading — I am reporting 20, measured, with the method above.🤖 Generated with Claude Code
https://claude.ai/code/session_015h79niBMyoB1xcaQje3uiz
Generated by Claude Code