@synap-core/workspace-templates 0.7.1 → 0.7.2

package/src/meetings-knowledge.yaml

@@ -25,26 +25,92 @@ workspace:
     meetings: provider
 
 profiles:
-  # ── Meeting (owned here) ─────────────────────────────────────────────────
+  # ── Reused pod-wide kinds ────────────────────────────────────────────────
+  # Declared minimally because the workspace-definition validator resolves view
+  # scopes and entityLink endpoints ONLY against the slugs declared here — a
+  # referenced-but-undeclared slug throws at install time, it does not fall
+  # through to the pod-wide kind. Kept light on purpose: these kinds are owned
+  # pod-wide (identity + full schema live there), this is just the local grant.
+  - slug: person
+    displayName: Person
+    icon: user
+    color: amber
+    description: A meeting attendee.
+    properties:
+      - slug: email
+        label: Email
+        valueType: string
+        inputType: email
+
+  - slug: task
+    displayName: Task
+    icon: check-square
+    color: blue
+    description: An action item that came out of a meeting.
+    properties:
+      # NOTE: the pod-wide `task` already ships `status` and `dueDate`, and the
+      # applier SKIPS properties that already exist — so these are not what makes
+      # the kanban work. They are restated only so the SLUG is declarable here
+      # (the validator resolves view scopes against this template's `profiles`).
+      # The enum mirrors the live pod-wide one exactly; diverging would be
+      # misleading since the declaration is skipped and the real lanes win.
+      - slug: status
+        label: Status
+        valueType: string
+        inputType: select
+        enumValues: [todo, in-progress, done, cancelled]
+        constraints: { defaultValue: todo }
+      - slug: dueDate
+        label: Due
+        valueType: date
+        inputType: date
+
+  - slug: note
+    displayName: Note
+    icon: file-text
+    color: violet
+    description: A note or summary captured from a meeting.
+    properties:
+      - slug: content
+        label: Content
+        valueType: string
+        inputType: textarea
+
+  # ── Event (reused pod-wide kind — the meeting's IDENTITY) ────────────────
+  # The pod already seeds `event`, and the live Google Calendar sync writes
+  # `entities.type = "event"`. A parallel `meeting` KIND would therefore sit
+  # empty beside a synced calendar AND mint a second entity for the same
+  # real-world meeting. Identity lives here; the meeting-ness is a role below.
+  - slug: event
+    displayName: Event
+    icon: calendar
+    color: sky
+    description: A calendar event — the thing a meeting actually is.
+    properties:
+      - slug: startDate
+        label: Start
+        valueType: date
+        inputType: date
+
+  # ── Meeting (a ROLE the event plays — NOT a second entity) ───────────────
+  # Kind-vs-Facets rule: a role an entity PLAYS is a facet attached to the real
+  # thing, never its own kind. Date/attendees/location come from the `event`;
+  # only these four are genuinely new. The import playbook ATTACHES this role to
+  # the already-synced event rather than creating a duplicate.
   - slug: meeting
     displayName: Meeting
     icon: video
     color: violet
-    description: A meeting — its date, attendees, and what came out of it.
+    scope: shared
+    profileKind: role
+    applicableKinds: [event]
+    description: The meeting hat an event wears — platform, transcript, 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
@@ -67,13 +133,37 @@ views:
     scopeProfileSlug: meeting
     description: Every meeting, its platform, and whether it's been processed.
     config:
-      columns: [title, meetingDate, platform, status]
+      columns: [title, startDate, platform, status]
+  # The workspace's daily question: which meetings happened but haven't been
+  # imported+summarized yet. This is the one action the workspace exists to
+  # prompt, so it is the landing view — not the full table.
+  - name: Needs Processing
+    slug: meetings-unprocessed
+    type: list
+    scopeProfileSlug: meeting
+    description: Meetings that happened but haven't been imported and summarized yet.
+    config:
+      filterBy: { field: status, operator: is, value: completed }
     defaultView: true
+  # Summaries the playbook writes land here — without a view they're invisible.
+  - name: Meeting Notes
+    slug: meeting-notes
+    type: list
+    scopeProfileSlug: note
+    description: Summaries and notes produced from meetings.
   - name: Meetings Calendar
     slug: meetings-calendar
     type: calendar
     scopeProfileSlug: meeting
     description: Meetings on a calendar, keyed on their date.
