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.

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 Layer 2 agent that only confirms edit targets are findable without assessing gaps and conflicts is incomplete and must be re-run with the full four-question prompt.

[V2-PROBE] Feasibility Probe Emission Rule

When answering the 4 questions above, if a plan section depends on an untested runtime/system behavior (network/protocol/runtime/third-party response shape) that cannot be verified by reading source files, the Layer 2 agent MUST:

1. Emit VC-FEASIBILITY-PROBE-NEEDED: [hypothesis] — cost-class: [class] and halt.
2. NOT produce the standard per-agent output format.
3. NOT attempt to reason about the untested behavior as if it were mechanical.

Mechanical checks (NO probe): edit targets findable by Grep, file exists, schema field present, export names matchable, port in the container table, config key present in env.ts.

Examples of mechanical checks (NO probe): "does src/env.ts export a <SERVICE>_JWT_SECRET field?" → read the file; "does the container table list port 3000 for the gateway service?" → read the table.

Probe candidates (emit + halt): any behavior that requires a running system, live network call, or in-container exec to verify.

Examples of probe candidates: "does the gateway forward the X-Custom-Routing header to the upstream provider at runtime?", "does the container proxy honor the allow-list config field when injecting platform keys?", "does the OpenRouter API return pricing as a string or a number?".

Note: For each CONCERN found, INVOKE vc-scenario. For high-risk flagged concerns, INVOKE vc-predict.