@@ -0,0 +1,26 @@
+---
+'@objectstack/plugin-approvals': minor
+'@objectstack/spec': patch
+'@objectstack/lint': patch
+---
+
+feat(plugin-approvals): an approval step whose approvers resolve to no one opens on the organization's administrators under the default `onEmptyApprovers: 'admin_rescue'`, as ordinary approvers in their inbox
+
+Clause-②: yes
+
+**FROM → TO: who receives an `admin_rescue` request.** A node whose approvers resolve to no concrete person (an unstaffed position, an empty team or department, an unset manager, an expression that yields no one) under the default `onEmptyApprovers: 'admin_rescue'`:
+
+- **FROM:** the request opened on a slate that named no one, such as the literal `position:sales_manager`. It was in no one's "My Pending", the bell counted 0, no one was told, and a `lockRecord: true` record stayed locked until a platform or tenant admin found it under **All** and decided it through the privileged override.
+- **TO:** the request opens on the request organization's administrators: the people who hold the organization-admin capability (`organization_admin` or `organization_admin_no_bypass`, ADR-0095 D3) in that organization. That is the same authority that lets a tenant admin override a request, resolved to the people who hold it, through the same grant resolution every request runs. An organization's owners and admins receive the capability automatically.
+
+They are ordinary approvers. The request is listed and counted for each of them under their own `approverId`, each is told once by `approval.requested`, out-of-office delegation applies to them, and a decision by one of them is an ordinary approval or rejection, recorded with `via_override: false`. The node's `behavior` reads them as one group. A platform administrator is not added for being one; one who also holds the organization's capability, such as its owner, is on the slate for that.
+
+The request says why. Its timeline carries a note, for example "Routed to this organization's administrators because the approver slate named no one: position 'sales_manager' has no holder.", and its node-config snapshot keeps the abandoned slate and the reason under `__resolvedFrom` (`admin_rescue:abandoned`, `admin_rescue:reason`). The abandoned slate is replaced, not kept beside the administrators, so a holder staffed into the position after the request opened does not receive it; an administrator can reassign it to them.
+
+**Unchanged.** A slate that names a person; `fallback`, `auto_approve` and `fail`; a `fallback` whose own list resolves to no one still degrades to `admin_rescue`, which now opens on the administrators. The privileged override stays for what the administrators' slate cannot reach: a request whose named approvers have all left after it opened, and an organization with no administrator (or a request with no organization), where the request still opens on the slate that names no one and the server logs a warning.
+
+**To name the person who should decide instead of the administrators,** declare `onEmptyApprovers: 'fallback'` with a `fallbackApprovers` list.
+
+**`@objectstack/spec`:** the `onEmptyApprovers` description says that `admin_rescue` opens on the organization's administrators and that `fallback` names who decides instead.
+
+**`@objectstack/lint`:** `approval-approvers-may-resolve-empty` no longer says the request "waits forever": it says the request opens on the organization's administrators, its remedy names `onEmptyApprovers: 'fallback'` as the way to name who decides, and its `os explain` text says the same.
@@ -104,13 +104,14 @@ through a provisioning path your own deployment supplies: this platform declares
 surface that authors its manager.
 
 Setting the column is still something you have to *do*. Where `manager_id` is unset the rung
