Dotabase Templates

Description

Dotabase Templates package a reusable database schema, views, behaviors, and metadata into a registered definition that can be instantiated consistently.

A template definition is registered with ownership and versioned provenance, then the instantiation service creates the supported Dotabase resources as one governed workflow. Schema, saved views, behavior bindings, and related metadata are interpreted through existing services rather than copied into raw tables. Single-instance enforcement prevents races from producing duplicate system databases.

User Story

As a workspace administrator, I install a proven project template instead of rebuilding its schema and views by hand. I select a registered template, provide the allowed instance details, and invoke instantiation. The service verifies scope and single-instance rules, creates the Dotabase through platform contracts, and records where it came from. I walk away with a consistent starting workspace that I can continue configuring as ordinary data.

Extension Surface

Extensible: built-in and company-scoped template definitions can be registered through the service contract.

packages/dotabases/src/templates/service.ts is the trusted registration surface for non-colliding definitions and ownership scope. The extension is declarative: compositions register supported resource descriptions, not arbitrary code fetched from a tenant row.

Capabilities & Limits

• Capability: Executes the scoped workflow described above through the cited live implementation paths.
• Capability: Preserves typed validation and applicable tenant, schema, lifecycle, or service boundaries.
• Limit: Instantiation creates platform-supported resources; arbitrary executable template code is not accepted. Templates can package schemas, views, behavior bindings, metadata, provenance, and single-instance policy. They cannot install an unknown property implementation, run a migration supplied by a customer, or keep an instance continuously synchronized after creation. Later edits belong to the instantiated Dotabase unless a separate reconciliation workflow owns them.

Implementation Map

• packages/dotabases/src/templates/service.ts
• packages/dotabases/src/templates/instantiate.ts
• packages/db/src/schema/dotabase-templates.ts

Related Features

Creates Dotabase Workspaces and can bundle Page Templates and Layouts.

Operationally, these relationships preserve a clear ownership boundary around Dotabase Templates. Neighboring features can invoke, supply, or consume its results, but `packages/dotabases/src/templates/service.ts` remains the grounded implementation authority for this capability. That distinction prevents the catalog claim from widening into adjacent rendering, transport, or governance work. Teams can therefore combine the feature with the named dependencies while still diagnosing configuration, validation, and lifecycle behavior at the package boundary that owns it.