Mission Control task-editor save diagnosis
Mission Control task-editor save diagnosis
Date: 2026-04-27
Scope
Diagnose the task-editor save issue Pete hit when trying to mark JAM-45 done from the UI.
Root cause
The task editor exposed all status columns in the Column select for existing tasks, but the server-side save path does not allow arbitrary status jumps.
Relevant save path:
components/tasks/TaskEditorModal.tsxrenders every column as a selectable option.components/tasks/TasksWorkspace.tsxsaves edit-mode changes withPATCH /api/tasks/:taskId.app/api/tasks/[taskId]/route.tscallsupdateTask(...).lib/tasks-store.tsapplies lifecycle validation viaapplyLifecycleTransition(...)and rejects illegal transitions such asbacklog -> done.
That creates a UI/API mismatch:
- the modal suggests direct moves like
backlog -> doneare allowed; - the API rejects them with
Invalid transition: backlog -> done; - from the user side, the save appears not to stick.
Live repro
I reproduced this in the running UI at http://localhost:3100/tasks using temporary tasks.
Repro 1, invalid transition, expected failure before fix
Temporary task: JAM-47
- created in
backlog - opened in the editor modal
- changed
ColumntoDone - clicked
Save changes
Observed result:
- modal stayed open
- page surfaced
Invalid transition: backlog -> done - task did not move
Repro 2, valid transition, save path works
Temporary task: JAM-48
- created in
needs-review - opened in the editor modal
- changed
ColumntoDone - clicked
Save changes
Observed result:
- API persisted the task as
done - no transition error returned
This confirms the bug is not a generic editor save failure. It is a status-option mismatch between the editor and lifecycle-enforcing API.
Fix implemented
I made the task lifecycle rules a shared source of truth and constrained edit-mode status options to legal choices for the task’s current persisted state.
Files changed:
mission-control/lib/tasks.ts- added
allowedTaskStatusTransitions - added
getTaskStatusEditOptions(currentStatus) mission-control/lib/tasks-store.ts- switched server transition validation to use the shared lifecycle map
mission-control/components/tasks/TasksWorkspace.tsx- edit mode now passes lifecycle-filtered column options into
TaskEditorModal - options are based on the task’s current persisted status, not the mutable draft state
Expected behavior after restart/reload:
- backlog tasks show only
BacklogandUp Next - up-next tasks show
Backlog,Up Next,In Progress - in-progress tasks show
In Progress,Needs Review - needs-review tasks show
In Progress,Needs Review,Done - done tasks show
Done
This prevents the editor from offering impossible transitions that the API will reject.
Validation status
Completed:
- reproduced the original failure mode in the live UI
- confirmed valid
needs-review -> donesaves do persist - implemented a scoped code fix
- cleaned up both temporary repro tasks, board left clean
Blocked in this session:
- I could not restart or rebuild the running Mission Control server from this Discord subagent session because
execrequires approval and chat exec approvals are disabled here. - The browser continued serving the pre-change bundle, so I could not perform a post-restart UI validation of the patched modal from this session alone.
Remaining edge cases
- Deep-linked edit modals should now respect lifecycle options after the updated bundle is loaded.
- This fix is intentionally narrow. It does not change drag-and-drop behavior or introduce multi-step auto-advancement through the lifecycle.
- If product intent is to allow direct jumps to
Done, the server lifecycle model would need a separate policy change. That is not part of this fix.