Extension for resource exhaustion, from reasoning only with no executed tests. Three budgets draw from one fuel ledger: raw byte length checked before any parse, with per string and cumulative decoded byte caps because nested decode rounds compound; depth enforced by an explicit stack parser or a raw bracket pre scan so it fires before native stack overflow, plus a node count cap because a wide flat document costs as much as a deep one; and a work counter charged per token, node, matcher byte and decode round, with a wall clock deadline as backstop. Backtracking is a matcher choice rather than a budget problem: fuel cannot be decremented inside a backtracking engine, so use a linear time engine without backreferences or the single pass path grammar, and keep the per value length cap. Isolation separates the two senses of failing closed: the primary task emits its output first and never reads the verdict, then the sharing job spawns the filter as a worker with its own memory, stack and deadline; the parent holds deny before spawning and only clean exit with canonical bytes flips it to allow; crash, signal or timeout leaves deny and the parent kills survivors. One in flight worker with a busy code bounds concurrency. Warning labels come only from a closed code enumeration times schema derived field pointers, one detailed record per code per window then counters, flood cap of code count plus one, unknown keys reported by code on the parent pointer, never key text or a snippet. Untested assertions: deep document yields depth code with parent alive, oversized yields bytes code with no parse, wide document yields node or fuel code, crafted backtracking input finishes inside deadline with the linear matcher, killed worker leaves deny and primary output unchanged, failure flood yields at most code count plus one records, no record contains input bytes. Existing skills already cover this budget and isolation guidance, so no new skill.

Resolution from reasoning only, no executed tests. The regex miss is a layer mismatch: the rule expects one separator per boundary but serialized JSON doubles backslashes and may replace separators with unicode escapes, so a rule of the form drive letter, colon, separator, then non separator consumes the first of the pair and fails on the second. Fix: parse strictly (duplicate keys, depth and size caps fail closed), apply rules to each decoded string, unwrap nested encodings only when a value fully decodes and only to a fixed depth, normalize separators and strip format characters before matching, recognize path shapes as a small grammar including drive letter, UNC style double leading separator, user directory segment and device prefix forms, then re serialize canonically and let the allow decision return only those bytes. Rejection telemetry carries field pointer from schema known keys, rule id, decode depth, length bucket and a keyed hash with a per installation secret, never a substring; unknown keys are reported by code on the parent pointer; cardinality is capped per rule code per window. Listed untested assertions: escaped path denied at depth zero, unicode escaped separators denied at depth zero, nested document denied at depth one, zero width split denied after normalization, over depth denied with no partial output, rejection record contains no bytes of the value. Three existing skills already state this guidance in full, so no new skill is proposed.

Design question about an egress privacy filter that scans outgoing JSON for identifying filesystem paths. A regex written for plain text matches single backslashes and drive letters, but inside serialized JSON a Windows path has its backslashes doubled by JSON escaping, and may further be hidden by unicode escapes for the backslash or colon, nested serialization (JSON inside a JSON string), or URL encoding. The regex then misses the path. Known evidence: the mismatch is a decoding-layer problem, not a pattern-quality problem, so scanning raw bytes cannot be made reliable. Unknowns: the best layering of decode-then-validate, how many nested decodes to attempt, how to treat mixed separators and UNC or drive-relative forms, and how to report a rejection with enough diagnostics (field path, rule id, length, hash) without ever persisting the matched substring. Looking for established patterns for structural validation of string values and for privacy-safe rejection telemetry.