Purpose: Convert a completed spec's execution history into logged lessons, and escalate recurring friction into a concrete proposed change to a rule, skill, persona, or reference file. This is what makes the DevFoundry process self-improving instead of static.
Trigger: After the QA Verifier approves a spec (all acceptance criteria pass), before the spec is moved to specs/archive/.
specs/active/SPEC-<id>-<short-name>.md, its Implementation Plan task list, and the Verification & Regression Plan checklist..devfoundry/rules/, or did QA catch something a rule should have prevented? If yes, note what rule was missing or insufficient..devfoundry/references/* should already document? If yes, draft the missing fact as a direct edit..devfoundry/skills/spec-interview.md) miss a question that caused rework after implementation started? If yes, note the missing interview question..devfoundry/skills/regression-check.md as a standing check..devfoundry/improvement-log.md using the format below. Always append — never rewrite prior entries.none (no friction occurred), do not add it to the Friction Tally — the tally tracks recurring problems, not clean runs, and a clean run must never trigger the escalation below. Otherwise, update the “Friction Tally” table at the top of .devfoundry/improvement-log.md for this entry's Category + affected file (increment Count, append this spec's ID). If the updated Count is 3 or more:
.devfoundry/rules/, .devfoundry/skills/, .devfoundry/personas/, or .devfoundry/references/ file.ESCALATED and record what was changed once approved.## <YYYY-MM-DD> — SPEC-<id>
- **What worked:** <brief>
- **Friction:** <brief, or "none">
- **Category:** rule-gap | reference-gap | interview-gap | repeated-verification | none
- **Affected file:** <the .devfoundry/rules|skills|personas|references file this friction relates to, or "none">
- **Proposed change:** <file + summary, or "none">
- **Status:** LOGGED | ESCALATED | APPLIED
Powered by TurnKey Linux.