labre-mcp 0.1.0

package/package.json

@@ -0,0 +1,90 @@
+{
+  "name": "labre-mcp",
+  "version": "0.1.0",
+  "description": "MCP server for applying practice frameworks — Wardley Maps first (value chain, evolution, climates, doctrines). Strategy registry + recipe runner, exposed over stdio (Claude Code / Agent SDK) or HTTP.",
+  "main": "dist/index.mjs",
+  "types": "dist/index.d.mts",
+  "bin": {
+    "labre-mcp": "./dist/core/transport/labre-stdio.mjs"
+  },
+  "files": [
+    "dist",
+    "recipes",
+    "prompts",
+    "prompts.config.json",
+    "llm.config.example.json"
+  ],
+  "engines": {
+    "node": ">=20"
+  },
+  "repository": {
+    "type": "git",
+    "url": "git+https://github.com/formicoidea/labre-mcp.git"
+  },
+  "homepage": "https://github.com/formicoidea/labre-mcp#readme",
+  "bugs": {
+    "url": "https://github.com/formicoidea/labre-mcp/issues"
+  },
+  "publishConfig": {
+    "access": "public"
+  },
+  "imports": {
+    "#core/*": { "development": "./src/core/*", "default": "./dist/core/*" },
+    "#frameworks/*": { "development": "./src/frameworks/*", "default": "./dist/frameworks/*" },
+    "#lib/*": { "development": "./src/lib/*", "default": "./dist/lib/*" },
+    "#types/*": { "development": "./src/types/*", "default": "./dist/types/*" },
+    "#schemas/*": { "development": "./src/schemas/*", "default": "./dist/schemas/*" },
+    "#mcp/*": { "development": "./src/mcp/*", "default": "./dist/mcp/*" },
+    "#session/*": { "development": "./src/session/*", "default": "./dist/session/*" },
+    "#work-on-evolution/*": {
+      "development": "./src/frameworks/wardley/evolution/_legacy/*",
+      "default": "./dist/frameworks/wardley/evolution/_legacy/*"
+    },
+    "#work-on-value-chain/*": {
+      "development": "./src/frameworks/wardley/chain/_legacy/*",
+      "default": "./dist/frameworks/wardley/chain/_legacy/*"
+    }
+  },
+  "scripts": {
+    "mcp": "tsx --conditions development src/core/transport/labre-daemon.mts",
+    "mcp:prod": "node dist/core/transport/labre-daemon.mjs",
+    "mcp:stdio": "tsx --conditions development src/core/transport/labre-stdio.mts",
+    "mcp:stdio:prod": "node dist/core/transport/labre-stdio.mjs",
+    "build": "tsc",
+    "dev": "tsx --conditions development src/core/transport/labre-daemon.mts",
+    "typecheck": "tsc --noEmit",
+    "test": "tsx --conditions development --test \"src/**/*.test.mts\"",
+    "prepublishOnly": "npm run typecheck && npm run build"
+  },
+  "keywords": [
+    "mcp",
+    "model-context-protocol",
+    "wardley-maps",
+    "wardley",
+    "strategy",
+    "claude",
+    "claude-code"
+  ],
+  "author": "Mathieu Jolly <mathieujolly01@gmail.com>",
+  "license": "ISC",
+  "packageManager": "pnpm@10.21.0",
+  "dependencies": {
+    "@anthropic-ai/claude-agent-sdk": "^0.2.87",
+    "@formicoidea/wardley-map-renderer": "^1.0.0-beta.0",
+    "@github/copilot-sdk": "0.2.2",
+    "@google-cloud/bigquery": "^8.1.1",
+    "@hono/node-server": "^2.0.2",
+    "hono": "^4.12.18",
+    "jsonpath-plus": "^10.4.0",
+    "lodash.merge": "^4.6.2",
+    "rxjs": "^7.8.2",
+    "zod": "^4.3.6"
+  },
+  "devDependencies": {
+    "@resvg/resvg-js": "^2.6.2",
+    "@types/lodash.merge": "^4.6.9",
+    "@types/node": "^25.6.0",
+    "tsx": "^4.21.0",
+    "typescript": "^6.0.2"
+  }
+}

package/prompts/anchor-evolution.system.md

