Anhang H — Heuristiken für Codequalität und Benutzbarkeit

Status: GENEHMIGT UND IN PRODUKTION. Es bleibt keine Entscheidung offen: die Form (D-043 und D-044), die Schalter (D-045 und D-046), das Dashboard (D-047) und die Anfangsschweregrade mit dem Gewicht der Barrierefreiheit (D-048, Abschnitt 10) sind entschieden. Das Dokument ist in allen acht Sprachen der Methode veröffentlicht und seine beiden Prompts sind Teil der Prompts-API: von dort verlangt build/prompts.mjs den englischen Text in allen acht byte-identisch, sonst schlägt der Build fehl. Datum: 2026-10-22.

Register der Entscheidungen dieses Anhangs: docs/DECISIONES.md, D-043 bis D-048. Das Compliance-Dashboard (Abschnitt 12) wurde in D-047 mit zwei Kennzahlen entschieden. Die Implementierungsarbeit lebt in PND-002.

1. Was heute fehlt und warum

Stufe 9 misst den Code bereits, und sie tut es mit einem Gate, das nicht durchlässt: ein einziger Formatierer, Größengrenzen (dreihundert Zeilen pro Datei, vierzig pro Funktion), Komplexität pro Funktion, duplizierter Code, toter Code, deklarierte und genutzte Abhängigkeiten, Abdeckung mit Sperrklinke und Mutationstests, wo es echte Nutzer gibt. Die Zahl wird in docs/CODE_QUALITY.md festgehalten. Das ist gelöst.

Nicht gelöst ist die andere Hälfte des Produkts. Ich habe den Korpus der Stufen geprüft: es gibt keine einzige Erwähnung von Benutzbarkeit, von Personen/Profilen oder von funktionaler Gruppierung. Die Oberfläche stützt sich heute auf zwei Dinge: den Screenshot, den der Eigentümer zehn Sekunden ansieht, und die manuellen Testfälle. Beide sind gut, beide sind menschlich, teuer und vergesslich. Ein System kann das Qualitätsgate mit Auszeichnung bestehen und trotzdem unbenutzbar sein: alles grün, und die Person findet nicht, wo sie kassiert.

Und es gibt ein Problem zweiter Schicht, das technisch ist, aber in der Oberfläche sichtbar wird: wenn dasselbe Produkt mehrere Profile nutzen (Verwaltung, Betrieb, Auskunft, Kunde), werden die Funktionalitäten an drei verschiedenen Stellen freigeschaltet — Datenbank, Menü und Routen-Guard —, die zu verschiedenen Zeitpunkten geschrieben werden und sich von selbst entkoppeln. Das Symptom ist immer dasselbe: jemand sieht eine Schaltfläche, die ihm nicht zusteht, oder schlimmer, jemand mit der Berechtigung findet die Bildschirmseite nicht.

Die beiden folgenden Heuristiken greifen diese zwei Dinge mit derselben Form an: ein kurzer Katalog prüfbarer Aussagen, wenige Instrumente, die sie selbst messen, und ein Weg der erklärten Ausnahme für den Fall, dass das Projekt ausbrechen muss.

2. Das Modell: drei Schichten, eine einzige Form der Regel

Die Versuchung ist, eine Regelliste zu schreiben und sie an den Stack des ersten Projekts zu binden. Das altert schlecht: die React-Regel gilt nicht in Angular, die Angular-Regel gilt nicht in einem Server mit Templates, und in zwei Jahren ist die halbe Liste tot. Der Vorschlag trennt drei Schichten.

Schicht 1 — Agnostischer Kern (nicht verhandelbar). Aussagen über Ergebnisse, nicht über Werkzeuge. „Es gibt einen einzigen Formatierer und niemand diskutiert mit ihm" gilt in TypeScript, PHP oder Go gleichermaßen. Der Kern wird mit stabilen Kennungen aufgelistet und ändert sich von Projekt zu Projekt nicht.

