The Bram binary now embeds SQLite with its FTS5 fulltext indexer and search engine. When you run Bram in a local GitHub (or GitLab) repo, here is what it indexes:
– the JSONL session files written by Claude Code and/or Codex
– the worklist items written by Bram
– git commits
– issues posted to GitHub or GitLab
The screenshot, from Bram’s own repo, shows that StickyBox is found in all of the indexed buckets: agent sessions, commits, issues, and worklist history. (The date slider is pushed back because I’m looking for earlier occurrences.)
When I added the search feature a few days ago I was thinking mainly of my own need to find things scattered across these buckets. But of course agents can use this unified search too! Here’s Claude Code proposing an XMLUI solution. (Spoiler alert: it won’t work.)
It proposed to use StickyBox to top-anchor the Find box you see in that screenshot, which reminded me that I’d been avoiding StickyBox for reasons I couldn’t fully articulate. So I asked Claude Code to investigate. Its cross-bucket searches found “the receipts” — the doomed StickyBox attempt in the earlier session unearthed by search — and investigation led to a different solution: StickySection (with top=”$height-AppHeader”).
Bram and XMLUI
These screenshots capture real use of Claude Code via the UI that Bram wraps around it. That UI is made with XMLUI: Bram is a Tauri app that combines a terminal and an XMLUI app that fronts Claude Code and/or Codex. As a co-maintainer of XMLUI and author of its CLI and MCP server, one of my goals has been to make XMLUI reliably learnable by agents.
The MCP server provides agents with tools for listing components and searching documentation, and tells agents to prefer xmlui_list_howto and xmlui_search_howto. These tools explore the HowTo section of the docs where we’ve assembled nearly 200 verified patterns. Crucially these are backed by playgrounds that run the examples live and prove they work. This is the gold standard. When agents propose an XMLUI solution they are instructed to use, and cite, known working patterns.
We always used to say that documentation was integral to a software product, but that was never really true because the docs were never amenable to the same kind of engineering discipline that governed the code. Now documentation has become a testable discipline. When an agent fails to find a working pattern, that’s an XMLUI bug. If I add a HowTo doc that enables the agent to find the working pattern the next time, that’s a fix.
Make it easy to do the right thing
I use Bram to develop a half-dozen different apps. When I’m working on one or another of them and discover a missing XMLUI HowTo, I know I should pause, research the problem, and create that HowTo. But in the thick of the action that is unlikely to happen, so these unanswered MCP queries accumulate. Now it’s much easier to mine project history, find unanswered questions, answer them, and continue to improve the XMLUI MCP server. Here’s the HowTo that emerged from the StickyBox/StickySection investigation.
There’s another level to this game. Because the MCP server logs tool calls, an agent’s failure to find verified HowTo docs can be timestamp-matched with conversation and worklist activity. Could agents mine the indexed corpus looking for cases where we’ve struggled to find a solution, and infer missing HowTo docs? Absence of evidence is, of course, not evidence of absence, and I’ll save the still-experimental method for another post. Meanwhile the unified search makes it easy to do the right thing when an unanswered question pops up.
