@synap-core/workspace-templates 0.9.4 → 0.11.0

package/src/outreach-comms.yaml

@@ -203,6 +203,202 @@ playbooks:
       - entity.create
     status: active
 
+# ── LinkedIn conversation ingest (PURE-CONFIG automation — PROPOSAL) ─────────
+# Pulls LinkedIn threads via Unipile and records each as an EXTERNAL channel +
+# messages through the GENERIC `channel.ingest` verb. No provider code in the
+# pod — this composes existing verbs (unipile_list_accounts /
+# unipile_list_conversations / unipile_list_messages + channel.ingest).
+#
+# TRIGGER MODEL — ONE automation, both jobs (no high-freq polling):
+#   • RECONCILIATION: `triggerType: cron` at a LOW frequency (daily 06:00).
+#   • BACKFILL / on-demand: fire the SAME automation via
+#     `POST /automations/{id}/trigger` (MCP `synap_trigger_automation`), which
+#     "bypasses the automation's normal trigger config" and runs the flow once.
+# channel.ingest is idempotent, so cron sweeps and manual backfills are safe to
+# overlap and repeat.
+#
+# ⚠️ NEEDS-REVIEW — TWO verified engine constraints shape this flow; see the
+# handoff report. (1) The automation engine has NO nested loops
+# (LOOP_BODY_NODE_TYPES excludes `loop`/`sub_automation`), so the requested
+# `loop conversations → loop messages → channel.ingest per message` graph is
+# not expressible. This does ONE loop over conversations and hands each thread's
+# whole `messages` array to channel.ingest in a single call. (2) A `transform`
+# `map:` pipe can only project a single field/string per item, so it cannot
+# normalize messages into `{text, sentAt, participant, idempotencySeed}` objects
+# in-flow. => channel.ingest must accept a BATCH `messages: [...]` of raw
+# provider rows and do the per-message normalization + idempotent dedup
+# SERVER-SIDE. That is a contract change vs the single-message signature.
+# Kept `status: draft` until that batch shape ships; then activate.
+automations:
+  - key: linkedin-conversation-ingest
+    name: LinkedIn conversation ingest
+    description: >-
+      Pull LinkedIn conversations via Unipile and record each thread as an
+      external channel + its messages through channel.ingest (idempotent, so
+      re-runs are safe). Cron = low-frequency reconciliation; manual trigger =
+      on-demand backfill.
+    triggerType: cron
+    triggerConfig:
+      expression: "0 6 * * *"
+    status: draft
+    flow:
+      nodes:
+        - id: trigger
+          type: trigger
+          position: { x: 0, y: 0 }
+          data:
+            label: Daily 06:00 reconciliation (also fired manually for backfill)
+            triggerType: cron
+            config:
+              expression: "0 6 * * *"
+
+        # Resolve the connected account AT RUNTIME so the cron sweep needs no
+        # payload. A multi-account / multi-provider pod would still need a
+        # run-param accountId to sweep MORE than the first LinkedIn account — a
+        # per-account sweep would itself need the nested loop this engine lacks
+        # (secondary follow-up, noted in the report).
+        - id: list-accounts
+          type: capability
+          position: { x: 0, y: 120 }
+          data:
+            label: Resolve the connected Unipile account
+            verbId: unipile_list_accounts
+
+        # F5 — PROVIDER FILTER. `unipile_list_accounts` returns RAW Unipile v2
+        # account rows and a pod can connect several providers, so a non-LinkedIn
+        # account (WhatsApp / Telegram / Gmail) can sit at index 0. Taking a blind
+        # `accounts.0` would ingest that provider's threads AS linkedin. This
+        # `transform` node's array `filter:` pipe keeps ONLY LinkedIn accounts;
+        # every step below takes `.0` of the FILTERED list.
+        #   Field: the predicate matches the RAW Unipile v2 account shape
+        #   `type: 'LINKEDIN' | 'GMAIL' | 'WHATSAPP' | …` (verified in
+        #   UnipileConnector's UnipileAccountSchema, NOT the capability's loose
+        #   "provider" prose). evaluateCondition does an EXACT, case-sensitive
+        #   `==`, hence the uppercase literal.
+        #   Failure mode: if no LinkedIn account is connected (or the raw field
+        #   shape ever drifts) the filtered list is empty → the accountId below
+        #   resolves to "" → the run FAILS VISIBLY at list-conversations. It never
+        #   silently ingests the wrong provider — that is the point of F5.
+        #   Multi-LinkedIn-account: still takes the first; a run-param accountId
+        #   is the multi-account follow-up (noted in the report).
+        - id: filter-linkedin-account
+          type: transform
+          position: { x: 0, y: 180 }
+          data:
+            label: Keep only LinkedIn Unipile accounts
+            expression: "{{steps.list-accounts.output.accounts}} | filter:item.type == 'LINKEDIN'"
+
+        - id: list-conversations
+          type: capability
+          position: { x: 0, y: 240 }
+          data:
+            label: List LinkedIn conversations for the account
+            verbId: unipile_list_conversations
+            inputMapping:
+              accountId: "{{steps.filter-linkedin-account.output.result.0.id}}"
+
+        # NOTE: the automation engine caps loops at MAX_LOOP_ITERATIONS=100 per run
+        # (logs a warning, then truncates). So one cron pass reconciles the 100
+        # most-recent conversations; accounts with >100 threads need either a
+        # newest-first list (so the active threads are always covered) or a paged
+        # sweep (blocked today — would need the nested loops the engine lacks).
+        # Fine for the current dogfood scale; revisit if a user exceeds ~100 threads.
+        - id: conversations-loop
+          type: loop
+          position: { x: 0, y: 360 }
+          data:
+            label: For each conversation
+            iteratorExpression: steps.list-conversations.output.conversations
+            itemVariable: conversation
+
+        # Loop body (owned by conversations-loop): list this thread's messages,
+        # then ingest. `{{loop.item.id}}` is the chat/thread id for THIS
+        # iteration; `steps.list-messages` is re-bound per iteration.
+        - id: list-messages
+          type: capability
+          position: { x: 0, y: 480 }
+          data:
+            label: List this thread's messages
+            verbId: unipile_list_messages
+            inputMapping:
+              threadId: "{{loop.item.id}}"
+              accountId: "{{steps.filter-linkedin-account.output.result.0.id}}"
+
+        # GENERIC ingest — records the external channel for this thread and its
+        # messages, idempotently (dedup on a per-message idempotency seed derived
+        # SERVER-SIDE, e.g. `${externalId}:${sentAt}:${body}`). See the ⚠️ note:
+        # `messages` is a BATCH of raw provider rows (pending channel.ingest's
+        # batch contract).
+        - id: ingest
+          type: capability
+          position: { x: 0, y: 600 }
+          data:
+            label: Ingest thread + messages (idempotent, generic)
+            verbId: channel.ingest
+            inputMapping:
+              provider: linkedin
+              externalId: "{{loop.item.id}}"
+              title: "{{loop.item.name}}"
+              accountExternalId: "{{steps.filter-linkedin-account.output.result.0.id}}"
+              # F1 — TARGET THE CRM WORKSPACE. Without this, channel.ingest lands
+              # in the automation's OWN workspace, but the dashboard inbox reads
+              # "The arch CRM". Single-tenant target = the inbox/CRM workspace.
+              # TODO(multi-tenant): make this an install/run param instead of a
+              # literal (the flow schema has no template-var/param mechanism for a
+              # capability inputMapping today, so a documented literal is the
+              # single-tenant path — see the report).
+              workspaceId: "499328b7-fd35-4143-b1bc-67b9e45d9b4b"
+              # F2 — SUPPRESS THE BACKFILL STORM. This is a poll / reconciliation
+              # of HISTORICAL messages, so it must NOT emit
+              # `external_message.received` per message (channel resolve + dedup
+              # insert still run). Without this, one backfill of N threads fans
+              # out through the webhook + automation-trigger reactors N×messages.
+              suppressSideEffects: true
+              # BATCH mode: hand the whole thread's messages[] to the generic verb
+              # in ONE call (the engine has no nested loops). channel.ingest stays
+              # provider-agnostic — messageMap tells it (in CONFIG) where each field
+              # lives inside a raw Unipile v2 message row. Verified live 2026-07-27:
+              # a message = { id, text, timestamp (ISO), sender_id, is_sender, ... }.
+              messages: "{{steps.list-messages.output.messages}}"
+              messageMap:
+                text: text
+                id: id
+                sentAt: timestamp
+                # F3 — DIRECTION. `is_sender` (dot-path to a boolean per row) marks
+                # the operator's OWN sent messages as OUTBOUND so the inbox renders
+                # them right-aligned, instead of everything looking inbound.
+                isOutbound: is_sender
+                # F6 — participantExternalId DROPPED on purpose. link-at-birth
+                # binds the channel to the participant of the first-processed
+                # (newest) message, which — when that message is the account
+                # OWNER's own reply — mis-binds the whole thread to yourself. The
+                # channel `title` already carries the conversation (contact) name,
+                # so dropping the per-message sender id lets link-at-birth avoid
+                # the mis-bind.
+      edges:
+        - { id: e-trigger-accounts, source: trigger, target: list-accounts }
+        - {
+            id: e-accounts-filter,
+            source: list-accounts,
+            target: filter-linkedin-account,
+          }
+        - {
+            id: e-filter-convos,
+            source: filter-linkedin-account,
+            target: list-conversations,
+          }
+        - {
+            id: e-convos-loop,
+            source: list-conversations,
+            target: conversations-loop,
+          }
+        - {
+            id: e-loop-messages,
+            source: conversations-loop,
+            target: list-messages,
+          }
+        - { id: e-messages-ingest, source: list-messages, target: ingest }
+
 # LinkedIn send/search via Unipile, email send via Gmail (nango-google). The
 # user connects each once on install; a missing key fails gracefully per-skill.
 integrations:

package/src/project-management.yaml

@@ -268,7 +268,12 @@ profiles:
     icon: user
     color: "#0891B2"
     description: "Team member or stakeholder"
-    scope: WORKSPACE
+    # Pod-wide identity: `person` is ONE pod-wide SYSTEM kind. `entityScope: pod`
+    # lands the ROWS with `workspace_id = NULL` (visible from every workspace);
+    # `scope` omitted (no claim) so the applier reuses the system row and these
+    # project-management props land as this workspace's OVERLAY.
+    # (Was `scope: WORKSPACE`, which contradicted the pod-wide model.)
+    entityScope: pod
     properties:
       - slug: person-role
         label: Role