Services et données¶

La migration 0037_buildings ajoute les agrégats immobiliers, permissions de groupe ciblées et rattachements optionnels aux garages/stockages. 0038_merge_buildings converge ensuite cette branche avec 0037_merge_crafting_vehicles sans DDL ni DML. 0039_building_timestamps est le head attendu par la readiness et ajoute les defaults PostgreSQL now() manquants aux timestamps des tables immobilières. Les deux migrations 0037 publiées restent immuables. Les achats et recoveries restent atomiques. Voir Architecture technique de l'immobilier.

Services Compose¶

Service	Responsabilité	Exposition par défaut
`database`	PostgreSQL 16, vérité métier	interne
`redis`	cache, sessions, verrous	interne
`api`	FastAPI et migrations	`8000` interne
`admin`	UI nginx et proxy API	`8080`
`bot`	Discord, OAuth et mutations de rôles	`8081` interne
`fivem`	FXServer et txAdmin	`30120` TCP/UDP, `40120`
`docs`	site MkDocs Material statique	`8001`
`logs-init`	création des fichiers de logs	ponctuel
`log-maintenance`	rotation des logs	interne

Persistance¶

Les volumes nommés conservent PostgreSQL, Redis, les artefacts FXServer, txAdmin et les ressources FiveM. Chaque application dispose d'un volume de logs. L'API monte ceux des autres services en lecture seule pour la consultation administrative. Les volumes restent automatiquement isolés par le nom de projet Compose. logs-init s'exécute explicitement comme root, crée les fichiers partagés puis attribue /logs/database et postgresql.log à l'UID/GID 70:70 utilisé par postgres:16-alpine. Les permissions 0775/0664 permettent à PostgreSQL d'ouvrir son journal tout en conservant sa lecture par l'API. L'image database/Dockerfile ajoute une seconde garantie indépendante de l'ordonnancement Compose. Son wrapper démarre comme root, recrée et réattribue le journal, vérifie qu'il est inscriptible puis délègue à /usr/local/bin/docker-entrypoint.sh. L'entrypoint officiel conserve donc seul la gestion de PGDATA, d'initdb et de la descente de privilèges vers l'utilisateur postgres.

Les comptes sont liés de manière unique à Discord. Les personnages référencent leur compte et conservent identité, argent en dollars RP entiers, apparence, vêtements, position et état de recustomisation. Les notes whitelist, rôles administrés, grants, contenu du loading screen, actions de modération et audit sont persistés dans PostgreSQL.

Les vêtements sont séparés de la morphologie dans le JSON characters.clothing, sous la forme components et props. Cette séparation permet aux magasins de remplacer une tenue sans modifier le visage, les cheveux, les tatouages ou le modèle du personnage.

Les inventaires et leurs instances occupent des tables dédiées. Un verrou transactionnel sur l'inventaire et une révision monotone sérialisent les mutations, y compris pour les futurs inventaires partagés.

Redis utilise notamment les clés préfixées :

gta:player:{fivem_identifier}
gta:character:{character_id}
gta:session:{source_id}
gta:lock:{resource}:{identifier}

Le préfixe est configurable avec REDIS_KEY_PREFIX.

La readiness ne déduit plus l'état du schéma de quelques tables historiques. Elle résout une fois l'unique head du répertoire Alembic embarqué et la compare à alembic_version. Une base joignable mais en retard est ainsi exposée comme schema: outdated et bloque le démarrage FiveM.

ARPhone¶

La migration 0029_arphone porte implants, bindings, communications et médias. PostgreSQL conserve le durable, Redis grants/rate limits/typing/appels temporaires, et arphone_media les WebP. ON DELETE SET NULL conserve l'implant lors de la suppression du personnage.

Les véhicules enregistrés occupent registered_vehicles; leurs droits physiques sont normalisés dans vehicle_keys, les points de service dans vehicle_locksmiths et l'idempotence des mutations dans vehicle_request_receipts. La plaque est unique, le propriétaire personnage/groupe est un XOR et la metadata de l'item n'est jamais la source de vérité. Les snapshots de position, d'apparence et de dégâts sont enregistrés au plus toutes les vingt secondes.

Migration véhicules 0033¶

0033_vehicle_handling_storage succède à 0032_vehicle_garages et ajoute sans modifier les dossiers, clés ou inventaires existants :

vehicle_handling_sources, vehicle_handling_profiles, vehicle_handling_profile_versions et vehicle_handling_assignments ;
vehicle_compartments, vehicle_temporary_compartments et vehicle_compartment_overrides ;
vehicle_compartment_events pour idempotence, audit fonctionnel et notification propriétaire.

La migration insère trois ORIGINAL immuables et dix profils standards, tous sans affectation. Elle ne matérialise aucun compartiment existant au déploiement : le couple coffre/boîte à gants est créé une seule fois au premier résumé ou accès. Les clés étrangères utilisent les UUID stables et les contraintes imposent portée, type, révision et unicité. La readiness attend exactement le head 0033_vehicle_handling_storage avant d'exposer les nouveaux modules.

alembic_version.version_num conserve la capacité standard PostgreSQL de 32 caractères. Tous les identifiants de révision du dépôt sont validés avant alembic upgrade head et par les tests API ; une révision plus longue bloque la construction/recette avec son identifiant et sa longueur, avant toute tentative de migration.

Préférences compteur 0036¶

0036_speedometer_placement succède à 0035_speedometer_cruise_v2 sans modifier les migrations publiées. vehicle_speedometer_preferences reste one-to-one avec player_accounts et conserve thème, visibilité, éclairage, révision, timestamps et cascade. La migration ajoute scale_percent, position_x et position_y, transforme small/normal/large en 80/100/120 et initialise le bas-centre (0.5,0.8).

PostgreSQL impose une échelle entière comprise entre 60 et 140 et divisible par 5, ainsi que deux coordonnées finies dans [0,1]. La colonne size reste présente pour la compatibilité de lecture des anciennes applications, mais n'appartient plus au contrat v3 ni à l'empreinte d'une nouvelle écriture. Le régulateur n'a aucun stockage actif ; les colonnes historiques d'Alembic ne sont pas réécrites ni supprimées.

Domaine énergie¶

La migration 0038_vehicle_energy a introduit catalogue, prix, stations, sessions, paiements, jobs, préférences et événements avec UUID stables. 0039_vehicle_energy_simple constitue la transition historique Essence seule. La révision forward-only 0040_vehicle_lc_fuel rétablit les trois propulsions actives, six produits, états de réservoir/composition, préférences de blips, 26 chargeurs, 14 points spécialisés et la rétention 90/365 jours. Elle conserve les 22 anciens points électriques 0038 archivés et ne réécrit aucun historique terminal. Le schéma et ses règles de conservation sont documentés dans Énergie des véhicules.