mulmoterminal 4.8.2 → 4.8.3

package/README.md

@@ -595,6 +595,7 @@ The Settings modal (the gear button) persists per-user UI choices to `~/.mulmote
 | `worklogIntervalHours` | Worklog cadence in hours (default `6`, clamped to `1`–`168`). A stepper in the same Settings section covers the range. |
 | `terminalSubmit` | Which bytes Claude reads as **submit** vs **newline**: `"cr"` (default — Enter submits, Shift+Enter makes a newline) or `"esc-cr"` (for a Claude Code rebound the other way). Applies to the keyboard **and** the phone remote-view submit, for **Claude sessions only** (shell/codex keep plain Enter). See the [Configuration guide](https://receptron.github.io/mulmoterminal/guide/en/config.html#terminal-submit). Settings → **Terminal keys** offers both, worded as behaviour. |
 | `copyOnSelect` | `true` puts a **mouse selection on the clipboard the moment it settles**, with no key pressed (the PuTTY / iTerm2 behaviour). **Off by default** — it changes the clipboard when you may only have meant to highlight something. There is a checkbox in Settings → **Terminal keys**, applied at once; a hand edit of the file needs a **server restart, then a tab reload** (the server reads this file once at startup, and the browser reads the value from it on load). Composes with the `copy` keymap action rather than replacing it. Over plain `http://` the browser gives a page no clipboard access, so a fallback asks xterm to copy instead; see the [Configuration guide](https://receptron.github.io/mulmoterminal/guide/en/config.html#copy-on-select). |
