feat(todo-format): make the bug-priority matrix binding for codebases

Any project with a codebase (including home and work) derives its codebase bugs' priority from a severity-by-frequency matrix. The priority is dictated, not argued. The mapping is fixed: P1 to [#A], P2 to [#B], P3 to [#C], P4 to [#D], with the bands defined per codebase. Features keep their roadmap judgment. Privacy, security, and safety defects are graded on severity alone. I preserved the worked-example bundle under docs/design.

1 files changed, 46 insertions, 0 deletions

diff --git a/claude-rules/todo-format.md b/claude-rules/todo-format.md
index 5c34966..55530de 100644
--- a/claude-rules/todo-format.md
+++ b/claude-rules/todo-format.md
@@ -33,6 +33,52 @@ When a project's `todo.org` lacks the section, add it before filing or
 grading further tasks — propose the priority semantics and tag set from the
 project's existing usage, and confirm with Craig.
 
+### Bug priority from severity × frequency (mandatory where a codebase exists)
+
+Some projects carry a codebase — source the project maintains under version
+control — even when the project isn't primarily a "code project." home and work
+both have one. Wherever a project has a codebase, a task representing a bug
+*against that codebase* does not get its priority argued: it is **dictated** by
+the severity × frequency matrix below. This is not opt-in. Features keep their
+per-project `[#A]`–`[#D]` roadmap judgment; codebase bugs do not.
+
+Two facts set a bug's priority:
+
+- **Severity** — how bad it is when it occurs (service down / data loss /
+  security or privacy leak at one end; a cosmetic nit at the other).
+- **Frequency** — how often a user hits it (every user every time → rare edge
+  case).
+
+```
+| Frequency / Severity   | Critical | Major | Minor | Cosmetic |
+|------------------------+----------+-------+-------+----------|
+| Every user, every time | P1       | P1    | P2    | P3       |
+| Most users, frequently | P1       | P2    | P3    | P4       |
+| Some users, sometimes  | P2       | P3    | P3    | P4       |
+| Rare edge case         | P2       | P3    | P4    | P4       |
+```
+
+P-level → priority letter (fixed — not a per-project knob):
+
+- P1 → `[#A]`
+- P2 → `[#B]`
+- P3 → `[#C]`
+- P4 → `[#D]`
+
+Release vehicle is illustrative and project-dependent: P1 = current
+release/patch, P2 = next patch, P3 = next major, P4 = backlog. A project with no
+release train maps the letters and skips the vehicle. A "no open `[#A]` bugs"
+release gate therefore means "no open P1."
+
+Each project still defines, in its scheme header, what
+Critical/Major/Minor/Cosmetic and the frequency rows mean *for its own
+codebase* — the bands are concrete per codebase, but the matrix structure and
+the letter mapping are fixed.
+
+**Severity-alone carve-out:** privacy or security leaks, compliance violations,
+and safety issues are graded on severity alone — one occurrence with the right
+consequences is a showstopper no matter how rarely it would be hit.
+
 ## The Rule
 
 A todo entry has two parts: