assertledger 1.0.0 → 1.1.1

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-timeout-discovery-inconclusive.md

@@ -0,0 +1,126 @@
+# Timeouts and infrastructure errors no longer fail discovery
+
+A candidate run that ends in `TIMEOUT` or `INFRA_ERROR` never reached a verdict. It can neither
+prove nor disprove that the candidate test was discovered and attributed. The core now classifies
+such a candidate as `INCONCLUSIVE` instead of `INVALID`. This resolves an ambiguity of the
+[proof model](proof-model.md), which listed the case both under `INVALID` (discovery failed) and
+under `INCONCLUSIVE` (`TIMEOUT` or `INFRA_ERROR`); the core applied the first.
+
+## What changed
+
+The engine reports every `TIMEOUT` and `INFRA_ERROR` observation with `attributed: false` and,
+normally, `candidateTestsDiscovered: 0`. The `DISCOVERY` gate requires every candidate run to report
+an attributed candidate test, so those runs made it fail, and the candidate became `INVALID` before
+the core looked at execution outcomes. A candidate that hangs on the faulty code was reported as a
+broken test, and the campaign as `REJECTED`.
+
+Once completeness and stability hold, `DISCOVERY` now distinguishes the runs that fail it:
+
+| Runs that fail discovery | Before | After |
+| --- | --- | --- |
+| None | `DISCOVERY` passed | unchanged |
+| At least one completed run (`PASS`, `ASSERTION_FAILURE`, compile, collection, crash or no-test outcome) | `INVALID`, `CANDIDATE_DISCOVERY_INVALID` | unchanged |
+| Only `TIMEOUT` or `INFRA_ERROR` runs | `INVALID`, `CANDIDATE_DISCOVERY_INVALID` | `INCONCLUSIVE`, `CANDIDATE_EXECUTION_INCONCLUSIVE` |
+
+In the last case the `DISCOVERY` gate is `FAILED` with reason `CANDIDATE_EXECUTION_INCONCLUSIVE`,
+and `REFERENCE`, `NEUTRAL` and `TARGET_STRENGTH` stay `NOT_RUN` with `PREREQUISITE_GATE_FAILED`, as
+after any failed prerequisite. The candidate kills nothing: a red reference or neutral world, or a
+target its other runs killed, is not recorded as a failed gate or a kill, whereas a timeout reported
+with an attributed candidate test, a core input the engine does not produce, still lets those gates
+run. Once its attempts are complete and agree, a completed run that disproves discovery still makes
+the candidate `INVALID`, whatever else timed out; missing attempts still make it `INCONCLUSIVE` and
+attempts that disagree `UNSTABLE` first. Inconclusive execution still takes precedence over a red
+reference or neutral world, as it already did for timeouts that passed discovery.
+
+## Observable effects
+
+For a campaign where a candidate falls in the last row:
+
+- candidate status `INVALID` becomes `INCONCLUSIVE`, with the reason codes above, whatever the
+  campaign decision, including in the candidate list of evidence exports built from the manifest
+  and in the evidence status profile v1 reports for that candidate;
+- when no other candidate is selected, the campaign decision `REJECTED` / `NO_ELIGIBLE_CANDIDATE`
+  becomes `INCONCLUSIVE` / `CANDIDATE_EVIDENCE_INCONCLUSIVE`, and the CLI exit code of `verify` and
+  `check` becomes `3` instead of `2`; in that case the evidence export reason code becomes
+  `CANDIDATE_EVIDENCE_INCONCLUSIVE` instead of `CANDIDATE_EVIDENCE_INVALID`. A campaign with a
+  selected candidate stays `VERIFIED`,
+  invalid controls keep their precedence (`CONTROL_EVIDENCE_INVALID`), and a campaign that another
+  unstable or inconclusive candidate already made `INCONCLUSIVE` keeps its decision;
+- the `decisionDigest` and `artifactDigest` values of the manifest change. The digest projections
+  do not.
+
+The core does not look at where those outcomes come from. They include a candidate that hangs on a
+target world and a structured-command adapter that dies without a report, writes a malformed report
+or reports `INFRA_ERROR` itself (each witnessed below), as well as other engine paths such as a run
+that ends without an exit code and without a valid report (for the structured-command adapter, with
+any report but `PASS`), a `node:test` run without a valid report, a contradictory report, a process
+that fails to start or a container execution failure. A candidate that makes its own run end in
+`INFRA_ERROR`, for example by forcing a zero exit code despite failing tests, is therefore
+inconclusive rather than invalid. None of them can be selected: only an `ELIGIBLE` candidate is, so
+no `VERIFIED` decision changes.
+
+## Replay of existing manifests
+
+Replay recomputes the decision from the recorded observations, and no field distinguishes the
+decision semantics before and after this change (`policyVersion` stays `1.0.0`). Therefore:
+
+- a manifest sealed before this change, with at least one candidate in the last row above, no
+  longer replays: `decisionDigestValid` and `artifactDigestValid` stay `true`,
+  `decisionSemanticsValid` and `valid` become `false`. This holds per candidate, not per decision:
+  a `VERIFIED` manifest with such a neighbouring candidate is affected too, and so are the evidence
+  exports, profiles and benchmarks built from it;
+- a manifest sealed after this change with such a candidate fails replay the same way under a
+  verifier that predates it (1.1.0 and earlier).
+
+Re-decide affected manifests from their observations with the release that includes this change,
+and replay them with a verifier of that release or a later one. Manifests without a candidate in
+the last row replay as before.
+
+## Compatibility decision
+
+`CONTRIBUTING.md` asks for a schema-version discussion before a contract-breaking change. This
+change keeps `schemaVersion` and `policyVersion` unchanged:
+
+- the previous decision contradicted the proof model's own rule that `TIMEOUT` and `INFRA_ERROR`
+  are inconclusive. Campaign requests declare `policyVersion`, and the core accepts only `1.0.0`;
+  versioning would make the core accept a second version that requests opt into, while every
+  request that does not opt in would keep the misclassification;
+- replay fails closed: an affected manifest never replays as valid under the other semantics, so no
+  verdict is silently reinterpreted, and every other manifest replays unchanged.
+
+The cost of this choice: `policyVersion` `1.0.0` no longer names a single decision function, so
+archived manifests of the affected case, including `VERIFIED` ones with an affected neighbour, stop
+replaying; and a candidate can turn its own `INVALID` status into `INCONCLUSIVE` by ending its run
+in `INFRA_ERROR`, which can turn the campaign decision from `REJECTED` into `INCONCLUSIVE` (exit
+code 3 instead of 2), never into a selection.
+
+The alternative is a `policyVersion` bump under which `1.0.0` manifests keep replaying with the old
+rule. Choosing it would replace this section and the replay section above.
+
+## What does not change
+
+No schema version, manifest field, gate order, digest projection, adapter protocol, diagnostic
+catalogue entry or unsafe-execution permission changes, and no reason code is added or removed;
+`CANDIDATE_EXECUTION_INCONCLUSIVE` can now appear on the `DISCOVERY` gate. Its explanation already
+asks to fix the timeout or infrastructure failure and rerun; the campaign explanation of
+`CANDIDATE_EVIDENCE_INCONCLUSIVE` still speaks of unstable or incomplete evidence, as it did for
+timeouts after discovery. The conformance v1 bundle and its lock are unchanged: every candidate run
+in its fixtures reports an attributed candidate test, so none reaches the new case. The self-hosted
+core campaign keeps its mutation anchors and its existing-test snapshot.
+
+## Compatibility witnesses
+
+- `tests/core-inconclusive-discovery.test.ts` fails against the previous core for `TIMEOUT` and
+  `INFRA_ERROR` runs as the engine reports them, a candidate that hangs everywhere, a hung neighbour
+  of an eligible candidate, and a red reference with a timed-out target. It also pins, to the values
+  the previous core produced for the same host-independent fixtures, the decision digests of the
+  inputs whose verdict must not change (a completed run that disproves discovery beside a `TIMEOUT`
+  or an `INFRA_ERROR`, unattributed assertion, compile, collection and crash outcomes, a completed
+  crash reported without an exit code, no test discovered, diverging timeouts, a timed-out control,
+  an attributed timeout), and shows that a manifest sealed before this change, rebuilt with both of
+  its digests, fails replay only on decision semantics. The reverse direction was observed by
+  replaying a manifest of this change with the previous core, which the repository tests cannot
+  import.
+- `tests/engine.test.ts` runs a real `node:test` candidate that hangs on the target world for every
+  attempt, and a structured-command adapter that dies without a report, writes a malformed report
+  or reports `INFRA_ERROR` on the target. All four fail against the previous core and pass now.

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

