Use case
WikiBricks stores local memory in SQLite, which works well for agents but is awkward for people to inspect. The Markdown export is useful for backups, Git review, and portability, but a synchronized tree of Markdown files would duplicate the database and introduce rename, link, and conflict rules.
Add a small local browser that reads the live SQLite store. It should make curated pages and their relationships easy to inspect without creating another copy of the wiki.
Proposed API
Add a CLI command that starts a local, read-only web UI:
The command binds to 127.0.0.1 by default and reads through WikiClient. The first release should provide:
- full-text search plus page type and tag filters;
- rendered Markdown with page metadata, sources, and version history;
- typed outgoing links, backlinks, and a one-hop relationship view;
- raw session pages hidden by default; and
- Markdown download for the selected page.
The existing Karpathy-style Markdown export and import remain explicit portability tools. The UI does not maintain a synchronized Markdown mirror.
Acceptance criteria
wikibricks browse opens a browser over the configured local SQLite database.- The server listens only on localhost unless the user explicitly changes the bind address.
- The first release is read-only and remains usable while an MCP process writes through SQLite WAL.
- Search, filters, page rendering, metadata, sources, history, outgoing links, and backlinks work against the live database.
- The relationship view shows one hop by default and does not require a full graph visualization.
- Rendered Markdown is sanitized before display.
- Raw sessions are excluded from default search and navigation.
- A user can download the current page as Markdown without exporting the whole wiki.
- Tests cover concurrent reads, session visibility, Markdown sanitization, and linked-page navigation.
- Documentation explains the trust boundary, bind options, and the difference between browsing and Markdown export.
Editing can follow in a separate issue. Any later write path must use the page version or content hash to detect conflicts.
Alternatives considered
A synchronized directory of Markdown files is easy to open in an editor, but it creates a second source of truth and makes typed links and renames harder to maintain. SQLite desktop tools expose tables rather than the wiki model. The generated _meta/index is useful for a quick inventory, but it does not provide search, backlinks, history, or source navigation.
Additional context
Use case
WikiBricks stores local memory in SQLite, which works well for agents but is awkward for people to inspect. The Markdown export is useful for backups, Git review, and portability, but a synchronized tree of Markdown files would duplicate the database and introduce rename, link, and conflict rules.
Add a small local browser that reads the live SQLite store. It should make curated pages and their relationships easy to inspect without creating another copy of the wiki.
Proposed API
Add a CLI command that starts a local, read-only web UI:
The command binds to
127.0.0.1by default and reads throughWikiClient. The first release should provide:The existing Karpathy-style Markdown export and import remain explicit portability tools. The UI does not maintain a synchronized Markdown mirror.
Acceptance criteria
wikibricks browseopens a browser over the configured local SQLite database.Editing can follow in a separate issue. Any later write path must use the page version or content hash to detect conflicts.
Alternatives considered
A synchronized directory of Markdown files is easy to open in an editor, but it creates a second source of truth and makes typed links and renames harder to maintain. SQLite desktop tools expose tables rather than the wiki model. The generated
_meta/indexis useful for a quick inventory, but it does not provide search, backlinks, history, or source navigation.Additional context
src/wikibricks/export_karpathy.pysrc/wikibricks/import_karpathy.py