Three causes behind the stuck indicator:
- OperationStatus.End did not retire the generation, so tick work posted
while the dispatcher was blocked drained afterwards and set
ShowIndicator back to true on a finished operation.
- The startup update check ran in Task.Run; OperationStatus writes its
observable properties on the calling thread, so the final
ShowIndicator=false never reached the binding.
- OperationIndicator overwrote its own DataContext from the Status
property, which re-targeted the call-site binding. It now scopes the
DataContext to an inner panel and collapses itself when Status is
null; every call site switched from DataContext= to Status=.
Also gates the footer connection pill in the command body instead of
CanExecute (a disabled command greyed out the ONLINE chip), and extends
OperationTiming: pid per line, 4 MB rollover, fast successes dropped
(failures always kept), and DetailsIsland.BindAsync now carries the
selection trigger via TasksIslandViewModel.SelectFrom.
Replace the three ItemsControl sections (Overdue/Open/Completed) with a single
flat Rows collection (HeaderRow | TaskRowViewModel) bound to a ListBox +
VirtualizingStackPanel, so the realized container count stays bounded instead
of growing with the list (measured: ~7-8 realized containers at any scroll
position with 1000 source rows). Group headers become regular row entries,
each section is simply omitted from Rows when empty, and the Completed
section's Clear-completed action moves onto the header row itself.
SectionFor/ReorderAsync/FindNextInSameSection now read a row's section off
the nearest preceding HeaderRow in Rows instead of three separate bound
collections, and ScrollSelectedIntoView goes through ListBox.ScrollIntoView so
it still works for rows outside the realized window. Drag/reorder behavior,
grouping/counts, and the Clear-completed button are unchanged.
Auto-scroll-while-dragging and the cross-section reorder bug are explicitly
out of scope (follow-up tasks).
Dragging a task row onto a user list in the Lists island now reassigns it
to that list. The task drag holds the pointer capture, so the release is
resolved geometrically (new case between the Mission Control and reorder
cases) instead of going through the Lists island's own DragDrop path,
which never sees a DragEventArgs during a task drag.
TaskRepository.MoveToListAsync reassigns the task plus every descendant
(a child must never sit in a different list than its parent) and appends
the task at the end of the target list. Guards: running tasks and tasks
holding an Active/Kept worktree are rejected to the footer error strip;
a move that changes repo asks for confirmation naming both repos.
The source repo is read from the task's own list rather than the island's
current list, which is a smart/virtual list with no working dir of its own
whenever one of those is shown.
Task rows now drive a hand-built pointer-capture drag instead of
DragDrop.DoDragDropAsync: armed on press, begins past a 4px threshold so a
plain click still selects. The ghost follows the screen cursor across windows;
on release the action is decided by what is under the cursor -- over the
Mission Control window queues the task (geometric DragHitTest, no OLE drop),
over another row in the same user list reorders, anywhere else cancels and
restores the row. Drag starts from any list kind (drag-to-queue everywhere)
but reorder-on-drop stays gated on CanReorder. Removes the obsolete OLE
TaskRowFormat path from both the source and MissionControlView (pane
PaneFormat reorder is untouched).
Three coordinated guards close the orphan-creation paths:
- CreateChildAsync refuses when the parent is not in a planning phase.
- DiscardPlanningAsync now returns a structured DiscardPlanningOutcome
and refuses when children are queued or running; callers can opt into
auto-dequeuing queued kids via dequeueQueuedChildren=true. Terminal
children (Done/Failed/Cancelled) are promoted to top-level instead of
becoming orphans when the parent's PlanningPhase is reset.
- OrphanRecovery hosted service clears ParentTaskId on any rows whose
parent is missing or no longer in a planning phase on worker startup,
mirroring the StaleTaskRecovery pattern.
UI surfaces the block reason: a confirm dialog offers to dequeue queued
children and retry; a running-children block is shown as a hard error
asking the user to cancel first.
WorkerClient now negotiates the JsonStringEnumConverter so the
DiscardPlanningResult enum round-trips correctly over SignalR.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
The tunnel pointer handler returned early when CanReorder was false,
so clicking a row in smart/virtual lists never updated the details
pane. Select first, then bail out of the drag path; also skip drag
initialisation on nested buttons so the done-toggle click still fires.
mika kuns