@ai-ecoverse/slicc-cdp 1.30.11 → 1.30.13

package/README.md

@@ -396,13 +396,15 @@ A complete record emits `certified-candidate @ai-ecoverse/slicc-cdp@<v> sha256=<
 
 ## PR certification tooling
 
+Staged guard and integration executions retain distinct identities for the subject commit and independently checked pack, the actual product Cargo manifests/versions, the harness source commit and its byte fingerprint, and any MAIN-owned named-proof overlay. The subject reader requires only Cargo identity, so a historical subject does not need the current harness's corpus dependency or lock; the selected harness reader still requires its exact locked corpus. The sole absence case is a historical release/replay integration harness with no shared dependency or corpus lock entry and no guard-runner worker: source and staged bytes must positively establish that absence before execution, the identity explicitly retains `corpus: null`, and assigned nonguard workers still require real completed results. PR and guard harnesses never use this exception; corpus-null guard executions/reports and partial or missing declared pins remain rejected or `INCOMPLETE`, not invented empty guard PASS. Before independent reconstruction, the record job fetches the exact planned merge and baseline source objects without credentials, without changing its MAIN checkout or executing candidate code. The installed guard corpus, driver and runner are identified by exact package version, file SHA256s and the digest of the complete unique scoped row universe. Staging and the pre-execution reader verify these bytes rather than relabeling the plan or inheriting an outer checkout's git SHA. The validated staged subject SHA is supplied to the guard reporter. Synthetic PR npm versions do not substitute for product Cargo versions. The independent PR record reconstructs source/harness facts from exact git objects and downloads only the exact published corpus package with scripts disabled, checks its whole tarball against the source lock's SHA512 integrity, and recomputes corpus/driver/universe identities without executing candidate binaries. It retains expected and observed identities, checks actual report source/version and the final complete row universe, and preserves earlier attempts. Missing or unsupported metadata/rows remain `INCOMPLETE`; proven source/byte substitutions remain `FAIL`. Empty declared named-proof sets do not become invented executions. These are source/byte bindings, not an attestation of an honest producer, compiler, workspace or uploader. This identity change does not update dependency pins or activate the separate paired-catalog rollout.
+
 Cert suites record explicit guard target/slot limits, isolate the heavy corpus worker from concurrent native setup tests, and keep every first attempt and exact planned rerun. The guard test retains its declared 900-second budget; the worker permits 60 seconds for termination and records any forced kill as `INCOMPLETE`. A shared 60-minute execution budget is additionally bounded by the recorded 90-minute job start and a five-minute upload reserve. Missing, malformed or expired hosted job timing fails closed. Nested `AggregateError` causes are retained as bounded structured JSON with explicit limit markers. Every guard worker receives a new owned report path for each attempt; complete rows are embedded in the suite JSON and original diagnostic JSON bytes remain in the uploaded file, with its size and SHA256 recorded. Capturing a report is not a PASS or an attestation of honest execution in the producing workspace.
 
 `cert-guard-shards.yml` measures fixed-target shards through the PR's own read-only, secrets-free CI jobs on `vars.CERT_RUNNER`, rather than loading a shared developer Mac. Four declared target partitions cover the exact published corpus: the current 1.8.3 corpus has 11 targets and 668 rows; the partitions also name the two additional targets used by the 1.8.5 corpus. Targets absent from the selected published corpus are not declared as executed or passed. Each job keeps all assigned rows and variants with at most four targets and four slots per target, and does not retry the measurement. The rebalanced partitions separate seven, vault, vault-x and apex rather than pairing the first two with their large same-site sets. Their expected row counts are 154/160/202/152 for 1.8.3 and 154/160/204/156 for the 13-target 1.8.5 corpus; these counts are recorded beside the exact keys, never used instead of them. Their new wall times must be measured in CI rather than assumed from row counts. The data-only aggregate requires every declared shard and its exact unique row keys, not matching counts. A missing shard, unsupported execution, forced kill or absent complete report is `INCOMPLETE`; a positive failure remains FAIL. Each shard records suite time and pre-upload job wall time, plus the number of rows whose errors name `Target.createTarget`, `Target.attachToTarget` or browser-startup timeouts. That count is unknown (`null`) without a complete report; original attempts and errors remain available. The aggregate is explicitly a measurement, not a behavioural PR certificate. Selecting the candidate's exact corpus and driver, validating execution identities, declaring new-row negatives and activating the protected caller remain separately reviewed steps.
 
 Artifact-binding tools are staged before their workflow activation. `pr-artifacts.mjs --plan <plan> --bindings <job-outputs.json> --roles '["guard"]' --action download --directory <archives> --out <result>` checks the complete run inventory, exact canonical role names, IDs and SHA256 artifact digests against producer upload job outputs, then hashes the actual ZIP bytes before writing a role-named archive. It never extracts or executes candidate payloads. Download refusal exits nonzero; inspection distinguishes metadata matching from byte verification. Bindings have schema1, the exact PR plan identity and an `artifacts` array of `{role,name,id,digest}`. API listings and artifact contents cannot supply missing producer bindings. Bare uploader SHA256 and the API's `sha256:` representation are normalized explicitly, never confused with the npm tarball digest. Duplicate IDs/names, substituted metadata and unexpected extra suffix artifacts are `FAIL`; missing uploads, expired evidence or an incomplete API listing are `INCOMPLETE`, with FAIL taking precedence. `pr-record.mjs --bindings <job-outputs.json>` independently enforces the complete pre-record inventory and refuses forged extras even when other evidence is missing. Record/report scopes exclude their own not-yet-uploaded results. Existing non-required callers without this argument retain the disclosed bootstrap behaviour until a separately reviewed workflow activation provides trusted producer outputs and replaces wildcard consumers; this tools change alone does not close the rollout finding. Bios's reusable workflow must expose upload IDs/digests for its report and both shards before activation. Producer job outputs bind consumers to that producer's uploaded bytes; they do not attest the honesty of code executing in the same producer job. Deliberate same-job tampering with output files or the upload action's workspace remains a same-repository-code residual under the accidental-change threat model, not an isolation guarantee. Candidate jobs remain hosted, read-only and secrets-free; signing, model and reporting jobs do not execute candidate inputs.
 
-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.
+The `scripts/cert/pr-*` tools run in `.github/workflows/cert-review-pr.yml`, initially non-required. **Draft status decides when a PR is reviewed** (no label gate): every same-repo PR that isn't a draft is reviewed on opened, ready_for_review, reopened and every push; a draft that changes behaviour records `not reviewed: draft, mark it ready for review` (INCOMPLETE, never PASS; a draft that changes no shipped behaviour still records `not behaviour`), and a missing draft flag counts as a draft. **Mark ready = reviewed, and merges on green**; a PR held for anything stays a draft. Each PR has one concurrency group with cancel-in-progress: a new head or converted_to_draft cancels the running proof, and a record reported after the PR became a draft is INCOMPLETE (`converted to draft: not proof`). Label events other than `cert-review-approved` run in a group of their own and neither start nor cancel anything; their `cert-review` job mirrors the head's `cert-review-pr` status (green only when that is `success`) and posts nothing, so a label can't turn the job check green during or after a failed review. Renovate's pull requests aren't drafts, so they're reviewed by themselves. 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.
 
 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.
 
@@ -412,6 +414,10 @@ Bios binding consumers are also staged before caller activation. `pr-bios-inputs
 
 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.
 
