vc-predict

# vc-predict — Multi-Persona Pre-Analysis

> **Output style:** Follow `process/development-protocols/communication-standards.md` — answer-first, plain language, no unexplained jargon, TL;DR on long responses.

Five expert personas independently analyze a proposed change, then debate conflicts to produce a consensus verdict before a single line of code is written.

## When to Use

- Before implementing a major or high-risk feature
- Before a significant refactor or architecture change
- Evaluating competing technical approaches
- Stress-testing assumptions in a proposed design

## When NOT to Use

- Trivial or low-risk changes (use `debugger` for bugs, `generate-plan` / `plan-agent` for already-decided tasks)
- Already-approved work with no open design questions
- Pure dependency upgrades with no API changes

---

## Mode Selection

`vc-predict` runs in **Simple** or **Deep** mode. Choose based on the conditions below.

| | Simple | Deep |
|---|---|---|
| Context source | Approach description already in context | Approach description + historical research subagent |
| Subagent spawned | No | Yes — reads git log, prior reports, test failure history |
| Persona debate quality | Reasons from first principles | "We tried this 3 months ago and hit X" |
| When to use | Contained feature, clear scope, no prior attempts | See trigger conditions below |

### Deep Mode — Trigger Conditions (any one is sufficient)

- The approach involves a pattern previously attempted in this codebase (git history may show prior attempts)
- The approach touches a surface with known failure history: auth, billing, container lifecycle, streaming, or WebSocket reconnect
- Caller explicitly requests deep mode (`--deep` flag or "use deep predict")
- The plan is **COMPLEX** shape and this is the pre-checklist predict call

### Simple Mode — Trigger Conditions (default)

- Approach is a contained feature with clear scope
- No prior attempts at this surface area are likely
- Plan is SIMPLE shape and the design is not controversial

---

## Deep Mode — Research Subagent Protocol

Before the 5-persona debate, spawn a research subagent that performs the following steps in order:

1. **Git history scan** — run `git log --oneline --all -- [relevant files]` for each file or directory the approach touches. Flag any commits within the last 6 months that suggest a prior attempt, revert, or known fix.
2. **Prior phase reports** — search task folders under `process/features/{feature}/active/` and `process/features/{feature}/completed/` for `_REPORT_` files mentioning this surface (pattern: `active/{slug}_{date}/{slug}_REPORT_{date}.md`). Read any that contain keywords from the approach (e.g. "streaming", "SSE", "auth", "billing", "container lifecycle"). Legacy sibling `reports/` dir may also exist — scan it too if present.
3. **Test failure history** — grep test output files and CI logs for `FAIL` or `Error` patterns on relevant module names. Note recurring failures.
4. **Return a Historical Context block** containing:
   - What was tried before (commit refs, dates, brief description)
   - What failed and why
   - Current state of the surface (is it stable, under active churn, recently refactored?)
   - Known landmines (specific lines, patterns, or edge cases that broke before)

The 5 personas then receive this Historical Context block before their independent analysis phase. Each persona incorporates it when relevant.

### Output Quality Difference

**Simple predict** (no research):
> "Senior dev: this streaming approach could cause a memory leak in the SSE proxy."

**Deep predict** (with historical research):
> "Senior dev: we tried this exact streaming approach in commit `a3f921` (2026-03-15) — it caused a memory leak in the SSE proxy because the Bun response body was never released on client disconnect. The current proposal has the same pattern in `packages/api/src/routes/gateway-proxy.ts` line 84. The fix at the time was adding an `AbortController` listener; verify that is still present or re-apply."

---

## The 5 Personas

| Persona | Focus | Core Questions |
|---------|-------|----------------|
| **Architect** | System design, scalability, coupling | Does this fit the architecture? Will it scale? What new coupling does it introduce? |
| **Security** | Attack surface, data protection, auth | What can be abused? Where is data exposed? Are auth boundaries respected? |
| **Performance** | Latency, memory, queries, bundle size | What is the latency impact? N+1 queries? Memory leaks? Bundle bloat? |
| **UX** | User experience, accessibility, error states | Is this intuitive? What does the error state look like? Accessible on mobile? |
| **Devil's Advocate** | Hidden assumptions, simpler alternatives | Why not do nothing? What is the simplest alternative? Which assumption could be wrong? |

---

## Debate Protocol

1. **Read** the proposed change/feature description from the argument
2. **Read relevant code** if file paths are provided (grep for affected areas)
3. **Each persona analyzes independently** — do not let personas influence each other during this phase
4. **Identify agreements** — points where all (or 4+) personas align
5. **Identify conflicts** — points where personas meaningfully disagree
6. **Weigh tradeoffs** — for each conflict, evaluate which concern has higher impact
7. **Produce verdict** — GO / CAUTION / STOP with actionable recommendations

---

## Output Format

```
## Prediction Report: [proposal title]

## Verdict: GO | CAUTION | STOP

### Agreements (all personas align)
- [Point 1 — what they all agree on]
- [Point 2]

### Conflicts & Resolutions

| Topic | Architect | Security | Performance | UX | Devil's Advocate | Resolution |
|-------|-----------|----------|-------------|-----|-----------------|------------|
| [Issue] | [View] | [View] | [View] | [View] | [View] | [Recommendation] |

### Risk Summary

| Risk | Severity | Mitigation |
|------|----------|------------|
| [Risk description] | Critical/High/