@synap-core/workspace-templates 0.6.2 → 0.6.4

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@synap-core/workspace-templates",
-  "version": "0.6.2",
+  "version": "0.6.4",
   "type": "module",
   "packageManager": "pnpm@9.15.4",
   "description": "Canonical workspace definitions — YAML source + typed exports for browser, backend, CLI, and marketplace",

package/src/catalog.test.ts

@@ -7,7 +7,7 @@
 
 import { test } from "node:test";
 import assert from "node:assert/strict";
-import { mergeCatalog, type RemoteEntry } from "./catalog.js";
+import { mergeCatalog, computeTemplateUpdates, type RemoteEntry } from "./catalog.js";
 import type { WorkspaceYaml } from "./types.js";
 
 const BUNDLE_VERSION = "0.6.0";
@@ -154,3 +154,101 @@ test("maps a bundled template's meta fields onto the entry", () => {
   assert.equal(e.category, "workspace");
   assert.equal(e.isPrivate, true, "isPublic:false ⇒ isPrivate");
 });
+
+// ── computeTemplateUpdates ───────────────────────────────────────────────────
+
+test("computeTemplateUpdates: no update when installed equals catalog latest (semver)", () => {
+  const { entries } = mergeCatalog({
+    bundled: [bundled("crm")],
+    remote: [remote("crm", { version: "0.7.0" })],
+    bundleVersion: BUNDLE_VERSION, // remote strictly newer → remote wins, carries "0.7.0"
+  });
+  const [check] = computeTemplateUpdates([{ slug: "crm", version: "0.7.0" }], entries);
+  assert.equal(check.latestVersion, "0.7.0");
+  assert.equal(check.updateAvailable, false);
+});
+
+test("computeTemplateUpdates: update available when installed is older (semver)", () => {
+  const { entries } = mergeCatalog({
+    bundled: [bundled("crm")],
+    remote: [remote("crm", { version: "0.7.0" })],
+    bundleVersion: BUNDLE_VERSION,
+  });
+  const [check] = computeTemplateUpdates([{ slug: "crm", version: "0.5.0" }], entries);
+  assert.equal(check.latestVersion, "0.7.0");
+  assert.equal(check.updateAvailable, true);
+});
+
+// NOTE: uses a non-colliding slug so the remote row is kept as a DISTINCT entry
+// regardless of version — a hash string never parses as semver, so on a slug
+// COLLISION `remoteIsStrictlyNewer` would (correctly, per mergeCatalog's existing
+// squatting-defense semantics) keep the bundle winning and never surface the hash.
+test("computeTemplateUpdates: hash-vs-semver — any mismatch with a hash version signals an update", () => {
+  const { entries } = mergeCatalog({
+    bundled: [bundled("crm")],
+    remote: [remote("hash-template", { version: "h-abc123" })],
+    bundleVersion: BUNDLE_VERSION,
+  });
+  const [staleSemver] = computeTemplateUpdates(
+    [{ slug: "hash-template", version: "0.5.0" }],
+    entries,
+  );
+  assert.equal(staleSemver.latestVersion, "h-abc123");
+  assert.equal(staleSemver.updateAvailable, true, "semver installed vs hash latest ⇒ differ ⇒ update");
+
+  const [sameHash] = computeTemplateUpdates(
+    [{ slug: "hash-template", version: "h-abc123" }],
+    entries,
+  );
+  assert.equal(sameHash.updateAvailable, false, "identical hash ⇒ no update");
+
+  const [differentHash] = computeTemplateUpdates(
+    [{ slug: "hash-template", version: "h-old999" }],
+    entries,
+  );
+  assert.equal(differentHash.updateAvailable, true, "different hash ⇒ update");
+});
+
+test("computeTemplateUpdates: slug missing from catalog ⇒ no update, latestVersion undefined", () => {
+  const { entries } = mergeCatalog({
+    bundled: [bundled("crm")],
+    remote: [],
+    bundleVersion: BUNDLE_VERSION,
+  });
+  const [check] = computeTemplateUpdates([{ slug: "ghost-template", version: "1.0.0" }], entries);
+  assert.equal(check.latestVersion, undefined);
+  assert.equal(check.updateAvailable, false);
+});
+
+test("computeTemplateUpdates: bundled winner compares against bundleVersion when passed", () => {
+  const { entries } = mergeCatalog({
+    bundled: [bundled("crm")],
+    remote: [],
+    bundleVersion: BUNDLE_VERSION,
+  });
+  const stale = computeTemplateUpdates(
+    [{ slug: "crm", version: "0.1.0" }],
+    entries,
+    BUNDLE_VERSION,
+  );
+  assert.equal(stale[0].latestVersion, BUNDLE_VERSION);
+  assert.equal(stale[0].updateAvailable, true);
+
+  const noBundleVersion = computeTemplateUpdates([{ slug: "crm", version: "0.1.0" }], entries);
+  assert.equal(noBundleVersion[0].latestVersion, undefined, "no bundleVersion ⇒ nothing to compare");
+  assert.equal(noBundleVersion[0].updateAvailable, false);
+});
+
+test("computeTemplateUpdates: passes isPrivate through from the winning entry", () => {
+  const { entries } = mergeCatalog({
+    bundled: [bundled("crm")],
+    remote: [remote("private-pack", { isPrivate: true, version: "1.0.0" })],
+    bundleVersion: BUNDLE_VERSION,
+  });
+  const [check] = computeTemplateUpdates(
+    [{ slug: "private-pack", version: "0.9.0" }],
+    entries,
+  );
+  assert.equal(check.isPrivate, true);
+  assert.equal(check.updateAvailable, true);
+});

