---
name: release-updateset-stale-window
description: Publish-tail window where Latest serves STALE update-set.json (old counter) → updater skips
metadata: 
  node_type: memory
  type: project
  originSessionId: d095b3e4-b4dc-4ff4-8597-17c8faaa35fc
---

RELEASE-MECHANICS HAZARD (observed v0.19.1 cut, doyle 2026-07-02, non-blocking that cut). For ~minutes after deployah's publish-complete, a download of `update-set.json` from the Latest release returned the PREVIOUS release's envelope (v0.19.1 published but update-set still served version 38 + old shas); re-download minutes later returned correct v39.

**Why it bites:** an `spt update` fetching in that window sees counter 38 on a v0.19.1 release → treats as not-newer → SKIPS the update. Self-corrects once the v39 asset settles, but a real updater could miss the release in the gap.

**Suspected cause:** asset upload / clobber ordering in the publish tail. release.yml creates the DRAFT (binaries+SHA256SUMS+manifest+mock-adapter); the flip-public + metadata upload (`.release.json` ×2 + `update-set.json`) is deployah's local `xtask release-publish`. The update-set replace likely lands slightly after flip-public / after the per-platform `.release.json`, so Latest is public with a stale update-set for a beat.

**Candidate fix (next cut, verify before shipping):** in xtask release-publish, upload `update-set.json` BEFORE flipping the release public (or make flip-public the strict last step after a settle/read-back check that Latest's update-set == new counter). Eyeball the upload order in xtask release-publish + release.yml.

Kin: [[release-counter-from-published]] (counter read from published metadata — this is the write-side race of the same asset). Ledger [[v0121-published]].