WARDEN-WP-0032: flex-auth amendments to T02 and T03

flex-auth reviewed ZONE-WP-0001 as the consuming PDP and two findings
land on the ops-warden consumer side:

T02 - fail_closed is not expressible by a PDP. Fail-open describes what
warden sign does when flex-auth is unreachable, so no decision exists to
carry it. The replacement for policy.enabled is two things: stance,
which arrives in the decision, and failure mode, which stays local and
is declared per zone.

T02 - build_flex_auth_registry.py:77 already emits a hardcoded
trust_zone: platform that no policy reads. Resolve that before
compiling zone membership rather than adding security_zone beside it.

T03 - the declaration must say whether a zone rides the actor (subject)
or the lane (resource); in the compiled registry an actor is both.

No flex-auth registry schema change is needed - metadata, labels and
attributes already flatten into the rego input.

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

workplans/WARDEN-WP-0032-security-zones.md

@@ -82,6 +82,36 @@ re-establishing it is cheap precisely so this is a re-check rather than a re-do.
 
 This closes `WARDEN-WP-0031-T05`.
 
+**Amended by flex-auth 2026-08-19, reviewing `ZONE-WP-0001` as the PDP.** Two
+constraints that change what this task can build, both argued in full at
+`ZONE-WP-0001-T03` and `T04`:
+
+1. **The zone-aware control splits across the boundary, it does not move.**
+   flex-auth will read compiled zone *membership* from the registry and apply the
+   per-zone *stance* from its policy package, returning an effect plus an
+   advisory annotation. What stays on the ops-warden side is the axis flex-auth
+   structurally cannot carry: **`fail_closed` is not expressible by a PDP.**
+   Fail-open describes what `warden sign` does when flex-auth is *unreachable* —
+   no decision is rendered, so no compiled data and no policy rule can reach it.
+   So the replacement for `policy.enabled` is not one zone-derived boolean
+   either; it is (a) stance, which arrives *in the decision*, and (b) failure
+   mode, which stays a local ops-warden setting declared per zone. Plan for two,
+   or T02 will be built expecting flex-auth to answer something it cannot.
+
+2. **The membership compiler is ops-warden's to change, and it has a name
+   collision to resolve first.** `scripts/build_flex_auth_registry.py:77` already
+   emits `"trust_zone": "platform"` as a hardcoded constant on every
+   ssh-certificate resource. It is a first-class field on flex-auth's `Resource`,
+   it is surfaced into rego input, and **no policy package reads it**. Before
+   compiling zone membership, either retire that constant or deliberately
+   repurpose it — do not add `security_zone` beside a dormant `trust_zone` and
+   leave the next reader to guess which is real. That is the `ADR-0001`
+   second-source-of-truth failure in miniature, inside a generated artifact.
+
+Good news for T03's cost: **no flex-auth registry schema change is required.**
+`metadata`, `labels` and `attributes` already flatten into the rego input, so the
+compiler can emit membership today.
+
 ```task
 id: WARDEN-WP-0032-T03
 status: wait
@@ -90,7 +120,11 @@ state_hub_task_id: "fd642377-8d64-473c-b684-f8f1a842c223"
 ```
 
 **Declare ops-warden's zones** in whatever format `ZONE-WP-0001-T05` settles,
-alongside the existing posture descriptors. Carry the conformance rule:
+alongside the existing posture descriptors. Per flex-auth's T05 amendment, this
+declaration must also say whether a zone rides the **actor** (a flex-auth
+subject) or the **lane** (a flex-auth per-actor resource) — in the compiled
+registry an actor is both, and the compiler needs to be told which record
+carries membership. Carry the conformance rule:
 *accuracy, not altitude*. Declaring a stricter zone than can be evidenced is the
 failure mode that looks like progress.