Where Xianyun is headed

Xianyun (閑雲, pinyin Xián Yún — “idle cloud”) started as a Rust rewrite of Caproni, a command-line tool that orchestrates local Kubernetes development environments. The rewrite isn’t just a language swap. It’s aimed at a specific, narrower job than “general dev environment tool”: being a developer-focused validation tool and verification driver, with AI agents as a first-class caller, not an afterthought.

The lineage: Caproni already pointed this way

Caproni’s own documentation already frames its core value this way — see the use-cases page in Caproni’s documentation: spinning up an ephemeral, Helm-deployed instance to validate features, reproduce bugs, or demo workflows, with environment configuration that’s sharable rather than hand-assembled each time.

Xianyun keeps that framing and sharpens it. Where Caproni is a tool a developer runs, Xianyun is a tool built so a verification loop — human or agentic — can run it, read structured output back, and decide what to do next, repeatedly, without a human parsing terminal text in the middle every time.

What “AI agent-first” means concretely

This isn’t a marketing label. It constrains real design decisions:

• Typed, structured results over ad-hoc text. Where Caproni’s Go code paths some results through free-text log lines, the Rust port favors Result<T, E> with specific error variants an agent (or a human-written script) can match on, not a string to grep.
• Real concurrency primitives, not best-effort goroutines. xianyun run’s reloader-supervision engine, for example, uses tokio:: task::JoinSet specifically for its join-before-return guarantee — a verification driver that can’t be sure every supervised process actually finished before reporting success is not trustworthy for an agent to build a decision on.
• A real test-first compatibility contract. Every ported behavior has a test proving the same contract the Go original’s test proved, not just “it compiles and seems to work.” An agent-first tool for validation has to itself be validated to that standard, or it’s not fit for the job it claims to do.
• Config and CLI compatibility as a floor, not a ceiling. Existing caproni.yaml projects work against Xianyun unmodified (see Caproni compatibility) — migration cost for existing users is zero, so adopting Xianyun for agent-driven workflows doesn’t require re-authoring every project’s config first.

What this doesn’t mean (yet)

This vision statement describes intent, not a finished feature set. Xianyun now has an MCP server, crates/xianyun-mcp, that exposes an allowlisted subset of the command tree to agents (see ADR-0005), but it doesn’t yet have a structured machine-readable output mode across every command: only registry status offers -o json. The porting work tracked in each crate’s PORT_NOTES.md is about reaching behavioral parity with Caproni first, and parity isn’t complete (the spec lists the open gaps). Structured output across the CLI is a deliberate next phase once parity is solid, not something to half-build alongside it.

See also

• crates/README.md — the Rust workspace layout, naming, and per-crate porting status.
• macOS notes — the small, explicitly-deferred macOS-only slice of the port.
• Use cases — the validation, development, and test-environment framing this vision extends. It comes from Caproni’s use-case pages, which are in the upstream repository.