Re-export safely

Re-exporting should replace generated source while preserving the application shell and your handwritten integration. That safety comes from the repository boundary and review process—not from the exporter merging arbitrary manual edits.

The rule to design around

If a file says it is generated by Misaki Studio, assume the next export can replace its complete contents.

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

Make visual, property, variant, state, event, timeline, and supported logic changes in the Misaki Studio project. Keep application-specific adapters outside the generated tree.

A maintainable destination shape

One practical boundary is:

application/
├── src/generated/          ← Misaki target; replaceable
├── public/assets/          ← Misaki asset target; review generated media
├── src/integration/        ← handwritten adapters
├── src/app-or-pages/       ← handwritten routing/composition when not generated
├── tests/                  ← handwritten consumer tests
├── package.json            ← application shell, except reviewed npm workflow
└── provider configuration  ← handwritten deployment shell

A boilerplate may intentionally use src/ as the generated target and keep only a few shell files alongside it. That can work, but the exact generated paths must be known so exporter output cannot collide with _app, _document, provider configuration, or handwritten routes.

Know the exceptions

• A Script file exports the user's authored TypeScript without the generated-file header. Its destination copy is still refreshed from the project on export, so edit the Misaki Script source rather than creating two divergent copies.

• The optional backend export overwrites its generated database/index.ts manifest while the backend boilerplate shell is intended to remain handwritten.

• Export NPM To Git also updates package.json version, exports, and typesVersions. Treat that metadata as part of the npm workflow's generated change, then verify it against the actual build outputs before publishing.

Before every re-export

1. Ensure the intended Misaki Studio changes are persisted; when the project uses sync or version control, create the normal project-side checkpoint.

2. Commit or snapshot every destination repository.

3. Read settings/export and list all targets that the action will process.

4. Confirm frontend, asset, and optional backend paths.

5. Search the destination for generated headers and unexpected handwritten changes inside those files.

6. Search for HAND EDIT (not produced by the exporter) markers and move required work outside generated paths.

7. Record the destination's current typecheck, test, and build result if the change is high risk.

8. Stop if a target, credential, branch, or generated boundary is unclear.

The current raw MCP get-export result can expose a configured Git token. Ask for a redacted target summary and do not retain the full response in shared logs.

Run one generation route

Prefer a local-folder export for review because it leaves the result as an uncommitted destination diff. The operation writes every configured local-folder target, so remove obsolete targets or verify all of them first.

Read my export settings and give me a redacted list of local targets. Verify each directory exists. Run the normal export-code-to-folder only if every target matches this approved list: <targets>. Do not use helper output, Git, publishing, or deployment. Report per-target results and stop for diff review.

Do not run local and Git export back to back merely to “make them consistent.” Review the local result first, then make a separate decision about remote state.

Review the diff by category

Expected modifications

• TSX/SCSS for edited Pages and Components;

• generated API, data, environment, design-system, document, or script modules whose project sources changed;

• assets newly referenced by generated code;

• SEO output when Page metadata or routes changed;

• database client or backend manifest when database definitions changed.

Changes that need explanation

• unrelated Components or Pages;

• new runtime or framework imports;

• a generated path moving between folders;

• package metadata or lockfile changes;

• an unexpected backend artifact;

• provider configuration or application-shell changes;

• credentials, absolute local paths, or environment values;

• very large asset additions.

Missing changes that can also be a problem

The exporter writes current output but does not perform a general cleanup of obsolete destination files. A Page, Component, asset, or library module removed or renamed in Misaki Studio can leave an old file in the destination.

Compare the generated tree with the project paths and remove stale generated files as a separate reviewed change. Do not recursively delete a broad destination merely to force cleanliness.

Verify as a consumer

Generation checks and application checks answer different questions. After the diff is understood:

1. Install dependencies from the destination's locked state.

2. Run its TypeScript check and tests.

3. Run a production build.

4. Preview that production artifact.

5. Exercise the changed Component API, responsive states, events, data calls, navigation, and animation.

6. Confirm assets and SEO output resolve at deployed-style paths.

7. For a package, pack and install it into a clean consumer.

If verification fails, fix the appropriate source:

• visual/generated behavior in the Misaki project;

• integration behavior in a handwritten adapter;

• build/hosting behavior in the application or boilerplate shell.

Avoid patching a generated file unless it is a temporary diagnostic you will discard before the next export.

Commit the destination clearly

Keep generated changes reviewable. A useful commit separates:

• regenerated Misaki output;

• handwritten integration changes;

• dependency or provider changes.

When one commit must contain more than one category, explain the boundary in its message or review notes. This makes a later regeneration diff much easier to audit.

Recovery

Undo/redo in Misaki Studio changes project file content; it does not restore a destination folder or revert a pushed Git commit.

• For an uncommitted local export, restore from the destination snapshot or version-control diff.

• For a committed local export, use a normal reviewed revert in the destination repository.

• For a Git export, inspect the remote commit and use the repository host's normal revert workflow. Avoid rewriting shared branch history.

• For a published package or deployed site, follow the registry/provider rollback process; project undo is not a release rollback.