Mastraudit

Audit a Mastra implementation in the order things actually go wrong.

That ordering is the whole point, and it is a correction. An audit that leads with architecture catches a stray @mastra/* import instantly and misses the incident that costs the most hours. Package boundaries are cheap to fix and rarely fatal. Execution semantics - what a step does, how fan-out results are keyed, whether a load-bearing write throws - are where runs die, and they are invisible to a structural pass.

So: execution first, structure second. If you run out of time, you will have spent it on the half that matters.

Source of truth

Mastra moves fast enough that recalled API shapes are wrong more often than right. In priority order:

1. The installed packages. node_modules/@mastra/* types and embedded docs. This is what will actually run.
2. The documentation for that version. A local mirror if one exists, the published docs otherwise.
3. Nothing else. Never model memory for constructor signatures, model routing, storage, memory, workflow, or tool APIs.

Note the installed version and resolve any disagreement in favour of what is installed. Where a codebase ships its own Mastra conventions - a house package, an architecture document, a failure log - read it first; it outranks generic guidance about that codebase.

The five-minute pass