Vc Feasibility Test

vc-feasibility-test

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.

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.

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

1. Read the hypothesis from the VC-FEASIBILITY-PROBE-NEEDED signal
2. Pick the probe family (1–8) and its cost class
3. 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.
4. Design the minimal probe within that family
5. Run the probe empirically — capture actual output, not expected output
6. Analyze the evidence: does it confirm or refute the hypothesis?
7. Assign a verdict: VIABLE | NOT-VIABLE | INCONCLUSIVE
8. 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).