assertledger 1.0.0 → 1.1.0

package/docs/container-isolation.md

@@ -0,0 +1,156 @@
+# Container isolation
+
+[Back to the reference](reference.md) · [Security policy](../SECURITY.md)
+
+Verification request v2 adds a `container` isolation backend. Every control and candidate
+execution then runs in a fresh Linux container created from a digest-pinned image that is already
+present on an operator-administered Docker-compatible daemon. `trusted-local` stays available in v1
+and v2, remains explicitly `UNSANDBOXED`, and still requires external authorization.
+
+Container isolation is a containment layer around an execution, not a proof that a campaign is
+correct. The daemon, its host kernel, the image and the AssertLedger engine remain trusted.
+
+## Select the backend
+
+The Git workflow selects the backend explicitly. Without `--container-image` or
+`--allow-unsafe-execution`, `check` stops before reading the repository and names both options:
+
+```sh
+assertledger check . --before BEFORE --after AFTER --neutral NEUTRAL --neutral-reason "explicit control reason" --test tests/regression.test.js --base-test tests/base.test.js --out .assertledger/evidence --container-image node@sha256:DIGEST
+```
+
+`verify` runs a v2 request whose `isolation.kind` is `container` without
+`--allow-unsafe-execution`:
+
+```json
+{
+  "schemaVersion": "2.0.0",
+  "isolation": {
+    "kind": "container",
+    "image": "node@sha256:DIGEST",
+    "environment": [{ "name": "TZ", "value": "UTC" }],
+    "limits": {
+      "memoryBytes": 1073741824,
+      "cpuMillicores": 2000,
+      "pids": 256,
+      "temporaryDirectoryBytes": 67108864
+    }
+  }
+}
+```
+
+The other request fields keep their v1 meaning; `assertledger schema verification-request-v2 --json`
+prints the complete contract. `check` uses the limits shown above and a 30-second timeout per
+execution.
+
+Combining a container image or request with `--allow-unsafe-execution` fails with
+`ISOLATION_MODE_CONFLICT` before any runtime call. Combining `--container-runtime` with a
+trusted-local request fails the same way.
+
+The runtime command belongs to the operator, never to the request. It defaults to `["docker"]` and
+is passed as a JSON argument array; it is never interpreted by a shell:
+
+```sh
+assertledger verify request.json --container-runtime '["docker"]' --json
+```
+
+On Windows with Docker Engine inside WSL, use
+`--container-runtime '["wsl.exe","-d","Ubuntu","--exec","docker"]'` from a POSIX shell. Shells that
+strip inner double quotes from native arguments, such as Windows PowerShell 5.1, need escaped
+quotes. The SDK takes the same values through its v2 entry points, which return v2 manifests:
+
+```js
+const ledger = new AssertLedger();
+await ledger.verifyV2(request, { containerRuntime: { command: ["docker"] } });
+await ledger.checkGitRegressionV2({ ...options, container: { image: "node@sha256:DIGEST" } });
+```
+
+`verify()` and `checkGitRegression()` keep their v1 contracts and result types.
+
+The MCP `check` and `verify` tools still execute only trusted-local v1 requests.
+
+## Backend checks before execution
+
+AssertLedger queries the runtime before creating a workspace container. Each refusal happens before
+any repository code runs and has an [`explain`](diagnostics.md) entry:
+
+| Reason code | Meaning |
+| --- | --- |
+| `CONTAINER_RUNTIME_COMMAND_INVALID` | The runtime argv is not a JSON array of 1 to 16 non-empty strings. |
+| `CONTAINER_RUNTIME_NOT_FOUND` | The runtime executable cannot be started. |
+| `CONTAINER_RUNTIME_UNAVAILABLE` | The runtime reports no reachable daemon. |
+| `CONTAINER_RUNTIME_PLATFORM_UNSUPPORTED` | The daemon does not run Linux containers. |
+| `CONTAINER_IMAGE_REFERENCE_INVALID` | The `check` image is not pinned by `@sha256:`; a v2 request with such an image fails request validation. |
+| `CONTAINER_IMAGE_NOT_PRESENT` | The pinned image is absent locally. AssertLedger never pulls. |
+| `CONTAINER_IMAGE_DIGEST_MISMATCH` | The local image does not carry the pinned digest. |
+| `CONTAINER_IMAGE_PLATFORM_UNSUPPORTED` | The image is not a Linux image. |
+| `CONTAINER_CLEANUP_FAILED` | A finished container could not be removed; no result is produced. |
+
+Review an image, then pull it yourself by the same digest, for example
+`docker pull node@sha256:DIGEST`. For `node:test`, the engine also probes `node` inside the image
+twice and records its path, version and SHA-256 digest, as it does locally.
+
+## Controls applied to every execution
+
+| Boundary | Control |
+| --- | --- |
+| Files | No host path is mounted. The prepared workspace is streamed as an archive into an anonymous volume; the root file system is read-only; `/tmp` is a `tmpfs` bounded by `temporaryDirectoryBytes`. |
+| Result | Only a regular file named `result.json`, no larger than the report bound, is read back as an archive in memory. A link, a renamed entry or a malformed archive yields `INFRA_ERROR`. |
+| Identity | User and group `65534`, all capabilities dropped, `no-new-privileges`. |
+| Network | `--network=none`: only the loopback interface exists. |
+| Environment | The image's own variables, the variables the runtime sets itself such as `HOSTNAME` and `HOME`, the declared `environment` entries and the adapter protocol variables. The host environment is never forwarded. |
+| Resources | `pids`, `memoryBytes` with swap disabled, and `cpuMillicores` limits. |
+| Time | On timeout the container is killed, which ends every process in its PID namespace, including detached descendants. |
+| Output | Standard output and error are bounded by `maximumOutputBytes`; the runtime log driver is disabled. |
+| Lifetime | One container per execution, labeled `assertledger.execution`, removed with its volume afterwards. |
+
+A timeout is recorded as `TIMEOUT`. A process stopped by the memory or process limit exits without a
+valid report and is recorded as an infrastructure or process failure. Neither can count as target
+detection: only an attributed `ASSERTION_FAILURE` kills a target.
+
+## Evidence
+
+A v2 manifest binds the backend facts to the decision digest in
+`evidenceContext.execution.backend`: image reference, identifier, OS and architecture; runtime
+client and server versions, server OS and architecture, cgroup version and reported security
+options; and the controls, declared environment and limits above. The top-level
+`isolation` summary records `kind: "container"`, `level: "CONTAINER"` and the runtime argv; it is
+covered by the artifact digest. The manifest's `limitations` state the main limits of this backend.
+
+Declared environment values are recorded verbatim. Never place a secret in `isolation.environment`.
+
+Replay validates v1 and v2 manifests. Evidence export, Agentic Test Profiles and benchmarks still
+accept only v1 manifests. The v1 request and manifest contracts are unchanged.
+
+## Limits and non-claims
+
+- Containers share the daemon host's kernel; this is not a virtual machine boundary.
+- Access to the Docker daemon is equivalent to administrative access on its host. Run it on a host
+  without secrets, as you would a CI runner.
+- AssertLedger does not bound the writable workspace volume. Storage quotas remain an
+  operator-administered daemon setting.
+- `/dev/shm` keeps the runtime default size (64 MiB on Docker Engine), charged to the memory limit.
+- The image and declared environment values are operator inputs. AssertLedger verifies the image
+  digest, not its contents. With no network, the image must already contain every runtime the
+  adapter needs.
+- An interrupted AssertLedger process can leave a labeled container. Remove it with
+  `docker ps --all --filter label=assertledger.execution` followed by `docker rm --force --volumes`.
+- Only Linux daemons are supported. The host side is platform-neutral Node.js: CI runs the backend
+  selection, diagnostic, archive and cleanup tests against a fake runtime on Linux, Windows and
+  macOS. The hostile scenario suite runs against real Docker Engine on Linux in CI and was run
+  locally against Docker Engine in WSL on Windows. GitHub-hosted Windows and macOS runners provide
+  no Linux daemon, so no real daemon is exercised from a macOS host.
+
+## Real-daemon test suite
+
+`tests/container-isolation-docker.test.ts` runs hostile scenarios against a real daemon: network
+egress, root file system writes, host paths, environment leakage, privileges, temporary storage
+and process count, a detached descendant after timeout, a result link, a memory limit, an absent
+image and an end-to-end `check`. It is skipped unless both variables below are set, and
+`ASSERTLEDGER_REQUIRE_CONTAINER_TESTS=1` turns a missing configuration into a failure:
+
+```sh
+ASSERTLEDGER_CONTAINER_RUNTIME='["docker"]' ASSERTLEDGER_CONTAINER_IMAGE='node@sha256:DIGEST' pnpm test
+```
+
+The suite never pulls; provide the image first.

package/docs/evidence-export.md

@@ -0,0 +1,146 @@
+# Interoperable evidence export
+
+AssertLedger can hand its results to an external engine, such as a change-governance tool, as
+typed evidence. The export is a thin, deterministic projection of a replay-valid
+[evidence manifest](proof-model.md). It adds no gate, no authority, and no runtime dependency on
+any consumer: AssertLedger behaves identically whether a consumer exists, accepts the evidence,
+degrades it, or ignores it.
+
+Three public contracts are involved, each with a versioned JSON Schema:
+
+| Contract | Schema | Produced by |
+| --- | --- | --- |
+| Provider manifest | [`evidence-provider-manifest.v1.json`](../schemas/evidence-provider-manifest.v1.json) | `assertledger provider`, `AssertLedger.providerManifest()`, `assertledger_provider` |
+| Export request | [`evidence-export-request.v1.json`](../schemas/evidence-export-request.v1.json) | The consumer or operator |
+| Evidence export | [`evidence-export.v1.json`](../schemas/evidence-export.v1.json) | `assertledger export`, `AssertLedger.exportEvidence()`, `assertledger_export` |
+| Export replay result | [`evidence-export-replay-result.v1.json`](../schemas/evidence-export-replay-result.v1.json) | `assertledger export-replay`, `AssertLedger.replayEvidenceExport()`, `assertledger_export_replay` |
+
+## Provider manifest: what is announced
+
+The provider manifest describes the installed provider: its version, the source revision recorded
+at build time, its scope, the formats it accepts and emits, its capabilities, its supported
+adapters, its cost model, and its limits. It carries a `manifestDigest` over its canonical
+projection.
+
+The source revision is `RECORDED` with the commit and a `CLEAN` or `DIRTY` worktree only when the
+package build captured it (`dist/build-info.json`). A source checkout or a build without Git reports
+`UNKNOWN`; the current checkout never fills in a missing value.
+
+Capabilities are announcements. `CONTROL_WITHOUT_CANDIDATE`, `REFERENCE_PASS`,
+`REGRESSION_DETECTION`, `NEUTRAL_PASS`, and `STABILITY_REPETITION` are `SUPPORTED` test-observed
+controls. `GIT_REVISION_PROVENANCE` is `SUPPORTED_WHEN_RECORDED`. `EXECUTION_FRESHNESS`,
+`PRODUCER_AUTHENTICATION`, and `SANDBOXED_EXECUTION` are `UNSUPPORTED`. A capability never proves
+that a control ran: only the recorded observations of an exported manifest do.
+
+## Export request
+
+```json
+{
+  "schemaVersion": "1.0.0",
+  "manifest": { "...": "a replay-valid evidence manifest v1" },
+  "consumerRequest": {
+    "reference": "change-42",
+    "profileId": null,
+    "obligations": [
+      { "id": "detect", "control": "REGRESSION_DETECTION" },
+      { "id": "sandbox", "control": "SANDBOXED_EXECUTION" }
+    ]
+  }
+}
+```
+
+`consumerRequest` may be `null`. Obligation identifiers must be unique. The request is not a
+policy for AssertLedger: it only lets the export state which requested controls were executed,
+not executed, or unsupported. No particular plan format is required.
+
+The export refuses a manifest that fails replay with `EVIDENCE_EXPORT_SOURCE_INVALID` (CLI exit
+code `4`, no output). A malformed request fails with `EVIDENCE_EXPORT_REQUEST_INVALID`, as does a
+request embedding a v2 manifest from [container isolation](container-isolation.md): this export
+version accepts only v1 manifests.
+
+## Evidence export: what was observed
+
+The export embeds its `sourceManifest` and is self-contained. Its sections are deliberately
+separate:
+
+- `result`: the verbatim campaign decision, a per-candidate and per-world view, and a single
+  conservative `detection` with a stable `reasonCode`.
+- `integrity`: the replay rails that were verified before export and the bound digests (artifact,
+  decision, repository, policy, and world digests).
+- `authenticity`: always `UNAUTHENTICATED` with attestation `NONE`; the producer name and version
+  are only declared by the manifest.
+- `environment`: `trusted-local`/`UNSANDBOXED` isolation, the environment allowlist names, and the
+  adapter. The framework is `RECORDED` only for a `node:test` manifest that recorded its official
+  adapter profile; otherwise it stays `UNKNOWN`.
+- `confidence`: the level `REPLAY_CONSISTENT_UNAUTHENTICATED`, with the properties that replay
+  established and those it did not (producer authenticity, observation truthfulness, execution
+  isolation, execution freshness, and the semantic relevance of the declared worlds).
+- `scope`: attempts, candidate and observation counts, and each world with its digest, declared
+  provenance, and Git revision. Git commits and trees are exported only when the provenance is the
+  exact canonical record written by [Git regression qualification](git-regression.md);
+  `gitRevisions` is `RECORDED`, `PARTIAL`, or `NOT_RECORDED`.
+- `controls`: executed controls with their observation counts, requested obligations with
+  `EXECUTED`, `NOT_EXECUTED`, or `UNSUPPORTED` coverage, and gates that did not run.
+- `profile`: `NOT_REQUESTED`, or `UNKNOWN_PROFILE` for any requested profile identifier. No usage
+  profile is defined yet, so none is ever applied or inferred.
+- `policy`: the effective AssertLedger policy version and digest.
+- `cost`: the estimated process executions derived from the recorded campaign shape, the observed
+  executions and recorded wall time with its coverage, and execution freshness `UNKNOWN` with cache
+  provenance `NOT_RECORDED`, because evidence manifest v1 does not record them.
+
+### Detection mapping
+
+The first matching row applies.
+
+| Situation | `detection` | `modality` | `reasonCode` |
+| --- | --- | --- | --- |
+| Campaign `VERIFIED` | `OBSERVED` | `TEST_OBSERVED` | `REGRESSION_ASSERTION_OBSERVED` |
+| Campaign `ENGINE_ERROR` | `NOT_ESTABLISHED` | `NONE` | `ENGINE_ERROR` |
+| Invalid controls | `NOT_ESTABLISHED` | `NONE` | `CONTROL_EVIDENCE_INVALID` |
+| An `UNSTABLE` or `INCONCLUSIVE` candidate | `NOT_ESTABLISHED` | `NONE` | `CANDIDATE_EVIDENCE_INCONCLUSIVE` |
+| An `INVALID` candidate | `NOT_ESTABLISHED` | `NONE` | `CANDIDATE_EVIDENCE_INVALID` |
+| A target outcome that is neither a stable attributed `PASS` nor a stable attributed assertion | `NOT_ESTABLISHED` | `NONE` | `OPERATIONAL_OUTCOME_NOT_DETECTION` |
+| At least one target observed passing | `NOT_OBSERVED` | `TEST_OBSERVED` | `TARGET_PASSED_WITHOUT_DETECTION` |
+| Otherwise, such as every target killed without meeting the policy | `NOT_ESTABLISHED` | `NONE` | `TARGET_STRENGTH_INSUFFICIENT` |
+
+The targeted test is the candidate: its `id` and content `digest`, the SHA-256 of the canonical JSON
+of its `[{ "path", "content" }]` overlay files. Evidence manifest v1 does not record the file paths
+themselves; a consumer holding the verification request (for example `executed-request.json`
+written by `assertledger check`) can recompute the digest to bind paths to the exported evidence.
+
+Per world, `signal` is `RED` only for complete, stable, attributed `ASSERTION_FAILURE` runs and
+`GREEN` only for complete, stable, attributed `PASS` runs. A target world's `detection` is
+`OBSERVED` or `NOT_OBSERVED` only when controls are valid and the candidate is `ELIGIBLE` or
+`WEAK_ORACLE`. Compilation, collection, crash, timeout, infrastructure, and no-test outcomes are
+never promoted to detection evidence in either direction.
+
+## Determinism and replay
+
+The same manifest and consumer request always produce the same export bytes after canonical
+serialization, independent of JSON key order; obligations are ordered by identifier. The
+`exportDigest` covers the whole export except itself.
+
+`assertledger export-replay` validates the export schema, replays the embedded source manifest,
+recomputes `exportDigest`, and rebuilds the export from the embedded manifest and consumer request.
+`valid` requires all four rails. It exits with `0` when valid and `4` otherwise. A re-digested
+forgery keeps `exportDigestValid` true but fails `semanticsValid`.
+
+## Consumer responsibilities
+
+A consumer decides admissibility with its own obligations. The
+[`consumer example`](../examples/evidence-export/consumer.mjs) rejects an export that fails replay,
+ignores exports without observed detection, and degrades observed detection to advisory when
+controls or Git revisions are missing or the evidence is unauthenticated, which is always the case
+for this version. Rejecting, degrading, or ignoring an export changes nothing in AssertLedger.
+
+## Non-claims
+
+The export does not rerun tests, authenticate the producer, attest isolation, prove that recorded
+observations were truthful, prove freshness, or make declared worlds semantically relevant. It
+covers only the recorded worlds, candidates, and attempts.
+
+## Versioning
+
+These four schemas are additive to the frozen [conformance v1](conformance-v1.md) set and are
+locked by `conformance/schema-extensions.json`. Any change to their bytes, their mapping, or their
+digest projections requires a new schema version, a migration note, and compatibility tests.