package/src/catalog.ts

@@ -101,6 +101,59 @@ export interface MergeCatalogInput {
   remoteStatus?: RemoteSourceStatus;
 }
 
+/**
+ * A control-plane package LIST row, as returned by `GET /api/packages` and
+ * `GET /api/packages/mine`. This is the raw JSON shape BEFORE it is projected
+ * into a `RemoteEntry`. Both list routes STRIP `definition`, so it is absent
+ * here (the install path fetches the full row per-slug on demand).
+ *
+ * `isPublic` is present ONLY on `/mine` rows (`false` ⇒ private). Public browse
+ * rows omit it BY CONSTRUCTION (the list route hard-filters `WHERE is_public =
+ * true`), so its absence means "public", never "unknown".
+ *
+ * Consumers used to hand-copy this shape + `rowToRemoteEntry` (browser
+ * `useMarketplaceCatalog`, CLI `cp-packages`); this is the ONE canonical copy.
+ */
+export interface CpPackageRow {
+  slug: string;
+  displayName: string;
+  description?: string | null;
+  /** CP package category / type (e.g. `"workspace"`, `"view"`). */
+  category?: string;
+  tags?: string[] | null;
+  icon?: string | null;
+  /** Present only on `/mine` rows. `false` ⇒ private. Browse rows omit it. */
+  isPublic?: boolean;
+}
+
+/**
+ * Map a CP list row into the merge door's `RemoteEntry`. THE canonical mapping —
+ * browser + CLI import this instead of hand-copying it (the two copies had
+ * already drifted in `description`/`isPrivate` handling).
+ *
+ * `isPrivate` is passed EXPLICITLY by the caller because it depends on WHICH
+ * route the row came from: browse rows are all-public (pass `undefined`), `/mine`
+ * rows carry the real flag (pass `row.isPublic === false`). Keeping it a param —
+ * not derived here — lets a caller that fetches the two routes separately control
+ * it per-source; `assembleCatalog` derives it from the row for the common case.
+ */
+export function rowToRemoteEntry(
+  row: CpPackageRow,
+  isPrivate?: boolean,
+): RemoteEntry {
+  return {
+    slug: row.slug,
+    name: row.displayName,
+    description: row.description ?? undefined,
+    category: row.category,
+    tags: row.tags ?? [],
+    icon: row.icon ?? null,
+    isPrivate,
+    // Both list routes strip `definition`; absence ⇒ bundle wins a slug conflict,
+    // and the install path fetches the full definition per-slug when needed.
+  };
+}
+
 // ============================================================================
 // Output
 // ============================================================================
@@ -283,3 +336,131 @@ export function mergeCatalog(input: MergeCatalogInput): MergeCatalogResult {
     sources: { bundled: "ok", remote: remoteStatus },
   };
 }
