Automation Chat produces prose, never proposals — the chat workflow needs re-thinking

[Chris0Jeky]

What happened (live dogfooding, 2026-08-23)

Created a chat session titled "Shopping" with no board context, then asked the assistant to improve a card on Angela's Board. Over four turns the assistant produced only prose: a clarification question, then a Markdown "revised task description", then the same description again with "Deadline: Today". No proposal was created. Nothing appeared in Review. Nothing changed on the board. From the user's seat there was no signal that anything was wrong — the assistant behaved as if it had done the work.

Transcript (abridged):

• User: "can you update Angela's Board only task to make it tidy, better, better description?"
• Assistant: Asking for clarification — 4 questions
• User: "Just do your best"
• Assistant: prose "Task Title: Board Management Optimization …" (entirely hallucinated content, unrelated to the real card)
• User: "yeah, just do it, deadline for today"
• Assistant: the same prose again with "Deadline: Today"

Root causes found

1. No board context ⇒ no proposal is structurally possible. ChatService.HandleMessage gates every proposal attempt on session.BoardId.HasValue (backend/src/Taskdeck.Application/Services/ChatService.cs:461). The session in this transcript had none. The user names a board in the message ("Angela's Board") and the system never binds it, never asks, never warns — the board picker is a free-text "Board context (optional)" input in the sidebar that the user has no reason to know is load-bearing.
2. "Request proposal generation" is an unchecked checkbox below the composer. useAutomationChat.ts:40 defaults requestProposal to false and resets it to false after every send (:272). The one control that turns chat from a text generator into an agent is off by default, unlabelled as to consequence, and self-disarming.
3. The clarification loop has no exit. ClarificationDetector flags the response as a clarification and suppresses proposal creation entirely (ChatService.cs:449-456). "Just do your best" does not force best-effort; the model answered in prose and the loop simply ended with no action and no state change.
4. The assistant never read the board. It invented "Board Management Optimization" out of the session title. Without board context there is no read-set, so the model confabulates a card that does not exist and the user cannot tell.

Why this matters

Taskdeck's whole premise is capture → proposal → human review → apply. Chat is the surface where a user naturally expresses intent, and in its current shape it produces zero proposals for the most obvious phrasing of the most obvious task. It reads as a chatbot bolted next to the product rather than the front door to it.

What needs re-thinking (not just a patch)

This is a workflow redesign, not a bug fix. Suggested shape — to be settled by an ADR before implementation:

• Every chat session is board-scoped, or the first turn resolves a board. If the user names a board in natural language, resolve it and confirm inline; if it is ambiguous, ask that question rather than four generic ones.
• Acting is the default, prose is the exception. Remove or invert the "Request proposal generation" checkbox: the agent should always attempt to turn actionable intent into operations, and say plainly when it cannot.
• Grounding before generation. An instruction that names an existing card must trigger a board read, so the diff is against the real card, not an invented one. Provenance already has a place to record this.
• Clarification must terminate. After one clarification round, "just do it" / "do your best" forces a best-effort proposal (the plumbing exists — forceBestEffort in ChatService.cs:450); a proposal the user can reject is strictly better than prose the user cannot act on.
• Always land somewhere. Every actionable turn should end with either a proposal ID linked into Review, or an explicit "I could not act, because X" — never a wall of Markdown that looks like completed work.

Acceptance criteria

• ADR recorded in docs/decisions/ covering board binding, default-to-act, grounding, and clarification termination for the chat surface.
• A session with no bound board cannot silently swallow an actionable instruction — the user is told, in the turn, that no board is bound and given a way to bind one.
• "update on " phrased naturally produces a proposal visible in Review, with the diff computed against the real card.
• A clarification round followed by "just do your best" terminates in a proposal or an explicit refusal, never in prose-as-if-done.
• Assistant output never presents generated text as an applied change.
• Tests cover: unbound-board actionable message, clarification-then-force, and grounded update against an existing card.

Evidence

Live session 71e202fd-22f0-4c9d-9308-6ab7952ecc63, board "Angela's Board", OpenAI gpt-4o-mini, 2026-08-23 16:32–16:34.

Related

Reported alongside GH-2005 (capture due date dropped end-to-end) and GH-2006 (date-field picker affordance) from the same dogfooding pass.

[Chris0Jeky]

