P0012: Learning to Learn is the meta-skill — triple-loop debrief review method (best-evidenced seed: 5 same-day receipts, 2 repos)

[git-repo-auth]

Promotion from the first distillation sweep (C1, successor charter, 2026-07-20). Drafted by sweep flight run_fb133d81, transplanted by the dispatch seat (klappy.dev push refused to the flight — documented fallback). Patch was git apply --check verified against main. Merging is the maintainer's alone (M3) — defer and reject are legitimate outcomes and each promotion's Evidence section says so honestly.

Full report + kirigami foldout: docs/reports/2026-07-20-first-distillation-sweep.md on sweep/2026-07-20-first-distillation in outcomes-driven-development.

---

---

uri: klappy://docs/promotions/P0012-learning-to-learn-triple-loop-review
title: "P0012: Learning to Learn Is the Meta-Skill — Make Triple-Loop Review a Standing Debrief Question"
audience: docs
exposure: nav
tier: 3
voice: neutral
stability: evolving
tags: ["promotions", "proposed", "learning-to-learn", "trust-kernel", "debrief", "meta-skill"]
promotion_status: proposed

P0012: Learning to Learn Is the Meta-Skill — Make Triple-Loop Review a Standing Debrief Question

Learning to learn from mistakes is a meta-skill, not an emergent nicety of good process, and the program should treat it as first-class. Concretely: every debrief should answer three questions, not one — what did we learn (single-loop: fix the mistake), what law prevents the class (double-loop: fix the system that produced it), and did the learning machinery itself perform (triple-loop: fix how the fixing works). A debrief that only answers the first is a log, not a learning event.

Observed Pattern

Debriefs today reliably capture single-loop learning (fix the mistake) and, increasingly, double-loop learning (candidate lines → policy amendments, e.g. dispatch-flight-rules). What is not yet a standing question is triple-loop review: whether the learning machinery itself — the debrief format, the candidate-line duty, the validator posture — performed, or whether it would have caught the same class of miss sooner, cheaper, or without escalating to the captain.

• Affects: every debrief across every flight/session in this program
• Outcome without the standing question: the program keeps fixing instances and classes, but never audits whether its own learning apparatus is improving; triple-loop insight (e.g., the corpus incident's caching-architecture reversal) currently happens only when a captain personally catches it, not as a routine debrief question

Evidence

All observations below are drawn from one calendar window (2026-07-18 evening
→ 2026-07-19 ~04:50Z) but span distinct events, distinct repositories, and
distinct mechanisms — treated here as independent occurrences of the pattern,
not a single incident, per the sweep's judgment that same-day-but-distinct
qualifies. Flagged honestly: none of these observations spans multiple
calendar days, which is a weaker independence bar than e.g. P0002's six
cross-repo occurrences.

Validation Session	Date	Outcome	Notes
ARS dispatch-flight-rules policy, same-day casualty→law	2026-07-18/19	Double-loop success	Casualties → candidate: lines → policy merged same-day (commit 0abf04d); the debrief legislated so the class of mistake dies, not the instance
Validators failing their own author twice	2026-07-18/19	Triple-loop signal	PR #101 (api-listing scope) and PR #104 (three findings) — fresh-context validators correctly FAILed the authoring seat's own work; the check-the-checker layer performed
Guards catching their creators within seconds	2026-07-18/19	Triple-loop signal	Un-baked corpus guard flagged its own author's missing frontmatter; the pinned-list test guarded the guard itself
Cross-seat debrief-driving-fix	2026-07-18/19	Triple-loop success	A cowork seat's debrief drove a second seat's production fix (corpus outage RCA) — the debrief functioned as inter-seat learning transfer, not just intra-seat record
Captain's bridge-vs-architecture catch	2026-07-19	Triple-loop success (human-in-loop)	Seat proposed a workaround (auto-mirror machinery) to stabilize a bug; captain identified the deeper question (should the second source of truth exist at all), producing PRD corpus-self-serve-v1 within the hour — the fastest triple-loop turnaround observed, but currently requires the captain's personal attention rather than a standing debrief question

Total observations: 5
Independent occurrences: 5 distinct mechanisms/events within one session window, across 2 repos (ARS, and the corpus/PRD work); no cross-sess

---

Note

Low Risk
Documentation-only: new method guidance and a promotion record with no gates, code paths, or enforcement changes.

Overview
Introduces triple-loop debrief review as active canon under canon/methods/, framing debriefs as three loops (fix the mistake, legislate the class, audit the learning machinery) with a standing question tied to trust-kernel, not a new value.

Adds docs/promotions/P0012 with observed pattern, five same-window evidence rows, proposed language that matches the landed canon file, low-risk assessment, and sweep provenance. The promotion Status section records that the canon text was already extracted verbatim on captain merge instruction while frontmatter still marks promotion_status: proposed and lists proposed under Status—reviewers should treat that as documentation drift to reconcile, not new runtime behavior.

^{Reviewed by Cursor Bugbot for commit 635100b. Bugbot is set up for automated code reviews on this repo. Configure here.}

[github-actions]

Canon Quality — Frontmatter Schema ✅

All 50 file(s) in writings/ conform to klappy://canon/meta/frontmatter-schema.

_{Validator: scripts/validate-frontmatter.py · Canon: klappy://canon/constraints/frontmatter-validation-before-merge · Run: #403}

[github-actions]

Canon Quality — Homepage Surfacing ✅

50 essay(s) scanned. Soft report — never blocks; the hard field gate is the Frontmatter Schema job.

All published essays resolve to the homepage feed.

_{Report: scripts/surfacing-report.py · Canon: klappy://canon/constraints/frontmatter-validation-before-merge}

[github-actions]

Canon Quality — P0010 Retrieval-Readiness ⚠️

Soft report for klappy://canon/constraints/retrieval-disclosure-contract. 706 files scanned. Never blocks — informational until the corpus is ready to enforce.

• Blocking-class findings: 15 (structural fields the contract would filter on)
• Warnings: 0 (kind resolves to unknown)
• Informational: 13 (exempt templates/archive/drafts)

Kind distribution: {'essays': 52, 'canon': 244, 'apocrypha': 38, 'docs': 306, 'journals': 60, 'unknown': 6}
Kind source: {'path': 571, 'frontmatter': 129, 'none': 6} (frontmatter-primary, path-secondary)
Default-include visibility: 602 visible, 104 hidden (journals/apocrypha/unknown)

By rule: {'audience-invalid': 2, 'exposure-missing': 5, 'tier-missing': 5, 'tier-invalid': 7, 'fm-missing': 3, 'kind-unresolvable': 6}

These are not schema violations (see the Frontmatter Schema job for those on writings/). They are corpus-readiness signals for the retrieval contract: invalid/missing audience, exposure, tier, and docs whose kind cannot be resolved. Fix in a corpus-cleanup PR before the contract flips to enforcing. See the retrieval-readiness-findings artifact for the full list.

_{Validator: scripts/audit-retrieval-readiness.py · Constraint: klappy://canon/constraints/retrieval-disclosure-contract · Run: #403}

[github-actions]

Canon Quality — oddkit_audit ✅

No dead klappy:// references or legacy link patterns found in writings/. 52 files scanned.

_{Spec: klappy://docs/oddkit/specs/oddkit-audit · Workflow: .github/workflows/canon-quality.yml · Run: #403}