Jeder Stapel fuehrt jetzt die Menge der Barcode-Zeichenketten, die bei
seinen Modulen gelesen wurden (stack.codes). Traegt ein gescanntes Modul
einen Code, den ein Stapel bereits kennt, hat das Vorrang vor dem Vergleich
der technischen Angaben - ein Barcode ist exakt gelesen, abgeleitete Angaben
koennen fehlerbehaftet sein. Genau ein Stapel ueber einen bekannten Code
-> Zuweisung, auch bei unvollstaendigen Angaben; mehrere -> weiterhin
mehrdeutig, der Nutzer entscheidet; kein passender Code -> unveraendert die
bisherige Regel. Eine Seriennummer, die bei jedem Modul anders ist, laeuft
dabei einfach ins Leere, ohne die Zuordnung ueber die Teilenummer zu
verhindern.
proposeAssignment und commitAssignment bekommen dafuer einen neuen, optional
en codes-Parameter (Vorgabe []); bestehende Aufrufe ohne diesen Parameter
verhalten sich unveraendert.
storage.js sichert und prueft stack.codes jetzt mit: fehlt das Feld (Stand
aus einer aelteren Fassung), gilt der Stapel als ohne bekannte Codes statt
den ganzen Stand zu verwerfen; ist es vorhanden, muss es eine Liste von
Zeichenketten sein wie jedes andere Feld auch.
test/storage.test.js: wieder -> reloaded, kaputt -> broken, zweiterEintrag
-> secondEntry, vorschlag -> proposal (Bezeichner, nicht die deutschen
Testbeschreibungen).
Neuer Test deckt die bislang nur mit einem einzigen Stapel geprueften
Stapelzaehler-Neuberechnung beim Laden ab: drei gespeicherte Stapel mit
absichtlich falschem count, davon einer (C) ganz ohne zugeordnete
Eintraege - alle drei muessen unabhaengig voneinander korrekt aus den
tatsaechlichen Eintraegen neu berechnet werden (A=2, B=1, C=0).
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
- Fuegt isPositiveInteger() hinzu fuer Validierung von Eintragsnummern
- nextEntryId und entry.entryId muessen ganze Zahlen >= 1 sein
- Akzeptiert nicht mehr negative, gebrochene oder Null-Werte
- Vier neue Tests pruefen die verstaerkten Anforderungen
- Alle bestehenden Tests bleiben gruen
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Stapelzähler wird beim Laden immer aus den zugeordneten Einträgen neu
berechnet statt aus dem gespeicherten Wert übernommen. Zusätzlich wird
verworfen (null): Einträge mit unbekannter Stapelkennung, doppelte
Eintragsnummern, doppelte Stapelkennungen und ein nextEntryId, der nicht
größer als jede vorhandene Eintragsnummer ist.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
loadSession pruefte bisher nur, ob stacks/entries Arrays sind, nicht
deren Inhalt. Ein fremder oder verfaelschter Eintrag unter dem
gleichen Schluessel kam dadurch als vermeintlich gueltige Sitzung
durch und liess die App beim naechsten Scan mit TypeError abstuerzen
(stack.spec fehlte). Falsch typisierte Felder (nextEntryId als String,
stack.count als String) wurden ebenfalls durchgereicht und verdarben
die Sitzung lautlos (doppelte entryIds, "3" + 1 = "31").
loadSession verlangt jetzt, dass nextEntryId eine endliche Zahl ist
und dass jeder Stapel/Eintrag ein echtes Objekt (kein Array, nicht
null) mit den Feldern ist, die session.js tatsaechlich weiterverwendet.
Schlaegt eine Pruefung fehl, liefert loadSession null - ein halb
brauchbarer Zustand wird nicht repariert oder teilweise uebernommen.
vchuser