AssertLedger 2.1.0

AssertLedger 2.1.0 permet de vérifier un test Bun désigné dans son paquet, avec ses preloads, ses liens internes et des matchers explicitement déclarés de confiance.

• Requêtes et manifests v5, import de témoins v2 et snapshots limités à la fermeture des tests. Les formats v1 à v4 restent pris en charge.
• Conservation des configurations de compilation héritées, des alias package.json#imports, des runtimes JSX et des dossiers vides inclus. Une configuration invalide inutilisée ne bloque plus un test indépendant.
• Le preload AssertLedger précède les preloads du dépôt. Un matcher intégré remplacé nécessite une déclaration de confiance explicite ; une erreur de compilation, de collecte ou d'infrastructure reste un refus.
• MCP server/client 2.3.0, Biome 2.5.15, types Node 22.20.5 et tsx 4.23.15. Zod reste à 4.4.3 pour préserver les schémas publiés et les règles de validation.

Installation : npm install assertledger@2.1.0.

Guide de migration v5.

Validation : 886 tests locaux passent, les 12 jobs de CI du candidat et les 12 de main passent. Les PR #71, #31 et #32 sont fusionnées ; la PR #15 a été rejetée pour préserver la compatibilité Zod. Le paquet publié a été téléchargé et réinstallé depuis le registre public, avec identité source, égalité des fichiers et replays CLI/SDK vérifiés.

43 paires négatives/restaurées sont liées au commit testé. Audit frais PROOF_ADEQUATE ; gate ALLOW / PROOF_ADEQUATE_WITH_LIMITS. Les trois attestations d'environnement inconnues et les trois dispenses de témoin par fichier restent détaillées dans les preuves jointes.

Le tarball joint est exactement celui testé et publié. SHA256 : ff4a07a5642bd92d45d5296042f55bed158506ab3d5f913014872841c1d45f38.

Le mode trusted-local reste explicitement non isolé. Les vérifications publiées couvrent les cas exécutés et la matrice de CI ; elles ne qualifient pas tous les dépôts consommateurs. Les preuves et leurs limites sont détaillées dans les assets de cette release.

AssertLedger 2.0.3

AssertLedger 2.0.3 réduit le coût des témoins exécutés en conteneur.

• Sur le témoin Bun mesuré sous Windows avec Docker natif dans WSL, la médiane passe de 419,722 s à 130,577 s, soit 3,214× plus rapide, sur trois exécutions avant et trois après. Les six verdicts sont VERIFIED, avec des observations identiques et des replays valides.
• Les lancements du runtime passent de 217 à 40 grâce à une connexion de contrôle system dial-stdio qualifiée. Les archives sont compressées et leurs octets immuables peuvent être conservés dans une campagne, jusqu’à 32 MiB.
• ASSERTLEDGER_RUNTIME_TRACE fournit des durées par phase et conteneur. --container-transport cli|stdio permet un choix explicite.

Les tentatives, sondes, contrôles, plafonds, workspaces et volumes neufs, réseau désactivé, racine en lecture seule et vérification de l’image sont préservés. Aucun cache du contrôle préalable ni concurrence d’exécution n’est ajouté. Le gain annoncé concerne le témoin et les conditions documentés.

npm install --save-dev assertledger@2.0.3

Méthode et mesures brutes.

Le tarball joint est celui testé et publié. Les pièces jointes distinguent les preuves de l’optimisation, les métadonnées de release, les CI, le paquet et l’installation depuis le registre public. Les limites de preuve restent explicites ; les schémas et projections de digest ne changent pas.

AssertLedger 2.0.2

AssertLedger 2.0.2 rend les refus du contrôle préalable Bun actionnables.

• La sonde fautive et les résultats attendu et observé sont affichés sur stderr et dans le JSON de verify et import-witness.
• Un refus ne crée ni fichier ni dossier dans --out.
• explain BUN_TEST_PROFILE_PREFLIGHT_FAILED indique comment lire le diagnostic et rejouer le contrôle complet.

Les critères de qualification, les budgets, les schémas historiques et les projections de digest restent inchangés. Aucun cache ni regroupement d'appels Docker n'est ajouté.

npm install --save-dev assertledger@2.0.2

Le tarball joint est celui testé et publié. Les preuves jointes distinguent le correctif, les métadonnées de release, la CI, le paquet et l'installation publique. Les contrôles de refus utilisent des sondes factices ; le monorepo WSL du signalement n'est pas revendiqué comme rejoué.

AssertLedger 2.0.1

