Skip to content

version_skew: deep --pypi leg — flag floors naming yanked releases - #148

Merged
Jammy2211 merged 2 commits into
mainfrom
feature/version-skew-yank-awareness
Aug 18, 2026
Merged

version_skew: deep --pypi leg — flag floors naming yanked releases#148
Jammy2211 merged 2 commits into
mainfrom
feature/version-skew-yank-awareness

Conversation

@Jammy2211

Copy link
Copy Markdown
Contributor

Summary

Closes the yank gap the version_skew check 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 yanked 2026.7.6.649).

python -m heart.checks.version_skew --pypi now 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 / BAD as in the tag leg.

Design constraints honored (per the Mind prompt draft/feature/pyautoheart/version_skew_yank_awareness.md):

  • Tick untouched: the probe is network-bound, so it never runs from tick.sh — on-demand / nightly only, behind the explicit --pypi flag.
  • Sidecar state (version_skew_pypi.json): the tick's version_skew.json rewrite 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 like run() (persistence lives in main() only); one PyPI fetch per distinct package, not per workspace.
  • Fork (b) of the version model stands: this reads state only, no commit-back behavior.

Wiring

  • heart/state.pyversion_skew_pypi snapshot 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).
  • Live probe against real PyPI (autolens, 421 releases): 2026.7.9.1 → OK, the yanked 2026.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

claude added 2 commits August 18, 2026 20:31
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
@Jammy2211
Jammy2211 merged commit 7659f15 into main Aug 18, 2026
2 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants