# RetrieX Patch p43F - Search Repair Accessory Code Vocabulary View

## Ziel

p43F setzt auf dem gruen bestaetigten p43E-Stand auf und reduziert weitere doppelte SearchRepair-Begriffslisten ohne fachliche Runtime-Aenderung.

Der Patch zentralisiert die mehrfach gepflegten Zubehoercode-Begriffe fuer SearchRepair in `config/retriex/vocabulary.yaml` und laesst lokale Overrides in `config/retriex/search_repair.yaml` weiterhin zu.

## Geaenderte Dateien

- `config/retriex/vocabulary.yaml`
- `config/retriex/search_repair.yaml`
- `src/Config/SearchRepairConfig.php`
- `patch_history/RETRIEX_PATCH_43F_SEARCH_REPAIR_ACCESSORY_CODE_VOCABULARY_VIEW_README.md`

## Inhalt

### vocabulary.yaml

Neu zentral gepflegte Klassen:

- `requested_accessory_code_terms`
- `shop_meta_terms`

Neue SearchRepair-Views:

- `search_repair.requested_accessory_code_terms`
- `search_repair.model_candidate_exclude_terms`

Die View `search_repair.requested_accessory_code_terms` liefert die bisherigen Begriffe fuer:

- `requested_accessory_code_fallback_terms`
- `requested_accessory_code_context_prefix_terms`

Die View `search_repair.model_candidate_exclude_terms` liefert die bisherigen Modell-Exclude-Begriffe aus Zubehoercode-Begriffen plus Shop-/Verfuegbarkeits-Metabegriffen.

### search_repair.yaml

Lokale Listen wurden entfernt fuer:

- `requested_accessory_code_fallback_terms`
- `requested_accessory_code_context_prefix_terms`
- `model_candidate_exclude_terms`

Die YAML-Datei dokumentiert jetzt, dass diese Werte aus `vocabulary.yaml` kommen und lokale Listen weiterhin als explizite Projekt-Overrides wieder hinzugefuegt werden koennen.

### SearchRepairConfig.php

Die drei Accessoren nutzen nun den vorhandenen Mechanismus `configOrVocabularyStringList()`:

- `getRequestedAccessoryCodeFallbackTerms()`
- `getRequestedAccessoryCodeContextPrefixTerms()`
- `getModelCandidateExcludeTerms()`

Damit bleibt das bisherige Override-Verhalten erhalten: lokale YAML-Listen haben Vorrang, sonst wird die zentrale Vocabulary-View verwendet.

## Explizit nicht geaendert

- keine neue fachliche Runtime-Logik
- keine Scoring-Aenderung
- keine Retrieval-Aenderung
- keine Prompt-Regel-Aenderung
- keine Admin-UI
- keine neuen harten Listen im PHP-Core
- keine Aenderung an Pattern-Templates oder Regex-Semantik

## Effektive Listen vor/nach p43F

Verglichen wurde p43E-Basis gegen p43F-Arbeitsstand:

- `requested_accessory_code_fallback_terms`: 5 / 5, identisch
- `requested_accessory_code_context_prefix_terms`: 5 / 5, identisch
- `model_candidate_exclude_terms`: 8 / 8, identisch
- `direct_product_attribute_lookup.product_type_terms`: 12 / 12, identisch
- `direct_product_attribute_lookup.stop_terms`: 40 / 40, identisch
- `generic_candidate_tokens`: 13 / 13, identisch
- `accessory_candidate_terms`: 6 / 6, identisch
- `accessory_or_bundle_terms`: 14 / 14, identisch
- `specificity_boost_terms`: 7 / 7, identisch

## Lokal ausgefuehrte Checks

```bash
php -l src/Config/SearchRepairConfig.php
php -l src/Config/AgentRunnerConfig.php
python3 YAML parse check fuer geaenderte YAML-Dateien
python3 effektive SearchRepair-Listen p43E vs p43F vergleichen
```

Ergebnis: gruen.

## Nicht lokal ausfuehrbar

Die Symfony-Console-Checks konnten in der ChatGPT-Arbeitsumgebung nicht ausgefuehrt werden, weil der entpackte ZIP-Stand kein `vendor/` enthaelt und in dieser Umgebung kein `composer` verfuegbar ist.

Blockierender Fehler:

```text
Dependencies are missing. Try running "composer install".
```

Bitte nach dem Einspielen im Projekt ausfuehren:

```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
```
