[FEATURE] Complete verification-goal on-demand proof execution through VNext

[Joncallim]

Parent tracking issue: #187
Parent programme: #184 / #333
Execution mode: implementation
Depends on: #336
Consumed by: #337, #356

Problem Statement

The verification-goal registry/import/revision foundation from #187 is already merged on main through PRs #328-#330, but later executable proof-run work accumulated in stale monolithic PR #331 before VNext. Continuing that branch would introduce project-specific execution/scheduling machinery beside the generic Mission/Execution/Operation runtime.

Forge still needs a safe on-demand proof execution slice before Software Engineering and later scheduled verification can rely on verification goals.

Desired Outcome

A current verification-goal revision can be run on demand as one bounded VNext Execution using typed Operation bindings, explicit Resource/Grant/budget admission and #336 confinement. The run persists canonical outcome/evidence compatible with #185/#186 and safely recovers from restart/duplicate delivery. It owns no recurring scheduler and makes zero model calls by default.

User Story

As the Forge operator,
I want to run a registered “what still works” assertion on demand through the same governed runtime as other work,
So that proof evidence is trustworthy without reviving the stale project-specific runner architecture.

Requirements

• Reuse the verification-goal schema/registry/import/revision code already merged on main; do not replace it.
• Map one selected goal revision to a bounded Execution identity through [FEATURE][ARCH] VNext Phase 0 — generic runtime contracts and compatibility seam #334 contracts.
• Pin goal revision, Resource/repository version, Operation definition/version, verifier policy, timeout/resource limits and actor.
• Use only typed/catalogued deterministic Operation bindings; reject arbitrary model-authored command text.
• Execute command/file proof Operations only through [FEATURE] VNext Phase 2 — secure generic execution envelope and side-effect recovery #336 confinement/Resource Grant authority.
• Default proof execution uses no LLM. A verification goal is deterministic proof unless a separately admitted verifier later requires cognition.
• Persist run lifecycle and canonical result at least passed | failed | inconclusive | blocked, plus [FEATURE] Normalize execution outcomes and stop reasons #185 canonical outcome, duration, evidence refs, Resource/commit fingerprint and stable failure reason.
• Feed comparable attempts into [FEATURE] Add capability reliability ledger #186 only when cohort requirements are satisfied; missing/unknown evidence never becomes success.
• Record last-known-green / first-observed-failing state as rebuildable projections; immutable proof history remains authoritative.
• Duplicate/replayed requests must not produce duplicate confirmed side effects or contradictory terminal state.
• Cancellation/revocation/lease loss fences the underlying Operation.
• Preserve output/redaction/secret/resource bounds reviewed in old [EPIC] Verification goals and proof-run lifecycle #187 work and [FEATURE] VNext Phase 2 — secure generic execution envelope and side-effect recovery #336.
• Provide authenticated API/service entrypoint plus minimal operator run/status/recovery surface; broad reporting belongs [FEATURE] Add reliability, autonomy, and regression reporting #191.
• Do not implement cadence/scheduling here; [FEATURE] Schedule verification-goal proof runs through generic Triggers #356/[FEATURE] VNext Phase 7 — Trigger/Event runtime with dedupe, causality, and zero-token idle #341 own recurring delivery.
• Do not import or depend on [FEATURE] Add independent Verification Workforce execution #188. Independent model verification is a separate parallel capability; [FEATURE] VNext Phase 3 — complete Software Engineering as the first generic Workforce #337 is the integration point where [FEATURE] Add independent Verification Workforce execution #188 and [FEATURE] Complete verification-goal on-demand proof execution through VNext #355 are both consumed.

Implementation Sequence

