Design question about an egress privacy filter that scans outgoing JSON for identifying filesystem paths. A regex written for ordinary text can miss a Windows path once JSON encoding doubles each backslash, and it can also miss unicode escape sequences, forward slash variants, URL encoding, and values nested in arrays or objects. The filter must reject such payloads without writing the rejected content itself to logs, since the log would then leak the same identifying data. Known evidence: pattern matching on the raw serialized document is fragile because the same logical string has several serialized forms. Unknowns: the best layering of decode-then-validate versus validate-then-serialize, how to normalize candidate strings before matching, how to report a rejection with enough diagnostics for debugging while emitting only structural metadata such as key path, value length and rule identifier, and how to write tests that assert redaction without embedding real identifying values.

Resolution by reasoning only, no tests executed. The defect is a layer mismatch rather than a weak pattern: a rule authored for decoded text runs on serialized bytes, where a separator arrives doubled or as a unicode escape, so a rule of the form letter, colon, separator, non separator consumes the first backslash and fails on the second. The sound design is parse strictly with duplicate key rejection and depth and size limits, walk every decoded string at any depth, apply per field allowlist grammars and structural signals to the decoded value, then serialize canonically from the validated tree and have the allow result carry those exact bytes. Normalization is bounded to a small number of decode rounds under one shared budget and refuses values that keep changing; any abort fails the whole document. Rejection records are a type that cannot hold the value: schema derived field location, rule identifier, decode round, coarse length bucket, character class summary, and a keyed hash under a rotating secret. Tests generate candidates from a placeholder grammar, property test that detection commutes with each encoding transform, and assert via a capturing sink that no log record contains a candidate. The three existing skills matched at task start already cover this guidance fully, so no new or updated skill is warranted.

Follow up, reasoning only, no tests executed. Extended the design with resource exhaustion resistance. Three budgets draw from one per document ledger: bytes checked on raw length before parsing and on normalization output since compatibility normalization can expand, depth enforced inside the parser or by a bracket pre-scan because a recursive parser stack overflow is uncatchable and takes the host task down, and work as a fuel counter charged before each node visit, matcher byte, decode round and diagnostic hash. Backtracking is an engine property, not a pattern property, so an allowlist grammar with nested quantifiers is still catastrophic; use an automaton based linear time matcher or a structural scanner, with a hard value length cap and a wall clock deadline only as backstop. Two senses of failing closed stay separate: any exhaustion rejects the whole document and never shares the scanned prefix, while the primary task sees rejection as a returned value never an exception. Limits are fixed constants derived from legitimate payload distribution, never input scaled. Warnings are a closed enum of categories with per category counters, schema derived location, configured limit and a coarse exhaustion bucket, rate limited and deduplicated per window. Existing matched skills already cover the fuel ledger and the two fail closed senses, so no new skill.