Liste des changements RTM

4.6.0-0154 — réception Cloud en validation

Une incompatibilité de dates pouvait bloquer la réception des journées et dossiers du Cloud. Le connecteur accepte désormais le format UTC émis par le Cloud, en conservant les preuves et les contrôles existants.

Les places, quotas et règles de paiement restent inchangés : une nouvelle admission exige toujours un paiement confirmé par le Cloud. Cette candidate doit encore recevoir sa recette sur le Rock 5B.

4.6.0-0153 — stabilisation en développement

La candidate se concentre sur la stabilité des sessions et la synchronisation courante, avec une recette prévue sur le Rock 5B et une validation distincte de la double authentification Cloud. Les reprises avancées et les autres nouveautés sont reportées ; leur nouvelle capacité reste non annoncée.

La synchronisation et la continuation de journée lient leurs commandes à la session affichée : une ancienne réponse ou un ancien bouton ne peut plus agir sur une nouvelle vue. Les reçus restent disponibles pour une nouvelle tentative explicite, sans renvoi automatique.

La vue prépare les portées physiques et le retrait explicite de références lorsque le serveur fournit ces preuves. Les anciens historiques restent lisibles quand leurs mutations sont déclarées indisponibles ; le parcours Pending v3 et la continuation commerciale restent distincts. Les dix langues sont conservées.

Le gel précédent a réussi 149 tests Python, 68 cas Node et 17 cas Chromium ciblés. Le complément de synchronisation a ensuite réussi ses 66 cas Node avec DOM synthétique, sans échec ni omission. L’intégration HTTP/SQL et la recette du nouvel artefact sur Rock 5B restent à qualifier.

Le nouveau parcours de reprise traite une reconstruction interrompue dont la base cible n’a pas reçu son activation finale. Les effets déclarés par le Cloud et les effets inconnus restent distincts ; les pertes et exclusions doivent être examinées avant toute décision administrative.

Les anciennes bases ne retrouvent aucun droit et les places incertaines restent bloquées. La reprise ne remplace pas le paiement confirmé par le Cloud avant admission. Aucun compactage ni effacement n’est autorisé par ce protocole.

Les actions de l’organisateur sont liées à leur session : changement de compte ou de session, accès refusé et réponses anciennes effacent le contexte concerné, sans renvoi automatique d’une action après reconnexion. La revue des niveaux et l’import CSV conservent les reçus pour une reprise explicite.

Un bilan facultatif signale les pilotes sans groupe, les capacités et les informations manquantes ou périmées. Les saisies, fichiers et choix sont conservés lors d’un changement de langue ; les droits et le parcours existant restent prioritaires.

Les recherches et réinitialisations d’identité disposent de limites persistées et des mêmes contrôles de portée. Ce lot de développement reste à valider sur son nouvel artefact ; aucun nouveau build 0153 ni résultat de recette n’est publié ici.

Le développement, l’intégration et les validations sont en cours. Cette candidate ne remplace aucune installation et n’est pas qualifiée.

4.6.0-0152 — en développement

La préparation Timing et les aides des champs de configuration disposent de traductions dans dix langues. Le changement de langue conserve les saisies et fichiers sélectionnés ; une confirmation doit être renouvelée dans le nouveau contexte.

Les succès partiels de création d'événement et de synchronisation des modèles restent visibles lorsqu'une relecture échoue. Une restauration ne rejette plus un journal JSON valide à cause de la limite des simples champs texte ; les plafonds et contrôles de conservation restent actifs.

Les autres écrans restent à terminer avant l'activation globale des langues supplémentaires. Cette candidate n'est pas qualifiée.

4.6.0-0151 — en développement

Le manuel comporte 45 chapitres dans dix langues, avec recherche, navigation, légendes et impression. L'activation des langues supplémentaires dans toute l'application attend la traduction et la validation des autres écrans.

La continuation accepte le motif facultatif prévu par le Cloud. Le contrôle de restauration distingue une référence absente d’une référence modifiée et conserve le refus avant toute modification.

La traduction des autres écrans, notamment Timing, Configuration et Administration, reste à terminer. Les nouveaux parcours de reprise interrompue et de réduction des journaux sont encore à l’étude. Cette candidate n’est pas qualifiée.

4.6.0-0150 — en développement

Préparation de la reprise sur une nouvelle base avec conservation de la provenance des périodes, pertes signalées et validation administrative. Les places incertaines restent bloquées et le paiement Cloud reste obligatoire.

Les changements et leurs aides sont en cours de développement. Aucun nouveau parcours n’est encore qualifié.

Les déclarations de copies restent consultables pendant le blocage de synchronisation. Sous Windows, l’inventaire compare correctement les dates des fichiers ; une observation impossible bloque la suppression avant son effet et permet une nouvelle revue explicite.

Les aides pilote, organisateur, synchronisation et confidentialité et le lecteur du manuel proposent dix langues. Les autres chapitres sont identifiés comme français ; la recherche et l’impression respectent la sélection.

Le portail organisateur et la fiche pilote du chronométrage proposent également dix langues. Les saisies et fichiers sont conservés au changement de langue ; les confirmations de suppression doivent être renouvelées.

La reprise sur une nouvelle base présente toutes les pages de pertes avant confirmation. Les routes de continuation et de couverture sont raccordées au connecteur ; une réception Cloud reste distincte du droit de rouler.

Si le compte change pendant une opération de fichiers ou le chargement d’une revue, son résultat est rejeté sans afficher l’ancien diagnostic ni relancer automatiquement l’action. Le paquet vérifie également l’empreinte exacte de sa clé publique de test.

4.6.0-0149 — en développement

Un aperçu permet de préparer une nouvelle période Timing après une modification Cloud de la journée, en conservant les engagements et résultats précédents. Une séance ou un moteur chrono actif bloque cette préparation.

La reprise exige la confirmation Cloud, une nouvelle preuve financière et les contrôles d’admission. Aucun paiement, place ou quota n’est créé par cette opération. Une réponse perdue peut être reprise manuellement avec la même commande.

Les sauvegardes préservent la filiation des périodes et leurs références. La reconstruction sur une nouvelle base lorsqu’il existe déjà ces périodes reste à développer. Les nouveaux parcours et leurs dix langues sont en cours de revue et ne sont pas encore qualifiés.

La clôture d’une journée ayant des périodes conserve ses passages, séances et résultats. Le dialogue annonce la conservation ou la purge selon la réponse du serveur. La fusion des pilotes conservés et le changement de leurs références commerciales restent bloqués tant que leur filiation n’est pas prise en charge.

4.6.0-0148 — en développement

La réception des dossiers Cloud corrige une lecture d’archives incompatible qui pouvait laisser le dossier en attente, même sans ancienne archive. Le traitement conserve sa transaction et peut être repris après une erreur.

Les contrôles reconnaissent les reçus restreints imbriqués dans les anciennes archives. Sous Windows, les demandes concurrentes attendent correctement le verrou de conservation des copies.

Les sauvegardes conservées pour examen sont protégées contre les suppressions ordinaires et la rotation automatique. Les pièces retenues sont également protégées dans le gestionnaire de fichiers, y compris lors du renommage d’un dossier ou de son téléchargement en ZIP. La suppression d’une copie reste soumise à une validation administrative explicite.

La reprise de synchronisation refuse une rotation dont l’archive dépasserait la taille lisible, en conservant l’ancienne identité, ses preuves et ses réservations. Les anciens retours sont lus archive par archive.

Une pièce disparue après approbation reste à examiner : aucune suppression n’est déclarée prouvée sur la seule absence du fichier. Les refus et résultats incertains sont expliqués dans les dix langues.

Le circuit peut partager ses inventaires et ses déclarations de revue avec le Cloud. Les écrans distinguent l’état local d’une copie, la réception de sa déclaration et les copies externes encore inconnues. Une réception Cloud ne vaut pas vérification indépendante d’effacement.

Les preuves conservées hors de la base protègent ce suivi lors des restaurations. La suppression approuvée des anciennes archives Cloud et la revue des couvertures inconnues restent à compléter.

Cette candidate est en développement et n’est pas qualifiée.

4.6.0-0147 — en développement

Les PDF Timing conservent leur interligne de 14 points lors d’un changement de police, notamment entre alphabets latins et japonais.

Les tests de restauration contrôlent correctement les erreurs de contrainte et ferment leurs connexions temporaires sous Windows. Le test de clôture respecte la conservation des engagements et de leur historique prévue par le contrat Trackday.

Le parcours d’identité distingue l’anonymisation au circuit de la demande globale au Cloud. Les anciennes sauvegardes et pièces nominatives restent soumises à une revue et une validation d’administrateur avant suppression.

Un contrôle indépendant protège les identités retirées lors des restaurations et des diffusions en direct. Une réponse préparée avant un retrait est refusée après celui-ci. Les photos conservées pour examen restent protégées, y compris lors d’une suppression différée.

L’écran de confidentialité permet à un administrateur habilité de reprendre un cas après aperçu, confirmation et motif. L’auteur, le plan et les preuves d’origine sont conservés.

La reconstruction et la reprise avec pertes déclarées exigent une validation administrative explicite. Les places incertaines restent bloquées et toute nouvelle admission exige un paiement confirmé par le Cloud.

Cette candidate n’est pas encore qualifiée. Les parcours coordonnés d’identité et de reprise doivent être validés avec Cloud test.42 sur leurs paquets exacts.

4.6.0-0146 — en développement

Les anciens comptes pilote ne sont plus migrés automatiquement au démarrage. Leur migration contrôlée propose un aperçu des conflits et une reprise après interruption. Les anciens accès sont fermés avant activation du compte interne ; les privilèges organisateur ne sont pas transférés.

Les changements d’horaires, de ressources ou d’organisateur d’une journée Cloud nécessitent une revue et une confirmation. Les admissions sont suspendues pendant cette revue ; les passages et groupes des pilotes déjà en piste restent disponibles. Le déplacement d’une journée déjà roulée reste à développer.

Un nouveau pilote peut être préparé sans Internet, sans compte de connexion ni contact vérifié. Le rapprochement Cloud reste explicite et son admission exige un paiement confirmé par le Cloud. Les preuves conservées protègent les pilotes, véhicules et engagements concernés contre une suppression ou une restauration incohérente.

Les nouveaux parcours sont traduits dans dix langues. Un refus de modification d’identité ne provoque plus une fausse indisponibilité de la base pendant dix secondes.

Cette candidate n’est pas encore qualifiée. Les validations des versions précédentes ne valident pas ces changements.

4.6.0-0145 — en développement

L’import CSV propose un aperçu, le choix des colonnes et une décision par ligne. Un reçu permet de vérifier une confirmation incertaine sans créer de doublons. L’import ne crée aucun compte ni engagement et conserve les identités existantes sans les modifier.

Les PDF des résultats, grilles et tours, ainsi que les résultats HTML, reprennent la langue choisie parmi les dix langues disponibles. Les titres et statuts sont traduits ; les temps et identités sont conservés. Le PDF des résultats indique aussi le temps total.

Les évolutions de synchronisation métier et de gestion des identités pilote sont en cours d’intégration. Cette candidate n’est pas encore qualifiée ; les limites et résultats seront consolidés avant sa livraison.

