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

[os-justin]

Claim: PM loop R3 (objectui domain:ui PM seat) — wave of 5, slot 4/5
Session: session_01YBWFb5YgMU5dw8p2VKj16S
Branch: claude/issue-7704-schema-registry-chatbot-keys
Worktree: objectui-issue-7704
Domain: domain:ui · package: types
Clause-②: yes. Adding two entries to SchemaRegistry widens the published ComponentType union (ComponentType = keyof SchemaRegistry). That is a public-face change, not a spelling.

Tier: TIER_FLOOR='sonnet' · TIER_DEFAULT='opus' · CONTRACT_REVIEW_TIER='claude-fable-5-1' (read from objectstack:scripts/pm/dispatch-gates.mjs:10023). Clause-② binds the enqueue gate to CONTRACT_REVIEW_TIER; claude-fable-5-1 is measured unavailable to this session (rate_limit HTTP 429 on a dispatch at that tier) ⇒ quota-exhaustion exemption ⇒ opus = TIER_DEFAULT, ⛔ no lower, carrying needs:contract-review as the compensating control. ⛔ Does not enqueue while that label is on it.

⭐ Blocked-by: #7662 is RELEASED. PR #7662 merged 2026-09-05T07:14:56Z (fix(types): SchemaRegistry's kanban entry stops describing a component it cannot name), closing objectui#7645. ⇒ this card is unblocked; the file is free.

Premise re-verified by this seat on origin/main = 21d7989fb:

packages/types/src/registry.ts:203    'chatbot': ChatbotSchema;
packages/types/src/complex.ts:1308   export interface ChatbotEnhancedSchema
packages/types/src/complex.ts:1390   export interface ChatbotFloatingSchema
packages/cli/src/utils/known-schema-types.ts:83-84   'chatbot-enhanced', 'chatbot-floating'

