feat(task-input): show prompt in chat thread immediately on submit

[fercgomes]

Summary

Submitting a new task used to leave the user on TaskInput (with a spinning submit button) until the saga finished creating the task, folder, and workspace. Only then did onTaskReady fire and navigate to TaskDetail, where SessionView showed a full-screen spinner until the agent session connected and applyOptimisticPrompt wrote the user message into the optimistic store. The flow felt sluggish because each step blocked the UI from showing the prompt.

This change navigates to a thread-style view synchronously on submit:

• New task-pending view in navigationStore (transient — excluded from persistence; replaced in history on transition so back doesn't land on a stale placeholder).
• pendingTaskPromptStore holds the prompt text keyed first by a client-generated UUID, then re-keyed to the real task id once the saga returns.
• PendingChatView renders the user-message bubble + "Connecting to agent..." footer with the same layout as SessionView's connected state. TaskPendingView wraps it for the view-router; SessionView's initializing branch also renders it when a pending entry exists, bridging the gap until applyOptimisticPrompt fires.
• useTaskCreation.handleSubmit stashes the prompt, navigates to the pending view, then runs the saga. On failure it clears the pending entry and navigates back to task-input with initialPrompt preserved.
• MainLayout, useSidebarData, and TaskListView treat task-pending like task-input for sidebar/SpaceSwitcher state. CommandCenterPanel's onTaskCreated override skips the pending view so its existing flow is untouched.

Screen.Recording.2026-05-22.at.16.23.08.mov

Test plan

• pnpm --filter code typecheck clean
• 2 new navigation-store tests cover navigateToPendingTask and the history-replace behavior
• All 914 renderer tests pass
• Manual: submit a local task — confirm thread + prompt appear immediately, then spinner, then agent response streams in
• Manual: submit a worktree task — pending view stays during provisioning, transitions seamlessly to TaskDetail
• Manual: submit a cloud task — pending view shows during saga's cloud setup, then CloudInitializingView takes over
• Manual: simulate a saga failure — pending view goes back to task-input with the prompt restored
• Manual: submit from CommandCenterPanel — no pending view; existing flow unchanged
• Manual: press back from TaskDetail after submit — lands on task-input, not the empty pending placeholder

[greptile-apps]

Comments Outside Diff (1)

1. apps/code/src/renderer/features/task-detail/hooks/useTaskCreation.ts, line 239-244 (link)

   After editor.clear() is called inside the if (pendingTaskKey) block, editor.getText() returns "". The nullish-coalescing operator ?? only falls back for null/undefined, not empty strings, so "" ?? plainPromptText evaluates to "". The if (plainText) guard then fails, and addPrompt is never called — meaning the task input history is silently skipped on every normal submission that shows the pending view.

   Prompt To Fix With AI

   This is a comment left during a code review.
   Path: apps/code/src/renderer/features/task-detail/hooks/useTaskCreation.ts
   Line: 239-244
   
   Comment:
   After `editor.clear()` is called inside the `if (pendingTaskKey)` block, `editor.getText()` returns `""`. The nullish-coalescing operator `??` only falls back for `null`/`undefined`, not empty strings, so `"" ?? plainPromptText` evaluates to `""`. The `if (plainText)` guard then fails, and `addPrompt` is never called — meaning the task input history is silently skipped on every normal submission that shows the pending view.
   
   
   
   How can I resolve this? If you propose a fix, please make it concise.

Prompt To Fix All With AI

Fix the following 3 code review issues. Work through them one at a time, proposing concise fixes.

---

### Issue 1 of 3
apps/code/src/renderer/features/task-detail/hooks/useTaskCreation.ts:239-244
After `editor.clear()` is called inside the `if (pendingTaskKey)` block, `editor.getText()` returns `""`. The nullish-coalescing operator `??` only falls back for `null`/`undefined`, not empty strings, so `"" ?? plainPromptText` evaluates to `""`. The `if (plainText)` guard then fails, and `addPrompt` is never called — meaning the task input history is silently skipped on every normal submission that shows the pending view.

```suggestion
        if (!contentOverride) {
          const plainText = (pendingTaskKey ? plainPromptText : editor.getText()?.trim()) ?? plainPromptText;
          if (plainText) {
            useTaskInputHistoryStore.getState().addPrompt(plainText);
          }
        }
```

### Issue 2 of 3
apps/code/src/renderer/features/sessions/components/PendingChatView.tsx:8-9
The JSDoc says "skip the absolute fill wrapper" when `embedded` is true, but the code does the opposite — it *adds* an `absolute inset-0` wrapper. The comment should describe that the absolute wrapper is added so the component fills an existing `relative` container.

```suggestion
  /** Render inside an existing `relative` positioned container — wraps content in `absolute inset-0` to fill it. */
  embedded?: boolean;
```

### Issue 3 of 3
apps/code/src/renderer/stores/pendingTaskPromptStore.ts:3-7
**Stored fields never consumed**

`attachmentLabels` is populated in `useTaskCreation` but `PendingChatView` only uses `promptText` — the labels are never rendered. `createdAt` is similarly stored but not read anywhere. Per the simplicity rule of having no superfluous parts, both fields can be removed until there is a consumer for them.

_{Reviews (1): Last reviewed commit: "feat(task-input): show prompt in chat th..." | Re-trigger Greptile}

[greptile-apps]

The JSDoc says "skip the absolute fill wrapper" when embedded is true, but the code does the opposite — it adds an absolute inset-0 wrapper. The comment should describe that the absolute wrapper is added so the component fills an existing relative container.

Suggested change

	/** Render inside an existing positioned container — skip the absolute fill wrapper. */
	embedded?: boolean;
	/** Render inside an existing `relative` positioned container — wraps content in `absolute inset-0` to fill it. */
	embedded?: boolean;

Prompt To Fix With AI

This is a comment left during a code review.
Path: apps/code/src/renderer/features/sessions/components/PendingChatView.tsx
Line: 8-9

Comment:
The JSDoc says "skip the absolute fill wrapper" when `embedded` is true, but the code does the opposite — it *adds* an `absolute inset-0` wrapper. The comment should describe that the absolute wrapper is added so the component fills an existing `relative` container.

```suggestion
  /** Render inside an existing `relative` positioned container — wraps content in `absolute inset-0` to fill it. */
  embedded?: boolean;
```

How can I resolve this? If you propose a fix, please make it concise.

[adboio]

this is FIRE, thank you, one of my biggest pet peeves

[mostly typing before i forget, and maybe so i can use this comment as a prompt later 😂] as a followup i might try to make the loading state a bit more obvious too - maybe putting the input box at the bottom immediately as a shimmer loader or disabled, and putting a "starting task..." loader below the initial msg that looks like a normal agent loading state

[adboio]

• feat(task-input): show prompt in chat thread immediately on submit #2310 👈 (View in Graphite)
• main

This stack of pull requests is managed by Graphite. Learn more about stacking.

[adboio]

rebased to bring in the merged bulk archive, testing & reviewing now!

[adboio]

turns out that feedback was quick for code to implement 😛 thoughts?

speedy-task-startup-demo.mp4 (uploaded via Graphite)