@synap-core/workspace-templates 0.7.2 → 0.7.4

package/src/operations.yaml

@@ -5,6 +5,7 @@
 
 meta:
   slug: operations
+  domain: company
   name: Operations
   description: "Deliver client work end to end — the engagements you're running, the deliverables due inside them, and the contracts that govern them. Won deals from CRM hand off into engagements here."
   icon: briefcase
@@ -25,6 +26,19 @@ workspace:
     crm: consumer
     operations: provider
 
+# The daily client-briefing automation below enumerates clients with
+# `entity.query { profileSlug: "client" }`, and that verb FAILS CLOSED on an
+# unknown slug (`assertKnownProfileSlug`) — an Operations workspace installed
+# without the pod-wide `client` role would kill the run on its first node. The
+# `client` role is foundation's SSOT (foundation.yaml, `scope: shared`,
+# `profileKind: role`), so require it, exactly like crm.yaml does. `require`,
+# not `compose`: foundation is a real workspace, not an overlay.
+dependencies:
+  - slug: foundation
+    kind: workspace
+    relation: require
+    reason: "Provides the pod-wide `client` role the daily client-briefing automation queries."
+
 profiles:
   - slug: engagement
     displayName: Engagement
@@ -140,6 +154,65 @@ profiles:
         valueType: string
         inputType: textarea
 
+  # The durable OUTPUT of the daily briefing automation. A recap that only ever
+  # exists as a chat message is not knowledge — it cannot be queried, ranked, or
+  # linked. This kind is what turns the digest into structure: one dated row per
+  # client per run, linked to the client entity and readable long after the
+  # message scrolled away. Written to the TEAM side only; never client-facing.
+  - slug: client-briefing
+    displayName: Client Briefing
+    icon: newspaper
+    color: "#F59E0B"
+    description: "A dated internal recap of one client's recent communications — what moved, what's at risk, what's next. For the team, never for the client."
+    properties:
+      - slug: briefing-client
+        label: Client
+        valueType: entity_id
+        targetProfileSlug: company
+        inputType: entity_select
+      - slug: briefing-date
+        label: Written At
+        valueType: date
+        inputType: date
+      # Idempotency key, NOT display. `output/entity_create`'s `dedupeBy` matches
+      # on this exact value, so a redelivered run reuses the row it already wrote
+      # instead of appending a second briefing for the same client and tick.
+      - slug: briefing-key
+        label: Run Key
+        valueType: string
+        inputType: text
+      - slug: briefing-headline
+        label: Headline
+        valueType: string
+        inputType: text
+      - slug: briefing-summary
+        label: Summary
+        valueType: string
+        inputType: textarea
+      - slug: briefing-risks
+        label: Risks
+        valueType: string
+        inputType: textarea
+      - slug: briefing-next-actions
+        label: Next Actions
+        valueType: string
+        inputType: textarea
+      - slug: briefing-message-count
+        label: Messages Read
+        valueType: number
+        inputType: number
+
+# Schema relations. `briefing_about_client` MUST be declared here: an automation
+# `relation_create` dispatches `graph.link` → `relations.create`, which rejects
+# any type that is neither a system built-in nor a workspace relation def
+# (routers/relations.ts — "Unknown relation type"). The applier find-or-creates
+# the def from this block, so the automation's link resolves.
+entityLinks:
+  - sourceProfileSlug: client-briefing
+    targetProfileSlug: company
+    type: briefing_about_client
+    label: Client
+
 # CURATED views — the delivery motion, not one per profile
 views:
   - name: Engagements
@@ -159,6 +232,11 @@ views:
     type: table
     scopeProfileSlug: contract
     description: "Contracts with their status, value, and term."
+  - name: Client Briefings
+    slug: client-briefings
+    type: list
+    scopeProfileSlug: client-briefing
+    description: "The daily internal recaps, newest first."
 
 onboarding:
   goal: >
@@ -220,3 +298,276 @@ bento:
     - kind: view
       viewName: Contracts
       pos: { x: 6, y: 0, w: 6, h: 5 }