-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.
+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/candidate-flaky/refused evidence and mismatched row sets remain `INCOMPLETE`. Baseline-only flakes also remain `INCOMPLETE` unless the actual-row exception below is fully validated. 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.
+
+The workflow opts in with `CERT_BIOS_ACTUAL_ROWS=1` only on the MAIN-owned classifier step; it does not pass new argv to older MAIN controls. Without this opt-in or an explicit direct `--rows` flag, the original strict classification remains unchanged, including baseline flakes staying `INCOMPLETE`. Older MAIN ignores the env opt-in and keeps its strict comparison; actual-row advisories activate only after the new consumer lands. The opt-in never accepts missing or mismatched uploaded documents. `pr-bios.mjs --rows` remains available for direct tests and downloads each declared base/candidate canary shard by its unique exact artifact name, API ID and digest in the current run/head. It bounds archive/document reads, verifies the whole uploaded ZIP SHA256, selects one canonical shard document, and binds its pack override/source to the exact side. Only MAIN tools read these bytes; this step has read-only Actions access and does not execute candidate code. The evidence retains every exact scoped row and its three actual outcomes as a bounded projection, plus the original document SHA256, ZIP identity and projection hash. Full original diagnostics remain in the linked raw shard artifacts. The independent record downloads these same exact artifacts again and checks projection/identity agreement rather than trusting the producer's flags or fractions. This binding is specific to the new actual-row input; the default BIOS pin and staged strict producer activation are unchanged.
+
+A base-only flaky row becomes an advisory only when the identical candidate `(shard,key)` has three actual executed `pass` outcomes. A `0/3` summary alone is insufficient for this exception. Missing rows/repeats, skips, timeouts, killed/unexecuted rows and candidate flakes stay `INCOMPLETE`; stable regression/shared-failure/improvement rules and integrity `FAIL` precedence remain. `biosLedger` in the producer evidence and independent record preserves repository/run/attempt/PR/head/audit/BIOS pin, scoped key, exact outcomes/rates and both uploaded artifact identities. Producer advisory/ledger fields must agree with independent recomputation. `biosLedgerObservations` deduplicates separately validated records by repository/run/attempt/scoped key and rejects conflicting duplicates; it is reporting only, not a history input to certification. `bios-ledger-first-case.json` records the original #373 E2.vault control prompt observation with its original `INCOMPLETE`, never retroactive certification. Only another independently validated base-side flagged run is a second observation; a clean, skipped, cancelled or refused run is not.
 
-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.
+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, candidate flakes, unvalidated baseline flakes 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.

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@ai-ecoverse/slicc-cdp",
-  "version": "1.30.11",
+  "version": "1.30.13",
   "description": "SLICC's CDP layer: client, browser API, transports, HAR, and ARIA snapshot",
   "type": "module",
   "license": "Apache-2.0",
@@ -69,8 +69,8 @@
   },
   "devDependencies": {
     "@ai-ecoverse/slicc-browsers": "1.8.3",
-    "@ai-ecoverse/slicc-kernel": "1.131.0",
-    "@ai-ecoverse/slicc-shared-web": "1.24.2",
+    "@ai-ecoverse/slicc-kernel": "1.133.4",
+    "@ai-ecoverse/slicc-shared-web": "1.27.0",
     "@biomejs/biome": "2.5.15",
     "lefthook": "2.2.1",
     "semantic-release": "25.0.9"