Skip to content

roadmap.md

Latest commit

 

History

History
193 lines (139 loc) · 18.5 KB

roadmap.md

File metadata and controls

193 lines (139 loc) · 18.5 KB
Raw

Roadmap

This roadmap describes what Boruna is working toward. It is realistic, not aspirational marketing. Items without a milestone are under consideration but not scheduled.

Last refreshed: 2026-05-17 (after the v1.4.0 release).

v3.0.0 — HTTP / distributed layer removed

As of v3.0.0, Boruna's entire HTTP / serving / distributed-execution layer has been removed: the distributed coordinator, distributed workers, active-active HA, and coordinator mTLS; the three web UIs (workflow dashboard, evidence web viewer, approval console); the serve cargo feature and its server dependencies; and the coordinator, dashboard, worker, and evidence serve CLI commands plus the --coordinator / --coord-token flags.

Boruna is now a local deterministic engine + CLI. The historical 0.4.0 / 0.5.0 milestones below record distributed-execution work that shipped at the time and has since been removed — they are retained as history, not as descriptions of current capabilities. Approval and external-trigger gates remain, handled locally via boruna workflow approve/reject/trigger plus resume.

Current: 1.4.0 — SHIPPED (2026-05-17)

Workspace version is 1.4.0. Fourth feature minor on the 1.x LTS line. Agent-native CLI inspection surfaces (boruna doctor, boruna size, boruna workflow graph, boruna lang codes, boruna skills — all --json-capable, motivated by a competitive review of vercel-labs/zero); the boruna-lsp language server for .ax files (diagnostics, completion, formatting); three compliance example workflows (SOC 2 audit, HIPAA data pipeline, financial review). See the CHANGELOG for the full list.

Previous: 1.3.0 — SHIPPED (2026-04-30)

Workspace version was 1.3.0. Third feature minor on the 1.x LTS line. 27 new __builtin_* functions (string, list, and map operations); import resolution wired end-to-end (import "std-name" inlines libs/<name>/src/core.ax at compile time); evidence inspect now shows step output content for plaintext bundles (500-char preview in text mode, full "step_outputs" in --json); std-llm and std-json graduated to 1.0-stable (all 13 stdlib packages are now stable); std-json gains json_array, fixed int_to_string and json_escape; std-validation gains validate_contains, validate_starts_with, validate_ends_with. See the CHANGELOG for the full list.

Previous: 1.2.0 — SHIPPED (2026-04-29)

Workspace version was 1.2.0. Second feature minor on the 1.x LTS line. All 11 original std-* packages graduated to 1.0-stable; improved error messages and lang repair; compliance templates, model eval, and LSP MVP landed as future-track work. See the CHANGELOG for the full list.

Previous: 0.3.0

Released 2026-04-26 — closes every big-rock theme on the original 0.3.0 plan: persistent workflow state (crash-resumable), concurrent step execution within waves, step retry policies, idempotent invocation, workflow versioning for CI/CD safety, the LLM-handler decision (BYOH), per-step attempt tracking with the project's first schema migration, workflow step output piping via the step_input builtin, and async step execution via the external-trigger CLI for webhook-driven workflows. Plus review-driven safety work (atomic trigger-commit closing a TOCTOU race; SSRF-hardened real HTTP handler).

See CHANGELOG.md for the full 0.3-S2a → 0.3-S16 sprint stack.

Previous: 0.2.0

Released 2026-04-25 — driven by FleetQ implementer feedback. Closes the two P0 adoption blockers; other P1/P2 asks tracked as issues #3–#9.

What shipped:

  • Fine-grained capability policy in MCP boruna_run — accepts a structured Policy object (per-capability allow/budget rules, allowlist vs. denylist mode, NetPolicy with allowed_domains / methods / byte limits / timeout), in addition to the legacy "allow-all" / "deny-all" strings. Documented JSON Schema 2020-12 at docs/reference/policy.schema.json. Breaking (MCP only): unknown policy values now return error_kind: "invalid_policy" instead of silently treating them as "allow-all".
  • Multi-target static binary releases on every v* tag: x86_64-unknown-linux-musl, aarch64-unknown-linux-musl, x86_64-apple-darwin, aarch64-apple-darwin, plus combined SHA256SUMS. Linux builds are musl so they run on Alpine and other libc-minimal distros.
  • docs/releasing.md — release process and verification.

