---
title: "The Pre-Release Scan Was Checking Only One Direction"
canonical: https://dxdev.com/blog/2026-08-18_the-pre-release-scan-was-checking-only-one-direction/
datePublished: 2026-08-18
---
A scan we run before every release meeting reported the board and the code in sync, no discrepancies, nothing to chase down. That verdict was about to go straight into the meeting.

## What the scan believed

The report read clean: every ticket the release diff touched had a matching entry on the board, no leftover references, nothing missing. It was a real check, and it had passed. The person about to run the meeting pushed back anyway, from memory: last time, something in a different part of the codebase hadn't been flagged properly, and they wanted it checked again before trusting a clean read.

## What was actually true

The pushback was right, and the scan's own design explained why. Every check it ran started from the pending code changes and asked whether the board agreed with them. That direction can catch a ticket wrongly marked or missing from the diff, but it structurally cannot catch a ticket the meeting would read out loud that the diff never contained at all, because there was nothing on the "code changes" side to compare against. A scan built entirely around "does the board match this diff" is blind to "is there a ticket on the board this diff should have touched and doesn't."

Rebuilding the check the other way, starting from every ticket on the board and asking what the code history actually says about it, immediately surfaced seven real discrepancies on a release the narrower scan had called clean minutes earlier: tickets carrying a release label whose code had never actually reached the branch that ships, and at least one ticket whose work lived in the codebase under a different label than the board's own field claimed.

## The fix's own blind spot

The rebuilt check went in as three new rules. One of them was itself wrong. It flagged two tickets as anomalies because their code lived only in a separate pipeline the main release doesn't touch, treating that as a mismatch. It wasn't. That separate pipeline is supposed to carry the same release label, by design, and ships on its own cadence a little later. The false flag was caught about an hour after it shipped, once that pipeline's actual release ran and gave something real to check the new rule against, and it was demoted from an anomaly to a plain note in the same meeting summary.

## What shipped

The release meeting now reads from a check that looks both directions: board to code, and code to board. Seven real gaps got found the same morning they were finally visible, and the one new rule that cried wolf on correct data got corrected before it could do that every single week going forward. The clean report that started this had already earned trust it hadn't verified; the only reason the actual gaps surfaced was that someone declined to accept a clean read from memory of what had gone wrong before.