fix(ci): published-README call sites assert the leading boundary instead of consuming it

[os-project-manager]

Fixes#9610

⚠️Reading note. A negative-lookbehind literal cannot be carried in a GitHub body: the ! in (? + less-than + ! + [ is deleted in storage (measured in #9621, with controls both ways). So wherever the real source has those two characters, this body writes NLB. The genuine line is in the diff.

The defect, re-measured before fixing

extractMemberCalls found Name.member( with a leading alternation whose non-^ arm consumes a character. The regex is global, so a receiver starting at the very next character after a previous match had no boundary left to match against. A match always ends at its own ( — which makes the swallowed position exactly outer(Inner.m(.

Re-measured on the published regex, receiver set {CacheServicePlugin}:

await kernel.use(CacheServicePlugin.configure({ a: 1 }));
all: ["kernel.use"] kept: [] MISSED
await kernel.use( CacheServicePlugin.configure({ a: 1 }));
all: ["kernel.use","CacheServicePlugin.configure"] kept: ["CacheServicePlugin.configure"] caught

And end to end on the built tree, service-cache's README given the genuine CacheServicePlugin with a fabricated static, one space apart:

README line	pre-fix	post-fix
await kernel.use(CacheServicePlugin.configure({...}))	exit 0, green	exit 1, line 299: documents CacheServicePlugin.configure(...)
await kernel.use( CacheServicePlugin.configure({...}))	exit 1	exit 1, same finding, same key

That nested position is not a corner — kernel.use(new SomePlugin({...})) is the house spelling of every README this gate polices, so the blind spot sat in the gate's most important position, and on the likeliest wrong rewrite of any of those pages.

The fix

A negative lookbehind: the boundary is asserted zero-width, nothing is consumed, and the ^ arm folds in because a negative lookbehind is satisfied at position 0.

// NLB stands for the two characters this body cannot carry; see the reading note.constrx=/(?NLB[\w$.'"`])([A-Za-z_$][\w$]*)\s*\.\s*([A-Za-z_$][\w$]*)\s*\(/g;

The character class is byte-for-byte the old one, so the fence is unchanged. Group indices shift 2/3 to 1/2 with the capture gone.

The card's proposal is sound — the missing ! is a platform artifact, not an authoring error

The regex literal in #9610's "Suggested fix" reads back without its !, which is a SyntaxError — V8 reads a less-than right after (? as the opener of a named group. I did not file that as a defect in the card:

• The card's prose names "a negative lookbehind" and reasons from the property only the negative form has ("satisfied at position 0"), so the author wrote the !.
• The same deletion then hit this PR. My first body revision carried the real literal in three places; all three came back with the ! gone.
• Probed with controls in A negative-lookbehind literal cannot be carried in an issue/PR body — the ! is deleted from (? + less-than + ! + [, and AGENTS.md's sanitizer clause names only less-than plus a letter #9621: A less-than !Bkeeps its !, while (? less-than [\w$])loses it. The destructive shape is the markup-declaration opener — less-than, !, [ — which is exactly how a negative lookbehind over a character class is written.

⇒ Nothing in the card needs changing. Filed as #9621, because AGENTS.md's sanitizer clause names only a less-than followed by a letter and so does not cover this, and because the same read path truncated a body at a doctype token (#9557's family).

--self-test, in the same edit

The hole survived a gate written with self-tests in both directions because every existing fixture placed the wanted receiver where no earlier match on the line had consumed anything in front of it. Three cases added:

• extractMemberCalls — a receiver directly inside a discarded call is still read — fixture is await kernel.use(CacheServicePlugin.configure({...})), receiver adjacent to a discarded kernel.use( match with no separating character.
• analyzeDocument — a fabricated static nested inside another call is reported — the same shape end to end.
• extractMemberCalls — the nested position does not widen the fence — the other direction in that same position: wrapper.CacheServicePlugin.configure(, all three quote styles, and the correct new CacheServicePlugin( spelling all stay silent.

Reverse verification

Fix committed first, then the boundary reverted to the consuming form with the new fixtures left in place:

✗ check:published-readme-exports --self-test — 2 failure(s)
extractMemberCalls — a receiver directly inside a discarded call is still read
expected ["CacheServicePlugin.configure"]
actual []
analyzeDocument — a fabricated static nested inside another call is reported
expected ["...|member|@objectstack/kernel|Kernel.configure"]
actual []

Restored from the committed branch state; git status clean afterwards. Honest note on direction: the third case is green under both regexes by design — it is a fence-preservation pin (it reddens if someone widens the character class), not a regression detector for this change.

No drift in what is detected

The fix changes zero known instances. Same numbers before and after, on the same built tree:

✓ check:published-readme-exports — 60 published document(s) across 77 workspace package(s);
166 import statement(s), 47 workspace type entr(ies).
16 known instance(s) still in scripts/published-readme-exports.baseline.json;
2 of the findings are call sites.

Cross-check against PR #9602 (not yet merged; this does not address it)

PR #9602 rewrites the five service READMEs and shrinks the baseline 16 to 10. Its head content was overlaid onto this branch and measured both ways:

gate	over #9602's READMEs + baseline
this branch's fixed gate	green, 10 known instances, 2 call sites
origin/main's pre-fix gate	green, 10 known instances, 2 call sites

⇒ The fix newly detects nothing in #9602's rewritten content, and the numbers match #9602's own reported result exactly. No finding about that PR, and no baseline interaction in either landing order.

Gates

The gate union derived by node scripts/pm/dispatch-gates.mjs from git diff --name-only $(git merge-base origin/main HEAD) (one changed path, scripts/check-published-readme-exports.mjs) is check:published-readme-exports; check:nul-bytes and eslint added for any-edit coverage. All run at a87e7f0bd, the final commit, with the working tree clean against it — all exit 0:

• pnpm check:published-readme-exports (self-test + full scan) — exit 0
• pnpm check:nul-bytes (self-test + scan of 6171 files) — exit 0
• npx eslint scripts/check-published-readme-exports.mjs --no-inline-config — exit 0

The full workspace was built first (turbo run build, 71 tasks, 71 successful): this gate hard-errors on a missing type entry rather than skipping, so on an unbuilt tree it refuses and measures nothing — a refusal is not a pass.

No changeset

Repo tooling only — scripts/ ships in no package's files array, so nothing user-visible changes. skip-changeset applied as a label.

---

Generated by Claude Code