@mindrian_os/cli 1.13.0-beta.10 → 1.13.0-beta.44

package/lib/wiki/wiki-watcher.cjs

@@ -1,105 +0,0 @@
-'use strict';
-/**
- * wiki-watcher.cjs — File watcher + SSE broadcast for wiki auto-refresh
- *
- * Watches room/ directory via chokidar. On file changes,
- * calls the onChange callback and broadcasts SSE events
- * to all connected browser clients.
- */
-
-const chokidar = require('chokidar');
-const path = require('path');
-
-const sseClients = new Set();
-
-/**
- * Start watching a room directory for changes.
- * @param {string} roomDir - Path to room/ directory
- * @param {function} onChangeCallback - Called with { event, path } on changes
- * @returns {object} chokidar watcher instance
- */
-function startWatcher(roomDir, onChangeCallback) {
-  const absRoom = path.resolve(roomDir);
-
-  const watcher = chokidar.watch(absRoom, {
-    ignoreInitial: true,
-    ignored: [
-      /\.mindrian/,
-      /\.reasoning/,
-      /node_modules/,
-      /\.git/
-    ],
-    persistent: true,
-    awaitWriteFinish: {
-      stabilityThreshold: 300,
-      pollInterval: 100
-    }
-  });
-
-  watcher.on('all', (event, filePath) => {
-    // Only care about .md file changes
-    if (!filePath.endsWith('.md')) return;
-
-    const relPath = path.relative(absRoom, filePath);
-
-    // Call the application callback (rebuild index, etc.)
-    if (typeof onChangeCallback === 'function') {
-      onChangeCallback({ event, path: relPath });
-    }
-
-    // Broadcast SSE event to all connected clients
-    broadcast({ event: 'change', path: relPath, type: event });
-  });
-
-  return watcher;
-}
-
-/**
- * Add an SSE client (Express response object).
- * Sets appropriate headers and sends initial keepalive.
- * @param {object} res - Express response object
- */
-function addSSEClient(res) {
-  res.writeHead(200, {
-    'Content-Type': 'text/event-stream',
-    'Cache-Control': 'no-cache',
-    'Connection': 'keep-alive'
-  });
-
-  // Initial keepalive comment
-  res.write(':keepalive\n\n');
-
-  sseClients.add(res);
-
-  // Clean up on disconnect
-  res.on('close', () => {
-    removeSSEClient(res);
-  });
-}
-
-/**
- * Remove an SSE client from the set.
- * @param {object} res - Express response object
- */
-function removeSSEClient(res) {
-  sseClients.delete(res);
-}
-
-/**
- * Broadcast an SSE event to all connected clients.
- * @param {object} data - Event data to serialize as JSON
- */
-function broadcast(data) {
-  const message = `data: ${JSON.stringify(data)}\n\n`;
-
-  for (const client of sseClients) {
-    try {
-      client.write(message);
-    } catch (e) {
-      // Client disconnected — remove
-      sseClients.delete(client);
-    }
-  }
-}
-
-module.exports = { startWatcher, addSSEClient, removeSSEClient };

package/pipelines/analogy/01-decompose.md

