@synap-core/workspace-templates 0.9.4 → 0.11.0

package/src/concept-guard.test.ts

@@ -43,14 +43,25 @@ describe("concept guard — shipped corpus", () => {
     ).toEqual([]);
   });
 
-  it("still sees the two-tier CRM divergence — declared, not absent", () => {
-    // If business-developer's crm-lead/crm-client ever stopped colliding with
-    // foundation's lead/client, the allowlist would be stale and rule 3 would
-    // fire. This asserts the allowlist is load-bearing, not inert.
-    const withoutAllowlist = Object.keys(DECLARED_DIVERGENCES);
-    expect(withoutAllowlist).toEqual(["crm-lead|lead", "client|crm-client"]);
-    expect(WORKSPACE_TEMPLATES["business-developer"]?.profiles.find((p) => p.slug === "crm-lead")
-      ?.semanticSlug).toBe("crm.lead");
+  it("needs NO declared divergence — the CRM fork was resolved, not allowlisted", () => {
+    // The allowlist was born carrying `crm-lead|lead` + `client|crm-client`.
+    // business-developer.yaml now re-declares the SHARED `lead`/`client` roles
+    // and carries its business-development fields as workspace-overlay
+    // properties, so there is no fork left to declare. Rule 3 (stale-allowlist)
+    // is what forces this to stay true: a leftover entry fails CI.
+    expect(Object.keys(DECLARED_DIVERGENCES)).toEqual([]);
+
+    const bd = WORKSPACE_TEMPLATES["business-developer"]?.profiles ?? [];
+    expect(bd.map((p) => p.slug)).not.toContain("crm-lead");
+    expect(bd.map((p) => p.slug)).not.toContain("crm-client");
+    for (const slug of ["lead", "client"]) {
+      const reused = bd.find((p) => p.slug === slug);
+      expect(reused, `business-developer must reuse shared '${slug}'`).toBeDefined();
+      expect(reused?.scope).toBe("shared");
+      expect(reused?.profileKind).toBe("role");
+      // No alias: the shared slug IS the concept identity.
+      expect(reused?.semanticSlug).toBeUndefined();
+    }
   });
 });
 
@@ -71,33 +82,36 @@ describe("concept guard — fires on a real fork", () => {
         "some-addon": [role("channel-partner", { scope: "WORKSPACE" })],
       })
     );
-    // Fixture corpora never match the real allowlist, so the stale-allowlist
-    // findings are expected noise here — the collision is what is under test.
-    const forks = violations.filter((v) => v.rule !== "stale-allowlist");
-    expect(forks).toHaveLength(1);
-    expect(forks[0]!.rule).toBe("concept-collision");
-    expect(forks[0]!.concept).toBe("partner");
-    expect(forks[0]!.message).toContain("channel-partner");
+    expect(violations).toHaveLength(1);
+    expect(violations[0]!.rule).toBe("concept-collision");
+    expect(violations[0]!.concept).toBe("partner");
+    expect(violations[0]!.message).toContain("channel-partner");
   });
 
   it("suppresses exactly the pair an author declared — and nothing else", () => {
-    // The SAME shape as the test above, but with the slugs the allowlist names.
+    // The SAME shape as the test above, but with an allowlist naming the pair.
     // This is the whole safety property of the escape hatch: it is per-pair, not
-    // per-concept, so a THIRD `lead` spelling would still fail.
+    // per-concept, so a THIRD `lead` spelling would still fail. The allowlist is
+    // INJECTED because the shipped one is (healthily) empty — the guard must
+    // still behave correctly the next time someone genuinely needs an entry.
+    const allowlist = { "crm-lead|lead": "declared for this fixture" };
     const declared = findConceptViolations(
       corpus({
         foundation: [role("lead", { scope: "shared" })],
         "business-developer": [role("crm-lead", { semanticSlug: "crm.lead", scope: "WORKSPACE" })],
-      })
+      }),
+      allowlist
     );
     expect(declared.filter((v) => v.rule === "concept-collision")).toEqual([]);
+    expect(declared.filter((v) => v.rule === "stale-allowlist")).toEqual([]);
 
     const third = findConceptViolations(
       corpus({
         foundation: [role("lead", { scope: "shared" })],
         "business-developer": [role("crm-lead", { semanticSlug: "crm.lead", scope: "WORKSPACE" })],
         "another-addon": [role("sales-lead", { scope: "WORKSPACE" })],
-      })
+      }),
+      allowlist
     );
     expect(third.filter((v) => v.rule === "concept-collision")).toHaveLength(2);
   });
@@ -109,9 +123,7 @@ describe("concept guard — fires on a real fork", () => {
         other: [role("pipeline-lead", { semanticSlug: "sales.lead" })],
       })
     );
-    expect(violations.filter((v) => v.rule !== "stale-allowlist").map((v) => v.rule)).toEqual([
-      "concept-collision",
-    ]);
+    expect(violations.map((v) => v.rule)).toEqual(["concept-collision"]);
   });
 
   it("fails when two aliased profiles disagree on shape", () => {
@@ -125,11 +137,15 @@ describe("concept guard — fires on a real fork", () => {
   });
 
   it("fails when an allowlist entry stops matching anything", () => {
-    // DECLARED_DIVERGENCES is module-level, so an empty corpus makes every
-    // entry stale — exactly the state a resolved divergence would leave behind.
-    const violations = findConceptViolations(corpus({}));
-    expect(violations.every((v) => v.rule === "stale-allowlist")).toBe(true);
-    expect(violations).toHaveLength(Object.keys(DECLARED_DIVERGENCES).length);
+    // An entry whose collision no longer exists — exactly the state resolving a
+    // divergence leaves behind, and exactly what forced `crm-lead|lead` and
+    // `client|crm-client` to be DELETED rather than left as decoration.
+    const violations = findConceptViolations(corpus({}), {
+      "crm-lead|lead": "resolved, but the entry was left behind",
+    });
+    expect(violations).toEqual([
+      expect.objectContaining({ rule: "stale-allowlist", concept: "crm-lead|lead" }),
+    ]);
   });
 });
 
@@ -142,7 +158,7 @@ describe("concept guard — stays green on legitimate patterns", () => {
         marketing: [role("lead", { scope: "shared" })],
       })
     );
-    expect(violations.filter((v) => v.rule !== "stale-allowlist")).toEqual([]);
+    expect(violations).toEqual([]);
   });
 
   it("allows sibling roles authored in ONE template to share a noun", () => {
@@ -151,7 +167,7 @@ describe("concept guard — stays green on legitimate patterns", () => {
         "blockchain-ecosystem": [role("marketing-agency"), role("paid-ads-agency")],
       })
     );
-    expect(violations.filter((v) => v.rule !== "stale-allowlist")).toEqual([]);
+    expect(violations).toEqual([]);
   });
 
   it("allows an identical concept reused under one semanticSlug", () => {
@@ -161,7 +177,7 @@ describe("concept guard — stays green on legitimate patterns", () => {
         marketing: [role("campaign", { semanticSlug: "marketing.campaign", scope: "shared" })],
       })
     );
-    expect(violations.filter((v) => v.rule !== "stale-allowlist")).toEqual([]);
+    expect(violations).toEqual([]);
   });
 
   it("does not police non-role profiles", () => {
@@ -171,6 +187,6 @@ describe("concept guard — stays green on legitimate patterns", () => {
         b: [{ slug: "meeting-note", displayName: "Meeting Note", properties: [] }],
       })
     );
-    expect(violations.filter((v) => v.rule !== "stale-allowlist")).toEqual([]);
+    expect(violations).toEqual([]);
   });
 });

package/src/concept-guard.ts

@@ -2,9 +2,11 @@
  * 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:
