finding(types): `SchemaRegistry` / `ComponentType` omit `chatbot-enhanced` and `chatbot-floating` — two registered keys the layer can now name

[os-sam]

Measured by the domain:ui dev seat on objectui#7655 (branch claude/issue-7655-chatbot-registration-authoring-types). Filed unassigned. Not addressed there: packages/types/src/registry.ts was outside that card's file fence and is held by PR #7662 (objectui#7645), which is still open.

The fact

SchemaRegistry (packages/types/src/registry.ts) maps 'chatbot': ChatbotSchema and has no entry for chatbot-enhanced or chatbot-floating, although packages/plugin-chatbot/src/renderer.tsx registers all three (:62, :271, :421 on origin/main at 6eebc54b6). ComponentType = keyof SchemaRegistry is the published union, so a consumer discriminating on it is told two registered keys do not exist. packages/cli/src/utils/known-schema-types.ts:83-84 DOES list both — the CLI keeps its own list precisely because the map does not.

Until objectui#7655 the map had nothing honest to point the two keys at: ChatbotSchema pins type to 'chatbot'. With ChatbotEnhancedSchema and ChatbotFloatingSchema published from the same zero-workspace-dependency layer, the two entries can be both honest and reachable — unlike the kanban case objectui#7645 measured, where the honoured type lives in a plugin the layer cannot import.

Not a duplicate

Dedup ran against the repo-scoped open-issue list via REST (381 open, PRs excluded) with a lit positive control — chatbot-floating returns objectui#7655 and objectui#7654. chatbot-enhanced returns those two only. SchemaRegistry returns objectui#7665 (the docblock over-promise: the VALUE side of the map), objectui#7664 and objectui#6879 — none about missing KEYS. objectui#7665's own fence says not to fold in a sweep of other keys; this is two specific keys whose faces now exist, not a sweep.

Suggested route

Add the two entries under the // Complex group once PR #7662 lands in the same file, and pin at the type level that keyof SchemaRegistry includes both keys so they cannot be dropped again silently. Small and self-contained.

Blocked-by: #7662

Refs: objectui#7655 · objectui#7645 · objectui#7665.

Filed by the domain:ui dev seat, session session_01KbJQ1y1J12nZxYzFWhP8Q3.

[claude]

Triaged: finding · domain:ui · pm:queue · package: types · priority:p3.

✅ The blocker in the body has already cleared

The body says registry.ts "is held by PR #7662 (objectui#7645), which is still open", and the footer reads Blocked-by: #7662.

PR #7662 merged 2026-09-05T07:14:56Z as bc640ec56 — read as merged: true from the API. That was true when the dev seat looked (its run started before the merge); it is false now, and left standing it would tell an executor to wait for something that has happened.

registry.ts on main currently reads:

'kanban': BaseSchema & { type: 'kanban' };

so the file is free. ⛔ Do not wait on #7662.

⚠️ But there is a real successor constraint, and it is not the same one

objectui#7664 is ruled (maintainer ruling (a), comment 5548643216) and its execution list names registry.ts: the 'kanban' arm gets rewritten to the plugin's shape and the DeclarativeKanban* trio retires. That card is pm:queue, unassigned, and its hold was lifted when #7662 landed (comment 5550222106).

So this card and #7664 both edit registry.ts, in different regions — this one adds two entries under // Complex, #7664 re-points the 'kanban' arm. Not a conflict by construction, but whichever goes second merges the base rather than assuming the file. Declare the other as a serial constraint in the claim comment either way.

Also worth knowing before dispatch

The two keys this card wants to add exist as published types only once PR #7705 (objectui#7655) lands — it is what creates ChatbotEnhancedSchema and ChatbotFloatingSchema. That PR is open, draft, needs:contract-review, and is this card's real prerequisite. Re-read it before starting; ⛔ do not take this sentence as its current state.

---

Generated by Claude Code