Two fixes to the planning conversation: draggable commons chips, and a readiness check instead of a vanished button

[debtn]

Two independent changes to the plan-mode conversation, one commit each. They can be read separately.

---

1. Drag a "Drew on the commons" chip into the message to build on it

A plan reply that leans on a commons entry shows it as a chip under the reply — Drew on the commons: Mutual Aid Pod — and until now the chip did one thing: open the gallery card. Saying "yes, that one, build on it" meant retyping the title and hoping the next turn's retrieval surfaced the same entry again. In the first planning exchanges, where entries are being weighed against each other, that was the whole conversation.

The chip now drags. Dropped anywhere on the composer it lands as an @[Title] mention at the caret, padded so it never fuses with the word beside it, with the same dashed drop target the image drop uses and its own copy ("Drop to build on this commons entry"). A text/plain twin rides along, so a drop on any ordinary text field still lands as the token. Typing @ offers the surfaced entries too, alongside your apps — so the same reference is one tap on a phone, where nothing drags.

The mention is a promise, not a hint

At send time an @[Title] that names a surfaced commons entry pins it into the same Relevant Knowledge from the RT Commons section retrieval fills — first, with the strongest match and its full text (bounded, like retrieval's own deepening) — whatever this turn's search happened to score.

• Retrieval's copy of the same entry steps aside (deduped by slug)
• The build log records the pin as its own retrieval line ("referenced directly (…)"), so the report's provenance can credit it
• The reply's own chips and commons_mentions count it like any surfaced entry
• A short Referenced Commons Entry section names the intent ("the builder pointed at this directly") so the model knows it was chosen, not merely found

Surfaced entries are read from the messages' commonsRefs rather than a side registry, so a reloaded chat still knows what it drew on. The mention popover re-lists on each open, since the set grows as the chat goes.

Files: src/knowledge/mentions.ts, src/components/Chat/MessageList.tsx, src/components/Chat/MessageInput.tsx, src/components/Chat/ChatPanel.tsx

Driven in Chromium, with commons detail reads stubbed: the chip drags and lands as the token; a second chip pads beside typed text; a repeat drag is a no-op; the overlay copy shows mid-drag; @mut offers Mutual Aid Pod · commons; pinnedCommonsEntries resolves to { match: 'both', similarity: 1, body_excerpt: 1400 chars }, and an unknown title or no mention pins nothing.

---

2. Ask if they're ready to build, instead of pointing at a button that left

The bug. The invitation outlived the button. A drafted plan landed with Build this plan under it, and then the person did what plan mode is for — "can we add a way for neighbors to say which tools they lend?" — and the refinement came back as a short conversational reply. The action was pinned to a last message shaped like a plan document, so it vanished with the document, while the prompt kept telling every reply to end by inviting them to press it. The reply said press Build this plan; there was nothing to press.

The action belongs to the plan, not to one message

Once a plan document has been drafted, every settled plan reply carries the action, and it stays until the plan is built. That is honest rather than convenient: the build send carries the whole conversation, so "the plan above" has always meant the plan as it now stands — refinements included — not the first draft of it. Refinements made after the plan document are already incorporated; they always were.

The one exception is a reply that asked questions, which wants answers rather than approval. That rule already governed existing projects and now governs both, so there is one rule instead of two.

The better half is not needing the button

Refinement replies now close by asking — "Anything else to change, or ready to build?" — as a one-tap card, using the answer-card machinery plan questions already render. Its yes is not an answer to relay: tapping Ready to build starts the build, rather than spending a whole reply to say "yes" and get a button offered back. So the readiness question hides the action while it is open, and is the press while it stands. "Something else…" sits beside it for another change.

Both doors open the same way (build-from-plan.ts): mode flips, the build message rides the queue plan answers already use — one send path, not two. A phrasing the matcher doesn't recognise sends as an ordinary answer and the action is still underneath, so a miss costs a round trip, never a build nobody asked for.

Files: src/components/Chat/build-from-plan.ts (new — one definition of what building the plan means), src/components/Chat/MessageList.tsx, src/components/Chat/ChatPanel.tsx, src/knowledge/context-builder.ts (both plan prompts: ask, don't point at a button)

Driven in Chromium, six scenarios, zero page errors:

action present after a refinement reply	✅ (the reported bug)
still present on the drafted plan	✅ no regression
absent before any plan exists	✅ nothing to build yet
readiness card hides it, offers "Something else…"	✅
tapping the yes sends the build prompt, not the words	✅ first-build prompt from scratch, delta prompt on a built project
an ordinary question still relays its answer, stays in plan mode	✅

---

tsc -b and vite build clean across both. eslint on the touched files sits at the same pre-existing problems as an untouched tree — none in the new code.

🤖 Generated with Claude Code

https://claude.ai/code/session_01RFnFvBZPsVQjc5Xwj7H9nZ

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated
relational-builder	Ready	Preview	Sep 3, 2026 5:52pm UTC