Schicht 2 — Adapter pro Stack (konfigurierbar). Für jede Regel des Kerns erklärt jede Frontend-Familie, womit sie gemessen wird und mit welchem Schwellenwert. Ein React-Projekt mit Vite, eines mit Next, eines mit Angular, eines mit Server und Templates, eines mobil und eines auf der Kommandozeile sind sechs verschiedene Adapter desselben Kerns. Hier lebt alles, was der Nutzer als „konfigurierbar pro Frontend" verlangt hat.

Schicht 3 — Entscheidungen des Projekts (erklärt). Die konkreten Schwellenwerte und die Ausnahmen. Sie werden nicht erfunden: sie werden beim Eigentümer erfragt und aufgeschrieben, genauso wie die Dimensionierung in der Architekturstufe. Ist ein Schwellenwert nicht erklärt, gilt der des Adapters, und das wird als solches registriert.

Jede Regel wird immer mit demselben Datensatz aus sechs Feldern geschrieben:

Die Ausnahme wird erklärt, niemals weggelassen. Eine Regel wird mit einem Register aus vier Feldern abgeschaltet: Kennung, Begründung in einer Zeile, wer sie genehmigt (der Eigentümer, nicht der Agent) und Datum der Überprüfung. Eine abgeschaltete Regel ohne Register ist ein Fehler des Gates, keine Entscheidung. Es ist dasselbe Kriterium, das die Methode bereits anwendet, um eine „zum Bestehen" erhöhte Grenze nicht zu akzeptieren.

3. Die vier Instrumente

Keine Heuristik nützt etwas, wenn ihre Prüfung eine Meinung ist. Es sind vier, und jede Regel erklärt, zu welchem sie gehört.

1. Automatisches Gate. Läuft bei jedem Push und beim Schließen eines Blocks. Liefert grün oder rot. Es ist billig, wiederholbar und diskutiert nicht. Es misst alles, was sich zählen lässt.
2. Abfrage der Matrix. Die Matrix der Funktionalitäten pro Profil (siehe B2) ist ein deklaratives Artefakt; Menü, Routing und Berechtigungen werden aus ihr abgeleitet. Die Matrix prüfen heißt die Oberfläche prüfen. Das ist das Stück, das einen Teil der Benutzbarkeit in etwas maschinell Prüfbares verwandelt.
3. End-to-End-Test pro Profil. Für jedes erklärte Profil ein Skript, das als dieses Profil eintritt und die Menge der erreichbaren Funktionalitäten mit der Zeile der Matrix vergleicht: weder weniger noch mehr. Es ist der Test, der die beiden typischen Entkopplungen fängt (die überflüssige Schaltfläche und die fehlende Bildschirmseite).
4. Manueller Fall. Was keine Maschine beurteilt: ob die Gruppierung verständlich ist, ob die Aufgabe ohne Hilfe abgeschlossen wird, ob der Text in der Sprache des Nutzers ist. Er wird mit Personen ausgeführt und registriert, wie es Stufe 10 bereits verlangt.

4. Teil A — Codequalität

Der Kern erweitert Stufe 9: er ersetzt sie nicht und widerspricht ihr nicht, er gibt jedem bereits gemessenen Punkt Namen, Schweregrad und Adapter und fügt hinzu, was heute fehlt — die Oberfläche als Code betrachtet.

Die Regeln CQ-12 bis CQ-18 sind die, die „Codequalität" an der Front bedeutsam machen. Ohne sie kann das Projekt neunzig Prozent Mutation haben und eine Bildschirmseite, die die Summe mit ihrer eigenen Arithmetik in einer Komponente berechnet: das Schlechteste beider Welten, denn die duplizierte Berechnung besteht alle Tests des Backends.