Les journées Cloud vérifient leurs admissions lors des attributions de transpondeur, imports, nouveaux démarrages et verrouillages de grille. L’arrêt d’une session reste possible pendant une réconciliation. Les listes organisateur conservent leur confidentialité même sans pilote admis. Les opérations d’identité en cours restent protégées au redémarrage, et une restauration conserve le repère local indépendant de synchronisation.

La console organisateur permet de fixer des plafonds de groupe et un seuil de confiance. Une validation de niveau conserve son motif, son auteur, sa date et ses révocations. Les anciennes valeurs sont signalées comme historiques. Les reçus et aperçus évitent les doubles confirmations ; la restauration conserve les décisions déjà connues.

La suppression d’un événement lié au Cloud ou à un historique de validation est refusée sans effacer ses engagements. Les dates, le circuit et le propriétaire d’une journée Cloud restent soumis à une revue dédiée.

4.6.0-0144

• Mon espace pilote propose des filtres par circuit, événement, véhicule et dates, une comparaison des meilleurs temps archivés et un export CSV strictement personnel.
• Les comparaisons restent propres à un circuit et un véhicule ; un véhicule inconnu n’est pas inventé et les tours purgés après clôture ne sont pas recréés.
• Un changement de compte ou un accès refusé efface les données privées affichées. Une mutation n’est pas rejouée automatiquement après reconnexion.
• Le portail pilote et le CSV utilisent les dix langues existantes. Changer de langue conserve vos saisies et photos sélectionnées ; les dates affichées correspondent au jour enregistré utilisé par le filtre.
• Les PDF Timing conservent les alphabets accentués, grecs, cyrilliques et japonais avec des polices incorporées. Un caractère non pris en charge est signalé explicitement.
• Les messages et accusés Cloud sont conservés dans DATA avec les sauvegardes. Une restauration bloque les échanges jusqu’à réconciliation ; le raccordement métier complet reste à terminer.

4.6.0-0143

• Le profil TV interne Exploitation / suivi propose Direct, Suivi, Classement et Sessions, avec une carte native pilotable à la télécommande. Le classement utilise uniquement un flux Course autorisé.
• Le suivi TV visible s’actualise toutes les deux secondes après une lecture réussie, contre cinq ailleurs et après erreur, sans requêtes superposées. Les positions GNSS fiables expirent individuellement au même seuil ; aucun mouvement ni cap inconnu n’est inventé. Les profils de diffusion existants restent distincts du suivi interne.
• Dans Direct sur TV 1080p, la prochaine session reste entièrement lisible avec le compteur ; le statut de la piste est nommé explicitement.
• Commissaires Android 0.3.0 propose le déroulé, les feux courants, le signalement d’incidents et ses reçus. Un secteur sans panneau ou un lieu libre suffit, même hors session. Un brouillon ou un envoi incertain ne repart jamais automatiquement.
• La direction traite les signalements depuis Paramètres et les notifications Piste : prise en charge, clôture ou rejet, avec un formulaire compact et le contrôle des droits, du circuit et de la révision. Les alertes de stations et du journal restent visibles ; l’aide contextuelle ouvre le guide Android. Ce traitement ne commande aucun feu.
• Les nouvelles tables et attributions de circuit préservent les anciennes données ; sauvegarde et restauration couvrent les incidents et leur historique. Les événements anciens sans circuit fiable restent conservés hors des nouvelles projections.
• Le contrôle de migration vérifie que les anciennes demandes gardent leur numéro et un circuit non attribué, même après deux passages de migration.
• TV et Commissaires passent à 0.3.0 / code 3, avec les dix langues existantes. Une commande envoyée reste distincte d’une confirmation physique du feu.
• Les reprises TV abandonnent les appels obsolètes, même après changement de serveur. Commissaires arrête les anciennes lectures après déconnexion et protège la connexion suivante contre leurs callbacks.
• La console efface les anciennes données en cas d’accès refusé, même si la réponse est tronquée ; les délais réseau expirés affichent une erreur de connexion lisible.
• La recette Android refuse les interfaces masquées par un dialogue de blocage du système et conserve les preuves avant fermeture. Les contrôles Commissaires attendent une commande visible et active ; les échecs de clic conservent leur diagnostic.

4.6.0-0142

• Le zoom sur un incident garde aussi les libellés des lignes de chronométrage à une taille lisible. Ils ne masquent plus le tracker ni la piste.
• La carte compacte dans Piste, les secteurs automatiques, le bouton jaune et « Vue piste » conservent leur comportement ; les alertes restent limitées à la session en cours.
• La recette navigateur vérifie le vrai rendu des lignes de chronométrage et les styles de RTM. Les contrôles GNSS et la validation des drapeaux restent inchangés.

4.6.0-0141

• La carte d’incident se place en bas à droite de Piste pour laisser les contrôles des calques visibles. Son bouton conserve sa couleur jaune.
• Les libellés de la piste gardent une taille lisible pendant le zoom sur le tracker. Les grandes inscriptions ne masquent plus la portion concernée.
• « Vue piste » conserve la vue générale même lorsqu’une position arrive après le clic. La fermeture de la carte n’acquitte pas l’incident.
• Les secteurs et la position restent automatiques ; la session en cours, la fraîcheur GNSS et la validation distincte du drapeau restent contrôlées.

4.6.0-0140

• La carte compacte d’incident reste dans Piste, avec secteurs et zoom automatiques pendant la session en cours. Le bouton jaune conserve sa couleur dans les thèmes, même désactivé.
• Une position GNSS fiable reste visible si le tracker repart ou si l’épisode de détection a changé. La demande de drapeau reste désactivée jusqu’à revérification de l’incident.
• Une position ancienne, une horloge non fiable ou un profil modifié ne produisent aucun faux cadrage. Les demandes restent soumises à la direction ; sans feu actif dans le secteur, elles restent désactivées.
• Les pannes des stations restent signalées hors session. Les anciens incidents sont conservés pour l’audit et ne bloquent pas les nouvelles sessions.

4.6.0-0139

• Piste affiche une carte compacte d’incident avec bouton jaune, secteurs automatiques et zoom sur le tracker, uniquement pendant la session en cours.
• Une ancienne alerte non acquittée ou relevée hors session ne bloque plus les incidents d’une nouvelle session. Les répétitions du même incident restent regroupées et les anciens événements sont conservés pour l’audit.
• Une position ancienne ou un secteur inconnu désactive la proposition. La direction valide toujours le drapeau ; les pannes des stations restent signalées hors session.

4.6.0-0138

• Dans Piste, une carte compacte remplace le grand formulaire d’incident. Le bouton « Proposer le jaune » est jaune ; la validation par la direction reste distincte.
• Les secteurs sont calculés depuis la dernière position GNSS validée. Une zone inconnue ou une position ancienne ne déclenche aucune proposition sur tout le circuit.
• L’incident zoome sur le tracker, avec ses secteurs surlignés et un retour « Vue piste ». Le repli permet de garder la piste visible sans acquitter l’incident.
• Cartes, liste et marqueurs d’incident apparaissent uniquement pour la session en cours. Les pannes des stations restent signalées hors session et les anciens événements restent conservés.

4.6.0-0137

• Les stations Rock 5 et Rock 3B en service sont surveillées même sans mouvement de tracker ou page Track ouverte.
• Un arrêt, un défaut ou une radio arrêtée déclenche une notification Piste. Une absence d’observation de plus de vingt secondes signale une perte de liaison.
• Une panne conserve une seule identité de notification pendant toute sa durée, y compris après redémarrage de RTM. Le rétablissement est signalé séparément ; une station volontairement désactivée reste exclue.
• Les observations anciennes, dupliquées ou rejouées ne rétablissent pas la disponibilité. Une radio en erreur ou d’état inconnu reste indisponible ; le rétablissement nécessite un état RX ou TX confirmé. Les services permanents et les commandes radio restent gérés sur les passerelles.
• Les jeux de test du statut et des demandes de drapeaux isolent les stations afin de préserver les contrôles indépendants du journal et du chronométrage.
• Les tests des gardes de restauration et des contacts trackers utilisent une horloge contrôlée pour rester indépendants de la charge du banc.

4.6.0-0136

• Les paramètres des trackers 2,4 GHz proposent un seul modèle et un ajout organisé en trois étapes : identifier l’appareil, préparer son accès, puis vérifier la réception. Les transpondeurs se gèrent dans Timing.
• Le numéro du firmware est repris explicitement, sans suggestion susceptible de réutiliser une ancienne identité. Les noms lisibles sont prioritaires ; les diagnostics et opérations sensibles sont regroupés à part.
• Les trackers en réserve restent dans les paramètres avec leur clé et leur historique. Ils sont exclus de Track et de la scène 3D jusqu’à leur remise en service.
• Les passerelles Rock 5 et Rock 3B disposent d’un formulaire d’ajout à la demande et d’un accès RTM dédié. Les fiches désactivées restent consultables, hors du résumé opérationnel.
• Un profil privé peut être téléchargé pendant l’affichage d’une nouvelle clé, pour import protégé dans une passerelle compatible. Il ne reconfigure pas le firmware ou la radio ; la première réception réelle reste vérifiée séparément.

4.6.0-0135

• Les noms et les marques ne font plus supposer le type d’un véhicule T3-S3. Sans type renseigné, la fiche, les icônes et les repères de liste restent neutres, en cohérence avec la 3D.
• La liste affiche T3-S3 / LG290P ou l’affectation saisie, au lieu du type interne rtm_tracker.
• La présentation des passerelles précise qu’un GNSS local est optionnel selon le rôle. Le rôle prévu dans RTM reste distinct de son application matérielle.
• Le suivi 2D charge ses images de fond par une file bornée et reprend au plus deux fois une saturation temporaire. Les demandes périmées sont annulées ; les erreurs d’accès restent explicites.

4.6.0-0134

• Paramètres distingue les passerelles Rock 5 et Rock 3B et leur rôle prévu : référence GNSS ou réception radio. Le résumé de leur état apparaît dans Track.
• Les nouveaux parcours utilisent uniquement le tracker LilyGO T3-S3 SX1280 PA avec GNSS LG290P. Les anciennes déclarations et données restent conservées.
• Track propose 2D, 3D détaillée, 3D technique et maquette, avec les mêmes filtres, sélection et suivi. Le navigateur mémorise le choix du compte ; la première ouverture reste en 2D.
• La scène Mirecourt et la scène générique utilisent les positions reçues. Un type ou un cap inconnu donne un repère neutre. Les points anciens restent signalés ; l’historique est accessible sur demande.
• Les légendes des scènes détaillée et générique restent lisibles à l’échelle du circuit et sont séparées sans déplacer les points. Les actualisations conservent les interactions à la souris et le cadrage.
• La liste affiche la qualité GNSS, l’inclinaison et les accélérations lorsqu’elles sont disponibles et récentes. Les mesures brutes et les secrets ne sont pas exposés.
• Le test de rollback d’un lot contrôle son horloge pour rester déterministe sur un PC chargé. Le budget de traitement réel reste inchangé.
• Le contrat des passerelles ne propose pas de commande distante de session. Le Wi-Fi pour les futures applications et les objets d’exploitation dans la 3D restent à intégrer séparément. Le firmware et la radio conservent leur qualification propre.

