@mindrian_os/install 1.13.0-beta.11

package/references/personas/hat-perspectives.md

@@ -0,0 +1,76 @@
+# Hat Perspectives -- De Bono Six Thinking Hats Mapping
+
+> Authoritative hat-to-perspective mapping for persona generation.
+> Each hat defines a constrained perspective lens that examines room data from one angle.
+
+---
+
+## White Hat -- Facts & Data
+
+- **Color:** white
+- **Label:** Facts & Data
+- **Perspective Instruction:** What do we actually know? Strip opinion. Data only.
+- **Focus Areas:** Numbers, metrics, market data, financial figures, validated claims, evidence-backed statements, data gaps
+- **Complementary Hat:** Blue (process ensures data is complete)
+- **Tension Hat:** Red (gut feelings vs hard data)
+- **Question Style:** "What data supports this?" / "Where is the evidence?" / "What numbers are missing?"
+
+---
+
+## Red Hat -- Emotions & Intuition
+
+- **Color:** red
+- **Label:** Emotions & Intuition
+- **Perspective Instruction:** What does your gut say about this venture? No justification needed.
+- **Focus Areas:** Team passion, market excitement, user pain intensity, founder conviction, stakeholder reactions, emotional resonance
+- **Complementary Hat:** Yellow (optimism channels intuition)
+- **Tension Hat:** White (data vs feeling)
+- **Question Style:** "How does this feel?" / "What's your instinct here?" / "What excites or worries you most?"
+
+---
+
+## Black Hat -- Risks & Dangers
+
+- **Color:** black
+- **Label:** Risks & Dangers
+- **Perspective Instruction:** What kills this? What fails? What's the worst case?
+- **Focus Areas:** Competitive threats, financial risks, regulatory barriers, technical debt, team gaps, market timing risks, assumption fragility
+- **Complementary Hat:** White (facts ground risk assessment)
+- **Tension Hat:** Yellow (optimism vs caution)
+- **Question Style:** "What could go wrong?" / "What kills this?" / "What's the worst case scenario?"
+
+---
+
+## Yellow Hat -- Benefits & Opportunities
+
+- **Color:** yellow
+- **Label:** Benefits & Opportunities
+- **Perspective Instruction:** What's the upside? Why could this work brilliantly?
+- **Focus Areas:** Market opportunity, competitive advantages, team strengths, timing benefits, growth potential, strategic positioning
+- **Complementary Hat:** Green (creativity amplifies opportunity)
+- **Tension Hat:** Black (optimism vs risk)
+- **Question Style:** "Why could this work?" / "What's the biggest upside?" / "What advantages do you have?"
+
+---
+
+## Green Hat -- Creativity & Alternatives
+
+- **Color:** green
+- **Label:** Creativity & Alternatives
+- **Perspective Instruction:** What else? What's weird? What hasn't been tried?
+- **Focus Areas:** Alternative approaches, unconventional strategies, pivot possibilities, adjacent markets, creative partnerships, novel business models
+- **Complementary Hat:** Yellow (optimism enables creative leaps)
+- **Tension Hat:** Blue (structure vs freeform)
+- **Question Style:** "What if you tried...?" / "Has anyone done this differently?" / "What's the weirdest option?"
+
+---
+
+## Blue Hat -- Process & Meta
+
+- **Color:** blue
+- **Label:** Process & Meta
+- **Perspective Instruction:** Are we asking the right questions? What's missing from the analysis?
+- **Focus Areas:** Analysis completeness, missing sections, methodology gaps, decision framework, next steps, room structure health
+- **Complementary Hat:** White (data completeness supports process)
+- **Tension Hat:** Green (structure vs creativity)
+- **Question Style:** "Are we asking the right questions?" / "What's missing?" / "What should we analyze next?"

package/references/personas/persona-template.md