+| `questionPaneEnabled` | `true` offers a Claude session's **`AskUserQuestion` choices as buttons** in a pane beside the enlarged terminal. **The terminal's own dialog stays** and the pane drives it — a click presses the arrow keys and Enter in the real dialog, so either end can answer and the first one wins. Claude sessions only (the choices arrive on Claude Code's hooks). A **single** question can also be answered in your own words — a text box under the buttons writes into the dialog's own `Type something` row; several questions at once, or a multi-select one, get buttons only, and `Chat about this` stays in the terminal. **Off by default** — it lets a pane type into your terminal. Checkbox in Settings → **Terminal keys**, applied at once (the server re-reads the file per question). See the [Feature reference](https://receptron.github.io/mulmoterminal/guide/en/features.html#question-pane). |
 | `decisionDigest` | Keep a **Markdown digest of the decisions this project's sessions asked for**, refreshed at startup and every few hours, so an agent can read what has already been decided before asking something similar. Written to `~/.mulmoterminal/decisions/<project>.md` (never into your repository) and served to agents by the bundled `mulmoterminal-decisions` skill. **Off by default** — it is a vision-stage idea, and it writes a file that would otherwise not exist. The digest holds dated facts, never inferred rules. Settings → **Sessions and background tasks** has the switch. |
 | `issueWorkComments` | Let a cell **comment on the issue it is working on**: **one comment**, posted when the work starts and then **edited** as the PR opens and merges (closing the issue if the forge has not already), each milestone stamped in UTC. The comment names the working **directory** it happened in — the folder name only, never the path — so a reader can tell which clone, and two terminals do not start the same issue twice. It says it came from MulmoTerminal. CI is deliberately not reported: it is on the PR already, and it flaps. **Off by default**; it writes to the forge, often on somebody else's issue. Needs the matching CLI logged in — `gh` for GitHub, `glab` for gitlab.com and any host declared in `gitlabHosts`. See the [Configuration guide](https://receptron.github.io/mulmoterminal/guide/en/config.html#issue-work-comments). Editable in Settings → **GitHub and GitLab**. |
 | `prWorkdirFooter` | Ends a PR body with `work in <clone>` — the directory name of the clone the work happened in, so a PR says which of several side-by-side checkouts produced it. Applies to **both** paths that open PRs here: **⧉ Open PR** appends it to the PR it creates, and every Claude session is told to end the bodies it writes with the same line (the name is resolved by the server, so a session inside a managed worktree still names the main checkout). **On by default**; set `false` to opt out, from Settings → **GitHub and GitLab** or the file — read per PR and per session spawn, so no restart is needed, and a second MulmoTerminal beside this one sees the change too. Appending is idempotent: an existing PR never gets a second copy. |

package/common/askQuestion.ts

@@ -0,0 +1,217 @@
+import { isRecord } from "./isRecord.js";
+
+// The pub/sub channel carrying "this session is asking the user a question". Both sides decide
+// from it — the server publishes what the PreToolUse hook reported, the pane listens to know a
+// dialog is up and what it offers — so the name and the payload shape live here.
+export const ASK_QUESTION_CHANNEL = "ask-question";
+
+/** The tool name whose input this module reads. Claude Code's built-in question dialog. */
+export const ASK_QUESTION_TOOL = "AskUserQuestion";
+
+export interface AskOption {
+  label: string;
+  description?: string;
+}
+
+export interface AskQuestion {
+  question: string;
+  header: string;
+  options: AskOption[];
+  multiSelect: boolean;
+}
+
+export interface AskQuestionEvent {
+  sessionId: string;
+  toolUseId: string;
+  questions: AskQuestion[];
+}
+
+/** The same dialog, now answered — in the terminal, in the pane, or cancelled with Esc. The pane
+ *  drops its buttons on this: keys aimed at a dialog that has closed would reach the prompt
+ *  underneath, where Down walks the input history and Enter would re-submit what it found. */
+export interface AskQuestionDone {
+  sessionId: string;
+  toolUseId: string;
+  done: true;
+}
+
+const parseOption = (value: unknown): AskOption | null => {
+  if (!isRecord(value) || typeof value.label !== "string" || !value.label) return null;
+  return typeof value.description === "string" ? { label: value.label, description: value.description } : { label: value.label };
+};
+
+const isOption = (value: AskOption | null): value is AskOption => value !== null;
+
+const parseQuestion = (value: unknown): AskQuestion | null => {
+  if (!isRecord(value) || typeof value.question !== "string" || !Array.isArray(value.options)) return null;
+  const options = value.options.map(parseOption).filter(isOption);
+  // Length mismatch means one option failed to parse: answering by index against a list we
+  // could not read whole would pick the wrong row, so the whole question is rejected instead.
+  if (options.length === 0 || options.length !== value.options.length) return null;
+  return { question: value.question, header: typeof value.header === "string" ? value.header : "", options, multiSelect: value.multiSelect === true };
+};
+
+const isQuestion = (value: AskQuestion | null): value is AskQuestion => value !== null;
+
+/** Read a PreToolUse `tool_input` for AskUserQuestion. Null when it is not one, or not whole. */
+export const parseAskQuestions = (toolInput: unknown): AskQuestion[] | null => {
+  if (!isRecord(toolInput) || !Array.isArray(toolInput.questions)) return null;
+  const questions = toolInput.questions.map(parseQuestion).filter(isQuestion);
+  if (questions.length === 0 || questions.length !== toolInput.questions.length) return null;
+  return questions;
+};
+
+const identifiesADialog = (data: unknown): data is Record<string, unknown> & { sessionId: string; toolUseId: string } =>
+  isRecord(data) && typeof data.sessionId === "string" && typeof data.toolUseId === "string";
+
+export const isAskQuestionEvent = (data: unknown): data is AskQuestionEvent =>
+  identifiesADialog(data) && data.done !== true && parseAskQuestions(data) !== null;
+
+export const isAskQuestionDone = (data: unknown): data is AskQuestionDone => identifiesADialog(data) && data.done === true;
+
+// The close is published even while the pane is switched OFF, and only the offer is gated.
+// Turning the switch off mid-dialog would otherwise strand a pane that is already showing
+// buttons: the dialog closes, nothing says so, and the next click sends Down/Enter into the
+// prompt underneath — the exact stale-input case the close exists to prevent. A close for a
+// question that was never offered is a no-op in the pane, so this costs nothing when the switch
+// was off all along, and it carries no question text either way.
+export const shouldPublishQuestion = (event: AskQuestionEvent | AskQuestionDone, paneEnabled: boolean): boolean => isAskQuestionDone(event) || paneEnabled;
+
+/** As much of a recorded tool call as picking the open dialog out of a history needs. */
+export interface RecordedCall {
+  toolUseId?: string | undefined;
+  toolName?: string | undefined;
+  toolInput?: unknown;
+  status?: string | undefined;
+}
+
+// The dialog a session is blocked on right now, rebuilt from its tool-call history. The pane's
+// channel is event-only and replays nothing on reconnect, so a browser that reloads between the
+// question and its answer would otherwise never learn about a session that is waiting — and with
+// no button to open the pane, that question becomes unanswerable from the browser entirely.
+//
+// The LAST call, not the last one that happens to still say `running`. A session blocked on a
+// question runs nothing else until it is answered, so a later call is proof the question is over —
+// however it ended. Scanning back instead would keep offering a dialog whose close never arrived
+// (an interrupted turn, a `/clear`, a hook that did not land) long after the agent moved on, and
+// the buttons would type into whatever the screen became.
+export const openQuestionOf = (calls: readonly RecordedCall[], sessionId: string): AskQuestionEvent | null => {
+  const last = calls[calls.length - 1];
+  if (last?.toolName !== ASK_QUESTION_TOOL || last.status !== "running" || !last.toolUseId) return null;
+  const questions = parseAskQuestions(last.toolInput);
+  return questions ? { sessionId, toolUseId: last.toolUseId, questions } : null;
+};
+
+/** Why an answer did not reach the dialog. Serialized by the host, rendered by every client, so
+ *  the values live here rather than once per layer — a drift between them is a client showing the
+ *  wrong explanation, or none. */
+export type AnswerFailure =
+  /** The dialog was answered (in the terminal, or by another client) before this arrived. */
+  | "closed"
+  /** picks do not fit the questions — wrong count, out of range, or not ascending. */
+  | "bad-picks"
+  /** No PTY in this process to type into: the session outlived a server restart. */
+  | "unwritable"
+  /** Some keys reached the dialog before the rest were abandoned. Its cursor has moved and its
+   *  boxes may be ticked, so where it stands is no longer knowable from here — a fresh sequence
+   *  would be computed from a state the dialog left behind and could commit a different answer. */
+  | "partial";
+
+export type AnswerResult = { ok: true } | { ok: false; reason: AnswerFailure };
+
+/** The body of `POST /api/question/:sessionId/answer`. The session comes from the route path, not
+ *  from here — a client names the dialog it is answering, never the session it belongs to. */
+export interface AnswerRequestBody {
+  toolUseId: string;
+  /** Chosen option indexes, one entry per question. */
+  picks?: number[][];
+  /** Or the user's own words, for the dialog's text row. */
+  text?: string;
+}
+
+/** Read a request body's SHAPE. Whether the picks or the words fit the dialog is decided against
+ *  the questions the host itself recorded — see server/session/answerQuestion.ts. */
+export const readAnswerRequest = (body: unknown): AnswerRequestBody | null => {
+  if (!isRecord(body) || typeof body.toolUseId !== "string") return null;
+  const text = typeof body.text === "string" ? { text: body.text } : {};
+  return { toolUseId: body.toolUseId, ...(body.picks === undefined ? {} : { picks: readPickRows(body.picks) }), ...text };
+};
+
+// Rows of numbers, or nothing. A row that is not that is dropped to `[]` rather than coerced: the
+// host then refuses it as bad-picks, and a coerced pick is a keystroke aimed at a row nobody chose.
+const readPickRows = (picks: unknown): number[][] =>
+  Array.isArray(picks) ? picks.map((row) => (Array.isArray(row) ? row.filter((idx): idx is number => typeof idx === "number") : [])) : [];
+
+export const isAnswerFailure = (value: unknown): value is AnswerFailure =>
+  value === "closed" || value === "bad-picks" || value === "unwritable" || value === "partial";
+
+const KEY_DOWN = "\x1b[B";
+const KEY_ENTER = "\r";
+
+// The dialog lists MORE rows than `options`: a "Type something" row follows them, and a
+// multi-select question puts its Submit row after that. So Submit sits at options.length + 1.
+// Measured against claude 2.1.231, not inferred from the tool schema — the extra rows exist
+// only on screen, and reading the schema alone would aim every multi-select Enter one row short.
+const submitRow = (options: readonly AskOption[]): number => options.length + 1;
+
+const moveDown = (from: number, to: number): string[] => Array.from({ length: Math.max(0, to - from) }, () => KEY_DOWN);
+
+// Enter TOGGLES a multi-select row and leaves the cursor where it is, so each pick is
+// "walk down to it, toggle", and the walk starts from the previous pick rather than the top.
+const toggleEach = (picks: readonly number[]): { keys: string[]; cursor: number } =>
+  picks.reduce<{ keys: string[]; cursor: number }>(({ keys, cursor }, idx) => ({ keys: [...keys, ...moveDown(cursor, idx), KEY_ENTER], cursor: idx }), {
+    keys: [],
+    cursor: 0,
+  });
+
+const keysForOne = (question: AskQuestion, picks: readonly number[]): string[] => {
+  if (!question.multiSelect) return [...moveDown(0, picks[0] ?? 0), KEY_ENTER];
+  const { keys, cursor } = toggleEach(picks);
+  return [...keys, ...moveDown(cursor, submitRow(question.options)), KEY_ENTER];
+};
+
+// Ascending and distinct, because the walk above only ever moves DOWN: an out-of-order pick
+// would silently toggle the wrong row rather than fail.
+const picksValid = (question: AskQuestion, picks: readonly number[]): boolean => {
+  const inRange = picks.every((idx) => Number.isInteger(idx) && idx >= 0 && idx < question.options.length);
+  const ascending = picks.every((idx, i) => i === 0 || idx > (picks[i - 1] ?? -1));
+  return inRange && ascending && (question.multiSelect || picks.length === 1);
+};
+
+// The review screen ("Ready to submit your answers?", with Submit preselected) appears for every
+// shape EXCEPT a lone single-select question, which commits on the option's own Enter. All four
+// shapes were measured; guessing here either leaves the dialog open or drops a stray Enter into
+// the prompt once it has closed.
+const needsReview = (questions: readonly AskQuestion[]): boolean => questions.length > 1 || questions.some((question) => question.multiSelect);
+
+// Answering in the user's own words, through the dialog's own `Type something` row.
+//
+// That row IS a text field, and the way in is to highlight it and type: the row then reads back what
+// was typed, and Enter commits it as the ANSWER — `answers` carries the words, not a decline.
+// Measured against claude 2.1.231. (Enter on the row while it is still empty declines instead,
+// which is what a first reading of it mistook for its whole behaviour.)
+//
+// It sits directly after that question's options.
+export const keysToAnswerInWords = (questions: readonly AskQuestion[], text: string): string[] | null => {
+  const only = questions.length === 1 ? questions[0] : undefined;
+  // The one shape this was measured on: a lone SINGLE-select question, where the text row's Enter
+  // is the whole answer. The others each end somewhere this sequence does not reach — a wizard
+  // moves on to its next question, and a multi-select dialog stops at its review screen — and the
+  // host would claim the dialog while the terminal still waits for something the pane cannot send.
+  if (!only || only.multiSelect || !text) return null;
+  return [...moveDown(0, only.options.length), text, KEY_ENTER];
+};
+
+/**
+ * The keystrokes that answer a live AskUserQuestion dialog. `picks[i]` holds the chosen option
+ * indexes of `questions[i]` — exactly one for a single-select question, any ascending set for a
+ * multi-select one. Null when the picks do not fit the questions, so a caller cannot half-drive
+ * a dialog it has misread.
+ */
+export const keysForAnswers = (questions: readonly AskQuestion[], picks: readonly (readonly number[])[]): string[] | null => {
+  if (questions.length === 0 || picks.length !== questions.length) return null;
+  const paired = questions.map((question, i) => ({ question, picks: picks[i] ?? [] }));
+  if (!paired.every(({ question, picks: chosen }) => picksValid(question, chosen))) return null;
+  const keys = paired.flatMap(({ question, picks: chosen }) => keysForOne(question, chosen));
+  return needsReview(questions) ? [...keys, KEY_ENTER] : keys;
+};

package/common/gitlabHosts.ts

@@ -10,7 +10,18 @@ import { GITHUB_HOST, GITLAB_HOST } from "./repoEntry.js";
 // A hostname, lower case, with at least one dot. The dot is not cosmetic: `parseRepoEntry` reads a
 // leading segment as a host ONLY when it contains one, so a dotless declaration could never match
 // an entry and would sit in the config doing nothing.
-const HOSTNAME_RE = /^[a-z0-9]([a-z0-9-]*[a-z0-9])?(\.[a-z0-9]([a-z0-9-]*[a-z0-9])?)+$/;
+// Tested per label rather than as one hostname pattern: the single-regex form nested `[a-z0-9-]*`
+// inside the repeated dotted group, which is the shape that goes exponential on input that almost
+// matches. Measured, this one did not — but the per-label form removes the class instead of
+// depending on that, and reads as the rule it enforces.
+const LABEL_RE = /^[a-z0-9][a-z0-9-]*$/;
+
+const isLabel = (label: string): boolean => LABEL_RE.test(label) && !label.endsWith("-");
+
+const isHostname = (host: string): boolean => {
+  const labels = host.split(".");
+  return labels.length > 1 && labels.every(isLabel);
+};
 
 const SCHEME_RE = /^https?:\/\//;
 
@@ -26,7 +37,7 @@ const GITLAB_HOSTS_MAX = 20;
 export function normalizeGitlabHost(input: unknown): string | null {
   if (typeof input !== "string") return null;
   const host = input.trim().toLowerCase().replace(SCHEME_RE, "").replace(/\/$/, "");
-  return HOSTNAME_RE.test(host) ? host : null;
+  return isHostname(host) ? host : null;
 }
 
 /** The declared hosts, de-duplicated and capped. Anything unusable is dropped rather than failing

package/common/terminalReplies.ts

@@ -0,0 +1,66 @@
+// What a terminal emulator sends back on the INPUT channel without anyone typing.
+//
+// xterm.js answers the application's own queries there: device attributes, the foreground and
+// background colours, the cursor position. It also says when the terminal gained or lost focus.
+// All of it arrives exactly as a keystroke does, and none of it is the user answering anything.
+//
+// That matters to anything asking "has the user typed since this question appeared?"
+// (server/session/write-to-session.ts). Counting these replies meant an answer from the question
+// pane was refused after any attach, resize or theme read — measured, not guessed: a single button
+// press was preceded by `ESC[?1;2c`, `ESC[>0;276;0c` and two OSC colour replies (#1693).
+//
+// MOUSE reports are deliberately absent. They look the same on the wire, but a click can select an
+// option in the dialog — that is the user answering, and an answer already being typed must yield
+// to it exactly as it yields to a keystroke.
+//
+// The forms are spelled out rather than generalised — no "any OSC", no "any CSI". This list decides
+// what CANNOT interrupt an answer, so a pattern wider than the replies actually queried would hand
+// that exemption to input nobody has looked at.
+const ESC = "\u001b";
+const BEL = "\u0007";
+const ST = `(?:${BEL}|${ESC}\\\\)`;
+
+const REPLIES = [
+  `${ESC}\\[[IO]`, // focus in / out
+  `${ESC}\\[\\?[\\d;]*c`, // primary device attributes
+  `${ESC}\\[>[\\d;]*c`, // secondary / tertiary device attributes
+  `${ESC}\\[\\d+;\\d+R`, // cursor position report
+  `${ESC}\\]1[0-9];rgb:[\\da-fA-F/]*${ST}`, // colour queries — foreground, background, cursor
+].join("|");
+
+const ANY_REPLY = new RegExp(REPLIES, "g");
+
+// A chunk can END mid-sequence: the socket splits where it likes, so `ESC[?1` and `;2c` can arrive
+// separately. Neither half matches, and both would read as "the user typed" — the very false alarm
+// this module exists to stop. A tail that could still GROW into a reply is held instead of judged.
+//
+// It stops before the terminating letter, which is what keeps a real key out of the holding pen:
+// `ESC[B` (Down) carries its `B` already and cannot be waiting for anything.
+//
+// A LONE Escape is never held. It is how the user cancels the dialog, and holding it would let a
+// paced answer carry on typing into a question they had just dismissed — while the reply it might
+// theoretically have grown into is written whole by the emulator, in one frame, every time.
+const STILL_GROWING = new RegExp(`^${ESC}(?:\\[[?>]?[\\d;]*|\\][\\d;]*(?:rgb:[\\da-fA-F/]*)?)$`);
+
+/** The longest tail worth holding. Bounded so a stream of junk cannot accumulate. */
+const MAX_PENDING = 64;
+
+export interface InputScan {
+  /** Did anything in this chunk come from the user? */
+  fromUser: boolean;
+  /** The unfinished tail, to be carried into the next chunk. */
+  pending: string;
+}
+
+/**
+ * Classify one chunk of terminal input, carrying `pending` from the chunk before it.
+ *
+ * `fromUser` is false only when everything is a reply the emulator produced by itself. A trailing
+ * sequence that is still growing is neither — it waits in `pending` until it finishes.
+ */
+export const scanForUserInput = (pending: string, data: string): InputScan => {
+  const chunk = `${pending}${data}`;
+  const rest = chunk.replace(ANY_REPLY, "");
+  if (rest.length > 0 && rest.length <= MAX_PENDING && STILL_GROWING.test(rest)) return { fromUser: false, pending: rest };
+  return { fromUser: rest.length > 0, pending: "" };
+};

package/dist/assets/{abnfDiagram-N423BO3Z-D0pzqjdS-VtGooEqr.js → abnfDiagram-N423BO3Z-D0pzqjdS-BUEzXU7-.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-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};
+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-Bbu-Zwi4.js";import"./chunk-I66GZJ75-DSPCVCny-j7cLCRvd.js";import"./chunk-3NCLNEKW-CBztX243-ChFYkHfP.js";import{n as i,r as a,t as o}from"./chunk-6Q2QTUOP-Cx8nz5_t-BOfQsmdP.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-DKxow7MX.js

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