The attribution gate cannot be written about in a fenced code block. GENERATED_RE is anchored to line start, so any line inside a markdown code fence that begins with the banned footer shape is refused exactly as a real footer would be -- and a fence is the natural way to document a shape. Pre-existing, not introduced by iss-262: the plain `Generated with [tool](url)` form was already refused inside a fence; iss-262 extends that to the emphasised forms. Hit live on the iss-262 PR itself, whose first body quoted the footer in a fence and failed the gate it tightens. The current convention is to quote the shape mid-sentence instead, which the corpus pins with two accept cases, but that makes the one document most likely to show the shape -- the change that tightens the rule -- the one least able to show it. Options: (a) keep the convention and document it in AGENTS.md so the next author does not rediscover it through a red CI leg; (b) teach the gate fence state, which costs real complexity in a bash security check and opens an evasion route, since a footer wrapped in a fence would go unflagged while still rendering as visible text; (c) accept as-is. Needs a deliberate ruling rather than a same-PR patch.

Frontmatter

.abcd/work/issues/resolved/iss-268-the-attribution-gate-cannot-be-written.md
open on GitHub ↗ · commit history ↗

mentions4

• dcn-26081700000000042026-08-17 — The attribution gate's list-container fence limit is ACCEPTED as a
• iss-262check-attribution.sh's GENERATED_RE misses the italic footer form a hosted agent platform actually appends: `_Generated by [Claude Code](...)_` starts with an underscore, and the regex anchors '^[[:space:]]*(robot)?[Gg]enerated (with|by) [' — so the exact footer shape that motivated the gate sails through the body check when wrapped in markdown italics. Admit an optional leading '_' or '*' (and matching trailing) in the shape. Found live: both walkability PRs carried the italic footer and the body check did not flag it; the failing leg was commit identity.
• iss-270The attribution gate's fence handling reads a fence's indent in ABSOLUTE columns, but CommonMark measures the three-space opener limit relative to the enclosing container. That diverges in BOTH directions inside a list item, and the dangerous direction is the one this record originally stated backwards.
• iss-271Three clauses of the attribution gate's fence matcher are not pinned by the corpus. Found by the ruthless review of iss-268, which ran a 31-mutant battery: (1) the marker-character TYPE restriction in fenceparse -- substituting 'if (c == "") return 0' keeps termination and leaves the corpus green, but --- *** ___ === runs then become fence delimiters, which is a real bypass direction; (2) the tab exclusion in sub(/^ +/, "", t) -- the comment asserts a tab-led line is not a fence, but allowing [ \t] leaves the corpus green; (3) blank()'s \t\r character set -- narrowing it to a plain space leaves the corpus green. All three are CORRECT as written; only the coverage is missing, and only the first has a bypass direction. Two smaller gaps from the same battery: the iss-270 list-item residual is pinned for '- ' items but not for '1. ' items (content column 3, also under the absolute limit, same class and same reproduction shape), and no case places a checkable line immediately after a fence closer, so a one-line over-strip at the boundary would pass the whole corpus. Note when adding cases for (1): deleting the marker-character line outright HANGS awk rather than failing a case, because on an empty line the character is the empty string and substr past the end also returns it, so the run counter never terminates -- a mode a pass/fail corpus cannot express, and the reason that line carries a termination comment.