Vc Test Coverage Plan

vc-test-coverage-plan

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

Generate a TDD-first full test plan per blast radius area. Assigns all 4 test tiers with exact commands, what each proves, what it does NOT prove, and explicit resolution options for every gap.

Boundary vs vc-feasibility-test

This skill is POST-decision: the design is already chosen and you are assigning coverage tiers across a known blast radius. If instead an approach cannot be decided because a runtime/library/external mechanism is unverified — that is a PRE-decision question and belongs to vc-feasibility-test (a one-shot empirical probe producing a VIABLE/NOT-VIABLE/INCONCLUSIVE VERDICT), run before SPEC/INNOVATE locks. Do not use test tiers to answer "does this mechanism work at all?".

When To Invoke

• PLAN phase — populate the Verification Evidence section of a new plan
• VALIDATE Section III — generate the full test plan after V2 fan-out, before writing the validate-contract
• EXECUTE phase — as test gates at the end of each plan section and as a regression suite after all sections complete

Context Discovery (MANDATORY FIRST — do this before anything else)

This skill MUST NOT infer tiers, commands, or runners from training data. Before reading the plan or naming a single area:

1. Invoke vc-context-discovery to load the relevant context group files.
2. Read process/context/tests/all-tests.md and follow its downstream routing chain to the relevant deeper test docs (tests/container-e2e.md, tests/browser-automation.md, tests/live-e2e.md, etc.). The entry point is a router, not full knowledge — reading only the router and skipping the chain is insufficient.
3. Discover the existing test files inside the blast radius (real runners + real commands + real fixtures — not guesses).

Hard stop (mirrors vc-plan-agent TIER_ASSIGNMENTS_BLOCKED): if the all-tests.md routing chain was not loaded, or existing blast-radius test files were not discovered, STOP and emit TIER_ASSIGNMENTS_BLOCKED — report BLOCKED with "Test context chain not loaded; returning to RESEARCH to load all-tests.md and discover existing test files. Do not generate tier assignments from training data." Do NOT proceed to the waterfall. Every Command / Steps cell below must be an exact command sourced from the loaded test context, never an inferred placeholder.

Test Tier Decision Waterfall

For each area in the plan's blast radius, assign a tier using this waterfall:

1. Fully-automated — if a deterministic command exists that exercises the area end-to-end without human judgment. Must be runnable in CI without setup beyond env vars. Examples: pnpm test, bun test, node validate-script.mjs, grep checks.

2. Hybrid — if the test requires a precondition (running container, live DB, specific env) that is not always available in CI, but the test itself is deterministic once set up. Record the precondition explicitly. Examples: container E2E tests, DB migration checks.

3. Agent probe — if the area requires judgment that cannot be mechanically asserted. Describe the probe scenario and what the agent should judge. Examples: UI visual regression, prose quality, API response plausibility.

4. Known gap — if no test exists and none can be added within the blast radius of this plan. Document the gap explicitly. Do not use this tier to avoid writing tests.

High-Risk Classes

These classes always require at least a hybrid test gate (no known-gap allowed without explicit documented rationale):

• auth or identity flows
• billing, payments, or credit accounting
• schema/data migrations or destructive writes
• public API or external contract changes
• deploy/runtime/container/proxy/gateway behavior
• permission, secret, or trust-boundary logic

Required table format for high-risk class areas:

Hybrid Failure Resolution Priority

When a hybrid test fails during or after EXECUTE:

1. Fix now — if the failure is in the blast radius of the current plan and the fix is small. Fix, re-run the hybrid gate, confirm green, then continue.
2. New phase plan — if the failure requires work that is outside the current phase scope but has a clear fix. Create a follow-up phase plan and document the gap.
3. Update existing phases — if the failure is in a phase that is still active and the fix can be absorbed without scope expansion. Route the fix back to that phase.
4. Backlog note — if the failure is in a known-gap area, the fix is non-trivial, and deferral is acceptable. Write a backlog artifact. Do not silently absorb it.

Per-Area Test Plan Output Format

Produce one block per area in the blast radius. Area = package, service, or logical surface (e.g. packages/api — new route, packages/ui — UI component).

Area: [package/service name]

Rules:

• Include a row for every tier that applies. Omit a tier row only if the tier genuinely does not apply — do not omit to avoid work.
• Known-gap rows must have — in the Command/Steps column and a brief reason in the "What it does NOT prove" column.
• Fully-automated commands must be exact and runnable — do not use placeholder [command] in a real output.