feat(code): move /goal criteria generation server-side

[Mason Daugherty (mdrxy)]

/goal acceptance-criteria drafting now runs on the agent server and can use conversation, repository, web, and explicitly read-only configured MCP context while preserving resumable review state.

---

Previously, /goal proposals were drafted in the client process from the explicit objective, so remote or sandbox repository context and references to the current conversation were unavailable. This moves proposal and amendment drafting into a nested agent in the main server graph, where it can use recent conversation context, bounded read-only repository search, fetch_url, optional web search, and configured MCP tools explicitly annotated as read-only.

Repository context remains read-only and repository-rooted across backends: local reads use a virtual project root, while sandbox reads are constrained to the provider's declared working directory, including canonical-path checks that reject symlink escapes.

Proposals are stored as pending checkpoint state rather than chat messages, so review survives remote interrupts and resumes without polluting the coding conversation. Each proposal is correlated with its originating request, and criteria requests are cleared after success, failure, or cancellation without clearing newer requests. Cancelling criteria generation stops the server run without adding normal chat-interruption messages. The client refreshes checkpoint state after generation and reuses the existing accept, edit, and reject flow; model profile overrides now cross the client/server boundary consistently.

[open-swe]

Open SWE Review found 1 potential issue.

Open in Web • View Open SWE trace

[Mason Daugherty (mdrxy)]

Future direction, not a blocker for this PR: if dcode adds more server-side operations like /offload, consider extracting these non-chat workflows behind a small, explicit operations protocol rather than adding more command channels to the main conversation graph.

That could be a separate operations graph using the standard LangGraph run APIs, with a versioned request/result envelope containing an operation ID, source conversation thread ID, operation type, payload, status, result, and error. Each operation would run on its own thread/run, so results and cancellation are correlated without using chat messages or conversation-state fields as transport. The operations graph and agent graph could share the same cached model, repository/sandbox backend, MCP sessions, and tool policy.

The criteria agent introduced here should remain reusable in that design; only its transport and lifecycle ownership would move. I would wait until there is a second operation that needs the abstraction rather than generalizing prematurely.

[Mason Daugherty (mdrxy)]

Follow-up to the future direction above: /offload is already the concrete second server-side operation that would justify this refactor.

Today the Textual client synthesizes a compact_conversation tool call, updates thread state, approves the resulting interrupt, drains the run, and handles reconciliation and cleanup. A follow-up should move that lifecycle behind the same kind of typed, server-owned operation boundary: the client submits an offload request through the normal server API, the server performs compaction and persists the result, and the client only renders the outcome.

That would give us the second real use case needed to design the shared operations protocol around observed requirements rather than generalizing this PR prematurely. Still not a blocker or scope expansion for this PR; /offload should be the next migration that drives the abstraction.