+
+# ============================================================================
+# Automations — the daily client-briefing digest.
+#
+# WHAT: once a day, for every `client`, read that client's inbound comms,
+# distil the real signal with ONE batched AI call (never per-message), persist
+# a durable `client-briefing` row, and post the recap to the client's TEAM-side
+# channel. Firewall: the recap NEVER lands in the client-facing channel.
+#
+# GOVERNANCE DESIGN (why this run cannot die on a `proposed` verdict):
+#   • The three `capability` nodes call ONLY read-only builtins —
+#     `entity.query`, `ai.generate`, `channel.resolve` — all in
+#     READ_ONLY_BUILTIN_VERBS, so the capability gate AUTO-RUNS them (no grant,
+#     no proposal). A `capability` node THROWS on a `proposed` verdict
+#     (automation-executor.ts) — these three can never reach it.
+#   • `messages_query` + `condition` are pure read / pure eval — never governed.
+#   • The two governed WRITES are `output` nodes, NOT `capability` nodes:
+#       – `entity_create` returns `{status:"proposed"}` on a propose verdict
+#         (it never throws), and `entity.create` is in DEFAULT_AUTO_APPROVE, so
+#         a human-owned or agent-owned run auto-approves and writes directly.
+#       – `relation_create` dispatches `graph.link`; the `graph.link` builtin is
+#         seeded `approved:true` (rung 2.7 → auto) and `relation.create` is in
+#         DEFAULT_AUTO_APPROVE, so it auto-executes — never a propose verdict.
+#       – `channel_message` is a direct, firewall-checked insert with NO
+#         governance gate at all.
+#   • Every write also lives INSIDE the loop body, whose per-item try/catch
+#     aborts only THAT client's remaining steps on any error — the RUN itself
+#     survives regardless.
+#
+# `status: active` is load-bearing: the cron scheduler selects
+# `status="active" AND nextRunAt <= now`. A `draft` never fires — that was the
+# exact bug this automation replaces. `metadata.templateKey` makes re-apply
+# idempotent (the post-workspace applier dedups by name / templateKey).
+#
+# ⚠️ KNOWN BLOCKER — RETURNS ZERO CLIENTS UNTIL A BACKEND FIX LANDS.
+# `client`/`company` entities are POD-WIDE (`workspaceId: null`). This automation
+# runs under a WORKSPACE LENS, and `workspaceLensWhere`
+# (`packages/api/src/utils/user-visible-where.ts`) excludes pod-wide globals from
+# a focused workspace by design (`includeGlobals` defaults falsy — product
+# decision 2026-06-15). So the `entity.query` verb — which resolves
+# `input.workspaceId ?? ctx.workspaceId` and CANNOT express a global lens (its
+# param is `workspaceId: uuid().optional()`) — enumerates ZERO clients under the
+# Operations lens. The `list-clients` node is deliberately left with NO
+# workspace override so it starts working the moment the backend fix (let
+# `entity.query` express a pod-wide/global lens → `workspaceLensWhere` with
+# `null`/`includeGlobals:true`) lands. NO workaround is baked in here — a
+# hardcoded client list or a workspace-scoped copy would defeat the point.
+#
+# LIMITATION (honest): `messages_query` resolves ONLY the EXTERNAL client-comms
+# channel bound to the client entity — team-side chatter ABOUT a client is not
+# in the digest input. The recap is intentionally still posted to the TEAM
+# channel; it summarises the client conversation, not internal discussion.
+# ============================================================================
+automations:
+  - key: operations-daily-client-briefing
+    name: Daily client briefing
+    description: >-
+      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 * * *"
+    status: active
+    metadata:
+      templateKey: operations-daily-client-briefing
+      # The `list-clients` node uses `scope: pod` — the entity.query pod-wide
+      # opt-in. That opt-in must be DEPLOYED for the query to return pod-wide
+      # clients; without it a pod-wide client query yields 0 rows and this
+      # automation is a silent no-op (fires on cron, loops over nothing).
+      requiresPodWideEntityQueryLens: true
+    flow:
+      nodes:
+        - id: trigger
+          type: trigger
+          position: { x: 0, y: 0 }
+          data:
+            label: Daily at 08:00
+            triggerType: cron
+            config:
+              expression: "0 8 * * *"
+
+        # READ-ONLY builtin. Enumerates clients by the pod-wide `client` ROLE
+        # (foundation SSOT). `entity.query` fails CLOSED on an unknown slug via
+        # `assertKnownProfileSlug` — the `dependencies: require foundation` block
+        # above guarantees the `client` role exists, so the first node can't die.
+        #
+        # `scope: pod` = the EXPLICIT pod-wide opt-in. `client` entities are
+        # pod-wide (workspaceId:null); a run's workspace lens hides pod-wide
+        # globals by default (workspaceLensWhere, product decision 2026-06-15),
+        # so WITHOUT scope:pod this loops over zero clients. scope:pod pins the
+        # globals-only, owner-gated lens, returning exactly the caller's pod-wide
+        # clients — an explicit request, NOT globals silently bleeding into a
+        # focused workspace. Do NOT "fix" a zero result by hardcoding a client
+        # list or a workspace-scoped profile — scope:pod IS the fix.
+        - id: list-clients
+          type: capability
+          position: { x: 0, y: 120 }
+          data:
+            label: List clients (pod-wide `client` role)
+            verbId: entity.query
+            inputMapping:
+              profileSlug: client
+              scope: pod
+              limit: "100"
+
+        - id: clients-loop
+          type: loop
+          position: { x: 0, y: 240 }
+          data:
+            label: For each client
+            iteratorExpression: steps.list-clients.output.entities
+            itemVariable: client
+
+        # READ. Resolves the client's EXTERNAL client-comms channel bound to the
+        # client entity and returns its recent window. Team-side chatter is NOT
+        # included (see the LIMITATION note above).
+        - id: read-comms
+          type: messages_query
+          position: { x: 0, y: 360 }
+          data:
+            label: Read this client's recent comms
+            subjectEntityId: "{{loop.item.id}}"
+            limit: 40
+
+        # READ-ONLY builtin (pure compute — mutates nothing, auto-runs). ONE
+        # batched digest for the whole window; NO per-message AI. Returns STRICT
+        # JSON whose fields map onto the client-briefing properties below.
+        - id: digest
+          type: capability
+          position: { x: 0, y: 480 }
+          data:
+            label: Distil the real signal → JSON
+            verbId: ai.generate
+            inputMapping:
+              json: "true"
+              maxTokens: "1200"
+              system: >-
+                You advise a client-delivery team. You read one client's recent
+                inbound messages and surface only what genuinely matters. You
+                are firewall-aware: your output is for the INTERNAL team, never
+                the client.
+              prompt: >-
+                Digest the recent communications for the client
+                "{{loop.item.title}}" into a concise internal briefing for OUR
+                delivery team.
+
+                PEOPLE GUARD (do not break): distinguish the CLIENT's people
+                from OUR team members who also appear in the thread. Never treat
+                a teammate as a client contact, lead, or new person. Only real,
+                client-side signal counts.
+
+                Surface ONLY real signal: status changes, decisions,
+                deals/opportunities, competitor mentions, new client-side
+                leads/contacts, risks/blockers, and deadlines/commitments. Skip
+                small talk and noise. Lead with what matters; keep it tight.
+
+                Respond with STRICT JSON and NOTHING else:
+                {
+                  "hasSignal": "true" or "false" (a STRING),
+                  "headline": "<one-line summary; empty string when hasSignal is 'false'>",
+                  "summary": "<a short markdown digest for the team; empty string when 'false'>",
+                  "risks": "<risks/blockers as short markdown, or empty string>",
+                  "nextActions": "<recommended next actions as short markdown, or empty string>"
+                }
+                Set hasSignal to "false" when there is no notable activity (no
+                messages, or only chatter).
+
+                Recent conversation (oldest first, JSON):
+                {{steps.read-comms.output.messages}}
+
+        # PER-ITEM FILTER (continue-semantics). When the digest found no signal,
+        # skip the rest of THIS client's body — no briefing row, no post. A
+        # `condition` node is a loop-body type; a `switch` is NOT (it would break
+        # the loop's contiguous-body chain), so the gate MUST be a `condition`.
+        - id: signal-gate
+          type: condition
+          position: { x: 0, y: 600 }
+          data:
+            label: Only continue when there's real signal
+            expression: "steps.digest.output.hasSignal === true"
+
+        # GOVERNED WRITE via an `output` node (returns `proposed`, never throws;
+        # `entity.create` is auto-approved). Durable, dated log row.
+        # `dedupeBy: briefing-key` makes a redelivered run reuse the same row
+        # instead of appending a duplicate for the same client + tick.
+        - id: write-briefing
+          type: output
+          position: { x: 0, y: 720 }
+          data:
+            label: Save the client briefing
+            outputType: entity_create
+            config:
+              profileSlug: client-briefing
+              title: "Briefing — {{loop.item.title}}"
+              dedupeBy: briefing-key
+              properties:
+                briefing-key: "{{loop.item.id}}::{{trigger.payload.scheduledAt}}"
+                briefing-client: "{{loop.item.id}}"
+                briefing-date: "{{trigger.payload.scheduledAt}}"
+                briefing-headline: "{{steps.digest.output.headline}}"
+                briefing-summary: "{{steps.digest.output.summary}}"
+                briefing-risks: "{{steps.digest.output.risks}}"
+                briefing-next-actions: "{{steps.digest.output.nextActions}}"
+                briefing-message-count: "{{steps.read-comms.output.count}}"
+
+        # GOVERNED WRITE via `output` node → `graph.link` (auto-executes:
+        # builtin approved + relation.create in DEFAULT_AUTO_APPROVE). Links the
+        # briefing to its client. The relation TYPE is declared in `entityLinks`
+        # above, so `relations.create` accepts it instead of "Unknown relation
+        # type". `dedupe` (default) skips a duplicate edge on re-run.
+        - id: link-briefing
+          type: output
+          position: { x: 0, y: 840 }
+          data:
+            label: Link briefing → client
+            outputType: relation_create
+            config:
+              fromEntityId: "{{steps.write-briefing.output.entityId}}"
+              toEntityId: "{{loop.item.id}}"
+              relationType: briefing_about_client
+
+        # READ-ONLY builtin. Resolves the client's TEAM-side channel by
+        # branchPurpose (the firewall ROLE), NOT the client-facing channel.
+        - id: resolve-team
+          type: capability
+          position: { x: 0, y: 960 }
+          data:
+            label: Resolve the client's TEAM channel (FIREWALL)
+            verbId: channel.resolve
+            inputMapping:
+              contextObjectType: entity
+              contextObjectId: "{{loop.item.id}}"
+              branchPurpose: team
+
+        # UNGOVERNED direct insert (firewall-checked mirror). Posts to the
+        # EXPLICIT resolved team channelId — NOT channelType:'subjectEntity',
+        # which needs a run subjectEntityId that CRON runs never carry.
+        - id: post-recap
+          type: output
+          position: { x: 0, y: 1080 }
+          data:
+            label: Post the recap to the TEAM channel (FIREWALL)
+            outputType: channel_message
+            config:
+              channelId: "{{steps.resolve-team.output.channelId}}"
+              content: >-
+                **{{loop.item.title}} — daily briefing**
+
+                {{steps.digest.output.headline}}
+
+                {{steps.digest.output.summary}}
+
+                **Risks:** {{steps.digest.output.risks}}
+
+                **Next:** {{steps.digest.output.nextActions}}
+              metadata:
+                automationMessage: true
+                kind: client-briefing
+      edges:
+        - { id: e-trigger-list, source: trigger, target: list-clients }
+        - { id: e-list-loop, source: list-clients, target: clients-loop }
+        - { id: e-loop-read, source: clients-loop, target: read-comms }
+        - { id: e-read-digest, source: read-comms, target: digest }
+        - { id: e-digest-gate, source: digest, target: signal-gate }
+        - { id: e-gate-write, source: signal-gate, target: write-briefing }
+        - { id: e-write-link, source: write-briefing, target: link-briefing }
+        - { id: e-link-resolve, source: link-briefing, target: resolve-team }
+        - { id: e-resolve-post, source: resolve-team, target: post-recap }

package/src/outreach-comms.yaml

@@ -8,6 +8,7 @@
 
 meta:
   slug: outreach-comms
+  domain: revenue
   name: Outreach & Comms
   description: Personalized LinkedIn and email outreach — sequenced touches against real people and companies, drafted and sent by an agent.
   icon: send
@@ -189,7 +190,11 @@ playbooks:
       - { name: target, type: entity, label: Target contact, required: true }
       - { name: campaign, type: text, label: Campaign name, required: true }
       - { name: channel, type: choice, label: Channel, defaultValue: linkedin }
-      - { name: campaignContext, type: text, label: Value prop + call to action }
+      - {
+          name: campaignContext,
+          type: text,
+          label: Value prop + call to action,
+        }
     executor: is-agent
     grants:
       - linkedin_send_invite