Modernizing VistA development on the VA's Health Cloud.

vista-cloud-dev is an ecosystem of composable tools that bring present-day software engineering — version control, unit testing, linting, formatting, an IDE language server, and AI-agent surfaces — to VistA, the VA's health information system.

VistA is built using the M application database that runs on Intersystems IRIS, which is the same M-based platform and technology that all Epic healthcare systems use worldwide. Beyond the common core technology as Epic, all VistA systems have been migrated to a single integrated cloud platform provided by Amazon Web Services, enabling the next generation of cloud-based AI-driven healthcare innovation and services. For information on the VistA Health Cloud see https://cloudvista.github.io.

vista-cloud-dev is built for both IRIS and YottadB database engines and is open to the community. The work is under active development — interfaces are stabilizing but not yet at a tagged stable release.

The guiding principle is simple:

Git is the source of truth; the database is just the engine.

You write .m files in git, sync them into a running IRIS (or YottaDB) instance, test against the live engine, and pull changes back — instead of treating the database as the place source code "lives."

• New here? Read docs — the modernization strategy, the m-cli spec, and the toolchain dependency map (the why behind everything below).
• Setting up a machine? Clone the org via workspace — ./bootstrap.sh clones every repo and checks out the right branches.
• Want the tool? m-cli is the m command; its README has install + first-run instructions.
• Want to help? See Contributing.

• Why this exists
• The four capabilities
  • 1 · Version control
  • 2 · Modern testing
  • 3 · M-aware IDE
  • 4 · The standard library
• Architecture at a glance
• The components
  • Strategy & documentation
  • The M toolchain (host-side, Go)
  • The IRIS / VistA source bridge
  • The M runtime library
  • Agent & intelligence surfaces
  • Coordination & scaffolding
• The m command surface
• Design principles
• Contributing
• Shared CI

VistA is one of the largest and longest-lived production codebases in the world, but M development has historically lacked the everyday tooling other ecosystems take for granted. VA's migration of VistA onto IRIS — inside the FedRAMP-HIGH VA Enterprise Cloud (AWS GovCloud) — is an opportunity to close that gap. vista-cloud-dev supplies four things M developers don't have today:

Everything is engine-neutral where it can be (works on YottaDB and IRIS) and engine-specific only where it must be (the IRIS source boundary).

Each gap above, as a flow.

Two things get version-controlled: individual routines and whole KIDS patches.

Routines — m pull / m push round-trips M code between IRIS and .m files on the filesystem, which version-control through GitHub like any other code.

flowchart LR
    gh["GitHub"]
    fs["m routines"]
    iris[("IRIS<br/>VistA database")]
    gh <-->|git pull / push| fs
    fs <-->|m pull / m push| iris

Patches — kids-vc decomposes a monolithic .KID patch into its components (routines, FileMan data dictionaries, …) so they can be diffed and stored in GitHub, and assembles them back into an installable .KID that is pushed into IRIS.

flowchart LR
    gh["GitHub"]
    comps["patch components"]
    kid[".KID patch<br/>(assembled)"]
    iris[("IRIS<br/>VistA database")]

    gh <-->|git pull / push| comps
    kid -->|m kids decompose| comps
    comps -->|m kids assemble| kid
    kid -->|install| iris

Write a *TST.m suite first, run it with m test against the live engine via ^STDASSERT, and get machine-readable results plus coverage.

flowchart TB
    tst["*TST.m suite<br/>(written test-first)"]
    tst -->|m test| runner["m test runner"]
    runner -->|executes on| engine[("YottaDB / IRIS engine")]
    engine -->|"^STDASSERT pass / fail"| report["TAP / JUnit report"]
    runner -->|m coverage| cov["LCOV coverage<br/>≥85% gate"]

One parser feeds every editor feature: format, lint, and the language server all sit on the m-parse syntax tree.

flowchart TB
    src[".m source"]
    src --> mparse["m-parse<br/>tree-sitter-m → syntax tree"]
    mparse --> fmt["m fmt<br/>AST-preserving format"]
    mparse --> lint["m lint<br/>rule engine"]
    mparse --> lsp["m lsp<br/>highlight · go-to-def · diagnostics"]

Your M code calls conformance-tested STD* modules instead of re-inventing per-site utilities — the same on YottaDB and IRIS.

flowchart TB
    app["Your M routine<br/>do ^STDx(...)"]
    app --> lib
    subgraph lib["m-stdlib — pure-M · YottaDB &amp; IRIS"]
        direction LR
        fmt2["data formats<br/>STDJSON · STDREGEX · STDCSV"]
        enc["encoding<br/>STDUUID · STDB64 · STDHEX"]
        test["testing<br/>STDASSERT · STDMOCK · STDFIX"]
        util["utilities<br/>STDLOG · STDDATE · STDCOLL"]
    end

