diff --git a/machine-docs/REVIEW-2.md b/machine-docs/REVIEW-2.md index ec1f8d4..86610f9 100644 --- a/machine-docs/REVIEW-2.md +++ b/machine-docs/REVIEW-2.md @@ -2073,3 +2073,33 @@ NOT a veto, NOT a verdict — recorded so the §7.1 ruling is rigorous when the (Harness caveat: tool-output garbled/duplicated lines this session; every VERIFIED fact above was re-confirmed and is consistent across duplicated outputs; the one truncated fact is explicitly marked OPEN.) + +## discourse Q4.6 §7.1 — DECISIVE FACT RESOLVED @2026-05-30T13:10:11Z (closes the OPEN item above; leaning DENY; still NOT a verdict — gate unclaimed) +Verified the published-tag list + per-tag image pins first-hand on the host (`~/.abra/recipes/discourse`): +- Published tags (newest last): `0.6.3+3.1.2` (app image `bitnami/discourse:3.1.2`→404), + `0.7.0+3.3.1` (app image `bitnami/discourse:3.3.1`→404). 0.7.0+3.3.1 is the NEWEST published. +- PR head `ci/bitnamilegacy-repin` (7b7ddd70) = `0.8.0+3.3.1`, app image `bitnamilegacy/discourse:3.3.1` (200). +- So `previous_version()=recipe_versions()[-2]` = **0.6.3+3.1.2** (image 3.1.2) ≠ head image 3.3.1; + and `[-1]` = **0.7.0+3.3.1** (image 3.3.1) == head's image and IS the PR's direct predecessor. + +**Resolution of the crux:** the upgrade tier is **NOT fundamentally untestable**. An HONEST crossover is +achievable: base = **0.7.0+3.3.1** (the PR's actual predecessor) deployed with a uniform overlay +`services.app.image: bitnamilegacy/discourse:3.3.1` (re-pins the 404 → the served legacy image, leaving +the 0.7.0 compose/env otherwise intact) → chaos-redeploy to head `0.8.0+3.3.1`. That is a REAL release +crossover (version label 0.7.0→0.8.0, chaos-stamped head commit) on the identical servable 3.3.1 image — +which is exactly what a namespace-re-pin PR legitimately exercises (the app image is unchanged BY DESIGN; +HC1 tests the version/redeploy transition, not an image bump). + +**The only real obstacle** is harness base-selection: `previous_version()` returns `[-2]` (0.6.3+3.1.2, +image 3.1.2), not the PR's true predecessor `[-1]` (0.7.0+3.3.1). With `[-2]` a single uniform image +overlay CAN'T honestly bridge 3.1.2→3.3.1 (it would force one image on both = a Frankenstein base or a +hollow head). But targeting `[-1]` as the base — correct whenever a PR introduces a version ABOVE the +newest published tag — makes a uniform overlay honest. That is a **modest base-selection fix** (a few +lines, the kind of "small shared harness addition" plan §0/§2 explicitly allows), **not** an +environment-level blocker. §7.1 forbids deferring what's testable-with-effort. + +**Leaning: §7.1 sign-off for the upgrade-tier deferral would be DENIED** as currently framed ("no +servable prev image" is false — bitnamilegacy:3.3.1 is served, and the 0.7.0→0.8.0 crossover is honest +and achievable). NOT a final verdict: discourse Q4.6 is unclaimed. If the Builder claims the deferral, the +bar is: show the 0.7.0→0.8.0 honest crossover is genuinely unachievable (not just `[-2]`-inconvenient), or +implement it green. I'll re-run cold either way before ruling.