@ai-ecoverse/slicc-bios 1.31.18 → 1.32.1

package/README.md

@@ -506,7 +506,7 @@ Seven certifies a gated package (slicc-kernel, slicc-cdp, slicc-clipboard, slicc
 
 **release-state** ([`scripts/cert/release-state.mjs`](scripts/cert/release-state.mjs), code only) judges each gated pin and each `certs.json` line that a change adds, against the registry and its own repository's certification:
 - **Always:** the registry's integrity equals the lockfile's (or the line's).
-- **slicc-kernel, slicc-jsh, mcpcat, wasi-slicc (slicc-cli's):** npm provenance names the tarball and `<repo>/.github/workflows/release.yml` at `refs/heads/main`; that commit is on main and carries `cert-review` success, either a check run from app 15368 whose suite is a `merge_group` run of `.github/workflows/cert-review.yml` on that commit (cert-review v2), or, until the repo is on v2, a `cert-review` commit status from `github-actions[bot]`. A version-only release commit is judged by its parent. The kernel also passes on its npm `certified` tag. wasi-slicc counts only from 1.44.1, its first PR-certified version, and never 1.44.4, whose release run failed (slicc-cli coordinator). Residual until each of these repos is on v2 check runs: the commit-status rule trusts any same-repo workflow with `statuses: write`, so it trusts that repo's collaborators.
+- **slicc-kernel, slicc-jsh, mcpcat, wasi-slicc (slicc-cli's):** npm provenance names the tarball and `<repo>/.github/workflows/release.yml` at `refs/heads/main`; that commit is on main and carries `cert-review` success: a `cert-review` commit status from `github-actions[bot]` (what cert-review v2 writes from slicc-shared-web v1.27.1, and what these repos' own merge groups wrote before), or a v1.27.0 check run from app 15368 whose `external_id` names a `merge_group` run of `.github/workflows/cert-review.yml` (its plain path or the org-required `@refs/heads/main` one) on that commit. A version-only release commit is judged by its parent. The kernel also passes on its npm `certified` tag. wasi-slicc counts only from 1.44.1, its first PR-certified version, and never 1.44.4, whose release run failed (slicc-cli coordinator). A status whose `target_url` is a run attempt counts only if that run is a `merge_group` run of the repository's `cert-review.yml` on that commit; once a repository is listed in `V2_STATUS` (when it moves to v1.27.1), only such statuses count. Residual until then: the bare commit-status rule trusts any same-repo workflow with `statuses: write`, so it trusts that repo's collaborators; the org require-workflows ruleset and the cert-path guard are what bind it.
 - **slicc-cdp, slicc-clipboard, wasm-tailscale:** the npm `certified` dist-tag is this version.
 - **homescoop (`wasm-*`, `wasi-*`, `wasix-*`, `py-*`):** npm provenance names the tarball and homescoop's `ladder-build.yml` (or `publish.yml`) at `refs/heads/main`, any version, and homescoop's `certification-exceptions.json`, read at the commit pinned in `release-state.mjs`, neither fails the version (`verdict: fail`) nor requires a kernel bios doesn't pin (`verdict: requires`). An unreadable or unknown-shaped file fails closed.
 It runs twice: in `ci / test` for quick feedback, and as cert-review's code check, from main's tree with the pull request's head as data, so the pull request's own code can't make it pass. A failure names the package and why, and the PR stays red until it pins a certified version. An `@ai-ecoverse` lockfile entry that doesn't resolve to a registry tarball with its integrity (a `tarball:` resolution, an alias, a link) fails it.
@@ -521,7 +521,7 @@ It runs twice: in `ci / test` for quick feedback, and as cert-review's code chec
 
 ### Certification review
 
-[`.github/workflows/cert-review.yml`](.github/workflows/cert-review.yml) calls slicc-shared-web's cert-review v2 on every non-draft pull request into main and every merge group, and sets one `cert-review` check run on the head. Pull-request code runs only in CI: the `ci / cert evidence` job (`pull_request`, a read-only token, no secrets) re-runs each test file the shards failed three times on the head's tree and on main's, each with its own slicc CLI, runs each changed gated pin's scenario ([`scripts/cert/scenarios/<package>.txt`](scripts/cert/scenarios/), one command per line, with `# pass:` lines saying what output passes) in seven on both trees through `test:cert`, inspects each changed pin, and records release-state, all in the `cert-evidence` artifact ([`scripts/cert/evidence.mjs`](scripts/cert/evidence.mjs)). cert-review fetches that artifact and the shards' artifacts, from this PR's CI run and main's, by id and digest; the review reads them with Read, Glob and Grep only, against the rules in [`scripts/cert/review.txt`](scripts/cert/review.txt). A gated pin with no scenario is a known gap ("can't judge <package> in seven"). Changes to `scripts/cert/**`, `scripts/ci/**` or any workflow need the coordinator's `cert-review-approved`.
+[`.github/workflows/cert-review.yml`](.github/workflows/cert-review.yml) calls slicc-shared-web's cert-review v2 on every non-draft pull request into main and every merge group, and sets one `cert-review` commit status on the head (by `github-actions[bot]`, linked to its run attempt; slicc-shared-web v1.28.0). Pull-request code runs only in CI: the `ci / cert evidence` job (`pull_request`, a read-only token, no secrets) re-runs each test file the shards failed on the head's tree until it passes (at most three times) and, only if it failed every time, on main's, each with its own slicc CLI, within a 20-minute budget for all re-runs and scenarios (files with an open `flaky-test` issue are skipped, except those covering data integrity, security or the guard: `CLASSES` in evidence.mjs), so it never holds the CI run for hours. A file a shard failed and a re-run passed is a head flake, a finding, and a fail in those three classes. A spent budget or a missing result fails `ci / cert evidence` (`evidence.mjs check`), and `ci / test` needs that job, runs each changed gated pin's scenario ([`scripts/cert/scenarios/<package>.txt`](scripts/cert/scenarios/), one command per line, with `# pass:` lines saying what output passes) in seven on both trees through `test:cert`, all in the `cert-evidence` artifact ([`scripts/cert/evidence.mjs`](scripts/cert/evidence.mjs)). A separate `ci / cert inspect` job runs no pull-request code: from main's scripts, with the head checked out only as data, it inspects each changed pin's registry tarballs and records release-state in the `cert-inspect` artifact, which the caller marks as upstream data (`evidence-notes`), so injection-shaped text in a dependency's code is a note for the review, not a failure. cert-review fetches that artifact and the shards' artifacts, from this PR's CI run and main's, by id and digest; the review reads them with Read, Glob and Grep only, against the rules in [`scripts/cert/review.txt`](scripts/cert/review.txt). A gated pin with no scenario is a known gap ("can't judge <package> in seven"). Changes to `scripts/cert/**`, `scripts/ci/**` or any workflow need the coordinator's `cert-review-approved`.
 
 ### Canary
 
@@ -574,7 +574,7 @@ No test calls a real model. Every test serves an empty `packages/agent/` project
 
 ### CI
 
-`ci.yml` runs on pull requests, the merge queue and pushes to `main`. A `ci / plan` job ([`scripts/ci/plan.mjs`](scripts/ci/plan.mjs)) splits the integration tests into 14 shards: each `guard-set-*.test.mjs` becomes one item per detach variant of the pinned guard vectors (run with `GUARD_VARIANTS`), every other test file is one item, and the items go in a random order, seeded with the run id, to the least-loaded shard by the times in [`scripts/ci/durations.json`](scripts/ci/durations.json), the longest items first. Each shard (`ci / integration (s01)` …) runs its items with [`scripts/ci/shard.mjs`](scripts/ci/shard.mjs), one `node --test` per guard-set file with its variants (the other files join the first), counting a test the guard-set helper reports for that run's guard-set file, keeps the harness's artifacts and coverage from every run, and writes its verdict line. `ci / test`, the required check, fails without a passing verdict from every shard the plan named.
+`ci.yml` runs on pull requests, the merge queue and pushes to `main`. Its jobs run on the Cloud Run pools (`CERT_RUNNER` for the shards, `CERT_LIGHT_RUNNER` for the rest) for same-repo pull requests, the merge queue, dispatches and `main`, and on `ubuntu-latest` for forks; until 2026-10-20 the merge queue ran on `ubuntu-latest`, where its shards waited for GitHub's runners. A `ci / plan` job ([`scripts/ci/plan.mjs`](scripts/ci/plan.mjs)) splits the integration tests into 14 shards: each `guard-set-*.test.mjs` becomes one item per detach variant of the pinned guard vectors (run with `GUARD_VARIANTS`), every other test file is one item, and the items go in a random order, seeded with the run id, to the least-loaded shard by the times in [`scripts/ci/durations.json`](scripts/ci/durations.json), the longest items first. Each shard (`ci / integration (s01)` …) runs its items with [`scripts/ci/shard.mjs`](scripts/ci/shard.mjs), one `node --test` per guard-set file with its variants (the other files join the first), counting a test the guard-set helper reports for that run's guard-set file, keeps the harness's artifacts and coverage from every run, and writes its verdict line. `ci / test`, the required check, fails without a passing verdict from every shard the plan named.
 
 On a pull request, the plan first reads the files the pull request changes (`git diff HEAD^1 HEAD` on its merge commit) and picks a mode ([`scripts/ci/scope.mjs`](scripts/ci/scope.mjs)):
 
@@ -586,7 +586,7 @@ On a pull request, the plan first reads the files the pull request changes (`git
 
 [`scripts/ci/scopes.json`](scripts/ci/scopes.json) maps each package name or pattern to its rows (`full` for the harness, Playwright and the installer's tar, `vendors` for the slicc CLI). The plan prints its mode and why in the job summary, and `ci / test` passes only when the jobs that mode skips were skipped and every other job passed: `ci: PASS docs plan, 0 shards, skipped integration and vendors`. The merge queue always runs everything, so `main` is never less tested.
 
-Every shard runs the files with a failing test once more and passes when they pass (`retry`, skipped when it wouldn't fit the shard's 62 minutes). From 2026-10-17 to 2026-10-18 a two-by-two experiment compared that with control: 0 of 28 merge queue runs with retry failed, against 15 of 42 without it, so the arms without retry were retired. The pull request's number mod 2 still picks whether a failing shard also cancels the others (`fail-fast+retry` for odd numbers, `retry` for even ones and pushes to `main`), for its runs and its merge queue runs alike, to measure what fail-fast does to the time a pull request waits on CI and its time to merge. The plan, with the arm, the seed and each shard's items, is in the job summary and the `experiment-plan` artifact; each shard's record (`artifacts/experiment/<shard>.json`: its groups, the first run and any retry with their exit codes, counts and failed files) is in its `integration-<shard>` artifact, with each item's time and every test that failed and then passed on the retry. `ci / test` joins them into `summary.json` (the `experiment-summary` artifact), and for each test that flipped it files an issue labeled `flaky-test`, or comments on the open one for that test, with the run, the arm, the shard and the first run's error ([`scripts/ci/summary.mjs`](scripts/ci/summary.mjs)); this step never fails the check, and a fork's read-only token files nothing. `node scripts/ci/durations.mjs` refreshes `durations.json` with the median times of the last 40 runs' summaries.
+Every shard runs the files with a failing test once more and passes when they pass (`retry`, skipped when it wouldn't fit the shard's 62 minutes), and a shard that still fails cancels the others (`fail-fast`). Both were tested first. From 2026-10-17 to 2026-10-18 a two-by-two experiment by pull request number found that 0 of 28 merge queue runs with retry failed, against 15 of 42 without it. From 2026-10-18 to 2026-10-20 the number's parity picked fail-fast or not, with retry on both sides: over 525 runs, failing runs finished after a median of 29 minutes with fail-fast against 47 without (the first shard went red after about 26 minutes in both), passing runs took the same time (46 and 45 minutes), and the 65 pull requests merged since leaned the same way (mean CI wait 1.8 h against 2.4 h, time to merge 4.0 h against 4.9 h, not yet significant). A run's arm is now always `fail-fast+retry`. The plan, with the arm, the seed and each shard's items, is in the job summary and the `experiment-plan` artifact; each shard's record (`artifacts/experiment/<shard>.json`: its groups, the first run and any retry with their exit codes, counts and failed files) is in its `integration-<shard>` artifact, with each item's time and every test that failed and then passed on the retry. `ci / test` joins them into `summary.json` (the `experiment-summary` artifact), and for each test that flipped it files an issue labeled `flaky-test`, or comments on the open one for that test, with the run, the arm, the shard and the first run's error ([`scripts/ci/summary.mjs`](scripts/ci/summary.mjs)); this step never fails the check, and a fork's read-only token files nothing. `node scripts/ci/durations.mjs` refreshes `durations.json` with the median times of the last 40 runs' summaries.
 
 ## Hosting
 

package/package.json

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

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": "6.11.3",
+    "@ai-ecoverse/slicc-agent": "6.15.1",
     "@ai-ecoverse/slicc-kernel": "1.136.1"
   }
 }

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

@@ -14,34 +14,34 @@ importers:
   .:
     dependencies:
       '@ai-ecoverse/slicc-agent':
-        specifier: 6.11.3
-        version: 6.11.3(@ai-ecoverse/slicc-kernel@1.136.1)(@aws-sdk/credential-provider-node@3.972.84)(@smithy/signature-v4@5.7.4)(ws@8.22.0)
+        specifier: 6.15.1
+        version: 6.15.1(@ai-ecoverse/slicc-kernel@1.136.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.136.1
         version: 1.136.1
 
 packages:
 
-  '@ai-ecoverse/slicc-agent@6.11.3':
-    resolution: {integrity: sha512-10gn38tlOlvMnAq/s+YIx0k3RAg3dhH5BSVnH9PE8LZ4euOTYP8aD7ldowGkuTrultHZa/kSAFS592Nkz7+1/Q==}
+  '@ai-ecoverse/slicc-agent@6.15.1':
+    resolution: {integrity: sha512-zDoFTj4EHIzFHFwwXFn2bo1/XjTMDZTeSn9myCmj8TBb5TY94wSNqUrWu1//V5owLtF/BK8SLEBmBUE5Sf5DDw==}
     engines: {node: '>=24'}
     peerDependencies:
       '@ai-ecoverse/slicc-kernel': '>=1.110.0 <2'
-      '@ai-ecoverse/slicc-spectrum': ^1.88.0
+      '@ai-ecoverse/slicc-spectrum': ^1.98.0
     peerDependenciesMeta:
       '@ai-ecoverse/slicc-spectrum':
         optional: true
 
-  '@ai-ecoverse/slicc-browsers@1.8.5':
-    resolution: {integrity: sha512-Ec91bcUjUORvGzC1YQ9BJ+0N17T8pJMITcAkVSVFayO0cq5OP8T1kXrMC/LoXVqLcOjo8kmxEVsu/qkzylyNFw==}
+  '@ai-ecoverse/slicc-browsers@1.9.2':
+    resolution: {integrity: sha512-WVaDUiZbd5nwG03+2WoQ8YA8ATC2mkx1DRCWpLuMFBNnyN0cd5IRoGF6KYNjMkXvBQCvZZxP+gwffrpmHYJ/cQ==}
     engines: {node: '>=24'}
 
   '@ai-ecoverse/slicc-kernel@1.136.1':
     resolution: {integrity: sha512-OIrL7sWfPIM+uyUQxqpwfYKiMX+lc58kcR8gx1zYi9R0I8UTcsMCKXJsW+VrFHcCqXY/7G3YE/9LB9I0VTJtXQ==}
     engines: {node: '>=24'}
 
-  '@ai-ecoverse/slicc-vault@1.12.2':
-    resolution: {integrity: sha512-PeY1aMdV9LHZkUBZaHHN3snXxq+0mDnmbyUFt7tq1cCRW9ECQfHjy132KWeDX8vVwS+c6JAK5dInNN/NvGvBRA==}
+  '@ai-ecoverse/slicc-vault@1.14.0':
+    resolution: {integrity: sha512-/0Z5dH10zc3S+Q+AtQvAVXohfezLTdj/Tmsh/ehLCrsCo9pRQZH843Te2h+OQSgAZq7aBiq+IYFWL7NS2fK/tA==}
     engines: {node: '>=24'}
 
   '@anthropic-ai/sdk@0.129.0':
@@ -346,11 +346,11 @@ packages:
 
 snapshots:
 
-  '@ai-ecoverse/slicc-agent@6.11.3(@ai-ecoverse/slicc-kernel@1.136.1)(@aws-sdk/credential-provider-node@3.972.84)(@smithy/signature-v4@5.7.4)(ws@8.22.0)':
+  '@ai-ecoverse/slicc-agent@6.15.1(@ai-ecoverse/slicc-kernel@1.136.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.8.5
+      '@ai-ecoverse/slicc-browsers': 1.9.2
       '@ai-ecoverse/slicc-kernel': 1.136.1
-      '@ai-ecoverse/slicc-vault': 1.12.2
+      '@ai-ecoverse/slicc-vault': 1.14.0
       '@aws-sdk/middleware-websocket': 3.972.54
       '@earendil-works/chord': 1.3.0
       '@earendil-works/pi-ai': 1.3.0(@aws-sdk/credential-provider-node@3.972.84)(@smithy/signature-v4@5.7.4)(ws@8.22.0)
@@ -370,11 +370,11 @@ snapshots:
       - ws
       - zod
 
-  '@ai-ecoverse/slicc-browsers@1.8.5': {}
+  '@ai-ecoverse/slicc-browsers@1.9.2': {}
 
   '@ai-ecoverse/slicc-kernel@1.136.1': {}
 
-  '@ai-ecoverse/slicc-vault@1.12.2': {}
+  '@ai-ecoverse/slicc-vault@1.14.0': {}
 
   '@anthropic-ai/sdk@0.129.0':
     dependencies: