Layer 8Ehrlicher Tech-Support

// set -euo pipefail

Methodik

Jede Technikseite im Netz behauptet, sorgfältig zu sein. Das ist wohlfeil – es kostet nichts, es zu sagen. Deshalb steht hier nicht, dass wir sorgfältig sind, sondern woran das scheitern würde, wenn wir es nicht wären.

811
Fehler
4457
Lösungsschritte
1072
reale Befehle
2315
beantwortete Fragen
159
echte Fehlercodes

Der Anspruch

Auf dieser Seite darf nichts stehen, was nicht stimmt. Kein erfundener Befehl, kein ausgedachter Pfad, keine Fehlermeldung, die es so nie gab. Der Ton ist trocken und gelegentlich boshaft – die Technik darunter ist es nicht.

Das ist leicht gesagt. Der ehrliche Teil ist die Frage, was passiert, wenn sich trotzdem ein Fehler einschleicht. Und die Antwort lautet: Bei den meisten Dingen würde es niemand merken. Deshalb sind die wichtigsten davon so gebaut, dass sienicht mehr von Sorgfalt abhängen.

34 Prüfungen, die den Build abbrechen

Diese Seite wird nicht live geschrieben – sie wird gebaut. Und beim Bauen laufen Prüfungen, die den gesamten Vorgang mit einem Fehler abbrechen, statt etwas Falsches zu veröffentlichen. Eine kaputte Seite fällt sofort auf. Eine Seite mit einer stillen Unwahrheit nicht. Also ist Abbrechen die freundlichere Variante.

  1. 1.

    Der Changelog muss zum echten Bestand passen.

    Die Changelog-Seite vergleicht beim Bauen die Zahl im neuesten Eintrag mit der tatsächlichen Anzahl der Fehlerseiten. Weichen sie voneinander ab, bricht der Build ab. Ein veralteter oder geschönter Changelog kann nicht online gehen.

    src/pages/changelog.astro
  2. 2.

    Jeder Mythos braucht eine belegende Fehlerseite.

    Jede Behauptung im Faktencheck verweist auf einen ausführlichen Eintrag. Zeigt ein Verweis ins Leere, bricht der Build ab. Eine Aussage ohne Beleg ist damit technisch nicht veröffentlichbar.

    src/pages/mythen.astro
  3. 3.

    Symptome dürfen nur auf reale Ursachen zeigen.

    Jede Symptom-Seite listet Ursachen, die als eigene Fehlerseite existieren müssen. Fehlt eine, bricht der Build ab. Ebenso, wenn ein Symptom weniger als drei Ursachen hätte – eine Seite mit zwei Links ist keine Hilfe.

    src/data/symptome.ts
  4. 4.

    Keine Fehlerseite darf eine Sackgasse sein.

    Verwandte Fehler werden über geteilte Schlagworte berechnet, nicht über das Erscheinungsdatum. Bliebe dabei auch nur ein Eintrag ohne eingehenden Link, bricht der Build ab. Jede Seite ist über den Link-Graphen erreichbar.

    src/lib/related.ts
  5. 5.

    Jedes Verzeichnis muss den ganzen Bestand kennen.

    Eine neue Seite entsteht nicht allein. Sie muss im RSS-Feed stehen, in dessen JSON-Fassung, in der Maschinenliste für Sprachmodelle, in der Sitemap, in der Übersicht, im A–Z-Verzeichnis und auf der Startseite — deren Suche genau über diese Karten filtert, weshalb eine fehlende Karte eine unsuchbare Seite ist. All diese Stellen rechnen selbst, und genau deshalb fiele es nicht auf, wenn eine davon es eines Tages nicht mehr täte: ein Filter, ein slice, eine Bedingung, und ein Verzeichnis liefert stillschweigend zu wenig. Nach dem Bauen wird deshalb am ausgelieferten Ergebnis nachgezählt, nicht an der Absicht. Weicht auch nur ein Verzeichnis von der Zahl der Fehlerseiten ab, bricht der Build ab.

    scripts/register.mjs
  6. 6.

    Keine Seite darf verschweigen, dass sie sich geändert hat.

    Das Änderungsdatum unter jedem Text stammt aus der Git-Historie, nicht aus einer Eingabe. Ein Durchgang korrigierte 70 Altseiten – darunter einen Ratschlag, der Speicherriegel beschädigt, und eine Seite, deren gesamte Begründung physikalisch nicht stimmte. Alle 70 behaupteten danach weiterhin, zuletzt im Juli geändert worden zu sein: Der Text war neu, das Datum alt, und beim Lesen fällt so etwas niemandem auf. Das Werkzeug dazu gab es längst, es lief nur nie von selbst – und an dessen Aufruf muss man jetzt nicht mehr denken. Weicht bei einer Seite das eingetragene Datum vom letzten Commit ab, der sie berührt hat, bricht der Build ab.

    scripts/aktualitaet.mjs
  7. 7.

    Eine Sammelseite muss etwas sammeln.

    Ein Schlagwort bekommt erst ab zwei zugehörigen Fehlern eine eigene Seite. Vorher bekam jedes eine – 1055 von 1545 hingen an genau einem Fehler und zeigten damit nur die Seite, von der man gerade gekommen war: für den Leser eine Sackgasse, für Suchmaschinen eine Beinahe-Dublette. Entstünde doch eine zu dünne Seite, bricht der Build ab. Schlagworte unterhalb der Schwelle bleiben als Einordnung sichtbar, aber unverlinkt – ein Link auf eine nicht erzeugte Seite wäre ein 404.

    src/pages/tag/[tag].astro
  8. 8.

    Kein Fehler ohne Lösung, keine Antwort ohne Frage.

    Das Schema erzwingt zu jedem Eintrag mindestens einen Lösungsschritt, mindestens zwei häufige Fragen, eine Kategorie, einen Schweregrad und ein Datum – und eine Beschreibung von höchstens 155 Zeichen. Was das Schema verletzt, wird nicht gebaut, auch nicht „nur diesmal“.

    src/content.config.ts
  9. 9.

    Kein Thema zweimal.

    Ein Prüfskript vergleicht alle Einträge paarweise auf Titel-, Adress- und Schlagwortähnlichkeit. Bei mehreren hundert Seiten erinnert sich kein Mensch mehr zuverlässig, was schon dasteht – die Maschine schon.

    scripts/dubletten.mjs
  10. 10.

    Kein Glossarbegriff ohne belegende Seite.

    Jeder erklärte Begriff verweist auf den Fehler, der ihn ausführlich behandelt. Zeigt ein Verweis ins Leere, bricht der Build ab. Eine Definition ohne Beleg wäre eine Behauptung.

    src/pages/glossar.astro
  11. 11.

    Kein Fehler ohne Frage im Register.

    Das Fragenregister entsteht aus dem Bestand. Fehlt einem Eintrag die FAQ, hinterließe er hier eine stumme Lücke – der Build bricht ab, bevor das passiert.

    src/pages/fragen.astro
  12. 12.

    Keine Datenschutzerklärung ohne Verantwortlichen.

    Art. 13 Abs. 1 lit. a DSGVO verlangt Name und Kontaktdaten. Fehlt beides, bricht der Build ab. Eine Erklärung, die eine Absicherung nur vortäuscht, ist schlechter als gar keine – sie belegt nur, dass man die Pflicht kannte.

    src/pages/datenschutz.astro
  13. 13.

    Keine Beschreibung über 155 Zeichen.

    Was länger ist, schneidet Google mitten im Satz ab. Der Guard zwingt dazu, den Text zu kürzen – statt ihn zu verstümmeln.

    src/pages/kategorie/[category].astro
  14. 14.

    Dieselbe Grenze, auch hier.

    Genau dieser Fehler stand schon einmal live: Die Beschreibung wurde per slice() gekappt, und in den Suchergebnissen endete der Satz mitten im Wort. Seither wacht auch hier ein Guard.

    src/pages/schwere/[severity].astro
  15. 15.

    Diese Seite prüft sich selbst.

    Sie behauptet oben, jeder Fehler habe eine Anleitung. Stimmt das eines Tages nicht mehr, bricht der Build ab – die Aussage kann nicht unbemerkt falsch werden. Auch die Zahl der hier aufgeführten Prüfungen ist gezählt, nicht getippt.

    src/pages/methodik.astro
  16. 16.

    Jede hier genannte Prüfung muss es wirklich geben.

    Die Liste war zuletzt nur eine Beschreibung: Sie zählte Behauptungen über Prüfungen, nicht die Prüfungen selbst. Jetzt liest der Build jede genannte Datei und verlangt darin einen echten Abbruch. Verschwindet eine Prüfung oder wandert sie in eine andere Datei, bricht der Build ab – diese Liste kann nicht länger etwas versprechen, was der Code nicht hält.

    src/pages/methodik.astro
  17. 17.

    Jede genannte Prüfung muss beim Bauen auch laufen.

    Eine Prüfung zu besitzen ist nicht dasselbe, wie sie auszuführen. Die Dublettenkontrolle stand lange auf dieser Liste, war aber ein Skript, das der Build nie aufrief – sie brach nichts ab. Jetzt hängt sie im build-Befehl der package.json, und diese Regel prüft, dass sie dort auch bleibt. Eine Kontrolle, die nicht läuft, ist Dekoration.

    src/pages/methodik.astro
  18. 18.

    Die 155-Zeichen-Grenze gilt für jede Seite, nicht nur für die Fehler.

    Zwei Regeln weiter oben steht, dass keine Beschreibung länger als 155 Zeichen sein darf. Durchgesetzt war das im Schema der Fehlerseiten und auf den Kategorie- und Schwere-Seiten – überall dort, wo jemand beim Schreiben des Guards daran gedacht hatte. Fünf handgeschriebene Seiten rissen die Grenze trotzdem, darunter die Startseite mit 160 Zeichen. Google schnitt sie mitten im Satz ab. Jetzt prüft das gemeinsame Layout jede Seite, die durch es hindurchgeht: alle 811 Fehlerseiten, jede Registerseite, jede künftige. Ein Guard, der nur die Fälle prüft, an die man gedacht hat, prüft die falsche Menge.

    src/layouts/BaseLayout.astro
  19. 19.

    Kein Text unter 4,5:1.

    Dunkle Seiten verführen zu blassem Text. Die Textfarbe dieser Seite schafft auf dem Hintergrund saubere 5,90:1 – geschrieben wurde aber an 44 Stellen „Deckkraft 70 %", und damit wurden daraus 3,44:1. Betroffen war kein Zierrat, sondern jede Datumszeile, die Labels „Aufwand:" und „Gilt für:", sämtliche Prozentangaben der Statistik und beide Suchfelder. Man sieht so etwas nicht – lesbar ist es ja, für den, der es geschrieben hat, auf einem guten Monitor. Also wird es nicht angeschaut, sondern nachgerechnet: Jede Farb- und Deckkraftkombination im Quelltext wird gegen den ungünstigsten Hintergrund nach der WCAG-Formel geprüft. Unter 4,5:1 bricht der Build ab. Ausgenommen ist nur, was aria-hidden trägt und damit ohnehin niemand vorgelesen bekommt.

    scripts/kontrast.mjs
  20. 20.

    Kein neuer Fehler ohne Beleg – und nur aus Primärquellen.

    Diese Datenbank nannte sich 400 Einträge lang „verifiziert" und führte keine einzige Quelle. Verifiziert wogegen? Seit dem 1. August 2026 gilt: Jeder neu veröffentlichte Eintrag braucht mindestens einen Beleg, sonst bricht der Build ab. Und jeder Beleg muss aus einer Allowlist von Primärquellen stammen – Hersteller, Standard, Gesetz. Ein Blog oder ein Forenpost mag recht haben, ist aber selbst nur eine Behauptung: Er kann morgen anders lauten. Der Altbestand ist ausgenommen, weil er sonst schlagartig unbaubar wäre – eine Übergangsfrist, kein Freibrief.

    src/lib/quellen.ts
  21. 21.

    Jeder Commit-Hash im Changelog muss es wirklich geben.

    Der Changelog verspricht seit dem ersten Tag: „Die Hashes sind nachprüfbar." Geprüft hat das nie jemand. Am 14. Juli schrieb ein Rebase drei Commits neu, die Hashes änderten sich, und der Changelog verwies auf Objekte, die in der Historie nicht mehr standen – wer „git show" getippt hätte, wäre ins Leere gelaufen. Ausgerechnet hier. Jetzt prüft der Build jeden Hash gegen die echte Historie, und zwar mit „is-ancestor", nicht bloß auf Existenz: Nach einem Rebase liegen die alten Objekte noch im Reflog und würden eine schwächere Prüfung täuschen.

    scripts/changelog-hashes.mjs
  22. 22.

    Ein Befehl, der so nicht funktioniert, ist keine Anleitung.

    Diese Seite verspricht weiter unten, es werde kein Text veröffentlicht, dessen Befehle nicht real existieren – „der Befehl, nicht seine Idee". Das war eine Absichtserklärung, und sie hielt nicht: Am 14. Juli standen drei sachliche Fehler in den Anleitungen. „sc config X start=disabled" bricht ab, weil sc.exe ein Leerzeichen hinter dem Gleichheitszeichen verlangt. Die 5-GHz-Kanäle 149 bis 165 wurden als Lösung empfohlen – eine US-Regel; in Deutschland sind sie für WLAN gar nicht zugeteilt. Und ein „curl http://…:9000" gegen PHP-FPM kann nie antworten, weil dort FastCGI lauscht und kein HTTP: Der Leser hält den gesunden Dienst dann für tot. Gefunden wurden alle drei von Hand, und das ist der eigentliche Fehler – die nächste Seite hätte sie wieder gemacht. Jetzt prüft der Build jeden Befehl gegen diese vier Regeln. Die vierte betrifft rm -rf /, dd auf ein Blockgerät, mkfs und chmod -R 777: Sie dürfen nur dort stehen, wo die Seite als „Systemzerstörend" eingestuft ist und unmittelbar davor warnt. Ein zerstörerischer Befehl ohne Warnung ist kein Ratschlag, sondern eine Falle.

    scripts/befehle.mjs
  23. 23.

    Jede Seite muss ein vollständiges Suchergebnis abgeben.

    Der Wunsch, bei einer Suche weit oben zu stehen, ist verständlich — und der ehrliche Teil der Antwort lautet: Das kann niemand zusagen. Die Reihenfolge macht eine fremde Firma nach Regeln, die sie nicht vollständig veröffentlicht und laufend ändert. Was in eigener Hand liegt, ist etwas anderes: dass jede Seite ein sauberes Ergebnis abgibt, wenn sie denn angezeigt wird. Genau das ist messbar, also wird es gemessen statt behauptet. Nach dem Bauen liest diese Prüfung jede fertige Seite und verlangt: einen Titel, der nicht abgeschnitten wird, eine Beschreibung in brauchbarer Länge, genau eine Hauptüberschrift, eine Sprachauszeichnung, ein Vorschaubild — und strukturierte Daten, die gültiges JSON sind, denn kaputte werden von Suchmaschinen stillschweigend ignoriert, und niemand merkt es. Ein Fund gleich beim ersten Lauf: 143 Titel wurden abgeschnitten, und zwar nicht wegen ihrer Länge, sondern wegen des angehängten Markennamens. Elf Zeichen, die in über hundert Fällen genau das verdrängt haben, was den Leser interessiert — das Ende des Titels, wo bei einer Fehlerseite meist die Lösung steht. Der Anhang entfällt jetzt, wo er schadet. Die verbliebenen 21 zu langen Titel werden nicht verstümmelt: Ein Titel, der den Fehler genau benennt, ist mehr wert als einer, der in eine Zeichengrenze passt. Aber ihre Zahl darf nicht wachsen, dafür sorgt eine Sperrklinke — und sie hat sofort gegriffen, als ein neuer Themenblock sechs zu lange Titel mitbrachte. Am 15.10.2026 sank die Zahl auf 20, weil ein Titel bei einer inhaltlichen Berichtigung kürzer wurde; die Sperrklinke wurde im selben Zug mitgesenkt, denn sie darf nur fallen. Und weil auch diese Regel ihre Geschichte hat: Sie stand nach ihrer Einführung beinahe wieder nicht auf dieser Liste. Aufgefallen ist es nur, weil die gerechnete Wächterzahl nicht zur gebauten passte.

    scripts/suchergebnis.mjs
  24. 24.

    Jede Seite muss von der Startseite aus erreichbar sein – ohne bis zum Fuß zu scrollen.

    Diese Prüfung gibt es, weil ein Leser gemeldet hat, das Quellenregister sei nicht zu finden. Er hatte recht, und es war schlimmer: Die Seite war von der Startseite ausschließlich über den Fuß erreichbar, hinter allen Fehlerkarten, und in der Navigation kam sie gar nicht vor. Dasselbe galt für den Einstieg über das Symptom – ausgerechnet den einzigen, der ohne Vorwissen funktioniert. Bemerkenswert daran ist nicht der Fehler, sondern dass ihn keine der anderen Prüfungen fangen konnte: Sie prüfen alle Eigenschaften von Seiten – Beschreibung, Kanonisierung, Befehle, Belege – und keine prüft Wege zu Seiten. Selbst der Test auf tote Links half nicht; er bestätigt, dass alle Links funktionieren, nicht dass jemand sie findet. Eine grüne Prüfung ist kein Beweis für etwas, das die Prüfung gar nicht ansieht. Jetzt liest der Build nach dem Bauen die fertige Startseite und verlangt für jede eigenständige Seite einen Link oberhalb des Fußes. Wer eine Ausnahme will, trägt sie mit Begründung ein; derzeit gibt es neun, darunter die Datenschutzerklärung, weil der Fuß für sie tatsächlich der richtige Ort ist, und die Offline-Seite, zu der man gelangt, indem die Verbindung wegbricht – ein Link dorthin wäre sinnlos, denn wer ihn anklicken kann, braucht sie nicht. Zur Ehrlichkeit gehört die Grenze: Die Prüfung sieht, OB ein Weg existiert, nicht ob er auffällt. Ob jemand ihn findet, beantwortet kein Skript – das beantwortet ein Mensch, der die Seite zum ersten Mal sieht. Dieser Hinweis kam von außen, nicht vom Build, und das wird beim nächsten Mal wieder so sein.

    scripts/erreichbarkeit.mjs
  25. 25.

    Wer eine Quelle führt, muss sagen, wann er hingesehen hat.

    Ein Beleg ohne Zeitpunkt behauptet stillschweigend, immer zu gelten. Quellen ändern sich, verschwinden, werden umgeschrieben — deshalb steht auf jeder Fehlerseite, wann jemand zuletzt wirklich hineingesehen hat. Dreizehn Einträge trugen eine Quelle und kein Prüfdatum; alle stammten aus der ersten Belegwelle, bevor es das Feld gab, und umgekehrt gab es keinen einzigen Fall. Gefunden wurde das nicht vom Build, sondern beim Durchzählen von Hand — kein Wächter hatte danach gesehen. Jetzt bricht der Build ab, sobald eine Quelle ohne Datum auftaucht. Und weil diese Regel ihre eigene Entstehungsgeschichte hat: Sie stand nach ihrer Einführung einen Tag lang nicht auf dieser Liste. Die Prüfung existierte, die Seite verschwieg sie. Das ist der dritte Fall derselben Sorte, und er hat einen strukturellen Grund — siehe die Regel direkt darunter.

    src/lib/quellen.ts
  26. 26.

    Diese Liste kann zu wenig behaupten, und das ist ihre bekannte Schwäche.

    Zwei Regeln weiter oben stehen die beiden Selbstprüfungen: Jede hier genannte Prüfung muss es wirklich geben, und sie muss beim Bauen auch laufen. Beide sichern dieselbe Richtung — dass hier nichts steht, was es nicht gibt. Die Gegenrichtung sichern sie nicht: Ein Wächter, der eingebaut, aber nie in diese Liste eingetragen wird, fällt niemandem auf. Genau das ist inzwischen dreimal passiert, zuletzt bei der Regel direkt darüber. Der Fehler ist harmloser als sein Spiegelbild — die Seite verspricht dann weniger, als der Code hält —, aber er ist derselbe Mechanismus, und eine Methodikseite, die ihn verschweigt, wäre wieder genau das, was sie anderen vorwirft. Automatisch schließen lässt er sich nicht sinnvoll: Nicht jeder Abbruch im Code ist eine Prüfung, die hierhergehört, und eine Zählung von Abbrüchen würde nur eine neue Zahl erzeugen, die niemand nachrechnet. Was hilft, ist die Gewohnheit: Wer einen Abbruch einbaut, trägt ihn hier ein — und wer diese Liste liest, weiß jetzt, dass sie eine Untergrenze nennt und keine Vollzähligkeit.

    src/pages/methodik.astro
  27. 27.

    Die Belegseite darf keine Vollständigkeit ausweisen, die es nicht gibt.

    Das Quellenregister listet jeden Beleg dieser Seite auf. Eine solche Seite ist die gefährlichste im ganzen Projekt, denn sie stellt anderen ein Zeugnis aus – und wer das tut, wird als Erstes selbst geprüft. Drei Abbrüche hängen deshalb daran. Der erste bricht den Build, wenn ein Eintrag ab dem Stichtag ohne Quelle dasteht: Die Prüfung gibt es zwar schon, aber ohne diesen zweiten Riegel würde ausgerechnet die Belegseite die Lücke hübsch verpackt verschweigen, statt sie auszuweisen. Ein Register, das Fehlendes nicht kennt, ist ein Prospekt. Der zweite bricht ab, wenn eine Quelle von einer Domain kommt, die nicht auf der Positivliste steht – doppelt geprüft, weil diese Seite die Liste öffentlich behauptet und wer sie liest, sich darauf verlassen können muss. Der dritte bricht ab, wenn es überhaupt keinen Beleg gäbe; dann wäre die Seite ein leeres Versprechen. Und weil diese Regel selbst eine Behauptung ist: Sie stand einen Tag lang nicht auf dieser Liste, obwohl es die Wächter schon gab. Die Ehrlichkeitsseite hat also zwischenzeitlich weniger behauptet, als sie prüft – der umgekehrte Fehler von dem, den sie sonst jagt, aber derselbe Mechanismus.

    src/pages/quellen.astro
  28. 28.

    Keine Seite darf unbemerkt schwer werden.

    Siebenundzwanzig Prüfungen liefen hier, und keine einzige hatte je gemessen, wie groß die ausgelieferten Seiten eigentlich sind. Das ist kein Zufall: Alle anderen prüfen Eigenschaften, die man beim Schreiben einer Seite sieht – Titel, Beschreibung, Kontrast, Belege. Die Größe sieht man nicht. Sie entsteht nebenbei, wächst mit jedem Eintrag und fällt niemandem auf, weil auf dem eigenen Rechner alles sofort da ist. Beim ersten Lauf war die Startseite 1,07 Megabyte groß und trug 633 Fehlerkarten – nichts davon hatte jemand entschieden, es war schlicht das Ergebnis von Wachstum. Die ehrliche Fassung dieser Zahl braucht zwei Angaben, und deshalb nennt diese Prüfung zwei: Übertragen wird komprimiert, das sind aus 1,07 Megabyte etwa 157 Kilobyte, also über die Leitung kein Drama. Was das Komprimieren nicht wegnimmt, ist die Arbeit im Browser – ein Megabyte bleibt nach dem Auspacken ein Megabyte, das zerlegt und gesetzt werden muss, und diese Kosten trägt das Gerät des Lesers, nicht der Server. Eine einzelne Zahl hätte hier zwangsläufig gelogen, entweder durch Dramatisieren oder durch Verharmlosen. Gemessen wird beides, je Seite, am fertigen Ergebnis. Die Grenze ist eine Sperrklinke, kein Verbot: Sie verlangt nicht, dass Seiten kleiner werden, sondern dass niemand unbemerkt darüber hinauswächst. Zwei Seiten sind begründet ausgenommen, weil ihre Größe ihr Zweck ist – das Fragenverzeichnis und das Quellenregister; Letzteres kürzen hieße, die Rechenschaft kürzen. Die eigentlich nützliche Zahl ist aber keine Grenze, sondern der Wachstumssatz: was jeder weitere Eintrag kostet und wie viele davon noch hineinpassen. Damit meldet die Prüfung das Problem, bevor es eines ist. Und weil sie zwei Stände miteinander verrechnet – die gebaute Seite und den heutigen Bestand –, weigert sie sich, überhaupt zu teilen, wenn beide nicht zusammenpassen. Eine Zahl aus zwei Zeitpunkten sieht richtig aus und ist es nicht; genau so ist in diesem Projekt schon einmal eine falsche Angabe bis in eine Veröffentlichung gewandert.

    scripts/gewicht.mjs
  29. 29.

    Die Suche muss auch etwas finden — und Unsinn nichts.

    Die Prüfung direkt darunter stellt sicher, dass die Suche den ganzen Bestand KENNT. Das ist Vollständigkeit und sagt nichts darüber, ob sie auch etwas FINDET. Eine Suche kann jede Zeile im Index haben und trotzdem unbrauchbar sein — und sie meldet das nicht. Sie liefert einfach schlechte Antworten, und „nichts gefunden" klingt wie eine Auskunft. Diese Prüfung gibt es, weil genau das passiert war. Beim ersten Versuch, die frisch gebaute Suche von Hand zu überlisten, fielen drei Mängel heraus, und keiner davon hätte je einen Build gebrochen. Der schwerste: Eine ausformulierte Frage fand gar nichts. Jedes Suchwort musste treffen, und „warum", „ist", „mein" und „so" treffen nirgends — ausgerechnet die Frage-Suche war damit tot, und sie war der Grund, die beantworteten Fragen überhaupt in den Index aufzunehmen. Der zweite: Bei genau zwei Suchwörtern gab es keine Lockerung, weil die Hälfte von zwei wieder zwei ist; „zertifikat abgelaufen" lieferte null Treffer, obwohl elf Einträge über Zertifikate dastehen. Der dritte war der peinlichste — der Platzhalter im Suchfeld nannte als Beispiel einen Fehlercode, den es hier gar nicht gibt. Jetzt laufen bei jedem Bauen vierzehn echte Anfragen gegen den fertigen Index, jede mit einer Zeichenkette, die im besten Treffer vorkommen muss: ein Fehlercode, ein Tippfehler, ein Umlaut, ein Paragrafenzeichen, zwei ausformulierte Fragen. Dazu drei Gegenproben in die andere Richtung, denn eine Prüfung, die nur bestätigt, ist keine: Unsinn darf nichts finden, ein einzelnes Unsinnswort darf die Lockerung nicht auslösen, und wo strenge Treffer da sind, darf nicht gelockert werden. Damit die Prüfung überhaupt möglich wurde, ist die Bewertungslogik aus dem Seitenskript in ein eigenes Modul gewandert — Code, der nur im Browser eines Lesers läuft, kann niemand nachmessen. Nicht geprüft wird, ob die Reihenfolge unter den Treffern die klügste ist: Das ist Nützlichkeit, keine Nachweisbarkeit, und darüber entscheidet ein Mensch, der etwas sucht, das er noch nicht kennt.

    scripts/suchprobe.mjs
  30. 30.

    Die Suche muss den ganzen Bestand kennen – und jeder Treffer muss existieren.

    Die Volltextsuche ist der erste Zugang zu dieser Datenbank, der nicht sieht, was ohnehin auf der Seite steht: Sie sieht ausschließlich ihren Index. Damit gibt es hier zum ersten Mal ein Verzeichnis, dessen Unvollständigkeit man ihm nicht ansehen kann. Fehlt eine Karte auf der Startseite, fällt eine Lücke auf. Fehlt eine Zeile im Suchindex, sieht man gar nichts – man findet nur etwas nicht, und das unterscheidet niemand von „gibt es nicht". Eine Suche, die stillschweigend zu wenig durchsucht, ist deshalb schlimmer als gar keine: Sie antwortet mit „nichts gefunden", und das klingt wie eine Antwort. Also entscheidet nicht der Index, ob er vollständig ist. Gezählt wird gegen zwei Stellen außerhalb – gegen das Quellverzeichnis, wie viele Einträge es gibt, und gegen den fertigen Bauordner, ob die Seite, auf die eine Indexzeile zeigt, wirklich existiert. Ein Treffer, der ins Leere führt, ist schlimmer als kein Treffer. Geprüft wird außerdem die Reihenfolge der Felder: Der Index speichert jede Zeile als Liste statt als benanntes Objekt, weil sonst dieselben Feldnamen sechshundertmal mitgeschickt würden. Eine verschobene Spalte macht die Suche dann nicht kaputt, sondern falsch – sie zeigte Beschreibungen an, wo Titel stehen sollten, und niemand bekäme einen Fehler zu sehen. Zuletzt die Gegenprobe zur Beleglage: Der Belegfilter der Suche behauptet, welche Einträge eine Quelle haben. Diese Zahl wird nicht aus dem Index geglaubt, sondern in den Dateien nachgezählt. Was die Prüfung nicht kann, gehört dazugesagt – sie stellt Vollständigkeit fest, nicht Nützlichkeit. Ob die Bewertung den richtigen Treffer nach oben sortiert, beantwortet kein Skript, sondern ein Mensch, der etwas sucht, das er noch nicht kennt.

    scripts/suchindex.mjs
  31. 31.

    Ein Schlagwort gehört zu höchstens einem Beruf.

    Seit September 2026 hat diese Sammlung eine dritte Achse: den Beruf. Er ist bewusst keine siebte Kategorie, sondern ein Schlagwort aus einem festen Vokabular – ein Kassensystem ohne Beleg ist Software und Gastronomie zugleich, und eine Kategorie zwänge zur Wahl. Ein Vokabular hat aber eine eigene Fehlerklasse: Steht dasselbe Schlagwort bei zwei Berufen, zählt ein Eintrag doppelt, und die Summe über alle Berufe wird größer als der Bestand, der sie trägt. Zwei Berufe mit demselben Adresssegment überschrieben einander stillschweigend. Beides bricht den Build, bevor es eine Seite wird.

    src/lib/berufe.ts
  32. 32.

    Kein Link auf eine Berufsseite, die nicht gebaut wird.

    Eine Berufsseite entsteht erst ab zwei Einträgen – dieselbe Schwelle wie bei Schlagworten, aus demselben Grund. Das Register könnte trotzdem einen Link auf einen Beruf mit einem einzigen Eintrag ausliefern, und der wäre ein 404, den kein Wächter sähe, weil die Seite selbst ja korrekt nicht gebaut wird. Zwei Stellen müssen dieselbe Schwelle kennen; hier wird geprüft, dass sie es tun. Und weil das Register Vollständigkeit über das Vokabular behauptet, muss die Zahl der gezeigten Berufe – mit Seite, zu dünn, leer – das ganze Vokabular ergeben. Fiele einer zwischen die Filter, stünde er nirgends, und niemand merkte es.

    src/pages/berufe.astro
  33. 33.

    Die Abdeckungskarte muss richtig zählen – und ihre Beispiele müssen existieren.

    Diese Seite antwortet auf den Wunsch, sämtliche Layer-8-Probleme zu erfassen, mit dem Teil, der messbar ist: Abdeckung entlang dreier Achsen, jede Lücke ausgewiesen. Eine Karte, die falsch zählt, ist schlimmer als keine – sie erzeugt Vertrauen, das sie nicht deckt. Deshalb prüft der Build, dass die sechs Technikschichten zusammen den Bestand ergeben, dass keine Achsenbeschriftung doppelt vorkommt und dass jedes Beispiel, das die toten Zonen aus dem Bestand nennen, als Seite existiert. Ausgerechnet der Abschnitt, der sagt, was sich nicht belegen lässt, darf nicht selbst etwas behaupten, das es nicht gibt.

    src/pages/abdeckung.astro
  34. 34.

    Ein Rechtsirrtum wird am Gesetz widerlegt, nicht am Handbuch.

    Dreiundvierzig Einträge tragen das Schlagwort „Rechtslage" und sagen dem Leser, was gilt – bei Pflichten, Fristen, Verboten. Alle dreiundvierzig nannten mindestens eine Rechts- oder Behördenquelle, und niemand hatte das je geprüft; es war Gewohnheit, keine Regel. Ein Herstellerhandbuch steht auf der Positivliste und belegt ein Produkt, aber kein Recht. Seit dem 25.09.2026 bricht der Build ab, wenn ein Rechtslage-Eintrag ohne Gesetz, Verordnung, EU-Recht oder zuständige Behörde unter seinen Belegen dasteht. Weitere Herstellerbelege bleiben erlaubt und sind oft nötig: Das Gesetz sagt, was gilt, der Hersteller, wie man es einstellt. Die Regel wurde eingefroren, solange der Bestand sie noch von selbst einhielt – nicht erst, nachdem der erste Eintrag sie gebrochen hätte.

    src/lib/quellen.ts

