@synap-core/workspace-templates 0.9.3 → 0.10.0

package/src/business-developer.template.test.ts

@@ -47,17 +47,30 @@ describe("Business Developer workspace overlay", () => {
     expect(template.workspace.visibility).toBeUndefined();
   });
 
-  it("keeps CRM lifecycle facets workspace-local", () => {
-    for (const slug of ["crm-lead", "crm-client"]) {
+  it("extends the SHARED lead/client roles instead of forking them", () => {
+    // The lifecycle roles are the pod-wide foundation SSOT, re-declared so this
+    // workspace receives the grant. Row-level fields must match foundation
+    // VERBATIM (one row, no overlay mechanism — shared-role-ssot rule (c)); the
+    // business-development fields ride along as workspace-overlay PROPERTIES.
+    for (const slug of ["lead", "client"]) {
       const facet = profile(slug);
-      expect(facet.scope).toBe("WORKSPACE");
+      expect(facet.scope).toBe("shared");
       expect(facet.profileKind).toBe("role");
-      expect(facet.applicableKinds).toEqual(["person", "company"]);
+      expect(facet.applicableKinds).toEqual(["company", "person"]);
+      expect(facet.semanticSlug).toBeUndefined();
     }
 
-    expect(template.profiles.some((candidate) => ["lead", "client"].includes(candidate.slug))).toBe(false);
+    // The forked spellings are GONE — reintroducing either is the regression.
+    expect(
+      template.profiles.some((candidate) => ["crm-lead", "crm-client"].includes(candidate.slug)),
+    ).toBe(false);
+
+    // Extras only: foundation's own `leadStage` / `clientStatus` / `notes` are
+    // NOT restated here (restating with a different definition is base drift).
+    expect([...propertySlugs("lead")]).not.toContain("leadStage");
+    expect([...propertySlugs("client")]).not.toContain("clientStatus");
 
-    expect([...propertySlugs("crm-lead")].sort()).toEqual([
+    expect([...propertySlugs("lead")].sort()).toEqual([
     "assignedUserId",
     "convertedAt",
     "disqualificationReason",
@@ -70,6 +83,13 @@ describe("Business Developer workspace overlay", () => {
     "qualificationNotes",
     "source",
     ].sort());
+
+    expect([...propertySlugs("client")].sort()).toEqual([
+      "becameClientAt",
+      "handoffDestination",
+      "handoffNotes",
+      "handoffStatus",
+    ].sort());
   });
 
   it("models proposals and auditable commission separately from leads", () => {
@@ -136,6 +156,10 @@ describe("Business Developer workspace overlay", () => {
   });
 
   it("relies on CRM's single generic counterparty relationship", () => {
+    // `linked_to_deal` stays the ONE generic counterparty edge the handoff
+    // flow's `find-party` node reads. The role-qualified edges beside it are
+    // ADDITIVE (a brokered deal has a client side and a partner side) and must
+    // never displace it — hence the exact-order assertion.
     expect(
       crmTemplate.entityLinks?.map(({ sourceProfileSlug, targetProfileSlug, type }) => ({
         sourceProfileSlug,
@@ -145,6 +169,20 @@ describe("Business Developer workspace overlay", () => {
     ).toEqual([
       { sourceProfileSlug: "person", targetProfileSlug: "deal", type: "linked_to_deal" },
       { sourceProfileSlug: "company", targetProfileSlug: "deal", type: "linked_to_deal" },
+      { sourceProfileSlug: "person", targetProfileSlug: "deal", type: "client_on_deal" },
+      { sourceProfileSlug: "company", targetProfileSlug: "deal", type: "client_on_deal" },
+      { sourceProfileSlug: "person", targetProfileSlug: "deal", type: "partner_on_deal" },
+      { sourceProfileSlug: "company", targetProfileSlug: "deal", type: "partner_on_deal" },
+    ]);
+
+    // The handoff still reads ONLY the generic edge — a brokered deal's partner
+    // side must not be mistaken for the counterparty that becomes the client.
+    const handoff = template.automations?.find((a) => a.name === "Win and hand off");
+    const findParty = (handoff?.flow.nodes as Array<{ id?: string; data?: unknown }>).find(
+      (n) => n.id === "find-party",
+    );
+    expect((findParty?.data as { relationTypes?: string[] }).relationTypes).toEqual([
+      "linked_to_deal",
     ]);
   });
 
@@ -152,7 +190,7 @@ describe("Business Developer workspace overlay", () => {
     expect(
       template.playbooks?.map(({ name, subjectProfile }) => ({ name, profileSlug: subjectProfile?.profileSlug })),
     ).toEqual([
-      { name: "Qualify a CRM lead", profileSlug: "crm-lead" },
+      { name: "Qualify a CRM lead", profileSlug: "lead" },
       { name: "Advance a commercial proposal", profileSlug: "deal" },
     ]);
     expect(template.playbooks?.[0]?.goalTemplate ?? "").toMatch(/Do not create a deal/);
@@ -215,18 +253,49 @@ describe("Business Developer workspace overlay", () => {
       }),
     );
 
+    // The handoff writes the SHARED role slugs — this is what makes the party
+    // a client pod-wide (and therefore visible to the Operations pickup).
+    expect(handoff?.flow.nodes).toContainEqual(
+      expect.objectContaining({
+        id: "attach-client",
+        data: expect.objectContaining({
+          outputType: "facet_attach",
+          config: expect.objectContaining({ facetSlug: "client" }),
+        }),
+      }),
+    );
+    expect(handoff?.flow.nodes).toContainEqual(
+      expect.objectContaining({
+        id: "convert-lead",
+        data: expect.objectContaining({
+          outputType: "facet_update",
+          config: expect.objectContaining({ facetSlug: "lead" }),
+        }),
+      }),
+    );
+    expect(handoff?.flow.nodes).toContainEqual(
+      expect.objectContaining({
+        id: "guard-lead",
+        data: expect.objectContaining({
+          checks: expect.arrayContaining([
+            expect.objectContaining({ arrayIncludes: "lead" }),
+          ]),
+        }),
+      }),
+    );
+
     expect(template.actionPlacements).toEqual([
       expect.objectContaining({
         profileSlug: "person",
         kind: "playbook",
         ref: "Qualify a CRM lead",
-        when: { requiredFacetSlugs: ["crm-lead"] },
+        when: { requiredFacetSlugs: ["lead"] },
       }),
       expect.objectContaining({
         profileSlug: "company",
         kind: "playbook",
         ref: "Qualify a CRM lead",
-        when: { requiredFacetSlugs: ["crm-lead"] },
+        when: { requiredFacetSlugs: ["lead"] },
       }),
       expect.objectContaining({
         profileSlug: "deal",
@@ -256,7 +325,7 @@ describe("Business Developer workspace overlay", () => {
     expect(playbooks).toHaveLength(2);
     expect(playbooks[0]).toMatchObject({
       name: "Qualify a CRM lead",
-      subjectProfile: { profileSlug: "crm-lead" },
+      subjectProfile: { profileSlug: "lead" },
       params: [{ name: "lead", type: "string", description: "CRM lead" }],
     });
     expect(playbooks[1]).toMatchObject({

package/src/business-developer.yaml

@@ -1,13 +1,19 @@
 # Business Developer — a composable, lead-first CRM operating model.
 #
 # This is an ADDITIVE overlay on the CRM workspace, not a second CRM and not a
-# rewrite of shared identity profiles. It deliberately uses workspace-scoped
-# `crm-lead` and `crm-client` role facets instead of the pod-wide `lead` and
-# `client` vocabulary from Foundation. A person or company can therefore be a
-# lead in one CRM workspace without becoming a lead everywhere in the pod.
+# rewrite of shared identity profiles. It REUSES the pod-wide `lead` and
+# `client` roles from Foundation (`scope: shared`, `profileKind: role`) and adds
+# its business-development properties to them as WORKSPACE OVERLAYS — the
+# documented extension mechanism (`getEffectiveProperties`, and rule (b) of
+# `shared-role-ssot.test.ts`). It used to fork them into workspace-scoped
+# `crm-lead` / `crm-client`; that was a vocabulary fork of one real-world
+# concept: the same company was a "lead" under one spelling and not under the
+# other, so pod-wide surfaces, the Operations handoff, and the CRM app
+# disagreed about who was a client. One concept, one slug, workspace-specific
+# FIELDS.
 #
 # Lifecycle:
-#   person / company + crm-lead → optional deal(s) → won deal → crm-client
+#   person / company + lead → optional deal(s) → won deal → client
 #
 # Deals are commercial proposals attached through CRM's existing
 # `linked_to_deal` relation. The CRM requires one counterparty before a deal
@@ -41,23 +47,33 @@ workspace:
     - crm.business-development
 
 profiles:
-  # Workspace-local operational status. This is intentionally separate from
-  # Foundation's shared `lead` role: lead ownership, next actions, and CRM
-  # lifecycle status must be visible to this CRM workspace's members only.
-  - slug: crm-lead
-    displayName: CRM Lead
-    icon: user-round-search
-    color: amber
-    description: A person or company actively being qualified or contacted by this CRM workspace.
-    scope: WORKSPACE
+  # ── Lead (reused shared role — SSOT is foundation.yaml) ───────────────────
+  # NOT a workspace-local copy: this RE-DECLARES foundation's pod-wide `lead`
+  # role so the CRM workspace receives the grant (shared profiles are
+  # grant-gated — a workspace only sees a shared role if it references the
+  # slug), and ADDS the business-development properties below.
+  #
+  # Row-level fields (displayName/icon/color/description/applicableKinds) are
+  # restated VERBATIM from foundation, exactly as crm.yaml does: there is ONE
+  # pod-wide row and no overlay mechanism for row-level fields, so a divergent
+  # value here would be silently false on every pod depending on apply order
+  # (shared-role-ssot rule (c)).
+  #
+  # The properties are EXTRAS ONLY. Foundation's own `leadStage` / `notes` are
+  # deliberately NOT restated — omitting is "no claim", and restating with a
+  # different definition is the base-drift rule (b) forbids. Extras land as
+  # WORKSPACE OVERLAYS via getEffectiveProperties, so this workspace's members
+  # see lifecycle/ownership fields that other workspaces don't.
+  - slug: lead
+    displayName: Lead
+    icon: user-plus
+    color: yellow
+    description: An early-pipeline prospect — not yet a client, being qualified or nurtured.
+    scope: shared
     profileKind: role
-    # Explicit concept identity: this is the WORKSPACE tier of the `lead`
-    # concept, not a second, unrelated one. Declaring it makes the two-tier
-    # design machine-readable (both tiers are reachable via getBySemanticSlug)
-    # and is what the cross-template concept guard requires alongside its
-    # DECLARED_DIVERGENCES entry — see src/concept-guard.ts.
-    semanticSlug: crm.lead
-    applicableKinds: [person, company]
+    applicableKinds:
+      - company
+      - person
     properties:
       - slug: lifecycleStage
         label: Lifecycle stage
@@ -129,19 +145,22 @@ profiles:
         valueType: date
         inputType: date
 
-  # The same counterparty receives this facet when one of its commercial
-  # proposals is won. It intentionally carries only handoff context; client
-  # delivery, renewal, and service health remain outside this pre-sale addon.
-  - slug: crm-client
-    displayName: CRM Client
-    icon: badge-check
+  # ── Client (reused shared role — SSOT is foundation.yaml) ─────────────────
+  # Same pattern as `lead` above: foundation's pod-wide `client` role, restated
+  # verbatim at row level, EXTENDED with the handoff context this pre-sale
+  # addon owns. Client delivery, renewal, and service health belong to
+  # operations.yaml, which reads the SAME `client` role pod-wide — that shared
+  # slug is what makes the CRM → Operations handoff possible at all.
+  - slug: client
+    displayName: Client
+    icon: briefcase
     color: emerald
-    description: A CRM lead converted by a won commercial proposal and ready for handoff.
-    scope: WORKSPACE
+    description: An active commercial relationship — created when a deal is won.
+    scope: shared
     profileKind: role
-    # Workspace tier of the `client` concept — see the note on `crm-lead` above.
-    semanticSlug: crm.client
-    applicableKinds: [person, company]
+    applicableKinds:
+      - company
+      - person
     properties:
       - slug: becameClientAt
         label: Became client at
@@ -404,7 +423,7 @@ playbooks:
       deal simply because the lead is qualified. If a commercial proposal is
       warranted, explain why and ask for or propose that next step separately.
     subjectProfile:
-      profileSlug: crm-lead
+      profileSlug: lead
     params:
       - { name: lead, type: entity, label: CRM lead, required: true }
     executor: is-agent
@@ -477,8 +496,11 @@ automations:
               - path: steps.read-deal.output.entity.properties.handoffStatus
                 notEquals: handed_off
                 message: This proposal has already been handed off.
+              # minLength, NOT exists: `exists` is a null check, so an empty
+              # string satisfies it and the handoff would proceed with no
+              # sourcer actually set. The intent here is "has a value".
               - path: steps.read-deal.output.entity.properties.sourcedByUserId
-                exists: true
+                minLength: 1
                 message: Set the business developer who sourced this proposal before handing it off.
               - path: steps.read-deal.output.entity.properties.synapFeeAmount
                 numberGte: 0
@@ -518,7 +540,7 @@ automations:
             label: Confirm qualified CRM lead
             checks:
               - path: steps.read-party.output.entity.facetSlugs
-                arrayIncludes: crm-lead
+                arrayIncludes: lead
                 message: The commercial counterparty must still be a CRM lead before it becomes a CRM client.
 
         # Source-deal claim is the durable idempotency boundary for the whole
@@ -699,7 +721,7 @@ automations:
             outputType: facet_attach
             config:
               entityId: "{{steps.read-party.output.entity.id}}"
-              facetSlug: crm-client
+              facetSlug: client
               properties:
                 becameClientAt: "{{steps.handoff-time.output.result}}"
                 handoffStatus: handed_off
@@ -712,7 +734,7 @@ automations:
             outputType: facet_update
             config:
               entityId: "{{steps.read-party.output.entity.id}}"
-              facetSlug: crm-lead
+              facetSlug: lead
               properties:
                 lifecycleStage: converted
                 convertedAt: "{{steps.handoff-time.output.result}}"
@@ -809,14 +831,14 @@ actionPlacements:
     kind: playbook
     ref: Qualify a CRM lead
     label: Qualify lead
-    when: { requiredFacetSlugs: [crm-lead] }
+    when: { requiredFacetSlugs: [lead] }
 
   - profileSlug: company
     surface: entity-detail
     kind: playbook
     ref: Qualify a CRM lead
     label: Qualify lead
-    when: { requiredFacetSlugs: [crm-lead] }
+    when: { requiredFacetSlugs: [lead] }
 
   - profileSlug: deal
     surface: entity-detail

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