assertledger 1.0.0

package/CONTRIBUTING.md

@@ -0,0 +1,31 @@
+# Contributing
+
+AssertLedger accepts small, reviewable changes backed by observable behavior.
+
+Use Node.js 22.15 or newer and pnpm 11.
+
+`pnpm test` and `pnpm test:coverage` build the package through their explicit pretest lifecycle
+scripts, enabled in `pnpm-workspace.yaml`. This supplies the compiled reporter even in a fresh
+checkout. `pnpm check` includes that same build and test path.
+
+1. Read `AGENTS.md`, `docs/architecture.md`, and `docs/proof-model.md`.
+2. Install the pinned toolchain with `pnpm install --frozen-lockfile`.
+3. Add a failing test for public behavior changes.
+4. Keep deterministic decision logic in `src/core`; keep I/O in `src/engine`.
+5. Run `pnpm generate:schemas` after changing any wire contract, and include all resulting files in
+   `schemas/` in the review.
+6. Run `pnpm check` and include the relevant evidence in the pull request.
+
+Test and coverage runs execute at most two test files concurrently. Many suites launch real child
+processes; bounded concurrency keeps their unchanged execution deadlines meaningful on shared hosts.
+
+Commits should follow Conventional Commits. Contract-breaking changes require a schema-version and
+migration discussion before implementation.
+
+The following surfaces are public contracts: request schemas, normalized outcomes, candidate and
+campaign statuses, gate ordering, reason codes, CLI exit codes, canonicalization, decision-digest
+scope, artifact-digest scope, adapter protocols, and MCP tool schemas. Add compatibility tests and a
+migration note before changing any of them.
+
+Do not run `trusted-local` campaigns on untrusted contributions or credential-bearing CI runners.
+The normal `pnpm check` gate does not require a user-supplied unsafe campaign.

package/LICENSE

@@ -0,0 +1,21 @@
+MIT License
+
+Copyright (c) 2026 TestForge contributors
+
+Permission is hereby granted, free of charge, to any person obtaining a copy
+of this software and associated documentation files (the "Software"), to deal
+in the Software without restriction, including without limitation the rights
+to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
+copies of the Software, and to permit persons to whom the Software is
+furnished to do so, subject to the following conditions:
+
+The above copyright notice and this permission notice shall be included in all
+copies or substantial portions of the Software.
+
+THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
+AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
+OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
+SOFTWARE.

package/README.fr.md

