eleven / messenger Public

Slash commands + app-thread Views (opt-in chat view) (#176)

* web: fix nested scroll + phantom scrollbar in the pickers

The new-chat / add-people sheet had two nested vertical scroll containers (the sheet AND .pick-list both scrolled) plus a stray horizontal scrollbar (overflow-y:auto silently promotes overflow-x to auto, so a sub-pixel overflow rendered a bar). Make picker sheets a clipped flex column so the head + search stay pinned and only the list scrolls — one clean scroll region. Scoped via :has(.pick-list) so other modals are untouched.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

* web: merge Apps into the picker's one grouped scroll list

Apps were a pinned footer below the scrolling people/helpers list. Move them into the same .pick-list as a third group (People / Helpers / Apps) so all three scroll together under the pinned search. Search now spans all groups (relabelled 'Search people' -> 'Search'). Apps aren't roster members: tapping one still opens its personal app-thread via resolveAppThread, not createThread.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

* docs: capture the commands & mini-apps design bar in CLAUDE.md

Familiar-before-novel (Slack/Discord conventions); a command invokes a response in place (bot reply, public or private) and never navigates or mutates the UI as a side effect — moving out of context is an action chip; apps live alongside the chat, not instead of it; delight (pre-baked UI or AI expressiveness) rides on top of the familiar basics.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

* web: slash-command layer — / typeahead, private replies, invalid handling

Builds the command experience on the existing registry (defineApp commands): a leading '/' opens a typeahead of all registered commands (name + description); a command answers IN PLACE with a private 'only visible to you' reply (buildLocalNotice — a client-only feed row, never sent, gone on reload), attributed to the app (To-do) or, for an unknown '/foo', to Eleven; a failed command is answered, never broadcast. /todo and /remind now confirm with a reply + a 'View …' action chip (navigating is the user's tap, never the command's side effect — see CLAUDE.md).

Registry: commands normalize to {run,desc,args}; parseCommand returns {name,args,app|null} so unknown '/word' is caught; commandCatalog() feeds the typeahead. ui.js composerToken gains a start-anchored 'command' token. Both composers pass a feed-aware respond(); the chat app renders replies in a dedicated .chatapp-notices strip (its feed is a keyedList container). Tests updated for the new parseCommand shape + composerToken '/' cases.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

* web: typing-indicator fixes + Slack-style /remind parsing

Typing: (1) the chat app showed your OWN typing in any thread where you'd not yet sent a message — it derived your name from message history (null when empty), so the name-based self-filter missed you; drop your own relay echo by uid in the ephemeral hook instead. (2) A '/command' in progress no longer emits a typing beat (it's private), in both composers.

Remind: parseReminder now accepts Slack phrasing — a leading 'me', and a front-loaded time with 'to' ("/remind me in 10 seconds to do a thing"), alongside the existing trailing forms. 'meeting' isn't mistaken for the 'me' keyword.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

* web: app-thread Views (Chat default / Interface) + reminder-as-DM + dismissable notices

Change 3: an app-thread is now a DM with its bot. It opens in the CHAT view by default (its events render as bot bubbles via a new per-app chatMessage() hook) with a header [Chat | Interface] toggle to its interactive UI. Both views fold live from one event log. Reminders: the fire arrives as 'You asked me to remind you: X' (a message, not a toast — notify hook dropped; sidebar unread + push still cover you when elsewhere); setting one confirms in the same thread.

'Views' is the model: Chat is always the default view; apps add the Interface view; more (custom, per-thread) are planned via a view dropdown. Routing via renderAppFor(id); app events fold into BOTH the owner app (Interface) and a bot bubble (Chat) on open and live.

Local notices (command replies) gain a dismiss ✕ with a radial countdown ring, auto-dismiss after a read-scaled delay (paused on hover/focus, in step with the ring), and an sr-only 'dismisses in N seconds' announcement (never shown on screen).

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

* docs: capture the Views model (Chat default / Interface / future view picker)

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

* web+agent: register the bot's commands with the client so /help etc. reach the bot

The client's unknown-command catch was swallowing Eleven's bot commands (/help, /theme, /dark, /light, /profile, /themes) before they reached the bot — a regression from the command layer. Fix: one shared source of truth, web/static/bot-commands.js (names + help), imported by BOTH the sidecar (agent/commands.mjs attaches each run()) and the client (apps.js). The client now SENDS a known bot command (runCommand returns false → the composer posts it, the bot answers) and lists them in the / typeahead — gated to threads that actually have a bot (chat.js threadHasBot). Only a truly unknown /word is still caught and answered privately.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

* web: make the chat view of an app-thread functional (send just works)

An app-thread's chat view is a regular DM, but a plain message typed there never folded/rendered — the untyped-message fold was gated on chatAppFor(tid), which is null for app-threads. Include app-threads (threadApp[tid]) so notes you type in the chat view fold + render, whether or not the app's bot ever replies.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

