STREET WIZARD

Rôle

Rendre la carte, tenir la caméra sur le véhicule, calculer l'itinéraire, détecter la sortie de route, porter tous les marqueurs.

Pièces

mapbox.ts 756 · NavExperience.tsx 4 648 · camera.ts 251 · route-track.ts 171 · nav-view.ts 68 · cluster.ts 69 · Speedometer.tsx 551 · HighwaySignBoard.tsx 160

Décision — Mapbox n'est pas une dépendance npm

La bibliothèque est chargée à l'exécution, version épinglée v3.9.0, par injection d'un <script> pointant le CDN Mapbox (GL_VERSION, mapbox.ts:71). Favorable : zéro poids Mapbox dans le bundle initial. Défavorable : carte indisponible si le CDN ne répond pas, version verrouillée par une constante du code et non par le lockfile, et aucun contrôle d'intégrité de sous-ressource. Voir F-04.

Règles d'or — non négociables

• Les marqueurs sont du HTML. Véhicules, pairs, signalements, commerces et annonces sont des éléments DOM au-dessus du canvas. Ni couches symboles, ni WebGL. Toute modification qui suppose des objets GL est fausse pour ce dépôt.
• Bloquer la pression, pas le clic. Mapbox lie le déplacement sur mousedown/touchstart. Au moment où click se déclenche, la carte a déjà bougé. Tout contrôle dans un marqueur intercepte pointerdown + mousedown + touchstart (non passif) et click.
• L'ancre du véhicule est padding.top. Mapbox centre sur (haut + hauteur − bas)/2 : un grand « bas » remonte la voiture. Inversion déjà commise une fois, documentée en garde dans camera.ts. Ne pas ré-inverser.
• Certaines options n'existent qu'à la construction (anticrénelage, plafond de densité de pixels). Les changer impose de remonter la carte via sa clé React — déjà câblé.

Sortie de route — pourquoi l'écart latéral ne suffit pas

Une première version déclenchait le recalcul sur l'écart latéral. Ce critère reste à ~0 m pendant un demi-tour complet : on roule sur la ligne, à l'envers. Le module projette donc la position en curviligne et surveille la progression — WRONGWAY_M = 120 m de recul cumulé, plancher 15 km/h.

La pose de caméra — trois régimes, et un seuil de bascule

Nouveau depuis la révision A : la caméra n'a plus une pose mais trois, et le régime se choisit au zoom. BROWSE_ZOOM_HI = 16,5 : au-dessus, vue de conduite, angle du conducteur. BROWSE_ZOOM_LO = 12 : en dessous, carte à plat, on lit la ville. Entre les deux, interpolation. COCKPIT_PITCH est passé de 66 à 70, encadré par MIN 45 / MAX 80 pour que le doigt ne puisse pas mettre la caméra sous le sol ni la coucher à l'horizontale.

État : opérationnel. Deux corrections de terrain de la révision A attendent toujours une confirmation au volant (voir N-5).

Canal

wo-fleet-live, mode présence, clé = guest_id de l'appareil

Pièces

fleet.ts 754 · chat.ts 147 · presence.ts 140 · parking.ts 139

Le stationnement — le seul endroit où une position s'écrit, et elle est décalée

fleet_parked, une ligne par rouleur, purgée dès qu'il repart en live. Règle : si le point de stationnement est à moins de PARK_SAFE_M de la maison, la position publiée est décalée sur l'église la plus proche (catégorie Search Box place_of_worship — le lieu de rassemblement par défaut de la scène) ; à défaut, sur une caserne ; à défaut, arrondie sur une grille d'environ 500 m. Le flou est honnête et déclaré : l'écran dit « secteur », pas une fausse adresse précise.

Présence en lecture seule — et pourquoi la vitrine web ne se déclare pas

presence.ts s'abonne et lit, rien d'autre. Se déclarer présent depuis la page web publique d'un crew ferait apparaître sur la carte, en conduite, quelqu'un qui lit une page web — un pin qui ne roule pas et ne bougera jamais. La déclaration reste l'affaire de useFleetChannel, sur la carte, là où il y a vraiment un véhicule.

Pièces

session.ts 253 · profile.ts 456 · account.ts 83 · fleet-reset.ts 66

Tables

fleet_accounts, fleet_sessions, fleet_roles, fleet_admins — toutes scellées

Le jeton — ce qu'il est, précisément

