Observation, filed unassigned while implementing #7086. Not a live defect today — the affected population is 0. Filed because #7086 makes the class reachable and the failure would be un-escapable rather than merely silent.
What #7086 changed, and the asymmetry it leaves
#7086 widened scanFences in scripts/check-doc-snippet-types.mjs so a fence opened inside a Markdown blockquote is collected and compiled. Blockquoted TypeScript blocks are now held to the gate's contract.
That contract has two halves: a collected block must compile, or it must carry a fragment marker declaring why it cannot. #7086 delivered the first half for blockquoted blocks and not the second, because two other anchors in the same function are still blockquote-unaware:
FRAGMENT_MARKER is anchored ^[ \t]* before the marker's opening delimiter, so > {/* doc-snippet: fragment ... */} does not register as a marker at all.- The attachment walk requires the marker to be the nearest non-blank line above the fence, and
trim() on a blockquote's spacer line yields >, not the empty string. So even a marker that did register would not attach across the > spacer that normally separates a callout's prose from its fence.
Net effect: a blockquoted TypeScript block that legitimately cannot compile — an elided body, a continuation of an earlier block — is collected, fails, and has no declared way to say so. The author's only outs are to unindent the callout or to add the page to UNGATED_DOCS, which is a debt list that is meant only to shrink.
Why it was left out of #7086
Population is 0, measured over the gate's own 224-document scan set: 0 blockquoted fragment markers. The controls hold in the same query — 2900 plain fence openers and 112 plain fragment markers, so the zero is a reading and not a broken pattern.
And the fix is not the same one-line shape as #7086's. Widening FRAGMENT_MARKER alone would be a half-fix that only works when the marker sits immediately above the fence with no > spacer — worse than leaving it, because it would work in tests and fail in the callout shape real pages use. Doing it properly means also teaching the blank-line walk that a bare > is blank, which is a second mechanism in the same function. That was outside the dispatched scope for #7086, which was explicitly bounded to the collector's anchor and its prefix-stripping.
Suggested disposition
Low priority while the population stays 0. The cheap defensive version is a diagnostic rather than a feature: when a failing collected block sits at quote depth greater than 0, say so in its message, so the author is told the escape hatch is out of reach instead of being left to guess. The full version widens both the marker anchor and the blank-line walk to the opener's depth, reusing the stripQuotePrefix helper #7086 added.
Refs #7086.
Generated by Claude Code
Observation, filed unassigned while implementing #7086. Not a live defect today — the affected population is 0. Filed because #7086 makes the class reachable and the failure would be un-escapable rather than merely silent.
What #7086 changed, and the asymmetry it leaves
#7086 widened
scanFencesinscripts/check-doc-snippet-types.mjsso a fence opened inside a Markdown blockquote is collected and compiled. Blockquoted TypeScript blocks are now held to the gate's contract.That contract has two halves: a collected block must compile, or it must carry a fragment marker declaring why it cannot. #7086 delivered the first half for blockquoted blocks and not the second, because two other anchors in the same function are still blockquote-unaware:
FRAGMENT_MARKERis anchored^[ \t]*before the marker's opening delimiter, so> {/* doc-snippet: fragment ... */}does not register as a marker at all.trim()on a blockquote's spacer line yields>, not the empty string. So even a marker that did register would not attach across the>spacer that normally separates a callout's prose from its fence.Net effect: a blockquoted TypeScript block that legitimately cannot compile — an elided body, a continuation of an earlier block — is collected, fails, and has no declared way to say so. The author's only outs are to unindent the callout or to add the page to
UNGATED_DOCS, which is a debt list that is meant only to shrink.Why it was left out of #7086
Population is 0, measured over the gate's own 224-document scan set: 0 blockquoted fragment markers. The controls hold in the same query — 2900 plain fence openers and 112 plain fragment markers, so the zero is a reading and not a broken pattern.
And the fix is not the same one-line shape as #7086's. Widening
FRAGMENT_MARKERalone would be a half-fix that only works when the marker sits immediately above the fence with no>spacer — worse than leaving it, because it would work in tests and fail in the callout shape real pages use. Doing it properly means also teaching the blank-line walk that a bare>is blank, which is a second mechanism in the same function. That was outside the dispatched scope for #7086, which was explicitly bounded to the collector's anchor and its prefix-stripping.Suggested disposition
Low priority while the population stays 0. The cheap defensive version is a diagnostic rather than a feature: when a failing collected block sits at quote depth greater than 0, say so in its message, so the author is told the escape hatch is out of reach instead of being left to guess. The full version widens both the marker anchor and the blank-line walk to the opener's depth, reusing the
stripQuotePrefixhelper #7086 added.Refs #7086.
Generated by Claude Code