diff --git a/docs/briefings/clide-team-mode-friction.md b/docs/briefings/clide-team-mode-friction.md new file mode 100644 index 000000000..7e30f01d3 --- /dev/null +++ b/docs/briefings/clide-team-mode-friction.md @@ -0,0 +1,85 @@ +--- +title: "clide friction log — for the clide team" +description: "Observed friction + improvement notes while driving clide as the Settled Reach IDE, esp. the untested team-mode UI. Hand-off material for the clide team." +type: briefing +status: active +created: 2026-06-07 +tags: [clide, ide, team-mode, friction, feedback] +--- + +# clide friction log — for the clide team + +Running notes on where clide helps and where it creaks, captured live while using it as the +Settled Reach IDE. Intended as hand-off material for the clide team (the `projects/clide` repo). +Each item: **what**, **impact**, **suggested fix**. + +## Already observed (pre team-mode) + +1. **Diff view is working-tree only — no committed/branch-vs-main diff.** `clide ui open diff ` + and `clide git diff` show only uncommitted changes; there's no verb to view a *committed* + branch-vs-`main` diff. So for reviewing an already-committed PR, the diff view is empty. + *Impact:* can't "look at a PR diff with the user" in clide — had to fall back to /pr-review. + *Fix:* a `clide ui open diff --base main` (or `clide git diff --range main...HEAD`) that + renders a committed range diff in the diff tab. This is the single biggest gap found so far. + +2. **`capabilities` is excellent.** Live dispatcher registry, never drifts — exactly the right + discovery primitive. Keep it; consider linking it from `clide --help`'s top usage line. + +3. **`ui toast` + `ui open` + `status` parity works well.** `shown:true`/`opened:true` returns are + clear; `status` gives a clean one-shot orientation (panes/git/editor/readers). + +## Team-mode UI (under test — 2026-06-07) + +Context: lead is inside tmux (`TMUX` set), `teammateMode: auto`, so teammates spawn as tmux panes +clide is expected to render. This is the untested surface. Observations appended below as the +Q-101 workshop runs. + +### FINDING T1 — clide UI does not reflect team mode (HEADLINE) — 2026-06-07 + +**What.** Ran a real team (`TeamCreate` + an Agent teammate `Tyre`, `teammateMode: auto`, lead in +tmux) to run a design workshop. The **work layer functioned perfectly** — Tyre spawned, read the +brief, and wrote a 16 KB `tyre-round1.md`; task-list + file + message coordination all worked. But +**clide's UI never reflected any of it** (user-reported: "both the team-mode side-panel pane and the +clide renders are not responding to team mode"). + +**Diagnostics.** +- clide has a `claude.team-chat` view (`visible:true`) but it sits `active:false` and shows no + teammate activity — the scaffold exists, the wiring doesn't. +- Teammates spawn as **separate tmux sessions** (observed: 27 sessions vs the lead's session `25`). + clide does not adopt/render those sessions — `clide pane list`/`status` enumerate only clide's own + Flutter views, never the teammate panes. +- `clide capabilities` exposes **no `team`/`agent`/`chat` subsystem** — there's no CLI verb to + observe team state, list members, or read the team chat. (Confirmed against the live registry.) + +**Impact.** Team mode is effectively invisible inside clide: the user can't watch teammates, read the +team chat, or see per-teammate progress. The lead can only observe via Claude-side tools (`TaskList`, +`SendMessage`, reading output files) — none of which surface in clide. For a multi-agent workshop this +removes the entire point of the IDE's team UI. + +**Suggested fixes (for the clide team).** +1. **Wire `claude.team-chat` to the live message bus** — subscribe to the same team mailbox the + lead/teammates use so DMs + broadcasts render in the Team Chat view as they happen. +2. **Adopt teammate tmux sessions into clide's pane model** — when a teammate spawns (separate tmux + session), surface it as a clide pane/tab (one per teammate) so the user can watch each one; + enumerate them in `clide pane list` with `source: team`. +3. **Add a `clide team` subsystem** — `team list` (members + status), `team chat [--tail]`, + `team focus ` (open that teammate's pane). Parity: the lead drives team mode via Claude + tools; clide should *observe* it, per the D-6 contract. +4. Until then, a smaller stopgap: have the Team Chat view at least show "team active: N members" + + the task-list state, so the user knows team mode is live even without full rendering. + +**Refinement — the teammate ran `in-process`, not a tmux pane.** Tyre's shutdown ack reported +`backendType: in-process`, `paneId: in-process`. So under `teammateMode: auto` inside clide the +teammate took the **in-process fallback** rather than spawning a tmux split — which means there was +*no pane for clide to adopt or render in the first place*. (The 27-vs-25 tmux session delta seen +earlier is unrelated background sessions, not this teammate.) This sharpens the fix: +- The likely root cause is the **auto → in-process fallback firing inside clide** (clide's PTY/tmux + env isn't detected as splittable), so team mode degrades to invisible in-process agents. +- Fix options for the clide team: (a) make clide a first-class `teammateMode: tmux` host so teammates + spawn as adoptable panes; **and/or** (b) render *in-process* teammates too — subscribe the + `claude.team-chat` view to the in-process team mailbox so even fallback teammates are visible. (b) + is the more robust fix since in-process will always be a possible backend. + +**Workaround taken this session.** Kept Tyre's delivered round-1; ran the rest of the Q-101 workshop +as **background Agent subagents** (the Si/reviewer pattern), which DO surface in clide's normal Claude +activity flow — i.e. avoid `teammateMode` teammates until the team-chat view is wired to the mailbox.