@@ -1,80 +0,0 @@
----
-stage: 1
-methodology: reason
-chain: analogy
-input_from: null
-output_to: abstract
-room_section: problem-definition
----
-
-# Stage 1: Decompose (SAPPhIRE Extraction)
-
-## Input Extraction
-
-First stage -- uses room artifacts across all sections. No prior pipeline artifact needed.
-
-Scan `room/STATE.md` for venture context: problem type, venture stage, filled sections. Then read key artifacts from the most populated sections (problem-definition, solution-design, market-analysis) to understand the venture's core challenge.
-
-If the user provided a specific problem or contradiction when starting the pipeline, use that as the focal point. Otherwise, identify the venture's primary challenge from room state.
-
-## Stage Instructions
-
-Run `/mos:reason` with the venture's core problem, framing the decomposition around SAPPhIRE layers.
-
-Read `references/methodology/sapphire-encoding.md` for the SAPPhIRE ontology reference.
-
-For each major room artifact, extract:
-
-### SAPPhIRE Triples
-
-| Layer | Question | Extract From |
-|-------|----------|-------------|
-| **State** | What is the current situation/condition? | problem-definition/ |
-| **Action** | What action does the system perform? | solution-design/ |
-| **Part** | What structural components exist? | team-execution/ |
-| **Phenomenon** | What observable behaviors/trends drive this? | market-analysis/ |
-| **Input** | What resources/inputs does the system consume? | business-model/ |
-| **Real effect** | What underlying principle/mechanism operates? | competitive-analysis/ |
-| **Effect** | What measurable outcome results? | financial-model/ |
-
-### Core Contradiction Identification
-
-Identify the venture's CORE CONTRADICTION -- the tension where improving one dimension worsens another:
-- "Increasing [X] degrades [Y]"
-- "We need [A] but [A] prevents [B]"
-- "Our strength in [domain] becomes a weakness when [condition]"
-
-Check existing KuzuDB `CONTRADICTS` edges if available:
-```
-Scan room/.lazygraph/ for existing contradiction edges
-```
-
-### Function-Behavior-Structure Encoding
-
-For the core problem, produce:
-- **Function:** What the system DOES (verb + object, domain-independent)
-- **Behavior:** HOW it achieves the function (mechanism)
-- **Structure:** WHAT components enable the behavior (parts and relationships)
-
-Larry should push the user past domain-specific language: "You say 'customer acquisition' -- but functionally, what are you doing? You're FILTERING a population by fit criteria and CONVERTING interest to commitment. Those are functions that exist everywhere."
-
-When the methodology produces its artifact, ensure pipeline provenance is added to frontmatter:
-
-```yaml
-pipeline: analogy
-pipeline_stage: 1
-sapphire_function: "[extracted function]"
-sapphire_behavior: "[extracted behavior]"
-sapphire_structure: "[extracted structure]"
-core_contradiction: "[improving X] vs [worsening Y]"
-```
-
-## Output Contract
-
-The following sections from the artifact feed into Stage 2 (abstract):
-
-- **SAPPhIRE triples** -- become the input for domain-independent encoding
-- **Core contradiction** -- becomes the target for TRIZ parameter mapping
-- **Function-behavior-structure** -- becomes the basis for cross-domain search queries
-
-Stage 2 will extract these by scanning `room/problem-definition/` for the most recent artifact with `pipeline: analogy` and `pipeline_stage: 1` in frontmatter.

package/pipelines/analogy/02-abstract.md

