Is Traverse production ready?
Traverse v0.7.0 is functionally stable for the local placement target, but a security and permanence audit found dangerous defaults that mean the framework should be treated as pre-production for anything network-facing. The local runtime and contract validation are solid. The CLI's HTTP server and the MCP server currently have real authentication gaps. The project is also pre-1.0, so minor version bumps can include breaking API changes. Pin your version and read the changelog before upgrading.
What is stable today
- Local placement target — runs WASM capabilities in the local process
- Contract validation — preconditions and postconditions against JSON Schema
- The traverse CLI — capability registration, invocation, and trace inspection (local use; the HTTP serve mode has known gaps, see below)
- The MCP server — tools/list and tools/call for AI agent integration, trusted as a local IDE child process only (no auth boundary, see below)
- Trace artifacts — every execution is recorded and inspectable
- The governing spec model — linking contracts to source documents
What is still maturing
- Browser, edge, cloud, and AI pipeline placement targets — in development
- Hosted registry — not yet available
- Language SDKs for Python, TypeScript, Go — planned
- Streaming output — not yet supported
- JWT verification, Sigstore verification, and MCP authentication — implemented as insecure defaults or stubs today, not yet real. Ed25519 artifact signing does work.
Known security gaps
A framework-wide audit (July 2026) found the following before recommending any network exposure:
- The HTTP server defaults to Development mode and never forces Production; unsigned artifacts are allowed to run.
- JWT identity is parsed from the base64 payload only — there is no signature or JWKS verification, so a forged token is accepted.
- The MCP stdio server has no authentication at all. Anything that can write to its stdin can execute capabilities and read full execution traces.
- Sigstore artifact verification is currently a stub that always reports "verified" rather than performing real verification.
None of this affects the local runtime itself — WASM sandboxing and contract validation are unaffected. It affects anything that exposes the HTTP API or the MCP server beyond a fully trusted local process. Read the full security audit for severity, file locations, and the remediation roadmap.
How to evaluate readiness for your use case
If you need the local target only — running contracts on one machine, exposing capabilities to an AI agent via MCP — then Traverse is ready for that today. The core execution model is solid. The things still in progress are around the broader deployment surface, not the fundamental runtime behavior.
If you need to deploy capabilities to the browser or cloud, or if you need a hosted registry your team can share, those features are not there yet. You would be building ahead of the stable surface and accepting more churn.
The pre-1.0 caveat
Pre-1.0 means Enrico can change APIs between minor versions if the design requires it. In practice, the contract format and core runtime behavior have been stable across recent releases. The parts that change are the edges — new placement targets bring new APIs, and those settle as the targets mature. Follow the changelog and the roadmap to stay informed.