mulmoterminal 4.16.1 → 4.18.0

package/README.md

@@ -1083,11 +1083,13 @@ everything else on disk that happens to parse as a deck. Measured on a real work
 matched, 33 were the user's own decks and 217 were a checked-out repository's test fixtures and
 samples.** A menu is a short list of things you chose.
 
-**Where the decks have to live:** in any directory MulmoTerminal knows about — the workspace it
-was started in, plus the directories in your launcher's saved list (up to 64 in total, and one that
-is no longer on disk is skipped). Those are read **once at startup**, so a repository you open for
-the first time needs a restart before its decks can be shown. Any deck you can see in the file tree is also reachable there — right-click a row and choose
-**Open in the Canvas** — with no configuration at all.
+**Where the decks have to live:** anywhere. A deck under the workspace — or under a directory in
+your launcher's saved list (up to 64 in total, read once at startup) — is addressed by its place in
+that directory; one anywhere else is addressed by its own path. Either way it opens, and a deck you
+open both ways is **one card**, not two. A deck you can see in the file tree is reachable there too
+— right-click a row and choose **Open in the Canvas** — with no configuration at all, as long as the
+pane knows the directory its tree is rooted at. It shows that path in its header; a pane still
+reading `(default workspace)` has nothing to resolve a row against and offers no entry.
 
 If a deck cannot be opened (it was deleted, or the workspace moved since startup), the cell says
 why rather than doing nothing.

package/common/dirPathKey.ts

