journal(2): immich claimed; remaining-recipe scope + backup-capability survey (ghost/bluesky/uptime-kuma/mattermost all backup-capable → P4 overlays required)

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

machine-docs/JOURNAL-2.md

@@ -1196,3 +1196,38 @@ extension and on the live immich-server's held connections. So I'm deploying imm
 will test seed→dump→drop→restore→verify directly in the `database` container to pin down the exact
 dump/restore commands (likely `pg_dumpall --clean --if-exists` and connection-termination on restore)
 that round-trip the ci_marker, then bake the proven commands into pg_backup.sh. No "should work".
+
+---
+## 2026-05-30T~23:22 — Q3.5 immich CLAIMED; remaining-recipe scope (backup-capability survey)
+
+immich P4 done the right way: recipe-PR `recipe-maintainers/immich#1` (mechanism validated live, then
+full lifecycle green `/root/ccci-immich-prfull.log` — 5 tiers + 3 custom, deploy-count=1, clean
+teardown). Added a genuine 2nd P3 functional test (asset-processing: exifInfo metadata + library
+statistics) so the §4.3 ≥2-tests floor is met by separate test functions, not one test doing double
+duty (avoids the bluesky F2-8 "floor BYPASSED" failure mode). Claimed `0487631`.
+
+**Remaining Phase-2 work (post-immich), by node-contention class.** The Adversary will cold-verify
+immich next (full ~30min run; MAX_TESTS=1) so I should NOT start a heavy deploy until it frees.
+
+Backup-capability survey (just done) of the 4 overlay-less recipes — ALL backup-capable, so P4
+data-integrity overlays are REQUIRED (not N/A like mailu):
+- **ghost** — app vol `/var/lib/ghost/content` (path) + mysql `mysqldump --tab` pre-hook. P4: seed a
+  ghost post (mysql) OR content marker. Also owes §4.3 create-post (named Adversary standing
+  condition) — needs Ghost owner-setup + admin token. Heavy (~15-20min cold start).
+- **bluesky-pds** — `backupbot.backup=true` on pds svc (data volume: sqlite account repos + blobs).
+  P4: create account+post (goat), backup, wipe, restore, assert the post/account survive. (F2-8 was
+  about the §4.3 floor; bluesky already has 4 functional tests incl. account+post round-trip.)
+- **uptime-kuma** — default sqlite data-vol backup (mariadb variant has dump hooks). P4: create a
+  monitor, backup, restore, assert. Also owes §4.3 create-monitor (deferred — needs a Socket.IO
+  client primitive in harness; uptime-kuma's setup wizard + monitor CRUD are Socket.IO, not REST).
+- **mattermost-lts** — app `/mattermost` + postgres `pg_dump` pre-hook. P4: create team/channel/
+  message, backup, restore, assert. Also owes §4.3 create-message read-back depth.
+
+Overlay-complete, need only a formal green-run + gate claim: **matrix-synapse**, **lasuite-docs**
+(dep: keycloak). **plausible** needs a cold green run when the upstream clickhouse-backup GitHub
+rate-limit cools (deploy converges) — preserve the log. **discourse** + **drone** remain BLOCKED
+(upstream bitnami images gone / operator /etc/timezone host-deploy).
+
+NEXT unblocked unit (when node free): pick a recipe and take it to a claim. Suggest order by ease:
+matrix-synapse (overlay-complete → just run+claim) → bluesky-pds P4 overlay → mattermost-lts P4 →
+ghost (P4 + §4.3 create-post) → uptime-kuma (P4 + Socket.IO §4.3). Keep heavy deploys sequential.