Project structure

A project created with maru init 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.

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 for the workflow.