@synap-core/workspace-templates 0.8.1 → 0.9.1

package/src/crm.yaml

@@ -462,6 +462,52 @@ playbooks:
       - entity.create
     status: active
 
+  # ── CRM Hygiene — always-on maintenance agent ────────────────────────────
+  # A scheduled agent that keeps the pipeline healthy: (1) enriches stale
+  # contact/company records with missing or outdated fields, and (2) flags deals
+  # that have stalled (no recent activity / stuck in a stage past a healthy
+  # threshold). It runs UNATTENDED on a daily schedule, so EVERY change it makes
+  # is surfaced as a PROPOSAL for the user to review — never auto-applied. That is
+  # enforced by `metadata.governance.forceProposeWrites`, which `executePlaybookRun`
+  # stamps onto the run's focus session; the write gate then routes every agent
+  # write to a proposal (permission-check `deriveSessionForceProposeGovernance`).
+  # No subjectProfile → ONE reasoning session per run that sweeps the whole
+  # pipeline (not one session per entity), which keeps within the 10-proposals/
+  # user/day agent cap.
+  - name: CRM Hygiene
+    description: Always-on maintenance — enriches stale contacts/companies and flags stalled deals. Every change is proposed for your review, never auto-applied.
+    goalTemplate: >-
+      You are the CRM hygiene maintenance agent, running unattended on a daily
+      schedule. Keep the pipeline healthy in two passes, and remember: EVERY
+      change you make is a proposal for the user to review, so be precise and
+      never fabricate.
+
+      Pass 1 — Enrich stale records. Find `person` and `company` records that are
+      missing key fields (e.g. industry, companySize, location, jobTitle, email,
+      website) or whose `lastContactDate` is old. For each, fill in what you can
+      verify from existing pod data and public sources (use the enrichment tools
+      you are granted); leave a field blank rather than guess. Do not touch
+      records that are already complete and current.
+
+      Pass 2 — Flag stalled deals. Find `deal` records with no activity for a
+      while or stuck in the same `dealStage` past a healthy threshold (roughly:
+      contacted/qualified for 14+ days, proposal/negotiation for 30+ days).
+      For each stalled deal, propose a concise `nextStep` to unblock it and note
+      why it looks stalled. Do not advance a deal's stage on its behalf — surface
+      the risk and a recommended action for the human to decide.
+
+      Skip anything already healthy. If nothing needs attention, do nothing.
+    schedule:
+      cron: "0 8 * * *"
+      enabled: true
+    metadata:
+      governance:
+        forceProposeWrites: true
+    executor: is-agent
+    grants:
+      - apify_run_actor
+    status: active
+
 # Apify powers the enrichment playbook (scrape public sources for a lead's
 # firmographics). Composed pod-wide at provisioning via the existing
 # integrations door; the user supplies the Apify API key once on install — a

package/src/foundation.yaml

@@ -86,11 +86,22 @@ profiles:
         valueType: string
         inputType: textarea
 
+  # ── Audience ──────────────────────────────────────────────────────────────
+  # `scope: shared` + `entityScope: pod`: an ideal customer profile is not a
+  # foundation-local fact, it is the pod's answer to "who is this for". Content
+  # OS pillars, journey stages, and marketing segments all point AT these rows,
+  # so both axes have to open: `shared` makes the DEFINITION reachable across a
+  # `require` boundary (a consumer that re-declares the slug gets the grant),
+  # `entityScope: pod` makes the ROWS land with `workspace_id = NULL` so a
+  # sibling workspace's picker can actually see them. Neither alone is enough —
+  # they are independent axes (see TemplateProfile.entityScope).
   - slug: audience
     displayName: Audience
     icon: users
     color: blue
     description: "An ideal customer profile — who we are built for."
+    scope: shared
+    entityScope: pod
     properties:
       - slug: segment
         label: Segment
@@ -109,11 +120,15 @@ profiles:
         valueType: array
         inputType: text
 
+  # Shared + pod-scoped for the same reason as `audience`: a pain is the thing
+  # content is written to dissolve, so a Content OS pillar links to it directly.
   - slug: pain-point
     displayName: Pain Point
     icon: flame
     color: orange
     description: "A specific pain a target audience feels today."
+    scope: shared
+    entityScope: pod
     properties:
       - slug: description
         label: Description
@@ -135,11 +150,21 @@ profiles:
         valueType: string
         inputType: textarea
 
