fix(mobile): unify draft and thread navigation and composer behavior#23467

🟠 High threads/NewTaskDraftScreen.tsx:819

A hardware-keyboard submit can enqueue a task while the project is cloning or before the incoming share has finished merging, even though the Send button is blocked. ComposerEditor.onSubmit reaches handleStart without enforcing sendBlockedReason, and handleStart does not check cloneBlocksStart, isIncomingShareReady, or isImportingShare; validate these conditions here or guard the shared submit path.

Fixed in a8b95bc7439. The shared keyboard-submit path now checks the same send-block reason as the button, and draft submission also rejects clone/import/interaction-locked states before enqueueing.

🟠 High threads/NewTaskDraftScreen.tsx:1191

The shared composer remains editable during flow.submitting and incoming-share transfers, so edits made while enqueueThreadOutboxMessage is pending are cleared by the successful submit without being sent; a failed share-import cancellation can likewise restore over edits made during the transfer. sendBlockedReason disables Send but does not pass the interaction lock to the editor or attachment-removal controls; preserve those locks in the shared composer.

Fixed in a8b95bc7439. Draft interaction locking now reaches the shared composer, including the editor, attachment removal, and submit controls. The existing draft submit/import lock is retained throughout the transfer.

🟡 Medium threads/NewTaskDraftScreen.tsx:1112

When flow.selectedModel is null, this early return leaves the user unable to switch environments or reconnect, so a draft with no usable model cannot recover from this screen. The fallback only renders a text editor despite telling the user to connect; keep environment selection and reconnect actions available in this branch.

No longer relevant as of d6d95412841e0b0443c050ac620755d8964989c1

Fixed in d6d95412841: the no-model fallback retains the environment trigger, so it can open the picker and connection details while preserving the local draft.

The environment picker is now available, but the no-model fallback still has no reconnect action or connection-details link. onReconnectEnvironment remains only on the normal ThreadScreenBinding path, so the recovery concern is only partially resolved.

The recovery path is available through the environment trigger retained in the no-model fallback (NewTaskDraftScreen.tsx). It opens NewTaskEnvironment; EnvironmentPickerRow in NewTaskContextPickerScreens.tsx exposes Show connection details and, when disconnected, Reconnect now wired to onReconnectEnvironment. The maintainer explicitly requested a minimal trigger with an offline dot and detailed status/reconnect controls in the environment screen, so duplicating those controls on the draft fallback would contradict that design. The direct ThreadScreenBinding callback is not the only reconnect entry point.

🟠 High threads/NewTaskDraftScreen.tsx:368

When the route’s project has been removed, choosing a replacement leaves the incoming share permanently unimported and the composer locked. This fallback keeps the draft route mounted with its stale initialProjectRef, so the import effect’s selectedProjectMatchesRoute check rejects the replacement project; replace the draft route or update its project params when the replacement is selected.

Fixed in 8e0a377. The missing-project fallback now replaces the stale draft with the project picker, preserving the incoming share ID. Selecting a replacement mounts a fresh draft with matching project params. Added a StackRouter regression test covering removal of the stale draft and selection of the replacement; both navigation tests and mobile typecheck pass.

🟠 High threads/NewTaskDraftScreen.tsx:1262

When the legacy plan-mode preference is disabled, the shared composer still exposes /plan, but selecting it only removes the command from the prompt and saves a setting that resolvePendingTaskInteractionMode ignores, so the task starts in default mode instead of planning mode. Pass onUpdateThreadInteractionMode only when flow.planModeEnabled, as before.

No longer relevant as of 07b62c591eefb776b2b3e1a61c875dfc8b5576ee

Fixed in 8e0a377 and c4947f8. Drafts only supply the interaction-mode callback when plan mode is enabled. The shared screen/composer now preserve an absent callback, so the command menu does not offer /plan when the preference disables it. Mobile typecheck passes.

🎯 Functional Correctness | 🟡 Minor | ⚡ Quick win

Route sidebar draft actions through handleSelectThreadRoute.

handleNewThreadOnBranch and handleNewThreadInProject call navigation.navigate("Thread", …) directly. The same actions in HomeRouteScreen (Lines 71-78 and 287-293) use selectThreadRoute.

The direct call skips four things:

• The Android workspace reset (selectAndroidWorkspace).
• The overlay reset (resolveThreadSelectionOverlayState).
• The replace handling for nested thread routes such as ThreadFiles.
• setFileInspectorPreferredVisible(false).

In split view, starting a draft from a sidebar row while ThreadFiles is focused pushes a draft over the file route. The file inspector also stays open. On Android, the tab and stack reset does not run. CommandPalette (Lines 282 and 315) uses the same direct pattern.

Use the central selector so that every entry point behaves the same way.

✅ Addressed in commits 5ff95f5 to d1a219f

Fixed in d1a219f9db2. Routed both sidebar actions and the two command-palette draft actions through selectThreadRoute, preserving the shared workspace, overlay and inspector reset behavior. Validation: 21 focused tests, mobile typecheck, and scoped lint (existing warnings only).

@juliusmarminge The supplied code confirms both sidebar actions now use handleSelectThreadRoute and preserve their draft fields. Your reported command-palette changes address the remaining entry points. This addresses the finding.

✅ Review thread resolved.

_{You are interacting with an AI system.}

🗄️ Data Integrity & Integration | 🟠 Major | ⚡ Quick win

Reset the flow when the draft identity changes on the same route.

reset() runs only when NewTaskDraftRouteScreen mounts ([reset] is stable). Several paths change draft params on the existing Thread route key, so the component does not remount:

