GUI: /goal saves the objective but does not start working immediately #181

Summary

Entering /goal <objective> in the GUI persists the standing goal but returns without starting an agent turn. The product expectation is that /goal should begin working on the goal immediately, so the UI appears to pause after printing “Goal set.”

Reproduction

1. In the GUI composer, enter a substantive goal, e.g. /goal do multiple simulations acting as different users and report back with possible improvements. file any bugs as issues ultracode.
2. Submit it.
3. Observe the confirmation:
   • Goal set: ...
   • I'll track it as a live checklist (todo_write) and work through it across turns.
4. Observe that no model turn or tool activity starts until another ordinary user message is submitted.

Expected

/goal <objective> should atomically:

1. persist the standing goal;
2. create exactly one executable user turn for the objective;
3. submit it immediately;
4. show queued/running state; and
5. avoid duplicate execution on retries or repeated UI events.

If save-only behavior is retained for some reason, the command must explicitly say that no work has started and provide a Start goal action. The current confirmation implies active work and is misleading.

Actual / root cause

The recognized GUI command is save-only:

• gui/src-tauri/src/runtime/simple.rs:1312-1354 stores conversation.goal, persists it, refreshes the snapshot, and returns a command result. It never enqueues a prompt or invokes the model.
• gui/src/components/PromptComposer.tsx:80-85 returns after trySubmitAsCommand(promptDraft) succeeds, so normal submitPrompt() is skipped.

The confirmation around simple.rs:1341-1343 says the goal will be tracked and worked through, despite no execution being started.

Trajectory evidence

The session trace does not show a run beginning and then pausing. It shows no executable model turn from /goal. On the next ordinary user prompt, the standing-goal steering was appended and execution began immediately:

• ordinary prompt event: t=32,031 ms
• WebSocket connecting: t=32,032 ms (+1 ms)
• WebSocket connected: t=32,707 ms
• first API result: t=37,436 ms, no error

Persisted sessions with a non-null goal and empty message history further confirm that goal persistence is currently independent from executable-turn creation.

User-impact simulations

• New user: Reads “Goal set” / “I'll ... work through it” as confirmation that work started, then assumes the agent stalled.
• Power user: Expects a command with an objective to execute immediately and must send a meaningless follow-up to trigger it.
• Automation user: Cannot rely on /goal as a one-shot command; workflows silently remain idle and may execute later under the wrong follow-up context.

Acceptance criteria

• Submitting /goal <objective> starts one and only one agent run without a second user message.
• The run uses the newly persisted standing goal and ultracode steering when present.
• UI state changes from command acknowledgment to queued/running.
• Retries/reconnects do not duplicate the first goal run.
• /goal with a missing objective still shows usage and does not run.
• Setting or replacing a goal while another run is active has defined, tested behavior.

Related issues checked

No exact duplicate found. #178 concerns standing-goal injection/state lifecycle and false ultracode activation, rather than /goal failing to start work. #62, #79, and #100 are related architectural/UX precedents but not duplicates.