1 files changed, 1 insertions, 46 deletions
diff --git a/docs/superpowers/plans/2026-08-03-post-0.1.0-usability.md b/docs/superpowers/plans/2026-08-03-post-0.1.0-usability.md
index 6c29fe0..3cdc71a 100644
--- a/docs/superpowers/plans/2026-08-03-post-0.1.0-usability.md
+++ b/docs/superpowers/plans/2026-08-03-post-0.1.0-usability.md
@@ -240,7 +240,7 @@ taking that too literally.
 | 164 | A draft this application saved keeps `inbox` | defect | S | open, 2026-08-25, **cause corrected 2026-08-25**. The first diagnosis blamed a missing drafts helper and was WRONG: `NOT_ARRIVALS` in `qtmaildirconf.py` is `("sent", "drafts")`, the folder list includes every account's drafts folder, and `notmuch count` confirms the carve-out query MATCHES the affected draft. The carve-out is scoped to `tag:new`, and the draft carries `inbox` while `tag:new` is 0, so it was never in scope when the hook ran. Measured separately: an mbsync-style rename does NOT re-add `new.tags`, so the retag theory is out too. What remains unestablished is WHICH pass tagged it; establish that before writing code |
 | 165 | A draft gets a new Message-ID on every autosave | enhancement | ? | open, 2026-08-25, found while hand-testing 163 and 164. `MessageBuilder::build()` generates an id unconditionally and every autosave calls it, so each revision is a distinct MESSAGE to notmuch and to the server rather than a new version of one. Invisible while the file is replaced correctly, which item 163's fix restores; it is what turned that fork into two messages rather than one duplicated file. Needs a DECISION on what a draft's identity is before any code: a stable id reused at send, a stable id discarded at send, or the status quo. Neither `ComposeContext` nor `OutgoingMessage` has a field to carry an id, so it is not a changed call site |
 | 166 | Mail you send to your own other account loses `inbox` | defect | S | open, found 2026-08-25. Wholly this repo's: the hooks live in `assets/hooks/` with their own suites, and the live `post-new` symlinks to them |
-| 167 | No way to tell one build of an unreleased version from another | enhancement | XS | open, found 2026-08-25 from the notes, unrecorded until now. `src/version.h.in` interpolates `PROJECT_VERSION` alone, so every build between two releases reports the same string and a rebuilt binary cannot be told from the one it replaced. The user runs unreleased builds daily, which is when it matters. Needs a DECISION on the source: the git describe/short hash (accurate, needs the build to re-run cmake to pick up a new commit) or a monotonic counter (always moves, means nothing on its own) |
+| 167 | No way to tell one build of an unreleased version from another | enhancement | XS | **done 2026-08-25**, unreleased. The user chose a counter over a git description: `QTMAILDIR_BUILD_NUMBER`, a cmake option ON by default, increments a counter in the BUILD directory on every build and writes `buildnumber.h`. `QTMAILDIR_VERSION_DISPLAY` carries it; `QTMAILDIR_VERSION` stays clean and is what the window title, `applicationVersion` and the release procedure use |
 
 Sizes are rough: XS under an hour, S a sitting, M a session.
 
@@ -1519,48 +1519,3 @@ id and a draft of a reply carries both.
 - Item 163's fix stands on its own and this does not block it: the file is
   replaced correctly now, so the fork this would have mitigated no longer
   happens by that route.
-
-## 167. No way to tell one build of an unreleased version from another
-
-**Observed (user, from the notes):** "we should add a dev build number to be
-pushed everytime we rebuild after a fix, so that I can verify if I'm in the
-correct app version." The note has sat unrecorded through several sessions;
-the 2026-08-25 reconciliation is the first to pick it up.
-
-**Cause (verified in the code, 2026-08-25.)** The version lives in exactly one
-place, `project(qtmaildir VERSION ...)`, and `src/version.h.in` interpolates
-`@PROJECT_VERSION@` and nothing else. That is correct for a release and says
-nothing between two of them: the string moves only when the release procedure
-bumps it, so every rebuild of `0.27.0` reports `0.27.0`. The status table above
-shows why it bites in practice, since most closed items since 0.27.0 read
-"unreleased" and the user hand-tests each one against a binary they rebuilt
-themselves.
-
-Both surfaces that show the version take it from the same macro, so whatever is
-added reaches them at once: the window title (`mainwindow.cpp:939`), the About
-dialog (`mainwindow.cpp:2449`), the placeholder pane (`messageview.cpp:547`),
-`--version` and `--help` (`main.cpp`).
-
-**Approach.** Needs a DECISION before any code, because the two candidates fail
-in opposite directions.
-
-A git description (`git describe --always --dirty`, or the short hash) is
-accurate and self-explaining: it names the commit the binary was built from, and
-a reviewer can check out exactly that. Its cost is that CMake computes it at
-CONFIGURE time, so a build after a new commit reports the previous hash unless
-the configure step is made to re-run, which is a custom command with a dependency
-on `.git/HEAD` and the packed refs, and is the part that usually ships subtly
-wrong.
-
-A monotonic counter always moves and needs no git, but it means nothing on its
-own: build 412 does not say which fix is in it, and it differs between the user's
-machine and any other, so it cannot be quoted in a report.
-
-**Constraints.** A release build must keep printing a clean `X.Y.Z`, since the
-SlackBuild in the `my-slackbuilds` repo builds from the release tarball where
-there is no git checkout at all, and the release procedure checks
-`./build/src/qtmaildir --version`. Whatever is added is therefore an addition to
-the string in a dev build and absent in a release one, not a change to the
-version itself.
-
-**Size: XS** once the decision is made.