@webmcp-auto-ui/agent 2.5.28 → 2.5.29

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@webmcp-auto-ui/agent",
-  "version": "2.5.28",
+  "version": "2.5.29",
   "description": "LLM agent loop + remote/WASM/local providers + MCP wrapper",
   "license": "AGPL-3.0-or-later",
   "type": "module",

package/src/autoui-server.ts

@@ -5,22 +5,13 @@
 import { createWebMcpServer, parseFrontmatter } from '@webmcp-auto-ui/core';
 import { RAW_RECIPES } from './recipes/_generated.js';
 
-// Notebook widget recipes (vanilla renderers) — moved to @webmcp-auto-ui/ui
+// Notebook widget recipe (vanilla renderer) — moved to @webmcp-auto-ui/ui
 // @ts-ignore — Vite raw imports, not resolved by tsc
-import compactRecipe from '@webmcp-auto-ui/ui/widgets/notebook/recipes/compact.md?raw';
-// @ts-ignore
-import workspaceRecipe from '@webmcp-auto-ui/ui/widgets/notebook/recipes/workspace.md?raw';
-// @ts-ignore
-import documentRecipe from '@webmcp-auto-ui/ui/widgets/notebook/recipes/document.md?raw';
-// @ts-ignore
-import editorialRecipe from '@webmcp-auto-ui/ui/widgets/notebook/recipes/editorial.md?raw';
-
-// Notebook widget renderers (vanilla JS) — import via subpath to avoid pulling
+import notebookRecipe from '@webmcp-auto-ui/ui/widgets/notebook/recipes/notebook.md?raw';
+
+// Notebook widget renderer (vanilla JS) — import via subpath to avoid pulling
 // the .svelte exports of the ui package root through tsc.
-import { render as renderCompact } from '@webmcp-auto-ui/ui/widgets/notebook/compact.js';
-import { render as renderWorkspace } from '@webmcp-auto-ui/ui/widgets/notebook/workspace.js';
-import { render as renderDocument } from '@webmcp-auto-ui/ui/widgets/notebook/document.js';
-import { render as renderEditorial } from '@webmcp-auto-ui/ui/widgets/notebook/editorial.js';
+import { render as renderNotebook } from '@webmcp-auto-ui/ui/widgets/notebook/notebook.js';
 import { render as renderRecipeBrowser } from '@webmcp-auto-ui/ui/widgets/notebook/recipe-browser.js';
 
 // Inline recipe for recipe-browser (real vanilla widget)
