@ai-ecoverse/slicc-cdp 1.30.2 → 1.30.3

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 CHANGED
@@ -396,10 +396,12 @@ Artifact-binding tools are staged before their workflow activation. `pr-artifact
396
396
 
397
397
  The `scripts/cert/pr-*` tools run in `.github/workflows/cert-review-pr.yml`, initially non-required. Every control checkout uses the main base SHA; candidate code runs only in hosted, read-only, secrets-free jobs with credentials disabled. Signing never executes input binaries. The Bedrock credential is confined to the data-only model step, which has no tools; code validates its head-bound structured verdict and execution receipt. Test-only changes and all package manifest changes, including scripts-only `postinstall` changes, take the full review. The merge-group pass-through is exact-head, ancestry-bound and code-only, consuming immutable trusted PR records and a fresh shared self-guard receipt. The always-running aggregate records missing or skipped ancestors as `INCOMPLETE`, never PASS. Release verification remains `verified` until the separately approved required-check rollout. Signed PR binaries and the collected signed assets expire after one day; digest and verification records remain for 90 days. The selected Bedrock model id is recorded in `review.json`, with the pinned default `global.anthropic.claude-opus-5-5`. Source-object fetches are credential-free for this public repository; a future trusted private-fork route would need an explicit read token, not candidate access to signing or review credentials.
398
398
 
399
- The staged `pr-bios-files.mjs --directory <dir> --out <receipt.json>` writer accepts a data-only JSON envelope on stdin: `{base:<JSON string>,candidate:<JSON string>}`. It writes the complete original bytes to fixed `bios-base.json` and `bios-candidate.json` names, never overwrites existing files or follows a linked output directory, and records byte counts and SHA256 hashes. Each result is capped at 512 KiB; encoded stdin is capped at 8 MiB. Missing or oversized data is `INCOMPLETE`, malformed data or an unsafe write is `FAIL`, and nothing is truncated. Transport `PASS` is not a bios verdict. The existing main-owned bios consumer already reads those files through `--base` and `--candidate`. Caller forwarding will replace the whole-result environment variables with JSON-string expressions in a quoted script-file heredoc passed through stdin. JavaScript action inputs such as `github-script`'s `INPUT_SCRIPT` are also environment variables and cannot safely carry these large results. The main-only, `workflow_dispatch`-only `cert-bios-file-self-test.yml` checks two complete 160 KiB outputs through the same expression/script-file/stdin route with read-only permissions and no secrets; its synthetic payload contains quotes, Unicode, shell syntax and a delimiter on data lines. This stages the file route without activating the caller or claiming artifact-ID/ZIP binding. The separately approved artifact-bound route remains later work.
399
+ The main-owned `pr-bios-files.mjs --directory <dir> --out <receipt.json>` writer accepts a data-only JSON envelope on stdin: `{base:<JSON string>,candidate:<JSON string>}`. It writes the complete original bytes to fixed `bios-base.json` and `bios-candidate.json` names, never overwrites existing files or follows a linked output directory, and records byte counts and SHA256 hashes. Each result is capped at 512 KiB; encoded stdin is capped at 8 MiB. Missing or oversized data is `INCOMPLETE`, malformed data or an unsafe write is `FAIL`, and nothing is truncated. Transport `PASS` is not a bios verdict. The existing main-owned bios consumer already reads those files through `--base` and `--candidate`. The PR caller replaces the whole-result environment variables with JSON-string expressions in a quoted script-file heredoc passed through stdin. JavaScript action inputs such as `github-script`'s `INPUT_SCRIPT` are also environment variables and cannot safely carry these large results. The main-only, `workflow_dispatch`-only `cert-bios-file-self-test.yml` checks two complete 160 KiB outputs through the same expression/script-file/stdin route with read-only permissions and no secrets; its synthetic payload contains quotes, Unicode, shell syntax and a delimiter on data lines. The file route does not activate or claim artifact-ID/ZIP binding. The separately approved artifact-bound route remains later work.
400
400
 
401
- Bios binding consumers are also staged before caller activation. `pr-bios-inputs.mjs --bindings <job-outputs.json>` selects reviewed producer `17ef7c40eb12d93d9a781626196d6052292aa94a`, checks both pack upload IDs and artifact ZIP digests against the complete run API inventory, and emits `candidate-artifact-id`, `candidate-artifact-digest` and `candidate-binding: strict` beside each independently checked npm tarball hash. The ZIP and npm hashes are different identities. `pr-bios.mjs --bindings <job-outputs.json>` accepts each labelled workflow output envelope as `{result,artifact-id,artifact-digest,artifacts}`; `artifacts` may be its raw JSON-string output or the parsed array. It requires exactly the five planned uploads per label (report, both shards and both files archives), exact names/roles/IDs/digests/attempt, distinct IDs, direct report upload outputs and the result artifact URL. It cross-checks the callee outputs against trusted caller bindings and API metadata, rejecting unexpected global inventory suffixes even when another output is missing. A conditional extra plan upload is not part of these fixed two-shard calls and is rejected. The record independently repeats these checks using its own live API inventory and caller bindings; a claimed producer `PASS` or embedded metadata inspection cannot replace them. Strict selection never falls back to the old pin or API-discovered bindings when outputs are absent. Without `--bindings`, the existing non-required bootstrap caller still explicitly uses `4025d6aabc2c06add216183064d81914a171cd64`; the `bindingCommit` configuration stages the new pin without switching that caller early. The later main-owned caller activation must pin both `canary.yml` and `bios-ref` to `17ef7c40eb12d93d9a781626196d6052292aa94a`, pass trusted producer outputs, verify actual artifact ZIP bytes before use, remove wildcard consumers and seal the final report's producer binding. These metadata consumers alone do not close those remaining rollout requirements or attest honest execution inside a producing job.
401
+ Bios binding consumers are also staged before caller activation. `pr-bios-inputs.mjs --bindings <job-outputs.json>` selects reviewed complete-row producer `c2cec127b935419049568f584093d7ef03ac0721`, checks both pack upload IDs and artifact ZIP digests against the complete run API inventory, and emits `candidate-artifact-id`, `candidate-artifact-digest` and `candidate-binding: strict` beside each independently checked npm tarball hash. The ZIP and npm hashes are different identities. `pr-bios.mjs --bindings <job-outputs.json>` accepts each labelled workflow output envelope as `{result,artifact-id,artifact-digest,artifacts}`; `artifacts` may be its raw JSON-string output or the parsed array. It requires exactly the five planned uploads per label (report, both shards and both files archives), exact names/roles/IDs/digests/attempt, distinct IDs, direct report upload outputs and the result artifact URL. It cross-checks the callee outputs against trusted caller bindings and API metadata, rejecting unexpected global inventory suffixes even when another output is missing. A conditional extra plan upload is not part of these fixed two-shard calls and is rejected. The record independently repeats these checks using its own live API inventory and caller bindings; a claimed producer `PASS` or embedded metadata inspection cannot replace them. Strict selection never falls back to the old pin or API-discovered bindings when outputs are absent. Without `--bindings`, the existing non-required bootstrap caller still explicitly uses `4025d6aabc2c06add216183064d81914a171cd64`; the `bindingCommit` configuration stages the new pin without switching that caller early. The later main-owned caller activation must pin both `canary.yml` and `bios-ref` to `c2cec127b935419049568f584093d7ef03ac0721`, pass trusted producer outputs, verify actual artifact ZIP bytes before use, remove wildcard consumers and seal the final report's producer binding. These metadata consumers alone do not close those remaining rollout requirements or attest honest execution inside a producing job.
402
402
 
403
403
  The model reviewer uses the kernel lane's pinned `claude-code-action/base-action`, but keeps the attached empty operand `--tools=` and does not request `--json-schema`: an earlier schema-flag call failed to return `structured_output` in the live bootstrap proof. Unlike the kernel's filesystem-writing reviewer, this model cannot read or write files or execute commands. Main-owned `pr-review.mjs` parses only the execution receipt's successful final result: one complete JSON object or one fenced `json` block with nothing else. It validates the exact schema and head/commit binding, hashes the execution receipt, and requires exactly one `system/init` receipt with empty `tools` and `mcp_servers` arrays. Any advertised tool or MCP server is `INCOMPLETE` with `review model had tools`; absent or malformed capability receipts are also `INCOMPLETE`. The invocation flag alone is not proof of tool isolation; malformed output, free-text keywords and missing execution are never a substitute verdict.
404
404
 
405
- Mandatory bios evidence uses `ai-ecoverse/slicc-bios/.github/workflows/canary.yml` pinned to merged commit `4025d6aabc2c06add216183064d81914a171cd64`, with `packages-update-cdp` and `guard` shards, repeat three, against both unpublished base and candidate packs. Main prepares distinct `base` and `candidate` labels and verifies both pack hashes without executing them. The consumer checks the producer's real `result` output: pinned bios ref, caller run, repeat, labelled artifact URL, exact override version/hash and artifact-source status binding, counts and completion arrays. The producer summary has no structured candidate `source` field; its exact artifact/run/hash status and override hash are checked, not an invented field or `ok` alone. Candidate regressions/failures are `FAIL`; missing calls, unfinished shards, skips, flaky results or malformed output are `INCOMPLETE`. Both-failing rows remain visible as flags rather than being mistaken for new regressions. The final record independently revalidates both result documents against its own byte-checked packs. The pin alone never makes the slot pass: the rollout workflow still needs two literal pinned canary calls and complete results. Required checks and rulesets need separate rollout approval. The shared guard's accepted residual is: self-guard catches accidental cert-path edits; not enforced against a deliberate rewrite of the workflow.
405
+ Bios comparison is between the two PR packs, not between the candidate and bios's registry pins. Both summaries must provide an untruncated `tests` array with unique stable `{key,shard,test,verdict,failed}` identities and actual completed-run ratios such as `failed.candidate: "0/3"` or `"3/3"`. The key includes the full test ancestry/variant/transport; duplicate display titles are not aligned by occurrence counters. The consumer requires the identical complete key set on both sides, recomputes all counts and validates the capped diagnostic lists against those complete rows. Only candidate-fail/base-PASS rows are introduced failures. Both-pack failures are flags, and base-fail/candidate-PASS rows are improvements. A producer `ok=false` is retained as a flag only when entirely explained by verified shared failures, or by verified base failures improved by the candidate; other rejection causes, missing/truncated/unexecuted/partial/skipped/flaky/refused evidence and mismatched row sets remain `INCOMPLETE`. Counts alone cannot invent base-PASS evidence. `pr-bios.mjs --base-report <bound-canary.json> --candidate-report <bound-canary.json>` can instead consume complete bound report rows, checking exact summary source, identities, counts, lists and result consistency. These options are data-only and do not discover or download artifacts: the caller must first obtain the report via trusted upload ID/digest and verify actual ZIP bytes. The independent record repeats the comparison from the raw retained rows rather than trusting producer PASS or flags. Missing `tests`/stable keys never falls back to the previous count-based candidate verdict, including for old-protocol callers. Caller transport and bios's new complete-row producer contract require their separate main-owned rollout; this comparator does not activate artifact binding or erase historical canary failures.
406
+
407
+ Mandatory bios evidence uses `ai-ecoverse/slicc-bios/.github/workflows/canary.yml` pinned to merged commit `4025d6aabc2c06add216183064d81914a171cd64`, with `packages-update-cdp` and `guard` shards, repeat three, against both unpublished base and candidate packs. Main prepares distinct `base` and `candidate` labels and verifies both pack hashes without executing them. The consumer checks the producer's real `result` output: pinned bios ref, caller run, repeat, labelled artifact URL, exact override version/hash and artifact-source status binding, counts and completion arrays. The producer summary has no structured candidate `source` field; its exact artifact/run/hash status and override hash are checked, not an invented field or `ok` alone. Candidate-introduced failures on base-PASS tests are `FAIL`; pre-existing both-pack failures and confirmed improvements are flags. Missing calls, unfinished shards, skips, flaky results or malformed output are `INCOMPLETE`. Both-failing rows remain visible as flags rather than being mistaken for new regressions. The final record independently revalidates both result documents against its own byte-checked packs. The pin alone never makes the slot pass: the rollout workflow still needs two literal pinned canary calls and complete results. Required checks and rulesets need separate rollout approval. The shared guard's accepted residual is: self-guard catches accidental cert-path edits; not enforced against a deliberate rewrite of the workflow.
Binary file
Binary file
package/package.json CHANGED
@@ -1,6 +1,6 @@
1
1
  {
2
2
  "name": "@ai-ecoverse/slicc-cdp",
3
- "version": "1.30.2",
3
+ "version": "1.30.3",
4
4
  "description": "SLICC's CDP layer: client, browser API, transports, HAR, and ARIA snapshot",
5
5
  "type": "module",
6
6
  "license": "Apache-2.0",