Benchmarks / CPU and I/O (per commit) (push) Successful in 8m16s
Benchmarks / Frame budget (on demand) (push) Skipped
Build and test / Desktop (Linux) (push) Failing after 32s
Build and test / Layer separation (push) Successful in 29s
Traceability / Requirement traces (push) Failing after 42s
🐳 Android image / Build and push (push) Successful in 2s
Build and test / android-image (push) Successful in 2s
🐳 Windows image / Build and push (push) Successful in 2s
Build and test / windows-image (push) Successful in 2s
Build and test / Android (aarch64) (push) Failing after 0s
Build and test / Windows (x86_64, cross) (push) Failing after 0s
Adopting an image from a peer's face shard stamped its run marker as now, and the export reads a catalog marker newer than the shard's as a re-index. So every adopted image went straight back out under this device's client id: 14,100 adopted, 15,457 "newly indexed" on the next pass, twenty-two shards of a peer's faces uploaded a second time. merge_shard now carries the peer's indexed_at into the local index, and the import writes that marker into face_index; where an older peer's shard carries none, the store takes the catalog's, so the two agree either way and the export finds nothing to send. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>