Verticale Mobility¶

Status: TARGET

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

Rôle¶

La verticale Mobility doit encapsuler les règles propres aux produits de mobilité personnelle lorsque leur sémantique ne peut pas être gérée proprement par le Domain Core générique.

Elle peut notamment couvrir :

trottinettes électriques ;
vélos électriques ;
vélos ;
VTT ;
hoverboards ;
gyropodes ;
gyroroues ou autres familles voisines si les données réelles le justifient.

Le module doit fournir des preuves spécialisées au Resolver sans devenir lui-même moteur de résolution ou service d’écriture.

Le registre public peut déclarer plusieurs feuilles de mobilité dans :

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

Certaines feuilles peuvent utiliser des vertical IDs ou accessory_types différents.

Cette architecture publique ne constitue pas une preuve qu’une verticale métier unifiée mobility est active. Avant tout travail Runtime, vérifier le registre vertical et le code réellement chargé.

Attributs structurants cibles¶

Selon la famille, les preuves utiles peuvent inclure :

marque ;
modèle ;
type de véhicule ;
motorisation ;
puissance ;
capacité de batterie ;
autonomie annoncée ;
taille ou géométrie pertinente ;
compatibilité d’accessoire lorsqu’il ne s’agit pas du produit principal.

Tous ces attributs ne doivent pas automatiquement participer à l’identité. Leur rôle doit être établi par audit sur des données réelles.

Famille produit avant variante¶

Le premier garde-fou consiste à ne pas confondre des familles différentes.

Par exemple, une trottinette électrique et un vélo électrique peuvent partager :

une marque ;
une batterie ;
une puissance ;
certains mots marketing.

Cela ne les rend pas compatibles.

La famille produit doit donc être établie avant l’évaluation fine des variantes.

Conflits à préserver¶

Exemples de conflits potentiellement bloquants :

type de véhicule différent ;
modèle explicitement différent ;
motorisation ou version incompatible lorsqu’elle définit une variante ;
taille incompatible lorsqu’elle fait partie de l’identité produit ;
produit principal confondu avec accessoire ;
marque incompatible.

Les statuts communs restent :

resolved ;
unknown ;
ambiguous ;
conflict.

Une autonomie ou une puissance proche n’est pas une preuve suffisante de résolution.

Reason codes¶

Exemples de codes cibles :

mobility.product_type.exact
mobility.model.exact
mobility.product_type.conflict
mobility.variant.ambiguous
mobility.battery.unknown

Ils sont documentaires tant qu’ils ne sont pas confirmés dans l’implémentation.

Projection¶

Les attributs de mobilité destinés au Frontend doivent être préparés par le flux normal :

preuves normalisées
    ↓
verticale Mobility
    ↓
Resolver
    ↓
Projection Builder
    ↓
Write Service
    ↓
Frontend

Le Frontend ne doit pas déduire une autonomie, une famille ou une compatibilité depuis le titre marchand.

Industrialisation¶

Avant activation :

constituer un échantillon réel par famille ;
inventorier les attributs disponibles et leur fiabilité ;
identifier les confusions produit/accessoire ;
définir les conflits réellement bloquants ;
exécuter des audits read-only ;
simuler les règles ;
mesurer les unknown, ambiguous et conflict ;
vérifier les régressions sur les autres verticales ;
activer seulement le périmètre validé.

Garde-fous¶

Ne jamais :

fusionner toutes les familles de mobilité dans une seule identité générique ;
considérer une caractéristique proche comme preuve d’identité ;
utiliser la navigation publique comme règle métier ;
écrire depuis le module ;
forcer une résolution lorsque la taille, le modèle ou le type restent ambigus.

État de transmission¶

Cette page est un guide TARGET. Elle doit servir à préparer l’industrialisation, pas à affirmer que Mobility est déjà disponible dans le Runtime.