@@ -1,87 +0,0 @@
----
-stage: 2
-methodology: reason
-chain: analogy
-input_from: decompose
-output_to: search
-room_section: problem-definition
----
-
-# Stage 2: Abstract (Domain-Independent Encoding)
-
-## Input Extraction
-
-Extract from Stage 1 artifact (scan `room/problem-definition/` for most recent artifact with `pipeline: analogy` and `pipeline_stage: 1` in frontmatter):
-
-- **SAPPhIRE triples** -- the function-behavior-structure decomposition per room section
-- **Core contradiction** -- the improving-vs-worsening tension
-- **Function-behavior-structure** -- the domain-specific encoding to be abstracted
-
-Present to the user: "From the decomposition, I'm abstracting: [function] as the core function, with [contradiction] as the key tension to resolve."
-
-## Stage Instructions
-
-The goal is to strip ALL domain-specific language and produce a purely functional description that could apply to any field. This is what enables cross-domain search -- you cannot find analogies in biology if you keep using business terminology.
-
-### Step 1: Functional Verb Replacement
-
-Replace every domain-specific term with a standardized functional verb. Read `references/methodology/sapphire-encoding.md` for the functional verb vocabulary.
-
-Standard functional verbs: deliver, protect, transform, connect, filter, amplify, regulate, separate, convert, store, distribute, stabilize, absorb, channel, detect, signal, adapt, repair, recycle, generate.
-
-Examples:
-- "Customer acquisition funnel" becomes "filter population by fit criteria, convert interest to commitment"
-- "Tumor drug resistance" becomes "adaptive barrier blocks delivery system"
-- "Supply chain optimization" becomes "minimize transfer distance while maintaining flow capacity"
-- "Competitive moat" becomes "structural barrier that increases with usage"
-
-Larry should challenge domain-locked thinking aggressively: "You keep saying 'market penetration' -- but functionally, what is penetration? It's overcoming a barrier to reach a target. Where else do systems overcome barriers to reach targets? Everywhere -- cell membranes, firewalls, military logistics, root systems in soil."
-
-### Step 2: TRIZ Parameter Mapping
-
-Read `references/methodology/triz-principles.md` for the 39 TRIZ parameters and 40 inventive principles.
-
-Map the core contradiction to TRIZ parameter space:
-1. Identify which of the 39 parameters the venture is trying to IMPROVE
-2. Identify which of the 39 parameters WORSENS as a result
-3. Look up the TRIZ Contradiction Matrix intersection for suggested inventive principles
-
-Read `references/methodology/triz-matrix.json` for the contradiction matrix data.
-
-Format:
-```
-TRIZ Contradiction:
-  Improving: Parameter [N] - [name]
-  Worsening: Parameter [M] - [name]
-  Suggested Principles: [P1], [P2], [P3], [P4]
-  Principle descriptions: [from triz-principles.md]
-```
-
-### Step 3: Functional Keywords for Search
-
-Produce 5-10 domain-independent keywords that capture the venture's core functions. These become the search queries for Stage 3.
-
-Format: `[verb] + [abstract object]`
-Examples: "filter population", "overcome adaptive barrier", "amplify weak signal", "distribute through network", "regulate bidirectional flow"
-
-When the methodology produces its artifact, ensure pipeline provenance is added to frontmatter:
-
-```yaml
-pipeline: analogy
-pipeline_stage: 2
-abstract_function: "[domain-independent function description]"
-triz_improving: "[parameter number and name]"
-triz_worsening: "[parameter number and name]"
-triz_principles: [list of suggested principle numbers]
-functional_keywords: [list of 5-10 search keywords]
-```
-
-## Output Contract
-
-The following sections from the artifact feed into Stage 3 (search):
-
-- **Abstract function description** -- becomes the primary search query for cross-domain analogy retrieval
-- **TRIZ parameter mapping** -- guides search toward domains that resolved the same contradiction type
-- **Functional keywords** -- become specific search terms for AskNature, patents, and academic databases
-
-Stage 3 will extract these by scanning `room/problem-definition/` for the most recent artifact with `pipeline: analogy` and `pipeline_stage: 2` in frontmatter.

package/pipelines/analogy/03-search.md

