p75+76

patch_history/RETRIEX_PATCH_75_FOLLOWUP_PRICE_ACTION_GUARD_README.md

@@ -0,0 +1,46 @@
+# RetrieX Patch p75 - Follow-up Price Action Guard
+
+## Ziel
+
+Nach p74 konnte bei Antworten mit Preisangaben weiterhin die Folgeaktion `Preis anzeigen` erscheinen. Beispiel:
+
+```text
+Zeige mir die Preise zu testomat resthärte indikator.
+```
+
+Die Antwort enthielt bereits konkrete Preise wie `98,20 €`, trotzdem wurde erneut `Preis anzeigen` angeboten. Zusätzlich sollte die Preis-Folgeaktion bei klaren No-Match-/Eignungswarnungen defensiver sein.
+
+## Änderung
+
+- Die Preiserkennung für Follow-up-Actions erkennt nun auch Preisformate wie `98,20 €` zuverlässig.
+- Die bisherige Regex hatte bei `€` ein Wortgrenzenproblem und erkannte außerdem `Preise` nicht sicher.
+- Shop-Folgeaktionen werden zusätzlich per YAML ausgeblendet, wenn die Antwort klar keinen direkten/expliziten Produkttreffer oder keine gesicherte technische Eignung formuliert. Dadurch entstehen bei No-Value-Antworten keine künstlichen Filter- oder Preis-Actions.
+
+## Warum generisch?
+
+Der Patch enthält keine Testomat-, Resthärte-, Indikator- oder TH-Code-Sonderlogik. Er verbessert nur die generische Action-Sichtbarkeit anhand von Preisformaten und konfigurierbaren No-Value-/No-Match-Formulierungen.
+
+## Erwartete Wirkung
+
+- Wenn eine Antwort bereits Preise wie `83,30 €`, `98,20 €` oder `Preis: 109,20 €` enthält, erscheint `Preis anzeigen` nicht erneut.
+- Bei klaren No-Match-/Eignungswarnungen wird keine Preisaktion künstlich angeboten.
+- Rollenfilter-Actions bleiben unverändert kontextsensitiv, werden aber bei klaren No-Value-/No-Match-Antworten ebenfalls ausgeblendet.
+
+## Checks
+
+Lokal geprüft:
+
+```bash
+php -l src/Agent/AgentRunner.php
+python3 YAML parse config/retriex/chat-messages.yaml
+php smoke: Preisformate mit Eurozeichen werden erkannt
+python3 smoke: zusätzliche YAML-No-Value-Patterns matchen
+```
+
+In der Zielumgebung zusätzlich ausführen:
+
+```bash
+bin/console mto:agent:config:validate
+bin/console mto:agent:regression:test
+bin/console mto:agent:config:audit-source --details
+```

patch_history/RETRIEX_PATCH_76_MODEL_VARIANT_SHOP_REPAIR_README.md

@@ -0,0 +1,79 @@
+# RETRIEX PATCH 76 - Model Variant Shop Repair
+
+## Ziel
+
+Produktnahe Messgeräte-Anfragen mit technisch belegten Modellvarianten dürfen nicht auf eine generische Basisfamilie zurückfallen, wenn RAG-Wissen konkrete Varianten nennt und die Shop-Suche nur eine zu breite Query verwendet.
+
+Beispielklasse:
+
+- User: `ich möchte gern gesamtchlor messen. welche messgerät sollte ich nutzen`
+- RAG nennt konkrete Varianten wie `Testomat 2000 CLF` / `Testomat 2000 CLT`
+- Shopquery darf daraus nicht nur `Testomat 2000` machen und die Variante verlieren
+
+## Änderungen
+
+### 1. Modellvariantensuffixe in finalen Shopqueries bewahren
+
+`AgentRunner::filterShopQueryToPositiveTokens()` bewahrt nun generisch alphabetische Modell-/Variantensuffixe, wenn sie direkt an ein bereits erlaubtes Modell-/Code-Token anschließen.
+
+Beispiel:
+
+- vorher: `Testomat 2000 CLF` -> `testomat 2000`
+- nachher: `Testomat 2000 CLF` -> `testomat 2000 clf`
+
+Das ist generisch und nicht auf CLF/CLT oder Testomat hardcodiert.
+
+### 2. Mehrere Modellvariantensuffixe in CommerceQueryParser erhalten
+
+`CommerceQueryParser::compactShopSearchTokens()` erhält jetzt nicht nur ein einzelnes Suffix nach einer Modellnummer, sondern eine zusammenhängende Suffixkette.
+
+Beispielklasse:
+
+- `Family 2000 ABC DEF` behält beide Varianten-/Suffix-Tokens, sofern sie dem generischen Suffixmuster entsprechen.
+
+### 3. RAG-gefundene konkrete Modellvarianten als Repair-Queries nutzen
+
+`SearchRepairService` baut bei schwachen primären Shop-Treffern generische Repair-Queries aus konkreten Modellvarianten, die im RAG-Kontext gefunden wurden.
+
+Dabei werden bevorzugt spezifische Varianten mit Suffix/Code genutzt, statt nur die Basisfamilie zu suchen.
+
+### 4. Modellkandidaten-Pattern erweitert
+
+`genre.yaml` erkennt Modellkandidaten mit getrenntem Variantensuffix, z. B. generisch:
+
+- `Produkt 2000 ABC`
+- `Produkt 2000 ABC DEF`
+
+### 5. Repair-Budget leicht erhöht
+
+`retriex.commerce.search_repair.max_queries` wurde von `1` auf `2` erhöht, damit bei zwei plausiblen Varianten nicht nur die erste Variante abgefragt wird.
+
+## Nicht geändert
+
+- Keine Testomat-Sonderlogik
+- Keine CLF-/CLT-Sonderlogik im PHP-Core
+- Kein neues Ranking-/Retrieval-Scoring
+- Keine Änderung an Shopware Criteria-Struktur
+- Keine Änderung an Produktrollenlogik
+
+## Lokale Checks
+
+- `php -l src/Commerce/SearchRepairService.php`
+- `php -l src/Agent/AgentRunner.php`
+- `php -l src/Commerce/CommerceQueryParser.php`
+- `php -l src/Config/AgentRunnerConfig.php`
+- `php -l src/Config/SearchRepairConfig.php`
+- YAML Parse für `genre.yaml`, `commerce.yaml`, `agent.yaml`, `search_repair.yaml`
+- Regex-Smoke: Modellkandidaten-Pattern erkennt `Testomat 2000 CLF` und `Testomat 2000 CLT`
+
+## Empfohlener Regressionstest
+
+```text
+ich möchte gern gesamtchlor messen. welche messgerät sollte ich nutzen
+```
+
+Erwartung:
+
+- Shop-/Repair-Logik verliert Suffixe wie `CLF`/`CLT` nicht mehr.
+- Wenn Shopdaten konkrete Varianten liefern, sollen diese Varianten in der Antwort erscheinen.
+- Eine generische Basisfamilie wie `Testomat 2000` darf nicht die konkrete Variante ersetzen.

