Found while implementing #11875 (signature/qrcode joined the driver's TEXT family under the 2026-08-25 maintainer ruling). Filed unassigned, observation-class — no measured consumer breakage; recording the drift so the next reader of type-compat.ts is told.
The observation
packages/spec/src/data/type-compat.ts (CANONICAL_TO_FIELD) maps each canonical SQL column type to the ObjectStack field types it is exactly/lossily compatible with:
text: { suggested: 'text', exact: ['text', 'textarea', 'email', 'url', 'phone', 'markdown', 'html', 'richtext', 'code', 'select', 'color'], lossy: [] } — signature and qrcode are absent.binary: { suggested: 'file', exact: ['file', 'image', 'signature'], lossy: ['text'] } — the only place signature appears, reading it as a binary payload.
After #11875, an unbounded TEXT column is the platform's OWN emitted physical shape for signature / qrcode (their stored value is a string — routinely a data-URI — per STRING_VALUE_TYPES and valueSchemaFor, which says z.string() for both). So introspecting a table the driver itself created would find a text column holding a signature and the compat table would not list signature as exactly compatible with it, while binary — a column shape the driver never emits for this type — would.
Why this is a finding and not part of #11875
The compat table serves external-column introspection/import suggestions, a different surface from the authoring/write/storage seams the ruling covered, and its membership semantics ("which field types can this existing column serve") were not part of the ruled route. Whether signature/qrcode (and possibly the binary.exact row) should move is a small self-contained decision for whoever owns this table.
Dedup note
The pre-filing issue search could not run in the filing session (repo-scoped REST returns 403 "GitHub access is not enabled for this session"); local grep of type-compat.ts and its neighbors found no issue reference covering this. If a covering card exists, close this as a duplicate.
Found while implementing #11875 (signature/qrcode joined the driver's TEXT family under the 2026-08-25 maintainer ruling). Filed unassigned, observation-class — no measured consumer breakage; recording the drift so the next reader of
type-compat.tsis told.The observation
packages/spec/src/data/type-compat.ts(CANONICAL_TO_FIELD) maps each canonical SQL column type to the ObjectStack field types it is exactly/lossily compatible with:text: { suggested: 'text', exact: ['text', 'textarea', 'email', 'url', 'phone', 'markdown', 'html', 'richtext', 'code', 'select', 'color'], lossy: [] }—signatureandqrcodeare absent.binary: { suggested: 'file', exact: ['file', 'image', 'signature'], lossy: ['text'] }— the only placesignatureappears, reading it as a binary payload.After #11875, an unbounded TEXT column is the platform's OWN emitted physical shape for
signature/qrcode(their stored value is a string — routinely a data-URI — perSTRING_VALUE_TYPESandvalueSchemaFor, which saysz.string()for both). So introspecting a table the driver itself created would find atextcolumn holding a signature and the compat table would not listsignatureas exactly compatible with it, whilebinary— a column shape the driver never emits for this type — would.Why this is a finding and not part of #11875
The compat table serves external-column introspection/import suggestions, a different surface from the authoring/write/storage seams the ruling covered, and its membership semantics ("which field types can this existing column serve") were not part of the ruled route. Whether
signature/qrcode(and possibly thebinary.exactrow) should move is a small self-contained decision for whoever owns this table.Dedup note
The pre-filing issue search could not run in the filing session (repo-scoped REST returns 403 "GitHub access is not enabled for this session"); local grep of
type-compat.tsand its neighbors found no issue reference covering this. If a covering card exists, close this as a duplicate.