# DEFERRED — items parked for operator input The single canonical registry of things the loops have deliberately decided **not to do autonomously**, and that need operator input to move on. Filing here is the loops' explicit way of saying *"we've considered this, we're not doing it on our own; the operator gets to decide if/when it comes back"* — instead of a vague "Q4 follow-up" buried in a JOURNAL. This list is **open-ended.** Items can sit here indefinitely; the operator reviews at their own pace. There is **no obligation to close every item** — many will reasonably stay deferred for the life of the project. Closing is operator-driven. The Phase-4 cleanup pass should **surface** this list to the operator (so it's seen at least once before the build is called done) — but does **not** force closure. ## Conventions - **Append-only.** Either loop may file; never edit/delete someone else's entry. Closing = check the box + a one-liner pointing to the commit / PR / operator decision. - **Each entry should clearly say what the loops would need from the operator** to lift the deferral (an opt-in flag, a resource decision, an architectural call, plain "go ahead and do it") — that's the actionable part for the operator skimming this list. - A "Re-entry trigger" / IDEA cross-link is **optional** — include when there's a natural mechanism (e.g. an opt-in flag in `cc-ci-plan/IDEAS.md`); not every deferral has one, and many legitimately don't. ## Format (one item per entry) ``` ### YYYY-MM-DD — - [ ] **What:** - **Filed by:** , phase - **Reason for deferral:** - **Re-entry trigger:** - **Linked IDEA / BACKLOG:** ``` --- ## Open deferrals ### 2026-05-28 — matrix-synapse `compress_state.sh` port - [ ] **What:** Port the upstream recipe-maintainer `recipe-info/matrix-synapse/tests/compress_state.sh` to a cc-ci functional test under `tests/matrix-synapse/functional/`. The original creates state groups WITHOUT edges (full snapshots — Synapse's bloat pattern), runs `synapse_auto_compressor`, and asserts row counts drop. - **Filed by:** Builder, phase 2 (Q4.1 matrix-synapse PARITY pass) - **Reason for deferral:** Needs N>>1 synthesized state groups on every fresh deploy. Cost/time tradeoff is real — too-small N loses the test's meaning (state-group bloat is by definition a large-state phenomenon), too-large N inflates per-run time. Defensible defer; operator-confirmed 2026-05-28: heavier than needed for default CI. - **Re-entry trigger:** the `--extra` opt-in flag (see linked IDEA) so this runs only when the operator explicitly asks for the heavy suite; or a dedicated long-running matrix instance. - **Linked IDEA:** `cc-ci-plan/IDEAS.md` — *Optional `--extra` flag for heavy/operational tests*. ### 2026-05-28 — matrix-synapse `test_complexity_limit.sh` port - [ ] **What:** Port `recipe-info/matrix-synapse/tests/test_complexity_limit.sh` — exercise Synapse's complexity-limit rejection of overly-complex events. - **Filed by:** Builder, phase 2 (Q4.1 matrix-synapse PARITY pass) - **Reason for deferral:** Load-test class; needs many-event setup. Operator-confirmed 2026-05-28: more than needed for a default matrix CI test. - **Re-entry trigger:** the `--extra` opt-in flag (linked IDEA). - **Linked IDEA:** `cc-ci-plan/IDEAS.md` — *Optional `--extra` flag for heavy/operational tests*. ### 2026-05-28 — matrix-synapse `test_purge.sh` port - [ ] **What:** Port `recipe-info/matrix-synapse/tests/test_purge.sh` — exercise the recipe's `abra.sh db purge_history` / `db purge_room` admin helpers. - **Filed by:** Builder, phase 2 (Q4.1 matrix-synapse PARITY pass) - **Reason for deferral:** Recipe-helper-script tests, not synapse-behaviour tests (orthogonal to default Phase-2 coverage). Operator-confirmed 2026-05-28: more than needed for a default matrix CI test. - **Re-entry trigger:** the `--extra` opt-in flag (linked IDEA) — so PRs touching the recipe's abra helper scripts can opt in to exercising them. - **Linked IDEA:** `cc-ci-plan/IDEAS.md` — *Optional `--extra` flag for heavy/operational tests*. ### 2026-05-28 — matrix-synapse media upload/download roundtrip - [ ] **What:** Add `tests/matrix-synapse/functional/test_media_upload_roundtrip.py` exercising `/_matrix/media/v3/upload` + `/_matrix/media/v3/download//`. - **Filed by:** Builder, phase 2 (Q4.1 matrix-synapse PARITY pass) - **Reason for deferral:** Not in the Q4.1 first pass; the three currently-landed functional tests already cover Synapse's defining behaviour (register / room / message / federation). - **Re-entry trigger:** Phase-2 follow-up (a recipe-coverage breadth pass) OR a PR that touches Synapse's media subsystem. - **Linked IDEA:** — ### 2026-05-28 — lasuite-docs OIDC parity ports + create-a-doc deeper test - [x] **CLOSED @2026-05-28** by Builder commits `41ede13` (SSO-dep refactor: deps-after-generic tiers + `tests/lasuite-docs/setup_custom_tests.sh` hook + `deps_creds` fixture) and `cd25f52` (functional/test_oidc_login.py parity port + functional/test_create_doc.py §4.3 prescribed create-a-doc + read-back). Both tests marked @pytest.mark.requires_deps. Cold-verifiable: `RECIPE=lasuite-docs STAGES=install,custom cc-ci-run runner/run_recipe_ci.py` → 5 custom tests PASS (incl. the two new ones), deploy-count=2 (recipe + keycloak dep). `upload_conversion.py` parity (.md/.docx upload+conversion via authenticated `/api/v1.0/documents//upload`) remains as a Phase-2 follow-up below. ### 2026-05-28 — cryptpad create-a-pad + content round-trip Playwright test — ✅ RESOLVED @2026-05-29 - [x] **RESOLVED @2026-05-29 (Builder, commits `05d0dc1` test + `656b68b` cold-timing fix).** `tests/cryptpad/playwright/test_pad_content_roundtrip.py` lands the §4.3 create-pad → type → FRESH-context read-back, **green in the full harness custom tier** (`/root/ccci-cryptpad-full3.log`: install/upgrade/backup/restore/custom all pass; `test_cryptpad_pad_content_survives_fresh_session` PASSED; deploy-count=1; clean teardown). Mapped empirically against CryptPad 2026.2.0 (the prior deferral cited 5.7.0 fragility): editor in nested `…/pad/ckeditor-inner.html`; `/pad/` DOES auto-create a fragment-keyed pad after ~15s cold init; patience-tuned (`goto_with_retry` + 240s hash-wait + reload). F2-9 (Adversary-owned) satisfied — left for the Adversary to close on cold-verify. (Detail below retained for audit.) - [ ] **What:** Add `tests/cryptpad/playwright/test_pad_content_roundtrip.py` — exercise the full "open /pad/, type uniquely-marked content, reload, assert marker survives in the decrypted pad" lifecycle. The §4.3 prescribed CryptPad test. - **Filed by:** Builder, phase 2 (Q3.4 cryptpad PARITY pass) - **Reason for deferral:** CryptPad's pad-creation flow is **version-specific** in the release under test (10.6.0+5.7.0). `/pad/` does NOT auto-redirect to a fragment-keyed pad URL on visit; the UI selector for "new rich-text" varies across versions; three drafts each missed the right contract. The maximal subset that IS shipped (parity health_check + recipe-specific spa_assets + Playwright SPA-render with console-error filter) covers the same JS-pipeline initialization that create-a-pad relies on. F2-9 Adversary conditional sign-off granted with the explicit expectation this lifts before Phase-2 DONE. - **Re-entry trigger:** Adversary's F2-9 sign-off requires this lifts BEFORE Phase-2 DONE — must pin a stable CryptPad app-launch contract (e.g. `/pad/?new=1` if supported, or a role-based Playwright accessibility-tree selector for "New Rich Text") + ship the create-and-read-back test. Q5.2 cold-sample MUST include this. - **Linked IDEA:** — ### 2026-05-28 — uptime-kuma create-a-monitor (§4.3 prescribed) - [ ] **What:** Add a test that completes uptime-kuma's first-run setup wizard via Socket.IO, logs in to obtain a JWT, creates a monitor (`monitor add` Socket.IO emit), and asserts the monitor appears in the listed-monitors response. - **Filed by:** Builder, phase 2 (Q4.8 uptime-kuma enrollment) - **Reason for deferral:** Requires a Socket.IO client primitive in `runner/harness/` (uptime-kuma uses Socket.IO for ALL real-time updates including setup + monitor CRUD). Today's tests (parity health + Socket.IO handshake + SPA branding) cover the same handshake + bundle the setup-then-monitor flow would use; adding a full Socket.IO client is a substantial harness primitive worth deferring until either (a) another recipe also needs Socket.IO interaction or (b) the `--extra` flag lands so this can live in `extra/`. - **Re-entry trigger:** the `--extra` opt-in flag (linked IDEA) OR another recipe enrollment that requires Socket.IO client primitives in the harness (whichever comes first). - **Linked IDEA:** `cc-ci-plan/IDEAS.md` — *Optional `--extra` flag for heavy/operational tests*. ### 2026-05-28 — ghost create-a-post round-trip (§4.3 prescribed) — ✅ RESOLVED @2026-05-30 - [x] **RESOLVED @2026-05-30 (Builder):** `tests/ghost/functional/test_post_roundtrip.py` (helper `_ghost.py`) authored + GREEN (`test_create_post_roundtrip PASSED`, full-lifecycle run `/root/ccci-ghost-pr1d.log`). Owner setup → admin session cookie → POST published post (unique marker) → GET read-back (title+html). Part of the Q4.4 ghost claim (STATUS-2 ## Gate Q4.4). - [ ] **What:** Add `tests/ghost/functional/test_post_roundtrip.py` exercising Ghost's admin setup + token-auth + POST `/ghost/api/v3/admin/posts/` (create) + GET `/ghost/api/v3/admin/posts//` (read back), asserting the post round-trips. - **Filed by:** Builder, phase 2 (Q4.4 ghost enrollment) - **Reason for deferral:** Requires Ghost's first-run owner-setup flow (POST `/ghost/api/v3/admin/authentication/setup/` with per-run admin email+password as class-B run-scoped) + JWT token management for the admin API. The current 3 tests (parity health + content_api + admin_redirect) cover the same Ghost-server / API / admin-route surface; the create-post flow is the natural §4.3 deeper test and is doable, but adds setup state to manage. Reasonable to defer to the `--extra` flag rollout OR a Phase-2 follow-up specifically for Q4 deeper tests. - **Re-entry trigger:** the `--extra` opt-in flag (linked IDEA) OR a Q4 deeper-test pass before Phase-2 DONE if the Adversary calls for it (Phase-4 cleanup pass MUST review). - **Linked IDEA:** `cc-ci-plan/IDEAS.md` — *Optional `--extra` flag for heavy/operational tests*. ### 2026-05-28 — Q2.2 authentik enrollment + `setup_authentik_realm` SSO backend - [ ] **What:** Enroll authentik in cc-ci tests/ (mirror-and-enroll if not yet mirrored) + add a `setup_authentik_realm` (or equivalent provider-pluggable name) backend in `runner/harness/sso.py` mirroring the keycloak path; a dependent recipe should be able to declare `DEPS = ["authentik"]` and use the same `harness.sso.setup__*` API. - **Filed by:** Adversary (F2-7, Q2 checkpoint) → migrated to DEFERRED.md by Builder - **Reason for deferral:** Q2.4 acceptance is already proven via keycloak; no Phase-2 dependent recipe yet REQUIRES authentik specifically (the lasuite-* recipes use keycloak; cryptpad's recipe-maintainer SSO test uses authentik but that parity port is already deferred above). The SSO harness's OIDC FLOW primitives (`oidc_password_grant`, `assert_discovery_endpoint`) are already provider-agnostic; only `setup_keycloak_realm` is keycloak-specific. - **Re-entry trigger (NARROWED per operator SSO policy 2026-05-29):** ONLY when a recipe **genuinely REQUIRES authentik** (cannot work under keycloak). Dropped the former triggers — cryptpad's OIDC is now tested under **keycloak** (its upstream uses authentik but keycloak is equally valid), and **Phase-2 DONE is explicitly NOT gated on authentik** (no "prove pluggability"/second-provider/ DONE-review trigger). keycloak is the default SSO provider for all recipe OIDC tests. See DECISIONS.md "SSO-provider policy". - **Linked IDEA:** — ### 2026-05-29 — heavy-recipe upgrade tier needs more host disk (28GB too small) — CLOSED @2026-05-29 - [x] **CLOSED @2026-05-29:** orchestrator resized the cc-ci VM disk; filesystem auto-grew to **64G (44G free, 30% used)**, infra healthy, warm keycloak up. The disk constraint is resolved. The heavy-recipe upgrade tiers are now runnable. **Follow-on (now ACTIVE backlog, not a deferral):** run lasuite-drive's FULL lifecycle incl. the upgrade tier GREEN + Adversary cold-verify for the Q3.2 gate (per the Adversary, the upgrade tier is no longer validly deferrable); then re-confirm immich/lasuite-meet/lasuite-docs upgrade tiers. Tracked under BACKLOG-2 Q3.2. **UPDATE @2026-05-29:** lasuite-drive full lifecycle (incl. upgrade tier) is now **3× green** (commits `a151489` install-time OIDC + `4b38b66` collabora-ready upgrade gate; logs r2/r3/r4); Q3.2 CLAIMED, awaiting Adversary. The upgrade tier converged cleanly at 64G disk with the collabora-ready gate (the old 28GB pull-overflow concern below is moot at 64G). Remaining follow-on: re-confirm immich/lasuite-meet/lasuite-docs upgrade tiers when those recipes' gates run. - [ ] **What:** The upgrade tier for the heaviest recipes cannot complete on the 28GB host. Proven on **lasuite-drive**: the prev→PR-head chaos upgrade crosses two multi-GB office image versions at once — onlyoffice/documentserver-de `9.2 → 9.3.1.2` (3.94GB each) + collabora/code `25.04.9.1.1 → 25.04.9.4.1` (~1GB) — so ~10GB of office images must coexist on disk during the in-place rolling update. The host has only ~14GB docker headroom over its ~13GB baseline (nix store ~9.6GB + infra images), so the PR-head pull hit 99% and the deploy failed. There is **no harness mitigation** (the prev images are *running* when the new must be pulled — cannot `rmi` a running image; nothing dangling to prune pre-upgrade). install/backup/restore/custom (single version, ~6GB) all fit and pass — only the upgrade tier overflows. Almost certainly also blocks the upgrade tier of other heavy recipes (lasuite-docs ships collabora; immich ships multi-GB ML images; lasuite-meet). - **Filed by:** Builder, phase 2 (Q3.2 lasuite-drive full-lifecycle attempt) - **Reason for deferral:** Class A1 EXTERNAL infra input — host disk size. Not improvisable; not a test-quality issue; the recipe legitimately bumps office image tags across releases. - **Operator action to lift:** grow the cc-ci host disk (resize the droplet volume + online-grow the filesystem) to give heavy-recipe upgrade tiers transient headroom — ~+20GB would comfortably cover the dual-office-version crossover and the rest of the heavy set. Then re-run the full lasuite-drive lifecycle (and re-confirm immich/lasuite-meet/lasuite-docs upgrade tiers). - **Re-entry trigger:** operator disk resize, OR Phase-2b pull-through cache + image-GC policy work. - **Linked IDEA:** `cc-ci-plan/IDEAS.md` (pull-through cache / Phase 2b). --- ## Closed deferrals (none yet — append `### YYYY-MM-DD — CLOSED (commit/PR)` here when re-entered.) ### 2026-05-28 — plausible (Q4.7) recipe enrollment - [ ] **What:** Enroll plausible in cc-ci with parity health_check + ≥2 specific tests (per plan §4.3: "track a test event, query it back"). `tests/plausible/recipe_meta.py` + `tests/plausible/functional/test_health_check.py` are drafted (commit pending) but the e2e fails: services converge but the served app returns HTTP 500 from `/` for the full 600s HTTP_TIMEOUT window — config-class failure, not a deploy-timing issue. - **Filed by:** Builder, phase 2 - **Reason for deferral:** The first deploy attempt set EXTRA_ENV={DISABLE_AUTH=true, DISABLE_REGISTRATION=true, SECRET_KEY_BASE=<64-char fixed>}. Stack converged 1/1 but the Phoenix app returned 500 the whole window. Likely missing required config (e.g. DATABASE_URL, MAILER vars, or a Phoenix bootstrap step). Diagnosing requires live container-log inspection + iterative env tuning — more debug time than fits a single autonomous loop pass. - **Operator action to lift:** Either (a) iterate on plausible's required env / debug live logs in an interactive session; OR (b) re-enroll plausible after the operator confirms a working env recipe. - **Linked IDEA:** — ### 2026-05-28 — lasuite-docs upload_conversion.py parity (.md/.docx upload + conversion) - [ ] **What:** Port `recipe-info/lasuite-docs/tests/upload_conversion.py`. The original uploads a `.md` and a `.docx` to `POST /api/v1.0/documents//upload` and asserts the y-provider / docspec conversion paths fire (.md → yjs; .docx → BlockNote → yjs). - **Filed by:** Builder, phase 2 (Q3.1 follow-up after the OIDC pieces closed) - **Reason for deferral:** Builder priority — the §4.3 create-a-doc floor is met by test_create_doc.py (closed in the entry above). Upload/conversion exercises a distinct subsystem (y-provider + docspec) and adds two binary fixtures + a multi-service-readiness wait. Defensible defer; lift when the operator wants the deeper coverage OR Phase-4 reviews. ### 2026-05-29 — immich recipe needs a pg_dump backup hook for reliable DB restore (P4) - [ ] **What:** immich's upstream recipe backs up the LIVE postgres data VOLUME via restic (`backupbot.backup=true` on `database`, no pg_dump hook), so a DB row does NOT survive `abra app restore` (diagnosed: seed→backup→drop→restore→row absent; app healthy). Real backup data-integrity (P4) requires a consistent SQL dump. **Fix:** add the drive/meet pattern to the immich recipe — `pg_backup.sh` swarm-config + labels `backupbot.backup.pre-hook: "/pg_backup.sh backup"` + `backupbot.backup.volumes.postgres.path: "backup.sql"` + `backupbot.restore.post-hook: "/pg_backup.sh restore"` (adapt POSTGRES_USER=postgres, POSTGRES_DB=immich). Via the recipe-create-pr flow (mirror immich on recipe-maintainers → branch → cc-ci full-suite GREEN on the PR incl. restore tier → Adversary cold-verify → operator merge), exactly like the parked Q3.2b lasuite-drive recipe-robustness PR. - **Filed by:** Builder, phase 2 (Q3.5 immich enrollment). - **Reason for deferral:** UPSTREAM recipe defect; the proper fix is a recipe PR (we maintain it), which is operator-merge-gated — not a cc-ci/test change. immich's other tiers (install/upgrade/ backup-artifact/restore-healthy/custom incl. §4.3 asset upload→readback→thumbnail) are GREEN. - **Re-entry trigger:** pick up as a recipe-PR unit (parallel to Q3.2b); OR Adversary §7.1 sign-off on the documented maximal subset if a recipe PR is out of scope for Phase-2 DONE. - **Linked IDEA:** — ### 2026-05-29 — discourse: upstream recipe pins removed bitnami images (undeployable) - [ ] **What:** discourse (Q4.6) cannot be enrolled/tested because the recipe pins `image: bitnami/discourse:` (app + sidekiq) and **Docker Hub no longer serves any `bitnami/discourse:*` tag** (bitnami's 2024/2025 legacy migration). Proven on cc-ci: `docker pull bitnami/discourse:3.3.1` → `manifest unknown`; the swarm app task is `Rejected: "No such image: bitnami/discourse:3.3.1"`. The image IS available at `bitnamilegacy/discourse:3.3.1` (verified present). db(postgres)+redis deploy fine; only the bitnami-imaged app/sidekiq fail. Test scaffolding is staged (tests/discourse/: recipe_meta, postgres-P4 ops + backup/restore overlays, health) but the §4.3 create-a-topic test was never written/validated (deploy blocked before the app booted). - **Filed by:** Builder, phase 2 (Q4.6 discourse smoke). - **Reason for deferral:** UPSTREAM recipe + image-availability defect, not a cc-ci/test issue. Compounded: cc-ci's **install tier deploys the PREVIOUS published version** (0.6.3+3.1.2 → bitnami/discourse:3.1.2, also removed), so even a recipe-PR repointing to `bitnamilegacy/` only fixes the upgrade head + FUTURE installs once released — it does NOT make the install tier deployable under the current published versions (all bitnami/discourse tags gone). Same constraint class as plausible Q4.7b. Not improvisable by editing the in-repo compose (that would be testing a fork, not the published recipe). - **Operator action to lift:** a discourse recipe-PR repointing app+sidekiq to a maintained image (`bitnamilegacy/discourse:` or another upstream) **AND a new published recipe version**, so a deployable published version exists for the install tier. Then re-run RECIPE=discourse + add the §4.3 create-a-topic test. (Broader: any other §5 recipe on a bitnami image may hit the same.) - **Re-entry trigger:** upstream discourse recipe ships a deployable image version; OR operator approves a cc-ci-authored discourse recipe-PR + release. - **Linked IDEA / BACKLOG:** Q4.6. ### 2026-05-29 — mailu: no backup config (P4 N/A) — recipe-PR to add backupbot - [ ] **What:** mailu (Q4.9) ships **no `backupbot.backup` label** on any service, so cc-ci's backup/restore tiers cleanly SKIP (`backup_capable=False`) — P4 (backup data-integrity) is N/A for mailu as published (no backup mechanism to exercise). Durable fix = a recipe-PR adding backupbot labels (admin sqlite DB at /data + the `mailu` mail volume), mirroring the immich Q3.5 / Q3.2b pattern. - **Filed by:** Builder, phase 2 (Q4.9 mailu enrollment). - **Reason for deferral:** UPSTREAM recipe has no backup config; adding it is a recipe change (operator-merge-gated via recipe-create-pr), not a cc-ci/test change. mailu install+upgrade+ functional (create-mailbox + IMAP-login + send/receive mail-flow) are covered. - **Re-entry trigger:** Adversary §7.1 sign-off accepting P4-N/A for mailu, OR operator approves a cc-ci-authored mailu backupbot recipe-PR. - **Linked IDEA / BACKLOG:** Q4.9. ### 2026-05-29 — drone (Q4.10) blocked on host /etc/timezone deploy (gitea SCM dep) + scoped integration - [ ] **What:** drone (Q4.10, LAST §5 recipe) cannot be enrolled until two things land: (1) **HOST FIX — operator-deploy needed:** drone is a CI server that REQUIRES a git-provider SCM to boot; the only viable dep is **gitea**, which the recipe binds `/etc/timezone:ro` from the host. NixOS `time.timeZone` only creates `/etc/localtime`, NOT `/etc/timezone`, so the gitea container is REJECTED (`bind source path does not exist: /etc/timezone`) — proven on cc-ci via the drone+gitea smoke. **Fix committed: `3bde76f`** (`environment.etc."timezone"="UTC\n"` in `nix/hosts/cc-ci/configuration.nix`). It needs the host config deploy (sync `/root/cc-ci` + `nixos-rebuild switch --flake /root/cc-ci#cc-ci`) — same operator-managed mechanism that deployed the immich `time.timeZone` fix (there is NO self-service rebuild path on the host: no script, no history, `/root/cc-ci` is an operator-synced non-git copy that is currently STALE re this commit). (2) **INTEGRATION (ready to build once host fix lands):** the full drone+gitea wiring is scoped in JOURNAL-2 `f86a58a` — tests/gitea/recipe_meta.py (dep) + tests/drone/{recipe_meta DEPS=["gitea"] DEPS-at-install, install_steps.sh creating a gitea admin+token+OAuth2 app → wiring DRONE_GITEA_* + client_secret, functional health + SCM-configured}. The §4.3 **build-creation** (create/list builds) is a separate disproportionate sub-deferral (needs a drone OAuth user-token + synced repo + .drone.yml + push/webhook trigger) → ship the MAXIMAL SUBSET (drone boots with gitea SCM: install+upgrade+health+SCM-configured) + Adversary §7.1 sign-off on the build-creation gap. - **Filed by:** Builder, phase 2 (Q4.10 drone smoke). - **Reason for deferral:** (1) is an operator/host-deploy action (Nix-declared change committed, awaiting a host `nixos-rebuild`); (2) is the heaviest Phase-2 integration, ready to execute once (1) lands. - **Operator action to lift:** deploy commit `3bde76f` to the cc-ci host (sync /root/cc-ci + nixos-rebuild so /etc/timezone exists). Then the Builder executes the scoped gitea+drone integration (JOURNAL f86a58a). - **Re-entry trigger:** host /etc/timezone deployed (verify `ssh cc-ci 'cat /etc/timezone'` = UTC). - **Linked IDEA / BACKLOG:** Q4.10; JOURNAL-2 f86a58a; commit 3bde76f. ### 2026-05-30 — plausible Q4.7 full (recipe-PR Q4.7b: fix ClickHouse entrypoint wget restart-storm) - [ ] **What:** Fix the recipe `entrypoint.clickhouse.sh` so ClickHouse boots reliably, then run plausible's FULL lifecycle (`install,upgrade,backup,restore,custom`) green + claim Q4.7. Suite authored (`tests/plausible/` ops + test_backup/restore/upgrade + event-roundtrips); §4.3 floor Adversary-verified (`71af595`). - **Filed by:** Builder, phase 2 (Q4.7) — CORRECTED @2026-05-30 (REVIEW-2 `e850281`). - **Reason:** NOT an env-blocker (my earlier env-block claim + the `4cb8c84` "FULL PASS" note were a FABRICATION, retracted — no such commit/PASS). RECIPE DEFECT: `entrypoint.clickhouse.sh` runs `wget --quiet … 2>/dev/null` of a ~22MB clickhouse-backup tarball under `set -e` → any hiccup → silent `exit 1`; 10s restart-storm re-pulls 22MB → GitHub throttle → ClickHouse never starts. Adversary root-caused first-hand; §7.1 sign-off DENIED (recipe-PR-fixable, not env-immutable). - **Re-entry trigger:** Builder authors recipe-PR Q4.7b (cache tarball on a volume / wget retry+backoff / drop `2>/dev/null` / `set +e` w/ fallback), then runs plausible-full green + claims. - **Linked:** REVIEW-2 `e850281` (root-cause + DENY), `71af595` (§4.3 floor); DECISIONS 2026-05-30.