chatbot-enhanced / chatbot-floating in registry.ts: 0 hits. Lit control on the same file, same read: the map declares 69 entries. ⇒ the zero is a reading. ⭐ And the card's central claim holds on today's tree: both faces are declared in @object-ui/types itself (complex.ts:1308 / :1390, from #7655/PR #7705), so the two entries can be both honest and reachable — unlike the kanban case #7645 measured, where the honoured type lived in a plugin this zero-workspace-dependency layer cannot import. The CLI's parallel list at known-schema-types.ts:83-84 is the evidence that the map is the half that is wrong.

Boundaries:

• ✅ Add the two entries under the // Complex group, and pin at the type level that keyof SchemaRegistry includes both keys, so they cannot be dropped again silently. ⚠️ That pin is the real deliverable — without it this card can regress invisibly, which is how it arose.
• ⛔ Do not sweep other keys. objectui#7665's own fence forbids folding a general sweep in; this is two specific keys whose faces now exist. ⛔ Do not answer finding(types): SchemaRegistry['kanban'] names the declarative schema, but the renderer registered for kanban honours the plugin's — the map's value does not describe the component it names #7645's generalization question (does every SchemaRegistry value have to be the type its renderer honours) — that lives on SchemaRegistry's docblock promises more than the layer can deliver — it owns the key set, not the values #7665.
• ⛔ Region fence — slot 3/5 of this same wave (finding(types/plugin-chatbot): six ChatbotSchema keys are declared and read by no registration — loading, showAvatars, userAvatar, assistantAvatar, markdown, height #7703) holds packages/types/src/complex.ts and zod/complex.zod.ts, where it is retiring six ChatbotSchema members. This card owns packages/types/src/registry.ts and its own new pin, and nothing else in packages/types. ⛔ Do not edit complex.ts (import from it only). ⛔ Do not add a zod-mirror-parity ledger row — that file is finding(types/plugin-chatbot): six ChatbotSchema keys are declared and read by no registration — loading, showAvatars, userAvatar, assistantAvatar, markdown, height #7703's if the suite demands one.
• ⚠️ finding(types/plugin-chatbot): six ChatbotSchema keys are declared and read by no registration — loading, showAvatars, userAvatar, assistantAvatar, markdown, height #7703 does not move ChatbotEnhancedSchema or ChatbotFloatingSchema — it retires members of ChatbotSchema, a different interface — so the two slots do not collide semantically either. If the dev measures otherwise, it ⛔ stops and reports.
• ✅ Changeset @object-ui/types: minor.

The queue arbitrates.

---

Generated by Claude Code

[os-justin]

os-dev-report

{
  "issue": 7704,
  "status": "done",
  "branch": "claude/issue-7704-schema-registry-chatbot-keys",
  "pr": "https://github.com/objectstack-ai/objectui/pull/8145",
  "premise_still_valid": true,
  "summary": "Added 'chatbot-enhanced': ChatbotEnhancedSchema and 'chatbot-floating': ChatbotFloatingSchema to SchemaRegistry under the // Complex group, so the published ComponentType = keyof SchemaRegistry union names all three plugin-chatbot registrations. Both entries are honest and reachable: each value pins `type` to its own key, each registration already takes that exact type as its `schema` parameter (renderer.tsx:256, :394), and both faces are declared in @object-ui/types itself, so this zero-workspace-dependency layer imports no plugin. The real deliverable is the type-level pin, packages/types/src/__tests__/schema-registry-chatbot-keys-7704.test.ts, which holds the keys in two channels: COMPILE-TIME (tsc -p tsconfig.test.json, chained off the package's type-check script) and RUNTIME (a TypeScript-AST census of the interface source plus each key selecting its own arm through safeValidateSchema). PM Zone-2 premise re-verified on origin/main = 21d7989fb and it holds; the Zone-1 release of Blocked-by: #7662 also holds -- registry.ts on main already carries #7664's reworked 'kanban': KanbanSchema arm, so the file was free. No semantic collision with the concurrent #7703: it retires ChatbotSchema members, and the two faces named here pick only ChatbotSharedKey plus maxHeight / processVisibility. Region fence honoured -- exactly three files, additive only (288 insertions, 0 deletions), complex.ts and zod/complex.zod.ts untouched (imported from only), and no zod-mirror-parity ledger row added. Changeset is @object-ui/types: minor. PR left DRAFT with needs:contract-review attached per Clause-2; label read back and confirmed as the union ['package: types','tests','needs:contract-review'] with nothing stripped by the auto-labeler.",
  "tests": "All measured on final commit 8c1c4019d; every exit code captured before any pipe (cmd > log 2>&1; EXIT=$?), and each verdict quoted is the tool's own printed line. GREEN -- pnpm --filter @object-ui/types build: os-verify-lock VERDICT command-exit 0, 'dist completeness: 1 package(s) complete (124 emitted files verified)'. pnpm exec vitest run packages/types/: VERDICT command-exit 0, 'Test Files 134 passed (134) / Tests 2505 passed (2505)'. pnpm --filter @object-ui/types type-check: exit 0 (tsc --noEmit + tsconfig.examples.json + tsconfig.test.json); proved my pins are IN that program with tsc -p tsconfig.test.json --listFiles -- the new file is line 440 of 595, so this is a measurement and not NOT MEASURED. Gates exit 0: check:control-bytes ('scanned 6511 tracked text file(s)'), check:phantom-deps ('Every in-scope import is declared by the package that publishes it' -- the gate that caught the kanban attempt, re-measured green as the PM asked), check:unreferenced-sources, check:doc-types ('889 type literal(s) against 658 registered key(s)'), check:self-import, check-changeset-presence, check-changeset-no-major, check-changeset-fixed, check-changeset-overwrite, check-type-check-coverage ('42/42 packages compile their tests'), check-lint-coverage ('46/46 packages linted'). check-governed-queue-guard --test on the three paths: 'NOT GOVERNED -- 3 path(s) checked against 5 governed surface(s); none matched'. Also self-scanned grep -naP '[\\x00-\\x08\\x0b\\x0c\\x0e-\\x1f\\x7f]' over the three touched files: no hits. ABLATION (the pin is lit, and it is per-key): implementation committed FIRST, then two mutation legs, each with a trap '<restore>' EXIT INT TERM using absolute paths from git rev-parse --show-toplevel and restoring via git checkout HEAD -- <path> (never a bare checkout). On-disk mutation proven per leg by grep -cF on the exact removed text (before=1, after=0) plus git hash-object showing the blob moved off HEAD eb39756db. Leg A, drop 'chatbot-enhanced': tsc exit 2 with exactly 4 errors in the pin file, all naming chatbot-enhanced -- TS2344 at (90,37) 'Type false does not satisfy the constraint true' and TS2339 at (96,60)/(103,59)/(116,78) 'Property chatbot-enhanced does not exist on type SchemaRegistry'; vitest exit 1, 2 census tests fail. Leg B, drop 'chatbot-floating': symmetric, tsc exit 2, 4 errors at (91,37)/(97,60)/(104,59)/(119,78) all naming chatbot-floating; vitest exit 1, 2 fail. Neither leg reddens the other key's pins, so the pins are per-key rather than one blanket check. Both restore legs proven by BLOB HASH back to eb39756db and 'git diff HEAD -- registry.ts is empty: YES', and final git status --short was empty. No dist preflight was owed: registry.ts emits no runtime code and both channels read source (tsc compiles src, the test imports ../index relatively), so no build sits between mutation and observation. CROSS-PACKAGE REVERSE VERIFICATION against the rebuilt .d.ts (not cache): @object-ui/types rebuilt, dist/registry.d.ts:89-91 carries all three keys; probed from packages/plugin-chatbot resolving @object-ui/types BY PACKAGE NAME so the read goes through dist. Positive leg (ComponentType = 'chatbot-enhanced' / 'chatbot-floating' and both SchemaRegistry[key]['type'] reads): tsc exit 0. Negative leg (ComponentType = 'chatbot-does-not-exist'): tsc exit 2, TS2322 'Type \"chatbot-does-not-exist\" is not assignable to type keyof SchemaRegistry' -- so the union is a real literal union, not widened to string, which is what makes the positive leg mean anything. First attempt at both legs exited 1 for the SAME wrong reason (TS5112, tsconfig-vs-CLI), i.e. NOT MEASURED; re-run with --ignoreConfig produced the readings above. Probe files removed and git status confirmed clean. DECLARED NARROWINGS (CI runs the full farm): turbo ls --affected reports 43 packages because @object-ui/types is the graph root, but that is a graph-shape artifact, not a runtime risk surface -- the changed file emits NO runtime code (dist/registry.js is 'export {}', 207 bytes of licence header), and the only reference to SchemaRegistry or ComponentType anywhere outside packages/types is two COMMENTS (plugin-kanban/src/types.ts:28, app-shell/src/layout/AppSidebar.tsx:251), so no downstream code consumes either symbol. eslint narrowed with all three pieces of evidence: (1) population read from eslint's own config, files ['**/*.{ts,tsx}'] minus its ignores = 4265 tracked files; (2) file count read from --format json = 2 files, 0 errors, 0 warnings, exit 0; (3) invariance -- the config declares no parserOptions.project and no projectService (0 occurrences), so type-aware linting is off and this diff cannot move the verdict of any untouched file. NOT MEASURED (read as neither green nor red): check:sdui-registration-pins prints 'No console build to weigh at apps/console/dist/assets. This is exit 2, not a pass' -- prerequisite is a console build; check:readme-exports exit 1 with 484 findings, of which 481 are 'its type entry ./dist/index.d.ts is not on disk -- run pnpm build first' and the other 3 are floor failures caused by that same absence ('packagesRead: found 2, floor is 25'), with ZERO findings naming packages/types. Both need a full workspace build and neither can be moved by a diff that adds no registration and no README line; declared to CI.",
  "mcp_calls": "8 -- 2 issue reads on #7704 (body + all comments), 1 failed get_labels on the PR (the labels reader does not resolve a PR number), create_pull_request, 2 pull_request_read (pre-write label read + post-write comparative read-back), issue_write for the label union, and this report comment. Card and comment reads went through MCP because the REST channel is CLOSED to this seat: an authenticated probe of GET /repos/objectstack-ai/objectui/issues/8145/labels returned HTTP 403 'GitHub access is not enabled for this session. An org admin must connect the Claude GitHub App for this organization.' (unauthenticated: also 403), and no gh CLI is installed (gh: command not found). CHANNEL SWITCH DECLARED: the label write could therefore not use the additive POST .../issues/<n>/labels endpoint, so it went through the MCP fallback -- read current set, union, whole-group write, mandatory comparative read-back. Read-back diff of union(read set, target) against the live set: identical, ['package: types','tests','needs:contract-review'], nothing stripped by the auto-labeler. No dedup search was run because there is nothing to file.",
  "open_questions": [],
  "out_of_scope_findings": []
}

---

Generated by Claude Code

[os-justin]

MERGED — PR #8145 landed through the merge queue as squash 20316bac3 on main (2026-09-06T21:0xZ). Card auto-closed by Fixes.

Verified by CONTENT, against a control proven to fire BEFORE the merge — ⛔ not by sha, ⛔ not by the PR's merged flag:

read	pre-merge	post-merge
'chatbot-enhanced': ChatbotEnhancedSchema; on main	0	1
'chatbot-floating': ChatbotFloatingSchema; on main	0	1
the same greps on the PR branch	1 / 1	—
packages/types/src/registry.ts line count on main (instrument live?)	209	—
'chatbot': ChatbotSchema; — the entry this card must not re-point	—	1 (unchanged)
negative control 'chatbot-zzz'	—	0
the new pin file on main	—	209 lines

⇒ the pre-merge zeros were readings on a live file, and the post-merge ones are the landed change. git log origin/main: 20316bac3 fix(types): SchemaRegistry names all three chatbot registrations (#8145) at the tip.

State transition in this stroke (domain:ui @ objectui PM seat, session_01YBWFb5YgMU5dw8p2VKj16S): pm:dispatched stripped, assignee cleared. The claim on this card is released.

What this round is worth recording for

⭐ The pin is per-key, and that was proven rather than asserted. Dropping either entry reddens 4 tsc errors and 2 vitest tests naming only that key, and ⛔ does not redden the other's pins. A single blanket "both keys exist" check would have passed the same ablation while being half as strong.

⭐ Two channels, and the file says which is which. The compile-time block is erased before vitest runs, so a green vitest is not evidence about it — stated in the docblock with the precedent files named. That confusion has cost this repo before; pre-empting it in the artefact is the right place.

⭐ The honesty pin carries its own falsifiability leg. _HonestyCanFail asserts that the pre-#7655 value (ChatbotSchema['type'] = 'chatbot') is not either new key. An honesty assertion that cannot fail is decoration; this one can.

⭐ Cross-package reverse verification through the rebuilt .d.ts, resolving by package name so the read goes through dist, with a negative leg ('chatbot-does-not-exist' → TS2322) proving the union is a real literal union and not widened to string. Without that leg the positive leg would mean nothing.

⭐ Two gates declared NOT MEASURED came back green on CI (check:readme-exports, check:sdui-registration-pins) — confirming the declaration was an honest prerequisite failure, ⛔ not a red reported as unmeasurable.

One judgement recorded, ⛔ not silently tidied: the pin docblock and PR body cite the chatbot registration at renderer.tsx:62; it is at :60. The two keys this card adds are cited exactly (:241, :379, :256, :394). A two-line drift in a comment, on the one key the diff does not touch, still lands a reader in the same ComponentRegistry.register('chatbot', call ⇒ a patch round and a full CI cycle would be disproportionate.

Scope held: two keys, not a sweep. objectui#7665 still owns the map's docblock over-promise and the other entries; objectui#7645's generalization question (must every SchemaRegistry value be the type its renderer honours?) is ⛔ not answered here.

---

Generated by Claude Code