Export your code

This workflow takes you from a reviewed Page or Component to generated files in a destination you control. It uses read-only inspection first, then a deliberate whole-project write.

Before you start

You need:

• a Page or Component whose preview has been reviewed;

• a destination chosen with Choose an output;

• a version-controlled or disposable target;

• current export paths configured in settings/export;

• the consuming application's install, typecheck, test, build, and preview commands.

Use the desktop app for local-folder export. Git, registry, hosted-site, and cloud-provider actions have separate external side effects.

1. Inspect the selected file

In the editor, open the Page or Component and choose Preview Code Of Selected Open File from the code-shaped top-bar menu. Switch between the generated files shown in the dialog.

With MCP:

Select my project and resolve <file path>. Run export-code with part: "tsx", then part: "scss". Summarize the public component API, generated imports, element structure, data or routing dependencies, and style boundaries. Do not configure or write any export target.

export-code is read-only. It generates current text for one visual file and is the best first evidence for what that file compiles to. Mockups return no code.

2. Check diagnostics without overclaiming

Run get-diagnostics for the same file. It can map recognized TypeScript problems back to design nodes and can surface checker errors for some non-design files.

An empty response is not proof the destination compiles: the checker is lossy and does not replace the consuming application's full TypeScript/build pipeline.

Run get-diagnostics for <file path>. If errors are reported, identify the producing nodes and explain what should change in the Misaki project. Do not edit yet. If no errors are surfaced, say that this is not a full build result.

3. Review the whole-project implications

Read How export works. The folder operation can write supported project files, linked-library output, assets, SEO helpers, a database client, and an optional backend—not only the Page or Component you inspected.

Confirm:

• every configured local target is intended to receive this project;

• path, asset, and optional backendPath do not overlap destructively;

• generated dependencies exist in the destination;

• handwritten code is outside generated paths;

• backend output is deliberately enabled or deliberately empty.

4. Configure the destination

Follow Configure local and Git export targets.

For a typical frontend boilerplate clone:

REACT SRC PATH  → /absolute/path/to/clone/src
ASSET PATH      → /absolute/path/to/clone/public
NODEJS SRC PATH → empty

The local directories must already exist. Read the target back before exporting. If any Git target contains a credential, do not share the raw get-export result because it currently includes the token.

5. Protect the destination

Before the write:

1. Commit or snapshot the destination repository.

2. Record its current branch and status.

3. Search generated paths for HAND EDIT (not produced by the exporter) and move required custom work out of the overwrite boundary.

4. Check for additional local targets, because all of them will run.

Do not use the export itself as a backup.

For repeat exports into a maintained application, use the full Re-export safely checklist.

6. Run the local export

In the desktop editor, choose Export Code To Local Folder.

With MCP:

Read and summarize all local export targets. Confirm their directories exist and are folders. If every target matches the approved plan, run export-code-to-folder with the normal production output. Report each target result, then stop. Do not push, publish, deploy, or modify generated files by hand.

Use the normal production output for application integration. Export Code To Local Folder With Helper and MCP's helper: true variant emit helper code used by Misaki Studio's checking workflow; they are not the default application artifact.

The operation can partially succeed: one valid target may be written even if another target reports an error. Inspect every configured destination after the call.

7. Review what changed

Start with the diff, not the success notification.

• Confirm expected Page/Component TSX and SCSS files changed.

• Inspect newly introduced imports and runtime helpers.

• Confirm referenced images, audio, and fonts resolve under the asset path.

• Check routes and SEO output for Pages.

• If the project has database files, check the frontend client and any explicitly requested backend manifest.

• Look for stale files from renamed or removed project paths.

• Verify no secret or local-only value entered source control.

8. Test the destination

Run a clean dependency installation when adoption risk justifies it, then the repository's typecheck, tests, production build, and local preview. Exercise authored states, events, navigation, responsive modes, data calls, and important animations in the built application.

For a package, use npm pack and a clean consumer before publication. For a static-site target, inspect the built output before provider deployment.

Git export is a separate route

Export Code To Git and Export NPM To Git clone, generate, commit, and push to every configured Git target. Production MCP can edit the Git target configuration but does not expose this push action.

The current exporter also stores a branch field without passing it to the clone/push implementation. Treat Git export as unfinished for branch selection and do not rely on that field to protect a remote branch. A remote commit is not reversed by project undo.