Eve

English | 中文

Eve is a model-native executable semantic language and local-first runtime.

AI models author compact .eve source. Eve lowers that source into typed semantic DAGs, canonical protocol artifacts, execution plans, bounded capability calls, receipts, replay evidence, and optional generated targets such as Web projects.

Humans inspect, approve, govern, debug, and audit through projections and tools. They are not the primary source authors.

Status

Eve Plan 2.0 declared public release on 2026-06-21. The mature model-native GA line was accepted on 2026-06-24.

• Roadmap: docs/roadmap.md
• Public release signoff: docs/eve-public-release-signoff-2026-06-21.md
• Model-native GA signoff: docs/eve-model-native-ga-signoff-2026-06-24.md
• Release gate: docs/eve-protocol-release-v2.md
• Command contract: docs/eve-command-surface-v1.md

The roadmap is the only source of truth for phase order and completion status. This repository still operates as a development-stage workspace, so destructive refactors remain allowed when they improve Plan 2.0.

Install

1. GitHub Release Binary

Download the binary for your platform from the GitHub Release page:

• eve-linux-x86_64.tar.gz
• eve-darwin-arm64.tar.gz

Then install it into your PATH:

tar -xzf eve-linux-x86_64.tar.gz
chmod +x eve
sudo mv eve /usr/local/bin/eve

On macOS arm64, use eve-darwin-arm64.tar.gz instead of eve-linux-x86_64.tar.gz.

2. Build From Source

cargo build --release -p eve-cli --bin eve
./target/release/eve doctor examples/phase8/local_quickstart

Quickstart

eve new my-app --template reference-web
cd my-app
eve check
eve run
eve test
eve verify
eve build
eve doctor

eve build generates target artifacts from .eve semantic truth. For the Web target, generated files live under the project generated/ directory.

Starter Templates

Recommended official templates:

• reference-web
• reference-data-workflow
• reference-local-agent
• reference-os-automation
• reference-native-ui

Earlier focused starters:

• web-app
• audit-report
• structured-extraction
• external-commit-approval

See docs/eve-official-template-catalog-v1.md for the official template catalog.

Common Workflow

Most users only need this loop at first:

eve new my-app --template reference-web
cd my-app
eve check
eve run
eve test
eve verify
eve build
eve doctor

Other common command groups:

• Intent loop: eve intent preview, eve intent apply
• Packages and compatibility: eve package inspect|resolve|verify-lock|audit, eve compat check, eve migrate --dry-run
• Registry and trust: eve registry publish --dry-run, eve registry install
• Runtime evidence: eve debug trace, eve debug explain, eve ops health|replay-incident|export
• Service and agent flows: eve service ..., eve agent ...
• OS, automation, and native surfaces: eve os ..., eve automation ..., eve native ...

See docs/eve-command-surface-v1.md for the full frozen command contract.

What Eve Is Not

Eve is not a Python, Java, or JavaScript replacement designed around human coding habits. It is not a JSON-first automation framework, a prompt-wrapper agent runtime, or an unrestricted shell/browser/network executor.

Eve's source truth is .eve. JSON remains a projection surface for inspection, testing, and release evidence.

FAQ

Q1. What advantages does Eve have over traditional programming languages?

Eve is optimized for model authorship, semantic patching, controlled execution, and audit evidence. Traditional languages optimize for human coding habits. Eve keeps source truth in .eve, semantic DAG identity, plans, capabilities, receipts, replay, and target diffs.

Q2. Does the small package size mean Eve is incomplete?

No. Package size alone does not prove completeness or incompleteness. Eve is a Rust-first local toolchain, so the public binary can be much smaller than a full Python or Java distribution that ships a large standard runtime and ecosystem.

Q3. Is Eve a fake project?

No. Eve already ships a real protocol and runtime chain across .eve source, semantic DAG, canonical artifacts, execution plans, runtime execution, receipts, replay evidence, package/registry/trust surfaces, service and agent flows, OS and automation boundaries, and generated target proofs.

Q4. If eve build generates traditional code, what is the advantage?

The advantage is that generated code is an output, not the logic truth. Eve keeps the source of truth in .eve, semantic DAG identity, execution plans, capability policy, receipts, replay, and target diffs.

Directly writing traditional code makes the codebase the primary place where logic, side effects, tests, and audit behavior live. Eve's goal is different: the model edits semantic truth first, and target code is regenerated or skipped depending on what the runtime or integration path needs.

Q5. Is the intended workflow natural language -> AI model -> Eve -> traditional code?

Close, but the important correction is that traditional code is optional target output. The intended mainline is:

human intent
-> AI-authored .eve or semantic patch
-> semantic DAG
-> execution plan / bytecode
-> Eve runtime / capability adapters
-> receipts / replay / audit
-> optional generated target output

The durable logic should live in Eve artifacts. Generated traditional code may support Web targets, integrations, deployments, or migrations, but it must not become the primary feedback, debugging, package, test, or execution truth.

Q6. Can Eve generate any traditional programming language?

Not automatically today. Eve can support multiple target backends over time, but each target must be implemented, validated, and tied back to .eve semantic truth through manifests, target diffs, and audit evidence.

The goal is not to generate every language for its own sake. The goal is to let Eve execute directly where possible and generate traditional code only when a target platform or integration requires it.

Q7. Can any AI model use Eve?

Eve is intended to be model-agnostic. It should not be tied to one model provider. Any AI model that can generate .eve, apply semantic patches, read diagnostics, and repair its output can use Eve at some level.

Different models will use Eve with different reliability. Stronger models may author full packages and workflows; smaller models may need more diagnostics, templates, repair loops, editor-facing semantic projections, and compatibility evidence.

Development

cargo fmt --all --check
cargo test --workspace

Common local verification:

cargo run -q -p eve-cli --bin eve -- check examples/phase8/local_quickstart
cargo run -q -p eve-cli --bin eve -- run examples/phase8/local_quickstart
cargo run -q -p eve-cli --bin eve -- test examples/phase8/local_quickstart
cargo run -q -p eve-cli --bin eve -- build examples/phase8/local_quickstart
cargo run -q -p eve-cli --bin eve -- doctor examples/phase8/local_quickstart

License

Licensed under either of:

• Apache License, Version 2.0 (LICENSE-APACHE)
• MIT License (LICENSE-MIT)

at your option.