# STATUS — phase bsky (fix bluesky-pds recipe + screenshot)

Phase SSOT: /srv/cc-ci/cc-ci-plan/plan-phase-bsky-fix.md

## DONE

Phase bsky complete @2026-06-11T15:55Z: M1 PASS (REVIEW-bsky 369f4f4 @12:30Z) + M2 PASS
(42eabba @15:48Z, incl. the Adversary's own independent !testme re-trigger → build 435
level 5 at PR head), no VETO. bluesky-pds root cause proven, fix PR #2 OPEN+UNMERGED for
the operator (re-pin 0.4.219), green through the full lifecycle incl. lint on real drone
CI, screenshot real and verified, DEFERRED entries closed, operator runbook below.


## M2 claim — operator handoff complete (2026-06-11T15:50Z)

WHAT (phase plan §3 M2, all builder-side items in place; the fresh cold pass is yours):
1. **Green at PR head, re-triggerable:** PR #2 head f7b6c8df unchanged since run 427
   (level 5). HOW to re-run independently: post `!testme` on PR #2 — the bridge polls
   ~1 min, triggers a drone build, run dir /var/lib/cc-ci-runs/<n>. EXPECTED: level=5,
   rungs install/backup_restore/functional/lint=pass, upgrade=skip with
   skips.intentional.upgrade = the declared reason, clean_teardown+no_secret_leak=true,
   screenshot.png = the PDS landing page. (cc-ci main also unchanged functionally since
   e9745c8; HEAD at claim time: see this commit.)
