@synap-core/workspace-templates 0.8.0 → 0.9.0

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@synap-core/workspace-templates",
-  "version": "0.8.0",
+  "version": "0.9.0",
   "type": "module",
   "packageManager": "pnpm@9.15.4",
   "description": "Canonical workspace definitions — YAML source + typed exports for browser, backend, CLI, and marketplace",
@@ -17,13 +17,13 @@
   ],
   "scripts": {
     "type-check": "tsc --noEmit",
-    "build:yaml": "node build.mjs",
+    "build:yaml": "node --experimental-strip-types build.mjs",
     "check:converters": "node scripts/check-converters.mjs",
     "check:concepts": "node scripts/check-concepts.mjs",
-    "build": "node build.mjs && tsup && node scripts/check-converters.mjs && node scripts/check-concepts.mjs",
+    "build": "node --experimental-strip-types build.mjs && tsup && node scripts/check-converters.mjs && node scripts/check-concepts.mjs",
     "provision": "node scripts/provision.mjs",
     "eval": "node scripts/eval-standard.mjs",
-    "prepublishOnly": "node build.mjs && tsup && node scripts/check-converters.mjs && node scripts/check-concepts.mjs"
+    "prepublishOnly": "node --experimental-strip-types build.mjs && tsup && node scripts/check-converters.mjs && node scripts/check-concepts.mjs"
   },
   "dependencies": {
     "zod": "^3.0.0",

package/src/builder.yaml

@@ -1290,7 +1290,7 @@ views:
     scopeProfileSlug: devplane_deployment
     startField: deployedAt
     config:
-      dateField: deployedAt
+      dateField: properties.deployedAt
       colorBy: deployStatus
     description: "Deployment events on a calendar so release cadence is visible at a glance."
   - name: Packages

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

@@ -130,6 +130,8 @@ describe("Business Developer workspace overlay", () => {
       })),
     ).toEqual([
       { sourceProfileSlug: "deal", targetProfileSlug: "crm-commission-entitlement", type: "crm_commission_for_deal" },
+      { sourceProfileSlug: "person", targetProfileSlug: "campaign", type: "member_of" },
+      { sourceProfileSlug: "company", targetProfileSlug: "campaign", type: "member_of" },
     ]);
   });
 

package/src/business-developer.yaml

@@ -280,6 +280,79 @@ profiles:
         valueType: string
         inputType: textarea
 
+  # ── Campaign (reused kind — SSOT is marketing.yaml) ───────────────────────
+  # NOT a new kind and NOT a CRM fork of one: this RE-DECLARES the
+  # marketing-campaign template's `campaign` so the CRM can attach people and
+  # companies to the campaigns that sourced them (`member_of`, below). Keeping
+  # `semanticSlug: marketing.campaign` is what makes it the SAME concept rather
+  # than a third one — the concept guard only errors when two DIFFERENT slugs
+  # claim one semanticSlug. `content-os.yaml` re-declares it exactly this way;
+  # this follows that precedent.
+  #
+  # It must live in THIS file, not in `crm.yaml` or `marketing.yaml`:
+  # `toWorkspaceDefinition` does NOT flatten dependencies, so only
+  # business-developer's OWN profiles/entityLinks reach an existing CRM
+  # workspace through `reconcileFromDefinition`. It is also what lets the
+  # `member_of` links below resolve — an entityLink endpoint must be an own
+  # profile, a SYSTEM_PROFILE, or dependency vocab, and `campaign` is none of
+  # the latter two.
+  #
+  # Scope is OMITTED (= workspace) to MATCH marketing's own declaration: the
+  # promotion to pod-wide is the resolver's job (resolve-profile-for-apply.ts
+  # same-actor workspace→shared branch), not ours to assert. Body kept verbatim
+  # so no property drift.
+  - slug: campaign
+    displayName: Campaign
+    icon: megaphone
+    color: pink
+    description: "A marketing campaign — email, social, event, content, or partnership"
+    semanticSlug: marketing.campaign
+    properties:
+      - slug: campaign-status
+        label: Status
+        valueType: string
+        inputType: select
+        enumValues: [planning, active, paused, completed, cancelled]
+        constraints: { defaultValue: planning }
+      - slug: campaign-channel
+        label: Channel
+        valueType: string
+        inputType: select
+        enumValues:
+          [email, social, event, content, partnership, paid, organic, other]
+      - slug: campaign-goal
+        label: Goal
+        valueType: string
+        inputType: textarea
+      - slug: campaign-target-audience
+        label: Target Audience
+        valueType: string
+        inputType: textarea
+      - slug: campaign-start-date
+        label: Start Date
+        valueType: date
+        inputType: date
+      - slug: campaign-end-date
+        label: End Date
+        valueType: date
+        inputType: date
+      - slug: campaign-budget
+        label: Budget
+        valueType: number
+        inputType: number
+      - slug: campaign-lead-count
+        label: Lead Count
+        valueType: number
+        inputType: number
+      - slug: campaign-conversion-rate
+        label: Conversion Rate (%)
+        valueType: number
+        inputType: number
+      - slug: campaign-notes
+        label: Notes
+        valueType: string
+        inputType: textarea
+
 entityLinks:
   # The existing generic `linked_to_deal` relation remains the deal ↔
   # counterparty connection. This overlay adds only the new auditable
