decisions/deferred(2): lasuite-drive upgrade tier = disk env-blocker (28GB host, dual multi-GB office image crossover); maximal subset in flight; operator disk-resize escalation; adversary heads-up

machine-docs/DECISIONS.md

@@ -693,3 +693,16 @@ green run SEEDS the canonical. `--quick` never promotes (proven W2). Only cold a
 Promote gate predicate (unit-tested): `is_enrolled(recipe) and overall==0 and not quick and not ref`.
 (`not ref` = a catalogue-latest run, i.e. the nightly sweep or a manual `RECIPE=<r>` run — a PR
 `!testme` carries REF=PR-head and must NOT advance the canonical to a PR's code.)
+
+## Phase 2 — heavy-recipe upgrade tier disk constraint (28GB host) — SETTLED finding @2026-05-29
+The upgrade tier (HC1: prev published → PR-head via in-place `abra app deploy --chaos`) cannot
+complete for recipes whose successive releases bump multi-GB image tags, because the rolling update
+must hold BOTH versions on disk transiently. Proven on lasuite-drive: onlyoffice 9.2 → 9.3.1.2
+(3.94GB each) + collabora two versions → ~10GB office images at once vs ~14GB docker headroom on the
+28GB host → 99% → deploy fail. **No harness fix is possible** (the prev images are running, so they
+are neither dangling-prunable nor `rmi`-able when the new must be pulled). install/backup/restore/
+custom (single version) fit and pass. Resolution = grow the host disk (Class A1 operator input,
+DEFERRED.md 2026-05-29). Until then, heavy recipes are verified via their maximal testable subset
+(install+backup+restore+custom) with the upgrade tier flagged as a genuine env-level (disk) blocker
+per plan §7.1 (Adversary sign-off required). The cleanup runbook for an over-full host: `pkill -f
+run_recipe_ci.py`; `docker stack rm <leftover>`; remove its volumes+secrets; `docker image prune -f`.