+    # The date comes from the underlying `event` (startDate), not the meeting
+    # role. NOTE the `properties.` prefix is REQUIRED: the calendar resolves
+    # dateField with a dotted-path walker against the entity, so a bare
+    # `startDate` reads `entity.startDate` (undefined) and only renders at all
+    # by falling through the hardcoded dueDate→startDate→startTime chain.
+    config:
+      dateField: properties.startDate
+      colorBy: status
   - name: Action Items
     slug: meeting-action-items
     type: kanban
@@ -152,20 +242,41 @@ onboarding:
         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.
+      - >
+        "Attendees" as a list of names is not attendee capture — it's a string.
+        If the summary says "Sarah will send the deck" and Sarah isn't a tracked
+        person linked to that task, the next meeting with Sarah starts from zero
+        again. Resolve every attendee to a real person, or say out loud that
+        you're choosing not to.
+      - >
+        A summary nobody re-reads is theatre. The test for a good meeting note is
+        whether someone who missed the call could act from it alone — if it needs
+        the transcript to make sense, it isn't a summary yet.
     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.
+      The PIPE is live, not the rows: transcript source and calendar connected,
+      the Import & Summarize playbook run once end-to-end on a real recent
+      meeting, and the output inspected together — a note a human would actually
+      keep, tasks that are genuinely actionable, and attendees resolved to
+      tracked people rather than name strings. If the first import produces vague
+      tasks ("follow up"), fix the extraction bar now, not after fifty meetings.
   collect:
+    # Deliberately NOT a backfill. The import playbook fills date, summary,
+    # attendees and action items — asking the human to type them here would
+    # invert the product's whole loop (capture → AI structures it). The only
+    # thing the agent can't infer is which meetings deserve the pipe.
     - profileSlug: meeting
-      what: Recent or upcoming meetings worth tracking.
+      what: >
+        Which recurring meetings are worth importing every time — the standing
+        1:1s, the weekly ops call. A watchlist, not a backlog.
       cardinality: few