@@ -1,135 +0,0 @@
----
-stage: 3
-methodology: research
-chain: analogy
-input_from: abstract
-output_to: transfer
-room_section: competitive-analysis
----
-
-# Stage 3: Search (Dual-Mode Analogy Retrieval)
-
-## Input Extraction
-
-Extract from Stage 2 artifact (scan `room/problem-definition/` for most recent artifact with `pipeline: analogy` and `pipeline_stage: 2` in frontmatter):
-
-- **Abstract function description** -- the domain-independent encoding of the venture's core problem
-- **TRIZ parameter mapping** -- improving/worsening parameters and suggested inventive principles
-- **Functional keywords** -- 5-10 domain-independent search terms
-
-Present to the user: "Searching for analogies to: [abstract function]. Looking for systems that [functional description] across [internal/external/both] sources."
-
-## Stage Instructions
-
-This stage runs DUAL-MODE search: internal (room graph + Brain) and external (web research). The mode depends on user preference or pipeline configuration:
-
-- **Internal only** (`--brain`): KuzuDB + Brain queries, no web search
-- **External only** (`--external`): Tavily web research, no Brain queries
-- **Both** (default): All sources in parallel
-
-### Internal Search (Tier 0 / Tier 1 / Tier 2)
-
-#### Tier 0: LLM Reasoning (always available)
-
-Use the abstract function description and functional keywords to generate candidate analogies from training knowledge. For each candidate, provide:
-- Source domain
-- How the analogy maps structurally
-- Analogy distance classification (near / far / cross-domain)
-
-Generate 3-5 candidates from diverse domains (biology, engineering, military, sports, economics, ecology, etc.).
-
-#### Tier 1: KuzuDB Local Graph (if room/.lazygraph/ exists)
-
-Query existing HSI_CONNECTION edges for structural_transfer matches:
-
-```
-Scan HSI_CONNECTION edges where innovation_type = 'structural_transfer'
-Sort by hsi_score DESC
-Return top 5 with source/target artifacts and structural descriptions
-```
-
-Also query CONTRADICTS edges that share the same TRIZ parameter pattern as the venture's contradiction.
-
-#### Tier 2: Brain MCP (if connected)
-
-Read `references/brain/query-patterns.md` for `brain_cross_domain` and `brain_search_semantic` patterns.
-
-1. **brain_cross_domain**: Find bridging frameworks between the venture's domain and other domains
-2. **brain_search_semantic**: Vector search using the abstract function description as query text
-3. **brain_analogy_search**: Find frameworks from DIFFERENT domains that address the SAME problem type
-
-```cypher
-MATCH (f1:Framework)-[:ADDRESSES_PROBLEM_TYPE]->(pt:ProblemType)
-WHERE f1.category = $source_category
-WITH pt, collect(f1) AS source_frameworks
-MATCH (f2:Framework)-[:ADDRESSES_PROBLEM_TYPE]->(pt)
-WHERE NOT f2.category = $source_category
-AND NOT f2 IN source_frameworks
-OPTIONAL MATCH (f2)-[:CO_OCCURS]->(bridge:Framework)
-WHERE bridge IN source_frameworks
-RETURN f2.name, f2.category, f2.description, pt.name, bridge.name
-ORDER BY bridge IS NOT NULL DESC
-LIMIT 15
-```
-
-### External Search (via Tavily MCP)
-
-If external mode is active, dispatch parallel research queries:
-
-1. **Biomimicry search**: Search AskNature.org with functional keywords
-   - Query: "how does nature [abstract function keyword]?"
-   - Example: "how does nature filter population by fit criteria?"
-
-2. **Patent search**: Search Google Patents or Lens.org with TRIZ principles
-   - Query: "[TRIZ principle name] AND [functional keyword]"
-   - Example: "segmentation AND adaptive barrier delivery"
-
-3. **Academic search**: Search Google Scholar or Semantic Scholar
-   - Query: "[abstract function] cross-domain analogy"
-   - Example: "overcome adaptive barrier delivery system structural isomorphism"
-
-Each external result must include:
-- Source URL and title
-- Source domain classification
-- How it maps to the venture's abstract function
-- Analogy distance score (near/far/cross-domain)
-- Structural fitness estimate (0-1)
-
-### Ranking and Classification
-
-Combine all results (internal + external) and rank by:
-
-| Factor | Weight | Description |
-|--------|--------|-------------|
-| Structural fitness | 40% | How well the relational structure maps to the venture |
-| Analogy distance | 30% | Far/cross-domain analogies score higher (more novel) |
-| Evidence quality | 20% | Concrete examples beat abstract similarities |
-| Source reliability | 10% | Brain graph > academic > patent > web |
-
-Classify each analogy by distance:
-- **Near** (same industry): structural_fitness 0.30-0.45, low surprise
-- **Far** (adjacent domain): structural_fitness 0.45-0.65, medium surprise
-- **Cross-domain** (completely different field): structural_fitness > 0.65, high surprise
-
-When the methodology produces its artifact, ensure pipeline provenance is added to frontmatter:
-
-```yaml
-pipeline: analogy
-pipeline_stage: 3
-search_mode: "[internal|external|both]"
-analogies_found: [count]
-top_analogy: "[source domain]: [brief description]"
-analogy_distances: { near: N, far: N, cross_domain: N }
-discovery_methods: [list of methods that found results]
-```
-
-## Output Contract
-
-The following sections from the artifact feed into Stage 4 (transfer):
-
-- **Top 3-5 ranked analogies** -- each with source domain, structural mapping, distance classification
-- **Structural fitness scores** -- quantified mapping quality for each analogy
-- **Discovery provenance** -- how each analogy was found (LLM/KuzuDB/Brain/external)
-- **TRIZ principle alignment** -- which inventive principles each analogy embodies
-
-Stage 4 will extract these by scanning `room/competitive-analysis/` for the most recent artifact with `pipeline: analogy` and `pipeline_stage: 3` in frontmatter.

package/pipelines/analogy/04-transfer.md

