@synap-core/workspace-templates 0.12.0 → 0.24.0

package/capabilities/arch-backend.capability.json

@@ -0,0 +1,97 @@
+{
+  "apiVersion": "synap/v1",
+  "kind": "capability",
+  "meta": {
+    "slug": "arch-backend",
+    "name": "The Arch — Backend Agents",
+    "description": "List and run The Arch's backend agents from Synap. The agents you can reach depend on your Arch key's scope, and results arrive in The Arch. Needs an Arch A2A API key.",
+    "tags": [
+      "capability",
+      "arch",
+      "a2a",
+      "private",
+      "opt-in"
+    ],
+    "isPublic": false,
+    "syncByDefault": false,
+    "owner": "template-owner"
+  },
+  "spec": {
+    "key": "arch-backend",
+    "name": "The Arch — Backend Agents",
+    "description": "Invoke The Arch's own backend agents from Synap over the A2A (agent-to-agent) protocol — the REVERSE of the consume-a-service connectors (Exa/Apify/Unipile call OUT to third parties; this calls IN to The Arch's product). The Arch exposes 15 agents at POST https://thearch.so/api/a2a/rpc (Google A2A v0.3 JSON-RPC 2.0); this capability wraps the two safe entry points: discover the agents this key may invoke, and dispatch one. WHICH agents are reachable is governed SERVER-SIDE by the A2A key's own scope (A2A_KEY_SCOPES) — the recommended key is scoped to the read-only intelligence agents only (market-intelligence, radar-discovery, onchain-discovery, competitor-watch), never the money/outbound agents (cold-outreach, autonomous-bd-agent, content-generator). So the reachable surface is the intersection of these verbs and that key scope; there is no way to widen it from the pod side. PRECONDITION: an Arch A2A API key issued by The Arch (set in its A2A_API_KEYS + scoped in A2A_KEY_SCOPES), pasted into this capability's connection. Dispatch is asynchronous: message/send returns a task { id, state } that the Arch runs via its own Inngest fleet — the durable result lands in The Arch, not inline.",
+    "params": [
+      {
+        "name": "archA2aApiKey",
+        "label": "Arch A2A API key",
+        "type": "text",
+        "required": true,
+        "description": "The Arch A2A key (a value present in The Arch's A2A_API_KEYS and scoped in A2A_KEY_SCOPES). Stored server-encrypted in the vault; never persisted in the template."
+      }
+    ],
+    "vault": [
+      {
+        "ref": "archA2aApiKeySecret",
+        "name": "{{name}} Arch A2A key",
+        "value": "{{archA2aApiKey}}",
+        "type": "api_key",
+        "description": "Arch A2A API key for the arch_a2a connector (sent as the X-API-Key header)."
+      }
+    ],
+    "tools": [
+      {
+        "name": "arch_a2a",
+        "kind": "api",
+        "description": "Authenticated HTTP access to The Arch's A2A surface (https://thearch.so). The applier injects the vaulted key into the `X-API-Key` header (raw key, no prefix — The Arch's auth scheme); its credentialRef is remapped to the runtime vault://<id> at apply time. Discovery is GET /api/a2a/agents; dispatch is POST /api/a2a/rpc (JSON-RPC 2.0).",
+        "credentialRef": "archA2aApiKeySecret",
+        "executor": "is-agent",
+        "config": {
+          "baseUrl": "https://thearch.so",
+          "auth": {
+            "in": "header",
+            "name": "X-API-Key",
+            "prefix": ""
+          }
+        }
+      }
+    ],
+    "skills": [
+      {
+        "name": "arch_list_agents",
+        "intent": "list_records",
+        "kind": "code",
+        "scope": "pod",
+        "description": "Discover the Arch backend agents THIS key may invoke — the A2A discovery endpoint (GET /api/a2a/agents), already filtered server-side to the key's capability scope, so it returns only the agents `arch_run_agent` is actually allowed to dispatch. Read-only, no side effects. Returns { count, agents: [{ id, name, description, capabilities }] }. Run this first to see the reachable surface before dispatching.",
+        "requires": [
+          "arch_a2a"
+        ],
+        "executionMode": "sync",
+        "timeoutSeconds": 30,
+        "parameters": {},
+        "code": "// Discover the Arch agents this key may invoke. Executor wraps this body as\n// (async (args, context) => { <code> }); use args directly and `return`.\n// callProvider('arch_a2a','GET','/api/a2a/agents') injects the vaulted key as\n// `X-API-Key: <key>` (config.auth). The endpoint filters the list to this key's\n// A2A_KEY_SCOPES, so it never reveals agents this key cannot invoke.\nconst res = await callProvider('arch_a2a', 'GET', '/api/a2a/agents');\nconst payload = res?.body ?? res;\nconst rows = Array.isArray(payload?.agents) ? payload.agents : [];\nconst agents = rows.map((a) => ({\n  id: a?.id ?? null,\n  name: a?.name ?? null,\n  description: a?.description ?? null,\n  capabilities: Array.isArray(a?.capabilities) ? a.capabilities.map((c) => c?.name ?? c) : null,\n}));\nreturn { count: agents.length, agents };"
+      },
+      {
+        "name": "arch_run_agent",
+        "intent": "run_external_job",
+        "kind": "code",
+        "scope": "pod",
+        "description": "Dispatch one Arch backend agent over A2A (POST /api/a2a/rpc, method message/send). ASYNCHRONOUS: The Arch accepts the task and runs it on its own Inngest fleet — this returns { agentId, taskId, state } (state is typically 'submitted'), NOT the finished analysis. The durable output lands inside The Arch (its Mongo + channels), by design. Named as an ACTION verb because it triggers real work; the reachable agentId set is bounded server-side by this key's scope, so a request for an out-of-scope agent is rejected 403. Args: { agentId: string (e.g. 'market-intelligence'), prompt: string (the natural-language brief for the agent) }.",
+        "requires": [
+          "arch_a2a"
+        ],
+        "executionMode": "sync",
+        "timeoutSeconds": 60,
+        "parameters": {
+          "agentId": "string",
+          "prompt": "string"
+        },
+        "code": "// Dispatch an Arch agent over A2A JSON-RPC. Executor wraps this body as\n// (async (args, context) => { <code> }); use args directly and `return`.\n// callProvider('arch_a2a','POST','/api/a2a/rpc',rpc) injects `X-API-Key` via\n// config.auth. message/send is async: it returns a task descriptor, not the\n// finished result — The Arch runs the agent on its own fleet.\nconst agentId = String(args?.agentId ?? '').trim();\nif (!agentId) throw new Error('arch_run_agent: agentId is required');\nconst prompt = String(args?.prompt ?? '').trim();\nif (!prompt) throw new Error('arch_run_agent: prompt is required');\n\nconst rpc = {\n  jsonrpc: '2.0',\n  id: 'synap-' + agentId,\n  method: 'message/send',\n  params: {\n    agentId,\n    message: { role: 'user', parts: [{ type: 'text', text: prompt }] },\n  },\n};\n\nconst res = await callProvider('arch_a2a', 'POST', '/api/a2a/rpc', rpc);\nconst payload = res?.body ?? res;\nif (payload?.error) {\n  throw new Error('arch_run_agent: A2A error ' + (payload.error.code ?? '') + ' ' + (payload.error.message ?? ''));\n}\nconst result = payload?.result ?? payload;\nreturn {\n  agentId,\n  taskId: result?.id ?? null,\n  state: result?.status?.state ?? null,\n  metadata: result?.metadata ?? null,\n};"
+      }
+    ],
+    "provides": [
+      "list_records",
+      "run_external_job"
+    ]
+  },
+  "dependencies": []
+}

