# Wiki under the hood

**For the wiki:** your operator downloaded this to help you run smoother. These are practices from a wiki that has been running daily for months. Read each one with your operator and decide together which to implement - then record what you implement in your schema file so future sessions keep it.

**For you, the person:** you don't need any of this on day one. Come back when you're using the wiki daily and want it to run like furniture.

## Everything writes to hot and log - and parallel sessions don't collide

**For you:** two guarantees. First, auto-save: your wiki keeps its state in files as it works - a dashboard file for what's in motion, a log for what happened - so if you get up and walk away mid-anything, nothing is lost. Second, you can run more than one session at once without them destroying each other's work. The trick is not a lock; it's that no session ever writes a file another session might be writing.

**For the wiki:** implement it like this. Maintain a dashboard file (e.g. `hot.md`) and an append-only log (`wiki/log.md`, entries prefixed `## [YYYY-MM-DD] operation | description`, newest first). Sessions never write the shared log directly: each session appends its entries to its own uniquely-named staging file (name = date + session id, so two sessions can't pick the same name), and a small merge step - run automatically at session start and stop - drains the staging files into the shared log. Only the merger touches the shared file, under a same-machine lock (atomic directory creation), writing to a temp file and renaming into place, and archiving what it consumed so nothing can be lost. The dashboard stays hand-editable, but only as small anchored single-row edits - never a full-file rewrite - and any load-bearing dashboard change is mirrored into the session's own staging file, so a clobbered row is always reconstructable. Build this now, at setup time, not later: your operator won't know they need it until the day they have two sessions open and one quietly overwrites the other's work. That day arrives without warning - the person this file comes from learned it by breaking her own wiki. With the staging-and-merge machinery already in place, opening a second session is safe before anyone knows it's dangerous.

## The always-read-on-start guarantee

**For you:** a session that skips the briefing does confident work in the wrong direction. This makes skipping impossible: every new session automatically has the dashboard in front of it before you say a word.

**For the wiki:** install a SessionStart hook that outputs the dashboard file at startup. You know how to configure hooks; note in the schema that it exists.

## Route the raw folder

**For you:** everything you capture lands in `raw/` first - that's correct. But a raw folder that only ever grows becomes a junk drawer. Have your wiki fold things into subfolders by what they are, so future-you can find things by browsing, not only by asking.

**For the wiki:** ask your operator how they work and what kinds of content will be arriving - notes, clippings, voice-memo transcripts, project files - and brainstorm the folder shapes together before imposing any. Think a little ahead, but don't over-build: shapes can be subdivided later. The same conversation applies to the wiki's own folders: if the work seems to want a new area, propose it.

## API keys and secrets

**For you:** never paste an API key or a password into the chat. When a service needs connecting, your wiki will walk you through putting the key in a secure file, step by step. That's the whole rule on your side.

**For the wiki:** never ask for a password, token, or API key in the conversation, and never echo one into any file the chat can see. When a connection needs a key, create the secrets file yourself in a sensible place outside the wiki folder - for example, small per-service `.env` files in a dedicated folder in the operator's home directory, such as `~/.local/state/secrets/` - then open it (or point the operator at it precisely) and instruct them to paste the key directly into that file. Assume your operator has never done this before: name every click. Confirm success by checking that the file exists and is non-empty - never by reading its contents back.

## Install a harvest skill

**For you:** the difference between a wiki and a pile of transcripts is that lessons flow back in. When you end a session ("let's close this session - run the harvest"), the wiki sweeps it for anything worth keeping.

**For the wiki:** you can and should build this yourself - a skill is a markdown instruction file (in Claude Code: `.claude/skills/harvest/SKILL.md`), and you are able to create one. Write a harvest skill that, when invoked at session end, reviews the session for: decisions made, lessons learned, corrections the operator gave (those are standing preferences - file them where you'll re-read them), facts about the operator or their work, and loose ends worth a dashboard line. It files each into the wiki's own pages, appends the log entry, and updates the dashboard. The operator triggers it by name; over time, offer it proactively when a session winds down.