Initial commit: Cascade Knowledge Base with OKF-aligned schema and skills

Sets up the layered wiki/linked/libs knowledge base described in
CLAUDE.md/AGENTS.md, with a frontmatter schema, recursive index/log
convention, and conformance lint checks aligned with Google's Open
Knowledge Format. Adds two on-demand Claude Code Skills: export-okf
(regenerate an OKF-conformant bundle at outputs/okf/) and sync-changes
(reconcile this repo's git history with its origin remote, surfacing
conflicts to the user).

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
This commit is contained in:
Michał Kopeć 2026-07-13 19:03:50 +02:00
commit c56348b15b
14 changed files with 1320 additions and 0 deletions

View file

@ -0,0 +1,181 @@
---
name: export-okf
description: Export the local wiki/ knowledge base as an Open Knowledge Format (OKF) v0.1-conformant bundle at outputs/okf/, so any generic OKF tool can consume it. Use when the user asks to "export the wiki as OKF", "generate the OKF bundle", "export to OKF", "publish the OKF export", or "sync outputs/okf".
---
# Export to OKF skill
## Purpose
Regenerate `outputs/okf/` from the current `wiki/` tree as a bundle that
conforms to Google's Open Knowledge Format (OKF) v0.1 spec
(https://github.com/GoogleCloudPlatform/knowledge-catalog/blob/main/okf/SPEC.md),
so any generic OKF consumer (e.g. Google's reference graph visualizer) can
read this knowledge base without needing to understand this repo's richer,
more opinionated schema (`confidence`, `quality`, `retention`, `supersedes`,
dual-linking, the cascade layers). This is a one-way, on-demand export —
`wiki/` stays the authoritative source; `outputs/okf/` is always a derived
artifact of it, never edited by hand and never fed back in.
This skill only runs when explicitly invoked — it is deliberately not part
of the always-loaded `CLAUDE.md`/`AGENTS.md` Ingest/Lint workflows, so its
mapping ruleset doesn't tax every session's context.
## Trigger phrases
Use this skill when the user says things like:
- "export the wiki as OKF" / "export to OKF"
- "generate the OKF bundle" / "regenerate outputs/okf"
- "publish the OKF export"
- "sync outputs/okf with the wiki"
## How to run this skill
### Step 1 — Read the source tree
Read every file under `wiki/` (the whole tree, including `entities/`,
`graph/`, and any other subdirectories present). Note which filenames are
`index.md` or `log.md` at any depth (these are OKF's two reserved names) —
everything else is a concept document.
### Step 2 — Clear and rebuild `outputs/okf/`
`outputs/okf/` is a pure, fully-regenerated build artifact. Delete its
current contents (if any) and rebuild it from scratch by mirroring `wiki/`'s
directory structure 1:1 under `outputs/okf/`. Never hand-patch an existing
export — always regenerate the whole bundle, so it can't accumulate stale
files left over from wiki pages that were since renamed or removed.
Do not touch anything outside `outputs/okf/`. Do not run any `git`
commands — regenerating files is this skill's job; staging and committing
the result is a separate, explicit action left to the user.
### Step 3 — Transform concept documents (every file that isn't `index.md`/`log.md`)
For each such file, rewrite its frontmatter using this field mapping:
| wiki/ field | OKF output field | Rule |
|---|---|---|
| `type` | `type` | passthrough (required on both sides — every wiki page should already have one; if a page is somehow missing it, use `type: unknown` and flag it in the final report rather than skipping the file) |
| `resource` | `resource` | passthrough |
| `tldr` | `description` | rename |
| `last_updated` | `timestamp` | passthrough as-is (bare `YYYY-MM-DD` is a valid ISO 8601 date — do not fabricate a time-of-day that was never recorded) |
| *(none — derive)* | `title` | the first `# H1` heading in the body; if there is none, slugify the filename (e.g. `foo-bar.md` → "Foo Bar") |
| `confidence`, `quality`, `retention`, `supersedes`, `superseded_by`, `freshness_window_days` | same key names | passthrough unchanged, as OKF extension fields — OKF requires consumers to tolerate unrecognized keys, so these ride along as-is |
| `kb_schema_version` (only ever present on `wiki/index.md`) | *(omit)* | OKF's root `index.md` frontmatter is spec-limited to `okf_version` only; this key has no valid home in the bundle and is dropped, not relocated |
| *(none)* | `tags` | omit — there is no source field to derive it from; do not fabricate |
Then rewrite the body's links:
1. **Strip wikilinks.** Every dual-link in the source looks like
`[[Page Name]] / [Page Name](path.md)`. Delete the `[[...]]` half
(and the ` / ` separator if present), keep only the
`[text](path.md)` half. OKF has no wikilink concept.
2. **Rewrite repo-root-absolute intra-wiki links.** A link like
`/wiki/entities/foo.md` becomes `/entities/foo.md` — the OKF bundle
root is `outputs/okf/`, not the repo root, so the leading `/wiki`
segment must be stripped. Plain relative links (e.g.
`../entities/foo.md`) need no change, since the export mirrors
`wiki/`'s tree exactly.
3. **Leave `linked/<name>/...` and `libs/<name>/...` references
untouched.** These point outside `wiki/` and outside any
self-contained bundle — converting or inlining them is out of scope.
OKF explicitly tolerates broken links, so leaving these as
unresolvable-outside-the-repo references is spec-compliant. Count
how many of these you leave untouched, for the final report.
### Step 4 — Regenerate `index.md` files
**Root `outputs/okf/index.md`:** frontmatter contains *only*
`okf_version: "0.1"` — this is the one documented exception to "index.md
has no frontmatter" in the OKF spec. Body is a flat bullet list, one line
per linked page or subdirectory, in the form
`* [Title](path) - one-line description` (reuse each page's `description`,
i.e. the renamed `tldr`, as the description text). Drop the source
`wiki/index.md`'s "Use when" column entirely — it's a Claude-agent-only
lazy-loading optimization with no meaning to a generic OKF consumer — and
drop any prose sections (like the source's "## Entity Pages" paragraph).
**Every nested `index.md`** (`entities/index.md`, `graph/index.md`, and
any future topic-folder index): no frontmatter, ever. Strip the source's
explanatory prose and italic placeholder notes (e.g.
"*(No entities yet — populated on the next ingest.)*"), keeping only the
bullet list — an empty list is spec-valid if the directory has no pages
yet.
### Step 5 — Regenerate `log.md` files
For each `log.md` in the source tree (root and any subdirectory), reformat
its entries into OKF's convention: group entries by date under
`## YYYY-MM-DD` headers (date only, no time, newest date first), each
entry as a bullet:
```
* **Verb**: description with [links](/path/to.md) (source: original source text).
```
Map the source's `ACTION TYPE` to an OKF verb: `CREATE` → Creation,
`UPDATE` → Update, `DELETE` → Deprecation, `RESTRUCTURE` → Update (fallback
for anything else). Fold the source entry's `- **Source:**` line in as the
trailing parenthetical shown above rather than dropping it — it's useful
provenance information and OKF's format has room for free text after the
verb. Drop the `---` horizontal-rule separators between entries; they are
not part of OKF's log format.
### Step 6 — Handle non-reserved special pages
`wiki/error-book.md` and `wiki/overview.md` are not OKF reserved
filenames (only `index.md` and `log.md` are) — export them as ordinary
concept documents using the Step 3 rules like any other page. They should
already carry `type`/`tldr`/`last_updated` frontmatter; if you ever find
one that doesn't, that's a lint problem in the source wiki — flag it in
the report rather than silently patching the export.
### Step 7 — Validate the output bundle
Before reporting done, re-check the *generated* `outputs/okf/` bundle
against OKF's own conformance criteria (the same shape of check `CLAUDE.md`
§5 step 1 runs against the source wiki):
- Every non-reserved `.md` file has frontmatter with a non-empty `type`.
- The root `index.md`'s frontmatter contains only `okf_version` (or is
empty); every nested `index.md` has no frontmatter at all.
- Every `log.md` entry matches the `## YYYY-MM-DD` header pattern.
- Every intra-bundle link (i.e. every link you did NOT leave untouched in
Step 3.3) resolves to a file that actually exists in `outputs/okf/`. If
the rewrite in Step 3.2 produced a link that doesn't resolve, that's a
bug in this export, not an acceptable "broken link" — fix it before
reporting done, don't just note it as a warning.
### Step 8 — Report
Tell the user:
- How many concept documents were exported.
- How many `index.md`/`log.md` files were regenerated.
- How many `linked/`/`libs/` cross-cascade references were left
unconverted (Step 3.3), since those won't resolve if the bundle is ever
moved or shipped standalone.
- Any conformance issues found in Step 7 and whether they were fixed.
- A reminder that `outputs/okf/` has been regenerated on disk but not
staged or committed — that's a separate step for the user to take when
ready to publish the update.
## Edge cases
- **Empty `wiki/entities/` or `wiki/graph/`** (as of writing, both are
empty): still regenerate their `index.md` as an empty bullet list under
`outputs/okf/entities/` and `outputs/okf/graph/` — an empty index is
spec-valid, don't skip the directory entirely.
- **A wiki page missing `type`:** per Step 3, use `type: unknown` and flag
it in the report — this indicates the source wiki itself failed lint's
conformance check (see `CLAUDE.md` §5 step 1), which is worth surfacing
to the user rather than quietly masking it in the export.
- **A future `wiki/archived/` directory:** export it like any other
subdirectory (mirror the structure, apply the same per-file rules) —
OKF has no notion of archival status; `retention`/`freshness_window_days`
already ride along as extension fields for any consumer that cares.
- **Re-running the skill with no wiki changes since the last run** should
produce byte-identical output — if you notice non-determinism (e.g. from
arbitrary ordering when listing directory entries), sort filenames
alphabetically wherever you're generating a bullet list or walking a
directory, so re-runs are stable.

View file

@ -0,0 +1,199 @@
---
name: sync-changes
description: Reconcile this repo's git history with its origin remote — pull down remote commits, commit any local working-tree changes, resolve any conflicts with the user, then push. Use when the user asks to "sync changes", "sync with git", "sync with the remote", "sync with origin", "push and pull my changes", "reconcile git", or "sync the repo". This is a git-level operation, distinct from the content-level "Sync the wiki" / "Ingest" workflow in CLAUDE.md, which processes raw/inbox/ into structured wiki/ pages.
---
# Sync changes skill
## Purpose
Keep this repo's local working tree and its `origin` remote in sync in both
directions: pull remote commits down, commit local file changes, resolve any
conflicts with the user, then push. `wiki/`, `outputs/`, `workload/`, and
every other tracked path are treated as opaque files at this layer — this
skill only does git mechanics (stage/commit/fetch/merge/push). It never
invokes the Ingestion Workflow, never re-derives entities/graph/index/log
content, and never tries to semantically reconcile markdown or frontmatter —
a conflicted file is just text with conflict markers until the user says
otherwise.
Unlike the `export-okf` skill, this skill **does** commit and push on its
own once conflicts (if any) are resolved — that automation was explicitly
requested for this skill.
## Trigger phrases
Use this skill when the user says things like:
- "sync changes"
- "sync with git" / "sync with the remote" / "sync with origin"
- "push and pull my changes"
- "reconcile git"
- "sync the repo"
Do **not** use this skill for bare "Sync" or "Sync the wiki" — those trigger
the content-level Ingestion Workflow in `CLAUDE.md`/`AGENTS.md` §3 instead
(processing `raw/inbox/` into `wiki/`), which this skill has nothing to do
with.
## How to run this skill
### Step 1 — Pre-flight safety checks
Run:
```bash
git rev-parse --is-inside-work-tree
git status --porcelain=v1
```
Check for an in-progress merge/rebase/cherry-pick:
```bash
test -f .git/MERGE_HEAD && echo "MERGE IN PROGRESS"
test -f .git/REBASE_HEAD -o -d .git/rebase-merge -o -d .git/rebase-apply && echo "REBASE IN PROGRESS"
test -f .git/CHERRY_PICK_HEAD && echo "CHERRY-PICK IN PROGRESS"
```
If any of these report something in progress, **stop immediately**. Tell
the user a git operation is already underway and must be resolved or
aborted manually (`git merge --abort` / `git rebase --abort`) before running
this skill again. Do not try to clean it up yourself.
Scan the `git status --porcelain` output for paths that look like secrets:
`.env`, `.env.*`, anything containing `credentials`, `*.pem`, `*.key`,
`id_rsa*`, anything containing `secret` (case-insensitive). If any match,
ask the user via `AskUserQuestion` whether to include or skip each one
*before* staging anything in Step 3 — never silently commit or silently
drop a flagged file.
### Step 2 — Detect the first-run / unrelated-histories case
```bash
git fetch origin
git rev-parse HEAD # fails with "unknown revision" if local has no commits yet
git rev-parse origin/main # fails if the remote branch doesn't exist/is empty
```
- **Local `HEAD` exists** → go to Step 3, regardless of remote state.
- **Local `HEAD` doesn't exist, and `origin/main` doesn't exist or is empty**
→ this is a plain first publish, not a reconciliation. Proceed
automatically to Step 3 (it will just commit and push with nothing to
merge).
- **Local `HEAD` doesn't exist, but `origin/main` already has commits**
**hard stop, every time this is detected.** Show the user:
```bash
git log origin/main --oneline | head -20
git status --porcelain # everything currently on local disk, untracked
```
Then ask via `AskUserQuestion` with exactly these three options:
- "Merge — bring in origin/main's history (`git merge --allow-unrelated-histories origin/main` after committing local content), then resolve any conflicts"
- "Remote wins — check out origin/main first (`git reset --hard` is not needed since there's no local commit yet; instead branch from origin/main), then reapply my local changes on top of it"
- "Stop — I'll sort this out myself"
Do **not** offer a fourth "discard remote, force local to become main"
option — that requires a force-push and is out of scope for this skill;
if the user wants that, tell them it needs to be done manually. Execute
only the option chosen, then continue to Step 3 with whichever git state
results.
### Step 3 — Steady-state flow
Order matters: **commit local changes first, then fetch/merge, then push.**
Committing first turns any overlap into an ordinary merge conflict (which
Step 4 already knows how to present), rather than a stash-pop conflict with
no commit boundary to fall back on.
```bash
# Commit local changes, if any (skip entirely if git status --porcelain is clean)
git add <path1> <path2> ... # explicit paths only — never `git add -A` or `git add .`
git commit -m "Sync: local changes as of <ISO timestamp>"
# Reconcile with remote
git fetch origin
git merge origin/main # merge, never rebase — rebase would rewrite local commits
# and require a force-push, which is out of scope here
```
Outcomes of the merge:
- `Already up to date.` or a clean auto-merge → continue below.
- `CONFLICT` → go to Step 4, then come back here once every conflict is
resolved and committed.
```bash
# Push
git push origin main
```
If the push is rejected as non-fast-forward (the remote moved again between
fetch and push), retry the fetch → merge → push cycle **exactly once**. If
it fails again, stop and report the raw error to the user — never force,
never retry more than once.
### Step 4 — Present each conflict to the user
```bash
git diff --name-only --diff-filter=U
```
For each path returned, read the full file. It may contain more than one
conflict block — handle each independently, leaving all surrounding
unconflicted content untouched. Each block looks like:
```
<<<<<<< HEAD
(local text)
=======
(remote text)
>>>>>>> origin/main
```
For each block:
- Call `AskUserQuestion` with the file path (and block number if the file
has more than one) as context, showing both the local and remote text in
full. Options: **"Keep local version"**, **"Keep remote version"**,
**"Provide merged text"**.
- If "Provide merged text" is chosen, ask the user to supply the
replacement text directly.
- Rewrite the block with the chosen/provided content and strip the three
marker lines for that block.
- If the conflict is on a binary file or the markers can't be cleanly
parsed, skip the "Provide merged text" option and instead resolve with
`git checkout --ours <path>` or `git checkout --theirs <path>` per the
user's local/remote choice.
Once every block in a file is resolved, `git add` that file immediately —
don't wait for every file to be done before staging the first one, so
progress is always visible in `git status`. Once every conflicted file is
staged, commit:
```bash
git commit -m "Merge origin/main (conflicts resolved with user input)"
```
Then return to Step 3's push.
### Step 5 — Report
End with a structured summary:
```
## Sync report
**Pulled from origin/main:** <N> commit(s) — <oneline log, or "none, already up to date">
**Committed locally:** <N> file(s) — <paths>, commit <short-hash> (or "no local changes to commit")
**Conflicts encountered:** <N> (or "none")
- <path> (block N of M) — resolved: kept local / kept remote / custom merged text
**Secrets flagged:** <files and the user's choice, or "none">
**Push result:** origin/main now at <short-hash> (or the retry/failure detail if it didn't succeed)
```
If anything was committed under `wiki/` without a corresponding
`wiki/log.md` (or subdirectory `log.md`) update in the same diff, add a
one-line nudge to run Ingest/Lint afterward — this is a suggestion, not a
blocker.
## Edge cases
- **Nothing to do on either side** — report "already in sync," make no
commits, run no push.
- **Local changes only, remote unchanged** — commit, fast-forward push, no
merge/conflict step needed.
- **Remote changes only, local clean** — fast-forward merge, nothing to
commit, nothing to push; report "pulled N commits, nothing local to
push."
- **Push rejected twice in a row** — stop, report the raw git error, do not
force and do not retry a third time.
- **No remote configured, or fetch/push fails on auth/network** — report
the error clearly. This skill does not manage git credentials.

2
.gitignore vendored Normal file
View file

@ -0,0 +1,2 @@
libs/
tmp/

225
AGENTS.md Normal file
View file

@ -0,0 +1,225 @@
# SYSTEM PROMPT: CASCADE KNOWLEDGE BASE ARCHITECT
## ROLE & PHILOSOPHY
You are an autonomous Knowledge Architect Agent for a **Cascade Knowledge Base**. The system is designed as a layered stack: read-only upstream knowledge bases (symlinked in `linked/` and git-managed copies in `libs/`) form the foundation, and the local mutable knowledge base overlays on top. This means knowledge flows downward through the cascade — upstream truths are preserved, while you only ever modify the local layer.
If an entity exists in both the local wiki and any upstream KB, the local version takes precedence and overrides the upstream one.
You view directories as storage disks, context windows as RAM, and your processing loops as CPU cycles. Your sole objective is to build, maintain, and dynamically structure a comprehensive knowledge base, respecting the cascade priority rules at all times.
You possess full autonomy over local directory structure, file naming conventions, and cross-referencing. You must strictly adhere to the operational boundaries and file management rules detailed below.
---
## 1. DIRECTORY STRUCTURE
The root directory contains exactly seven top-level entries. You must maintain this structure flawlessly:
```
├── libs/ # GIT-MANAGED COPIES ONLY. Read-only external KBs copied into the repo (gitignored — populated by the user via git).
│ └── <name>/ # Individual external knowledge base (immutable — never write here).
├── linked/ # SYMLINKS ONLY. Each entry is a symbolic link to another KB root (read-only upstream source of truth).
│ └── <name>/ # Individual upstream knowledge base (immutable — never write here).
├── outputs/ # MANAGED BY AGENT. Generated artifacts, exports, compiled files produced from the wiki.
│ # On-demand workflows beyond Ingest/Lint may be defined as Claude Code Skills under
│ # `.claude/skills/` — check there before assuming a capability doesn't exist.
├── raw/ # WRITTEN BY USER ONLY. Raw files, scratchpad notes, URLs, links.txt.
│ └── inbox/ # Drop zone: unprocessed material the agent cleans on ingest.
├── tmp/ # MANAGED BY AGENT. Temporary files, caches, intermediate processing artifacts (gitignored).
├── wiki/ # MANAGED BY AGENT. The local, mutable, structured markdown wiki. Overlays linked/ and libs/.
│ ├── index.md # Entry point / routing table with "Use when" triggers. Carries kb_schema_version.
│ ├── overview.md # High-level map of the knowledge base.
│ ├── log.md # AGENT LOG. Root rollup tracking wiki-level modifications (see Recursive Index & Log Convention).
│ ├── error-book.md # AGENT MAINTAINED. Records compilation errors and derived constraints.
│ ├── entities/ # AGENT POPULATED. Typed entity pages (people, projects, concepts, libraries). Has its own index.md.
│ └── graph/ # AGENT MAINTAINED. Edge lists and relationship data for the knowledge graph. Has its own index.md.
└── workload/ # MANAGED BY AGENT. Summaries of discussions and decisions.
└── YYYY-MM-DD_summary.md
```
### Cascade Lookup Priority
When searching for any entity, concept, or file, use the following cascade (first match wins):
1. **Local wiki/** — highest priority; agent-written content overlays everything below.
2. **linked/\<name\>/** — read-only upstream KBs mounted as symlinks, searched in alphabetical order.
3. **libs/\<name\>/** — read-only external KBs copied via git, searched in alphabetical order.
4. If no match is found anywhere, treat the entity as unknown.
You must **never** create, modify, move, or delete any file or directory inside `linked/` or `libs/`.
### Index-First Navigation
When searching for information, always start by looking for `index.md` files.
Read the index to discover what pages and subdirectories are available before
drilling into individual files. Scan `index.md` across all layers:
1. **wiki/** — scan `wiki/index.md`, then recursively check any subdirectory `wiki/<topic>/index.md`.
2. **linked/\<name\>/** — for each linked upstream KB, scan its root `index.md` and subdirectory indexes.
3. **libs/\<name\>/** — same pattern: root index first, then subdirectory indexes as needed.
This avoids blind filesystem scans and uses the index as a curated table of contents — exactly as Karpathy's original pattern intended.
### Recursive Index & Log Convention
Index-First Navigation only works if subdirectory indexes actually exist. Maintain them as follows:
- Every `wiki/` subdirectory that groups multiple pages (`entities/`, `graph/`, and any future topic folder) must contain its own `index.md`. It carries no frontmatter and is a flat bullet list of links, each with a one-line description mirroring the linked page's `tldr` — plus a link to any nested subdirectory.
- A subdirectory may also keep its own `log.md` once it has enough independent change history to warrant one (a judgment call — typically once it holds several pages or changes on its own cadence, separate from the rest of the wiki). Entries follow the same reverse-chronological format as Rule B.
- The root `wiki/log.md` stays the top-level rollup: it records changes made directly under `wiki/` (`index.md`, `overview.md`, `error-book.md`, directory-creation events) plus one pointer line whenever a subdirectory log absorbs a change, e.g. `- See wiki/entities/log.md for entity-page changes on this date.` Each change gets exactly one home log — never record the same change in both.
### Lazy-Loading with "Use When" Triggers
The `wiki/index.md` is a routing table. Each entry has a **Use when** column
that lists trigger keywords. Before loading any page:
1. Read `wiki/index.md` (stays in context — it is small).
2. Match the current task's keywords against the **Use when** entries.
3. Only load the matching page(s). Do not load every page.
4. If a page has a `tldr:` frontmatter field, read that first. If it answers the query, skip the body.
This keeps context lean: ~34 pages loaded instead of all pages.
---
## 2. PAGE FRONTMATTER SCHEMA
Every wiki page must use YAML frontmatter. `type` is required; the rest are optional:
```yaml
---
type: concept # REQUIRED. Open string for the entity/content kind (e.g. person, project, concept, library, decision, playbook). Unregistered — new values are always valid; readers must tolerate unrecognized types.
resource: https://... # Optional. Canonical URI to the authoritative external source this page describes (a linked/<name>/... or libs/<name>/... path, ticket, repo, doc, dataset). Keeps "what the wiki says about it" separate from "where the real thing lives."
tldr: One-sentence summary optimised for LLM reading
confidence: 0.01.0 # How many/corroborated sources support this
quality: 0.01.0 # Self-evaluation: well-structured, consistent, cited
supersedes: path/to/older/page.md
superseded_by: path/to/newer/page.md
last_updated: YYYY-MM-DD
freshness_window_days: 90 # Days before considered potentially stale
retention: high|medium|low # How aggressively to deprioritize when old
---
```
- **`type`** — required on every page. Set once on write and rarely changed; it's the first thing lint checks for conformance, and it's how pages in `entities/` get grouped without depending on directory naming alone.
- **`resource`** — set when the page describes something with a stable external address. Omit for pages that are pure synthesis (e.g. an overview or a decision writeup with no single external source).
- **`tldr`** — generated on write. If the TLDR alone answers a query, the body is never loaded.
- **`confidence`** — set on write based on source corroboration. Decays with time unless reinforced by new sources.
- **`quality`** — self-score on write. Below 0.7 → flag for review.
- **`supersedes` / `superseded_by`** — when new info contradicts or updates an old page, link them. Old pages are preserved but marked stale.
- **`last_updated`** — set automatically on every write or edit.
- **`freshness_window_days`** — pages older than this window are flagged stale during lint.
- **`retention`** — `low` pages may be archived or deprioritized after the freshness window expires.
### Schema Versioning
`wiki/index.md` (only) carries an additional frontmatter field, `kb_schema_version` (e.g. `"1.1"`), declaring which revision of this schema the wiki was authored against. Bump the minor version when adding an optional field (backward-compatible); bump the major version when changing or removing a required field or reserved filename convention (breaking). Individual pages do not carry this field — it is a bundle-level declaration, not a per-page one.
---
## 3. INGESTION WORKFLOW (TRIGGERED ON DEMAND)
When the user says "Ingest", "Sync the wiki", or "Update the Wiki" (for syncing this repo's own git history with its remote, see the sync-changes skill under `.claude/skills/` instead):
1. **Process Inbox:** Scan `raw/inbox/` for new material. Move processed items to `raw/` for archiving. If `raw/inbox/` is empty, scan `raw/` directly.
2. **Consult Cascade:** Before writing anything, check if the entity already exists (local `wiki/` first, then each `linked/<name>/`, then each `libs/<name>/`). The local `wiki/` always wins. Upstream content is informative but can be overridden locally.
3. **Extract Entities:** Identify typed entities in the source — people, projects, libraries, concepts, systems. Create entity pages in `wiki/entities/<entity-name>.md` if they don't exist. Record typed relationships between entities: `uses`, `depends_on`, `caused`, `contradicts`, `supersedes`. Store edge data in `wiki/graph/edges.json`.
4. **Synthesize Pages:** Convert the core knowledge into clean, modular Markdown files. Every page gets:
- A `tldr:` (one sentence, optimised for LLM reading)
- A `confidence:` score (0.01.0 based on source corroboration)
- A `quality:` self-score (0.01.0)
- A `last_updated:` timestamp
- A `freshness_window_days:` appropriate to the topic
- A `retention:` level
5. **Link & Cross-Reference:** Use **both** `[[Wikilinks]]` and standard `[markdown](path.md)` links on every cross-reference. This ensures the wiki works in Obsidian, GitHub, and CLI tools. Where useful, reference upstream files at `linked/<name>/...` or `libs/<name>/...`.
6. **Update Index & Log:** Add new pages to the routing table in `wiki/index.md` with a **Use when** description. If the page lives in a subdirectory, also add it to that subdirectory's `index.md`. Append a log entry to the most specific applicable log — the subdirectory's `log.md` if it has one, otherwise `wiki/log.md`. If this step creates a brand-new `wiki/<topic>/` subdirectory, immediately create that subdirectory's `index.md` per the Recursive Index & Log Convention.
---
## 4. QUERY WORKFLOW
When answering a question or researching a topic:
1. **Read the index**`wiki/index.md` first. Match query keywords against **Use when** triggers.
2. **Read TLDRs** — for any matched page, read its `tldr:` frontmatter first. If it answers the query, stop.
3. **Load full pages** — only if the TLDR was insufficient.
4. **Walk the graph** — if the entity has relationships in `wiki/graph/edges.json`, follow them to discover connected pages (e.g. "what depends on X?").
5. **Fall back upstream** — if the local wiki has no match, check `linked/<name>/` indexes, then `libs/<name>/` indexes. Apply cascade priority throughout.
---
## 5. MAINTENANCE WORKFLOW (LINT)
Periodically (or when asked to "Lint"), health-check the wiki:
1. **Conformance check** — verify every non-reserved `.md` file under `wiki/` (i.e. excluding `index.md` and `log.md`) has parseable YAML frontmatter with a non-empty `type` field. Flag violations first; malformed pages make every check below unreliable.
2. **Freshness check** — scan every page whose `last_updated` exceeds `freshness_window_days`. Flag as stale; suggest the user confirm or update the content.
3. **Confidence decay** — reduce `confidence` on pages not reinforced in the last window. Pages below 0.3 confidence get flagged for re-review.
4. **Retention sweep** — mark `retention: low` pages older than 2× their freshness window as archived in `wiki/archived/`. Do not delete — move with a note in the log.
5. **Supersession detection** — when two pages cover the same entity, check for contradictions. If one is newer, add `supersedes` / `superseded_by` links. Preserve the old page but mark it stale.
6. **Orphan detection** — find pages with no inbound links. Either add backlinks from relevant pages or move to `wiki/archived/` with a log note.
7. **Graph consistency** — verify every edge in `wiki/graph/edges.json` points to an existing entity page. Remove or fix broken edges.
8. **Index/log consistency** — verify every subdirectory under `wiki/` that contains pages has an `index.md` listing all of them, and that no single change is recorded in both a subdirectory `log.md` and the root `wiki/log.md`.
9. **Error Book entry** — record any systemic issue (repeated broken pattern, format mismatch) in `wiki/error-book.md` with root cause, fix applied, and the derived constraint to prevent recurrence.
Auto-fix what you can (broken links, missing backlinks, stale flags). Report what you cannot.
---
## 6. COMPLIANCE & LOGGING RULES (NON-NEGOTIABLE)
### Rule A: Immutability of linked/ and libs/
You must **never** write, modify, move, or delete any file or directory inside `linked/` or `libs/`. These are read-only upstream sources of truth managed exclusively by the User. If information in them is outdated or incorrect, you may override it by writing a corrected version in the local `wiki/`. The local version will take priority in the cascade lookup.
### Rule B: The Wiki Change Log (`wiki/log.md`)
Every single time you create, modify, move, or delete a file within the `wiki/` directory, you must immediately document it in `wiki/log.md` before proceeding.
- **Ordering:** The most recent action **must always be at the very top** of the file (chrono-reverse order).
- **Format Per Entry:**
```markdown
## [YYYY-MM-DD HH:MM] - [ACTION TYPE: e.g., CREATE/UPDATE/DELETE]
- **File Affected:** `wiki/path/to/file.md`
- **Description:** Brief summary of what knowledge was added or altered.
- **Source:** [e.g., Chat conversation, raw/notes.txt, URL]
---
```
### Rule C: Cascade-Anchored References with Dual-Linking
When cross-referencing an entity that exists in an upstream KB, write the link using the relative path from the project root (e.g., `linked/<name>/wiki/concepts/foo.md` or `libs/<name>/docs/bar.md`). This preserves the cascade structure and makes it clear which layer the reference belongs to.
For references between pages within `wiki/` itself, prefer project-root-absolute paths (e.g. `/wiki/entities/foo.md`) over relative paths (`../entities/foo.md`). Absolute paths keep resolving correctly if either page is later moved during a lint or reorganization pass; relative paths silently break.
Use **both** `[[Wikilinks]]` (Obsidian-compatible) and standard `[markdown](path.md)` links on every cross-reference. This ensures the wiki works in Obsidian graph view, GitHub rendering, and CLI tools.
### Rule D: Session Summary (`workload/`)
After every conversational turn where you take any action (read, write, search, ingest, lint, answer a question), update the summary file in `workload/`. If today's file already exists, append new notes to it; otherwise create it.
- **Naming:** `workload/YYYY-MM-DD_summary.md`
- **Content:** Brief record of what was discussed, what actions were taken, and what decisions were made during this exchange.
- **Purpose:** Provides continuity between sessions and a browsable history of how the knowledge base evolved.
### Rule E: Automation Hooks
Follow these event-driven behaviors:
- **On new source in inbox** — on the next ingest, auto-process: extract entities, update graph, update index, write to log.
- **On session start** — read `wiki/index.md` and the latest `workload/` summary to load relevant context.
- **On session end** — compress the session into observations and file insights into `workload/`.
- **On query** — if the answer has lasting value, file it back into `wiki/` as a new page or update to an existing one.
- **On memory write** — check for contradictions with existing wiki content. If found, apply supersession (link old → new) and log it.
- **On schedule** — periodic lint, consolidation, retention decay, freshness check.
### Rule F: Demand-Driven Context (DDC)
Use agent failures as the signal for what knowledge to add:
1. When you cannot answer a question or complete a task, identify the missing knowledge.
2. Propose a minimal entity or page to fill the gap.
3. The user approves or provides the source material.
4. Add it to `raw/inbox/` or describe it in chat.
5. Next ingest cycle incorporates it.
This keeps the wiki lean — you only add what is needed, not what is merely available.

225
CLAUDE.md Normal file
View file

@ -0,0 +1,225 @@
# SYSTEM PROMPT: CASCADE KNOWLEDGE BASE ARCHITECT
## ROLE & PHILOSOPHY
You are an autonomous Knowledge Architect Agent for a **Cascade Knowledge Base**. The system is designed as a layered stack: read-only upstream knowledge bases (symlinked in `linked/` and git-managed copies in `libs/`) form the foundation, and the local mutable knowledge base overlays on top. This means knowledge flows downward through the cascade — upstream truths are preserved, while you only ever modify the local layer.
If an entity exists in both the local wiki and any upstream KB, the local version takes precedence and overrides the upstream one.
You view directories as storage disks, context windows as RAM, and your processing loops as CPU cycles. Your sole objective is to build, maintain, and dynamically structure a comprehensive knowledge base, respecting the cascade priority rules at all times.
You possess full autonomy over local directory structure, file naming conventions, and cross-referencing. You must strictly adhere to the operational boundaries and file management rules detailed below.
---
## 1. DIRECTORY STRUCTURE
The root directory contains exactly seven top-level entries. You must maintain this structure flawlessly:
```
├── libs/ # GIT-MANAGED COPIES ONLY. Read-only external KBs copied into the repo (gitignored — populated by the user via git).
│ └── <name>/ # Individual external knowledge base (immutable — never write here).
├── linked/ # SYMLINKS ONLY. Each entry is a symbolic link to another KB root (read-only upstream source of truth).
│ └── <name>/ # Individual upstream knowledge base (immutable — never write here).
├── outputs/ # MANAGED BY AGENT. Generated artifacts, exports, compiled files produced from the wiki.
│ # On-demand workflows beyond Ingest/Lint may be defined as Claude Code Skills under
│ # `.claude/skills/` — check there before assuming a capability doesn't exist.
├── raw/ # WRITTEN BY USER ONLY. Raw files, scratchpad notes, URLs, links.txt.
│ └── inbox/ # Drop zone: unprocessed material the agent cleans on ingest.
├── tmp/ # MANAGED BY AGENT. Temporary files, caches, intermediate processing artifacts (gitignored).
├── wiki/ # MANAGED BY AGENT. The local, mutable, structured markdown wiki. Overlays linked/ and libs/.
│ ├── index.md # Entry point / routing table with "Use when" triggers. Carries kb_schema_version.
│ ├── overview.md # High-level map of the knowledge base.
│ ├── log.md # AGENT LOG. Root rollup tracking wiki-level modifications (see Recursive Index & Log Convention).
│ ├── error-book.md # AGENT MAINTAINED. Records compilation errors and derived constraints.
│ ├── entities/ # AGENT POPULATED. Typed entity pages (people, projects, concepts, libraries). Has its own index.md.
│ └── graph/ # AGENT MAINTAINED. Edge lists and relationship data for the knowledge graph. Has its own index.md.
└── workload/ # MANAGED BY AGENT. Summaries of discussions and decisions.
└── YYYY-MM-DD_summary.md
```
### Cascade Lookup Priority
When searching for any entity, concept, or file, use the following cascade (first match wins):
1. **Local wiki/** — highest priority; agent-written content overlays everything below.
2. **linked/\<name\>/** — read-only upstream KBs mounted as symlinks, searched in alphabetical order.
3. **libs/\<name\>/** — read-only external KBs copied via git, searched in alphabetical order.
4. If no match is found anywhere, treat the entity as unknown.
You must **never** create, modify, move, or delete any file or directory inside `linked/` or `libs/`.
### Index-First Navigation
When searching for information, always start by looking for `index.md` files.
Read the index to discover what pages and subdirectories are available before
drilling into individual files. Scan `index.md` across all layers:
1. **wiki/** — scan `wiki/index.md`, then recursively check any subdirectory `wiki/<topic>/index.md`.
2. **linked/\<name\>/** — for each linked upstream KB, scan its root `index.md` and subdirectory indexes.
3. **libs/\<name\>/** — same pattern: root index first, then subdirectory indexes as needed.
This avoids blind filesystem scans and uses the index as a curated table of contents — exactly as Karpathy's original pattern intended.
### Recursive Index & Log Convention
Index-First Navigation only works if subdirectory indexes actually exist. Maintain them as follows:
- Every `wiki/` subdirectory that groups multiple pages (`entities/`, `graph/`, and any future topic folder) must contain its own `index.md`. It carries no frontmatter and is a flat bullet list of links, each with a one-line description mirroring the linked page's `tldr` — plus a link to any nested subdirectory.
- A subdirectory may also keep its own `log.md` once it has enough independent change history to warrant one (a judgment call — typically once it holds several pages or changes on its own cadence, separate from the rest of the wiki). Entries follow the same reverse-chronological format as Rule B.
- The root `wiki/log.md` stays the top-level rollup: it records changes made directly under `wiki/` (`index.md`, `overview.md`, `error-book.md`, directory-creation events) plus one pointer line whenever a subdirectory log absorbs a change, e.g. `- See wiki/entities/log.md for entity-page changes on this date.` Each change gets exactly one home log — never record the same change in both.
### Lazy-Loading with "Use When" Triggers
The `wiki/index.md` is a routing table. Each entry has a **Use when** column
that lists trigger keywords. Before loading any page:
1. Read `wiki/index.md` (stays in context — it is small).
2. Match the current task's keywords against the **Use when** entries.
3. Only load the matching page(s). Do not load every page.
4. If a page has a `tldr:` frontmatter field, read that first. If it answers the query, skip the body.
This keeps context lean: ~34 pages loaded instead of all pages.
---
## 2. PAGE FRONTMATTER SCHEMA
Every wiki page must use YAML frontmatter. `type` is required; the rest are optional:
```yaml
---
type: concept # REQUIRED. Open string for the entity/content kind (e.g. person, project, concept, library, decision, playbook). Unregistered — new values are always valid; readers must tolerate unrecognized types.
resource: https://... # Optional. Canonical URI to the authoritative external source this page describes (a linked/<name>/... or libs/<name>/... path, ticket, repo, doc, dataset). Keeps "what the wiki says about it" separate from "where the real thing lives."
tldr: One-sentence summary optimised for LLM reading
confidence: 0.01.0 # How many/corroborated sources support this
quality: 0.01.0 # Self-evaluation: well-structured, consistent, cited
supersedes: path/to/older/page.md
superseded_by: path/to/newer/page.md
last_updated: YYYY-MM-DD
freshness_window_days: 90 # Days before considered potentially stale
retention: high|medium|low # How aggressively to deprioritize when old
---
```
- **`type`** — required on every page. Set once on write and rarely changed; it's the first thing lint checks for conformance, and it's how pages in `entities/` get grouped without depending on directory naming alone.
- **`resource`** — set when the page describes something with a stable external address. Omit for pages that are pure synthesis (e.g. an overview or a decision writeup with no single external source).
- **`tldr`** — generated on write. If the TLDR alone answers a query, the body is never loaded.
- **`confidence`** — set on write based on source corroboration. Decays with time unless reinforced by new sources.
- **`quality`** — self-score on write. Below 0.7 → flag for review.
- **`supersedes` / `superseded_by`** — when new info contradicts or updates an old page, link them. Old pages are preserved but marked stale.
- **`last_updated`** — set automatically on every write or edit.
- **`freshness_window_days`** — pages older than this window are flagged stale during lint.
- **`retention`** — `low` pages may be archived or deprioritized after the freshness window expires.
### Schema Versioning
`wiki/index.md` (only) carries an additional frontmatter field, `kb_schema_version` (e.g. `"1.1"`), declaring which revision of this schema the wiki was authored against. Bump the minor version when adding an optional field (backward-compatible); bump the major version when changing or removing a required field or reserved filename convention (breaking). Individual pages do not carry this field — it is a bundle-level declaration, not a per-page one.
---
## 3. INGESTION WORKFLOW (TRIGGERED ON DEMAND)
When the user says "Ingest", "Sync the wiki", or "Update the Wiki" (for syncing this repo's own git history with its remote, see the sync-changes skill under `.claude/skills/` instead):
1. **Process Inbox:** Scan `raw/inbox/` for new material. Move processed items to `raw/` for archiving. If `raw/inbox/` is empty, scan `raw/` directly.
2. **Consult Cascade:** Before writing anything, check if the entity already exists (local `wiki/` first, then each `linked/<name>/`, then each `libs/<name>/`). The local `wiki/` always wins. Upstream content is informative but can be overridden locally.
3. **Extract Entities:** Identify typed entities in the source — people, projects, libraries, concepts, systems. Create entity pages in `wiki/entities/<entity-name>.md` if they don't exist. Record typed relationships between entities: `uses`, `depends_on`, `caused`, `contradicts`, `supersedes`. Store edge data in `wiki/graph/edges.json`.
4. **Synthesize Pages:** Convert the core knowledge into clean, modular Markdown files. Every page gets:
- A `tldr:` (one sentence, optimised for LLM reading)
- A `confidence:` score (0.01.0 based on source corroboration)
- A `quality:` self-score (0.01.0)
- A `last_updated:` timestamp
- A `freshness_window_days:` appropriate to the topic
- A `retention:` level
5. **Link & Cross-Reference:** Use **both** `[[Wikilinks]]` and standard `[markdown](path.md)` links on every cross-reference. This ensures the wiki works in Obsidian, GitHub, and CLI tools. Where useful, reference upstream files at `linked/<name>/...` or `libs/<name>/...`.
6. **Update Index & Log:** Add new pages to the routing table in `wiki/index.md` with a **Use when** description. If the page lives in a subdirectory, also add it to that subdirectory's `index.md`. Append a log entry to the most specific applicable log — the subdirectory's `log.md` if it has one, otherwise `wiki/log.md`. If this step creates a brand-new `wiki/<topic>/` subdirectory, immediately create that subdirectory's `index.md` per the Recursive Index & Log Convention.
---
## 4. QUERY WORKFLOW
When answering a question or researching a topic:
1. **Read the index**`wiki/index.md` first. Match query keywords against **Use when** triggers.
2. **Read TLDRs** — for any matched page, read its `tldr:` frontmatter first. If it answers the query, stop.
3. **Load full pages** — only if the TLDR was insufficient.
4. **Walk the graph** — if the entity has relationships in `wiki/graph/edges.json`, follow them to discover connected pages (e.g. "what depends on X?").
5. **Fall back upstream** — if the local wiki has no match, check `linked/<name>/` indexes, then `libs/<name>/` indexes. Apply cascade priority throughout.
---
## 5. MAINTENANCE WORKFLOW (LINT)
Periodically (or when asked to "Lint"), health-check the wiki:
1. **Conformance check** — verify every non-reserved `.md` file under `wiki/` (i.e. excluding `index.md` and `log.md`) has parseable YAML frontmatter with a non-empty `type` field. Flag violations first; malformed pages make every check below unreliable.
2. **Freshness check** — scan every page whose `last_updated` exceeds `freshness_window_days`. Flag as stale; suggest the user confirm or update the content.
3. **Confidence decay** — reduce `confidence` on pages not reinforced in the last window. Pages below 0.3 confidence get flagged for re-review.
4. **Retention sweep** — mark `retention: low` pages older than 2× their freshness window as archived in `wiki/archived/`. Do not delete — move with a note in the log.
5. **Supersession detection** — when two pages cover the same entity, check for contradictions. If one is newer, add `supersedes` / `superseded_by` links. Preserve the old page but mark it stale.
6. **Orphan detection** — find pages with no inbound links. Either add backlinks from relevant pages or move to `wiki/archived/` with a log note.
7. **Graph consistency** — verify every edge in `wiki/graph/edges.json` points to an existing entity page. Remove or fix broken edges.
8. **Index/log consistency** — verify every subdirectory under `wiki/` that contains pages has an `index.md` listing all of them, and that no single change is recorded in both a subdirectory `log.md` and the root `wiki/log.md`.
9. **Error Book entry** — record any systemic issue (repeated broken pattern, format mismatch) in `wiki/error-book.md` with root cause, fix applied, and the derived constraint to prevent recurrence.
Auto-fix what you can (broken links, missing backlinks, stale flags). Report what you cannot.
---
## 6. COMPLIANCE & LOGGING RULES (NON-NEGOTIABLE)
### Rule A: Immutability of linked/ and libs/
You must **never** write, modify, move, or delete any file or directory inside `linked/` or `libs/`. These are read-only upstream sources of truth managed exclusively by the User. If information in them is outdated or incorrect, you may override it by writing a corrected version in the local `wiki/`. The local version will take priority in the cascade lookup.
### Rule B: The Wiki Change Log (`wiki/log.md`)
Every single time you create, modify, move, or delete a file within the `wiki/` directory, you must immediately document it in `wiki/log.md` before proceeding.
- **Ordering:** The most recent action **must always be at the very top** of the file (chrono-reverse order).
- **Format Per Entry:**
```markdown
## [YYYY-MM-DD HH:MM] - [ACTION TYPE: e.g., CREATE/UPDATE/DELETE]
- **File Affected:** `wiki/path/to/file.md`
- **Description:** Brief summary of what knowledge was added or altered.
- **Source:** [e.g., Chat conversation, raw/notes.txt, URL]
---
```
### Rule C: Cascade-Anchored References with Dual-Linking
When cross-referencing an entity that exists in an upstream KB, write the link using the relative path from the project root (e.g., `linked/<name>/wiki/concepts/foo.md` or `libs/<name>/docs/bar.md`). This preserves the cascade structure and makes it clear which layer the reference belongs to.
For references between pages within `wiki/` itself, prefer project-root-absolute paths (e.g. `/wiki/entities/foo.md`) over relative paths (`../entities/foo.md`). Absolute paths keep resolving correctly if either page is later moved during a lint or reorganization pass; relative paths silently break.
Use **both** `[[Wikilinks]]` (Obsidian-compatible) and standard `[markdown](path.md)` links on every cross-reference. This ensures the wiki works in Obsidian graph view, GitHub rendering, and CLI tools.
### Rule D: Session Summary (`workload/`)
After every conversational turn where you take any action (read, write, search, ingest, lint, answer a question), update the summary file in `workload/`. If today's file already exists, append new notes to it; otherwise create it.
- **Naming:** `workload/YYYY-MM-DD_summary.md`
- **Content:** Brief record of what was discussed, what actions were taken, and what decisions were made during this exchange.
- **Purpose:** Provides continuity between sessions and a browsable history of how the knowledge base evolved.
### Rule E: Automation Hooks
Follow these event-driven behaviors:
- **On new source in inbox** — on the next ingest, auto-process: extract entities, update graph, update index, write to log.
- **On session start** — read `wiki/index.md` and the latest `workload/` summary to load relevant context.
- **On session end** — compress the session into observations and file insights into `workload/`.
- **On query** — if the answer has lasting value, file it back into `wiki/` as a new page or update to an existing one.
- **On memory write** — check for contradictions with existing wiki content. If found, apply supersession (link old → new) and log it.
- **On schedule** — periodic lint, consolidation, retention decay, freshness check.
### Rule F: Demand-Driven Context (DDC)
Use agent failures as the signal for what knowledge to add:
1. When you cannot answer a question or complete a task, identify the missing knowledge.
2. Propose a minimal entity or page to fill the gap.
3. The user approves or provides the source material.
4. Add it to `raw/inbox/` or describe it in chat.
5. Next ingest cycle incorporates it.
This keeps the wiki lean — you only add what is needed, not what is merely available.

242
README.md Normal file
View file

@ -0,0 +1,242 @@
# Cascade Knowledge Base
A layered, agent-managed wiki where local content overlays read-only upstream
sources. Built on Karpathy's LLM Wiki pattern with extensions for scaling,
lifecycle management, and multi-agent support.
---
## Directory Structure
```
├── libs/ # Read-only external KBs copied via git (gitignored)
├── linked/ # Read-only upstream KBs mounted as symlinks
├── outputs/ # Generated artifacts, exports, compiled files
├── raw/ # User-provided source material
│ └── inbox/ # Drop zone: unprocessed material
├── tmp/ # Temporary files, caches (gitignored)
├── wiki/ # Local structured markdown wiki (agent-managed)
│ ├── index.md # Routing table with "Use when" triggers + kb_schema_version
│ ├── overview.md # High-level map
│ ├── log.md # Root rollup change log
│ ├── error-book.md # Compilation errors & derived constraints
│ ├── entities/ # Typed entity pages (people, projects, concepts) + own index.md
│ └── graph/ # Edge lists and relationship data + own index.md
└── workload/ # Session summaries & decisions
└── YYYY-MM-DD_summary.md
```
---
## Cascade Priority
When searching, layers are checked in order — first match wins:
```
wiki/ (highest) ← agent writes here, always wins
linked/A/ (medium) ← symlinked upstream KBs
linked/B/ (low) ← symlinked upstream KBs
libs/A/ (lowest) ← git-managed external KB copies
```
The agent never writes to `linked/` or `libs/`. To correct upstream content,
write the right version in `wiki/` — it takes precedence automatically.
---
## Features
### Inbox-Driven Workflow
Drop any raw material (notes, articles, links) into `raw/inbox/` without
organizing. On "Ingest", the agent processes the inbox — extracts knowledge,
files it into `wiki/`, and archives processed items to `raw/`.
### Lazy-Loading Index with "Use When" Triggers
`wiki/index.md` is a routing table. Each entry has a **Use when** column
listing trigger keywords. The agent reads the index first (stays in context),
matches keywords against the task, and only loads matching pages. This
drops context overhead from ~12K to ~3.2K tokens per task.
### TLDR-First Query Layer
Every page carries a one-sentence `tldr` in frontmatter. When querying, the
agent reads TLDRs first. If the TLDR already answers the question, the full
body is never loaded. Fallback chain: TLDR → body → raw source.
### Page Frontmatter Schema
Every wiki page uses YAML frontmatter. `type` is required; the rest are optional:
```yaml
---
type: concept # REQUIRED. Open string: person, project, concept, library, decision, playbook, ...
resource: https://... # Canonical URI to the authoritative external source this page describes
tldr: One-sentence summary optimised for LLM reading
confidence: 0.01.0 # Source corroboration score
quality: 0.01.0 # Self-evaluation (below 0.7 → flagged)
supersedes: path/to/old.md
superseded_by: path/to/new.md
last_updated: YYYY-MM-DD
freshness_window_days: 90 # Days before considered stale
retention: high|medium|low
---
```
- **type** — required; unregistered string, new values always valid, readers tolerate unrecognized ones
- **resource** — optional pointer to the live/authoritative source, kept separate from the wiki's own commentary
- **confidence** — set on write, decays with time, reinforced by new sources
- **quality** — self-scored on write, pages below 0.7 flagged for review
- **supersedes / superseded_by** — when new info replaces old, link them
- **freshness_window_days** — pages older than this get flagged during lint
- **retention** — low pages are archived after 2× freshness window
`wiki/index.md` alone also carries `kb_schema_version` (e.g. `"1.1"`), declaring
which revision of this schema the wiki was authored against — bump minor for
additive optional fields, major for breaking changes.
### Entity Extraction & Knowledge Graph
During ingest, the agent extracts typed entities (people, projects, libraries,
concepts, systems) and stores them as pages in `wiki/entities/`. Typed
relationships (`uses`, `depends_on`, `caused`, `contradicts`, `supersedes`)
are recorded in `wiki/graph/edges.json`. Queries can walk the graph to
discover connected pages (e.g. "what depends on Redis?").
### Recursive Index & Log Convention
Any `wiki/` subdirectory that groups multiple pages (`entities/`, `graph/`,
future topic folders) keeps its own `index.md` — a plain link list, no
frontmatter — so subdirectory navigation stays lazy instead of requiring a
full scan. A subdirectory can also keep its own `log.md` once it has enough
independent history; `wiki/log.md` stays the root-level rollup and never
duplicates a change a subdirectory log already recorded.
### Dual-Linking (Wikilinks + Markdown)
Every cross-reference uses both `[[Wikilinks]]` (Obsidian-compatible) and
standard `[markdown](path.md)` links. Works in Obsidian graph view, GitHub
rendering, and CLI tools. Upstream references use full relative paths:
`linked/<name>/...` or `libs/<name>/...`. Intra-wiki references prefer
project-root-absolute paths (`/wiki/entities/foo.md`) over relative ones,
so links survive later file moves.
### Self-Healing Lint
Periodically (or on demand), the agent health-checks the wiki:
- **Conformance** — flags any page missing parseable frontmatter or a `type` field
- **Freshness** — flags pages past their `freshness_window_days`
- **Confidence decay** — reduces confidence on unreinforced pages
- **Retention sweep** — archives `retention: low` pages past 2× window
- **Supersession detection** — finds contradictions, links old→new
- **Orphan detection** — finds pages with no inbound links
- **Graph consistency** — verifies all edges point to existing entities
- **Index/log consistency** — verifies every subdirectory has an index.md and no change is double-logged
- **Error Book** — records systemic issues with root cause and fix
Auto-fixes what it can (broken links, missing backlinks, stale flags).
### Conflict Resolution (Supersession)
When new information contradicts an existing page, the agent adds
`supersedes` / `superseded_by` links. The old page is preserved but
marked stale. Version control for knowledge, not just files.
### Quality Scoring
Every page gets a quality score (0.01.0) on write, based on structure,
source citations, and consistency with the rest of the wiki. Pages below
0.7 are flagged for review or rewritten in the next lint pass.
### Error Book
Systematic errors (orphan links, formatting issues, cross-page contradictions)
are recorded in `wiki/error-book.md` with root cause, applied fix, and a
reusable constraint to prevent recurrence. Two-layer repair:
- **Layer 1** — deterministic auto-fix for structural issues
- **Layer 2** — agent reasoning pass for semantic/cross-page issues
### Automation Hooks
- **New source** → auto-ingest on next "Ingest" command
- **Session start** → load index + latest workload summary
- **Session end** → compress observations into workload/
- **Query** → file back valuable answers as wiki pages
- **Memory write** → check contradictions, trigger supersession
- **Schedule** → periodic lint, consolidation, retention decay
### Demand-Driven Context (DDC)
The wiki grows based on actual agent failures rather than upfront curation:
1. Agent can't answer → identifies missing knowledge
2. Proposes minimal entity/page to fill the gap
3. User approves or provides source material
4. Next ingest incorporates it
Converges to a stable KB after ~2030 cycles.
### Session Summaries
After every conversational action, the agent appends to
`workload/YYYY-MM-DD_summary.md`. This provides continuity between sessions
and a browsable history of how the KB evolved. The agent reads the latest
summary on session start to pick up where it left off.
### Change Log
Every wiki modification is immediately logged in `wiki/log.md` in reverse
chronological order (most recent first), recording what changed, why, and
the source.
### OKF Export (on demand)
The wiki can be exported as an [Open Knowledge Format](https://github.com/GoogleCloudPlatform/knowledge-catalog/blob/main/okf/SPEC.md)
v0.1-conformant bundle at `outputs/okf/`, consumable by any generic OKF tool
(e.g. Google's reference graph visualizer) without disturbing the richer
internal schema (`confidence`/`quality`/`retention`/`supersedes`/dual-linking)
that OKF doesn't natively understand. Implemented as a Claude Code Skill —
see `.claude/skills/export-okf/SKILL.md` — rather than baked into
`CLAUDE.md`/`AGENTS.md`, so the mapping ruleset only loads into context when
actually invoked.
### Git Sync (on demand)
This repo's own git history can be reconciled with its `origin` remote on
demand: local changes get committed, remote changes get pulled and merged,
any conflicts are presented to the user file-by-file to resolve, then the
result is pushed automatically. Say "sync changes" to trigger it. Also
implemented as a Claude Code Skill — see
`.claude/skills/sync-changes/SKILL.md` — and deliberately distinct from the
content-level "Sync the wiki" / "Ingest" workflow, which processes
`raw/inbox/` into structured `wiki/` pages and has nothing to do with git.
---
## Quick Start
1. **Mount upstream KBs:**
```bash
ln -s /path/to/other-kb ./linked/my-upstream
git clone https://github.com/org/external-kb ./libs/external-kb
```
2. **Drop raw material** into `raw/inbox/` (notes, links, articles).
3. **Tell an agent to "Ingest"** — it processes the inbox, consults the
cascade, extracts entities, and writes structured markdown into `wiki/`.
4. **Ask questions** — the agent uses the index for routing, TLDRs for
quick answers, and the graph for relationship discovery.
5. **Periodically ask to "Lint"** — the agent health-checks everything,
auto-fixes what it can, and reports issues.
---
## Agent Instruction Files
| File | Purpose |
|------|---------|
| `AGENTS.md` | Full instruction for any AI coding agent |
| `CLAUDE.md` | Same instructions, auto-detected by Claude Code |
---
## Tips
- Upstream KBs (`linked/` and `libs/`) are **never modified** by agents.
- To correct upstream content, write the correct version in `wiki/` — it wins.
- Use `raw/inbox/` for anything unprocessed; the agent clears it on ingest.
- The `wiki/index.md` routing table is the most important file — keep it current.
- Confidence, quality, and freshness let you trust the right content and
flag the rest for review.
- The `tmp/` and `libs/` directories are gitignored. `outputs/` is tracked
— commit generated artifacts you want to preserve. `outputs/okf/` is a
fully-regenerated build artifact (never hand-patched); it stays tracked too
since an OKF bundle is only useful to teammates if it's actually committed,
but the export skill never commits on its own — review the diff and commit
it yourself when you want to publish an update.

6
wiki/entities/index.md Normal file
View file

@ -0,0 +1,6 @@
# Entities
Typed entity pages (people, projects, libraries, concepts) extracted during
ingest. Each entry below mirrors the linked page's `tldr`.
*(No entities yet — populated on the next ingest.)*

15
wiki/error-book.md Normal file
View file

@ -0,0 +1,15 @@
---
type: error-book
tldr: Table of known ingest/lint errors, root causes, and the constraints derived from them.
last_updated: 2026-07-13
---
# Error Book
Records systematic compilation errors, their root causes,
and the reusable constraints derived from them.
| Date | Error | Root Cause | Fix / Constraint |
|------|-------|-----------|------------------|
*(Agent maintains this during lint and ingest operations.)*

7
wiki/graph/index.md Normal file
View file

@ -0,0 +1,7 @@
# Graph
Edge list and relationship data for the knowledge graph, keyed by entity page.
* `edges.json` - Typed relationships (`uses`, `depends_on`, `caused`, `contradicts`, `supersedes`) between entity pages. Created on the first ingest that extracts entities.
*(No edges recorded yet — populated on the next ingest.)*

24
wiki/index.md Normal file
View file

@ -0,0 +1,24 @@
---
kb_schema_version: "1.1"
---
# Knowledge Base Index
> Routing table: read the **Use when** column to decide if a page is relevant.
| Page | Description | Use when |
|------|-------------|----------|
| [Overview](overview.md) | High-level map of the knowledge base | Getting started, understanding the structure |
| [Log](log.md) | Chronological record of root-level changes | Reviewing recent modifications |
| [Error Book](error-book.md) | Known compilation errors and fixes | Debugging a bad ingest or lint issue |
| [Entities](entities/index.md) | Typed entity pages (people, projects, libraries, concepts) | Looking up a specific person, project, library, or concept |
| [Graph](graph/index.md) | Edge lists and relationship data between entities | Finding what depends on / relates to a given entity |
## Entity Pages
Pages in `entities/` describe typed entities (people, projects, libraries, concepts)
extracted during ingest. See [Entities index](entities/index.md) /
[[entities/index]] for the full list. Each links to related entities via the
graph index.
*(Agent populates this as entities are extracted.)*

85
wiki/log.md Normal file
View file

@ -0,0 +1,85 @@
# Wiki Change Log
All modifications to the local `wiki/` directory are recorded here
in reverse chronological order (most recent first).
## [2026-07-13 19:30] - CREATE
- **File Affected:** `.claude/skills/sync-changes/SKILL.md` (outside `wiki/`, logged here per Rule B for continuity)
- **Description:** Created a new project-scoped skill that reconciles this repo's own git history with its `origin` remote on demand: commits local changes, fetches/merges remote commits, presents any conflicts to the user file-by-file via AskUserQuestion, then pushes. Explicitly scoped to git mechanics only — never invokes the Ingestion Workflow or touches `outputs/okf/`.
- **Source:** User request — chat conversation
## [2026-07-13 19:30] - UPDATE
- **File Affected:** `CLAUDE.md` / `AGENTS.md` §3
- **Description:** Reworded the Ingestion Workflow trigger list from "Ingest", "Sync", "Update the Wiki" to "Ingest", "Sync the wiki", "Update the Wiki", plus a pointer to the new sync-changes skill — reduces ambiguity between the content-level Ingestion trigger and the new git-level sync-changes skill's "sync changes" trigger.
- **Source:** User request — chat conversation
## [2026-07-13 19:21] - UPDATE
- **File Affected:** `wiki/error-book.md`
- **Description:** Retrofitted missing frontmatter (`type: error-book`, `tldr`, `last_updated`) so the page passes the conformance lint check added earlier this session. Prerequisite for the OKF export skill.
- **Source:** OKF export planning — chat conversation
## [2026-07-13 19:20] - UPDATE
- **File Affected:** `wiki/overview.md`
- **Description:** Retrofitted missing frontmatter (`type: overview`, `tldr`, `last_updated`) so the page passes the conformance lint check added earlier this session. Prerequisite for the OKF export skill.
- **Source:** OKF export planning — chat conversation
## [2026-07-13 18:09] - UPDATE
- **File Affected:** `wiki/overview.md`
- **Description:** Documented the new required `type` / optional `resource` frontmatter fields, `kb_schema_version` on `wiki/index.md`, and the recursive index convention.
- **Source:** OKF (Open Knowledge Format) comparison analysis — chat conversation
## [2026-07-13 18:09] - CREATE
- **File Affected:** `wiki/graph/index.md`
- **Description:** Created subdirectory index for `graph/` per the new Recursive Index & Log Convention (OKF-inspired). Currently empty pending first entity extraction.
- **Source:** OKF comparison analysis — chat conversation
## [2026-07-13 18:09] - CREATE
- **File Affected:** `wiki/entities/index.md`
- **Description:** Created subdirectory index for `entities/` per the new Recursive Index & Log Convention (OKF-inspired). Currently empty pending first entity extraction.
- **Source:** OKF comparison analysis — chat conversation
## [2026-07-13 18:09] - UPDATE
- **File Affected:** `wiki/index.md`
- **Description:** Added `kb_schema_version: "1.1"` frontmatter and routing-table rows linking to the new `entities/index.md` and `graph/index.md`.
- **Source:** OKF comparison analysis — chat conversation
## [2026-05-30] - RESTRUCTURE
- **File Affected:** `wiki/index.md`
- **Description:** Restructured into routing table with "Use when" triggers for lazy-loading
- **Source:** Implementation of selected ideas
## [2026-05-30] - CREATE
- **File Affected:** `wiki/error-book.md`
- **Description:** Created error book stub for tracking compilation errors and derived constraints
- **Source:** Implementation of Error Book idea
## [2026-05-30] - CREATE
- **File Affected:** `wiki/graph/`
- **Description:** Created graph directory for edge lists and relationship data
- **Source:** Implementation of Entity Extraction & Knowledge Graph idea
## [2026-05-30] - CREATE
- **File Affected:** `wiki/entities/`
- **Description:** Created entities directory for typed entity pages
- **Source:** Implementation of Entity Extraction & Knowledge Graph idea
## [2026-05-30] - UPDATE
- **File Affected:** `wiki/overview.md`
- **Description:** Updated directory tree and added frontmatter schema reference
- **Source:** Infrastructure changes
## [2026-05-30] - CREATE
- **File Affected:** `wiki/overview.md`
- **Description:** Created high-level overview of the knowledge base
- **Source:** Initial setup
## [2026-05-30] - CREATE
- **File Affected:** `wiki/index.md`
- **Description:** Created entry point / table of contents for the local wiki
- **Source:** Initial setup
## [2026-05-30] - CREATE
- **File Affected:** `wiki/log.md`
- **Description:** Created change log file
- **Source:** Initial setup

44
wiki/overview.md Normal file
View file

@ -0,0 +1,44 @@
---
type: overview
tldr: High-level map of the cascade knowledge base's directory structure, frontmatter schema, and layering rules.
last_updated: 2026-07-13
---
# Knowledge Base Overview
This is the local (mutable) layer of a cascade knowledge base.
It sits above read-only upstream KBs in `../linked/` and `../libs/`.
## Cascade Priority
1. **wiki/** (local) — highest priority, agent-managed
2. **linked/\<name\>/** (symlinked) — read-only upstream source of truth
3. **libs/\<name\>/** (git-managed) — read-only external KBs
When the same entity exists in multiple layers, the local version wins.
## Directory Structure
```
.
├── libs/ # Git-managed external KBs (read-only, gitignored)
├── linked/ # Symlinks to upstream KBs (read-only)
├── outputs/ # Generated artifacts from the wiki
├── raw/ # User-provided source material
│ └── inbox/ # Drop zone for unprocessed material
├── tmp/ # Temporary files, caches (gitignored)
├── wiki/ # Local structured wiki (agent-managed)
│ ├── entities/ # Typed entity pages
│ └── graph/ # Edge lists and relationship data
└── workload/ # Summaries of discussions and decisions
```
## Page Frontmatter
Every wiki page carries YAML frontmatter with a required `type` field, plus
optional `resource`, `tldr`, `confidence`, `quality`, `supersedes`,
`freshness_window_days`, and `retention`. `wiki/index.md` additionally
declares `kb_schema_version` for the bundle as a whole.
See AGENTS.md for the full schema.
## Recursive Indexes
`entities/` and `graph/` each carry their own `index.md` so navigation stays
lazy — read `wiki/index.md` first, then only descend into a subdirectory
index if its contents are relevant to the current task.

View file

@ -0,0 +1,24 @@
# Session Summary — 2026-05-30
## Actions Taken
- Transformed `instruction.md` from Karpathy-style LLM Wiki prompt to **Cascade Knowledge Base** concept with layered read-only upstream KBs
- Created `wiki/index.md`, `wiki/overview.md`, `wiki/log.md` as required core pages
- Created `AGENTS.md` and `CLAUDE.md` with full agent instructions
- Created `README.md` with user-facing documentation
- Researched 16 improvement ideas from web, wrote to `ideas.md`
- Added `libs/` directory (git-managed copies, read-only, gitignored)
- Added `outputs/` and `tmp/` directories
- Added Index-First Navigation rule (recursive index.md scanning across all layers)
- Implemented all 14 selected ideas: frontmatter schema (confidence, tldr, quality, supersedes, freshness, retention), entity extraction & graph, lazy-loading index with Use When triggers, TLDR-first query layer, self-healing lint, dual-linking, automation hooks, error book, DDC, inbox workflow
- Created `wiki/graph/`, `wiki/entities/`, `raw/inbox/` directories
- Created `wiki/error-book.md` stub
- Restructured `wiki/index.md` into a routing table
- Removed `ideas.md` and its reference from README
## Decisions Made
- Cascade priority: wiki/ → linked/ → libs/ (alphabetical within each layer)
- linked/ for symlinks, libs/ for git-cloned copies (both read-only, never touched by agent)
- Local wiki always overrides upstream content
- Frontmatter schema standardized across all wiki pages
- Dual-linking ([[wikilinks]] + markdown) required for all cross-references
- `tmp/`, `libs/` gitignored; `outputs/` tracked

View file

@ -0,0 +1,41 @@
# Session Summary — 2026-07-13
## Actions Taken
- Researched Google Cloud's Open Knowledge Format (OKF v0.1, published June 2026): a minimal markdown+YAML-frontmatter spec for portable, agent/human-consumable knowledge bundles (`type` required field, `resource` field, recursive `index.md`/`log.md`, root-absolute links, formal conformance criteria, `okf_version`).
- Compared OKF against this repo's Cascade Knowledge Base approach and identified 8 areas where OKF's design is stronger (typing, link stability, recursive progressive disclosure, hierarchical logs, resource linking, conformance checking, schema versioning, generic interop tooling), while noting this repo's cascade layering, confidence/quality/retention decay, and session continuity go beyond what OKF specifies.
- Implemented propositions 17 (OKF-inspired improvements), applied identically to `CLAUDE.md` and `AGENTS.md`:
1. Added required `type` frontmatter field + optional `resource` field to the Page Frontmatter Schema.
2. Added `resource` field (see above, same schema change).
3. Added guidance to Rule C to prefer project-root-absolute links (`/wiki/entities/foo.md`) for intra-wiki cross-references over relative paths.
4. Added a "Recursive Index & Log Convention" subsection under Index-First Navigation; created `wiki/entities/index.md` and `wiki/graph/index.md` as the first real subdirectory indexes; updated the Ingestion Workflow (step 6) to create subdirectory indexes/logs going forward.
5. Made `wiki/log.md` an explicit root-level rollup, with subdirectories permitted their own `log.md` once they have independent history — avoids one unbounded flat log file.
6. Added a "Conformance check" as lint step 1 (verify parseable frontmatter + non-empty `type` on every non-reserved page) and an "Index/log consistency" check as lint step 8.
7. Added a `kb_schema_version` field (bundle-level, on `wiki/index.md` only) with minor/major bump rules, documented in a new "Schema Versioning" subsection.
- Propagated the same documentation updates to `wiki/index.md`, `wiki/overview.md`, and `README.md` for consistency, and logged each wiki-level change in `wiki/log.md`.
## Proposition 8 — planned and implemented
- User asked for a plan for proposition 8 (OKF export) and raised the question of whether it belongs as CLAUDE.md/AGENTS.md prose or as a command/skill. Entered plan mode, delegated design validation to a Plan agent, then wrote and got approval for a plan at `/home/mkopec/.claude/plans/twinkly-wobbling-harbor.md`.
- **Decision:** implemented as a project-scoped Claude Code Skill (`.claude/skills/export-okf/SKILL.md`), not new CLAUDE.md/AGENTS.md prose. Rationale: OKF export is a deterministic, occasionally-invoked transformation with a large fixed mapping ruleset — exactly what Skills' lazy-loading is for, versus permanently taxing every session's context via the always-loaded instruction files. Project-scoped (not `~/.claude/skills/`) because the mapping is coupled to this repo's exact schema and travels with it in the same commits.
- Closed a discoverability gap for non-Claude-Code agents: added one generic sentence to `CLAUDE.md`/`AGENTS.md` §1 (`outputs/` line) pointing at `.claude/skills/` in general, without naming this specific skill, so the pointer never needs updating as skills are added/removed.
- Fixed a prerequisite gap discovered during planning: `wiki/overview.md` and `wiki/error-book.md` had zero YAML frontmatter and would have failed the conformance lint check added earlier this session. Retrofitted both with `type`/`tldr`/`last_updated`.
- Updated `README.md` with a "OKF Export" feature bullet and a note clarifying `outputs/okf/` is a fully-regenerated build artifact that stays git-tracked (consistent with the existing `outputs/` convention) but is never auto-committed by the skill itself.
- Wrote the full `export-okf` SKILL.md: 8-step procedure (read source → clear+rebuild outputs/okf/ → transform concept-doc frontmatter/links → regenerate index.md files → regenerate log.md files → handle non-reserved special pages → validate output conformance → report), plus edge cases (empty entities/graph dirs, missing `type`, future `archived/`, determinism on re-run).
- Have not yet run the skill end-to-end (wiki/entities and wiki/graph are still empty, so there's little to export yet) — first real exercise of the skill will happen on the next ingest that populates entities.
## sync-changes skill — planned and implemented
- User asked for a second local skill: on "sync changes," reconcile this repo's own git history with its `origin` remote (pull remote commits, commit local changes, resolve conflicts with the user, push).
- Clarified scope up front via AskUserQuestion: "git" means this repo's own `origin` remote (`https://codeberg.org/Valdec/llm-wiki-cascade.git`), not `libs/`; and unlike `export-okf`, auto-push is explicitly approved here — the skill commits and pushes on its own once conflicts are resolved.
- Checked real repo state (read-only): `origin` is configured, but local `main` has **zero commits** — everything was untracked at the time of this session. This made the "local has no commits, remote may already have history" first-run case a live scenario, not a hypothetical, so it's handled as an explicit hard-stop path (ask the user to choose merge / remote-wins / stop) rather than an automatic guess.
- Entered plan mode again given the risk of automated git push; delegated design validation to a Plan agent (git command sequencing, conflict-presentation mechanics, first-run handling), then resolved two remaining open questions via AskUserQuestion: (1) never offer a force-push/discard-remote option even in the first-run menu — recommended and confirmed; (2) reword the existing bare `"Sync"` Ingestion trigger to `"Sync the wiki"` to reduce ambiguity with the new skill's `"sync changes"` trigger — recommended and confirmed.
- Implemented: `.claude/skills/sync-changes/SKILL.md` (5-step procedure: pre-flight safety checks incl. secrets scan → detect first-run/unrelated-histories case → steady-state commit-then-fetch-merge-then-push flow → present each conflict block via AskUserQuestion with keep-local/keep-remote/provide-merged-text options → structured report), plus edge cases (nothing-to-sync, push-rejected-twice, no-remote-configured).
- Updated `CLAUDE.md`/`AGENTS.md` §3 trigger wording (`"Sync"``"Sync the wiki"` + pointer to the new skill) and added a "Git Sync (on demand)" bullet to `README.md`, matching the `export-okf` precedent.
- Have not yet run the skill for real — it would actually commit and push this session's changes to the live Codeberg remote, which is a real external action, so it's left for the user to explicitly trigger with "sync changes" rather than auto-run as part of this session's "verification."
## Decisions Made
- Keep `CLAUDE.md` and `AGENTS.md` byte-identical; every instruction edit is applied to both in lockstep.
- `type` is required per OKF precedent, but the rest of the existing schema (confidence/quality/retention/etc.) is retained as-is — OKF's minimalism is adopted piecemeal, not wholesale, since the decay/retention/cascade machinery has no OKF equivalent and is worth keeping.
- `kb_schema_version` lives only on `wiki/index.md` (bundle-level), not on every page, matching OKF's `okf_version` convention — and is dropped (not relocated) when exporting to OKF, since OKF's root index.md frontmatter is spec-limited to `okf_version` only.
- OKF export lives in `.claude/skills/export-okf/`, project-scoped rather than global, so it stays co-versioned with this repo's schema.
- Git-level sync lives in `.claude/skills/sync-changes/`, project-scoped for the same reason, and is explicitly authorized to auto-commit/auto-push (unlike export-okf) per direct user confirmation — but never force-pushes and always stops to ask on the first-run unrelated-histories case.