4.6.0-0133

• Le manuel compact de maintenance reprend la dernière aide embarquée et son empreinte, avec les explications du journal des observations de base.
• Le client partagé de qualification transmet correctement les paramètres URL. Les requêtes paginées atteignent leur route ; les régressions couvrent aussi l'encodage UTF-8, les chemins bruts, les corps et les en-têtes.
• L'API et les règles du journal0132 sont conservées. Le candidat0132 n'a pas été installé après sa recette en échec ; ce nouvel artefact0133 doit être qualifié complètement par Hermès avant installation.

4.6.0-0132

• Les observations des bases conservées dans DATA deviennent consultables après l’arrêt de la passerelle : chargement manuel par pages de vingt, sur une heure, vingt-quatre heures ou sept jours. Les actualisations de l’état courant conservent les détails ouverts.
• La lecture utilise les droits Track de l’opérateur, sans clé BASE. Les déclarations, réglages et clés restent réservés au droit de configuration. Changer de compte ou de base invalide les réponses tardives.
• Le journal distingue admission au direct et état actuellement retenu. Il vérifie la concordance du contenu avec son empreinte stockée et masque les observations illisibles ou divergentes. Les compteurs absents restent inconnus ; une concordance ne qualifie ni radio ni RTK.
• Les lectures sont bornées par le nombre de lignes et la période, avec pagination figée et index DATA additif. Aucune lecture ne rafraîchit un état ou n’envoie de commande au matériel. Le candidat exact reste à qualifier sur le Pi par Hermès.

4.6.0-0131

• Le panneau des bases sépare les RTCM validés, admissions USB, fragments RF et octets remis à l’UART GNSS. Une étape absente reste « Non observé » ; zéro exige un compteur réellement observé. Les bornes périodiques sont indiquées par « Au moins ».
• Les compteurs sont liés à leur processus ou démarrage, à une période et à un horodatage borné. Ils ne prouvent pas la réussite des étapes suivantes. Les observations LG290P rover peuvent indiquer séparément qualité, satellites, âge différentiel et station de référence sans déduire une consommation GNSS ou une solution RTK.
• L’extension diagnostics est fermée, optionnelle et utilise l’authentification BASE existante. Les anciens messages0130 et leurs empreintes de doublon restent compatibles ; aucune migration DATA ni commande matérielle n’est ajoutée.
• Le reporting de passerelle est préparé dans une copie distincte ; il lit les compteurs LG et USB réels et laisse inconnues les mesures non exposées par le firmware036. Cette édition ne modifie pas le Wi-Fi ou le mesh. Recette du candidat exact sur le Pi principal par Hermès avant toute promotion.

4.6.0-0130

• Le panneau Bases Radxa et passerelles remplace les commandes USB. Il déclare les bases et affiche les observations fraîches de la passerelle, de la source de corrections et du GNSS de référence, avec un motif explicite en cas d'indisponibilité.
• Chaque base possède sa propre clé API, distincte des clés trackers. Elle est révélée une seule fois puis stockée sous forme d'empreinte, avec copie, masquage, renouvellement et révocation. L'affichage est lié au compte et à la visibilité de la fiche ; les lectures périodiques conservent les contrôles de saisie.
• Les observations de base ont un schéma fermé et sont acquittées après commit DATA. Doublons et reprises ne rafraîchissent pas l'état ; la fraîcheur d'affichage vient de la réception serveur. RTM n'envoie aucun ordre radio, USB ou de provisionnement.
• Le parcours T3-S3 propose une identité stable disponible et un nom lisible à vérifier sur le matériel. Le nom RTM, le nom OLED et l'identité restent distincts ; changer un nom ne change pas les clés.
• La couverture utilise les vraies captures HTTP fraîches et durables du tracker choisi, avec son identité boot/séquence. Aucun uptime, RSSI, base_id de livraison ou point GNSS manquant n'est inventé. Le RSSI reste indisponible pour les nouveaux essais ; les anciens historiques restent lisibles.
• Les anciens drivers, routes, commandes, widget et passerelle USB/IP sub-GHz sont retirés. Les déclarations anciennes identifiées sont désactivées et signalées comme retirées, sans effacer identités, mesures, archives privées ou empreintes de clés. Leur remplacement demande un profil pris en charge explicite.
• Le registre des bases et ses reçus sont ajoutés aux sauvegardes DATA. La mise à jour préserve la configuration GNSS privée existante. Le paquet0130 exact doit être qualifié sur PC et sur le Pi principal par Hermès ; aucune promotion à Mirecourt n'est incluse.
• Les sauvegardes0129 complètes restent reconnues et ne suppriment pas les bases déjà présentes ; une paire de tables de base incomplète est refusée. Un renommage conserve une désactivation concurrente. Le retrait des anciennes déclarations précède le démarrage des consommateurs et conserve leurs reçus en historique.
• Les tests de qualification ont été alignés sur les métadonnées de transport et les captures T3-S3. Leurs contrôles de persistance et de collision sont conservés ; ces corrections de recette ne changent pas le comportement fonctionnel de cette édition.
• Un fix ou un flux de corrections de la base ne prouve aucun fix rover, correction utile, portée ou EIRP. Sans GNSS rover connecté, aucune position réelle n'est attendue.

4.6.0-0129

• Configuration des périphériques : un bouton permet de déclarer un tracker T3-S3 / SX1280 utilisant la passerelle HTTP externe. Sa fiche explique l'association de l'identifiant firmware à l'identifiant RTM, l'URL serveur et la clé API privée propre à chaque tracker.
• La clé API peut être générée, copiée, masquée, renouvelée ou révoquée sans QR ni instructions Android. Elle reste affichée une seule fois pour le compte autorisé. Son renouvellement invalide l'ancienne clé et exige sa mise à jour dans la passerelle.
• Le profil de connexion choisi est conservé séparément du transport observé dans les captures traitées. Les trackers T3-S3 ne sont plus dirigés vers les réglages HaLow ; le matériel non identifié conserve une fiche générique. Une différence entre profil et transport observé est signalée sans changer la configuration.
• Modifier le nom, le véhicule ou la catégorie GNSS/transpondeur conserve le type physique du périphérique. Les colonnes de connexion sont ajoutées sans remplacer les données existantes ; le parcours Android et le menu USB / HaLow restent disponibles.
• La configuration des périphériques attend les activations réelles du serveur avant ses lectures. Avec Track actif et Timing désactivé, l'entrée directe dans la page permet de configurer les trackers sans requête Timing fondée sur les valeurs initiales du navigateur.
• L'identifiant technique du tracker accepte jusqu'à 64 caractères, comme la base DATA. La saisie et les validations serveur refusent proprement une valeur plus longue avant son écriture.
• Ces changements ne pilotent pas le provisionnement radio, le port USB ou NTRIP de la passerelle et ne prouvent pas une liaison physique ou un fix RTK. Le candidat doit être qualifié sur PC puis sur le Pi principal par Hermès ; aucune promotion à Mirecourt n'est effectuée.

4.6.0-0128

• BUG-000033 et BUG-000034 : les commandes « Tout le circuit » et par secteur conservent leurs boutons pendant les mises à jour live. Un clic reste utilisable lorsque les trackers émettent, sans perte du survol ou du focus au rythme des données reçues.
• La palette garde ses boutons et le grand aperçu du drapeau dans la barre inférieure reste en place pendant les actualisations. La sélection du drapeau et de son texte est conservée ; les changements de secteurs, d'état des panneaux, de langue, d'activation du module et d'autorisation restent pris en compte.
• Les commandes conservent leurs routes et contrôles de droits. Le simple appui de la souris et le survol ne provoquent aucun envoi supplémentaire ; les animations prévues des drapeaux clignotants restent disponibles.
• Le nouvel artefact doit être qualifié sur PC puis sur le Pi par Hermès. La release et la sauvegarde précédentes sont conservées pour le retour arrière, sans écraser les écritures ultérieures. Aucune migration de données ni intervention à Mirecourt n'accompagne cette correction.

4.6.0-0127

• Le rapport PDF du journal Piste conserve le titre complet de la session. Les noms longs passent à la ligne ; un titre exceptionnellement long dispose de pages d'identification au début du rapport. Seule sa partie dans le nom du fichier est limitée, avec l'identifiant de session conservé ; les noms de fichiers usuels ne changent pas.
• Les messages de session, dont la validation manuelle, apparaissent intégralement dans la colonne Message au lieu d'être raccourcis sous Signal. Les messages enregistrés des autres événements restent également complets.
• Les cellules et annotations passent à la ligne. Un même événement peut continuer sur plusieurs pages, avec une indication de suite, sans perdre ni répéter son texte et sans toucher le pied de page. Le nombre de lignes reste celui des événements enregistrés.
• Le titre et le journal utilisent la police fournie avec RTM pour conserver les accents, ligatures et ponctuations françaises. Les caractères absents de cette police affichent leur code ; le texte original reste disponible aux lecteurs PDF compatibles pour l'extraction. La copie et la recherche dépendent du lecteur ; tous les alphabets et compositions typographiques ne sont pas garantis.
• Les rapports déjà générés sont conservés. La correction ne modifie ni les journaux enregistrés, ni les droits, ni la validation des sessions ; les exports PDF Timing gardent leur générateur et leurs limites propres.
• Ce nouveau paquet doit être qualifié sur PC et sur le Pi principal, avec contrôle visuel des PDF. Le retour arrière conserve les rapports et les écritures postérieures à la sauvegarde ; RTM Cloud garde sa livraison indépendante.

4.6.0-0126

