---
title: "The Unclaimed Ticket That Quietly Inherited the Wrong Directory"
canonical: https://dxdev.com/blog/stop-guessing-the-clone/
datePublished: 2026-05-13
---
The platform runs on four parallel clones: clone two, clone three, clone four, and a base clone that carries no number at all. Different tickets get routed to different clones so work doesn't collide. With a fresh ticket and correct routing, this works fine. If the agent guesses a clone before confirming where the ticket belongs, it can walk into the wrong directory and start editing with full confidence.

## What the old routing skill did

A fresh ticket made the agent look at the available clones and pick one. When session context was ambiguous, the pick tended toward the base clone. That clone is valid for some work. It is wrong for a ticket that belongs on clone three. Once the agent has a plausible answer it doesn't second-guess it, and "the clone is there and it is not locked" is a plausible answer.

The fix we shipped was a policy change. Fresh tickets now default to read-only review. The agent reads the ticket, reads the relevant code, and surfaces a plan. It does not check out a branch or edit a file until the session has been explicitly attached to a clone and that attachment is confirmed. Write access has to be earned.

## The fallback hiding in session attach

Session attach had a subtler version of the same problem. When work was "unclaimed" (no session had declared ownership), the system needed a fallback, and the fallback was the base clone. It wasn't clone two or whichever clone fit the current ticket. It was the first plausible checkout matching the default name.

A default like this hides well. Most of the time, unclaimed work isn't being actively edited, so the wrong fallback never fires. Then a session gets interrupted, or the session manifest doesn't get written correctly, or a command runs in a context the system didn't anticipate. The fallback kicks in and the agent is operating on the wrong clone. If it checks, it catches the mismatch immediately. If it doesn't, it carries on.

So unclaimed work no longer silently inherits a clone. If the session has no explicit attachment, the system surfaces that gap and stops. The agent either establishes the right attachment before proceeding, or it tells us it can't determine where to operate.

## The orientation prototype, aimed upstream

While the routing policy handled the failure after it happened, we built the orientation prototype to go after the cause.

It is a per-session chrome layer. When a session opens, the browser lands directly on the session page with the key already prefilled. A strip under the header shows the current area, epic, and task, with a unified picker to set or change any of them. The agent doesn't have to infer context from environment state or file structure, because the session starts with orientation already declared.

The routing policy covers what happens when the agent guesses. The orientation layer removes the need to guess: with area, epic, and task declared, the agent knows which clone the work belongs on before it reads a single file.

Phase 2 (inline pickers in the conversation stream, new-task and new-epic create flows) is not built yet. What shipped on the 13th was the session-start surface: chrome opening on the right page, key prefilled, orientation strip visible from the first prompt.

## Confidence is the failure mode

Agents always work from incomplete information, and most guesses are fine. The trouble is that the agent proceeds with the same confidence after a guess as after a verified fact.

Ask a human collaborator which directory a ticket belongs in and they signal their uncertainty. They say it's probably clone three but they'll check, or that they aren't sure and will look at the session manifest. They don't disappear for five minutes and come back having edited files in a directory they weren't sure about.

The routing policy and the session attach hardening both force that uncertainty to surface before the write happens. Read-only by default means a wrong guess costs a plan that needs correcting, not a file that needs reverting. With no silent fallback, the gap has to be filled explicitly.

If your AI workflow guesses the repo before it proves context, it will eventually edit the wrong thing with confidence. The fix is removing the path where the guess is enough to proceed.

## One thing to check

Find out what happens in your workflow when a piece of work has no confirmed home: does it fall back to a default checkout, or does it stop and say so? Require read-only review until the target is explicitly confirmed.