+ * `business-developer.yaml` once 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` (that
+ * fork has since been collapsed back onto the shared slugs). Nothing failed at
+ * the time. 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`.
@@ -46,20 +48,15 @@ export interface ConceptViolation {
  * list cannot rot into a graveyard.
  *
  * Key = the two colliding profile slugs, sorted, joined by "|".
+ *
+ * Currently EMPTY, and that is the healthy state. The two entries this list was
+ * born for — `crm-lead|lead` and `client|crm-client` — were RESOLVED rather
+ * than kept: business-developer.yaml now re-declares the shared `lead`/`client`
+ * roles and carries its business-development fields as workspace-overlay
+ * PROPERTIES. One concept, one slug, workspace-specific fields. Rule 3 below
+ * would have failed CI had the entries been left behind.
  */
-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)",
-};
+export const DECLARED_DIVERGENCES: Record<string, string> = {};
 
 /**
  * A profile's concept identity. `semanticSlug` is the ONE field that can say
@@ -105,7 +102,14 @@ interface ProfileRef {
 }
 
 export function findConceptViolations(
-  templates: Record<string, WorkspaceYaml> = WORKSPACE_TEMPLATES
+  templates: Record<string, WorkspaceYaml> = WORKSPACE_TEMPLATES,
+  /**
+   * The declared-divergence allowlist to enforce against. Defaults to the real
+   * one; injectable so the escape-hatch semantics (rule 1 suppression, rule 3
+   * staleness) stay testable now that the shipped list is empty — previously
+   * those tests could only be written because a live entry happened to exist.
+   */
+  declaredDivergences: Record<string, string> = DECLARED_DIVERGENCES
 ): ConceptViolation[] {
   const violations: ConceptViolation[] = [];
   const all: ProfileRef[] = [];
@@ -143,7 +147,7 @@ export function findConceptViolations(
       if (term !== conceptTerm(effectiveSemanticSlug(b.profile))) continue;
 
       const key = pairKey(a.profile.slug, b.profile.slug);
-      if (key in DECLARED_DIVERGENCES) {
+      if (key in declaredDivergences) {
         usedAllowlistKeys.add(key);
         continue;
       }
@@ -200,7 +204,7 @@ export function findConceptViolations(
   }
 
   // ── RULE 3 — the allowlist may not rot ─────────────────────────────────────
-  for (const key of Object.keys(DECLARED_DIVERGENCES)) {
+  for (const key of Object.keys(declaredDivergences)) {
     if (usedAllowlistKeys.has(key)) continue;
     violations.push({
       rule: "stale-allowlist",

package/src/content-os.yaml

@@ -826,6 +826,10 @@ views:
     description: Your editorial calendar — every post on the day it publishes.
     config:
       dateField: properties.publish-date
+      # The scope lives in `scopeProfileIds` (UUIDs), so `query.profileSlug` is
+      # empty — set focusKind explicitly (a slug the adapter reads from `render`)
+      # so the backlog + empty-state frame for posts ("Unscheduled posts").
+      focusKind: post
   - name: Pillars
     slug: content-pillars
     type: list
@@ -949,6 +953,24 @@ bento:
       viewName: Content Calendar
       pos: { x: 6, y: 5, w: 6, h: 5 }
 
+# Per-profile entity-detail layouts (the "template-defined default" bento,
+# entities.ts:3720). A `series` opens showing its ordered curriculum, a `pillar`
+# showing everything made under it — the two crafted detail surfaces. Each is a
+# generic header + properties PLUS a custom cell (registered in
+# registerWorkspacePersonalizationCells; `widgetType` IS the cellKey). The custom
+# widgets read the entity id from CellContext, the same way entity-header does.
+profileEntityBentoTemplates:
+  series:
+    blocks:
+      - { id: series-eb-header, kind: widget, widgetType: entity-header, pos: { x: 0, y: 0, w: 12, h: 2 } }
+      - { id: series-eb-props, kind: widget, widgetType: entity-properties, pos: { x: 0, y: 2, w: 5, h: 8 } }
+      - { id: series-eb-curriculum, kind: widget, widgetType: series-curriculum, pos: { x: 5, y: 2, w: 7, h: 8 } }
+  pillar:
+    blocks:
+      - { id: pillar-eb-header, kind: widget, widgetType: entity-header, pos: { x: 0, y: 0, w: 12, h: 2 } }
+      - { id: pillar-eb-props, kind: widget, widgetType: entity-properties, pos: { x: 0, y: 2, w: 5, h: 8 } }
+      - { id: pillar-eb-chapter, kind: widget, widgetType: pillar-chapter, pos: { x: 5, y: 2, w: 7, h: 8 } }
+
 # Editorial graph: connect posts to campaign / pillar / sponsor
 entityLinks:
   - sourceProfileSlug: post

package/src/corpus-flow-validity.test.ts

@@ -0,0 +1,130 @@
+/**
+ * CORPUS guard: every automation flow we SHIP must pass `validateFlowDefinition`.
+ *
+ * Why this file exists. `validateTemplate` has called `validateFlowDefinition`
+ * for a while (`validate.ts:588`), and the package had 83 passing tests — yet
+ * `operations.yaml`'s "Pick up handed-off clients" shipped with four write nodes
+ * orphaned outside their loop body, creating entities and relations with EMPTY
+ * ids on every run of every pod that installed it. The rule existed and the
+ * validator was wired; nothing ever ran the two together over the real corpus.
+ * A validator no test points at the shipped data is a validator that only ever
+ * checks fixtures.
+ *
+ * So this reads the SAME YAML the build reads (`readYamlTemplates`, the source
+ * the generator consumes — not `templates.ts`, which is generated output and
+ * could drift) and asserts the shipped flows are clean. It fails loudly with the
+ * per-node messages, because "which node, and why" is the whole value.
+ */
+
+import { test } from "vitest";
+import assert from "node:assert/strict";
+import { existsSync, readdirSync, readFileSync } from "node:fs";
+import { dirname, join } from "node:path";
+import { fileURLToPath } from "node:url";
+import { readYamlTemplates } from "./generate.mjs";
+import { validateFlowDefinition } from "./validate-flow.js";
+
+interface ShippedAutomation {
+  readonly key?: string;
+  readonly name?: string;
+  readonly flow?: unknown;
+}
+
+test("corpus: every shipped automation flow passes validateFlowDefinition", () => {
+  const templates = readYamlTemplates();
+  const failures: string[] = [];
+  let flowsChecked = 0;
+
+  // `readYamlTemplates()` yields `{ file, slug, data }` — the parsed YAML is
+  // under `data`, NOT spread onto the entry.
+  for (const entry of templates) {
+    const { slug, data } = entry as {
+      slug?: string;
+      data?: { automations?: ShippedAutomation[] };
+    };
+    const automations = data?.automations;
+    if (!Array.isArray(automations)) continue;
+
+    for (const automation of automations) {
+      if (!automation?.flow) continue;
+      flowsChecked++;
+      const { valid, errors } = validateFlowDefinition(automation.flow);
+      if (valid) continue;
+      const label = automation.key ?? automation.name ?? "<unnamed>";
+      for (const error of errors) {
+        failures.push(
+          `${slug ?? "<template>"} › ${label} › ` +
+            `${error.nodeId ?? "-"} [${error.code}] ${error.message}`
+        );
+      }
+    }
+  }
+
+  // Guard the guard: if the corpus ever stops yielding flows (a rename in
+  // `readYamlTemplates`, a schema move), this test would "pass" while checking
+  // nothing — the exact failure mode it was written to prevent.
+  assert.ok(
+    flowsChecked > 0,
+    "no automation flows found in the shipped corpus — this guard is checking nothing"
+  );
+
+  assert.deepEqual(
+    failures,
+    [],
+    `shipped automation flows failed validation:\n  ${failures.join("\n  ")}`
+  );
+});
+
+// ── The SECOND corpus: Control-Plane capability seeds ────────────────────────
+// The YAML sweep above was written after a shipped workspace template was found
+// writing entities with empty ids. It did not catch the IDENTICAL defect in
+// `client-comms-report.capability.json`, because that flow lives in a different
+// repo, in JSON, and nothing pointed a validator at it. Same bug, same week,
+// missed for the same reason: a corpus nobody sweeps.
+//
+// These seeds ship automations verbatim into user pods, so they are held to the
+// same contract. Skips when the CP checkout is absent, like the drift guards.
+const HERE = dirname(fileURLToPath(import.meta.url));
+const CP_SEEDS = join(
+  HERE,
+  "../../../../synap-control-plane-api/src/seeds/capability-templates",
+);
+
+test("corpus: every CP capability seed's automation flow passes validateFlowDefinition", (t) => {
+  if (!existsSync(CP_SEEDS)) {
+    t.skip();
+    return;
+  }
+  const failures: string[] = [];
+  let flowsChecked = 0;
+
+  for (const file of readdirSync(CP_SEEDS).filter((f) => f.endsWith(".json"))) {
+    const seed = JSON.parse(readFileSync(join(CP_SEEDS, file), "utf8")) as {
+      automations?: Array<{ key?: string; name?: string; flowDefinition?: unknown }>;
+    };
+    for (const automation of seed.automations ?? []) {
+      if (!automation?.flowDefinition) continue;
+      flowsChecked++;
+      const { valid, errors } = validateFlowDefinition(automation.flowDefinition);
+      if (valid) continue;
+      const label = automation.key ?? automation.name ?? "<unnamed>";
+      for (const error of errors) {
+        failures.push(
+          `${file} › ${label} › ${error.nodeId ?? "-"} [${error.code}] ${error.message}`,
+        );
+      }
+    }
+  }
+
+  // Same self-guard as above: a rename in the seed shape must fail loudly
+  // rather than silently sweep nothing.
+  assert.ok(
+    flowsChecked > 0,
+    "no automation flows found in the CP capability seeds — this guard is checking nothing",
+  );
+  assert.deepEqual(
+    failures,
+    [],
+    `CP capability seed flows failed validation:\n  ${failures.join("\n  ")}`,
+  );
+});

package/src/crm.yaml

@@ -18,13 +18,13 @@ meta:
     - contacts
   isPublic: true
 
-# Canonical hosted surface. Browser resolves auth from appId and launches this
-# URL with non-secret workspace/Pod context; CRM establishes its own session.
-app:
-  kind: url
-  appId: crm
-  url: https://crm.synap.live
-  title: CRM
+# CRM is a website, so Browser opens it in its normal first-party web session.
+# It deliberately does not use the SDK-hosted iframe/auth-broker path.
+layout:
+  primarySurface:
+    kind: url
+    url: https://crm.synap.live
+    title: CRM
 
 # SSOT ordering guarantee — this template REFERENCES foundation's pod-wide
 # shared `client`/`partner`/`lead`/`churned` roles below. The apply engine seeds
@@ -63,6 +63,12 @@ profiles:
     icon: user
     color: amber
     description: A prospect, stakeholder, or contact.
+    # Pod-wide identity: `entityScope: pod` lands the ROWS with `workspace_id =
+    # NULL` (one person record visible from every workspace); the CRM lenses onto
+    # it via a role facet (lead/client). `person` is a pod-wide SYSTEM kind, so
+    # `scope` is omitted (no claim) — the applier reuses the system row and these
+    # CRM props land as this workspace's property OVERLAY.
+    entityScope: pod
     properties:
       - slug: email
         label: Email
@@ -123,7 +129,13 @@ profiles:
     icon: building-2
     color: "#10B981"
     description: An organisation being qualified or sold to.
-    scope: WORKSPACE
+    # Pod-wide identity: `entityScope: pod` lands the ROWS with `workspace_id =
+    # NULL` (one company record visible from every workspace, auto-appearing on the
+    # Ecosystem graph), lensed onto this CRM by its role facet (lead/client).
+    # `company` is a pod-wide SYSTEM kind, so `scope` is omitted (no claim) — the
+    # applier reuses the system row and these CRM props land as an OVERLAY.
+    # (Was `scope: WORKSPACE`, which contradicted the pod-wide model.)
+    entityScope: pod
     properties:
       - slug: contextSummary
         label: Context
@@ -336,6 +348,14 @@ profiles:
           - healthy
           - at_risk
           - critical
+      - slug: driveLink
+        label: Drive folder
+        valueType: string
+        inputType: url
+      - slug: driveFolderId
+        label: Drive folder ID
+        valueType: string
+        inputType: text
 
   # ── Partner (referral source + co-delivery collaborator) ──────────────────
   - slug: partner
@@ -456,6 +476,21 @@ profiles:
         valueType: string
         inputType: textarea
 
+# `linked_to_deal` is the GENERIC counterparty edge and stays the SSOT for "who
+# is on this deal" — the handoff flow's `find-party` node reads exactly it and
+# requires exactly one match, so nothing below may replace it.
+#
+# The two ROLE-QUALIFIED edges are additive: some deals are brokered, and the
+# party on the client side is not the party on the partner side. `client` and
+# `partner` are CO-ATTACHABLE facets on the same person/company (a facet is a
+# hat, not an identity), so the side a party plays ON THIS DEAL cannot be read
+# off its facets — the same company can be the client on one deal and the
+# introducing partner on another. That is a property of the EDGE, which is why
+# it is expressed as two relation types rather than promoted to a kind or
+# inferred from a facet.
+#
+# Both are optional. A direct deal carries only `linked_to_deal` (+ optionally
+# `client_on_deal` naming the same party); nothing requires a partner side.
 entityLinks:
   - sourceProfileSlug: person
     targetProfileSlug: deal
@@ -463,6 +498,22 @@ entityLinks:
   - sourceProfileSlug: company
     targetProfileSlug: deal
     type: linked_to_deal
+  - sourceProfileSlug: person
+    targetProfileSlug: deal
+    type: client_on_deal
+    label: Client side
+  - sourceProfileSlug: company
+    targetProfileSlug: deal
+    type: client_on_deal
+    label: Client side
+  - sourceProfileSlug: person
+    targetProfileSlug: deal
+    type: partner_on_deal
+    label: Partner side
+  - sourceProfileSlug: company
+    targetProfileSlug: deal
+    type: partner_on_deal
+    label: Partner side
 
 onboarding:
   goal: >

package/src/define.primary-surface.test.ts

@@ -59,13 +59,11 @@ describe('workspace primary-surface conversion', () => {
     });
   });
 
-  it('ships the generated CRM template as a hosted primary surface', () => {
+  it('ships the generated CRM template as an ordinary website surface', () => {
     expect(
       toWorkspaceDefinition('crm').definition.layoutConfig?.primarySurface
     ).toEqual({
-      kind: 'app',
-      appId: 'crm',
-      rendererType: 'external',
+      kind: 'url',
       url: 'https://crm.synap.live',
       title: 'CRM',
     });

package/src/define.ts

@@ -272,6 +272,19 @@ export interface WorkspaceDefinitionInput {
   seedEntities: NonNullable<WorkspaceYaml['seedEntities']>;
   suggestedRelations?: WorkspaceYaml['suggestedRelations'];
   displayTemplates?: WorkspaceYaml['displayTemplates'];
+  /**
+   * Domain-level relation TYPE vocabulary — the door find-or-creates a
+   * `relation_defs` row per entry (idempotent by slug within the workspace). NOT
+   * `entityLinks` (those are profile→profile edges and drop the rich metadata).
+   * Carried verbatim; the authored form IS the wire form.
+   */
+  relationDefs?: WorkspaceYaml['relationDefs'];
+  /**
+   * Workspace intelligence commands — the door find-or-creates an
+   * `intelligence_commands` row per entry (idempotent by title). Carried
+   * verbatim; the authored form IS the wire form.
+   */
+  commands?: WorkspaceYaml['commands'];
   layoutConfig: WorkspaceYaml['layout'] | undefined;
   bentoViewName?: string;
   /**
@@ -398,6 +411,11 @@ export function toWorkspaceDefinition(
     seedEntities: tpl.seedEntities ?? [],
     suggestedRelations: tpl.suggestedRelations,
     displayTemplates: tpl.displayTemplates,
+    // Relation-type vocabulary + intelligence commands — carried verbatim so the
+    // one reconcile door can seed the universal defaults (the `base` template)
+    // that three hardcoded seeders used to. Authored form IS the wire form.
+    relationDefs: tpl.relationDefs,
+    commands: tpl.commands,
     layoutConfig: normalizeTemplateLayout(tpl.layout, tpl.app),
     bentoViewName: tpl.bento?.viewName,
     bentoLayout: bento.bentoLayout,
@@ -472,6 +490,8 @@ type WorkspaceDefinitionForwarded =
   | 'seedEntities'
   | 'suggestedRelations'
   | 'displayTemplates'
+  | 'relationDefs'  // → carried verbatim; door find-or-creates relation_defs rows
+  | 'commands'      // → carried verbatim; door find-or-creates intelligence_commands rows
   | 'layout'        // → layoutConfig
   | 'bento'         // → bentoViewName + bentoLayout (widgets) + bentoViewBlocks (views)
   | 'profileEntityBentoTemplates'
@@ -544,6 +564,10 @@ export interface PackageDefinitionOutput {
   suggestedRelations?: WorkspaceYaml['suggestedRelations'];
   displayTemplates?: WorkspaceYaml['displayTemplates'];
   entityLinks?: WorkspaceYaml['entityLinks'];
+  /** Relation-type vocabulary — carried verbatim (authored form IS the wire form). */
+  relationDefs?: WorkspaceYaml['relationDefs'];
+  /** Intelligence commands — carried verbatim (authored form IS the wire form). */
+  commands?: WorkspaceYaml['commands'];
   /** WIDGET half of the authored bento union — mapped by the pod via `widgetType`. */
   bentoLayout?: BentoWidgetBlockWire[];
   /**
@@ -619,6 +643,8 @@ export function toPackageDefinition(
     suggestedRelations: tpl.suggestedRelations,
     displayTemplates: tpl.displayTemplates,
     entityLinks: tpl.entityLinks,
+    relationDefs: tpl.relationDefs,
+    commands: tpl.commands,
     bentoLayout: bento.bentoLayout,
     bentoViewBlocks: bento.bentoViewBlocks,
     bentoViewName: tpl.bento?.viewName,
@@ -650,6 +676,8 @@ type PackageDefinitionForwarded =
   | 'suggestedRelations'
   | 'displayTemplates'
   | 'entityLinks'
+  | 'relationDefs'  // → carried verbatim
+  | 'commands'      // → carried verbatim
   | 'bento'         // → bentoViewName + bentoLayout (widgets) + bentoViewBlocks (views)
   | 'profileEntityBentoTemplates'
   | 'layout'        // → layoutConfig

package/src/ecosystem.yaml

@@ -51,6 +51,14 @@ profiles:
     icon: user
     color: amber
     description: A person in the ecosystem — a founder, operator, or contact.
+    # Pod-wide identity. `person` is a pod-wide SYSTEM kind, so `entityScope: pod`
+    # is the load-bearing axis: the ROWS land with `workspace_id = NULL`, visible
+    # from every workspace (auto-appearing on the Ecosystem graph) and lensed onto
+    # a CRM only where it wears a role facet (lead/client/partner). `scope` is
+    # deliberately OMITTED: it is already a system profile (more pod-wide than
+    # `shared`), so any scope claim only forks the row-level SSOT (see
+    # shared-role-ssot.test.ts (c)); the applier reuses the existing system row.
+    entityScope: pod
     properties:
       - slug: email
         label: Email
@@ -66,6 +74,12 @@ profiles:
     icon: building-2
     color: "#10B981"
     description: A company in the ecosystem — a player you operate around.
+    # Pod-wide identity — same rationale as `person` above: `company` is a pod-wide
+    # SYSTEM kind, so `entityScope: pod` lands the ROWS with `workspace_id = NULL`
+    # (visible from every workspace, auto-appearing on the Ecosystem graph, lensed
+    # onto CRM only by its role facet). `scope` omitted so the applier reuses the
+    # existing system row without forking the row-level SSOT.
+    entityScope: pod
     properties:
       - slug: website
         label: Website

package/src/enterprise-os.yaml

@@ -51,7 +51,7 @@ dependencies:
   - slug: business-developer
     kind: workspace
     relation: require
-    reason: "The lead-first sales motion (crm-lead/crm-client roles, commercial proposals, commission handoff) that the CRM app runs on. Composes onto the CRM workspace above — without it the CRM lens is provisioned with pod-wide lead/client only and the app's pipeline is empty."
+    reason: "The lead-first sales motion (the business-development overlay on the pod-wide lead/client roles, commercial proposals, commission handoff) that the CRM app runs on. Composes onto the CRM workspace above — without it the CRM lens has the bare lead/client roles with no lifecycle or handoff fields and the app's pipeline is empty."
   - slug: content-os
     kind: workspace
     relation: require

package/src/foundation.yaml

@@ -371,6 +371,14 @@ profiles:
           - healthy
           - at_risk
           - critical
+      - slug: driveLink
+        label: Drive folder
+        valueType: string
+        inputType: url
+      - slug: driveFolderId
+        label: Drive folder ID
+        valueType: string
+        inputType: text
 
   # ── Partner (referral source + co-delivery collaborator) ──────────────────
   - slug: partner