docs(decisions-log): PR #18 has no approval-policy check -- measured, not assumed

My brief said this PR's CI would fail on an `approval-policy` stage because
`conformance/**` is a security-relevant path requiring human approval, and to
report that as expected. I wrote that down before checking it. It is not true:

  * `grep -rn 'approval-policy|approval_policy' .gitea/ ci/` returns nothing.
    gate.yml has jobs `gate` and `conformance`; merge-gate.yaml has
    spec-immutability, lint, l0, render-golden, l1, conformance, merge-gate.
  * GET /branch_protections -> protected_file_patterns: '' . No path rule of any
    kind, and no CODEOWNERS file in the repo.
  * status_check_contexts: ['gate / gate (pull_request)'] -- one context, not an
    approval stage.

What blocks this PR is what blocked #12-#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 is
not pedantry -- "expect a red X" and "expect a green run an agent still cannot
merge" send a reviewer to different places.

The correction is left IN the log rather than quietly deleted. This is the fourth
consecutive entry where a confidently-stated control turned out not to exist, and
the pattern is more useful than a tidy paragraph.

Also records what the CI run actually did, read out of the job log rather than off
the tick (a skipped Gitea job reports success): lint, l0, render-golden, l1 and
gitea-settings all pass; spec-immutability and conformance SKIPPED; MERGE GATE
UNDETERMINED. So `gate / gate` = success means rc 3 tolerated, not rc 0. Note that
gitea-settings RAN AND PASSED with REQUIRE_GITEA_SETTINGS=true -- the detector
armed in #15 works, and CI is more complete than the local toolbox run, where that
stage can only skip.

Co-Authored-By: Claude Opus 5 (1M context) <[email protected]>

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.**