Output support

Output support

A valid .expec contract can be useful to several outputs. It does not follow that every language construct has a supported mapping in every output.

Current profiles

Output	ID	What it produces
TypeScript contracts	typescript	Supported declarations/signatures with preserving project edits
TypeScript acceptance	acceptance	Readable tests, DSL checks and runtime driver contracts
Java contracts / acceptance	java, java-acceptance	Supported Java declarations and JUnit acceptance layers
Kotlin contracts / acceptance	kotlin, kotlin-acceptance	Supported Kotlin declarations and JUnit acceptance layers
Python contracts / acceptance	python, python-acceptance	Supported Python declarations and pytest acceptance layers
UML	uml	Supported structural relationships and authored communication sequences
Markdown	markdown	Contracts, examples and visible obligations

The language also exposes finite structure/contract listing outputs for inspection; they are not an additional executable application language. The profiles above are the author-facing code/document/diagram choices.

Native prerequisites

The released journeys use Node 24.19.0 / npm 11.20.0; Java and Kotlin use JDK 21 and Gradle 9.1.0. Kotlin uses 2.4.10; JVM acceptance uses JUnit 6.1.3. The Python profile uses CPython 3.12, uv 0.12.23, LibCST 1.9.0, Jedi 0.20.0, mypy 2.4.0 and pytest 9.1.1.

These are the documented finite profiles, not a claim of arbitrary version compatibility. Native configuration and dependencies must be explicitly prepared. A missing requirement should produce an actionable error rather than implicit installation.

What remains your implementation

Code generation can produce signatures, declarations and stubs. Driver stubs need real behavior. Prose promises and satisfies expectations need verification work; they are not natural-language programs.

A generated interface or type does not execute anything. A diagram is not a test. A Markdown explanation is not runtime evidence. An authored interaction is not an observed call trace. An output may reject a valid specification when it cannot preserve or represent its construct faithfully.

Preservation and coverage

Established identities and explicit native mappings support preserving handwritten implementations through supported changes. A new or ambiguous mapping can require a deliberate decision. Native files remain the source of actual implementation and use facts.

Static search coverage is finite. Dynamic or unresolved references can leave coverage incomplete and block a preserving edit. The tool must not interpret incomplete reference discovery as proof that deleting something is safe. Partial writes are reported rather than described as an atomic transaction.

The Python profile uses controlled native inspection and pytest execution; it does not promise arbitrary plugin/configuration support. Similar profile and mapping constraints apply to other native outputs.

Scope of this reference

This edition demonstrates six output families, not every possible target. npm-registry publication, IDE support, full compiler self-hosting, browser execution and hosted Supabase behavior are not established by these examples. Compiler source contracts can still be useful for self-development without being a fully self-hosting compiler.

Related: Project configuration and commands · Examples and scenarios · Interactions