Vault Roadmap

Definition

The vault roadmap defines the evolution of this LLM Wiki from its current Foundation phase toward a fully automated, scaled knowledge system. It is derived from studying the six leading implementations and identifying which capabilities matter for a CLI-based, LLM-maintained research vault (as opposed to a product or desktop app).

Reference Implementations Studied

Implementation	Stars	Key Innovation	What to Borrow
nashsu/llm_wiki	14.3k	Tauri desktop, 4-signal relevance, MCP server	MCP server pattern
rohitg00 (LLM Wiki v2)	1.5k	Memory lifecycle, typed graph, hybrid search 95.2% LongMemEval	Lifecycle + hybrid search
atomicstrata/llm-wiki-compiler	1.7k	L0-L3 lifecycle profiles, OKF canonical, CLI-first	Lifecycle profiles
lucasastorian/llmwiki	1.3k	Chrome extension, email, course mode, hosted	Event-driven ingest pattern
Astro-Han/karpathy-llm-wiki	1.5k	Agent Skills-based, pure Claude Code, 94 articles from 99 sources	Our closest architectural match
praneybehl/llm-wiki-plugin	60	Explicit graph layer (nodes.jsonl, edges.jsonl, graph.sqlite, graph.graphml)	Graph export format

Current Position: Foundation + Discipline Complete (Verified 2026-08-03)

The core Karpathy pattern, the governance layer, and all TR-01–TR-18 implementation items are in place. Implementation state is verified against files and live gates in docs/implementation-status.md, not by re-reading historical checklists:

• raw/ → wiki/ → governance architecture
• OKF-compliant frontmatter with tag taxonomy
• 16 guardrails (link cap, forward-only, compounding invariant, routing, trusted relationships, external-URL rule, gains/losses report, etc.)
• Three core operations: ingest, query, lint (each governed by a synaptic-* skill)
• Wikilint automated gate (scripts/wikilint.ps1)
• Deterministic query gate (scripts/query-check.ps1) and procedural lint (scripts/process-lint.ps1)
• MCP server (mcp/server.py) — live integration passing 43/43
• Graph layer export (scripts/graph-export.ps1) — 260 nodes/pages, 1623 directed edges (main + prompt wiki)
• Hybrid query helper (scripts/hybrid_query_helper.py) — BM25 + vector + graph PageRank (RRF fusion)
• Source watcher + ingest queue (scripts/watch.ps1, scripts/auto_ingest.py) — claim/release/complete + Page Candidates with per-candidate decisions
• External URL capture + freshness ledger (scripts/external_links.py)
• Multi-wiki scopes (main + prompt) and prompt-wiki content audit (147 pages)
• Community detection via Louvain (graph_communities)
• Main wiki: 111 pages, 18 filed queries — implementation matrix: 18/18 TR items IMPLEMENTADO, 0 PARCIAL, 0 NÃO IMPLEMENTADO

Implications

The Foundation (Phase 1) and Discipline (Phase 2) capabilities are shipped, not roadmap. The open design space narrows to Phase 3 (Automation: scheduled and content-capture pipelines) and the few Phase 4 items that are still genuine gaps (general graph-traversal queries). The RSS/feed ingester is the strongest Phase 3 candidate and is the feature proposed on this page below.

Roadmap

Phase 1: Navigation (0–100 pages) — COMPLETE (verified 2026-08-03)

#	Capability	Why	Borrowed from	Status
1	✅ Wikilint gate	Automated structural enforcement	Oleg Ivanchenko	Done
2	✅ Graph layer export	scripts/graph-export.ps1 — auto-generate nodes.jsonl/edges.jsonl from wikilinks	praneybehl	Done
3	✅ MCP server	Expose wiki as MCP tool for query/ingest from other agents	nashsu, atomicstrata	Done
4	✅ Hybrid query	BM25 + vector search for navigating beyond index.md at 100+ pages	rohitg00 (95.2% LongMemEval)	Done
5	✅ Source watcher	Trigger capture automatically when a new file appears in raw/	lucasoridian, rohitg00	Done (TR-09)

