@synap-core/workspace-templates 0.7.0 → 0.7.2

package/src/concept-guard.ts

@@ -0,0 +1,219 @@
+/**
+ * Cross-template CONCEPT guard — catches vocabulary forks between templates.
+ *
+ * WHY THIS EXISTS (read before weakening or deleting it):
+ * `business-developer.yaml` introduced workspace-scoped `crm-lead`/`crm-client`
+ * for the same real-world concept that `foundation.yaml`/`crm.yaml` declare as
+ * pod-wide shared `lead`/`client`. Nothing failed. Three reasons:
+ *
+ *   1. `build.mjs`'s `validate()` runs PER FILE, inside the read loop, so it
+ *      structurally cannot see that another template already owns `lead`.
+ *   2. The only vocabulary rule that exists (`template-shared-role-ssot.test.ts`
+ *      in synap-backend) polices a HARDCODED five-slug set — and it FORBIDS
+ *      declaring one of those slugs workspace-scoped, which is exactly what the
+ *      two-tier design legitimately needed. So RENAMING was the path of least
+ *      resistance: `crm-lead` is outside the set and passes silently. That rule
+ *      polices SPELLING, not MEANING.
+ *   3. That test also cannot run in CI — it resolves this package across a
+ *      sibling-repo relative path that CI never checks out. It is green on a dev
+ *      machine and mute everywhere else.
+ *
+ * This guard lives HERE, in the repo that owns the template source, and runs in
+ * this repo's CI (`pnpm test`) and in `pnpm build` / `prepublishOnly` via
+ * `scripts/check-concepts.mjs`. It is deliberately NOT a hardcoded slug list —
+ * that is the pattern that failed.
+ *
+ * WHAT IT DOES NOT DO: it does not guess. There is no fuzzy name matching, no
+ * edit distance, no synonym table. A guesser nobody trusts is worse than no
+ * guard. It uses two exact, falsifiable signals only — see the rules below.
+ */
+
+import { WORKSPACE_TEMPLATES } from "./templates.js";
+import type { TemplateProfile, WorkspaceYaml } from "./types.js";
+
+export interface ConceptViolation {
+  rule: "concept-collision" | "alias-shape-divergence" | "stale-allowlist";
+  /** The concept term or semantic slug the finding is about. */
+  concept: string;
+  message: string;
+}
+
+/**
+ * DECLARED, INTENTIONAL divergences — the escape hatch, and deliberately the
+ * SECONDARY mechanism. An entry here is an author saying "yes, two spellings of
+ * one concept, on purpose, and here is why". Keep it tiny; every entry must
+ * carry its WHY. A key that stops matching anything FAILS the guard, so this
+ * list cannot rot into a graveyard.
+ *
+ * Key = the two colliding profile slugs, sorted, joined by "|".
+ */
+export const DECLARED_DIVERGENCES: Record<string, string> = {
+  // Two-tier lead vocabulary, documented at business-developer.yaml:1-16.
+  // Foundation's `lead` is a SHARED pod-wide role: being a lead is true
+  // everywhere. `crm-lead` is a WORKSPACE-scoped role so a person can be a lead
+  // inside one CRM workspace without becoming a lead across the whole pod. The
+  // tiers are intentionally separate rows; `semanticSlug: crm.lead` records the
+  // kinship so the two are discoverable as one concept via getBySemanticSlug.
+  "crm-lead|lead":
+    "business-developer: workspace-tier lead, deliberately NOT pod-wide foundation `lead` (two-tier CRM design)",
+  // Same reasoning for the post-sale side of the same lifecycle.
+  "client|crm-client":
+    "business-developer: workspace-tier client, deliberately NOT pod-wide foundation `client` (two-tier CRM design)",
+};
+
+/**
+ * A profile's concept identity. `semanticSlug` is the ONE field that can say
+ * "same concept, different spelling"; synap-backend's `profile-repository.ts`
+ * defaults it to the slug when unset, so this mirrors runtime truth exactly.
+ */
+function effectiveSemanticSlug(profile: TemplateProfile): string {
+  return profile.semanticSlug ?? profile.slug;
+}
+
+/**
+ * The bare noun a concept identifier ends in: `crm.lead` → `lead`,
+ * `crm-lead` → `lead`, `lead` → `lead`.
+ *
+ * This is EXACT terminal-token equality on the author's own qualified name —
+ * not a similarity heuristic. `crm-lead` and `lead` collide because the author
+ * literally wrote the same noun; `prospect` and `lead` do not collide, and that
+ * is honest: no guard can know they mean the same thing.
+ */
+export function conceptTerm(semanticSlug: string): string {
+  const tokens = semanticSlug.split(/[.\-_]/).filter(Boolean);
+  return (tokens[tokens.length - 1] ?? semanticSlug).toLowerCase();
+}
+
+/** `undefined`/`null` = the template makes NO claim, which cannot contradict one. */
+function declaredValue(profile: TemplateProfile, field: string): string | null {
+  const raw = (profile as unknown as Record<string, unknown>)[field];
+  if (raw === undefined || raw === null) return null;
+  if (field === "applicableKinds") {
+    return Array.isArray(raw) ? JSON.stringify([...(raw as string[])].sort()) : null;
+  }
+  // `scope` is authored as both `shared` and `WORKSPACE` across the corpus.
+  return JSON.stringify(String(raw).toLowerCase());
+}
+
+function pairKey(a: string, b: string): string {
+  return [a, b].sort().join("|");
+}
+
+interface ProfileRef {
+  template: string;
+  profile: TemplateProfile;
+}
+
+export function findConceptViolations(
+  templates: Record<string, WorkspaceYaml> = WORKSPACE_TEMPLATES
+): ConceptViolation[] {
+  const violations: ConceptViolation[] = [];
+  const all: ProfileRef[] = [];
+  for (const [templateSlug, template] of Object.entries(templates)) {
+    for (const profile of template.profiles ?? []) {
+      all.push({ template: templateSlug, profile });
+    }
+  }
+
+  // ── RULE 1 — concept collision across templates ────────────────────────────
+  // Two ROLE profiles, in DIFFERENT templates, with DIFFERENT slugs, whose
+  // concept identifiers end in the same noun. Every qualifier is load-bearing:
+  //   • ROLE only — roles are the facet vocabulary (the hat an entity wears),
+  //     where a fork actually hurts: the same person is a lead under one
+  //     spelling and not under the other. Kinds are things with their own life.
+  //   • DIFFERENT templates — sibling roles authored in ONE file are a
+  //     deliberate distinction the author had in front of them (blockchain-
+  //     ecosystem's `marketing-agency` + `paid-ads-agency`). A fork is by
+  //     definition cross-template drift. This qualifier is what takes the rule
+  //     from 1 false positive to 0 on the current corpus.
+  //   • DIFFERENT slugs — the SAME slug in several templates is the documented
+  //     overlay/reuse mechanism (`lead` in foundation + crm + marketing), not a
+  //     fork. That case is rule 2's business.
+  const roles = all.filter((r) => r.profile.profileKind === "role");
+  const usedAllowlistKeys = new Set<string>();
+  const reportedPairs = new Set<string>();
+
+  for (let i = 0; i < roles.length; i++) {
+    for (let j = i + 1; j < roles.length; j++) {
+      const a = roles[i]!;
+      const b = roles[j]!;
+      if (a.template === b.template) continue;
+      if (a.profile.slug === b.profile.slug) continue;
+      const term = conceptTerm(effectiveSemanticSlug(a.profile));
+      if (term !== conceptTerm(effectiveSemanticSlug(b.profile))) continue;
+
+      const key = pairKey(a.profile.slug, b.profile.slug);
+      if (key in DECLARED_DIVERGENCES) {
+        usedAllowlistKeys.add(key);
+        continue;
+      }
+      if (reportedPairs.has(key)) continue;
+      reportedPairs.add(key);
+      violations.push({
+        rule: "concept-collision",
+        concept: term,
+        message:
+          `two role profiles denote the concept "${term}" under different slugs: ` +
+          `"${a.profile.slug}" (${a.template}) vs "${b.profile.slug}" (${b.template}). ` +
+          `Either REUSE the existing slug, or — if the divergence is intentional — declare it: ` +
+          `set an explicit \`semanticSlug\` on the new profile and add "${key}" to ` +
+          `DECLARED_DIVERGENCES in src/concept-guard.ts with the reason.`,
+      });
+    }
+  }
+
+  // ── RULE 2 — declared alias, forked shape ──────────────────────────────────
+  // Two profiles with DIFFERENT slugs that claim the SAME `semanticSlug` are
+  // asserting "one concept". Then their row-level shape must agree, or the
+  // assertion is a lie and the field is decorative. Absence is not a conflict:
+  // a template that OMITS a row-level field makes no claim (that is exactly how
+  // marketing.yaml correctly stops restating what foundation owns).
+  // Same-slug re-declaration is NOT checked here — that is the overlay path.
+  const bySemantic = new Map<string, ProfileRef[]>();
+  for (const ref of all) {
+    const key = effectiveSemanticSlug(ref.profile);
+    const bucket = bySemantic.get(key);
+    if (bucket) bucket.push(ref);
+    else bySemantic.set(key, [ref]);
+  }
+  for (const [semantic, group] of bySemantic) {
+    if (new Set(group.map((r) => r.profile.slug)).size < 2) continue;
+    for (const field of ["profileKind", "scope", "applicableKinds"]) {
+      const claims = new Map<string, string>();
+      for (const ref of group) {
+        const value = declaredValue(ref.profile, field);
+        if (value === null) continue;
+        const existing = claims.get(value);
+        if (!existing) claims.set(value, `${ref.template}:${ref.profile.slug}`);
+      }
+      if (claims.size > 1) {
+        violations.push({
+          rule: "alias-shape-divergence",
+          concept: semantic,
+          message:
+            `profiles aliased to semanticSlug "${semantic}" disagree on \`${field}\`: ` +
+            [...claims].map(([v, who]) => `${who} declares ${v}`).join(", ") +
+            `. Aliased profiles assert one concept — make the shapes agree, or drop the alias.`,
+        });
+      }
+    }
+  }
+
+  // ── RULE 3 — the allowlist may not rot ─────────────────────────────────────
+  for (const key of Object.keys(DECLARED_DIVERGENCES)) {
+    if (usedAllowlistKeys.has(key)) continue;
+    violations.push({
+      rule: "stale-allowlist",
+      concept: key,
+      message:
+        `DECLARED_DIVERGENCES entry "${key}" no longer matches any collision — ` +
+        `the divergence was resolved or the profiles were renamed. Delete the entry.`,
+    });
+  }
+
+  return violations;
+}
+
+export function formatConceptViolations(violations: ConceptViolation[]): string {
+  return violations.map((v) => `  • [${v.rule}] ${v.message}`).join("\n");
+}

