You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Filed unassigned by the os-dev seat implementing #11542 (session session_015ahemw8RcTgqtxrj15PEZx). Recording, not fixing — like #11542 itself, it moves a MEASURED POPULATION, which the header of --bridge-coverage attaches a before/after standard to, and closing it moves a scan #11542's own before/after was priced to leave still. No live instance on today's tree.
What
#11542 gives the eight route: / client: lead scans in scripts/docs-audit/affected-docs.mjs one anchored spelling, in declLead, so subroute: / myclient: is no longer a declaration to seven of them and not to the eighth. The anchor it unifies on is \b, which is the spelling declarationsIn — the one scan that was already right — had.
\b asserts a boundary between a word character and a non-word character. It therefore fails only against a preceding word character ([A-Za-z0-9_]). $ is not one, and $route is a legal JS identifier:
A file declaring oneroute: produces two rows. Measured on the #11542 branch (parseLedgerSource driven through --self-test), i.e. after the anchor lands.
Why it is silent, and how this differs from #11542
Silent for the reason #10683 / #10793 / #11542 were: the partial-read verdict keys on the gap between rows and routesDeclared, and after #11542all eight scans read the same spelling, so both terms still move together and no verdict fires. outsideCode cannot see it either — the lead genuinely IS in code position.
What #11542 removed was the divergence: eight scans answering one question differently while all eight looked right. This is not that. All eight agree here, and they agree by being wrong together — which is exactly the shape #11542's issue rejected on sight as "agreed-and-wrong" when it was proposed as the other direction for the key. So it is a strictly smaller defect than #11542 was, and a real one.
--self-test on the #11542 branch pins today's behaviour as deliberately unmoved, so whoever closes this card flips an existing pin rather than finding none:
'a `$route:` still mints a phantom row — deliberately unmoved'
'and it is still SILENT — all eight scans agree on it, so both terms move together'
Tightening declLead's anchor from \b to a negative lookbehind that also excludes $ (the idiom rulePatternFor, symbolRe and dottedRe already use in this same file) moves declarationsIn too — the one scan #11542 left byte-identical on purpose. #11542's before/after was priced for eight scans converging on the spelling declarationsInalready had (269 of 269 / 222 of 222 / 45 reachable / 177 UNREACHABLE, byte-identical row for row). A tightening past \b is a second population move with its own before/after to price, against a scan the first move did not touch.
⚠️ The exact regex is deliberately NOT spelled out on this card. GitHub's body sanitizer strips the < + ! digraph out of an issue or PR body — inside a code span and inside a fenced block alike — and silently leaves a different, valid-looking regex behind; the first version of this issue carried that corrupted form in two places. Read the verbatim spelling from declLead's docblock and the --self-test boundary comment in scripts/docs-audit/affected-docs.mjs, which the sanitizer cannot reach. $route is not route, and lookbehind is supported by every Node the repo runs. Needs the delta measured and stated, including the declarationsIn side that docs-audit: subroute: / myclient: mints a silent PHANTOM ROW — only declarationsIn anchors the key with \b, the other seven scans do not #11542's pricing deliberately excluded.
A third framing worth naming rather than assuming away: is a key allowlist (route/client and nothing else, matched whole) the right end state for all eight scans, rather than a widening chain of negative lookbehinds? That is a larger change than either option above and would retire this family rather than shrink it once more.
Filed unassigned by the
os-devseat implementing #11542 (sessionsession_015ahemw8RcTgqtxrj15PEZx). Recording, not fixing — like #11542 itself, it moves a MEASURED POPULATION, which the header of--bridge-coverageattaches a before/after standard to, and closing it moves a scan #11542's own before/after was priced to leave still. No live instance on today's tree.What
#11542 gives the eight
route:/client:lead scans inscripts/docs-audit/affected-docs.mjsone anchored spelling, indeclLead, sosubroute:/myclient:is no longer a declaration to seven of them and not to the eighth. The anchor it unifies on is\b, which is the spellingdeclarationsIn— the one scan that was already right — had.\basserts a boundary between a word character and a non-word character. It therefore fails only against a preceding word character ([A-Za-z0-9_]).$is not one, and$routeis a legal JS identifier:⇒
rows 2 · routesDeclared 2 · clientsDeclared 1 · declined 0 · outsideCode 0 · brokenScan 0A file declaring one
route:produces two rows. Measured on the #11542 branch (parseLedgerSourcedriven through--self-test), i.e. after the anchor lands.Why it is silent, and how this differs from #11542
Silent for the reason #10683 / #10793 / #11542 were: the partial-read verdict keys on the gap between
rowsandroutesDeclared, and after #11542all eight scans read the same spelling, so both terms still move together and no verdict fires.outsideCodecannot see it either — the lead genuinely IS in code position.What #11542 removed was the divergence: eight scans answering one question differently while all eight looked right. This is not that. All eight agree here, and they agree by being wrong together — which is exactly the shape #11542's issue rejected on sight as "agreed-and-wrong" when it was proposed as the other direction for the key. So it is a strictly smaller defect than #11542 was, and a real one.
--self-teston the #11542 branch pins today's behaviour as deliberately unmoved, so whoever closes this card flips an existing pin rather than finding none:Why #11542 did not fold it in
Tightening
declLead's anchor from\bto a negative lookbehind that also excludes$(the idiomrulePatternFor,symbolReanddottedRealready use in this same file) movesdeclarationsIntoo — the one scan #11542 left byte-identical on purpose. #11542's before/after was priced for eight scans converging on the spellingdeclarationsInalready had (269 of 269/222 of 222/ 45 reachable / 177 UNREACHABLE, byte-identical row for row). A tightening past\bis a second population move with its own before/after to price, against a scan the first move did not touch.Direction, not a prescription
Widen the anchor in
declLeadfrom\bto a negative lookbehind that also excludes$— one place, the way docs-audit:subroute:/myclient:mints a silent PHANTOM ROW — onlydeclarationsInanchors the key with\b, the other seven scans do not #11542 put the\bthere.<+!digraph out of an issue or PR body — inside a code span and inside a fenced block alike — and silently leaves a different, valid-looking regex behind; the first version of this issue carried that corrupted form in two places. Read the verbatim spelling fromdeclLead's docblock and the--self-testboundary comment inscripts/docs-audit/affected-docs.mjs, which the sanitizer cannot reach.$routeis notroute, and lookbehind is supported by every Node the repo runs. Needs the delta measured and stated, including thedeclarationsInside that docs-audit:subroute:/myclient:mints a silent PHANTOM ROW — onlydeclarationsInanchors the key with\b, the other seven scans do not #11542's pricing deliberately excluded.Leave it. No live instance. Costs what docs-audit:
subroute:/myclient:mints a silent PHANTOM ROW — onlydeclarationsInanchors the key with\b, the other seven scans do not #11542's route 3 cost: the counting contract is violated the moment one lands, and it lands silently.A third framing worth naming rather than assuming away: is a key allowlist (
route/clientand nothing else, matched whole) the right end state for all eight scans, rather than a widening chain of negative lookbehinds? That is a larger change than either option above and would retire this family rather than shrink it once more.Refs: #11542, #11494, #10901, #10793, #10683, #10500.
Generated by Claude Code