ventureos 1.0.0

package/workflows/3-find-pain/customer-pain-discovery/step-4-pain-atomization.md

@@ -0,0 +1,138 @@
+# Step 4: Pain Atomization and FIP Scoring
+<!-- Phase 3, Step 4 — Weeks 4-5 -->
+<!-- Agent: Customer Discovery Specialist -->
+
+## Objective
+Decompose the validated broad pain into atomic, testable units. Score each unit on the FIP framework (Frequency / Intensity / Prevalence). Identify the sharpest, most actionable pain needle to anchor the venture solution.
+
+---
+
+## 4.1 Load FIP Framework and Context
+
+Load:
+- `{project-root}/ventureOS/data/scoring/pain-scoring.yaml` — FIP scoring framework
+- `interview-synthesis.md` — all interview learnings
+- `pain-hypothesis.md` — current pain hypothesis
+
+Confirm the broad pain(s) to atomize:
+- Primary pain from synthesis (highest frequency/intensity signal)
+- Any secondary pains worth atomizing
+
+---
+
+## 4.2 Atomization Exercise
+
+For the primary broad pain, decompose into atomic units:
+
+**Instructions:**
+1. Start with the broad pain statement (e.g., "ESG data is hard to incorporate into decisions")
+2. Ask: "What specifically makes this hard? In what specific situations? For which specific role?"
+3. Break down into 4-7 atomic pain units — each independently describable, testable, and scoreable
+4. A good atomic pain:
+   - Has a specific trigger ("when submitting the quarterly board report...")
+   - Has a specific consequence ("...takes 3 days of manual data collection")
+   - Can be scored independently on FIP
+
+**Example atomization:**
+- Broad pain: "ESG data is hard to incorporate into decisions"
+- Atomic unit 1: "Finding ESG data across 15 different systems before board meetings"
+- Atomic unit 2: "No way to compare ESG performance of projects side by side"
+- Atomic unit 3: "Can't trace ESG claims back to source data for auditors"
+
+---
+
+## 4.3 FIP Scoring for Each Atomic Unit
+
+Using the FIP framework (from pain-scoring.yaml), score each atomic unit:
+
+**Frequency (1-5):** How often does the customer experience this specific pain?
+- 5 = Daily or multiple times per day
+- 4 = Weekly
+- 3 = Monthly
+- 2 = Quarterly or less
+- 1 = Rarely
+
+**Intensity (1-5):** How severe is the pain when experienced?
+- 5 = Stops work, major cost or frustration
+- 4 = Significant workaround required, time/money lost
+- 3 = Annoying, some workaround exists
+- 2 = Minor inconvenience
+- 1 = Barely noticed
+
+**Prevalence (1-5):** What % of the target market experiences this?
+- 5 = >75%
+- 4 = 50-75%
+- 3 = 25-50%
+- 2 = 10-25%
+- 1 = <10%
+
+**FIP Average = (F + I + P) / 3**
+- ≥4.0 = Strong — sufficient to anchor a venture
+- 3.0-3.99 = Moderate — warrants further investigation
+- <3.0 = Weak — unlikely to support a business alone
+
+**Evidence sources for scoring:**
+- Frequency: direct interview data ("how often does this happen?")
+- Intensity: direct interview data ("how painful is this on a 1-10 scale?") + consequence data
+- Prevalence: desk research (industry reports, analyst data, LinkedIn company filters)
+
+---
+
+## 4.4 Pain Ranking and Desk Research
+
+1. Rank all atomic units by FIP average
+2. For the top 2-3: do desk research on PREVALENCE
+   - Search for data on how many companies / people in the market face this specific situation
+   - Look for: industry reports, job posting data, G2/review site patterns, regulatory filings
+   - Update prevalence score based on desk research findings
+3. Confirm market size signal: if FIP is strong, cross-reference with TAM data — how big is the market of people with this specific pain?
+
+---
+
+## 4.5 Select the Primary Pain to Solve
+
+Choose the winning atomic pain unit based on:
+- Highest FIP average AND
+- Alignment with our ability to build a solution AND
+- Clearest differentiation opportunity AND
+- Best fit with mothership assets
+
+Document the rationale. This is the pain that anchors Phase 4 (Define Solution).
+
+---
+
+## 4.6 Produce Pain Atomization Matrix
+
+Using the `pain-atomization.md` template, fill in the full matrix:
+- All atomic pain units with FIP scores
+- Representative quotes for each
+- Interview count per pain unit
+- FIP ranking summary
+- Prioritized pain to solve with rationale
+
+Save: `{output_folder}/{venture_name}/pain-atomization.md`
+Update `pain-hypothesis.md` with refined primary pain.
+Update `venture-state.yaml`: hypotheses.problem, completed_artifacts.
+
+---
+
+## 4.7 Checkpoint
+
+**GUIDED MODE:**
+Present pain atomization matrix. Ask:
+- "Does this FIP ranking align with your intuition from the interviews?"
+- "Is there any pain unit we missed?"
+- "Are you confident in the primary pain selection?"
+
+**YOLO MODE:**
+Proceed to Step 5.
+
+---
+
+## Step 4 Outputs
+
+| Output | File |
+|--------|------|
+| Pain atomization matrix | `pain-atomization.md` |
+| Updated pain hypothesis | `pain-hypothesis.md` |
+| Desk research notes | `interviews/desk-research-prevalence.md` |

