@ai-ecoverse/slicc-agent 6.0.1 → 6.0.3

package/README.md

@@ -744,3 +744,26 @@ npm run lint
 `npm test` builds `dist/`, bundles a test worker that runs the agent on pi's faux provider, and runs the integration tests in Chromium through the [slicc-shared-web harness](https://github.com/ai-ecoverse/slicc-shared-web#integration-test-harness). Unit tests live in `test/unit/`, which stays out of git; the pre-commit hook requires every changed line in `src/` to be covered. No test calls a real model.
 
 Releases are cut by semantic-release on every push to `main`, and only there, in two jobs. `main` only takes merges that the merge queue tested on that same commit, so the release runs no tests. The `tag` job runs on the bench pool, so it starts within a minute of the push. It computes the version, tags the commit and creates the GitHub release, with `npmPublish: false`. A run that starts after `main` has moved on skips, and the run for the newer commit releases it. The `publish` job runs on a GitHub-hosted runner, because npm's trusted publishing and provenance accept no self-hosted runner. Each `publish` job runs `scripts/publish.mjs`, which publishes only its own run's version, from that run's commit, so the provenance names the run that built it. Publish jobs have no concurrency group, so GitHub never cancels one that is pending and no version is skipped. A job that runs after a newer version is tagged or on npm publishes with the dist-tag `backfill`, so `latest` never moves back. Re-running a failed `publish` job completes its version.
+
+### Certify in the pull request
+
+Every same-repo pull request gets one `cert-review` status from `.github/workflows/cert-review-pr.yml`. Its tools live in `tools/cert-review/` and are a port of slicc-kernel's. **Main's code decides:** each job checks out the pull request's base (`pull_request.base.sha`), or the protected branch for a merge group (`merge_group.base_ref`, never the group's speculative `base_sha`), and fetches only the trees under test. So a pull request is never reviewed by its own reviewer.
+
+- **What is behaviour, by output:**
+  - **Plan:** packs the base and the pull request merged onto it with `npm pack --dry-run --ignore-scripts`. A change touches behaviour when it changes a file either side ships (`dist`, `bin`, `packages/vfs-root` and whatever `files` lists, so a shipped prompt or agent definition counts), a build input (`src/`, `bin/`, `build.mjs`, `tsconfig*.json`, `patches/`, `package.json` and its lock, `.releaserc*`, `scripts/publish.mjs`), `release.yml` or `ci.yml`, or the reviewer itself.
+  - **Not behaviour:** anything else, such as `evals/`, `test/`, `README.md`, `AGENTS.md`, `renovate.json`, `lefthook.yml`, `scripts/check-*.mjs` and `review.yml`. It gets a green `not behaviour: <files>`.
+  - **Same dist:** a behaviour change is packed for real on both sides. If the tarballs carry the same files, entry types, modes and bytes once each side's exact version and `gitHead` are normalised (source maps without their `mappings`), and `package.json` differs only in `devDependencies`, `version` and `gitHead`, the status is `not behaviour (identical dist)` with both sha256. A change to the reviewer, `release.yml`, `ci.yml`, `.releaserc*` or `scripts/publish.mjs` always gets the full review.
+- **When it runs:** on `merge-ok`, and again on every push while the label is on. Before that a behaviour change is red with `waits for merge-ok`.
+- **The full review:**
+  - The integration suite runs on the merged tree and on main's tree, on `vars.CERT_RUNNER`, with no secrets in those steps. The agent's tests bundle `src/`, so they run on the tree the tarball was packed from.
+  - **The NEGATIVE:** the pull request's `test/` diff is applied to main's tree, and its integration tests must fail there for a fix (a test file that fails to load is never a NEGATIVE). Unit tests stay out of git and out of it.
+  - A Claude review on Bedrock reads only that evidence. It has read-only tools, and the key exists only in its step. It writes a verdict file.
+  - Code turns the result into the line. Missing evidence (a suite that didn't finish, a missing artifact, a review that left nothing) is `cert-ci: INCOMPLETE`, never certified on the model's judgement. The status reads `certified @ai-ecoverse/slicc-agent PR #<n> at <head>, build <v> sha256=<hex> (…; downstream: not run (slicc-bios#480))`, and a sticky comment carries the review.
+- **Downstream:** a bios/seven boot of the candidate isn't part of it yet. It waits for slicc-bios#480, and the line says so.
+- **The merge group:** looks up each pull request's `cert-review` on the head being merged. Every pull request needs a green one (certified, or not behaviour), or the group is red.
+- **The self-guard:** the shared `cert-self-guard` action, pinned. It holds the reviewer's own paths: `.github/workflows/cert*.yml`, `tools/cert-review/**`, `.github/actions/cert-self-guard/**`, and `.github/runner.mjs`, which picks CI's runner and is loaded from the base. A change to them is red with `reviewer change: needs coordinator review` until the agent coordinator adds `cert-review-approved` to that head. Workers never apply that label, which is a procedural rule: every agent acts as the same GitHub account. The guard refuses a bot's label, checks admin or maintain permission and binds the label to the head, so a later push removes it.
+- **Bootstrap:** the pull request that adds this workflow can't pass its own check, because its base has no tools yet.
+- **Releases:** after `publish`, `release / verify on npm` (light runner, no secrets) re-hashes the npm tarball against its SLSA provenance and writes one line into the GitHub release's notes, between `<!-- cert-verify -->` markers.
+  - The line starts with `certified` only when every pull request it covers was certified, or not behaviour, at its merge. That's read as the newest finished `cert-review` at or before `merged_at`, so a later re-review changes nothing.
+  - Otherwise it reads `verified … (pr-certified: not all: …)`, as for pull requests merged before the check was required.
+  - Another sha for the same version is a supply-chain alert.

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@ai-ecoverse/slicc-agent",
-  "version": "6.0.1",
+  "version": "6.0.3",
   "description": "SLICC's agent core on pi durable: an agent worker, session storage, remoting and pi extensions",
   "type": "module",
   "license": "Apache-2.0",
@@ -63,13 +63,13 @@
     "release": "semantic-release"
   },
   "devDependencies": {
-    "@ai-ecoverse/slicc-kernel": "1.110.0",
+    "@ai-ecoverse/slicc-kernel": "1.120.2",
     "@ai-ecoverse/slicc-scrub": "1.0.0",
     "@ai-ecoverse/slicc-shared-web": "1.23.1",
-    "@ai-ecoverse/slicc-spectrum": "1.84.2",
-    "@ai-ecoverse/wasm-bash": "5.3.0-18",
-    "@ai-ecoverse/wasm-coreutils": "9.12.0-8",
-    "@ai-ecoverse/wasm-git": "2.55.0-15",
+    "@ai-ecoverse/slicc-spectrum": "1.85.0",
+    "@ai-ecoverse/wasm-bash": "5.3.0-19",
+    "@ai-ecoverse/wasm-coreutils": "9.12.0-9",
+    "@ai-ecoverse/wasm-git": "2.55.0-16",
     "@biomejs/biome": "2.5.15",
     "@types/node": "24.19.2",
     "esbuild": "0.28.2",
@@ -82,7 +82,7 @@
     "typescript": "7.0.2"
   },
   "dependencies": {
-    "@ai-ecoverse/slicc-browsers": "1.7.6",
+    "@ai-ecoverse/slicc-browsers": "1.7.8",
     "@ai-ecoverse/slicc-vault": "1.9.1",
     "@aws-sdk/middleware-websocket": "^3.972.54",
     "@earendil-works/chord": "1.3.0",