• La correction d'heure applique exactement la valeur confirmée, avec ses secondes et millisecondes. La confirmation distingue heure locale et UTC et indique « transpondeur inconnu » lorsque son identifiant est absent ; les identifiants présents restent affichés tels quels.
• La publication vérifie les prérequis avant de modifier les résultats. Une publication refusée ne laisse pas de classement final partiel ; les pénalités ne sont comptées qu'une fois après publication et relecture.
• Timing rend le roulage ciblé, ses états, ses prérequis et ses résultats plus visibles. Les commandes répétées sont regroupées ; les noms des pilotes et sessions remplacent les identifiants dans les résultats combinés.
• Les imports Timing disposent d'un aperçu et d'un bilan. Les formats inconnus et erreurs de feuilles ou colonnes sont expliqués avant l'application ; le serveur conserve ses contrôles de droits et de références.
• Les huit exemples du modèle Timing restent ignorés sans créer de données. Le bilan effectif présente les paramètres appliqués une seule fois ; les causes d'erreur répétées sont dédupliquées sans perdre leurs emplacements ni les autres erreurs.
• Les imports du simulateur conservent les identifiants alphanumériques des transpondeurs. Leurs annexes de simulation sont vérifiées puis ignorées et signalées, sans créer de passages réels.
• Une reprise de publication vérifie l'intégrité du classement enregistré. Les CSV ambigus sont refusés ; le bilan compte chaque ligne ignorée une seule fois et les historiques importés conservent leurs références aux groupes.
• Les vues publiques, formulaires et dialogues améliorent contraste, libellés et navigation au clavier. Le véhicule engagé affiche son verrouillage ; les pages refusées permettent de revenir à l'espace autorisé.
• Les alertes de chronométrage Speaker gardent un texte sombre lisible sur leur fond clair, avec les thèmes clairs comme sombres.
• Tab et Maj+Tab restent dans les dialogues de confirmation, saisie et information. Les contrôles masqués ou désactivés sont exclus ; Échap annule et la fermeture rend le focus au déclencheur.
• Les états publics usuels sont traduits. Les Meilleurs tours précisent que leurs temps ne comprennent pas les pénalités du classement. Les liens Public et Speaker expliquent un contexte Organisateur Piste incompatible sans le changer automatiquement.
• Les PDF Timing corrigent les accents et les caractères Windows ANSI usuels, répartissent les classements sur plusieurs pages A4 et passent les noms longs à la ligne sans troncature. Les caractères hors Windows ANSI restent une limite du générateur.
• Les exports de configuration et les étapes de restauration sont explicités. Un outil prépare une démo locale cohérente, sans panneau ni service Internet, dans un dossier neuf.
• Le choix Piste affiche le nom et la durée retenus et précise son application immédiate. Le bouton Fermer conserve cette sélection sans démarrer la session.
• Les retours Organisateur restent attachés à leur compte, événement et onglet, sans masquer les alertes de sécurité ou de reprise. Les passages publics remplacent les codes techniques connus par leurs libellés métier, avec le code disponible en détail.
• Sur petit écran, les cartes, champs et commandes Timing restent dans la largeur de la page. Le tableau conserve un défilement interne ; le profil passe sous le titre et le sélecteur lorsque la place manque.
• Une correction d'heure ou une publication confirmée reste annoncée comme appliquée si la relecture échoue. Actualiser les données relit sans renvoyer l'action ; les refus et réponses ambiguës restent non confirmés. Les retours tardifs d'un autre compte ou contexte sont écartés.
• Une mise à jour de dernière activité bloquée par une contention SQLite ne fait plus échouer une session déjà vérifiée. L'expiration, la révocation, l'état actif et les droits restent contrôlés ; les autres erreurs de stockage restent visibles.
• Une sauvegarde des données et de la configuration accompagne le retour arrière. Les preuves de qualification restent liées au paquet exact ; RTM Cloud conserve sa livraison indépendante.

4.6.0-0125

• Interfaces et projection opérationnelle : le circuit enregistre les dossiers projetés par le Cloud dans une table locale consultable (identité, véhicule, offre, statut, documents), par mise à jour idempotente.
• Les suppressions sont appliquées via des pierres tombales : la copie locale est retirée sans jamais toucher aux données de chronométrage ni à l'historique des pilotes.

4.6.0-0124

• Synchronisation métier Cloud↔circuit (côté RTM) : le circuit reçoit la projection limitée du Cloud (journées autorisées, dossiers), l'applique sans jamais rejouer une opération déjà reçue, et publie ses retours (présence, résultats) à travers une file locale durable.
• Le connecteur central n'autorise que les trois routes de synchronisation, avec le même jeton privé et le même transport borné que les autres services. Un type ou une version de schéma inconnu reste en attente, jamais appliqué à moitié.

4.6.0-0123

• Confidentialité : un compte organisateur ne lit plus, dans l'historique d'un pilote, les tours des événements qui ne sont pas attachés à son organisation. La requête de l'historique est désormais bornée à ses propres événements.
• La direction du circuit conserve l'historique complet de sa base locale ; le pilote conserve son historique personnel complet et ne peut pas lire celui d'un tiers.
• Les autres lectures de temps (tours, classements, exports, passages, flux et audits) étaient déjà limitées à leur périmètre et restent inchangées.

4.6.0-0122

• Le serveur RTM Cloud dispose de son propre projet de développement, avec ses consignes et sa documentation. Les services Cloud restent accessibles depuis RTM avec leurs droits et contrats existants.
• Les sources et vérifications RTM sont autonomes. La vue Piste, les profils, les API et les fonctions d'exploitation sont conservés.
• Les anciennes recettes qui démarraient un serveur Cloud sont conservées dans les archives du projet Cloud et retirées du paquet RTM.
• Cette organisation des sources ne modifie aucune installation en service ; la qualification reste liée à chaque paquet exact.

4.6.0-0121

• Après un enregistrement réussi dans Général, le test d'email de récupération redevient disponible lorsque la configuration et les droits permettent l'envoi. Un échec d'enregistrement ou une perte de droits maintient les protections nécessaires.
• Cette version conserve les améliorations des menus, des miniatures, des fichiers, de la connexion et de la maintenance de 0120. Piste garde sa présentation et son fonctionnement.
• Le résultat du test confirme l'acceptation par le serveur de messagerie ; vérifiez la réception dans la boîte du destinataire.

4.6.0-0120

• Général réunit l'identité du circuit, les documents, l'email de récupération et Cloud et licence. Les formulaires sont regroupés, les menus placés à gauche des titres et la recherche mène aux sous-rubriques. Les modifications en attente sont signalées.
• Créez une miniature depuis le profil de circuit, choisissez son fond et son format, puis utilisez-la dans Timing ou téléchargez-la en PNG. L'aperçu automatique suit le profil actif. Logos et images disposent de fonds adaptés à leur lisibilité.
• La page intermédiaire Occupation de piste disparaît ; le comptage, les limites et les alertes restent disponibles. Les portails s'ouvrent directement depuis les Paramètres.
• La connexion présente clairement le circuit et ses accès locaux. Le mot de passe peut être affiché, la récupération utilise un identifiant ou un email et le lien reçu ouvre directement le choix du nouveau mot de passe.
• Maintenance et assistance rassemble l'état RTM, les diagnostics et les outils serveur configurés. Cockpit garde sa connexion système distincte. La santé DATA tient compte de la base réellement configurée ; un service réseau non utilisé n'est plus assimilé à une panne. Un accès impossible aux fichiers Kea est signalé sans interrompre la page.
• Les dialogues et textes des parcours concernés sont harmonisés. Piste conserve sa présentation et son fonctionnement. Le test d'email confirme l'acceptation par le serveur de messagerie ; vérifiez sa réception dans la boîte du destinataire.

4.6.0-0119

• Les paramètres se chargent sans erreur lorsque la connexion est confirmée avant le premier statut RTM. Le panneau Modules attend les données disponibles ; les brouillons restent protégés lors d'une actualisation du même compte et sont effacés lors d'un changement de compte ou de droits.
• Cette correction conserve les menus d'exploitation, le gestionnaire de fichiers, les thèmes et le test d'email de 0118. La vue Piste conserve sa présentation et son fonctionnement.

4.6.0-0118

• Les paramètres sont organisés par installation, exploitation, équipements, interfaces et maintenance. Général distingue l'identité, les documents et la messagerie. Les modules disposent de leur propre page et de leur propre enregistrement ; la rubrique « à coder » disparaît de l'interface d'exploitation.
• Le test d'email utilise la configuration SMTP enregistrée et un destinataire explicite. Le résultat est daté et distingue l'acceptation par le serveur de la réception en boîte. Les modifications non enregistrées bloquent le test ; les droits et une limite de fréquence encadrent l'envoi.
• Le gestionnaire de fichiers et les sélecteurs proposent un fil d'Ariane, une recherche dans le dossier courant, un tri et des métadonnées. Les actions conservent leurs droits et les formats attendus. La suppression reste définitive avec confirmation.
• Les fenêtres, panneaux et champs suivent les palettes choisies. Les thèmes principaux sont mis en avant ; les autres thèmes et la personnalisation restent disponibles. Un contrôle du contraste des textes précède l'enregistrement d'un thème personnalisé.
• Les autres menus et les aides utilisent des formulations orientées exploitation et maintenance. La vue Piste conserve sa présentation et son fonctionnement. Les cartes, profils, données métier et restrictions d'accès sont préservés.

4.6.0-0116

• Une mise à jour live pouvait remplacer un contrôle Track pendant l'appui et perdre le clic sur une case, un nom, Fiche ou une pastille. Le candidat 0115 est rejeté pour cette régression ; 0116 conserve les contrôles pendant leur interaction native au pointeur, au clavier, dans un sélecteur ou pendant une composition de texte.
• Les données continuent d'être fusionnées pendant l'interaction. Le rendu reprend après activation ou fin de l'interaction, sans clic artificiel. Changement de compte, retrait de droits et désactivation du module restent prioritaires. Les gestes caméra, le focus et les choix d'affichage conservent leur comportement.
• La consultation héritée conserve liste cochable, carte centrale et fiche repliable, affichage indépendant de la consultation, groupes Timing par identifiants via la vraie API autorisée, fraîcheur GNSS UI de cinq secondes, caméra et suivi explicite. Groupes sélectionnés et contexte indisponible donnent zéro résultat avec choix conservés ; seul un nouvel événement disponible les réinitialise. Les fonds et leurs droits, l'historique à la demande et la configuration autorisée sont conservés.
• Le rapport associé à l'artefact exact porte la qualification ; ces notes ne sont pas un rapport de recette et les résultats de 0115 ne qualifient pas 0116. Aucun débit de 800 captures/s, délai inférieur à deux secondes ou stockage trois jours n'est qualifié par ce correctif. Python reste en 3.12 et Tracker Android en 0.5.0 ; aucune commande matérielle automatique ni nouveau firmware radio.

4.6.0-0115

• Track propose une liste cochable, une carte centrale et une fiche compacte repliable. Afficher un tracker et consulter sa fiche sont deux choix indépendants ; une recherche sans résultat ne ramène plus toute la liste. Les filtres Auto/Moto répétés sont remplacés par groupes Timing, GPS, mouvement et recherche.
• Les groupes proviennent uniquement de la session Timing liée à la session Track active, sous les droits Track et Timing. Les identifiants tracker/groupe font foi, sans rapprochement par nom. Sans groupe reste distinct d'un contexte indisponible : les groupes sélectionnés et leurs pastilles restent conservés, avec zéro résultat explicite jusqu'au retour d'un contexte valide. Aucun élargissement silencieux ; seul un nouvel événement disponible réinitialise ces choix.
• La lecture INTERNAL de session encadre un snapshot DATA unique pour contexte, groupes et affectations. Un changement visible refuse le contexte ; ce contrôle ne constitue pas une transaction distribuée entre les deux bases.
• La fiche expose vitesse, cap, précision, batterie et âge GNSS ; les valeurs anciennes ne sont pas présentées comme une vitesse actuelle. La règle d'affichage récent est de cinq secondes. En mouvement exige un tracker en ligne, une position récente et une vitesse supérieure à 1 km/h, sans changement du délai de contact serveur ou des critères d'incident.
• Zoom, déplacement, cadrage et suivi explicite conservent les fonds existants et leurs droits. Le suivi se met en pause après un geste manuel et signale l'attente d'un point frais ; les marqueurs proches restent consultables. Focus, saisie et choix d'affichage survivent aux mises à jour. Historique et configuration autorisée restent dans les détails secondaires.
• La qualification est portée par le rapport associé à l'artefact exact ; ces notes ne constituent pas un rapport de recette. Aucun résultat d'une version antérieure ne qualifie ce build. Aucun débit de 800 captures/s, délai inférieur à deux secondes ou stockage trois jours n'est qualifié par cette évolution d'interface. Python reste en 3.12 et Tracker Android en 0.5.0 ; aucune commande matérielle automatique ni nouveau firmware radio.

