smbls 3.14.838 → 3.14.840

package/CHANGELOG.md

@@ -1,5 +1,21 @@
 # smbls
 
+## 3.14.840
+
+### Patch Changes
+
+- XMA round 3 (performance): a pre-rendered page is adopted in short tasks; the first render puts rows on screen whole; the design system is prepared at build time and adopted by the page; `smbls build` adds V8 compile hints and (opt-in, `build.modulePreload`) lazy-module preloads; brender's preload goes after the import map; pre-built pages can be flagged stale (`fetch.seed.isStale` / `maxAge` / `onRefresh`, `<html data-smbls-stale>`); routes without their own page answer with 200.html on every deploy target; the app starts in the address's language (`addressLang`) and adopts the seeded answers; `DropdownDisclosure` and Dialog `locked`; frank-audit accepts DOM work on a bridged library's and a parsed document's own nodes; a server render waits for its own labels (label loads in flight are per app); mermaid renderProjectHtml takes a caller-resolved head (`options.metadata`) and `metadata.source` is never a tag.
+
+## 3.14.839
+
+### Patch Changes
+
+- Cross-tenant isolation for server renders, and the wider CLI production gate.
+
+  - fetch: a server render context (`isolateFetchCache`, set by brender) has its own query store — cache, requests in flight, invalidations and mounted queries — so two renders of different projects in one process never share rows, in sequence or at the same time; a server render binds no browser-only refetch (no focus / online listeners, no `refetchInterval` timer), so no request of one page lands in another page's seed and the process exits when the work is done.
+  - brender: renders that start together share one framework bundle; every render owns its `location`, Web Storage and `history`.
+  - cli: destructive platform writes (project delete, transfer, members, invites, library changes, version writes) print the target and need a typed "production" or `--yes` for production; `project create` is not gated.
+
 ## 3.14.838
 
 ### Patch Changes

package/README.md

@@ -98,7 +98,11 @@ page are built in chunks of 10 ms (`@symbo.ls/element` yielding mounts).
 The first view is painted once. The root is built outside the document and
 goes in with one insertion when the shell and the first page are complete, so
 the first paint shows the whole first view, as when the boot was one task, and
-nothing on screen moves.
+nothing on screen moves. What reaches the document while the first render
+still yields — rows a state update (a fetched list) builds as the root goes
+in — goes in whole too: an element whose children are still being built
+waits outside its parent until its last chunk is in (`@symbo.ls/element`
+`mountWhole`), so a row never shows with only its first children.
 
 ```js
 create(App, { firstRender: 8 })                                // chunks of 8 ms
@@ -131,9 +135,29 @@ When things happen:
 - A project's own `domqlOptions.mountYield` wins over the 10 ms budget. After
   the first render, reconciles, `if:` and navigations build in one go again
   unless the project set `domqlOptions.mountYield`.
-- A boot over a pre-rendered (brender) page builds its shell and page in one
-  task over the server markup (only the entry script's task ends first); a
-  server render keeps the whole boot in one task.
+- A boot over a pre-rendered (brender) page adopts the server markup in the
+  same short tasks: the shell, then the first page in a task of its own, in
+  chunks of the budget. The server's nodes stay on screen while each element
+  takes its own, so nothing visible changes. `create()` resolves once the
+  adoption is done; no `onMounted` runs before it; the hydration window (and
+  `window.__BRENDER_HYDRATION__`) is counted from its end. A click on a server
+  node whose element is not built yet is held and dispatched again, once, on
+  the same node when the adoption is done (an element already adopted handles
+  its own events at once); input during the adoption does not close the
+  window. `firstRender: false` adopts in one task, as before; a page that
+  replaces the server markup (no registry, `hydrate: false`) renders in one
+  task; a server render keeps the whole boot in one task.
+- A pre-rendered page shows the data of its build (`smbls build` pages: until
+  the next build). `el.context.prerender` is the build it comes from,
+  `{ stamp, time }` (`<meta name="brender-stamp">`). When the page is flagged
+  stale (`<html data-smbls-stale>`, or the project's `fetch.seed.isStale` /
+  `fetch.seed.maxAge`), it is adopted from the build's data as any page is,
+  and when the hydration window closes (on a replaced page: when its first
+  view has settled) the fetch plugin asks again, at idle, for exactly what
+  took a recorded answer and swaps in what changed;
+  `window.__BRENDER_HYDRATION__.refreshed` counts it. A page that is not
+  stale sends nothing extra. See `@symbo.ls/fetch`, "A pre-built page shows
+  the data of its build".
 
 ## Plugins