@@ -0,0 +1,63 @@
+# Persona Template
+
+> Schema for generated persona markdown files in `room/personas/`.
+
+## YAML Frontmatter Schema
+
+```yaml
+---
+hat: {color}                    # white | red | black | yellow | green | blue
+hat_label: {display name}      # "Facts & Data" | "Emotions & Intuition" | etc.
+domain: {extracted-domain}      # Slugified from room venture name / problem definition
+perspective: {1-line instruction} # What this hat focuses on
+generated_from:                 # List of section names used in generation
+  - problem-definition
+  - market-analysis
+generated_date: {ISO date}      # YYYY-MM-DD
+room_hash: {7-char hex}         # First 7 chars of MD5 hash of STATE.md content
+disclaimer: "This is a perspective lens generated from your room data. It is NOT professional advice. Validate all insights with qualified professionals."
+---
+```
+
+## Body Template
+
+```markdown
+# {Color} Hat -- {Label} Perspective
+
+## Who I Am
+
+{2-3 sentences describing what this hat does, written in first person from the hat's perspective. References the venture domain.}
+
+## What I See In Your Room
+
+### From {Section Name}
+{Brief signal extracted from that section's content, viewed through this hat's lens.}
+
+### From {Section Name}
+{Brief signal extracted from that section's content, viewed through this hat's lens.}
+
+## My Questions For You
+
+1. {Specific question grounded in room data, from this hat's perspective}
+2. {Specific question grounded in room data, from this hat's perspective}
+3. {Specific question grounded in room data, from this hat's perspective}
+
+## Where I Disagree With Other Hats
+
+- **vs {Tension Hat} ({Label}):** {Anticipated tension point based on room content}
+- **vs {Complementary Hat} ({Label}):** {Where alignment exists but emphasis differs}
+
+---
+*This is a perspective lens generated from your room data. It is NOT professional advice. Validate all insights with qualified professionals. Generated from room state on {date}.*
+```
+
+## Naming Convention
+
+Files are named: `{hat-color}-{domain}.md`
+
+Examples:
+- `white-health-tech-marketplace.md`
+- `black-health-tech-marketplace.md`
+- `green-health-tech-marketplace.md`
+
+Never use human names. Hat-color naming reinforces the "perspective lens" framing.

package/references/pipeline/act-output-contract.md

@@ -0,0 +1,88 @@
+# Autonomous Engine Output Contract
+
+*Loaded by `/mos:act` chain mode and `agents/framework-runner.md`*
+
+---
+
+## Purpose
+
+When `/mos:act --chain` runs multiple frameworks in sequence, each framework's output must be structured so the next framework can consume it as input. This contract defines that structure.
+
+## Output Format
+
+Every framework-runner invocation produces this structured output after filing artifacts:
+
+```yaml
+framework: {name}
+chain_position: {N} of {total}
+venture_stage: {stage from STATE.md}
+problem_type: {definition_level}/{complexity}
+
+key_findings:
+  - {finding 1}
+  - {finding 2}
+  - {finding 3}
+
+claims_filed:
+  - section: {room section}
+    file: {filename}
+    type: {insight|analysis|recommendation|assumption}
+
+open_questions:
+  - {question the next framework should address}
+  - {gap or tension surfaced}
+
+chain_forward:
+  focus: {what the next framework should concentrate on}
+  context: {1-2 sentence summary of what was learned}
+  constraints: {any boundaries or assumptions to carry forward}
+```
+
+## Chain Input Rules
+
+When a framework-runner receives chain input from a previous framework:
+
+1. **key_findings** become the starting context -- acknowledge them, do not re-derive
+2. **open_questions** become the framework's primary focus areas
+3. **chain_forward.focus** overrides the default methodology entry point
+4. **claims_filed** provide cross-references for the new framework's artifacts
+
+## Chain Selection Logic
+
+When `/mos:act --chain` selects 3-5 frameworks:
+
+1. First framework addresses the room's weakest section or most pressing gap
+2. Each subsequent framework builds on the previous -- never redundant
+3. The sequence follows natural methodology progression:
+   - Exploration (beautiful-question, explore-domains, map-unknowns)
+   - Analysis (root-cause, analyze-systems, find-bottlenecks)
+   - Synthesis (structure-argument, build-thesis, systems-thinking)
+   - Validation (challenge-assumptions, validate, think-hats)
+4. Brain graph `FEEDS_INTO` relationships guide the chain when available
+5. Local fallback uses the progression above as default ordering
+
+## Dry-Run Format
+
+When `/mos:act --dry-run` previews the execution plan:
+
+```
+[ACT] Execution Plan
+     Room: {room name}
+     Stage: {venture stage}
+     Problem: {definition}/{complexity}
+
+     Step 1: {framework-name}
+             Why: {1-line reasoning}
+             Target: room/{section}/
+             Est: {time estimate}
+
+     Step 2: {framework-name}
+             Why: {1-line reasoning from chain_forward}
+             Input: Step 1 findings
+             Target: room/{section}/
+             Est: {time estimate}
+
+     ...
+
+     Total: {N} frameworks, ~{total time} estimated
+```

