@synap-core/workspace-templates 0.7.0 → 0.7.2

package/dist/index.d.ts

@@ -751,6 +751,177 @@ declare function isHashVersion(version: string | undefined): boolean;
  */
 declare function computeTemplateUpdates(installed: InstalledTemplate[], catalog: CatalogEntry[], bundleVersion?: string): TemplateUpdateCheck[];
 
+/**
+ * layerTemplateGraph — the KEYSTONE composition-graph engine.
+ * ============================================================
+ *
+ * Today the CLI (`synap-cli/src/commands/market.ts` `buildCompositionTrees`)
+ * renders template composition as a nested TREE: `buildDependencyNode`
+ * rebuilds a fresh `TreeNode` for every OCCURRENCE of a slug on every path, so
+ * a widely-required base (e.g. `foundation`) prints once per branch that
+ * reaches it (6× under a suite like `enterprise-os`). Its "shared" tag is only
+ * top-level-package granularity — there is no true fan-in count.
+ *
+ * This module replaces that with a LAYERED DAG: every node appears EXACTLY
+ * ONCE, positioned at its longest-path depth, with edges converging on it —
+ * so `foundation` sinks to the bedrock row with N inbound edges instead of
+ * being redrawn N times. It is the single source of truth for template
+ * composition; the CLI, browser dialogs, backend boot-ordering, and (later)
+ * the Atlas all consume it.
+ *
+ * PURE + TRANSPORT-AGNOSTIC (same discipline as `catalog.ts`): this is the
+ * ONLY module `synap-cli`, `browser`, `synap-control-plane-api`, and
+ * `synap-backend` can all resolve. No React, no dagre/d3, no fetch, no
+ * Node-only APIs. Pixel layout lives elsewhere (browser-only) — this module
+ * only computes topology (layers + edges + memoized nodes), never coordinates.
+ *
+ * CONSUMES drift, never recomputes it: `installed` / `updates` are read
+ * straight off `catalog.ts`'s `InstalledTemplate`-shaped rows and
+ * `computeTemplateUpdates()` output — this module does no semver comparison
+ * of its own.
+ */
+
+/**
+ * An installed template row, keyed by slug — the shape this engine needs to
+ * mark a node `installed` and populate `workspaceIds`.
+ *
+ * NOTE ON NAMING: `catalog.ts`'s `InstalledTemplate` is `{ slug, version }`
+ * only — it was built for `computeTemplateUpdates`'s narrower need (a version
+ * to diff) and carries no `workspaceId`. `CompositionNode.workspaceIds` is
+ * part of the ratified API and cannot be populated from that shape, so this
+ * is a REAL conflict, not a preference: this module declares its own,
+ * slightly richer row instead of importing `catalog.ts`'s `InstalledTemplate`
+ * under that name. Every field of `catalog.ts`'s `InstalledTemplate` is a
+ * subset of this one, so a caller building `InstalledTemplate[]` for
+ * `computeTemplateUpdates` can build ONE array of `CompositionInstalledEntry`
+ * and pass it to both doors.
+ */
+interface CompositionInstalledEntry {
+    slug: string;
+    workspaceId: string;
+    workspaceName?: string;
+    /** `settings.packageVersion`, when the pod stamped one. Omit when unknown. */
+    version?: string;
+}
+/** One compose-relation dependency, attached to the BASE node it overlays onto. */
+interface CompositionOverlay {
+    slug: string;
+    name: string;
+    installed: boolean;
+}
+/** One edge in the raw dependency graph, exactly as declared (kept even when broken by a cycle). */
+interface CompositionEdge {
+    from: string;
+    to: string;
+    relation: "compose" | "require";
+    depKind?: string;
+}
+interface CompositionNode {
+    slug: string;
+    name: string;
+    /** Longest-path depth: `1 + max(layer of every node that depends on this one)`. Roots = 0, bedrock = max. */
+    layer: number;
+    /** TRUE fan-in — every slug (node or compose-only overlay source) that declares a dependency on this one. */
+    dependents: string[];
+    /** Which of the input `roots` transitively reach this node (self-inclusive for a root). */
+    roots: string[];
+    installed: boolean;
+    workspaceIds: string[];
+    installedVersion?: string;
+    latestVersion?: string | null;
+    updateAvailable: boolean;
+    noVersionInfo: boolean;
+    /** `compose`-relation deps that overlay onto THIS node (see rule 2 — the overlay source itself is never a layer node). */
+    overlays: CompositionOverlay[];
+}
+interface CompositionGraph {
+    nodes: Map<string, CompositionNode>;
+    edges: CompositionEdge[];
+    /** `layers[0]` = roots … `layers[n]` = bedrock. Compose-overlay SOURCES never appear here (rule 2). */
+    layers: CompositionNode[][];
+    /** Broken back-edges `[from, to]` — surfaced, never silently swallowed (rule 4). */
+    cycles: string[][];
+}
+interface LayerTemplateGraphInput {
+    /** Top-level slugs to walk from. Always land at `layer: 0`. */
+    roots: string[];
+    /** INJECTED edge source (rule 5) — never hardcoded to the bundled map. See `bundledEdgesOf`. */
+    edgesOf: (slug: string) => readonly TemplateDependency[];
+    nameOf?: (slug: string) => string | undefined;
+    installed?: CompositionInstalledEntry[];
+    updates?: TemplateUpdateCheck[];
+}
+/**
+ * Default `edgesOf` — reads `dependencies[]` off the BUNDLED template map
+ * only. This is what the current CLI walker is hardcoded to, which is
+ * precisely the live bug rule 5 fixes: a remote/private CP-only package's
+ * `definition.dependencies` are invisible to it, so its subtree silently
+ * renders empty. Callers with a remote catalog entry available should pass
+ * their OWN `edgesOf` that falls back to `entry.remote.definition.dependencies`
+ * (or similar) for slugs this default can't see.
+ */
+declare function bundledEdgesOf(slug: string): readonly TemplateDependency[];
+declare function layerTemplateGraph(input: LayerTemplateGraphInput): CompositionGraph;
+
+/**
+ * Cross-template CONCEPT guard — catches vocabulary forks between templates.
+ *
+ * WHY THIS EXISTS (read before weakening or deleting it):
+ * `business-developer.yaml` introduced workspace-scoped `crm-lead`/`crm-client`
+ * for the same real-world concept that `foundation.yaml`/`crm.yaml` declare as
+ * pod-wide shared `lead`/`client`. Nothing failed. Three reasons:
+ *
+ *   1. `build.mjs`'s `validate()` runs PER FILE, inside the read loop, so it
+ *      structurally cannot see that another template already owns `lead`.
+ *   2. The only vocabulary rule that exists (`template-shared-role-ssot.test.ts`
+ *      in synap-backend) polices a HARDCODED five-slug set — and it FORBIDS
+ *      declaring one of those slugs workspace-scoped, which is exactly what the
+ *      two-tier design legitimately needed. So RENAMING was the path of least
+ *      resistance: `crm-lead` is outside the set and passes silently. That rule
+ *      polices SPELLING, not MEANING.
+ *   3. That test also cannot run in CI — it resolves this package across a
+ *      sibling-repo relative path that CI never checks out. It is green on a dev
+ *      machine and mute everywhere else.
+ *
+ * This guard lives HERE, in the repo that owns the template source, and runs in
+ * this repo's CI (`pnpm test`) and in `pnpm build` / `prepublishOnly` via
+ * `scripts/check-concepts.mjs`. It is deliberately NOT a hardcoded slug list —
+ * that is the pattern that failed.
+ *
+ * WHAT IT DOES NOT DO: it does not guess. There is no fuzzy name matching, no
+ * edit distance, no synonym table. A guesser nobody trusts is worse than no
+ * guard. It uses two exact, falsifiable signals only — see the rules below.
+ */
+
+interface ConceptViolation {
+    rule: "concept-collision" | "alias-shape-divergence" | "stale-allowlist";
+    /** The concept term or semantic slug the finding is about. */
+    concept: string;
+    message: string;
+}
+/**
+ * DECLARED, INTENTIONAL divergences — the escape hatch, and deliberately the
+ * SECONDARY mechanism. An entry here is an author saying "yes, two spellings of
+ * one concept, on purpose, and here is why". Keep it tiny; every entry must
+ * carry its WHY. A key that stops matching anything FAILS the guard, so this
+ * list cannot rot into a graveyard.
+ *
+ * Key = the two colliding profile slugs, sorted, joined by "|".
+ */
+declare const DECLARED_DIVERGENCES: Record<string, string>;
+/**
+ * The bare noun a concept identifier ends in: `crm.lead` → `lead`,
+ * `crm-lead` → `lead`, `lead` → `lead`.
+ *
+ * This is EXACT terminal-token equality on the author's own qualified name —
+ * not a similarity heuristic. `crm-lead` and `lead` collide because the author
+ * literally wrote the same noun; `prospect` and `lead` do not collide, and that
+ * is honest: no guard can know they mean the same thing.
+ */
+declare function conceptTerm(semanticSlug: string): string;
+declare function findConceptViolations(templates?: Record<string, WorkspaceYaml>): ConceptViolation[];
+declare function formatConceptViolations(violations: ConceptViolation[]): string;
+
 /**
  * @synap-core/workspace-templates — Definition adapter
  *
@@ -955,4 +1126,4 @@ interface PackageDefinitionOutput {
  */
 declare function toPackageDefinition(slugOrYaml: string | WorkspaceYaml): PackageDefinitionOutput;
 
