sync: absent from my scan does not mean deleted

[myobie]

Two doors into one defect. A path that is absent from an entry's scan is not necessarily a path anybody deleted, and treating the two as the same thing deletes live files on every peer.

Door one caused a real incident on 2026-08-25. Door two is already live on main and needs no configuration change or release to reach.

---

Door one — a path removed from an include

plans/** was taken out of an entry's include as part of a migration. That left ~20 paths recorded in the entry's manifest and observed set while its scan could no longer see them. Inert under a policy that does not propagate deletes.

Then propagation was turned on. Those paths read as "in my records, absent from my scan" — exactly what a local delete looks like. Thirteen live files were removed from three machines. All were recoverable from git, which is the only reason it was a bad night rather than a disaster.

Narrowing an include is a scope change. Nobody deleted anything.

Fix: scan_into_node_observed no longer calls local_remove for a path the entry does not include.

Test failed first on main:

DROPPING A PATH FROM THE INCLUDE DELETED THE FILE.

Door two — the root itself stops existing

scan_folder opens with if !root.exists() { return Ok(out) }. A missing root returns an empty scan, not an error. Every tracked path is then absent from the scan, so a delete-propagating policy tombstones the whole entry and ships it to every peer.

st2-bus-default is bus policy, and bus has always propagated deletes. That entry carries 17,689 files across three machines. A root vanishes without anyone deleting anything: an unmounted volume, a directory renamed mid-pass, a mount not ready at boot, a rename-swap by another process.

The blast radius is not about the file count. The bus entry carries agent context and message history, and git holds none of it — the catalog repo tracks agent.kdl, plans/ and _templates/ only. Tonight's thirteen files came back because git had them. A bus mass delete has no such floor.

Fix: scan_into_node_observed returns early and changes nothing when the root does not exist. Deleting the contents of a folder still propagates normally, because the root survives that and the scan runs.

Test failed first on main:

a root that vanished was read as a delete of every file in the entry,
and that tombstone set goes to every peer

---

What I deliberately did not do

The tidier half of door one is to drop excluded paths from the manifest too. That needs its own change: a peer whose config still selects the path sends it back on every reconcile, this side drops it again, and the whole index is rewritten each time. Fixing a delete by inventing a write loop is not a fix. Filtering on adopt is the likelier answer and it changes what crosses the wire. The comment says so at the site.

A third test that is a guard, not a reproduction

enabling_delete_propagation_does_not_delete_what_is_still_there was written to reproduce a proposed cause of the incident — that enabling propagation replayed a backlog of old deletes. It does not reproduce, because that was not the cause. It passes before and after. I kept it rather than manufacture a failure: it proves the switch itself is not the dangerous part.

The discriminator that settled the real cause: exactly the excluded set died. _templates/** and agents/**/agent.kdl survived, both still included, and there were zero deleted tracked files outside plans/.

Provenance, and the lesson

I found door two while fixing door one, which is the right way round. But: a test suite written after an incident inherits the shape of that incident. I built the folder-sync matrix around the failure I had just seen. The class is "the thing I am watching stopped existing", and these are two doors into it. There may be a third.

Green: lib 242, folder_sync 5, sync_slice 3.

Agent: Silber.fabric