@synap-core/workspace-templates 0.10.0 → 0.11.0

package/package.json

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

package/src/__fixtures__/report-automation-flow.json

@@ -175,7 +175,7 @@
         "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
@@ -196,7 +196,7 @@
         "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

package/src/base.yaml

@@ -455,7 +455,7 @@ automations:
                 Notes — {{steps.gather-notes.output.count}} found: {{steps.project-notes.output.result}}
                 People — {{steps.gather-people.output.count}} found: {{steps.project-people.output.result}}
                 Companies — {{steps.gather-companies.output.count}} found: {{steps.project-companies.output.result}}
-              maxTokens: "700"
+              maxTokens: "2000"
             errorHandling:
               continueOnError: true
         - id: relate
@@ -537,7 +537,7 @@ automations:
                 is busy, a company with people but no tasks. Write only observations
                 that span TWO OR MORE records or kinds. If there are none, say what you
                 checked and did not find — never answer with nothing.
-              maxTokens: "700"
+              maxTokens: "2000"
             errorHandling:
               continueOnError: true
         - id: assemble

package/src/blockchain-ecosystem.yaml

@@ -47,6 +47,10 @@ profiles:
     description: A liquidity provider — makes markets and provides depth for a token.
     scope: shared
     profileKind: role
+    # Shared supply-role category → the intro-matcher's roster spans ALL roles
+    # tagged "provider" via entity.query { roleCategory: "provider" } (no per-role
+    # hardcoding). Keep this string in sync with networking.yaml's solution-provider.
+    roleCategory: provider
     applicableKinds:
       - company
       - person
@@ -81,6 +85,10 @@ profiles:
     description: A security firm or individual that audits smart contracts and protocols.
     scope: shared
     profileKind: role
+    # Shared supply-role category → the intro-matcher's roster spans ALL roles
+    # tagged "provider" via entity.query { roleCategory: "provider" } (no per-role
+    # hardcoding). Keep this string in sync with networking.yaml's solution-provider.
+    roleCategory: provider
     applicableKinds:
       - company
       - person
@@ -115,6 +123,10 @@ profiles:
     description: An outsourced engineering studio or build partner.
     scope: shared
     profileKind: role
+    # Shared supply-role category → the intro-matcher's roster spans ALL roles
+    # tagged "provider" via entity.query { roleCategory: "provider" } (no per-role
+    # hardcoding). Keep this string in sync with networking.yaml's solution-provider.
+    roleCategory: provider
     applicableKinds:
       - company
       - person
@@ -149,6 +161,10 @@ profiles:
     description: A brand, growth, or content marketing agency.
     scope: shared
     profileKind: role
+    # Shared supply-role category → the intro-matcher's roster spans ALL roles
+    # tagged "provider" via entity.query { roleCategory: "provider" } (no per-role
+    # hardcoding). Keep this string in sync with networking.yaml's solution-provider.
+    roleCategory: provider
     applicableKinds:
       - company
       - person
@@ -183,6 +199,10 @@ profiles:
     description: A performance / paid-media buying agency.
     scope: shared
     profileKind: role
+    # Shared supply-role category → the intro-matcher's roster spans ALL roles
+    # tagged "provider" via entity.query { roleCategory: "provider" } (no per-role
+    # hardcoding). Keep this string in sync with networking.yaml's solution-provider.
+    roleCategory: provider
     applicableKinds:
       - company
       - person
@@ -217,6 +237,10 @@ profiles:
     description: A key opinion leader or influencer who amplifies reach.
     scope: shared
     profileKind: role
+    # Shared supply-role category → the intro-matcher's roster spans ALL roles
+    # tagged "provider" via entity.query { roleCategory: "provider" } (no per-role
+    # hardcoding). Keep this string in sync with networking.yaml's solution-provider.
+    roleCategory: provider
     applicableKinds:
       - company
       - person
@@ -243,6 +267,88 @@ profiles:
         valueType: string
         inputType: textarea
 
+  # ── Grant Program (the per-chain funding PROGRAM — parent of a round) ───────
+  # The 3-layer grants spine is PROGRAM ≠ ROUND ≠ APPLICATION. `round` (in
+  # grants.yaml) is the funding-cycle/deadline carrier; a program is the
+  # long-lived, chain-scoped funder above it (e.g. Stellar SCF, Optimism RetroPGF).
+  # It lives HERE, with the web3 vocabulary, because a program IS a blockchain-
+  # ecosystem thing (it carries a `blockchain` and program mechanics), and it is
+  # a real-world entity referenced from every workspace — hence pod-wide, mirroring
+  # company/person in ecosystem.yaml (`entityScope: pod`). `scope: shared` makes
+  # the profile DEF pod-wide too, so a REUSING template (grants.yaml `require`s this
+  # overlay) resolves `grant-program` for its `round → belongs_to → grant-program`
+  # edge and deadline view. `defaultPlaybook` is a text ref for now — Wave 2 will
+  # create the actual per-chain playbook and bind it.
+  - 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
+        # Defaults to the BASE grant playbook (grants.yaml `Grant Process`), the
+        # data-driven process that reads THIS program's cadence/tracks/tranche
+        # model at runtime. Override per-program only for a differently-shaped chain.
+        constraints:
+          defaultValue: Grant Process
+      - slug: description
+        label: Description
+        valueType: string
+        inputType: textarea
+
 # Web3 actor↔actor relations (company→company). `company` resolves from the
 # Ecosystem base — not redeclared here.
 entityLinks:

