convoke-agents 2.0.0

package/_bmad/bme/_vortex/workflows/production-monitoring/steps/step-05-synthesize.md

@@ -0,0 +1,183 @@
+---
+step: 5
+workflow: production-monitoring
+title: Synthesize & Route
+---
+
+# Step 5: Synthesize & Route
+
+Time to bring the portfolio together. We've validated experiment contexts, assembled the portfolio, monitored signals against baselines, and prioritized by divergence severity. Now we produce the HC5 Portfolio Signal Report artifact and route to the next step in the Vortex.
+
+## Why This Matters
+
+Production data is the most honest user feedback — it can't lie. At portfolio scale, that honest feedback tells Max which experiments are confirming their hypotheses, which are degrading, and which are revealing unexpected behavior. The HC5 portfolio signal report gives Max everything needed to make portfolio-level decisions: prioritized signals across all monitored experiments, divergence assessments, anomaly flags, and data quality — all grounded in experiment baselines. No recommendations. No strategy. Just prioritized portfolio intelligence.
+
+## Your Task
+
+### 1. Review Your Portfolio Signal Report
+
+Before we package everything, let's do a final quality pass on each section:
+
+**Signal Description (Portfolio-Level):**
+
+| Field | Check |
+|-------|-------|
+| **Signal Summary** | Does it capture the portfolio-level picture? Is it factual and concise? |
+| **Signal Type** | Is the classification appropriate for portfolio monitoring? |
+| **Severity** | Is the severity justified by the highest-priority signal in the portfolio? |
+| **Detection Method** | Is it clear this is a portfolio monitoring assessment? |
+| **Time Window** | Is the observation period consistent across experiments? |
+| **Affected Scope** | Are all monitored experiments and their affected areas identified? |
+
+**Context (Per-Experiment Lineage + Vortex History):**
+
+| Field | Check |
+|-------|-------|
+| **Per-Experiment Lineage** | Can each signal be traced back to its originating experiment? Are baselines explicit? |
+| **Vortex History** | Are available upstream references (HC2, HC3, previous HC5) documented per experiment? |
+
+**Trend Analysis (Per-Experiment):**
+
+| Field | Check |
+|-------|-------|
+| **Trend Direction** | Is the trajectory accurately classified for each experiment? |
+| **Rate of Change** | Is divergence quantified with specific metrics, not vague descriptions? |
+| **Baseline Comparison** | Is each experiment's baseline explicitly stated and the comparison clear? |
+| **Confidence** | Does the confidence level reflect both data quality and assessment certainty per experiment? |
+
+**Anomaly Detection (if anomalies flagged):**
+
+| Field | Check |
+|-------|-------|
+| **Anomaly Description** | Is the unexpected behavior described factually, without speculative strategy? |
+| **Discovery Needed** | Is the HC10 routing decision documented with rationale per experiment? |
+
+**Data Quality (Per-Experiment and Portfolio-Level):**
+
+| Field | Check |
+|-------|-------|
+| **Per-Experiment Quality** | Is data quality assessed for each experiment individually? |
+| **Portfolio Confidence** | Does the overall confidence honestly reflect portfolio-level reliability? |
+
+### 2. Generate the HC5 Artifact
+
+I'll produce the HC5 Portfolio Signal Report artifact with this structure:
+
+```yaml
+---
+contract: HC5
+type: artifact
+source_agent: noah
+source_workflow: production-monitoring
+target_agents: [max]
+input_artifacts:
+  - path: "_bmad-output/vortex-artifacts/{hc4-experiment-1}"
+    contract: HC4
+  - path: "_bmad-output/vortex-artifacts/{hc4-experiment-2}"
+    contract: HC4
+created: YYYY-MM-DD
+---
+```
+
+**HC5 Required Body Sections:**
+1. **Signal Description** — Portfolio-level signal summary, Signal Type, Severity (based on highest-priority signal), Detection Method, Time Window, Affected Scope (all monitored experiments)
+2. **Context** — Per-experiment Experiment Lineage (Originating Experiment, Original Hypothesis, Experiment Outcome, Expected Production Behavior, Actual vs Expected) + Vortex History per experiment
+3. **Trend Analysis** — Per-experiment trend direction, duration, rate of change, baseline comparison, confidence
+4. **Anomaly Detection** (when anomalies flagged in any experiment) — Per-experiment anomaly description, deviation, explanations, discovery needed, discovery focus
+5. **Data Quality** — Per-experiment quality assessment + portfolio-level confidence
+
+**Portfolio Signal Summary Addendum:**
+In addition to the standard HC5 sections, include a Portfolio Signal Summary showing each monitored experiment with its priority level, signal status, divergence assessment, and trajectory. This gives Max the portfolio-level view that distinguishes this report from a single-signal or behavioral report.
+
+| Priority | Experiment | Signal Status | Divergence | Trajectory | Anomaly? |
+|----------|-----------|--------------|-----------|-----------|----------|
+| P1 | *name* | *one-sentence* | *quantified* | *direction* | Yes / No |
+| P2 | *name* | *one-sentence* | *quantified* | *direction* | Yes / No |
+| P3 | *name* | *one-sentence* | *quantified* | *direction* | Yes / No |
+
+**This artifact explicitly does NOT include:**
+- Strategic recommendations (that is Max's domain)
+- Pivot/patch/persevere decisions (that is Max's domain)
+- Experiment design suggestions (that is Liam/Wade's domain)
+- Resource allocation recommendations (that is Max's domain)
+- Portfolio prioritization decisions (Noah prioritizes signals by divergence; Max decides what to do about them)
+
+Noah produces intelligence — prioritized, evidence-based portfolio monitoring. Max produces decisions.
+
+**Save to:** `{output_folder}/vortex-artifacts/hc5-portfolio-report-{date}.md`
+
+I'll create this file with all the sections above once you confirm the content is ready.
+
+### 3. Validation Questions
+
+Before we finalize, let's validate:
+
+**Evidence Check:**
+- [ ] Is every signal assessment grounded in observed production data compared to experiment baselines?
+- [ ] Can we trace each signal back to its originating experiment through the Experiment Lineage section?
+- [ ] Is divergence quantified with specific metrics for every experiment?
+
+**Portfolio Completeness Check:**
+- [ ] Are all monitored experiments included in the portfolio signal summary?
+- [ ] Does the Signal Description capture the portfolio-level picture, not just individual experiments?
+- [ ] Does each experiment have its own Context section with Experiment Lineage?
+- [ ] Does each experiment have its own Trend Analysis with all 5 required fields?
+- [ ] Does the Data Quality section include both per-experiment and portfolio-level assessment?
+
+**Prioritization Check:**
+- [ ] Is the P1/P2/P3 prioritization consistent with the prioritization framework (severity × scope × confidence)?
+- [ ] Are the highest-priority signals clearly identified and quantified?
+- [ ] Does the portfolio summary give Max a clear ranked view of which experiments need attention?
+
+**Intelligence-Not-Strategy Check:**
+- [ ] Does the report contain zero strategic recommendations?
+- [ ] Does it avoid prescribing what to do about any signal or prioritization?
+- [ ] Does it present findings in prioritized signal + context + trend format, leaving decisions to Max?
+- [ ] Would Max have everything needed to make portfolio-level decisions from this report?
+
+---
+
+## Your Turn
+
+Review the portfolio signal report sections. Confirm when you're ready for me to generate the final HC5 artifact.
+
+---
+
+**[a]** Advanced Elicitation — Deep dive into HC5 refinement with guided questioning
+**[p]** Party Mode — Bring in other Vortex agents for collaborative artifact critique
+**[c]** Continue — Generate the HC5 artifact and proceed to routing
+
+---
+
+## Vortex Compass
+
+Based on what you just completed, here are your evidence-driven options:
+
+| If you learned... | Consider next... | Agent | Why |
+|---|---|---|---|
+| Portfolio signal report complete with prioritized signals across experiments | learning-card | Max 🧭 | Portfolio signal report ready (HC5) |
+| ⚡ Anomalies detected across one or more experiments | user-discovery | Isla 🔍 | Anomalies across experiments (HC10) |
+| Specific signal within the portfolio warrants deeper focused analysis | signal-interpretation | Noah 📡 | Deep dive on specific signal |
+
+> **Note:** These are evidence-based recommendations. You can navigate to any Vortex agent
+> at any time based on your judgment.
+
+**Or run Max's [VN] Vortex Navigation** for a full gap analysis across all streams.
+
+### ⚠️ Insufficient Evidence for Routing
+
+If the evidence gathered so far doesn't clearly point to a single next step:
+
+| To route to... | You need... |
+|----------------|-------------|
+| Max 🧭 | Complete HC5 portfolio signal report with per-experiment assessments and sufficient data quality confidence |
+| Isla 🔍 | Specific anomaly identified across one or more experiments with clear deviation from experiment expectations |
+| Noah 📡 | Specific signal identified during monitoring that warrants focused signal-interpretation analysis |
+
+**Workflow-specific signals:**
+- Portfolio assembly incomplete → consider revisiting **step-02** for complete baseline mapping
+- Divergence assessment unclear → consider revisiting **step-03** for sharper signal monitoring
+- Prioritization criteria insufficient → consider revisiting **step-04** for clearer severity/scope assessment
+- Insufficient experiment contexts provided → gather more HC4 artifacts before proceeding
+
+**Recommended:** Revisit earlier steps to strengthen your portfolio monitoring, or run **Max's [VN] Vortex Navigation** for a full gap analysis.

package/_bmad/bme/_vortex/workflows/production-monitoring/workflow.md

@@ -0,0 +1,52 @@
+---
+workflow: production-monitoring
+type: step-file
+description: Monitor production signals across multiple active experiments simultaneously to prioritize divergence and produce portfolio-level intelligence reports
+author: Noah (production-intelligence-specialist)
+version: 1.6.0
+---
+
+# Production Monitoring Workflow
+
+This workflow guides you through monitoring production signals across multiple active experiments simultaneously, prioritizing signals by divergence from validated baselines, and producing an HC5 portfolio signal report for Max.
+
+## What is Production Monitoring?
+
+Production monitoring is the practice of watching multiple graduated experiments in production at once — reading the portfolio of signals through their experiment baselines to identify which experiments need attention and which are performing as expected.
+
+Signal + context + trend applies to every experiment in the portfolio. A single experiment's signal tells you about that experiment. Multiple experiments' signals tell you about the portfolio — which bets are paying off, which are degrading, and which are revealing behavior the experiments didn't anticipate. Anomaly detection surfaces what dashboards hide, but at portfolio scale, it also surfaces cross-experiment patterns that single-signal analysis misses.
+
+This workflow assembles the experiment portfolio, monitors each experiment's production signals against its baselines, prioritizes by divergence severity, and packages the portfolio intelligence for the decision-maker. Here's what we're seeing in context across the portfolio: that's the deliverable. Not strategy. Not recommendations. Prioritized portfolio intelligence.
+
+## Workflow Structure
+
+**Step-file architecture:**
+- Just-in-time loading (each step loads only when needed)
+- Sequential enforcement (must complete step N before step N+1)
+- State tracking in frontmatter (progress preserved)
+
+## Steps Overview
+
+1. **Setup & Multi-Experiment Input Validation** - Validate multiple experiment context inputs (HC4 artifacts or equivalent)
+2. **Portfolio Assembly & Baseline Mapping** - Assemble the experiment portfolio and extract validated baselines per experiment
+3. **Signal Monitoring & Divergence Assessment** - Monitor production signals for each experiment and assess divergence from baselines
+4. **Signal Prioritization & Anomaly Flagging** - Prioritize signals by divergence severity and flag anomalies for routing
+5. **Synthesize & Route** - Produce HC5 portfolio signal report artifact and route via Compass
+
+## Output
+
+**Artifact:** HC5 Portfolio Signal Report markdown file in `{output_folder}/vortex-artifacts/hc5-portfolio-report-{date}.md`
+
+**Template:** None (HC5 artifact is generated inline during Step 5)
+
+**Schema:** Conforms to HC5 contract (`_bmad/bme/_vortex/contracts/hc5-signal-report.md`)
+
+**Consumer:** Max (learning-card) uses this to make portfolio-level decisions about which experiments need attention.
+
+---
+
+## INITIALIZATION
+
+Load config from {project-root}/_bmad/bme/_vortex/config.yaml
+
+Load step: {project-root}/_bmad/bme/_vortex/workflows/production-monitoring/steps/step-01-setup.md

package/_bmad/bme/_vortex/workflows/proof-of-concept/proof-of-concept.template.md

@@ -0,0 +1,25 @@
+---
+title: "PoC: {poc-name}"
+date: {date}
+type: proof-of-concept
+status: {status}
+---
+
+# Proof-of-Concept: {poc-name}
+
+## Technical Risk
+
+{technical-risk}
+
+## PoC Results
+
+{results}
+
+## Feasibility Assessment
+
+{feasibility}
+
+---
+
+**Created with:** Convoke v2.0.0
+**Workflow:** proof-of-concept

package/_bmad/bme/_vortex/workflows/proof-of-concept/steps/step-01-risk.md

@@ -0,0 +1,79 @@
+---
+step: 1
+workflow: proof-of-concept
+title: Define Technical Risk
+---
+
+# Step 1: Define Technical Risk
+
+Before building anything, we need to identify exactly what could prevent this from working. Technical risk comes first because if the technology cannot support the idea, nothing else matters.
+
+## Why This Matters
+
+Teams waste months building products that hit a technical wall they could have identified in a day. Performance bottlenecks, unsupported integrations, algorithmic infeasibility, data constraints -- these are the silent killers of product ideas. Defining technical risk up front forces you to confront the hardest engineering questions before committing resources. This workflow answers "CAN we build this?" so you never waste time asking "SHOULD we build this?" for something that was technically impossible from the start.
+
+## Your Task
+
+### 1. What Are You Trying to Build?
+
+Describe the technical capability you need to validate. Wade expects a clear technical question -- not a business hypothesis, not a user story, but a specific technical challenge.
+
+**Good examples:**
+- "Can we process 10,000 real-time events per second with sub-200ms latency using our current infrastructure?"
+- "Can we integrate with the Stripe Connect API to handle split payments across three-party marketplace transactions?"
+- "Can our recommendation algorithm achieve >80% precision on sparse user data (<10 interactions per user)?"
+
+**Provide your technical question:**
+- What exactly needs to work?
+- What system, API, algorithm, or architecture is involved?
+- What does "working" look like in measurable terms?
+
+### 2. Identify Technical Risk Categories
+
+For your technical question, assess each risk category:
+
+| Risk Category | Your Assessment | Severity |
+|---------------|----------------|----------|
+| **Performance** | Can it meet speed/throughput requirements? What are the latency and volume targets? | High / Medium / Low / N/A |
+| **Scalability** | Will it work at 10x or 100x current load? Where are the scaling bottlenecks? | High / Medium / Low / N/A |
+| **Integration Complexity** | How many external systems, APIs, or services must connect? What are the coupling risks? | High / Medium / Low / N/A |
+| **Third-Party Dependencies** | Are we relying on external services, SDKs, or APIs we do not control? What happens if they change or fail? | High / Medium / Low / N/A |
+| **Data Handling** | Can we access, transform, and store the data we need? Are there volume, format, or privacy constraints? | High / Medium / Low / N/A |
+| **Algorithmic Feasibility** | Does a known solution exist for the computational problem? Is it tractable at our scale? | High / Medium / Low / N/A |
+| **Infrastructure** | Do we have (or can we provision) the compute, storage, and networking required? | High / Medium / Low / N/A |
+
+### 3. Rank Your Top Technical Risks
+
+From the assessment above, identify the 1-3 risks that could kill this effort:
+
+| Priority | Risk | Why It Could Kill Us | Current Evidence |
+|----------|------|---------------------|------------------|
+| 1 | *The risk most likely to block you* | *What happens if this fails* | *What do we know today (if anything)* |
+| 2 | *(optional)* | | |
+| 3 | *(optional)* | | |
+
+**Guidance:** Focus on the risks with the highest severity AND the least evidence. A high-severity risk with strong evidence that it is solvable is not your biggest problem. A medium-severity risk with zero evidence is more dangerous than it looks.
+
+### 4. Define Success and Failure Criteria
+
+Before we design the PoC, establish what "feasible" and "not feasible" mean:
+
+| Criteria | Threshold | How We Will Measure |
+|----------|-----------|-------------------|
+| **Pass** | *What result proves this is technically feasible?* | *Specific metric or observation* |
+| **Fail** | *What result proves this is NOT feasible?* | *Specific metric or observation* |
+| **Inconclusive** | *What result means we need more data?* | *What additional testing would be required* |
+
+If you cannot define a pass/fail threshold, your technical question is too vague. Sharpen it before proceeding.
+
+---
+
+## Your Turn
+
+Describe the technical capability you need to validate, assess the risk categories, rank your top risks, and define pass/fail criteria. Share your analysis and I will help you sharpen the risk definition before we scope the PoC.
+
+## Next Step
+
+When your technical risks are defined and success criteria are established, I'll load:
+
+{project-root}/_bmad/bme/_vortex/workflows/proof-of-concept/steps/step-02-scope.md

package/_bmad/bme/_vortex/workflows/proof-of-concept/steps/step-02-scope.md

@@ -0,0 +1,105 @@
+---
+step: 2
+workflow: proof-of-concept
+title: Design PoC Scope
+---
+
+# Step 2: Design PoC Scope
+
+Now that you know what could break, let's design the smallest possible test that answers the technical feasibility question. A proof-of-concept is not a prototype, not an MVP, not a demo -- it is the minimum code required to validate or invalidate a specific technical risk.
+
+## Why This Matters
+
+The most common PoC failure is scope creep. Teams start testing whether an API integration works and end up building half the product. Every hour spent on polish, error handling, or UI in a PoC is an hour wasted -- because if the core technical question answers "no," all that extra work is thrown away. Ruthless scoping keeps PoCs cheap, fast, and focused on the one question that matters.
+
+## Your Task
+
+### 1. Define the Core Technical Question
+
+From Step 1, distill your risks into a single, testable technical question:
+
+| Element | Your Answer |
+|---------|-------------|
+| **The Question** | What single technical question must this PoC answer? |
+| **In Scope** | What is the minimum set of components, integrations, or code needed to answer the question? |
+| **Out of Scope** | What are you explicitly NOT building? (Error handling, auth, UI, persistence, monitoring, etc.) |
+| **Time Box** | How long should this PoC take? (Hours, not weeks. If it takes weeks, the scope is too large.) |
+
+**Guidance:** If your "In Scope" list has more than 3-5 items, your PoC is too big. Strip it down to the absolute minimum needed to answer the question.
+
+### 2. Design the Technical Approach
+
+Map out the simplest path to answering the question:
+
+| Component | What You Will Build | What You Will Fake/Stub |
+|-----------|-------------------|----------------------|
+| **Data** | *Minimum data needed* | *Hardcoded values, mock data, sample files* |
+| **Integration** | *Actual API calls, library usage, or protocol tests* | *Mock services, stubbed responses, local simulators* |
+| **Compute** | *The actual algorithm, query, or processing* | *Simplified versions, reduced datasets, single-threaded* |
+| **Infrastructure** | *Minimum deployment (local, container, sandbox)* | *Production-grade setup, scaling, redundancy* |
+
+**What you will NOT build:**
+- [ ] Production error handling
+- [ ] Authentication / authorization
+- [ ] User interface (unless UI IS the technical question)
+- [ ] Logging / monitoring
+- [ ] Data migrations
+- [ ] Automated tests (manual verification is fine for a PoC)
+- [ ] Documentation beyond what this workflow produces
+
+### 3. Define PoC Deliverables
+
+What will exist when the PoC is done?
+
+| Deliverable | Description |
+|-------------|------------|
+| **Working code** | *What will it do? What will it demonstrate?* |
+| **Test data** | *What data will you use? Where does it come from?* |
+| **Measurement method** | *How will you measure pass/fail against the criteria from Step 1?* |
+| **Run instructions** | *How does someone else reproduce the result? (Even a single command is enough.)* |
+
+### 4. Identify Dependencies and Blockers
+
+Before building, confirm you have (or can get) everything needed:
+
+| Dependency | Status | Blocker? |
+|------------|--------|----------|
+| **API keys / credentials** | Have / Need / Can self-provision | Yes / No |
+| **Test environment** | Have / Need / Can create locally | Yes / No |
+| **Test data** | Have / Need / Can generate | Yes / No |
+| **Libraries / SDKs** | Have / Need / Can install | Yes / No |
+| **Hardware / compute** | Have / Need / Can provision | Yes / No |
+
+If any dependency is a blocker, resolve it before proceeding to Step 3. Do not start building a PoC that you know will stall on a missing credential or environment.
+
+### 5. Scope Gut-Check
+
+Final check before you build:
+
+- [ ] Can this PoC be completed in the time box defined above?
+- [ ] Does it test exactly one technical risk (the highest-priority one from Step 1)?
+- [ ] Would a clear pass/fail result from this PoC change your decision about the project?
+- [ ] If the PoC fails, will you know WHY it failed (not just that it failed)?
+- [ ] Is there anything in scope that does not directly contribute to answering the technical question?
+
+If you answered "no" to the last question, remove it from scope. If you answered "no" to any of the others, tighten the scope until every answer is "yes."
+
+---
+
+## Your Turn
+
+Design your PoC scope: define the core question, map the technical approach, list deliverables, and confirm dependencies. Share your scope and I will help you cut anything that does not directly answer the technical question.
+
+---
+
+**[a]** Advanced Elicitation -- Deep dive into scope refinement with guided questioning
+**[p]** Party Mode -- Bring in other Vortex agents to challenge your PoC scope
+**[c]** Continue -- Proceed to building the proof-of-concept
+
+---
+
+## Next Step
+
+When your PoC scope is defined and gut-checked, I'll load:
+
+{project-root}/_bmad/bme/_vortex/workflows/proof-of-concept/steps/step-03-build.md

package/_bmad/bme/_vortex/workflows/proof-of-concept/steps/step-03-build.md

@@ -0,0 +1,92 @@
+---
+step: 3
+workflow: proof-of-concept
+title: Build Prototype
+---
+
+# Step 3: Build Prototype
+
+Time to build. The scope is locked, the question is clear, and the pass/fail criteria are defined. Now write the minimum code needed to answer the technical feasibility question -- nothing more.
+
+## Why This Matters
+
+A proof-of-concept is a learning tool, not a product. The moment you start optimizing, refactoring, or adding "just one more feature," you have stopped validating feasibility and started building a product. The goal is a clear answer -- feasible or not feasible -- in the shortest time possible. Ugly code that answers the question is infinitely more valuable than elegant code that answers the wrong question.
+
+## Your Task
+
+### 1. Set Up the Build Environment
+
+Before writing PoC code, confirm your environment matches the scope from Step 2:
+
+| Requirement | Status | Notes |
+|-------------|--------|-------|
+| **Runtime / language** | Ready / Setting up | *e.g., Node 20, Python 3.12, Go 1.22* |
+| **Dependencies installed** | Ready / Installing | *List key libraries or SDKs* |
+| **API keys / credentials** | Configured / Pending | *Confirm access to external services* |
+| **Test data available** | Ready / Generating | *Confirm data source and format* |
+| **Test environment** | Ready / Provisioning | *Local, container, cloud sandbox* |
+
+If anything is "Pending" or "Provisioning," resolve it before proceeding. Do not start coding around missing infrastructure -- that creates noise in your results.
+
+### 2. Build to the Scope
+
+Follow the scope defined in Step 2. For each in-scope component:
+
+| Component | What to Build | Done? |
+|-----------|--------------|-------|
+| *From Step 2 scope* | *Specific implementation task* | [ ] |
+| *From Step 2 scope* | *Specific implementation task* | [ ] |
+| *From Step 2 scope* | *Specific implementation task* | [ ] |
+
+**Build rules:**
+- [ ] **No scope creep.** If you discover something interesting but out of scope, write it down for later -- do not build it now.
+- [ ] **No optimization.** First make it work, then measure. Optimization is for production, not PoCs.
+- [ ] **No polish.** Hardcoded values, console output, manual steps -- all acceptable. The PoC needs to produce a measurable result, not impress anyone.
+- [ ] **Document surprises.** If something unexpected happens during implementation -- an API behaves differently than documented, a library has a limitation you did not expect, performance is wildly different from estimates -- write it down immediately. These surprises ARE the findings.
+
+### 3. Track Implementation Notes
+
+As you build, capture what you learn. These notes feed directly into Step 4 (testing) and Step 6 (documentation):
+
+| Observation | Category | Impact on Feasibility |
+|-------------|----------|----------------------|
+| *What you noticed while building* | Performance / Integration / Data / Algorithm / Infrastructure | Positive / Negative / Neutral |
+
+**Categories to watch:**
+- **Performance:** Was anything surprisingly fast or slow?
+- **Integration:** Did the API/service work as documented? Any unexpected behaviors, rate limits, or authentication quirks?
+- **Data:** Is the data in the format you expected? Any transformation issues?
+- **Algorithm:** Does the approach work in principle? Any edge cases that change the picture?
+- **Infrastructure:** Any resource constraints (memory, CPU, network) you did not anticipate?
+
+### 4. Build Checkpoint
+
+Before moving to testing, verify:
+
+- [ ] The PoC runs end-to-end (even if manually triggered or partially hardcoded)
+- [ ] It produces a measurable output that can be compared against the pass/fail criteria from Step 1
+- [ ] You can reproduce the result (run it again, get a comparable outcome)
+- [ ] You have not built anything outside the Step 2 scope
+- [ ] Implementation notes capture every surprise, blocker, and unexpected behavior
+
+**If the PoC does not run:** That is a valid finding. If you cannot get it working at all, document exactly where it breaks and why. A PoC that fails to run because of a fundamental technical limitation has answered the feasibility question -- the answer is "no" (or "not with this approach").
+
+---
+
+## Your Turn
+
+Build the PoC according to your Step 2 scope. Track implementation notes as you go. When you have a running prototype that produces measurable output, share your implementation notes and we will move to structured testing.
+
+---
+
+**[a]** Advanced Elicitation -- Deep dive into implementation challenges with guided questioning
+**[p]** Party Mode -- Bring in other Vortex agents to review your implementation approach
+**[c]** Continue -- Proceed to testing technical assumptions
+
+---
+
+## Next Step
+
+When your prototype is built and producing measurable output, I'll load:
+
+{project-root}/_bmad/bme/_vortex/workflows/proof-of-concept/steps/step-04-test.md

package/_bmad/bme/_vortex/workflows/proof-of-concept/steps/step-04-test.md

@@ -0,0 +1,103 @@
+---
+step: 4
+workflow: proof-of-concept
+title: Test Technical Assumptions
+---
+
+# Step 4: Test Technical Assumptions
+
+The prototype exists. Now we find out if it actually works -- not "works on my machine" but works against the specific pass/fail criteria defined in Step 1. This is where assumptions meet reality.
+
+## Why This Matters
+
+Building a PoC and declaring it "works" based on a single happy-path run is not validation -- it is confirmation bias. Technical feasibility means the system works under the conditions that matter: at the expected load, with realistic data, against actual API endpoints, within the required time constraints. This step forces you to test systematically rather than optimistically, so the feasibility assessment in Step 5 is grounded in evidence, not hope.
+
+## Your Task
+
+### 1. Revisit Your Pass/Fail Criteria
+
+Pull forward the criteria from Step 1 and confirm they are still the right thresholds:
+
+| Criteria | Threshold (from Step 1) | Still Valid? | Adjusted Threshold (if changed) |
+|----------|------------------------|--------------|-------------------------------|
+| **Pass** | *What proves feasibility* | Yes / No | *Updated threshold if needed* |
+| **Fail** | *What disproves feasibility* | Yes / No | *Updated threshold if needed* |
+| **Inconclusive** | *What means "need more data"* | Yes / No | *Updated threshold if needed* |
+
+If you adjusted thresholds, document why. Moving the goalposts after seeing results is a red flag -- but refining criteria based on what you learned during the build (Step 3) is legitimate.
+
+### 2. Design Test Scenarios
+
+For each technical risk being validated, define specific test scenarios:
+
+| Scenario | What It Tests | Input | Expected Output | Risk Category |
+|----------|--------------|-------|----------------|---------------|
+| **Happy path** | Does it work at all under ideal conditions? | *Simplest valid input* | *Expected result* | Baseline |
+| **Realistic load** | Does it work at expected production conditions? | *Realistic data volume, concurrent users, or request rate* | *Within pass threshold* | Performance / Scalability |
+| **Edge cases** | Does it handle boundary conditions? | *Empty data, maximum size, malformed input, timeout* | *Graceful handling or documented limitation* | Data / Algorithm |
+| **Failure modes** | What happens when dependencies fail? | *API timeout, network error, invalid response* | *Known failure behavior* | Integration / Dependencies |
+| **Stress test** | Where does it break? | *2x, 5x, 10x expected load* | *Identify breaking point* | Scalability |
+
+**Guidance:** You do not need all five scenario types. Choose the ones that directly test your top risks from Step 1. If your primary risk is integration complexity, focus on happy path and failure modes. If your primary risk is performance, focus on realistic load and stress test.
+
+### 3. Run Tests and Record Results
+
+Execute each scenario and record raw results:
+
+| Scenario | Actual Result | Pass/Fail/Inconclusive | Notes |
+|----------|--------------|----------------------|-------|
+| *Happy path* | *What actually happened* | *Against criteria* | *Anything unexpected* |
+| *Realistic load* | *Measured metrics* | *Against criteria* | *Bottlenecks observed* |
+| *Edge cases* | *Behavior observed* | *Against criteria* | *Limitations found* |
+| *Failure modes* | *How it failed* | *Against criteria* | *Recovery behavior* |
+| *Stress test* | *Breaking point found* | *Against criteria* | *Resource limits hit* |
+
+**Record raw data, not interpretations.** If the response time was 340ms, write "340ms" -- do not write "acceptable." Interpretation happens in Step 5.
+
+### 4. Capture Performance Data (If Applicable)
+
+If performance is a relevant risk, record specific metrics:
+
+| Metric | Target (from Step 1) | Measured | Delta | Acceptable? |
+|--------|---------------------|----------|-------|-------------|
+| **Latency (p50)** | *Target ms* | *Actual ms* | *+/- ms* | Yes / No |
+| **Latency (p95)** | *Target ms* | *Actual ms* | *+/- ms* | Yes / No |
+| **Throughput** | *Target ops/sec* | *Actual ops/sec* | *+/- ops/sec* | Yes / No |
+| **Memory usage** | *Target MB* | *Actual MB* | *+/- MB* | Yes / No |
+| **CPU utilization** | *Target %* | *Actual %* | *+/- %* | Yes / No |
+| **Error rate** | *Target %* | *Actual %* | *+/- %* | Yes / No |
+
+### 5. Document Unexpected Findings
+
+During testing, you will discover things you did not expect. These are often more valuable than the planned test results:
+
+| Finding | Expected? | Impact | Action Required |
+|---------|-----------|--------|----------------|
+| *What you discovered* | Yes / No | High / Medium / Low | *Does this change the feasibility assessment?* |
+
+Pay special attention to:
+- API rate limits or throttling not mentioned in documentation
+- Data format inconsistencies between documentation and reality
+- Performance cliffs (works fine at N, collapses at N+1)
+- Hidden dependencies or configuration requirements
+- Licensing or usage restrictions discovered during testing
+
+---
+
+## Your Turn
+
+Design test scenarios for your top technical risks, run them against the prototype, and record raw results. Share your test results and unexpected findings -- I will help you assess what they mean for feasibility.
+
+---
+
+**[a]** Advanced Elicitation -- Deep dive into test design with guided questioning
+**[p]** Party Mode -- Bring in other Vortex agents to challenge your test methodology
+**[c]** Continue -- Proceed to feasibility evaluation
+
+---
+
+## Next Step
+
+When your tests are complete and results are recorded, I'll load:
+
+{project-root}/_bmad/bme/_vortex/workflows/proof-of-concept/steps/step-05-evaluate.md