@@ -43,3 +43,22 @@ export function dirPathKey(path: string): string {
 
 /** Whether two paths name the same directory, as far as spelling can tell. */
 export const isSameDirPath = (a: string | null | undefined, b: string | null | undefined): boolean => !!a && !!b && dirPathKey(a) === dirPathKey(b);
+
+/**
+ * Whether `path` names one file on its own — POSIX `/…`, a Windows drive root, a UNC share.
+ *
+ * NARROWER than `rootOf` on purpose, in the one place the two could disagree: a SINGLE leading
+ * backslash. `rootOf` keys `\deck.json` as `/deck.json`, which is right for its job (comparing two
+ * spellings of a directory lexically) and wrong for this one — on Windows that path is rooted on
+ * the process's CURRENT DRIVE, which the spelling does not carry and a browser cannot infer. Keying
+ * it would give `\deck.json` and `C:\deck.json` two identities for one file while conflating the
+ * first with a POSIX `/deck.json` (Codex P2 on #1976). A caller that needs a decision here gets
+ * "no", and whatever it falls back to is at worst what it did before.
+ *
+ * The same distinction `rootOf` already draws for `C:foo` and `\server\share`: a spelling that
+ * means something else must not borrow a rooted one's key.
+ */
+export const isRootedPath = (path: string): boolean => {
+  const trimmed = path.trim();
+  return /^[a-zA-Z]:[/\\]/.test(trimmed) || /^[/\\]{2}/.test(trimmed) || trimmed.startsWith("/");
+};

package/common/shortcuts.ts

@@ -6,6 +6,11 @@
 // show up in the other — so the on-disk format is the contract: an OBJECT WRAPPER
 // `{ shortcuts: Shortcut[] }`, not a bare array, matching mulmoclaude/src/types/shortcuts.ts.
 // Keep this type in sync with MulmoClaude's.
+//
+// It is a SUBSET of what a record may hold, not the whole of it: the file is the union of every
+// version of both apps that has written it, and a stored record can carry fields this build has
+// never heard of. `toShortcut` (server/backends/shortcuts.ts) carries those through rather than
+// dropping them (#1996) — so this type says what MulmoTerminal understands, not what exists.
 
 export const SHORTCUT_KINDS = ["collection", "feed"] as const;
 export type ShortcutKind = (typeof SHORTCUT_KINDS)[number];
@@ -19,6 +24,14 @@ export interface Shortcut {
   title: string;
   /** Cached material-symbols glyph — refreshed on reconcile. */
   icon: string;
+  /** Cached accent colour name — MulmoClaude's, and only MulmoClaude draws it (#1993).
+   *
+   *  Carried rather than understood: this app has no accent palette, so it keeps whatever string
+   *  the file holds and hands it back unchanged. Deliberately NOT validated here — deciding which
+   *  colours are legal is the job of the app that draws them, and a check that drifted from theirs
+   *  would silently delete a colour they consider valid, which is the bug this field exists to fix.
+   *  Absent when the collection names none. */
+  color?: string;
 }
 
 /** True when two shortcuts target the same thing (the dedupe key). */

package/common/toolGroups.ts

@@ -8,7 +8,12 @@
 // config already written against it.
 
 // The groups, ordered by how much damage a call can do.
-//   render   — draws into the Canvas panel and stops there. No side effect outside it.
+//   render   — draws a model or document for the user, and writes nothing but the
+//              artifact it just drew. It USED to mean "no side effect outside the
+//              Canvas panel"; presentShapeScript saves its `.shape` and
+//              renderShapeScript saves a PNG, so the honest line is that a render
+//              tool touches only its own output, never the workspace's data or
+//              anything off this machine.
 //   data     — reads/writes the workspace's structured data (collections, accounting).
 //   media    — generation that is slow, costly, and lands files on disk.
 //   external — reaches a third-party account or API.
@@ -84,6 +89,11 @@ const GROUP_BY_TOOL = new Map<string, ToolGroup>([
   ["presentForm", "render"],
   ["presentChart", "render"],
   ["presentHtml", "render"],
+  ["presentShapeScript", "render"],
+  // Beside presentShapeScript deliberately: a cell that can show a 3D model should be
+  // able to CHECK one, and splitting the pair would leave an agent able to present a
+  // model it cannot look at first.
+  ["renderShapeScript", "render"],
 
   // presentCollection RENDERS, but it renders collection data and only makes sense next to
   // manageCollection — a cell offered the view without the store gets a tool it cannot fill.
@@ -175,8 +185,34 @@ export const LEGACY_GUI_SERVER_IDS: readonly string[] = ["mulmoterminal-gui"];
 // model spend money silently under a switch the UI presents as "let the agent draw", so it
 // keeps Claude Code's prompt (answer it once per project and the prompt stops).
 //
-// The three below save an artifact and draw it, and call nothing external.
-export const AUTO_ALLOWED_TOOLS: readonly string[] = ["presentForm", "presentChart", "presentHtml"];
+// The four below save an artifact and draw it, and call nothing external.
+//
+// `presentShapeScript` was listed here on the grounds that it saved nothing at all —
+// the source travelled in the tool result and was rendered client-side. That stopped
+// being true at shapescript-plugin 1.1.0, which writes the model to
+// `artifacts/shapes/` and can open a `.shape` the caller names. It stays on the list,
+// but now for the same reason as the other three rather than a stronger one that no
+// longer holds.
+//
+// `renderShapeScript` is here too, and the reasoning is worth stating because the first
+// attempt got it wrong. It starts a PROCESS — a headless browser — which reads like the
+// far side of "calls nothing external", so it was left off. But this bar is about REACH
+// and COST, not about process creation: the tools kept off it spend money
+// (presentDocument's image fill), publish to the internet, or act in someone else's
+// account. A local Chromium rendering a page WE construct, with every request it makes
+// aborted unless it is one of our two assets, does none of that. It writes a PNG under
+// the workspace artifacts and burns CPU for at most the render budget.
+//
+// Leaving it off was also not the half-measure it looked like. This list governs GRID
+// cells; the workspace passes `allowedToolNames()`, which auto-approves everything not
+// in NEVER_AUTO_APPROVED_TOOLS — so the tool prompted in a cell and ran unattended in
+// the workspace, which is the worst of both and matches no stated policy (codex on
+// #2010). The two paths now agree.
+//
+// And the friction had no payoff: the tool exists so an agent can CHECK a model before
+// showing it, which is a render-look-fix loop. A prompt in the middle of that costs the
+// user attention to approve the agent looking at its own work.
+export const AUTO_ALLOWED_TOOLS: readonly string[] = ["presentForm", "presentChart", "presentHtml", "presentShapeScript", "renderShapeScript"];
 
 /** Tools that must keep the agent's permission prompt on EVERY claude session, including the
  *  workspace.

package/common/toolbarPins.ts

@@ -0,0 +1,107 @@
+// Which of the pinned favourites the app toolbar shows without opening Collections (#1984).
+//
+// Shared because both sides decide from it: the server sanitizes what `~/.mulmoterminal/config.json`
+// says, the browser renders the toolbar and writes the same field back.
+//
+// Deliberately NOT a field on `Shortcut`. The pins themselves live in `<workspace>/config/shortcuts.json`,
+// which MulmoTerminal SHARES with MulmoClaude, and both apps rebuild every record when they write it
+// (`normalizeShortcuts`) — so a field one app added is dropped the first time the other pins anything.
+// This is a MulmoTerminal-side view preference over that shared list, and it holds only the identity
+// of the pins it promotes: the label and the icon are read from the pin, so renaming a collection
+// cannot leave the toolbar saying the old name.
+import { SHORTCUT_KINDS, type Shortcut, type ShortcutKind } from "./shortcuts.js";
+
+/** How many buttons the toolbar draws, and so how many pins can be promoted at once. The row
+ *  already carries the view switch, the grid's own controls, the status tally and two gauges; past
+ *  a handful the pins stop being "one press away" and start pushing that row into its horizontal
+ *  scroll, which is the two-step this feature exists to remove. */
+export const MAX_TOOLBAR_PINS = 5;
+
+/** How many keys the FILE may hold, which is not the same number.
+ *
+ *  Nothing here ever deletes a key it did not just demote: unpinning a promoted collection leaves
+ *  its key in the config, where it draws nothing and takes no slot — and re-pinning brings the
+ *  button straight back. That is a deliberate choice over tidying the file on save. Tidying means
+ *  deciding "this pin is gone" from a list that might be stale, and one wrong answer deletes a
+ *  promotion the user still wants, silently; four separate review findings on PR #1991 were all
+ *  ways of getting that decision wrong. A key nobody can see costs a line of JSON.
+ *
+ *  So the file's own limit is a sanity bound, not a budget — you would have to unpin forty-five
+ *  promoted collections to meet it. */
+export const MAX_STORED_TOOLBAR_PINS = 50;
+
+/** How one promoted pin is named in the config: `"collection:works"`. */
+export const toolbarPinKey = (pin: Pick<Shortcut, "kind" | "slug">): string => `${pin.kind}:${pin.slug}`;
+
+// Split on the FIRST colon, not every colon: `kind` is one of two known words, so everything after
+// it is the slug even if a slug ever contains one.
+function parseToolbarPin(key: unknown): { kind: ShortcutKind; slug: string } | null {
+  if (typeof key !== "string") return null;
+  const separator = key.indexOf(":");
+  if (separator <= 0) return null;
+  const kind = SHORTCUT_KINDS.find((candidate) => candidate === key.slice(0, separator));
+  if (kind === undefined) return null;
+  const slug = key.slice(separator + 1);
+  return slug.length > 0 ? { kind, slug } : null;
+}
+
+/** Keep the well-formed keys, in order, deduped, up to the FILE's bound. Anything else — a config
+ *  written by hand, a key naming a kind this build does not have — is dropped rather than rendered
+ *  as a blank button. The bound here is `MAX_STORED_TOOLBAR_PINS`, not the number of buttons:
+ *  truncating to five would delete keys whose pins are merely unpinned right now. */
+export function sanitizeToolbarPins(input: unknown): string[] {
+  if (!Array.isArray(input)) return [];
+  const out: string[] = [];
+  input.forEach((raw) => {
+    const pin = parseToolbarPin(raw);
+    if (!pin) return;
+    const key = toolbarPinKey(pin);
+    if (out.includes(key) || out.length >= MAX_STORED_TOOLBAR_PINS) return;
+    out.push(key);
+  });
+  return out;
+}
+
+/** The pins the toolbar draws: the configured keys, in the CONFIG's order, resolved against the
+ *  favourites that exist now, and cut to the number of buttons the row can carry.
+ *
+ *  A key whose pin is gone — unpinned here, or in MulmoClaude, which writes the same file — is
+ *  skipped rather than drawn: the title and icon come from the pin, so there is nothing to label it
+ *  with. Skipped, not deleted, and it does not consume one of the five: re-pin it and the button is
+ *  back exactly where it was.
+ *
+ *  What counts as "gone" is gone from the list the CALLER holds. The client store reads
+ *  `/api/shortcuts` once per page, so a pin removed by the other app is still drawn until something
+ *  re-reads it — which opening Settings' Toolbar pins does (Codex, PR #1991). */
+export function resolveToolbarPins(shortcuts: readonly Shortcut[], keys: readonly string[]): Shortcut[] {
+  const byKey = new Map(shortcuts.map((shortcut) => [toolbarPinKey(shortcut), shortcut]));
+  return keys
+    .flatMap((key) => {
+      const shortcut = byKey.get(key);
+      return shortcut ? [shortcut] : [];
+    })
+    .slice(0, MAX_TOOLBAR_PINS);
+}
+
+/** The list to save after promoting or demoting one pin.
+ *
+ *  DEMOTING removes exactly the key the user unticked, and nothing else. PROMOTING appends, so a
+ *  hand-ordered config is not reshuffled by ticking one more box. Neither ever drops a key that was
+ *  not the subject of the click — see `MAX_STORED_TOOLBAR_PINS` for why that restraint is the whole
+ *  design rather than an omission.
+ *
+ *  `live` is what is pinned right now (`toolbarPinKey` of each favourite). It is read ONLY to count
+ *  the promotions that can actually be drawn: a key whose pin is gone draws nothing, so counting it
+ *  toward the five would fill the row with buttons that are not there and leave nothing to untick
+ *  (Codex, PR #1991). Nothing is deleted on the strength of it, which is what makes a stale `live`
+ *  harmless here — at worst the count is off by one until the next read.
+ *
+ *  Returns the SAME array when nothing would change: already promoted, not promoted anyway, or a
+ *  promotion refused because the row is full. */
+export function nextToolbarPins(keys: readonly string[], live: readonly string[], key: string, promote: boolean): readonly string[] {
+  if (!promote) return keys.includes(key) ? keys.filter((entry) => entry !== key) : keys;
+  if (keys.includes(key)) return keys;
+  const drawn = keys.filter((entry) => live.includes(entry)).length;
+  if (drawn >= MAX_TOOLBAR_PINS || keys.length >= MAX_STORED_TOOLBAR_PINS) return keys;
+  return [...keys, key];
+}