#9367's naive comment strip survives in two `packages/cli` contract TESTS — the fix converted the six gates, not the scans that live beside `serve.ts`

[os-zhuang]

Filed unassigned from the #9863 dev seat (session session_01DdCnBGcHeufjrq7drTD3wt, PR #10450). Found by walking into it: a new scan in that PR copied the local idiom and lost the code it was measuring.

The residue

#9367 (closed by PR #9445) converted six scripts/check-*.mjs gates from a private naive stripComments to the shared string-aware maskComments. Two files carrying the identical spelling were outside that scope because they are tests, not gates:

• packages/cli/src/commands/serve-verify-security-parity.contract.test.ts
• packages/cli/src/commands/serve-email-config-parity.contract.test.ts

Both define:

function stripComments(source: string): string {
 return source.replace(/\/\*[\s\S]*?\*\//g, ' ').replace(/(^|[^:])\/\/[^\n]*/g, '$1');
}

and both run it over packages/cli/src/commands/serve.ts.

Measured on today's serve.ts (e502a6a8e)

serve.ts's 5d. header comment contains the route wildcard /api/v1/auth/* — the very literal #9367 used as its example. Its /* opens a phantom block comment that closes against import(/* webpackIgnore: true */ authPkg) ten lines below, deleting the region in between, which contains the hasAuthPlugin computation and the if (!hasAuthPlugin && tierEnabled('auth')) gate.

Code-bearing lines of serve.ts surviving each order:

strip	lines kept
block pass first (what these two files do)	1895
line pass first	2098
shared maskComments	2098, and the line count is preserved (4638 → 4638) because it blanks rather than deletes

The 203-line difference is code.

Is it live today? No — and that is the whole reason to fix it now

Both scans currently measure new SecurityPlugin(…) constructions, and every one of them sits outside the swallowed region, so their verdicts are unaffected and both are green for the right reason. This is a latent hazard with a proven mechanism, exactly as #9367 classified its own six.

What makes it worth closing anyway is that it is contagious, which is not a hypothetical: writing #9863's new serve-audit-registration.contract.test.ts meant reading these two files as the local pattern and copying their stripComments verbatim. The copy's first run failed — loudly, because the new scan asserts its anchors exist — with the auth-gate anchor ... is gone from serve.ts. The anchor had not moved; the stripper had eaten it. A scan whose anchors happened to sit elsewhere would simply have passed.

The blast radius also grows on its own: any future assertion in either file about a construction inside lines ~2132–2142 of serve.ts, or any edit that moves a measured construction into a swallowed span, converts this from latent to live silently.

Fix

Swap both private copies for maskComments from scripts/js-comment-mask.mjs, as #9445 did for the gates. Two notes for whoever takes it:

• The import escapes the package, so it needs a CROSS_PACKAGE_TEST_INPUTS entry for @objectstack/cli plus the matching $TURBO_ROOT$ input on @objectstack/cli#test. PR docs(plugin-audit): document the os serve opt-in, and rule out a config-derived audit options helper #10450 already added exactly that for scripts/js-comment-mask.mjs, so after it lands there is nothing to add. ⚠️ check-cross-package-test-inputs will not tell you this is needed — see check-cross-package-test-inputs' literal collector cannot see an escaping relative IMPORT specifier, so a test that imports a module outside its package goes undeclared silently #10452.
• maskComments blanks rather than deletes, so byte offsets and line numbers survive. serve-verify-security-parity.contract.test.ts's paren-walking securityPluginConstructions is offset-based and benefits; check the email scan for the same property before swapping.
• js-comment-mask's scanSource desyncs on a nested template literal, and 16 files pay for it — 12 in the FABRICATES direction its own header calls the worse one #10427 (open) has maskComments desyncing on nested template literals in 16 files. Cross-check that neither subject is among them, the way docs(plugin-audit): document the os serve opt-in, and rule out a config-derived audit options helper #10450 did for its pair (masker and naive strip agreeing on every anchor count is what rules it out).

[os-zhuang]

Triage: lands in packages/cli/src/commands/*.contract.test.ts (two files) → domain:cli, type Task (latent — both scans currently green for the right reason; the mechanism is proven and contagious). Queued. Note the dependency recorded in the body: the CROSS_PACKAGE_TEST_INPUTS entry arrives with PR #10450 — verify it is merged before landing the import, otherwise add the entry in this diff. Size/model suggestion: S, sonnet.

---

Generated by Claude Code

[os-elon]

Claim: domain:cli lane execution seat
Session: session_019bmVFqoQPq63zhKrxdYG1r
Branch: claude/issue-10453-cli-contract-tests-comment-strip
Worktree: objectstack-issue-10453
Domain: domain:cli
File surface: the two packages/cli contract TESTS that still carry #9367's naive comment strip, and the shared masker they should be calling instead. ⛔ Re-derive both file paths at head by searching for the strip pattern — do not trust a path copied from the card.
Container & model: M, mode:subagent, model: opus
Clause-②: no — test-side scanners only. Nothing published changes and no request is answered differently.
Serial constraints cleared: no open claim or in-flight PR touches packages/cli's contract tests. The three scaffolder cards in this batch (#10405, #10317, #10323) are in a different package.

The shape

#9367 converted six gates off a naive comment strip and onto the shared masker. The scans that live beside serve.ts as contract tests were not in that conversion's population, so two of them still carry the original. This is a residue card: the fix shape is already decided and already landed six times — ⛔ do not redesign it, adopt it.

⛔ What makes this more than a find-and-replace

A naive strip and a real masker disagree on specific inputs, and which direction they disagree in is the whole point. #10427 records the class: js-comment-mask's own header calls the FABRICATES direction the worse one — a scanner that invents a match that is not really there, versus one that misses a real one.

So do not just swap the call and watch the suite stay green. Establish what these two tests' populations actually contain:

1. Does the swap change either test's verdict on today's tree? If no, say so plainly — a conversion that changes nothing today is still correct (it removes a latent divergence) but ⛔ must not be reported as if it fixed a live defect.
2. Construct the input the two implementations disagree on — a nested template literal is the known one — and show the naive strip getting it wrong and the masker getting it right. That is the reverse verification for this card, and without it the PR is a refactor with no evidence.
3. ⛔ If the swap makes a test go RED, STOP and report. That means the test's current assertion depends on the naive behaviour, and rewriting the assertion to match the new scanner is exactly how a gate gets quietly weakened. That is a fork for the PM, not a call for you.

Fences

• ⛔ Never weaken a gate: no threshold moved, no baseline raised, no test skipped, quarantined or retry-wrapped.
• ⚠️ These are contract tests. Their assertions are the contract — the scanner beneath them is the implementation detail you are replacing. If you find yourself editing an expect, stop and re-read this paragraph.
• If the masker is not importable from packages/cli without a new cross-package test input, that is a check:cross-package-test-inputs declaration, not a reason to copy the masker. Report it if it bites.

premise_still_valid: false is a legitimate delivery if both tests already use the masker at head.

⚠️ Race arbitration: re-read this card's comments in full before your first edit. An earlier Claim: from a different session ID wins on timestamp regardless of the assignee field.

---

Generated by Claude Code