Make every version source say 0.5.0

CHANGELOG.md

@@ -11,6 +11,10 @@ can tell whether the format it is looking at is one it understands.
 
 ## [Unreleased]
 
+Nothing yet.
+
+## [0.5.0] — 2026-09-14
+
 ### Added
 
 - **`--device cpu|cuda` on `iqforge measure-leakage`**, defaulting to `cpu`.
@@ -86,11 +90,34 @@ can tell whether the format it is looking at is one it understands.
   checkpoint recorded no environment at all, which is the state every published
   grid is in, so the guard had never protected one. It now refuses that case
   instead of waving it through.
-- **`docs/release-notes/v0.5.0.md` says it is an unpublished draft.** The file
-  read as a shipped release while `__version__`, `CITATION.cff` and the newest
-  released CHANGELOG section all said `0.4.0` and no `v0.5.0` tag existed. It
-  now names that state at the top and points at `[Unreleased]`, so the four
-  places that carry a version agree about which one is real.
+- **The refuse categories are documented with the same numbers everywhere.**
+  `measure-leakage` prints `category 4  ceiling  (methodology 6.4)` and a
+  reader follows that citation into `docs/methodology.md` §6, which did not
+  contain the word "category" at all. The numbering matches §6.1–§6.4 by
+  construction and does not extend past it — `category 5` is a refusal while
+  `§6.5` is LoRaIQ, the one dataset that section did *not* eliminate. §6 now
+  opens with a cross-reference table covering all six categories, names the two
+  that cite something other than §6, and states that collision outright. A test
+  pins the code, SPEC and methodology together so they cannot drift apart again.
+- **`PARITY_GATE_PASSED` says what it asserts.** `scripts/parity_gate.py` was
+  documented in two lines that did not say what it checks, so a reader could
+  not tell "ran with the same configuration" from "produced the same numbers".
+  It is the second one: run count, seed-pair set, and `test_accuracy`,
+  `train_accuracy`, `train_windows`, `test_windows` compared by exact equality
+  row by row. SPEC §5.10.1 and methodology §8 now say so, along with what it
+  deliberately does not compare.
+- **README, ROADMAP and `docs/methodology.md` brought back in line with what
+  shipped.** The README documented `measure-leakage` as running "at split seed
+  42 and train seed 0" — the regression above, described as the design — and
+  omitted `--force`'s limits and `iqforge train`. methodology gained a
+  question-to-section guide; it is 1100 lines with no contents.
+- **The four places that carry a version agree again.** `docs/release-notes/
+  v0.5.0.md` had read as a shipped release while `__version__`, `CITATION.cff`
+  and the newest released CHANGELOG section all said `0.4.0` and no `v0.5.0`
+  tag existed; it was labelled an unpublished draft for as long as that was
+  true. With this release it is the release notes for `0.5.0`, and
+  `__version__`, `CITATION.cff`, the CHANGELOG heading and the built wheel's
+  METADATA all report the same number.
 - **The experiment scripts and their tests no longer carry a hardcoded path.**
   `scripts/leakage_real.py`, `scripts/leakage_loraiq.py`, `tests/test_preflight.py`
   and `tests/test_measurement.py` all fell back to an absolute path inside one
@@ -404,7 +431,8 @@ First release.
   `info`, `inspect`, `build` and `stats` work without it.
 - 16 example recordings, so the whole pipeline runs without hardware.
 
-[Unreleased]: https://github.com/emrefbulut/iqforge/compare/v0.4.0...HEAD
+[Unreleased]: https://github.com/emrefbulut/iqforge/compare/v0.5.0...HEAD
+[0.5.0]: https://github.com/emrefbulut/iqforge/compare/v0.4.0...v0.5.0
 [0.4.0]: https://github.com/emrefbulut/iqforge/compare/v0.3.0...v0.4.0
 [0.3.0]: https://github.com/emrefbulut/iqforge/compare/v0.2.0...v0.3.0
 [0.2.0]: https://github.com/emrefbulut/iqforge/compare/v0.1.0...v0.2.0

CITATION.cff

@@ -13,14 +13,14 @@ authors:
 repository-code: "https://github.com/emrefbulut/iqforge"
 url: "https://github.com/emrefbulut/iqforge"
 license: MIT
-version: "0.4.0"
+version: "0.5.0"
 # Carries the date the version above is intended to be tagged. It was once left
 # absent until the tag existed, on the reasoning that the file should never date
 # a release nobody can fetch -- but that put the correct value in a commit AFTER
 # the tag, so the tagged tree always shipped a citation with no date, and 0.2.0
 # went two days that way before anyone noticed. Pre-filling is the lesser
 # problem: if the tag slips, correct this line before pushing it.
-date-released: "2026-08-19"
+date-released: "2026-09-14"
 keywords:
   - software-defined-radio
   - sigmf

README.md

@@ -14,14 +14,15 @@
 
 ---
 
