vc-feasibility-test

name: vc-feasibility-test description: "Use when a SPEC, INNOVATE, or VALIDATE (Layer 2) approach hinges on an unverified runtime/library/external mechanism: run a probe from the 8-family taxonomy and produce a VIABLE/NOT-VIABLE/INCONCLUSIVE VERDICT artifact." argument-hint: "[hypothesis] [task-folder] [probe-family]" trigger_keywords: feasibility, spike, verify assumption, probe mechanism, empirical check, unverified mechanism, does this work, runtime quirk, api shape check layer: contract metadata: author: vibecode-pro-max-kit version: "2.0.0"

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

One-shot empirical probe skill. Used when SPEC or INNOVATE encounters an approach hinging on an unverified external/runtime/library mechanism — the question is "does this mechanism actually work the way the design assumes?", asked before the decision locks.

Boundary vs vc-test-coverage-plan

These two skills are complementary and must not be confused:

vc-feasibility-test (this skill) = PRE-decision. "Does the mechanism work at all?" Run before SPEC/INNOVATE locks an approach, when the answer is unknown. Output: a one-shot VERDICT artifact.
vc-test-coverage-plan = POST-plan. "How do I cover this blast radius across the 4 test tiers?" Run after a plan exists, when the design is already chosen. Output: a per-area tier table.

If the approach is already decided and you are assigning test tiers → use vc-test-coverage-plan. If you cannot decide because a mechanism is unverified → use this skill first.

When To Invoke

When vc-spec-agent, vc-innovate-agent, or a vc-validate-agent Layer 2 dimension agent emits VC-FEASIBILITY-PROBE-NEEDED
When a mechanism cannot be verified from source code alone
One-shot: not an iterative loop (use vc-autoresearch for iteration)

Skill Executor

Always executed by vc-debugger (via the VC-FEASIBILITY-PROBE-NEEDED signal routing in orchestration.md). SPEC, INNOVATE, and VALIDATE Layer 2 agents do not run probes themselves.

Probe-Method Taxonomy (pick one family)

Every probe belongs to one of these 8 families. Name the chosen family in the VERDICT. Each family has a default cost/safety class (see next section) — the probe inherits it.

#	Family	What it probes	Typical method	Default cost class
1	Local process / Node script	pure library/runtime behavior in isolation	run a `.mjs`/Bun script, regex/parse check, call the lib fn directly	cheap-local
2	Unit/integration test harness	behavior under the project's own test runner	`pnpm --filter … test` (Vitest) or `bun test` on a scratch case	cheap-local
3	tRPC / Prisma / DB query	route shape, query behavior, index/constraint semantics	hit a tRPC route or run a Prisma/raw-SQL query against a test DB	needs-container (only if it needs the live app DB) / else cheap-local
4	External API shape capture	real response shape/behavior of a 3rd-party API	one live request to OpenRouter / Stripe / Composio / Clerk / Bright Data	needs-live-provider
5	Container exec / internal-port curl	in-container service behavior, proxy injection, file-server, supervisord	`docker exec … curl http://localhost:{port}` on a disposable container	needs-container
6	Browser / CDP capture	anti-detect quirks, CDP events, SPA nav, popup behavior	Playwright/CDP client, `page.on(...)`, snapshot	needs-browser
7	WS / SSE handshake & timing	gateway WS framing, SSE delivery/reconnect, JSONL shape	raw `ws`/`EventSource` client + frame/timing capture	needs-container (if against in-container service) / else cheap-local
8	Cloudflare worker runtime	KV staleness, step-replay/idempotency, edge JWT verify	`wrangler dev` + curl, deploy a throwaway worker	needs-cf

If none of the 8 fit, the question is probably not a feasibility probe — reconsider whether vc-research-agent (unknown context) or vc-test-coverage-plan (known design) is the right tool instead.

Probe Cost / Safety Class (MANDATORY GATE)

Every VERDICT declares one cost class. The class governs whether the probe may run unattended or needs explicit opt-in. A probe that cannot be run within its safety gate produces an INCONCLUSIVE verdict — it is never silently skipped or faked.

