fix(docs): stop advertising a superseded Flow release - #75
Merged
Conversation
openadapt-flow 1.24.0 published on 2026-07-27. Five sentences on docs.openadapt.ai -- including one on the security-review page -- still asserted that the live runner and compiler report "the published Flow 1.23.0 identity". Verifying rather than assuming changes the fix. The managed runtime really does pin 1.23.0: openadapt-cloud runner/runtime-version.json records openadapt_flow 1.23.0 with wheel sha256 b5d10dfc..., and https://app.openadapt.ai/api/health/ready reports ready:true in live mode. So the NUMBER is right and the word "published" is what became false. Bumping these to 1.24.0 would have replaced a stale claim with a fabricated one. They now read "the pinned managed-runtime 1.23.0 identity", which is what is true. Also: every release reached the aggregated changelog carrying only the licence boilerplate python-semantic-release puts at the top of every body, so openadapt-flow v1.24.0 was published with no visible content and its "Bug Fixes" notes dropped. summarize_body now skips that sentence, and the regenerated changelog carries the real change categories. To stop this recurring, docs/published-version-claims.json records every version the docs state and what kind of claim it is: one that must track the current PyPI release, a deliberate deployment pin, or a frozen historical measurement. scripts/check_published_version_claims.py enforces it, stdlib only. The offline half runs on every PR in ci.yml: registered claims must still appear verbatim where recorded, and no authored page may contain a "published X.Y.Z"-shaped sentence that is not declared to track PyPI. The daily half compares every tracking claim, and the newest entry in each changelog section, against PyPI, and files an issue when it fails -- a red scheduled run in a repository nobody has open is not a signal. Docs behind PyPI fail; docs ahead of a not-yet-uploaded release warn, as does an unreachable index, because a guard that goes red for unrelated reasons stops being read. tests/test_published_version_claims.py proves the guard FAILS when it should, including against a simulated future release and against the exact wording that shipped, and that it accepts the corrected pinned/historical wording. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01NyCHrzA1psrKMFfroYbzaM
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What was wrong
openadapt-flow1.24.0 published at 2026-07-27T03:58Z. Five sentences live on docs.openadapt.ai — including one on the security-review page — still asserted that the live runner and compiler report "the published Flow 1.23.0 identity".Verifying changed the fix
The obvious correction is
1.23.0→1.24.0. That would have been wrong. The managed runtime really is pinned to 1.23.0:openadapt-cloudrunner/runtime-version.jsonrecordsopenadapt_flow: 1.23.0, wheel sha256b5d10dfc294479866d6dddd4c1a6afc9164414f0634703173b7e440dc0133bec— the same digest the stale platform manifest carried.https://app.openadapt.ai/api/health/readyreturnsready: true,mode: live, runner and compiler reachable.So the number was right; the word "published" is what became false. Bumping to 1.24.0 would have replaced a stale claim with a fabricated one. The sentences now read "the pinned managed-runtime 1.23.0 identity".
Corrected at
docs/concepts/deployment-matrix.md:104,docs/guides/hosted.md:35and:61(the reported location missed the second one),docs/guides/security-review.md:129,docs/get-started/what-works-today.md:69.Changelog
docs/changelog.mdhad a v1.24.0 row whose only content was_This release is published under the MIT License._— the boilerplate python-semantic-release puts at the top of every release body in every repository.summarize_bodyreturned it as the summary and dropped the actual notes. It now skips that sentence, and the regenerated changelog carries the real change categories (flow v1.24.0 →Bug Fixes, launcher v1.9.0 →Chores, v1.8.0 →Build System, …). 20 rows gained real content.Making recurrence impossible
docs/published-version-claims.jsonrecords every version number the docs state and what kind of claim it is:pypi-latestpinned-deploymenthistoricalscripts/check_published_version_claims.pyenforces it, stdlib only.Offline half — every PR, via
ci.yml: registered claims must still appear verbatim where recorded (a reword cannot quietly turn a pin into a publication claim); no authored page may contain apublished X.Y.Z-shaped sentence that is not declared to track PyPI; the changelog parses.Daily half —
published-version-claims.yml: every tracking claim, and the newestvX.Y.Zentry in each tracked changelog section, is compared to PyPI. This drift originates in another repository, so no PR can catch it — only a schedule can.Docs behind PyPI fail. Docs ahead (GitHub release published, PyPI upload not landed) warn, as does an unreachable index — a guard that goes red for reasons unrelated to its subject stops being read, which is exactly how the sibling manifest drift survived. A failed scheduled run files or updates an issue rather than leaving a red dot on a repo nobody has open.
Proof it fails when it should
tests/test_published_version_claims.py— 19 tests. It fails on a simulated future release (1.24.0documented,1.25.0published), on the exact sentence that shipped, on four publication-claim phrasings, and on a registry that has detached from the docs; it passes the corrected pinned/historical wording and warns rather than fails on a not-yet-uploaded release.Replayed against the pre-fix
origin/maindocs tree, the offline scan alone returns 5 errors:Verification
pytest tests/ -q→ 98 passed.validate_docs.py→ Validation passed.mkdocs build --strict→ clean.🤖 Generated with Claude Code
https://claude.ai/code/session_01NyCHrzA1psrKMFfroYbzaM