-      keyFields: [meetingDate, platform]
+      keyFields: [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.
+    - "Name a meeting from last week whose outcome you can't remember. What did that cost you?"
+    - "When a meeting produces an action item, where does it go today — and does it survive the week?"
+    - "Which recurring meeting would you cancel if you could see its action-item completion rate?"
+  doneWhen: >
+    Transcript source connected and one real meeting imported end-to-end —
+    summary note, at least one action item, and attendees resolved to people.
 
 app:
   kind: stored
@@ -174,7 +285,7 @@ app:
 layout:
   defaultView: Meetings
   defaultApp: null
-  pinnedApps: [dashboard, data]
+  pinnedApps: [dashboard, data, chat]
   sidebarItems:
     - kind: view
       viewName: Meetings
@@ -194,7 +305,10 @@ layout:
       icon: database
 
 bento:
-  viewName: Meetings
+  # Distinct from the "Meetings" table it embeds — the bento is created as its
+  # OWN view row, so reusing an embedded view's name puts two identically-named
+  # views in the switcher and makes layout.defaultView ambiguous.
+  viewName: Meetings Home
   blocks:
     - kind: view
       viewName: Meetings

package/src/outreach-comms.yaml

@@ -256,7 +256,7 @@ app:
 layout:
   defaultView: Campaigns
   defaultApp: null
-  pinnedApps: [dashboard, data]
+  pinnedApps: [dashboard, data, chat]
   sidebarItems:
     - kind: view
       viewName: Campaigns
@@ -272,7 +272,10 @@ layout:
       icon: database
 
 bento:
-  viewName: Campaigns
+  # Distinct from the "Campaigns" table it embeds — see meetings-knowledge:
+  # the bento becomes its own view row, so a shared name collides in the
+  # switcher and makes layout.defaultView ambiguous.
+  viewName: Outreach Home
   blocks:
     - kind: view
       viewName: Campaigns

package/src/templates-freshness.test.ts

@@ -0,0 +1,55 @@
+/**
+ * FRESHNESS GATE for the generated-and-committed `src/templates.ts`.
+ *
+ * WHY (read before deleting):
+ * `src/templates.ts` is generated from `src/*.yaml` by `build.mjs` and is
+ * COMMITTED to git. Every other check in this package — `concept-guard`,
+ * `catalog`, `composition-graph`, the backend's shared-role tripwire — reads
+ * that committed snapshot, NOT the YAML. Root `pnpm test` does not regenerate
+ * it. So before this test, an author could edit a template YAML, run
+ * `pnpm test`, and get a green guard against vocabulary that no longer exists
+ * on disk. A guard that can pass against a stale artifact is not a guard.
+ *
+ * This test closes that hole in the cheapest possible place: the existing
+ * `pnpm test` CI step. It re-renders the corpus IN MEMORY with the SAME
+ * function `build.mjs` uses (`src/generate.mjs`) and asserts the committed file
+ * matches byte-for-byte. No build dependency, no extra CI step, ~tens of ms.
+ */
+
+import { readFileSync } from "node:fs";
+import { describe, expect, it } from "vitest";
+import {
+  readYamlTemplates,
+  renderTemplatesModule,
+  TEMPLATES_FILE,
+} from "./generate.mjs";
+
+describe("templates.ts freshness", () => {
+  it("matches what build.mjs would generate from src/*.yaml", () => {
+    const expected = renderTemplatesModule(readYamlTemplates());
+    const actual = readFileSync(TEMPLATES_FILE, "utf-8");
+
+    if (actual !== expected) {
+      throw new Error(
+        [
+          "",
+          "❌ src/templates.ts is STALE — it no longer matches src/*.yaml.",
+          "",
+          "   Every template check (concept-guard, catalog, composition-graph, and",
+          "   synap-backend's shared-role tripwire) reads this generated file, so a",
+          "   stale snapshot makes them all green against vocabulary that is not on",
+          "   disk anymore.",
+          "",
+          "   FIX — regenerate and commit the result:",
+          "     cd synap-app/packages/workspace-templates && pnpm build:yaml",
+          "",
+          "   (`pnpm build` also regenerates, and additionally runs tsup + the",
+          "   converter/concept guards.)",
+          "",
+        ].join("\n"),
+      );
+    }
+
+    expect(actual).toBe(expected);
+  });
+});

package/src/templates.ts

@@ -6790,6 +6790,7 @@ const DATA = {
         "description": "A person or company actively being qualified or contacted by this CRM workspace.",
         "scope": "WORKSPACE",
         "profileKind": "role",
+        "semanticSlug": "crm.lead",
         "applicableKinds": [
           "person",
           "company"
@@ -6897,6 +6898,7 @@ const DATA = {
         "description": "A CRM lead converted by a won commercial proposal and ready for handoff.",
         "scope": "WORKSPACE",
         "profileKind": "role",
+        "semanticSlug": "crm.client",
         "applicableKinds": [
           "person",
           "company"
@@ -13243,7 +13245,7 @@ const DATA = {
       ]
     },
     "bento": {
-      "viewName": "Ecosystem Map",
+      "viewName": "Ecosystem Home",
       "blocks": [
         {
           "kind": "view",
@@ -22472,18 +22474,92 @@ const DATA = {
     },
     "profiles": [
       {
-        "slug": "meeting",
-        "displayName": "Meeting",
-        "icon": "video",
+        "slug": "person",
+        "displayName": "Person",
+        "icon": "user",
+        "color": "amber",
+        "description": "A meeting attendee.",
+        "properties": [
+          {
+            "slug": "email",
+            "label": "Email",
+            "valueType": "string",
+            "inputType": "email"
+          }
+        ]
+      },
+      {
+        "slug": "task",
+        "displayName": "Task",
+        "icon": "check-square",
+        "color": "blue",
+        "description": "An action item that came out of a meeting.",
+        "properties": [
+          {
+            "slug": "status",
+            "label": "Status",
+            "valueType": "string",
+            "inputType": "select",
+            "enumValues": [
+              "todo",
+              "in-progress",
+              "done",
+              "cancelled"
+            ],
+            "constraints": {
+              "defaultValue": "todo"
+            }
+          },
+          {
+            "slug": "dueDate",
+            "label": "Due",
+            "valueType": "date",
+            "inputType": "date"
+          }
+        ]
+      },
+      {
+        "slug": "note",
+        "displayName": "Note",
+        "icon": "file-text",
         "color": "violet",
-        "description": "A meeting — its date, attendees, and what came out of it.",
+        "description": "A note or summary captured from a meeting.",
         "properties": [
           {
-            "slug": "meetingDate",
-            "label": "Date",
+            "slug": "content",
+            "label": "Content",
+            "valueType": "string",
+            "inputType": "textarea"
+          }
+        ]
+      },
+      {
+        "slug": "event",
+        "displayName": "Event",
+        "icon": "calendar",
+        "color": "sky",
+        "description": "A calendar event — the thing a meeting actually is.",
+        "properties": [
+          {
+            "slug": "startDate",
+            "label": "Start",
             "valueType": "date",
             "inputType": "date"
-          },
+          }
+        ]
+      },
+      {
+        "slug": "meeting",
+        "displayName": "Meeting",
+        "icon": "video",
+        "color": "violet",
+        "scope": "shared",
+        "profileKind": "role",
+        "applicableKinds": [
+          "event"
+        ],
+        "description": "The meeting hat an event wears — platform, transcript, and what came out of it.",
+        "properties": [
           {
             "slug": "platform",
             "label": "Platform",
@@ -22497,12 +22573,6 @@ const DATA = {
               "other"
             ]
           },
-          {
-            "slug": "attendees",
-            "label": "Attendees",
-            "valueType": "array",
-            "inputType": "text"
-          },
           {
             "slug": "status",
             "label": "Status",
@@ -22542,19 +22612,44 @@ const DATA = {
         "config": {
           "columns": [
             "title",
-            "meetingDate",
+            "startDate",
             "platform",
             "status"
           ]
+        }
+      },
+      {
+        "name": "Needs Processing",
+        "slug": "meetings-unprocessed",
+        "type": "list",
+        "scopeProfileSlug": "meeting",
+        "description": "Meetings that happened but haven't been imported and summarized yet.",
+        "config": {
+          "filterBy": {
+            "field": "status",
+            "operator": "is",
+            "value": "completed"
+          }
         },
         "defaultView": true
       },
+      {
+        "name": "Meeting Notes",
+        "slug": "meeting-notes",
+        "type": "list",
+        "scopeProfileSlug": "note",
+        "description": "Summaries and notes produced from meetings."
+      },
       {
         "name": "Meetings Calendar",
         "slug": "meetings-calendar",
         "type": "calendar",
         "scopeProfileSlug": "meeting",
-        "description": "Meetings on a calendar, keyed on their date."
+        "description": "Meetings on a calendar, keyed on their date.",
+        "config": {
+          "dateField": "properties.startDate",
+          "colorBy": "status"
+        }
       },
       {
         "name": "Action Items",
@@ -22637,27 +22732,28 @@ const DATA = {
           "Attendees are people, not names in a transcript — capture them as tracked contacts so the next meeting with them has history.\n"
         ],
         "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.\n"
+          "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.\n",
+          "\"Attendees\" as a list of names is not attendee capture — it's a string. If the summary says \"Sarah will send the deck\" and Sarah isn't a tracked person linked to that task, the next meeting with Sarah starts from zero again. Resolve every attendee to a real person, or say out loud that you're choosing not to.\n",
+          "A summary nobody re-reads is theatre. The test for a good meeting note is whether someone who missed the call could act from it alone — if it needs the transcript to make sense, it isn't a summary yet.\n"
         ],
-        "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.\n"
+        "bar": "The PIPE is live, not the rows: transcript source and calendar connected, the Import & Summarize playbook run once end-to-end on a real recent meeting, and the output inspected together — a note a human would actually keep, tasks that are genuinely actionable, and attendees resolved to tracked people rather than name strings. If the first import produces vague tasks (\"follow up\"), fix the extraction bar now, not after fifty meetings.\n"
       },
       "collect": [
         {
           "profileSlug": "meeting",
-          "what": "Recent or upcoming meetings worth tracking.",
+          "what": "Which recurring meetings are worth importing every time — the standing 1:1s, the weekly ops call. A watchlist, not a backlog.\n",
           "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?"
+        "Name a meeting from last week whose outcome you can't remember. What did that cost you?",
+        "When a meeting produces an action item, where does it go today — and does it survive the week?",
+        "Which recurring meeting would you cancel if you could see its action-item completion rate?"
       ],
-      "doneWhen": "A few meetings captured with a date and platform, at least one with a summary."
+      "doneWhen": "Transcript source connected and one real meeting imported end-to-end — summary note, at least one action item, and attendees resolved to people.\n"
     },
     "app": {
       "kind": "stored",
@@ -22668,7 +22764,8 @@ const DATA = {
       "defaultApp": null,
       "pinnedApps": [
         "dashboard",
-        "data"
+        "data",
+        "chat"
       ],
       "sidebarItems": [
         {
@@ -22698,7 +22795,7 @@ const DATA = {
       ]
     },
     "bento": {
-      "viewName": "Meetings",
+      "viewName": "Meetings Home",
       "blocks": [
         {
           "kind": "view",
@@ -23421,7 +23518,8 @@ const DATA = {
       "defaultApp": null,
       "pinnedApps": [
         "dashboard",
-        "data"
+        "data",
+        "chat"
       ],
       "sidebarItems": [
         {
@@ -23445,7 +23543,7 @@ const DATA = {
       ]
     },
     "bento": {
-      "viewName": "Campaigns",
+      "viewName": "Outreach Home",
       "blocks": [
         {
           "kind": "view",