package/references/pipeline/chains-index.md

@@ -0,0 +1,39 @@
+# Pipeline Chains Index
+
+*Loaded on demand by `/mos:pipeline`*
+
+---
+
+## Available Chains
+
+| Chain | Display Name | Stages | Est. Time | Venture Stages | Description |
+|-------|-------------|--------|-----------|----------------|-------------|
+| discovery | Discovery Pipeline | 3 | 45-90min | Pre-Opportunity, Discovery | From domain territory to customer needs -- explore intersections, examine from 6 perspectives, identify jobs-to-be-done |
+| thesis | Thesis Pipeline | 3 | 60-120min | Design, Investment | From structured argument to stress-tested investment thesis -- build pyramid, challenge assumptions, synthesize thesis |
+
+---
+
+## How Pipelines Work
+
+Each pipeline is a sequence of methodology commands where the output of one stage feeds structured input to the next. The user runs `/mos:pipeline {name}` and Larry orchestrates the flow:
+
+1. **Stage contracts** define what each methodology needs from the previous stage and what it produces for the next
+2. **Artifacts are filed to Room sections** with pipeline provenance metadata (`pipeline`, `pipeline_stage`, `pipeline_input`)
+3. **User controls progression** -- they can exit, resume, or skip stages at any time
+4. **Input extraction is transparent** -- Larry always shows what was carried forward before running the next methodology
+
+Pipelines do not modify how methodologies work. They wrap them with structured context. Every methodology remains independently invocable outside a pipeline.
+
+---
+
+## Adding New Chains
+
+New chains follow the same pattern:
+
+1. Create a directory in `pipelines/{chain-name}/`
+2. Add `CHAIN.md` with chain metadata (name, stages, venture_stages, problem_types)
+3. Add numbered stage contracts (`01-{methodology}.md`, `02-{methodology}.md`, etc.)
+4. Each stage contract defines: Input Extraction, Stage Instructions, Output Contract
+5. Add an entry to this index
+
+Stage contracts reference existing methodology commands -- no new commands needed. The chain is the innovation, not the individual stages.

package/references/pws-profile-generation.md

