@ai-ecoverse/slicc-bios 1.51.24 → 1.51.26

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.

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@ai-ecoverse/slicc-bios",
-  "version": "1.51.24",
+  "version": "1.51.26",
   "description": "Slim loader that boots SLICC into OPFS and serves the UI from there",
   "type": "module",
   "license": "Apache-2.0",
@@ -49,9 +49,9 @@
     "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.10",
+    "@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.2",

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.15",
+    "@ai-ecoverse/slicc-agent": "7.9.1",
     "@ai-ecoverse/slicc-kernel": "1.170.1"
   }
 }

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

@@ -14,8 +14,8 @@ importers:
   .:
     dependencies:
       '@ai-ecoverse/slicc-agent':
-        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)
+        specifier: 7.9.1
+        version: 7.9.1(@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
@@ -25,8 +25,8 @@ packages:
   '@ai-ecoverse/jerk-oauth@1.3.2':
     resolution: {integrity: sha512-BLDMsojkewl82/05mQoEdWpGg4YT04KWVWcpb0TLTKIUcjfJ98GUi7vAE9Q2eDAFAlDlzpRXDCr1dSxqwiJazQ==}
 
-  '@ai-ecoverse/slicc-agent@7.8.15':
-    resolution: {integrity: sha512-ogLqsyasVb/b7p4FA+i4W9X1UJ82S5qm/2cyPelLWTWPMMpkU0tZppjWYxnOJyoV4uKT1aFUpLfDfTJtezB2MQ==}
+  '@ai-ecoverse/slicc-agent@7.9.1':
+    resolution: {integrity: sha512-6DG0um8vhO+B2iWq7nd588P9xkn7h9MgGdG38cSJwmKgmB2V6US0xERn4+N8mVTCCMg54s1Yy5M4Vl2DUpPg4g==}
     engines: {node: '>=24'}
     peerDependencies:
       '@ai-ecoverse/slicc-kernel': '>=1.110.0 <2'
@@ -355,7 +355,7 @@ snapshots:
 
   '@ai-ecoverse/jerk-oauth@1.3.2': {}
 
-  '@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)':
+  '@ai-ecoverse/slicc-agent@7.9.1(@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