@synap-core/workspace-templates 0.6.2 → 0.6.3

package/package.json

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

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,38 @@ 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,
+  });
+}

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,7 @@ export {
 
 export type { WorkspaceTemplateSlug } from "./templates.js";
 
-export { mergeCatalog } from "./catalog.js";
+export { mergeCatalog, rowToRemoteEntry, assembleCatalog } from "./catalog.js";
 export type {
   MergeCatalogInput,
   MergeCatalogResult,
@@ -72,6 +71,8 @@ export type {
   CatalogEntry,
   BundledCatalogEntry,
   RemoteCatalogEntry,
+  CpPackageRow,
+  AssembleCatalogInput,
 } from "./catalog.js";
 
 export {

package/src/templates.ts

@@ -8472,6 +8472,16 @@ const DATA = {
         "groupBy": "post-status",
         "description": "Content posts by status."
       },
+      {
+        "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",
@@ -8513,6 +8523,12 @@ const DATA = {
           "label": "Posts",
           "icon": "file-edit"
         },
+        {
+          "kind": "view",
+          "viewName": "Content Calendar",
+          "label": "Calendar",
+          "icon": "calendar"
+        },
         {
           "kind": "view",
           "viewName": "Pillars",
@@ -8538,10 +8554,20 @@ const DATA = {
       "blocks": [
         {
           "kind": "view",
-          "viewName": "Pillars",
+          "viewName": "Content Calendar",
           "pos": {
             "x": 0,
             "y": 0,
+            "w": 12,
+            "h": 6
+          }
+        },
+        {
+          "kind": "view",
+          "viewName": "Pillars",
+          "pos": {
+            "x": 0,
+            "y": 6,
             "w": 6,
             "h": 5
           }
@@ -8551,7 +8577,7 @@ const DATA = {
           "viewName": "Newsletters",
           "pos": {
             "x": 6,
-            "y": 0,
+            "y": 6,
             "w": 6,
             "h": 5
           }
@@ -9729,6 +9755,62 @@ const DATA = {
         "targetProfileSlug": "deal",
         "type": "linked_to_deal"
       }
+    ],
+    "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"
+      }
     ]
   },
   "dev-dashboard": {
@@ -12010,11 +12092,43 @@ const DATA = {
           }
         ],
         "executor": "is-agent",
+        "schedule": {
+          "cron": "0 9 * * 1",
+          "enabled": false
+        },
         "grants": [
           "Web Search",
           "Entity Creator"
         ],
         "status": "active"
+      },
+      {
+        "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"
+      }
+    ],
+    "integrations": [
+      {
+        "templateKey": "exa"
       }
     ],
     "onboarding": {

package/src/types.ts

@@ -176,18 +176,6 @@ export interface TemplateProfileEntityBentoTemplates {
   };
 }
 
-// ============================================================================
-// Automations
-// ============================================================================
-
-export interface TemplateAutomation {
-  name: string;
-  description?: string;
-  trigger: string;
-  action: string;
-  config?: Record<string, unknown>;
-}
-
 // ============================================================================
 // Cross-workspace source pinning
 // ============================================================================
@@ -515,9 +503,6 @@ export interface WorkspaceYaml {
   /** Per-profile entity bento layouts */
   profileEntityBentoTemplates?: TemplateProfileEntityBentoTemplates;
 
-  /** Automations to install on workspace creation */
-  automations?: TemplateAutomation[];
-
   /** Playbooks (session templates) seeded with the workspace */
   playbooks?: TemplatePlaybook[];
 
@@ -559,7 +544,6 @@ export interface ResolvedWorkspaceTemplate {
     bentoViewName?: string;
     bentoViewBlocks?: TemplateBentoBlock[];
     profileEntityBentoTemplates?: TemplateProfileEntityBentoTemplates;
-    automations: TemplateAutomation[];
     extends?: TemplateExtendsRef[];
   };
 }