fix(ci): let an administrator merge their own green PR

`required_approvals: 1` on `main` was a lock-out, not a protection. Gitea refuses to let a PR's author approve their own PR, and `jakman85` is the only collaborator — so no account in existence could approve a PR the operator opened, including the PR that would fix that. Measured 2026-10-01 on PR #35: gate green in 1m41s, reviews `[]`, `required_approvals: 1`, unmergeable. It was never the documented design either: `ci/approval-policy.sh`'s header and `ci/gate.sh:194` both already describe the model as "required_approvals drops to 0 and the GATE decides", and `require-gate.sh`'s own closing note named this failure and prescribed this remedy. 2026-09-30's entry flagged the 1-vs-0 disagreement as unresolved; this settles it at 0. Layer 1 — branch protection. required_approvals 1 -> 0 in the declaration, plus infra/gitea/allow-admin-self-merge.sh to apply it live (target read FROM the declaration, so the script cannot drift from what the gate checks). require-gate.sh moves to 0 too; left at 1 it would re-impose the lock-out on its next run. The narrow choice is deliberate: the other way to unblock an owner is block_admin_merge_override: false, which would re-open what block-admin-override.sh was written to close (PRs #5-#9, zero approvals). This drops the approval COUNT only — block_admin_merge_override and enable_status_check stay true and are asserted after the PATCH, so a red gate stays unmergeable by everyone, administrators included. Layer 2 — ci/approval-policy.sh. Sensitive paths still need a non-author approval the sole admin cannot get, so an administrator may waive it with an `/approve-override <reason>` comment: directive must start a line, reason mandatory, permission re-checked LIVE, invalidated by a new commit, and the overrider + reason printed in the gate log and job summary. Candidate selection is the pure, offline ci/approval-override.py (23 unit assertions, all passing); authorisation stays in the fail-closed stage. Every new failure mode blocks. The cost, stated not buried: for an administrator, "a change to the gate cannot be gated by the gate" is now advisory rather than structural. Unavoidable with one human; what is bought back is an attributed, commit-scoped record instead of a silent bypass. And the uncomfortable part, accepted as an operator decision: authorisation is by live permission alone, and the AGENT account `gitea-admin` also holds `owner` — so an agent can clear its own PR this way. Documented in approval-policy.json, the stage header, and CLAUDE.md (which tells agents not to). Narrowing needs no code change: add `override_admins` and the stage already requires membership. Adjacent fix, in scope because `make -C ci test` is the only runner for the suite added here: ci/tests/gate-decision.test.sh hand-maintained a stub list that "must name EVERY stage gate.sh runs" and omitted `approval-policy` (added to gate.sh by PR #17), so run_stage hit exit 127 and 15 of 50 assertions failed. Verified pre-existing on pristine origin/main @ 0c7e8dd. The list is now derived from gate.sh's own run_stage lines, so the omission cannot recur; the suite goes 15-failed -> 50 passing and `make -C ci test` goes FAILED -> all suites passed. Toolbox gate: rc 3 UNDETERMINED — every stage green except `gitea-settings` (no SETTINGS_API_TOKEN locally) and `conformance` (no cluster). NOT a green run. The live rule is UNCHANGED and still reads 1 — mutating it is an operator action. Until allow-admin-self-merge.sh is run, ci/gitea-settings.sh will correctly report DRIFT and this PR will be red. Co-Authored-By: Claude Opus 5 (1M context) <[email protected]>
2026-10-02 00:02:20 -05:00
30 changed files with 340 additions and 2695 deletions
@@ -40,21 +40,13 @@ missing credential is a lock-out, here a skip would be a bypass.
 **The administrator override (2026-10-01).** The rule above was unsatisfiable for the one human
 who runs this repo: Gitea refuses to let an author approve their own PR, and `jakman85` is the
 only collaborator — so a sensitive-path PR the operator opened could never be merged, *including
-the PR that would fix that.* An administrator may therefore waive the review by posting this on
+the PR that would fix that.* An administrator may therefore waive the review by commenting on
 the PR:

    /approve-override <reason>

-**Post it as a PR *review* of type "Comment", not in the plain comment box.** CI's
-`SETTINGS_API_TOKEN` is minted `[read:repository, read:admin]`, and `/issues/{n}/comments` sits
-behind Gitea's *issue* scope — so an override typed into the comment box is **invisible to CI**,
-and the stage reports it as a missing approval rather than as a permission problem (measured on
-PR #38, 2026-10-02). `/pulls/{n}/reviews` is readable, so a review body works today. Both sources
-are accepted and the gate names which it used; the comment box starts working once
-`infra/gitea/set-ci-token.sh` is re-run to pick up `read:issue`.
-
-The directive must **start a line**, the **reason is mandatory**, the poster's `admin`/`owner`
-permission is re-checked **live** when the gate runs, and it must be **newer than the
+The directive must **start a line**, the **reason is mandatory**, the commenter's `admin`/`owner`
+permission is re-checked **live** when the gate runs, and the comment must be **newer than the
 head commit** — push again and you must override again. The overrider, the timestamp and the
 reason are printed in the gate log and the job summary. For an administrator, "a change to the
 gate cannot be gated by the gate" is therefore **advisory, not structural**; what is kept is an
@@ -137,15 +137,14 @@ spec:
            secretKeyRef:
              name: plex-claim
              key: PLEX_CLAIM
-        resources:
-          limits:
-            gpu.intel.com/i915: 1
        volumeMounts:
        - name: config
          mountPath: /config
        - name: media
          mountPath: /media
          readOnly: true
+        - name: dri
+          mountPath: /dev/dri
      volumes:
      - name: config
        persistentVolumeClaim:
@@ -153,6 +152,10 @@ spec:
      - name: media
        persistentVolumeClaim:
          claimName: plex-media
+      - name: dri
+        hostPath:
+          path: /dev/dri
+          type: DirectoryOrCreate
 ---
 # Service
 apiVersion: v1
@@ -170,28 +173,6 @@ spec:
    port: 32400
    targetPort: 32400
 ---
-# CiliumNetworkPolicy reciprocal ingress allow (R-NET-02): plex-allow-radarr-32400
-apiVersion: cilium.io/v2
-kind: CiliumNetworkPolicy
-metadata:
-  name: plex-allow-radarr-32400
-  namespace: plex
-  labels:
-    app.kubernetes.io/name: plex
-spec:
-  endpointSelector:
-    matchLabels:
-      app.kubernetes.io/name: plex
-  ingress:
-  - fromEndpoints:
-    - matchLabels:
-        app.kubernetes.io/name: radarr
-        k8s:io.kubernetes.pod.namespace: radarr
-    toPorts:
-    - ports:
-      - port: '32400'
-        protocol: TCP
---
 # CiliumNetworkPolicy reciprocal ingress allow (R-NET-02): plex-allow-seerr-32400
 apiVersion: cilium.io/v2
 kind: CiliumNetworkPolicy
@@ -214,28 +195,6 @@ spec:
      - port: '32400'
        protocol: TCP
 ---
-# CiliumNetworkPolicy reciprocal ingress allow (R-NET-02): plex-allow-sonarr-32400
-apiVersion: cilium.io/v2
-kind: CiliumNetworkPolicy
-metadata:
-  name: plex-allow-sonarr-32400
-  namespace: plex
-  labels:
-    app.kubernetes.io/name: plex
-spec:
-  endpointSelector:
-    matchLabels:
-      app.kubernetes.io/name: plex
-  ingress:
-  - fromEndpoints:
-    - matchLabels:
-        app.kubernetes.io/name: sonarr
-        k8s:io.kubernetes.pod.namespace: sonarr
-    toPorts:
-    - ports:
-      - port: '32400'
-        protocol: TCP
---
 # CiliumNetworkPolicy gateway-ingress allow (R-NET-01/02): plex-allow-gateway-ingress
 apiVersion: cilium.io/v2
 kind: CiliumNetworkPolicy
@@ -283,28 +283,6 @@ spec:
      - port: '9117'
        protocol: TCP
 ---
-# CiliumNetworkPolicy egress allow (R-NET-02): radarr-allow-plex-32400
-apiVersion: cilium.io/v2
-kind: CiliumNetworkPolicy
-metadata:
-  name: radarr-allow-plex-32400
-  namespace: radarr
-  labels:
-    app.kubernetes.io/name: radarr
-spec:
-  endpointSelector:
-    matchLabels:
-      app.kubernetes.io/name: radarr
-  egress:
-  - toEndpoints:
-    - matchLabels:
-        app.kubernetes.io/name: plex
-        k8s:io.kubernetes.pod.namespace: plex
-    toPorts:
-    - ports:
-      - port: '32400'
-        protocol: TCP
---
 # CiliumNetworkPolicy reciprocal ingress allow (R-NET-02): radarr-allow-seerr-7878
 apiVersion: cilium.io/v2
 kind: CiliumNetworkPolicy
@@ -281,28 +281,6 @@ spec:
      - port: '9117'
        protocol: TCP
 ---
-# CiliumNetworkPolicy egress allow (R-NET-02): sonarr-allow-plex-32400
-apiVersion: cilium.io/v2
-kind: CiliumNetworkPolicy
-metadata:
-  name: sonarr-allow-plex-32400
-  namespace: sonarr
-  labels:
-    app.kubernetes.io/name: sonarr
-spec:
-  endpointSelector:
-    matchLabels:
-      app.kubernetes.io/name: sonarr
-  egress:
-  - toEndpoints:
-    - matchLabels:
-        app.kubernetes.io/name: plex
-        k8s:io.kubernetes.pod.namespace: plex
-    toPorts:
-    - ports:
-      - port: '32400'
-        protocol: TCP
---
 # CiliumNetworkPolicy reciprocal ingress allow (R-NET-02): sonarr-allow-seerr-8989
 apiVersion: cilium.io/v2
 kind: CiliumNetworkPolicy
@@ -81,49 +81,46 @@ env:
  # clients, so per "prefer safety over completeness" it is left unset. FOLLOW-UP: once remote
  # reachability through the Gateway is confirmed, set ADVERTISE_IP: "https://plex.home.keithjackson.dev:443".
 # HARDWARE TRANSCODING — the host iGPU's render device (schema 1.8.0 `hardware`; R-PLAT-02).
-# INTENT ONLY, AND THE MECHANISM DELIBERATELY DOES NOT LIVE HERE. This says "this workload needs an
-# Intel Quick Sync render device"; it does NOT name a device path and it does NOT name a resource.
-# How the platform hands the device over is `catalog/render.py`'s business and is documented in
-# `schemas/renderer-contract.md` `### hardware` — read that for the mechanism, never this comment.
-# The payoff is proven, not theoretical: on 2026-10-01 the mechanism was swapped outright (hostPath
-# -> Intel GPU device plugin extended resource) and THIS BLOCK DID NOT MOVE — a `render.py` change
-# plus a re-render, zero catalog edits. Do not "simplify" it into a raw `/dev/...` path; that is the
-# whole point of the enum.
+# INTENT ONLY. This says "this workload needs an Intel Quick Sync render device"; it does NOT name a
+# device path. The renderer currently satisfies it with exactly two things — a `/dev/dri` hostPath
+# volume (`type: DirectoryOrCreate`) and a read-write `/dev/dri` volumeMount on the app container —
+# and nothing else: no nodeSelector, no privileged, no resources (schemas/renderer-contract.md
+# `### hardware`). If that mechanism is later replaced by the Intel GPU device plugin
+# (`gpu.intel.com/i915`), it is a `catalog/render.py` change and THIS BLOCK DOES NOT MOVE. Do not
+# "simplify" it into a raw `/dev/...` path; that is the whole point of the enum.
 #
 # THE DEVICE IS PRESENT ON EVERY PROD NODE, so nothing had to be installed and Plex can land
 # anywhere. Measured on all three nodes 2026-09-30: `/dev/dri/renderD128` present, `root:render`,
 # GID 992, mode 0660, driver `i915` bound (NOT `xe`), UHD Graphics 630 on an i7-9700T, media engines
-# `vcs0`/`vecs0` live, iGPU enabled in BIOS on each. Measured again 2026-10-01, one layer up: all
-# three nodes advertise `gpu.intel.com/i915: 1` in `.status.allocatable`. This field renders no
-# nodeSelector; placement is a separate concern with its own justification.
-#
-# PLEX'S SCHEDULABILITY IS NOW COUPLED TO THE `intel-gpu-plugin` DaemonSet, and that is a real cost,
-# not a footnote. The current mechanism is a hard scheduling constraint: if the resource is
-# unavailable (plugin broken, removed, or not yet reconciled) this pod is UNSCHEDULABLE, and because
-# `apps-wave-0` is `wait: true` with `apps-wave-1` `dependsOn` it, that STALLS THE WHOLE APP TIER.
-# The previous hostPath mechanism degraded silently to software transcoding instead — but it never
-# actually granted access (device-cgroup EPERM, measured 2026-10-01), so there was nothing to keep.
-# THE ESCAPE HATCH IS THIS BLOCK: delete these two lines and re-render, and Plex goes back to
-# software transcoding and the tier unblocks. One field, no code change. `runbooks/plex-quicksync.md`
-# carries that procedure for whoever needs it at 2am.
+# `vcs0`/`vecs0` live, iGPU enabled in BIOS on each. Plex happens to run on k3s-prod-2 today, but
+# that is scheduler history rather than a requirement — this field deliberately renders no
+# nodeSelector, because placement is a separate concern with its own justification.
 #
 # NO `podSecurityContext.supplementalGroups`, AND ADDING ONE WOULD BE INERT — do not "fix" this.
 # The device is `root:render` 0660 and this process is uid/gid 1000, so the obvious move is to push
-# the host `render` GID in as a supplemental group. It cannot work here, and this survived the
-# mechanism swap unchanged. MEASURED IN THE RUNNING CONTAINER, 2026-09-30 and again 2026-10-01: the
-# image's own `/etc/cont-init.d/45-plex-hw-transcode-and-connected-tuner` stats every char device
-# under `/dev/dri`, `groupadd`s a matching group INSIDE the container when none exists, and
+# the host `render` GID in as a supplemental group. It cannot work here. MEASURED IN THE RUNNING
+# CONTAINER, 2026-09-30: the image's own
+# `/etc/cont-init.d/45-plex-hw-transcode-and-connected-tuner` stats every char device under
+# `/dev/dri`, `groupadd`s a matching group INSIDE the container when none exists, and
 # `usermod -a -G`s the `plex` user into it — every start, nothing hardcoded, which also makes a host
-# GID renumbering self-healing (no GID is pinned anywhere in this repo) and which works the same way
-# on a PLUGIN-INJECTED device as on a bind-mounted one. Measured live, `Plex Media Server` ran with
-# `Groups: 44 100 992 1000` — 992 IS the host `render` GID, i.e. the hook had already done the job.
-# The service execs via `s6-setuidgid plex`, and `s6-setuidgid` REPLACES the process group list from
-# `/etc/group` rather than appending to it, so root's gid `0` — which PID 1 (`s6-svscan`) does hold —
-# is GONE, and anything Kubernetes supplies reaches s6-svscan and is discarded before Plex ever
-# starts. The group is the image's job and it does it correctly. `render.py --selftest` asserts the
-# ABSENCE of a pod securityContext for this field precisely so nobody adds an inert one back later.
+# GID renumbering self-healing (no GID is pinned anywhere in this repo). The service then execs via
+# `s6-setuidgid plex`, and `s6-setuidgid` REPLACES the process group list from `/etc/group` rather
+# than appending to it: `Plex Media Server` runs with `Groups: 100 1000`, and root's gid `0` — which
+# PID 1 (`s6-svscan`) does hold — is GONE. Anything Kubernetes supplies therefore reaches s6-svscan
+# and is discarded before Plex ever starts. Mounting the device is sufficient; the group is the
+# image's job and it does it correctly. `render.py --selftest` asserts the ABSENCE of a pod
+# securityContext for this field precisely so nobody adds an inert one back later.
 #
-# THE LAST MILE IS A MANUAL OPERATOR STEP AND CANNOT LIVE IN THIS REPO. Handing over the device does
+# `DirectoryOrCreate` IS THE SAFE FAILURE MODE, not laziness. A node that comes back without the
+# device (rebuild, BIOS reset, driver regression, hardware swap) gets an empty directory and Plex
+# degrades to SOFTWARE transcoding. `Directory` would fail the mount instead — and because
+# `apps-wave-0` is `wait: true` with `apps-wave-1` `dependsOn` it, that would stall the WHOLE app
+# tier for a feature that is not load-bearing. The price, stated plainly: a missing device is
+# SILENT. This SD renders no `metricsEndpoint`, so there is no ServiceMonitor, no transcode-mode
+# metric, and no alert that could ever fire. The only proof is an operator reading the Plex
+# dashboard.
+#
+# THE LAST MILE IS A MANUAL OPERATOR STEP AND CANNOT LIVE IN THIS REPO. Mounting the device does
 # not enable hardware transcoding — Plex's own `HardwareAcceleratedCodecs` preference does, and it
 # is ABSENT from `Preferences.xml` today (the toggle has never been on). NO environment variable can
 # set it: a grep of the running image's entire init surface (`/etc/cont-init.d`, `/etc/services.d`,
@@ -131,7 +128,8 @@ env:
 # and the six prefs the image does write (`MachineIdentifier`, `ProcessedMachineIdentifier`,
 # `PlexOnlineToken`, `customConnections`, `allowedNetworks`, `TranscoderTempDirectory`) are all
 # unrelated. So there is no GitOps path to the toggle; an operator clicks it once in the web UI.
-# `runbooks/plex-quicksync.md` is that procedure, plus how to verify it took.
+# `runbooks/plex-quicksync.md` is that procedure, plus how to verify it took and the
+# device-cgroup failure mode to expect first.
 hardware:
  gpu: intel-quicksync
 exposure: public              # edge port-forward + public DNS; clients + Seerr reach it (docs/09; R-DNS/R-NET)
@@ -100,9 +100,6 @@ dependencies:
  - to: jackett                 # arr → indexer proxy (docs/13 dependency graph; R-NET-02 explicit allow)
    port: 9117
    protocol: tcp
-  - to: plex
-    port: 32400                 # arr -> plex: required since library is on NFS which does not provide file CRUD notifications
-    protocol: tcp
 ingressRoutes:
  - host: radarr.${BASE_DOMAIN}
    port: 7878                  # Radarr web/API; TLS terminates at the shared Gateway (docs/08, docs/09)
@@ -166,14 +166,11 @@ OAUTH2_PROXY_METRICS_PORT = 44180
 # --- Hardware capability: `hardware.gpu: intel-quicksync` ------------------------------
 # The ServiceDefinition declares the CAPABILITY (schemas/servicedefinition.schema.json
 # `hardware.gpu`); everything below is the MECHANISM that currently satisfies it and is
-# deliberately confined to this file. This file is the ONLY place the mechanism appears,
-# which is what let it be swapped on 2026-10-01 -- from a `/dev/dri` hostPath to the Intel
-# GPU device plugin's extended resource -- with ZERO ServiceDefinition edits.
-#
-# The extended resource is advertised by the `intel-gpu-plugin` DaemonSet
-# (platform/intel-gpu-plugin/, pinned intel/intel-gpu-plugin:0.37.0). MEASURED on all three
-# prod nodes 2026-10-01: `.status.allocatable["gpu.intel.com/i915"] == 1`.
-QUICKSYNC_RESOURCE = "gpu.intel.com/i915"
+# deliberately confined to this file. Swapping to the Intel GPU device plugin
+# (`gpu.intel.com/i915` resource requests instead of a hostPath) is a change here and
+# nowhere else -- no catalog entry moves.
+DRI_VOLUME_NAME = "dri"
+DRI_DEVICE_DIR = "/dev/dri"

 # --- API routes: 401 instead of 302, PER APP ------------------------------------------
 # oauth2-proxy answers an unauthenticated request with a 302 to Keycloak. Its built-in AJAX
@@ -574,59 +571,41 @@ def r_deployment(s: dict) -> dict:
    # workload needs the host iGPU's render node for hardware video transcode. The SD says
    # only that; the wiring below is the platform's current mechanism for satisfying it.
    #
-    # THE MECHANISM IS AN EXTENDED RESOURCE, AND THE hostPath IT REPLACED WAS MEASURED NOT
-    # TO WORK. Do NOT "simplify" this back into a `/dev/dri` hostPath volume. That was the
-    # original implementation (merged 2026-09-30) and it was proven broken in the live Plex
-    # pod on k3s-prod-2 on 2026-10-01: the device node was VISIBLE in the container
-    # (`crw-rw---- root video2 226,128 renderD128`) and could not be opened --
-    # `uid 0 O_RDWR -> EPERM` and `uid 1000 O_RDWR -> EPERM`. EPERM from the DEVICE CGROUP,
-    # not EACCES from file permissions, proven three ways: root on the HOST opens the same
-    # device rc=0; the node is unified `cgroup2fs`; and the container's runc `config.json`
-    # read `linux.resources.devices: [{allow: False, access: 'rwm'}]` with
-    # `linux.devices: None` -- one deny-all rule, no allow entry for major 226. A hostPath is
-    # a filesystem operation: it binds the device node in but adds NO cgroup allow rule,
-    # because Kubernetes cannot infer one from a volume.
+    # `type: DirectoryOrCreate` is DELIBERATE and load-bearing -- do NOT "tighten" it to
+    # `Directory`. A node that comes back without the render device (rebuild, BIOS change,
+    # driver regression, hardware swap) must degrade the workload to SOFTWARE transcoding,
+    # not fail the mount: `apps-wave-0` is `wait: true` and `apps-wave-1` dependsOn it, so a
+    # failed hostPath mount stalls the entire app tier for the sake of a feature that is not
+    # load-bearing. `DirectoryOrCreate` turns that failure mode into "transcodes in
+    # software" instead of "the app tier does not reconcile". /dev is tmpfs, so the empty
+    # directory the kubelet creates on such a node leaves nothing durable behind.
    #
-    # The device plugin is what produces the allow rule. Confirmed in the v0.37.0 source:
-    # `createDeviceSpecsFromDrmFiles` emits `DeviceSpec{..., Permissions: "rw"}`, which the
-    # kubelet turns into both the device injection and the matching cgroup allow.
-    #
-    # `limits`, NOT `requests`, AND THAT IS NOT A STYLE CHOICE: an extended resource must be
-    # expressed in `limits`. Kubernetes mirrors `requests` from `limits` automatically, and a
-    # requests-only extended resource is invalid. App container only, never a sidecar -- the
-    # oauth2-proxy sidecar does no transcoding.
-    #
-    # THE FAILURE MODE THIS TRADED INTO, STATED PLAINLY -- it is worse in blast radius, and
-    # unavoidable. BEFORE: a missing device meant `DirectoryOrCreate` mounted an empty dir,
-    # Plex ran and SILENTLY software-transcoded (invisible, but harmless to everything else).
-    # NOW: if the resource is unavailable (plugin broken, removed, or not yet reconciled) the
-    # pod is UNSCHEDULABLE, and because `apps-wave-0` is `wait: true` with `apps-wave-1`
-    # dependsOn it, that STALLS THE APP TIER. There is no graceful-degradation variant: an
-    # extended resource is a hard scheduling constraint, and it is also the only thing that
-    # produces the cgroup allow rule. Plex's schedulability is now coupled to the
-    # intel-gpu-plugin DaemonSet; that is the price of hardware transcoding working at all.
-    # ESCAPE HATCH (one field, no code change): delete the `hardware:` block from
-    # `catalog/plex.yaml` and re-render -- Plex returns to software transcoding and the tier
-    # unblocks. runbooks/plex-quicksync.md carries it.
+    # The mount is deliberately NOT readOnly: VA-API opens the render node read-write.
    #
    # `podSecurityContext.supplementalGroups` is DELIBERATELY NOT SET here, and adding it
-    # would be a regression, not a hardening. MEASURED in the running container on prod-2
-    # (2026-09-30, re-measured 2026-10-01): the image's own cont-init hook
+    # would be a regression, not a hardening. MEASURED in the running container on prod-2,
+    # 2026-09-30: the image's own cont-init hook
    # `/etc/cont-init.d/45-plex-hw-transcode-and-connected-tuner` `find`s every char device
    # under /dev/dri, `stat -c '%g'` each one's GID, `groupadd`s a matching group INSIDE the
    # container when none exists, and `usermod -a -G` the app user into it -- every start,
-    # nothing hardcoded. It does exactly the same thing to the PLUGIN-INJECTED device, which
-    # is why this swap needs no group work either. cont-init.d completes before services.d,
-    # so the account database s6 reads at exec time already carries the group: measured live,
-    # `Plex Media Server` ran with `Groups: 44 100 992 1000`, where 992 is the host `render`
-    # GID. The service is started with `exec s6-setuidgid plex ...`, and `s6-setuidgid`
-    # REPLACES the process group list from /etc/group rather than appending to it, so
-    # anything Kubernetes puts in supplementalGroups reaches s6-svscan and is discarded
-    # before the app ever starts. A supplementalGroups entry here would be inert AND would
-    # mislead whoever debugs this next.
+    # nothing hardcoded. cont-init.d completes before services.d, so the account database
+    # s6 reads at exec time already carries the group. The service is then started with
+    # `exec s6-setuidgid plex ...`, and `s6-setuidgid` REPLACES the process group list from
+    # /etc/group rather than appending to it: `Plex Media Server` runs with
+    # `Uid: 1000  Gid: 1000  Groups: 100 1000` -- root's gid 0, which PID 1 (s6-svscan) does
+    # have, is GONE. Anything Kubernetes puts in supplementalGroups reaches s6-svscan and is
+    # then discarded before the app ever starts. MOUNTING THE DEVICE IS SUFFICIENT; the
+    # group handling is the image's job and it does it correctly. A supplementalGroups entry
+    # here would be inert AND would mislead whoever debugs this next.
    hw_gpu = (s.get("hardware") or {}).get("gpu")
    if hw_gpu == "intel-quicksync":
-        container["resources"] = {"limits": {QUICKSYNC_RESOURCE: 1}}
+        volume_mounts.append({"name": DRI_VOLUME_NAME, "mountPath": DRI_DEVICE_DIR})
+        volumes.append(
+            {
+                "name": DRI_VOLUME_NAME,
+                "hostPath": {"path": DRI_DEVICE_DIR, "type": "DirectoryOrCreate"},
+            }
+        )

    if volume_mounts:
        container["volumeMounts"] = volume_mounts
@@ -2671,13 +2650,10 @@ def _selftest() -> int:
        "an SD without podSecurityContext must not gain a pod securityContext",
    )

-    # 6b) hardware.gpu: intel-quicksync -> a `gpu.intel.com/i915` LIMIT on the app container
-    #     and NOTHING ELSE: no volume, no volumeMount, no securityContext, no nodeSelector.
-    #     The SD declares the CAPABILITY; these assertions pin the MECHANISM that currently
-    #     satisfies it -- including what it deliberately does NOT emit -- so a change to it
-    #     is a deliberate, visible edit. The previous mechanism (a /dev/dri hostPath) is
-    #     asserted ABSENT: it was measured not to work (EPERM from the device cgroup; see
-    #     the emission site), and the absence assertion is what stops it coming back.
+    # 6b) hardware.gpu: intel-quicksync -> a /dev/dri hostPath volume and a read-write mount
+    #     on the app container, and NOTHING ELSE. The SD declares the CAPABILITY; these
+    #     assertions pin the MECHANISM that currently satisfies it -- including what it
+    #     deliberately does NOT emit -- so a change to it is a deliberate, visible edit.
    hw_docs = render(
        {
            "name": "hw",
@@ -2688,36 +2664,24 @@ def _selftest() -> int:
    hw_pod = next(
        d[1] for d in hw_docs if d[1]["kind"] == "Deployment"
    )["spec"]["template"]["spec"]
-    hw_app = hw_pod["containers"][0]
-    # The whole mechanism, exactly: an extended resource in `limits`. `requests` is NOT set
-    # by the renderer -- Kubernetes mirrors it from `limits`, and a requests-only extended
-    # resource is invalid. Asserting the exact dict is deliberate: it fails if anyone adds a
-    # CPU/memory resources feature through this field (that would be scope creep, and this
-    # field is about the DEVICE only).
    check(
-        hw_app.get("resources") == {"limits": {"gpu.intel.com/i915": 1}},
-        "hardware.gpu=intel-quicksync must render resources.limits "
-        "{gpu.intel.com/i915: 1} on the app container, and nothing else in resources",
+        {
+            "name": "dri",
+            "hostPath": {"path": "/dev/dri", "type": "DirectoryOrCreate"},
+        }
+        in hw_pod.get("volumes", []),
+        "hardware.gpu=intel-quicksync must render a /dev/dri hostPath volume "
+        "with type DirectoryOrCreate (a GPU-less node must degrade, not fail the mount)",
    )
-    # The retired mechanism must stay retired. A hostPath binds the device node in but adds
-    # no device-cgroup allow rule, so the open() was EPERM with the node plainly visible.
+    hw_mounts = hw_pod["containers"][0].get("volumeMounts", [])
    check(
-        not any(
-            "hostPath" in v or v.get("name") == "dri" for v in hw_pod.get("volumes", [])
-        )
-        and not any(
-            m.get("mountPath") == "/dev/dri" or m.get("name") == "dri"
-            for m in hw_app.get("volumeMounts", [])
-        ),
-        "hardware.gpu=intel-quicksync must render NO /dev/dri hostPath volume and no "
-        "/dev/dri mount (the hostPath mechanism was measured not to work: device-cgroup "
-        "EPERM; the device plugin's DeviceSpec Permissions: rw is what grants access)",
+        {"name": "dri", "mountPath": "/dev/dri"} in hw_mounts,
+        "hardware.gpu=intel-quicksync must mount /dev/dri READ-WRITE on the app container",
    )
-    # The resource is the WHOLE feature: no pod securityContext is invented. The image's own
-    # cont-init hook adds the app user to the (plugin-injected) device's group inside the
-    # container, and s6-setuidgid discards any Kubernetes-supplied supplementalGroups anyway
-    # (see the emission site). Asserting the absence is what stops someone adding an inert
-    # one back.
+    # The device mount is the WHOLE feature: no pod securityContext is invented. The image's
+    # own cont-init hook adds the app user to the device's group inside the container, and
+    # s6-setuidgid discards any Kubernetes-supplied supplementalGroups anyway (see the
+    # emission site). Asserting the absence is what stops someone adding an inert one back.
    check(
        "securityContext" not in hw_pod,
        "hardware.gpu must NOT invent a pod securityContext (supplementalGroups is inert "
@@ -2725,12 +2689,10 @@ def _selftest() -> int:
    )
    # Nothing privileged, and no node pinning: Kyverno restrict-host-namespaces (Enforce)
    # rejects `privileged: true` in an app namespace, and placement is a separate concern
-    # with its own justification -- this field is about the DEVICE only. (The extended
-    # resource now constrains placement to nodes the plugin advertises, which is the
-    # scheduler's own doing, not a nodeSelector this renderer writes.)
+    # with its own justification -- this field is about the DEVICE only.
    check(
        "privileged" not in hw_pod.get("securityContext", {})
-        and "securityContext" not in hw_app
+        and "securityContext" not in hw_pod["containers"][0]
        and "nodeSelector" not in hw_pod,
        "hardware.gpu must emit no privileged securityContext and no nodeSelector",
    )
@@ -2743,10 +2705,8 @@ def _selftest() -> int:
    check(
        "volumes" not in nohw_pod
        and "volumeMounts" not in nohw_pod["containers"][0]
-        and "resources" not in nohw_pod["containers"][0]
        and "securityContext" not in nohw_pod,
-        "an SD without `hardware` must gain no resources block, no volume, no mount and no "
-        "securityContext",
+        "an SD without `hardware` must gain no dri volume, no mount and no securityContext",
    )
    # An SD that declares BOTH keeps its own podSecurityContext exactly as written -- the
    # hardware field neither adds to it nor rewrites it.
@@ -2763,35 +2723,9 @@ def _selftest() -> int:
        if d[1]["kind"] == "Deployment"
    )["spec"]["template"]["spec"]
    check(
-        hwm_pod["securityContext"] == {"fsGroup": 1001, "supplementalGroups": [44]}
-        and hwm_pod["containers"][0].get("resources")
-        == {"limits": {"gpu.intel.com/i915": 1}},
+        hwm_pod["securityContext"] == {"fsGroup": 1001, "supplementalGroups": [44]},
        "hardware.gpu must leave the SD's own podSecurityContext untouched",
    )
-    # The resource goes on the APP container only. A forward-auth app renders an oauth2-proxy
-    # sidecar, which does no transcoding and must not consume one of the node's i915 slots.
-    hws_containers = next(
-        d[1]
-        for d in render(
-            {
-                "name": "hws",
-                "source": {"image": "a:1"},
-                "hardware": {"gpu": "intel-quicksync"},
-                "ingressRoutes": [{"host": "hws.home.keithjackson.dev", "port": 8080}],
-                "auth": {"mode": "forward-auth", "groups": ["media-users"]},
-            }
-        )
-        if d[1]["kind"] == "Deployment"
-    )["spec"]["template"]["spec"]["containers"]
-    check(
-        len(hws_containers) == 2
-        and hws_containers[0].get("resources")
-        == {"limits": {"gpu.intel.com/i915": 1}}
-        and "gpu.intel.com/i915"
-        not in hws_containers[1].get("resources", {}).get("limits", {}),
-        "hardware.gpu must put the i915 limit on the APP container only, never on the "
-        "oauth2-proxy sidecar",
-    )

    # 6c) forward-auth (Option B): an exposed forward-auth app gets an oauth2-proxy sidecar that
    #     fronts the Gateway path (fail-closed), while oidc/native/none apps are unchanged.
@@ -100,9 +100,6 @@ dependencies:
  - to: jackett                 # arr → indexer proxy (docs/13 dependency graph; R-NET-02 explicit allow)
    port: 9117
    protocol: tcp
-  - to: plex                    # arr -> plex: required since library is on NFS which does not provide file CRUD notifications
-    port: 32400
-    protocol: tcp
 ingressRoutes:
  - host: sonarr.${BASE_DOMAIN}
    port: 8989                  # Sonarr web/API; TLS terminates at the shared Gateway (docs/08, docs/09)
@@ -1,54 +1,39 @@
 #!/usr/bin/env python3
-"""ci/approval-override.py — select the admin-override on a PR, if there is a valid one.
+"""ci/approval-override.py — select the admin-override comment on a PR, if there is a valid one.

-This script decides NOTHING about authority. It parses a PR's comments and reviews and returns
-the single override *candidate* that ci/approval-policy.sh should then try to authorise against
+This script decides NOTHING about authority. It parses a PR's comment list and returns the
+single override *candidate* that ci/approval-policy.sh should then try to authorise against
 the live Gitea permission API. Keeping the two apart is the point:

  * parsing is pure, offline, and therefore TESTABLE (ci/tests/approval-override.test.sh);
  * authorisation needs the API and must stay in the stage that fails closed.

-A candidate is a comment OR a review whose body contains, AT THE START OF A LINE, the directive
-followed by a non-empty reason:
+A candidate is a comment whose body contains, AT THE START OF A LINE, the directive followed
+by a non-empty reason:

    /approve-override the gate cannot gate itself and I am the only human reviewer

-TWO SOURCES, AND WHY THAT IS NOT BELT-AND-BRACES. Measured 2026-10-02 on PR #38: the override was
-posted as an ordinary PR comment, was well-formed, was newer than the head commit — and the stage
-still blocked, because CI could not READ it. `SETTINGS_API_TOKEN` is minted with scopes
-`[read:repository, read:admin]`, and Gitea puts /issues/{n}/comments behind the *issue* scope, so
-the request came back as an error OBJECT rather than an array. `/pulls/{n}/reviews` is under
-read:repository and was readable in the same run. So:
-
-  * a REVIEW body works with the token CI has today (leave a review of type "Comment");
-  * a COMMENT body works once the token carries read:issue (see infra/gitea/set-ci-token.sh).
-
-Accepting both means the hatch is not hostage to one API scope. A source that cannot be read
-contributes no candidates and is reported on stderr; it can only cause a false BLOCK, never a
-false pass, which is why degrading it is safe and blocking on it was not necessary.
-
 WHY EACH RULE IS HERE

  * START OF A LINE, not "anywhere in the body". Otherwise quoting someone else's override
-    ("you could just /approve-override this") re-arms it. Lines beginning with '>' are DROPPED
-    rather than unquoted, for exactly that reason.
-  * A REASON IS MANDATORY. A bare directive records that a review was waived but not why, which
-    is the difference between an audit trail and a rubber stamp.
-  * STALE OVERRIDES ARE DISCARDED. An override earned at commit A must not silently cover commit
-    B. Any candidate created at or before the head commit's timestamp is dropped — the same
-    semantics Gitea's own `dismiss_stale_approvals` applies to approvals. Push new commits and
-    you must re-override.
-  * A PENDING REVIEW IS NOT SUBMITTED. It is a private draft visible only to its author, so it is
-    not an act of anything and is dropped.
-  * THE LATEST CANDIDATE WINS, across both sources, so a later override supersedes an earlier one.
+    ("you could just /approve-override this") re-arms it. Markdown quotes are stripped of a
+    leading '>' before matching for the same reason -- a quoted directive must NOT count, so
+    lines beginning with '>' are DROPPED, not unquoted.
+  * A REASON IS MANDATORY. A bare directive records that a review was waived but not why,
+    which is the difference between an audit trail and a rubber stamp.
+  * STALE OVERRIDES ARE DISCARDED. An override earned at commit A must not silently cover
+    commit B. Any candidate created at or before the head commit's timestamp is dropped --
+    the same semantics Gitea's own `dismiss_stale_approvals` applies to reviews. Push new
+    commits and you must re-override.
+  * THE LATEST CANDIDATE WINS, so a second override comment supersedes the first rather than
+    both being live.

-Output: one TSV line (login, timestamp, source, reason) on stdout, or nothing at all when there is
-no valid candidate. Never exits non-zero for "no override" — absence is a normal answer and the
+Output: one TSV line (login, created_at, reason) on stdout, or nothing at all when there is no
+valid candidate. Never exits non-zero for "no override" -- absence is a normal answer, and the
 caller must not be able to confuse it with a parse crash.

 Input, all via env so nothing lands in `ps`:
-  COMMENTS_JSON  the Gitea /issues/{n}/comments array (or an error object; or absent)
-  REVIEWS_JSON   the Gitea /pulls/{n}/reviews array   (or an error object; or absent)
+  COMMENTS_JSON  the Gitea /issues/{n}/comments array
  HEAD_TIME      ISO-8601 timestamp of the PR head commit
  DIRECTIVE      the override directive, e.g. /approve-override
 """
@@ -96,97 +81,57 @@ def extract_reason(body, directive):
    return None


-def load_source(env_name, label):
-    """Return a list of items for one source, or [] with a stderr note if it is unusable."""
-    raw = os.environ.get(env_name)
-    if not raw or not raw.strip():
-        return []
-    try:
-        parsed = json.loads(raw)
-    except (ValueError, TypeError):
-        print(
-            "approval-override: %s is not valid JSON — ignoring that source" % label,
-            file=sys.stderr,
-        )
-        return []
-    if isinstance(parsed, list):
-        return parsed
-    # An error object, typically {"message": "token does not have ... scope"}. Say which,
-    # because "no override found" and "could not read the overrides" look identical from
-    # the outside and the first wasted a real debugging session.
-    detail = ""
-    if isinstance(parsed, dict):
-        detail = str(parsed.get("message") or parsed.get("errors") or "")[:200]
-    print(
-        "approval-override: %s is not a list (Gitea returned %s%s) — ignoring that source"
-        % (label, type(parsed).__name__, ": " + detail if detail else ""),
-        file=sys.stderr,
-    )
-    return []
-
-
-def candidates_from(items, source, directive, head_time):
-    """Yield (when, login, reason, raw_when, source) for every valid override in one source."""
-    found = []
-    for item in items:
-        if not isinstance(item, dict):
-            continue
-        login = ((item.get("user") or {}).get("login") or "").strip()
-        reason = extract_reason(item.get("body"), directive)
-        if not login or not reason:
-            continue
-        # A PENDING review is an unsubmitted private draft — not an act of anything.
-        state = str(item.get("state") or "").upper()
-        if source == "review" and state == "PENDING":
-            print(
-                "approval-override: dropping PENDING (unsubmitted) review by '%s'" % login,
-                file=sys.stderr,
-            )
-            continue
-        raw_when = (
-            item.get("submitted_at") or item.get("created_at") or item.get("updated_at") or ""
-        )
-        when = parse_ts(raw_when)
-        if when is None:
-            print(
-                "approval-override: dropping %s override by '%s' — unreadable timestamp %r"
-                % (source, login, raw_when),
-                file=sys.stderr,
-            )
-            continue
-        # An override must post-date the commit it covers.
-        if head_time is not None and when <= head_time:
-            print(
-                "approval-override: dropping STALE %s override by '%s' (%s) — not newer than "
-                "head commit (%s). Re-post it to override the current commit."
-                % (source, login, when.isoformat(), head_time.isoformat()),
-                file=sys.stderr,
-            )
-            continue
-        found.append((when, login, reason, raw_when, source))
-    return found
-
-
 def main():
    directive = os.environ.get("DIRECTIVE", "/approve-override").strip()
    head_time = parse_ts(os.environ.get("HEAD_TIME", ""))

-    found = []
-    found += candidates_from(
-        load_source("COMMENTS_JSON", "COMMENTS_JSON"), "comment", directive, head_time
-    )
-    found += candidates_from(
-        load_source("REVIEWS_JSON", "REVIEWS_JSON"), "review", directive, head_time
-    )
-
-    if not found:
+    try:
+        comments = json.loads(os.environ.get("COMMENTS_JSON") or "[]")
+    except (ValueError, TypeError):
+        # The caller validated this JSON already; if it is broken here, say so loudly on
+        # stderr and emit no candidate. Silence on stdout means "no override".
+        print("approval-override: COMMENTS_JSON is not valid JSON", file=sys.stderr)
+        return 0
+    if not isinstance(comments, list):
+        print("approval-override: COMMENTS_JSON is not a list", file=sys.stderr)
        return 0

-    # Latest wins, across both sources: a later override supersedes an earlier one.
-    when, login, reason, raw_when, source = max(found, key=lambda c: c[0])
+    candidates = []
+    for comment in comments:
+        if not isinstance(comment, dict):
+            continue
+        login = ((comment.get("user") or {}).get("login") or "").strip()
+        reason = extract_reason(comment.get("body"), directive)
+        if not login or not reason:
+            continue
+        created_raw = comment.get("created_at") or comment.get("updated_at") or ""
+        created = parse_ts(created_raw)
+        if created is None:
+            print(
+                "approval-override: dropping override by '%s' — unreadable timestamp %r"
+                % (login, created_raw),
+                file=sys.stderr,
+            )
+            continue
+        # An override must post-date the commit it covers.
+        if head_time is not None and created <= head_time:
+            print(
+                "approval-override: dropping STALE override by '%s' (%s) — not newer than "
+                "head commit (%s). Re-comment to override the current commit."
+                % (login, created.isoformat(), head_time.isoformat()),
+                file=sys.stderr,
+            )
+            continue
+        candidates.append((created, login, reason, created_raw))
+
+    if not candidates:
+        return 0
+
+    # Latest wins: a later override supersedes an earlier one.
+    created, login, reason, created_raw = max(candidates, key=lambda c: c[0])
    # Keep the reason on one line — this becomes a TSV field.
    reason = " ".join(reason.split())
-    print("%s\t%s\t%s\t%s" % (login, raw_when, source, reason))
+    print("%s\t%s\t%s" % (login, created_raw, reason))
    return 0


@@ -103,15 +103,8 @@ REVIEWS_JSON="$(api "${GITEA_URL}/api/v1/repos/${GITEA_REPO}/pulls/${PR}/reviews
 # PR conversation comments live under the ISSUES endpoint. `/pulls/{n}/comments` returns review
 # (diff) comments ONLY, so an override posted in the normal comment box would never appear in it.
 # Verified against this Gitea (1.24.3) rather than assumed.
-#
-# This one is NOT in the must-parse loop below, and that is deliberate. /issues/{n}/comments sits
-# behind Gitea's *issue* token scope, which `SETTINGS_API_TOKEN` does not carry (it is minted
-# `[read:repository, read:admin]`) — so it returns an error OBJECT, not an array. Blocking on that
-# turned "CI cannot read your override" into a message that said "you did not post one", and cost a
-# real debugging session on PR #38. It is handled explicitly, and loudly, further down: an
-# unreadable source can only cause a false BLOCK, never a false pass.
 COMMENTS_JSON="$(api "${GITEA_URL}/api/v1/repos/${GITEA_REPO}/issues/${PR}/comments?limit=1000" || true)"
-for v in FILES_JSON PR_JSON REVIEWS_JSON; do
+for v in FILES_JSON PR_JSON REVIEWS_JSON COMMENTS_JSON; do
  jq -e . >/dev/null 2>&1 <<<"${!v}" || {
    err "could not read ${v} from Gitea for PR #${PR} — BLOCKING rather than assuming."
    summary "- approval-policy: **BLOCKED — Gitea unreadable**"
@@ -177,23 +170,8 @@ if [ "$OVERRIDE_ENABLED" = "true" ]; then
    exit 1
  fi

-  # Is the comments source actually readable? Say so plainly if not — a scope problem and "you
-  # never posted an override" are indistinguishable from the outside, and conflating them is what
-  # made PR #38 look like a code bug.
-  if ! jq -e 'type == "array"' >/dev/null 2>&1 <<<"${COMMENTS_JSON:-}"; then
-    SCOPE_MSG="$(jq -r '.message // empty' <<<"${COMMENTS_JSON:-null}" 2>/dev/null || true)"
-    warn "cannot read PR COMMENTS from Gitea${SCOPE_MSG:+ — ${SCOPE_MSG}}."
-    warn "  /issues/${PR}/comments needs the *issue* token scope; SETTINGS_API_TOKEN is minted"
-    warn "  [read:repository, read:admin] (infra/gitea/set-ci-token.sh). An override posted as an"
-    warn "  ordinary PR COMMENT is therefore invisible to CI — post it as a REVIEW of type"
-    warn "  'Comment' instead, which /pulls/${PR}/reviews exposes under read:repository."
-    summary "- approval-policy: note — PR comments unreadable (token lacks the issue scope); use a **review** to override"
-    COMMENTS_JSON='[]'
-  fi
-
-  # Pure, offline, unit-tested selection: which comment or review, if any, is a live override?
-  OVERRIDE_TSV="$(COMMENTS_JSON="$COMMENTS_JSON" REVIEWS_JSON="$REVIEWS_JSON" \
-    HEAD_TIME="$HEAD_TIME" DIRECTIVE="$DIRECTIVE" \
+  # Pure, offline, unit-tested selection: which comment, if any, is a live override?
+  OVERRIDE_TSV="$(COMMENTS_JSON="$COMMENTS_JSON" HEAD_TIME="$HEAD_TIME" DIRECTIVE="$DIRECTIVE" \
    python3 "${CI_DIR}/approval-override.py")" || {
      err "ci/approval-override.py failed — BLOCKING rather than assuming there is no override."
      summary "- approval-policy: **BLOCKED — override parser failed**"
@@ -202,8 +180,7 @@ if [ "$OVERRIDE_ENABLED" = "true" ]; then
  if [ -n "$OVERRIDE_TSV" ]; then
    OV_USER="$(cut -f1 <<<"$OVERRIDE_TSV")"
    OV_WHEN="$(cut -f2 <<<"$OVERRIDE_TSV")"
-    OV_SRC="$(cut -f3 <<<"$OVERRIDE_TSV")"
-    OV_WHY="$(cut -f4- <<<"$OVERRIDE_TSV")"
+    OV_WHY="$(cut -f3- <<<"$OVERRIDE_TSV")"

    # AUTHORITY IS MEASURED LIVE, never inferred from the comment or from a name in git.
    PERM_JSON="$(api "${GITEA_URL}/api/v1/repos/${GITEA_REPO}/collaborators/${OV_USER}/permission" || true)"
@@ -237,13 +214,12 @@ print("yes" if (ok_perm and ok_list) else "no")
      else
        warn "ADMIN OVERRIDE by '${OV_USER}' (permission '${OV_PERM}'); author is '${AUTHOR}'."
      fi
-      warn "  via:    PR ${OV_SRC}"
      warn "  when:   ${OV_WHEN}  (head commit ${HEAD_SHA:0:8}, ${HEAD_TIME})"
      warn "  reason: ${OV_WHY}"
      warn "  review waived on: $(printf '%s ' $SENSITIVE)"
      ok "sensitive paths cleared by administrator override — this stage does not block."
      SELFNOTE=""; [ "$OV_USER" = "$AUTHOR" ] && SELFNOTE=", **self-waived as author**"
-      summary "- approval-policy: **OVERRIDDEN by \`${OV_USER}\`** (permission \`${OV_PERM}\`, via PR ${OV_SRC}${SELFNOTE})"
+      summary "- approval-policy: **OVERRIDDEN by \`${OV_USER}\`** (permission \`${OV_PERM}\`${SELFNOTE})"
      summary "  - reason: ${OV_WHY}"
      summary "  - review waived on: $(printf '\`%s\` ' $SENSITIVE)"
      exit 0
@@ -263,12 +239,10 @@ err "  honestly approve for itself. Get a human review, or move the change out o
 printf '    %s\n' $SENSITIVE >&2
 err "  The list lives in infra/gitea/approval-policy.json, with a reason per entry."
 if [ "$OVERRIDE_ENABLED" = "true" ]; then
-  err "  Or, if you hold admin/owner on this repository, post this on the PR:"
+  err "  Or, if you hold admin/owner on this repository, comment on the PR:"
  err "      ${DIRECTIVE} <reason>"
-  err "  as a REVIEW of type 'Comment' (not the plain comment box — CI's token cannot read"
-  err "  /issues/${PR}/comments without the issue scope; see infra/gitea/set-ci-token.sh)."
-  err "  The reason is mandatory, the directive must START a line, and it must be NEWER than"
-  err "  head commit ${HEAD_SHA:0:8} — push again and you must override again."
+  err "  The reason is mandatory, the directive must START a line, and the comment must be"
+  err "  NEWER than head commit ${HEAD_SHA:0:8} — push again and you must override again."
 fi
 summary "- approval-policy: **BLOCKED — needs a non-author approval, or an admin \`${DIRECTIVE}\` comment**"
 exit 1
@@ -26,13 +26,7 @@ BEFORE="2026-10-01T11:30:00Z"

 # run <comments-json> -> stdout of the parser (stderr is diagnostic only)
 run() {
-  COMMENTS_JSON="$1" REVIEWS_JSON="" HEAD_TIME="${2:-$HEAD_TIME}" DIRECTIVE="${3:-/approve-override}" \
-    python3 "$SUT" 2>/dev/null
-}
-
-# run_rev <reviews-json> — the same, but through the REVIEWS source.
-run_rev() {
-  COMMENTS_JSON="" REVIEWS_JSON="$1" HEAD_TIME="${2:-$HEAD_TIME}" DIRECTIVE="${3:-/approve-override}" \
+  COMMENTS_JSON="$1" HEAD_TIME="${2:-$HEAD_TIME}" DIRECTIVE="${3:-/approve-override}" \
    python3 "$SUT" 2>/dev/null
 }

@@ -60,24 +54,10 @@ expect_user() {
 expect_reason() {
  local label="$1" json="$2" want="$3" out got
  out="$(run "$json")"
-  got="$(cut -f4- <<<"$out")"
+  got="$(cut -f3- <<<"$out")"
  if [ "$got" = "$want" ]; then ok "$label"; else bad "$label (wanted '${want}', got '${got}')"; fi
 }

-# check <label> <actual> <wanted>
-check() {
-  if [ "$2" = "$3" ]; then ok "$1"; else bad "$1 (wanted '${3}', got '${2}')"; fi
-}
-
-# review <login> <submitted_at> <state> <body>
-review() {
-  python3 -c '
-import json, sys
-print(json.dumps([{"user": {"login": sys.argv[1]}, "submitted_at": sys.argv[2],
-                   "state": sys.argv[3], "body": sys.argv[4]}]))
-' "$1" "$2" "$3" "$4"
-}
-
 echo "== ci/approval-override.py"

 # --- the happy path -------------------------------------------------------------------
@@ -161,72 +141,5 @@ else
  bad "with no HEAD_TIME the candidate should still be returned (got '${out}')"
 fi

-# --- the REVIEWS source ---------------------------------------------------------------
-# Load-bearing, not redundant. Measured on PR #38: SETTINGS_API_TOKEN is minted
-# [read:repository, read:admin], /issues/{n}/comments needs the ISSUE scope, so a well-formed
-# override in the comment box came back as an error object and was invisible. /pulls/{n}/reviews
-# IS readable with that token, so a review body is the route that works today.
-check "a review body carries an override" \
-  "$(cut -f1 <<<"$(run_rev "$(review jakman85 "$AFTER" COMMENT '/approve-override via a review')")")" \
-  jakman85
-check "the source is reported as 'review'" \
-  "$(cut -f3 <<<"$(run_rev "$(review jakman85 "$AFTER" COMMENT '/approve-override via a review')")")" \
-  review
-check "the source is reported as 'comment' for a comment" \
-  "$(cut -f3 <<<"$(run "$(comment jakman85 "$AFTER" '/approve-override via a comment')")")" \
-  comment
-
-out="$(run_rev "$(review jakman85 "$BEFORE" COMMENT '/approve-override stale review')")"
-check "a stale review override is dropped too" "${out:-<none>}" "<none>"
-
-out="$(run_rev "$(review jakman85 "$AFTER" PENDING '/approve-override unsubmitted draft')")"
-check "a PENDING (unsubmitted) review is NOT an act of anything" "${out:-<none>}" "<none>"
-
-check "an APPROVED review carrying the directive still counts as an override" \
-  "$(cut -f1 <<<"$(run_rev "$(review jakman85 "$AFTER" APPROVED '/approve-override belt and braces')")")" \
-  jakman85
-
-out="$(run_rev "$(review jakman85 "$AFTER" COMMENT 'ordinary review prose, no directive')")"
-check "an ordinary review body is not an override" "${out:-<none>}" "<none>"
-
-# --- an unreadable source degrades to 'no candidates', never to a pass ----------------
-# The real-world shape: Gitea answers with {"message": "token does not have ... scope"}.
-ERR_OBJ='{"message":"token does not have at least one of required scope(s): [read:issue]"}'
-out="$(COMMENTS_JSON="$ERR_OBJ" REVIEWS_JSON="" HEAD_TIME="$HEAD_TIME" \
-       DIRECTIVE=/approve-override python3 "$SUT" 2>/dev/null)"
-check "an error OBJECT from the comments API yields no override" "${out:-<none>}" "<none>"
-
-out="$(COMMENTS_JSON="$ERR_OBJ" \
-       REVIEWS_JSON="$(review jakman85 "$AFTER" COMMENT '/approve-override reviews still work')" \
-       HEAD_TIME="$HEAD_TIME" DIRECTIVE=/approve-override python3 "$SUT" 2>/dev/null)"
-check "an unreadable COMMENTS source does not suppress a valid REVIEW override" \
-  "$(cut -f1 <<<"$out")" jakman85
-
-# and it must SAY so, or a scope problem reads as 'you never posted one' (it did, on PR #38)
-errout="$(COMMENTS_JSON="$ERR_OBJ" REVIEWS_JSON="" HEAD_TIME="$HEAD_TIME" \
-          DIRECTIVE=/approve-override python3 "$SUT" 2>&1 >/dev/null)"
-case "$errout" in
-  *"not a list"*read:issue*) ok "the diagnostic names the scope Gitea complained about" ;;
-  *) bad "the diagnostic should quote Gitea's message (got: ${errout})" ;;
-esac
-
-# --- latest wins ACROSS the two sources ----------------------------------------------
-out="$(COMMENTS_JSON="$(comment early "2026-10-01T12:10:00Z" '/approve-override from a comment')" \
-       REVIEWS_JSON="$(review later "2026-10-01T12:50:00Z" COMMENT '/approve-override from a review')" \
-       HEAD_TIME="$HEAD_TIME" DIRECTIVE=/approve-override python3 "$SUT" 2>/dev/null)"
-check "the latest override wins across both sources (review newer)" "$(cut -f1 <<<"$out")" later
-check "and its source is labelled" "$(cut -f3 <<<"$out")" review
-
-out="$(COMMENTS_JSON="$(comment later "2026-10-01T12:50:00Z" '/approve-override from a comment')" \
-       REVIEWS_JSON="$(review early "2026-10-01T12:10:00Z" COMMENT '/approve-override from a review')" \
-       HEAD_TIME="$HEAD_TIME" DIRECTIVE=/approve-override python3 "$SUT" 2>/dev/null)"
-check "the latest override wins across both sources (comment newer)" "$(cut -f1 <<<"$out")" later
-check "and that source is labelled too" "$(cut -f3 <<<"$out")" comment
-
-# --- both sources absent entirely -----------------------------------------------------
-out="$(COMMENTS_JSON="" REVIEWS_JSON="" HEAD_TIME="$HEAD_TIME" \
-       DIRECTIVE=/approve-override python3 "$SUT" 2>/dev/null)"
-check "no sources at all yields no override, and no crash" "${out:-<none>}" "<none>"
-
 printf '\n  %d passed, %d failed\n' "$PASS" "$FAIL"
 [ "$FAIL" -eq 0 ] || exit 1
@@ -129,22 +129,6 @@ KNOWN_EXTERNAL_MONITORS: dict[str, str] = {
        "a PodMonitor, so it resolves against POD ports, not Service ports — the Flux controller "
        "Deployments (and their `http-prom` container port) are installed by the Flux bootstrap "
        "manifests, not authored here. Live on prod: job flux-system/flux-system, 6 targets up.",
-    "platform/oauth2-proxy/podmonitor.yaml:oauth2-proxy-sidecars":
-        "a PodMonitor, so it resolves against POD ports, not Service ports. Unlike the other "
-        "entries here the target is NOT chart-owned — the `metrics` (44180) container port is "
-        "authored in this repo, on the oauth2-proxy sidecar in apps/wave-0/{jackett,qbittorrent,"
-        "pihole}.yaml and apps/wave-1/{radarr,sonarr}.yaml. It is unauditable here because NO "
-        "Service exposes 44180 BY DESIGN: adding one would mean changing catalog/render.py and "
-        "every apps/wave-* render and golden, to publish an endpoint only Prometheus should dial. "
-        "A PodMonitor needs no Service, which is the whole reason it was chosen. What assertion "
-        "(2) would have checked was instead MEASURED on prod 2026-10-01, read-only: the pods "
-        "declare ports [('http', 4180), ('metrics', 44180)], the selector label "
-        "homelab.keithjackson.dev/auth-mode=forward-auth is on exactly those five gate pods, and "
-        "port-forwarding 44180 returns http=200 with 10208 bytes of oauth2_proxy_* metrics. "
-        "CAVEAT, deliberately recorded: those targets are DOWN on prod, because the app "
-        "namespaces' default-deny NetworkPolicy drops the scrape from ns monitoring (same bug and "
-        "fingerprint as platform/longhorn/networkpolicy-metrics.yaml documents). The port name "
-        "resolves; the network path does not yet.",
 }

 MONITOR_KINDS = ("ServiceMonitor", "PodMonitor")
@@ -1,289 +0,0 @@
---
-date: 2026-09-30
-branch: feat/oauth2-proxy-auth-failure-visible
-title: The Jackett auth failure was invisible because the gates emit nothing — alert on the gap, not on a metric that does not exist
---
-
-## What changed
-
-Jackett's UI broke in the way that costs the most: **HTTP 200 and a plausible page**. The
-operator's report named the property that matters — *"reloading the page never fixes the issue and
-the user is never re-prompted for login"*. Two sibling branches fix the auth defects. This one is
-about the fact that **no signal existed anywhere**, and it turns out that is not an oversight in
-the alert rules. It is an absence of data.
-
-**The measurement that decided the whole design** (prod, live Prometheus, 2026-09-30):
-
-    count by (__name__) ({__name__=~"oauth2_proxy.*"})
-      oauth2_proxy_requests_in_flight => 2
-
-Two series. Both from the **shared** forward-auth Deployment in the `oauth2-proxy` namespace.
-That is every oauth2-proxy metric this cluster holds. The six per-app gate sidecars — crafty,
-jackett, pihole, qbittorrent, radarr, sonarr — publish **nothing at all**: they run with
-`--http-address=0.0.0.0:4180` and no `--metrics-address`, so oauth2-proxy's metrics listener never
-starts; they declare only a `http:4180` container port; and no ServiceMonitor or PodMonitor in the
-cluster selects them.
-
-So the alert the brief asked for — *"a gated app is serving a sustained rate of auth redirects to
-a user who is authenticated"* — **is not writable**, and writing it anyway would have produced
-exactly the artefact this repo keeps getting burned by: a rule that is present, evaluating,
-permanently silent, and indistinguishable from health. It was not written.
-
-What was written instead alerts on the condition that made the incident invisible, from families
-that **are** scraped:
-
- **`platform/oauth2-proxy/auth-visibility-alerts.yaml`** — `OAuth2ProxyGateUnobserved`:
-
-      count by (namespace) (kube_pod_container_info{container="oauth2-proxy"})
-        unless
-      count by (namespace) (up{container="oauth2-proxy"})
-
-  `for: 1h`, `severity: warning`. `kube_pod_container_info` is kube-state-metrics (a declared
-  owner in `alert-metrics-have-scrape-targets`) and sees the container whether or not it exports
-  anything; `up` is UNIVERSAL and carries a `container` label for any scrape target, so the rule
-  needs no advance knowledge of what job name a future per-app scrape will use. Nothing in it
-  touches `oauth2_proxy_*`, so it cannot be inert for the reason it is reporting. **It returns six
-  namespaces against live prod right now** and excludes `oauth2-proxy`, which is scraped. It
-  clears per-namespace as each gate gains a real scrape.
- **`platform/oauth2-proxy/auth-visibility-alerts.promtool-test.yaml`** — four states pinned:
-  fires for an unscraped namespace, never for the scraped one, honours `for: 1h` (pending at 59m),
-  and **stops** once a scrape appears under a *different* job name. Series shapes copied off live
-  prod, not invented.
- **`runbooks/oauth2-proxy-auth-failures.md`** — how to tell "the gate refused me" from "the group
-  check refused me" from "the app refused me" from "the XHR silently got HTML", with the
-  2026-09-30 jackett trace as the worked example. Registered in `runbooks/kustomization.yaml`'s
-  `configMapGenerator` and listed in `runbooks/README.md`.
- **`runbooks/README.md`** — a new row in *"Alerts you should not trust the silence of"* for the
-  per-app sidecars, plus the measured reason.
- **`platform/oauth2-proxy/README.md`** — what this component can and cannot see, and the exact
-  three-part change that would close the gap.
-
-**Why the obvious alternative was rejected.** An alert on the *shared* proxy's
-`oauth2_proxy_requests_total{code="302"}` ratio is the one a reader expects to see here. It would
-need a new `SCRAPE_OWNERS` entry in `conformance/**` (a sensitive path needing human approval),
-and — decisively — **it would not have fired on this incident**: the shared instance is not in the
-data path for any sidecar-gated app, and its current pods export no `oauth2_proxy_requests_total`
-at all, having proxied nothing since they started (the counter exists in the TSDB only from an
-older ReplicaSet, `oauth2-proxy-78449b5657-*`, with `code` labels `302` and `401` and no `202`).
-Shipping it would have looked like coverage of the reported failure and been none.
-
-## What I verified
-
-Everything below was measured against live prod through the pinned container, read-only. No
-`apply`, no `edit`, no `patch`, no `flux reconcile`.
-
- **The full oauth2-proxy metric inventory.** `count by (__name__) ({__name__=~"oauth2_proxy.*"})`
-  → `oauth2_proxy_requests_in_flight => 2`. `count by (__name__) ({job="oauth2-proxy"})` returns
-  go_*/process_*/promhttp_* plus that one family and nothing else. **Only the shared instance is
-  scraped**: `up{job="oauth2-proxy"}` → 2 targets, `10.0.1.189:44180` and `10.0.2.47:44180`, both
-  `1`, `namespace="oauth2-proxy"`.
- **The per-app sidecars are unscraped, and unscrapable as configured.** Every pod carrying an
-  `oauth2-proxy` container, with its declared ports: the two shared replicas have
-  `[('http',4180),('metrics',44180)]`; crafty, jackett, pihole, qbittorrent, radarr and sonarr all
-  have `[('http',4180)]` only. The live jackett sidecar's args contain no `--metrics-address`.
-  `kubectl get servicemonitors,podmonitors -A` lists 16 ServiceMonitors and 5 PodMonitors; the
-  only oauth2-proxy entry is `oauth2-proxy/oauth2-proxy`.
- **No existing alert is inert *for this reason*, because no alert references these metrics at
-  all.** `grep -rn oauth2_proxy --include=*.yaml` over the tree hits only cookie-name strings in
-  `platform/crafty/`. The 39 live PrometheusRules include `platform-health-identity`, whose four
-  rules are about Keycloak readiness and the client reconciler and are all keyed on `kube_*`
-  (scraped, fine). **The inertness here is the absence of a rule, not a broken one** — which is
-  why the runbook README's inert-alerts table gains a row phrased like the etcd one.
- **Keycloak cannot express it either.** `count by (__name__) ({__name__=~"keycloak_.*"})` →
-  empty, and empty over `[30d]`. The `keycloak-service` scrape yields JVM/Agroal/JGroups metrics
-  only; there are no user-event or login counters, so "a burst of re-logins for one client" is not
-  observable from the IdP side.
- **`oauth2_proxy_requests_total` has existed historically but not on the current pods.**
-  `count_over_time(oauth2_proxy_requests_total[30d])` returns three series, all from
-  `oauth2-proxy-78449b5657-*` (a prior ReplicaSet): `code="302"` on both replicas and `code="401"`
-  on one, ~634 samples each (~5h of a 30d window). **No `code="202"` ever.**
- **The alert expression fires against live data.** Run verbatim on prod:
-  `count by (namespace) (kube_pod_container_info{container="oauth2-proxy"}) unless count by
-  (namespace) (up{container="oauth2-proxy"})` → `pihole, jackett, crafty, qbittorrent, sonarr,
-  radarr`, value 1 each; `oauth2-proxy` correctly absent.
- **The log signal exists and is collected.** Loki (`loki-0`, SingleBinary) and a 3-node Alloy
-  DaemonSet are running, and Alloy labels pod logs with `namespace`/`container`. LogQL over 24h,
-  `{container="oauth2-proxy"}`: crafty 12036 lines, jackett 11669, oauth2-proxy 34559, pihole
-  11520, qbittorrent 11520, radarr 11763, sonarr 11520. Filtered to `|= "No valid authentication
-  in request"`: **crafty 81, jackett 39, radarr 67**; to `|= "AuthSuccess"`: **crafty 1, jackett
-  4, radarr 1**. Those ratios (81:1, 10:1, 67:1) are the incident's signature and are in the
-  runbook as the thing to compare against.
- **Why `kubectl logs` hid it.** The jackett sidecar's stdout is ~11.5k lines/day and almost all
-  of it is `GET "/ping" ... 200 2` from the kubelet probe, twice every 15s. A `--tail=40` shows
-  forty `/ping` lines and looks perfectly healthy. The runbook's commands all filter.
- **Runbook registration, both halves.** `- oauth2-proxy-auth-failures=oauth2-proxy-auth-failures.md`
-  is in `runbooks/kustomization.yaml`'s `configMapGenerator.files`, and the page is listed under
-  *Identity* in `runbooks/README.md`. The page clears the L0 quality floor (the four operator
-  sections, >1500 bytes, mentions `dev.sh` and `--context k3s-prod`), and the alert's
-  `runbook_url` points at exactly that name.
- **Gate:** run in the pinned toolbox from this worktree with the `ENGINE` shim. Exit code and
-  per-stage outcomes in the next section — read them there, not here.
-
-## What I did NOT verify
-
- **The alert has never fired in Alertmanager.** Nothing is applied; the PrometheusRule exists
-  only in git on this branch. What is proven is that its expression returns the expected vector
-  against live prod data and that promtool agrees about its behaviour over synthetic series.
-  **Merging is what deploys it.**
- **`OAuth2ProxyGateUnobserved` would NOT have fired *during* the 2026-09-30 jackett incident in
-  any useful sense** — it describes a standing condition that has been true since the sidecars
-  were deployed, so it would have been firing before, during and after. That is deliberate and it
-  is the honest claim: it is a **gap tracker**, not an incident detector. It would have meant that
-  on 2026-09-30 an operator asking "why did nothing alert?" had the answer already on the board
-  instead of discovering it during the investigation. **No alert on this platform could have
-  detected the incident itself, and none can today.**
- **The alert that the brief actually asked for does not exist, and cannot be written yet.** The
-  sustained-redirect-ratio rule needs `oauth2_proxy_requests_total` from the *per-app* sidecars.
-  **Enabling that requires editing files owned by the two sibling branches** — the sidecar args in
-  `apps/wave-0/jackett.yaml` (Mira Vance) and `apps/wave-0/{qbittorrent,pihole}.yaml`,
-  `apps/wave-1/{radarr,sonarr}.yaml` (Theo Bright) — so it was **not attempted here**. The change
-  is three things per app, together: `--metrics-address=0.0.0.0:44180`, a `metrics` containerPort
-  plus Service port, and a ServiceMonitor. Once any one app has them, the rule belongs beside
-  `OAuth2ProxyGateUnobserved`, and that app's namespace drops out of it automatically.
- **The Loki alerting path is inert and I did not fix it.** Loki *has* a ruler stanza and the
-  chart's `loki-sc-rules` sidecar is running with `LABEL=loki_rule`, `FOLDER=/rules` — so a
-  ConfigMap-shipped LogQL rule would be delivered. But `GET /loki/api/v1/rules` answers **"unable
-  to read rule dir /var/loki/rules/fake: no such file or directory"** (the ruler reads a different
-  directory from the one the sidecar writes), and the rendered config contains **no
-  `alertmanager_url`** — `grep -i 'alertmanager\|rule_path'` over the `loki` ConfigMap returns
-  nothing. So a LogQL alert on `|= "No valid authentication in request"` — which *would* have
-  caught this incident, and is the single highest-value follow-up here — **would evaluate and
-  notify nobody**. Wiring it means `rulerConfig` (alertmanager_url + a matching rules directory)
-  in `platform/monitoring/loki.yaml`, which is not a file this brief gave me. **I did not ship an
-  inert rule ConfigMap to look productive.**
- **Nothing was reproduced in a browser.** The 302-to-200-with-HTML mechanism is read off the
-  sidecar access log and the response sizes (`/UI/Dashboard 200 44379`), not observed in devtools.
- **Loki retention is 72h** (`platform/monitoring/loki.yaml`), so the 24h ratios above are a
-  snapshot; anything older than three days is already gone. This is stated in the runbook because
-  it bounds what an operator can still investigate.
- **The gate's L2/L3 conformance did not run** (`CLUSTER_AVAILABLE` unset), so no runtime
-  requirement touched by this branch is certified. See the exit code below — **rc 3 is
-  UNDETERMINED, not green.**
-
-### Follow-ups, in order of value
-
-1. **Wire the Loki ruler to Alertmanager** (`platform/monitoring/loki.yaml`). This is the only
-   route to an alert that would have caught the actual 2026-09-30 failure, and the data is
-   already being collected. The rule is one expression:
-   `sum by (namespace) (rate({container="oauth2-proxy"} |= "No valid authentication in request" [15m]))
-   > 5 * sum by (namespace) (rate({container="oauth2-proxy"} |= "AuthSuccess" [15m]))`.
-2. **Give one gate sidecar a metrics endpoint** and watch its namespace drop out of
-   `OAuth2ProxyGateUnobserved`. That is the cheapest proof the alert is a tracker and not a nag,
-   and it unlocks the ratio rule in Prometheus.
-3. **Consider whether `--set-xauthrequest` apps should get `--api-routes`** so API paths answer
-   401 instead of 302. That is the fix that would make this failure *loud* rather than merely
-   observable, and it belongs with whoever owns the sidecar args.
-
---
-
-# Round 2 — 2026-10-01: the scrape got wired, and found a bug in this branch's own alert
-
-Added to the same PR (#29) rather than a fourth concurrent branch. PR #28 merged in the meantime
-and `main` moved three PRs ahead; `origin/main` is merged in here, and the `runbooks/kustomization.yaml`
-conflict was resolved by **keeping both** runbook entries (mine and `oauth2-proxy-session`).
-
-## What changed
-
-**`platform/oauth2-proxy/podmonitor.yaml` (new).** PR #28 gave the five fleet sidecars
-`--metrics-address=0.0.0.0:44180` and a named `metrics` port. No Service exposes 44180 on any of
-them, so a ServiceMonitor would have nothing to select — a **PodMonitor** targets pod ports directly
-and needs no renderer change. Selects on the pod label `homelab.keithjackson.dev/auth-mode:
-forward-auth`, which is on exactly the five fleet gate pods and absent from crafty's: the property,
-not an app list, so a sixth forward-auth app needs no edit.
-
-**`auth-visibility-alerts.yaml`: `up{container="oauth2-proxy"}` → `up{container="oauth2-proxy"} == 1`.
-This is a real bug fix, and it is the most important thing in this round.** A target that is
-discovered but failing still publishes `up`, with value **0**. The series exists, so
-`count by (namespace)` returned 1, `unless` removed the namespace, and `OAuth2ProxyGateUnobserved`
-would have **gone quiet while nothing was being scraped at all** — this branch's own disease,
-reproduced inside the alert written to cure it. Not hypothetical: the PodMonitor lands five targets
-whose scrape is dropped, so the bare form would have silently cleared on this very commit.
-
-**Two new unit-test scenarios** pinning that: a discovered-but-failing target must still fire, and a
-target that works and then breaks must re-fire rather than latch cleared.
-
-**Docs corrected rather than appended to.** The 2026-09-30 claim "the sidecars export no metrics at
-all" is now only half true and was rewritten in `runbooks/README.md`, `platform/oauth2-proxy/README.md`
-and the alert header, each showing the two-step history, because each step looked like the end of it.
-The runbook gains the policy-vs-no-target triage (step 1b) and the **radarr `/signalr` worked case**.
-
-**Deliberately NOT shipped: the ratio alert.** `oauth2_proxy_requests_total` now exists on the
-endpoint, but not in the TSDB, because the scrape is blocked. Writing the ratio rule today would make
-it inert for precisely the reason it was refused on 2026-09-30. It becomes writable the day a scrape
-succeeds, not the day a listener exists.
-
-## What I verified
-
- **The endpoint serves — by payload, not by flag.** Port-forwarded to the jackett pod's 44180:
-  `http=200 bytes=10208`, exporting `oauth2_proxy_requests_in_flight`, `oauth2_proxy_requests_total`
-  (`code="200" 3`, `code="302" 2`) and `oauth2_proxy_response_duration_seconds`. `--metrics-address`
-  being in `args` and `/metrics` returning a body are different claims; both now hold.
- **The scrape path is DROPPED, measured from the right place.** From grafana in ns `monitoring`
-  (beside Prometheus, same policy position) to the jackett pod IP: `:44180` → `wget: download timed
-  out`; `:4180` → **also** timed out; the shared proxy's `:44180` → 200 with `oauth2_proxy_*` present.
-  Cause, read from the objects: ns jackett's `default-deny` is `podSelector: {}`,
-  `policyTypes: [Ingress, Egress]`, with an `egress` rule and **no `ingress` key** (deny-all ingress);
-  the only allowance is CNP `jackett-allow-gateway-ingress`, `fromEntities: [ingress]` to port 4180.
-  The shared proxy is scrapable only because ns `oauth2-proxy` has **no NetworkPolicy at all**.
- **No Service exposes 44180** on any of the five (enumerated).
- **The pod label selector is exact:** `auth-mode=forward-auth` on all five fleet gate pods, absent
-  from crafty's. Crafty's sidecar still has no `--metrics-address` (args read in full).
- **Flux ordering forbids shipping the fix from here:** `oauth2-proxy dependsOn=['platform-config']`
-  and `apps-wave-0 dependsOn=['platform-config']` — siblings, no ordering. A NetworkPolicy naming ns
-  `jackett` from this tier would apply today and fail on a cold rebuild.
- **The `== 1` guard is non-vacuous — proven by mutation.** Reverting it to the bare `up` makes the
-  two new scenarios FAIL (`got: nil` at 1h5m and 2h5m) and leaves every other assertion passing;
-  restoring it returns the suite to SUCCESS under pinned promtool v3.14.0.
- **Gate:** see the next section for the exit code and skips.
-
-## What I did NOT verify
-
- **The PodMonitor has never been applied.** That it discovers the five pods is reasoned from the
-  measured pod labels and port name, not observed — no target list has been read with it in place,
-  because applying it is an operator action. **Expect `up == 0` on all five when it lands**, which is
-  the documented state, not a regression.
- **I did not fix the NetworkPolicy, and this PR therefore does not make the gates observable.** It
-  makes them *discovered*, and makes the remaining gap loud instead of silent. The one narrow rule
-  per app (ns monitoring → `auth-mode=forward-auth` → TCP 44180, per
-  `platform/longhorn/networkpolicy-metrics.yaml`) has to be rendered with each app's own policy, in
-  the catalog/renderer that is in flight on another branch. **It needs an owner.**
- **Whether Prometheus will actually select a PodMonitor in ns `oauth2-proxy` targeting other
-  namespaces.** `namespaceSelector.any: true` plus `podMonitorSelectorNilUsesHelmValues: false` and
-  the fact that cross-namespace ServiceMonitors/PrometheusRules already work here say yes; it is not
-  measured with this object.
- **No session-lifecycle claim can be made from the current window.** `AuthSuccess` is **0** on both
-  jackett and radarr since the PR #28 restart, so nobody has signed in and `--cookie-refresh=2m30s`
-  has never executed a refresh. The cookie fix is unproven in the one dimension that matters most.
- **The radarr `/signalr` finding is the coordinator's measurement, not mine** — I reproduced neither
-  the 206/209 sample nor the jackett 0-in-13,612. They are recorded as reported.
- **L2/L3 conformance still did not run** (`CLUSTER_AVAILABLE` unset). Nothing is certified.
-
-### Round 2 addendum — CI is RED, by design, and the local gate cannot see why
-
-After pushing round 2, `gate / gate (pull_request)` reported **failure after 1m42s** while the local
-toolbox run was rc 3 with nothing failed. Measured cause, singular:
-
-    sensitive paths touched:
-      conformance/tests/l0-static/servicemonitor-ports-resolve/check.sh   (matched conformance/**)
-    approving reviews: (no reviews at all)        author=gitea-admin
-
-`ci/approval-policy.sh` is fail-closed and exits 1 when a PR touches a `sensitive_paths` glob with no
-`APPROVED` review from a non-author — "a change to the gate cannot be gated by the gate". The single
-`KNOWN_EXTERNAL_MONITORS` entry is what trips it. **Nothing in L0/L1 failed.**
-
-**The local gate structurally cannot catch this, and said `approval-policy: green (N/A)`.** The stage
-short-circuits to N/A when `GITHUB_EVENT_NAME` is unset, which it always is off-CI. So for any branch
-touching a sensitive path, a clean local gate is a FALSE REASSURANCE — the PR run is the only honest
-signal. That is a general trap, not specific to this change, and it is worth knowing before someone
-concludes a red PR means broken code.
-
-To clear: a non-author approving review, then **re-run the gate** — approval does not re-trigger the
-status check, so the required context stays red until the job runs again. `required_approvals=1`
-already applied to every PR here, so the human was needed regardless; the conformance entry only
-turns the tick red while that is pending.
-
-The alternative is to drop the register entry, which means dropping `podmonitor.yaml` with it (the
-check fails without the declaration). I did not take it: the entry is the "declare the limit"
-mechanism the check explicitly asks for, it is shrink-only so it cannot rot quietly, and
-`flux-podmonitor.yaml` is the same case already in the register. But it is a real trade and the
-reviewer should make it knowingly.
@@ -87,43 +87,6 @@ Also updated: `CLAUDE.md` §1 and the §2 enforcement table (the "approval requi
 explicitly ⬜ with the reason, rather than a stale ✅), and `infra/gitea/README.md` gains §6 and
 marks its historical step 4 as reversed — do not re-apply.

-**Second pass, 2026-10-02 — the override did not work the first time, and why.** The operator ran
-the live PATCH (`required_approvals: 0` confirmed live, with `block_admin_merge_override` and
-`enable_status_check` still `true`), merged PR #35, and posted `/approve-override Need to ensure
-approval override work as expected` on PR #38. The gate re-ran (run 203) and **still blocked.**
-
-The comment was not at fault: posted by `jakman85`, directive at the start of the line, reason
-present, and 29 minutes **newer** than head commit `616a497`, so it cleared the staleness rule.
-What failed was that **CI could not read it.** Run 203's log:
-
-    approval-override: COMMENTS_JSON is not a list
-
-`SETTINGS_API_TOKEN` is minted `["read:repository", "read:admin"]` by
-`infra/gitea/set-ci-token.sh`, and Gitea puts `/issues/{n}/comments` behind the **issue** scope. So
-Gitea returned an error *object*, `jq -e .` accepted it as valid JSON, and the stage fell through
-to "no approving review" — **a permission failure wearing the costume of a missing override.**
-`/pulls/{n}/files` and `/pulls/{n}/reviews` are under `read:repository`, which is exactly why every
-other part of the same stage worked and this one did not.
-
-Three fixes, and the first is the one that mattered most:
-
-1. **The diagnosis is no longer misleading.** `COMMENTS_JSON` is out of the must-parse-or-block
-   loop and is explicitly checked for being an *array*; when it is not, the stage prints Gitea's
-   own `.message`, names the missing scope, and says where to post the override instead. An
-   unreadable source can only cause a false BLOCK, never a false pass, so degrading it to a loud
-   warning is safe — and blocking on it was never the honest behaviour.
-2. **The override is accepted from a PR REVIEW body as well as a comment**, so the hatch is not
-   hostage to one API scope. A review of type "Comment" works on the token CI has *today*. The
-   gate names which source it used. `PENDING` (unsubmitted, author-only draft) reviews are dropped.
-3. **`set-ci-token.sh` now requests `read:issue`**, which makes the ordinary comment box work —
-   the thing anybody reaches for first. It takes effect only on a **re-run**: an existing token's
-   scopes cannot be widened in place.
-
-`ci/tests/approval-override.test.sh` grows from 23 to **38 assertions**, covering the reviews
-source, `PENDING` reviews, an error *object* from the comments API, "an unreadable comments source
-must not suppress a valid review override", latest-wins across both sources, and that the
-diagnostic actually quotes Gitea's message.
-
 **One adjacent fix, deliberately in scope: `ci/tests/gate-decision.test.sh` was already broken.**
 It hand-maintains a list of stub stage scripts that "must name EVERY stage `gate.sh` runs", and it
 did not name `approval-policy` — added to `gate.sh` by PR #17 and never added here. `run_stage`
@@ -167,30 +130,8 @@ missing from its test. `make -C ci test` goes from **FAILED to all suites passed
  **FAIL, 15 failed / 35 passed**. After deriving the stub list from `gate.sh`: **PASS, 50
  assertions**.
 - **`make -C ci test` in the pinned toolbox: `ci/tests: all suites passed`, rc 0** — approval-override
-  **38**, gate-decision 50, touched-requirements-base 31, test-attribution 15, touched-requirements 26,
+  23, gate-decision 50, touched-requirements-base 31, test-attribution 15, touched-requirements 26,
  decisions-log pass. It was rc 2 (`ci/tests: FAILED`) before the stub-list fix.
- **The live flip worked, and the drift detector proved it.** Run 202 (before): `gitea-settings:
-  FAIL`, `required_approvals: DECLARED 0 but LIVE is 1`. Run 203 (after the operator ran the
-  PATCH): `gitea-settings: pass`, with `block_admin_merge_override = true` among the keys it
-  checked. So the narrow change held — the approval count moved and the gate's teeth did not.
- **The first override attempt failed for a measured reason, not a guessed one.** Run 203 log:
-  `approval-override: COMMENTS_JSON is not a list`. Token scopes read from `set-ci-token.sh`:
-  `[read:repository, read:admin]`. The same run successfully read `/pulls/38` and
-  `/pulls/38/files` (author and sensitive paths both resolved) and got past the reviews
-  validation, which is how I know `/pulls/{n}/reviews` IS readable with that token — from
-  behaviour, not from documentation.
- **The comment itself was valid.** `created_at` 2026-10-02T05:31:24Z vs head commit `616a497`
-  committer date 2026-10-02T00:02:20-05:00 → the comment is 29m04s newer, so it passed the
-  staleness rule. Ruling the comment out is what left the token scope as the only candidate.
- **`?limit=1000` is not the culprit.** Queried `/issues/38/comments` with `limit=1000`, `limit=50`
-  and no limit using my own credentials: `type=array` in all three. So the difference is the
-  credential, not the query.
- **The root cause is confirmed by Gitea, in its own words.** Run 206 (the fix in place):
-  `[warn] cannot read PR COMMENTS from Gitea — token does not have at least one of required
-  scope(s), required=[read:issue], token scope=read:admin,read:repository.` followed by the
-  instruction to post the override as a review. That is the diagnosis the first attempt should
-  have produced, and `gitea-settings: pass` in the same run. The stage still ends `FAIL`, correctly
-  — there is no valid override on the PR yet.
 - **Toolbox merge gate** (`./infra/devcontainer/dev.sh run bash -c './ci/gate.sh'`), run on the
  rebased branch: **rc 3, `MERGE GATE: UNDETERMINED`**. Green stages: spec-immutability,
  decisions-log, lint, l0 (23 offline cases, 0 failures), render-golden including the new
@@ -201,32 +142,20 @@ missing from its test. `make -C ci test` goes from **FAILED to all suites passed

 ## What I did NOT verify

- **The override has still never been ACCEPTED by a real run.** This is the second attempt at
-  this bullet, which is itself the point: the first pass called the hatch unverified, and the
-  first real test found a defect that no amount of local testing would have (an API scope CI has
-  and I did not). What is now measured is that the parse → *reject* path works end to end and
-  diagnoses itself. The **accepting** branch — directive found → live permission lookup → exit 0 —
-  has never executed. Posting the override as a **review** on PR #38 is its first real test, and
-  I would not be surprised by a third round.
- **`read:issue` is the right scope name — Gitea said so itself, so this is no longer a guess.**
-  Run 206 printed Gitea's own message: `token does not have at least one of required scope(s),
-  required=[read:issue], token scope=read:admin,read:repository`. That both confirms the root
-  cause and names the string, which matters because this repo has been burned by a token *name*
-  that could not exist (`GITEA_SETTINGS_TOKEN`). What is **still** unverified is that the token
-  *mint* accepts it — `POST /users/{u}/tokens` with that scope has not been run. The review route
-  does not depend on it.
- **I did not verify that Gitea lets a PR's own author submit a `COMMENT`-type review.** Gitea
-  blocks author self-*approval*; "Comment" is expected to be allowed, and that expectation is now
-  load-bearing for the recommended route. It is one click to find out, and I deliberately did not
-  test it by posting an override myself: doing so as `gitea-admin` is precisely the agent
-  self-override that `CLAUDE.md` now forbids.
- **The whole re-run mechanism is manual.** `gate.yml` triggers on `pull_request` and `push: main`
-  only — there is no `issue_comment` trigger, so posting an override does **not** re-run the gate.
-  Re-run the job from the Actions UI, or close and reopen the PR (which fires `pull_request` and
-  leaves the head SHA alone). **Do not push an empty commit to re-trigger it:** that moves the head
-  commit and makes the override stale by the rule above, so it would have to be posted again. A
-  comment trigger was considered and not built — it would need to check out PR head code while the
-  job holds `SETTINGS_API_TOKEN`, which is the classic pwn-request shape and not worth it here.
+- **The live Gitea rule still says `required_approvals: 1`. I did not change it.** Mutating live
+  platform settings is an operator action; `infra/gitea/allow-admin-self-merge.sh` is written,
+  syntax-checked, and **unrun**. The declaration and the live rule must move together.
+  *Now measured, not predicted:* PR #38's CI run (run 202, job 0) fails at **1m44s** with
+  `required_approvals: DECLARED 0 but LIVE is 1` → `gitea-settings: FAIL`. Correct behaviour, and
+  the PR stays red until the script is run.
+- **The override has never been ACCEPTED by a real run** — only offered. Measured in the same CI
+  log: the stage reached `approval-policy: FAIL` on the sensitive paths and printed the *new*
+  code's guidance, `Or, if you hold admin/owner on this repository, comment on the PR:
+  /approve-override <reason> ... NEWER than head commit 7b9f733c`. So the new stage **is** what
+  runs on this PR (self-bootstrapping confirmed by measurement, not by reasoning), and the
+  authorising branch — comment parse → live permission lookup → exit 0 — is still **unexercised**.
+  Posting the comment on PR #38 is its first real test. If it does not work, the recovery is to
+  PATCH `required_approvals` and read run 202's successor log.
 - **I have not seen the gate still REFUSE a merge** now that approvals are 0. The claim that
  `block_admin_merge_override: true` keeps a red gate unmergeable rests on Gitea's documented
  behaviour and on the 2026-09-29 session, **not** on a provoked refusal in this one. That probe
@@ -1,120 +0,0 @@
---
-date: 2026-10-01
-branch: bugfix/arr-to-plex
-title: Radarr and Sonarr may now reach Plex on 32400 — the network path only, not the Plex connection itself
---
-
-## What changed
-
-Radarr and Sonarr had no route to Plex. The media library lives on NFS
-(`/mnt/Storage/plex`, the ZFS dataset `Storage/plex` on `${BULK_NFS_SERVER}`), and NFS
-does not deliver filesystem CRUD notifications, so Plex never learns that an arr has
-written a new file. Without a push from the arrs, the library only reflects new media
-when somebody scans it by hand. That is the bug this branch addresses.
-
-The fix is one `dependencies:` entry per app, added to the catalog — the source of truth:
-
-    - to: plex
-      port: 32400
-      protocol: tcp
-
-in both `catalog/radarr.yaml` and `catalog/sonarr.yaml` (these two *are* the arr suite
-here; `jackett`, `qbittorrent` and `seerr` are different roles and are untouched).
-
-The renderer expands each entry into a **pair** of Cilium policies, which is why a
-three-line catalog change produces 88 lines under `apps/`:
-
-| Side | Policy | File |
-|---|---|---|
-| egress | `radarr-allow-plex-32400` | `apps/wave-1/radarr.yaml` |
-| egress | `sonarr-allow-plex-32400` | `apps/wave-1/sonarr.yaml` |
-| reciprocal ingress | `plex-allow-radarr-32400` | `apps/wave-0/plex.yaml` |
-| reciprocal ingress | `plex-allow-sonarr-32400` | `apps/wave-0/plex.yaml` |
-
-Three commits, and the middle two are worth recording because both were self-inflicted
-gate failures rather than design changes:
-
- `753c48b` — the catalog edit alone, with `apps/` left unrendered.
- `9048c2f` — re-rendered `apps/` from the catalog, which `render==golden` requires.
- `58f02fe` — removed 20 trailing spaces on `catalog/radarr.yaml:103`, left behind as
-  comment-alignment padding when the comment moved down to the `port:` line. Sonarr's
-  equivalent line kept its comment in place, which is why only radarr tripped.
-
-## What I verified
-
-**The lint failure, root-caused.** Gate run 193 on `9048c2f` failed with
-`[fail] lint: FAILED -> blocks merge`, and lint was the only failing stage. yamllint
-emitted 419 findings, but **418 were `line-length`**, which `ci/yamllint.yaml` pins at
-`level: warning` and which therefore cannot change the exit code. The single error-level
-finding in the entire repository was:
-
-    catalog/radarr.yaml
-      103:13    error    trailing spaces  (trailing-spaces)
-
-`trailing-spaces` inherits the default severity (error), so that one line returned rc 1.
-After the fix, `git grep -nIE ' +$' -- '*.yaml' '*.yml'` matches nothing repo-wide.
-
-**Gate run 195 on `58f02fe`** (read from the job log, not from the status tick):
-
-    [ ok ] approval-policy: green     [ ok ] l0: green
-    [ ok ] gitea-settings: green      [ ok ] render-golden: green
-    [ ok ] decisions-log: green       [ ok ] l1: green
-    [ ok ] lint: green
-    [fail] MERGE GATE: UNDETERMINED — greenness was NOT ESTABLISHED.
-    [fail]   Stages that did not run: spec-immutability
-
-The Gitea check reports `success` / "Successful in 1m41s", but the gate's own verdict is
-**UNDETERMINED (rc 3)**, not PASS. That tick is `gate.yml` tolerating exit 3 for the one
-stage it documents as unverifiable on this runner (the spec repo is not checked out
-there). Nothing else produced a 3.
-
-**`render==golden` green** on `58f02fe`, so `apps/` is a faithful canonical render of
-`catalog/` — the four generated policies are not hand-written drift.
-
-**DNS egress was already open** and is not a new gap: `apps/wave-1/radarr.yaml` carries
-an existing allow for port 53 UDP+TCP, so resolving the Plex service name does not need
-anything added here.
-
-**Live branch protection on `main`**, measured against
-`/api/v1/repos/Home-Network/home-network-k3s-impl/branches/main` rather than assumed:
-`protected: true`, `user_can_push: false`, `enable_status_check: true`,
-`status_check_contexts: ['gate / gate (pull_request)']`, `required_approvals: 1`.
-
-## What I did NOT verify
-
-**This change does not accomplish what the PR set out to do.** It opens the network path
-and nothing else. Triggering a library update also requires each arr's
-*Settings → Connect → Plex Media Server* entry plus a Plex token, and **none of that
-exists anywhere in `catalog/` or `apps/`** — I grepped both for `plex`, `token` and
-`connect` and found only NFS paths, a uid and a timezone. Radarr's and Sonarr's config
-lives on a 5Gi Longhorn PVC mounted at `/config`, so that connection is UI-only state
-that exists solely on the PVC and never in git, in the same way Crafty's local login
-does. **Until somebody adds it in each app's UI, Plex still will not see library
-updates, and this branch will look like it did nothing.** That follow-up is not tracked
-by any file in this PR.
-
-**L2/L3 conformance never ran.** `CLUSTER_AVAILABLE` is unset on the runner, so the
-eight requirements this diff touches — `R-NET-01`, `R-NET-05`, `R-NET-06`, `R-NET-07`,
-`R-IDP-02`, `R-IDP-06`, `R-GITOPS-02`, `R-PLAT-02` — are **UNVERIFIED**. That gap is
-unusually load-bearing here: the entire substance of this change is four
-CiliumNetworkPolicies, and no test has confirmed that traffic from the `radarr` or
-`sonarr` namespaces actually reaches `plex:32400`. The green gate proves the offline
-render subset only.
-
-**`spec-immutability` did not run** (`R-TEST-06` not verified), for the documented
-reason — the sibling spec repo is absent from the runner.
-
-**Nothing was checked on the cluster.** I ran no `kubectl`, so I did not confirm that
-the `plex` Service exposes 32400 as the arrs would address it, that the pod labels the
-policies select (`app.kubernetes.io/name`, `k8s:io.kubernetes.pod.namespace`) match the
-running pods, or that Cilium accepted the four new objects. Flux has not applied any of
-this: the branch is unmerged, so `.status.lastAppliedRevision` does not contain it.
-
-**I did not verify Plex's own side** — whether its library-update endpoint on 32400 is
-the right target for the arrs' notification, or whether Plex requires
-"Update my library automatically" enabled to act on one.
-
-**I am not the approver and did not approve this PR.** `required_approvals: 1` is live,
-and the only credential on the authoring workstation belongs to the PR's author
-(`jakman85`), whose own review Gitea does not count. Per CLAUDE.md §1 the merge is a
-human action regardless.
@@ -1,211 +0,0 @@
---
-date: 2026-10-01
-branch: feat/quicksync-via-device-plugin
-title: "`hardware.gpu: intel-quicksync` is now satisfied by `gpu.intel.com/i915`, not a `/dev/dri` hostPath — the hostPath was measured not to work (device-cgroup EPERM), and the swap took ZERO ServiceDefinition edits"
---
-
-## What changed
-
-The mechanism behind `hardware.gpu: intel-quicksync` was replaced. **No ServiceDefinition field
-moved** — that was the whole design bet when this field was made an enum of capability classes
-instead of a device path, and this is the change that collects on it.
-
-**Why the old mechanism had to go.** The `/dev/dri` hostPath shipped on 2026-09-30 was measured
-**non-functional** in the live Plex pod on k3s-prod-2 on 2026-10-01. The device node was *visible*
-in the container — `crw-rw---- root video2 226,128 renderD128` — and could not be opened:
-
-| attempt | result |
-|---|---|
-| `uid 0`, `O_RDWR` | **`EPERM`** "Operation not permitted" |
-| `uid 1000`, `O_RDWR` | **`EPERM`** "Operation not permitted" |
-
-`EPERM` is the **device cgroup**, not `EACCES` from file permissions, proven three ways: root on the
-**host** opens the same device `rc=0`; the node is unified `cgroup2fs`; and the container's runc
-`config.json` read `linux.resources.devices: [{allow: False, access: 'rwm'}]` with
-`linux.devices: None` — one deny-all rule, no allow entry for major 226. A hostPath is a *filesystem*
-operation: it binds the device node in and adds **no cgroup allow rule**, because Kubernetes cannot
-infer one from a volume. `uid 0` failing matters: root does not bypass the cgroup device gate, so
-"run it as root" was never going to work either, and `privileged: true` is unavailable (Kyverno
-`restrict-host-namespaces` is Enforce on app namespaces).
-
-**`catalog/render.py`** — retired `DRI_VOLUME_NAME` / `DRI_DEVICE_DIR` for `QUICKSYNC_RESOURCE`
-(`gpu.intel.com/i915`). The `hardware.gpu == intel-quicksync` branch now emits exactly one thing on
-the **app container only** (never a sidecar):
-
-```yaml
-resources:
-  limits:
-    gpu.intel.com/i915: 1
-```
-
-and no volume, no volumeMount, no `securityContext`, no `nodeSelector`. `limits` rather than
-`requests` is mandatory, not stylistic: Kubernetes mirrors `requests` from `limits` automatically and
-a requests-only extended resource is invalid. This is the **only** app-container `resources` render
-path in the file and it is deliberately narrow — no general CPU/memory resources feature was invented
-along the way.
-
-**Self-tests** — the three existing ones updated plus one new:
- the emitted `resources` dict is asserted **exactly** (`{"limits": {"gpu.intel.com/i915": 1}}`), so
-  a stray CPU/memory addition through this field fails loudly;
- the retired hostPath volume and `/dev/dri` mount are asserted **absent**;
- the no-`hardware` negative extended to cover `resources` (absence still renders nothing at all);
- the `podSecurityContext` pass-through still holds, and the "no synthesised `securityContext`"
-  assertion is kept verbatim;
- **new:** the i915 limit must never reach the oauth2-proxy sidecar.
-
-**`schemas/renderer-contract.md`** — the mechanism half of `### hardware` and invariant 8 rewritten.
-The intent half is unchanged and still correct. The `EPERM` measurement is recorded as the *reason*
-the design is what it is, so a future reader cannot "simplify" it back without knowing it was tried
-and measured. The `DirectoryOrCreate` rationale is kept, explicitly labelled historical.
-
-**`catalog/plex.yaml`** — comment correction only; the `hardware:` field is byte-identical.
-`git diff` on that file contains **no non-comment lines**. Its old comment restated the mechanism
-("exactly two things — a `/dev/dri` hostPath volume…"), which is now false; it states intent and
-points at the contract, and keeps the measured facts that remain true (device on all three nodes,
-`i915` bound, the cont-init hook / `supplementalGroups` explanation).
-
-**`runbooks/plex-quicksync.md`** — the diagnostic sequence now checks
-`.status.allocatable["gpu.intel.com/i915"]` and the plugin DaemonSet instead of a hostPath; the
-decisive open test is specified **as uid 1000 via `s6-setuidgid plex`**; the cgroup `EPERM` is
-recast from a *risk* to the *reason for the design*; a new top-of-page "STOP HERE IF PLEX IS
-`Pending`" section and a "Plex will not schedule" procedure carry the new failure mode and the escape
-hatch. The manual-toggle section (`HardwareAcceleratedCodecs`, Settings → Transcoder, still not
-settable by any env var) is unchanged.
-
-**`apps/wave-0/plex.yaml`** — re-rendered: six hostPath lines removed, a three-line `resources` block
-added. Nothing else in `apps/` changed.
-
-### The one real regression, stated rather than sold
-
-This trades failure modes, and the new one is **worse in blast radius**:
-
-| | device/resource unavailable ⇒ |
-|---|---|
-| **Before** | `DirectoryOrCreate` mounted an empty dir; Plex ran and **silently software-transcoded**. Invisible, harmless to everything else. |
-| **After** | Plex is **Unschedulable**. `apps-wave-0` is `wait: true` and `apps-wave-1` `dependsOn` it, so this **stalls the app tier**. |
-
-It is **unavoidable**: an extended resource is a hard scheduling constraint, and it is also the only
-thing that produces the cgroup allow rule. There is no graceful-degradation variant. Plex's
-schedulability is now coupled to the `intel-gpu-plugin` DaemonSet — broken, removed, or merely not
-yet reconciled, it takes the app tier with it. That is the price of hardware transcoding working at
-all.
-
-**Escape hatch — one field, no code change:** delete the `hardware:` block from `catalog/plex.yaml`
-and re-render. Plex returns to software transcoding and the tier unblocks. It is in the contract, in
-the runbook's "Plex will not schedule → remedy B" with exact commands, and here, because it is what
-someone will need at 2am.
-
-## What I verified
-
-**The precondition, re-read from the branch rather than assumed:** the plugin is a standalone
-DaemonSet at `platform/intel-gpu-plugin/` with its own Flux Kustomization
-(`clusters/base/intel-gpu-plugin.yaml`, named `intel-gpu-plugin` in `flux-system`), namespace
-`intel-gpu-plugin`, DaemonSet `intel-gpu-plugin`, pinned `intel/intel-gpu-plugin:0.37.0`. Every
-`kubectl` command I wrote into the runbook names those exact objects. The node/DaemonSet readings
-themselves (`i915=1` on all three nodes; 3 desired / 3 ready / 3 available) were **measured by the
-PM, not by me** — see "What I did NOT verify".
-
-**`render.py --selftest`: PASS**, and every new assertion is **mutation-tested — 8/8 mutants caught**
-(a test that cannot fail is not a test):
-
-| mutant | caught by |
-|---|---|
-| `requests` instead of `limits` | exact-resources assertion |
-| emission dropped entirely | exact-resources assertion |
-| `/dev/dri` hostPath + mount re-added | hostPath-absent assertion |
-| emitted unconditionally (no `hardware` key) | no-`hardware` negative |
-| `supplementalGroups` synthesised | no-pod-`securityContext` assertion |
-| resource renamed `gpu.intel.com/xe` | exact-resources assertion |
-| quantity as the string `"1"` | exact-resources assertion |
-| limit leaked onto the oauth2-proxy sidecar | new app-container-only assertion |
-
-**Re-render is clean and scoped.** `python3 catalog/render.py --all catalog -o apps --wave-layout
--no-image-automation` then `git status --porcelain apps/` ⇒ `M apps/wave-0/plex.yaml` and nothing
-else. `git diff --stat apps/` ⇒ `1 file changed, 3 insertions(+), 6 deletions(-)` — exactly the six
-hostPath lines out, the three-line `resources` block in. **`apps/wave-1/keycloak.yaml` and
-`apps/wave-0/vm-demo.yaml` are untouched** (checked explicitly: they are git-tracked but excluded
-from the golden comparison by `RENDER_GOLDEN_NOT_ONBOARDED` in `ci/render-golden.sh`, so a spurious
-diff there would land ungated). `clusters/` is untouched; `--emit-waves` was not run.
-
-**Invariant 8 holds, mechanically checked rather than eyeballed.** `git diff -U0 catalog/plex.yaml`
-filtered to non-comment changed lines returns **empty**, and `yaml.safe_load` gives
-`hardware == {'gpu': 'intel-quicksync'}`. Zero ServiceDefinition field edits.
-
-**The gate: `rc 3` UNDETERMINED, which is this environment's calibrated best — NOT green, and I am
-not calling it green.** Run from this worktree in the pinned toolbox
-(`DEV_KUBECONFIG=/dev/null`, plus an `ENGINE` shim bind-mounting the main checkout's `.git`
-read-only, per CLAUDE.md §3; `infra/ansible/.cache/prod.kubeconfig` was **not** copied):
-
-| stage | result |
-|---|---|
-| `spec-immutability` | **SKIPPED** — spec repo not present at `/work/../home-network-k3s` (R-TEST-06 unverified) |
-| `decisions-log` | green |
-| `lint` | green |
-| `l0` | green |
-| `render-golden` | green |
-| `l1` | green |
-| `approval-policy` | green (`event='none'`, N/A off a PR event) |
-| `gitea-settings` | **SKIPPED** — `SETTINGS_API_TOKEN` unset |
-| `conformance` | **SKIPPED** — `CLUSTER_AVAILABLE != true`, L2/L3 not run |
-
-Three skips, the three expected ones; **nothing failed**. `diff base: origin/main @ 8214642d87de …
-HEAD @ 78bf68493d7d`, touched requirements resolved (`R-PLAT-02` among them), so the R-TEST-03
-coverage gate actually applied — an earlier run on the uncommitted tree reported the touched set
-"NOT DETERMINABLE (on-base)" and that is *not* the run I am quoting.
-
-## What I did NOT verify
-
-**HARDWARE TRANSCODING IS STILL NOT OBSERVED WORKING, and nothing in this branch could establish
-it.** A green gate proves the **manifest renders**, nothing more.
-
- **The `open()` test has not been re-run under the new mechanism, and cannot be until this merges
-  and Flux reconciles.** The whole case for this change is that the device plugin's
-  `DeviceSpec{… Permissions: "rw"}` produces the cgroup allow rule the hostPath could not. That is
-  read from the v0.37.0 **source**, not observed on this cluster. If the plugin does not in fact
-  deliver it here, this change buys nothing and costs schedulability.
- **The Plex-side toggle is still unset.** `HardwareAcceleratedCodecs` was **absent** from
-  `Preferences.xml` as of 2026-09-30 and nothing in this branch touches it; no env var, ConfigMap or
-  `postBuild` substitution can. It is a manual UI click, and until it happens Plex software-transcodes
-  no matter how the device arrives.
- **I did not measure the cluster at all.** `i915=1` on all three nodes and the DaemonSet's
-  3/3/3 come from the PM's brief, dated 2026-10-01. Per CLAUDE.md §2b this repo is not evidence about
-  the live platform, and neither is a handoff entry: **re-measure before relying on them** (the
-  commands are first-command #1 in the runbook). The DaemonSet was 2m15s old when read — young enough
-  that it had not been observed stable for any length of time.
- **The new failure mode has not been exercised.** "Plugin unavailable ⇒ Plex Unschedulable ⇒
-  `apps-wave-0` stalls ⇒ `apps-wave-1` blocked" is derived from `wait: true` and `dependsOn` in the
-  Flux wiring, not from a drill. The escape hatch (delete `hardware:`, re-render) is likewise
-  reasoned, not rehearsed — though it is a strict subset of the renderer path the selftest covers.
- **No L2/L3 conformance.** `CLUSTER_AVAILABLE` is unset, so the gate's runtime layer did not run
-  here and does not run in CI either. `spec-immutability` and `gitea-settings` also skipped.
- **CI's own tick, when it appears, will not distinguish rc 0 from rc 3**:
-  `.gitea/workflows/gate.yml:138` is `./ci/gate.sh || [ "$?" -eq 3 ]`. Read the stage output, not the
-  colour — and take the newest row per context from `GET /statuses/{sha}`, which appends.
- **`imagePullPolicy: Always` on `plexinc/pms-docker:latest` is still a live hazard** to the
-  cont-init-hook reasoning this feature leans on. Unchanged by this branch, recorded in the runbook's
-  floating-image caveat.
-
-### Post-merge sequence for the operator (all mutating steps are yours, not an agent's)
-
-1. Merge the PR once the gate reports. Confirm Flux applied it — compare
-   `kubectl --context k3s-prod -n flux-system get kustomization apps-wave-0
-   -o jsonpath='{.status.lastAppliedRevision}'` against the merge commit.
-2. Confirm Plex **scheduled** (this is the new risk):
-   `kubectl --context k3s-prod -n plex get pod -l app.kubernetes.io/name=plex -o wide`.
-   `Pending` ⇒ runbook "Plex will not schedule".
-3. Confirm it consumed the resource:
-   `kubectl --context k3s-prod -n plex get pod -l app.kubernetes.io/name=plex
-   -o jsonpath='{.items[0].spec.containers[0].resources.limits}'`.
-4. **The decisive test — as uid 1000, via `s6-setuidgid plex`. `rc=0` is the pass condition:**
-   `kubectl --context k3s-prod -n plex exec deploy/plex -- s6-setuidgid plex sh -c
-   'exec 3<>/dev/dri/renderD128 && echo RW-OPEN-OK || echo RW-OPEN-DENIED'`.
-   **Passing as `uid 0` is weaker evidence and must not be accepted as proof** — Plex runs as 1000,
-   and uid 0 was one of the two `EPERM`s that killed the hostPath.
-5. **Only then** the Plex UI toggle: Settings → Transcoder → "Use hardware acceleration when
-   available" (under *Show Advanced*) → Save. Then force a transcode and read Dashboard → Activity:
-   `Transcode (hw)` is the proof; plain `Transcode` is software.
-
-Step 4 failing means the plugin is not delivering the cgroup allow rule on this cluster. Do **not**
-reach for `privileged: true` (Kyverno Enforce rejects it, and uid 0 failed anyway) and do **not**
-re-add a `/dev/dri` hostPath (that is the mechanism this replaced, measured non-functional). The
-escape hatch is to delete the `hardware:` block from `catalog/plex.yaml` and re-render.
@@ -1,149 +0,0 @@
---
-date: 2026-10-02
-branch: fix/plex-quicksync-verification
-title: Hardware transcoding works — and `runbooks/plex-quicksync.md`'s verification section was wrong
---
-
-## What changed
-
-**Hardware transcoding is confirmed working on prod.** Measured 2026-10-02 from
-`Plex Media Server.log` in the running pod: `vaapi` on `/dev/dri/renderD128`
-(`Intel CoffeeLake-S GT2 [UHD Graphics 630]`), `using hardware decode accelerator vaapi`,
-`zero-copy support present`, `using zero-copy transcoding`, and
-`final decoder: vaapi, final encoder: vaapi`. VAAPI for **both** directions, zero-copy, so frames
-never round-trip through the CPU. The device-plugin mechanism from PR #37 works end to end.
-
-**And `runbooks/plex-quicksync.md`'s verification section was wrong, which is the correction this
-branch exists to publish.** The page said the Plex dashboard showing `Transcode (hw)` was "the *only*
-proof available, and nothing else will ever tell you". The operator had hardware transcoding fully
-working while **Dashboard → Activity showed nothing of the sort** — so the page's authoritative check
-was silent on a working system, and sent someone looking for a fault that did not exist. Three
-inference errors are now corrected on the page, two of them recorded as named false leads so the next
-reader does not re-walk them:
-
-1. **The dashboard is not proof.** Replaced as the primary check by Plex's own log — the grep is in
-   the page, in its **redacting** form, because `Plex Media Server.log` carries API URLs containing
-   `X-Plex-Token` (CLAUDE.md §6; a credential has been leaked into a transcript here before). The
-   page also now says explicitly that **`Plex Transcoder Statistics.log` is the wrong file** — it
-   holds XML `<Variant .../>` records, not ffmpeg output, and the name invites the mistake — and why
-   `grep -a` is required. The dashboard is **kept but demoted** to a secondary, best-effort signal,
-   with its absence stated to prove nothing.
-2. **An fd snapshot is not evidence.** A `/proc/*/fd` sweep inside the pod found no holder of
-   `renderD128` while hardware transcoding was active; transcode sessions are short and the scan
-   landed in a gap. Recorded as a documented false lead, with the reliable process-level check in its
-   place: the transcoder's **argv** (`-hwaccel`, `-hwaccel_device`, `vaapi`, `renderD128`), found via
-   `ps -eo pid,user,comm | grep -i transcoder`.
-3. **A missing preference key does not mean the setting is off.** The page told readers to treat an
-   absent `HardwareAcceleratedCodecs` in `Preferences.xml` as "never enabled". With hardware
-   acceleration demonstrably on and working, that key was **absent from all 27 attributes** while
-   `HardwareDevicePath` **was** written and the log said `hardware transcoding: enabled`. First-command
-   #4 now reads both keys and states plainly that `HardwareDevicePath` present is a positive signal,
-   absence of `HardwareAcceleratedCodecs` means nothing either way, only `="0"` is conclusive, and the
-   log settles it.
-
-Also on the page:
-
- **GID `992` is no longer presented as a number to expect.** Under the plugin the injected device
-  arrives `root:root`, so the image's `cont-init.d` hook resolves GID **`0`** and adds `plex` to the
-  **root group** — measured `Groups: 0 100 1000`, `id plex` → `groups=1000(plex),0(root),100(users)`.
-  992 was the hostPath-era host `render` GID. The page now says so, marks the root-group membership as
-  an inherent property of the plugin's `DeviceSpec` rather than a defect, and repeats that it is
-  **not** a reason to reintroduce `supplementalGroups` (still a no-op: `s6-setuidgid` rebuilds the
-  group list from `/etc/group`). The stale `Groups: 100 1000` claim in the escalation section is gone.
- **A new troubleshooting entry for legitimate per-title fallbacks**, marked as a **hypothesis**.
-  Between two fully hardware sessions, one logged `enabled, but no hardware decode accelerator found`
-  and empty final decoder/encoder. UHD 630 decodes H.264, HEVC 8/10-bit and VP9 but **not AV1** and
-  not 10-bit 4:2:2 HEVC, so the likely cause is the source file, not the platform — explicitly
-  written as a lead to check first, **not** a confirmed diagnosis of that item.
- The status is stated at the top of the page and in a rewritten provenance footer that separates the
-  2026-10-02 confirmations from the superseded 2026-09-30/2026-10-01 hostPath-era readings.
- `runbooks/README.md`'s index entry for the page was stale in the same two ways (it still described a
-  `/dev/dri` hostPath and the dashboard-only proof) and is corrected to match.
-
-Unchanged on purpose: the "STOP HERE IF PLEX IS `Pending`" section and the escape hatch (delete the
-`hardware:` block from `catalog/plex.yaml`, re-render) keep exactly their existing prominence — they
-are correct and they are the 2am material. The "no alert is possible" reasoning is also kept verbatim
-in substance: Plex declares no `metricsEndpoint`, renders no ServiceMonitor, and a fallback alert
-would be a rule evaluating against nothing.
-
-**Documentation only.** No change to `catalog/`, `schemas/`, `apps/` or `platform/`.
-
-## What I verified
-
- **Gate, in the pinned toolbox from this worktree** (`DEV_KUBECONFIG=/dev/null`, `ENGINE` shim
-  bind-mounting the main checkout's `.git`): **rc 3 UNDETERMINED**, diff base
-  `origin/main @ 948875aad37d`, with exactly the three expected skips and **no failures**. Green:
-  `decisions-log`, `lint`, `l0`, `render-golden`, `l1`, `approval-policy`. Skipped:
-  `spec-immutability` (spec repo unavailable → R-TEST-06 not verified), `gitea-settings`
-  (`SETTINGS_API_TOKEN` unset), `conformance` (`CLUSTER_AVAILABLE!=true` → L2/L3 not run).
-  Touched requirements: **R-OBS-04**, reported `UNVERIFIED` for lack of a cluster. `approval-policy`
-  passed as `N/A` locally (`event='none'`, not a `pull_request`) — it evaluates for real on the PR.
-  **rc 3 is not green**, it is the calibrated worktree result, and it is reported here as rc 3.
- **The gate was run three times, with the same rc 3 / three-skip result on each committed tip** —
-  including the final one. Worth recording from the first attempt: run *before* committing, with
-  `HEAD == origin/main`, the touched-requirement set is `NOT DETERMINABLE (on-base)` and the
-  R-TEST-03 coverage gate cannot be applied at all. Commit before gating from a fresh worktree branch.
- **`runbooks/kustomization.yaml` still carries `- plex-quicksync=plex-quicksync.md`** in the
-  `configMapGenerator` `files:` list (line 110) — checked explicitly, because without it the page
-  merges and still 404s. `README=README.md` is likewise present, which is what serves the corrected
-  index entry.
- **This change touches no `sensitive_paths`.** `infra/gitea/approval-policy.json` lists `ci/**`,
-  `.gitea/**`, `conformance/**`, `clusters/**`, `bootstrap/**`, `infra/gitea/**`,
-  `platform/kyverno/**`, `platform-config/kustomization.yaml`, `.sops.yaml`, `**/*.sops.yaml`,
-  `**/rbac.yaml`, `CLAUDE.md`. `runbooks/**` and `decisions/**` are not among them, and the
-  `approval-policy` stage passed.
- **No YAML was added or edited**, so `indent-sequences: consistent` (which blocked a sibling branch
-  today) is not in play here; `lint` passed over the full tracked YAML set regardless.
- **`DECISIONS-LOG.md` is untouched** — this handoff is its own file, per CLAUDE.md §7.
- **The PR's own CI run was read, not assumed** (PR #39, run 208, task 261, head `1677dff5688b`).
-  **It is RED, and not because of this branch.** Every stage this change could affect is green —
-  `decisions-log`, `lint`, `l0`, `render-golden`, `l1`, `approval-policy` (`approval-policy` evaluated
-  for real on the `pull_request` event and passed: no sensitive path touched). The single failure is
-  **`gitea-settings`**, quoting the measured field:
-
-      [fail]   required_approvals: DECLARED 1 but LIVE is 0
-      [fail] Gitea has DRIFTED from infra/gitea/expected-branch-protection.json.
-      [fail] MERGE GATE: BLOCKED
-
-  Every other declared setting matched (`block_admin_merge_override`, `block_on_rejected_reviews`,
-  `dismiss_stale_approvals`, `enable_status_check`, `enable_push=false`,
-  `status_check_contexts = ["gate / gate (pull_request)"]`, `runners online: 1`). So **live `main`
-  currently requires ZERO approvals**, the declaration still says 1, and with
-  `REQUIRE_GITEA_SETTINGS: "true"` in `.gitea/workflows/gate.yml` that drift **blocks every PR in
-  the repo**, not just this one. Note the shape of it: the check that would notice approvals are
-  unenforced is the check that is failing. Local branch `fix/admin-approval-override` (`616a497`,
-  "fix(ci): let an administrator merge their own green PR") looks like the in-flight work that means
-  to change the declaration. **I did not touch it** — `infra/gitea/**` is a sensitive path, needs a
-  non-author approval, and is outside this branch's documentation-only scope. It is an operator
-  decision: re-assert the protection, or change the declaration deliberately in its own PR.
- The repository-wide grep for `992` to find what else still asserts it: remaining occurrences are in
-  `catalog/plex.yaml`, `catalog/render.py`, `schemas/renderer-contract.md`,
-  `platform/intel-gpu-plugin/README.md`, `platform/intel-gpu-plugin/kustomization.yaml`, and three
-  older `decisions/` entries.
-
-## What I did NOT verify
-
- **I did not re-measure anything on the live cluster in this session.** Every platform number on the
-  page — the VAAPI/zero-copy log lines, `RW-OPEN-OK` as uid 1000, the `gpu.intel.com/i915` limits and
-  requests on the pod spec, `Groups: 0 100 1000`, `id plex`, the 27 `Preferences.xml` attributes, the
-  empty `/proc/*/fd` sweep — came to me as measurements taken earlier on 2026-10-02 and was
-  transcribed, not re-run. Per CLAUDE.md §2b, treat the page as reporting those readings rather than
-  as proof of current state; re-run the primary check before relying on it.
- **The per-title fallback cause is unverified and labelled as such.** The source codec of the title
-  that logged `no hardware decode accelerator found` was never read. The AV1 / 10-bit-4:2:2-HEVC
-  explanation is inferred from UHD 630's capability set alone.
- **Whether Plex's dashboard *ever* shows `Transcode (hw)` on this deployment is unknown.** It was
-  observed silent during working hardware transcoding; whether that is a client/version quirk, a
-  reporting bug, or something about this setup was not investigated. The page therefore demotes it
-  rather than explaining it.
- **The commands as written in the page were not executed from the page.** They are the forms that
-  were run, re-wrapped for `dev.sh`; in particular the `exec -it deploy/plex -- sh` route for the argv
-  check is noted as possibly lacking a TTY under `dev.sh run` and was not exercised in that shape.
- **Stale `992` copies outside `runbooks/` were left alone**, deliberately — scope was documentation
-  only, and `catalog/plex.yaml`, `catalog/render.py`, `schemas/renderer-contract.md` and
-  `platform/intel-gpu-plugin/` all still carry the hostPath-era `Groups: 44 100 992 1000` reading as
-  if current. `render.py --selftest` asserts around that comment, so correcting it is a real change
-  with gate consequences, not a doc edit. **That is open work.** Older `decisions/` entries also cite
-  992; those are historical records and should stay as written.
- **CI on the PR.** The branch is pushed and the PR opened; I did not watch the Gitea run report, so
-  nothing here should be read as "CI green". The only gate result I can quote is the local rc 3 above.
@@ -161,18 +161,7 @@ a *green* one no longer needs a signature that cannot exist.
 **Security-relevant changes are still reviewed** — by `ci/approval-policy.sh` against
 `approval-policy.json` `sensitive_paths`, not by this field. An administrator waives that review
 only by posting `/approve-override <reason>` on the PR: reason mandatory, permission re-checked
-live, invalidated by a new commit, and recorded by account in the gate summary.
-
-> **Post the override as a PR *review* (type "Comment"), not in the plain comment box** — until
-> the CI token is re-minted. `SETTINGS_API_TOKEN` is `[read:repository, read:admin]`, and
-> `/issues/{n}/comments` needs Gitea's *issue* scope, so Gitea answers with an error **object**
-> instead of an array and the override is invisible. Measured on PR #38 (2026-10-02): a correct,
-> fresh, well-formed override in the comment box produced `approval-policy: FAIL` reading as "no
-> approving review" — a permission failure disguised as a missing one. `/pulls/{n}/reviews` is
-> under `read:repository` and worked in the same run. The stage now reads **both** sources, names
-> which one it used, and says plainly when the comments API is unreadable. `set-ci-token.sh`
-> requests `read:issue` as of 2026-10-02, so **re-run it** and the comment box works too — token
-> scopes cannot be widened in place. Note that the
+live, invalidated by a new commit, and recorded by account in the gate summary. Note that the
 **agent account `gitea-admin` also reports permission `owner`**, so it can clear its own PRs that
 way; that is an accepted consequence of authorising by permission alone, and the route to
 narrowing it (an `override_admins` allowlist, already honoured by the code) is written down in
@@ -32,8 +32,7 @@
    "requires_reason": true,
    "authorized_permissions": ["admin", "owner"],
    "invalidated_by_new_commits": true,
-    "_how": "Post the directive at the START of a line, followed by a reason: '/approve-override <why>'. ci/approval-policy.sh resolves the poster's LIVE repo permission via /collaborators/{login}/permission and accepts the override only if it is in authorized_permissions. The overrider, the source, the timestamp and the reason are printed in the gate log and the job summary.",
-    "_where_to_post_it": "EITHER a PR REVIEW body (type 'Comment') OR the ordinary PR comment box. Prefer the REVIEW: measured 2026-10-02 on PR #38, a well-formed override in the comment box was INVISIBLE to CI, because /issues/{n}/comments sits behind Gitea's *issue* token scope and SETTINGS_API_TOKEN is minted [read:repository, read:admin]. Gitea returned an error object rather than an array, and the stage reported 'no approving review' -- a permission problem wearing the costume of a missing override. /pulls/{n}/reviews is under read:repository and was readable in the same run, so a review body is the route that works on today's token. infra/gitea/set-ci-token.sh now also requests read:issue, which makes the comment box work -- but only after that script is RE-RUN, since an existing token's scopes cannot be widened in place. The stage accepts both sources and names which one it used, so neither route is load-bearing alone.",
+    "_how": "Comment on the PR with the directive at the START of a line, followed by a reason: '/approve-override <why>'. ci/approval-policy.sh resolves the commenter's LIVE repo permission via /collaborators/{login}/permission and accepts the override only if it is in authorized_permissions. The overrider, the timestamp and the reason are printed in the gate log and the job summary.",
    "_self_override_is_allowed": "The author may override their own PR if they hold an authorized permission. That is the entire point -- with one human there is no one else -- but it means the 'a change to the gate cannot be gated by the gate' protection is, for an administrator, advisory rather than structural. It is traded for an auditable record: the waiver is an explicit act, attributed, with a stated reason, in the PR's comment history and the gate output.",
    "_known_consequence_agent_accounts": "ACCEPTED, EYES OPEN (operator decision, 2026-10-01). Authorisation is by live permission ALONE, with no allowlist of human accounts. The agent account `gitea-admin` reports permission `owner` on this repo (measured 2026-10-01), so an AGENT can clear the sensitive-path review on its own PR by posting the directive. Agents author most PRs here, so this is the broad case, not the edge case. To narrow it later without changing any logic, add an `override_admins` allowlist here and require membership in addition to the permission check -- ci/approval-policy.sh reads both from this file.",
    "_staleness": "An override is dropped unless its comment is NEWER than the PR head commit, mirroring Gitea's own dismiss_stale_approvals. An override earned at commit A therefore does not silently cover commit B; push again and you must override again."
@@ -5,23 +5,9 @@
 # The token value is NEVER printed. It goes from the token API into the secrets API and
 # nowhere else -- not to stdout, not to a file, not into an agent transcript.
 #
-# Scope: `read:repository` + `read:admin` are what ci/gitea-settings.sh needs (the rule object,
-# and the runner list). `read:issue` is for ci/approval-policy.sh, and it was MISSING — see below.
-# Gitea token scopes are coarse; grant the least that works on your version and confirm the check
-# goes green rather than assuming the scope name.
-#
-# WHY read:issue IS HERE (added 2026-10-02, measured on PR #38). ci/approval-policy.sh reads the
-# PR's comments to find an admin `/approve-override`. /issues/{n}/comments sits behind the *issue*
-# scope, which this script did not request — so Gitea answered with an error OBJECT instead of an
-# array, and a perfectly well-formed override posted in the PR comment box was invisible to CI.
-# The failure did not look like a permission problem from the outside; it looked like the override
-# had not been posted. `/pulls/{n}/files` and `/pulls/{n}/reviews` are under read:repository, which
-# is why every other part of the same stage worked and this one did not.
-#
-# The stage now accepts an override from a REVIEW body as well, so it still functions on a token
-# WITHOUT read:issue. This scope is what makes the ordinary comment box work too — the thing
-# anybody would reach for first. **Re-run this script to pick it up; an existing token's scopes
-# cannot be widened in place.**
+# Scope: `read:repository` + `read:admin` are what the check needs (the rule object, and the
+# runner list). Gitea token scopes are coarse; grant the least that works on your version and
+# confirm the check goes green rather than assuming the scope name.
 set -euo pipefail
 HOST=gitea.home.keithjackson.dev; OWNER=Home-Network; REPO=home-network-k3s-impl
 # NOT GITEA_* — Gitea reserves that prefix for secret names and returns HTTP 400
@@ -35,7 +21,7 @@ basic() { curl -sS --config <(printf 'user = "%s:%s"\n' "$U" "$P") "$@"; }

 echo "==> minting token '${NAME}' as ${U}"
 TOKEN="$(basic -X POST -H 'Content-Type: application/json' \
-  -d "{\"name\":\"${NAME}\",\"scopes\":[\"read:repository\",\"read:admin\",\"read:issue\"]}" \
+  -d "{\"name\":\"${NAME}\",\"scopes\":[\"read:repository\",\"read:admin\"]}" \
  "https://${HOST}/api/v1/users/${U}/tokens" | jq -r '.sha1 // empty')"
 [ -n "$TOKEN" ] || { echo "token creation failed (check scopes for your Gitea version)" >&2; exit 1; }
 echo "==> got a ${#TOKEN}-character token (value not shown)"
@@ -88,72 +88,3 @@ This proves the R-IDP-02 property (unauthenticated cannot reach the upstream) on
 3. Log in as a **non-platform-admins** user -> expect **403** (authenticated but not authorized).
 4. Confirm the session cookie is `.home.keithjackson.dev`-scoped (single sign-on across the other
   protected UIs).
-
-## Observability: what this component can and cannot see (measured 2026-09-30)
-
-`servicemonitor.yaml` scrapes **this namespace's** deployment and nothing else. On prod that is
-two targets, `job="oauth2-proxy"`, both `up=1`. The complete set of oauth2-proxy-specific series
-in the TSDB is:
-
-    count by (__name__) ({__name__=~"oauth2_proxy.*"})
-      oauth2_proxy_requests_in_flight => 2
-
-**The per-app gate sidecars are not scraped, and there is nothing to scrape.** Six apps run an
-`oauth2-proxy` container of their own — crafty, jackett, pihole, qbittorrent, radarr, sonarr —
-each with `--http-address=0.0.0.0:4180` and **no `--metrics-address`**, so oauth2-proxy's metrics
-listener never starts. They declare only a `http:4180` container port, no `metrics` port exists on
-their Services, and `kubectl get servicemonitors,podmonitors -A` selects none of them. Any alert
-written against `oauth2_proxy_requests_total{namespace="jackett"}` would be structurally inert.
-
-This matters because the gate's characteristic failure is invisible by construction: an
-unauthenticated **XHR** gets a `302` to Keycloak rather than a `401`, the browser follows it
-against a live SSO session with no prompt, and the call resolves **200 carrying an HTML page**
-where the app expected JSON. Nothing in the request path reports an error. On 2026-09-30 jackett
-spent a burst of requests in exactly that state, re-established a session, and lost it 26 seconds
-into a 5-minute session, while `jackett-down` sat at 1 replica available the whole time.
-
-`auth-visibility-alerts.yaml` therefore alerts on **the gap**, not on the incident:
-`OAuth2ProxyGateUnobserved` compares `kube_pod_container_info{container="oauth2-proxy"}` against
-`up{container="oauth2-proxy"}` — two already-scraped families — and names every namespace running
-a gate that nothing observes. It fires for six namespaces today and clears per-namespace as each
-one gains a scrape. `runbooks/oauth2-proxy-auth-failures.md` is the by-hand substitute meanwhile,
-and it reads the sidecar logs out of Loki (Alloy collects them; 72h retention).
-
-**To close the gap for an app**, three things are needed together, on that app's own manifest:
-`--metrics-address=0.0.0.0:44180` on the sidecar, a `metrics` containerPort plus the matching
-Service port, and a ServiceMonitor selecting it. Only then does the auth-churn rule — sustained
-`code="302"` as a share of `oauth2_proxy_requests_total`, held across a window longer than the
-session lifetime — become writable rather than decorative.
-
-### Update 2026-10-01: the listener exists; the scrape path does not
-
-PR #28 added `--metrics-address=0.0.0.0:44180` and a named `metrics` container port to the five
-fleet sidecars (jackett, radarr, sonarr, qbittorrent, pihole). `podmonitor.yaml` in this directory
-discovers them by the pod label `homelab.keithjackson.dev/auth-mode: forward-auth` — a **PodMonitor**
-rather than a ServiceMonitor because no Service exposes 44180 and adding one would mean changing the
-renderer.
-
-The endpoint is real: port-forwarded straight to the jackett pod, `/metrics` returns **http=200,
-10208 bytes**, exporting `oauth2_proxy_requests_in_flight`, `oauth2_proxy_requests_total` (with
-`code` labels) and `oauth2_proxy_response_duration_seconds`. That is verified by payload, not by the
-flag appearing in `args` — a distinction worth keeping, because the two claims came apart here.
-
-**The scrape is nevertheless dropped.** From a pod in ns `monitoring`, both `:44180` and `:4180` on
-the jackett pod time out; the shared proxy's `:44180` answers. The only difference is that ns
-`oauth2-proxy` has **no NetworkPolicy at all**, while each app namespace has a `default-deny` whose
-`policyTypes` include `Ingress` with no `ingress` rules (deny-all) plus a single CNP admitting
-`fromEntities: [ingress]` to port 4180 — the Gateway's Envoy and nothing else. Prometheus matches no
-clause.
-
-So the targets read `up == 0` and the TSDB is still empty for those namespaces. This is the same bug
-and the same fingerprint as `platform/longhorn/networkpolicy-metrics.yaml` documents for Longhorn,
-and the same narrow fix applies: ns `monitoring` → the gate pod label → TCP 44180 only. It cannot
-ship from this directory, because `oauth2-proxy` and `apps-wave-0` are **siblings** in the Flux graph
-(both `dependsOn: [platform-config]`), so a NetworkPolicy naming ns `jackett` would apply on today's
-cluster and fail on a cold rebuild. It belongs with each app's own rendered policy.
-
-Consequence for `auth-visibility-alerts.yaml`: its `unless` clause requires `up == 1`, not merely a
-present `up` series. A discovered-but-failing target publishes `up` with value 0, so the bare form
-would have cleared `OAuth2ProxyGateUnobserved` the moment the PodMonitor landed — reporting the gates
-as observed while nothing was being scraped. The unit test pins that scenario; deleting the `== 1`
-fails it and nothing else.
@@ -1,177 +0,0 @@
---
-# promtool unit tests for OAuth2ProxyGateUnobserved (platform/oauth2-proxy/auth-visibility-alerts.yaml).
-#
-# WHY. The rule is an `unless` between two aggregations over DIFFERENT metric families, and the
-# failure modes of that shape are both silent: a label that does not survive `count by` makes the
-# right-hand side match nothing (the alert fires for the scraped namespace too, i.e. permanently),
-# and a right-hand side that over-matches makes it fire for nobody (i.e. inert). Neither is
-# visible by reading the expression, and neither is visible on a live cluster where the answer
-# happens to look plausible. So all four states are pinned: fires for an unscraped namespace,
-# stays quiet for a scraped one, honours `for: 1h`, and STOPS once a scrape appears.
-#
-# HOW TO RUN. The one repo-wide harness, by the companion convention:
-#   ./infra/devcontainer/dev.sh run bash -c 'platform/monitoring/tests/run.sh platform/oauth2-proxy/auth-visibility-alerts.promtool-test.yaml'
-# promtool is pinned in infra/devcontainer/versions.env; never run it off the host PATH.
-#
-# THE SERIES BELOW ARE REAL SHAPES read off live prod Prometheus on 2026-09-30 before being
-# copied here — kube_pod_container_info as kube-state-metrics emits it (job="kube-state-metrics",
-# its own instance/pod labels, image/image_id/container_id) and `up` as the oauth2-proxy
-# ServiceMonitor emits it (endpoint="metrics", port 44180). The point of using the real shapes is
-# that `count by (namespace)` has to discard all of them; a test with tidy two-label series would
-# pass while the real expression collapsed differently.
-#
-# ASSERTIONS USE `ALERTS` RATHER THAN exp_alerts: the description annotation is long prose and
-# comparing it verbatim would couple this file to every wording change while proving nothing the
-# ALERTS series does not already prove.
-rule_files:
-  - auth-visibility-alerts.rules.yaml
-evaluation_interval: 1m
-
-tests:
-  # ---------------------------------------------------------------------------------------------
-  # 1. THE STATE PROD IS ACTUALLY IN (2026-09-30): jackett runs a gate sidecar with no scrape;
-  #    the shared oauth2-proxy namespace runs two that ARE scraped. Asserts the alert fires for
-  #    jackett and NOT for oauth2-proxy, and that `for: 1h` is honoured (pending at 59m).
-  - interval: 1m
-    name: an unscraped gate namespace fires after 1h; the scraped one never does
-    input_series:
-      - series: 'kube_pod_container_info{container="oauth2-proxy",container_id="containerd://937ae6fc",endpoint="http",image="quay.io/oauth2-proxy/oauth2-proxy:v7.8.1",image_id="quay.io/oauth2-proxy/oauth2-proxy@sha256:d62e2d81",image_spec="quay.io/oauth2-proxy/oauth2-proxy:v7.8.1",instance="10.0.1.213:8080",job="kube-state-metrics",namespace="jackett",pod="jackett-c5bfcbfb8-c75f9",service="kube-prometheus-stack-kube-state-metrics",uid="5b57d48f-e7d3-4050-9cd1-16aaaa052996"}'
-        values: '1x130'
-      # The shared instance: kube-state-metrics sees both replicas...
-      - series: 'kube_pod_container_info{container="oauth2-proxy",container_id="containerd://aa11bb22",endpoint="http",image="quay.io/oauth2-proxy/oauth2-proxy:v7.8.1",image_id="quay.io/oauth2-proxy/oauth2-proxy@sha256:d62e2d81",image_spec="quay.io/oauth2-proxy/oauth2-proxy:v7.8.1",instance="10.0.1.213:8080",job="kube-state-metrics",namespace="oauth2-proxy",pod="oauth2-proxy-7568c78795-cqz27",service="kube-prometheus-stack-kube-state-metrics",uid="1111aaaa-0000-0000-0000-000000000001"}'
-        values: '1x130'
-      - series: 'kube_pod_container_info{container="oauth2-proxy",container_id="containerd://cc33dd44",endpoint="http",image="quay.io/oauth2-proxy/oauth2-proxy:v7.8.1",image_id="quay.io/oauth2-proxy/oauth2-proxy@sha256:d62e2d81",image_spec="quay.io/oauth2-proxy/oauth2-proxy:v7.8.1",instance="10.0.1.213:8080",job="kube-state-metrics",namespace="oauth2-proxy",pod="oauth2-proxy-7568c78795-bscxg",service="kube-prometheus-stack-kube-state-metrics",uid="1111aaaa-0000-0000-0000-000000000002"}'
-        values: '1x130'
-      # ...and both replicas are genuinely scraped, so `up` carries container="oauth2-proxy" there.
-      - series: 'up{container="oauth2-proxy",endpoint="metrics",instance="10.0.1.189:44180",job="oauth2-proxy",namespace="oauth2-proxy",pod="oauth2-proxy-7568c78795-cqz27",service="oauth2-proxy"}'
-        values: '1x130'
-      - series: 'up{container="oauth2-proxy",endpoint="metrics",instance="10.0.2.47:44180",job="oauth2-proxy",namespace="oauth2-proxy",pod="oauth2-proxy-7568c78795-bscxg",service="oauth2-proxy"}'
-        values: '1x130'
-    promql_expr_test:
-      # Not yet firing at 59m — `for: 1h` has not elapsed. Guards against someone "simplifying"
-      # the hold away and turning every rollout into a page.
-      - expr: 'ALERTS{alertname="OAuth2ProxyGateUnobserved",alertstate="firing"}'
-        eval_time: 59m
-        exp_samples: []
-      - expr: 'ALERTS{alertname="OAuth2ProxyGateUnobserved",alertstate="pending",namespace="jackett"}'
-        eval_time: 59m
-        exp_samples:
-          - labels: 'ALERTS{alertname="OAuth2ProxyGateUnobserved",alertstate="pending",namespace="jackett",severity="warning"}'
-            value: 1
-      # Firing for jackett past the hold...
-      - expr: 'ALERTS{alertname="OAuth2ProxyGateUnobserved",alertstate="firing"}'
-        eval_time: 65m
-        exp_samples:
-          - labels: 'ALERTS{alertname="OAuth2ProxyGateUnobserved",alertstate="firing",namespace="jackett",severity="warning"}'
-            value: 1
-      # ...and never for the namespace that IS scraped. This is the assertion that catches an
-      # `unless` whose right-hand side stopped matching: without it, a broken rule that fires for
-      # every gate namespace would pass the test above.
-      - expr: 'ALERTS{alertname="OAuth2ProxyGateUnobserved",namespace="oauth2-proxy"}'
-        eval_time: 65m
-        exp_samples: []
-      # The count must be 1 per namespace-with-a-gate, not 1 overall: a `count by (namespace)`
-      # that lost its `by` would collapse to a single unlabelled series.
-      - expr: 'count by (namespace) (kube_pod_container_info{container="oauth2-proxy"}) unless count by (namespace) (up{container="oauth2-proxy"})'
-        eval_time: 65m
-        exp_samples:
-          - labels: '{namespace="jackett"}'
-            value: 1
-
-  # ---------------------------------------------------------------------------------------------
-  # 2. THE FIX LANDING. jackett's sidecar gains --metrics-address and a ServiceMonitor 70m in, so
-  #    `up` starts carrying container="oauth2-proxy" for namespace="jackett" under a DIFFERENT job
-  #    name than the shared proxy's. The alert must stop. This is what makes the rule a gap
-  #    tracker rather than a permanent nag, and it pins that the match is on `container`, not on
-  #    a hardcoded job="oauth2-proxy" (which would keep firing forever after a correct fix).
-  - interval: 1m
-    name: the alert clears once the sidecar is actually scraped
-    input_series:
-      - series: 'kube_pod_container_info{container="oauth2-proxy",container_id="containerd://937ae6fc",endpoint="http",image="quay.io/oauth2-proxy/oauth2-proxy:v7.8.1",image_id="quay.io/oauth2-proxy/oauth2-proxy@sha256:d62e2d81",image_spec="quay.io/oauth2-proxy/oauth2-proxy:v7.8.1",instance="10.0.1.213:8080",job="kube-state-metrics",namespace="jackett",pod="jackett-c5bfcbfb8-c75f9",service="kube-prometheus-stack-kube-state-metrics",uid="5b57d48f-e7d3-4050-9cd1-16aaaa052996"}'
-        values: '1x130'
-      # Absent for the first 70 minutes, then present. `_x` is "no sample"; the scrape did not
-      # exist yet.
-      - series: 'up{container="oauth2-proxy",endpoint="metrics",instance="10.0.1.213:44180",job="jackett-auth",namespace="jackett",pod="jackett-c5bfcbfb8-c75f9",service="jackett-auth-metrics"}'
-        values: '_x70 1x60'
-    promql_expr_test:
-      - expr: 'ALERTS{alertname="OAuth2ProxyGateUnobserved",alertstate="firing",namespace="jackett"}'
-        eval_time: 65m
-        exp_samples:
-          - labels: 'ALERTS{alertname="OAuth2ProxyGateUnobserved",alertstate="firing",namespace="jackett",severity="warning"}'
-            value: 1
-      - expr: 'ALERTS{alertname="OAuth2ProxyGateUnobserved",namespace="jackett"}'
-        eval_time: 80m
-        exp_samples: []
-
-  # ---------------------------------------------------------------------------------------------
-  # 3. THE REGRESSION GUARD FOR `== 1` — the scenario that exposed a real bug on 2026-10-01.
-  #
-  #    A target is DISCOVERED but every scrape FAILS: `up` exists with value 0. This is not
-  #    hypothetical — it is the exact state podmonitor.yaml creates today, because the app
-  #    namespaces' default-deny drops the scrape (measured; see podmonitor.yaml).
-  #
-  #    With the original `unless count by (namespace) (up{container="oauth2-proxy"})`, the `up`
-  #    SERIES EXISTS, so `count by (namespace)` returns 1, `unless` removes the namespace, and the
-  #    alert GOES QUIET while nothing is being scraped at all — a green signal standing in for an
-  #    absent one, which is the precise disease this whole rule was written to cure. Deleting the
-  #    `== 1` makes THIS test fail and every other test in this file still pass, which is the
-  #    property that makes it worth having.
-  - interval: 1m
-    name: a discovered-but-FAILING target does not count as observed (up==0 must still fire)
-    input_series:
-      - series: 'kube_pod_container_info{container="oauth2-proxy",container_id="containerd://937ae6fc",endpoint="http",image="quay.io/oauth2-proxy/oauth2-proxy:v7.8.1",image_id="quay.io/oauth2-proxy/oauth2-proxy@sha256:d62e2d81",image_spec="quay.io/oauth2-proxy/oauth2-proxy:v7.8.1",instance="10.0.1.213:8080",job="kube-state-metrics",namespace="jackett",pod="jackett-6877fcd9f5-ht9d9",service="kube-prometheus-stack-kube-state-metrics",uid="5b57d48f-e7d3-4050-9cd1-16aaaa052996"}'
-        values: '1x130'
-      # The PodMonitor target exists and never succeeds: NetworkPolicy drops the packets, so the
-      # scrape times out and `up` is published as 0 rather than going absent.
-      - series: 'up{container="oauth2-proxy",endpoint="metrics",instance="10.0.0.189:44180",job="oauth2-proxy-sidecars",namespace="jackett",pod="jackett-6877fcd9f5-ht9d9"}'
-        values: '0x130'
-    promql_expr_test:
-      - expr: 'ALERTS{alertname="OAuth2ProxyGateUnobserved",alertstate="firing",namespace="jackett"}'
-        eval_time: 65m
-        exp_samples:
-          - labels: 'ALERTS{alertname="OAuth2ProxyGateUnobserved",alertstate="firing",namespace="jackett",severity="warning"}'
-            value: 1
-      # And the inner clause itself yields NOTHING while the scrape is failing — which is the
-      # mechanism the alert depends on, asserted directly so a future reader can see why the
-      # `== 1` matters without re-deriving it. (Scenario 4 below covers the other direction:
-      # a succeeding scrape really does clear the alert, so `== 1` has not made the rule
-      # impossible to satisfy.)
-      - expr: 'count by (namespace) (up{container="oauth2-proxy"} == 1)'
-        eval_time: 65m
-        exp_samples: []
-
-  # ---------------------------------------------------------------------------------------------
-  # 4. A FLAPPING target: up goes 1 -> 0 and stays there. The alert must come BACK, not latch
-  #    cleared. Covers the ordering bug where a once-observed namespace is permanently excluded.
-  - interval: 1m
-    name: a target that starts working and then fails re-fires
-    input_series:
-      - series: 'kube_pod_container_info{container="oauth2-proxy",container_id="containerd://937ae6fc",endpoint="http",image="quay.io/oauth2-proxy/oauth2-proxy:v7.8.1",image_id="quay.io/oauth2-proxy/oauth2-proxy@sha256:d62e2d81",image_spec="quay.io/oauth2-proxy/oauth2-proxy:v7.8.1",instance="10.0.1.213:8080",job="kube-state-metrics",namespace="radarr",pod="radarr-7d55cbffb9-42hmh",service="kube-prometheus-stack-kube-state-metrics",uid="3333cccc-0000-0000-0000-000000000001"}'
-        values: '1x250'
-      # Healthy for the first 60m, then every scrape fails for the rest.
-      - series: 'up{container="oauth2-proxy",endpoint="metrics",instance="10.0.1.77:44180",job="oauth2-proxy-sidecars",namespace="radarr",pod="radarr-7d55cbffb9-42hmh"}'
-        values: '1x60 0x180'
-    promql_expr_test:
-      # Quiet while it was working.
-      - expr: 'ALERTS{alertname="OAuth2ProxyGateUnobserved",namespace="radarr"}'
-        eval_time: 55m
-        exp_samples: []
-      # Firing again an hour after it broke.
-      - expr: 'ALERTS{alertname="OAuth2ProxyGateUnobserved",alertstate="firing",namespace="radarr"}'
-        eval_time: 125m
-        exp_samples:
-          - labels: 'ALERTS{alertname="OAuth2ProxyGateUnobserved",alertstate="firing",namespace="radarr",severity="warning"}'
-            value: 1
-
-  # ---------------------------------------------------------------------------------------------
-  # 5. NO GATE, NO ALERT. A namespace with no oauth2-proxy container must never appear, or the
-  #    rule would page for every app on the platform the day someone widened the matcher.
-  - interval: 1m
-    name: namespaces without a gate sidecar are never reported
-    input_series:
-      - series: 'kube_pod_container_info{container="plex",container_id="containerd://feed0001",endpoint="http",image="ghcr.io/example/plex:1",image_id="ghcr.io/example/plex@sha256:feed0001",image_spec="ghcr.io/example/plex:1",instance="10.0.1.213:8080",job="kube-state-metrics",namespace="plex",pod="plex-0",service="kube-prometheus-stack-kube-state-metrics",uid="2222bbbb-0000-0000-0000-000000000001"}'
-        values: '1x130'
-    promql_expr_test:
-      - expr: 'ALERTS{alertname="OAuth2ProxyGateUnobserved"}'
-        eval_time: 65m
-        exp_samples: []
@@ -1,137 +0,0 @@
---
-# oauth2-proxy AUTH-VISIBILITY alerting (R-OBS-04).
-#
-# ============================================================================================
-# WHY THIS FILE EXISTS — THE 2026-09-30 JACKETT FAILURE THAT NOTHING OBSERVED
-# ============================================================================================
-# Jackett's UI stopped working. Reloading never fixed it and the user was never re-prompted to
-# log in. The sidecar's own access log had the whole story:
-#
-#   [oauthproxy.go:1026] No valid authentication in request. Initiating login.
-#   GET "/api/v2.0/indexers/yts/config?_=..."          HTTP/1.1 ... 302 400
-#   GET "/api/v2.0/indexers/thepiratebay/config?_=..." HTTP/1.1 ... 302 409
-#   ... ten of these at 15:30:53, then a fresh [AuthSuccess] at 15:31:06,
-#   then "No valid authentication in request" again 26 SECONDS LATER, inside the same session.
-#
-# NOTHING ANYWHERE ELSE RECORDED IT. oauth2-proxy answers an unauthenticated XHR with a 302 to
-# Keycloak rather than a 401; the browser follows it silently, the live SSO session satisfies it
-# without a prompt, and the XHR resolves 200 carrying a 44 KB HTML dashboard where the app's
-# JavaScript wanted JSON. From the browser, from the user, and from any uptime check, the service
-# is healthy. `jackett-down` (apps/wave-0/jackett.yaml) watches
-# kube_deployment_status_replicas_available, which was 1 throughout and would have been 1 if the
-# gate had rejected every request ever made.
-#
-# ============================================================================================
-# WHY THIS FILE DOES NOT CONTAIN THE OBVIOUS ALERT — MEASURED, prod, 2026-09-30
-# ============================================================================================
-# The alert you would want is "a gated app is serving a sustained rate of auth redirects to a
-# user who is already authenticated". It is NOT WRITABLE against this cluster's TSDB, and the
-# reason is this file's real subject:
-#
-#   THE PER-APP GATE SIDECARS EXPORT NO METRICS AT ALL.
-#
-#   $ promtool query instant :9090 'count by (__name__) ({__name__=~"oauth2_proxy.*"})'
-#     oauth2_proxy_requests_in_flight => 2          <- the SHARED proxy's two replicas. That is ALL.
-#
-#   PARTLY SUPERSEDED 2026-10-01, and the correction matters more than the original. PR #28 gave
-#   the five FLEET sidecars `--metrics-address=0.0.0.0:44180` and a named `metrics` port, and the
-#   endpoint genuinely serves (verified by payload: http=200, 10208 bytes, all three
-#   `oauth2_proxy_*` families present — not merely by the flag being in `args`). podmonitor.yaml
-#   in this directory now discovers them. But the scrape is still DROPPED by the app namespaces'
-#   default-deny ingress, so the TSDB remains empty for those namespaces; and crafty still has no
-#   metrics listener at all. The rule below is unchanged in purpose and still has work to do.
-#
-#   Every sidecar (crafty, jackett, pihole, qbittorrent, radarr, sonarr) ran with
-#   `--http-address=0.0.0.0:4180` and NO `--metrics-address`, so oauth2-proxy's metrics listener
-#   was never started; the container declared only port `http:4180`, there was no `metrics` port on
-#   any of their Services, and there was no ServiceMonitor or PodMonitor for any of them anywhere
-#   in the cluster (measured: `kubectl get servicemonitors,podmonitors -A`). Six gates, zero
-#   telemetry. An alert written against `oauth2_proxy_requests_total{namespace="jackett"}` would
-#   have been PERMANENTLY INERT — present, evaluating, silent, and indistinguishable from health.
-#   This repo has shipped that mistake before (VeleroNoRecentBackup, the Longhorn rules), which is
-#   why `conformance/tests/l0-static/alert-metrics-have-scrape-targets` exists, and why the
-#   temptation was refused here rather than ratcheted into a register.
-#
-#   The SHARED proxy IS scraped (job="oauth2-proxy", 2 targets, up=1) but it is not in the data
-#   path for any sidecar-gated app — each app gates itself — and its current pods export no
-#   `oauth2_proxy_requests_total` at all, having proxied nothing since they started. An alert on
-#   the shared instance would not have fired on this incident either. Saying so is the point.
-#
-# So this file alerts on the CONDITION THAT MADE THE INCIDENT INVISIBLE, not on the incident.
-# That condition is measurable today, from two already-scraped metric families, and it is the
-# precondition for ever being able to alert on the incident itself. It self-clears the moment a
-# sidecar gains a metrics endpoint and a scrape — at which point the auth-churn rule becomes
-# writable and belongs here beside it. See runbooks/oauth2-proxy-auth-failures.md, which is the
-# by-hand equivalent an operator uses in the meantime.
-apiVersion: monitoring.coreos.com/v1
-kind: PrometheusRule
-metadata:
-  name: oauth2-proxy-auth-visibility
-  namespace: oauth2-proxy
-  labels:
-    release: kube-prometheus-stack     # kube-prometheus-stack's ruleSelector
-    app.kubernetes.io/name: oauth2-proxy
-spec:
-  groups:
-    - name: oauth2-proxy.auth-visibility
-      rules:
-        - alert: OAuth2ProxyGateUnobserved
-          # A namespace runs an oauth2-proxy gate container, and Prometheus holds no scrape
-          # target for that container in that namespace.
-          #
-          # BOTH SIDES ARE ALREADY-SCRAPED FAMILIES, deliberately:
-          #   * kube_pod_container_info  — kube-state-metrics, the declared owner in
-          #     alert-metrics-have-scrape-targets. It sees the container whether or not the
-          #     container exports anything, which is exactly the property needed here.
-          #   * up                       — UNIVERSAL. `up` carries the `container` label for any
-          #     ServiceMonitor/PodMonitor target, so this works for a future per-app scrape
-          #     without knowing what job name it will pick.
-          # Nothing in this expression touches `oauth2_proxy_*`, so the rule cannot itself be
-          # inert for the reason it is reporting.
-          #
-          # MEASURED ON PROD 2026-09-30 — this expression returned six namespaces:
-          #   {namespace="crafty"} {namespace="jackett"} {namespace="pihole"}
-          #   {namespace="qbittorrent"} {namespace="radarr"} {namespace="sonarr"}
-          # and excluded namespace="oauth2-proxy", whose two replicas ARE scraped. It fires on
-          # the state the cluster is in; it is not a rule waiting for a hypothetical.
-          #
-          # `== 1` IS LOAD-BEARING, AND IT IS A BUG FIX (2026-10-01). This clause was originally
-          # a bare `up{container="oauth2-proxy"}`, which was WRONG in the one way that matters
-          # here: a target that is DISCOVERED BUT FAILING still publishes `up`, with value 0. So
-          # the series exists, `count by (namespace)` returns 1, `unless` removes the namespace,
-          # and the alert GOES QUIET while nothing whatsoever is being scraped. That is this
-          # branch's own disease — a green signal standing in for an absent one — reproduced
-          # inside the alert written to cure it. It was not hypothetical: podmonitor.yaml lands
-          # five targets whose scrape is DROPPED by NetworkPolicy (measured; see that file), so
-          # the bare form would have silently cleared on the very next commit. `== 1` means
-          # "observed" requires a scrape that actually succeeds.
-          #
-          # A failing target is therefore reported by BOTH this rule and kube-prometheus-stack's
-          # generic TargetDown. That duplication is deliberate: TargetDown says "a target is
-          # down", this says "an authentication gate is unobserved", and during an incident those
-          # are different sentences. The overlap is the cheap half of the trade.
-          expr: |
-            count by (namespace) (kube_pod_container_info{container="oauth2-proxy"})
-              unless
-            count by (namespace) (up{container="oauth2-proxy"} == 1)
-          # 1h, not 5m: a rollout briefly has a running sidecar whose target has not been
-          # discovered yet, and this condition is a standing architectural gap, never an
-          # emergency. Long enough that no deploy can produce it.
-          for: 1h
-          labels:
-            severity: warning
-          annotations:
-            summary: "oauth2-proxy gate in {{ $labels.namespace }} exports no metrics"
-            description: >-
-              The {{ $labels.namespace }} namespace runs an oauth2-proxy gate container and
-              Prometheus has NO scrape target for it, so every authentication decision that gate
-              makes — every redirect to Keycloak, every 403 on a group check, every session that
-              silently fails to hold — is invisible to metrics and to alerting. This is not a
-              theoretical gap: on 2026-09-30 the jackett gate answered a burst of the app's own
-              XHR calls with 302s to Keycloak, re-established a session, and lost it again 26
-              seconds later, and the only record anywhere was a line in the sidecar's stdout.
-              No alert could have fired, because there is nothing to alert on. Until a scrape
-              exists the runbook's LogQL queries are the substitute; the fix is
-              `--metrics-address=0.0.0.0:44180` on the sidecar plus a `metrics` port and a
-              ServiceMonitor, after which the auth-churn rule becomes writable.
-            runbook_url: "https://${BASE_DOMAIN}/runbooks/oauth2-proxy-auth-failures"
@@ -14,12 +14,3 @@ resources:
  - oauth2-proxy-credentials.sops.yaml
  - httproute.yaml       # forward-auth sign-in/callback ingress (was referenced in-place by platform-config)
  - servicemonitor.yaml  # Prometheus scrape (was referenced in-place by platform-config)
-  # Alerting on whether the gates are OBSERVABLE at all. Travels with the servicemonitor above
-  # for the same reason it does: monitoring.coreos.com CRDs are registered by the `platform`
-  # tier, which is Ready before this tier's platform-config dependency completes.
-  - auth-visibility-alerts.yaml
-  # Discovers the PER-APP gate sidecars' :44180 metrics endpoints by pod label (PR #28 added the
-  # listener; no Service exposes it, so this is a PodMonitor, not a ServiceMonitor). The scrape is
-  # still denied by the app namespaces' default-deny ingress — read podmonitor.yaml's header
-  # before concluding the targets should be up.
-  - podmonitor.yaml
@@ -1,109 +0,0 @@
---
-# PodMonitor for the PER-APP oauth2-proxy gate sidecars (R-OBS-04).
-#
-# ============================================================================================
-# WHY A PodMonitor AND NOT A ServiceMonitor
-# ============================================================================================
-# PR #28 gave all five fleet sidecars `--metrics-address=0.0.0.0:44180` and a named `metrics`
-# container port. It did NOT add a Service port, and measured on prod 2026-10-01 none of the five
-# Services exposes 44180:
-#
-#   jackett      jackett:     [('port-9117', 9117), ('authproxy', 4180)]
-#   radarr       radarr:      [('port-7878', 7878), ('authproxy', 4180)]
-#   sonarr       sonarr:      [('port-8989', 8989), ('authproxy', 4180)]
-#   qbittorrent  qbittorrent: [('port-8080', 8080), ('authproxy', 4180)]
-#   pihole       pihole:      [('port-80',     80), ('authproxy', 4180)]
-#
-# A ServiceMonitor selects Service PORTS, so it would have nothing to select. A PodMonitor targets
-# pod ports directly and bypasses Services entirely — so this needs no change to the Services, and
-# therefore no change to `catalog/render.py` or the `apps/wave-*` renders and goldens.
-#
-# SELECTOR: the `homelab.keithjackson.dev/auth-mode: forward-auth` POD LABEL, not a namespace list.
-# Measured 2026-10-01: that label is present on exactly the five fleet gate pods (jackett, radarr,
-# sonarr, qbittorrent, pihole) and absent from crafty's, which is a separately-managed deployment
-# (platform/crafty) that still has no `--metrics-address` at all. So the selector describes the
-# PROPERTY being scraped rather than enumerating today's apps, and a sixth forward-auth app is
-# picked up with no edit here. `namespaceSelector.any: true` because those five namespaces are
-# created by the apps-wave-0/1 tiers, which this tier does not and must not depend on.
-#
-# ============================================================================================
-# READ THIS BEFORE BELIEVING THE TARGETS ARE UP: THE SCRAPE IS CURRENTLY DENIED BY NETWORKPOLICY
-# ============================================================================================
-# This PodMonitor is NECESSARY AND NOT SUFFICIENT. The endpoint serves, and the path from ns
-# monitoring is blocked. Both halves measured on prod 2026-10-01, read-only:
-#
-#   THE ENDPOINT IS HEALTHY — port-forward straight to the jackett pod's 44180:
-#     GET /metrics -> http=200 bytes=10208
-#     # TYPE oauth2_proxy_requests_in_flight gauge
-#     # TYPE oauth2_proxy_requests_total counter
-#     # TYPE oauth2_proxy_response_duration_seconds histogram
-#     oauth2_proxy_requests_total{code="200"} 3
-#     oauth2_proxy_requests_total{code="302"} 2
-#
-#   THE SCRAPE PATH IS DROPPED — from a pod in ns monitoring (grafana, which sits beside
-#   Prometheus and so occupies the same policy position) to the jackett pod IP:
-#     http://10.0.0.189:44180/metrics   -> wget: download timed out
-#     http://10.0.0.189:4180/ping       -> wget: download timed out     (even the "allowed" port)
-#     http://<shared-proxy>:44180/metrics -> 200, oauth2_proxy_* present (control: ns oauth2-proxy
-#                                            has NO NetworkPolicy, which is the only reason the
-#                                            shared instance has ever been scrapable)
-#
-#   WHY: ns jackett's `default-deny` NetworkPolicy is `podSelector: {}` with
-#   `policyTypes: [Ingress, Egress]` and an `egress` rule ONLY — no `ingress` key, which in
-#   NetworkPolicy semantics is deny-all-ingress. The only ingress allowance is the CNP
-#   `jackett-allow-gateway-ingress`: `fromEntities: [ingress]` to port 4180 — the Gateway's Envoy
-#   and nothing else. Prometheus matches no clause and its packets are dropped, not refused.
-#
-# SO THE TARGETS BELOW WILL READ `up == 0` UNTIL AN INGRESS ALLOWANCE LANDS. That is a known,
-# measured, documented state — NOT a regression introduced here, and NOT something to silence.
-# It is deliberately left visible: `OAuth2ProxyGateUnobserved` in auth-visibility-alerts.yaml
-# requires `up == 1`, precisely so a discovered-but-failing target does not read as "observed"
-# (see that file's header — this exact trap is why the `== 1` is there).
-#
-# THIS IS THE SAME BUG LONGHORN HAD, and the platform has a documented fix idiom for it:
-# platform/longhorn/networkpolicy-metrics.yaml, whose header records the identical fingerprint
-# measured on 2026-09-13 — ServiceMonitor in place, 3 targets DISCOVERED, `up` 0/0/0, TSDB empty,
-# `lastError: context deadline exceeded` (a drop, not a refusal). The fix there is a narrow
-# additive `networking.k8s.io/v1` NetworkPolicy: ns monitoring -> the pod label, that one port.
-#
-# WHY THAT POLICY IS NOT IN THIS DIRECTORY. It would have to be five objects, one per app
-# namespace, and those namespaces are created by apps-wave-0/1. Measured Flux graph, 2026-10-01:
-#   oauth2-proxy  dependsOn=['platform-config']        <- this tier
-#   apps-wave-0   dependsOn=['platform-config']        <- SIBLING, no ordering between them
-#   apps-wave-1   dependsOn=['apps-wave-0']
-# They are siblings, so on a cold bootstrap there is no guarantee ns jackett exists when this tier
-# applies, and a NetworkPolicy naming a missing namespace fails to apply. It would work on today's
-# running cluster and break on a rebuild — the "works now, broken on restore" shape this repo
-# keeps paying for. Longhorn's precedent is safe only because longhorn-system is created by the
-# same tier that ships its policy. The allowance therefore belongs WITH THE APPS, rendered next to
-# the rest of each app's network policy — i.e. in the catalog/renderer, which is in flight on
-# another branch. Tracked in the handoff; it is one narrow rule per app, not a redesign.
-apiVersion: monitoring.coreos.com/v1
-kind: PodMonitor
-metadata:
-  name: oauth2-proxy-sidecars
-  namespace: oauth2-proxy
-  labels:
-    release: kube-prometheus-stack     # kube-prometheus-stack's podMonitorSelector
-    app.kubernetes.io/name: oauth2-proxy
-    homelab.keithjackson.dev/purpose: metrics-scrape
-spec:
-  namespaceSelector:
-    # The gate sidecars live in the app namespaces, not this one. `any` rather than a fixed list so
-    # a new forward-auth app needs no edit here — the pod label below is what scopes this.
-    any: true
-  selector:
-    matchLabels:
-      # The PROPERTY, not the app list. Present on exactly the five fleet gate pods (measured
-      # 2026-10-01); absent from crafty, which has no metrics listener yet.
-      homelab.keithjackson.dev/auth-mode: forward-auth
-  podMetricsEndpoints:
-    # By PORT NAME (`metrics`, 44180), never by number: the name is what PR #28 declared on the
-    # container, and a numeric port here would silently stop matching if the port were renumbered.
-    - port: metrics
-      path: /metrics
-      interval: 30s
-      # 10s, matching the drop signature above: a DENIED path does not refuse, it hangs until the
-      # scrape times out. Leaving the default would make each failing target hold a scrape slot for
-      # the full interval.
-      scrapeTimeout: 10s
@@ -51,36 +51,6 @@ rule groups still evaluate against nothing and **cannot fire**:
 | Flux (`gotk_*`) | `FluxReconciliationFailure`, `FluxResourceSuspended`, `ImageUpdateAutomationFailing`, `ImagePolicyStalled`, `UpdateHealthGateFailed` |
 | Hubble (`hubble_drop_total`) | `HubbleDeniedFlowSpike` |
 | etcd (`kubeEtcd` disabled for k3s, deliberately) | no etcd fsync alerting exists at all |
-| per-app oauth2-proxy sidecars (`oauth2_proxy_*`) — updated 2026-10-01 | no authentication alerting exists at all for crafty, jackett, pihole, qbittorrent, radarr, sonarr |
-
-The oauth2-proxy row is the newest, and it has **moved twice in two days** — worth reading in order,
-because each step looked like the end of it.
-
-**2026-09-30 — nothing to scrape.** `count by (__name__) ({__name__=~"oauth2_proxy.*"})` returned
-exactly one family, `oauth2_proxy_requests_in_flight`, from the two replicas of the **shared**
-forward-auth instance. All six per-app gate sidecars ran without `--metrics-address`, so their metrics
-listener never started, and no ServiceMonitor or PodMonitor selected them.
-
-**2026-10-01 — the listener exists, and the scrape is still blocked.** PR #28 added
-`--metrics-address=0.0.0.0:44180` and a named `metrics` port to the five fleet sidecars, and the
-endpoint genuinely serves (port-forwarded: `http=200`, 10208 bytes, all three `oauth2_proxy_*`
-families, `oauth2_proxy_requests_total{code="302"}` present). `platform/oauth2-proxy/podmonitor.yaml`
-now discovers them by pod label. **But the app namespaces' `default-deny` NetworkPolicy drops the
-scrape**: from a pod in ns `monitoring`, both `:44180` and `:4180` on the jackett pod time out, while
-the shared proxy's `:44180` answers — the only difference being that ns `oauth2-proxy` has no
-NetworkPolicy at all. So the targets are discovered and `up == 0`, and the TSDB is still empty for
-those namespaces. **This is the same bug Longhorn had**, with the same fingerprint; the fix idiom is
-`platform/longhorn/networkpolicy-metrics.yaml` (ns monitoring → one pod label → one port), and for
-these apps it has to be rendered alongside each app's own policy rather than shipped from the
-oauth2-proxy tier, which is a *sibling* of `apps-wave-0` in the Flux graph and so cannot rely on those
-namespaces existing yet.
-
-`OAuth2ProxyGateUnobserved` (`platform/oauth2-proxy/auth-visibility-alerts.yaml`) alerts on the gap
-itself from `kube_pod_container_info` and `up` — two families that *are* scraped. Note its `up == 1`:
-a discovered-but-failing target publishes `up` with value **0**, so the earlier bare form would have
-gone quiet the moment the PodMonitor landed, while nothing was being scraped. That near-miss is the
-whole reason to distrust a cleared alert here. Crafty remains outside all of this — no metrics
-listener at all. See `oauth2-proxy-auth-failures`.

 Each affected runbook says so on its own page and gives the by-hand equivalent. See `targets-down`.

@@ -138,14 +108,6 @@ Each affected runbook says so on its own page and gives the by-hand equivalent.
 - **`keycloak-db`** — Keycloak's CloudNativePG database is unavailable.
 - **`keycloak-client-secrets`** — the client/URL reconciler failing or silent. The 2026-09-06 lockout that
  every green signal missed.
- **`oauth2-proxy-auth-failures`** — a gated app "is up but does not work". Linked from
-  `OAuth2ProxyGateUnobserved`. The gate answers an unauthenticated **XHR** with a 302 to Keycloak
-  rather than a 401, the browser follows it silently against a live SSO session, and the call
-  resolves **200 carrying HTML** where the app's JavaScript wanted JSON — so the user is never
-  re-prompted and every uptime check stays green. Tells the gate's refusal from the group check
-  from the app's own login, from the sidecar log and from Loki, with the 2026-09-30 jackett trace
-  as the worked example. **Read the caveat**: the per-app gate sidecars export no metrics at all,
-  so these logs (72h of them) are the only record this class of failure leaves.

 ### Operator procedures (no alert links here)
 - **`plex-claim`** — claiming the Plex Media Server. **Claimed 2026-09-29**; the page now only
@@ -153,18 +115,14 @@ Each affected runbook says so on its own page and gives the by-hand equivalent.
  plex.tv/claim — so it is a timed sequence, scripted as `infra/plex/claim-ship.sh`:
  token → `sops` → PR → gate → merge → **forced** `flux reconcile` → pod roll (~2m45s measured).
  Includes why a changed Secret does not restart anything, and why an expired token is harmless.
- **`plex-quicksync`** — hardware transcoding on the host iGPU. **Confirmed working 2026-10-02**
-  (VAAPI decode *and* encode, zero-copy). GitOps requests `gpu.intel.com/i915` on the pod
-  (`hardware.gpu: intel-quicksync`, satisfied by the `intel-gpu-plugin` DaemonSet — a `/dev/dri`
-  hostPath was measured not to work: device-cgroup `EPERM`); **a human still has to tick Settings →
-  Transcoder → "Use hardware acceleration when available"**, and no environment variable can do it
-  (the image supports no `PLEX_PREFERENCE*`, verified). **The proof is `Plex Media Server.log`'s
-  `final decoder: / final encoder:` line, not the Plex dashboard** — the dashboard showed nothing
-  while hardware transcoding was working, so its silence proves nothing; the page carries the
-  redacting grep (`X-Plex-Token` lives in that log), the WRONG log file to avoid, and two more
-  documented false leads (an empty `/proc/*/fd` scan, and a missing `HardwareAcceleratedCodecs` key).
-  Plex renders no ServiceMonitor, so no alert could ever fire. Also: **`Pending` stalls the whole app
-  tier** and its one-field escape hatch, and why a `:latest` pull can silently break it.
+- **`plex-quicksync`** — hardware transcoding on the host iGPU. GitOps puts `/dev/dri` in the pod
+  (`hardware.gpu: intel-quicksync`); **a human still has to tick Settings → Transcoder → "Use hardware
+  acceleration when available"**, and no environment variable can do it (the image supports no
+  `PLEX_PREFERENCE*`, verified). The page names the real preference key (`HardwareAcceleratedCodecs`,
+  read out of the binary), says which widely-cited key **does not exist**, and is explicit that the
+  **only** proof is `Transcode (hw)` on the Plex dashboard — Plex renders no ServiceMonitor, so no
+  alert could ever fire. Also: the device-cgroup failure to expect first and its device-plugin
+  fallback, and why a `:latest` pull can silently break it.
 - **`oauth2-proxy-session`** — a gated UI loads but its saves quietly do nothing, and you are never
  re-prompted to log in. Tells the three stacked auth layers apart from the sidecar's own access log
  (the four lines that matter, including the upstream `-` that means the proxy answered a request the
@@ -85,17 +85,10 @@ configMapGenerator:
      - node-io=node-io.md
      - node-memory=node-memory.md
      - node-memory-swap=node-memory-swap.md
-      # Linked from OAuth2ProxyGateUnobserved, and the diagnostic procedure for any gated app
-      # that "is up but does not work" — the gate answers an unauthenticated XHR with a 302,
-      # not a 401, so the failure arrives as an HTTP 200 carrying the wrong body.
-      - oauth2-proxy-auth-failures=oauth2-proxy-auth-failures.md
      # Operator procedure, not alert-linked. Reading the per-app oauth2-proxy sidecar log to tell
      # Keycloak, the sidecar and the app's own login apart. Cookie collision between two sidecars
      # presents as random session loss in ONE app's log and is only legible with both side by side,
      # so the page has to be reachable at 3am without going looking for it in git.
-      # SIBLING PAGE to oauth2-proxy-auth-failures above, and they are deliberately both here: this
-      # one is the SESSION-LIFECYCLE procedure (why a session died), that one is the DIAGNOSTIC
-      # TRIAGE (which of the three layers refused, and how to tell a 302-to-200 from a real success).
      - oauth2-proxy-session=oauth2-proxy-session.md
      # Operator procedure, not an alert page (no alert links to it — the
      # alert-runbooks-resolvable check treats that as advisory). It is served
@@ -1,244 +0,0 @@
-# oauth2-proxy auth failures — telling the three layers apart
-
-Linked from `OAuth2ProxyGateUnobserved`, and the page to open whenever a gated app "is up but
-does not work": a UI that loads and then shows nothing, a page that never finishes, a list that
-stays empty, a save that silently does not save. The alert is about the *visibility* gap; this
-page is the diagnostic procedure, and it works whether or not the alert ever fired.
-
-## What this means here
-
-Every app behind Keycloak on this platform has **three** places a request can be refused, and
-from a browser they look identical — because two of the three answer with **HTTP 200**.
-
-| Layer | What refuses | What the browser sees |
-|---|---|---|
-| 1. The gate (oauth2-proxy sidecar) | no valid session cookie | **302 to Keycloak**, then usually **200** |
-| 2. The gate's group check | session valid, wrong group | 403, or a redirect loop |
-| 3. The app itself | the app's own login / API key | the app's own 401 or login page |
-
-**Layer 1 is the one that hides.** oauth2-proxy answers an unauthenticated request with a
-redirect, not a 401 — correct for a browser navigation, disastrous for an **XHR**. The app's
-JavaScript asks for JSON, the gate answers `302`, the browser follows it silently, the live
-Keycloak SSO session satisfies it with no prompt, and the XHR resolves **200 with an HTML
-dashboard in the body**. `fetch()` sees a success. The user sees an empty page. Reloading does
-nothing, and nobody is ever asked to log in, because from the browser's point of view nothing
-failed.
-
-The worked example, jackett on 2026-09-30, straight from the sidecar log:
-
-    [oauthproxy.go:1026] No valid authentication in request. Initiating login.
-    GET "/api/v2.0/indexers/yts/config?_=..."          HTTP/1.1 ... 302 400
-    GET "/api/v2.0/indexers/thepiratebay/config?_=..." HTTP/1.1 ... 302 409
-    ... ten of these at 15:30:53
-    [AuthSuccess] Authenticated via OAuth2: Session{email:... created:2026-09-30 15:31:06
-                  expires:2026-09-30 15:36:06 refresh_token:true groups:[platform-admins]}
-    GET "/UI/Dashboard"        200 44379
-    GET "/api/v2.0/indexers?_=..." 200 1501229
-    ... and 26 seconds later, inside that same 5-minute session:
-    [oauthproxy.go:1026] No valid authentication in request. Initiating login.
-
-A session created at 15:31:06, valid until 15:36:06, not honoured at 15:31:32. That is the
-signature of the session being **re-established over and over instead of held** — a cookie that
-another proxy is overwriting, or a cookie that never comes back at all — not of Keycloak being
-down and not of the app being broken.
-
-**Read this before you trust any silence (updated 2026-10-01).** The five fleet gate sidecars now
-*do* run a metrics listener on `:44180`, and `platform/oauth2-proxy/podmonitor.yaml` discovers
-them — but **the scrape is dropped by the app namespaces' `default-deny` NetworkPolicy**, so those
-targets read `up == 0` and the TSDB holds nothing for them. Crafty has no listener at all. Only
-the shared `oauth2-proxy` namespace instance is genuinely scraped, and it is not in the data path
-for any of these apps. So there is still nothing to graph and nothing that could have alerted.
-**The logs below remain the only record that this class of failure happened.** Check which state
-you are in before you trust a quiet dashboard — "First commands" step 1 tells you in one query.
-
-## First commands
-
-`kubectl` does not exist on the workstation; everything runs in the pinned container, and always
-with an explicit context.
-
-**1. Which namespaces have an unobserved gate** (this is what the alert measures):
-
-```
-infra/devcontainer/dev.sh run bash -c \
-  'kubectl --context k3s-prod -n monitoring exec prometheus-kube-prometheus-stack-prometheus-0 \
-     -c prometheus -- /bin/promtool query instant http://localhost:9090 \
-     "count by (namespace) (kube_pod_container_info{container=\"oauth2-proxy\"}) unless count by (namespace) (up{container=\"oauth2-proxy\"} == 1)"'
-```
-
-**1b. If a namespace is listed, is it "no target" or "target failing"?** The two need different
-fixes and the alert deliberately does not distinguish them:
-
-```
-infra/devcontainer/dev.sh run bash -c \
-  'kubectl --context k3s-prod -n monitoring exec prometheus-kube-prometheus-stack-prometheus-0 \
-     -c prometheus -- /bin/promtool query instant http://localhost:9090 \
-     "up{container=\"oauth2-proxy\"}"'
-```
-
-No series for the namespace → nothing discovers it (no PodMonitor match; check the pod carries
-`homelab.keithjackson.dev/auth-mode=forward-auth` and a named `metrics` port). A series with
-value **0** → discovered but every scrape fails; get the reason from the target's `lastError`:
-
-```
-infra/devcontainer/dev.sh run bash -c \
-  'kubectl --context k3s-prod -n monitoring port-forward svc/kube-prometheus-stack-prometheus 19090:9090 & sleep 5; \
-   curl -s localhost:19090/api/v1/targets | python3 -c "
-import json,sys
-for t in json.load(sys.stdin)[\"data\"][\"activeTargets\"]:
-    if t[\"labels\"].get(\"container\")==\"oauth2-proxy\":
-        print(t[\"labels\"].get(\"namespace\"), t[\"health\"], t.get(\"lastError\",\"\")[:90])"'
-```
-
-`context deadline exceeded` is a **drop**, not a refusal — that is NetworkPolicy, not a dead
-endpoint. Confirm the endpoint itself is fine by port-forwarding straight to the pod, which
-bypasses policy entirely:
-
-```
-infra/devcontainer/dev.sh run bash -c \
-  'kubectl --context k3s-prod -n jackett port-forward \
-     $(kubectl --context k3s-prod -n jackett get pod -l app.kubernetes.io/name=jackett -o name | head -1) \
-     14418:44180 & sleep 5; curl -s -o /dev/null -w "http=%{http_code} bytes=%{size_download}\n" \
-     http://127.0.0.1:14418/metrics'
-```
-
-`http=200` with a few KB means the listener is healthy and the path is what is broken. As of
-2026-10-01 that is the state of all five fleet apps, and the fix is an ingress allowance from ns
-`monitoring` to port 44180 — see `platform/longhorn/networkpolicy-metrics.yaml` for the idiom.
-
-**2. The sidecar log — but you must grep it.** The gate's stdout is ~11,500 lines a day per app
-and almost all of it is the kubelet health probe (`GET "/ping" ... 200`). A plain
-`kubectl logs --tail=100` shows you nothing but `/ping` and looks perfectly healthy. Filter:
-
-```
-infra/devcontainer/dev.sh run bash -c \
-  'kubectl --context k3s-prod -n jackett logs deploy/jackett -c oauth2-proxy --since=2h \
-     | grep -v "/ping" | grep -E "No valid authentication|AuthSuccess|403|401|callback"'
-```
-
-Substitute the namespace: `crafty`, `jackett`, `pihole`, `qbittorrent`, `radarr`, `sonarr`.
-
-**3. The same question across every gate at once, from Loki.** Alloy collects all of these, so
-you can ask about the whole fleet and about a window that has already scrolled out of
-`kubectl logs`. Port-forward Loki and query it:
-
-```
-infra/devcontainer/dev.sh run bash -c \
-  'kubectl --context k3s-prod -n monitoring port-forward svc/loki 13100:3100 & sleep 5; \
-   curl -s -G --data-urlencode "query=sum by (namespace) (count_over_time({container=\"oauth2-proxy\"} |= \"No valid authentication in request\" [24h]))" \
-     http://127.0.0.1:13100/loki/api/v1/query | python3 -m json.tool | grep -E "namespace|value" '
-```
-
-and the denominator, which is what makes the number mean something:
-
-```
-   ... --data-urlencode "query=sum by (namespace) (count_over_time({container=\"oauth2-proxy\"} |= \"AuthSuccess\" [24h]))" ...
-```
-
-**How to read the ratio.** A healthy sign-in is roughly **one or two** `No valid authentication`
-lines per `AuthSuccess` — the first request of a session is unauthenticated by definition. A
-ratio in the tens means sessions are not surviving. Measured on prod 2026-09-30 (24h):
-
-| namespace | `No valid authentication` | `AuthSuccess` | ratio |
-|---|---|---|---|
-| crafty | 81 | 1 | 81:1 |
-| radarr | 67 | 1 | 67:1 |
-| jackett | 39 | 4 | ~10:1 |
-| pihole, qbittorrent, sonarr | 0 | 0 | (unused in the window) |
-
-All three of those are the failure, not the baseline.
-
-**The cleanest worked case of all — radarr, measured 2026-10-01.** After the cookie fix landed,
-jackett dropped to **0** `No valid authentication` lines in 13,612 (from 39), and `removing
-session` / `cookie signature not valid` went to **0 on both apps** (radarr had 8 and 8 before).
-The eviction fingerprint is gone. But radarr still logged **206** rejections — and sampling 209 of
-them, **every single one was the same request**:
-
-    GET "/signalr/messages/negotiate" ... 302    <- browser UA, over and over
-
-That is one left-open browser tab. Its cookie is gone, its SignalR socket keeps trying to
-reconnect, and every attempt is silently 302'd to Keycloak. Nobody is at the keyboard, so nobody
-is ever re-prompted; the tab just sits there looking like a working page that has stopped
-updating. **This is the entire failure class in one line**: a non-navigation request answered with
-a redirect, forever, with no error surfaced anywhere.
-
-So when you read a rejection count, **always group by request path before concluding anything**:
-
-```
-infra/devcontainer/dev.sh run bash -c \
-  'kubectl --context k3s-prod -n radarr logs deploy/radarr -c oauth2-proxy --since=24h \
-     | grep -v "/ping" | grep "No valid authentication" -A 1 \
-     | grep -oE "\"[^\"]+\" HTTP" | sort | uniq -c | sort -rn | head'
-```
-
-One path dominating means an orphaned client, not a broken gate — annoying but harmless, and it
-clears when the tab is closed. Many different paths from one session means the session itself is
-not surviving, which is the real defect. A per-app `--api-route` is the structural fix for the
-first shape: it makes those paths answer **401** instead of 302, so the client fails loudly
-instead of looping. Note that a count of **0 `AuthSuccess`** alongside a high rejection count
-means nobody has signed in since the last restart — so `--cookie-refresh` has never run, and no
-session-lifecycle conclusion can be drawn from that window at all.
-
-**4. Did the gate admit the user, or did the app refuse them?** Look for the `[AuthSuccess]` line
-and what follows it. If `[AuthSuccess]` appears and the very next thing is the *app's own* login
-page or the app's 401, the gate did its job and layer 3 is your problem — that is the Crafty
-shape, and `runbooks/crafty-admin-credential.md` covers it.
-
-**5. Cookie names, when sessions do not survive.** Two oauth2-proxy instances emitting the
-**same** cookie name on the **same** domain hold different cookie-secrets, so each overwrites the
-other's cookie and the loser logs exactly the `No valid authentication` line above. List what
-each gate is configured to emit (arguments only — never print a Secret's data):
-
-```
-infra/devcontainer/dev.sh run bash -c \
-  'for ns in crafty jackett pihole qbittorrent radarr sonarr; do printf "%-12s " "$ns"; \
-     kubectl --context k3s-prod -n $ns get deploy $ns \
-       -o jsonpath="{range .spec.template.spec.containers[?(@.name==\"oauth2-proxy\")]}{.args}{end}" \
-     | tr "," "\n" | grep -E "cookie-name|cookie-domain" | tr "\n" " "; echo; done'
-```
-
-A gate with no `--cookie-name` is using oauth2-proxy's default `_oauth2_proxy`. If two of them
-share that default **and** a zone-wide `--cookie-domain=.home.keithjackson.dev`, they are
-evicting each other, and the symptom is intermittent and depends on which app you visited last.
-
-## Likely causes, most likely first
-
-1. **Cookie collision between two gates on one domain.** Default cookie names plus a zone-wide
-   cookie domain. Signature: high `No valid authentication`-to-`AuthSuccess` ratio, sessions
-   dying seconds after being created, symptom depends on browsing order, and *nothing* wrong at
-   Keycloak. Fix is a unique `--cookie-name` and a host-scoped `--cookie-domain` per gate — see
-   `decisions/2026-09-29-crafty-oauth2-proxy-signin.md`, which found and fixed exactly this.
-2. **The cookie is too large to come back.** With `--pass-access-token` the session carries the
-   access token; a fat Keycloak token pushes the cookie past 4 KB and it gets split into
-   `_oauth2_proxy_0`, `_oauth2_proxy_1`… If a chunk is dropped the session is unreadable and the
-   gate logs the same line. Look for numbered cookie names in the log, and for a session that
-   never survives a single navigation.
-3. **The XHR path is not the navigation path.** The app's API is under a prefix the gate handles
-   differently, or the app issues cross-origin XHRs the cookie does not accompany. Signature:
-   `/UI/...` returns 200 and `/api/...` returns 302 in the *same second*, which is precisely the
-   jackett trace above.
-4. **Session lifetime shorter than the app's polling interval,** with no refresh. The jackett
-   session above was a 5-minute session. If `refresh_token:true` is present and sessions still
-   die early, the refresh is failing, not missing.
-5. **Group check, not authentication.** `--allowed-group` is a floor: a valid Keycloak session in
-   the wrong group is refused *after* a successful login, which reads as a loop. Look for 403 and
-   for the `groups:[...]` list on the `[AuthSuccess]` line.
-6. **The app, not the gate.** `[AuthSuccess]` followed by the app's own login page or 401.
-
-## When to escalate or stop
-
- **Stop and hand over if the fix is a manifest change.** Everything above is read-only
-  diagnosis. Changing a `--cookie-name`, adding `--metrics-address`, or editing an alert goes
-  through a branch and a PR; `kubectl edit` on a gate is drift that the next Flux reconcile
-  reverts, and in the meantime you have an unreproducible cluster.
- **Stop if you find yourself about to print a Secret.** The cookie-secret and client-secret live
-  in `oauth2-proxy-credentials` and the per-app equivalents. Compare *key names* and whether two
-  Secrets differ; never dump `.data` or `.stringData`. A password has been leaked into a
-  transcript here exactly this way.
- **Escalate to the platform owner if Keycloak itself is the suspect** — check `KeycloakDown` and
-  `KeycloakDatabaseDown` first (`runbooks/keycloak-down.md`, `runbooks/keycloak-db.md`). In the
-  2026-09-30 incident Keycloak was healthy throughout and blaming it would have cost days.
- **The honest limit of this page.** With no metrics from the sidecars there is no history beyond
-  Loki's **72h** retention (`platform/monitoring/loki.yaml`, `retention_period: 72h`). If the
-  report is older than three days, the evidence is gone and the only remaining move is to
-  reproduce it. That is the cost of the gap `OAuth2ProxyGateUnobserved` is tracking, and it is
-  the reason to close it rather than silence it.
@@ -1,33 +1,14 @@
 # plex-quicksync — making Plex actually use Intel Quick Sync, and proving it did

-**Status: hardware transcoding is CONFIRMED WORKING on prod as of 2026-10-02** — VAAPI for both
-decode *and* encode, zero-copy, measured in Plex's own server log (see "How to verify"). The manual
-toggle has been ticked. This page is therefore now mostly a **verification and regression**
-procedure, and its old verification section was **wrong** — see the correction at the top of
-"How to verify".
 **Alert:** none, and none is possible — see "How to verify" below. This is an **operator procedure**,
 not an incident page. It is indexed here because the feature it completes is **inert until a human
 clicks one button**, and a switched-off feature that looks shipped is exactly what this page exists
 to prevent.
 **Files:** `catalog/plex.yaml` (`hardware.gpu: intel-quicksync`), `apps/wave-0/plex.yaml` (the
-rendered golden — the `resources.limits: gpu.intel.com/i915: 1` block), `catalog/render.py` (the
-mechanism), `schemas/renderer-contract.md` `### hardware` (the contract),
-`platform/intel-gpu-plugin/` (the DaemonSet that advertises the resource).
+rendered golden — the `dri` hostPath volume and the `/dev/dri` mount), `catalog/render.py` (the
+mechanism), `schemas/renderer-contract.md` `### hardware` (the contract).
 **Related:** `runbooks/plex-claim.md` — the other Plex procedure with a manual last mile.

-## STOP HERE IF PLEX IS `Pending` / `Unschedulable`
-
-That is this feature's **one serious failure mode** and it **stalls the whole app tier**
-(`apps-wave-0` is `wait: true`; `apps-wave-1` `dependsOn` it). Since 2026-10-01 Plex requests the
-extended resource `gpu.intel.com/i915: 1`, which is a **hard scheduling constraint** — if the
-`intel-gpu-plugin` DaemonSet is not advertising it on at least one schedulable node, Plex does not
-start at all. Go to **"Plex will not schedule"** below; it is the first troubleshooting section on
-purpose.
-
-**The escape hatch, in one sentence:** delete the two `hardware:` lines from `catalog/plex.yaml`,
-re-render, and merge — Plex returns to software transcoding and the tier unblocks. Exact commands
-are in **"Plex will not schedule" → remedy B**.
-
 ## What this means here

 Plex transcodes in **software** by default. On the UHD Graphics 630 iGPU of an i7-9700T, Quick Sync
@@ -37,8 +18,8 @@ is in git**:

 | Half | Who does it | State |
 |---|---|---|
-| The render device is inside the container **and openable** | **GitOps.** `hardware.gpu: intel-quicksync` in `catalog/plex.yaml` renders `resources.limits: {gpu.intel.com/i915: 1}` on the app container. The `intel-gpu-plugin` DaemonSet (`platform/intel-gpu-plugin/`) injects the device **and the matching device-cgroup allow rule**. Flux applies it. | Done by merging that change. |
-| Plex is *told* to use it | **The operator, by hand, in the Plex web UI.** | **Done, 2026-10-02**, and confirmed from the **log** rather than from a preference key. `HardwareAcceleratedCodecs` is **still absent** from `Preferences.xml` with hardware transcoding working, so its absence proves nothing — see first-command #4. |
+| The render device is inside the container at `/dev/dri` | **GitOps.** `hardware.gpu: intel-quicksync` in `catalog/plex.yaml` renders a `dri` hostPath volume (`/dev/dri`, `type: DirectoryOrCreate`) and a read-write `/dev/dri` volumeMount on the app container. Flux applies it. | Done by merging that change. |
+| Plex is *told* to use it | **The operator, by hand, in the Plex web UI.** | **NOT done.** `HardwareAcceleratedCodecs` was **absent** from `Preferences.xml` when this page was written — the toggle has never been on. |

 **There is no GitOps path to the second half, and that is verified rather than assumed.** A bounded
 grep across the running image's entire init surface — `/etc/cont-init.d`, `/etc/services.d`,
@@ -49,44 +30,10 @@ Every `setPref` the image performs is one of six hardcoded keys (`MachineIdentif
 and no `postBuild` substitution can set it. So do not go looking for the clever way to automate this;
 there isn't one, and the search has already been done.

-### Why a resource request and not a `/dev/dri` hostPath
-
-Because the hostPath was **tried and measured not to work**, and knowing that is the only thing that
-will stop someone "simplifying" it back. Merged 2026-09-30, measured in the live pod on k3s-prod-2 on
-**2026-10-01**: the device node was plainly **visible** in the container
-(`crw-rw---- root video2 226,128 renderD128`) and **could not be opened** —
-
-| attempt | result |
-|---|---|
-| `uid 0`, `O_RDWR` | **`EPERM`** "Operation not permitted" |
-| `uid 1000`, `O_RDWR` | **`EPERM`** "Operation not permitted" |
-
-`EPERM` is the **device cgroup** refusing, not `EACCES` from file permissions. The two look identical
-from the outside and are not the same problem. Proven three ways: root on the **host** opened the
-same device `rc=0`; the node is unified `cgroup2fs`; and the container's runc `config.json` read
-`linux.resources.devices: [{allow: False, access: 'rwm'}]` with `linux.devices: None` — **one
-deny-all rule, no allow entry for major 226**. A hostPath is a *filesystem* operation: it binds the
-device node in and adds **no cgroup allow rule**, because Kubernetes cannot infer one from a volume.
-
-Two non-workarounds, so nobody spends an evening on them: **`uid 0` failed too**, so running as root
-does not bypass the cgroup gate; and **`privileged: true` is not available** — Kyverno
-`restrict-host-namespaces` is **Enforce** on app namespaces and rejects it.
-
-The device plugin is what produces the allow rule — in the v0.37.0 source,
-`createDeviceSpecsFromDrmFiles` emits `DeviceSpec{…, Permissions: "rw"}`, which the kubelet turns
-into both the device injection and the matching cgroup allow.
-
-**The failure mode that trade bought, stated plainly.** Before, a missing device meant the pod ran
-and **silently software-transcoded** — invisible, but harmless to everything else. Now, a missing
-*resource* means Plex is **Unschedulable** and the app tier stalls. That is strictly worse in blast
-radius and it is **unavoidable**: an extended resource is a hard scheduling constraint, and it is
-also the only thing that produces the cgroup allow rule. There is no graceful-degradation variant.
-The one improvement is that the loss is no longer silent.
-
-What this does **not** do, so nobody reads more into a green gate than is there: it does not enable
-hardware transcoding (that is the manual toggle below — done 2026-10-02), a green gate only proves
-the **manifest renders**, and it writes no `nodeSelector` — the resource itself constrains Plex to nodes the plugin
-advertises, which is the scheduler's doing and not a selector in this repo.
+What the device mount does **not** do, so nobody reads more into a green gate than is there: it does
+not enable hardware transcoding, it does not prove the device can be *opened* from inside a
+non-privileged pod (see "Likely causes" #2), and it renders no `nodeSelector` — Plex can land on any
+of the three nodes and all three carry the device.

 ## Running the commands in this runbook

@@ -104,46 +51,15 @@ read of that file below greps a single named key — do not widen one.

 ## First commands

-**0. Is Plex running at all?** Ask this first now — the current mechanism can stop it starting.
-
-```
-infra/devcontainer/dev.sh run bash -c \
-  'kubectl --context k3s-prod -n plex get pod -l app.kubernetes.io/name=plex -o wide'
-```
-
-`Pending` ⇒ go straight to **"Plex will not schedule"**. Running ⇒ carry on.
-
-**1. Do the nodes advertise the resource, and is the plugin Ready?** This replaces the old "is the
-hostPath mounted" check, and it is now the first thing that can be wrong.
-
-```
-infra/devcontainer/dev.sh run bash -c \
-  'kubectl --context k3s-prod get nodes -o json \
-   | jq -r ".items[] | \"\(.metadata.name) i915=\(.status.allocatable[\"gpu.intel.com/i915\"] // \"ABSENT\")\""'
-```
-
-Expect `i915=1` on each of the three prod nodes (measured 2026-10-01: all three). Any `ABSENT` ⇒ that
-node cannot run Plex. Then the DaemonSet behind it:
-
-```
-infra/devcontainer/dev.sh run bash -c \
-  'kubectl --context k3s-prod -n intel-gpu-plugin get daemonset intel-gpu-plugin'
-```
-
-Expect **3 desired / 3 ready / 3 available** (measured 2026-10-01). Anything less is the cause, not a
-symptom — fix it there, in `platform/intel-gpu-plugin/`, not here.
-
-**2. Did Flux apply the current manifest?** `gpu.intel.com/i915` on the app container means the
-GitOps half landed:
+**1. Is the device mounted into the pod at all?** (Proves Flux applied the change, not that it works.)

 ```
 infra/devcontainer/dev.sh run bash -c \
  'kubectl --context k3s-prod -n plex get pod -l app.kubernetes.io/name=plex \
-     -o jsonpath="{.items[0].spec.containers[0].resources.limits}"; echo'
+     -o jsonpath="{.items[0].spec.containers[0].volumeMounts[*].mountPath}"; echo'
 ```

-A `/dev/dri` **volumeMount** instead ⇒ the running pod predates the 2026-10-01 merge and is on the
-mechanism that does not work. Compare
+`/dev/dri` in that list ⇒ the GitOps half landed. Absent ⇒ the running pod predates the merge; compare

 ```
 infra/devcontainer/dev.sh run bash -c \
@@ -153,52 +69,46 @@ infra/devcontainer/dev.sh run bash -c \

 against the merge commit before blaming anything else.

-**3. Is the device visible inside the container, and can Plex *open* it?** This is the decisive test
-of the whole mechanism, and **it must be run as uid 1000**, because that is what Plex runs as.
+**2. Is the device actually visible inside the container?**

 ```
 infra/devcontainer/dev.sh run bash -c \
  'kubectl --context k3s-prod -n plex exec deploy/plex -- ls -l /dev/dri'
 ```

-Expect `renderD128`, mode `crw-rw----`. The plugin injects it; there is no longer any
-`DirectoryOrCreate` empty-directory case — if the resource were missing the pod would not be running
-to exec into. Then the open, **as the app user**:
+Expect `renderD128` (usually `card0` too), mode `crw-rw----`, group `render`. An **empty directory**
+here is the `DirectoryOrCreate` degradation: the kubelet created an empty `/dev/dri` because the node
+had none. That is the designed-safe outcome — the app tier still reconciles — but it means software
+transcoding, silently. Find which node the pod is on and ask why that node lost its iGPU:
+
+```
+infra/devcontainer/dev.sh run bash -c \
+  'kubectl --context k3s-prod -n plex get pod -l app.kubernetes.io/name=plex -o wide'
+```
+
+**3. Can Plex *open* it?** This is the question the manifest cannot answer — see "Likely causes" #2.

 ```
 infra/devcontainer/dev.sh run bash -c \
  'kubectl --context k3s-prod -n plex exec deploy/plex -- \
-     s6-setuidgid plex sh -c "exec 3<>/dev/dri/renderD128 && echo RW-OPEN-OK || echo RW-OPEN-DENIED"'
+     bash -c "exec 3<>/dev/dri/renderD128 && echo RW-OPEN-OK || echo RW-OPEN-DENIED"'
 ```

-`RW-OPEN-OK` **as uid 1000** is the pass condition. **Passing as `uid 0` is weaker evidence and must
-not be accepted as proof** — Plex runs as 1000, and the whole point of the 2026-10-01 change was a
-cgroup rule that uid 0 could not buy its way past either. `RW-OPEN-DENIED` with the device plainly
-visible is the **device-cgroup** failure — i.e. the plugin's allow rule did not arrive; see "Likely
-causes" #2.
+`RW-OPEN-DENIED` (or `Operation not permitted` / `Permission denied`) with the device plainly visible
+in step 2 is the **device-cgroup** failure, not a file-permission failure. The two look identical from
+the outside and are not the same problem.

-**4. Is the toggle on?** **You cannot answer this from `Preferences.xml` alone.** That mistake is on
-this page's record: it told readers to treat a missing `HardwareAcceleratedCodecs` as "never
-enabled", and on 2026-10-02 that key was **absent from all 27 attributes** while hardware
-transcoding was demonstrably working. Named keys only — never the whole file, it holds
-`PlexOnlineToken`:
+**4. Is the toggle on?** Named key only — never the whole file:

 ```
 infra/devcontainer/dev.sh run bash -c \
  'kubectl --context k3s-prod -n plex exec deploy/plex -- \
-     grep -o -e "HardwareAcceleratedCodecs=\"[01]\"" -e "HardwareDevicePath=\"[^\"]*\"" \
-     "/config/Library/Application Support/Plex Media Server/Preferences.xml" || echo NEITHER-KEY'
+     grep -o "HardwareAcceleratedCodecs=\"[01]\"" \
+     "/config/Library/Application Support/Plex Media Server/Preferences.xml" || echo ABSENT'
 ```

-| Reading | What it actually means |
-|---|---|
-| `HardwareDevicePath="…"` **present** | **Positive signal.** Plex writes this when hardware acceleration is configured; it was present on 2026-10-02 alongside a working VAAPI pipeline. |
-| `HardwareAcceleratedCodecs` **absent** | **Nothing. Neither on nor off.** Measured absent with the feature working (2026-10-02). Do not diagnose from it, and do not write it into the file to "fix" it. |
-| `HardwareAcceleratedCodecs="0"` | explicitly **off** — the only conclusive reading, and only in the negative. |
-| `HardwareAcceleratedCodecs="1"` | on. |
-
-**The log settles it, this file does not.** Go to "How to verify"; the `hardware transcoding:
-enabled` and `final decoder/final encoder` lines are the verdict.
+`ABSENT` ⇒ never enabled (the state this page was written in). `="0"` ⇒ explicitly off. `="1"` ⇒ on,
+and the remaining question is whether it *works* — go to "How to verify".

 ## The one manual step

@@ -207,11 +117,8 @@ Plex web UI → **Settings → Transcoder → "Use hardware acceleration when av

 The underlying preference key is **`HardwareAcceleratedCodecs`**. That name was confirmed by
 extracting strings from the 23 MB `Plex Media Server` binary in the running container — **not** from
-recall and not from a forum post. **But do not expect to see it in `Preferences.xml` after ticking
-the box:** on 2026-10-02, with the toggle on and hardware transcoding working, the key was absent and
-`HardwareDevicePath` was what had been written. The key exists in the binary; Plex does not
-necessarily persist it. Real neighbouring keys from the same binary, so you can recognise them and
-not invent them:
+recall and not from a forum post. Real neighbouring keys from the same binary, so you can recognise
+them and not invent them:

 | Key | What it is |
 |---|---|
@@ -228,223 +135,73 @@ binary. Recorded explicitly so nobody spends an evening hunting for it or, worse
 Editing `Preferences.xml` by hand is **not** the procedure. It is app state on the replicated Longhorn
 tier, it is in no git commit, and the UI writes the key correctly. Use the UI.

-## How to verify — the log, not the dashboard
+## How to verify — and why there is no alert

-**Correction, 2026-10-02.** Until today this page said the Plex dashboard showing `Transcode (hw)`
-was "the *only* proof available, and nothing else will ever tell you". **That was false and it cost
-the operator real time:** hardware transcoding was fully working — VAAPI decode *and* encode, with
-zero-copy — while **Dashboard → Activity showed nothing of the sort**. A check that is silent while
-the feature works does not just fail to prove anything; it sends someone hunting a fault that does
-not exist. The authoritative check is **Plex's own server log**.
+Start a playback that **forces a transcode** (a client that cannot direct-play the source, or pick a
+lower quality explicitly), then read Plex's own **Dashboard → Activity**:

-### The primary check — run this one
+- **`Transcode (hw)`** on the session ⇒ hardware transcoding. **This is the proof.**
+- plain **`Transcode`** ⇒ software. The feature is not working, whatever the manifest says.

-```
-./infra/devcontainer/dev.sh run bash -c 'kubectl --context k3s-prod -n plex exec deploy/plex -- \
-  grep -aiE "hardware transcoding: (final|using)" \
-  "/config/Library/Application Support/Plex Media Server/Logs/Plex Media Server.log" \
-  | sed -E "s/(X-Plex-Token|token)=[^&[:space:]]*/\1=REDACTED/g" | tail -5'
-```
+**That dashboard is the *only* proof available, and nothing else will ever tell you.**
+`catalog/plex.yaml` declares no `metricsEndpoint`, so Plex renders **no ServiceMonitor at all** —
+there is no scrape, no transcode-mode metric, and therefore no alert that could fire. Do not open work
+to "alert on software-transcode fallback": with no metric behind it such a rule would be permanently
+inert, and this repo has already been burned at scale by rules that evaluated against nothing while
+looking like coverage (`runbooks/README.md`, "Alerts you should not trust the silence of"). If that
+gap is ever worth closing, the honest order is a real exporter first and a rule second.

-| Line | Verdict |
-|---|---|
-| `hardware transcoding: final decoder: vaapi, final encoder: vaapi` | **PASS.** Hardware in **both** directions. This is the pass condition. |
-| `hardware transcoding: using zero-copy transcoding` | Best case — frames never round-trip through the CPU. Observed on prod 2026-10-02. |
-| `hardware transcoding: final decoder: , final encoder: ` (both empty) | It **fell back to software** for that session. |
-| no matching line at all | No transcode has been attempted since the log rolled — force one (below), then look again. Absence is not a failure. |
-
-The 2026-10-02 reading on prod, in full, for the shape to recognise:
-
-```
-Codecs: hardware transcoding: testing API vaapi for device '/dev/dri/renderD128'
-                              (Intel CoffeeLake-S GT2 [UHD Graphics 630])
-hardware transcoding: using hardware decode accelerator vaapi
-hardware transcoding: zero-copy support present
-hardware transcoding: using zero-copy transcoding
-hardware transcoding: final decoder: vaapi, final encoder: vaapi
-```
-
-To make a line appear, start a playback that **forces a transcode**: a client that cannot
-direct-play the source, or an explicitly lower quality. Direct Play / Direct Stream never reaches
-the transcoder and logs nothing.
-
-### Three things to get right about that command
-
-1. **Always keep the `sed`.** `Plex Media Server.log` carries API URLs containing
-   **`X-Plex-Token=…`**, a live plex.tv credential. Any output that might land in a ticket, a
-   transcript or a chat window must be redacted — CLAUDE.md §6, and a credential has already been
-   leaked into a transcript in this repo exactly this way. The redacting form above is the form to
-   copy; do not "simplify" the pipe out of it.
-2. **`Plex Transcoder Statistics.log` is the WRONG FILE.** The name is irresistible and someone will
-   reach for it. It holds XML `<Variant .../>` session records — **not** ffmpeg/VAAPI output. There
-   is no decoder/encoder verdict anywhere in it. The file you want is `Plex Media Server.log`.
-3. `grep -a` is deliberate: the log carries occasional non-UTF-8 bytes, and without `-a` GNU grep
-   reports "binary file matches" and prints nothing — which reads exactly like "no hardware
-   transcoding".
-
-### Secondary and unreliable: the Plex dashboard
-
-**Dashboard → Activity** *may* label a transcoding session `Transcode (hw)`. If it does, it agrees
-with the log and you are done. **If it does not, that proves nothing at all** — measured 2026-10-02:
-hardware transcoding active and zero-copy, dashboard silent. Never conclude "software transcoding"
-from the dashboard and never open an investigation on its say-so. Kept here only because it is the
-fastest glance available; it is a convenience, **not evidence**.
-
-### Process-level, while a transcode is in flight: the transcoder's argv
-
-This shows Plex *requesting* hardware, as distinct from reporting it afterwards. Get a shell in the
-pod (if `-it` has no TTY under `dev.sh run`, wrap each line in `sh -c "…"` instead):
+Corroborating, not a substitute — the server log on the config PVC:

 ```
 infra/devcontainer/dev.sh run bash -c \
-  'kubectl --context k3s-prod -n plex exec -it deploy/plex -- sh'
+  'kubectl --context k3s-prod -n plex exec deploy/plex -- \
+     sh -c "grep -i -m20 -e hardware -e vaapi -e hwdevice \
+     \"/config/Library/Application Support/Plex Media Server/Logs/Plex Media Server.log\""'
 ```

-then, inside the pod:
-
-```
-ps -eo pid,user,comm | grep -i transcoder
-tr '\0' ' ' < /proc/<transcoder-pid>/cmdline | grep -oE '(-hwaccel[a-z_]*|vaapi|renderD[0-9]+)'
-```
-
-`-hwaccel`, `-hwaccel_device`, `vaapi`, `renderD128` present ⇒ Plex is asking for hardware. Keep the
-`grep -oE`: the raw argv contains media paths and session identifiers you do not want in a
-transcript. This only works while a session is actually transcoding.
-
-### Documented false lead: scanning `/proc/*/fd` for a holder of `renderD128`
-
-**It returns nothing even when hardware transcoding is working.** Measured 2026-10-02: a
-`/proc/*/fd` sweep inside the pod found **no** process holding `/dev/dri/renderD128`, while the log
-showed `final decoder: vaapi, final encoder: vaapi` for sessions either side of the scan. Transcode
-sessions are **short** and the scan landed in a gap between two of them. An empty fd scan is a
-**timing artefact, not a finding** — do not report it as evidence of software transcoding, and do
-not escalate on it. Use the argv check above (which has the same timing constraint but tells you
-something when it does catch a session), or just read the log, which is retrospective and therefore
-does not care about timing.
-
-### Why there is no alert — this half was always right
-
-`catalog/plex.yaml` declares no `metricsEndpoint`, so Plex renders **no ServiceMonitor at all** —
-there is no scrape, no transcode-mode metric, and therefore no alert that could fire. Do not open
-work to "alert on software-transcode fallback": with no metric behind it such a rule would be
-permanently inert, and this repo has already been burned at scale by rules that evaluated against
-nothing while looking like coverage (`runbooks/README.md`, "Alerts you should not trust the silence
-of"). If that gap is ever worth closing, the honest order is a real exporter first and a rule
-second.
+Treat those strings as advisory: they are Plex's, not this repo's, and they move between versions.
+Absence of a match is **not** evidence of software transcoding; a VA-API device open is good evidence
+of hardware. The dashboard remains the verdict.

 ## Likely causes, most likely first

-When the **log** says it fell back to software — `final decoder: , final encoder: ` with both
-fields empty. (Not when the dashboard is quiet: the dashboard's silence means nothing, see "How to
-verify".)
+When the dashboard still says plain `Transcode`:

-1. **The toggle is off.** Historically the most likely answer and the reason this page exists. It was
-   ticked on 2026-10-02 and should stay ticked, but a `/config` restore or a stray UI save can unset
-   it. Remedy: the manual step above. **Do not diagnose this from a missing
-   `HardwareAcceleratedCodecs`** — see first-command #4; only `="0"` is conclusive, and the log line
-   `hardware transcoding: enabled` is the real signal that the toggle took.
+1. **The toggle is off.** Overwhelmingly the most likely answer, and the reason this page exists.
+   First-command #4 returns `ABSENT` or `="0"`. Remedy: the manual step above. Check this **before**
+   investigating anything technical.

-2. **The device cannot be `open()`ed — the plugin's cgroup allow rule did not arrive.** Symptom:
-   first-command #3 shows `renderD128` present and correctly owned, and the open returns
-   `RW-OPEN-DENIED` / `Operation not permitted`. This is `EPERM` from the **device cgroup**, not
-   `EACCES` from file permissions. **This is no longer a design risk — it is the measured reason the
-   design is what it is** (2026-10-01; see "Why a resource request and not a `/dev/dri` hostPath").
-   If it recurs *under the current mechanism*, the plugin is the suspect, not the manifest: confirm
-   the pod really did consume the resource
+2. **containerd's device cgroup is refusing the `open()` — UNVERIFIED, and the largest remaining
+   technical risk in this feature.** Whether a non-privileged pod may `open()` a bind-mounted
+   character device on this k3s/containerd build **has not been established**; it can only be settled
+   by deploying and trying. The container inits as uid 0, which settles *file* permissions, but
+   **uid 0 does not bypass the cgroup device gate.** Symptom: step 2 shows `renderD128` present and
+   correctly owned, step 3 returns `RW-OPEN-DENIED`.
+   **The documented fallback is the Intel Device Plugin for Kubernetes** (`gpu.intel.com/i915` as a
+   resource request, no hostPath). Because the ServiceDefinition field expresses *intent* rather than
+   a device path, that migration is a **`catalog/render.py` change plus a re-render — with no
+   ServiceDefinition edit anywhere**; `catalog/plex.yaml` keeps saying exactly what it says today.
+   **`privileged: true` is not an available escape hatch:** Kyverno `restrict-host-namespaces` is in
+   **Enforce** mode and rejects it in app namespaces. Do not reach for it.

-   ```
-   infra/devcontainer/dev.sh run bash -c \
-     'kubectl --context k3s-prod -n plex get pod -l app.kubernetes.io/name=plex \
-        -o jsonpath="{.items[0].spec.containers[0].resources}"; echo'
-   ```
-
-   and then check the plugin pod on Plex's node (first-command #1). **Do not reach for
-   `privileged: true`** — Kyverno `restrict-host-namespaces` is Enforce and rejects it, and uid 0
-   failed the same open in 2026-09-30's measurement anyway. **Do not re-add a `/dev/dri` hostPath**;
-   that is the mechanism this replaced, and it was measured not to work.
-
-3. **The pod landed on a node whose GPU went away.** Under the current mechanism this does **not**
-   present as an empty `/dev/dri` — the node simply stops advertising `gpu.intel.com/i915` and Plex
-   either never schedules there or gets evicted off. So this cause now shows up as **`Pending`**, not
-   as silent software transcoding: see "Plex will not schedule". All three prod nodes carried
-   `renderD128` with `i915` bound when measured (2026-09-30) and all three advertised the resource on
-   2026-10-01, so this means a node changed — a rebuild, a BIOS reset, or a driver regression.
-   **Fix the node.**
+3. **The pod landed on a node without the device.** Step 2 shows an empty `/dev/dri`. All three prod
+   nodes carried `renderD128` with `i915` bound when this was measured (2026-09-30), so this means a
+   node changed — a rebuild, a BIOS reset, or a driver regression. `DirectoryOrCreate` is why the app
+   tier still came up; the cost is that the loss is silent. **Fix the node, do not tighten the mount:**
+   `Directory` would stall `apps-wave-0` (`wait: true`, with `apps-wave-1` depending on it) for a
+   feature that is not load-bearing.

 4. **The image changed under you.** See "The floating-image caveat". A `:latest` pull can remove the
   mechanism this feature leans on with no commit in this repo.

-5. **The session was never transcoding.** Direct Play / Direct Stream never reaches the transcoder,
-   so no `hardware transcoding:` line is written for it at all. An *absent* line is this, not a
-   failure — confirm a transcode actually happened before treating anything as a hardware fault.
+5. **The session was never transcoding.** Direct Play / Direct Stream never touches the transcoder, so
+   `Transcode (hw)` cannot appear. Confirm the session actually says `Transcode` before treating it as
+   a hardware failure.

-6. **The *source* codec may be one this iGPU cannot decode — HYPOTHESIS, not a confirmed
-   diagnosis.** The symptom that points here is fallback on **particular titles** while other
-   sessions are hardware. Measured on prod 2026-10-02, *between* two fully hardware sessions, one
-   session logged:
-
-   ```
-   hardware transcoding: enabled, but no hardware decode accelerator found
-   hardware transcoding: final decoder: , final encoder:
-   ```
-
-   The platform was demonstrably working either side of it, so the likely explanation is the **file**,
-   not the cluster: UHD 630's media engine decodes H.264, HEVC 8-bit and 10-bit, and VP9 — but **not
-   AV1**, and not 10-bit 4:2:2 HEVC. **This was NOT verified against that particular title.** It is
-   inferred from the hardware's capability set and is written here as the lead to check first, not as
-   a finding. So: fallback on *all* files is a platform problem (causes 1-4); fallback on *some*
-   files, check the source codec before suspecting the device, and expect occasional legitimate
-   per-title fallbacks to be normal rather than a fault.
-
-## Plex will not schedule
-
-**Symptom:** the Plex pod sits `Pending`, and `apps-wave-0` does not go Ready, which holds
-`apps-wave-1` behind it. This is the cost of the 2026-10-01 mechanism and the section you want at
-2am.
-
-```
-infra/devcontainer/dev.sh run bash -c \
-  'kubectl --context k3s-prod -n plex describe pod -l app.kubernetes.io/name=plex | tail -20'
-```
-
-`0/3 nodes are available: 3 Insufficient gpu.intel.com/i915` (or similar) confirms it: **nothing is
-advertising the resource Plex requires**. Plex's schedulability is coupled to the `intel-gpu-plugin`
-DaemonSet, deliberately and unavoidably — the plugin is also the only thing that produces the
-device-cgroup allow rule, so there is no variant of this feature that degrades gracefully.
-
-**Remedy A — fix the plugin (preferred).** Run first-command #1. If the DaemonSet is not 3/3, or the
-nodes show `i915=ABSENT`, the fault is in `platform/intel-gpu-plugin/` or on the node, and that is
-where to fix it. Check its Flux Kustomization reconciled:
-
-```
-infra/devcontainer/dev.sh run bash -c \
-  'kubectl --context k3s-prod -n flux-system get kustomization intel-gpu-plugin'
-```
-
-A plugin that is merely **not yet reconciled** resolves itself; one that is failing does not.
-
-**Remedy B — the escape hatch: give up hardware transcoding and unblock the tier.** One field, no
-code change. In a branch (never on `main`, never `kubectl edit` — Flux reconciles `main` and would
-revert you):
-
-1. delete these two lines from `catalog/plex.yaml`:
-
-   ```yaml
-   hardware:
-     gpu: intel-quicksync
-   ```
-
-2. re-render the golden:
-
-   ```
-   python3 catalog/render.py --all catalog -o apps --wave-layout --no-image-automation
-   ```
-
-   The only change must be `apps/wave-0/plex.yaml`, losing its `resources` block.
-3. gate, PR, merge. Plex schedules anywhere and **software-transcodes**; the app tier unblocks.
-
-Re-adding the field later is the same edit in reverse. Nothing about the Plex-side toggle or the
-`/config` PVC is affected either way — do **not** delete the PVC as part of this.
+6. **The source needs a codec Quick Sync on this generation cannot handle** — e.g. AV1 decode, which
+   Coffee Lake's UHD 630 has no engine for. Plex falls back to software *per stream*. Symptom: some
+   sessions show `(hw)` and others do not. Not a fault.

 ## The floating-image caveat

@@ -472,37 +229,21 @@ infra/devcontainer/dev.sh run bash -c \
 ```

 `45-plex-hw-transcode-and-connected-tuner` still present ⇒ the group mechanism is still the one
-described here: the hook reads the injected device's **own** ownership, which under the device plugin
-is `root:root`, so it resolves GID `0` (see "When to escalate or stop"). Gone or renamed ⇒ stop and
-re-measure. In particular the "no `supplementalGroups` needed" conclusion in `catalog/plex.yaml` and
-`schemas/renderer-contract.md` is only true while that hook exists.
+described here. Gone or renamed ⇒ stop and re-measure. In particular the "no `supplementalGroups`
+needed" conclusion in `catalog/plex.yaml` and `schemas/renderer-contract.md` is only true while that
+hook exists.

 ## When to escalate or stop

 - **Do not add `supplementalGroups` or a `podSecurityContext` to `catalog/plex.yaml`.** It would be
-  **inert**, and it would mislead the next person. The image's `cont-init.d` hook stats each
-  `/dev/dri` char device and `usermod -a -G`s the `plex` user into **that device's** group, inside
-  the container; the service then execs via `s6-setuidgid plex`, which **rebuilds** the process group
-  list from `/etc/group` rather than appending to it. Anything Kubernetes supplies is therefore
+  **inert**, and it would mislead the next person. Measured in-container 2026-09-30: the image's
+  `cont-init.d` hook stats each `/dev/dri` char device and `usermod -a -G`s the `plex` user into its
+  group *inside* the container, and the service then execs via `s6-setuidgid plex`, which **replaces**
+  the process group list from `/etc/group` rather than appending — `Plex Media Server` runs with
+  `Groups: 100 1000`, root's gid `0` (which PID 1 does hold) gone. Anything Kubernetes supplies is
  discarded before Plex starts. `render.py --selftest` asserts that absence deliberately.
- **GID `992` is a hostPath-era number — do not expect it, and do not read the root group as a
-  defect.** Under the device plugin the injected `/dev/dri/renderD128` arrives **`root:root`**, so
-  the hook resolves GID **`0`** and adds `plex` to the **root group**. Measured 2026-10-02:
-  `Plex Media Server` runs with `Groups: 0 100 1000`, and `id plex` reports
-  `groups=1000(plex),0(root),100(users)`. Under the old hostPath the device was `root:render`
-  (GID 992 on these nodes) and the reading was `Groups: 44 100 992 1000`. **992 is now irrelevant**:
-  if any page, comment or older handoff tells you to expect it, that text is stale and the system
-  you are looking at is working. The root-group membership is an inherent property of the plugin's
-  `DeviceSpec` — it injects the host device with its host ownership — **not** a defect, and **not** a
-  reason to reintroduce `supplementalGroups`, which would still be a no-op for the reason in the
-  bullet above.
 - **Do not reach for `privileged: true`.** Kyverno `restrict-host-namespaces` is Enforce and will
-  reject it — and it would not help: `uid 0` failed the same `open()` in the 2026-09-30 measurement,
-  because root does not bypass the cgroup device gate.
- **Do not re-add a `/dev/dri` hostPath, and do not "simplify" the resource request into one.** That
-  was the original mechanism and it was measured non-functional on 2026-10-01 (device-cgroup `EPERM`
-  with the device plainly visible). The device plugin's `DeviceSpec{… Permissions: "rw"}` is what
-  grants access; a volume cannot.
+  reject it. If the cgroup gate is the blocker, the answer is the Intel device plugin (cause #2).
 - **Do not `kubectl edit`/`patch` the Deployment to add or change the device mount.** Flux reconciles
  `main`; a hand-applied change is drift that the next reconcile reverts or, worse, adopts. Mutating
  `kubectl` and `flux reconcile` are **operator** actions, and the durable change is a git change
@@ -512,10 +253,9 @@ re-measure. In particular the "no `supplementalGroups` needed" conclusion in `ca
 - **Do not delete the `plex-config` PVC to "start clean".** It is the library database, metadata and
  watch state (`policy: daily-offcluster`). The transcode toggle is one preference, not a reason to
  lose the DB.
- **Stop and get the operator** if the device cannot be opened from the pod as uid 1000 (cause #2
-  confirmed) *under the current mechanism* — note that this open **passed** on 2026-10-02
-  (`RW-OPEN-OK` as uid 1000 via `s6-setuidgid plex`), so a failure now is a regression. The next step is a platform change in
-  `platform/intel-gpu-plugin/`, with its own PR, not more poking at this workload.
+- **Stop and get the operator** if the device cannot be opened from the pod (cause #2 confirmed). The
+  next step is a platform change — the Intel device plugin — with its own PR, not more poking at this
+  workload.

 ## Known gaps, deliberately not fixed here

@@ -537,25 +277,7 @@ Recorded so they are findable, and so nobody assumes they were overlooked:

 ---
 Source of truth: `runbooks/plex-quicksync.md`. Index: `/runbooks/`
-
-**Hardware transcoding is CONFIRMED WORKING on prod, measured 2026-10-02.** From
-`Plex Media Server.log` in the running pod: API `vaapi` on `/dev/dri/renderD128`
-(`Intel CoffeeLake-S GT2 [UHD Graphics 630]`), `using hardware decode accelerator vaapi`,
-`zero-copy support present`, `using zero-copy transcoding`, and
-`final decoder: vaapi, final encoder: vaapi`. Also measured in the same pod: `RW-OPEN-OK` opening
-`/dev/dri/renderD128` as uid 1000 via `s6-setuidgid plex`; the pod spec carrying
-`{"limits":{"gpu.intel.com/i915":"1"},"requests":{"gpu.intel.com/i915":"1"}}`; `Groups: 0 100 1000`
-and `id plex` → `groups=1000(plex),0(root),100(users)`; and `HardwareDevicePath` present in
-`Preferences.xml` while `HardwareAcceleratedCodecs` was absent from all 27 attributes.
-
-Earlier readings, kept for provenance and **superseded** where they conflict: the node measurements
-(all three prod nodes) and the in-container image measurements taken **2026-09-30** against
-`plexinc/pms-docker` digest `sha256:e0ab27395614…` (`plexmediaserver 1.43.4.10903`); the hostPath
-`EPERM` open results and the `Groups: 44 100 992 1000` / GID-992 group reading, **2026-10-01, under
-the hostPath mechanism that no longer exists**; and the `gpu.intel.com/i915: 1` allocatable and
-`intel-gpu-plugin` DaemonSet readings, **2026-10-01**.
-
-What this page still does **not** establish: that any particular title's software fallback was caused
-by its source codec (cause 6 is an unverified hypothesis), and that Plex's dashboard *ever* labels a
-session `Transcode (hw)` on this deployment — it has not been observed doing so, which is exactly why
-the log is now the primary check.
+The node measurements (all three prod nodes) and the in-container image measurements cited here were
+taken **2026-09-30** against `plexinc/pms-docker` digest `sha256:e0ab27395614…`
+(`plexmediaserver 1.43.4.10903`). Hardware transcoding had **not** been observed working at the time
+of writing, and the Plex-side toggle was still unset.
@@ -166,115 +166,56 @@ platform must render, and cites the requirement each mapping satisfies. Changing
  (today: `intel-quicksync`), not a device path, not a hostPath, not a resource request. The
  ServiceDefinition says *what class of host device this workload needs*; how the platform hands it
  over is `catalog/render.py`'s business and lives nowhere else. **Do not "simplify" this into a raw
-  `/dev/...` path.** The payoff is no longer hypothetical: on **2026-10-01** the mechanism was
-  swapped outright — from a `/dev/dri` hostPath to the Intel GPU device plugin's extended resource —
-  as a **`catalog/render.py` change plus a re-render, with ZERO catalog edits** and no re-review of
-  per-service device wiring. `catalog/plex.yaml`'s `hardware:` block came through byte-identical.
-  Extend the enum for a genuinely different capability class (e.g. `nvidia-nvenc`); never to name a
-  second route to the same one.
- `gpu: intel-quicksync` → on the **app container only** (never a sidecar), **exactly one thing**:
+  `/dev/...` path.** The entire payoff is that migrating from the hostPath mechanism below to the
+  Intel GPU device plugin (`resources.limits: gpu.intel.com/i915`) is a renderer change with **zero**
+  catalog edits and zero re-review of per-service device wiring. Extend the enum for a genuinely
+  different capability class (e.g. `nvidia-nvenc`); never to name a second route to the same one.
+- `gpu: intel-quicksync` → on the **app container only** (never a sidecar), exactly two things:
+  1. a **hostPath volume** `dri` → `/dev/dri`, **`type: DirectoryOrCreate`**;
+  2. a **read-write volumeMount** of `dri` at `/dev/dri` on the app container (VA-API opens the
+     render node read-write, so it is deliberately not `readOnly`).

-      resources:
-        limits:
-          gpu.intel.com/i915: 1
-
-  **That is the whole mapping.** No volume, no volumeMount, no `securityContext`, no `nodeSelector`,
-  no privileged anything.
-  - **`limits`, not `requests`, and that is not a style choice.** An extended resource must be
-    expressed in `limits`; Kubernetes mirrors `requests` from `limits` automatically, and a
-    requests-only extended resource is rejected as invalid.
-  - The resource is advertised by the **`intel-gpu-plugin` DaemonSet** (`platform/intel-gpu-plugin/`,
-    its own Flux Kustomization at `clusters/base/intel-gpu-plugin.yaml`, pinned
-    `intel/intel-gpu-plugin:0.37.0`). **Measured 2026-10-01:** all three prod nodes report
-    `.status.allocatable["gpu.intel.com/i915"] == 1`; DaemonSet 3 desired / 3 ready / 3 available.
-  - This is the **only** app-container `resources` render path in the file, and it is deliberately
-    narrow. **Do not generalise it into a CPU/memory resources feature** while passing through — that
-    is a separate field with a separate justification, and `render.py --selftest` asserts the emitted
-    dict *exactly* so the attempt fails loudly.
- **WHY THE hostPath MECHANISM WAS ABANDONED — read this before "simplifying" it back.** The first
-  implementation (merged 2026-09-30) rendered a `dri` hostPath volume at `/dev/dri` plus a read-write
-  mount. It was **measured not to work** in the live Plex pod on k3s-prod-2 on **2026-10-01**. The
-  device node was **visible** in the container — `crw-rw---- root video2 226,128 renderD128` — and
-  **could not be opened**:
-
-  | attempt | result |
-  |---|---|
-  | `uid 0`, `O_RDWR` | **`EPERM`** "Operation not permitted" |
-  | `uid 1000`, `O_RDWR` | **`EPERM`** "Operation not permitted" |
-
-  `EPERM` is the **device cgroup** refusing, not `EACCES` from file permissions — the two look
-  identical from the outside and are not the same problem. Proven three ways: root on the **host**
-  opens the same device `rc=0`; the node is unified `cgroup2fs`; and the container's runc
-  `config.json` reads `linux.resources.devices: [{allow: False, access: 'rwm'}]` with
-  `linux.devices: None` — **one deny-all rule, no allow entry for major 226**. A hostPath is a
-  *filesystem* operation: it binds the device node in but adds **no cgroup allow rule**, because
-  Kubernetes cannot infer one from a volume. **Note that `uid 0` failed too** — root does not bypass
-  the cgroup device gate, so "run it as root" is not a workaround. Neither is `privileged: true`:
-  Kyverno `restrict-host-namespaces` is **Enforce** on app namespaces and rejects it.
-  The device plugin is what produces the allow rule — confirmed in the v0.37.0 source,
-  `createDeviceSpecsFromDrmFiles` emits `DeviceSpec{…, Permissions: "rw"}`, which the kubelet turns
-  into both the device injection and the matching cgroup allow.
- **THE FAILURE MODE THIS TRADED INTO IS WORSE IN BLAST RADIUS, AND IT IS UNAVOIDABLE.** Stated
-  plainly rather than sold:
-
-  | | device/resource unavailable ⇒ |
-  |---|---|
-  | **Before** (hostPath, `DirectoryOrCreate`) | kubelet mounts an empty dir; Plex runs and **silently software-transcodes**. Invisible, but harmless to everything else. |
-  | **Now** (extended resource) | the pod is **Unschedulable**. `apps-wave-0` is `wait: true` and `apps-wave-1` `dependsOn` it, so this **stalls the app tier**. |
-
-  There is **no graceful-degradation variant**: an extended resource is a hard scheduling
-  constraint, and it is also the only thing that produces the cgroup allow rule. The workload's
-  schedulability is now **coupled to the `intel-gpu-plugin` DaemonSet** — a plugin that is broken,
-  removed, or merely not yet reconciled takes the app tier with it. That is the price of hardware
-  transcoding working at all.
-  - **Escape hatch, one field and no code change:** delete the `hardware:` block from the
-    ServiceDefinition (`catalog/plex.yaml`) and re-render. The workload returns to software
-    transcoding and the tier unblocks. `runbooks/plex-quicksync.md` carries it as a first-class
-    procedure, because it is what someone will need at 2am.
-  - The old mechanism's cost is **gone**, and that is the one improvement: a missing device is no
-    longer silent. There is still no metric and no alert (media apps here render no
-    `metricsEndpoint`, so no ServiceMonitor exists), but "Plex is Unschedulable" is loud, whereas
-    "Plex is quietly software-transcoding" never was.
+  **Mounting the device is sufficient. That is the whole mapping.**
 - **`podSecurityContext.supplementalGroups` is deliberately NOT rendered, and adding it would be a
-  regression rather than a hardening.** This survives the mechanism swap unchanged, and it was
-  re-measured against the plugin's behaviour. `renderD128` is `root:render` `0660`, so the obvious
+  regression rather than a hardening.** `/dev/dri/renderD128` is `root:render` `0660`, so the obvious
  move is to push the host `render` GID in — and it does not work. **Measured in the running
-  container on prod-2 (2026-09-30, re-measured 2026-10-01):** the image's own
+  container on prod-2, 2026-09-30:** the image's own
  `/etc/cont-init.d/45-plex-hw-transcode-and-connected-tuner` hook `find`s every char device under
  `/dev/dri`, `stat -c '%g'` each one's GID, `groupadd`s a matching group *inside the container* when
-  none exists, and `usermod -a -G` the app user into it — every start, nothing hardcoded. It does
-  exactly the same thing to a **plugin-injected** device as to a bind-mounted one, which is why this
-  swap needed no group work. `cont-init.d` completes before `services.d`, so the account database is
-  already correct when the service execs. The service then starts via `exec s6-setuidgid plex …`, and
-  `s6-setuidgid` **replaces** the process group list from `/etc/group` rather than appending to it —
-  measured live, `Plex Media Server` ran with `Groups: 44 100 992 1000`, where **992 is the host
-  `render` GID**, while root's gid `0` (which PID 1, `s6-svscan`, does hold) was **gone**. A
-  Kubernetes `supplementalGroups` therefore reaches `s6-svscan` and is discarded before the app ever
-  starts. It would be inert *and* it would mislead whoever debugs this next. The renderer asserts its
-  own absence in `render.py --selftest`.
+  none exists, and `usermod -a -G` the app user into it — every start, nothing hardcoded.
+  `cont-init.d` completes before `services.d`, so the account database is already correct when the
+  service execs. The service then starts via `exec s6-setuidgid plex …`, and `s6-setuidgid`
+  **replaces** the process group list from `/etc/group` rather than appending to it:
+  `Plex Media Server` runs as `Uid: 1000  Gid: 1000  Groups: 100 1000`, with root's gid `0` — which
+  PID 1 (`s6-svscan`) does hold — **gone**. A Kubernetes `supplementalGroups` therefore reaches
+  `s6-svscan` and is discarded before the app ever starts. It would be inert *and* it would mislead
+  whoever debugs this next. The renderer asserts its own absence in `render.py --selftest`.
  - A corollary worth having: because the hook re-`stat`s the device on every start, the host GID
    **drifting** (a node rebuild renumbering the *systemd dynamic* `render` group) is self-healing.
    No GID is pinned anywhere in this repo.
-  - **Scope of that measurement, stated so nobody over-reads it.** "The group is the image's job" was
-    established for an image that resolves the device group itself. A FUTURE consumer that runs
-    non-root and has no equivalent init hook would still need the group solved somehow — and the
-    answer for that case is a **renderer** change (per-image handling), not a new ServiceDefinition
-    field. The enum is what keeps that option open, and the 2026-10-01 swap is the proof it works.
-    The first such consumer must re-measure rather than assume this bullet covers it.
+  - **Scope of that measurement, stated so nobody over-reads it.** "Mounting the device is
+    sufficient" was established for an image that resolves the device group itself. A FUTURE
+    consumer that runs non-root and has no equivalent init hook would still need the group solved
+    somehow — and the answer for that case is a **renderer** change (per-image handling, or the
+    device plugin), not a new ServiceDefinition field. The enum is what keeps that option open. The
+    first such consumer must re-measure rather than assume this bullet covers it.
+- **`DirectoryOrCreate` is load-bearing — do not tighten it to `Directory`.** A node that comes back
+  without the render device (rebuild, BIOS change, driver regression, hardware swap) must degrade the
+  workload to **software transcoding**, not fail the mount. `apps-wave-0` is `wait: true` and
+  `apps-wave-1` `dependsOn` it, so a failed hostPath mount stalls the **whole app tier** for the sake
+  of a feature that is not load-bearing. `/dev` is tmpfs, so the empty directory the kubelet creates
+  on such a node leaves nothing durable behind.
+  - **The cost of that choice, stated plainly:** a missing device is **silent**. The workload
+    software-transcodes and nothing reports it. There is no metric to alert on — media apps here
+    render no `metricsEndpoint`, so no ServiceMonitor exists — and an alert that cannot fire is worse
+    than none (see §`observability`'s 2026-09-13 correction). The only proof of hardware transcode is
+    an operator observing it in the application's own dashboard.
 - **Deliberately NOT rendered** from this field: no `privileged: true` (Kyverno
-  `restrict-host-namespaces` is Enforce on app namespaces and would reject it, and it would not have
-  helped anyway — see the `EPERM` table); no `nodeSelector` (placement is a separate concern with its
-  own justification — this field is about the device, not about where the pod lands; the extended
-  resource does constrain placement to nodes the plugin advertises, but that is the **scheduler's**
-  doing, not a selector this renderer writes); no CPU/memory requests or limits (see above — the
-  `resources` block carries the extended resource and nothing else).
- **Historical, kept so a reader recognises it rather than reintroduces it:**
-  `type: DirectoryOrCreate` on the retired hostPath was load-bearing *for that mechanism* — it is
-  what made a GPU-less node degrade to software transcoding instead of failing the mount and
-  stalling the app tier. That rationale died with the hostPath; it is **not** an argument for bringing it back, since
-  the mechanism it protected never granted access in the first place.
- Absent ⇒ **nothing at all** is rendered; every service that does not opt in stays byte-identical
-  (no `resources` key, no volume, no mount, no `securityContext`).
+  `restrict-host-namespaces` is Enforce on app namespaces and would reject it, and the render node
+  does not need it); no `nodeSelector` (placement is a separate concern with its own justification —
+  this field is about the device, not about where the pod lands); no resource requests/limits (there
+  is no app-container resource render path, and inventing one here would be scope creep).
+- Absent ⇒ **nothing at all** is rendered; every service that does not opt in stays byte-identical.
  Ignored for `kind: vm` — a VM receives devices through KubeVirt's own `domain.devices`.
 - **Requirements:** **R-PLAT-02** (the PaaS provides the host capability; the app declares need).

@@ -424,18 +365,11 @@ platform must render, and cites the requirement each mapping satisfies. Changing
   `external-dns.alpha.kubernetes.io/controller: none`, and no `public` service's route carries it.
   Derived from `exposure` alone; enforced on every gate run by
   `conformance/tests/l0-static/internal-services-publish-no-public-dns` (R-DNS-03).
-8. **`hardware` is inert until opted into, and its mechanism is renderer-local — now DEMONSTRATED,
-   not merely claimed.** An SD with no `hardware` key renders no `resources` block, no volume and no
-   volumeMount; an SD *with* it gains a `gpu.intel.com/i915: 1` **limit on the app container only**
-   (never a sidecar) and no `securityContext` either. All directions are proven by
-   `render.py --selftest`, and each assertion is mutation-tested. The resource name
-   `gpu.intel.com/i915` appears in `catalog/render.py` and nowhere else in the catalog path, so the
-   capability's implementation can be replaced without touching a single ServiceDefinition — which
-   is exactly what happened on **2026-10-01**, when the mechanism moved from a `/dev/dri` hostPath
-   (measured non-functional: device-cgroup `EPERM`) to the device plugin's extended resource with
-   **zero** catalog edits. The cost of that mechanism is recorded in §`hardware`: the workload is now
-   **Unschedulable** when the resource is absent, which stalls the app tier, and the escape hatch is
-   to delete the `hardware:` block and re-render.
+8. **`hardware` is inert until opted into, and its mechanism is renderer-local.** An SD with no
+   `hardware` key renders no volume and no volumeMount; an SD *with* it gains no `securityContext`
+   either. Both directions are proven by `render.py --selftest`. The `/dev/dri` hostPath and the
+   `DirectoryOrCreate` type appear in `catalog/render.py` and nowhere else, so the capability's
+   implementation can be replaced without touching a single ServiceDefinition.

 ## Requirement traceability (contract-level)
 Primary **R-GITOPS-02** (single reviewable object wires every requirement). Field-level: R-NET-01/02