Keep a multi-repo codebase wiki rewriting itself when code changes

Ranjith Kumar Kakkarayil built a single-user Next.js app that runs OpenWiki, an open-source LangChain CLI that reads a codebase and writes a linked Markdown wiki with every claim tied to source files. A project groups several repositories (front end, back end, jobs service). The app exports them side by side into a private workspace, commits a local snapshot after each sync, and polls the git host with ls-remote every few minutes. When a tracked branch moves, OpenWiki runs an incremental update from the snapshot diff. Repos are only ever read, never written. A local gateway feeds the model calls to any OpenAI-compatible API, and a Q&A panel answers questions in strict JSON with checked citations. The app itself was written by parallel coding agents in separate worktrees, with a reviewer agent checking each task.

In the first real test, a change to one file rewrote six of the eight wiki pages and left the other two byte-for-byte the same. A coverage view showed the wiki cited about 7% of roughly 2,900 documentable files, and 2% of a 1,500-file front end. Bugs along the way: a skip rule kept a stale wiki forever after a failed run, adding the first repo kicked off an expensive run too early, and the reviewer agent caught a credential fallback and a path-traversal hole.

Generation can take many minutes with no output, so a silence timeout cannot detect hangs; the author added a Stop button and an overall limit. OpenWiki checkpoints per page, not during planning, so a restart mid-plan loses that work. A global git rule rewriting https to SSH silently broke token clones until git config was isolated.