Cline Memory Bank Rules

# Memory Bank Rules My memory resets between sessions. The `memory-bank/` directory is my only continuity. These rules are not optional. ## Session start - Read every file in `memory-bank/` before doing anything else, in this order: `projectBrief.md`, `architecture.md`, `decisions.md`, `activeContext.md`, `progress.md`. Do not start a task before all five are read. - If any file is missing, create it from the structure below and fill it by inspecting the repo — then confirm the contents with the user before relying on them. - If `activeContext.md` contradicts what I see in the code, trust the code, flag the contradiction, and fix the memory file in the same session. ## File structure - `projectBrief.md` — what the product is, who uses it, the 3–5 non-negotiable requirements. Changes rarely; only on explicit scope changes. - `architecture.md` — stack, directory map, how data flows, where each kind of code belongs, commands that must pass before commit. Update when structure changes, not when files change. - `decisions.md` — append-only log: date, decision, alternative rejected, one-line reason. Example: `2026-06-10 — Chose polling over websockets for job status; ws infra not worth it under 50 users.` Never rewrite or delete entries; supersede with a new entry referencing the old. - `activeContext.md` — what is being worked on right now: current task, files involved, approach chosen, known broken states, next concrete step. This file is always accurate at session end. - `progress.md` — feature checklist: done / in progress / not started, plus a short known-issues list with repro notes. ## When to update - Update `activeContext.md` and `progress.md` at the end of every working session, and immediately after completing any task — not "when convenient". - Append to `decisions.md` the moment a choice is made between alternatives (library, pattern, schema shape), even mid-task. If I argued for an approach and the user overruled it, record the user's choice as the decision. - When the user says "update memory bank", re-read every file, reconcile each against the current codebase, and rewrite stale sections — this is a full review, not a token edit. - After any change to build tooling, environment setup, or commands, update `architecture.md` in the same session. ## What never goes in memory - Secrets, tokens, connection strings, or anything from `.env` — refer to variables by name only. - Code snippets longer than 5 lines — link to the file path instead; the repo is the source of truth for code. - Speculation, sentiment, or transcript summaries ("user seemed frustrated"). Facts and decisions only. - Duplicated content between files. Each fact lives in exactly one file; other files reference it. ## Writing standard - Every entry is dated (YYYY-MM-DD). Plain declarative sentences, no headers deeper than `##`, no file longer than ~150 lines — when a file approaches the limit, compress history, never drop open items or decisions.