feat(review): store a unit correction like the extraction – "Stk." as pcs

[Fluory]

Warum

Fixes #96 · Folge aus dem Review von #95 (Befund 5)

Arbeitsstand

• Ziel: Eine Einheiten-Korrektur wird gespeichert wie bei der Erkennung: „Stk.“ wird zu pcs, andere Einheiten bleiben, wie sie getippt wurden. Das Audit behält, was getippt wurde.
• Nicht-Ziele: Normalisierung anderer Felder (Menge, Datum) bei Korrekturen.
• Erledigt: canonicalUnit im Review-Modul als Spiegel von canonical_unit des KI-Dienstes, samt Paritätstest gegen dessen Tabelle; correctField nutzt es für unit; Audit mit entered; Korrekturfeld zeigt „Stk.“; Hinweis umformuliert; CHANGELOG.
• Offen: nichts – Review-Notes umgesetzt, CI grün.
• Annahmen: keine.
• Nächster kleinster Schritt: Merge.

Was ist passiert (Klartext)

Auf der Prüfseite heißt die Einheit „Stk.“. Wer eine Einheit korrigierte und „Stk.“ eintippte, speicherte bisher genau diesen Text, und ans ERP ging dann „Stk.“ statt der vereinbarten Einheit „pcs“. Jetzt werden übliche Schreibweisen wie „Stk.“, „Stück“ oder „Meter“ beim Speichern genauso vereinheitlicht wie bei der automatischen Erkennung. Unbekannte Einheiten wie „Rolle“ bleiben unverändert. Im Protokoll steht weiterhin, was die Person eingetippt hat.

Plan-Pflicht (SYSTEM.md §4)

• Kein Auslöser – keine Modulgrenze, öffentliche API, Migration, Auth/Rechte, kein Zahlungs-/Daten-/Infrapfad, höchstens zwei Module, keine Architekturvarianten, umkehrbar
• Auslöser zutreffend – Impact Manifest ausgefüllt (Plan vor Code)

Geändert

• src/features/review/unit.ts (+ Test, neu): canonicalUnit, UNIT_SPELLINGS – gleiche Schreibweisen und gleiche Normalisierung wie services/ai/.../grounding/values.py
• src/features/review/review.ts: correctField vereinheitlicht unit; Audit-Daten entered, wenn getippt ≠ gespeichert
• src/app/requests/[id]/page.tsx, value-label.ts: Korrekturfeld zeigt „Stk.“, Hinweis umformuliert und per aria-describedby verknüpft
• tests/integration/review.test.ts: Korrektur „ Stk. “ → pcs, „Rolle“ bleibt, „Stück“ danach ist kein neuer Eintrag; Audit; ERP-Payload nach Freigabe (buildQuoteRequest) enthält pcs
• CHANGELOG.md

Nachweis (SYSTEM.md §11)

• verify:changed: grün – unit.test.ts 3/3 (zuerst rot: Modul fehlte), vitest src/features/review src/app/requests 47/47; tsc, eslint, depcruise (Exit 0)
• verify: grün – CI-Lauf 36465904120 (Kopf eb5e8c3): Unit 281/281, Integration 147/147 gegen Postgres + S3, darunter der neue Einheiten-Test bis zum ERP-Payload; depcruise, build, audit
• verify:full / E2E-Spec: nicht betroffen (Korrekturfluss unverändert; E2E prüft Mengen-Korrektur)
• Manueller Prüfnachweis: –
• Frischer Review (P1 vor Ready-for-review; Architektur/API/DB immer): unabhängiger Subagent, „mergeable per risk matrix“ mit 4 Notes → umgesetzt bzw. begründet: feat(review): store a unit correction like the extraction – "Stk." as pcs #100 (comment)

Doku-Entscheidung (genau eine)