AssertLedger 2.0.1 corrige le blocage d’audit sur les templates TypeScript contenant un dièse après une substitution, notamment ${1} # et ${x} ### ${y}.

• Init, audit et le parcours des imports utilisent un itérateur commun qui gère les templates imbriqués et garantit la progression.
• Le texte des templates ne crée plus de faux identifiants ou points de décision dans l’audit.
• Une erreur de tokenisation irrécupérable produit le code JAVASCRIPT_TOKENIZATION_FAILED, avec le fichier et la position. explain fournit une explication et une action.

Le schéma de sortie d’audit reste 2.0.0. Les dépendances, contrats gelés, règles d’exclusion et projections de digest sont conservés. Aucun changement de migration supplémentaire pour les consommateurs de la 2.0.0.

Installation :

npm install --save-dev assertledger@2.0.1

Correctif : PR #65. Préparation de release : PR #66.

Source du paquet et du tag : 26f73273f3b224229cc0ee32950aed775d85235d, checkout propre. Les pièces jointes distinguent les tests locaux, la CI, les contrôles de preuve, la fusion, le tarball publié et son installation publique.

La CI du candidat et la CI après fusion ont chacune leurs 12 jobs verts. Le smoke du paquet et l’installation neuve depuis npm réussissent. Le tarball public est identique au paquet testé ; les audits des templates terminent en code 0 avec un JSON v2 valide et les mêmes signaux que les expressions équivalentes. latest pointe sur 2.0.1.

Le premier rail local reste consigné avec 785 tests réussis et 24 échecs. Un diagnostic ciblé a observé le premier probe Bun arrêté au-delà de son délai de 5 secondes, sans rapport ; l’origine de cette lenteur reste indéterminée. Aucun test ni délai n’a été assoupli. La preuve de release utilise les exécutions CI complètes sur l’arbre exact et les vérifications distinctes du paquet installé.

Le scanner reste lexical : les cas de regex du corpus prouvent la terminaison, pas une analyse grammaticale complète. Les contrôles d’erreur injectent des fautes délibérées ; ils ne prétendent pas observer une erreur naturelle du fournisseur. Les digests lient les octets et ne constituent pas une signature du producteur.

AssertLedger 2.0.0

AssertLedger 2.0.0 corrige les diagnostics des gros monorepos et rend explicite l’inventaire d’audit.

• doctor --json, init --dry-run et init produisent un conflit JSON valide lorsqu’une borne d’inventaire est dépassée. La limite de 1 000 tests reste inchangée ; aucune liste n’est tronquée et aucun fichier de configuration n’est écrit pour un plan en conflit.
• explain reconnaît les codes statiques de doctor/init et propose une action, notamment le choix explicite avec --framework lorsque plusieurs frameworks sont détectés.
• Avec une requête de vérification, audit utilise ses exclusions et les valeurs par défaut, comme la copie de campagne. Sans requête, la configuration valide s’applique. La sortie indique les exclusions utilisées et leur source.

Migration nécessaire : audit() et le CLI d’audit produisent désormais le schéma v2. Les consommateurs qui attendent strictement la sortie v1 doivent utiliser le schéma/parser v2. Les anciens schémas, parsers et artefacts v1 restent disponibles. Guide de migration.

Installation :

npm install --save-dev assertledger@2.0.0

Source du paquet et du tag : eccf7f684ea09c0cc6676212d07553147a76908f, checkout propre. PR #64, CI du candidat.

Les pièces jointes documentent le tarball testé, le registre et l’installation publique. La politique des liens symboliques, les limites de schéma et les projections de digest de campagne sont conservées. Le replay vérifie l’intégrité et les décisions ; il n’authentifie pas le producteur ni ne prouve un monorepo tiers. trusted-local reste explicitement non sandboxé.

AssertLedger 1.5.0

AssertLedger 1.5.0 qualifie les garanties déclarées avant une campagne et conserve leur périmètre dans les receipts et le replay.

• Plans scellés et décisions partagées entre CLI, SDK et MCP ; suites omises ou non prises en charge conservées comme obligations ouvertes.
• Profil public public-turbo-orchestration-2.11.7-bun-1.4.2 : sept obligations locales, caches isolés froids/chauds/invalidation, restauration des sorties, tâches non cachées, propagation des échecs et routage CI local.
• Attribution des assertions Node/Bun, observations terminales après fermeture du processus, refus des rapports anciens, versions inconnues et receipts incohérents. Une erreur opérationnelle ne vaut pas détection.
• Contrat v4 : vérification d’un test Bun existant désigné, import de témoins, fermeture des tests et modes d’isolation explicitement déclarés. Les contrats historiques restent compatibles.

