# Phase 8: Task Delete - Context

**Gathered:** 2026-03-18
**Status:** Ready for planning

<domain>
## Phase Boundary

Add a delete action to tasks with smart behavior: hard delete (remove from DB) if the task has never been completed, soft delete (deactivate, hide from views) if the task has been completed at least once. Preserves completion history for future statistics. No UI to view or restore archived tasks in this phase.

</domain>

<decisions>
## Implementation Decisions

### Delete placement
- Red delete button at the bottom of the task edit form, below the history section, separated by a divider
- Edit mode only — no delete button in create mode (user can just back out)
- No swipe-to-delete, no long-press context menu, no AppBar icon — form only
- Deliberate action: user must open the task, scroll down, and tap delete

### Confirmation dialog
- Single generic "Aufgabe löschen?" confirmation — same message for both hard and soft delete
- User does not need to know the implementation difference (permanent vs deactivated)
- Follow existing room delete dialog pattern: TextButton cancel + FilledButton with error color
- Existing l10n strings (taskDeleteConfirmTitle, taskDeleteConfirmMessage, taskDeleteConfirmAction) already defined

### Delete behavior
- Check task_completions count before deleting
- 0 completions → hard delete: remove task and completions from DB (existing deleteTask DAO method)
- 1+ completions → soft delete: set isActive = false on the task, task hidden from all active views
- Need new `isActive` BoolColumn on Tasks table with default true + schema migration

### Post-delete navigation
- Pop back to the room task list (same as save behavior)
- Reactive providers will auto-update to reflect the deleted/deactivated task

### Archived task visibility
- Soft-deleted tasks are completely hidden from all views — no toggle, no restore UI
- Archived tasks preserved in DB purely for future statistics phase
- No need to build any "show archived" UI in this phase

### Claude's Discretion
- Migration version number and strategy
- Exact button styling (consistent with Material 3 error patterns)
- Whether to add a SnackBar confirmation after delete or just navigate back silently

</decisions>

<specifics>
## Specific Ideas

- User explicitly wants simplicity: "just have a delete function keep it simple"
- The smart hard/soft behavior is invisible to the user — they just see "delete"
- Keep the flow dead simple: open task → scroll to bottom → tap delete → confirm → back to list

</specifics>

<code_context>
## Existing Code Insights

### Reusable Assets
- `TasksDao.deleteTask(taskId)`: Already implements hard delete with cascade (completions first, then task)
- `TaskActionsNotifier.deleteTask(taskId)`: Provider method exists, calls DAO
- Room delete confirmation dialog (`rooms_screen.dart:160-189`): AlertDialog pattern with error-colored FilledButton
- German l10n strings already defined: taskDeleteConfirmTitle, taskDeleteConfirmMessage, taskDeleteConfirmAction

### Established Patterns
- Confirmation dialogs: AlertDialog with TextButton cancel + error FilledButton
- DAO transactions for cascade deletes
- ConsumerStatefulWidget for screens with async callbacks
- Schema migrations in database.dart with version tracking

### Integration Points
- `task_form_screen.dart`: Add delete button after history ListTile (edit mode only)
- `tasks_dao.dart`: Add softDeleteTask method (UPDATE isActive = false) alongside existing hard deleteTask
- `calendar_dao.dart`: 6 queries need WHERE isActive = true filter
- `tasks_dao.dart`: watchTasksInRoom needs WHERE isActive = true filter
- `database.dart`: Add isActive BoolColumn to Tasks table + migration
- All existing tasks must default to isActive = true in migration

</code_context>

<deferred>
## Deferred Ideas

None — discussion stayed within phase scope

</deferred>

---

*Phase: 08-task-delete*
*Context gathered: 2026-03-18*
