@synap-core/workspace-templates 0.12.0 → 0.24.0

package/src/crm.yaml

@@ -1,8 +1,35 @@
 # CRM workspace template
-# The CRM owns pre-sale work only. A won deal is handed to the operating
-# workspace; this template deliberately does not provision client delivery,
-# campaigns, tasks, documents, automations, or sales-specific playbooks. A
-# use-case overlay (for example `business-developer`) may add those workflows.
+# The CRM owns pre-sale work only: who is worth pursuing (the `lead` role's
+# leadStage, "Qualify a lead"), the sale (the deal's commercialStage, "Win a
+# deal") and the campaigns people come from. A won deal is handed to the
+# operating workspace; client delivery belongs to Operations.
+#
+# Business Developer folded into this file (founder decision 2026-10-12): its
+# lead/client fields, the campaign kind and "Qualify a lead" live here now; its
+# "Advance a commercial proposal" was dropped for "Win a deal"; its Synap-fee
+# and commission model moved to the private arch-sales, retired the same day with
+# The Arch (retired.yaml; source kept in retired-sources/).
+#
+# Outreach & Comms folded into this file (founder decision 2026-10-23): for a
+# founder-led company outreach is part of the commercial job, one space per
+# domain. Its `outreach-touch` kind (same slug, same lifecycle keys), its
+# relations `sent_to` / `part_of`, its views, its campaign process and its
+# LinkedIn ingest live here now. Its `outreach-campaign` kind was a twin of
+# this file's `campaign` (whose `campaign-type` already has `outreach`): an
+# outreach campaign is a `campaign` with campaign-type outreach, and its
+# `targets` edge to people and companies was a twin of `member_of`. The agent
+# drafts, a person sends; a reply never opens a deal (a deal exists only once a
+# meeting is booked). `outreach-comms` is retired (retired.yaml).
+#
+# One send door (founder decisions d1, d5, d6 of 2026-11-02, session d00cd2ac):
+# the conversation with a person is their CHANNEL. A drafted message is a
+# proposed message in it, filed through the pod's `messaging.send` ({to:
+# <person or company entity id>, text}): a `messaging.external.send` proposal
+# the person approves, and only then is it sent. No process creates an
+# `outreach-touch` any more (d5 retires those drafts; the kind stays until the
+# existing ones are moved into their channels), and none calls a tool's own
+# send verb. The LinkedIn ingest automation is gone: the pod's messaging
+# webhook and its history import record LinkedIn messages in the channels.
 
 meta:
   slug: crm
@@ -17,6 +44,37 @@ meta:
     - pipeline
     - contacts
   isPublic: true
+  # Onboarding start (meta.start): the "sales" card. Its views are the deal
+  # views below (deal-pipeline, deals-table, deals-list).
+  start:
+    order: 3
+    label: Sales
+    promise: Leads and deals, each with a dated next step.
+    suggestFor: [small-business, founder]
+    profile: deal
+    views: [deal-pipeline, deals-table, deals-list]
+    example:
+      - { title: "Acme renewal", values: { commercialStage: negotiating, value: 12000, nextStep: "Send revised quote Thu" } }
+      - { title: "Nordlys brand audit", values: { commercialStage: proposed, value: 6000, nextStep: "Follow up on proposal Mon" } }
+      - { title: "Atelier 9 workshop", values: { commercialStage: draft, value: 2800, nextStep: "Discovery call Wed" } }
+      - { title: "Maison Dupont redesign", values: { commercialStage: won, value: 18000, nextStep: "Kick-off next week" } }
+      - { title: "Lumen Studio retainer", values: { commercialStage: lost, value: 4500 } }
+    firstSession:
+      title: Your live deals
+      goal: "Add the 3 to 5 deals you are moving now, each with its company, a real person and a dated next step."
+    starters:
+      - "We sell services to mid-size agencies"
+      - "I am a freelancer with a few warm leads"
+      - "We sell a SaaS subscription to small businesses"
+  # What this space PRODUCES (homes): the purpose word, then its kinds/roles.
+  intent:
+    label: Sales
+    produces:
+      - profile: lead
+      - profile: client
+      - profile: deal
+      - profile: campaign
+      - profile: outreach-touch
 
 # 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.
@@ -27,7 +85,8 @@ layout:
     title: CRM
 
 # SSOT ordering guarantee — this template REFERENCES foundation's pod-wide
-# shared `client`/`partner`/`lead`/`churned` roles below. The apply engine seeds
+# shared `client`/`partner`/`lead` roles below (reference form: no
+# body restated). 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. Requiring foundation makes the resolver install it first
@@ -38,7 +97,7 @@ dependencies:
   - slug: foundation
     kind: workspace
     relation: require
-    reason: "Provides the pod-wide client/partner/lead/churned role vocabulary this workspace reuses."
+    reason: "Provides the pod-wide client/partner/lead role vocabulary this workspace reuses."
 
 workspace:
   name: CRM
@@ -53,9 +112,12 @@ workspace:
     - crm.pipeline
     - crm.contacts
     - crm.deals
+    - outreach.campaigns
+    - outreach.touches
   sourceRoles:
     social: consumer
     crm: provider
+    outreach: provider
 
 profiles:
   - slug: person
@@ -90,8 +152,11 @@ profiles:
         label: LinkedIn URL
         valueType: string
         inputType: url
-      - slug: source
-        label: Source
+      # Lead attribution — WHERE the lead came from commercially. Never
+      # `source`: that pod-wide field held transport and lead values in one
+      # enum (decision 2026-09-14); HOW a record arrived is `provenance`.
+      - slug: leadSource
+        label: Lead source
         valueType: string
         inputType: select
         enumValues:
@@ -167,8 +232,8 @@ profiles:
         label: Location
         valueType: string
         inputType: text
-      - slug: source
-        label: Source
+      - slug: leadSource
+        label: Lead source
         valueType: string
         inputType: select
         enumValues:
@@ -207,22 +272,27 @@ profiles:
     color: violet
     description: A pre-sale opportunity tracked until won, lost, or handed off.
     scope: WORKSPACE
+    # The ONE lifecycle (work model L1): every option's category. A deal is
+    # opened only when a person records a booked meeting (CRM build plan A2/A4,
+    # 2026-10-22), so its first stage reads "Meeting booked"; `proposed` reads
+    # "Proposal sent". A stage still open after 14 days is stuck (the stalled
+    # mark, and CRM Hygiene's threshold below).
+    lifecycle:
+      property: commercialStage
+      options:
+        - { key: draft, label: Meeting booked, category: open, stuckAfterDays: 14 }
+        - { key: proposed, label: Proposal sent, category: active, stuckAfterDays: 14 }
+        - { key: negotiating, category: active, stuckAfterDays: 14 }
+        - { key: won, category: done }
+        - { key: lost, category: lost, humanOnly: true }
     properties:
-      - slug: dealStage
-        label: Stage
-        valueType: string
-        inputType: select
-        enumValues:
-          - lead
-          - contacted
-          - qualifying
-          - proposal
-          - negotiating
-          - won
-          - lost
-          - inactive
+      # The deal's ONE lifecycle (work model W15, 2026-10-11): a deal is the
+      # sale only. Qualification (who is worth pursuing) is the `lead` role's
+      # `leadStage`. The legacy `dealStage` (lead/contacted/qualifying/…) and
+      # the system `stage` are retired; live rows fold via conversions
+      # `crm.deal-stage.commercial-fold`.
       - slug: commercialStage
-        label: Commercial stage
+        label: Stage
         valueType: string
         inputType: select
         enumValues:
@@ -255,6 +325,14 @@ profiles:
         label: Expected close date
         valueType: date
         inputType: date
+      # The booked meeting that opened the deal (CRM build plan A3). A date on
+      # the deal, not a link to a calendar event: the person records it in one
+      # click whether or not a calendar is connected, and the pipeline reads it
+      # without a join. A synced calendar event can still be linked to the deal.
+      - slug: meetingDate
+        label: Meeting date
+        valueType: date
+        inputType: date
       - slug: nextStep
         label: Next step
         valueType: string
@@ -271,208 +349,339 @@ profiles:
           - pending
           - ready
           - handed_off
+      - slug: wonAt
+        label: Won at
+        valueType: date
+        inputType: date
+      - slug: lostReason
+        label: Lost reason
+        valueType: string
+        inputType: textarea
 
   # ═══════════════════════════════════════════════════════════════════════════
-  # ECOSYSTEM ROLES — shared pod-wide role vocabulary (SSOT is foundation.yaml).
+  # ECOSYSTEM ROLES — REFERENCES to foundation's pod-wide shared roles.
   #
-  # These `scope: shared`, `profileKind: role` profiles are ONE pod-wide row each,
-  # defined ONCE in foundation.yaml. The CRM re-declares them so the apply engine
-  # (create-workspace-from-definition.ts) resolves each slug to the existing
-  # pod-wide profile and GRANTS this workspace access to it (SHARED profiles are
-  # grant-gated — a workspace only sees a shared role if it references the slug).
-  # Without these references the CRM workspace could attach `client`/`lead`/…
-  # facets that entities.list could never surface, so every row fell through to
-  # the "Idle" relationship status (crmData.ts getRelationshipStatus).
-  #
-  # Bodies match foundation VERBATIM (row-level icon/color/displayName/description
-  # + every property definition): two templates declaring the same shared slug
-  # with DIVERGENT bodies fight over one pod-wide row (base drift). The
-  # template-shared-role-ssot tripwire enforces this — do NOT diverge here.
+  # One role per name, pod-wide (concepts.md). The body lives ONCE in
+  # foundation.yaml. A reference is `slug + displayName + scope: shared +
+  # profileKind: role` (+ only the properties THIS workspace adds, which land as
+  # workspace overlays): the apply engine resolves the slug to the one pod-wide
+  # row and GRANTS this workspace access (shared profiles are grant-gated — the
+  # CRM only sees `client`/`lead`/… facets because it references them). Row
+  # fields (icon, colour, description, applicableKinds) are NOT restated: the
+  # reused row is never mutated, so restating them only invited drift.
+  # `displayName` stays because the tRPC install door requires it, and must
+  # equal foundation's (shared-role-ssot rule c). validate.ts rule
+  # `shared-role-reference-*` requires foundation in the dependency chain.
   # ═══════════════════════════════════════════════════════════════════════════
-
-  # ── Client (active commercial relationship) ───────────────────────────────
+  # The handoff context a won deal writes ("Win a deal" attaches the role with
+  # handoffStatus handed_off) and Operations' "Pick up handed-off clients"
+  # reads. Moved verbatim from business-developer (2026-10-12).
   - slug: client
     displayName: Client
-    icon: briefcase
-    color: emerald
-    description: An active commercial relationship — created when a deal is won.
     scope: shared
     profileKind: role
-    applicableKinds:
-      - company
-      - person
     properties:
-      - slug: clientStatus
-        label: Status
+      - slug: becameClientAt
+        label: Became client at
+        valueType: date
+        inputType: date
+      - slug: handoffStatus
+        label: Handoff status
         valueType: string
         inputType: select
