cc-ci/REVIEW-bsky.md

REVIEW-bsky.md — Adversary verdicts for the bsky sub-phase

Phase SSOT: /srv/cc-ci/cc-ci-plan/plan-phase-bsky-fix.md. Gates: M1 (root cause + green fix PR), M2 (operator handoff complete → ## DONE). This file is append-only; the Builder reads it, never writes it.

---

Baseline recon @2026-06-11 (cold, pre-claim — NOT a verdict)

Established independently from the live recipe checkout on cc-ci (~/.abra/recipes/bluesky-pds, HEAD b2d86ef, tag 0.2.0+v0.4-4-gb2d86ef) so I am ready to verify the Builder's root-cause claim without anchoring:

• compose.yml: app image: ghcr.io/bluesky-social/pds:0.4 — a moving minor tag. Version label coop-cloud.${STACK_NAME}.version=0.2.0+v0.4.
• Recipe overrides the image entrypoint via entrypoint.sh.tmpl (mounted as a config at /entrypoint.sh, entrypoint: dumb-init --, command: /entrypoint.sh). That script ends with exec node --enable-source-maps index.js — a relative index.js, resolved against the image's WORKDIR.
• Known symptom (rcust/shot evidence, DEFERRED.md): app crash-loops Cannot find module '/app/index.js' (MODULE_NOT_FOUND) under Node v24.15.0. Consistent with: image WORKDIR /app, but index.js no longer present there → upstream restructured/rebuilt whatever :0.4 now resolves to.

Verification angles I will hold the Builder's M1/M2 to (per phase plan §3 gates):

1. Root-cause evidence reproduces — I independently inspect the live image (docker run --entrypoint sh ... -c 'ls; node --version' / crane/skopeo) and confirm index.js is absent from the assumed WORKDIR at the OLD pin, and present/working at the NEW pin.
2. The fix is in the recipe mirror PR, not the harness; diff minimal + each line justified against upstream bluesky-social/pds changelog; version label bumped per recipe convention; no test/gate weakening anywhere in cc-ci.
3. The green run is genuinely the PR head via the drone !testme path (not a local hand-run) — full lifecycle incl. lint, level recorded under de-capped semantics.
4. Screenshot real + credential-free (I Read the PNG myself); never shows generated creds.
5. DEFERRED entries closed with pointers; operator handoff in STATUS-bsky.md.

No gate CLAIMED yet — awaiting Builder's first claim(...) on a bsky gate.

Pre-claim recon update @2026-06-11T11:45Z (cold image probe — NOT a verdict)

Independently reproduced BOTH halves of the root cause via docker run on cc-ci:

• ghcr.io/bluesky-social/pds:0.4 (current moving tag, digest …2324702f): Node v24.15.0, WORKDIR /app, ships index.ts only — no index.js. The recipe's entrypoint exec node --enable-source-maps index.js therefore fails with exactly Cannot find module '/app/index.js'. Symptom reproduced. ✔
• ghcr.io/bluesky-social/pds:0.4.219 (Builder's proposed pin): Node v20.20.2, WORKDIR /app, ships index.js (package.json main: index.js). The recipe's existing entrypoint resolves the file → addresses the crash at the image level. ✔

Open scrutiny points I will hold the M1 claim to (NOT yet judged — no gate CLAIMED):

• §2.2 upgrade-preference: 0.4.219 is the latest patch of the previous 0.4 line, not an upgrade to current stable (:0.4 now = 0.5.1). The plan prefers upgrading unless research justifies otherwise. Need: a genuine DECISIONS.md justification (e.g. 0.5.x moved to a TS entrypoint requiring an entrypoint rewrite / larger blast radius) — I'll read it only AFTER my own verdict, and check it against upstream changelog.
• Pin should be exact/immutable (0.4.219 looks like a full patch tag — verify it's not itself moving; digest-pin would be strongest).
• Fix must land on the recipe MIRROR PR and be proven green via the drone !testme path 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.