4.6.0-0114

• Piste charge et dessine les objets du profil actif associé à son fond géographique : surface de piste, stands, paddock, limites, accès, secteurs et lignes de chronométrage. Le chargement ne dépend plus des contrôles de l'atelier.
• Track affiche également les surfaces, contours et accès auparavant exclus de son rendu, y compris les repères Point. Les trous restent transparents et les trois zones gardent leurs couleurs fixes.
• OpenStreetMap et Plan RTM utilisent les mêmes coordonnées opérationnelles. Les objets restent superposés au fond après zoom et déplacement ; l'absence de lien secteur/feu ne masque pas le circuit.
• La consultation conserve les géométries, identités et l'état actif. La vue GPS indépendante de Track ne reçoit pas les objets du circuit. Aucune modification ou commande de récepteur GNSS, tracker, base radio ou feu.
• Les vérifications ciblées et navigateur utilisent des réponses isolées. La recette visuelle du profil réel sur le Pi doit identifier ce nouvel artefact ; une simulation ne qualifie ni l'implantation réelle ni les performances du flux trackers.

4.6.0-0113

• Les ouvertures de la base interne évitent la création répétée des répertoires usuels. Configuration et chemin restent lus à chaque ouverture ; un nouveau parent est préparé avant connexion et les erreurs d'accès restent visibles.
• Le préchargement PostgreSQL natif réunit les préfixes directs et historiques en une commande paramétrée. Capacités, ordre capture puis identifiant, référence UTC et identifiants BIGINT restent conservés ; les autres connexions gardent leur voie compatible sans replay après erreur SQL.
• Quantum de seize candidats, budget souple de cent millisecondes, quotas, fraîcheur, critères d'incident, accusés après commit et archivage restent conservés. Les alertes proposent un drapeau à demander puis confirmer.
• Les contrôles PC ciblés préparatoires de 0113 ont réussi : 15 tests des chemins internes, 107 tests d'analyse dont 10 nouveaux contrôles des préfixes, et 9 contrôles de l'outil de qualification. Sources inchangées pendant chaque suite et gardes à zéro ; l'adaptateur SQLite des préfixes ne constitue pas une preuve PostgreSQL native. L'outil de recette exige le build 0113 et son manifeste vérifié.
• Les suites complètes PC et Pi de 0112 ont réussi avec 1 743 tests chacune. Sa charge conserve les 48 000 captures uniques mais échoue, avec 9/40 incidents cibles et un retard d'analyse important. Ces résultats ne qualifient pas le nouveau paquet 0113, qui exige ses propres contrôles et mesures.
• La conservation de trois jours garde les traitements et incidents ouverts. Python reste en 3.12, Tracker Android en 0.5.0 et le firmware radio 2,4 GHz reste à développer. Le débit de 800 captures/s, la détection en moins de deux secondes et la capacité réelle de trois jours restent à démontrer.

4.6.0-0112

• La vérification réussie d'une clé tracker inchangée est mémorisée sans expiration, avec 1 024 succès au plus et 64 verrous fixes. Seules deux empreintes sont retenues ; Track, la ligne DATA, le statut, le hash et la révocation restent vérifiés à chaque requête, puis la preuve au commit. Aucun droit ou secret n'est mis en cache.
• La recherche des reçus existants et l'insertion PostgreSQL utilisent deux puis onze tableaux paramétrés avec psycopg. L'ordre des premières admissions est explicite, les IDs des captures égales restent cohérents et les doublons gardent le même reçu et le premier brut.
• Le lookup d'ACK ne recharge plus les grands résultats dérivés inutiles. L'analyse, l'archive et l'audit gardent leurs lectures ; anciens ACK, réponses compactes, session, contexte et commit restent conservés.
• Les tableaux builtin adaptés utilisent le codec binaire psycopg. Paramètres scalaires, valeurs personnalisées et autres connexions gardent leur voie compatible choisie avant SQL. Une erreur du pilote annule la transaction sans seconde exécution ; les identifiants BIGINT restent exacts.
• Le comptage des effets évite le parcours d'une fenêtre GPS connue uniquement lorsqu'une majoration prouve le même maximum. Capacité réelle, aliases, formes legacy, cycles et fallback complet sont conservés ; la borne de 16 Mio, les checkpoints, GPS/ACC et rollback ne changent pas.
• Les 71 tests PC ciblés préparatoires ont réussi avec source inchangée et gardes à zéro. Six petites fixtures TEMP PostgreSQL ont aussi réussi avec fermeture réelle et données permanentes inchangées ; elles combinent fonctions SOURCE17 et propriétaire Frozen16, sans qualifier un paquet complet ni une charge.
• La charge SOURCE16 a échoué avec 0/40 couples tracker/incident attendus, capture→ACK P50 de 67,975 s et P99 de 119,614 s. FULLPC et charge 0112 demandent leurs rapports du nouveau gel. Le Pi est inaccessible ; un ZIP PC préparatoire ne vaut ni qualification de production ni promotion. Aucun débit de 800/s, délai inférieur à deux secondes ou stockage trois jours n'est acquis.
• Quotas et seuils, rétention avec holds et demande puis approbation humaines des propositions restent conservés. Aucune nouvelle migration ou commande matérielle automatique. Python reste en 3.12, Tracker Android en 0.5.0 et le firmware radio 2,4 GHz reste à développer.

4.6.0-0111

• Les identifiants et références durables Track/GNSS utilisent BIGINT sur PostgreSQL. La conservation de trois jours ne remet pas les séquences à zéro ; la limite des anciens entiers 32 bits pouvait être atteinte en environ 31 jours à 800 captures/s.
• Les séquences existantes sont élargies sans redémarrage ni changement de position, propriétaire, incrément, cache, cycle ou bornes personnalisées. Les contraintes et anciennes références NOT VALID restent conservées ; les autres colonnes entières ne sont pas élargies.
• Initialisation, schéma du flux, copie autorisée et restaurations DATA/GNSS appliquent le même contrat. Une cible de copie déjà remplie sans remplacement est refusée avant ce nouvel élargissement. SQLite conserve INTEGER PRIMARY KEY et l'autoincrément.
• La migration conserve la transaction propriétaire et les limites plus strictes ; son helper borne locks à une seconde et statements à 60 secondes. Une grande table peut être réécrite ou provoquer un timeout : sauvegarde, arrêt coordonné et recette restent nécessaires, sans promesse de démarrage instantané.
• Le watchdog ne transfère plus un état inutilisé et évite la lecture du contexte avant une demi-seconde d'absence. À cette frontière, le seuil courant et les preuves de silence restent contrôlés.
• Les notifications réussies sont marquées ensemble avec psycopg, par tableaux d'identifiants exacts et d'heures UTC individuelles. Les refus gardent leurs retries, les erreurs SQL annulent le lot et les autres connexions gardent leur voie compatible. Livraison au moins une fois, identifiants stables et borne de 512 restent conservés.
• Les 19 tests PC ciblés et huit petites fixtures natives BigInt ont réussi. Ils ne remplacent pas FULLPC, FULLPi ni la charge SOURCE16, encore non exécutées. Les charges V6 de 0110 ont échoué avec 10/40 puis 14/40 incidents attendus dans l'essai profilé, malgré les 48 001 bruts intacts et la bijection entre archives retenues et positions GNSS. Aucun débit 800/s ou délai inférieur à deux secondes n'est qualifié.
• La conservation de trois jours garde ses holds pour travaux et incidents ouverts. Les propositions jaunes exigent demande puis approbation explicites, sans commande matérielle automatique. Python reste en 3.12, Tracker Android en 0.5.0 et le firmware radio 2,4 GHz reste à développer.

4.6.0-0110

• La file PostgreSQL accepte jusqu'à 4 096 admissions en attente ou actives, sous un budget comptabilisé de 64 Mio. Cela limite les refus lors de rafales simultanées ; le budget ne représente pas toute la mémoire du processus et ne prouve pas un débit soutenu.
• Les lots restent bornés et chaque accusé individuel attend son commit. Les captures, leurs identités, sessions et contextes sont conservés ; une file pleine renvoie un refus sans effacer les mesures de l'émetteur.
• Après 128 notifications diffusées avec succès, le relais rend la main sans ajouter sa pause de 100 ms. Chaque lot reprend le contrôle de maintenance ; les lots partiels et erreurs conservent leur attente.
• Une annulation attend la fin réelle du thread déjà lancé avant de libérer la garde de restauration, même si l'annulation se répète. Elle ne relance pas l'opération et ne rend pas remplaçables des ressources encore utilisées.
• Les quatre incidents et leurs confirmations restent conservés. La conservation de trois jours garde ses exceptions ; une proposition de drapeau exige toujours une demande et une approbation autorisées, sans commande matérielle automatique.
• Python reste en 3.12 et Tracker Android en 0.5.0. Le firmware radio 2,4 GHz reste à développer.
• Les 1 677 tests PC complets réussis appartiennent à 0109, dont la charge PC V5 a échoué avec 15 couples tracker/incident attendus sur 40 et dont la suite Pi n'a pas été exécutée après une erreur de préparation. Les 53 tests PC ciblés de ce lot ne qualifient pas le nouveau paquet 0110 : débit de 800 captures/s, délais inférieurs à deux secondes et capacité sur trois jours restent à mesurer.

4.6.0-0109

• Le comptage de la mémoire des contextes et des effets d'analyse parcourt les objets de façon itérative. Il conserve le même calcul des octets retenus et compte une seule fois les objets partagés.
• L'analyse copie directement les formes d'état qu'elle connaît, avec leurs fenêtres GPS et leurs preuves d'incident. Une forme inhabituelle ou des objets mutables partagés déclenchent une copie générale de l'état entier pour préserver leurs liens et les preuves.
• Les cinq écritures groupées de l'analyse PostgreSQL transmettent un tableau par colonne au pilote psycopg. Les valeurs nulles restent prises en charge, les colonnes de mesure normalisent les entiers en nombres à virgule et les identifiants BIGINT restent exacts. Les autres connexions et valeurs inhabituelles conservent le chemin compatible.
• Ces changements conservent les captures brutes, les accusés après commit, l'ordre des traitements, les états direct et historique, les confirmations d'incident et la diffusion après commit. La conservation de trois jours garde ses exceptions pour les traitements et incidents ouverts ; un drapeau proposé exige toujours la confirmation de l'opérateur.
• Aucune nouvelle migration ni dépendance n'est ajoutée. Python reste en 3.12 et Tracker Android en 0.5.0.
• Les suites de 0108 ont réussi sur PC et Pi, mais sa charge PC de quarante trackers à vingt captures par seconde a échoué. Les essais SQL isolés préparatoires ne prouvent pas le débit du flux. Le nouvel artefact 0109 exige sa propre qualification ; le délai inférieur à deux secondes et la capacité de stockage sur trois jours restent à mesurer.

4.6.0-0108

