mlx-bun 0.4.0 → 1.0.0

package/src/web/skills/memory/SKILL.md

@@ -1,120 +0,0 @@
----
-name: memory
-description: Use when the answer depends on the user's prior conversations or personal context: explicit memory/recall requests, named personal projects, people, preferences, decisions, or history not explained in the current chat. Do not use for weather, current public facts, generic web research, or ordinary coding/file tasks when current files are sufficient. Also use when the user wants to set up, inspect, or manage memory.
----
-
-# Memory
-
-The user has a personal **memory** — a wiki of Markdown articles synthesized
-from their past conversations, stored locally at `~/.mlx-bun/wiki/`. User memory
-articles live under `articles/`. Read-only mlx-bun reference docs live under
-`Reference/` as symlinks and are also searchable/readable, but synthesis never
-writes them. Each user article is the consolidated, finished understanding of one
-topic. Your job is to *use it* so the user never has to re-explain what they've
-already told you.
-
-It is entirely local: the articles, the synthesis, and these tools all run on
-the user's machine. Nothing about their memory leaves the device.
-
-## Consulting memory (the common case)
-
-When the answer depends on personal continuity — an explicit memory/recall
-request, or a named project, person, decision, preference, or history that is
-not explained in the current chat — look it up **before** answering or asking
-the user to re-explain. Doing the lookup first, instead of answering from first
-principles, is itself the helpful move.
-
-Do **not** use memory for weather, current public facts, generic web research,
-or ordinary coding/file tasks when the current files or the web tools answer the
-question. Memory is for user-specific context, not for performing familiarity.
-
-The read path is **FIND the article → READ it small → answer**. It is
-deterministic navigation — never a vector search, and there is no way to
-query/sort articles by an infobox field (the infobox is facts you *read*, via
-`memory_infobox`, not a filter).
-
-1. **FIND the article.**
-   - When the user names a specific thing, person, or project, call
-     `memory_resolve` with the name as said ("S5 IIX", "the Lumix"). It returns
-     the matched stem, title, kind, and lead — no search, no guessing.
-   - For "what do I have about X", call `memory_category` with a `category`
-     (e.g. `Lenses`), `type`, or `series`. This is membership, not search: it
-     lists the articles that are actually about X.
-2. **READ it small (the default).** Call `memory_read` to get the article's TOC
-   + lead, then `memory_section` to read just the **one** section you need. The
-   whole article is the exception — pass `force=true` only when you truly need
-   all of it. The article is the user's consolidated current position; read it
-   rather than reconstructing their view from scattered fragments.
-3. **Follow the graph / read the infobox when useful.** `memory_links` shows
-   outgoing links grouped by origin (infobox / series / see also / prose) plus
-   backlinks — use it to hop to a neighbour (e.g. from a camera's infobox
-   `mount: [[L-Mount]]` to the mount article). `memory_infobox` surfaces the
-   structured facts to read. `memory_list` is a bare overview;
-   `memory_status` answers setup/schedule/location questions. mlx-bun reference
-   docs are separate from personal memory; use `reference_search`,
-   `reference_read`, and `reference_list` for those.
-4. **`memory_search` is the LAST resort.** Only fall back to it when
-   `memory_resolve` / `memory_category` have failed across a couple of
-   phrasings. It is a plain substring scan that doesn't understand meaning.
-5. **Use it silently, as a continuation.** Let what you find shape your response
-   like a long-time colleague who already knows the state of things. Speak as a
-   continuation, never as a retrieval report: do not preface answers with "per
-   the wiki…", "according to the article…", "I checked your memory…", or
-   "welcome back, I see you're working on X". Cite an article by name only if
-   the user asks where something came from, or to distinguish "the wiki says X"
-   from "I think Y".
-
-Use memory as an invisible prior: it should narrow relevance and improve the
-answer, not become the topic of the answer. Avoid performative recall — do not
-name-drop unrelated remembered facts to sound familiar.
-
-## Opening memory for the user
-
-The wiki is a normal Markdown/Obsidian vault. If the user asks to browse, open,
-inspect, or edit their memory directly, you may open it for them after a brief
-confirmation:
-
-```bash
-mlx-bun memory open
-mlx-bun memory open <article>
-```
-
-The first form opens `~/.mlx-bun/wiki/` in Obsidian when available, falling back
-to the folder in Finder. The second form opens a specific article stem such as
-`Archie_Project` directly in Obsidian, falling back to the default Markdown app.
-Opening the vault or article is allowed; editing articles during chat is not. If
-the user wants a change to become durable memory, keep the conversation natural
-and let synthesis incorporate it later, unless they explicitly ask to edit files
-by hand in Obsidian.
-
-## Setting up memory (if it doesn't exist yet)
-
-If memory isn't set up (the memory tools aren't available, or the user asks to
-turn it on), explain it plainly and set it up on agreement:
-
-> Your memory is a folder of Markdown articles at `~/.mlx-bun/wiki/`,
-> synthesized from your conversations so I can remember your context across
-> sessions. It's a normal git-tracked wiki you fully own and can edit or
-> delete — and it never leaves your machine.
-
-On a yes, run the setup via the bash tool (the user approves it):
-
-```
-mlx-bun memory init
-```
-
-This creates the vault and walks through optional steps (importing an existing
-wiki, scheduling nightly synthesis). Confirm before each persistent action.
-
-## What not to do
-
-- Don't claim a fact "from memory" that you didn't read in an article — find
-  and read the article first, or say you don't have it.
-- Don't write to or edit the wiki during a normal conversation; the read tools
-  are read-only by design. Synthesis is a separate, deliberate step.
-- Do open the wiki or a specific article in Obsidian/Finder if the user asks to
-  browse or edit their memory themselves (`mlx-bun memory open [article]`).
-- Don't dump article contents at the user verbatim — use them to inform a
-  direct, relevant answer.
-- Don't perform familiarity. If the user asks for weather, current facts, or a
-  normal coding task, use the task-appropriate tool instead of memory.

