From f81967228dfd2adb3f05fa6ea71aa7648f6529f9 Mon Sep 17 00:00:00 2001 From: Keith Jackson Date: Tue, 29 Sep 2026 19:21:49 -0500 Subject: [PATCH] docs(decisions-log): the `approval-policy` check this PR was expected to fail does not exist MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit I was briefed to expect CI to FAIL on an `approval-policy` check, because `conformance/**` is security-relevant. Measured instead: grep -rn approval .gitea/workflows/ -> no match branches/main status_check_contexts -> ['gate / gate (pull_request)'] commits//statuses gate / gate -> success, "Successful in 1m36s" gate / conformance -> pending, "Blocked by required conditions" The only required context is `gate / gate`, and it is green — and it genuinely ran (1m36s), so this is not the skipped-Gitea-job-reports-success trap. There is no path-based approval policy in CI anywhere in this repo. What blocks the merge is `required_approvals: 1` and the fact that `gitea-admin` authors every agent PR and cannot self-approve — the control that returned HTTP 405 on PR #12. Recording it because the PR body and the log entry both asserted the wrong blocker, and this repo has been burned repeatedly by documentation that described a control nobody measured. A change to the admission boundary under `conformance/**` is gated by a generic human approval, not by anything that knows the path is security-relevant; if that is the intent, it is not implemented. Co-Authored-By: Claude Opus 5 (1M context) --- DECISIONS-LOG.md | 34 ++++++++++++++++++++++++++++++---- 1 file changed, 30 insertions(+), 4 deletions(-) diff --git a/DECISIONS-LOG.md b/DECISIONS-LOG.md index fe9a753..b09aa44 100644 --- a/DECISIONS-LOG.md +++ b/DECISIONS-LOG.md @@ -5233,8 +5233,34 @@ Nothing FAILED. rc 3 is the expected local outcome and `gate.yml` tolerates it. - `ci/conformance.sh` still runs the suite **locally** and is untouched (plan §3 item 4). This branch changes nothing about what CI does today. -### PR +### PR #20 — and a correction to what was expected to block it -Opened against `main`, **not merged**. Its CI is **expected to FAIL on `approval-policy`**: -`conformance/**` is security-relevant and needs a human approval. That is the control -working; it was not worked around. +Opened against `main`, **not merged**. I was briefed to expect CI to FAIL on an +`approval-policy` check because `conformance/**` is security-relevant. **That check does not +exist.** Measured rather than assumed: + + grep -rn approval .gitea/workflows/ -> no match + GET /repos/.../branches/main + protected True + user_can_push False + enable_status_check True + status_check_contexts ['gate / gate (pull_request)'] + required_approvals 1 + GET /repos/.../commits//statuses + success gate / gate (pull_request) Successful in 1m36s + pending gate / conformance (pull_request) Blocked by required conditions + +So: the **only** required context is `gate / gate`, and it is GREEN (1m36s — it ran; this is +not the skipped-job-reports-success trap). There is **no path-based approval policy in CI at +all**. What actually stops this merging is `required_approvals: 1` plus the fact that +`gitea-admin` authors every agent PR and cannot self-approve — the same control that returned +HTTP 405 on PR #12. `gate / conformance` is "Blocked by required conditions", i.e. the +`CLUSTER_AVAILABLE` guard, unchanged. + +**Consequence worth acting on:** a change under `conformance/**` — including a change to the +admission boundary itself — is gated by a *generic* human approval, not by anything that knows +the path is security-relevant. If the intent is "security-relevant paths get a stricter +review", that policy is not implemented anywhere in this repo. `CODEOWNERS`-style path review +or a `paths:`-scoped required check would be the mechanism; neither exists today. + +The PR was **not merged** and nothing was worked around.