@synap-core/workspace-templates 0.6.4 → 0.7.1

package/src/define.ts

@@ -10,9 +10,39 @@
  * shape never drifts per call-site.
  */
 
-import type { TemplateBentoBlock, WorkspaceYaml } from "./types.js";
+import type { TemplateAutomation, TemplateBentoBlock, WorkspaceYaml } from "./types.js";
 import { getWorkspaceTemplate } from "./templates.js";
 
+/**
+ * A `TemplateAutomation` as the apply door expects it: `flowDefinition`, not
+ * the authored `flow` (mirrors `PackagePostWorkspaceBody['automations'][number]`
+ * / the Hub `POST /packages/apply` `AutomationSchema`).
+ */
+export interface PackageAutomationWire {
+  /** Stable template identity; names may be edited without orphaning the flow. */
+  key?: string;
+  name: string;
+  description?: string;
+  triggerType: TemplateAutomation['triggerType'];
+  triggerConfig?: Record<string, unknown>;
+  flowDefinition?: { nodes: unknown[]; edges: unknown[]; precondition?: string };
+  status?: TemplateAutomation['status'];
+}
+
+function toAutomationWire(
+  automations: TemplateAutomation[] | undefined,
+): PackageAutomationWire[] | undefined {
+  return automations?.map((a) => ({
+    key: a.key,
+    name: a.name,
+    description: a.description,
+    triggerType: a.triggerType,
+    triggerConfig: a.triggerConfig,
+    flowDefinition: a.flow,
+    status: a.status,
+  }));
+}
+
 /** A widget block as the wire expects it: `bentoLayout[]`, keyed by `widgetType`. */
 export interface BentoWidgetBlockWire {
   widgetType: string;
@@ -147,6 +177,21 @@ export interface WorkspaceDefinitionInput {
    * tools/skills/automations silently dropped on that door.
    */
   capabilities?: WorkspaceYaml['integrations'];
+  /** Playbooks normalized to the workspace-create input contract. */
+  playbooks?: Array<Record<string, unknown>>;
+  /**
+   * Entity-detail action placements — forwarded verbatim to
+   * `applyPackagePostWorkspace`, which merges them into
+   * `settings.actionPlacements`. The tRPC door (`createFromDefinition`)
+   * declares `actionPlacements` in its zod input and carries them through the
+   * shared apply door. No shape transform: the authored form IS the wire form.
+   */
+  actionPlacements?: WorkspaceYaml['actionPlacements'];
+  /**
+   * Graph-based automations. Deliberately distinct from the legacy
+   * `automations` loop/playbook-trigger wire shape accepted by this door.
+   */
+  flowAutomations?: PackageAutomationWire[];
   // Workspace-level metadata (flattened from the `workspace` block)
   workspaceSubtype?: string;
   workspaceType?: NonNullable<WorkspaceYaml['workspace']>['workspaceType'];
@@ -177,6 +222,27 @@ export interface ToDefinitionResult {
   templateId: string;
 }
 
+/**
+ * The workspace-create door persists a compact primitive input contract. A
+ * template's entity/choice parameter is still represented precisely by its
+ * `subjectProfile` or runtime prompt, while the persisted input value is an ID
+ * or selected value string. Keep this conversion at the shared template seam
+ * so browser creation and package application cannot silently disagree.
+ */
+function toWorkspacePlaybooks(playbooks: WorkspaceYaml["playbooks"]): Array<Record<string, unknown>> | undefined {
+  return playbooks?.map((playbook) => ({
+    ...playbook,
+    params: playbook.params?.map((param) => ({
+      name: param.name,
+      type: param.type === "number" || param.type === "boolean" ? param.type : "string",
+      ...(param.defaultValue !== undefined ? { default: param.defaultValue } : {}),
+      ...(param.label
+        ? { description: param.label }
+        : {}),
+    })),
+  }));
+}
+
 /**
  * Resolve a template (by slug or YAML object) into the createFromDefinition
  * payload. Pass `nameOverride` to rename the workspace at creation time.
@@ -228,6 +294,13 @@ export function toWorkspaceDefinition(
     workspaceCapabilities: ws.capabilities,
     sourceRoles: ws.sourceRoles,
     defaultSources: ws.defaultSources,
+    // Workspace creation persists its own compact playbook parameter shape.
+    // Map authored entity/choice inputs here instead of dropping playbooks.
+    playbooks: toWorkspacePlaybooks(tpl.playbooks),
+    // Entity-detail action placements — forwarded verbatim; the apply door
+    // resolves playbook/automation refs and merges into settings.actionPlacements.
+    actionPlacements: tpl.actionPlacements,
+    flowAutomations: toAutomationWire(tpl.automations),
     onboarding: tpl.onboarding,
     // Template-composition dependencies — forwarded so the tRPC/UI door gets the
     // SAME deps-first ordering the CLI/Hub door gets via `toPackageDefinition`.
@@ -281,6 +354,9 @@ type WorkspaceDefinitionForwarded =
   | 'bento'         // → bentoViewName + bentoLayout (widgets) + bentoViewBlocks (views)
   | 'profileEntityBentoTemplates'
   | 'integrations'  // → capabilities (installed via shared applyPackagePostWorkspace door)
+  | 'playbooks'     // → normalized compact playbook contract
+  | 'actionPlacements' // → settings.actionPlacements via applyPackagePostWorkspace
+  | 'automations' // → flowAutomations → shared applyPackagePostWorkspace door
   | 'onboarding'
   | 'dependencies';
 
@@ -297,12 +373,7 @@ 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'
-  // 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,
@@ -367,6 +438,19 @@ export interface PackageDefinitionOutput {
   layoutConfig?: WorkspaceYaml['layout'];
   capabilities?: WorkspaceYaml['integrations'];
   playbooks?: WorkspaceYaml['playbooks'];
+  /** Flow-based automations — mapped to the apply door's `flowDefinition` field. */
+  automations?: PackageAutomationWire[];
+  /**
+   * Entity-detail action placements — carried verbatim (authored form IS the
+   * wire form). NOTE: the Hub `PackageApplySchema` (synap-backend
+   * `hub-protocol/rest/packages.ts`) is a plain `z.object` and does not yet
+   * declare `actionPlacements`, so on the CLI/Hub install path this field is
+   * STRIPPED before `applyPackagePostWorkspace` sees it. The tRPC
+   * `createFromDefinition` door DOES carry it. Named follow-up: add an
+   * `ActionPlacementSchema` field to `PackageApplySchema` to close the Hub half
+   * (out of the T2 fence — flagged in the handoff).
+   */
+  actionPlacements?: WorkspaceYaml['actionPlacements'];
   onboarding?: WorkspaceYaml['onboarding'];
   /** Template-composition dependencies — resolved by the apply endpoint. */
   dependencies?: WorkspaceYaml['dependencies'];
@@ -421,6 +505,8 @@ export function toPackageDefinition(
     layoutConfig: tpl.layout,
     capabilities: tpl.integrations,
     playbooks: tpl.playbooks,
+    automations: toAutomationWire(tpl.automations),
+    actionPlacements: tpl.actionPlacements,
     onboarding: tpl.onboarding,
     dependencies: tpl.dependencies,
   };
@@ -448,6 +534,8 @@ type PackageDefinitionForwarded =
   | 'layout'        // → layoutConfig
   | 'integrations'  // → capabilities
   | 'playbooks'
+  | 'automations'   // → mapped to the apply door's flowDefinition wire shape
+  | 'actionPlacements' // → carried verbatim (Hub inbound schema decl is a follow-up)
   | 'onboarding'
   | 'dependencies';
 

package/src/ecosystem.yaml

@@ -381,9 +381,11 @@ playbooks:
     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.
+      moves. Use web search for news and public signal, and use the Apify scraper
+      for a deep scan of their site (pricing page, changelog, careers page) when
+      a URL is known. 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:
@@ -398,8 +400,9 @@ playbooks:
     # 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
+      - exa_search
+      - apify_run_actor
+      - entity.create
     status: active
 
   # A radar DISCOVERY run: the self-generating half. No subjectProfile → a single
@@ -409,28 +412,32 @@ playbooks:
   - 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.
+      Find companies that compete with us in {ourSpace}. Fan out neural web
+      searches with the exa_search skill using category "company" — cover direct
+      competitors, adjacent tools that solve the same job a different way, and
+      emerging players, not just the obvious incumbents. 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) as
+      the dedup key — never create a company whose website already matches one we
+      track. Skip anything already known. Report what you added, the search
+      angles you covered, and why each new 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
+      - entity.create
     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.
+# Exa powers the discovery radar (find companies we don't track yet); Apify
+# powers the deep-scan half of Research Competitor (scrape a known competitor's
+# site for pricing/changelog/careers signal). Composed pod-wide at provisioning
+# via the existing integrations door; the user supplies each API key once on
+# install — a missing key fails gracefully per-skill, not the whole workspace.
 integrations:
   - templateKey: exa
+  - templateKey: apify
 
 onboarding:
   goal: >

package/src/index.ts

@@ -44,6 +44,8 @@ export type {
   TemplateOnboardingCollectTarget,
   TemplatePlaybook,
   TemplatePlaybookParam,
+  TemplateAutomation,
+  TemplateActionPlacement,
 } from "./types.js";
 
 // The dependency-kind vocabulary as a VALUE — so consumers (marketplace,
@@ -83,6 +85,19 @@ export type {
   TemplateUpdateCheck,
 } from "./catalog.js";
 
+export {
+  layerTemplateGraph,
+  bundledEdgesOf,
+} from "./composition-graph.js";
+export type {
+  CompositionInstalledEntry,
+  CompositionOverlay,
+  CompositionEdge,
+  CompositionNode,
+  CompositionGraph,
+  LayerTemplateGraphInput,
+} from "./composition-graph.js";
+
 export {
   toWorkspaceDefinition,
   toPackageDefinition,

package/src/meetings-knowledge.yaml

@@ -0,0 +1,204 @@
+# Meetings & Knowledge workspace template
+# A standalone capture layer for meetings: pull the transcript, summarize it,
+# and turn it into the things that actually matter afterward — notes, tasks,
+# and the people involved. Reuses the pod-wide person/task/note kinds so a
+# meeting's output lands where every other workspace already looks for it.
+
+meta:
+  slug: meetings-knowledge
+  name: Meetings & Knowledge
+  description: Import and summarize meetings — transcripts become notes, action items become tasks, and attendees become tracked people.
+  icon: video
+  color: "#8B5CF6"
+  tags: [meetings, notes, tasks, transcripts, calendar]
+  isPublic: true
+
+workspace:
+  name: Meetings & Knowledge
+  description: Import and summarize meetings — transcripts become notes, action items become tasks, and attendees become tracked people.
+  subtype: meetings-knowledge
+  visibility: pod_visible
+  capabilities:
+    - meetings.import
+    - meetings.summaries
+  sourceRoles:
+    meetings: provider
+
+profiles:
+  # ── Meeting (owned here) ─────────────────────────────────────────────────
+  - slug: meeting
+    displayName: Meeting
+    icon: video
+    color: violet
+    description: A meeting — its date, attendees, and what came out of it.
+    properties:
+      - slug: meetingDate
+        label: Date
+        valueType: date
+        inputType: date
+      - slug: platform
+        label: Platform
+        valueType: string
+        inputType: select
+        enumValues: [zoom, google-meet, teams, in-person, other]
+      - slug: attendees
+        label: Attendees
+        valueType: array
+        inputType: text
+      - slug: status
+        label: Status
+        valueType: string
+        inputType: select
+        enumValues: [scheduled, completed, processed]
+        constraints: { defaultValue: scheduled }
+      - slug: summary
+        label: Summary
+        valueType: string
+        inputType: textarea
+      - slug: transcriptUrl
+        label: Transcript URL
+        valueType: string
+        inputType: url
+
+views:
+  - name: Meetings
+    slug: meetings
+    type: table
+    scopeProfileSlug: meeting
+    description: Every meeting, its platform, and whether it's been processed.
+    config:
+      columns: [title, meetingDate, platform, status]
+    defaultView: true
+  - name: Meetings Calendar
+    slug: meetings-calendar
+    type: calendar
+    scopeProfileSlug: meeting
+    description: Meetings on a calendar, keyed on their date.
+  - name: Action Items
+    slug: meeting-action-items
+    type: kanban
+    scopeProfileSlug: task
+    groupBy: status
+    description: Tasks generated from meetings, by status.
+    config:
+      groupBy: status
+
+entityLinks:
+  - sourceProfileSlug: meeting
+    targetProfileSlug: person
+    type: attended_by
+    label: Attended by
+  - sourceProfileSlug: meeting
+    targetProfileSlug: task
+    type: generated
+    label: Generated
+  - sourceProfileSlug: meeting
+    targetProfileSlug: note
+    type: summarized_in
+    label: Summarized in
+
+# Playbook — pulls the transcript (Fireflies) and calendar context (Google
+# Calendar), summarizes it, and writes the follow-through: a note, tasks per
+# action item, and any new attendees. Bound to the meeting kind so a captured
+# meeting can offer this as a session.
+playbooks:
+  - name: Import & Summarize Meeting
+    description: Pull a meeting's transcript, summarize it, and extract action items and attendees into tasks, notes, and people.
+    goalTemplate: >-
+      Import the meeting {meeting} — pull its transcript from Fireflies and use
+      Google Calendar for scheduling/attendee context. Produce: {outputTypes}.
+      Create a note with the summary, create a task for each action item, and
+      make sure attendees not already tracked are captured as person entities.
+      Update the meeting record's summary, transcriptUrl, and status.
+    subjectProfile:
+      profileSlug: meeting
+    params:
+      - { name: meeting, type: entity, label: Meeting, required: true }
+      - { name: outputTypes, type: text, label: Outputs, defaultValue: "a summary note, action-item tasks, and updated attendee records" }
+    executor: is-agent
+    grants:
+      - fireflies_import_last_meeting
+      - fireflies_search
+      - calendar_list
+      - entity.create
+    status: active
+
+# Transcript import via Fireflies, calendar/attendee context via Google
+# (nango-google). The user connects each once on install; a missing key fails
+# gracefully per-skill.
+integrations:
+  - templateKey: fireflies
+  - templateKey: nango-google
+
+onboarding:
+  goal: >
+    Get recent meetings into the pod so summaries, action items, and attendees
+    are captured instead of living only in someone's memory of the call.
+  framing: |
+    THE CHIEF OF STAFF: Act as a sharp chief of staff who turns meetings into
+    follow-through. A meeting with no summary and no action items didn't
+    happen as far as the rest of the org is concerned.
+  expertise:
+    starters:
+      - >
+        Every meeting worth logging needs a "so what" — at least one action item
+        or decision. If a founder describes a meeting with no outcome, ask what
+        changed because of it.
+      - >
+        Attendees are people, not names in a transcript — capture them as
+        tracked contacts so the next meeting with them has history.
+    blindSpots:
+      - >
+        Recurring meetings (standups, 1:1s) get skipped because they feel
+        routine — but their action items are exactly what falls through the
+        cracks. Don't let "it's just a standup" excuse skipping capture.
+    bar: >
+      A handful of recent meetings are logged with a real summary and at least
+      one action item each, so the Import & Summarize playbook has something
+      concrete to run against.
+  collect:
+    - profileSlug: meeting
+      what: Recent or upcoming meetings worth tracking.
+      cardinality: few
+      keyFields: [meetingDate, platform]
+  openingQuestions:
+    - "What meetings do you want tracked — recurring ones, or just the important ones?"
+    - "Where do your meetings live — Zoom, Google Meet, somewhere else?"
+    - "Do you already record/transcribe them, or should that start now?"
+  doneWhen: A few meetings captured with a date and platform, at least one with a summary.
+
+app:
+  kind: stored
+  cellKey: entity-detail
+
+layout:
+  defaultView: Meetings
+  defaultApp: null
+  pinnedApps: [dashboard, data]
+  sidebarItems:
+    - kind: view
+      viewName: Meetings
+      label: Meetings
+      icon: video
+    - kind: view
+      viewName: Meetings Calendar
+      label: Calendar
+      icon: calendar
+    - kind: view
+      viewName: Action Items
+      label: Action Items
+      icon: check-square
+    - kind: app
+      appId: data
+      label: Data
+      icon: database
+
+bento:
+  viewName: Meetings
+  blocks:
+    - kind: view
+      viewName: Meetings
+      pos: { x: 0, y: 0, w: 8, h: 5 }
+    - kind: view
+      viewName: Action Items
+      pos: { x: 8, y: 0, w: 4, h: 5 }