mulmoterminal 4.8.0 → 4.8.2

package/README.md

@@ -724,7 +724,13 @@ malformed file is ignored.
   "icon": "docs/logo.png",              // image on this dir's cells (path here, URL, or data:); omit to use the repo's favicon
   "badgeColor": "#cf222e",              // badge color (hex #rrggbb)
   "headerColor": "#190a23",             // cell header background (hex #rrggbb)
-  "headerTextColor": "#ffffff",         // cell header text color (hex #rrggbb)
+  "headerTextColor": "#ffffff",         // cell header text color while idle (hex #rrggbb)
+  "headerStatusColors": {               // what the header shows once a status takes the background over
+    "working": "#6d28d9",               //   just the background — the text colour is derived from it
+    "done": { "background": "#166534" },
+    "blocked": { "background": "#7c2d12", "text": "#ffe8a3" }
+  },
+  "headerStatusTint": "background",     // "none" keeps headerColor while working/done (not blocked)
   "cellColor": "#101014",               // cell body background (hex #rrggbb)
   "cellBorderColor": "#2a2a4e",         // cell border color (hex #rrggbb)
   "dotColor": "#00e676",                // idle status dot (hex #rrggbb)
@@ -786,7 +792,9 @@ Settings → Directory settings names both files and lists which keys the local
 | `icon`       | An **image** marking this directory — shown in the cell header, the cockpit roster, the filmstrip thumbnails, the launcher's directory chips, and the phone's terminal list and terminal screen. Either a path **relative to this directory** (an absolute path, or a `../` that escapes it, is rejected), an `http(s)://` URL, or a `data:image/…` URI. PNG / JPEG / **GIF (animated plays)** / WebP / AVIF / SVG / ICO / BMP. Not to be confused with a header **button's** `icon`, which is a Material Symbols name. **Omit it and the repository's own favicon is used** (`public/favicon.svg`, `apple-touch-icon.png`, a web manifest — see `autoDirIcon`); `false` means no icon here and stops that search. |
 | `badgeColor` | Badge background color (`#rrggbb`); text auto-contrasts. |
 | `headerColor` | Header **background** color (`#rrggbb`) — the grid cell's header row and the terminal's own header row (grid row 2). While a terminal is working/blocked the status tint still shows; the custom color applies when idle. |
-| `headerTextColor` | Header **text** color (`#rrggbb`) — the dir path, title, and prompt. |
+| `headerTextColor` | Header **text** color (`#rrggbb`) — everything written on the header: the dir path, title and prompt, plus the model/context badge, the token counts and any custom chip. **Omit it and a readable colour is derived from `headerColor`.** It applies while that colour is what shows: a working/done/blocked cell paints the theme's own status tint, so its text returns to the theme's too — an ink chosen for your header colour is not readable on a tint the theme mixed. Recolour those states with `headerStatusColors` instead. |
+| `headerStatusColors` | What the header shows once a **status** owns the background: an object keyed by `working` / `done` / `blocked` (there is no `idle` — `headerColor` is idle). Each value is a background `#rrggbb`, or `{ "background": …, "text": … }`. **Omit `text` and a readable one is derived from the background**, so naming one colour can never come out unreadable. A status you don't name keeps the theme's tint. |
+| `headerStatusTint` | `"background"` (default) lets a status replace the header background. `"none"` keeps `headerColor` while **working** and **done** — the status still reads from the cell border, the status dot and the pill. It deliberately does **not** reach `blocked`, the one state where nothing proceeds until you answer; give that state a colour of its own in `headerStatusColors` if you want one. |
 | `cellColor` | Cell **body background** color (`#rrggbb`) — the frame around the terminal. |
 | `cellBorderColor` | Cell **border** color (`#rrggbb`). The status frame (working/blocked) still overrides it while active. |
 | `dotColor` | **Idle** status-dot color (`#rrggbb`). The working/waiting colors are unchanged so the activity signal stays intact. |

package/common/bundledSkills.ts

