@synap-core/workspace-templates 0.12.0 → 0.23.0

package/src/business-model.yaml

@@ -27,12 +27,25 @@
 #
 # The porteur and funder ROLES it needs are declared in foundation.yaml, the
 # shared-role SSOT — see the note there.
+#
+# THIS IS THE CANONICAL GRP (concept consolidation W4a, 2026-09-25). The method
+# ships as a TRACK TEMPLATE — "Business Model (GRP)", `scope: project`, six
+# steps, each naming the DOMAIN (workspace template slug) it is worked in — and
+# the nine seeded questions are the GRP method's own set, one per component of
+# its three pillars: GRP = Génération · Rémunération · Partage (founder decision
+# A, 2026-09-28 — NOT the later "GRP #1 … #9" wedge/ICP/positioning set). They
+# are copied verbatim from the founder's live pod-level rows so an install ADOPTS
+# them (seed dedupe is `${kind}:${title}` in the target workspace OR among the
+# user's pod-wide rows — services/definition-seeds.ts) instead of adding a
+# second set. `convention` and `projection` are pod-wide kinds, so the GRP needs
+# no workspace of its own: its entities are filed to the project by the track,
+# not by where the session happened to run.
 
 meta:
   slug: business-model
   domain: strategy
   name: Business Model
-  description: Interrogate a venture as a model that rests on things — components supported by evidence, bound by real conventions, and quantified by projections whose assumptions stay visible.
+  description: "Business Model (GRP): a track template you run on a project. Six steps turn the model's nine component questions into evidence-backed decisions, conventions and projections."
   icon: layout-grid
   color: "#0EA5E9"
   tags: [strategy, business-model, grp, ibis, viability]
@@ -69,6 +82,11 @@ profiles:
         valueType: string
         inputType: select
         enumValues: [open, exploring, answered, abandoned]
+      # `wedge-stage` (the C→A wedge ladder) left the template with the
+      # "GRP #" set (founder decision A, 2026-09-28): it is one venture's go-to-
+      # market ladder, not part of the Génération / Rémunération / Partage
+      # method, and only "GRP #1" ever carried it. The live Foundation overlay
+      # is untouched — reconcile is additive.
   - slug: decision
     displayName: Decision
     icon: gavel
@@ -86,6 +104,12 @@ profiles:
     icon: scale
     color: rose
     description: A binding rule the model must satisfy and did not choose — an eligibility threshold, a professional duty, a contractual floor, a platform policy. Distinct from a decision (nobody decided it) and from a finding (it constrains rather than informs).
+    # Pod-wide kind (same two axes as foundation's audience/offer): a GRP step
+    # worked in another domain (a Finance or Research session) must still be
+    # able to resolve and file a convention — it belongs to the project's
+    # model, not to the workspace the session ran in.
+    scope: shared
+    entityScope: pod
     profileKind: kind
     properties:
       - slug: rule
@@ -102,7 +126,16 @@ profiles:
         label: Type
         valueType: string
         inputType: select
-        enumValues: [regulatory, deontological, eligibility, contractual, platform, fiscal, other]
+        enumValues:
+          [
+            regulatory,
+            deontological,
+            eligibility,
+            contractual,
+            platform,
+            fiscal,
+            other,
+          ]
       - slug: bindingStatus
         label: Binding Status
         valueType: string
@@ -128,6 +161,10 @@ profiles:
     icon: trending-up
     color: violet
     description: A quantified scenario with its assumptions attached. The number is never the artifact — the assumptions are, because that is the only part anyone can argue with.
+    # Pod-wide for the same reason as `convention`: the money step runs in
+    # Finance, and its projections must land on the project's model.
+    scope: shared
+    entityScope: pod
     profileKind: kind
     properties:
       - slug: scenario
@@ -163,6 +200,35 @@ profiles:
         inputType: select
         enumValues: [low, medium, high]
 