package/docs/git-regression.md

@@ -11,14 +11,18 @@ assertledger check . --before BEFORE --after AFTER --neutral NEUTRAL --neutral-r
 
 `--after` utilise `HEAD` par défaut. `--base-test` peut être répété. Le dossier donné à `--out` doit être un nouveau chemin relatif au dépôt. AssertLedger le réserve de manière exclusive, écrit `executed-request.json` et `summary.md`, puis publie `manifest.json` en dernier par renommage atomique. La présence de `manifest.json` est le marqueur de complétion ; un lecteur doit ignorer un dossier qui ne le contient pas.
 
-L’exécution `trusted-local` est volontairement **UNSANDBOXED**. Le drapeau `--allow-unsafe-execution` constitue l’autorisation distincte de l’opérateur. L’API équivalente est `new AssertLedger().checkGitRegression(options)` et exige `allowUnsafeExecution: true`.
+Le mode d’exécution est toujours choisi explicitement. Sans `--container-image` ni `--allow-unsafe-execution`, `check` refuse de s’exécuter ; les deux ensemble sont refusés avec `ISOLATION_MODE_CONFLICT`.
 
-MCP expose le même parcours avec `assertledger_check` (alias `testforge_check`) seulement si
+Pour isoler l’exécution, remplacez `--allow-unsafe-execution` par `--container-image NOM@sha256:DIGEST`. Chaque contrôle et chaque candidat s’exécute alors dans un conteneur Linux neuf, sans réseau ni montage de l’hôte, avec les limites par défaut et un délai de 30 secondes par exécution. L’image doit déjà être présente sur le démon et contenir `node` : AssertLedger ne la télécharge jamais. `--container-runtime` accepte la commande du runtime sous forme de tableau JSON, `["docker"]` par défaut. Le manifeste produit est alors en version `2.0.0`. Voir [l’isolation par conteneur](container-isolation.md).
+
+L’exécution `trusted-local` est volontairement **UNSANDBOXED**. Le drapeau `--allow-unsafe-execution` constitue l’autorisation distincte de l’opérateur. Côté SDK, `new AssertLedger().checkGitRegression(options)` exige `allowUnsafeExecution: true` et renvoie un manifeste v1 ; `checkGitRegressionV2(options)` exige `container: { image }` et renvoie un manifeste v2.
+
+MCP expose le parcours `trusted-local` avec `assertledger_check` (alias `testforge_check`) seulement si
 l’opérateur a démarré le serveur avec `--allow-unsafe-execution`. L’entrée reprend les options
 du SDK, sans le champ de permission : `repository`, `before`, `after` facultatif, `neutral`,
 `neutralReason`, `test`, `baseTests` et `out`. La racine est confinée aux dépôts autorisés ; le
 dossier de sortie suit les mêmes contrôles que la CLI. Un client ne peut pas s’accorder cette
