Rewrite TODO.md sentence by sentence

Rewritten from scratch against the code on next; the sections and
their contents are kept.

Model: fable-5-1

TODO.md

@@ -4,18 +4,15 @@ One issue per unit of work, and one branch and one PR per issue:
 
 - make sure a tracked issue exists with a definition of done
 - branch from `next`, never from `main`
-- do the work and push the branch
-- open a PR with base `next`, never `main`
+- do the work, then open a PR with base `next`, never `main`
 - pass an independent review
-- the repository manager squash-merges it into `next`
-
-The repository manager is the role that merges each issue's PR into `next`.
-Nothing stays local-only: every commit is pushed.
+- the repository manager, the role that merges every PR, then squash-merges it
+  into `next`
+- push; nothing stays local-only
 
 `next` is the branch for the next milestone. It must stay green and mergeable
 into `main` at all times. A milestone's work reaches `main` through one PR from
-`next`, which the owner, @sneak, merges. Cutting a release from `main` is a
-separate step after that.
+`next`. Cutting a release from `main` is a separate step after that.
 
 The tracker (https://git.eeqj.de/sneak/webhooker/issues) records what is done
 and what is under way. This file keeps no list of either.
@@ -29,20 +26,20 @@ What is still open for 1.0.0 is in its milestone
 Delivery is at least once by design. When webhooker cannot record the outcome of
 a delivery, it sends that delivery again. The target can then receive the same
 event twice. The alternative is a lost delivery that nothing reports. The README
-says so. Such a duplicate is not a defect to re-file.
+says so under How it works. Such a duplicate is not a defect to re-file.
 
 # Next Step
 
 @sneak runs webhooker in limited production, then tags `v1.0.0`. Merging `next`
 into `main` is a separate act. It waits on neither the production run nor the
-tag.
+tag. `next` is kept mergeable at all times; that is the point of the branch.
 
 # Future Steps
 
 - Per-webhook rate limits, set in the web UI and enforced at the entrypoint.
-  Today `RECEIVER_RATE_LIMIT` is the only rate-limit setting. It is how many
-  requests per minute one client address may send to one entrypoint. The same
-  address is also capped at ten times that across all entrypoints together.
+  Today `RECEIVER_RATE_LIMIT` is the only setting. It is how many requests per
+  minute one client address may send to one entrypoint. The same address is also
+  capped at ten times that across all entrypoints together.
 - API key authentication for programmatic access. The `APIKey` model and its
   `api_keys` table exist. Nothing creates a key and nothing checks one.
 - REST API v1. `/api/v1` is mounted with no routes today.