Arising from int-0002 — Zero-ceremony operation — one binary, no server, no daemon
Go, not Elixir/OTP, despite kazi's stack
kazi is Elixir/OTP (ADR-0003, `docs/adr/0003-language-elixir-otp.md`), with a Burrito + Homebrew-tap + release-please distribution pipeline already built and proven — `kazi-org/homebrew-tap` and the `kazi-org/burrito` fork exist. Reusing that stack would mean free CI and free distribution, which is a real cost saving and the strongest argument against this decision.
It loses anyway, because the two tools have opposite runtime shapes. kazi is a long-running controller supervising concurrent convergence runs — OTP is the right answer. dira is invoked from `SessionStart`, `Stop`, and `PreCompact` hooks, several times a session, and the human is blocked on it. A brief that takes 300ms to render gets removed from the hook config within a week, and then int-0001 fails for mechanical reasons rather than design ones.
What is actually forfeited and must be rebuilt: goreleaser instead of Burrito, a second formula in the existing `kazi-org/homebrew-tap`, and a separate release workflow. That is a few days of setup, paid once, against a latency budget paid on every single invocation forever.
Overruling this is a one-line supersede — the alternative is recorded above with its own revisit condition, which is the point of writing it this way.
Alternatives on record — 4
✗Elixir/OTP, reusing kazi's Burrito + Homebrew tap + release-please pipelinerefused dira is a short-lived, hook-invoked CLI that runs several times per session in the latency path of a human waiting on a prompt.
BEAM start-up is tens to hundreds of milliseconds before any work happens, and a Burrito-wrapped binary also pays a first-run unpacking cost. OTP's actual value — supervision trees, long-lived processes, distribution, fault isolation across concurrent runs — is exactly what kazi needs as a convergence controller, and exactly what dira has no use for: dira starts, reads files, prints, and exits. Paying BEAM's start-up cost for a process with no concurrency and no uptime is paying for the one thing that does not apply.
revisit ifdira grows a genuinely long-lived component — a watch daemon or a hosted multi-tenant service — at which point that component alone could be Elixir without changing the CLI
✗Rustrefused Equivalent start-up and single-binary story to Go, with better guarantees, but slower to write and a smaller pool of contributors for an OSS tool that wants drive-by PRs.
Go's stdlib covers everything dira needs (files, JSON/YAML, an embedded HTTP server for `dira ui`, SQLite via a single dependency).
revisit ifnever on performance grounds; only if the team's expertise shifts
✗A shell script or Pythonrefused Shell cannot carry the query engine or the storage interface (dec-0005).
Python reintroduces a runtime to install, breaking the one-binary promise of int-0002 — and its start-up is no better than BEAM's for this workload.
✗A TypeScript CLI on Node/Bunrefused Node start-up is in the same range as BEAM; Bun fixes that but ships a large binary and a young ecosystem for a tool meant to be boring infrastructure.
Node start-up is in the same range as BEAM; Bun fixes that but ships a large binary and a young ecosystem for a tool meant to be boring infrastructure.