+  # ── The GRP interrogation marker (founder decision D4: joins the template) ──
+  # A workspace role on `question`: marks a question as one of the nine GRP
+  # interrogations and carries its number, its GRP pillar and how good the
+  # evidence behind its answer is. Property slugs verbatim from the live
+  # Foundation role (snake_case as live). GRP = Génération · Rémunération ·
+  # Partage — the live role's "Growth Research Positioning" was an agent's
+  # invented expansion and is corrected here. Seeds cannot carry facets, so a
+  # fresh install gets the role and the nine questions; the first GRP session
+  # attaches it. The seeds carry their pillar in `tags` regardless.
+  - slug: grp-interrogation
+    displayName: GRP Interrogation
+    description: "Marks a Question as one of the nine GRP business-model interrogations (GRP = Génération · Rémunération · Partage). Carries the interrogation number (1-9), its GRP pillar (generation, remuneration or sharing), and the quality of the evidence behind the answer."
+    profileKind: role
+    applicableKinds: [question]
+    properties:
+      - slug: interrogation_number
+        label: Interrogation number
+        valueType: number
+        inputType: number
+      - slug: grp_domain
+        label: GRP pillar
+        valueType: string
+        inputType: text
+        description: "generation (Génération), remuneration (Rémunération) or sharing (Partage) — the same word the question carries in its tags."
+      - slug: evidence_quality
+        label: Evidence quality
+        valueType: string
+        inputType: text
+
 # Relation TYPE vocabulary. Declared here (not as bare entityLinks) because
 # these two carry description + inverse labels that the entity-link path drops.
 relationDefs:
@@ -240,7 +306,8 @@ views:
     scopeProfileSlug: projection
     description: Scenarios with their assumptions in the open, so a number can be argued with.
     config:
-      columns: [title, scenario, horizon, revenueEstimate, costEstimate, confidence]
+      columns:
+        [title, scenario, horizon, revenueEstimate, costEstimate, confidence]
   - name: Open Interrogation
     slug: business-model-open-questions
     type: kanban
@@ -251,101 +318,281 @@ views:
 # ── Seeds: the interrogation, not fake data ────────────────────────────────
 # A strategy template that seeds example companies teaches nothing and gets
 # deleted. What is actually reusable is the QUESTION SET — the workspace should
-# arrive with the model's nine interrogations already open, so the first session
+# arrive with the model's nine interrogations already open, so the first step
 # has somewhere to start and the kanban is not an empty box.
+#
+# The GRP method's nine questions, three per pillar — Génération (porteur,
+# value proposition, value fabrication), Rémunération (revenue sources, volume
+# and pricing, performance), Partage (stakeholders, conventions, ecosystem).
+# VERBATIM from the founder's live pod-level rows (workspaceId NULL, read
+# 2026-09-28): title, the question text in `properties.title`, `description`,
+# `tags` and `questionStatus`. The PILLAR is the live tag `generation` /
+# `remuneration` / `sharing` — that is how a step (or an agent) finds a pillar's
+# questions; no new field. Only `askedAt` (2026-09-15, the day the founder asked
+# them) is left out: a fixed historical date on a fresh install would be false,
+# and an adopted row keeps its own anyway (adoption never rewrites properties).
+# Do not paraphrase a title — the seed dedupe key is `${kind}:${title}`, so a
+# reworded title seeds a SECOND set beside the live one instead of adopting it
+# (asserted by business-model-grp.template.test.ts, and through the real helper
+# by synap-backend compose-overlay.seeds.pglite.test.ts).
+#
+# Which STEP of the method each question serves is carried by the step itself:
+# its `suggestedTasks` open with the exact titles of its questions (see the
+# playbook below; porteur → Porteur; offer_buyer → Value proposition + Value
+# fabrication; conventions_cost → Stakeholders + Conventions + Ecosystem;
+# money_means → Revenue sources + Volume and pricing; refutation → Performance).
 seedEntities:
   - profileSlug: question