patch_history/RETRIEX_PATCH_77_PRICE_UNAVAILABLE_ACTION_GUARD_README.md

@@ -0,0 +1,44 @@
+# RetrieX Patch p77 - Price Unavailable Action Guard
+
+## Ziel
+
+Nach p76 ist die fachliche Auswahl fuer Gesamtchlor deutlich besser: Bei `ich moechte gern gesamtchlor messen...` wird der konkrete Shop-/RAG-Anker `Testomat 2000 THCL` gehalten. Danach konnte die Follow-up-UI aber nach einer Preisantwort erneut Actions wie `Preis anzeigen`, `Nur Zubehoer anzeigen`, `Nur Geraete anzeigen` oder `Technische Details anzeigen` anbieten, obwohl die Antwort bereits sagte, dass der konkrete Preis nicht explizit angegeben bzw. nur auf Anfrage verfuegbar ist.
+
+## Änderung
+
+- Die Preis-Erkennung fuer Follow-up-Actions erkennt Preisformate wie `7.202,00 €` und `98,20 €` robuster.
+- `Preis anzeigen` wird ausgeblendet, wenn die Antwort bereits Preise enthaelt oder klar sagt, dass der Zielpreis nicht angegeben, nicht enthalten, nicht ausgewiesen oder nur auf Anfrage verfuegbar ist.
+- Rollenfilter-Actions werden bei No-Match-, No-Eignung- und Preis-nicht-verfuegbar-Antworten ausgeblendet.
+- Rollenfilter-Actions werden ebenfalls ausgeblendet, wenn die Antwort klar eine einzige direkte Loesung bzw. ein einziges direktes Messgeraet nennt; dann erzeugen Filter keinen Mehrwert.
+- `Technische Details anzeigen` wird ausgeblendet, wenn die Antwort bereits technische Eignung, Messparameter, Produktnummer, Verfuegbarkeit oder eine Preis-nicht-verfuegbar-Einordnung liefert.
+
+## Warum generisch?
+
+Der Patch enthaelt keine Testomat-, THCL-, Gesamtchlor- oder Modell-Sonderlogik. Er erweitert nur die konfigurierbaren Follow-up-Action-Guards und die generische Preisformat-Erkennung.
+
+## Erwartete Wirkung
+
+- Nach einer Preisantwort wie `Der Preis fuer dieses Geraet ist nicht explizit angegeben` erscheint keine erneute `Preis anzeigen`-Action.
+- Bei einer klaren Einzelgeraet-Antwort entstehen keine sinnlosen Rollenfilter wie `Nur Zubehoer anzeigen` oder `Nur Geraete anzeigen`.
+- Bei Antworten mit technischen Kerndetails erscheint `Technische Details anzeigen` nicht mehr als redundante Aktion.
+
+## Checks
+
+Lokal geprueft:
+
+```bash
+php -l src/Agent/AgentRunner.php
+php -l src/Config/AgentRunnerConfig.php
+php -l src/Config/ChatMessagesConfig.php
+python3 YAML parse config/retriex/chat-messages.yaml
+php PCRE pattern validation for follow-up action hide patterns
+php smoke: price-unavailable pattern matches German no-price wording
+```
+
+In der Zielumgebung zusaetzlich ausfuehren:
+
+```bash
+bin/console mto:agent:config:validate
+bin/console mto:agent:regression:test
+bin/console mto:agent:config:audit-source --details
+```