@ai-ecoverse/slicc-bios 1.51.22 → 1.51.25

package/README.md

@@ -270,7 +270,7 @@ Below the system rows, Install / Update offers **Optional packages** (spectrum
 
 Today it offers git, the GitHub CLI, OpenSSH, `slicc` (see [Sevens this kernel follows](#network)), Python, the Python data tools (numpy, pandas and matplotlib), Node.js (slicc-jsh's `node` and `jsh`), `sliccy:browser` for `.jsh` scripts, Ruby, Perl, Biome, the PDF tools (poppler), qpdf, rsync, screen, SQLite, the BIND tools (`dig`, `host` and `nslookup`), websocat, ntfy, GnuPG, fnox, mcpcat (an MCP client), zip (Info-ZIP's `zip`, `unzip` and `zipinfo`), xxd (vim's hex dump, with `xxd -r`) and ImageMagick. zip's `unzip` refuses an entry whose name isn't UTF-8 (an old Latin-1 or CP437 archive without a Unicode path): it says `cannot create <name>` / `Illegal byte sequence`, extracts the other entries and exits 50, and `unzip -l` still lists the entry. It never extracts it under a changed name, and `unzip -p` still streams its bytes ([homescoop#1174](https://github.com/ai-ecoverse/homescoop/issues/1174)). ImageMagick is homescoop's HEIF build (`wasm-imagemagick-heif`, a superset of the plain build, which isn't offered), with `magick`, `convert`, `mogrify`, `identify` and `magick-open`, and it reads HEIC and AVIF. A failed write leaves an existing target as it was. Its known issues: writing over another user's 0666 file in a sticky directory such as `/tmp` fails with `Operation not permitted`, though writing your own files works ([homescoop#1258](https://github.com/ai-ecoverse/homescoop/issues/1258)); `.mpc` writes fail with `cache resources exhausted` ([homescoop#1208](https://github.com/ai-ecoverse/homescoop/issues/1208)); and the cert's coverage gaps, among them the no-encoder fallback and MPC's two-file write ([homescoop#1209](https://github.com/ai-ecoverse/homescoop/issues/1209)). sudo for `magick`, `convert` or `mogrify` is offered once, never always, since they write files. No two entries' npm `latest` provide the same command, so an install never shadows another entry's; `packages.test` checks that against npm's current `latest`.
 
-- **Install** runs `pnpm add -g <package>@<version>` in the page's kernel, as a user would, under the Web Lock `slicc-optional`, so the commands work at once in every open shell. pnpm 12 gives each global add its own project under `$PNPM_HOME/global/v11/`; bios reads `PNPM_HOME` from the kernel's environment. Afterwards `os/packages.js` reads that project's `pnpm-lock.yaml`, and every package in it, the one added and each dependency, must pass [the gate](#optional-packages). A locked integrity that isn't the registry's for that version (drift) removes the package again and fails the row with *This version doesn't match the tested build*; any other refusal fails it with *Not offered: <reason>.* An Update that fails puts the version it had back (*… stays.*), and an install that fails removes the package, so nothing unchecked stays installed. A row with no version from npm installs nothing, and Install and Update ask npm for the offer again first, so they never act on the OPFS cache's version. An entry's `requires` (uv needs Python) are installed first. A package's kernel command always wins over the same package's Node `bin`. After each install and update, for every name that a package declares both in `slicc.commands` and in `bin`, bios replaces the link that pnpm made in root's `$PNPM_HOME/bin` with a symlink to `/usr/bin/<name>`, and removes it from a user's own `~/.local/share/pnpm/bin`, where the kernel then serves the user's own kernel command at that same path, but only when that link points into this package, so `mcpcat` runs `/usr/bin/mcpcat`, not a `#!/usr/bin/env node` script with no Node to run it, and a shell that already looked up `$PNPM_HOME/bin/mcpcat` keeps running the kernel command. Once the kernel command is gone (`pnpm remove -g`), the next pass removes such a symlink. A command chained right after the install in the same shell (`pnpm add -g mcpcat && mcpcat`) runs the kernel command at once too: since slicc-kernel 1.147.0 the kernel runs pnpm's Node shim for a package's own kernel command as that command (slicc-kernel#1453). Another package's bins are never touched, and a package with only a `bin` keeps it. A `pnpm add -g` typed in a shell gets the same pass: bios watches only the `bin` and `global` folders of root's `$PNPM_HOME` (`/usr/local/share/pnpm`) and of each user's `~/.local/share/pnpm`, and `/etc/passwd`, to add a user's when the user appears; about 50 ms after pnpm writes there, it runs that pass over the global's packages, as that user for a user's own global (bios#715). `/opt/user` (Your packages) isn't affected: its bins are not on `PATH`. A certified catalog package's agent skills reach every cone the same way. After the install or update, for each folder its `package.json` lists in `pi.skills`, bios links each skill in it into `/usr/share/skills/<name>`, through the kernel and as root, so no cone can change what the agent loads. The folder has to resolve inside the package; the skill's folder name has to match `^[a-z0-9][a-z0-9-]*$` and equal its `SKILL.md` `name`; and it mustn't collide with a built-in or with an entry it didn't make. The skill files are made readable by everyone (`a+rX`). bios records its links in `var/lib/slicc/optional/<id>/skills`, removes the ones an update drops, and removes all of them on Remove. A skipped skill is logged and never fails the install. The agent's rule stands: it doesn't scan root's global pnpm, so a user's `pnpm add -g` can't add skills. A project entry also **updates** a required package that's older than the catalog's before it installs, since it runs on the catalog's version: the data tools override their own Python away, and their builds need the catalog's Python. A global add brings its own pinned dependencies, so it leaves an older required package as it is.
+- **Install** runs `pnpm add -g <package>@<version>` in the page's kernel, as a user would, under the Web Lock `slicc-optional`, so the commands work at once in every open shell. pnpm 12 gives each global add its own project under `$PNPM_HOME/global/v11/`; bios reads `PNPM_HOME` from the kernel's environment. Afterwards `os/packages.js` reads that project's `pnpm-lock.yaml`, and every package in it, the one added and each dependency, must pass [the gate](#optional-packages). A locked integrity that isn't the registry's for that version (drift) removes the package again and fails the row with *This version doesn't match the tested build*; any other refusal fails it with *Not offered: <reason>.* An Update that fails puts the version it had back (*… stays.*), and an install that fails removes the package, so nothing unchecked stays installed. A row with no version from npm installs nothing, and Install and Update ask npm for the offer again first, so they never act on the OPFS cache's version. An entry's `requires` (uv needs Python) are installed first. A package's kernel command always wins over the same package's Node `bin`. After each install and update, for every name that a package declares both in `slicc.commands` and in `bin`, bios replaces the link that pnpm made in root's `$PNPM_HOME/bin` with a symlink to `/usr/bin/<name>`, and removes it from a user's own `~/.local/share/pnpm/bin`, where the kernel then serves the user's own kernel command at that same path, but only when that link points into this package, so `mcpcat` runs `/usr/bin/mcpcat`, not a `#!/usr/bin/env node` script with no Node to run it, and a shell that already looked up `$PNPM_HOME/bin/mcpcat` keeps running the kernel command. Once the kernel command is gone (`pnpm remove -g`), the next pass removes such a symlink. A command chained right after the install in the same shell (`pnpm add -g mcpcat && mcpcat`) runs the kernel command at once too: since slicc-kernel 1.147.0 the kernel runs pnpm's Node shim for a package's own kernel command as that command (slicc-kernel#1453). Another package's bins are never touched, and a package with only a `bin` keeps it. A `pnpm add -g` typed in a shell gets the same pass: bios watches only the `bin` and `global` folders of root's `$PNPM_HOME` (`/usr/local/share/pnpm`) and of each user's `~/.local/share/pnpm`, and `/etc/passwd`, to add a user's when the user appears; about 50 ms after pnpm writes there, it runs that pass over the global's packages, as that user for a user's own global (bios#715). Each pnpm home runs one such pass at a time, and a write during or after one starts another only if that home's `bin` entries or installed packages differ from what the last pass started from, so a removal that changed nothing starts nothing. That's the usual case for a user's own kernel command whose file names its own package: the kernel serves it at that path, so `rm -f` returns 0 and it stays. A file that can't be removed warns once in the console, doesn't stop the pass for the home's other packages, and is tried again when something in that home changes. The panel's step waits only for a step already running on the same `bin`, never for another home's (bios#1153). `/opt/user` (Your packages) isn't affected: its bins are not on `PATH`. A certified catalog package's agent skills reach every cone the same way. After the install or update, for each folder its `package.json` lists in `pi.skills`, bios links each skill in it into `/usr/share/skills/<name>`, through the kernel and as root, so no cone can change what the agent loads. The folder has to resolve inside the package; the skill's folder name has to match `^[a-z0-9][a-z0-9-]*$` and equal its `SKILL.md` `name`; and it mustn't collide with a built-in or with an entry it didn't make. The skill files are made readable by everyone (`a+rX`). bios records its links in `var/lib/slicc/optional/<id>/skills`, removes the ones an update drops, and removes all of them on Remove. A skipped skill is logged and never fails the install. The agent's rule stands: it doesn't scan root's global pnpm, so a user's `pnpm add -g` can't add skills. A project entry also **updates** a required package that's older than the catalog's before it installs, since it runs on the catalog's version: the data tools override their own Python away, and their builds need the catalog's Python. A global add brings its own pinned dependencies, so it leaves an older required package as it is.
 - **Progress:** a row shows pnpm's package counts once pnpm counts more than one package. Before that, a single package, such as Python, still shows its download in bytes, from pnpm's `Downloading` lines (see [Agent](#agent)). Without either the bar is indeterminate.
 - **State** comes from pnpm's global projects, not from a list of bios's own, so a package installed by hand shows as installed with its version. One older than npm's offered version offers **Update**, which adds that version; one at or above it offers **Remove**. bios never downgrades.
 - **A user's own installs:** bios also reads each user's own pnpm global (`/home/<user>/.local/share/pnpm/global/v11`, a `pnpm add -g` as `cone`), as root and read-only, straight from the files: it runs no pnpm as the user for that, and with kernel users off it reads none. Each row lists its installs (`installs`, slicc-spectrum#475): the panel's copy as `{ version, where: '/usr/local/share/pnpm', manager: 'panel' }` and each user's as `{ version, where: '/home/<user>/.local/share/pnpm', user, manager: 'pnpm' }`. The version and state follow the panel's copy, or else the user's newest. A row with any install never offers **Install**, and only a panel copy offers **Remove**; a row with only user installs offers **Update** when it's older than npm's offered version, and nothing otherwise. That **Update** runs `pnpm add -g` as each user whose copy is older, with their uid, gid, `HOME`, `PNPM_HOME` and `PATH` in their home, with `--ignore-scripts`, `--ignore-pnpmfile`, the store's integrity check and no release-age wait (the catalog's version is certified), never as root and never with the system's environment, so the files stay theirs and no system copy appears. Their lockfile then passes the same check as a panel install; if it doesn't, bios puts the user's version back and the row says so. bios never touches a user's own bins. A requirement counts only in its own scope: the panel's copy for a panel install or a project, so one only a user has is installed for the system first, and that user's own global, or the panel's, for that user's copy (*Needs …*). The Remove question counts every copy that needs it, a user's included, and the move from the old root global moves a system copy even when a user has the package. The panel's own Install, Update and Remove work on its copy as before, whatever a user has.
@@ -397,7 +397,9 @@ The choice is in `document.documentElement.dataset.transport`: `extension` or `p
 
 Programs in the kernel drive a browser over the Chrome DevTools Protocol: `playwright-cli` and `curlwright` ([slicc-cdp](https://github.com/ai-ecoverse/slicc-cdp), in the base set) or anything else that reads `SLICC_CDP_URL`. The kernel's facade on `127.0.0.1:9222` takes connections only from programs inside the kernel. `playwright-cli route`, `route-list` and `unroute` (slicc-cdp ≥ 1.10.0) fulfil or change a tab's requests through `Fetch` on that tab's session while a command runs. A pattern that names a protected host is refused, and a request to a protected origin is never routed. slicc-cdp ≥ 1.11.2 keeps the protected origins out of reach on its own side too: `tab-list` leaves protected tabs out, a command that names one with `--tab` exits 1, `open` and `goto` refuse protected URLs, and a tab it touches can't load a protected document (a script, link, meta refresh or redirect into one gets Chrome's error page). It hands each one to the `cdp` hook that `os/cdp.js` gives `createKernel`, and the hook connects it to a host:
 
-1. **[slicc-extension](https://github.com/ai-ecoverse/slicc-extension):** when the extension defines `sliccExtension.cdp`, its `chrome.debugger` bridge drives the Chrome that seven runs in. Every program connection shares the page's one extension port. The hook gives each connection only the answers to its own commands and the events of the sessions it attached, and on close it detaches every session the connection attached.
+1. **[slicc-extension](https://github.com/ai-ecoverse/slicc-extension):** browser automation through the extension requires **7.10.0 or later**. When a supported extension defines `sliccExtension.cdp`, its `chrome.debugger` bridge drives the Chrome that seven runs in. Every program connection shares the page's one extension port. The hook gives each connection only the answers to its own commands and the events of the sessions it attached, and on close it detaches every session the connection attached.
+
+An older extension, or one that cannot report a supported release version, refuses browser automation with `slicc: refused: Update slicc-extension to use browser automation in seven. Reload this tab after updating.` Fetch and sign-in remain available.
 
 **Seven's own pages and the vault are out of reach.** Every connection, whether through the extension or a linked browser, goes through a guard (`guardProtected` in `os/guard.js`), so no program in the kernel can drive, read or close a protected tab. What is protected comes from [slicc-browsers](https://github.com/ai-ecoverse/slicc-browsers#protected-origins)' `protectedOrigins` (in the base set): every `sliccy.ai` host, the vault (`vault.sliccy.ai`), `blob:`, `filesystem:` and `view-source:` URLs by the URL inside them, and `devtools:`, plus seven's own origin. A blank popup or frame (`about:blank`, `about:srcdoc`) is protected when its opener is protected or unknown, or when it was protected before. Seven's own pages can show files from OPFS that the user or the agent wrote, and the vault holds the user's secrets.
 - **Hidden targets:** `Target.getTargets` and the target events leave protected targets out.
@@ -408,7 +410,7 @@ Programs in the kernel drive a browser over the Chrome DevTools Protocol: `playw
 - **Requests from protected documents:** a request whose URL, document, frame, initiator, `Referer` or `Origin` is protected never reaches the program. The guard continues its `Fetch` pause itself, drops its `Network` events, and refuses its bodies (`Network.getResponseBody`, `getRequestPostData`, `Fetch.getResponseBody` and the like). Bodies, `replayXHR` and `Fetch` replies for a request the guard hasn't seen are refused too. Extra-info events that come before their request wait up to 2 s for it, then are dropped.
 - **Flat sessions only:** `Target.attachToTarget` and `Target.setAutoAttach` need `flatten: true`. `Target.sendMessageToTarget`, `Target.attachToBrowserTarget` and `Target.exposeDevToolsProtocol` are refused, so no command can be tunnelled past the guard.
 
-- **Known limit:** extensions that refuse `Target.setAutoAttach` (including 7.6.x) leave an ordinary page with a cross-site iframe locked for paint, DOM, CSS, accessibility and input. The guard fails closed when it cannot place the child.
+- **Known limit:** extensions that refuse `Target.setAutoAttach` leave an ordinary page with a cross-site iframe locked for paint, DOM, CSS, accessibility and input. The guard fails closed when it cannot place the child.
 
 **Sign-in tabs are held for life (#754).** A sign-in popup shows its token or code in its URL and on the IdP's pages, and the guard can't scrub a page's own content. So the owner tab holds every sign-in tab from the moment it opens. A held tab is never listed, attached, auto-attached or reported to a program on any origin, until it closes. Its events, `urlFragment` included, never reach the program.
 - **Seven's own sign-in:** the popup opens on `about:blank#slicc-sign-in-<nonce>`. bios asks the owner over the `slicc-held` BroadcastChannel to hold it. The owner finds that target by its marker URL on each browser host (slicc-extension), holds it, and only then is the popup sent to the IdP. The owner answers `held` once it has held the tab on every listed host, `none` when no host is listed, and `unheld` otherwise, including when a listed host can't be opened. On `unheld`, on `none` while bios sees a host, or on no answer within 6 s while a host is connected, the sign-in stops before the IdP and says so; it never goes on unheld. On `none`, the sign-in goes on, and the owner keeps it as in flight for 11 minutes (in `localStorage`, `slicc-os.sign-in-flight`, so a reload keeps it). Before any program gets a browser connection, the owner sweeps every host: it holds sign-in tabs still on `about:blank`, and while a sign-in is in flight, every page a protected page opened. So a host that connects in the middle of a sign-in never sees its tab.
@@ -420,7 +422,7 @@ Programs in the kernel drive a browser over the Chrome DevTools Protocol: `playw
 
 A tab a program creates through the guard opens in the background, behind seven, unless it passes `background: false`. A program that needs seven to keep rendering should open tabs, the default, and not `newWindow`: even unfocused, a new window can cover seven's window, and Chrome then throttles seven ([slicc-extension#105](https://github.com/ai-ecoverse/slicc-extension/issues/105)).
 
-A program picks a host by adding `runtime=extension`, or a linked browser's `<device>/<browser>`, to the query of the URL it opens (`playwright-cli --runtime extension`). With no runtime, the extension goes first, then a linked browser. The hook never derives a URL from the request: it reaches only the extension's page global and the linked browsers.
+A program picks a host by adding `runtime=extension`, or a linked browser's `<device>/<browser>`, to the query of the URL it opens (`playwright-cli --runtime extension`). With no runtime, a supported extension goes first, then a linked browser. If an installed extension is unsupported, automatic selection refuses with the update-and-reload message rather than silently using a linked browser; update the extension or name the linked browser explicitly with `--runtime <device>/<browser>`. The hook never derives a URL from the request: it reaches only the extension's page global and the linked browsers.
 
 **No consent dialog.** A connection goes straight through once the hook has found a host; seven doesn't ask first. The once-per-session confirm from #138 was removed by Lars's decision W10. The Network panel shows the host in its browser automation line (`browser` on the network port, from `browserVia`): through the extension, through a linked browser, or not available.
 

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@ai-ecoverse/slicc-bios",
-  "version": "1.51.22",
+  "version": "1.51.25",
   "description": "Slim loader that boots SLICC into OPFS and serves the UI from there",
   "type": "module",
   "license": "Apache-2.0",
@@ -49,12 +49,12 @@
     "format": "biome check --write ."
   },
   "devDependencies": {
-    "@ai-ecoverse/slicc": "1.49.33",
+    "@ai-ecoverse/slicc": "1.49.35",
     "@ai-ecoverse/slicc-browsers": "1.18.21",
-    "@ai-ecoverse/slicc-cdp": "1.42.9",
+    "@ai-ecoverse/slicc-cdp": "1.43.0",
     "@ai-ecoverse/slicc-shared-web": "2.13.7",
     "@ai-ecoverse/slicc-spectrum": "1.107.2",
-    "@ai-ecoverse/slicc-vault": "1.17.0",
+    "@ai-ecoverse/slicc-vault": "1.17.2",
     "@biomejs/biome": "2.6.2",
     "aws4fetch": "1.0.20",
     "es-module-lexer": "3.0.4",

package/src/packages/agent/package.json

@@ -3,7 +3,7 @@
   "private": true,
   "description": "SLICC's agent, which the UI installs with pnpm in the background into /opt/agent in OPFS",
   "dependencies": {
-    "@ai-ecoverse/slicc-agent": "7.8.14",
+    "@ai-ecoverse/slicc-agent": "7.8.15",
     "@ai-ecoverse/slicc-kernel": "1.170.1"
   }
 }

package/src/packages/agent/pnpm-lock.yaml

@@ -14,19 +14,19 @@ importers:
   .:
     dependencies:
       '@ai-ecoverse/slicc-agent':
-        specifier: 7.8.14
-        version: 7.8.14(@ai-ecoverse/slicc-kernel@1.170.1)(@aws-sdk/credential-provider-node@3.972.84)(@smithy/signature-v4@5.7.4)(ws@8.22.0)
+        specifier: 7.8.15
+        version: 7.8.15(@ai-ecoverse/slicc-kernel@1.170.1)(@aws-sdk/credential-provider-node@3.972.84)(@smithy/signature-v4@5.7.4)(ws@8.22.0)
       '@ai-ecoverse/slicc-kernel':
         specifier: 1.170.1
         version: 1.170.1
 
 packages:
 
-  '@ai-ecoverse/jerk-oauth@1.3.0':
-    resolution: {integrity: sha512-dbCU1KgYns8lP8IUCWbvCxQxCFSiVxuEYViu4CcnxphcrL9gltTvPdBpQOfAduU80GQTU3H4CMjGwuCo6EGNhg==}
+  '@ai-ecoverse/jerk-oauth@1.3.2':
+    resolution: {integrity: sha512-BLDMsojkewl82/05mQoEdWpGg4YT04KWVWcpb0TLTKIUcjfJ98GUi7vAE9Q2eDAFAlDlzpRXDCr1dSxqwiJazQ==}
 
-  '@ai-ecoverse/slicc-agent@7.8.14':
-    resolution: {integrity: sha512-ISVe9fLIPUNCRsGP1alJzH0/3xE9QiqNg7TFjvdRjCMCL6anoAqOKMSoUlbu4Ri/FCJEbU2/FAca9bK3CyVABA==}
+  '@ai-ecoverse/slicc-agent@7.8.15':
+    resolution: {integrity: sha512-ogLqsyasVb/b7p4FA+i4W9X1UJ82S5qm/2cyPelLWTWPMMpkU0tZppjWYxnOJyoV4uKT1aFUpLfDfTJtezB2MQ==}
     engines: {node: '>=24'}
     peerDependencies:
       '@ai-ecoverse/slicc-kernel': '>=1.110.0 <2'
@@ -47,8 +47,8 @@ packages:
     resolution: {integrity: sha512-HZ5qVnVez4B2UTP+UrHbYg6GnHJjpT09byt/HHJ8Y0IRk13q5Oj8rFFCme+R0T5h42ZlmwaNVI+n77VtSaCtuA==}
     engines: {node: '>=24'}
 
-  '@ai-ecoverse/slicc-vault@1.17.0':
-    resolution: {integrity: sha512-mG6CEviDcEnpumTxNIMR7yLF8SYW6VtrVOhABcjOgyvWLGNN/dN6YmhOezHJMNlP2kMF7MX+hSlu3LNS+wH7Ow==}
+  '@ai-ecoverse/slicc-vault@1.17.2':
+    resolution: {integrity: sha512-Zu0YooQmW/Fhieqz73vmPdzKfplPU1Ar88WIRC7/rMNTd1lut3JLywoTKgq0MI4I/G6a2n55D8r03rm5fGgv3A==}
     engines: {node: '>=24'}
 
   '@anthropic-ai/sdk@0.129.0':
@@ -353,13 +353,13 @@ packages:
 
 snapshots:
 
-  '@ai-ecoverse/jerk-oauth@1.3.0': {}
+  '@ai-ecoverse/jerk-oauth@1.3.2': {}
 
-  '@ai-ecoverse/slicc-agent@7.8.14(@ai-ecoverse/slicc-kernel@1.170.1)(@aws-sdk/credential-provider-node@3.972.84)(@smithy/signature-v4@5.7.4)(ws@8.22.0)':
+  '@ai-ecoverse/slicc-agent@7.8.15(@ai-ecoverse/slicc-kernel@1.170.1)(@aws-sdk/credential-provider-node@3.972.84)(@smithy/signature-v4@5.7.4)(ws@8.22.0)':
     dependencies:
       '@ai-ecoverse/slicc-browsers': 1.18.21
       '@ai-ecoverse/slicc-kernel': 1.170.1
-      '@ai-ecoverse/slicc-vault': 1.17.0
+      '@ai-ecoverse/slicc-vault': 1.17.2
       '@aws-sdk/middleware-websocket': 3.972.54
       '@earendil-works/chord': 1.4.0
       '@earendil-works/pi-ai': 1.4.0(@aws-sdk/credential-provider-node@3.972.84)(@smithy/signature-v4@5.7.4)(ws@8.22.0)
@@ -386,9 +386,9 @@ snapshots:
 
   '@ai-ecoverse/slicc-scrub@1.1.0': {}
 
-  '@ai-ecoverse/slicc-vault@1.17.0':
+  '@ai-ecoverse/slicc-vault@1.17.2':
     dependencies:
-      '@ai-ecoverse/jerk-oauth': 1.3.0
+      '@ai-ecoverse/jerk-oauth': 1.3.2
       '@ai-ecoverse/slicc-scrub': 1.1.0
 
   '@anthropic-ai/sdk@0.129.0':