@ai-ecoverse/slicc-bios 1.13.2 → 1.15.0

package/README.md

@@ -48,7 +48,7 @@ A kernel process can still write to `/os/` and `/node_modules/` (any process whi
 - **Agents:** the rail of cones and their scoops, with each one's status (spectrum ≥ 1.23.0). Selecting a scoop opens its chat, and **Drop** stops it after a confirm. The header picker lists the cones and creates new ones with **New cone**. A cone starts scoops with the `agent` and `subagent` commands that slicc-agent installs in `/usr/local/bin`, mode 755, on every user's `PATH` (slicc-agent ≥ 3.35.0; it removes the copies earlier versions put in `$PNPM_HOME/bin` once the new ones are in place): `agent --prompt …` runs a scoop until it answers, and `agent --async …` starts one that reports back to its cone as a lick.
 - **Chat:** SLICC's agent, a chat per cone or scoop, once it's installed (see [Agent](#agent)). Its tab joins the terminal's group without taking focus. The model is AWS Bedrock (`us.anthropic.claude-sonnet-5-5` in `us-west-2`) with a Bedrock API key entered under **Settings → Accounts**. The key stays in the agent worker's encrypted credential store. Bedrock sends no CORS headers, so chat needs a local proxy or the extension (see [Network](#network)).
 - **Terminal:** `bash -i` sessions on the kernel, starting in `/home`, as many as you open with **+**.
-- **Files:** the OPFS root as a tree. `/.slicc` (the agent's own state, mode 0700 from slicc-agent 3.35.0) and `/.slicc-unlinked` (where the kernel keeps a deleted file that a program still has open, slicc-kernel ≥ 1.37.1) are hidden (`hide`, spectrum ≥ 1.9.0); `/node_modules`, `/opt/agent/node_modules`, pnpm's store and `/home/.cache` are listed but not scanned. The tree follows what the terminal writes (a rescan every 2 s and on `FileSystemObserver` records). Files open in tabs, and **Edit** turns a tab into a text area that **Save** or `Mod+S` writes back to OPFS. Mounted folders show in the tree too (see [Folder mounts](#folder-mounts)).
+- **Files:** the OPFS root as a tree. `/.slicc` (the agent's own state, mode 0700 from slicc-agent 3.35.0) and `/.slicc-unlinked` (where the kernel keeps a deleted file that a program still has open, slicc-kernel ≥ 1.37.1) are hidden (`hide`, spectrum ≥ 1.9.0); `/node_modules`, `/opt/agent/node_modules`, pnpm's store and `/home/.cache` are listed but not scanned. The tree follows what the terminal writes: a rescan every 2 s, and on `FileSystemObserver` records. From spectrum 1.85.1, records only under hidden or unscanned trees cause no rescan, and the rest cause at most one every 2 s, so an agent install into `/opt/agent/node_modules` no longer rescans the whole tree per record. Files open in tabs, and **Edit** turns a tab into a text area that **Save** or `Mod+S` writes back to OPFS. Mounted folders show in the tree too (see [Folder mounts](#folder-mounts)).
 - **Memory:** what the agent remembers (slicc-agent ≥ 3.14.0, spectrum ≥ 1.28.0). Each scope is one `MEMORY.md`: `/home/.pi/agent/memory/` for everyone and one per cone, `/home/.pi/agent/agent-memory/<path>/` for roles. An entry is a `###` title under a `##` section, with an optional `tag:` line before its body. The agent writes them with `memory_write`, the panel's **Save** and **Forget** write the same files, and a file edited by hand shows up in the panel.
 - **Changes:** what agents changed in git repositories, by repository, with the diff and **Accept** or **Revert** per change or for all (slicc-agent ≥ 3.21.1, spectrum ≥ 1.37.0). It sits next to the Freezer, closed by default, and opens from the rail or View. Git isn't preinstalled, so until someone runs `pnpm add -g @ai-ecoverse/wasm-git` it says so and shows that command.
 - **Freezer:** every conversation in the session database (slicc-agent ≥ 3.23.0, spectrum ≥ 1.39.0). Live cones show **Open**. A cone deleted with **Delete cone** in Agents (which asks first), an earlier chat left by New chat, or a stopped scoop or agent run stays there with its title, model, kind and message count. **Thaw** brings it back as a cone, and the row then says what it was thawed as. **Remove**, which asks first, deletes its working folders; the conversation stays in the database.
@@ -376,7 +376,7 @@ seven can also join a tailnet, with a patched build of Tailscale's wasm client (
       - **Identity:** one persistent DTLS certificate per hub origin (`RTCPeerConnection.generateCertificate`, ECDSA P-256 for a year, in the IndexedDB database `slicc-follow`), so the device and its access survive reloads. Unlinking deletes it.
       - **The link:** the follower answers as the link's node: its HELLO says `role: 'node'`, `kind: 'seven'`, caps `join` and `permissions`, and its tab as `node`, and it opens even stream ids. The owner treats a link as a follower because the hub said `slicc-seven/1`, and closes it if HELLO disagrees. A follower gets no `.slicc.internal` name, no exit, and none of the CLI kinds: the owner refuses `kernel`, `agent` and `browsers` from it with `EOPNOTSUPP`.
       - **View, Control and Terminal:** each follower certificate has three switches in Linked devices, off by default and kept with the device in `slicc-os.devices` (`setAccess` on the network port). Control and Terminal need View, so turning either on turns View on, and turning View off clears both. Without View a follower links but gets nothing: it shows as **Asks to follow**, with Allow, and its page says it waits for the owner. The owner's HELLO carries the current switches, and every change goes to the follower as `OPEN { kind: 'permissions', view, control, terminal }` on the control channel. Losing View resets the follower's open streams with `EACCES`, and so does losing Terminal for its terminals. For a CLI, the old **Allow remote control** is the same Control switch.
-      - **Chat (`pi`):** with View, the follower opens `OPEN { kind: 'pi' }` and gets the owner's agent, the same replicated chat a follower tab has. The owner bridges the stream to `owner.port({ readOnly, pages: false, device })` with slicc-agent's `bridgePort` (agent ≥ 3.32.0; `device`, the link's id, from 5.9.0), read-only unless the device has Control, and without `pages`, so a follower's agent can't drive the owner's panels. The follower builds its `AgentConnection` with `linkEndpoint` and `connectAgent`, and spectrum's agent model on top. The stream carries slicc-agent's frames: a `u32` length, a `u8` tag (data, hello or close) and the payload. Without Control, a send, steer or stop is refused by the owner's agent with `EACCES`, and the chat shows that it watches only. Changing Control resets the stream, so the follower reconnects with the new access, and losing View resets it with `EACCES`. The follower installs `/opt/agent` itself, for `page.js` and the agent model, in a kernel it starts only for that install. Linked devices shows *Watching* while a follower's chat is open. A failed connection is tried again after 2 s, except when the owner runs another agent version: `connectAgent` then rejects with `EVERSION` (slicc-agent ≥ 5.5.2), and the follower shows the agent's sentence as bios's own warning (`follow:other-agent-version`, not dismissable) and makes no further attempt in that follow session.
+      - **Chat (`pi`):** with View, the follower opens `OPEN { kind: 'pi' }` and gets the owner's agent, the same replicated chat a follower tab has. The owner bridges the stream to `owner.port({ readOnly, pages: false, device })` with slicc-agent's `bridgePort` (agent ≥ 3.32.0; `device`, the link's id, from 5.9.0), read-only unless the device has Control, and without `pages`, so a follower's agent can't drive the owner's panels. The follower builds its `AgentConnection` with `linkEndpoint` and `connectAgent`, and spectrum's agent model on top. The stream carries slicc-agent's frames: a `u32` length, a `u8` tag (data, hello or close) and the payload. Without Control, a send, steer or stop is refused by the owner's agent with `EACCES`, and the chat shows that it watches only. Changing Control resets the stream, so the follower reconnects with the new access, and losing View resets it with `EACCES`. The follower installs `/opt/agent` itself, for `page.js` and the agent model, in a kernel it starts only for that install. Linked devices shows *Watching* while a follower's chat is open. A failed connection is tried again after 2 s, except when the owner runs another agent version: `connectAgent` then rejects with `EVERSION` (slicc-agent ≥ 5.5.2), and the follower shows the agent's sentence as bios's own warning (`follow:other-agent-version`, not dismissable) and makes no further attempt in that follow session. Meanwhile its follow port's state carries the sentence as `refused` (spectrum ≥ 1.85.0): the top-bar light turns neutral and reads *Can’t follow <owner>*, the chat drops its *Watch only* note, and the page stays read-only. A later follow session that connects clears it, and the warning with it.
       - **Terminals (`terminal`):** with View and Terminal, the follower's Terminal panel opens shells in the owner's kernel. Each one is `OPEN { kind: 'terminal', cols, rows, cwd? }`, and the owner runs `bash -i` there with its own terminals' prompt, as the same user its own terminals use (root today, so Terminal is a root shell on the owner's SLICC), and answers OPENED `{ pid }`. Both directions then carry records, each a `u32` length, a `u8` type and a payload: `0` terminal bytes, `1` a resize as `{ cols, rows }` JSON, `2` a signal name (`INT`, `TSTP`, `QUIT`, `HUP`), and, from the owner only, `3` the shell's exit status as a decimal string, just before END. A bad record or size resets the stream with `EPROTO` or `EINVAL`. The follower's END closes the shell, and the owner ends the stream when the shell exits. Linked devices shows *Terminal open* while one runs (`terminals`), and turning Terminal or View off resets every open shell with `EACCES`.
       - **Names:** both sides call themselves `SLICC on <platform>` (`navigator.userAgentData.platform`). When two show the same name, the first four hex digits of the certificate fingerprint are added.
     - **Sevens this kernel follows (the in-kernel `slicc`):** the optional `slicc` package (`@ai-ecoverse/wasi-slicc`, slicc-cli's client commands built for `wasip1`) runs `slicc <join-url> prompt|watch|abort` in seven's terminal against another seven's agent, as slicc-cli's README specifies in §1.4 and §5.16. The program never touches WebRTC, the hub or the join state: it reaches the page's **link facade** at `SLICC_LINK_URL` (`tcp://127.0.0.1:7400`), which `os/os.js` declares with `createKernel({ facades: { link: { port: 7400, hook } } })` (`os/facade.js`, slicc-kernel ≥ 1.90.0), and the page follows that seven's tray for it (`os/leaders.js`).
@@ -479,9 +479,13 @@ Limits:
 [`.github/workflows/canary.yml`](.github/workflows/canary.yml) answers "is bios main green with these candidate versions?" before anyone asks for a pin. It never pushes, pins or opens a PR: it reports.
 
 - **Triggers:** `workflow_dispatch` and `workflow_call` with `overrides`, a JSON list of `name@version` (`["@ai-ecoverse/slicc-kernel@1.81.0"]`), and optionally `runner`, `shards` (names from [`scripts/canary/shards.json`](scripts/canary/shards.json); `follow-chat`, `remote-pydata`, `users-agent-ui`, `packages-update-cdp`, `guard`, `guard-set-extension-prompt`, `guard-set-extension-lagging`, `guard-set-proxy-prompt`, `guard-set-proxy-lagging`, `k4-link`, `user-packages-keys-favicon` and `rest` by default; a shard's `env` in that file, such as `GUARD_VARIANTS`, is set for its tests, or `sweep` for just the base-set sweep and the certs check), `expect` and `bios-ref` (any branch or sha of slicc-bios: the shard jobs check it out and lay this ref's `scripts/canary`, and `sweep.test.mjs` if it has none, over it; a ref whose `pins.test.mjs` has no canary mode gets the candidates in its working copy of `certs.json` instead, and the report still lists them as candidates). A proof in `proofs.json` can name its own `ref` the same way. An hourly `schedule` checks npm's `latest` of every kernel, jsh, cdp, agent, `wasm-*`, `wasi-*`, `wasix-*` and `py-*` package that a `src/packages/**/package.json` pins, and runs once with every newer one as the overrides, only when that list differs from the last scheduled canary's (its inputs are kept in the Actions cache). A `pull_request` trigger, filtered to the canary's own files, runs the proof in [`scripts/canary/proofs.json`](scripts/canary/proofs.json) from one plan job, cancelling a superseded run: kernel 1.78.0 on the `sweep` shard must regress grep, sed, jq, xz, findutils, diffutils and patch with exit 70 (kernel #483). A second proof packs `@ai-ecoverse/slicc-cdp@1.26.2` with `npm pack`, uploads it from the plan job, and runs it as a candidate artifact on `packages-update-cdp` and `guard` with `repeat: 3`.
-- **A candidate from another repo's run:** `candidate-package` (the package it replaces, `@ai-ecoverse/slicc-cdp`), `candidate-artifact` (an artifact holding one `npm pack` tarball of it), `candidate-run` (the run that uploaded it), `candidate-sha256` and optionally `candidate-repo` (the caller's repository by default). Each shard job downloads the artifact with `github.token`, which under `workflow_call` is the caller's, so the caller's job needs `actions: read`. [`override-pins.mjs`](scripts/canary/override-pins.mjs) checks the tarball's sha256 before it reads anything and refuses a mismatch, then checks the tarball is that package with an exact version. It seeds the harness download cache with the bytes at the npm URL of that version, and rewrites the pins and locks through a local registry that serves npm's packuments with that version added, so an unpublished `x.y.z-pr.N.M` locks like a published one (npm's lock gets the registry URL back). Everything else stays a registry version. The report lists it as `candidate (artifact <run>/<name>, sha256 …)`.
+- **A candidate from another repo's run:** `candidate-package` (the package it replaces, `@ai-ecoverse/slicc-cdp`), `candidate-artifact` (an artifact holding one `npm pack` tarball of it), `candidate-run` (the run that uploaded it), `candidate-sha256` (the tarball's) and optionally `candidate-repo` (the caller's repository by default). Each shard job downloads the artifact with `github.token`, which under `workflow_call` is the caller's, so the caller's job needs `actions: read`. [`override-pins.mjs`](scripts/canary/override-pins.mjs) checks the tarball's sha256 before it reads anything and refuses a mismatch, then checks the tarball is that package with an exact version. It seeds the harness download cache with the bytes at the npm URL of that version, and rewrites the pins and locks through a local registry that serves npm's packuments with that version added, so an unpublished `x.y.z-pr.N.M` locks like a published one (npm's lock gets the registry URL back). Everything else stays a registry version. The report lists it as `candidate (artifact <run>/<name>, sha256 …)`.
+- **Binding the candidate to its upload:** a call that names a candidate also passes `candidate-artifact-id` and `candidate-artifact-digest`, the `artifact-id` and `artifact-digest` outputs of the step that uploaded it (the digest is the zip's SHA-256, not the tarball's `candidate-sha256`; a `sha256:` prefix is allowed). `candidate-binding` is `strict` by default, and the plan refuses a candidate without both values. Only an explicit `candidate-binding: legacy` takes a candidate by name, as before; runs that name no candidate, such as the schedule and the PR proofs, don't set it. Before anything from the tested ref runs, [`scripts/canary/bind.mjs`](scripts/canary/bind.mjs) reads `GET /repos/{repo}/actions/artifacts/{id}` and `GET /repos/{repo}` and refuses the artifact unless its id, name, `workflow_run.id`, `workflow_run.repository_id` and digest are the bound ones and it hasn't expired. The shard then downloads it by `artifact-ids` with `digest-mismatch: error`, and the tarball's sha256 check stays. The PR proof's tarball is bound the same way, to the plan job's upload step.
+- **Digests:** every digest the canary emits is the uploader's `artifact-digest` output, 64 lowercase hex digits with no prefix. The REST API's `digest` field is `sha256:` followed by the same digits, so strip that prefix before comparing.
+- **`artifact-id`, `artifact-digest` and `artifacts`** are `workflow_call` outputs. The first two are the `canary` report artifact's, from the report job's upload step. `artifacts` is a JSON list of `{ role, name, id, digest, attempt }` covering every artifact the call uploaded, in this order: `plan` (the plan job's `canary-inputs` on a schedule, or the PR proof's tarball), then for each planned shard, in plan order, `shard` (`<label>-canary-shard-<run>-<shard>`) and `files` (`<label>-canary-files-<run>-<shard>`, present only when the shard left files), then `report` (`<label>-canary`). Names follow from the trusted plan. Each id and digest is the output of the step that uploaded that artifact, never an API lookup, and a `shard` or `files` row appears only once the report has checked it against the API. `attempt` is the `github.run_attempt` of the job that uploaded it: a job carried over from an earlier attempt keeps its number, and ids come only from the job outputs of the current attempt.
+- **The shards reach the report by their upload steps:** a matrix job's outputs collapse to the last job's, so each shard job writes its rows to its own output, `binding_<strategy.job-index>` (the shard job declares `binding_0` to `binding_15`, and the plan refuses more than 16 jobs). The report job reads them all with `toJSON(needs.shard.outputs)`, checks each planned shard's `shard` and `files` artifacts against the API the same way as the candidate (with this run and this repository), and downloads only the verified `shard` ids. The shard jobs ran the candidate, so this API check, not the shard job, is what ties each id to the one artifact of that name in this run. It refuses a binding for a shard the plan didn't make, a row whose name isn't the planned one (a forged extra suffix), a directory in the download that no verified binding names, a `shard.json` holding another shard, and any download that failed its digest check. Each refusal turns the canary red with `FAIL refused <name>`, and the bindings step prints its own `canary bindings: PASS|FAIL` verdict, which the report requires.
 - **`repeat`** (1 to 10, default 1): each selected test file runs that many times with the candidates, and the files with a failure run that many times on main's pins. A test failing in every candidate run and no baseline run is a regression, one failing in every run of both is a failure on both, and anything mixed is flaky. Each row carries its counts, `candidate 2/3, baseline 0/3`.
-- **`result`**, a `workflow_call` output next to `ok`: the JSON summary (`ok`, `counts`, `regressions`, `both`, `flaky`, `failures`, `missingShards`, `unexplainedExits`, `candidates`, `overrides`, `repeat`) plus the `canary` artifact's name and URL.
+- **`result`**, a `workflow_call` output next to `ok`: the JSON summary (`ok`, `counts`, `regressions`, `both`, `flaky`, `failures`, `missingShards`, `unexplainedExits`, `refused`, `candidates`, `overrides`, `repeat`) plus the `canary` artifact's name, URL, id and digest. Those last two are a convenience: `artifact-id`, `artifact-digest` and `artifacts` are the authoritative values. A plan that refuses its inputs still gets a report, `canary: FAIL the plan refused: …`.
 - **Permissions:** `contents: read` and `actions: read`, no secrets and no `id-token`. A caller outside bios runs the plan with its inputs: the PR proofs and the hourly npm check run only for bios's own triggers.
 - **Jobs:** one plan job, one job per shard of each run, and one report job, because the queue for a runner costs more than the work.
 - **Runner:** fork code never runs on the org's Cloud Run pools. A same-repo `pull_request` (the proofs from our own branches), or a `schedule`, `workflow_dispatch`, `workflow_run` or `release` run on `main` (any `bios-ref`), puts the shard jobs on the `runner` input, else the `CERT_RUNNER` repository variable (`cloud-run-bench`), and the light plan and report jobs on `CERT_LIGHT_RUNNER` (`cloud-run`). Everything else runs on `ubuntu-latest`, and the `runner` input is ignored: fork pull requests, and dispatches from any other branch. Under `workflow_call` the same check reads the caller's event. The pools run with "no new privileges", so `sudo` can't become root there: the shard job installs Chromium's system libraries only when `sudo -n true` works, and otherwise relies on the image's.

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@ai-ecoverse/slicc-bios",
-  "version": "1.13.2",
+  "version": "1.15.0",
   "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.7.10",
     "@ai-ecoverse/slicc-node": "2.5.1",
     "@ai-ecoverse/slicc-shared-web": "1.23.1",
-    "@ai-ecoverse/slicc-spectrum": "1.84.2",
+    "@ai-ecoverse/slicc-spectrum": "1.86.3",
     "@ai-ecoverse/slicc-vault": "1.9.2",
     "@biomejs/biome": "2.5.15",
     "es-module-lexer": "3.0.3",

package/src/packages/package-lock.json

@@ -10,7 +10,7 @@
         "@ai-ecoverse/slicc-cdp": "1.26.2",
         "@ai-ecoverse/slicc-clipboard": "1.0.2",
         "@ai-ecoverse/slicc-kernel": "1.113.0",
-        "@ai-ecoverse/slicc-spectrum": "1.84.2",
+        "@ai-ecoverse/slicc-spectrum": "1.86.3",
         "@ai-ecoverse/wasi-pnpm": "12.9.1-9",
         "@ai-ecoverse/wasi-ripgrep": "15.2.0-3",
         "@ai-ecoverse/wasm-bash": "5.3.0-18",
@@ -80,9 +80,9 @@
       }
     },
     "node_modules/@ai-ecoverse/slicc-spectrum": {
-      "version": "1.84.2",
-      "resolved": "https://registry.npmjs.org/@ai-ecoverse/slicc-spectrum/-/slicc-spectrum-1.84.2.tgz",
-      "integrity": "sha512-7nSam2gjvT18jjpajcEn4Q7IqX0qTITU5G4ZrH1oipcgiOMmNmXTMeWOra1CAPL1+JZMHHQIIdYmh6nBCLAGlw==",
+      "version": "1.86.3",
+      "resolved": "https://registry.npmjs.org/@ai-ecoverse/slicc-spectrum/-/slicc-spectrum-1.86.3.tgz",
+      "integrity": "sha512-SvF+bJzZ4azUr8dABvwfuYMTiDbS1zHMOc5Wq2lyFNYRMsq+/TB6xSYdOrLfEuH/x2xXN2gyrVzJ8Xs7gQI14g==",
       "license": "Apache-2.0",
       "engines": {
         "node": ">=24"

package/src/packages/package.json

@@ -7,7 +7,7 @@
     "@ai-ecoverse/slicc-cdp": "1.26.2",
     "@ai-ecoverse/slicc-clipboard": "1.0.2",
     "@ai-ecoverse/slicc-kernel": "1.113.0",
-    "@ai-ecoverse/slicc-spectrum": "1.84.2",
+    "@ai-ecoverse/slicc-spectrum": "1.86.3",
     "@ai-ecoverse/wasi-pnpm": "12.9.1-9",
     "@ai-ecoverse/wasi-ripgrep": "15.2.0-3",
     "@ai-ecoverse/wasm-bash": "5.3.0-18",

package/src/packages/pnpm-lock.yaml

@@ -21,8 +21,8 @@ importers:
         specifier: 1.113.0
         version: 1.113.0
       '@ai-ecoverse/slicc-spectrum':
-        specifier: 1.84.2
-        version: 1.84.2
+        specifier: 1.86.3
+        version: 1.86.3
       '@ai-ecoverse/wasi-pnpm':
         specifier: 12.9.1-9
         version: 12.9.1-9
@@ -112,8 +112,8 @@ packages:
     resolution: {integrity: sha512-PGJvZUm/oQYuS9pbUxDIpBSCeyaW91wDN2yWPCZIv664WDWKsiCTeQ1c4i8xU4Bq7C66viFK6EzZhvvofQ6b3Q==}
     engines: {node: '>=24'}
 
-  '@ai-ecoverse/slicc-spectrum@1.84.2':
-    resolution: {integrity: sha512-7nSam2gjvT18jjpajcEn4Q7IqX0qTITU5G4ZrH1oipcgiOMmNmXTMeWOra1CAPL1+JZMHHQIIdYmh6nBCLAGlw==}
+  '@ai-ecoverse/slicc-spectrum@1.86.3':
+    resolution: {integrity: sha512-SvF+bJzZ4azUr8dABvwfuYMTiDbS1zHMOc5Wq2lyFNYRMsq+/TB6xSYdOrLfEuH/x2xXN2gyrVzJ8Xs7gQI14g==}
     engines: {node: '>=24'}
     peerDependencies:
       '@shikijs/langs': 4.5.0
@@ -208,7 +208,7 @@ snapshots:
 
   '@ai-ecoverse/slicc-kernel@1.113.0': {}
 
-  '@ai-ecoverse/slicc-spectrum@1.84.2': {}
+  '@ai-ecoverse/slicc-spectrum@1.86.3': {}
 
   '@ai-ecoverse/wasi-pnpm@12.9.1-9': {}