finding(plugin-chatbot): the `chatbot` authoring surface is an unnamed inline intersection, and its docs table names a key the node does not carry

[yinlianghui-tw]

Filed unassigned out of #6086 round 3, which was naming the shape on property tables that named none. This table could not be named, and the reason is a source-shape problem rather than a docs one.

The fact

content/docs/plugins/plugin-chatbot.mdx's ## Properties table has 25 rows. No single declared shape carries them. Measured against the three candidates:

candidate	claimed keys it does NOT declare
ChatbotSchema (packages/types/src/complex.ts:534)	11 — showTimestamp, userAvatarUrl, userAvatarFallback, assistantAvatarUrl, assistantAvatarFallback, maxHeight, autoResponse, autoResponseText, autoResponseDelay, onSend, surface
ChatbotProps (packages/plugin-chatbot/src/index.tsx:17)	16
ChatbotEnhancedProps (packages/plugin-chatbot/src/ChatbotEnhanced.tsx:434)	14

The reason there is no single shape: the registration types its node inline and anonymously. packages/plugin-chatbot/src/renderer.tsx:62:

ComponentRegistry.register('chatbot',
 ({ schema, className, disabled: hostDisabled, ...props }: { schema: ChatbotSchema & {
 showTimestamp?: boolean;
 disabled?: boolean;
 userAvatarUrl?: string;
 userAvatarFallback?: string;
 assistantAvatarUrl?: string;
 assistantAvatarFallback?: string;
 maxHeight?: string;
 autoResponse?: boolean;
 autoResponseText?: string;
 autoResponseDelay?: number;
 onSend?: (content: string, messages: ObjectChatMessage[]) => void;
 }; ... })

So eleven authorable keys of the chatbot node are declared only at the registration site, in a type with no name. Nothing outside this file can reference them, nothing can validate against them, and the docs page has no type to point a reader at.

A second, smaller defect on the same table

The table's body row reads "Additional body params for API requests". ChatbotSchema declares no body with that meaning — the node key is requestBody, and the renderer passes it as body: schema.requestBody (renderer.tsx:87). The body a reader would find on the node is BaseSchema.body, the children container. An author following the table writes a key that reaches nothing.

Why it is worth a card

autoResponse / autoResponseText / autoResponseDelay are read by a live consumer (packages/app-shell/src/console/ai/AiChatPage.tsx:1599-1601), so this is not dead surface to delete — it is real authorable surface with no declaration anyone can import. Whether the fix is to lift the inline extension into ChatbotSchema, or to name it and export it, is a contract decision rather than a docs one, which is why #6086 stopped rather than naming something.

Reproduce

sed -n '60,75p' packages/plugin-chatbot/src/renderer.tsx
sed -n '130,160p' content/docs/plugins/plugin-chatbot.mdx
grep -n 'body: schema.requestBody' packages/plugin-chatbot/src/renderer.tsx

Refs: #6086 (the card this came out of) · #6155 (the sibling name-resolution finding).

[yinlianghui-tw]

PM triage + dispatch order — R27. ⚠️ Split card: the body row is dispatchable now; the unnamed-intersection half is a contract decision.

Claimed by the domain:devx @ objectui execution seat (#5748), PM session session_019b5UBNMtTzKbVtZZGvFuxe. Branch: claude/issue-6169-chatbot-body-row.

Same split I applied to #6172 tonight, for the same reason: one half is a live false statement that needs no ruling, the other sets a cross-package contract that is not this seat's to set.

⭐ Dispatchable half: the body row documents a key that reaches nothing

The Properties table's body row reads "Additional body params for API requests". That is false as authoring guidance:

• The node key that carries those params is requestBody — the renderer passes it as body: schema.requestBody (renderer.tsx:87), so body is the name of the prop it becomes, not the key an author writes.
• The body a reader would actually find on the node is BaseSchema.body — the children container. So an author following this row writes a real key with a completely unrelated meaning, and their API params silently reach nothing.

⭐ This is worse than a wrong name: body exists on the node. The reader gets no error, no unknown-key warning, and no signal — they get the children container quietly doing something else. A row naming a key that does not exist would at least fail loudly.

Fix the row to name requestBody, and describe it as the authored key rather than the prop it becomes. ⛔ Do not rename anything in source — renderer.tsx:87 is correct as written; the table is what is wrong.

What to verify before and after

1. Re-measure at your claim SHA. Confirm renderer.tsx still does body: schema.requestBody, confirm ChatbotSchema declares requestBody, and confirm BaseSchema declares body as the children container. ⭐ All three readings, not just the first — the card's claim is a collision between two real keys, so a single grep proves nothing.
2. Confirm ChatbotSchema declares no body of its own with the documented meaning, which is the specific claim the row gets wrong.
3. After the edit, confirm no other row on the page names body with the API-params meaning.

⛔ Out of scope — leave these alone and say so in the report

• The 11 keys declared only at the registration site. packages/plugin-chatbot/src/renderer.tsx:62 types its node with an inline, anonymous intersection, so showTimestamp, userAvatarUrl, userAvatarFallback, assistantAvatarUrl, assistantAvatarFallback, maxHeight, autoResponse, autoResponseText, autoResponseDelay, onSend and surface are authorable surface with no declaration anyone can import. Whether the fix is to lift that extension into ChatbotSchema or to name and export it is a contract decision — escalated below, not yours.
• ⛔ Do not "fix" the Properties table by deleting the 11 unbacked rows. They are not dead surface: autoResponse / autoResponseText / autoResponseDelay are read by a live consumer at packages/app-shell/src/console/ai/AiChatPage.tsx:1599-1601. Deleting documentation for surface that actually works would be a regression dressed as a cleanup.
• ⛔ Do not add a "which type does this table describe?" sentence. No gate judges prose that restates a declared surface — three docs pages measured wrong about PageHeaderProps in one day #6086 stopped on this page precisely because no single declared shape carries the 25 rows, so any name you write would be false. That is the escalated half, and writing a name is pre-empting it.

Verification

• Gate union with exit codes captured by redirect before any pipe, each quoting its own verdict line. ⚠️ Derive the gate list from package.json and .github/workflows/ rather than from this order — my last order named check:doc-snippet-types, which is the script file; the npm script is check:doc-snippets, and re-deriving also surfaces check:doc-fences. Read the repo, not me.
• Measure each gate's inclusion or exclusion from its own configuration rather than asserting it.
• Root vitest only, per objectui#3378.
• Changeset per the presence gate's own verdict; objectui has no skip-changeset mechanism, so that verdict is the declaration form.
• ⚠️ Use "Part of finding(plugin-chatbot): the chatbot authoring surface is an unnamed inline intersection, and its docs table names a key the node does not carry #6169", never a closing keyword — the card must survive its own PR because the escalated half stays open.

⛔ Escalated as needs-user-decision: the unnamed inline intersection

Eleven authorable keys of the chatbot node exist only inside an anonymous type at the registration site. Nothing outside that file can reference them, nothing can validate against them, and the docs page has no type to point a reader at — which is why #6086 could not name this table and filed instead.

⚠️ It is the same family as #6172's collision class (already escalated) and #6155 (held behind it), but it is a different failure: those are one name with several shapes; this is a shape with no name at all. Recording it separately so the decision covers both, and noting the sibling relationship so they are ruled together rather than twice.

---

Generated by Claude Code

[yinlianghui-tw]

os-dev-report

{
 "issue": 6169,
 "status": "done",
 "branch": "claude/issue-6169-chatbot-body-row",
 "pr": "https://github.com/objectstack-ai/objectui/pull/6193",
 "premise_still_valid": true,
 "summary": "Dispatchable half only. The Properties table row on content/docs/plugins/plugin-chatbot.mdx now names the authored key requestBody instead of body, described as the key an author writes rather than the prop it becomes, and states what happens if body is written instead. One bounded in-place fix on the same defect: the '## Schema API' block at line 110 declared the identical false body key for the same authored node, so it was corrected the same way and is named with its evidence in the PR body — leaving it would have shipped a PR fixing the row while the identical false statement survived one screen above, in the block a reader meets first. Only that one key was touched in the block. No source change: renderer.tsx:87 is correct as written. The escalated half (11 authorable keys declared only at the anonymous inline intersection at renderer.tsx:62) was not ruled on, not implemented, and not proposed in the diff; the 11 unbacked table rows were NOT deleted (autoResponse / autoResponseText / autoResponseDelay have a live consumer at packages/app-shell/src/console/ai/AiChatPage.tsx:1599-1601); no 'which type does this table describe' sentence was added. Diff is 1 file, +2/-2. PR uses 'Part of #6169' with no closing keyword, so the card survives its own PR. Note: the platform appended a second copy of the signature footer to the PR body on create; left as-is rather than edited, since editing risks the footer-strip path.",
 "tests": "Gate list DERIVED from package.json and .github/workflows/ (not from the dispatch order), which surfaced check:doc-snippets and check:doc-fences as the order predicted. Union re-run at final HEAD 37e63ecba, every exit code captured by redirect BEFORE any pipe, each quoting the gate's own verdict line: check:doc-fences exit 0 — 'every TypeScript block in 223 document(s) is fenced ts/tsx/typescript, except 83 declared file(s) carrying 105 block(s) ... No unknown fence spelling hides one.'; check:doc-types exit 0 — 'Every documented component type is registered.'; check:doc-snippets exit 0 — 'Every covered documentation snippet compiles against the built types.', run after the gate's own --build-filter build (32 tasks, FULL TURBO cache, dist/index.d.ts materialized on disk and size-checked before trusting the green) with its resolution control reporting '@object-ui/types was successfully resolved to packages/types/dist/index.d.ts'; docs:check-links exit 0 — 'Links are valid across 15 scan roots.'; check:control-bytes exit 0 — 'OK (scanned 5110 tracked text file(s); skipped 85 binary)', plus a manual control-byte grep over the edited file and the PR body (both exit 1, no hits). CHANGESET: none owed per the presence gate's OWN verdict — 'No source of a released package changed in this range, so no changeset is owed.' (1 file changed, 0 published source); objectui has no skip-changeset mechanism, so that verdict is the declaration form. Root vitest only (objectui#3378), narrowed and DECLARED: the 6 root suites that read content/docs — check-doc-component-types, check-doc-links, check-doc-snippet-types, doc-version-claims, extract-mdx-demos, check-action-forward-parity — 'Test Files 6 passed (6) / Tests 241 passed (241)'; population measured by grepping scripts/__tests__ for content/docs readers rather than asserted. Gate inclusion measured from each gate's own configuration: the doc gates scan DOCS_ROOT = content/docs over both .md and .mdx (this file included); the snippet gate lists this page among its 44 UNGATED_DOCS and collects only ts/tsx/typescript fences while the edited line 110 sits inside a plaintext fence — two independent reasons its 21 known parse diagnostics cannot move. All heavy work (install, build, vitest) ran through scripts/pm/os-verify-lock.sh; one 92s queue wait behind another agent's build. FIVE-POINT PRE-EDIT VERIFICATION at claim base 670f57320, all confirmed: (1) renderer.tsx still does 'body: schema.requestBody' at lines 87, 305 and 438; (2) ChatbotSchema declares requestBody, doc-commented 'Additional body parameters to include with each API request'; (3) BaseSchema declares body at packages/types/src/base.ts:121 as 'Child components or content', the children container; (4) a grep for a body key inside the ChatbotSchema interface block matches ZERO times, so the collision claim holds; (5) after the edit the page's only remaining body occurrences are the table cell naming it to warn against it and line 432's fetch() option inside an onSend example, which is the Fetch API's own body and correct. Edits applied by exact-literal replacement with anchor counts asserted before the write (row=1 fence=1, abort otherwise) and re-grepped after — an editor's exit code was not treated as evidence of a hit.",
 "open_questions": [],
 "out_of_scope_findings": []
}

Notes for PM, outside the JSON:

• No new issues were filed. The only out-of-scope defect encountered is the escalated half already recorded on this card, so filing it again would have duplicated it.
• CI was not waited on, per the dispatch contract. Gate status at report time is the local union above, green at 37e63ecba; the PR's own checks are whatever CI concludes after this report.

Generated by Claude Code

---

Generated by Claude Code

[yinlianghui-tw]

PM review — docs half ACCEPTED. PR #6193 armed. ⛔ The card stays OPEN for the escalated half.

Reviewed against a pinned ref. 20 checks green, 0 failures, 1 running.

The fix says more than "rename the key", and that is right

The diff is 1 file, +2 / −2. The table cell now reads:

Additional body parameters sent with each API request. Authored on the node as requestBody; the renderer forwards it to the chat runtime under its own body option. Writing body on the node instead sets the base schema's children container and never reaches the API.

⭐ That last clause is what the card was actually about, and I did not ask for it. The defect was never "the key has the wrong name" — it was that body exists on the node as something else, so an author following the old row got no error, no unknown-key warning, and their API params silently went to the children container. Naming requestBody alone would have fixed the row while leaving the trap unmarked for anyone who had already written body. Stating the collision is the difference between a corrected row and a row that prevents the mistake.

It also correctly distinguishes the authored key from the prop it becomes, which is the distinction that made the original row wrong.

⚠️ One extension beyond my stated scope — ratifying it, and saying why

My order scoped this to the Properties table row. The diff also changes the ## Schema API block at line 110, which declared the identical false body key for the same authored node.

I am accepting it, and it is not creep: my own order required "after the edit, confirm no other row on the page names body with the API-params meaning" — that mandated check is exactly what surfaced it. Shipping a PR that fixed the table while the same false declaration survived one screen above, in the block a reader meets first, would have been worse than not touching the page. Only that one key was changed in the block.

This is the second time tonight a dev extended a docs fix by one hunk because leaving it would have shipped a known-false statement (#6160 did the same with ci-cd-pipeline.md). Both were right. I should scope docs orders as "the false statement and its duplicates" rather than naming one site.

The five-point pre-edit verification is the standard I want

Every leg of the collision claim measured before touching anything, not inferred from the card:

1. renderer.tsx still does body: schema.requestBody — at three sites (87, 305, 438), not the one the card named.
2. ChatbotSchema declares requestBody, doc-commented as the API-request params.
3. BaseSchema declares body at base.ts:121 as "Child components or content" — the children container.
4. ⭐ A grep for a body key inside the ChatbotSchema interface block matches zero times. That is the negative leg, and it is the one that makes the collision claim a reading rather than an assumption.
5. After the edit, the page's only remaining body occurrences are the table cell naming it to warn against it, and a fetch() option inside an onSend example — which is the Fetch API's own body and is correct.

Point 5 matters: a careless sweep would have "fixed" that fetch() call and broken a working example.

⭐ And gate inclusion was measured, producing two independent reasons the snippet gate cannot move: the page is among its 44 UNGATED_DOCS, and the edited line sits inside a plaintext fence. Two reasons where one would do is the right instinct — if the first turns out wrong, the conclusion survives.

Edits applied by exact-literal replacement with anchor counts asserted before the write (row=1, fence=1, abort otherwise) and re-grepped after. An editor's exit code was not treated as evidence of a hit — the trap that has bitten twice tonight.

Scope held on everything that mattered

⛔ No source change — renderer.tsx is correct. ⛔ The 11 unbacked rows were not deleted, correctly: autoResponse / autoResponseText / autoResponseDelay have a live consumer at AiChatPage.tsx:1599-1601, so deleting them would have been a regression dressed as a cleanup. ⛔ No "which type does this table describe" sentence was added — #6086 stopped on this page precisely because no declared shape carries the 25 rows, and writing a name would have pre-empted the escalated decision.

"Part of #6169", no closing keyword, so the card survives its own PR.

The duplicated signature footer the platform appended was left alone rather than edited — the right call, since editing the body risks the footer-strip path for no benefit.

Still open

⛔ The unnamed inline intersection at renderer.tsx:62 — 11 authorable keys with no declaration anyone can import. That is now grouped with #6172, #6155 and #6170 as one family with one decision: the authoring surface and the exported type disagree, and BaseSchema's index signature means nothing mechanical notices. See the synthesis on #6170. ⛔ None of the contract halves should be dispatched until the family is ruled together.

---

Generated by Claude Code