@synap-core/workspace-templates 0.12.0 → 0.24.0

package/dist/index.d.ts

@@ -1,634 +1,8 @@
-/**
- * @synap-core/workspace-templates — Types
- *
- * Canonical shape of a workspace template.
- * YAML source files validate against these types.
- * Every consumer (browser, backend, CLI, marketplace) imports from here.
- */
-type TemplateAppKind = "native" | "stored" | "url";
-interface TemplateAppRef {
-    kind: TemplateAppKind;
-    /** For kind='native': the appId registered in the browser manifest */
-    appId?: string;
-    /** For kind='native': how the platform renders the app */
-    rendererType?: "native" | "external" | "iframe-srcdoc";
-    /** For kind='stored': the cell key registered in the cell registry */
-    cellKey?: string;
-    /** For kind='stored': default props passed to the cell */
-    props?: Record<string, WorkspaceJsonValue>;
-    /** For kind='url': external URL to open */
-    url?: string;
-    /** Human label */
-    title?: string;
-}
-type WorkspaceJsonValue = string | number | boolean | null | WorkspaceJsonValue[] | {
-    [key: string]: WorkspaceJsonValue;
-};
-type WorkspacePrimarySurface = {
-    kind: "app";
-    appId: string;
-    rendererType: "native";
-    title?: string;
-    props?: Record<string, WorkspaceJsonValue>;
-} | {
-    kind: "app";
-    appId: string;
-    rendererType: "external";
-    url: string;
-    title?: string;
-    props?: Record<string, WorkspaceJsonValue>;
-} | {
-    kind: "cell";
-    cellKey: string;
-    title?: string;
-    props?: Record<string, WorkspaceJsonValue>;
-} | {
-    /**
-     * Ordinary website. Unlike an external `app`, this has no trusted app
-     * identity and is always opened through the Browser's unprivileged URL
-     * surface.
-     */
-    kind: "url";
-    url: string;
-    title?: string;
-} | {
-    kind: "view";
-    viewId: string;
-    title?: string;
-};
-/**
- * Authoring-time view reference. View IDs do not exist until provisioning, so
- * templates and packages address a view by its stable authored name and/or
- * slug. The pod resolves this to `WorkspacePrimarySurface` before persistence.
- */
-type WorkspacePrimarySurfaceViewReference = {
-    kind: "view";
-    viewName: string;
-    viewSlug?: string;
-    title?: string;
-} | {
-    kind: "view";
-    viewName?: string;
-    viewSlug: string;
-    title?: string;
-};
-type TemplatePrimarySurface = WorkspacePrimarySurface | WorkspacePrimarySurfaceViewReference;
-interface TemplateProperty {
-    slug: string;
-    label: string;
-    valueType: string;
-    inputType?: string;
-    placeholder?: string;
-    enumValues?: string[];
-    constraints?: Record<string, unknown>;
-    targetProfileSlug?: string;
-}
-interface TemplateProfile {
-    slug: string;
-    displayName: string;
-    icon?: string;
-    color?: string;
-    description?: string;
-    /**
-     * Visibility of the profile DEFINITION — who can USE this vocabulary.
-     * `system` = pod-wide; `shared` = ONE row reachable from other workspaces via
-     * a `profile_workspace_access` grant; omit or `workspace` = this workspace
-     * only. Orthogonal to `entityScope` below — do not conflate the two axes. */
-    scope?: string;
-    /**
-     * Placement of the profile's ENTITY ROWS — where the data LANDS.
-     * `pod` → entities are created with `workspace_id = NULL` and are therefore
-     * visible in every workspace; `workspace` (the backend default when omitted)
-     * → entities belong to the workspace that created them.
-     *
-     * Independent of `scope`: a `shared` profile can still mint workspace-scoped
-     * rows, and a `workspace`-scoped profile could in principle mint pod-wide
-     * ones. Both provisioning doors thread this verbatim into
-     * `ProfileRepository.create` (`create-workspace-from-definition.ts:1149`,
-     * `reconcile-workspace-from-definition.ts:319`) — omitting it inherits the
-     * repo default (`workspace`), which is the unchanged behaviour for templates
-     * that do not declare it. Applied on CREATE only: neither door flips the
-     * `entity_scope` of an existing profile (a divergence is reported as an
-     * advisory `scopeConflict` and the live row is left alone).
-     */
-    entityScope?: "pod" | "workspace";
-    /** Semantic slug for system profiles. */
-    semanticSlug?: string;
-    /** Kind vs role profile. Omit for default ('kind'). */
-    profileKind?: "kind" | "role";
-    /** For profileKind='role': which base-kind profile slugs this role can attach to. */
-    applicableKinds?: string[];
-    properties: TemplateProperty[];
-}
-interface TemplateView {
-    name: string;
-    slug?: string;
-    type: string;
-    scopeProfileSlug?: string;
-    scopeProfileSlugs?: string[];
-    config?: Record<string, unknown>;
-    /** If true, this view auto-selected as the default view for this workspace */
-    defaultView?: boolean;
-    description?: string;
-    groupBy?: string;
-}
-interface TemplateEntityLink {
-    sourceProfileSlug: string;
-    targetProfileSlug: string;
-    type: string;
-    label?: string;
-}
-/**
- * A domain-level relation TYPE definition — a `relation_defs` row, the workspace's
- * relation vocabulary. Distinct from {@link TemplateEntityLink}, which is a
- * profile→profile EDGE (and only carries `type` + `label`). A relation def stands
- * alone: it has no source/target profile pairing and it carries the rich metadata
- * (`description`, `isDirectional`, `uiHints`) that the entity-link path drops.
- *
- * Mirrors `DefaultRelationDef` in synap-backend
- * `packages/database/src/utils/default-relation-defs.ts` VERBATIM — the door
- * find-or-creates a `relation_defs` row from each entry (idempotent by
- * `slug` within the workspace), which is `ensureDefaultRelationDefs`'s body.
- */
-interface TemplateRelationDef {
-    slug: string;
-    displayName: string;
-    description?: string;
-    isDirectional?: boolean;
-    uiHints?: {
-        category?: "workflow" | "social" | "reference" | "hierarchy";
-        inverseLabel?: string;
-    };
-}
-interface TemplateSeedEntity {
-    profileSlug: string;
-    title: string;
-    properties?: Record<string, unknown>;
-    content?: string;
-}
-/**
- * Relations between seed entities, created on provisioning. `sourceRef`/
- * `targetRef` reference seed-entity titles (or refs) defined in `seedEntities`.
- * Mirrors `suggestedRelations` in synap-backend `create-workspace-from-definition.ts`.
- */
-interface TemplateSuggestedRelation {
-    sourceRef: string;
-    targetRef: string;
-    type: string;
-    metadata?: Record<string, unknown>;
-}
-/**
- * Entity-card display templates. Mirrors `displayTemplates` in synap-backend
- * `create-workspace-from-definition.ts`.
- */
-interface TemplateDisplayTemplate {
-    name: string;
-    description?: string;
-    entityType?: string;
-    targetType?: string;
-    isDefault?: boolean;
-    config: Record<string, unknown>;
-}
-interface TemplateSidebarSurface {
-    kind: "cell" | "view" | "entity" | "document" | "channel" | "app" | "url";
-    cellKey?: string;
-    viewId?: string;
-    viewName?: string;
-    appId?: string;
-    url?: string;
-    rendererType?: "native" | "external" | "iframe-srcdoc";
-    placement?: "main" | "side" | "floating" | "modal" | "popover" | "embed";
-    displayMode?: "compact" | "medium" | "full";
-    props?: Record<string, unknown>;
-    title?: string;
-    meta?: Record<string, unknown>;
-}
-interface TemplateSidebarItem {
-    kind: "app" | "view" | "profile" | "external" | "cell";
-    appId?: string;
-    viewName?: string;
-    viewId?: string;
-    profileSlug?: string;
-    url?: string;
-    cellKey?: string;
-    cellProps?: Record<string, unknown>;
-    /** When present, bypasses kind-based dispatch — full surface control */
-    surface?: TemplateSidebarSurface;
-    label?: string;
-    icon?: string;
-    section?: string;
-    matchUrls?: string[];
-}
-interface TemplateLayoutConfig {
-    pinnedApps?: string[];
-    defaultView?: string;
-    /**
-     * Canonical first screen for this workspace.
-     *
-     * `undefined` means the template has no opinion during reconciliation,
-     * `null` explicitly returns the workspace to its home surface, and a
-     * descriptor replaces the current primary surface. */
-    primarySurface?: TemplatePrimarySurface | null;
-    /** Compatibility input only. New templates should use `app:` or `primarySurface`. */
-    defaultApp?: string | null;
-    theme?: string;
-    sidebarItems?: TemplateSidebarItem[];
-}
-interface TemplateBentoBlock {
-    kind: "view" | "widget";
-    viewName?: string;
-    widgetType?: string;
-    pos: {
-        x: number;
-        y: number;
-        w: number;
-        h: number;
-    };
-    config?: Record<string, unknown>;
-    overrides?: Record<string, unknown>;
-}
-interface TemplateProfileEntityBentoTemplates {
-    [profileSlug: string]: {
-        blocks: Array<Record<string, unknown>>;
-    };
-}
-/** Mirrors `WorkspaceSourceRole` in synap-backend `schema/workspaces.ts`. */
-type TemplateSourceRole = "provider" | "consumer" | "provider-consumer";
-/** Mirrors `WorkspaceDefaultSource` in synap-backend `schema/workspaces.ts`. */
-interface TemplateDefaultSource {
-    /** The workspace id that supplies this capability domain. */
-    workspaceId: string;
-    /** The capability domain this source satisfies (e.g. "brand", "strategy"). */
-    capability?: string;
-    /** Optional profile slug the source resolves to. */
-    profileSlug?: string;
-    /** Human label for the source. */
-    label?: string;
-}
-interface TemplateOnboardingCollectTarget {
-    /** Profile slug to populate (e.g. "audience", "competitor"). */
-    profileSlug: string;
-    /** Human description of what to capture for this target. */
-    what: string;
-    /** Roughly how many to expect — guides interview depth. */
-    cardinality?: "one" | "few" | "several";
-    /** Key fields the agent should make sure to fill. */
-    keyFields?: string[];
-}
-interface TemplateOnboardingExpertise {
-    /**
-     * Concrete starting points the agent PROPOSES instead of asking blank —
-     * "most X do Y, want that as a starting point?". Grounds the agent's
-     * proposals in real domain knowledge (never fabricates strategy — for
-     * mission/positioning these FRAME, they don't invent the answer).
-     */
-    starters?: string[];
-    /**
-     * Blind spots founders in this domain commonly miss. The agent proactively
-     * surfaces these if the founder hasn't — catching what they don't say.
-     */
-    blindSpots?: string[];
-    /** What a GREAT result looks like here — the bar the agent pushes toward. */
-    bar?: string;
-}
-interface TemplateOnboarding {
-    /** The outcome this onboarding achieves, in one sentence. */
-    goal: string;
-    /** Domain framing/voice the agent adopts for THIS workspace (the persona). */
-    framing: string;
-    /**
-     * Authored domain expertise the agent leads with (optional). Turns the
-     * interview from "extract what the founder knows" into "resolve what they
-     * lack". See the `onboard` skill's "Lead with your expertise" step.
-     */
-    expertise?: TemplateOnboardingExpertise;
-    /** What structured data to collect (entities to create + their key fields). */
-    collect: TemplateOnboardingCollectTarget[];
-    /** A few opening questions — the agent adapts from here, never rigid. */
-    openingQuestions?: string[];
-    /** "Done" signal the agent self-evaluates against. */
-    doneWhen?: string;
-}
-interface TemplatePlaybookParam {
-    name: string;
-    type: "text" | "number" | "entity" | "choice" | "boolean";
-    label?: string;
-    required?: boolean;
-    defaultValue?: unknown;
-}
-interface TemplatePlaybook {
-    name: string;
-    description?: string;
-    goalTemplate: string;
-    params?: TemplatePlaybookParam[];
-    executor?: "is-agent" | "external-agent" | "hybrid";
-    inputStrategy?: "none" | "static" | "rotating" | "query";
-    channelSpec?: {
-        type: "GROUP" | "AGENT_COLLAB" | "THREAD";
-        members?: string[];
-        aiReactionMode?: "on_mention" | "always" | "never";
-    };
-    /**
-     * A cron schedule that maintains ONE backing cron automation (a single
-     * `playbook_run` node) which the pod's `automation-cron-scheduler` fires.
-     * `enabled` is read STRICTLY (`materializePlaybookCronAutomation` requires
-     * `enabled === true`) — omit it and the backing cron is NEVER created, so the
-     * playbook silently never fires. Always set it explicitly.
-     */
-    schedule?: {
-        cron: string;
-        enabled: boolean;
-    } | null;
-    /** tool/skill keys this playbook grants. */
-    grants?: string[];
-    /**
-     * Free-form playbook metadata → `playbooks.metadata`. Carries the propose-only
-     * governance marker for unattended maintenance playbooks:
-     * `{ governance: { forceProposeWrites: true } }` — every agent write in the
-     * playbook's scheduled sessions then routes to a reviewable proposal.
-     */
-    metadata?: Record<string, unknown>;
-    /**
-     * The entity kind this playbook operates over, persisted to
-     * `playbooks.subject_profile`. Makes the playbook matchable by
-     * `playbooks.matchForEntity` (filters `subject_profile->>'profileSlug'`), so a
-     * captured entity of this kind can auto-launch the playbook as a session.
-     */
-    subjectProfile?: {
-        profileSlug: string;
-        filter?: Record<string, unknown>;
-    };
-    status?: "draft" | "active" | "paused";
-}
-interface TemplateAutomation {
-    /** Stable local key (unused on the wire today — reserved for dedup/refs). */
-    key?: string;
-    name: string;
-    description?: string;
-    triggerType: "event" | "cron" | "webhook" | "manual";
-    triggerConfig?: Record<string, unknown>;
-    flow: {
-        nodes: unknown[];
-        edges: unknown[];
-        precondition?: string;
-    };
-    status?: "draft" | "active" | "paused";
-}
-interface TemplateCommandDerivedInput {
-    name: string;
-    label?: string;
-    /** Mirrors `DerivedInput.type` (text | number | entity | view | choice). */
-    type?: string;
-}
-interface TemplateCommand {
-    title: string;
-    promptTemplate: string;
-    derivedInputs?: TemplateCommandDerivedInput[];
-    /** text | proposal | view */
-    outputMode?: string;
-    canCreateViews?: boolean;
-    /** read_only | propose_writes */
-    permissionsProfile?: string;
-}
-interface TemplateActionPlacement {
-    /** Entity kind whose detail surface this action appears on. */
-    profileSlug: string;
-    /** Where the action renders. Only "entity-detail" is consumed today. */
-    surface: "entity-detail" | string;
-    /** What the action does when clicked. */
-    kind: "capability" | "playbook" | "automation";
-    /**
-     * Reference to the thing to run: a capability verb key, or a playbook /
-     * automation NAME (resolved to a row id at apply time).
-     */
-    ref: string;
-    /** Human label shown on the action button. */
-    label: string;
-    /** Additional entity-state requirements, evaluated by the rendering surface. */
-    when?: {
-        /** All listed workspace facets must be present on the entity. */
-        requiredFacetSlugs?: string[];
-        /** Entity property values that must equal their configured literal values. */
-        propertyEquals?: Record<string, unknown>;
-        /** Any configured property/value match makes the action applicable. */
-        propertyAnyEquals?: Record<string, unknown[]>;
-        /** Entity property values that must not equal their configured literal values. */
-        propertyNotEquals?: Record<string, unknown>;
-    };
-    /** Explicit intent required before a consequential action is launched. */
-    confirmation?: {
-        title: string;
-        description?: string;
-        confirmLabel?: string;
-    };
-}
-interface TemplateIntegration {
-    /** Capability template key to install (matches a capability template). */
-    templateKey: string;
-    /** Override default params with {{var}} interpolation. */
-    params?: Record<string, string>;
-    /** "apply" (create+update) or "install" (create only). */
-    mode?: "apply" | "install";
-}
-interface TemplateExtendsRef {
-    source: string;
-    import?: {
-        profiles?: string[];
-        views?: string[];
-    };
-}
-/**
- * A dependency this template declares on ANOTHER template/package. The install
- * resolver (backend `POST /api/hub/packages/apply`) reads these to build the
- * pod's template graph: every dependency is ensured present before this
- * template is applied — missing ones install first (topologically) — and a
- * `compose` dependency LAYERS this template's schema additively onto the
- * dependency's workspace instead of creating a second workspace.
- *
- * This is the general composition primitive: a BASE template carries the
- * agnostic data model; an OVERLAY template `compose`s onto it and adds the
- * use-case-specific data (e.g. `blockchain-ecosystem` → `ecosystem`,
- * `grants` → `operations`). Distinct from `extends` (which imports from a live
- * workspace, tRPC-only) — `dependencies` is template→template.
- */
-/**
- * PACKAGE_DEPENDENCY_KINDS — the dependency-kind vocabulary, declared ONCE.
- *
- * This tuple exists so consumers can IMPORT the vocabulary instead of
- * hand-copying it. `TemplateDependency` is mirrored by hand in several other
- * places — a comment cannot fail a build, an import can, but these mirrors live
- * in repos this package does not own, so they must match this list EXACTLY:
- *
- *   - marketplace            `features/marketplace/src/types.ts`
- *   - onboarding             `features/onboarding/src/{templates/workspace-templates,components/WorkspacePreview}.ts(x)`
- *   - browser                `InstallPackageDialog.tsx`
- *   - synap-backend          `package-definition.ts` (`PackageDependencyKind`)
- *   - hub-protocol REST      `rest/packages.ts` (zod enum)
- *   - control-plane-api      `db/schema/packages.ts` (`TemplateDependency` type)
- *                            + `routes/packages.ts` (`DEPENDENCY_KINDS` zod enum)
- *
- * These are the 7 literals the wire accepts, in lockstep with the CP publish
- * enum (`DEPENDENCY_KINDS = [...PACKAGE_TYPES, "automation"]`, CP
- * `routes/packages.ts`), the hub install enum (`rest/packages.ts`), and the
- * backend resolver's `PackageDependencyKind` (`@synap/database`).
- *
- * Resolver behaviour (backend `package-dependency-resolver.ts`):
- *   - `workspace`         → resolve+install; the ONLY kind that may `compose`.
- *   - `capability` / `cell` → resolve+install, always `require`d (presence).
- *   - `skill` / `workflow` / `view` / `automation` → ACCEPTED and `require`d
- *     present, surfaced as `required-absent` (non-fatal) — no standalone by-slug
- *     applier on the pod yet; when one grows, give the kind its own branch.
- *
- * `'automation'` is legacy vocabulary: CP migration `0049_package_vocabulary`
- * renamed the `automation` package category → `workflow` (which absorbs
- * automation + playbook, `PACKAGE_TYPES` in CP `db/schema/packages.ts`). It
- * stays accepted on the wire — and therefore in this tuple — for back-compat
- * with dependencies published before the rename.
- */
-declare const PACKAGE_DEPENDENCY_KINDS: readonly ["workspace", "capability", "skill", "workflow", "view", "cell", "automation"];
-/** What a `TemplateDependency` points at. Derived — never re-declare the list. */
-type PackageDependencyKind = (typeof PACKAGE_DEPENDENCY_KINDS)[number];
-interface TemplateDependency {
-    /** Slug of the template/package this one depends on. */
-    slug: string;
-    /**
-     * What the dependency is. Default `'workspace'`. Only `'workspace'`
-     * dependencies can be `compose`d; every other kind is always `require`d
-     * present without merging.
-     */
-    kind?: PackageDependencyKind;
-    /**
-     * How this template relates to the dependency:
-     * - `'compose'`: this template is an OVERLAY on the dependency's workspace.
-     *   The base is installed first if absent, then this template's profiles /
-     *   roles / relations / views are applied ADDITIVELY onto the base workspace
-     *   — no separate workspace is created for this template.
-     * - `'require'` (default): the dependency must be present on the pod as its
-     *   own artifact, but this template does not merge into it.
-     */
-    relation?: "compose" | "require";
-    /**
-     * Short human reason shown in the install-time "this also installs…" prompt.
-     */
-    reason?: string;
-}
-interface TemplateMeta {
-    slug: string;
-    name: string;
-    description: string;
-    icon: string;
-    color: string;
-    tags?: string[];
-    isPublic?: boolean;
-    /**
-     * Human-facing subject area used to SECTION the marketplace (CLI `market
-     * list`, browser New Space + catalog). Authored here so grouping is a
-     * property of the template, read by every surface — never re-derived from a
-     * hardcoded slug→group map in a consumer. NOT `category` (that is the
-     * PACKAGE TYPE — `workspace`/`capability`/…). Optional and open: an unknown
-     * or missing value is grouped, never dropped — see `./domains.ts`.
-     */
-    domain?: string;
-}
-interface WorkspaceYaml {
-    /** Template metadata — not sent to backend, used for listing/UI */
-    meta: TemplateMeta;
-    /** The workspace definition sent to createFromDefinition */
-    workspace: {
-        name: string;
-        description: string;
-        proposalId?: string;
-        subtype?: string;
-        /**
-         * Workspace classifier — consumed by createFromDefinition (settings.workspaceType,
-         * creator-role + agent-workspace behavior). Mirrors the backend union.
-         */
-        workspaceType?: "personal" | "agent" | "project" | "operational";
-        visibility?: string;
-        /** Capabilities this workspace provides (e.g. "brand.library", "content.pipeline") */
-        capabilities?: string[];
-        /**
-         * Cross-workspace dependency roles.
-         * E.g. { brand: "consumer", content: "provider" }
-         * "consumer" = this workspace reads from another workspace of that capability
-         * "provider" = this workspace provides that capability to others
-         */
-        sourceRoles?: Record<string, TemplateSourceRole>;
-        /**
-         * Pins which workspace supplies each capability domain for this workspace.
-         * E.g. { brand: { workspaceId: "..." } } — read by the IS source resolver
-         * (resolveBrandWorkspaceId / resolveFoundationWorkspaceId) before falling
-         * back to provider role. Usually set at runtime, not in a template, but
-         * carried here so it round-trips through the canonical seam.
-         */
-        defaultSources?: Record<string, TemplateDefaultSource>;
-    };
-    /** Entity profiles — the data schema */
-    profiles: TemplateProfile[];
-    /** Curated views — only the ones that add value */
-    views?: TemplateView[];
-    /** Schema-level links between entity types */
-    entityLinks?: TemplateEntityLink[];
-    /**
-     * Domain-level relation TYPE vocabulary seeded into the workspace's
-     * `relation_defs`. Distinct from `entityLinks` (profile→profile edges): a
-     * relation def stands alone and carries `description`/`isDirectional`/`uiHints`.
-     * The `base` template carries the universal defaults. See {@link TemplateRelationDef}.
-     */
-    relationDefs?: TemplateRelationDef[];
-    /**
-     * Workspace-scoped intelligence commands (prompt-template "Default Command
-     * Pack") seeded with the workspace. The `base` template carries the universal
-     * pack. See {@link TemplateCommand}.
-     */
-    commands?: TemplateCommand[];
-    /** Initial data to seed on workspace creation */
-    seedEntities?: TemplateSeedEntity[];
-    /** Relations between seed entities, created on provisioning */
-    suggestedRelations?: TemplateSuggestedRelation[];
-    /** Entity-card display templates */
-    displayTemplates?: TemplateDisplayTemplate[];
-    /** App reference — what opens as first screen */
-    app?: TemplateAppRef;
-    /** Browser sidebar + layout config */
-    layout?: TemplateLayoutConfig;
-    /** Bento dashboard */
-    bento?: {
-        viewName?: string;
-        blocks?: TemplateBentoBlock[];
-    };
-    /** Per-profile entity bento layouts */
-    profileEntityBentoTemplates?: TemplateProfileEntityBentoTemplates;
-    /** Playbooks (session templates) seeded with the workspace */
-    playbooks?: TemplatePlaybook[];
-    /**
-     * Flow-based automations (WHEN→THEN triggers) seeded with the workspace.
-     * Applier-only — see {@link TemplateAutomation}.
-     */
-    automations?: TemplateAutomation[];
-    /**
-     * Entity-detail action placements seeded into `settings.actionPlacements`.
-     * See {@link TemplateActionPlacement}.
-     */
-    actionPlacements?: TemplateActionPlacement[];
-    /** Capability templates (tools/connectors) to install on provisioning */
-    integrations?: TemplateIntegration[];
-    /**
-     * Per-workspace onboarding context. Written to workspace.settings.onboarding
-     * and read by the shared `onboard` skill to run a domain-specific adaptive
-     * interview — no per-domain skill file needed.
-     */
-    onboarding?: TemplateOnboarding;
-    /** Inherit profiles/views from other workspaces */
-    extends?: TemplateExtendsRef[];
-    /**
-     * Template-composition dependencies — other templates this one needs. The
-     * install resolver installs missing dependencies first and, for a `compose`
-     * dependency, layers this template additively onto the dependency's
-     * workspace. See {@link TemplateDependency}.
-     */
-    dependencies?: TemplateDependency[];
-}
+import { W as WorkspaceYaml, T as TemplateDependency, a as TemplateLifecycleOption, b as TemplateLifecycleOptionWaits } from './define-DqoItRiR.js';
+export { B as BentoViewBlockWire, c as BentoWidgetBlockWire, d as BuiltSpacePackage, e as BuiltSpacePackageCell, I as INTENT_LABEL_MAX, P as PACKAGE_DEPENDENCY_KINDS, f as PackageAutomationWire, g as PackageDefinitionOutput, h as PackageDependencyKind, S as START_EXAMPLE_RANGE, i as START_STARTERS_RANGE, j as START_VIEWS_MAX, k as SpacePackageCellWire, l as SplitBentoBlocks, m as TemplateActionPlacement, n as TemplateAppKind, o as TemplateAppRef, p as TemplateAutomation, q as TemplateBentoBlock, r as TemplateDefaultSource, s as TemplateDisplayTemplate, t as TemplateEntityLink, u as TemplateExtendsRef, v as TemplateIntegration, w as TemplateIntent, x as TemplateLayoutConfig, y as TemplateMeta, z as TemplateOnboarding, A as TemplateOnboardingCollectTarget, C as TemplatePlaybook, D as TemplatePlaybookParam, E as TemplatePrimarySurface, F as TemplateProfile, G as TemplateProfileEntityBentoTemplates, H as TemplateProperty, J as TemplateSeedEntity, K as TemplateSidebarItem, L as TemplateSidebarSurface, M as TemplateSourceRole, N as TemplateSpacePackage, O as TemplateSpacePackageCell, Q as TemplateStart, R as TemplateSuggestedRelation, U as TemplateView, V as ToDefinitionResult, X as WorkspaceDefinitionInput, Y as WorkspaceJsonValue, Z as WorkspacePrimarySurface, _ as WorkspacePrimarySurfaceViewReference, $ as normalizeTemplateLayout, a0 as spacePackageCells, a1 as splitBentoBlocks, a2 as toAutomationWire, a3 as toPackageDefinition, a4 as toWorkspaceDefinition } from './define-DqoItRiR.js';
+import '@synap-core/types/presentation';
+import '@synap-core/types/space-brief';
+import '@synap-core/types/capability-intents';
 
 declare const WORKSPACE_TEMPLATES: Record<string, WorkspaceYaml>;
 type WorkspaceTemplateSlug = keyof typeof WORKSPACE_TEMPLATES;
