version_skew: deep --pypi leg — flag floors naming yanked releases - #148
Merged
Conversation
The tick-path check compares floors against local git tags, so it cannot see the other way a floor goes bad: the release it names being yanked on PyPI afterwards (the 2026-07 shape, where every floor named the yanked 2026.7.6.649). The gap was acknowledged in the module docstring and owned nowhere. `python -m heart.checks.version_skew --pypi` now asks the PyPI JSON API whether each floor still names an installable (non-yanked) release and whether any installable release satisfies it. Statuses: UNSATISFIABLE (nothing installable >= floor — same defect class as the tag leg's UNSATISFIABLE, readiness RED), FLOOR_YANKED (floors are >= bounds, so a yanked floor with newer installable releases still resolves — readiness YELLOW, fix by bumping the floor), UNKNOWN (PyPI unreachable — STALE, never a false block), OK/BAD as before. Network, so never part of the tick: the probe is on-demand/nightly only and persists to its own version_skew_pypi.json sidecar so the tick's version_skew.json rewrite can never clobber its evidence (and vice versa). run_pypi() is side-effect-free like run(); one fetch per distinct package, not per workspace. Snapshot, readiness legs (+weights) and a dashboard section wired; 484 tests pass (15 new). Task: PyAutoMind draft/feature/pyautoheart/version_skew_yank_awareness.md Co-Authored-By: Claude <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01SKw8oaLZoD3cZnmETMDEkc
…ckage test The tenant firewall gate flagged HowToLens as a new instance fact in organ code; autolens_assistant is an already-present fact in this file and maps to the same package, so the test proves the same dedup behaviour. Co-Authored-By: Claude <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01SKw8oaLZoD3cZnmETMDEkc
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.
Summary
Closes the yank gap the
version_skewcheck acknowledges in its own docstring: the tick leg compares floors against local git tags, so it cannot see the other way a floor goes bad — the release it names being yanked on PyPI after the fact (the 2026-07 incident shape, where every floor named the yanked2026.7.6.649).python -m heart.checks.version_skew --pypinow asks the PyPI JSON API whether each workspace floor still names an installable (non-yanked) release and whether any installable release satisfies it.Statuses / readiness mapping:
UNSATISFIABLE— no installable release ≥ floor on PyPI (every candidate yanked): same defect class as the tag leg's UNSATISFIABLE → readiness RED.FLOOR_YANKED— the floor version itself is yanked/absent but a newer installable release satisfies it; floors are>=bounds so installs still resolve → readiness YELLOW ("bump the floor").UNKNOWN— PyPI unreachable/unparseable → STALE, never a false hard block (offline box safe).OK/BADas in the tag leg.Design constraints honored (per the Mind prompt
draft/feature/pyautoheart/version_skew_yank_awareness.md):tick.sh— on-demand / nightly only, behind the explicit--pypiflag.version_skew_pypi.json): the tick'sversion_skew.jsonrewrite can never clobber on-demand PyPI evidence, and vice versa. An absent slice is no signal in readiness and the dashboard.run_pypi()is side-effect-free likerun()(persistence lives inmain()only); one PyPI fetch per distinct package, not per workspace.Wiring
heart/state.py—version_skew_pypisnapshot slice.heart/readiness.py— the four legs above + score weights.heart/dashboard.py— "Version skew (PyPI)" section (rendered only once the probe has run).Testing
python3 -m pytest tests/— 484 passed (15 new: probe status matrix incl. fileless releases, one-fetch-per-package, offline→UNKNOWN, sidecar isolation from the tick file, readiness RED/YELLOW/STALE legs).autolens, 421 releases):2026.7.9.1 → OK, the yanked2026.7.6.649 → FLOOR_YANKED,2099.1.1.1 → UNSATISFIABLE,garbage → BAD.🤖 Generated with Claude Code
https://claude.ai/code/session_01SKw8oaLZoD3cZnmETMDEkc
Generated by Claude Code