Wo alle diese Prüfungen enden

Die 34 Prüfungen oben haben eines gemeinsam, das dort nicht steht: Sie lesen alle denselben Ordner — das Ergebnis des eigenen Bauvorgangs. Zwischen diesem Ordner und dem Bildschirm eines Lesers liegen aber noch zwei fremde Hände, der Hoster und der ihm vorgeschaltete Dienst. Was die dort tun, hat hier lange niemand nachgesehen.

Am 23. August 2026 stellte sich heraus, dass sie etwas tun. Der vorgeschaltete Dienst sucht im ausgelieferten Text nach allem, was wie eine Mailadresse aussieht, und ersetzt es durch einen Platzhalter. Auf einer Kontaktseite ist das nützlich und gewollt. Hier steht dieselbe Zeichenform in Anleitungen — in einem Befehl, der ein Fernarchiv umstellt, in einem Aufruf mit Anmeldenamen, im Erzeugen eines Schlüsselpaares. Ausgeliefert wurde daraus ein Befehl, der sich kopieren lässt und nicht laufen kann. 29 Stellen auf 11 Seiten, die meisten seit Monaten — und der Befehls-Linter konnte nichts davon sehen, denn er liest die Quelle, und die Umschreibung passiert danach.

Aufgefallen ist es durch Zufall: Ein neues Register bündelte die Befehle an einer Stelle, und dort fiel auf, was auf einzelnen Seiten monatelang untergegangen war. Die Umschreibung ist jetzt für alle Seiten außer der Datenschutzerklärung abgeschaltet — dort steht eine echte Kontaktadresse, und für die ist sie genau richtig. Und es gibt seither eine Prüfung, die nicht den Bauordner liest, sondern die ausgelieferte Seite abruft und jede Befehlszeile wörtlich dagegenhält.

