README, TODO and the viewport README say what the tree does (closes #24)

README.md: Getting Started leads with make targets; a Backend section
gives netwatch-server's routes and how the image builds and runs it;
the checks are GET requests; the WAN host list, health states, summary
figures, sorting and missing features match src/main.js; the TODO
section points to TODO.md, which holds the one to-do list.

backend/README.md: its TODO section points to TODO.md too, whose
Future Steps take its three open items.

TODO.md: Workflow branches from next and opens the PR against next;
Status, Next Step and Future Steps describe the open work, linked to
its issue where one exists.

test/viewport/README.md: the unit tests run on Node's test runner,
not vitest.

Model: opus-5-5

TODO.md

@@ -1,28 +1,38 @@
 # Workflow
 
-- branch (from `main`)
+- branch from `next`
 - 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
+- push the branch and open a PR against `next`
 
 # Status
 
-pre-1.0. No git tags. `feat/reportbuf-storage` is merged; the backend, the CI
-workflow, and the backend repo standard files are all on `main`. Frontend and
-backend are both functional. Working toward the 1.0.0 milestone by closing the
-remaining repo-compliance issues on the tracker.
+pre-1.0. No git tags. `main` is the stable branch and `next` the development
+branch, which every PR targets. The frontend and the Go backend ship as one
+Docker image, and the Gitea workflow `.gitea/workflows/check.yml` runs
+`script/cibuild` on every push. Working toward 1.0.0.
 
 # Next Step
 
-Confirm the `.gitea/workflows/check.yml` run is green (main always green
-policy). The workflow file is already on `main`; what is unverified is that its
-latest run passes.
+Take "IPv4 only" out of the page's footer, as nothing in the page limits a check
+to IPv4 ([#111](https://git.eeqj.de/sneak/netwatch/issues/111)).
 
 # Completed Steps
 
+- 2026-10-04: `README.md`, `TODO.md` and `test/viewport/README.md` say what the
+  tree does (issue #24). The README's Getting Started leads with `make` targets;
+  a new Backend section says what `netwatch-server` stores, its routes and how
+  the image builds and runs it, and points to `backend/README.md` for its
+  settings; the checks are GET requests; the 26 WAN hosts, the four health
+  states, the summary's figures and the features the list lacked are described
+  as the page has them; and its TODO section points here, as does the one in
+  `backend/README.md`, whose open items moved to Future Steps. This file's
+  Workflow branches from `next` and opens the PR against `next`, Status says
+  where the repo stands, and Next Step and Future Steps hold only open work,
+  linked to its issue where one exists. The viewport harness README names Node's
+  test runner, not `vitest`
 - 2026-10-04: in `src/main.js` (issue #102), a target's min, max, median and
   average latency come from one list of its answers, through the same function
   the summary's figures use, so the median is written once. The latency color
@@ -374,12 +384,17 @@ latest run passes.
 
 # Future Steps
 
-- Wire `script/frontend-viewport-test` into CI as its own step (deliberately not
-  part of `make check` today; the decision has real CI-runtime cost and is
-  tracked separately)
-- Compliance top-up as one small commit: add .editorconfig and add the hooks
-  target to the Makefile
-- After merge, confirm .gitea/workflows/check.yml is on main and CI is green
-  (main always green policy)
-- Decide what to do with untracked resume.sh: commit it, gitignore it, or delete
-  it
+- Decide whether the repo moves to the layout `REPO_POLICIES.md` gives, with
+  `backend/` no longer repeating files from the root
+  ([#30](https://git.eeqj.de/sneak/netwatch/issues/30))
+- Run `make frontend-viewport-test` in CI as its own step; it is not part of
+  `make check`, as it needs Docker and takes minutes
+- A backend test that posts a report to `POST /api/v1/reports` and checks the
+  compressed file it is written to
+- A backend route that decompresses the stored reports and answers queries on
+  them
+- Prometheus metrics for the backend's in-memory buffer: its size, the number of
+  flushes and the number of reports
+- A configurable host list (an environment variable or a config file)
+- Export of the latency history (CSV or JSON)
+- A notification when the health status changes to DEGRADED