---
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 spt-releases metadata (`<artifact>.release.json` `version` field on the latest release), not from MEMORY.md, the changelog, or arithmetic on the version number. 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]].