MtoRagSystem/genre_yaml_konfigurationsanleitung.md

RetrieX v1.6.0 – Konfigurationsanleitung config/retriex/genre.yaml

Stand: Version 1.6.0 auf Basis des aktuellen rag-inprogress.zip.

Diese Anleitung beschreibt, welche fachlichen Werte in config/retriex/genre.yaml gepflegt werden, wie sie in der Runtime wirken und welche Prüfungen nach Änderungen ausgeführt werden müssen.

genre.yaml ist in RetrieX v1.6.0 die zentrale Fachkonfiguration für die aktive Domäne. Im aktuellen Paket ist genau ein Genre aktiv:

id: water_analysis
label: Water analysis / measurement devices
mode: single_installation_single_genre

Wichtig: RetrieX v1.6.0 ist keine Multi-Tenant- oder Multi-Genre-Plattform. Eine Installation steht für ein fachliches Genre. Domainnahe Begriffe, Produktrollen, Query-Guards, Promptregeln, Shop-Matching-Wörter und Regression-Guardrails gehören deshalb hierher, nicht zurück in hart codierte PHP-Listen.

---

1. Rolle von genre.yaml im System

genre.yaml ergänzt die technischen YAML-Dateien unter config/retriex um eine fachliche Source-of-Truth-Schicht.

In genre.yaml gehören insbesondere:

• Hauptprodukt-, Zubehör- und Verbrauchsmaterialrollen
• Produktattribute, Messparameter, Größen-, Farb- oder Längenbegriffe
• Marken, Kanonisierungen, Schreibvarianten und Synonyme
• Commerce-/Shop-Suchbegriffe und positive Tokenfilter
• Referenzauflösung für Follow-ups aus dem Chatverlauf
• Produktlisten- und Produktlink-Follow-ups
• exakte Zubehör-/Indikatorcode-Guards
• technische Prompt- und Antwortprioritäten
• Measurement-Evidence-Guards
• Search-Repair-Kandidaten und Direct-Attribute-Lookups
• Governance-, Source-of-Truth- und Regression-Anker

Nicht in genre.yaml gehören:

• Datenbankzugangsdaten
• Shopware-Zugangsdaten
• LLM-Endpunkt
• Python-/Vector-Service-Pfade
• Cache-, Lock-, Log- oder Infrastrukturparameter
• konkrete Modell-Samplingwerte wie Temperature oder Top-P

Diese Werte bleiben in .env, services.yaml, model.yaml, vector.yaml, runtime.yaml oder in der Datenbankkonfiguration.

---

2. Grundstruktur

Die Datei hängt am Symfony-Parameter:

parameters:
  retriex.genre.config:
    id: water_analysis
    label: Water analysis / measurement devices
    mode: single_installation_single_genre
    description: ...
    adaptation_surface: ...
    configuration_values: ...

2.1 Metadaten

Feld	Bedeutung	Anpassung
id	technischer Genre-Identifier	Nur ändern, wenn die Installation fachlich umgewidmet wird.
label	lesbarer Name	Frei sprechend halten.
mode	Betriebsmodell	In v1.6.0 bei single_installation_single_genre belassen.
description	Kurzbeschreibung	Bei Umwidmung aktualisieren.

2.2 adaptation_surface

adaptation_surface ist die Landkarte der fachlichen Anpassungsflächen. Sie dokumentiert, welche Runtime-Pfade durch genre.yaml fachlich überlagert oder gespeist werden.

Auswirkung:

• dient Audit, Review und Migration
• ändert normalerweise nicht direkt das Antwortverhalten
• muss zu configuration_values passen
• soll keine fachliche Payload enthalten

Ändern nur dann, wenn neue genreabhängige Runtime-Pfade hinzukommen, wegfallen oder umbenannt werden.

2.3 configuration_values

configuration_values enthält die eigentlichen fachlichen Werte. Änderungen hier können Retrieval, Shop-Suche, Commerce-Routing, Promptbau, Search Repair, Follow-up-Auflösung und Regression-Guards unmittelbar beeinflussen.

Grundregel:

• Fachwerte immer hier pflegen.
• Bestehende Gruppenstruktur beibehalten.
• source_paths nicht entfernen.
• Nach Änderungen immer Validate, Source-Audit, Pattern-Audit und Regression ausführen.

2.4 source_paths

source_paths verknüpfen Genre-Werte mit den alten oder effektiven technischen Config-Pfaden.

