@synap-core/workspace-templates 0.11.0 → 0.12.0

package/src/validate-flow.ts

@@ -667,7 +667,17 @@ function collectLoopBindingRefs(data: unknown): string[] {
       return;
     }
     if (isRecord(v)) {
-      for (const x of Object.values(v)) walk(x);
+      // Skip AUTHORING NOTES. An `_`-prefixed key is documentation the runtime
+      // never evaluates (`_filterNote` and friends explain what DOWNSTREAM
+      // nodes do, and so legitimately quote `{{loop.item...}}` in prose).
+      // Reading them as live references made a correct flow fail validation:
+      // `stellar-grant-client` was reported as "references {{loop.item}} but is
+      // not inside a loop body" purely because its note DESCRIBED the nodes
+      // that do. Kept identical in all three copies of this walker.
+      for (const [k, x] of Object.entries(v)) {
+        if (k.startsWith("_")) continue;
+        walk(x);
+      }
     }
   };
   walk(data);

package/src/validate.test.ts

@@ -80,6 +80,92 @@ describe("validateTemplate — clean template", () => {
   });
 });
 
+describe("validateTemplate — system Knowledge contract", () => {
+  const template = (overrides: Record<string, unknown> = {}): WorkspaceYaml =>
+    ({
+      meta: {
+        slug: "knowledge-consumer",
+        name: "Knowledge consumer",
+        description: "d",
+        icon: "brain",
+        color: "#000000",
+      },
+      workspace: { name: "Knowledge consumer", description: "d" },
+      profiles: [{ slug: "gadget", displayName: "Gadget", properties: [] }],
+      views: [
+        {
+          name: "Knowledge",
+          type: "table",
+          scopeProfileSlug: "knowledge",
+          config: { columns: ["title", "knowledgeForm"] },
+        },
+      ],
+      ...overrides,
+    }) as WorkspaceYaml;
+
+  it("allows templates to consume system Knowledge without redeclaring it", () => {
+    const result = validateTemplate(
+      template({
+        seedEntities: [
+          {
+            profileSlug: "knowledge",
+            title: "Write migrations that preserve meaning",
+            properties: { knowledgeForm: "insight" },
+          },
+        ],
+      })
+    );
+
+    expect(result, JSON.stringify(result.errors)).toEqual({ ok: true, errors: [] });
+  });
+
+  it("rejects a template-owned Knowledge profile", () => {
+    const result = validateTemplate(
+      template({
+        profiles: [
+          {
+            slug: "knowledge",
+            displayName: "Knowledge",
+            properties: [
+              {
+                slug: "ek_type",
+                label: "Type",
+                valueType: "string",
+                inputType: "select",
+                enumValues: ["gotcha", "lesson"],
+              },
+            ],
+          },
+        ],
+      })
+    );
+
+    expect(result.ok).toBe(false);
+    expect(
+      result.errors.some((error) => error.rule === "system-profile-redefined")
+    ).toBe(true);
+  });
+
+  it("rejects a legacy or missing Knowledge form on seeded Knowledge", () => {
+    const result = validateTemplate(
+      template({
+        seedEntities: [
+          {
+            profileSlug: "knowledge",
+            title: "Legacy knowledge",
+            properties: { ek_type: "gotcha" },
+          },
+        ],
+      })
+    );
+
+    expect(result.ok).toBe(false);
+    expect(
+      result.errors.map((error) => error.rule).sort()
+    ).toEqual(["knowledge-seed-form-invalid", "knowledge-seed-legacy-form"]);
+  });
+});
+
 // Regression: before wiring `validateFlowDefinition` into validateTemplate, a
 // template automation with a broken FLOW (bogus node type / dangling edge / cycle
 // / typo'd channelType) passed the template gate green and then silently never

package/src/validate.ts

@@ -159,6 +159,22 @@ export const SYSTEM_PROFILES = new Set([
   "report",
 ]);
 
