status(redfix): evidence addendum for F-redfix-3 — durable content assertion for the discourse fix (sha pins rotted via later-phase force-push; content re-verified at ede6399); historical shas left unedited on purpose. DONE unchanged, no gate reopened

machine-docs/JOURNAL-redfix.md

@@ -688,3 +688,34 @@ reboot took toward foreign root files.
 
 No unblocked work exists: every DoD item is Adversary-verified green, nothing is claimed, nothing is blocked.
 Starting a work loop would be make-work. Terminal condition met → loop stopped.
+
+---
+
+## 2026-07-08 — F-redfix-3 (Adversary, CLOSED/non-blocking): acted anyway, on the record not the gate
+
+Watchdog pinged on `1271c24`. Verdict: **DONE stands, no VETO**; M1+M2 intact; F-redfix-3 filed and CLOSED by
+the Adversary with "no action required of the Builder now". No inbox file in either direction.
+
+I re-tested its load-bearing claim from a fresh clone rather than accepting a closed finding on trust — the
+whole point of the finding is that a stale pointer can make a live fix *look* withdrawn, and that failure mode
+applies to the Adversary's own note as readily as to mine:
+
+    git clone .../recipe-maintainers/discourse && git fetch origin 'refs/heads/*:...' 'refs/pull/*/head:...'
+    git cat-file -t 9ff5e19   -> fatal: Not a valid object name   (same for 53ba0910)
+    git show origin/discourse-official-image:compose.yml | grep image:  -> image: discourse/discourse:3.5.3
+    git show origin/discourse-official-image:compose.smtpauth.yml | grep -c sidekiq -> 0
+
+Both halves confirmed: the shas are genuinely unreachable from all 17 refs, and the fix content is intact at
+head `ede6399`. Cause is a later phase force-pushing the shared `discourse-official-image` branch. M2 was
+verified against the shas that existed on 06-18, so a subsequent rebase cannot retroactively unfix it.
+
+**Why I edited STATUS despite "no action required."** The rotted pins live in *my* file, and a content
+assertion (file -> expected line + the command to check it) is precisely STATUS material under
+WHAT+HOW+EXPECTED+WHERE. Leaving it would hand a future auditor a document whose own repro steps fail, which
+reads as "the discourse fix was withdrawn." So I appended an evidence addendum giving the durable content
+check, and **deliberately did not rewrite the historical sha lines** — those record what was verified on
+2026-06-18, and editing them to match today would misrepresent the M2 evidence rather than preserve it.
+
+This changes no claim and reopens no gate: `## DONE` stands, M1+M2 PASS unchanged, no VETO. The general lesson
+(shared recipe branches get rewritten; pin content, or push a tag) is the Adversary's, and it is a good one.
+Terminal condition still met. Loop stopped.

machine-docs/STATUS-redfix.md

@@ -26,6 +26,29 @@ M1 read-only crash gone; bluesky-pds recipe PR #4 @4987ba9 (caddy `${STACK_NAME}
 200 (was 000). gitea/bluesky end-to-end canonical advance is operator-merge-gated (fix proven by
 chaos-deploy; published tags don't carry it pre-merge) — consistent with "nothing merged", not a shrug.
 
+### Evidence addendum 2026-07-08 (re: F-redfix-3) — discourse sha pins have rotted; verify by CONTENT
+
+The discourse shas cited below (`9ff5e19`, `53ba0910`) **no longer resolve on the mirror**. A *later* phase
+force-pushed and extended the shared branch `discourse-official-image` (now `ede6399` = `refs/pull/5/head`;
+redfix's PR is no longer `#4`). This is branch drift by later work, **not** a retraction of the redfix fix,
+and it does not disturb the M2 PASS — which was given against the shas that existed on 2026-06-18. The other
+three recipe pins and the harness pin are exact and still resolve: mattermost-lts `ci/pg-restore`@`4ca7f418`,
+gitea `ci/app-ini-writable`@`a0f2db88`, bluesky-pds `ci/warm-routing-alias`@`4987ba91`, cc-ci
+`redfix-m2-harness`@`07fc6d4a`.
+
+Historical sha lines below are left **unedited on purpose** — they record what was verified when. Use this
+durable **content assertion** instead of the shas to re-verify discourse at any future head:
+
+    git clone https://git.autonomic.zone/recipe-maintainers/discourse && cd discourse
+    git show origin/discourse-official-image:compose.yml | grep -m1 'image:.*discourse'
+    git show origin/discourse-official-image:compose.smtpauth.yml | grep -c sidekiq
+
+EXPECTED: `image: discourse/discourse:3.5.3` (the official-image migration = M2's claim) and `0` (the
+F-redfix-1 orphaned-sidekiq removal). Both re-confirmed by the Builder at `ede6399` on 2026-07-08, and by the
+Adversary at `ede6399` and `refs/pull/4/head`@`0c4539b7`. (Caveat when reproducing absence of a sha: a
+`--filter=blob:none` clone and `git fetch origin <sha>` both yield false "absent" signals — test reachability
+from all `refs/heads/*` + `refs/pull/*/head` instead.)
+
 ---
 
 ## Phase: M1 — investigate + isolate + classify (IN PROGRESS)