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

@@ -5,12 +5,14 @@ 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, then open a PR with base `next`, never `main`
-- pass an independent review; the manager then squash-merges into `next`
+- pass an independent review
+- 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. One PR from `next` into `main` accumulates the
-milestone. Releases are cut from `main` separately.
+into `main` at all times. A milestone's work reaches `main` through one PR from
+`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.
@@ -21,22 +23,25 @@ What is still open for 1.0.0 is in its milestone
 (https://git.eeqj.de/sneak/webhooker/milestone/9). `v1.0.0` is not tagged. Only
 @sneak tags it.
 
-Delivery is at least once by design. A send whose result row does not land is
-sent again, so a receiver can see a duplicate. The alternative is a silent lost
-delivery. The README says so under How it works. It is not a defect to re-file.
+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 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 from tagging and waits on neither. `next` is kept
-mergeable at all times; that is the point of the branch.
+into `main` is a separate act. It waits on neither the production run nor the
+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 in the receiver. Today
-  `RECEIVER_RATE_LIMIT` sets one limit for every entrypoint on the server.
-- API key authentication for programmatic access. The `APIKey` table exists, but
-  nothing creates a key and nothing checks one.
+- Per-webhook rate limits, set in the web UI and enforced at the entrypoint.
+  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.
     - CRUD for webhooks, entrypoints and targets
     - event viewing and filtering endpoints
@@ -48,21 +53,22 @@ mergeable at all times; that is the point of the branch.
   each target's deliveries. The event log shows every attempt's duration.
   `/metrics` carries server-wide counts and delivery durations.
 - A remember-me option at login. Today every session survives a browser restart.
-  It lasts up to 7 days, and ends sooner after `SESSION_IDLE_TIMEOUT` (default
-  24 hours) without use.
+  It lasts up to 7 days. It ends sooner after `SESSION_IDLE_TIMEOUT` (default 24
+  hours) without use.
 - Password reset over the web for a forgotten password. Today a signed-in user
-  can change their password, and a lost password is reset from the console with
+  can change their password. A lost password is reset from the console with
   `webhooker resetpw` (https://git.eeqj.de/sneak/webhooker/issues/208).
 - Later, nice to have
     - email delivery target type
     - SNS and S3 delivery targets
-    - data transformations, such as a configurable Slack message format; the
-      Slack target sends one fixed format today
+    - data transformations, such as a configurable Slack message format. The
+      Slack target sends one fixed format today.
     - JSONL file delivery with periodic S3 upload. Today the `database` target
-      archives events to SQLite files, rotated hourly, daily or monthly if set,
-      and the webhook page offers them as one gzipped JSON download.
+      archives events to SQLite files. A target can rotate those files hourly,
+      daily or monthly. The webhook page offers them as one gzipped JSON
+      download.
     - webhook event search, and filtering beyond the event log's failed and
       pending views
     - multi-user with role-based access control. Today each webhook belongs to
-      one account, but only the account made at first boot exists and there is
-      no way to add another.
+      one account. Only the account made at first boot exists. There is no way
+      to add another.