Found while extending that gate for #10641. Nothing is broken through this today — all ten links currently resolve. It is a hole in the gate's population, filed as an observation.
A note on spelling, because this issue was born mangled. Every literal
angle-bracket token in the first version of this body was eaten by GitHub's body
sanitizer — inside code spans, inside fenced blocks, and in the issue title —
leaving empty backticks and a measurement block with the input missing. So this
body writes the two characters as LT and GT throughout. AGENTS.md's
"GitHub mutates body BYTES" clause is the authority; this issue is one more
datapoint for it.
The gap
extractLinks in scripts/check-published-readme-links.mjs matches two shapes:
INLINE_LINK — the [text](dest) form, and its image variantREFERENCE_DEFINITION — the [label]: dest form
It does not match the CommonMark autolink: a bare URL surrounded by angle
brackets, LT https://example.com/x GT written with no spaces. GitHub and npm both
render that as a live link. Measured against the shipped extractor:
input Docs: LT https://objectstack.ai/docs/no-such-page-anywhere GT
output []
(LT and GT standing in for the literal angle brackets, per the note above.)
So an autolinked docs URL is invisible to all four assertions — no page-resolution
check, no anchor check. A 404 written in that form ships to npm green.
Population
Ten such links in published READMEs, all pointing at the docs site:
packages/adapters/hono/README.md:84,85
packages/core/README.md:113,114
packages/drivers/driver-memory/README.md:95,96
packages/plugins/plugin-security/README.md:109,110
packages/rest/README.md:122,123
Every one resolves against content/docs right now (/docs, /docs/references,
/docs/references/api, /docs/references/kernel, /docs/references/security,
/docs/protocol), which is why this is a latent hole and not a live defect. They are
also already on the canonical host, so the #10641 sweep had nothing to do to them —
worth saying plainly, because it means the gate's silence on this form has never yet
been observed to cost anything.
Why it is worth closing anyway
The gate's own header states its subject as "every outbound link in a PUBLISHED
markdown file". This form is a link by that definition, and it is the form the READMEs
reach for in their most prominent position — the "Docs" / "API Reference" footer pair
in five packages. A future edit to one of those routes is exactly the drift assertions
3 and 4 exist to catch, and they would not catch it.
Shape of a fix
An autolink is a destination with no label, so it needs a third pattern beside the two
above, plus a --self-test case pinning it — the gate's own stated convention is that
every recognised shape gets a pin. Three things to be careful about:
stripCodeSpans / stripFencedBlocks run first, so an autolink inside a fence
stays example text. That is already correct for the other two patterns and should
stay correct for this one; a self-test case in the same shape as the existing
"SKIPS a link inside a fenced block" pin covers it.- The pointy-bracket destination form — angle brackets inside the parentheses of
an inline link, used when the URL contains a space — is a different construct and is
already handled within INLINE_LINK. The autolink is the bare URL with no
surrounding link syntax. Do not conflate them; the existing pin
"extractLinks unwraps a pointy-bracket destination" covers only the first. - CommonMark also autolinks a
mailto: URI in the same brackets. That should classify
as external, exactly as the inline form does today, and is worth its own pin.
Found while extending that gate for #10641. Nothing is broken through this today — all ten links currently resolve. It is a hole in the gate's population, filed as an observation.
The gap
extractLinksinscripts/check-published-readme-links.mjsmatches two shapes:INLINE_LINK— the[text](dest)form, and its image variantREFERENCE_DEFINITION— the[label]: destformIt does not match the CommonMark autolink: a bare URL surrounded by angle
brackets,
LT https://example.com/x GTwritten with no spaces. GitHub and npm bothrender that as a live link. Measured against the shipped extractor:
(
LTandGTstanding in for the literal angle brackets, per the note above.)So an autolinked docs URL is invisible to all four assertions — no page-resolution
check, no anchor check. A 404 written in that form ships to npm green.
Population
Ten such links in published READMEs, all pointing at the docs site:
Every one resolves against
content/docsright now (/docs,/docs/references,/docs/references/api,/docs/references/kernel,/docs/references/security,/docs/protocol), which is why this is a latent hole and not a live defect. They arealso already on the canonical host, so the #10641 sweep had nothing to do to them —
worth saying plainly, because it means the gate's silence on this form has never yet
been observed to cost anything.
Why it is worth closing anyway
The gate's own header states its subject as "every outbound link in a PUBLISHED
markdown file". This form is a link by that definition, and it is the form the READMEs
reach for in their most prominent position — the "Docs" / "API Reference" footer pair
in five packages. A future edit to one of those routes is exactly the drift assertions
3 and 4 exist to catch, and they would not catch it.
Shape of a fix
An autolink is a destination with no label, so it needs a third pattern beside the two
above, plus a
--self-testcase pinning it — the gate's own stated convention is thatevery recognised shape gets a pin. Three things to be careful about:
stripCodeSpans/stripFencedBlocksrun first, so an autolink inside a fencestays example text. That is already correct for the other two patterns and should
stay correct for this one; a self-test case in the same shape as the existing
"SKIPS a link inside a fenced block" pin covers it.
an inline link, used when the URL contains a space — is a different construct and is
already handled within
INLINE_LINK. The autolink is the bare URL with nosurrounding link syntax. Do not conflate them; the existing pin
"extractLinks unwraps a pointy-bracket destination" covers only the first.
mailto:URI in the same brackets. That should classifyas
external, exactly as the inline form does today, and is worth its own pin.