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:

| Area | High-risk class | Minimum tier | Gap rationale if known-gap accepted |
|---|---|---|---|
| [e.g. Auth/identity flow] | auth/identity | Hybrid | [If known-gap: must state why hybrid is impossible and what alternative coverage exists] |
| [e.g. Billing credit deduction] | billing/credits | Hybrid | — |

## 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]**

| Tier | Scenario | Command / Steps | What it proves | What it does NOT prove |
|---|---|---|---|---|
| Fully-automated | [e.g. Route returns 200 with correct shape] | `[exact command]` exits 0 | [Specific outcome proved] | [Explicit gap] |
| Fully-automated | [e.g. Route returns 401 on missing token] | Same suite, auth-rejection case | [Specific outcome proved] | [Explicit gap] |
| Hybrid | [e.g. Integration with real DB] | `[exact command]` — precondition: [what must be running/set] | [Specific outcome proved] | [Explicit gap] |
| Agent probe | [e.g. Visual or behavioral judgment] | [Step-by-step scenario for the agent] | [What the agent judges] | [What cannot be aut