Sie sind wichtig für:

• Nachvollziehbarkeit
• Source-of-Truth-Guardrails
• Migrationssicherheit
• Audit-Ausgaben

Sie liefern nicht selbst den Runtime-Wert. Bei reinen Fachwertänderungen bleiben sie normalerweise unverändert.

---

3. Runtime-Lesemodell in v1.6.0

Die folgenden Runtime-Klassen lesen fachliche Werte bevorzugt über GenreConfig bzw. genregebundene Konfigurationsviews:

Klasse / Bereich	Typische Genre-Werte	Wirkung
DomainVocabularyConfig	Produktrollen, Views, Rollenbegriffe	Geräte-/Zubehörtrennung, Prompt- und Shop-Begriffe
CommerceQueryParserConfig	Marken, Canonical Terms, Korrekturen	Shopquery-Normalisierung und Token-Erhalt
QueryEnricherConfig	Query-Enrichment-Regeln	Erweiterung oder Fokussierung von Suchanfragen
CommerceIntentConfig	Commerce-Signale, Produkt-/Preis-/Shopmuster	Erkennung von Kauf-, Preis- und Shop-Intents
SalesIntentConfig	Sales-, Vergleichs-, ROI-Signale	Vertriebsnahe Intent-Erkennung
AgentRunnerConfig	Follow-ups, Shopquery-Cleanup, Direct Answer, RAG-Anker	Chatverlauf, Shop-Fallbacks und Antwortsteuerung
PromptBuilderConfig	Antwortpriorität, Fact-Grounding, Output-Regeln	Finale Antwortqualität und Grenzen
SearchRepairConfig	Repair-Kandidaten, Attribut-Lookup, Zubehörcodes	Reparatur schwacher oder referenzieller Shopanfragen
NdjsonHybridRetrieverConfig	Exact Selection, Tabellen-/Indikatormuster	Präzision bei RAG-Fakten und Tabellenextraktion
LanguageCleanupConfig	Protected Terms und Cleanup-Profile	Schutz fachlicher Tokens vor Sprachbereinigung
GovernanceConfig	Regression- und Audit-Guardrails	Schutz vor Rückfällen in hardcodierte Fachlogik

Legacy-YAMLs bleiben als technische Verarbeitungsschicht relevant, sind aber nicht mehr der bevorzugte Pflegeort für neue fachliche Domänenwerte.

---

4. Gruppen in configuration_values

4.1 product_roles

Zweck: definiert, welche Begriffe als Hauptprodukt, Zubehör, Verbrauchsmaterial oder rollenbezogene Prompt-/Shop-Begriffe gelten.

Wichtige Knoten:

• primary_product_terms
• accessory_product_terms
• requested_accessory_code_terms
• shop_views
• prompt_views
• no_llm_fallback_terms

Auswirkung:

• trennt Geräte/Hauptprodukte von Zubehör und Verbrauchsmaterialien
• beeinflusst Shop-Matching, Promptregeln und No-LLM-Fallbacks
• verhindert, dass Zubehörfragen als Gerätefragen beantwortet werden
• schützt Flows wie Indikator/Reagenz/Zubehör gegen falsche Produktrollen

Anpassung:

• Für ein neues Genre zuerst diese Gruppe überarbeiten.
• Hauptprodukt- und Zubehörbegriffe getrennt halten.
• Realistische Nutzerbegriffe, Umlaute und ASCII-Varianten aufnehmen.
• Keine zu generischen Wörter wie produkt, artikel oder teil als starke Rollenbegriffe verwenden.

Beispiel Wasseranalyse:

primary_product_terms:
  terms:
    - messgerät
    - analysegerät
    - testomat
accessory_product_terms:
  terms:
    - indikator
    - reagenz
    - zubehör

4.2 product_attributes

Zweck: definiert fachliche Attribute, Constraints und Vergleichsmuster.

Wichtige Knoten:

• direct_attribute_cleanup.product_type_terms
• direct_attribute_cleanup.stop_terms
• direct_attribute_cleanup.comparative_constraint_patterns
• size_and_color_terms
• numeric_length_constraints

Auswirkung:

• ermöglicht direkte Attributfragen wie „Anschlusskabel länger 20 m“
• steuert Cleanup vor Search Repair
• unterstützt Sortier-/Filterlogik für numerische Längen oder Größen
• kann für andere Genres auf Größe, Farbe, Material, Spannung, Gewinde, Kompatibilität usw. umgewidmet werden

