[Bug] /ultraplan terminal-to-cloud signaling unreliable, lacks state validation

Bug Description
/ultraplan terminal-to-cloud signaling is unreliable.

Workflow: invoked /ultraplan from a Claude Code CLI session (v2.1.128). Terminal output
showed "ultraplan ready · <session-url>" at invocation. Some minutes later, the terminal
session received what appeared to be a notification that the plan was generated and
waiting for approval. The orchestrator (Claude in the terminal) relayed this to me.

When I went to the cloud session URL, no plan was visible. I checked GitHub — no PR,
no remote branch, no events from the cloud session. The "plan ready" signal was either
premature or wrong.

Two distinct usability issues here:

1. The word "ready" is overloaded. "ultraplan ready" at invocation appears to mean

"session is set up" but reads as "plan output is ready". A reader interpreting
from the terminal output alone gets the wrong mental model.

1. Whatever signal told the terminal-side orchestrator that the plan was approvable was

not validated against actual cloud-session state. There's no way for a terminal-side
user to verify the signal short of opening the web UI and looking. If the UI shows
nothing, the user has no way to know whether the cloud session is still working,
silently failed, or sent a false signal.

Impact: terminal-side users can't trust /ultraplan progress signaling. The web UI
becomes the only reliable source of state, which defeats one of the stated benefits
("you can continue to work while the plan is generated remotely") because you have to
keep manually polling the UI.

Suggested fix: either (a) make the terminal-side signaling actually reflect cloud-side
state, or (b) reduce signaling claims to "session created" / "session URL active" and
let the web UI carry all status communication unambiguously.

Environment: Claude Code CLI v2.1.128, /ultraplan research preview, macOS, Pro
subscription. Repo on GitHub. Session URL: <pasted at submission time>.

Environment Info

• Platform: darwin
• Terminal: ghostty
• Version: 2.1.128
• Feedback ID: 0ff87255-0159-4987-beda-5e2e900fe8fb

Errors

[{"error":"MaxFileReadTokenExceededError: [REDACTED] content (26837 tokens) exceeds maximum allowed tokens (25000). Use offset and limit parameters to read specific portions of the file, or search for specific content instead of reading the whole file.\n    at FF7 (/$bunfs/root/src/entrypoints/cli.js:4860:12894)\n    at processTicksAndRejections (native:7:39)","timestamp":"2026-05-06T21:51:26.289Z"},{"error":"MaxFileReadTokenExceededError: [REDACTED] content (31801 tokens) exceeds maximum allowed tokens (25000). Use offset and limit parameters to read specific portions of the file, or search for specific content instead of reading the whole file.\n    at FF7 (/$bunfs/root/src/entrypoints/cli.js:4860:12894)\n    at processTicksAndRejections (native:7:39)","timestamp":"2026-05-06T22:51:50.921Z"},{"error":"AxiosError: Request failed with status code 404\n    at Di (/$bunfs/root/src/entrypoints/cli.js:115:1194)\n    at <anonymous> (/$bunfs/root/src/entrypoints/cli.js:120:12710)\n    at emit (node:events:92:22)\n    at endReadableNT (internal:streams/readable:865:50)\n    at processTicksAndRejections (native:7:39)\n    at request (/$bunfs/root/src/entrypoints/cli.js:122:2467)\n    at processTicksAndRejections (native:7:39)","timestamp":"2026-05-06T22:58:24.103Z"},{"error":"AxiosError: Request failed with status code 404\n    at Di (/$bunfs/root/src/entrypoints/cli.js:115:1194)\n    at <anonymous> (/$bunfs/root/src/entrypoints/cli.js:120:12710)\n    at emit (node:events:92:22)\n    at endReadableNT (internal:streams/readable:865:50)\n    at processTicksAndRejections (native:7:39)\n    at request (/$bunfs/root/src/entrypoints/cli.js:122:2467)\n    at processTicksAndRejections (native:7:39)","timestamp":"2026-05-06T22:58:35.114Z"}]