• La sélection d'un petit lot historique pouvait parcourir et trier tout le journal en attente. Un index partiel ordonné par capture et identifiant couvre les champs nécessaires et conserve les données existantes.
• L'analyse PostgreSQL borne désormais sa sélection à seize candidats avant les requêtes. Les autres captures restent durables, avec le même partage direct/historique, les mêmes retries, la même fraîcheur et les mêmes commits.
• SQLite conserve la taille de lot demandée et reçoit un index couvrant équivalent. Les contrôles vérifient les voies déséquilibrées, l'ordre des effets, les prédécesseurs en retry et les initialisations répétées.
• La création de l'index intervient lors de l'initialisation du schéma et peut allonger la mise à jour d'un journal volumineux. Sauvegarde et arrêt coordonné restent nécessaires.
• Les gains d'une requête ne qualifient pas le débit global. Ce paquet exige sa propre recette PC et Pi, des mesures pour quarante trackers à vingt captures par seconde et des délais d'incident inférieurs à deux secondes. Python reste en 3.12 et le firmware radio 2,4 GHz reste à développer.

4.6.0-0107

• La refonte trackers conserve son journal durable commun USB/Android, ses deux processus Python 3.12, ses quatre incidents prioritaires, ses propositions de drapeau à confirmer et sa conservation serveur de trois jours. Tracker Android reste en version 0.5.0.
• Le catalogue complet des drapeaux pouvait dépasser la taille acceptée du statut initial et fermer la connexion de supervision. Le direct utilise une projection bornée ; le catalogue complet se charge séparément en arrière-plan, sans retarder les alertes.
• L'édition conserve toutes les définitions, y compris les drapeaux masqués et personnalisés. Le catalogue se renouvelle après une modification, un import ou une restauration. Les transferts inchangés utilisent un ETag.
• Le cache du navigateur appartient au compte courant et à la révision reçue. Déconnexion et perte du droit de lecture retirent le catalogue ; une réponse tardive d'un autre compte ou d'une ancienne révision est écartée. Une erreur de chargement reste visible.
• Le statut reste borné lorsque de nombreux drapeaux sont visibles ou qu'une image personnalisée est volumineuse. Les commandes de panneau et les programmes VSN conservent leur fonctionnement.
• La vue Tracker ne réaffiche plus une ancienne précision GPS lorsqu'une capture plus récente la déclare absente dans l'ancien format de statut. Le format courant conserve la précision du fix analysé ; une mesure d'accéléromètre ne la remplace pas. Les contrôles d'interface vérifient les valeurs absentes, les zéros et les palettes avec les helpers et identités de capture courants.
• Ce nouvel artefact exige sa propre recette PC et Pi. Le délai de deux secondes pour 40 trackers à 20 Hz, le stockage sur trois jours et les transmissions matérielles restent soumis à mesure. Le firmware radio 2,4 GHz n'est pas livré.

4.6.0-0106

• Conservation commune de trois jours pour le brut, les positions et les incidents clôturés. La maintenance conserve les traitements inachevés, incidents ouverts et demandes de drapeau en attente ; les quotas ne raccourcissent plus les preuves.
• L'état du flux présente la politique actuelle et le dernier bilan de conservation. Une erreur conserve les suppressions confirmées et signale les compteurs incomplets. Les sauvegardes qui référencent un contexte absent sont refusées avant restauration.
• Les quatre incidents prioritaires proposent un drapeau jaune à examiner, puis à demander et approuver. Ces actions vérifient que le même épisode GNSS est encore actuel. La détection ne commande aucun panneau.
• Les copies d'un broadcast reçues par plusieurs bases retrouvent le même reçu. Une identité réutilisée avec un contenu de capture différent est refusée avec 409 et préserve le premier brut.
• Le firmware radio 2,4 GHz est à développer. Le parcours attendu distingue capture et réception, avec identité de démarrage, séquence, heure du fix et précision. Le format radio, son adaptateur et la transmission réelle restent à qualifier ensemble.
• Le journal dérivé référence les réglages partagés ; les alarmes conservent leurs preuves complètes. L'analyse préverrouille au plus seize candidats, et l'entrée utilise aussi les paramètres natifs psycopg. Les gains de débit doivent être mesurés sur ce paquet.
• Le traitement réduit les décodages et copies temporaires répétés des points. La vérification du module demandé évite de reconstruire tous les modules à chaque réception, avec les mêmes contrôles de licence à chaque appel.
• USB et Android enregistrent leurs points dans un journal durable commun avant accusé de réception. Deux processus Python 3.12 distincts analysent et archivent, avec reprise après arrêt et identifiants stables.
• PostgreSQL regroupe les réceptions dans un writer borné ; chaque accusé attend son commit, avec session et contexte capturés avant l'attente. Le drain USB règle chaque reçu séparément et conserve les enveloppes non confirmées, sans acquittement par son cache mémoire.
• Les traitements utilisent le même ordre de verrous et réévaluent désactivations, révocations et rotations de clés avant leurs effets. Une restauration est refusée tant que le writer ou le drain USB reste actif. Le provider DATA est conservé pendant chaque transaction.
• L'analyse PostgreSQL groupe les échanges SQL en conservant l'état de chaque point pour le suivant et les preuves de dépassement des autres trackers. Les historiques dépassant le préchargement borné gardent leur contrôle SQL. Le watchdog groupe ses lectures sans modifier la preuve du silence.
• L'archive PostGIS valide ses points par lot, avec un réglage commun visible jusqu'au lot suivant et reconnaissance des doublons avant les filtres. Un point défectueux ne fait pas acquitter les insertions annulées ; les décisions terminées restent conservées après une confirmation de commit perdue.
• Les baux de workers sont acquis par une décision SQL atomique et les paramètres des requêtes groupées sont préparés sans parcours répétés. L'archive exige sa propre transaction DATA pour ne pas enregistrer un reçu encore annulable.
• Avec le pilote PostgreSQL psycopg, l'analyse et l'archive préparent moins d'objets SQL pour leurs lots. Les transactions, identifiants et contrôles de doublons restent conservés ; le gain doit être mesuré par la recette.
• La vitesse déclarée et la vitesse calculée restent identifiées. Les sauts GPS, horloges et vitesses incohérentes interrompent les preuves sans modifier le point brut ; contexte cartographique et réglages sont conservés.
• Une fenêtre bornée fournit une vitesse moyenne avec durée et incertitude lorsque les fixes successifs sont insuffisants. Les mesures ACC intercalées conservent la preuve GPS. Cette moyenne ne prouve pas un arrêt brutal.
• Arrêt brutal, immobilisation sur piste ou près du bord, contresens et sortie de piste demandent plusieurs points cohérents. Pitlane et paddock excluent les arrêts. Le sens et la précision doivent être connus. Les règles restent modifiables et aucune commande automatique des feux n'est ajoutée.
• La reprise historique utilise un état séparé et ne remplace pas le direct. Les preuves de dépassement suspect sont durables. Les positions sont regroupées sur 100 ms par tracker ; une alerte déclenche sa lecture autorisée immédiatement.
• Le silence du flux est surveillé sans nouveau point ; heartbeat et historique ne le masquent pas. Une règle retirée ne déclenche plus d'alarme depuis un ancien contexte. Le repli SSE relaie les alertes avec contrôle du compte et de la session.
• Un GPS répété avec un nouvel identifiant et les paquets hors ordre restent enregistrés, sans repousser le silence ni remplacer l'état d'analyse. Une erreur après un commit terminé ne rouvre pas les effets déjà enregistrés.
• Heartbeat et réenregistrement actualisent le contact sans rétablir online après un silence confirmé ; une nouvelle observation live éligible rétablit cet état. Les notifications reflètent l'état enregistré.
• Les notifications WebSocket et SSE conservent l'identifiant de l'incident enregistré, pour retrouver la même alerte après une reprise.
• Le tampon USB conserve les points jusqu'à l'accusé durable. Sauvegardes et restaurations préservent les nouveaux états et identifiants ; la sauvegarde complète suspend les deux processus. Un point est limité à 64 Ko ; l'audit HTTP redondant des points acceptés est supprimé.
• Les tampons hors connexion restent bornés : USB à 250 000 événements ou 512 Mio, Android à 50 000 mesures ou 24 heures. Une saturation USB suspend la lecture ; la radio actuelle ne reprend pas les trames jamais reçues. Les pertes Android restent affichées. Ces tampons ne garantissent pas une journée complète sans serveur.
• Tracker Android 0.5.0 conserve 5 Hz par défaut et propose 1, 5, 10 ou 20 Hz. La capture continue pendant les requêtes ; les lots privilégient les mesures fraîches, avec un quota de rattrapage. La cadence GNSS réelle et le délai d'alerte restent à mesurer.
• L'envoi Android par lots conserve le même corps lors des retries et attend chaque accusé durable avant retrait. Un lot peut confirmer certains points et en refuser d'autres ; une réponse malformée n'efface rien. Le repli vers l'ancienne API intervient à la tentative suivante.
• Le drain USB réduit les lectures répétées par trame. Les refus de statut, de révocation ou de type conservent leurs enveloppes bloquées, sans faux accusé. Le cache de configuration détecte les remplacements de fichier et les changements pendant une lecture.
• La conservation serveur reste de trois jours. Le tampon Android de 50 000 mesures représente au plus 41 min 40 s sans accusé à 20 Hz ; ses pertes restent comptées et visibles.
• Android transmet le cap fourni par le fix GNSS courant. Un cap absent ou périmé reste absent ; l'ancien cap et un calcul entre deux positions ne sont plus présentés comme une mesure native.
• Les vrais fixes GPS frais gardent leur priorité sur ACC et le rattrapage. Un point devenu ancien rejoint l'historique avec sa session d'audit. L'affichage et la reconnexion conservent le fix et les métadonnées de vitesse.
• Le sens attendu se règle dans l'éditeur de secteurs et zones de piste. Le cap GNSS est contrôlé par un déplacement significatif ; des caps contradictoires suspendent la preuve de contresens.
• Une panne DATA conserve le démarrage des comptes et réglages ; le moteur réessaie sa préparation au retour de la base, sans acquitter de point non enregistré.
• Une DATA revenue sans migrations est initialisée avant reprise des consommateurs. Une ancienne archive initialise les nouvelles règles ; une archive 0106 conserve les suppressions décidées par l'opérateur.
• La création du journal sur PostgreSQL conserve ses contraintes SQL ; l'ancienne traduction qui empêchait cette migration est corrigée.
• Les migrations traduisent les identifiants SQLite AUTOINCREMENT vers PostgreSQL et refusent de lancer les consommateurs si DATA reste incomplète.
• Le traitement des trackers retire les lectures d'identifiant inutiles, tout en conservant les identités stables des reçus et des alertes.
• La mise à jour du direct utilise des conditions SQL portables sur PostgreSQL, y compris pour ACC seul et une précision absente. Une erreur pouvait faire vieillir les positions avant validation des alertes.
• Des caches mémoire bornés réutilisent les contextes décodés et les contours préparés. Chaque lot vérifie sa source durable ; une restauration renouvelle les caches. La cartographie conserve ses contours et les mêmes critères de zones et de distance au bord.
• La lecture du contexte regroupe les métadonnées internes dans un snapshot SQLite cohérent en lecture seule. Les chemins de base et d'archive copient les seules sections utiles de configuration, avec les mêmes contrôles de fraîcheur et la compatibilité des anciens réglages GNSS.
• La recette de sauvegarde vérifie le même journal sur PC et Pi, avec les mêmes contrôles de restauration et de sécurité.
• Un refus d'arrêt du writer conserve l'erreur initiale et les références actives. La fermeture des processus d'analyse et d'archive ne tente plus cet arrêt une seconde fois ; la restauration reste refusée.
• Le banc de charge prépare son propre circuit et sa carte après vérification de DATA, pour qualifier les trackers sans dépendre du circuit livré par défaut.
• Le débit de 40 trackers et le délai de deux secondes restent soumis à la recette mesurée. Les trames USB anciennes sans précision ou heure fiable limitent les alertes ; le firmware enrichi externe et les transmissions matérielles doivent encore être qualifiés.

