feat(tasks): Tasks screen becomes a Specs-style list with Play

.frame/specs/tasks-list-view/digest.md

@@ -0,0 +1,22 @@
+---
+keywords: tasks board, kanban, task list, spec tasks, play button, in progress, new task form, acceptance criteria
+related: tasks-detail-on-demand, boards-done-window, agent-dispatch, home-widget-board, compact-center-vs-code-density, new-spec-agent-handoff
+---
+Replaced the Tasks Kanban with the Specs screen's shell: scope segments with counts (All / Active / Done,
+opens on Active), In progress above Pending, Completed under the done window behind the "Show" ghost tile,
+tiles in the Specs grid, no drag anywhere. Under Active, In progress / Pending chips narrow to one section,
+the Specs phase-chip pattern (T10). The reason was spec safety: a drag rewrote a spec task's status
+and so the spec's phase. Spec tasks are now hidden by default; an "Include spec tasks n" checkbox lists them
+in the status sections with the others, each tile labelled `<slug> · T##`, read-only (no Play, no status
+action, no Delete; the drawer has "Open spec"). A first version put them in a section of their own, grouped
+per spec, behind a chip; review rejected it as a second list hung under the main one (T09 overturned D4). What the screen lists
+comes from the pure `src/renderer/tasks/listModel.js`; the run prompt lives in the pure
+`src/renderer/tasks/runPrompt.js`, which every Play surface shares through `tasksPanel.openRunFlow`.
+A task missing `description` or `acceptanceCriteria` gets a format step at Play: the agent writes the fields,
+shows the criteria and waits. New Task saves only `userRequest` verbatim; no agent runs at creation (rejected:
+the new-spec-style handoff at creation, which writes criteria before the code is in view).
+Rules: never send a status from an order write. Permanent Save sends `{ id }` only and keeps spec tasks in their
+file slots. A screen action must never change a `spec:` task's status. Counts must equal what each
+scope and status chip lists with the checkbox in its current state.
+
+Chain: spec.md → plan.md → tasks.md → outcome.md

.frame/specs/tasks-list-view/outcome.md