-        enumValues:
-          - prospect
-          - active
-          - paused
-          - former
-          - churned
-      - slug: accountManager
-        label: Account Manager
+        enumValues: [pending, ready, handed_off]
+        constraints: { defaultValue: pending }
+      - slug: handoffDestination
+        label: Handoff destination
         valueType: string
         inputType: text
-      - slug: engagementStartDate
-        label: Engagement Start
-        valueType: date
-        inputType: date
-      - slug: satisfactionScore
-        label: Satisfaction
-        valueType: number
-        inputType: number
-      - slug: lifetimeValue
-        label: Lifetime Value
-        valueType: number
-        inputType: number
-      - slug: notes
-        label: Notes
+      - slug: handoffNotes
+        label: Handoff notes
         valueType: string
         inputType: textarea
-      - slug: contractValue
-        label: Contract Value
+  - slug: partner
+    displayName: Partner
+    scope: shared
+    profileKind: role
+    properties: []
+  # The people you talk to at a company: the pod's SYSTEM `contact` role (no
+  # scope claim, like `person`). Declaring it grants it to this space, so the
+  # space and its apps see who wears it (founder decision 2, 2026-10-26;
+  # synap-backend resolveProfileForApply, PR #237).
+  - slug: contact
+    displayName: Contact
+    profileKind: role
+  # Qualification fields "Qualify a lead" fills. Extras only: foundation's own
+  # `leadStage` (the lead's ONE lifecycle) and `notes` are not restated.
+  # Moved verbatim from business-developer (2026-10-12).
+  - slug: lead
+    displayName: Lead
+    scope: shared
+    profileKind: role
+    properties:
+      - slug: assignedUserId
+        label: Assigned user ID
+        valueType: string
+        inputType: text
+        placeholder: Workspace member ID
+      - slug: leadSource
+        label: Lead source
+        valueType: string
+        inputType: select
+        # warm-network: someone the owner knows; research: found by "Build a
+        # prospect list from our foundation"; import: a contacts file;
+        # inbound-form: the website's form (CRM build plan A1).
+        enumValues:
+          [
+            cold-outreach,
+            linkedin,
+            twitter,
+            landing-page,
+            inbound-call,
+            inbound-form,
+            referral,
+            warm-network,
+            event,
+            research,
+            import,
+            other,
+          ]
+      # Always 1–5, signal first (founder decision 2026-10-27): set by "Score a
+      # list", whose goal is the ONE home of the rubric. No min/max constraint:
+      # pods may still hold scores on the older scale until they are rescored.
+      - slug: icpScore
+        label: ICP score (1–5)
         valueType: number
         inputType: number
-      - slug: renewalDate
-        label: Renewal Date
-        valueType: date
-        inputType: date
-      - slug: healthScore
-        label: Health
+        placeholder: 1 to 5
+      # The public sign that this lead needs the offer now (founder decision
+      # 2026-10-27; the rubric's "signal" part, "Score a list"): hiring = a job
+      # post or mission offer for automation, AI agents or no-code; asking = a
+      # public post or freelance request asking for that help; tooling = uses
+      # those tools publicly, no ask; none = nothing found.
+      - slug: buyingSignal
+        label: Buying signal
         valueType: string
         inputType: select
-        enumValues:
-          - healthy
-          - at_risk
-          - critical
-      - slug: driveLink
-        label: Drive folder
+        enumValues: [hiring, asking, tooling, none]
+      # The public URL proving the buying signal. Public sources only.
+      - slug: buyingSignalSource
+        label: Buying signal source
         valueType: string
         inputType: url
-      - slug: driveFolderId
-        label: Drive folder ID
-        valueType: string
+      # When the ICP score was last set; "Score a list" rescores a lead only
+      # when this is older than its rescoreAfterDays.
+      - slug: scoredAt
+        label: Scored at
+        valueType: date
+        inputType: date
+      - slug: outreachChannels
+        label: Outreach channels
+        valueType: array
         inputType: text
+        placeholder: linkedin, email, phone
+      - slug: lastContactedAt
+        label: Last contacted at
+        valueType: date
+        inputType: date
+      - slug: nextActionAt
+        label: Next action at
+        valueType: date
+        inputType: date
+      - slug: nextAction
+        label: Next action
+        valueType: string
+        inputType: textarea
+      - slug: qualificationNotes
+        label: Qualification notes
+        valueType: string
+        inputType: textarea
+      - slug: disqualificationReason
+        label: Disqualification reason
+        valueType: string
+        inputType: textarea
+      - slug: convertedAt
+        label: Converted at
+        valueType: date
+        inputType: date
+      # Written by "Prepare a pre-sale estimate"'s SENT step (CRM build plan A7).
+      - slug: estimateSentAt
+        label: Estimate sent at
+        valueType: date
+        inputType: date
+      - slug: estimateSentChannel
+        label: Estimate sent on
+        valueType: string
+        inputType: select
+        enumValues: [email, linkedin, phone, in-person, other]
 
-  # ── Partner (referral source + co-delivery collaborator) ──────────────────
-  - slug: partner
-    displayName: Partner
-    icon: handshake
-    color: teal
-    description: A partner relationship — both a referral source and a co-delivery collaborator, distinguished by partner type.
+  # ── Audience (shared kind — SSOT is foundation.yaml) ─────────────────────
+  # A lead's SEGMENT is the audience it was found for: a `targets` edge from
+  # the person or company to the audience (CRM build plan A8, below). Declared
+  # here as a reference so the CRM space is granted the pod-wide kind (shared
+  # profiles are grant-gated) and the edge and "Build a prospect list from our
+  # foundation" (whose subject is an audience) resolve. No body restated.
+  - slug: audience
+    displayName: Audience
     scope: shared
-    profileKind: role
-    applicableKinds:
-      - company
-      - person
+    entityScope: pod
+    properties: []
+
+  # ── Campaign (reused kind — SSOT is marketing.yaml) ───────────────────────
+  # The SAME concept as marketing's campaign (`semanticSlug: marketing.campaign`),
+  # re-declared so the CRM can attach people and companies to the campaign that
+  # sourced them (`member_of`, below) and the CRM app's campaign pages have a
+  # kind to read. Body kept verbatim across marketing / content-os / here.
+  # Moved from business-developer (2026-10-12).
+  - slug: campaign
+    displayName: Campaign
+    icon: megaphone
+    color: pink
+    description: "A marketing campaign — email, social, event, content, or partnership"
+    semanticSlug: marketing.campaign
+    # The ONE lifecycle (work model L1): every option's category.
+    lifecycle:
+      property: campaign-status
+      options:
+        - { key: planning, category: open }
+        - { key: active, category: active }
+        - { key: paused, category: paused, humanOnly: true }
+        - { key: completed, category: done }
+        - { key: cancelled, category: lost, humanOnly: true }
     properties:
-      - slug: partnerStatus
+      - slug: campaign-status
         label: Status
         valueType: string
         inputType: select
-        enumValues:
-          - prospect
-          - active
-          - paused
-          - churned
-      - slug: partnerType
-        label: Partner Type
+        enumValues: [planning, active, paused, completed, cancelled]
+        constraints: { defaultValue: planning }
+      - slug: campaign-channel
+        label: Channel
         valueType: string
         inputType: select
         enumValues:
-          - referral
-          - co-delivery
-          - both
-      - slug: accountManager
-        label: Account Manager
+          [email, social, event, content, partnership, paid, organic, other]
+      - slug: campaign-goal
+        label: Goal
         valueType: string
-        inputType: text
-      - slug: engagementStartDate
-        label: Engagement Start
+        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: satisfactionScore
-        label: Satisfaction
+      - slug: campaign-budget
+        label: Budget
         valueType: number
         inputType: number
-      - slug: lifetimeValue
-        label: Lifetime Value
+      - slug: campaign-lead-count
+        label: Lead Count
         valueType: number
         inputType: number
-      - slug: notes
+      - slug: campaign-conversion-rate
+        label: Conversion Rate (%)
+        valueType: number
+        inputType: number
+      - slug: campaign-notes
         label: Notes
         valueType: string
         inputType: textarea
-      - slug: contractValue
-        label: Contract Value
-        valueType: number
-        inputType: number
-      - slug: renewalDate
-        label: Renewal Date
-        valueType: date
-        inputType: date
-      - slug: healthScore
-        label: Health
+      # `campaign-type` is the campaign's NATURE/phase, orthogonal to
+      # `campaign-channel` (the delivery medium). scoping/outreach/live have no
+      # channel equivalent, so folding them into `campaign-channel` would lose
+      # them — they get their own def. Kept verbatim across the three campaign
+      # declarations (marketing / content-os / here) so there is no drift.
+      - slug: campaign-type
+        label: Type
         valueType: string
         inputType: select
         enumValues:
-          - healthy
-          - at_risk
-          - critical
-
-  # ── Lead (early-pipeline prospect, pre-client) ─────────────────────────────
-  - 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
-    applicableKinds:
-      - company
-      - person
-    properties:
-      - slug: leadStage
-        label: Stage
+          [scoping, outreach, live, partnership, event, other]
+        constraints: { defaultValue: outreach }
+      # `campaign-color` backs the per-campaign colour the CRM surfaces render.
+      # Stored as a palette NAME (see apps/crm/lib/campaignColors.ts), not a hex.
+      - slug: campaign-color
+        label: Color
         valueType: string
         inputType: select
-        enumValues:
-          - prospect
-          - qualified
-          - nurturing
-          - converted
-          - lost
-        constraints: { defaultValue: prospect }
-      - slug: notes
-        label: Notes
+        enumValues: [indigo, violet, amber, cyan, pink, teal]
+      # ── CRM-only extras (workspace overlay; NOT part of the verbatim body) ──
+      # An outreach campaign is the ANGLE a lead is approached with (CRM build
+      # plan A8): a `campaign` with campaign-type outreach. Folded from Outreach
+      # & Comms' `outreach-campaign` (2026-10-23), whose other fields already had
+      # a home here: targetSegment = campaign-target-audience (plus the lead's
+      # `targets` edge to an audience), startDate = campaign-start-date, notes =
+      # campaign-notes, status draft/active/paused/completed = campaign-status
+      # planning/active/paused/completed. These two had none; the drafts of
+      # "Personalized Outreach" and "Follow up on leads in outreach" follow them.
+      - slug: campaign-value-prop
+        label: Value proposition
         valueType: string
         inputType: textarea
+      - slug: campaign-call-to-action
+        label: Call to action
+        valueType: string
+        inputType: text
+        placeholder: e.g. Book a 20-minute call, or ask for the free estimate
 
