@synap-core/workspace-templates 0.9.4 → 0.10.0

package/src/base.yaml

@@ -0,0 +1,839 @@
+# ═══════════════════════════════════════════════════════════════════════
+# base — universal operational defaults (slug: base, domain: core)
+#
+# GENERATED by scripts/gen-base (throwaway) from three backend seeders:
+#   - automations[0].flow  ← REPORT_AUTOMATION_FLOW  (ensure-report-automation.ts)
+#   - relationDefs[]        ← DEFAULT_RELATION_DEFS   (default-relation-defs.ts)
+#   - commands[]            ← DEFAULT_COMMANDS        (ensure-default-commands.ts)
+#
+# The flow is transcribed BYTE-FAITHFULLY — the hardened report prompts are the
+# product. Its fidelity is pinned by base.report-automation.test.ts against
+# __fixtures__/report-automation-flow.json. Do NOT hand-edit the flow here; edit
+# the source of truth and regenerate, OR (post-Wave-4, once the backend const is
+# deleted) edit here and update the fixture in the same commit.
+# ═══════════════════════════════════════════════════════════════════════
+meta:
+  slug: base
+  domain: core
+  name: Base
+  description: Universal operational defaults every workspace inherits — the report automation, the default relation vocabulary, and the default command pack.
+  icon: layers
+  color: "#6B7280"
+  tags:
+    - core
+    - defaults
+    - operational
+  isPublic: true
+workspace:
+  name: Base
+  description: The pod-wide operational defaults — carried as config so one reconcile door seeds them into every workspace instead of three hardcoded seeders.
+  proposalId: base-v1
+  visibility: pod_visible
+profiles: []
+relationDefs:
+  - slug: assigned_to
+    displayName: Assigned To
+    description: Person assigned to task/project
+    isDirectional: true
+    uiHints:
+      category: workflow
+  - slug: blocks
+    displayName: Blocks
+    description: Prevents progress on another task
+    isDirectional: true
+    uiHints:
+      category: workflow
+  - slug: depends_on
+    displayName: Depends On
+    description: Requires completion of another task
+    isDirectional: true
+    uiHints:
+      category: workflow
+  - slug: relates_to
+    displayName: Relates To
+    description: General relationship between entities
+    isDirectional: false
+    uiHints:
+      category: reference
+  - slug: mentions
+    displayName: Mentions
+    description: Referenced in content
+    isDirectional: true
+    uiHints:
+      category: reference
+  - slug: links_to
+    displayName: Links To
+    description: Hyperlink or reference
+    isDirectional: true
+    uiHints:
+      category: reference
+  - slug: parent_of
+    displayName: Parent Of
+    description: Hierarchical parent relationship
+    isDirectional: true
+    uiHints:
+      category: hierarchy
+  - slug: tagged_with
+    displayName: Tagged With
+    description: Categorization tag
+    isDirectional: true
+    uiHints:
+      category: reference
+  - slug: created_by
+    displayName: Created By
+    description: Author or creator
+    isDirectional: true
+    uiHints:
+      category: social
+  - slug: attended_by
+    displayName: Attended By
+    description: Participant in event
+    isDirectional: true
+    uiHints:
+      category: social
+  - slug: belongs_to_project
+    displayName: Belongs To Project
+    description: Project membership
+    isDirectional: true
+    uiHints:
+      category: hierarchy
+  - slug: founder_brand_of
+    displayName: Founder Brand Of
+    description: A personal-brand project is the founder brand of a company project — links a person's brand to the company it expresses
+    isDirectional: true
+    uiHints:
+      category: hierarchy
+      inverseLabel: Expression of
+  - slug: references
+    displayName: References
+    description: Cites or refers to
+    isDirectional: true
+    uiHints:
+      category: reference
+  - slug: works_at
+    displayName: Works At
+    description: Person works at an organization
+    isDirectional: true
+    uiHints:
+      category: social
+      inverseLabel: Employs
+  - slug: deal_for
+    displayName: Deal For
+    description: Sales deal associated with a contact
+    isDirectional: true
+    uiHints:
+      category: workflow
+      inverseLabel: Has Deal
+  - slug: advances
+    displayName: Advances
+    description: advances the company's Foundation mission/vision goal
+    isDirectional: true
+    uiHints:
+      category: workflow
+      inverseLabel: Advanced by
+  - slug: met_at
+    displayName: Met at
+    description: Person met at an event or gathering
+    isDirectional: true
+    uiHints:
+      category: social
+      inverseLabel: Attendees
+  - slug: works_on
+    displayName: Works on
+    description: Person contributes to a project
+    isDirectional: true
+    uiHints:
+      category: workflow
+      inverseLabel: Contributors
+  - slug: has_skill
+    displayName: Has skill
+    description: Person possesses a skill or expertise
+    isDirectional: true
+    uiHints:
+      category: reference
+      inverseLabel: Skilled people
+  - slug: affiliated_with
+    displayName: Affiliated with
+    description: Person affiliated with an organization
+    isDirectional: true
+    uiHints:
+      category: social
+      inverseLabel: Members
+  - slug: knows
+    displayName: Knows
+    description: Two people know each other
+    isDirectional: false
+    uiHints:
+      category: social
+  - slug: discussed_with
+    displayName: Discussed with
+    description: Had a discussion or conversation with
+    isDirectional: false
+    uiHints:
+      category: social
+commands:
+  - title: Create View from Description
+    promptTemplate: |-
+      You are helping the user create a new view from a natural language description.
+
+      **User's goal:** @{arg:goal}
+
+      Create a proposal for a new view that matches this description. Include:
+      - View type (table, kanban, list, etc.)
+      - Filters, sorts, and scope
+      - Layout configuration
+
+      Output your proposal clearly so it can be turned into a Synap view.
+    derivedInputs:
+      - name: goal
+        label: Goal
+        type: text
+    outputMode: view
+    canCreateViews: true
+    permissionsProfile: propose_writes
+  - title: Extract Entities from Text
+    promptTemplate: |-
+      You are helping the user extract entities and relationships from text.
+
+      **User's text or selection:**
+
+      @{context:text}
+
+      Analyze this content and propose:
+      1. New entities to create (Notes, Tasks, People, Companies, etc.) with their properties
+      2. Relationships between entities (blocks, related_to, parent_of, etc.)
+
+      Output proposals that the user can review and approve. Do not create anything directly—always propose.
+    derivedInputs: []
+    outputMode: proposal
+    canCreateViews: false
+    permissionsProfile: propose_writes
+  - title: Summarize Selection
+    promptTemplate: |-
+      You are helping the user get a concise summary of their selection.
+
+      **User's text or selection:**
+
+      @{context:text}
+
+      Provide a clear, structured summary. Highlight key points, dates, and actionable items if relevant. Keep it concise but comprehensive.
+    derivedInputs: []
+    outputMode: text
+    canCreateViews: false
+    permissionsProfile: read_only
+  - title: Analyze Entities
+    promptTemplate: |-
+      You are helping the user analyze selected entities.
+
+      **Current entity context:**
+
+      @{context:entity}
+
+      Analyze this entity and provide:
+      - Overview and key properties
+      - Insights, gaps, or opportunities
+      - Suggestions for relationships or next steps
+
+      Be concise and actionable.
+    derivedInputs: []
+    outputMode: text
+    canCreateViews: false
+    permissionsProfile: read_only
+  - title: Create Task from Text
+    promptTemplate: |-
+      You are helping the user turn text into tasks.
+
+      **User's text (meeting notes, pasted content, or selection):**
+
+      @{context:text}
+
+      Extract actionable tasks. For each task propose:
+      - Title
+      - Optional: due date, priority, assignee, status
+      - Link to source if applicable
+
+      Output proposals only—do not create entities directly. The user will review and approve.
+    derivedInputs: []
+    outputMode: proposal
+    canCreateViews: false
+    permissionsProfile: propose_writes
+  - title: Create Event from Text
+    promptTemplate: |-
+      You are helping the user turn text into events.
+
+      **User's text (meeting notes, calendar copy, or selection):**
+
+      @{context:text}
+
+      Extract events with dates/times. For each event propose:
+      - Title
+      - Start time and end time
+      - Optional: description, tags
+
+      Output proposals only—do not create entities directly. The user will review and approve.
+    derivedInputs: []
+    outputMode: proposal
+    canCreateViews: false
+    permissionsProfile: propose_writes
+automations:
+  - name: Generate report
+    description: Gather this workspace's state, interpret it over three AI rounds, and write a report entity. Run it as-is for a general report, or pass a prompt (e.g. "focus on our clients") to steer what it is about.
+    triggerType: manual
+    triggerConfig: {}
+    status: active
+    flow:
+      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.
+                Read the gathered workspace data and say what it MEANS: volume and shape of work,
+                what is in flight versus stalled, what is well-covered versus thin.
+                Work from the FIELDS on each record, not just its name: status, priority and
+                due dates are what distinguish moving work from stalled work, and an unset
+                field is itself worth reporting. Listing or counting what exists is NOT a
+                finding — say what the state of it means.
+                DATA 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.
+                You 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.
+                EVERY 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.
+                NEVER 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.
+                STEER 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.
+                LINK 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.
+                Output PLAIN PROSE — short paragraphs and bullets, with [[entity:…]] chips
+                inline wherever you name a record. No markdown headings, no ::: directive
+                blocks, no code fences. Under 300 words. Another round will format this.
+              prompt: |-
+                STEER:
+                - Prompt: {{trigger.payload.prompt}}
+                - Focus: {{trigger.payload.focus}}
+                - Project lens id: {{trigger.payload.projectId}}
+
+                COUNTS — the exact number of records gathered for each kind. These figures
+                are measured, not estimated, and they are the ONLY quantities available to
+                you. Each line also gives the cap the gather was limited to.
+                - Tasks: {{steps.gather-tasks.output.count}} gathered (cap 25)
+                - Notes: {{steps.gather-notes.output.count}} gathered (cap 15)
+                - People: {{steps.gather-people.output.count}} gathered (cap 15)
+                - Companies: {{steps.gather-companies.output.count}} gathered (cap 15)
+                READING A COUNT AGAINST ITS CAP: a count BELOW the cap means every record of
+                that kind is listed below — the set is COMPLETE and you may describe it as
+                such. A count EQUAL to the cap means the gather stopped at the cap and more
+                records exist that you cannot see — describe that kind as "at least N" and
+                never as complete, and never claim something does not exist merely because
+                it is absent from the list.
+
+                Time window: only records updated on or after {{trigger.payload.since}}
+
+                GATHERED DATA — one line per record, MOST RECENTLY UPDATED first. Each line
+                is `<id> · <title>` followed by ` · <field>=<value>` pairs carrying that
+                record's real state. An EMPTY value means the field is not set on that
+                record — that is a fact you may report (an unset status or a missing due
+                date is a finding), and never a value to guess at. Recent does not mean
+                important.
+                Tasks — {{steps.gather-tasks.output.count}} found: {{steps.project-tasks.output.result}}
+                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"
+            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.
+                You receive the raw gathered data AND the analyst's read of it. Your job is what
+                the analyst did NOT do: surface RELATIONSHIPS and things worth attention —
+                clusters, repeated themes, people or companies that recur across kinds, gaps
+                where a kind is conspicuously empty, and anything that looks like it needs a
+                decision. Prefer three sharp observations over ten shallow ones.
+                YOUR SCOPE IS WHAT CONNECTS RECORDS, not what they individually are. Every
+                observation you write must involve TWO OR MORE records, or TWO OR MORE kinds:
+                a name that appears in both a task and a company, work clustered on one
+                person, a due date that lines up with an event, a kind that is empty while a
+                related kind is busy. Do NOT re-describe volume, status distribution or how
+                busy the workspace is — that is the analyst's section and repeating it makes
+                yours redundant. Do not summarise or restate the analyst's read.
+                NEVER RETURN AN EMPTY ANSWER. If you genuinely find no cross-kind pattern,
+                write one or two sentences naming what you looked for and did not find (for
+                example: no person recurs across the tasks and companies gathered). That is a
+                real finding and the reader needs it. Silence is not an available outcome.
+                DATA 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.
+                You 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.
+                EVERY 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.
+                NEVER 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.
+                STEER 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.
+                LINK 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.
+                Output PLAIN PROSE, under 250 words, with [[entity:…]] chips inline. No
+                headings, no ::: directive blocks, no code fences.
+              prompt: |-
+                STEER:
+                - Prompt: {{trigger.payload.prompt}}
+                - Focus: {{trigger.payload.focus}}
+                - Project lens id: {{trigger.payload.projectId}}
+
+                COUNTS — the exact number of records gathered for each kind. These figures
+                are measured, not estimated, and they are the ONLY quantities available to
+                you. Each line also gives the cap the gather was limited to.
+                - Tasks: {{steps.gather-tasks.output.count}} gathered (cap 25)
+                - Notes: {{steps.gather-notes.output.count}} gathered (cap 15)
+                - People: {{steps.gather-people.output.count}} gathered (cap 15)
+                - Companies: {{steps.gather-companies.output.count}} gathered (cap 15)
+                READING A COUNT AGAINST ITS CAP: a count BELOW the cap means every record of
+                that kind is listed below — the set is COMPLETE and you may describe it as
+                such. A count EQUAL to the cap means the gather stopped at the cap and more
+                records exist that you cannot see — describe that kind as "at least N" and
+                never as complete, and never claim something does not exist merely because
+                it is absent from the list.
+
+                Time window: only records updated on or after {{trigger.payload.since}}
+
+                GATHERED DATA — one line per record, MOST RECENTLY UPDATED first. Each line
+                is `<id> · <title>` followed by ` · <field>=<value>` pairs carrying that
+                record's real state. An EMPTY value means the field is not set on that
+                record — that is a fact you may report (an unset status or a missing due
+                date is a finding), and never a value to guess at. Recent does not mean
+                important.
+                Tasks — {{steps.gather-tasks.output.count}} found: {{steps.project-tasks.output.result}}
+                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}}
+
+                ANALYST'S READ — already written and already in the report. Do NOT
+                restate, summarise or re-analyse it. It is here so you do not repeat it:
+                {{steps.analyze.output}}
+
+                YOUR TASK — cross-kind patterns ONLY. Look for what connects the lists
+                above: a person who recurs in tasks and companies, work clustered on one
+                name, due dates that line up, a kind that is empty while a related kind
+                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"
+            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
+                document body in Synap-flavoured markdown. You add no new facts — you arrange,
+                title, and format what the earlier rounds produced.
+
+                NEVER 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.
+
+                NUMBERS: you were given no COUNTS block, so you may not originate a quantity
+                at all. Reproduce a figure ONLY by copying one that already appears in the
+                round material, digit for digit. Never total, re-count, convert to words, or
+                put a number in the title or in a ## heading that is not already in the
+                material beneath it.
+
+                SYNAP MARKDOWN SYNTAX — these rules are absolute:
+                1. A section is a FOUR-COLON container that must be opened and closed:
+                   ::::synap-section{agent="analyst" round="analyze" confidence="0.8"}
+                   ...content...
+                   ::::
+                2. Leaf embeds use THREE colons and MUST BE CLOSED with their own ::: line.
+                   There is NO self-closing form. An unclosed embed swallows every line that
+                   follows it until the section ends, and that content is LOST. Always write
+                   the closing ::: immediately after the opening line:
+                   :::synap-cell{instanceId="..."}
+                   :::
+                   :::synap-view{viewId="..."}
+                   :::
+                   :::synap-entity{id="..."}
+                   :::
+                3. The outer container must always have STRICTLY MORE colons than anything nested
+                   inside it. Four outside, three inside. If you ever nest a four-colon block in a
+                   four-colon block the section closes early and the rest of the report leaks out.
+                4. ATTRIBUTE VALUES MUST BE QUOTED. An UNQUOTED value ends at the first } it
+                   contains, which silently truncates the attribute — so always quote. Use
+                   DOUBLE quotes for a plain value, and SINGLE quotes when the value is itself
+                   a JSON object, so the JSON's own double quotes survive:
+                   :::synap-cell{cellKey="chart-pie" cellProps='{"profileSlug":"task","groupBy":"status"}'}
+                   :::
+                   A single-quoted value may contain both " and } — those are only special to
+                   an unquoted value. Write the JSON compact, on one line, with no trailing
+                   comma; malformed JSON renders the cell with empty config.
+                5. The ONLY section attributes that survive are: id, agent, round, skills,
+                   confidence, stepRunId, nodeId, status. Anything else is silently dropped.
+                6. confidence is a 0-1 ratio written as a decimal string, e.g. confidence="0.8".
+                   Never a percentage.
+                7. CHIPS ARE CONTENT — COPY THEM THROUGH VERBATIM. The round material you were
+                   given already contains [[entity:<id>|<label>]] markers. Reproduce every one
+                   EXACTLY as written: same brackets, same id, same label. Do NOT tidy them into
+                   plain text, do NOT rewrite or re-case an id, do NOT convert them to markdown
+                   links. You are told you add no new FACTS; a chip is not a fact, it is the
+                   earlier round's finding made navigable, and stripping it removes the only
+                   clickable thing in the report while leaving the prose looking fine.
+                   You may add a chip ONLY by copying a marker that already appears in the
+                   material. Never invent an id, and never use a kind word other than `entity` —
+                   this report is READ-ONLY prose, and either mistake produces a dead chip.
+                8. NEVER EMIT :::synap-view, AND NEVER EMIT :::synap-cell WITH AN instanceId.
+                   Both need an id you have not been given and cannot obtain, and a made-up
+                   reference produces a permanent broken block in a document a human reads.
+                9. YOU MAY EMIT A CHART :::synap-cell — from this allowlist ONLY, configured
+                   through cellProps. These cells fetch their own data at render time, so they
+                   need no id, and they make the report a live surface instead of a text file:
+                   - :::synap-cell{cellKey="stat-card" cellProps='{"profileSlug":"<kind>","aggregation":"count","timePeriod":"week","label":"<Kind> created this week"}'}
+                   - :::synap-cell{cellKey="chart-pie" cellProps='{"profileSlug":"<kind>","groupBy":"<property>","label":"<the finding this shows>"}'}
+                   - :::synap-cell{cellKey="chart-bar" cellProps='{"profileSlug":"<kind>","mode":"category","groupBy":"<property>","label":"<the finding this shows>"}'}
+                   Rules, all mandatory:
+                   (a) profileSlug must be one of the kinds gathered for THIS report: task,
+                       note, person, company. A chart over any other kind is a claim this
+                       report cannot back — the data was never read.
+                   (b) groupBy / field must name a property that plausibly exists on that
+                       kind. If you are not confident one does, use the stat-card line above
+                       EXACTLY as written — profileSlug, aggregation, timePeriod AND a label
+                       naming the window. Never drop timePeriod and never label a windowed
+                       count with a bare kind name: the card counts records CREATED in that
+                       window, so "Tasks" over a weekly count is a false statement about
+                       the workspace.
+                   (c) Close EVERY embed with its own ::: line, per rule 2. An unclosed embed
+                       swallows the rest of the section.
+                   (d) EDITORIAL RULE — embed to SHOW what a sentence cannot: a distribution,
+                       a ratio, a count. Never to decorate. At most 2-3 in the whole report,
+                       placed inside the section whose prose they support. A chart that merely
+                       restates the sentence beside it is noise, and noise is worse than
+                       nothing here. If no gathered kind has a distribution worth showing,
+                       emit no cells at all — that is a correct report, not a lesser one.
+                   (e) AT MOST ONE cell per section, and NEVER at the top of a section.
+                       Place it immediately AFTER the sentence making the claim it evidences,
+                       so the reader has the claim before the picture. A chart that opens a
+                       section makes the reader decode a graphic to find out what the section
+                       is about, which is the delay the ## heading and the claim sentence
+                       exist to remove.
+                   (f) The label must state the FINDING, not the dimension. Write
+                       label:"Half the open tasks are blocked", never label:"Distribution",
+                       "Status" or "Tasks by status". Always set label explicitly: with none,
+                       a pie chart titles itself "Distribution" and a bar chart "Breakdown" —
+                       words true of every such chart ever drawn, which tell the reader
+                       nothing they cannot already see in the shapes.
+                   (g) A CHART IS A LIVE VIEW, THE PROSE IS A SNAPSHOT. These cells run
+                       their own query when the report is OPENED, which may be long after
+                       this text was written — so a sentence quoting a count and a chart
+                       measuring the same thing WILL eventually disagree, and the reader
+                       cannot tell which is stale. Never write a specific number in a
+                       sentence that sits beside a chart of the same data: let the chart
+                       carry the number and let the sentence carry the claim
+                       ("most open tasks are stalled at review", not "12 of 19 are stalled").
+                       And if the sentence already gives the number the chart would show,
+                       DROP THE CHART — one of them is redundant, and the sentence is the one
+                       that cannot go stale against itself.
+                   Everything else this report needs is ::::synap-section containers plus
+                   [[entity:…]] chips inline.
+
+                10. EVERY ::::synap-section MUST OPEN WITH A ## CLAIM HEADING — its first
+                    line, before any prose. The heading states WHAT THE SECTION FOUND, not
+                    what produced it: "## Half the open tasks are blocked", never
+                    "## Analysis", "## Analyze round" or "## Findings". Under 10 words, no
+                    trailing period, no markdown or [[entity:…]] chip inside the heading
+                    itself — put the chip in the prose beneath it. Write exactly one ## per
+                    section. This heading is the section's title everywhere it is read: the
+                    slide deck sets it as the slide headline (with no heading it falls back
+                    to the round and agent names, which the slide already shows underneath),
+                    and the scrolling reader has no section titles at all without it. A
+                    section whose heading merely names the round tells the reader nothing
+                    they cannot already see.
+
+                STRUCTURE: one ::::synap-section per round, in order — analyze, then relate.
+                Open with a single "# " title line ABOVE the first section, and open each
+                section with its own ## claim heading per rule 10.
+
+                STEER HANDLING: if the STEER lines are empty, title the report generically
+                ("Workspace report — <period>") and keep the rounds in their given order. If any
+                STEER line has text, name that subject in the title and lead each section with
+                the material that answers it. Never add facts the rounds did not give you.
+
+                MISSING ROUNDS: if a round's material looks like {"error": "..."} or is empty,
+                you MUST still emit its section, with status="failed", containing one visible
+                sentence naming what is missing. NEVER silently produce a shorter report — a
+                reader must be able to see that a round did not run. A failed section is NOT
+                exempt from rule 10: give it a ## heading that states what is missing
+                ("## The patterns round produced nothing"), because it still occupies a slide
+                and still needs a headline.
+
+                WORKED EXAMPLE of correct output:
+                # Workspace report — July 2026
+
+                ::::synap-section{agent="analyst" round="analyze" confidence="0.8"}
+                ## Most open tasks are stalled at review
+
+                Open tasks are piling up untouched since the sprint opened, and the great
+                majority are sitting in one status — the oldest is
+                [[entity:3f2a91c4-7b10-4e55-9c02-8ad1f6e4b2d7|Migrate the billing worker]].
+                Notes are thin.
+                :::synap-cell{cellKey="chart-pie" cellProps='{"profileSlug":"task","groupBy":"status","label":"Review is where open tasks accumulate"}'}
+                :::
+                ::::
+
+                ::::synap-section{agent="analyst" round="relate" status="failed" confidence="0.2"}
+                ## The patterns round produced nothing
+
+                This section is missing: the patterns round failed and produced no material.
+                ::::
+
+                Be CONCISE — your entire output must fit in 2000 tokens. Emit ONLY the markdown
+                document. No preamble, no explanation, no code fences around the whole thing.
+              prompt: |-
+                STEER:
+                - Prompt: {{trigger.payload.prompt}}
+                - Focus: {{trigger.payload.focus}}
+                - Project lens id: {{trigger.payload.projectId}}
+
+                Report generated at: {{steps.now.output.result}}
+
+                ANALYZE ROUND MATERIAL:
+                {{steps.analyze.output}}
+
+                RELATE ROUND MATERIAL:
+                {{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.
+                No markdown, no directives, no quotes, no leading label. Just the sentence.
+                If 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):
+                {{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