docs: close item 200, the launch selectors

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

1 files changed, 57 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 d6b199e..f5ae9f0 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
@@ -10583,6 +10583,63 @@ is coupled to `everySelectedRowIsInATrashFolder()`, which by design never
 answers for spam, so "Restore already covers what qtmaildir moved" was a
 capability claim that no surface offered. Read item 201 for the narrower,
 decision-free half.
+## 200. qtmaildir cannot be launched at a given account, thread or message
+
+**Observed (user, from the notes):** "the program should accept cli parameters
+like `--account` or `--thread`/`--message`, so that another app can launch
+qtmaildir opening that account's inbox or a certain message/thread."
+
+**Cause.** Verified. `main.cpp:38-66` walks `argv` with `std::strcmp` and
+recognises `--version`/`-v` and `--help`/`-h`, nothing else. Both answer and
+return BEFORE `QApplication` is constructed, which is deliberate and documented
+in the file: `--version` has to work on a machine where the GUI cannot open.
+Anything else on the command line is ignored silently.
+
+**Parsing is the small half.** `QCommandLineParser` is stdlib for this and
+replaces the `strcmp` loop, with the one constraint that the early-exit options
+must keep answering without a `QApplication`.
+
+**Two things make this M rather than S, and both are the interesting part.**
+
+1. **There is no single-instance mechanism.** No `QLocalServer` or
+   `QLocalSocket` appears anywhere in `src/`. A second launch therefore opens a
+   second window against the same notmuch database, and notmuch permits only one
+   open handle per process, so two processes is two handles and the read-write
+   burst the write path depends on becomes a contention question. The note's own
+   framing, "another app can launch qtmaildir", is the case where the
+   application is usually ALREADY RUNNING, so the useful behaviour is to steer
+   the running window rather than to start a second one.
+2. **A selector has to reach a query the startup path does not take.**
+   `--account` is close to free, since the account selector and the built-in
+   filters already compose that query and `Config::resolvedQuery()` exists for
+   exactly this. `--thread` and `--message` are not: they name a row that may
+   not be in the configured startup view at all, so the startup path has to
+   accept an arbitrary query and then select a row within its result, which is
+   a selection-after-load problem the window solves nowhere else.
+
+**One decision from the user before this can be planned.** Whether a second
+launch should hand its arguments to the running window and focus it, or simply
+start with a different query. The first is what makes the feature useful to an
+external caller and is essentially the whole cost of the item; the second is
+close to free for `--account` alone. They are different items sharing one line
+in the notes.
+
+**Constraints.** Arguments are untrusted input in the ordinary sense: a
+`--thread` value reaches a notmuch query, so it goes through `SearchTerm`'s
+quoting like every other query this application builds, rather than being
+concatenated at the call site.
+
+**Done 2026-10-01**, on branch `cli-selectors` and fast-forwarded to master,
+for the release after 0.30.0. `LaunchSelectors` parses the three options and
+carries them over a versioned socket payload; `SingleInstance` owns the
+`QLocalServer` and degrades to a plain window when no socket can be made.
+Decisions settled while hand-testing: `--thread` takes hex ids only, since it
+reaches `thread:` unquoted; `--message` always targets the message, a
+conversation's first included, and `--thread` is the way to ask for the
+conversation; `--thread`/`--message` without `--account` switch to All
+accounts; a miss names itself in the status bar and restores the previous
+view. Hand-tested and confirmed, including a handoff to a running window and
+bash completion.
 ## 201. A message in the Spam view cannot be un-spammed, even one qtmaildir put there
 
 **Observed (user, 2026-09-14, testing the `spam-view` branch).** "If a message