220 lines
16 KiB
Markdown
220 lines
16 KiB
Markdown
# 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 — <slug>
|
|
- [ ] **What:** <concrete description, link to file/test/spec>
|
|
- **Filed by:** <Builder|Adversary>, phase <id>
|
|
- **Reason for deferral:** <technical, scope, "more than needed for default CI", dependency>
|
|
- **Re-entry trigger:** <optional — what operator input / mechanism would bring it back>
|
|
- **Linked IDEA / BACKLOG:** <optional cross-ref>
|
|
```
|
|
|
|
---
|
|
|
|
## 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-tests` 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-tests` 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-tests` opt-in flag (linked IDEA).
|
|
- **Linked IDEA:** `cc-ci-plan/IDEAS.md` — *Optional `--extra-tests` 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-tests` 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-tests` 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/<server>/<media_id>`.
|
|
- **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/<id>/upload`) remains as a Phase-2 follow-up below.
|
|
|
|
### 2026-05-28 — cryptpad create-a-pad + content round-trip Playwright test
|
|
- [ ] **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-tests` flag lands so this can live in `extra/`.
|
|
- **Re-entry trigger:** the `--extra-tests` 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-tests` flag for heavy/operational tests*.
|
|
|
|
### 2026-05-28 — ghost create-a-post round-trip (§4.3 prescribed)
|
|
- [ ] **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/<id>/` (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-tests` flag rollout OR a Phase-2
|
|
follow-up specifically for Q4 deeper tests.
|
|
- **Re-entry trigger:** the `--extra-tests` 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-tests` 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_<provider>_*` 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.
|
|
- [ ] **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 — <slug> 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/<id>/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.
|