Publish a website

Publish the current Misaki Studio project through the desktop Publish Website flow, wait for the asynchronous build to finish, then verify the returned hosted URL as a visitor. Publishing first synchronizes the latest project state and changes an external hosted destination.

Coverage: Desktop UI. The production MCP surface can inspect and export project output but does not currently expose the whole-project hosted Website publish action.

Before publishing

Complete these checks:

• preview every public Page and route;

• test responsive boundaries, themes, interactions, navigation, and important data states;

• inspect generated code and diagnostics;

• verify assets and external URLs;

• remove real test credentials and private Users data;

• review current sync status and resolve incoming changes;

• confirm that a hosted Misaki URL is the intended destination rather than local/Git export or a self-owned boilerplate deployment.

Read Choose an output if those destinations are still interchangeable.

Start the publish

1. Open the code-shaped menu in the project top bar.

2. Choose Publish Website.

3. Review the current website status in the dialog.

4. Choose Publish only after the project and destination are confirmed.

5. Keep the dialog available while the project synchronizes, builds, and publishes.

The dialog can show live build/publish stages. A publish can take minutes; use the stage and refreshed status to distinguish ongoing work from completion rather than repeatedly starting new publishes.

Wait for a final result

The publish request first synchronizes project updates, then starts the website build on the storage/build service. Closing the dialog does not mean the job succeeded or failed.

Reopen or use Reload to fetch current website information. When a URL is available, use the dialog's copy action or open the route for verification.

Do not publish repeatedly while an earlier build is still active. A second request is not a recovery strategy for an uninspected failure.

Verify as a visitor

Open the hosted URL in a clean browser context and check:

1. the root route and every intended nested route;

2. navigation, refresh, and direct URL entry;

3. narrow, medium, and wide layouts;

4. public themes and variants;

5. assets, fonts, images, audio, and external media;

6. loading, empty, error, and public data states;

7. metadata, title, description, and social/SEO output;

8. console and network failures;

9. links to external destinations;

10. the deployment URL shown by the project after refresh.

Preview and generated-code inspection do not prove the hosted artifact. Verify the actual URL.

Ask an agent to prepare, not publish

In the selected Website project, prepare a publication review without publishing. Inspect the project tree, public Pages, Document Page routes, Preview states, generated output, diagnostics, assets, and known authentication/database/boilerplate limitations. Return a go/no-go checklist and the exact issues that remain. Do not sync, push, publish, promote a domain, or mutate any external destination.

This uses MCP for evidence while keeping the externally mutating publish action in the explicit UI workflow.

Failure and recovery

If the build fails:

1. record the stage and visible result;

2. refresh website information once;

3. inspect generated output, diagnostics, and the current project sync state;

4. reproduce the build in a compatible local/boilerplate consumer when possible;

5. correct the project source or hosting shell responsible for the failure;

6. preview and inspect again before starting a new publish.

Project undo does not roll back a hosted deployment. Current custom-domain promotion can point selected domains at a chosen build, including an older build ID, but its visitor-facing UI and recovery workflow require a separate runtime-verified guide before it should be used as the documented rollback path.

Current limits

• Hosted publication is asynchronous and externally mutating.

• There is no production MCP tool for the whole-project Website publish action.

• A successful request is not proof that the final URL finished building.

• Authentication, public backend actions, and Users-data export have current unfinished boundaries described in Logic and data.

• Custom-domain setup, promotion, and rollback are not yet runtime-verified for this documentation rewrite.