[Feature]: Persistent Goal orchestration with evidence-gated completion

Description

I would like upstream feedback on a narrower successor to #465: a durable, per-session Goal whose completion is gated by explicit verification evidence.

The problem is that TODO state, completed subtasks, and assistant prose are useful progress signals, but they are not reliable proof that a user objective has been satisfied. A Goal would remain authoritative across turns and plugin restarts, coordinate work through the existing specialist system, and complete only when its required criteria have valid evidence.

Proposed V1 user experience

• Expose Goal as a selectable primary agent.
• The first eligible user message creates a Goal when the session has none.
• Support /goal <objective>, status, pause, resume, revise, and clear.
• Reuse the existing task system, canonical reconciliation, wake scheduler, permissions, and wait_for_user behavior.
• Provide status through the command surface; a localhost read-only panel can remain optional.

Completion and safety contract

• There is no manual "complete" command.
• Each required criterion receives a persisted verifier assignment.
• Evidence counts only after that exact assigned task completes and is canonically reconciled.
• Goal identity, revision, session generation, board-run identity, task identity, and task generation fence stale or reused results.
• Malformed, duplicate, mismatched, failed, cancelled, superseded, stale, or unassigned results fail closed and leave the Goal incomplete.
• Pausing and user/permission/manual-action waits suppress new Goal work. Terminal facts from already-launched tasks can still be reconciled safely.

Difference from #465

This is not another independent continuation loop with a manual completion command or only a cycle counter. It reuses OMOS's existing wake and task reconciliation infrastructure, adds strict persistence validation and generation/revision fencing, and treats separately assigned verifier evidence as the completion authority.

The intent is to address the safety concerns identified on #465, including malformed persisted state, timer races, and paused Goals continuing work.

Initial scope

• V1 only. The current V2 bridge does not expose all provenance and wake contracts needed for equivalent behavior.
• No request to merge an independent fork wholesale.
• No replacement for BackgroundJobBoard, existing reconciliation, Deepwork, Loop, or TODO behavior.
• No budgets, multi-Goal portfolio, generalized workflow engine, or native Desktop status card.

A standalone companion plugin is not currently a safe boundary because Goal needs canonical board generations, execution ownership, wake arbitration, cache-safe context composition, user-message provenance, and session disposal from the core plugin runtime.

Reference implementation

• Repository: https://github.com/userbox020/opencode-goal-orchestration-plugin
• Source preview: https://github.com/userbox020/opencode-goal-orchestration-plugin/releases/tag/v0.1.0-preview.0
• Runtime contract: https://github.com/userbox020/opencode-goal-orchestration-plugin/blob/main/docs/goal.md

The reference is based on upstream v2.2.17 and remains independently maintained. It is not presented as a ready-to-merge branch.

Local validation includes typechecking, a clean build, 441 targeted Goal/task/ wake/reconciliation tests, packaged import checks, an OpenCode 1.18.13 host smoke, and a packaged workflow fixture covering automatic creation, worker and verifier tasks, canonical reconciliation, completion, and an authenticated panel snapshot. This establishes a V1 reference, not universal host or model compatibility.

Would upstream be interested in reviewing this incrementally, beginning with the isolated Goal lifecycle, persistence, and fail-closed verification contract? If not, feedback on the desired boundary or missing extension points would still help keep the independent implementation aligned.

Extra context

• Prior durable Goal attempt: #465
• Earlier continuation safety discussion: #147
• Existing todo continuation foundation: #248

If the direction is welcome, any implementation would be prepared separately from a current upstream-derived branch and split into reviewable stages. Work on the independent fork would continue regardless of upstream acceptance.