[observed] inbox: expected Captures from two machines in the same second get distinct inbox filenames; observed Both used the same second-stamped name, so the next pull hit an add/add conflict fp-ceda83968a85

[leeovery]

Session-observed report from a dex instance. Structured mechanics
only: each field was refused, not scrubbed, on any detected leak,
and the reporter's fuller note never leaves the instance.

• engine: 0.1.17
• verb: inbox
• date: 2026-09-17
• expected: Captures from two machines in the same second get distinct inbox filenames
• observed: Both used the same second-stamped name, so the next pull hit an add/add conflict
• fingerprint: fp-ceda83968a85

steps:

1. Capture a link on one machine and push
2. Capture a different link on another machine in the same second and push
3. A run pulls both: git reports an add/add conflict on the one inbox file
4. Resolution needs judgment: rename one side to a free name so both captures survive

[leeovery]

Related, found while reviewing the lens work: the same collision reaches staged media. bin/dex inbox keys a capture's media directory by a hash of the file's name (media/<sha1("media/<name>")[:6]>/<name>), so two captures that stage a file under the same name share one path. In inbox.py's _fetched, a second file of a different size overwrites the first item's media, and one of the same size is silently treated as already downloaded even when the bytes differ. The phone shortcut names files by the capture timestamp, so this is reachable through same-second captures (this issue's case) or any capture client that doesn't timestamp its file names.