Fix six defects found in the first end-to-end inbox → knowledge run (1.2.0)

Two of these made documented workflows impossible to complete correctly.

P0 — the inbox could never be cleared. The intent ("keep items here only until
they're classified") was stated in one place and contradicted in five, so an
agent following the contract correctly refused to remove anything. Grants a
scoped clear authority instead of blanket delete: an inbox copy may be removed
once its content is verifiably filed at the destination named in the approved
triage table, never before that destination copy exists. Adds a Clear stage
after Apply, and rewrites rollback to run from the destination using the triage
report's source → destination record.

P0 — every bundle wikilink broke on the first ingest. Bundle indexes are all
named index.md, so [[bundle-slug]] can only resolve through an alias, and
bundle-template.md shipped none. Adds aliases: [<bundle-slug>], states the rule
in frontmatter.md (whose "required when filename != id" framing did not cover
bundle indexes, which have no id at all), and makes verify.py fail on a bundle
index missing its alias.

P1 — nothing documented that inbox material bound for the knowledge base goes to
04-knowledge/raw/<type>/ and is then ingested rather than copied in.

P1 — Ingest/Query/Lint had no way to be invoked: adds /ingest, /query-knowledge,
/lint-knowledge, routing rows in CLAUDE.md, and a knowledge-base responsibility
on the knowledge-librarian naming the wiki and pointing at SCHEMA.md.

P1 — the wiki is the shareable layer but had no automated anonymity gate. Adds
04-knowledge/WorkOSWiki and 04-knowledge/schema to the privacy scanner's targets
(raw/ stays out; it is non-anonymous by design). Skips Obsidian's git-ignored
.obsidian/ config, which the new scan flagged.

P2 — built wiki files had drifted from setup/templates/, losing among other
things the aliases rule that would have prevented the bundle-link failure. All
14 built files re-derived from their templates with instance additions
re-applied, plus tests/drift/test_template_drift.py to fail on content a built
file has lost. Run against the pre-fix tree it caught all four known drops and
five more.

Verified end to end on a clean copy: a document dropped into 00-inbox/ reaches a
bundle as a linked OKF page with a provenance page, updated indexes, and a log
entry, ending with an empty inbox and no manual file edits, with privacy_check,
validate_structure, verify.py, and run_tests.py all green.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

Author: CoachSteff

.claude/agents/knowledge-librarian.md

@@ -1,6 +1,6 @@
 ---
 name: knowledge-librarian
-description: Captures, classifies, and files incoming material to keep the Work OS tidy and findable. Use for inbox processing and knowledge organisation.
+description: Captures, classifies, and files incoming material to keep the Work OS tidy and findable. Use for inbox processing, knowledge-base ingest, and knowledge organisation.
 tools: Read, Write, Glob, Grep
 ---
 
@@ -13,3 +13,12 @@ Read the supporting files in that folder before working, and follow
 .claude/skills/capture-and-classify/classification-rules.md for routing.
 Route user-specific data only to 01-context/; never into instructions, templates, or knowledge notes.
 Propose moves before applying them; never delete or overwrite important files without approval.
+
+`00-inbox/` is a queue: after moves are applied and each destination copy is confirmed, clear the
+inbox copies of the filed items. That scoped clear is authorised by the approved triage table — it
+is not general delete authority, and nothing is removed before its destination copy exists.
+
+Before working in `04-knowledge/`, read 04-knowledge/schema/SCHEMA.md — it defines the Ingest,
+Query, and Lint operations, the frontmatter spec, and the anonymity, copyright, and provenance
+gates. Durable reference material goes to 04-knowledge/raw/<type>/ and is then ingested per that
+schema (`/ingest`), not copied into the wiki by hand.

.claude/commands/ingest.md

@@ -0,0 +1,34 @@
+---
+description: Ingest a source from 04-knowledge/raw/ into the knowledge base (provenance page, topic pages, indexes, log).
+---
+
+# /ingest
+
+Execute the **Ingest** operation defined in §4 of `04-knowledge/schema/SCHEMA.md`. Read that file
+first — it is the contract; this command only sequences it.
+
+**Input:** a source in `04-knowledge/raw/<type>/` (or a source the user points at, which is saved
+there first). Material routed here by `/process-inbox` arrives this way.
+
+1. **Read** the source in `raw/`. State the mode. Summarise the key takeaways for the user.
+2. **Summarise into provenance.** Create `<vault>/sources/<YYYY-MM-DD-source-slug>.md`
+   (`type: reference`) with the takeaways, the `raw/…` path, and the original link/date. Its
+   filename is dated, so it needs `aliases: [<id>]`.
+3. **Fold into topic pages.** Create or update `concept` / `reference` / `howto` pages in the right
+   `<vault>/<topic>/` bundle, from `04-knowledge/schema/page-template.md`. Add `[[wikilinks]]`; bump
+   each touched page's `updated:`.
+4. **Update indexes.** The bundle's `index.md` (from `04-knowledge/schema/bundle-template.md` —
+   bump `version:`, and a new bundle index must carry `aliases: [<bundle-slug>]` or the master
+   catalog's link to it breaks), then the vault's `index.md`.
+5. **Log it.** Append one entry to `<vault>/log.md`: date, source, pages touched, notable findings.
+
+**Gates (all four apply):** anonymity — generalise real names, companies, clients, emails, and
+locations; personal specifics go to `01-context/`, never into the wiki. Copyright — summarise, never
+paste raw text. Provenance — every non-obvious claim carries a `source:`. No side effects without
+approval.
+
+**Finish by verifying:**
+
+```bash
+python3 setup/verify.py 04-knowledge <VAULT> && python3 scripts/privacy_check.py --quiet
+```

.claude/commands/lint-knowledge.md

@@ -0,0 +1,28 @@
+---
+description: Run the knowledge base health check and write a dated lint report.
+---
+
+# /lint-knowledge
+
+Execute the **Lint** operation defined in §6 of `04-knowledge/schema/SCHEMA.md`. Run it during the
+weekly review, or on request.
+
+Scan the vault for:
+- **Contradictions** — claims that conflict between pages.
+- **Orphans** — pages with no incoming `[[wikilinks]]`.
+- **Missing concepts** — ids referenced in `[[links]]` with no page.
+- **Stale claims** — a page whose `updated:` predates a newer source on the same topic.
+- **Low-confidence items** — `confidence: low` pages needing follow-up.
+- **Anonymity leaks** — any real name, company, client, email, or location that slipped in.
+- **Index drift** — bundle `entries:` or the master `index.md` out of sync with disk.
+- **Missing aliases** — dated pages (filename ≠ `id`), and bundle `index.md` files missing
+  `aliases: [<bundle-slug>]`.
+
+Write findings to `04-knowledge/_lint/lint-<YYYY-MM-DD>.md` and append a one-line summary to the
+vault's `log.md`. **Propose** fixes; do not auto-fix contradictions or delete pages without approval.
+
+The mechanical checks back this up and should be run alongside it:
+
+```bash
+python3 setup/verify.py 04-knowledge <VAULT> && python3 scripts/privacy_check.py --quiet
+```

.claude/commands/process-inbox.md

@@ -4,15 +4,22 @@ description: Triage everything in 00-inbox and route it to the right folders.
 
 # /process-inbox
 
-Process `00-inbox/` end to end.
+Process `00-inbox/` end to end. The inbox is a queue: a run ends with every filed item cleared out
+of it, and only flagged items left behind.
 
 1. For each inbox item, apply the `capture-and-classify` skill:
    - determine type and destination via `classification-rules.md`;
    - route any personal data to the personal zone (`01-context/`);
+   - route durable reference material to `04-knowledge/raw/<type>/`, to be **ingested** per
+     `04-knowledge/schema/SCHEMA.md` (run `/ingest`) rather than copied into `04-knowledge/`;
    - detect duplicates.
 2. Present a triage table (item → destination → filename → flags) and **ask for approval** before
    moving anything.
-3. After approval, apply moves; never delete or overwrite without explicit confirmation.
-4. Report what changed and what remains in the inbox.
+3. After approval, apply the moves and record source → destination in the triage report.
+4. Clear the inbox: remove the `00-inbox/` copy of each item whose destination is named in the
+   approved table and whose destination copy is confirmed to exist. Nothing is removed before its
+   destination copy exists; flagged or unconfirmed items stay. Any other deletion or overwrite
+   still requires explicit confirmation.
+5. Report what changed and what remains in the inbox (flagged items only, ideally none).
 
 Delegates heavy triage to the `knowledge-librarian` agent when the inbox is large.

.claude/commands/query-knowledge.md

@@ -0,0 +1,16 @@
+---
+description: Answer a question from the knowledge base, cited with wikilinks, and offer to save the answer.
+---
+
+# /query-knowledge
+
+Execute the **Query** operation defined in §5 of `04-knowledge/schema/SCHEMA.md`.
+
+1. **Read the vault's `index.md` first** to navigate. Do not brute-force-load every page.
+2. Open only the relevant pages; synthesise an answer.
+3. **Cite** with `[[wikilinks]]`, and where a claim rests on a source, its `raw/…` or
+   `<vault>/sources/…` provenance. Tag claims `[fact | interpretation | assumption]` and state
+   confidence.
+4. If the answer is novel and worth keeping, **offer to save it** as a new page (and log it) — that
+   is how the base compounds. Say plainly when the base does not cover the question, rather than
+   filling the gap from general knowledge without marking it.

.claude/skills/capture-and-classify/SKILL.md

@@ -21,22 +21,31 @@ named consistently, and checked for user-specific data.
 4. Check for **duplicates**; if a near-match exists, propose a merge instead of a new file.
 5. **Propose** the move (source → destination, new name). Do not overwrite or delete without
    approval.
-6. After approval, apply the move and report what changed.
+6. After approval, apply the move and record source → destination in the triage report. Durable
+   reference material goes to `04-knowledge/raw/<type>/` and is then **ingested** per
+   `04-knowledge/schema/SCHEMA.md`, not merely copied in.
+7. **Clear** the `00-inbox/` copy of each item whose destination copy is confirmed to exist, so the
+   inbox stays a queue. Leave flagged and unconfirmed items in place. Report what changed.
 
 ## Outputs
 A triage decision per item: type, destination path, filename, personal-zone routing note,
-duplicate/merge note.
+duplicate/merge note, and whether the inbox copy was cleared.
 
 ## Context dependencies
 - Never copy personal data out of `01-context/`.
 
 ## Prohibited actions
-- Deleting or overwriting important files without approval.
+- Deleting or overwriting important files without approval. Clearing an inbox copy is the one
+  scoped exception: it is authorised once the item's content is verifiably filed at the destination
+  named in the approved triage table, and never before that destination copy exists. See
+  `08-workflows/capture-and-classify/approval-policy.md`.
 - Placing user-specific data outside `01-context/`.
 
 ## Quality checklist
 - [ ] Correct type and destination, justified by the rules.
 - [ ] Consistent, dated filename.
 - [ ] Personal data routed to the personal zone (`01-context/`).
+- [ ] Knowledge-bound material ingested per the schema, not just copied into `04-knowledge/`.
 - [ ] Duplicates detected and flagged.
 - [ ] Move proposed before applied.
+- [ ] Inbox cleared of everything filed; only flagged items remain.

.claude/skills/capture-and-classify/classification-rules.md

@@ -5,19 +5,34 @@ still unclear, leave it in `00-inbox/` and ask.
 
 | If the item is... | Destination |
 |---|---|
-| Raw, unprocessed capture not yet triaged | `00-inbox/` (stays until classified) |
+| Raw, unprocessed capture not yet triaged | `00-inbox/` (a queue — cleared once filed; see below) |
 | User-specific: profile, priorities, clients, private examples, terminology | `01-context/` (git-ignored) |
 | Fictional persona/sample data for demos | `01-context/demo/` |
 | An ongoing responsibility with no end date | `02-areas/` |
 | Work with a defined outcome and completion point | `03-projects/` (active / waiting / archive) |
-| Durable reference knowledge or research notes | `04-knowledge/` |
+| Durable reference knowledge or research notes | `04-knowledge/raw/<type>/`, then **ingested** per `04-knowledge/schema/SCHEMA.md` |
 | A reusable, anonymous document/agenda/template | `05-templates/` |
 | A decision worth remembering, with rationale | `06-decisions/` |
 | A portable agent specification | `07-agents/` |
 | A multi-step process definition | `08-workflows/` |
 | A finished or draft deliverable for others | `09-outputs/` (drafts / final) |
 | Completed or stale material to retain but retire | `10-archive/` |
 
+## Inbox lifecycle
+`00-inbox/` is a queue, not a store: an item lands, is classified, is filed at an approved
+destination, and its inbox copy is then **cleared**. Removal is authorised once the content is
+verifiably filed at the destination named in the approved triage table, and never before that
+destination copy exists. An item whose destination is unclear stays in `00-inbox/` and is flagged.
+See `08-workflows/capture-and-classify/approval-policy.md`.
+
+## Filing to the knowledge base means Ingest, not a file move
+"Durable reference knowledge" does **not** mean dropping a file into `04-knowledge/`. The source
+document goes into `04-knowledge/raw/<type>/` — the immutable, git-ignored archive of source
+material — and is then processed by the five-step **Ingest** in
+`04-knowledge/schema/SCHEMA.md` (`/ingest`): a dated provenance page under the wiki's `sources/`,
+one or more topic pages, updated bundle and master indexes, and a `log.md` entry. The file move
+alone leaves the knowledge base unchanged.
+
 ## Personal data goes in the personal zone
 Personal context — a real name, company, client, email, location, or personal preference — belongs
 under `01-context/` (git-ignored), the home for your own data. Keep it out of the *shareable

00-inbox/README.md

@@ -3,7 +3,33 @@
 Unprocessed capture. Anything new and un-triaged lands here first, then gets routed by the
 `capture-and-classify` skill / `/process-inbox` command.
 
-- Keep items here only until they're classified.
+## Lifecycle — this is a queue, not a store
+
+An inbox item exists in order to be filed and then to leave. One triage run takes an item through
+four steps:
+
+1. **Land** — the item is dropped here, un-triaged.
+2. **Classify** — `/process-inbox` proposes a destination for every item (the triage table).
+3. **Apply** — after approval, the item's content is written to that destination.
+4. **Clear** — once the content is verifiably filed at the destination named in the approved
+   triage table, the `00-inbox/` copy is removed. Nothing is removed before its destination copy
+   exists.
+
+An item whose destination is unclear is **not** removed: it stays here and is flagged for the next
+run. A healthy inbox is therefore empty, or holds only flagged items.
+
+Step 4 is authorised by this lifecycle — it is not a general licence to delete. It covers only an
+inbox copy whose destination copy has been confirmed to exist. See
+[`../08-workflows/capture-and-classify/approval-policy.md`](../08-workflows/capture-and-classify/approval-policy.md).
+
+## Rules
+
 - If an item contains user-specific data, it must be routed to `01-context/`, never to an
   anonymous folder.
+- Durable reference material is routed to `04-knowledge/raw/<type>/` and then **ingested** per
+  [`../04-knowledge/schema/SCHEMA.md`](../04-knowledge/schema/SCHEMA.md) — filing it there means
+  running Ingest, not copying a file in.
 - Naming: `YYYY-MM-DD-short-kebab-title.md`.
+- The contents of this folder are git-ignored (only this README is tracked). Inbox material often
+  comes from elsewhere — recorded-session transcripts, exports, other people's data — so it stays
+  out of the shareable template by default.

04-knowledge/CLAUDE.md

@@ -4,18 +4,20 @@ This folder is an **LLM Wiki** (Andrej Karpathy's pattern) whose pages follow th
 **Open Knowledge Format (OKF)**. It has three layers:
 
 - `raw/` — immutable primary material you or agents drop in (web clips, PDFs, files, data).
-- `WorkOSWiki/` — the anonymous, LLM-maintained knowledge pages. This is the shareable layer.
+- `WorkOSWiki/` — the anonymous, LLM-maintained knowledge pages. This is the shareable layer, and the
+  folder you open as an Obsidian vault.
 - `schema/` — how the base is structured and operated.
 
 **Before you Ingest, Query, or Lint this knowledge base, read
-[`schema/SCHEMA.md`](schema/SCHEMA.md).** It defines the operations, the page format, the
-naming rules, and the anonymity and no-side-effects-by-default gates.
+[`schema/SCHEMA.md`](schema/SCHEMA.md).** It defines the operations, the page format, the naming
+rules, and the anonymity and no-side-effects-by-default gates. In Claude Code the three
+operations are `/ingest`, `/query-knowledge`, and `/lint-knowledge`.
 
 Two hard rules:
 
 1. **`WorkOSWiki/` is anonymous.** No real names, companies, clients, emails, or locations in wiki
-   pages. Personal specifics belong in `01-context/` (see the root `CLAUDE.md`). `raw/` is the
-   only non-anonymous layer and is git-ignored.
+   pages. Personal specifics belong outside the wiki, in the private context folder (in a Work OS,
+   `01-context/` — see the root `CLAUDE.md`). `raw/` is the only non-anonymous layer and is git-ignored.
 2. **No external side effects by default.** Do not contact external integrations or perform
    external side effects without explicit approval; prefer dry-run, and use only fictional or
    public sources for seed content.

04-knowledge/README.md

@@ -1,44 +1,45 @@
 # 04-knowledge
 
 Durable reference knowledge, run as an **LLM Wiki** (Karpathy's pattern) with pages in the
-**Open Knowledge Format (OKF)**. Things you'd rather not re-derive later live here as a knowledge
-graph that compounds over time, instead of being re-discovered on every question.
+**Open Knowledge Format (OKF)**. Things you'd rather not re-derive later matter here: knowledge
+lives here as a graph that compounds over time, instead of being re-discovered on every question.
 
 ## The three layers
 
 | Layer | What it holds | Editable? | Anonymous? |
 |---|---|---|---|
 | `raw/` | Primary material you or agents find — web clips, PDFs, files, datasets. | Read-only | No — git-ignored |
-| `WorkOSWiki/` | LLM-maintained OKF pages, organised into topic bundles, with `index.md` + `log.md`. | LLM-maintained | **Yes** |
+| `WorkOSWiki/` | LLM-maintained OKF pages, in topic bundles, with `index.md` + `log.md`. | LLM-maintained | **Yes** |
 | `schema/` | The operating model, page format, and rules. | Rarely | Yes |
 
-The rest of the tooling (agents, commands) reads [`schema/SCHEMA.md`](schema/SCHEMA.md) to know how
-to operate the base. A short auto-loaded [`CLAUDE.md`](CLAUDE.md) points there.
+Tooling reads [`schema/SCHEMA.md`](schema/SCHEMA.md) to operate the base; a short auto-loaded
+[`CLAUDE.md`](CLAUDE.md) points there. The three operations are also exposed as commands:
+`/ingest`, `/query-knowledge`, and `/lint-knowledge`.
 
 ## How it runs — three operations
 
 - **Ingest** — a new source in `raw/` is summarised into `WorkOSWiki/sources/` and folded into the
   relevant topic pages, updating the indexes and the log.
-- **Query** — questions are answered from `WorkOSWiki/index.md` first, cited with `[[wikilinks]]`, and
-  good answers are saved back as pages so knowledge compounds.
+- **Query** — questions are answered from `WorkOSWiki/index.md` first, cited with `[[wikilinks]]`,
+  and good answers are saved back as pages so knowledge compounds.
 - **Lint** — a periodic health check for contradictions, orphans, stale claims, and missing pages.
 
 See [`schema/SCHEMA.md`](schema/SCHEMA.md) for the exact procedures.
 
 ## Open in Obsidian
 
-Use `WorkOSWiki/` as the UI: **open `04-knowledge/WorkOSWiki/` as your Obsidian vault** (not `04-knowledge/`).
-That keeps the private, git-ignored `raw/` layer out of Obsidian's index and gives a clean graph of
-just the knowledge pages. `[[wikilinks]]`, `tags:`, and `related:` all work as Obsidian links;
-dated source pages carry `aliases:` so their `[[id]]` links resolve. Obsidian's `.obsidian/` config
-is git-ignored via `WorkOSWiki/.gitignore`.
+**Open `04-knowledge/WorkOSWiki/` as your Obsidian vault** (not `04-knowledge/`). That keeps
+the private, git-ignored `raw/` layer out of Obsidian's index and gives a clean graph of just the
+knowledge pages. The vault name in Obsidian is the folder name (`WorkOSWiki`). `[[wikilinks]]`, `tags:`, and
+`related:` all work as Obsidian links; dated source pages and bundle indexes carry `aliases:` so
+their links resolve. Obsidian's `.obsidian/` config is git-ignored via `WorkOSWiki/.gitignore`.
 
 ## Anonymity
 
-`WorkOSWiki/` notes are **anonymous references**. Any real name, company, client, email, or location
-belongs in `01-context/`, never in `WorkOSWiki/`, `schema/`, or templates. `raw/`
-may contain personal or copyrighted material, so it is git-ignored and never shared; wiki pages
-*summarise and cite* raw material, they never reproduce it verbatim.
+`WorkOSWiki/` notes are **anonymous references**. Real names, companies, clients, emails, or
+locations belong outside the wiki, in the private context folder (in a Work OS, `01-context/`),
+never in `WorkOSWiki/`, `schema/`, or templates. `raw/` may contain personal or copyrighted material, so it is git-ignored and never
+shared; wiki pages *summarise and cite* raw material, they never reproduce it verbatim.
 
 ## Not part of the wiki