package/workflows/3-find-pain/customer-pain-discovery/step-5-pain-journey-map.md

@@ -0,0 +1,150 @@
+# Step 5: Pain Journey Map and ICP Definition
+<!-- Phase 3, Step 5 — Weeks 5-7 -->
+<!-- Agent: Customer Discovery Specialist -->
+
+## Objective
+Map the customer's end-to-end pain journey for the primary pain. Define the Ideal Customer Profile (ICP) from accumulated evidence. Map buyer vs. user. Identify the best solution entry points. Complete Phase 3 and prepare handoff to Phase 4.
+
+---
+
+## 5.1 Load All Phase 3 Context
+
+Load:
+- `pain-atomization.md` — primary pain and FIP scores
+- `interview-synthesis.md` — all interview learnings and archetypes
+- `stakeholder-map.md` — buyer/user mapping
+
+Confirm the primary pain to map (winning atomic pain from Step 4).
+
+---
+
+## 5.2 Pain Journey Mapping
+
+Using the `pain-journey-map.md` template, map the customer's pain journey for the primary pain:
+
+**Journey stages to map:**
+1. **Trigger:** What specific event or situation causes the pain to surface?
+2. **Awareness:** The customer realizes there's a problem — what do they see/feel?
+3. **Struggle:** They try to deal with it — what do they do? What goes wrong?
+4. **Workaround:** They settle on a workaround — what is it? How good is it?
+5. **Outcome:** The pain episode ends — how satisfied are they? What residue remains?
+
+**For each stage capture:**
+- Customer action (what they do)
+- Customer thought (what they think/say)
+- Emotional state (frustrated / resigned / anxious / overwhelmed)
+- Pain touchpoints (specific moments of friction)
+- Tools / systems involved
+- Workaround used at this stage
+
+**Map the emotional arc:**
+Draw the emotional curve — where does it dip lowest? That's the intervention point.
+
+---
+
+## 5.3 Buyer vs. User Mapping
+
+From the journey map, clarify the buyer/user relationship:
+1. **Who is the user?** Who experiences this journey daily?
+2. **Who is the buyer?** Who approves the budget for a solution?
+3. **Are they the same?** If not: map both journeys and their priorities
+4. **Decision-making process:** How does the buyer learn about solutions? What triggers a buying decision?
+5. **Implication for sales motion:** Should we sell top-down (to buyers) or bottom-up (to users)?
+
+---
+
+## 5.4 Solution Entry Point Identification
+
+Based on the pain journey:
+1. Where in the journey does the pain reach maximum intensity? (highest intervention value)
+2. Where is the customer most motivated to try something new?
+3. Where does a solution create the biggest before/after contrast?
+4. Which entry point is most tractable as a first wedge product?
+
+List 2-3 candidate solution entry points ranked by: pain intensity × feasibility × wedge potential.
+
+---
+
+## 5.5 Define the Ideal Customer Profile (ICP)
+
+Using all Phase 3 evidence, define the ICP using the `icp-profile.md` template:
+
+**From interview synthesis:**
+- Which participant profiles showed the strongest pain?
+- Which roles, company types, company sizes, geographies?
+
+**ICP dimensions to define:**
+- Demographics/firmographics: role, industry, company size, geography, company stage
+- Psychographics: what they're measured on, what they fear, how they make decisions
+- Pain profile: primary pain, FIP score, workaround, switching motivation
+- Buying behavior: how they discover solutions, buying process, typical budget
+
+**Buyer vs. User ICP:**
+If buyer ≠ user, define both with separate profiles.
+
+**ICP exclusion criteria:**
+Who explicitly does NOT fit? (Helps focus GTM.)
+
+---
+
+## 5.6 Produce Phase 3 Outputs
+
+Save all final documents:
+
+**Pain Journey Map:**
+Save: `{output_folder}/{venture_name}/pain-journey-map.md`
+
+**ICP Profile:**
+Save: `{output_folder}/{venture_name}/icp-profile.md`
+
+**Update venture-state.yaml:**
+- `hypotheses.customer` → update with final ICP definition
+- `hypotheses.problem` → update with final primary pain statement
+- `guiding_questions.pain` → mark all answered (with evidence file references)
+- `completed_artifacts` → add pain-journey-map, icp-profile
+- `category_progress.venture` → update to reflect Phase 3 completion
+
+---
+
+## 5.7 Phase 3 Completion Gate
+
+Before declaring Phase 3 complete, verify all guiding questions:
+
+| Guiding Question | Answered? | Evidence File |
+|-----------------|-----------|--------------|
+| What do people need? | Yes/No | |
+| Can the team prioritize the most important pain? | Yes/No | pain-atomization.md |
+| Is the pain frequent, intense, prevalent enough? | Yes/No | pain-atomization.md (FIP ≥ 3.0) |
+| Has the team validated the pain exists? (10+ interviews) | Yes/No | interview-synthesis.md |
+| Can they identify their ideal customer? | Yes/No | icp-profile.md |
+| Does the team understand who the buyer is? | Yes/No | icp-profile.md |
+
+If any question is NOT answered: identify what additional interviews or research is needed.
+
+---
+
+## 5.8 Handoff to Phase 4
+
+When Phase 3 is complete, brief the Venture Master and Product Strategist:
+1. Primary pain validated: [pain statement] | FIP: ___
+2. ICP: [brief description]
+3. Buyer: [role] | User: [role] — same/different
+4. Solution entry point recommendation: [entry point description]
+5. What must the solution do to address the validated pain?
+
+**Phase 4 can begin when:**
+- Primary pain FIP ≥ 3.0 (weak signal — need more interviews)
+- ICP is defined
+- At least 10 interviews completed
+- Pain journey map shows at least one viable solution entry point
+
+---
+
+## Step 5 Outputs
+
+| Output | File |
+|--------|------|
+| Pain journey map | `pain-journey-map.md` |
+| ICP profile | `icp-profile.md` |
+| Phase 3 completion gate | _(in venture-state.yaml guiding_questions)_ |
+| Phase 4 brief | `phase-4-brief.md` |

