@ai-ecoverse/slicc-bios 1.17.7 → 1.17.9

package/README.md

@@ -6,7 +6,7 @@ The page shows six boot steps as they run:
 
 1. **Acquire OPFS** – open the origin private file system and ask for persistent storage.
 2. **Create installer worker** – start `installer.js`, a shared worker that does all of the BIOS's OPFS writes and is shared by every tab.
-3. **Install packages from npm into OPFS** – the installer reads [`src/packages/package-lock.json`](src/packages/package-lock.json), the lockfile the BIOS ships with. It skips packages that name an `os` or `cpu` (native binaries such as esbuild's, which can't run in a browser). For every other locked package it downloads the tarball from `registry.npmjs.org` and checks its `integrity`, then unpacks it with the built-in `DecompressionStream` and [`modern-tar`](https://github.com/ayuhito/modern-tar) into OPFS at its lockfile path (`node_modules/…`), dropping `.` segments from entry names and skipping any entry with `..`. A package that is already there is rewritten in place, never emptied first: every file is overwritten whole (an OPFS write commits on close), the entry points (`package.json`, its `bin` and `main`) come last, and only then do the files the new version no longer has go, so a running kernel or another tab never finds the package missing. While it unpacks, it hashes every file (SHA-256) and records the hashes in IndexedDB (see [Integrity](#integrity)). It also keeps each file's mode from the tarball, owned by root: once a package's files are in, it hands their paths and modes to the kernel's `writeMetadata` (`@ai-ecoverse/slicc-kernel/meta`, read from the installed kernel), in one batch per run, so an executable outside `bin/`, such as pnpm's `shims/i`, stays executable when the kernel checks modes. The seed's files are recorded as root's `0644`. A kernel without `/meta` skips this. A package installed before the kernel had `/meta` gets its modes once, on the first run with it: the installer fetches its tarball again, checks its integrity, reads the modes from the headers without unpacking, and marks the receipt (`modes: true`). A package installed or replaced later is marked when it's stamped. It also records a receipt in `var/lib/bios/`. A package whose recorded integrity matches the lockfile's and whose files are still there isn't downloaded again, so pinning a new version replaces just that package. Replacing a package keeps its nested `node_modules`, and packages the lockfile no longer lists are deleted along with their receipts and hashes. A package without recorded hashes is downloaded again, even with a receipt, so the first boot after integrity checks arrived downloads the base set once. Last, the installer copies the deployment's `package.json` and `pnpm-lock.yaml` to the OPFS root for pnpm, and the lockfile once more to `var/lib/slicc/pnpm-lock.yaml`, which records what is installed (see [Updates](#updates)).
+3. **Install packages from npm into OPFS** – the installer reads [`src/packages/package-lock.json`](src/packages/package-lock.json), the lockfile the BIOS ships with. It skips packages that name an `os` or `cpu` (native binaries such as esbuild's, which can't run in a browser). For every other locked package it downloads the tarball from `registry.npmjs.org` and checks its `integrity`, then unpacks it with the built-in `DecompressionStream` and [`modern-tar`](https://github.com/ayuhito/modern-tar) into OPFS at its lockfile path (`node_modules/…`), dropping `.` segments from entry names and skipping any entry with `..`. A package that is already there is rewritten in place, never emptied first: every file is overwritten whole (an OPFS write commits on close), the entry points come last: a command's wasm (and its variants), then its glue or script with `bin`, `main` and `exports` targets, then `package.json`, and only then do the files the new version no longer has go, so a running kernel or another tab never finds the package missing. While it unpacks, it hashes every file (SHA-256) and records the hashes in IndexedDB (see [Integrity](#integrity)). It also keeps each file's mode from the tarball, owned by root: once a package's files are in, it hands their paths and modes to the kernel's `writeMetadata` (`@ai-ecoverse/slicc-kernel/meta`, read from the installed kernel), in one batch per run, so an executable outside `bin/`, such as pnpm's `shims/i`, stays executable when the kernel checks modes. The seed's files are recorded as root's `0644`. A kernel without `/meta` skips this. A package installed before the kernel had `/meta` gets its modes once, on the first run with it: the installer fetches its tarball again, checks its integrity, reads the modes from the headers without unpacking, and marks the receipt (`modes: true`). A package installed or replaced later is marked when it's stamped. It also records a receipt in `var/lib/bios/`. A package whose recorded integrity matches the lockfile's and whose files are still there isn't downloaded again, so pinning a new version replaces just that package. Replacing a package keeps its nested `node_modules`, and packages the lockfile no longer lists are deleted along with their receipts and hashes. A package without recorded hashes is downloaded again, even with a receipt, so the first boot after integrity checks arrived downloads the base set once. Last, the installer copies the deployment's `package.json` and `pnpm-lock.yaml` to the OPFS root for pnpm, and the lockfile once more to `var/lib/slicc/pnpm-lock.yaml`, which records what is installed (see [Updates](#updates)).
 4. **Add UI page to OPFS** – the installer copies `src/seed/` to `os/` in OPFS and records each file's hash. This is a stand-in until the UI ships as a downloadable asset.
 5. **Intercept same-origin requests** – `sw.js`, a module service worker, answers in-scope requests from OPFS and passes everything else to the network (see [What the service worker serves](#what-the-service-worker-serves)). The code it serves from OPFS carries `Cross-Origin-Opener-Policy: same-origin`, `Cross-Origin-Embedder-Policy: require-corp` and `Cross-Origin-Resource-Policy: same-origin`, so the UI page and the workers it starts are cross-origin isolated. Scripts it serves get their bare imports resolved (see [Modules](#modules)).
 6. **Serve UI from OPFS** – navigate to `os/` (keeping the URL fragment) with a cross-document view transition. That page imports [`@ai-ecoverse/slicc-kernel`](https://github.com/ai-ecoverse/slicc-kernel) and [`@ai-ecoverse/slicc-spectrum`](https://github.com/ai-ecoverse/slicc-spectrum) by name from `node_modules/` in OPFS, starts the kernel on the OPFS root and boots SLICC's UI, `<slicc-app>`, on spectrum's kernel model. The agent comes later, from its own pnpm project (see [Agent](#agent)). Commands come from the installed packages: `bash`, coreutils, `grep`, `sed`, findutils, `gawk`, `diff` (with `cmp`, `sdiff` and `diff3`), `patch`, `rg` (ripgrep), `jq`, `less`, `tree`, `tar` with `gzip`, `xz` and `bzip2` (and their `gunzip`, `zcat`, `unxz`, `xzcat`, `lzma`, `bunzip2` and `bzcat` names), `curl`, `mount`, `umount`, `clear`, `tput`, `tset`, `reset`, `pnpm` with its `npm` and `npx` shims, and `playwright-cli` and `curlwright` from slicc-cdp. The shell starts in `/home` as **root** (slicc-kernel ≥ 1.44.0 has users: `/etc/passwd` and `/etc/group` list root, nobody, sudo, users and nogroup), so the prompt ends in `#`, `whoami` and `id` say root, `ls -l` and `ps` show user names, and root's `HOME` is `/root` (mode 0700) with `PNPM_HOME=/usr/local/share/pnpm`. bash, coreutils, procps and git are the homescoop H1 rebuilds that know about users; older builds claimed uid 1000. `tar` forks the compressors for `-z`, `-J` and `-j` through `/bin/sh`. Hard links in archives aren't recreated, and there's no `--zstd`. xz is single-threaded: `-T` is accepted but has no effect. The `zgrep`, `xzgrep` and `bzgrep`-style wrapper scripts aren't installed as commands. Whatever the shell writes stays in OPFS across reloads. The kernel terminates HTTPS with `wasm-tls-engine`, so `curl https://…` works over whichever transport is picked (see [Network](#network)). `wasm-git` is left out for its size (53 MB); it can come later through pnpm.
@@ -533,7 +533,7 @@ No test calls a real model. Every test serves an empty `packages/agent/` project
 
 `ci.yml` runs on pull requests, the merge queue and pushes to `main`. A `ci / plan` job ([`scripts/ci/plan.mjs`](scripts/ci/plan.mjs)) splits the integration tests into 14 shards: each `guard-set-*.test.mjs` becomes one item per detach variant of the pinned guard vectors (run with `GUARD_VARIANTS`), every other test file is one item, and the items go in a random order, seeded with the run id, to the least-loaded shard by the times in [`scripts/ci/durations.json`](scripts/ci/durations.json), the longest items first. Each shard (`ci / integration (s01)` …) runs its items with [`scripts/ci/shard.mjs`](scripts/ci/shard.mjs), one `node --test` per guard-set file with its variants (the other files join the first), counting a test the guard-set helper reports for that run's guard-set file, keeps the harness's artifacts and coverage from every run, and writes its verdict line. `ci / test`, the required check, fails without a passing verdict from every shard the plan named.
 
-The pull request's number mod 4 picks an arm of a two-by-two experiment, for its runs and its merge queue runs alike (pushes to `main` are control): 0 is control, 1 cancels the other shards when one fails (`fail-fast`), 2 runs the files with a failing test once more and passes the shard when they pass (`retry`, skipped when it wouldn't fit the shard's 62 minutes), and 3 does both. The plan, with the arm, the seed and each shard's items, is in the job summary and the `experiment-plan` artifact; each shard's record (`artifacts/experiment/<shard>.json`: its groups, the first run and any retry with their exit codes, counts and failed files) is in its `integration-<shard>` artifact, with each item's time and every test that failed and then passed on the retry. `ci / test` joins them into `summary.json` (the `experiment-summary` artifact), and for each test that flipped it files an issue labeled `flaky-test`, or comments on the open one for that test, with the run, the arm, the shard and the first run's error ([`scripts/ci/summary.mjs`](scripts/ci/summary.mjs)); this step never fails the check, and a fork's read-only token files nothing. `node scripts/ci/durations.mjs` refreshes `durations.json` with the median times of the last 40 runs' summaries. After 100 pull requests the arms are compared on time to merge, merge queue failures, and the time a pull request waits on CI.
+Every shard runs the files with a failing test once more and passes when they pass (`retry`, skipped when it wouldn't fit the shard's 62 minutes). From 2026-10-17 to 2026-10-18 a two-by-two experiment compared that with control: 0 of 28 merge queue runs with retry failed, against 15 of 42 without it, so the arms without retry were retired. The pull request's number mod 2 still picks whether a failing shard also cancels the others (`fail-fast+retry` for odd numbers, `retry` for even ones and pushes to `main`), for its runs and its merge queue runs alike, to measure what fail-fast does to the time a pull request waits on CI and its time to merge. The plan, with the arm, the seed and each shard's items, is in the job summary and the `experiment-plan` artifact; each shard's record (`artifacts/experiment/<shard>.json`: its groups, the first run and any retry with their exit codes, counts and failed files) is in its `integration-<shard>` artifact, with each item's time and every test that failed and then passed on the retry. `ci / test` joins them into `summary.json` (the `experiment-summary` artifact), and for each test that flipped it files an issue labeled `flaky-test`, or comments on the open one for that test, with the run, the arm, the shard and the first run's error ([`scripts/ci/summary.mjs`](scripts/ci/summary.mjs)); this step never fails the check, and a fork's read-only token files nothing. `node scripts/ci/durations.mjs` refreshes `durations.json` with the median times of the last 40 runs' summaries.
 
 ## Hosting
 

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@ai-ecoverse/slicc-bios",
-  "version": "1.17.7",
+  "version": "1.17.9",
   "description": "Slim loader that boots SLICC into OPFS and serves the UI from there",
   "type": "module",
   "license": "Apache-2.0",