Sole-Maintainer Approval

An approval is four-eyes: the approver is never the requester. The ONE exception is the installation's DECLARED maintainer, who may approve a request they filed themselves — and every such approval is stamped on the node, written to its log and shown on its page as "self-approved by maintainer", who and when. Everyone else still needs a different approver. Policy sole-maintainer-approval (register).

Why

A single-maintainer estate runs its agents through the maintainer's own credential, so nearly every pending request — a Reconcile, a Recycle, an operation request — is filed under the maintainer's identity. Four-eyes then leaves the estate with nobody who may approve anything at all. The alternatives are worse: an agent identity that approves on the maintainer's behalf moves the decision to a machine, and a standing admin bypass makes it silent. The exception is therefore NAMED (one person), DECLARED (configuration a governed change controls, never a node any administrator can edit), and AUDITED (it can never look like a second person's approval).

The rule — one function, three gates

The decision lives in ONE place, SoleMaintainerApproval.Decide(requester, approver, maintainer) (MeshWeaver.Plugins Store/Core/Source/SoleMaintainerApproval.cs), shared by source into every gate:

Identities are compared trimmed and case-insensitively. The rule decides ONLY the self-approval question: every gate's global-administrator check, binding, freshness and single-use checks are unchanged.

Where the maintainer is declared

The installation's maintainer is the configuration key Hosting:Operator:Maintainer, which the deployment record's operator.maintainer renders (Hosting__Operator__Maintainer; HostingOperatorSpec.Maintainer). The key kept its historical name, from when it covered only the instance-action Actions path. It now holds for every approval gate of the installation: instance actions on any executor, and operation requests. Absent, nobody may approve their own request. It is deliberately NOT a node: a node in the Admin partition would let any global administrator name themselves and approve their own requests — the very bypass the rule exists to prevent. Changing the record is itself a governed Reconcile that someone approves. A Governance standard may name a narrower maintainer for that standard alone (authority.maintainer, committed content); the decision is the same function either way.

Signing alone — a count-of-signers gate on a one-person installation

Self-approval decides WHO may approve; it does not change HOW MANY must. A governed activity's Signatures gate counts distinct signers, so a count: 2 gate (package.provision on a standard installation) can never go green where only one person exists — the maintainer's own signature counts as one. A second, separately declared key lets that ONE signature satisfy the gate:

It is declared for the same reason the maintainer is: a node or a standard field an administrator can write would let them make a two-person rule a one-person rule for themselves. Nothing else loosens — the maintainer's signature must still be their own write, eligible under the standard's signers, bound to the current content, younger than the acceptance and the signature lifetime, and unconsumed; every other signer counts as before. Meant for a single-person installation with no confidential data (a test instance).

It is audited like a self-approval: the gate's detail reads 1/2 — <id> (signed alone as sole maintainer, policy sole-maintainer-approval, Hosting:Operator:MaintainerSignsAlone); the write that makes the activity ready stamps signedAloneBy / signedAloneAt and logs SIGNED ALONE BY MAINTAINER: '<id>' signed the activity '<standard>', and that one signature satisfied a gate asking for N signer(s) …; no second person signed; and the activity page shows Signed alone by maintainer (German: Allein von der verantwortlichen Person unterschrieben) through SoleMaintainerApproval.AloneLabel / AloneExplanation.

Audited, never silent

The page label and explanation are translated (English, German) through SoleMaintainerApproval.Label / Explanation; the log line is machine-facing English and UTC.

The approvals inbox

Hosting/Approvals (NodeType Hosting/ApprovalInbox) lists every item on THIS instance that waits for an approval and that the viewer can read: parked instance actions, approvable operation requests, and open governed activities. One fed grid (BindGrid + PropertyColumnControl): type, what it does, plan, filed by, filed, expires, "can you approve it?" and the live result; a row-scoped ☐/☑ selection; "Approve selected", "Reject selected", "Select every approvable row".

• No approval path of its own. An instance action is approved through its page's own Approve body (InstanceActionLayoutAreas.ApproveClick — bound to the plan the row showed, attested for the clicker); an operation request through its RequestedAction field (OperationRequestLayoutAreas.RequestActionAs). The item's own gate re-checks everything.
• Never offered: a superseded action (its supersededBy field, or a name marked SUPERSEDED), an expired park, an item the viewer filed and may not approve, and an action that cannot run where it lives (a Job-executed kind on an installation whose operator is off, a dispatched kind with no signing key). A bulk Approve SKIPS such a row by name even when it is selected.
• Reject retires an instance action through its own cancel field (supersededBy) and rejects an operation request through RequestedAction = Reject.
• Activities are listed, never selected: a signature is the signer's own act on the activity's page.
• Results are live, per row, read off each item's own node stream, and stay after the item leaves the pending set.
• One instance. An instance never reads another instance's requests; each has its own inbox at the same address, and the page says so.

Manual for operators: MeshWeaver.Plugins Hosting/ApprovalsInbox (get Hosting/ApprovalsInbox).