Anpassung:

• Fachliche Produktartbegriffe austauschen, nicht nur ergänzen.
• Stop-Terme nur für Bedienwörter verwenden.
• Regex-Muster vorsichtig ändern und mit echten Prompts testen.

4.3 brands_and_canonical_terms

Zweck: pflegt Marken, Kanonisierungen, Schreibweisen und semantische Synonyme.

Wichtige Knoten:

• known_brands
• canonical_terms
• query_enrichment_rules
• accessory_focus_variants
• rag_evidence_synonyms

Auswirkung:

• schützt Markennamen und Modellfamilien in Shopqueries
• normalisiert Tippfehler oder Schreibvarianten
• hält direkte Produktnamen wie chlor select sensor oder Modellkürzel wie testomat lab cl stabil
• unterstützt RAG-Evidence-Abgleich über Synonyme

Anpassung:

• Nur etablierte Synonyme und klare Korrekturen eintragen.
• Keine aggressiven Kanonisierungen, die Varianten zusammenwerfen.
• Kürzel wie CL, TH, SIO2, LAB CL immer gegen Regression testen.

4.4 intent_and_routing

Zweck: enthält fachliche Werte für Commerce-, Sales- und Routing-Erkennung.

Wichtige Knoten:

• fuzzy_routing_terms
• commerce_intent
• sales_intent

Auswirkung:

• erkennt Preis-, Shop-, Produkt-, Beratungs- und Vergleichsfragen
• trennt technische Wissensfragen von Produkt-/Kaufintents
• verhindert, dass reine Fachfragen unnötig zu Shop-Suchen werden

Anpassung:

• Starke Shopbegriffe und Beratungssignale sauber trennen.
• Branchen- oder Anwendungskontexte nicht automatisch als Produktbeweis behandeln.
• Für neue Genres typische Kauf-/Vergleichs-/Beratungswörter ergänzen.

4.5 context_resolution

Zweck: löst referenzielle Folgefragen aus Chatverlauf und sichtbaren Antworten auf.

Wichtige Knoten:

• commercial_table_follow_up
• referential_terms
• history_anchor_enrichment
• product_list_followup
• meta_query_guard
• rag_anchor_enrichment

Auswirkung in v1.6.0:

• Folgefragen wie „was kostet der indikator“ können den letzten Geräte-/Indikatoranker nutzen.
• Produktlisten-Follow-ups wie „gib mir Links zu den Produkten“ können sichtbare Produktnamen extrahieren.
• Mehrprodukt-Follow-ups werden auf einzelne Produktanker vorbereitet.
• Schwache Shopfragen wie „suche im Shop nach der Information“ können auf konkrete History-Anker zurückfallen.
• RAG-Anker wie Messwerte und Produkttitel helfen, Folgefragen fachlich zu fokussieren.

Anpassung:

• referential_terms sind Pronomen/Füllwörter, keine Produktbegriffe.
• product_list_followup.anchor_patterns müssen konkrete Produktidentitäten erfassen.
• meta_query_guard sollte Bedien-/Meta-Wörter enthalten, die nicht als Suchinhalt dominieren dürfen.
• Bei neuen Produktfamilien entsprechende canonical_family_terms und Startmuster ergänzen.

4.6 shop_query_runtime

Zweck: steuert, welche Tokens in Shopqueries erhalten, entfernt, positiv gefiltert oder zu konkreten Produktankern repariert werden.

Wichtige Knoten:

• current_input_preservation_terms
• stopword_cleanup
• positive_token_filter
• generic_device_anchor
• compound_prefix_match
• primary_identity_repair
• semantic_shop_search_tokens
• direct_answer

Auswirkung in v1.6.0:

• Relationsrauschen wie „erreicht“, „gemessen“, „beim“ oder reine Bedienwörter wird entfernt.
• Korrigierte Tokens aus der Commerce-Konfiguration bleiben in der finalen Query erhalten.
• Modellkürzel wie LAB CL, THCL, CLT, SIO2 werden über positive Filter und Nachbarschaftsregeln geschützt.
• Generische Gerätefragen können auf konkrete YAML-konfigurierte Geräteanker wie testomat 808 sio2 geführt werden.
• Self-Loops bei identischen Folgeaktionsqueries können unterdrückt werden.

Anpassung:

• allowed_terms und blocked_terms immer zusammen prüfen.
• adjacent_variant_terms nur für echte Modell-/Variantentokens verwenden.
• generic_device_anchor.anchor_rules ist der richtige Ort für domainnahe Gerät-Parameter-Anker, nicht PHP-Core.
• Stopwords niemals so breit wählen, dass Produktnamen oder Messparameter verloren gehen.

4.7 result_identity_and_answer_policy

Zweck: definiert Antwortregeln, Prompt-Prioritäten, Evidence Guards und Ergebnisidentität.

Wichtige Knoten:

• prompt_rules.output_priority_technical
• prompt_rules.response_format_technical
• prompt_rules.response_format_accessory
• prompt_rules.fact_grounding_technical
• prompt_rules.fact_grounding_with_shop
• prompt_keyword_views
• measurement_evidence_guard_terms
• measurement_evidence_maps

Auswirkung:

• technische Fakten werden exakt und quellennahe beantwortet
• niedrigste/höchste Grenzwerte bleiben auf den Primärfakt fokussiert
• Indikator-/Reagenzfragen werden nicht mit anderen Varianten vermischt
• Produktselektion mit Shopdaten bleibt an Produktidentität, Produktnummer und explizite Evidence gebunden
• nicht belegte Informationen sollen als „Nicht bekannt.“ formuliert werden

Anpassung:

• Promptregeln kurz, eindeutig und testbar halten.
• Keine Vertriebsversprechen aufnehmen, die aus Quellen nicht belegbar sind.
• Bei neuen Messparametern measurement_evidence_maps erweitern.
• Exakte Code- und Variantenregeln immer mit Zubehör-/Preisflows testen.

4.8 search_repair

Zweck: repariert schwache Shopqueries und direkte Attributsuchen.

Wichtige Knoten:

• direct_product_attribute_lookup
• requested_accessory_code_terms
• candidate_patterns
• candidate_terms

Auswirkung:

• erkennt spezifische Modell-/Zubehörkandidaten
• hält exakte Zubehörcodes wie 300 getrennt von Varianten wie 300 S
• unterstützt reparierte Queries bei fehlenden oder schwachen Primärtreffern
• hilft bei Follow-ups, die nur „Preis“, „Shop“ oder „Information“ enthalten

Anpassung:

• Regexe nicht auf einzelne Produkte hart verdrahten.
• Code-Muster so definieren, dass Varianten nur bei expliziter Nutzereingabe gematcht werden.
• Generische Kandidatentokens knapp halten, sonst entstehen breite Shoptreffer.

4.9 retrieval_and_language

Zweck: verbindet Genre-Werte mit Retrieval- und Sprachbereinigung.

Wichtige Knoten:

• protected_terms
• cleanup_profiles
• retrieval_vocabulary_views
• exact_selection

Auswirkung:

• schützt kurze technische Tokens vor Stopword-Cleanup
• sichert RAG-Evidence- und Retrieval-Referenz-Cleanup
• unterstützt exakte Auswahl bei Tabellen, Grenzwerten und Indikatormappings

Anpassung:

• Kurze Modell-/Messparameter-Tokens in Protected-Term-Listen absichern.
• Cleanup-Profile nicht durch alte Legacy-Stopword-Listen ersetzen.
• Exact-Selection-Regeln bei Tabellenfragen mit Regression testen.

4.10 shop_data_mapping

Zweck: beschreibt fachliche Shopdaten-Zuordnung und Shop-Matching-Rollen.

Wichtige Knoten:

• custom_fields
• text
• role_guard
• commerce_connection

Auswirkung:

• mappt Shopware-Custom-Fields auf Antwortfelder
• steuert Geräte-/Zubehörfilterung im Shop-Matching
• entscheidet, wann Shopdaten als kommerzielle Felder priorisiert werden

Anpassung:

• Feldnamen an den realen Shopware-Datenbestand anpassen.
• Rollenfilter nicht so hart setzen, dass Zubehör-/Bundle-Treffer verschwinden.
• Shopdaten dürfen technische Eignung nur belegen, wenn der Produktdatensatz sie explizit nennt.

4.11 governance_and_regression

Zweck: hält Regression- und Audit-Anker für stabile Flows.

Wichtige Knoten:

• regression_baseline
• vocabulary_guardrails
• core_pattern_audit

Auswirkung:

• schützt zentrale 1.4.x/1.5.x/1.6.0-Flows
• bewahrt kurze Modell-/Parameter-Tokens
• verhindert Rückfälle in neue fachliche PHP-Hardcodings
• macht verdächtige Pattern-/Token-Nutzung im Core reviewbar

