Document the periodic log review, in both directions

[ptr727]

Captures a design decision from the migration that had survived only as a one-line first-week task, which is not a periodic process.

Why

Real traffic is the only source that finds what every check here is blind to. The URL contract proves the 328 URLs someone thought to list and the 917 redirects derived from the export. It cannot know about a URL nobody recorded, because the crawl that produced the lists is the crawl the lists are checked against. A visitor following a sixteen-year-old link is the one reader who tests that.

Both directions, because they are blind to each other

The same two the media checks read, for the same reason:

Direction	Question	Signal	Cadence
Outward	What did someone ask for that is not here?	non-200 responses	daily for the first week after cutover, then monthly
Inward	What is here that nobody has ever asked for?	URLs absent from every 200	quarterly at the earliest, a long tail by nature

Outward is the one with an action — add the URL to checks/golden-urls.txt, add a redirect. Expect the raw counts to be dominated by scanners probing wp-login.php and .env, which is noise from a site that used to run WordPress.

Inward answers a question nothing else can, and it has an immediate concrete use: the 97 carried media files the old platform never published. If nothing requests them across a year, that settles whether carrying them is preservation or clutter — and no reasoning from this repository can settle it.

Three tiers, each blind to something

A request crosses the proxy before it reaches the site, so no single log answers both questions:

Tier	Sees	Cannot see
Traefik / Pangolin's Traefik on the VPS	every request reaching the host, including unknown hostnames, TLS failures, names this site does not serve	which release answered
Pangolin, VPS only	requests the auth gate rejected	the local mirrors, which have no gate
Caddy, per environment	path, status, and the X-Blog-Release that answered	anything the tiers above rejected

A 404 count from Caddy alone is a floor, not a total. A request the edge refused is a reader who found nothing just as surely, and it appears in no Caddy log.

Two parsing traps, both of which silently yield nothing

• The Caddy access log is format console — a line is a timestamp, level, and logger name followed by a JSON object rather than being JSON. A parser assuming one object per line reads zero records.
• trusted_proxies is what makes client_ip the reader rather than the proxy. Without it every request appears to come from one internal address and the inward pass cannot tell a reader from a health check.

Retention is the prerequisite, and it is not configured

The containers use Docker's json-file driver with no rotation and no size limit — /etc/docker/daemon.json sets only a storage driver, so built-in defaults apply. The log grows without bound, and is discarded entirely when the container is recreated. The first is a disk risk on a VPS; the second silently resets the window the inward pass depends on being long.

Nothing here fixes it, because the log driver belongs to the host rather than to this repository — the same split Retention and Who Owns What already describe for release pruning. It is recorded in TODO.md and dated to the cutover, since a review reads whatever survived and reports confidently on it either way.

Verification

Documentation only. markdownlint and editorconfig-checker clean; no code, config, workflow, or content change, so the build and URL contract are untouched.

The claims about the running system were checked rather than assumed: the log directive and format console in deploy/Caddyfile, the containers' actual access-log output, the json-file driver with empty options, and /etc/docker/daemon.json carrying only storage-driver. The VPS tiers are described from OPERATIONS.md's existing environment table rather than from access I do not have, and the text says which is which.

🤖 Generated with Claude Code

[Copilot]

Pull request overview

This PR documents the periodic log review process (both “outward” and “inward” directions) as an operational procedure, capturing post-migration practices and constraints that aren’t enforceable via the repository’s automated URL checks.

Changes:

• Adds an OPERATIONS.md “Log Review” section describing the two-direction review, the three logging tiers, parsing pitfalls, and why Caddy-only counts underreport.
• Updates TODO.md to record the log-retention prerequisite and to point readers to the new operational procedure for ongoing review cadence and interpretation.

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated no comments.

File	Description
TODO.md	Records the retention prerequisite and references the documented periodic log review procedure.
OPERATIONS.md	Introduces a “Log Review” section defining process, tiers, pitfalls, and retention constraints.