-    title: Who is the porteur, and what does the model rest on them for?
+    title: "Porteur — what does the founder bring that cannot be hired, and what does the venture require of them personally?"
     properties:
+      title: "Porteur — what does the founder bring that cannot be hired, and what does the venture require of them personally?"
+      description: "Generation / porteur. Tests intuitu personae: credentials, licences, reputation and relationships that are attached to a named person rather than to the company. Answering this exposes load-bearing single points of failure that a capability table hides. Circular: the porteur's standing determines which stakeholders will engage, and the stakeholders engaged determine what standing the porteur must hold."
+      tags: [business-model, grp, generation, method-question]
       questionStatus: open
-    content: Name the person, then name the specific competence, network, capital, or legitimacy the model cannot survive without. If the answer is generic, the model has no porteur — it has a job posting.
   - profileSlug: question
-    title: What does the porteur's situation forbid?
+    title: "Value proposition — for whom is this indispensable, and what do they stop doing once they have it?"
     properties:
+      title: "Value proposition — for whom is this indispensable, and what do they stop doing once they have it?"
+      description: "Generation / value proposition. The second half is the real test: a proposition nobody stops anything for is a preference, not a need. Circular: the conventions the venture is bound by constrain what may be promised, and the promise made determines which conventions become binding."
+      tags: [business-model, grp, generation, method-question]
       questionStatus: open
-    content: Runway, hours available, geography, non-compete, dependants, health. Constraints discovered in month four were knowable in week one.
   - profileSlug: question
-    title: What is the offer, stated as the problem it ends?
+    title: "Value fabrication — what is the chain that actually produces the value, and which link do we own?"
     properties:
+      title: "Value fabrication — what is the chain that actually produces the value, and which link do we own?"
+      description: "Generation / fabrication de la valeur. Forces the distinction between the activity performed and the value delivered, and names the links owned by others. A venture that owns no link is a broker; a venture that owns every link is usually lying about cost."
+      tags: [business-model, grp, generation, method-question]
       questionStatus: open
-    content: Not a description of what is built — a statement of the situation a buyer is in before, and after. If the offer can only be described by its features, the buyer has not been found yet.
   - profileSlug: question
-    title: Who exactly buys it, and who merely benefits from it?
+    title: "Revenue sources — who pays, for which unit, and why that unit rather than another?"
     properties:
+      title: "Revenue sources — who pays, for which unit, and why that unit rather than another?"
+      description: "Remuneration / sources de revenus. The payer is frequently not the beneficiary, and the billing unit encodes a theory of value that is rarely stated. Circular: the segment chosen determines which revenue source is available, and the revenue source chosen re-selects the viable segment."
+      tags: [business-model, grp, remuneration, method-question]
       questionStatus: open
-    content: Link to `audience` entities. Payer, user, and beneficiary are frequently three different parties, and a model that conflates them forecasts revenue from people who never pay.
   - profileSlug: question
-    title: Which conventions bind this model, and which are still assumed?
+    title: "Volume and pricing — what volume at what price clears the cost base, and is that volume reachable in this market?"
     properties:
+      title: "Volume and pricing — what volume at what price clears the cost base, and is that volume reachable in this market?"
+      description: "Remuneration / volume et prix. Separates the arithmetic question from the market question; a model can be internally coherent and still require a volume the addressable market cannot supply."
+      tags: [business-model, grp, remuneration, method-question]
       questionStatus: open
-    content: Eligibility thresholds, professional duties, platform policies, fiscal regimes. Every convention starts `assumed`; the work is reading the source text and moving it to `verified`. An eligibility collision — where the segment with the most pull sits outside the scheme that would fund it — only becomes visible once the numbers are pulled.
   - profileSlug: question
-    title: What does one unit of delivery actually cost to produce?
+    title: "Performance — which number tells us the model works, and what observation would falsify it?"
     properties:
+      title: "Performance — which number tells us the model works, and what observation would falsify it?"
+      description: "Remuneration / performance. Requires a stopping rule stated before the evidence arrives, while it can still be set honestly. Circular: price assumptions drive the performance target, and observed performance revises the pricing thesis."
+      tags: [business-model, grp, remuneration, method-question, falsifiable]
       questionStatus: open
-    content: Time, tooling, subcontracting, the unbilled parts. Link the answer to a `projection` so the assumptions stay attached to the number.
   - profileSlug: question
-    title: Where does the money come from before revenue does?
+    title: "Stakeholders — who must say yes for this to exist, and what does each of them need in return?"
     properties:
+      title: "Stakeholders — who must say yes for this to exist, and what does each of them need in return?"
+      description: "Sharing / parties prenantes. Covers actors with veto power who are not customers: regulators, orders and professional bodies, funders, referencing schemes, platform gatekeepers. Their consent is a precondition, not a sales outcome."
+      tags: [business-model, grp, sharing, method-question]
       questionStatus: open
-    content: Attach `funder` roles to the companies or schemes involved, with their eligibility conditions. Subsidy is a credential and a discount; it is rarely a pipeline.
   - profileSlug: question
-    title: What means — people, tools, licences, premises — must exist first?
+    title: "Conventions — which rules bind us, who enforces them, and which are mandatory rather than advisory?"
     properties:
+      title: "Conventions — which rules bind us, who enforces them, and which are mandatory rather than advisory?"
+      description: "Sharing / conventions. Deontological codes, eligibility thresholds, neutrality requirements and conflict-of-interest rules that constrain the model from outside. The binding-versus-advisory distinction decides whether a convention is a design constraint or a preference, and enforcement determines the cost of breach."
+      tags: [business-model, grp, sharing, method-question, conventions]
       questionStatus: open
-    content: The means rest on the money and the money rests on the offer. That circularity is the model, not a planning error; record it with `rests_on` and stop trying to linearise it.
   - profileSlug: question
-    title: What observation would refute this model, and by when?
+    title: "Ecosystem — what does the venture give back, and what breaks if we extract without returning?"
     properties:
+      title: "Ecosystem — what does the venture give back, and what breaks if we extract without returning?"
+      description: "Sharing / partage et ecosysteme. The reciprocity test that distinguishes a durable position from extraction. Answering it usually surfaces the convention or stakeholder relationship that fails first under pressure."
+      tags: [business-model, grp, sharing, method-question]
       questionStatus: open
-    content: Set the falsifiable test now, while it can still be set honestly. A model with no refuting observation is a belief with a spreadsheet attached.
 
-# The circularity, declared. These edges deliberately form cycles — that is the
-# point of `rests_on`, and the reason this pack does not use `depends_on`.
+# The method's dependency order, declared: a downstream pillar RESTS ON the
+# upstream one — Rémunération rests on Génération (you are paid for value you
+# generate), Partage rests on Rémunération and Génération (you share what you
+# capture, with those the porteur can engage). Plus exactly the three cycles the
+# questions' own descriptions name ("Circular: …"): value proposition ⇄
+# conventions, porteur ⇄ stakeholders, volume and pricing ⇄ performance. Cycles
+# are legal for `rests_on` — that is why this pack does not use `depends_on`.
 suggestedRelations:
-  - sourceRef: What is the offer, stated as the problem it ends?
-    targetRef: Who exactly buys it, and who merely benefits from it?
+  # Génération (internal): the chain produces what the proposition promises.
+  - sourceRef: "Value fabrication — what is the chain that actually produces the value, and which link do we own?"
+    targetRef: "Value proposition — for whom is this indispensable, and what do they stop doing once they have it?"
+    type: rests_on
+  # Rémunération rests on Génération.
+  - sourceRef: "Revenue sources — who pays, for which unit, and why that unit rather than another?"
+    targetRef: "Value proposition — for whom is this indispensable, and what do they stop doing once they have it?"
+    type: rests_on
+  - sourceRef: "Volume and pricing — what volume at what price clears the cost base, and is that volume reachable in this market?"
+    targetRef: "Value fabrication — what is the chain that actually produces the value, and which link do we own?"
+    type: rests_on
+  - sourceRef: "Volume and pricing — what volume at what price clears the cost base, and is that volume reachable in this market?"
+    targetRef: "Revenue sources — who pays, for which unit, and why that unit rather than another?"
+    type: rests_on
+  - sourceRef: "Performance — which number tells us the model works, and what observation would falsify it?"
+    targetRef: "Volume and pricing — what volume at what price clears the cost base, and is that volume reachable in this market?"
     type: rests_on
-  - sourceRef: What is the offer, stated as the problem it ends?
-    targetRef: What means — people, tools, licences, premises — must exist first?
+  # Partage rests on Génération / Rémunération.
+  - sourceRef: "Stakeholders — who must say yes for this to exist, and what does each of them need in return?"
+    targetRef: "Porteur — what does the founder bring that cannot be hired, and what does the venture require of them personally?"
     type: rests_on
-  - sourceRef: What means — people, tools, licences, premises — must exist first?
-    targetRef: Where does the money come from before revenue does?
+  - sourceRef: "Stakeholders — who must say yes for this to exist, and what does each of them need in return?"
+    targetRef: "Revenue sources — who pays, for which unit, and why that unit rather than another?"
     type: rests_on
-  - sourceRef: Where does the money come from before revenue does?
-    targetRef: What is the offer, stated as the problem it ends?
+  - sourceRef: "Conventions — which rules bind us, who enforces them, and which are mandatory rather than advisory?"
+    targetRef: "Value proposition — for whom is this indispensable, and what do they stop doing once they have it?"
     type: rests_on
-  - sourceRef: Where does the money come from before revenue does?
-    targetRef: Which conventions bind this model, and which are still assumed?
+  - sourceRef: "Ecosystem — what does the venture give back, and what breaks if we extract without returning?"
+    targetRef: "Stakeholders — who must say yes for this to exist, and what does each of them need in return?"
     type: rests_on
-  - sourceRef: Who exactly buys it, and who merely benefits from it?
-    targetRef: Which conventions bind this model, and which are still assumed?
+  # The three named cycles (the back edges).
+  - sourceRef: "Value proposition — for whom is this indispensable, and what do they stop doing once they have it?"
+    targetRef: "Conventions — which rules bind us, who enforces them, and which are mandatory rather than advisory?"
     type: rests_on
-  - sourceRef: What does one unit of delivery actually cost to produce?
-    targetRef: What does the porteur's situation forbid?
+  - sourceRef: "Porteur — what does the founder bring that cannot be hired, and what does the venture require of them personally?"
+    targetRef: "Stakeholders — who must say yes for this to exist, and what does each of them need in return?"
     type: rests_on
-  - sourceRef: What is the offer, stated as the problem it ends?
-    targetRef: Who is the porteur, and what does the model rest on them for?
+  - sourceRef: "Volume and pricing — what volume at what price clears the cost base, and is that volume reachable in this market?"
+    targetRef: "Performance — which number tells us the model works, and what observation would falsify it?"
     type: rests_on
 