Anfangsschweregrade (D-048). Vom ersten Tag an blockieren die vierzehn Regeln, die einen Prüfer haben und nicht von einem zu diskutierenden Schwellenwert abhängen: CQ-01 bis CQ-06, CQ-08 und CQ-11 bis CQ-17. CQ-09 blockiert, wo es echte Nutzer gibt, denn dort wird gemessen. Es warnen drei, und nur drei: CQ-07 (Typen), CQ-10 (Abhängigkeiten) und CQ-18 (Barrierefreiheit), weil sie verlangen, dass das Projekt zuerst kalibriert. Formatierer, Linter, Größe und Komplexität werden nicht gelockert: Stufe 9 blockiert sie heute bereits, und dies erweitert sie, ersetzt sie nicht; die geerbte Schuld wird mit einer erklärten Ausnahme oder mit der Grundlinie der Sperrklinke gelöst, niemals durch Senken des Schweregrads. Und CQ-12 und CQ-14 sind die beiden einzigen Regeln dieser Tabelle, die mit menschlichem und nicht mit maschinellem Rot blockieren: sie werden beim Abschluss des offenen Punktes geprüft und mit dem manuellen Fall vor Augen, genau wie UX-22 und UX-27, nicht bei jedem Commit. Kann das Projekt diesen Abschluss nicht tragen, sinkt die Regel per registrierter Entscheidung auf WARNT, nicht aus Vergessenheit.

Adapter pro Frontend-Familie. Ein Beispiel, wie Schicht 2 instanziiert wird (die Namen sind illustrativ; das Projekt wählt und schreibt sie):

Was sich zwischen den Spalten ändert, ist das Werkzeug und der Schwellenwert. Was sich nicht ändert, ist die Aussage. Das macht die Heuristik agnostisch, ohne sie dekorativ zu machen.

5. Teil B — Benutzbarkeit

Fünf Familien. Die erste und die zweite sind die, die der Eigentümer ausdrücklich verlangt hat; die anderen drei gibt es, weil ohne sie die Gruppierung und die Profile genauso verfallen, nur langsamer.

B1 — Gruppierung nach funktionaler Konvergenz

