The pane-swap idea from the night before got built starting just after midnight, in the same session that had been planning it. The first push to dev/v3 came back wrong: clicking the blog tree opened nothing, and the whole thing looked broken on contact.
Six rebuilds to get the pane right
The reset came down to what "freeze pane" actually meant. The explanation that finally landed: the header stays fixed like a spreadsheet freeze pane, everything under it is the explorer, and clicking a link in that explorer loads new content into the viewing pane without the header ever reloading. The pattern is one other sites use too: a fixed header and nav that never move, with everything below it swapped in place from whatever gets clicked.
Six commits came out of getting there. The first regenerated dev/v3 with pane-swap navigation. The second generated all 46 real post pages for the preview instead of the five-entry fixture it had been running on. The third made the swaps instant, cutting the transition from 580ms down to 15ms while leaving the initial page load untouched. The fourth built the actual freeze-pane layout: the document stops scrolling, and content scrolls inside a bounded pane with a 1px leading edge and pinned corners. The fifth removed that edge; the line resting under the middle pane's text didn't sit right. The sixth wired the blog breadcrumbs live: clicking "Blog" loads every post, clicking a year narrows to that year, clicking a month narrows further, all rendered into the pane with the URL never changing. That last piece was the one described since the "all posts" link turned out to just point at the blog landing page instead of a real listing.
By the end it was workable but not finished, close enough to build on.
Two posts written to bring the blog current
With the pane working, the next job was catching the blog up. Two research agents ran in parallel to write the 9th and the 10th: the 9th had no vault journal at all and was reconstructed from git and session transcripts, and the 10th was written first-hand since it was the same session that had done the pane-swap planning the night before. Both went out through the staging-journals method. Pointing build_blog.py at the real journals directory instead would have overwritten 34 published posts' titles, since it still holds the "No work evidenced" stubs from the August sweep. git diff on the published posts showed only the two new files, plus one nav link update on the 8th. The blog went from 46 posts to 48, and the dev/v3 preview regenerated to match.
A go-live stopped by its own risk list
With the pane working and the blog current, the next request was to take the whole dev/v3 design live, replacing the current site at ericli.n5hq.me, with the existing site archived alongside the old v1 as a new v2. Before touching routing, four problems came back from a recon pass. Every dev/v3 page carries a deliberate noindex, nofollow meta tag from the build, which would de-index the live site if promoted as is. /dev/v3/assets/ and /assets/ both exist and a naive merge could overwrite live assets. The live site has a lab/ section, four portfolio/ sub-pages, and a Contact route that dev/v3 doesn't have equivalents for, all of them linked from the sitemap. And copying dev/v3's index.html to the repo root, or rebuilding it with --base=/, would each break www.n5hq.me in a different way: a root index.html overrides the host-conditional routing this repo's own notes already warn about, and the base-path rebuild would turn every internal link into a protocol-relative //assets/… href.
Three open questions came out of that: whether the five portfolio sub-pages get archived into /v2/ or ported into the new design, whether the blog archives there too or stays live only at its real URLs, and what to do about /v1 already being publicly fetchable today, including eight raw journal markdown files. I answered all three at the very end of the session: use the up-to-date dev/v3 subpages, use dev/v3's blog over v2's, and leave /v1's exposure as is. Nothing was built from those answers that night. The migration itself is still ahead.
A dead backup job, unplugged for good
In the middle of the pane work, a separate and unrelated question came in: Proxmox VE had been emailing that the 1am vzdump job on pve01, pve02, and pve03 was failing every night, while a 2:30am job succeeded right after. The 1am job turned out to be the PBS trial job, which had been dead since August 27th and was already documented as such. It got disabled with enabled 0 on the job, verified propagated to all three nodes through /etc/pve. The 2:30am CIFS job to the NAS was left untouched, so nightly backups keep running either way.