Triple-Loop Debrief Review

1. Fix the mistake (single-loop) — a validator FAILs a PR; the seat
   iterates; re-validation passes. Routine by design.
2. Fix the system that produced it (double-loop) — casualties become
   candidate: lines, which become policy; the debrief legislates so the
   class of mistake dies, not the instance.
3. Fix how the fixing works (triple-loop, the meta-skill) — did the
   learning machinery itself perform? What would have caught this sooner,
   cheaper, or without escalating to the maintainer?

A debrief that only answers loop 1 is a log, not learning. Every debrief
should name, even briefly: what did the learning machinery itself do this
session, and did it work?

This is not a new value — it is canon/values/trust-kernel ("Trust Is Built
by Managing Expectations") gaining a standing instrument. Declared
expectations are promises with a shape; triple-loop review is the audit that
keeps the promise about the learning process itself honest, not just the
promise about any single outcome.

Triple-loop insight only surfaces when a human happens to notice it (e.g., a
bridge-fix vs. architecture-fix distinction). The class of catch does not
scale past the attention of whoever is watching that day.