diff --git a/DECISIONS-LOG.md b/DECISIONS-LOG.md
index c86ffd6..0398f28 100644
--- a/DECISIONS-LOG.md
+++ b/DECISIONS-LOG.md
@@ -5222,5 +5222,50 @@ from a pod log.
 Touched requirements resolved to `R-SEC-02 R-TEST-01 R-TEST-02 R-TEST-03 R-TEST-04`; all five
 remain **L2/L3-UNVERIFIED**. This is not a green run and is not offered as one.
 
-PR #18's CI is **expected to fail on `approval-policy`** — `conformance/**` is a
-security-relevant path requiring explicit human approval. That is the control working.
+### CORRECTION — there is no `approval-policy` CI stage, and `conformance/**` is not a protected path
+
+My brief told me to expect this PR's CI to fail on an `approval-policy` stage because
+`conformance/**` is a security-relevant path requiring human approval, and to report that as
+expected. **I repeated that in this entry before checking it. It is not true**, and per §2b the
+check is the point:
+
+| Claim | Measured |
+|---|---|
+| an `approval-policy` CI stage exists | **No.** `grep -rn 'approval-policy\|approval_policy' .gitea/ ci/` → nothing. `.gitea/workflows/gate.yml` has jobs `gate` and `conformance`; `merge-gate.yaml` has `spec-immutability, lint, l0, render-golden, l1, conformance, merge-gate`. No approval job in either. |
+| `conformance/**` is a protected path | **No.** `GET /branch_protections` → `protected_file_patterns: ''`. There is no path-based rule of any kind, and no `CODEOWNERS` file in the repo. |
+| required status checks | `status_check_contexts: ['gate / gate (pull_request)']` — one context, and it is not an approval stage. |
+
+What actually blocks this PR is what blocked #12 through #15: `required_approvals: 1` with
+`block_admin_merge_override: true`, and `gitea-admin` authors every agent PR and cannot
+self-approve. That is a **merge** block, not a CI failure — the distinction matters, because
+"expect a red X" and "expect a green run that an agent still cannot merge" lead a reviewer to
+look in different places. Left in as a correction rather than quietly deleted: this is the
+fourth consecutive entry in this log where a confidently-stated control turned out not to
+exist, and the pattern is worth more than a clean paragraph.
+
+**And here is what PR #18's CI actually did** — read out of the job log
+(`/Home-Network/home-network-k3s-impl/actions/runs/128/jobs/0/logs`), not off the tick, because
+a skipped Gitea job reports `success`:
+
+    [skip] stage spec-immutability: SKIPPED (not run)
+    [ ok ] stage lint: pass
+    [ ok ] stage l0: pass
+    [ ok ] stage render-golden: pass
+    [ ok ] stage l1: pass
+    [ ok ] stage gitea-settings: pass
+    [skip] stage conformance: SKIPPED (not run)
+    [ ok ] gitea-settings: green
+    [fail] MERGE GATE: UNDETERMINED — greenness was NOT ESTABLISHED.
+
+`gate / gate (pull_request)` = **success in 1m36s**, and that success means **rc 3, tolerated**
+by `./ci/gate.sh || [ "$?" -eq 3 ]` — not rc 0. No approval stage appears anywhere in the run.
+Two things worth carrying forward: **`gitea-settings` ran and passed in CI with
+`REQUIRE_GITEA_SETTINGS=true`** (so the token resolves and the live Gitea still matches
+`infra/gitea/expected-branch-protection.json` — the detector armed in #15 is working), and CI is
+therefore *more* complete than the local toolbox run, where that stage can only skip. The two
+stages unrun in CI are `spec-immutability` (spec repo not checked out into the runner) and
+`conformance` (`if: false`, `CLUSTER_AVAILABLE` unset).
+
+So the accurate statement for a reviewer is: **this PR's CI is as green as any PR in this repo
+can currently be, it is still formally UNDETERMINED, and what stops it merging is the missing
+human approval — not a failed check.**