4.3 KiB
4.3 KiB
VG-Core Inventory
Bereits vorhandener Core
src/core/README.mdsrc/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 insrc/popup/popup.html,src/popup/popup.js,src/dashboard/dashboard.html,src/dashboard/dashboard.js,src/background/request-observer.js.VG-IV: gefunden insrc/dashboard/dashboard.html,src/dashboard/dashboard.js,src/background/request-observer.js.vendorget_iv: gefunden insrc/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.