package/workflows/3-find-pain/customer-pain-discovery/workflow.md

@@ -0,0 +1,82 @@
+# Customer Pain Discovery Workflow
+<!-- Phase 3: Find Customer Pain — Weeks 2-7 -->
+<!-- Agent: Customer Discovery Specialist -->
+<!-- Step-file architecture: 5 sequential steps with checkpoints -->
+
+## Overview
+
+This is the most critical phase of incubation. The goal is to validate that a real, significant, and prevalent customer pain exists that can support a business. This workflow runs across Weeks 2-7, overlapping with Phase 2 (domain) and Phase 4 (solution).
+
+**Three discovery modes** — select at the start:
+- **[T] Toolkit:** Agent creates scripts. User runs real interviews. Agent synthesizes notes.
+- **[S] Simulation:** AI generates synthetic customer/expert personas and simulates interviews. Clearly labeled SIMULATED.
+- **[I] Integration:** Import data from Listen Labs, Maze, UserTesting, or any structured export.
+
+Modes can be combined (e.g., run real interviews AND run synthetic simulations to fill gaps).
+
+**Execution mode:**
+- **Guided:** Pause and review at every template-output checkpoint
+- **Yolo:** Run all 5 steps autonomously, present all outputs at the end
+
+---
+
+## Pre-flight Check
+
+Before starting, the agent should:
+1. Load `{project-root}/ventureOS/config.yaml`
+2. Load `{project-root}/ventureOS/_memory/venture-sidecar/venture-state.yaml`
+3. Load `pain-hypothesis.md` if it exists (from Phase 2)
+4. Load `stakeholder-map.md` if it exists (from Phase 2)
+5. Load `{project-root}/ventureOS/data/scoring/pain-scoring.yaml` (FIP framework)
+6. Confirm: discovery mode (T/S/I) and execution mode (Guided/Yolo)
+
+---
+
+## Step 1: Pain Hypothesis and Interview Preparation
+**File:** `{project-root}/ventureOS/workflows/3-find-pain/customer-pain-discovery/step-1-pain-hypothesis.md`
+
+---
+
+## Step 2: Interviews (Real, Synthetic, or Imported)
+**File:** `{project-root}/ventureOS/workflows/3-find-pain/customer-pain-discovery/step-2-interviews.md`
+
+---
+
+## Step 3: Synthesis (Run after each interview batch)
+**File:** `{project-root}/ventureOS/workflows/3-find-pain/customer-pain-discovery/step-3-synthesis.md`
+
+---
+
+## Step 4: Pain Atomization and Scoring
+**File:** `{project-root}/ventureOS/workflows/3-find-pain/customer-pain-discovery/step-4-pain-atomization.md`
+
+---
+
+## Step 5: Pain Journey Map and ICP
+**File:** `{project-root}/ventureOS/workflows/3-find-pain/customer-pain-discovery/step-5-pain-journey-map.md`
+
+---
+
+## Completion Criteria
+
+Phase 3 is complete when ALL of the following guiding questions are answered with evidence:
+- [ ] What do people need? (primary pain identified)
+- [ ] Can the team prioritize the most important pain to solve?
+- [ ] Is the pain frequent, intense, and/or prevalent enough to support a business? (FIP ≥ 3.0 average)
+- [ ] Has the team validated the pain exists? (minimum 10 interviews recommended)
+- [ ] Can they identify their ideal customer? (ICP defined)
+- [ ] Does the team understand who the buyer is? (buyer vs. user mapped)
+
+---
+
+## Key Outputs
+
+| Artifact | File | Status |
+|---------|------|--------|
+| Interview scripts | `interviews/scripts/` | |
+| Interview notes | `interviews/notes/` | |
+| Interview synthesis | `interview-synthesis.md` | |
+| Pain atomization matrix | `pain-atomization.md` | |
+| Pain scores (FIP) | _(in pain-atomization.md)_ | |
+| Customer pain journey map | `pain-journey-map.md` | |
+| ICP profile | `icp-profile.md` | |

