@aglyn/aglyn 1.0.0-beta.211 → 1.0.0-beta.213

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@aglyn/aglyn",
-  "version": "1.0.0-beta.211",
+  "version": "1.0.0-beta.213",
   "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.211",
-    "@aglyn/shared-data-mdi": "1.0.0-beta.211",
-    "@aglyn/shared-data-types": "1.0.0-beta.211",
-    "@aglyn/shared-util-email": "1.0.0-beta.211",
-    "@aglyn/shared-util-first-touch": "1.0.0-beta.211",
-    "@aglyn/shared-util-http": "1.0.0-beta.211",
-    "@aglyn/shared-util-logger": "1.0.0-beta.211",
-    "@aglyn/shared-util-timestamp": "1.0.0-beta.211",
-    "@aglyn/shared-util-tools": "1.0.0-beta.211",
-    "@aglyn/shared-util-vendor": "1.0.0-beta.211",
+    "@aglyn/shared-data-enums": "1.0.0-beta.213",
+    "@aglyn/shared-data-mdi": "1.0.0-beta.213",
+    "@aglyn/shared-data-types": "1.0.0-beta.213",
+    "@aglyn/shared-util-email": "1.0.0-beta.213",
+    "@aglyn/shared-util-first-touch": "1.0.0-beta.213",
+    "@aglyn/shared-util-http": "1.0.0-beta.213",
+    "@aglyn/shared-util-logger": "1.0.0-beta.213",
+    "@aglyn/shared-util-timestamp": "1.0.0-beta.213",
+    "@aglyn/shared-util-tools": "1.0.0-beta.213",
+    "@aglyn/shared-util-vendor": "1.0.0-beta.213",
     "@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

@@ -2447,6 +2447,13 @@ export const ASSIST_DOCS_INDEX = [
         anchor: '#search-engine-visibility',
         text: 'You decide what search engines are allowed to index, at two levels.\nThe whole site\nSetup → SEO → Search engines has a Discourage search engines from indexing this site switch. Turn it on while you stage a launch — the site stays live and anyone with a link can still reach it, but:\n- robots.txt refuses every crawler (Disallow: /) and names no sitemap\n- sitemap.xml is served empty (valid but with no URLs, so search consoles read "nothing here" rather than an error they retry)\n- every page carries a noindex robots meta tag — links are still followed, but the page is not listed\nWhile it is on, a warning banner follows you through the console on every page of that site. That is deliberate — a site missing from Google weeks after launch is almost always this switch, left on and forgotten.\nTurning it off restores everything within about a minute. Search engines take longer: re-indexing a site is their schedule, not yours, so allow days.\nrobots.txt and noindex answer different questions. Disallow asks a crawler not to fetch a page; noindex asks it not to list one. Aglyn sends both, because a page linked from somewhere else can be listed without ever being fetched — and a crawler that obeys the disallow never sees the noindex that would have stopped it.\nA single page\nUse the page\'s own Visibility, in Page Access on the screen\'s detail page. Only Public pages are offered to search engines. Unlisted, Password protected and Members only pages are all kept out of search results and out of the sitemap, while staying reachable to whoever has the link or the credentials.\nUse the site-wide switch while nothing is ready, and per-screen Unlisted once you\'re launching page by page — the switch also covers pages you haven\'t created yet, which per-screen visibility cannot.\nnoindex is a reque'
     },
