learning-from-mistakes

name	learning-from-mistakes
description	Record a hard-won engineering lesson after a bug or mistake is resolved. Use when a bug resisted ATLAS until Boss's guidance cracked it, or when a long debugging hunt ended in an aha moment worth never relearning.

Capture the lesson so future-ATLAS does not pay the same debugging cost twice.

When to write an entry

Write one — without being asked — when either is true:

• Boss had to step in. A bug or mistake ATLAS could not solve alone; Boss's guidance is what cracked it.
• Aha moment after a long hunt. A debugging session that ran long and ended in a non-obvious realization.

Skip routine fixes. The bar is surprise: would this genuinely save someone — likely future-ATLAS — from a hard time? If the cause was obvious in hindsight to anyone, it is not worth an entry. Apply the same high-entropy filter as NOTES.md: record what is surprising, not what is expected.

Where

One file per lesson: docs/learning-from-mistakes/<kebab-case-slug>.md. The slug names the problem, so the folder is self-indexing — e.g. stale-closure-in-useeffect.md, timezone-off-by-one-on-date-parse.md.

Format

Keep it brief — important information only. Four short sections:

# <Lesson title — the problem in one line>

**Date**: YYYY-MM-DD · **Area**: <project / module / domain>

## Symptom
What looked wrong — the observable behavior or the assumption that failed.

## Root cause
The non-obvious truth. Why it actually happened.

## Resolution
The fix, or the insight that cracked it. Credit Boss's guidance if that is what unblocked it.

## Lesson
The transferable rule — how to recognize or avoid this next time.

A few tight sentences per section beats a padded template. If a section adds nothing, drop it.

Recall

Before concluding a hard bug is unsolvable, scan docs/learning-from-mistakes/ — a past lesson may already name the cause.