stolperstein: a checker nobody calls belongs to the same class as no checker

The finding said rules without machine contradiction go unfollowed. Today showed
the sharper version: judge.py exists, contradicts deterministically, and was run
on none of the seven ledgers written that day until asked. First run: 26 findings
across three of them, all from the later part of the session.

That devalues the obvious remedy. Building a tool is not enough while calling it
stays voluntary — the contradiction has to be unavoidable, tied to a step the
work passes through anyway, rather than to the memory of whoever writes. The AAR
obligation failed the same way on the same day, losing to a more convenient
reading in a template comment rather than to ignorance.
This commit is contained in:
Thore Cimbal
2026-08-21 12:00:00 +00:00
parent ea13f71ac6
commit 6a520c86e3
@@ -102,3 +102,46 @@ Was **nicht** hilft: die Regel nochmals irgendwohin schreiben. Sie steht bereits
Stellen, und beide wurden gelesen — siehe
[„Meldet Erfolg, ist aber blind"](meldet-erfolg-ist-aber-blind.md)
für die verwandte Klasse und **FB-08**.
---
## ⚠️ Nachtrag 2026-08-21 — die schärfste Form: das Werkzeug **gibt** es, und es wird nicht aufgerufen
Der Befund lautete bisher: *Regeln ohne maschinellen Widerspruch werden nicht
befolgt.* Am 2026-08-21 trat eine Variante auf, die schlimmer ist, weil sie die
naheliegende Abhilfe entwertet.
`scripts/judge.py` **existiert**, prüft Ledger deterministisch gegen die Regeln
des Rahmenwerks und widerspricht sehr wohl. An diesem Tag entstanden sieben
Ledger. Der Richter wurde auf **keines** davon angesetzt — bis sorb fragte, ob
alles gemäß Rahmenwerk dokumentiert sei.
Das Ergebnis der ersten Ausführung: **26 Befunde** über drei Ledger. Alle drei
stammen aus dem *späteren* Teil derselben Sitzung; die vier aus dem früheren
Teil waren sauber. Es war also kein Missverständnis der Regel, sondern ein
Nachlassen der Form im Verlauf — und nichts hat es gemeldet, weil der
Widerspruch zwar bereitstand, aber nie ausgelöst wurde.
Die drei Fehlerarten waren:
| | |
|---|---|
| Gates absteigend gelistet | die Vorlage sagt „one row per gate **as it closes**" |
| Leiter-Sprossen mit `reused:` ohne Commit | in einem geschlossenen Ledger zählt das als `pending` |
| Eine Zeile für ein **nicht geschlossenes** Gate | eine Behauptung ohne Beleg — genau das, was ein Ledger verhindern soll |
**Was das am Befund ändert.** Bisher lautete die Abhilfe sinngemäß „bau ein
Werkzeug dagegen". Dieser Fall zeigt, dass ein vorhandenes Werkzeug **nicht
genügt**, solange sein Aufruf selbst unbewacht ist. Der Widerspruch muss nicht
nur existieren, er muss **unausweichlich** sein — an einen Schritt gebunden, den
der Ablauf ohnehin durchläuft (Commit-Hook, CI-Job, Gate-Abschluss), nicht an
die Erinnerung dessen, der schreibt.
Dieselbe Struktur am selben Tag ein zweites Mal: die AAR-Pflicht
([[aar-pflicht-ohne-werkzeug]]) unterlag nicht mangels Kenntnis, sondern weil
ein Nebentext eine bequemere Lesart anbot. Beide Male stand die Regel richtig
da. Beide Male fehlte der Zwang, sie einzulösen.
**Erntewürdig ist deshalb die Verschärfung:** Ein Prüfwerkzeug, dessen Aufruf
freiwillig ist, gehört zur selben Klasse wie eine Regel ohne Werkzeug — es
erzeugt nur den zusätzlichen Anschein, das Problem sei gelöst.