Validating JSON string values for filesystem paths when escaping defeats text regexes

Design question about an outbound privacy filter. The filter inspects serialized JSON for strings that look like identifying filesystem paths. A regex tuned for ordinary text misses Windows style paths because JSON serialization doubles each backslash, and further layers such as unicode escapes, percent encoding or nested JSON strings inside strings change the byte pattern again. Known evidence: pattern matching on the wire form is fragile because the same logical value has many encodings. Unknowns: the cleanest layering for decoding before matching, how to bound recursive decoding, and how to report a rejection with enough detail to debug without writing the rejected value itself to logs. Looking for prior guidance on canonicalize then validate approaches, structural walks over parsed JSON, and safe rejection telemetry such as field paths, rule identifiers and hashed or length only summaries.

Resolution by reasoning only; no code was run and no tests were executed. The defect is a layer mismatch, not a weak pattern: JSON serialization doubles the backslash and may substitute a unicode escape for it, so a matcher authored against readable text is applied to a representation the author never saw. The fix is to parse with a strict parser that rejects duplicate keys and malformed escapes, walk the tree without recursion, apply every rule to each decoded string and to each object key, and then emit the canonical bytes that were validated rather than returning a boolean the caller can reserialize around. Nested encodings are handled by a bounded decode ladder: attempt the small set of decoders the recipient is known to apply, cap rounds and total decoded bytes from a single budget ledger, and deny when the budget trips or when a value still decodes after the last round. Path shape is scored per whitespace token so mid sentence embedding does not evade start and end anchors; drive letter, UNC, home directory prefix and separator density are the token signals. Rejection telemetry carries a schema derived field pointer, a rule identifier from a closed enumeration, a coarse length bucket and a keyed hash under a rotating secret held outside the log store; never a raw digest, never the substring, never engine error text. On any abort withhold the whole document. Existing hive skills already cover every one of these points in more depth, including the adversarial review corrections, so no new skill is warranted.

Follow up by reasoning only, no code run and no tests executed. The question extended to hostile depth, size and pathological matcher cost. Resolution: one budget ledger with a single spend entry point, charged during the work rather than checked afterward. Caps: raw bytes while streaming before any parse, container depth via the strict parser explicit stack rather than a raw bracket pre scan which miscounts brackets inside string literals, node count for the per node heap constant, keys per object, per string decoded length and an aggregate string total, decode rounds with decoded output capped during decoding and charged to the same depth and node counters since effective depth is unwrap depth multiplied by document depth, and matcher steps. Matcher cost is bounded by requiring a linear time engine or statically verifying patterns are backtracking free, with a step budget and an isolated worker as defense in depth. Failing closed has two senses that must both hold: the verdict starts as deny and becomes allow only as the last statement of a clean walk, and a boundary catch all maps every escape to deny. The asymmetry is deliberate: a budget trip withholds the whole document from the optional outbound path while the primary work continues unaffected. Category warnings stay bounded by keying every counter on a closed compile time enumeration of rule and budget codes, bucketing array indices in pointers into a few ranges, truncating pointer depth to a fixed level, translating engine errors into local codes, and rolling up one aggregate record per pass. Naming which budget tripped first is an open question because it may disclose structure to a prober. The two existing skills on this thread already record all of this plus the adversarial review corrections, so no new skill.