Skip to content

Record operations as recurring work, not as a finished milestone - #54

Merged
ptr727 merged 2 commits into
developfrom
record-operations-as-recurring-work
Aug 8, 2026
Merged

Record operations as recurring work, not as a finished milestone#54
ptr727 merged 2 commits into
developfrom
record-operations-as-recurring-work

Conversation

@ptr727

@ptr727 ptr727 commented Aug 8, 2026

Copy link
Copy Markdown
Owner

TODO.md only. No code, no content, no workflow change.

Do not merge this before #51. That promotion is open against develop, and merging here first pulls this commit into it and invalidates the verification its body describes.

Why

The backlog listed the periodic log review and the off-host log pull among the one-off migration tasks. A reader finishing that list would read the migration as done, while neither duty has ever run on its cadence — which is the shape a recurring duty has right before it silently becomes a one-off. Both move into a Recurring operations section that says outright that everything above it ends and this does not, and the State table gains an Operations row so the summary stops implying the deploy pipeline is the whole system.

The decision this records

The operational tooling has no home in git. vps-backup-pull, its systemd units, and the environment variables naming both ends of the copy exist only on the Proxmox host — which is the host the backup runs from. Losing it loses both the copies and the means of making them, and the instructions that produced them live in a channel file this repository deliberately does not carry.

Two candidate homes are recorded without choosing between them: here, beside the deploy tooling the same host runs, or the home-automation config repository with the rest of that host's configuration.

One instance of the cost is already measurable rather than hypothetical. build-redirects.py exists in three places: twice under the capture directory, identical to each other at 115 lines, and once here at checks/build-redirects.py, the maintained copy at 225. The capture is not a git repository, so nothing detects the drift.

The same open question covers the other thirteen migration scripts in the capture — the wp2hugo run, the content restructure and clean passes, media localization, the crawl and mirror, the golden-URL build, the media inventory. Some are worth keeping only if generalized and some are cheaper to rewrite than to maintain, so it is a per-script call.

Two open questions closed with measurements

  • HUGO_BASEURL on the production environment held https://blog.insanegenius.com/, the live WordPress address. deploy-site-task.yml uses that value twice: it builds with it, and it points check-live-urls.sh at it. A production deploy would have baked the old platform's address into every canonical tag, feed link and sitemap.xml, then sent 1,245 requests at the live site to verify it. Now set to the interim .net name; the revert at M7b is recorded as the unfinished half.
  • The first production deploy does not fix the /robots.txt 404 the VPS agent raised in its §22.10. hugo.yaml sets no enableRobotsTXT, so this site emits no robots.txt at all and the 404 survives the deploy, leaving X-Robots-Tag as the only control. sitemap.xml is emitted and becomes fetchable on the interim hostname at that same deploy. A crawler therefore gets a full sitemap and no robots file.

Also filed from this work: #52 (gallery captions render as a stray text node) and #53 (the log pull, written and tested but not installed).

Verification

markdownlint-cli2 and editorconfig-checker clean. cspell is not run against TODO.md by CI, which gates README.md and HISTORY.md only, so it was run by hand — the file's twelve unknown words are all pre-existing except one British spelling this branch introduced and then fixed.

Nothing in this branch changes the built site, so the local-mirror gate does not apply.

🤖 Generated with Claude Code

Copilot AI lite review requested due to automatic review settings August 8, 2026 04:02

Copilot AI left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Pull request overview

Updates the repository’s running backlog (TODO.md) so ongoing operational responsibilities (log review cadence and off-host log pulls) are tracked explicitly as recurring work rather than appearing as one-off migration milestones.

Changes:

  • Extends the “State” table to include an explicit Operations row, and refines the VPS production status entry.
  • Introduces a new “Recurring operations” section and moves the periodic log review + off-host log pull items into it.
  • Records an open decision about where operational tooling should live, and adds issue link references for #52 and #53.

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

ptr727 and others added 2 commits August 7, 2026 22:00
The backlog listed the log review and the off-host log pull among the
one-off migration tasks, so a reader finishing that list would read the
migration as done while neither duty had ever run on its cadence. Both
move to a Recurring operations section that says outright that everything
above it ends and this does not, and the State table gains an Operations
row so the summary stops implying the pipeline is the whole system.

The open decision behind them is that the tooling has no home in git.
vps-backup-pull, its systemd units, and the variables naming both ends of
the copy exist only on the Proxmox host, which is the host the backup runs
from, so losing it loses both the copies and the means of making them.
Two candidate homes are recorded without choosing between them.

The same question covers the fourteen migration scripts in the capture
directory, and one of them already shows the cost of leaving it open:
build-redirects.py exists in three places, the two capture copies
identical to each other at 115 lines and this repo's maintained copy at
225. The capture is not a git repository, so nothing detects that.

Two open questions are closed with measurements rather than assumptions.
The production environment's HUGO_BASEURL held the live WordPress address,
which the deploy workflow both builds with and points the live check at,
and it is now the interim name. And the first production deploy does not
fix the robots.txt 404 the VPS agent flagged in its 22.10: hugo.yaml sets
no enableRobotsTXT so the site emits none at all, while sitemap.xml is
emitted and becomes fetchable at that same deploy.

The VPS production row said the resource was deliberately disabled, which
its own file contradicted twenty lines later.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
The gallery caption entry under Open decisions is gone: #55 answered the question
it posed, against the captured live site, and closed #52 with it.

Two findings from the VPS agent's §23.3 and §24.3 replace it.

The robots.txt entry described a gap on the interim name and missed that the
cutover makes it a loss. The live .com blog serves a robots.txt today carrying a
Sitemap: line, and this site emits none, so M7b moves a site that has had crawl
directives for years to having none and takes the sitemap pointer with them. That
side found it from the outside, will not put a file in this bundle, and has made
it block step 1 of the M7b checklist rather than be discovered after it. Recorded
as deliberately undecided with the three options, and Open decisions points at it
rather than restating it, so the two cannot drift.

Nothing checks that media survived the trip to the server. A 3,095-request gate
run fetched no image at all, which prompted the question of whether the legacy
media list is wired in. It is, at build time, against files on disk. The live
check requests pages and redirects and never an image, so a media tree lost
between the build and the server is caught by neither, the build having passed
before the loss and the live gate never asking.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Copilot AI review requested due to automatic review settings August 8, 2026 05:02
@ptr727
ptr727 force-pushed the record-operations-as-recurring-work branch from e362e54 to 4d64eed Compare August 8, 2026 05:02

Copilot AI left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Pull request overview

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

@ptr727
ptr727 merged commit 83966a5 into develop Aug 8, 2026
5 checks passed
@ptr727
ptr727 deleted the record-operations-as-recurring-work branch August 8, 2026 12:53
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants