Measured on PR #11430 (card #11374, driver-sql column mapping) on 2026-08-23. Filed unassigned, as an observation with a clean same-day reproduction.
This is the #9282 class — "the file that CARRIES a rule several pages restate yields no anchor" — reproduced in a different file, and notably after #9192 replaced package-granular listing with precision-first symbol anchoring specifically to fix the both-directions error that #9192's own title names.
What the diff changed
packages/drivers/driver-sql/src/sql-driver.ts — createColumn's mapping for the text family. Before: text / textarea / html → TEXT on every dialect. After: VARCHAR(maxLength) when the field declares a maxLength ≤ 768 and a declared index keys the column.
What the advisory said
Six hand-written pages, every one via the same coarse anchor SqlDriver (symbol):
data-modeling/drivers.mdx · data-modeling/index.mdx · plugins/packages.mdx · protocol/kernel/index.mdx · protocol/kernel/lifecycle.mdx · protocol/objectql/query-syntax.mdx
None of the six states the type→column mapping. They name the SqlDriver class in passing (lifecycle, plugin registration, a keyset-pagination example).
What it missed
content/docs/protocol/objectql/types.mdx — not listed, and it is the page the diff falsified, in four places:
- the
text field's **Database mapping:** — "SQL driver: TEXT on every dialect. maxLength is enforced by record validation, not by the column type — the DDL does not read it." Now false in both sentences. textarea's same line;html's same line;- the Type Conversion Matrix row
| text | TEXT | TEXT | TEXT |.
All four were corrected in #11430 — but only because a human went looking, not because the advisory pointed there.
Why it misses, and why this is structural rather than a tuning miss
The page documents the mapping by its inputs — the ObjectQL type names text, textarea, html. The diff touches the mapping's implementation — the emitter. The two share no symbol, so precision-first anchoring has nothing to connect them.
That is the same shape #9282 recorded for declared-fields.ts and #8771 recorded pre-#9192. The rule that a page restates and the code that carries the rule are related by semantics, not by a shared identifier, and an identifier-based bridge is structurally unable to see it.
⚠️ The direction that matters: the six false positives are cheap — a reader skims and dismisses them. The false negative is not, because the advisory's presence invites the reader to treat "not listed" as "not affected". An advisory that is silently incomplete on exactly the rule-carrying files is worse for those files than no advisory, since it supplies unearned confidence.
Not claimed
- No population measured. I have not swept for other rule-carrying files with the same property; this is one instance plus two closed precedents in the same class, not a census. That sweep is the obvious next question and I have not run it.
- No fix proposed. Whether the answer is a curated code↔page ledger for rule-carrying files, a per-type anchor vocabulary, or accepting the gap and saying so in the advisory's own "what this run could not see" block is a devx design call.
- The advisory does already publish a "what this run could not see" section — it names the SDK route-bridge coverage (45 of 222). This class is not in it, and adding it would at least make the gap honest.
Lineage
#9192 (both-directions error, package-granular) → #8771 (missed the one page documenting the narrowed endpoint) → #9282 (structurally blind to the rule-carrying file) → #11357 (open: READMEs still anchorless after #9282's close) → this card (rule-carrying file, post-#9192, both directions in one PR).
Filed by the engine seat while reviewing #11430; the docs there are fixed, so nothing is currently shipping wrong on account of this.
Measured on PR #11430 (card #11374, driver-sql column mapping) on 2026-08-23. Filed unassigned, as an observation with a clean same-day reproduction.
This is the #9282 class — "the file that CARRIES a rule several pages restate yields no anchor" — reproduced in a different file, and notably after #9192 replaced package-granular listing with precision-first symbol anchoring specifically to fix the both-directions error that #9192's own title names.
What the diff changed
packages/drivers/driver-sql/src/sql-driver.ts—createColumn's mapping for the text family. Before:text/textarea/html→TEXTon every dialect. After:VARCHAR(maxLength)when the field declares amaxLength≤ 768 and a declared index keys the column.What the advisory said
Six hand-written pages, every one via the same coarse anchor
SqlDriver (symbol):data-modeling/drivers.mdx·data-modeling/index.mdx·plugins/packages.mdx·protocol/kernel/index.mdx·protocol/kernel/lifecycle.mdx·protocol/objectql/query-syntax.mdxNone of the six states the type→column mapping. They name the
SqlDriverclass in passing (lifecycle, plugin registration, a keyset-pagination example).What it missed
content/docs/protocol/objectql/types.mdx— not listed, and it is the page the diff falsified, in four places:textfield's**Database mapping:**— "SQL driver:TEXTon every dialect.maxLengthis enforced by record validation, not by the column type — the DDL does not read it." Now false in both sentences.textarea's same line;html's same line;| text | TEXT | TEXT | TEXT |.All four were corrected in #11430 — but only because a human went looking, not because the advisory pointed there.
Why it misses, and why this is structural rather than a tuning miss
The page documents the mapping by its inputs — the ObjectQL type names
text,textarea,html. The diff touches the mapping's implementation — the emitter. The two share no symbol, so precision-first anchoring has nothing to connect them.That is the same shape #9282 recorded for
declared-fields.tsand #8771 recorded pre-#9192. The rule that a page restates and the code that carries the rule are related by semantics, not by a shared identifier, and an identifier-based bridge is structurally unable to see it.Not claimed
Lineage
#9192 (both-directions error, package-granular) → #8771 (missed the one page documenting the narrowed endpoint) → #9282 (structurally blind to the rule-carrying file) → #11357 (open: READMEs still anchorless after #9282's close) → this card (rule-carrying file, post-#9192, both directions in one PR).
Filed by the engine seat while reviewing #11430; the docs there are fixed, so nothing is currently shipping wrong on account of this.