@synap-core/workspace-templates 0.6.4 → 0.7.0

package/src/crm.yaml

@@ -1,8 +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,
-# campaigns, tasks, documents, or automations. It DOES seed funnel playbooks
-# (the action layer) so the pipeline is operable via sessions — see `playbooks:`.
+# campaigns, tasks, documents, automations, or sales-specific playbooks. A
+# use-case overlay (for example `business-developer`) may add those workflows.
 
 meta:
   slug: crm
@@ -17,6 +17,20 @@ meta:
     - contacts
   isPublic: true
 
+# SSOT ordering guarantee — this template REFERENCES foundation's pod-wide
+# shared `client`/`partner`/`lead`/`churned` roles below. The apply engine seeds
+# a shared profile's pod-wide BASE property body from whichever template
+# creates it FIRST, and adds a REUSING template's extra props as workspace
+# OVERLAYS. Requiring foundation makes the resolver install it first
+# (deps-first), so the base is always foundation's SSOT body and never this
+# template's. `require`, not `compose`: foundation is a real workspace, not an
+# overlay.
+dependencies:
+  - slug: foundation
+    kind: workspace
+    relation: require
+    reason: "Provides the pod-wide client/partner/lead/churned role vocabulary this workspace reuses."
+
 workspace:
   name: CRM
   description: A focused pre-sale workspace for contacts, companies, and deals.
@@ -407,67 +421,33 @@ entityLinks:
     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.
+# Playbook — enriches a lead/prospect from public sources (company site,
+# LinkedIn, firmographic signal) so ICP scoring and qualification start from
+# real data instead of a blank record. Bound to `lead` so a newly captured
+# lead can offer this as a session.
 playbooks:
-  - name: Enrich this lead
-    description: Take a thin, freshly-captured lead and fill it out — company, title, LinkedIn, and the relationships around it.
+  - name: Enrich Lead/Company
+    description: Enrich a lead or company from public sources — firmographics, company size, and recent signal — to sharpen ICP scoring and qualification.
     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.
+      Enrich {target} using public sources. Scrape their website and LinkedIn
+      presence (via Apify) for firmographics: company size, industry, location,
+      and any recent signal (funding, hiring, product launches). Fill in the
+      missing profile fields (industry, companySize, location, icpScore) with
+      what you find, and note anything that changes qualification. Do not
+      fabricate — leave a field blank rather than guess.
     subjectProfile:
       profileSlug: lead
     params:
-      - { name: lead, type: entity, label: Lead, required: true }
+      - { name: target, type: entity, label: Lead or company, required: true }
     executor: is-agent
+    grants:
+      - apify_run_actor
+      - entity.create
     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
+# Apify powers the enrichment playbook (scrape public sources for a lead's
+# firmographics). Composed pod-wide at provisioning via the existing
+# integrations door; the user supplies the Apify API key once on install — a
+# missing key fails gracefully per-skill, not the whole workspace.
+integrations:
+  - templateKey: apify

package/src/define.flow-automations.test.ts

@@ -0,0 +1,65 @@
+import { describe, expect, it } from "vitest";
+import { toWorkspaceDefinition } from "./define.js";
+import type { WorkspaceYaml } from "./types.js";
+
+const workflowTemplate: WorkspaceYaml = {
+  meta: {
+    slug: "workflow-contract-test",
+    name: "Workflow contract test",
+    description: "Test template",
+    icon: "workflow",
+    color: "blue",
+  },
+  workspace: { name: "Workflow contract test", description: "Test" },
+  profiles: [],
+  automations: [
+    {
+      name: "A manual workflow",
+      triggerType: "manual",
+      flow: {
+        nodes: [{ id: "trigger", type: "trigger" }],
+        edges: [],
+        precondition: "trigger.payload.ready === true",
+      },
+    },
+  ],
+  actionPlacements: [
+    {
+      profileSlug: "person",
+      surface: "entity-detail",
+      kind: "automation",
+      ref: "A manual workflow",
+      label: "Run workflow",
+      when: {
+        requiredFacetSlugs: ["lead"],
+        propertyEquals: { stage: "ready" },
+      },
+      confirmation: { title: "Continue?", confirmLabel: "Run" },
+    },
+  ],
+};
+
+describe("toWorkspaceDefinition flow automations", () => {
+  it("keeps graph workflows distinct from legacy loop automations", () => {
+    const { definition } = toWorkspaceDefinition(workflowTemplate);
+
+    expect(definition.flowAutomations).toEqual([
+      expect.objectContaining({
+        name: "A manual workflow",
+        triggerType: "manual",
+        flowDefinition: expect.objectContaining({
+          precondition: "trigger.payload.ready === true",
+        }),
+      }),
+    ]);
+    expect("automations" in definition).toBe(false);
+  });
+
+  it("preserves action applicability and confirmation policy", () => {
+    const { definition } = toWorkspaceDefinition(workflowTemplate);
+    expect(definition.actionPlacements?.[0]).toMatchObject({
+      when: { requiredFacetSlugs: ["lead"], propertyEquals: { stage: "ready" } },
+      confirmation: { title: "Continue?", confirmLabel: "Run" },
+    });
+  });
+});

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,

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 }