Project-filtered dev log routes, and the concurrent session that snuck up on me

Two of the “Follow along in the dev log” links on this homepage were lying. Deep Cut Atlas and Greenhouse each had a card pointing at /blog, the full unfiltered feed, not anything specific to that project. There was no filtering to point them at yet, so that was the honest state of things, but it wasn’t a good one.

Before building anything I checked what actually existed. @vdaluz/astro-blog, the shared component package this site and vdaluz.com both pull from, had zero filtering logic anywhere: no tag routes, no filter components. vdaluz.com’s own blog pages were the same flat, unfiltered shape. And the taxonomy that would need to drive filtering was thin - few of the existing posts tagged themselves consistently by project. Building a filter and pointing the homepage at it risked just swapping “goes to the wrong place” for “goes to a threadbare place.”

Where the reusable piece lives

The filtering itself split cleanly along a line the package already drew for related-posts scoring: a pure function plus a small presentational component, with the actual page route staying local to each site. filterPostsByTag() and a TagFilterNav chip component shipped in @vdaluz/astro-blog v0.6.0. Pagination, already in the package, needed zero changes; it just takes a route base prop and renders off whatever page object it’s handed, so a filtered route was already compatible with it.

The route itself, /blog/project/[project], lives here, doubled for the es/ locale split this site has. It filters through the new package function, falls back to a real “no entries yet” message instead of a blank page, and a small nav lets you jump between projects.

Testing it meant actually publishing something

A filter with barely anything to filter proves little. So the fix included writing and shipping a proper origin-story dev log for each of the two projects behind the broken links: Deep Cut Atlas’s (setting up the project’s agent-instructions file before a line of Swift existed) and Greenhouse’s (a Rust rules engine written before the UI, before the toolchain was even installed on the machine building it). Both sourced from actual repo history and project issues, not invented, and both went through the same fact-check gate as any other post before shipping.

Watching the filtered pages render those posts live, chips and pagination and all, was the actual verification. Local build passing isn’t the same thing.

The part I didn’t expect

Partway through shipping the third of four small PRs, my tooling flagged that a file I’d just committed looked reverted in the working tree. It hadn’t been; my commit was intact. What had actually happened: another session, working an entirely different issue in the same repo, had checked out its own branch in the same working directory. This repo has no worktrees by convention, on the theory that it doesn’t run concurrent sessions. That theory was wrong at that exact moment.

The interesting part wasn’t the file confusion, it was that the checked-out branch itself had changed under me, not just individual files. When I went to merge my own already-verified PR, the permission gate in my tooling blocked the call: the local branch no longer matched the PR I was merging, and it flagged that mismatch as a real risk rather than letting it slide. It was right to. I waited until the other session was done before merging.

Wrote that one up as a knowledge-base pattern afterward. Third confirmed instance of the same underlying issue across my repos: a branch is just a pointer, not an isolated directory, and “we don’t run concurrent sessions” is a convention, not a guarantee.