package/capabilities/arch-client-intelligence.capability.json

@@ -0,0 +1,401 @@
+{
+  "apiVersion": "synap/v1",
+  "kind": "capability",
+  "meta": {
+    "slug": "arch-client-intelligence",
+    "name": "Arch Client Intelligence",
+    "description": "When a client message or transcript arrives, refreshes that client's context summary and proposes a grant-submission card if grant work is detected. On a new Cal.com booking, prepares a call brief. Needs the Grants pipeline; automations ship turned off.",
+    "tags": [
+      "capability"
+    ],
+    "isPublic": true,
+    "syncByDefault": true
+  },
+  "spec": {
+    "key": "arch-client-intelligence",
+    "name": "Arch Client Intelligence",
+    "description": "The Arch's PROACTIVE client-intelligence layer (Waves 3+4), expressed entirely as config — automations + playbooks, zero backend code. EVENT-DRIVEN, not a daily fleet pass (the Stellar 'Client Sync' + 'Client Comms — Daily Report' crons already do the daily whole-fleet read; a third would be redundant, so everything here is triggered by a real event and gated by a filter). Three moves: (1) on a NEW client message/transcript (external_message.received — Fireflies transcripts + Discord/email all land via recordInboundMessage and fire this event), re-synthesize THAT ONE client's whole context across every bound channel + linked docs and refresh its derived `contextSummary` (governed self-update — proposes); (2) when that synthesis DETECTS grant-work (the client is discussing/pursuing a grant program), launch an is-agent playbook that PROPOSES a `grant_submission` pipeline card (never auto-creates — a mis-detection must never spawn a junk card, so this goes through the propose door, not an automation entity_create output); (3) on a NEW cal.com booking (an `event` entity created by cal-com's cal_create_booking, source:'cal.com'), run an is-agent call-prep-brief playbook for the upcoming call. Pairs with the grants workspace-template (reuses their `grant_submission` kind + `contextSummary` slug). Install into a workspace that has the grant spine (grant_submission / grant-program) composed.",
+    "params": [],
+    "vault": [],
+    "tools": [],
+    "skills": [
+      {
+        "name": "arch-client-intelligence-method",
+        "kind": "instruction",
+        "scope": "pod",
+        "description": "How to re-synthesize a single client's context on a new message, detect grant-work, and prep a call — the methodology behind the Arch proactivity automations/playbooks.",
+        "code": "# Arch client intelligence — methodology\n\nThis is the PROACTIVE, event-driven client-intelligence layer. It fires on a real signal (a new client message/transcript, or a new cal.com booking) and works ONE client at a time — never a whole-fleet sweep. Follow these rules on every run.\n\n## 1. Re-synthesis on a new message (external_message.received)\n- Only act on a MATCHED client: a message whose channel is bound to a client entity (the trigger carries `data.entityId`). An unbound / internal message is skipped — never fire on every message.\n- Gather the client's WHOLE context, not just the one message: read EVERY bound channel (Discord + email + Fireflies transcripts + team thread) and the client's linked documents. This is the `messages_query` gathering primitive with `scope: \"all-channels\"` + `includeDocuments: true`.\n- Produce a durable `contextSummary` — 1-3 plain-language sentences a teammate would want at a glance: where the client stands and what just happened. Never empty; if nothing material happened, say so in one line. Write it back via the GOVERNED self-update (it PROPOSES for a non-owner — that is correct, a human approves the refresh). REUSE the existing `contextSummary` property slug — never invent a new field.\n\n## 2. Grant-work detection → PROPOSE (never auto-create)\n- Grant-work = the client is discussing, scoping, or pursuing a grant PROGRAM (e.g. Stellar SCF, Optimism RetroPGF, Arbitrum) — a real application intent, not a passing mention.\n- When detected, the pipeline card is a `grant_submission`. It is PROPOSED, never auto-created: a mis-detected grant must never silently spawn a junk pipeline card, not even on the owner's pod. Proposing routes it to human review (a 'proposed' result is success, not failure).\n- Resolve identity FIRST: the grant PROGRAM is (or should become) its own `grant-program` entity — match before creating; the client is ALREADY an entity (the message's channel is bound to it), so you never create a company. Link the proposed submission `submitted_by` → the client and `submitted_to` → the round/program AFTER approval.\n\n## 3. Call prep on a new booking (cal.com event)\n- A cal.com booking lands as an `event` entity (`properties.source == \"cal.com\"`). Only prep cal.com events — a plain calendar-sync event is skipped.\n- Resolve the attendee (name/email on the booking) to an EXISTING client entity via identity resolution — do NOT create a person/company from a booking.\n- If a client resolves, gather their context (all channels + linked docs) and write a concise prep brief: who they are, where things stand, open needs, and 3 talking points for the call.\n\n## Firewall (never bend)\n- Any brief/report is for the INTERNAL TEAM channel only — resolve it via `channel.resolve` with `branchPurpose: \"team\"` and post there and only there. NEVER post an AI synthesis into a client-facing channel."
+      },
+      {
+        "name": "propose_grant_submission",
+        "kind": "code",
+        "scope": "pod",
+        "description": "Propose (never auto-create) a `grant_submission` pipeline card for a client the synthesis detected is pursuing a grant program. Governed: routes through the propose door for human review. Args: { clientId: string (the ALREADY-resolved client entity id), clientName?: string, programName?: string (the detected grant program), evidence?: string (a short verbatim quote evidencing the grant-work) }.",
+        "executionMode": "async",
+        "timeoutSeconds": 60,
+        "parameters": {
+          "clientId": "string",
+          "clientName": "string?",
+          "programName": "string?",
+          "evidence": "string?"
+        },
+        "code": "// Propose a grant_submission card (governed — the propose door files it for\n// human review; it is NEVER auto-created). Executor wraps this body as\n// (async (args, context) => { <code> }); use args directly and `return`.\n// Identity firewall: the client is ALREADY an entity (its channel is bound) —\n// we NEVER create a company here; we only propose the non-company submission\n// card and key it to the client via sourceRecordId so a human/later sync can\n// link submitted_by -> client and submitted_to -> the round after approval.\nconst clientId = String(args?.clientId ?? '').trim();\nif (!clientId) throw new Error('propose_grant_submission: clientId is required');\nconst clientName = String(args?.clientName ?? '').trim();\nconst programName = String(args?.programName ?? '').trim();\nconst evidence = String(args?.evidence ?? '').trim();\n\nconst title = (clientName || 'Client') + ' \\u2014 grant submission' + (programName ? ' (' + programName + ')' : '');\nconst summary = programName\n  ? ('Detected grant-work: the client is pursuing ' + programName + '.' + (evidence ? ' Evidence: \"' + evidence + '\"' : ''))\n  : 'Detected grant-work in the client\\u2019s recent context.';\n\n// stage/status use grant_submission’s OWN enum vocab (grants.yaml): a fresh\n// pursuit starts at stage \"scope\", status \"waiting-client\". sourceRecordId =\n// the client entity id (the same stable per-client key the Stellar spine uses),\n// so a later sync/human can dedupe + advance the one card.\nconst res = await propose.entity({\n  profileSlug: 'grant_submission',\n  title: title,\n  properties: { stage: 'scope', status: 'waiting-client', summary: summary, sourceRecordId: clientId },\n  reasoning: 'AI detected grant-work in the client\\u2019s context. Proposing a grant_submission pipeline card for review (never auto-created). After approval, link submitted_by \\u2192 the client and submitted_to \\u2192 the round/program.'\n});\nreturn { proposed: res?.proposed ?? true, proposalId: res?.proposalId ?? null, clientId: clientId, programName: programName };"
+      }
+    ],
+    "provides": [],
+    "playbooks": [
+      {
+        "name": "Arch — Propose Grant Submission",
+        "description": "On detected grant-work for a client, PROPOSE a `grant_submission` pipeline card (never auto-create). Identity-resolves the grant program first, proposes the card via the `propose_grant_submission` skill, and (after approval) links it to the client + round. Launched by the 'Arch — Client Re-Synthesis' automation when its synthesis detects grant-work; also runnable on demand for any client.",
+        "goalTemplate": "The client {client} is pursuing a grant program — detected from their recent context: {programName} (evidence: {evidence}). PROPOSE a grant_submission pipeline card for this client — never auto-create it; a 'proposed' result is success, awaiting human review.\n\n1. Resolve identity first: match the grant program ({programName}) against an existing `grant-program` entity before treating it as new; the client is ALREADY an entity, so never create a company.\n2. Propose the card by running the `propose_grant_submission` skill with the client id, the client name, the program name, and the short evidence quote. It keys the card to the client via sourceRecordId and starts it at stage 'scope'.\n3. After the proposal is approved, link the submission `submitted_by` → the client and `submitted_to` → the program's round. Leave any field you cannot verify blank — never fabricate.",
+        "params": [
+          {
+            "name": "client",
+            "label": "Client",
+            "type": "entity",
+            "required": true,
+            "description": "The client entity pursuing the grant (the session subject). Already resolved — never created here."
+          },
+          {
+            "name": "programName",
+            "label": "Grant program",
+            "type": "text",
+            "required": false,
+            "description": "The grant program the synthesis detected the client is pursuing (e.g. Stellar SCF)."
+          },
+          {
+            "name": "evidence",
+            "label": "Evidence",
+            "type": "text",
+            "required": false,
+            "description": "A short verbatim quote from the client's context evidencing the grant-work."
+          }
+        ],
+        "subjectProfile": {
+          "profileSlug": "company"
+        },
+        "channelSpec": {
+          "type": "THREAD",
+          "aiReactionMode": "only_mentioned"
+        },
+        "executor": "is-agent",
+        "status": "active",
+        "stages": [
+          {
+            "key": "propose",
+            "name": "Propose submission",
+            "category": "started",
+            "description": "Identity-resolve the grant program, then propose (never auto-create) the grant_submission card for the client via the propose_grant_submission skill.",
+            "goal": "A grant_submission card is PROPOSED for the client (stage 'scope'), keyed to the client via sourceRecordId, awaiting human review — never auto-created.",
+            "grants": [
+              {
+                "kind": "skill",
+                "id": "propose_grant_submission"
+              }
+            ],
+            "expectedOutputs": [
+              {
+                "kind": "note",
+                "label": "Proposed grant submission"
+              }
+            ],
+            "suggestedTasks": [
+              "Resolve the grant program identity",
+              "Propose the grant_submission card (never auto-create)",
+              "Note the client + program to link after approval"
+            ]
+          }
+        ]
+      },
+      {
+        "name": "Arch — Call Prep Brief",
+        "description": "On a new cal.com booking, prep the upcoming call: resolve the attendee to an existing client, gather that client's context across every bound channel + linked docs, and post a concise prep brief to the client's INTERNAL TEAM channel (firewall — never client-facing). Launched by the 'Arch — Call Prep on New Booking' automation; also runnable on demand for any booking event.",
+        "goalTemplate": "A new cal.com booking landed as the event {booking}. Prepare a brief for this upcoming call, following the `arch-client-intelligence-method` methodology.\n\n1. Read the booking event's details — attendee name/email, start time, and meeting link.\n2. Resolve the attendee to an EXISTING client entity via identity resolution (match on email/name). Do NOT create a person or company from a booking.\n3. If a client resolves, gather their context across ALL bound channels + linked documents, then write a concise prep brief: who they are, where the relationship stands, any open needs, and 3 talking points for the call. If no client resolves, write a lightweight brief from the booking details alone.\n4. FIREWALL: resolve the client's TEAM channel via channel.resolve { branchPurpose: \"team\" } and post the brief there and only there — never a client-facing channel. If no team channel exists, stop and say so rather than posting anywhere else.",
+        "params": [
+          {
+            "name": "booking",
+            "label": "Booking",
+            "type": "entity",
+            "required": true,
+            "description": "The cal.com booking `event` entity to prep for (the session subject)."
+          }
+        ],
+        "subjectProfile": {
+          "profileSlug": "event"
+        },
+        "channelSpec": {
+          "type": "THREAD",
+          "aiReactionMode": "only_mentioned"
+        },
+        "executor": "is-agent",
+        "status": "active"
+      }
+    ],
+    "automations": [
+      {
+        "name": "Arch — Client Re-Synthesis on New Message",
+        "description": "EVENT-DRIVEN, one client at a time. When a new client message/transcript lands (external_message.received — Fireflies transcripts, Discord, email all fire this), re-synthesize THAT client's whole context (all bound channels + linked docs) and refresh its derived `contextSummary` (governed self-update — proposes). If the synthesis detects grant-work, launch the 'Arch — Propose Grant Submission' playbook (which PROPOSES a grant_submission — never auto-creates). Gated to MATCHED clients only (a bound channel) so it never fires on internal/unmatched messages — the anti-over-automation guardrail. Seeded DRAFT: it runs a paid AI pass per matched client message, so activate it after a dogfood run (same convention as the Stellar/CRM AI automations).",
+        "triggerType": "event",
+        "triggerConfig": {
+          "eventPattern": "external_message.received.completed"
+        },
+        "status": "draft",
+        "metadata": {
+          "kind": "arch-client-resynthesis"
+        },
+        "flowDefinition": {
+          "nodes": [
+            {
+              "id": "trigger",
+              "type": "trigger",
+              "position": {
+                "x": 0,
+                "y": 0
+              },
+              "data": {
+                "triggerType": "event",
+                "label": "New client message / transcript",
+                "config": {
+                  "eventPattern": "external_message.received.completed"
+                }
+              }
+            },
+            {
+              "id": "matched-client-gate",
+              "type": "condition",
+              "position": {
+                "x": 0,
+                "y": 120
+              },
+              "data": {
+                "label": "Only a MATCHED client (channel bound to an entity)",
+                "expression": "trigger.payload.data.entityId !== \"\"",
+                "_note": "The `external_message.received` event fires for EVERY inbound external message; its `data.entityId` is the bound client entity (null when the channel isn't client-bound). matchFilters (triggerConfig) is equality-only and cannot express 'entityId is present', so the matched-client gate lives here in-flow, BEFORE any paid AI pass — this is the anti-over-automation filter (gate by matched-client, never fire-on-every-message). Bare-path + operator + quoted literal is the correct condition grammar: resolveTemplate renders an absent path to \"\" (=> \"\" !== \"\" => false, skip) and a present id to the id (=> true, proceed). external_message events are inbound EXTERNAL messages only (not team-thread chatter), so this is inherently external-attendee-gated too."
+              }
+            },
+            {
+              "id": "gather",
+              "type": "messages_query",
+              "position": {
+                "x": 0,
+                "y": 240
+              },
+              "data": {
+                "label": "Gather the client's WHOLE context (all channels + linked docs)",
+                "subjectEntityId": "{{trigger.payload.data.entityId}}",
+                "scope": "all-channels",
+                "includeDocuments": true,
+                "limit": 40,
+                "_note": "W2's messages_query fan-out: scope 'all-channels' merges every channel bound to the client (Discord + email + Fireflies transcripts + team thread) chronologically, and includeDocuments adds the client's linked-document previews. Output: { messages, documents, channels, truncated }. The access floor (workspace OR pod-wide) is enforced inside the node — the fan-out never widens it."
+              }
+            },
+            {
+              "id": "assess",
+              "type": "capability",
+              "position": {
+                "x": 0,
+                "y": 360
+              },
+              "data": {
+                "label": "Re-synthesize context + detect grant-work → JSON",
+                "verbId": "ai.generate",
+                "inputMapping": {
+                  "json": "true",
+                  "maxTokens": "600",
+                  "system": "You are a strict data-extraction function that re-synthesizes ONE client's context from their recent communications and detects whether they are pursuing a grant program. Respond with STRICT JSON and NOTHING else. Never fabricate.",
+                  "prompt": "The client entity id is {{trigger.payload.data.entityId}}. Below is their recent context gathered across every bound channel (chronological) and their linked documents.\n\nMessages:\n{{steps.gather.output.messages}}\n\nLinked documents:\n{{steps.gather.output.documents}}\n\nReturn STRICT JSON with EXACTLY these keys and nothing else:\n{\n  \"contextSummary\": \"1-3 plain-language sentences on where this client stands and what just happened; never empty (say 'no material activity' in one line if nothing happened)\",\n  \"grantDetected\": \"true\" or \"false\" (a STRING, not a boolean): 'true' ONLY when the client is clearly discussing / scoping / pursuing a specific grant PROGRAM (e.g. Stellar SCF, Optimism RetroPGF, Arbitrum), not a passing mention,\n  \"grantProgram\": \"the grant program name when grantDetected is 'true', else an empty string\",\n  \"grantEvidence\": \"a short VERBATIM quote from the context evidencing the grant-work when grantDetected is 'true', else an empty string\"\n}\nAlways return ALL keys. Use conservative defaults (grantDetected 'false', empty strings) when unsure."
+                },
+                "_note": "ONE assess pass (mirrors Stellar 'Client Sync' + grants.yaml 'grant-submission-sync'): re-synthesizes contextSummary AND detects grant-work in the same read. This flow is SINGLE-SUBJECT from the event — there is no loop node, so the prompt must not reference a loop item (an earlier draft did, and it would have rendered empty at run time). The client is identified by the trigger's entityId, the same handle every other node here uses; the client's display title is not separately available, so the prompt leans on the gathered messages/documents (each message carries its source). grantDetected is a STRING ('true'/'false') so the string-based `condition` gate downstream can test it with an explicit `=== \"true\"` (a bare truthiness check would read 'false' as truthy — the documented gate-fail-open trap)."
+              }
+            },
+            {
+              "id": "enrich-context",
+              "type": "output",
+              "position": {
+                "x": -220,
+                "y": 480
+              },
+              "data": {
+                "label": "Refresh the client's contextSummary (governed self-update — PROPOSES)",
+                "outputType": "entity_update",
+                "config": {
+                  "entityId": "{{trigger.payload.data.entityId}}",
+                  "properties": {
+                    "contextSummary": "{{steps.assess.output.contextSummary}}"
+                  }
+                },
+                "_note": "GOVERNED SELF-UPDATE of a DERIVED field, REUSING the existing `contextSummary` slug (defined on company/client via foundation/CRM — the SAME slug Stellar 'Client Sync' writes; never invent a new property). Routes through checkAutomationWriteOrPropose: for a non-owner / non-auto-approved automation it PROPOSES (correct — a human approves the refresh); for an owner/auto-approved workspace it direct-writes. entity_update on the EXISTING client ({{trigger.payload.data.entityId}}) — it NEVER creates an entity."
+              }
+            },
+            {
+              "id": "grant-gate",
+              "type": "condition",
+              "position": {
+                "x": 220,
+                "y": 480
+              },
+              "data": {
+                "label": "Only when the synthesis detected grant-work",
+                "expression": "steps.assess.output.grantDetected === \"true\"",
+                "_note": "Bare-path + operator + quoted literal (the correct, non-fail-open condition grammar). Fans out from `assess` independently of enrich-context — a contextSummary propose failure never blocks grant detection, and vice versa (the decoupled-chains pattern from Stellar 'Client Sync')."
+              }
+            },
+            {
+              "id": "propose-submission",
+              "type": "playbook_run",
+              "position": {
+                "x": 220,
+                "y": 600
+              },
+              "data": {
+                "label": "Propose a grant_submission (via is-agent playbook — never auto-create)",
+                "playbookName": "Arch — Propose Grant Submission",
+                "paramsMapping": {
+                  "subjectId": "{{trigger.payload.data.entityId}}",
+                  "client": "{{trigger.payload.data.entityId}}",
+                  "programName": "{{steps.assess.output.grantProgram}}",
+                  "evidence": "{{steps.assess.output.grantEvidence}}"
+                },
+                "_note": "Why a PLAYBOOK, not an entity_create output node: automations SUPPRESS proposal persistence (dispatchViaCapabilityRouter sets suppressProposal:true) and an entity_create output auto-writes for an owner — neither can guarantee 'always propose, never auto-create'. An is-agent playbook runs in a proposal-persisting context, so its propose.entity (the `propose_grant_submission` skill) genuinely files a reviewable proposal even on the owner's pod. subjectId binds the session subject (executePlaybookRun reads entityId/subjectId); `client` fills the goal's {client}."
+              }
+            }
+          ],
+          "edges": [
+            {
+              "id": "e-trigger-gate",
+              "source": "trigger",
+              "target": "matched-client-gate"
+            },
+            {
+              "id": "e-gate-gather",
+              "source": "matched-client-gate",
+              "target": "gather",
+              "sourceHandle": "yes"
+            },
+            {
+              "id": "e-gather-assess",
+              "source": "gather",
+              "target": "assess"
+            },
+            {
+              "id": "e-assess-enrich",
+              "source": "assess",
+              "target": "enrich-context"
+            },
+            {
+              "id": "e-assess-grantgate",
+              "source": "assess",
+              "target": "grant-gate"
+            },
+            {
+              "id": "e-grantgate-propose",
+              "source": "grant-gate",
+              "target": "propose-submission",
+              "sourceHandle": "yes"
+            }
+          ]
+        }
+      },
+      {
+        "name": "Arch — Call Prep on New Booking",
+        "description": "EVENT-DRIVEN. When a new cal.com booking lands as an `event` entity (cal-com's cal_create_booking stamps properties.source:'cal.com'), read the event, gate to cal.com bookings only, and launch the 'Arch — Call Prep Brief' playbook to prep the upcoming call. Fires on every event.create but the source gate keeps the paid AI/playbook to cal.com bookings only (anti-over-automation). Seeded DRAFT — activate after a dogfood run.",
+        "triggerType": "event",
+        "triggerConfig": {
+          "eventPattern": "entity.create.completed",
+          "filters": {
+            "profileSlug": "event"
+          }
+        },
+        "status": "draft",
+        "metadata": {
+          "kind": "arch-call-prep",
+          "pairsWith": "cal-com"
+        },
+        "flowDefinition": {
+          "nodes": [
+            {
+              "id": "trigger",
+              "type": "trigger",
+              "position": {
+                "x": 0,
+                "y": 0
+              },
+              "data": {
+                "triggerType": "event",
+                "label": "New event entity created",
+                "config": {
+                  "eventPattern": "entity.create.completed",
+                  "filters": {
+                    "profileSlug": "event"
+                  }
+                }
+              }
+            },
+            {
+              "id": "read-event",
+              "type": "entity_read",
+              "position": {
+                "x": 0,
+                "y": 120
+              },
+              "data": {
+                "label": "Load the new event",
+                "entityId": "{{trigger.payload.subjectId}}",
+                "_note": "The entity.create.completed event data is only { profileSlug, title } — it does NOT carry properties. So `source` must be READ from the entity here; the gate below matches on this node's output, exactly like lead-conversion-enrollment reads the lead before switching on its source."
+              }
+            },
+            {
+              "id": "source-gate",
+              "type": "condition",
+              "position": {
+                "x": 0,
+                "y": 240
+              },
+              "data": {
+                "label": "Only cal.com bookings (skip plain calendar-sync events)",
+                "expression": "steps.read-event.output.entity.properties.source === \"cal.com\"",
+                "_note": "cal-com's cal_create_booking proposes the event with properties.source:'cal.com'. Bare-path + operator + quoted literal. Gating BEFORE the playbook keeps the paid AI/prep-brief to real bookings only — a plain calendar-sync event (no cal.com source) is skipped (anti-over-automation)."
+              }
+            },
+            {
+              "id": "prep",
+              "type": "playbook_run",
+              "position": {
+                "x": 0,
+                "y": 360
+              },
+              "data": {
+                "label": "Prep the upcoming call (is-agent playbook)",
+                "playbookName": "Arch — Call Prep Brief",
+                "paramsMapping": {
+                  "subjectId": "{{trigger.payload.subjectId}}",
+                  "booking": "{{trigger.payload.subjectId}}"
+                },
+                "_note": "subjectId binds the session subject (executePlaybookRun reads entityId/subjectId); `booking` fills the goal's {booking}. The playbook resolves the attendee → an existing client (identity resolution the agent has and a bare command node lacks), gathers context, and posts the brief to the TEAM channel (firewall)."
+              }
+            }
+          ],
+          "edges": [
+            {
+              "id": "e-trigger-read",
+              "source": "trigger",
+              "target": "read-event"
+            },
+            {
+              "id": "e-read-gate",
+              "source": "read-event",
+              "target": "source-gate"
+            },
+            {
+              "id": "e-gate-prep",
+              "source": "source-gate",
+              "target": "prep",
+              "sourceHandle": "yes"
+            }
+          ]
+        }
+      }
+    ]
+  },
+  "dependencies": []
+}