@synap-core/workspace-templates 0.4.0 → 0.6.0

package/src/marketing.yaml

@@ -10,6 +10,21 @@ meta:
   tags: [marketing, crm, outreach, leads, campaigns]
   isPublic: true
 
+# SSOT ordering guarantee — this template REFERENCES foundation's pod-wide
+# shared `lead` role. The apply engine seeds a shared profile's pod-wide BASE
+# property body from whichever template creates it FIRST, and adds a REUSING
+# template's extra props as workspace OVERLAYS. Without this dependency,
+# marketing-first would make the pod-wide `lead` base marketing's 10-prop body
+# for EVERY workspace. Requiring foundation makes the resolver install it first
+# (deps-first), so the base is always foundation's SSOT body (leadStage, notes)
+# and marketing's extras stay per-workspace overlays. `require`, not `compose`:
+# foundation is a real workspace, not an overlay.
+dependencies:
+  - slug: foundation
+    kind: workspace
+    relation: require
+    reason: "Provides the pod-wide lead role vocabulary (leadStage) this workspace reuses."
+
 workspace:
   name: Marketing Campaign OS
   description: "Track leads, manage campaigns, and let AI help run your outreach. Contacts, pipeline, tasks, and AI briefings — all connected."
@@ -20,6 +35,8 @@ workspace:
     - marketing.contacts
     - marketing.leads
   sourceRoles:
+    brand: consumer
+    content: consumer
     marketing: provider
 
 profiles:
@@ -80,6 +97,9 @@ profiles:
     color: blue
     description: "A person in your marketing contact list."
     semanticSlug: marketing.contact
+    profileKind: role
+    applicableKinds:
+      - person
     properties:
       - slug: contact-email
         label: Email
@@ -117,19 +137,26 @@ profiles:
         valueType: string
         inputType: text
 
+  # `scope: shared` dedups to the ONE pod-wide `lead` profile seeded by
+  # foundation.yaml (SSOT for leadStage). Ordering is guaranteed by the
+  # `require: foundation` dependency above — foundation always installs first,
+  # so the pod-wide BASE body is always foundation's and the props below are
+  # always workspace OVERLAYS on top of it. That is the legitimate extension
+  # mechanism: EXTRA props are fine. What is NOT fine is REDECLARING a prop
+  # foundation already owns (e.g. `leadStage`) with a divergent enum/default —
+  # that is base drift, and the SSOT tripwire fails on it.
+  # (Standards reference inherited base props like `leadStage` directly.)
   - slug: lead
     displayName: Lead
     icon: user-plus
     color: green
     description: "A potential customer or partner contact in your pipeline"
     semanticSlug: marketing.lead
+    scope: shared
+    profileKind: role
+    applicableKinds:
+      - person
     properties:
-      - slug: lead-stage
-        label: Stage
-        valueType: string
-        inputType: select
-        enumValues: [new, contacted, interested, qualified, demo, proposal, converted, lost]
-        constraints: { defaultValue: new }
       - slug: lead-source
         label: Source
         valueType: string
@@ -164,7 +191,7 @@ profiles:
         label: Last Contacted
         valueType: date
         inputType: date
-      - slug: lead-notes
+      - slug: notes
         label: Notes
         valueType: string
         inputType: textarea
@@ -190,7 +217,7 @@ views:
     slug: lead-pipeline
     type: kanban
     scopeProfileSlug: lead
-    groupBy: lead-stage
+    groupBy: leadStage
     description: "Lead pipeline kanban by stage."
 
 onboarding:
@@ -249,7 +276,7 @@ onboarding:
     - profileSlug: lead
       what: A few representative leads already in motion, placed at their true pipeline stage.
       cardinality: several
-      keyFields: [lead-stage, lead-source, lead-company]
+      keyFields: [leadStage, lead-source, lead-company]
     - profileSlug: contact
       what: Key marketing contacts — the people already on the list and how they got there.
       cardinality: few