@synap-core/workspace-templates 0.6.0 → 0.6.1

package/src/define.ts

@@ -10,9 +10,107 @@
  * shape never drifts per call-site.
  */
 
-import type { WorkspaceYaml } from "./types.js";
+import type { TemplateBentoBlock, WorkspaceYaml } from "./types.js";
 import { getWorkspaceTemplate } from "./templates.js";
 
+/** A widget block as the wire expects it: `bentoLayout[]`, keyed by `widgetType`. */
+export interface BentoWidgetBlockWire {
+  widgetType: string;
+  pos: TemplateBentoBlock['pos'];
+  config?: Record<string, unknown>;
+}
+
+/** A view block as the wire expects it: `bentoViewBlocks[]`, keyed by `viewName`. */
+export interface BentoViewBlockWire {
+  kind: 'view';
+  viewName: string;
+  pos: TemplateBentoBlock['pos'];
+  overrides?: Record<string, unknown>;
+}
+
+export interface SplitBentoBlocks {
+  bentoLayout: BentoWidgetBlockWire[];
+  bentoViewBlocks: BentoViewBlockWire[];
+}
+
+/**
+ * Split the authored `bento.blocks` DISCRIMINATED UNION into the TWO wire
+ * fields the pod expects. This is the whole point: `TemplateBentoBlock` is one
+ * array discriminated by `kind`, but the pod does NOT read `kind` — it splits by
+ * FIELD (`create-workspace-from-definition.ts`):
+ *
+ *   - `bentoLayout`     → mapped as widgets, reads `widget.widgetType`
+ *   - `bentoViewBlocks` → filtered against `viewMap[vb.viewSlug ?? vb.viewName]`,
+ *                         unknown entries DROPPED with a logger.warn
+ *
+ * Dumping the whole union into either single field silently mis-routes the other
+ * half — which is exactly what both converters used to do:
+ *   - `toWorkspaceDefinition` sent all blocks as `bentoViewBlocks`, so widgets
+ *     (no `viewName`) hit `viewMap[undefined]` and were filtered out.
+ *   - `toPackageDefinition` sent all blocks as `bentoLayout`, so view blocks
+ *     (no `widgetType`) became widgets with `widgetType: undefined`.
+ * Net: nobody had ever seen an authored bento render as authored.
+ *
+ * Blocks are emitted in the EXACT shape each sink declares (the tRPC
+ * `createFromDefinition` zod is strict: `bentoLayout` requires `widgetType`,
+ * `bentoViewBlocks` requires `kind: 'view'` + `viewName`), so a widget's
+ * `overrides` and a view's `config` are not smuggled into the wrong sink.
+ * Authored order is preserved WITHIN each kind; the pod concatenates
+ * `[...widgetBlocks, ...viewBlocks]`, so cross-kind order is the pod's to define.
+ *
+ * `kind` is INFERRED from field presence when absent. `TemplateBentoBlock.kind`
+ * is a required field in TypeScript, but the generated `templates.ts` casts the
+ * parsed YAML `as unknown as Record<string, WorkspaceYaml>` — so the compiler
+ * never checks the authored data against the type, and `agent-fleet.yaml`
+ * authored 8 widget blocks with no `kind:` at all (bare `widgetType`). Routing
+ * strictly on `kind` would silently DROP those — the exact failure mode this
+ * function exists to end. Inferring by field mirrors what the pod itself does
+ * (it splits by field and never reads `kind`), so the seam is total: a block
+ * that CAN be materialized always is. `scripts/check-converters.mjs` is the
+ * strict half — it fails the build if an authored block omits `kind` — so this
+ * leniency is a safety net, not a place for drift to hide.
+ */
+function resolveBlockKind(block: TemplateBentoBlock): 'widget' | 'view' | null {
+  if (block.kind === 'widget' || block.kind === 'view') return block.kind;
+  if (block.widgetType) return 'widget';
+  if (block.viewName) return 'view';
+  return null;
+}
+
+export function splitBentoBlocks(
+  blocks: TemplateBentoBlock[] | undefined
+): SplitBentoBlocks {
+  const bentoLayout: BentoWidgetBlockWire[] = [];
+  const bentoViewBlocks: BentoViewBlockWire[] = [];
+
+  for (const block of blocks ?? []) {
+    const kind = resolveBlockKind(block);
+    if (kind === 'widget') {
+      // A widget block without `widgetType` cannot be rendered — the pod would
+      // create a `widgetType: undefined` block. Drop it loudly rather than ship
+      // a broken block; the build-time guard asserts this never happens in the
+      // authored templates.
+      if (!block.widgetType) continue;
+      bentoLayout.push({
+        widgetType: block.widgetType,
+        pos: block.pos,
+        ...(block.config ? { config: block.config } : {}),
+      });
+    } else if (kind === 'view') {
+      // Same reasoning: the pod filters unknown/absent view names anyway.
+      if (!block.viewName) continue;
+      bentoViewBlocks.push({
+        kind: 'view',
+        viewName: block.viewName,
+        pos: block.pos,
+        ...(block.overrides ? { overrides: block.overrides } : {}),
+      });
+    }
+  }
+
+  return { bentoLayout, bentoViewBlocks };
+}
+
 /** The flat definition object accepted by createFromDefinition. */
 export interface WorkspaceDefinitionInput {
   workspaceName: string;
@@ -26,7 +124,16 @@ export interface WorkspaceDefinitionInput {
   displayTemplates?: WorkspaceYaml['displayTemplates'];
   layoutConfig: WorkspaceYaml['layout'] | undefined;
   bentoViewName?: string;
-  bentoViewBlocks?: NonNullable<WorkspaceYaml['bento']>['blocks'];
+  /**
+   * 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'];
   // Workspace-level metadata (flattened from the `workspace` block)
   workspaceSubtype?: string;
@@ -77,6 +184,10 @@ export function toWorkspaceDefinition(
   const name = nameOverride ?? ws.name;
   const proposalId = ws.proposalId ?? `${tpl.meta.slug}-v1`;
 
+  // The authored `bento.blocks` union must be ROUTED, not forwarded: the pod
+  // splits by field, not by `kind`. See `splitBentoBlocks`.
+  const bento = splitBentoBlocks(tpl.bento?.blocks);
+
   const definition: WorkspaceDefinitionInput = {
     workspaceName: name,
     description: ws.description,
@@ -89,7 +200,8 @@ export function toWorkspaceDefinition(
     displayTemplates: tpl.displayTemplates,
     layoutConfig: tpl.layout,
     bentoViewName: tpl.bento?.viewName,
-    bentoViewBlocks: tpl.bento?.blocks,
+    bentoLayout: bento.bentoLayout,
+    bentoViewBlocks: bento.bentoViewBlocks,
     profileEntityBentoTemplates: tpl.profileEntityBentoTemplates,
     workspaceSubtype: ws.subtype,
     workspaceType: ws.workspaceType,
@@ -114,6 +226,90 @@ export function toWorkspaceDefinition(
   return { definition, proposalId, workspaceName: name, templateId: tpl.meta.slug };
 }
 
+// ─── Exhaustiveness ledger: toWorkspaceDefinition ────────────────────────────
+// `WorkspaceYaml` is read by two converters and nothing forced either to be
+// total — which is how `dependencies` was silently dropped here for months.
+// Every key of `WorkspaceYaml` must be classified below as either FORWARDED
+// onto the wire or explicitly DROPPED with a reason. Adding a field to
+// `WorkspaceYaml` FAILS THE BUILD until it is classified, forcing the author
+// to make the forward-or-drop decision instead of defaulting to silent loss.
+//
+// ⚠️ KNOW WHAT THIS LEDGER DOES NOT CATCH. It is FIELD-PRESENCE-exhaustive, not
+// SEMANTICS-exhaustive. It asks "is every key classified?" — not "does the value
+// reach the right sink?". `bento` was classified as forwarded, and it WAS
+// forwarded: the whole discriminated union was dumped into ONE field on each
+// door (`bentoViewBlocks` here, `bentoLayout` in `toPackageDefinition`). The
+// ledger passed while widgets were filtered out on one door and views became
+// `widgetType: undefined` widgets on the other. A ledger entry is a CLAIM about
+// routing; only a runtime assertion can check the claim.
+// → The counterpart guard for that class is `scripts/check-converters.mjs`,
+//   which RUNS both converters over all templates and asserts the per-kind
+//   block counts survive the split. Any future union-shaped field (one authored
+//   array fanning out to N wire fields) needs an assertion there too — do not
+//   let a ledger comment stand in for one.
+
+/** Keys `toWorkspaceDefinition` reads and carries onto the wire. */
+type WorkspaceDefinitionForwarded =
+  | 'meta'          // → proposalId (meta.slug) + templateId; not a wire field itself
+  | 'workspace'     // flattened into workspaceName/description/workspaceType/…
+  | 'profiles'
+  | 'views'
+  | 'entityLinks'
+  | 'seedEntities'
+  | 'suggestedRelations'
+  | 'displayTemplates'
+  | 'layout'        // → layoutConfig
+  | 'bento'         // → bentoViewName + bentoLayout (widgets) + bentoViewBlocks (views)
+  | 'profileEntityBentoTemplates'
+  | 'onboarding'
+  | 'dependencies';
+
+/**
+ * Keys deliberately NOT forwarded by `toWorkspaceDefinition`. Each needs a
+ * one-line WHY. "The door has no such field" = forwarding is a no-op; anything
+ * else is a real gap and should say so.
+ */
+type WorkspaceDefinitionDropped =
+  // UI-only: `workspaces.createFromDefinition` has no `app` field. Consumers
+  // read `template.app` straight off the YAML to pick the first screen, so this
+  // never belonged on the wire.
+  | 'app'
+  // The door DOES accept `extends`, but no template declares it today (0/21).
+  // Forwarding is a no-op until one does — wire it then.
+  | 'extends'
+  // The door DOES accept `automations`, but no template declares it today
+  // (0/21), and its zod shape ({trigger,action:{playbook_run}}) is not
+  // `TemplateAutomation`. Needs a mapper if a template ever uses it.
+  // The browser install path installs automations via its own createAutomation door.
+  | 'automations'
+  // The door has no `integrations` field. Its `tools` field is a DIFFERENT
+  // shape ({name,kind,inputSchema} vs {templateKey,params,mode}). Capability
+  // templates are seeded via the packages/apply path, not createFromDefinition
+  // — see the note on `TemplateIntegration` in types.ts. Forwarding = no-op.
+  | 'integrations'
+  // REAL GAP (agent-fleet, project-management declare playbooks). The door
+  // accepts `playbooks`, but the shapes disagree: template param `type` allows
+  // 'text'|'entity'|'choice', the tRPC enum accepts only string|number|boolean
+  // (and defaultValue↔default, grants: string[]↔{kind,ref}[]). Raw forwarding =
+  // zod BAD_REQUEST. Needs a param mapper — separate wave, not a silent drop.
+  | 'playbooks';
+
+type UnclassifiedWorkspaceDefinitionKey = Exclude<
+  keyof WorkspaceYaml,
+  WorkspaceDefinitionForwarded | WorkspaceDefinitionDropped
+>;
+
+// If this errors, a new `WorkspaceYaml` field is unclassified. Forward it in
+// `toWorkspaceDefinition` and add it to `WorkspaceDefinitionForwarded`, or add
+// it to `WorkspaceDefinitionDropped` with a one-line WHY.
+const _workspaceDefinitionLedger: [UnclassifiedWorkspaceDefinitionKey] extends [never]
+  ? true
+  : [
+      'UNCLASSIFIED YAML FIELD — forward it or add it to WorkspaceDefinitionDropped:',
+      UnclassifiedWorkspaceDefinitionKey,
+    ] = true;
+void _workspaceDefinitionLedger;
+
 /**
  * The unified `PackageDefinition` shape consumed by `POST /api/hub/packages/apply`
  * (CLI `synap launch`) and the CP package registry seeder. It composes the
@@ -145,7 +341,17 @@ export interface PackageDefinitionOutput {
   suggestedRelations?: WorkspaceYaml['suggestedRelations'];
   displayTemplates?: WorkspaceYaml['displayTemplates'];
   entityLinks?: WorkspaceYaml['entityLinks'];
-  bentoLayout?: NonNullable<WorkspaceYaml['bento']>['blocks'];
+  /** 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'];
@@ -173,6 +379,9 @@ export function toPackageDefinition(
   }
 
   const ws = tpl.workspace;
+  // Same routing as the tRPC door — the union is split by `kind`, never dumped
+  // whole into one field. See `splitBentoBlocks`.
+  const bento = splitBentoBlocks(tpl.bento?.blocks);
   return {
     _meta: {
       slug: tpl.meta.slug,
@@ -195,7 +404,8 @@ export function toPackageDefinition(
     suggestedRelations: tpl.suggestedRelations,
     displayTemplates: tpl.displayTemplates,
     entityLinks: tpl.entityLinks,
-    bentoLayout: tpl.bento?.blocks,
+    bentoLayout: bento.bentoLayout,
+    bentoViewBlocks: bento.bentoViewBlocks,
     bentoViewName: tpl.bento?.viewName,
     profileEntityBentoTemplates: tpl.profileEntityBentoTemplates,
     layoutConfig: tpl.layout,
@@ -205,3 +415,56 @@ export function toPackageDefinition(
     dependencies: tpl.dependencies,
   };
 }
+
+// ─── Exhaustiveness ledger: toPackageDefinition ──────────────────────────────
+// Same forcing function as above, for the OTHER converter. These two are NOT
+// merged on purpose: they target different endpoints with different contracts
+// (`PackageDefinition` is a superset with renames — seedEntities→suggestedEntities,
+// bento.blocks→bentoLayout, integrations→capabilities, plus `_meta`). Keeping
+// two converters is fine; keeping either one lossy-by-accident is not.
+
+/** Keys `toPackageDefinition` reads and carries onto the wire. */
+type PackageDefinitionForwarded =
+  | 'meta'          // → _meta
+  | 'workspace'     // flattened into workspaceName/description/workspaceType/…
+  | 'profiles'
+  | 'views'
+  | 'seedEntities'  // → suggestedEntities
+  | 'suggestedRelations'
+  | 'displayTemplates'
+  | 'entityLinks'
+  | 'bento'         // → bentoViewName + bentoLayout (widgets) + bentoViewBlocks (views)
+  | 'profileEntityBentoTemplates'
+  | 'layout'        // → layoutConfig
+  | 'integrations'  // → capabilities
+  | 'playbooks'
+  | 'onboarding'
+  | 'dependencies';
+
+/** Keys deliberately NOT forwarded by `toPackageDefinition`. */
+type PackageDefinitionDropped =
+  // UI-only, same as the definition door: `PackageDefinition` has no `app`.
+  | 'app'
+  // REAL GAP: backend `PackageDefinition` DOES declare `extends`
+  // (package-definition.ts:262) and `automations` (:268), but
+  // `PackageDefinitionOutput` omits both. No template declares either today
+  // (0/21), so this is latent, not live — wire them when a template first uses
+  // one.
+  | 'extends'
+  | 'automations';
+
+type UnclassifiedPackageDefinitionKey = Exclude<
+  keyof WorkspaceYaml,
+  PackageDefinitionForwarded | PackageDefinitionDropped
+>;
+
+// If this errors, a new `WorkspaceYaml` field is unclassified. Forward it in
+// `toPackageDefinition` and add it to `PackageDefinitionForwarded`, or add it
+// to `PackageDefinitionDropped` with a one-line WHY.
+const _packageDefinitionLedger: [UnclassifiedPackageDefinitionKey] extends [never]
+  ? true
+  : [
+      'UNCLASSIFIED YAML FIELD — forward it or add it to PackageDefinitionDropped:',
+      UnclassifiedPackageDefinitionKey,
+    ] = true;
+void _packageDefinitionLedger;

package/src/enterprise-os.yaml

@@ -0,0 +1,183 @@
+# Enterprise OS — the public operating system suite
+# ==================================================
+# A SUITE template: it stands up a whole company's public operating core in one
+# install by REQUIRING its constituent workspaces (deps-first), then adds a thin
+# "command tower" home of its own — a place to track the company's objectives
+# across the lenses it just installed.
+#
+# What it composes (all public, all bundled):
+#   • foundation — strategic DNA (mission, audience, positioning, principles)
+#   • ecosystem  — the market graph (partners, competitors, segments, trends)
+#   • operations — how the company runs (the operational lens)
+#   • crm        — the pipeline (contacts, leads, clients, deals)
+#
+# It uses `require` (not `compose`): each constituent is a REAL workspace, not an
+# overlay. Deps-first resolution installs foundation first (the SSOT role
+# vocabulary provider), so every downstream lens reuses foundation's pod-wide
+# roles rather than forking twins. Installing Enterprise OS a second time is
+# idempotent — the resolver reuses existing constituent workspaces by slug.
+
+meta:
+  slug: enterprise-os
+  name: Enterprise OS
+  description: Stand up a company's public operating core in one install — strategy, market, operations, and pipeline — plus a command tower to track objectives across them.
+  icon: layout-dashboard
+  color: "#4F46E5"
+  tags: [suite, enterprise, os, foundation, crm, operations, ecosystem]
+  isPublic: true
+
+# Deps-first: foundation is the pod-wide role-vocabulary provider, so it must
+# resolve before ecosystem/operations/crm reuse its shared roles. `require` (not
+# `compose`): each is a standalone workspace, not an additive overlay.
+dependencies:
+  - slug: foundation
+    kind: workspace
+    relation: require
+    reason: "Strategic DNA + the pod-wide role vocabulary (partner/client/lead) every other lens reuses. Must resolve first."
+  - slug: ecosystem
+    kind: workspace
+    relation: require
+    reason: "The market graph — the players, segments, and trends the company operates around."
+  - slug: operations
+    kind: workspace
+    relation: require
+    reason: "How the company runs — the operational lens."
+  - slug: crm
+    kind: workspace
+    relation: require
+    reason: "The pipeline — contacts, leads, clients, and deals."
+
+workspace:
+  name: Enterprise OS
+  description: The command tower for the company operating system — track strategic objectives across the strategy, market, operations, and pipeline lenses this suite installs.
+  subtype: enterprise-os
+  visibility: pod_visible
+  sourceRoles:
+    strategy: consumer
+
+profiles:
+  # The one native profile the command tower owns: a strategic objective the
+  # company is driving across the lenses this suite installs. Deliberately light
+  # — the depth lives in the constituent workspaces; this is the cross-cutting
+  # scoreboard that ties them together.
+  - slug: objective
+    displayName: Objective
+    icon: target
+    color: "#4F46E5"
+    description: A company objective the operating system is driving toward — the cross-cutting outcome the lenses serve.
+    properties:
+      - slug: outcome
+        label: Outcome
+        valueType: string
+        inputType: textarea
+      - slug: status
+        label: Status
+        valueType: string
+        inputType: select
+        enumValues: [on-track, at-risk, off-track, achieved]
+        constraints: { defaultValue: on-track }
+      - slug: horizon
+        label: Horizon
+        valueType: string
+        inputType: select
+        enumValues: [now, next, later]
+        constraints: { defaultValue: now }
+      - slug: owner
+        label: Owner
+        valueType: string
+        inputType: text
+      - slug: targetDate
+        label: Target Date
+        valueType: date
+        inputType: date
+
+views:
+  - name: Objectives
+    slug: objectives
+    type: table
+    scopeProfileSlug: objective
+    description: The company's strategic objectives across every lens, by horizon and status.
+    defaultView: true
+    config:
+      columns: [title, status, horizon, owner, targetDate]
+  - name: Objective Board
+    slug: objective-board
+    type: kanban
+    scopeProfileSlug: objective
+    description: Objectives grouped by status — a running scoreboard for the operating system.
+    config:
+      groupBy: status
+
+onboarding:
+  goal: >
+    Stand up the company's operating core and name the handful of strategic
+    objectives it is driving — so strategy, market, operations, and pipeline are
+    all in place and pointed at the same outcomes from day one.
+  framing: |
+    THE CHIEF OF STAFF: Act as a sharp chief of staff standing up the company OS.
+    The four lenses (foundation, ecosystem, operations, CRM) are already
+    installed — your job is to name the 3-5 objectives that cut across them, so
+    the operating system has a scoreboard, not just structure.
+  expertise:
+    starters:
+      - >
+        Name few, real objectives. An operating system with 20 objectives has
+        none; force the 3-5 that actually decide the year, each with an owner and
+        a horizon (now / next / later).
+      - >
+        Tie each objective to a lens. A good objective names where it lives —
+        pipeline growth (CRM), a market move (ecosystem), an operational fix
+        (operations), or a positioning shift (foundation) — so the scoreboard
+        maps to the structure underneath it.
+    blindSpots:
+      - >
+        Objectives with no owner and no date are wishes. Every one needs a single
+        owner and a target date, or it will not move.
+      - >
+        "Grow the business" is not an objective — it is a category. Push for the
+        specific outcome that would make this quarter a win.
+    bar: >
+      A short, honest scoreboard: 3-5 objectives, each owned, dated, placed on a
+      horizon, and tied to the lens that serves it — sitting on top of a fully
+      installed operating core.
+  collect:
+    - profileSlug: objective
+      what: The 3-5 strategic objectives the company is driving this horizon.
+      cardinality: few
+      keyFields: [status, horizon, owner]
+  openingQuestions:
+    - "What are the 3-5 objectives that will decide this year for the company?"
+    - "Who owns each one, and is it a now, next, or later horizon?"
+  doneWhen: A few objectives captured, each with an owner and a horizon.
+
+app:
+  kind: stored
+  cellKey: entity-detail
+
+layout:
+  defaultView: Objectives
+  defaultApp: null
+  pinnedApps: [dashboard, data]
+  sidebarItems:
+    - kind: view
+      viewName: Objectives
+      label: Objectives
+      icon: target
+    - kind: view
+      viewName: Objective Board
+      label: Board
+      icon: kanban-square
+    - kind: app
+      appId: data
+      label: Data
+      icon: database
+
+bento:
+  viewName: Objectives
+  blocks:
+    - kind: view
+      viewName: Objectives
+      pos: { x: 0, y: 0, w: 8, h: 4 }
+    - kind: view
+      viewName: Objective Board
+      pos: { x: 8, y: 0, w: 4, h: 4 }

package/src/index.ts

@@ -37,6 +37,7 @@ export type {
   TemplateAutomation,
   TemplateExtendsRef,
   TemplateDependency,
+  PackageDependencyKind,
   TemplateProfileEntityBentoTemplates,
   TemplateDefaultSource,
   TemplateSourceRole,
@@ -46,6 +47,12 @@ export type {
   TemplatePlaybookParam,
 } from "./types.js";
 
+// The dependency-kind vocabulary as a VALUE — so consumers (marketplace,
+// onboarding, backend, hub zod, browser, CP zod) can `z.enum(PACKAGE_DEPENDENCY_KINDS)`
+// / derive their type from it instead of hand-copying the list. Six mirrors
+// exist today; this is the door that lets them stop being mirrors.
+export { PACKAGE_DEPENDENCY_KINDS } from "./types.js";
+
 export {
   WORKSPACE_TEMPLATES,
   getWorkspaceTemplate,
@@ -55,9 +62,28 @@ export {
 
 export type { WorkspaceTemplateSlug } from "./templates.js";
 
-export { toWorkspaceDefinition, toPackageDefinition } from "./define.js";
+export { mergeCatalog } from "./catalog.js";
+export type {
+  MergeCatalogInput,
+  MergeCatalogResult,
+  BundledEntry,
+  RemoteEntry,
+  RemoteSourceStatus,
+  CatalogEntry,
+  BundledCatalogEntry,
+  RemoteCatalogEntry,
+} from "./catalog.js";
+
+export {
+  toWorkspaceDefinition,
+  toPackageDefinition,
+  splitBentoBlocks,
+} from "./define.js";
 export type {
   WorkspaceDefinitionInput,
   ToDefinitionResult,
   PackageDefinitionOutput,
+  SplitBentoBlocks,
+  BentoWidgetBlockWire,
+  BentoViewBlockWire,
 } from "./define.js";

package/src/marketing.yaml

@@ -146,16 +146,25 @@ profiles:
   # foundation already owns (e.g. `leadStage`) with a divergent enum/default —
   # that is base drift, and the SSOT tripwire fails on it.
   # (Standards reference inherited base props like `leadStage` directly.)
+  #
+  # The same reasoning applies to the ROW-LEVEL fields, and more strictly: the
+  # row has no overlay mechanism, so this template must not restate what
+  # foundation owns. `description`, `semanticSlug` and `applicableKinds` are
+  # therefore OMITTED here — they are written only on the create path, which
+  # foundation always takes, so declaring them here asserted a value that never
+  # applied (this template claimed `applicableKinds: [person]` while the live row
+  # says [company, person]).
+  # `icon`/`color` are the exception that must be RESTATED rather than dropped:
+  # they are also read into `profileHintsMap` to build THIS workspace's auto-bento
+  # for `lead`, so omitting them regresses the widgets to a default indigo
+  # database icon. They must MATCH foundation's row (`user-plus`/`yellow`) — the
+  # old `green` rendered green widgets around a yellow row.
   - slug: lead
     displayName: Lead
     icon: user-plus
-    color: green
-    description: "A potential customer or partner contact in your pipeline"
-    semanticSlug: marketing.lead
+    color: yellow
     scope: shared
     profileKind: role
-    applicableKinds:
-      - person
     properties:
       - slug: lead-source
         label: Source