BinderUpload-and-Search KB

Binder is a small team wiki. You drop in your documents, find anything as you type, ask questions that get answered with citations, and see which pages are stale or missing. Small teams keep policies in scattered docs, the search in most tools fails on typos and phrases, and nobody notices when a page goes stale or when people keep searching for something that was never written.

The Claude mode request builder and response parser are unit tested, but the live API was never called during the build, by design. Real drag-drop and folder picking weren't clicked by hand. The importers behind them are tested, and paste-import is covered by the smoke test. The index is rebuilt in memory, so a KB of thousands of pages would be slow to open.

Claude Code built it on September 23 from the Claude Code side of the split file. I directed the product shape: a team wiki, not a support widget (that was 64) or a PDF Q&A tool (that was 65). Owners and review dates are first-class fields, and "content gaps" (searches that return nothing) are the signal of what to write next.

It's plain HTML, CSS, and ES modules, no build step, no dependencies, and a 40-line Node static server. The whole retrieval pipeline is a pure tested core: inverted index, BM25, typo tolerance with a bounded edit distance, MinHash for near-duplicates, and a hand-written zip writer for export. It runs the same in Node tests and in the browser, so the UI is a thin layer over 201 assertions.

Claude also wrote all 25 demo articles for a fictional home care agency, including deliberately stale pages and a near-duplicate mileage page, so the health dashboard shows real findings instead of noise. On top of the unit tests, a DevTools-protocol smoke test clicks through search, keyboard nav, editing, history, health, export, Ask, and paste-import in headless Chrome, 20 of 20. Earlier agents in the sprint lost work to dropped streams, so most writes stayed under about 4 KB.

• The first Ask version "answered" a dress code question by quoting a lockbox code sentence, because "code" was the only word it knew. Counting unknown question words against a coverage rule (about 60% of content words must be present) made it say it doesn't know. That's now a test.
• Plain BM25 ranked a stale near-copy above the current page because it was slightly shorter. A small freshness factor (85% of the score past the review window) fixed the ranking without hiding anything.
• On an HTML form, form.title is the form's title attribute, not the input named "title." form.elements is the safe accessor.
• Re-rendering the article pane on every keystroke would wipe an open editor. Keying the render on view, selection, and the articles array made search and editing independent.
• A literal em dash slipped into the test file's own em-dash check. We built the character with String.fromCharCode instead.

Binder is the third RAG build in a row after Lantern (64) and Folio (65), and it was scoped on purpose to not repeat them. The honest decline carried straight through: 64 used score plus coverage, 65 used an "answerable" gate, and 66 used the unknown-words coverage rule. The fenced, untrusted-context prompt for the optional Claude mode is the same pattern in all three.

I'd store the index incrementally in IndexedDB so large KBs open instantly, and split passages by heading so citations point to the exact part of a long article.