V-AC Feasibility

Overview

A verification-AC (V-AC) can be written, reviewed, and cite the correct AC number, yet be impossible to satisfy under any correct implementation — because the runtime command it relies on tests something the runtime semantics never expose. This gate arms when a plan's Validation Checklist contains any V-AC whose verification is a runtime command: docker exec/kubectl exec, curl/wget/Playwright against a running service, systemctl/journalctl state or log assertions, redis-cli/psql/mongosh live-query assertions, or any assertion over a running process's environment/memory/in-flight state. Static V-AC (test -f, grep against a file, lint/unit exit codes) do not need this gate — they are deterministic against the working tree.

The Failure This Gate Prevents

Motivating incident: an AC asserting "env var X is set to Y on the running service" was verified by docker exec <container> printenv X. But printenv reads the shell's environment, not the value a running Node process holds after process.env[X] = Y was set in code. The assertion could never pass, no matter how correct the implementation — yet it survived plan review because the reviewer matched the AC number and the command shape without executing it against a real (or skeleton) runtime. Verbatim AC↔V-AC mirroring and semantic-match review are necessary but not sufficient: a V-AC must also be feasible, and feasibility is a property of runtime semantics, not of text.

The Contract

For every runtime-command V-AC, the plan must demonstrate — before locking it into the Validation Checklist — that the command can return the PASS result when the implementation is correct. Acceptable evidence, in order of preference:

1. Dry-run against a real runtime. Execute the command against the running dev/staging/test service (or a stubbed skeleton standing in for the final one) and confirm it produces an observable, correct result under a deliberately-correct fixture. Quote the result inline in the plan.
2. Semantic proof of the observation path. When no runtime is reachable at plan time, name the exact mechanism through which the asserted value becomes observable — e.g. "the value is logged via the application logger and asserted with journalctl -u <unit> | grep", or "the value is exposed on /healthz JSON and asserted with curl … | jq". A command whose observation path cannot be named is presumed infeasible.
3. Re-scope to a feasible assertion. If neither holds, replace the V-AC with one that is observable — the log line, HTTP response field, or persisted side-effect instead of the in-process value the runtime never exposes.

Common Infeasible Patterns

• docker exec C printenv X for a value set via process.env[X]=Y in code — printenv reads the shell env, not the live process's mutated env. Replacement: assert the app log line or a /config health field that echoes X.
• curl <url> before the service binds the port/route exists — unmapped route returns 404 regardless of correctness. Replacement: grep the router for the real path first, then assert the mapped route.
• kubectl exec … cat /proc/1/environ for a runtime-mutated var — /proc/1/environ is the launch env, frozen at exec time. Replacement: expose the value through an app endpoint or structured log.
• systemctl show -p Environment for an app-set variable — shows unit-declared env, not values set inside the process. Replacement: assert via the app's own observability surface.

Output

Record the feasibility verdict inline in the plan next to each runtime-command V-AC, so a reviewer replays it without re-querying:

• V-AC-N — feasible (dry-run: <command> → <observed PASS result>)
• V-AC-N — feasible (observation path: <named mechanism>)
• V-AC-N — infeasible as written → re-scoped to <new assertion>

A runtime-command V-AC with no feasibility annotation is a planning defect: fix the plan (prove or re-scope) before transitioning to /dr-do. Catching an infeasible V-AC at plan time costs one dry-run or one grep; catching it at /dr-do or /dr-verify costs a full pipeline cycle plus a V-gate reformulation.