-permission dans son message.
+permission dans son message. Le mode conteneur n’est pas encore exposé par MCP.
 
 ## Limites de cette première tranche
 

package/docs/migration-verification-v2.md

@@ -0,0 +1,55 @@
+# Verification request and evidence manifest v2
+
+Version `2.0.0` of the verification request and evidence manifest adds
+[container isolation](container-isolation.md). It is a new major contract beside v1, not a change
+to v1.
+
+## What stays the same
+
+- The 34 v1 schema bytes, the conformance-v1 lock root, v1 decision and artifact digest
+  projections, outcomes, gates and reason-code semantics are unchanged.
+- A v1 request still produces a v1 manifest, and v1 manifests replay exactly as before.
+- `parseVerificationRequest()` and `parseEvidenceManifest()` still accept only v1 and reject v2.
+- The SDK methods `verify()` and `checkGitRegression()` keep their v1 inputs, results and TypeScript
+  types; `verify()` still refuses a v2 request with `SCHEMA_VERSION_UNSUPPORTED`.
+- `trusted-local` keeps its fields, stays `UNSANDBOXED` and still requires explicit authorization.
+- MCP tool schemas, evidence export, Agentic Test Profiles and benchmarks still accept only v1.
+
+## What v2 adds
+
+- `schemas/verification-request.v2.json`: the v1 request with `schemaVersion: "2.0.0"` and an
+  `isolation` union of the unchanged `trusted-local` object and a `container` object with a
+  digest-pinned image, declared environment and limits. A request cannot name the runtime command
+  or forward host variables.
+- `schemas/evidence-manifest.v2.json`: the v1 manifest with `evidenceContext.execution.backend`,
+  which the decision digest covers, and a top-level `isolation` union whose container form records
+  the runtime argv. A v2 `trusted-local` manifest records `{ "kind": "trusted-local", "level":
+  "UNSANDBOXED" }` as its backend.
+- Both schemas join the additive schema-extension lock, whose published digest changes
+  accordingly.
+- `parseVerificationRequestV2()` and `parseEvidenceManifestV2()` accept only v2;
+  `parseVersionedVerificationRequest()` and `parseVersionedEvidenceManifest()` accept either version.
+- The SDK adds `verifyV2(request, options)` and `checkGitRegressionV2(options)`, which return
+  `EvidenceManifestV2Contract`, and the `GitRegressionV2Options` type.
+
+## Changes visible to existing callers
+
+- A request declaring `schemaVersion: "2.0.0"` previously failed with
+  `SCHEMA_VERSION_UNSUPPORTED` everywhere. The CLI `verify` command, `verifyV2()` and the exported
+  engine function `verifyCampaign()` now validate it as v2. Other unknown versions still fail with
+  that code.
+- CLI and SDK container failures use new `CONTAINER_*` and `ISOLATION_MODE_CONFLICT` reason codes,
+  with CLI exit code `4`, before any repository code runs.
+- `assertledger schema` also prints `verification-request-v2` and `evidence-manifest-v2`.
+
+## Compatibility witnesses
+
+- `tests/verification-v2.test.ts`: v2 acceptance and rejection, digest binding of the backend,
+  replay tampering, v1 parsers and export closed to v2, and published schema identities.
+- `tests/conformance-v1.test.ts` and `tests/schema-registry.test.ts`: unchanged v1 bytes and lock,
+  registered v2 schemas.
+- `tests/container-backend.test.ts` and `tests/container-facades.test.ts`: backend selection,
+  hardened runtime arguments, archive handling and CLI/SDK behavior against a fake runtime.
+- `tests/container-isolation-docker.test.ts`: hostile scenarios against a real Docker Engine.
+- `tests/engine.test.ts` and `tests/core.test.ts` now use `3.0.0` as their unsupported-version
+  witness, because `2.0.0` became a supported version.

