@ai-ecoverse/slicc-bios 1.39.7 → 1.39.9
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/README.md +1 -1
- package/package.json +1 -1
package/README.md
CHANGED
|
@@ -541,7 +541,7 @@ Seven certifies a gated package (slicc-kernel, slicc-cdp, slicc-clipboard, slicc
|
|
|
541
541
|
**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:
|
|
542
542
|
- **Always:** the registry's integrity equals the lockfile's (or the line's).
|
|
543
543
|
- **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.
|
|
544
|
-
- **slicc-kernel from `.github/workflows/ci.yml`** (slicc-shared-web's pipeline, `PIPELINE` in `release-state.mjs`): npm provenance names the tarball and
|
|
544
|
+
- **slicc-kernel and wasi-slicc (slicc-cli's) from `.github/workflows/ci.yml`** (slicc-shared-web's pipeline, `PIPELINE` in `release-state.mjs`): npm provenance names the tarball and the repository's `.github/workflows/ci.yml` at `refs/heads/main`, that commit is on main, and it carries successful `ci / integration` and `ci / review` check runs from app 15368 whose run (by their `details_url`) is a `merge_group` run of `ci.yml` on that commit, so the release went through the merge queue. No `cert-review` status is needed. Older releases, from `release.yml`, are judged by the rule above, and wasi-slicc's version rules (from 1.44.1, never 1.44.4) apply either way.
|
|
545
545
|
- **slicc-cdp, slicc-clipboard, wasm-tailscale:** the npm `certified` dist-tag is this version.
|
|
546
546
|
- **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.
|
|
547
547
|
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.
|