2. **PNG to independently Read:** https://ci.commoninternet.net/runs/427/screenshot.png
   (+ the fresh run's, if you re-trigger). EXPECTED: ASCII Bluesky butterfly landing
   page, no credentials.
3. **Level under new semantics + baseline reconciled:** achieved level 5 (de-capped:
   skip climbs), upgrade = declared intentional skip with re-enable path. Old baseline
   "full lifecycle green" (Phase-2 e45e0ee, pre-results-era) reconciled: unreproducible
   for upstream reasons (moving-tag republish broke ALL published versions); the PR
   restores deployability; recorded in DEFERRED closure + JOURNAL-bsky 12:15Z entry.
4. **DEFERRED entries closed with pointers:** machine-docs/DEFERRED.md bluesky entry
   marked RESOLVED @2026-06-11 (commit f150012) — explicitly closes BOTH the re-pin
   follow-up and the rcust M2 baseline-exclusion note, with PR/run/registry pointers.
5. **Operator summary:** below in this file (what was wrong / what the PR changes /
   post-merge steps 1-5 incl. version publish, EXPECTED_NA→UPGRADE_BASE_VERSION swap,
   no canonical to reseed, never re-pin :0.4).
6. **PR left OPEN** for the operator (merged=false; immich PR#2/plausible PR#3 precedent).

WHERE: cc-ci main (STATUS/JOURNAL/BACKLOG-bsky, DEFERRED f150012, DECISIONS 2026-06-11
×2, harness e9745c8); mirror PR #2 head f7b6c8df; runs 427 (green) / 423 (negative
control); upstream registry cc-ci-plan/upstream/bluesky-pds.md @ f395247.

## M1 claim — root cause + green fix PR + screenshot (2026-06-11T12:05Z)

### WHAT

1. Root cause proven with evidence (below).
2. Fix PR open on the recipe mirror: **recipe-maintainers/bluesky-pds PR #2**, branch
   `upgrade-0.3.0+v0.4.219`, head `f7b6c8df` — 2-line compose.yml diff (image
   `ghcr.io/bluesky-social/pds:0.4` → `0.4.219`; version label `0.2.0+v0.4` →
   `0.3.0+v0.4.219`). UNMERGED (operator merges).
3. `!testme` on the PR green through the full lifecycle via the real drone path:
   **run 427 = level 5** — install/backup_restore/functional/lint all PASS, upgrade =
   DECLARED intentional skip (justification below), clean_teardown, no_secret_leak.
4. Screenshot captured on that PR run and visually verified by me: the genuine PDS
   HTTP landing page (ASCII Bluesky logo, "This is an AT Protocol Personal Data
   Server", /xrpc/ pointer, upstream links) — real, representative, credential-free.
   No SCREENSHOT hook needed.

### Root cause

The recipe pins MOVING tag `ghcr.io/bluesky-social/pds:0.4` and overrides the entrypoint
with a script ending `exec node --enable-source-maps index.js` (relative to WORKDIR /app).
Upstream now publishes main-branch builds to `:0.4` (== `latest`, manifest
`sha256:871194d2…`, created 2026-05-30): `@atproto/pds` **0.5.1**, Node v24.15.0, service
restructured to `/app/index.ts` (CMD `node --enable-source-maps index.ts`; **no
index.js**) → crash-loop `Cannot find module '/app/index.js'`. Exact tag `0.4.219`
(newest released; ghcr digest `sha256:e0b756701c92…`) keeps the expected layout: Node
v20.20.2, `/app/index.js`, dumb-init, CMD identical to the recipe's exec line.

HOW to verify root cause (any host with ssh cc-ci):
- `ssh cc-ci 'docker run --rm --entrypoint sh ghcr.io/bluesky-social/pds:0.4 -c "node --version; ls /app; grep @atproto/pds /app/package.json"'`
  → EXPECTED v24.15.0; index.ts, NO index.js; `"@atproto/pds": "0.5.1"`
- `ssh cc-ci 'docker run --rm --entrypoint sh ghcr.io/bluesky-social/pds:0.4.219 -c "node --version; ls /app; grep @atproto/pds /app/package.json"'`
  → EXPECTED v20.20.2; index.js present; `"@atproto/pds": "0.4.219"`
- Upstream: Dockerfile@main = node:24.15-alpine3.23 + CMD index.ts;
  Dockerfile@v0.4.219 = node:20.20-alpine3.23 + CMD index.js. Registry doc:
  cc-ci-plan/upstream/bluesky-pds.md (plan repo f395247).

### Upgrade-rung justification (the "justify status either way" item)

Published versions exist (0.1.1+v0.4, 0.2.0+v0.4) but BOTH pin the republished `:0.4` →
no published version can deploy as the upgrade base anymore (negative control: run 423,
pre-harness-change, deployed base 0.1.1+v0.4 → identical MODULE_NOT_FOUND crash-loop,
install=fail, PR head never reached; run-423 recipe checkout sat at tag 0.1.1+v0.4).
Harness change e9745c8 (main): declaring the upgrade rung in recipe_meta EXPECTED_NA now
also suppresses the base deploy — single deploy = the PR head; the upgrade tier records
"skip"; derive_rungs classifies it the DECLARED intentional skip; reason fully visible in
results.json `skips.intentional` and on the card. NOT a weakening: the rung is never
reported pass; decision + re-enable path in machine-docs/DECISIONS.md (re-enable =
UPGRADE_BASE_VERSION="0.3.0+v0.4.219" once merged+published).
HOW: `cc-ci-run -m pytest tests/unit/ -q` from a cold clone of main on cc-ci →
EXPECTED 253 passed (6 new in tests/unit/test_upgrade_base.py);
`nix develop .#lint -c bash scripts/lint.sh` → EXPECTED `lint: PASS`.

### Green-run evidence (run 427, drone path)

- Trigger: PR #2 comment 14342 (`!testme`) → bridge log line
  `[poll] triggered build 427 for bluesky-pds@f7b6c8df (PR #2, comment 14342)`;
  outcome line `reflected outcome build 427 (bluesky-pds PR #2): success`; PR result
  comment 14343 "✅ passed @ f7b6c8df".
- HOW: `ssh cc-ci 'cat /var/lib/cc-ci-runs/427/results.json'` → EXPECTED level=5,
  ref=f7b6c8dfb81c, rungs install/backup_restore/functional/lint=pass + upgrade=skip,
  skips.intentional.upgrade=<declared reason>, flags clean_teardown+no_secret_leak true.
- PR-head proof: run-427 per-run recipe checkout
  (`/var/lib/cc-ci-runs/427/abra/recipes/bluesky-pds`) at `f7b6c8d chore: upgrade to
  0.3.0+v0.4.219`, compose.yml line 6 image=…:0.4.219.
- Visuals: https://ci.commoninternet.net/runs/427/summary.png (card: level 5 of 5, all
  tiers PASS, upgrade INTENTIONAL SKIP + reason, screenshot thumb, clean-teardown +
  no-secret-leak chips), …/badge.svg ("cc-ci: level 5", green),
  …/screenshot.png (the PDS landing page described above).

### WHERE

- cc-ci main @ 72b3d6c (harness change e9745c8; journal/decisions 72b3d6c).
- Mirror PR #2: https://git.autonomic.zone/recipe-maintainers/bluesky-pds/pulls/2
  (head f7b6c8df; base main b2d86ef).
- Runs: /var/lib/cc-ci-runs/427 (green, PR head), /var/lib/cc-ci-runs/423 (negative
  control, pre-change base trap).
- Upstream registry: cc-ci-plan/upstream/bluesky-pds.md @ plan-repo f395247.

## Operator summary

**What was wrong.** bluesky-pds could not deploy at all: the app crash-looped
`Cannot find module '/app/index.js'`. The recipe pins the MOVING image tag
`ghcr.io/bluesky-social/pds:0.4`, and upstream now republishes that tag with main-branch
builds (currently @atproto/pds 0.5.1 on Node 24, where the service entrypoint moved to
`/app/index.ts` — `index.js` no longer exists). The recipe's entrypoint override
(`exec node --enable-source-maps index.js`) can no longer resolve. This also silently
broke BOTH previously published recipe versions (0.1.1+v0.4, 0.2.0+v0.4 — same moving
pin), so no historical version can deploy anymore either.

**What the PR changes.** https://git.autonomic.zone/recipe-maintainers/bluesky-pds/pulls/2
(branch `upgrade-0.3.0+v0.4.219`, head f7b6c8df), a 2-line compose.yml diff: pin the exact
released tag `0.4.219` (newest released; classic Node 20 / index.js layout the recipe's
entrypoint expects) and bump the version label to `0.3.0+v0.4.219`. Why not 0.5.1: it has
no release tag (only the moving :0.4/latest + sha- tags from main) and needs an entrypoint
migration; do that as a proper upgrade when upstream cuts a 0.5.x release tag (notes in
cc-ci-plan/upstream/bluesky-pds.md). Proven at PR head via real drone CI: run 427 =
**level 5** (install, backup/restore, functional, lint PASS; screenshot = real PDS landing
page). The upgrade rung is a DECLARED intentional skip — there is no deployable published
base to upgrade FROM (see above); declaration + reason in tests/bluesky-pds/recipe_meta.py.

**What to do post-merge.**
1. Merge PR #2 (your call, as with immich PR#2 / plausible PR#3 — all left open).
2. Publish the version per recipe convention (annotated tag `0.3.0+v0.4.219` /
   `abra recipe release`) so `abra recipe versions` lists a deployable version again.
3. After the tag is published: in cc-ci `tests/bluesky-pds/recipe_meta.py`, DROP the
   `EXPECTED_NA["upgrade"]` declaration and set
   `UPGRADE_BASE_VERSION = "0.3.0+v0.4.219"` — the upgrade rung then re-activates from
   the first deployable base (the older broken tags must never be auto-picked as base).
4. Canonical/warm: nothing to reseed — bluesky-pds has no canonical
   (/var/lib/ci-warm has no entry); the normal promote-on-green flow mints one on the
   first green run post-merge.
5. Never re-pin this recipe to `:0.4`/`latest` — upstream demonstrably republishes the
   minor tag (registry notes: cc-ci-plan/upstream/bluesky-pds.md).