@@ -1,101 +0,0 @@
----
-stage: 4
-methodology: structure-argument
-chain: analogy
-input_from: search
-output_to: validate
-room_section: solution-design
----
-
-# Stage 4: Transfer (Correspondence Table Generation)
-
-## Input Extraction
-
-Extract from Stage 3 artifact (scan `room/competitive-analysis/` for most recent artifact with `pipeline: analogy` and `pipeline_stage: 3` in frontmatter):
-
-- **Top 3-5 ranked analogies** -- source domain, structural mapping, distance classification
-- **Structural fitness scores** -- quantified mapping quality
-- **TRIZ principle alignment** -- inventive principles each analogy embodies
-
-Also re-read Stage 1 artifact (scan `room/problem-definition/` for `pipeline: analogy` and `pipeline_stage: 1`) for:
-- **SAPPhIRE triples** -- the original function-behavior-structure of the venture
-- **Core contradiction** -- what the transferred solution must resolve
-
-Present to the user: "I found [N] analogies. The strongest is from [source domain] with [structural fitness] structural fitness. Building correspondence tables for the top [3] candidates."
-
-## Stage Instructions
-
-Run `/mos:structure-argument` to build a Minto Pyramid for each transferred solution. The governing thought for each is: "The solution from [source domain] can be adapted to [venture domain] because [structural isomorphism]."
-
-### Step 1: Correspondence Table Construction
-
-For each of the top 3 analogies, build an explicit correspondence table:
-
-```markdown
-## Correspondence Table: [Source Domain] -> [Venture Domain]
-
-| Source Element | Source Function | Venture Equivalent | Transfer Feasibility |
-|---------------|----------------|-------------------|---------------------|
-| [element A1] | [what it does in source] | [proposed venture equivalent] | High/Medium/Low |
-| [element A2] | [what it does in source] | [proposed venture equivalent] | High/Medium/Low |
-| [element A3] | [what it does in source] | [proposed venture equivalent] | High/Medium/Low |
-
-**Structural Isomorphism:** [description of which relations are preserved]
-**What Transfers:** [specific solution principle that applies]
-**What Does NOT Transfer:** [domain-specific elements that break the mapping]
-**Transfer Distance:** [near/far/cross-domain]
-```
-
-### Step 2: Concrete Design Proposals
-
-For each correspondence table, generate a concrete design proposal:
-
-1. **The Adaptation**: How the source domain solution would work in the venture's context
-2. **Implementation Steps**: 3-5 specific actions to apply the transferred principle
-3. **Required Modifications**: What changes to the venture's current approach are needed
-4. **New Capabilities Needed**: What the venture would need to build or acquire
-5. **Expected Impact**: How this resolves the core contradiction identified in Stage 1
-
-### Step 3: Transfer Feasibility Scoring
-
-Rate each transfer on two axes:
-
-| Axis | Score Range | Measures |
-|------|-----------|----------|
-| **Structural fit** | 0.0-1.0 | How many relations from the source survive in the venture mapping |
-| **Implementation distance** | 0.0-1.0 | How far the venture needs to move from its current state (lower = easier) |
-
-**Combined score** = structural_fit * (1 - implementation_distance * 0.5)
-
-This penalizes high-distance implementations but not as heavily as low structural fit.
-
-### Step 4: KuzuDB Edge Creation
-
-If room/.lazygraph/ exists, the following edges should be created after Stage 4:
-
-- **ANALOGOUS_TO** edges between venture artifacts and source domain concepts
-  - Properties: analogy_distance, structural_fitness, source_domain, transfer_map (JSON), discovery_method, pipeline_stage: 4
-- **RESOLVES_VIA** edges linking existing CONTRADICTS edges to the proposed resolution
-  - Properties: resolution_type: "analogy", analogy_source, confidence, triz_principle
-
-When the methodology produces its artifact, ensure pipeline provenance is added to frontmatter:
-
-```yaml
-pipeline: analogy
-pipeline_stage: 4
-transfers_generated: [count]
-top_transfer: "[source domain] -> [venture domain]: [brief description]"
-combined_scores: [list of combined feasibility scores]
-edges_created: { analogous_to: N, resolves_via: N }
-```
-
-## Output Contract
-
-The following sections from the artifact feed into Stage 5 (validate):
-
-- **Correspondence tables** -- the explicit element-to-element mappings for each analogy
-- **Design proposals** -- concrete adaptations to stress-test
-- **Transfer feasibility scores** -- structural fit and implementation distance ratings
-- **What does NOT transfer** -- known mapping failures for Devil's Advocate to probe
-
-Stage 5 will extract these by scanning `room/solution-design/` for the most recent artifact with `pipeline: analogy` and `pipeline_stage: 4` in frontmatter.

