Feature request: Executable completion criterion for goal mode

Feature request: Executable completion criterion for goal mode

Context

Goal mode accepts a textual completionCriterion, but the criterion is never executed: the agent decides on its own when to call UpdateGoal(complete). Completion is therefore a self-declaration by the model, not a mechanical check.

The local usage culture (AGENTS.md) requires "NEVER cheat the verifier" and an "observable proof" for every task — currently these rules are disciplinary (the agent is asked to provide proofs), not mechanical (the runtime verifies nothing).

Concrete use case (2026-08-29): the goal "rebase deepseek-harness" was completed with manually gathered proofs (139/139 tests, typecheck). Those proofs could have been declared as executable checks at goal creation time and validated by the runtime instead of relying on the agent's goodwill.

Problem or Gap

There is no way to attach an executable success criterion to a goal. The completionCriterion string informs the agent's judgment but is never run by the runtime, so nothing prevents a goal from being marked complete while its verification has not passed.

Proposal

1. Optional executable syntax for completionCriterion:

   "completionCriterion": { "run": "cmd", "expect_exit": 0 }
   

   or a list of such checks (each check = command + expected result). The current textual form remains valid (backward compatible).
2. Runtime-enforced completion: when the agent calls UpdateGoal(complete) on a goal carrying checks, the runtime executes the checks itself; completion is accepted only if all checks pass.
3. Raw output attached: the completion summary embeds the raw output of each check (not just the exit code), keeping the proof inspectable.

Impact

• Integrity: goals can no longer be declared complete while their verification fails — the verifier becomes mechanical, not disciplinary.
• Auditability: completion summaries carry raw check output, usable as evidence.
• Adoption: the textual form stays valid, so existing goals keep working.

Acceptance criteria

1. A goal with checks cannot be marked complete while a check fails (exit code ≠ expected).
2. When all checks pass, complete is accepted and each check's raw output appears in the completion summary.
3. A goal without executable checks behaves exactly as today (backward compatibility).
4. A failing check is reported back to the agent with its raw output so it can correct the situation.
5. A check command that crashes or times out reports the failure with partial output; the goal is not completed and the runtime does not crash.
6. A malformed executable criterion (empty command, missing field) is rejected at goal creation.
7. Checks run with the same permissions as a standard shell tool call in the session — no implicit privilege elevation.

No specific files or tests are named. Start by tracing goal creation and the UpdateGoal(complete) handling, then inspect AGENTS.md and the existing standard shell tool execution path. Done means executable criteria are validated with output, failures are reported safely, malformed criteria are rejected, and textual criteria remain backward compatible.