• Split view uses setParams in handleSelectThreadRoute and createHomeThreadRouteAction.
• Compact view uses navigate("Thread", …) on a focused Thread route.

In those cases the shared NewTaskFlowProvider keeps the previous activeDraftKey, the previous selectedProjectKey, and the screen's creationMetadata.

Trigger: open draft A from the sidebar (draftId: A), then press "New task" or ⌘N.

• props.draftId becomes undefined, so the initial-project effect in NewTaskDraftScreen runs.
• If the destination project differs, setProject calls carryDraftContentTo. That function calls retargetNewTaskDraft(activeDraftKey) and moves draft A's content to the other project.
• If the destination project is the same, the effect returns early. "New task" then shows draft A instead of an empty draft.

Remount the draft screen when its identity changes. The ThreadScreenHost outlet keeps the native screen and editor, so a remount does not rebuild them.

✅ Confirmed as addressed by @juliusmarminge

Fixed in d1a219f9db2. Keyed the draft controller by normalized draft identity, including the saved/pending draft, project, environment, branch/worktree and incoming share. This resets its flow and creation metadata on same-route draft changes while retaining ThreadScreenHost. Added identity regression coverage and verified switching between two drafts restores each draft’s own text and attachments on iPad. Validation: 21 focused tests, mobile typecheck, and scoped lint (existing warnings only).

@juliusmarminge Verified the fix in d1a219f9db2. The draft controller now uses the normalized draft identity as its key, while ThreadScreenHost remains mounted. This addresses the stale flow and creation metadata on same-route draft changes.

The regression tests cover draft changes, starting a new draft, project changes, incoming shares, and parameter normalization. I inspected the code and tests; I did not rerun validation.

✅ Review thread resolved.

_{You are interacting with an AI system.}

🎯 Functional Correctness | 🟡 Minor | ⚡ Quick win

Use a draft-specific files route when threadId is absent.

openFiles navigates to ThreadFiles without threadId, but ThreadFiles uses the required threads/:environmentId/:threadId/files pattern. The generated path can therefore contain /undefined/. parseActiveThreadPath accepts that segment and enables thread commands for the nonexistent thread.

ThreadFilesTreeScreen.handleSelectFile also navigates to ThreadFile without threadId for drafts. Add a draft tree route and keep draft file selections on draft routes. Do not make the shared thread prefix optional, because that prefix is also used by terminal, review, and other thread routes.

✅ Addressed in commits 5ff95f5 to d1a219f

Fixed in d1a219f9db2. Added NewTaskFiles with a draft-specific linking path. Draft header file browsing now uses it, and file selection without a thread ID opens NewTaskFile. Live-thread path patterns are unchanged. Verified the draft file browser opens on iPad; added the draft-tree deep-link restoration case. Validation: 21 focused tests, mobile typecheck, and scoped lint (existing warnings only).

@juliusmarminge Thanks for the fix. The reported NewTaskFiles route and NewTaskFile selection path address this finding while preserving live-thread path patterns.

✅ Review thread resolved.

_{You are interacting with an AI system.}

🎯 Functional Correctness | 🟡 Minor | ⚡ Quick win

Use startNewTask for the rail "new thread" action.

onNewThread calls navigation.navigate("Thread", { draft: {} }) directly. The Android FAB uses startNewTask instead (HomeRouteScreen Line 206). startNewTask picks a project through newTaskDestination and runs selectAndroidWorkspace. That call selects the threads tab and resets the workspace stack.

The direct call has a consequence on the Settings workspace page. The draft is pushed over SettingsSheet, and the workspace tab state is not switched to threads. The rail can therefore keep "settings" selected while the draft is visible.

AndroidWorkspaceNavigation renders inside AdaptiveWorkspaceContext, so the hook is available.

✅ Addressed in commits 5ff95f5 to d1a219f

Fixed in d1a219f9db2. The Android rail now uses startNewTask, so project selection and the threads workspace reset are shared with the other entry points. Validation: 21 focused tests, mobile typecheck, and scoped lint (existing warnings only).

@juliusmarminge Thanks for the fix. Using startNewTask through the callback addresses this finding by sharing project selection and the threads workspace reset.

✅ Review thread resolved.

_{You are interacting with an AI system.}

🎯 Functional Correctness | 🟡 Minor | ⚡ Quick win

Apply the hasThread gating to the toolbar Git menu as well.

This change disables "Review changes" and "More" for drafts in useThreadGitHeaderActionItems. threadGitMenuDefinition (Lines 554-568) builds the menu used by ThreadGitControls, and it still ignores props.hasThread.

useThreadHeaderOptions renders <ThreadGitControls … showActionControls /> as a fallback when !layout.usesSplitView && !usesNativeHeaderGlass. On that path, a draft keeps "Review changes" enabled. openReview then navigates to ThreadReview with the draft shell's unsaved threadId.

Apply the same condition in both menu builders.

✅ Addressed in commits 5ff95f5 to d1a219f

Fixed in d1a219f9db2. Applied the same hasThread gate and first-message availability subtitle to both toolbar Git actions. Validation: 21 focused tests, mobile typecheck, and scoped lint (existing warnings only).

@juliusmarminge The supplied code confirms the fix. Both menu builders disable “Review changes” and “More” when hasThread === false and show the first-message availability subtitle. “Review changes” also retains the repository check.

✅ Review thread resolved.

_{You are interacting with an AI system.}

🎯 Functional Correctness | 🟡 Minor | ⚡ Quick win