Found while implementing #11355 (packages/spec/scripts/check-skill-examples.ts).
The gap
#11355 gave both loops in extractFromFile one shared notion of fence ownership
(fenceOwners()). The body boundary is still computed twice, by two patterns that do not
agree on what closes a fence:
extraction body end ^```\s*$ (exactly three backticks, column 0)
fence walk close ^ {0,3}`{run,}[ \t]*$ (run-length aware, up to three spaces indent)
Both directions diverge:
Status
Latent, no occurrence. Measured on the corpus while landing #11355: 257 marked blocks
across 99 files extract identically with the ownership fix in place, and no file in any
scanned root uses CRLF (checked skills/, content/docs/, packages/spec/src,
packages/client-react/src, packages/client/src — zero files containing CR).
Worth recording rather than leaving buried because it is the same family as #11355: two
notions of one fact living in one file, agreeing today. The per-surface vacuous-green guard
would catch a whole surface dropping to zero blocks, but a single file's tail going quiet is
invisible to it.
Suggested shape
Un-adjudicated:
- Take the body end from the same walk —
fenceOwners() already computes each span's end, so
extraction could read it instead of re-deriving one. Re-measure corpus extraction identity
either way; the 257 blocks / 99 files reading above is the baseline to compare against. - Or state the divergence deliberately in the file's header comment, so the next author knows
which closer governs which half.
Deliberately not folded into #11355's PR: that card's ruling scoped the change to
fence-awareness of extraction's recognition, and this is a different question (where a block
ends) whose fix has to be re-measured against the corpus on its own.
Found while implementing #11355 (
packages/spec/scripts/check-skill-examples.ts).The gap
#11355 gave both loops in
extractFromFileone shared notion of fence ownership(
fenceOwners()). The body boundary is still computed twice, by two patterns that do notagree on what closes a fence:
Both directions diverge:
closes the fence for the walk but not for extraction. Extraction's body then runs past the
real end of the block — to the next bare three-backtick line, or to EOF.
(
\s*matches CR) but not for the walk ([ \t]*does not). The walk then reads the fenceas unclosed, which under CommonMark consumes the rest of the document — and since [finding] check:skill-examples's marked-block EXTRACTION (not just the orphan scan) is not fence-aware — a fully worked nested example could misfire #11355
that also suppresses extraction of every later block in that file, and suppresses orphan
reporting for it.
Status
Latent, no occurrence. Measured on the corpus while landing #11355: 257 marked blocks
across 99 files extract identically with the ownership fix in place, and no file in any
scanned root uses CRLF (checked
skills/,content/docs/,packages/spec/src,packages/client-react/src,packages/client/src— zero files containing CR).Worth recording rather than leaving buried because it is the same family as #11355: two
notions of one fact living in one file, agreeing today. The per-surface vacuous-green guard
would catch a whole surface dropping to zero blocks, but a single file's tail going quiet is
invisible to it.
Suggested shape
Un-adjudicated:
fenceOwners()already computes each span's end, soextraction could read it instead of re-deriving one. Re-measure corpus extraction identity
either way; the 257 blocks / 99 files reading above is the baseline to compare against.
which closer governs which half.
Deliberately not folded into #11355's PR: that card's ruling scoped the change to
fence-awareness of extraction's recognition, and this is a different question (where a block
ends) whose fix has to be re-measured against the corpus on its own.