vc-validate-findings

# vc-validate-findings

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

Defines the role specs, prompts, and output schemas for the two-layer VALIDATE fan-out (a parallel check across 4 dimensions + per-section feasibility probes). Produces a net gate verdict (PASS / CONDITIONAL / BLOCKED) and all the inputs needed to write the validate-contract — the written checklist that gates EXECUTE.

---

## References

- `references/example-validate-output.md` — full V4 menu + validate-contract template; calibrate output format against this file

---

## When To Invoke

- VALIDATE V2–V3: invoked by `vc-validate-agent` after V1 pre-check passes
- Post-execute review in UPDATE PROCESS when re-validation of a plan is needed

---

## Strategy Boundary

This skill is **STRATEGY-AGNOSTIC**. It defines the role specs, prompts, and output schemas for each dimension/section agent. It does NOT determine how those agents are executed (Workflow vs parallel Agent tool vs vc-team).

The execution method is determined by `vc-agent-strategy-compare`, which must be invoked BEFORE `vc-validate-findings` is called. `vc-validate-findings` outputs agent role definitions; the caller executes them using the recommended strategy.

---

## Mode Selection

Choose before spawning any agents. Pass the selected mode to all Layer 1 and Layer 2 agents in their prompt context.

### Simple Mode (default)

Runs the Layer 1 + Layer 2 fan-out using context available in the current conversation. Validation agents derive context from the plan file and what was passed in the prompt.

**Appropriate when:**
- Plan is self-contained (all context needed is in the plan text)
- Context is fresh in the current conversation window
- Blast radius is clear and confined to a single domain
- No container/infra/worker lifecycle surfaces are touched
- Fewer than 5 blast-radius packages

### Deep Mode

Trigger when **any one** of the following is true:
- Plan blast radius touches container, infra, or worker lifecycle
- Plan has 5+ blast-radius packages
- Plan is a phase in a multi-phase program (prior phase outputs must be loaded)
- Caller explicitly requests deep mode

**How Deep Mode works — run this context-loading step BEFORE spawning any Layer 1 or Layer 2 agents:**

1. Read `process/context/all-context.md` routing table → identify which context groups are relevant to the blast radius
2. Load relevant context group `all-*.md` files (e.g. `container/all-container.md`, `infra/all-infra.md`, `tests/all-tests.md`, `skills/all-skills.md`) — only the groups that apply
3. If phase program: read the latest 1–2 phase reports from inside task folders (`process/features/{feature}/active/{slug}_{date}/{slug}_REPORT_{date}.md`) or legacy `process/features/{feature}/reports/` (read-only legacy path)
4. Read existing test files in the blast radius (gives the Layer 1 test-coverage agent real data, not guesses)
5. Package all loaded material as a **Context Bundle** and pass it to every Layer 1 and Layer 2 agent

**Quality difference in practice:**
- Simple: Layer 1 infra agent infers container port assignments from plan description text
- Deep: Layer 1 infra agent reads the container context group (process/context/container/ or the repo's equivalent routing entrypoint) and knows the real port table (gateway:3000, file-server:3001, app-dev:3002, ctx-gateway:3099, browser-bridge:9377, MITM:9090/9091) — can catch real port conflicts the plan missed

---

## Layer 1 — Four Always-On Dimension Agents

Always run all four, regardless of complexity score. These run in parallel.

| Dimension | Focus | Context to attach |
|---|---|---|
| Infra/setup fit | Does this work with container/worker/proxy architecture? Are target file paths, port numbers, and runtime surfaces correct? | `process/context/all-context.md` routing → container and infra groups (follow routing table for local paths) |
| Test coverage | Is the verification strategy realistic given the test infra? Which tiers apply (fully-automated / hybrid / agent-probe)? | `process/context/tests/all-tests.md` |
| Breaking changes | Identify API contracts, schemas, auth flows, or public contract changes. Are downstream consumers listed and safe? | Plan's Public Contracts and Blast Radius sections |
| Security surface | Quick STRIDE/OWASP scan. Does the plan touch auth, billing, data, secrets, or trust boundaries? | `vc-security` skill context |

**Note:** the security surface dimension INVOKES the `vc-security` skill — do not absorb `vc-security`'s logic here.

### Per-Agent Output Format

```
Dimension: [name]
Status: PASS | CONCERN | FAIL
Findings:
- [finding 1]
- [finding 2]
Confidence: HIGH | MEDIUM | LOW
Notes: [optional context]
```

---

## Layer 2 — Per-Section Feasibility Agents

One agent per plan section or phase. These run in parallel with each other (and may overlap with Layer 1 in time, but Layer 2 results are presented after Layer 1 results are collected).

Each Layer 2 agent must answer four questions — not just "are edit targets findable?":

1. **Mechanical feasibility** — Are the edit target strings present and uniquely matchable in the named files? Can the described create/write steps be executed without collision?
2. **Plan gaps** — What is this section missing that it should include? Are there adjacent files or behaviors that should be updated but are not listed?
3. **Conflicts** — Does anything in this section contradict current file state, other plan sections, or repo conventions?
4. **Risk** — What is the single highest-risk edit in this section and how should the execute-agent sequence or mitigate it?

### Per-Agent Output Format

```
Section: [section name or phase number]
Status: PASS | CONCERN | FAIL
Mechanical feasibility: [verdict + evidence]
Gaps found: [list or "none"]
Conflicts found: [list or "none"]
Highest-risk edit + mitigation: [description]
```

**Warning:** A La