Uh oh!
There was an error while loading. Please reload this page.
feat(console-ai): reviewable "Proposed plan" card before build - #1875
Merged
Conversation
propose_blueprint returns a plan (objects, assumptions, structure-deciding
questions) BEFORE anything is staged. Until now it surfaced only as a bare
"Propose blueprint — Completed" step, so the confirm gate the backend's own
note describes ("present this and call apply_blueprint after they approve or
edit it") had no UI. This adds the Airtable-Omni-style "See the plan, then
approve/adjust" affordance.
- mapMessages: detectProposedPlan lifts the reviewable shape (objects +
field counts, counts line, assumptions, ≤2 questions) from the
blueprint_proposed envelope; defensive (drops malformed objects, derives
counts from the blueprint when omitted, parses the JSON-string result).
Wired onto ChatToolInvocation.proposedPlan.
- ChatbotEnhanced: renders a "Proposed plan" card — summary, object chips
with field counts, a totals line, the agent's assumptions, and any
structure-deciding questions highlighted as the confirm gate, plus an
"approve or adjust" hint. Nothing is live yet. New plan* label props.
- Localized headings: AiChatPage via t(), floating chatbot via locale
(en + zh 方案预览/搭建前请确认/假设).
Verification: 5 new unit tests (detectProposedPlan: lift, JSON-string path
through the mapper, count derivation + malformed-drop, extend-mode targetApp,
non-proposal rejection) — mapMessages suite 37 green; plugin-chatbot +
app-shell type-check clean.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>The latest updates on your projects. Learn more about Vercel for GitHub. |
Contributor
✅ Console Performance Budget
📦 Bundle Size Report
Size Limits
|
Uh oh!
There was an error while loading. Please reload this page.
xuyushun441-sys added a commit
that referenced
this pull request
Jun 22, 2026
… remap server tool-call type (#1877) Two reload regressions on the AI chat surface, both in app-shell's useChatConversation.ts: 1. sanitizeChatMessagesForCache rebuilt cached tool parts WITHOUT the tool `output`. On the readMessageCache fallback (server returns no/partial messages), mapMessages.detectDraftResult / detectProposedPlan had nothing to parse, so the "Review N changes / Publish" card, the ADR-0038 verification chip, and the #1875 "Proposed plan" card silently vanished — only the bare tool header survived. Fix (lean): re-serialize the already-derived draftReview / proposedPlan into a COMPACT, re-parseable `output` envelope — dropping the heavy blueprint (object `fields` / `failed` are materialized only to the length the detectors count). Stored as `output` (a first-class SDK tool-part field, not a custom key) because the AI SDK preserves `output` through useChat init — exactly as the server-backed mergeToolResultsInto path relies on. No mapMessages change: the existing detectors re-parse the compact envelope. 2. toUIMessages passed the server's ModelMessage assistant tool-call part `type:'tool-call'` through verbatim. In the ConsoleFloatingChatbot path (hydratedHistory = uiMessagesToChatMessages, which derives toolName from the part type) this humanized the step title to "Call" instead of "Apply blueprint" / "Propose blueprint". Remap `tool-call` (with a toolName) to `tool-<toolName>`; the result-merge and detectors are unaffected (they key off toolCallId / output). AiChatPage's own mapper reads the toolName field and was already immune. Adds 4 regression tests (round-trip live -> cache -> reload through sanitizeChatMessagesForCache + uiMessageToChatMessage; tool-call remap), verified to fail without the fix. app-shell (576) + plugin-chatbot (118) suites green; type-check + lint clean. Co-authored-by: Jack Zhuang <277994282+os-zhuang@users.noreply.github.com> Co-authored-by: Claude Opus 4.8 <noreply@anthropic.com>
xuyushun441-sys added a commit
that referenced
this pull request
Jun 22, 2026
#1878) #1875 added the propose_blueprint review card (detector + ChatbotEnhanced body + labels) but it never rendered in the product — two wiring gaps that the detector-level unit tests couldn't catch, found by live browser test: 1. ChatbotEnhanced.shouldRenderDetailedTool only routed a tool to the DETAILED body (where the card lives) when it had draftReview items / was awaiting / failed — a propose_blueprint result carries `proposedPlan` but no draftReview, so it was collapsed into the summary CHIP strip and the card block was never reached. Route on `proposedPlan` too. 2. AiChatPage has its OWN history converter (hydratedMessagesToChatMessages, the /ai/build surface) separate from mapMessages (the floating chat). It wired draftReview but not proposedPlan, so the card was dropped on reload there. Lift proposedPlan alongside draftReview, and export detectProposedPlan + ProposedPlan from the package index. Live-verified on the EE rig: a propose-only prompt on /ai/build now renders the "Proposed plan" card (object chips with field counts, totals line, assumptions, confirm-questions, approve hint). Tests: ChatbotEnhanced renders the card for a proposedPlan tool (not a chip); AiChatPage hydration lifts proposedPlan from the merged tool output. plugin-chatbot 119 + app-shell hydration green; type-check clean. Co-authored-by: Jack Zhuang <277994282+os-zhuang@users.noreply.github.com> Co-authored-by: Claude Opus 4.8 <noreply@anthropic.com>
xuyushun441-sys added a commit
that referenced
this pull request
Jun 22, 2026
… gate (#1884) The plan card (#1875/#1878) was read-only — the user had to TYPE "build it" to proceed. Add a one-click gate, matching Airtable Omni's "Build it": - "Build it" button sends an approval message via the existing onSendMessage channel (same path as suggestion chips) → the agent proceeds to apply_blueprint. It's context-aware: when the plan still carries open questions, approval sends an accept-defaults message so a click never silently drops them. - "Adjust" button focuses the chat input so the user types changes in their own words (no canned answer forced on an open-ended plan). - Falls back to the existing static hint when the host hasn't wired onSendMessage. Localized labels + messages on both surfaces (AiChatPage t(), ConsoleFloatingChatbot locale; en + zh 开始搭建/调整方案). Per-question canned quick-replies are intentionally NOT added: propose_blueprint returns free-text questions with no structured options, so "Build it (with defaults)" + type-to-answer is the honest affordance. A structured questions:[{text,options}] from the backend would enable per-question chips later. Verification: 3 new render tests (approve-with-defaults when questions exist, plain approve when none, hint-fallback when sending unwired) — ChatbotEnhanced 40 green; plugin-chatbot + app-shell type-check clean. Co-authored-by: Jack Zhuang <277994282+os-zhuang@users.noreply.github.com> Co-authored-by: Claude Opus 4.8 <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for freeto join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Why
propose_blueprintreturns a plan (objects, assumptions, ≤2 structure-deciding questions) BEFORE anything is staged. Until now it surfaced only as a bare "Propose blueprint — Completed" step, so the confirm gate the backend's own note describes ("present this and call apply_blueprint after they approve or edit it") had no UI. This adds the Airtable-Omni-style see the plan → approve / adjust affordance, on the/ai/buildsurface (#1868).What
detectProposedPlanlifts the reviewable shape (objects + field counts, totals, assumptions, questions) from theblueprint_proposedenvelope — defensive (drops malformed objects, derives counts from the blueprint when omitted, parses the JSON-string result the tool returns). Wired ontoChatToolInvocation.proposedPlan.plan*label props.AiChatPageviat(); floating chatbot via itslocale(en + zh 方案预览 / 搭建前请确认 / 假设).Verification
detectProposedPlan: lift, JSON-string path through the mapper, count-derivation + malformed-drop, extend-modetargetApp, non-proposal rejection) — mapMessages suite 37 green.plugin-chatbot+app-shelltype-check clean (turbo).🤖 Generated with Claude Code