Check text that follows a closing comment in the product-name guard (#1168)

[akshit-khandelwal47]

Part of #1168

Summary

The optional P3 from the review of #1190 ((c2) of #1168), as promised there.

Measured, from that review: the product-name guard (scripts/frontend-product-name.test.mjs) skipped the whole line on which a multi-line comment closes. A line starting with {/* that closes its comment and then shows text was skipped as well. So a bare "Bridge" after */ passed. The reviewer appended <span>Bridge</span> after the */ closing the comment at main.tsx:1651, and the guard still passed.

The change:

• The scan is now a function, bareBridges(text). For each line it keeps only the text outside comments, and reports a bare "Bridge" there as { line, text }.
  • Comments it skips: a line starting with // (or * , inside a doc block), and every /* … */ span, whether it opens and closes on one line or across several.
  • What is checked: whatever follows a */ on the same line.
• The file-level test asserts bareBridges finds nothing in the 14 files, and names each finding as file:line: text.
• A new test, text after a comment closes is checked, and text inside one is not, pins:
  • both of the reviewer's cases: text after a multi-line comment's close, and a {/* x */} line that then shows text;
  • that //, * and ComplyEaze Bridge lines pass;
  • that a plain <p>Bridge</p> is found.

One limit: a /* inside a string literal would hide what follows it on that line. None of the 14 files has a /* that does not open a comment (checked line by line).

Test

At 92c123f8 (the code commit), with master merged in after #1190.

node --test scripts/frontend-product-name.test.mjs                # 2 tests, 2 passed
node scripts/check-surface-ack.mjs --mode pull_request --pr 1203 --base origin/master   # touched pinned files (none); surface ack check ok

The guard passes on all 14 files, so no displayed text was hiding behind a closing comment.

P4

1. What existing component could do this? The guard itself; its loop becomes a function that a test can call directly.
2. What is deleted? The rule that skipped a whole line when it started a comment or closed a multi-line one.
3. What breaks if this is not built? A bare "Bridge" written after a comment closes passes the guard (shown above).

Net LOC

From git diff --numstat against master e506d219: +54 / −17 in scripts/frontend-product-name.test.mjs, so net +37. All test code. The file is not pinned, so there is no ack.

Mutants

Each was applied to a saved copy, run with the guard file, and restored. All were killed.

#	Mutant	Killed by
K1	the closing line skipped again (break after */ instead of scanning on)	text after a comment closes is checked, and text inside one is not
K2	a mid-line /* ends the line's scan, so a one-line {/* x */} hides what follows	the same
K3	the reviewer's case in the product: <span>Bridge</span> appended after the */ at main.tsx:1651	the front end's displayed text names the product in full, which now names src/main.tsx:1651

Not measured

• Comment syntax beyond //, /* */ and {/* */}, such as a /* inside a string or a template literal. See the limit above.

Needs a lab run: none

This changes a test file only.

Migration, security and rollback

• Migration: none.
• Security: none.
• Rollback: revert the PR's commits.

Review checklist

review-checklist.md line 10: Errors are actionable without exposing sensitive values.

🤖 Generated with Claude Code

[lamemustafa]

Independent review (local, Opus) of b399978

Verdict: no P1/P2; 2 optional P3. Test only; no pinned path. Reviewed clean at b399978. Mark it ready and I'll queue that same head.

1. It closes the gap. bareBridges now drops only the commented spans of a line and checks what follows a */. My probe case from Name ComplyEaze Bridge in full in the shell, closing and posting screens (#1168, c2) #1190, text after a multi-line comment closes, is pinned by the new test. So is a {/* x */} line that then shows text. The 14 product files still pass.
2. Mutants. I ran these on a copy of the head with Node 24; the head gives 2/0.
   • K1: the closing line is skipped again (break after */). Killed, 1/1.
   • K2: a mid-line /* ends the line's scan. Killed, 1/1.
   • Mine: going back to skipping any line that starts with * (the old rule), instead of * . It survives, 2/0. No test has a line starting with * but no space, so the narrower rule is unpinned. Optional; add a case such as "*Bridge", if the narrowing is meant.
3. Optional P3: the comment above SOURCES still describes the old rule: "a line starting with a comment marker, or any line inside a block comment that spans several lines". The function's own doc comment is accurate; the file header should match it.
4. Scope. +54/−17 in one unpinned test file. The head merges master e506d219.

[akshit-khandelwal47]

Thank you for the review of b399978, and for the extra mutant.

1, 2 (K1, K2) and 4. Gap closed, mutants and scope: nothing to change. This head stays b399978. I'll mark it ready when its CI is green.

Optional P3s: both taken, in one small follow-up after this merges, so the head you reviewed is the one queued:

• (2) The narrowing to * is meant. A doc-comment continuation line has a space after its *, while a line like *Bridge is not a comment and should be checked. The follow-up adds that case (bareBridges("*Bridge") finds it), so your mutant, back to any leading *, fails.
• (3) The header comment above SOURCES will describe the rule as the function does: commented spans are dropped, and what follows a */ on the same line is checked.

Open: the two P3s, in one follow-up after this merges.

[akshit-khandelwal47]

Ready for review at b399978

[lamemustafa]

Four of your PRs are now open and marked ready (#1188, #1191, #1200 and this one), one above the cap of three. All four are reviewed at their current heads and armed for the queue, so none is waiting for a review. Please open or mark nothing new ready until at least one of them has merged.

[lamemustafa]

Queued at b399978 (the reviewed head): it enters the merge queue as soon as this head's pull-request checks finish green. Please push nothing more here. If it leaves the queue, I'll say why here.

[akshit-khandelwal47]

Understood, and sorry for going over: I counted only PRs still waiting for review, not every open one. From now on the cap counts every open PR of mine, reviewed or not. I'll open nothing new until at most two are open, so the next one makes three. Two small follow-ups are built locally and will wait: #1188's doc comment and #1203's P3s.

[lamemustafa]

Thank you, and a correction to my earlier note: the rule as written (step 2) is at most 3 PRs waiting for review, and you counted it right. A PR that has been reviewed at its current head and is armed for the queue is not waiting for review, so it does not count. My "one over the cap" was wrong, and you do not need to count every open PR.

What the cap does ask: do not have more than 3 PRs awaiting a first or delta review at once, and a PR with unanswered review points counts as waiting. Keep the follow-ups you built locally until their predecessors merge, as you planned.

[akshit-khandelwal47]

Follow-up: both optional P3s (the *Bridge case and the header comment) are in #1206.