review(bsky): EXPECTED_NA['upgrade'] premise verified cold — both published tags (0.1.1/0.2.0+v0.4) pin broken moving :0.4, no deployable base; recorded scoping/teeth checks for the claim
All checks were successful
continuous-integration/drone/push Build is passing

This commit is contained in:
autonomic-bot
2026-06-11 11:56:07 +00:00
parent 73889ed860
commit cfda9e72db

View File

@ -61,3 +61,28 @@ Open scrutiny points I will hold the M1 claim to (NOT yet judged — no gate CLA
at PR head — not a local hand-run; no cc-ci harness/gate weakening.
Still no gate CLAIMED (STATUS-bsky: "none claimed yet — working M1"). Idling for the claim.
## Pre-claim recon @2026-06-11T11:55Z — EXPECTED_NA['upgrade'] premise (cold, NOT a verdict)
Builder added a harness change: `EXPECTED_NA['upgrade']` suppresses the upgrade-tier base
deploy for bluesky-pds ("no deployable base"). I independently checked the premise on the
live recipe checkout:
- Published recipe tags: ONLY `0.1.1+v0.4` and `0.2.0+v0.4`. **Both** pin
`ghcr.io/bluesky-social/pds:0.4` (the moving tag that now resolves to the broken
0.5.1/index.ts image). So every published base would crash identically → there is no
deployable previous published version. Premise holds. ✔
- Logic: the PR fix (pin 0.4.219) is the FIRST deployable published version; before it,
NO published version deploys, so a "previous published → PR" upgrade path cannot exist.
Genuinely N/A, not a dodge. (Post-merge, future PRs WILL have a deployable base → tier
re-activates; operator handoff should note this.)
STILL must hard-verify when M1 is CLAIMED (do NOT pre-judge):
- The NA is **scoped to bluesky-pds only** (per-recipe EXPECTED_NA declaration, not a
global loosening of the upgrade tier for all recipes) — read the diff.
- install / backup-restore / functional / lint tiers are NOT suppressed.
- N/A recorded honestly with reason and handled correctly under de-capped level semantics
(doesn't silently inflate the level nor falsely block); the 6 new upgrade_base() unit
tests actually have teeth.
- §9 alternative ("deploy base minimally via overlay, then upgrade to latest") is correctly
rejected here: latest-deployable == PR head == 0.4.219, so there's no version delta to
test and an overlay base would be synthetic — N/A is the honest call, not the overlay.