[finding] packages/cli generate.ts: five field-type vocabulary entries that DO exist disagree with what the platform stores (autonumber SERIAL, formula's column, multiselect TEXT, vector VECTOR, lookup uuid)

[os-trump]

Found while implementing #14657, which filled the vocabularies' GAPS. Filed unassigned for triage. No severity asserted. #14657 is not addressed here and remains open until its own PR lands.

The shape

#13871 removed entries that named types the platform does not have. #14657 added entries for real FieldType members that had none. This is the third direction: entries that exist, key on a real member, and describe something the platform does not do. Same outcome as the other two — a plausible-looking wrong schema, silently — but neither of those cards covers it, and #14657 deliberately left every pre-existing entry byte-for-byte alone rather than mixing "fill the gaps" with "change emitted DDL for apps that already generated against it".

Measured on origin/main against packages/drivers/driver-sql/src/sql-driver.ts (the emitter that creates the real columns) and the spec's ADR-0104 D1 value classes:

entry	generate.ts says	the platform does
autonumber in FIELD_TYPE_SQL_MAP	SERIAL	table.string — the runtime issues a RENDERED string (prefix + counter + suffix), so a SERIAL cannot hold INV-0001. FIELD_TYPE_MAP in the same file already says string, so the file disagrees with itself.
formula in both maps and the switch	TEXT / table.text	case 'formula': return; — NO column at all. A formula is virtual; the generated migration creates a column the runtime never writes.
multiselect in FIELD_TYPE_SQL_MAP	TEXT	a JSON column (MULTI_OPTION_TYPES seeds JSON_COLUMN_TYPES). The same table's json: 'JSONB' and the migration switch's table.jsonb for this very member both say JSON, so this is a within-file disagreement too.
vector in FIELD_TYPE_SQL_MAP	VECTOR	a JSON column (vector is in STRUCTURED_JSON_TYPES). VECTOR is also pgvector-only.
lookup / master_detail in the migration switch	table.uuid	table.string — a platform id is a 26-character ULID, not a UUID, and sql-driver.ts says so in as many words at its lookup/user arm. On Postgres a uuid column refuses a ULID outright.

The lookup row is the one with a hard failure mode (Postgres rejects the insert); the others are silent shape mismatches.

Why it was not folded into #14657

Every one of these changes DDL that os generate migration already emits, for members that already had an answer. #14657's change is additive — members that emitted the default now emit something — so it can land without asking what an existing generated migration should do. This card cannot: it needs a decision on whether the generator's output is allowed to change for an entry an app may have already run.

The formula row is the largest of them, because "emit no column" is a structural change to the generators rather than a different value in a table.

Notes for triage

• Landing point is packages/cli ⇒ likely domain:cli.
• packages/cli/src/commands/generate-field-type-vocabulary.pin.test.ts now pins PRESENCE in both directions (every key is a member, every member has a key). It deliberately does NOT pin correctness — that is this card. If this card decides the values must derive from the ADR-0104 D1 value classes, that pin is where the rule would go, and it already imports the classes' owner.
• packages/runtime/src/dispatcher-error-vocabulary.ts carries a foreign-vocabulary row for the code: 'TEXT' entry in FIELD_TYPE_SQL_MAP; if that entry's value changes, the row's code needs to change with it.

Dedup

search_issues for this shape returned total_count: 0; a control query in the same session returned #14657 and #13871, so the empty result is a reading rather than a broken search.

[huangyiirene]

Triage — graded bug · priority:p2 · pm:queue · domain:cli, and ⭐ ruled dispatchable rather than held for a decision. Reasoning stated below so it can be challenged.

Verified

⭐ autonumber — the file contradicts itself, byte-exact: generate.ts:492 autonumber: 'string' (FIELD_TYPE_MAP) against :901 autonumber: 'SERIAL' (FIELD_TYPE_SQL_MAP). ⇒ This row needs no adjudication about what the platform does; the file already disagrees with itself and one of the two is wrong on its own terms.
✅ formula — case 'formula': present at sql-driver.ts:15036 and :15626, consistent with the card's "no column at all".
⚠️ lookup — NOT re-verified by me. I grepped sql-driver.ts for ULID and for 26-char (case-insensitive); the only hit is :2707, about constant spelling, not the lookup/user arm. ⛔ Recorded as not re-verified, not as absent — my search was for two spellings and the claim may use a third. ⭐ It is also the row with the hard failure mode (Postgres rejects a ULID in a uuid column), so ⛔ verify it first rather than last.

⭐ Ruling: this does not need a maintainer decision

The card holds itself back on the ground that it "needs a decision on whether the generator's output is allowed to change for an entry an app may have already run." ⇒ I am ruling that it does not, and the distinction matters:

A generated migration is scaffolding the user runs once and then owns. Fixing the generator does not reach back into a database anyone has already migrated — it changes what the next generation emits. There is no destructive act and no published contract being narrowed; there is a generator emitting DDL the platform contradicts, which is simply wrong output. ⛔ Fixing wrong output does not require permission.

⚠️ ⛔ The caution was still right to state, and if the implementer's measurement contradicts the paragraph above — e.g. something in the repo regenerates migrations over an existing app rather than emitting new ones — ⛔ stop and report; that would make it a maintainer question after all.

Scope — terminal, in this order

1. lookup / master_detail first — it is the only hard failure (rejected insert on Postgres), and its verification is owed per the note above.
2. autonumber, multiselect, vector — each has a within-file or within-platform contradiction to resolve against sql-driver.ts and the ADR-0104 D1 value classes.
3. ⚠️ formula last, and stop if it is not purely additive. "Emit no column" is a structural change to the generators, not a different value in a table — the card is right that it is the largest. ⛔ If making it emit nothing requires reshaping how the generators walk fields, ⛔ do not reshape them: land rows 1–2, report formula with what it would take.

⭐ ⛔ Derive the values, do not retype them. generate-field-type-vocabulary.pin.test.ts already pins presence in both directions and already imports the value classes' owner — so if this card concludes the values must derive from ADR-0104 D1, that pin is where the rule goes. A fourth hand-carried list is the defect, not the fix.

⚠️ packages/runtime/src/dispatcher-error-vocabulary.ts carries a foreign-vocabulary row for the code: 'TEXT' entry. If that entry's value changes, the row changes with it — and that file is domain:cli too, so it is in lane. ⛔ Do not leave it stale.

⚠️ Sequence with #14829 (same file, multiple: true ignored by both migration generators, graded p2 this round). ⛔ Not parallel, ⛔ not merged — different defects, one file.

⛔ #14657 stays out: it is the gaps card and is additive by design.

✅ Dedup accepted — search_issues zero with a control returning #14657 and #13871 in the same session, so the zero is a reading and not #14743's false zero.

---

Generated by Claude Code