Record production gap for FLEX-WP-0010 and re-probe FLEX-WP-0009

FLEX-WP-0010-T04: the deployed flex-auth-tenant-engine Deployment bakes
the policy package into its image, so production still serves the
four-action policy -- probed live, tenant.retire returns deny
unknown_action there while tenant.create allows. TEN-WP-0005-T05 is
unblocked in source but needs an image build from 8e127e5 and a rollout,
which this workplan does not scope. Stated in the workplan and in
examples/tenant-engine/README.md rather than left implied.

FLEX-WP-0009-T04: replayed all six user-engine fixtures against the
deployed flex-auth-user-engine service; all six matched expected effect
and reason, confirming the deployed failure matrix is still fail-closed.
T04 stays in progress -- the criterion also requires user-engine to
retire its local bridge, which is not flex-auth's to close.

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

examples/tenant-engine/README.md

@@ -74,6 +74,12 @@ covered by fixture and by
 driven through the client, which only ever emits the seven registered strings
 — which is the property the guard exists to protect.
 
+**Not yet in production.** The policy package is baked into the container
+image, so the deployed `flex-auth-tenant-engine` Deployment still serves the
+pre-FLEX-WP-0010 four-action policy — probed 2026-08-10, `tenant.retire`
+returns deny `unknown_action` there. A new image built from this commit and
+rolled out is the remaining step before a live lifecycle mutation succeeds.
+
 ## Related
 
 - `docs/tenant-engine-resource-namespace.md`

workplans/FLEX-WP-0009-user-engine-production-policy-service.md

@@ -103,3 +103,22 @@ availability bypass and the deployed failure matrix remains fail closed.
 with decision `decision:4bf95ebb989ac628`; the cross-tenant variant returned
 deny/cross_tenant with decision `decision:bab072ce3ee72d98`. Runtime activation
 remains gated on the separately owned event and mail receivers.
+
+2026-08-10 re-probe: all six policy fixtures were replayed against the
+**deployed** `flex-auth-user-engine.flex-auth.svc.cluster.local:8080` and
+every one matched its expected effect and reason —
+`self-allow` `decision:27cbab2e5533508a` allow/`self_service`;
+`tenant-admin-allow` `decision:350b46fb42989606` allow/`tenant_admin`;
+`platform-allow` `decision:79334537419466bd` allow/`platform_operator`;
+`cross-tenant-deny` `decision:b3cc0b7e819aecde` deny/`cross_tenant`;
+`missing-role-deny` `decision:818e2249491ef09f` deny/`no_matching_role_or_context`;
+`wrong-system-deny` `decision:5e20697e202aa7c6` deny/`wrong_system`.
+The deployed failure matrix is therefore confirmed still fail-closed 42h
+into the current rollout.
+
+**Still open, and not flex-auth's to close:** the done-criterion is that
+*user-engine* replaces its local authorization bridge without an
+availability bypass. That cutover is user-engine's decision and remains
+gated on the separately owned event and mail receivers. flex-auth has
+delivered and re-verified the service side; T04 stays `progress` rather
+than being marked done on evidence that only covers half the criterion.

workplans/FLEX-WP-0010-tenant-lifecycle-policy-actions.md

@@ -221,4 +221,23 @@ profile `caring-0.4.0-rc2`, now carrying all seven actions — the version
 string is unchanged because the package is additive and `v1` remains the
 activated revision; the identifying fact for TEN-WP-0005-T05 is that `v1` as
 of this commit contains `tenant.update`, `tenant.retire`, and
-`tenant.reactivate`. `TEN-WP-0005-T05` is unblocked.
+`tenant.reactivate`.
+
+**Production is not yet serving this policy — stated plainly because
+TEN-WP-0005-T05 depends on it.** The policy package is baked into the
+flex-auth container image, not mounted from a ConfigMap: the deployed
+`flex-auth-tenant-engine` Deployment in namespace `flex-auth` runs image
+`@sha256:c25fc34a6cd7e64d955f8723ec70e176a583d5ae71d76280c4e2d89fba0fe0aa`
+with `--policy /opt/flex-auth/examples/tenant-engine/policy_package.md`
+from that image. Probed live on 2026-08-10 via port-forward:
+`tenant.retire` still returns **deny `unknown_action`**, while
+`tenant.create` returns allow — i.e. the running instance is the
+pre-FLEX-WP-0010 four-action policy.
+
+So `TEN-WP-0005-T05` is unblocked **in source** but not **in the cluster**
+until a new image is built from commit `8e127e5` and rolled out. That
+rollout is a production deploy that this workplan does not scope (contrast
+FLEX-WP-0007 and FLEX-WP-0009-T03, which carried explicit deployment
+tasks) and it is deliberately left for an owner decision rather than done
+implicitly under a policy-authoring workplan. It is the single remaining
+step between this commit and a live lifecycle mutation.