256 bits tirés par le serveur (extensions.gen_random_bytes(32), migration 0017), rendus en hexadécimal, insérés dans fleet_sessions avec une expiration à 90 jours. Chaque ouverture purge au passage les sessions expirées. Le client ne garde que ce jeton opaque ; le rang n'est jamais stocké localement comme une vérité, il est demandé au serveur (fleet_whoami).

Suppression de compte — ce qui prouve que c'est bien toi

Un compte réclamé exige la passphrase : c'est la seule preuve d'identité que ce modèle possède. Un rouleur qui n'a jamais réclamé de compte n'a que son guest_id, et c'est déjà ce avec quoi toute l'app écrit en son nom ; le code ne fait pas semblant que c'en est plus. Le serveur efface ses lignes, puis l'état local est effacé — s'arrêter au serveur laisserait l'app ouverte sur un compte qui n'existe plus.

Règle de plafonnement

On n'accepte que ce que 300 km/h sur le temps réellement écoulé autorise ; le surplus est jeté. Fenêtre plafonnée à 24 h, soit 7 200 km par rattrapage — jamais atteignable par un vrai rouleur. Le refus reste muet : une erreur explicite dirait à un script sous quel seuil se placer.

Formule de niveau : niveau = ⌊ (km / 3)^1/1,5 ⌋, bornée au maximum. Repères : niveau 10 → 95 km · niveau 22 → 305 km · niveau 37 → 676 km. Le niveau n'est jamais stocké comme vérité : il est recalculé. Côté serveur il n'est jamais repris — greatest(niveau, calculé) — pour qu'une retouche de formule ne déclasse personne.

Le garage est le plus gros module moteur du dépôt (garage.ts, 1 225 lignes) : catalogue de véhicules, sprites 3/4 pour la fiche et vue arrière détourée pour le pin de carte, déblocages par niveau, décors de showroom (spots.ts) débloqués eux aussi au niveau, de Montréal (gratuit) au niveau maximum.

Deux pistes de progression, volontairement séparées : le niveau se dérive des kilomètres — on ne peut pas se le fabriquer sans rouler — et l'XP mesure la vie sociale. Verser de l'XP de publication dans le niveau casserait la garantie : quelqu'un monterait au clavier et « niveau 37 » cesserait de vouloir dire « j'ai roulé 700 km ». Le gain d'XP est décidé par le serveur, dans la même transaction que le post : délai entre deux posts payants, plafond quotidien, bonus VIP.

Le côté de la route n'est jamais demandé. Le cap GPS du signaleur part avec l'alerte ; le filtrage « devant moi, dans mon sens » se fait à la lecture. La concurrence pose la question ; ici on la déduit, ce qui retire un geste en conduisant.

Appui long = police, ~450 ms, sans rien ouvrir. C'est ~80 % des signalements : lui faire traverser un menu est le vrai défaut de la concurrence.

Diffusion sur un canal dédié wo-reports — ajouté depuis la révision A, où la relecture était périodique. Un signalement apparaît désormais chez les autres sans attendre la prochaine lecture. Durée de vie serveur par report_ttl, fusion des doublons, confirmation et infirmation par vote.

Canal

wo-convoy-<id> — présence des membres + diffusion de la destination

Serveur

11 RPC : convoy_create, convoy_get, convoy_join, convoy_join_public, convoy_leave, convoy_mine, convoy_public_list, convoy_set_dest, convoy_set_visibility, convoy_halt

Scellées

fleet_convoys, fleet_convoy_members