package/workflows/4-define-solution/feasibility-assessment/instructions.xml

@@ -0,0 +1,81 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<workflow-instructions name="feasibility-assessment">
+
+  <overview>
+    Assess whether the wedge solution can be built. Evaluate all four routes: Build (internal development), Buy (acquire technology), Partner (use a third party), Invest (stake in an existing company). Map the technology ecosystem. Recommend the optimal implementation approach.
+  </overview>
+
+  <step n="1" name="solution-requirements">
+    <title>Define Technical Requirements</title>
+    <agent>product-strategist</agent>
+    <instructions>
+      Load wedge-definition.md and value-proposition.md.
+      Define the technical requirements for the wedge:
+      1. Core capabilities required (what must the system do?)
+      2. Data requirements (what data is needed? where does it come from?)
+      3. Integration requirements (what systems must it connect to?)
+      4. AI/ML requirements (if applicable)
+      5. Security and compliance requirements
+      6. Scalability requirements
+      Document in solution-feasibility.md Step 1 section.
+    </instructions>
+  </step>
+
+  <step n="2" name="build-buy-partner">
+    <title>Build / Buy / Partner / Invest Analysis</title>
+    <agent>product-strategist</agent>
+    <instructions>
+      For each route, assess feasibility using the solution-feasibility.md template:
+
+      BUILD: Can we build the core capability in-house? What tech stack? What team? Timeline?
+      BUY: Are there existing products or APIs that provide this capability? (Web search for options)
+      PARTNER: Are there companies with this capability we could white-label, resell, or integrate with?
+      INVEST: Are there early-stage companies with this capability worth investing in?
+
+      Use web search to find candidate technologies, APIs, and partners for BUY/PARTNER routes.
+      Score each option 1-5 on feasibility.
+      Recommend a route (or hybrid approach).
+    </instructions>
+    <template-output file="{output_folder}/{venture_name}/solution-feasibility.md">
+      Save feasibility analysis with all four routes evaluated.
+    </template-output>
+  </step>
+
+  <step n="3" name="ecosystem-map">
+    <title>Ecosystem Mapping</title>
+    <agent>product-strategist</agent>
+    <instructions>
+      Map the technology ecosystem the solution operates within using the ecosystem-map.md template:
+      1. Key suppliers and enablers (what does our solution depend on?)
+      2. Competitors and substitutes (using web research — already done in Phase 2 but refresh for solution context)
+      3. Complementors (who enhances our solution or vice versa)
+      4. Platform dependencies (APIs, data platforms, cloud providers)
+      5. Integration landscape (what systems our ICP already uses that we must integrate with)
+      6. Partnership candidates — who would make a valuable partnership?
+
+      Use web search to identify technology players, platforms, and ecosystem participants.
+    </instructions>
+    <template-output file="{output_folder}/{venture_name}/ecosystem-map.md">
+      Save ecosystem map with partnership candidates.
+    </template-output>
+  </step>
+
+  <step n="4" name="feasibility-verdict">
+    <title>Feasibility Verdict and Build Plan</title>
+    <agent>product-strategist</agent>
+    <instructions>
+      Produce the feasibility verdict:
+      1. Overall feasibility: Feasible / Feasible with caveats / Not feasible
+      2. Recommended implementation approach (build/buy/partner/invest or hybrid)
+      3. Biggest technical risk and mitigation
+      4. Prototype-to-wedge build plan (phases and timelines)
+      5. Mothership technology assets that can accelerate development
+
+      Update venture-state.yaml: completed_artifacts, guiding_questions.solution (technical feasibility question)
+    </instructions>
+    <state-update file="{project-root}/ventureOS/_memory/venture-sidecar/venture-state.yaml">
+      Update: completed_artifacts (solution-feasibility, ecosystem-map), guiding_questions.solution
+    </state-update>
+  </step>
+
+</workflow-instructions>

