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

package/references/personas/hat-perspectives.md

@@ -1,76 +0,0 @@
-# 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

@@ -1,63 +0,0 @@
-# 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

@@ -1,88 +0,0 @@
-# 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

@@ -1,39 +0,0 @@
-# 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

@@ -1,79 +0,0 @@
-# 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

@@ -1,143 +0,0 @@
-# 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

@@ -1,68 +0,0 @@
----
-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

@@ -1,38 +0,0 @@
----
-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.*