+/**
+ * System-owned profiles whose schema is defined by the pod, rather than by a
+ * workspace template. A template may scope a view, link, sidebar item, or seed
+ * entity to `knowledge` because it is in {@link SYSTEM_PROFILES}; it must never
+ * declare the profile itself. Re-declaring it would turn a shared contract into
+ * whichever template happened to be applied first.
+ *
+ * `knowledgeForm` is intentionally an enum property on the Knowledge kind, not
+ * a facet/role: a knowledge entity has exactly one form, while Synap roles are
+ * additive. Keep this guard local to the template corpus; the actual profile
+ * schema and its migration are owned by the backend seeder.
+ */
+const TEMPLATE_FORBIDDEN_SYSTEM_PROFILE_SLUGS = new Set(["knowledge"]);
+const KNOWLEDGE_FORMS = new Set(["insight", "caution"]);
+const LEGACY_KNOWLEDGE_SEED_FIELDS = new Set(["ek_type", "type"]);
+
 // ── Dependency-vocabulary closure (compose vs require semantics) ─────────────
 
 /**
@@ -396,6 +412,20 @@ export function validateTemplate(
   const known = (s: string) =>
     slugs.has(s) || SYSTEM_PROFILES.has(s) || baseProfileSlugs.has(s);
 
+  // ── System-owned Knowledge contract ─────────────────────────────────────
+  // `knowledge` is available to every template through SYSTEM_PROFILES. It is
+  // not an overlay point: allowing a template to declare it lets a workspace
+  // fork its base property definitions, enum vocabulary, or profile row-level
+  // metadata. Templates consume it through views/links/seeds only.
+  for (const profile of tpl.profiles || []) {
+    if (!TEMPLATE_FORBIDDEN_SYSTEM_PROFILE_SLUGS.has(profile.slug)) continue;
+    add(
+      "system-profile-redefined",
+      `profiles.${profile.slug}`,
+      `Profile "${profile.slug}" is system-owned. Reference it from views, links, sidebar items, or seedEntities; do not declare template-owned properties or metadata.`
+    );
+  }
+
   // Views: structured views need a scope; scoped profiles must resolve.
   for (const v of tpl.views || []) {
     const type = String(v.type || "").toLowerCase();
@@ -579,6 +609,25 @@ export function validateTemplate(
         "seedEntities",
         `seedEntity references unknown profile "${s.profileSlug}"`
       );
+
+    if (s.profileSlug !== "knowledge") continue;
+    const properties = s.properties ?? {};
+    for (const field of LEGACY_KNOWLEDGE_SEED_FIELDS) {
+      if (!(field in properties)) continue;
+      add(
+        "knowledge-seed-legacy-form",
+        `seedEntities.${s.title}.properties.${field}`,
+        `Knowledge seed entities use "knowledgeForm" ("insight" | "caution"), not the legacy "${field}" field.`
+      );
+    }
+    const form = properties.knowledgeForm;
+    if (!KNOWLEDGE_FORMS.has(String(form))) {
+      add(
+        "knowledge-seed-form-invalid",
+        `seedEntities.${s.title}.properties.knowledgeForm`,
+        `Knowledge seed entities require knowledgeForm to be "insight" or "caution".`
+      );
+    }
   }
 
   // profileSlug referential integrity, part 2 — every OTHER site that names a

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

@@ -1,393 +0,0 @@
-{
-  "nodes": [
-    {
-      "id": "trigger",
-      "type": "trigger",
-      "position": {
-        "x": 0,
-        "y": 200
-      },
-      "data": {
-        "triggerType": "manual",
-        "label": "Run report",
-        "config": {}
-      }
-    },
-    {
-      "id": "now",
-      "type": "compute",
-      "position": {
-        "x": 200,
-        "y": 200
-      },
-      "data": {
-        "label": "Timestamp",
-        "operation": "now"
-      }
-    },
-    {
-      "id": "gather-tasks",
-      "type": "query",
-      "position": {
-        "x": 420,
-        "y": 20
-      },
-      "data": {
-        "label": "Tasks",
-        "profileSlug": "task",
-        "filter": "{\"updatedAt\": {\"$gte\": \"{{trigger.payload.since}}\"}}",
-        "orderBy": "updatedAt",
-        "orderDir": "desc",
-        "limit": 25,
-        "errorHandling": {
-          "continueOnError": true
-        }
-      }
-    },
-    {
-      "id": "gather-notes",
-      "type": "query",
-      "position": {
-        "x": 420,
-        "y": 140
-      },
-      "data": {
-        "label": "Notes",
-        "profileSlug": "note",
-        "filter": "{\"updatedAt\": {\"$gte\": \"{{trigger.payload.since}}\"}}",
-        "orderBy": "updatedAt",
-        "orderDir": "desc",
-        "limit": 15,
-        "errorHandling": {
-          "continueOnError": true
-        }
-      }
-    },
-    {
-      "id": "gather-people",
-      "type": "query",
-      "position": {
-        "x": 420,
-        "y": 260
-      },
-      "data": {
-        "label": "People",
-        "profileSlug": "person",
-        "filter": "{\"updatedAt\": {\"$gte\": \"{{trigger.payload.since}}\"}}",
-        "orderBy": "updatedAt",
-        "orderDir": "desc",
-        "limit": 15,
-        "errorHandling": {
-          "continueOnError": true
-        }
-      }
-    },
-    {
-      "id": "gather-companies",
-      "type": "query",
-      "position": {
-        "x": 420,
-        "y": 380
-      },
-      "data": {
-        "label": "Companies",
-        "profileSlug": "company",
-        "filter": "{\"updatedAt\": {\"$gte\": \"{{trigger.payload.since}}\"}}",
-        "orderBy": "updatedAt",
-        "orderDir": "desc",
-        "limit": 15,
-        "errorHandling": {
-          "continueOnError": true
-        }
-      }
-    },
-    {
-      "id": "project-tasks",
-      "type": "transform",
-      "position": {
-        "x": 540,
-        "y": 20
-      },
-      "data": {
-        "label": "Project tasks",
-        "expression": "{{steps.gather-tasks.output.entities}} | map: {{item.id}} · {{item.title}} · status={{item.properties.status}} · priority={{item.properties.priority}} · due={{item.properties.dueDate}} · updated={{item.updatedAt}}",
-        "errorHandling": {
-          "continueOnError": true
-        }
-      }
-    },
-    {
-      "id": "project-notes",
-      "type": "transform",
-      "position": {
-        "x": 540,
-        "y": 140
-      },
-      "data": {
-        "label": "Project notes",
-        "expression": "{{steps.gather-notes.output.entities}} | map: {{item.id}} · {{item.title}} · updated={{item.updatedAt}}",
-        "errorHandling": {
-          "continueOnError": true
-        }
-      }
-    },
-    {
-      "id": "project-people",
-      "type": "transform",
-      "position": {
-        "x": 540,
-        "y": 260
-      },
-      "data": {
-        "label": "Project people",
-        "expression": "{{steps.gather-people.output.entities}} | map: {{item.id}} · {{item.title}} · email={{item.properties.email}} · lastInteraction={{item.properties.lastInteractionAt}} · updated={{item.updatedAt}}",
-        "errorHandling": {
-          "continueOnError": true
-        }
-      }
-    },
-    {
-      "id": "project-companies",
-      "type": "transform",
-      "position": {
-        "x": 540,
-        "y": 380
-      },
-      "data": {
-        "label": "Project companies",
-        "expression": "{{steps.gather-companies.output.entities}} | map: {{item.id}} · {{item.title}} · industry={{item.properties.industry}} · location={{item.properties.location}} · updated={{item.updatedAt}}",
-        "errorHandling": {
-          "continueOnError": true
-        }
-      }
-    },
-    {
-      "id": "analyze",
-      "type": "capability",
-      "position": {
-        "x": 660,
-        "y": 200
-      },
-      "data": {
-        "label": "Analyze",
-        "verbId": "ai.generate",
-        "verbKind": "read",
-        "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": "2000"
-        },
-        "errorHandling": {
-          "continueOnError": true
-        }
-      }
-    },
-    {
-      "id": "relate",
-      "type": "capability",
-      "position": {
-        "x": 900,
-        "y": 200
-      },
-      "data": {
-        "label": "Patterns",
-        "verbId": "ai.generate",
-        "verbKind": "read",
-        "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": "2000"
-        },
-        "errorHandling": {
-          "continueOnError": true
-        }
-      }
-    },
-    {
-      "id": "assemble",
-      "type": "capability",
-      "position": {
-        "x": 1140,
-        "y": 200
-      },
-      "data": {
-        "label": "Assemble",
-        "verbId": "ai.generate",
-        "verbKind": "read",
-        "inputMapping": {
-          "system": "You are the ASSEMBLER round of a Synap workspace report. You compose the FINAL\ndocument body in Synap-flavoured markdown. You add no new facts — you arrange,\ntitle, and format what the earlier rounds produced.\n\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.\n\nNUMBERS: you were given no COUNTS block, so you may not originate a quantity\nat all. Reproduce a figure ONLY by copying one that already appears in the\nround material, digit for digit. Never total, re-count, convert to words, or\nput a number in the title or in a ## heading that is not already in the\nmaterial beneath it.\n\nSYNAP MARKDOWN SYNTAX — these rules are absolute:\n1. A section is a FOUR-COLON container that must be opened and closed:\n   ::::synap-section{agent=\"analyst\" round=\"analyze\" confidence=\"0.8\"}\n   ...content...\n   ::::\n2. Leaf embeds use THREE colons and MUST BE CLOSED with their own ::: line.\n   There is NO self-closing form. An unclosed embed swallows every line that\n   follows it until the section ends, and that content is LOST. Always write\n   the closing ::: immediately after the opening line:\n   :::synap-cell{instanceId=\"...\"}\n   :::\n   :::synap-view{viewId=\"...\"}\n   :::\n   :::synap-entity{id=\"...\"}\n   :::\n3. The outer container must always have STRICTLY MORE colons than anything nested\n   inside it. Four outside, three inside. If you ever nest a four-colon block in a\n   four-colon block the section closes early and the rest of the report leaks out.\n4. ATTRIBUTE VALUES MUST BE QUOTED. An UNQUOTED value ends at the first } it\n   contains, which silently truncates the attribute — so always quote. Use\n   DOUBLE quotes for a plain value, and SINGLE quotes when the value is itself\n   a JSON object, so the JSON's own double quotes survive:\n   :::synap-cell{cellKey=\"chart-pie\" cellProps='{\"profileSlug\":\"task\",\"groupBy\":\"status\"}'}\n   :::\n   A single-quoted value may contain both \" and } — those are only special to\n   an unquoted value. Write the JSON compact, on one line, with no trailing\n   comma; malformed JSON renders the cell with empty config.\n5. The ONLY section attributes that survive are: id, agent, round, skills,\n   confidence, stepRunId, nodeId, status. Anything else is silently dropped.\n6. confidence is a 0-1 ratio written as a decimal string, e.g. confidence=\"0.8\".\n   Never a percentage.\n7. CHIPS ARE CONTENT — COPY THEM THROUGH VERBATIM. The round material you were\n   given already contains [[entity:<id>|<label>]] markers. Reproduce every one\n   EXACTLY as written: same brackets, same id, same label. Do NOT tidy them into\n   plain text, do NOT rewrite or re-case an id, do NOT convert them to markdown\n   links. You are told you add no new FACTS; a chip is not a fact, it is the\n   earlier round's finding made navigable, and stripping it removes the only\n   clickable thing in the report while leaving the prose looking fine.\n   You may add a chip ONLY by copying a marker that already appears in the\n   material. Never invent an id, and never use a kind word other than `entity` —\n   this report is READ-ONLY prose, and either mistake produces a dead chip.\n8. NEVER EMIT :::synap-view, AND NEVER EMIT :::synap-cell WITH AN instanceId.\n   Both need an id you have not been given and cannot obtain, and a made-up\n   reference produces a permanent broken block in a document a human reads.\n9. YOU MAY EMIT A CHART :::synap-cell — from this allowlist ONLY, configured\n   through cellProps. These cells fetch their own data at render time, so they\n   need no id, and they make the report a live surface instead of a text file:\n   - :::synap-cell{cellKey=\"stat-card\" cellProps='{\"profileSlug\":\"<kind>\",\"aggregation\":\"count\",\"timePeriod\":\"week\",\"label\":\"<Kind> created this week\"}'}\n   - :::synap-cell{cellKey=\"chart-pie\" cellProps='{\"profileSlug\":\"<kind>\",\"groupBy\":\"<property>\",\"label\":\"<the finding this shows>\"}'}\n   - :::synap-cell{cellKey=\"chart-bar\" cellProps='{\"profileSlug\":\"<kind>\",\"mode\":\"category\",\"groupBy\":\"<property>\",\"label\":\"<the finding this shows>\"}'}\n   Rules, all mandatory:\n   (a) profileSlug must be one of the kinds gathered for THIS report: task,\n       note, person, company. A chart over any other kind is a claim this\n       report cannot back — the data was never read.\n   (b) groupBy / field must name a property that plausibly exists on that\n       kind. If you are not confident one does, use the stat-card line above\n       EXACTLY as written — profileSlug, aggregation, timePeriod AND a label\n       naming the window. Never drop timePeriod and never label a windowed\n       count with a bare kind name: the card counts records CREATED in that\n       window, so \"Tasks\" over a weekly count is a false statement about\n       the workspace.\n   (c) Close EVERY embed with its own ::: line, per rule 2. An unclosed embed\n       swallows the rest of the section.\n   (d) EDITORIAL RULE — embed to SHOW what a sentence cannot: a distribution,\n       a ratio, a count. Never to decorate. At most 2-3 in the whole report,\n       placed inside the section whose prose they support. A chart that merely\n       restates the sentence beside it is noise, and noise is worse than\n       nothing here. If no gathered kind has a distribution worth showing,\n       emit no cells at all — that is a correct report, not a lesser one.\n   (e) AT MOST ONE cell per section, and NEVER at the top of a section.\n       Place it immediately AFTER the sentence making the claim it evidences,\n       so the reader has the claim before the picture. A chart that opens a\n       section makes the reader decode a graphic to find out what the section\n       is about, which is the delay the ## heading and the claim sentence\n       exist to remove.\n   (f) The label must state the FINDING, not the dimension. Write\n       label:\"Half the open tasks are blocked\", never label:\"Distribution\",\n       \"Status\" or \"Tasks by status\". Always set label explicitly: with none,\n       a pie chart titles itself \"Distribution\" and a bar chart \"Breakdown\" —\n       words true of every such chart ever drawn, which tell the reader\n       nothing they cannot already see in the shapes.\n   (g) A CHART IS A LIVE VIEW, THE PROSE IS A SNAPSHOT. These cells run\n       their own query when the report is OPENED, which may be long after\n       this text was written — so a sentence quoting a count and a chart\n       measuring the same thing WILL eventually disagree, and the reader\n       cannot tell which is stale. Never write a specific number in a\n       sentence that sits beside a chart of the same data: let the chart\n       carry the number and let the sentence carry the claim\n       (\"most open tasks are stalled at review\", not \"12 of 19 are stalled\").\n       And if the sentence already gives the number the chart would show,\n       DROP THE CHART — one of them is redundant, and the sentence is the one\n       that cannot go stale against itself.\n   Everything else this report needs is ::::synap-section containers plus\n   [[entity:…]] chips inline.\n\n10. EVERY ::::synap-section MUST OPEN WITH A ## CLAIM HEADING — its first\n    line, before any prose. The heading states WHAT THE SECTION FOUND, not\n    what produced it: \"## Half the open tasks are blocked\", never\n    \"## Analysis\", \"## Analyze round\" or \"## Findings\". Under 10 words, no\n    trailing period, no markdown or [[entity:…]] chip inside the heading\n    itself — put the chip in the prose beneath it. Write exactly one ## per\n    section. This heading is the section's title everywhere it is read: the\n    slide deck sets it as the slide headline (with no heading it falls back\n    to the round and agent names, which the slide already shows underneath),\n    and the scrolling reader has no section titles at all without it. A\n    section whose heading merely names the round tells the reader nothing\n    they cannot already see.\n\nSTRUCTURE: one ::::synap-section per round, in order — analyze, then relate.\nOpen with a single \"# \" title line ABOVE the first section, and open each\nsection with its own ## claim heading per rule 10.\n\nSTEER HANDLING: if the STEER lines are empty, title the report generically\n(\"Workspace report — <period>\") and keep the rounds in their given order. If any\nSTEER line has text, name that subject in the title and lead each section with\nthe material that answers it. Never add facts the rounds did not give you.\n\nMISSING ROUNDS: if a round's material looks like {\"error\": \"...\"} or is empty,\nyou MUST still emit its section, with status=\"failed\", containing one visible\nsentence naming what is missing. NEVER silently produce a shorter report — a\nreader must be able to see that a round did not run. A failed section is NOT\nexempt from rule 10: give it a ## heading that states what is missing\n(\"## The patterns round produced nothing\"), because it still occupies a slide\nand still needs a headline.\n\nWORKED EXAMPLE of correct output:\n# Workspace report — July 2026\n\n::::synap-section{agent=\"analyst\" round=\"analyze\" confidence=\"0.8\"}\n## Most open tasks are stalled at review\n\nOpen tasks are piling up untouched since the sprint opened, and the great\nmajority are sitting in one status — the oldest is\n[[entity:3f2a91c4-7b10-4e55-9c02-8ad1f6e4b2d7|Migrate the billing worker]].\nNotes are thin.\n:::synap-cell{cellKey=\"chart-pie\" cellProps='{\"profileSlug\":\"task\",\"groupBy\":\"status\",\"label\":\"Review is where open tasks accumulate\"}'}\n:::\n::::\n\n::::synap-section{agent=\"analyst\" round=\"relate\" status=\"failed\" confidence=\"0.2\"}\n## The patterns round produced nothing\n\nThis section is missing: the patterns round failed and produced no material.\n::::\n\nBe CONCISE — your entire output must fit in 2000 tokens. Emit ONLY the markdown\ndocument. No preamble, no explanation, no code fences around the whole thing.",
-          "prompt": "STEER:\n- Prompt: {{trigger.payload.prompt}}\n- Focus: {{trigger.payload.focus}}\n- Project lens id: {{trigger.payload.projectId}}\n\nReport generated at: {{steps.now.output.result}}\n\nANALYZE ROUND MATERIAL:\n{{steps.analyze.output}}\n\nRELATE ROUND MATERIAL:\n{{steps.relate.output}}",
-          "maxTokens": "2000"
-        }
-      }
-    },
-    {
-      "id": "summarize",
-      "type": "capability",
-      "position": {
-        "x": 1380,
-        "y": 200
-      },
-      "data": {
-        "label": "One-line summary",
-        "verbId": "ai.generate",
-        "verbKind": "read",
-        "inputMapping": {
-          "system": "Write ONE plain sentence, under 200 characters, stating what this report found.\nNo markdown, no directives, no quotes, no leading label. Just the sentence.\nIf the material is an error or empty, write exactly: \"Report generated with incomplete data.\"",
-          "prompt": "Material to summarize (may be an error object if the round failed):\n{{steps.analyze.output}}",
-          "maxTokens": "500"
-        }
-      }
-    },
-    {
-      "id": "guard-assembled",
-      "type": "guard",
-      "position": {
-        "x": 1620,
-        "y": 200
-      },
-      "data": {
-        "label": "Body assembled",
-        "checks": [
-          {
-            "path": "steps.assemble.output",
-            "minLength": 200,
-            "message": "The assembler produced no usable body (under 200 characters) — refusing to write an empty report."
-          },
-          {
-            "path": "steps.assemble.output.error",
-            "exists": false,
-            "message": "The assembler round failed — refusing to write a report without a body."
-          }
-        ]
-      }
-    },
-    {
-      "id": "create-report",
-      "type": "output",
-      "position": {
-        "x": 1860,
-        "y": 200
-      },
-      "data": {
-        "label": "Create report",
-        "outputType": "entity_create",
-        "config": {
-          "profileSlug": "report",
-          "title": "Workspace report — {{steps.now.output.result}}",
-          "properties": {
-            "reportPeriod": "{{steps.now.output.result}}",
-            "generatedAt": "{{steps.now.output.result}}",
-            "reportStatus": "ready",
-            "summary": "{{steps.summarize.output}}",
-            "reportSources": [
-              "Tasks",
-              "Notes",
-              "People",
-              "Companies"
-            ]
-          },
-          "body": "{{steps.assemble.output}}",
-          "systemData": {
-            "renderer": {
-              "kind": "cell",
-              "cellKey": "{{trigger.payload.renderer}}"
-            }
-          }
-        }
-      }
-    }
-  ],
-  "edges": [
-    {
-      "id": "e-trigger-now",
-      "source": "trigger",
-      "target": "now"
-    },
-    {
-      "id": "e-now-tasks",
-      "source": "now",
-      "target": "gather-tasks"
-    },
-    {
-      "id": "e-now-notes",
-      "source": "now",
-      "target": "gather-notes"
-    },
-    {
-      "id": "e-now-people",
-      "source": "now",
-      "target": "gather-people"
-    },
-    {
-      "id": "e-now-companies",
-      "source": "now",
-      "target": "gather-companies"
-    },
-    {
-      "id": "e-tasks-project",
-      "source": "gather-tasks",
-      "target": "project-tasks"
-    },
-    {
-      "id": "e-notes-project",
-      "source": "gather-notes",
-      "target": "project-notes"
-    },
-    {
-      "id": "e-people-project",
-      "source": "gather-people",
-      "target": "project-people"
-    },
-    {
-      "id": "e-companies-project",
-      "source": "gather-companies",
-      "target": "project-companies"
-    },
-    {
-      "id": "e-tasks-analyze",
-      "source": "project-tasks",
-      "target": "analyze"
-    },
-    {
-      "id": "e-notes-analyze",
-      "source": "project-notes",
-      "target": "analyze"
-    },
-    {
-      "id": "e-people-analyze",
-      "source": "project-people",
-      "target": "analyze"
-    },
-    {
-      "id": "e-companies-analyze",
-      "source": "project-companies",
-      "target": "analyze"
-    },
-    {
-      "id": "e-analyze-relate",
-      "source": "analyze",
-      "target": "relate"
-    },
-    {
-      "id": "e-relate-assemble",
-      "source": "relate",
-      "target": "assemble"
-    },
-    {
-      "id": "e-assemble-summarize",
-      "source": "assemble",
-      "target": "summarize"
-    },
-    {
-      "id": "e-summarize-guard",
-      "source": "summarize",
-      "target": "guard-assembled"
-    },
-    {
-      "id": "e-guard-create",
-      "source": "guard-assembled",
-      "target": "create-report"
-    }
-  ]
-}