I Lost a Commit While
My AI Swarm Kept Building.

I thought the commit was gone

I was trying to promote a lead-discovery capability into SwarmOffice. The implementation report looked good: four source adapters, explicit lead promotion, tenant boundaries, and 69 passing tests. It even had a commit: e832367.

Then I tried to publish the branch.

I was in Windows PowerShell, but the commit was not in the repository I was standing in. We searched the usual worktree roots, then the VPS, then Termux. Nothing. At one point I was running Git commands from my home directory and getting the same “not a git repository” error over and over.

The code was not necessarily lost. The thing I had lost was the location of the work.

The search was not the proof

The first searches were too narrow. They checked expected roots and assumed the relevant checkout would be in one of them. One script also mishandled .git files used by worktrees. I kept getting negative results, and we started talking as though those results proved the commit had disappeared.

They did not.

A failed search proves only that the search did not find the thing. It does not prove the thing does not exist. That distinction matters when several agents can work in different containers, worktrees, machines, and remote branches.

The earlier GitHub check was also a snapshot. At that moment the branch was not available remotely. It was not a permanent verdict.

The swarm moved while I was looking

The fresh GitHub reconciliation changed the story. SwarmOffice PR #7 now exists, with exact head e83236733a7854099e1fcba75f9985125180d2fe. It records the same 16-file, 892-line promotion, the 69-test reviewed head, and an 80-test merged-state probe against the newer base.

So the missing commit was not a reason to recreate the implementation. It was a reason to ask the shared system where the work had gone.

That is the difference I want Dream.OS to make.

The promotion itself takes discovery code from contract-leads and gives it a bounded home in SwarmOffice. External sources become DiscoveryRecords, scoring ranks them, and an explicit promotion creates a Lead. Publicly discoverable does not mean consented. A high score does not mean qualified. The adapter does not get to send outreach just because it found somebody.

The source also exposed a data-quality bug: an unparseable RSS date could become “now,” manufacturing recency. The promoted version preserves the unknown date instead.

But PR #7 is still open. It is not a merged product capability, and the original RemoteOK source patch remains a separate provenance item.

What actually shipped

The wider GitHub check shows the swarm doing more than producing another architecture proposal.

SwarmOffice PR #6 merged on September 5 as ba71333a8ac74d8921ee982836915ab6cf1661ed. That is a real canonical promotion: a governed social queue boundary. It does not make the adapter a live publisher. PR #8 remains a follow-up to close governance gaps without replacing that merged boundary.

ProjectScanner has reviewable work for a v2 portfolio evidence index and fleet hygiene sensors. The hygiene lane reports exact-head CI and VPS parity against the AgentTools Git-facts dependency. DreamVault has an HQ compiler, Git-event coverage and consumer work, and merge/deletion preparation that records dry-run evidence without pretending those mutations happened.

Dream.os-Core has also moved. The HQ event pipeline, ProjectScanner adapter, CPC adapter, signed GitHub ingestor, and deployment package exist as separate reviewable layers. The newer operator-task admission work is especially relevant: it reuses the existing DreamSync feed instead of inventing another queue. It can prepare a bounded task packet, but it does not claim that a real worker executed it.

That is progress. It is also not the same as saying the headquarters is live end to end.

The next chapter has to be an outcome

I compared this against the existing Build Log before deciding what to write. The archive already has the infrastructure story, the delete-button story, the HQ handoff story, the retrospective about building too much, and the architecture-budget rule. Another post saying “we need fewer frameworks and better handoffs” would just repeat the lesson.

This incident gives us a more concrete test.

Can Dream.OS answer: “Where is the work I was just doing?” Can it distinguish a local commit from a pushed branch, a reviewable PR from a merge, and a merged capability from a live service? Can it recover the exact source without asking me to search four environments manually?

The next useful milestone is one governed operator-task path that starts from canonical authority, reaches a compatible worker, executes a bounded task, verifies the result, and leaves a durable closeout that another agent can resume from.

The current operator-task admission work is a starting point, not proof that this path is complete. Its own PR says the live queue still needs concurrency and recovery acceptance, and that the commercial video pilot is not an executable coding task.

A green test should not become a fake production receipt just because I want the story to have an ending.

What I want to see next

I want to give Dream.OS one objective, leave the conversation, and come back to a record that tells me what happened without reconstructing the day.

Not “the agent says it finished.”

The actual repository, exact commit, PR or merge state, execution receipt, verification result, and next human gate.

And if the work is still only in a temporary environment, I want the system to say that before the environment disappears.

The swarm is moving. The next job is making that movement recoverable, governed, and useful enough that I do not have to be its memory.

That is the chapter I want to earn next.