docs: record ChatEmbed plan-action exclusion with a pinning test (#6057)

[CrysisDeu]

Problem / Motivation

deriveFollowUpOptions returns followUpIsPlan on every branch, but ChatEmbed destructures only { followUpOptions }, silently dropping it. After #6040 wired plan-action dispatch into ChatPane and ChatPage, ChatEmbed was the one follow-up-rendering host left unsettled: is the drop a defect (same class as #5893) or a deliberate exclusion? Issue #6057 asks to settle and record it.

Why it matters

An unrecorded drop is indistinguishable from an oversight. The next contributor auditing plan-chip coverage either wastes an investigation re-deriving why ChatEmbed is safe, or "fixes" it by wiring dispatch into a surface that structurally lacks the mode gate the dispatch path requires — reintroducing exactly the ambiguity #6040 closed elsewhere.

What changed (motivation → approach → change)

Re-triage on main verified the defect is latent, not live, so this takes the issue's own "if not reachable, record it" branch (Path A) — a documentation-plus-pin change, deliberately NOT the full parity wiring (Path B):

• Comment at the deriveFollowUpOptions destructure in website/src/app-sdk/ChatEmbed.tsx recording the exclusion and why it holds: the slot-detail payload this embed polls carries no mode field (so the embed structurally lacks the orchestrator-mode gate ChatPane/ChatPage consult before dispatching), and _deny_cross_app_slot_access narrows exposure by 404ing app-token embeds on any foreign or unscoped slot. The comment is explicit that the ownership guard alone does not rule out a plan-bearing slot (an app could embed its own orchestrator-mode slot) — the missing mode source is what carries the exclusion. SideChat makes the same exclusion silently; that is stated truthfully rather than claimed as a recorded precedent.
• Pinning test in website/src/test/ChatEmbed.test.tsx asserting a plan-shaped chip stays on the composer-draft path. It pins its own premise (deriveFollowUpOptions(fixture).followUpIsPlan === true, so grammar/fixture drift fails loudly instead of degrading the test into a duplicate of the plain-chip case) and spies the global api client's planAction — the transport a future dispatch wiring would actually use — so a wiring that dispatches AND fills the draft cannot pass.

Path B remains the future parity option: if dashboard-token embeds ever need working plan chips, the wiring is usePlanActionMutation plus a mode source in ChatEmbed. That is a product decision nobody has asked for, and this PR deliberately does not make it (no mode field added to the endpoint, no usePlanActionMutation import, SideChat untouched).

Pre-push adversarial review

Two rounds, two model-pinned blind lanes (GPT + Opus mirrors) per round. Round 1: BLOCK/BLOCK — 4 convergent actionable findings, all fixed (overbroad ownership-guard claim rescoped; false "SideChat records the same exclusion" corrected to "silently makes"; premise assertion added; dead same-mock URL-filter assertion replaced with a real-transport spy). Round 2: PASS/PASS, one Low advisory adopted (spy stubbed so the failing case surfaces as an assertion, not an unhandled rejection).

Tests

• a plan-shaped chip edits the draft and never dispatches a plan action (website/src/test/ChatEmbed.test.tsx) — locks in: (1) the fixture genuinely derives followUpIsPlan=true; (2) clicking the chip lands the label in the composer draft; (3) no call on the embed's own API surface; (4) no call on api.planAction, the global-client transport plan dispatch uses.
• Full file re-run green: 35/35 (npx vitest run src/test/ChatEmbed.test.tsx), plus ChatEmbed.frameless and ChatEmbed.approvalRollback suites. npx tsc -b clean, eslint 0 errors, brand gate green.

Manual verification

N/A — unit coverage sufficient: the change is a comment plus a test; no runtime behavior changes.

Screenshots / video

No UI change, no screenshots — comment + test only, zero visual delta.

Related Issues

Closes #6057

Checklist

• At most two commits (one is the norm), with a Conventional Commits title (feat|fix|docs|refactor|perf|test|chore|ci|build|revert: ...)
• Existing tests pass and new tests added for new functionality
• Self-review completed; code follows project style guidelines
• Documentation updated (if applicable) — the recorded exclusion IS the documentation
• No secrets, credentials, or internal references in the diff

[github-actions]

Design Review (Fable 5) — ✅ PASS

Design-level review of 184de3ab68f8e10bc926c18217cfaf18662ddcdc — updated in place on each push. A BLOCK verdict blocks PR readiness; PASS/CONCERNS are advisory.

Design-Verdict: PASS

A latent-ambiguity record plus a self-premise-pinning test is exactly proportionate — Path B's product wiring is correctly deferred, not half-built.

Suggestions

• The record for SideChat's identical silent drop lives only inside ChatEmbed's comment; a one-line pointer at SideChat's own destructure would keep the next plan-chip audit from re-deriving it there (fine as a follow-up).

[DESIGN-REVIEWED] 184de3a

[github-actions]

UX Review (Fable 5) — ✅ PASS

UX-level review of 184de3ab68f8e10bc926c18217cfaf18662ddcdc — updated in place on each push. A BLOCK verdict blocks PR readiness; PASS/CONCERNS are advisory.

UX-Verdict: PASS

Zero rendered change: the diff adds a code comment and a pinning test; every pixel, string, and flow a user touches is identical to base.

[UX-REVIEWED] 184de3a

[github-actions]

Opus 4.8 Review — ✅ no blocking findings

Reviewed 184de3ab68f8e10bc926c18217cfaf18662ddcdc — this comment is updated in place on each push.

Review details

The diff contains only a comment block addition in ChatEmbed.tsx (no production logic change — the deriveFollowUpOptions destructure is unchanged) and a new test pinning the deliberate plan-exclusion. The discovery pass found no candidates. Nothing in the diff introduces a reachable defect, security hole, crash, or data loss; the only inaccuracies are comment-level (the "whenever onSend is supplied, as it is here" clause, when no onSend is passed), which are style/form and out of scope.

No findings.

[OPUS-REVIEWED] 184de3a

Verdict parsed from the review's SHA-scoped output markers for commit 184de3ab68f8e10bc926c18217cfaf18662ddcdc.

False positive or not applicable? A repository writer can comment:
/ai-review override fable 184de3ab68f8e10bc926c18217cfaf18662ddcdc: <one-sentence reason>

[github-actions]

First Principles Review (Fable 5) — 🟡 CONCERNS

Premise-level review of 184de3ab68f8e10bc926c18217cfaf18662ddcdc — why this exists and whether the shipped surface is the smallest honest version. Updated in place on each push. A BLOCK verdict blocks PR readiness; PASS/CONCERNS are advisory.

All claims verified: four hosts call deriveFollowUpOptions (ChatPane and ChatPage dispatch; ChatEmbed and SideChat both drop followUpIsPlan), api.planAction exists at client.ts:2759, and the diff is comment + test only. The one depth finding is the counted sibling the diff itself concedes.

First-Principles-Verdict: CONCERNS

The record settles ChatEmbed but the identical unrecorded drop survives one grep away in SideChat — half of the named harm remains.

What this change ships

Intent: record that ChatEmbed's silent drop of the plan flag is deliberate, and pin it so nobody "fixes" it — an ADDITION (docs + test), scoped by issue #6057.

1. A comment at ChatEmbed's destructure recording the plan-chip exclusion and why it holds — justified (issue ChatEmbed drops followUpIsPlan — untriaged sibling of #5893's host class #6057 asked for exactly this record).
2. A test pinning that a plan-shaped chip fills the draft and never dispatches — justified; spies the real transport, pins its own fixture premise.

No behavior change, no new public surface, nothing undeclared.

Watch

• Point patch with 1 counted unfixed sibling: grepping followUpIsPlan across website/src shows SideChat (pages/chat/SideChat.tsx:111) drops it identically with no record or pin — the diff's own comment says so ("with no record there"). The description's deferral ground ("a product decision nobody has asked for") covers Path B wiring, not recording SideChat, which is this same-size pattern applied once more; the "next contributor auditing plan-chip coverage" harm the description names is removed for one of the two silent hosts.
• Description says ChatEmbed was "the one follow-up-rendering host left unsettled," which its own comment contradicts — SideChat is equally unsettled. Minor framing drift, same root as above.

Subtractions

• Shrink the ChatEmbed comment by the isPlanAction bullet (ChatEmbed.tsx:110-112): it describes hosts that dispatch, and the file never dispatches — its zero option changes nothing the record needs.

[FIRST-PRINCIPLES-REVIEWED] 184de3a

[github-actions]

GPT 5.6 Review — ✅ no blocking findings

GPT 5.6 completed its review of 184de3ab68f8e10bc926c18217cfaf18662ddcdc and found no blocking issues.

This comment is updated in place on each push.

Review details

No findings.
[GPT-REVIEWED] 184de3a

False positive or not applicable? A repository writer can comment:
/ai-review override gpt 184de3ab68f8e10bc926c18217cfaf18662ddcdc: <one-sentence reason>

[CrysisDeu]

First Principles disposition (head 184de3ab6)

One rationale per finding:

Watch 1 — SideChat's identical drop remains unrecorded: ACCEPTED, routed to follow-up #6754. The finding is correct and the harm is real for the second host. This PR's task scope is pinned to issue #6057, which names ChatEmbed only, and the executing task spec explicitly forbids touching SideChat in this change ("smallest possible diff: one comment block + one test"). Rather than widen a review-ready diff, the same-size pattern (comment + premise-pinned test, Path B still excluded) is filed as #6754 with this lane's finding cited as provenance.

Watch 2 — "the one follow-up-rendering host left unsettled" framing drift: ACCEPTED AS STATED, body left unedited deliberately. The precise framing is "the one host issue #6057 asked to settle"; SideChat is indeed equally unsettled, as the diff's own comment concedes and #6754 now tracks. A PR-body edit re-triggers every pull_request [edited] workflow for a full CI round on an otherwise-green PR, so the correction is recorded here (and in #6754) instead of by editing the description.

Subtraction — drop the isPlanAction bullet: DECLINED. The bullet is deliberately framed as downstream context ("On hosts that DO dispatch… this file never consults it because it never dispatches"), not as one of the facts carrying the exclusion — it answers the reader's next question (what happens to a plan-shaped label that lands in the composer and gets sent?) without which the record invites a "but is the fallthrough safe?" re-investigation. Removing three comment lines would also cost a full CI round on a green head for zero behavioral delta.

[bolichen97]

Approved after a full-diff review (scope match, no out-of-scope files, security surface checked, tests verified non-vacuous). Review notes available on request.