+
+export interface AssembleCatalogInput {
+  /** Bundled templates (this package). Always in-process. */
+  bundled: BundledEntry[];
+  /**
+   * Raw CP list rows (browse and/or `/mine`, concatenated). Mapped to
+   * `RemoteEntry` via `rowToRemoteEntry`; `isPrivate` is DERIVED per-row from
+   * `isPublic` (`false` ⇒ private; absent/`true` ⇒ public), which handles both
+   * browse rows (no `isPublic`) and `/mine` rows uniformly.
+   */
+  remoteRows?: CpPackageRow[];
+  /** This client's bundled-package version (the winner signal vs each row). */
+  bundleVersion: string;
+  /** The transport's verdict on the remote fetch. Default `"ok"`. */
+  remoteStatus?: RemoteSourceStatus;
+}
+
+/**
+ * Convenience wrapper over `mergeCatalog`: maps raw CP rows through the canonical
+ * `rowToRemoteEntry` and merges them with the bundled templates. Still PURE — the
+ * caller fetches the rows (its own transport/auth) and passes them in; this only
+ * maps + merges. Use `mergeCatalog` + `rowToRemoteEntry` directly when you need
+ * per-source `isPrivate` control (e.g. keeping browse and `/mine` distinct).
+ */
+export function assembleCatalog(input: AssembleCatalogInput): MergeCatalogResult {
+  const remote = (input.remoteRows ?? []).map((row) =>
+    rowToRemoteEntry(row, row.isPublic === false ? true : undefined),
+  );
+  return mergeCatalog({
+    bundled: input.bundled,
+    remote,
+    bundleVersion: input.bundleVersion,
+    remoteStatus: input.remoteStatus,
+  });
+}
+
+// ============================================================================
+// Installed-vs-catalog update check
+// ============================================================================
+
+/** A template a pod has installed — the door reads `settings.packageVersion` off the workspace row. */
+export interface InstalledTemplate {
+  slug: string;
+  version: string;
+}
+
+/** Per-slug verdict: is a newer catalog version available than what's installed? */
+export interface TemplateUpdateCheck {
+  slug: string;
+  installedVersion: string;
+  /** `undefined` when the slug has no matching catalog entry, or a bundled winner and no `bundleVersion` was passed. */
+  latestVersion: string | undefined;
+  updateAvailable: boolean;
+  /** Passed through from the winning catalog entry, so callers can route private updates through the authed path. */
+  isPrivate?: boolean;
+}
+
+/**
+ * `true` when `version` is a CP content-hash stamp (`"h-<hash>"`) rather than semver.
+ * Content-hash versions are NOT semver-comparable — see `computeTemplateUpdates`.
+ */
+export function isHashVersion(version: string | undefined): boolean {
+  return typeof version === "string" && version.startsWith("h-");
+}
+
+/**
+ * Compare an installed version against a catalog's latest — reusing
+ * `remoteIsStrictlyNewer` for the semver path. Either side being a content-hash
+ * (`"h-..."`) makes the pair NOT semver-comparable, so an update is signalled
+ * whenever the two raw strings simply differ (equal ⇒ no update, by construction
+ * the CP only reissues a new hash when the template content actually changed).
+ */
+function isNewerVersion(installedVersion: string, latestVersion: string | undefined): boolean {
+  if (latestVersion === undefined) return false;
+  if (isHashVersion(installedVersion) || isHashVersion(latestVersion)) {
+    return installedVersion !== latestVersion;
+  }
+  return remoteIsStrictlyNewer(latestVersion, installedVersion);
+}
+
+/**
+ * Compute, per installed template, whether the CATALOG (bundled + remote,
+ * already merged by `mergeCatalog`/`assembleCatalog`) carries a newer version
+ * than what the pod installed — the shared "update available" check all three
+ * doors (browser, synap-app, CLI) reuse instead of re-deriving it.
+ *
+ * `installed` and `catalog` are BOTH already-fetched/computed by the caller —
+ * this stays PURE, same as the rest of this module (no fetch, no auth).
+ *
+ * The catalog's winning entry carries the latest version signal two ways:
+ *   • `source: "remote"` → `remote.definition?.sourcePackage?.version` (semver
+ *     OR, going forward, a CP content-hash `"h-<hash>"` stamp).
+ *   • `source: "bundled"` → bundled entries carry no version field at all
+ *     (`TemplateMeta` has none); pass `bundleVersion` (this client's compiled
+ *     package version, the same value fed to `mergeCatalog`) to compare against
+ *     it. Omit `bundleVersion` and bundled-backed slugs report `latestVersion:
+ *     undefined, updateAvailable: false` (nothing comparable).
+ *
+ * A slug with no matching catalog entry ⇒ `updateAvailable: false`,
+ * `latestVersion: undefined` — there is nothing to update TO.
+ */
+export function computeTemplateUpdates(
+  installed: InstalledTemplate[],
+  catalog: CatalogEntry[],
+  bundleVersion?: string,
+): TemplateUpdateCheck[] {
+  const bySlug = new Map(catalog.map((entry) => [entry.slug, entry]));
+
+  return installed.map(({ slug, version: installedVersion }) => {
+    const entry = bySlug.get(slug);
+    if (!entry) {
+      return { slug, installedVersion, latestVersion: undefined, updateAvailable: false };
+    }
+
+    const latestVersion =
+      entry.source === "remote"
+        ? entry.remote.definition?.sourcePackage?.version
+        : bundleVersion;
+
+    return {
+      slug,
+      installedVersion,
+      latestVersion,
+      updateAvailable: isNewerVersion(installedVersion, latestVersion),
+      isPrivate: entry.isPrivate,
+    };
+  });
+}

