@ai-ecoverse/slicc-bios 1.37.3 → 1.38.0

package/README.md

@@ -556,7 +556,7 @@ It runs twice: in `ci / test` for quick feedback, and as cert-review's code chec
 
 [`.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`.
+- **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). The same key covers what the optional catalog offers (each entry's npm `latest`, or the highest version in its `range`), so a new catalog release alone runs the catalog's shards (`packages-update-cdp`, `remote-pydata` and `rest`) against main's pins, since the catalog's tests take the version npm offers. A scheduled canary that ends red has the separate [`canary-issue.yml`](.github/workflows/canary-issue.yml) (on `workflow_run`, the only workflow here with `issues: write`, so callers of the reusable canary grant nothing more) file one open `known-issue` titled *canary: the scheduled canary is red*, or comment on it while it's open, with the verdict, the run and the catalog's offers ([`issue.mjs`](scripts/canary/issue.mjs)). homescoop's live certification-exceptions.json is the immediate fix: it denies a bad release at once. 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). 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.

package/package.json

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