diff --git a/.vch-description b/.vch-description
index 10fbbbe..dd324f2 100644
--- a/.vch-description
+++ b/.vch-description
@@ -1,7 +1,7 @@
 Sortierhilfe fuer gebrauchte Server-RAM-Module. Man haelt ein Modul vor die
 Handykamera, und die App sagt sofort, auf welchen Stapel es gehoert - Module
-mit identischen technischen Daten und identischer Hersteller-Teilenummer
-landen zusammen, damit daraus verkaufsfertige Kits entstehen.
+mit gleichen technischen Daten und, soweit lesbar, gleicher Hersteller-
+Teilenummer landen zusammen, damit daraus verkaufsfertige Kits entstehen.
 
 Gedacht fuer den Wareneingang im Gebrauchthandel mit Serverkomponenten, wo
 gemischte Chargen ankommen und von Hand sortiert werden muessen. Die App
diff --git a/README.md b/README.md
index 3f5235a..18000f2 100644
--- a/README.md
+++ b/README.md
@@ -2,9 +2,18 @@
 
 Browser-App, die per Handykamera gebrauchte Server-RAM-Module erkennt und
 beim physischen Sortieren am Tisch anleitet: Modul vor die Kamera halten, die
-App nennt den Stapel. Module mit identischer Spec **und** identischer
-Hersteller-Teilenummer bilden einen Stapel, damit daraus verkaufsfertige Kits
-entstehen.
+App nennt den Stapel. Verglichen wird über alle Merkmale, die bei Modul und
+Stapel bekannt sind — Kapazität, Bauform, Rank, Geschwindigkeit und, sofern
+gelesen, Hersteller-Teilenummer (`specsCompatible` in `src/spec.js`); ein auf
+einer Seite fehlendes Merkmal wird dabei übersprungen, nicht als Widerspruch
+gewertet. Passt danach genau ein Stapel, wird das Modul zugewiesen; passen
+mehrere, fragt die App nach (`proposeAssignment` in `src/session.js`). Das hat
+eine bewusst in Kauf genommene Folge: Konnte die Teilenummer nicht gelesen
+werden — der häufige Fall bei überklebten oder beschädigten Etiketten — und
+passt anhand der übrigen Merkmale nur ein Stapel, landet das Modul dort, auch
+wenn seine tatsächliche Teilenummer eine andere wäre. Diese Abwägung ist
+Absicht: Ohne sie müsste die App bei jedem zweiten Modul nachfragen, sobald
+die Texterkennung keine Teilenummer liefert.
 
 Die Erkennung läuft vollständig lokal im Browser — kein Server, keine Cloud,
 keine Daten verlassen das Gerät.
@@ -15,7 +24,10 @@ keine Daten verlassen das Gerät.
    dekodiert (`zxing-wasm`). Das ist exakt, im Gegensatz zu Texterkennung.
    Werden mehrere Barcodes im Bild gefunden, die sich widersprechen (nicht
    dieselbe Teilenummer), gilt das als mehrdeutig — die App rät nicht,
-   sondern fragt nach.
+   sondern fragt nach. Das gilt nur für Barcodes mit einem bekannten
+   Nummernschema; widersprechen sich mehrere Barcodes mit unbekanntem
+   Nummernschema, wird keine ihrer Teilenummern übernommen und das Ergebnis
+   stützt sich allein auf die Texterkennung, ohne dass die App nachfragt.
 2. **Teilenummer-Decoder.** Aus einer Hersteller-PN wie `M386A8K40BM1-CRC4Y`
    werden Kapazität, Bauform und Geschwindigkeit tabellengesteuert
    abgeleitet. Gelingt das, entfällt OCR vollständig.
@@ -108,6 +120,7 @@ nicht gesetzt ist).
 | `src/ocr.js` | Bildaufbereitung (Otsu) und Adapter zu `tesseract.js` |
 | `src/ui/` | Ansichten: Scan-Ansicht, Ergebnis-Einblendung, Rot-Dialog bei Mehrdeutigkeit, Sitzungsliste |
 | `src/main.js` | Verdrahtung aller Module zur lauffähigen App |
+| `src/styles.css` | Farbvariablen (Grün/Gelb/Rot der Ampel-Rückmeldung), Layout des Kamera-Vollbilds samt Zielrahmen, Stapel-Leiste und Aktionsknöpfe sowie die Overlays für Treffer-Rückmeldung, Rot-Dialog und Sitzungsliste |
 
 `spec`, `pn-decoder`, `ocr-extract`, `session`, `pipeline` und `storage` sind
 reine Funktionen ohne Browser-Zugriff (kein `window`, `document` oder
@@ -201,6 +214,15 @@ werden:
   Otsu-Aufbereitung liefert auf einem echten, glänzenden Etikettenfoto
   tatsächlich brauchbaren Text (bisher nur an synthetischen Testbildern
   geprüft, nie an einem echten Foto).
+- Ladezeit des WASM-Barcode-Moduls (`zxing-wasm`) beim allerersten Scan einer
+  Sitzung beobachten — bleibt sie deutlich unter der 10-Sekunden-Zeitgrenze
+  der Pipeline, und braucht ein zweiter, schnell nachfolgender Scan nicht
+  erneut die volle Ladezeit (Beleg, dass die Vorbereitung tatsächlich nur
+  einmal läuft)?
+- Verbindung während des allerersten Scans einer Sitzung unterbrechen (WASM
+  lädt per CDN), danach mit wiederhergestellter Verbindung erneut scannen:
+  Das muss einen echten neuen Ladeversuch auslösen statt dauerhaft mit
+  demselben Fehler zu scheitern.
 - Ladezeit des Tesseract-Arbeiters beim allerersten Scan einer Sitzung
   beobachten — bleibt sie auf einem normalen Handy deutlich unter der
   20-Sekunden-Zeitgrenze der Pipeline?