Self-evolution
Corrections become learnings, learnings load every session, and a review skill turns recurring signals into prompt and skill edits.
Feedback is durable
Every correction you give mid-conversation ("don't do that", "actually, that's wrong") lands in knowledge/raw/user/feedback.md, append-only. The next compile synthesizes all feedback into a Learnings block in knowledge/memory/index.md, which loads at the start of every future session. Kevin sees its own past misses while it works.
Self-review
When you have ten minutes, run self-review. It casts a wide net across eight sources: the Learnings synthesis, the full feedback log, the last seven days of sessions and task threads, git history, concept articles, in-flight plans, and installed skills. It greps for both correction and confirmation phrases; wins validate non-obvious choices.
Each theme is classified as missing, buried, present but violated, or present and working. The point is catching rules that landed but did not stick. Themes rank by severity × instances × cycles; anything with fewer than two independent signals is dropped. If nothing clears the bar, Kevin says so and stops.
Proposals come in three tracks:
| Track | What | Applied |
|---|---|---|
| A | Prompt or skill edits. Identity → SOUL.md, procedural → AGENTS.md, skill-specific → that skill | In session, you pick which to accept |
| B | Code-change plans written to reports/plans/ | Never auto-applied; you implement them in a separate session |
| C | Install or create a skill, only for a recurring multi-step procedure | Explicit approval required |
Aging proposals (over 14 days, no follow-through) get re-surfaced, downgraded, or closed. A quality gate runs before anything lands: every target file actually read, specific evidence with timestamps and quotes, and for any pre-existing rule, violations counted after it was introduced.
Three stages, loosely coupled: capture is automatic, compile is on demand, review is manual. No ceremony.