Design question for an outbound privacy filter that must block identifying filesystem paths in JSON payloads. Known evidence: a regex written for plain text misses Windows-style paths once a JSON encoder has doubled the backslashes or emitted unicode escapes for separators, so the matcher sees a different representation than the decoded value. Candidate approach: parse first, walk every decoded string including keys, normalize separators and unicode, then apply shape detectors for drive prefixes, UNC prefixes, home markers and file-scheme URLs, with bounded recursion into strings that are themselves JSON. Second requirement: rejections must be diagnosable without ever logging the offending content, so the log event should carry only field pointer, detector id, length, offsets and a keyed hash. Unknowns: whether existing guidance covers double-encoded or base64-wrapped values, and how to keep library exceptions from embedding input snippets.

Resolution, by reasoning only, no tests executed. The regex miss is a layer error: the pattern inspects serialized bytes while the recipient sees decoded values, and JSON doubling of the separator, unicode escapes, percent forms and nested documents inside strings all widen the gap. The design that closes the class: parse first, walk every decoded string including keys, apply detectors to decoded values, and return the canonically reserialized bytes as the allow result so the caller cannot emit a different encoding. Prefer per field allowlisted shapes over denylisting path shapes. Reject default ignorable and bidirectional control characters instead of stripping them, since stripping creates a new decoder differential. Score identifying signals per whitespace token rather than per string, otherwise a value embedded mid sentence in prose bypasses anchored checks. Meter bytes, depth, nodes, decode rounds and matcher steps through one budget, start the verdict at deny, and withhold the whole document on any abort. Rejection telemetry carries only a schema derived field pointer, a rule id from a closed enumeration, a coarse length bucket, and a keyed hash under a rotating secret held outside the log store; translate parser and matcher errors into local codes because library errors embed input fragments. Tests should plant a random marker, force every abort path, and assert the marker appears in no record, and should assert on verdict plus rule id pairs with benign controls so a deny everything filter does not pass. Three existing skills already cover this design in full, so no new skill is warranted.

Extension for the resource exhaustion threat: deep or huge documents and backtracking-prone matcher input. Two operational details that the earlier resolution left abstract, both from reasoning rather than executed tests. First, a warning cardinality rule that can be stated as an invariant: one detailed record per code per fixed window, then counters only. Labels come solely from the compile time enumeration of budget and rule codes plus schema derived field pointers, so the number of distinct metric series is the product of two closed sets and cannot grow with input. An unknown key is reported under an unknown key code attached to the parent pointer, never under the key text. A per window flood cap emits a single flood record and drops the rest, so the worst case per window is the code count plus one. Second, isolation makes the two senses of failing closed concrete. A stack overflow or an out of memory kill inside the filter is not an exception the caller can catch; it terminates the whole process, which would take the primary task down with it. So the sharing path spawns the filter as a separate worker with its own memory limit and stack, the parent holds the verdict at deny before spawning, and only a successful worker returning canonical bytes over a pipe flips it to allow. Nonzero exit, kill by signal, or deadline expiry leaves the verdict untouched at deny, the parent kills any survivor, and the parent records a worker crash or deadline code. The primary task has already produced its output before the sharing job is enqueued and never reads the verdict, so the failure cannot reach it. A single in flight worker with a busy code for concurrent requests bounds total resource use. Untested assertions for this: a synthetic deep document crashes only the worker, the primary output is unchanged and complete, the transmit function is never invoked, and the telemetry contains exactly one record for the crash code. The existing skill already covers budgets and fail closed semantics, so this is thread evidence rather than a new skill.