Discovery is the “find” half, and it’s the piece I’m happiest with architecturally.

A provider is about as small as an interface gets. It answers one question, given a directory: which files here are importable? It also has to be a cheap check that cannot fail.

type DiscoveryProvider interface {
    Name() string
    Imports(dir string) []string
}

It returns file paths, not executables. Turning a file into executables is Flow’s job (or, for the formats Flow doesn’t know about, a parser on Mochi’s side). Nine providers ship today: Makefile, package.json, docker-compose, loose shell scripts, Justfile, Taskfile, GitHub Actions, Dockerfile, and Cargo. The first four are parsed by Flow itself; the rest are Mochi’s. Registration order matters. The first provider to claim a file wins, which is how conflicts get resolved without a merge policy.

Nothing is written to disk

The important design decision: discovered executables are generated at read time, not imported into your repo.

Mochi decorates Flow’s executable cache. Discovery persists only a selection of importable files per workspace, and the decorator regenerates their executables on every read, so they appear identically in the desktop, in mochi run, and in flow browse, while your repo stays exactly as it was. Generation happens against a virtual flow file that only ever exists in memory; its directory is the only thing that matters, because that’s what imports resolve relative to.

Failures degrade to nothing rather than propagating, so a bad provider can never break the cache it’s wrapping. Repeat scans are cheap: state stores file modification times as a fingerprint and short-circuits when nothing has changed.

Attribution has a constraint worth mentioning, because it shaped the design. Flow doesn’t inherit flow-file annotations into generated executables, and a slashed namespace would break its reference parser. Discovered executables get a single namespace plus a per-executable annotation naming the provider that found them.

The desktop app holds no business logic. Every operation is a Tauri command that shells out to the bundled mochi binary and parses its JSON output. Same binary, two surfaces.

A few details that turned out to matter more than expected:

It goes through a shell. A GUI app on macOS doesn’t inherit a login shell’s environment, so invocations source the user’s profile first. Arguments are POSIX-quoted, which matters because executable references contain a space. validate flow/ns:name has to survive the round trip as one token instead of being split into two.

Runs are tagged with their origin. Every spawned process gets FLOW_RUN_SOURCE=desktop. Without it, a run started by clicking Execute is indistinguishable from one typed into a terminal. Both would record cli, because that’s what Flow assumes when nothing says otherwise. The desktop is its own origin, and history should say so.

Secrets reach providers through the environment, never argv. Arguments are visible to every process on the machine; a child process’s environment is not.

Type Safety Across Three Languages

Mochi is Go, TypeScript, and Rust in one repo. JSON Schemas are the contract, vendored from Flow, which owns them. TypeScript types and the raw schema modules are generated for the frontend; Rust types are generated for the Tauri backend; Go gets the same types by importing Flow as a library rather than by generating them.

That’s a better arrangement than it sounds like: the schema is what keeps the Rust and TypeScript mirrors honest against the Go types they’re shadowing. Generation is orchestrated by Flow executables (of course), and CI fails if generated code is out of date.

This is the “remember” pillar, and it’s the reason Mochi exists at all. Agents run a lot of commands on your behalf. The transcript is ephemeral and unstructured, there one moment and gone the next. Mochi keeps the record: what ran, how long it took, whether it failed, and why.

Almost none of that storage is Mochi’s. Flow already records every execution to a shared embedded datastore, with a record that carries the reference, timing, status, exit code, process ID, log archive, and the useful part, provenance: source (cli, desktop, or mcp), clientName (claude-code, cursor), sessionId, and workingDir. Records are lifecycle-aware: they appear as running the moment a run starts and update in place when it finishes.

Two of those fields have justifications I like. workingDir exists because the workspace is already recoverable from the reference but the path is not, and it’s the only thing separating two checkouts of the same repo. sessionId exists so one assistant’s related runs stay grouped.

Mochi’s contribution is aggregation. A single pass over history rolls executions up per executable and per workspace, keyed by executable ID rather than by reference so that verb aliases like run, exec, and start of the same thing all collapse into one bucket. That same rollup feeds both search ranking and the dashboard, so history gets swept once per invocation rather than once per feature.

The dashboard turns it into four purpose-built views rather than one generic screen: Welcome for first-run setup, Pulse for health and what’s happening now, Launch for getting back to work, and Insights for activity over time. Insights surfaces the busiest, least reliable, and slowest workflows, plus recommendations. Those are plain heuristics today, a reliability rule and a duration rule, with stable IDs so that dismissing one survives regeneration. They are deliberately built as the seam that model-generated insights will later plug into.

The AI layer is provider-agnostic behind a two-method interface. Features depend on that interface rather than on a concrete client, which keeps where the tokens come from a resolution-time decision.

You bring your own key: OpenAI, Anthropic, Gemini, Ollama, or any OpenAI-compatible endpoint. Keys are never stored in Mochi’s config. The config file holds only a pointer to a vault entry, and the secret itself lives in the Flow vault. Each provider gets its own slot, so you can hold an OpenAI key and an Anthropic key at once and flip between them without re-entering anything.

Reaching the vault involved a small workaround. Mochi’s AI package can’t import Flow’s vault resolution, since it’s internal to Flow and off-limits the same way it is to the Rust layer. Instead it shells out to its own binary’s inherited secret command, exactly as the desktop does. Vault access always goes through Flow’s real implementation rather than a reimplementation of it.

The agent loop is bounded rather than trusted to stop on its own: a round budget and a wall-clock timeout, sized for analyzing a whole workspace while still stopping well short of a runaway. Tools come from Mochi’s own MCP server behind a three-tier permission policy, and every call is recorded as an audit entry. Confirmation is designed to cross a process boundary. If no confirmation handler is set, the loop returns a pending request rather than blocking, so the desktop can ask the user and resume.

Usage is logged locally as one JSON line per generation, with age and size retention, so you can see what your own key is being spent on.