Jun 9, 2026, 3:23 PM

This commit is contained in:
Paweł Domański
2026-06-09 13:23:52 +00:00
parent cff1376a23
commit ab6daac16b
+24 -11
View File
@@ -68,29 +68,42 @@ There are three distinct layers to this setup:
## Feynman's 12 Problems Framework
We maintain a list of ~12 "Favorite Problems" in `wiki/feynman_problems.md`. Every new piece of information is checked against this list to see if it offers a new insight or connection.
## Workflows
## Operations / Workflows
### 1. Ingest
When the user says "ingest [source]" or adds a file to `raw/`:
1. Read the raw source completely.
2. Create `wiki/summaries/<source-slug>.md` with full summary.
*You drop a new source into the raw collection and tell the LLM to process it.*
1. Read the raw source completely. Discuss key takeaways if prompted.
2. Create `wiki/summaries/<source-slug>.md` with a full summary.
3. Identify all concepts, entities, and strategies mentioned.
4. **Feynman Check**: Compare against `wiki/feynman_problems.md` and update it if connections are found.
5. Create/Update concept and entity pages using the required sections.
6. Add cross-links in both directions between all touched pages.
7. Update `wiki/log.md` and relevant indices in `wiki/indices/` (thematic and type-based).
7. Update `wiki/log.md` and relevant indices in `wiki/indices/`.
8. Update `wiki/index.md` if new categories are needed.
9. Flag any contradictions with existing content.
*(A single source might touch 10-15 wiki pages. The LLM handles the cascading updates.)*
### 2. Query
1. Read `wiki/index.md` and relevant thematic indices in `wiki/indices/` to find relevant pages.
2. Synthesize an answer citing specific pages with wiki links.
3. If new insight is found, create a synthesis page in `wiki/syntheses/`.
*You ask questions against the wiki. The LLM searches for relevant pages, reads them, and synthesizes an answer.*
1. Read `wiki/index.md` and relevant thematic indices to find pages.
2. Synthesize an answer with explicit citations (wiki links). Answers can take different forms (markdown page, comparison table, slide deck, chart).
3. **Crucial insight**: Good answers should be filed back into the wiki as new pages (e.g., in `wiki/syntheses/`). A comparison you asked for or a connection you discovered shouldn't disappear into chat history.
### 3. Lint
1. Check for orphan pages, stale claims, contradictions, and missing cross-links.
2. Fix automatically where possible; report others.
3. Suggest new sources or topics.
*Periodically, ask the LLM to health-check the wiki.*
1. Look for orphan pages with no inbound links.
2. Check for contradictions between pages or stale claims that newer sources have superseded.
3. Find important concepts mentioned but lacking their own page.
4. Identify missing cross-references or data gaps that could be filled with a web search.
5. Suggest new questions to investigate and new sources to look for to keep the wiki healthy as it grows.
## Indexing and Logging
Two special files help navigate the wiki as it grows:
- **`wiki/index.md` (Content-oriented)**: A catalog of everything in the wiki. Each page listed with a link, a one-line summary, and optionally metadata (date, source count). Organized by category. The LLM updates it on every ingest. Read this first when answering a query.
- **`wiki/log.md` (Chronological)**: An append-only record of what happened and when (ingests, queries, lint passes). Prefix entries consistently (e.g., `## [YYYY-MM-DD] ingest | Title`) so it's parseable via simple grep commands.
## Why this works
The tedious part of maintaining a knowledge base is not the reading or the thinking — it's the bookkeeping: updating cross-references, keeping summaries current, noting contradictions, and maintaining consistency. Humans abandon wikis because the maintenance burden grows faster than the value. LLMs don't get bored, don't forget to update cross-references, and can touch 15 files in one pass. The human curates sources and directs the analysis; the LLM does everything else. This relates to Vannevar Bush's *Memex* (1945) — a curated knowledge store with associative trails — but solves the problem of "who does the maintenance".
## Rules
- Never modify files in `raw/`.