* auto-claude: subtask-1-1 - Add queue capacity check to handleStatusChange
When a task status is changed to 'in_progress' via handleStatusChange (e.g.,
from column header buttons or context menus), enforce the maxParallelTasks
limit by redirecting to 'queue' if capacity is full. Also auto-process the
queue when a task leaves in_progress. This mirrors the existing logic in
handleDragEnd.
Co-Authored-By: Claude Opus 4.6 <[email protected]>
* auto-claude: subtask-1-2 - Add queue capacity check before startTask() in TaskCard, TaskDetailModal, WorkspaceMessages
Co-Authored-By: Claude Opus 4.6 <[email protected]>
* fix: extract shared queue capacity logic and fix stuck task restart regression
- Extract `startTaskOrQueue()`, `isQueueAtCapacity()`, and
`DEFAULT_MAX_PARALLEL_TASKS` into task-store.ts to eliminate identical
queue capacity logic duplicated across 4 files (DRY violation)
- Fix stuck task restart regression: exclude the current task from the
in_progress count so restarting a stuck task doesn't incorrectly queue it
- Fix inconsistent default: use ?? 3 everywhere (was ?? 1 in 3 new files
vs ?? 3 in KanbanBoard, causing different behavior per UI element)
- Fix unawaited persistTaskStatus in TaskCard (was fire-and-forget in a
sync handler) and TaskDetailModal (missing await in async handler)
- Add explanatory comment in KanbanBoard handleStatusChange about why
isAutoPromotionInProgress guard is not needed (only user interactions)
Co-Authored-By: Claude Opus 4.6 <[email protected]>
* fix: remove duplicate processQueue() call in handleDragEnd
handleStatusChange already calls processQueue() when a task leaves
in_progress, so the second call in handleDragEnd was redundant.
Co-Authored-By: Claude Opus 4.6 <[email protected]>
* fix: log queue failures, remove dead bypass code, fix comment
- startTaskOrQueue now logs an error when persistTaskStatus fails
instead of silently discarding the result
- Remove dead isAutoPromotionInProgress bypass from drag handler since
handleStatusChange enforces capacity independently (the bypass was
negated by the second check)
- Fix inaccurate comment: handleStatusChange is called from both the
dropdown menu and the drag handler, not just the dropdown
Co-Authored-By: Claude Opus 4.6 <[email protected]>
* fix: return queue failure result from startTaskOrQueue and remove duplicate processQueue
startTaskOrQueue now returns a result object so callers can surface errors
to the user (toast in TaskDetailModal, console.error in WorkspaceMessages).
Removed explicit processQueue() from handleStatusChange since the useEffect
task status change listener already handles queue auto-promotion.
Co-Authored-By: Claude Opus 4.6 <[email protected]>
* fix: correct i18n key path and surface startTaskOrQueue failures to users
Fix wrong i18n key path (tasks:errors → tasks:wizard.errors) so the toast
shows the translated message instead of a raw key. Add toast feedback in
TaskCard on start failure. Add inline error display in WorkspaceMessages
when Proceed to Coding fails.
Co-Authored-By: Claude Opus 4.6 <[email protected]>
* fix: show user feedback when task is queued instead of started
All three startTaskOrQueue callers (TaskCard, TaskDetailModal,
WorkspaceMessages) now notify the user when a task is redirected to the
queue due to the parallel task limit. Uses existing i18n keys
(tasks:queue.movedToQueue). Also clarifies startTaskOrQueue JSDoc
regarding fire-and-forget semantics of the 'started' action.
Co-Authored-By: Claude Opus 4.6 <[email protected]>
* fix: use i18n and neutral styling for queued notice in WorkspaceMessages
Replace hardcoded English string with t('tasks:queue.movedToQueue') and
use a separate notice state with text-muted-foreground styling instead of
reusing the destructive error state. Also add missing status.queue key
to French translations.
Co-Authored-By: Claude Opus 4.6 <[email protected]>
---------
Co-authored-by: Claude Opus 4.6 <[email protected]>
