diff --git a/CLAUDE.md b/CLAUDE.md index 964c3e2..94a1eab 100644 --- a/CLAUDE.md +++ b/CLAUDE.md @@ -6,7 +6,9 @@ at the **root of the platform dependency DAG**, plus two sibling operation packa in the same wheel. numpy only; depends on nothing internal; every other repo depends *toward* it. -> **Status:** **released — v2.x on PyPI**. The v1 API was frozen from v1.0.0 (ADR-018) +> **Status:** **v2.x — the version in this tree**; see +> [PyPI](https://pypi.org/project/views-frames/) for what is published. The v1 API was +> frozen from v1.0.0 (ADR-018) > and **broken once, deliberately, in 2.0.0** (ADR-028): a frame's `index` must now > actually be a `SpatioTemporalIndex`, and `frame.values` is write-protected. > `CONFORMANCE_FLOOR` moved `1.0.0` → `2.0.0` — its first move. Everything else is @@ -17,10 +19,10 @@ depends *toward* it. ## Maintenance mode -**This package is finished.** It is released, its public API was frozen at v1.0.0 and has been -broken exactly once since (2.0.0, ADR-028 — a validation hole found by attacking the claim -that it was finished), -and its governance documents have been checked against the code and are now asserted by CI. +**This package is finished.** It is published on PyPI, its public API was frozen at v1.0.0 and +has been broken exactly once since (2.0.0, ADR-028 — a validation hole found by attacking the +claim that it was finished), and its governance documents have been checked against the code +and are now asserted by CI. Work here should be rare, small, and caused by something outside this repository. **Do not run discovery tooling here.** `repo-assimilation`, `graphify`, `review-base-docs` diff --git a/README.md b/README.md index 229a005..8db632f 100644 --- a/README.md +++ b/README.md @@ -4,7 +4,11 @@ > containers (`FeatureFrame`, `PredictionFrame`, and their anticipated siblings) > that every other repo depends on and that depends on nothing internal. > -> **Status:** **v2.0.0 — published to PyPI** (frozen at v1.0.0, ADR-018, and broken once in 2.0.0, ADR-028; the +> **Status:** **v2.0.0 — the version in this tree.** For what is actually published, see +> [PyPI](https://pypi.org/project/views-frames/): between a release commit and its publish +> job this number is deliberately ahead, so this banner tracks the source and never claims +> a publication it cannot verify. API frozen at v1.0.0 (ADR-018) and broken once in 2.0.0 +> (ADR-028; the > v1.1 surface is > purely additive — the coherent posterior summary, ADR-019; v1.2.0 rebuilt the tower > `outside-in`, C-44; v1.3.0 makes the tower summary distribution-agnostic — no magnitude diff --git a/reports/technical_risk_register.md b/reports/technical_risk_register.md index 96030db..72af88d 100644 --- a/reports/technical_risk_register.md +++ b/reports/technical_risk_register.md @@ -5,9 +5,9 @@ | Project | views-frames | | Owner | VIEWS platform maintainers | | Last Updated | 2026-08-18 | -| Total Concerns | 93 | +| Total Concerns | 94 | | Open Concerns | 10 | -| Resolved Concerns | 83 | +| Resolved Concerns | 84 | | Disagreements | 12 | --- @@ -441,6 +441,47 @@ Cross-refs: C-47 (eval provenance kept out of the generic header — the precede > Resolved 2026-07-31 by **ADR-027** (Epic #208 / S1 #209) — the #113 decision. +### C-97: the status banners asserted a release state the repo cannot verify — RESOLVED + +| Field | Value | +|-------|-------| +| ID | C-97 | +| Tier | 4 | +| Resolved | 2026-08-18 | +| Resolution | Both banners reworded to be state-neutral, permanently: they state the version **in this tree** and link to PyPI for what is published. | +| Source | pre-release falsification audit (2026-08-18, F2) — predicted before execution | +| Cross-refs | C-70 (the banner epoch-lag that produced check 6), C-96 (the other half of the same audit), C-74 (a check that does not run). | + +`README.md` said **"v2.0.0 — published to PyPI"** and `CLAUDE.md` said **"released — v2.x on +PyPI"** while PyPI served `1.11.0` and no `v2.0.0` tag existed. Both were false, on `main`, and +`README.md` is the PyPI long description. + +This is the ordinary bump-then-publish transient every prior release had, which is why nobody +noticed it in sixteen releases. It stopped being a transient here: the tag is gated on C-13's +adoption-issue requirement, which has no date, so the false claim would stand for as long as +that took. + +**The version number was never the bug — the words were.** A banner that asserts *publication* +makes a claim about the world that the repository cannot check, and it is wrong in every cycle +between the version bump and the publish job. The repair is to stop making the claim rather +than to keep correcting it: the banner now states the version in the tree, links to PyPI, and +says plainly that it is deliberately ahead between a release commit and its publish. One edit, +no recurring work. Softening before each release and re-asserting afterwards was considered and +rejected — it rebuilds the trap every cycle. + +`validate_docs.sh` check 6 is untouched and still pins the banner's MAJOR.MINOR to +`pyproject.toml`, which is the part that *is* checkable from inside the repo. + +**What this cost, stated rather than glossed.** The audit's own stub asserted `banner version == +PyPI version`. That was the right test against the old wording and is the wrong test against the +new one — it would contradict check 6, since the banner is now legitimately ahead between +releases. The stub was rewritten to assert that the banner makes no publication claim, which is +**weaker**: it cannot catch a merely stale banner. Check 6 covers staleness against +`pyproject.toml`, and no check inside this repo can know what PyPI serves without the network. +The rewritten stub was mutation-tested — restoring "published to PyPI" fails it. + +--- + ### C-96: the wheel's package count drifted in the documents that describe it — RESOLVED | Field | Value |