From cfdccb3f7482d6ac1752a60031e167335921a42d Mon Sep 17 00:00:00 2001 From: vchuser Date: Tue, 28 Jul 2026 17:50:38 +0200 Subject: [PATCH] docs: correct stacking rule, barcode flow, and device-check gaps MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit - README/.vch-description overstated the stacking rule as a hard "identical specs AND identical part number" requirement. In reality specsCompatible (src/spec.js) only compares fields known on both sides, so an unread part number is skipped rather than compared; proposeAssignment (src/session.js) only prompts when multiple stacks match. Documented the actual rule and its deliberate trade-off. - Added a sentence on how pipeline.js handles multiple barcodes with an unknown numbering scheme that disagree: no part number is taken over and OCR alone decides, without prompting. - Added src/styles.css to the "Aufbau" file table. - Added the two barcode-adapter device checks from .superpowers/sdd/task-9-report.md (first-load timing, reload after an interrupted first load) to "Am Gerät noch zu prüfen"; reviewed task-8 and task-10..13 reports and confirmed their other device checks were already present. --- .vch-description | 4 ++-- README.md | 30 ++++++++++++++++++++++++++---- 2 files changed, 28 insertions(+), 6 deletions(-) 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?