-export { type AssembleCatalogInput, type BentoViewBlockWire, type BentoWidgetBlockWire, type BundledCatalogEntry, type BundledEntry, type CatalogEntry, type CpPackageRow, type InstalledTemplate, type MergeCatalogInput, type MergeCatalogResult, PACKAGE_DEPENDENCY_KINDS, type PackageDefinitionOutput, type PackageDependencyKind, type RemoteCatalogEntry, type RemoteEntry, type RemoteSourceStatus, type SplitBentoBlocks, type TemplateActionPlacement, type TemplateAppKind, type TemplateAppRef, type TemplateAutomation, type TemplateBentoBlock, type TemplateDefaultSource, type TemplateDependency, type TemplateDisplayTemplate, type TemplateEntityLink, type TemplateExtendsRef, type TemplateIntegration, type TemplateLayoutConfig, type TemplateMeta, type TemplateOnboarding, type TemplateOnboardingCollectTarget, type TemplatePlaybook, type TemplatePlaybookParam, type TemplateProfile, type TemplateProfileEntityBentoTemplates, type TemplateProperty, type TemplateSeedEntity, type TemplateSidebarItem, type TemplateSidebarSurface, type TemplateSourceRole, type TemplateSuggestedRelation, type TemplateUpdateCheck, type TemplateView, type ToDefinitionResult, WORKSPACE_TEMPLATES, type WorkspaceDefinitionInput, type WorkspaceTemplateSlug, type WorkspaceYaml, assembleCatalog, computeTemplateUpdates, getWorkspaceTemplate, isHashVersion, listPublicTemplates, listWorkspaceTemplates, mergeCatalog, rowToRemoteEntry, splitBentoBlocks, toPackageDefinition, toWorkspaceDefinition };
+export { type AssembleCatalogInput, type BentoViewBlockWire, type BentoWidgetBlockWire, type BundledCatalogEntry, type BundledEntry, type CatalogEntry, type CompositionEdge, type CompositionGraph, type CompositionInstalledEntry, type CompositionNode, type CompositionOverlay, type ConceptViolation, type CpPackageRow, DECLARED_DIVERGENCES, type InstalledTemplate, type LayerTemplateGraphInput, type MergeCatalogInput, type MergeCatalogResult, PACKAGE_DEPENDENCY_KINDS, type PackageDefinitionOutput, type PackageDependencyKind, type RemoteCatalogEntry, type RemoteEntry, type RemoteSourceStatus, type SplitBentoBlocks, type TemplateActionPlacement, type TemplateAppKind, type TemplateAppRef, type TemplateAutomation, type TemplateBentoBlock, type TemplateDefaultSource, type TemplateDependency, type TemplateDisplayTemplate, type TemplateEntityLink, type TemplateExtendsRef, type TemplateIntegration, type TemplateLayoutConfig, type TemplateMeta, type TemplateOnboarding, type TemplateOnboardingCollectTarget, type TemplatePlaybook, type TemplatePlaybookParam, type TemplateProfile, type TemplateProfileEntityBentoTemplates, type TemplateProperty, type TemplateSeedEntity, type TemplateSidebarItem, type TemplateSidebarSurface, type TemplateSourceRole, type TemplateSuggestedRelation, type TemplateUpdateCheck, type TemplateView, type ToDefinitionResult, WORKSPACE_TEMPLATES, type WorkspaceDefinitionInput, type WorkspaceTemplateSlug, type WorkspaceYaml, assembleCatalog, bundledEdgesOf, computeTemplateUpdates, conceptTerm, findConceptViolations, formatConceptViolations, getWorkspaceTemplate, isHashVersion, layerTemplateGraph, listPublicTemplates, listWorkspaceTemplates, mergeCatalog, rowToRemoteEntry, splitBentoBlocks, toPackageDefinition, toWorkspaceDefinition };