• Keine langlebige Doku betroffen – Begründung: –
• Doku betroffen und im selben PR aktualisiert:
  • Produktdoku (P0: README): –
  • Technische Doku: –
  • Architekturkarte: –
  • ADR: –
  • CHANGELOG [Unreleased] (sichtbares Feature oder Verhalten – im selben PR, nie „später"): Changed-Eintrag feat(review): accept "Stk." in a unit correction and store the ERP unit #96

Entferntes oder Umbenanntes: docs/ + README gegrept, Treffer bereinigt: nichts entfernt

Dateigrößen und neue Bausteine (SYSTEM.md §7)

Dateien über 500 Zeilen im Diff (Ausnahmen: generierter Code, Lockfiles, Fixtures, Migrationen, Schemas, Ressourcen, Doku, Konfiguration):

• keine
• bewusst belassen – Begründung: –
• im selben PR nach fachlicher Verantwortung geteilt
• Folge-Issue –

Über 800 Zeilen mit neuer Fachlogik oder über 1000 Zeilen (P1/P2): nicht betroffen

Neue Shared-Komponente, Utility-Datei, Adapter oder fachlicher Service:

• nein
• ja – gesucht nach: vorhandener Einheiten-Normalisierung (pcs, Stück, canonical); gefunden: canonical_unit im KI-Dienst (Python) und nur eine Anzeige-Abbildung in value-label.ts. Keine TS-Normalisierung vorhanden, deshalb neu im Review-Modul als Spiegel der Python-Regel. Ein Paritätstest liest die Python-Tabelle, sodass eine Änderung auf einer Seite rot wird.

Subagent-Einsätze

• 1 × frischer Review (read-only) – Ergebnis und Umsetzung im PR-Kommentar.

Risiken / offene Punkte

• Die Tabelle existiert in Python und TypeScript. Der Paritätstest bricht mit klarer Meldung, sobald sich eine Seite ändert oder die Python-Tabelle umzieht.
• Neu: Speichern eines nicht-kanonisch gespeicherten Einheitswerts ohne Änderung (z. B. eine Altkorrektur „Stk.“) erzeugt eine protokollierte Korrektur auf pcs – gewollt. Unkorrigierte uncertain-Rohwerte des KI-Dienstes bleiben unverändert.

---

🤖 Generated with Claude Code

[vercel]

Deployment failed for project requestflow-ai with the following error:

Resource is limited - try again in 24 hours (more than 100, code: "api-deployments-free-per-day").

Learn More: https://vercel.com/doc-edit?upgradeToPro=build-rate-limit

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated
requestflow-ai	Error		Sep 28, 2026 6:37pm UTC

[vercel]

Deployment failed for project requestflow with the following error:

Resource is limited - try again in 24 hours (more than 100, code: "api-deployments-free-per-day").

Learn More: https://vercel.com/doc-edit?upgradeToPro=build-rate-limit

[Fluory]

Frischer Review (unabhängiger Subagent, liest nur, Stand 5a266ff)

Geprüft: CI check grün auf 5a266ff (inkl. review.test.ts 18 Integrationstests, unit.test.ts 3). Vercel-Fehler: Rate-Limit, nicht codebezogen. Lokal vitest --project unit src/features/review 17/17.

• Es gibt kein Kopffeld unit (merge.ts:3), nur Positionen zu normalisieren reicht.
• „Stück“ nach „Stk.“ erzeugt korrekt keinen neuen Eintrag.
• Die Audit-Daten bleiben abwärtskompatibel (entered optional); außer Tests liest kein Code field.corrected-Daten.
• CHANGELOG und Klartext korrekt.

1. [Note] – src/features/review/unit.ts:21 – Die Normalisierung ist nicht exakt gleich. Beide Implementierungen mit denselben Eingaben ausgeführt:

   • "Stk.": TS pcs, Python None
   • "Stk.\u0085" und "Stk.\u001F": Python pcs, TS null
   • "Milli-\nmeter": Python mm, TS null

   _FOLD und casefold vs. toLowerCase können nicht abweichen, weil keine Schreibweise Strich, Anführungszeichen, x oder ß enthält. – Über ein einzeiliges Feld praktisch unerreichbar; im schlimmsten Fall bleibt der Text wie getippt. – „exactly like“ / „never differ“ abschwächen oder eine gemeinsame Fixture (Eingabe → Ergebnis) für pytest und vitest anlegen.

2. [Note] – unit.test.ts:24-31 – Der Paritätstest prüft nur die Tabelle, nicht die Normalisierung. Er wird bei jeder Tabellenänderung rot. Bricht ruff format (line-length 100) die pcs-Zeile aber um, zeigt er nur einen unverständlichen undefined-Diff. – Fail-safe, aber schwer zu deuten. – Eine nicht passende Zeile gezielt mit klarer Meldung scheitern lassen.

3. [Note] – page.tsx:294 – Speichern ohne Änderung ist bei pcs ein No-op. Bei einem nicht-kanonisch gespeicherten Wert entsteht jetzt aber eine Korrektur auf pcs, etwa bei einer Altkorrektur „Stk.“ oder einem uncertain-Rohwert ohne Beleg (verifier.py:130). – Die Richtung ist gewollt, das Verhalten neu; unkorrigierte uncertain-Einheiten gehen weiterhin als „Stk.“ ans ERP. – Im PR erwähnen, Folge-Issue erwägen.

4. [Note] – page.tsx:297 – Der Hinweis ist nicht per aria-describedby mit #item-correction verknüpft (schon vorher so; Muster in auth-form.tsx:72). Screenreader lesen ihn beim Fokus nicht vor, und dass unbekannte Einheiten bleiben, sagt er nicht. – aria-describedby setzen.

Urteil: mergeable per risk matrix – Keine Änderung an Architektur, Migration, API oder Rechten, der ERP-Vertrag bleibt unverändert, CI grün, alle Akzeptanzkriterien per Test belegt.

---

Umsetzung

#	Befund	Umsetzung
1	Normalisierung nicht exakt gleich	eb5e8c3: Die Wortwahl ist ehrlich – gleiche Schreibweisen und gleiche Normalisierungsschritte für das, was ein einzeiliges Feld enthalten kann; exotische Steuer- und Zeilenumbruchzeichen können abweichen. Eine gemeinsame Fixture gibt es bewusst nicht: praktisch unerreichbar, und im schlimmsten Fall bleibt der Text wie getippt.
2	unverständlicher Fehler bei umformatierter Tabelle	eb5e8c3: Eine nicht passende Zeile wirft „unexpected line in _UNIT_SPELLINGS – adapt this parser: …“
3	Speichern ohne Änderung korrigiert nicht-kanonische Werte	Gewollt: Die Einheit wird damit ERP-tauglich, und die Korrektur ist wie jede andere protokolliert. Unkorrigierte uncertain-Rohwerte ändert dieser PR nicht; das ist das Verhalten des KI-Dienstes (Vorschlag ohne Beleg bleibt roh zur Prüfung). Im PR unter Risiken genannt.
4	Hinweis nicht verknüpft	eb5e8c3: aria-describedby="unit-hint item-correction-hint" am Korrekturfeld; der Einheiten-Hinweis sagt jetzt auch „andere Einheiten bleiben, wie getippt“