* web: stop the command reply flashing away in an app's own chat view

The chat app cleared its notices strip on every re-render; inside an app-thread's own chat, the command's own event folds a bubble here and re-renders, wiping the just-shown reply. Notices now own their lifecycle (auto-dismiss timer + ✕), so drop the render-clear; respond() still replaces the prior reply before appending.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

* web: split-pane Views on desktop (chat + interface), single-pane toggle on mobile

An app-thread mounts BOTH views of its one folded log: the Chat pane (#app-pane) and the Interface pane (#interface-pane). Desktop (>=721px): side by side; the header toggle's Interface choice hides Chat so the interface fills the pane. Mobile (<=720px): one View at a time, toggled. A normal chat thread leaves #interface-pane empty (hidden → full width), unchanged. Both panes redraw from the same state on every fold, so they stay in sync live (a reminder firing appears in Chat and updates the Interface list at once).

'View <app>' (a command reply's chip) opens the app's thread showing its interface — the desktop split already shows it; a narrow layout switches to the Interface pane. Also: the dismiss ✕ is drawn as SVG lines (centred on the ring) instead of a text glyph that wouldn't centre.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

* web: fix group/DM chats blanking out (classList.toggle force must be boolean)

applyAppThreadView passed 'threadApp[id] && …' as the toggle force; for a group/DM that's undefined, and classList.toggle(x, undefined) FLIPS instead of removing — so opening group chats alternately gained .iface, whose desktop CSS hides the chat pane (and there's no interface pane), blanking the thread. Coerce to a real boolean so a non-app-thread always clears .iface.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

* web: three-view toggle (Chat/Split/Interface), /me action lines, first-chat intro

Views: the header toggle is now [Chat | Split | Interface] — Split (desktop-only, the default) shows both panes; Chat and Interface each show one, on both platforms. Driven by a data-app-view attribute (chat|split|interface) instead of the old .iface class.

Action lines: in an app-thread's own chat, a command's event lands as a persistent, centered /me-style line ('added "milk"', 'set a reminder: …') — chatMessage can return { text, action:true } for that, or a string for a bot message bubble (a reminder firing). The ephemeral 'only visible to you' reply is suppressed when the command targets the thread you're in (the action line is the record); it still shows when you fire a command from another chat.

First-chat intro: an empty app-thread chat shows a per-app explainer ('This is the start of your chat history with To-do. Type /todo Something …. You can also … in the Interface view'), matching each app's real commands.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

* web: full-history action lines + persistent top-of-chat intro for app-threads

Action lines were missing for a well-used bot because the chat view only folded the recent /api/messages window; older adds (compacted into the state snapshot the Interface uses) never became action lines. Fold the FULL event log for an app-thread's chat view instead (fetchAllThreadMessages paginates older pages, bounded at 2000) so the history is complete. The Interface still seeds fast from the snapshot.

The intro ('This is the start of your chat history with …') is now a PERSISTENT keyed first row that scrolls up as the conversation grows, instead of a vanishing empty-state that disappeared the moment you chatted or an action line landed.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

* web: fix action lines never appearing (per-app fold de-dupe)

foldInto de-duped folded message ids PER THREAD, shared across apps. An app-thread event folds into BOTH its owning app (state → the Interface) and the chat app (an action-line bubble), reusing the same server message id — so the owner fold added the id first and the chat fold was skipped as a 'dup'. The Interface updated but no action line ever appeared. Make the de-dupe per (thread, app) so the same message can fold into two apps. Regression test added.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

* web: make the app-thread chat view opt-in (takeover by default)

#160 made every personal app-thread a "companion": a Chat view plus an
Interface view, with a [Chat | Split | Interface] header toggle, mandatory
for all of them. That over-committed the architecture — an app could no
longer own its thread's full surface, and chat.js decided the presentation
for every app.

Make companion opt-in and takeover the default, keyed off a single fact the
app already declares: whether it implements chatMessage(event) (the hook that
projects its events into the Chat view). An app WITH chatMessage (To-do,
Reminders) gets the companion split, unchanged; an app WITHOUT one (Bookmarks)
takes over the whole thread — its render() is the surface, no chat pane, no
toggle (the original full-pane model, restored). The gate is a one-line
predicate, appWantsChatView(name), in apps.js; chat.js consults it instead of
hardcoding "every app-thread is companion". The takeover open path restores
main's pre-#160 personal-app fold (isAppType → foldEvent) that #160 had
narrowed to the chat app only.

Verified live: To-do opens Split with the 3-way toggle (companion, unchanged);
Bookmarks opens full-pane with no toggle and its state survives reload
(takeover history-fold works); switching between them doesn't bleed view state;
no console errors. go build / go test ./... / npm test all green (added an
appWantsChatView unit test).

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

---------

Co-authored-by: Paul Campbell <paul@tito.io>
Co-authored-by: Claude Opus 4.8 (1M context) <noreply@anthropic.com>