@@ -688,6 +62,21 @@ interface PackageItemSummary {
     key: string;
     name: string;
 }
+/**
+ * The DERIVED template kinds a playbook sub-item carries. A playbook's own
+ * `scope` decides it — `"project"` is a method a project runs as a track, any
+ * other value (the schema default `session`) is one sitting of work. The author
+ * never declares it. The control plane derives the SAME rule in SQL for remote
+ * rows (`packageItemsSql`, synap-control-plane-api `routes/packages.ts`); the
+ * user-facing noun is `resolveTemplateNoun(scope)` (`@synap-core/types/vocabulary`).
+ */
+declare const TRACK_TEMPLATE_ITEM_KIND = "track-template";
+declare const WORK_TEMPLATE_ITEM_KIND = "work-template";
+/** Playbooks → `{kind,key,name}` sub-items. `key` = name (playbooks carry no key). */
+declare function derivePlaybookItems(playbooks: ReadonlyArray<{
+    name?: unknown;
+    scope?: unknown;
+} | null | undefined> | null | undefined): PackageItemSummary[];
 /**
  * A bundled template — the canonical `WorkspaceYaml` this package ships. Callers
  * pass `listPublicTemplates()` (18) or `listWorkspaceTemplates()` (21); the door
@@ -1113,8 +502,8 @@ interface ConceptViolation {
  *
  * Currently EMPTY, and that is the healthy state. The two entries this list was
  * born for — `crm-lead|lead` and `client|crm-client` — were RESOLVED rather
- * than kept: business-developer.yaml now re-declares the shared `lead`/`client`
- * roles and carries its business-development fields as workspace-overlay
+ * than kept: crm.yaml (business-developer folded into it, 2026-10-12)
+ * re-declares the shared `lead`/`client` roles and carries its business-development fields as workspace-overlay
  * PROPERTIES. One concept, one slug, workspace-specific fields. Rule 3 below
  * would have failed CI had the entries been left behind.
  */
