@ai-ecoverse/slicc-bios 1.21.0 → 1.21.1

package/README.md

@@ -486,7 +486,7 @@ 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` (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 …)`.
+- **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). The tests get the same packument (#599): each test process of a candidate run imports [`packuments.mjs`](scripts/canary/packuments.mjs), which checks the seeded tarball against `pins.json`'s sha256 and integrity again (refusing a mismatch, so no test runs) and, whenever the harness fetches that package's packument from npm, adds the version with the manifest from the tarball's own `package.json`, `dist.tarball` at the seeded npm URL and `dist.integrity` the tarball's sha512. The `dist-tags` stay npm's, so the candidate never becomes `latest`, and every other request passes through unchanged. Seven's in-kernel pnpm, installing the optional catalog's `slicc` say, then resolves the candidate like a published version. 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.
 - **The canary's own scripts:** every checkout of its tools (the plan and report jobs, and the `scripts/canary` laid over the tested ref) is `job.workflow_sha`, the commit of the `canary.yml` that defines the job. Under `workflow_call` that is the called workflow's commit, not the caller's (`github.workflow_sha`), so a caller pinned to `canary.yml@<sha>` runs that commit's scripts, whatever `main` holds. The plan job prints `canary tools: PASS|FAIL` and fails unless it checked out that commit. `bios-ref` only picks the tested tree, and an empty one is that same commit.
 - **Callers pinned before the bindings (#523):** a `canary.yml` from before it checks out `main`'s scripts and passes no `CANDIDATE_BINDING`, `CANDIDATE_ARTIFACT_ID` or `CANDIDATE_ARTIFACT_DIGEST` at all, so main's plan takes its candidate by name, as `legacy`, and prints `canary plan: legacy binding, the calling canary.yml passes no candidate-binding`. Its report passes `--prefix <label>-` instead of `--bindings` and `--download`: the report then reads only the planned `<label>-canary-shard-<run>-<shard>` directories of that call's download, and refuses any other directory. The current `canary.yml` always passes `candidate-binding`, so a call through it without an id and a digest stays strict, even with an empty `candidate-binding`.

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@ai-ecoverse/slicc-bios",
-  "version": "1.21.0",
+  "version": "1.21.1",
   "description": "Slim loader that boots SLICC into OPFS and serves the UI from there",
   "type": "module",
   "license": "Apache-2.0",
@@ -42,12 +42,12 @@
     "format": "biome check --write ."
   },
   "devDependencies": {
-    "@ai-ecoverse/slicc": "1.44.6",
+    "@ai-ecoverse/slicc": "1.44.7",
     "@ai-ecoverse/slicc-browsers": "1.8.5",
     "@ai-ecoverse/slicc-node": "2.5.1",
     "@ai-ecoverse/slicc-shared-web": "1.24.2",
     "@ai-ecoverse/slicc-spectrum": "1.86.4",
-    "@ai-ecoverse/slicc-vault": "1.10.1",
+    "@ai-ecoverse/slicc-vault": "1.12.0",
     "@biomejs/biome": "2.5.15",
     "es-module-lexer": "3.0.3",
     "fake-indexeddb": "6.2.5",