Realignment 2026-08-23 — verified against main a43df082c. Root cause 1 is sharper than filed, and that changes the cost of the fix. A milestone/ADR decision is flagged below for the maintainer; this pass does not decide it.

Root cause 1: it does warn — the warning is gated on the wrong condition

The body says the system "never binds it, never asks, never warns." It does warn. backend/src/Taskdeck.Application/Services/ChatService.cs:468-469:

assistantContent = $"{llmResult.Content}\n\n(To act on this, open a board-scoped chat session.)";
messageType = "status";

The problem is that this line is unreachable for exactly the turn that needs it. Two gates stand in front of it:

// :450-454 — the clarification short-circuit, which returns before any proposal path
var isClarification = llmResult.IsClarificationRequest
    || (!forceBestEffort && !llmResult.IsActionable
        && ClarificationDetector.IsClarificationResponse(llmResult.Content));
if (isClarification && messageType != "degraded") { messageType = "clarification"; /* no proposal creation */ }
else
{
    // :461
    var shouldAttemptProposal = llmResult.IsActionable || (dto.RequestProposal && session.BoardId.HasValue);
    if (shouldAttemptProposal)          // :463
    {
        if (!session.BoardId.HasValue)  // :465 — the hint lives only here

So a clarification or non-actionable turn — precisely the observed transcript — falls through silently. The honest-failure copy already exists in the codebase; it is behind the wrong condition. Ungating it is a small change, not a redesign.

Root causes 2 and 3 verified as written

• frontend/taskdeck-web/src/composables/useAutomationChat.ts:40 — const requestProposal = ref(false); reset to false after every send at :272. The user never opts in unless something sets it (:345).
• The clarification branch suppresses proposal creation with no exit. forceBestEffort exists in the condition at ChatService.cs:451 but nothing in the observed flow sets it (it is computed at :381 from a skip request or ClarificationDetector.ShouldForceBestEffort).

Open decision — flagged, not decided

Walkthrough q-3 puts every open Priority I issue on v0.1.2, but AC1 of this issue requires an ADR, and the body itself says "this is a workflow redesign, not a bug fix" — which matches the v0.2 Coherent Context-to-Action Loop theme rather than the v0.1.x Honest Windows Beta theme.

The shape of the split, if the maintainer wants one:

• v0.1.2 honesty slice, no ADR — ungate the existing no-board hint so it fires on every actionable-looking turn including clarifications, and make sure generated prose never reads as an applied change.
• v0.2 redesign, ADR-gated — board binding from natural language, default-to-act, grounding before generation, clarification termination.

This is the maintainer's call (decision label applied). Whether the chat workflow redesign needs its own ADR, and whether the honesty slice ships inside v0.1.2 while the redesign waits for v0.2, are both product decisions. Nothing here is split or re-milestoned by this pass.

[Chris0Jeky]

v0.1.2 honesty slice implemented — PR #2074. The redesign half is untouched and remains your recorded v0.2/ADR decision; nothing here splits or re-milestones the issue.

What the slice does, exactly as the 2026-08-23 realignment described it:

• The no-board notice now fires on every turn that asks for an action in an unbound session — clarification turns included (that path is only entered for actionable-but-ambiguous requests), plus an explicit RequestProposal, a "just do your best" that forces best effort, and a user message the local intent classifier reads as a board action. Root cause 1 was exactly as the realignment recorded: the copy existed, the gates made it unreachable.
• The copy now states that nothing was created or changed, so generated Markdown cannot read as completed work.
• Clarification turns keep messageType: "clarification", so round counting and the composer's skip action still work.

Which acceptance criteria this moves:

• AC2 (an unbound session cannot silently swallow an actionable instruction — the user is told in the turn): met for the "told" half. "Given a way to bind one" is still not offered inline; that is board binding, which is the redesign.
• AC5 (assistant output never presents generated text as an applied change): met for unbound sessions. A board-scoped session can still end an actionable turn in prose when the provider does not flag its reply actionable, and tool-calling turns can still imply a change with no proposal — both need default-to-act / grounding.
• AC1, AC3, AC4 and the grounded-update test are untouched: they are the redesign half.

Residual recorded rather than fixed: root cause 2 (useAutomationChat.ts:40/:272 — requestProposal defaults false and resets after every send) is left alone. No minimal honest-signaling change exists there without redesigning the opt-in flow, and the honesty signal is now delivered server-side on the turn regardless of the checkbox.