package/docs/project-intent.md

@@ -50,8 +50,9 @@ référence, un monde neutre rouge, une observation instable ou une attribution
 
 Le socle local comprend les contrats versionnés, le noyau déterministe, les digests, le replay
 sémantique, le moteur d’exécution, les façades CLI/SDK/MCP, l’audit statique et l’initialisation.
-Le registre contient 34 schémas JSON, tous présents dans le verrou de conformance. L’ancien
-décompte de 30 dans la roadmap était périmé.
+Le registre contient 38 schémas JSON : les 34 figés par le verrou de conformance v1 et les 4
+schémas d’export d’évidence, verrouillés par une extension additive qui ne modifie pas le bundle v1.
+L’ancien décompte de 30 dans la roadmap était périmé.
 
 L’adaptateur officiel intégré est `node:test`. Le protocole `testforge-command` permet d’intégrer
 un autre framework avec un adaptateur fourni par l’opérateur. Détecter Vitest, Jest, Bun ou pytest

package/docs/proof-model.md

@@ -98,10 +98,12 @@ observations were truthful, authenticate the producer, or replace a signed exter
 
 The manifest alone is not a self-contained reproduction bundle. It stores candidate and world
 digests rather than their file bodies, stdout/stderr digests rather than raw logs, and environment
-allowlist names rather than effective values. The built-in `node:test` adapter records its resolved
-executable real path, version, and SHA-256 digest; the structured-command adapter records only its
-configured command. Preserve the original request, repository snapshot, dependencies, missing
-executable identities, and raw logs separately when independent audit matters.
+allowlist names rather than effective values. A v2 container manifest also binds the image identity,
+runtime facts, declared environment values, and limits to the decision. The built-in `node:test`
+adapter records its resolved executable real path, version, and SHA-256 digest; the
+structured-command adapter records only its configured command. Preserve the original request,
+repository snapshot, dependencies, missing executable identities, and raw logs separately when
+independent audit matters.
 
 ## Explicit non-claims
 
