patch 20h
This commit is contained in:
152
RETRIEX_PATCH_20H_TOTAL_COMMERCE_ROUTING_STATUS_FIX_README.md
Normal file
152
RETRIEX_PATCH_20H_TOTAL_COMMERCE_ROUTING_STATUS_FIX_README.md
Normal file
@@ -0,0 +1,152 @@
|
||||
# RetrieX Patch 20h – Total Commerce Routing & Shop Status Fix
|
||||
|
||||
## Ziel
|
||||
|
||||
Dieser Patch ersetzt die fragmentierten p20d/p20e/p20f/p20g-Nachbesserungen durch einen kumulativen Fix gegen den aktuellen `rag-inprogress.zip`-Stand.
|
||||
|
||||
Er adressiert zwei zusammenhängende Fehlerklassen:
|
||||
|
||||
1. Explizite oder referenzielle Commerce-/Shop-Anfragen dürfen nicht im RAG-only-Pfad landen.
|
||||
2. Sobald ein Shop-/Commerce-Routing erkannt ist, darf die Statuskarte während des Ablaufs nicht weiter `Shop-Treffer: nicht angefragt` anzeigen.
|
||||
|
||||
## Behobene Fälle
|
||||
|
||||
### Expliziter Shop-Intent
|
||||
|
||||
Beispiel:
|
||||
|
||||
```text
|
||||
shop testomat 808
|
||||
```
|
||||
|
||||
Erwartung:
|
||||
|
||||
- Commerce-Intent wird abgesichert.
|
||||
- Shop-Pfad wird betreten.
|
||||
- Status springt nach der Intent-Erkennung auf `Shop-Treffer: wird geladen`.
|
||||
|
||||
### Tippfehler-Normalisierung bleibt erhalten
|
||||
|
||||
Beispiel:
|
||||
|
||||
```text
|
||||
was kpstet der indikator
|
||||
```
|
||||
|
||||
Erwartung:
|
||||
|
||||
- LLM-/Fuzzy-Normalisierung bleibt erhalten.
|
||||
- Die Anfrage kann intern als Preis-/Shop-Follow-up geroutet werden.
|
||||
- Es wird keine konkrete Tippfehlerliste eingeführt.
|
||||
|
||||
### Referenzieller Tabellen-/Preis-Follow-up
|
||||
|
||||
Beispiel:
|
||||
|
||||
```text
|
||||
welche grenzwerte kann der testomat 808 messen
|
||||
|
||||
die tabelle mit preisen
|
||||
```
|
||||
|
||||
Erwartung:
|
||||
|
||||
- `die tabelle mit preisen` wird als kommerzieller Tabellen-Follow-up in den Shop-Pfad gehoben.
|
||||
- Die Shop-Query wird aus dem Verlauf robuster abgeleitet, z. B. `Testomat 808 indikator`.
|
||||
- Die History wird newest-first durchsucht und nicht nur der letzte Turn betrachtet.
|
||||
|
||||
### Status-/Meta-Konsistenz
|
||||
|
||||
Sobald Commerce-Intent erkannt ist, wird `shopCountMode` zentral berechnet:
|
||||
|
||||
- vor Shop-Suche: `loading` → `Shop-Treffer: wird geladen`
|
||||
- nach Shop-Suche: `count` → echte Trefferzahl
|
||||
- Shop-Systemfehler: `unavailable` → `Shop-Treffer: nicht verfügbar`
|
||||
- Commerce erkannt, aber keine konkrete Suchquery lösbar: `not_resolved` → `Shop-Treffer: keine Suchquery`
|
||||
- nur Nicht-Commerce bleibt `not_requested`
|
||||
|
||||
Damit gibt es im Shop-/Commerce-Ablauf keine verstreuten harten `not_requested`-Zwischenstatus mehr.
|
||||
|
||||
## Geänderte Datei
|
||||
|
||||
- `src/Agent/AgentRunner.php`
|
||||
|
||||
## Technische Änderungen
|
||||
|
||||
- Initialisierung von `$commerceIntent` und `$shopSearchSkippedBecauseNoQuery` vor dem Try-Block.
|
||||
- Absicherung gegen Normalisierungsverluste: falls der normalisierte Routing-Prompt keinen Commerce-Intent ergibt, der Originalprompt aber schon, wird der Original-Commerce-Intent übernommen.
|
||||
- Frühes Meta-Event `Shop-Routing erkannt` bei Commerce-Intent.
|
||||
- RAG-Zwischenmeta nutzt bei Commerce-Intent `loading` statt `not_requested`.
|
||||
- `not_requested` wird nicht mehr an mehreren Stellen hart gesetzt, sondern über `resolveShopCountModeForMeta()` zentral berechnet.
|
||||
- Referenzielle Tabellen-Follow-ups werden ohne vorherige harte History-Anchor-Bedingung in den Shop-Pfad gehoben.
|
||||
- Tabellen-/Preis-Follow-up-Query sucht History-Kontext robuster über Commerce-Kontext, erweiterten Verlauf und optional Full-History.
|
||||
- History-Turns werden newest-first geprüft.
|
||||
- Wenn ein Indikator-/Tabellenkontext ohne Modell gefunden wird, bleibt ein Fallback erhalten; ein später gefundener Modellanker hat Vorrang.
|
||||
|
||||
## Lokale Prüfungen
|
||||
|
||||
Durchgeführt in der Container-Umgebung:
|
||||
|
||||
```bash
|
||||
php -l src/Agent/AgentRunner.php
|
||||
```
|
||||
|
||||
Ergebnis: OK.
|
||||
|
||||
Zusätzliche statische Checks:
|
||||
|
||||
- kein hartes `shopCountMode: 'not_requested'` mehr im AgentRunner
|
||||
- `not_requested` nur noch zentral in `resolveShopCountModeForMeta()`
|
||||
- `loading`, `not_resolved`, `unavailable` und `count` werden zentral unterschieden
|
||||
- keine konkreten Tippfehlerlisten wie `kpstet` / `ksotet`
|
||||
|
||||
Nicht vollständig ausführbar in dieser Umgebung:
|
||||
|
||||
```bash
|
||||
bin/console mto:agent:config:validate
|
||||
bin/console mto:agent:regression:test
|
||||
bin/console mto:agent:config:audit-source --details
|
||||
bin/console mto:agent:config:audit-patterns --details
|
||||
```
|
||||
|
||||
Grund: Die ZIP enthält keine installierten Composer-/Runtime-Dependencies; die lokale Umgebung hat außerdem nicht alle benötigten PHP-Extensions.
|
||||
|
||||
## Pflichtprüfung nach Einspielen
|
||||
|
||||
```bash
|
||||
bin/console cache:clear
|
||||
bin/console mto:agent:config:validate
|
||||
bin/console mto:agent:regression:test
|
||||
bin/console mto:agent:config:audit-source --details
|
||||
bin/console mto:agent:config:audit-patterns --details
|
||||
```
|
||||
|
||||
Falls OPcache/PHP-FPM aktiv ist, danach PHP-FPM bzw. Container neu laden.
|
||||
|
||||
## Manuelle Regressionstests
|
||||
|
||||
```text
|
||||
shop testomat 808
|
||||
```
|
||||
|
||||
Erwartung: Shop wird angefragt; nach Shop-Routing nicht mehr `Shop-Treffer: nicht angefragt`.
|
||||
|
||||
```text
|
||||
was kpstet der indikator
|
||||
```
|
||||
|
||||
Erwartung: Shop-/Preis-Follow-up greift weiterhin über Normalisierung/Fuzzy-Routing.
|
||||
|
||||
```text
|
||||
welche grenzwerte kann der testomat 808 messen
|
||||
|
||||
die tabelle mit preisen
|
||||
```
|
||||
|
||||
Erwartung: Shop-Suche wird ausgelöst; Query sinngemäß `Testomat 808 indikator`.
|
||||
|
||||
```text
|
||||
die tabelle mit shop preisen
|
||||
```
|
||||
|
||||
Erwartung: Shop-Suche wird ausgelöst, sofern Verlaufskontext vorhanden ist; sonst `Shop-Treffer: keine Suchquery` statt irreführend `nicht angefragt`.
|
||||
Reference in New Issue
Block a user