readme, roadmap: say what is true now

The status block no longer says scaffold, "The loop" no longer says none of it
runs yet, and the table of what each verb actually runs names format-patch
rather than a bare git diff.

Configuration is real: the file and its keys, the two environment variables,
init, and a doctor transcript showing what got resolved and from where. What is
left is Later and Far, plus three gaps named rather than papered over: real
mail, a full kernel build, and the fix round trip against a real kernel patch.

The tests section describes the fixture harness and the three tests that want
the host's own tools.

ROADMAP's Now and Next record what landed and what each item does now. The
series paragraph explains why the sidecar records a whole range rather than a
base: a re-roll that regenerated base..HEAD would pick up every commit that
landed on the branch since create and mail it with the set.

ROADMAP.md

@@ -6,61 +6,73 @@ ranges from one afternoon to a design conversation first.
 
 ## Now
 
-Implement the stubs. `README.md` lists them grouped by how much they
-unblock, and `patch submit` is where most people should start, since it is
-the only verb that needs no network.
+Done. Every verb runs, and the loop closes end to end: a commit went from a
+working tree to a `git send-email` plan, then round again as v2 threaded off
+the original. `README.md` has the walkthrough and the acceptance evidence.
 
-The milestone worth having is the loop closing:
+The milestone was this:
 
 ```text
 quest -> edit -> check -> format -> commit -> create -> submit -> v2
 ```
 
 One patch through one review cycle without dropping to a shell to run git or
-checkpatch by hand. Until that works, nothing else on this page is worth
-building.
+checkpatch by hand. The one step that stays yours on purpose is `git add`:
+`patch commit` commits what you staged, because sweeping a dirty tree into a
+kernel patch is a review comment nobody asked for.
 
-Two tests belong here too, both named in the README: the `vN-` naming rule in
-`reroll_path`, and the `To:`/`Cc:` split in `lookup`.
+The two tests this section named are in place: the `vN-` naming rule in
+`reroll_path`, and the `To:`/`Cc:` split in `lookup`, the second of which is
+also asserted against the host's real `get_maintainer.pl` in an opt-in test.
+
+`rg -n 'todo!' src/` finds nothing. What is left overall is the three gaps in
+the README's *What is not proven*, and `Later` and `Far` below.
 
 ## Next
 
+All three landed, in this order. The sections below say what each one does now.
+
 ### A series instead of a single patch
 
-Everything today produces one file. Real submissions are often a patch set
-with a cover letter, which means:
+Done. `patch create xhci-port-rearm --range master..HEAD --cover-letter
+"<blurb>"` writes a numbered set through `git format-patch`, cover letter
+included; `patch submit` takes a directory or several files and sends them in
+one `git send-email` invocation; `patch update <dir>` re-rolls the whole set
+through `--reroll-count`, so every file moves to vN together, and the
+superseded files go only once the new revision is complete. The blurb's first
+line becomes the cover letter's subject, and leaving `--cover-letter` off
+leaves git's template in place, which `git send-email` refuses.
 
-- `patch create` writing a numbered set from a commit range, and a
-  `0000-cover-letter.patch` alongside it
-- `patch submit` taking several files at once, which `git send-email`
-  already supports
-- `patch update` re-rolling the whole set, so every file in it moves to v2
-  together, the way `git format-patch --reroll-count` does it
-- per-patch version numbers, for the same reason
-
-This is the widest gap between what spectral does and how kernel patches are
-actually sent, so it comes first once the stubs are done.
+A `series.toml` in the directory records the range it was generated for: both
+ends as hashes, the revision, the files, and the blurb. The range is what makes
+a re-roll safe, since regenerating `base..HEAD` instead would quietly pick up
+every commit that landed on the branch since `create` and mail it with the set.
 
 ### spectral doctor
 
-The README asks for three things before spectral is useful: a kernel tree,
-`git send-email` that works, and `qemu-system-x86_64` on `$PATH`. Today you
-find out that `send-email` was never configured at the moment you try to
-submit, which is the worst time to learn it.
+Done. It checks, in the order a first run hits them: the tree path and where it
+came from, that the path is a kernel tree, `scripts/checkpatch.pl`,
+`scripts/get_maintainer.pl`, `MAINTAINERS`, git, `git send-email`, a sender
+identity, whether any mail route is configured, qemu on `$PATH`, that the patch
+directory is writable, and whether a config file exists.
 
-A `doctor` subcommand would check the tree, the two scripts inside it, the
-`send-email` config, qemu, and the resolved paths, then name whichever one is
-missing. The `Error` variants for the tree cases already exist.
+One line per check with the fix under it, and the summary names the first hard
+failure. Exit 1 when something hard failed; a missing qemu or a missing mail
+route warns and keeps exit 0, because `--dry-run` is where the loop actually
+stops on this machine.
 
 ### Config file and init
 
-`src/config.rs` carries the TODO. Two additions:
+Done. `~/.config/spectral/config.toml` (or `$XDG_CONFIG_HOME`), holding the
+tree path, the patch directory, always-CC addresses and a send-email identity.
+Precedence is the environment over the file over the built-in default, and
+`$SPECTRAL_PATCH_DIR` joined `$SPECTRAL_KERNEL` for symmetry.
 
-- `~/.config/spectral/config.toml` holding the tree path, the patch
-  directory, your send-email identity, and any addresses you always want
-  CC'd. The environment variable keeps winning over the file.
-- `spectral init`, to clone a tree or point at one you already have and
-  verify it, so nobody has to read the Configuration section twice.
+`spectral init --tree <path>` verifies a tree, or `--clone <url> [--depth N]`
+fetches one, then writes the config. A second run with the same tree says so
+and writes nothing; a run that would change an existing answer is refused until
+`--force`. Malformed TOML, an unknown key and a relative path are named errors
+rather than surprises three commands later.
 
 ## Later
 
@@ -93,7 +105,8 @@ re-roll.
 
 That needs spectral to record what it sent and where, which nothing does
 today. Where that state lives is the design question to settle before the
-feature.
+feature. A series already carries `series.toml`, which is the smallest version
+of that record: it is what a re-roll reads.
 
 ### Packaging and polish
 
@@ -164,7 +177,8 @@ should not produce a v3. `reroll_path` is already specified as a no-op at the
 same revision, and `auto` inherits that requirement.
 
 It depends on the verbs, on `doctor` to fail fast instead of halfway, and on
-the config and state files the sections above describe.
+the config and state files the sections above describe. `doctor` and the config
+file are here now; the state file is what review tracking still has to decide.
 
 ## Not planned