How export works

Misaki Studio export is code generation from the current project model. It is not a download of the editor canvas and it is not a copy of the preview DOM. The exporter loads project files, asks supported file types for their generated source, formats that source, writes required assets and project-level helpers, and optionally writes a separate backend artifact.

Inspection and export are different operations

• Operation: Preview Code Of Selected Open File · Scope: Generated files for the selected file. · External write?: No. Read-only code dialog.

• Operation: MCP export-code · Scope: TSX and SCSS for one Page or Component; includes authored Code Component source when present. · External write?: No. Returns text.

• Operation: MCP get-diagnostics · Scope: Current checker diagnostics for one file, mapped to design nodes when possible. · External write?: No. The checker is intentionally described as lossy.

• Operation: Export Code To Local Folder / MCP export-code-to-folder · Scope: Complete project to every configured local-folder target. · External write?: Yes. Rewrites generated output.

• Operation: Export Code To Git · Scope: Complete project to every configured Git target, followed by commit and push. · External write?: Yes. Remote external state.

• Operation: Export NPM To Git · Scope: Complete project plus generated package-map/version changes, followed by commit and push. · External write?: Yes. Remote external state.

Inspect one file first. A per-file code preview helps you understand an API or diagnose a generated fragment; it does not reproduce the complete folder export.

What a visual file generates

A visual Page or Component normally generates:

• one React/TypeScript file (.tsx);

• one scoped stylesheet (.module.scss).

The generated component source can include structure, properties, states, events, timelines, data access, design-system references, and imports required by the authored file. The exact imports are demand-driven, so inspect the actual output rather than copying a fixed dependency list from another project.

A Code Component also has authored source stored in its Code node. MCP export-code shows that source separately from the Misaki-generated wrapper and includes compiled Code-node files where applicable.

A Mockup generates no React code. Its editor view can be captured for review, but it is not an exportable runtime file.

What a whole-project export can add

The folder exporter walks the project's supported files, not only the currently open tab. Depending on project contents, the output can include:

• Page and Component TSX/SCSS;

• code from supported API, storage, CMS/data, document/blog, script, environment, and design-system files;

• referenced images, SVGs, audio, and uploaded fonts under the asset destination;

• an SEO page manifest and sitemap/robots generation script;

• linked-library code under a lib/<library-slug>/ namespace plus referenced library assets;

• a generated database client in the frontend when the project contains database files;

• a separate backend manifest only when both a non-empty backend target and project database files exist.

This list describes output categories, not a guaranteed fixed tree. A project's file paths and content determine the generated paths. Inspect the post-export diff as the authoritative result for that project.

The frontend and backend stay separate

Every target has frontend source and asset paths. The optional Node.js source path is a different output root.

target
├── path         generated frontend source
├── asset        referenced media and fonts
└── backendPath  optional generated Node.js/Express manifest

No backendPath means no backend artifact. Even with a backend path, a project without files under database/ emits no backend. When database files do exist, the frontend can also receive its generated database client because Components may reference database views.

The current public backend boilerplate supplies the service shell around the generated manifest, but its SQL action engine is unfinished. Generated output does not make that public shell production-ready.

Know which source you own

Most generated files begin with:

// This file is generated by Misaki Studio. Do not edit.

Treat those files as replaceable. Handwritten adapters, application services, tests, routing glue, and provider configuration should live outside paths the exporter owns.

Script files are an important exception: their authored TypeScript source is exported without the generated-file header because the script is user-authored source. A destination can therefore contain both generated files and intentional authored source; review by file role, not only by extension.

The starter application's shell—such as _app.tsx, _document.tsx, provider configuration, and package scripts—is also maintained outside the generated project tree unless a target explicitly places generated output over it.

Formatting, assets, and stale files

Generated code is formatted before it is written. Referenced image/audio assets and configured fonts are copied to their output folders. Export creates required nested directories beneath an accepted target.

The exporter writes current files but should not be treated as a general-purpose cleanup tool for handwritten or obsolete output. Use a clean target or review removed/renamed project files explicitly so stale destination files cannot silently survive as valid application code.

Verification is part of export

A successful exporter response proves the generation operation finished for the targets it reports; it does not prove the consuming application builds or behaves correctly.

After export:

1. Inspect every changed, added, and unexpectedly unchanged file.

2. Check that generated imports resolve against installed dependencies.

3. Run the destination's formatter only if it will not conceal the generation diff.

4. Run typecheck, tests, and a production build.

5. Preview the built artifact and exercise important interactions.

6. For a package, pack and install the tarball in a clean consumer before publication.

7. For a deployment, inspect the production artifact before approving the external release.

UI and MCP relationship

Coverage: UI + MCP for per-file inspection and local-folder export; Partial MCP for Git and publishing.

MCP can inspect a Page or Component with export-code, report current diagnostics, configure targets, and run the normal whole-project local-folder export. It does not currently expose the Git export/push action, and it does not turn provider deployment into an undoable project edit.