journal(bsky): run 423 red = upgrade-base trap (base 0.1.1+v0.4 pins broken :0.4, PR head never reached); decisions entry for EXPECTED_NA-upgrade base suppression; run 427 in flight

BACKLOG-bsky.md

@@ -4,8 +4,8 @@
 
 - [x] B1: Root-cause diagnosis — inspect recipe compose/entrypoint + actual `:0.4` image vs exact tags on cc-ci (2026-06-11)
 - [x] B2: Upstream research persisted to cc-ci-plan/upstream/bluesky-pds.md (plan repo f395247)
-- [ ] B3: DECISIONS.md entry — pin choice (exact 0.4.219 over 0.5.1-main / digest pin), version label bump
+- [x] B3: DECISIONS.md entry — pin choice (exact 0.4.219 over 0.5.1-main / digest pin), version label bump
-- [ ] B4: Mirror PR branch `upgrade-0.3.0+v0.4.219` — compose.yml re-pin + label bump; open PR on recipe-maintainers/bluesky-pds
+- [x] B4: Mirror PR branch `upgrade-0.3.0+v0.4.219` — compose.yml re-pin + label bump; open PR on recipe-maintainers/bluesky-pds
 - [ ] B5: `!testme` on the PR → full lifecycle green (install/health, upgrade-path status justified, backup/restore, functional, L5 lint); record level under de-capped semantics + reconcile expected baseline
 - [ ] B6: Screenshot on the green PR run — verify PNG real/representative/credential-free (Read it); SCREENSHOT hook only if needed
 - [ ] B7: Claim M1 (root cause + green fix PR + screenshot verified)

JOURNAL-bsky.md

@@ -47,3 +47,28 @@ Bridge enrollment confirmed: bluesky-pds in POLL_REPOS (nix/modules/bridge.nix:4
 `!testme` works. Mirror has only closed PR#1 (skill smoke test); my fix → PR#2.
 
 Next: DECISIONS entry (B3), mirror branch + PR (B4), !testme (B5).
+
+## 2026-06-11T11:40Z–11:55Z — run 423 red: the upgrade-BASE trap (B5 first attempt)
+
+PR #2 opened (branch upgrade-0.3.0+v0.4.219, head f7b6c8df, 2-line diff) and !testme'd
+(comment 14340) → drone build/run 423. RESULT: install=fail, level 0 — but NOT the PR:
+the run never deployed the PR head. The harness deploys ONCE at the upgrade BASE
+(`previous_version` = vers[-2] = 0.1.1+v0.4 — confirmed: run-423's recipe checkout sat at
+tag 0.1.1+v0.4) and only the upgrade tier chaos-redeploys the PR head. Both published tags
+(0.1.1+v0.4, 0.2.0+v0.4) pin the broken moving `:0.4` → the base crash-loops the SAME
+MODULE_NOT_FOUND (run-423 app log: Node v24.15.0, /app/index.js missing) → install fails
+before my fix is ever exercised. No published version can EVER deploy again (upstream
+republished the tag) — so the upgrade path is structurally unverifiable until a fixed
+version is published post-merge.
+
+Fix (harness, evidence-backed, not a weakening): EXPECTED_NA["upgrade"] (the EXISTING
+declared-intentional-skip mechanism, de-capped levels phase lvl5) now also suppresses the
+base deploy — extracted `upgrade_base()` pure helper in run_recipe_ci.py; single deploy
+becomes the PR head; upgrade tier records "skip"; derive_rungs classifies it intentional
+with the declared reason (visible in results.json skips.intentional — never reported as a
+pass). tests/bluesky-pds/recipe_meta.py declares it with the full reason + the re-enable
+path (UPGRADE_BASE_VERSION="0.3.0+v0.4.219" once published). 6 new unit tests
+(tests/unit/test_upgrade_base.py) lock the decision matrix; meta-key doc regenerated.
+Verified: 253 unit tests pass on cc-ci (was 247), repo lint PASS. Pushed e9745c8.
+
+Re-triggered !testme (comment 14342) → build/run 427. Monitor armed.

machine-docs/DECISIONS.md

@@ -1367,3 +1367,19 @@ version); digest-suffix pinning (abra survey/upgrade tooling chokes on tag@diges
 immich standing note). When upstream cuts real 0.5.x release tags, upgrade properly
 (entrypoint will then need the index.ts/Node-24 migration — recorded in
 cc-ci-plan/upstream/bluesky-pds.md). Never re-pin to `:0.4`/`latest`/minor tags.
+
+**EXPECTED_NA["upgrade"] suppresses the upgrade-tier base deploy (phase bsky, 2026-06-11).**
+The deploy-once design deploys the upgrade BASE (previous published version) and only the
+upgrade tier chaos-redeploys the PR head — so a recipe whose published versions ALL became
+undeployable (bluesky-pds: every tag pins moving `ghcr.io/bluesky-social/pds:0.4`, which
+upstream republished with incompatible main builds) fails INSTALL at the base before the PR
+head is ever exercised, and no UPGRADE_BASE_VERSION value can help (it must be a published
+tag — they're all broken). Decision: declaring the upgrade rung in EXPECTED_NA (the existing
+intentional-skip mechanism) now ALSO makes upgrade_base() return None → the single deploy is
+the PR head itself; the upgrade tier records "skip"; derive_rungs classifies it as the
+DECLARED intentional skip with the recipe's reason (results.json skips.intentional). NOT a
+gate weakening: the rung is never reported pass, the skip + reason are fully visible, and the
+declaration is evidence-backed in the recipe_meta comment + upstream registry; it is the only
+way to exercise a PR at all for a recipe in this state. Re-enable path documented per-recipe
+(bluesky: drop EXPECTED_NA + set UPGRADE_BASE_VERSION="0.3.0+v0.4.219" once merged+published).
+Locked by tests/unit/test_upgrade_base.py.