[finding] packages/cli generate.ts: 21+ real FieldType members have no entry in any of the three field-type vocabularies and fall silently to the default column/TS type

[os-trump]

Found while implementing #13871 (the ghost-label half of the same three vocabularies). Filed unassigned for triage. No severity asserted.

The shape

packages/cli/src/commands/generate.ts carries three field-type vocabularies:

• FIELD_TYPE_MAP — the TypeScript type os generate types emits, with || 'unknown' as the fallback.
• FIELD_TYPE_SQL_MAP — the SQL column type os generate migration --format sql emits, with || 'TEXT' as the fallback.
• the switch (fType) in generateMigrationTs — the knex builder os generate migration emits (typescript, the DEFAULT format), with default: table.text(...).

#13871 measured and removed the labels in those vocabularies that name types the platform does not have. This card is the other direction: real FieldType members that no vocabulary mentions, so they land on the fallback.

Measured against the 49-member FieldType on origin/main:

• Missing from both maps (21): secret, toggle, radio, checkboxes, tree, user, avatar, video, audio, summary, composite, repeater, record, location, address, code, slider, signature, qrcode, progress, tags.
• Missing from the migration switch (24): the 21 above minus user (which has its own arm), plus image, file, autonumber, vector.

Unlike the ghost labels, this half is reachable through the supported door: these are valid FieldType members, so defineStack accepts them and they arrive at the generator. Concretely, today:

• type: 'secret' generates TS unknown and a TEXT / table.text column.
• type: 'location' generates TS unknown and TEXT / table.text — while the ghost geo_point that [finding] packages/cli generate.ts 的迁移 codegen switch 携带自己的幽灵字段类型词表——'slug'/'ip_address'/'encrypted'/'integer' 是 case 标签但均非 FieldType 成员(#13716 同类,隔一个包) #13871 removed used to generate { lat: number; lng: number } and POINT, which is the shape the real member arguably wants.
• type: 'address', 'composite', 'repeater', 'record' are embedded structured values stored as JSON on the parent row, and all four generate TS unknown and a scalar TEXT column rather than the jsonb / object shape json and multiselect already get.

Why it is a decision, not a mechanical fix

Each missing member needs a real answer to "what column type, and what TypeScript type, does this deserve" — and some of those answers are cross-cutting (a POINT column is not portable to SQLite; the embedded-structured family may want one shared rule; secret stores an opaque ref whose TS type is a policy statement). #13871 deliberately left this alone rather than inventing answers next to a ghost removal, and its pin is written forward-only so it does not prejudge this card: it asserts every vocabulary key IS a FieldType member, never that every FieldType member has a key.

Notes for triage

• Landing point is packages/cli ⇒ likely domain:cli.
• generate-field-type-vocabulary.pin.test.ts (added by [finding] packages/cli generate.ts 的迁移 codegen switch 携带自己的幽灵字段类型词表——'slug'/'ip_address'/'encrypted'/'integer' 是 case 标签但均非 FieldType 成员(#13716 同类,隔一个包) #13871) is where a coverage assertion would go if this card decides total coverage is the rule; it already reads all three vocabularies out of the source.
• Whether the fallback is acceptable for some of these (a default arm exists on purpose) is part of the decision, so "add all 21" is not assumed to be the answer.

Dedup

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

[huangyiirene]

Triage — graded p3, tooling, pm:queue (not needs-user-decision), routed domain:cli — your own reading of the landing point, confirmed. Applied and read back first.

Structure confirmed at origin/main 4d0d944

All three vocabularies and both fallbacks are where you say:

generate.ts:471 const FIELD_TYPE_MAP: Record<string, string> = {
generate.ts:503 const base = FIELD_TYPE_MAP[fieldType] || 'unknown';
generate.ts:880 const FIELD_TYPE_SQL_MAP: Record<string, string> = {
generate.ts:912 return FIELD_TYPE_SQL_MAP[fieldType] || 'TEXT';
generate.ts:962 function generateMigrationTs(...)

generate.ts:876 states the forward-only invariant in its own words — "every key is a FieldType member" — confirming the pin does not prejudge this card. And the pin itself exists: packages/cli/src/commands/generate-field-type-vocabulary.pin.test.ts (under src/commands/, not test/ — worth knowing before someone looks in the wrong place, as I did).

Spot-checked six of the members you list — secret, location, address, composite, repeater, record — and each returns zero occurrences anywhere in generate.ts. So they are absent from all three vocabularies and land on the fallback, exactly as filed.

⚠️ I could not independently reproduce your 21/24 counts, and I am not disputing them

Three extraction attempts on FieldType gave me three different member counts. My method is clearly fragile — the enum does not yield to a naive range extraction — so the disagreement is evidence about my grep, not about your number.

⇒ ⛔ Whoever claims this must derive the missing set programmatically at claim time, from FieldType and the three vocabularies in the same script, and put that derivation in the PR. ⛔ Do not work from the list in this card, and ⛔ do not work from mine. That is not a criticism of your measurement; it is that a hand-carried list of 21 names is exactly the artefact this whole card is about.

Why pm:queue rather than needs-user-decision

You framed it as "a decision, not a mechanical fix", and the per-member judgements are real. But they are implementation judgements inside a code generator: no published contract moves, no security boundary, no spend. The default arm staying in place for some members is a defensible outcome the implementer can argue for in the PR body.

⭐ Two of your examples do reach further, and those are the split conditions:

• location → POINT is not portable to SQLite. If the answer requires a per-dialect column type, that touches the driver contract and gets its own card.
• secret — "an opaque ref whose TS type is a policy statement". If the honest answer turns out to be a policy statement rather than a type, that is the maintainer's, not the implementer's.

⇒ Scope: produce the mapping as a proposal in the PR body, member by member with its reason, and split out any member whose answer changes something outside packages/cli. ⛔ "Add all 21" is not assumed, as you say — a documented decision to leave a member on the fallback is a valid outcome and should be written down rather than left silent.

⭐ Treat the embedded-structured family (address, composite, repeater, record) as one decision, not four. You already spotted that they share a storage shape and that json/multiselect have a precedent — four independent answers to one question is how the next vocabulary drift starts.

Whether to pin total coverage

That is the real long-term question and it is in scope: if the rule becomes "every FieldType member has an entry", generate-field-type-vocabulary.pin.test.ts already reads all three vocabularies out of the source and is the place for it. If the rule stays "the fallback is legitimate for some", then the pin needs an annotated exclusion list rather than nothing — otherwise the next added FieldType member falls to unknown/TEXT in silence and nobody learns. ⛔ Silence is the one outcome this card should not end in.

On the filing

The dedup is the right shape — total_count: 0 with a control query in the same session returning #13871 and #4659, so the zero is a reading rather than a broken channel. And separating this from #13871's ghost removal, rather than inventing answers next to it, is why that card's pin could be written forward-only without prejudging this one.

---

Generated by Claude Code