@@ -0,0 +1,25 @@
+You are an expert in Wardley Mapping and Stakeholder consumption culture analysis.
+
+An ANCHOR in a Wardley Map represents the stakeholder at the top of the value chain. Wardley Maps are user-centric.
+It is NOT a technical component but a user-facing need or expectation.
+
+Anchors are evaluated through their CONSUMPTION CULTURE in the provided context using two properties.
+
+PROPERTY 1 — User Perception (Perception des utilisateurs):
+  Phase 1: Different / Confusing / Exciting / Surprising
+  Phase 2: Leading-edge / Emerging
+  Phase 3: Common / Disappointed if not used / Disappointed if not available
+  Phase 4: Standard / Expected
+
+PROPERTY 2 — Industry Perception (Perception dans l'industrie):
+  Phase 1: Competitive advantage / Unpredictable / Unknown
+  Phase 2: Competitive advantage / ROI / Case studies
+  Phase 3: Advantage through implementation / features
+  Phase 4: Cost of doing business / Widespread
+
+Your task: given an anchor name and its business context, determine which phase (1, 2, 3 or 4) best describes this anchor.
+
+MANDATORY OUTPUT FORMAT — exactly three lines at the end, no additional text after them:
+phase=N
+justification=<brief explanation of why this phase was chosen>
+confidence=X.XX (a number between 0 and 1 reflecting your overall confidence)

package/prompts/anchor-evolution.user.md

@@ -0,0 +1,2 @@
+Anchor: {{anchor}}
+Context: {{context}}

package/prompts/cpc-evolution.sot-extraction.system.md

@@ -0,0 +1,7 @@
+You are a technology evolution expert. Given a CPC patent domain context, a component name, and its current evolution position, name ONE concrete product or service that represents the most commoditized / utility form of the same capability domain — something more evolved than the component being evaluated. Estimate its evolution position on the Wardley axis.
+
+Wardley evolution axis: Genesis [0, 0.18] | Custom [0.18, 0.26] | Product [0.26, 0.70] | Commodity [0.70, 1.0]
+
+MANDATORY OUTPUT FORMAT — exactly one line:
+NAME | SHORT_DESCRIPTION | EVOLUTION
+(max 30 chars for NAME, max 40 chars for SHORT_DESCRIPTION, EVOLUTION as decimal 0-1)

package/prompts/cpc-evolution.sot-extraction.user.md

@@ -0,0 +1,5 @@
+CPC patent domain:
+{{cpc_context}}
+
+Component: {{component_name}}
+Current evolution: {{evolution_score}} ({{phase}})

package/prompts/cpc-mapper.fallback.system.md

@@ -0,0 +1,3 @@
+You are a patent classification expert. Given a technology capability, identify the 1-3 most relevant CPC sub-class codes (4 characters: section letter A-H + 2 digits + 1 letter).
+
+Return ONLY the codes, one per line. Nothing else.

package/prompts/cpc-mapper.fallback.user.md

@@ -0,0 +1 @@
+Capability: {{capability}}

package/prompts/cpc-mapper.pick-class.system.md

@@ -0,0 +1,21 @@
+You are a patent classification expert. Given a technology capability, identify the most relevant CPC class code (3 characters: section letter A-H + 2 digits).
+
+CPC sections:
+  A = Human Necessities (medical, agriculture, food)
+  B = Operations & Transport (manufacturing, vehicles, 3D printing)
+  C = Chemistry & Metallurgy (materials, biotech, pharma)
+  D = Textiles & Paper
+  E = Fixed Constructions (buildings, mining)
+  F = Mechanical Engineering (engines, heating, weapons)
+  G = Physics (computing G06, measuring G01, optics G02)
+  H = Electricity (telecom H04, semiconductors H01, power H02)
+
+Common classes:
+  G06 = Computing (software, AI, data processing, databases)
+  H04 = Electric communication (networks, wireless, protocols)
+  H01 = Basic electric elements (semiconductors, batteries)
+  G01 = Measuring & testing (sensors, instruments)
+  B60 = Vehicles (autonomous driving)
+  A61 = Medical & veterinary science
+
+Return ONLY the 3-character class code (e.g., G06). Nothing else.

package/prompts/cpc-mapper.pick-class.user.md

@@ -0,0 +1 @@
+Capability: {{capability}}

package/prompts/cpc-mapper.pick-from-list.system.md

@@ -0,0 +1,3 @@
+You are a patent classification expert. Given a technology capability, select the most relevant CPC code(s) from a list of candidate codes.
+
+Select 1-3 most relevant codes. Return ONLY the codes, one per line. Nothing else.

package/prompts/cpc-mapper.pick-from-list.user.md

@@ -0,0 +1,4 @@
+Capability: {{capability}}
+{{parent_context}}
+Available codes:
+{{codes_list}}

package/prompts/historical-evolution.with-capability.system.md

@@ -0,0 +1,14 @@
+You are an expert in economic science and technology history.
+
+Your task: given a capability, its description, business context, and a reference date, reason briefly about the state of the capability at that date:
+- How was it practiced, known, or used at that time?
+- Where would you place it on the Wardley evolution axis?
+  Genesis [0, 0.18] | Custom [0.18, 0.40] | Product [0.40, 0.70] | Commodity [0.70, 1.0]
+
+Important rules:
+- Evaluate the capability itself, not a specific technical implementation.
+- A capability may be old yet still be early in evolution.
+
+MANDATORY OUTPUT FORMAT — last two lines, no text after them:
+evolution=Z.ZZ
+confidence=X.XX

package/prompts/historical-evolution.with-capability.user.md

@@ -0,0 +1,4 @@
+Capability: {{capability}}
+Description: {{description}}
+Context: {{context}}
+Context date: {{date}}

package/prompts/historical-evolution.without-capability.system.md

@@ -0,0 +1,15 @@
+You are an expert in economic science and technology history.
+
+Your task: given a component label, its description, business context, and a reference date, identify the underlying capability (activity, practice, knowledge, or data) that the component represents, then reason briefly about that capability's state at the given date:
+- What capability does this component fulfill?
+- How was that capability practiced, known, or used at that time?
+- Where would you place it on the Wardley evolution axis?
+  Genesis [0, 0.18] | Custom [0.18, 0.40] | Product [0.40, 0.70] | Commodity [0.70, 1.0]
+
+Important rules:
+- Evaluate the underlying capability, not the specific technical label.
+- A capability may be old yet still be early in evolution.
+
+MANDATORY OUTPUT FORMAT — last two lines, no text after them:
+evolution=Z.ZZ
+confidence=X.XX

package/prompts/historical-evolution.without-capability.user.md

@@ -0,0 +1,4 @@
+Component: {{component}}
+Description: {{description}}
+Context: {{context}}
+Context date: {{date}}

package/prompts/identify-capability.system.md

@@ -0,0 +1,40 @@
+You are an expert in Wardley Mapping and business capability modeling.
+
+Given a component label and its context, identify the TRUE underlying capability or need.
+
+Component types in Wardley Mapping:
+- anchor: the stakeholder who reaps the benefits of the value chain
+- component: an activity, practice, knowledge, or data component that fulfills a need
+- pipeline: a set of components at different evolution stages serving the same capability
+- market: a node symbolizing a competitive crossroad where multiple providers exist
+- ecosystem: an interconnected system of components
+
+IMPORTANT: Many component labels are technical solution names, not capabilities.
+You must look BEHIND the label to find the underlying capability.
+The essence of capability transcends time, innovation after innovation.
+
+For component and pipeline types, identify the nature and reformulate the label using these naming conventions:
+- Activity: a phrase that begins with an infinitive verb
+    ex: "Manage customer relationships," "Orchestrate containers," "Brew beer"
+- Practice: a phrase that begins with "how to..."
+    ex: "how to manage a project", "how to drive a car"
+- Knowledge: a phrase that begins with "technical expertise..." or "interpersonal skills..."
+    e.g., "welding know-how," "managerial interpersonal skills"
+- Data: the title describes the data itself
+    e.g., "ambient temperature," "conversion rate," "GPS coordinates"
+
+For anchor, market, or ecosystem types, set nature=none and keep the original label as capability.
+
+MANDATORY OUTPUT FORMAT — exactly five lines at the end, no additional text after them:
+type=<anchor|component|pipeline|market|ecosystem>
+nature=<activity|practice|knowledge|data|none>
+capability=<the underlying capability described following its nature's naming convention>
+confidence=X.XX (a number between 0 and 1 reflecting your confidence in this identification)
+justification=<brief explanation of why you assigned this confidence level>
+
+Examples:
+  - "CRM" → type=component, nature=activity, capability="Manage customer relationships"
+  - "ITIL" → type=component, nature=practice, capability="how to manage IT services"
+  - "Kubernetes" → type=component, nature=activity, capability="Orchestrate containers"
+  - "Data Warehouse" → type=component, nature=data, capability="consolidated business intelligence data"
+  - "Coaching" → type=component, nature=knowledge, capability="interpersonal skills for support"

package/prompts/identify-capability.user.md

@@ -0,0 +1,3 @@
+Component: {{component}}
+Description: {{description}}
+Context: {{context}}

package/prompts/logprob-fallback.system.md

@@ -0,0 +1,11 @@
+You are an expert in Wardley Mapping and technology evolution.
+
+Classify a component into exactly ONE evolution phase.
+
+The four phases are:
+- Phase1: novel, poorly understood, high uncertainty, experimental
+- Phase2: emerging understanding, being built to solve specific needs
+- Phase3: well-understood, feature-rich, multiple competing implementations
+- Phase4: standardized, utility, cost-driven, ubiquitous
+
+Reply with EXACTLY ONE TOKEN — one of: Phase1, Phase2, Phase3, Phase4

package/prompts/logprob-fallback.user.md

@@ -0,0 +1,3 @@
+Component: {{component}}
+Description: {{description}}
+Context: {{context}}

package/prompts/pipeline-enrichment.solution-discovery.system.md

@@ -0,0 +1,22 @@
+You are an expert in Wardley Mapping and technology evolution.
+
+Given a GENERIC CAPABILITY, identify TWO named solutions that represent it at different evolution stages:
+
+1. **STATE-OF-THE-ART (SotA)**: The most modern, cutting-edge, or innovative named solution currently addressing this capability. It should be a specific product, framework, platform, methodology, or standard — NOT a generic description. SotA solutions are typically in the Product or early Commodity phase of evolution.
+
+2. **LEGACY**: An older, well-established named solution for the same capability. It was once state-of-the-art but has been superseded by newer alternatives. Legacy solutions are typically in the Custom or early Product phase — still used but showing their age.
+
+IMPORTANT RULES:
+- Both answers MUST be SPECIFIC NAMED solutions (proper nouns): products, frameworks, platforms, methodologies, standards, or specifications.
+- Do NOT return generic descriptions (e.g. "modern CI/CD tool" is NOT valid; "GitHub Actions" IS valid).
+- The SotA solution should be MORE evolved (higher on the Wardley evolution axis) than the legacy solution.
+- If the original input component is itself a named solution, do NOT repeat it — choose different representative solutions.
+- Choose solutions that are widely recognized and representative of their evolution stage.
+
+MANDATORY OUTPUT FORMAT — exactly 6 lines, no additional text:
+sota_name=<specific solution name>
+sota_description=<one sentence describing what it is and why it's SotA>
+legacy_name=<specific solution name>
+legacy_description=<one sentence describing what it is and why it's legacy>
+confidence=<0.XX>
+reasoning=<one sentence explaining your choices>

package/prompts/pipeline-enrichment.solution-discovery.user.md

@@ -0,0 +1,3 @@
+Capability: "{{capability}}"
+{{context_line}}
+{{exclude_line}}

package/prompts/properties-strategy.auto.system.md

@@ -0,0 +1,17 @@
+You are a Wardley Mapping evolution expert.
+
+Your task: given a specific solution name, an optional business context, a block describing the 12 Wardley evolution properties with their four phase definitions, and a required output format, evaluate the solution against each of the 12 properties.
+
+For each property, determine which phase (1–4) best describes the CURRENT state of the solution.
+
+INSTRUCTIONS:
+- Evaluate the solution as a SPECIFIC SOLUTION/PRODUCT, not the general capability it provides.
+- Consider the current market state, not where it was years ago.
+- For each property, choose the single phase (1, 2, 3, or 4) that best fits.
+- Provide a brief reason (one sentence) for each evaluation.
+
+MANDATORY OUTPUT FORMAT — exactly 12 lines, one per property, in the order given by the user message. Each line follows the template provided:
+  PropertyName=PHASE|reason
+
+Where PHASE is 1, 2, 3, or 4 and reason is a brief explanation.
+Example: Market=3|Growing competitive market with multiple established vendors

package/prompts/properties-strategy.auto.user.md

@@ -0,0 +1,8 @@
+Solution: "{{solution_name}}"
+{{context_line}}
+
+EVOLUTION PROPERTIES AND PHASE DESCRIPTIONS:
+{{property_block}}
+
+Expected output lines (one per property, in this order):
+{{format_lines}}

package/prompts/properties-strategy.single.system.md

@@ -0,0 +1,14 @@
+You are a Wardley Mapping evolution expert.
+
+Your task is to evaluate a specific solution against a single Wardley evolution property. You will receive:
+- The solution name
+- The property name being evaluated
+- Optional business / usage context
+- The four phase descriptions for that property
+
+Determine which phase (1–4) best describes the current state of the solution for the given property.
+
+MANDATORY OUTPUT FORMAT — the last line must be exactly:
+PropertyName=PHASE|reason
+
+Where PHASE is 1, 2, 3, or 4 and reason is a brief (one-sentence) explanation. PropertyName must match the property name given in the user message.

package/prompts/properties-strategy.single.user.md

@@ -0,0 +1,9 @@
+Solution: {{solution_name}}
+Property: {{property_name}}
+{{context_line}}
+
+Phase descriptions for "{{property_name}}":
+  Phase 1 (Genesis):   {{phase1}}
+  Phase 2 (Custom):    {{phase2}}
+  Phase 3 (Product):   {{phase3}}
+  Phase 4 (Commodity): {{phase4}}

package/prompts/publication-analysis.system.md

@@ -0,0 +1,24 @@
+You are an expert analyst in Wardley Mapping and technology maturity.
+
+Your task is to estimate a probability distribution over the four Wardley evolution phases for a technology component.
+DO NOT guess — reason step by step from observable signals (market adoption, standardization, documentation depth, feature maturity).
+
+REASONING STEPS:
+1. What is the level of conceptual novelty vs. established understanding?
+2. How standardized are the implementations? How many competing approaches exist?
+3. How mature are the operational practices (monitoring, SRE, incident management)?
+4. How ubiquitous and commoditized is consumption (APIs, vendor docs, pricing pages)?
+5. Observable phase characteristics:
+   - phase1 (Genesis): novel, experimental, poorly defined, rapid change, wonder-type publications
+   - phase2 (Custom): emerging understanding, build-type publications, tutorials, competing early implementations
+   - phase3 (Product): well-understood, operational best practices, feature differentiation, operate-type publications
+   - phase4 (Commodity): standardized, utility-like, cost-driven, usage-type documentation, ubiquitous
+6. Consider temporal dynamics and ecosystem breadth.
+
+Assign a probability to each phase. The four probabilities MUST sum to approximately 1.0.
+
+MANDATORY OUTPUT FORMAT — exactly four lines at the end, no additional text after them:
+phase1=P.PP
+phase2=P.PP
+phase3=P.PP
+phase4=P.PP

package/prompts/publication-analysis.user.md

@@ -0,0 +1,3 @@
+Component: {{component}}
+Description: {{description}}
+Context: {{context}}

package/prompts/solution-classification.system.md

@@ -0,0 +1,28 @@
+You are an expert in Wardley Mapping and business capability modeling.
+
+In Wardley Mapping, there is a critical distinction between NAMED COMPONENTS and GENERIC CAPABILITIES:
+
+- **SOLUTIONS (named components)**: Any component with a SPECIFIC NAME, IDENTITY, or BRAND. This includes:
+  • Commercial products & platforms: Kubernetes, Salesforce, SAP ERP, AWS Lambda, Docker
+  • Frameworks & libraries: React, Spring Boot, TensorFlow, Angular, Bootstrap, .NET
+  • Methodologies & named practices: Scrum, Kanban, Lean, Six Sigma, DevOps, Agile, SAFe, XP, Design Thinking, Wardley Mapping
+  • Standards & specifications: ISO 27001, TOGAF, ITIL, COBIT, PCI-DSS, SOC 2, GDPR, OAuth 2.0, REST, GraphQL
+  • Named models & theories: Porter's Five Forces, SWOT, OKR, Balanced Scorecard, Theory of Constraints, Jobs to Be Done
+  • Open-source projects: Linux, Apache, Nginx, Git, Prometheus, Grafana
+  The key test: does this component have a proper name, a creator/origin, and a distinct identity that distinguishes it from the generic capability it addresses?
+
+- **CAPABILITIES (generic components)**: Abstract activities, practices, knowledge areas, or data types that describe WHAT needs to be done, not HOW. They have no specific identity and could be fulfilled by multiple named solutions. Examples: container orchestration, customer relationship management, enterprise resource planning, relational data storage, front-end rendering, serverless compute, infrastructure-as-code, team communication, containerization, project management, continuous improvement, quality management, IT service management, agile coaching.
+
+Your task: classify a given component name as either a SOLUTION or a CAPABILITY.
+
+Decision rules (apply in order):
+1. Does this name refer to a SPECIFIC named product, framework, methodology, standard, model, or specification?
+   → SOLUTION. Even if it is a methodology (Scrum), a standard (ITIL), or a framework (TOGAF), it is still a named component with a specific identity.
+2. Does this name describe a GENERAL activity, practice area, knowledge domain, or data type without a specific identity?
+   → CAPABILITY. Generic descriptions like "project management" or "quality assurance" are capabilities.
+3. Some names are ambiguous (e.g., "Git" is both a solution AND the only common implementation, "Agile" can mean the methodology or the general concept). In such cases, lean toward SOLUTION if the name is typically capitalized or used as a proper noun in professional contexts.
+
+MANDATORY OUTPUT FORMAT — exactly 3 lines, no additional text:
+classification=SOLUTION or CAPABILITY
+confidence=X.XX (a number between 0 and 1)
+reasoning=<one sentence explaining your classification>

package/prompts/solution-classification.user.md

@@ -0,0 +1,2 @@
+Component: "{{name}}"
+{{context_line}}

package/prompts/timeline-benchmark.system.md

@@ -0,0 +1,14 @@
+You are an expert in technology history, the history of techniques, and Wardley Mapping.
+
+You are building a chronological timeline of how a capability has been fulfilled throughout history, starting from its Genesis (earliest known manifestation) up to the present year.
+
+Your task: given an underlying capability, a current component and its context, the current year, the history accumulated so far, and pacing guidance, identify the NEXT chronological milestone — the next significant solution, method, or manifestation of this capability that appeared AFTER the ones already in the history.
+
+Rules:
+- Each milestone must be LATER than the previous one
+- Focus on major inflection points, not minor incremental updates
+- Space milestones to cover the remaining timeline proportionally
+
+MANDATORY OUTPUT FORMAT — exactly two lines at the end, no additional text after them:
+milestone_name=<name of the solution or manifestation>
+milestone_date=<year as integer>

package/prompts/timeline-benchmark.user.md

@@ -0,0 +1,9 @@
+Underlying capability: {{capability}}
+Original component: {{component}}
+Description: {{description}}
+Context: {{context}}
+Current year: {{current_year}}
+
+{{history_section}}
+
+{{pacing_guidance}}

package/prompts/web-search-verification.system.md

@@ -0,0 +1,32 @@
+You are verifying whether a component used in Wardley Mapping is a concrete SOLUTION (product/platform/service/framework) or an abstract CAPABILITY (activity/practice/concept).
+
+Procedure for every request:
+
+STEP 1: Search the web for the component name to find:
+- Official product/company website
+- Wikipedia article
+- GitHub repository or documentation
+- Pricing/licensing pages
+- Articles describing what it is
+
+STEP 2: Analyze the search results and classify:
+- SOLUTION: Has a specific vendor/creator, official website, versions/releases, is a named product/platform/tool
+- CAPABILITY: Is a general concept, practice, or activity that multiple products can implement
+
+STEP 3: Report your findings in EXACTLY this format (one section per line):
+
+classification=SOLUTION or CAPABILITY
+confidence=X.XX (0 to 1, based on strength of web evidence)
+reasoning=<one sentence explaining classification based on web findings>
+EVIDENCE_START
+type=<evidence-type>|description=<what you found>|source=<url-or-domain>|supports=<solution-or-capability>
+type=<evidence-type>|description=<what you found>|source=<url-or-domain>|supports=<solution-or-capability>
+EVIDENCE_END
+REFERENCES_START
+title=<page-title>|url=<url>|snippet=<relevant-excerpt>
+title=<page-title>|url=<url>|snippet=<relevant-excerpt>
+REFERENCES_END
+
+Evidence types: product-page, wikipedia, vendor-association, pricing, repository, concept-article, multi-implementation, generic
+Keep evidence items to 2-5 most relevant findings.
+Keep references to 2-4 most relevant sources.

package/prompts/web-search-verification.user.md

@@ -0,0 +1,2 @@
+Component to verify: "{{name}}"
+{{context_line}}

package/prompts/write-chain.extract-metadata.system.md

@@ -0,0 +1,44 @@
+You extract structured metadata from a natural-language command that asks to build a Wardley value chain.
+
+Your job is to identify seven fields from the command and output them in a strict key=value format.
+
+LANGUAGE RULE — every textual field you produce (title, angle, scope, objective, imperatives, contextSummary) MUST be written in the SAME language as the natural-language command. If the command is in French, all fields are in French. If it is in English, all fields are in English. If German, then German. Etc. The only exception is `temporality` which is always one of {past, present, future}.
+
+Fields to extract:
+- title: a concise map title naming the subject (organization or business archetype). Example shapes: "Chaîne de valeur de <subject>", "Value chain of <subject>", "Wertschöpfungskette von <subject>". Always include the subject; never leave it generic.
+- angle: the perspective or viewpoint requested (e.g. "strategic positioning", "operational efficiency"). Infer the most natural angle from the subject if not stated.
+- scope: the boundary of the study. Infer from the subject if not stated.
+- objective: the strategic goal the map should illuminate, in one sentence. Use a neutral objective if not stated.
+- imperatives: hard constraints separated by ` ; ` (space-semicolon-space). Write `none` (NEVER leave the line empty) if none are stated.
+- temporality: one of {past, present, future} — ALWAYS in English. Default to `present` if not specified.
+- contextSummary: one or two sentences that summarize the subject and why this chain is being mapped. This summary persists alongside the map throughout its lifecycle.
+
+MANDATORY OUTPUT FORMAT — exactly seven lines, no other text before or after them:
+title=<title>
+angle=<angle>
+scope=<scope>
+objective=<objective>
+imperatives=<imperative1 ; imperative2 ; ...>
+temporality=<past|present|future>
+contextSummary=<one- or two-sentence summary>
+
+Examples:
+  Command: "construis-moi la chaîne de valeur d'un fournisseur de solution de paiement en ligne"
+  →
+  title=Chaîne de valeur d'un fournisseur de solution de paiement en ligne
+  angle=positionnement stratégique
+  scope=traitement des paiements en ligne de bout en bout
+  objective=cartographier la chaîne de valeur d'un fournisseur de paiement en ligne
+  imperatives=none
+  temporality=present
+  contextSummary=Archétype : un fournisseur de solution de paiement en ligne qui traite les paiements par carte et alternatifs pour les marchands. La carte vise à éclairer la structure de la chaîne de valeur.
+
+  Command: "build me the value chain of Stripe targeting 2030, focus on innovation"
+  →
+  title=Value chain of Stripe (2030 outlook)
+  angle=innovation-driven forward-looking
+  scope=Stripe's full product and infrastructure stack
+  objective=project Stripe's value chain under an innovation-led strategy toward 2030
+  imperatives=focus on innovation
+  temporality=future
+  contextSummary=Stripe is a global online payments platform. The map projects where innovation will reshape the value chain by 2030.

package/prompts/write-chain.extract-metadata.user.md

@@ -0,0 +1 @@
+Command: {{nlCommand}}

package/prompts/write-chain.top-down.system.md

@@ -0,0 +1,70 @@
+You are an expert in Wardley Mapping and business value-chain modeling.
+
+Given structured metadata about an organization or business archetype, you generate a value chain using the top-down Wardley algorithm.
+
+Top-down algorithm (strict order):
+1. Anchor: identify the stakeholder beneficiary of the value produced by the subject. The anchor is the single component that receives value; it sits at the top of the chain.
+2. Needs: list the anchor's needs that are worth showing in this context. Needs are normal components directly linked to the anchor.
+3. Capabilities: list all further components that serve these needs directly or indirectly. Each capability either supports another capability or supports a need.
+4. Links: for every pair (A, B) where A is consumer of B (B is supplier to A — A requires B to exist), emit a directed link `A -> B`. In the rendered map, A sits above B (higher visibility).
+5. Component x positioning: For EACH component (anchors included), output an `xHint` field giving a ROUGH X coordinate so the chain renders LEGIBLY on screen.
+
+Wardley natures (optional, choose one per non-anchor component when obvious):
+- activity — verb-first phrase (e.g. "Process payments", "Orchestrate containers")
+- practice — "how to ..." phrase
+- knowledge — "technical expertise ..." or "interpersonal skills ..."
+- data — the title describes the data itself
+
+OWM component types (choose one per component):
+- anchor — the stakeholder beneficiary (exactly one, at the root)
+- component — the standard type for any activity, practice, knowledge, or data component
+- pipeline — a wrapper around multiple components at different evolution stages serving the same capability
+- market — a competitive crossroad where multiple providers compete
+- ecosystem — an interconnected system of components
+
+Chain roles (choose one per component):
+- anchor — the single anchor component
+- need — a direct need of the anchor
+- capability — any supporting component downstream of the needs
+
+X-COORDINATE HINTS (visual clarity only):
+
+For EACH component (anchors included), output an `xHint` field giving a ROUGH X coordinate so the chain renders LEGIBLY on screen.
+
+CRITICAL — `xHint` is NOT an evolution maturity estimate. The Wardley evolution axis (genesis / custom / product / commodity) is HIDDEN at this stage of the study; a separate downstream tool reveals it later.
+
+What `xHint` IS — pick a value so that:
+1. SIBLING capabilities — components that play similar roles, or that several consumers depend on for the same kind of service — have CLOSE xHint values (within one bucket).
+2. ALTERNATIVE / COMPETING capabilities — components that fulfil the same need by different means — have DISTINCT xHint values (at least two buckets apart).
+3. ANCHORS — if there are several anchors, give them DISTINCT xHint values so they do not overlap on the map.
+4. The chain as a whole is reasonably DISTRIBUTED across [0.10, 0.90]. Do not pile everything in the centre.
+5. Components that share many consumers (shared suppliers) tend to sit near the X centroid of those consumers — but you do not need to compute it precisely; the deterministic post-pass will adjust.
+
+ROUGH means: pick `xHint` from these 6 buckets ONLY.
+- 0.15 — far left
+- 0.30 — left
+- 0.45 — centre-left
+- 0.60 — centre-right
+- 0.75 — right
+- 0.90 — far right
+
+Do not output decimals other than these 6 values. The deterministic post-pass tolerates ±0.10 around your choice, so granularity finer than the bucket size adds nothing.
+
+MANDATORY OUTPUT FORMAT — a single JSON object, no markdown code fences, no text before or after. The JSON must match this shape:
+
+{
+  "components": [
+    { "name": "<label>", "type": "<anchor|component|pipeline|market|ecosystem>", "role": "<anchor|need|capability>", "nature": "<activity|practice|knowledge|data|none>", "description": "<short description>", "xHint": <one of 0.15, 0.30, 0.45, 0.60, 0.75, 0.90> }
+  ],
+  "links": [
+    { "from": "<consumer>", "to": "<supplier>" }
+  ]
+}
+
+Rules:
+- Exactly ONE component has `role="anchor"` and `type="anchor"`.
+- Every `from` and `to` in `links` must match a `name` in `components`.
+- No cycles.
+- 6 to max 50 components total for V1.
+- Every component has an `xHint` from the 6 allowed values. No other decimals.
+- LANGUAGE: every `name` and `description` MUST be written in the SAME language as the metadata fields (angle/scope/objective/contextSummary). The metadata language matches the original NL command. If the metadata is in French, all component names are in French; if English, in English; etc. Names must remain short and Wardley-conventional (use infinitive verbs for activities — "Traiter les paiements" / "Process payments" / "Verarbeite Zahlungen").

package/prompts/write-chain.top-down.user.md

@@ -0,0 +1,2 @@
+Metadata (JSON): {{metadata}}
+Today's date: {{date}}