Maintaining MEMORY.md

Resolve the repository root and inspect MEMORY.md at the start of repository work and before non-trivial debugging, design, workflow, or skill maintenance. Missing memory is normal. Current repository evidence always overrides it.

Qualifying Entries

• GOTCHA: repository evidence proves a reusable trap or failure mode and its cause, recovery, or avoidance is known.
• TASTE: the user expresses a durable preference that will change future repository work.
• CONVENTIONS: repository evidence proves a stable, repository-specific pattern in code, structure, naming, testing, or workflow that will change future work.

Do not record transient status, task history, broad summaries, speculation, generic best practices, or secrets. Do not add conventions already stated in AGENTS.md or authoritative documentation. If a convention should govern all contributors, recommend updating its authoritative owner unless that file is already within the user's requested scope; do not add a new memory entry for it. During curation, retain an existing entry that is the sole record until its authoritative update is completed, then remove the duplicate. Sanitize any reusable lesson involving credentials, tokens, private endpoints, proprietary data, or personal information.

Curate

Perform lightweight curation whenever inspecting or updating memory. Using the evidence already gathered, merge, revise, remove, or sanitize entries that are demonstrably duplicated, misplaced, contradicted, stale, non-qualifying, or sensitive. Do not broaden a lightweight pass into a repository-wide audit.

Perform full curation when the user explicitly requests it or concrete evidence suggests MEMORY.md may be stale. Check every entry against current repository evidence, authoritative guidance, and later explicit user preferences: