@synap-core/workspace-templates 0.7.3 → 0.8.0

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@synap-core/workspace-templates",
-  "version": "0.7.3",
+  "version": "0.8.0",
   "type": "module",
   "packageManager": "pnpm@9.15.4",
   "description": "Canonical workspace definitions — YAML source + typed exports for browser, backend, CLI, and marketplace",

package/src/crm.yaml

@@ -108,6 +108,11 @@ profiles:
     description: An organisation being qualified or sold to.
     scope: WORKSPACE
     properties:
+      - slug: contextSummary
+        label: Context
+        valueType: string
+        inputType: textarea
+        placeholder: The AI-maintained one-paragraph summary of who this client is and where they stand.
       - slug: website
         label: Website
         valueType: string
@@ -178,6 +183,17 @@ profiles:
           - won
           - lost
           - inactive
+      - slug: commercialStage
+        label: Commercial stage
+        valueType: string
+        inputType: select
+        enumValues:
+          - draft
+          - proposed
+          - negotiating
+          - won
+          - lost
+        constraints: { defaultValue: draft }
       - slug: valueType
         label: Value type
         valueType: string

package/src/enterprise-os.yaml

@@ -48,6 +48,10 @@ dependencies:
     kind: workspace
     relation: require
     reason: "The pipeline — contacts, leads, clients, and deals."
+  - slug: business-developer
+    kind: workspace
+    relation: require
+    reason: "The lead-first sales motion (crm-lead/crm-client roles, commercial proposals, commission handoff) that the CRM app runs on. Composes onto the CRM workspace above — without it the CRM lens is provisioned with pod-wide lead/client only and the app's pipeline is empty."
   - slug: content-os
     kind: workspace
     relation: require

package/src/networking.yaml