Implications. Installation-and-queue capture is implemented; fully automatic LLM synthesis is deliberately kept agent-driven and never auto-generated (Guardrail #10).

Phase 2: Discipline (100–200 pages)

#	Capability	Why	Status
6	Lifecycle profiles (L0–L3)	Tag pages: L0=stub, L1=developing, L2=mature, L3=synthesized	✅ Done (TR-02/TR-03)
7	Confidence scoring per section	LLM self-evaluates each section on ingest, flags low-confidence claims	✅ Done (frontmatter confidence + per-claim markers)
8	Scheduled lint	Weekly auto-lint via Task Scheduler or git hook	✅ Done (maintenance.ps1 + task template)
9	Quality gates	Reject new pages below threshold; flag stale pages for review	🟡 Stale/low-confidence checks; no hard reject (guardrail-driven, not mechanical)
10	Consolidation tiers	Move low-value pages to archive; merge redundant pages	✅ Done (archive-page.ps1; supersession metadata)

Implications. Discipline behavior is largely mechanical today. The remaining gap is a hard quality gate (rejecting pages below a confidence floor), which sits apart because page creation is deliberately an LLM decision, not a threshold check.

Phase 3: Automation (200–500 pages) — current target

#	Capability	Why	Status
11	Crystallization	Treat chat sessions, logs, and research threads as sources	⬜ Candidate — includes Deep Research filing_intent hand-off (run_manifest.json → dashboard queue of unfiled runs; DECISIONS.md 2026-08-06, nashsu-inspired)
12	Event-driven ingest	Watch raw/; auto-ingest on file create	✅ Done (TR-11 claim/release/Page Candidates; Work Units variant declined 2026-07-31)
13	Self-healing lint	Auto-fix broken links, auto-merge orphans	⬜ Candidate (lint is advisory; fixes are LLM decisions)
14	CI/CD pipeline	Git push → lint → deploy to read-only site or Obsidian sync	🟡 Partial (lint+tests in CI; no read-only deploy)
15	RSS/feed ingester	Scheduled pull from configured feeds into raw/	⬜ Selected candidate — proposal below

Implications. Event-driven ingest is done; what remains in Phase 3 is the content-flow antecedents. The RSS ingester (Row 15) is the one that converts the most manual part of capture (URL discovery) into schedule, and it composes with the already-shipped queue/ledger, so it is the recommended next feature.

Phase 4: Scale (500+ pages)

#	Capability	Why	Status
16	Typed relationships	”uses”, “depends on”, “contradicts”, “supersedes” as edge types	✅ Done (Guardrail #14; supersession metadata)
17	Graph traversal queries	”What depends on Redis?” walks the typed graph	🟡 Partial (PageRank + neighbors/communities; no general traversal)
18	Hybrid search production	BM25 + vector + graph RRF fusion (rohitg00 95.2% recipe)	✅ Done (hybrid_query_helper.py)
19	Multi-vault routing	Different domains → different wikis, query routed automatically	🟡 Partial (intra-vault scopes TR-14; no runtime vault switching)
20	Corporate governance	Sandboxes, tunnels, vault-level permissions	⬜ Not applicable (single user, local-first)

Feature Proposal — RSS/Feed Ingester (Phase 3, Row 15)

Status: candidate — not implemented. It is not on the “What NOT to Do” list below, so it is the selected next feature; scope has to be approved explicitly (consistent with how DECISIONS.md [2026-07-31] words the advanced-ingest decision).

What

A scheduled pull that reads a small configured list of RSS feeds, fetches new entries, and lands each entry as an immutable snapshot under a raw directory with provenance, then queues it for ingest exactly the way scripts/external_links.py captures URLs and scripts/auto_ingest.py queues them today.

Why it is next

• It automates the most repetitive manual part of capture (finding and saving a URL), which is the part the owner does today by hand.
• It composes cleanly with the existing pipeline — no new architecture, no new governance model, no page auto-creation.
• It reuses TR-09 (watcher/queue), TR-10 (external capture + freshness), and TR-11 (claim/release/Page Candidates). The new surface is one config file + one fetch script.

Borrowed from

• lucasastorian/llmwiki and rohitg00 (named in Reference Implementations above) — near-automatic delivery of new articles into the vault.

Design sketch (aligned with existing architecture)

• Config: a small file listing feeds (title, url) — the analog of how _schema.md centralizes taxonomy; compute created/content_hash at fetch.
• Fetch: a Python helper reading feeds and writing each entry as markdown with source_url, source_type: feed-or-wiki-entry (or web), created, consistent with the raw/external/ snapshot contract. Append-only: a changed entry writes a new snapshot and preserves the old one.
• Pipeline: write snapshot → enqueue via auto_ingest.py → the LLM decides pages (Guardrail #10) → complete through the existing batch flow (--claim/--complete cycle).
• Scheduling: reuse the existing Task Scheduler template (same as maintenance.ps1) or an on-demand call; not a background-hosted daemon.
• Cross-reference: link back to [[ingest]], [[query]], [[lint]], and the external-URL freshness work to stay inside the governed flow.

Non-goals (boundaries)

• No automatic synthesis or automatic page creation — the agent still owns page decisions (Guardrail #10).
• No dedup guarantee beyond the agent’s judgment (the query gate checks honesty, not mechanical dedup).
• No hosted reader or subscription service; local scheduled only.

Open questions

• Feed entries to raw/articles/ vs a dedicated raw/feeds/ directory — and what the route classifier sees.
• Is adding feedparser (or stdlib-only fetching) an acceptable dependency?
• Do feed entries reuse the external-link freshness ledger, or stay purely local history like other raw/ content?
• Should each scheduled pull run one full ingest cycle per entry, or batch new entries and let the LLM claim them in the existing cycle?

Implications

Adopting the RSS ingester converts URL discovery from a manual step into a scheduled one while keeping all the vault’s non-negotiables intact: immutable provenance, append-only snapshots, and LLM-owned page decisions. It reuses TR-10/TR-11 and requires only one config file and one script, so it is the lowest-risk, highest-leverage Phase 3 build available. It also validates the pipeline in DECISIONS.md that gates future automation behind an explicit scope choice.

Decision Logic: What NOT to Do

Some advanced features are intentionally excluded because they don’t fit a CLI-based research vault:

Feature	Why skip
Desktop GUI (Tauri)	Adds build complexity; Claude Code is the interface
Chrome extension	Web clipping can be done via git-based CLI
Course mode	Not relevant for a personal research vault
Hosted option	Local-first is a core principle
Email integration	Unlikely to beat an RSS/feed route for a local vault
Work Units / Analysis Packets / lease recovery	Declined 2026-07-31; they solve multi-agent coordination that does not exist in this single-user, sequential-session vault

Implications. The exclusion list still holds; RSS is the complement of “email integration” — both are capture-delivery, but RSS is scheduled and installed where email was rejected as low-ROI. The declined Work Units rows preserve the reason that the advanced ingest stay out of scope.

Related Concepts

• llm-wiki — The pattern this roadmap extends
• lint — Wikilint is the foundational gate
• knowledge-graph — Graph layer (Phase 1) enables explicit graph
• memory-lifecycle — Phase 2 discipline applies lifecycle concepts
• ingest — Event-driven and crystallization modes (Phase 3)
• query — Hybrid search (Phase 1) and graph traversal (Phase 4)
• external-skills-ecosystem — MCP integration (Phase 1) connects to external skills
• ecossistema-stacks-vs-nosso-vault — Current stack comparison against represented ecosystem projects
• coolest-under-explored-feature — Community detection as the highest-leverage under-used capability
• surprising-connections-community-insights — Delivered insight layer operationalizing community detection (Phase 4 stepping stone)

Open Questions

• At what page count does the implicit wikilink graph become insufficient? Sources say 100-200 but no empirical data.
• Is the Astro-Han approach (Agent Skills, pure Claude Code) the right long-term model for this vault, or should we adopt an MCP server? Both are CLI-compatible but MCP adds external dependencies.
• RSS scope: feed entries to raw/articles/ or a dedicated raw/feeds/; whether feedparser is an acceptable dependency; whether feed entries reuse the external freshness ledger.

Relevant Skills & Dependencies

• brainstorming – used to design and plan the implementation.
• writing-plans – generates a granular implementation plan and task breakdown.
• todowrite – tracks multi-phase tasks and status.
• Testing frameworks: Pester (PowerShell unit tests) and pytest (Python integration tests).
• CI/CD: GitHub Actions workflow runs lint, tests, and deployment.
• MCP server: FastAPI (Python) for exposing the vault as an MCP endpoint.
• BM25: Whoosh or Pyserini for classic term-based retrieval.
• Vector embeddings: sentence-transformers library (e.g., all-MiniLM-L6-v2).
• Graph processing: NetworkX for generating nodes.jsonl/edges.jsonl and later traversals.
• Source watcher: Python watchdog package (or PowerShell Register-ObjectEvent).
• Feeds (proposal): feedparser (or stdlib-only) — to fetch configured feed entries.

Sources

^[raw/articles/denser-llm-wiki-analysis.md] ^[raw/articles/llm-wiki-v2-rohitg00-2026.md] ^[raw/papers/pesquisa-aprofundada-padrao-llm-wiki.md]