@@ -1218,6 +607,21 @@ declare function groupByDomain<T>(items: readonly T[], domainOf: (item: T) => st
  * so it is always present. It is DB-free (only `import type` internally), so it
  * needs no injection: the flow-node contract check runs for every caller
  * (build / check-converters / CLI / CP) automatically.
+ *
+ * A SECOND RUNTIME IMPORT: `@synap-core/types/capability-intents`, for the
+ * `taskIntents` membership check. This one resolves from the linked workspace
+ * package rather than a sibling file, and it is a LEAF with no generated
+ * dependency, so it is present under the type-stripper for the same reason
+ * `./validate-flow.ts` is. It is intentionally NOT injected like the
+ * converters: the intent vocabulary is a leaf VALUE, not a compiled template
+ * converter, and a validator that silently skips its check when a caller forgot
+ * to pass converters would be worse than one that resolves a constant.
+ *
+ * A THIRD RUNTIME IMPORT: `@synap-core/types/space-brief`, for the declared
+ * `skills[]` shape check. Same class as `capability-intents` — a pure,
+ * dependency-free leaf resolved from the linked workspace package. The rule is
+ * the SAME `validateSpaceSkillDeclaration` the pod's applier runs, so authoring
+ * and install cannot drift on what a skill declaration is.
  */
 
 interface ValidationError {
@@ -1321,6 +725,39 @@ declare const SYSTEM_PROFILES: Set<string>;
  * the same closure serves every caller.
  */
 declare function collectBaseProfileSlugs(data: WorkspaceYaml, resolveDep: (slug: string) => WorkspaceYaml | undefined, seen?: Set<string>): Set<string>;
+/**
+ * The fields of a lifecycle option and of a step's declared wait. MIRROR of
+ * `LifecycleOption` / `LifecycleOptionWaits` (`@synap-core/types/lifecycle`,
+ * `option.ts`), same reason as above; `lifecycle-waits.parity.test.ts` pins
+ * them to that source and to the pod's parser.
+ */
+declare const LIFECYCLE_OPTION_FIELDS: readonly ["key", "label", "category", "tone", "humanOnly", "stuckAfterDays", "dateBinding", "waits"];
+declare const LIFECYCLE_OPTION_WAITS_FIELDS: readonly ["on", "waitKind", "refFrom", "dateBinding"];
+/**
+ * What a step may say it waits on: MIRROR of the pod's `HOLD_ON` without
+ * `unspecified` (`parseOptionWaits`, `utils/lifecycle-model.ts`: a step that
+ * says `unspecified` says nothing, and the pod refuses it).
+ */
+declare const LIFECYCLE_WAITS_ON: readonly ["person", "agent", "external", "thing", "decision", "date", "nobody"];
+/** MIRROR of `WAIT_KINDS` (`@synap-core/types/units`, `wait-kind.ts`), same reason as above. */
+declare const LIFECYCLE_WAIT_KINDS: readonly ["answer", "approval", "send", "try_it", "access", "decide", "their_reply", "their_document", "signature", "payment", "vendor", "agent_work", "agent_stopped", "ci", "devbox_job", "merge_queue", "red_main", "deploy", "another_work", "date", "nobody"];
+/**
+ * The problems of one option's `dateBinding` and `waits`, in the pod's words
+ * and by the pod's rules (`parseLifecycleOptions` / `parseOptionWaits`): a
+ * property slug, never on a done/lost option; `waits.on` one of
+ * {@link LIFECYCLE_WAITS_ON}, `waitKind` one of {@link LIFECYCLE_WAIT_KINDS},
+ * `refFrom` / `dateBinding` property slugs, no other field. Exactly what the
+ * pod accepts: nothing more (it does not check that the property exists).
+ */
+declare function lifecycleOptionWaitsProblems(option: {
+    key?: unknown;
+    category?: unknown;
+    dateBinding?: unknown;
+    waits?: unknown;
+}): Array<{
+    field: "dateBinding" | "waits";
+    message: string;
+}>;
 /**
  * Validate ONE template. Pure: returns `{ ok, errors }`, never exits. Covers the
  * per-template rules formerly split across build.mjs `validate()` (required
@@ -1330,49 +767,114 @@ declare function collectBaseProfileSlugs(data: WorkspaceYaml, resolveDep: (slug:
  * viewName present, bentoViewName + capabilities parity — the last group only
  * when `opts.converters` is supplied).
  */
-declare function validateTemplate(tpl: WorkspaceYaml, opts?: ValidateOptions): ValidateResult;
+declare function validateTemplate(authored: WorkspaceYaml, authoredOpts?: ValidateOptions): ValidateResult;
 
 /**
- * Node-contract validation for automation flow definitions.
- *
- * The persist doors and the install/apply doors validate flow SHAPE only
- * (`{ nodes: [], edges: [] }`). A semantically-broken flow — a `channel_message`
- * output with a typo'd `channelType`, a `capability` node with no `verbId`, an
- * edge to a nonexistent node, a cycle, an unknown `node.type` — passes the shape
- * check and only fails at RUNTIME (automation-executor.ts throws mid-run). For a
- * template automation this is worse: it validates green at author time and then
- * SILENTLY never fires on a live pod.
- *
- * `validateFlowDefinition` closes that gap: a PURE, synchronous, DB-free function
- * that rejects malformed flows with actionable per-node errors. It is called by
- * `validateTemplate` (this package) so `synap market validate` / the build gate /
- * the CP publish door all run the same contract check, and by the pod's persist
- * doors.
- *
- * ── SSOT-IN-WAITING — temporary duplicate ────────────────────────────────────
- * This is a PURE copy of synap-backend's
- * `packages/api/src/services/automations/validate-flow.ts` (the current runtime
- * SSOT, which carries the `@synap/database` COMPILE-TIME drift guard). This copy
- * exists so `validateTemplate` — which runs in THIS published, backend-independent
- * package (CLI `synap market validate` / build gate / CP publish) — can catch
- * broken automation flows at AUTHOR time. It is intentionally free of any
- * `@synap/database` import (this package depends only on zod + js-yaml), so the
- * compile-time drift guard cannot live here; it stays in backend.
- *
- * The two copies are kept byte-identical (logic) by `validate-flow.drift.test.ts`
- * in this package, which reads BOTH files and fails if they diverge.
- *
- * CUTOVER (collapse to ONE SSOT): publish `@synap-core/workspace-templates`, bump
- * synap-backend (`^0.7.1`) and CP (`^0.9.2`) deps to that version, then replace
- * backend's validate-flow.ts body with a re-export FROM HERE (keeping backend's
- * `AssertExact` guard binding these arrays to the `@synap/database` unions).
- * Until then: keep the constant arrays below identical to `@synap/database`
- * `schema/automations.ts`.
+ * The ten base lifecycles, as TEMPLATE-TIME presets.
+ * ==================================================
+ *
+ * A profile's lifecycle may be written in full (`options: [...]`) or adopt one
+ * of the ten bases below and say only how it differs:
+ *
+ *   lifecycle:
+ *     property: brand-status
+ *     adopts: asset
+ *     rename: { in-review: studied, deprecated: archived }  # base key → this kind's key
+ *     drop: [in-review]                                      # base keys this kind does not use
+ *     add:                                                   # steps the base does not have
+ *       - { key: signed, category: active, after: sent }     # `after` / `before` a resulting key
+ *     humanOnly: { deprecated: true }                        # per resulting key
+ *     stuckAfterDays: { sent: 14 }                           # per resulting key
+ *     dateBinding: { sent: dueDate }                         # per resulting key
+ *     waits: { sent: { on: external, waitKind: payment } }   # per resulting key
+ *
+ * `resolveLifecyclePresets` compiles that into the flat declaration the pod
+ * already stores (`{ property, options }`), and fills the lifecycle select's
+ * `enumValues` from the options when the YAML leaves them out (the pod
+ * replaces them with the option keys anyway, `declare-lifecycle.ts`). There is
+ * no inheritance at runtime: the pod never sees `adopts`, and a change to a
+ * base reaches a kind only when its template is rebuilt and republished.
+ *
+ * Decision: status-flow plan, document aac47c4a, Q1.3 ("ten bases, as template
+ * presets, not a runtime engine"); the steps are the deep dive's table
+ * (document 152478c2 §1), `humanOnly` and `stuckAfterDays` where it gives them
+ * (§1 table 👤, §7 agreement sketch). The deep dive's "waits on the outside" (⧗)
+ * is not encoded in the bases; a kind declares a step's wait (`waits`) and its
+ * date (`dateBinding`) itself, on an added step or per resulting key. Their
+ * shapes are the validator's (`lifecycleOptionWaitsProblems`, the pod's rules):
+ * this compiler only carries them.
+ *
+ * Callers: `generate.mjs` (build + every corpus test), `validateTemplate` (any
+ * authored YAML), `toWorkspaceDefinition` / `toPackageDefinition`, and the
+ * catalog loader (through the built dist). The resolver is idempotent: a flat
+ * lifecycle with its `enumValues` comes back as the same object.
+ *
+ * Only `import type` here: `build.mjs` and `generate.mjs` load this file under
+ * Node's type stripping, before `dist/` exists.
+ */
+
+type BaseStep = Pick<TemplateLifecycleOption, "key" | "category" | "tone" | "humanOnly" | "stuckAfterDays">;
+/** The ten bases: default steps in picker order (open → active → paused → done → lost). */
+declare const BASE_LIFECYCLES: {
+    readonly "work-item": readonly [BaseStep, BaseStep, BaseStep, BaseStep, BaseStep, BaseStep, BaseStep];
+    readonly run: readonly [BaseStep, BaseStep, BaseStep, BaseStep, BaseStep, BaseStep];
+    readonly decision: readonly [BaseStep, BaseStep, BaseStep, BaseStep, BaseStep, BaseStep, BaseStep, BaseStep];
+    readonly asset: readonly [BaseStep, BaseStep, BaseStep, BaseStep];
+    readonly publication: readonly [BaseStep, BaseStep, BaseStep, BaseStep, BaseStep, BaseStep, BaseStep];
+    readonly agreement: readonly [BaseStep, BaseStep, BaseStep, BaseStep, BaseStep, BaseStep, BaseStep, BaseStep];
+    readonly pipeline: readonly [BaseStep, BaseStep, BaseStep, BaseStep, BaseStep, BaseStep, BaseStep];
+    readonly relationship: readonly [BaseStep, BaseStep, BaseStep, BaseStep, BaseStep];
+    readonly offering: readonly [BaseStep, BaseStep, BaseStep, BaseStep, BaseStep, BaseStep];
+    readonly initiative: readonly [BaseStep, BaseStep, BaseStep, BaseStep, BaseStep, BaseStep, BaseStep];
+};
+type BaseLifecycleName = keyof typeof BASE_LIFECYCLES;
+/** A step a kind adds to its base. */
+interface TemplateLifecycleStepAdd extends TemplateLifecycleOption {
+    /** Insert after this resulting key (default: after the last step of its category). */
+    after?: string;
+    /** Insert before this resulting key. */
+    before?: string;
+}
+/** The authored form of a lifecycle that adopts a base; compiled to `TemplateLifecycle`. */
+interface TemplateLifecycleAdoption {
+    property: string;
+    adopts: BaseLifecycleName;
+    /** Base key → this kind's key. */
+    rename?: Record<string, string>;
+    /** Base keys this kind does not use. */
+    drop?: string[];
+    add?: TemplateLifecycleStepAdd[];
+    /** Per resulting key; `false` removes a base's person-only mark. */
+    humanOnly?: Record<string, boolean>;
+    /** Per resulting key. */
+    stuckAfterDays?: Record<string, number>;
+    /** Per resulting key: the date property the step is bound to. */
+    dateBinding?: Record<string, string>;
+    /** Per resulting key: the wait the step declares. */
+    waits?: Record<string, TemplateLifecycleOptionWaits>;
+}
+interface LifecyclePresetProblem {
+    path: string;
+    message: string;
+}
+interface LifecyclePresetResolution {
+    /** The template with every resolvable lifecycle flat; the same object when nothing changed. */
+    template: WorkspaceYaml;
+    /** Overlays that could not be resolved; their lifecycle is left as authored. */
+    problems: LifecyclePresetProblem[];
+}
+/**
+ * Compile every `adopts:` lifecycle of a template into its flat declaration and
+ * generate the lifecycle select's `enumValues` where the YAML omits them. Pure;
+ * never throws. An unresolvable overlay is reported and left as authored, so
+ * `validateTemplate` refuses it.
  */
+declare function resolveLifecyclePresets(tpl: WorkspaceYaml): LifecyclePresetResolution;
+
 /** The 23 node types — `AutomationNodeBase.type` union (schema/automations.ts). */
 declare const FLOW_NODE_TYPES: readonly ["trigger", "command", "condition", "delay", "output", "loop", "transform", "fetch", "query", "entity_read", "related_entities", "guard", "compute", "select", "claim", "messages_query", "runs_query", "proposals_query", "switch", "skill", "capability", "sub_automation", "playbook_run"];
-/** The 11 output types — `OutputNodeDef.data.outputType` (schema/automations.ts). */
-declare const FLOW_OUTPUT_TYPES: readonly ["notification", "entity_create", "entity_update", "facet_attach", "facet_update", "facet_detach", "relation_create", "webhook", "channel_message", "session_update", "set_state"];
+/** The 15 output types — `OutputNodeDef.data.outputType` (schema/automations.ts). */
+declare const FLOW_OUTPUT_TYPES: readonly ["notification", "record_observation", "entity_create", "entity_update", "facet_attach", "facet_update", "facet_detach", "relation_create", "webhook", "channel_message", "session_update", "complete_outcome", "post_evidence", "reevaluate_criterion", "set_state"];
 /**
  * The known `config.channelType` values for a `channel_message` output. Mirrors
  * the executor's channel_message resolution (automation-executor.ts). The output
@@ -1429,232 +931,4 @@ declare function validateFlowDefinition(flow: unknown, resolvers?: FlowValidatio
  */
 declare function flowValidationErrorMessage(flow: unknown, resolvers?: FlowValidationResolvers): string | null;
 
-/**
- * @synap-core/workspace-templates — Definition adapter
- *
- * Converts a YAML template (WorkspaceYaml) into the flat payload shape that
- * the backend `workspaces.createFromDefinition` mutation + Hub REST
- * `/workspaces/from-definition` endpoint expect.
- *
- * This is the single canonical seam: every consumer (browser app, onboarding,
- * CLI, marketplace) provisions a workspace through this function so the wire
- * shape never drifts per call-site.
- */
-
-/**
- * A `TemplateAutomation` as the apply door expects it: `flowDefinition`, not
- * the authored `flow` (mirrors `PackagePostWorkspaceBody['automations'][number]`
- * / the Hub `POST /packages/apply` `AutomationSchema`).
- */
-interface PackageAutomationWire {
-    /** Stable template identity; names may be edited without orphaning the flow. */
-    key?: string;
-    name: string;
-    description?: string;
-    triggerType: TemplateAutomation['triggerType'];
-    triggerConfig?: Record<string, unknown>;
-    flowDefinition?: {
-        nodes: unknown[];
-        edges: unknown[];
-        precondition?: string;
-    };
-    status?: TemplateAutomation['status'];
-}
-/** A widget block as the wire expects it: `bentoLayout[]`, keyed by `widgetType`. */
-interface BentoWidgetBlockWire {
-    widgetType: string;
-    pos: TemplateBentoBlock['pos'];
-    config?: Record<string, unknown>;
-}
-/** A view block as the wire expects it: `bentoViewBlocks[]`, keyed by `viewName`. */
-interface BentoViewBlockWire {
-    kind: 'view';
-    viewName: string;
-    pos: TemplateBentoBlock['pos'];
-    overrides?: Record<string, unknown>;
-}
-interface SplitBentoBlocks {
-    bentoLayout: BentoWidgetBlockWire[];
-    bentoViewBlocks: BentoViewBlockWire[];
-}
-/**
- * Produce the canonical persisted layout. A template may author either the
- * top-level `app:` shorthand or an explicit `layout.primarySurface`, never both.
- * Legacy `defaultApp` is the final compatibility fallback. Keeping the property
- * absent preserves a live workspace value during reconciliation; an authored
- * null is retained as an explicit clear.
- */
-declare function normalizeTemplateLayout(layout: TemplateLayoutConfig | undefined, app: TemplateAppRef | undefined): TemplateLayoutConfig | undefined;
-declare function splitBentoBlocks(blocks: TemplateBentoBlock[] | undefined): SplitBentoBlocks;
-/** The flat definition object accepted by createFromDefinition. */
-interface WorkspaceDefinitionInput {
-    workspaceName: string;
-    description: string;
-    proposalId?: string;
-    profiles: WorkspaceYaml['profiles'];
-    views: NonNullable<WorkspaceYaml['views']>;
-    entityLinks: NonNullable<WorkspaceYaml['entityLinks']>;
-    seedEntities: NonNullable<WorkspaceYaml['seedEntities']>;
-    suggestedRelations?: WorkspaceYaml['suggestedRelations'];
-    displayTemplates?: WorkspaceYaml['displayTemplates'];
-    /**
-     * Domain-level relation TYPE vocabulary — the door find-or-creates a
-     * `relation_defs` row per entry (idempotent by slug within the workspace). NOT
-     * `entityLinks` (those are profile→profile edges and drop the rich metadata).
-     * Carried verbatim; the authored form IS the wire form.
-     */
-    relationDefs?: WorkspaceYaml['relationDefs'];
-    /**
-     * Workspace intelligence commands — the door find-or-creates an
-     * `intelligence_commands` row per entry (idempotent by title). Carried
-     * verbatim; the authored form IS the wire form.
-     */
-    commands?: WorkspaceYaml['commands'];
-    layoutConfig: WorkspaceYaml['layout'] | undefined;
-    bentoViewName?: string;
-    /**
-     * WIDGET half of the authored bento union. The door declares this field
-     * (`workspaces.createFromDefinition` zod) and the pod maps it as widgets via
-     * `widget.widgetType`. It was missing from this interface entirely, which is
-     * why `toWorkspaceDefinition` had nowhere to put widgets and dumped the whole
-     * union into `bentoViewBlocks` — where every widget was silently filtered out.
-     */
-    bentoLayout?: BentoWidgetBlockWire[];
-    /** VIEW half of the authored bento union — resolved against the viewMap. */
-    bentoViewBlocks?: BentoViewBlockWire[];
-    profileEntityBentoTemplates?: WorkspaceYaml['profileEntityBentoTemplates'];
-    /**
-     * Capability integrations (→ tools + skills + vault + capability-embedded
-     * automations/playbooks). Emitted from the template's `integrations:` list —
-     * IDENTICAL to what `toPackageDefinition` puts in its `capabilities` field. The
-     * tRPC door (`workspaces.createFromDefinition`) now declares `capabilities` in
-     * its zod input and installs them via the SHARED `applyPackagePostWorkspace`
-     * door (same as Hub `/packages/apply`). It was missing from this interface, so
-     * `toWorkspaceDefinition` had nowhere to put integrations and the browser
-     * BUNDLED install path carried NO capabilities — every capability's
-     * tools/skills/automations silently dropped on that door.
-     */
-    capabilities?: WorkspaceYaml['integrations'];
-    /** Playbooks normalized to the workspace-create input contract. */
-    playbooks?: Array<Record<string, unknown>>;
-    /**
-     * Entity-detail action placements — forwarded verbatim to
-     * `applyPackagePostWorkspace`, which merges them into
-     * `settings.actionPlacements`. The tRPC door (`createFromDefinition`)
-     * declares `actionPlacements` in its zod input and carries them through the
-     * shared apply door. No shape transform: the authored form IS the wire form.
-     */
-    actionPlacements?: WorkspaceYaml['actionPlacements'];
-    /**
-     * Graph-based automations. Deliberately distinct from the legacy
-     * `automations` loop/playbook-trigger wire shape accepted by this door.
-     */
-    flowAutomations?: PackageAutomationWire[];
-    workspaceSubtype?: string;
-    workspaceType?: NonNullable<WorkspaceYaml['workspace']>['workspaceType'];
-    workspaceVisibility?: string;
-    workspaceCapabilities?: string[];
-    sourceRoles?: NonNullable<WorkspaceYaml['workspace']>['sourceRoles'];
-    defaultSources?: NonNullable<WorkspaceYaml['workspace']>['defaultSources'];
-    /** Per-workspace onboarding context — written to settings.onboarding. */
-    onboarding?: WorkspaceYaml['onboarding'];
-    /**
-     * Template-composition dependencies. MUST be forwarded: the backend resolves
-     * these BEFORE materializing this workspace (`workspaces.createFromDefinition`
-     * → `materializeWorkspaceCore` Step 0 → `resolvePackageDependencies`), which
-     * is what installs a `require`d base FIRST and makes shared-profile base
-     * seeding deterministic. Dropping this field silently de-orders provisioning
-     * on the tRPC/UI door — see the note in `toWorkspaceDefinition`.
-     */
-    dependencies?: WorkspaceYaml['dependencies'];
-}
-interface ToDefinitionResult {
-    definition: WorkspaceDefinitionInput;
-    /** Stable idempotency key — the template's proposalId or slug. */
-    proposalId: string;
-    /** Display name for the new workspace. */
-    workspaceName: string;
-    /** Template id for telemetry / dedup. */
-    templateId: string;
-}
-/**
- * Resolve a template (by slug or YAML object) into the createFromDefinition
- * payload. Pass `nameOverride` to rename the workspace at creation time.
- */
-declare function toWorkspaceDefinition(slugOrYaml: string | WorkspaceYaml, nameOverride?: string): ToDefinitionResult;
-/**
- * The unified `PackageDefinition` shape consumed by `POST /api/hub/packages/apply`
- * (CLI `synap launch`) and the CP package registry seeder. It composes the
- * workspace definition with the capability/playbook/onboarding layers. Mirrors
- * `PackageDefinition` in synap-backend `package-definition.ts`. Typed loosely on
- * the layered fields to avoid a backend import; the wire validation lives in the
- * apply endpoint.
- */
-interface PackageDefinitionOutput {
-    _meta: {
-        slug: string;
-        icon?: string;
-        color?: string;
-        domain?: string;
-        tags?: string[];
-        isPublic?: boolean;
-        requiredTier?: string | null;
-    };
-    workspaceName: string;
-    description: string;
-    workspaceType?: WorkspaceYaml['workspace']['workspaceType'];
-    workspaceSubtype?: string;
-    workspaceVisibility?: string;
-    workspaceCapabilities?: string[];
-    sourceRoles?: WorkspaceYaml['workspace']['sourceRoles'];
-    defaultSources?: WorkspaceYaml['workspace']['defaultSources'];
-    profiles: WorkspaceYaml['profiles'];
-    views: NonNullable<WorkspaceYaml['views']>;
-    suggestedEntities: NonNullable<WorkspaceYaml['seedEntities']>;
-    suggestedRelations?: WorkspaceYaml['suggestedRelations'];
-    displayTemplates?: WorkspaceYaml['displayTemplates'];
-    entityLinks?: WorkspaceYaml['entityLinks'];
-    /** Relation-type vocabulary — carried verbatim (authored form IS the wire form). */
-    relationDefs?: WorkspaceYaml['relationDefs'];
-    /** Intelligence commands — carried verbatim (authored form IS the wire form). */
-    commands?: WorkspaceYaml['commands'];
-    /** WIDGET half of the authored bento union — mapped by the pod via `widgetType`. */
-    bentoLayout?: BentoWidgetBlockWire[];
-    /**
-     * VIEW half of the authored bento union. Widgets go to `bentoLayout`, views
-     * here — the pod splits by field (create-workspace-from-definition.ts:1373
-     * reads `bentoViewBlocks`), so both wire fields must be carried. The apply
-     * door's `PackageApplySchema` now declares this field (it is a plain
-     * `z.object`, so an undeclared field would be silently stripped) — the inbound
-     * seam is closed to match this outbound emit.
-     */
-    bentoViewBlocks?: BentoViewBlockWire[];
-    bentoViewName?: string;
-    profileEntityBentoTemplates?: WorkspaceYaml['profileEntityBentoTemplates'];
-    layoutConfig?: WorkspaceYaml['layout'];
-    capabilities?: WorkspaceYaml['integrations'];
-    playbooks?: WorkspaceYaml['playbooks'];
-    /** Flow-based automations — mapped to the apply door's `flowDefinition` field. */
-    automations?: PackageAutomationWire[];
-    /**
-     * Entity-detail action placements — carried verbatim (authored form IS the
-     * wire form). The Hub `PackageApplySchema` (synap-backend
-     * `hub-protocol/rest/packages.ts`) now declares `actionPlacements`
-     * (`z.array(ActionPlacementSchema).optional()`), so BOTH the tRPC
-     * `createFromDefinition` door and the CLI/Hub install path carry it through to
-     * `applyPackagePostWorkspace` — the parity is closed.
-     */
-    actionPlacements?: WorkspaceYaml['actionPlacements'];
-    onboarding?: WorkspaceYaml['onboarding'];
-    /** Template-composition dependencies — resolved by the apply endpoint. */
-    dependencies?: WorkspaceYaml['dependencies'];
-}
-/**
- * Resolve a template (by slug or YAML object) into the full `PackageDefinition`
- * accepted by `POST /api/hub/packages/apply` and the CP registry seeder. This is
- * the single seam the CLI and control-plane use so they read from the canonical
- * package instead of disk-stored JSON.
- */
-declare function toPackageDefinition(slugOrYaml: string | WorkspaceYaml): PackageDefinitionOutput;
-
-export { type AssembleCatalogInput, type BentoViewBlockWire, type BentoWidgetBlockWire, type BundledCatalogEntry, type BundledEntry, CHANNEL_MESSAGE_CHANNEL_TYPES, type CatalogEntry, type CompositionEdge, type CompositionGraph, type CompositionInstalledEntry, type CompositionNode, type CompositionOverlay, type ConceptViolation, type CpPackageRow, DECLARED_DIVERGENCES, type DomainGroup, FLOW_NODE_TYPES, FLOW_OUTPUT_TYPES, type FlowValidationError, type FlowValidationResolvers, type FlowValidationResult, type InstalledTemplate, type LayerTemplateGraphInput, type MergeCatalogInput, type MergeCatalogResult, OTHER_DOMAIN_ID, OTHER_DOMAIN_LABEL, PACKAGE_DEPENDENCY_KINDS, type PackageDefinitionOutput, type PackageDependencyKind, REQUIRED_META_FIELDS, REQUIRED_WORKSPACE_FIELDS, type RemoteCatalogEntry, type RemoteEntry, type RemoteSourceStatus, SYSTEM_PROFILES, type SplitBentoBlocks, TEMPLATE_DOMAINS, type TemplateActionPlacement, type TemplateAppKind, type TemplateAppRef, type TemplateAutomation, type TemplateBentoBlock, type TemplateConverters, type TemplateDefaultSource, type TemplateDependency, type TemplateDisplayTemplate, type TemplateDomain, type TemplateEntityLink, type TemplateExtendsRef, type TemplateIntegration, type TemplateLayoutConfig, type TemplateMeta, type TemplateOnboarding, type TemplateOnboardingCollectTarget, type TemplatePlaybook, type TemplatePlaybookParam, type TemplatePrimarySurface, type TemplateProfile, type TemplateProfileEntityBentoTemplates, type TemplateProperty, type TemplateSeedEntity, type TemplateSidebarItem, type TemplateSidebarSurface, type TemplateSourceRole, type TemplateSuggestedRelation, type TemplateUpdateCheck, type TemplateView, type ToDefinitionResult, type ValidateOptions, type ValidateResult, type ValidationError, WORKSPACE_TEMPLATES, type WorkspaceDefinitionInput, type WorkspaceJsonValue, type WorkspacePrimarySurface, type WorkspacePrimarySurfaceViewReference, type WorkspaceTemplateSlug, type WorkspaceYaml, assembleCatalog, bundledEdgesOf, collectBaseProfileSlugs, computeTemplateUpdates, conceptTerm, domainLabel, findConceptViolations, flowValidationErrorMessage, formatConceptViolations, getWorkspaceTemplate, groupByDomain, isHashVersion, isKnownDomain, layerTemplateGraph, listPublicTemplates, listWorkspaceTemplates, mergeCatalog, normalizeTemplateLayout, rowToRemoteEntry, splitBentoBlocks, toPackageDefinition, toWorkspaceDefinition, validateFlowDefinition, validateTemplate };
+export { type AssembleCatalogInput, BASE_LIFECYCLES, type BaseLifecycleName, type BundledCatalogEntry, type BundledEntry, CHANNEL_MESSAGE_CHANNEL_TYPES, type CatalogEntry, type CompositionEdge, type CompositionGraph, type CompositionInstalledEntry, type CompositionNode, type CompositionOverlay, type ConceptViolation, type CpPackageRow, DECLARED_DIVERGENCES, type DomainGroup, FLOW_NODE_TYPES, FLOW_OUTPUT_TYPES, type FlowValidationError, type FlowValidationResolvers, type FlowValidationResult, type InstalledTemplate, LIFECYCLE_OPTION_FIELDS, LIFECYCLE_OPTION_WAITS_FIELDS, LIFECYCLE_WAITS_ON, LIFECYCLE_WAIT_KINDS, type LayerTemplateGraphInput, type LifecyclePresetProblem, type LifecyclePresetResolution, type MergeCatalogInput, type MergeCatalogResult, OTHER_DOMAIN_ID, OTHER_DOMAIN_LABEL, REQUIRED_META_FIELDS, REQUIRED_WORKSPACE_FIELDS, type RemoteCatalogEntry, type RemoteEntry, type RemoteSourceStatus, SYSTEM_PROFILES, TEMPLATE_DOMAINS, TRACK_TEMPLATE_ITEM_KIND, type TemplateConverters, TemplateDependency, type TemplateDomain, type TemplateLifecycleAdoption, type TemplateLifecycleStepAdd, type TemplateUpdateCheck, type ValidateOptions, type ValidateResult, type ValidationError, WORKSPACE_TEMPLATES, WORK_TEMPLATE_ITEM_KIND, type WorkspaceTemplateSlug, WorkspaceYaml, assembleCatalog, bundledEdgesOf, collectBaseProfileSlugs, computeTemplateUpdates, conceptTerm, derivePlaybookItems, domainLabel, findConceptViolations, flowValidationErrorMessage, formatConceptViolations, getWorkspaceTemplate, groupByDomain, isHashVersion, isKnownDomain, layerTemplateGraph, lifecycleOptionWaitsProblems, listPublicTemplates, listWorkspaceTemplates, mergeCatalog, resolveLifecyclePresets, rowToRemoteEntry, validateFlowDefinition, validateTemplate };