What did NOT ship from the original 0.2.0 plan (deferred to 0.2.x or 0.3.0):

  • boruna new interactive scaffold
  • boruna fmt auto-formatter
  • Watch mode (boruna run --watch)
  • Improved error messages with suggested fixes for all common mistakes
  • Better lang repair coverage
  • Evidence bundle diff
  • Workflow step output piping
  • std-llm, std-json library expansion

These were displaced by the FleetQ adoption work. They are still on the path to v1 — see 0.2.x and 0.3.0 below.

0.2.x — Developer experience patch lane

Target: rolling, May–July 2026

The DX work originally scoped for 0.2.0 ships incrementally as point releases. Each is small, additive, and non-breaking.

  • boruna new — scaffold a new workflow from a template interactively (sprint W3-C)
  • boruna fmt — auto-formatter for .ax files (v1: post1-T-1.3; v2 comment-preserving: post1/fmt-v2 PR #45)
  • boruna run --watch — re-run on file change (post1-T-1.4)
  • Improved error messages — boruna lang check now suggests nearest variable/function name for E003/E004 errors (edit-distance-1), type-conversion hints for E009, improved message text for E001/E002/E007 (post1/improved-diagnostics-repair)
  • Better lang repair — handles E003/E004 near-miss rename patches; bottom-up patch ordering prevents offset corruption; new Conservative strategy applies only high-confidence (≥80%) patches (post1/improved-diagnostics-repair)
  • Evidence bundle diff — boruna evidence diff <bundle-a> <bundle-b> (post1/evidence-diff, PR #44)
  • Expanded stdlib — std-llm, std-json libraries (post1/std-new-packages PR #46)

0.3.0 — Real-use durability — SHIPPED (2026-04-26)

Focus: workflows that survive process restarts, handle long-running steps, and unblock production use cases. Combined original 0.3.0 plan with two FleetQ P1 asks that fit thematically.

  • Persistent workflow state — checkpoint and resume across process restarts (0.3-S2a/S2b/S3/S6)
  • Async step execution — steps that wait for external events via webhook-driven CLI trigger (0.3-S15); approval gates (0.3-S2c)
  • Step retry policies — configurable retry with backoff on transient failures (0.3-S5)
  • Workflow versioning — --expect-workflow-hash for CI/CD safety (0.3-S9)
  • Workflow step output piping — step_input builtin (0.3-S14)
  • Structured resource limits with typed errors (#5) — max_memory_mb, max_wall_ms, max_output_bytes (0.3-S10)
  • Versioned capability identity (#3) — boruna_capability_list returns capability_set_hash for safe caching
  • LLM live handler decision — DECIDED (sprint 0.3-S8): Bring Your Own Handler (BYOH). No default LLM handler ships in core; integrators wire their provider via the CapabilityHandler trait. Rationale + integration contract + reference OpenAI handler in docs/guides/llm-integration.md.
  • Concurrent step execution within waves — --concurrency N (0.3-S4)
  • Idempotent invocation — --skip-if-running for cron-driven scheduling (0.3-S7/S10)
  • Per-step attempt tracking with first schema migration v1→v2 (0.3-S11/S12/S13)
  • Atomic trigger commit closing TOCTOU race (0.3-S16, review-driven)
  • Scheduled workflows — trigger workflows on a cron schedule (deferred to 0.3.x; partially addressed by --skip-if-running for safe cron invocation) — boruna workflow schedule <dir> --cron "..." cron daemon (post1/scheduler-registry-rolling)

0.4.0 — Operations (mostly shipped on master, tag pending)

Originally targeted Q4 2026; landed early as 0.4-S1 → 0.4-S16 + 0.5-S1 → 0.5-S2f. Tag will be cut after auth (0.5-S3) lands.

  • Distributed step execution — coord+workers HTTP cluster + multi-wave advancement (0.5-S2a → 0.5-S2f)
  • Workflow dashboard — Axum + askama SSR (0.4-S16); merged into the coordinator listener (0.5-S2d)
  • Prometheus metrics endpoint — /metrics route + per-run-status counters (0.4-S?)
  • OpenTelemetry observability (#9) — per-capability OTLP spans (0.4-S5)
  • Policy management as code — Policy JSON files + boruna policy validate (0.4-S?)
  • Multi-environment support — --env flag + namespaced data-dir + Prometheus env= label (0.4-S14)
  • Streaming output from boruna_run (#4) — periodic progress events + capability call markers (post1-T-1.1, post1-T-2.2)
  • LLM provider registry — config-driven provider selection via --providers providers.json; ProviderRegistry validates config + logs intent (post1/scheduler-registry-rolling)
  • Scheduled workflows (carried over from 0.3.x) — full cron daemon via boruna workflow schedule (post1/scheduler-registry-rolling)

0.5.0 — Distributed execution + spec freeze

Target: ~Q3-Q4 2026 (accelerated from original Q1 2027 target).

Two sub-themes: (a) finish what 0.5-S2* started so distributed mode is production-grade, (b) lock the API surface for 1.0.

(a) Distributed-execution closure

  • workflow run --submit-only + coordinator wait — end-to-end multi-wave (0.5-S2e/f)
  • 0.5-S3 — Authentication — shared-secret bearer token. MUST land before any non-loopback bind is recommended. Gating for production deployments.
  • W6-A — mTLS + per-worker client certificates — additive opt-in mTLS surface on the coord HTTP routes. Cert subject CN drives worker identity; mismatch returns coord.identity_mismatch. Bearer auth path remains unchanged for LTS compatibility. See docs/design-coord-mtls.md.
  • 0.5-S4 — workflow run --coordinator <url> — combines submit + wait in one command for CI workflows
  • 0.5-S5 — Distributed retry policies — wires RetryPolicy through the wait driver so failed steps with retry budget transition Failed → Pending instead of permanent Failed
  • 0.5-S6 — Distributed approval-gate / external-trigger — generalizes the operator-bridge protocol from 0.3-S15 to work in distributed mode
  • 0.5-S7 — Output blob references — large step outputs (>64 KiB) stored in content-addressed blob store; inline/blob routing in runner; BlobStore read-side restore (post1/output-blob-refs)
  • Coordinator HA / failover (sprint W2) — multi-coord active-active against shared SQLite, worker URL failover at registration, /api/health for LB probes. The ADR 002 "coord restart = all leases void" assumption was audited and confirmed already-safe (threshold-based sweep preserves healthy leases under concurrent coords).
  • Worker capability tagging / placement (sprint W3-A) — workers advertise a SUBSET of the coord's capability set via --advertise-caps; coord filters claims to caps the worker covers. Backwards-compatible (omitted flag = full fleet). New coord.unknown_capability error_kind.
  • Blob GC sweep (sprint W3-B) — boruna evidence gc-blobs reclaims orphan blobs in <data-dir>/blobs/. Closes the 0.5-S7 accepted limitation around manual cleanup.
  • Rolling upgrades — per-capability version negotiation via --advertise-cap-versions cap=ver; coordinator filters by version compatibility (post1/scheduler-registry-rolling)

(b) Spec freeze

  • Stable, documented MCP tool response schemas (#6) — protocol_version: 1 (0.5-S4 of FleetQ track)
  • Output JSON Schema validation as first-class gate (#8) (0.5-S6 of FleetQ track)
  • Record/replay for net.fetch (#7) (0.5-S7 of FleetQ track)
  • Versioned .ax language specification — formal grammar, type rules, capability semantics. Each future release publishes against a language_version. (Sprint W1-B, docs/spec/ax-language-1.0.md, boruna_compiler::LANGUAGE_VERSION = "1.0".)
  • Versioned workflow DAG schema — JSON Schema for workflow.json with schema_version field; backwards-compatible parser. (sprint W4; spec at docs/spec/workflow-dag-1.0.md, boruna_orchestrator::WORKFLOW_DAG_SCHEMA_VERSION = 1.)
  • Versioned evidence bundle format — schema for the bundle directory contents, format_version field, forward-compat reader. Shipped sprint W1-C; spec at docs/spec/evidence-bundle-1.0.md.
  • Versioned bytecode format — opcode discriminants, value model, capability ID table, module wire format, determinism contract. Shipped sprint W9-A; spec at docs/spec/bytecode-1.0.md, boruna_bytecode::BYTECODE_VERSION = "1.0".
  • Migration tooling beta — boruna migrate <from-version> upgrade path for any pre-1.0 breaking change. (sprint W5-C)

1.0.0 — Production readiness — SHIPPED (2026-04-28)

Milestone: the stable API surface is locked. 0.5+ programs compile and run unchanged. This is mostly a commitment release, not a feature release — the engineering between 0.5 and 1.0 is small but the durability promise is large.

  • Security audit of the VM and capability enforcement (external auditor; bookable months in advance — must commit Q4 2026 to land Q2 2027)
  • Performance benchmarks — published baseline for compile time, step throughput, evidence bundle write/verify time (sprint W5-A; see PERFORMANCE.md)
  • Long-term support commitment for 1.x — backports for security fixes, deprecation policy (sprint W5-B; see lts.md)
  • Migration tooling — boruna migrate covering pre-1.0 breaking changes (sprint W5-C)
  • All schemas (language, DAG, evidence, bytecode) finalized and documented
  • Evidence bundle encryption — at-rest encryption for bundles containing sensitive data (sprint W6-B, AES-256-GCM envelope encryption; see docs/design-bundle-encryption.md)

Previous: 1.1.0 — SHIPPED (2026-04-29)

First minor release on the 1.x LTS line. All changes are additive — no breaking changes.

  • MCP streaming capability call markers — boruna_run progress notifications carry "cap: llm.call" or "caps: llm.call, net.fetch" when capability calls fire during a VM slice. Gives MCP clients real-time visibility into what the VM is executing (post1-T-2.2).
  • Evidence bundle web inspector — boruna evidence serve <bundle-dir> [--port N] opens a local axum HTTP server with bundle overview, hash-chained audit log, and per-step output accordion. Verification runs inline. Feature-gated (boruna-cli/serve). Experimental tier (post1-T-4.4).
  • Trivia-in-AST foundation — new lex_full(source) API returns tokens with leading_trivia (attached // comments). Foundation for the comment-preserving boruna fmt v2 formatter. Existing lex() is unchanged. Experimental tier (post1-T-2.5).
  • BYOH reference handler library — four new CapabilityHandler reference implementations in examples/llm_handlers/: Anthropic Messages API, Ollama, vLLM/OpenAI-compatible, AWS Bedrock skeleton. Each is ~80–120 LOC, copy-and-tweak, no Cargo dep (post1-T-1.2).
  • BundleStorage adapters stable — S3, GCS, and Azure Blob adapters promoted from #[doc(hidden)] to stable public API. StorageError marked #[non_exhaustive]. New boruna evidence rotate-kek command re-encrypts DEKs under a new key-encryption key without touching ciphertext (post1-T-3.1–3.3, T-4.3).

What we need to decide now (before 0.3.0 starts)

These decisions block downstream planning. None of them are urgent today, but each one becomes urgent within 1–2 quarters.

  1. Security audit booking — pick auditor, scope, budget by Q4 2026. A real audit costs $30–100k and books months in advance. If this slips past Q4 2026, v1.0.0 slips with it.
  2. LLM live handler shipping plan — decided (0.3-S8): Bring Your Own Handler. See docs/guides/llm-integration.md.
  3. Persistence storage backend — decided (ADR 001): sqlite, no abstraction trait. Shipped via 0.3-S2a/S2b/S3/S6.
  4. Dashboard scope and tech — full SSR Rust stack (Axum + askama, fits the project) vs. SPA (more work, more polish). 0.4.0 dashboard depends on this answer.

Future / under consideration

These items are on the long-term radar but not scheduled:

  • Commercial platform: hosted workflow execution, managed evidence storage, SSO, RBAC, compliance reporting — built on the open source core.
  • IDE integration: language server (LSP) for .ax syntax, completion, and diagnostics in VS Code / Neovim (boruna-lsp MVP: diagnostics, completion, formatting — future/lsp).
  • Model evaluation framework: run the same workflow against multiple LLM providers and compare evidence bundles. (boruna workflow eval — future/model-eval)
  • Compliance templates: pre-built workflow patterns for common regulated use cases (SOC 2, HIPAA, financial audit — future/compliance-templates).
  • Cross-language FFI: call into Rust/Python libraries from .ax through a typed capability interface.

What is intentionally out of scope

Boruna will not become:

  • A general-purpose programming language (use Rust, Python, etc. for that)
  • An LLM framework (use LangChain, LCEL, etc. for that)
  • A cloud provider (Boruna runs where you deploy it)
  • A no-code tool (Boruna is for engineers)

Tracking

See also: Stability, Limitations, Releasing