package/src/web/skills/web-research/SKILL.md

@@ -1,46 +0,0 @@
----
-name: web-research
-description: Use only when the user asks you to research something, do a deep dive, fact-check a claim, compare options, or answer a question that needs current, accurate, real-world information ("what's the latest on…", prices, releases, news, specs). Do not use for ordinary conversation, ordinary coding tasks, or questions answerable from the current conversation/files.
----
-
-# Web Research
-
-A workflow for answering questions that need current, accurate, real-world
-information, using the `web_search` and `web_fetch` tools. The goal is a
-trustworthy, well-sourced answer — not a guess dressed up as one.
-
-## When to use this
-
-- The answer depends on current events, recent releases, prices, versions,
-  or anything that changes over time.
-- The user wants a thorough or authoritative answer, or asks for sources.
-- A specific claim needs verifying, or you would otherwise be speculating.
-
-Do **not** use this for ordinary conversation that does not require external information. In that case, reply naturally instead of explaining the research workflow.
-
-## Workflow
-
-1. **Plan.** Restate the question in your own words and list the 2–4 concrete
-   things you need to find out. This keeps the searches focused.
-2. **Search broadly.** Call `web_search` with a few focused queries — one idea
-   per query — rather than a single vague one. Vary the wording if the first
-   results are weak.
-3. **Read the best sources.** Use `web_fetch` to actually read the most
-   relevant results. Prefer primary sources (official docs, the original
-   announcement, the paper, the vendor's own page) over blogs and aggregators.
-   Read at least two or three independent sources.
-4. **Cross-check.** Confirm each key fact appears in more than one independent
-   source. Where sources disagree, surface the disagreement instead of picking
-   one silently.
-5. **Answer.** Lead with a direct answer, then the supporting detail. Cite
-   every nontrivial claim with a Markdown link to a page you actually fetched.
-   Separate what's well-supported from what's uncertain.
-
-## Quality rules
-
-- Check publication dates; for fast-moving topics, prefer recent sources.
-- Never cite a page you didn't fetch, and never invent quotes, numbers, or URLs.
-- Quote sparingly and exactly.
-- If the sources are thin or conflicting, say so plainly — don't overstate
-  confidence to sound complete.
-- If a search returns nothing useful, try different terms before giving up.

package/src/web/skills.ts

@@ -1,97 +0,0 @@
-// mlx-bun bundled skills — curated pi skills the web chat ships with.
-//
-// Why materialize to disk? pi loads skills by reading SKILL.md from a
-// filesystem path, but mlx-bun also ships as a single `bun build --compile`
-// binary where source files don't exist on disk. So each SKILL.md is
-// embedded into the bundle as a text import (the same trick app.html uses)
-// and written to ~/.mlx-bun/skills/<name>/SKILL.md at startup. One source of
-// truth that resolves identically when run from source and from the binary —
-// no build-script changes, no sidecar files.
-//
-// These load via DefaultResourceLoader.additionalSkillPaths even though the
-// web session keeps noSkills:true: that flag only disables auto-discovery of
-// the user's personal ~/.pi and project .pi skills, so the chat stays
-// isolated while still getting our curated set (resource-loader.js:277).
-//
-// Memory is deliberately gated by vault existence. If memory is not enabled,
-// we do not expose its skill at all; otherwise small local models can fixate on
-// the skill description even when the user asks unrelated things like weather.
-//
-// To add a skill: drop a folder under ./skills/<name>/SKILL.md, add a text
-// import for it, and append it to BUNDLED_SKILLS.
-
-import { mkdirSync, writeFileSync } from "node:fs";
-import { homedir } from "node:os";
-import { join } from "node:path";
-import webResearchMd from "./skills/web-research/SKILL.md" with { type: "text" };
-import memoryMd from "./skills/memory/SKILL.md" with { type: "text" };
-
-interface BundledSkill {
-  /** Directory name under the skills root; should match the SKILL.md `name`. */
-  name: string;
-  /** Raw SKILL.md contents, embedded at build time. */
-  md: string;
-}
-
-const BUNDLED_SKILLS: readonly BundledSkill[] = [
-  { name: "web-research", md: webResearchMd },
-  { name: "memory", md: memoryMd },
-];
-
-export interface BundledSkillOptions {
-  /** Include the web-research workflow skill. Default false: tool schemas are enough, and small local models can over-apply workflow skills. */
-  includeWebResearch?: boolean;
-  /** Include the personal-memory skill. Default true for backward compatibility. */
-  includeMemory?: boolean;
-}
-
-/** Where the bundled skills are written; also pi's per-session scratch root. */
-export function bundledSkillsRoot(): string {
-  return join(homedir(), ".mlx-bun", "skills");
-}
-
-/** Memoize: the embedded content can't change within a process run. */
-const materialized = new Set<string>();
-
-/**
- * Write the embedded skills to disk (overwriting, so updates propagate) and
- * return the root directory to pass as a single additionalSkillPaths entry.
- * pi scans it for per-skill SKILL.md files. Runs its disk writes once per
- * process even when called per browser connection.
- */
-function selectedSkills(opts: BundledSkillOptions = {}): readonly BundledSkill[] {
-  const includeMemory = opts.includeMemory ?? true;
-  const includeWebResearch = opts.includeWebResearch ?? false;
-  return BUNDLED_SKILLS.filter((skill) => {
-    if (!includeMemory && skill.name === "memory") return false;
-    if (!includeWebResearch && skill.name === "web-research") return false;
-    return true;
-  });
-}
-
-/**
- * Materialize selected bundled skills and return exact skill directories. Use
- * these paths in DefaultResourceLoader.additionalSkillPaths. Returning exact
- * directories (rather than the shared root) prevents an old on-disk memory
- * skill from being discovered when memory is disabled for the current session.
- */
-export function materializeBundledSkillPaths(opts: BundledSkillOptions = {}): string[] {
-  const root = bundledSkillsRoot();
-  const paths: string[] = [];
-  for (const skill of selectedSkills(opts)) {
-    const dir = join(root, skill.name);
-    if (!materialized.has(skill.name)) {
-      mkdirSync(dir, { recursive: true });
-      writeFileSync(join(dir, "SKILL.md"), skill.md);
-      materialized.add(skill.name);
-    }
-    paths.push(dir);
-  }
-  return paths;
-}
-
-/** Backward-compatible root materializer for older call sites. Prefer materializeBundledSkillPaths(). */
-export function materializeBundledSkills(): string {
-  materializeBundledSkillPaths({ includeMemory: true, includeWebResearch: true });
-  return bundledSkillsRoot();
-}

package/src/web/src/adapters-panel.ts

@@ -1,288 +0,0 @@
-// GENERATED-ADJACENT source module — part of the src/web/src/* split (plan
-// §7/§9 Phase 2). Built into src/web/app.js by scripts/build-web.ts.
-//
-// Adapter routing table (plan §5.6, §9 Phase 2): the deep surface behind
-// the composer's ⚙ button beside #chat-adapter. Shows every on-disk
-// adapter with its three states (available / loaded+mounted /
-// selected-for-this-chat), base model, rank, size on disk, and RAM cost
-// when mounted (GET /v1/adapters now reports `ram_bytes` — see
-// docs/reference/server-api.md), with compatible-graying and a why-not
-// tooltip. Actions: mount, select, unselect, and stack two compatible
-// adapters as "a+b" — resolveSpec/injectAdapter already support composite
-// ids end to end (proved in tests/research/pi-web.test.ts's stacking test; the
-// shape-validated mount is proved against real weights in the
-// MLX_BUN_TEST_LORA=1-gated tests/parity/lora.test.ts).
-//
-// Single source of SELECTION state, not a single fetch: composer.ts's quick
-// <select> and this table each hit /v1/adapters(+/available) independently
-// (same endpoints, same shapes) rather than sharing one in-memory cache —
-// but chat.ts keeps them from disagreeing about what's SELECTED by writing
-// through both on every change (adapterSel.onchange syncs
-// adaptersPanel.selectedSpec; this table's actions sync #chat-adapter's
-// value back). What must never drift is which adapter(s) are active for
-// the chat, not which HTTP call fetched the list.
-
-import { $, toast, trapFocus, setAdaptersPanelClose, type FocusTrap } from "./shell";
-import { api } from "./api";
-import { esc } from "./markdown";
-
-/** Shape returned by GET /v1/adapters/available (on-disk, unfiltered). */
-export interface AvailableAdapterRow {
-  id: string;
-  path: string;
-  rank: number | null;
-  scale: number;
-  base_model: string | null;
-  mounted: boolean;
-  compatible: boolean;
-}
-
-/** Shape returned by GET /v1/adapters (mounted only, with RAM cost). */
-export interface MountedAdapterRow {
-  id: string;
-  path: string;
-  rank: number | null;
-  scale: number;
-  size_bytes: number;
-  mounted_layers: number;
-  ram_bytes: number;
-}
-
-function fmtBytes(n: number | null | undefined): string {
-  if (n == null) return "—";
-  if (n >= 2 ** 20) return (n / 2 ** 20).toFixed(1) + " MB";
-  if (n >= 2 ** 10) return (n / 2 ** 10).toFixed(1) + " KB";
-  return n + " B";
-}
-
-/** Send callback type shared with the rest of chat.ts's WS wiring. */
-type Send = (obj: unknown) => boolean;
-
-export class AdaptersPanelState {
-  available: AvailableAdapterRow[] = [];
-  mounted: Map<string, MountedAdapterRow> = new Map();
-  /** The composer's current single-select value ("" = none), kept in sync
-   *  so the table can show which one/ones are "selected for this chat". */
-  selectedSpec: string | null = null;
-  /** Multi-select scratch state for the "stack" flow — ids the user has
-   *  ticked in the table before hitting "apply stack". Cleared on apply. */
-  stackPicks: Set<string> = new Set();
-}
-
-let trap: FocusTrap | null = null;
-
-/** Fetch both adapter endpoints once and refresh every dependent view: the
- *  table body (if open, with its actions re-wired against `send`) and the
- *  composer's quick <select> (renderAdapterOptionsHtml, imported from
- *  composer.ts — one source of truth, not a second fetch). `send` is
- *  required (not optional) so a refresh never silently leaves the table's
- *  mount/select/stack buttons wired to a no-op. */
-export async function refreshAdaptersPanel(state: AdaptersPanelState, send: Send): Promise<void> {
-  const [availD, mountedD] = await Promise.all([
-    api("/v1/adapters/available").catch(() => ({ ok: false } as const)),
-    api("/v1/adapters").catch(() => ({ ok: false } as const)),
-  ]);
-  state.available = ((availD as { adapters?: AvailableAdapterRow[] }).adapters) || [];
-  const mountedList = ((mountedD as { adapters?: MountedAdapterRow[] }).adapters) || [];
-  state.mounted = new Map(mountedList.map((a) => [a.id, a]));
-  // Drop stack picks for adapters that vanished from disk (e.g. an
-  // in-flight delete elsewhere).
-  for (const id of [...state.stackPicks]) if (!state.available.some((a) => a.id === id)) state.stackPicks.delete(id);
-  renderAdaptersBody(state, send);
-}
-
-/** Parse the composer's currently-selected spec ("" | "id" | "a+b") into
- *  the set of ids it names, for the table's per-row "selected" badge. */
-function selectedIds(state: AdaptersPanelState): Set<string> {
-  const spec = state.selectedSpec;
-  if (!spec) return new Set();
-  return new Set(spec.split("+").map((s) => s.trim()).filter(Boolean));
-}
-
-/** Render one adapter row: id/badges, base-model/rank/size/RAM meta line,
- *  incompatible-why note, and the mount/select/unselect/stack actions.
- *  Pure enough to unit-test (no fetch inside), takes callbacks for the
- *  actions so the DOM wiring lives in one place (initAdaptersPanel). */
-export function renderAdapterRow(
-  a: AvailableAdapterRow,
-  opts: {
-    mountedInfo: MountedAdapterRow | undefined;
-    isSelected: boolean;
-    stackPicked: boolean;
-    stackModeOn: boolean;
-  },
-): string {
-  const { mountedInfo, isSelected, stackPicked, stackModeOn } = opts;
-  const rowClasses = ["ad-row"];
-  if (!a.compatible) rowClasses.push("incompatible");
-  if (isSelected) rowClasses.push("selected");
-  const badges: string[] = [];
-  if (mountedInfo) badges.push('<span class="ad-badge mounted">mounted</span>');
-  if (isSelected) badges.push('<span class="ad-badge selected">selected</span>');
-  const meta: string[] = [];
-  if (a.base_model) meta.push("base <b>" + esc(a.base_model.split("/").pop()) + "</b>");
-  if (a.rank) meta.push("rank <b>" + esc(a.rank) + "</b>");
-  meta.push("disk <b>" + esc(fmtBytes(mountedInfo ? mountedInfo.size_bytes : null) === "—" ? "—" : fmtBytes(mountedInfo ? mountedInfo.size_bytes : null)) + "</b>");
-  if (mountedInfo) meta.push("RAM <b>" + esc(fmtBytes(mountedInfo.ram_bytes)) + "</b>");
-  const why = !a.compatible
-    ? '<div class="ad-why">' + (a.base_model
-        ? "trained for " + esc(a.base_model) + ", not the currently-served model"
-        : "not compatible with the currently-served model") + "</div>"
-    : "";
-  const actions: string[] = [];
-  if (a.compatible) {
-    if (stackModeOn) {
-      actions.push(
-        '<label class="ad-stack-chk"><input type="checkbox" class="ad-stack-pick" data-id="' + esc(a.id) + '"' +
-        (stackPicked ? " checked" : "") + (!mountedInfo ? " disabled title=\"mount first to stack it\"" : "") + '> stack</label>',
-      );
-    }
-    if (!mountedInfo) {
-      actions.push('<button type="button" class="ad-mount" data-id="' + esc(a.id) + '" data-path="' + esc(a.path) + '">Mount</button>');
-    } else if (!isSelected) {
-      actions.push('<button type="button" class="ad-select primary" data-id="' + esc(a.id) + '">Select</button>');
-    } else {
-      actions.push('<button type="button" class="ad-unselect" data-id="' + esc(a.id) + '">Unselect</button>');
-    }
-  }
-  return (
-    '<div class="' + rowClasses.join(" ") + '" data-adapter-row="' + esc(a.id) + '">' +
-      '<div class="ad-row-main">' +
-        '<div class="ad-row-head"><span class="ad-row-id" title="' + esc(a.id) + '">' + esc(a.id) + "</span>" + badges.join("") + "</div>" +
-        '<div class="ad-meta">' + meta.join(" · ") + "</div>" +
-        why +
-      "</div>" +
-      '<div class="ad-actions">' + actions.join("") + "</div>" +
-    "</div>"
-  );
-}
-
-/** Full table body: a stack-mode toggle + composed-spec bar (when picks
- *  exist), then one section of rows. Exported so tests/using/web-app.test.ts can
- *  exercise esc() discipline without a live DOM/network. */
-export function renderAdaptersBodyHtml(state: AdaptersPanelState): string {
-  if (!state.available.length) {
-    return (
-      '<div class="ad-empty">No adapters found on disk yet.<br>' +
-      "Fine-tune one in the Developer tab, or drop an adapter directory into " +
-      "<code>~/.cache/mlx-bun/adapters</code>.</div>"
-    );
-  }
-  const selected = selectedIds(state);
-  const stackModeOn = state.stackPicks.size > 0 || selected.size > 1;
-  const rows = state.available.map((a) => renderAdapterRow(a, {
-    mountedInfo: state.mounted.get(a.id),
-    isSelected: selected.has(a.id),
-    stackPicked: state.stackPicks.has(a.id),
-    stackModeOn,
-  })).join("");
-  const picks = [...state.stackPicks];
-  const stackBar = picks.length
-    ? '<div class="ad-stack-bar"><span class="lbl">Stack:</span><span class="expr">' +
-        esc(picks.join(" + ")) + '</span><button type="button" id="ad-stack-apply" class="ad-actions-btn">Apply</button>' +
-        '<button type="button" id="ad-stack-clear" class="ad-actions-btn">Clear</button></div>'
-    : "";
-  return (
-    '<div class="ad-note">Every adapter found on disk, mounted or not. Mounting loads it into ' +
-    "memory (RAM cost shown once mounted); selecting makes it active for this chat's next turn " +
-    "(a fresh KV segment). Tick two mounted adapters' “stack” boxes to compose them as " +
-    '<code>a+b</code> — the server already supports it end to end.</div>' +
-    stackBar +
-    '<div class="ad-sec-title">On disk (' + state.available.length + ")</div>" +
-    rows
-  );
-}
-
-function renderAdaptersBody(state: AdaptersPanelState, send: Send): void {
-  const body = $("adapters-body");
-  if (!body) return;
-  body.innerHTML = renderAdaptersBodyHtml(state);
-  wireRowActions(state, send);
-}
-
-function wireRowActions(state: AdaptersPanelState, send: Send): void {
-  const body = $("adapters-body");
-  if (!body) return;
-  body.querySelectorAll<HTMLButtonElement>(".ad-mount").forEach((btn) => {
-    btn.onclick = async () => {
-      const id = btn.dataset.id!, path = btn.dataset.path!;
-      btn.disabled = true; btn.textContent = "Mounting…";
-      const r = await api("/v1/adapters", { method: "POST", body: { id, path } });
-      if (r && (r.error || r.ok === false)) {
-        toast("adapter: " + (r.error || "mount failed"), "err");
-        btn.disabled = false; btn.textContent = "Mount";
-        return;
-      }
-      toast("mounted " + id, "ok");
-      await refreshAdaptersPanel(state, send);
-    };
-  });
-  body.querySelectorAll<HTMLButtonElement>(".ad-select").forEach((btn) => {
-    btn.onclick = () => {
-      const id = btn.dataset.id!;
-      state.selectedSpec = id;
-      state.stackPicks.clear();
-      send({ type: "set_adapter", id });
-      const sel = $("chat-adapter") as HTMLSelectElement | null;
-      if (sel && [...sel.options].some((o) => o.value === id)) sel.value = id;
-      toast("adapter selected — new turns start a fresh KV segment", "ok");
-      renderAdaptersBody(state, send);
-    };
-  });
-  body.querySelectorAll<HTMLButtonElement>(".ad-unselect").forEach((btn) => {
-    btn.onclick = () => {
-      state.selectedSpec = null;
-      send({ type: "set_adapter", id: null });
-      const sel = $("chat-adapter") as HTMLSelectElement | null;
-      if (sel) sel.value = "";
-      renderAdaptersBody(state, send);
-    };
-  });
-  body.querySelectorAll<HTMLInputElement>(".ad-stack-pick").forEach((chk) => {
-    chk.onchange = () => {
-      const id = chk.dataset.id!;
-      if (chk.checked) state.stackPicks.add(id); else state.stackPicks.delete(id);
-      renderAdaptersBody(state, send);
-    };
-  });
-  const apply = $("ad-stack-apply") as HTMLButtonElement | null;
-  if (apply) apply.onclick = () => {
-    if (state.stackPicks.size < 2) { toast("stack needs at least two ticked adapters", "err"); return; }
-    const spec = [...state.stackPicks].join("+");
-    state.selectedSpec = spec;
-    send({ type: "set_adapter", id: spec });
-    const sel = $("chat-adapter") as HTMLSelectElement | null;
-    if (sel) sel.value = ""; // composite spec has no matching single <option>
-    toast("stacked " + spec + " — new turns start a fresh KV segment", "ok");
-    renderAdaptersBody(state, send);
-  };
-  const clear = $("ad-stack-clear") as HTMLButtonElement | null;
-  if (clear) clear.onclick = () => { state.stackPicks.clear(); renderAdaptersBody(state, send); };
-}
-
-function openPanel(state: AdaptersPanelState, send: Send): void {
-  const ov = $("adapters-overlay");
-  ov.classList.add("open");
-  $("adapters-manage").setAttribute("aria-expanded", "true");
-  if (trap) trap.capture();
-  refreshAdaptersPanel(state, send);
-}
-export function closeAdaptersPanel(): void {
-  $("adapters-overlay").classList.remove("open");
-  $("adapters-manage").setAttribute("aria-expanded", "false");
-  if (trap) trap.restore();
-}
-
-/** Wire the ⚙ button + overlay close affordances. Escape is handled by the
- *  global closeTopOverlay sweep in shell.ts (one mechanism, not a bespoke
- *  listener per overlay — same pattern as the HF modal / sampling popover). */
-export function initAdaptersPanel(state: AdaptersPanelState, send: Send): void {
-  const btn = $("adapters-manage");
-  if (!btn) return;
-  trap = trapFocus($("adapters-panel"), () => $("adapters-overlay").classList.contains("open"));
-  btn.onclick = () => openPanel(state, send);
-  const close = $("adapters-close");
-  if (close) close.onclick = closeAdaptersPanel;
-  $("adapters-overlay").addEventListener("click", (e) => { if (e.target === $("adapters-overlay")) closeAdaptersPanel(); });
-  setAdaptersPanelClose(closeAdaptersPanel);
-}