package/src/catalog.ts

@@ -33,6 +33,20 @@ import type { WorkspaceYaml } from "./types.js";
 // Inputs
 // ============================================================================
 
+/**
+ * A lightweight, QUERY-TIME summary of one sub-object a package carries (a cell
+ * today; the shape generalizes to views/automations without change). Rides the
+ * catalog LIST projection so a surface can match/surface a sub-item WITHOUT the
+ * full `definition` — it carries `key + name` only, never the sub-object's code.
+ * `kind` is DERIVED (in the CP SELECT, from which sub-array the row came from),
+ * never a stored taxonomy.
+ */
+export interface PackageItemSummary {
+  kind: string;
+  key: string;
+  name: string;
+}
+
 /**
  * A bundled template — the canonical `WorkspaceYaml` this package ships. Callers
  * pass `listPublicTemplates()` (18) or `listWorkspaceTemplates()` (21); the door
@@ -69,6 +83,13 @@ export interface RemoteEntry {
    * never "unknown-so-hide".
    */
   isPrivate?: boolean;
+  /**
+   * Lightweight computed summary of the row's sub-objects (cells), carried on the
+   * LIST projection so a surface can surface a matching sub-item without the full
+   * `definition`. `undefined` on sources that don't compute it (bundled) — treated
+   * as "no known sub-items". See `PackageItemSummary`.
+   */
+  items?: PackageItemSummary[];
   /**
    * The CP `definition` jsonb — opaque install payload. The door reads only
    * `definition.sourcePackage.version` (the winner signal). Absent on browse rows
@@ -128,6 +149,11 @@ export interface CpPackageRow {
   icon?: string | null;
   /** Present only on `/mine` rows. `false` ⇒ private. Browse rows omit it. */
   isPublic?: boolean;
+  /**
+   * Computed sub-object summary from `GET /api/packages` / `/mine` (query-time,
+   * not a stored column). Carries `key + name` per cell; never the cell code.
+   */
+  items?: PackageItemSummary[];
 }
 
 /**
@@ -154,6 +180,7 @@ export function rowToRemoteEntry(
     tags: row.tags ?? [],
     icon: row.icon ?? null,
     isPrivate,
+    items: row.items,
     // Both list routes strip `definition`; absence ⇒ bundle wins a slug conflict,
     // and the install path fetches the full definition per-slug when needed.
   };
@@ -175,6 +202,12 @@ interface CatalogEntryBase {
   icon?: string | null;
   /** `true` ⇒ not publicly listed (internal bundled template, or private CP row). */
   isPrivate: boolean;
+  /**
+   * The entry's sub-object summary (cells). Always present (defaults to `[]`) so a
+   * consumer can match sub-items uniformly. Bundled workspace templates carry no
+   * cells → `[]` (honest); a remote row carries its CP-computed `items`.
+   */
+  items: PackageItemSummary[];
 }
 
 /** A catalog entry backed by a bundled template. Install via `toWorkspaceDefinition()` / `toPackageDefinition()` on `template`. */
@@ -256,6 +289,8 @@ function bundledToEntry(tpl: WorkspaceYaml): BundledCatalogEntry {
     tags: tpl.meta.tags ?? [],
     icon: tpl.meta.icon,
     isPrivate: tpl.meta.isPublic === false,
+    // Bundled workspace templates carry no cells — be honest, not `undefined`.
+    items: [],
     template: tpl,
   };
 }
@@ -271,6 +306,7 @@ function remoteToEntry(row: RemoteEntry): RemoteCatalogEntry {
     tags: row.tags ?? [],
     icon: row.icon ?? null,
     isPrivate: row.isPrivate ?? false,
+    items: row.items ?? [],
     remote: row,
   };
 }

package/src/grants.yaml

@@ -43,6 +43,16 @@ dependencies:
     kind: workspace
     relation: require
     reason: "Provides the pod-wide client / partner / sponsor role vocabulary this workspace reuses."
