Add isolated ops-warden warn pin (FLEX-WP-0016); FLEX-WP-0007 stays finished

policy.enabled cannot flip against the user-engine or tenant-engine
bindings. Helm release flex-auth-ops-warden rev 1 serves the production
registry in warn. Workstation warden sends no caller token; enforce and
the yaml flip stay ops-warden's.

workplans/FLEX-WP-0016-ops-warden-incluster-policy-pin.md

@@ -0,0 +1,107 @@
+---
+id: FLEX-WP-0016
+type: workplan
+title: "In-cluster ops-warden policy pin so policy.enabled can flip"
+domain: infotech
+repo: flex-auth
+status: active
+owner: grok
+topic_slug: netkingdom
+planning_priority: P1
+planning_order: 160
+depends_on_workplans:
+  - FLEX-WP-0007
+  - FLEX-WP-0015
+related_workplans:
+  - WARDEN-WP-0009
+created: "2026-08-19"
+updated: "2026-08-19"
+---
+
+# FLEX-WP-0016 - In-cluster ops-warden policy pin so policy.enabled can flip
+
+FLEX-WP-0007 is **finished**. Its repo-side artifacts, tunnel smoke, and
+vault-backed joint evidence already exist. What it deliberately deferred is
+the production `policy.enabled: true` flip.
+
+That flip is not a flex-auth kubectl of FLEX-WP-0007 leftovers. Three facts
+now make a new workplan the honest vehicle:
+
+1. FLEX-WP-0015 closed A0 on the two live pins. ops-warden's own sequencing
+   rule (ADHOC-2026-08-17-T01) was: `policy.enabled` must not flip anywhere
+   while `/v1/check` still answers unauthenticated callers. That condition
+   now holds for `flex-auth-user-engine` and `flex-auth-tenant-engine`.
+2. Those pins cannot serve ops-warden. Each has an exact
+   `resource.system` → ServiceAccount binding. A `warden sign` check with
+   `system: ops-warden` against either pin is 403, not a signing decision.
+3. There is no in-cluster ops-warden policy Service. FLEX-WP-0007 smoke used
+   a workstation runtime on `127.0.0.1:18090` via `flex-auth-coulombcore`.
+   Example `flex_auth_url` `http://flex-auth.flex-auth.svc.cluster.local:8080`
+   does not exist.
+
+## Ownership
+
+| Concern | Owner |
+| --- | --- |
+| Independently rollable in-cluster pin with the ops-warden policy package and production registry | flex-auth |
+| Workstation/CoulombCore `flex_auth_url` (tunnel or port-forward) | ops-warden / operator |
+| Calling-side identity on `warden sign` (TokenReview or later mTLS) | ops-warden, on its own schedule |
+| `policy.enabled: true` in `warden.yaml` | ops-warden operator |
+
+`warden sign` on a laptop is not a Kubernetes ServiceAccount. ADR 0004's
+choke point therefore cannot be `enforce` on this pin until ops-warden has a
+calling identity. First pin is **warn**. Enforce and the `policy.enabled`
+flip wait on that calling side.
+
+## Tasks
+
+```task
+id: FLEX-WP-0016-T01
+status: done
+priority: high
+```
+
+**Overlay pin.** Add `values/ops-warden.yaml`: same digest as the A2 pins,
+`--registry` / `--policy` for `examples/ops-warden/production_registry_snapshot.json`
+and `policy_package.md`, `callerAuth.mode: warn`, binding
+`ops-warden=system:serviceaccount:ops-warden:ops-warden`. `consumer.isolated:
+true` until there is an in-cluster PEP namespace to admit. Include it in
+`tests/stage1.sh`.
+
+Done 2026-08-19: `values/ops-warden.yaml` on digest `sha256:138aa347…`,
+warn, isolated, production registry. `tests/stage1.sh` renders it.
+
+```task
+id: FLEX-WP-0016-T02
+status: done
+priority: high
+```
+
+**Deploy warn.** `helm upgrade --install flex-auth-ops-warden` from the
+overlay. Prove `/healthz` and one allow `/v1/check` from an operator
+port-forward (isolated NetworkPolicy admits no consumer ingress). Do not
+flip `policy.enabled`.
+
+Done 2026-08-19: Helm release `flex-auth-ops-warden` rev 1, Service
+`flex-auth-ops-warden.flex-auth.svc.cluster.local:8080`. Port-forward
+`:19090` `/healthz` 200; `agt-state-hub-bridge` allow
+`decision:49350f1064f674d7`; TTL 999 deny `ttl_out_of_bounds`
+`decision:ad1620ffa431efe0`. Unauthenticated calls log
+`caller authentication warning` and still return a decision (warn).
+user-engine and tenant-engine pins were not moved.
+
+```task
+id: FLEX-WP-0016-T03
+status: wait
+priority: medium
+```
+
+**Handoff for the flip.** Tell ops-warden the Service DNS, digest, warn mode,
+and that `policy.py` currently sends no `Authorization` header. They adopt
+the calling side; then this pin can enforce; then they set
+`policy.enabled: true` with `fail_closed: true`. Flex-auth does not edit
+`~/.config/warden/warden.yaml`.
+
+Asked 2026-08-19. Cluster DNS from a warden workstation is not assumed;
+they pick tunnel or port-forward. `policy.py` posts JSON with no
+`Authorization` header.