diff --git a/.planning/phases/04-tasks-kanban/04-CONTEXT.md b/.planning/phases/04-tasks-kanban/04-CONTEXT.md
new file mode 100644
index 0000000..e3f127b
--- /dev/null
+++ b/.planning/phases/04-tasks-kanban/04-CONTEXT.md
@@ -0,0 +1,121 @@
+# Phase 4: Tasks (Kanban) - Context
+
+**Gathered:** 2026-05-15
+**Status:** Ready for planning
+
+
+## Phase Boundary
+
+Inside a tablo, a user can run a kanban board with four fixed columns (todo / in progress / in review / done). Users can create tasks in a column, edit task title and description inline, move tasks between columns via drag-and-drop, reorder tasks within a column, and delete tasks. All mutations are HTMX-driven; ordering persists across refreshes.
+
+Delivers TASK-01..07. **Not** in scope: configurable/user-defined columns (fixed for v1), rich-text task descriptions, task comments, task assignees, due dates, task tags/labels, file attachments on tasks (files attach to tablos in Phase 5), tab navigation on the tablo detail page (added only when Phase 5 files section is integrated).
+
+
+
+
+## Implementation Decisions
+
+### Column Architecture
+- **D-01:** Fixed 4 columns: `todo`, `in_progress`, `in_review`, `done` — hardcoded as Go constants, no `task_columns` table. No column CRUD routes in this phase. TASK-01's "configurable" option is deferred.
+- **D-02:** Column stored on each task row as a Postgres `ENUM` type: `CREATE TYPE task_status AS ENUM ('todo','in_progress','in_review','done')`. Type-safe in the DB; sqlc generates a Go type; invalid values rejected at DB layer. Adding a future status requires `ALTER TYPE task_status ADD VALUE` (safe, non-blocking migration).
+- **D-03:** Hard-delete only — no `deleted_at` column on tasks. Consistent with Phase 3 (D-01). All task delete handlers require inline confirmation before firing (reuse D-07 pattern from Phase 3).
+
+### Task Ordering
+- **D-04:** Task position stored as `position INTEGER NOT NULL` on the tasks row. First task in a column = 100, second = 200, gap of 100 between each. Inserting between two tasks uses the midpoint (e.g. 150). When gaps narrow below a threshold (e.g. adjacent positions differ by < 2), a rebalance pass reassigns multiples of 100 for that column. O(n) rebalance is acceptable at v1 task counts.
+- **D-05:** Last-write-wins for concurrent edits — documented in code, acceptable for v1 (per TASK-07). No optimistic locking required.
+
+### Move/Reorder Interaction
+- **D-06:** Drag-and-drop via **Sortable.js** (standalone ~30KB utility, not a JS framework). Handles both within-column reorder (TASK-05) and cross-column move (TASK-04) via a single draggable surface per column.
+- **D-07:** Sortable fires an `end` event on drop. A small inline `