review(2): Q4.3 bluesky-pds PASS — COLD full lifecycle GREEN (my clone, log adv-bluesky-pr0) 5 tiers+4 custom, deploy-count=1, real upgrade crossover 0.1.1+v0.4→0.2.0+v0.4, clean teardown; P4 atproto-account marker non-vacuous via IN-BAND pre_restore delete+assert-gone (no recipe-PR — bluesky volume restore genuinely round-trips, real recipe diff from postgres recipes); 2 distinct P3 functional (account+post §4.3 round-trip + getSession auth-gating 401); no veto

machine-docs/REVIEW-2.md

@@ -1650,3 +1650,67 @@ restore fix — same data-loss class cc-ci already caught in immich + matrix-syn
 **Isolation note:** verdict from the plan (P1–P8) + the test code (ops.py/test_restore.py/test_backup.py/
 functional/{_mm,test_create_message,test_multiuser_message}.py) + the STATUS Gate-Q4.5 verification
 info + my own cold PR=1 full run AND PR=0 negative control. JOURNAL-2 not consulted before this verdict.
+
+## Q4.3 bluesky-pds — PASS @2026-05-30T01:55Z (COLD, first-hand, my clone /root/adv-verify @origin/main 7d69a59)
+
+Cold full-lifecycle re-run on cc-ci from my OWN clone — the exact claimed command
+`RECIPE=bluesky-pds PR=0 cc-ci-run runner/run_recipe_ci.py` — log `/root/adv-bluesky-pr0.log`.
+
+**Full lifecycle GREEN.**
+- RUN SUMMARY: `deploy-count = 1 (expect 1)`; `install/upgrade/backup/restore/custom` **all pass**.
+- Upgrade: `head_ref=b2d86efb chaos-version=b2d86efb version=0.1.1+v0.4→0.2.0+v0.4` (HC1,
+  head_ref==chaos-version, real prev→PR-head crossover); `test_upgrade_preserves_data PASSED`.
+- Restore: `tests/bluesky-pds/test_restore.py::test_restore_returns_state PASSED`; backup:
+  `test_backup_captures_state PASSED`.
+- Custom — **4 PASS**: `test_account_lifecycle_and_post_roundtrip`,
+  `test_describe_server_returns_atproto_envelope`, `test_pds_health_returns_version`,
+  `test_get_session_requires_auth`.
+- Clean teardown: post-run no pds/bsky stack; 0 bsky/pds secrets / 0 volumes / 0 networks.
+
+**P4 — non-vacuous, NO recipe-PR (correctly).** The marker is a DETERMINISTIC atproto **account**
+(real recipe data in the PDS sqlite under /pds — the backed-up volume), not a loose file. The
+non-vacuousness guard is IN-BAND: `ops.pre_restore` deletes the account AND `assert not
+account_exists(...)` ("marker account delete did not take") — so the pre-restore state provably
+diverges from the backup, and the orchestrated run would have ERRORED at the pre_restore seed if the
+delete hadn't taken. The run cleared pre_restore and `test_restore_returns_state` then PASSED (account
+resolves again via live XRPC `describeRepo`) — i.e. the volume backup→restore genuinely round-trips
+and the running PDS reloads it. This is the in-band equivalent of mattermost's PR=0 negative control;
+no fix-vs-nofix split exists here because **bluesky's volume restore already works** (unlike the
+postgres recipes whose running DB held its store open and didn't reload — the data-loss class cc-ci
+caught in immich + mattermost). `account_exists` hits the live public XRPC endpoint fresh (no cache);
+the handle is per-run-domain-unique (no cross-run contamination). The upgrade tier reuses the same
+marker → data-continuity across the chaos crossover proven too.
+
+**P3 — ≥2 SEPARATE non-vacuous functional tests (read the bodies):**
+- `test_account_lifecycle_and_post_roundtrip` (§4.3, the prescribed flow): goat `pds describe` asserts
+  the PDS self-identifies as `did:web:<domain>` → `goat pds admin account create` (parse `did:plc:…`)
+  → public `com.atproto.server.createSession` (login → accessJwt) → `repo.createRecord`
+  (`app.bsky.feed.post`, unique marker text) → `repo.getRecord` → assert `value.text` round-trips +
+  `$type` correct → account delete. Per-run UUID handle + per-run marker ⇒ no stale/echo false-pass;
+  four distinct PDS layers (self-DID, admin API, public auth, repo CRUD).
+- `test_get_session_requires_auth` — GET `com.atproto.server.getSession` with NO token → asserts
+  **401** + a JSON XRPC error envelope. A real security-contract assertion (200=anonymous leak,
+  404=route missing, 5xx=backend broken) — distinct path from the account/post round-trip, not a
+  generic 200 health check.
+- (`test_describe_server_returns_atproto_envelope` + `test_pds_health_returns_version` are supporting
+  liveness, above the P3 floor.)
+
+**P2 parity:** recipe-maintainer `goat_account.py` → `functional/test_account_and_post.py` (account
+lifecycle via goat CLI), extended with the atproto post round-trip. **P5/P6 N/A** — self-contained (no
+external dep); atproto is an API/CLI protocol fully exercised; no browser-only UX owed. **P7** — no
+weakened/skipped/mocked tests; all real assertions; P4 is fail-observable in-band.
+
+**Break-it checks:** (1) in-band pre_restore delete+assert-gone proves the P4 has teeth without a
+recipe-PR; (2) clean teardown verified post-run (no residue); (3) per-run unique handle+marker defeat
+stale-response false-pass; (4) auth-gating test would catch an anonymous-access leak; (5)
+deploy-count=1 (no hidden redeploy).
+
+**Verdict: Q4.3 bluesky-pds PASS.** Full lifecycle GREEN cold, deploy-count=1, real upgrade crossover
+0.1.1+v0.4→0.2.0+v0.4, P4 account-marker survives backup→restore (non-vacuous, in-band delete-assert),
+2 distinct P3 functional tests (account+post round-trip + auth gating), clean teardown. No `## VETO`.
+Advances P1 coverage (bluesky-pds enrolled). Correctly NO recipe-PR — bluesky's volume restore
+round-trips cleanly (a genuine recipe difference from the postgres recipes, borne out by my run).
+
+**Isolation note:** verdict from the plan (P1–P8) + the test code (_p4.py / ops.py / test_{restore,
+backup,upgrade}.py / functional/{test_account_and_post,test_session_auth}.py) + the STATUS Gate-Q4.3
+verification info + my own cold full-lifecycle run. JOURNAL-2 not consulted before this verdict.