Record the operator's acceptance of ops-mason's plan-approval gate.

Founder plan approval is accepted as the gate for ops-mason's phase-4
protected writes, as an operator-accepted exception to section 6.4, not a
change to the standard. Review 2026-12-21.

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

docs/ops-mason-plan-approval-gate-decision.md

@@ -0,0 +1,40 @@
+# ops-mason plan-approval gate: operator decision
+
+**Decided by:** Bernd Worsch, operator. **Date:** 2026-09-21. **Recorded by:** the-custodian.
+
+## Decision
+
+The founder's approval of an ops-mason construction plan (`plan.is_approved()`) is **accepted as the gate** for ops-mason's phase-4 protected changes. These are the changes it covers:
+
+- writing OpenBao policies, and auth roles on `auth/approle` and `auth/kubernetes`
+- creating AppRole secret_ids
+- `kubectl apply` of Kubernetes objects
+
+These changes do not additionally require an access-engine decision.
+
+## What kind of decision this is
+
+This is an **operator-accepted exception**, not a change to the standard.
+
+- §6.4 obligation 1 of the security layer model still requires a PEP-shaped repository to act on a PDP decision.
+- ops-mason still does not meet that obligation, and this decision does not say that it does.
+- What changes is the status of the gap. It was undecided; it is now accepted by the operator, with a stated reason and a review date.
+
+Amending §6.4 to recognise operator plan approval as a PDP-equivalent would be a canon change. That goes through gate-house and net-kingdom, and nobody has proposed it.
+
+## Why
+
+ops-mason's construction plans are drafted and self-reviewed by an agent, then approved by the founder before phase 4 runs. For the actions above, the founder is the deciding party, and the decision is made per plan, with the plan's content in view. The operator judges that an explicit, per-plan human approval is an adequate gate for these writes at the estate's current scale.
+
+## Conditions
+
+- **Only these changes are covered.** The exception covers the phase-4 actions listed above, as ops-mason declared them in its INTENT.md frontmatter on 2026-09-21 (ops-mason@0ff263a). A new class of protected change is not covered until the operator accepts it.
+- **Structure only.** ops-mason's own declared capability is "structure only, never secret values". The exception depends on that holding.
+- **Review 2026-12-21.** That is the date ops-mason already set on the gaps. At review, the operator either renews the exception or asks for these writes to route through access-engine.
+- **Still declared.** The gaps stay declared, not removed, and are marked accepted rather than open. A conformance run must report them as accepted exceptions, not as conformance.
+
+## Consequences for other records
+
+- **ops-mason:** records the decision against its declared gaps and its `pep_stance` entry, which currently lists "remain founder-approval-gated only" as an open option.
+- **gate-house:** records it as an operator-accepted exception against §6.4 and the §13.1 stance-map row. The exception is noted in gate-house's own records, not in canon.
+- **Kubernetes:** the question of which engine, if any, should own the `kubectl apply` contact stays open with gate-house. This decision accepts the gate for that contact; it does not name an owner.