# Project structure

> The few project areas you change and the output the toolkit generates.

Canonical: https://maru.audio/docs/project-structure
Documentation index: https://maru.audio/llms.txt

A project created with [`maru init`](https://maru.audio/docs/create.md) is a normal web project
with one typed audio module. Names may vary between starters and larger
modules, but the ownership boundaries stay the same.

```text
my-tool/
├── package.json       # dependencies, scripts and the module entry
├── README.md          # purpose, setup, targets and verification
├── AGENTS.md          # instructions for coding agents working on the project
├── src/
│   ├── index.ts       # module declaration entry
│   ├── contract.ts    # parameters and state (Processor starters)
│   ├── dsp/           # module-owned processing (Processor starters)
│   ├── ui/            # face, styles and controls
│   └── presets/       # factory preset source, when the module has presets
├── assets/            # samples, images and other resources
└── build/             # generated artifacts
```

Import shared behavior from the `maruaudio` package: declarations from
`maruaudio/audio/define`, DSP leaves from `maruaudio/dsp/...` and face controls
from `maruaudio/ui/...`. Keep module-specific UI, presets and assets here.
A module can be composed without loading its face or importing another app.

## What you own

The module declares the sound or MIDI graph and its stable public parameters.
The interface is ordinary web code connected through bindings supplied by the
starter. Assets and presets remain part of your project.

This is also the useful boundary for a coding agent: ask it to change the graph
in the module and the experience in the interface, then verify both in the
workbench.

## What the toolkit generates

The toolkit handles preview data, host metadata, parameter automation, saved
state, native project files, and bundled interface assets. Do not build product
logic into generated output because it can be recreated.

## Portability and switching

Your module source, web interface, assets, presets, and project configuration
remain readable files in your workspace. The interface is ordinary web source,
so you can replace packages, connect other services, and deploy a supported
browser build on your own site.

This does not mean switching has no cost. The typed graph API, runtime bindings,
and native packaging are Maru dependencies. Moving the project to another
audio framework means adapting or replacing those parts. The important point is
that you can see the boundary, keep your work, and plan that migration instead
of being locked inside a hosted editor or inaccessible project format.

Use `maru dev` for the workbench and the `maru module` and `maru plugin`
commands for checks and builds. See [Check, build and export](https://maru.audio/docs/export.md)
for the workflow.