@ai-ecoverse/slicc-bios 1.35.0 → 1.36.0

package/README.md

@@ -538,7 +538,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` 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`.
+[`.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.29.1). [`cert-rerun.yml`](.github/workflows/cert-rerun.yml) re-runs the newest cert-review run when a pull request is marked ready or gains or loses `cert-review-approved` (an org required workflow starts only on opened, synchronize and reopened), with `actions: write` only. A pull request moved onto main needs a push (or a close and reopen), so that CI and its evidence run against main. Inspect, the evidence and release-state compare against main as GitHub merged it (the merge ref's first parent), never the event's base.sha, which goes stale when main moves. 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
 
@@ -566,7 +566,7 @@ It runs twice: in `ci / test` for quick feedback, and as cert-review's code chec
 
 ### The npm package
 
-`@ai-ecoverse/slicc-bios` on npm carries only the manifests a consumer needs to test against what seven ships: `src/packages/package.json`, `package-lock.json`, `pnpm-lock.yaml` and `certs.json`, `src/packages/agent/package.json` and `pnpm-lock.yaml`, and `src/packages/optional/package.json`, `package-lock.json` and `catalog.json`. It has no runtime code and no dependencies, and those paths stay where they are. [`.github/workflows/release.yml`](.github/workflows/release.yml) releases it from `main` only: semantic-release reads the conventional commits, tags `v<version>` and writes the GitHub release, then `npm publish --provenance` publishes the tag at HEAD through npm's trusted publishing on a GitHub-hosted runner, retrying, and skipping a version npm already has. So re-running the workflow on main publishes a tag whose publish failed. The deploy to seven (`deploy.yml`) is separate and doesn't wait for it.
+`@ai-ecoverse/slicc-bios` on npm carries only the manifests a consumer needs to test against what seven ships: `src/packages/package.json`, `package-lock.json`, `pnpm-lock.yaml` and `certs.json`, `src/packages/agent/package.json` and `pnpm-lock.yaml`, and `src/packages/optional/package.json`, `package-lock.json` and `catalog.json`. It has no runtime code and no dependencies, and those paths stay where they are. [`.github/workflows/release.yml`](.github/workflows/release.yml) releases it from `main` only: semantic-release reads the conventional commits, tags `v<version>` and writes the GitHub release, then `npm publish --provenance` publishes the tag at HEAD through npm's trusted publishing on a GitHub-hosted runner, retrying, and skipping a version npm already has. So re-running the workflow on main publishes a tag whose publish failed. The step then waits until npm serves the version, up to about 8 minutes with a growing backoff, since npm's listing can lag a publish by a minute or more ([`scripts/ci/served.mjs`](scripts/ci/served.mjs)). It passes only once npm's `dist.integrity` equals the tarball's from `npm pack --dry-run`, or, when only the gzip differs because another runner packed it, once the served tarball's tar equals the packed one byte for byte. A version npm serves with other contents fails at once, and one npm never serves fails after the wait. Every `npm view` answer, and `npm publish`'s output, is in the log. The deploy to seven (`deploy.yml`) is separate and doesn't wait for it.
 
 ## Develop
 
@@ -603,6 +603,8 @@ 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.
 
+A shard also deletes the harness's stall traces (`stall-<n>-trace.json`, often 70–110 MB each) of tests that passed in every attempt (in `artifacts/` and, after a retry, in the first attempt's copy too), and lists each one with its size under `trimmed` in its record and in the log. Screenshots, logs, coverage and every file of a test that failed, flipped or timed out in any attempt stay, as does everything from a file that crashed without reporting, and every artifact of a file in any of cert review's classes (`CLASSES` in [`scripts/cert/evidence.mjs`](scripts/cert/evidence.mjs)), or in no list yet, even when it passed. That keeps the `integration-<shard>` artifacts small enough for cert review's evidence.
+
 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.35.0",
+  "version": "1.36.0",
   "description": "Slim loader that boots SLICC into OPFS and serves the UI from there",
   "type": "module",
   "license": "Apache-2.0",