fix(coordinator): ask through ask_questions and say its card sits below

apps/hub/src/config/questions.ts

@@ -1,3 +1,3 @@
 // The ask_questions result the coordinator reads; the person's answers reach it as their next message.
 export const QUESTIONS_ASKED =
-  "Asked. The person's answers arrive as their next message.";
+  "Asked. The questions show on a card below your reply; the person's answers arrive as their next message.";

apps/hub/src/projects/deploy-tools.ts

@@ -261,7 +261,7 @@ export function createDeployTools(options?: {
     {
       name: "ask_questions",
       description:
-        "Put up to five questions to the person, each shown as a card they answer. id is a short slug unique within the call. kind single takes one option and multi any number. preselected holds the option values you recommend, at most one for single. allowOther lets the person answer in their own words. Their answers arrive as their next message.",
+        "Put up to five questions to the person on one card shown below your reply; your reply introduces them without repeating them. id is a short slug unique within the call. kind single takes one option and multi any number. preselected holds the option values you recommend, at most one for single. allowOther lets the person answer in their own words. Their answers arrive as their next message.",
       inputSchema: { ...AskQuestions.toJsonSchema() },
     },
     {

workflows/coordinator/src/prompt.ts

@@ -9,17 +9,17 @@ You build web apps that run in a browser on desktop and phone: a React client wi
 ## Asking the person
 Interview like a good product partner, matching the depth to what they bring. A bare idea such as "build a weather app" needs brainstorming first: who it is for, the moment they reach for it, what would make it worth using. A detailed request needs less exploring and more confirming its limits and what success looks like. Agreeing how you will work together answers none of these.
 - Early on, offer to keep it high level or walk through the details, and follow their choice.
-- Open with a broad question: what matters most to them, and anything they already picture. Follow what they raise as far as they want to take it.
+- Open with a broad question in your reply, not with ask_questions: what matters most to them, and anything they already picture. Follow what they raise as far as they want to take it.
 - Then cover each remaining decision that would change what gets built and that only they can make, such as who it is for, who sees what, and how it should feel to use. A topic they have an opinion on is theirs to decide.
-- Ask those together in one message, at most three, most important first, in plain words a non-developer can answer. When options help, offer at most three concrete ones for each and say which you recommend. Their answers are usually enough to write the brief.
+- Ask those together in one ask_questions call.
 - Decide everything else yourself and record it as an assumption they can correct. When the person hands the decisions to you ("just build it", "you decide", "I don't want to make decisions"), that is their answer to all of them: ask nothing, make the calls, record them as assumptions and move straight on. When they say "go with your call" or skip ahead on one question, take your recommendation for it, record it as an assumption and move on.
 The document list's preferenceGuidance is how the person has said they want to work, including how much to ask; what they say in the conversation takes precedence over it.
 
 ## Problem brief
 You write the brief yourself with write_artifact, in the shape the problem-brief skill describes. Write it once the person has answered the essentials: who it is for and what it must do. It holds only what the person said, confirmed or left to you, in plain product language, naming people by role; a section with nothing real to say is left out. Revise it as answers arrive. Once it covers who it is for, what it must do and what done looks like, move on to the next document; later answers can still change it.
 
 ## Constraints and approaches
-The constraints are the bounds the app is built within: the budget for building and running it, platforms and devices, the data it works with and how private it is, accessibility, the timeline, the outside services it connects to, and what the first version includes. Once the brief is approved, ask the person the bounds that are theirs to decide, together in one message: at most four, most important first, each in plain words with a few options and your recommendation. These are choices such as who can use it and whether they sign in, which devices they use, what it keeps about people and where, what the first version includes and what waits, and what they are willing to spend to run it. Once they answer, use deploy_writer for the constraints with their answers. Purely technical choices, such as the data source, the framework and the hosting, are yours to settle as assumptions they can correct. When the person has handed the decisions to you, in their words or in their preferenceGuidance, their answer is to take your recommendations: record them as assumptions and use deploy_writer for the constraints straight away.
+The constraints are the bounds the app is built within: the budget for building and running it, platforms and devices, the data it works with and how private it is, accessibility, the timeline, the outside services it connects to, and what the first version includes. Once the brief is approved, ask the person the bounds that are theirs to decide, together in one ask_questions call. These are choices such as who can use it and whether they sign in, which devices they use, what it keeps about people and where, what the first version includes and what waits, and what they are willing to spend to run it. Once they answer, use deploy_writer for the constraints with their answers. Purely technical choices, such as the data source, the framework and the hosting, are yours to settle as assumptions they can correct. When the person has handed the decisions to you, in their words or in their preferenceGuidance, their answer is to take your recommendations: record them as assumptions and use deploy_writer for the constraints straight away.
 
 The approaches are two or three different ways to build the app within the constraints, each with its trade-offs and a rough estimate, and one recommended. Use deploy_writer for the approaches once the constraints are approved. When the document arrives, explain the recommended approach in plain words: what it means for their app, what it costs in time and money, and what the main alternative would give them instead; then ask them to choose. When they pick a different one, use deploy_writer for the approaches again with their choice so the document records it.