Template Studio deployment
Template Studio publishing has two separate outcomes:
- Studio saves a validated, immutable template version.
- A configured integration registers that version's pinned runtime as a managed template in Uhuu App.
The Studio version is the authoring source. A failed or unavailable App handoff keeps that published version available for a retry; it does not establish a successful App deployment.
Coordinated rollout
Production launch remains pending the owning team's approval and verification of the deployed applications and renderer. Explicit workspace selection, per-source origin rules, and managed-template structure controls are prepared for a coordinated handoff; caller adoption is still pending. Do not assume an arbitrary first workspace, automatic workspace creation, or that these prepared controls are already deployed.
Destination and ownership
The destination must be an explicitly authorized workspace in the intended team. Confirm it before registration and inspect the workspace and managed-template identity returned by a successful handoff. Current caller adoption must be completed before a deployment can rely on the prepared workspace-selection contract.
Managed registration identifies a template by its source mapping, rather than by a display name or guessed URL. It must preserve manually authored templates and distinguish source-owned structure from document-local edits. During rollout, confirm which management controls the deployed App exposes; source preparation is not proof that a live edit surface enforces those controls.
Keep the runtime pinned
Retain the published manifest's returned URLs and selected version. The runtime path has this shape:
{studio-origin}/render/{team-id}/{studio-template-id}/{version-id}Use the actual approved origin and returned identifiers. A pinned config URL contains the selected version, for example ?version=v3; a latest alias intentionally follows future publications. The manifest also supplies the schema identity, editor/viewer handoff, and uhuu_builder metadata. Preserve this metadata with the document payload.
A pinned template registration and an individual document's revision are different identities. Publishing or registering a newer template does not by itself attest that existing documents were migrated, that their saved data is unchanged, or that a historical render snapshot was preserved. Check the document's saved revision and runtime selection before rendering; use an explicit reviewed version-update flow when changing its runtime.
Data, branding, and the SDK bridge
Studio resolves deployment base data from the selected saved test-data record and record index. Temporary browser previews and unsaved integration data are not durable deployment inputs. A template without selected saved data starts with an empty schema record.
The handoff includes the selected record, required page/integration containers, and pinned uhuu_builder runtime metadata. Keep BrandKit selection and resolved asset provenance with the same payload used for preview and PDF export.
The published /render runtime loads the Uhuu SDK and responds to incoming document payload changes. A document-local field edit updates that document's rendering rather than republishing the Studio layout. Layout authoring continues in Studio.
Studio supplies page dimensions in millimeters, orientation, and preview mode. App maps exact A0–A6 dimensions to presets and retains other dimensions as custom sizes. Runtime CSS remains authoritative for per-page overrides and mixed formats. Verify the actual preview and export rather than inferring pagination from the base page preset.
Verify the handoff
Review both publish state and App deployment state. A successful publish can coexist with deployment states such as unavailable, not configured, failed, or permission denied. Inspect the returned App template, workspace, version, and pinned runtime before reporting deployment as complete.
Retries use the same ready immutable version. The managed handoff rejects an older version replacing a newer one, and rejects the same version with conflicting configuration content. Resolve those conflicts through the source owner instead of editing the managed mapping by hand.
Finally, open a document through the approved App flow, verify its saved content and assets, check the selected runtime and brand revision, and perform an authorized render verification. A local source check or a package version alone does not establish deployed compatibility.