cc-ci/machine-docs/DEFERRED.md

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

• What: Port recipe-info/lasuite-docs/tests/oidc_login.py (authenticated OIDC flow against lasuite-docs's protected API) + recipe-info/lasuite-docs/tests/upload_conversion.py (.md/.docx uploads via authenticated /api/v1.0/documents/<id>/upload) + add test_create_doc.py (the §4.3 prescribed create-a-doc + read-back via authenticated /api/v1.0/documents/).
• Filed by: Builder, phase 2 (Q3.1 lasuite-docs PARITY pass)
• Reason for deferral: Requires lasuite-docs's OIDC env wired to the dep keycloak at install time — tests/lasuite-docs/install_steps.sh that reads $CCCI_DEPS_FILE for the dep keycloak domain, calls harness.sso.setup_keycloak_realm, inserts SECRET_OIDC_RPCS via abra, and writes the OIDC env vars (OIDC_REALM, OIDC_OP_*) to the parent's .env. The Q3.1 first pass shipped test_oidc_with_keycloak.py (exercises OIDC against the dep) + test_auth_required.py (proves the auth gate is wired) — these meet the ≥2 specific floor but do not exercise the authenticated lasuite-docs API.
• Re-entry trigger: Before any Q3 gate claim (Q3.1 must show §4.3 create-a-doc) — i.e. the next Phase-2 work cycle, not Phase-4. Adversary's Q3/Q4 checkpoint @ 2026-05-28 explicitly noted "will revisit when Q3.1 is formally claimed."
• Linked IDEA: —

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: When Q3.4 cryptpad's deferred oidc_login.py parity is lifted (cryptpad's upstream test uses authentik), OR when an additional Q4 recipe enrolls with DEPS = ["authentik"], OR Phase-2 DONE review (operator may insist on second-provider coverage proving the harness IS pluggable, not just claimed).
• Linked IDEA: —

---

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: —