@@ -113,4 +115,6 @@ AssertLedger does not prove:
 - semantic relevance or correctness of operator-supplied worlds;
 - resistance to a candidate designed to recognize the worlds;
 - containment of hostile code under `trusted-local`;
+- containment beyond the recorded [container controls](container-isolation.md), which share the
+  daemon host's kernel and trust the daemon, its host, and the image;
 - provenance authenticity without a separate signed attestation.

package/docs/reference.md

@@ -18,7 +18,11 @@ assertledger audit . --json
 assertledger analyze . --json
 assertledger schema verification-request --json
 assertledger verify assertledger.request.json --allow-unsafe-execution --json
+assertledger verify assertledger.container-request.json --container-runtime '["docker"]' --json
 assertledger replay assertledger.manifest.json --json
+assertledger provider --json
+assertledger export assertledger.export-request.json --json
+assertledger export-replay assertledger.evidence-export.json --json
 assertledger profile assertledger.profile-request.json --json
 assertledger profile-replay assertledger.profile-report.json --json
 assertledger profile-v2 assertledger.profile-v2-request.json --json
@@ -45,15 +49,35 @@ directory or in a colocated `*.test.*`/`*.spec.*` source file. Comments, string
 documentation-like config filenames do not count; no evidence produces an empty list. Detection is
 intentionally incomplete: an unrecognized manifest layout or test-file convention yields no claim.
 
-`verify`, `replay`, `profile`, `profile-replay`, `profile-v2`, `profile-v2-replay`, `benchmark`, and
+`verify`, `replay`, `export`, `export-replay`, `profile`, `profile-replay`, `profile-v2`,
+`profile-v2-replay`, `benchmark`, and
 `benchmark-replay`, `benchmark-acquire`, and `benchmark-acquire-replay` also accept `-`
 or an omitted file argument and
 then read JSON from stdin. The CLI rejects file and stdin JSON inputs larger than 16 MiB. JSON
 results go to stdout. Diagnostics go to stderr. `assertledger mcp` reserves stdout for JSON-RPC.
 
 `--allow-unsafe-execution` is an external authorization signal. The CLI requires it for every
-campaign and sets the request's local acknowledgement before validation. The flag does not create a
-sandbox.
+trusted-local campaign and sets the request's local acknowledgement before validation. The flag does
+not create a sandbox.
+
+A v2 request with `container` isolation runs without that flag: each execution uses a fresh
+container from a digest-pinned local image through the operator's `--container-runtime` JSON argv,
+which defaults to `["docker"]`. `check` selects the same backend with `--container-image`. Combining
+the two modes fails with `ISOLATION_MODE_CONFLICT`. See [container isolation](container-isolation.md).
+
+`profile` exits with `0` for `QUALIFIED`, `2` for `NOT_QUALIFIED` or `BUDGET_MISSED`, and `3` for
+`INSUFFICIENT_TIMING_EVIDENCE`. A malformed request or a replay-invalid source manifest writes no
+report, prints its reason code such as `AGENTIC_PROFILE_SOURCE_INVALID` to stderr, and exits with
+`4`. `profile-replay` exits with `0` only when every replay rail is valid and with `4` otherwise.
+`profile-v2` has no `NOT_QUALIFIED` status; it uses the same codes for the statuses it shares with
+v1 and `4` for `OBSERVED_BENCHMARK_FAILURE` and `COMPARISON_SCOPE_MISMATCH`, and
+`profile-v2-replay` follows `profile-replay`. Unexpected engine errors exit with `5`.
+
+`provider` prints the evidence provider manifest and exits with `0`. `export` exits with `0` after
+writing an [evidence export](evidence-export.md), whatever its detection result; a malformed request
+or a replay-invalid source manifest writes no export, prints `EVIDENCE_EXPORT_REQUEST_INVALID` or
+`EVIDENCE_EXPORT_SOURCE_INVALID` to stderr, and exits with `4`. `export-replay` exits with `0` only
+when every replay rail is valid and with `4` otherwise.
 
 Versioned JSON Schemas are published for the
 [`verification request`](../schemas/verification-request.v1.json),