package/pipelines/analogy/05-validate.md

@@ -1,106 +0,0 @@
----
-stage: 5
-methodology: challenge-assumptions
-chain: analogy
-input_from: transfer
-output_to: null
-room_section: competitive-analysis
----
-
-# Stage 5: Validate (Structural Mapping Stress-Test)
-
-## Input Extraction
-
-Extract from Stage 4 artifact (scan `room/solution-design/` for most recent artifact with `pipeline: analogy` and `pipeline_stage: 4` in frontmatter):
-
-- **Correspondence tables** -- element-to-element mappings for each analogy
-- **Design proposals** -- concrete adaptations to stress-test
-- **Transfer feasibility scores** -- structural fit and implementation distance
-- **What does NOT transfer** -- known mapping failures to probe
-
-Also re-read Stage 2 artifact (scan `room/problem-definition/` for `pipeline: analogy` and `pipeline_stage: 2`) for:
-- **TRIZ contradiction mapping** -- does the transfer introduce NEW contradictions?
-- **Abstract function description** -- does the transfer preserve the core function?
-
-Present to the user: "I have [N] transferred solutions. Now the Devil's Advocate will stress-test each structural mapping to find where they break."
-
-## Stage Instructions
-
-Run `/mos:challenge-assumptions` with the correspondence tables and design proposals as the claims under examination.
-
-### Challenge Framework
-
-For each transferred analogy, the Devil's Advocate must probe:
-
-#### 1. Structural Integrity Challenges
-
-- **Mapping completeness**: "You mapped [source element] to [venture element], but what about [unmapped source element]? The source system needs ALL of these to work -- can you function without it?"
-- **Relation preservation**: "In the source domain, [element A] directly causes [element B]. In your venture, that causal link doesn't exist. The analogy breaks here."
-- **Scale mismatch**: "This works in [source domain] because the system operates at [scale]. Your venture operates at [different scale]. Does the principle survive the scale change?"
-
-#### 2. New Contradiction Detection
-
-For each design proposal, check whether the transferred solution introduces NEW contradictions:
-- "By adopting [source approach], you improve [X] but now you worsen [Y]. This is a new TRIZ contradiction: Parameter [N] vs Parameter [M]."
-- If new contradictions found, look up TRIZ matrix for resolution principles
-- A transfer that resolves one contradiction but creates two new ones is a net negative
-
-#### 3. Domain Assumption Challenges
-
-- "The source domain assumes [condition]. Does that condition hold in your venture?"
-- "This solution evolved in [source ecosystem]. Your ecosystem has [different property]. Will it survive the transplant?"
-- "The analogy distance is [cross-domain]. At this distance, what domain-specific mechanisms are you implicitly importing?"
-
-#### 4. Implementation Feasibility Challenges
-
-- "The implementation distance is [score]. What are the 3 biggest obstacles to getting from here to there?"
-- "This requires [capability] that your team/venture currently lacks. How do you acquire it?"
-- "The source took [timeframe] to develop this. What makes you think you can transfer it in [venture timeframe]?"
-
-### Classification
-
-After stress-testing, classify each transferred analogy:
-
-| Status | Meaning | Action |
-|--------|---------|--------|
-| **SURVIVED** | Structural mapping held under interrogation, no critical failures | Recommend for implementation |
-| **WOUNDED** | Partial structural mapping, some relations broke but core principle transfers | Refine mapping, address broken relations |
-| **KILLED** | Fundamental structural mismatch discovered, analogy is superficial | Document why it failed for learning |
-
-### Survival Map
-
-Produce a survival map showing:
-```
-Analogy 1: [Source Domain] -> [Status]
-  Survived: [which structural mappings held]
-  Failed: [which mappings broke and why]
-  New contradictions: [any introduced by the transfer]
-  Refined proposal: [if WOUNDED, what changes would save it]
-
-Analogy 2: [Source Domain] -> [Status]
-  ...
-```
-
-When the methodology produces its artifact, ensure pipeline provenance is added to frontmatter:
-
-```yaml
-pipeline: analogy
-pipeline_stage: 5
-analogies_tested: [count]
-survived: [count]
-wounded: [count]
-killed: [count]
-new_contradictions_found: [count]
-recommended_transfer: "[best surviving analogy source domain]"
-```
-
-## Output Contract
-
-Final stage -- no downstream pipeline stage. The artifact serves as:
-
-- **Decision support** for which analogies to pursue in the venture
-- **Risk documentation** showing where structural mappings are weakest
-- **Learning record** for why certain cross-domain transfers fail (improves future searches)
-- **Input to /mos:act** for subsequent framework selection based on validated analogies
-
-If a transfer SURVIVED with high structural fitness (> 0.7), Larry should proactively suggest: "This analogy is strong enough to drive your next design iteration. Want me to run `/mos:act` to apply the transferred principle, or `/mos:build-thesis` to incorporate it into your investment argument?"

