@ai-ecoverse/slicc-bios 1.54.5 → 1.54.6
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/README.md +1 -0
- package/package.json +1 -1
package/README.md
CHANGED
|
@@ -80,6 +80,7 @@ On a shared origin, the BIOS moves SLICC 6 into seven in this browser once, afte
|
|
|
80
80
|
- **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.
|
|
81
81
|
- **Failure** (`error`) removes the frame and sets nothing, so six keeps working. The BIOS shows the error with **Try again** and **Not now**.
|
|
82
82
|
- **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.
|
|
83
|
+
- **Opening seven:** after an upgrade on exactly `www.sliccy.ai`, each boot renews `slicc-home=www` (`Domain=sliccy.ai`, `Path=/`, `Secure`, `SameSite=Lax`, 400 days). Only a top-level BIOS on exactly `seven.sliccy.ai` follows it to `https://www.sliccy.ai/7/`, keeping the fragment, and only if its own OPFS `os/` directory is absent. Other cookie values and hosts are ignored. `?stay` clears the cookie, removes the flag and boots here.
|
|
83
84
|
- **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. Closing the notice hides it until the next start; its **Stop trying** drops the key, so seven stops trying and leaves SLICC 6's files where they are (in `/slicc-fs` and the export directory). 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.
|
|
84
85
|
|
|
85
86
|
### Integrity
|