compush

/compush — record the work, commit, push

Run these steps in order. Every step is scoped to what this session changed — no archaeology, no re-auditing past sessions.

1. Memory

Save or update memory files for anything memory-worthy from this session (hard-won fixes, new patterns, feedback, project context).

• Search first, then write: run memory_search() for the topic — if an existing file covers it, UPDATE that file; never create a near-duplicate. Delete or fold in files this session made obsolete.
• Index discipline: each memory gets ONE line in MEMORY.md, max ~200 chars: - [Title](file.md) — hook. Detail lives in the topic file, never in the index. If you catch an index entry growing into a paragraph, move the detail into its topic file and shorten the line.

2. Wiki

If the session changed feature behavior, UI, state/store logic, a backend handler, or a data flow: memory_search() for the relevant wiki file(s) and edit them to match the code. Skip only when the change has no behavior surface (comments, formatting, docs-only).

3. Agent instructions (CLAUDE.md or equivalent) — only if a durable rule changed

The instructions file is a lean orientation doc with a hard character budget (pick one for your project — e.g. 40,000 — and enforce it). Most sessions should not touch it.

• Add or adjust an entry only for a durable, load-bearing rule future sessions must see WITHOUT searching — the "you'll silently break something if you don't know this" class.
• Format: 1–3 lines — the actionable rule plus See <memory file> for the full story. The investigation narrative, war story, and fix history belong in the memory file, never in the instructions file.
• Over budget after your edit? Compress or delegate an existing entry to its memory file in the same pass. The budget is not advisory.

4. Living docs — quick targeted reconcile (skip if your project has none)

If the project maintains long-form living docs (architecture doc, design plan, whitepaper), reconcile only what this session touched:

• Take the 2–4 concrete nouns of what the session changed and run ONE memory_search() plus ONE case-insensitive grep over the doc(s) for them (grep catches exact headings the embedding ranks low).
• Hits → read those sections against what the code does NOW and fix stale prose. New design-level concern → add a subsection in the doc's existing voice.
• No hits and the change is cosmetic → done. Either way, state in one line what you checked.
• Do NOT sweep git history for older drift — this step covers the current session only.