rowboatlabs/rowboat

Summary On the Home to-do surface, a suggestion that was already declined/dismissed (or already accepted) can reappear in the suggestion tray on a later planner run instead of staying permanently filtered out. Where this lives in code (found on origin/feat/todo-homepage-v2 / origin/fix/todo-home-polish — not on main yet) apps/x/apps/renderer/src/components/todo-view.tsx:1123 — stores suggestions state; :1209-1214 loads them via todo:get; :1334-1352 accept/decline handlers; :1915-1948 renders the suggestion tray. apps/x/apps/main/src/ipc.ts:2656-2686 — exposes todo:get, todo:acceptSuggestion, todo:declineSuggestion; :2796-2805 records dismissal of accepted proposed items. apps/x/packages/core/src/runtime/tools/domains/todo.ts:47-78 — implements the todo-propose tool used by the planner. apps/x/packages/core/src/todo/planner-memory.ts:71-96 — records planner feedback and builds "sticky dismissed" keys; :128-143 dedupes against the current todo/suggestions.md. apps/x/packages/c

Problem Right-click does almost nothing in the app today. Electron doesn't provide context menus by default — apps must wire them up themselves, and we currently don't. Concretely: No Cut/Copy/Paste menu in text inputs, including the chat composer No "Copy" on selected text in emails, chat messages, or notes No spell-check suggestions (Chromium's spellchecker is on, but suggestions only surface via a context menu) No "Copy Link Address" on links, no "Save Image" on images No context menu in the embedded browser pane The only right-click menus that exist are custom in-app (Radix UI) menus on a few list rows — chat history entries, notes, knowledge items, workspace files — plus the tray icon menu. Those should keep working as-is. Suggested approach Use the electron-context-menu package — it provides editing, spellcheck, link, and image menus out of the box: cd apps/x/apps/main && pnpm add electron-context-menu Initialize it in the main process (apps/x/apps/main/src/main.ts); e

When a query triggers multiple sequential web searches, the UI generates a separate UI card for every single query executed. As seen in the attached screenshot, this creates significant visual clutter, unnecessarily stretches the vertical length of the chat history, and disrupts the overall user experience. Solution Instead of rendering individual cards for every search, consecutive web searches should be batched or grouped into a single, unified "Web Search" container. The parent container can show an aggregated status (e.g., "Searching the web... (4 queries)"). Expanding the container should reveal the list of individual search queries executed. Steps to reproduce Enter a complex prompt that requires multi-hop verification or multiple separate search terms. Observe the chat output rendering individual, repetitive "Web search" cards stacked vertically. Visual Evidence Suggested UX Improvements Collapsible Accordion: Wrap all concurrent/consecutive searches into one accordion com

Summary With an OpenAI-compatible provider backed by LM Studio (llama.cpp), configuring a local model and running Test & Save succeeds, but starting a chat fails immediately with an HTTP 400 from the backend. Root cause: llama.cpp compiles the pattern regexes in the request's tool schemas into a GBNF grammar for constrained decoding, and GBNF has no PCRE shorthand classes (\d, \w, \s) or word boundaries (\b). One offending field fails grammar compilation and takes down the entire request. Environment Rowboat: 0.7.1 — Linux .deb, Ubuntu 22.04 Backend: LM Studio (llama.cpp), e.g. qwen/qwen3-... Provider configured in Rowboat as OpenAI-compatible Steps to reproduce Add an OpenAI-compatible provider pointing at LM Studio, pick a tool-capable model. Test & Save → succeeds. Start a chat and send any message → fails. What happens LM Studio server log: parse: error parsing grammar: unknown escape at \d Client receives: {"error":{"code":400,"message":"Failed to initialize samplers: f