cc-ci/REVIEW-dstamp.md

REVIEW-dstamp.md — Adversary verdicts for phase dstamp

Phase: investigate & solve the discourse abra-stamp drift (upgrade-HC1 stamps the prev-base tag commit instead of the PR-head version, harness-neutral, since ~06-10). SSOT: /srv/cc-ci/cc-ci-plan/plan-phase-dstamp-discourse-drift.md. Gates M1, M2.

Verdict log is append-only. review(...)-prefixed commits carry verdicts (load-bearing watchdog signal). Findings filed under ## Adversary findings in BACKLOG-dstamp.md.

---

Prep notes (NOT a verdict — no gate claimed yet) @2026-06-11T15:5x

Recon done cold before any Builder claim, to make M1/M2 verification fast and independent. Anti-anchoring: formed only from the plan (SSOT), the harness code, and direct host evidence — no dstamp JOURNAL exists yet; none read.

Stamp mechanism (from code): HC1's "stamp" = the coop-cloud.<stack>.chaos-version docker service label abra writes on a --chaos deploy = the deployed recipe git commit (runner/harness/lifecycle.py:468 deployed_identity, runner/harness/generic.py:146 assert_upgraded). Upgrade flow (generic.py:226 perform_upgrade): deploy prev-published base → recipe_checkout_ref(recipe, head_ref) (git checkout -f head) → chaos_redeploy (abra app deploy --chaos). HC1 asserts chaos_commit == head_ref (after stripping the +U untracked-overlay marker). PASS requires the chaos-version to equal the PR head.

Cold observable facts (from /var/lib/cc-ci-runs/m2p-discourse/abra/recipes/discourse snapshot + live ~/.abra/recipes/discourse on cc-ci, 2026-06-11):

• Recipe HEAD 7ae7b0f = "chore: upgrade to 0.9.0+3.5.0"; git describe --tags = 0.7.0+3.3.1-9-g7ae7b0f → HEAD is 9 commits past the newest annotated tag 0.7.0+3.3.1 (commit eb96de9). No 0.8.x/0.9.x tag exists.
• The drift symptom (per plan): chaos-version stamped eb96de94+U = the prev-base tag commit (= the upgrade base 0.7.0+3.3.1), NOT the PR-head 7ae7b0f.
• abra is nix-pinned: abra version 0.13.0-beta-06a57de, store path under /run/current-system → binary drift requires a flake.lock/nixos-generation bump between 06-05 and 06-10 (verify against generations, don't assume).

Open question I'll independently re-derive when M1 is claimed: why the --chaos redeploy after checkout-to-HEAD stamps the BASE commit (eb96de9), not HEAD (7ae7b0f). Candidates to test cold: (a) re-checkout to head silently reverted (abra fetch/reset during deploy); (b) abra chaos resolves the version from the app's recorded .env RECIPE/version (= the base) rather than the working-tree HEAD; (c) the "env drift" since 06-10 = recipe/ mirror git state moved (unreleased commits pushed past last tag) or a tag re-pointed.

Guardrail teeth I will enforce at M2: HC1 must still FAIL on a genuinely wrong stamp (synthesize a wrong-version deploy and show RED). Any "fix" that derives EXPECTED from "what makes the test pass" rather than abra's documented behavior = automatic FAIL.

Status: idle, awaiting Builder to seed STATUS-dstamp.md and claim M1. Watchdog will ping on the claim(...) commit.