-expands to nobody, the request opens on a slate no one can act on, and under the default
-`lockRecord: true` the record stays locked — recoverable only by a platform or tenant admin
-override. So set it for everyone who submits this request, or take one of the two escapes that
-need no write to the column at all: add a second approver entry that cannot resolve empty — e.g.
-`{ type: 'org_membership_level', value: 'owner' }` — or declare `onEmptyApprovers: 'fallback'`
-on the node with a `fallbackApprovers` list, so an empty manager rung opens the request on those
-people instead. Neither makes `manager` resolve; they make the failure survivable, which is a
+expands to nobody, and under the default `onEmptyApprovers: 'admin_rescue'` the request opens on
+the organization's administrators instead of on the submitter's manager
+([When a slate names no one](#when-a-slate-names-no-one)). So set it for everyone who submits this
+request, or take one of the two escapes that need no write to the column at all: add a second
+approver entry that cannot resolve empty — e.g. `{ type: 'org_membership_level', value: 'owner' }`
+— or declare `onEmptyApprovers: 'fallback'` on the node with a `fallbackApprovers` list, so an
+empty manager rung opens the request on those people instead of on the administrators. Neither
+makes `manager` resolve; they route the request to the person who should decide it, which is a
 different and independently useful thing. `os lint` reports the shape at authoring time
 (`approval-approvers-may-resolve-empty`, `info`) and carries the same remedy text, so the two
 cannot drift apart — and it keeps reporting it even with a fallback declared, because a static
@@ -289,16 +290,16 @@ empty slate you can see than a task the tenancy wall hides.
 
 A result may legitimately be **empty** (a present-but-empty field or variable);
 the node-level `onEmptyApprovers` policy decides what that means —
-`admin_rescue` (default: the request opens, a privileged admin takes over via
-Reassign), `fail` (the node fails: an empty slate is a config bug),
+`admin_rescue` (default: the request opens on the organization's administrators —
+[When a slate names no one](#when-a-slate-names-no-one)), `fail` (the node fails: an empty slate is a config bug),
 `auto_approve` (skip the request and continue down `approve` with
 `output.autoApproved = true`; opt-in, since it waves the record through), or
 `fallback` (open the request on the people named in `fallbackApprovers`). A
 **missing** key (`vars.never_written`) is a loud error instead — guard
 genuinely-optional inputs with `has(vars.x) ? vars.x : []`.
 
-`fallback` is the only one of the four that **names people**, so it is the only
-one that turns an empty slate into a request someone can actually decide:
+`fallback` is how a node **names who decides** an empty slate, instead of leaving it to
+the organization's administrators:
 
 ```ts
 {
@@ -320,8 +321,9 @@ before the node opens any approval request.
 
 Prefer a fallback target that cannot itself resolve empty (a literal `user`, or
 the `owner` membership tier). If it does resolve empty the node degrades to
-`admin_rescue` — the request still opens and the run is never killed — and the
-log says both that the fallback fired and that it found nobody.
+`admin_rescue` — the request opens on the organization's administrators and the
+run is never killed — and the log says both that the fallback fired and that it
+found nobody.
 
 The "previous approver picks the next step's approvers" loop needs no record
 field at all: declare `decisionOutputs: ['next_reviewers']` on node A, have the
@@ -349,8 +351,9 @@ where nothing reads the outputs. Enforcement has no elevation bypass — a
 one-click email action link and an `auto_approve` SLA escalation both fail
 rather than advance into a node that would resolve nobody, leaving the request
 pending and visibly overdue. Without the flag your only backstop is
-`onEmptyApprovers` — the next node opens, resolves nobody, and stalls for an
-admin rescue long after the approver who could have filled it in has gone.
+`onEmptyApprovers` — the next node opens, resolves nobody, and lands on the
+organization's administrators long after the approver who could have filled it in
+has gone.
 
 ## The full lifecycle — submit to field change
 
@@ -409,8 +412,47 @@ What an entry that resolves to nobody leaves on the slate depends on its kind:
 - **A slate left empty, or holding only literals,** goes to the node's
   `onEmptyApprovers` policy, whose four values are listed under
   [Approving across organizations](#cross-org-approvers). Under the default,
-  `admin_rescue`, the request opens on that slate and waits for an
-  administrator, or for a holder of a `position:` literal on it.
+  `admin_rescue`, the request opens on the organization's administrators
+  instead.
+
+#### When a slate names no one [#when-a-slate-names-no-one]
+
+Under the default `onEmptyApprovers: 'admin_rescue'`, a slate that names no
+person opens the request on the **organization's administrators**: the people
+who hold the organization-admin capability (`organization_admin` or
+`organization_admin_no_bypass`, ADR-0095 D3) in the request's organization. An
+organization's owners and admins receive that capability automatically. It is
+the same authority that lets a tenant admin override a request, resolved to the
+people who hold it.
+
+They are ordinary approvers:
+
+- the request is in each administrator's queue and counted in their bell, under
+  their own `approverId`, as for any approver;
+- each is told once, by `approval.requested`, and out-of-office delegation
+  applies to them as to any named approver;
+- a decision by one of them is an ordinary approval or rejection, recorded with
+  `via_override: false`. The node's `behavior` reads them as one group: under
+  `first_response`, or `per_group` with the default `minApprovals`, one of them
+  decides; `unanimous` and `quorum` count them as they count any slate.
+
+A platform administrator is not added for being one: that standing crosses the
+tenant wall, and the slate is the organization's own. One who also holds the
+organization's capability, such as its owner, is on the slate for that.
+
+The request says why. Its timeline carries a note, for example *Routed to this
+organization's administrators because the approver slate named no one: position
+'sales_manager' has no holder.*, and its node-config snapshot keeps the abandoned
+slate and the same reason under `__resolvedFrom` (`admin_rescue:abandoned`,
+`admin_rescue:reason`). The abandoned slate is replaced, not kept beside them: a
+holder staffed into the position after the request opened does not receive it,
+and an administrator can reassign it to them.
+
+To name the person who should decide instead, declare
+`onEmptyApprovers: 'fallback'` with `fallbackApprovers`. Only an organization
+with no administrator, or a request with no organization, still opens on the
+slate that names no one: the server logs a warning, no one is told, and only the
+admin override decides it.
 
 ### The approver finds it in their queue
 
@@ -453,28 +495,7 @@ position under as their own identity. The deprecated pre-rename prefix is no
 alias of it (ADR-0090 D3): it matches only a slot stored under that exact
 spelling, and no holder acts under it.
 Other filters: `status`, `object`, `recordId`, `submitterId`, `q`, `limit`,
-`offset`, and `unstaffed`.
-
-`unstaffed=true` adds the pending requests whose slate names no person: only
-unstaffed literals such as `position:<name>`, or nothing at all. This is what
-`admin_rescue` opens. They
-are added only for a caller who may override them: an admin with override
-authority (`admin_full_access`, or `organization_admin` within their
-organization). Every such row reads `viewer.can_override: true`. For anyone else the parameter
-adds nothing. It is ORed with `approverId`, never ANDed, so one call answers
-"my pending approvals, rescues included", and its `total` counts both:
-
-```bash
-curl -b cookies.txt \
-  "https://your-app.example.com/api/v1/approvals/requests?status=pending&approverId=usr_123&unstaffed=true"
-```
-
-It reads `true` or `false` only (`false` is the same as leaving it out); any
-other value is refused with `400`. The test reads the slate, not the directory:
-a `position:<name>` slot whose position gained a holder after the request opened
-still matches (that holder also finds it under `approverId`), and a slate that
-still names a person never matches, even if that person has since left.
-Reassign such a request from the **All** view.
+and `offset`.
 
 <Callout type="warn">
 **`approverId` is a filter, not authorization.** What you may see is decided
@@ -499,15 +520,17 @@ question back to this service via `fileAccessDelegate`).
 **Opening a step tells its approvers.** When a request opens, each concrete
 approver on its slate gets one `approval.requested` notification ("Approval
 requested", linked to that request in the Approvals Inbox): a named user, every
-holder of a staffed position or member of a team, and the `fallbackApprovers`
-when the node's `onEmptyApprovers: 'fallback'` opened on them. It goes through
+holder of a staffed position or member of a team, the `fallbackApprovers`
+when the node's `onEmptyApprovers: 'fallback'` opened on them, and the
+organization's administrators when the default `admin_rescue` opened on them. It goes through
 the installed messaging service, the same way as the reminder, reassignment,
 escalation, and return notifications, and the same delivery preferences apply.
 Without a messaging service, no approval notification is delivered at all.
 
 Two cases tell nobody by design. A slot no one holds (`position:<name>` with
-no holders) names no person, so a step that resolves to nobody notifies no
-one: its `onEmptyApprovers` policy decides what happens instead. An
+no holders) names no person, so it is told nothing; a step whose whole slate
+names no one is decided by its `onEmptyApprovers` policy, and only in an
+organization with no administrator does the default leave no one to tell. An
 out-of-office delegate gets one message, `approval.ooo_substituted`, not a
 second one for the opening.
 
@@ -711,9 +734,12 @@ admin can rescue a stuck request. The service stays the sole authority — the
 predicate only trims the UI.
 
 <Callout type="info">
-**Admin override — recovering a stuck request.** An approval routed to a
-`position` / `team` / `department` with **no holders** resolves to only its
-`<type>:<name>` literal in `pending_approvers`. A `position:<name>` slot is
+**Admin override — recovering a stuck request.** A slate that names no one
+opens on the organization's administrators under the default `admin_rescue`
+([When a slate names no one](#when-a-slate-names-no-one)), so the override is
+break-glass for what that cannot reach: a request whose named approvers have all
+left after it opened, and an organization with no administrator, where the
+request opens on its `<type>:<name>` literals. A `position:<name>` slot is
 decided by whoever holds that position once someone is staffed into it; until
 then — and for a `team` or `department` literal, always — no concrete user can
 act, and (with `lockRecord`) the record stays locked. A **platform admin**