From 005e80d38a7082b549a459d540d76e2cf936e4fa Mon Sep 17 00:00:00 2001 From: Keith Jackson Date: Mon, 5 Oct 2026 22:38:55 -0500 Subject: [PATCH] docs(pm-agent): record the PR's own CI result, read from the log not the status tick MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit The PR gate ran and BLOCKED on approval-policy alone — the sensitive-path rule, with no non-author review — while every technical stage passed, gitea-settings included (the one stage a workstation cannot run). That is the gate working, and it is the one thing an agent must not clear for itself. Also recorded: the commit-status API reported 'pending — Waiting to run' for a run that had already completed, so the log is the source of truth here. §2b again. Co-Authored-By: Claude Opus 5 (1M context) --- decisions/2026-10-05-pm-agent-issue-to-pr.md | 21 ++++++++++++++++++++ 1 file changed, 21 insertions(+) diff --git a/decisions/2026-10-05-pm-agent-issue-to-pr.md b/decisions/2026-10-05-pm-agent-issue-to-pr.md index 28dcec5..9146991 100644 --- a/decisions/2026-10-05-pm-agent-issue-to-pr.md +++ b/decisions/2026-10-05-pm-agent-issue-to-pr.md @@ -80,6 +80,27 @@ All offline, in the pinned toolbox (`./infra/devcontainer/dev.sh run`), never on The gate names that single stage as the reason for rc 3 ("Stages that did not run: gitea-settings"), so nothing in the change is unexamined — but rc 3 is not a pass and this entry does not call it one. +- **The PR's OWN CI run, read from its log rather than from the status tick** (PR #57, head + `8b5e950b`, `.gitea/workflows/gate.yml` with `GATE_STRICT_SKIPS=true` and + `REQUIRE_GITEA_SETTINGS=true`): decisions-log **pass**, lint **pass**, l0 **pass**, + render-golden **pass**, l1 **pass**, **gitea-settings pass** — including + `block_admin_merge_override = true`, which is the one stage my workstation cannot run at + all — spec-immutability **SKIPPED** (the spec repo is absent in CI, as its own step + tolerates), conformance **SKIPPED**, and **approval-policy FAIL → MERGE GATE: BLOCKED**. + The failure is *only* the sensitive-path rule: "This PR changes the pipeline or the + security posture it rests on, and has NO approving review from anyone other than its author + ('gitea-admin')", over eleven paths — `clusters/{base,dev,prod}/*`, + `platform-config/kustomization.yaml`, `platform/kyverno/{admission,tests}/pm-agent*`, + `platform/pm-agent/rbac.yaml` and `platform/pm-agent/pm-agent-credentials.sops.yaml`. + **That is the gate working, not a defect in the change**, and it is the one thing an agent + must not clear for itself: the operator posts `/approve-override ` as a PR *review*, + or a non-author reviews it. CI is therefore red and will stay red until a human acts. +- **The commit-status API did not reflect any of that.** While the run completed and its log + carried the verdict above, `GET /commits/{sha}/status` still reported + `gate / gate (pull_request): pending — Waiting to run`. Worth knowing before anyone builds + automation on that endpoint: on this Gitea the status tick lagged the run indefinitely, so + the log is the source of truth. A fresh instance of §2b — "a green tick is not proof + anything ran"; here the tick was not even wrong, it was absent. - **The gate caught two real defects in this change before I did**, which is worth recording because both were in the parts I was most confident about: 1. `flux-postbuild-substitution` → 1 UNDEFINED + 1 FATAL-PARSE. My ConfigMap's *comment*