autolearn

# Autolearn: compound a solved problem, keep the learnings honest `autolearn` turns a verified fix into one in-repo learning doc, maintains those docs as the code moves, captures durable project vocabulary, and hands user/preference facts to the memory writer. It writes exactly **two** in-repo surfaces itself: the operating repo's `docs/solutions/` (one learning per file, sole to autolearn — no other skill edits it) and the repo-root `CONCEPTS.md` (the shared-vocabulary glossary, one definition per concept). `CONCEPTS.md` is a shared surface: `compound` also writes it directly, as a second legitimate writer following the same one-definition-per-concept discipline. Every auto-memory write is delegated to `memory-update`. `Op:` of a compound run is `extend` (a new learning) or, in refresh, `correct`/`purge` (see Commits). ## Auto-invoke <auto_invoke> <trigger_phrases> - "that worked" - "it's fixed" - "working now" - "problem solved" - "verified the fix" - "tests pass now" - "build succeeds" </trigger_phrases> Fire automatically on a trigger phrase or after a verified non-trivial fix. The reject-by-default gate below still decides whether a doc is actually warranted. Auto-firing is permission to evaluate, not permission to fabricate. **Skill integration:** after any non-trivial verified outcome, the orchestrating skill should invoke `/autolearn` to evaluate whether a `docs/solutions/` or `CONCEPTS.md` entry is warranted. <manual_override>`/autolearn [context]` documents imm...