Cost class	Safety gate	If gate not met
cheap-local	none — run freely (local script, test harness, parse check)	n/a
needs-container	use a disposable container only. NEVER `docker exec` the shared dev container (`app-*`) or shared Postgres. Disposable live-E2E containers need the disposable-cleanup env gate enabled.	verdict `INCONCLUSIVE`, note "no disposable container available"
needs-live-provider	requires explicit double opt-in from the user before any billed/live 3rd-party call (OpenRouter, Stripe, Composio, Bright Data, Clerk). Default local mode is BYOK Mistral.	verdict `INCONCLUSIVE`, note "live-provider opt-in not granted"
needs-browser	a browser/CDP session must be available; never drive a shared user session	verdict `INCONCLUSIVE`, note "no browser session available"
needs-cf	a `wrangler dev`/throwaway-worker sandbox; never touch a deployed production worker	verdict `INCONCLUSIVE`, note "no CF sandbox available"

The emitted VC-FEASIBILITY-PROBE-NEEDED signal SHOULD carry the anticipated cost class so the orchestrator can resolve the opt-in gate before dispatching vc-debugger (see orchestration.md §VC-FEASIBILITY-PROBE-NEEDED Signal Routing).

Probe Execution Steps

Read the hypothesis from the VC-FEASIBILITY-PROBE-NEEDED signal
Pick the probe family (1–8) and its cost class
Confirm the safety gate for that cost class is met. If not → write an INCONCLUSIVE verdict with the gate-not-met reason and stop. Do NOT escalate to a higher-cost probe or run against a shared resource.
Design the minimal probe within that family
Run the probe empirically — capture actual output, not expected output
Analyze the evidence: does it confirm or refute the hypothesis?
Assign a verdict: VIABLE | NOT-VIABLE | INCONCLUSIVE
Write the VERDICT artifact to the active task folder

VERDICT Artifact Format

Filename: {slug}_FEASIBILITY_{dd-mm-yy}.md Location: same active task folder as the SPEC/plan that triggered the probe

Required frontmatter fields (MUST be present — validated by validate-feasibility-verdict.mjs):

---
slug: [task-slug]
date: YYYY-MM-DD
verdict: VIABLE | NOT-VIABLE | INCONCLUSIVE
originating-phase: spec | innovate | pvl
---

The originating-phase: field is REQUIRED. Valid values:

spec — probe triggered by vc-spec-agent ([SP3])
innovate — probe triggered by vc-innovate-agent ([I2.5])
pvl — probe triggered by vc-validate-agent Layer 2 ([V2-PROBE])

Required sections (MUST be present — validated by validate-feasibility-verdict.mjs):

Hypothesis

One-sentence statement of what is being tested.

Mechanism Under Test

The specific external, runtime, or library behavior being probed.

Probe Family

One of the 8 families above (e.g. 5 — Container exec / internal-port curl).

Probe Cost Class

One of: cheap-local | needs-container | needs-live-provider | needs-browser | needs-cf. State whether the safety gate was met.

Probe Method

The exact command(s) or steps run to test the hypothesis.

Evidence Captured

The raw output from the probe (trimmed to relevant lines). For an INCONCLUSIVE gate-not-met verdict, state explicitly that the probe was not run and why.

Verdict

One of: VIABLE | NOT-VIABLE | INCONCLUSIVE

Resulting Design Constraint

The "action consequence" of the probe, split into three explicit parts:

What this licenses: what the approach is now allowed to depend on.
What this forbids: what the approach must NOT depend on.
What remains uncertain (known-gap): what the probe did not settle and must be treated as an open risk (for INCONCLUSIVE, this is the main content).

Completion Signal

After writing the VERDICT artifact, emit:

VC-FEASIBILITY-VERDICT-READY: [verdict keyword] — [full path to VERDICT file]

Example:

VC-FEASIBILITY-VERDICT-READY: NOT-VIABLE — process/features/model-selector/active/model-selector_10-06-26/model-selector_FEASIBILITY_10-06-26.md

Re-spawn Handoff

The orchestrator reads the VERDICT artifact and extracts a Prior Feasibility: summary. Format passed to the re-spawned agent:

Prior Feasibility: [hypothesis] — verdict: [VIABLE|NOT-VIABLE|INCONCLUSIVE] — licenses: [one line] — forbids: [one line] — uncertain: [one line]

Example:

Prior Feasibility: Does the gateway forward params.provider.sort? — verdict: NOT-VIABLE — licenses: nothing new — forbids: any approach depending on params.provider.sort being forwarded (the layer strips it) — uncertain: whether a different forwarding field survives

The re-spawned SPEC, INNOVATE, or VALIDATE agent reads this block and uses the verdict to lock or reject the approach. When originating-phase: pvl, the re-spawned vc-validate-agent resumes from V1 and records resolved probes in a ## Feasibility Probes Resolved subsection of the validate-contract (omitted when no probe ran).