+# ── The method: a TRACK TEMPLATE (scope project) ───────────────────────────
+# The six steps of the founder's approved live method (73848ca9 on the pod),
+# verbatim: goals, suggestedTasks, categories, and the open-ended `maintain`
+# step. Two additions. (1) Each step's suggestedTasks OPEN with the exact titles
+# of the seeded GRP questions it answers (the step → question map; a stage
+# session is offered its goal + suggestedTasks, so the step names its questions
+# by the same title the seed dedupe keys on). (2) `domain` per step — the workspace TEMPLATE slug the
+# step is worked in (startStageSession resolves it to the project's installed
+# workspace, and falls back to the project home when it is missing). ONE domain
+# per step, the primary one:
+#   porteur          → foundation     the porteur role + non-goals/constraints are Foundation's.
+#   offer_buyer      → foundation     offer/audience/pain-point live there; buyer
+#                                     companies get the pod-wide `lead` role, which
+#                                     attaches from any workspace (W2b), so CRM is
+#                                     not needed to run this step.
+#   conventions_cost → foundation     the Conventions + Projections views this pack
+#                                     installs live in Foundation; both kinds are
+#                                     pod-wide, so the unit-cost projection still
+#                                     shows in Finance.
+#   money_means      → finance        money before revenue = revenue-stream/budget/
+#                                     expense, Finance's kinds.
+#   refutation       → research-base  a falsifiable test is a hypothesis with a
+#                                     date; hypothesis/finding live in Research.
+#   maintain         → foundation     the Deprecation Check starts from a changed
+#                                     Foundation element.
+# The session-scoped "Business Model Interrogation" this replaces is gone; the
+# live-only copy on the founder's pod (f93b155b) is retired by a governed archive.
 playbooks:
-  - name: Business Model Interrogation
-    description: Walk the nine components as questions, resolve each into a decision backed by evidence, and record the conventions and projections the model rests on — including the cycles.
-    goalTemplate: "Interrogate the business model for {venture} and record what it rests on. Steps: (1) Walk each of the nine seeded `question` entities in this workspace; where one is already answered, mark it and move on. (2) Resolve each into a `decision`, keeping the options that lost attached via `refutes` rather than deleting them. Where the evidence itself needs gathering, do that in the Research workspace and link back — do not restate sources here. (3) Every external rule discovered becomes a `convention` with its `issuer` and `sourceReference`; leave `bindingStatus` at `assumed` until the source text has actually been read, then `verified`. (4) Every number becomes a `projection` with its `assumptions` filled in — never a bare figure. (5) Wire the graph with `rests_on` — offer on audience, projection on offer, decision on convention. Do NOT try to make the graph acyclic: if the offer rests on the means and the means rest on the money and the money rests on the offer, record all three. (6) Attach `porteur` and `funder` roles to the real people and organisations instead of creating new entities for them. (7) Close by listing which conventions are still `assumed` and which projections carry `low` confidence — that list is the actual state of the model."
+  - name: Business Model (GRP)
+    description: The business-model method, run as a TRACK on a project (project-scoped). Walks the nine component questions as stages, resolves each into a decision backed by evidence, and records the conventions and projections the model rests on, including the cycles. Stages can be re-entered — the model is maintained, not finished.
+    goalTemplate: "Interrogate the business model of this project and record what it rests on: resolve each component question into a decision with evidence, keep conventions 'assumed' until their source is read, give every number a projection with its assumptions, and wire the graph with rests_on (cycles included)."
     icon: layout-grid
