One topology, swappable engines

Backend CLIs ship weekly and change their machine output without notice. cadora doctor checks each backend binary is present and its version falls inside the range the adapter contract was last verified against — offline, no model calls. Verified engines (claude, codex, kiro) carry a tested range; experimental ones (glm, antigravity) run, but aren't in the release smoke yet.

Outside-range is a warning (untested — it usually still works); missing or unparsable is the hard signal. Exit stays 0 while at least one live backend is usable, so cadora doctor drops straight into CI. Add --json for the structured report.

Point --executor at any engine and the entire run executes there. Every node runs on Codex, the build gate re-runs for real, and per-node cost is attributed to codex in the archive — the same manifest shape you'd get from Claude Code.

The run header reads executor=codex; funding= appears only for Claude Code (its subscription-vs-api token). Cost is attributed per node to the engine that ran it — dollar figures here are illustrative (est.).

Design on one engine, build on another — in a single run. --construction-executor routes construction-phase nodes to a second backend while inception and operations nodes stay on --executor. Here the three design nodes run on Claude Code and the three code nodes on Codex, each node stamped with the engine that ran it. One conductor, one archive, one verdict.

Routing is by phase — inception and operations stay on --executor; only construction moves to --construction-executor. The split is invisible downstream: gates, integrity, and cost attribution treat a two-engine run exactly like a one-engine run.

--executor <name> resolves through a small registry — one class per engine, each implementing the same NodeExecutor contract: run(node, prompt, cwd) → ExecutionResult. Adding an engine is a one-class change; nothing else in Cadora knows which backend ran. get_executor(name) forwards only the kwargs a backend accepts, so --funding reaches Claude Code and is quietly ignored elsewhere.

Ask for an engine that isn't there and the registry is the allow-list: unknown executor 'x'; choose from ['antigravity', 'claude', 'codex', 'fixture', 'glm', 'kiro'].

The differentiator no single vendor ships: run the same topology through two backends and diff outcome and cost per node. cadora compare reads two archived manifests and lines them up — pass/fail, model, and cost, node by node — so “we switched engines” becomes a measured claim, not a guess.

Same topology, same gates, both green — the diff is purely engine economics (figures illustrative, est.). cadora compare is its own capability; this is just where multi-backend pays off.

This is the whole point of a vendor-neutral conductor. Whichever engine ran — or a mix — the audit surface is identical: the same deterministic gates re-run the real build, the same toolchain-integrity checks, the same tamper-evident evidence pack, the same per-node cost attribution. Swapping engines changes the bill and maybe the speed. It never changes the shape of the proof.