Documentation / Core 1.0.7 source validation — 2026-10-17

Core 1.0.7 source validation — 2026-10-17

Measured on Windows with Linux Docker containers against public Core source commit 20d837a2f735c1c785db6593b58ebe10b3dd9f05, tree 0df0b96852f472ff0a80f5c3a88ded0f61215c81. The pin helper resolved v1.0.7 to that commit and exited 0. A fresh scripts/bootstrap.ps1 fetched the pinned source and exited 0; its CLI build reported 0 warnings and 0 errors. The built source CLI's --version exited 0 and returned 1.0.0-0.local+20d837a2f735c1c785db6593b58ebe10b3dd9f05.

This records source execution only. No official Core 1.0.7 CLI package was downloaded, installed or accepted by this validation. The unchanged Core 1.0.6 acceptance record preserves its historical source and installed-package results.

Source case Assertions passed Other verdicts Case runner exit
inventory-python 5 0 0
kafka-mtls 2 0 0
ledger-jsonrpc 10 0 0
orders-dotnet 5 0 0
orders-dotnet-compose (targeted retry) 5 0 0
payments-java 4 0 0
Migration from-postman 4 0 0
Migration from-xunit 3 0 0
Migration from-specflow 4 0 0

The six samples total 31 passing assertions, including the ledger custom runner's 10; the three migrations separately total 11. Counts come from the CLI scenario summaries. Each final case's JUnit report contains one scenario, with zero failures, errors or skips. “Other verdicts” combines fail, environment-error and inconclusive assertion counts for the final case execution.

The initial scripts/run-sample.ps1 all native exit was 3: Compose was refused before provisioning because its documented VOUCHFX_COMPOSE_PASSWORD input was absent. Its initial summary was pass=0 fail=0 envError=1 inconclusive=0. The other five case runners exited 0. The original log and all-run reports were retained separately. Only Compose was retried, using a newly generated disposable password supplied in the child process environment, then removed; its native exit was 0 with five passing assertions. The initial aggregate exit remains 3; no second full all run is claimed. scripts/run-migrations.ps1 exited 0 and reported exit 0 for each migration.

The standard source runner rebuilt ledger-jsonrpc against the new pin before executing it; the runner build reported 0 warnings and 0 errors. Its packages.lock.json required no tracked change. It remains custom-source-only.

Measured Kafka security event and reports

The standard runner writes HTML and JUnit, without requesting a JSONL archive. After the sequential sample and migration runs, this additional source CLI invocation captured the real event alongside its two report projections:

dotnet .vouchfx-src/src/Cli/Vouchfx.Cli/bin/Release/net8.0/vouchfx.dll `
  run samples/kafka-mtls/tests `
  --events out/kafka-mtls-security-results.jsonl `
  --junit out/kafka-mtls-security-results.xml `
  --html out/kafka-mtls-security-report.html `
  --fail-on-env-error --fail-on-inconclusive

Measured native exit: 0; assertions: 2 passed, 0 other verdicts; JUnit scenarios: 1. This repeat is separate event-projection coverage and is not added to the 31-assertion sample total.

The JSONL archive contains exactly one security-confirmation event (v: 1, schemaVersion: v1), emitted at 2026-10-17T16:28:24.3156919+00:00, with run ID cc9424eb8ae94e2eb27b63f4bdc47a3c. Its observed fields are:

Field Value
targetName / targetKind broker / service
declaredProfile / declaredEndpoint mtls / 9092
observedAddress / observedProtocol localhost:19093 / Tls13
clientIdentityResolved true
level AuthenticatedRoundTrip
replayed false

The decoded JUnit property vouchfx.securityConfirmation.0 exactly equals that JSON event, including timestamp and run ID. The HTML “Security confirmations” table contains one matching row with the same target, declaration, address, protocol, identity-resolution flag, level and run ID, labelled “Build-time probe”. Its qualification that identity resolution alone does not establish peer acceptance is present. These checks exited 0.

The actual probe diagnostic separately records that the broker answered a Kafka ApiVersions request using the client identity and refused the same request on a second connection without a client certificate. That probe evidence establishes this run's mTLS confirmation; the two successful publish/consume assertions alone would not establish client-authentication enforcement. Topic-level authorisation was not confirmed.

SHA-256 of the retained event-run artifacts:

Artifact under out/ SHA-256
kafka-mtls-security-results.jsonl c6c5889ec19f5549251e230a4cc3af3507266a65a0e4484e36ff2b830be2c594
kafka-mtls-security-results.xml 690ed659acb19ed3c70e599f39681768a82e5a53a29e4c9b67186f924e35d018
kafka-mtls-security-report.html 761a0c6c4fe163def1162204d2c91f9e6bc4fb6b92c0466780bb0be62be2b99c

Per-command logs, native exit markers, the original all-run artifact snapshot and the verification receipt are retained outside the repository. Generated reports remain ignored under out/; no test certificates or credentials are committed.