Development record
The 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.
The 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.
UNDER-REJECTION (the hole, live today). A first-level - item's content sits at column 2 and a 1. item's at column 3 — both UNDER the absolute limit. So a fence opened inside such an item is read as a document-level fence, the span it "closes" over is stripped, and a footer inside that span never reaches the rules although the forge renders it as an ordinary paragraph. Reproduced and pinned in the corpus as a known-accept (KNOWN: a fence inside a list item is read as document-level).
OVER-REJECTION (the usability complaint). Nested deeper — a fence under a second-level bullet, or inside a blockquote — the indent exceeds the limit, the fence is not recognised, and the gate refuses the example exactly as iss-268 described. This repo's pull-request bodies are heavily bulleted, so both shapes are common.
DO NOT relax the opener indent limit. An earlier draft of this record proposed exactly that, on the ground that deeply-indented content is itself a code block. It is the wrong move: relaxing the limit widens the under-rejection hole above while appearing to fix the complaint, and it was grounded in the "stripped region is a subset of what markdown renders as code" invariant that iss-268 retracted as false.
What iss-268 settled on instead: the property the gate actually defends is that a footer appended LAST is caught whatever precedes it — an accident at scale (itd-91), not an adversary — and a body constructed around the footer was never defended. Any fix here must keep that property and must not be justified by the retracted subset claim.
Options: (a) track container context properly (list-item content indent, blockquote markers), which is a markdown block parser and probably too much for a bash gate; (b) refuse to strip anything from a document containing a list marker, as is already done for HTML blocks — safe by construction since striking less can only over-reject, but it would disable the concession for most of this repo's bodies; (c) accept and document, which is the current state, with the residual pinned in the corpus so a future change is visible.
Found by the ruthless and security reviews of the iss-268 fix.
Frontmatter
| id | iss-270 |
|---|---|
| type | issue |
| lifecycle | wontfix |
| severity | minor |
.abcd/work/issues/wontfix/iss-270-the-attribution-gate-still-cannot-be.md
open on GitHub ↗ · commit history ↗
mentions5
- dcn-26081700000000042026-08-17 — The attribution gate's list-container fence limit is ACCEPTED as a
- dcn-26082600000000062026-08-26 — Bug-hunt round 9 (bughunt-a): baseline green after unshallowing
- iss-268The 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.
- 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.
- itd-91A Project Declares Once How It Wants AI Acknowledged — And Every Commit, PR, And Record Follows