Configure local and Git export targets

An export target tells Misaki Studio where to write the generated frontend, assets, and—only when requested—a separate Node.js backend. Configure the target only after you know who owns that destination and which files regeneration may replace.

Before you add a target

You need:

• a selected project with its settings/export file;

• an empty or version-controlled destination you can safely diff;

• separate source and asset directories;

• an optional backend directory only when you have chosen a compatible Node.js/Express host;

• for Git, a repository and credentials permitted to push to it.

Use Choose an output first if local folder, Git, package publication, hosted-site publication, and a boilerplate are still interchangeable in your plan.

Understand the path fields

• Editor label: REACT SRC PATH · MCP/stored field: path · Local target: Existing absolute directory. · Git target: Directory relative to the cloned repository.

• Editor label: ASSET PATH · MCP/stored field: asset · Local target: Existing absolute directory. · Git target: Directory relative to the cloned repository.

• Editor label: NODEJS SRC PATH · MCP/stored field: backendPath · Local target: Optional existing absolute directory. · Git target: Optional directory relative to the cloned repository.

An empty or whitespace-only backendPath means “do not generate a backend.” The source and asset paths are always required for a working target.

For the current frontend boilerplates, the usual mapping is:

REACT SRC PATH  → <clone>/src
ASSET PATH      → <clone>/public
NODEJS SRC PATH → empty

Configure a local-folder target in the editor

Coverage: UI + MCP. Desktop required to export.

1. Open settings/export in the File Explorer.

2. Under LOCAL FOLDER, choose Add Config.

3. Give the target a description that identifies the application or clone.

4. Enter the existing frontend source and asset directories.

5. Leave NODEJS SRC PATH empty unless this target intentionally receives the generated backend.

6. Recheck every path before using the project's Export action.

The local exporter rejects a target when a required path is missing, does not exist, or is not a directory. If a backend path is present, it must also already exist and be a directory.

Configure a local-folder target with MCP

The production tools are get-export, add-export-target, update-export-target, and remove-export-target. Targets have no stable ID; each kind is addressed by its current zero-based index. Adding or removing an earlier target changes later indices, so read the list immediately before an update or removal.

Select my project and find settings/export. Report a redacted summary of its local targets. If no target points to this verified clone, add one with description <name>, frontend source <absolute-src-directory>, assets <absolute-public-directory>, and no backend path. Read back only the non-secret local target fields. Do not export.

Run export-code-to-folder only after reviewing the target. It exports the entire project to every configured local-folder target. A failure in one target does not prove no other target was written, so inspect each destination after a mixed or failed result.

Configure a Git target in the editor

Coverage: Partial MCP. Git writing is currently a UI/server action, not a production MCP export tool.

1. Under GIT, choose Add Config.

2. Enter a descriptive name, repository URL, commit email, username, token, and branch label.

3. Enter repository-relative frontend source and asset paths such as src and public.

4. Leave the backend path empty for a frontend-only repository.

5. Review all configured Git targets before starting a Website or npm Git export.

The Git exporter clones the repository, creates missing configured directories inside its checkout, writes generated output, commits, and pushes. For npm export it also rewrites package metadata from the generated source tree.

Current Git limitations

• The Git export action iterates over every configured Git target; it is not a single-target picker.

• The stored BRANCH field is not passed to the current clone/push implementation. Do not assume the configured branch label controls the destination branch.

• Production MCP can configure Git targets but does not expose the Git export/push operation.

• A push is external state. Project undo cannot remove a remote commit or restore overwritten remote content.

Until the branch behavior has a verified implementation and test, use a repository whose safe default branch is the intended target or perform the export through a separately reviewed Git workflow.

Protect the Git token

The editor renders the token as a secure text field, but the current MCP get-export response includes the token in plain text when one is configured.

• Do not paste raw target output into a prompt, issue, screenshot, or documentation page.

• Ask agents for a redacted summary and never for the token value.

• Use a narrowly scoped credential and follow the repository host's rotation policy.

• Rotate the token if it appears in a retained transcript or log.

This is a current product limitation, not a recommended secret-management workflow.

Review and recovery

Before a local or Git write:

1. Commit or snapshot the destination.

2. Search the generated tree for HAND EDIT (not produced by the exporter).

3. Move handwritten adapters, business logic, tests, and configuration outside the generated boundary.

4. Confirm whether all configured targets are intended to receive the export.

Afterward, inspect the full diff and run the destination's typecheck, tests, build, and preview. Undo/redo of the settings/export file can change target configuration history, but it does not reverse files already written to disk or commits already pushed to Git.