4.6.0-0105

• Le champ « N° » disparaît des palettes Piste et Secteurs. Les commandes de ces palettes n'ajoutent plus de numéro. La saisie du drapeau texte T, les programmes et les anciennes commandes API restent compatibles.
• L'état piste réutilise les panneaux dans la même requête et transforme les événements de comptage déjà lus, sans les relire individuellement. Les droits et filtres restent conservés, sans cache partagé entre comptes.
• La recette reprend les contrôles manquants de 0104 avec un nouveau paquet identifié. Les limites fournisseur, restauration et délais sont consignées dans le bilan de recette ; ces notes ne présument pas de leur réussite.

4.6.0-0104

• BUG-000032 : cliquer sur le fond de la carte Piste conserve le drapeau sélectionné et le texte déjà validé. Le prochain clic sur un panneau utilise cette sélection. Le clic sur le fond ne commande aucun feu.
• Échap hors fenêtre ouverte et Annuler dans la saisie texte gardent leur rôle. Le changement de palette, les contrôles de droits et la protection contre les clics sous le bandeau restent conservés.
• Sur un écran de hauteur inférieure ou égale à 600 pixels, notamment en paysage 844 × 390, le menu de la barre supérieure utilise aussi son affichage compact en haut de l'écran, avec hauteur limitée et défilement interne.
• Ce nouveau candidat suit le bilan 0103 clos avec une qualification fonctionnelle incomplète. Ses corrections exigent leurs propres validations ; aucun succès Pi, publication ni rendu matériel n'est présumé.

4.6.0-0103

• Les sauvegardes Cloud, locales, la restauration et la récupération après sinistre sont regroupées dans Configuration → Sauvegardes. La tuile Cloud et sa fenêtre disparaissent de Piste. L'ancien lien #restore ouvre les archives.
• Le catalogue d'archives Cloud est chargé seulement dans son onglet. La programmation locale reste accessible lorsque le Cloud est lent ; les requêtes simultanées sont regroupées. Les droits, l'option payante et les confirmations de restauration restent conservés.
• Le chargement des cartes ne bloque plus tous les autres chargements derrière un verrou réseau unique. Le nombre d'acquisitions est limité ; les erreurs DNS, HTTPS, réseau, fournisseur et les délais dépassés sont distingués. Les images sont vérifiées avant affichage et mise en cache.
• Dans Configuration → Cartes, préparez un cache IGN sur les limites de la carte ou autour de son centre, avec un rayon de 0,1 à 5 km. La zone est un carré couvrant ce rayon. Une estimation présente les images présentes et manquantes, leur volume réel ou estimé, puis la progression et l'annulation du téléchargement.
• Le téléchargement est borné à 100 km² et 5 000 images, soumis au quota réel. OpenStreetMap autorise la consultation et son cache habituel, mais pas le préchargement de zones ; son fournisseur public n'est pas proposé pour ce téléchargement.
• Les indicateurs Piste réservent la place des contrôles Calques et défilent sous ceux-ci lorsque la hauteur manque. Les positions enregistrées sont conservées, y compris lors des déplacements au clavier ou à la souris des rangées sous la zone visible. La fenêtre de création OSM suit les couleurs du thème.
• L'horloge met à jour les seuls contrôles de session. Les logos inchangés ne sont plus recréés et les lectures simultanées du journal sont regroupées ; une réponse d'un ancien organisateur est écartée.
• Les liens de la fenêtre À propos précisent leur portée de traduction. Les contrôles d'aide portent aussi sur Configuration avec son panneau Sauvegardes intégré ; les échecs de déplacement conservent leurs diagnostics et captures. Les tests de concurrence identifient le thread qui possède le verrou et la fixture de restauration utilise une horloge maîtrisée, sans changer le comportement du produit.
• La qualification est confiée à Hermès et son Codex. Les images synthétiques ne prouvent pas l'accès réel OSM/IGN ni la charge du Pi ; aucun succès Pi, publication ou changement Cloud n'est présumé. Compte+IP, D1 et l'offre 2026 restent prévus pour 0104 et suivants.

4.6.0-0102

• Sauvegardes mène explicitement à la programmation Cloud. Le même formulaire est disponible dans Cloud et restauration et depuis l'accueil ; résultat lisible près du formulaire, bouton occupé jusqu'à la réponse et réglages accessibles même si le catalogue est indisponible.
• Le créateur OpenStreetMap affiche la cause d'une carte indisponible : session, droits, abonnement, images hors ligne, fournisseur ou image illisible. Réessayer et réouverture actualisent les calques ; les couches retirées ne continuent plus leurs téléchargements.
• Sur mobile, les bulles Piste enregistrées sur ordinateur se réorganisent si elles se chevauchent, sans effacer les positions de bureau. Les indicateurs restent accessibles lorsque la hauteur manque et les liens au clavier sont conservés.
• Les contrôles d'abonnement cartographique et de sauvegarde payante restent applicables. Aucun prestataire réel, DNS, proxy, serveur Cloud ou installation de production n'est modifié par ce lot.
• Tests, recette Pi et livraison sont confiés à Hermès et/ou son Codex, sur l'artefact figé. Compte+IP, D1 et l'offre 2026 restent prévus à partir de 0103.
• La recette cartographique corrige sa simulation du passage hors ligne et vérifie l'erreur HTTP 404 et l'état indisponible lors de la réouverture.
• Le créateur OSM annule son redimensionnement différé lorsque sa carte est détruite et vérifie que la fenêtre est visible. La recette conserve la destruction immédiate et les erreurs JavaScript complètes. Le fond de la fenêtre météo reste dans ses marges sur mobile.
• La fenêtre météo reste aussi dans la hauteur de l'écran. Son contenu défile et le bouton Fermer reste visible ; la recette vérifie l'accès au dernier contenu.
• La météo Cloud reprend les prévisions AROME/ARPEGE, la vigilance datée et le radar national avec son intensité au circuit en mm/h. Les données anciennes ou absentes restent identifiées, les jours affichés suivent les données disponibles et aucune animation locale ni absence d'alerte n'est inventée.
• Le radar associe chaque image à son échéance, actualise les données à l'ouverture de l'onglet et retire les mesures périmées dans une fenêtre laissée ouverte. La vigilance perd sa couleur à l'expiration du bulletin ou lors d'une transition de période. Les images restent privées. Demain suit l'heure de Paris ; la fenêtre météo tient sur mobile.
• Les journées de prévision peuvent être partielles. La sélection de station dans RTM et les sources PIAF/AROME PI restent hors de ce correctif ; les simulations ne qualifient pas les fournisseurs réels.

4.6.0-0101

• La tuile Sauvegarde Cloud de la page principale ouvre une fenêtre, comme la météo : copie immédiate ou quotidienne, restauration d’archive et récupération après sinistre.
• Dernier résultat réel actualisé chaque minute, droits et confirmations conservés. Le même panneau est utilisé dans Configuration, sur mobile et au clavier.
• La restauration ferme maintenant le flux permanent Track avant de remplacer les données ; les écritures et téléchargements ordinaires ne sont pas interrompus.
• Option payante, compte Cloud indépendant après sinistre, copie de sécurité et équipements suspendus. Même version RTM et PostgreSQL/PostGIS nécessaires ; système et code exclus.
• 0100 reste un candidat historique bloqué. Les améliorations compte+IP, D1 et l’offre 2026 passent aux builds 0102 et suivants.

4.6.0-0100

• Consolidation des protections 0099 : licence signée conservée hors ligne, retrait de sécurité différé pendant les sessions, récupération protégée, état en direct filtré et blocage temporaire de connexion.
• Option payante Sauvegarde Cloud complète, immédiate ou quotidienne : configuration, comptes, secrets applicatifs, bases et fichiers, intégrité contrôlée, rétention et suivi des erreurs.
• Après sinistre, le compte Cloud retrouve les archives sans l’ancien jeton. Sur un RTM préparé de même version, choisir l’archive et confirmer restaure configuration et données. Sauvegarde de sécurité préalable, accès système de la cible préservés et équipements à remettre en service explicitement.
• Le mini-site intégré est retiré. Les logos et anciennes pages de présentation dirigent vers les rubriques maer.fr ; les écrans métier restent locaux. Internet est requis pour les présentations commerciales.
• Client permanent de test sur le Pi principal, distinct de Mirecourt en production. Chaque publication exige la qualification de ce nouvel artefact ; les candidats historiques 0097/0098 ne sont pas réutilisés.
• Limites : pas de sauvegarde du système ou du code, 256 Mio par archive, 20 archives et 2 Gio par installation. PostgreSQL/PostGIS et la même version RTM doivent être préparés avant restauration. Les améliorations compte+IP et D1 restent au lot suivant.

4.6.0-0099

• Une panne du Cloud, un refus HTTP ou une rotation de jeton conserve la dernière licence signée. Un retrait signé des modules Flags ou Track attend l’arrêt des sessions et est journalisé.
• Les liens de récupération de mot de passe utilisent une adresse configurée ou celle du serveur. Les en-têtes de proxy ne sont acceptés que depuis un proxy explicitement déclaré.
• Le flux en direct filtre les données par compte. Pilotes et organisateurs ne reçoivent plus les panneaux, secteurs, autres organisateurs ni la télémétrie piste.
• Les échecs de connexion et demandes de récupération sont limités temporairement par compte et IP. Le blocage dure 15 minutes par défaut et ne désactive jamais définitivement un compte. Mot de passe limité à 256 caractères.
• Base Git 0096 : les travaux locaux 0097/0098 non commités restent séparés. Aucun changement Cloud ni déploiement en production.
• Les programmes de drapeaux retrouvent exactement les octets du catalogue de référence, sans changement de leurs images ni de leur comportement. L’aide de Restauration et des notes de version rejoint le manuel existant. Les pages Mises à jour et Test de couverture reçoivent leur aide contextuelle ; le manuel dérivé de l’assistant est régénéré.

4.6.0-0098 — candidat historique, consolidé dans 0100

• Le mini-site commercial intégré est retiré du paquet RTM. Les logos RTM, Track, Timing, Flags et MAER Engineering ouvrent directement leurs rubriques sur maer.fr dans un nouvel onglet.
• Les anciennes adresses des pages de présentation conduisent à maer.fr, y compris via le relais Cloud. Un lien reste disponible si la navigation automatique est bloquée ; les anciennes images et chemins inconnus renvoient une erreur 404.
• Les présentations nécessitent Internet. Les écrans métier, logos locaux et résultats de chronométrage restent disponibles dans RTM. Les adresses privées et paramètres de RTM ne sont pas transmis au site public.

4.6.0-0097 — candidat historique, consolidé dans 0100