@@ -0,0 +1,79 @@
+# PWS Profile Generation System
+
+*Reference for Brain MCP integration (Phase 4) and persona-based methodologies.*
+
+---
+
+## Purpose
+
+Generates comprehensive profiles for PWS cohort members as the **last step** in the Problem Seeker workflow. Profiles highlight traits aligned with PWS methodology success: systems thinking, adaptability across problem types, collaborative innovation.
+
+## Profile Structure
+
+```
+[FULL NAME] | PWS Profile
+
+UNIQUE PWS IDENTITY: "[Domain Expertise] & [Entrepreneurial Role] [Action] [Innovation Area]"
+
+PERSONAL INFORMATION
+ACADEMIC BACKGROUND (interdisciplinary, technical + strategic)
+PROFESSIONAL EXPERIENCE (technical depth + entrepreneurial breadth)
+SKILLS & EXPERTISE (vision, analysis, implementation, collaboration)
+PROFESSIONAL ATTRIBUTES (leadership, work approach, collaboration, problem-solving)
+MOTIVATIONS (growth mindset, openness, networking, structured methodology)
+```
+
+## Key Elements for Success Profiles
+
+- **Unique PWS Identity**: intersection of technical expertise and innovation role
+- **Skills mix**: strategic vision + analytical + implementation + collaborative
+- **Attributes**: balance direction with collaboration, thoroughness with adaptability
+- **Motivations**: growth + meaningful contribution + networking + collaborative innovation
+
+## Data Room Integration
+
+Maps directly to room sections:
+- Person nodes → `team-execution` section
+- Skill clusters → cross-reference across `problem-definition`, `solution-design`, etc.
+- Problem type experience → `competitive-analysis` (undefined, ill-defined, wicked, well-defined)
+- Collaboration potential → shared skills analysis across team
+
+## Neo4j Queries for Profile Enhancement
+
+```cypher
+-- Skills identification
+MATCH (p:Person {id: $id})-[:HAS_SKILL]->(s:Skill)
+RETURN s.name, s.category, s.proficiency_level
+ORDER BY s.proficiency_level DESC
+
+-- Experience mapping
+MATCH (p:Person {id: $id})-[:WORKED_ON]->(proj:Project)-[:INVOLVED]->(d:Domain)
+RETURN d.name, count(proj) as project_count
+ORDER BY project_count DESC
+
+-- Collaboration potential
+MATCH (p1:Person {id: $id}), (p2:Person)
+WHERE p1 <> p2
+MATCH (p1)-[:HAS_SKILL]->(s:Skill)<-[:HAS_SKILL]-(p2)
+RETURN p2.name, count(s) as shared_skills
+ORDER BY shared_skills DESC LIMIT 10
+
+-- Skill clusters (successful participants)
+MATCH (p:Person)-[:HAS_SKILL]->(s:Skill)
+RETURN s.name, count(p) ORDER BY count(p) DESC LIMIT 10
+```
+
+## Methodology Connections
+
+| Methodology | Profile Use |
+|-------------|------------|
+| **Bono Six Hats** | Hat perspectives as persona facets — how this person thinks from each angle |
+| **Domain Explorer** | Sub-domains map to person's expertise intersections |
+| **JTBD** | User segments become persona archetypes, jobs become career/venture motivations |
+| **Diagnose** | Problem type classification maps to person's experience with each type |
+
+## Notion Integration
+
+Database properties: Full Name, Unique PWS Identity, ID, Location, Contact, LinkedIn, Cohort, Academic Background, Professional Experience, Skills (multi-select), Professional Attributes, Motivations, Profile Status (Draft/Review/Final)
+
+Link to: Application Review DB, Problem Statement DB, Team Formation DB

package/references/reasoning/reasoning-schema.md