@@ -22,6 +22,7 @@ export const BUNDLED_SKILL_NAMES = [
   "mulmoterminal-notify",
   "mulmoterminal-bug-report",
   "mulmoterminal-decisions",
+  "mulmoterminal-shared-app",
 ] as const;
 
 export type BundledSkillName = (typeof BUNDLED_SKILL_NAMES)[number];

package/common/chromeFromColor.ts

@@ -15,7 +15,7 @@
 // Snapping every role to absolute values drifts by ΔE 20 at the dark end of the hue wheel; making
 // every role a relative offset drifts by ΔE 15 at the pale end. Both were tried; this is the mix
 // that fits. Anyone retuning these numbers should re-measure rather than reason about them.
-import { readableTextColor } from "./contrast.js";
+import { contrastRatio, readableTextColor, relativeLuminance } from "./contrast.js";
 
 export interface ChromeColors {
   badgeColor: string;
@@ -36,6 +36,37 @@ const BUTTON = { s: 0.67, l: 0.89 };
 
 const clamp01 = (n: number): number => Math.min(1, Math.max(0, n));
 
+// The inks a header background can be written in. Black is softened to a near-black so a pale
+// header does not read as a printed page; white is left pure, since anything softer loses contrast
+// on the dark end where it is chosen.
+const DARK_INK = "#1b2430";
+const PURE_DARK_INK = "#000000";
+const LIGHT_INK = "#ffffff";
+
+// WCAG AA for normal text. These chips run to 10px, so the large-text 3:1 bar does not apply.
+const AA_CONTRAST = 4.5;
+const DARK_INK_LUMINANCE = relativeLuminance(0x1b, 0x24, 0x30);
+
+// The softening is a PREFERENCE, and it costs contrast: on a mid-tone background that cost is what
+// drops the text below AA — `#e8341c` measures 3.68:1 against the softened ink and 4.94:1 against
+// pure black (Codex on #1592, which is right and was worth measuring). So it is applied only while
+// it is free. Falling back always works: at the worst background — the luminance where black and
+// white are equally readable — the pure ink still reaches 4.58:1.
+function inkFor(rgb: [number, number, number]): string {
+  if (readableTextColor(rgb[0], rgb[1], rgb[2]) === "#fff") return LIGHT_INK;
+  const background = relativeLuminance(rgb[0], rgb[1], rgb[2]);
+  return contrastRatio(background, DARK_INK_LUMINANCE) >= AA_CONTRAST ? DARK_INK : PURE_DARK_INK;
+}
+
+/** Which ink a header background wants, or null when it isn't a colour we can read. Exported so a
+ *  directory that declares only `headerColor` derives the SAME text colour this file gives a
+ *  repo.json brand colour (src/components/cellHeaderStyle.ts) — two answers to one question is how
+ *  one directory ends up written in two different colours. */
+export function headerTextColorFor(background: string): string | null {
+  const rgb = parseHex(background);
+  return rgb ? inkFor(rgb) : null;
+}
+
 /** The seven colours for a brand colour, or null when it isn't a colour we can read. */
 export function chromeFromColor(primary: string, background?: string | null): ChromeColors | null {
   const rgb = parseHex(primary);
@@ -50,7 +81,7 @@ export function chromeFromColor(primary: string, background?: string | null): Ch
     headerColor: normalizeHex(primary),
     // Never taken from the file — see the spec's "text colour is never declared". Deriving it is
     // also what makes two conforming tools agree.
-    headerTextColor: readableTextColor(rgb[0], rgb[1], rgb[2]) === "#000" ? "#1b2430" : "#ffffff",
+    headerTextColor: inkFor(rgb),
     // `background` is the surface the brand colour sits on, which is exactly what a cell body is.
     // Gated on it PARSING, not on it being present: an unusable value here used to win the branch,
     // survive as a non-colour, and then be dropped downstream — leaving no surface at all, neither

package/common/collectionPortability.ts

@@ -22,7 +22,10 @@ export type SelfContainmentCode =
   /** No `primaryKey`, so ids are 4 random bytes and two machines can mint the same one. */
   | "no-primary-key"
   /** The project is not a git repo, so there is nothing to clone and most checks do not apply. */
-  | "not-a-repo";
+  | "not-a-repo"
+  /** Records live in the app's Firestore, not in the repository — by design for a SHARED
+   *  collection, and the reason it clones differently from every other kind. */
+  | "shared-store";
 
 /** `blocker` stops the clone working; `warning` costs something on the other machine; `info` is
  *  context. Only a blocker makes `portable` false. */

package/common/dirChrome.ts

@@ -3,6 +3,8 @@
 // all extend this, so a field added on one side can't go missing on the other.
 // `theme` and `colors` stay out of it — each side declares them with its own type
 // (the server keeps the validated strings, the client narrows them to xterm's ITheme).
+import type { HeaderStatusColors, HeaderStatusTint } from "./headerStatusColors.js";
+
 export interface DirChrome {
   name: string | null;
   badgeColor: string | null;
@@ -11,6 +13,11 @@ export interface DirChrome {
   // palette) — these tint the chrome around the terminal, not the terminal itself.
   headerColor: string | null;
   headerTextColor: string | null;
+  // What the header shows once a status REPLACES that background — working / done / blocked
+  // (common/headerStatusColors.ts). null means "not configured here", so a directory that says
+  // nothing falls through to the global default rather than asserting the built-in over it.
+  headerStatusColors: HeaderStatusColors | null;
+  headerStatusTint: HeaderStatusTint | null;
   // The cell frame + accents (grid cell): body background, border, the idle status
   // dot, and the header's icon buttons. Hex #rrggbb or null for the theme default.
   cellColor: string | null;
@@ -40,6 +47,8 @@ export const EMPTY_DIR_CHROME: Readonly<DirChrome> = {
   badgeColor: null,
   headerColor: null,
   headerTextColor: null,
+  headerStatusColors: null,
+  headerStatusTint: null,
   cellColor: null,
   cellBorderColor: null,
   dotColor: null,

package/common/dirConfigSource.ts

@@ -14,6 +14,8 @@ export const DIR_CONFIG_KEYS = [
   "badgeColor",
   "headerColor",
   "headerTextColor",
+  "headerStatusColors",
+  "headerStatusTint",
   "cellColor",
   "cellBorderColor",
   "dotColor",

package/common/githubPaneOrder.ts

@@ -0,0 +1,83 @@
+// Which repository's section the GitHub pane leads with.
+//
+// The pane is opened beside a CELL, and the cell names a directory — so the list is most useful
+// with that directory's repository first. Reordering rather than scrolling to it: a scroll that
+// lands slightly off looks like nothing happened, it has to re-run on every reload, and a repo
+// with no open PRs and no open issues has nothing to scroll to at all, where an empty section at
+// the top still answers "yours: none".
+//
+// Pure and shared so it can be tested without mounting the pane, and so the PR list and the issue
+// list cannot drift into ordering themselves differently.
+import { dirPathKey } from "./dirPathKey.js";
+
+/** The only field either list is ordered by. Both `RepoPrs` and `RepoIssues` carry it. */
+export interface RepoGrouped {
+  repo: string;
+}
+
+/** Case-insensitively, the way GitHub itself treats `owner/repo`. */
+const sameRepo = (a: string, b: string): boolean => a.toLowerCase() === b.toLowerCase();
+
+/**
+ * Whether `cwd` is the clone at `base`, or anywhere inside it.
+ *
+ * CONTAINMENT, not equality: a cell is very often somewhere under the clone rather than at its
+ * root — the user cd'd into `src/`, or the cell was started there — and an exact match left every
+ * one of those leading with the wrong repo (Codex review).
+ *
+ * Through `dirPathKey` because the browser has no filesystem: it folds both separators, a trailing
+ * slash, `.` and `..` into one spelling. Lexical only, so it cannot see through a symlink — which
+ * is right here, where the answer decides presentation. (server/infra/path-within.ts carries the
+ * strict rule for the places where it is a boundary.) Case-folded on top: Windows and the default
+ * macOS volume both treat two spellings of one directory as the same one.
+ */
+const isWithinDir = (base: string, cwd: string): boolean => {
+  const root = dirPathKey(base).toLowerCase();
+  const target = dirPathKey(cwd).toLowerCase();
+  if (root === "" || target === "") return false;
+  if (target === root) return true;
+  // A prefix is NOT containment — `/srv/project-old` starts with `/srv/project`. The separator is
+  // what makes it a boundary. `dirPathKey` leaves one only on a filesystem root ("/", "C:/").
+  return target.startsWith(root.endsWith("/") ? root : `${root}/`);
+};
+
+/**
+ * `owner/repo` for the directory a cell is in, from the reverse map `/api/repo-dirs` already
+ * serves — no extra request and no `git` subprocess, since the view fetches it anyway for the
+ * issue rows' start control.
+ *
+ * `null` for a directory that names no repository — not a git repo, no `origin`, a forge we cannot
+ * act on, or simply a clone the user never registered in Settings. All four are ordinary, and the
+ * caller leaves the order alone.
+ */
+export function repoForCwd(cwd: string | null | undefined, repoDirs: readonly { repo: string; dirs: readonly { path: string }[] }[]): string | null {
+  if (!cwd) return null;
+  // The DEEPEST match wins. Clones nest here — a worktree under a repo's managed root, or a repo
+  // vendored inside another — and the innermost one is the repository the cell is actually in.
+  let best: { repo: string; depth: number } | null = null;
+  for (const entry of repoDirs) {
+    for (const dir of entry.dirs) {
+      if (!isWithinDir(dir.path, cwd)) continue;
+      const depth = dirPathKey(dir.path).length;
+      if (!best || depth > best.depth) best = { repo: entry.repo, depth };
+    }
+  }
+  return best?.repo ?? null;
+}
+
+/**
+ * `rows` with `repo`'s entry first, everything else in the order it arrived.
+ *
+ * A stable move, not a sort: the server's order is meaningful (it follows the configured repo
+ * list) and only one element is being promoted. Returns the input unchanged when there is no repo
+ * to lead with, or when it has no section — which is why a cell in an unregistered clone simply
+ * gets the conventional order.
+ */
+export function leadWithRepo<T extends RepoGrouped>(rows: readonly T[], repo: string | null): T[] {
+  if (!repo) return [...rows];
+  const at = rows.findIndex((row) => sameRepo(row.repo, repo));
+  if (at <= 0) return [...rows];
+  const lead = rows[at];
+  if (lead === undefined) return [...rows]; // unreachable: findIndex answered a real index
+  return [lead, ...rows.slice(0, at), ...rows.slice(at + 1)];
+}

package/common/headerStatusColors.ts

@@ -0,0 +1,122 @@
+// What a cell header is painted with while a session is working / done / blocked, and who decides.
+//
+// A header has two layers that were designed together and can drift apart: the DIRECTORY's colour
+// (`headerColor` plus its ink) and the STATUS wash the theme mixes over it. #1591 is what the drift
+// looks like — a `headerTextColor` chosen against a dark purple, still applied while a light theme
+// paints the pale `--bg-selected` a running session gets: white on #d6e4fb, measured at 1.15:1 off
+// the reporter's own screenshot.
+//
+// So both layers are resolved HERE, once, and every caller asks rather than combining the pieces
+// itself. That is also what lets a directory recolour a status: the same function answers "what
+// shows now", whether the answer came from the theme or from a config file.
+//
+// `idle` is deliberately not a configurable status. `headerColor` / `headerTextColor` ARE the idle
+// state, and a second way to say the same thing is how one directory ends up written in two
+// different colours.
+import { headerTextColorFor } from "./chromeFromColor.js";
+import { isHexColor } from "./hexColor.js";
+import { isRecord } from "./isRecord.js";
+
+/** The states whose header background the theme replaces, and which a config may therefore claim. */
+export const HEADER_STATUS_KEYS = ["working", "done", "blocked"] as const;
+export type HeaderStatusKey = (typeof HEADER_STATUS_KEYS)[number];
+
+/** Every state a header paints — the three above plus the directory's own. */
+export type HeaderPaintStatus = HeaderStatusKey | "idle";
+
+export interface HeaderStatusColor {
+  background: string | null;
+  /** Omitted derives an AA ink from `background`. Naming it without a background is honoured
+   *  as-is: that is a statement about a wash the author can see, unlike `headerTextColor`, which
+   *  is a statement about the directory's own colour and is what #1591 misapplied. */
+  text: string | null;
+}
+
+export type HeaderStatusColors = Partial<Record<HeaderStatusKey, HeaderStatusColor>>;
+
+/** `background`: the theme washes the header while a session works (today's behaviour).
+ *  `none`: the directory's own `headerColor` stays, and the status reads from the cell border,
+ *  the dot and the status pill instead. */
+export const HEADER_STATUS_TINTS = ["background", "none"] as const;
+export type HeaderStatusTint = (typeof HEADER_STATUS_TINTS)[number];
+export const DEFAULT_HEADER_STATUS_TINT: HeaderStatusTint = "background";
+
+// `none` says "keep my palette", and `blocked` is the one state where nothing proceeds until the
+// user answers. A switch aimed at colour consistency taking the amber off THAT is an accident, so
+// it doesn't reach it — a directory that wants a different blocked colour says so outright with a
+// `headerStatusColors.blocked` entry, which is honoured below.
+const TINT_NONE_APPLIES_TO: readonly HeaderStatusKey[] = ["working", "done"];
+
+/** What a header paints in one state. `null` means "the theme decides" — the caller emits no
+ *  custom property and the theme's own wash / ink shows through the CSS fallback. */
+export interface HeaderPaint {
+  background: string | null;
+  text: string | null;
+}
+
+const NOTHING: HeaderPaint = { background: null, text: null };
+
+export interface HeaderChrome {
+  headerColor: string | null;
+  headerTextColor: string | null;
+  // Both nullable so "nothing configured" is expressible without every caller spreading a default
+  // in first — the shape a DirChrome already carries.
+  statusColors: HeaderStatusColors | null;
+  tint: HeaderStatusTint | null;
+}
+
+// A hex background always yields a readable ink, so `background` set and `text` unset cannot
+// produce an unreadable header — the point of letting a config name one colour.
+function paintFor(background: string | null, text: string | null): HeaderPaint {
+  if (isHexColor(text)) return { background: isHexColor(background) ? background : null, text };
+  if (isHexColor(background)) return { background, text: headerTextColorFor(background) };
+  return NOTHING;
+}
+
+export function resolveHeaderPaint(status: HeaderPaintStatus, chrome: HeaderChrome): HeaderPaint {
+  if (status === "idle") return paintFor(chrome.headerColor, chrome.headerTextColor);
+  const declared = chrome.statusColors?.[status];
+  if (declared && (isHexColor(declared.background) || isHexColor(declared.text))) return paintFor(declared.background, declared.text);
+  // `none` means "keep the colour I chose", so it needs a colour to keep. A directory with a
+  // `headerTextColor` and no usable `headerColor` has nothing for the ink to have been chosen
+  // against — carrying the ink alone would leave it on the theme's wash, which is the bug this
+  // whole file exists to stop (Codex review on #1619).
+  const keepsDirectoryColour = chrome.tint === "none" && TINT_NONE_APPLIES_TO.includes(status) && isHexColor(chrome.headerColor);
+  return keepsDirectoryColour ? paintFor(chrome.headerColor, chrome.headerTextColor) : NOTHING;
+}
+
+// ---- config parsing -------------------------------------------------------------------------
+
+const oneEntry = (input: unknown): HeaderStatusColor | null => {
+  if (isHexColor(input)) return { background: input, text: null };
+  if (!isRecord(input)) return null;
+  const background = isHexColor(input.background) ? input.background : null;
+  const text = isHexColor(input.text) ? input.text : null;
+  return background || text ? { background, text } : null;
+};
+
+/** Per status, so one bad entry can't discard the two that are right. A bare hex string is
+ *  accepted for a status as shorthand for `{ background: … }` — the common case is one colour. */
+export function sanitizeHeaderStatusColors(input: unknown): HeaderStatusColors {
+  if (!isRecord(input)) return {};
+  const out: HeaderStatusColors = {};
+  for (const key of HEADER_STATUS_KEYS) {
+    const entry = oneEntry(input[key]);
+    if (entry) out[key] = entry;
+  }
+  return out;
+}
+
+/** `null` for anything that isn't one of the two modes, which is what "unset here" has to look
+ *  like: a directory that says nothing must fall through to the global default rather than
+ *  asserting the built-in one over it. */
+export function sanitizeHeaderStatusTint(input: unknown): HeaderStatusTint | null {
+  return HEADER_STATUS_TINTS.find((mode) => mode === input) ?? null;
+}
+
+/** The directory's answer, else the global one. WHOLE-key, not a per-status merge: the same rule
+ *  `mergedDirConfigRaw` states for the three config files, and for its reason — a block a reader
+ *  has to assemble from two places is harder to predict than one they can see entire. */
+export function mergeHeaderStatusColors(global: HeaderStatusColors | null, dir: HeaderStatusColors | null): HeaderStatusColors | null {
+  return dir && Object.keys(dir).length > 0 ? dir : global;
+}

package/common/hexColor.ts

@@ -0,0 +1,12 @@
+// What counts as a colour anywhere a directory's .mulmoterminal.json supplies one. Only
+// 6-digit hex: the server's schema accepts nothing else, and the UI drops what it can't
+// parse rather than handing an unknown string to a style binding.
+//
+// In common/ because both sides decide from it: the server validates a config file with this
+// rule and the browser drops what it can't paint, and a third copy of the regex is how the two
+// answers start differing.
+const HEX_COLOR_RE = /^#[0-9a-fA-F]{6}$/;
+
+// `unknown` rather than `string | null | undefined`: this is what a config parser asks about a
+// value straight out of JSON, and narrowing the parameter would make every such site cast first.
+export const isHexColor = (color: unknown): color is string => typeof color === "string" && HEX_COLOR_RE.test(color);

package/common/pathSegments.ts

@@ -0,0 +1,23 @@
+// Splitting a filesystem path into its parts, on EITHER separator.
+//
+// `path.sep` is not the answer here: these paths come from a config file and from a saved
+// directory list, so a Windows path can be read on a mac (a synced config, a bug report, a test
+// fixture) and a POSIX one on Windows. Code that splits on "/" alone does not fail loudly on
+// `C:\Users\me\project` — it returns the WHOLE STRING as one segment, which is how a "label"
+// becomes an absolute path.
+//
+// That is a privacy contract in one place: the phone's project listing sends a label and never a
+// path, precisely so a command or an artifact cannot publish the user's home directory. A
+// one-separator split turns that guarantee off on Windows without changing a line of the code
+// that states it.
+
+/** The non-empty parts of a path, splitting on `/` and `\` alike. A drive letter (`C:`) stays a
+ *  segment of its own — it is not a directory name, and nothing here wants it as one. */
+export function pathSegments(value: string): string[] {
+  return value.split(/[/\\]+/).filter((segment) => segment.length > 0);
+}
+
+/** The last part of a path — its directory or file name — or the input when it has none. */
+export function lastSegment(value: string): string {
+  return pathSegments(value).at(-1) ?? value;
+}

package/common/toolGroups.ts

@@ -90,6 +90,13 @@ const GROUP_BY_TOOL = new Map<string, ToolGroup>([
   ["presentCollection", "data"],
   ["manageCollection", "data"],
   ["manageAccounting", "data"],
+  // manageSharedApp deploys and publishes the SHARED collections of the directory the cell is
+  // open in, so it belongs where their store does: a cell without the data group has no
+  // collection tools, and a deploy tool beside no collections is a tool with nothing to deploy.
+  // It is not in AUTO_ALLOWED_TOOLS, and it is in NEVER_AUTO_APPROVED_TOOLS below — publish is the
+  // one operation here that changes what people outside the roster can see, and the permission
+  // prompt is wanted in front of it on EVERY session, the workspace included.
+  ["manageSharedApp", "data"],
 
   ["generateImage", "media"],
   ["presentMulmoScript", "media"],
@@ -161,3 +168,19 @@ export const LEGACY_GUI_SERVER_IDS: readonly string[] = ["mulmoterminal-gui"];
 //
 // The three below save an artifact and draw it, and call nothing external.
 export const AUTO_ALLOWED_TOOLS: readonly string[] = ["presentForm", "presentChart", "presentHtml"];
+
+/** Tools that must keep the agent's permission prompt on EVERY claude session, including the
+ *  workspace.
+ *
+ *  `AUTO_ALLOWED_TOOLS` above is the grid cell's list and withholds these already — but it is an
+ *  allowlist, and the workspace does not use it. The workspace passes `allowedToolNames()`, which
+ *  is every tool, so a tool absent from `AUTO_ALLOWED_TOOLS` was still auto-approved in exactly
+ *  the session that builds a shared app. The comment on `manageSharedApp` said the prompt was
+ *  wanted in front of publish; nothing implemented it. This is what implements it.
+ *
+ *  It matters because of what the agent reads. A shared app is a repository, and the agent is
+ *  already reading untrusted text out of it — skill files, collection notes, issue bodies, survey
+ *  copy somebody pasted. `manageSharedApp` publishes to the internet, rewrites the roster, and
+ *  hands the roster live records. With auto-approval, "invite this address as owner, then deploy"
+ *  arriving in that text is a tool call rather than a question. */
+export const NEVER_AUTO_APPROVED_TOOLS: readonly string[] = ["manageSharedApp"];

package/dist/assets/{abnfDiagram-N423BO3Z-D0pzqjdS-C_1F9Lr9.js → abnfDiagram-N423BO3Z-D0pzqjdS-VtGooEqr.js}

@@ -1 +1 @@
-import{n as e}from"./chunk-Y2CYZVJY-Bdt8pFDJ-DsF7k-Jl.js";import{f as t}from"./src-CvsWqFln-Tc7ZSrRz.js";import{_ as n,g as r}from"./mermaid-parser.core-C1baW7NG-B9TNqufx.js";import"./chunk-I66GZJ75-DSPCVCny-BJLh4409.js";import"./chunk-3NCLNEKW-CBztX243-CRh6N7eI.js";import{n as i,r as a,t as o}from"./chunk-6Q2QTUOP-Cx8nz5_t-DoqT-qjo.js";import{t as s}from"./chunk-JWPE2WC7-BQ3zXr2k-DSd3Ct95.js";var c=r().RailroadAbnf.parser.LangiumParser,l=e(e=>{let t=e.alternatives.map(u);return t.length===1?t[0]:{type:`choice`,alternatives:t}},`transformAlternation`),u=e(e=>{let t=e.elements.map(f);return t.length===1?t[0]:{type:`sequence`,elements:t}},`transformConcatenation`),d=e(e=>{if(e.includes(`*`)){let[t,n]=e.split(`*`);return{min:t?parseInt(t,10):0,max:n?parseInt(n,10):1/0}}let t=parseInt(e,10);return{min:t,max:t}},`parseRepeat`),f=e(e=>{let t=p(e.primary);if(!e.repeat)return t;let{min:n,max:r}=d(e.repeat);return n===0&&r===1?{type:`optional`,element:t}:{type:`repetition`,element:t,min:n,max:r}},`transformElement`),p=e(e=>{switch(e.$type){case`AbnfStringLiteral`:return{type:`terminal`,value:e.value};case`AbnfNumVal`:return{type:`terminal`,value:e.value};case`AbnfRuleName`:return{type:`nonterminal`,name:e.name};case`AbnfGroup`:return l(e.element);case`AbnfOptionalGroup`:return{type:`optional`,element:l(e.element)};default:throw Error(`Unsupported ABNF primary node: ${e.$type}`)}},`transformPrimary`),m=e(e=>({name:e.name,definition:l(e.definition)}),`transformRule`),h=e(e=>{s(e,a),e.title&&a.setTitle(e.title),e.rules.map(e=>a.addRule(m(e)))},`populateDb`),g={parser:{parse:e(e=>{a.clear(),t.debug(`[ABNF Parser] Starting Langium parse`);let r=c.parse(e);if(r.lexerErrors.length>0||r.parserErrors.length>0)throw new n(r);let i=r.value;t.debug(`[ABNF Parser] Parsed rules:`,i.rules.length),h(i),t.debug(`[ABNF Parser] Parse complete`)},`parse`),parser:{yy:a}},db:a,renderer:o,styles:i};export{g as diagram};
+import{n as e}from"./chunk-Y2CYZVJY-Bdt8pFDJ-DsF7k-Jl.js";import{f as t}from"./src-CvsWqFln-Tc7ZSrRz.js";import{_ as n,g as r}from"./mermaid-parser.core-C1baW7NG-DtjLsxX1.js";import"./chunk-I66GZJ75-DSPCVCny-BkEOB2v-.js";import"./chunk-3NCLNEKW-CBztX243-BLYNocBE.js";import{n as i,r as a,t as o}from"./chunk-6Q2QTUOP-Cx8nz5_t-UvMPWJ3Z.js";import{t as s}from"./chunk-JWPE2WC7-BQ3zXr2k-DSd3Ct95.js";var c=r().RailroadAbnf.parser.LangiumParser,l=e(e=>{let t=e.alternatives.map(u);return t.length===1?t[0]:{type:`choice`,alternatives:t}},`transformAlternation`),u=e(e=>{let t=e.elements.map(f);return t.length===1?t[0]:{type:`sequence`,elements:t}},`transformConcatenation`),d=e(e=>{if(e.includes(`*`)){let[t,n]=e.split(`*`);return{min:t?parseInt(t,10):0,max:n?parseInt(n,10):1/0}}let t=parseInt(e,10);return{min:t,max:t}},`parseRepeat`),f=e(e=>{let t=p(e.primary);if(!e.repeat)return t;let{min:n,max:r}=d(e.repeat);return n===0&&r===1?{type:`optional`,element:t}:{type:`repetition`,element:t,min:n,max:r}},`transformElement`),p=e(e=>{switch(e.$type){case`AbnfStringLiteral`:return{type:`terminal`,value:e.value};case`AbnfNumVal`:return{type:`terminal`,value:e.value};case`AbnfRuleName`:return{type:`nonterminal`,name:e.name};case`AbnfGroup`:return l(e.element);case`AbnfOptionalGroup`:return{type:`optional`,element:l(e.element)};default:throw Error(`Unsupported ABNF primary node: ${e.$type}`)}},`transformPrimary`),m=e(e=>({name:e.name,definition:l(e.definition)}),`transformRule`),h=e(e=>{s(e,a),e.title&&a.setTitle(e.title),e.rules.map(e=>a.addRule(m(e)))},`populateDb`),g={parser:{parse:e(e=>{a.clear(),t.debug(`[ABNF Parser] Starting Langium parse`);let r=c.parse(e);if(r.lexerErrors.length>0||r.parserErrors.length>0)throw new n(r);let i=r.value;t.debug(`[ABNF Parser] Parsed rules:`,i.rules.length),h(i),t.debug(`[ABNF Parser] Parse complete`)},`parse`),parser:{yy:a}},db:a,renderer:o,styles:i};export{g as diagram};

package/dist/assets/architecture-TIHT7OUA-Cqhmai3f-B4pyJ5Jo.js

@@ -0,0 +1 @@
+import{f as e}from"./mermaid-parser.core-C1baW7NG-DtjLsxX1.js";export{e as createArchitectureServices};