package/src/content-os.yaml

@@ -402,6 +402,20 @@ views:
     scopeProfileSlug: post
     groupBy: post-status
     description: Content posts by status.
+  # The editorial calendar — the "it lands on a calendar" promise. Posts render
+  # on a month grid keyed on their Publish Date. The calendar renderer resolves
+  # the event date via getProperty(entity, dateField) against the entity's nested
+  # `properties` object (CalendarView default is `properties.date`), so the
+  # dateField must be the `properties.`-prefixed path, NOT a bare slug — a bare
+  # slug only anchors the visible month, it does not map events.
+  # `publish-date` is valueType:date, so values render as all-day chips.
+  - name: Content Calendar
+    slug: content-calendar
+    type: calendar
+    scopeProfileSlug: post
+    description: Your editorial calendar — every post on the day it publishes.
+    config:
+      dateField: properties.publish-date
   - name: Pillars
     slug: content-pillars
     type: list
@@ -434,6 +448,10 @@ layout:
       viewName: Posts
       label: Posts
       icon: file-edit
+    - kind: view
+      viewName: Content Calendar
+      label: Calendar
+      icon: calendar
     - kind: view
       viewName: Pillars
       label: Pillars
@@ -451,12 +469,15 @@ layout:
 bento:
   viewName: Posts
   blocks:
+    - kind: view
+      viewName: Content Calendar
+      pos: { x: 0, y: 0, w: 12, h: 6 }
     - kind: view
       viewName: Pillars
-      pos: { x: 0, y: 0, w: 6, h: 5 }
+      pos: { x: 0, y: 6, w: 6, h: 5 }
     - kind: view
       viewName: Newsletters
-      pos: { x: 6, y: 0, w: 6, h: 5 }
+      pos: { x: 6, y: 6, w: 6, h: 5 }
 
 # Editorial graph: connect posts to campaign / pillar / sponsor
 entityLinks:

package/src/crm.yaml

@@ -1,7 +1,8 @@
 # CRM workspace template
 # The CRM owns pre-sale work only. A won deal is handed to the operating
 # workspace; this template deliberately does not provision client delivery,
-# playbooks, campaigns, tasks, documents, or automations.
+# campaigns, tasks, documents, or automations. It DOES seed funnel playbooks
+# (the action layer) so the pipeline is operable via sessions — see `playbooks:`.
 
 meta:
   slug: crm
@@ -405,3 +406,68 @@ entityLinks:
   - sourceProfileSlug: company
     targetProfileSlug: deal
     type: linked_to_deal
