Write reusable rich Documents, then arrange them in a Document Page tree to create nested website routes. A Document owns content blocks; a Document Page owns route structure, attachments, metadata, SEO, and layout Component choices.
Coverage: UI + MCP, with incomplete generated-output details that require runtime verification.
File: Document · Owns: rich-text and embedded media/Component blocks · Does not do by itself: create a public route
File: Document Page · Owns: nested route tree, attachments, metadata, SEO, page/summary Components · Does not do by itself: replace the content inside an attached Document
The MCP family retains historical blog-* operation names even though the current UI calls the route-tree file Document Page.
Create a Document below Documents and open it.
Add paragraphs, headings, bullet/numbered lists, quotes, code blocks, or dividers.
Apply inline bold, italic, strike, underline, code, URL link, or internal page link formatting.
Add Image, YouTube, or Component blocks when they support the article.
Configure supported media/Component width, border, and padding in the UI.
Start with exactly one H1 page title, use H2 for major sections and H3 for subsections, and do not skip levels to change visual size. Reserve H4–H6 for genuinely deeper nesting.
Preview the Document by itself or in an embedding context.
Internal page links and Component blocks store identities; rename/restructure tests must confirm those references still resolve.
Create a Document Page in a permitted Page location.
Add tree items before, after, or inside the current item.
Name items with route-friendly labels and attach a Document or supported Page Component.
Leave an item unattached only when it acts as a grouping parent for children.
Add route SEO, including a distinct browser/search title and meta description. These values belong to the Document Page route and are not inferred from Markdown headings.
Choose the page, item, and summary-item Components used by the generated site.
Preview the complete route tree and follow every emitted route.
Names become lowercase route segments with spaces replaced by hyphens. An unattached leaf emits no route. The root route currently re-exports the first document and is not duplicated in the SEO page list.
In the
Websiteproject, inspect<Document reference>and<Document Page reference>. Update only these Document blocks:<bounded content structure>, preserving existing block IDs where possible. In the Document Page tree, add<route items>and attach the intended Documents/Components, metadata, and SEO. Do not delete or reorder unrelated routes. Read the blocks and tree back, preview the complete route set, verify internal links and generated output, and report any unsupported block presentation setting instead of approximating it.
Document MCP operations can replace/append a document, target block insertion/replacement/deletion, and add image/video/Component blocks. Document Page operations read and mutate the route tree, attachments, layout Components, and SEO.
For a surgical correction, prefer edit-document with current stable block IDs over replacing the whole document.
inspect the stored block order and types;
check headings, lists, code, links, and embedded assets visually;
verify Component blocks resolve to compatible files;
inspect every Document Page item, parent, order, attachment, slug, metadata, and SEO value;
confirm grouping nodes and unattached leaves behave as intended;
open every expected route, including nested routes and the root;
inspect responsive layout and generated output in the intended boilerplate.
Document block edits and Document Page tree edits belong to different file histories. Moving a route-tree item preserves its item ID, while deleting the item is different from deleting its attached Document file.
Publishing the generated routes is an external action and is not reversed by undoing the project definition.
A Document becomes a public route only when a Document Page attaches it.
Attachments and layout choices must resolve to compatible current files.
Some media/Component block presentation controls are UI-only or lack complete MCP coverage.
Rich Document generated output and the complete route workflow still require runtime verification before this guide is approved.
Older stored Document shapes use a compatibility rendering path; verify migrated content visually.