saturday-rituallisted

# Maintenance ritual **This is optional.** Skip it for anything small, young, or throwaway — a short-lived project, a solo developer on a handful of files, a prototype. The maintenance overhead exceeds the value until a project is long-lived enough to accumulate real drift across its skills, docs, and rules. The default bias is to defer; only run this once drift is actually piling up (a registry filling with findings, skill docs that describe how the code worked months ago, a rules file that's been routinely overridden). When it does apply, it catches what nothing else does. Long-lived projects drift invisibly: a skill doc cites file paths that have moved and function shapes that have changed, so it quietly produces wrong recommendations; a flow doc still describes the journey as of the last redesign, so conformance checks pass against a stale baseline; a rule says one thing while everyone routes around it with the override syntax, so the rule book is fiction. Each is harmless per session and toxic across sessions. The ritual is the detection loop that keeps the canonical sources honest. ## The four properties — ship all four or none A ritual fails the moment it lacks any of these. 1. **Bounded time.** Pick a cadence and a time-box and hold them — a common default is thirty minutes a week, longer for high-activity projects, biweekly or monthly for quiet ones. Cadence without a time-box stretches to fill the day and gets skipped when busy; a time-box without a cadence nev