---
name: release-counter-from-published
description: "Release --version counter comes from PUBLISHED spt-releases metadata, never memory derivation; a collision breaks the spt-update rollback floor (REQ-UPD-8)."
metadata: 
  node_type: memory
  type: feedback
  originSessionId: dfcf879c-b64a-4f28-9235-11afcd2894c8
---

2026-06-21 (v0.13.0 cut). I derived the next release counter from memory ("v0.12.0 was 25 → next is 26") and handed deployah `counter 26`. WRONG — v0.12.1 had already shipped as **counter 26**. deployah caught it by reading the PUBLISHED metadata on spt-releases (`spt-x86_64-linux.release.json` = `{"version":26, product_version 0.12.1}`) and corrected to **27**.

**Why:** the release counter is strictly monotonic and is the spt-update rollback floor (REQ-UPD-8). A reused counter collides with an existing published release and corrupts update/rollback ordering.

**How to apply:** before any publish, derive `--version` from the ACTUAL published releases-repo metadata (`<artifact>.release.json` `version` field on the latest release), not from MEMORY.md, the changelog, or arithmetic on the version number. **THE-FORKENING (2026-07-14): counter source moves to `BigscreenVR/spt-bs-releases` for counter 59+; gh release assets were NOT migrated, so the last pre-fork release (v0.31.0 = counter 58) stays readable only on `SaberMage/spt-releases` — at the v0.32.0 cut, baseline reads SaberMage, publish goes to bs-releases; thereafter bs-releases is the sole source.** Version number (0.x.y) and counter are independent — a patch that never shipped still consumed no counter; a patch that DID ship consumed one. deployah verifies this at cut time; the gater should state the counter as "verify against spt-releases" rather than asserting a number. Related: each release also has a product_version. See the v0.13.0 saga in [[v013-forkpty-groundtruth]].