Changelog

Der Melder schrieb fuer JEDEN fehlenden Publish „die Kette meldet gruen, geliefert
wird nichts". Bei `ayoune-google-ads-client` meldete gar keine Kette etwas
(`pipelines_config` 404, 0 Laeufe). Der Satz beschrieb also einen anderen Zustand als
den vorliegenden — und schickte den Folge-Auftrag in die falsche Richtung: er suchte
den Fehler im `|| echo` des Publish-Schritts, waehrend der Schritt nie ausgefuehrt
worden war. ⚠ Diese Vermutung stammte aus MEINEM eigenen Brief; sie war nie gemessen.

Ueber zehn Bibliotheken gemessen: 5 mit eingeschalteter Kette, 4 OHNE Kette und
trotzdem veroeffentlicht (von Hand), 1 ohne Kette und ohne Paket. Die Haelfte hat gar
keine laufende Kette — und das ist offenbar in Ordnung.

Getrennt wird jetzt die URSACHE, nicht die Schwere: die Befund-Klasse bleibt
`paket-fehlt` (Ausstiegs-Vertrag unveraendert, beide Faelle faerben rot), dazu kommt je
Fund ein Feld `chain` und ein eigener Satz. Die Klassen-UEBERSCHRIFT ist jetzt
ursachen-NEUTRAL — der alte Satz steht nur noch dort, wo er zutrifft.

🔴 DREI BEFUNDE UEBER DAS EIGENE WERKZEUG, alle beim Verify aufgefallen:

1. `--registry` war fuer SCOPED Pakete WIRKUNGSLOS. Gemessen:
`npm view @tolinax/ayoune-http --registry https://registry.npmjs.org` liefert
`2026.1.0`, weil `npm config get @tolinax:registry` auf `registry.ayoune.app` zeigt
und eine scope-spezifische Registry ueber `--registry` GEWINNT. Gegenprobe im selben
Lauf: `npm view express --registry …` greift. Der Schalter war also fuer genau die
Pakete blind, fuer die dieser Waechter gebaut ist — und haette jeden Gegen-Lauf
gegen ein anderes Register still verfaelscht. Behoben ueber `npmViewArgs`, das den
Scope aus dem Paketnamen ableitet und `--@scope:registry=` mitgibt (3 Proben).

2. Die 404-ZWEIDEUTIGKEIT: Bitbucket antwortet auf `pipelines_config` mit 404, wenn die
Kette nie eingeschaltet wurde UND wenn es das Repositorium gar nicht gibt. Aus dem
404 allein folgt „nie eingeschaltet" NICHT. Geloest OHNE dritten Abruf: der
Publish-Durchgang laeuft per Bauart nur ueber lokal existierende Verzeichnisse, die
Existenz ist dort belegt und wird durchgereicht. ⚠ Ein erster Anlauf fragte sie per
API nach — und machte aus einem korrekten `kette-nie-gelaufen` ein `unbestimmt`,
sobald jene Abfrage aus einem anderen Grund als 404 fehlschlug. Eine Probe, die
scheitern KANN, darf eine belegte Tatsache nicht ueberschreiben.

3. Der Status-Regex stand als `/API (d{3}) /` statt `\d{3}` in der Datei (der Backslash
ging beim Einsetzen ueber ein Heredoc verloren). Er traf damit NIE, `configStatus`
blieb null, und JEDER Befund fiel auf `unbestimmt` — die ganze Nachschaerfung war
still ausgehebelt, ohne dass eine Probe rot wurde. Die vorhandenen Proben pruefen die
reine Klassifikation; der Regex lag im netzabhaengigen Abruf. Jetzt als reine
`statusFromError` herausgezogen und mit 3 Proben festgenagelt. LEHRE: eine
Zeichenketten-Auswertung gehoert in eine reine Funktion, sonst ist sie per Bauart
ungeprueft.

VERIFY, live gegen Bitbucket (nicht per Fixture):
- `ayoune-google-ads-client` -> `kette-nie-gelaufen` (404 + size=0, unabhaengig gemessen)
- `ayoune-email-blocks` -> `kette-laeuft` (enabled=true, size=9)
- chainCounts zaehlt beide getrennt: {nie-gelaufen 1, laeuft 1, unbestimmt 0}
- Negativ-Kontrolle mit ungueltigen Zugangsdaten: der Melder laeuft durch, meldet den
Registry-Befund und behauptet KEINE Ursache (`unbestimmt`), Ausstieg unveraendert.

Proben +21 (I Ursachen-Klassen · J Registry-Schalter · K 404-Zweideutigkeit ·
L Status-Regex), 84/84 in dieser Datei gruen. Volle Paket-Reihe 4797/8 — dieselben acht
Bestandsfehler wie vor der Aenderung (4776/8 in Iteration 2 gemessen), also +21 Tests,
+21 pass, fail unveraendert: keine Regression.

🟢 NEBENBEFUND: `ayoune-google-ads-client` ist inzwischen VEROEFFENTLICHT — der Brief,
den dieser Waechter am 2026-08-22 erzeugt hat, ist abgearbeitet worden. Der Live-Beleg
oben laeuft deshalb bewusst