@voltro/plugin-notifications 0.54.0 → 0.56.0

package/dist/index.d.ts

@@ -380,10 +380,12 @@ export declare interface NotificationsPluginOptions {
      * `name` below: `alias` REPLACES the namespace, `name` distinguishes two
      * installations within it.
      *
-     * The cost, stated because nothing else states it: the local and cloud
-     * dashboards fetch this plugin's panel at the DEFAULT slug, so an aliased
-     * install keeps working while its dashboard panel 404s. Alias to escape a
-     * collision, not for taste.
+     * The dashboard panel follows: the plugin's inspect endpoints keep a mount
+     * under its CANONICAL name alongside the aliased one, so aliasing does not
+     * take the panel away. The one case it cannot cover is two installs of this
+     * plugin — one canonical name, two panels — which get no shared mount at
+     * all, on purpose. Read `inspectSlug` from `/_voltro/inspect/plugins` to
+     * reach a specific install.
      */
     readonly alias?: string;
     /**
@@ -403,10 +405,21 @@ export declare interface NotificationsPluginOptions {
      *
      * It is not offered on every plugin, and the omissions are deliberate rather
      * than unfinished: a `tables: false` that quietly disables a table carrying an
-     * AUTHORIZATION or SAFETY decision — the SAML replay cache, SCIM provisioning
-     * state, billing's usage counters, cdc-out's outbox — is a security regression
-     * shipped as an ergonomics feature. Those plugins need a named store seam
-     * first, not a boolean.
+     * AUTHORIZATION or SAFETY decision is a security regression shipped as an
+     * ergonomics feature. The SAML replay cache, SCIM provisioning state,
+     * billing's usage counters and cdc-out's outbox are EXAMPLES, not the whole
+     * list — read "not offered on that plugin" as the answer, never "so every
+     * other plugin's tables are safe to take over". Those plugins need a named
+     * store seam first, not a boolean.
+     *
+     * `plugin-storage` is the case that reads like an oversight and is not one.
+     * `_voltro_storage_grants` decides who may read and write an object, so it
+     * belongs to the paragraph above — but the field would not reach it in any
+     * case: storage's four tables are contributed as FRAMEWORK tables
+     * (`cli/src/frameworkTables.ts`, `when: 'always'`), not through `extendSchema`,
+     * so there is nothing for a `tables: false` to switch off. An app that wants
+     * to own the grant table needs a grant-store seam, and that seam does not
+     * exist yet.
      */
     readonly tables?: boolean;
     /**