rtClient.templates

rtClient.templates reads the contract-composition surface: which Clarity fragments compose a product type, which ##_..._## slots they declare, and which capabilities, constraints, and attributes exist to fill them. There is deliberately no DB-backed template CRUD (no listTemplates / createTemplate) - composition is read live from the fragment manifest, so it cannot drift from what deploys.

rtClient.templates.getCapabilityRegistry()

The registry of composable parts - every capability, constraint, and attribute, with each attribute's accepted Types. This is the read a create surface uses to render what a product can compose.

const { data: registry } = await rtClient.templates.getCapabilityRegistry();
const attributes = registry.attributes; // each with its Types

rtClient.templates.getSlotSpecs()

The slot specifications a page-family template declares - the placeholders composition fills. Returns ApiResponse<PageSlotSpecResponse>.

rtClient.templates.getPipelineComposition(productTypeId?)

How the rendering pipeline composes for a product type. Returns ApiResponse<PipelineCompositionResponse>.

rtClient.templates.getContractComposition(opts?)

The live composition of a product type's deployable contract: fragments is the ordered .clar manifest the composer concatenates, and composedSource rides along when requested ({ productType, includeSource: true }). Admin-gated - rt-admin's contract inspector is the consumer.

rtClient.templates.processTemplate(request)

Generic template processing (POST /api/contracts/template/generate). Most apps never call this directly - product creation goes through the create services, which compose and generate server-side.