+  # This template REFERENCES the pod-wide `grant-program` kind (the per-chain
+  # funding-program parent) that the blockchain-ecosystem overlay defines. The
+  # 3-layer grants spine is program → round → grant_submission: `round` (owned
+  # here) `belongs_to` a `grant-program` (owned there). `require` installs that
+  # overlay FIRST so `grant-program` exists (pod-wide) before this template
+  # provisions the edge + deadline view — same deps-first pattern as foundation.
+  - 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:
   name: Grants Pipeline
@@ -873,11 +883,26 @@ views:
         - averageAwardAmount
       sortBy: roundNumber
       sortDir: desc
+  # Round deadlines on one time axis. Scoped to `round` ONLY: rounds are the
+  # deadline SSOT (they carry `submissionDeadline`); `grant-program` carries
+  # `nextDeadline`, which the calendar's dateField fallback chain
+  # (dueDate/startDate/startTime/date) never resolves, so a program would land
+  # dateless in the "Unscheduled" backlog. Plotting programs + rounds on ONE
+  # timeline is a deferred UI-phase item. `colorField` (NOT `colorBy` — the
+  # calendar adapter reads `colorField`) colors each round by its status.
+  - name: Deadlines
+    type: calendar
+    scopeProfileSlug: round
+    description: Upcoming round submission deadlines, on one time axis.
+    config:
+      dateField: properties.submissionDeadline
+      colorField: status
+  # No `coverField`: grant-project has no image property (`summary` is prose, so it
+  # rendered as a text/blank cover). Fall back to the gallery's clean default cover.
   - name: Awarded Projects
     type: gallery
     scopeProfileSlug: grant-project
     config:
-      coverField: summary
       showFields:
         - currentStatus
         - awardedRoundCount
@@ -907,6 +932,35 @@ entityLinks:
     targetProfileSlug: company
     type: submitted_by
     label: Submitted By
+  # The application belongs to the engagement that pursued it (contract lives in
+  # the composed operations base). Closes the spine on the submission side.
+  - sourceProfileSlug: grant_submission
+    targetProfileSlug: contract
+    type: for_contract
+    label: Engagement
+  # The commercial bridge: a grant application maps to its fee/commission `deal`,
+  # so a grant win is tied to the money. Mirrors networking.yaml's canonical
+  # `intro → billed_as → deal` commercial-mapping predicate (same edge type,
+  # reused for one consistent meaning across the pod graph). `deal` resolves here
+  # because it is a SYSTEM profile (validate.ts `SYSTEM_PROFILES`) — so this needs
+  # NO crm compose (grants stays an operations overlay, not a CRM). The deal lives
+  # in the CRM workspace; this is a cross-workspace relation, consistent with
+  # grant_submission's other cross-domain edges (submitted_by → company).
+  - sourceProfileSlug: grant_submission
+    targetProfileSlug: deal
+    type: billed_as
+    label: Billed as
+  # 3-layer spine: a round is one cycle OF a long-lived program (SCF #42 → SCF).
+  - sourceProfileSlug: round
+    targetProfileSlug: grant-program
+    type: belongs_to
+    label: Program
+  # The engagement pursues a program (contract lives in the composed operations
+  # base; grant-program in the required blockchain-ecosystem overlay).
+  - sourceProfileSlug: contract
+    targetProfileSlug: grant-program
+    type: pursues
+    label: Pursues
   - sourceProfileSlug: grant-project
     targetProfileSlug: round
     type: appears_in
@@ -923,6 +977,199 @@ entityLinks:
     targetProfileSlug: grant_submission
     type: evidenced_by
     label: Evidenced By