+
+# Playbooks — session templates seeded with the workspace. The CRM's action layer.
+# `subjectProfile` binds each playbook to a funnel subject so the Capture → Session
+# matcher (`playbooks.matchForEntity`, filtering `subject_profile->>'profileSlug'`)
+# can offer it when that subject is captured — a captured lead surfaces "Enrich this
+# lead" / "Qualify this lead"; a deal surfaces "Work this deal". The subject entity
+# is passed as the matching entity param and substituted into the goalTemplate.
+#
+# Two subjects are used: `lead` (a shared ROLE facet on a person/company — the same
+# facet-role subject pattern ecosystem.yaml uses for `competitor`) and `deal` (a
+# primary CRM kind). The matcher keys purely on the profileSlug string, so a role
+# facet and a kind are matched identically.
+#
+# No `grants:` on "Enrich this lead": enrichment tools (Apify/Unipile-LinkedIn) are
+# workspace-conditional and may not be granted, so the goalTemplate context-injects
+# the intent and the session agent uses whatever enrichment capability the workspace
+# actually has — mirroring how "Produce Content" (content-os) grants nothing and
+# leans on the workspace's tools, rather than hardcoding a tool that might be absent.
+playbooks:
+  - name: Enrich this lead
+    description: Take a thin, freshly-captured lead and fill it out — company, title, LinkedIn, and the relationships around it.
+    goalTemplate: >-
+      Enrich this lead ({lead}). Starting from whatever is known, fill out the
+      missing detail — company, job title, LinkedIn URL, location, and the people
+      and companies around them — and record it on the lead. Draw on whatever
+      enrichment capability this workspace has connected (e.g. an Apify or
+      Unipile/LinkedIn tool); if none is available, enrich from the public web and
+      what is already in the pod. Link the lead to its company and any related
+      contacts, and note where information is still missing.
+    subjectProfile:
+      profileSlug: lead
+    params:
+      - { name: lead, type: entity, label: Lead, required: true }
+    executor: is-agent
+    status: active
+
+  - name: Qualify this lead
+    description: Assess a lead against the ICP, score the fit, and decide the next step — advance, nurture, or disqualify.
+    goalTemplate: >-
+      Qualify this lead ({lead}). Assess how well they fit our ideal customer
+      profile — company, role, industry, size, and the signals of intent or need —
+      and set an ICP score. Decide the next step: advance them toward a deal,
+      keep nurturing, or disqualify. Write the reasoning and the decision back onto
+      the lead (its stage, score, and next step) so the call is auditable.
+    subjectProfile:
+      profileSlug: lead
+    params:
+      - { name: lead, type: entity, label: Lead, required: true }
+    executor: is-agent
+    status: active
+
+  - name: Work this deal
+    description: Move a deal toward Won — read the current stage, find the blocker, and propose the next step and owner.
+    goalTemplate: >-
+      Work this deal ({deal}) toward Won. Assess where it stands — its current
+      stage, value, and close date — and identify the single thing blocking it from
+      advancing. Propose the concrete next step, who owns it, and by when, and
+      update the deal's next step accordingly. If the stage should change, say so
+      and why.
+    subjectProfile:
+      profileSlug: deal
+    params:
+      - { name: deal, type: entity, label: Deal, required: true }
+    executor: is-agent
+    status: active

package/src/define.ts

