FLEX-WP-0016: record disposition; SCOPE reflects ADR-0006 and the zone review

FLEX-WP-0016 was titled 'so policy.enabled can flip' and the flip is not
coming. ops-warden's ADR-0006 defers it permanently in favour of
zone-scoped enforcement, so this closes rather than stalls: every task
it owned is delivered and enforce is independently verified by both
sides. The pin stays enforce and is not reverted to warn.

SCOPE's account of policy.enabled was stale - it read as a
build-stage timing choice. Replaced with the actual reason and with
flex-auth's boundary as the reviewing PDP: membership compiles to the
registry, stance stays in the policy package, fail-open is not
expressible by a PDP.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

SCOPE.md

@@ -90,12 +90,25 @@ fixtures, and tests). `FLEX-WP-0006` published that gate and `FLEX-WP-0007`
 deployed flex-auth as a reachable production runtime for it. The joint
 OpenBao-backed smoke is verified (2026-06-29: vault-backed allow recorded
 `decision:032b096c433ad80c`; TTL-over-max denied `ttl_out_of_bounds` by
-flex-auth before OpenBao). Production `policy.enabled` is **deliberately left
+flex-auth before OpenBao). `FLEX-WP-0016` then shipped an independently rollable
-off** for now — the ecosystem is still build-stage/pre-testing, so the gate is
+in-cluster ops-warden pin and moved it to `callerAuth.mode: enforce` once
-verified and banked for later live enforcement rather than forced into premature
+ops-warden adopted a calling identity (`WARDEN-WP-0031`): anonymous `/v1/check`
-production rigor. With the baseline complete, new work (live enforcement
+is 401, a token bound to another protected system is 403.
-rollout, additional consumers, deeper delegated backends) will open as fresh
+
-workplans.
+Production `policy.enabled` is **deliberately off, and is not coming back as a
+boolean.** ops-warden's `ADR-0006` (2026-08-19) defers it permanently:
+`policy.enabled` is one repo-wide flag, and with `fail_closed: true` it makes
+flex-auth a hard dependency of every `warden sign` — including the SSH
+certificates the ops-bridge tunnels depend on, one of which carries the policy
+call itself. Enforcement is being rescoped to *security zones* (`zone-engine`
+`ZONE-WP-0001`, consumer side `WARDEN-WP-0032`). flex-auth reviewed that model as
+the PDP on 2026-08-19 and holds one boundary: zone **membership** compiles into
+the registry snapshot flex-auth already consumes (no schema change needed), while
+per-zone **stance** belongs in the versioned policy package, because registry
+content is absent from decision provenance. **Fail-open is not expressible by a
+PDP at all** and stays a consumer-side setting. The enforcing pins stay
+enforcing regardless — an enforcing pin with no enforcing consumer still turns
+the anonymous path into a 401 rather than a decision.
 
 State Hub integration is present through:
 

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

@@ -117,3 +117,39 @@ per call; authenticated gate against warn held the warning count at 4
 (3) `resource.system=user-engine` → **403** `forbidden`.
 user-engine and tenant-engine pins were not moved. `policy.enabled` remains
 ops-warden's flip.
+
+## Disposition — closed 2026-08-19, not waiting on the flip
+
+This workplan's title says "so `policy.enabled` can flip", and the flip is not
+coming. Recording why that closes it rather than stalls it.
+
+ops-warden set `ADR-0006` on 2026-08-19: *enforcement is zone-scoped, never a
+global flag*. `policy.enabled` is one repo-wide boolean, and with
+`fail_closed: true` it makes flex-auth a hard dependency of every `warden sign`
+— including the SSH certificates the ops-bridge tunnels depend on, one of which
+now carries the policy call itself. That is a **deliberate deferral of the
+control's shape**, not a delay in ops-warden's adoption. The successor is
+`zone-engine` `ZONE-WP-0001` (the model) and ops-warden `WARDEN-WP-0032` (the
+consumer side); the eventual control will be zone-aware and will not be this
+boolean. Nothing in flex-auth's scope will be re-run when it lands.
+
+Everything this workplan owned is delivered and verified:
+
+- T01 overlay pin — `values/ops-warden.yaml`, production registry and policy.
+- T02 deployed and proven — allow, deny, `/healthz`.
+- T03 handoff — ops-warden adopted the calling side (`WARDEN-WP-0031`), the pin
+  moved to `enforce`, and enforcement is independently verified by both sides:
+  Bearer → 200 `decision:f3f7c88f9585582a`, anonymous → **401**, wrong system →
+  **403**.
+
+**The pin stays `enforce` and is not reverted to `warn`.** An enforcing pin with
+no enforcing consumer is not waste: it makes the anonymous path a 401 rather than
+a decision, which was the `ADHOC-2026-08-17-T01` condition regardless of whether
+ops-warden calls it. Re-verified live 2026-08-19 —
+`deploy/flex-auth-ops-warden` carries `--caller-auth-mode enforce` and
+`/healthz` is 200 through the managed tunnel
+`flex-auth-ops-warden-railiance01` (`:19090`).
+
+The one open flex-auth-side item is a heads-up obligation, not a task: the tunnel
+pins the Service ClusterIP `10.43.1.165`. If that Service is recreated the pin
+breaks and ops-warden needs telling.