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

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.