v0.4.0 implementation and evidence baseline

September 10, 2026 ยท View on GitHub

Status: HOSTED GREEN for the implemented v0.4.0 code baseline.

Audience: documentation readers, contributors, maintainers, and coding agents.

Baseline date: 2026-09-10.

Authoritative release baseline

The current documentation baseline is the published SEMAPRAX v0.4.0 prerelease, commit dfc15e2ddc818fa97744b5a9d69fd6108dd6a321. The maintainer has confirmed HOSTED GREEN for the implemented code and its release evidence. The release-note length problem was a publication issue, not an outstanding implementation or hosted-conformance task.

The documentation reconciliation starts from main commit 49119c8d14c2ff1f6fef582ea80611659fc930ef. Its changes after the release tag are documentation-only; the compiler, runtime, packages, tests, and workflow logic are the same as the release baseline. Subsequent documentation-only commits do not create a new language or protocol version.

This record establishes the current release acceptance; it does not invent a new workflow-run identifier or rewrite the conclusions of historical workflow attempts. Exact older run IDs, logs, test counts, and known-answer values remain attached to the executions that produced them.

How to read evidence status throughout docs/

For an already implemented feature included in v0.4.0, pre-release wording such as "local evidence only", "hosted evidence remains required", "hosted promotion remains open", or "current-head evidence unobserved" is superseded by this HOSTED GREEN baseline where the missing condition was execution of the implemented release gates. Do not carry those completed evidence tasks forward into the roadmap or an implementation backlog.

Three separate facts must remain separate:

  1. Implementation and evidence: the admitted v0.4.0 implementation has the accepted hosted-green release evidence.
  2. Contract scope: each owning specification still defines exactly which syntax, types, operations, effects, targets, and failure paths are admitted.
  3. Product completion or publication: missing functionality, an unpublished SDK, a private ABI, an explicit promotion decision, or a broader completion gate is not completed merely by the evidence status changing.

A historical local execution remains a historical local execution. It can be retained as a reproducible witness alongside the current hosted-green baseline; it is no longer the sole current evidence classification for the released implementation. Conversely, a future, proof-only, ignored, or explicitly unimplemented gate is not silently declared executed by this record.

The completion matrix remains the authority for the full product requirements. Its overall Partial status is compatible with a HOSTED GREEN release: the release proves the admitted slices, not every future feature in the language objective.

Released implementation map

Use the owning versioned specifications for exact limits and compatibility. The release includes the current implementations, not just the earlier v1 slices described in historical evidence sections.

AreaCurrent owning references
Source Agent lifecycle, typed operations, and direct executionIterative lifecycle v2, typed effects v3, Direct Runtime v2
Checkpointed execution and migrationOperation checkpoints v2, state migration v2, durable migration v3
Project and workspace execution associationsProject linked lifecycle, Project linked migration, execution roots, workspace association, workspace migration
Generic language compositionArgument inference v3, authored variants, compiler collections, owned record composition v2, owned Result
Collections, callbacks, and traversalVec v2, Box v2, function values v2, closures v2, generic Iterator helpers, generic Iterator operations
Semantic changes and retained program meaningUniversal transactions v2, transaction composition, semantic query, incremental semantic service
Installed and generated workflowsUnified CLI, installed guidance, scaffold v3, standard library catalog

This map is a navigation aid, not a replacement for any versioned contract. Older versions remain relevant to compatibility and frozen wire identities. A successor's additional behavior must not be retroactively attributed to its predecessor's schema or ABI.

Published artifacts

The release is pre-alpha and has three published toolchain archives. The following sizes and SHA-256 digests are the release API's artifact metadata.

ArchiveBytesSHA-256
semaprax-v0.4.0-x86_64-unknown-linux-gnu.tar.gz17,922,46021613bed94c9ed41d8ca67cee0924429fff18b1236198c58b16cb4bfd40786f9
semaprax-v0.4.0-aarch64-apple-darwin.tar.gz15,789,2849b4ebf2bc0e9ca8bdb12db4dea795f9bf7b7b8cf73731f077c3bb80221acda60
semaprax-v0.4.0-x86_64-pc-windows-msvc.zip18,547,218e175bfc830f189229f0b9881df3afcf0bfb10939cd4a89c5b18bc138def54d07

See the release process for the release record and installation guide for use. Checksums are integrity metadata, not signatures. The release remains unsigned, not notarized, and not a claim of cross-host byte-reproducible builds.

Documentation maintenance rules

Current summaries, feature status paragraphs, and roadmap evidence tasks should use this release baseline rather than repeat pre-release local-only status. Preserve semantic limits and remaining functionality, including explicit public promotion requirements. Preserve historical release records and the bytes of retained evidence under docs/evidence/; those are provenance, not mutable status dashboards. Generated catalogs and diagnostic-help data must continue to match their owning generators and executable contracts.

A later code change requires evidence for its changed behavior. Do not reuse this baseline to claim that untested post-v0.4.0 code is hosted green. A successful documentation update also does not assert that a new compiler test run was performed during that update.