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.
Projektvorgabe: Kommentare und Oberflaechentexte deutsch, Bezeichner im Code
englisch. Betroffen: src/barcode.js (vorbereitungsPromise -> readyPromise,
inkl. Verweis-Kommentar in ocr.js), sowie lokale Variablen in
test/spec-match.test.js, test/session.test.js und test/pipeline.test.js
(u.a. ocrAufgerufen -> ocrCalled, gefunden bei vollstaendigem Durchgang
aller Test-Dateien). Testbeschreibungen (Prosa) und Kommentare bleiben
unangetastet - nur echte Bezeichner wurden umbenannt.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
proposeAssignment verlangt jetzt zusätzlich zur bisherigen
Verträglichkeitsprüfung, dass Stapel und Modul mindestens ein Merkmal
gemeinsam belegt haben. Ein Stapel mit vollständig leerem Spec (Rot-Fall,
"neuer Stapel") hatte sonst mit jedem Modul null gemeinsame Felder und
galt fälschlich als verträglich mit allem.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
commitAssignment and moveEntry stored the same spec object in both
stack.spec and entry.spec. A later, more complete scan enriching
stack.spec would retroactively mutate the entry that first created the
stack, making it appear as if it had been scanned with data it never
actually had. Both places now store independent shallow copies so the
entries log and the stacks spec (comparison baseline) can't leak into
each other.
Also documents that undoLast intentionally reverts the last *recorded*
entry, not the last *action* - a subsequent moveEntry/removeEntry on a
different entry does not change what undoLast will take back - and
adds a test pinning that contract after a reorder.
vchuser