@@ -0,0 +1,143 @@
+# Reasoning Frontmatter Schema
+
+Reference for Larry when generating REASONING.md frontmatter and for developers extending reasoning operations.
+
+## Purpose
+
+Every section's REASONING.md uses YAML frontmatter to capture structured metadata: what this section depends on, what it provides, confidence ratings, and verification criteria. This schema is the single source of truth for that structure.
+
+## Schema
+
+### Top-Level Fields
+
+| Field | Type | Description |
+|-------|------|-------------|
+| `section` | string | Room section name (e.g., `problem-definition`, `market-analysis`) |
+| `generated` | string | Date when reasoning was generated (YYYY-MM-DD format) |
+| `methodology_run` | string | Associated methodology run ID (e.g., `run-2026-03-25-001`). Empty if generated without a full run. |
+| `brain_enriched` | boolean | Whether Brain (Neo4j/Pinecone) was available during generation |
+| `room_hash` | string | MD5 hash (first 7 chars) of STATE.md at generation time. Used as staleness signal -- if current STATE.md hash differs, reasoning may be outdated. |
+
+### Dependency Graph Fields
+
+| Field | Type | Description |
+|-------|------|-------------|
+| `requires` | array of objects | Sections this reasoning depends on. Each object has `section` (string) and `provides` (string describing what it contributes). |
+| `provides` | array of strings | What this section contributes to the venture (e.g., "Problem type classification", "TAM estimate"). |
+| `affects` | array of strings | Section names impacted by changes in this section. |
+
+### Confidence Object
+
+| Field | Type | Description |
+|-------|------|-------------|
+| `confidence.high` | array of strings | Claims with strong evidence (8-10/10 certainty). Each string is a specific claim. |
+| `confidence.medium` | array of strings | Claims needing more evidence (5-7/10 certainty). |
+| `confidence.low` | array of strings | Speculative claims (1-4/10 certainty). |
+
+### Verification Object
+
+| Field | Type | Description |
+|-------|------|-------------|
+| `verification.must_be_true` | array of strings | Goal-backward criteria: what must be TRUE for this section to be considered complete. |
+| `verification.status` | string | One of: `pending`, `verified`, `failed`. |
+
+## Full Example
+
+```yaml
+---
+section: problem-definition
+generated: 2026-03-25
+methodology_run: run-2026-03-25-001
+requires:
+  - section: market-analysis
+    provides: "Customer validation data"
+  - section: competitive-analysis
+    provides: "Competitor pain point mapping"
+provides:
+  - "Problem type classification"
+  - "Wicked problem characteristics"
+  - "Primary user pain points"
+affects: ["solution-design", "competitive-analysis"]
+confidence:
+  high: ["Problem is wicked (8/10)", "TAM estimate 2-5B"]
+  medium: ["Regulatory headwinds in EU"]
+  low: ["China market timing"]
+verification:
+  must_be_true:
+    - "Problem definition cites at least 2 customer data points"
+    - "Wicked characteristics identified and scored"
+    - "Pain points validated by market-analysis artifacts"
+  status: pending
+brain_enriched: true
+room_hash: abc123f
+---
+```
+
+## Field Details
+
+### `requires` (Dependency Declaration)
+
+Each entry declares a dependency on another section's output:
+
+```yaml
+requires:
+  - section: market-analysis
+    provides: "Customer validation data"
+```
+
+Larry should populate this based on which other sections' artifacts were referenced when generating the reasoning. The `provides` field describes what specific data or insight flows from that section.
+
+### `confidence` (MECE Claim Rating)
+
+Every claim in the reasoning body should be reflected in the confidence frontmatter. Claims must be:
+- **Specific** -- not "market looks good" but "TAM estimate 2-5B based on Gartner 2025"
+- **Traceable** -- reference the artifact or data point supporting the claim
+- **MECE** -- collectively exhaustive (all key claims rated), mutually exclusive (no claim in two levels)
+
+### `verification.must_be_true` (Goal-Backward Criteria)
+
+These are the acceptance criteria for the section, written from the outcome backward:
+- What evidence must exist?
+- What analysis must be complete?
+- What dependencies must be satisfied?
+
+Larry generates these during reasoning. They serve as a checklist for section completeness.
+
+### `room_hash` (Staleness Signal)
+
+The first 7 characters of the MD5 hash of STATE.md at generation time. When reasoning operations detect a different hash, the reasoning may be stale -- the room has changed since this reasoning was generated.
+
+## LazyGraph Edge Types
+
+The `requires` and `affects` fields feed LazyGraph edges:
+
+| Frontmatter Field | LazyGraph Edge | Direction |
+|-------------------|---------------|-----------|
+| `requires[].section` | `REASONING_INFORMS` | dependency -> this section |
+| `affects[]` | `REASONING_INFORMS` | this section -> affected section |
+
+These edges enable Larry to traverse reasoning dependencies: "If problem-definition reasoning changes, what other sections' reasoning might be invalidated?"
+
+## Programmatic Access
+
+```javascript
+const { getReasoningFrontmatter, setReasoningFrontmatter, mergeReasoningFrontmatter } = require('./lib/core/reasoning-ops.cjs');
+
+// Read full frontmatter
+const fm = getReasoningFrontmatter(roomDir, 'problem-definition');
+
+// Read specific field
+const conf = getReasoningFrontmatter(roomDir, 'problem-definition', 'confidence');
+
+// Set a field
+setReasoningFrontmatter(roomDir, 'problem-definition', 'brain_enriched', true);
+
+// Merge multiple fields
+mergeReasoningFrontmatter(roomDir, 'problem-definition', {
+  brain_enriched: true,
+  room_hash: 'abc123f',
+});
+```
+
+---
+*MindrianOS Reasoning Engine -- frontmatter schema reference v1.0*

