Verticale Gaming¶

Status: TARGET

Cette page décrit le contrat cible de la verticale Gaming. Elle ne prouve pas qu’un module Gaming complet est actuellement branché au Runtime.

Rôle¶

La verticale Gaming doit encapsuler les règles propres aux consoles, jeux vidéo et accessoires gaming lorsque ces règles ne peuvent pas rester génériques dans le Domain Core.

Elle peut contribuer à :

l’identification d’une famille de console ;
la distinction entre jeu, console et accessoire ;
la compatibilité plateforme ;
la génération de candidats spécialisés ;
la détection de conflits propres au domaine ;
les attributs spécialisés destinés aux projections.

Elle ne remplace ni le Resolver, ni le Projection Builder, ni les Write Services.

La présence de feuilles Gaming dans :

plugins/ccx-feeds-industrial/includes/application/navigation-architecture.php

ne signifie pas qu’une verticale Gaming métier complète est active.

La navigation décrit une architecture publique. L’existence d’un module vertical Runtime doit être prouvée séparément dans le registre, le bootstrap et le code métier.

Périmètre cible¶

Le domaine peut notamment couvrir :

consoles ;
jeux vidéo ;
manettes ;
casques gaming ;
accessoires de recharge ;
sim racing ;
joysticks ;
cockpits et sièges.

Ces familles ne doivent pas être fusionnées simplement parce qu’elles appartiennent toutes à l’univers public Gaming.

Attributs structurants¶

Selon la famille, les preuves utiles peuvent inclure :

marque ;
plateforme ;
génération ;
modèle ;
édition ;
type d’accessoire ;
compatibilité déclarée ;
support physique ou dématérialisé ;
région lorsque cette information est réellement structurante.

Une valeur absente reste unknown. Elle ne doit pas être déduite d’un simple mot marketing ou d’une proximité de titre.

Conflits à préserver¶

Exemples de conflits potentiellement bloquants :

jeu PlayStation contre jeu Xbox ;
accessoire explicitement compatible avec une autre plateforme ;
console et accessoire confondus ;
génération incompatible ;
modèle de console incompatible ;
type d’accessoire différent malgré un titre proche.

Le module doit pouvoir retourner les statuts communs :

resolved ;
unknown ;
ambiguous ;
conflict.

Il ne doit jamais transformer une compatibilité incertaine en résolution certaine.

Reason codes¶

Les reason codes cibles doivent rester stables et orientés métier, par exemple :

gaming.platform.exact
gaming.platform.unknown
gaming.generation.conflict
gaming.accessory_type.conflict
gaming.compatibility.ambiguous

Ces noms sont des exemples de contrat documentaire, pas une preuve d’implémentation actuelle.

Projection¶

Une projection Gaming peut exposer des attributs spécialisés, mais elle ne doit pas recalculer la compatibilité ou l’identité.

Le flux attendu reste :

preuves normalisées
    ↓
verticale Gaming
    ↓
Resolver / décision commune
    ↓
Projection Builder
    ↓
Write Service

Industrialisation¶

Avant toute activation Runtime, la verticale doit passer par :

inventaire des données réelles ;
définition des familles et attributs structurants ;
audits read-only ;
mesure des unknown, ambiguous et conflict ;
simulation des règles locales ;
comparaison avant/après ;
tests de non-régression inter-verticales ;
activation ciblée seulement après validation.

Garde-fous¶

Ne jamais :

déplacer une règle Gaming dans le Core sans preuve multi-verticale ;
utiliser la navigation publique comme preuve de résolution métier ;
écrire directement depuis une règle Gaming ;
considérer un titre similaire comme preuve suffisante de compatibilité ;
masquer un conflit de plateforme pour améliorer artificiellement un KPI.

État de transmission¶

Cette page doit être lue comme un guide de préparation. Pour savoir si Gaming est réellement disponible dans un environnement donné, vérifier le code Runtime et les commandes enregistrées avant toute conclusion.