The release step that never made it into docs

The legacy release was live. Its closing pass did not exist.

The loud lane had completed its merge, tag, and deploy ritual. The two quieter grid lanes had no code waiting for production, yet the release train was unfinished. I treated the legacy tag as the finish line, when the shared minor across three repositories was the unfinished object.

The empty lanes hid the unfinished work

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

That distinction 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 signal a broken release. Closure required all three lanes released and carrying the same minor.

The release scan was already designed to inspect more than the visible lane. Its --no-sidecars option explicitly skipped the grid and continuously deployed lanes, which made the default scope clear. I allowed the normal scan to become a single-lane reading habit. The tool already showed the other lanes. What it lacked was a named moment that forced me to return after the meeting and finish the remaining proof.

That sounds tidy in a flow description. It was fragile in the work. A person had to remember there was another session. A quiet lane with nothing new to deploy still needed a version tag. Since there was no named closeout step, I could finish the visible part, read live, and never obtain evidence that the week was closed.

Claude found copy drift before it found closure

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

Claude did not fail by being vague. It failed by finding specific, executable-looking instructions that no longer matched the actual release path. Real hotfixes had already gone out botched on the strength of a four-month-old copy of instructions that contradicted the canonical steps, before anyone traced the pattern back to a stale duplicate near the agent’s entry point. I initially called the stale copy a hotfix documentation cleanup, but the release closeout showed that the stale copy and the remembered follow-up were the same failure shape. The copied skill and guard got repaired. A critical instruction could live as either a stale duplicate or a remembered afterthought. In both cases, a command could finish its local work and still leave the process incomplete.

I made the last pass startable

Adding more paragraphs to ai/shared/workflow would have repeated the original failure. The file already held release rules, while a station-side note warned against copying them. I made a named /post-release skill instead. Its value was no new release theory. It gave the manual follow-up an entry point and a closure test.

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

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

The release had two endings

The runbook correction was as important as the skill. It omitted the second pass and contained a contradiction in a check intended to cover the whole process. I made the classic operational mistake of trusting the most ceremonial artifact. A legacy deployment tag could be real. It still had no power to show whether every repository had the same weekly minor.

No new code was required 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. I had already called the week finished, out loud, before those three refs existed.

dxdev LESSON · paste into your AI coding agent
LESSON: The Loudest Release Lane Is Not the Same Fact As the Release Being Done
SOURCE: dxdev.com/blog/2026-08-27_release-process-hidden-second-pass
WHAT HAPPENED: A release process spanned three lanes/repositories: one loud lane with a conventional merge-tag-deploy ritual and a meeting, two quieter lanes that promoted on their own branches with no equivalent ceremony. The release scan already supported inspecting all three (a --no-sidecars flag explicitly skipped the quiet lanes, meaning the tool showed the full scope by default), but with no named step forcing a return to check them, the visible lane's "live" status was mistaken for the whole release being closed. A separate investigation into botched hotfixes traced back to the same root shape: a four-month-out-of-date copy of release instructions living inside an agent skill, close enough to the entry point to be followed instead of the canonical steps. Running a new named /post-release skill against the current release found both quiet lanes needed nothing deployed but were still missing their weekly version tag, on all three repositories, with no code changes involved.
THE RULE: In a multi-lane or multi-repo process, the lane with the most visible ceremony (a meeting, a deploy notification) is not evidence the other lanes are also closed; a process needs a named, run-every-time closeout step that checks every lane against the shared definition of done (here, a matching version tag across three repos), because "nothing needed shipping" and "the process is closed" are different facts, and a stale duplicate of a runbook sitting near an entry point will get followed over the canonical one until someone corrects it.
CHECK MY CODE, then report PASS or FAIL with file:line for each:
  1. Any multi-lane, multi-repo, or multi-service release/deploy process where one component has a visible ceremony (meeting, tag, notification) and the others do not, with no explicit closeout step verifying all components reached the same defined-done state.
  2. Any copy or summary of a canonical runbook/process doc living closer to an agent's or tool's entry point than the canonical version, risking the stale copy being followed instead.
  3. Any release or deploy tool with an option to skip certain scope (like --no-sidecars) that has become the default habitual invocation, rather than the exception it was designed to be.
THEN PRINT: a table (check, PASS/FAIL, evidence, fix) + a verdict (applies / partially / OUT_OF_SCOPE / no) + the single most important next action.