• Programmes VSN rétablis à leurs octets originaux vérifiés par le catalogue ; dépendances des tests d'API déclarées et vérifiées avant la qualification.
• Archives ZIP compatibles Windows et Linux, fermeture des connexions SQLite après transaction et attente de fin d'instantané en cas d'annulation avant la reprise des acquisitions.
• Option payante Sauvegarde Cloud : copie complète immédiate ou quotidienne de la configuration, des comptes, secrets applicatifs, bases et fichiers du client, avec vérification d'intégrité, rétention et suivi des échecs.
• Après perte du serveur : récupération depuis le compte Cloud avec un code temporaire, sans ancien jeton ni sauvegarde locale. Sur un RTM préparé de même version, choisissez une archive et confirmez la reprise complète. Les anciennes copies restent disponibles après expiration de l'abonnement.
• Sauvegarde de sécurité, redémarrage via le worker local disponible ou Cockpit, traitement explicite des erreurs et mise en attente des acquisitions. Les comptes et réglages du client sont récupérés ; les connexions système de la cible restent en place. Les équipements nécessitent une remise en service explicite.
• Les archives portables anciennes conservent leur fonctionnement. La sauvegarde complète exclut le système, code, caches, fichiers de logs et anciennes archives. GNSS configurée inaccessible, chemin externe non pris en charge ou dépassement de quota : refus explicite. Cloud : 256 Mio par archive, 20 archives et 2 Gio par installation.
• Livraison associée à RTM Cloud 0.1.0-test.21, avec recette Pi identifiée par les empreintes des paquets avant toute promotion.

4.6.0-0096

• La mise à jour depuis 4.6.0-0094 par le bouton client fonctionne de nouveau : des fins de ligne différentes dans la liste des dépendances ne sont plus prises pour un changement de dépendances.
• Aucun autre changement : fonctions, écrans, réglages et données restent ceux de la version précédente.

4.6.0-0095

• Réorganisation interne des sources par produit, sans changement fonctionnel : fonctions, écrans, réglages, données et adresses restent identiques à la version 4.6.0-0094.
• Le paquet installé conserve la même organisation. La mise à jour ne demande aucune migration ni action particulière ; le retour à 4.6.0-0094 reste possible par réinstallation.

4.6.0-0094

• Météo Cloud enrichie : Météo-France AROME reste prioritaire. Les prochaines heures disponibles et un complément OpenWeather configuré par MAER alimentent les prévisions à cinq jours par pas de trois heures, la pluie, les nuages, la visibilité, la pression et le ressenti selon les données reçues. Les clés restent au Cloud ; la configuration manuelle est conservée.
• Les sources, les dates et la résolution des prévisions sont indiquées. Les minima/maxima quotidiens sont ceux des échantillons disponibles. Les informations absentes, dont radar, UV, vigilance ou sept jours complets, restent signalées indisponibles. Aucun abonnement OpenWeather One Call n’est souscrit.
• Nouveau menu Restauration : choix d’une archive locale, import d’un ZIP depuis le PC ou récupération d’une copie Cloud, puis aperçu du contenu et confirmation de son empreinte. Une archive importée n’est jamais restaurée automatiquement.
• Avant restauration, RTM refuse les sessions actives, crée une sauvegarde de sécurité et passe en maintenance en attendant la fin des opérations. Les comptes, secrets, identité du circuit, connexions, adresses et identifiants des panneaux, liaisons USB et réglages météo de la cible sont conservés. Un matériel de remplacement doit être raccordé explicitement. Le journal de l’assistant reste sur la cible et les demandes en attente ou approuvées sont invalidées ; les anciennes intentions d’affichage dynamique ne sont pas rejouées. Un redémarrage explicite du service depuis Cockpit est requis. Une erreur partielle garde la maintenance fermée pour une reprise contrôlée depuis la sauvegarde de sécurité.
• Sauvegarde privée dans RTM Cloud : envoi, liste, récupération et suppression confirmée, avec abonnement Maintenance et droits RTM. Les archives sont chiffrées et séparées par installation, dans la limite de 256 Mio chacune, 20 archives et 2 Gio par installation. Aucune suppression automatique pour libérer de la place.
• Les terminaux Android TV restaurés restent désactivés et révoqués : chaque écran doit être réappairé avant de reprendre son affichage.
• Livraison associée au Cloud 0.1.0-test.16 et préparation du central sur un serveur Ubuntu dédié. La qualification reste faite sur le Pi et la mise à jour utilise le même paquet privé. Une restauration applicative couvre les données incluses dans l’archive, pas le système Linux complet.

4.6.0-0093

• Piste : le titre « Palette » reste entier. Le numéro et la nouvelle liste des palettes se trouvent côte à côte sous le titre. La palette « Principale » reste le choix initial et conserve ses drapeaux, leur visibilité et leur ordre existants.
• Les palettes Flèches, Sécurité, Pluie, Glissant et Autres montrent les drapeaux classés dans les réglages. Chaque drapeau possède un nouveau champ « Palette spécialisée », distinct de sa visibilité dans la principale ; la liste indique ces deux états. Les programmes usuels actifs du catalogue sont préclassés une fois et les doublons archivés restent masqués. Un drapeau ne peut être classé que dans une palette spécialisée. « Extinction » est toujours disponible. Changer de palette annule la sélection en cours sans commander de feu.
• L'historique ci-dessous regroupe les évolutions retrouvées dans les notes et documents antérieurs. Les attributions ou publications incertaines sont indiquées au lieu d'être présentées comme acquises.
• Premier lot du chantier Assistant IA : le manuel RTM versionné devient consultable avec le seul abonnement IA. Les états du site, diagnostics et propositions de réglage exigent toujours l'abonnement Maintenance et les droits RTM. Aucun accès au terminal, aux fichiers ou aux commandes de feux n'est ajouté. Le serveur RTM Cloud correspondant porte la version technique 0.1.0-test.15 ; un fournisseur et un modèle IA doivent être configurés.
• La base interne reçoit un champ additif de classement, sans effacer les drapeaux personnalisés ni les préférences existantes. L'installation en un clic conserve le dispositif de sauvegarde et de retour arrière ; une restauration intégrale repose sur la sauvegarde des données et de la configuration de l'installation.

4.6.0-0092

• Sur le Pi de test, le superviseur de la base USB distante attend 30 secondes entre deux recherches lorsque la base est absente, et 10 secondes après une erreur. Cela évite que les recherches USB/IP répétées monopolisent le processeur.
• La reconnexion automatique reste active : dès que la base distante réapparaît, elle est reprise au prochain contrôle. Une reconnexion peut donc prendre jusqu'à environ 30 secondes de plus. Aucune commande de feu ni modification des données de circuit n'est effectuée.
• Maintenance du banc de test : anciennes sauvegardes NAS déplacées sur la clé USB après vérification, cache de construction supprimé et anciennes piles Docker arrêtées. Ces actions ne concernent pas l'installation de Mirecourt.

4.6.0-0091

• La zone d'information du drapeau prend la place restante après les secteurs. La limite de largeur qui imposait un défilement des secteurs est supprimée.
• Les boutons de secteurs gardent leur nom et le nombre de panneaux lisibles, sans ascenseur interne. Si la fenêtre est trop étroite, la barre répartit les éléments sur plusieurs lignes et adapte sa hauteur, sans masquer la carte ni la palette.
• L'encart reste dans la barre du bas avec sa couleur, son aperçu et ses instructions. Les boutons « Bugs et suivi » et Aide restent accessibles. Les droits, les commandes et la sortie par Échap sont conservés ; sélectionner un drapeau n'envoie aucune commande.
• Correction du défaut observé sur le Pi en 0090 avec les barres de défilement classiques. Aucun changement du moteur serveur, du schéma de données ou des dépendances.

4.6.0-0090

• L'encart du drapeau sélectionné est replacé dans la barre inférieure des secteurs. Sa présentation horizontale compacte utilise l'espace disponible à côté des secteurs, au lieu d'un panneau séparé au-dessus de la barre.
• La couleur de fond, l'aperçu du drapeau et les instructions contrastées sont conservés. Les boutons « Bugs et suivi » et Aide restent accessibles à droite sans recouvrir le message ; la disposition s'adapte aux petites fenêtres. Si la barre des secteurs est masquée dans les préférences, l'encart seul apparaît temporairement en bas pendant la sélection.
• Échap et le clic hors zone quittent la sélection. Les droits et les commandes restent inchangés ; sélectionner ou prévisualiser un drapeau n'envoie aucune commande. Aucun changement de données ni de dépendances.
• Consigne permanente de recette : utiliser en priorité l'installation principale du Pi avec sauvegarde et retour arrière utiles, pour rendre le candidat visible et éviter les installations parallèles superflues, tout en conservant l'isolation des tests et du matériel de production.

4.6.0-0089

• L'encart de sélection des drapeaux dispose d'un espace réservé sous la carte et la palette, au-dessus de la barre des secteurs. Si l'écran manque de hauteur, la page défile et l'encart reste accessible après la palette, sans recouvrir ses choix. Les couleurs, textes et aperçus contrastés de 0088 sont conservés.
• L'encart laisse utiliser la palette, y compris le choix Texte sur petit écran. Un clic sur l'encart ne commande pas un feu ou un secteur masqué dessous ; les commandes au clavier restent disponibles. Il disparaît à la sortie de sélection, à la désactivation de Flags ou au retrait des droits d'action sur les drapeaux. Le droit de commander suffit à conserver la sélection. La sélection et l'aperçu seuls n'envoient aucune commande.
• Consigne permanente de l'utilisateur : chaque changement livré, même mineur, doit incrémenter la version et être expliqué dans les notes de version.

4.6.0-0088

• À propos : numéro complet mis en évidence et actualisé à chaque ouverture, accès au catalogue par « Vérifier les mises à jour » et à ces notes par « Liste des changements ». Consulter le catalogue ne lance aucune installation. En cas d'échec du chargement, la version est indiquée indisponible.
• BUG-000029 « Couleur souris » : l'encart de sélection montre le drapeau choisi pour limiter les confusions. Son fond reprend la couleur, avec une vignette de la palette pour les motifs, images et textes. Le numéro ou le texte choisi reste indiqué dans l'action.
• Texte contrasté, aperçu fixe sans clignotement ni curseur personnalisé, encart placé au-dessus de la barre de commandes et des boutons Bugs et suivi/Aide. Les instructions restent visibles même si une image ne se charge pas.
• La touche Échap permet de quitter la sélection lorsqu'aucune fenêtre de dialogue n'est ouverte. Le clic hors zone reste disponible. La sortie efface l'aperçu et ses couleurs ; les commandes et permissions restent identiques.

Fonctions disponibles en 4.6.0-0087

• Mises à jour privées : catalogue RTM Cloud, version installée et notes des publications. L'installation nécessite une action explicite et un service local préparé par MAER. Le parcours vérifie les publications signées et prévoit sauvegarde, contrôle du service et restauration en cas d'échec.
• Météo : affichage des conditions et de la température, vent et direction, prévisions et alertes selon les données disponibles et le fournisseur configuré.
• Connexion Cloud : réglages du raccordement privé, test de connexion et vérification des informations de licence. La disponibilité des services connectés dépend du raccordement et des droits correspondants.