#0055: Korrektur - "vollstaendig geschlossen" stimmte nicht

v0.6.0-rc.1 scheiterte am 2026-08-19 mit genau dem 404, den dieses Issue behoben
haben sollte. Die .npmrc stand nie in der COPY-Zeile von apps/web/Dockerfile und
kam im Docker-Build nie an.

Die Abnahme hat gemessen, ob die Konfiguration wirkt, wenn sie vorhanden ist -
nicht, ob sie ueberall ankommt, wo installiert wird. Gutgegangen ist es nur,
weil --frozen-lockfile unter pnpm 10 die gepinnte Tarball-URL nahm und gar nichts
aufloeste; der Schutz kam vom Lockfile, nicht von der .npmrc. pnpm 11 prueft mit
minimumReleaseAgeStrict jeden Eintrag, loest wieder auf und landet ohne .npmrc
bei npmjs. Genau diesen Ablauf sagt die .npmrc in ihrem eigenen Kommentar voraus.

Behoben in ThreadNet-Web:c90ac4d. Status bleibt done - korrigiert wurde die
Behauptung, nicht der Zustand.

Lehre: Fuer Konfiguration, die ueber ihre Position im Dateisystem wirkt, ist die
Liste der Orte die Pruefung, nicht das Verhalten an einem davon.

docs/issues/0055-npm-scope-aufloesung-threadnet-web.md

@@ -127,3 +127,45 @@ Fallstrick und der Prüfung, dass die Tarball-URL auf rohana zeigt.
 
 **Nicht angefasst:** `allow_failure: true` auf `publish_npm` — eigener Befund, liegt
 weiterhin bei sorb.
+
+## Korrektur 2026-08-20 — „vollständig geschlossen" stimmte nicht
+
+Der Abschnitt oben schließt mit dem Satz, die Lücke sei „vollständig geschlossen, nicht
+nur an einer Stelle". Das war falsch, und es ist am 2026-08-19 in Produktion aufgefallen.
+
+**Was passiert ist:** Der Release-Kandidat `v0.6.0-rc.1` erzeugte kein Image.
+`docker_web` scheiterte mit
+
+```
+[ERR_PNPM_FETCH_404] GET https://registry.npmjs.org/@sorb%2Fthreadnet-call-embedded
+No authorization header was set for the request.
+```
+
+— also exakt der Fehler, den dieses Issue behoben haben sollte.
+
+**Warum die Abnahme ihn nicht gefunden hat:** Sie hat gemessen, ob die `.npmrc`
+*wirkt*, wenn sie vorhanden ist — in einem isolierten Baum, im frischen Klon, im
+CI-Job `web`. Überall dort liegt sie im Wurzelverzeichnis und wird gelesen. Nicht
+geprüft wurde, ob sie überall *ankommt*, wo installiert wird. Und im Docker-Build kam
+sie nie an: Die `COPY`-Zeile in `apps/web/Dockerfile` listet die Dateien einzeln auf
+und führte `.npmrc` nicht.
+
+**Warum es trotzdem monatelang gutging** — und das ist die eigentliche Pointe, denn die
+`.npmrc` sagt es in ihrem eigenen Kommentar voraus: Unter pnpm 10 nahm
+`--frozen-lockfile` die im Lockfile gepinnte Tarball-URL und löste gar nichts auf. Der
+Schutz kam also nicht von der `.npmrc`, sondern vom Lockfile. Erst der Upstream-Merge
+brachte pnpm 11 mit `minimumReleaseAgeStrict: true`; das prüft für jeden Eintrag das
+Veröffentlichungsdatum, braucht dafür Registry-Metadaten — und landet ohne `.npmrc` bei
+npmjs.
+
+**Behoben** in `ThreadNet-Web:c90ac4d`: `.npmrc` steht jetzt in der `COPY`-Zeile.
+Belegt durch den Bau von `v0.6.0-rc.2` und alle folgenden.
+
+**Die Lehre ist nicht „eine Datei vergessen".** Die Abnahme hat die richtige Frage
+falsch gestellt: „wirkt die Konfiguration?" statt „liegt sie an jeder Stelle, an der
+installiert wird?". Für Konfiguration, die per Dateisystem-Position wirkt, ist die
+Liste der Orte die Prüfung — nicht das Verhalten an einem davon. Dieselbe Klasse wie
+der Fallstrick weiter oben, dass der Desktop-Client seine eigene `config.json` lädt.
+
+Status bleibt `done`: Die Lücke ist jetzt tatsächlich geschlossen. Korrigiert wurde die
+Behauptung, nicht der Zustand.