# BACKLOG — phase `regall` ## Build backlog ### Batch 1 (in flight) - [ ] B1a: Trigger !testme on drone PR#1 (upgrade=p baseline, open PR) - [ ] B1b: Trigger !testme on gitea PR#1 (upgrade=p baseline, open PR) - [ ] B1c: Trigger !testme on matrix-synapse PR#4 (upgrade=p baseline, open PR) ### Batch 2 (queued) - [ ] B2a: Trigger !testme on mumble PR#1 - [ ] B2b: Trigger !testme on lasuite-meet PR#7 - [ ] B2c: Trigger !testme on n8n PR#6 ### Batch 3 (queued) - [ ] B3a: Trigger !testme on custom-html PR#5 - [ ] B3b: Trigger !testme on mattermost-lts PR#2 - [ ] B3c: Trigger !testme on mailu PR#4 ### Batch 4 (queued — recipes without open PRs need trivial PRs created) - [ ] B4a: ghost — create trivial PR + !testme - [ ] B4b: immich — create trivial PR + !testme - [ ] B4c: lasuite-docs — create trivial PR + !testme ### Batch 5 (queued) - [ ] B5a: lasuite-drive — create trivial PR + !testme - [ ] B5b: plausible — create trivial PR + !testme (has UPGRADE_BASE_VERSION override) - [ ] B5c: uptime-kuma — create trivial PR + !testme ### Batch 6 (queued) - [ ] B6a: custom-html-tiny — create trivial PR + !testme - [ ] B6b: bluesky-pds PR#3 (upgrade=skip, lower risk but still needs sweep) ### Post-sweep - [ ] B7: Build results table + classify any regressions - [ ] B8: Fix any prevb-caused regressions (if any) - [ ] B9: Re-verify fixes (if any) - [ ] B10: Claim M1 gate (all run + classified) - [ ] B11: Claim M2 gate (regressions fixed + verified) ## Adversary findings ### A-regall-2 [adversary] OPEN @2026-06-17T03:25Z — plausible backup_restore=fail; classify prevb regression or flake **Filed:** 2026-06-17T03:25Z **Severity:** MEDIUM — backup_restore failure drops plausible from baseline L5 to L2. Blocks M1 classification. **Run:** 750 (Drone 750, PR#4). Result: level=2, backup_restore=fail. **Baseline:** run 658, level=5, backup_restore=pass. **Failure:** `test_restore_returns_state` — `ERROR: relation "ci_marker" does not exist` after restore. - Backup test passed (only checks artifact file exists, 0.134s — does NOT verify ci_marker content) - Restore completes (test_restore_healthy passes), but ci_marker table absent from DB **Prevb-specific difference:** - Run 750 upgrade: `version=3.0.1+v2.0.0→3.0.1+v2.0.0` (NO-OP: UPGRADE_BASE_VERSION='3.0.1+v2.0.0' matches recipe.yml version) - Run 658 upgrade: `version=d77adba4698b` (git ref — genuine upgrade from published base to tested commit) - Hypothesis: prevb's new base-resolution path resolves UPGRADE_BASE_VERSION to a static version; if recipe.yml also pins that same version, the upgrade is a no-op, which may change the DB state sequence enough to break backup/restore - Same failure pattern in m2r-plausible and m2rr-plausible (prevb development runs) — both level=2, backup_restore=fail **Builder rerun:** Drone 754 — **ALSO FAILED** (same error, same level=2, backup_restore=fail). **Adversary verdict: GENUINE REGRESSION (2/2 runs failed) — NOT a flake.** Both runs 750 and 754: - `version=3.0.1+v2.0.0→3.0.1+v2.0.0` (no-op upgrade via UPGRADE_BASE_VERSION) - `ERROR: relation "ci_marker" does not exist` after restore - Backup test passes (artifact only, not content) - Restore test fails **Required:** Builder must diagnose the no-op upgrade path and either: (a) Fix the backup/restore to work correctly under same-version upgrades, OR (b) Update UPGRADE_BASE_VERSION to an older version so upgrade is genuine, OR (c) Document why plausible backup_restore is not feasible and mark as known-fail Builder-INBOX written @2026-06-17T03:30Z with full details. **Adversary closes after:** Builder fixes + re-run shows backup_restore=pass. --- ### A-regall-1 [adversary] CLOSED @2026-06-17T02:20Z — mailu baseline table corrected **CLOSED:** Builder corrected STATUS-regall.md in commit 7c6134a: mailu upgrade rung now shows "pass" not "skip (no deployable base)". ~~### A-regall-1 [adversary] OPEN — mailu baseline table has incorrect upgrade rung~~ **Filed:** 2026-06-17T02:10Z **Severity:** LOW (informational — does not block the sweep, but affects regression classification) **Discrepancy:** STATUS-regall.md baseline table shows mailu upgrade rung = "skip (no deployable base)". The actual baseline run 526 (Jun 12) shows `upgrade: "pass"` in both `results` and `rungs` sections. **Evidence (cold-verified from /var/lib/cc-ci-runs/526/results.json):** ``` "results": { ..., "upgrade": "pass", ... } "rungs": { ..., "upgrade": "pass", "backup_restore": "skip", ... } ``` The `skip` in run 526 applies to `backup_restore` (mailu is not backup-capable), NOT to upgrade. **Impact:** If post-prevb mailu runs show upgrade=skip or upgrade=fail, it would be incorrectly considered within-baseline (the table says "skip") rather than a regression from the true baseline (upgrade=pass). **Required correction:** STATUS-regall.md should read: `mailu | 5 | pass | 526` for the upgrade rung. **Adversary closes:** after Builder corrects the baseline table in STATUS-regall.md.