Available

Thought Keeper

An automatic Zettelkasten over the claims of your sources

16 entries available

Thought Keeper turns the sources you give it—Markdown, PDFs with local OCR, URL snapshots, your own wiki pages—into claims: one sentence per file, with its source node, a flat topic and a type. That is an automatic Zettelkasten, with the atomising, filing and linking done by an agent over files you own.

Four ordered steps produce them: capture makes a source readable locally, the outline turns it into a tree of references, distill writes the claims and audits them, and cluster groups them into titleless associations—deterministically, without a model. Claims are Markdown files under atoms/, enough to rebuild the index from the vault alone.

Retrieval is deliberately vectorless: the agent walks outlines, claim topics, a lexical index and the claim graph, and every answer cites its claims down to the source node. It ships as one CGO-free Go binary with a tray icon and an installable Svelte PWA. A link with no readable text becomes a bookmark—collected, not understood.

How the Project Started
The itch behind Thought Keeper: notes that do not compile themselves, and the three ideas that promised a way out.
Exploring the Concept
Why two layers became three, and why retrieval here means reasoning over hierarchies instead of vector search.
Defining the Goal
Drawing the line around v1: a local desktop reader, not a RAG pipeline, not a server, and never anything silent.
Shaping the Scope
The v1 boundary that survived contact: one file per source, claims as truth, a disposable index, and a desktop app with no server.
Choosing the Tech Stack
Go, SQLite, and one CGO-free binary everywhere: the constraint that chose the stack for me.
Initial Architecture
Ports next to use cases, dependencies pointing inward, and a core that imports the standard library and nothing else.
First Working Version
The whole pipeline end to end: intake, extract, tree, atomize, compile — and the status rules that keep it honest.
Designing the Agent
A bounded tool loop, a deliberately small tool set, and mandatory citations — the agent as a use case, the model as an adapter.
From Panels to a Reader
Rebuilding the UI as a document-first Svelte SPA on an event stream, and turning the app into a real desktop application.
An Encompassing Collection
Bookmarks, favicons, derived topics, and ASCII tags: making 'everything I collected' one list without lying in the wiki.
Provenance over Titles
The correctness chapter: re-ingest that cleans by provenance, a repair that reloads what it writes, and a reindex that finally rebuilds from the vault.
Enforced, Not Written Down
The specification said things the code did not do: a gate one step never took, a status that reported waiting as running, atoms addressed by a file name, and an outline that copied the document.
The Reader Catches Up
The pipeline had become claim-first while the app still navigated the old model: a topic tree, a global search box, answers filed as pages. This is the chapter where the reader learned the same words.
The Cost of a Save
Saving one wiki page took three and a half minutes. The fix was not a faster fetch — it was admitting that a save had no business fetching at all, and that a scheduler which rescans the vault per source turns a queue into a lie.
The Page Layer Goes Away
The pipeline was honest and the reader spoke its language. Then the vault filled up with real sources — and the last generated layer, the page, turned out to be the one thing nobody read.
Where a Setting Belongs
The overlay already knew where every value came from. Teaching it to write asked the harder questions: what may change while a run is in flight, what must never be edited from a UI, and which settings belong to the vault rather than to the machine.