Roadmap clarification: will standalone TUI move to app-server-backed runtime for multi-client live sync? #11958
Description
Request
Could the team clarify the roadmap for TUI architecture:
- Is the standalone TUI expected to migrate to an app-server-backed runtime?
- If yes, is that a near-term or long-term direction?
- If no, what is the intended long-term model for cross-client live sync?
Why this matters
Right now, users can share a threadId across processes, but live sync is process-local unless clients share the same app-server runtime. In practice this causes confusion:
- TUI in one process + app-server in another process do not share live in-memory turn events.
- Sync is eventual via rollout/resume/read, not true real-time multi-client state.
- Users building custom clients need to know which architecture to target.
What would help
A short guidance note in docs would unblock design decisions:
- Recommended architecture for true multi-client live sync (today).
- Whether TUI-over-app-server is an intended destination.
- If there are planned APIs for cross-process sync/refresh (or if that is explicitly out of scope).
Context
I found app-server transport progress (e.g. websocket support in #10693) and related sync issues, but no explicit roadmap statement tying this to standalone TUI direction.