@@ -78,8 +102,12 @@ Versioned JSON Schemas are published for the
 [`corpus trust policy`](../schemas/agentic-corpus-trust-policy.v1.json) and paired
 [`corpus provenance`](../schemas/agentic-corpus-provenance.v1.json), six corpus allocation and
 two-party [`commitment/reveal`](../schemas/agentic-corpus-allocation-commitment.v1.json) contracts,
-plus six pre-declared [`H3 experiment`](../schemas/agentic-corpus-experiment-plan.v1.json) contracts.
-The main CLI `schema` command prints the thirty-one facade schemas by name; the corpus evaluator consumes
+plus six pre-declared [`H3 experiment`](../schemas/agentic-corpus-experiment-plan.v1.json) contracts,
+and the [`evidence provider manifest`](../schemas/evidence-provider-manifest.v1.json),
+[`evidence export request`](../schemas/evidence-export-request.v1.json),
+[`evidence export`](../schemas/evidence-export.v1.json), and
+[`evidence export replay result`](../schemas/evidence-export-replay-result.v1.json).
+The main CLI `schema` command prints the thirty-six facade schemas by name; the corpus evaluator consumes
 the two trust/provenance schemas directly.
 A complete runnable verification request
 is available at
@@ -96,8 +124,8 @@ campaign wall-time proxy with an exact scoped warm-total-wall p95 cost basis. It
 artifacts and commands remain supported.
 
 The checked-in [`conformance v1 bundle`](conformance-v1.md) locks autonomous inputs, complete
-expected outputs, negative replay witnesses, all published schema bytes, and selected public
-digests. `pnpm check` validates this static oracle without regenerating it.
+expected outputs, negative replay witnesses, the v1 schema bytes, and selected public digests; an
+additive lock covers the schemas published after v1. `pnpm check` validates this static oracle without regenerating it.
 
 ## TypeScript SDK
 
@@ -128,6 +156,14 @@ const profile = assertLedger.profile({
 });
 const profileIntegrity = assertLedger.replayProfile(profile);
 
+const provider = assertLedger.providerManifest();
+const evidenceExport = assertLedger.exportEvidence({
+  schemaVersion: "1.0.0",
+  manifest,
+  consumerRequest: null,
+});
+const exportIntegrity = assertLedger.replayEvidenceExport(evidenceExport);
+
 const benchmarkRequest = JSON.parse(await readFile("assertledger.benchmark-request.json", "utf8"));
 const benchmark = assertLedger.benchmark(benchmarkRequest);
 const benchmarkIntegrity = assertLedger.replayBenchmark(benchmark);
@@ -160,6 +196,10 @@ surface, for consumers migrating from the prior name.
 The SDK accepts plain JSON-compatible values and validates them against the same contracts as the
 CLI. Unlike the CLI and MCP tool, `AssertLedger.verify()` has no separate authorization parameter: the
 caller must set `isolation.acknowledgedUnsafeExecution` to `true` after applying its own policy.
+`verify()` and `checkGitRegression()` accept only v1 inputs and return v1 manifests.
+`verifyV2(request, { containerRuntime: { command } })` and `checkGitRegressionV2(options)` run
+[container isolation](container-isolation.md) and return v2 manifests; a container request needs no
+acknowledgement, and the runtime argv never comes from the request.
 
 `AssertLedger.replay()` reports schema validity, both digest checks, and deterministic
 decision-semantic validity. Its aggregate `valid` field is true only when all four checks pass. Replay
@@ -233,7 +273,7 @@ server name reported to clients is `assertledger`. Every tool is registered twic
 `assertledger_*` name and a legacy `testforge_*` name bound to the same handler and the same tool
 configuration. The schema lookup pair has no single fixed output schema because its selected JSON
 Schema document varies; every other pair shares the same output-schema object. The default server
-exposes twenty-eight read-only tools:
+exposes thirty-four read-only tools:
 
 | Preferred tool | Legacy alias | Purpose |
 | --- | --- | --- |
@@ -247,6 +287,9 @@ exposes twenty-eight read-only tools:
 | `assertledger_profile_v2` | `testforge_profile_v2` | Derive a benchmark-backed strength and warm-cost profile |
 | `assertledger_profile_v2_replay` | `testforge_profile_v2_replay` | Replay a self-contained Profile v2 report |
 | `assertledger_schema` | `testforge_schema` | Return any of the published JSON Schemas |