@@ -288,6 +361,17 @@ entityLinks:
     targetProfileSlug: crm-commission-entitlement
     type: crm_commission_for_deal
     label: Commission entitlement
+  # Campaign membership — the sourcing edge between a counterparty and the
+  # campaign it came from. Same predicate for both endpoint kinds, mirroring
+  # CRM's own `linked_to_deal` person/company pair.
+  - sourceProfileSlug: person
+    targetProfileSlug: campaign
+    type: member_of
+    label: Member of
+  - sourceProfileSlug: company
+    targetProfileSlug: campaign
+    type: member_of
+    label: Member of
 
 # These are guided, proposal-first sessions — not background automations. They
 # never create a deal merely because a lead exists, and never convert a lead to

package/src/communication.yaml

@@ -20,11 +20,22 @@ meta:
 # (identity, colors, fonts, assets, voice guide, rules, templates, components).
 # This overlay adds the STRATEGIC MESSAGING layer (positioning, narrative,
 # audience, differentiator) on top, so there is ONE brand vocabulary, not two.
+#
+# `require: foundation` alongside the `compose` is legal: the resolver caps
+# COMPOSE deps at one per template (assertSingleComposeDep) and iterates the rest
+# by relation — it does not cap the dependency list. It is also necessary: the
+# four messaging kinds below are foundation's, not brand-library's, and a
+# `scope: shared` reuse only dedups to the SSOT row if the owner is guaranteed to
+# install first, which is exactly what a `require` buys (deps-first ordering).
 dependencies:
   - slug: brand-library
     kind: workspace
     relation: compose
     reason: "Layers positioning, narrative, and audience onto your Brand Library."
+  - slug: foundation
+    kind: workspace
+    relation: require
+    reason: "Owns the pod-wide positioning, narrative, audience, and differentiator vocabulary this workspace layers onto the brand."
 
 workspace:
   # Composes onto Brand Library: name + subtype MATCH the base (overlay contract),
@@ -40,13 +51,26 @@ workspace:
 
 profiles:
   # ═══════════════════════════════════════════════════════════════════════════
-  # BRAND KINDS — verbatim from brand-library.yaml
+  # MESSAGING KINDS — verbatim from foundation.yaml (NOT brand-library)
+  #
+  # This block long carried a comment claiming these came from brand-library.
+  # They do not: brand-library declares none of them; `positioning`, `narrative`,
+  # `audience`, and `differentiator` are foundation's (foundation.yaml:138, :157,
+  # :89, :174). The wrong attribution had a real cost — with no `require:
+  # foundation` and no `scope: shared`, these four re-declarations minted a
+  # SECOND set of rows and the pod ended up with two positionings that could
+  # disagree. Both halves of the fix are now in place: the `require` above makes
+  # foundation install first (so its body is the SSOT base), and `scope: shared`
+  # makes provisioning dedup to that ONE pod-wide row and grant this workspace
+  # access instead of forking. Bodies stay verbatim so there is no property drift
+  # on the shared row.
   # ═══════════════════════════════════════════════════════════════════════════
   - slug: positioning
     displayName: Positioning
     icon: crosshair
     color: cyan
     description: "Market category, who we stand against, and why we win."
+    scope: shared
     properties:
       - slug: category
         label: Category
@@ -66,6 +90,7 @@ profiles:
     icon: book-open
     color: amber
     description: "The origin -> insight -> mission story arc."
+    scope: shared
     properties:
       - slug: arc
         label: Story arc
@@ -83,6 +108,7 @@ profiles:
     icon: users
     color: blue
     description: "An ideal customer profile — who we are built for."
+    scope: shared
     properties:
       - slug: segment
         label: Segment
@@ -106,6 +132,7 @@ profiles:
     icon: sparkles
     color: green
     description: "One thing only we do, believe, or refuse."
+    scope: shared
     properties:
       - slug: statement
         label: Statement