-  # ── Churned (formerly-active relationship that ended) ──────────────────────
-  - slug: churned
-    displayName: Churned
-    icon: user-x
-    color: gray
-    description: A relationship (client, partner, or otherwise) that was active and has since ended.
-    scope: shared
-    profileKind: role
-    applicableKinds:
-      - company
-      - person
+  # ── Outreach touch (owned here — folded from Outreach & Comms, 2026-10-23) ─
+  # RETIRED AS A DRAFT (founder decision d5, 2026-11-02): no process creates a
+  # touch any more; a new message is a proposed message in the person's
+  # channel (messaging.send). The kind stays only while the existing touches
+  # are moved into their channels; it is removed after that move.
+  # One message drafted for (and then sent to) one person, as part of an
+  # outreach campaign. Same slug and lifecycle keys as in Outreach & Comms.
+  # The agent drafts, a person sends (founder decision 2026-10-20): `sent` is
+  # humanOnly, and no CRM process carries a send grant. Who it goes to is the
+  # `sent_to` edge; whose message it is, the lead, is `relates_to` (required,
+  # entityLinks below); its campaign (the angle) is `part_of`.
+  - slug: outreach-touch
+    displayName: Outreach Touch
+    icon: message-circle
+    color: blue
+    description: A single message drafted for one person as part of an outreach campaign; a person sends it.
+    # The ONE lifecycle (work model L1): every option's category.
+    lifecycle:
+      property: status
+      options:
+        - { key: drafted, category: open }
+        - { key: sent, category: active, humanOnly: true }
+        - { key: opened, category: active }
+        - { key: replied, category: done }
+        - { key: bounced, category: lost }
+        - { key: no_response, category: lost }
     properties:
-      - slug: churnedDate
-        label: Churned Date
+      - slug: channel
+        label: Channel
+        valueType: string
+        inputType: select
+        enumValues: [linkedin, email]
+      # first_message: the first personal message to a lead, drafted by "Draft
+      # a first message" (2026-10-27).
+      - slug: touchType
+        label: Touch type
+        valueType: string
+        inputType: select
+        enumValues: [first_message, connection_request, follow_up, intro_email, reply]
+      - slug: status
+        label: Status
+        valueType: string
+        inputType: select
+        enumValues: [drafted, sent, opened, replied, bounced, no_response]
+        constraints: { defaultValue: drafted }
+      - slug: sentDate
+        label: Sent date
         valueType: date
         inputType: date
-      - slug: churnReason
-        label: Reason
-        valueType: string
-        inputType: textarea
-      - slug: notes
-        label: Notes
+      - slug: messageContent
+        label: Message content
         valueType: string
         inputType: textarea
 
@@ -514,6 +723,103 @@ entityLinks:
     targetProfileSlug: deal
     type: partner_on_deal
     label: Partner side
+  # Campaign membership — the sourcing edge between a counterparty and the
+  # campaign it came from (moved from business-developer, 2026-10-12).
+  - sourceProfileSlug: person
+    targetProfileSlug: campaign
+    type: member_of
+    label: Member of
+  - sourceProfileSlug: company
+    targetProfileSlug: campaign
+    type: member_of
+    label: Member of
+  # Outreach touches (folded from Outreach & Comms, 2026-10-23): who a message
+  # goes to, and the outreach campaign (the angle) it is part of. The people a
+  # campaign reaches are its members (`member_of` above); Outreach & Comms'
+  # `targets` edge from a campaign to people and companies was a twin of it, and
+  # `targets` here means a lead's segment (below).
+  - sourceProfileSlug: outreach-touch
+    targetProfileSlug: person
+    type: sent_to
+    label: Sent to
+  - sourceProfileSlug: outreach-touch
+    targetProfileSlug: campaign
+    type: part_of
+    label: Part of
+  # Whose message it is (founder D3.1, research R3 2469006b, plan 38fb38a7 §3):
+  # a message is about ONE lead, the person or company it `relates_to`. It is
+  # the one rule the CADENCE counts by and the CRM app reads ("whose message"),
+  # so it is REQUIRED: the pod's create doors warn when a new touch has none
+  # (D3.2: warn, never refuse yet), and template health lists the touches
+  # missing it. The two rows are ONE rule, met by an edge to either kind.
+  - sourceProfileSlug: outreach-touch
+    targetProfileSlug: person
+    type: relates_to
+    label: Relates to
+    required: true
+  - sourceProfileSlug: outreach-touch
+    targetProfileSlug: company
+    type: relates_to
+    label: Relates to
+    required: true
+  # Segment (CRM build plan A8): the audience a lead was found for. The same
+  # `targets` relation foundation uses for positioning → audience. The ANGLE a
+  # lead is approached with is its outreach campaign (a `campaign` with
+  # campaign-type outreach), which the follow-up drafts are `part_of`.
+  - sourceProfileSlug: person
+    targetProfileSlug: audience
+    type: targets
+    label: Targets
+  - sourceProfileSlug: company
+    targetProfileSlug: audience
+    type: targets
+    label: Targets
+
+# Views folded from Outreach & Comms (2026-10-23). The CRM's own surface is the
+# website (layout.primarySurface); these are the workbench lenses on the same
+# rows. Same slugs as there.
+views:
+  # The deal views: the sale, drawn three ways over the `deal` kind.
+  - name: Pipeline
+    slug: deal-pipeline
+    # The ONE board (work model L3, D3): columns ARE the deal's declared
+    # lifecycle (`commercialStage`), moves go through the one mover.
+    type: pipeline
+    scopeProfileSlug: deal
+    description: Every deal on a board by stage, from meeting booked to won or lost.
+    config:
+      profileSlug: deal
+  - name: Deals
+    slug: deals-table
+    type: table
+    scopeProfileSlug: deal
+    description: Every deal with its stage, value, expected close date and next step.
+    config:
+      columns: [title, commercialStage, value, closeDate, nextStep]
+  - name: Deals list
+    slug: deals-list
+    type: list
+    scopeProfileSlug: deal
+    description: Deals in the order they are expected to close.
+    config:
+      sortColumn: closeDate
+      sortDirection: asc
+  - name: Campaigns
+    slug: outreach-campaigns
+    type: table
+    scopeProfileSlug: campaign
+    description: Every campaign people come from — its type, its status, who it is for and its offer.
+    config:
+      columns: [title, campaign-type, campaign-status, campaign-target-audience, campaign-start-date]
+  - name: Messages
+    slug: outreach-touches
+    type: kanban
+    scopeProfileSlug: outreach-touch
+    groupBy: status
+    description: Every outreach message, grouped by where it stands — drafted for a person to send, through replied.
+    config:
+      groupBy: status
+      cardFields: [channel, touchType, sentDate]
 
 onboarding:
   goal: >
@@ -529,10 +835,10 @@ onboarding:
   expertise:
     starters:
       - >
-        A useful first pipeline is deliberately small. Start with the few stages
-        that change how the team acts — contacted, qualifying, proposal,
-        negotiating, won, and lost — and keep the template's default stages
-        unless the user's real process needs a different view.
+        A useful first pipeline is deliberately small. A deal's stages are the
+        sale only — draft, proposed, negotiating, won, lost; who is worth
+        pursuing at all is the lead's qualification, not a deal stage. Keep the
+        template's stages unless the user's real process needs a different view.
       - >
         Populate the workspace with live work, not a perfect historical archive:
         propose the three to five opportunities the user is actively trying to
@@ -561,17 +867,20 @@ onboarding:
       and no invented commercial data.
   collect:
     - profileSlug: company
+      min: 1
       what: The real prospect organisations behind current conversations.
       cardinality: few
       keyFields: [website, industry, companySize, source, nextStep]
     - profileSlug: person
+      min: 1
       what: The known stakeholders for those organisations and opportunities.
       cardinality: few
       keyFields: [email, jobTitle, company, source, nextFollowUpDate]
     - profileSlug: deal
+      min: 1
       what: The live opportunities worth actively moving through the pipeline.
       cardinality: few
-      keyFields: [dealStage, value, closeDate, nextStep]
+      keyFields: [commercialStage, value, closeDate, nextStep]
   openingQuestions:
     - "Which three to five opportunities are you actively trying to move right now?"
     - "For the most important one, which company and real stakeholder are involved?"
@@ -605,6 +914,103 @@ playbooks:
       - entity.create
     status: active
 
+  # ── Qualify a lead — a ROLE-subject process ─────────────────────────────
+  # Runs on the `lead` ROLE (foundation's pod-wide role, profileKind: role),
+  # not on a kind: its status is the role's leadStage, written on the FACET of
+  # the person or company carrying it (the lifecycle door `moveStatus`); a
+  # person starts it (manual since 2026-10-27, see activators). Moved from
+  # business-developer's "Qualify a CRM lead" (founder decision 2026-10-12).
+  # Deciding is ONE `choose` (pursue / nurture / drop) with no gate asking
+  # again. Pursue sets the lead qualified with the next action "book a
+  # meeting"; it never opens a deal (CRM build plan A4, 2026-10-22): a deal
+  # exists only once a person records a booked meeting (founder decision
+  # 2026-10-20), and that same move converts the lead. Nurture and drop are the
+  # person's answer, recorded as nurturing / disqualified.
+  # Next action (CRM review 2026-10-27): every outcome that leaves the lead
+  # open (score, pursue, nurture) writes the facet's `nextAction` (one
+  # imperative line) and `nextActionAt` (a date) by name: the CRM app's lead
+  # page shows the next action, and a process that leaves a lead open without
+  # one leaves the person with nothing to do. Drop stays the person's move:
+  # `disqualified` is humanOnly on the lifecycle, so the agent's move after
+  # the `choose` is a proposal the person approves, never applied by it.
+  - name: Qualify a lead
+    description: Research one lead, decide with a person whether it is worth pursuing, and set a pursued lead qualified with "book a meeting" as its next action.
+    goalTemplate: >-
+      Qualify this lead ({lead}). RESEARCH: verify and enrich only facts you
+      can support — company, role, size, recent signal — and record the
+      source of each. SCORE: assess fit against the offers and the ideal
+      client, set the ICP score, qualification notes and outreach channels,
+      and write the step you recommend as the lead's next action: `nextAction`
+      one imperative line (e.g. "Send the first message on LinkedIn") and
+      `nextActionAt` its date. DECIDE: ask the person to `choose` pursue,
+      nurture or drop, your recommendation first; that answer is the
+      decision. NURTURE: set the lead to nurturing, with `nextAction` to check
+      in again and `nextActionAt` the date they gave (three months out when
+      they gave none). DROP: write their reason in `disqualificationReason`
+      and move the lead to disqualified; that move is the person's
+      (disqualified is human-only), so it comes back proposed for them to
+      approve, which is success; never write it another way. PURSUE: only
+      when they chose pursue, set the lead to qualified with `nextAction`
+      "Book a meeting" (one line naming the channel, e.g. "Ask for a
+      meeting on LinkedIn") and `nextActionAt` its date. Never create a deal:
+      a deal is opened when a person records a booked meeting, and that same
+      step converts the lead. Never mark the lead a client.
+    subjectProfile:
+      profileSlug: lead
+      statusProperty: leadStage
+    humanOnlyStatuses: [new, outreach, engaged, nurturing, converted, disqualified]
+    # Manual only (founder decision 2026-10-27): the `created` worker started
+    # one run per lead and burned the budget; a list is scored in ONE run by
+    # "Score a list" instead, and a person qualifies the leads worth it.
+    activators:
+      - { on: manual, mode: propose }
+    params:
+      - { name: lead, type: entity, label: Lead, required: true }
+    executor: is-agent
+    status: active
+    requiredIntents: [enrich_entity, search_external]
+    stages:
+      - key: research
+        name: Research
+        category: planned
+        subjectStatus: researching
+        goal: Verify and enrich the lead's facts from the pod and public sources, citing each source.
+        criteria:
+          - key: lead-facts-sourced
+            statement: Every fact added to the lead names where it came from.
+            check: { kind: judge }
+      - key: score
+        name: Score
+        category: started
+        goal: Set the ICP score, qualification notes and outreach channels, and the recommended step as the lead's nextAction and nextActionAt.
+        criteria:
+          - key: lead-score-set
+            statement: The lead has an ICP score and a written reason for it.
+            check: { kind: judge }
+          - key: lead-next-action
+            statement: The lead's nextAction is one imperative line and its nextActionAt is set.
+            check: { kind: judge }
+      - key: decide
+        name: Decide
+        category: started
+        goal: Ask the person to choose pursue, nurture or drop, your recommendation first, and record the answer on the lead; a nurtured lead gets a nextAction to check in and its nextActionAt, a dropped one its disqualificationReason and a proposed move to disqualified.
+        criteria:
+          - key: lead-decision-chosen
+            statement: The person chose pursue, nurture or drop, and the lead records the choice.
+            check: { kind: human }
+          - key: lead-open-has-next-action
+            statement: A lead the answer leaves open (pursued or nurtured) has a nextAction and a nextActionAt for that answer.
+            check: { kind: judge }
+      - key: pursue
+        name: Pursue
+        category: completed
+        subjectStatus: qualified
+        goal: Only after the person chose pursue, set the lead qualified with nextAction "Book a meeting" (one line naming the channel) and its nextActionAt. Open no deal.
+        criteria:
+          - key: lead-book-meeting
+            statement: The lead's nextAction is to book a meeting and its nextActionAt is set.
+            check: { kind: judge }
+
   # ── 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
@@ -633,8 +1039,8 @@ playbooks:
       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).