+  # ── Messaging kinds (positioning / narrative / differentiator) ────────────
+  # `scope: shared` because Communication RE-DECLARES all three: they are the
+  # on-message layer every downstream domain reads, and without `shared` the
+  # re-declaration mints a SECOND row and the two drift silently (that fork is
+  # what the comment at communication.yaml:42 used to hide). `positioning` also
+  # takes `entityScope: pod`, because offers and journey stages point at the
+  # positioning ROW from other workspaces; narrative and differentiator stay
+  # workspace-placed — nothing references their rows across a boundary yet.
   - slug: positioning
     displayName: Positioning
     icon: crosshair
     color: cyan
     description: "Market category, who we stand against, and why we win."
+    scope: shared
+    entityScope: pod
     properties:
       - slug: category
         label: Category
@@ -159,6 +184,7 @@ profiles:
     icon: book-open
     color: amber
     description: "The origin -> insight -> mission story arc."
+    scope: shared
     properties:
       - slug: arc
         label: Story arc
@@ -176,6 +202,7 @@ profiles:
     icon: sparkles
     color: green
     description: "One thing only we do, believe, or refuse."
+    scope: shared
     properties:
       - slug: statement
         label: Statement
@@ -201,6 +228,72 @@ profiles:
         valueType: string
         inputType: textarea
 
+  # ═══════════════════════════════════════════════════════════════════════════
+  # OFFER — the thing being sold, pod-wide (SSOT)
+  #
+  # Nothing in the corpus represented a SKU before this. It belongs in
+  # foundation because an offer is IDENTITY, not content: it is the commercial
+  # expression of the positioning, aimed at an audience, and it is read by every
+  # commercial domain (a CRM deal is a deal ON an offer; a marketing campaign
+  # promotes one; a Content OS post teaches toward one). Same mechanics as the
+  # ecosystem roles below — `scope: shared` so the DEFINITION crosses a `require`
+  # boundary once a consumer re-declares the slug, `entityScope: pod` so the ROWS
+  # are visible from every workspace. It is a KIND, not a role: an offer has its
+  # own price, lifecycle, and positioning — it is not a hat some other entity
+  # wears.
+  #
+  # OPTIONAL BY CONSTRUCTION. A user who sells nothing never creates one, and
+  # every consumer must treat absence as "no commercial axis" rather than an
+  # empty required field. Deliberately thin: what it is, whether it is live, how
+  # it is priced, and the two identity rows it hangs off. Money AMOUNTS live on
+  # the deal/contract that references the offer, not here — an offer's price is a
+  # model, not a number.
+  # ═══════════════════════════════════════════════════════════════════════════
+  - slug: offer
+    displayName: Offer
+    icon: package
+    color: fuchsia
+    description: "Something the company sells — a product, service, or program. Optional: a pod that sells nothing simply has none."
+    scope: shared
+    entityScope: pod
+    properties:
+      - slug: offer-status
+        label: Status
+        valueType: string
+        inputType: select
+        enumValues:
+          - draft
+          - active
+          - paused
+          - retired
+        constraints: { defaultValue: draft }
+      - slug: offer-summary
+        label: Summary
+        valueType: string
+        inputType: textarea
+        placeholder: "What it is and what changes for the buyer"
+      - slug: offer-price-model
+        label: Price Model
+        valueType: string
+        inputType: select
+        enumValues:
+          - one-off
+          - subscription
+          - retainer
+          - usage-based
+          - free
+          - other
+      - slug: offer-audience
+        label: Audience
+        valueType: entity_id
+        targetProfileSlug: audience
+        inputType: entity_select
+      - slug: offer-positioning
+        label: Positioning
+        valueType: entity_id
+        targetProfileSlug: positioning
+        inputType: entity_select
+
   # ═══════════════════════════════════════════════════════════════════════════
   # ECOSYSTEM ROLES — pod-wide, cross-workspace role vocabulary (SSOT)
   #

package/src/internal-runbook.yaml

@@ -345,7 +345,7 @@ views:
     scopeProfileSlug: ritual
     description: Recurring meetings and cadences on a calendar.
     config:
-      dateField: ritual-date
+      dateField: properties.ritual-date
       colorField: cadence
 
 # Schema-level links — give the relation picker and graph domain-specific

package/src/project-management.yaml

@@ -493,7 +493,7 @@ views:
     scopeProfileSlugs: [task, sprint, project]
     description: "Unified calendar of task due dates, sprint cycles, and project deadlines"
     config:
-      dateField: task-due-date
+      dateField: properties.task-due-date
 
   - name: OKRs by Quarter
     slug: okr-by-quarter