@ai-ecoverse/slicc-bios 1.44.11 → 1.44.12

package/README.md

@@ -42,9 +42,9 @@ On a shared origin, the BIOS moves SLICC 6 into seven in this browser once, afte
 - **When it asks:** `/slicc-fs` in OPFS has an entry, `localStorage['slicc-os.six']` isn't `upgraded`, and `/upgrade-to-seven.html` answers within 10 s, without a redirect, and carries `<meta name="slicc-six-upgrade">`. Without the meta (www's fallback answers unknown paths with six's own page) nothing is framed and nobody is asked. One tab asks at a time (Web Lock `slicc-six-upgrade`).
 - **The question:** *Move SLICC 6 into seven in this browser?*, saying that files move as they are, including any keys or passwords written inside them, and that SLICC 6 and its Chrome extension then stop working in this browser. It's a modal dialog with focus on **Not now**, so Enter and Escape decline; **Not now** leaves both alone and boots seven, and the next boot asks again. There's no setting.
 - **Moving:** the BIOS frames `/upgrade-to-seven.html` hidden, on the same origin. The page starts on load, stops six's tabs and posts `{ type: 'slicc-six-upgrade', … }` to its parent. The BIOS listens only to messages whose `origin` is its own and whose `source` is that frame. Progress shows under the question: *Stopping SLICC 6 tabs…*, then *Reading files: 120 of 1,240* (`reading` counts the files under `/slicc-fs` it reads) and *Writing the export: 3 of 9* (`writing` counts the entries it writes, `manifest.json` last); two minutes without a message fail the move.
-- **Success** (`done: true`, `exportId`, `dir = /slicc-v6-upgrade/<exportId>/`): while the frame still holds six's `slicc-six-kernel` lock, the BIOS sets `slicc-os.six = upgraded` and `slicc-os.six-import = <dir>`, creates the cache `slicc-bios.six-retired`, unregisters every service worker under `/preview/`, and removes every other directory under `/slicc-v6-upgrade/` (interrupted runs). Only then does the frame go, so a six tab opened in between sees the marker and stays down.
+- **Success** (`done: true`, `exportId`, `dir = /slicc-v6-upgrade/<exportId>/`): while the frame still holds six's `slicc-six-kernel` lock, the BIOS sets `slicc-os.six = upgraded` and `slicc-os.six-import = <dir>`, sets the cookie `__Host-slicc-six-retired` (`Path=/`, `Secure`, `SameSite=Strict`), unregisters every service worker under `/preview/`, and removes every other directory under `/slicc-v6-upgrade/` (interrupted runs). Only then does the frame go, so a six tab opened in between sees the marker and stays down.
 - **Failure** (`error`) removes the frame and sets nothing, so six keeps working. The BIOS shows the error with **Try again** and **Not now**.
-- **Retired:** every later BIOS boot opens the cache and unregisters `/preview/` again, and so does every start of `/os/` while the marker is set (`/` no longer reaches the BIOS). The service worker answers a navigation to `/` (whatever its query, so six's extension's `?slicc=leader&ext=…` and `?cherry=1&ui-only=1` too) with a redirect to `/os/` once the cache exists. The extension's leader tab then shows seven; its side panel can't show `/os/` in its frame, so it just stops working. It always passes `/upgrade-to-seven.html` and `/assets/*` to the network on a shared origin, even when OPFS has files there: on www, `/assets/` belongs to SLICC 6 (its exporter's hashed chunks), so seven keeps nothing of its own there, and a kernel process can't plant an exporter page or script for the BIOS to frame.
+- **Retired:** every later BIOS boot sets the cookie and unregisters `/preview/` again, and so does every start of `/os/` while the marker is set (`/` no longer reaches the BIOS). That also renews the cookie, which Chrome keeps for at most 400 days. The service worker answers a navigation to `/` (whatever its query, so six's extension's `?slicc=leader&ext=…` and `?cherry=1&ui-only=1` too) with a redirect to `/os/` once the cookie is set, reading it with `cookieStore` on every such navigation. Only a window can set that cookie: kernel processes run in dedicated workers, which have neither `document.cookie` nor `cookieStore`. The extension's leader tab then shows seven; its side panel can't show `/os/` in its frame, so it just stops working. It always passes `/upgrade-to-seven.html` and `/assets/*` to the network on a shared origin, even when OPFS has files there: on www, `/assets/` belongs to SLICC 6 (its exporter's hashed chunks), so seven keeps nothing of its own there, and a kernel process can't plant an exporter page or script for the BIOS to frame.
 - **The import:** once the agent runs on `/os/`, `os/six.js` hands `slicc-os.six-import` to it with `control.importProfile({ inPlace })`. The agent moves the files out of `/slicc-fs`, and deletes the directory on success; the key goes then. An import that fails or throws keeps the key and shows a notice, and the next start tries again. A key whose directory has no readable `manifest.json` stays too, with the same notice, and nothing moves; only leftover directories that no key names are ignored. Tabs take turns under the Web Lock `slicc-os.six-import` and read the key again once they hold it.
 
 ### Integrity

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@ai-ecoverse/slicc-bios",
-  "version": "1.44.11",
+  "version": "1.44.12",
   "description": "Slim loader that boots SLICC into OPFS and serves the UI from there",
   "type": "module",
   "license": "Apache-2.0",
@@ -46,7 +46,7 @@
     "@ai-ecoverse/slicc-browsers": "1.18.14",
     "@ai-ecoverse/slicc-cdp": "1.41.20",
     "@ai-ecoverse/slicc-node": "2.5.1",
-    "@ai-ecoverse/slicc-shared-web": "2.12.3",
+    "@ai-ecoverse/slicc-shared-web": "2.12.4",
     "@ai-ecoverse/slicc-spectrum": "1.104.1",
     "@ai-ecoverse/slicc-vault": "1.17.0",
     "@biomejs/biome": "2.5.15",