@@ -0,0 +1,236 @@
+# AssertLedger
+
+**Votre test de régression détecte-t-il vraiment le bug ?**
+
+AssertLedger exécute le même test sur le code corrigé, un défaut connu et un témoin neutre.
+Vous obtenez un verdict, les observations qui le justifient et un fichier de preuves à revérifier.
+
+[English](README.md) · **Français**
+
+[Essayer l’exemple](#essayer-lexemple) · [Comprendre le résultat](#comprendre-le-résultat) · [Utiliser votre dépôt](#utiliser-votre-dépôt) · [Documentation](#documentation)
+
+**1.0 · node:test · CLI, SDK et MCP · MIT**
+
+Installez l’outil dans votre dépôt avec Node.js 22.15 ou une version ultérieure :
+
+```sh
+npm install --save-dev assertledger@1.0.0
+npx assertledger doctor .
+```
+
+La [démonstration d’une correction historique](examples/git-history/README.md) fonctionne depuis
+le paquet installé. L’exemple source ci-dessous détaille les preuves étape par étape.
+
+## Un test vert peut laisser passer le bug
+
+La fonction `isEven(2)` doit renvoyer `true`. Une régression inverse accidentellement sa réponse.
+
+```js
+// Les deux tests passent avec le code correct.
+assert.equal(typeof isEven(2), "boolean"); // Passe aussi quand la réponse est fausse.
+assert.equal(isEven(2), true);             // Détecte cette régression précise.
+```
+
+AssertLedger rend cette différence visible :
+
+| Même test candidat | Code corrigé | Défaut connu | Témoin neutre | Résultat |
+| --- | --- | --- | --- | --- |
+| « Renvoie un booléen » | Réussite | Réussite | Réussite | `WEAK_ORACLE` pour ce défaut |
+| « Deux est pair » | Réussite | Échec d’assertion | Réussite | Admissible à la sélection |
+| Le test plante ou dépasse le délai | — | Erreur d’exécution | — | Ne compte pas comme détection |
+
+Vous fournissez le défaut et le témoin neutre. AssertLedger ne décide pas de leur signification.
+Des exécutions répétées et des tests de contrôle vérifient que la différence observée peut être
+attribuée au test candidat.
+
+```mermaid
+flowchart LR
+    T[Même test candidat] --> R[Code corrigé]
+    T --> B[Défaut connu]
+    T --> N[Témoin neutre]
+    R --> E[Observations enregistrées]
+    B --> E
+    N --> E
+    E --> V[Verdict déterministe]
+    V --> M[Preuves revérifiables]
+```
+
+## Essayer l’exemple
+
+Prérequis : **Git**, **Node.js 22.15+** et **pnpm 11.1.2**. Le premier adaptateur intégré utilise `node:test`.
+
+```sh
+git clone --branch v1.0.0 https://github.com/hoklims/assertledger.git
+cd assertledger
+pnpm install --frozen-lockfile
+pnpm build
+```
+
+L’exemple fourni contient une fonction de parité correcte, sa version inversée, un témoin neutre
+équivalent et les deux tests présentés plus haut. Consultez [sa requête](examples/node-test/request.json),
+puis lancez :
+
+```sh
+node dist/cli.js verify examples/node-test/request.json --allow-unsafe-execution --json
+```
+
+> **Exécutez uniquement du code de confiance.** L’option `--allow-unsafe-execution` autorise
+> l’exécution locale du code. Ce mode est explicitement **UNSANDBOXED**, sans bac à sable :
+> il ne protège pas votre machine contre du code malveillant.
+
+Décision attendue :
+
+```json
+{
+  "status": "VERIFIED",
+  "selectedCandidateIds": ["strong"],
+  "reasonCodes": ["POLICY_SATISFIED"]
+}
+```
+
+Il s’agit de la section `decision` du manifeste complet. Le candidat `weak` reçoit le motif
+`WEAK_ORACLE`. Le manifeste consigne aussi les contrôles, les tentatives, les résultats observés,
+les empreintes et les limites d’exécution.
+
+### Enregistrer et revérifier les preuves
+
+Créez un fichier `demo.mjs` à la racine du dépôt avec ce contenu. Il utilise le même exemple via
+le SDK et écrit le manifeste en UTF-8, sous Windows comme sous Linux :
+
+```js
+import { readFile, writeFile } from "node:fs/promises";
+import { AssertLedger } from "./dist/index.js";
+
+const ledger = new AssertLedger();
+const request = JSON.parse(await readFile("examples/node-test/request.json", "utf8"));
+// Examinez l’exemple de confiance avant d’autoriser explicitement son exécution.
+request.isolation.acknowledgedUnsafeExecution = true;
+const manifest = await ledger.verify(request);
+await writeFile("manifest.json", JSON.stringify(manifest, null, 2), "utf8");
+console.log(manifest.decision);
+```
+
+```sh
+node demo.mjs
+node dist/cli.js replay manifest.json --json
+```
+
+Les cinq champs de vérification doivent valoir `true` : `valid`, `schemaValid`, `decisionDigestValid`,
+`artifactDigestValid` et `decisionSemanticsValid`. Cette revérification ne nécessite aucun modèle
+d’IA et ne relance pas les tests.
+
+## Comprendre le résultat
+
+| Verdict de la campagne | Ce qu’il indique | Suite à donner |
+| --- | --- | --- |
+| `VERIFIED` | Les tests sélectionnés respectent la politique déclarée pour ces variantes et ces tentatives. | Examinez le défaut, les contrôles et les preuves avant d’accepter le test. |
+| `REJECTED` | Aucun candidat ne respecte la politique déclarée. | Consultez les motifs ; renforcez l’assertion ou corrigez les variantes déclarées. |
+| `INCONCLUSIVE` | Les observations ne permettent pas de décider de façon stable. | Examinez les exécutions instables, la découverte des tests et les erreurs d’exécution. |
+| `ENGINE_ERROR` | La campagne n’a pas produit de résultat exploitable. | Corrigez l’environnement ou la configuration, puis relancez. |
+
+Un délai dépassé, une erreur de syntaxe, un échec de collecte des tests ou un plantage de processus
+**ne compte jamais comme un bug détecté**. Un rejet concerne le défaut déclaré ; le test peut
+rester utile dans d’autres situations.
+
+La commande `replay` contrôle l’intégrité et la cohérence de la décision. Elle n’authentifie pas
+l’auteur des observations, ne prouve pas la correction générale du programme et ne garantit pas
+qu’un test restera toujours stable.
+
+## Utiliser votre dépôt
+
+Commencez par un diagnostic statique. Il lit le dépôt sans exécuter ses tests ni écrire de fichiers :
+
+```sh
+node dist/cli.js doctor path/to/your-repository
+node dist/cli.js doctor path/to/your-repository --json
+```
+
+`WOULD_CREATE` signifie qu’une configuration peut être préparée. Vous fournissez encore le test
+candidat et les contrôles. Le [guide d’initialisation](docs/repository-init.md) décrit `init`,
+la configuration et le verrou des preuves. Détecter un framework ne signifie pas savoir l’exécuter.
+
+Après l’initialisation, le [diagnostic dynamique](docs/runtime-doctor.md) vérifie Node, le reporter,
+la découverte des tests et l’attribution des assertions avec `doctor --runtime --allow-unsafe-execution`.
+Pour comprendre un refus, lancez `explain CODE` : la commande indique la prochaine action sûre.
+
+### Qualifier un test de régression commité
+
+Choisissez le commit qui contient le bug (`BEFORE`), sa correction (`AFTER`) et un témoin neutre
+(`NEUTRAL`). Le candidat provient de `AFTER` ; ses octets restent identiques dans les trois variantes.
+Remplacez les chemins, les révisions et la justification du témoin par vos propres valeurs :
+
+```sh
+node dist/cli.js check path/to/your-repository --before BEFORE --after AFTER --neutral NEUTRAL --neutral-reason "Expliquez pourquoi ce témoin préserve le comportement attendu" --test tests/regression.test.js --base-test tests/base.test.js --out .assertledger/evidence-001 --allow-unsafe-execution
+```
+
+| Prérequis de ce premier parcours Git | Pourquoi |
+| --- | --- |
+| Un candidat JavaScript `node:test` commité | Chaque variante reçoit le même test enregistré. |
+| Aucune dépendance d’exécution déclarée | Ce parcours n’installe ni ne transporte les dépendances. |
+| Un test de base inchangé dans chaque révision | Le contrôle ne doit pas varier avec la correction. |
+| Les mêmes chemins de fichiers, hormis le candidat | Les ajouts, suppressions et renommages ne sont pas encore qualifiés. |
+
+La commande enregistre `summary.md`, `executed-request.json` et `manifest.json` dans un nouveau dossier.
+Le manifeste est publié en dernier ; sa présence marque un résultat complet. La requête enregistrée
+pointe vers une copie temporaire supprimée après l’exécution ; conservez les révisions Git pour
+relancer la campagne. Le [guide du parcours Git](docs/git-regression.md) détaille les limites et
+le rôle du témoin neutre.
+
+## Utiliser AssertLedger avec un agent
+
+Un agent propose un test candidat ; le moteur déterministe évalue les observations.
+Consultez le [skill pour les agents](integrations/skill/SKILL.md), le
+[SDK TypeScript](docs/reference.md#typescript-sdk) ou la [référence MCP](docs/reference.md#mcp-v2-over-stdio).
+
+Générez une configuration Codex propre au projet avec le CLI compilé :
+
+```sh
+node dist/cli.js connect path/to/your-repository --client codex
+```
+
+Cette commande prévisualise la configuration et le skill fourni. Ajoutez `--write` pour les
+installer ; tout contenu existant différent est conservé et signalé comme un conflit.
+Le serveur MCP généré démarre en lecture seule. L’exécution de tests candidats demande une
+autorisation explicite distincte. Le [guide de prise en main](docs/developer-experience.md) précise
+les exigences de confiance du projet et de rechargement du client.
+
+Utilisez `--client claude-code` pour Claude Code ou `--client mcp` pour un descripteur générique.
+`disconnect --client codex --write` retire seulement les fichiers restés strictement identiques.
+Le [guide des clients](docs/client-connections.md) décrit l’installation et la désinstallation.
+
+## Documentation
+
+Le guide Git est en français ; les autres références techniques sont en anglais.
+
+| Vous souhaitez… | Commencez ici |
+| --- | --- |
+| Préparer un dépôt | [Initialisation](docs/repository-init.md) · [Audit statique](docs/repository-audit.md) |
+| Comprendre un blocage | [Diagnostic dynamique](docs/runtime-doctor.md) · [Explication des motifs](docs/diagnostics.md) |
+| Essayer une correction historique | [Exemple Unicode-regexp](examples/git-history/README.md) |
+| Qualifier une correction ou connecter Codex | [Parcours Git](docs/git-regression.md) · [Prise en main](docs/developer-experience.md) |
+| Comprendre l’attribution, les contrôles et les empreintes | [Modèle de preuve](docs/proof-model.md) |
+| Intégrer le CLI, le SDK ou MCP | [Référence d’intégration](docs/reference.md) |
+| Vérifier le paquet réellement distribué | [Contrôles de distribution](docs/distribution.md) · [Preuves CI](docs/ci.md) |
+| Développer un adaptateur | [Protocole des adaptateurs](docs/adapter-protocol.md) · [Architecture](docs/architecture.md) |
+| Consulter le périmètre de la version 1.0 | [Critères de release](docs/release-1.0.md) · [Feuille de route](docs/roadmap.md) |
+| Explorer les évaluations avancées | [Profils](docs/agentic-test-profile.md) · [Benchmarks](docs/agentic-benchmark.md) · [Calibration](docs/agentic-corpus-plan.md) |
+
+Les profils scientifiques et la calibration conservent leurs propres exigences de preuve.
+Leur présence n’établit ni un avantage sur un produit externe ni une adéquation au marché mesurée.
+
+## Contribuer
+
+```sh
+pnpm check
+pnpm run smoke:package
+```
+
+Ajoutez un test comportemental rouge avant de changer un contrat public. Gardez l’exécution
+dans le moteur et les décisions dans le noyau pur. Consultez [CONTRIBUTING.md](CONTRIBUTING.md)
+et [SECURITY.md](SECURITY.md).
+
+**Compatibilité :** le nom actuel est AssertLedger. Les anciens alias TestForge et les identifiants
+des contrats versionnés restent disponibles pour préserver les intégrations et la revérification
+des preuves existantes. Consultez le [guide de migration](docs/migration-testforge-to-assertledger.md).
+
+Distribué sous licence [MIT](LICENSE).

package/README.md

@@ -0,0 +1,224 @@
+# AssertLedger
+
+**Does your regression test actually catch the bug?**
+
+AssertLedger runs the same test against fixed code, a known fault and a neutral control.
+You get a verdict, the observations behind it and an evidence file you can replay.
+
+**English** · [Français](README.fr.md)
+
+[Try the example](#try-the-example) · [Understand the result](#understand-the-result) · [Use your repository](#use-your-repository) · [Documentation](#documentation)
+
+**1.0 · node:test · CLI, SDK and MCP · MIT**
+
+Install in your repository with Node.js 22.15 or later:
+
+```sh
+npm install --save-dev assertledger@1.0.0
+npx assertledger doctor .
+```
+
+The [historical correction demo](examples/git-history/README.md) runs from the installed package.
+The source example below walks through the evidence step by step.
+
+## A passing test can miss the bug
+
+Suppose `isEven(2)` should return `true`. A regression accidentally inverts the implementation.
+
+```js
+// Both tests pass on the correct implementation.
+assert.equal(typeof isEven(2), "boolean"); // Also passes when the answer is wrong.
+assert.equal(isEven(2), true);             // Detects this particular regression.
+```
+
+AssertLedger makes that distinction explicit:
+
+| Same candidate test | Fixed code | Known fault | Neutral control | Result |
+| --- | --- | --- | --- | --- |
+| “Returns a boolean” | Pass | Pass | Pass | `WEAK_ORACLE` for this fault |
+| “Two is even” | Pass | Assertion failure | Pass | Eligible for selection |
+| Test crashes or times out | — | Operational error | — | No credited detection |
+
+The operator supplies the fault and the neutral control. AssertLedger does not invent their meaning.
+Repeated runs and base tests check that the observed difference can be attributed to the candidate.
+
+```mermaid
+flowchart LR
+    T[Same candidate test] --> R[Fixed code]
+    T --> B[Known fault]
+    T --> N[Neutral control]
+    R --> E[Recorded observations]
+    B --> E
+    N --> E
+    E --> V[Deterministic verdict]
+    V --> M[Replayable evidence]
+```
+
+## Try the example
+
+You need **Git**, **Node.js 22.15+** and **pnpm 11.1.2**. The first built-in adapter is `node:test`.
+
+```sh
+git clone --branch v1.0.0 https://github.com/hoklims/assertledger.git
+cd assertledger
+pnpm install --frozen-lockfile
+pnpm build
+```
+
+The bundled example contains a correct parity function, an inverted version, a neutral equivalent,
+and the two tests above. Inspect [its request](examples/node-test/request.json), then run:
+
+```sh
+node dist/cli.js verify examples/node-test/request.json --allow-unsafe-execution --json
+```
+
+> **Run trusted code only.** `--allow-unsafe-execution` authorizes local code execution.
+> This backend is explicitly **UNSANDBOXED**. Use a trusted checkout; it cannot contain hostile code.
+
+Expected decision:
+
+```json
+{
+  "status": "VERIFIED",
+  "selectedCandidateIds": ["strong"],
+  "reasonCodes": ["POLICY_SATISFIED"]
+}
+```
+
+That is the `decision` section of the full manifest. The `weak` candidate is marked `WEAK_ORACLE`.
+The manifest also records the controls, attempts, observed outcomes, digests and execution limits.
+
+### Save and replay the evidence
+
+Create `demo.mjs` at the repository root with the following content. This writes UTF-8 consistently
+on Windows and Linux and uses the same example through the SDK:
+
+```js
+import { readFile, writeFile } from "node:fs/promises";
+import { AssertLedger } from "./dist/index.js";
+
+const ledger = new AssertLedger();
+const request = JSON.parse(await readFile("examples/node-test/request.json", "utf8"));
+// Review the trusted example before explicitly authorizing its execution.
+request.isolation.acknowledgedUnsafeExecution = true;
+const manifest = await ledger.verify(request);
+await writeFile("manifest.json", JSON.stringify(manifest, null, 2), "utf8");
+console.log(manifest.decision);
+```
+
+```sh
+node demo.mjs
+node dist/cli.js replay manifest.json --json
+```
+
+All five replay fields should be `true`: `valid`, `schemaValid`, `decisionDigestValid`,
+`artifactDigestValid` and `decisionSemanticsValid`. Replay requires no model and does not run tests again.
+
+## Understand the result
+
+| Campaign verdict | What it tells you | Next step |
+| --- | --- | --- |
+| `VERIFIED` | Selected tests meet the declared policy for these worlds and attempts. | Review the fault, controls and evidence before accepting the test. |
+| `REJECTED` | No candidate meets the declared policy. | Read candidate reasons; strengthen the assertion or correct the declared worlds. |
+| `INCONCLUSIVE` | The observations do not support a stable decision. | Inspect unstable runs, discovery and operational errors. |
+| `ENGINE_ERROR` | The campaign could not produce a usable result. | Fix the environment or configuration, then rerun. |
+
+A timeout, syntax error, collection failure or process crash **never counts as a detected bug**.
+A rejection concerns the declared fault model; the test may still have value elsewhere.
+
+Replay checks integrity and decision consistency. It does **not** authenticate whoever produced the
+observations, prove general program correctness or guarantee permanent freedom from flaky tests.
+
+## Use your repository
+
+Start with a static diagnostic. It reads the repository without running its tests or writing files:
+
+```sh
+node dist/cli.js doctor path/to/your-repository
+node dist/cli.js doctor path/to/your-repository --json
+```
+
+`WOULD_CREATE` means a configuration can be planned. You still supply the candidate and controls.
+The [initialization guide](docs/repository-init.md) explains `init`, the configuration and evidence
+lock. Detection of a framework is not proof that AssertLedger can execute it.
+
+After initialization, [runtime doctor](docs/runtime-doctor.md) can check Node, the reporter,
+discovery and assertion attribution with `doctor --runtime --allow-unsafe-execution`.
+For a refusal, use `explain CODE` to get a safe next action.
+
+### Qualify a committed regression test
+
+Choose the buggy commit (`BEFORE`), its correction (`AFTER`) and a neutral control (`NEUTRAL`).
+The candidate comes from `AFTER`; the exact same bytes run in all three worlds.
+Replace the paths, revisions and neutral reason below with your own:
+
+```sh
+node dist/cli.js check path/to/your-repository --before BEFORE --after AFTER --neutral NEUTRAL --neutral-reason "Explain why this control preserves the expected behavior" --test tests/regression.test.js --base-test tests/base.test.js --out .assertledger/evidence-001 --allow-unsafe-execution
+```
+
+| Required for this first Git workflow | Why |
+| --- | --- |
+| Committed JavaScript `node:test` candidate | Each world receives the same recorded test. |
+| No declared runtime dependencies | This workflow does not install or transport dependencies. |
+| An unchanged base test in every revision | The control must not change with the correction. |
+| The same file paths, apart from the candidate | File additions, deletions and renames are not qualified yet. |
+
+The command saves `summary.md`, `executed-request.json` and `manifest.json` in a new output directory.
+`manifest.json` is published last; its presence marks a complete result. The saved request refers to
+a temporary snapshot that has been removed; preserve the Git revisions if you need to run again.
+Read the [Git workflow guide](docs/git-regression.md) for limits and neutral-control semantics.
+
+## Use it with an agent
+
+An agent can propose a candidate; the deterministic engine evaluates the observations.
+Use the [agent skill](integrations/skill/SKILL.md), [TypeScript SDK](docs/reference.md#typescript-sdk)
+or [MCP reference](docs/reference.md#mcp-v2-over-stdio).
+
+Generate a project-scoped Codex configuration from the built CLI:
+
+```sh
+node dist/cli.js connect path/to/your-repository --client codex
+```
+
+This previews the configuration and packaged skill. Add `--write` to install both; different
+existing content is preserved and reported as a conflict. The generated MCP server starts read-only.
+Candidate execution requires a separate explicit opt-in. See [developer entry points](docs/developer-experience.md)
+for project trust and reload requirements.
+
+Use `--client claude-code` for Claude Code or `--client mcp` for a generic descriptor.
+`disconnect --client codex --write` removes only byte-identical owned files.
+The [client guide](docs/client-connections.md) covers installation and removal.
+
+## Documentation
+
+| You want to… | Start here |
+| --- | --- |
+| Set up a repository | [Initialization](docs/repository-init.md) · [Static audit](docs/repository-audit.md) |
+| Diagnose a blockage | [Runtime doctor](docs/runtime-doctor.md) · [Reason-code guidance](docs/diagnostics.md) |
+| Try a historical correction | [Unicode-regexp example](examples/git-history/README.md) |
+| Qualify a correction or connect Codex | [Git workflow](docs/git-regression.md) · [Developer entry points](docs/developer-experience.md) |
+| Understand attribution, controls and digests | [Proof model](docs/proof-model.md) |
+| Integrate the CLI, SDK or MCP | [Integration reference](docs/reference.md) |
+| Verify the actual distributed package | [Distribution checks](docs/distribution.md) · [CI evidence](docs/ci.md) |
+| Extend an adapter | [Adapter protocol](docs/adapter-protocol.md) · [Architecture](docs/architecture.md) |
+| Review the 1.0 scope | [Release criteria](docs/release-1.0.md) · [Roadmap](docs/roadmap.md) |
+| Explore advanced evaluation work | [Profiles](docs/agentic-test-profile.md) · [Benchmarks](docs/agentic-benchmark.md) · [Calibration](docs/agentic-corpus-plan.md) |
+
+Scientific profiles and calibration retain their own evidence requirements. Their presence does
+not establish an improvement on an external product or a measured product-market fit.
+
+## Contribute
+
+```sh
+pnpm check
+pnpm run smoke:package
+```
+
+Add a failing behavioral test for public contract changes. Keep execution in the engine and decision
+logic in the pure core. Read [CONTRIBUTING.md](CONTRIBUTING.md) and [SECURITY.md](SECURITY.md).
+
+**Compatibility:** AssertLedger is the current name. Legacy TestForge aliases and versioned wire
+identifiers remain available so existing integrations and evidence can be replayed.
+See the [migration guide](docs/migration-testforge-to-assertledger.md).
+
+Licensed under [MIT](LICENSE).

package/SECURITY.md

@@ -0,0 +1,51 @@
+# Security policy
+
+## Execution boundary
+
+AssertLedger executes repository code, world overlays, adapter code, and candidate tests. The
+`trusted-local` backend is explicitly `UNSANDBOXED`: temporary workspaces, a reduced environment,
+bounded output, and process timeouts reduce accidental damage, but they do not contain hostile code.
+Timeout enforcement and process-tree termination are best effort and depend on local host facilities.
+
+Do not run untrusted or adversarial candidates with `trusted-local` on a developer workstation or a
+CI runner containing secrets. Use a separately administered container or VM boundary with network
+disabled, no host sockets, no credentials, a non-root user, a read-only base image, and CPU, memory,
+PID, disk, and time limits. AssertLedger v0.1 records the achieved isolation level; it does not claim to
+provide an OS sandbox.
+
+Candidate files are restricted to configured test roots. Absolute paths, traversal segments, path
+segments ending in a dot or space, and NTFS alternate data stream syntax are rejected. Repository
+symlinks are not silently omitted: AssertLedger rejects a symlink unless an excluded path segment keeps
+it outside the inventory and snapshot. Overlay writes also reject symlink destinations discovered in
+the workspace. Commands run from executable and argument arrays with `shell: false`.
+
+Environment allowlists cannot include `NODE_OPTIONS` or names beginning with `TESTFORGE_` or
+`NODE_TEST_`, using case-insensitive comparison. AssertLedger reserves these names for runner custody.
+
+These checks protect the intended write boundary; they do not make execution safe. The source
+repository, operator-supplied worlds and policy, dependencies, runner adapter, host, and AssertLedger
+engine remain part of the trusted computing base.
+
+## Semantic boundary
+
+A `VERIFIED` decision means only that the selected candidate produced the policy-required,
+repeatable observations in the declared worlds. It is not proof of program correctness, absence of
+flakiness, absence of bugs, complete fault detection, or resistance to a candidate designed to
+recognize the worlds.
+
+Manifest digests detect modification; they do not authenticate the producer or prove that reported
+observations were truthful. Use an external signing and attestation system when provenance identity
+matters.
+
+The repository digest omits `.git`, `.testforge`, `node_modules`, and operator-excluded path segments.
+The manifest stores repository, candidate, world, executable, and process-output digests where the
+adapter supplies them; it does not embed the repository snapshot, overlay bodies, raw logs, or
+effective environment values. The built-in `node:test` adapter records its resolved executable real
+path, Node.js version, and executable SHA-256 digest. The structured-command adapter does not resolve
+or hash its executable. Preserve and attest missing materials separately when they affect an audit or
+reproduction claim.
+
+## Reporting a vulnerability
+
+Until a private security contact is published, open a GitHub security advisory on the repository.
+Do not include exploit payloads or secrets in a public issue.

package/benchmarks/agentic-profile/README.md

@@ -0,0 +1,15 @@
+# Agentic Test Profile corpus
+
+This scaffold accumulates evidence for hypotheses H1-H4. It is not an optimization loop and it
+does not alter AssertLedger's deterministic `VERIFIED` verdict.
+
+- `public/` contains reviewable `*.case.json` evidence that may be evaluated with per-case feedback.
+- `private/` is the physically separate holdout. Only aggregate H1-H4 counts may leave that split.
+
+Each case must have a canonical paired `*.provenance.json`. The evaluator also requires an
+externally pinned trust policy and expected policy digest; source IDs are never self-authenticating.
+
+The evaluator remains `NOT_READY` until it validates at least 20 cases from at least three sources,
+including non-empty public and private splits and evaluable evidence for every hypothesis.
+Unsigned legacy cases remain parseable but cannot satisfy readiness. See
+`docs/agentic-corpus-provenance.md` for the migration and non-claims.

package/benchmarks/agentic-profile/public/README.md

@@ -0,0 +1,5 @@
+# Public corpus split
+
+Place reviewable Agentic Test Profile v1 files here with the suffix `*.case.json`. Do not fabricate
+cases to satisfy readiness gates; each source revision must be immutable and independently auditable.
+Pair every case with a canonical `<basename>.provenance.json`; do not store private keys here.