+      while or stuck in the same `commercialStage` past the stage's stuck
+      threshold (14 days in Meeting booked, Proposal sent or negotiating).
       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.
@@ -651,9 +1057,985 @@ playbooks:
       - apify_run_actor
     status: active
 
+  - name: Win a deal
+    description: Take a deal from first conversation to won or lost — qualify it, write and send the proposal, negotiate, and hand a won deal to delivery, with a person deciding every commitment.
+    goalTemplate: >-
+      Work this deal ({deal}) through its stages; each stage moves the deal's
+      commercial stage. QUALIFY: from the pod (the company, its people, every
+      past message and meeting) and public sources, establish the four facts a
+      proposal needs — the problem the buyer wants solved and what it costs
+      them, a budget range, who signs, and when they need it — and link the
+      people involved to the deal. Do not guess a fact: when one is missing,
+      ask the person who owns the relationship. WRITE: draft the proposal
+      document (scope, deliverables, timeline, price, terms) from the agency's
+      offers and past won proposals, and set the deal's value and close date.
+      SEND: a person approves the proposal before it goes to the client;
+      nothing is sent without that approval. AWAIT: wait for the client's
+      answer and record it on the deal. NEGOTIATE: its check reads that
+      answer; log every objection and counter-offer and propose the next step.
+      WON: once a person confirms the client said yes, reuse the engagement
+      Operations already has for this company; only when there is none, open
+      one at proposed with its client set to the company. Then attach the
+      client role to the company with handoff status handed_off. The daily
+      "Pick up handed-off clients" automation skips any client that already
+      has an engagement, so no second one is opened. A lost deal is a
+      person's call — record why it was lost.
+    subjectProfile:
+      profileSlug: deal
+      statusProperty: commercialStage
+    humanOnlyStatuses: [lost]
+    activators:
+      - { on: created, mode: propose }
+    params:
+      - { name: deal, type: entity, label: Deal, required: true }
+    executor: is-agent
+    status: active
+    requiredIntents: [enrich_entity, search_external, list_records]
+    expectedOutputs:
+      - { kind: person, label: Decision maker, relationToSubject: linked_to_deal }
+      - { kind: document, label: Proposal }
+      - { kind: engagement, label: Client engagement, relationToSubject: relates_to }
+    metadata:
+      lineage: { method: "BANT qualification, proposal-led B2B sale" }
+    stages:
+      - key: qualify
+        name: Qualify
+        category: planned
+        subjectStatus: draft
+        goal: Establish need, budget, decision maker and timing from evidence, and link the people involved.
+        criteria:
+          - key: qualify-need
+            statement: The buyer's problem and what it costs them are written on the deal.
+            check: { kind: judge }
+          - key: qualify-budget
+            statement: A budget range is recorded, or the deal says the buyer refused to give one.
+            check: { kind: judge }
+          - key: qualify-decision-maker
+            statement: The person who signs is linked to the deal.
+            check: { kind: judge }
+          - key: qualify-timing
+            statement: The date the buyer needs this by is recorded.
+            check: { kind: judge }
+      - key: write
+        name: Write proposal
+        category: started
+        goal: Draft the proposal and set the deal's value and close date.
+        gate: { kind: check }
+        onFail: { toStage: qualify }
+        criteria:
+          - key: proposal-drafted
+            statement: A proposal document with scope, timeline, price and terms is attached to the deal.
+            check: { kind: judge }
+          - key: proposal-value-set
+            statement: The deal's value and expected close date are set.
+            check: { kind: evidence, evidenceKey: deal-value }
+      - key: send
+        name: Send proposal
+        category: started
+        subjectStatus: proposed
+        goal: A person approves the proposal; then send it to the decision maker and record when.
+        gate: { kind: human }
+        onFail: { toStage: write }
+      - key: await-answer
+        name: Awaiting the answer
+        category: started
+        goal: Wait for the client's answer to the proposal and record it on the deal.
+        indefinite: true
+        criteria:
+          - key: proposal-answered
+            statement: The client's answer to the proposal is recorded on the deal.
+            check: { kind: judge }
+      - key: negotiate
+        name: Negotiate
+        category: started
+        subjectStatus: negotiating
+        goal: Answer objections, log every counter-offer on the deal, and propose the next step.
+        gate: { kind: check }
+        onFail: { toStage: await-answer }
+        indefinite: true
+        criteria:
+          - key: negotiate-terms-agreed
+            statement: The final price and scope the client agreed to are written on the deal.
+            check: { kind: judge }
+      - key: won
+        name: Won
+        category: completed
+        subjectStatus: won
+        goal: A person confirms the client said yes; then reuse the company's engagement in Operations (open one only when none exists) and attach the client role to the company.
+        gate: { kind: human }
+        onFail: { toStage: negotiate }
+
+  # ── Build a prospect list from our foundation — a BATCH process ──────────
+  # CRM build plan A5 (founder Q5). One run = one batch of candidate accounts
+  # for ONE audience, its subject. The person decides the batch in ONE review:
+  # the candidates are ONE composite proposal, and keep or drop is a per-item
+  # disposition on it (stored in the proposal's `dispositions`; a partly kept
+  # batch is never counted as a full approval). Approving creates only the kept
+  # candidates. The dropped ones stay readable on that proposal, and the next
+  # batch reads them back so it never suggests them again. Generic: the
+  # audience, the offers and the market come from Foundation.
+  # Pool (2026-10-27, CRM lists): `pool: network` searches nothing outside the
+  # pod; it ranks the person's own `contact` role holders with the "Score a
+  # list" rubric (its one home), and the kept ones become leads with lead
+  # source warm-network, in the same single review.
+  - name: Build a prospect list from our foundation
+    description: Turn one audience and the company's offers into a short, sourced batch of companies and people worth contacting; a person keeps or drops each one in a single review, and only the kept ones become leads.
+    goalTemplate: >-
+      Build a prospect list for the audience {audience}: about {count}
+      accounts in {market}, from the {pool} pool. READ: the audience
+      (segment, persona, jobs, traits) and the company's offers and
+      positioning in Foundation; never invent an offer. Then read this
+      process's earlier batches for this audience: each batch's review
+      records which candidates a person dropped, and none of them may be
+      suggested again. POOL public — SEARCH: public sources only (company
+      sites, company pages, job posts, public posts, directories); never
+      collect contact data a person chose to hide, never use a scraped
+      personal database. For each account record the company name, website,
+      size, why it fits (one line naming the audience trait it matches), a
+      recent trigger if any, the likely decider's role and public profile URL,
+      and the source URL of every fact. DEDUPE: look for the same company
+      (website or domain) or person (email or profile URL) in the pod first;
+      an existing record is reused, never duplicated. POOL network — RANK:
+      search nothing outside the pod. The candidates are the person's own
+      contacts, the people and companies holding the contact role in the pod
+      that are not a lead already. Score each against the audience with the
+      rubric written in the "Score a list" process (read it there; never
+      restate or change it), leave out the ones scoring 1, and keep the best
+      ones. Each is an existing record, never a new one. PROPOSE: submit the
+      whole batch as ONE proposal, best fits first. From the public pool,
+      per account: the company (or the existing one), its decider when known, the lead role at stage
+      new with lead source research and the sources, and a targets link to
+      the audience. From the network pool, per contact: the existing record,
+      the lead role at stage new with lead source warm-network, its
+      icpScore, buyingSignal, buyingSignalSource, scoredAt and
+      qualificationNotes from the rubric, and a targets link to the
+      audience. The person keeps or drops each candidate in that one review,
+      and approving creates only the kept ones. Never create a lead outside
+      that proposal, and never ask the person to pick the accounts a second
+      time.
+    subjectProfile:
+      profileSlug: audience
+    activators:
+      - { on: manual, mode: propose }
+    params:
+      - { name: audience, type: entity, label: Audience to prospect, required: true }
+      - { name: count, type: number, label: How many accounts to propose, default: 25 }
+      - { name: market, type: text, label: Country and language, default: the market Foundation names }
+      # public = search public sources; network = rank the person's own
+      # contacts (the `contact` role holders) instead (2026-10-27).
+      - { name: pool, type: choice, label: Where to look, options: [public, network], defaultValue: public }
+    executor: is-agent
+    status: active
+    requiredIntents: [search_external]
+    stages:
+      - key: read
+        name: Read the foundation
+        category: planned
+        goal: Read the audience and the offers, restate the ideal account in three lines, and list the candidates a person dropped in earlier batches.
+        criteria:
+          - key: prospect-icp-restated
+            statement: The ideal account is restated from the pod's audience and offers, with no invented offer.
+            check: { kind: judge }
+      - key: search
+        name: Search the pool
+        category: started
+        goal: Find candidate accounts in public sources, or rank the person's own contacts with the "Score a list" rubric for the network pool, and record a source for every fact.
+        criteria:
+          - key: prospect-facts-sourced
+            statement: Every fact on every candidate names its source URL.
+            check: { kind: judge }
+          - key: prospect-no-duplicates
+            statement: No candidate duplicates a company or person already in the pod.
+            check: { kind: judge }
+          - key: prospect-not-dropped-before
+            statement: No candidate is one a person dropped in an earlier batch.
+            check: { kind: judge }
+      - key: review
+        name: Person keeps or drops each candidate
+        category: completed
+        goal: Submit the batch as one proposal; the person keeps or drops each candidate in that one review, and only the kept ones are created.
+        expectedOutputs:
+          - { kind: company, label: Prospect accounts, relationToSubject: targets }
+        criteria:
+          - key: prospect-one-proposal
+            statement: The whole batch is one proposal, each candidate an item of it with its sources.
+            check: { kind: judge }
+
+  # ── Score a list — THE one home of the lead rubric ──────────────────────
+  # CRM lists (founder decision 2026-10-27). A list IS an audience; its leads
+  # are the people and companies with the lead role whose `targets` edge
+  # points at it. ONE run scores the whole list, signal first, 1 to 5 (it
+  # replaces one "Qualify a lead" run per lead, which burned the budget). The
+  # rubric is written ONCE, in this goal: "Build a prospect list from our
+  # foundation" (network pool) reads it here, and "Draft a first message"
+  # reads the fields it writes and never rescores. The subject is an audience,
+  # which declares no lifecycle, so no stage moves anything (the shape of
+  # "Build a prospect list from our foundation"); it never moves a lead's
+  # leadStage either.
+  - name: Score a list
+    description: Score every lead of one list (an audience) from public signals, 1 to 5, signal first, and write the score, the signal, its source and why on each lead; one run for the whole list.
+    goalTemplate: >-
+      Score the leads of the list {audience}: the people and companies with
+      the lead role and a targets link to this audience whose scoredAt is
+      empty or older than {rescoreAfterDays} days, at most {limit} of them,
+      the never-scored ones first. READ: the audience (segment, persona,
+      jobs-to-be-done, traits, description), which are the list's criteria,
+      and the company's offers in Foundation. RESEARCH each lead from public
+      sources only (its website, company page, public profile, job posts,
+      public posts, freelance platforms) and from the pod (past messages,
+      conversations, notes); never collect contact data a person chose to
+      hide, never use a scraped personal database. RUBRIC (its one home):
+      score = signal + fit + warmth, at least 1 and at most 5. SIGNAL, 0 to
+      2: hiring or asking within the last 90 days = 2, where hiring is a job
+      post or mission offer for automation, AI agents or no-code (n8n, Make,
+      Zapier, Hermes, Claude Code, AI ops and the like) and asking is a
+      public post or freelance request asking for that help; tooling = 1, it
+      uses those tools publicly with no ask; none = 0, nothing found. FIT, 0
+      to 2: a founder or director of a company of 2 to 30 people in France,
+      or an independent expert or small agency, that is not a competitor =
+      2; partial (size unknown, outside France, or near the decider rather
+      than the decider) = 1; excluded (an AI or no-code agency that
+      competes, a regulated profession, more than 50 people, a student) = 0.
+      WARMTH, 0 or 1: an existing two-way exchange with the person, or a
+      first-degree connection with messages, = 1. WRITE on each lead's lead
+      role: icpScore (the score), buyingSignal (hiring, asking, tooling or
+      none), buyingSignalSource (the public URL proving the signal, empty for
+      none), scoredAt (today) and qualificationNotes (the points for signal,
+      fit and warmth with one line each, the doubt you could not resolve, and
+      the source URL of every fact). Leave a fact out rather than guess.
+      Write the scores in one batch. Never move a lead's stage, never create
+      a lead, never draft a message. End with a summary: how many leads were
+      scored, how many per score, and the best five with their signal.
+    subjectProfile:
+      profileSlug: audience
+    activators:
+      - { on: manual, mode: propose }
+    params:
+      - { name: audience, type: entity, label: List (audience) to score, required: true }
+      - { name: limit, type: number, label: Most leads to score in this run, defaultValue: 50 }
+      - { name: rescoreAfterDays, type: number, label: Rescore leads scored more than this many days ago, defaultValue: 30 }
+    executor: is-agent
+    status: active
+    requiredIntents: [search_external]
+    stages:
+      - key: read
+        name: Read the list
+        category: planned
+        goal: Read the audience's criteria and the offers, and list the leads to score — those targeting the audience never scored or scored more than rescoreAfterDays days ago, at most limit.
+        criteria:
+          - key: score-leads-listed
+            statement: The leads to score are the ones targeting the audience that were never scored or were scored more than rescoreAfterDays days ago, at most limit.
+            check: { kind: judge }
+      - key: score
+        name: Score each lead
+        category: started
+        goal: Research each lead from public sources and the pod, score it with the rubric, and write icpScore, buyingSignal, buyingSignalSource, scoredAt and qualificationNotes on its lead role.
+        criteria:
+          - key: score-fields-set
+            statement: Every scored lead has an icpScore from 1 to 5, a buyingSignal and a scoredAt.
+            check: { kind: judge }
+          - key: score-notes-sourced
+            statement: Every scored lead's qualificationNotes give the signal, fit and warmth points, the doubt, and the source URL of each fact.
+            check: { kind: judge }
+          - key: score-signal-proved
+            statement: Every lead whose buyingSignal is not none has a buyingSignalSource URL proving it.
+            check: { kind: judge }
+          - key: score-public-only
+            statement: Every fact comes from a public source or the pod, and no contact data a person hid was collected.
+            check: { kind: judge }
+          - key: score-reader-only
+            statement: No lead's stage was moved, no lead was created and no message was drafted.
+            check: { kind: judge }
+      - key: summary
+        name: Sum up the list
+        category: completed
+        goal: Write how many leads were scored, how many per score, and the best five with their signal.
+        criteria:
+          - key: score-summary
+            statement: The summary gives the number scored, the count per score and the best five with their signal.
+            check: { kind: judge }
+
+  # ── Draft a first message — one lead's first message ────────────────────
+  # CRM lists (founder decision 2026-10-27). One run drafts ONE personal first
+  # message for one lead: a proposed message in the person's channel, filed
+  # through the pod's send door `messaging.send` (founder decisions d1/d6,
+  # 2026-11-02), for a person to approve. The agent never sends: the pod sends
+  # only what a person approved, and no CRM process carries a send grant. It
+  # reads the score fields "Score a list" wrote and never rescores.
+  # A lifecycle READER of leadStage, like "Follow up on leads in outreach": no
+  # stage moves the lead; once the message is sent, the move to outreach is
+  # PROPOSED through the door, so "Follow up on leads in outreach" drafts the
+  # next one. Next action: the draft becomes the lead's `nextAction` with
+  # `nextActionAt` today, like every CRM draft.
+  # Messages and cadence (founder decisions 2026-10-27, send door 2026-11-02):
+  # every drafter writes a draft the same way (DRAFT RULES: messaging.send to
+  # the person's entity id, never a tool's own send verb, never an outreach
+  # touch, never synap_capture), and every send sets the next follow-up by the same
+  # CADENCE: 3 days after the first message, 7 days after each follow-up, at
+  # most two follow-ups. The DRAFT RULES and CADENCE paragraphs are each word
+  # for word the same in this process, "Follow up on leads in outreach" and
+  # "Personalized Outreach" (crm-messages-cadence.template.test.ts pins them).
+  - name: Draft a first message
+    description: Draft one personal first message for a lead, citing its buying signal or a past exchange, in the person's language, as a proposed message in their channel for a person to approve; the agent never sends.
+    goalTemplate: >-
+      Draft the first message to the lead {lead} on {channel}. READ: the
+      lead's score fields (icpScore, buyingSignal, buyingSignalSource,
+      qualificationNotes) as they are, never rescoring them; its channels,
+      past messages and notes in the pod; and the outreach campaign given
+      ({campaign}), if any: its value proposition and call to action are the
+      angle. WHO: a person lead is written to directly; for a company lead,
+      write to the person who decides there (from the pod, else its public
+      decider), and when no decider is known ask the person who to write to.
+      DRAFT: one first message on channel {channel}, in the campaign's angle
+      when one is given. DRAFT RULES: each draft is one proposed message in
+      the channel of the person it is written to, filed through the pod's
+      send door: run messaging.send with to = that person's entity id (for a
+      company lead, its decider: when that person is not in the pod, create
+      them through the entity door with only their own fields, such as name,
+      role and LinkedIn URL, never the company's website, domain or email),
+      text = the message, and provider linkedin or email. Read their channel
+      first (synap_get_channel, mode person) for what was already said. The
+      pod files it for a person to review in that channel; it goes out only
+      once they approve it. Never call a tool's own send verb (Unipile,
+      Gmail), never create an outreach touch, a note or a task holding the
+      message, and never use synap_capture for it. Never send.
+      A LinkedIn message is drafted whatever their reach: the pod holds a
+      draft to someone who is not a connection yet, shows it with the next
+      step and lets it go out once they connect, so never hold a draft back
+      for want of a connection. Draft it, then, in this order: (1) a person
+      with no linkedinUrl: find their profile with linkedin_find_profile
+      (their full name and company); on a match, propose its linkedinUrl and
+      linkedinProviderId on the person for a person to approve; on none or
+      several, ask the person to choose among its candidates (the process
+      "Find their LinkedIn" does this for one lead). (2) Read their
+      linkedinConnection, which only the pod writes (never set it or
+      linkedinInvitedAt): connected, nothing more; none or not set, ask to
+      connect with linkedin_send_invite (it refuses someone already connected
+      or already invited: then nothing more); pending, the draft waits for
+      them; ignored, draft by email instead when they have an email address.
+      While the draft waits for them to connect, set the lead's nextAction to
+      "Wait for <name> to accept the LinkedIn request" and its nextActionAt 7
+      days later. An email message needs none of this. Its message
+      is personal: it cites the buying signal and what it showed, or a past
+      exchange, never a generic template; short; in the person's language,
+      French by default, and in French it says vous. It offers one useful
+      next step, never pressure. Draft one message only: a person reviews
+      it in the channel, edits it if needed and approves it. NEXT ACTION:
+      set the lead's nextAction to "Send the first message to <name> on
+      LinkedIn" ("Send the first message to <name> by email" on email),
+      naming the person written to, and its nextActionAt to today. Never
+      move the lead's stage while drafting. SENT: once the message is sent,
+      follow the cadence, so "Follow up on leads in outreach" drafts the
+      next one. CADENCE: when a message is sent (a person approved its
+      proposed message, so it is an outbound message in the channel), set
+      its lead's lastContactedAt to the sent day, count the messages sent to
+      the lead (the outbound messages in its channels, read with
+      synap_get_channel mode person: for a company lead, the channels of the
+      person written to there), and set the lead's next action: after the
+      first message, nextAction "Follow up with <name> if no reply" and
+      nextActionAt the sent day + 3 days; after the first follow-up,
+      nextAction "Follow up with <name> a last time if no reply" and
+      nextActionAt the sent day + 7 days; after the second follow-up,
+      nextAction "No reply after two follow-ups: nurture or drop <name>" and
+      nextActionAt the sent day + 7 days, and when that date passes with no
+      reply, "Follow up on leads in outreach" proposes nurturing. Never a
+      third follow-up. Propose moving a lead at new or researching to
+      outreach through the status door, with its expected status. A reply
+      stops the cadence: a reply is an inbound message after our last
+      outbound one in the channel, and "Follow up on leads in outreach"
+      reads it and proposes the next step.
+    subjectProfile:
+      profileSlug: lead
+    activators:
+      - { on: manual, mode: propose }
+    params:
+      - { name: lead, type: entity, label: Lead, required: true }
+      - { name: campaign, type: entity, label: Outreach campaign (optional) }
+      - { name: channel, type: choice, label: Channel, options: [linkedin, email], defaultValue: linkedin }
+    executor: is-agent
+    status: active
+    grants: [entity.create]
+    stages:
+      - key: draft
+        name: Draft the first message
+        category: started
+        goal: Read the lead's score fields, channels and history, draft one personal first message for the person (a company's decider) as a proposed message in their channel through messaging.send (to = their entity id, never a tool's own send verb, never an outreach touch or synap_capture), and set the lead's nextAction "Send the first message to <name> on LinkedIn" with nextActionAt today.
+        expectedOutputs:
+          # The proposed message: a `messaging.external.send` proposal on the
+          # person's channel (target type `messaging`). The channel is already
+          # bound to the person, so it writes no edge to the lead.
+          - { kind: messaging, label: Proposed first message, relationToSubject: none }
+        criteria:
+          # A judge: no core or catalog verb reads a session's proposals and
+          # answers {passed}, so the pod has no exact check for this yet.
+          - key: first-message-one-draft
+            statement: One proposed message, filed through messaging.send to the person written to (for a company, its decider), waits for review in that person's channel, holds the message text, and follows the campaign's angle when one was given, whatever the person's LinkedIn reach; on LinkedIn to someone not yet a connection, the pod holds it, and their profile is found and the connection asked for or awaited, in the DRAFT RULES order.
+            check: { kind: judge }
+          - key: first-message-no-capture
+            statement: No tool's own send verb was called, no outreach touch, note or task holds the message, no record was made with synap_capture, and a decider created for a company lead carries only the person's own fields, never the company's website, domain or email.
+            check: { kind: judge }
+          - key: first-message-personal
+            statement: The message cites the lead's buying signal or a past exchange, is in the person's language (French by default, with vous), and is not a generic template.
+            check: { kind: judge }
+          - key: first-message-not-rescored
+            statement: The lead's icpScore, buyingSignal and scoredAt are unchanged, and its stage was not moved.
+            check: { kind: judge }
+          - key: first-message-next-action
+            statement: The lead's nextAction is "Send the first message to <name>" on the channel, naming the person written to, and its nextActionAt is today.
+            check: { kind: judge }
+      - key: send
+        name: Person sends
+        category: completed
+        goal: The person reviews the proposed message in the channel, edits it if needed and approves it, and the pod sends it; then set the lead's lastContactedAt to the sent day, nextAction "Follow up with <name> if no reply" and nextActionAt the sent day + 3 days, and propose moving a new or researching lead to outreach.
+        gate: { kind: human }
+        onFail: { toStage: draft }
+
+  # ── Find their LinkedIn — one lead's LinkedIn profile ───────────────────
+  # CRM Messages contract (decision b603d75e, build map ca310f27): the first of
+  # the steps a LinkedIn lead walks (Find their LinkedIn, Ask to connect,
+  # Waiting, Send). linkedin_find_profile is a read with no inputMap, so the
+  # actions door cannot run it for the CRM app: the app starts this process
+  # for one lead (`params.lead`, as "Draft a first message"). On a strict match
+  # it PROPOSES linkedinUrl and linkedinProviderId on the person; on none or
+  # several it hands the person up to 3 candidates. The reach fields stay the
+  # pod's (backend#786). A lifecycle READER of leadStage: no stage moves.
+  - name: Find their LinkedIn
+    description: Find one lead's LinkedIn profile by their full name and company and propose its URL and member id on the person for a person to approve, or offer up to 3 candidates to choose from; nothing is sent.
+    goalTemplate: >-
+      Find the LinkedIn profile of the lead {lead}. WHO: a person lead is
+      looked up themselves; for a company lead, the person who decides there,
+      from the pod; when no decider is known, ask the person who it is. When
+      that person already has a linkedinUrl, say so and stop. FIND: run
+      linkedin_find_profile with their full name, their company and the
+      LinkedIn account unipile_list_accounts lists (when several are
+      connected, ask the person which one reads). On a match, propose its
+      linkedinUrl and linkedinProviderId on the person through the entity
+      door, for a person to approve; never write them directly, and never set
+      linkedinConnection or linkedinInvitedAt, which only the pod writes. On
+      none, several or more results than it read, ask the person to choose
+      among its candidates (at most 3, each with its name, headline and
+      profile URL) or to give the URL themselves, then propose the one chosen
+      the same way. Never send a message or a connection request, never draft
+      one, and never move the lead's stage.
+    subjectProfile:
+      profileSlug: lead
+    activators:
+      - { on: manual, mode: propose }
+    params:
+      - { name: lead, type: entity, label: Lead, required: true }
+    executor: is-agent
+    status: active
+    requiredIntents: [enrich_entity]
+    stages:
+      - key: find
+        name: Find the profile
+        category: started
+        goal: Run linkedin_find_profile for the lead (a company lead's decider) with their full name and company; on a match propose linkedinUrl and linkedinProviderId on the person, otherwise ask the person to choose among up to 3 candidates or give the URL.
+        criteria:
+          - key: find-linkedin-proposed
+            statement: The person's linkedinUrl and linkedinProviderId are proposed on them for a person to approve (a strict match, or the candidate the person chose), or the person was asked to choose among at most 3 candidates; nothing was written directly.
+            check: { kind: judge }
+          - key: find-linkedin-reader-only
+            statement: No message or connection request was sent or drafted, linkedinConnection and linkedinInvitedAt were not set, and the lead's stage was not moved.
+            check: { kind: judge }
+      - key: confirm
+        name: Person confirms
+        category: completed
+        goal: The person approves the proposed profile, or picks a candidate or gives the URL, and the pod stores linkedinUrl and linkedinProviderId on the person; the lead's next step is then to ask to connect.
+        gate: { kind: human }
+        onFail: { toStage: find }
+
+  # ── Follow up on leads in outreach — THE one follow-up process ───────────
+  # CRM build plan A6 (founder Q4). A batch worker: each weekday it reads the
+  # channels of the leads in outreach. Due with no reply, it drafts one message
+  # each, a proposed message in the person's channel through the pod's send
+  # door `messaging.send`, in the angle of the lead's outreach campaign (A8).
+  # The agent never sends (founder decision 2026-10-20): a person approves each
+  # proposed message and the pod sends it. It replaces the pod-local process of
+  # the same name (founder's pod, 2026-10-21), which wrote its drafts nowhere.
+  # Replies (send door, 2026-11-02): a message sent from a channel is no
+  # outreach touch, so "Read the reply to an outreach message" never watches
+  # it; THIS process is the one reader of a reply in a channel (an inbound
+  # message after our last outbound one): it summarises it and proposes the
+  # next step, and a deal is never opened. "Read the reply" keeps only the
+  # touches marked sent before the channels. A lifecycle READER of leadStage:
+  # no stage moves the lead; nurturing after the second follow-up is proposed
+  # through the door once the last date passes in silence. `statusProperty`
+  # is named because the schedule worker reads `outreach`.
+  # Next action (CRM review 2026-10-27): a drafted message becomes the lead's
+  # `nextAction` ("Send the drafted message to <name>", `nextActionAt` today),
+  # and a message marked sent sets `nextActionAt` by the CADENCE (founder
+  # decision 2026-10-27, the same words as "Draft a first message" and
+  # "Personalized Outreach"): 3 days after the first message, 7 days after
+  # each follow-up, at most two follow-ups, never a third. The CRM app's lead
+  # page shows the next action, and a process that leaves a lead open without
+  # one leaves the person with nothing to do.
+  - name: Follow up on leads in outreach
+    description: Each weekday, read the channels of the leads in outreach; summarise a reply and propose the next step, or, when the follow-up is due with no reply, draft the next message in the angle of its outreach campaign as a proposed message for a person to approve; the agent never sends.
+    goalTemplate: >-
+      Follow up on the leads in outreach. For each, read its channels
+      (synap_get_channel, mode person: for a company lead, the channels of
+      the person who decides there) and its notes. A REPLY is an inbound
+      message after our last outbound one in a channel. With a reply, draft
+      nothing: summarise it for a person; when they show interest, propose
+      the next step (prepare the free estimate, "Prepare a pre-sale
+      estimate", or book a meeting) and propose moving the lead to engaged;
+      when they decline, propose nurturing or disqualified with their reason
+      (in disqualificationReason). Unless you propose dropping them, write
+      the next step on the lead as nextAction, one imperative line, and
+      nextActionAt, the date they named or today. Never open a deal and
+      never answer the reply yourself; a person does. With no reply, and
+      only when the lead's next action date is today or past and no
+      proposed message to it is still waiting, draft the next message, to
+      the lead (for a company, the person who decides there) and in the
+      angle of the lead's outreach campaign: follow its value proposition
+      and call to action, short and in the lead's language, offering the
+      next useful step, never pressure. For a lead with no campaign, ask the
+      person which one. Draft at most two follow-ups per lead: a lead
+      already sent two follow-ups gets no draft, never a third follow-up;
+      when its last date passes in silence, propose moving it to nurturing
+      through the status door, with its expected status. DRAFT RULES: each
+      draft is one proposed message in the channel of the person it is
+      written to, filed through the pod's send door: run messaging.send with
+      to = that person's entity id (for a company lead, its decider: when
+      that person is not in the pod, create them through the entity door
+      with only their own fields, such as name, role and LinkedIn URL, never
+      the company's website, domain or email), text = the message, and
+      provider linkedin or email. Read their channel first
+      (synap_get_channel, mode person) for what was already said. The pod
+      files it for a person to review in that channel; it goes out only once
+      they approve it. Never call a tool's own send verb (Unipile, Gmail),
+      never create an outreach touch, a note or a task holding the message,
+      and never use synap_capture for it. Never send.
+      A LinkedIn message is drafted whatever their reach: the pod holds a
+      draft to someone who is not a connection yet, shows it with the next
+      step and lets it go out once they connect, so never hold a draft back
+      for want of a connection. Draft it, then, in this order: (1) a person
+      with no linkedinUrl: find their profile with linkedin_find_profile
+      (their full name and company); on a match, propose its linkedinUrl and
+      linkedinProviderId on the person for a person to approve; on none or
+      several, ask the person to choose among its candidates (the process
+      "Find their LinkedIn" does this for one lead). (2) Read their
+      linkedinConnection, which only the pod writes (never set it or
+      linkedinInvitedAt): connected, nothing more; none or not set, ask to
+      connect with linkedin_send_invite (it refuses someone already connected
+      or already invited: then nothing more); pending, the draft waits for
+      them; ignored, draft by email instead when they have an email address.
+      While the draft waits for them to connect, set the lead's nextAction to
+      "Wait for <name> to accept the LinkedIn request" and its nextActionAt 7
+      days later. An email message needs none of this. For each draft, set
+      the lead's `nextAction` to send it (e.g. "Send the drafted message to
+      Ana on LinkedIn") and `nextActionAt` to today. The person reviews each
+      proposed message in its channel, edits it if needed and approves it;
+      the agent never sends. CADENCE: when a message is sent (a person
+      approved its proposed message, so it is an outbound message in the
+      channel), set its lead's lastContactedAt to the sent day, count the
+      messages sent to the lead (the outbound messages in its channels, read
+      with synap_get_channel mode person: for a company lead, the channels of
+      the person written to there), and set the lead's next action: after
+      the first message, nextAction "Follow up with <name> if no reply" and
+      nextActionAt the sent day + 3 days; after the first follow-up,
+      nextAction "Follow up with <name> a last time if no reply" and
+      nextActionAt the sent day + 7 days; after the second follow-up,
+      nextAction "No reply after two follow-ups: nurture or drop <name>" and
+      nextActionAt the sent day + 7 days, and when that date passes with no
+      reply, "Follow up on leads in outreach" proposes nurturing. Never a
+      third follow-up. Propose moving a lead at new or researching to
+      outreach through the status door, with its expected status. A reply
+      stops the cadence: a reply is an inbound message after our last
+      outbound one in the channel, and "Follow up on leads in outreach"
+      reads it and proposes the next step.
+    subjectProfile:
+      profileSlug: lead
+      statusProperty: leadStage
+    activators:
+      # Weekdays 07:00 UTC, one batch over the leads in outreach.
+      - { on: schedule, cron: "0 7 * * 1-5", status: outreach, mode: propose }
+      - { on: manual, mode: propose }
+    executor: is-agent
+    status: active
+    expectedOutputs:
+      # Proposed messages on the people's channels (see "Draft a first message").
+      - { kind: messaging, label: Proposed follow-ups, relationToSubject: none }
+    stages:
+      - key: draft
+        name: Draft due follow-ups
+        category: started
+        goal: Read the channels of the leads in outreach; summarise each reply and propose its next step; for each due lead with no reply, draft one follow-up as a proposed message through messaging.send to the person (never a tool's own send verb, never an outreach touch or synap_capture), setting the lead's nextAction to send it and nextActionAt to today; a lead who replied, or was already sent two follow-ups, gets none.
+        criteria:
+          - key: followup-history-read
+            statement: Each draft reflects what was already sent to that lead and any reply, read from its channels.
+            check: { kind: judge }
+          - key: followup-angle
+            statement: Each draft follows the angle of the lead's outreach campaign and its call to action.
+            check: { kind: judge }
+          - key: followup-no-draft-after-reply
+            statement: No message is drafted for a lead who replied (its reply is summarised and a next step proposed, no deal opened), nor a third follow-up for a lead already sent two.
+            check: { kind: judge }
+          # A judge, not an exact check: see "first-message-one-draft" in
+          # "Draft a first message" for what the pod lacks.
+          - key: followup-draft-rules
+            statement: Each draft is a proposed message filed through messaging.send to the person written to and waits in their channel; no tool's own send verb was called, no outreach touch, note or task holds a message, and no record was made with synap_capture.
+            check: { kind: judge }
+          - key: followup-next-action
+            statement: Every lead with a draft has nextAction to send it and nextActionAt today.
+            check: { kind: judge }
+      - key: send
+        name: Person sends
+        category: completed
+        goal: >-
+          The person reviews each proposed message in its channel, edits it if needed and approves it, and the pod sends it; then set each lead's lastContactedAt to the sent day and, after the first follow-up, nextAction "Follow up with <name> a last time if no reply" and nextActionAt the sent day + 7 days; after the second follow-up, nextAction "No reply after two follow-ups: nurture or drop <name>" and nextActionAt the sent day + 7 days.
+        gate: { kind: human }
+        onFail: { toStage: draft }
+
+  # ── Personalized Outreach — a campaign process (folded from Outreach & Comms) ─
+  # Runs one OUTREACH campaign (a `campaign` with campaign-type outreach: the
+  # angle) through campaign-status planning → active → completed, the same
+  # lifecycle marketing's "Run a campaign" follows (workers are per space, so a
+  # campaign created here starts this process, one created in Marketing starts
+  # that one). It drafts the FIRST message for each person; the next ones are
+  # "Follow up on leads in outreach"'s, which also reads the replies.
+  # Each first message is a proposed message in the person's channel, filed
+  # through the pod's send door `messaging.send` (2026-11-02, decisions d1/d6).
+  # Changed in the fold (2026-10-23): the agent never sends (no send grant; the
+  # person approves each proposed message), people are linked with
+  # `member_of` (Outreach & Comms' `targets` twin is gone), and the campaign's
+  # result is counted in booked meetings, never in deals the agent opened.
+  - name: Personalized Outreach
+    description: Run one outreach campaign — write the angle and its offer, pick the people, draft one personal first message each as a proposed message in their channel; a person approves the list, then approves each message, which the pod sends.
+    goalTemplate: >-
+      Run this outreach campaign ({campaign}) on {channel}; each stage moves
+      its status. If its type is not outreach, stop and say so. PREPARE: write
+      the target audience, the value proposition and the call to action. Pick
+      the people to reach from the pod (and public sources when the pod has
+      too few), resolving each one before creating anything, link each as a
+      member of the campaign with the lead role (lead source cold-outreach
+      when it has none), and for each draft one first message to that person
+      in this campaign's angle, specific to them — their company, role and
+      any past message — never a generic template. DRAFT RULES: each draft is
+      one proposed message in the channel of the person it is written to,
+      filed through the pod's send door: run messaging.send with to = that
+      person's entity id (for a company lead, its decider: when that person
+      is not in the pod, create them through the entity door with only their
+      own fields, such as name, role and LinkedIn URL, never the company's
+      website, domain or email), text = the message, and provider linkedin
+      or email. Read their channel first (synap_get_channel, mode person) for
+      what was already said. The pod files it for a person to review in that
+      channel; it goes out only once they approve it. Never call a tool's own
+      send verb (Unipile, Gmail), never create an outreach touch, a note or a
+      task holding the message, and never use synap_capture for it. Never
+      send.
+      A LinkedIn message is drafted whatever their reach: the pod holds a
+      draft to someone who is not a connection yet, shows it with the next
+      step and lets it go out once they connect, so never hold a draft back
+      for want of a connection. Draft it, then, in this order: (1) a person
+      with no linkedinUrl: find their profile with linkedin_find_profile
+      (their full name and company); on a match, propose its linkedinUrl and
+      linkedinProviderId on the person for a person to approve; on none or
+      several, ask the person to choose among its candidates (the process
+      "Find their LinkedIn" does this for one lead). (2) Read their
+      linkedinConnection, which only the pod writes (never set it or
+      linkedinInvitedAt): connected, nothing more; none or not set, ask to
+      connect with linkedin_send_invite (it refuses someone already connected
+      or already invited: then nothing more); pending, the draft waits for
+      them; ignored, draft by email instead when they have an email address.
+      While the draft waits for them to connect, set the lead's nextAction to
+      "Wait for <name> to accept the LinkedIn request" and its nextActionAt 7
+      days later. An email message needs none of this. START: a person approves the audience, the offer and
+      the list,
+      then reviews each proposed message in its channel and approves it;
+      nothing goes out before they approve it, and the agent never sends.
+      Once a message is sent, follow the cadence, so "Follow up on leads in
+      outreach" drafts the next one. CADENCE: when a message is sent (a
+      person approved its proposed message, so it is an outbound message in
+      the channel), set its lead's lastContactedAt to the sent day, count
+      the messages sent to the lead (the outbound messages in its channels,
+      read with synap_get_channel mode person: for a company lead, the
+      channels of the person written to there), and set the lead's next
+      action: after the first message, nextAction "Follow up with <name> if
+      no reply" and nextActionAt the sent day + 3 days; after the first
+      follow-up, nextAction "Follow up with <name> a last time if no reply"
+      and nextActionAt the sent day + 7 days; after the second follow-up,
+      nextAction "No reply after two follow-ups: nurture or drop <name>" and
+      nextActionAt the sent day + 7 days, and when that date passes with no
+      reply, "Follow up on leads in outreach" proposes nurturing. Never a
+      third follow-up. Propose moving a lead at new or researching to
+      outreach through the status door, with its expected status. A reply
+      stops the cadence: a reply is an inbound message after our last
+      outbound one in the channel, and "Follow up on leads in outreach"
+      reads it and proposes the next step. FINISH: when every person written
+      to has replied or their follow-ups ended in silence, record in the
+      campaign notes how many messages were sent (the outbound messages in
+      their channels), how many got a reply and how many led to a booked
+      meeting. Pausing or cancelling is a person's call.
+    subjectProfile:
+      profileSlug: campaign
+      statusProperty: campaign-status
+    humanOnlyStatuses: [paused, cancelled]
+    activators:
+      - { on: created, mode: propose }
+    params:
+      - { name: campaign, type: entity, label: Outreach campaign, required: true }
+      - { name: channel, type: choice, label: Channel, options: [linkedin, email], defaultValue: linkedin }
+    executor: is-agent
+    status: active
+    requiredIntents: [find_people, enrich_entity]
+    grants: [entity.create]
+    expectedOutputs:
+      # Proposed messages on the members' channels (see "Draft a first message").
+      - { kind: messaging, label: Proposed first messages, relationToSubject: none }
+    stages:
+      - key: prepare
+        name: Prepare
+        category: planned
+        subjectStatus: planning
+        goal: Write the audience, value proposition and call to action; pick the people; draft one first message each as a proposed message in their channel (messaging.send).
+        criteria:
+          - key: outreach-offer
+            statement: The target audience, value proposition and call to action are written on the campaign.
+            check: { kind: judge }
+          - key: outreach-personal
+            statement: Every drafted message names something specific to its person.
+            check: { kind: judge }
+      - key: start
+        name: Person approves the list
+        category: started
+        subjectStatus: active
+        goal: A person approves the audience, offer and list; then the person approves each proposed message in its channel, and the pod sends it.
+        gate: { kind: human }
+        onFail: { toStage: prepare }
+        indefinite: true
+      - key: finish
+        name: Finish
+        category: completed
+        subjectStatus: completed
+        goal: Record how many messages were sent, how many got a reply and how many led to a booked meeting.
+        criteria:
+          - key: outreach-reply-rate
+            statement: The campaign notes record how many messages were sent, replied to, and led to a booked meeting.
+            check: { kind: judge }
+
+  # ── Read the reply to an outreach message — one message's process ─────────
+  # Was Outreach & Comms' "Send an outreach message" (folded 2026-10-23). The
+  # agent no longer sends: the run starts once a PERSON marked the message
+  # sent (`sent` is humanOnly on the lifecycle), and it only watches.
+  # LEGACY SCOPE (send door, 2026-11-02): it watches only the outreach touches
+  # a person marked sent; a message sent from a channel (messaging.send) is no
+  # touch, and its reply is read by "Follow up on leads in outreach". It
+  # retires with the outreach-touch kind once the touches are moved into their
+  # channels (decision d5). It is the reader of a reply to a touch: a
+  # positive reply proposes the next step (the
+  # free estimate or a meeting) and never opens a deal (a deal exists only once
+  # a person records a booked meeting). The next message after silence is
+  # "Follow up on leads in outreach"'s, never this run's. `mode: run`: it
+  # cannot send or commit anything, and its done/lost moves are proposed.
+  # Next action (CRM review 2026-10-27): the next step it proposes after a
+  # reply, and the new way to reach someone after a bounce, are written on the
+  # lead facet as `nextAction` + `nextActionAt`, not only in the summary: the
+  # CRM app's lead page shows the next action, and a process that leaves a
+  # lead open without one leaves the person with nothing to do.
+  # No response (founder decision 2026-10-27): the lead's next action date,
+  # set by the CADENCE (3 days after the first message, 7 days after each
+  # follow-up), passing in silence; after the second follow-up this run also
+  # proposes nurturing, since no third follow-up is ever drafted.
+  - name: Read the reply to an outreach message
+    description: Once a person has marked an outreach touch sent (messages recorded before the channels), watch for the reply; summarise it and propose the next step — the free estimate or a meeting — and never open a deal.
+    goalTemplate: >-
+      Watch this sent outreach message ({touch}) for a reply; each stage
+      moves its status. WAIT: watch its conversation. Set it bounced when it
+      did not reach the person, or no response when its lead's next action
+      date passes with no reply; that date is the cadence's (the sent day + 3
+      days after the first message, the sent day + 7 days after each
+      follow-up), so when the lead has none, count from this message's sent
+      date. The next message is drafted by "Follow up on leads in outreach",
+      not here. When this message is the second follow-up (the third message
+      sent to the lead) and its date passes with no reply, mark it no
+      response and propose moving the lead to nurturing through the status
+      door, with its expected status; there is never a third follow-up.
+      REPLIED: its
+      check reads the reply. Summarise it for a person. When they show
+      interest, propose the next step — prepare the free estimate ("Prepare a
+      pre-sale estimate") or book a meeting — and propose moving the lead to
+      engaged; when they decline, propose nurturing or disqualified with their
+      reason (in `disqualificationReason`). Unless you propose dropping them,
+      write the next step you propose on the lead as `nextAction`, one
+      imperative line (e.g. "Book a meeting with Ana"; "Check in again" for
+      nurturing), and `nextActionAt`, the date they named or today; never
+      leave it only in the summary. BOUNCED: set
+      the lead's `nextAction` to find another way to reach them and
+      `nextActionAt` to today. Never open a deal: a deal is opened only when a
+      person records a booked meeting. Never answer the reply yourself; a
+      person does. Opened is recorded by a person.
+    subjectProfile:
+      profileSlug: outreach-touch
+      statusProperty: status
+    humanOnlyStatuses: [drafted, sent, opened]
+    activators:
+      - { on: enters_status, status: sent, mode: run }
+    params:
+      - { name: touch, type: entity, label: Outreach message, required: true }
+    executor: is-agent
+    status: active
+    stages:
+      - key: wait
+        name: Waiting for a reply
+        category: started
+        goal: Watch the conversation for a reply, a bounce, or the follow-up date passing in silence.
+        indefinite: true
+        criteria:
+          - key: touch-reply-recorded
+            statement: A reply from the person is recorded in the conversation.
+            check: { kind: judge }
+      - key: replied
+        name: Replied
+        category: completed
+        subjectStatus: replied
+        goal: Summarise the reply for a person and propose the next step — the free estimate or a meeting; never open a deal.
+        gate: { kind: check }
+        onFail: { toStage: wait }
+        criteria:
+          - key: touch-next-step-proposed
+            statement: The reply is summarised, a proposed next step (other than a drop) is the lead's nextAction with a nextActionAt, and no deal was opened.
+            check: { kind: judge }
+      - key: bounced
+        name: Bounced
+        category: canceled
+        subjectStatus: bounced
+        goal: The message did not reach the person; note why on the message, and set the lead's nextAction to find another way to reach them, with nextActionAt today.
+      - key: no-response
+        name: No response
+        category: canceled
+        subjectStatus: no_response
+        goal: The lead's next action date passed with no reply; note it on the message, and after the second follow-up propose moving the lead to nurturing.
+
+  # ── Prepare a pre-sale estimate ──────────────────────────────────────────
+  # CRM build plan A7 (founder Q8). A free one-page estimate for a lead,
+  # before any deal. Generic: written in the lead's language and the company's
+  # voice, from the offers in Foundation; amounts come from the pod's own won
+  # deals for that offer or from the approver, never invented; the approver is
+  # the pod's owner. After approval a person sends it, and the SENT step records
+  # the date and the channel on the lead (`estimateSentAt`,
+  # `estimateSentChannel`, above). A lifecycle READER: it never moves the lead.
+  - name: Prepare a pre-sale estimate
+    description: Write a free one-page estimate for a lead from sourced facts and the company's own offers; the pod's owner approves it, a person sends it, and the date and channel it went out on are recorded on the lead.
+    goalTemplate: >-
+      Prepare a free pre-sale estimate for {lead}. Form answers, if any:
+      {formAnswers}. RESEARCH: from the pod and public sources only (their
+      website, company page, job posts, public posts), write what the company
+      does, its size, the tools it uses and where its time goes; cite the
+      source of every fact and leave out anything you cannot verify. ESTIMATE:
+      one page in the lead's language and the company's voice from Foundation
+      (outcomes for the buyer, no jargon), in six blocks: 1) what we
+      understood, in 3 to 5 lines they can correct; 2) where their time and
+      money go today; 3) what we would do, from the company's offers in
+      Foundation, never an offer it does not have; 4) what it would gain them,
+      as a RANGE with every assumption written next to it, never a single
+      promised number; 5) scope, timeline and price: the offer's price model,
+      with amounts from the company's past won deals for that offer, else left
+      blank for the approver to set, never invented; 6) the next step.
+      APPROVE: the pod's owner approves the estimate before it goes anywhere;
+      nothing is sent without that yes. SENT: once a person has sent it,
+      record on the lead the date and the channel it went out on, and its last
+      contacted date.
+    subjectProfile:
+      profileSlug: lead
+    activators:
+      - { on: manual, mode: propose }
+    params:
+      - { name: lead, type: entity, label: Lead, required: true }
+      - { name: formAnswers, type: text, label: What they wrote in the website form (empty for outbound), default: "" }
+    executor: is-agent
+    status: active
+    requiredIntents: [search_external]
+    stages:
+      - key: research
+        name: Research
+        category: planned
+        goal: Gather sourced facts about the company — what it does, its size, its tools, where its time goes.
+        criteria:
+          - key: estimate-facts-sourced
+            statement: Every fact about the company names its source, and nothing unverified is presented as true.
+            check: { kind: judge }
+      - key: draft
+        name: Draft the estimate
+        category: started
+        goal: Write the one-page estimate in its six blocks, with ranges and their assumptions, from the company's own offers.
+        expectedOutputs:
+          - { kind: document, label: Pre-sale estimate, relationToSubject: relates_to }
+        criteria:
+          - key: estimate-six-blocks
+            statement: The estimate has all six blocks, in the lead's language.
+            check: { kind: judge }
+          - key: estimate-ranges
+            statement: The gain is a range with its assumptions written next to it, and every price comes from an offer and a past won deal or is left blank.
+            check: { kind: judge }
+      - key: approve
+        name: Owner approves
+        category: started
+        goal: The pod's owner reads the estimate and approves it for sending, or sends it back with corrections.
+        gate: { kind: human }
+        onFail: { toStage: draft }
+      - key: sent
+        name: Sent
+        category: completed
+        goal: A person sends the approved estimate and says when and on which channel; record both on the lead with its last contacted date.
+        gate: { kind: human }
+        criteria:
+          - key: estimate-sent-recorded
+            statement: The lead records the date and the channel the estimate was sent on.
+            check: { kind: judge }
+
+# The lead requirement keeps "Qualify a lead" out of plain person/company
+# records (rendered by CRM and Browser through the shared entity-action runner).
+actionPlacements:
+  - profileSlug: person
+    surface: entity-detail
+    kind: playbook
+    ref: Qualify a lead
+    label: Qualify lead
+    when: { requiredFacetSlugs: [lead] }
+
+  - profileSlug: company
+    surface: entity-detail
+    kind: playbook
+    ref: Qualify a lead
+    label: Qualify lead
+    when: { requiredFacetSlugs: [lead] }
+
 # 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
 # missing key fails gracefully per-skill, not the whole workspace.
 integrations:
   - templateKey: apify
