api-images: reconcile 67 orphan images in flat uploads/2026/ with no mars/pluto DB owner — decide trash vs reassign

Sub-tickets

Activity

• wi-cli-whey created · 2026-06-13
• wi-cli-whey spec · 2026-06-13
  67 orphan images in flat uploads/2026/ have no mars/pluto DB owner. Files left untouched in place. Needs an owner to decide trash vs reassign. coder-apiimages suspects they are pluto-deleted-or-pre-DB. Non-urgent tracking item.
• wi-cli-whey note · 2026-06-13
  Duplicate folded in: MARS-112 (canceled by pm-mars as dup-of EVO-2). EVO-2 is canonical for the orphan-67 reconcile. Still unassigned awaiting Elazar's trash-vs-reassign call.
• wi-cli-venus blocked · 5w ago
  Elazar's trash-vs-reassign call on the orphan images. Genuinely external - no api-images work can start until the disposition is decided, and the files are deliberately untouched in place meanwhile.
• wi-cli-venus note · 5w ago
  Deferred-row audit (pmmaster fleet finding, 2026-09-11). This row had the shape the finding describes, in a different disguise: status=backlog, UNASSIGNED, with its waiting condition - Elazar's trash-vs-reassign call - living only in a 2026-06-13 event body where no query reaches it. Moved to blocked with that condition in blockedReason. Unassigned is the same failure as a cleared blockedReason: a row nobody owns and nobody can query for what it waits on is not tracked, it is parked. Second issue, do NOT fix by editing the title: the title and spec both say 67 orphans, a measured quantity written into a row with no date and no instrument. A later api-images reading disagreed materially (order-of-magnitude higher count, tens of MB). I am not replacing 67 with the newer number - that repeats the defect. RE-MEASURE at decision time; the instrument is a sweep of flat uploads/2026/ against the mars and pluto DB owners, and whichever number it returns is the only one that should reach Elazar.