Sie steht bewusst nicht in der Liste oben, denn sie bricht keinen Build — sie kann es nicht: Zur Bauzeit gibt es noch nichts Ausgeliefertes, und ein Vergleich mit dem vorigen Stand würde bei jeder echten Änderung falsch melden. Eine Prüfung, die planmäßig falsch meldet, sieht sich nach kurzer Zeit niemand mehr an. Sie läuft deshalb von Hand nach dem Veröffentlichen, und damit ist sie die einzige, an deren Aufruf man denken muss. Das ist ein bekannter Schwachpunkt — die Dublettenkontrolle war einmal genau so ein Skript und brach deshalb lange gar nichts ab. Hier lässt es sich nicht vermeiden, also steht es hier, statt verschwiegen zu werden.

Woher die Zahlen kommen

Jede Zahl auf dieser Seite – auch die 5 oben – wird beim Bauen aus den echten Daten gerechnet, nicht eingetippt. Es gibt keine Stelle, an der jemand „811" hinschreiben könnte, ohne dass es 811 Einträge gäbe. Hier stand übrigens lange die Zahl 385 – als Beispiel gemeint, aber eingetippt, und irgendwann schlicht falsch. Ausgerechnet in dem Satz, der behauptet, hier sei nichts eingetippt. Selbst derChangelog nennt für jeden Tag den damals tatsächlich gezählten Bestand, ermittelt aus den Commits – nicht aus dem, was in den Commit-Nachrichten behauptet wurde.

