From 9c8a1addb2824bcde7c74efee4c2b3053084caac Mon Sep 17 00:00:00 2001 From: Enrico Piovesan Date: Wed, 8 Jul 2026 22:17:17 -0600 Subject: [PATCH] feat: publish real security & permanence audit, correct false claims Adds /security-audit.html: the full Traverse Permanence & Security Audit (July 2026) -- verdict, 15-item findings register with severity, the permanence guarantee matrix, crate maturity table, trust boundary map, and the opportunity roadmap. Content is reproduced faithfully from the source audit; no numbers or claims invented. Linked from the Developers nav dropdown, mobile menu, and footer so it isn't orphaned. Also corrects claims elsewhere on the site that the audit contradicts: - roadmap.astro claimed "100% test coverage, all shipped code is tested, no exceptions." The audit found only 3 of 6 crates are coverage-gated; the CLI's ~9k-line HTTP surface and the MCP server are not. Corrected to state this precisely, linking to the audit. - is-traverse-production-ready.astro (both the visible body and its FAQPage JSON-LD) claimed the MCP server and CLI were safe to "use in production today" with no caveat. The audit found the MCP stdio server has zero authentication (any stdin writer can execute capabilities and read full traces) and the HTTP server defaults to Development mode with unverified JWTs. Added a "Known security gaps" section and corrected the safe-to-use list to reflect this. - what-is-traverse-security-model.astro implied checksums are verified automatically before deploy; the audit found the runtime checksum gate is not enforced in verify_artifact and Sigstore verification is a stub. Corrected the claim and added a pointer to the full audit. Co-Authored-By: Claude Sonnet 5 --- src/components/Footer.astro | 1 + src/components/Nav.astro | 8 + .../is-traverse-production-ready.astro | 4 +- .../what-is-traverse-security-model.astro | 2 +- src/pages/roadmap.astro | 2 +- src/pages/security-audit.astro | 340 ++++++++++++++++++ 6 files changed, 353 insertions(+), 4 deletions(-) create mode 100644 src/pages/security-audit.astro diff --git a/src/components/Footer.astro b/src/components/Footer.astro index 2584d46..634b1bd 100644 --- a/src/components/Footer.astro +++ b/src/components/Footer.astro @@ -31,6 +31,7 @@
  • Quickstart
  • CLI Reference
  • All Questions
    • +
  • Security Audit
    • diff --git a/src/components/Nav.astro b/src/components/Nav.astro index 092862a..aa454f9 100644 --- a/src/components/Nav.astro +++ b/src/components/Nav.astro @@ -165,6 +165,13 @@ const { currentPath = '' } = Astro.props; vs function calling, microservices, serverless + + ◎ + + Security Audit + Honest security & permanence status + +
    @@ -197,6 +204,7 @@ const { currentPath = '' } = Astro.props; All Questions Examples Compare + Security Audit Blog Roadmap Changelog diff --git a/src/pages/questions/is-traverse-production-ready.astro b/src/pages/questions/is-traverse-production-ready.astro index 39bd54b..eb197e8 100644 --- a/src/pages/questions/is-traverse-production-ready.astro +++ b/src/pages/questions/is-traverse-production-ready.astro @@ -2,8 +2,8 @@ import QuestionLayout from '@layouts/QuestionLayout.astro'; const relatedLinks = []; -const _body = "

    Traverse v0.7.0 is stable for the local placement target. You can use the local runtime, contract validation, CLI, and MCP server in production today. The project is pre-1.0, which means minor version bumps can include breaking API changes. If you build on Traverse now, pin your version and read the changelog before upgrading.

    \n\n

    What is stable today

    \n \n\n

    What is still maturing

    \n \n\n

    How to evaluate readiness for your use case

    \n

    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.

    \n

    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.

    \n\n

    The pre-1.0 caveat

    \n

    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.

    "; -const _jsonLd = "{\"@context\":\"https://schema.org\",\"@type\":\"FAQPage\",\"mainEntity\":[{\"@type\":\"Question\",\"name\":\"Is Traverse production ready?\",\"acceptedAnswer\":{\"@type\":\"Answer\",\"text\":\"Traverse v0.7.0 is stable for the local placement target. The local runtime, contract validation, MCP server, and CLI are all usable in production today. Other placement targets (browser, edge, cloud, AI pipeline) are in development. The project is pre-1.0, meaning APIs can change between minor versions.\"}}]}"; +const _body = "

    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.

    \n\n

    What is stable today

    \n \n\n

    What is still maturing

    \n \n\n

    Known security gaps

    \n

    A framework-wide audit (July 2026) found the following before recommending any network exposure:

    \n \n

    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.

    \n\n

    How to evaluate readiness for your use case

    \n

    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.

    \n

    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.

    \n\n

    The pre-1.0 caveat

    \n

    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.

    "; +const _jsonLd = "{\"@context\": \"https://schema.org\", \"@type\": \"FAQPage\", \"mainEntity\": [{\"@type\": \"Question\", \"name\": \"Is Traverse production ready?\", \"acceptedAnswer\": {\"@type\": \"Answer\", \"text\": \"Traverse v0.7.0's local runtime and contract validation are stable, but a security audit found the HTTP server defaults to an insecure Development mode and the MCP server has no authentication. Treat network-facing surfaces as pre-production until those gaps close. Other placement targets (browser, edge, cloud, AI pipeline) are in development. The project is pre-1.0, meaning APIs can change between minor versions.\"}}]}"; --- security audit for exact status. The registry stores the binary alongside the contract, so you can audit both. This matters when running third-party capabilities.

    \n\n

    What Traverse does not provide

    \n
      \n
    • Authentication or authorization — who can call a capability is your responsibility
      • \n
    • Network security — the MCP server transport security is your responsibility
      • \n
    • Key management or secret injection into capabilities
      • \n
    • Runtime monitoring or anomaly detection
      • \n
    \n\n

    Traverse gives you a sandboxed, contract-validated execution environment. Layering auth, transport security, and observability on top is your design decision. For a full breakdown of current gaps — including the MCP server's lack of authentication and the HTTP server's insecure default mode — see the security and permanence audit.

    "; const _jsonLd = "{\"@context\":\"https://schema.org\",\"@type\":\"FAQPage\",\"mainEntity\":[{\"@type\":\"Question\",\"name\":\"What is Traverse's security model?\",\"acceptedAnswer\":{\"@type\":\"Answer\",\"text\":\"Traverse runs capabilities inside a WASM sandbox with no host access by default. The contract enforces input and output constraints as hard gates before and after execution. Capabilities cannot reach outside their sandbox unless the host explicitly grants capabilities via WASI imports.\"}}]}"; --- \n\n
    \n Roadmap\n

    Where Traverse is going.

    \n

    This is the public roadmap. It is honest about what ships now, what is next, and what is further out. Nothing moves to planned without an approved governing spec. Nothing ships without test coverage.

    \n
    \n\n
    \n\n \n
    \n
    \n ✓\n

    Shipping now

    \n v0.7.0\n
    \n\n
    \n
    \n
    \n \n
    \n
    \n
    Core runtime
    \n
    Contract validation, WASM execution, trace production. The engine everything else runs on.
    \n
    \n
    \n
    \n
    \n \n
    \n
    \n
    CLI
    \n
    Build, run, validate, and inspect capabilities from the command line.
    \n
    \n
    \n
    \n
    \n \n
    \n
    \n
    MCP server
    \n
    Exposes capabilities as tools for AI agents. Contracts are machine-readable. Traces are queryable.
    \n
    \n
    \n
    \n
    \n \n
    \n
    \n
    Browser adapter
    \n
    Run WASM capabilities in the browser with JavaScript bindings. No round-trip for business logic.
    \n
    \n
    \n
    \n
    \n \n
    \n
    \n
    React demo
    \n
    Working example of browser-side capabilities in a React app.
    \n
    \n
    \n
    \n
    \n \n
    \n
    \n
    Expedition example
    \n
    End-to-end example domain showing contract governance, execution, and tracing in a real scenario.
    \n
    \n
    \n
    \n
    \n \n
    \n
    \n
    9 governing specs
    \n
    Every shipped component has a machine-readable spec. The codebase is navigable by humans and AI agents.
    \n
    \n
    \n
    \n
    \n \n
    \n
    \n
    100% test coverage
    \n
    All shipped code is tested. No exceptions. Every future PR must maintain this.
    \n
    \n
    \n
    \n
    \n\n \n
    \n
    \n →\n

    Next

    \n v0.8.x\n
    \n\n
    \n\n
    \n
    \n
    Edge executor adapter
    \n planned\n
    \n

    Run capabilities at the edge. Same WASM binary, same contract. Cloudflare Workers and similar targets in scope.

    \n executor / edge\n
    \n\n
    \n
    \n
    Python SDK (experimental)
    \n planned\n
    \n

    Call Traverse capabilities from Python. Useful for data pipelines, ML workflows, and teams that do not write Rust.

    \n sdk / python\n
    \n\n
    \n
    \n
    Expanded trace querying
    \n planned\n
    \n

    More expressive queries against trace artifacts. Filter by capability, outcome, contract clause, and time range. CLI and MCP both benefit.

    \n tracing / cli\n
    \n\n
    \n
    \n
    Performance benchmarks page
    \n planned\n
    \n

    Real numbers for real workloads. Contract validation overhead, execution latency by environment, and comparisons against baseline approaches.

    \n docs / perf\n
    \n\n
    \n
    \n
    Additional example domains
    \n planned\n
    \n

    More working examples beyond Expedition. Pricing rules, eligibility checks, validation pipelines. Each one governed by a spec and fully tested.

    \n examples\n
    \n\n
    \n
    \n\n \n
    \n
    \n ⋯\n

    Later

    \n exploring\n
    \n\n
    \n\n
    \n
    \n
    Cloud executor adapter
    \n exploring\n
    \n

    Native cloud deployment for capabilities. AWS Lambda and similar targets. The same binary that runs in browser or at edge, now in cloud.

    \n executor / cloud\n
    \n\n
    \n
    \n
    AI-pipeline placement target
    \n exploring\n
    \n

    First-class support for capabilities that run inside AI pipelines as governed tools. Builds on the MCP foundation with richer placement declarations.

    \n ai / placement\n
    \n\n
    \n
    \n
    Multi-agent orchestration
    \n exploring\n
    \n

    Coordinate multiple agents calling governed capabilities. Conflict prevention via contract constraints. No two agents can violate the same rule in the same execution.

    \n ai / orchestration\n
    \n\n
    \n
    \n
    Governance dashboard
    \n exploring\n
    \n

    Visual interface for exploring capabilities, their contracts, and trace history. Designed for teams that need to audit what ran and why.

    \n observability\n
    \n\n
    \n
    \n
    Extended SBOM tooling
    \n exploring\n
    \n

    Software bill of materials for capabilities. Know exactly what is in each WASM binary, what contracts govern it, and what versions are in production.

    \n security / sbom\n
    \n\n
    \n
    \n
    Device executor
    \n exploring\n
    \n

    Run capabilities on-device. Mobile and embedded targets. The portability story extends all the way to the hardware layer.

    \n executor / device\n
    \n\n
    \n
    \n\n
    \n\n \n
    \n
    Principles that govern this roadmap
    \n
    \n
    \n
    01
    \n
    Spec before code. Every item on this roadmap requires an approved governing spec before any implementation starts. The spec defines what the feature does, what inputs it takes, what constraints apply, and how it integrates with the rest of the system.
    \n
    \n
    \n
    02
    \n
    No feature ships without test coverage. The 100% coverage bar is not a target. It is a floor. Anything that ships must maintain it.
    \n
    \n
    \n
    03
    \n
    Community input is welcome. Have a use case that is not covered? Open an issue on GitHub. Feature requests that come with a clear problem statement and a proposed spec have the best chance of moving forward.
    \n
    \n
    \n
    04
    \n
    Honest sequencing. Items in \"exploring\" are not commitments. They are directions worth thinking about. If circumstances change, the roadmap changes too.
    \n
    \n
    \n
    \n\n\n\n
    \n
    \n
    \n
    Have a feature request?
    \n

    Open an issue on GitHub. A clear problem statement and a proposed spec is the fastest path to getting something on the roadmap.

    \n \n
    \n
    "; +const _body = "
    \n\n
    \n Roadmap\n

    Where Traverse is going.

    \n

    This is the public roadmap. It is honest about what ships now, what is next, and what is further out. Nothing moves to planned without an approved governing spec. Nothing ships without test coverage.

    \n
    \n\n
    \n\n \n
    \n
    \n ✓\n

    Shipping now

    \n v0.7.0\n
    \n\n
    \n
    \n
    \n \n
    \n
    \n
    Core runtime
    \n
    Contract validation, WASM execution, trace production. The engine everything else runs on.
    \n
    \n
    \n
    \n
    \n \n
    \n
    \n
    CLI
    \n
    Build, run, validate, and inspect capabilities from the command line.
    \n
    \n
    \n
    \n
    \n \n
    \n
    \n
    MCP server
    \n
    Exposes capabilities as tools for AI agents. Contracts are machine-readable. Traces are queryable.
    \n
    \n
    \n
    \n
    \n \n
    \n
    \n
    Browser adapter
    \n
    Run WASM capabilities in the browser with JavaScript bindings. No round-trip for business logic.
    \n
    \n
    \n
    \n
    \n \n
    \n
    \n
    React demo
    \n
    Working example of browser-side capabilities in a React app.
    \n
    \n
    \n
    \n
    \n \n
    \n
    \n
    Expedition example
    \n
    End-to-end example domain showing contract governance, execution, and tracing in a real scenario.
    \n
    \n
    \n
    \n
    \n \n
    \n
    \n
    9 governing specs
    \n
    Every shipped component has a machine-readable spec. The codebase is navigable by humans and AI agents.
    \n
    \n
    \n
    \n
    \n \n
    \n
    \n
    100% coverage on core crates
    \n
    traverse-contracts, traverse-registry, and traverse-runtime are coverage-gated in CI. The CLI's HTTP surface and the MCP server are not yet gated — see the security audit.
    \n
    \n
    \n
    \n
    \n\n \n
    \n
    \n →\n

    Next

    \n v0.8.x\n
    \n\n
    \n\n
    \n
    \n
    Edge executor adapter
    \n planned\n
    \n

    Run capabilities at the edge. Same WASM binary, same contract. Cloudflare Workers and similar targets in scope.

    \n executor / edge\n
    \n\n
    \n
    \n
    Python SDK (experimental)
    \n planned\n
    \n

    Call Traverse capabilities from Python. Useful for data pipelines, ML workflows, and teams that do not write Rust.

    \n sdk / python\n
    \n\n
    \n
    \n
    Expanded trace querying
    \n planned\n
    \n

    More expressive queries against trace artifacts. Filter by capability, outcome, contract clause, and time range. CLI and MCP both benefit.

    \n tracing / cli\n
    \n\n
    \n
    \n
    Performance benchmarks page
    \n planned\n
    \n

    Real numbers for real workloads. Contract validation overhead, execution latency by environment, and comparisons against baseline approaches.

    \n docs / perf\n
    \n\n
    \n
    \n
    Additional example domains
    \n planned\n
    \n

    More working examples beyond Expedition. Pricing rules, eligibility checks, validation pipelines. Each one governed by a spec and fully tested.

    \n examples\n
    \n\n
    \n
    \n\n \n
    \n
    \n ⋯\n

    Later

    \n exploring\n
    \n\n
    \n\n
    \n
    \n
    Cloud executor adapter
    \n exploring\n
    \n

    Native cloud deployment for capabilities. AWS Lambda and similar targets. The same binary that runs in browser or at edge, now in cloud.

    \n executor / cloud\n
    \n\n
    \n
    \n
    AI-pipeline placement target
    \n exploring\n
    \n

    First-class support for capabilities that run inside AI pipelines as governed tools. Builds on the MCP foundation with richer placement declarations.

    \n ai / placement\n
    \n\n
    \n
    \n
    Multi-agent orchestration
    \n exploring\n
    \n

    Coordinate multiple agents calling governed capabilities. Conflict prevention via contract constraints. No two agents can violate the same rule in the same execution.

    \n ai / orchestration\n
    \n\n
    \n
    \n
    Governance dashboard
    \n exploring\n
    \n

    Visual interface for exploring capabilities, their contracts, and trace history. Designed for teams that need to audit what ran and why.

    \n observability\n
    \n\n
    \n
    \n
    Extended SBOM tooling
    \n exploring\n
    \n

    Software bill of materials for capabilities. Know exactly what is in each WASM binary, what contracts govern it, and what versions are in production.

    \n security / sbom\n
    \n\n
    \n
    \n
    Device executor
    \n exploring\n
    \n

    Run capabilities on-device. Mobile and embedded targets. The portability story extends all the way to the hardware layer.

    \n executor / device\n
    \n\n
    \n
    \n\n
    \n\n \n
    \n
    Principles that govern this roadmap
    \n
    \n
    \n
    01
    \n
    Spec before code. Every item on this roadmap requires an approved governing spec before any implementation starts. The spec defines what the feature does, what inputs it takes, what constraints apply, and how it integrates with the rest of the system.
    \n
    \n
    \n
    02
    \n
    No feature ships without test coverage. The 100% coverage bar is not a target. It is a floor. Anything that ships must maintain it.
    \n
    \n
    \n
    03
    \n
    Community input is welcome. Have a use case that is not covered? Open an issue on GitHub. Feature requests that come with a clear problem statement and a proposed spec have the best chance of moving forward.
    \n
    \n
    \n
    04
    \n
    Honest sequencing. Items in \"exploring\" are not commitments. They are directions worth thinking about. If circumstances change, the roadmap changes too.
    \n
    \n
    \n
    \n\n
    \n\n
    \n
    \n
    \n
    Have a feature request?
    \n

    Open an issue on GitHub. A clear problem statement and a proposed spec is the fastest path to getting something on the roadmap.

    \n \n
    \n
    "; --- ({ Critical: 'sev-critical', High: 'sev-high', Medium: 'sev-medium', Low: 'sev-low' }[s] || 'sev-low'); + +const jsonLd = JSON.stringify({ + '@context': 'https://schema.org', + '@type': 'TechArticle', + headline: 'Traverse Permanence & Security Audit', + description: 'Full-framework analysis of durability/determinism guarantees and security risk vs opportunity in Traverse.', + datePublished: '2026-07-01', + author: { '@type': 'Organization', name: 'Traverse Framework' }, +}); +--- + + + +
    +
    +
    + Security & Permanence +

    Traverse Permanence & Security Audit

    +

    Full-framework analysis of durability/determinism guarantees and security risk vs. opportunity.

    +

    Source: specs, crates, CI gates, SECURITY.md · July 2026

    +
    +
    + +
    +
    +
    + Verdict: Traverse has a strong specification and governance layer, but is correctly labeled pre-production. Security controls are partially implemented with dangerous defaults (dev mode, unverified JWTs, stub Sigstore). Permanence is strongest for immutable specs and Ed25519 artifact signing; weakest for durable audit, long-retention replay, and identity-bound event evidence. +
    + +
    +
    2
    Critical findings
    +
    4
    High findings
    +
    7
    Medium findings
    +
    2
    Low / info
    +
    52
    Approved specs
    +
    6
    Workspace crates
    +
    3/6
    Coverage-gated crates
    +
    + +
    +

    Spec vs. implementation readiness

    +

    Isolation (WASM sandbox + WASI deny-by-default) is specified, implemented, and close to production-ready. CI gates (coverage, supply-chain, contractual checks) are specified and implemented for 3 of 6 crates, but not production-ready across the workspace — the CLI's ~9k-line HTTP surface and the MCP server both ship outside the coverage gate.

    +
    + +
    +

    Findings register

    +
    + + + + {findings.map((f) => ( + + + + + + + ))} + +
    SeverityDomainLocationFinding
    {f.sev}{f.domain}{f.loc}{f.finding}
    +
    +
    + +
    +

    Permanence guarantee matrix

    +

    What the framework claims to keep durable, deterministic, or attributable — vs. what code actually preserves across process restart and time.

    +
    + + + + {permanenceMatrix.map((r) => ( + + + + + + + ))} + +
    GuaranteeSpecifiedImplementedGap
    {r.g}{r.spec}{r.impl}{r.gap}
    +
    +
    + +
    +

    Security & permanence strengths

    +
    +
    +

    Security strengths

    +
      +
    • Ed25519 artifact verification is real and deterministic
      • +
    • WASM deny-by-default WASI + ABI import CI gate
      • +
    • Draft contract quarantine at execution boundary
      • +
    • HTTP workspace auth, scopes, audit JSONL (partial)
      • +
    • Supply-chain CI: lockfile, SBOM, reproducible build checks
      • +
    • No production unsafe; hot paths largely avoid unwrap/panic
      • +
    +
    +
    +

    Permanence strengths

    +
      +
    • Approved specs marked immutable in governance registry
      • +
    • Cursor replay + duplicate event_id suppression (036)
      • +
    • Private traces hash inputs/outputs (no raw I/O leakage)
      • +
    • Semver progression and contractual enforcement gates
      • +
    • Expedition WASM path is a deterministic vertical slice
      • +
    • LocalFileDataStore provides basic on-disk persistence
      • +
    +
    +
    +
    + +
    +

    Crate maturity & blast radius

    +
    + + + + {crates.map((c) => ( + + + + + + + ))} + +
    CrateMaturityCoverageRisk signal
    {c.name}{c.maturity}{c.coverage}{c.risk}
    +
    +
    + +
    +

    Opportunity roadmap

    +

    Ranked by risk reduction per effort. P0 items close exploit paths that contradict approved specs 030/031 today.

    +
    + + + + {roadmap.map((r) => ( + + + + + + ))} + +
    OpportunityWhy it mattersEffort
    {r.p}{r.why}{r.effort}
    +
    +
    + +
    +

    Trust boundary map

    +
    +
    +

    HTTP API (serve)

    +

    Broadest attack surface. Dev defaults, unverified JWT, optional unauthenticated mode. Also the richest permanence surface (registration, traces, sessions).

    +
    +
    +

    MCP stdio

    +

    Implicit local trust only. Full execute + trace export with no credential check. Safe as an IDE child process; unsafe if redirected or remotely bridged.

    +
    +
    +

    WASM guest

    +

    Wasmtime isolation + WASI deny-by-default is solid. Host ABI whitelist exists but traverse_host::* functions are not linked yet.

    +
    +
    +

    Artifact / supply chain

    +

    Ed25519 works. Sigstore and checksum gates are incomplete. Publish/sync trusts the external registry path before extraction completes.

    +
    +
    +
    + +
    +

    Recommended next moves

    +
      +
    1. 1

      Treat all network-facing surfaces as non-production until JWT crypto verification and Production-default security ship.

      2. +
    2. 2

      Add a durable event/audit journal if compliance or multi-restart recovery is a product requirement — in-memory 5-minute replay is not permanence.

      3. +
    3. 3

      Close governance holes: approve or decouple spec 022; coverage-gate CLI/MCP; finish or explicitly defer specs 051/057–059.

      4. +
    +
    + +
    +

    Key evidence

    +

    crates/traverse-runtime/src/security.rs · crates/traverse-cli/src/http_api.rs · crates/traverse-mcp/src/stdio_server.rs · crates/traverse-runtime/src/events/broker.rs · specs/030, 031, 036 · SECURITY.md

    +
    +
    +
    + +
    +
    +
    +
    +
    See where Traverse actually stands.
    +

    Read the honest production-readiness breakdown, or dig into the governing specs yourself.

    +
    + +
    +
    +
    +