+| `assertledger_provider` | `testforge_provider` | Describe the evidence provider, its announced capabilities, cost model, and limits |
+| `assertledger_export` | `testforge_export` | Export replay-valid evidence for an external consumer |
+| `assertledger_export_replay` | `testforge_export_replay` | Replay a self-contained evidence export |
 | `assertledger_replay` | `testforge_replay` | Validate and replay a manifest's schema, digests, and decision semantics |
 | `assertledger_benchmark_acquire_replay` | `testforge_benchmark_acquire_replay` | Replay acquisition source, artifact, context, digest, and status bindings |
 | `assertledger_corpus_allocate` | `testforge_corpus_allocate` | Create a deterministic calibration/holdout allocation |
@@ -280,8 +323,9 @@ evidence manifest. The operator's capability is required for both tools.
 ## Continuous integration
 
 Run `pnpm check` on every change. The included GitHub Actions workflow runs this gate on Node.js 22
-and 24 on Ubuntu and Windows. A separate matrix installs and exercises the packed artifact on both
-operating systems with Node.js 22.15.0 and 24. A CI job that executes campaigns must
+and 24 on Ubuntu, Windows and macOS. A separate matrix installs and exercises the packed artifact
+on Ubuntu and Windows with Node.js 22.15.0 and 24. On Ubuntu, the gate also runs the real-daemon
+[container isolation](container-isolation.md) suite. A CI job that executes campaigns must
 also treat `trusted-local` as `UNSANDBOXED`: use an isolated runner without secrets or host
 credentials, and pass `--allow-unsafe-execution` only from reviewed CI configuration.
 
@@ -328,7 +372,8 @@ deterministic core and protocols are framework-independent; `node:test` is the f
 framework adapter. Other frameworks integrate through the structured-command protocol described in
 [docs/adapter-protocol.md](adapter-protocol.md).
 
-Planned work is not shipped behavior. Priorities include a real sandbox backend, additional
+Planned work is not shipped behavior. Priorities include VM isolation, container evidence in
+derived reports, additional
 framework reporters with runtime attribution, signed provenance, cross-runtime conformance
 fixtures, and more built-in adapters. See [docs/roadmap.md](roadmap.md).
 

package/docs/roadmap.md

@@ -7,7 +7,9 @@ regression-test qualification workflow, acceptance criteria, and evidence bounda
 ## Implemented locally in v0.1
 
 - deterministic repository analysis;
-- thirty-four versioned public JSON Schemas, all frozen by conformance v1;
+- forty versioned public JSON Schemas: thirty-four frozen by conformance v1, and four
+  evidence-export schemas plus the v2 verification request and evidence manifest locked by the
+  additive schema-extension lock;
 - reference, target, and neutral overlay worlds;
 - one campaign snapshot and disposable execution workspaces;
 - built-in `node:test` runtime reporter and structured-command adapter;
@@ -28,11 +30,16 @@ regression-test qualification workflow, acceptance criteria, and evidence bounda
   planned-process and planned-timeout equality, content-addressed suites, per-source
   non-inferiority, and a shared frozen candidate universe;
 - a static conformance-v1 oracle locking canonicalization, decisions, replay witnesses, Profile v1,
-  Benchmark v1, and all 34 published schema bytes;
+  Benchmark v1, and all 34 v1 schema bytes, plus an additive lock for later schemas;
 - a pinned 24-case, three-source empirical corpus plan with signed admission and holdout rules,
   including eight receipt-linked TestExplora cases admitted only for curated calibration;
 - JSON CLI, TypeScript SDK, MCP v2 stdio server, and integration skill;
-- `trusted-local`, explicitly recorded as `UNSANDBOXED`.
+- an interoperable evidence export with a provider manifest, separate result, integrity,
+  authenticity, environment, confidence, control, and cost sections, and deterministic replay;
+- `trusted-local`, explicitly recorded as `UNSANDBOXED`;
+- a v2 [container isolation backend](container-isolation.md): a fresh digest-pinned Linux container
+  per execution, no network or host mounts, bounded resources, and backend facts bound to the
+  decision.
 
 ## Release 1.0 priority
 
@@ -55,7 +62,8 @@ scoped deterministic qualification workflow.
    tranche is curated calibration evidence and cannot satisfy the holdout requirement.
 2. Add faithful framework-specific phase adapters. The framework-neutral acquisition path is
    shipped, but the built-in `node:test` reporter cannot attribute all four phases.
-3. Add an isolation backend backed by an independently administered container or VM boundary.
+3. Extend container isolation to evidence export, profiles, benchmarks and MCP, and add a VM
+   boundary for threats that a shared kernel does not contain.
 4. Add framework reporters beyond `node:test` that derive discovery and attribution from runtime
    events.
 5. Publish cross-runtime conformance fixtures for canonicalization, decisions, and both digests.

package/examples/agentic-profile/profile-manifest.mjs

@@ -24,5 +24,9 @@ if (manifestPath === undefined) {
     },
   });
   process.stdout.write(`${JSON.stringify(report)}\n`);
-  process.exitCode = report.status === "QUALIFIED" ? 0 : 2;
+  // Same mapping as `assertledger profile`.
+  process.exitCode =
+    { QUALIFIED: 0, NOT_QUALIFIED: 2, BUDGET_MISSED: 2, INSUFFICIENT_TIMING_EVIDENCE: 3 }[
+      report.status
+    ] ?? 5;
 }