+    {
+        path: '/building-sites/seo/overview',
+        title: 'SEO Toolkit',
+        heading: 'Verify your site with Google Search Console',
+        anchor: '#verify-your-site-with-google-search-console',
+        text: 'Search Console and Bing Webmaster Tools want proof the site is yours before they show you its search data. A site on an aglyn.app address has no DNS of its own to add a record to, so use the HTML tag method — it works on every site, custom domain or not.\n1. In Google Search Console, choose Add property → URL prefix, enter your site\'s full address, and pick HTML tag under Other verification methods.\n2. Copy the tag it shows you. You can paste the whole tag or just the code inside content — Aglyn keeps only the code.\n3. In Setup → SEO → Search engine verification, paste it into Google Search Console and press Update.\n4. Back in Search Console, press Verify. Allow a minute for the published site to pick up the change if the first attempt fails.\nBing works the same way: in Bing Webmaster Tools, choose Add site, pick HTML Meta Tag, and paste the msvalidate.01 tag into Bing Webmaster Tools.\nKeep the code in place after verifying — both tools re-check it from time to time, and removing it un-verifies the site. Clearing a field and pressing Update removes that tag from every page.'
+    },
     {
         path: '/building-sites/seo/overview',
         title: 'SEO Toolkit',
@@ -5175,7 +5182,7 @@ export const ASSIST_DOCS_INDEX = [
         title: 'Guide: trusted realm bundles',
         heading: 'Build against the host ABI',
         anchor: '#build-against-the-host-abi',
-        text: 'Use the template\'s build config: your react, react/jsx-runtime, and @aglyn/aglyn imports compile to lookups on globalThis.AGLYNPLUGINHOST — the app injects its own singletons there, which is what keeps your components on the app\'s React and your registrations in the app\'s registries. Export register(host) (client surfaces) and, only if you truly need server handlers, registerApi(). Declare hostAbi in your manifest; a bundle built for another generation never loads.'
+        text: 'Use the template\'s build config. Two kinds of import never end up in your bundle: what must be the same instance as the app\'s, and libraries the site already runs. Those compile to lookups on globalThis.AGLYNPLUGINHOST, where the app puts its own modules. Everything else you import is compiled in and tree-shaken.\n| Import | Host key | What the host holds |\n| react, react/jsx-runtime | React, jsxRuntime | The app\'s React. Two copies can\'t render one tree |\n| @aglyn/aglyn | aglyn | The realm plugin surface: the registries, the schema and field constants, defineUiFeatureBundle, console slots, the element contexts, and the site-function and variable runtime |\n| @mui/material, @mui/material/ | mui | The components listed below, plus useMediaQuery and createSvgIcon |\n| @mui/material/styles | muiStyles | alpha, css, darken, emphasize, getContrastRatio, keyframes, lighten, styled, useColorScheme, useTheme |\nThe MUI components on the host are Alert, Box, Button, Card, CardContent, Checkbox, Chip, CircularProgress, Collapse, Divider, FormControl, FormControlLabel, FormHelperText, IconButton, InputAdornment, InputLabel, Link, List, ListItem, ListItemText, MenuItem, Paper, Radio, RadioGroup, Select, Stack, SvgIcon, Switch, Table, TableBody, TableCell, TableHead, TableRow, TextField, Tooltip, Typography.\nTaking MUI from the host is what makes a plugin element look like the rest of the page. It takes the site\'s palette, type, component defaults and dark mode, and its styles are written into the page\'s style cache during the server render, not after it. It also costs nothing twice: the page already downloads that MUI.\nThe rest of the rules:\n- The build refuses to compile in anything from @mui/, @emotion/ or react-dom. A copy would download twice and miss the site\'s theme. Style with s'
     },
     {
         path: '/developers/plugins/guides/realm-bundles',
@@ -5196,7 +5203,7 @@ export const ASSIST_DOCS_INDEX = [
         title: 'Guide: trusted realm bundles',
         heading: 'Where realm bundles load',
         anchor: '#where-realm-bundles-load',
-        text: '- Console: before the shell renders, from the org\'s trusted installs.\n- Published sites: post-hydration (additive — first paint never waits on a marketplace CDN), and only on a page that uses the plugin: one that places a component its manifest declares under contributes.site, or on every page when it declares a site feature. A plugin that only adds console widgets never loads on a published page, and neither does the host that runs it. See contributes.\n- Server (rare): only on deployments with PLUGINREMOTESERVER=enabled plus a per-deploy listingId@version allowlist; every load is audited.'
+        text: '- Console: from the org\'s trusted installs, on the screens that draw what the manifest declares under contributes.console.\n- Besigner: for a site that runs the plugin, when it declares site components or site features, so its elements are in the Elements panel and draw on the canvas. The canvas waits for the bundle.\n- Published sites: post-hydration (additive — first paint never waits on a marketplace CDN), and only on a page that uses the plugin: one that places a component its manifest declares under contributes.site, or on every page when it declares a site feature. A plugin that only adds console widgets never loads on a published page, and neither does the host that runs it. See contributes.\n- Server (rare): only on deployments with PLUGINREMOTESERVER=enabled plus a per-deploy listingId@version allowlist; every load is audited.'
     },
     {
         path: '/developers/plugins/guides/realm-bundles',
@@ -5210,7 +5217,7 @@ export const ASSIST_DOCS_INDEX = [
         title: 'Guide: trusted realm bundles',
         heading: 'Troubleshooting',
         anchor: '#troubleshooting',
-        text: '- Loads in dev loop, not from the marketplace: dev loop skips verification. Check the browser console for the loader\'s reason — usually "missing signature" (not signed yet) or "sha256 mismatch".\n- AGLYNPLUGINHOST is not set: your bundle executed outside a host surface — the console gate and site effect set the ABI before loading; don\'t import the bundle yourself.\n- Server bundle didn\'t register: the dispatcher logs which chain link failed (not realm-trusted, built for host ABI N, fetch, signature) and skips — check the deployment logs and the allowlist entry.'
+        text: '- Loads in dev loop, not from the marketplace: dev loop skips verification. Check the browser console for the loader\'s reason — usually "missing signature" (not signed yet) or "sha256 mismatch".\n- this Aglyn host does not provide mui: the bundle ran on a host older than the MUI keys. Every current console and site provides them.\n- … never compiles it in (build): an import of MUI, emotion or react-dom outside what the host holds. Use the host\'s components and @mui/material/styles.\n- AGLYNPLUGINHOST is not set: your bundle executed outside a host surface — the console gate and site effect set the ABI before loading; don\'t import the bundle yourself.\n- Server bundle didn\'t register: the dispatcher logs which chain link failed (not realm-trusted, built for host ABI N, fetch, signature) and skips — check the deployment logs and the allowlist entry.'
     },
     {
         path: '/developers/plugins/guides/server-apis',
@@ -5301,7 +5308,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 +5532,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, and the Besigner for every site that runs the plugin |\n| site.features | The runtimeId of each site runtime it mounts | Every page of a site that has the plugin switched on, and the Besigner for that site |\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 Besigner loads a plugin that declares either site key for every site that runs it, whether or not the page open places one of its elements. That way its elements appear in the Elements panel and draw on the canvas. The site\'s list is the workspace\'s installs plus the site\'s own, the same list its published pages load from.\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 '
     },
     {
         path: '/developers/plugins/reference/manifest-and-envs',
@@ -6491,7 +6498,7 @@ export const ASSIST_DOCS_INDEX = [
         title: 'Create a site',
         heading: 'What a site contains',
         anchor: '#what-a-site-contains',
-        text: '- Screens & layouts — the pages and the shared frames they render in.\n- Data — the datasets this site can see. Variables and functions are under Logic, and workflows and actions under Automation.\n- Media — images, video, and files, organized in folders.\n- Setup — theme, SEO, tracking, and emails under tabbed settings. The Site logo card (Details tab) sets your brand mark: it\'s shown on the live site\'s page-navigation loading overlay — a themed, blurred scrim with a progress bar. Without a logo, the loader shows your site name instead.\n- Billing — the plan and usage meters that gate features and quotas.'
+        text: '- Screens & layouts — the pages and the shared frames they render in.\n- Data — the datasets this site can see. Variables and functions are under Logic, and workflows and actions under Automation.\n- Media — images, video, and files, organized in folders.\n- Setup — theme, SEO, tracking, and emails under tabbed settings. The Site logo card (Details tab) sets your brand mark: it\'s shown on the live site\'s page-navigation loading overlay — a themed, blurred scrim with a progress bar. Without a logo, the loader shows your site name instead. Add a Dark mode logo too if yours is hard to see on a dark background: visitors browsing in dark mode see it on the loader and error pages, and without one they see the light mode logo.\n- Billing — the plan and usage meters that gate features and quotas.'
     },
     {
         path: '/getting-started/create-a-site',
@@ -6953,7 +6960,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',