A developer or AI agent drives m — the centerpiece — which fans out to its four jobs (sync, parse, package, test), all of which act on the vista-iris instance at the bottom.

flowchart TB
    user["Developer / AI agent"]
    user --> mcli["<b>m-cli</b> — the <code>m</code> busybox"]

    mcli -->|m pull / push| irissync["irissync<br/>source sync"]
    mcli -->|parse tree| mparse["m-parse<br/>tree-sitter-m"]
    mcli -->|m kids| kidsvc["kids-vc<br/>KIDS packaging"]
    mcli -->|m test| stdlib["m-stdlib<br/>M runtime + tests"]

    irissync --> vistairis["<b>vista-iris</b><br/>VistA loaded into IRIS for Health"]
    mparse --> vistairis
    kidsvc --> vistairis
    stdlib --> vistairis

    classDef center fill:#00ADD8,stroke:#024,stroke-width:2px,color:#fff;
    classDef engine fill:#1f2937,stroke:#111,color:#fff;
    class mcli center;
    class vistairis engine;

Driven directly from a terminal, or by an AI agent through the m-dev-tools-mcp server (which exposes every m command as an MCP tool). Underpinning the whole stack: docs (strategy/specs), go-cli-template (the shared clikit CLI grammar every binary inherits), and workspace (the clone-all manifest + bootstrap).

A second, read-only track helps you understand the VistA codebase while you work in it — M-aware editing in VS Code, and code/data-model/docs lookups through vista-info-hub.

flowchart TB
    user["Developer"]
    user --> vscode["VS Code + M plugin<br/>syntax highlighting · LSP · go-to-definition"]
    user --> hub["vista-info-hub<br/>CLI · TUI · web"]

    vscode -->|"language intelligence · m lsp"| awareness["VistA situational awareness<br/>routines · FileMan data dictionary · VA docs"]
    hub -->|routine / file / risk queries| awareness

Key invariants

• Single writer — irissync push is the only thing that writes routines back into IRIS; everything else (list/pull/status/verify) is read-only by construction.
• Single parser — m-parse is the one M parse engine; fmt, lint, and lsp all sit on it. It runs the tree-sitter-m grammar as WASM through wazero, so the whole toolchain stays a static binary with no CGO.
• One command grammar — every Go binary builds on go-cli-template's clikit, so they share an identical output contract (text | json | auto), error model, and exit-code ladder. m aggregates them all via m schema, which is exactly what m-dev-tools-mcp reflects to agents.

m is a busybox: native commands live in m-cli; sibling namespaces are dispatched to standalone binaries discovered at runtime ($M_<NAME>_BIN, then alongside m, then $PATH). Missing siblings degrade to stubs so the schema stays valid.

m fmt        AST-preserving formatter (shape-checked: parse(fmt(x)) == parse(x))
m lint       query-driven rule engine over the parse tree
m lsp        M language server (LSP 3.x over stdio)
m test       run *TST.m suites via the engine, ^STDASSERT, TAP/JUnit output
m coverage   line + branch coverage → LCOV
m watch      re-run lint/fmt (and tests) on change
m schema     emit the aggregated command tree as JSON (agent discovery)

m list|pull|status|verify|push        → irissync   (push is the sole DB writer)
m kids decompose|assemble|roundtrip|lint|parse  → kids-vc

Install and first-run instructions live in the m-cli README; machine setup and the end-to-end pull → edit → test → push workflow live in workspace.

• Git-canonical source. The database is the engine, not the repository.
• Engine-neutral by default. YottaDB and IRIS are both first-class; only the IRIS source boundary (irissync) is engine-specific.
• Static, dependency-free binaries. CGO_ENABLED=0 everywhere — even the M parser runs as WASM via wazero, so there is no libc/C toolchain at runtime.
• One contract, many surfaces. A single command grammar (clikit) and a reflected schema mean CLI flags, MCP tools, and JSON envelopes never drift.
• Safe by construction. Read verbs can't mutate the database; the single writer is locked and conflict-checked; KIDS packaging refuses PHI/PII.
• Conformance-tested. m-stdlib modules ship with vendored RFC/NIST corpuses and an ≥85% coverage gate per module.
• Machine-reviewable docs. Every design doc is validated in CI by doc-framework.

Contributions are welcome. The org-wide guides live in this .github repo:

• Contributing guide
• Code of Conduct
• Security policy

The codebase is licensed under Apache-2.0, with two deliberately isolated exceptions (the MIT VS Code extensions and the AGPL-derived embedded grammar artifact in m-parse) — see NOTICE.

Not affiliated with or endorsed by the US Department of Veterans Affairs. "VistA" refers to the public-domain VA health information system. These tools operate on VistA source and ship with fictitious test data only — never load real patient (PHI/PII) data into instances used with them.

Go repos call the reusable workflow in this repo:

uses: vista-cloud-dev/.github/.github/workflows/go-ci.yml@main