fix(web-api-discovery): the literal pass emits an unquoted sentinel where a JSON number was, and the gate passes it

[MarkMichaelis]

The defect

applyLiteralPass runs over the serialized whole-HAR string
(sanitize-har.js:661), replacing each profile literal with an angle-bracket
sentinel by plain text substitution. It has no idea what JSON context the value
sat in.

When the literal was a quoted string, the result is well-formed:

"userId":"<literal>"   ->   "userId":"<FacebookUserId>"      valid

When the literal was a bare JSON number, it is not:

"productIdentifier":<literal>}  ->  "productIdentifier":<FacebookUserId>}   INVALID

An angle-bracket sentinel is not a JSON token, so the document no longer parses.

Evidence

Real capture, MarkMichaelis/CodiwomplerSocialMedia,
.har-captures/www.facebook.com/2026-09-10-124423, entry 322:

raw span replaced        : 14 chars   (first char: a digit)
scrub span written       : 16 chars   (first char: "<")
raw char just BEFORE     : ":"
raw char just AFTER span : "}"
scrubbed window          : "…tID":null,"productIdentifier":<FacebookUserId>}"

The value was unquoted — a JSON number — and the sentinel replaced it in place.

Relationship to #479

#479 is the same symptom (a request payload rewritten into invalid JSON) via a
different mechanism. The fix for #479 decodes percent-encoded form bodies before
detection and replacement, which takes that capture from 15 of 24 unparseable
payloads to 1 of 24. This issue is the remaining 1.

They are separate because they live in different modules and neither fix implies
the other: #479 is pii.js reading escapes as digits; this is har-literals.js
ignoring JSON context. #479 should stay open until both land.

Why the leak gate does not catch it

Same blind spot as #479 and #475: verify-scrub asks whether a secret survived,
never whether the document it produced is still well-formed. This capture scrubbed
clean — verified: true, errors: 0 — with an unparseable payload in it.

Suggested fix

The literal pass already has the machinery: har-literals.js carries
percentDecode, parseJsonObject, decodeNestedJson and
transformEncodedParams, so it is not naive about encoding — only about JSON
value context.

The narrow fix is to quote the sentinel when the literal it replaces is not
already delimited: if the character before the match is : or , or [ and the
match is not preceded by ", emit "<Sentinel>" rather than <Sentinel>.

The more robust fix is the one #479 took — replace structurally on the parsed
document rather than textually on the serialization — but the literal pass runs
last, deliberately, over everything including non-JSON bodies, so that change is
larger than it looks and should be weighed rather than assumed.

Test note

The fixture must contain the literal as a bare JSON number, not a quoted
string. A string-valued fixture produces a well-formed result today and would keep
doing so after any fix, falsifying nothing.

Related

#479 (same symptom, percent-escape mechanism, fixed separately), #475 (a value
the scrubber's own table says to replace, surviving), #480 (a name-only secret in
a nested payload, never detected). All four share a root shape: the run holds
what it needs to check its own work and does not. Queue: #368.

[MarkMichaelis]

The heuristic approach is unsound. PR #485 is closed unmerged.

I implemented the "quote the sentinel when it stands in a whole-value position" fix suggested
above, and an independent review (Claude Sonnet 5) reproduced three ways it corrupts documents
that were previously fine. Verified by direct execution, not argument:

in : "Name: 61593494464534, Age: 5"          out: "Name: \"<S>\", Age: 5"
in : "a,61593494464534,c"                    out: "a,\"<S>\",c"
in : x:"abc\\", y:61593494464534,z:1}        out: ...y:\\"<S>\\",z:1}

1. Prose and CSV. : before and , after is ordinary punctuation, not JSON structure. The
   pass runs over everything — this repo's own suite already calls it on
   'owner is Ada Lovelace, cc Lovelace'. That test passes only because those characters miss
   the trigger set, not because the heuristic is right.
2. Escape depth cannot be read off the nearest quote. A same-depth sibling whose string
   value ends in \ makes the scan copy an unrelated backslash run, injecting literal
   backslashes into top-level JSON — the exact class of breakage this issue is about.
3. A raw %3A in un-encoded text spoofs the percent branch and injects %22.

The root problem is not the trigger set. The old behaviour was wrong for one narrow case and
safe everywhere else; any punctuation-based fix trades that for a broad, unbounded false-positive
class. That is a worse trade, and no amount of widening or narrowing the character sets
changes it — the pass has no structural knowledge of the text it edits, by design.

Where the real fix lives — this converges with #480

Worth recording, because it redirects the work:

A top-level bare JSON number could be fixed with no heuristic at all — walk the parsed HAR
before serialization and replace a number value with the sentinel string, which JSON.stringify
quotes correctly.

That would not fix the capture this was found in. There, the bare number sits inside
percent-encoded JSON inside a form parameter inside postData.text — a string at the HAR
level. Reaching it means descending into a nested encoded payload and operating structurally
once inside, which is exactly what #480 needs for a different reason.

So #482 and #480 want the same machinery, and neither is reachable by editing serialized text
with punctuation rules. They should be taken together, structurally, or not at all.

State left behind

• PR fix(web-api-discovery): the literal pass emitted a sentinel where a JSON value belonged #485 closed unmerged; branch and worktree removed.
• fix(web-api-discovery): the scrub read percent-escapes as payload digits, corrupting some bodies and leaking others #483 merged, which took the three measured captures from 12/26, 59/110 and 15/24
  unparseable request payloads down to 0/26, 0/110 and 1/24.
• That remaining 1 of 24 is this issue. It is a data-quality defect in a committable
  artifact — an unparseable variables payload — not a leak. Nothing is disclosed by it.
• fix(web-api-discovery): the scrub rewrites request payloads into invalid JSON, and the leak gate passes them #479 therefore stays open, and its remaining scope is exactly this one.

The test file written for the abandoned approach is not kept: eleven of its cases encode the
heuristic's own assumptions and would push a future fix back toward the same shape. The
reproductions above are the part worth keeping, and they are here.