--- title: "The Staff-Center Commits We Reverted Out of Develop" canonical: https://dxdev.com/blog/develop-was-shipping-the-wrong-work/ datePublished: 2026-05-19 --- On the morning of May 19, we opened a release diff for the platform and found seven commits in local `master` that weren't in the remote. That looked like a problem. It wasn't one. The seven commits were already shipped, and local `master` just hadn't synced. Once we pulled, the lag resolved and the diff collapsed to the handful of items actually queued for release. It wasn't. ## the noise that hid the real problem The platform runs on a branch model where `develop` is the release branch, `preview` is a preview surface, and `master` is production. Features go into `develop` when they're approved and ready to ship. That's the invariant: anything on `develop` is cleared for the next release. We had been running several parallel work streams. One was a specific change that had cleared review and was ready. A second was staff-center modernization work, larger and not approved for this release. A third was agent-system plumbing. All three had active feature branches. With the lag cleared, the actual diff showed items from all three streams. The approved change and the unapproved work sat side by side in `develop`, looking equally ready to ship. They had been merged in without a gate. ## how the unapproved work got in The staff-center and agent-system work had landed in `develop` during a prior session. When you work across multiple branches with an AI agent executing git operations, the agent touches the integration branch the same way it touches a feature branch. It doesn't know that `develop` means something different. It knows you said "merge this." The gate is your own memory, applied at every merge. Ours had not been applied consistently. The [agent merged feature work](/blog/onboarding-an-agent-you-dont-control/) into `develop` without us marking it release-pending first. The feature branches still existed, the commits were real and the work was genuine. None of that made it safe to ship in this release window. Nothing in the diff looked wrong. The code was correct and the changes were intentional. The only signal was the shape of the diff itself: larger than expected, and including surfaces we hadn't consciously released. That is hard to catch on instinct. ## the revert We reverted the contaminating commits and kept the reviewed change, because it was approved and belonged in the release. The staff-center and agent-system changes went back to their feature branches, intact and valid, just not in this release. The review observations we had collected while looking at the staff-center work became follow-up tickets. They weren't blockers, and making them blockers would have been the wrong call. The ship went out with the right scope. What we had to do was ask whether every item in the diff had a release decision attached to it. The agent doesn't ask that on its own. ## what we changed Feature branches should stay in feature branches until there is a deliberate release decision. That sounds obvious, but in a high-throughput session with an agent moving fast, the deliberate decision step is the first thing that gets compressed. After this, we added a memory entry to our agent system stating that `develop` merges require explicit release intent, and that technical correctness isn't enough. The memory is read at session start. It doesn't prevent a bad merge, but it makes that path slightly more conscious. We also found a push-hook gap. The platform's git setup does not currently reject a `develop` push that includes non-approved work. That enforcement would have to live in the merge step, either as a checklist the agent runs or as a branch-protection rule requiring a release ticket reference. Neither exists yet. Both are on the list. The immediate fix was manual: check the diff against an approved-items list before any `develop` merge. It's a habit and it isn't automation, but habits carry you while you build the automation. ## parallel throughput changes what integration failure looks like Before AI-paired development, the limit on branch traffic was typing speed and context switching. You could realistically hold two or three work streams in your head. The integration branch grew slowly enough that a bad merge usually announced itself before much damage was done. With an agent running, you can push five streams at once. Each one is coherent and tested. Any single stream can be fine, yet the integration branch now has to be a semantic safety system, not just a place to collect commits. The agent helps us go faster. It doesn't track what has and hasn't been approved for release. That distinction lives in our heads and nowhere else. When we lose it for one merge, the integration branch becomes a misleading artifact. It looks clean, CI passes, and the diff contains work that was never supposed to ship. The merge that contaminated `develop` probably took thirty seconds. Finding it, reverting it cleanly, and getting the right scope back into the release took most of the morning. ## who decides what is cleared Here the release branch collected work that had no release decision, and nothing in the git setup rejected it. Checking every item in a release diff against an approved list catches it today. Branch protection or a release ticket requirement is what keeps the check from resting on memory.