Die Mutterregel: eine Funktionalität wird nach dem gruppiert, was die Person zu tun gekommen ist, nicht nach dem Modul, aus dem sie stammt. Der Code organisiert sich nach Entitäten („Rechnung", „Kunde", „Zahlung"); die Personen nicht. Niemand tritt ins System, um „Entitäten zu verwalten": man tritt ein, um zu kassieren, zu versenden, den Monat abzuschließen. Zeigt das Menü die Entitäten, wird die Person zur Übersetzerin. Das Menü ist die Arbeit.

B2 — Profile und pro Profil freigeschaltete Funktionalitäten

Hier liegt das Stück mit dem größten Ertrag, und der Grund ist ein ingenieurtechnischer, kein gestalterischer: die Freischaltung wird einmal erklärt, in einer Matrix, und alles andere leitet sich aus ihr ab. Heute ist der klassische Fehler, die Berechtigung dreimal zu schreiben (im Menü, im Routen-Guard und im Datenfilter) und dass die drei auseinanderlaufen. Mit der Matrix als einzigem Produzenten sind Menü, Routing, Serverberechtigungen und Testskripte Konsumenten, und die Produzenten/Konsumenten-Symmetrie, die die Methode bereits verlangt, wird von selbst prüfbar.

Die Matrix hat vier Spalten und eine Zeile pro Funktionalität: Funktionalität, Zuhause (die Gruppe aus B1), Profile, die sie haben, Einstiegsroute. Nichts weiter.

B3 — Zustände, und was die Person sieht, wenn etwas fehlt

Die meisten Reklamationen von „es geht nicht" sind Bildschirmseiten, die nicht sagen konnten „es gibt nichts", „es lädt" oder „es ist fehlgeschlagen". Vier Zustände, immer, in jeder Liste und jeder Detailansicht.

B4 — Aktionen und Fehler

B5 — Sprache und Barrierefreiheit

6. Wo es einhakt, und welche Artefakte entstehen

Der Anhang erfindet keine neuen Stufen: er hängt sich an die, die es gibt. Das vermeidet doppelte Gates und vermeidet das übliche Schicksal von Benutzbarkeitslisten, nämlich einmal gelesen zu werden.

Wo er hingehört (D-043). Er ist querliegend zu den vier Abschnitten, mit dem Hauptgewicht im Konstruktionszyklus (Stufen 5 bis 12), wo entschieden und gebaut wird. Er ist keine eigene Stufe: eine numerierte Stufe würde die Leiter umnumerieren, die Schrittanzahl verändern und den Anhang der Pflichtübersetzung der Verträge in die acht Sprachen unterwerfen, bevor die Konstruktion grün durchlaufen kann, ohne ein Gate hinzuzufügen, das der Zyklus nicht schon hat.

Wie er einhakt (D-044). Eine kanonische Quelle, fünf Anker und zwei vorherige Eingänge. Der Text der Regeln lebt nur hier und die Prompts zitieren ihn; sie kopieren ihn niemals. Die fünfundvierzig Regeln in die acht Prompts des Zyklus zu wiederholen verwässert sie (sie konkurrieren mit der eigenen Arbeit jeder Stufe und der Agent befolgt sie jedes Mal anders), leitet sie ab (zwei Kopien desselben Textes entkoppeln sich von selbst, was genau das Antimuster ist, das Stufe 11 verfolgt) und macht sie nicht querliegender: querliegend wird eine Regel dadurch, dass jeder Block durch dasselbe Gate geht, nicht dadurch, dass die Regel überall geschrieben steht.

Stand (D-049). Die fünf Anker sind eingehängt: der Eröffnungs-Prompt der Stufen 5, 8, 9, 10 und 12 zitiert diesen Anhang in den acht Sprachen, mit einer einzigen englischen Formulierung, die in allen identisch ist, und ihrer lokalen Übersetzung daneben. Das Dokument wird auf der Website mit dem Rest der Methode in den acht Sprachen veröffentlicht, und seine beiden Prompts sind als Vertrag anexo-h in docs/html/api/prompts.json eingetreten: von dort vergleicht build/prompts.mjs sie byte-identisch in allen acht, sonst schlägt der Build fehl.

Die Stufen 6, 7 und 11 erhalten höchstens eine Zeile: die 6 registriert bereits Schwellenwerte und Ausnahmen als Entscheidungen (es ist der natürliche Ort der erklärten Ausnahme), und die 11 ist die, in der der Fall der viermal geschriebenen Matrix mit voller Wucht eintritt. Ihnen wird kein eigener Text hinzugefügt, um sie nicht zu verwässern.

Drei Artefakte, alle in docs/: CODE_QUALITY.md (erweitert), USABILITY.md (neu, mit dem Ergebnis pro Regel und den erklärten Ausnahmen) und PROFILE_MATRIX.md (die Matrix, die zugleich Dokument und Quelle des Menüs ist).

7. Konfiguration

Eine einzige Datei pro Projekt erklärt Schicht 2 und Schicht 3. Beispiel mit der vorgeschlagenen Form, nicht mit endgültigen Werten:

{
  "version": 1,
  "frontend": "react-vite",
  "gemessen_von": {
    "format": "prettier",
    "lint": "eslint",
    "typen": "tsc",
    "komplexitaet": "eslint-complexity",
    "duplizierung": "jscpd",
    "toter_code": "knip",
    "abdeckung": "vitest-coverage",
    "mutation": "stryker",
    "barrierefreiheit": "axe-core"
  },
  "schwellenwerte": {
    "zeilen_pro_datei": 300,
    "zeilen_pro_funktion": 40,
    "pfade_pro_funktion": 10,
    "mindestabdeckung": 0,
    "mutationsziel": 0
  },
  "ausnahmen": [
    {
      "regel": "CQ-17",
      "begruendung": "geerbter druckbarer Bericht, ohne Tokens",
      "genehmigt_von": "Eigentuemer",
      "pruefen_am": "2027-01-31"
    }
  ]
}

Die beiden Nullen sind absichtlich und sind der Teil, der zählt: die Mindestabdeckung setzt die Sperrklinke mit dem Gemessenen, und das Mutationsziel setzt der Eigentümer, wenn das Projekt Nutzer hat. Stehen sie auf null und hat sie niemand erklärt, meldet das Gate sie als nicht erklärten Schwellenwert, statt ihn zu erfinden.

8. Die beiden Bausteine in der Form, die die Methode nutzt

Codequalität.

Benutzbarkeit.

9. Was dieser Vorschlag nicht tut

• Er fügt keine Stufe hinzu. Es sind fünfundvierzig querliegende Regeln (18 zu Qualität und 27 zu Benutzbarkeit), keine neue Etappe. Sie hängen an den Stufen, die es bereits gibt.
• Er erfindet keine Punktzahl. Eine Zahl „Benutzbarkeit 78" sagt nicht, was zu reparieren ist, und wird in die falsche Richtung optimiert. Es wird pro Regel berichtet. Abschnitt 12 schlägt zwei abgeleitete Kennzahlen vor, aber sie sind eine Auszählung von Regeln mit ihrer Begründung — keine Note für Qualität oder Benutzbarkeit — und sie ermächtigen nicht, irgendetwas zu schließen.
• Er ersetzt nicht den Eigentümer. Der Test des ersten Klicks, der Screenshot und der Aufgabentest bleiben menschlich: sie sind das einzige Instrument, das „es funktioniert" von „es dient" unterscheidet.
• Er bringt keine Schwellenwerte ab Werk. Die des Adapters sind ein erklärter Ausgangspunkt; das Projekt, das seine eigenen nicht erklärt, erbt sie, und das wird als solches registriert.
• Er verspricht nicht, dass das Gate die schlechte Gruppierung erkennt. Eine Maschine kann prüfen, dass es keine Duplizierung und keine Waisen gibt; heißt die Gruppe „Verwaltung", muss es eine Person sehen.

10. Die Entscheidungen: was entschieden wurde und was fehlt

Entschieden

In D-048 geschlossen, und die beiden Korrekturen, die es mitbringt

Die beiden Fragen, die das Schreiben der Prompts blockierten, sind beantwortet: die erste in Zeile 5 und die zweite in Zeile 6. Aber die Empfehlung, die genehmigt wurde, hatte zwei Sachfehler, und sie stehen hier, damit sie nicht zurückkommen:

1. Der Zählfehler. Wo dieser Anhang „siebenundzwanzig Regeln" sagte, ist die richtige Zahl fünfundvierzig: 18 zu Qualität (CQ-01 bis CQ-18) und 27 zu Benutzbarkeit (UX-01 bis UX-27). Die alte Zahl kam aus einem Entwurf, der nur die Hälfte zählte. Korrigiert in den Abschnitten 6 und 9 und in D-048 vermerkt; der Text von D-044 bleibt so erhalten, wie er geschrieben wurde, weil eine Entscheidung ein Register ist und nicht umgeschrieben wird.
2. Formatierer, Linter, Größe und Komplexität werden nicht gelockert. Eine frühere Fassung dieser Empfehlung schickte sie zu „warnt", um Projekte mit geerbter Schuld nicht zu blockieren. Das kann nicht sein: Stufe 9 blockiert sie heute bereits, und diese Erweiterung erweitert sie, ersetzt sie nicht. Die geerbte Schuld wird mit einer erklärten Ausnahme gelöst — mit Begründung und Datum der Überprüfung — oder mit der Grundlinie der Sperrklinke, nicht durch Senken des Schweregrads der Regel.

Und eine erklärte Einschränkung, weil sie die einzige ihrer Art ist: CQ-12 und CQ-14 blockieren mit menschlichem Rot. Kein Werkzeug prüft, dass eine Bildschirmseite keine Geschäftsregeln entscheidet. Sie werden beim Abschluss des offenen Punktes geprüft, mit dem manuellen Fall vor Augen und demselben Kriterium wie UX-22 und UX-27; kann das Projekt diesen Abschluss nicht tragen, sinken sie per registrierter Entscheidung auf WARNT. Eine Regel, die blockiert und die niemand prüft, ist schlimmer als eine Regel, die warnt.

Kalender, keine Entscheidung

Die Übersetzung. Erledigt: der Anhang existiert in den acht Sprachen und seine beiden Prompts sind Teil der Prompts-API, mit byte-identischem englischem Text in allen acht Fassungen (D-043 verlangt es und build/prompts.mjs prüft es bei jedem Build). Das Spanische bleibt das Kanonische: wenn je eine Übersetzung und das Spanische auseinandergehen, gewinnt das Spanische und die Übersetzung wird in derselben Änderung korrigiert.

11. Wie geprüft wird, dass das Gate wirklich wacht

Eine Heuristik, die nichts ändert, wenn man sie ein- oder ausschaltet, ist kein Gate, sondern Dekoration. Die Abnahmeprüfung der Implementierung (PND-002) ist ein Fixture-Projekt mit absichtlichen Verstößen jeder Familie:

Angesehen wird nicht nur die Farbe: angesehen wird, dass die beiden Abschaltzeilen im Bericht existieren. Ein grünes Ergebnis ohne diese Zeile ist der einzige Fehler, den diese Prüfung nicht von selbst an der Farbe erkennt, und deshalb wird sie durch Lesen der Ausgabe geprüft.

12. Das Compliance-Dashboard (ENTSCHIEDEN: zwei Kennzahlen, D-047)

Status. Entschieden am 2026-10-22 in D-047: das Dashboard geht mit zwei Kennzahlen, mit dem Fingerabdruck des Regelwerks, mit Sperrklinke, mit dem Menschlichen außerhalb des Prozentsatzes und mit der Pflichtbegründung. Es ermächtigt nicht, Blöcke zu schließen. Was folgt, ist die Spezifikation, die die Implementierung (PND-002) erfüllen muss.

Was es ist. Ein deterministisches Derivat des Ergebnisses pro Regel, das das Gate bereits ausgegeben hat. Es misst nichts Neues und beurteilt nichts Neues: es zählt. Könnte das Dashboard das Urteil einer Regel ändern, gäbe es zwei Quellen der Wahrheit für dasselbe, und genau das bekämpft der Anhang in UX-10 (die Navigation wird aus der Matrix abgeleitet) und in CQ-14 (ein einziger Ort für den Zustand).

Was es nicht ist. Es ist kein Abnahmekriterium. Keine Kennzahl ermächtigt, einen Block zu schließen: Grün oder Rot entscheidet jede blockierende Regel, eine nach der anderen. Das Dashboard beschreibt die Tendenz und zeigt, was anzusehen ist. Beginnt man, es als Schließschwelle zu nutzen, dient es nicht mehr, denn der kürzeste Weg, eine Zahl zu erhöhen, ist das Abschalten von Regeln.

Zwei Kennzahlen, niemals eine.

Der Grund, dass es zwei sind: eine Regel abzuschalten hebt die Erfüllung und senkt die Abdeckung. Mit einer einzigen Kennzahl ist Abschalten gratis und das Dashboard belohnt Blindheit. Mit zwei Kennzahlen, die sich in entgegengesetzte Richtungen bewegen, verschwindet die Abkürzung: um ein besseres Dashboard zu zeigen, muss Code repariert werden, nicht eine Regel abgeschaltet. Und die Abdeckung lässt sich nicht erhöhen, ohne zu messen.

Der Fingerabdruck des Regelwerks. Jeder Eintrag behält, mit welchem Maßstab er berechnet wurde: Version des Katalogs, aktive und abgeschaltete Regeln, Frontend-Adapter und Werkzeugversionen. Ohne das sind eine 82 von gestern und eine 91 von heute nicht dieselbe Messung, obwohl sie gleich geschrieben werden: es sind zwei verschiedene Regelwerke und die Reihe ist falsch. Zwei Kennzahlen ohne Fingerabdruck erzeugen eine Illusion von Fortschritt, die schlimmer ist als kein Dashboard. Ändert sich der Fingerabdruck, wird der Eintrag als nicht vergleichbar markiert oder die Historie wird mit dem geltenden Maßstab neu berechnet; niemals wird sie ohne diesen Hinweis daneben gezeichnet.

Sperrklinke. Die Erfüllung sinkt von einem Block zum nächsten nicht ohne eine registrierte Entscheidung, die es erklärt. Es ist derselbe Mechanismus, den die Testabdeckung in CQ-08 bereits hat: die Zahl von heute ist der Boden von morgen. Sinken ist nicht verboten; sinken ohne Register schon.

Was nicht in die Rechnung eingeht. Was nur eine Person beurteilen kann — der Test des ersten Klicks (UX-07), der Aufgabentest (UX-06), der Screenshot (UX-27) und alle manuellen Fälle — wird als bestanden oder fehlgeschlagen registriert, pro Block, mit Name und Datum, und getrennt als Abdeckung der menschlichen Prüfung berichtet. Es geht nicht in den Erfüllungsprozentsatz ein. Mischt man sie, ist das Ergebnis eine Zahl, die sechzig Prozent Messung und vierzig Prozent Meinung ist, und niemand kann sagen, was was ist. Deshalb gilt Abschnitt 9 weiter: das Dashboard erfindet keine Benutzbarkeitsnote, es zählt Regeln.

Wie es falsifiziert wird. Erweitert die Abnahmeprüfung aus Abschnitt 11:

Wo es erscheint. Im ehrlichen Bericht der Stufe 12 (Anker 5), und in dieser Reihenfolge: zuerst das binäre Urteil des Gates, dann die zwei Kennzahlen, dann was abgeschaltet ist und bis wann, dann die Bewegung gegen den vorigen Block mit ihrer genannten Ursache. Immer mit der Begründung: sank um vier Punkte: CQ-15, drei Zeichenketten außerhalb des Katalogs auf der Kassiervorderseite. Eine Kennzahl ohne Begründung ist Rauschen; die Begründung ist das, was sie für einen Eigentümer handlungsfähig macht, der keinen Code liest.

Erklärtes Risiko. Das Dashboard wird der Eigentümer lesen, der keinen Code liest, und deshalb wird er wollen, dass es steigt. Die Zahl wird zum Ziel, und das Ziel verdrängt den Zweck. Die Verteidigungen sind die oben, und es sind fünf: zwei Kennzahlen, die sich beim Abschalten widersprechen, der Fingerabdruck, der das Vergleichen verschiedener Maßstäbe verhindert, die Sperrklinke, die ohne Register nicht sinken lässt, das Menschliche außerhalb des Prozentsatzes und die Pflichtbegründung, mit dem Gate, über das nicht per Durchschnitt verhandelt wird. Fällt eine der fünf, wird das Dashboard abgeschaltet: ein schlecht genutztes Dashboard richtet mehr Schaden an, als keines zu haben.

13. Register

Jede Entscheidung dieses Anhangs steht in docs/DECISIONES.md mit Datum, Autor, wörtlichem Zitat und betroffenen Dateien: D-043 (Form), D-044 (Mechanismus), D-045 (Schalter), D-046 (Disziplin des Schalters), D-047 (das Dashboard mit zwei Kennzahlen). Die Implementierung und ihre Abnahmekriterien leben in PND-002.

Es bleibt keine Entscheidung offen: die Form (D-043 und D-044), die Schalter (D-045 und D-046), das Dashboard (D-047) und die Anfangsschweregrade mit dem Gewicht der Barrierefreiheit (D-048) sind entschieden. Der Text reist in den acht Sprachen und ist Teil der Prompts-API, was den einzigen Punkt schließt, der im Kalender stand.