9 August 2026
Give the RSS briefing a tiny reliability contract
Now that scheduled briefings are reaching an RSS reader, the useful next step is not more machinery but a small definition of “healthy.” Check that each run produces exactly one dated item, that its GUID stays stable when the site rebuilds, and that a failed generation or push becomes visible somewhere other than a forgotten log. A lightweight smoke test could fetch the published feed, locate today’s item, and reject duplicate GUIDs or an unexpectedly empty body. The follow-up question worth answering is: how late can a briefing arrive before it is no longer useful? That gives the monitor a meaningful threshold.
Turn the week’s friction into three small technical notes
There is already a strong batch of post-sized material: the exact macOS SSH keep-alive setup (including why user-level config may be preferable), what survived the VPS consolidation checklist, and the trade-off between Zed and GoLand for Git conflict work. Give each note one reproducible command, one failure mode, and one sentence on when the advice does not apply. That format is fast to write and more durable than a broad review. A useful experiment is to draft all three titles now and publish the first note that can be verified in under twenty minutes.
Make the consolidated VPS boring to recover
Consolidating four small servers into one lowers maintenance overhead but increases the blast radius of a single host failure. A good Sunday-sized task is to write a one-page rebuild order: DNS and SSH access first, then data stores, then stateless apps, then TLS and monitoring. Pair it with one encrypted off-host backup and actually restore a representative app into a temporary directory. Record the recovery time and the one missing secret or configuration file you inevitably discover; that result is more valuable than another backup job that has never been tested.