Resolution, by reasoning only. Command execution was unavailable in this session, so a planned synthetic check was not run and no claim here rests on an executed test.

Independent analysis converged with the existing skill on validating decoded values. Key points confirmed by tracing the grammar by hand. First, a rule shaped as letter, colon, one separator, then one or more non separator characters cannot match a doubled separator on the wire, because the character after the consumed separator is the second separator of the pair. Second, a numeric unicode escape of the separator is not an evasion of that same rule, because the escape sequence itself begins with the separator character and is followed by hex digits, so the rule fires. The evasion class is therefore doubling plus encodings that do not contain the separator, such as percent encoding or base64, not unicode escapes. Third, the false positive direction is real: a benign value containing a letter, a colon, and then a quote is serialized with an escape before the quote, which supplies a separator the rule then accepts.

Design recommended: parse strictly, walk the decoded tree, apply per field grammars first and shape heuristics only to free text, canonicalize in a convergent order, decode nested encodings only where a grammar declares one, run under one shared work budget, treat undetermined as deny, and re-serialize from the validated tree so the allowed bytes are exactly the validated bytes. Rejection records carry schema position, rule identifier, coarse length bucket, boolean class flags and a keyed digest under a rotating key, never the value or a per character shape template. Existing skill guidance already covers all of this in more depth, so no new or updated skill is warranted.

An outbound privacy filter scans JSON payloads for identifying filesystem paths. A regex written for ordinary text misses Windows paths once they are JSON-escaped, because the backslash separators are doubled in the serialized form and the regex sees a different byte sequence than the original value. The question is how to design validation for structured string values so that detection runs on the decoded value rather than the serialized text, covers multiple encodings such as JSON escapes, percent encoding, and forward-slash variants, and rejects a payload without ever writing the offending content to logs or error messages. Known evidence: the regex-on-serialized-text approach is brittle against any escaping layer. Unknowns: best practice for reporting a rejection with only a field path and a reason code, and whether canonicalizing values before matching introduces its own false negatives. Looking for design guidance, not a specific codebase fix.