@synap-core/workspace-templates 0.6.1 → 0.6.3

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@synap-core/workspace-templates",
-  "version": "0.6.1",
+  "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/builder.yaml

@@ -1258,6 +1258,27 @@ entityLinks:
     type: depends_on
     label: Depends on
 
+# Playbooks — session templates seeded with the workspace.
+# `subjectProfile` binds this playbook to the `devplane_feature` kind so the
+# Capture → Session matcher (playbooks.subject_profile->>'profileSlug') can offer
+# it when a feature/idea is captured. The captured feature is passed as the
+# `feature` entity param and substituted into the goalTemplate.
+playbooks:
+  - name: Evaluate Feature
+    description: Assess a feature — its current state, whether it's worth building, and how it fits the rest of the system.
+    goalTemplate: >-
+      Evaluate this feature ({feature}): where it stands today (its status,
+      progress, and any blockers), whether it is actually useful (the problem it
+      solves and for whom), and how it integrates with the existing apps,
+      packages, services, and environments in this workspace. Finish with a clear
+      recommendation — continue, cut, or reshape — and the reasoning behind it.
+    subjectProfile:
+      profileSlug: devplane_feature
+    params:
+      - { name: feature, type: entity, label: Feature, required: true }
+    executor: is-agent
+    status: active
+
 onboarding:
   goal: Capture the real engineering surface — the apps that are shipped, where their code lives, what runs behind them, where they deploy, and what's in flight — so the workspace mirrors what the team actually builds and runs, not a generic template.
   framing: >

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:
@@ -473,6 +494,28 @@ entityLinks:
     type: sponsored_by
     label: Sponsor
 
+# Playbooks — session templates seeded with the workspace.
+# `subjectProfile` binds this playbook to the `post` kind so the Capture → Session
+# matcher (playbooks.subject_profile->>'profileSlug') can offer it when a post is
+# captured. The captured post is passed as the `post` entity param and substituted
+# into the goalTemplate; the agent carries it from raw idea to a scheduled draft.
+playbooks:
+  - name: Produce Content
+    description: Take a captured post idea and carry it from spark to a scheduled, platform-ready draft.
+    goalTemplate: >-
+      Produce content for {platform} from this idea ({post}). Take the raw idea,
+      shape it into a {format} draft with a scroll-stopping hook and a clear CTA,
+      keep it aligned to the post's pillar and the operator's brand voice, then
+      move it to Scheduled with a publish date.
+    subjectProfile:
+      profileSlug: post
+    params:
+      - { name: post, type: entity, label: Post, required: true }
+      - { name: platform, type: text, label: Platform, required: true }
+      - { name: format, type: text, label: Format }
+    executor: is-agent
+    status: active
+
 onboarding:
   goal: >
     Stand up the editorial engine — the pillars you're known for, the platforms

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

@@ -368,6 +368,70 @@ entityLinks:
     type: involves
     label: Involves
 
+# Playbooks — session templates seeded with the workspace.
+# Ported from the orphaned `deep-research.playbook.json` (CP templates/packs):
+# same goalTemplate + companyContext param + is-agent executor + Web-Search /
+# Entity-Creator grants + typed outputs (encoded via the {outputTypes} param).
+# `subjectProfile` binds it to the shared `competitor` role so the Capture →
+# Session matcher can offer it when a competitor is captured; the captured
+# competitor is passed as the `competitor` entity param.
+playbooks:
+  - name: Research Competitor
+    description: Deep-research a competitor and position it against us — strengths, weaknesses, pricing, and the gaps we can exploit.
+    goalTemplate: >-
+      Research this competitor ({competitor}) and compare them to us. Investigate
+      their {focus}: positioning, strengths, weaknesses, pricing, and recent
+      moves. Use the provided company context where relevant: {companyContext}.
+      Produce: {outputTypes}. Update the competitor entity with what you find and
+      make clear where we win and where we are exposed.
+    subjectProfile:
+      profileSlug: competitor
+    params:
+      - { name: competitor, type: entity, label: Competitor, required: true }
+      - { name: focus, type: text, label: Focus area, defaultValue: "product, pricing, and positioning" }
+      - { 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/enterprise-os.yaml

@@ -10,6 +10,7 @@
 #   • ecosystem  — the market graph (partners, competitors, segments, trends)
 #   • operations — how the company runs (the operational lens)
 #   • crm        — the pipeline (contacts, leads, clients, deals)
+#   • content-os — the editorial engine (pillars, posts, platforms, newsletters)
 #
 # It uses `require` (not `compose`): each constituent is a REAL workspace, not an
 # overlay. Deps-first resolution installs foundation first (the SSOT role
@@ -46,6 +47,10 @@ dependencies:
     kind: workspace
     relation: require
     reason: "The pipeline — contacts, leads, clients, and deals."
+  - slug: content-os
+    kind: workspace
+    relation: require
+    reason: "The editorial engine — pillars, posts, platforms, and newsletters — so the company's content operation is part of the operating core."
 
 workspace:
   name: Enterprise OS

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 {