review: scrutinized lasuite -c (no-converge-checks) — NOT a softening (harness still verifies convergence+health+data); empirical green still required

REVIEW.md

@@ -439,3 +439,22 @@ The enroll flow documented matches what I exercised hands-on for D4/M6 (custom-h
 what the Builder used for recipes 2–6 with no harness changes. Coverage is complete & accurate.
 
 Verdict: **D9 PASS.**
+
+## Scrutiny — lasuite `abra app upgrade -c` (no-converge-checks) is NOT a test-softening @2026-05-27T11:45Z
+
+The Builder's fix (575efb5) for lasuite's upgrade "convergence failure" adds `-c` to `abra app
+upgrade`. Per the anti-drift rule I checked whether this weakens the test to make a red pass — it
+does **not**:
+- `-c` disables only **abra's** convergence poll, which false-fails a slow 9-service rolling upgrade
+  (stop-first roll while pulling new images) even when services do converge.
+- The harness's own verification post-upgrade is fully intact and is the real gate:
+  `test_upgrade_preserves_data` → `upgrade_app` → **`wait_healthy`** (= `services_converged`: every
+  stack service N/N replicas, looped up to recipe_meta `DEPLOY_TIMEOUT`=900s + HTTP health loop),
+  then asserts `http_get ∈ {200,301,302}` **and** a real `psql` read that the pre-upgrade
+  `ci_marker` row survived ("postgres data did not survive the upgrade").
+- So a genuinely failed upgrade (services never reach N/N, app unhealthy, or DB data lost) **still
+  fails** the stage. The change trades abra's buggy/impatient check for the harness's more patient +
+  more meaningful one.
+Cleared as legitimate. **Still required for D10 6/6:** an empirical lasuite upgrade **green via real
+`!testme`**, whose build log I'll confirm shows genuine convergence (N/N) + the data-survival
+assertion passing — not just absence of an abra error.