# VG-Core Load Order

## Manifest-Ladereihenfolge

Die Background-Scripts werden laut `manifest.json` in dieser Reihenfolge geladen:

| Reihenfolge | Script | Einordnung |
| --- | --- | --- |
| 1 | `src/core/module-registry.js` | Core |
| 2 | `src/modules/vg-observe/module.js` | Fachmodul |
| 3 | `src/background/db/db-constants.js` | Core-Kandidat |
| 4 | `src/background/db/db-core.js` | Core-Kandidat |
| 5 | `src/background/gvl/gvl-vendor-normalizer.js` | Core-Kandidat |
| 6 | `src/background/gvl/gvl-vendor-relationship-normalizer.js` | Core-Kandidat |
| 7 | `src/background/gvl/gvl-catalog-normalizer.js` | Core-Kandidat |
| 8 | `src/background/db/db-retention.js` | Core-Kandidat |
| 9 | `src/background/db/db-record-locks.js` | Core-Kandidat |
| 10 | `src/background/utils.js` | Core-Kandidat |
| 11 | `src/background/settings.js` | Core-Kandidat |
| 12 | `src/background/maintenance-guard.js` | Core-Kandidat |
| 13 | `src/background/consent-memory.js` | Fachmodul |
| 14 | `src/background/request-fingerprint.js` | Fachmodul |
| 15 | `src/background/request-observer.js` | Fachmodul |
| 16 | `src/background/gvl-service.js` | Fachmodul |
| 17 | `src/background.js` | Fachmodul |

## Globale Abhängigkeiten

- `globalThis.VGCoreModuleRegistry`: wird in `src/core/module-registry.js` gesetzt und in `src/modules/vg-observe/module.js` zur Registrierung von `VGObserveModule` verwendet.
- `globalThis.VGObserveModule`: wird in `src/modules/vg-observe/module.js` gesetzt.
- `globalThis.VendorGetGvlService`: wird in `src/background/gvl-service.js` gesetzt und in `src/background.js` für `ingestGvlSnapshot` verwendet.
- `globalThis.normalizeGvlVendorsFromSnapshot` und `globalThis.normalizeLatestGvlSnapshotVendors`: werden in `src/background/gvl/gvl-vendor-normalizer.js` gesetzt.
- `globalThis.normalizeGvlVendorRelationshipsFromSnapshot` und `globalThis.normalizeLatestGvlVendorRelationships`: werden in `src/background/gvl/gvl-vendor-relationship-normalizer.js` gesetzt.
- `globalThis.normalizeGvlCatalogsFromSnapshot` und `globalThis.normalizeLatestGvlCatalogs`: werden in `src/background/gvl/gvl-catalog-normalizer.js` gesetzt.
- `browser.runtime.onMessage` und `browser.webRequest.onBeforeRequest`: werden in `src/background.js` registriert.
- `browser.storage.local.get` und `browser.storage.local.set`: werden in `src/background/settings.js` verwendet.
- `indexedDB.open` und `indexedDB.deleteDatabase`: werden in `src/background/db/db-core.js` verwendet.
- `crypto.subtle.digest` und `TextEncoder`: werden in `src/background/utils.js` und `src/background/gvl-service.js` verwendet.
- `fetch`: wird in `src/background.js` für den offiziellen IAB-GVL-Abruf verwendet.
- `URL`: wird in `src/background/request-fingerprint.js` und `src/background/request-observer.js` zur Request-Auswertung verwendet.
- `atob`: wird in `src/background.js` beim Decoding von TC-String-Core-Metadaten verwendet.

Weitere implizite globale Funktionsabhängigkeiten entstehen durch nicht-modulare Script-Ladung:

- `src/background/db/db-core.js` erwartet `VENDORGET_DB_NAME` und `VENDORGET_DB_VERSION` aus `src/background/db/db-constants.js`.
- `src/background/db/db-retention.js` und `src/background/db/db-record-locks.js` erwarten `VENDORGET_EVIDENCE_STORE_NAMES` aus `src/background/db/db-constants.js`.
- `src/background/request-fingerprint.js` erwartet `sha256Hex` und `stableStringify` aus `src/background/utils.js`.
- `src/background/request-observer.js` erwartet `isRequestMonitoringEnabled`, `isEvidenceWriteSuspended`, `buildObservedRequestFingerprint`, `buildObservedRequestFingerprintSource`, `getLatestConsentStateForRequest` und `persistObservedRequest`.
- `src/background.js` erwartet unter anderem `handleObservedRequest`, `isConsentCaptureEnabled`, `rememberLatestTcfPing`, `getLatestTcfPing`, `sha256Hex`, `stableStringify`, `rememberLatestConsentState`, `openVendorGetDb`, Retention-/Lock-Funktionen und `VendorGetGvlService`.

## Core-relevante Risiken

- Ladeordnungsrisiko: `src/modules/vg-observe/module.js` registriert sich nur, wenn `globalThis.VGCoreModuleRegistry` bereits existiert. Die aktuelle Reihenfolge erfüllt das, ist aber empfindlich gegen Manifest-Änderungen.
- Implizite globale Abhängigkeiten: Viele Background-Scripts exportieren keine Module, sondern stellen Funktionen durch gemeinsame Script-Ausführung bereit. Verschiebungen können dadurch Laufzeitfehler erzeugen, ohne dass Imports brechen.
- DB-Konstanten / DB-Version: `src/background/db/db-constants.js` definiert `VENDORGET_DB_VERSION = 5` und die Store-Namen. `src/background/db/db-core.js` nutzt diese Werte direkt für `indexedDB.open` und Store-Anlage.
- Kopplung zwischen Core-Kandidaten und VG-Observe: DB-, Retention-, Record-Lock-, Settings- und GVL-Normalizer-Dateien wirken infrastrukturell, enthalten aber Namen, Stores oder Datenflüsse aus Consent, Request, Evidence und GVL-Snapshot-Logik.
- GVL-Kopplung: Normalizer können später Teil einer gemeinsamen Wissensbasis sein, sind aktuell aber an Snapshot-Stores und Background-DB-Zugriffe gekoppelt.

## Nicht ändern

- keine Script-Reihenfolge ändern
- keine `manifest.json` ändern
- keine DB-Version ändern
- keine Dateien verschieben

## Nächster risikoarmer Schritt

Als nächsten kleinen Schritt eine reine Dokumentations-Tabelle ergänzen, die je Background-Script die erwarteten vorausgehenden globalen Funktionen und die bereitgestellten globalen Funktionen beschreibt. Kein Refactor, keine Migration, keine Umbenennung.