---
title: "What Version 3.364 Still Owed After the Deploy Passed"
canonical: https://dxdev.com/blog/release-process-hidden-second-pass/
datePublished: 2026-08-25
---
The legacy release was live, the tag was pushed, the deploy had passed, and the week was not closed.

The legacy lane had finished its merge, tag and deploy ritual. The two grid lanes had no code waiting for production, so nothing in the release looked unfinished. But the object we were supposed to close was the shared minor across three repositories, and we had treated the legacy tag as the finish line.

## Why the quiet lanes got skipped

The release process was already split into three lanes. One uses `master` and a conventional versioned deployment. The other two promote on their own production branches. That asymmetry had trained our attention. The first lane produced a meeting, a visible version and a deploy result. The other pair produced less noise, and their separate pass lived after the meeting, in a new session, instead of in the main release moment.

That split was intentional. The original cadence let the legacy lane ship on release day and deferred the grid lanes by a day or two, until the process was boring enough to combine. A short delay did not mean a broken release. Closure meant all three lanes released and carrying the same minor.

The release scan was already built to look past the visible lane. Its `--no-sidecars` option skips the grid and continuously deployed lanes, which makes the default scope clear. We let the normal scan turn into a habit of reading one lane. The tool already showed the other lanes. What it lacked was a named moment that made us come back after the meeting and finish the proof.

That sounds tidy as a flow description. In the work it was fragile. A person had to remember there was another session. A lane with nothing new to deploy still needed a version tag. With no named closeout step, we could finish the visible part, read `live`, and never get evidence that the week was closed.

## A stale copy turned up first

Earlier that day, a Claude session started on what looked like a different problem: routine hotfixes were getting botched. The investigation found an old copy of the release instructions inside the `/item` skill. It was four months out of date, it contradicted the canonical steps, and it sat close enough to the agent's entry point to win. A branch-ancestry guard could also have let a develop-cut branch through into production.

Claude did not fail by being vague. It followed specific, executable-looking instructions that no longer matched the real release path. Real hotfixes had already gone out botched on the strength of that copy before anyone traced the pattern back to a stale duplicate. We first filed it as a hotfix documentation cleanup. Then the release closeout showed that the stale copy and the remembered follow-up had the same shape. The copied skill and the guard got repaired. But a critical instruction could live as a stale duplicate or as a remembered afterthought, and in both cases a command could finish its local work and leave the process incomplete.

## Making the last pass startable

Adding more paragraphs to `ai/shared/workflow` would have repeated the original failure. That file already held release rules, and a station-side note warned against copying them. So we made a named `/post-release` skill. It adds no new release theory. It gives the manual follow-up an entry point and a closure test.

Running it against `3.364` gave a useful, embarrassing result. Both grid lanes were already level with production, so nothing needed shipping. All three repositories still owed the weekly version tag, and the skill confirmed the tags on origin. The second pass exposed missing release identity across the three repositories, with no deployment involved.

That changed what we could automate. In this configuration, deployment workflows react to branch pushes only. A tag push creates no deployment trigger, so the operation can create and push the missing minor tags without rerunning the release. The tag is proof of shared version state across lanes.

## Two endings, one runbook

The runbook fix mattered as much as the skill. It left out the second pass, and one check meant to cover the whole process contradicted itself. A legacy deployment tag can be perfectly real and still say nothing about whether every repository carries the same weekly minor.

No new code was needed in the grid lanes for `3.364`. The missing work was three tag references on origin, on repositories that had shipped nothing new that week. We had already called the week finished, out loud, before those three refs existed.

A release is closed when every repository carries the same weekly minor and a named step has checked it after the release meeting. Where a critical instruction lives only as a stale copy or a remembered follow-up, it needs a single canonical home and an entry point.