mulmoterminal 4.26.0 → 5.0.0

package/README.md

@@ -1232,6 +1232,18 @@ The toggle is not the only way in: while a cell is enlarged, **clicking a file p
 printed** opens it here too, rather than in a new tab or full-screen — see
 [Clicking a file path](#clicking-a-file-path).
 
+**Open a file by name instead of walking the tree.** The pane's header has a **search** button
+that opens a finder over it: type part of a file's name or path and it narrows a list of every
+file in the project — fuzzily, so `fpane` finds `src/components/FilesPane.vue`. Arrow keys and
+Enter pick one; it opens in the editor **with the tree expanded down to it**, so the files
+around it are one click away. In a git repository the candidates come from `git ls-files`, so
+everything your `.gitignore` excludes — `node_modules` and the rest — is never offered; outside
+one the tree is walked instead: no ignore file is read, and only a short list of directories
+nobody authors by hand (`node_modules`, virtualenvs, caches) is skipped. The panel says so rather
+than letting you believe an ignore file was applied. There is also a
+[`files-find` shortcut](https://receptron.github.io/mulmoterminal/guide/en/config.html#keymap)
+with no default binding, which opens the pane first if it is closed.
+
 All reads and writes go through `GET/PUT /api/files/browse/*?cwd=&path=`, and every
 `path` is **contained within the project root** (server-side) — `..`/absolute escapes
 are rejected for reads and writes alike, so editing can't reach outside the directory
@@ -1629,6 +1641,20 @@ narrow and tall for one record you are discussing — and each position keeps it
   prompt history, codex's rollout), so a prompt sent mid-turn is there and text a skill
   injected is not. A `/clear` draws a line: the pane shows what you have asked *since*, the
   same way the header, the title and the last reply all stop describing the ended conversation.
+- **Conversation pane** — the enlarged cell's conversation, read as TURNS rather than as the
+  screen, from `GET /api/transcript/view`. A Claude cell runs on the alternate screen, so the
+  terminal keeps no scrollback worth scrolling; this reads the agent's own transcript instead,
+  and **scrolling up walks the session back to its first turn**, a page at a time.
+  - It **takes the terminal's place when you open it** — the one pane that does, because reading
+    is its whole subject. The expand button puts the terminal back beside it.
+  - **A frame per speaker**: what you asked in one, what the agent answered in another, named
+    ("You" / "Claude"). The reply is **rendered markdown** — headings, lists, tables, fenced
+    code — not the characters it is written with.
+  - **Tool traffic is folded away**, one line saying what ran (`Bash · Read`); click to open it.
+    It is most of a turn's bulk and almost none of what you came back to read.
+  - A **snapshot**, not a live tail — the terminal beside it is the live view — and the header's
+    reload fetches the newest turns again. Claude, Codex, Cursor and Copilot; an agent whose
+    conversation no reader here can read yet says so rather than showing an empty pane.
 - **Notifications** (🔔) — a toolbar bell with an unread badge and a dropdown of active
   notifications; click a row to jump to its session.
 - **Star MulmoTerminal** — a star button in the grid toolbar that stars the project on GitHub

package/common/codeBlocks.ts

@@ -55,9 +55,31 @@ const closes = (line: string, opener: string): boolean => {
   return !!fence && fence.run[0] === opener[0] && fence.run.length >= opener.length && fence.info.trim() === "";
 };
 
-export function fencedBlocks(markdown: string): FencedBlock[] {
+/** A run of prose, or one fenced block — the whole text, in order and with nothing dropped.
+ *
+ *  This is the ONE walk over the fences, and `fencedBlocks` below is it with the prose dropped. It
+ *  is not a second scanner: the two used to be separate loops over the same rules, which is two
+ *  places for a fence rule to drift.
+ *
+ *  It is deliberately not tied to any one reader. The transcript pane rendered its segments for a
+ *  while and now renders the reply as markdown instead (#2112); saying otherwise here sends the next
+ *  reader looking for a consumer that no longer exists (Claude review, round 1). */
+export type MarkdownSegment = { kind: "text"; text: string } | { kind: "code"; lang: string | null; body: string };
+
+/** The one walk over the fences. `fencedBlocks` is this with the prose dropped.
+ *
+ *  Prose runs are joined with the newlines they had, so a run's own blank lines survive; a segment
+ *  is emitted only when it has a line in it, so an input that opens with a fence does not lead with
+ *  an empty one. */
+export function markdownSegments(markdown: string): MarkdownSegment[] {
   const lines = markdown.split("\n");
-  const blocks: FencedBlock[] = [];
+  const segments: MarkdownSegment[] = [];
+  const prose: string[] = [];
+  const flushProse = (): void => {
+    if (prose.length === 0) return;
+    segments.push({ kind: "text", text: prose.join("\n") });
+    prose.length = 0;
+  };
   let i = 0;
   // Each line is read into a const before use: with noUncheckedIndexedAccess, `lines[i]` is
   // `string | undefined` even inside `i < lines.length`, and the loop condition is what actually
@@ -66,9 +88,11 @@ export function fencedBlocks(markdown: string): FencedBlock[] {
     const line = lines[i];
     const open = line === undefined ? null : fenceOf(line);
     if (!open) {
+      if (line !== undefined) prose.push(line);
       i++;
       continue;
     }
+    flushProse();
     const fence = open.run;
     const info = open.info.trim();
     const body: string[] = [];
@@ -78,9 +102,14 @@ export function fencedBlocks(markdown: string): FencedBlock[] {
       i++;
     }
     i++; // step over the closing fence (or past the end, for an unclosed block)
-    blocks.push({ lang: info ? (info.split(/\s+/)[0]?.toLowerCase() ?? null) : null, body: body.join("\n") });
+    segments.push({ kind: "code", lang: info ? (info.split(/\s+/)[0]?.toLowerCase() ?? null) : null, body: body.join("\n") });
   }
-  return blocks;
+  flushProse();
+  return segments;
+}
+
+export function fencedBlocks(markdown: string): FencedBlock[] {
+  return markdownSegments(markdown).flatMap((segment) => (segment.kind === "code" ? [{ lang: segment.lang, body: segment.body }] : []));
 }
 
 /** The block a reader means by "the code you just gave me": the last one. Null when the reply

package/common/collectionRefresh.ts

@@ -0,0 +1,34 @@
+// The `POST /api/collections/:slug/refresh` response. One shape for BOTH arms of that
+// route — a declarative/agent feed's `ingest` re-run and a `googleCalendar` sync — because
+// the collection view reads one result whichever arm answered, and two host-side shapes for
+// one button is how a field ends up set by one arm and never read from the other.
+//
+// It mirrors MulmoClaude's `CollectionRefreshBody` (server/api/routes/collectionCalendarRefresh.ts)
+// so the two hosts over the shared workspace answer the same plugin identically. Re-stated
+// rather than imported, for `collectionPush.ts`'s reason: the plugin ships its
+// `CollectionRefreshResult` from `@mulmoclaude/collection-plugin/vue`, and the server has no
+// business pulling a Vue package in to describe its own response.
+//
+// An absent field is an ABSENT KEY, never an explicit `undefined`. That is what the wire carries
+// either way (JSON.stringify drops an undefined value), and under `exactOptionalPropertyTypes` it
+// is also what makes this assignable to the plugin's own `CollectionRefreshResult` — so the
+// binding in `collectionUi.ts` type-checks the server's shape against the view's expectation
+// instead of both sides describing it separately.
+
+export interface CollectionRefreshResult {
+  /** Always true — "the refresh ran", not "records changed". A refusal is told through
+   *  `errors`, the way the push's `pushed` works. */
+  refreshed: true;
+  written: number;
+  /** Why the refresh did not do what was asked. Read beside the button, so an empty list is
+   *  the only thing that means "it worked". */
+  errors: string[];
+  /** Records a `googleCalendar` sync deleted (the event was cancelled in Google). Sent by the
+   *  calendar arm only: the feed engine counts its own `maxItems` evictions, but the feed arm
+   *  has never reported them and MulmoClaude's does not either. */
+  removed?: number;
+  /** An agent-ingest feed dispatched a worker session instead of writing records itself. */
+  dispatched?: boolean;
+  /** The dispatched session, for the view to navigate to. */
+  chatId?: string;
+}

package/common/keymap.ts

@@ -22,6 +22,7 @@ export const KEYMAP_ACTIONS = [
   "terminal-new-adjacent",
   "terminal-close",
   "terminal-restart",
+  "files-find",
   "copy",
   "paste",
 ] as const;
@@ -49,7 +50,17 @@ export const TERMINAL_SCOPED_ACTIONS: readonly KeymapAction[] = ["copy", "paste"
 // Here rather than beside gridShortcutFor because BOTH sides decide from it: the grid dispatches on
 // it, and validateKeymap has to know that these decline the key — the handler returns WITHOUT
 // stopping the event, so a `send` on the same keystroke fires instead (codex on #1906).
-export const NEEDS_A_CURRENT_TERMINAL: readonly KeymapAction[] = ["zoom-next", "zoom-prev", "terminal-new-adjacent", "terminal-close", "terminal-restart"];
+// `files-find` is here because the pane it opens exists only in the ENLARGED row (see
+// docs/grid-view-modes.md) — a tiled grid has nowhere to put it, so the key declines rather than
+// guessing which of nine terminals was meant.
+export const NEEDS_A_CURRENT_TERMINAL: readonly KeymapAction[] = [
+  "zoom-next",
+  "zoom-prev",
+  "terminal-new-adjacent",
+  "terminal-close",
+  "terminal-restart",
+  "files-find",
+];
 
 // A key that puts BYTES into the focused terminal instead of running an app action (#1005) —
 // Cmd+Right as Ctrl+E for end-of-line, say, or Alt+B for word-back.

package/common/themeColors.ts

@@ -28,3 +28,20 @@ export const THEME_COLOR_KEYS = [
   "brightCyan",
   "brightWhite",
 ] as const;
+
+export type ThemeColorKey = (typeof THEME_COLOR_KEYS)[number];
+
+/** What a palette colour may look like: xterm accepts `#rgb` / `#rgba` / `#rrggbb` / `#rrggbbaa`.
+ *  Here rather than in the server schema because BOTH sides check it — the server rejects a config
+ *  on it, and the client re-checks the response before the value reaches a canvas. Two copies of
+ *  this pattern is how one side ends up accepting what the other drops. */
+export const PALETTE_COLOR_RE = /^#([0-9a-fA-F]{3,4}|[0-9a-fA-F]{6}|[0-9a-fA-F]{8})$/;
+
+/** STRICT — surrounding whitespace is a reject, not something to trim away. The server's
+ *  `paletteColor` trims before it matches and hands back the trimmed value, so everything this
+ *  predicate legitimately sees has already been normalised; accepting `" #fff "` here would mean
+ *  forwarding that exact string to xterm, which does not trim and cannot parse it. Validate the
+ *  value you are about to pass on, not a cleaned-up version of it. */
+export function isPaletteColor(value: unknown): value is string {
+  return typeof value === "string" && PALETTE_COLOR_RE.test(value);
+}

package/common/themeVars.ts

@@ -4,6 +4,7 @@
 // it, so a key known to one side and not the other would be accepted and then silently ignored.
 
 import { THEME_IDS, type ThemeId } from "./themeIds.js";
+import type { ThemeColorKey } from "./themeColors.js";
 
 // The CSS custom properties one theme sets, mirroring the `:root[data-theme=...]` blocks in
 // src/style.css. A theme with no `extends` has to supply every one of them — a half-painted
@@ -65,6 +66,10 @@ export interface CustomThemeInput {
   /** A built-in theme to start from. Omitted means `colors` must be complete. */
   extends?: ThemeId;
   colors: Partial<ThemeVars>;
+  /** xterm palette entries set outright, for the canvas colours `colors` cannot reach: the
+   *  cursor pair, the selection foreground, the 16 ANSI colours. Wins over what `colors`
+   *  implies (#2097). */
+  term?: Partial<Record<ThemeColorKey, string>>;
 }
 
 /** The full variable set for a theme: the base it extends, with its own colours on top.
@@ -132,11 +137,24 @@ export function isLightTheme(vars: ThemeVars): boolean {
 /** The xterm palette a theme's variables imply. xterm draws on a canvas and cannot read CSS
  *  variables, so the same colours have to reach it as values — derived here rather than asked
  *  for twice, since two copies of one colour is two chances to change only one. The 16 ANSI
- *  colours are NOT derived: they come from the base theme, which is what `extends` is for. */
-export function termThemeFromVars(vars: ThemeVars): { background: string; foreground: string; selectionBackground: string } {
+ *  colours are NOT derived: they come from the base theme, which is what `extends` is for.
+ *
+ *  The cursor pair is derived from the SAME two variables the cell it sits on uses, which makes
+ *  the cursor an inverted cell — so the character under it stays as readable as the characters
+ *  beside it. Inheriting the cursor from the base instead is what made a light theme extending a
+ *  dark one draw a dark block with xterm's default black glyph on top (#2097). */
+export function termThemeFromVars(vars: ThemeVars): {
+  background: string;
+  foreground: string;
+  selectionBackground: string;
+  cursor: string;
+  cursorAccent: string;
+} {
   return {
     background: vars["--bg-base"],
     foreground: vars["--term-fg"],
     selectionBackground: vars["--term-selection"],
+    cursor: vars["--term-fg"],
+    cursorAccent: vars["--bg-base"],
   };
 }

package/common/transcriptView.ts

@@ -0,0 +1,78 @@
+// What a hosted agent's conversation looks like ON THE WIRE.
+//
+// In `common/` because both ends decide from it: the host folds an agent's JSONL (or copilot's
+// table) into these shapes in `server/session/transcript-view.ts`, and two clients render them —
+// the phone's terminal detail page over the remoteHost socket, and the browser's transcript pane
+// over `/api/transcript/view`. Mirroring the shape into `src/` would let one side gain a status the
+// other silently renders as nothing.
+//
+// The RULES that produce these — the turn boundary, the line budget, the tool-result cap — stay on
+// the server. This file is the vocabulary, not the folding.
+
+export type TranscriptRowKind = "user" | "assistant" | "tool" | "unknown";
+
+/** One content block, rendered.
+ *
+ *  `text` may itself contain newlines — an assistant answer is passed through whole, because the
+ *  wrapping belongs to the client's CSS and not to a host that cannot know its width.
+ *
+ *  `clipped` says THIS row's text was cut, which is a different fact from `TranscriptView.truncated`
+ *  (a whole turn was dropped). Naming them the same word would leave the client unable to decide
+ *  which mark to draw. */
+export interface TranscriptRow {
+  kind: TranscriptRowKind;
+  text: string;
+  clipped?: boolean;
+  /** This tool row is the CALL — the tool's name and the head of its arguments — rather than what
+   *  the tool answered (#2112).
+   *
+   *  Said by the host because only the host can say it: both halves arrive as `kind: "tool"`, and a
+   *  client telling them apart by shape ("short and single-line means a name") is guessing about
+   *  four agents' output at once. A pane that collapses tool traffic needs it to label the fold with
+   *  what RAN — the part a reader is looking for when they open it again. */
+  call?: boolean;
+}
+
+/** One exchange: a user prompt and everything that followed it.
+ *
+ *  `at` is the BOUNDARY record's own timestamp — the moment the turn started — or null when it is
+ *  not a string. Null rather than dropping the turn: a turn is worth more than its clock. */
+export interface TranscriptTurn {
+  at: string | null;
+  rows: TranscriptRow[];
+}
+
+/** What the host answers. A discriminated union rather than "readable: boolean": "no transcript
+ *  yet", "the conversation was ended with /clear" and "too big to find a turn in" are three
+ *  different things to tell a person, and one boolean collapses them into the same blank view. */
+export type TranscriptView =
+  | { status: "ok"; turns: TranscriptTurn[]; truncated: boolean }
+  | { status: "none" }
+  | { status: "cleared" }
+  | { status: "too-large" }
+  /** This session's agent keeps a conversation somewhere, and no reader here can read it yet
+   *  (#1822). A DIFFERENT fact from `none`, which means "this session has written nothing we can
+   *  find" — the phone falls back to the screen for both, but only one of them is worth a sentence
+   *  to a person, and only one of them is a thing to go and implement.
+   *
+   *  Never answered for a shell or a launcher cell: those have no conversation and never will, so
+   *  the screen IS their content rather than a fallback from something missing. */
+  | { status: "not-supported" };
+
+/** One page of a conversation, read backwards from `older` (#2112).
+ *
+ *  The cursor is OPAQUE to the client on purpose: it is a byte offset for the three agents that
+ *  keep a file and a `turn_index` for the one that keeps a table, and a client that knew which
+ *  would be deciding something only the host can know. It is handed back verbatim to ask for the
+ *  page before this one.
+ *
+ *  `older: null` means this page reaches the start of what can be read — either the head of the
+ *  transcript, or the point past which the host refuses to read (`status: "too-large"`).
+ *
+ *  The view is carried whole rather than flattened in beside the cursor: every non-`ok` status is
+ *  a sentence the client already knows how to show, and re-deciding them per page is how the two
+ *  ends drift. */
+export interface TranscriptPage {
+  view: TranscriptView;
+  older: string | null;
+}