Les neuf obligations du consommateur privé, dont sa vraie pipeline Bitbucket, restent ouvertes. Le replay vérifie l’intégrité et les décisions ; il ne réexécute pas les tests et n’authentifie pas leur producteur. trusted-local reste explicitement non sandboxé.

Installation :

npm install --save-dev assertledger@1.5.0

Source du paquet et du tag : 9895fee7350669b65e033c47f6ebe33675fb6f5a, checkout propre. Qualification #34, release #63, CI du candidat.

Les pièces jointes lient le tarball testé, l’archive du registre et les vérifications de l’installation publique. Les contrôles de livraison restent distincts des garanties du consommateur privé.

AssertLedger 1.4.0

AssertLedger 1.4.0

This minor release changes a public CLI contract: assertledger analyze now refuses an option it does not know. It writes the usage to stderr, nothing to stdout, and exits 64, as init and doctor already do. It used to ignore the option, so analyze . --exclude .claude exited 0 on the full set while looking as if the exclusion were applied: --exclude belongs to doctor and init.

Migration: drop the option. To leave an entry out of the analyzed set, declare it with assertledger init --exclude NAME, which records it in assertledger.config.json for analyze to honor. --json stays accepted, and analyze, analyze <repository>, analyze <repository> --json and analyze --json <repository> are unchanged. An argument that starts with - is an option, so a repository directory whose name starts with - is passed as ./-name.

Unchanged: reason codes, schemas, digests and MCP tool schemas. A second positional argument is still ignored, and so is an option placed before the command.

