@aglyn/aglyn 1.0.0-beta.209 → 1.0.0-beta.212

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@aglyn/aglyn",
-  "version": "1.0.0-beta.209",
+  "version": "1.0.0-beta.212",
   "license": "Apache-2.0",
   "homepage": "https://aglyn.com",
   "repository": {
@@ -33,16 +33,16 @@
     "./package.json": "./package.json"
   },
   "dependencies": {
-    "@aglyn/shared-data-enums": "1.0.0-beta.209",
-    "@aglyn/shared-data-mdi": "1.0.0-beta.209",
-    "@aglyn/shared-data-types": "1.0.0-beta.209",
-    "@aglyn/shared-util-email": "1.0.0-beta.209",
-    "@aglyn/shared-util-first-touch": "1.0.0-beta.209",
-    "@aglyn/shared-util-http": "1.0.0-beta.209",
-    "@aglyn/shared-util-logger": "1.0.0-beta.209",
-    "@aglyn/shared-util-timestamp": "1.0.0-beta.209",
-    "@aglyn/shared-util-tools": "1.0.0-beta.209",
-    "@aglyn/shared-util-vendor": "1.0.0-beta.209",
+    "@aglyn/shared-data-enums": "1.0.0-beta.212",
+    "@aglyn/shared-data-mdi": "1.0.0-beta.212",
+    "@aglyn/shared-data-types": "1.0.0-beta.212",
+    "@aglyn/shared-util-email": "1.0.0-beta.212",
+    "@aglyn/shared-util-first-touch": "1.0.0-beta.212",
+    "@aglyn/shared-util-http": "1.0.0-beta.212",
+    "@aglyn/shared-util-logger": "1.0.0-beta.212",
+    "@aglyn/shared-util-timestamp": "1.0.0-beta.212",
+    "@aglyn/shared-util-tools": "1.0.0-beta.212",
+    "@aglyn/shared-util-vendor": "1.0.0-beta.212",
     "@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

@@ -5301,7 +5301,7 @@ export const ASSIST_DOCS_INDEX = [
         title: 'Plugins & Marketplace',
         heading: 'How plugins run',
         anchor: '#how-plugins-run',
-        text: '- Each plugin loads into a sandboxed PluginFrame host runtime, isolated by origin.\n- A manifest + sandbox bridge protocol defines what a plugin can do.\n- A host-mediated network bridge lets plugins make network calls without direct access to your environment.\n- See Sandbox security model for what that isolation actually enforces — including the per-plugin network policy — if you\'re writing one.\n- Your workspace decides which plugins are enabled at all, and a site admin can narrow that further per site from the site\'s Admin → Plugins page. A plugin disabled for a site disappears from that site\'s navigation, editor, published pages, and API — other sites in the workspace are unaffected, and a site can never enable a plugin the workspace has switched off.\n- The site\'s Admin → Plugins page lists both kinds in two groups — what ships with the platform, and what the workspace installed from the marketplace — because which one a row is is the first thing you need to know before switching it. A marketplace plugin gets the same per-site switch as a built-in one.\n- Most plugins are on for a site unless it turns them off. User Accounts is the exception: it is off until a site turns it on, because it is the one that decides whether the site serves /signin, /signup and /recover — and a sign-in page on a marketing site is worse than a missing one. See Member accounts for what the switch does.\n- AI has a site switch and no workspace switch. It is on for every workspace, because the AI add-on, credits, allotments and overage billing belong to the workspace rather than to any site. A site can switch AI off for itself on its Admin → Plugins page: that hides AI on the site, refuses every AI request made for it and stops its queued jobs without spending credits, while the workspace\'s AI ke'
+        text: '- Each plugin loads into a sandboxed PluginFrame host runtime, isolated by origin.\n- A manifest + sandbox bridge protocol defines what a plugin can do.\n- A host-mediated network bridge lets plugins make network calls without direct access to your environment.\n- See Sandbox security model for what that isolation actually enforces — including the per-plugin network policy — if you\'re writing one.\n- Your workspace decides which plugins are enabled at all, and a site admin can narrow that further per site from the site\'s Admin → Plugins page. A plugin disabled for a site disappears from that site\'s navigation, editor, published pages, and API — other sites in the workspace are unaffected, and a site can never enable a plugin the workspace has switched off.\n- The site\'s Admin → Plugins page lists both kinds in two groups — what ships with the platform, and what the workspace installed from the marketplace — because which one a row is is the first thing you need to know before switching it. A marketplace plugin gets the same per-site switch as a built-in one.\n- Most plugins are on for a site unless it turns them off. User Accounts reads the other way: a site has it only once the site turns it on, because it is the one that decides whether the site serves /signin, /signup and /recover — and a sign-in page on a marketing site is worse than a missing one. A new site is created with it turned on; a site created before that has it off until it asks. See Member accounts for what the switch does.\n- AI has a site switch and no workspace switch. It is on for every workspace, because the AI add-on, credits, allotments and overage billing belong to the workspace rather than to any site. A site can switch AI off for itself on its Admin → Plugins page: that hides AI on the site, refuses e'
     },
     {
         path: '/developers/plugins/overview',
@@ -5525,7 +5525,7 @@ export const ASSIST_DOCS_INDEX = [
         title: 'Manifests, trust lifecycle & environment',
         heading: 'Plugin manifest (published with every version)',
         anchor: '#plugin-manifest-published-with-every-version',
-        text: 'Validation is server-side (validatePluginManifest) — invalid manifests never publish. capabilities are enforced by the sandbox tier: the plugin origin stamps a CSP from network, the bridge drops undeclared props and events.\ncontributes — where the plugin loads\nA plugin loads only where something uses it. Installing one loads nothing: the platform reads contributes to decide which published pages and which console screens fetch your bundle, and it never runs your code to find out.\n| Key | What it declares | Where the plugin then loads |\n| site.components | The canvas component ids register() registers | A published page whose node tree places one of them |\n| site.features | The runtimeId of each site runtime it mounts | Every page of a site that has the plugin switched on |\n| console.slots | The widget slots it fills, including the panels the shell draws as slots (assistPanel, besignerInspector) | A console screen that renders one of those slots |\n| console.routes / console.orgRoutes | The console routes its pages serve (/my-plugin) | The screens under those routes |\n| console.shell | It adds a nav tab, a provider or a staff page, which the shell draws on every screen | Every screen of the workspace |\nThe declaration is the whole contract, so it has to be complete:\n- The verifier compares it with your bundle. verify-plugin-bundle.mjs and the publish API read what register() registers (a widget\'s slot, a nav item\'s href, a runtime\'s runtimeId, a component\'s $id) and refuse a registration the declaration omits: a slot you forget to declare is a slot whose screens never load your plugin.\n- A new version must declare. A bundle whose register() registers anything and whose manifest has no contributes fails publishing, with the declaration the verifier read printed for you to '
+        text: 'Validation is server-side (validatePluginManifest) — invalid manifests never publish. capabilities are enforced by the sandbox tier: the plugin origin stamps a CSP from network, the bridge drops undeclared props and events.\ncontributes — where the plugin loads\nA plugin loads only where something uses it. Installing one loads nothing: the platform reads contributes to decide which published pages and which console screens fetch your bundle, and it never runs your code to find out.\n| Key | What it declares | Where the plugin then loads |\n| site.components | The canvas component ids register() registers | A published page whose node tree places one of them |\n| site.features | The runtimeId of each site runtime it mounts | Every page of a site that has the plugin switched on |\n| console.slots | The widget slots it fills, including the panels the shell draws as slots (assistPanel, besignerInspector) | A console screen that renders one of those slots |\n| console.routes / console.orgRoutes | The console routes its pages serve (/my-plugin) | The screens under those routes |\n| console.shell | It adds a nav tab, a provider or a staff page, which the shell draws on every screen | Every screen of the workspace |\nOne more site key declares no load point. site.functionBindings names the elements that run one of the site\'s functions in the visitor\'s browser, each mapped to the prop that holds the function\'s name:\nWhen a page is composed, an element listed there gets the named function\'s definition and the site variables that function reads. Every other element gets neither, so a function\'s rules and prices never reach an element that did not ask for them. Each key must also appear in site.components, and the value must be a plain prop name. A marketplace declaration cannot rebind a pl'
     },
     {
         path: '/developers/plugins/reference/manifest-and-envs',
@@ -6540,7 +6540,7 @@ export const ASSIST_DOCS_INDEX = [
         title: 'Publish your first screen',
         heading: 'How fast changes go live',
         anchor: '#how-fast-changes-go-live',
-        text: '- Publishing a screen refreshes its live page immediately — the very next visitor gets the new version, usually within seconds.\n- Publishing a layout or a reusable component refreshes every page that uses it the same way. When that fan-out is very large, the publish confirms that the remaining pages "update on their own within an hour" — and they do.\n- Site settings go live when you save them. Your theme, logo, favicon, app icon, social image, SEO and structured data, business details, languages, consent banner, announcement bar, popup and store settings have no publish step — saving one refreshes every page of the live site immediately, the same way a publish does. Installing, updating or resetting a marketplace theme does too.\n- Saving is not publishing. A save writes your working version; the live site serves the published one. The one subtle case: if you edit the version that is currently live and press Save, the live site catches up on its own within about a minute — and because pages regenerate behind the scenes, you may need to refresh twice to see it.\n- Your site\'s sitemap.xml, robots.txt, and RSS feeds refresh within about five minutes (a publish refreshes the sitemap immediately).'
+        text: '- Publishing a screen refreshes its live page immediately — the very next visitor gets the new version, usually within seconds.\n- Publishing a layout or a reusable component refreshes every page that uses it the same way. When that fan-out is very large, the publish confirms that the remaining pages "update on their own within an hour" — and they do.\n- Site settings go live when you save them. Your theme, logo, favicon, app icon, social image, SEO and structured data, business details, languages, consent banner, announcement bar, popup and store settings have no publish step — saving one refreshes every page of the live site immediately, the same way a publish does. Installing, updating or resetting a marketplace theme does too, and so does saving a product, a review\'s moderation, a site variable or function, an overlay or an A/B test. If you close the tab straight after saving, the refresh still happens within a few minutes.\n- Collections refresh their own pages. Changing a collection\'s template screens, its address or its categories refreshes its listing and every published entry page — including the old addresses after a rename.\n- A deleted site stops serving at once. Its cached pages are dropped when you delete it, rather than lingering for up to an hour.\n- Saving is not publishing. A save writes your working version; the live site serves the published one. The one subtle case: if you edit the version that is currently live and press Save, the live site catches up on its own within about a minute — and because pages regenerate behind the scenes, you may need to refresh twice to see it.\n- Your site\'s sitemap.xml, robots.txt, and RSS feeds refresh within about five minutes (a publish refreshes the sitemap immediately).'
     },
     {
         path: '/getting-started/publish-your-first-screen',
@@ -6953,7 +6953,7 @@ export const ASSIST_DOCS_INDEX = [
         title: 'Member accounts',
         heading: '1. Turn User Accounts on for the site',
         anchor: '#1-turn-user-accounts-on-for-the-site',
-        text: 'Member accounts are off by default, on every site. Until you switch them on, /signin, /signup and /recover do not exist on that site — they return a genuine 404, the same as any address you have not published.\nTurn them on at Sites → your site → Admin → Plugins, on the Site plugins card: flip User Accounts and press Save site plugins. It is a per-site switch, exactly like the other plugin toggles there, so one site in a workspace can have member accounts while another does not.\nWhy it defaults to off Most sites are marketing sites, and a sign-in page on a marketing domain is worse than a missing one: it looks like the place to type a password, while the real sign-in usually lives somewhere else entirely — a separate app domain, or your identity provider. Aglyn\'s own site is the example. Serving /signin there would invite people to enter console credentials on a page that is not the console. So the pages appear only when you say the site has members.\nSwitching User Accounts off again does not delete anything. Existing members, their profiles and their order history stay exactly where they are in Users; only the public pages stop being served. Switch it back on and everything is reachable again.\nSites that were already using member accounts when this switch arrived keep them — the switch was turned on for any site with members, a designated auth screen, or a members-only page.'
+        text: 'A new site starts with member accounts on. A site created before that change starts with them off, and while they are off, /signin, /signup and /recover do not exist on that site — they return a genuine 404, the same as any address you have not published.\nThe switch is at Sites → your site → Admin → Plugins, on the Site plugins card: flip User Accounts and press Save site plugins. It is a per-site switch, exactly like the other plugin toggles there, so one site in a workspace can have member accounts while another does not.\nSwitch it off on a site with no members A sign-in page on a marketing domain is worse than a missing one: it looks like the place to type a password, while the real sign-in usually lives somewhere else entirely — a separate app domain, or your identity provider. Aglyn\'s own site is the example. Serving /signin there would invite people to enter console credentials on a page that is not the console. If a site has no members, switch User Accounts off for it.\nSwitching User Accounts off again does not delete anything. Existing members, their profiles and their order history stay exactly where they are in Users; only the public pages stop being served. Switch it back on and everything is reachable again.\nSites that were already using member accounts when this switch arrived keep them — the switch was turned on for any site with members, a designated auth screen, or a members-only page.'
     },
     {
         path: '/guides/member-accounts',