# VG-Core Inventory

## Bereits vorhandener Core

- `src/core/README.md`
- `src/core/module-registry.js`

## Core-Kandidaten, noch nicht verschieben

| Pfad | Vermutete Core-Funktion | Risiko bei Verschiebung | Kurze Begründung |
| --- | --- | --- | --- |
| `src/background/utils.js` | Gemeinsame Hilfsfunktionen für Hashing und stabile Serialisierung | mittel | Wird als generische Grundlage genutzt, hängt aber aktuell implizit an der Script-Ladereihenfolge im Background-Kontext. |
| `src/background/settings.js` | Globale Enable/Disable-Einstellungen | mittel | Enthält modulübergreifend wirkende Schalter, ist aber noch konkret an Consent- und Request-Monitoring benannt. |
| `src/background/maintenance-guard.js` | Gemeinsame Evidence-Schreibsperre für Wartungs-/Admin-Vorgänge | niedrig | Kapselt eine kleine globale Sperrlogik ohne direkte Fachauswertung; Abhängigkeiten wirken überschaubar. |
| `src/background/db/db-constants.js` | Gemeinsame IndexedDB-Namen, Version und Store-Liste | hoch | Zentral für DB-Version und Store-Namen; jede Verschiebung berührt Ladeordnung und Migrationsrisiko. |
| `src/background/db/db-core.js` | Gemeinsames IndexedDB-Öffnen und Store-Anlage | hoch | Enthält konkrete Object-Store-Erzeugung inklusive Consent-, Request- und GVL-Stores; sehr sensibel für DB-Kompatibilität. |
| `src/background/db/db-retention.js` | Gemeinsame Evidence-Zählung und Retention-Helfer | mittel | Arbeitet über alle Evidence-Stores und wirkt infrastrukturell, ist aber an die aktuelle Store-Liste gekoppelt. |
| `src/background/db/db-record-locks.js` | Gemeinsame Record-Lock-Operationen für Evidence-Daten | mittel | Modulübergreifende Sperrlogik, aber direkt an alle Evidence-Stores und deren Felder gebunden. |
| `src/background/gvl/gvl-catalog-normalizer.js` | Normalisierung gemeinsamer GVL-Katalogdaten | hoch | Könnte später gemeinsame Vendor-/GVL-Wissensbasis stützen, ist aktuell aber eng mit GVL-Snapshots und IndexedDB-Schreibzugriff verbunden. |
| `src/background/gvl/gvl-vendor-normalizer.js` | Normalisierung gemeinsamer Vendor-Stammdaten | hoch | Potenziell modulübergreifend wertvoll, aber derzeit aus konkreten GVL-Snapshots abgeleitet und DB-gekoppelt. |
| `src/background/gvl/gvl-vendor-relationship-normalizer.js` | Normalisierung gemeinsamer Vendor-Beziehungen | hoch | Potenziell Teil einer Wissensbasis, aber noch an Snapshot-Verarbeitung und Store-Struktur gebunden. |

Hinweis: `src/shared/`, `src/common/` und `src/utils/` wurden im aktuellen Bestand nicht gefunden.

## Eindeutig nicht Core

- `src/modules/vg-observe/`: VG-Observe ist das aktive Fachmodul für Beobachtung / Consent / TCF / GVL / Evidence.
- `src/modules/vg-block/`: Fachmodul für Block-/Interventionslogik.
- `src/modules/vg-graph/`: Fachmodul für Graphvisualisierung.
- `src/background.js`: Enthält VG-Observe-spezifische TCF-/CMP-Beobachtung, TC-String-Auswertung, Consent-State-Persistenz, GVL-Fetch und Evidence-Persistenz.
- `src/background/consent-memory.js`: Fachliche Zwischenspeicherung beobachteter TCF-/Consent-Zustände.
- `src/background/request-observer.js`: Request-Beobachtung und Korrelation mit Consent-State.
- `src/background/request-fingerprint.js`: Request-Fingerprinting mit Consent-Query-Parametern.
- `src/background/gvl-service.js`: Konkrete GVL-Snapshot-Erfassung, Hashing, Speicherung und Event-Erzeugung.
- `src/content/tcf-listener.js`: Content-seitige TCF-/CMP-Beobachtung.
- `src/injected/tcf-bridge.js`: Injected Bridge zur TCF-/CMP-Erfassung und TC-String-Capture.
- `src/popup/`: UI-spezifische Popup-Logik und Darstellung.
- `src/dashboard/`: UI-spezifische Dashboard-, Admin- und Evidence-Ansichten.

## Altbegriffe als Fundstellen

- `VendorGet-IV`: gefunden in `src/popup/popup.html`, `src/popup/popup.js`, `src/dashboard/dashboard.html`, `src/dashboard/dashboard.js`, `src/background/request-observer.js`.
- `VG-IV`: gefunden in `src/dashboard/dashboard.html`, `src/dashboard/dashboard.js`, `src/background/request-observer.js`.
- `vendorget_iv`: gefunden in `src/background/db/db-constants.js`.

Diese Altbegriffe werden hier nur dokumentiert und nicht umbenannt.

## Nächster risikoarmer Schritt

Als nächsten kleinen Schritt eine zweite reine Dokumentationsdatei oder einen Abschnitt ergänzen, der die aktuelle Script-Ladereihenfolge und Abhängigkeiten der Background-Dateien beschreibt. Kein Refactor, keine Verschiebung, keine DB-Migration.