+
+# The BASE grant playbook — ONE reusable, data-driven process that runs an
+# engagement through ANY program. Chain-specifics (cadence, submissionTracks,
+# trancheModel, nextDeadline) are READ from the `grantProgram` entity at runtime,
+# NOT hardcoded per chain — so one playbook serves Stellar SCF, Optimism RetroPGF,
+# etc. Only a genuinely different-SHAPED program later earns its own override
+# playbook (base + data-driven-override decision). Generalizes the Stellar staged
+# advisor (CP `stellar-grant-client`) into a template. Bound to `contract` (the
+# engagement, per decision — NOT company); targets a `grant-program` param — the
+# 3-layer spine (contract → grant-program → round → grant_submission) made runnable.
+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:
+
+      1. Identify — understand the project and which of the program's
+         submissionTracks fit; set the submission `stage` to `scope`.
+      2. Draft — write the abstract, then the full proposal (products & services,
+         success criteria, GTM, traction); move `stage` `abstract` → `build` and
+         fill the submission's body fields.
+      3. Submit — finalize against the program's nextDeadline and submit; once
+         submitted, set `stage` to `awaiting-results`.
+      4. Awaiting — track the decision and keep `status` current
+         (in-review / waiting-client / needs-document / blocked).
+      5. Awarded — on a decision, set `outcome` (awarded / rejected / partial)
+         and record the awarded amount.
+      6. Delivering — for an award, work the program's trancheModel: fill the
+         tranche deliverables and update trancheCompletion as each milestone ships.
+
+      Never 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 }
+    # Generic stages, mapped onto grant_submission's own stage/status/outcome +
+    # tranche vocab so the run can maintain the card as it advances.
+    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
+
+# Makes the spine ALIVE: a daily maintenance run that keeps each grant
+# application's `grant_submission` card current (advances stage + status) — the
+# durable, kanban-visible state of record. Generalizes the Stellar CP "Client
+# Sync" automation (read comms → assess → advance submission) into a chain-
+# AGNOSTIC workspace-template automation: it advances using grant_submission's
+# OWN stage/status vocab, so it works for any program (no Stellar-specific
+# assumptions). Same fan-out-safe shape the corpus uses (cron → in-flow `query`
+# → `loop`), NOT the `inputStrategy:'query'` playbook fan-out (which has the
+# known gap).
+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 * * *"
+    # DRAFT by default (deliberate safety): this runs a paid AI assess per
+    # grant_submission every day, so installing the suite must NOT silently start
+    # paid runs. Flip to `active` to let the pipeline self-maintain — same
+    # enabled-off-by-default convention as the radar / CRM-hygiene playbooks.
+    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 * * *"
+
+        # READ-ONLY builtin + SELECTION. The grant_submission cards ARE the grant
+        # pursuits (each is created by the `Grant Process` playbook at pursuit
+        # start), so querying them directly is the safe selection: it touches ONLY
+        # real pursuits and never fabricates a card for a non-grant contract.
+        #
+        # ── CREATE-IF-MISSING (deferred, flagged) ────────────────────────────
+        # The Stellar reference does create-if-missing by querying its subject
+        # (companies) and upserting the submission. Generalizing that safely means
+        # selecting "contracts that PURSUE a grant program" — but `entity.query`
+        # filters JSONB PROPERTIES only, it cannot filter by a `pursues` EDGE, and
+        # there is no query-fan-out capability to enumerate edge-linked subjects.
+        # Querying ALL contracts and creating a card per contract would spuriously
+        # create submissions for every non-grant engagement. So creation stays the
+        # `Grant Process` playbook's job (the agent creates the card when a pursuit
+        # begins) and this automation MAINTAINS. Fully-generalized create-if-
+        # missing needs an edge-aware selection capability that does not exist yet.
+        - 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
+
+        # READ-ONLY builtin. Recent activity on THIS submission's thread — the raw
+        # signal the assess pass reads to place the pursuit's stage/status.
+        - 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
+
+        # READ-ONLY (pure compute). ONE assess pass → STRICT JSON naming the
+        # submission's current stage + status, constrained to grant_submission's
+        # OWN enum vocab so it maps straight back onto the card (chain-agnostic).
+        - 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}}
+
+                Recent activity (oldest first):
+                {{steps.read-activity.output.messages}}
+
+                Report the submission's current state as STRICT JSON, using ONLY
+                these vocabularies and NOTHING else:
+                {
+                  "stage": "scope|abstract|build|awaiting-results",
+                  "status": "answered|waiting-client|needs-document|in-review|blocked"
+                }
+
+        # GOVERNED WRITE via `output/entity_update` — advances the card's stage +
+        # status (the durable, kanban-visible state). Governed like every output
+        # write: routes to a proposal for review unless auto-approved.
+        - 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

package/src/networking.yaml

@@ -212,6 +212,11 @@ profiles:
     description: A company or person that provides a capability The Arch can broker a client need against.
     scope: shared
     profileKind: role
+    # Shared supply-role category — the intro-matcher's roster is now
+    # entity.query { roleCategory: "provider" }, spanning EVERY role tagged
+    # "provider" (this one in a public install; + blockchain-ecosystem's web3
+    # supply roles when The Arch installs both). One string, kept in sync there.
+    roleCategory: provider
     applicableKinds:
       - company
       - person
@@ -365,15 +370,21 @@ automations:
               limit: "100"
 
         # READ-ONLY builtin. The provider roster to match against — companies /
-        # people wearing the pod-wide `solution-provider` role.
+        # people wearing ANY role tagged `roleCategory: "provider"`. Dynamic by
+        # design: a public install matches its `solution-provider`s; The Arch
+        # (which also installs blockchain-ecosystem) additionally matches the web3
+        # supply roles; any future supply role tagged "provider" auto-joins with
+        # ZERO edits here. No `profileSlug` → no per-role hardcoding, no dependency
+        # on blockchain-ecosystem (a public installer simply has no web3 roles to
+        # match, so nothing leaks).
         - id: list-providers
           type: capability
           position: { x: 0, 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"
 
         - id: needs-loop