Static copy

Copied from docs/en/adp/ADP-008-v0.1.0-language-release.md in https://github.com/poppy-team/aipo-lang (MIT). Pinned to revision ce47c4e070404fc41722ccd8e2b7b808b99062a8, blob 84c0c5b671435217fa7602a679a230477af37635. The source repository remains canonical; this copy is refreshed through a sync pull request, not live.

ADP-008 — Release aipo v0.1.0 and the interoperability boundary

Status: accepted Date: 2026-09-24 Related: docs/product/vision.md, docs/product/scope.md, docs/adp/ADP-006-wave3-wave4-open-decisions.md, docs/adp/ADP-007-package-identity-and-distribution.md, docs/adp/ADP-009-synchronous-c-abi.md, docs/adp/ADP-010-interoperability-thin-proofs.mdAuthority: subordinate to the canon; this ADP defines the cut for the language's first release, not a complete ecosystem.

A. Context

Aipo already has an executable foundation: language, VM, JavaScript backend, async, contracts, internal host ABI, local/GitHub packages and basic tooling. The complete product for games, web and editors is still too large to fit in the first release.

The expression "V1" means aipo v0.1.0: the first reliable and usable version of the language. It does not mean that every application, engine or tool is already ready.

B. Decision

The aipo v0.1.0 release is language-first and has three priorities:

1. Language: V1 syntax, types, contracts, modules, errors and async.
2. Embedding: Rust API and a synchronous, versioned, engine-independent C ABI.
3. Interoperability: real thin proofs for Rust, C and JavaScript.

The release also includes the minimal test runner and the package contract already implemented for local and pinned GitHub dependencies.

C. Release contents

Area	Inclusion criterion
Language	V1 syntax, semantic contracts, modules, Failure/fault split and essential stdlib
Async	async fn, await, task.*, deterministic scheduler and VM↔JS parity
CLI	aipo run, check, build, fmt and a minimal test
Rust embedding	Safe Rust API for a host, without exposing Rust references or layouts to Aipo
C ABI	Opaque, versioned, synchronous, single-threaded runtime, with stable handles and errors
JS interop	Explicit and limited bridge; no implicit Node or browser globals
Packages	aipo.toml, aipo.lock, cache and pinned GitHub, already certified
Thin proofs	One small real integration for each boundary: Rust, C and JS
Release	Examples, documentation, migration, tests and complete gates

The number 0.1.0 does not remove the security, determinism, parity or compatibility gates. It only defines a first deliverable boundary.

D. Release test runner

aipo test is part of the language because validating behavior, contracts and interoperability is part of the product.

The minimum contract is:

• canonical test("name") do ... end block;
• assertions via expect;
• a fresh VM per test;
• controlled clock and RNG;
• explicit host capabilities;
• network off by default;
• human output and --message-format=jsonl;
• stable exit codes.

aipo new, aipo watch, LSP, REPL, debugger and profiler belong to the later product tooling. They can be designed now, but they do not block the language's v0.1.0.

E. C ABI v0

The full decision is in docs/adp/ADP-009-synchronous-c-abi.md. The first ABI is synchronous and single-threaded because the current VM is single-threaded and the product does not yet need to promise threads.

The ABI must:

• expose an opaque runtime and handles;
• version the contract;
• pass simple values and handles explicitly;
• register host functions per module and capability;
• map errors to stable codes;
• prevent panics, Rust references and Rust lifetimes at the boundary;
• preserve the possibility of adding step and run_until_idle later.

Async in the C ABI is an additive evolution, not a detail of v0. The language's async semantics are already part of the release; the cooperative pump for hosts comes later.

F. Interoperability thin proofs

The full decision is in docs/adp/ADP-010-interoperability-thin-proofs.md. The release does not promise to port entire libraries. It proves each boundary with a small, real, testable integration.

Boundary	Minimum proof	Limit
Rust	One real host module; egui can be the preferred proof	Does not require a complete egui wrapper
C	A small library with create/use/release, ownership and explicit errors	Does not require porting an entire framework
JS	A JS module with an explicit bridge and error translation	Does not amount to full Node nor implicit access to window

Each proof needs a test, documentation, a capabilities declaration and a way to verify ownership. The selection criterion is API clarity and safety, not popularity.

G. Post-v1 products

The following items are explicitly outside aipo v0.1.0:

• Godot and engine adapters;
• Aipo/Petunia3D engine;
• visual editor, REPL, debugger and profiler;
• aipo new, aipo watch and full LSP;
• DOM/storage profile, fetch, workers and WebAssembly;
• registry, publishing, SemVer solving and vendor tree;
• full hot reload;
• lifecycle/install scripts.

The Aipo/Petunia3D engine remains a deferred decision. The ECS + behavior gameplay surface, host-owned assets and the Godot adapter are the future direction, not a dependency of v0.1.0.

H. Implementation order

1. Certify the language and async core of v0.1.0.
2. Implement the minimal test runner.
3. Write the ADR and the spike for the C ABI.
4. Create the Rust embedding API.
5. Deliver a C thin proof.
6. Deliver a JS thin proof.
7. Update docs, examples and release notes, and run all gates.

I. Definition of Done

aipo v0.1.0 can only be declared when:

• the main corpus passes on the VM and on JavaScript;
• async and contracts have executable fixtures;
• aipo test runs isolated tests;
• the C ABI has headless integration and documented versioning;
• Rust, C and JS have verifiable thin proofs;
• errors, capabilities and ownership are documented;
• local/GitHub packages remain fail-closed;
• documentation, examples and migration notes are up to date;
• fmt, clippy, tests, docs, Prumo and security gates are green.

J. Consequences

The release delivers a usable language without promising a complete platform. Godot and the engine of our own will only become serious investments after the ABI and the thin proofs demonstrate that the boundary works.

The main risk is scope growth. Any feature that requires an editor, engine, registry or framework must go into a later release or a separate goal.