Goal judges: let a second model confirm a /goal is met

[M0xoo]

/goal hands "done" to the same agent that did the work. With Codex and Claude, the provider reports the goal complete when the agent judges it met (OrchestrationV2ProviderGoal.status), and T3 takes its word for it. When an agent is wrong about its own work, which happens with long goals, the thread shows the goal as met and settles like any finished work.

For example. /goal all tests in packages/api pass: an agent that skips two flaky tests and reruns the suite can report the goal met, and nothing in the thread says otherwise until CI fails.

Proposal: an optional judge for a goal.

• When setting a goal you can pick a judge: any installed provider instance and model, like the model picker. A default goes in Settings → Chat (Off by default, so nothing changes unless you choose one).
• When the provider reports the goal complete, T3 starts a read-only check in the same workspace: the judge gets the goal text and the thread's diff since the goal was set, can read files and run read-only commands, and answers met or not yet with a short reason.
• Met: the goal stays complete and the goal line shows "Confirmed by " with the reason.
• Not yet: T3 sets the goal again and sends the judge's reason to the agent as the next message, marked as coming from the judge. The goal line shows "Sent back by ".
• To keep it from looping: if the judge sends the goal back twice for the same reason with no new changes, the goal stops as blocked and asks you.

Why another model. A different model (or provider) does not share the agent's blind spots, and a cheap one is enough for a read-only check. In my own tool (wisp, open source), goals work this way: a separate read-only check decides "done", optionally with several judges that vote. Most of the value came from one judge on a different model than the agent.

Scope for a first PR: one judge per goal, web and desktop first, Codex and Claude goals (the two providers with native /goal). Mobile shows the judge's verdict on the goal line and gets the picker later. Several judges with a vote could come later if this proves useful.

Questions for maintainers before I build anything:

1. Would you accept a T3-level check on top of the provider's native goal, or should this wait for a T3-owned goal loop?
2. Is the side-chat machinery (a read-only fork in the same folder) the right base for the judge run, or would you rather it be a delegate_task-style child?