@@ -0,0 +1,597 @@
+# Networking — the BD-middleman overlay on the CRM workspace.
+# =========================================================================
+# The Arch sits between clients: client A has a NEED, client B has a
+# CAPABILITY (a `solution-provider` role), and The Arch brokers the INTRO and
+# bills the match as a deal. This is an ADDITIVE overlay on the CRM workspace —
+# it reuses CRM's `company`/`deal`/`client` vocabulary and layers three things:
+#
+#   • need              — KIND: the client's stated ask (the demand side).
+#   • intro             — KIND: the brokerage artifact (the match + its fee).
+#   • solution-provider — FACET (role on company/person): the supply side.
+#
+# KIND vs FACET rationale (applied rigorously):
+#   - `need` is a KIND: it is a thing with its own independent life — a status
+#     that moves (open → matching → intro-made → satisfied), a requester, an
+#     evidence trail. It is NOT a hat a company wears; it is authored, tracked,
+#     and retired on its own timeline. So it is a primary kind, never a facet.
+#   - `intro` is a KIND for the same reason `deal` is: it is a relationship-thing
+#     (requester × provider × need × stage × fee) with its own life and its own
+#     board. It cannot be a facet of any single entity — it spans two companies.
+#   - `solution-provider` is a FACET (profileKind: role): "being a provider of
+#     X" is a HAT an existing company or person wears. The Arch must NOT spin up
+#     a second entity for a firm it already knows as a company/client — it
+#     resolves identity first, then attaches this role. It carries no independent
+#     identity, it cascades with the parent company, and graph edges link the
+#     PARENT company (introduced_provider), not the facet. Mirrors the web3 role
+#     facets in blockchain-ecosystem.yaml (market-maker / security-auditor / …).
+#
+# SHARED-ROLE SSOT: `solution-provider` is a networking-specific role with a
+# single consumer (this template). Following the blockchain-ecosystem precedent
+# — where market-maker / security-auditor / dev-shop are `scope: shared` roles
+# OWNED by their domain template, not foundation — it is declared ONCE here as
+# `scope: shared`, `profileKind: role`. foundation.yaml is the SSOT only for the
+# CROSS-CUTTING roles that many templates reuse (client / partner / lead /
+# churned / sponsor); a single-consumer domain role belongs with its domain, and
+# a single declaration cannot drift, so it is NOT added to foundation and NOT
+# re-declared anywhere else. (The shared-role-ssot tripwire polices rows (b)/(c)
+# per profile slug and rule (d) applicableKinds — a lone consistent declaration
+# passes all of them.)
+
+meta:
+  slug: networking
+  domain: revenue
+  name: Networking
+  description: "The BD-middleman layer over your CRM — capture client needs, keep a roster of solution providers, and broker the intros that connect demand to supply."
+  icon: waypoints
+  color: "#6366F1"
+  tags: [networking, business-development, matchmaking, intros, middleman]
+  isPublic: true
+
+# OVERLAY on CRM — composes additively onto the CRM workspace (no separate
+# workspace is created); subtype MATCHES the compose base (`crm`, a no-op on the
+# additive reconcile) and visibility is OMITTED so the base CRM keeps its own
+# identity. `require foundation` (deps-first) guarantees the pod-wide role
+# vocabulary CRM reuses is seeded before this overlay lands — mirroring
+# grants.yaml's compose-base + require-foundation dependency shape.
+dependencies:
+  - slug: crm
+    kind: workspace
+    relation: compose
+    reason: "Adds a needs → intros brokerage workflow onto your CRM workspace."
+  - slug: foundation
+    kind: workspace
+    relation: require
+    reason: "Provides the pod-wide client/partner role vocabulary the CRM base reuses."
+
+workspace:
+  name: Networking
+  description: "A brokerage workspace layered on your CRM — client needs, a provider roster, and the intros that connect them."
+  proposalId: networking-v1
+  subtype: crm
+
+profiles:
+  # ── Need (KIND) — the demand side: a client's stated ask ───────────────────
+  - slug: need
+    displayName: Need
+    icon: target
+    color: amber
+    description: A client's stated ask — the demand The Arch brokers a provider against.
+    scope: WORKSPACE
+    properties:
+      - slug: needStatus
+        label: Status
+        valueType: string
+        inputType: select
+        enumValues: [open, matching, intro-made, satisfied, dropped]
+        constraints: { defaultValue: open }
+      - slug: domain
+        label: Domain
+        valueType: string
+        inputType: text
+        placeholder: The area of the ask — e.g. market-making, audit, design.
+      - slug: urgency
+        label: Urgency
+        valueType: string
+        inputType: text
+      - slug: budgetRange
+        label: Budget Range
+        valueType: string
+        inputType: text
+      - slug: requesterCompanyId
+        label: Requester
+        valueType: entity_id
+        inputType: entity_select
+        targetProfileSlug: company
+      # The A↔B FIREWALL control. `confidential` (the default) keeps a need OUT
+      # of the match roster entirely — only `shareable` needs may be surfaced to
+      # a provider match. Defaulting to confidential means a need is private
+      # until a human explicitly opens it up.
+      - slug: confidentiality
+        label: Confidentiality
+        valueType: string
+        inputType: select
+        enumValues: [shareable, confidential]
+        constraints: { defaultValue: confidential }
+      - slug: evidenceQuote
+        label: Evidence Quote
+        valueType: string
+        inputType: textarea
+        placeholder: The client's own words that captured this need.
+      - slug: sourceMessageId
+        label: Source Message ID
+        valueType: string
+        inputType: text
+      - slug: notes
+        label: Notes
+        valueType: string
+        inputType: textarea
+
+  # ── Intro (KIND) — the brokerage artifact: the match + how it bills ────────
+  - slug: intro
+    displayName: Intro
+    icon: waypoints
+    color: violet
+    description: The middleman brokerage artifact — connects a requester to a provider for a need, and bills the match as a deal.
+    scope: WORKSPACE
+    properties:
+      - slug: introStage
+        label: Stage
+        valueType: string
+        inputType: select
+        enumValues: [identified, proposed, approved, introduced, in-discussion, signed, dead]
+        constraints: { defaultValue: identified }
+      - slug: requesterCompanyId
+        label: Requester
+        valueType: entity_id
+        inputType: entity_select
+        targetProfileSlug: company
+      - slug: providerCompanyId
+        label: Provider
+        valueType: entity_id
+        inputType: entity_select
+        targetProfileSlug: company
+      - slug: needId
+        label: Need
+        valueType: entity_id
+        inputType: entity_select
+        targetProfileSlug: need
+      # ── Fee vocabulary — REUSED VERBATIM from business-developer.yaml's `deal`
+      # commercial contract, so an intro bills exactly like a CRM deal does. ──
+      - slug: synapFeeModel
+        label: Synap fee model
+        valueType: string
+        inputType: select
+        enumValues: [fixed, success_fee]
+      - slug: synapSuccessFeeRate
+        label: Synap success fee rate
+        valueType: number
+        inputType: number
+      - slug: synapFixedFee
+        label: Synap fixed fee
+        valueType: number
+        inputType: number
+      - slug: expectedClientGain
+        label: Expected client gain
+        valueType: number
+        inputType: number
+      - slug: synapFeeAmount
+        label: Synap fee amount
+        valueType: number
+        inputType: number
+      - slug: sourcedByUserId
+        label: Sourced by user ID
+        valueType: string
+        inputType: text
+      - slug: commissionStatus
+        label: Commission status
+        valueType: string
+        inputType: select
+        enumValues: [estimated, earned, paid, requires_review, void]
+      - slug: introducedAt
+        label: Introduced at
+        valueType: date
+        inputType: date
+      - slug: outcome
+        label: Outcome
+        valueType: string
+        inputType: textarea
+      - slug: deadReason
+        label: Dead reason
+        valueType: string
+        inputType: textarea
+
+  # ── Solution Provider (FACET) — the supply side: a role on company/person ──
+  # `scope: shared`, `profileKind: role` — the ONE pod-wide row for "is a
+  # provider of some capability". Attached to the EXISTING company/person via
+  # FacetRepository; never a second entity. Mirrors blockchain-ecosystem's role
+  # facets. applicableKinds is required (rule (d) of the shared-role tripwire).
+  - slug: solution-provider
+    displayName: Solution Provider
+    icon: handshake
+    color: teal
+    description: A company or person that provides a capability The Arch can broker a client need against.
+    scope: shared
+    profileKind: role
+    applicableKinds:
+      - company
+      - person
+    properties:
+      - slug: status
+        label: Status
+        valueType: string
+        inputType: select
+        enumValues: [prospect, active, paused, churned]
+      - slug: domains
+        label: Domains
+        valueType: array
+        inputType: text
+        placeholder: The capability areas this provider covers.
+      - slug: capacity
+        label: Capacity
+        valueType: string
+        inputType: text
+      - slug: pricingNotes
+        label: Pricing Notes
+        valueType: string
+        inputType: textarea
+      - slug: geography
+        label: Geography
+        valueType: string
+        inputType: text
+      - slug: notes
+        label: Notes
+        valueType: string
+        inputType: textarea
+
+# Relations. `company`/`deal` resolve from the CRM compose base (not redeclared);
+# `need`/`intro` are this overlay's own kinds. The graph links the PARENT company
+# on both sides of an intro — a facet is never a link endpoint.
+entityLinks:
+  - sourceProfileSlug: need
+    targetProfileSlug: company
+    type: needed_by
+    label: Needed by
+  - sourceProfileSlug: intro
+    targetProfileSlug: need
+    type: resolves
+    label: Resolves
+  - sourceProfileSlug: intro
+    targetProfileSlug: company
+    type: introduced_requester
+    label: Requester
+  - sourceProfileSlug: intro
+    targetProfileSlug: company
+    type: introduced_provider
+    label: Provider
+  - sourceProfileSlug: intro
+    targetProfileSlug: deal
+    type: billed_as
+    label: Billed as
+
+# Curated views — the two boards of the brokerage motion plus the provider roster.
+views:
+  - name: Needs
+    slug: needs
+    type: kanban
+    scopeProfileSlug: need
+    description: Client needs on a board by status — open demand waiting for a match.
+    config:
+      groupByField: needStatus
+  - name: Intros
+    slug: intros
+    type: kanban
+    scopeProfileSlug: intro
+    description: Brokered intros on a board by stage — from identified match to signed.
+    config:
+      groupByField: introStage
+  - name: Providers
+    slug: providers
+    type: table
+    scopeProfileSlug: solution-provider
+    description: The solution-provider roster — companies wearing the provider role, by status.
+    config:
+      columns: [title, status, domains, geography, capacity]
+
+# ============================================================================
+# Intro Matcher automation — the daily demand↔supply match.
+#
+# WHAT: once a day, enumerate the SHAREABLE open needs, and for each one match
+# it against the solution-provider roster with ONE batched AI call, propose a
+# governed `intro`, and post a match brief to The Arch's INTERNAL team channel.
+#
+# A↔B FIREWALL (never bend):
+#   • Only `confidentiality: shareable` needs enter the roster — the query
+#     filters on it, so a confidential need is never even read into a match.
+#   • The brief posts to a `team`-purpose channel (branchPurpose: team) — The
+#     Arch's INTERNAL artifact channel — resolved from the REQUESTER COMPANY
+#     (client A, the need's owner), which owns a team channel bound at onboarding.
+#     That is The Arch's internal thread for client A, NOT a client-comms channel
+#     and NEVER client B's (the provider's) channel. It does not land in any
+#     client-facing channel. (It cannot resolve from the just-proposed intro
+#     entity: channel.resolve is a read-only FIND and the intro has no channel
+#     bound to it yet, so that returned null and the brief never posted.)
+#   • The matcher prompt forbids drafting anything for a client's own channel
+#     and forbids revealing one client's need to another client.
+#
+# GOVERNANCE: the two read builtins (`entity.query`, `channel.resolve`) and the
+# `ai.generate` digest are READ-ONLY and auto-run; the single WRITE is an
+# `output/entity_create` (returns `proposed`, never throws; `entity.create` is
+# auto-approved for an owner/agent run) — mirrors operations.yaml's daily
+# briefing exactly.
+#
+# NOTE on the query lens: `entity.query`'s DEFAULT lens already reads pod-wide ∪
+# workspace, so needs (workspace-scoped) and providers (pod-wide shared role)
+# both resolve WITHOUT a `scope: pod` opt-in. `need` is this template's own
+# profile, so `assertKnownProfileSlug` cannot fail the first node.
+# ============================================================================
+automations:
+  - key: networking-intro-matcher
+    name: Intro Matcher
+    description: >-
+      Once a day, match each shareable open client need against the
+      solution-provider roster, propose an intro for the best fit, and post a
+      match brief to The Arch's internal team channel — never to a client's own
+      channel.
+    triggerType: cron
+    triggerConfig:
+      expression: "0 9 * * *"
+    status: active
+    metadata:
+      templateKey: networking-intro-matcher
+    flow:
+      nodes:
+        - id: trigger
+          type: trigger
+          position: { x: 0, y: 0 }
+          data:
+            label: Daily at 09:00
+            triggerType: cron
+            config:
+              expression: "0 9 * * *"
+
+        # READ-ONLY builtin. Enumerates ONLY shareable open needs — the firewall
+        # filter lives here, so a confidential need is never read into a match.
+        - id: list-needs
+          type: capability
+          position: { x: 0, y: 120 }
+          data:
+            label: List shareable open needs (FIREWALL filter)
+            verbId: entity.query
+            inputMapping:
+              profileSlug: need
+              filter:
+                needStatus: open
+                confidentiality: shareable
+              limit: "100"
+
+        # READ-ONLY builtin. The provider roster to match against — companies /
+        # people wearing the pod-wide `solution-provider` role.
+        - id: list-providers
+          type: capability
+          position: { x: 0, y: 240 }
+          data:
+            label: List the solution-provider roster
+            verbId: entity.query
+            inputMapping:
+              profileSlug: solution-provider
+              limit: "100"
+
+        - id: needs-loop
+          type: loop
+          position: { x: 0, y: 360 }
+          data:
+            label: For each shareable open need
+            iteratorExpression: steps.list-needs.output.entities
+            itemVariable: need
+
+        # READ-ONLY builtin (pure compute — auto-runs). ONE batched match call
+        # per need against the whole roster. Returns STRICT JSON naming the best
+        # provider (by entity id) or none.
+        - id: match
+          type: capability
+          position: { x: 0, y: 480 }
+          data:
+            label: Match this need to the roster → JSON
+            verbId: ai.generate
+            inputMapping:
+              json: "true"
+              maxTokens: "800"
+              system: >-
+                You are The Arch's business-development matchmaker. You connect a
+                CLIENT'S NEED to the single best SOLUTION PROVIDER from a roster.
+
+                FIREWALL (never break): your output is a brief for The Arch's
+                INTERNAL team channel ONLY. NEVER draft anything to be sent into a
+                client's own channel, and NEVER reveal one client's need to
+                another client. Do not name the requesting client in any text
+                intended for the provider.
+              prompt: >-
+                The client need:
+                title: {{loop.item.title}}
+                domain: {{loop.item.properties.domain}}
+                urgency: {{loop.item.properties.urgency}}
+                budget: {{loop.item.properties.budgetRange}}
+                detail: {{loop.item.properties.notes}}
+
+                The solution-provider roster (JSON — each has an id, title, and
+                properties incl. domains/geography/capacity):
+                {{steps.list-providers.output.entities}}
+
+                Pick the SINGLE best provider for this need, or none if nothing
+                fits well. Respond with STRICT JSON and NOTHING else:
+                {
+                  "hasMatch": "true" or "false" (a STRING),
+                  "providerEntityId": "<the matched provider's entity id, or empty string>",
+                  "providerName": "<the matched provider's name, or empty string>",
+                  "rationale": "<one or two sentences on why this provider fits, for the internal team>",
+                  "brief": "<a short internal match brief for the team, markdown>"
+                }
+                Set hasMatch to "false" when no provider is a genuine fit.
+
+        # PER-ITEM gate (continue-semantics). Skip the rest of THIS need's body
+        # when no provider fit — no intro, no post. A `condition` (not `switch`)
+        # keeps the loop body a contiguous chain.
+        - id: match-gate
+          type: condition
+          position: { x: 0, y: 600 }
+          data:
+            label: Only continue when there is a real match
+            expression: "steps.match.output.hasMatch === true"
+
+        # GOVERNED WRITE via `output/entity_create` (returns `proposed`, never
+        # throws; `entity.create` is auto-approved for an owner/agent run).
+        # Proposes the intro linking this need's requester to the matched provider.
+        - id: create-intro
+          type: output
+          position: { x: 0, y: 720 }
+          data:
+            label: Propose the intro
+            outputType: entity_create
+            config:
+              profileSlug: intro
+              title: "Intro — {{loop.item.title}} → {{steps.match.output.providerName}}"
+              properties:
+                introStage: identified
+                needId: "{{loop.item.id}}"
+                requesterCompanyId: "{{loop.item.properties.requesterCompanyId}}"
+                providerCompanyId: "{{steps.match.output.providerEntityId}}"
+
+        # READ-ONLY builtin. Resolves the REQUESTER COMPANY's team-side channel
+        # (The Arch's internal artifact channel for that client) — NOT a company
+        # client-comms channel, NEVER the provider's. This is the firewall
+        # boundary: the brief posts internally, never client-facing.
+        - id: resolve-team
+          type: capability
+          position: { x: 0, y: 840 }
+          data:
+            label: Resolve The Arch's internal team channel for the requester (FIREWALL)
+            _note: >-
+              Resolves from the REQUESTER COMPANY, not the intro entity.
+              channel.resolve is a read-only FIND — it never creates. A
+              just-proposed `intro` has no channel bound to it, so resolving from
+              {{steps.create-intro.output.entityId}} returned channelId: null and
+              the brief silently never posted. The requester company is a stable
+              entity that already owns a `team`-purpose channel (bound at
+              onboarding), so we resolve from it instead. Firewall-safe: this is
+              The Arch's INTERNAL team thread for client A (the need's owner), NOT
+              client B's (the provider's) channel and NOT any client-comms channel.
+            verbId: channel.resolve
+            inputMapping:
+              contextObjectType: entity
+              contextObjectId: "{{loop.item.properties.requesterCompanyId}}"
+              branchPurpose: team
+
+        # UNGOVERNED direct insert to the EXPLICIT resolved internal channelId.
+        # Posts the match brief to The Arch's team channel ONLY.
+        - id: post-brief
+          type: output
+          position: { x: 0, y: 960 }
+          data:
+            label: Post the match brief to the INTERNAL team channel (FIREWALL)
+            outputType: channel_message
+            config:
+              channelId: "{{steps.resolve-team.output.channelId}}"
+              content: >-
+                **Match found — {{loop.item.title}} → {{steps.match.output.providerName}}**
+
+                {{steps.match.output.rationale}}
+
+                {{steps.match.output.brief}}
+              metadata:
+                automationMessage: true
+                kind: intro-match
+      edges:
+        - { id: e-trigger-needs, source: trigger, target: list-needs }
+        - { id: e-needs-providers, source: list-needs, target: list-providers }
+        - { id: e-providers-loop, source: list-providers, target: needs-loop }
+        - { id: e-loop-match, source: needs-loop, target: match }
+        - { id: e-match-gate, source: match, target: match-gate }
+        - { id: e-gate-intro, source: match-gate, target: create-intro }
+        - { id: e-intro-resolve, source: create-intro, target: resolve-team }
+        - { id: e-resolve-post, source: resolve-team, target: post-brief }
+
+app:
+  kind: stored
+  cellKey: entity-detail
+
+layout:
+  defaultView: Needs
+  defaultApp: null
+  pinnedApps: [dashboard, data]
+  sidebarItems:
+    - kind: view
+      viewName: Needs
+      label: Needs
+      icon: target
+    - kind: view
+      viewName: Intros
+      label: Intros
+      icon: waypoints
+    - kind: view
+      viewName: Providers
+      label: Providers
+      icon: handshake
+
+bento:
+  viewName: Needs
+  blocks:
+    - kind: view
+      viewName: Needs
+      pos: { x: 0, y: 0, w: 6, h: 5 }
+    - kind: view
+      viewName: Intros
+      pos: { x: 6, y: 0, w: 6, h: 5 }
+
+onboarding:
+  goal: >
+    Capture the two sides of the brokerage — the live client NEEDS and the
+    SOLUTION-PROVIDER roster — so the matcher has real demand and real supply to
+    connect, and every intro traces back to a stated need and a named provider.
+  framing: |
+    THE BD MIDDLEMAN: Act as a sharp business-development broker who lives
+    between clients. One client has a need; another has the capability to meet
+    it; your value is the introduction and the fee on the match. Push for the
+    concrete: whose need is this, how confidential is it, and which real provider
+    can serve it. Tag the provider role onto the REAL company you already know —
+    never a second entity for the same firm.
+  expertise:
+    starters:
+      - >
+        A need has an owner and a confidentiality. Default every need to
+        confidential — it only enters the match roster once a human marks it
+        shareable. Capture whose need it is (the requester company) and, where
+        you can, the client's own words as the evidence quote.
+      - >
+        The provider is a HAT, not a new entity. Attach the solution-provider
+        role to the real company/person you already track (match on domain /
+        name first) — a market of providers is a graph of roles on known
+        companies, not a parallel directory.
+    blindSpots:
+      - >
+        A need with no provider and no status is a wish, not a pipeline. Force
+        the status (open / matching / intro-made) and, once a match exists,
+        broker the intro rather than letting the need sit open.
+      - >
+        The firewall is the product. Never let one client's confidential need
+        leak to another client. If a need is sensitive, keep it confidential —
+        an intro is proposed to the internal team first, never straight to a
+        client's channel.
+    bar: >
+      A workspace with real client needs (each with a requester and a
+      confidentiality), a roster of solution providers tagged onto real
+      companies, and the first intros brokered between them — so a glance shows
+      what demand is open and which providers can serve it.
+  collect:
+    - profileSlug: need
+      what: The live client needs you could broker a provider against.
+      cardinality: several
+      keyFields: [needStatus, domain, requesterCompanyId, confidentiality]
+    - profileSlug: solution-provider
+      what: The solution providers you can connect clients to, tagged onto the real company.
+      cardinality: several
+      keyFields: [status, domains, geography]
+  openingQuestions:
+    - "Which client needs are open right now, and whose needs are they?"
+    - "Which of those needs are shareable, and which must stay confidential?"
+    - "Which solution providers can you connect clients to, and what do they cover?"
+  doneWhen: A few client needs captured with a requester and a confidentiality, a handful of solution providers tagged onto real companies, and at least one intro brokered between them.

package/src/operations.yaml

@@ -355,9 +355,13 @@ automations:
   - key: operations-daily-client-briefing
     name: Daily client briefing
     description: >-
-      Each morning, for every client, distil their recent comms into one
-      batched digest, save it as a durable client-briefing, and post the recap
-      to the client's internal TEAM channel (never the client-facing channel).
+      Operations-native daily client briefing. Writes a durable, dated
+      client-briefing ENTITY per client (queryable history, linked to the
+      client) from their recent comms, and posts the recap to the client's
+      internal TEAM channel (never the client-facing channel). Knowledge-building
+      and entity-first — the delivery OS's structured memory of each client. For
+      a lighter, portable message-only digest installable on any pod, use the
+      client-comms-report capability.
     triggerType: cron
     triggerConfig:
       expression: "0 8 * * *"