package/workflows/4-define-solution/feasibility-assessment/workflow.yaml

@@ -0,0 +1,29 @@
+# VB Workflow: Feasibility Assessment (Phase 4)
+name: feasibility-assessment
+description: "Technical feasibility analysis for the wedge solution. Evaluates build/buy/partner/invest options. Maps the technology ecosystem and identifies the recommended implementation approach."
+author: "VB"
+
+config_source: "{project-root}/ventureOS/config.yaml"
+output_folder: "{config_source}:output_folder"
+venture_name: "{config_source}:venture_name"
+user_name: "{config_source}:user_name"
+communication_language: "{config_source}:communication_language"
+date: system-generated
+
+installed_path: "{project-root}/ventureOS/workflows/4-define-solution/feasibility-assessment"
+instructions: "{installed_path}/instructions.xml"
+
+templates:
+  - "{project-root}/ventureOS/data/templates/solution-feasibility.md"
+  - "{project-root}/ventureOS/data/templates/ecosystem-map.md"
+
+tags:
+  - feasibility
+  - technical-assessment
+  - ecosystem-map
+  - phase-4
+
+execution_hints:
+  interactive: true
+  autonomous: true
+  web_search_required: true

package/workflows/4-define-solution/wedge-design/step-1-wedge-hypothesis.md