1. Run contract + persistence — versioned proof-run identity/state/evidence linked to exact goal revision and generic Execution/Principal/Resource/Operation refs; immutable terminal history and rebuildable projections.
2. Preflight/admission service — load current goal revision, verify enabled/current state, bind Resource/ref/version, resolve allowed deterministic Operation, enforce [FEATURE] VNext Phase 2 — secure generic execution envelope and side-effect recovery #336 Grant/confinement/budget/timeout limits before execution.
3. Confined deterministic runner — execute supported command/file proof operation with bounded environment/output/filesystem/process/time; default no model/provider path.
4. Canonical result mapper — distinguish assertion failure, runner/infrastructure failure, policy block, cancellation and inconclusive evidence; emit [FEATURE] Normalize execution outcomes and stop reasons #185 outcome without collapsing unknown state.
5. Evidence + reliability integration — persist deterministic evidence refs/fingerprints and feed only comparable completed evidence to [FEATURE] Add capability reliability ledger #186; last-green/first-failing projection derives from immutable runs.
6. Idempotency/recovery — stable request/run identity, lease fencing, duplicate request/restart/cancel tests and no double terminalization/confirmed side effects.
7. API/operator path — authenticated on-demand run request, current run/status/result/recovery; do not mix scheduling or reporting subsystem work.
8. PR331 requirement-port review — inspect stale PR feat: implement project verification goals and proof runs (#187) #331 solely for edge-case tests (redaction, output bounds, restart/idempotency, command policy) and prove every retained behavior is either implemented here or explicitly out of scope.

Primary Code Seams To Inspect First

• web/lib/verification-goals/** and merged registry/import/revision tests
• web/db/schema.ts / migrations for goal/run evidence
• [FEATURE][ARCH] VNext Phase 0 — generic runtime contracts and compatibility seam #334 Mission/Execution/Resource/Operation/Principal contracts
• [FEATURE] VNext Phase 2 — secure generic execution envelope and side-effect recovery #336 confinement/Grant/Operation runner and cancellation/fencing
• [FEATURE] Normalize execution outcomes and stop reasons #185 canonical outcome helpers
• [FEATURE] Add capability reliability ledger #186 reliability evidence/selectors
• authenticated verification-goal API/UI surfaces
• stale PR feat: implement project verification goals and proof runs (#187) #331 diff/tests only as historical evidence, never implementation base

Orthogonal Checkpoints

1. Goal/revision authority: current vs stale/archived/disabled revision, optimistic revision race, Resource/ref mismatch.
2. Operation policy: arbitrary shell/model-authored command injection, unsupported Operation, environment/path/symlink escape, Resource widening.
3. Confinement/cancellation: timeout, kill/revoke, stale lease, child process, output/disk/resource bounds.
4. Persistence/idempotency: duplicate request, crash before/during/after Operation, restart, terminalization race, projection rebuild.
5. Outcome semantics: assertion failure vs infrastructure error vs block vs inconclusive; unknown/missing evidence never maps green.
6. Evidence/privacy: secrets/raw protected paths/output/logs, redaction and retention, evidence fingerprint provenance.
7. Reliability comparability: wrong goal/Resource/Operation/runtime cohort excluded; sample counts not inflated by duplicate/retried runs.
8. Dependency/scope: no scheduler/Trigger implementation, no reliance on [FEATURE] Schedule verification-goal proof runs through generic Triggers #356 or [FEATURE] Add independent Verification Workforce execution #188; no model call by default.
9. Regression: merged PR328-330 registry/import/revision behavior remains authoritative and green.

Acceptance Criteria

• [FEATURE] VNext Phase 2 — secure generic execution envelope and side-effect recovery #336 is closed before implementation starts.
• An existing merged verification-goal revision runs on demand without using PR feat: implement project verification goals and proof runs (#187) #331's runtime/scheduler branch.
• The proof run has VNext Execution/Principal/Resource/Grant/Operation identity and exact goal revision/version evidence.
• Unsupported/arbitrary command definitions fail before execution.
• Supported command/file proof executes inside [FEATURE] VNext Phase 2 — secure generic execution envelope and side-effect recovery #336 confinement and cannot escape Resource scope.
• Default proof execution makes zero model calls.
• Pass/fail/inconclusive/blocked states persist with canonical [FEATURE] Normalize execution outcomes and stop reasons #185 outcome and bounded evidence, without conflating assertion and infrastructure failure.
• Comparable proof evidence integrates with [FEATURE] Add capability reliability ledger #186 without treating unknown/missing evidence as success or double-counting duplicates.
• Restart/duplicate delivery/cancellation/stale-lease fixtures cannot duplicate confirmed proof action or terminalize inconsistently.
• Last-green/first-failing projections are rebuildable from immutable run history.
• Operator/API status clearly distinguishes policy block, execution failure, assertion failure and inconclusive evidence.
• No scheduler/cron/Trigger implementation, [FEATURE] Add independent Verification Workforce execution #188 dependency or model requirement is added by this issue.
• Relevant safe test/edge-case requirements from PR feat: implement project verification goals and proof runs (#187) #331 are explicitly ported or dispositioned, while no stale branch code is cherry-picked wholesale.

Out of Scope

• Scheduled/recurring proof runs ([FEATURE] Schedule verification-goal proof runs through generic Triggers #356/[FEATURE] VNext Phase 7 — Trigger/Event runtime with dedupe, causality, and zero-token idle #341).
• Full reporting/dashboard ([FEATURE] Add reliability, autonomy, and regression reporting #191).
• Independent model Verification Workforce ([FEATURE] Add independent Verification Workforce execution #188).
• Arbitrary shell authority.
• Reusing PR feat: implement project verification goals and proof runs (#187) #331 as the implementation base.

Implementation Scope

Large - expected as 3-5 small PRs: run contract/persistence; preflight+confined runner; outcome/evidence/reliability; recovery/API; final adversarial regression.

Technical Notes

New implementation branches start from current main. Treat PR #331 as reviewed historical test evidence only. After each schema/runner/recovery checkpoint, perform fresh contract, state, failure, security/privacy, regression and evidence-readiness passes before proceeding.

[Joncallim]

Hostile deterministic-proof addendum — proof execution is untrusted code execution, not a harmless read

A fresh pass found a class of risk not explicit enough in #355: a deterministic verification command can execute arbitrary repository/package code, create files, spawn children, access network/credentials, and mutate caches even though it makes zero model calls. Treat proof execution as a confined Operation with explicit effect/network/environment semantics, not as a trusted shell check.

1. Separate logical proof request from execution attempt/delivery

Use distinct identities:

• proof request — operator/consumer intent to evaluate one exact goal revision against one exact Resource subject;
• proof attempt — one actual confined Operation execution;
• queue/outbox delivery occurrence — transport identity only.

Duplicate delivery of one request does not create a second proof attempt unless recovery semantics require it. Two deliberate operator requests may create two separate proof requests even when their subjects are identical.

Never use (goal_id, resource) alone as a forever-idempotency key that makes a legitimate later rerun disappear.

2. The proof subject is immutable and version-bound

Pin before execution:

• exact verification-goal revision/digest;
• exact Resource/repository identity + commit/tree/content revision;
• Operation definition/version/digest;
• expected assertion/result schema;
• toolchain/runtime/confinement profile revision;
• relevant lock/dependency inputs where the proof claim depends on them;
• policy/Grant/security revision;
• proof-request schema version.

If the working Resource moves after admission, do not silently test the new contents. Use an immutable snapshot/worktree/materialization of the admitted subject or fail/re-admit.

A pass for Resource revision A is not a pass for B.

3. Proof commands run against a read-only authoritative subject plus explicit ephemeral scratch

Default deterministic verification must not modify the authoritative repository/Resource it is verifying.

Confinement should expose:

• subject inputs read-only where technically possible;
• an explicit bounded temporary workspace/cache/output area for build/test artifacts;
• only declared writable paths/capacities;
• no host repository write authority;
• no credential mounts except those explicitly required by a separately classified proof Operation;
• no ambient home/config/socket/device access.

If a proof genuinely requires mutation of a disposable copy, that copy is a separate ephemeral Resource derived from the immutable subject; its writes do not change the subject identity being verified.

A test suite that edits source files, Git config/index/refs, or another authoritative Resource either fails policy or must use a separately declared Operation with reviewed semantics. “Tests usually do not write source” is not a boundary.

4. Network is deny-by-default for deterministic proofs

Many test/build commands can make network calls implicitly (package install, telemetry, update check, integration test, malicious code).

Every proof Operation declares network_requirement per SPEC-0004. Default verification goals should be none/offline where feasible.

When network is required:

• exact destination/credential policy is admitted before run;
• [FEATURE] VNext Phase 1 — deterministic budget, routing, and context economics #335/[FEATURE] VNext Phase 2 — secure generic execution envelope and side-effect recovery #336 egress/confinement rules apply;
• network access is not inherited from the host merely because the proof command needs it;
• proof result/evidence records that the claim was produced with network-dependent inputs and the relevant versions where knowable.

Add a hostile fixture whose “test” attempts outbound network and prove an offline goal blocks it.

5. Command definitions must be closed typed Operations, not shell prose

Do not accept goal/model/user strings that are later passed to sh -c/bash -c as execution authority.

Prefer Operation definitions with validated argv/env/input fields. If shell semantics are genuinely required for a catalogued Operation, the shell script/template is trusted versioned Operation definition content, while goal data supplies only validated parameters.

Reject:

• command substitution/metacharacter injection through data fields;
• arbitrary environment-variable names that can alter loaders/runtime (LD_PRELOAD, NODE_OPTIONS, Git config injection, etc.) unless explicitly allowlisted by the Operation;
• executable path resolution through untrusted working-tree PATH entries unless the Operation intentionally runs project binaries under confinement;
• symlink/path escapes from declared subject/scratch roots.

6. Environment identity/provenance is part of proof comparability

A commit digest alone is not sufficient to compare many deterministic proof results.

Record bounded environment evidence relevant to the goal, e.g.:

• OS/runtime/confinement image/profile digest;
• tool/compiler/runtime versions;
• dependency/lockfile digest or resolved environment identity where applicable;
• Operation version;
• architecture/platform when material;
• approved environment-variable schema revision (not raw secret values).

#186 comparability must reject evidence across incompatible environments when the goal's cohort policy says the difference matters. Do not infer comparability solely because the same goal id was run twice.

7. A process exit code is not automatically the semantic assertion

Each goal/Operation declares how outputs establish passed | failed | inconclusive | blocked.

Examples:

• exit 0 may be sufficient for a catalogued command.exit_status.v1 assertion;
• file/content proof requires the declared output/evidence to exist and validate;
• malformed/missing expected result is inconclusive/runner failure, not pass;
• timeout/kill/infrastructure failure is not assertion failure;
• output parser failure cannot be turned into failure/pass by English matching.

Use typed stable reason codes from the shared SPEC-0007 registry.

8. Authoritative evidence persistence is part of terminal pass

A proof cannot become authoritatively passed if Forge failed to durably store the minimum required result/evidence identity.

Ordering:

1. durable proof request/attempt intent;
2. run confined Operation;
3. validate result/evidence;
4. persist bounded authoritative evidence + canonical outcome atomically enough that recovery can distinguish execution from evidence finalization;
5. only then expose terminal passed.

If the process may have run but evidence finalization fails, recover/reconcile from the Operation journal/retained bounded result where possible; otherwise result is inconclusive/evidence-degraded. Do not manufacture green from Task logs/stdout that happened to appear.

9. Output bounds/redaction must preserve evidence honesty

Do not simply truncate stdout/stderr and then claim a proof passed when the required assertion may lie beyond the retained prefix.

Define separately:

• bounded raw capture allowed inside trusted runner memory/temp storage;
• assertion parser input bound/streaming behavior;
• persisted safe excerpt;
• complete bounded content digest/structured result when needed for evidence;
• redaction policy.

If output exceeds a limit required to determine the assertion, return a stable limit/inconclusive result rather than silently discarding decisive evidence.

A digest of secret-bearing raw output should not become an unkeyed correlation/leak artifact; use existing protected evidence patterns/domain-separated keyed digest where necessary, while persisting only sanitized evidence.

10. Kill the entire process tree and fence late output

Timeout/cancel/revoke/lease-loss handling must cover child/grandchild processes, not only the direct command PID.

After cancellation/fence:

• no child continues consuming CPU/network/disk;
• stale process output cannot finalize the proof;
• late filesystem writes are confined to disposable scratch;
• stale worker cannot overwrite a newer attempt/current projection.

Use #336's actual confinement/process-control proof; do not recreate a weaker local child-process wrapper in #355.

11. last-known-green / first-observed-failing projections need deterministic ordering

Concurrent/out-of-order attempts can complete in the opposite order they were requested. A slow old run must not overwrite the current projection merely because it finished last.

Projection ordering must bind at least exact subject Resource revision + goal revision + authoritative proof-request/attempt generation according to defined semantics.

For a moving repository, report “green for revision X” rather than a timeless green flag. The current projection advances only when policy says the observed subject is at least as current as the existing projection.

Old immutable runs remain queryable; projections are rebuildable from their explicit ordering rules.

12. Evidence from a proof that itself changes the subject is non-comparable unless explicitly modelled

Detect whether the proof changed authoritative subject state where that should be impossible (Git diff/index/ref, file digest, database/resource revision). Such a violation is a security/confinement failure and the proof cannot count as verified evidence.

This is especially important before #337 runs verification against the same repository.

13. Hostile fixture expansion

Add:

• project test tries to edit source/Git ref -> blocked or confined to disposable copy;
• test tries network/metadata service -> blocked for offline goal;
• test spawns daemon/grandchild then timeout -> entire tree terminated;
• malicious env value attempts loader/Git config injection -> rejected;
• shell metacharacters in goal parameter -> data, not command execution;
• process exits 0 but required result file/schema missing -> not pass;
• enormous stdout with decisive assertion after bound -> explicit output-limit/inconclusive, not pass;
• evidence DB write fails after successful command -> no authoritative green;
• two same-subject deliberate proof requests -> distinct requests; duplicated delivery -> no duplicate attempt;
• old revision A finishes after newer B -> projection remains correctly revision-scoped;
• same goal/resource under incompatible runtime/toolchain -> [FEATURE] Add capability reliability ledger #186 comparability rejects it;
• proof mutates subject unexpectedly -> verification evidence rejected/security finding.

The strengthened invariant is:

A deterministic proof is trustworthy because Forge controls its exact subject, Operation, environment, effects and evidence—not merely because no LLM was involved.

[Joncallim]

Architecture reconciliation — registry compatibility and proof semantics

Reviewed 1 October 2026 against current main e9d1129ccf0699e41cc1625eeb9cdd62186147c6, ADR 0013, goal contracts, and the existing hostile proof addendum. Source/architecture review only; no proof command was executed.

Reconcile the plan with the merged registry

The existing addendum's confinement, evidence, output-bound and recovery requirements remain valid. Two current v1 restrictions must survive the runner:

• Goal references have exactly operationId and operationVersion. The parser rejects catalogued Operations with nonempty inputKeys. The addendum's discussion of validated argv/parameters is future Operation design guidance, not permission to add arbitrary inputs to current goal JSON or smuggle them through the run endpoint. Bind repository/Resource context through the trusted generic runtime contract. If a new input-bearing goal format is necessary, make it an explicit versioned schema/migration decision first.
• Operation references are canonically sorted by ID/version and duplicates rejected. Their source-array order therefore cannot express a setup→assertion pipeline. Do not make sorted name order into hidden business semantics. Keep v1 members independent under the reviewed contract; dependent multi-step proofs require an explicit trusted composite Operation or a separately reviewed workflow contract, not incidental iteration order.

Remaining runner decisions

1. Registry membership, not just snapshot existence. The merged store retains removed and superseded goal snapshots. At admission, bind the current registry revision and prove exact current membership/enabled state alongside the goal digest. A historical snapshot lookup alone must not revive a removed goal. Define separately what happens if the registry changes after the run is admitted: preserve historical results against the pinned revision, while current-run admission/cancellation follows the declared policy. Never silently replace the admitted definition.
2. Multiple Operations need a total aggregation rule. Every required member gets a typed outcome and evidence reference. An unrun member is not success; fail-fast must record why remaining members did not run. Define assertion failure versus infrastructure/policy block precedence without collapsing the member-level facts. All-required assertions must actually be established before the goal is green. Do not use the last process exit code as the whole goal result.
3. Deterministic execution is not guaranteed reproducibility. Tests may depend on time, random seeds, external services or flaky scheduling. Record relevant seed/clock/environment inputs where the Operation can control them, and declare residual nondeterminism. Retrying until one pass appears cannot erase earlier failures or inflate reliability. Repeated samples and recovery retries need distinct, bounded semantics and [FEATURE] Add capability reliability ledger #186 cohort treatment.
4. Prove the intended assertion, not merely the worker's script. A catalogued exit-status goal may legitimately attest only to that exact command's exit status. It must not be presented as broader behavioural coverage. If the required criterion is independent acceptance, bind protected proof definitions/fixtures rather than trusting a candidate that removes its tests or substitutes exit 0. This distinction belongs in evidence and operator wording.
5. Keep trust ownership explicit. The runner captures process/limit/evidence facts; untrusted repository output cannot author those facts. Required structured-result files need bounded no-follow reads from the admitted scratch Resource, exact schema validation and provenance. Missing or replaced files cannot become green because a log line says “passed.”
6. Recovery reuses shared mechanisms. Consume [BUG][P0] Make Postgres-to-Redis wakeups durable, idempotent, and recoverable #347 durable delivery and [FEATURE] VNext Phase 2 — secure generic execution envelope and side-effect recovery #336 Operation uncertainty/fencing. “No model calls” does not make a potentially side-effecting proof safe to replay. Preserve the existing request/attempt/delivery distinction; do not build a second process supervisor or scheduler here.

Additional acceptance cases

• Removed goal snapshot still exists: a fresh run request cannot bypass current registry membership.
• Registry head advances between UI selection and admission: stale selection fails/reconciles explicitly.
• Reordering v1 source references cannot change proof semantics.
• One member passes and another is skipped, malformed or blocked: goal cannot silently pass.
• Candidate changes a test to unconditional success: evidence is no stronger than the admitted proof definition, and protected criteria remain unproven.
• Flaky first failure followed by success: immutable history and reliability sample counts remain honest.
• Output file is replaced/symlinked after process exit: safe evidence capture refuses the substituted result.
• Zero model invocations are asserted at the transport boundary; no hidden “repair” call occurs after a proof fails.

Delivery / dependency boundary

Start from the merged registry, preserve its import/revision tests, then add run admission/aggregation and the confined runner under #336. #188 remains parallel, #337 integrates the two, and #356/#341 own scheduling. PR #331 is historical requirement/test evidence only. The issue remains blocked until its declared prerequisite is satisfied; this review does not close it or launch implementation.