Cópia estática

Copiado de docs/adp/ADP-008-v0.1.0-language-release.md em https://github.com/poppy-team/aipo-lang (MIT). Fixado na revisão ce47c4e070404fc41722ccd8e2b7b808b99062a8, blob 583d83476bc5aef578ae4188da08d39fa81da374. O repositório de origem permanece canônico; esta cópia é atualizada por um pull request de sincronização, não em tempo real.

ADP-008 — Release aipo v0.1.0 e fronteira de interoperabilidade

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 ao canon; esta ADP define o recorte da primeira release da linguagem, não um ecosystem completo.

A. Contexto

Aipo já possui uma base executável: linguagem, VM, backend JavaScript, async, contratos, host ABI interna, packages locais/GitHub e tooling básica. O produto completo de games, web e editors ainda é grande demais para entrar na primeira release.

A expressão “V1” significa aipo v0.1.0: a primeira versão confiável e utilizável da linguagem. Ela não significa que todas as aplicações, engines ou ferramentas já estejam prontas.

B. Decisão

A release aipo v0.1.0 é language-first e tem três prioridades:

1. Linguagem: V1 syntax, types, contracts, modules, errors e async.
2. Embedding: Rust API e C ABI síncrona, versionada e independente de engine.
3. Interoperabilidade: thin proofs reais para Rust, C e JavaScript.

A release também inclui o test runner mínimo e o contrato de packages já implementado para dependências locais e GitHub pinado.

C. Conteúdo da release

Área	Critério de inclusão
Language	V1 syntax, semantic contracts, modules, Failure/fault split e stdlib essencial
Async	async fn, await, task.*, scheduler determinístico e paridade VM↔JS
CLI	aipo run, check, build, fmt e test mínimo
Rust embedding	API Rust segura para um host, sem expor referências ou layouts Rust ao Aipo
C ABI	Runtime opaco, versionado, síncrono, single-threaded, handles e erros estáveis
JS interop	Bridge explícito e limitado; sem globais implícitos de Node ou browser
Packages	aipo.toml, aipo.lock, cache e GitHub pinado já certificados
Thin proofs	Uma integração real pequena para cada fronteira: Rust, C e JS
Release	Exemplos, documentação, migração, testes e gates completos

O número 0.1.0 não remove os gates de segurança, determinismo, paridade ou compatibilidade. Ele apenas define uma primeira fronteira entregável.

D. Test runner da release

aipo test é parte da linguagem porque validar comportamento, contracts e interoperabilidade faz parte do produto.

O contrato mínimo é:

• bloco canônico test("name") do ... end;
• assertions via expect;
• um VM novo por teste;
• clock e RNG controlados;
• capabilities de host explícitas;
• rede desligada por padrão;
• output humano e --message-format=jsonl;
• exit codes estáveis.

aipo new, aipo watch, LSP, REPL, debugger e profiler pertencem ao tooling do produto posterior. Eles podem ser desenhados agora, mas não bloqueiam a v0.1.0 da linguagem.

E. C ABI v0

A decisão completa está em docs/adp/ADP-009-synchronous-c-abi.md. A primeira ABI é síncrona e single-threaded porque o VM atual é single-threaded e o produto ainda não precisa prometer threads.

A ABI deve:

• expor runtime e handles opacos;
• versionar o contrato;
• valores simples e handles de forma explícita;
• registrar funções host por módulo e capability;
• mapear erros para códigos estáveis;
• impedir panic, referência Rust e lifetime Rust na fronteira;
• preservar a possibilidade de adicionar step e run_until_idle depois.

Async na ABI C é evolução aditiva, não um detalhe da v0. A semântica async da linguagem já faz parte da release; o pump cooperativo para hosts vem depois.

F. Thin proofs de interoperabilidade

A decisão completa está em docs/adp/ADP-010-interoperability-thin-proofs.md. A release não promete portar bibliotecas inteiras. Ela prova cada fronteira com uma integração pequena, real e testável.

Fronteira	Prova mínima	Limite
Rust	Um módulo host real; egui pode ser a prova preferencial	Não exige wrapper completo de egui
C	Uma biblioteca pequena com create/use/release, ownership e erros explícitos	Não exige portar um framework inteiro
JS	Um módulo JS com bridge explícito e tradução de erros	Não equivale a Node completo nem acesso implícito a window

Cada proof precisa de teste, documentação, declaração de capabilities e uma forma de verificar ownership. O critério de escolha é clareza da API e segurança, não popularidade.

G. Produtos pós-v1

Os seguintes itens ficam explicitamente fora da aipo v0.1.0:

• Godot e adapters de engines;
• engine Aipo/Petunia3D;
• editor visual, REPL, debugger e profiler;
• aipo new, aipo watch e LSP completo;
• perfil DOM/storage, fetch, workers e WebAssembly;
• registry, publicação, SemVer solving e vendor tree;
• hot reload completo;
• scripts de lifecycle/install.

A engine Aipo/Petunia3D permanece uma decisão adiada. A superfície de gameplay ECS + comportamento, assets pertencentes ao host e o adapter do Godot são a direção futura, não uma dependência da v0.1.0.

H. Ordem de implementação

1. Certificar o núcleo linguístico e async da v0.1.0.
2. Implementar o test runner mínimo.
3. Escrever o ADR e o spike da ABI C.
4. Criar a Rust embedding API.
5. Entregar um thin proof C.
6. Entregar um thin proof JS.
7. Atualizar docs, exemplos, release notes e executar todos os gates.

I. Definition of Done

A aipo v0.1.0 só pode ser declarada quando:

• o corpus principal passa na VM e no JavaScript;
• async e contracts possuem fixtures executáveis;
• aipo test executa testes isolados;
• a ABI C possui integração headless e versionamento documentado;
• Rust, C e JS possuem thin proofs verificáveis;
• erros, capabilities e ownership estão documentados;
• packages locais/GitHub continuam fail-closed;
• documentação, exemplos e notas de migração estão atualizados;
• fmt, clippy, testes, docs, Prumo e gates de segurança estão verdes.

J. Consequências

A release entrega uma linguagem utilizável sem prometer uma plataforma completa. Godot e a engine própria só serão investimentos sérios depois de a ABI e os thin proofs demonstrarem que o boundary funciona.

O principal risco é crescimento de escopo. Qualquer feature que exija editor, engine, registry ou framework deve entrar em uma release posterior ou em um goal separado.