Bring README and TODO.md in line with next after the milestone merge (closes #132)

Docs only. TODO.md's Next Step says no implementation work is open and
the cache design waits on sneak's review. The README is corrected
wherever the code contradicts it: login's TOTP and email OTP steps and
the crypto done outside libsodium; which errors are retried and what
each backup does with a failed download; which metadata a backup's JSON
keeps; the session and logout behavior; the CLI's --exif, --json, ML
data and thumbnail-fixer details; the cache's default directory and
size limit; when refreshes run and what fresh() and lib.backup() wait
for; the Photo fields; test coverage; the Makefile shims; and the
408/429 retries.

Model: opus-5-5

README.md

@@ -171,19 +171,16 @@ local cache is reliable, and the UI is responsive on a five-year-old laptop.
 
 All work on quak is test-driven. No exceptions.
 
-1. Every change starts on a feature branch off `next`, and its pull request
+1. Every change starts on a feature branch off `main`.
-   targets `next`.
 2. The first commit on the branch is the test suite for what is being added or
    changed. Those tests must fail at that commit; the branch is red until the
    implementation lands.
 3. Subsequent commits add the implementation and any refactors needed to make
    the tests pass.
-4. A pull request can only be merged into `next` when `make check` is green.
+4. A feature branch can only be merged into `main` when `make check` is green.
-   Once it has passed review, the repository manager squash-merges it into
+   `main` is always green. CI runs `script/cibuild`, which builds the
-   `next`. Only sneak merges `next` into `main`. `main` and `next` are always
+   `Dockerfile`: its `lint` and `test` phases, then the compile, so neither a
-   green. CI runs `script/cibuild`, which builds the `Dockerfile`: its `lint`
+   red branch nor one that does not compile can pass CI.
-   and `test` phases, then the compile, so neither a red branch nor one that
-   does not compile can pass CI.
 5. Tests are the canonical API documentation for this library. Every test file
    is commented thoroughly enough that a reader who has never seen quak can
    learn how to use it from the tests alone. Comments explain why a behavior
@@ -201,7 +198,7 @@ All work on quak is test-driven. No exceptions.
    not the tests, and so not the full `make check`. This is deliberate so the
    TDD red-phase commit (failing tests, no implementation yet) can land. The
    `test` phase is part of the image build, which is what CI executes via
-   `script/cibuild`, so a red branch still cannot reach `next`.
+   `script/cibuild`, so a red branch still cannot reach `main`.
 
 ## Design
 
@@ -842,15 +839,14 @@ documents:
   `yarn.lock`. Never `git add -A`. Never force-push to main.
 
 - **The "Development workflow" section above.** All changes go on feature
-  branches off `next`, and every pull request targets `next`; only sneak merges
+  branches. Tests are written first and committed in a failing state before the
-  `next` into `main`. Tests are written first and committed in a failing state
+  implementation. Tests are the canonical API documentation and must be
-  before the implementation. Tests are the canonical API documentation and must
+  commented thoroughly. `main` is always green.
-  be commented thoroughly. `main` and `next` are always green.
 
 - **Required checks before every commit:** `make lint` must pass — that is
   eslint plus the prettier check, and it builds the `lint` phase of the
   `Dockerfile`, so it needs docker. The pre-commit hook enforces exactly that.
-  `make check` (which also runs the tests) must pass before merging into `next`.
+  `make check` (which also runs the tests) must pass before merging to `main`.
   `make fmt-check` is available for a host-side formatting check on its own, but
   it is not a separate requirement: `make lint` already covers it, and running
   both would check formatting twice. Never invoke eslint or prettier directly;

TODO.md

@@ -1,15 +1,12 @@
 # Workflow
 
-- branch from `next`
+- branch (from `main`)
 - do the work in Next Step
 - move Next Step to the top of Completed Steps
 - move the top item of Future Steps into Next Step
 - commit (`TODO.md` changes in the same commit as the work)
+- merge to `main` if the branch is not protected, otherwise open a PR
 - push
-- open a pull request that targets `next`
-- once the pull request has passed review, the repository manager squash-merges
-  it into `next`
-- only sneak merges `next` into `main`
 
 # Status
 
@@ -25,16 +22,6 @@ declares one.
 
 # Completed Steps
 
-- 2026-09-29: The "Workflow" list at the top of this file now says to branch
-  from `next` and open a pull request that targets `next`, that the repository
-  manager squash-merges a reviewed pull request into `next`, and that only sneak
-  merges `next` into `main`, as the README does (issue 137).
-
-- 2026-09-29: The README's "Development workflow" and "For LLMs" sections now
-  say work branches from `next`, every pull request targets `next`, the
-  repository manager squash-merges reviewed pull requests into `next`, and only
-  sneak merges `next` into `main` (issue 135).
-
 - 2026-09-29: Brought the README and this file in line with `next` after the
   milestone merge (issue 132). The Next Step says no implementation work is open
   and the cache design (issue 36) waits on sneak's review. README corrections: