@aglyn/aglyn 1.0.0-beta.151 → 1.0.0-beta.152

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@aglyn/aglyn",
-  "version": "1.0.0-beta.151",
+  "version": "1.0.0-beta.152",
   "license": "Apache-2.0",
   "homepage": "https://aglyn.com",
   "repository": {
@@ -33,15 +33,15 @@
     "./package.json": "./package.json"
   },
   "dependencies": {
-    "@aglyn/shared-data-enums": "1.0.0-beta.151",
-    "@aglyn/shared-data-mdi": "1.0.0-beta.151",
-    "@aglyn/shared-data-types": "1.0.0-beta.151",
-    "@aglyn/shared-util-email": "1.0.0-beta.151",
-    "@aglyn/shared-util-http": "1.0.0-beta.151",
-    "@aglyn/shared-util-logger": "1.0.0-beta.151",
-    "@aglyn/shared-util-timestamp": "1.0.0-beta.151",
-    "@aglyn/shared-util-tools": "1.0.0-beta.151",
-    "@aglyn/shared-util-vendor": "1.0.0-beta.151",
+    "@aglyn/shared-data-enums": "1.0.0-beta.152",
+    "@aglyn/shared-data-mdi": "1.0.0-beta.152",
+    "@aglyn/shared-data-types": "1.0.0-beta.152",
+    "@aglyn/shared-util-email": "1.0.0-beta.152",
+    "@aglyn/shared-util-http": "1.0.0-beta.152",
+    "@aglyn/shared-util-logger": "1.0.0-beta.152",
+    "@aglyn/shared-util-timestamp": "1.0.0-beta.152",
+    "@aglyn/shared-util-tools": "1.0.0-beta.152",
+    "@aglyn/shared-util-vendor": "1.0.0-beta.152",
     "@data-driven-forms/react-form-renderer": "^4.2.0",
     "@msgpack/msgpack": "^3.1.3",
     "@types/unist": "^3.0.3",

package/src/lib/app-utils/docs-index.generated.js

@@ -4237,7 +4237,7 @@ export const ASSIST_DOCS_INDEX = [
         title: 'Sequences',
         heading: 'Compliance settings',
         anchor: '#compliance-settings',
-        text: 'Every email a sequence sends ends with a footer saying who sent it, where they can be reached by post, that the email is a business solicitation, and how to stop more of them:\nThe United States\' CAN-SPAM Act requires those things of a commercial email, so the footer is added to every email after your text — no template or merge field can leave it off. You set what it says in Sequences → Compliance:\n- Legal name — your organization\'s legal name, as the footer prints it.\n- Brand name — the name the solicitation sentence uses, when it isn\'t the legal name. Leave it empty to use the legal name.\n- Postal address — a valid physical postal address: a street address, a post office box registered with the US Postal Service, or a private mailbox registered with the US Postal Service under its rules for commercial mail receiving agencies. Write it over as many lines as it takes; the footer prints them on one line.\nNo sequence can be activated while the legal name or the postal address is empty, and an email with neither is never sent.\nAllowed countries {#allowed-countries}\nThe countries a sequence may send to at all, United States by default. Every sequence sends only to the countries both it and this list allow, so taking a country off here takes it off every sequence at once.\nThe others are off because the law is different there. Canada, the United Kingdom and most of the European Union require a consent basis that an email to someone who never contacted you does not have. So a cold email — to someone who never filled in a form, signed up, ordered or booked with you, or wrote to you — never goes outside the United States, whatever this list says. Add another country only for people who came to you first.'
+        text: 'Every email a sequence sends ends with a footer saying who sent it, where they can be reached by post, that the email is a sales email, and how to stop more of them:\nThe United States\' CAN-SPAM Act requires those things of a commercial email, so the footer is added to every email after your text — no template or merge field can leave it off. You set what it says in Sequences → Compliance:\n- Legal name — your organization\'s legal name, as the footer prints it.\n- Brand name — the name the solicitation sentence uses, when it isn\'t the legal name. Leave it empty to use the legal name.\n- Postal address — a valid physical postal address: a street address, a post office box registered with the US Postal Service, or a private mailbox registered with the US Postal Service under its rules for commercial mail receiving agencies. Write it over as many lines as it takes; the footer prints them on one line.\nNo sequence can be activated while the legal name or the postal address is empty, and an email with neither is never sent.\nAllowed countries {#allowed-countries}\nThe countries a sequence may send to at all, United States by default. Every sequence sends only to the countries both it and this list allow, so taking a country off here takes it off every sequence at once.\nThe others are off because the law is different there. Canada, the United Kingdom and most of the European Union require a consent basis that an email to someone who never contacted you does not have. So a cold email — to someone who never filled in a form, signed up, ordered or booked with you, or wrote to you — never goes outside the United States, whatever this list says. Add another country only for people who came to you first.'
     },
     {
         path: '/content-and-data/crm/sequences',
@@ -4937,7 +4937,7 @@ export const ASSIST_DOCS_INDEX = [
         title: 'Building feature plugins',
         heading: 'Remote bundles: the trusted realm tier (AGL-420)',
         anchor: '#remote-bundles-the-trusted-realm-tier-agl-420',
-        text: 'Marketplace plugins normally run sandboxed in the cross-origin PluginFrame. Listings a staff member has reviewed and signed (trust: \'realm\' + an Ed25519 signature over the bundle\'s sha256 on the version doc) instead load INTO the app realm and use every registry above — first-party-grade extensions installed per workspace, no repo change.\n- Build with tools/plugin-loader/realm/rollup.config.mjs: your react, react/jsx-runtime, and @aglyn/aglyn imports compile to lookups on globalThis.AGLYNPLUGINHOST (the app\'s own singletons), so the emitted bundle imports nothing. Export register(host) for client surfaces; registerApi() for server handlers.\n- Publish through the marketplace pipeline, install (pins {version, sha256}), then staff grant trust via POST /api/admin/sign-plugin.\n- The console loads an org\'s realm installs before the shell renders; published sites load them post-hydration (additive runtimes — first paint never waits on a marketplace CDN). Every load verifies the sha256 pin and the platform signature and fails closed; revocations is the hard kill switch.\n- Server handler bundles are additionally gated by PLUGINREMOTESERVER=enabled + a per-deploy PLUGINREMOTESERVERBUNDLES allowlist, default off everywhere.\nFull trust chain, env matrix, and walkthrough: docs/PLUGINLOADING.md in the repo; a runnable demo lives at tools/plugin-loader/realm/demo.'
+        text: 'Marketplace plugins normally run sandboxed in the cross-origin PluginFrame. Listings a staff member has reviewed and signed (trust: \'realm\' + an Ed25519 signature over the bundle\'s sha256 on the version doc) instead load INTO the app realm and use every registry above — first-party-grade extensions installed per workspace, no repo change.\n- Build with tools/plugin-loader/realm/rollup.config.mjs: your react, react/jsx-runtime, and @aglyn/aglyn imports compile to lookups on globalThis.AGLYNPLUGINHOST (the app\'s own singletons), so the emitted bundle imports nothing. Export register(host) for client surfaces; registerApi() for server handlers.\n- Publish through the marketplace pipeline, install (pins {version, sha256}), then staff grant trust via POST /api/marketplace/admin/trust.\n- The console loads an org\'s realm installs before the shell renders; published sites load them post-hydration (additive runtimes — first paint never waits on a marketplace CDN). Every load verifies the sha256 pin and the platform signature and fails closed; revocations is the hard kill switch.\n- Server handler bundles are additionally gated by PLUGINREMOTESERVER=enabled + a per-deploy PLUGINREMOTESERVERBUNDLES allowlist, default off everywhere.\nFull trust chain, env matrix, and walkthrough: docs/PLUGINLOADING.md in the repo; a runnable demo lives at tools/plugin-loader/realm/demo.'
     },
     {
         path: '/developers/plugins/building-feature-plugins',
@@ -5105,7 +5105,7 @@ export const ASSIST_DOCS_INDEX = [
         title: 'Guide: trusted realm bundles',
         heading: 'Granting trust (staff)',
         anchor: '#granting-trust-staff',
-        text: 'Admin → Plugin reviews has a Listed plugins — realm trust section: every listed and verified plugin with its recent versions, each showing a Realm-trusted or Sandboxed chip and a Latest marker, with per-version Grant realm trust and Revoke realm trust buttons. Trust is granted to a specific reviewed version, not to the listing — a newer version stays sandboxed until it is reviewed and granted in turn.\nBoth actions are super-staff only and adminAudit\'d. The equivalent API is POST /api/admin/sign-plugin { listingId, version }, with { action: \'revoke\' } to revoke; a hard-kill still needs a revocation doc. Signing requires PLUGINTRUSTPRIVATEKEY on the console deployment — generate the pair with tools/scripts/generate-plugin-trust-key.mjs.'
+        text: 'Admin → Plugin reviews has a Listed plugins — realm trust section: every listed and verified plugin with its recent versions, each showing a Realm-trusted or Sandboxed chip and a Latest marker, with per-version Grant realm trust and Revoke realm trust buttons. Trust is granted to a specific reviewed version, not to the listing — a newer version stays sandboxed until it is reviewed and granted in turn.\nBoth actions are super-staff only and adminAudit\'d. The equivalent API is POST /api/marketplace/admin/trust { listingId, version }, with { action: \'revoke\' } to revoke; a hard-kill still needs a revocation doc. Signing requires PLUGINTRUSTPRIVATEKEY on the console deployment — generate the pair with tools/scripts/generate-plugin-trust-key.mjs.'
     },
     {
         path: '/developers/plugins/guides/realm-bundles',
@@ -5455,7 +5455,7 @@ export const ASSIST_DOCS_INDEX = [
         title: 'Manifests, trust lifecycle & environment',
         heading: 'Review & trust lifecycle',
         anchor: '#review--trust-lifecycle',
-        text: '- listed/verified (or legacy/absent) plugin listings appear in browse; everything else is owner-and-staff-only. Verified adds the ✅ badge.\n- Realm trust is separate and orthogonal: a super-staff signature over a version\'s sha256 (POST /api/admin/sign-plugin) sets trust: \'realm\', letting that version load into the app realm. The revocations/{listingId} kill switch beats everything.'
+        text: '- listed/verified (or legacy/absent) plugin listings appear in browse; everything else is owner-and-staff-only. Verified adds the ✅ badge.\n- Realm trust is separate and orthogonal: a super-staff signature over a version\'s sha256 (POST /api/marketplace/admin/trust) sets trust: \'realm\', letting that version load into the app realm. The revocations/{listingId} kill switch beats everything.'
     },
     {
         path: '/developers/plugins/reference/manifest-and-envs',
@@ -6344,7 +6344,7 @@ export const ASSIST_DOCS_INDEX = [
         title: 'The console tour',
         heading: 'Workspace settings & notifications',
         anchor: '#workspace-settings--notifications',
-        text: 'Organization-wide settings (name, workspace URL) live under Organization → Settings, which also holds Profile, API keys, Branding, Single sign-on, Privacy, Ownership and Delete. Turning plugins on and off for the workspace is its own section, Organization → Plugins — Marketplace is for finding and installing new ones, not for administering what you already run:\nThe notifications feed\nYour in-app notification feed — billing, publishing, workflow failures — lives under Notifications. The page shows what arrived, newest first, with Mark all read and a Notification settings button beside it:\nNotification settings\nEverything about what reaches you lives on its own page, Notification settings, reachable from that button or from the Manage tab strip.\nWhat you are told about is a table: one row per category, one column for In console and one for Email.\n- In console is on for every category. Switching it off stops that category appearing in the feed and in the bell.\n- Email is off for every category. Switch one on and you also get a message in your inbox when one of those notifications arrives. This does not touch the mail Aglyn already sends you — invites, verification, receipts, password resets and dunning are separate, and are not affected by anything on this page.\nWorkspace and site overrides\nOne workspace or one site sets the same answers for a single workspace or a single site, rather than for your whole account. Each cell starts at Inherit, which means it follows the level above it: a site follows its workspace, a workspace follows your account. Set one to On or Off and only that scope changes. This is how you take form submissions by email from one busy site without taking them from the other five.\nDaily digests\nDaily CRM digest is on by default. Each morning it sends yo'
+        text: 'Organization-wide settings (name, workspace URL) live under Organization → Settings, which also holds Profile, API keys, Branding, Single sign-on, Privacy, Ownership and Delete. Turning plugins on and off for the workspace is its own section, Organization → Plugins — Marketplace is for finding and installing new ones, not for administering what you already run:\nThe notifications feed\nYour in-app notification feed — billing, publishing, workflow failures — lives under Notifications, which has two sections in the rail on the left: All notifications and Settings. The first shows what arrived, newest first, with Mark all read above it:\nNotification settings\nEverything about what reaches you lives on the second section, Settings.\nWhat you are told about is a table: one row per category, one column for In console and one for Email.\n- In console is on for every category. Switching it off stops that category appearing in the feed and in the bell.\n- Email is off for every category. Switch one on and you also get a message in your inbox when one of those notifications arrives. This does not touch the mail Aglyn already sends you — invites, verification, receipts, password resets and dunning are separate, and are not affected by anything on this page.\nWorkspace and site overrides\nOne workspace or one site sets the same answers for a single workspace or a single site, rather than for your whole account. Each cell starts at Inherit, which means it follows the level above it: a site follows its workspace, a workspace follows your account. Set one to On or Off and only that scope changes. This is how you take form submissions by email from one busy site without taking them from the other five.\nDaily digests\nDaily CRM digest is on by default. Each morning it sends you one notification '
     },
     {
         path: '/getting-started/create-a-site',