package/references/reasoning/reasoning-template.md

@@ -0,0 +1,68 @@
+---
+section: {section}
+generated: {date}
+methodology_run: {run_id}
+requires:
+  - section: {dependency_section}
+    provides: "{what it provides}"
+provides:
+  - "{what this section provides}"
+affects: ["{affected_section_1}", "{affected_section_2}"]
+confidence:
+  high: []
+  medium: []
+  low: []
+verification:
+  must_be_true:
+    - "{verification criterion 1}"
+    - "{verification criterion 2}"
+  status: pending
+brain_enriched: false
+room_hash: {hash}
+---
+
+# {Section Label} -- Reasoning
+
+## Why This Section Matters
+
+{Larry fills: strategic importance of this section in the venture context}
+
+## Key Claims & Assumptions
+
+### High Confidence
+{Larry fills: claims with strong evidence}
+
+### Medium Confidence
+{Larry fills: claims needing more evidence}
+
+### Low Confidence
+{Larry fills: speculative claims}
+
+## Minto Structure
+
+### Situation
+{Larry fills: current state of affairs}
+
+### Complication
+{Larry fills: what changed or challenges the situation}
+
+### Question
+{Larry fills: the key question this section answers}
+
+### Answer
+{Larry fills: the section's core argument}
+
+## Cross-Section Logic
+
+{Larry fills: how this section connects to others}
+
+## What Larry Would Challenge
+
+{Larry fills: devil's advocate perspective}
+
+## Verification Criteria
+
+{Larry fills: what must be TRUE for this section to be complete}
+
+---
+*Generated by MindrianOS Reasoning Engine. This is structured critical thinking, not professional advice.*

package/references/reasoning/run-template.md

@@ -0,0 +1,38 @@
+---
+run_id: {run_id}
+section: {section}
+started: {started}
+completed: {completed}
+steps:
+  - diagnose
+  - select-framework
+  - apply
+  - file
+  - cross-reference
+  - update-graph
+brain_enriched: false
+room_hash: {hash}
+---
+
+# Methodology Run: {Section Label}
+
+## Step 1: Diagnose
+> {Larry fills: problem type classification and venture stage assessment}
+
+## Step 2: Select Framework
+> {Larry fills: selected methodology and rationale}
+
+## Step 3: Apply
+> {Larry fills: key claims and insights extracted}
+
+## Step 4: File
+> {Larry fills: where REASONING.md was filed}
+
+## Step 5: Cross-Reference
+> {Larry fills: cross-references discovered between sections}
+
+## Step 6: Update Graph
+> {Larry fills: graph edges created or updated}
+
+---
+*Generated by MindrianOS Reasoning Engine. Methodology run artifact.*