Séparation nette entre ce qui doit survivre et ce qui doit disparaître : le groupe vit en base (il survit aux reconnexions, à la fermeture de l'app, au tunnel), les positions restent en présence sur le canal flotte global, filtrées par appartenance. Aucune position de convoi n'est écrite. Le leader partage une destination ; elle est diffusée sur le canal et route chez tout le monde.

« Devant », pas « autour ». Le contraire de la concurrence, qui renvoie volontiers dix kilomètres en arrière. On ne garde que ce qui est devant : le long du trajet si l'on navigue, sinon dans un cône vers le cap.

État inchangé depuis la révision A : la fiche riche (photos, horaires, achalandage, Building ID) est architecturée en deux étapes — Search Box API pour le mapbox_id, puis l'endpoint Details — avec un substitut propre en attendant. Deux points restent à confirmer avec un vrai jeton : l'URL de l'endpoint et la forme du parseur. Ils sont isolés à deux endroits, marqués comme tels. Voir R-7.

Forme : le pin d'annonce est une pastille de prix, pas l'hexagone maison. Sur la même carte, une auto à vendre et un radar ne doivent pas avoir la même silhouette : l'une invite, l'autre avertit.

Le rang vient du serveur (fleet_whoami), jamais de l'appareil. Il n'ouvre qu'un bouton de plus ; la RPC revérifie le galon de son côté. Un client modifié ne gagne rien à mentir.

Depuis la révision A : réactions typées sur le mur (migrations 0049 → 0063, dont un déploiement en trois temps — accepter les deux formes pendant la bascule, puis restreindre), épinglage de commentaire, liste des réacteurs, recherche de rouleurs, classement, fiches techniques de véhicule en texte riche.

Chaque rouleur porte un CD ; les autres le consultent depuis sa fiche, mettent un « j'aime » ou un favori qui l'ajoute à leur roadtrip. Une chanson peut passer en direct sur la radio de province (canal wo-radio-<prov>, rotation serveur par radio_rotate).

4 390 lignes, aucune mesure automatisée dans ce dossier. C'est le plus grand angle mort recensé, et il a triplé de taille depuis la révision A — voir N-3.

Migration 0070, likes_were_failing_silently : les « j'aime » échouaient sans rien dire. Le nom du fichier est le constat. C'est le type de défaut que ce sous-système produira encore tant qu'il n'est pas exercé.

Mur public, commentaires, messages privés et annonces sont du contenu généré par les utilisateurs. La règle 1.2 de l'App Store exige de pouvoir signaler un contenu, bloquer une personne et joindre l'éditeur. Rien de tout cela n'existait.

Quatre états distincts sont rendus — pas de session / session sans rang / hors ligne / d'accord — parce que la version précédente rendait null dans les quatre cas et affichait la même phrase grise : impossible de savoir laquelle, donc impossible de réparer.

Fenêtre sur les gels : le gel est muet pour le rouleur, par conception. Le prix de ce silence est qu'un faux positif ne se voyait nulle part. La console affiche donc en permanence le compte de gels — un zéro y est un zéro mesuré — et, dès qu'il dépasse zéro, une bande dit combien et depuis quand, le rouleur concerné remonté en tête de liste.

Étendu depuis la révision A en six panneaux : véhicules (catalogue et variantes), codes promo, dons de véhicules, stations de radio, crews, télémétrie serveur. 3 480 lignes. Toutes les RPC de ces panneaux prennent un jeton et résolvent le rang côté serveur : aucune identité n'est acceptée en argument.

Veille écran : GPS = écran toujours allumé sur la carte, verrou repris automatiquement au retour d'arrière-plan. La veille tue le GPS ; c'est un verrou fonctionnel, pas un confort.

Couches de navigation : un registre central fait que le geste retour Android/PWA referme la surface ouverte au lieu de quitter la carte. Vingt-deux surfaces y sont inscrites.

Le conteneur natif — ce qui est fait et ce qui ne l'est pas

Capacitor 8.5.1, identifiant net.streetwizard.app, dossier android/ présent. La cible build:app coupe Nitro et demande à TanStack Start de pré-rendre une coquille — vérifié : dist/client/index.html, 5 Ko, avec la feuille de style et l'amorce du client. C'est ce dossier qu'on embarque.

On n'utilise pas server.url. Pointer la webview sur https://streetwizard.net serait cinq minutes de travail, et ce serait littéralement le site dans une fenêtre : le cas que la règle 4.2 d'Apple vise en premier, sans démarrage hors-ligne ni écran de chargement propre. La coquille embarquée démarre sans réseau ; les données arrivent ensuite, comme dans le navigateur.

Ce qui reste à faire, déclaré : le dossier ios/ (exige macOS et CocoaPods — un projet natif déposé sans qu'aucun Xcode ne l'ait ouvert serait invérifiable) ; l'origine publique à donner à la fonction serveur de réinitialisation, qui n'existe pas dans la coquille ; les permissions natives (position en arrière-plan, audio en veille) et leurs textes de justification iOS — ce sont eux qu'Apple lit.

Trois sources volontairement distinctes, affichées séparément : les favoris et le travail vivent en base (user_places, scellée, plafonnée par user_places_cap) ; l'historique vit en base aussi (trip_history, scellée) ; la maison ne quitte jamais l'appareil.

Les fondre en une seule liste ferait disparaître une différence qui compte : un favori est une intention, une entrée d'historique est une trace. L'historique est écrit à l'arrivée, jamais au départ — une destination abandonnée en chemin n'est pas un trajet, et la reproposer serait proposer de refaire une route qu'on a précisément décidé de ne pas faire.

La maison reste en localStorage parce que c'est elle qui pilote le mode fantôme : la donnée la plus sensible du produit est aussi la seule qui n'a jamais de raison de partir sur le réseau.

Le guidage vocal avait été coupé (speak() réduit à un no-op) parce qu'il entrait en conflit avec le design sonore : la voix parlait par-dessus l'ambiance et le démarrage moteur, et deux sons qui se battent valent moins que le silence. Le remettre en enlevant le return aurait reproduit le problème à l'identique — le défaut n'était pas la voix, c'était l'absence de règles entre elle et le reste.

Les quatre règles, dans voice.ts :

1. Elle baisse le reste. Toute annonce coupe l'ambiance le temps de parler et la rend ensuite. La voix ne se superpose plus, elle prend la parole.
2. Elle ne s'empile pas. Une file d'attente est pire que rien en voiture : une consigne qui arrive trois secondes après le virage fait tourner au mauvais endroit. On annule ce qui est en cours et on dit la chose neuve.
3. Elle a une priorité. Un virage passe devant une alerte routière ; une alerte ne coupe jamais une consigne de manœuvre.
4. Elle parle la langue de l'app (fr/en), pas un fr-CA codé en dur, et choisit une vraie voix de cette langue si le système en a une.

L'ambiance suit la météo réelle du point où l'on roule (Open-Meteo, sans clé, cache par arrondi de coordonnées) : beau temps et pluie ne sonnent pas pareil.

Aucun paiement n'est encaissé dans l'application à ce jour : il n'y a ni Stripe, ni achat intégré, ni abonnement. Ce sous-système est l'outillage de la monétisation — ce qui permet de distribuer, de récompenser et de mesurer — pas la caisse.

Codes promo : deux temps séparés à dessein — regarder (promo_peek) puis échanger (promo_redeem). Le rouleur voit ce que le code lui ouvre et choisit sa caisse, au lieu d'échanger à l'aveugle et de découvrir après coup ce qu'il vient de prendre. Un choix irréversible ne se fait pas les yeux fermés. Trois tables, toutes scellées.

Dons de véhicules : quatre natures — boss, crew_perk, gift, staff — attribuées depuis le back office, jeton obligatoire, révocables.

VIP : xp_is_vip côté serveur ; le statut modifie les règles de gain d'XP, pas le niveau.

Page de crew publique (/org/$slug, 1 546 lignes) : lisible sans app, sans compte, indexable. Roster, présence en direct (en lecture seule — voir S-02), véhicules du crew, mur. C'est la surface d'acquisition du produit : un crew partage son lien, et ce lien montre quelque chose de vivant plutôt qu'une page d'atterrissage.

Cartes partageables : assemblage sur un <canvas> 1200×630 des mêmes calques que le garage (décor + véhicule + fiche technique), export JPEG, partage natif sur mobile et téléchargement ailleurs. 100 % client, aucun rendu serveur : léger, instantané, zéro dépendance.

Pages légales : /privacy, /terms, /data-deletion. Prérequis de soumission des deux boutiques — voir section 11.

Constat. La passphrase est réduite côté client à un SHA-256 sans sel ni fonction de dérivation, puis comparée telle quelle en base. Le condensat est un porteur. Aucune limitation de débit ne protège fleet_session_open ni fleet_session_open_nick, toutes deux exécutables par anon.

Portée du risque. Un bourrage d'identifiants est réalisable depuis l'extérieur sans aucun frein. Une fuite de fleet_accounts — actuellement protégée par le scellement — donnerait des condensats directement réutilisables, sans même avoir à les casser.

Remède. Par ordre de coût croissant : (1) limitation de débit par identifiant et par IP sur les deux fonctions d'ouverture, avec délai croissant ; (2) re-condensation côté serveur en crypt() / bcrypt avec sel, migration progressive au prochain succès de connexion ; (3) adoption de Supabase Auth, qui apporte au passage la vérification HaveIBeenPwned relevée en 11.1. C'est la première recommandation du dossier — voir R-1.

Constat. Le guest_id est une chaîne locale, et il circule publiquement (roster de crew, liste de réacteurs, membres de convoi). Les fonctions bornent ce qu'un appelant peut faire par unité de temps mais ne prouvent pas la propriété de la ligne visée.

Atténuation en place. Plafonnement physique de l'odomètre · rang résolu au serveur pour toute modération et tout back office · tables sensibles scellées · plafonds de volume sur lieux, trajets et chansons.

Remède. Exiger le jeton de session sur toutes les écritures identitaires, comme c'est déjà le cas pour le back office. Le motif existe, il est éprouvé, il reste à l'étendre. Voir R-2.

État depuis la révision A : inchangé sur le fond, mais la surface a grandi — 33 RPC de plus, dont plusieurs écrivent à guest_id.

Constat révisé. 50 tables étrangères subsistent dans wizardops. Elles totalisent 116 lignes ; 19 sont vides ; 41 existent à l'identique dans le schéma chantier, où le produit vit désormais.

Ce qui a changé. À la révision A, ce constat était majeure et décrit comme le seul dont le rayon d'explosion dépassait Street Wizard. Le produit a depuis migré vers ses propres schémas. Ce qui reste est un résidu de migration.

Risque résiduel. Une politique RLS trop permissive sur l'une de ces 50 tables reste exposée à la clé publique de Street Wizard ; et un développeur qui écrit dans la mauvaise copie perd sa donnée en silence, ce qui est le mode de défaillance le plus coûteux à diagnostiquer.

Remède. Supprimer les 50 tables résiduelles après confirmation que chantier et public portent bien la donnée vivante. Opération de nettoyage, pas de refonte. Voir R-3.

Mapbox GL JS v3.9.0 est injecté à l'exécution depuis api.mapbox.com, version épinglée par une constante du code et non par le lockfile, sans attribut integrity. Aucun poids dans le bundle (bénéfice réel), mais : indisponibilité de la carte si le CDN ne répond pas, et exécution de code arbitraire sur la page porteuse du jeton en cas de compromission du CDN. Remède : ajouter un contrôle d'intégrité de sous-ressource, ou héberger la bibliothèque. Voir R-6.

Constat. Deux paires partagent un numéro : 0016_dump_tickets_and_undo + 0016_odometer_catchup, et 0017_session_open_gen_random_bytes + 0017_admin_frozen_riders. Deux numéros manquent : 0020 et 0058.

Portée. Sur une base neuve rejouée depuis les fichiers, l'ordre de deux migrations de même numéro est indéterminé. Ici les fonctions sont en create or replace et indépendantes, donc le rejeu resterait correct — mais la garantie tient au contenu, pas à la numérotation.

État. La discipline a tenu sur 50 migrations depuis : aucune nouvelle collision. Les paires historiques n'ont pas été renommées — renommer un fichier déjà appliqué provoquerait un rejeu chez quiconque suit le registre. Décision laissée au propriétaire. Le constat est rétrogradé parce qu'il est historique et clos en pratique.

Les lignes d'une personne bloquée arrivent au téléphone avant d'être écartées. Déclaré dans moderation.ts. Durcissement : filtrer dans les RPC de flux (fleet_wall_feed, dm_inbox, market_near). Voir R-5.

:root porte une palette claire complète qu'aucun écran n'utilise, héritée du gabarit de départ. Elle a déjà causé un fond blanc en production, par un defaultTheme="light" qui réécrivait à l'hydratation la classe posée au SSR. Un jeu de couleurs mort est un piège pour le prochain développeur. Retirer, ou assumer un mode clair et le finir.

Quatre fonctions des spots de la route (road_status_ttl, road_vote_radius_m, _road_dist_m, _road_named) survivent à des tables qui n'existent plus. Trois fonctions de notes (note_leave, notes_inbox, notes_mark_read) et la table fleet_notes ne sont appelées par aucun client. fleet_claim est remplacée par fleet_claim2 et n'est plus appelée. fleet_queue est scellée et vestigiale. Surface serveur inutile = surface à auditer sans contrepartie.

Voir 11.4. C'est la dette la plus coûteuse à rattraper après un transfert, et la première question d'une vérification diligente technique. Elle est atténuée — pas compensée — par une documentation interne d'un niveau inhabituel.

La signalétique est entièrement dessinée. Il subsiste une quinzaine d'emoji dans du texte : descriptions de badges, quelques phrases d'interface, un pied de page. Décision de l'auteur — c'est sa voix, pas du langage visuel.