@@ -135,6 +135,18 @@ export interface WorkspaceDefinitionInput {
   /** 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'];
   // Workspace-level metadata (flattened from the `workspace` block)
   workspaceSubtype?: string;
   workspaceType?: NonNullable<WorkspaceYaml['workspace']>['workspaceType'];
@@ -203,6 +215,13 @@ export function toWorkspaceDefinition(
     bentoLayout: bento.bentoLayout,
     bentoViewBlocks: bento.bentoViewBlocks,
     profileEntityBentoTemplates: tpl.profileEntityBentoTemplates,
+    // Capability integrations — forwarded so the tRPC/UI (bundled) install door
+    // seeds the SAME operational payload (tools + skills + capability-embedded
+    // automations/playbooks) the CLI/Hub door gets via `toPackageDefinition`.
+    // `workspaces.createFromDefinition` declares `capabilities` in its zod input
+    // and routes it through the shared `applyPackagePostWorkspace` door. Omitting
+    // it here made the browser bundled-install path carry no capabilities at all.
+    capabilities: tpl.integrations,
     workspaceSubtype: ws.subtype,
     workspaceType: ws.workspaceType,
     workspaceVisibility: ws.visibility,
@@ -261,6 +280,7 @@ type WorkspaceDefinitionForwarded =
   | 'layout'        // → layoutConfig
   | 'bento'         // → bentoViewName + bentoLayout (widgets) + bentoViewBlocks (views)
   | 'profileEntityBentoTemplates'
+  | 'integrations'  // → capabilities (installed via shared applyPackagePostWorkspace door)
   | 'onboarding'
   | 'dependencies';
 
@@ -277,16 +297,6 @@ type WorkspaceDefinitionDropped =
   // 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
@@ -446,12 +456,10 @@ 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';
+  // (package-definition.ts:262), but `PackageDefinitionOutput` omits it. No
+  // template declares it today (0/21), so this is latent, not live — wire it
+  // when a template first uses one.
+  | 'extends';
 
 type UnclassifiedPackageDefinitionKey = Exclude<
   keyof WorkspaceYaml,

package/src/ecosystem.yaml

@@ -392,11 +392,46 @@ playbooks:
       - { name: companyContext, type: text, label: Our company context }
       - { name: outputTypes, type: text, label: Outputs, defaultValue: "a head-to-head comparison summary and an updated competitor profile" }
     executor: is-agent
+    # A radar MONITOR: bound to the competitor KIND + a schedule → the backing
+    # cron automation fans out (query→loop→playbook_run) and runs this once per
+    # competitor. Disabled by default so installing the workspace never silently
+    # starts paid AI runs — the user turns it on when they want the watch.
+    schedule: { cron: "0 9 * * 1", enabled: false }
     grants:
       - Web Search
       - Entity Creator
     status: active
 
+  # A radar DISCOVERY run: the self-generating half. No subjectProfile → a single
+  # scheduled run (not per-existing-entity) that finds competitors we don't track
+  # yet and adds them — deduplicated by website — so the knowledge base grows
+  # itself. Requires the Exa capability (integrations below).
+  - name: Discover Competitors
+    description: Scan the market for competitors we don't track yet and add them to the ecosystem — the self-generating half of the radar.
+    goalTemplate: >-
+      Find companies that compete with us in {ourSpace}. Use neural web search
+      (the exa_search skill with category "company") to surface real, named
+      companies — direct competitors, adjacent tools that solve the same job a
+      different way, and emerging players. For each genuinely NEW one (not already
+      a competitor in our ecosystem), propose it as a `competitor` entity and
+      ALWAYS include its `website` (its canonical URL) so it de-duplicates against
+      what we already track — never create a company that already exists. Skip
+      anything already known. Report what you added and why each one matters.
+    schedule: { cron: "0 9 * * 1", enabled: false }
+    params:
+      - { name: ourSpace, type: text, label: Our market / category, required: true }
+    executor: is-agent
+    grants:
+      - exa_search
+      - Entity Creator
+    status: active
+
+# The Exa search capability powers the discovery radar (find companies we don't
+# track yet). Composed pod-wide at provisioning via the existing integrations
+# door; the user supplies the Exa API key once on install.
+integrations:
+  - templateKey: exa
+
 onboarding:
   goal: >
     Map the real ecosystem — the key players (companies and people), who partners

package/src/index.ts

@@ -34,7 +34,6 @@ export type {
   TemplateSuggestedRelation,
   TemplateDisplayTemplate,
   TemplateIntegration,
-  TemplateAutomation,
   TemplateExtendsRef,
   TemplateDependency,
   PackageDependencyKind,
@@ -62,7 +61,13 @@ export {
 
 export type { WorkspaceTemplateSlug } from "./templates.js";
 
-export { mergeCatalog } from "./catalog.js";
+export {
+  mergeCatalog,
+  rowToRemoteEntry,
+  assembleCatalog,
+  computeTemplateUpdates,
+  isHashVersion,
+} from "./catalog.js";
 export type {
   MergeCatalogInput,
   MergeCatalogResult,
@@ -72,6 +77,10 @@ export type {
   CatalogEntry,
   BundledCatalogEntry,
   RemoteCatalogEntry,
+  CpPackageRow,
+  AssembleCatalogInput,
+  InstalledTemplate,
+  TemplateUpdateCheck,
 } from "./catalog.js";
 
 export {