Conversational refinement loop for ambiguous chat proposals

[Chris0Jeky]

Parent

Part of #570 (Chat-to-proposal NLP gap)

Problem

When a user's request is actionable but ambiguous, the system either:

• Fails to parse it (current behavior)
• Would generate a best-guess proposal that may not match user intent

Examples of ambiguity:

• "create onboarding tasks" — how many? what titles? which column?
• "reorganize the board" — what does reorganize mean?
• "clean up old cards" — what counts as old?

Proposed Changes

When the LLM detects actionable intent but cannot fully resolve it into specific instructions:

1. LLM asks clarifying questions instead of generating instructions
2. User answers refine the instruction set
3. After sufficient clarity, LLM generates concrete instructions
4. Instructions flow to the existing proposal pipeline

Example Flow

User: "create onboarding tasks for non-technical people"
LLM: "I can help with that! To create the right tasks, could you tell me:
      1. How many tasks do you need?
      2. What specific areas? (e.g., HR orientation, tools setup, team intros)
      3. Which column should they go in?"
User: "3 tasks: HR orientation, tools walkthrough, team introductions. Put them in Backlog."
LLM: [generates 3 create card instructions for Backlog column]

Depends On

• LLM-assisted instruction extraction
• Board-context-aware prompting (for column suggestions)

Acceptance Criteria

• LLM asks clarifying questions for ambiguous requests
• Clarification responses refine the instruction set
• Maximum 2 rounds of clarification before attempting best-effort
• User can skip clarification ("just do your best")

[Chris0Jeky]

Update: Unblocked by tool-calling spike

Spike #618 (completed, docs/spikes/SPIKE_618_COMPLETED.md §9) includes a concrete design for conversational refinement via tool calling:

• No separate "clarification mode" needed — clarification is natural multi-turn conversation where the LLM uses read tools to offer specific options before proposing changes
• Max 2 clarification rounds enforced by system prompt convention
• The ToolCallingChatOrchestrator multi-turn loop (Phase 1, LLM-06: Phase 1 — Read tools, orchestrator, and provider tool-calling extension #649) provides the infrastructure for back-and-forth refinement

This issue is now unblocked once Phase 1 (#649) of the tool-calling implementation lands. Recommend re-scoping this issue to focus on the UX and prompt engineering for clarification flows, since the underlying multi-turn architecture will already exist.