Anpassung:

• Neue stabile Kunden-/Testflows als Regression-Anker ergänzen.
• Domain Marker Terms aktuell halten.
• Audit-Ausnahmen nur für technische Parserlogik zulassen, nicht für fachliche Sonderfälle.

---

5. Wichtige v1.6.0-Guardrails

5.1 Exakte Zubehör- und Indikatorcodes

Ein konkreter Code wie 300 darf nicht automatisch Varianten wie 300 S, 301 oder 302 einschließen. Varianten sind nur erlaubt, wenn die Nutzerfrage sie explizit nennt oder die Quelle denselben Produktdatensatz eindeutig damit verbindet.

Relevant sind insbesondere:

• product_roles.requested_accessory_code_terms
• search_repair.requested_accessory_code_terms
• search_repair.candidate_patterns
• result_identity_and_answer_policy.prompt_rules

5.2 Geräteanker bei referenziellen Shopfragen

Bei Follow-ups wie „was kostet der indikator“ muss der konkrete Verlaufskontext erhalten bleiben, z. B. Gerät + Indikatortyp. indikatortyp ist Kontextsignal, darf aber nicht allein die Shopquery dominieren.

Relevant sind:

• context_resolution.history_anchor_enrichment
• context_resolution.commercial_table_follow_up
• shop_query_runtime.positive_token_filter
• shop_query_runtime.stopword_cleanup

5.3 Produktlisten- und Link-Follow-ups

Bei Fragen wie „gib mir Links zu den Produkten“ soll RetrieX sichtbare Produktanker aus der vorherigen Antwort verwenden und Mehrproduktlisten in Einzelqueries aufteilen.

Relevant sind:

• context_resolution.product_list_followup.enabled
• context_resolution.product_list_followup.anchor_patterns
• context_resolution.product_list_followup.max_anchors
• context_resolution.product_list_followup.template

5.4 Schwache History-/Meta-Fragen

Meta-Fragen wie „suche im Shop nach der Information“ enthalten kaum Produktsubstanz. v1.6.0 darf dann auf den letzten konkreten Produktanker aus der History zurückfallen, statt information als Shopquery zu senden.

Relevant sind:

• context_resolution.meta_query_guard
• context_resolution.product_list_followup.noise_terms
• shop_query_runtime.stopword_cleanup

5.5 Generische Device-Parameter-Anker

Fragen wie „Gerät für Silikatüberwachung“ können auf konkrete konfigurierbare Anker wie testomat 808 sio2 geführt werden. Diese Abbildung gehört in YAML, nicht als Sonderlogik in PHP.

Relevant ist:

• shop_query_runtime.generic_device_anchor.anchor_rules

---

6. Sichere Änderungsreihenfolge

Kleine Wertänderung

1. Passenden Knoten in configuration_values suchen.
2. Wert ändern oder ergänzen.
3. source_paths unverändert lassen.
4. Config und Regression prüfen.

Neues Synonym oder neue Marke

1. brands_and_canonical_terms prüfen.
2. Falls Shopquery-relevant: shop_query_runtime.positive_token_filter.allowed_terms prüfen.
3. Falls Retrieval-/Prompt-relevant: retrieval_and_language.protected_terms oder passende Vocabulary-Views prüfen.
4. Gegen echte Prompts testen.

Neues Zubehör oder Verbrauchsmaterial

1. product_roles.accessory_product_terms ergänzen.
2. product_roles.requested_accessory_code_terms prüfen.
3. result_identity_and_answer_policy.response_format_accessory prüfen.
4. Shopquery- und Preis-Follow-up testen.

Neues Geräte-/Parameter-Mapping

1. shop_query_runtime.generic_device_anchor.anchor_rules ergänzen.
2. brands_and_canonical_terms.canonical_terms prüfen.
3. result_identity_and_answer_policy.measurement_evidence_maps ergänzen, falls technische Evidence betroffen ist.
4. mto:agent:test:shop-search und mto:agent:retrieval:test ausführen.

Umwidmung auf neues Genre

1. id, label, description ändern.
2. product_roles vollständig ersetzen.
3. Attribute, Marken, Synonyme und Intents ersetzen.
4. Shopquery-Runtime und Search Repair neu fachlich definieren.
5. Promptregeln neutralisieren und danach genrebezogen ergänzen.
6. Regression-Baseline für das neue Genre aufbauen.
7. Alte Wasseranalyse-Tokens aus Guardrails entfernen, sofern nicht mehr gültig.