@@ -0,0 +1,72 @@
+# Outcome — Tasks List View
+
+## T01 — Add the pure list model
+
+Added `src/renderer/tasks/listModel.js` (`buildListModel`, plus `isSpecTask` and `specSlugOf` for later tasks) and `test/tasksListModel.test.js` (23 tests, including a sweep that checks every scope's count equals what it lists, with and without the reveal and the window). Beyond plan.md's shape: the window also applies to revealed spec tasks, their older ones count toward `olderCount` only while revealed, and spec groups keep file order even under a sort. Not wired yet, as the plan sequenced.
+
+_Captured: 2026-10-15 · 2 file change(s)_
+
+---
+## T02 — Move the run prompt into the pure runPrompt.js
+
+Added `src/renderer/tasks/runPrompt.js` (`missingFields`, `buildTaskPrompt`, `isSpecTask` re-exported from `listModel.js`) and made `tasksPanel.buildTaskPrompt` a one-line delegate; fixed its stale "Kanban" comment. The "Before starting" steps are now built from a list numbered First/Then, so a ready task's prompt is byte-identical to the old builder plus the criteria line (pinned in `test/taskRunPrompt.test.js` against a verbatim copy of the old function). Beyond the plan's wording, the format step tells the agent to read the task's `tasks.json` entry, because that is where a form-created task's `userRequest` is: the prompt itself still carries no request text.
+
+_Captured: 2026-10-15 · 3 file change(s)_
+
+---
+## T03 — Make addTask keep the request
+
+`tasksManager.addTask` now copies a non-blank string `userRequest` verbatim, whitespace included. A blank or non-string request records no field. Extended `test/tasksManager.test.js` with the verbatim, blank/absent/wrong-type, and id-only `reorderTasks` cases; the last checks that status, `updatedAt` and `completedAt` all survive. Also rewrote `reorderTasks`' doc comment, which described Kanban drag-and-drop, to say what an entry without a status does. No code change there.
+
+_Captured: 2026-10-15 · 2 file change(s)_
+
+---
+## T04 — Replace the Kanban with the Specs-style grid
+
+Rebuilt the Tasks markup in `index.html`: a toolbar with the scope segments, Filter and Sort moved to its right, and a list container in place of the three columns. `tasksDashboard.js` now renders sections of `.specs-card` tiles and the `.specs-card-older` ghost tile from `buildListModel`; all drag code, `commitOrder` and the column lookups are deleted, and the export surface is unchanged. Permanent Save sends ids only. Beyond the plan, it keeps spec tasks in their file slots and fills the remaining slots with the sorted non-spec tasks, so a sort never reorders a spec's T01…Tn. Section tracks are a task-only `.tasks-dashboard-grid` with the Specs template, because `.specs-dashboard-grid` is itself a full-height scroll container and cannot repeat per section.
+
+_Captured: 2026-10-15 · 3 file change(s)_
+
+---
+## T05 — Play and drawer status actions
+
+Added the Play button to pending non-spec tiles; it calls `tasksPanel.openRunFlow` without selecting the tile. Added a drawer action slot (`index.html`) left of Delete, filled per status as D9 lists: Play → `openRunFlow`, and Mark complete, Back to pending and Reopen → `UPDATE_TASK { status }`. The action handler re-reads the task and refuses spec tasks, so a spec task opened from the top-bar chip already shows no actions before T06 adds its read-only drawer. A task with an unknown status gets the pending set, matching the section it is listed in.
+
+_Captured: 2026-10-15 · 3 file change(s)_
+
+---
+## T06 — Spec tasks on demand
+
+Added the "Spec tasks n" chip after the scope segments. It is present only while the project has spec tasks, and it toggles a per-project `showSpecTasks` flag that resets on project change. Revealed spec tasks render in a "Spec tasks" section, grouped by slug with an "Open spec" link. A spec task's drawer is read-only: no actions, Delete hidden and refused, an "Open spec" button (`specsDashboard.show()` + `openSpec(slug, { instant: true })`, D17). Beyond the plan, spec tiles show their T number and a status pill, since they sit outside the status sections. Groups are headed by slug, not title, because this screen does not load spec data.
+
+_Captured: 2026-10-15 · 2 file change(s)_
+
+---
+## T07 — New Task maps to the schema
+
+Replaced the New Task form's Description textarea with Request (`index.html`). `submitForm` now sends `userRequest` untrimmed when it is not blank, and never sends `description`. A tile shows `userRequest` until the task has a description. The saved task still has `description: ''`, because `addTask` defaults it. The plan left that alone, and readiness treats it as missing. The retired side panel's own task modal keeps its Description field; it is out of scope.
+
+_Captured: 2026-10-15 · 2 file change(s)_
+
+---
+## T08 — Rewrite the texts that describe the Kanban
+
+Rewrote the tour's Tasks step, the guide's "Plan and tasks" sentence and capability entry 04.01 to describe the grid, Play on a pending task, and spec tasks hidden until revealed. Beyond the three texts plan.md named, two more in the same files made the same Kanban claim and changed with them: the guide's "Specs & tasks boards" item ("every task, spec-generated or added by hand") and the capabilities diagram's "kanban state" label for tasks.json. Tour and guide tests still pass, including the tour's two-sentence limit.
+
+_Captured: 2026-10-15 · 3 file change(s)_
+
+---
+## T09 — Spec tasks join the status sections behind an "Include spec tasks" checkbox
+
+Overturned D4 after review: `listModel.js` drops `specGroups`, and included spec tasks now sit in the In progress / Pending / Completed sections under the same scope, window and sort rules. `tasksDashboard.js` replaces the "Spec tasks" chip and bottom section with an "Include spec tasks n" checkbox on the toolbar's right (`index.html`, `tasks-dashboard.css`). A spec tile shows `<slug> · T##` in its foot instead of its number and status pill, and keeps no Play. The guide sentence and capability entry 04.01 name the checkbox; the tour step already said only "hidden until you show them", so it stays.
+
+_Captured: 2026-10-15 · 7 file change(s)_
+
+---
+## T10 — In progress / Pending status chips under Active
+
+`buildListModel` now takes `status`, narrows Active to that one section (ignored in All and Done), and returns `status:in_progress` / `status:pending` counts that do not move with the pick, while `specTasks` follows it. `tasksDashboard.js` shows the two chips after the scope segments only while Active is picked, with the Specs phase-chip markup; a second click clears the pick, any scope pick resets it, and an empty pick says "Nothing in progress." or "Nothing pending.". `tasks-dashboard.css` inks them like the section dots, and `test/tasksListModel.test.js` extends the S10 sweep to each status.
+
+_Captured: 2026-10-15 · 4 file change(s)_
+
+---