@@ -0,0 +1,17 @@
+---
+"@objectstack/spec": patch
+"@objectstack/client": patch
+"@objectstack/rest": patch
+"@objectstack/cli": patch
+---
+
+docs: the suggested-binding acceptance is deployment-level and takes effect
+
+Clause-②: no
+
+Text only. These are the published sentences that describe what confirming a package's `isDefault` suggestion does. They now match the behaviour `@objectstack/plugin-security` ships in this release.
+
+- `@objectstack/spec`: `ISecurityService.listAudienceBindingSuggestions`, `confirmAudienceBindingSuggestion` and `dismissAudienceBindingSuggestion` keep "writes the binding" for the confirm. The text now also says what that means: a `manage_metadata` holder accepts once for the deployment, `everyone`'s definition is derived again, and a dismiss on an accepted suggestion revokes it. The package-level `isDefault` note keeps "an admin confirms in Setup" and adds who that admin is.
+- `@objectstack/client`: the `security.suggestedBindings.confirm` and `.dismiss` TSDoc.
+- `@objectstack/rest`: the route summaries of the confirm and dismiss routes. Paths and envelopes are unchanged.
+- `@objectstack/cli`: the ownership-inventory citation for `sys_audience_binding_suggestion` now says the record is deployment-level and owned by the Default Organization.
@@ -0,0 +1,30 @@
+---
+"@objectstack/plugin-security": minor
+---
+
+feat(plugin-security)!: accepting a package's `isDefault` suggestion takes effect for the whole deployment
+
+Clause-②: yes (narrowing)
+
+**BREAKING.** A package's `isDefault: true` permission set now reaches every signed-in member through ONE deployment-level acceptance, and the acceptance takes effect. Before this release a confirm wrote a `sys_position_permission_set` row that granted nothing.
+
+- **What an accept does.** `POST /api/v1/security/suggested-bindings/:id/confirm` records the decision once for the deployment, and the security plugin derives the `everyone` anchor's definition again as the baseline plus every accepted set. The derivation also runs at boot, on uninstall and on a package-door publish. A member's reads of the package's objects change on the next request. `bindingCreated` is `true` when the definition did not name the set before.
+- **Who may decide (narrowing).** All three routes now need the `manage_metadata` capability, and under a `group` or `isolated` tenancy posture the platform operator. Before this release a tenant administrator (the `*` wildcard holder) listed, confirmed and dismissed suggestions for their organization. That caller is now refused `403 PERMISSION_DENIED`. Remedy: a `manage_metadata` holder decides, once for the deployment.
+- **The record is the deployment's.** `sys_audience_binding_suggestion` rows are owned by the Default Organization. A deployment with no Default Organization (several organizations, none with slug `default`) answers `409 SUGGESTION_STATE` with the remedy.
+- **Rows written before this release are never promoted.** A Default Organization row a tenant administrator confirmed or dismissed is set back to `pending`, unless the baseline already names the set. A row another organization owns, or none, is not read. Boot logs a warning with the count. Such rows granted nothing before this release and grant nothing after it.
+- **The high-risk gate is on the definition (ADR-0090 D7).** Accepting a set that carries a bit the `everyone` anchor forbids answers `403 PERMISSION_DENIED`. If a publish later adds such a bit to an accepted set, the derivation withholds it and logs an `error` that names the set.
+- **Revoke.** `POST …/:id/dismiss` on an accepted suggestion revokes it, and `everyone` is derived again without the set. A set that only the baseline names (`confirmed`, no resolver) cannot be dismissed (`409`).
+- **Only `everyone`.** A `guest`-anchor suggestion is refused `409`, because accepting it would record a grant that never takes effect.
+- **The anchors stay sealed.** No caller writes `everyone`'s definition. An acceptance changes the derivation's input, and the plugin re-declares the definition. Reconciliation reads that definition and no binding row.
+- **Declarations come from the security catalog.** A suggestion is offered for an `isDefault` set that the catalog serves with an owning package, which is the source the authorization resolver reads. The module no longer reads `sys_position`, `sys_permission_set` or `sys_position_permission_set`. It also no longer materializes a set.
+- **New field:** `sys_audience_binding_suggestion.deployment_decision`, a boolean that is `true` when a `manage_metadata` holder resolved the row.
+
+Exported TypeScript surface (the compiler names each caller):
+
+- Removed: `reapOrganizationLessSuggestions`, `listSuggestionOrganizationIds` and the `SuggestionReconcileScope` type. Nothing replaces them, because the record is no longer per organization.
+- `reconcileAudienceBindingSuggestions` and `syncAudienceBindingSuggestions` now take `(ql, logger)`. The metadata, scope and organization parameters are gone.
+- `SuggestionReconcileOutcome` reports `unread` in place of `organizations` and `reaped`. `SuggestionSyncOutcome` gains `reopened`.
+- `SuggestionDeps` drops `resolveSets` and takes `posture` and `rederiveEveryone`.
+- New: `readAcceptedEveryoneSets(ql, metadata)` and the `WithheldAcceptance` type.
+
+<!-- adr-0087: not-required (runtime-interface-only packages/plugins/plugin-security/src/suggested-audience-bindings.ts#SuggestionDeps, packages/plugins/plugin-security/src/suggested-audience-bindings.ts#SuggestionReconcileOutcome) TypeScript service plumbing with no metadata surface; the compiler names every caller, and no stored row or authored key changes shape (the new object field defaults to false) -->
@@ -428,6 +428,18 @@ as the flow and action activation switches. The two audience anchors,
 `everyone` and `guest`, are refused with `400` in either direction: one row
 would switch the authenticated or anonymous baseline off for every principal.
 
+The anchors are sealed against every caller-reachable write: this door, the
+metadata door and an organization overlay all refuse them. A package's
+`isDefault` set still reaches every signed-in member, and the seal reads this
+way: an **acceptance changes the input of a derivation, and no caller writes
+the anchor's definition**. The security plugin is the only declarer of
+`everyone`'s definition. It derives it as the deployment's baseline plus each
+package default a `manage_metadata` holder accepted, and re-declares it on
+every accept, revoke, uninstall and package publish. The acceptance record is
+one row per suggestion, owned by the Default Organization, and the
+high-privilege gate runs on the definition each time it is derived. See
+[Permission sets](./permission-sets).
+
 - A deactivated **permission set** contributes nothing: not its name, not its
   `system_permissions`, not its `tab_permissions`. As with an expired grant, a
   deactivated unscoped `admin_full_access` no longer derives `platform_admin`
 
@@ -253,38 +253,55 @@ hand.
 ## Package suggestion — `isDefault` (ADR-0090 D5)
 
 A package may mark one of its sets `isDefault: true`: an **install-time
-suggestion** to bind it to the `everyone` anchor. The admin confirms each
-suggestion individually; nothing auto-binds, and the D7 linter rejects an
+suggestion** to give it to every signed-in member through the `everyone`
+anchor. An admin holding `manage_metadata` accepts each suggestion once, for
+the whole deployment; nothing auto-binds, and the D7 linter rejects an
 `isDefault` set that carries anchor-forbidden bits (VAMA, destructive bits,
 system permissions). A plain `'*'` wildcard grant is *not* an anchor-forbidden
 bit for `everyone` — the platform's own `member_default` baseline is exactly
 that shape; the wildcard ban is the stricter `guest` tier's rule.
 
-Pending suggestions are materialized as `sys_audience_binding_suggestion`
-rows (one per organization × package × set × anchor, read-only over the data
-API) and resolved through the security surface — both installing a package at
-runtime and declaring the set in the stack produce them:
+Suggestions are materialized as `sys_audience_binding_suggestion` rows (one
+per package × set × anchor for the deployment, owned by the Default
+Organization, read-only over the data API) and resolved through the security
+surface — any `isDefault` set the security catalog serves with an owning
+package produces one:
 
 ```http
 GET  /api/v1/security/suggested-bindings?status=pending   # list (reconciles first)
-POST /api/v1/security/suggested-bindings/:id/confirm      # create the everyone binding
-POST /api/v1/security/suggested-bindings/:id/dismiss      # decline the prompt
+POST /api/v1/security/suggested-bindings/:id/confirm      # accept: everyone carries the set
+POST /api/v1/security/suggested-bindings/:id/dismiss      # decline, or revoke an acceptance
 ```
 
 `status` accepts `pending`, `confirmed` or `dismissed`, and may be omitted to
 list every suggestion. Any other value is rejected with a `400` naming the
 accepted set — it previously reached the query as a filter nothing matched, so
 a mistyped status returned an empty list that read as "no suggestions".
 
-All three require a tenant-level administrator (the anchors are tenant-level
-only — D12). Confirm writes a `sys_position_permission_set` row **as the
-caller**, so the audience-anchor gate re-checks the forbidden-bits predicate
-at the data layer. That row does not grant the set: what `everyone` grants is
-the `permissionSets` its definition names, so a confirmed suggestion changes no
-one's access until the set is named there. A suggestion whose binding was created out-of-band (boot
-baseline, manual bind) is marked `confirmed` automatically, and uninstalling
-the package prunes its pending suggestions. Studio surfaces pending
-suggestions after marketplace installs and in the Access pillar.
+All three require the `manage_metadata` capability, and under a walled
+tenancy posture the platform operator: the decision reaches every member of
+every organization, so a tenant administrator cannot make it. An acceptance
+takes effect at once. What `everyone` grants is the `permissionSets` its
+definition names, and the security plugin derives that definition as the
+deployment's baseline plus every accepted set — again on each accept, revoke,
+uninstall and package publish. No caller writes the definition itself (see
+[Authorization](./authorization)).
+
+- **The high-risk gate is on the definition.** Accepting a set that carries a
+  bit the `everyone` anchor forbids is refused with `403 PERMISSION_DENIED`;
+  if a later publish adds such a bit to an accepted set, the derivation
+  withholds it and logs why.
+- **Revoke** an acceptance by dismissing the accepted suggestion; uninstalling
+  the package removes its suggestions and its sets leave `everyone`.
+- A set the baseline already names (the served app's own `isDefault` set) is
+  marked `confirmed` without a resolver — observed, not accepted — and cannot
+  be dismissed here.
+- Only an `everyone` suggestion can be accepted. A decision a tenant
+  administrator recorded per organization before acceptances were
+  deployment-level is never carried over: the suggestion is pending again.
+
+Studio surfaces pending suggestions after marketplace installs and in the
+Access pillar.
 
 ## Delegated administration — `adminScope` (ADR-0090 D12)
 
 
@@ -182,7 +182,7 @@ The largest single consumer — **17 of the 122 sites**.
 | 54 | Package domain capability gates bypassed | runtime | Get: package management and package-inventory reads without the capability | `packages/runtime/src/domains/packages.ts#requireManageMetadata`, `#requireReadCapability` |
 | 55 | Activation write / authoring refusals do not fire | runtime | Get: activation artifacts writable and authorable without the activation-authoring capability | `packages/runtime/src/domains/activation-gate.ts#refuseUngrantedActivationWrite`, `#refuseUngrantedActivationAuthoring` |
 | 56 | Automation run-state read, flow-authoring write, the paused-run caller gate (screen read and resume), the two operator run-lifecycle writes and the elevated self-triggered start at every door that starts a flow by name all pass | runtime | Get: run state, flow writes, a paused run's screen and its resume with no grant and without being the run's starter — and cancelling or restoring a suspension without the platform-operator rung. The screen read and the resume ask one predicate, so this is one bypass for both. The lifecycle bypass is the in-process owner's door: plugin-approvals' revise-window recall (ADR-0044) cancels on behalf of a decision it already authorized and recorded. And starting a flow declared `runAs: 'system'` whose type is self-triggered (`autolaunched`, `record_change`, `schedule`) through any door that starts a flow by name — the trigger route, an action of `type: 'flow'` (REST `/actions` and the MCP `run_action` bridge) and a declared endpoint of `type: 'flow'` — which every other caller, the guest principal included, is refused `403 PERMISSION_DENIED` (the maintainer's rulings, letters B and A). The three doors ask one predicate, so this is one bypass for all of them, and it is the in-process caller's, such as a job: inbound HTTP never carries the flag | `packages/runtime/src/domains/automation.ts#mayReadRunState`, `#refuseUngrantedFlowWrite`, `#isRunStarterOrRunStateReader`, `#refuseUngrantedRunLifecycleWrite`, `packages/runtime/src/flow-start-admission.ts#refusesElevatedSelfTriggeredStart` |
-| 57 | Audience-binding suggestion recording skipped | plugin-security | Lose: install-time suggestions are not recorded for system callers | `packages/plugins/plugin-security/src/suggested-audience-bindings.ts#assertTenantAdmin` |
+| 57 | Audience-binding suggestion authority gate passes | plugin-security | Get: a system caller lists, accepts and dismisses suggestions without `manage_metadata` and, under a wall, without the platform-operator rung | `packages/plugins/plugin-security/src/suggested-audience-bindings.ts#assertDeploymentAuthority` |
 | 58 | Email-template organization door passes; webhook provenance stamp skipped | plugin-email, plugin-webhooks | Get (`sys_email_template`): a create or update of a template row. The door refuses every other write that names a caller, `403 PERMISSION_DENIED` (ADR-0131 D6), so the seeds, the boot sweep and the projection of a Studio save are the only writers. Lose (`sys_webhook`): the row is not marked as an admin customization | `packages/plugins/plugin-email/src/email-template-door.ts#isOrganizationWrite`, `packages/plugins/plugin-webhooks/src/webhook-provenance.ts#bindWebhookProvenanceStamp` |
 | 59 | **Automation flow data nodes re-add the `owner_id` stamp** (the one place row 2's gap is compensated inline) | service-automation | Get: a flow-authored INSERT under system elevation still lands owned, when the run resolved a user. Fill-only — flow-authored values win | `packages/services/service-automation/src/runtime-identity.ts#stampSystemInsertOwner`, called from `packages/services/service-automation/src/builtin/crud-nodes.ts#registerCrudNodes` |
 | 60 | Inbox caller refusal names `isSystem` as what was carried | service-messaging | Get: nothing — the refusal still fires. The flag only shapes the diagnostic, because privilege is not an authorization subject | `packages/services/service-messaging/src/inbox-caller.ts#resolveInboxRecipient` |