@@ -987,10 +978,7 @@ Call widget_display({name: "js-sandbox", params: {code: "document.getElementById
 
 /** Derived from RECIPES + notebook widget recipes — always in sync with registered widgets */
 const _NOTEBOOK_RECIPE_SOURCES: string[] = [
-  compactRecipe as string,
-  workspaceRecipe as string,
-  documentRecipe as string,
-  editorialRecipe as string,
+  notebookRecipe as string,
   recipeBrowserRecipe,
 ];
 export const NATIVE_WIDGET_NAMES = [...RECIPES, ..._NOTEBOOK_RECIPE_SOURCES].map(r => {
@@ -1011,12 +999,9 @@ for (const recipe of RECIPES) {
   autoui.registerWidget(recipe, undefined);
 }
 
-// Notebook widgets — vanilla renderers (resolved via WidgetRenderer vanilla path)
+// Notebook widget — vanilla renderer (resolved via WidgetRenderer vanilla path)
 const NOTEBOOK_WIDGETS: Array<[string, (container: HTMLElement, data: any) => any]> = [
-  [compactRecipe as string, renderCompact],
-  [workspaceRecipe as string, renderWorkspace],
-  [documentRecipe as string, renderDocument],
-  [editorialRecipe as string, renderEditorial],
+  [notebookRecipe as string, renderNotebook],
   [recipeBrowserRecipe, renderRecipeBrowser],
 ];
 for (const [recipe, renderer] of NOTEBOOK_WIDGETS) {

package/src/loop.ts

@@ -9,7 +9,7 @@ import type {
   LLMProvider, ProviderTool, McpToolDef, AgentCallbacks,
 } from './types.js';
 import type { ToolLayer, SchemaTransformOptions } from './tool-layers.js';
-import { buildToolsFromLayers, buildDiscoveryToolsWithAliases, activateServerTools, toProviderTools, sanitizeServerName, flattenPathMaps } from './tool-layers.js';
+import { buildToolsFromLayers, buildDiscoveryToolsWithAliases, activateServerTools, toProviderTools, sanitizeServerName } from './tool-layers.js';
 import { buildSystemPromptWithAliases, buildSystemPrompt } from './prompts/index.js';
 import type { DiscoveryCache } from './discovery-cache.js';
 import { unflattenParams, validateJsonSchema } from '@webmcp-auto-ui/core';
@@ -168,9 +168,9 @@ export async function runAgentLoop(
   // Use local alias maps (parallel-safe — no global singleton)
   const activatedServers = new Set<string>();
   const localAliasMap = new Map<string, string>();
-  // Snapshot pathMaps locally (parallel-safe). Reading the global flattenPathMaps
-  // singleton at dispatch-time races when two loops run concurrently.
-  const localPathMaps = new Map<string, Record<string, string[]>>(flattenPathMaps);
+  // Local pathMaps for flattened schemas — populated as servers are lazily activated
+  // (see activateServerTools call below). Parallel-safe: scoped to this loop run.
+  const localPathMaps = new Map<string, Record<string, string[]>>();
   const trace = new PipelineTrace();
 
   const disc = buildDiscoveryToolsWithAliases(options.layers ?? [], schemaOptions, trace);
@@ -398,7 +398,10 @@ export async function runAgentLoop(
               activatedServers.add(serverKey);
               const layer = (options.layers ?? []).find(l => sanitizeServerName(l.serverName) === serverName && l.protocol === protocol);
               if (layer) {
-                activeTools = activateServerTools(activeTools, layer, schemaOptions, trace);
+                const act = activateServerTools(activeTools, layer, schemaOptions, trace);
+                activeTools = act.tools;
+                // Merge new pathMaps so unflattenParams works for lazily-activated tools.
+                for (const [k, v] of act.pathMaps) localPathMaps.set(k, v);
               }
             }
           }

package/src/providers/hawk-models.ts

@@ -5,16 +5,17 @@ export interface HawkModelEntry {
 }
 
 export const HAWK_MODELS: HawkModelEntry[] = [
-  { id: 'qwen35-2b',       label: 'Qwen 3.5 2B — 49 tok/s',       tokps: 49 },
-  { id: 'bielik-1.5b-v3',  label: 'Bielik 1.5B — 47 tok/s',       tokps: 47 },
-  { id: 'gemma4-e2b',      label: 'Gemma 4 E2B — 43 tok/s',       tokps: 43 },
-  { id: 'ministral3-3b',   label: 'Ministral 3B — 35 tok/s',      tokps: 35 },
-  { id: 'qwen3-4b',        label: 'Qwen 3 4B — 28 tok/s',         tokps: 28 },
-  { id: 'gemma4-e4b',      label: 'Gemma 4 E4B — 26 tok/s',       tokps: 26 },
-  { id: 'qwen35-4b',       label: 'Qwen 3.5 4B — 23 tok/s',       tokps: 23 },
-  { id: 'qwen36-35b-a3b',  label: 'Qwen 3.6 35B MoE — 22 tok/s',  tokps: 22 },
-  { id: 'gemma4-26b-a4b',  label: 'Gemma 4 26B MoE — 20 tok/s',   tokps: 20 },
-  { id: 'ministral-8b',    label: 'Ministral 8B — 16 tok/s',      tokps: 16 },
+  { id: 'qwen35-2b',          label: 'Qwen 3.5 2B — 49 tok/s',         tokps: 49 },
+  { id: 'bielik-1.5b-v3',     label: 'Bielik 1.5B — 47 tok/s',         tokps: 47 },
+  { id: 'gemma4-e2b',         label: 'Gemma 4 E2B — 43 tok/s',         tokps: 43 },
+  { id: 'deepseek-coder-16b', label: 'DeepSeek Coder 16B — 41 tok/s',  tokps: 41 },
+  { id: 'ministral3-3b',      label: 'Ministral 3B — 35 tok/s',        tokps: 35 },
+  { id: 'qwen3-4b',           label: 'Qwen 3 4B — 28 tok/s',           tokps: 28 },
+  { id: 'gemma4-e4b',         label: 'Gemma 4 E4B — 26 tok/s',         tokps: 26 },
+  { id: 'qwen35-4b',          label: 'Qwen 3.5 4B — 23 tok/s',         tokps: 23 },
+  { id: 'qwen36-35b-a3b',     label: 'Qwen 3.6 35B MoE — 22 tok/s',    tokps: 22 },
+  { id: 'gemma4-26b-a4b',     label: 'Gemma 4 26B MoE — 20 tok/s',     tokps: 20 },
+  { id: 'ministral-8b',       label: 'Ministral 8B — 16 tok/s',        tokps: 16 },
 ];
 
 export function listHawkModels(): HawkModelEntry[] {

package/src/providers/wasm.ts

@@ -313,11 +313,13 @@ export class WasmProvider implements LLMProvider {
       }
     }
 
-    // Strip hallucinated framework tokens the model should never emit on its own:
-    // - <|tool_response>...<tool_response|>  (injected by the framework, never generated)
-    // - <|channel>thought...<channel|>      (ghost thought channels if Gemma emits one
-    //   without <|think|> activation — stray artefacts from pretraining)
-    // - <|think|>                            (stray thinking-mode markers)
+    // Strip hallucinated framework tokens the model should never emit on its own.
+    // Thinking mode is disabled for Gemma (since commit 164a24d) but the model
+    // may still leak these tokens as pretraining artefacts — keep the defensive
+    // strip regardless of activation.
+    // - <|tool_response>...<tool_response|>  (framework-injected, never generated)
+    // - <|channel>thought...<channel|>       (ghost thought channels)
+    // - <|think|>                             (stray pretraining artefacts)
     fullText = fullText
       .replace(/<\|tool_response>[\s\S]*?<tool_response\|>/g, '')
       .replace(/<\|channel>thought[\s\S]*?<channel\|>/g, '')

package/src/recipes/_generated.ts

@@ -932,7 +932,7 @@ component("gallery", {
   'hackathon-assemblee-nationale': `---
 id: hackathon-assemblee-nationale-mcp-webmcp
 name: Hackathon Assemblée Nationale · MCP & WebMCP starter
-components_used: [notebook-document, notebook-compact]
+components_used: [notebook]
 when: the user mentions the Assemblée Nationale hackathon, wants to experiment with parliamentary data (Tricoteuses, Legifrance), or asks for a starter notebook to explore deputies, votes, amendments, or legislative texts in a hackathon context. Keywords include "hackathon Assemblée Nationale", "MCP WebMCP hackathon", "tricoteuses playbook", "parlement playground", "hackathon parlementaire".
 servers: [autoui, tricoteuses]
 layout:
@@ -951,14 +951,9 @@ This recipe is a **specialization** of the generic \`notebook-playbook\` recipe
 
 ## How to use
 
-### Step 1 — Pick the document layout
+### Step 1 — Use the \`notebook\` widget
 
-Default to \`notebook-document\` for the hackathon. Reasons:
-- Participants expect to collaborate and leave traces for each other (avatars, comments)
-- The document layout reads naturally as "hackathon brief + starter code" rather than "dev tool"
-- Margin comments can be seeded to hint at directions to explore
-
-If the participant asks for a minimal dev-focused playground instead, fall back to \`notebook-compact\`.
+The single \`notebook\` widget fits the hackathon brief: prose, SQL and JS share one drag-and-droppable flow, suited both to a "brief + starter code" read and to free exploration.
 
 ### Step 2 — Seed the cells
 
@@ -974,7 +969,7 @@ The notebook should contain 5–7 cells covering:
 Example template (to be refined with actual hackathon organizers' briefs):
 
 \`\`\`
-widget_display({name: "notebook-document", params: {
+widget_display({name: "notebook", params: {
   title: "Hackathon Assemblée Nationale · starter",
   cells: [
     {
@@ -1039,7 +1034,6 @@ These recipes produce more specialized layouts than a generic notebook, and are
 - **Forgetting the hackathon framing**: without the "bienvenue" and "à vous" markdown cells, participants land on a bare notebook and lose the playbook feeling.
 - **SQL without LIMIT**: Tricoteuses queries without \`LIMIT\` can return thousands of rows and slow down the first impression.
 - **Inventing data**: do not seed with fake French parliamentary content (fake deputies, fake votes). If the actual data is not known at seed time, use generic queries (\`SELECT * FROM scrutins LIMIT 5\`) and let the user discover from there.
-- **Picking the wrong layout**: if the user is solo and wants to code fast, \`notebook-compact\` is better than \`notebook-document\`. Default to document for hackathon context because of the collaborative framing, not as a hard rule.
 `,
   'hummingbird-data': `---
 id: hummingbird-data
@@ -1133,8 +1127,8 @@ Do NOT render any widget.
   'notebook-playbook': `---
 id: create-interactive-notebook-playbook
 name: Create an interactive notebook playbook
-components_used: [notebook-compact, notebook-workspace, notebook-document, notebook-editorial]
-when: the user wants to experiment with data, prototype a small analysis, share a reusable scenario, or prepare a hackathon-ready playground. Keywords include "playground", "playbook", "experiment", "try", "prototype", "hackathon", "share a notebook", "template", "starter", "publish".
+components_used: [notebook]
+when: the user wants to experiment with data, prototype a small analysis, share a reusable scenario, or prepare a hackathon-ready playground. Keywords include "playground", "playbook", "experiment", "try", "prototype", "hackathon", "share a notebook", "template", "starter", "publish", "memo", "report".
 servers: [autoui]
 layout:
   type: single
@@ -1154,32 +1148,23 @@ This recipe applies across domains (parliamentary data, biodiversity, news, busi
 
 ## How to use
 
-### Step 1 — Pick the right notebook layout
-
-Choose one of the four \`notebook-*\` widgets based on the user's implicit intent:
+### Step 1 — Use the \`notebook\` widget
 
-| Layout | Use when |
-|---|---|
-| \`notebook-compact\` | Quick data exploration, reactive dataflow with named outputs, minimal chrome. **Default for most "playground" and "hackathon" requests.** |
-| \`notebook-workspace\` | The user expects a multi-cell analyst workspace with sources, cell navigation, \`run all\`, and a \`publish\` step. Use when they mention "dashboard", "app", "workspace", "publish". |
-| \`notebook-document\` | The user plans to share and discuss with a team. Use when "collaborate", "review", "comment", "reply" appear. |
-| \`notebook-editorial\` | The user wants a polished, article-like final deliverable mixing prose and code. Use for "memo", "report", "writeup", "blog-style". |
-
-When in doubt, pick \`notebook-compact\`.
+There is a single notebook widget. Prose paragraphs (\`md\`), SQL queries (\`sql\`) and JS code (\`js\`) share one ordered flow, all drag-and-droppable together. Publication-ready serif prose, suitable for playgrounds, memos, collaborative reviews and analyst workspaces alike.
 
 ### Step 2 — Pre-fill the cells with context-aware seeds
 
 Never create an empty notebook. Always seed with 3–5 cells that give the user an immediate starting point:
 
 1. **First cell: markdown** — title + one-sentence context of what the notebook is for
-2. **Second cell: markdown or code** — if an MCP data source is connected, a starter query that returns something visible (e.g. \`SELECT * FROM {table} LIMIT 10\`). Otherwise a markdown cell describing the next step
-3. **Third cell: code** — a transformation or a visualization that uses the output of step 2. Use \`varname\` on the SQL cell (\`varname: "rows"\`) and reference it in the JS cell — this activates the **reactive dataflow** (the downstream JS cell is flagged stale automatically when its upstream re-runs)
+2. **Second cell: sql or md** — if an MCP data source is connected, a starter query that returns something visible (e.g. \`SELECT * FROM {table} LIMIT 10\`). Otherwise a markdown cell describing the next step
+3. **Third cell: code** — a transformation or a visualization that uses the output of step 2. Use \`varname\` on the SQL cell (\`varname: "rows"\`) and reference it in the JS cell to activate the reactive dataflow
 4. **Last cell: markdown** — a short "to you to play" note inviting the user to add cells or edit
 
 Example seed for a generic data playground:
 
 \`\`\`
-widget_display({name: "notebook-compact", params: {
+widget_display({name: "notebook", params: {
   title: "Exploration playground",
   cells: [
     {type: "md", content: "### Exploration playground\\n\\nStart by running the first SQL cell, then iterate."},
@@ -1203,7 +1188,7 @@ SQL cells are dispatched automatically to the server's \`*_query_sql\` tool (fir
 
 ### Step 4 — Exporting & publishing
 
-All four notebook layouts share the same \`share\` button in the toolbar, offering **four export formats**:
+The toolbar \`share\` button offers **four export formats**:
 
 | Format | What it does |
 |---|---|
@@ -1212,27 +1197,23 @@ All four notebook layouts share the same \`share\` button in the toolbar, offeri
 | **PNG** | Snapshots the rendered notebook to an image. |
 | **JSON** | Exports the full widget state — re-importable for programmatic reuse. |
 
-**Layout-specific share affordances:**
-- \`notebook-workspace\` has a dedicated \`publish\` button (primary, accent-coloured) that flips \`mode: 'view'\`, tags the notebook \`published\` (from \`draft\`), and copies the Hyperskill link in one gesture. Use this when the user wants a clean hand-off.
-- \`notebook-document\` shows a single \`share\` link (live invite/collaboration is not available in this build; presence avatars only render when the \`presence\` param is explicitly provided).
-
 ### Step 5 — Working with connected data servers
 
-When one or more MCP data servers are connected, every notebook layout exposes a **collapsible left pane** (bookmark-bar styling, collapsed by default) that lists:
+When one or more MCP data servers are connected, the notebook exposes a **collapsible left pane** (bookmark-bar styling, collapsed by default) that lists:
 - **Recipes** published by each server (\`{server}_list_recipes()\`)
 - **Tools / tables** exposed by each server (\`{server}_list_tools()\`)
 
-Clicking any recipe opens a viewer modal. Each fenced code block inside the recipe has a \`↳ inject\` button that drops the snippet into the notebook as a new cell — the user never has to copy-paste.
+Clicking any recipe opens a viewer modal. Each fenced code block inside the recipe has a \`↳ inject\` button that drops the snippet into the notebook as a new cell.
 
-Two toolbar buttons flank the left pane on every layout:
+Two toolbar buttons flank the left pane:
 - **\`+ md\`** — 3-tab modal (New / File / URL) to create a markdown cell from scratch, from a local \`.md\` file, or from a URL
 - **\`+ recipe\`** — 3-tab modal (Browser / File / URL) to import a recipe from a connected server, a local \`.recipe.md\` file, or a URL
 
-Pass the server metadata via the \`servers:\` param so these affordances populate correctly:
+Pass the server metadata via the \`servers:\` param:
 
 \`\`\`ts
 widget_display({
-  name: 'notebook-compact',
+  name: 'notebook',
   params: {
     title: '...',
     cells: [...],
@@ -1241,26 +1222,21 @@ widget_display({
 })
 \`\`\`
 
-**Filter rule**: only MCP *data* servers (\`kind: 'data'\`) belong in \`servers:\`. Do NOT include WebMCP UI servers such as \`autoui\` — they expose no queryable data.
+**Filter rule**: only MCP *data* servers (\`kind: 'data'\`) belong in \`servers:\`. Do NOT include WebMCP UI servers such as \`autoui\`.
 
 ### Step 6 — Hand-off guidance
 
 After creating the notebook, mention to the user that they can:
 - **Share in four formats** via the toolbar \`share\` button (Hyperskill / Markdown / PNG / JSON)
 - **Switch to \`view\` mode** (read-only) when presenting
-- Use **\`run all\`** (workspace) or **\`publish\`** (workspace) for one-shot execution and publication
-- **Reply** to margin comments in a document layout (\`+ reply\` under each comment)
 - Access the \`⟲ history\` panel to see the edit trace and restore deleted cells
 - **Import recipes** from connected MCP servers via the left pane or the \`+ recipe\` modal
 
-For hackathon contexts, prefer seeding a \`notebook-document\` layout so participants can leave margin comments and replies on cells (presence stays opt-in — pass a \`presence\` array only if you have real editors to show).
-
 ## Examples
 
 ### Generic CSV / table playground
 \`\`\`
-// user: "I need a playground to play with this CSV"
-widget_display({name: "notebook-compact", params: {
+widget_display({name: "notebook", params: {
   title: "CSV playground",
   cells: [
     {type: "md", content: "### CSV playground\\n\\nRun the SQL cell to see the first rows, then iterate."},
@@ -1270,37 +1246,9 @@ widget_display({name: "notebook-compact", params: {
 }})
 \`\`\`
 
-### Publishable analyst workspace
-\`\`\`
-// user: "Set up an analysis I can publish to the team as an app"
-widget_display({name: "notebook-workspace", params: {
-  title: "Sales review",
-  cells: [
-    {type: "md", name: "intro", content: "What this analysis covers."},
-    {type: "sql", name: "fetch_sales", content: "select * from sales limit 100"},
-    {type: "js", name: "plot", content: "// chart the rows"}
-  ]
-}})
-// Then tell the user: click \`run all\` to execute, then \`publish\` to flip to view mode and copy the Hyperskill link.
-\`\`\`
-
-### Collaborative analysis with comments
-\`\`\`
-// user: "Set up a notebook my team can edit and comment on"
-widget_display({name: "notebook-document", params: {
-  title: "Team analysis",
-  cells: [
-    {type: "md", content: "Kick-off: describe the question here."},
-    {type: "sql", content: "select * from source limit 10", comment: {who: "reviewer", when: "2m", body: "Should we filter to last quarter only?"}},
-    {type: "md", content: "Your findings: add thoughts, <mark>highlights</mark>, and reply to the comment on the query above."}
-  ]
-}})
-\`\`\`
-
 ### Final memo
 \`\`\`
-// user: "Prepare a short memo of my findings"
-widget_display({name: "notebook-editorial", params: {
+widget_display({name: "notebook", params: {
   title: "Findings memo",
   kicker: "memo",
   cells: [
@@ -1317,12 +1265,10 @@ widget_display({name: "notebook-editorial", params: {
 ## Common mistakes
 
 - **Empty notebook**: never call \`widget_display\` without at least 3 seed cells. The user expects something they can immediately run.
-- **Wrong layout for the intent**: do not use \`notebook-editorial\` for quick exploration — it signals "finished article" and intimidates. Use \`notebook-compact\` unless the user explicitly asks for a publication feel.
 - **Heavy initial queries**: always \`LIMIT 10\` or \`LIMIT 20\` in seed SQL cells. Users will expand later if needed.
-- **Missing \`varname\` on SQL cells** (in compact layout): the named output is what the compact layout showcases, and it drives the stale-flag dataflow. Without it, the notebook loses half its reactive story.
+- **Missing \`varname\` on SQL cells**: the named output drives the reactive dataflow (downstream JS cells go stale when their upstream re-runs). Without it, the notebook loses half its story.
 - **Inventing UUIDs**: leave \`id\` unset — the widget generates a sensible default. Only pass \`id\` when restoring an existing notebook.
-- **Faking presence**: do not pass a \`presence\` array to \`notebook-document\` unless there are real editors to show. Presence is opt-in by design — empty \`presence\` hides the avatar row entirely.
-- **Including \`autoui\` in \`servers:\`**: only MCP *data* servers (\`kind: 'data'\`) belong there. UI servers like \`autoui\` would pollute the left pane.
+- **Including \`autoui\` in \`servers:\`**: only MCP *data* servers (\`kind: 'data'\`) belong there.
 `,
   'parlementaire-profile': `---
 id: display-parliamentary-profile-with-hemicycle-and-votes

package/src/recipes/hackathon-assemblee-nationale.md

@@ -1,7 +1,7 @@
 ---
 id: hackathon-assemblee-nationale-mcp-webmcp
 name: Hackathon Assemblée Nationale · MCP & WebMCP starter
-components_used: [notebook-document, notebook-compact]
+components_used: [notebook]
 when: the user mentions the Assemblée Nationale hackathon, wants to experiment with parliamentary data (Tricoteuses, Legifrance), or asks for a starter notebook to explore deputies, votes, amendments, or legislative texts in a hackathon context. Keywords include "hackathon Assemblée Nationale", "MCP WebMCP hackathon", "tricoteuses playbook", "parlement playground", "hackathon parlementaire".
 servers: [autoui, tricoteuses]
 layout:
@@ -20,14 +20,9 @@ This recipe is a **specialization** of the generic `notebook-playbook` recipe
 
 ## How to use
 
-### Step 1 — Pick the document layout
+### Step 1 — Use the `notebook` widget
 
-Default to `notebook-document` for the hackathon. Reasons:
-- Participants expect to collaborate and leave traces for each other (avatars, comments)
-- The document layout reads naturally as "hackathon brief + starter code" rather than "dev tool"
-- Margin comments can be seeded to hint at directions to explore
-
-If the participant asks for a minimal dev-focused playground instead, fall back to `notebook-compact`.
+The single `notebook` widget fits the hackathon brief: prose, SQL and JS share one drag-and-droppable flow, suited both to a "brief + starter code" read and to free exploration.
 
 ### Step 2 — Seed the cells
 
@@ -43,7 +38,7 @@ The notebook should contain 5–7 cells covering:
 Example template (to be refined with actual hackathon organizers' briefs):
 
 ```
-widget_display({name: "notebook-document", params: {
+widget_display({name: "notebook", params: {
   title: "Hackathon Assemblée Nationale · starter",
   cells: [
     {
@@ -108,4 +103,3 @@ These recipes produce more specialized layouts than a generic notebook, and are
 - **Forgetting the hackathon framing**: without the "bienvenue" and "à vous" markdown cells, participants land on a bare notebook and lose the playbook feeling.
 - **SQL without LIMIT**: Tricoteuses queries without `LIMIT` can return thousands of rows and slow down the first impression.
 - **Inventing data**: do not seed with fake French parliamentary content (fake deputies, fake votes). If the actual data is not known at seed time, use generic queries (`SELECT * FROM scrutins LIMIT 5`) and let the user discover from there.
-- **Picking the wrong layout**: if the user is solo and wants to code fast, `notebook-compact` is better than `notebook-document`. Default to document for hackathon context because of the collaborative framing, not as a hard rule.

package/src/recipes/notebook-playbook.md

@@ -1,8 +1,8 @@
 ---
 id: create-interactive-notebook-playbook
 name: Create an interactive notebook playbook
-components_used: [notebook-compact, notebook-workspace, notebook-document, notebook-editorial]
-when: the user wants to experiment with data, prototype a small analysis, share a reusable scenario, or prepare a hackathon-ready playground. Keywords include "playground", "playbook", "experiment", "try", "prototype", "hackathon", "share a notebook", "template", "starter", "publish".
+components_used: [notebook]
+when: the user wants to experiment with data, prototype a small analysis, share a reusable scenario, or prepare a hackathon-ready playground. Keywords include "playground", "playbook", "experiment", "try", "prototype", "hackathon", "share a notebook", "template", "starter", "publish", "memo", "report".
 servers: [autoui]
 layout:
   type: single
@@ -22,32 +22,23 @@ This recipe applies across domains (parliamentary data, biodiversity, news, busi
 
 ## How to use
 
-### Step 1 — Pick the right notebook layout
+### Step 1 — Use the `notebook` widget
 
-Choose one of the four `notebook-*` widgets based on the user's implicit intent:
-
-| Layout | Use when |
-|---|---|
-| `notebook-compact` | Quick data exploration, reactive dataflow with named outputs, minimal chrome. **Default for most "playground" and "hackathon" requests.** |
-| `notebook-workspace` | The user expects a multi-cell analyst workspace with sources, cell navigation, `run all`, and a `publish` step. Use when they mention "dashboard", "app", "workspace", "publish". |
-| `notebook-document` | The user plans to share and discuss with a team. Use when "collaborate", "review", "comment", "reply" appear. |
-| `notebook-editorial` | The user wants a polished, article-like final deliverable mixing prose and code. Use for "memo", "report", "writeup", "blog-style". |
-
-When in doubt, pick `notebook-compact`.
+There is a single notebook widget. Prose paragraphs (`md`), SQL queries (`sql`) and JS code (`js`) share one ordered flow, all drag-and-droppable together. Publication-ready serif prose, suitable for playgrounds, memos, collaborative reviews and analyst workspaces alike.
 
 ### Step 2 — Pre-fill the cells with context-aware seeds
 
 Never create an empty notebook. Always seed with 3–5 cells that give the user an immediate starting point:
 
 1. **First cell: markdown** — title + one-sentence context of what the notebook is for
-2. **Second cell: markdown or code** — if an MCP data source is connected, a starter query that returns something visible (e.g. `SELECT * FROM {table} LIMIT 10`). Otherwise a markdown cell describing the next step
-3. **Third cell: code** — a transformation or a visualization that uses the output of step 2. Use `varname` on the SQL cell (`varname: "rows"`) and reference it in the JS cell — this activates the **reactive dataflow** (the downstream JS cell is flagged stale automatically when its upstream re-runs)
+2. **Second cell: sql or md** — if an MCP data source is connected, a starter query that returns something visible (e.g. `SELECT * FROM {table} LIMIT 10`). Otherwise a markdown cell describing the next step
+3. **Third cell: code** — a transformation or a visualization that uses the output of step 2. Use `varname` on the SQL cell (`varname: "rows"`) and reference it in the JS cell to activate the reactive dataflow
 4. **Last cell: markdown** — a short "to you to play" note inviting the user to add cells or edit
 
 Example seed for a generic data playground:
 
 ```
-widget_display({name: "notebook-compact", params: {
+widget_display({name: "notebook", params: {
   title: "Exploration playground",
   cells: [
     {type: "md", content: "### Exploration playground\n\nStart by running the first SQL cell, then iterate."},
@@ -71,7 +62,7 @@ SQL cells are dispatched automatically to the server's `*_query_sql` tool (first
 
 ### Step 4 — Exporting & publishing
 
-All four notebook layouts share the same `share` button in the toolbar, offering **four export formats**:
+The toolbar `share` button offers **four export formats**:
 
 | Format | What it does |
 |---|---|
@@ -80,27 +71,23 @@ All four notebook layouts share the same `share` button in the toolbar, offering
 | **PNG** | Snapshots the rendered notebook to an image. |
 | **JSON** | Exports the full widget state — re-importable for programmatic reuse. |
 
-**Layout-specific share affordances:**
-- `notebook-workspace` has a dedicated `publish` button (primary, accent-coloured) that flips `mode: 'view'`, tags the notebook `published` (from `draft`), and copies the Hyperskill link in one gesture. Use this when the user wants a clean hand-off.
-- `notebook-document` shows a single `share` link (live invite/collaboration is not available in this build; presence avatars only render when the `presence` param is explicitly provided).
-
 ### Step 5 — Working with connected data servers
 
-When one or more MCP data servers are connected, every notebook layout exposes a **collapsible left pane** (bookmark-bar styling, collapsed by default) that lists:
+When one or more MCP data servers are connected, the notebook exposes a **collapsible left pane** (bookmark-bar styling, collapsed by default) that lists:
 - **Recipes** published by each server (`{server}_list_recipes()`)
 - **Tools / tables** exposed by each server (`{server}_list_tools()`)
 
-Clicking any recipe opens a viewer modal. Each fenced code block inside the recipe has a `↳ inject` button that drops the snippet into the notebook as a new cell — the user never has to copy-paste.
+Clicking any recipe opens a viewer modal. Each fenced code block inside the recipe has a `↳ inject` button that drops the snippet into the notebook as a new cell.
 
-Two toolbar buttons flank the left pane on every layout:
+Two toolbar buttons flank the left pane:
 - **`+ md`** — 3-tab modal (New / File / URL) to create a markdown cell from scratch, from a local `.md` file, or from a URL
 - **`+ recipe`** — 3-tab modal (Browser / File / URL) to import a recipe from a connected server, a local `.recipe.md` file, or a URL
 
-Pass the server metadata via the `servers:` param so these affordances populate correctly:
+Pass the server metadata via the `servers:` param:
 
 ```ts
 widget_display({
-  name: 'notebook-compact',
+  name: 'notebook',
   params: {
     title: '...',
     cells: [...],
@@ -109,26 +96,21 @@ widget_display({
 })
 ```
 
-**Filter rule**: only MCP *data* servers (`kind: 'data'`) belong in `servers:`. Do NOT include WebMCP UI servers such as `autoui` — they expose no queryable data.
+**Filter rule**: only MCP *data* servers (`kind: 'data'`) belong in `servers:`. Do NOT include WebMCP UI servers such as `autoui`.
 
 ### Step 6 — Hand-off guidance
 
 After creating the notebook, mention to the user that they can:
 - **Share in four formats** via the toolbar `share` button (Hyperskill / Markdown / PNG / JSON)
 - **Switch to `view` mode** (read-only) when presenting
-- Use **`run all`** (workspace) or **`publish`** (workspace) for one-shot execution and publication
-- **Reply** to margin comments in a document layout (`+ reply` under each comment)
 - Access the `⟲ history` panel to see the edit trace and restore deleted cells
 - **Import recipes** from connected MCP servers via the left pane or the `+ recipe` modal
 
-For hackathon contexts, prefer seeding a `notebook-document` layout so participants can leave margin comments and replies on cells (presence stays opt-in — pass a `presence` array only if you have real editors to show).
-
 ## Examples
 
 ### Generic CSV / table playground
 ```
-// user: "I need a playground to play with this CSV"
-widget_display({name: "notebook-compact", params: {
+widget_display({name: "notebook", params: {
   title: "CSV playground",
   cells: [
     {type: "md", content: "### CSV playground\n\nRun the SQL cell to see the first rows, then iterate."},
@@ -138,37 +120,9 @@ widget_display({name: "notebook-compact", params: {
 }})
 ```
 
-### Publishable analyst workspace
-```
-// user: "Set up an analysis I can publish to the team as an app"
-widget_display({name: "notebook-workspace", params: {
-  title: "Sales review",
-  cells: [
-    {type: "md", name: "intro", content: "What this analysis covers."},
-    {type: "sql", name: "fetch_sales", content: "select * from sales limit 100"},
-    {type: "js", name: "plot", content: "// chart the rows"}
-  ]
-}})
-// Then tell the user: click `run all` to execute, then `publish` to flip to view mode and copy the Hyperskill link.
-```
-
-### Collaborative analysis with comments
-```
-// user: "Set up a notebook my team can edit and comment on"
-widget_display({name: "notebook-document", params: {
-  title: "Team analysis",
-  cells: [
-    {type: "md", content: "Kick-off: describe the question here."},
-    {type: "sql", content: "select * from source limit 10", comment: {who: "reviewer", when: "2m", body: "Should we filter to last quarter only?"}},
-    {type: "md", content: "Your findings: add thoughts, <mark>highlights</mark>, and reply to the comment on the query above."}
-  ]
-}})
-```
-
 ### Final memo
 ```
-// user: "Prepare a short memo of my findings"
-widget_display({name: "notebook-editorial", params: {
+widget_display({name: "notebook", params: {
   title: "Findings memo",
   kicker: "memo",
   cells: [
@@ -185,9 +139,7 @@ widget_display({name: "notebook-editorial", params: {
 ## Common mistakes
 
 - **Empty notebook**: never call `widget_display` without at least 3 seed cells. The user expects something they can immediately run.
-- **Wrong layout for the intent**: do not use `notebook-editorial` for quick exploration — it signals "finished article" and intimidates. Use `notebook-compact` unless the user explicitly asks for a publication feel.
 - **Heavy initial queries**: always `LIMIT 10` or `LIMIT 20` in seed SQL cells. Users will expand later if needed.
-- **Missing `varname` on SQL cells** (in compact layout): the named output is what the compact layout showcases, and it drives the stale-flag dataflow. Without it, the notebook loses half its reactive story.
+- **Missing `varname` on SQL cells**: the named output drives the reactive dataflow (downstream JS cells go stale when their upstream re-runs). Without it, the notebook loses half its story.
 - **Inventing UUIDs**: leave `id` unset — the widget generates a sensible default. Only pass `id` when restoring an existing notebook.
-- **Faking presence**: do not pass a `presence` array to `notebook-document` unless there are real editors to show. Presence is opt-in by design — empty `presence` hides the avatar row entirely.
-- **Including `autoui` in `servers:`**: only MCP *data* servers (`kind: 'data'`) belong there. UI servers like `autoui` would pollute the left pane.
+- **Including `autoui` in `servers:`**: only MCP *data* servers (`kind: 'data'`) belong there.

package/src/tool-layers.ts

@@ -456,19 +456,31 @@ export function buildDiscoveryTools(layers: ToolLayer[]): ProviderTool[] {
   return tools;
 }
 
+/** Result of activateServerTools — extended tool set + per-call path maps for newly activated tools */
+export interface ActivateServerToolsResult {
+  tools: ProviderTool[];
+  /** Path maps for flattened schemas of newly added tools (empty if flatten is off). */
+  pathMaps: Map<string, Record<string, string[]>>;
+}
+
 /**
  * Add all tools from a specific server layer to the active tool set.
  * Called when a server is "touched" for the first time.
+ *
+ * Returns `{ tools, pathMaps }` — `pathMaps` is non-empty when `schemaOptions.flatten`
+ * is on, and must be merged into the loop-local pathMaps so `unflattenParams` works
+ * for lazily-activated tools. Backward-compat: if you only need `tools`, read `.tools`.
  */
 export function activateServerTools(
   currentTools: ProviderTool[],
   layer: ToolLayer,
   schemaOptions?: SchemaTransformOptions,
   trace?: PipelineTrace,
-): ProviderTool[] {
+): ActivateServerToolsResult {
   const prefix = `${sanitizeServerName(layer.serverName)}_${protocolToken(layer.protocol)}_`;
   const existing = new Set(currentTools.map(t => t.name));
   const newTools = [...currentTools];
+  const pathMaps = new Map<string, Record<string, string[]>>();
 
   const layerTools = layer.protocol === 'mcp'
     ? toProviderTools(layer.tools, schemaOptions, trace)
@@ -476,12 +488,22 @@ export function activateServerTools(
 
   for (const tool of layerTools) {
     const prefixed = `${prefix}${tool.name}`;
-    if (!existing.has(prefixed)) {
-      newTools.push({ ...tool, name: prefixed });
+    if (existing.has(prefixed)) continue;
+
+    let finalTool = { ...tool, name: prefixed };
+
+    if (schemaOptions?.flatten) {
+      const { schema: flatSchema, pathMap } = flattenSchema(finalTool.input_schema as import('@webmcp-auto-ui/core').JsonSchema);
+      if (Object.keys(pathMap).length > 0) {
+        finalTool.input_schema = flatSchema as Record<string, unknown>;
+        pathMaps.set(prefixed, pathMap);
+      }
     }
+
+    newTools.push(finalTool);
   }
 
-  return newTools;
+  return { tools: newTools, pathMaps };
 }
 
 /**

package/src/trace-observer.ts

@@ -374,9 +374,7 @@ export function createTraceObserver(ctx: TraceObserverContext): TraceObserver {
 
   function flush(): void {
     if (ids === null) return;
-    ctx.updateWidget(ids.dagId, buildCytoscapeData());
     ctx.updateWidget(ids.treeId, buildTreeData());
-    ctx.updateWidget(ids.sankeyId, buildSankeyData());
   }
 
   const callbacks: Partial<AgentCallbacks> = {
@@ -602,11 +600,11 @@ export function createTraceObserver(ctx: TraceObserverContext): TraceObserver {
     callbacks,
     mount(): { dagId: string; treeId: string; sankeyId: string } | null {
       if (ids !== null) return ids;
-      const dag = ctx.addWidget('animated-flow', buildCytoscapeData(), 'cytoscape');
       const tree = ctx.addWidget('tree', buildTreeData(), 'd3');
-      const sankey = ctx.addWidget('sankey', buildSankeyData(), 'autoui');
-      if (!dag || !tree || !sankey) return null;
-      ids = { dagId: dag.id, treeId: tree.id, sankeyId: sankey.id };
+      if (!tree) return null;
+      // dagId/sankeyId kept as empty strings for shape compatibility — the
+      // cytoscape + sankey sub-widgets were removed in favor of the tree only.
+      ids = { dagId: '', treeId: tree.id, sankeyId: '' };
       // Synchronous immediate flush — guarantees widgets reflect full buffer
       // when trace is toggled mid-run (retroactive within current session).
       flush();
@@ -633,19 +631,10 @@ export function createTraceObserver(ctx: TraceObserverContext): TraceObserver {
         flushTimer = null;
       }
       if (ids !== null) {
-        ctx.updateWidget(ids.dagId, {
-          elements: [],
-          style: CYTOSCAPE_STYLE,
-          layout: { name: 'cose', animate: true },
-        });
         ctx.updateWidget(ids.treeId, {
           root: { name: 'conv', children: [] },
           orientation: 'horizontal',
         });
-        ctx.updateWidget(ids.sankeyId, {
-          nodes: [],
-          links: [],
-        });
       }
     },
     detach(): void {