# Wiki

The wiki is a git repository of markdown that is also an Obsidian vault. It holds maintained knowledge for future work: what your agents learned in earlier sessions, kept in one place and organized so the next session reads it instead of rediscovering it. Agents operate it through the `llm-wiki` skill and the Meridian engine — the `mrd` command, or the same operations as MCP tools inside Claude Code. A person opens the same directory in Obsidian and reads the computed views in `bases/`.

It sits at both ends of a session. At the start it is a context source: `mrd run LLM_WIKI.md load` prints the wiki's identity, its companions and any structure findings. At the end it is a knowledge sink: the compound stage of the ccc chain writes what the session learned back into it.

The step that builds yours is Step 5 of [Start here](#start-here) — it fetches the skeleton archive and walks the five setup steps. This chapter explains what that step builds and how agents use it afterwards.

## The flow

```mermaid
flowchart LR
  I["inbox/"] --> G["ingest"] --> P["pages"] --> C["check"]
```

1. **inbox/** — evidence lands here as a raw capture: a clipped web page, a scraped repo, a curated session digest, a note you dropped by hand. A capture is immutable once dropped; it keeps its origin (`source:` or `source-uri:`) and its capture time (`created:`).
2. **ingest** — an agent with the `llm-wiki` skill loaded works the capture into knowledge (the skill's CAPTURE cluster): find the page that already covers the subject, preserve the evidence once, update the explanation readers already use, connect it, pin the claims that depend on a specific passage, validate. Not every capture needs a page in every layer.
3. **pages** — the maintained tiers: `sources/` explains one piece of evidence, `domains/` holds the current understanding of a subject, `synthesis/` reasons across subjects, `effects/` describes reusable artifacts.
4. **check** — `mrd run LLM_WIKI.md check` says whether the tree still conforms; exit 1 on findings.

## Layers — one folder per layer

The folder declares the layer. The set is mandated: every wiki under the shared contract carries the same folders, so a shipped Base's folder filter is identical everywhere.

| Folder | Layer | Mutability | What a page there is |
|---|---|---|---|
| `inbox/` | raw | immutable after drop | a capture, in one of six inbox folders: `_unstaged/` (the default drop; Obsidian's new-note folder), `clipper/`, `scraped/`, `filed/`, `curated-sessions/`, `refresh/` |
| `sources/<bucket>/` | source | immutable from the commit that introduces it | a dated interpretation of one input, linked to its capture; each bucket has an uppercase master page |
| `domains/<cluster>/<domain>/` | domain | evolving | one home page per domain; pins the source sections it interprets |
| `synthesis/` | synthesis | evolving | cross-topic reasoning; pins domain and source sections |
| `effects/<kind>/<group>/` | effect | content immutable | a descriptor of a reusable artifact — skill, agent, prompt, site, document, tool — with a git version record |
| `decisions/` | decision | append | `YYYY-MM-DD-<slug>.md`, `status:` pending, decided, rejected or superseded |
| `logs/` | exhaust | append | run logs |
| `bases/` | views | computed | Obsidian `.base` files that render inventories from frontmatter — never a hand-kept list |
| `bin/` | wrappers | byte-identical across wikis | the scripts the contract names |
| `review/` | board | generated, gitignored | the pin-state board `bin/wang` regenerates; never committed, never hand-edited |

A cluster under `domains/` is a pure container: a page goes inside a domain, never directly inside a cluster. Every tracked folder carries an uppercase blurb page (`inbox/INBOX.md`, `sources/SOURCES.md`, `domains/DOMAINS.md`, …) with a `^check` block; those blurbs are what `check` runs.

## Files the tools need

| File | What it is |
|---|---|
| `LLM_WIKI.md` | the entry page — `type: llm-wiki-root`, `wiki:` name, optional `sessions-root:` and `repos-root:`, and the declared `load` and `check` tasks |
| `SCHEMA.md` | the local overlay: contract version, sessions root, scope ledger, default owner — at most 60 lines, no absolute path |
| `CONTRACT.md` | the shared contract, byte-identical to the `llm-wiki` skill's `references/contract-v5.md` |
| `MERIDIAN.md` | the root's self-declaration (`type: meridian-root`, `name:`), written by `mrd init` |
| `bases/DOMAINS.base`, `bases/REVIEW.base` | the two Bases every wiki must carry; the rest are optional |
| `bin/` | `wang`, `why`, `repin`, `pin-law.sh`, `bases-identity.sh`, `contract-identity.sh`, `commit-gate.sh` and the others the contract lists |
| `.wikiignore` | the committed exception list for the gates (`SCHEMA.md`'s `scope-ledger:` names it); a finished wiki has it empty |
| `rules/`, `meridian/` | optional armed middleware, and the engine's reserved runtime home — never hand-edited |

`MERIDIAN.md` in the repo names the root; `~/MERIDIAN.md` on a machine binds that name to a path. Binding is what makes `<wiki-name>:LLM_WIKI.md` resolve from anywhere and makes the MCP tools list the wiki as a root. Local CLI work in the checkout needs no binding.

## How agents read it

- `mrd run LLM_WIKI.md --list` — the tasks the entry page declares; `load` and `check` are the two the entry template declares.
- `mrd run LLM_WIKI.md load` — the context an agent pulls at session entry.
- `mrd read <page>` — a page's section map, then the sections you name; read the map before a large page.
- `mrd sql` — SQL over the corpus's frontmatter, links, tags and sections; the way to find a subject's home.
- `mrd resolve '<wiki-name>:LLM_WIKI.md'` — where a named root lands on this machine.

Inside Claude Code the ccc-statusd MCP tools `read`, `sql`, `resolve`, `run` and `walk` do the same work with the same names; the `ccc-meridian` skill teaches both faces.

## How agents write it

- **A write is a guarded put.** The engine takes a fingerprint from your read and refuses the write if the page moved under you — a refusal names what is missing; re-read and re-plan, never resend the same bytes.
- **Link versus pin.** A link means "see also". A pin means "this claim depends on that passage": `mrd pin <page> '<target>#<Heading path>'`, one per claim, the narrowest heading that supports it, with a twin line under an `## Inputs` section at the end of the page. When the pinned passage changes the pin goes red on the review board; `bin/why` shows the pair, you read both, and `bin/repin` settles it — never re-pin unread text to make a check green.
- **Ingest by the skill's steps**, not by hand: prefer improving the page readers already use over adding another; keep each fact in one maintained home and link to it from elsewhere; remove obsolete guidance instead of stacking correction banners.
- **Provenance is untouchable.** A tidy never rewrites a capture's `created:`, `source:` or `source-uri:`, and never backfills `updated:` or `reviewed:`; `reviewed:` records a review act, not a cleanup.
- **Never a live secret in a page**, never another wiki's people, content or absolute paths.
- **Compound writes for you.** At the close of a ccc chain session the compound stage ingests the session's memos into the wiki bound under the root name `home-wiki` — bind yours under that name (step 5 does) or compound writes nothing into it.

## Checks, cheapest first

1. `mrd run LLM_WIKI.md check` — structure, blurb presence, the closed set of inbox folders. Silent when clean; exit 1 with a finding line per problem.
2. `mrd check --json` — pin state against the engine's baseline.
3. `bin/wang --gate` — regenerates `review/` and applies the hard tier of the board.

A `status` glance is not a verdict; `check` is. An empty pin walk means no pins, not verified truth.

## Obsidian

Open the wiki directory as a vault. Bases is a core Obsidian feature — no community plugin is required for the views to render. The skeleton carries no `.obsidian/` settings: in Obsidian's Files and links settings, point new notes and attachments at `inbox/_unstaged/`, so a note you write by hand lands in a declared inbox folder.

## The five setup steps

Named here so this chapter reads on its own; Step 5 of Start here runs them.

1. Choose the directory and the wiki name — a git repository, since pins anchor on git objects.
2. Adapt the entry template into `LLM_WIKI.md`.
3. Add `SCHEMA.md` and `CONTRACT.md`, with the layout, Bases and wrappers the contract requires.
4. Declare the Meridian root with `mrd init . --name home-wiki` and bind it in `~/MERIDIAN.md` under that name — the compound stage writes only into the root bound as `home-wiki`.
5. Verify: `mrd resolve LLM_WIKI.md`, `mrd run LLM_WIKI.md --list`, `mrd run LLM_WIKI.md load`, `mrd run LLM_WIKI.md check`.

The skeleton tarball carries steps 2 and 3 already done — entry page, contract, schema, the mandated folders with their blurb pages, the two required Bases and the wrappers — so the step is: extract, `mrd init`, verify.

## Skills that carry the detail

- `llm-wiki` — selecting a wiki, its entry pages, the verb clusters (CAPTURE, BUILD, SEEK, EVOLVE, HARVEST, UPDATE), page design, provenance and pins. Load it for any wiki work.
- `ccc-meridian` — the engine: addressing, section maps, guarded writes, pin proof, the refusal vocabulary, SQL over a root.
- `ccc-compound` — the chain stage that graduates a session's memos into the wiki.