Release identity: 9327ce8ab757cd03848416bc517f96de333c0411. The tag points at the commit the package was built from, not at the merge commit (8949ef810b1dc2ecea4c83c5250aace826a365a6) that carries the same tree. The published assertledger-1.4.0.tgz (SHA-256 f389f06b5f1a240bdb172b58a442fcdd7ba5eba710b06f6831c008b03aca2931, npm shasum affe5ee78458537803f6fb71aaa020e41b5bdd51) was reproduced byte for byte by a local build from a clean checkout of that commit. The package records that commit and a clean source tree. The release preparation pull request (#30) passed 13 of 13 checks, and its independent proof audit and deterministic gate are recorded there. Installed from the registry, the package exits 64 on analyze . --unknown and on analyze . --exclude .claude.

Install with npm install --save-dev assertledger@1.4.0. See the changelog.

AssertLedger 1.3.1

AssertLedger 1.3.1

This patch release makes the UNSUPPORTED_REPOSITORY_SYMLINK refusal actionable. assertledger analyze and the assertledger_analyze MCP tool now name the first repository link that refuses an analysis, as a quoted path, and the guidance no longer suggests analyze --exclude: that option belongs to doctor and init, and init records it in assertledger.config.json for analyze to honor.

The refusal itself is unchanged. A link is still neither followed nor copied, and the error code, exit code 4, schemas and digests are unchanged. doctor still reports the code only.

Release identity: a0d358248efc7f13556a989bd132da49b46cec36. The 12-job CI run on main passed on Windows, Linux and macOS. All six package smoke jobs (Node 22.15.0 and 24 on the three platforms) produced identical assertledger-1.3.1.tgz bytes (SHA-256 0E8990687346EA8CA56C3011389B76534B0BEB9C7CE1E50AF8C3C967B38ED768), and a local build from a clean checkout of that commit reproduced the same SHA-256. The package records that commit and a clean source tree. The independent proof audit and deterministic gate for the release preparation (#28) are recorded on the pull request.

Install with npm install --save-dev assertledger@1.3.1. See the changelog.

AssertLedger 1.3.0

AssertLedger 1.3.0

This release adds assertledger setup . --client codex|claude-code for a combined, conflict-checked preview of repository initialization and client connection. --write applies the plan only after both preflights pass. Repeating setup preserves existing files. A partial failure rolls back only files created by that call whose bytes still match the plan, and reports any unresolved paths.

assertledger demo --allow-unsafe-execution runs the packaged node:test fixture in a disposable directory. Its result is explicitly scoped to SHIPPED_FIXTURE_ONLY; it is not evidence about the caller's repository. Existing verification and refusal contracts remain in place.

Release identity: b9407bff214e37f55e75af9f50e49191a48b8229. The 12-job CI matrix passed on Windows, Linux and macOS. All three platform package smoke jobs produced identical assertledger-1.3.0.tgz bytes (SHA-256 F7F2BFE993D2B6399541ACFD4FBCE5FEBE185F0ACAF02C423D618C81A44A0ACC). The package records that commit and a clean source tree. The independent proof audit and deterministic gate are tracked separately from CI.

Install with npm install --save-dev assertledger@1.3.0. See the setup guide and changelog.

AssertLedger 1.2.0

1.2.0 — 2026-09-25

An explicitly authored bun:test regression candidate can now produce attributed AssertLedger
evidence on the qualified Bun 1.4.2 runtime. The built-in v3 adapter wraps bun:test callbacks
before test files load and identifies only errors thrown by the packaged assertSame helper.
Native Bun expect failures stay non-attributed. Bun's JUnit totals check completeness; they
never decide whether a failure is an assertion.

• Add verification request/evidence manifest v3, Bun initialization v2, and Bun runtime doctor v2.
  Historical v1/v2 schema bytes and replay remain unchanged; the new schemas extend the additive
  schema lock. The manifest binds Bun executable, driver, preload, helper, and preflight identity.
• Pin Bun 1.4.2 on the Windows, Linux, and macOS verification matrix. The adapter uses serialized
  bun:test callback instrumentation in explicitly unsandboxed trusted-local execution; container
  Bun requests are refused. Missing or inconsistent callback and JUnit counts, ordinary errors,
  and timeouts cannot kill a target.
• Carry assertion ownership from the preload through a signed process pipe and emit the final
  report from the driver. Candidate-written files cannot forge either evidence channel. Ownership
  is scoped to each test callback execution, including each parameterized row, so a saved error
  cannot be replayed. AsyncLocalStorage preserves that scope across asynchronous continuations.
  Multiple failing candidate rows are credited only when every failure is an owned assertion.
• Package the assertledger/bun helper and validate its JavaScript and TypeScript exports in a
  fresh package consumer. See verification v3 migration.
• Let static doctor select --framework bun:test in mixed repositories, including through SDK
  and MCP, without executing repository code.

Compatibility: existing Node and structured-command requests keep their v1/v2 contracts and
decisions. Bun campaigns require v3 requests and new candidate tests that import assertSame;
old Bun expect tests can remain base controls but their failures do not count as target evidence.
The v1 evidence provider/export surface does not project Bun v3 evidence.

A repository that keeps a local-only symbolic link, such as an agent's skill directory, can now be
diagnosed and initialized without weakening the link refusal.

• doctor and init accept --exclude NAME, repeatable, and the MCP assertledger_doctor tool an
  optional exclude array. Each value is one portable entry name, skipped at any depth like the
  defaults; anything else is a CONFLICT with INVALID_REPOSITORY_EXCLUDE. The names are written to
  repository.exclude, and a valid configuration's list then applies to init and doctor without
  flags, analyze and runtime doctor's configuration check. A different explicit list fails closed,
  for example with CONFIG_CONFLICT, or with UNSUPPORTED_REPOSITORY_SYMLINK when it exposes a
  link again.
• audit, campaign copies and manifest digests ignore the configured list: they keep the defaults
  and, for a campaign, the verification request's repository.exclude. audit therefore still
  refuses a repository whose linked entry is only declared in the configuration.
• A link inside the inventory still fails closed. init and every static doctor now report it as a
  CONFLICT result with UNSUPPORTED_REPOSITORY_SYMLINK instead of throwing, so the CLI keeps exit
  code 4 and the MCP tool returns the result instead of an error. analyze still throws. Runtime
  doctor therefore reports such a repository as RUNTIME_CONFIGURATION_BLOCKED instead of
  RUNTIME_CONFIGURATION_UNAVAILABLE.
• explain UNSUPPORTED_REPOSITORY_SYMLINK now has a catalogue entry, and the
  INVALID_REPOSITORY_EXCLUDE guidance describes entry names.
• isRepositoryExcludeName is exported beside the configuration parser, and analyzeRepository
  takes an optional { configuredExcludes: true }; without it, the engine function is unchanged.

Compatibility: schema, policy, profile, benchmark and conformance versions, manifest, audit and
benchmark digest projections are unchanged. The public analyze result, whose digest is not
evidence, now omits configured names, so its files and repositoryDigest can differ from an audit
of the same tree. A configuration written by 1.1.1 plans the same bytes. A configuration
whose repository.exclude was edited by hand used to return CONFIG_CONFLICT; its names now apply
to the static inventory. SDK callers that caught the UNSUPPORTED_REPOSITORY_SYMLINK rejection from
init or doctor now receive a CONFLICT result.