1 files changed, 65 insertions, 0 deletions
diff --git a/docs/superpowers/plans/2026-08-03-post-0.1.0-usability-closed.md b/docs/superpowers/plans/2026-08-03-post-0.1.0-usability-closed.md
index d6adc98..7a52984 100644
--- a/docs/superpowers/plans/2026-08-03-post-0.1.0-usability-closed.md
+++ b/docs/superpowers/plans/2026-08-03-post-0.1.0-usability-closed.md
@@ -7548,3 +7548,68 @@ needed. The drafts view is path-based, so zero tags is exactly enough.
 **Size: S.** One worker slot, one signal, and their tests.
 
 **Closed 2026-08-24** (unreleased). See the status table row for the outcome.
+
+
+## 159. The Drafts view lists threads, so a draft is unreachable by double-click
+
+**Observed (user, 2026-08-25):** "drafts should be treated like \"Sent\",
+listing only actual draft messages and not threads, otherwise I can double
+click on a thread message and nothing happens."
+
+**Cause (verified in code):** `Config::builtinFilter()` in `src/config.cpp`
+sets `filter.flat = true` for the `sent` generator only, at line 1011. The
+`drafts` branch below it leaves the default `false` with a comment stating the
+choice explicitly: "NOT flat, like Trash and unlike Sent: a draft reply
+belongs with the conversation it answers." That was item 138's decision and it
+is the thing the note contradicts.
+
+The consequence the user reports follows from it. A thread row stands for
+`ThreadSummary::firstMessageId`, which in a Drafts view is the first MATCHED
+message of the conversation, and that is not necessarily the draft. Item 153
+gated `edit_draft` on the file living in a configured drafts folder precisely
+so that opening ordinary mail this way cannot make the first autosave delete a
+received message, so the row is inert rather than harmful. Inert is still
+"nothing happens".
+
+**Built 2026-08-25**, after confirming the reversal with the user.
+
+**Not one line, and the reason is the part worth keeping.** The obvious fix is
+`filter.flat = true` in the `drafts` branch. That ships a defect: the view mode
+was decided in THREE places that each hardcoded a comparison against `"sent"`,
+and they have to agree.
+
+- `builtinFilter()` sets it for the button.
+- `loadSavedQueries()` reapplies it on read, so a hand-edited or migrated file
+  cannot produce a threaded Sent view.
+- `saveSavedQueries()` SKIPS writing it when the generator already implies it,
+  because a key carrying no information is one a hand-editor must read past.
+
+Setting only the first does not break the save/load pair, and it is worth being
+exact about why: the writer's skip knew only about `sent`, so it would have
+STORED `"flat": true` for drafts, and the reader would have honoured it. That
+round trip survives by accident.
+
+What does NOT survive is a file that carries no `flat` key: one written by an
+older build, migrated from elsewhere, or hand-edited, which is the case the
+reader's fallback exists for. It comes back THREADED against a flat button, and
+the writer then persists that disagreement on the next save. The reader is the
+load-bearing site, and it is the one a per-branch fix leaves untouched.
+
+`generatorIsFlat()` is the fix: one closed set beside `generatorTag()`, called
+from all three sites. `builtinFilter()` sets `filter.flat` once from it rather
+than inside a branch, so the set cannot drift from the labels below it.
+
+**Trash deliberately did not follow.** A deleted message still belongs to its
+conversation, and nothing in the trash has to be reachable for editing. The
+test asserts this, so a future change that flattens every folder filter fails
+rather than passing quietly.
+
+**Testing.** `theDraftsFilterIsThreadedNotFlat` asserted the old behaviour and
+is inverted rather than deleted, keeping the history in its comment. The
+round-trip is covered by extending `aGeneratedEntryWritesNoRedundantKeys`,
+which already asserted exactly that property for `sent`, rather than by a
+second test that would have restated it. Mutation-checked: reverting
+`generatorIsFlat()` to `sent` alone fails both.
+
+Suite 37 of 38; the failure is `undoMovesTheMessageBack`, item 136,
+pre-existing and on an unrelated path.