GitCover Symbol GCBoKGitCover Body of Knowledge

Namespace-Prefix und V7GUID-Identitätsmodell

Architektur-Entscheidung vom 2026-07-26. Dokumentiert in GitCover.Discovery/plans/ADR-001_namespace_prefix_gitcover.md.

Ausgangsfrage

Soll der lange C#-Namespace-Prefix GitCover.Discovery für eine spätere OSS-Veröffentlichung beibehalten oder gekürzt ohne Prefix (Discovery.*) gearbeitet werden?

Hintergrund: Bei dynamischer Zusammenarbeit zwischen Developern, AI Agents und MCP Services, die alle dynamisch miteinander arbeiten, könnten „absolute" Namespaces die Grenzen verwischen — denn das V7GUID-Konzept nutzt die ersten 48 Bit für die Tenant-ID und Typen werden mindestens auf der Tool-Ebene registriert, können aber auf Tenant- oder Repo-Ebene (Organisations-Ebene) re-definiert werden, damit bei GCEP zwischen Repos Eindeutigkeit herrscht, unabhängig von DLL-Versionen oder Prozess-Instanzen.

Das V7GUID-Identitätsmodell

Das V7GUID-Konzept legt Identität und Typisierung vollständig auf der Bit-Ebene fest:

Tenant-Identität (Bits 0–47)

Die Tenant-Identität leitet sich aus dem 48-Bit-Zeitstempel der Gründungs-UUIDv7 ab. Sie ist deterministisch in der GUID kodiert — der C#-Namespace transportiert keine zusätzliche Identitätsinformation.

repository_id (Bits 52–63, 12 Bit, 0–4095)

Adressiert ein Repository innerhalb eines Tenant-Kontexts. Pro Tenant gibt es genau ein TOP-Repository (id=1) und bis zu 4.095 weitere. Die Eindeutigkeit herrscht durch die repository_id, nicht durch den C#-Namespace.

kind (Bits 114–121, 8 Bit) — zentrale normative Registry

Normiert die Art der Tätigkeit repo-übergreifend und ersetzt lösungsspezifische Enums (RepoKind, ArtifactKind in GitCover.Discovery; Prozesstyp in GCP.Portfolio; Type in GCPN). Die zentrale kinds.json wird im OSS-Normative-Root (git.gitcover.org/OSS/TOP/.gitcover/dictionaries/) gepflegt.

Dual-Identifier (classification, uuid)

Trennt Class Identifier (was/Typ, deterministisch in Bits kodiert) und Object ID (welches konkrete Objekt, reines uuidv7). Beide zusammen bilden den Composite Key — der Namespace ist darin nicht enthalten.

Warum der Namespace-Prefix neutral ist

Der C#-Namespace-Prefix GitCover. suggeriert eine „absolute Identität", die im V7GUID-Modell nicht vorgesehen ist. Er ist für das Identitäts- und Typisierungsmodell neutral:

Gründe für die Beibehaltung

Argument Begründung
Markenkonsistenz Alle 18 Solutions in Development/Solutions/ nutzen den Prefix (bis auf historische Ausnahmen wie GCP/GCEP). Für die OSS-Veröffentlichung unter git.gitcover.org/GCC-OSS/<repo> signalisiert GitCover.* die Herkunft.
NuGet-Kollisionsfreiheit Ein schlichtes Discovery.* kollidiert leicht mit Drittanbieter-Paketen; GitCover.Discovery ist global eindeutig.
Lizenz-Sichtbarkeit Das IPLicensing-Modell (Open-Core, Field-of-Use-Taxonomie) benutzt den Namespace als Marker für Herkunft und Lizenz-Zugehörigkeit.
Solution-Ökosystem-Konsistenz Solution-übergreifende Bundles (GCEP-Federation, MCP-Hub) referenzieren heute GitCover.Core, GitCover.V7Guid — ein gekürzter Namespace bricht diese Kette.

Konsequenz für die dynamische Zusammenarbeit

Der C#-Namespace ist kein Identitätsmedium für:

Fazit

Der C#-Namespace-Prefix GitCover. wird als Bezeichner-Konvention beibehalten — nicht als Identitätsmedium. Identität und Typ-Eindeutigkeit herrschen durch das V7GUID-Modell (Tenant-ID in Bits 0–47, repository_id in Bits 52–63, kind-Registry in Bits 114–121). Der Prefix ist für die dynamische Zusammenarbeit zwischen Developern, AI Agents und MCP Services neutral — er transportiert keine Identitätsinformation, die nicht ohnehin in der V7GUID deterministisch kodiert ist.

Quellen