---

7. Pflichtchecks nach Änderungen

Nach jeder fachlichen Änderung an genre.yaml mindestens ausführen:

php bin/console mto:agent:config:validate
php bin/console mto:agent:config:audit-source --details
php bin/console mto:agent:config:audit-patterns --details
php bin/console mto:agent:regression:test

Für Review/CI zusätzlich möglich:

php bin/console mto:agent:config:dump-effective --summary
php bin/console mto:agent:config:validate --json
php bin/console mto:agent:regression:test --json

Für praktische Query-Tests:

php bin/console mto:agent:retrieval:test "niedrigster Grenzwert Wasserhärte"
php bin/console mto:agent:test:shop-search "testomat 808 300 indikator" --repair
php bin/console mto:agent:chat cli-debug

---

8. Typische Fehlerbilder

Änderung	Möglicher Fehler
Fachbegriff nur in PHP ergänzt	Audit findet neue hardcodierte Semantik oder spätere Updates verlieren den Wert.
blocked_terms zu breit	Produkt-/Parameter-Tokens verschwinden aus Shopqueries.
allowed_terms zu eng	Modellkürzel wie LAB CL oder SIO2 fallen auf generische Begriffe zurück.
Zubehörbegriff als Hauptprodukt gepflegt	Zubehörfragen werden als Gerätefragen beantwortet.
Exakte Code-Regel zu weich	300 zieht Varianten wie 300 S oder andere Codes in die Antwort.
Product-list Patterns zu breit	Follow-ups erzeugen falsche oder kombinierte Produktqueries.
Promptregel zu allgemein	Antworten werden sales-lastig oder enthalten nicht belegte Details.
Regression-Baseline nicht angepasst	stabile Flows können unbemerkt brechen.

---

9. Entscheidungsregeln

Wertart	Richtiger Ort
Geräte-/Zubehörwort	product_roles
Messparameter oder Attribut	product_attributes oder measurement_evidence_maps
Markenname / Produktfamilie	brands_and_canonical_terms.known_brands
Schreibvariante / Tippfehler	brands_and_canonical_terms.canonical_terms oder Commerce-Korrektur
Shopquery-Stopword	shop_query_runtime.stopword_cleanup
erhaltenswertes Shop-Token	shop_query_runtime.positive_token_filter.allowed_terms
verbotener Shop-Noise	shop_query_runtime.positive_token_filter.blocked_terms
generische Gerätefrage zu konkretem Produktanker	shop_query_runtime.generic_device_anchor.anchor_rules
Follow-up aus Verlauf	context_resolution
Antwort-/Promptgrenze	result_identity_and_answer_policy.prompt_rules
Search-Repair-Muster	search_repair
Regression-Schutz	governance_and_regression

---

10. Minimalbeispiele

10.1 Neues Zubehör-Synonym ergänzen

configuration_values:
  product_roles:
    accessory_product_terms:
      terms:
        - indikator
        - reagenz
        - kalibrierpuffer

Danach testen:

php bin/console mto:agent:config:validate
php bin/console mto:agent:regression:test

10.2 Neues Modellkürzel schützen

configuration_values:
  shop_query_runtime:
    positive_token_filter:
      adjacent_variant_terms:
        - lab
        - cl
        - sio2

Zusätzlich prüfen, ob das Kürzel auch in retrieval_and_language.protected_terms oder Governance-Guardrails geschützt werden muss.

10.3 Neue generische Geräteanker-Regel

configuration_values:
  shop_query_runtime:
    generic_device_anchor:
      anchor_rules:
        - anchor: example device xy
          template: "{anchor}"
          match_terms:
            - beispielparameter
            - beispielüberwachung

Danach praktische Shop- und Retrievaltests ausführen.

---

11. Kurzfazit

genre.yaml ist in RetrieX v1.6.0 die zentrale fachliche Steuerdatei. Sie hält die Domänenlogik aus dem PHP-Core heraus und macht Produktrollen, Query-Verhalten, Follow-up-Auflösung, Shop-Matching, Promptgrenzen und Regression-Guards reviewbar.

Neue fachliche Werte sollen hier oder in den angebundenen YAML-Views gepflegt werden. Nach jeder Änderung müssen Config-Validierung, Source-Audit, Pattern-Audit und Regressionstest grün bleiben.