@@ -55,15 +55,33 @@ Candidate statuses are:
 
 - `ELIGIBLE`: every gate needed by policy passed;
 - `WEAK_ORACLE`: reference and neutral evidence passed, but target strength did not;
-- `INVALID`: discovery, reference, or neutral evidence failed;
+- `INVALID`: a completed run disproved discovery, or reference or neutral evidence failed;
 - `UNSTABLE`: complete attempts produced different normalized outcomes;
 - `INCONCLUSIVE`: required observations were missing or execution produced `TIMEOUT` or
   `INFRA_ERROR`.
 
+When several apply, the first gate that fails decides, and inconclusive execution takes precedence
+over later failures:
+
+1. missing observations make the candidate `INCONCLUSIVE` (`COMPLETENESS`);
+2. diverging attempts make it `UNSTABLE` (`STABILITY`);
+3. a completed run without an attributed candidate test makes it `INVALID`
+   (`CANDIDATE_DISCOVERY_INVALID`);
+4. when only `TIMEOUT` or `INFRA_ERROR` runs lack an attributed candidate test, `DISCOVERY` is
+   not established and the candidate is `INCONCLUSIVE` (`CANDIDATE_EXECUTION_INCONCLUSIVE`): such a
+   run never reached a verdict, so it can neither prove nor disprove discovery;
+5. after discovery, any `TIMEOUT` or `INFRA_ERROR` run makes the candidate `INCONCLUSIVE` before a
+   red reference or neutral world makes it `INVALID`.
+
+See [the migration note](migration-timeout-discovery-inconclusive.md) for the effect on existing
+manifests.
+
 ## Campaign statuses
 
 - `VERIFIED`: at least one eligible candidate was selected.
-- `REJECTED`: evidence was complete and conclusive, but no candidate was eligible.
+- `REJECTED`: evidence was complete and conclusive, but no candidate was eligible. Once attempts are
+  complete and agree, a completed run that disproves discovery is conclusive, even if other runs
+  timed out.
 - `INCONCLUSIVE`: controls were invalid, or at least one candidate was unstable or inconclusive.
 - `ENGINE_ERROR`: the core could not normalize the supplied evidence safely.
 
@@ -98,10 +116,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 +133,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.