Status: APPROVED by orchestrator — decomposed into phase tickets. Epic: MC-3754. Date: 2026-05-19. Not the rejected 2026-04-20 plan: this is a front-end layout/routing shift — no tmux changes, no xterm.js, no worktree rearchitecture, no new runtimes.
GET / → dashboard() renders a status dashboard: KPI strip, then session_composer.html (chat is a 320px display:none widget mid-page), then runtime/team/health panels. The board (/board) is the primary work surface. WAT actions live in the Workbench [Tools] drawer — the user drives WAT routing manually. MC-3718 already wired the chat plumbing: composer plan mode → persistent_luci/send+harvest; MC-3722 added the mc-proposal card protocol. Missing: chat is secondary, no orchestrator-driven WAT, no thread concept.
Promote chat to the landing shell. GET / becomes a full-viewport chat: compact status bar at top, chat log filling the viewport, composer pinned bottom. Board/Workbench/Tickets stay fully functional as secondary views via bottom-nav tabs + inline action cards. Keeps URL contracts; backend plumbing (send/harvest, mc-proposal) unchanged.
Orchestrator owns WAT. The orchestrator decides each turn's outcome and emits structured blocks: mc-proposal (ticket cards — shipped) and new mc-action (action cards — run-now / send-to-Larry / open-workbench / answered). User approves inline in the thread; does not drive WAT separately.
Multi-session — Option A (recommended): ONE luci-persistent runtime + a chat_threads table. Each message is prefixed with a thread context tag; per-thread harvest cursor. Turns are sequential (one in-flight) — honest for a single-operator/single-runtime system; UI shows a "Thread X active" toast. Rejected: Option B (multiple runtimes — CCGram 409 risk), Option C (threads-as-tickets — defeats the paradigm).
Layout: desktop = 240px left thread-list rail + chat shell; mobile = [≡] header sheet for threads, chat fills viewport, bottom nav unchanged.
Phase 1 — full-screen chat shell at /. Restructure dashboard.html: chat primary, KPI strip → compact status bar, other panels behind a Settings sheet / More tab. #session-chat-panel visible by default, fills viewport. Composer default mode → plan. New .mc-chat-shell CSS. No route/backend change. Bump ASSET_VERSION + CACHE_NAME. (Supersedes MC-3753 dashboard-viewport fix.)
Phase 2 — thread list + persistence. New tables chat_threads (id, title, created_at, last_message_at, harvest_offset, last_turn_marker, archived) + chat_thread_messages (thread_id, role, content, proposals, actions, created_at). 6 APIs: list/create threads, thread messages, send (prefixes thread context tag), harvest, patch. Desktop left-rail thread list; mobile [≡] sheet. telegram-default system thread for plain Telegram chat. Sequential-turn toast.
Phase 3 — WAT inline action cards. New mc-action fenced-block protocol (analogous to mc-proposal): parseMcActions() strips + renders action cards (run_now → session_start implement_now; send_to_larry → quick_ticket assigned Larry; open_workbench → link; answered → done chip). Document the protocol in CLAUDE.md orchestrator section.
Phase 4 — board/workbench as inline secondary panels (OPTIONAL). Desktop only: resizable right panel slides in board/workbench via HTMX partial load. Mobile unchanged. Pure view-layer — no tmux/xterm.
telegram-default thread maps to the same runtime; zero new polling.mc_regression.sh + mc_doctor.py, ASSET_VERSION/CACHE_NAME bump. Phase 2 also needs a DB migration test.4 phases. Recommended: chat shell at /, board/workbench demoted to secondary, orchestrator emits mc-proposal + mc-action cards, single-runtime multi-thread (Option A). Front-end paradigm shift only — no new runtime infra.