@synap-core/workspace-templates 0.10.0 → 0.12.0

package/src/foundation.yaml

@@ -528,6 +528,68 @@ profiles:
         valueType: string
         inputType: textarea
 
+  # ── Roles the BUSINESS MODEL needs, and why they live here ─────────────────
+  # `porteur` and `funder` are hats, not kinds: the same person entity is a
+  # porteur of one venture and a funder of another, and the hat is revocable
+  # while the person is not. They are declared HERE because foundation.yaml is
+  # the shared-role SSOT (`shared-role-ssot.test.ts` derives the guarded
+  # vocabulary from this file) — declaring them in business-model.yaml instead
+  # would fork a second identity for a hat the whole pod refers to.
+  - slug: porteur
+    displayName: Porteur
+    icon: user-check
+    color: amber
+    description: The person carrying a venture — the one whose commitment, skills, and constraints the model actually rests on. Distinct from `client` (who pays) and `partner` (who collaborates).
+    scope: shared
+    profileKind: role
+    applicableKinds:
+      - person
+    properties:
+      - slug: brings
+        label: What They Bring
+        valueType: string
+        inputType: textarea
+        description: The specific competence, network, capital, or legitimacy this person contributes that the model depends on.
+      - slug: commitmentLevel
+        label: Commitment
+        valueType: string
+        inputType: select
+        enumValues: [full-time, part-time, advisory, intermittent]
+      - slug: constraints
+        label: Constraints
+        valueType: string
+        inputType: textarea
+        description: What limits this porteur — time, cash runway, geography, non-compete, family. A model that ignores these is fiction.
+  - slug: funder
+    displayName: Funder
+    icon: banknote
+    color: green
+    description: A source of non-revenue money or subsidy — a bank, a public scheme, an investor, a grantor. A hat worn by a company or a person, never a kind of its own.
+    scope: shared
+    profileKind: role
+    applicableKinds:
+      - company
+      - person
+    properties:
+      - slug: fundingType
+        label: Funding Type
+        valueType: string
+        inputType: select
+        enumValues: [grant, subsidy, loan, equity, guarantee, prize, other]
+      - slug: amountCommitted
+        label: Amount Committed
+        valueType: number
+        inputType: number
+      - slug: eligibilityConditions
+        label: Eligibility Conditions
+        valueType: string
+        inputType: textarea
+        description: The conditions the venture must satisfy to keep this money. These are the constraints most often discovered too late.
+      - slug: decisionDate
+        label: Decision Date
+        valueType: date
+        inputType: date
+
 views:
   - name: Mission & Vision
     slug: mission-vision

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,210 @@ 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 }
+    # A grant pursuit is an ENGAGEMENT with a before/during/after lifecycle that
+    # outlives any one working session (drafting, then weeks of waiting on the
+    # funder, then tranche delivery), so this is a PROJECT template: its stages
+    # coordinate a long-running container rather than script one focus session.
+    scope: project
+    # Generic stages, mapped onto grant_submission's own stage/status/outcome +
+    # tranche vocab so the run can maintain the card as it advances.
+    # `category` is the closed rollup bucket (backlog|planned|started|paused|
+    # completed|canceled), chosen by MEANING: `identify` is pre-commitment
+    # scoping (planned); `awaiting` is genuinely blocked on the funder (paused);
+    # `awarded` stays `started` because delivery follows an award — a rejected
+    # pursuit's terminality lives on the submission's own `outcome` field, not
+    # here.
+    stages:
+      - { key: identify, name: Identify, category: planned, 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, category: started, 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, category: started, description: "Finalize against the program deadline and submit the application.", goal: "Application submitted on time; submission stage = awaiting-results." }
+      - { key: awaiting, name: Awaiting, category: paused, 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, category: started, 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, category: started, 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/life-os.yaml

@@ -731,6 +731,16 @@ profiles:
         inputType: text
 
 views:
+  # Knowledge is the pod-owned, validated-memory kind. Notes remain the
+  # workspace's capture inbox; this view deliberately reuses the system
+  # contract instead of recreating a competing knowledge schema here.
+  - name: Knowledge
+    slug: knowledge
+    type: table
+    scopeProfileSlug: knowledge
+    description: Validated insights and cautions, with their long-form context and evidence kept in the graph.
+    config:
+      columns: [title, knowledgeForm]
   - name: All Notes
     type: table
     scopeProfileSlug: note
@@ -1160,6 +1170,10 @@ layout:
       appId: dashboard
       label: Brain Home
       icon: Home
+    - kind: profile
+      profileSlug: knowledge
+      label: Knowledge
+      icon: Brain
     - kind: profile
       profileSlug: note
       label: Notes

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

package/src/seed-obligation.test.ts

@@ -0,0 +1,181 @@
+/**
+ * Seed-obligation guard.
+ *
+ * THE BUG THIS EXISTS TO STOP, stated plainly: the applier has supported
+ * `seedEntities` and `suggestedRelations` since
+ * `create-workspace-from-definition.ts` learned to read them, and for 31 of 31
+ * shipped templates that support was exercised exactly zero times. The
+ * observable result is a workspace that installs 15 views over 0 entities —
+ * every board empty, every chart blank, and the user left to guess what the
+ * pack was for. Two real workspaces in the field reproduced this identically,
+ * which is the signature of a template defect rather than user behaviour.
+ *
+ * The rule: a template that ships VIEWS over profiles it OWNS must also ship
+ * at least one seed entity, so the workspace opens with something in it.
+ *
+ * The escape hatch is deliberate and narrow. `SEEDLESS_BY_DESIGN` lists the
+ * templates that predate this guard, each with the reason it is still empty.
+ * Adding a line there is legal; adding one silently is not, because the list is
+ * asserted to be exact — a template that gains seeds must leave the list in the
+ * same commit. That is what turns this from a lint into a shrinking backlog.
+ *
+ * What a seed is NOT: filler. Seeding three fake companies teaches nothing and
+ * gets deleted in the first minute. Seed the QUESTIONS, the stages, the
+ * checklist — the reusable part of the method. See `business-model.yaml`, which
+ * seeds the nine interrogations rather than an example business.
+ */
+
+import { describe, expect, it } from "vitest";
+import { WORKSPACE_TEMPLATES } from "./templates.js";
+import type { WorkspaceYaml } from "./types.js";
+
+/**
+ * Templates that ship views over their own profiles and NO seed entities.
+ *
+ * Every entry is a workspace that currently installs empty. Keep the reason
+ * honest — "not done yet" is a valid reason and a useful one, because it reads
+ * as debt instead of as a decision.
+ */
+const SEEDLESS_BY_DESIGN: Record<string, string> = {
+  "agent-fleet": "Pre-dates this guard. Fleet contents are per-pod; needs a seed pass.",
+  base: "Pod substrate, not a workspace a user opens. Seeds would land in every workspace.",
+  "blockchain-ecosystem": "Pre-dates this guard; needs a seed pass.",
+  "brand-library": "Pre-dates this guard; brand assets are inherently per-company.",
+  "builder-workspace": "Pre-dates this guard; needs a seed pass.",
+  "business-developer": "Pre-dates this guard; overlay on CRM, seeds belong on the base.",
+  "civic-france": "Pre-dates this guard; needs a seed pass.",
+  communication: "Pre-dates this guard; needs a seed pass.",
+  "content-os": "Pre-dates this guard; needs a seed pass.",
+  "content-studio": "Pre-dates this guard; needs a seed pass.",
+  crm: "Pre-dates this guard; needs a seed pass.",
+  "dev-dashboard": "Pre-dates this guard; needs a seed pass.",
+  ecosystem: "Pre-dates this guard; needs a seed pass.",
+  "enterprise-os": "Pre-dates this guard; needs a seed pass.",
+  finance:
+    "Pre-dates this guard. Confirmed empty in the field: 15 views, 6 profiles, 0 entities. First candidate for a seed pass — a chart of accounts and a metric set are genuinely reusable.",
+  foundation:
+    "Pre-dates this guard. Strategic DNA is company-specific, but the INTERROGATION is not — see business-model.yaml, which seeds it as an overlay.",
+  grants: "Pre-dates this guard; needs a seed pass.",
+  hr: "Pre-dates this guard; needs a seed pass.",
+  "internal-runbook": "Pre-dates this guard; needs a seed pass.",
+  legal: "Pre-dates this guard; needs a seed pass.",
+  "life-os": "Pre-dates this guard; needs a seed pass.",
+  "marketing-campaign": "Pre-dates this guard; needs a seed pass.",
+  "meetings-knowledge": "Pre-dates this guard; needs a seed pass.",
+  networking: "Pre-dates this guard; needs a seed pass.",
+  operations: "Pre-dates this guard; needs a seed pass.",
+  "outreach-comms": "Pre-dates this guard; needs a seed pass.",
+  "project-management": "Pre-dates this guard; needs a seed pass.",
+  "research-base":
+    "Pre-dates this guard. Radar reproduced the empty-workspace pathology on top of this substrate; seed pass wanted.",
+  "research-decision": "Overlay on research-base; the method is a playbook, not entities.",
+  social: "Pre-dates this guard; needs a seed pass.",
+  "the-arch": "Pre-dates this guard; needs a seed pass.",
+};
+
+/** Slugs of profiles this template declares itself (owned or re-declared). */
+function declaredProfileSlugs(tpl: WorkspaceYaml): Set<string> {
+  const profiles = (tpl as { profiles?: Array<{ slug?: string }> }).profiles ?? [];
+  return new Set(profiles.map((p) => p.slug).filter((s): s is string => Boolean(s)));
+}
+
+/** Views whose scope is a profile the template declares. */
+function viewsOverOwnProfiles(tpl: WorkspaceYaml): number {
+  const declared = declaredProfileSlugs(tpl);
+  const views =
+    (tpl as { views?: Array<{ scopeProfileSlug?: string; scopeProfileSlugs?: string[] }> })
+      .views ?? [];
+  return views.filter((v) => {
+    const scoped = [v.scopeProfileSlug, ...(v.scopeProfileSlugs ?? [])].filter(Boolean);
+    return scoped.some((s) => declared.has(s as string));
+  }).length;
+}
+
+function seedCount(tpl: WorkspaceYaml): number {
+  const t = tpl as {
+    seedEntities?: unknown[];
+    suggestedEntities?: unknown[];
+  };
+  return (t.seedEntities?.length ?? 0) + (t.suggestedEntities?.length ?? 0);
+}
+
+const slugOf = (slug: string, tpl: WorkspaceYaml) =>
+  (tpl as { meta?: { slug?: string } }).meta?.slug ?? slug;
+
+describe("workspace-templates — seed obligation (corpus)", () => {
+  it("every template with views over its own profiles ships seeds, or is declared seedless", () => {
+    const undeclared: string[] = [];
+
+    for (const [key, tpl] of Object.entries(WORKSPACE_TEMPLATES)) {
+      const slug = slugOf(key, tpl);
+      if (viewsOverOwnProfiles(tpl) === 0) continue;
+      if (seedCount(tpl) > 0) continue;
+      if (slug in SEEDLESS_BY_DESIGN) continue;
+      undeclared.push(
+        `${slug}: ships ${viewsOverOwnProfiles(tpl)} view(s) over its own profiles and 0 seed entities. ` +
+          `Add seedEntities (seed the METHOD, not fake data), or add "${slug}" to SEEDLESS_BY_DESIGN with a reason.`
+      );
+    }
+
+    expect(
+      undeclared,
+      `Templates would install a workspace of empty views:\n  - ${undeclared.join("\n  - ")}`
+    ).toEqual([]);
+  });
+
+  it("the seedless allowlist is exact — a template that gains seeds must leave it", () => {
+    const stale: string[] = [];
+
+    for (const [key, tpl] of Object.entries(WORKSPACE_TEMPLATES)) {
+      const slug = slugOf(key, tpl);
+      if (!(slug in SEEDLESS_BY_DESIGN)) continue;
+      if (seedCount(tpl) > 0) {
+        stale.push(`${slug}: now seeds ${seedCount(tpl)} entity(ies) — remove it from SEEDLESS_BY_DESIGN`);
+      }
+    }
+
+    const corpusSlugs = new Set(
+      Object.entries(WORKSPACE_TEMPLATES).map(([key, tpl]) => slugOf(key, tpl))
+    );
+    for (const slug of Object.keys(SEEDLESS_BY_DESIGN)) {
+      if (!corpusSlugs.has(slug)) {
+        stale.push(`${slug}: listed in SEEDLESS_BY_DESIGN but no such template exists`);
+      }
+    }
+
+    expect(stale, `Stale seedless allowlist:\n  - ${stale.join("\n  - ")}`).toEqual([]);
+  });
+
+  it("every seeded relation names entities seeded in the same template", () => {
+    // A suggested relation whose ref matches no seeded title fails SILENTLY at
+    // apply time — the workspace installs, the edge does not, and nothing says
+    // so. Catch the typo here instead of in a user's pod.
+    const dangling: string[] = [];
+
+    for (const [key, tpl] of Object.entries(WORKSPACE_TEMPLATES)) {
+      const slug = slugOf(key, tpl);
+      const t = tpl as {
+        seedEntities?: Array<{ title?: string }>;
+        suggestedEntities?: Array<{ title?: string }>;
+        suggestedRelations?: Array<{ sourceRef?: string; targetRef?: string; type?: string }>;
+      };
+      const rels = t.suggestedRelations ?? [];
+      if (rels.length === 0) continue;
+
+      const titles = new Set(
+        [...(t.seedEntities ?? []), ...(t.suggestedEntities ?? [])]
+          .map((e) => e.title)
+          .filter((x): x is string => Boolean(x))
+      );
+
+      for (const rel of rels) {
+        for (const ref of [rel.sourceRef, rel.targetRef]) {
+          if (!ref || titles.has(ref)) continue;
+          dangling.push(`${slug}: relation "${rel.type}" references unseeded entity "${ref}"`);
+        }
+      }
+    }
+
+    expect(dangling, `Dangling seeded relations:\n  - ${dangling.join("\n  - ")}`).toEqual([]);
+  });
+});

package/src/shared-role-ssot.test.ts

@@ -122,8 +122,11 @@ describe("workspace-templates — shared ecosystem role SSOT (corpus)", () => {
     // Guards the derivation itself: if foundation ever stops declaring its
     // shared roles, rule (a) would silently guard nothing.
     expect(foundation, "foundation template must exist in the corpus").toBeDefined();
+    // `porteur` and `funder` join the relationship roles: a business model
+    // rests on WHO carries it and WHO funds it, and both are revocable hats on
+    // an existing person/company rather than kinds of their own.
     expect([...SHARED_ROLE_SLUGS].sort()).toEqual(
-      ["churned", "client", "lead", "partner", "sponsor"]
+      ["churned", "client", "funder", "lead", "partner", "porteur", "sponsor"]
     );
   });