+    scope: project
+    stages:
+      - key: porteur
+        name: Porteur & constraints
+        category: started
+        domain: foundation
+        goal: Name who the model rests on and what their situation forbids.
+        suggestedTasks:
+          - "Porteur — what does the founder bring that cannot be hired, and what does the venture require of them personally?"
+          - Who is the porteur, and what does the model rest on them for?
+          - What does the porteur's situation forbid?
+      - key: offer_buyer
+        name: Offer & buyer
+        category: started
+        domain: foundation
+        goal: State the offer as the problem it ends, and separate payer, user and beneficiary.
+        suggestedTasks:
+          - "Value proposition — for whom is this indispensable, and what do they stop doing once they have it?"
+          - "Value fabrication — what is the chain that actually produces the value, and which link do we own?"
+          - What is the offer, stated as the problem it ends?
+          - Who exactly buys it, and who merely benefits from it?
+      - key: conventions_cost
+        name: Conventions & unit cost
+        category: started
+        domain: foundation
+        goal: Read the rules that bind the model and cost one unit of delivery.
+        suggestedTasks:
+          - "Stakeholders — who must say yes for this to exist, and what does each of them need in return?"
+          - "Conventions — which rules bind us, who enforces them, and which are mandatory rather than advisory?"
+          - "Ecosystem — what does the venture give back, and what breaks if we extract without returning?"
+          - Which conventions bind this model, and which are still assumed?
+          - What does one unit of delivery actually cost to produce?
+      - key: money_means
+        name: Money & means
+        category: started
+        domain: finance
+        goal: Find the money before revenue and the means that must exist first; record the circularity.
+        suggestedTasks:
+          - "Revenue sources — who pays, for which unit, and why that unit rather than another?"
+          - "Volume and pricing — what volume at what price clears the cost base, and is that volume reachable in this market?"
+          - Where does the money come from before revenue does?
+          - What means — people, tools, licences, premises — must exist first?
+      - key: refutation
+        name: Refutation test
+        category: started
+        domain: research-base
+        goal: Set the falsifiable observation and its date while it can still be set honestly.
+        suggestedTasks:
+          - "Performance — which number tells us the model works, and what observation would falsify it?"
+          - What observation would refute this model, and by when?
+          - List conventions still 'assumed' and projections with low confidence.
+      - key: maintain
+        name: Keep the model current
+        category: started
+        domain: foundation
+        indefinite: true
+        goal: When a foundation element changes, find what rests on it and re-check it (GRP Deprecation Check).
+        suggestedTasks:
+          - Run 'GRP Deprecation Check' when positioning, offer, value or a non-goal changes.
 
+  # The `maintain` step's work template (founder decision D4: joins the
+  # template). A SESSION template, verbatim from the live Foundation playbook.
+  - name: GRP Deprecation Check
+    description: Cross-workspace GRP deprecation check. When a Foundation element (positioning, differentiator, value, non-goal) is updated, this playbook finds linked entities in Radar, Brand, CRM, Content, Operations and creates tasks for owners. Non-Architech-specific — reusable for any venture using the GRP framework.
+    goalTemplate: "Check if {updated_part} deprecates linked GRP parts: detect cross-workspace dependencies, notify owners, plan updates, verify resolution"
+    # `{name}` is what a run substitutes; `{{name}}` never was (see
+    # playbook-goal-placeholders.test.ts). Declared so the run asks for it.
+    params:
+      - name: updated_part
+        type: text
+        label: Foundation element that changed
+        required: true
+    icon: refresh-cw
+    stages:
+      - key: detect_impact
+        name: Detect Impact
+        category: started
+      - key: notify_owners
+        name: Notify Owners
+        category: started
+      - key: plan_update
+        name: Plan Update
+        category: started
+      - key: verify
+        name: Verify Resolution
+        category: started
+
+# Founder decision D3: no shortcut on `question` (a question is answered inside
+# a step of the method, not by launching the method from it). The convention
+# shortcut points at the method.
 actionPlacements:
-  - profileSlug: question
-    surface: entity-detail
-    kind: playbook
-    ref: Business Model Interrogation
-    label: Interrogate as model component
   - profileSlug: convention
     surface: entity-detail
     kind: playbook
-    ref: Business Model Interrogation
+    ref: Business Model (GRP)
     label: Re-check what rests on this
 
 integrations:
   - templateKey: research-methods
   - templateKey: exa
+
+# ── taskIntents — WHAT THIS WORKSPACE NEEDS TO FUNCTION ───────────────────
+# Closed vocabulary: `@synap-core/types/capability-intents` (pod migrations
+# 0283/0284). DERIVED from the declared intents of this template's own
+# `integrations` capability packs — not hand-guessed. Checked at authoring
+# time by `validateTemplate` (`task-intent-unknown`) and by
+# `src/task-intents.test.ts`.
+taskIntents:
+  - search_external