A privacy filter scans outgoing JSON payloads for identifying filesystem paths. A regex tuned for ordinary text can miss a Windows path once the payload is JSON encoded, because each backslash becomes a doubled backslash, and unicode escapes can hide a backslash, drive colon or slash entirely. The open question is how to structure the check so it inspects decoded string values rather than serialized bytes, covers alternative encodings such as unicode escapes, URL encoding, forward slash Windows paths and UNC prefixes, and rejects safely without echoing the offending value into logs or error messages. Known evidence: serialization changes the byte pattern of separators; a filter on the serialized form is fragile. Unknowns: best placement in the pipeline, how to report a rejection with a stable field locator and category only, and how to test with synthetic values. Standalone design question; no repository inspection intended.

Resolution by reasoning only, no code executed. The text regex fails on serialized JSON because the encoder doubles every backslash, so a rule expecting a single separator followed by a non separator consumes the first backslash and then meets the second. Unicode escapes can remove the backslash, colon or slash from the wire form entirely. The correct fix is a layer change: strictly parse the outgoing document with duplicate key rejection and depth and size limits, walk the decoded tree, apply shape detectors to decoded string values and keys, normalize lookalike separators and strip zero width characters, decode nested JSON, percent and base64 layers for a small fixed number of rounds charged to one work budget, then serialize canonically from the validated tree and have the transmitter send only those bytes. Any parse failure or budget exhaustion rejects the whole document with nothing transmitted. Rejection records use a structure with no free string field: field locator, detector category, decoded length, match offset and length, plus a keyed digest of the value under a local secret for correlation and operator false positive checks. Library exception messages are wrapped because they embed input snippets. Recommended tests: round trip property test across all encoder wrappings, canary token leak test over all log sinks, false positive suite for version strings, ratios and URLs, and budget fail closed tests. The three existing skills matched at task start already cover this guidance in full, so no new skill is needed.

Follow-up on resource exhaustion, reasoning only, no tests executed. Three budgets checked cheapest first: a byte cap on the encoded payload before any parsing, a depth counter inside the parser rather than on the language stack so overflow surfaces as a deny outcome instead of an exception the caller might swallow, and a work ledger charged per decoded character, per nested decode round and per detector call. Detectors must be linear time, meaning no backreferences or lookaround, because a backtracking engine hides its cost inside one call and cannot be metered from outside. Fail closed has two directions: sharing is denied while the primary task continues. Achieve this by running the filter in a worker with a wall clock deadline and memory cap, and by making the outbound sender require a transmit handle that only an allow outcome produces. Deadline expiry and worker crash yield no handle, so nothing can be sent, and the supervisor returns control to the caller in every case. Denied payloads are marked permanently so a retry loop cannot burn CPU, and a circuit breaker on crash and deadline counts disables sharing for a cooldown. Warning cardinality rule, one per category per payload with counters beyond the window cap: categories are a closed enum, each category emits at most one warning per document with an integer hit count, and after a per window total the filter only increments a suppressed counter. Warnings carry category, count, integer depth, positional index path and ledger balances, never key names or value substrings, since keys can be attacker controlled. Existing skills already describe budget ledgers and the two senses of failing closed, so no new skill is proposed.