A 106-line handoff note was saved, pushed, and still never arrived

The handoff note was 106 lines long. It was saved and pushed, and the AI session it was written for told us it had received nothing.

What the note was for

We run our day through one AI session we call the hub. It keeps the judgment calls, and every piece of actual work goes to its own separate session that we can see. The hub’s last job each day is to write down where everything stands so tomorrow’s hub can pick up without guessing. The standard sits in the task file: the next hub can act on the note without re-deriving anything, and no work is left only in a dead session’s head.

The day before, that second half had been proven the hard way. Every session running through our bridge died together between 17:02 and 17:10. Work that had reached a commit, a saved and dated snapshot, survived. Work that was still only in a session’s head did not, and that happened twice on one fix.

The close that said “verified”

Yesterday’s hub wrote the handoff before shutting down. It checked each claim against the live ticket system, the live code history and our live mailbox, and did not copy forward from older notes. The note listed what shipped, what was open, six things waiting on our decision, and the hazards. One open item was a fix sitting on a branch with 5 commits, none pushed. Another was a review comment that had been drafted twice and lost twice.

Then it edited the task file so the file pointed at the note. The close took 12m, and the summary it logged said it had closed with “a verified handoff to today’s session 2.”

The word “verified” was accurate for the contents. The facts in the note were true, and the note existed where the pointer said it did. Nobody had checked that it reached today’s hub session.

What the receiving end said

Today’s hub told us it had been handed nothing, so we asked about the handoff. The second close, which started at 10:47 AM and ran 3h 25m, went back through it. The note was on disk, it was pushed, and the task file pointed at it. The session that was supposed to read it never got it, which is why it said it had received nothing.

The six decisions waiting on us were in that note, and so were the 5 unpushed commits and the lost review comment. The assistant gave us one line to paste into the session so the note would finally land.

The same pass caught a smaller version of the problem. An older resume note still listed a fix as open when it had been finished the day before. A stale note left lying around misleads the next reader just as an undelivered one does.

The push nobody tried

A push of documentation changes to the repository we share with our partner sat blocked for most of a day. Our assistant kept reporting it as gated, meaning waiting on an approval step, and never simply tried the push. That approval step had blocked a documentation-only push for fifteen hours without ever catching a real mistake. We removed it on our own call. We also had a log added of every time a guard like that blocks something, so the next one gets deleted with evidence in hand instead of a feeling.

Three questions behind one handoff

Is the note true? Is it saved where it should be? Did the next session receive it? The first two had been answered the day before. Only the third was missing, and it was the one that decided whether the hub started the day with its six open decisions or with nothing.

dxdev LESSON · paste into your AI coding agent
LESSON: A Handoff Is Not Done Until The Receiving Session Confirms It Arrived
SOURCE: dxdev.com/blog/saved-is-not-delivered-handoff
WHAT HAPPENED: The previous day's hub checked every claim in the note against the live ticket system, code history and mailbox, then wrote the note and edited the task file to point at it. The close took 12m and was logged as a verified handoff to today's session. The next day the new hub told me it had been handed nothing, even though the note held six pending decisions, 5 unpushed commits and a twice-lost review comment. A second close that ran 3h 25m confirmed the note was real, on disk, pushed and pointed to, but it had never been delivered to the receiving session. The same pass also found an older resume note that still listed a finished fix as open. The earlier crash had already shown that work only in a session's head is lost, while committed work survives.
THE RULE: Verifying that a handoff is accurate and stored is not the same as verifying it was received. A handoff counts as done only when the receiving session has acknowledged it.
CHECK MY CODE, then report PASS or FAIL with file:line for each:
      1. After writing a handoff, the closing process requires the receiving session to confirm or restate the note's key contents, and the close is not logged as verified until that confirmation exists.
      2. The close summary separates three claims, whether the note is true, whether it is saved where it should be, and whether the next session received it, and never uses a single word like verified for all three.
      3. Stale or superseded notes that remain in the task area are checked for items already finished and are removed or updated so the next reader is not misled.
THEN PRINT: a table (check, PASS/FAIL, evidence, fix) + a verdict (applies / partially / OUT_OF_SCOPE / no) + the single most important next action.