+  # Folded from Outreach & Comms (2026-10-23): LinkedIn (Unipile) and email
+  # (Google) are the accounts people are written to from. The CRM processes
+  # never call their send verbs: every message goes through the pod's send
+  # door (messaging.send, a proposed message the person approves), and the
+  # pod's messaging webhook and history import record LinkedIn messages in the
+  # people's channels (2026-11-02; they replace the CRM's LinkedIn ingest).
+  - templateKey: unipile-linkedin
+  - templateKey: nango-google
+
+# ── taskIntents — WHAT THIS WORKSPACE NEEDS TO FUNCTION ───────────────────
+# Closed vocabulary: `@synap-core/types/capability-intents` (pod migrations
+# 0283/0284). DERIVED from the declared intents of this template's own
+# `integrations` capability packs — not hand-guessed. Checked at authoring
+# time by `validateTemplate` (`task-intent-unknown`) and by
+# `src/task-intents.test.ts`.
+taskIntents:
+  - search_external
+  - fetch_record
+  - list_records
+  - run_external_job
+  - capture_into_pod
+  - enrich_entity
+  # From unipile-linkedin and nango-google (folded from Outreach & Comms).
+  # send_message: the pod's own send door (Synap Core's messaging.send) and
+  # Gmail; Unipile's send verbs no longer serve it (decision d6, 2026-11-02).
+  - connect_account
+  - send_message
+  - request_connection
+  - find_people
+  - schedule_event
+  - manage_file