@@ -0,0 +1,66 @@
+# Step 1: Wedge Hypothesis Generation
+<!-- Phase 4, Step 1 — Week 4 -->
+<!-- Agent: Product Strategist -->
+
+## Objective
+Generate 3-5 wedge entry point options, evaluate them, and select the most promising wedge to develop. Define the wedge clearly: smallest sellable product, target customer, and scaling hypothesis.
+
+---
+
+## 1.1 Run Wedge Storming Exercise
+
+Using the "wedge-storm" brainstorming technique from `brainstorming-techniques.csv`:
+
+1. Load `pain-atomization.md` (primary pain) and `pain-journey-map.md` (solution entry points)
+2. Generate 5-10 wedge ideas — each answering: "What is the smallest part of the solution we could build and sell first?"
+3. For each wedge idea:
+   - Name / short description
+   - What specific pain does it solve?
+   - Who specifically uses it?
+   - How is it delivered / what does it consist of?
+   - What is the MINIMUM to make it useful?
+   - What does success look like for the customer in month 1?
+
+---
+
+## 1.2 Evaluate Wedge Options
+
+Score each wedge option on:
+
+| Criterion | Why it matters |
+|-----------|---------------|
+| Pain specificity | Does it solve the highest FIP pain? |
+| Time to build | Can we prototype in 2-4 weeks? |
+| Differentiation | Is it clearly different from what exists? |
+| Customer desirability | Would the ICP actually use this? |
+| Mothership leverage | Can we use mothership assets to accelerate? |
+| Scalability | Does this wedge grow toward the big vision? |
+
+Score 1-5 per criterion. Select the highest-scoring option.
+
+---
+
+## 1.3 Define the Selected Wedge
+
+Using the `wedge-definition.md` template, define the winning wedge:
+- What it is (1-2 sentences)
+- Who it's for (specific ICP segment — as narrow as possible)
+- What specific atomic pain it addresses
+- What the core mechanism is (how it works)
+- What primary value it creates (specific: saves X hours, reduces Y cost)
+- How it's differentiated from alternatives
+- The wedge-to-vision scaling hypothesis
+
+---
+
+## 1.4 Checkpoint
+
+**GUIDED MODE:** Present wedge options and selected wedge to user. Ask: "Does this feel like the right starting point? Is the wedge small enough and differentiated enough?"
+
+**YOLO MODE:** Proceed to Step 2.
+
+---
+
+## Step 1 Outputs
+- `wedge-definition.md` (initial version — to be refined in Step 4)
+- Updated `venture-state.yaml`: hypotheses.wedge, hypotheses.solution

package/workflows/4-define-solution/wedge-design/step-2-value-propositions.md

@@ -0,0 +1,81 @@
+# Step 2: Value Propositions and Concept Cards
+<!-- Phase 4, Step 2 — Weeks 4-5 -->
+<!-- Agent: Product Strategist + Customer Discovery -->
+
+## Objective
+Develop and test value propositions for the wedge. Create concept cards for customer testing. Run value prop testing (real interviews or synthetic). Select the winning value proposition.
+
+---
+
+## 2.1 Value Proposition Sprint
+
+Using the "value-prop-sprint" brainstorming technique from `brainstorming-techniques.csv`:
+
+1. Load `wedge-definition.md` and `icp-profile.md`
+2. Generate 5+ value proposition statements using the format:
+   > "For [ICP], who [pain], [venture name] is a [category] that [benefit]. Unlike [alternative], we [differentiator]."
+3. For each VP: identify the core benefit, the key differentiator, and the customer emotion it targets
+
+Fill in the `value-proposition.md` template with all candidate VPs.
+
+---
+
+## 2.2 Create Concept Cards
+
+Using the `concept-card.md` template, create 3-5 concept cards representing different solution directions (or value proposition framings):
+
+For each concept card:
+- Problem statement (in customer language)
+- Solution concept (plain language, no jargon)
+- How it works (3-4 steps)
+- Key benefit (one bold statement)
+- Unlike alternatives section
+- Visual description for interview use
+
+Save cards to `{output_folder}/{venture_name}/concept-cards/card-{N}.md`
+
+---
+
+## 2.3 Test Value Propositions
+
+**Option A: Real Concept Card Interviews**
+Using the interview script from Phase 3 (concept card section):
+1. Run 5-10 concept card interviews with ICP
+2. Show each concept card and probe: resonance, differentiation, willingness to use/pay
+3. Capture scores and quotes per card
+
+**Option B: Synthetic Value Prop Testing**
+Using the "synthetic-value-prop-testing" tool from `synthetic-tools.csv`:
+1. Generate ICP personas from interview data
+2. Run each persona through all 5 concept cards
+3. Capture simulated reactions, resonance scores, objections
+4. Label ALL output: "⚠️ SIMULATED — Not real customer data"
+
+---
+
+## 2.4 Synthesize Testing Results
+
+Compile concept card / VP testing results:
+- Resonance score per concept card (1-5)
+- % who would use each
+- Top objections per card
+- Key quotes from testing
+- Winner: which concept card / VP had the strongest resonance?
+
+Update `value-proposition.md` with testing results.
+Update `wedge-definition.md` with the validated value proposition.
+
+---
+
+## 2.5 Checkpoint
+
+**GUIDED MODE:** Present value prop testing results. Ask: "Does the winning value prop feel right? Should we refine before moving to prototype?"
+
+**YOLO MODE:** Proceed to Step 3.
+
+---
+
+## Step 2 Outputs
+- `value-proposition.md` (with testing results)
+- `concept-cards/card-{N}.md` (3-5 cards)
+- Updated `wedge-definition.md`