-> **Status: latest release `0.4.0`.** On PyPI, tagged, CI green. The capture →
-> dataset pipeline works end to end and is covered by tests. Interfaces may
-> still change within `0.x` — see the [Roadmap](#roadmap) for what is planned
-> and what is deliberately out of scope.
+> **Status: `0.5.0`.** On PyPI, CI green. The capture → dataset pipeline works
+> end to end and is covered by tests. Interfaces may still change within `0.x`
+> — see the [Roadmap](#roadmap) for what is planned and what is deliberately
+> out of scope.
 >
-> `main` carries unreleased work on top of that release, listed under
-> `[Unreleased]` in [CHANGELOG.md](CHANGELOG.md). This README describes `main`,
-> so a few things below are ahead of what `pip install iqforge` gives you.
+> `0.5.0` corrects a measurement bug: between the Phase 5 migration and this
+> release, `measure-leakage` ran a single seed pair instead of fifteen, so any
+> leakage figure it produced carried `± 0.0`. See
+> [the release notes](docs/release-notes/v0.5.0.md).
 
 > [!IMPORTANT]
 > **If you built a dataset with `--labels csv` or `--group-by csv:` over a
@@ -382,7 +383,7 @@ See [ROADMAP.md](ROADMAP.md) (Now / Next / Later). Short status:
 - [x] Windowing, labelling, recording-level splitting, sharded storage
 - [x] `torch.utils.data.Dataset` + baseline classifier
 - [x] Packaging (wheel + sdist), GitHub Actions CI
-- [x] PyPI releases (`0.1.0`, `0.2.0`, `0.3.0`, `0.4.0`)
+- [x] PyPI releases (`0.1.0`, `0.2.0`, `0.3.0`, `0.4.0`, `0.5.0`)
 - [x] Leakage measurement (recording-level vs window-level), synthetic and on a
       real capture
 - [x] Real SigMF verification with public captures

ROADMAP.md

@@ -215,10 +215,11 @@ After Now is done — still reliability-first:
       Missing users is a product gap; more features will not close it.
 - [ ] Docs site (CLI + Python API reference) when the surface stops thrashing
 
-Versioning: `0.4.0` is the latest release. Cut the next one when useful, on a
-schedule if needed — not “only when hardware is done.” Unreleased work sits
-under `[Unreleased]` in [CHANGELOG.md](CHANGELOG.md); `docs/release-notes/`
-carries a draft for the next version, marked as a draft until it is tagged.
+Versioning: `0.5.0` is the latest release. Cut the next one when useful, on a
+schedule if needed — not “only when hardware is done.” Work that has landed but
+not shipped sits under `[Unreleased]` in [CHANGELOG.md](CHANGELOG.md), and a
+release-notes file under `docs/release-notes/` is marked an unpublished draft
+until its tag exists.
 
 ---
 

docs/phase5-phase6-checklist.md

@@ -13,8 +13,8 @@ Branch checked: `cursor/phase-1-independent-gaps-38eb`
 >
 > Individual readiness lines below have expired and are deliberately left as
 > they were written. The one most likely to mislead: the release-note item says
-> no next-version draft exists, and `docs/release-notes/v0.5.0.md` has since been
-> written — labelled an unpublished draft, because there is no `v0.5.0` tag.
+> no next-version draft exists. `docs/release-notes/v0.5.0.md` has since been
+> written and is now the release notes for `0.5.0`.
 >
 > For current state read [CHANGELOG.md](../CHANGELOG.md) `[Unreleased]` and
 > [ROADMAP.md](../ROADMAP.md).

docs/publishing.md

@@ -3,8 +3,8 @@
 Pre-release checklist, PyPI setup, GitHub release, and repository metadata.
 
 A PyPI version number is permanent. A bad upload can be yanked, but the number
-can never be reused — `0.4.0` would be burned and the fix would have to ship as
-`0.4.1`. Everything below exists to keep that from happening.
+can never be reused — `0.5.0` would be burned and the fix would have to ship as
+`0.5.1`. Everything below exists to keep that from happening.
 
 ## Pre-release checklist
 
@@ -20,7 +20,7 @@ uv build
 Confirm:
 
 - [ ] `__version__` in `src/iqforge/__init__.py` matches the tag you are about to
-      push (`0.4.0` → `v0.4.0`). This is the only place the version is written;
+      push (`0.5.0` → `v0.5.0`). This is the only place the version is written;
       `pyproject.toml` reads it from there and `tests/test_packaging.py` checks
       they agree.
 - [ ] `CITATION.cff`: `version` matches, and `date-released` is the date you
@@ -66,9 +66,9 @@ suite, and a check that the tag matches `__version__` before it builds or
 uploads anything.
 
 ```bash
-git tag -a v0.4.0 -m "v0.4.0"
-git push origin v0.4.0
-gh release create v0.4.0 --title "v0.4.0" --notes-file docs/release-notes/v0.4.0.md
+git tag -a v0.5.0 -m "v0.5.0"
+git push origin v0.5.0
+gh release create v0.5.0 --title "v0.5.0" --notes-file docs/release-notes/v0.5.0.md
 ```
 
 Watch the run:
@@ -81,7 +81,7 @@ If the verify job fails, delete the tag before retrying — a tag that never
 published is not a release:
 
 ```bash
-git tag -d v0.4.0 && git push origin :refs/tags/v0.4.0
+git tag -d v0.5.0 && git push origin :refs/tags/v0.5.0
 ```
 
 ### Manual upload