Record the log pull as installed, and the rename it does not carry

[ptr727]

Both records here said the off-host access-log pull was not installed. It is, and both were written before it was. An operational document that understates what runs misleads exactly as much as one that overstates it, so the correction is the same size either way.

What changed

TODO.md State table and the #53 entry. The pull is installed as vps-backup-pull.timer, 09:00 UTC daily with Persistent=true, and a first copy exists: 42 archives and 4 log files, 2026-08-08 12:59 UTC.

The distinction kept is that the timer has never fired. That first run was started by hand, so systemctl list-timers reports LAST as -. One copy is a fact; "backed up daily" is still a unit file until the first scheduled run on 2026-08-09.

The finding the copy produced, which is the more useful half

The pull passes no --delete for the logs, deliberately, since that flag exists to mirror the VPS's fourteen-archive window and must never touch an append-only record. So a file the VPS renames after it has been pulled keeps its old name off-host forever, alongside the new one, and nothing detects the divergence.

That has already happened. The host side found its archived log filenames were a day ahead of their contents, fixed it with dateyesterday, and merged the two existing files. Off-host, the pre-fix name survived:

File	Size	Lines	Contents
access.log-2026-08-08	47,969 B	52	all 2026-08-07, 21:09:27 → 23:26:27
access.log-2026-08-07.gz	4,818 B	58	all 2026-08-07, 21:07:37 → 23:26:27

Verified a strict subset with comm -23 over the sorted line sets rather than assumed one: 0 lines unique to the misnamed file. So a count over the off-host archive returned 110 lines where 58 exist, half of them filed under a date whose traffic they are not — the same defect the host fixed, surviving on the copy the log review will read once the VPS's window rolls past what it needs.

OPERATIONS.md now says to read a date from a line's StartUTC rather than from the filename holding it, and that a host-side rename is something the channel has to carry because no transfer will.

Also recorded

Why restoring mtimes in CI comes after a live media check rather than before. The host side measured zero shared inodes across every release the pipeline has delivered, against 1052 of 3266 built locally, and refuted the call-site hypothesis by testing --link-dest through a relative symlink under rrsync -wo, where it links correctly. The cause is that git stores no mtimes, so a CI checkout writes all 3,272 files inside a 23-second window. git-restore-mtime fixes it and needs no checkout change, since fetch-depth: 0 is already there. The ordering matters because today every file arrives as a fresh inode and --no-g --chmod=D2755,F644 re-establishes the mode contract on every deploy; make the mtimes honest and a third of the tree starts arriving as hard links carrying whatever mode its chain began with.

The log evidence that reframes the robots.txt decision./robots.txt was requested nine times on the interim hostname and answered 404 every time, five from real agents on a name with no inbound links, while no crawler fetched sitemap.xml or feed.xml once — every request to either came from curl. Crawlers are told where a sitemap is rather than guessing, and the only thing telling them is the file the cutover deletes, so the question is whether the sitemap stays advertised at all.

Verification

Documentation only, no behaviour, so the local mirror gate does not apply per OPERATIONS.md "Local Verification Before a Pull Request". markdownlint-cli2 and editorconfig-checker both clean over the changed files.

🤖 Generated with Claude Code

[Copilot]

Pull request overview

Updates operational documentation to reflect that the off-host VPS access-log pull is now installed (but has not yet executed on schedule), and records an observed edge case where VPS-side log archive renames do not propagate to the off-host copy—requiring log analysis to trust per-line StartUTC over filenames.

Changes:

• Update TODO.md state and recurring-operations entries to record the installed vps-backup-pull.timer, its first manual run, and the “rename not carried” behavior.
• Update OPERATIONS.md “Log Review” guidance to reflect the off-host copy’s existence and warn that filename-based counting can double-count when archives are renamed/merged after being pulled.
• Add additional measured context affecting operational decisions (notably around robots.txt / sitemap discovery).

Reviewed changes

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

File	Description
TODO.md	Records current operations state, the installed off-host log pull (manual first run), and the rename-not-propagated finding; adds measured context around robots.txt/sitemap discovery.
OPERATIONS.md	Updates log-review prerequisites and procedure notes to reflect the off-host log copy and the need to rely on StartUTC over filenames when archives are renamed post-pull.

---

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.

[Copilot]

Pull request overview

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