package/src/ecosystem.yaml

@@ -536,7 +536,10 @@ layout:
       icon: database
 
 bento:
-  viewName: Ecosystem Map
+  # Distinct from the "Ecosystem Map" graph view 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.
+  viewName: Ecosystem Home
   blocks:
     - kind: view
       viewName: Ecosystem Map

package/src/generate.d.mts

@@ -0,0 +1,15 @@
+/** Types for `generate.mjs` — the shared renderer for `src/templates.ts`. */
+
+export interface RawTemplateEntry {
+  /** Source file name, e.g. `business-developer.yaml`. */
+  file: string;
+  /** `meta.slug` as declared in the YAML. */
+  slug: string;
+  /** The parsed YAML document, untyped on purpose (build-time shape). */
+  data: unknown;
+}
+
+export declare const SRC_DIR: string;
+export declare const TEMPLATES_FILE: string;
+export declare function readYamlTemplates(): RawTemplateEntry[];
+export declare function renderTemplatesModule(templates: RawTemplateEntry[]): string;

package/src/generate.mjs

@@ -0,0 +1,86 @@
+/**
+ * The ONE renderer for the generated `src/templates.ts` corpus.
+ *
+ * WHY THIS FILE EXISTS (read before inlining it back into build.mjs):
+ * `src/templates.ts` is auto-generated from `src/*.yaml` AND committed to git
+ * (it has to be — `browser/tsconfig.json` aliases this package straight at
+ * `src/`, with no build step, and synap-backend's
+ * `__tripwires__/template-shared-role-ssot.test.ts` reads the file by path).
+ * A committed artifact can go stale: edit a YAML, run `pnpm test`, and every
+ * template-corpus check — including `concept-guard` — passes against
+ * vocabulary that no longer exists on disk. Only `pnpm build` regenerated.
+ *
+ * So the render logic lives HERE, and two callers share it:
+ *   • `build.mjs`            — validates, renders, WRITES the file.
+ *   • `src/templates-freshness.test.ts` — renders in memory and asserts the
+ *     committed file matches byte-for-byte. Runs in `pnpm test`, i.e. in CI.
+ *
+ * Duplicating the template string into the test would recreate the same class
+ * of drift one level up, so don't.
+ */
+
+import { readFileSync, readdirSync } from 'fs';
+import { dirname, join } from 'path';
+import { fileURLToPath } from 'url';
+import yaml from 'js-yaml';
+
+export const SRC_DIR = dirname(fileURLToPath(import.meta.url));
+export const TEMPLATES_FILE = join(SRC_DIR, 'templates.ts');
+
+/**
+ * Read + parse every `src/*.yaml`, in the same (readdir) order build.mjs used.
+ * No validation here — validation stays in build.mjs, which is the writer.
+ */
+export function readYamlTemplates() {
+  return readdirSync(SRC_DIR)
+    .filter((f) => f.endsWith('.yaml'))
+    .map((file) => {
+      const parsed = yaml.load(readFileSync(join(SRC_DIR, file), 'utf-8'));
+      return { file, slug: parsed?.meta?.slug, data: parsed };
+    });
+}
+
+/** Render the full text of `src/templates.ts` for a corpus. Pure. */
+export function renderTemplatesModule(templates) {
+  const data = JSON.stringify(
+    Object.fromEntries(templates.map((t) => [t.slug, t.data])),
+    null,
+    2,
+  );
+
+  return `// ═══════════════════════════════════════════════════════════════════════
+// AUTO-GENERATED from YAML source files in src/*.yaml
+// DO NOT EDIT — run \`node build.mjs\` or \`pnpm build\` to regenerate
+// ═══════════════════════════════════════════════════════════════════════
+
+import type { WorkspaceYaml } from './types.js';
+
+const DATA = ${data} as unknown as Record<string, WorkspaceYaml>;
+
+export const WORKSPACE_TEMPLATES: Record<string, WorkspaceYaml> = DATA;
+
+export type WorkspaceTemplateSlug = keyof typeof WORKSPACE_TEMPLATES;
+
+export function getWorkspaceTemplate(slug: string): WorkspaceYaml | undefined {
+  return WORKSPACE_TEMPLATES[slug];
+}
+
+export function listWorkspaceTemplates(): WorkspaceYaml[] {
+  return Object.values(WORKSPACE_TEMPLATES);
+}
+
+/**
+ * Public templates only (\`meta.isPublic !== false\`). This is a CONVENIENCE
+ * filter for the default picker — NOT a security boundary: the private YAML
+ * still ships in the published tarball, so anything that must not leak cannot
+ * rely on this. \`listWorkspaceTemplates()\` returns all of them (CLI, seeder,
+ * tripwire need the full set). Publicity is also expressed per-entry as
+ * \`CatalogEntry.isPrivate\` by \`mergeCatalog()\`, so a caller can pass ALL
+ * templates and filter at the presentation layer instead of choosing a list
+ * function up front — the merge door itself never filters (it stays pure).
+ */
+export function listPublicTemplates(): WorkspaceYaml[] {
+  return Object.values(WORKSPACE_TEMPLATES).filter(t => t.meta?.isPublic !== false);
+}
+`;
+}

package/src/index.ts

@@ -85,6 +85,30 @@ 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";
+
+// Cross-template vocabulary-fork guard. Exported because the build/publish gate
+// (`scripts/check-concepts.mjs`) runs it off `dist/` — one implementation, two
+// enforcement points (CI `pnpm test` + `pnpm build`).
+export {
+  findConceptViolations,
+  formatConceptViolations,
+  conceptTerm,
+  DECLARED_DIVERGENCES,
+} from "./concept-guard.js";
+export type { ConceptViolation } from "./concept-guard.js";
+
 export {
   toWorkspaceDefinition,
   toPackageDefinition,

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