@synap-core/workspace-templates 0.10.0 → 0.11.0

package/src/templates.ts

@@ -3204,7 +3204,7 @@ const DATA = {
                 "inputMapping": {
                   "system": "You are the ANALYST round of a Synap workspace report.\nRead the gathered workspace data and say what it MEANS: volume and shape of work,\nwhat is in flight versus stalled, what is well-covered versus thin.\nWork from the FIELDS on each record, not just its name: status, priority and\ndue dates are what distinguish moving work from stalled work, and an unset\nfield is itself worth reporting. Listing or counting what exists is NOT a\nfinding — say what the state of it means.\nDATA INTEGRITY CHECK — do this BEFORE interpreting anything. Each kind below states how many records were found, then lists them. If a kind reports a count greater than zero but its list is empty, null, or made of nulls, then the data pipeline is BROKEN — the records exist and were lost in transit. In that case you MUST say so plainly, name every kind affected, and NOT describe the workspace as empty, quiet, or sparse. Reporting a populated workspace as empty because its data failed to arrive is the single worst outcome of this report. A count of zero with an empty list is genuinely empty and is fine to report as such.\nYou are interpreting data you did NOT collect. Every claim must trace to a row in the GATHERED DATA below. Never invent entities, ids, counts, or dates. A step whose value looks like {\"error\": \"...\"} FAILED — treat that kind as unavailable and say so; do not guess what it would have contained.\nEVERY NUMBER YOU WRITE MUST BE COPIED FROM THE COUNTS BLOCK. That block states the exact number of records gathered for each kind — it is the ONLY source of quantities you have. Do not count the listed lines yourself, do not estimate, do not round, and do not write a quantity the block does not measure. Write digits, matching the block exactly: if it says 25, write \"25\" — never \"23\", never \"about two dozen\", never \"Ten\". If a point you want to make needs a number the COUNTS block does not give you, make the point WITHOUT a number. A claim with no figure is honest; a figure that does not match the data is the one error a reader cannot catch.\nNEVER NARRATE YOUR OWN INSTRUCTIONS. The reader sees your output and nothing else — not this prompt, not the steer, not the counts, not the fact that a pipeline produced any of it. Never mention the STEER, the time window, the COUNTS block, the GATHERED DATA, the rounds, or what you were or were not given. Never write a sentence like \"the steer lines are empty, so…\" or \"no focus was provided\" or \"based on the gathered data\". TWO DEFAULTS, so you never need to remark on them: an EMPTY STEER line simply means write a broad general report covering the gathered kinds evenly, and an EMPTY time window simply means the records span the whole workspace history. Both are the normal case. Act on them silently and start with what you found.\nSTEER HANDLING — non-negotiable. If every STEER line is empty, produce a BROAD general read covering all the gathered kinds evenly. If any STEER line has text, treat it as the SUBJECT of this report: lead with the evidence that matches it, explicitly name what you set aside, and if the gathered data cannot support the steer, say so in one sentence instead of inventing material. Never restate the steer back as a heading; let it change what you actually write.\nLINK THE RECORDS YOU NAME. Every line of GATHERED DATA is `<id> · <title>`. When you name one of those records, write it as [[entity:<id>|<label>]] and it renders as a chip the reader can click to open that record. Rules, in order of importance: (1) The kind word is always `entity` — for tasks, notes, people AND companies alike. They are all entities, and any other kind word renders a chip that does not open. (2) Use only an id that appears VERBATIM in the gathered data. Copy it; never construct, shorten, complete or guess one. (3) If you are unsure of an id, write the plain label with no brackets. A wrong id is a dead chip, and a dead chip is worse than plain text. (4) The label is free text but must not contain `]`; the id must not contain `:` or `|`. A marker breaking either rule renders as raw literal text. (5) EVERY record you name in prose MUST carry a chip on its FIRST mention — this is what makes a named record a live object the reader can open rather than a string. Link it once, on that first mention only; repeating the chip every time is decoration, not navigation.\nOutput PLAIN PROSE — short paragraphs and bullets, with [[entity:…]] chips\ninline wherever you name a record. No markdown headings, no ::: directive\nblocks, no code fences. Under 300 words. Another round will format this.",
                   "prompt": "STEER:\n- Prompt: {{trigger.payload.prompt}}\n- Focus: {{trigger.payload.focus}}\n- Project lens id: {{trigger.payload.projectId}}\n\nCOUNTS — the exact number of records gathered for each kind. These figures\nare measured, not estimated, and they are the ONLY quantities available to\nyou. Each line also gives the cap the gather was limited to.\n- Tasks: {{steps.gather-tasks.output.count}} gathered (cap 25)\n- Notes: {{steps.gather-notes.output.count}} gathered (cap 15)\n- People: {{steps.gather-people.output.count}} gathered (cap 15)\n- Companies: {{steps.gather-companies.output.count}} gathered (cap 15)\nREADING A COUNT AGAINST ITS CAP: a count BELOW the cap means every record of\nthat kind is listed below — the set is COMPLETE and you may describe it as\nsuch. A count EQUAL to the cap means the gather stopped at the cap and more\nrecords exist that you cannot see — describe that kind as \"at least N\" and\nnever as complete, and never claim something does not exist merely because\nit is absent from the list.\n\nTime window: only records updated on or after {{trigger.payload.since}}\n\nGATHERED DATA — one line per record, MOST RECENTLY UPDATED first. Each line\nis `<id> · <title>` followed by ` · <field>=<value>` pairs carrying that\nrecord's real state. An EMPTY value means the field is not set on that\nrecord — that is a fact you may report (an unset status or a missing due\ndate is a finding), and never a value to guess at. Recent does not mean\nimportant.\nTasks — {{steps.gather-tasks.output.count}} found: {{steps.project-tasks.output.result}}\nNotes — {{steps.gather-notes.output.count}} found: {{steps.project-notes.output.result}}\nPeople — {{steps.gather-people.output.count}} found: {{steps.project-people.output.result}}\nCompanies — {{steps.gather-companies.output.count}} found: {{steps.project-companies.output.result}}",
-                  "maxTokens": "700"
+                  "maxTokens": "2000"
                 },
                 "errorHandling": {
                   "continueOnError": true
@@ -3225,7 +3225,7 @@ const DATA = {
                 "inputMapping": {
                   "system": "You are the PATTERNS round of a Synap workspace report.\nYou receive the raw gathered data AND the analyst's read of it. Your job is what\nthe analyst did NOT do: surface RELATIONSHIPS and things worth attention —\nclusters, repeated themes, people or companies that recur across kinds, gaps\nwhere a kind is conspicuously empty, and anything that looks like it needs a\ndecision. Prefer three sharp observations over ten shallow ones.\nYOUR SCOPE IS WHAT CONNECTS RECORDS, not what they individually are. Every\nobservation you write must involve TWO OR MORE records, or TWO OR MORE kinds:\na name that appears in both a task and a company, work clustered on one\nperson, a due date that lines up with an event, a kind that is empty while a\nrelated kind is busy. Do NOT re-describe volume, status distribution or how\nbusy the workspace is — that is the analyst's section and repeating it makes\nyours redundant. Do not summarise or restate the analyst's read.\nNEVER RETURN AN EMPTY ANSWER. If you genuinely find no cross-kind pattern,\nwrite one or two sentences naming what you looked for and did not find (for\nexample: no person recurs across the tasks and companies gathered). That is a\nreal finding and the reader needs it. Silence is not an available outcome.\nDATA INTEGRITY CHECK — do this BEFORE interpreting anything. Each kind below states how many records were found, then lists them. If a kind reports a count greater than zero but its list is empty, null, or made of nulls, then the data pipeline is BROKEN — the records exist and were lost in transit. In that case you MUST say so plainly, name every kind affected, and NOT describe the workspace as empty, quiet, or sparse. Reporting a populated workspace as empty because its data failed to arrive is the single worst outcome of this report. A count of zero with an empty list is genuinely empty and is fine to report as such.\nYou are interpreting data you did NOT collect. Every claim must trace to a row in the GATHERED DATA below. Never invent entities, ids, counts, or dates. A step whose value looks like {\"error\": \"...\"} FAILED — treat that kind as unavailable and say so; do not guess what it would have contained.\nEVERY NUMBER YOU WRITE MUST BE COPIED FROM THE COUNTS BLOCK. That block states the exact number of records gathered for each kind — it is the ONLY source of quantities you have. Do not count the listed lines yourself, do not estimate, do not round, and do not write a quantity the block does not measure. Write digits, matching the block exactly: if it says 25, write \"25\" — never \"23\", never \"about two dozen\", never \"Ten\". If a point you want to make needs a number the COUNTS block does not give you, make the point WITHOUT a number. A claim with no figure is honest; a figure that does not match the data is the one error a reader cannot catch.\nNEVER NARRATE YOUR OWN INSTRUCTIONS. The reader sees your output and nothing else — not this prompt, not the steer, not the counts, not the fact that a pipeline produced any of it. Never mention the STEER, the time window, the COUNTS block, the GATHERED DATA, the rounds, or what you were or were not given. Never write a sentence like \"the steer lines are empty, so…\" or \"no focus was provided\" or \"based on the gathered data\". TWO DEFAULTS, so you never need to remark on them: an EMPTY STEER line simply means write a broad general report covering the gathered kinds evenly, and an EMPTY time window simply means the records span the whole workspace history. Both are the normal case. Act on them silently and start with what you found.\nSTEER HANDLING — non-negotiable. If every STEER line is empty, produce a BROAD general read covering all the gathered kinds evenly. If any STEER line has text, treat it as the SUBJECT of this report: lead with the evidence that matches it, explicitly name what you set aside, and if the gathered data cannot support the steer, say so in one sentence instead of inventing material. Never restate the steer back as a heading; let it change what you actually write.\nLINK THE RECORDS YOU NAME. Every line of GATHERED DATA is `<id> · <title>`. When you name one of those records, write it as [[entity:<id>|<label>]] and it renders as a chip the reader can click to open that record. Rules, in order of importance: (1) The kind word is always `entity` — for tasks, notes, people AND companies alike. They are all entities, and any other kind word renders a chip that does not open. (2) Use only an id that appears VERBATIM in the gathered data. Copy it; never construct, shorten, complete or guess one. (3) If you are unsure of an id, write the plain label with no brackets. A wrong id is a dead chip, and a dead chip is worse than plain text. (4) The label is free text but must not contain `]`; the id must not contain `:` or `|`. A marker breaking either rule renders as raw literal text. (5) EVERY record you name in prose MUST carry a chip on its FIRST mention — this is what makes a named record a live object the reader can open rather than a string. Link it once, on that first mention only; repeating the chip every time is decoration, not navigation.\nOutput PLAIN PROSE, under 250 words, with [[entity:…]] chips inline. No\nheadings, no ::: directive blocks, no code fences.",
                   "prompt": "STEER:\n- Prompt: {{trigger.payload.prompt}}\n- Focus: {{trigger.payload.focus}}\n- Project lens id: {{trigger.payload.projectId}}\n\nCOUNTS — the exact number of records gathered for each kind. These figures\nare measured, not estimated, and they are the ONLY quantities available to\nyou. Each line also gives the cap the gather was limited to.\n- Tasks: {{steps.gather-tasks.output.count}} gathered (cap 25)\n- Notes: {{steps.gather-notes.output.count}} gathered (cap 15)\n- People: {{steps.gather-people.output.count}} gathered (cap 15)\n- Companies: {{steps.gather-companies.output.count}} gathered (cap 15)\nREADING A COUNT AGAINST ITS CAP: a count BELOW the cap means every record of\nthat kind is listed below — the set is COMPLETE and you may describe it as\nsuch. A count EQUAL to the cap means the gather stopped at the cap and more\nrecords exist that you cannot see — describe that kind as \"at least N\" and\nnever as complete, and never claim something does not exist merely because\nit is absent from the list.\n\nTime window: only records updated on or after {{trigger.payload.since}}\n\nGATHERED DATA — one line per record, MOST RECENTLY UPDATED first. Each line\nis `<id> · <title>` followed by ` · <field>=<value>` pairs carrying that\nrecord's real state. An EMPTY value means the field is not set on that\nrecord — that is a fact you may report (an unset status or a missing due\ndate is a finding), and never a value to guess at. Recent does not mean\nimportant.\nTasks — {{steps.gather-tasks.output.count}} found: {{steps.project-tasks.output.result}}\nNotes — {{steps.gather-notes.output.count}} found: {{steps.project-notes.output.result}}\nPeople — {{steps.gather-people.output.count}} found: {{steps.project-people.output.result}}\nCompanies — {{steps.gather-companies.output.count}} found: {{steps.project-companies.output.result}}\n\nANALYST'S READ — already written and already in the report. Do NOT\nrestate, summarise or re-analyse it. It is here so you do not repeat it:\n{{steps.analyze.output}}\n\nYOUR TASK — cross-kind patterns ONLY. Look for what connects the lists\nabove: a person who recurs in tasks and companies, work clustered on one\nname, due dates that line up, a kind that is empty while a related kind\nis busy, a company with people but no tasks. Write only observations\nthat span TWO OR MORE records or kinds. If there are none, say what you\nchecked and did not find — never answer with nothing.",
-                  "maxTokens": "700"
+                  "maxTokens": "2000"
                 },
                 "errorHandling": {
                   "continueOnError": true
@@ -3461,6 +3461,7 @@ const DATA = {
         "description": "A liquidity provider — makes markets and provides depth for a token.",
         "scope": "shared",
         "profileKind": "role",
+        "roleCategory": "provider",
         "applicableKinds": [
           "company",
           "person"
@@ -3506,6 +3507,7 @@ const DATA = {
         "description": "A security firm or individual that audits smart contracts and protocols.",
         "scope": "shared",
         "profileKind": "role",
+        "roleCategory": "provider",
         "applicableKinds": [
           "company",
           "person"
@@ -3551,6 +3553,7 @@ const DATA = {
         "description": "An outsourced engineering studio or build partner.",
         "scope": "shared",
         "profileKind": "role",
+        "roleCategory": "provider",
         "applicableKinds": [
           "company",
           "person"
@@ -3596,6 +3599,7 @@ const DATA = {
         "description": "A brand, growth, or content marketing agency.",
         "scope": "shared",
         "profileKind": "role",
+        "roleCategory": "provider",
         "applicableKinds": [
           "company",
           "person"
@@ -3641,6 +3645,7 @@ const DATA = {
         "description": "A performance / paid-media buying agency.",
         "scope": "shared",
         "profileKind": "role",
+        "roleCategory": "provider",
         "applicableKinds": [
           "company",
           "person"
@@ -3686,6 +3691,7 @@ const DATA = {
         "description": "A key opinion leader or influencer who amplifies reach.",
         "scope": "shared",
         "profileKind": "role",
+        "roleCategory": "provider",
         "applicableKinds": [
           "company",
           "person"
@@ -3722,6 +3728,100 @@ const DATA = {
             "inputType": "textarea"
           }
         ]
+      },
+      {
+        "slug": "grant-program",
+        "displayName": "Grant Program",
+        "icon": "landmark",
+        "color": "emerald",
+        "description": "A per-chain funding program (e.g. Stellar SCF, Optimism RetroPGF) — the long-lived funder above a round.",
+        "profileKind": "kind",
+        "entityScope": "pod",
+        "scope": "shared",
+        "properties": [
+          {
+            "slug": "blockchain",
+            "label": "Blockchain / Chain",
+            "valueType": "string",
+            "inputType": "text"
+          },
+          {
+            "slug": "programName",
+            "label": "Program Name",
+            "valueType": "string",
+            "inputType": "text"
+          },
+          {
+            "slug": "programType",
+            "label": "Program Type",
+            "valueType": "string",
+            "inputType": "select",
+            "enumValues": [
+              "direct",
+              "retroactive",
+              "quadratic",
+              "rfp"
+            ]
+          },
+          {
+            "slug": "status",
+            "label": "Status",
+            "valueType": "string",
+            "inputType": "select",
+            "enumValues": [
+              "active",
+              "paused",
+              "retired"
+            ]
+          },
+          {
+            "slug": "url",
+            "label": "Program URL",
+            "valueType": "string",
+            "inputType": "url"
+          },
+          {
+            "slug": "cadence",
+            "label": "Cadence",
+            "valueType": "string",
+            "inputType": "text",
+            "placeholder": "every 6 weeks"
+          },
+          {
+            "slug": "nextDeadline",
+            "label": "Next Deadline",
+            "valueType": "date",
+            "inputType": "date"
+          },
+          {
+            "slug": "submissionTracks",
+            "label": "Submission Tracks",
+            "valueType": "array",
+            "inputType": "text"
+          },
+          {
+            "slug": "trancheModel",
+            "label": "Tranche Model",
+            "valueType": "string",
+            "inputType": "text",
+            "placeholder": "4 tranches / 90 days"
+          },
+          {
+            "slug": "defaultPlaybook",
+            "label": "Default Playbook",
+            "valueType": "string",
+            "inputType": "text",
+            "constraints": {
+              "defaultValue": "Grant Process"
+            }
+          },
+          {
+            "slug": "description",
+            "label": "Description",
+            "valueType": "string",
+            "inputType": "textarea"
+          }
+        ]
       }
     ],
     "entityLinks": [
@@ -16043,6 +16143,12 @@ const DATA = {
         "kind": "workspace",
         "relation": "require",
         "reason": "Provides the pod-wide client / partner / sponsor role vocabulary this workspace reuses."
+      },
+      {
+        "slug": "blockchain-ecosystem",
+        "kind": "workspace",
+        "relation": "require",
+        "reason": "Provides the pod-wide grant-program kind (per-chain funding programs) this workspace's rounds belong to."
       }
     ],
     "workspace": {
@@ -17202,12 +17308,21 @@ const DATA = {
           "sortDir": "desc"
         }
       },
+      {
+        "name": "Deadlines",
+        "type": "calendar",
+        "scopeProfileSlug": "round",
+        "description": "Upcoming round submission deadlines, on one time axis.",
+        "config": {
+          "dateField": "properties.submissionDeadline",
+          "colorField": "status"
+        }
+      },
       {
         "name": "Awarded Projects",
         "type": "gallery",
         "scopeProfileSlug": "grant-project",
         "config": {
-          "coverField": "summary",
           "showFields": [
             "currentStatus",
             "awardedRoundCount",
@@ -17251,6 +17366,30 @@ const DATA = {
         "type": "submitted_by",
         "label": "Submitted By"
       },
+      {
+        "sourceProfileSlug": "grant_submission",
+        "targetProfileSlug": "contract",
+        "type": "for_contract",
+        "label": "Engagement"
+      },
+      {
+        "sourceProfileSlug": "grant_submission",
+        "targetProfileSlug": "deal",
+        "type": "billed_as",
+        "label": "Billed as"
+      },
+      {
+        "sourceProfileSlug": "round",
+        "targetProfileSlug": "grant-program",
+        "type": "belongs_to",
+        "label": "Program"
+      },
+      {
+        "sourceProfileSlug": "contract",
+        "targetProfileSlug": "grant-program",
+        "type": "pursues",
+        "label": "Pursues"
+      },
       {
         "sourceProfileSlug": "grant-project",
         "targetProfileSlug": "round",
@@ -17276,6 +17415,215 @@ const DATA = {
         "label": "Evidenced By"
       }
     ],
+    "playbooks": [
+      {
+        "name": "Grant Process",
+        "description": "Run an engagement through a grant program end to end — identify fit, draft the application, submit, track the decision, and deliver the tranches. Reads the program's own cadence / tracks / tranche model so one playbook fits every chain.",
+        "goalTemplate": "Advance this engagement ({contract}) through the grant program ({grantProgram}) it is pursuing. FIRST read the program entity's own data — its cadence, submissionTracks, trancheModel, and nextDeadline — plus the client context on the contract, and let THOSE drive the plan: do not assume a chain's mechanics, read them from the program. Then work the stages in order and keep the client's `grant_submission` card as the durable state of record:\n1. Identify — understand the project and which of the program's\n   submissionTracks fit; set the submission `stage` to `scope`.\n2. Draft — write the abstract, then the full proposal (products & services,\n   success criteria, GTM, traction); move `stage` `abstract` → `build` and\n   fill the submission's body fields.\n3. Submit — finalize against the program's nextDeadline and submit; once\n   submitted, set `stage` to `awaiting-results`.\n4. Awaiting — track the decision and keep `status` current\n   (in-review / waiting-client / needs-document / blocked).\n5. Awarded — on a decision, set `outcome` (awarded / rejected / partial)\n   and record the awarded amount.\n6. Delivering — for an award, work the program's trancheModel: fill the\n   tranche deliverables and update trancheCompletion as each milestone ships.\n\nNever fabricate — leave a field blank rather than guess. Every write is proposal-gated for the user to review.",
+        "subjectProfile": {
+          "profileSlug": "contract"
+        },
+        "params": [
+          {
+            "name": "contract",
+            "type": "entity",
+            "profileSlug": "contract",
+            "label": "Engagement",
+            "required": true
+          },
+          {
+            "name": "grantProgram",
+            "type": "entity",
+            "profileSlug": "grant-program",
+            "label": "Grant Program",
+            "required": true
+          }
+        ],
+        "stages": [
+          {
+            "key": "identify",
+            "name": "Identify",
+            "description": "Understand the project and which of the program's submission tracks fit — before any writing.",
+            "goal": "A clear project understanding and the fitting submission track; submission stage = scope."
+          },
+          {
+            "key": "draft",
+            "name": "Draft",
+            "description": "Write the abstract, then the full proposal, from the client's real material.",
+            "goal": "Abstract then full proposal drafted; submission stage abstract → build with body fields filled."
+          },
+          {
+            "key": "submit",
+            "name": "Submit",
+            "description": "Finalize against the program deadline and submit the application.",
+            "goal": "Application submitted on time; submission stage = awaiting-results."
+          },
+          {
+            "key": "awaiting",
+            "name": "Awaiting",
+            "description": "Track the decision and keep the client status current.",
+            "goal": "Submission status reflects where the decision stands (in-review / waiting-client / needs-document / blocked)."
+          },
+          {
+            "key": "awarded",
+            "name": "Awarded",
+            "description": "Record the funder's decision and the awarded amount.",
+            "goal": "Submission outcome set (awarded / rejected / partial) with the awarded amount."
+          },
+          {
+            "key": "delivering",
+            "name": "Delivering",
+            "description": "Work the program's tranche model — ship and record each tranche.",
+            "goal": "Tranche deliverables filled and trancheCompletion updated as milestones ship."
+          }
+        ],
+        "executor": "is-agent",
+        "grants": [
+          "entity.create"
+        ],
+        "status": "active"
+      }
+    ],
+    "automations": [
+      {
+        "key": "grant-submission-sync",
+        "name": "Grant Submission Sync",
+        "description": "Once a day, keep each grant application's grant_submission card current — read the submission's recent activity, assess where the pursuit stands, and advance its stage + status so the pipeline stays the durable, kanban-visible state of record.",
+        "triggerType": "cron",
+        "triggerConfig": {
+          "expression": "0 8 * * *"
+        },
+        "status": "draft",
+        "metadata": {
+          "templateKey": "grant-submission-sync"
+        },
+        "flow": {
+          "nodes": [
+            {
+              "id": "trigger",
+              "type": "trigger",
+              "position": {
+                "x": 0,
+                "y": 0
+              },
+              "data": {
+                "label": "Daily at 08:00",
+                "triggerType": "cron",
+                "config": {
+                  "expression": "0 8 * * *"
+                }
+              }
+            },
+            {
+              "id": "list-submissions",
+              "type": "capability",
+              "position": {
+                "x": 0,
+                "y": 120
+              },
+              "data": {
+                "label": "List grant submissions to maintain",
+                "verbId": "entity.query",
+                "inputMapping": {
+                  "profileSlug": "grant_submission",
+                  "limit": "100"
+                }
+              }
+            },
+            {
+              "id": "submissions-loop",
+              "type": "loop",
+              "position": {
+                "x": 0,
+                "y": 240
+              },
+              "data": {
+                "label": "For each grant submission",
+                "iteratorExpression": "steps.list-submissions.output.entities",
+                "itemVariable": "submission"
+              }
+            },
+            {
+              "id": "read-activity",
+              "type": "messages_query",
+              "position": {
+                "x": 0,
+                "y": 360
+              },
+              "data": {
+                "label": "Read the submission's recent activity",
+                "subjectEntityId": "{{loop.item.id}}",
+                "limit": 40
+              }
+            },
+            {
+              "id": "assess",
+              "type": "capability",
+              "position": {
+                "x": 0,
+                "y": 480
+              },
+              "data": {
+                "label": "Assess the submission's stage + status → JSON",
+                "verbId": "ai.generate",
+                "inputMapping": {
+                  "json": "true",
+                  "maxTokens": "500",
+                  "system": "You are a strict data-extraction function for a grants pipeline. Read a grant application's recent activity and report where the application currently stands. Respond with STRICT JSON and NOTHING else. Never fabricate — if the activity does not clearly indicate a value, keep the submission's current one.",
+                  "prompt": "The grant submission: {{loop.item.title}} Current stage: {{loop.item.properties.stage}} Current status: {{loop.item.properties.status}}\nRecent activity (oldest first): {{steps.read-activity.output.messages}}\nReport the submission's current state as STRICT JSON, using ONLY these vocabularies and NOTHING else: {\n  \"stage\": \"scope|abstract|build|awaiting-results\",\n  \"status\": \"answered|waiting-client|needs-document|in-review|blocked\"\n}"
+                }
+              }
+            },
+            {
+              "id": "advance-submission",
+              "type": "output",
+              "position": {
+                "x": 0,
+                "y": 600
+              },
+              "data": {
+                "label": "Advance the submission stage + status",
+                "outputType": "entity_update",
+                "config": {
+                  "entityId": "{{loop.item.id}}",
+                  "properties": {
+                    "stage": "{{steps.assess.output.stage}}",
+                    "status": "{{steps.assess.output.status}}"
+                  }
+                }
+              }
+            }
+          ],
+          "edges": [
+            {
+              "id": "gs-trigger-list",
+              "source": "trigger",
+              "target": "list-submissions"
+            },
+            {
+              "id": "gs-list-loop",
+              "source": "list-submissions",
+              "target": "submissions-loop"
+            },
+            {
+              "id": "gs-loop-read",
+              "source": "submissions-loop",
+              "target": "read-activity"
+            },
+            {
+              "id": "gs-read-assess",
+              "source": "read-activity",
+              "target": "assess"
+            },
+            {
+              "id": "gs-assess-advance",
+              "source": "assess",
+              "target": "advance-submission"
+            }
+          ]
+        }
+      }
+    ],
     "app": {
       "kind": "stored",
       "cellKey": "entity-detail"
@@ -23941,6 +24289,7 @@ const DATA = {
         "description": "A company or person that provides a capability The Arch can broker a client need against.",
         "scope": "shared",
         "profileKind": "role",
+        "roleCategory": "provider",
         "applicableKinds": [
           "company",
           "person"
@@ -24120,10 +24469,10 @@ const DATA = {
                 "y": 240
               },
               "data": {
-                "label": "List the solution-provider roster",
+                "label": "List the provider roster (any roleCategory=provider)",
                 "verbId": "entity.query",
                 "inputMapping": {
-                  "profileSlug": "solution-provider",
+                  "roleCategory": "provider",
                   "limit": "100"
                 }
               }
@@ -29636,6 +29985,12 @@ const DATA = {
         "kind": "workspace",
         "relation": "require",
         "reason": "The engineering / ops dashboard — the build-side view of the company."
+      },
+      {
+        "slug": "networking",
+        "kind": "workspace",
+        "relation": "require",
+        "reason": "The partner-intro layer — need → intro-matcher → intro → billed_as → deal, with the A↔B confidentiality firewall; the Stellar Client-Sync emits needs that depend on it."
       }
     ],
     "workspace": {

package/src/the-arch.yaml

@@ -50,6 +50,10 @@ dependencies:
     kind: workspace
     relation: require
     reason: "The engineering / ops dashboard — the build-side view of the company."
+  - slug: networking
+    kind: workspace
+    relation: require
+    reason: "The partner-intro layer — need → intro-matcher → intro → billed_as → deal, with the A↔B confidentiality firewall; the Stellar Client-Sync emits needs that depend on it."
 
 workspace:
   name: The Arch

package/src/types.ts

@@ -607,46 +607,44 @@ export interface TemplateExtendsRef {
  * PACKAGE_DEPENDENCY_KINDS — the dependency-kind vocabulary, declared ONCE.
  *
  * This tuple exists so consumers can IMPORT the vocabulary instead of
- * hand-copying it. `TemplateDependency` is currently mirrored by hand in six
- * other places, four of which carry a comment promising they match "VERBATIM so
- * the wire shape never drifts" — a comment doing a type's job. A comment cannot
- * fail a build; an import can. Those mirrors live in repos this package does not
- * own, so this tuple does not fix them by existing — it makes the fix possible:
+ * hand-copying it. `TemplateDependency` is mirrored by hand in several other
+ * places — a comment cannot fail a build, an import can, but these mirrors live
+ * in repos this package does not own, so they must match this list EXACTLY:
  *
- *   - marketplace            `types.ts:102`
- *   - onboarding             `workspace-templates.ts:27`
- *   - synap-backend          `package-definition.ts:204` (exports its own
- *                            `PackageDependencyKind` — the closest peer)
- *   - hub-protocol REST      `rest/packages.ts:140` (zod enum)
- *   - browser                `InstallPackageDialog.tsx:262`
- *   - control-plane-api      `routes/packages.ts:436` (zod enum)
+ *   - marketplace            `features/marketplace/src/types.ts`
+ *   - onboarding             `features/onboarding/src/{templates/workspace-templates,components/WorkspacePreview}.ts(x)`
+ *   - browser                `InstallPackageDialog.tsx`
+ *   - synap-backend          `package-definition.ts` (`PackageDependencyKind`)
+ *   - hub-protocol REST      `rest/packages.ts` (zod enum)
+ *   - control-plane-api      `db/schema/packages.ts` (`TemplateDependency` type)
+ *                            + `routes/packages.ts` (`DEPENDENCY_KINDS` zod enum)
  *
- * ⚠️ `'automation'` IS RETIRED VOCABULARY, deliberately still listed here.
- * CP migration `0049_package_vocabulary` retired the `automation` package
- * category in favour of `workflow` ("workflow — a triggered/sequenced run
- * (absorbs 'automation' + 'playbook')", `PACKAGE_TYPES` in CP
- * `db/schema/packages.ts`). A dependency's `kind` names the TYPE of package it
- * points at, so this vocabulary should track `PACKAGE_TYPES` — meaning the live
- * spelling is `workflow`, not `automation`.
+ * These are the 7 literals the wire accepts, in lockstep with the CP publish
+ * enum (`DEPENDENCY_KINDS = [...PACKAGE_TYPES, "automation"]`, CP
+ * `routes/packages.ts`), the hub install enum (`rest/packages.ts`), and the
+ * backend resolver's `PackageDependencyKind` (`@synap/database`).
  *
- * It is NOT renamed here, on purpose. This is latent, not live: 0/21 templates
- * declare any `kind` other than the default `'workspace'`. And all four wire
- * enums (CP + hub zod, above) still accept `'automation'` and do NOT accept
- * `'workflow'` — so emitting `'workflow'` today would be rejected with a 400 at
- * both doors, and dropping `'automation'` from this tuple would make any
- * consumer that derives a zod enum from it start rejecting a value the wire
- * still legally accepts (a published third-party package may carry it; CP's own
- * schema permits it). Narrowing must therefore follow the wire, not lead it.
+ * Resolver behaviour (backend `package-dependency-resolver.ts`):
+ *   - `workspace`         → resolve+install; the ONLY kind that may `compose`.
+ *   - `capability` / `cell` → resolve+install, always `require`d (presence).
+ *   - `skill` / `workflow` / `view` / `automation` → ACCEPTED and `require`d
+ *     present, surfaced as `required-absent` (non-fatal) — no standalone by-slug
+ *     applier on the pod yet; when one grows, give the kind its own branch.
  *
- * ORDERED FIX (each step deployable alone, no flag day):
- *   1. Widen the CP + hub zod enums to accept BOTH `'automation'` and `'workflow'`.
- *   2. Add `'workflow'` here; mark `'automation'` deprecated; migrate any authored use.
- *   3. Once no payload carries `'automation'`, drop it from the wire enums and this tuple.
+ * `'automation'` is legacy vocabulary: CP migration `0049_package_vocabulary`
+ * renamed the `automation` package category → `workflow` (which absorbs
+ * automation + playbook, `PACKAGE_TYPES` in CP `db/schema/packages.ts`). It
+ * stays accepted on the wire — and therefore in this tuple — for back-compat
+ * with dependencies published before the rename.
  */
 export const PACKAGE_DEPENDENCY_KINDS = [
   "workspace",
   "capability",
-  /** @deprecated Retired by CP 0049 in favour of `workflow`. See note above. */
+  "skill",
+  "workflow",
+  "view",
+  "cell",
+  /** @deprecated Legacy alias for `workflow` (CP 0049). Still accepted on the wire. */
   "automation",
 ] as const;
 
@@ -658,8 +656,8 @@ export interface TemplateDependency {
   slug: string;
   /**
    * What the dependency is. Default `'workspace'`. Only `'workspace'`
-   * dependencies can be `compose`d; `'capability'`/`'automation'` are always
-   * `require`d present without merging.
+   * dependencies can be `compose`d; every other kind is always `require`d
+   * present without merging.
    */
   kind?: PackageDependencyKind;
   /**