Template Studio

Template Studio is the layout and template authoring surface. Authors edit pages and blocks, bind them to schema fields, select branding, preview with data, and publish immutable versions. Documents created from a published template have their own content and edits.

Preview and launch status

Template Studio's public launch and MCP rollout require the owning team's approval and deployment verification. Source implementations and local checks do not establish access for every team, an enabled pilot cohort, or matching deployed versions. Use your team's approved Studio connection and check the available capabilities.

Author and publish

1. Open a template in the authorized team. Create a draft or open an existing one. Start with a supported schema and starter layout; add or edit blocks through the Studio editor.
2. Bind data. Bind text, images, tables, charts, and other supported blocks to schema fields. Preview a known payload, or select and save test data from a supported DataHub source. Keep the selected record and its provenance visible.
3. Select branding. Choose a published BrandKit reference. Pin the kit revision when the output must be reproducible.
4. Review the draft. Inspect the layout, required fields, data, branding, and runtime validation issues. Resolve publish blockers before accepting the version.
5. Publish an immutable version. Keep its returned runtime manifest, version ID, pinned config URL, and schema identity together. Publishing and registration in Uhuu App are separate outcomes; see Studio deployment.

Restoring an older version creates an editable draft from that snapshot rather than overwriting the published version. A viewer or published runtime uses the published configuration; editing a document's field does not author a new template layout.

Compose through MCP

Studio MCP is proposal-first. It composes against existing published Role/Look contracts rather than giving an assistant unrestricted layout-authoring authority. Unified Uhuu discovery prefixes Studio tools with studio__; tool visibility and use depend on the connection's enabled capabilities and scopes.

1. Search the accessible template catalog and read get_template_composition_contract.
2. Follow its intake and field rules. If data references are permitted, use only the approved references returned by the supported tools.
3. Run validate_document_composition and present remaining assumptions or issues.
4. Use propose_document_draft to prepare the proposal, then direct the person to review and accept it in Uhuu.
5. Check get_proposal_status and obtain the accepted handoff through get_document_handoff. A proposed draft is not yet an accepted document.

The studio:documents scope covers the composition flow. Approved data references additionally require studio:data-refs; file intake is a separate studio:file-intake capability with its own confirmation requirements. Missing contracts or refused tools are reasons to resolve access or ask the template owner for authoring work, rather than silently switching into another workflow.

For filling an existing published document template directly, use Documents MCP. It follows that template's conversation guide and saves an editable draft after confirmation; the two flows have different ownership and acceptance steps.

Preserve versions and document edits

Use the returned runtime manifest instead of reconstructing URLs from names. A pinned runtime includes the selected template version; latest is an explicit moving alias. Retain uhuu_builder identity and schema metadata with the document payload, and keep document-local edits in that payload rather than in the published configuration.

Updating a document to another published version is an explicit migration. Review layout and field compatibility, preserve the original document creation identity and edits, and verify the resulting preview before export. Publishing a new template version alone does not prove that every existing document has migrated.