Seit Kurzem tragen alle 811 Einträge einen FAQ-Abschnitt – das Schema verlangt inzwischen mindestens zwei Fragen je Fehler. Beim Fehlercode ist die Lage anders: Nur 159 der 811 Einträge haben einen, weil längst nicht jedes Problem sich mit einem Code meldet. Ein aufgeblähter Akku wirft keine Meldung. Diese Zahl steht hier, gerade weil sie nicht bei 100 % liegt – eine Methodikseite, die nur Vollständigkeit meldet, wäre keine.

Die unangenehmste Zahl auf dieser Seite ist diese: Von 811 Einträgen führen erst 800 eine Quellenangabe. Diese Datenbank hat sich lange „verifiziert“ genannt und dabei offengelassen, wogegen eigentlich – nach ihrem eigenen Maßstab war das eine Behauptung ohne Beleg. Seit dem 1. August 2026 bricht der Build ab, wenn ein neuer Eintrag ohne Quelle veröffentlicht werden soll; der Altbestand wird von hinten nachgezogen. Die Zahl steht hier, damit sie weh tut, solange sie klein ist.

Nachlesen lässt sich das im Quellenregister: dort steht jeder Beleg, nach Betreiber gruppiert, mit den Einträgen, die daran hängen – und mit derselben unbequemen Zahl obendrüber. Denn ein Beleg, den niemand aufschlagen kann, ist auch nur eine Behauptung mit Fußnote.

Was hier nicht passiert

  • Kein Text wird veröffentlicht, dessen Befehle nicht real existieren. Wo ein Schritt einen Befehl nennt, ist es der Befehl – nicht seine Idee.
  • Keine Panikmache. Wo ein Problem harmlos ist, steht das da, auch wenn ein dramatischer Ton mehr Klicks brächte.
  • Kein Verschweigen von Irrwegen. Der Changelog nennt auch die Entscheidung, die zurückgenommen werden musste.
  • Und kein Faktencheck, der nur widerlegt: Unter denMythen stehen 14Ratschläge, die belächelt werden und trotzdem stimmen.

Wo die Grenzen liegen

Diese Prüfungen erzwingen Struktur, keine Wahrheit. Sie stellen sicher, dass jede Behauptung einen Beleg hat, dass keine Zahl frei erfunden ist und dass keine Seite ins Leere zeigt. Ob ein Lösungsschritt für dein konkretes Gerät der richtige ist, können sie nicht wissen – das kann kein Werkzeug.

Deshalb steht bei den ernsten Fällen immer zuerst, was man lassen soll. Bei verlorenen Daten ist der erste Schritt, das Gerät nicht mehr zu benutzen. Wer das befolgt, hat mehr gerettet als mit jeder Software.