diff --git a/history/2026-10-08-oidc-rp-follow-through-review.md b/history/2026-10-08-oidc-rp-follow-through-review.md
index e27218e..c2e03bd 100644
--- a/history/2026-10-08-oidc-rp-follow-through-review.md
+++ b/history/2026-10-08-oidc-rp-follow-through-review.md
@@ -73,3 +73,36 @@ client view) and `secret-delivered` (R5). Every item keeps
 The justification is accepted: the live registry is a Kubernetes Secret.
 ops-warden groups those steps into one `key-cape-oidc-login` session and does
 not execute them. `hand-over` belongs to the consumer.
+
+## Addendum 2026-10-09: R4 reconciled with ops-mason item 5
+
+net-kingdom pointed out that R4 conflicts with MASON-WP-0010-T01 item 5
+(per-case `{consuming_service}-keycape-client`). On reflection, R4 was wrong
+as written. **R4 is withdrawn and replaced with R4′.**
+
+A single parameterized entry would have to carry `workload_ref: not-applicable`,
+as the generic `openbao-api-key` template does. That would drop the consumer's
+workload reference, and `ADR-0009` needs that reference to select the zone and
+PEP failure mode for this exact client. A per-case entry carries real
+per-consumer data. It is not a second copy of a procedure, so `ADR-0001` is not
+engaged.
+
+**R4′:** keep one catalog entry per case, named
+`{consuming_service}-keycape-client` (ops-mason's item 5). Template its
+**body** in the type, as item 3 now requires for policies, so that cases add
+values and never route design (WARDEN-WP-0044-T04). The body should contain:
+
+- `owner_repo: key-cape`, `warden_executes: false`, `risk: high`,
+  `status: active` once verification passes
+- `workload_ref: {applicability: applicable, name: {consuming_service},
+  declaration_ref: <consumer declaration>}`. If the consumer has not published
+  a declaration, the field takes the explicit unknown form, never an inferred one.
+- `path_template: platform/workloads/keycape/{client_id}`, field `CLIENT_SECRET`
+- `delegation: {mode: native, intended_owner: key-cape}`
+- `rotation` steps referencing the type's mint-secret and verification, with
+  `automatable: false` until a run has been proven
+
+Correction to R4: the existing `rapp-qonto-keycape-client` is a
+client-credentials workload client at a different path. It is not a browser
+relying party, so it would **not** become a case of this type. Only the naming
+precedent carries over.
diff --git a/workplans/WARDEN-WP-0044-security-case-follow-through.md b/workplans/WARDEN-WP-0044-security-case-follow-through.md
index 95ae058..e3c55d2 100644
--- a/workplans/WARDEN-WP-0044-security-case-follow-through.md
+++ b/workplans/WARDEN-WP-0044-security-case-follow-through.md
@@ -62,6 +62,10 @@ changes before T02: a per-step `lane`, a narrow `warden_executes`, and
 `value_handling`. It also lists four refinements. This task is done when
 net-kingdom acknowledges the review (NK-WP-0048-T05).
 
+2026-10-09: R4 was withdrawn in favour of ops-mason's per-case
+`{consuming_service}-keycape-client`, with the entry body templated in the type
+(R4′, see the addendum in the review).
+
 ```task
 id: WARDEN-WP-0044-T02
 status: wait