package/pipelines/analogy/CHAIN.md

@@ -1,56 +0,0 @@
----
-name: analogy
-display_name: Design-by-Analogy Pipeline
-description: From venture problem to cross-domain analogies -- decompose, abstract, search, transfer, validate
-stages: 5
-estimated_time: 90-180min
-venture_stages: [Discovery, Design, Investment]
-problem_types: [ill-defined-complex, well-defined-complex, well-defined-complicated]
----
-
-# Design-by-Analogy Pipeline
-
-## When to Use
-
-User has a venture problem, contradiction, or design challenge that could benefit from solutions discovered in other domains. The pipeline formalizes cross-domain analogy discovery -- finding structural isomorphisms between the venture's problem and solutions from biology, engineering, other industries, or academic research.
-
-Typical starting points:
-- "I'm stuck on a design problem and need fresh approaches"
-- "What can we learn from how other industries solved this?"
-- "We have a contradiction -- improving X worsens Y"
-- "Find me analogies from nature or other fields"
-
-## Stage Sequence
-
-1. **decompose** -- Extract SAPPhIRE function-behavior-structure triples from room artifacts
-2. **abstract** -- Strip domain language, map to TRIZ parameter space, produce functional keywords
-3. **search** -- Dual-mode retrieval: internal (KuzuDB + Brain) and external (Tavily for AskNature, patents, academic)
-4. **transfer** -- Build correspondence tables mapping source domain solutions to venture domain
-5. **validate** -- Stress-test structural mappings via Devil's Advocate challenge
-
-## What It Produces
-
-After all 5 stages, the Room will have:
-- **problem-definition:** SAPPhIRE decomposition with function-behavior-structure triples (Stage 1)
-- **problem-definition:** Domain-independent abstract encoding with TRIZ contradiction mapping (Stage 2)
-- **competitive-analysis:** Ranked cross-domain analogies with source domains and structural fitness scores (Stage 3)
-- **solution-design:** Correspondence tables with concrete design proposals transferred from analogous domains (Stage 4)
-- **competitive-analysis:** Validated analogy survival map with stress-test results and refined proposals (Stage 5)
-
-## Chain Provenance
-
-Each artifact includes `pipeline: analogy` and `pipeline_stage: N` in frontmatter, creating an inspectable provenance chain. This allows Larry to detect existing pipeline progress and offer resumption.
-
-## Relationship to Existing Infrastructure
-
-This pipeline FORMALIZES what HSI already discovers implicitly:
-- HSI `structural_transfer` = Stage 2 (ABSTRACT) + Stage 4 (TRANSFER)
-- HSI `semantic_implementation` = Stage 4 (TRANSFER) applied
-- KuzuDB `CONTRADICTS` edges = Stage 1 (DECOMPOSE) contradiction detection
-- Brain `brain_cross_domain` = Stage 3 (SEARCH) internal mode
-
-The pipeline adds: SAPPhIRE encoding, TRIZ parameter mapping, external research orchestration, explicit correspondence tables, and Devil's Advocate validation of structural mappings.
-
-## Quick Access
-
-For on-demand analogy discovery without the full pipeline, use `/mos:find-analogies` which runs a compressed version of Stages 1-3.