Journal des modifications

Version v8.1.80 (#2304)

• Nouveau pilote de mise en demeure (par étapes) — prévisualisez gratuitement le début, puis débloquez la lettre complète.

Version v8.1.70 (#2309)

• Centre de commande admin — la barre de navigation « Actions rapides » persiste maintenant sur toutes les sous-sections, plus seulement /admin/dashboard.

Version v8.1.65 (#2305)

• Panneau en direct des décisions de la direction dans le Centre de commande — le fondateur consulte les décisions de l'équipe de direction IA depuis n'importe quel appareil, sans déploiement par décision.

Version v8.1.40 (#2288)

• Refonte du journal des modifications — catégories explicites par entrée (fini les approximations par mots-clés), une taxonomie élargie à 19 catégories, un barème de points de version durci et granulaire, la chronologie complète v0.0.0→actuelle reconstituée à partir des étiquettes git, et un panneau « Derniers développements » sur le Centre de commande.

Version v7.101.15 (#2222)

• Correction d'une collision de numéro de migration sur main — renumérotation de 0176_matter_inbound_email → 0191; rétablit un build vert pour toutes les PR.

Version v7.101.14 (#0)

• Chaque dossier a désormais sa propre adresse courriel — transférez ou mettez en copie votre correspondance et elle s'ajoute à la chronologie du dossier, dédupliquée et filtrée (ADR-0018 phase 1).

Version v7.101.4 (#2226, #2290)

• Organisation de ~550 fichiers de documentation à la racine dans docs/archive/ (documentation seulement).
• « Ouvrir le Centre de contrôle » ouvre désormais le tableau de bord du Centre de contrôle plutôt que la surface Répartition.

Version v7.101.3 (#2245)

• Espaces d'entité — espaces de travail isolés par locataire pour les institutions, cliniques juridiques et organisations.

Version v7.100.78 (#2203, #2213, #2244)

• Suivi des SLA pour les billets de support — cibles de première réponse/résolution par priorité avec états en règle/à risque/dépassé.
• Socle d'analytique de profil agrégée — un cumul quotidien, respectueux de la vie privée, des vues, contacts et engagements par prestataire (uniquement des totaux), consultable par le propriétaire du profil.
• Cadre d'espace de travail exécutif — un espace opérationnel par cadre (file, tableau de bord, décisions, journal d'audit) pour chaque cadre.

Version v7.100.53

• Publication de la version v7.100.53.

Version v7.100.18 (#2211)

• Les profils de prestataires de la place de marché affichent maintenant un état « Profil non réclamé », avec un parcours de réclamation et de vérification (nouvelle table `provider_claims`) permettant au professionnel légitime de réclamer une fiche exemple ou importée de Google et de soumettre sa vérification d'identité et de permis.

Version v7.100.8 (#2209)

• Télémétrie des dépenses IA — registre d'usage/coût par appel (ai_usage) avec cumul mensuel et alerte de seuil.

Version v7.99.83 (#1856)

• Moteur de régime de parrainage (#1856) porté au modèle Supabase sur la migration 0182 — classificateur C2C/P2P/CROSS, crédit de portefeuille à l'épreuve du double paiement et récompenses de parrainage professionnel soumises à une approbation humaine. Livré désactivé, l'activation des paiements restant verrouillée en attendant l'aval du Barreau.

Version v7.99.58 (#2212, #2215, #2229)

• Les profils de professionnels de la place de marché appliquent désormais la règle freemium ratifiée — l'identité (nom, badges de vérification, description courte, domaines de pratique, territoire, langues, contact) reste gratuite en permanence; la biographie complète, l'affichage des disponibilités en direct, les références clients et la promotion Vitrine exigent un abonnement professionnel actif.
• Tableau de bord ROI (version minimale) pour les prestataires — chiffres honnêtes par profil (vues, contacts, références présentées, délai de réponse auto-déclaré) comparés uniquement à vos 90 jours précédents, totaux agrégés seulement, sans référentiels ni données inventées.
• Espace de revue juridique de la VP Affaires juridiques — file de revue, moteur de flux à 9 statuts, décisions consignées de façon permanente et tableau de bord des risques, chaque transition étant inscrite à la chaîne d'audit de gouvernance infalsifiable.

Version v7.99.33

• Publication de la version v7.99.33.

Version v7.98.98 (#2247)

• Centre de commandement — les actions rapides passent dans une barre de navigation supérieure fixe, accessibles dès le chargement.

Version v7.98.88 (#2198, #2207)

• Journal d'événements de répartition — une nouvelle table en ajout seul « dispatch_events » et un éditeur en processus émettent un événement à chaque changement de statut de répartition ou de commande, offrant une sémantique pub-sub aux consommateurs sans courtier de messages. Branché sur le pipeline des commandes de service et les chemins de paiement, avec le cron de réconciliation existant qui rejoue tout événement dont la diffusion en processus a échoué.

Version v7.98.63 (#2200, #2224)

• Ajout d'une règle ESLint et d'un ADR qui verrouillent la frontière de modules Billets de soutien / Répartition afin d'empêcher tout recouplage silencieux entre les deux surfaces.
• Écran de classification de l'intake documentaire — choisir une carte de voie de résolution avance désormais immédiatement (sans « Continuer » redondant); le litige conserve un bouton explicite « Continuer vers le litige et contourner la résolution du différend »; le menu du type de différend passe au-dessus des options de litige et devient accessible au clavier via « Charger le parcours », avec la voie choisie rappelée à l'étape suivante.

Version v7.98.58

• Publication de la version v7.98.58.

Version v7.98.53 (#2135, #2142, #2143)

• L'historique des versions du dossier affiche maintenant les versions enregistrées de façon durable, groupées par jour, avec une restauration en un clic qui migre le dossier en toute sécurité vers cet état.

Version v7.98.43 (#2201)

• Copilote de soutien dans /admin/tickets — le personnel peut désormais rédiger une réponse ou résumer un fil de billet en un clic; le texte généré par l'IA est toujours modifiable, jamais envoyé automatiquement.

Version v7.98.33 (#2168)

• Correctif du pipeline de dérive de schéma — vérification CI en lecture seule contre la production, un workflow migrate-production sous approbation du fondateur (consigné au registre, RLS vérifié par migration), et le DDL entièrement retiré du build.

Version v7.98.8 (#2151, #2152, #2154, #2197)

• Correction du texte invisible ou peu contrasté en mode clair — les champs de formulaire et panneaux sombres (famille bg-ink-800) passent sur surfaces claires, et les accents émeraude/ambre s'assombrissent à des valeurs conformes WCAG AA; surtout visible sur les pages admin Répartition et billets, mais appliqué à l'échelle de l'application.
• Suivis de la visite guidée — le mécanisme de déploiement A/B par cohorte existe désormais réellement (un indicateur opt-in supprime l'ouverture automatique pour la cohorte contrôle et l'entonnoir admin annonce honnêtement l'état de l'expérience), les sessions connectées sont dédupliquées par compte afin qu'une personne sur plusieurs onglets ne compte qu'une fois (l'unité de décompte étant documentée sur la page admin), et un échec de récupération de l'état d'accueil qui supprime la visite initiale est désormais journalisé au lieu d'être silencieux.

Version v7.98.3

• Publication de la version v7.98.3.

Version v7.98.2 (#2195)

• Les billets de soutien ont leur application dédiée (/admin/tickets) — la page Répartition se concentre sur la vérification des huissiers et l'assignation des mandats, avec une carte d'accès direct à la boîte des billets.

Version v7.97.92 (#2150)

• La visite guidée de la page d'accueil apparaît désormais réellement — le moteur chargé à la demande n'était jamais résolu lors de l'hydratation de la page d'accueil prérendue statiquement, de sorte que la visite entièrement construite ne s'affichait pour personne; le lanceur se charge maintenant via un effet explicite après hydratation (rendu vérifié de bout en bout dans un vrai navigateur) et tout échec de chargement est journalisé au lieu d'être silencieux.

Version v7.97.91 (#2186)

• Renforcement du verrou de privilège — la péremption des vérifications est désormais par juridiction (plafond de trousse strictement borné à 30 jours), se resserre automatiquement selon la fréquence d'attache jusqu'à un plancher d'un jour, et une vérification périmée échoue avec une clause nommée distincte pour que les superviseurs voient exactement quoi corriger.

Version v7.97.86 (#2180)

• La page du marché des professionnels est désormais prégénérée statiquement par langue (les filtres s'appliquent instantanément côté client), éliminant le rendu serveur à chaque requête sur la première page marketing.

Version v7.97.84 (#2179)

• Les identifiants inconnus sous /problems et /experts renvoient désormais une vraie 404 au lieu d'un faux 200, corrigeant le gaspillage de budget d'exploration et la pollution de l'index.

Version v7.97.83 (#2150)

• La visite guidée de 30 secondes est désormais activée par défaut — elle se lance pour les visiteurs de la page d'accueil et les utilisateurs connectés de l'espace de travail sans dépendre de la configuration du déploiement (elle peut toujours être désactivée explicitement), corrigeant l'écart où la visite entièrement construite restait invisible pour tous.

Version v7.97.82 (#2176)

• Correction de la tâche planifiée d'agrégation des résultats (k-anonymat) qui n'avait jamais fonctionné — la route n'acceptait que POST alors que Vercel Cron l'appelle en GET, chaque exécution nocturne échouant en 405; le balayage planifié s'exécute désormais.

Version v7.97.77 (#2162, #2165)

• Partenariats Phase 0 — machine à états du secret professionnel, portail de supervision, schéma partenaire et faisceaux de capacités livrés derrière un indicateur (désactivé par défaut), avec une table de transitions exhaustive prouvant que le secret ne peut jamais s'attacher dans un espace non supervisé.
• Coûts serverless réduits et pages plus rapides pour les visiteurs anonymes — cache CDN pour la sonde de version, filtrage et déduplication côté client de la télémétrie d'erreurs, et un middleware qui évite l'aller-retour d'authentification Supabase pour les visiteurs non connectés.

Version v7.97.52

• Publication de la version v7.97.52.

Version v7.97.50 (#2161)

• Correction des liens hreflang et canoniques pour les langues autochtones (crk, chp, scs, xsl, ikt, gwi, dgr) — les plans de site et en-têtes Link n'émettent plus d'URL à double préfixe comme /en/crk/… qui renvoyaient un 404 aux moteurs de recherche.

Version v7.97.49 (#2148)

• Les cliniques juridiques peuvent maintenant recevoir des demandes d'invités — une personne invitée remplit le formulaire bilingue publié d'une clinique de façon anonyme, consent en vertu de la Loi 25 (instantané du consentement épinglé à la version du formulaire), reçoit un numéro de référence et confirme son courriel par lien magique; le personnel de la clinique examine les demandes dans une nouvelle file à deux volets (statuts, assignation d'une personne réviseure, insigne de courriel non vérifié). Le chemin d'écriture public est verrouillé de bout en bout : aucun accès anonyme à la base de données, un unique point d'entrée SECURITY DEFINER validé, une limitation de débit et des erreurs à l'épreuve de l'énumération.

Version v7.97.24 (#0, #2149, #2163, #2164, #2168)

• Documentation seulement — plan et décisions du fondateur (Partenariats institutionnels) dans docs/spec, ADR 0013–0016, et ébauche des Conditions partenaires/APD soumise à l'avis juridique.
• Audit en lecture seule de la dérive du schéma de production (étape 1 de l'épopée #2168) — documentation seulement, aucun changement d'exécution.
• Le centre de commandement du fondateur donne désormais un accès direct à ses vues autonomes — le moteur de campagnes, l'entonnoir de la visite guidée, l'entonnoir de conversion et l'analytique de justice sont à un clic du centre au lieu d'être des pages accessibles uniquement par URL.

Version v7.97.23 (#2139)

• Les billets de soutien ont désormais un cycle de vie visible de bout en bout — chaque soumission est conservée durablement avec une référence séquentielle TKT-AAAA-NNNNN (auparavant relayée à HubSpot seulement, perdue silencieusement quand le CRM était indisponible), un écran de confirmation complet (numéro, statut, date de création, prochaine étape), un historique « Mes demandes » avec chronologie des statuts par billet, une boîte de réception des billets de soutien avec recherche et filtres sur la page d'administration « Répartition et billets », et des avis par courriel à chaque changement de statut.

Version v7.97.18 (#2142, #2143, #2144, #2147, #2149, #2151, #2153)

• L'historique des versions d'un dossier est désormais durable et multi-appareils — chaque sauvegarde significative enregistre un instantané privé au titulaire (dédupliqué, plafonné aux 50 plus récents par dossier) avec un résumé structuré des modifications, prêt pour la future fonction de restauration.
• L'espace de travail affiche désormais un indicateur d'état de sauvegarde permanent et honnête (☁ Enregistré · Toutes les modifications synchronisées avec l'heure de la dernière sauvegarde, Enregistrement…, ✓ Enregistré, l'état distinct « Enregistré sur cet appareil » en mode local, et une reprise visible en cas d'échec d'écriture) ainsi qu'un bouton Enregistrer manuel qui force la sauvegarde immédiate et confirme par la notification « Dossier mis à jour » — la persistance est désormais évidente, jamais une déduction.
• Les réclamations ont maintenant leur propre onglet de premier plan (⚖️ Réclamations, sous « Bâtir le dossier ») — la section complète (cartes de réclamation, éléments juridiques, état de la preuve, exposition adverse) quitte le Résumé, qui conserve une carte-sommaire compacte menant au nouvel onglet.
• Vision de l'exécution v2 — l'invariant de décision humaine ouvre désormais la page et couvre les déterminations juridiques dans les trois phases, la phase 3 est recadrée comme l'orchestration de mandats signés par l'huissier (jamais la génération d'actes), le langage d'audit est corrigé (journal à ajout seul, aligné sur la Loi 25), les preuves géolocalisées reçoivent des garde-fous nommés (finalité limitée, conservation plafonnée, examen par la CAI), les validateurs deviennent la Chambre des huissiers de justice du Québec, le MJQ et la CAI, et une nouvelle section « Ce qui pourrait nous arrêter » nomme les trois points de blocage réglementaires.
• Correctifs de l'entonnoir de la visite guidée — les écritures d'événements qui échouent sont désormais journalisées au lieu d'être détruites silencieusement, l'entonnoir admin nomme chaque étape sautée en langage clair et explique la durée médiane, l'état vide indique comment démarrer la collecte, les erreurs de connexion sont distinguées des erreurs de pipeline, et la section cohortes indique honnêtement qu'aucune expérience A/B n'est encore en cours.

Version v7.96.96

• Publication de la version v7.96.96.

Version v7.96.95

• Publication de la version v7.96.95.

Version v7.96.85 (#1726, #2145)

• Les cliniques juridiques et les OBNL reçoivent la première tranche de l'initiative d'accueil sur mesure — une primitive de création de formulaires versionnée et bilingue (EN/FR obligatoires pour chaque champ) : des définitions de formulaires appartenant à l'organisation avec des versions publiées immuables, un validateur de définitions à sûreté intégrée et un moteur de rendu piloté par le schéma avec validation côté client. Les soumissions des invités et l'habillage par organisation demeurent bloqués en attente des décisions consignées de l'avocat-conseil et du fondateur (ADR-0012).
• Les stades de santé du dossier abandonnent tout cadrage d'échec — « Non viable » devient « Au démarrage » et le stade (plutôt que le chiffre) devient le titre — et le panneau de prochaine étape affiche exactement une action recommandée avec pastilles de temps et d'impact, les autres étapes étant repliées derrière « Autres étapes suggérées ».

Version v7.96.75

• Publication de la version v7.96.75.

Version v7.96.50 (#2116, #2117, #2119)

• Désabonnement en un clic (LCAP/CAN-SPAM, RFC 8058) — liens de désabonnement signés et en-têtes List-Unsubscribe dans les courriels de rappel, page de confirmation bilingue et blocage à sûreté intégrée de tout envoi facultatif.
• La phase du cycle de vie et la prochaine étape suggérée sont désormais enregistrées avec chaque élément de preuve et rétro-remplies en toute sécurité sur les dossiers existants (migration versionnée, sans perte).
• Les téléversements de preuves depuis le navigateur passent désormais par la barrière complète d'analyse (maliciels/CSAM) — les fichiers signalés et les pannes d'analyseur sont retenus et consignés comme incidents vérifiables, et les fichiers volumineux non encore analysés sont retenus (sécurité intégrale) au lieu d'être servis silencieusement lorsque l'analyse est active.

Version v7.96.25

• Publication de la version v7.96.25.

Version v7.96.15 (#2083, #2118)

• Projet pilote d'auto-hébergement (ADR-0011) — une image Docker autonome optionnelle avec un connecteur Cloudflare Tunnel prouve que la plateforme peut fonctionner hors de Vercel; les builds Vercel par défaut restent inchangés.
• Audit et verrouillage du mur de partage par sous-ensemble de documents au niveau de la base de données — 23 nouveaux tests de régression prouvent qu'un destinataire d'un partage restreint ne peut lire que les documents exacts partagés avec lui, que la révocation est immédiate et que les propriétaires ne sont pas affectés.

Version v7.96.13

• Publication de la version v7.96.13.

Version v7.96.8 (#1928, #2115)

• Synchronisation locale des dossiers, phase 3 — nouvelle commande terminal `npm run matter:rescan` pour vérifier la dérive d'un dossier synchronisé (lecture seule, même moteur de réconciliation que l'application, échec fermé si le manifeste est invalide), complétant l'épopée ADR-0008.
• Les journaux développeur assainis (garde-fou G37) caviardent désormais aussi les numéros d'assurance sociale à 9 chiffres sans séparateur, les numéros de téléphone sans séparateur et internationaux (+XX) ainsi que les formes avec parenthèses — tout en gardant lisibles les horodatages, numéros de version, numéros de dossier judiciaire et empreintes de commit.
• Rétablir les builds d'aperçu des PR sur Vercel — retrait de l'ignoreCommand lié au plafond de dépenses, maintenant que les limites ont été relevées (2026-07-10).

Version v7.95.93 (#2120)

• Dossier personnel d'auto-représentation (phase 1) — organisez votre propre chronologie, dépôts, communications et issues documentés en un dossier exportable DOCX/ZIP pour demander un examen; garde-fous structurels stricts (aucune donnée statistique, aucune conclusion visant un organisme nommé) selon l'ADR-0006 §9.

Version v7.95.68 (#0)

• Gouvernance interne — mise à jour des définitions des agents exécutifs avec leurs leçons auto-consignées (conformité, finances, juridique, produit), ajout d'un agent VP Marketing avec mandat de véracité publicitaire, et suivi du magasin de mémoire par agent.

Version v7.95.66 (#2105, #2107)

• Correction de l'échec de compilation en production par manque de mémoire qui bloquait tous les déploiements depuis le 2026-07-09 — la limite de tas utilise désormais la mémoire réelle du constructeur Vercel (6144 Mo sur 8 Go au lieu de 4096 Mo) et la consommation mémoire de webpack est réduite via webpackMemoryOptimizations de Next.js.

Version v7.95.61 (#2112)

• La vérification des citations canadiennes auprès de CanLII est corrigée pour utiliser l'API REST officielle (point d'accès caseBrowse et consultation directe des métadonnées de la décision) — une fois la clé d'API configurée, une citation neutre (p. ex. 2008 CSC 9) sera confirmée contre les métadonnées de CanLII avec un lien canonique cliquable, au lieu d'échouer silencieusement.

Version v7.95.60 (#1939)

• L'onglet Recherche comprend maintenant un parcours de recherche juridique guidé — décrivez votre problème en langage courant et obtenez les lois et articles applicables à partir d'un registre curé et vérifié (à commencer par les litiges de traite bancaire et la vente liée coercitive), chacun avec une source officielle cliquable, un statut de vérification et des liens de recherche CanLII pour la jurisprudence connexe. En l'absence de correspondance fiable dans le registre, vous êtes orienté vers une révision par un avocat plutôt que vers une supposition.

Version v7.95.35 (#2085)

• Moteur d'échéances — ajout d'une base de report « années » calculée par anniversaire calendaire exact (quantième à quantième; computation du délai selon l'art. 2879 C.c.Q.) et rebranchement de la prescription triennale de l'action personnelle (art. 2925 C.c.Q.) sur celle-ci, corrigeant le décalage d'un jour que l'approximation de 1095 jours produisait lors d'une année bissextile (p. ex. 2026-07-09 + 3 ans donne désormais 2029-07-09, et non 2029-07-08).

Version v7.95.30 (#2094)

• Le report des délais judiciaires québécois s'appuie désormais sur une table des jours fériés vérifiée à la source primaire (art. 61 Loi d'interprétation + art. 82 C.p.c.), corrigeant quatre jours non juridiques erronés ou manquants — la Journée nationale des patriotes, le 2 juillet (Fête du Canada reportée lorsque le 1er juillet tombe un dimanche) ainsi que les 26 décembre et 2 janvier — afin que les délais du C.p.c. échéant ces jours-là soient correctement prolongés au prochain jour ouvrable.

Version v7.95.25 (#2090)

• L'analyseur de sécurité des PR autonomes ne bloque plus à tort les changements de contenu juridique. Il ne signale désormais un identifiant que lorsqu'une ligne contient une vraie donnée secrète — un jeton de fournisseur connu (Stripe/GitHub/AWS, etc.) ou une affectation nommée comme un identifiant dont la valeur est réellement à haute entropie — au lieu de réagir au simple mot anglais « key » présent dans une loi, un mot-clé ou un identifiant de contenu. Les liens vers les sources législatives des gouvernements et tribunaux canadiens (canada.ca, *.gc.ca, *.gouv.qc.ca, CanLII) sont aussi reconnus comme des citations juridiques légitimes plutôt que comme des URL d'exfiltration externes.

Version v7.95.20 (#2093)

• L'espace de travail du dossier affiche maintenant un panneau en lecture seule « Historique des versions du dossier » — la version actuelle, ce qui la fait augmenter, et une liste en langage clair de chaque modification apportée au dossier depuis son ouverture dans cette session (parties, faits, pièces, témoins, documents et champs clés ajoutés, retirés ou modifiés).

Version v7.95.10 (#2087, #2088, #2089, #2091, #2092)

• Les cartes de la chronologie du dossier gardent désormais leurs détails par événement (signification/révision/pièce/fait/document) repliés par défaut derrière un bouton « Afficher les détails », et la pastille d'écart entre la date d'enregistrement et la date de l'événement explique au survol qu'un enregistrement peut précéder l'événement qu'il confirme.
• Un administrateur ne peut plus approuver ni refuser sa propre demande de vérification professionnelle (avocat/notaire/parajuriste) — un autre réviseur doit l'approuver, une règle appliquée dans la base de données afin de ne pouvoir être contournée.
• Les citations de lois dans la Recherche juridique pointent maintenant directement vers l'article précis sur LégisQuébec (p. ex. art. 2925 C.c.Q. → CCQ-1991 ?code=se:2925) plutôt que vers la page d'accueil du code.
• Les badges « enregistré/survenu » de la chronologie du dossier indiquent désormais les écarts de moins d'une minute en secondes (p. ex. « Enregistré 5 secondes plus tard ») au lieu d'arrondir tout petit écart à « 1 minute », et un écart infime de moins d'une seconde s'affiche comme « identique » — l'ampleur n'est donc jamais surestimée. Le sens (avant/après/identique) reste inchangé.
• Lorsque vous armez une échéance officielle, la boîte de confirmation affiche maintenant la mise en garde doctrinale de la règle (par exemple la note de prescription « 1095 jours correspondent approximativement à 3 ans ») et un lien « Source » qui ouvre l'article exact applicable, afin que vous puissiez lire la nuance et vérifier la source avant de confirmer.

Version v7.95.0

• Publication de la version v7.95.0.

Version v7.94.59 (#2007, #2086)

• Chaque page affiche maintenant un bouton persistant « Sortie rapide » — un clic remplace instantanément la page par un site neutre, sans boîte de confirmation, pour permettre à une personne en situation à risque de quitter rapidement.
• Le bouton « Sortie rapide » respecte désormais la taille minimale de cible tactile de 44px et ne chevauche plus la bannière d'édition sur les petits téléphones, ce qui le rend plus facile et plus sûr à toucher rapidement.

Version v7.94.54

• Publication de la version v7.94.54.

Version v7.94.29 (#2008)

• Ajout des conventions de nommage personnelles des dossiers (modes manuel/automatique/hybride, moteur de modèles, préréglages et mode confidentialité anonymisé) avec une nouvelle page Paramètres → Dossiers.

Version v7.94.4 (#1974)

• Le flux d'armement des délais officiels dispose enfin d'un contenu québécois réel — un premier recueil de règles amorce les délais procéduraux établis du C.p.c. (réponse à l'assignation, protocole de l'instance, appel) et la prescription triennale du C.c.Q., de sorte qu'un dossier peut enfin armer un délai officiel; d'autres règles en logement, travail, petites créances et avis municipal sont livrées à l'état d'ébauche en attente de la confirmation d'un juriste.

Version v7.93.79 (#412, #1928, #1933, #1942, #1994, #1996, #2002, #2022, #2034)

• La synchronisation vers un dossier se souvient maintenant du dossier choisi — sur Chromium elle garde la connexion d'une session à l'autre (en redemandant l'autorisation à votre retour) et revérifie le dossier chaque fois que vous revenez à l'onglet, en affichant un résumé révisable des changements sur le disque par rapport à l'application (sans jamais supprimer ni écraser en silence). Sur les autres navigateurs, l'export ZIP/dossier ponctuel reste en place.
• Une transaction complétée du marché suit désormais le cycle de vie d'objet Case-OS — elle devient un objet de service à part entière, est matérialisée comme nœud dans le graphe de preuve du dossier, et (lorsqu'un livrable est connu) émet l'unique DeliveryEvent partagé comme preuve de chaîne de possession; l'étape CRM HubSpot est livrée comme raccord inactif honnête qui s'abstient lorsqu'il n'est pas configuré au lieu de simuler un envoi, en attendant la revue des renseignements personnels (Loi 25).
• La publication de contenu juridique applique désormais la séparation des tâches — un directeur du contenu juridique nommé (distinct des administrateurs) doit approuver, les auteurs ne peuvent approuver leurs propres soumissions, et les délais de révision signalent les éléments en retard.
• L'entrevue guidée gagne une étape d'importation facultative — vous pouvez joindre un dossier, des fichiers ou une photo (mobile) des documents du dossier pendant sa création, afin qu'un dossier démarre déjà rempli plutôt que vide; passer l'étape ne change rien à la création manuelle, et les documents joints suivent le pipeline existant de téléversement, d'OCR et de classement une fois le dossier créé.
• La chronologie unifiée du dossier prend maintenant en charge le filtrage par type d'événement, état de vérification et plage de dates, avec un détail enrichi par type (méthode/historique de remise, verdict/attribution de révision, document source d'une pièce, références P d'un fait) et un indicateur honnête de l'écart survenu/enregistré.
• Chaque promesse des forfaits à paiement unique (Case Builder, Litigation Pro, Executive) correspond maintenant à une capacité réelle et livrée — six ont été confirmées comme réellement incluses et une ligne de l'offre Executive sans fondement (« Analyse des risques, issues et options ») a été corrigée pour refléter son véritable avantage de quotas illimités, afin que les forfaits n'annoncent plus rien que l'achat ne fournit pas.
• Le dépôt électronique auprès des tribunaux détermine désormais un fournisseur de services de dépôt électronique selon la juridiction et, lorsqu'aucun n'est configuré (le cas partout aujourd'hui), renvoie une réponse honnête « le dépôt électronique n'est pas encore offert dans votre juridiction » au lieu de l'ancien repli qui fabriquait un accusé de dépôt « soumis » pour un document qui n'a jamais atteint un tribunal. Un véritable adaptateur de fournisseur s'insère plus tard dans le même point d'ancrage sans modifier la route.

Version v7.93.9

• Publication de la version v7.93.9.

Version v7.92.79 (#1961, #1962, #1991, #2015, #2038)

• Votre mise en demeure affiche désormais où elle en est dans son cycle de vie — rédigée, transmise, reçue, en attente de réponse, répondue, ou délai écoulé sans réponse — ainsi que la prochaine étape à considérer, tirée directement de vos enregistrements de livraison et d'échéance pour ne jamais les contredire.
• L'en-tête « Projets enregistrés » devient le panneau « Dossier judiciaire assemblé » — une liste de complétude honnête (Parties/Faits/Chronologie/Pièces/Témoins/Communications/Dommages/Juridiction) et une ligne de provenance « Dernier assemblage · Version du dossier n° n » sur chaque document généré.
• Les deux catégories d'enquêteurs de la place de marché (« Enquêteurs en actifs » et « Détectives privés ») forment maintenant une seule catégorie structurée « 🕵️ Enquêtes et renseignement » avec neuf sous-catégories (détectives privés, enquêteurs en entreprise, spécialistes en criminalistique numérique, analystes en fraude, spécialistes en recouvrement d'actifs, enquêteurs en vérification d'antécédents, enquêteurs en soutien au litige, fournisseurs de surveillance, enquêteurs experts) — les fiches existantes continuent de fonctionner sous la nouvelle catégorie.
• Le centre de communication est maintenant l'UNIQUE endroit pour toute communication d'un dossier — l'ancien onglet autonome « Communications » (journal des interactions) est intégré comme volet 📝 Journal, les courriels s'ouvrent maintenant pour afficher l'historique complet de livraison et un lien cliquable vers la pièce justificative, et une barre de filtres commune (direction, date, partie, avec preuve) fonctionne sur les courriels, appels et correspondance.
• La vérification professionnelle confirme désormais que le type déclaré (avocat/notaire/parajuriste) correspond à l'accréditation — les types non concordants sont refusés à l'inscription face à une autorité émettrice connue, et le réviseur doit confirmer « le type correspond à l'accréditation » avant d'approuver.

Version v7.92.54

• Publication de la version v7.92.54.

Version v7.92.9 (#2003, #2010, #2012)

• Ajout d'un pipeline d'extraction documentaire à paliers (lib/intake/tiered) — la couche de confiance avant la mise à l'échelle des imports : extraction du texte natif au palier 1 (réelle), un raccord OCR de palier 2 avec un registre d'adaptateurs interchangeables (aucun fournisseur payant branché pour l'instant) et une couche de correction qui signale les segments peu fiables pour révision, avec une provenance par segment en ajout seul afin que l'extraction n'écrase jamais la preuve (ADR-0010).
• La barre de recherche de parcours tient maintenant compte de l'étape du dossier — depuis un dossier, la même recherche met en avant les prochaines étapes appropriées (p. ex. « rassembler des preuves et contacter directement » avant une tentative, « déposer une plainte à la CNESST/au TAT » après un échec), à partir de l'historique de tentative de résolution du dossier.

Version v7.91.84

• Publication de la version v7.91.84.

Version v7.91.79 (#2004)

• Le Centre de résolution affiche maintenant un panneau « Forum probable » une fois le type de problème et l'étape de tentative connus — des suggestions informatives (p. ex. un litige locatif pointant vers le Tribunal du logement, ou une réclamation de 50 000 $ pointant vers la Cour du Québec) tirées du répertoire des juridictions vérifié, avec une étape « confirmer le forum » pour choisir vous-même la cour/le district réel.

Version v7.91.54 (#2059)

• Les comptes administrateur et fondateur sont désormais illimités selon leur rôle — ils ne rencontrent plus les plafonds de dossiers/litiges/stockage du palier gratuit ni de mur de paiement pour une fonctionnalité, tant au niveau applicatif qu'au niveau de la base de données.

Version v7.91.49 (#0, #2010)

• L'entrevue guidée demande maintenant « Avez-vous déjà tenté de résoudre ce problème? » juste après la question juridique — la réponse fixe l'étape du cycle de vie du dossier et, si une tentative a déjà eu lieu, en enregistre les détails pour que la prochaine étape suggérée en tienne compte.
• Corrige l'échec de la compilation de production causé par un dépassement de mémoire JavaScript en portant la limite de mémoire de la compilation Next.js à 4 Go.

Version v7.91.44

• Publication de la version v7.91.44.

Version v7.91.19 (#2022)

• Nouvel onglet Chronologie du dossier — une vue chronologique unifiée et en lecture seule de chaque fait, signification, pièce et révision d'avocat, montrant pour chaque entrée la date de l'événement et la date d'enregistrement, reliée à sa preuve.

Version v7.90.94 (#1978, #2028)

• Poursuite du balayage systémique de l'INP (#1978, phase 3) — mémoïsation des composants de ligne/carte dans les onglets Enquête, Classification, Actes de procédure et Dépôts au greffe afin qu'une modification d'un élément ne re-rende plus tous les autres éléments de la liste.
• Révision terminologique juridique des résumés d'amendements constitutionnels américains (US_RIGHTS de HomeLanding) — correction d'un faux ami en portugais et alignement des formulations chinoise et hébraïque sur les termes doctrinaux reconnus pour pt/zh/he; ar/pa/de/it confirmés à l'aide de sources.

Version v7.90.89 (#2012, #2042)

• Ajout d'une barre de recherche par intention au Centre de résolution — décrivez votre problème en langage clair (ou choisissez une catégorie) pour trouver le bon parcours pré-litige parmi les 13 types de différends, avec un « pourquoi » visible pour chaque résultat.
• Traduction des 67 chaînes à couverture linguistique incomplète accumulées dans ReviewPackage.tsx, ReviewPackageActions.tsx, DocumentWorkflowCard.tsx et InvestigationObjectivesSection.tsx vers l'ensemble des 10 langues, comblant la dette signalée par #2027 et corrigeant la régression active du cliquet de DocumentWorkflowCard.tsx.

Version v7.90.84

• i18n: translate the accumulated 67 locale-incomplete literals (#2042, code half) (#2052).

Version v7.90.59 (#1874, #2004)

• Correction des tests espagnols de la suite E2E Momentic pour refléter le repli documenté (le contenu principal revient à l'anglais avec la bannière de traduction automatique sur les pages sans surcouche espagnole) et réparation du script lint:momentic défaillant avec une version de CLI épinglée à source unique.
• Nouveau répertoire maître des juridictions (27 cours/tribunaux/régulateurs du Québec, sourcés et étiquetés par provenance) avec un sélecteur guidé Province → District → Institution → Section dans l'assistant d'ouverture de dossier.

Version v7.90.34

• Publication de la version v7.90.34.

Version v7.90.29 (#2015)

• Ajout du centre de communications unifié (tranche 1) — un seul onglet avec sous-vues pour les messages internes, les courriels, les appels/messages vocaux et la correspondance, projetés en lecture seule à partir des données existantes du dossier.

Version v7.90.4 (#2044)

• Les fils de messages internes aux dossiers sont désormais créés de façon atomique — une contrainte d'unicité au niveau de la base de données élimine la dernière fenêtre où deux personnes répondant au même instant pouvaient scinder une conversation en deux fils.

Version v7.89.99 (#2033)

• Verrouillage des fonctionnalités accordées par SKU sur leurs surfaces réelles — la Salle de guerre, le Registre des pièces, le Centre de commande et les outils de pratique se verrouillent désormais derrière un appel à mise à niveau dans l'espace de travail, et la route d'extraction IA et la priorité des billets de soutien vérifient la même capacité résolue côté serveur, bouclant ainsi l'accès réel et appliqué du paiement au produit.

Version v7.89.89 (#2001)

• Correction d'un blocage de plusieurs secondes dans les champs « Fait prouvé » / « Récit » de la chronologie — une longue modification assistée par l'IA ne bloque plus la saisie.

Version v7.89.84 (#1876, #1898)

• Ajout de tests de non-régression pour les vrais noms d'expéditeurs dans Messages, le chargement borné des messages et l'atténuation de la course à la création de fil.

Version v7.89.79 (#2027)

• Traduction des 19 chaînes à couverture linguistique incomplète d'AssistedCheck.tsx (étiquettes, erreurs, catégories de signalement) vers l'ensemble des 10 langues, comblant l'écart laissé absorbé-mais-non-traduit par #1990 dans le cliquet i18n-localizedtext.

Version v7.89.74 (#1873)

• Correction du panneau Échéances qui pouvait afficher un « Prochain rappel » déjà passé — il choisit désormais toujours le prochain palier de rappel FUTUR, ou affiche un indicateur de retard lorsque tous les paliers non consignés sont déjà écoulés; correction également de deux commentaires pointant encore vers la migration renommée 0158→0159.

Version v7.89.69 (#2016)

• Le lien « Faire signifier par huissier » transmet maintenant le dossier au formulaire de service, afin qu'une demande de signification par huissier puisse être liée à votre dossier et à sa preuve de signification.

Version v7.89.68 (#2020)

• Les notaires vérifiés reçoivent désormais une véritable attribution professionnelle lors d'une révision, au lieu d'être limités à une mention personnelle ou « au nom de ».

Version v7.89.63 (#1899)

• Ajout de l'interface d'administration pour le pipeline de dossier de surveillance Justice Analytics™ (indice de disparité P2 → profil d'entité P3 → dossier de surveillance P4) — auparavant, la route `POST /api/admin/justice-analytics/review-package` (#1858) n'avait aucun formulaire, obligeant à composer manuellement le JSON de la requête. Le nouveau panneau sur `/admin/justice-analytics` affiche les champs d'entité, d'organisme de surveillance et de cohorte par dimension, ainsi que le cadrage, les constats et le texte de soumission générés par l'API, avec des états réels de chargement/accès refusé/backend désactivé/erreur et aucune donnée fabriquée.

Version v7.89.53 (#2009)

• Correction de la liste des districts judiciaires du Québec à 36 districts légaux (au lieu de 38) : les noms de villes chefs-lieux « Gatineau »/« Saguenay » sont désormais une table d'alias qui se résout toujours vers Hull/Chicoutimi lors de l'extraction des documents.

Version v7.89.52 (#0)

• Les étapes du parcours de résolution suivent maintenant le cycle de vie complet — Rédaction en cours, En révision et Approuvé pour envoi avant la soumission, plus un état distinct Accusé de réception reçu avec sa propre date, puisque c'est la confirmation de réception (et non la date d'envoi) qui déclenche les délais de réponse réglementaires comme le délai de 60 jours de l'AMF.

Version v7.89.42 (#1991, #2031)

• Lancement de la page d'accueil du Pôle Enquêtes (/investigations) — une prise en charge réelle et payante de frais de coordination pour cinq objectifs d'enquête (repérage d'actifs, localisation de personne, renseignement corporatif, fraude, soutien au litige), avec un état honnête « bientôt disponible » pour devenir enquêteur et aucune allégation de moteur de jumelage ou de réputation sur la page.
• Les achats ponctuels (Case Builder, Litigation Pro, Executive) débloquent désormais de vraies capacités et un quota réel via un résolveur d'entitlements unique, bouclant la boucle de revenus du paiement à l'accès produit.

Version v7.89.32

• Publication de la version v7.89.32.

Version v7.89.7 (#1971, #1999)

• Ajout d'un générateur gratuit de trousse « Impression et envoi postal » dans l'onglet Export — une véritable lettre d'accompagnement, une enveloppe et une étiquette d'expédition, un guide non prescriptif des classes d'envoi, ainsi qu'une saisie du suivi et de la confirmation de livraison qui crée automatiquement la pièce de preuve (#1968) une fois la livraison confirmée.
• L'import massif répare maintenant automatiquement un échec d'enregistrement dans le nuage (rafraîchissement de session + resynchronisation, un seul essai) avec trois messages distincts, garde la session active pour les imports de plusieurs heures, et permet de ne réessayer que les fichiers en échec.

Version v7.88.82

• feat: add free Print & Mail package generator (#1971) (#2026).

Version v7.88.77 (#1969)

• Le panneau Échéances signale maintenant une livraison confirmée dont le délai de réponse est écoulé sans réponse et propose les prochaines étapes du parcours de résolution du dossier, à titre informatif seulement.

Version v7.88.67 (#1962)

• Les documents s'appuient désormais sur un registre de pièces versionné et persistant, et deviennent figés (avec traçabilité) une fois signifiés, déposés ou archivés — rouvrir un document déposé pour le modifier crée une nouvelle version au lieu de le modifier silencieusement.

Version v7.88.57 (#2000)

• Correction d'un bogue d'extraction de dates qui interprétait silencieusement des dates américaines M/J/AA (et les horodatages de pied de page d'impression Gmail) en J/M/AA, créant de faux faits futurs dans la chronologie; les dates ambiguës sont désormais signalées pour révision et les faits datés dans le futur sont automatiquement marqués « à vérifier ».

Version v7.88.52 (#1978)

• Réduction du coût de rendu (INP) des onglets journal, engagements, registre des pièces et preuves de l'espace de travail, par la mémoïsation des composants de ligne et la stabilisation de leurs fonctions de rappel.

Version v7.88.47 (#1972)

• Dossier de révision structuré (résumé du dossier + document + pièces liées + chronologie) avec verdicts Approuver / Demander des modifications / Rejeter — étiquetés honnêtement comme signature d'un professionnel vérifié par la plateforme ou « consignée au nom de », jamais fabriquée.

Version v7.88.22 (#1967, #1970)

• Les documents peuvent désormais être transmis par courriel avec preuve — la plateforme hache le fichier joint exact, l'envoie, puis archive automatiquement la transmission comme pièce prête pour le tribunal. Désactivé avec un message honnête sur les instances sans fournisseur de courriel configuré.
• Les demandes de signification par huissier prennent désormais en charge la jointure réelle de documents (analysés), une estimation figée et le suivi de signification lié au dossier lorsqu'un dossier est fourni.

Version v7.88.12

• feat(service): bailiff context carryover + scan-gated document upload (#1970) (#2013).

Version v7.87.87 (#1998)

• Les citations juridiques portent désormais une chaîne de provenance auditable (source officielle versionnée, date de version, dernière vérification) — la liste « Fondements à vérifier » du panneau Keep the Date affiche un statut vérifié/en attente/manquant/invalide par citation plutôt qu'une simple mention non vérifiable.

Version v7.87.62 (#1942)

• Le suffixe « (autre filière) » du sélecteur de statut de procédure — un jargon interne — devient « (votre statut actuel) », indiquant clairement que l'option marquée est le statut réel présentement sélectionné de la procédure.

Version v7.87.61 (#2005)

• Le bouton « Nouveau dossier » devient l'action principale verte (« Nouveau dossier juridique ») — contraste élevé, cible tactile de 44 px — rendant le point d'entrée principal visuellement dominant.

Version v7.87.60 (#1898, #1921)

• Les collaborateurs d'un dossier voient désormais qui y a accès, avec des noms réels ou courriels masqués dans Messages — fini les listes vides et les identifiants bruts.

Version v7.87.55 (#1992)

• Enregistrement de juge.ca pour Apple Pay — le fichier d'association de domaine Stripe est désormais servi sous /.well-known/, corrigeant la feuille de paiement Apple Pay illisible signalée sur iOS lors du paiement.

Version v7.87.54 (#1966)

• Ajout de la « Vérification assistée » — une analyse IA d'un brouillon terminé qui signale des observations informationnelles (complétude, ton, structure, citations, lisibilité), jamais un verdict sur la validité juridique.

Version v7.87.44 (#1978)

• Renforcement de performance (phase 1 d'un chantier en plusieurs parties) — la fonction de sauvegarde centrale de l'espace de travail est désormais stable au lieu d'être reconstruite à chaque frappe, et les onglets Procédures et Parties ne redessinent plus que la ligne réellement modifiée au lieu de toute la liste.

Version v7.87.39 (#1981, #1982)

• Le moteur d'échéances applique désormais le report de l'art. 83 C.p.c. (une échéance tombant un samedi, dimanche ou jour férié au Québec est reportée au prochain jour juridique) et chaque règle peut porter une source de citation cliquable, affichée en lien lors de l'armement d'une échéance.

Version v7.87.34 (#1969)

• Le dossier dispose désormais d'un registre unique et audité de chaque tentative de signification (courriel, huissier, poste recommandée) — lié au hachage exact de l'artefact signifié, prêt à ancrer une échéance judiciaire sur la date de livraison confirmée.

Version v7.87.24 (#1958, #1960)

• Promotion de « citation à comparaître » et « avis de présentation » du palier JAUNE par défaut au palier ROUGE explicite dans le registre de classification, à la suite du suivi doctrinal de Julien (conséquences coercitives/de délai — art. 279-282, 146, 761 C.p.c.).

Version v7.87.23 (#1965)

• Les documents affichent maintenant un statut de révision/approbation (Brouillon, En révision, Approuvé) avec une distinction claire entre auto-révision et révision professionnelle, pour toujours savoir si un brouillon est prêt à envoyer.

Version v7.87.13 (#1968)

• Les modes de signification (courriel, huissier, poste) peuvent désormais déposer automatiquement une pièce dès la confirmation de livraison, sans risque de doublon ou de numéro en collision.

Version v7.87.3 (#1961)

• Un document de résolution généré affiche désormais une carte « que voulez-vous faire ensuite ? » — télécharger le dossier complet, programmer un rappel de suivi, commander une signification par huissier ou inviter un collaborateur à le réviser.

Version v7.86.78 (#1947)

• L'importation de documents indique désormais la source d'une date de dépôt (en-tête de courriel / texte du document / métadonnées du fichier / date d'importation) et propose les dates candidates détectées; les fichiers ignorés sont listés par nom et raison plutôt qu'un simple compte; les fichiers bureautiques (xlsx, pptx, csv, ods, odp, rtf) sont désormais stockés comme preuve sans extraction de texte plutôt qu'abandonnés.

Version v7.86.73 (#1963)

• Correction d'un problème de performance de la grille chronologique où la modification, la suggestion IA, la validation ou la contestation d'un fait redessinait toutes les lignes au lieu de la seule ligne modifiée (jusqu'à ~400 ms de délai sur les longues chronologies).

Version v7.86.68 (#1962)

• La liste des pièces, la déclaration sous serment et la demande introductive d'instance s'assemblent maintenant à partir de tout le dossier (pièces + documents de preuve + chronologie); un dossier avec de la preuve réelle n'affiche plus jamais « (aucune pièce) ».

Version v7.86.58 (#1950, #1964)

• Import massif (Phase A) : import en lot résumable, journalisé, pour les dossiers de 35 000 fichiers et plus — enregistrement immédiat, déduplication sha256, traitement par lots avec contre-pression, et enrichissement différé en arrière-plan.
• Correction d'un gel de 4,7 s à la fermeture de l'aperçu d'un document sur les dossiers volumineux — la fermeture ne re-génère plus toute la liste des preuves.

Version v7.86.53

• Publication de la version v7.86.53.

Version v7.86.43 (#1948)

• La classification des documents est désormais hiérarchisée par risque — les étiquettes procédurales comme jugement/ordonnance, saisie et transcription ne peuvent plus jamais s'appliquer automatiquement, exigent une confirmation explicite avec vérification de marqueurs structurels, et l'application en lot ouvre maintenant un aperçu révisable au lieu de modifier des dizaines de dossiers en un clic.

Version v7.86.18 (#1946)

• Les références de dossier pouvaient s'afficher avec un remplissage de zéros différent selon l'écran (p. ex. « M-2026-0016 » dans l'assistant d'import contre « M-2026-016 » sur les badges de documents) pour le même dossier, avec risque d'association de fichiers au mauvais dossier. Chaque dossier porte désormais une référence canonique unique stockée et affichée telle quelle partout; les dossiers existants s'auto-corrigent au chargement, et une collision de références entre deux dossiers distincts produit un avertissement visible au lieu d'une fusion silencieuse.

Version v7.86.13 (#1945)

• Correction des noms de parties tronqués à 2 caractères dans la revue d'import pour les documents numérisés/photographiés, et arrêt de l'attribution automatique d'un rôle de partie — chaque rôle suggéré exige désormais une confirmation explicite de l'utilisateur avant la création d'une fiche Partie.

Version v7.86.8 (#1955)

• Correction du texte trop pâle dans les aperçus imprimables des cahiers et du dossier d'audience — les cartes blanches « papier de cour » héritaient des couleurs de texte du thème sombre; le texte des documents s'affiche désormais en encre foncée lisible, et les indicateurs de section vide gagnent en contraste.

Version v7.86.7 (#1938)

• Les actions IA de la chronologie ne restent plus bloquées sur « accès refusé » pour un dossier pas encore synchronisé au nuage — l'application se resynchronise et réessaie une fois, ou explique la marche à suivre.

Version v7.86.6 (#1934)

• Nouveau parcours « Recouvrement urgent après un acte criminel » (saisie avant jugement, volets parallèles dédommagement criminel et IVAC) — première variante d'urgence du moteur de résolution.

Version v7.85.81 (#1941)

• Correction d'un problème de performance de l'espace de travail : la saisie dans les champs d'un dossier (notes, résumés, communications) pouvait brièvement figer la page, chaque frappe réenregistrant tout le dossier.

Version v7.85.80 (#1937)

• Les rôles des participants couvrent désormais toute la taxonomie québécoise des parties — Parties, Représentants, Preuve, Acteurs judiciaires et Autres (21 rôles au total), regroupés dans le sélecteur au lieu de tout réduire à « Autre ».

Version v7.85.79 (#1916)

• Le panneau de l'espace de travail démarre désormais réduit pour les nouveaux comptes sans dossier (il se déploie automatiquement dès la création du premier dossier) au lieu d'afficher des dizaines d'éléments désactivés dès la première visite.

Version v7.85.74 (#1932)

• Ajout de « Synchroniser vers un dossier » et « Importer depuis un dossier » dans l'onglet Export — matérialisez un dossier sur votre propre disque dur (écriture en direct sur Chrome/Edge, repli ZIP ailleurs) et réimportez manuellement les fichiers bruts, avec une validation stricte du manifeste (échec fermé) et un résumé complet de la synchronisation.

Version v7.85.49 (#1877, #1906)

• Alerte désormais les opérateurs en cas d'échec d'écriture d'un droit SKU ponctuel, corrigé la double appellation de champ des erreurs de dépôt, unifié les classes d'erreur EFSP dupliquées, corrigé une course d'état « occupé » dans la file éditoriale, et complété la documentation des intégrations Axis-2 pour couvrir les 34 portes — un lot de correctifs mineurs vérifiés issus de la revue automatisée.

Version v7.85.44 (#1927)

• Importez maintenant un dossier complet de votre disque dur — les sous-dossiers et leurs fichiers arrivent ensemble, organisés dans la bibliothèque de preuves selon votre propre classement, avec un inventaire d'importation indiquant précisément ce qui a été reçu.

Version v7.85.19 (#1925)

• Correction du blocage des générateurs de documents de l'onglet Résolution (lettre de plainte, lettre de suivi, soumission à l'ombudsman, plainte réglementaire, proposition de règlement, historique des tentatives) — un clic génère maintenant le projet à partir du dossier et l'ouvre directement dans l'éditeur de l'onglet Documents.

Version v7.85.14 (#1897)

• Sélecteur de statut des procédures : le sélecteur guidé à 30 statuts est maintenant masqué derrière une action explicite « Mettre à jour le statut », afin qu'un justiciable non représenté ne voie par défaut que le badge de statut et la phase.

Version v7.85.9 (#1891)

• Récupération après décalage de version post-déploiement — une erreur de bloc obsolète après un déploiement relance automatiquement la page une fois, au lieu de rester bloquée sur l'écran d'erreur.

Version v7.85.4 (#1894)

• Durcissement des quatre routes de paiement (service, billing, ops, copilot) afin de ne jamais renvoyer publiquement le texte d'erreur brut du fournisseur de paiement — un test E2E en production a détecté un message contenant la forme d'une clé Stripe renvoyé tel quel. Les détails sont désormais journalisés côté serveur uniquement; les clients reçoivent un message générique invitant à réessayer.

Version v7.84.99 (#1887)

• Case Builder (495 $), Litigation Pro (1 495 $) et Executive (4 995 $) sont désormais de vrais achats uniques sur la page de tarification, avec prix côté serveur, comptes Stripe par édition et un registre d'accès réservé à l'acheteur.

Version v7.84.74 (#1909)

• La vue portefeuille pré-dossier partage désormais le même panneau latéral persistant que l'espace de travail — les sections du dossier et des phases sont visibles mais estompées avec une indication « ouvrez un dossier pour les utiliser », et une entrée Accueil en surbrillance indique où vous êtes, pour qu'ouvrir un dossier ressemble à une seule application continue plutôt qu'à deux.

Version v7.84.69 (#1904)

• Correction du sélecteur de statut des procédures qui perdait le statut courant (et faisait disparaître le dossier de signification/dépôt) lors d'un changement du drapeau « plaidée » ou du statut de suspens — les deux restent désormais toujours visibles.

Version v7.84.64 (#1907)

• Les cahiers d'audience et le guide d'assemblage s'affichent maintenant comme de vrais documents imprimables (et non des téléchargements .md bruts), l'onglet Export affiche un avis honnête « ajoutez d'abord des pièces/faits » sur un dossier trop mince plutôt qu'un cahier presque vide, générer le cahier d'audience fait maintenant défiler et surligner visiblement le résultat, et les ensembles de documents (p. ex. la trousse pour l'avocat) conservent maintenant leur type de document correct.

Version v7.84.59 (#1903)

• Correction d'une anomalie de statut de dépôt où un dépôt électronique simulé (non en direct) pouvait paraître identique à un dépôt réel; l'espace de travail affiche désormais un avis distinct et sans équivoque de « simulation seulement » lorsqu'un dépôt n'a pas réellement été transmis à un tribunal.

Version v7.84.54 (#1896)

• Remplacement, dans l'espace de travail client, du menu d'onglets horizontal et du menu déroulant « Plus » par un panneau latéral persistant et réductible (bureau) — le registre des pièces et les témoins sont désormais épinglés aux côtés de la chronologie, de la preuve et des échéances, et les sections Bâtir/Résoudre/Cour/Exécuter restent toujours visibles plutôt que masquées selon l'étape du dossier.

Version v7.84.49 (#412, #426, #1870)

• L'action de dépôt de l'espace de travail appelle maintenant la véritable route de dépôt électronique renforcée (idempotence + audit + erreurs structurées) au lieu d'une simulation côté client — le mode hors ligne/local conserve son outil de test simulé, et chaque résultat (succès, validation, pas encore activé, session, réseau) affiche un message réel et honnête.

Version v7.84.39 (#1871)

• La file éditoriale d'administration affiche désormais un avis clair lorsqu'une publication est bloquée par la barrière de conformité de révision juridique, au lieu de revenir silencieusement en arrière sans explication.

Version v7.84.34 (#1861)

• Ajout d'une porte d'authentification côté serveur au gabarit de l'espace de travail /app — le point de contrôle unique pour toutes les routes /app/* (espace de travail, professionnel, client, paramètres et routes sœurs). Les visiteurs non authentifiés sont désormais redirigés vers la connexion au lieu d'afficher l'interface de l'espace de travail; auparavant, l'isolation des données reposait uniquement sur la sécurité au niveau des lignes (RLS) de l'API. L'aperçu local sans backend Supabase continue de passer afin de ne pas bloquer le développement.

Version v7.84.29 (#0)

• Paiement des forfaits : une session Stripe annulée revient maintenant vers la page Tarifs avec un message clair « aucun montant débité — réessayez » au lieu d'une impasse silencieuse; ajout de docs/BUYABLE_PATH_MAP.md répertoriant le statut de paiement de chaque offre commercialisée.

Version v7.84.24 (#0)

• Ajout de la messagerie interne au dossier — les collaborateurs d'un même dossier peuvent désormais rédiger, envoyer et lire des messages directement dans l'espace de travail, sans courriel externe.

Version v7.83.99 (#1872)

• Correction de la protection anti-abus de l'essai de 14 jours qui échouait en mode ouvert, et transmission de la langue de l'utilisateur à Stripe Checkout afin de garantir des conditions contractuelles en français (fr-CA) au paiement pour les sessions québécoises (formation du contrat, LPC — révision de conformité #1883) — avec le schéma d'abonnements en production, un client qui annule puis se réabonne possède plusieurs lignes; l'ancienne requête à ligne unique échouait sans vérification et accordait un nouvel essai. La requête tolère désormais tout nombre de lignes et toute erreur échoue en mode fermé (pas d'essai; le client de retour est simplement facturé normalement).

Version v7.83.94 (#1868)

• Les procédures d'un dossier affichent maintenant un statut de flux de travail détaillé et validé juridiquement (planification → préparation → révision → exécution → après exécution, plus suspens), séparées clairement entre « au dossier » et « en préparation », avec une note de non-conseil juridique lors de la consignation d'un dépôt ou d'une notification.

Version v7.83.69 (#70, #1717, #1852)

• Application de la porte de validation §7.3 (approbation du directeur du contenu juridique) dans le pipeline de soumissions de recherche. La route d'examen admin refuse désormais de faire passer une soumission à « approuvé » ou « publié » sans l'approbation legal_review lorsque LEGAL_CONTENT_REVIEW_REQUIRED est activé — comblant l'écart où l'indicateur de disponibilité legalContentPipeline signalait une porte de validation active que rien n'appliquait réellement. Les tentatives de publication bloquées sont auditées.
• Les rappels d'échéances sont désormais prouvés de bout en bout et laissent toujours une trace visible dans l'application, même sans courriel ni SMS configurés.

Version v7.83.64

• Publication de la version v7.83.64.

Version v7.83.54 (#0, #412, #426, #1644, #1646, #1703)

• Mur chronologique — ajout du bouton compagnon « Contester » sur les lignes de la chronologie; un fait signalé fait maintenant basculer son badge de statut vers « Conflit » (indépendamment des conflits de dates auto-détectés), complétant les critères d'acceptation du #1646 (le bouton de génération IA du récit, l'action Valider et l'édition de la source avaient déjà été livrés dans des tranches antérieures de l'épopée #1644).
• Le moteur d'équité/disparité Justice Analytics™ est désormais accessible via une nouvelle surface de surveillance réservée aux administrateurs (vue agrégée anonymisée par k-anonymat + génération de dossiers de révision), ce qui clôt l'épopée #1703.
• Les dépôts de cour sont désormais protégés contre les doublons et audités de bout en bout — un dépôt soumis à nouveau ou en double n'atteint le fournisseur de dépôt électronique (bac à sable/simulé) qu'une seule fois, chaque tentative est consignée dans le journal d'audit, et un échec temporaire du fournisseur libère la nouvelle tentative en toute sécurité.
• Correction des inscriptions accès anticipé/liste d'attente/infolettre — la table newsletter_signups utilisée par la route /api/newsletter n'avait jamais été créée par une migration, chaque inscription échouait donc avec une erreur 500 et était perdue; ajout de la migration 0158 (table + RLS réservée au rôle de service) et passage de la métrique « inscriptions infolettre » du centre de commandement à une tendance de portée jour/semaine/mois/total.
• Ajout d'une bibliothèque de tests E2E Momentic couvrant la surface publique (200 tests en langage naturel : smoke, contenu, place de marché, experts, verticales, conformité, i18n, RTL et accessibilité) avec des scripts npm par suite et une porte de lint.
• Ajout d'un essai gratuit de 14 jours sur les forfaits Pro et Premium — carte enregistrée dès le départ, conversion automatique en abonnement payant au 14e jour. Réservé aux nouveaux clients (aucun second essai pour un abonné de retour), appliqué par une porte d'essai pure (lib/billing/trial.ts) intégrée au paiement d'abonnement; les droits comptent déjà les abonnements en essai, donc aucune migration n'est requise. Les forfaits « Pratique du syndic » (trustee-practice) et professionnel sont volontairement exclus en attendant la validation de conformité.

Version v7.83.44

• Publication de la version v7.83.44.

Version v7.83.19 (#0)

• Correction du 404 de connexion admin — /admin/login (et /<locale>/admin/login) redirigent désormais vers la vraie page de connexion avec retour vers /admin, au lieu d'aboutir à un 404 pour quiconque essaie l'URL intuitive de connexion admin.

Version v7.83.14 (#1703, #1711)

• Ajout de Justice Analytics P4 — le générateur de dossiers de révision qui assemble les constats de disparité encadrés en une soumission à un organe de surveillance (cadrage neutre fixe, avis de non-détermination, méthodologie + confiance), jamais publié et jamais soumissible sur un résultat nul.

Version v7.83.4 (#68, #1462, #1644, #1653, #1809)

• Réalisation de la revue d'exactitude juridique des récits de chronologie générés par l'IA — sûrs du point de vue UPL par conception (l'invite interdit conclusions/avis/prédictions juridiques), sous conditions exigeant l'avis de contenu IA et un cadrage « Valider » non certifiant sur l'interface du justiciable.
• Ajout de l'outillage de migration des utilisateurs — inventaire en lecture seule, classification prudente réel/test, et un export HubSpot qui consigne chaque export dans la chaîne d'audit inviolable (fail-closed) — avec un guide de séquence sécuritaire en 5 étapes.

Version v7.82.74 (#1703, #1704, #1706, #1710, #1805)

• Ajout de Justice Analytics P3 — profils d'entités nommées sûrs contre la diffamation qui ne présentent que des constats de disparité encadrés au moyen d'un libellé de sauvegarde fixe (jamais de prose conclusive), verrouillés à un usage de révision par les instances de surveillance avec divulgation méthodologique obligatoire.
• Compte rendu de la session du 2026-07-06 (pipeline de changesets + clôture de conformité).

Version v7.82.64 (#1674, #1679)

• Résolution des questions ouvertes de la phase 0 de la visite guidée — conserver la structure en 5 temps, persistance localStorage pour la v1, ouverture selon le défilement/intention (pas à chaque visite), silencieux par défaut; le texte juridique de la démo est acheminé à la conformité.

Version v7.82.59 (#1644, #1652)

• Réalisation de la revue Loi 25 de ai_fact_feedback — la table livrée ne contient que des métadonnées (aucun texte brut des faits), avec suppression en cascade par dossier/auteur et RLS d'accès au dossier; le stockage de texte brut demeure interdit en attendant une évaluation distincte.

Version v7.82.54 (#1703, #1709)

• Ajout du moteur d'équité de Justice Analytics — un indice de disparité pur et encadré par la méthodologie qui calcule la disparité résiduelle après contrôles, un intervalle de confiance bilatéral et un indicateur de publiabilité selon N-minimum/confiance (les écarts bruts qui s'expliquent après contrôles ne sont pas publiables).

Version v7.82.44 (#1816)

• Correction du registre d'export des personnes concernées (Loi 25) — matter_shares est désormais exporté (partageur + destinataire), les tables de jonction d'autorisation de partage sont classées, et marketplace_engagements exporte son lien matter_id.

Version v7.82.43 (#68, #1462, #1834)

• Ajout de l'évaluation des facteurs relatifs à la vie privée (Loi 25) pour l'export d'utilisateurs vers HubSpot, inscription de la DPA HubSpot au registre des sous-traitants, et publication d'une divulgation du traitement CRM HubSpot sur les pages de confidentialité (en/fr/es).

Version v7.82.38 (#1462, #1832)

• Le script admin delete-user consigne désormais chaque suppression dans la chaîne d'audit inviolable (fail-closed), supprime de façon atomique, refuse de retirer des utilisateurs qui possèdent des dossiers, et exige une phrase de confirmation saisie.

Version v7.82.33 (#1629, #1829)

• check-version-advances ignore désormais la règle d'avancement strict pour les PR à changeset, afin qu'une PR qui dépose changes/*.md (au lieu de bumper à la main) passe la vérification CI requise.

Version v7.82.28 (#1629)

• Ajout d'un outillage de versionnage par « changesets » (changes/ + scripts changeset/check-changeset/apply-changesets) pour que les PR cessent d'entrer en conflit sur les fichiers de version et de changelog, avec une proposition de file d'attente de fusion — le correctif du bruit de versions lors des fusions concurrentes.

Version v7.82.23

• Publication de la version v7.82.23.

La tâche de publication s'authentifie via RELEASE_TOKEN pour pousser malgré la protection de branche (#1629)

• La tâche auto-version-bump récupère désormais le dépôt avec un RELEASE_TOKEN administrateur, ce qui lui permet de pousser le commit chore(release) sur la branche main protégée (le bot github-actions était refusé par les vérifications d'état requises) — le pipeline de publication par changesets est maintenant débloqué de bout en bout.

Le versionnage des publications repose désormais sur les changesets : auto-version-bump appelle apply-changesets (#1629)

• Le flux de publication matérialise maintenant la version, le journal des modifications bilingue et package-lock à partir des changesets changes/*.md à la fusion, mettant fin à la valse de versions concurrentes qui faisait entrer les PR en conflit sur les fichiers de version et de journal.

Durcissement de l'outil de changesets : mise à jour de version de package-lock.json + garde anti-dérive du fichier de verrouillage (#1826)

• apply-changesets.ts met désormais à jour les champs de version de package-lock.json en même temps que package.json, afin que le flux de changesets du #1629 se déploie sans dérive du fichier de verrouillage.
• La gouvernance de version vérifie maintenant que package-lock.json correspond à lib/version.ts, détectant la dérive signalée par Devin sur le #1824.

Garde-fous de conformité : porte de révision par avocat de la filière insolvabilité + interdiction permanente des honoraires de référence (#1427)

• Ajout des deux garde-fous de conformité de la filière insolvabilité. La porte de révision par avocat maintient VERROUILLÉE toute surface destinée aux professionnels (syndics/faillite) jusqu'à ce que les artefacts de révision juridique des filières CA et US soient consignés comme complets et approuvés — un agent ne peut pas la déverrouiller. Le garde-fou des honoraires interdit de façon permanente les honoraires de référence, le paiement pour placement, la tarification par prospect/par dossier/à honoraires conditionnels et la publicité financée par les syndics dans la filière insolvabilité (art. 49 LFI pour le Canada ; règles 5.4/7.2(b) pour les États-Unis) — une contrainte structurelle et non contournable, couverte par des tests unitaires. Aucune surface réglementée n'est activée par ce changement : il ajoute uniquement l'application qui garde la filière fermée jusqu'à l'approbation d'un avocat.

Docs : registres de gouvernance conservés — approbation du directeur du contenu juridique + note sur la propriété des migrations Supabase (#1823)

• Consignation de deux documents de gouvernance/exploitation dans le dépôt : l approbation et l acceptation du risque du directeur du contenu juridique (2026-07-02) pour le contenu QC/CA/US, et la note opérationnelle expliquant pourquoi l intégration de migration GitHub de Supabase doit rester désactivée (elle entre en conflit avec le lanceur de migrations au moment du build). Documentation uniquement — aucun changement d exécution.

M4 Requêtes arrive : une seule théorie de la cause par dossier, des trousses de requête en 8 parties et le projet de jugement rédigé en premier — la couche de sortie du moteur de litige (+25, newStandaloneTool)

• Le dernier module non commencé de la phase 1 est livré. Un nouvel onglet Requêtes porte l'unique théorie de la cause structurée du dossier — ce qui s'est passé, pourquoi c'est illégal, qui est responsable, le préjudice, le remède — et la base de données refuse une deuxième. Chaque requête s'assemble selon la trousse en 8 parties de la feuille de route (procédure, avis, affidavit, autorités tirées de la banque d'autorités, pièces tirées du registre R-n, projet de jugement, preuve de signification, version déposée), en référençant les faits de la chronologie et les aveux par leurs numéros ¶ émis par registre — l'argumentation référence la preuve, elle ne la copie jamais. Les invariants vivent dans le schéma, pas dans le texte : une trousse ne peut pas quitter le brouillon sans projet de jugement (contrainte CHECK), le test de concentration d'une page conditionne la préparation côté client, l'échelle de statuts ne saute jamais d'échelon, et une trousse déposée est gelée par déclencheur — un acte de cour immuable. Modifier la théorie après l'assemblage d'une requête fait surgir un avertissement de dérive, car des théories contradictoires entre requêtes détruisent la crédibilité. La sécurité par ligne borne chaque enregistrement aux accès du dossier, l'API reflète chaque règle pour qu'une transition bloquée s'explique au lieu d'échouer, et chaque sauvegarde infonuagique reflète la théorie et les trousses dans le registre normalisé — l'espace de travail, l'API et les surfaces avocat lisent la même réalité.

Ops : un prechecage de migration a echec rapide pour que les deploiements cessent de bloquer sur l hote de BD IPv6 (#1532)

• Ajout d un prechecage au lanceur de migrations : lorsque les migrations strictes sont requises (REQUIRE_MIGRATIONS=1) mais que la connexion pointe vers l hote direct Supabase (uniquement IPv6), la construction echoue desormais immediatement avec la remediation exacte (utiliser l URL du pooler de session IPv4) au lieu d un blocage de 15 secondes et d une erreur reseau obscure.

Outillage de securite : activer la protection contre les mots de passe compromis (HIBP) via l API de gestion Supabase (#1516)

• Ajout d un outil, execute par l operateur, qui active la protection contre les mots de passe compromis (Have-I-Been-Pwned) via l API de gestion Supabase et verifie le reglage apres l avoir applique plutot que de le presumer actif.

Contenu : cabler la couche editoriale des carrefours de juridiction derriere une validation (#1485)

• Cablage de la couche editoriale des carrefours de juridiction : les contacts cles et les ressources selectionnees ne s affichent sur une page de juridiction qu une fois qu un canevas verifie par un humain passe la validation. Le registre est livre vide, donc rien n est fabrique — les sections apparaissent uniquement lorsqu un editeur importe un canevas verifie.

Outillage : versionnage par « changesets » + une proposition de file d'attente de fusion — le correctif du bruit de versions lors des fusions concurrentes (#1629)

• Ajout d'un outillage de versionnage par « changesets » : chaque PR dépose un fichier sous changes/ au lieu de modifier lib/version.ts et le changelog, de sorte que les PR concurrentes cessent d'entrer en conflit sur ces deux fichiers ; l'incrément de version et une entrée de changelog bilingue sont matérialisés une seule fois au moment de la fusion. Livré avec une commande de création/liste, un garde-fou de PR, le script d'application à la fusion et des tests unitaires — inactif jusqu'à ce que le garde-fou CI et le flux d'incrément de version soient basculés selon la proposition dans docs/proposals/0001.

Ops (#71) : sauvegarde et restauration applicatives, portables, des dossiers/preuves — exportation/importation JSON par simple clé de rôle de service, sans connexion Postgres directe, en complément du plan de sauvegarde pg_dump déjà existant.

• Nouveaux `scripts/backup-matters.mjs` / `scripts/restore-matters.mjs` : le premier exporte `matters`, `matter_access`, `evidence_items` (et un inventaire de métadonnées — jamais le contenu des fichiers — du bucket de stockage privé `evidence`) dans un fichier JSON horodaté + un manifeste (sommes de contrôle SHA-256, comptes de lignes) écrit dans le répertoire ignoré par git `ops-exports/`; le second restaure à partir de ce fichier en mode « simulation » PAR DÉFAUT (aucune écriture sans `--apply`), refuse d'écraser une ligne plus récente en direct que dans la sauvegarde sauf avec `--force`, et rejette d'emblée tout fichier de sauvegarde altéré ou tronqué (vérification d'intégrité avant tout accès à la base).
• Nouveau module pur `lib/ops/matter-backup.ts` (aucune E/S) partagé par les deux scripts — calcule le manifeste/les sommes de contrôle et la logique de comparaison ligne par ligne (insertion / mise à jour / ignorer-identique / refuser-plus-récent-en-direct / forcer-l'écrasement). Couvert par 11 nouveaux tests (`lib/ops/__tests__/matter-backup.test.ts`) qui font un aller-retour complet sur des données fictives en mémoire — délibérément AUCUNE connexion à une base de données réelle.
• Nouveau `docs/runbooks/BACKUP_RESTORE.md` : procédure complète (simulation d'abord, puis application), recommandation de calendrier (exemples cron et launchd) et de politique de rétention, propre à ce nouvel outil — renvoie vers `docs/BACKUP_RESTORE_RUNBOOK.md` (la procédure `pg_dump`/PITR pleine base existante) dans les deux sens; les deux se complètent, aucun ne remplace l'autre.
• `package.json` : nouveaux scripts `ops:backup-matters` / `ops:restore-matters`, et câblage (oublié jusqu'ici) de `verify:backup-schedule`, qui existait déjà mais n'était relié à aucune commande npm. `.gitignore` : ajout de `/ops-exports/` (données réelles de dossiers/preuves — jamais commitées).
• Restauration réelle du contenu des fichiers de preuve hors périmètre de cet outil par choix délibéré (le manifeste ne capture que les métadonnées des objets de stockage) — reste couvert par la sauvegarde propre à Supabase Storage; voir la note de portée dans `IMPLEMENTATION_71.md` pour le suivi humain requis (automatisation CI planifiée, `.github/workflows/` étant réservé aux humains dans ce dépôt).

Le maillon d'intégration Phase 1 se referme : un avocat jumelé peut désormais recevoir le dossier ciblé — sur action explicite du client, jamais automatiquement (+10, existingToolUpgrade, #1810 / épique #63).

• Le moteur de litige et la place de marché se serrent enfin la main. Lorsque le pipeline de jumelage envoie votre demande aux avocats et que l'un l'accepte, le panneau de partage du dossier affiche désormais vos avocats jumelés à côté du formulaire de partage par courriel existant — un clic remet le dossier avec exactement la permission et la portée que vous avez choisies (révision ciblée en lecture seule des documents et pièces sélectionnés, ou collaboration complète), appliqué au niveau de la base de données comme tout autre partage.
• Le partage n'est jamais automatique : un jumelage est une piste, pas un consentement à consulter un dossier de litige, donc rien ne bouge tant que vous ne le décidez pas. L'engagement est marqué avec le dossier qu'il sert désormais (premier arrivé, premier servi — un engagement déjà lié à un autre dossier est refusé), et une entrée d'audit enregistre le transfert.
• Le nouveau `lib/matter-shares/create-share.ts` extrait l'implémentation unique de partage côté serveur (contrôle de propriété → insertion → double écriture de la liste d'accès → audit) afin que le parcours de partage par courriel existant et le nouveau parcours d'avocat jumelé ne puissent jamais diverger. Le nouveau `POST /api/engagements/[id]/share-dossier` exige que l'appelant SOIT le client de l'engagement (RLS + vérification explicite), que l'engagement soit accepté/en cours/terminé, et que l'avocat soit inscrit — des vérifications redondantes conservées même là où la RLS restreint déjà le même cas.

Fiabilité (CI) : le contrôle automatisé de fumée Playwright ne signale plus de faux échecs, ce qui rétablit la confiance dans un signal de qualité automatisé (#1799).

• Le contrôle de fumée Playwright (un balayage automatisé qui charge chaque page publique pour détecter des régressions avant qu'elles n'atteignent la production) signalait des erreurs 429 « trop de requêtes » sur pratiquement chaque exécution depuis qu'un récent durcissement anti-abus avait ajouté des limites de débit à deux points d'accès de télémétrie anonymes. Les chargements rapides de pages du contrôle de fumée déclenchaient la même protection anti-inondation anonyme destinée au trafic réellement abusif, et non un véritable défaut du produit — mais un contrôle qui est toujours rouge finit par apprendre à tout le monde à ne plus le regarder, ce qui risque de masquer une vraie régression plus tard.
• Correctif : les deux points d'accès concernés reconnaissent désormais un signal réservé à la CI qui permet au robot de fumée automatisé de contourner uniquement la limite de débit pour son propre trafic — rien d'autre dans la requête ne change, et aucun autre visiteur ou appelant n'est touché de quelque façon que ce soit. Ce signal n'existe que si un opérateur du dépôt le configure délibérément pour la tâche de CI; sans cette configuration (le comportement par défaut partout, y compris en production), les points d'accès se comportent exactement comme avant ce correctif.
• Aucun changement de comportement visible pour les utilisateurs. Il s'agit d'un correctif interne d'infrastructure CI/tests pour que la porte de qualité automatisée reflète à nouveau de vraies régressions plutôt qu'un faux positif déjà connu comme bruyant.

Durcissement (P0, clôture ROK Phase 2) : correctifs d'intégrité d'activation pour l'incident 0155/v7.80.14 — un lecteur du plan de contrôle qui échoue sur une colonne de migration manquante ne s'effondre plus directement en SAFE_MODE, plus une garde de synchronisation de schéma au déploiement et un guide opérateur d'activation (#1807, #1532, épopée #1746).

• Incident (2026-07-06) : la PR #1804 a livré un lecteur du plan de contrôle avec une sélection de colonnes explicite sur les nouvelles colonnes de la migration 0155, mais les déploiements de production n'appliquent pas automatiquement les migrations sans URL Postgres configurée — la sélection sur la base de données non migrée a donc échoué, et le comportement de repli fermé (correct) a silencieusement refusé chaque porte Stripe/paywall pendant environ 1 heure sans signal fort indiquant la cause.
• `lib/control-plane/state.ts` (`getControlState()`) reconnaît désormais SPÉCIFIQUEMENT une erreur de colonne Phase 2 manquante (SQLSTATE 42703) et retente une fois avec l'ensemble de colonnes d'avant 0155, en fixant par défaut les deux nouveaux interrupteurs d'arrêt à faux — leur vraie valeur par défaut — au lieu de retomber entièrement en SAFE_MODE. Un journal fort étiqueté « #1807 » s'affiche à chaque nouvelle tentative ; tout autre mode d'échec (réseau, ligne manquante, autre erreur) reste en repli fermé exactement comme avant.
• Nouveau `scripts/check-schema-sync.mjs` (intégré à `npm run build`) : lorsqu'une URL Postgres est configurée, sonde un manifeste de sentinelles archivé (`scripts/schema-sentinels.json`) des tables/colonnes clés des migrations récentes par rapport à la base de données en direct — avertissement seulement par défaut, `REQUIRE_SCHEMA_SYNC=1` pour faire échouer la construction. Sans URL Postgres configurée (posture réelle de production aujourd'hui, voir #1532), il reste en avertissement seulement, sans jamais casser une construction qui n'a aucun moyen de vérifier la base de données.
• Nouveau `npm run activation-lock-report` (`scripts/activation-lock-report.mjs`) — un rapport markdown pour l'opérateur combinant l'état de contrôle/drapeaux/interrupteurs d'arrêt en direct, les sentinelles de migrations en attente, les constats de `check:clean-state`, et une liste de vérification des neuf portes de l'ADR-0007 avec les portes 2 et 8 réellement évaluées par rapport à l'état en direct. Complète (sans le remplacer) le rapport JSON intégré existant #1747.
• Nouveau `docs/runbooks/ACTIVATION.md` — le guide de l'opérateur pour le graphe à 8 états, la conduite du panneau de contrôle, les trois couches d'interrupteurs d'arrêt, la procédure de restauration, l'incident #1807 comme étude de cas, et la procédure d'application de migration réservée au fondateur. Son annexe inclut le contenu complet du flux CI `activation-gate.yml` proposé pour #1754 (réservé aux humains — non appliqué à `.github/workflows/`).

Correctif de fiabilité de la facturation : le portail de compte (gestion de carte / factures / annulation) reste correct pour les membres actifs sur plus d'une édition-pays de la plateforme (#1793).

• Le lien interne entre votre compte et votre profil de facturation Stripe est propre à chaque édition-pays. Si vous aviez effectué un achat sous plus d'une édition avec le même compte, l'achat le plus récent pouvait écraser l'ancien à l'interne — l'ouverture du portail de facturation pour l'édition antérieure pouvait donc brièvement échouer avec une erreur générique au lieu de s'ouvrir. Cela n'a jamais exposé les données de facturation de qui que ce soit à quiconque; c'était purement une défaillance du type « mauvais bouton, réessayez » touchant un petit nombre de membres, désormais corrigée.
• Les deux parcours d'achat (abonnements et achats ponctuels/Copilot) enregistrent désormais le lien vers le profil de facturation Stripe par édition, et le portail de facturation se résout désormais strictement dans l'édition que vous utilisez actuellement — chaque portail d'édition s'ouvre donc toujours correctement, même pour les membres actifs sur plus d'une édition.
• Migration de base de données additive seulement (`0156_stripe_customers_edition_key.sql`); aucune donnée n'a été perdue ni réinitialisée, et aucun autre comportement de facturation n'a changé. Ajout de tests de régression automatisés couvrant l'isolation entre comptes et la stabilité des achats répétés, afin que ce type de problème soit désormais détecté avant la mise en production.

Correctif (P2, revenu/UX) : les profils de prestataires du marché ne se terminent plus en cul-de-sac au moment de la conversion — chaque prestataire offre désormais un vrai parcours de demande de soumission ou d'avis, au lieu d'un formulaire de contact générique ou d'un avis statique « non réservable » (#1737).

• Sur un profil de prestataire (`/marketplace/[slug]`), un professionnel vérifié ne menait auparavant qu'au formulaire de contact générique du site (`/contact?provider=slug`), et un professionnel non vérifié / en attente de révision juridique n'affichait qu'un avis statique « Non réservable avant vérification » sans aucune action — précisément là où un justiciable ayant enfin trouvé un prestataire était le plus susceptible de convertir. Les deux affichent désormais un vrai formulaire de demande propre au prestataire.
• Les prestataires vérifiés obtiennent un parcours « Demander une soumission » (courriel + message facultatif) qui enregistre la demande et établit les attentes (« répond habituellement en N h »). Les prestataires non vérifiés / en attente obtiennent un parcours « Pas encore réservable — inscrivez-vous » avec des attentes honnêtes : il capte la demande, promet d'avertir le justiciable dès que le prestataire est réservable et transmet ses coordonnées — au lieu de le rediriger vers un formulaire générique ou un cul-de-sac.
• Le nouveau `POST /api/marketplace/provider-request` enregistre l'intérêt seulement (aucun paiement, n'active jamais de porte de réservation), en persistant dans le registre partagé `service_orders` avec `status = 'provider_request'` via le client à rôle de service — le même modèle additif et respectueux des RP que le parcours d'avis existant (Loi 25 : le courriel/message n'atteint jamais les journaux). Se dégrade gracieusement en `{ ok: true }` si le service est indisponible, pour que l'expérience ne se bloque jamais.
• Nouvel îlot client `components/marketplace/ProviderRequestForm.tsx`; l'événement de croissance `PROVIDER_CONTACTED` est désormais déclenché à l'envoi réel de la demande. Entièrement trilingue (en/fr/es) avec clés de dictionnaire typées; aucun changement de schéma ni de migration.

Durcissement ROK Phase 2 : états d'activation CONNECTED/VERIFIED, trois interrupteurs d'arrêt indépendants, un moteur de retour en arrière par rejeu du registre, et le Superviseur de déploiement (épopée #1746, tickets #1748–#1752).

• Formalise le DAG d'activation de l'ADR-0007 (docs/adr/0007-rok-activation-dag.md) au-dessus du noyau d'orchestration des mises en production (ROK) Phase 1 (#1714) : « CONNECTED » et « VERIFIED » sont deux nouveaux états ADDITIFS insérés entre « STAGED » et « LIMITED_PROD » dans « lib/control-plane/types.ts » (#1749) — « CONNECTED » signifie que le pooler Supabase est câblé et validé en lecture seule, le revenu restant OFF ; « VERIFIED » signifie qu'une reconstruction propre a réussi et que le registre/les indicateurs du ROK sont internement cohérents. Câbler l'URL du pooler devient une transition d'état gardée et auditée plutôt qu'un simple changement de configuration silencieux. Chaque état, colonne et règle de transition existants restent inchangés ; la ligne singleton « FULL_PROD » en production n'est pas touchée par ce déploiement (« FULL_PROD<->LIMITED_PROD » demeure exactement une étape).
• Nouveau validateur de prérequis Gate 2 (« lib/control-plane/activation-gates.ts », « evaluateRokSelfCheck ») qui bloque un déplacement VERS L'AVANT vers « VERIFIED » ou « LIMITED_PROD » lorsque la forme des indicateurs configurés, la cohérence interne « PROGRESSION »/« CONTROL_STATES », ou la monotonicité du registre récent semblent incorrectes — jamais sur une étape de retour en arrière, afin qu'une porte de sécurité ne puisse jamais piéger un opérateur cherchant à reculer. Les portes restantes de l'ADR à neuf portes (aller-retour du pooler, essai à blanc des analytiques, parité de double écriture Stripe, hachage du manifeste de déploiement, …) exigent des signaux externes en direct que ce code ne produit pas encore et sont délibérément reportées, en attente de décision du fondateur — voir IMPLEMENTATION_1749.md.
• Interrupteurs d'arrêt en couches (#1750) : le simple « killSwitch » devient la couche Globale documentée, rejointe par deux nouvelles colonnes booléennes indépendantes et additives — « killSwitchRevenue » (Stripe + mur de paiement coupés, analytiques/Moteur de Justice non touchés) et « killSwitchRokEnforcement » (une échappatoire à sécurité positive, exigeant un motif, qui suspend le contrôle d'état/indicateur propre au ROK pour Stripe/le mur de paiement pendant que « system_control_events » continue d'enregistrer normalement chaque écriture — « désactiver l'application, garder la journalisation d'audit »). « lib/control-plane/guards.ts »/« writer.ts » étendus en conséquence ; les deux nouvelles colonnes valent par défaut « false », un no-op pour la ligne en production tant qu'un opérateur n'en active pas une délibérément. Le Panneau de Contrôle du Fondateur (« components/admin/ControlPlanePanel.tsx ») a reçu une section à confirmation par couche.
• Moteur de retour en arrière par rejeu du registre (#1751, nouveau « lib/control-plane/rollback.ts ») : reconstitue le dernier état que le registre append-only « system_control_events » a enregistré comme « VERIFIED »/« CONNECTED »/« SAFE_MODE », enregistre un événement « rollback.triggered » décrivant le plan, puis remonte la ligne « PROGRESSION » exacte, étape par étape validée, jusqu'à cette cible via le rédacteur EXISTANT « transitionState » — chaque saut est pleinement audité, comme une transition manuelle. Distinct de la récupération actuelle « EMERGENCY_LOCKDOWN »→« SAFE_MODE » : accessible depuis n'importe quel état, et la cible est dérivée du registre, non codée en dur. Câblé dans le POST du Panneau de Contrôle, « action: "rollback" ».
• Superviseur de déploiement (#1752, nouveau « lib/control-plane/supervisor.ts » + « GET /api/cron/rok-supervisor », protégé par CRON_SECRET via le « requireCronAuth » partagé, planifié toutes les 15 minutes dans vercel.json) : réconcilie la ligne faisant autorité avec la dernière transition enregistrée par le registre (« STATE_MISMATCH »), vérifie l'invariant de sécurité nommé par le fondateur lui-même — Stripe configuré en « live » en dehors de « LIMITED_PROD »/« FULL_PROD » (« SAFETY_VIOLATION », engage automatiquement « EMERGENCY_LOCKDOWN ») — et, seulement lorsqu'une valeur d'environnement « ROK_SUPERVISOR_EXPECTED_STATE » configurée par un opérateur est présente, la compare à l'état en direct (« DRIFT_DETECTED »). La vérification de dérive CI↔exécution est une implémentation PARTIELLE documentée, par décision délibérée de portée : ce dépôt n'a aucun signal d'identifiant de construction/SHA de commit existant dans le registre à comparer, et en fabriquer un serait pire qu'un no-op honnête — voir IMPLEMENTATION_1749.md pour ce qu'exigerait un vrai signal.
• Porte de réconciliation d'état propre en CI (#1748, nouveau « scripts/check-clean-state.ts », « npm run check:clean-state ») : signale les fichiers « app/api/**/route.ts » morts n'exportant aucun gestionnaire de méthode HTTP reconnu, deux routes qui résoudraient au même chemin d'API, des valeurs littérales dupliquées dans les tableaux « as const » de noms d'événements/télémétrie soigneusement tenus à jour de ce dépôt, et la réintroduction de chaînes historiques interdites (« src/[locale] », l'ancienne référence de projet Supabase morte pré-migration). Fonctionne en mode RAPPORT SEULEMENT (non bloquant, câblé dans « npm run build ») aujourd'hui, propre sur l'arbre actuel ; passer à la variante bloquante « check:clean-state:strict » une fois le rapport éprouvé stable est un suivi en attente de décision du fondateur.
• Nouvelles suites de tests unitaires pour chaque nouveau module (« activation-gates.test.ts », « rollback.test.ts », « supervisor.test.ts », plus des ajouts à « guards.test.ts »/« writer.test.ts »/« state-machine.test.ts ») et migration « 0155_rok_phase2_hardening.sql » — strictement additive (contraintes CHECK élargies, nouvelles colonnes NOT NULL DEFAULT false/null, aucun changement de table/politique ; la RLS de ces deux tables avait déjà été revue dans la migration 0150 et n'est pas touchée ici). Suite complète du plan de contrôle au vert (127 tests) ; voir IMPLEMENTATION_1749.md pour le registre complet de ce qui est livré par rapport à ce qui est explicitement reporté.

Docs/schéma (fichiers du dépôt seulement, #1791) : le substrat de grand livre Financial Impact Engine (FIE) Phase 0 arrive sous forme d'ADR + un jeu de migrations non auto-appliquées — rien n'est appliqué à la base de données en production.

• Nouveau `docs/adr/0007-financial-impact-engine-phase0.md` (ADR-0007) : un noyau de grand livre en partie double, multidevise, à sourçage d'événements, dans un schéma Postgres dédié `fie`, avec RLS par locataire — le socle d'un futur projecteur de facturation d'avocats (Phase 1) et de la Déclaration d'impact judiciaire (rapport d'économies/impact). Adapté de la remise de conception du fondateur; la logique SQL est inchangée par rapport à la source, seulement renumérotée.
• Renumérotation des fichiers du fondateur `0001_fie_core.sql`…`0004_fie_seed.sql` en `0156`…`0159` (la séquence `supabase/migrations/` de main en était à 0152, avec 0153/0154 déjà réservés par d'autres PR en cours) — mais placés sous `supabase/fie/migrations/`, et non `supabase/migrations/`, précisément pour que le parcours de répertoire de `scripts/apply-migrations.mjs` ne les capte jamais au prochain déploiement de production. Les promouvoir vers le chemin auto-appliqué est une décision distincte, explicite, réservée au fondateur.
• Adaptations de sécurité pour la production : le locataire/entité/compte de test d'isolation RLS « acme » ont été retirés de la migration de semis et déplacés vers un nouveau `supabase/fie/verify-fixtures.sql` (test local seulement); la fonction `fie.current_tenant()` basée sur GUC et le rôle `fie_app` sans connexion sont conservés exactement tels qu'écrits (aucun octroi à `authenticated`, aucune liaison au jeton JWT pour l'instant) — le point de liaison JWT de Supabase est documenté dans l'ADR comme travail de Phase 1, non fait ici.
• `supabase/fie/verify.sql` (la suite d'invariants auto-vérifiants T1–T9 du fondateur, précédemment exécutée avec succès 9/9 sur un vrai PostgreSQL 14.23) est déplacé aux côtés des données de test comme harnais de test, hors des deux répertoires de migrations pour ne jamais s'auto-appliquer. Voir `IMPLEMENTATION_1791.md` pour la carte de renumérotation, l'enquête sur l'auto-application, et la tentative/les résultats de vérification locale propres à ce dépôt.
• Aucun code applicatif, route ou chaîne d'interface n'a changé. Le ticket de suivi #1791 (`epic`, `architecture`, `human-gate`) porte la feuille de route par phases (projecteur de facturation Phase 1 jusqu'à la réévaluation Phase 4); ce PR est Phase 0 seulement.

Le Score de Justice™ passe en direct de bout en bout : pointage élément par élément, évaluation « Prêt pour le tribunal » et preuve rattachée aux éléments — câblés dans chaque dossier, du moteur à l'interface (#1664).

• Correspondance recours-situations : 27 des 113 situations réelles de consommation québécoises de la plateforme (« lib/legal/qc-consumer-problems.ts ») sont désormais rattachées à une cause d'action concrète — litiges contractuels, vices cachés, manquements à la Loi sur la protection du consommateur, préjudices en responsabilité extracontractuelle (dommages matériels, diffamation, vie privée, blessures médicales/dentaires, décès injustifié, et plus), non-paiement de factures ou de dettes, et réparations en matière de bail au TAL. Chaque rattachement est une correspondance confiante et référencée ; les situations restantes (droit de la famille, droit pénal, immigration, normes du travail, assurances et autres régimes pour lesquels ce modèle de recours n'a jamais été conçu) sont délibérément laissées non rattachées et consignées comme travail de suivi plutôt que devinées.
• Preuve rattachée aux éléments : un dossier peut désormais porter une ou plusieurs réclamations, chacune décomposée selon les éléments juridiques ordonnés de son recours. Le justiciable fixe un état de preuve en 5 paliers (non traité → allégué → appuyé → solide → corroboré) et une case d'admissibilité par élément, et y rattache une preuve déjà versée au dossier. C'est le signal réel derrière la dimension la plus lourde du pointage (Démonstration élément par élément) et le verrou « Élément non prouvé » — fini le zéro honnête mais figé.
• Seuils « Prêt pour le tribunal » sensibles au forum : le profil de juridiction (Petites créances / Cour du Québec / Cour supérieure / TAL) se déduit désormais automatiquement du montant réclamé et du forum, la bande concurrente de 75 000 $ à 99 999,99 $ étant départagée par le tribunal déjà choisi dans le dossier. La position de prescription se calcule à partir de la date de l'incident (et, pour un vice caché, de la date de découverte selon l'art. 2926 CCQ) par rapport au délai de prescription propre au recours de chaque réclamation — prudent par conception, privilégiant « discutable » plutôt que « clairement prescrit » chaque fois qu'une interruption est plausible. La médiation obligatoire (le seuil de 5 000 $ des Petites créances, par exemple) déclenche désormais son verrou sur la seule base du montant réclamé lorsqu'aucune étape de médiation n'est consignée du tout.
• Interface destinée au justiciable : le panneau Score de Justice de l'espace de travail affiche désormais un indicateur explicite « Prêt pour le tribunal », une liste de vérification des réclamations et éléments (référence d'autorité, sélecteur d'état de preuve, case d'admissibilité, rattachement de preuve, indices de preuve), une liste de points bloquants, et un panneau « Ce que la partie adverse attaque » — en anglais, français et espagnol complets ; le justiciable ne voit jamais les termes internes comme « verrou » ou « dimension ».
• Aucune migration de base de données : les réclamations sont persistées dans l'enregistrement complet du dossier, exactement comme le fait déjà chaque autre panneau de l'espace de travail. Plus de 60 tests nouveaux ou mis à jour (déduction du profil, position de prescription, seuil de médiation, pointage de bout en bout, et un test de rendu du panneau) ; la suite complète et « check:justice-score » (23/23) restent au vert.

Score de Justice™ : la couche Enjeux et réclamations arrive — le catalogue manquant derrière la dimension D7 (#1664).

• « lib/justice-score/model.ts » et les notes internes des tâches T4/T7 signalaient que la dimension D7 (« Démonstration élément par élément », la dimension la plus lourde avec 100 points de base) restait honnêtement inerte tant qu'aucun catalogue reliant les recours à leurs éléments juridiques n'existait pour l'alimenter. Le nouveau « lib/justice-score/issues-claims.ts » est ce catalogue : 7 recours québécois (responsabilité contractuelle, vice caché, responsabilité extracontractuelle, pratique interdite LPC, réclamation de somme due, réparations/jouissance TAL, enrichissement injustifié), chacun décomposé en ses éléments juridiques ordonnés — essentiels ou non — avec une étiquette bilingue/trilingue, une référence d'autorité indicative (CCQ/LPC), et, pour certains éléments, la dimension supplémentaire qu'ils alimentent.
• Le nouveau « lib/justice-score/element-derivation.ts » est le point d'ancrage dans le moteur : « deriveD7FromClaims(claims) » transforme l'état de preuve de chaque élément d'un dossier en une complétude Complétude/Substantiation/Admissibilité pour D7, ainsi que le signal réel derrière la porte G3 existante (un élément essentiel resté entièrement sans réponse) et des éléments d'exposition « ce que la partie adverse va attaquer », sûrs pour le justiciable. Cette couche se branche directement sur le moteur existant et INCHANGÉ (« computeJusticeScore »/« evaluateGates ») — aucun fichier du moteur n'a dû changer, puisque le modèle v1.0 verrouillé génère déjà génériquement un jeu de critères « d7-C »/« d7-S »/« d7-A »/« d7-R »/« d7-P » pour chaque dimension.
• Chaque recours/élément/référence d'autorité rédigé par le fondateur a été repris sans modification ; seules les orthographes des identifiants de dimension (« D7 » → « d7 ») et de profil de juridiction (« courQC » → « cq », etc.) ont été adaptées aux conventions déjà en place dans « model.ts »/« profiles.ts ». Une comparaison, constante par constante, avec les poids d'axe, les plafonds de porte, le plancher R et les seuils par tribunal du moteur existant n'a révélé aucun écart — les deux décrivent le même modèle v1.0 verrouillé par le fondateur.
• Cette version ne touche qu'à la couche données/moteur : « derive.ts »/« gaps.ts » (en pleine réécriture sous le chantier concurrent #1769) et l'interface WorkflowStepper destinée au justiciable restent délibérément intouchées — voir « IMPLEMENTATION_1664.md » et « docs/plan/justice-score/WIRING.md » pour le câblage qu'une future version devra encore réaliser une fois que les dossiers porteront des données de réclamation. De nouveaux tests fixent exactement les quatre valeurs limites Enjeux et réclamations → D7/G3 (63 / plafond 55 / 50 / 44,5) ; la suite justice-score complète et « check:justice-score » (23/23) restent au vert.

Intégration groupée : 16 PR de la flotte, révisées, atterrissent en une seule version — témoins ES, correctifs i18n, découverte de tests, unification du copilote, regroupement de navigation, verrou de référence du Score de Justice, lien client Stripe, consolidation du k-anonymat, correctif DSAR de première partie, ADR du graphe d'activation ROK, Repo Guardian, indicateur du sélecteur Drive, entonnoir de conversion, définition de « terminé » pour les panneaux, performance du hachage des preuves et décomposition de la coquille Workspace (#1800).

• Fait s'effondrer la cascade sérielle de changelog qui bloquait l'atterrissage de 16 PR indépendamment révisées et vérifiées au vert : #1612 (témoins ES), #1745 (correctifs dict fr), #1662 (découverte de tests), #1730 (unification du copilote), #1732 (regroupement de navigation), #1736 (verrou de référence du Score de Justice), #1738 (lien client Stripe), #1743 (consolidation du k-anonymat), #1742 (correctif DSAR de première partie), #1753 (ADR du graphe d'activation ROK), #1254 (Repo Guardian), #1763 (indicateur du sélecteur Drive), #1702 (entonnoir de conversion), #1627 (définition de « terminé » pour les panneaux), #1741 (performance du hachage des preuves), #1735 (décomposition de la coquille Workspace).
• L'entrée de changelog propre à chaque PR est préservée ci-dessous, empilée du plus récent au plus ancien selon sa version d'origine; cette entrée est le marqueur de la version groupée, pas un remplacement des entrées individuelles.
• Un seul renumérotage de migration a été nécessaire à l'entrée : la migration de k-anonymat de #1743 avait déjà été auto-renommée par son auteur de 0153 à 0154 pour éviter d'entrer en collision avec 0153_stripe_customer_link.sql de #1738 — SQL vérifié identique octet pour octet, aucune référence obsolète, `check:migration-collisions` au vert.
• Aucune PR n'a été écartée pour un conflit sémantique; tout conflit de fusion rencontré était mécanique (fichiers de version/changelog/verrouillage), résolu par fusion manuelle des dictionnaires de changelog et réconciliation d'un seul vrai conflit de code dans la coquille Workspace (le crochet `useWorkspaceOverlays` du remaniement #1735 contre l'indicateur `showAllSections` de #1732, tous deux préservés).

Correctif (P2, confidentialité / Loi 25) : le seuil de k-anonymat de la plateforme est désormais UN seul nombre révisé partout, et les agrégats de cohortes généralisent leurs valeurs de région/langue/spécialisation afin qu'une valeur rare en texte libre ne puisse plus ré-identifier une cohorte à peine au seuil k (#1743).

• Deux seuils avaient divergé : la barrière d'analyse comparative anonymisée (lib/analytics/cohort-gate.ts, #466) utilisait k=10 alors que le chemin d'apprentissage des résultats EN PRODUCTION (lib/matching/outcome-aggregates.ts + la contrainte CHECK de la base dans 0122) livrait un k=5 inférieur et non révisé. Une source unique de vérité, lib/privacy/k-anonymity.ts (K_ANONYMITY_MIN_COHORT), alimente maintenant les trois; consolidé VERS LE HAUT au seuil plus strict révisé par #466, soit 10 (relever un seuil k ne fait que supprimer davantage de cohortes rares, jamais moins). La migration 0154 relève la contrainte CHECK de matching_outcome_aggregates de >=5 à >=10.
• La preuve de dé-identification n'inspectait que les NOMS de clés, donc une spécialisation rare en texte libre partagée par exactement k dossiers pouvait satisfaire le seuil de taille tout en permettant une ré-identification. Le nouveau lib/matching/quasi-identifiers.ts fait correspondre région/langue/spécialisation à une liste d'autorisation bornée (codes de juridiction canoniques, langues de publication, catégories de litige); tout ce qui n'y figure pas est généralisé vers une catégorie grossière « other » à l'ingestion, et assertDeidentified prouve maintenant en mode fail-closed que chaque VALEUR de quasi-identifiant est généralisée avant qu'un agrégat puisse être publié.
• La consolidation et l'attestation juridique [H-LEGAL] #466 en attente (le seuil ne peut être abaissé sous 10 qu'après cette signature) sont consignées dans docs/decisions/1743-k-anonymity-threshold-consolidation.md. Aucun changement à l'isolation des dossiers, au RLS ou à l'invariant d'appariement sans influence des paiements.

Correctif (P1, UX justiciable) : un seul copilote conversationnel — vous pouvez maintenant poser une question libre, en contexte, depuis un dossier ouvert, et l'accueil cesse d'offrir deux portes d'entrée IA concurrentes (#1730).

• Dans un dossier, la carte no 1 du copilote s'intitulait « Poser une question » mais ne comportait qu'un bouton déclenchant une seule invite figée se terminant par une question fixe — aucune zone de texte, si bien qu'un justiciable lisant une requête ne pouvait littéralement pas taper « comment répondre à ceci ? ». Le vrai clavardage multi-tours (`CopilotChat.tsx`) n'était accessible que depuis l'accueil de l'espace de travail, jamais depuis un dossier ouvert.
• `CopilotChat.tsx` accepte désormais un `contextSummary` de dossier optionnel (le résumé structuré du dossier, ajouté à chaque requête pour que les réponses portent sur CE dossier) et des `starters` optionnels (questions d'exemple affichées en puces d'un seul clic sur le fil vide). Un même composant sert maintenant les deux surfaces.
• La carte no 1 du copilote dans un dossier ouvre ce clavardage amorcé avec le contexte du dossier et des amorces pertinentes (« Comment répondre à ceci ? », « Quelles sont mes prochaines étapes ? », « Qu'est-ce qui manque à mon dossier ? », « Comment me préparer à l'audience ? ») au lieu d'un bouton sans issue.
• À l'accueil, la fenêtre modale à question unique `AskQuestion`, redondante, est retirée : la carte « Poser une question », l'action rapide « Lancer le copilote » et l'entrée de navigation ouvrent toutes le même clavardage multi-tours, désormais amorcé avec les questions d'exemple d'information juridique générale. Plus aucune question de suivi ne perd son contexte.
• Aucun changement à la route `/api/ai/copilot`, aux limites de quota/péage, ni à aucune surface de facturation ou RLS — il s'agit d'une consolidation côté client des deux points d'entrée d'aide IA en un seul.

Entretien (P1, dette technique) : amorce d'une décomposition sans changement de comportement du composant coquille Workspace de ~4 200 lignes, afin qu'il soit plus sûr à modifier (#1735).

• `components/workspace/Workspace.tsx` était un composant client unique contenant 71 tranches de `useState` et des dizaines de constantes de niveau supérieur, faisant de chaque frappe au clavier un risque de re-rendu de tout l'arbre et rendant le fichier lui-même dangereux à toucher — la plus grande dette de maintenabilité signalée par l'audit de rafraîchissement du dépôt du CTO. Cette première passe, délibérément mécanique, en extrait trois groupes cohésifs et autonomes sans aucun changement fonctionnel.
• Le nouveau `components/workspace/workspace-shell.config.ts` regroupe la configuration pure et sans état de la coquille qui vivait auparavant en tête du composant : la taxonomie `Tab` à 36 entrées et la liste `TABS`, la carte `ACTIVITY_CATEGORY_BY_TAB`, les descripteurs `WORKSPACE_PORTALS`, l'assistant de stockage local `upsertLocalMatter` et le drapeau `GUIDED_TOUR_APP_ENABLED`. Ces éléments sont désormais importables par l'outillage et les tests sans tirer tout l'arbre du composant.
• Le nouveau `components/workspace/useWorkspaceOverlays.ts` extrait les dix bascules pures de visibilité des panneaux/superpositions (`useState`) (réglages, mode présentation, les deux assistants d'admission, cabinet, urgence, aide, les deux menus « plus d'onglets » et le badge infonuagique) dans un crochet cohésif, et le nouveau `components/workspace/useCloudSyncState.ts` fait de même pour les douze tranches d'état de synchronisation infonuagique et de persistance (session authentifiée, vérification de connectivité, signalement des échecs de chargement/sauvegarde, badges de synchronisation par dossier et flux d'importation des dossiers locaux orphelins). Dans les deux cas, la coquille les redéstructure en liaisons de noms identiques, de sorte que chaque site d'appel existant est inchangé octet pour octet — strictement préservateur du comportement.
• La nouvelle suite de caractérisation `components/workspace/__tests__/workspace-shell-refactor-1735.test.ts` fige la taxonomie d'onglets extraite, la carte d'activité et les descripteurs de portails, et vérifie que la coquille tire maintenant la configuration et les deux crochets d'état des modules voisins plutôt que de les déclarer en ligne. Suite complète au vert; `tsc --noEmit` et une véritable compilation `next build` passent. Aucun changement d'ergonomie, aucun changement de schéma ni de migration. L'état restant (les ~40 setters d'édition de dossier → un `useReducer`, puis un fournisseur de contexte pour les onglets à chargement différé) est documenté dans `IMPLEMENTATION_1735.md` comme les prochaines passes incrémentales.

Correctif (P2, durabilité des données / santé du code) : le magasin local des dossiers verrouille désormais sa migration par version de schéma, de sorte que la normalisation non typée s'exécute une fois par mise à niveau au lieu de s'exécuter à chaque chargement de page (#1740).

• `loadCases` de `lib/store/cases.ts` exécutait `migrateCase` — une normalisation non versionnée et non typée (analyse regex des pièces, cascade de valeurs par défaut `??`, conversions `ex:any`) — sur CHAQUE dossier à CHAQUE chargement, sans verrou de version de schéma. Un nouveau jalon `CASES_SCHEMA_VERSION` enregistre la version à laquelle chaque charge stockée a été normalisée pour la dernière fois ; `loadCases` n'exécute désormais `migrateCase` que lorsque la charge est EN RETARD par rapport à cette version, puis réécrit le tableau mis à niveau et incrémente le jalon, de sorte que la normalisation s'exécute une fois par mise à niveau plutôt qu'une fois par chargement de page.
• Le jalon réside dans une clé localStorage SÉPARÉE, en canal latéral (`juge:cases:schemaVersion`), et n'enveloppe pas le tableau — la charge sous `juge:cases:v1` reste un `LegalCase[]` brut, de sorte qu'un déploiement plus ancien lors d'un retour arrière la lit toujours sans changement (une enveloppe l'aurait fait rejeter comme « pas un tableau » et aurait silencieusement supprimé le produit de travail de l'utilisateur). Additif, rétro- ET compatible avec l'avenir ; aucune donnée locale existante n'est perdue.
• Posture de durabilité clarifiée dans le code : localStorage est le CACHE en mode local, tandis qu'en mode infonuagique authentifié la table Supabase `matters` (voir `upsertMatter`/`listMatters` de `lib/store/remote.ts`, mise en miroir à chaque changement par `components/workspace/Workspace.tsx`) est déjà la source de vérité durable — un navigateur vidé ne détruit donc plus le produit de travail des utilisateurs infonuagiques. L'étape restante de persistance serveur complète pour les utilisateurs anonymes est documentée dans `IMPLEMENTATION_1740.md`.
• Nouvelle suite unitaire `lib/store/__tests__/cases-schema-version.test.ts` couvrant les trois chemins face à un localStorage simulé : auto-réparation du tableau brut hérité, saut de version courante (prouvé en retournant verbatim une charge délibérément non normalisée) et re-migration de version en retard. Suite complète au vert ; aucun changement de schéma/migration.

Ops (infrastructure) : Repo Guardian — journal de santé unifié utilisant le rapport avec sécurité des types (#1254).

• Conversion de `scripts/run-repo-guardian.mjs` de JavaScript vers TypeScript (`scripts/run-repo-guardian.ts`) pour permettre les importations directes du module `lib/ops/repo-guardian.ts` et éliminer la duplication de logique de formatage. Le lanceur de patrouille construit maintenant un objet `RepositoryHealthReport` entièrement typé et appelle `formatHealthReportAsComment()` du module central au lieu de construire le markdown du commentaire en ligne.
• Le lanceur de patrouille est désormais un pur orchestrateur : engendre les vérifications de santé, collecte les résultats, applique `aggregateHealthStatus()` pour calculer l'état global, formate via la fonction de commentaire centralisée du module, et envoie. Aucune logique de formatage ne vit dans le lanceur lui-même — il délègue à `lib/ops/repo-guardian.ts`, qui est la source unique de la vérité pour la structure du rapport et la génération des commentaires.
• Syntaxe d'invocation : `node --import tsx scripts/run-repo-guardian.ts` (suivant le modèle établi du dépôt pour les scripts TypeScript dans le répertoire scripts/). Le support `--dry-run`, `--no-pr-triage` et la variable d'environnement `SKIP_BUILD` reste inchangé.
• Le lanceur de patrouille est prêt pour la production pour la planification CI/cron. Le CTO peut maintenant brancher sans risque dans `.github/workflows/` ou une action planifiée.

Gouvernance (processus, pas un bogue unique) : un panneau d'espace de travail n'est pas « livré » tant qu'il n'est pas monté depuis Workspace.tsx et qu'un garde-fou de câblage ne le prouve pas (#1627).

• Cause racine : quatre PR cette session (#1611 x2, #1619, #1621) ont chacune construit un vrai panneau `components/workspace/` testé et adossé au serveur, jamais importé dans `Workspace.tsx` — une fonction locale homonyme, à état client seulement (`Exhibits`/`Witnesses`/`Deadlines`/`Chronology`), restait montée au changement d'onglet. Les tests de rendu de composant de la PR #1618 ne pouvaient pas l'attraper : ils rendent le nouveau composant DE FAÇON ISOLÉE, donc ils passent que la page le référence ou non.
• Le nouveau test d'intégration modèle `components/workspace/__tests__/workspace-panel-wiring.test.tsx` prouve, pour les quatre onglets désormais corrigés (chronologie/pièces/témoins/échéances), que Workspace.tsx monte l'enveloppe « read-through » de chaque panneau, importe le composant adossé au serveur voulu et fait déléguer l'enveloppe vers celui-ci — en plus de rendre chaque composant serveur pour épingler son identité non héritée. C'est un modèle à copier : ajouter un panneau = ajouter une ligne.
• Comme le harnais de tests unitaires du dépôt (`node --import tsx --test` + `renderToStaticMarkup`, sans jsdom, les effets ne s'exécutent pas) ne peut pas amener une enveloppe read-through au-delà de son état de chargement initial jusqu'à la branche résolue, le câblage est vérifié sur le texte source de Workspace.tsx — le garde-fou mécanique fidèle pour « le composant voulu est-il câblé du tout ». La décision read-through elle-même reste testée unitairement dans `lib/workspace/__tests__/read-through.test.ts`.
• Définition de « terminé » codifiée dans la gouvernance : `docs/governance/executive-os/20-policies.md` (Ingénierie et livraison) et une leçon dans `40-lessons.md` (« ne pas bâtir la fondation dans un mur »), plus une ligne de critère d'acceptation pour panneau d'espace de travail ajoutée à la liste de contrôle de `.github/ISSUE_TEMPLATE/task.yml`. Le correctif rétroactif des quatre panneaux touchés est suivi séparément (#1620 et les deux issues sœurs); ils sont déjà câblés sur main, et ce garde-fou le verrouille désormais.

Documentation (P2, gouvernance) : l'ADR-0007 formalise le graphe d'activation du ROK — la dépendance par étapes qui contrôle la progression STAGED→CONNECTED→VERIFIED→LIMITED_PROD→FULL_PROD, codifiant le principe « un changement de configuration n'est pas une activation; seule une transition d'état validée l'est » (#1753).

• L'ADR-0007 (`docs/adr/0007-rok-activation-dag.md`) développe la Phase 1 du ROK (#1714) en formalisant les **neuf portes de prérequis** qui doivent tenir avant chaque transition d'état. La Phase 2 introduit deux états intermédiaires (`CONNECTED` : pool filaire et sain; `VERIFIED` : toutes les validations effectuées) pour empêcher les activations en cascade de sous-systèmes lorsque l'URL du pool est définie. Le DAG assure que Stripe ne peut pas s'exécuter (state ∉ {LIMITED_PROD, FULL_PROD}) qu'après un essai à blanc analytique et la détection d'aucune route orpheline.
• Le principe de gouvernance est : chaque transition d'état nécessite une preuve préalable. Câbler le pool est une **transition d'état** (STAGED→CONNECTED), pas une cascade d'effets secondaires — la plateforme reste analytique uniquement jusqu'à une transition explicite vers LIMITED_PROD qui permet à Stripe de s'exécuter. La restauration est auditable : chaque transition rétroactive par étapes est enregistrée dans `system_control_events`.
• La séquence DAG : **Phase 1** (Intégration du pool) : vérification de la santé du pool + validation du schéma → CONNECTED. **Phase 2** (Validation) : auto-vérification du ROK + essai à blanc analytique → VERIFIED. **Phase 3** (Chiffre d'affaires) : disponibilité du déploiement de Stripe + expériences de prix prêtes + approbation de santé du superviseur de déploiement → LIMITED_PROD et FULL_PROD. L'application se fait en deux couches : API Admin (transitions fondées sur le fondateur, interactif) + Superviseur de déploiement (auto-verrouillage automatique en cas de détection de dérive).
• Changement basé sur la documentation; aucun changement de schéma ou de code dans ce PR. L'implémentation de la Phase 2 (problèmes #1747–#1752 sous l'épopée #1746) ajoutera les validateurs, étendra la machine d'état et câblera l'application dans l'écrivain du plan de contrôle et le superviseur de déploiement.

Fonctionnalité (activation du marché, épopée #100) : l'entonnoir inscription → activation → mur payant → clic de mise à niveau → conversion est désormais instrumenté de bout en bout, avec une vue Command Center pour l'administration (#1702).

• La directive du fondateur pour la phase d'activation du marché est « instrumenter avant d'optimiser » : émettre les cinq événements de propension à payer afin de mesurer l'activation, l'intention face au mur payant et la conversion payante à partir de données réelles. Quatre des cinq points de contact émettaient déjà la taxonomie typée — `signup_complete` (AuthForm), `quota_hit` (murs payants de CaseBuilder / Workspace, #1727) et `upgrade_click` (UpgradeCta / SubscribeButton, #1723/#1727) — ce ticket ajoute donc les deux étapes manquantes et la vue qui lit les cinq comme un seul entonnoir.
• Nouvel événement de taxonomie `activation` (`lib/analytics/events.ts`) : se déclenche une fois par compte au premier litige (voie Prévention, `components/CaseBuilder.tsx`) OU au premier dossier (voie Exécution, `components/workspace/Workspace.tsx`), chacun protégé par une clé localStorage propre au compte afin qu'une inscription enregistre exactement une activation. Nouveau nom de fil `ACTIVATION` ajouté à la liste blanche de `POST /api/growth/events`.
• Nouvel événement de taxonomie `conversion` : émis CÔTÉ SERVEUR par le webhook de facturation Stripe (`app/api/billing/webhook/route.ts`) via une insertion directe à rôle de service dans `growth_events` lorsqu'un événement `customer.subscription.created` arrive déjà en état `active`/`trialing` — il reflète donc de l'argent réellement déplacé, se déclenche une fois par abonnement (les renouvellements arrivent en invoice.paid / subscription.updated, qui n'atteignent jamais cette branche) et est dédupliqué par le registre d'idempotence #1728 en cas de reprise. À oublier après émission : une défaillance d'analytique ne se transforme jamais en 502 qui ferait retenter la réconciliation par Stripe.
• Nouvelle vue d'entonnoir pour l'administration : `GET /api/admin/conversion-funnel` (réservé fondateur/administrateur via le garde partagé `resolveOpsAdmin`, journalisé) agrège une fenêtre bornée de `growth_events` dans l'entonnoir à cinq étapes `CONVERSION_FUNNEL` (nouvelles primitives pures `conversionFunnel` + `tallyConversionCounts` dans `lib/analytics/funnel.ts`, qui désambiguïsent les fils partagés SURFACE_VIEW / CTA_CLICK par l'étiquette `taxonomy` de chaque ligne), présentée à `/[lang]/admin/conversion-funnel` (`components/admin/ConversionFunnel.tsx`) avec la conversion par étape, l'abandon, le taux global et le principal goulot d'étranglement — reprenant exactement le modèle de l'entonnoir de la visite guidée (#1678).
• Sans renseignements personnels partout (uniquement user_id + codes de forfait/voie/type, jamais de noms ni de texte d'histoire); à oublier après émission à chaque point d'émission. De nouveaux tests unitaires couvrent le calcul de l'entonnoir à cinq étapes et le comptage fil/taxonomie. Aucun changement de schéma ni de migration — la table `growth_events` existante est le puits.

Correctif (P1, sécurité) : réconcilier la migration de la clé du sélecteur Drive (#1120) derrière un unique indicateur opérateur pour que les branches concurrentes cessent de re-trancher la question (#1763).

• Renvoi croisé : la PR #1601 (v7.75.92) a clos #1120 en CONSERVANT volontairement le repli hérité `NEXT_PUBLIC_GOOGLE_API_KEY` dans `getDrivePickerConfig()` (avertir une fois, continuer de fonctionner) et a explicitement reporté la suppression définitive jusqu'à ce que l'opérateur confirme que chaque environnement dispose de la clé non publique `GOOGLE_PICKER_API_KEY`. Une branche sœur ultérieure a tenté de retirer ce repli sans condition — ce qui désactiverait silencieusement l'import Google Drive sur tout déploiement non encore migré (la configuration retourne `null`), sans aucune barrière de confirmation opérateur.
• Plutôt que de laisser deux branches re-trancher la même question de conception selon le côté du conflit de rebase que `git` conserve, la suppression passe désormais par un unique indicateur détenu par l'opérateur : `GOOGLE_PICKER_KEY_MIGRATED`. Par défaut (non défini), le comportement prudent de #1601 est préservé — le repli hérité résout encore, l'avertissement `console.warn` unique se déclenche — de sorte qu'aucun déploiement en production ne régresse. Lorsque l'opérateur définit `GOOGLE_PICKER_KEY_MIGRATED=1` (attestant que la migration des variables Vercel est terminée), `getDrivePickerConfig()` refuse entièrement le repli public ; seule la clé non publique `GOOGLE_PICKER_API_KEY` satisfait la barrière.
• `lib/ops/operator-action-queue.ts` (action de l'enjeu #58) nomme désormais l'étape `GOOGLE_PICKER_KEY_MIGRATED` dans sa liste `requires`, de sorte que la file d'actions de l'opérateur documente elle-même le basculement. De nouveaux tests unitaires dans `lib/__tests__/drive-picker-key.test.ts` et `lib/__tests__/release-readiness.test.ts` vérifient que le comportement par défaut garde Drive prêt avec la clé héritée et que l'indicateur bascule `getDrivePickerConfig()`/`trustReadinessServices().googleDrive` pour la refuser. Aucun changement de schéma/migration ; le comportement existant est inchangé jusqu'à ce que l'opérateur y consente.

Correctif (P2, expérience du justiciable) : la porte d'urgence de l'entrevue oriente désormais un justiciable réellement urgent vers des options concrètes le jour même plutôt que vers le répertoire d'exemples complet et un formulaire de contact asynchrone générique (#1739).

• Répondre « J'ai besoin d'aide juridique dans les 24 heures » à la porte de sécurité de l'entrevue n'offrait auparavant que deux culs-de-sac : un bouton « Communiquer » vers le répertoire COMPLET (en grande partie des profils exemples non encore réservables) et un lien « Contacter » vers le formulaire /contact asynchrone générique — une personne face à une éviction ou à une échéance le lendemain était donc dirigée vers des surfaces incapables de produire une aide à temps, puis invitée à poursuivre l'entrevue standard.
• La branche urgente affiche maintenant trois options concrètes plutôt que tout le répertoire : (1) les professionnels qui répondent le plus vite pour CETTE édition (nouveau `lib/intake/urgent-options.ts` `fastestResponseProviders()` — filtré par édition via `providerTypesFor()`, classé disponible-avant-limité puis par délai de réponse annoncé, chacun avec un lien direct vers SON propre profil), (2) la surface d'aide juridique d'urgence propre à l'édition (`/marketplace/legal-aid`, aide à tarif réduit ou modulé) et (3) un soutien accéléré (la route de contact signalée `?urgent=1` afin d'être priorisée).
• Cela reste honnête : aucun numéro de ligne d'urgence n'est inventé, l'avis 911 de sécurité de la vie reste épinglé en haut, chaque professionnel affiché porte sa disponibilité et son signal « répond en moins de N h », et les profils exemples sont étiquetés « Exemple — vérification en attente » (ils ne sont pas encore réservables selon la barrière partagée `isProfileBookable`) au lieu de laisser croire à une réservation en direct. Le répertoire complet et « poursuivre l'entrevue guidée » restent accessibles en liens secondaires.
• Nouvelle suite unitaire `lib/intake/__tests__/urgent-options.test.ts` fixant le contrat de routage (exclut les profils totalement indisponibles, filtrage par édition, ordre disponibilité-puis-délai-de-réponse, profils exemples signalés non réservables). Toutes les nouvelles chaînes destinées aux utilisateurs sont livrées en en/fr/es et typées. Aucun changement de schéma ni de migration.

Performance (P2, dette technique) : l'importation de preuves côté client calcule désormais l'empreinte SHA-256 en flux hors du fil principal et importe les fichiers dans un pipeline à parallélisme borné, au lieu de charger chaque fichier en mémoire et de téléverser strictement un à la fois (#1741).

• Les boucles d'importation de `components/workspace/Evidence.tsx` (`ingestFile`, `ingestDropped`) traitaient les fichiers strictement en série — `await hashFile` puis `await uploadEvidence` puis `await extractText`, un fichier à la fois — et `hashFile` appelait `file.arrayBuffer()`, chargeant l'intégralité du fichier (jusqu'à 100 Mo) en mémoire sur le fil principal juste pour en calculer l'empreinte. Le dépôt d'un dossier de gros PDF retenait donc de grands tampons et téléversait un à un, produisant de longues importations sans réponse et une pression mémoire sur les appareils modestes.
• Le nouveau `lib/evidence/sha256-incremental.ts` est un SHA-256 (FIPS 180-4) sans dépendance, calculé par tranches, identique octet pour octet au `crypto.subtle.digest` en une passe qu'il remplace — vérifié par rapport aux vecteurs du NIST et à Web Crypto pour des frontières de tranche arbitraires. `lib/evidence/hash-worker.ts` lit un fichier par tranches de 4 Mo et les lui transmet dans un Web Worker dédié, et `lib/evidence/hash-file-stream.ts` réutilise un seul worker pour tous les fichiers — l'empreinte ne charge donc jamais le fichier entier et ne bloque jamais le fil d'interface, avec un repli transparent par tranches sur le fil principal lorsqu'un Worker ne peut être créé (SSR, tests, environnements verrouillés).
• Le nouveau `mapLimit()` de `lib/util/concurrency.ts` exécute le pipeline téléversement+extraction par fichier au plus 4 fichiers à la fois tout en préservant l'ordre d'entrée, de sorte que les identifiants de preuve restent attribués de façon déterministe et que la détection des doublons octet pour octet lors des imports de dossiers demeure inchangée. `ingestDropped` calcule maintenant les empreintes puis déduplique en une passe à parallélisme borné, et téléverse+extrait les survivants dans une autre, remplaçant l'unique boucle strictement séquentielle.
• Nouvelles suites unitaires : `lib/evidence/__tests__/sha256-incremental.test.ts` (vecteurs du NIST, indépendance aux frontières de tranche, parité avec Web Crypto, bords de bourrage de 55/56/64 octets) et `lib/util/__tests__/concurrency.test.ts` (préservation de l'ordre, plafond de concurrence, échec immédiat). Aucun changement de schéma ni de migration; aucune chaîne visible ni changement de comportement.

Correctif (découverte de tests) : les répertoires de route [id] ne sautent plus silencieusement les tests en raison de l'interprétation glob (#1662).

• Déplacement de `app/api/deadlines/[id]/__tests__/patch-route.test.ts` vers l'emplacement frère `app/api/deadlines/__tests__/patch-route.test.ts` avec importation mise à jour (`../[id]/route`). Ceci restaure la couverture de test du gestionnaire PATCH, auparavant mort en CI parce que `node --test` effectue une correspondance glob sur ses arguments et interprète `[id]` comme une classe de caractères.
• Correction apportée à `scripts/run-tests.mjs` pour invoquer `node --test` une fois par fichier découvert au lieu de transmettre tous les fichiers comme une liste d'arguments unique. Ceci prévient l'interprétation glob et garantit que tous les tests avec chemin entre crochets s'exécutent, même s'ils sont placés sous des segments de route dynamique comme `[id]`, `[matterId]`, etc. Tous les tests découverts continuent à s'exécuter; aucun test n'a été ajouté ou supprimé.
• Modèle établi : les tests de route appartiennent à un répertoire `__tests__` comme frère du segment dynamique, et non imbriqué en dessous. Ce modèle (utilisé en #1532) est désormais garanti sûr contre les problèmes d'appariement glob.

Correctif (P3, i18n) : deux fragments anglais non traduits dans le dictionnaire français (#1745).

• marketplaceDir.profile.sourceGoogleMaps : espacement français corrigé en « Source : Google Maps » (était « Source: Google Maps »).
• commandCenter.surfaces.kinds.admin : traduit en « Admin / Exploitation » (était l'anglais « Admin / Ops »).

Correctif (BLOQUANT, vie privée / Loi 25) : l'expansion de l'export d'accès #1742 faisait confiance à la RLS seule pour cadrer chaque table sur le demandeur — certaines politiques comportaient des branches OR trop larges divulguant les lignes d'autrui (#1742).

• La revue de sécurité (CTO) de l'expansion #1742 (25 tables nouvellement exportées) a révélé que `exportSubjectData` (`lib/privacy/data-subject.ts`) exécutait un `subjectClient.from(table).select(columns)` non filtré par table, sans aucun cadrage applicatif, en s'appuyant entièrement sur la politique RLS SELECT en vigueur. Ceci est dangereux partout où une politique comporte une branche OR plus large que « cette ligne m'appartient » : la branche « tableau ouvert » de `marketplace_orders` (tout huissier vérifié) renvoyait chaque commande ouverte de la plateforme entière (noms de tiers dans `description`); la branche `is_admin()`/`is_marketplace_admin()` sur ~11 tables (`bailiff_profiles`, `professional_verifications`, `payout_accounts`, `payouts`, `class_actions`, `claimants`, `claimant_distributions`, `referrals`, `referral_codes`, `intake_requests`, `marketplace_entities`, `marketplace_engagements`, `commissioner_profiles`) faisait qu'une demande d'accès du founder_admin renvoyait des lignes quasi plateforme entière; et la branche d'annuaire public `status = 'published'` (`expert_profiles`, `provider_profiles`, `marketplace_entities`) incluait la fiche publique de chaque autre professionnel comme si c'était « la donnée propre du demandeur ».
• Chaque entrée `export` de `SUBJECT_SCOPED_TABLES` déclare maintenant un filtre de cadrage explicite que `exportSubjectData` applique avec `.eq()`/`.or()` EN PLUS de la lecture cadrée par RLS — sans plus jamais se fier au cadrage de la politique elle-même. La plupart des tables déclarent une seule colonne (`selfColumns: ["user_id"]`); les tables à deux parties combinent plusieurs colonnes propres par OR (`marketplace_orders` : client_id/assigned_to/offered_to; `referrals` : referrer_user_id/referred_user_id) afin d'inclure les propres lignes du sujet DES DEUX côtés, jamais les lignes visibles par le tableau ouvert ou par un administrateur.
• `affiliate_commissions` ne possède aucune colonne d'identifiant utilisateur littérale (elle n'est indexée que par `code`, une clé étrangère vers `affiliate_codes`). Plutôt que de retirer silencieusement cette table pourtant de première partie, elle résout maintenant le propre code du sujet via la table déjà cadrée `affiliate_codes`, puis filtre par ce code résolu — un sujet sans code d'affiliation obtient zéro ligne, jamais une lecture non filtrée.
• `lib/privacy/__tests__/access-registry.test.ts` comporte désormais une vérification structurelle exigeant que chaque entrée `export` déclare une stratégie de cadrage, ainsi que des tests avec données propres/tierces amorcées (filtrage réel au niveau des colonnes, non plus le simple gabarit structurel précédent) prouvant que `marketplace_orders`, `expert_profiles`, `bailiff_profiles`/`referrals` et `affiliate_commissions` excluent chacun la ligne de l'autre partie ou d'un autre utilisateur.
• Aucun changement de schéma ni de RLS : les politiques sous-jacentes restent intactes — ce correctif comble l'écart entre ce que la RLS *permet* à un appelant authentifié de voir et ce que l'export d'accès *divulgue* comme étant ses propres données personnelles.

Le Score de Justice™ évalue de nouveau les vrais dossiers : derive.ts/gaps.ts recâblés à la taxonomie v1.0 verrouillée (#1769).

• Le verrouillage de la spécification v1.0 (#1665) a renommé/regroupé/renuméroté les 16 dimensions du Score de Justice et déplacé chaque identifiant de critère vers la forme « d<n>-<axe> » (ex. « d6-C »), sans réutiliser aucun ancien identifiant « d<n>-c<n> ». Jusqu'ici, « lib/justice-score/derive.ts » émettait encore les anciens identifiants : AUCUNE de ses clés de sortie ne correspondait au modèle réconcilié — chaque vrai dossier obtenait honnêtement 0 / Non viable. Cette version recâble les 16 fonctions par dimension sur la nouvelle taxonomie D1-D16 pour que les dossiers retrouvent leur valeur réelle.
• Il s'agit d'une véritable re-dérivation, pas d'un simple renommage : le modèle verrouillé évalue chaque dimension sur les cinq axes (C/S/A/R/P), donc chaque fonction associe désormais les vrais champs de « LegalCase » au bon axe selon les dimensions fusionnées/déplacées/scindées (ex. l'ancien « Théorie de la cause » + « Fondement juridique » fusionnent en D1 ; « Témoins » passe en D13 ; « Argumentation adverse/réplique » se scinde entre D10/D11).
• D7 « Démonstration élément par élément » (la dimension la plus lourde, 100 points de base) dépend de la couche Enjeux et réclamations pas encore construite (spec §13) ; conformément au ticket, elle reste honnêtement à 0 sur chaque axe jusqu'à l'arrivée de cette couche — le tableau « issues » grossier n'est PAS utilisé à sa place (cela dédoublerait D6 et fabriquerait une carte de preuve au niveau des éléments).
• « gaps.ts » : « STRUCTURAL_GAP_CRITERIA » re-dérivé aux 29 critères v1.0 sans champ de schéma correspondant (contre 11 — la structure uniforme à 5 axes expose de nombreux signaux d'admissibilité/procédure manquants par dimension), et « GATE_LINKED_DIMENSION » remappé (G1→D4 Prescription, G2→D3 Compétence, G3→D6 Preuve documentaire).
• Comportement honnête « Prêt pour le tribunal est une promesse » : comme ~45 % du poids de base du modèle (dont tout D7) porte un critère de Résilience contradictoire non appuyé selon le schéma actuel, même un dossier parfaitement préparé se situe désormais dans « Substantiellement préparé » — sa part de résilience passe sous le plancher global de 0,60 et G6 le maintient sous le seuil Prêt pour le tribunal. Atteindre ce seuil relève d'un travail futur sur le schéma, documenté dans IMPLEMENTATION_1769.md, pas d'un correctif mécanique.
• Réécriture des dictionnaires « wsJusticeScore » (16 noms de dimension, 4 noms de pilier, 80 libellés de critère) et « wsJusticeScoreGaps » (80 chaînes d'action « faire ceci ensuite ») en anglais et en français vers la taxonomie v1.0 ; rafraîchissement des tests de bout en bout « derive.test.ts »/« gaps.test.ts » auparavant ignorés — toute la suite justice-score est verte, sans aucun test ignoré.

Fonctionnalité (#1612, voie rapide #70) : le panneau Témoins de l'espace de travail (côté serveur) est maintenant entièrement trilingue — la couverture espagnole complète la localisation de l'interface des témoins.

• Le panneau Témoins (registre, dossier, aveux, contradictions et questions de contre-interrogatoire) et sa bannière d'importation par lecture-relais n'étaient qu'en repli anglais pour l'espagnol. Chaque chaîne `wsWitnessesPanel` et `wsWitnessesMount` possède désormais une traduction `es` explicite : un justiciable en espagnol voit le panneau dans sa langue plutôt que des textes de remplacement anglais — ce qui relève le cliquet explicite-ES imposé par la vérification i18n.
• Aucun changement de serveur, de schéma, de RLS ni de paiement : le substrat GET/POST `/api/witnesses`, ses sous-routes `[id]/dossier|questions|contradictions` et le montage `WitnessesReadThrough` livrés plus tôt (#1619 fondation, #1617 montage) demeurent inchangés. Cette entrée clôt #1612 comme étape d'achèvement de la localisation, maintenant que le schéma de production (#1532) est appliqué.

Fonctionnalité (Fast-Track #70) : les vérifications de chronologie côté serveur sont maintenant reliées au panneau Faits sous forme de bloc Intégrité de la chronologie (#1615).

• Audit des trois surfaces de chronologie (directive du CTO, #1615) : `POST /api/ai/chronology` est orienté citations-client et déjà relié à `ChronologyGrid`, mais `GET /api/chronology/timeline` (lacunes probatoires) et `GET /api/chronology/contradictions` (même événement/dates différentes) étaient orphelines — aucun composant ne les appelait. Toutes deux lisent la table `facts` côté SERVEUR (les lignes qu'écrit `POST /api/facts` et que rend `FactsChronology`), et non le magasin `LegalCase` côté client que rend `ChronologyGrid`; les relier à la grille afficherait donc des données d'une autre source. Elles sont désormais montées dans `FactsChronology`, le panneau faisant autorité côté serveur.
• Décision — UN panneau, pas deux : les deux signaux sont des vérifications d'intégrité sur la même requête `facts` cadrée au dossier, partagent un seul cycle d'actualisation et répondent à une seule question (« cette chronologie tient-elle ? »). Le nouveau `components/workspace/chronology/TimelineIntegrity.tsx` interroge les deux routes, liste côte à côte les lacunes probatoires de 30 jours et plus ainsi que les contradictions de dates, et se relance chaque fois qu'un fait est ajouté ou que son indicateur « contesté » est basculé. Présenté comme des signaux à examiner, jamais des conclusions — rien dans le panneau ne modifie un fait.
• Aucun changement de schéma ni de migration; les deux routes existaient déjà. Nouvelles chaînes destinées à l'utilisateur ajoutées en en/fr/es avec couverture de types complète.

Correctif (P2, vie privée / Loi 25) : l'export d'accès de la personne concernée (droit d'accès) divulgue maintenant les données de PREMIÈRE PARTIE du demandeur dans toutes les tables dont la RLS est cadrée sur le sujet, et non seulement quatre (#1742).

• `GET /api/privacy/access` (via `lib/privacy/data-subject.ts`) n'assemblait que profiles, matters, service_orders et subscriptions — omettant silencieusement de nombreuses autres tables contenant les données personnelles du demandeur, chacune cadrée par RLS sur `auth.uid()` (disputes, portfolios, class_actions, claimants, claimant_distributions, intake_requests, professional_verifications, payout_accounts, payouts, marketplace_engagements, marketplace_orders, referrals, referral_codes, support_access_grants, reminder_preferences, erasure_requests, les profils fournisseur/expert/entité du sujet, ainsi que ses enregistrements d'affiliation et Copilot). La justification « les tables enfants peuvent contenir des RP de tiers » ne s'applique pas à ces lignes de première partie, de sorte que le droit d'accès de la Loi 25 renvoyait une image incomplète.
• Nouveau registre `SUBJECT_SCOPED_TABLES` dans `lib/privacy/data-subject.ts` qui classe CHAQUE table dont la RLS cadre les lignes directement sur le sujet dans exactement une catégorie : `export` (données personnelles sur le sujet → incluses avec une liste de colonnes précise, sans joker) ou `exclude` (cadrée par RLS mais pas les données propres du sujet — registres de tiers, messages de contreparties, courriels d'invités, substrat d'audit/sécurité ou fiches d'annuaire public — chacune avec une raison documentée). `ACCESS_TABLES` est désormais DÉRIVÉ du registre, de sorte que la surface d'export et la classification ne peuvent jamais diverger.
• La lecture s'effectue toujours exclusivement via le client de session du sujet cadré par RLS (aucune lecture avec le rôle de service), donc même une table exportée ne peut renvoyer que les propres lignes du sujet. Les colonnes sont sélectionnées table par table afin d'exclure les RP de tiers, le texte chiffré (p. ex. `payout_accounts.bank_details_enc`) et les coordonnées des MEMBRES d'un recours collectif (`claimants.full_name/email/province`).
• Nouveau test piloté par le registre `lib/privacy/__tests__/access-registry.test.ts` : il analyse chaque migration à la recherche des tables portant une politique RLS de première partie `<colonne-sujet> = auth.uid()` et échoue à fermeture si une telle table n'est pas classée — la surface de divulgation ne peut donc plus jamais sous-divulguer silencieusement. Il vérifie aussi que chaque table nommée par l'audit est exportée et que les RP des membres / le texte chiffré bancaire restent exclus.
• Aucun changement de schéma ni de RLS : il s'agit d'un correctif de complétude en lecture seule sur des tables existantes et leur sécurité au niveau des lignes déjà en place.

Correctif (P2, facturation) : les acheteurs ponctuels et les abonnés Copilot peuvent désormais ouvrir le portail de facturation en libre-service — il ne renvoie plus 404 pour quiconque a payé (#1738).

• `app/api/billing/portal` n'ouvrait le portail de facturation Stripe que s'il pouvait lire un `stripe_customer_id` sur la ligne `subscriptions` de l'appelant. Or les acheteurs ponctuels (`/api/ops/checkout`, `/api/service/checkout`, `mode: payment`) et les abonnés Copilot mesurés (`/api/copilot/checkout`, écrits dans `copilot_accounts`, jamais dans `subscriptions`) n'obtiennent aucune ligne d'abonnement — le portail renvoyait donc 404 (« aucun compte de facturation pour l'instant — abonnez-vous d'abord ») à des personnes qui avaient bel et bien payé, leur bloquant la gestion des cartes, le téléchargement des factures, l'annulation et la relance Stripe.
• Nouvelle table de correspondance `stripe_customers` (migration `0153_stripe_customer_link.sql`) : une ligne par utilisateur reliant `user_id → stripe_customer_id`, RLS en lecture de sa propre ligne uniquement (les écritures sont réservées au service-role/webhook, même schéma que `subscriptions` 0037 et `copilot_accounts` 0009). Le portail résout désormais le client de l'appelant à partir de SA ligne d'abonnement OU de cet index de repli, toujours filtré sur `user_id` de bout en bout, de sorte qu'un portail ne peut jamais être ouvert pour le client d'autrui.
• Les sessions de paiement ponctuel (`/api/ops/checkout`, `/api/service/checkout`) définissent maintenant `customer_creation: "always"` — le mode `payment` de Stripe ne crée autrement aucun objet Client (`if_required`), ne laissant rien à persister. Chaque webhook de paiement réussi (`app/api/service/webhook`) relie désormais le client de l'acheteur authentifié via le nouvel utilitaire `linkStripeCustomer()` (au mieux) : le chemin de commande de service ponctuelle et le chemin d'activation Copilot. Les commandes anonymes (sans propriétaire authentifié) sont ignorées — il n'y a aucun compte auquel rattacher un portail.
• Aucun changement à la logique de forfait/droits, aux portes de quota, à la tarification ni à aucune politique RLS existante; les abonnés continuent d'être résolus via `subscriptions` exactement comme avant. Ceci ne fait que combler le lien client manquant afin que le portail se résolve pour chaque acheteur ayant payé, et pas seulement pour les abonnés.

Dette technique (P1) : le moteur de préparation Score de justice™ — qui alimente l'anneau de score, les prochaines étapes suggérées par le copilote, la stratégie et l'admission — possède maintenant un verrou de régression à valeurs de référence pour qu'aucun changement de pondération ou de seuil ne puisse modifier en silence le score affiché à chaque utilisateur (#1736).

• La fonction de préparation sur le chemin critique `scoreMatter` (`lib/justice-score/derive.ts`, remplaçante du `justiceScore()` retiré) n'avait aucun test verrouillant sa sortie par dimension. Un changement à n'importe quelle pondération de dimension, plafond de porte ou seuil « Prêt pour la cour » pouvait déplacer en silence le score affiché à chaque justiciable et les prochaines étapes suggérées par le copilote, sans que rien dans l'intégration continue ne le détecte.
• Nouvelle suite de verrouillage à valeurs de référence (`lib/justice-score/__tests__/justice-score-golden.test.ts`) : elle évalue trois vrais gabarits `LegalCase` — un dossier vide, un dossier partiellement préparé et un dossier soigneusement préparé — de bout en bout via `scoreMatter`, et vérifie pour chacune des 16 dimensions les points obtenus et disponibles, le total sur 1000 points, le score brut, le plafond de porte / statut des portes critiques et la bande de préparation par rapport à un ensemble de référence vérifié à la main.
• Parce que l'ensemble de référence fixe les points disponibles renormalisés par dimension (la répartition des pondérations) et les seuils de profil, tout changement de verrouillage des pondérations (recoupant la porte de verrouillage des pondérations du fondateur #1673) ou tout réglage de porte/seuil doit désormais mettre à jour consciemment les valeurs de référence, transformant une dérive comportementale silencieuse en une différence de test visible et révisée.
• Changement limité aux tests : aucun effet sur le produit, la base de données, la RLS, la facturation ou le comportement visible par l'utilisateur.

Correctif (P1, expérience du justiciable) : le menu « Plus » de l'espace de travail est maintenant regroupé en quatre phases en langage clair, et les étapes du parcours guidé correspondent aux onglets qu'elles ouvrent (#1732).

• Le menu déroulant « Plus » unique et plat qui entassait environ 28 sections au jargon professionnel (Salle de guerre, Centre de résolution, Instances, Greffe, Recours, Exécution, Recouvrement, Cycle de vie, Commande, Journal des événements, Simulation, Bates…) en un seul mur d'étiquettes est désormais organisé en quatre phases — Bâtir le dossier / Résoudre / Cour / Exécuter — chacune accompagnée d'une description d'une ligne en langage clair.
• Les phases avancées restent masquées jusqu'à ce que le dossier les atteigne (la phase Cour apparaît une fois le pré-litige débloqué, Exécuter une fois le dossier entré dans les étapes d'audience/jugement). Il s'agit d'un guidage souple, jamais d'un verrou : un bouton « Afficher les sections avancées » révèle toujours tout, et la phase contenant la section active n'est jamais masquée.
• Les libellés d'onglets suivent désormais le vocabulaire du parcours guidé : l'onglet « Chronologie » et l'onglet « Judiciarisation » se lisent de façon identique à l'étape correspondante.
• Lorsqu'une étape du parcours pointe vers une section située dans « Plus », l'onglet « Plus » nomme désormais la section active (p. ex. « Plus · Judiciarisation ») au lieu de faire sauter l'indicateur actif sur un simple « Plus ».
• Les deux étapes du Centre de résolution sont désormais distinguées par des descriptions en langage clair (étape 0 « Situation » = nommez votre différend et choisissez une voie; étape 5 « Résolution » = suivez les étapes pour régler avant le tribunal), affichées en infobulles et dans le nom accessible.

Ops (infrastructure) : Repo Guardian — patrouille automatisée de santé du dépôt avec orchestration des vérifications de santé et intégration GitHub (#1254).

• Nouveau `lib/ops/repo-guardian.ts` — module central orchestrant les vérifications de santé du dépôt et formatant les résultats en commentaires de problème GitHub. Exporte les interfaces typées pour les résultats de vérification de santé (`HealthCheckResult`), la logique d'agrégation (`aggregateHealthStatus`), et le formatage rapport-vers-commentaire (`formatHealthReportAsComment`). Les utilitaires d'horodatage gèrent la conversion UTC pour les en-têtes de commentaires de problème.
• Nouveau script de démarrage de patrouille `scripts/run-repo-guardian.mjs` exécutant la suite complète des vérifications de santé locales (npm ci, tsc, npm test, check:locales, check:i18n-gap, check:version-advances, check:trust-gaps, check:edition-purity, npm build) et affichant les résultats horodatés au problème GitHub #1254. Prend en charge `--dry-run` (affichage au lieu d'envoi) et `--no-pr-triage` (saute l'analyse des relations publiques). La variable d'environnement `SKIP_BUILD=1` permet de sauter gracieusement les vérifications de compilation quand les secrets ne sont pas disponibles.
• Nouvelle suite de test `lib/ops/__tests__/repo-guardian.test.ts` couvrant la logique d'agrégation (agrégation du statut au pire cas), le formatage d'horodatage, et le formatage de commentaire pour les rapports VERT/JAUNE/ROUGE avec sections optionnelles de triage des PR et problème déposé. Les 10 tests passent.
• Cette PR prépare l'infrastructure pour la première exécution de patrouille en CI/CD ou un travail cron — le script lui-même n'est pas encore planifié (aucun changement `.github/workflows/` — le jeton de l'agent n'a pas la portée `workflow`, donc le CTO câblera l'horaire dans un suivi).

Correctif (P2, sécurité/Loi 25) : les points d'entrée d'analytique pouvaient être inondés et bourrés de RP sans authentification, et le compteur public de croissance dévoilait des chiffres exacts en temps réel (#1744).

• `POST /api/growth/events` et `POST /api/presence` écrivent via le client Supabase à rôle de service (qui contourne le RLS) et sont accessibles sans session — volontairement, puisque la télémétrie anonyme de pages vues/CTA/présence est un trafic légitime. Avant ce correctif, aucune des deux routes n'avait de limiteur de débit, contrairement à la route sœur `POST /api/activity` (#1551), qui enveloppe déjà sa propre insertion à rôle de service dans un `SlidingWindowRateLimiter` par IP précisément parce qu'elle contourne le RLS. Les deux routes appliquent maintenant la même limite de 60 requêtes/minute par IP, renvoyant `429 { ok: false, error: "rate_limited" }` une fois dépassée.
• `growth/events` enregistrait aussi l'objet `metadata` du client tel quel dans la colonne jsonb conservée `growth_events.metadata` — un appelant non authentifié pouvait y insérer n'importe quelle clé, y compris des renseignements personnels en texte libre, dans une ligne conservée indéfiniment. Le nouveau `lib/analytics/metadata-guard.ts` et sa fonction `sanitizeGrowthMetadata()` réduisent `metadata` au sous-ensemble en liste blanche, uniquement composé de valeurs primitives et de taille plafonnée, que chaque émetteur réel de ce dépôt envoie réellement (l'enveloppe typée de la taxonomie, les champs de défilement/session/CTA de `GrowthTracker.tsx`, et le signal du tour guidé) — les clés inconnues, les objets/tableaux imbriqués et les nombres non finis sont rejetés plutôt qu'enregistrés.
• `GET /api/public/stats` renvoyait des comptes de lignes exacts et non authentifiés (profils, dossiers, preuves, procédures, commandes de service/assermentées/d'huissier, professionnels vérifiés) avec une mise en cache de 60 secondes, permettant à quiconque de sonder l'appel et d'observer la croissance de la plateforme progresser en temps quasi réel — un vecteur trivial d'énumération/de renseignement concurrentiel, sans plancher. Chaque compte divulgué est désormais arrondi par bande : arrondi vers le bas au multiple de 25 le plus proche, et tout chiffre sous 10 est rapporté comme 0 plutôt qu'un petit nombre exact.
• Nouveaux tests : tests de rafale de limitation de débit pour les deux routes (même convention que `app/api/feedback/route.ts`), une suite unitaire pour le garde-fou de métadonnées (`lib/analytics/__tests__/metadata-guard.test.ts`) couvrant la liste blanche, les plafonds de taille et la forme du signal du tour guidé, ainsi qu'un test unitaire de `band()` et un test de forme de route pour `public/stats`. Suite complète au vert; aucun changement de schéma ni de migration.

Correctif (P1, sécurité financière) : le webhook Stripe de facturation rejette maintenant les événements en double et hors séquence au lieu de les retraiter ou d'écraser un état d'abonnement plus récent (#1728).

• Stripe livre les événements de webhook au moins une fois et sans garantie d'ordre. `app/api/billing/webhook/route.ts` n'avait aucune protection contre l'un ou l'autre : un événement redélivré pouvait être retraité entièrement, et un événement en retard (p. ex. un `customer.subscription.deleted` retardé) pouvait écraser une ligne d'abonnement qu'un événement subséquent, plus récent, avait déjà mise à jour vers `active`.
• Nouveau registre d'idempotence `stripe_webhook_events` (migration `0152_stripe_webhook_idempotency.sql`) : l'`event.id` propre à Stripe est la clé primaire, donc une redélivrance d'un événement déjà réclamé échoue à l'insertion (`unique_violation`) et est accusée réception (`{ received: true, duplicate: true }`) sans retraitement — aucune course lecture-puis-vérification, puisque la clé primaire rend la réclamation atomique même sous des livraisons concurrentes.
• Nouvelle fonction de base de données `apply_ordered_subscription_upsert()` remplace le simple `.upsert()` sur `subscriptions` : elle effectue l'insertion-ou-mise-à-jour ET la comparaison « cet événement est-il plus récent que ce qui est déjà appliqué? » (`subscriptions.last_event_created_at`, nouvelle colonne nullable) dans une seule instruction atomique `INSERT ... ON CONFLICT ... WHERE`, de sorte qu'un événement périmé ou hors séquence ne peut jamais écraser une ligne avec un événement plus ancien que celui déjà appliqué.
• Si le traitement d'un événement réclamé échoue (p. ex. une erreur de base de données transitoire), le webhook libère la réclamation d'idempotence avant de retourner son 502 — la reprise automatique de Stripe pour ce même événement est donc traitée comme nouvelle, plutôt que d'être silencieusement avalée comme un « doublon » permanent.
• Aucun changement à la logique de forfait/droits, aux portes de quota 402, ni à aucune politique RLS existante sur `subscriptions` (0037/0148/0151) — ceci ferme uniquement la protection d'idempotence/ordre manquante sur la façon dont les événements atteignent la table.

Correctif (moteur de litige, Justice Score™ v1.0) : le moteur calcule désormais exactement ce que la spécification VERROUILLÉE du fondateur affirme, et non plus l'ébauche provisoire v0.1 sur laquelle il a été livré (#1665).

• lib/justice-score/model.ts : chaque dimension comporte désormais exactement 5 critères — un par axe (Complétude, Étayage, Recevabilité, Résilience, Conformité procédurale) — conformément à la formule verrouillée elle-même (Score = Σ_dimensions [ Poids_dim × Σ_axes ( poids_axe × score_axe ) ] / 1000). Cela a exigé d'adopter la véritable taxonomie à 16 dimensions de la spécification verrouillée (dimensions renommées/regroupées, p. ex. la prescription déplacée dans le Volet I, la préparation des témoins dans le Volet III, plus un nouveau D7 « Étayage élément par élément ») plutôt qu'une simple renumérotation — l'ancienne couverture d'axes sur mesure par dimension ne pouvait pas reproduire exactement les cas limites verrouillés (le cas « maximum partout = 100 » de verify.js exige que chaque dimension puisse atteindre 100 % sur chaque axe).
• Poids globaux des axes corrigés aux valeurs verrouillées C 250 / S 260 / A 120 / R 255 / P 115 (sur 1000) — la sous-pondération de la Recevabilité (était 80) est corrigée; la répartition poids-axe/mode de notation (binaire pour C/A/P, en 5 paliers pour S/R) est désormais une donnée explicite sur Axis.gradingMode.
• Le Volet III est renommé « Défense et réplique » (était « Test contradictoire » — l'ancien nom entrait en collision avec le nom de l'axe Résilience lui-même); les 4 volets sont renommés pour correspondre à la spécification verrouillée (Fondement juridique / Preuve / Défense et réplique / Machinerie procédurale).
• lib/justice-score/gates.ts : le plafond G1 « manifestement prescrit » est resserré de 25 à 15; le G3 (élément non prouvé) est resserré de 65 à 55; le G6 (le plancher de l'axe R) fait désormais partie de l'ensemble des portes CRITIQUES (G1, G2, G3, G4, G6) selon la spécification verrouillée, et non plus seulement un verrou au niveau des bandes.
• lib/justice-score/bands.ts : les bandes de score pures sont resserrées aux valeurs verrouillées « Non entamé 0-24 / En cours 25-49 / Étayé 50-(seuil-1) » (était 0-39/40-64/65-…).
• lib/justice-score/profiles.ts : seul le régime TAL (Tribunal administratif du logement) repondère désormais une dimension — les multiplicateurs de dimension sur mesure de l'ébauche pour Petites créances/Cour du Québec/Cour supérieure sont retirés selon le verrouillage. Le plancher de l'axe R est une constante globale unique de 0,60 pour chaque forum (variait auparavant par régime). Le plafond de réclamation de la Cour du Québec est corrigé à 99 999,99 $ (le G2 ne plafonne qu'à partir de 100 000 $).
• Nouveau lib/justice-score/__tests__/golden-v1.test.ts fait passer le moteur de PRODUCTION réel par chacun des cas limites verrouillés du fondateur (docs/plan/justice-score/verify.js, 23/23) — le jumeau en code du harnais de référence canonique.
• La dérivation des critères à partir des dossiers réels (derive.ts, T4) et ses dépendants (dashboard-view.ts/gaps.ts, T5/T6) utilisent encore l'ancienne taxonomie d'identifiants de critères et ne sont pas encore reconnectés à la nouvelle — chaque dossier réel obtient honnêtement un score de 0 jusqu'à ce que ce suivi soit livré (suivi sous #1769); cette PR ne touche pas la notation destinée aux justiciables, seulement le moteur de référence et ses propres tests.

Correctif (P1, conversion du mur payant) : une personne au forfait gratuit qui atteignait une limite ne voyait que du texte, sans issue — la dernière pièce de l'entonnoir de facturation se referme (#1727).

• Le 402 structuré (lib/billing/paywall.ts, #1697) était une impasse aux deux endroits où une vraie personne le rencontre aujourd'hui : la vérification de limite de litiges de components/CaseBuilder.tsx, et le 402 de limite de dossiers de app/api/matters/sync (atteint via le repli de route de session de lib/store/remote.ts lorsqu'une insertion RLS directe est refusée). Les deux affichaient un message bilingue sans aucun moyen d'agir sur le signal `upgradeRequired: true` déjà envoyé par le serveur. (STORAGE_QUOTA_EXCEEDED de app/api/matters/ingest et le 402 de app/api/disputes/[id]/convert n'ont actuellement aucun appelant côté interface, donc il n'y avait aucune impasse réelle à corriger là — laissés intacts, aucune logique serveur modifiée nulle part.)
• Nouveau composant partagé `components/billing/UpgradeCta.tsx` — le SEUL bouton d'appel à l'action « passer à un forfait » que chaque mur payant affiche : un simple lien vers la vraie section Abonnement (`/[locale]/pricing#subscribe`, #1723) qui déclenche le MÊME événement analytique `upgrade_click` que `SubscribeButton`, marqué selon quelle limite (dossier / litige / stockage) a provoqué le clic.
• Nouvel événement analytique `quota_hit` (lib/analytics/events.ts), réutilisant le nom de fil existant `SURFACE_VIEW` (même précédent que `pricing_view`/`marketplace_view`) — aucune modification de la liste blanche growth-events nécessaire. Se déclenche au moment où un mur de limite est réellement affiché, de sorte que `quota_hit` → `upgrade_click` → abonnement actif forme désormais un seul entonnoir mesurable.
• `components/CaseBuilder.tsx` : la vérification préalable de limite de litiges ET le filet de sécurité du déclencheur BD (dispute_quota_exceeded, l'application infranchissable) déclenchent désormais tous deux `quota_hit` et affichent le bouton — la vérification préalable est le chemin courant, le filet de sécurité le repli en cas de course ou d'absence d'utilisateur, et les deux sont de véritables moments de limite atteinte à mesurer.
• `lib/store/remote.ts` reçoit un code distinct `MATTER_QUOTA_EXCEEDED`, classé à partir du MÊME 402 que app/api/matters/sync renvoie déjà (aucun changement côté serveur) — avant cela, une personne au forfait gratuit ayant atteint la limite de dossiers était reclassée sous `MATTER_SYNC_PERMISSION_DENIED`, le même message qu'un vrai refus RLS/sécurité, masquant le mur payant derrière une erreur sans rapport apparent. Le bandeau d'échec de sauvegarde de `components/workspace/Workspace.tsx` reconnaît maintenant ce code, affiche son propre message bilingue, déclenche `quota_hit` et affiche le bouton — sans jamais déclencher le mur de session expirée/reconnexion qu'un vrai refus provoque.

Le Justice Score™ v1.0 est maintenant verrouillé : les 7 décisions ouvertes du fondateur sur les pondérations et seuils sont tranchées, et le test étalon est vert (#1672, referme le verrou de pondération #1673).

• Le modèle de préparation Justice Score™ (épopée #1664) a livré son moteur (T1–T6) ainsi que le retrait/passerelle de l'ancien score à 7 dimensions (T7) par rapport aux pondérations provisoires v0.1, chaque chiffre étant explicitement provisoire en attendant l'aval du fondateur au verrou de pondération (#1673). Le fondateur a maintenant ajusté en direct dans l'explorateur interactif et répondu aux 7 décisions du §12 — l'équilibre des piliers, les seuils Cour-Prête par tribunal (Petites Créances 78 / Cour du Québec 82 / Cour supérieure 86 / TAL 76, base 80), les plafonds de portes (G2 50, G3 55, G4 60, G5 70, plus les plafonds hors-porte G1 clair/discutable 15/55), la pondération de l'axe Complétude (25 %), le statut du TAL comme 4e profil de juridiction, une notation en 5 paliers (et non binaire) des critères, et la nomenclature des axes/dimensions/piliers/portes — fermant le modèle pour de bon.
• `docs/plan/justice-score/SPEC-v1.0.md` est la nouvelle spécification canonique (remplace les chiffres provisoires de SPEC-v0.1.md par le modèle v1.0 verrouillé : 16 dimensions × 5 axes — Complétude 250 / Substantiation 260 / Admissibilité 120 / Résilience 255 / Conformité procédurale 115 — plafonnés par 6 portes éliminatoires). `docs/plan/justice-score/explorer.html` est le nouvel explorateur compagnon verrouillé du fondateur (successeur du justice-score-explorer.html de l'ère provisoire, conservé pour l'historique). `docs/plan/justice-score/verify.js` est le nouveau harnais de régression étalon, câblé via `npm run check:justice-score` — il vérifie les invariants limites que le moteur (#1665) doit reproduire exactement : toutes les dimensions au maximum donne 100,0, la complétude seule donne 25,0, une prise en charge initiale (Complétude + Conformité procédurale seulement) donne 36,5, la pondération des dimensions de chaque profil de juridiction se renormalise exactement à 1000, chaque porte critique plafonne le score final à son plafond peu importe le total brut, et le plancher de Résilience bloque le statut Cour-Prête même quand le score brut dépasse le seuil du tribunal. Les 23 assertions passent.
• Changement documentaire uniquement (aucun code moteur touché ici — il a déjà été livré dans #1665–#1671 par rapport aux valeurs par défaut v0.1, qui ont maintenant une cible v1.0 verrouillée à vérifier). `IMPLEMENTATION_1672.md` à la racine du dépôt documente le relais pour le mainteneur qui câblera `check:justice-score` dans la matrice CI (omis de cette PR puisque le jeton de l'agent n'a pas la portée `workflow`).

Correctif (P0, amorçage de la facturation) : un utilisateur ne pouvait démarrer un abonnement nulle part dans l'application, et le seul bouton de mise à niveau câblé n'enregistrait ses achats nulle part (#1723).

• `/api/billing/checkout` — la VRAIE route de paiement que le webhook de facturation et les droits d'accès comprennent (et qui, depuis #1722, peut vendre tous les paliers) — n'avait aucun appelant en dehors d'un commentaire de code. `/pricing` était entièrement statique (chaque bouton de plan était un `<Link>` vers l'inscription ou un mailto), et le seul bouton de mise à niveau cliquable de toute l'application (`components/workspace/LitigationOps.tsx`) appelait un point de terminaison fantôme différent, `/api/workspace/checkout`, avec des identifiants de plan (`case-builder`, `self-rep-unlimited`) qui n'existent dans aucun catalogue de facturation, dont les métadonnées Stripe ne comportaient pas `kind: "billing-subscription"` — le webhook de facturation rejetait donc silencieusement chaque achat complété. Un paiement pouvait réussir chez Stripe alors que la plateforme ne l'enregistrait nulle part.
• Nouveau `components/pricing/SubscribeButton.tsx` — le SEUL vrai contrôle « démarrer un abonnement ». Envoie `{ plan, locale }` par POST à `/api/billing/checkout` avec un vrai `BillingPlanId` (lib/billing/plans.ts) et redirige vers l'URL de session Stripe Checkout retournée. Gère avec grâce chaque réponse non-2xx documentée au lieu de planter : le 401 redirige vers l'inscription sur le même site (reprenant le pattern existant de ReferralPanel/Header), le 403 `STRIPE_NOT_ALLOWED` (le garde-fou d'activation Stripe du ROK, #1714 — comportement correct en SAFE_MODE, pas un bogue) affiche un message calme « pas encore disponible », et tout autre refus affiche la raison propre de la route.
• `/pricing` obtient une nouvelle section d'abonnement réelle (`#subscribe`) qui affiche le vrai catalogue vendable (`planCatalog()`, filtré par édition — `professional` uniquement sur l'édition américaine, `trustee-practice` uniquement sur CA/QC) avec un `SubscribeButton` par plan. Les anciennes cartes de plan à visée marketing de la page (Starter/Resolution Plus/Case Builder…, Solo/Cabinet/Entreprise) décrivent un modèle de tarification ponctuel/à crédits différent qui n'a jamais été appuyé par un identifiant de prix Stripe réel dans le catalogue de facturation — réorienter leurs boutons mailto/Link existants vers le paiement d'abonnement aurait silencieusement câblé le mauvais prix au mauvais produit ; ils restent donc tels quels, tout comme les boutons gratuit/contact.
• La carte de mise à niveau de `components/workspace/LitigationOps.tsx` est redirigée du point de terminaison fantôme vers un simple lien vers la nouvelle section `/pricing#subscribe` (ses anciens identifiants de plan `case-builder`/`self-rep-unlimited` ne correspondaient à aucun plan ou prix de facturation réel, donc y substituer silencieusement un vrai identifiant de plan aurait faussé le montant facturé).
• `app/api/workspace/checkout/route.ts` est RETIRÉ définitivement (supprimé, pas redirigé) — confirmé par grep qu'il n'avait qu'un seul appelant, maintenant redirigé. `lib/control-plane/activation-inventory.ts` (le rapport de verrouillage pré-activation du ROK, #1747) et son test épinglé retirent la route du tableau des routes de service enregistrées et du constat « routes Stripe non protégées », maintenant VIDE — #1755 (ci-dessous) avait déjà comblé l'écart service/ops/copilot, et ce correctif comble le dernier écart restant en supprimant la route définitivement. L'entrée de la liste d'exemption d'audit pour le fichier supprimé dans `lib/settings/__tests__/gating-coverage.test.ts` est retirée.
• Nouvel événement analytique `upgrade_click` (lib/analytics/events.ts) se déclenche à l'instant où l'on appuie sur S'abonner, avant que la requête POST de paiement ne se résolve, en réutilisant le nom de fil existant `CTA_CLICK` (même précédent que `cta_click`/`service_view`) afin que la liste blanche des événements de croissance n'ait besoin d'aucune nouvelle entrée. Volontairement minimal — le volet 402 du mur payant de cet entonnoir relève de la portée de #1727, pas de celle-ci.
• `components/workspace/Workspace.tsx` reconnaît maintenant aussi la redirection de succès `?billing=subscribed` du vrai paiement avec un message éclair de confirmation — contrairement au gestionnaire hérité `?upgrade=success`, il ne définit pas de façon optimiste un identifiant de plan mis en cache côté client, puisque le webhook Stripe est la seule autorité qui écrit la ligne `subscriptions`.

Correctif (P0, sécurité d'activation) : le garde-fou d'activation Stripe couvre désormais toutes les vraies routes de paiement, pas seulement billing/checkout (#1755).

• Le rapport de verrouillage pré-activation de la Phase 2.5 du ROK (#1747) avait révélé que `assertStripeAllowed()` — l'invariant strict exigeant que tout effet de bord Stripe requière l'état ∈ {LIMITED_PROD, FULL_PROD} ET stripe.enabled ET l'interrupteur d'urgence désactivé — n'était câblé que dans `app/api/billing/checkout/route.ts`. `app/api/service/checkout`, `app/api/ops/checkout` et `app/api/copilot/checkout` appelaient chacun directement `stripe.checkout.sessions.create` : le SAFE_MODE et l'interrupteur d'urgence du fondateur n'avaient donc aucun effet sur eux — tout environnement avec une clé Stripe active pouvait encore créer de vraies sessions de paiement par ces trois routes, peu importe l'état du plan de contrôle.
• Les trois routes appellent désormais `assertStripeAllowed()` (importé de `lib/control-plane/guards.ts`) avant leur appel à `stripe.checkout.sessions.create` et renvoient exactement la même forme structurée `403 { error, code: "STRIPE_NOT_ALLOWED", reason }` que billing/checkout renvoyait déjà en cas de refus. Chacune enregistre aussi désormais `stripe.activation.triggered` via `recordStripeActivationTriggered` de `lib/control-plane/writer.ts` lors d'une création de session réussie, le même appel au bus d'événements prévu par le fondateur que fait billing/checkout. `app/api/workspace/checkout` restait délibérément non protégée ici — c'était le point de terminaison fantôme/divergent retiré définitivement par les travaux distincts de mise à feu de la facturation (#1723, ci-dessus).
• `lib/control-plane/activation-inventory.ts` (le modèle de données du rapport de verrouillage pré-activation lui-même) est mis à jour pour refléter la réalité : les routes service/ops/copilot passent de `gatedBy: null` à `gatedBy: "stripe"`, l'arête combinée non protégée se scinde en une arête protégée (service/ops/copilot) et une arête toujours non protégée (workspace seulement), et `WIRED_CONSUMERS.stripe` liste les quatre routes protégées — le rapport à l'origine de ce correctif ne signale donc plus son propre constat comme toujours ouvert. La nouvelle suite invariante de source `lib/control-plane/__tests__/checkout-guard-coverage.test.ts` vérifie, pour chaque vraie route de paiement, que le garde-fou est importé, vérifié strictement avant l'appel Stripe, et refuse avec le code stable `STRIPE_NOT_ALLOWED` — plus une assertion fixant que workspace/checkout reste délibérément non protégée. (Note : #1723, ci-dessus, supprime ensuite cette route définitivement et met à jour l'assertion fixée de cette suite en conséquence.)

Correctif : les deux paliers de facturation les plus élevés (Professionnel, Pratique de syndic) ne pouvaient jamais être vendus réellement — une écriture de webhook Stripe pour l'un ou l'autre échouait silencieusement, indéfiniment (#1722).

• `subscriptions` (migration 0037) est la source de vérité confirmée dans laquelle le webhook de facturation (app/api/billing/webhook/route.ts) inscrit chaque événement d'abonnement Stripe réel, et la migration 0148 avait déjà étendu owner_has_active_paid_plan() pour la lire pour les paliers grand public 'pro'/'premium' — cette partie était déjà correcte. Mais la contrainte CHECK de `subscriptions.plan` n'avait jamais été élargie au-delà de ('free','pro','premium'), même si lib/billing/plans.ts's BILLING_PLAN_ORDER — le seul filtre du webhook — répertoriait déjà 'professional' et 'trustee-practice' comme identifiants de plan réels. Un événement d'abonnement réel pour l'un ou l'autre palier supérieur violait la contrainte, l'écriture échouait, le webhook renvoyait son 502 générique, et Stripe retentait indéfiniment le même événement en échec : le paiement pouvait réussir chez Stripe alors que notre propre ligne `subscriptions` correspondante ne pouvait jamais être écrite.
• La nouvelle migration 0151 élargit la contrainte `subscriptions_plan_check` pour autoriser aussi 'professional' et 'trustee-practice', et remplace (create-or-replace) owner_has_active_paid_plan() afin que sa branche OR sur `subscriptions` reconnaisse les quatre paliers payants au lieu de deux seulement — logique par ailleurs identique, `professional_subscriptions` (0121) et les points d'application par déclencheur de base de données (0141/0142) restent inchangés.
• Additif et idempotent (suppression-si-existante puis ajout sur la contrainte, create-or-replace sur la fonction) — aucune table, déclencheur ou ligne existante n'est touché. De nouveaux tests d'invariant source (lib/monetization/__tests__/top-tier-entitlement.test.ts) vérifient directement le texte de la contrainte et de la fonction élargies, plus un test unitaire pur de l'ensemble des plans couvrant les lignes actives/expirées/annulées pour les quatre paliers payants.

L'espace de travail a enfin un bouton Aide — un point d'entrée persistant « ? » vers le Centre de soutien, le Centre de recherche, le contact direct avec le fondateur et la visite guidée (#1731).

• Nouveau bouton « ? » / Aide dans la barre d'outils de l'espace de travail (à côté de Paramètres), toujours visible — y compris en mode local (sans back-end), pas seulement pour les sessions connectées. Ouvre une petite boîte de dialogue HelpPanel (components/workspace/HelpPanel.tsx) avec trois liens vers des surfaces réelles et existantes : le Centre de soutien (/support), le Centre de recherche juridique (/research) et un mailto direct vers le fondateur — aucune nouvelle route ni nouveau back-end n'a été créé.
• Lorsque la visite guidée dans l'application est activée (NEXT_PUBLIC_GUIDED_TOUR_APP), le panneau d'aide propose aussi « Revoir la visite », en réutilisant exactement le même point d'entrée lib/guided-tour/tour-bus.ts que le bouton de navigation existant plutôt que de dupliquer le câblage — il n'existe toujours qu'une seule façon de demander à AppGuidedTour de s'ouvrir.
• Parité d'accessibilité complète avec le reste de la famille de boîtes de dialogue modales de l'espace de travail (idiome de ConfirmDeleteMatterDialog.tsx) : role="dialog", focus piégé via lib/a11y/focus-trap.ts, Échap et clic sur l'arrière-plan ferment tous deux la boîte, focus restauré vers l'élément déclencheur à la fermeture.
• Tout le nouveau texte est entièrement bilingue (en/fr) plus espagnol, typé dans dictionaries/types.ts sous AppDict.wsShell.

Accessibilité : les fenêtres modales de l'espace de travail piègent maintenant réellement le focus (#1734).

• Plusieurs fenêtres et tiroirs — le clavardage du Copilote IA, « Poser une question », la liste des dossiers, l'écran d'accueil de première utilisation, les confirmations de fermeture de dossier et d'armement d'échéance, le tiroir Services juridiques, la visionneuse de pièces, et trois tiroirs d'édition du centre de commande du fondateur — déclaraient aria-modal="true" sans jamais réellement piéger le focus, gérer la touche Échap, ni restaurer le focus à la fermeture. Un utilisateur du clavier ou d'un lecteur d'écran pouvait tabuler directement hors d'une « fenêtre modale » vers la page en arrière-plan, ce qui va à l'encontre du principe même d'une fenêtre modale (WCAG 2.4.3 Ordre du focus / modèle ARIA APG de fenêtre modale).
• Chacune de ces fenêtres réutilise maintenant l'utilitaire existant lib/a11y/focus-trap.ts (le même procédé déjà éprouvé par la confirmation de suppression de dossier) : le focus se déplace dans la fenêtre à l'ouverture, Tab/Maj+Tab est contenu à l'intérieur, Échap la ferme, et le focus est restauré vers l'élément qui l'avait déclenchée à sa fermeture.
• GuidedTour.tsx implémentait déjà un piégeage équivalent de son cru et n'a pas été modifié. Il s'agit d'un correctif purement comportemental — aucun changement visuel ou de texte, et prefers-reduced-motion n'est pas concerné puisqu'aucune nouvelle animation n'a été introduite.

Correction d'une régression d'URL canonique : les profils d'experts, les guides, la page urgence et partenaires fondateurs disparaissaient de l'index Google (#1733, P1).

• Cause racine : le `generateMetadata` de plusieurs pages publiques ne retournait pas de champ `alternates`. La résolution des métadonnées de Next.js traite un `alternates` manquant comme « hériter du layout parent » plutôt que « aucun canonique » — chacune de ces pages annonçait donc silencieusement la page d'accueil (`/${locale}`) comme sa propre URL canonique, indiquant à Google de retirer la page de l'index au profit de la page d'accueil. Il s'agit du même mode de défaillance que le #1541, réapparu sur des routes ajoutées après le déploiement de ce correctif sans en reprendre le patron.
• Correction de toutes les routes de la place de marché des experts (`/experts`, le carrefour `/experts/[discipline]`, le profil `/experts/[discipline]/[expertId]`, `/experts/devenir-expert`, `/experts/devenir-expert/apply`), de l'index des guides (`/guides`), de `/emergency`, et de `/founding-partners` (l'alias `/partenaires-fondateurs` avait déjà le correctif — la route anglaise principale ne l'avait jamais reçu) pour intégrer `pageAlternates(locale, path)` de lib/seo.ts dans leurs métadonnées, donnant à chaque page un canonique auto-référentiel plus les alternates hreflang complets pour chaque locale/édition.
• `/experts/devenir-expert/apply` n'avait aucun `generateMetadata` (pas même un titre) — elle en a désormais un.
• Un audit plus large du dépôt a révélé des dizaines de pages statiques plus anciennes (à propos, contact, presse, juridictions, etc.) présentant la même lacune ; celles-ci sont à plus faible trafic et sont laissées pour un balayage de suivi dédié afin de garder ce correctif P1 circonscrit à la fuite signalée.

Correctif : l'espagnol n'est plus présenté comme « autorité » alors qu'environ 91 % de l'interface s'affichait silencieusement en anglais (#1724, P0).

• `dictionaries/es.ts` correspond à `deepMerge(en, esPartial)`, et la surcouche espagnole `dictionaries/partials/es.ts` ne rédige explicitement qu'environ 9 % des valeurs du dictionnaire — le reste retombe silencieusement sur l'anglais. L'espagnol figurait néanmoins dans `authoritativeLocales` (lib/i18n-config.ts) aux côtés du français et de l'anglais, et contrairement à l'arabe, au chinois et au portugais, il était absent de `machineTranslationLocales` (lib/i18n/translation-engine.ts) : components/MachineTranslationBanner n'affichait donc aucun avis de traduction pour les visiteurs hispanophones — une page majoritairement anglaise présentée comme une page espagnole finalisée et faisant autorité.
• L'espagnol est retiré de `authoritativeLocales` et ajouté à `machineTranslationLocales`, en reproduisant exactement le câblage de l'arabe, du chinois, du portugais, de l'italien, de l'allemand, de l'hébreu et du pendjabi. L'espagnol affiche désormais le même bandeau honnête « traduction automatique (bêta) » que ces langues — le texte existait déjà dans `MACHINE.es` (lib/i18n/language-notices.ts) mais n'était jamais atteint car le drapeau « autorité » court-circuitait l'affichage.
• Aucun contenu du dictionnaire n'a été supprimé : `dictionaries/partials/es.ts` et son cliquet de couverture explicite (scripts/check-i18n-gap.ts) sont inchangés, et l'espagnol conserve une couverture résolue à 100 % grâce au repli FR/EN — seul l'avis présenté au lecteur change. Le blocage de mise en production « l'espagnol fait autorité » dans `scripts/check-release-blockers.mjs` est corrigé pour vérifier l'inverse (non autorité, dans l'ensemble de traduction automatique), afin d'empêcher toute régression silencieuse; réautoriser l'espagnol exigera de rehausser délibérément sa couverture explicite et de mettre à jour ce blocage en conséquence.

ROK phase 2.5 : un rapport de verrouillage pré-activation en lecture seule montre exactement ce qui peut s'exécuter en production dès maintenant, avant que le plan de contrôle ne soit jamais activé (#1747).

• Un nouveau lib/control-plane/activation-inventory.ts pur assemble un inventaire en trois parties : la surface d'API d'écriture externe enregistrée (facturation/Stripe, analytique de croissance/présence, tâches cron, routes de persistance IA), une cartographie de propagation d'événements source → destination, et — pour chaque indicateur ROK déclaré — si son véritable prédicat de garde (importé de lib/control-plane/guards.ts, jamais réimplémenté) permet son déclenchement selon un état fourni, ainsi que les routes qui câblent réellement cette garde. Aucune E/S, testé unitairement avec 11 cas node:test incluant la barre d'acceptation : rien de lié aux revenus n'est déclenchable en mode SAFE_MODE.
• L'audit a révélé un véritable écart à connaître avant que l'URL du pooler Supabase ne soit câblée : seul app/api/billing/checkout est câblé à assertStripeAllowed() — /api/service/checkout, /api/ops/checkout, /api/workspace/checkout et /api/copilot/checkout appellent chacun directement stripe.checkout.sessions.create et se déclencheront selon leurs propres conditions préalables, indépendamment de l'état du plan de contrôle. Séparément, les indicateurs analytics et justice_engine n'ont actuellement aucun consommateur câblé (growth/events, presence et chaque route de persistance ai/* écrivent sans condition aujourd'hui) — basculer l'un ou l'autre de ces indicateurs dès maintenant ne changerait aucun comportement d'exécution.
• Nouveau GET /api/admin/activation-lock-report en lecture seule, contrôlé par la même vérification resolveOpsAdmin() que chaque route du Centre de commande (#1105), et une nouvelle page autonome app/[lang]/admin/activation-lock-report (miroir exact de admin/control-plane) qui affiche le rapport via un nouveau ActivationLockReportPanel.tsx. Cette route et cette page n'effectuent AUCUNE écriture vers system_control_state/system_control_events, aucun appel Stripe et aucune migration — la fonctionnalité entière est en LECTURE SEULE par construction.

Conformité PNDAJ : la navigation de l'espace de travail ne présente plus le Copilote IA comme « obtenir des conseils » (#1718).

• La navigation de l'espace de travail comportait un seul élément — « Obtenir des conseils » / « Get legal guidance » — dont le clic ouvrait le tiroir de clavardage du Copilote IA. Présenter une fonctionnalité d'IA comme donnant des « conseils » est un risque de pratique non autorisée du droit (PNDAJ) : cela laisse croire que la plateforme dispense des conseils juridiques, alors que ses propres avis de non-responsabilité précisent qu'elle fournit uniquement de l'information juridique générale.
• Séparation en un modèle clair à 3 volets. Volet 1 (services juridiques humains / place de marché) : l'élément est renommé « Trouver un avocat » / « Find an attorney » et pointe désormais directement vers la véritable route de la place de marché des avocats (`/[lang]/attorneys`), en réutilisant la clé de dictionnaire `findAnAttorney` déjà utilisée par le tiroir Services juridiques pour la même destination. Volet 2 (couche d'information par IA) : un nouvel élément de navigation « Obtenir de l'information » / « Get information » ouvre le même tiroir de clavardage Copilote que l'ancien élément ouvrait, désormais correctement présenté comme un outil d'information, conforme au texte de l'avis « information juridique générale ». Volet 3 (ressources statiques) : Ressources juridiques, Services juridiques et tous les autres éléments de navigation demeurent inchangés.
• La clé de dictionnaire désormais inutilisée `getLegalGuidance` (fr/en/types) est retirée purement et simplement — une recherche exhaustive dans le dépôt a confirmé un seul site d'appel. Un nouveau texte espagnol explicite a été ajouté pour les deux libellés dans dictionaries/partials/es.ts (`findAnAttorney`, `getLegalInformation`) plutôt que de s'appuyer sur le repli vers l'anglais.

La suppression d'un dossier obtient une vraie boîte de confirmation et ne fige plus la page pendant 2,3 secondes (#1715, signalé par le fondateur).

• Le menu débordant de la carte de dossier de l'accueil de l'espace de travail supprimait un dossier sans aucune confirmation — un simple mauvais clic détruisait définitivement un dossier. Une nouvelle ConfirmDeleteMatterDialog (components/workspace/ConfirmDeleteMatterDialog.tsx) encadre désormais chaque suppression de dossier unique : elle nomme le dossier, indique clairement que la suppression est permanente et le retire à la fois de cet appareil et de l'infonuagique, et exige un clic explicite sur Annuler ou Supprimer. Elle remplace le confirm() natif du navigateur — non stylisé et non traduisible — auquel ce parcours retombait auparavant.
• La boîte de dialogue est conçue pour rester sûre au clavier pour une action destructrice : son ouverture déplace le focus vers Annuler — jamais vers Supprimer — de sorte qu'une touche Entrée accidentelle juste après l'ouverture ne peut qu'annuler ; atteindre Supprimer exige une tabulation délibérée ou un clic direct. Échap annule, Tab/Maj-Tab sont contenues à l'intérieur de la boîte de dialogue (réutilisant lib/a11y/focus-trap.ts, le même motif que OutboundLink.tsx / GrowthTracker.tsx), le focus est restauré sur l'élément déclencheur à la fermeture, et aucune animation d'entrée n'est utilisée, donc il n'y a rien à désactiver pour prefers-reduced-motion.
• Par ailleurs, la suppression d'un dossier figeait la page pendant un INP mesuré de 2 314 ms : deleteMatterFromHome de Workspace.tsx exécutait `saveCases(loadCases().filter(...))` — une lecture, un analyse, un filtrage, une re-sérialisation et une écriture SYNCHRONES de TOUT le magasin local de dossiers, preuves comprises — avant même de mettre à jour la liste affichée à l'écran. La mise à jour de l'état en mémoire (setCases/setStrandedLocal) s'exécute désormais D'ABORD, de sorte que la carte disparaît dans le rendu en cours, et l'écriture lourde du magasin est différée via un nouveau scheduleIdleWrite (lib/workspace/idle-write.ts) : il s'exécute via requestIdleCallback lorsque disponible, retombe sur une macrotâche (setTimeout) ailleurs, et force une écriture synchrone sur pagehide/visibilitychange afin qu'un utilisateur qui supprime puis quitte immédiatement ne perde jamais l'écriture.
• Le verrou de gel légal et la logique de branchement dossier-orphelin-vs-synchronisé ont été extraits, sans changement de comportement, dans un lib/workspace/matter-delete.ts pur (planMatterDeletion) afin d'être testés unitairement avec node:test — un dossier sous gel est toujours refusé (Workspace.tsx conserve le blocage existant alert(t.deleteBlockedByHold)), et la recherche de repli sur tout le magasin ne s'exécute que si le dossier n'est pas déjà en mémoire, la même paresse qu'auparavant. La zone de danger distincte « supprimer TOUS les dossiers » à confirmation par saisie (Paramètres, Workspace.tsx) demeure inchangée.

Noyau d'orchestration des mises en production (ROK), phase 1 : un plan de contrôle en temps réel découple le déploiement du code de l'activation du système — une machine à états globale, des indicateurs de fonctionnalités déclaratifs, une garde d'activation Stripe stricte, l'isolation du moteur de justice et un interrupteur d'arrêt d'urgence pour le fondateur (#1714, épopée).

• La nouvelle migration 0150 ajoute `system_control_state` (une ligne singleton contenant l'état global en direct — INIT/SAFE_MODE/STAGED/LIMITED_PROD/FULL_PROD/EMERGENCY_LOCKDOWN — plus le JSON des indicateurs déclaratifs par sous-système et l'interrupteur d'arrêt d'urgence) et `system_control_events` (piste d'audit en ajout seul, lecture admin/écriture service, immuable par déclencheur), reprenant le contrat de flux d'événements durable d'exec_event_log (0140) plutôt que d'inventer un nouveau bus. Par défaut : SAFE_MODE, tous les indicateurs sur DÉSACTIVÉ sauf l'analytique — une base sans changement fonctionnel, puisque Stripe n'est de toute façon pas encore en production réelle.
• Nouveau noyau lib/control-plane/ : une machine à états pure et exhaustivement testée (`canTransition` — EMERGENCY_LOCKDOWN toujours atteignable depuis n'importe quel état; le confinement ne se rétablit QUE vers SAFE_MODE; la progression avant/arrière se fait par étapes, sans sauter d'étape; INIT n'est jamais réintégré), un lecteur mis en cache et à sécurité intégrée (`getControlState`), les prédicats de garde (`isStripeAllowed`/`assertStripeAllowed`, `isPaywallEnforced`, `isKillSwitchOn`, `isEnabled`, `isJusticeEngineWriteAllowed` — chacun avec un jumeau pur basé sur une ligne pour des tests sans E/S), et l'unique rédacteur (`transitionState`/`updateFlag`/`engageKillSwitch`/`disengageKillSwitch`) qui valide chaque changement avant de le persister et d'ajouter un événement d'audit.
• L'invariant strict : `assertStripeAllowed()` retourne autorisé seulement lorsque l'état ∈ {LIMITED_PROD, FULL_PROD} ET stripe.enabled ET !kill_switch — branché comme véritable point de contrôle dans app/api/billing/checkout/route.ts (une nouvelle session de paiement est une véritable activation Stripe) avant `stripe.checkout.sessions.create`, renvoyant un 403 structuré en cas de refus et enregistrant `stripe.activation.triggered` en cas de succès. Le portail de facturation (libre-service pour la clientèle existante) et la route de webhook (réconciliation entrante des événements déjà émis par Stripe) sont délibérément laissés NON protégés — signalé explicitement dans IMPLEMENTATION_1714.md pour révision architecte/DTO, puisque désactiver la nouvelle activation par l'interrupteur ne doit jamais bloquer un client payant existant.
• Isolation du moteur de justice (spécification du fondateur : le moteur de score/analytique de justice ne doit JAMAIS lire l'état de facturation/tarification/application) : un test CI invariant de source vérifie que lib/store/cases.ts (justiceScore() aujourd'hui) et lib/strategy.ts n'importent jamais lib/billing/* ni lib/control-plane/*, PLUS une recherche par motif compatible avec l'avenir sur tout futur module lib/justice-score/**/lib/justice-analytics/** — y compris le socle de données Justice Analytics qui a atterri dans la même fenêtre (#1708, migration 0149) — de sorte que la garde s'applique déjà à celui-ci.
• Le branchement du mur de paiement résout explicitement la tension SAFE_MODE contre déclencheur de base de données : le nouveau lib/billing/quota-gate-server.ts, `checkQuotaGated` (utilisé par app/api/matters/sync et lib/litigation/dispute-conversion.ts — jamais components/CaseBuilder.tsx, un composant « use client » qui casserait s'il importait le lecteur à rôle de service) saute entièrement la pré-vérification côté application lorsque `paywall.enabled` est faux (le défaut SAFE_MODE). Il s'agit d'un changement SANS impact fonctionnel : les déclencheurs de base de données 0141/0142 sont totalement intacts et traduisent toujours une insertion rejetée par le MÊME 402 structuré dans les deux cas — le « aucune application » de SAFE_MODE ne gouvernait jamais que l'optimisation, jamais le véritable plancher.
• Nouveau panneau de contrôle du fondateur app/[lang]/admin/control-plane + sa route API GET/POST /api/admin/control-plane, protégée par la même vérification resolveOpsAdmin() que toute autre route du centre de commande (#1105) : état actuel + transitions valides suivantes, chaque indicateur avec ses commutateurs (mode/pourcentage de déploiement Stripe, mur de paiement, moteur de justice activé/mode écriture, analytique), un interrupteur d'arrêt d'urgence à confirmation obligatoire, et le flux des événements récents du plan de contrôle. Chaque écriture est validée par le rédacteur du noyau et doublement auditée (system_control_events pour le flux propre au domaine, admin_audit_log via logAdminAction pour « qui a fait cela »).

Justice Analytics™ P1 : le socle de données à confidentialité séparée pour le module d'analyse d'équité — consenti, uniquement agrégé; AUCUNE sortie de disparité n'est livrée ici, toujours soumise aux révisions statistique et juridique (#1708, ADR-0006, épopée #1703).

• Selon l'ADR-0006 §3/§4 (docs/adr/0006-justice-analytics-design-and-safeguards.md), la nouvelle migration 0149 ajoute six tables : `demographic_profiles` (volontaire, consentie, données personnelles de catégorie spéciale — origine ethnique, statut autochtone, statut de handicap, statut d'immigration, tranche de revenu, langue, chacune nullable indépendamment pour un consentement par champ) ne porte AUCUNE clé étrangère vers une table d'identité ou de dossier; le SEUL lien est `demographic_consent_links` (propriétaire + référence de cas optionnelle), et LES DEUX tables sont en RLS deny-all — aucune politique pour anon ou authenticated, pas même pour la propre session de l'utilisateur consentant.
• `case_outcomes` est en RLS circonscrite au dossier (can_access_matter/can_edit_matter, identique à toute autre table enfant de dossier) et porte les six variables de contrôle de l'ADR-0006 §2 dont un futur calcul d'équité aurait besoin (gravité de l'accusation, antécédents, entente sur plaidoyer, type de représentation, juridiction via la référence au tribunal/service policier, attribution du juge/tribunal) plus les champs de résultat — aucune colonne démographique, aucune clé étrangère vers l'une ou l'autre table démographique. `judge_profiles`/`police_profiles`/`court_profiles` sont des squelettes de référence d'entités publiques (RLS en lecture publique, écriture admin) sans colonne d'équité ou de disparité pour l'instant.
• Nouvelle couche d'accès lib/justice-analytics/ : une passerelle de k-anonymat pure (k-anonymity-gate.ts, MIN_CELL_SIZE=30 selon l'ADR-0006 §2 — plus stricte que les précédents existants MIN_COHORT=10/#466 et k=5/#1458 qu'elle prolonge) qui supprime entièrement toute cohorte sous le seuil, jamais une valeur partielle; les fonctions d'écriture/lecture-propre/révocation de consent.ts effectuent leur propre vérification explicite de propriété sur demographic_consent_links.owner_id avant de renvoyer une ligne (les tables deny-all n'ont aucune politique RLS sur laquelle s'appuyer); readDemographicAggregate() d'aggregate.ts est la seule fonction autorisée à lire à travers plusieurs profils consentis, avec une jointure éphémère en mémoire (jamais persistée) et ne renvoyant que des paires k-anonymisées {cohortValue, cellSize}.
• AUCUN code de disparité/équité/notation n'existe dans ce PR (vérifié par grep, documenté dans IMPLEMENTATION_1708.md) — aucun indice de disparité, aucun ajustement par régression, aucun intervalle de confiance, aucune table fairness_metrics/disparity_scores/review_packages, aucun câblage d'agent IA. Ceux-ci relèvent de P2 (#1709) et P3/P4 (#1710/#1711), toujours soumis aux révisions de méthodologie statistique (#1704) et juridique/diffamation (#1706). Les six nouvelles tables sont enregistrées dans lib/security/rls-table-registry.ts; le harnais d'audit RLS à l'échelle du dépôt (403 assertions) et 30 nouveaux tests unitaires de la couche d'accès passent, y compris des preuves qu'une lecture/révocation de consentement d'un utilisateur ne peut jamais toucher la ligne d'un autre utilisateur.

Le mur de paiement freemium s'applique désormais réellement : la création de dossier et la conversion litige→dossier renvoient un signal de mise à niveau structuré au plafond gratuit, et un abonné payant réel n'est jamais bloqué (#1697, ADR-0005 §3, épopée #100).

• Les primitives de quota de lib/billing/entitlements.ts (matterQuota/disputeQuota/hasQuotaRemaining) avaient été codées à la phase 1 mais n'étaient appelées par aucune route — les plafonds du palier gratuit (1 dossier / 25 litiges) n'étaient appliqués QUE par des déclencheurs de base de données (0141/0142), qui renvoyaient une exception brute, pas une réponse exploitable. Les nouveaux modules lib/billing/quota-gate.ts + lib/billing/subscription-state.ts branchent ces primitives dans une pré-vérification côté application qui lit le VRAI abonnement grand public de l'appelant LUI-MÊME (la table `subscriptions`, alimentée par le webhook Stripe) ainsi que son propre décompte de dossiers/litiges — jamais une lecture inter-utilisateurs.
• Le nouveau lib/billing/paywall.ts est la réponse structurée unique que chaque point de contact renvoie désormais au plafond : `{ ok:false, error:"quota_exceeded", code, quota:{used,limit}, upgradeRequired:true, message }`, HTTP 402. Branché dans app/api/matters/sync (création de dossier), lib/litigation/dispute-conversion.ts + app/api/disputes/[id]/convert (le RPC de conversion litige→dossier — le véritable point de contact du mur de paiement selon l'ADR-0005 §3, qui retombait auparavant sur un 500 générique), et une pré-vérification côté client à effort raisonnable dans components/CaseBuilder.tsx (création de litige, qui n'a pas de route serveur — le déclencheur de base de données demeure l'application réelle à cet endroit).
• Correction d'un véritable bug « l'utilisateur payant se fait bloquer » que ce câblage aurait autrement introduit : la fonction owner_has_active_paid_plan() du déclencheur de base de données ne reconnaissait que `professional_subscriptions` (un abonnement de publicité de la place de marché distinct, #1454), jamais la véritable table `subscriptions` Gratuit/Pro/Premium grand public que les vérifications de quota de ce ticket consultent. La nouvelle migration 0148 étend cette fonction avec une clause OR reconnaissant une ligne d'abonnement pro/premium active — refermant le TODO que la migration 0141 s'était laissé. Un véritable abonné payant est désormais illimité à la fois lors de la pré-vérification applicative ET du filet de sécurité en base de données, jamais un seul des deux.
• Chaque pré-vérification échoue OUVERTE en cas d'erreur de lecture et n'est qu'une optimisation d'expérience utilisateur, jamais le seul verrou : les déclencheurs de base de données (disputes_quota_guard, matters_quota_guard) demeurent l'application faisant autorité et impossible à contourner, puisque les insertions de litiges circulent sous la propre session RLS de l'appelant et que les insertions de dossiers s'exécutent sous le client à rôle de service. De nouveaux tests couvrent le mur de paiement au plafond, le succès sous le plafond, un véritable abonnement payant résolu comme illimité (et l'omission de la lecture du décompte), un abonnement expiré retombant au palier gratuit, et le fait que chaque requête de décompte est explicitement circonscrite à l'appelant.

Justice Analytics™ P0 : le document de conception (ADR) d'un moteur d'observabilité des disparités et de l'équité — rien n'est déployé avant l'aval statistique, la conformité et la revue juridique (#1707, épopée #1703).

• Il s'agit d'un engagement de conception, uniquement documentaire, pour le produit le plus à risque de la plateforme : une disparité mesurable des issues existe-t-elle pour un tribunal, un juge, un procureur ou un service de police, APRÈS avoir contrôlé les variables qui expliquent légitimement les différences d'issues? Le nouveau docs/adr/0006-justice-analytics-design-and-safeguards.md énonce d'abord le garde-fou non négociable : ce module n'attribue jamais à une personne ou à une institution une étiquette de racisme, de partialité ou de discrimination, et n'affirme jamais d'intention. Chaque résultat prend une forme fixe et unique — une disparité résiduelle statistiquement significative, son niveau de confiance, les contrôles appliqués, la taille de l'échantillon et une divulgation obligatoire des limites — avec une liste de formulations interdites appliquée par le même détecteur de garde-fous de sortie (§29.19) que toute autre capacité IA de la plateforme emprunte déjà. « Les agents IA fournissent des preuves, pas des conclusions » est structurel, non pas simplement énoncé : les cinq agents proposés (analyse des issues, détection de biais, audit d'équité, génération de dossier de révision, corrélation jurisprudentielle) transitent tous par la couche d'orchestration existante §29.23, avec requiresHumanApproval:true et aucune capacité verbe interdite.
• La proposition de méthodologie statistique — soumise à la revue par les pairs en statistique du fondateur (jalon #1704) pour confirmation ou modification — définit l'indice de disparité comme l'écart d'issue réel moins l'écart attendu après contrôles (gravité de l'accusation, antécédents, entente sur plaidoyer, type de représentation, juridiction, juge assigné), recommande l'ajustement par régression logistique/linéaire comme méthode principale (l'appariement par score de propension servant uniquement de vérification complémentaire de robustesse), un seuil de confiance de 95 %, une correction du taux de fausses découvertes de Benjamini-Hochberg pour les tests simultanés par entité et — élément critique — une taille d'échantillon minimale en deçà de laquelle rien n'est jamais rapportable (n ≥ 30 par cellule de cohorte, n ≥ 100 cas au total avant qu'une disparité pour une entité nommée soit rapportable), prolongeant exactement le principe déjà déployé « données insuffisantes, jamais un chiffre » de lib/analytics/cohort-gate.ts (#466) et lib/matching/outcome-aggregates.ts (#1458) — deux précédents explicitement moins à risque que ce module doit dépasser. Un exemple chiffré montre une disparité brute de 18 points qui s'explique entièrement après contrôles pour devenir un résidu non significatif de 1 point, à reproduire comme donnée de test synthétique à la phase P2.
• L'architecture de confidentialité — pour le jalon de conformité (#1705) — prévoit que demographic_profiles repose sur un consentement volontaire, explicite et par champ, sans clé étrangère directe vers l'identité des dossiers publics, jointe à case_outcomes uniquement de façon éphémère à l'intérieur d'une tâche d'agrégation à rôle de service qui ne persiste jamais la ligne jointe, et lisible uniquement en agrégat derrière le seuil minimal de cellule ci-dessus. Le consentement est révocable, la conservation est liée au consentement actif plus une période de grâce, et le droit américain sur la protection de la vie privée par État ainsi que la Loi 25 sont tous deux abordés pour ce déploiement d'abord américain, empaquetable par juridiction.
• Le modèle de données (conception seulement, aucune migration dans cette PR) sépare demographic_profiles/demographic_consent_links (isolé pour la confidentialité, accessible uniquement au rôle de service) de case_outcomes/judge_profiles/police_profiles/court_profiles/fairness_metrics/disparity_scores/review_packages (calculable publiquement, agrégat seulement). Le générateur de dossier de révision est conçu pour les organismes de surveillance (Conseil de la magistrature du Québec, Conseil canadien de la magistrature, commissions de déontologie policière, commissions des droits de la personne, ombudsmans) — présenté à l'utilisateur soumissionnaire ou à l'organisme de surveillance, jamais publié — pour la revue du jalon juridique (#1706).
• Le plan par phases intègre les trois jalons humains comme conditions préalables explicites à chaque phase, et non de simples aspirations au niveau de l'épopée : P1 (#1708, modèle de données) requiert le jalon de confidentialité; P2 (#1709, moteur d'équité) requiert le jalon statistique; P3 (#1710, analytique judiciaire et policière — la première surface nommant une entité) requiert la fermeture des TROIS jalons avant qu'aucun code puisse être fusionné; P4 (#1711, dossiers de révision) requiert le jalon juridique appliqué spécifiquement au gabarit du dossier. Trois décisions du fondateur ou d'experts sont soulevées, non tranchées : quel réviseur externe en statistique engager, si les résultats sont réservés aux utilisateurs vérifiés/soumissions d'organismes de surveillance ou à un accès agrégé plus large, et quels États américains cibler pour la v1.

L'ancrage RAG couvre désormais les téléversements réels de preuves, sans altérer le chemin inutilisé de la table documents — et les lignes miroir restent invisibles pour la facturation et les vues destinées aux justiciables (#1687, suite de #1638).

• #1638 avait corrigé le chemin de la table `documents` de la tâche cron d'auto-indexation §29.22, mais une recherche exhaustive du dépôt n'a trouvé aucun appelant navigateur pour cette route : les téléversements réels passent plutôt par le flux de téléversement de preuves, qui stocke le texte extrait dans le JSON `matters.data.documents`, un entrepôt que la tâche cron ne lisait jamais. Le rappel Copilot et la rédaction IA ancrée RAG citaient donc toujours zéro texte de document réel.
• La tâche cron d'auto-indexation §29.22 (app/api/cron/ai-index) exécute désormais d'abord une nouvelle étape de mise en miroir de l'entrepôt de preuves : elle balaie les dossiers à la recherche de documents de preuve dont le texte extrait n'est pas vide et met chacun en miroir dans une ligne de la table `documents`, avec pour clé l'identifiant propre du document de preuve. Le pipeline de réconciliation/indexation préexistant et INCHANGÉ récupère ensuite cette ligne dès son prochain passage, exactement comme n'importe quel autre document — aucun code de découpage/vectorisation/recherche n'a été modifié, si bien que toutes les garanties RLS et de portée par dossier déjà en place s'appliquent identiquement aux fragments issus des preuves.
• Déduplication/idempotence : une ligne miroir n'est (ré)écrite que lorsque son texte est nouveau ou a changé depuis le dernier miroir — un document inchangé est ignoré purement et simplement (aucune écriture, aucun `updated_at` mis à jour), ce qui empêche précisément la vérification de fraîcheur existante de revectoriser un document à chaque passage. Nouveaux modules lib/ai/retrieval/evidence-mirror.ts (sélection/comparaison pure) et evidence-reconcile.ts (exécuteur à E/S injectées), tous deux testés unitairement; un test de bout en bout prouve que le texte de preuve devient une véritable ligne `ai_document_chunks` interrogeable et qu'un second passage sur des données inchangées ne met rien en miroir ni ne revectorise rien.
• La revue de l'architecte a relevé que `documents` n'est PAS une table inutilisée — la facturation (quota de stockage des preuves), la vue des preuves destinée au justiciable, le registre des pièces exporté, l'assemblage des productions judiciaires et le point de terminaison de statut de miroir sur disque lisent/agrègent tous des lignes de `documents` sans savoir qu'une ligne miroir pourrait exister. La nouvelle migration 0147 ajoute `documents.is_index_mirror boolean not null default false`, mis à `true` uniquement sur les lignes mises en miroir; ces six consommateurs excluent désormais explicitement `is_index_mirror = true` (une ligne miroir ne peut plus jamais gonfler le stockage facturé, apparaître comme un document fantôme, ni être produite dans un dépôt judiciaire), tandis que les deux points d'entrée de l'indexeur (le balayage propre de cette tâche cron, et la route à la demande POST /api/ai/retrieval/index) n'appliquent aucun tel filtre, si bien que les lignes miroir sont indexées exactement comme les lignes natives.
• Tolérance aux pannes : une erreur de mise en miroir des preuves est isolée par document et ne bloque jamais la réconciliation préexistante de la table `documents` qui s'exécute immédiatement après.

Visite guidée, phase 4 : le flux TourEvent est maintenant persisté dans sa propre table, alimentant une vue d'entonnoir Command Center + un échafaudage de cohorte de déploiement graduel (#1678, épopée #1674).

• Ajout de la migration 0146_guided_tour_events.sql : une table append-only guided_tour_events capturant le flux typé TourEvent (opened/step_viewed/advanced/back/skipped/completed/cta_clicked), la variante, l'index d'étape, un identifiant de session anonyme généré côté client, une cohorte témoin/traitement dérivée côté serveur, et l'identifiant utilisateur optionnel s'il est connecté. Le RLS reprend EXACTEMENT le précédent existant pour la télémétrie anonyme (growth_events/0024, telemetry_events/0019) : le RLS est activé sans AUCUNE politique d'insertion ou de lecture pour les rôles anon ou authenticated — chaque écriture passe par la nouvelle route POST /api/guided-tour/events sur le client à rôle de service après validation, et la seule politique est une lecture réservée aux administrateurs (reprend les tables op_* de 0068). C'est délibérément plus strict qu'une politique RLS brute « insertion anonyme », qui permettrait à la clé publique anon d'écrire directement dans la table depuis l'extérieur de l'application.
• La route de capture dérive la cohorte CÔTÉ SERVEUR à partir de l'identifiant de session fourni par le client (lib/guided-tour/cohort.ts, un hachage FNV-1a déterministe réparti à ~50/50) plutôt que de faire confiance à une valeur fournie par le client, afin qu'elle ne puisse être falsifiée et reste reproductible pour audit. components/guided-tour/analytics.ts a reçu un second signal additif vers cette route (le signal growth_events existant depuis #1675 reste inchangé) — best-effort via sendBeacon/fetch-keepalive, encapsulé dans des try/catch, afin qu'un échec de capture ne puisse jamais briser l'interface de la visite. Réutilise LA MÊME clé de session sessionStorage que GrowthTracker.tsx écrit déjà, afin que les événements de visite et le reste de l'entonnoir de croissance partagent un identifiant de session pour de futures jointures.
• Nouvelle vue Command Center sur /admin/guided-tour (app/[lang]/admin/guided-tour/page.tsx + components/admin/GuidedTourFunnel.tsx), protégée par exactement la même passerelle administrateur partagée que chaque autre route Command Center (resolveOpsAdmin() de lib/ops/admin-gate.ts, à l'identique de /api/admin/ai-eval et /api/admin/campaigns) via une nouvelle route GET /api/admin/guided-tour-funnel. Affiche le taux de complétion par variante, le p50 du temps dans la visite (global et par variante), la répartition des points d'abandon (quelle étape est la plus abandonnée), et une répartition du taux de complétion par cohorte. Une page autonome plutôt qu'un nouvel onglet CommandShell, puisque les sept onglets existants de cette liste sont câblés via leurs propres tests d'accessibilité/de coquille dédiés, et qu'en ajouter un huitième serait un changement transversal plus lourd que ce rapport en lecture seule ne le justifie. Liée depuis les actions rapides du tableau de bord du fondateur (components/admin/CommandCenter.tsx).
• Tout le calcul d'agrégation (computeTourFunnel de lib/guided-tour/tour-funnel.ts) est une fonction pure, sans dépendance, sur les lignes d'événements brutes — aucun import Supabase — donc entièrement testée unitairement (lib/guided-tour/__tests__/tour-funnel.test.ts, lib/guided-tour/__tests__/cohort.test.ts) sans base de données : taux de complétion par session distincte, temps médian dans la visite avec appariement des ouvertures dupliquées/rejouées, départage des égalités des points d'abandon, et le déterminisme + l'équilibre ~50/50 de la répartition de cohorte sur un large échantillon synthétique.
• Note de portée : la répartition par cohorte est un ÉCHAFAUDAGE de déploiement uniquement — elle rapporte des compteurs bruts de complétion par lot, pas un gain validé statistiquement. Les deux métriques de succès restantes de l'épopée (gain d'inscriptions sur la page d'accueil vs témoin, gain de premier dossier en 24 h dans l'app) nécessitent un calcul de gain causal dédié une fois un volume suffisant accumulé ; délibérément différé et documenté comme suivi dans IMPLEMENTATION_1678.md plutôt que construit ici.

Indicateur d'accord humain-IA pour la boucle d'auto-amélioration de la chronologie, dans le volet Centre de commande du moteur d'évaluation (#1651).

• Extension de GET /api/admin/ai-eval (la route Centre de commande du moteur d'évaluation §29.20) avec un nouveau champ `factFeedback` : un rapport d'accord humain-IA (sur toute la période et sur les 30 derniers jours) calculé à partir des lignes `ai_fact_feedback` (#1648/#1691) — par champ de chronologie (event / factProven / narrative) et globalement, le taux d'acceptation telle quelle, le taux de modification, le taux de rejet, et la similarité moyenne des lignes modifiées. C'est l'indicateur de qualité de rédaction IA demandé par le président : à quelle fréquence un justiciable conserve la suggestion de l'IA sans la modifier.
• Nouveau module d'agrégation pur lib/ai/eval/fact-feedback-metrics.ts (computeFactFeedbackAgreement) — déterministe, sans dépendance, testé unitairement avec des données synthétiques et des taux attendus calculés à la main. Volontairement EXCLU du seuil de régression CI de runAllEvals() : contrairement à la classification/citation/red-team, il n'existe aucun jeu de données de référence pour cette famille (ce sont des retours de production réels, pas un jeu de test), conformément à la portée de #1651 qui prévoit de démarrer comme surface d'observation, pas comme bloqueur de fusion.
• Lit ai_fact_feedback via le MÊME client admin à rôle de service que resolveOpsAdmin() fournit déjà à la route /api/admin/ai-eval pour sa vérification réservée aux fondateurs — aucun nouveau contournement introduit. Métadonnées seulement : la requête sélectionne field/outcome/similarity, jamais le texte brut IA/humain (jamais persisté), conformément à la portée Loi 25 de la migration 0145. Enregistre une entrée au registre Loi 25 de lecture inter-dossiers du fondateur (api/admin/ai-eval), à l'image de la posture de lecture agrégée de /api/admin/metrics.
• Aucune tuile d'interface ajoutée pour l'instant — comme les familles classification/citation/red-team/UPL déjà présentes sur cette route, cela est livré comme une surface de rapport JSON pour la revue directe de Priya/Alexandre; une tuile Centre de commande est un prolongement naturel, hors de la portée de ce ticket.

ADR-0005 : la frontière freemium entre le Litige pré-judiciaire et le Dossier judiciaire est mise par écrit pour révision par le fondateur (+1, documentation)

• Un nouveau registre de décision d'architecture décrit comment le palier gratuit du Litige se rapporte au palier payant du Dossier (épopée #100), ancré dans ce qui existe déjà : la table autonome des litiges et sa fonction de conversion, l'ancien mécanisme litigationOverride intégré aux dossiers existants, les quotas freemium codés mais non appliqués, et le moteur du Score de justice fondé sur des profils de tribunal. Il désigne le point exact où s'applique la barrière de paiement (création d'un litige ou d'un dossier), explique pourquoi le Score de justice demeure un instrument réservé aux Dossiers alors qu'un signal de préparation pré-judiciaire plus léger existe déjà pour les litiges, et soumet deux décisions que seul le fondateur peut trancher — les noms présentés au justiciable pour les deux paliers, et si le palier gratuit est un plancher permanent ou un essai limité. Rien n'est livré ici : il s'agit d'un document destiné à la révision, pas d'un changement de code.

Justice Score™ T7 : l'ancien score à 7 dimensions est retiré — chaque surface restante lit désormais le moteur à 16 dimensions (#1671).

• La fonction justiceScore() (présence seulement, lib/store/cases.ts) est entièrement supprimée, avec ses types ScoreDimension/JusticeScore et les clés de dictionnaire mortes scoreTitle/scoreHint/dimensions. T5 (#1669) avait déjà remplacé le widget de l'onglet Aperçu de Workspace.tsx par le nouveau tableau de bord; cette version retire ses 4 derniers points d'appel : le badge de préparation sur les cartes de dossier de l'accueil du Centre de commandement (JusticeHome.tsx), la statistique de préparation moyenne et la colonne par dossier du portfolio du cabinet (Firm.tsx), les lignes de forces/faiblesses du panneau Stratégie (lib/strategy.ts), et la ligne de préparation après importation du rapport d'intake de documents (lib/intake/engine.ts). Les quatre lisent maintenant scoreMatter(matter, "base").band.cappedScore — le même chiffre plafonné par les verrous et calibré par ressort que le tableau de bord complet affiche comme score principal, sur la même échelle de 0 à 100 que l'ancien score, si bien qu'aucun appelant n'a dû changer la forme de son affichage.
• Les forces/faiblesses du panneau Stratégie parcouraient les 7 dimensions étiquetées à la main de l'ancien modèle; elles parcourent maintenant les 16 dimensions du nouveau moteur (via le nouveau paramètre requis `t: AppDict` de litigationStrategy) en utilisant les libellés déjà traduits de wsJusticeScore.dimensionNames plutôt qu'une seconde carte d'étiquettes maison. Le ratio gagné/disponible de chaque dimension intègre désormais la Substantiation, l'Admissibilité, la Résilience adverse et la Conformité procédurale, pas seulement la présence, si bien que le panneau peut faire ressortir des lacunes de préparation adverse (Partie adverse/Réplique, Autorités, Crédibilité) que l'ancien modèle ne pouvait pas voir. Plafonné aux 5 dimensions les plus significatives par liste (comme le plafond déjà existant sur les prochaines actions) pour que 16 candidats ne submergent pas le panneau.
• Le tableau de correspondance §10 est appliqué à chaque surface migrée : Théorie de la cause 18→Théorie de la cause 9 + Fondement juridique 8; Parties 14→Parties 4 + Compétence 3; Chronologie 18→8; Preuve 16→11; Pièces 12→7; Témoins 10→6; Échéances 12→Échéances 7 + Actes de procédure 5 — les 32 nouveaux points (Dommages, Partie adverse/Réplique, Autorités, Crédibilité, Communication de la preuve, Préparation à l'audience) relèvent presque entièrement du travail adverse et procédural que l'ancien modèle ne mesurait jamais. Un dossier hérité sans donnée propre au nouveau modèle obtient tout de même un score sensé sous scoreMatter (zéros honnêtes sur les ~11 critères structurellement non appuyables, selon T4/#1668) — aucune perte de données. Voir IMPLEMENTATION_1671.md pour l'inventaire complet des points d'appel.

Pointage Justice™ T6 : la liste classée « ce qui manque » — cadrage anti-embuscade, i18n complète (#1670).

• Ajout de lib/justice-score/gaps.ts (`deriveGaps`), une fonction pure du résultat `scoreMatter` de T4 (ReadinessResult) qui transforme le pointage en une liste classée et actionnable : chaque verrou déclenché apparaît comme son propre élément prioritaire (dans l'ordre du spec, toujours avant chaque lacune de critère — un verrou peut maintenir un pointage numériquement élevé sous le seuil « Prêt pour le tribunal » peu importe les points, donc le corriger n'est jamais « optionnel »), et chaque critère en deçà de la complétion totale devient un élément classé selon son impact sur le pointage (points non gagnés), avec un bonus pour les critères de Résilience adverse (axe R) et pour tout critère alimentant le vrai signal d'un verrou CRITIQUE actuellement déclenché (G1/délais, G2/compétence, G3/preuve) — le cadrage anti-embuscade : un dossier peut sembler solide sur papier et se faire quand même surprendre au procès, et le classement fait ressortir ce risque en premier. Les points disponibles/gagnés par critère sont reconstitués à partir des `dimScores` par dimension déjà existants (aucun changement requis à score.ts). Les 11 critères que T4 a documentés comme structurellement non pris en charge (IMPLEMENTATION_1668.md §5) apparaissent avec la mention honnête « pas encore suivi » plutôt qu'une action fabriquée.
• i18n : `deriveGaps` n'importe jamais de dictionnaire (uniquement des ids/nombres purs); une seconde fonction pure, `gapSuggestionCopy`, résout le texte destiné au justiciable à partir des dictionnaires bilingues — en réutilisant `wsJusticeScore.dimensionNames`/`criteria`/`gateNames`/`gateMessages`/`gateActions`/`bandNames` de T5 (#1669, fusionné en premier) plutôt que de les dupliquer, et en ajoutant seulement la section `wsJusticeScoreGaps`, net nouvelle : 60 textes d'action « faire ceci ensuite » (un par critère, en en/fr) plus le texte de cadrage/badge propre au panneau de lacunes (aussi ajouté dans partials/es.ts). Suit le patron établi de lib/witness/witness-view.ts (le dictionnaire est passé en paramètre, jamais importé à l'exécution). check:i18n-gap reste à 100 % fr/en, et le cliquet ES a progressé (996 -> 1003 feuilles espagnoles réelles).
• Tests (lib/justice-score/__tests__/gaps.test.ts, 25 nouveaux) : logique de classement (bonus axe R, bonus de lien à un verrou, les verrous déclenchés toujours en premier, marquage des lacunes structurelles, reconstitution des points disponibles par critère qui redonne exactement les totaux du modèle sur 1000/par dimension sous le profil de base et un profil repondéré), résolution i18n contre les vrais dictionnaires en/fr, déterminisme, et le scénario d'acceptation propre à l'épopée — réutilisation du scénario réaliste §11 de T4 (`dataEnteredNoAdversarialWorkMatter`, exporté de derive.test.ts) de bout en bout via `scoreMatter` -> `deriveGaps` : le dossier « toutes les cases remplies, aucun travail contradictoire » (brut 45,875, En construction) déclenche déjà G6 (part R de 13 % contre le seuil de 60 % du profil de base) avant même une surcharge, si bien que la lacune n°1 est G6 lui-même, suivi des lacunes de critères de l'axe R classées par impact — exactement l'histoire anti-embuscade demandée par l'épopée.
• Ne touche ni au composant du tableau de bord de T5 ni au retrait (pas encore commencé) de l'ancien pointage prévu à T7 — gaps.ts est additif, consommé par n'importe quelle interface (le tableau de bord de T5 ou une future surface) qui choisit de l'afficher.

Visite guidée, phase 3 : vrai texte, QA mobile, audit d'accessibilité + l'avertissement « illustration, pas un avis juridique » (#1677).

• Phase 3 de la visite guidée de 30 secondes (épopée #1674), qui referme le passage de qualité copie/phase 0 du fondateur. La colonne vertébrale à 5 étapes de la visite (Situation -> Diagnostic -> Résolution -> Marketplace -> Cour) a été réconciliée avec les 9 vraies étapes du WorkflowStepper de l'espace de travail : 4 des 5 étapes correspondent déjà exactement au vocabulaire réel du produit (Situation, Résolution — l'étape de la mise en demeure —, Marketplace et Cour sont des noms d'étape/de fonctionnalité littéraux); « Diagnostic » est une étiquette pédagogique volontairement compressée qui couvre les vraies étapes Classer et Chronologie, conservée selon la direction du fondateur (phase 0) d'orienter les nouveaux arrivants autour de la colonne à 5 étapes plutôt que du détail complet à 9 étapes. Aucun renommage n'a été nécessaire — voir IMPLEMENTATION_1677.md pour l'audit complet.
• Ajout d'un avertissement « illustration, pas un avis juridique » à l'écran de fin de la visite, en français (par défaut), en anglais et en espagnol, partagé par les variantes page d'accueil et intra-application. Le texte est volontairement générique — il ne cite pas la loi spécifique du dossier de démonstration (Loi sur la protection du consommateur) ni son délai de 30 jours — afin de rester exact peu importe la juridiction ou le délai réel du dossier d'un visiteur. Signalé dans IMPLEMENTATION_1677.md pour l'approbation de Julien (VP Affaires juridiques) / Geneviève (Conformité); livré maintenant sans bloquer sur cette révision, selon la directive.
• QA mobile (feuille du bas <= 480px) : correction d'un risque de débordement du viewport où une traduction française longue sur un écran court ou en mode paysage pouvait pousser le haut du contenu de la feuille hors de la zone visible (ajout d'une hauteur maximale + défilement), et élargissement des boutons textuels de la visite (Passer/Retour/« Plus tard », ainsi que l'action principale) à une cible tactile minimale de 44 px sur mobile.
• Audit d'accessibilité : le mini-écran simulé par étape (fausse citation de loi, fausses évaluations en étoiles, avatars) est désormais masqué aux technologies d'assistance (aria-hidden), puisqu'il ne fait que reformuler — sans jamais ajouter — le vrai contenu accessible du titre/corps/légende; confirmation que le piège de focus existant, la fermeture par Échap, la navigation par les flèches et les styles globaux prefers-reduced-motion + focus-visible du site couvrent déjà correctement la visite (aucun changement au moteur requis).
• Révision de traduction : ajout d'une vérification automatisée de complétude fr/en/es pour tour-content.ts (ce fichier est rédigé hors de dictionaries/*.ts, donc la vérification normale de parité check:i18n-gap ne le couvrait jamais) — chaque étape, écran de fin, texte d'interface et le nouvel avertissement doivent se résoudre dans les trois langues, sinon la suite échoue.
• Aucun changement de comportement ni d'API au moteur de la visite lui-même — uniquement le texte, l'accessibilité, la mise en page mobile et l'avertissement.

Justice Score™ T5 : le tableau de bord de préparation du justiciable — remplace l'ancien widget de pointage à 7 dimensions (#1669).

• Ajout de components/workspace/JusticeScoreDashboard.tsx, monté dans l'onglet Aperçu à l'endroit où l'ancien widget justiceScore() à 7 dimensions s'affichait. Il appelle scoreMatter(matter, profileId) de T4 et affiche le cadran de pointage et la bande de préparation, les 5 axes de qualité (Complétude/Justification/Admissibilité/Résilience face à la partie adverse/Conformité procédurale, avec le cadrage « seulement 25 % provient de la saisie de données »), le message en langage clair et l'action à poser pour chaque verrou déclenché, une liste d'exposition face à la partie adverse (dimensions à plus faible résilience), un radar des axes, ainsi qu'une liste de vérification complète par dimension et par critère — adapté de l'explorateur de calibrage du fondateur à docs/plan/justice-score/justice-score-explorer.html. Un sélecteur local de profil de juridiction (base/Petites créances/Cour du Québec/Cour supérieure/TAL) permet à un justiciable de voir le MÊME dossier pointé sous un autre forum; le dossier lui-même ne comporte pas encore de champ de profil persistant, il s'agit donc d'un état d'interface local et non sauvegardé, par défaut sur le profil de base neutre — conforme au scénario qui reproduit l'histoire de bout en bout de l'épopée (données saisies, aucun travail contradictoire → brut ≈46, En construction, plutôt que ~100 % avec l'ancien modèle).
• Conçu en lecture seule du modèle de pointage : aucun contrôle du nouveau tableau de bord ne permet de modifier le taux de complétion d'un critère — le justiciable améliore son dossier ailleurs dans l'espace de travail (faits, preuve, pièces, témoins…), jamais les pondérations du modèle. lib/justice-score/score.ts gagne un seul champ additif, JusticeScoreResult.criterionScores (pointage gagné/disponible/complétion par critère), et un nouveau lib/justice-score/dashboard-view.ts porte les fonctions d'aide de vue pures et testées indépendamment (buildScoreBreakdown, resilienceExposure, describeGates) à partir desquelles le composant s'affiche — aucun comportement existant de T1 à T4 n'est modifié.
• Parité complète en, fr, es pour chaque nouvelle chaîne (dictionaries/*.wsJusticeScore, environ 110 clés — noms et descriptions de bandes, noms d'axes, messages et actions de verrous, les 16 noms de dimension et les 60 libellés de critères, traduits plutôt que laissés dans le texte de travail interne anglais de model.ts). La fonction justiceScore(), ses clés de dictionnaire (scoreTitle/scoreHint/dimensions) et ses autres points d'appel (JusticeHome.tsx, Firm.tsx, lib/strategy.ts, lib/intake/engine.ts) demeurent intacts — retirer ces références croisées relève de T7 (#1671), pas de ce billet.

Nouveau : capture de la rétroaction IA-vs-humain sur les suggestions IA de la chronologie — la boucle d'auto-amélioration de la plateforme (#1648).

• Ajout de ai_fact_feedback (migration 0145) : chaque fois qu'un justiciable applique une valeur suggérée par l'IA pour « Fait prouvé » ou « Récit » dans la grille de chronologie, puis valide le champ, la plateforme enregistre désormais un signal structuré — quel champ, l'identifiant de la requête IA auditée, si l'humain a conservé la suggestion telle quelle, l'a modifiée ou l'a rejetée, et un score de similarité de 0 à 1 — sans ralentir ni risquer l'enregistrement (tir-et-oubli, à échec silencieux : un échec d'écriture de la rétroaction ne peut jamais empêcher l'enregistrement de votre travail).
• Protection de la vie privée par défaut (Loi 25) : cette version ne stocke délibérément AUCUN texte brut suggéré par l'IA ou saisi par l'humain — seulement le signal structuré de résultat/similarité ci-dessus. La conservation du texte brut demeure conditionnelle à l'examen ouvert de Geneviève (#1652); une voie de migration documentée est prévue pour ce suivi. Voir IMPLEMENTATION_1648.md.
• L'accès est limité au dossier : un utilisateur ne peut lire ou enregistrer de la rétroaction que pour un dossier auquel il a déjà accès (même porte RLS can_access_matter() utilisée partout dans la plateforme), appliquée sur la propre session de l'appelant — aucun contournement par rôle de service. Alimente la mesure de qualité de type banc d'essai prévue au #1651.

Justice Score™ T4 : dérivation dossier → critères — le pont présence→qualité, branché aux données réelles (#1668).

• Ajout de lib/justice-score/derive.ts : une fonction pure deriveCriterionCompletion(matter) qui associe les faits, la preuve, les pièces, les témoins, les échéances/procédures, les contradictions, la jurisprudence et la préparation à l'audience d'un dossier réel aux quelque 60 critères T1 et aux entrées des portes T2, ainsi que scoreMatter(matter, profileId) qui compose dérivation → pointage (T1) → portes (T2) → bande de préparation (T2) selon un profil de juridiction T3, en un seul ReadinessResult. Aucune des deux fonctions n'accède à une base de données ni à un client à rôle de service — l'appelant récupère le dossier via son propre contexte scoped RLS au préalable.
• G3 (élément non prouvé) est désormais branchée à la véritable correspondance preuve→élément : tout Issue plaidé sans aucune preuve associée déclenche la porte, plafonnant le pointage à 65. G1 (prescription) lit les échéances dérivées d'une règle; G2 (juridiction/quantum) vérifie le tribunal du dossier par rapport au profil choisi (sans inventer de montant réclamé, puisque LegalCase ne comporte aucun champ de quantum plaidé); G4 (signification) lit les demandes de service d'huissier; G5 (RED) lit le parcours de résolution.
• Partout où le modèle de données du dossier ne comporte réellement aucun champ pour un critère (11 des 60 — compétence des témoins, justification de l'intérêt pour agir, plusieurs indicateurs de résilience « résiste à l'attaque X »), le taux de complétion est honnêtement de 0, jamais inventé — voir le tableau complet de correspondance critère→champ et la liste des lacunes dans IMPLEMENTATION_1668.md (T6 les présentera comme suggestions d'amélioration du pointage). Un test de bout en bout prouve pour la première fois, sur un dossier réaliste, le scénario de l'exemple phare §11 de l'épopée : un dossier dont les données sont saisies mais sans travail contradictoire/d'admissibilité atterrit dans « En construction » (brut ≈46, plutôt que ~100 % avec l'ancien modèle), et un dossier soigneusement préparé atteint « Prêt pour le tribunal » selon le profil de la Cour du Québec.

Nouveau : la visite guidée se souvient maintenant de vous après connexion — multi-appareils, avec un bouton pour la revoir (#1676).

• Phase 2 de la visite guidée de 30 secondes (#1674). Les utilisateurs connectés obtiennent maintenant la visite dans l'espace de travail juridique : elle s'ouvre automatiquement la première fois et — contrairement à la version anonyme de la page d'accueil, qui se souvient par appareil — celle-ci se souvient par COMPTE, donc la fermer sur votre téléphone signifie qu'elle ne vous relancera pas sur votre ordinateur portable. Un nouveau bouton « Revoir la visite (30 s) » dans la barre d'outils de l'espace de travail permet de la revoir en tout temps. La visite anonyme de la page d'accueil (#1675) est inchangée. Désactivé par défaut : activez avec NEXT_PUBLIC_GUIDED_TOUR_APP=1.

Correctif critique : les documents de dossier sont maintenant extraits en texte, ce qui rend l'ancrage RAG réellement fonctionnel (#1638).

• Correction d'une lacune critique : les documents téléversés par les utilisateurs n'étaient jamais extraits en texte — queueIndex() dans matters/ingest était un no-op étiqueté, donc documents.extracted_text restait vide pour chaque téléversement réel, la tâche planifiée d'auto-indexation §29.22 ne trouvait rien à découper/vectoriser, et le rappel Copilot ainsi que la rédaction IA « ancrée RAG » s'appuyaient silencieusement sur zéro texte de document. Corrigé de la façon économique recommandée par le signalement (sans nouveau service d'extraction payant) : matters/ingest accepte désormais le texte déjà extrait côté navigateur (OCR / couche texte du PDF) de la même manière que evidence/ingest le fait déjà, le persiste dans documents.extracted_text, et la tâche planifiée existante le récupère à son prochain passage — aucun changement à la logique de découpage/vectorisation de la tâche elle-même.
• Ajout d'une colonne explicite documents.extraction_status ('pending_extraction' / 'client_extracted' / 'server_extracted') afin qu'un document ingéré sans texte soit une lacune visible et interrogeable, plutôt que silencieusement indiscernable d'un document indexé; un événement d'audit est aussi enregistré pour le cas en attente. L'ingestion sans texte réussit toujours (ouvert en cas d'échec) — aucun changement au comportement de téléversement pour l'appelant.
• Précision de portée : ceci n'ajoute pas d'analyse PDF/DOCX ni d'OCR côté serveur, et ne rétroactive pas le texte extrait pour les documents ingérés avant ce correctif (la migration ne fait que corriger les métadonnées de la nouvelle colonne de statut pour les lignes existantes qui avaient déjà du texte provenant d'une autre voie). Les deux sont des suites délibérément reportées — voir IMPLEMENTATION_1638.md.

Justice Score™ T3 : profils de juridiction sous forme de données — base + 4 tribunaux québécois (#1667).

• Ajout de lib/justice-score/profiles.ts, cinq trousses de données calibrées par tribunal (base, Petites créances, Cour du Québec civile, Cour supérieure, Tribunal du logement) qui s'intègrent au moteur T1 (#1665) uniquement comme données — aucun changement au moteur requis. Chaque trousse porte des multiplicateurs de pondération par dimension, un seuil de préparation au procès calibré selon le tribunal, un plancher minimal pour l'axe Résilience adverse, et des paramètres de filtre (plafonds/planchers de réclamation, déclencheur de médiation, exigence de bail) pour le travail sur les filtres/bandes prévu ensuite dans l'épopée (#1664). Il s'agit uniquement d'une charpente technique interne : aucun changement d'interface ni de notation destiné au justiciable n'est livré dans cette version.

Justice Score™ T2 : le moteur de verrous (G1-G6) + bandes de préparation (#1666).

• Ajout de lib/justice-score/gates.ts et bands.ts (épopée #1664, T2 du modèle de préparation Justice Score™). Six verrous plafonnent désormais le score brut du moteur T1 lorsqu'un dossier présente une lacune critique : une prescription non analysée ou expirée, un échec du contrôle juridiction/quantum, un élément plaidé sans aucune preuve à l'appui, ou une signification incomplète. Une septième condition (mode alternatif de résolution des différends obligatoire) applique un plafond plus souple lorsque le tribunal l'exige. Un sixième verrou, non numérique, verrouille la bande Prêt pour le tribunal dès que la démonstration de résilience adverse du dossier tombe sous le seuil du tribunal, même à score élevé. Les cinq bandes de préparation (Non viable / En construction / Substantiellement préparé / Prêt pour le tribunal / Aguerri pour le procès) sont calculées à partir du score plafonné et des résultats des verrous; un dossier qui franchit numériquement la barre Prêt pour le tribunal ou Aguerri pour le procès est délibérément maintenu à Substantiellement préparé — jamais promu silencieusement — lorsqu'un verrou requis n'est pas levé. Il s'agit uniquement d'une charpente technique interne : aucun changement d'interface ni de notation n'est livré dans cette version. Les seuils propres à chaque juridiction (T3), le raccordement aux données réelles du dossier pour ces verrous (T4) et le tableau de bord destiné au justiciable (T5) arriveront dans les tâches suivantes de l'épopée.

Interne : ajout du plan de conception Justice Score™ v0.1 + explorateur interactif dans docs/plan/ (#1672).

• Aucun changement de produit ni visible pour l'utilisateur. Ajout du plan de conception du modèle de préparation Justice Score™ (16 dimensions × 5 axes de qualité, 6 verrous, bandes de préparation à l'audience calibrées par instance, 5 profils de compétence) et de l'explorateur interactif de calibrage du fondateur comme documentation compagnon canonique sous docs/plan/justice-score/. Les pondérations sont provisoires et non verrouillées — rien ici ne modifie le moteur de notation en production tant que le fondateur n'a pas validé le verrouillage des pondérations (#1673). Fait partie de l'épopée Justice Score™ (#1664).

Nouveau : l'IA indique maintenant QUEL document appuie un fait prouvé dans la Chronologie, pas seulement son texte (#1650).

• Lorsque les boutons IA « ✨ » Fait prouvé ou Récit de la grille Chronologie produisent une suggestion fondée sur l'une des citations sources connues du fait, le sélecteur de source se pré-remplit désormais avec le document, la pièce et le paragraphe cités — affiché comme « L'IA a cité : <document> » — afin que vous puissiez confirmer ou modifier avant d'enregistrer, plutôt que de ne voir que la formulation de l'IA sans lien vers la pièce d'où elle provient. L'IA ne cite jamais que des citations qui lui ont réellement été fournies ; le serveur relie sa citation au document réel côté serveur, de sorte qu'elle ne peut jamais inventer une source. Les faits dont les sources n'ont aucun document connu (données plus anciennes) se comportent exactement comme avant.

Nouveau : une visite guidée de 30 secondes sur la page d'accueil, derrière un indicateur de fonctionnalité (#1675).

• Ajout du composant de visite interactive fourni par le fondateur (situation → diagnostic → résolution → marketplace → cour) : un dossier de remboursement simulé que le visiteur pilote lui-même, un clic à la fois, en moins de 30 secondes. Câblé pour la page d'accueil anonyme seulement à cette phase — la navigation passe par le routeur de l'application, la langue de la visite suit la locale du site, le thème utilise l'accent corail de la marque, et un pont d'analytique mince et sûr se déclenche sans nouvelle dépendance. Chargé dynamiquement (sans SSR) pour ne jamais retarder le premier affichage. Désactivé par défaut : activez avec NEXT_PUBLIC_GUIDED_TOUR_HOMEPAGE=1. La persistance par appareil (localStorage) et la variante in-app après inscription suivront à la phase 2 (#1676).

Justice Score™ T1 : le moteur de calcul pur + modèle typé (#1665).

• Ajout de lib/justice-score, la fondation du nouveau modèle de préparation Justice Score™ (épopée #1664) : une configuration typée et sans dépendance pour les 16 dimensions notées (regroupées en 4 piliers) et leurs critères, chacun rattaché à l'un des 5 axes — Complétude, Substantiation, Admissibilité, Résilience adverse, Procédural — plus un moteur pur qui renormalise les points pondérés des dimensions vers un modèle exact sur 1000 points et calcule les points obtenus par axe, dimension et pilier. Il s'agit uniquement d'une charpente technique interne : aucun changement d'interface ni de notation n'est livré dans cette version. Il remplace la mesure de présence seule de l'ancien score à 7 dimensions (« avez-vous saisi la donnée? ») par un modèle conçu pour aussi mesurer la solidité, l'admissibilité, la résistance à l'attaque adverse et la propreté procédurale — les seuils, les bandes, les profils de juridiction et le tableau de bord destiné au justiciable arriveront dans les tâches suivantes de l'épopée.

Interne : ajout de tests de régression pour le calculateur d'échéances et les panneaux témoins/échéances (#1633).

• Aucun changement visible pour l'utilisateur. Ajout de tests de rendu pour le panneau Témoins, le lanceur d'armement d'échéance et sa fenêtre de confirmation, ainsi que le calculateur d'échéances, plus de nouveaux tests unitaires fixant la logique de gravité/conséquence utilisée par le bouton « Ajouter aux échéances » du calculateur. Correction également de commentaires de test obsolètes dans trois fichiers de test de panneaux existants qui prétendaient encore être exclus de `npm test` alors qu'un changement antérieur les y avait déjà intégrés.

Nouveau : un indicateur de stockage sur votre page de facturation montre le stockage de preuves utilisé par rapport à votre plafond (#1628).

• L'API d'utilisation du stockage de preuves publiée plus tôt (#1602/#1603) n'avait aucune interface pour la lire. Paramètres → Facturation affiche désormais un indicateur en direct : octets utilisés, plafond de votre forfait (ou « illimité » pour les forfaits payants), une barre de progression et un avertissement clair avec un lien vers les forfaits lorsque vous approchez ou dépassez l'allocation gratuite de 5 Go. Les états de chargement, de connexion et d'erreur sont gérés honnêtement — aucun chiffre fictif.

Renforcement des contrôles d'accès sur les points de terminaison de détail des témoins et des faits (défense en profondeur) (#1632).

• Les points de terminaison du dossier de témoin, des contradictions, des questions, ainsi que celui de modification d'un fait, vérifient désormais votre accès au dossier avant de retourner ou de modifier quoi que ce soit — comblant une lacune où ces vues de détail omettaient une vérification déjà présente sur leurs points de terminaison de liste homologues. Le comportement existant pour les utilisateurs autorisés est inchangé.

Chronologie : bouton de génération IA pour le champ Récit (#1647).

• La colonne Récit de la chronologie dispose désormais du même bouton ✨ IA que Fait prouvé : elle propose un récit factuel en langage clair pour le justiciable — délibérément dans un registre distinct de la phrase de portée juridique du Fait prouvé — fondé uniquement sur les citations sources du fait. La suggestion remplit le champ pour que vous l'acceptiez ou la modifiiez avant l'enregistrement. La réponse de l'IA porte un identifiant de requête stable (affiché sur le champ) afin qu'une future fonctionnalité de capture de rétroaction puisse comparer la qualité du récit généré par IA à la formulation humaine.

Nouveau : un widget de rétroaction universel pour tout signaler d'un seul geste (#1639).

• Ajout d'une commande de rétroaction légère : pouce vers le haut ou vers le bas, une note facultative et une capture d'écran facultative de ce que vous consultez. Les envois ouvrent un billet trié pour l'équipe. Les captures d'écran ne sont jamais jointes au billet (seule leur taille est notée) afin de protéger le contenu privé de vos dossiers. Si la rétroaction n'est pas configurée sur une édition, vous obtenez un message clair au lieu d'un échec silencieux.

Préservation de session : journaux de session complets dans docs/sessions/ (directive du fondateur).

• Ajout d'une règle permanente et du premier journal de session (session boucle exécutive du 2026-07-05) : à l'approche de la limite de contexte, l'agent écrit un enregistrement MD complet de la conversation et de tout ce qui a été produit dans docs/sessions/, met à jour le dossier du fondateur et publie un mémo HubSpot — afin que rien ne soit perdu et que les bogues futurs soient traçables.

Chronologie : modifier la source et valider un fait (#1645, #1646).

• Dans la chronologie, vous pouvez désormais modifier le document/pièce + paragraphe qui constitue la SOURCE d'un fait, et marquer un fait VALIDÉ (un tampon de réviseur affiché à côté de la confiance dérivée). Les deux sont enregistrés avec vos autres modifications — la première étape de la chronologie entièrement modifiable.

Correctif : le bouton « IA → fait prouvé » de la chronologie fonctionne et indique pourquoi en cas d'échec (#1649).

• Renforcement de l'analyseur du fait prouvé par IA — il gère désormais les réponses entourées d'un bloc de code ou avec un libellé d'événement mince. Lorsque l'IA ne peut vraiment pas s'exécuter, la chronologie indique précisément pourquoi (non configurée / indisponible / accès refusé).

Les panneaux Échéances, Registre des pièces et Faits sont maintenant actifs dans l'espace de travail (#1620).

• Après le panneau Témoins, les onglets Échéances, Registre des pièces et Faits et chronologie affichent désormais leurs panneaux côté serveur (serveur d'abord, avec repli sur vos données du navigateur et importation en un clic). Les quatre modules d'organisation de dossier du parcours accéléré sont maintenant utilisables. Les Échéances affichent les échéances armées côté serveur en plus des rappels locaux (l'armement nécessite un jeu de règles, donc pas d'importation avec perte).

Calculateur de règlement : saisir le montant directement (le curseur se synchronise) (#1642).

• Chaque champ du planificateur de règlement dispose désormais d'une case numérique modifiable à droite — saisissez une valeur et le curseur suit, ou déplacez le curseur et la valeur suit. Les valeurs sont bornées à la plage de chaque champ.

Correctif : le test du nombre d'agents du poste de commandement attend 7 dirigeants (le nouveau VP des affaires juridiques).

• Correction du test du poste de commandement du fondateur qui codait en dur six agents exécutifs — il en attend désormais sept après l'arrivée du VP des affaires juridiques (51002). Débloque la construction de main.

Expansion du bureau exécutif : VP des affaires juridiques (Dr Julien Mercier, 51002) + autorité du CTO de changer de modèle.

• Ajout d'un agent exécutif VP des affaires juridiques — autorité de niveau doctoral sur le droit substantiel et procédural du Québec (droit civil), du reste du Canada (common law) et des États-Unis — pour valider que chaque parcours de résolution de problème affiche le bon forum, le bon délai et la bonne procédure par juridiction. Distinct de la barrière d'autorisation de la Conformité.
• Octroi au CTO de l'autorité de changer de modèle / d'effort de raisonnement pour la programmation de haute complexité, afin d'éviter un code inefficace ou sous-optimal.

Le panneau Témoins est maintenant actif dans l'espace de travail (#1617) : l'onglet Témoins affiche votre registre de témoins côté serveur, avec un repli sûr qui ne masque jamais les données déjà présentes dans votre navigateur.

• L'onglet Témoins affiche désormais le panneau côté serveur (dossier, contradictions, questions d'interrogatoire) au lieu de l'ancienne vue locale — en lisant d'abord le serveur, avec repli sur vos données présentes dans le navigateur et une importation en un clic pour ne rien perdre. C'est le premier des quatre panneaux du parcours accéléré à devenir utilisable; les trois autres suivent le même modèle.
• Les entrées du journal enregistrent désormais l'HEURE de publication en plus de la date (directive du fondateur).

Agents exécutifs auto-améliorants (#1622) : chaque dirigeant réfléchit, consigne ses leçons et modifie sa propre définition pour s'améliorer à chaque cycle.

• Les six agents de l'Executive OS (PDG/CTO/Produit/Opérations/Conformité/Finance) exécutent désormais une réflexion par cycle — « qu'ai-je appris / comment aurais-je pu faire mieux » —, la consignent en mémoire et promeuvent les leçons durables dans leurs propres fichiers de définition, que l'agent ou le superviseur méta-agent peut modifier. Chacun a été amorcé avec une véritable leçon de cette session. Ignoré aussi des artefacts parasites à la racine (un certificat isolé + des zips + des journaux de session).

Panneau Faits et aveux de l'espace de travail (#1614, volet #70) : gestion des faits et aveux côté serveur (fondation).

• Nouveau panneau Faits/Aveux relié aux API serveur /api/facts et /api/admissions — lister les faits (avec filtres contestés-seulement et étiquette de question), ajouter un fait, basculer l'indicateur contesté d'un fait, et lister/ajouter des aveux — le quatrième module d'organisation de dossier du parcours accéléré. Fondation : construit et testé; le montage dans l'onglet de l'espace de travail est séquencé après la migration de production (#1532) et le chemin d'importation des données (#1617).

Panneau Témoins de l'espace de travail (#1612, volet #70) : gérer les témoins d'un dossier via le registre serveur.

• Nouveau panneau Témoins relié à l'API serveur /api/witnesses existante — lister et ajouter des témoins, et consulter le dossier d'un témoin (aveux, contradictions, questions d'interrogatoire) — complétant un autre module d'organisation de dossier du parcours accéléré du fondateur, aux côtés des Échéances et du Registre des pièces.

Lot 1 de la direction du CTO (volet #70) : les tests de rendu des composants s'exécutent maintenant en CI, et /api/facts adopte le substrat de route partagé.

• Le lanceur de tests détecte désormais les tests de rendu des composants (components/**/__tests__/*.test.tsx), de sorte que les panneaux de l'espace de travail sont couverts en CI plutôt qu'en manuel uniquement (#1616).
• Migration de l'API des faits vers le contrat de route partagé (defineRoute) — la même barrière d'accès au dossier, la validation zod et l'enveloppe d'erreur à code machine que l'API des témoins — remplaçant une vérification d'authentification codée à la main (#1613).

Échéances et pièces du parcours accéléré du fondateur (#70) : le moteur d'échéances est maintenant lisible, actionnable, adossé à des rappels et affiché — plus un panneau de registre des pièces côté serveur (+100).

• Ajout de GET /api/deadlines et PATCH /api/deadlines/[id] pour lister les échéances armées d'un dossier et les marquer traitées/rejetées (#1604, #1605).
• Le cron de notifications déclenche désormais des rappels sur les échéances armées côté serveur — le moteur ne voit plus uniquement les dossiers côté client, si bien qu'une véritable échéance de dépôt/signification/prescription produit réellement un rappel (#1609).
• Nouveau panneau Échéances : échéances à venir triées de la plus proche à la plus lointaine, avec mise en évidence en retard/bientôt due et action traitée/rejetée en un clic (#1606).
• Nouveau panneau Registre des pièces relié au registre serveur, affichant les numéros de pièces R-n faisant autorité avec réservation et retrait (#1610).

API de lecture de l'utilisation du stockage (#1602, complète #1591/#1592) : une route pour voir la part utilisée de l'allocation de preuves de 5 Go.

• Ajout de GET /api/billing/storage-usage — un point d'accès protégé par authentification qui renvoie le stockage de preuves utilisé/limite/restant par rapport au plafond de votre forfait (5 Go gratuits ; illimité pour les forfaits payants), le pendant en lecture de la mesure que la limite de téléversement applique déjà.

Renforcement — retrait de la clé du sélecteur Google Drive (#1120) : orienter la configuration vers la GOOGLE_PICKER_API_KEY non publique et avertir si l'ancienne clé publique est encore utilisée.

• Documentation de GOOGLE_PICKER_API_KEY (côté serveur, protégée par authentification via /api/config/drive-picker) comme clé canonique du sélecteur Drive, et marquage de NEXT_PUBLIC_GOOGLE_API_KEY (incluse dans le bundle navigateur) comme obsolète.
• Le serveur consigne désormais un avertissement unique lorsque la clé du sélecteur provient encore de la variable publique, afin que les opérateurs migrent et suppriment la clé exposée.

Cycle de vie freemium phase 1 : quotas de litiges et de dossiers, application des limites, mesure du stockage de preuves, route de conversion litige→dossier et entonnoir de conversion nommé (+100, #100)

• Ajout des quotas de capacité — un palier gratuit de 25 litiges actifs, 1 dossier de litige et 5 Go de stockage de preuves — établis selon votre forfait, chaque forfait payant étant pour l'instant illimité.
• Application des limites gratuites de litiges et de dossiers directement dans la base de données, avec une invitation à passer à un forfait supérieur lorsqu'une limite est atteinte.
• Mesure du stockage de preuves : les téléversements sont vérifiés par rapport à votre allocation gratuite de 5 Go avant d'être conservés.
• Ajout d'une route pour convertir un litige en dossier de litige, et instrumentation de tout l'entonnoir Litige → Mise en demeure → Escalade → Dossier → Référence afin de mesurer l'abandon.
• Consignation de l'ADR-0004 précisant qu'un litige (admission pré-contentieuse) et un portefeuille (regroupement de dossiers) sont des concepts distincts.

Le système d'exploitation exécutif : des agents exécutifs nommés, un cadre décisionnel 4-C partagé, une dorsale d'exécution gouvernée, la tour de contrôle du fondateur, un orchestrateur à garde-fous d'autonomie bornée, un magasin d'événements durable et le premier opérateur réel (Stripe en mode test) (+100, #1574)

• Nous avons posé la fondation gouvernée d'une couche exécutive assistée par IA qui permet au fondateur d'agir comme président exécutif plutôt que comme PDG opérationnel. Plutôt que de bâtir un second système, cette version unifie le cerveau consultatif, les barrières de gouvernance et les signaux d'exploitation déjà présents sous une seule structure. Six agents exécutifs nommés existent désormais — Alexandre Roy (PDG), Priya Raman (directrice technique), Simone Beaulieu (produit), Marcus Chen (exploitation), Geneviève Lévesque (conformité) et David Okafor (finances) — chacun portant un matricule d'employé à 5 chiffres (département, humain ou agent, numéro de série) et déléguant aux spécialistes existants de la plateforme au lieu de les dupliquer. Un cadre décisionnel 4-C partagé (Capital, Contrôle, Avantage cumulatif, Charge cognitive) évalue chaque initiative et recommande sa fermeture lorsqu'elle n'améliore aucun de ces axes ; toute initiative touchant une surface sous barrière humaine est escaladée au fondateur, quel que soit son score. Une mémoire exécutive canonique (Vision, Stratégie, Politiques, Décisions, Leçons, Escalade) donne à chaque agent une source de vérité unique.
• Elle introduit aussi la dorsale d'exécution qui permet aux agents d'agir avec une autonomie bornée plutôt que de seulement raisonner. Les agents ne touchent jamais directement aux systèmes externes : ils émettent une tâche structurée qu'un routeur à permissions valide contre une matrice de capacités et un registre d'outils, puis achemine vers exécuter, escalader ou rejeter — chaque étape étant consignée dans un journal d'événements en ajout seul qui alimente un fil d'exécution en direct et des indicateurs système. Les lectures à faible risque s'exécutent automatiquement ; un changement de tarification à risque moyen est escaladé à l'agent PDG ; un changement de prix à risque élevé s'arrête dans la boîte du fondateur jusqu'à son approbation. L'exécution est isolée derrière un port d'opérateur interchangeable, et cette version ne livre qu'un opérateur de simulation déterministe avec une démonstration en boucle fermée — les opérateurs Stripe/GitHub/Supabase réels sont une phase ultérieure, d'abord en mode test et révisée.
• Enfin, elle ajoute la couche de données de la tour de contrôle du fondateur : une API en lecture, réservée au fondateur/admin, qui assemble une vue exécutive à six panneaux — vue d'ensemble, carte d'activité des agents, fil d'exécution en direct, boîte d'escalade (avec l'approbateur suggéré), revenus et impact, et santé du système — uniquement à partir du journal d'événements d'exécution. Un mode démo exécute la boucle de simulation en mémoire afin que la tour puisse être vue de bout en bout sans clés réelles. L'interface elle-même est une phase front-end ultérieure. Aucun comportement d'exécution n'est encore modifié ; il s'agit de code de bibliothèque pur avec tests, d'une API en lecture protégée, de documentation et de définitions d'agents, entièrement réversible.
• Cette version prolonge la dorsale avec ce qui la rend exploitable à grande échelle. Un orchestrateur achemine tout un lot de tâches proposées à travers le routeur tout en appliquant les garde-fous d'autonomie bornée qu'exige une véritable organisation multi-agents : deux écritures sur la même ressource ne peuvent s'exécuter toutes deux (la seconde est consignée comme conflit, jamais abandonnée en silence), une même tâche ne peut rentrer deux fois dans la file (garde anti-récursion), et aucun agent seul ne peut inonder l'organisation (un plafond par exécution) — et chaque décision, y compris les battements d'état des agents, est un événement sur le même journal en ajout seul. Un magasin d'événements durable (une nouvelle table en ajout seul, en lecture pour l'admin et en écriture réservée au rôle de service, protégée par la sécurité au niveau des lignes, avec un déclencheur d'immuabilité en ajout seul) permet à la tour de contrôle de refléter l'activité exécutive réelle entre les processus plutôt que le journal démo d'une seule requête. Et le premier opérateur réel arrive — un opérateur Stripe derrière le même port interchangeable — délibérément en mode test d'abord et à sûreté intégrée : il refuse toute clé non-test à moins qu'une clé réelle ne soit explicitement choisie, et il utilise l'identifiant de chaque tâche comme clé d'idempotence pour qu'une reprise ne puisse jamais facturer ou créer en double. Il est livré testé unitairement contre un faux injecté ; son activation réelle est une décision du fondateur qui requiert une clé de test Stripe et une revue des paiements. L'ensemble demeure du code de bibliothèque pur avec tests plus une migration (revue RLS requise avant fusion), et reste entièrement réversible.

L'accueil de l'espace de travail devient un poste de pilotage du litige (+10, #1534)

• L'accueil connecté met désormais en avant ce qui demande votre attention : une salutation selon l'heure résumant vos dossiers actifs, échéances dépassées et actions en attente avec un indicateur de priorité ; une rangée d'indicateurs du portefeuille (dossiers, échéances, en retard, preuves) ; un panneau « attention requise » reliant chaque dossier en retard directement à ses échéances ; et une rangée compacte d'actions rapides. Les cinq cartes de la place de marché juridique quittent la colonne principale pour un panneau latéral ⚖ Services juridiques derrière une seule entrée de navigation — chaque service reste à un clic, mais votre litige ne dispute plus l'écran à un annuaire de services.

L'avis de la page de tarification de l'édition américaine cite désormais le bon régulateur : la State Bar Association, et non le Barreau du Québec (+5, productionBugFix)

• La page de tarification de Judge911.com affichait un avis désignant le barreau québécois comme l'autorité encadrant la mise en relation avec des avocats — un vestige de la copie québécoise partagée que le pipeline de marque renomme sans en adapter la juridiction. L'édition américaine précise désormais, en anglais et en espagnol, que la mise en relation avec des avocats et toute rémunération associée demeurent assujetties à la State Bar Association et aux règles professionnelles applicables, et qu'elles ne seront pas monétisées tant que l'approbation déontologique ne sera pas complétée. L'édition québécoise conserve, inchangé, son libellé révisé par avocat visant le Barreau du Québec.

L'opération des campagnes gérées reçoit son ossature : des mandats attestés, une machine d'états qui impose la révision et des honoraires fixes que le schéma ne peut pas faire varier (+10, existingToolUpgrade)

• La phase 2 du programme publicitaire américain dispose désormais de son substrat opérationnel. Les administrateurs consignent les mandats de campagne des cabinets intéressés — État, fourchette de budget, objectifs — et aucun mandat ne peut exister sans que le cabinet atteste posséder ses propres comptes publicitaires et porter ses propres divulgations légalement requises : la base de données refuse la ligne autrement. Chaque mandat suit une machine d'états qui ne peut pas sauter la révision, chaque changement est audité deux fois, et les honoraires de gestion de la plateforme sont un montant fixe par fourchette de budget écrit une seule fois dans le code — il n'existe nulle part de variable par contact, par dossier ou en pourcentage avec laquelle un honoraire pourrait varier. Les opérations publicitaires réelles — comptes, dépenses, créations — demeurent celles du cabinet, externes par conception ; rien dans cette livraison ne déplace d'argent ni ne parle à un réseau publicitaire.

Le plan Pratique du syndic ouvre la phase 2 canadienne : des outils à tarif fixe qui ne peuvent structurellement pas acheter de visibilité (+25, newStandaloneTool)

• Les syndics autorisés en insolvabilité vérifiés peuvent désormais souscrire une trousse de pratique à 249 $ CA fixes par mois — organisation des dossiers, gestion documentaire, suivi des échéances et outils de flux de travail pour leurs propres opérations. L'architecture de conformité est le produit : les droits du plan ne peuvent pas exprimer de publicité ni de visibilité de place de marché, le répertoire ne lit prouvablement rien de lié au paiement, l'achat ne change rien à une inscription et une inscription n'exige jamais d'achat, et l'achat s'active compte par compte seulement après qu'un administrateur a lié le compte à un profil de syndic vérifié. Cette livraison a aussi comblé une lacune dormante : la règle « qui peut acheter » du plan professionnel existait depuis son lancement mais n'était jamais consultée au paiement — désormais une seule barrière d'achat décide de chaque plan contrôlé sur le chemin réel, délimitée par édition dans les deux sens, fermée par défaut sur toute identité non résolue, chaque refus étant audité.

Confidentialité des avatars resserrée : les visiteurs anonymes ne peuvent plus énumérer qui possède un compte (+5, hardening)

• Les photos de profil sont stockées sous des noms de fichiers qui intègrent des identifiants de compte, et la règle de stockage qui les rendait publiquement lisibles permettait aussi à tout client anonyme de lister le dossier entier — énumérant de fait les identifiants d'utilisateurs. La lecture est désormais limitée à chaque propriétaire : votre avatar s'affiche toujours partout comme avant (les liens d'images publics contournent cette règle par conception), les téléversements et suppressions conservent leurs protections existantes, mais le listage anonyme du répertoire a disparu.

Le durcissement de sécurité de la base de données arrive en trois lots auto-ajustables : surfaces d'injection épinglées, index en double supprimés, accès anonyme resserré (+5, hardening)

• Trois lots de maintenance, chacun écrit pour s'ajuster à ce qui reste à corriger et ne rien changer à ce qui est déjà correct : chaque fonction de la base reçoit un chemin de recherche épinglé (fermant une surface d'injection classique), chaque clé étrangère reçoit un index couvrant, les vérifications de sécurité par ligne sont réécrites pour s'évaluer une fois par requête plutôt qu'une fois par ligne, les index redondants sont supprimés, les visiteurs anonymes perdent la capacité d'exécuter des fonctions privilégiées qu'aucune politique de sécurité ne leur demande d'appeler, et chaque table délibérément verrouillée gagne une politique explicite réservée au service afin que son verrouillage soit visible pour les auditeurs plutôt qu'implicite. Rédigés par la boucle de maintenance autonome, adoptés avec les numéros de séquence corrigés ; rien dans ces lots ne change ce qu'un utilisateur peut voir ou faire.

Une mine silencieuse dans la base de données est désamorcée : les installations neuves ne s'arrêtent plus en plein montage (+5, hardening)

• Une migration de base de données contenait une règle écrite sous une forme que le moteur rejette, et comme la mise en place tolère discrètement certains environnements, une installation neuve cessait d'appliquer les changements à ce point sans échec bruyant — laissant toutes les tables ultérieures manquantes. La règle est désormais exprimée sous la forme correcte (un index unique partiel), le correctif crédite le réviseur autonome qui l'a repérée en premier, et un nouveau contrôle s'exécute à chaque commit pour que cette classe entière d'erreur ne puisse plus jamais entrer dans une migration.

La liste d'attente des campagnes gérées ouvre : un pur signal d'intérêt pour la phase 2, qui ne coûte rien et n'engage personne (+10, existingToolUpgrade)

• Les cabinets intéressés par des campagnes publicitaires entièrement gérées — une offre de phase 2 — peuvent désormais joindre une liste d'attente depuis la page d'inscription des avocats : cabinet, contact, État et la fourchette de budget mensuel envisagée. Le texte dit précisément ce que l'inscription fait et ne fait pas : elle ne coûte rien, n'engage personne, et aucune opération de campagne n'existe aujourd'hui. Les inscriptions atterrissent dans une table verrouillée aux vocabulaires fermés, et une vue administrative agrège la demande par État et par fourchette de budget — exactement le signal de validation que la décision de phase 2 du fondateur attendait.

Le plan Croissance entre en service pour les avocats en faillite : un emplacement publicitaire à tarif fixe, clairement étiqueté, qui ne peut jamais toucher le répertoire neutre (+10, existingToolUpgrade)

• Les avocats en faillite vérifiés peuvent désormais mettre à profit l'abonnement Croissance à 249 $ par mois : un emplacement publicitaire clairement étiqueté sur le guide de la faillite, plafonné, réparti aléatoirement à parts égales entre abonnés et visuellement séparé de tout ce qui est neutre. La séparation est structurelle, pas stylistique — la commandite vit dans sa propre table que le répertoire ne peut jamais joindre, la page de résultats neutres ne référence prouvablement jamais la facturation, et l'intégration continue vérifie ces deux faits à chaque commit. L'admissibilité revérifie la vérité de facturation à chaque affichage : un abonnement échu cesse immédiatement de s'afficher ; le tarif ne varie jamais selon les contacts ou les dossiers ; et l'étiquette de l'emplacement ainsi que la note de divulgation des agences d'allègement de dettes sont épinglées par test dans les trois langues. Un emplacement vide n'affiche rien du tout.

Le guide américain de la faillite et son questionnaire privé arrivent : chapitres 7 et 13 en langage clair, avec les étapes obligatoires cartographiées (+10, existingToolUpgrade)

• La voie américaine gagne sa porte d'entrée : un guide gratuit qui explique les chapitres 7 et 13 en termes généraux, parcourt le processus depuis la séance de conseil en crédit exigée par la loi jusqu'à la libération, et énonce clairement ce que la plateforme ne fait jamais — elle ne prépare, ne génère ni ne dépose jamais de requête ni aucun document de faillite. Un questionnaire de quatre questions s'exécute entièrement dans votre navigateur : les réponses ne sont jamais envoyées ni conservées, l'urgence ne façonne que l'information générale affichée (y compris le fonctionnement général de la suspension automatique), l'étape obligatoire de conseil est présentée sur chaque parcours, et la seule sortie est une vue filtrée du répertoire d'avocats vérifiés au barreau. Les ressources officielles — les notions de base des tribunaux fédéraux et les listes d'agences du ministère de la Justice — sont liées partout.

La voie américaine de la faillite ouvre : répertoire d'avocats vérifiés au barreau pour le Texas, la Floride et la Géorgie, avec l'étape obligatoire de conseil en crédit (+25, newStandaloneTool)

• Judge911 offre désormais un répertoire non classé d'avocats en faillite pour les trois États de lancement. Chaque avocat est vérifié au répertoire public du barreau de son État avant d'apparaître ; l'ordre est aléatoire à chaque affichage ; les seuls filtres sont l'État, le district fédéral, la langue et le domaine ; et aucun avocat ne paie pour figurer, pour figurer plus haut ou pour être recommandé — si de la publicité existe un jour, elle occupera des emplacements clairement séparés et étiquetés, jamais cette liste. Les avocats postulent par un formulaire libre-service gratuit avec une entente de participation versionnée qui énonce les règles : aucuns honoraires de recommandation, par contact ou par dossier dans un sens ou dans l'autre, et la plateforme ne prépare ni ne transmet jamais aucun dépôt. Une page dédiée explique la séance de conseil en crédit que la loi fédérale exige avant tout dépôt et dirige d'abord vers les listes officielles du ministère de la Justice — toute copie locale porte sa provenance par entrée et sa date de rafraîchissement. Les affichages du répertoire font l'objet d'un audit de confidentialité minimisé et sans identité conservé quatre-vingt-dix jours, à échec fermé : pas d'audit, pas de liste.

Les syndics peuvent maintenant joindre le répertoire : candidature libre-service gratuite, vérification de licence et entente de participation en langage clair (+10, existingToolUpgrade)

• Les syndics autorisés en insolvabilité demandent désormais leur inscription gratuite au répertoire par un formulaire libre-service. La candidature exige l'acceptation d'une entente de participation versionnée, en langage clair — aucuns honoraires de recommandation dans un sens ou dans l'autre, visibilité égale et non classée, le syndic demeurant responsable de sa propre conformité réglementaire — affichée intégralement, en trois langues, au-dessus de la case d'acceptation, la version acceptée étant épinglée au libellé exact présenté. Chaque candidature demeure en attente jusqu'à ce qu'un administrateur confirme la licence au registre public du BSF (la file de vérification offre la recherche officielle préremplie pour chaque candidat), et l'inscription n'apparaît qu'ensuite. Candidatures, vérifications et refus sont tous audités ; la route publique est limitée en débit ; et aucune étape de paiement n'existe nulle part dans le parcours — une inscription ne peut pas s'acheter, par schéma et par test.

La voie gratuite de l'insolvabilité ouvre : éducation en langage clair, questionnaire privé et répertoire non classé de syndics autorisés (+25, newStandaloneTool)

• Toute personne aux prises avec des dettes dispose désormais d'une section gratuite qui explique, en langage clair et en trois langues, ce que fait un syndic autorisé en insolvabilité, en quoi la proposition de consommateur diffère de la faillite et comment le processus se déroule — de l'information générale sous la stricte discipline sans-avis de la plateforme. Un questionnaire de quatre questions s'exécute entièrement dans votre navigateur : les réponses ne sont jamais envoyées ni conservées, et la seule sortie est une vue filtrée du répertoire des syndics. Le répertoire lui-même est construit comme la loi l'exige : chaque syndic affiché détient une licence du BSF vérifiée, l'ordre est aléatoire à chaque affichage, les seuls filtres sont la province, la langue et le domaine, personne ne paie pour figurer ni pour figurer plus haut — le schéma de la base de données ne peut même pas exprimer un classement — et vous contactez le syndic directement par ses coordonnées publiées, la plateforme n'étant jamais dans la conversation. Chaque affichage du répertoire fait l'objet d'un audit de confidentialité minimisé et sans identité, conservé quatre-vingt-dix jours ; si cet audit ne peut être consigné, la liste ne s'affiche pas, et l'outil officiel de recherche du BSF est offert sur chaque parcours.

La voie de l'insolvabilité est autorisée à la construction : les points de contrôle juridiques deviennent consultatifs par décision du fondateur (+2, maintenance)

• Le fondateur a exercé son autorité pour convertir les deux points de contrôle d'avis juridique de la voie de l'insolvabilité — canadien et américain — de bloquants en ordres du jour consultatifs permanents, et a ordonné la construction de bout en bout de tout l'arriéré restant. Ce qui ne change pas : tout ce que la loi elle-même exige — aucuns honoraires de recommandation, aucun placement payant, aucun classement lié au paiement dans la voie canadienne, et le refus absolu de l'édition américaine de préparer des dépôts de faillite. Ces protections sont d'ordre législatif, appliquées dans le code et l'intégration continue, et nul ne peut y renoncer. Les deux devis consignent la renonciation dans leur journal de décisions, et les six chantiers d'insolvabilité qu'elle débloque entrent dans la file.

La résidence des données devient un attribut épinglé et prouvable : région par catégorie, loi applicable et un pipeline de changement qui sait refuser (+10, existingToolUpgrade)

• Chaque dossier juridique, élément de preuve et enregistrement de facturation porte désormais sa région de stockage dès sa première écriture — estampillée par la base de données elle-même, de sorte qu'aucun chemin de code ne peut l'oublier. Une nouvelle section Résidence des données dans les paramètres montre, par catégorie, où résident les données, quelle loi les régit et si la gouvernance a gelé les changements. Le pipeline de changement est volontairement strict : le nouveau consentement à la juridiction précède toute migration, chaque changement est audité avec horodatage serveur — la juridiction applicable à tout enregistrement est prouvable pour toute date passée —, une mise en réserve juridique active gèle tout, et aucune région que l'infrastructure ne peut physiquement honorer n'est offerte : la plateforme refuse que la déclaration de résidence devance les octets réels. Toutes les données résident actuellement au Canada, sous le droit fédéral canadien et la Loi 25 du Québec ; d'autres régions n'arriveront qu'avec une véritable infrastructure multi-régions.

La limitation de débit apprend à compter entre serveurs : limiteur distribué + dédoublonnage des erreurs à la minute (+5, hardening)

• L'ingestion des rapports d'erreur n'était limitée que par instance de serveur : un attaquant frappant plusieurs instances tièdes multipliait son budget et pouvait inonder le journal de télémétrie. Trois couches se conjuguent désormais : le limiteur en mémoire demeure le plancher toujours actif, un compteur Redis partagé par toutes les instances applique la vraie limite par adresse IP dès que l'opérateur configure le service (il échoue en mode ouvert — une panne ne bloque jamais l'ingestion), et la base de données elle-même regroupe les erreurs identiques d'une même page en une seule ligne par minute — même une inondation qui contourne la limitation en changeant d'adresse ne peut enterrer les vrais signaux sous les doublons. La file d'actions de l'opérateur et le point de contrôle de santé rapportent désormais le service distribué honnêtement : l'application n'est déclarée que lorsque le service est pleinement utilisable et réellement branché à une route.

La clé du sélecteur Drive quitte le bundle public : servie à l'exécution, réservée aux utilisateurs authentifiés (+5, hardening)

• L'import Google Drive incorporait jusqu'ici sa clé de développeur du sélecteur dans le bundle JavaScript téléchargé par chaque visiteur — connecté ou non. La clé demeure désormais côté serveur et n'est remise qu'aux utilisateurs authentifiés via un point de configuration dédié aux en-têtes de cache privés : elle peut être remplacée sans reconstruction et les visiteurs anonymes ne la reçoivent jamais. Un test de régression épinglé la garde hors du bundle pour de bon, et les déploiements migrent la clé vers une variable d'environnement non publique à leur rythme — l'ancienne variable continue de fonctionner en solution de repli.

La barrière du backlog devient calculable par machine : les classes résiduelles formalisées dans la spec du runner (+2, maintenance)

• La spec du runner de backlog autonome définit désormais formellement les classes résiduelles qu'un agent ne peut jamais résorber — les barrières humaines, le travail transitivement bloqué par une barrière humaine, les éléments reportés en Phase 2 par décision du fondateur et les épics de suivi — et la règle de sélection comme la barrière de complétion les excluent par étiquette. Le tableau a été étiqueté en conséquence, avec l'autorité bloquante et l'action de déblocage exacte documentées sur chaque enjeu résiduel : la complétion d'une phase se calcule désormais à partir des seules étiquettes, et aucun passage futur du runner ne peut confondre un chantier soumis à l'avis d'un conseiller juridique avec du travail exécutable.

La boucle de réseau se ferme : les résultats réels alimentent désormais la primitive d'apprentissage — mur des dossiers intact (+10, existingToolUpgrade)

• Les dossiers peuvent désormais consigner leur dénouement comme événement de résultat à part entière, et une tâche planifiée transforme ces événements en cohortes anonymisées (k) dont la couche d'appariement a été conçue pour apprendre. Les garanties de confidentialité tiennent à chaque niveau : les enregistrements incomplets sont écartés plutôt que déduits, l'agrégation prouve la désidentification avant toute persistance, le schéma de stockage lui-même refuse toute cohorte de moins de cinq dossiers, et le paiement demeure structurellement absent de toute la boucle. L'activation des poids appris dans l'appariement en direct demeure une décision explicite — jamais un changement de classement silencieux.

Quatre documents dont tout le monde a besoin, gratuits et à compléter (+25, newStandaloneTool)

• Une bibliothèque publique de modèles ouvre avec les quatre documents organisationnels dont presque tout litige a besoin : une mise en demeure, une chronologie datée, une liste des pièces et un inventaire de la preuve — bilingues, à champs à compléter, téléchargeables sans compte, et portant l'avertissement informatif à même le document. De la structure, pas des conseils : les modèles organisent votre propre situation, et chaque page achemine vers les parcours guidés et le dossier. Un invariant est imposé par test pour toujours : ce catalogue ne peut jamais contenir un document de dépôt de faillite.

Les partenaires affichent leur relation d'argent (+10, existingToolUpgrade)

• Chaque partenariat porte désormais une relation d'argent explicite, et les règles sont structurelles : toute voie pouvant diriger une personne vers un service juridique — cliniques, organismes communautaires, professionnels du droit, institutions — est en permanence une relation d'orientation réciproque non rémunérée, avec une attestation bilingue d'absence de contrepartie; l'affiliation payée n'existe que pour la promotion des produits d'information d'auto-assistance et repose sur le garde anti-partage d'honoraires qui ne paie rien d'autre. Un nouveau garde encode aussi quand un syndic autorisé en insolvabilité peut être inscrit : entente de participation signée ET permis du BSF vérifié, les deux, sans exception. La file d'examen administrative étiquette la relation de chaque candidat, et une nouvelle vue administrative journalisée expose les codes d'affiliation, les attributions au premier contact et les commissions accumulées sur les produits d'information.

L'exclusion faillite couvre désormais aussi les dépôts d'entreprise (+5, hardening)

• Le garde qui empêche l'édition américaine de préparer un dépôt de faillite gagne la paperasse des personnes morales : les formulaires officiels 201 à 207 — la requête volontaire d'entreprise, les déclarations, annexes et états — sont désormais refusés par leur seul numéro de formulaire, sans mot-clé de faillite requis, exactement comme les formulaires individuels l'étaient déjà. Quatre demandes de formulaires d'entreprise rejoignent l'ensemble de tests bloqués.

Les guides ont désormais une juridiction d'attache — et l'Ontario reçoit son premier (+10, existingToolUpgrade)

• Chaque guide juridique appartient désormais à une grappe de juridiction, et des pages-carrefours les ancrent : tous les guides existants rejoignent la grappe du Québec, et un nouveau guide bilingue de l'Ontario — organiser une réclamation à la Cour des petites créances jusqu'au plafond vérifié de 35 000 $ — inaugure la grappe ontarienne. Chaque carrefour relie ses guides, la page des faits structurels de la juridiction et le pipeline, complétant la structure en étoile entre guides, réponses et pages de juridiction.

Le registre d'affiliation existe — et il ne peut pas contenir une commission interdite (+5, hardening)

• Le programme d'affiliation gagne sa couche de persistance par-dessus le garde anti-partage d'honoraires : une table de codes avec un seul code émis par le serveur par affilié, une table d'attribution au premier contact, et un registre de commissions dont le schéma lui-même refuse toute ligne qui n'est pas un produit d'information d'auto-assistance — une commission sur un engagement de service juridique constitue une violation de contrainte de base de données, en dessous de tout bogue applicatif. Une commission par commande, à l'épreuve de la falsification (chaque affilié ne lit que ses lignes; seuls les gestionnaires côté serveur écrivent), et un nouveau lien d'entrée appose l'attribution d'affiliation sur la télémétrie existante sans témoins, avec une locale validée et sans moyen de sonder quels codes existent.

Le forfait Professionnel existe — et il est structurellement incapable de vendre de l'influence (+25, paymentsPayoutsGate)

• Un quatrième forfait rejoint le catalogue : Professionnel, le palier ratifié à 249 $ fixes par mois pour les professionnels vérifiés, offert sur l'édition américaine seulement. Il n'achète que deux choses — des espaces publicitaires clairement identifiés et des outils de pratique — et l'architecture rend tout le reste impossible : le code d'acheminement et d'appariement a interdiction de lire quelque état de facturation que ce soit, chaque abonné paie le même tarif fixe, et les syndics autorisés en insolvabilité sont exclus deux fois plutôt qu'une — le garde d'achat les refuse (fermé par défaut devant tout type de fournisseur inconnu) et la base de données elle-même rejette la ligne. Chaque professionnel ne lit que son propre statut d'abonnement; seuls les gestionnaires côté serveur du processeur de paiement peuvent y écrire.

Correction d'une collision de numéro de migration sur la table d'audit de consultation insolvabilité (+2)

• La migration du journal d'audit de la voie insolvabilité et une migration de signaux de pré-qualification fusionnée séparément portaient toutes deux le numéro 0117. La migration d'audit de consultation est renumérotée 0118 afin qu'elles n'entrent plus en collision, rétablissant le garde-fou d'ordonnancement des migrations. Aucun changement de schéma — une correction de numérotation uniquement (les deux tables restent non appliquées, sous réserve de lancement).

Les dépôts au tribunal sont validés avant de quitter la maison (+5, durcissement #412)

• La route de dépôt au tribunal valide désormais les documents sélectionnés par rapport au profil de dépôt électronique du tribunal avant de les envoyer à un fournisseur : formats non pris en charge, fichiers trop volumineux, trop de documents ou de pièces, et parties ou documents manquants sont tous détectés en amont et renvoyés sous forme d'erreurs structurées, par document et bilingues. La route charge aussi le dossier selon vos propres règles d'accès, de sorte qu'un dépôt ne peut être soumis que pour un dossier que vous pouvez réellement consulter.

Les dossiers portent leur litige; le récapitulatif de portefeuille les compte (+5, câblage ADR-0003 C4)

• Le modèle de dossier côté client porte désormais l'identifiant de son litige (portefeuille), alimenté depuis la colonne faisant autorité matters.portfolio_id au chargement des dossiers. Le récapitulatif de portefeuille s'en sert pour indiquer combien de litiges distincts couvrent vos dossiers ouverts — affiché seulement lorsque des dossiers se regroupent réellement sous un même litige. Cela complète le chemin de lecture de l'ADR-0003 C4; la racine de navigation peut désormais regrouper par identifiant de litige sans câblage supplémentaire.

Correction du journal : deux versions du 19 juin partageaient le même numéro (+2)

• Deux versions distinctes du 19 juin portaient toutes deux le numéro 7.21.77 dans le journal — la version « découverte de recherche / contrôles de la page d'accueil » est désormais correctement 7.21.78, au-dessus de la version « calendrier procédural Gardez la date » à 7.21.77. Il s'agissait d'une simple correction d'affichage dans l'historique du journal; la version du produit en ligne n'est pas touchée et continue de progresser à chaque déploiement (le numéro de version du pied de page est intégré à la version compilée et reflète donc toujours exactement ce qui est déployé).

Les signaux de viabilité du dossier sont internes — jamais montrés à l'utilisateur (+10, durcissement UPL #1449)

• Le résultat de structuration du dossier par l'IA n'affiche plus à l'utilisateur de score de viabilité (riskLevel) ni de verdict de routage — présenter un signal de solidité du dossier à une personne non représentée constitue un risque d'exercice illégal du droit. Ces signaux restent produits, conservés et consignés sur la chaîne d'audit comme couche de routage interne, mais un nouveau garde-fou de sortie les retire de la réponse d'API destinée à l'utilisateur et échoue de manière sûre si l'un d'eux passait malgré tout. L'écran de résumé du dossier retire la pastille de risque en conséquence.

Substrat de confidentialité de la voie insolvabilité : journal d'audit de consultation minimisé + exception de contact publié (+10, #1441)

• La voie insolvabilité canadienne reçoit son substrat de confidentialité Loi 25 avant le lancement : un journal d'audit des consultations du répertoire, minimisé (une session pseudonyme, les filtres objectifs et les syndics affichés — jamais l'identité du débiteur ni ses difficultés financières), stocké dans une table accessible au seul rôle de service avec une rétention de 90 jours, écrit via la chaîne d'audit inviolable. Le garde-fou anti-désintermédiation du marché comporte désormais une exception explicite et testée pour les fiches publiées de syndics. Une ébauche d'évaluation des facteurs relatifs à la vie privée (Loi 25) est incluse pour le conseiller juridique; la voie elle-même ne sera lancée qu'après cette approbation.

Apprentissage des résultats sans jamais franchir le mur du dossier : k-anonymisé, insensible au paiement (+5, #1458)

• Fondations de la boucle réseau : les résultats de résolution par dossier peuvent désormais devenir un signal agrégé et dépersonnalisé qui améliore l'appariement objectif (région, langue, spécialisation) sans qu'aucune donnée par dossier ne franchisse la frontière d'isolation des dossiers. Deux garanties sont appliquées dans le code et prouvées par des tests : la k-anonymat et l'absence d'identifiant franchissant la frontière. Les poids d'appariement ne lisent que la distribution des résultats — le paiement ne peut influencer le routage. Une ébauche d'évaluation des facteurs relatifs à la vie privée (Loi 25) est incluse pour le conseiller juridique.

Commissions d'affiliation : produits d'information seulement, partage d'honoraires bloqué dans le code (+5, #1455)

• Le programme d'affiliation ne peut verser une commission que sur une seule chose — les produits d'information d'auto-assistance (livrables documentaires de 20 $/500 $) — et sur rien d'autre. Un garde-fou codé refuse toute commission liée à un avocat, à un syndic autorisé en insolvabilité ou à tout autre service professionnel ou renvoi, car payer pour cela constituerait un partage d'honoraires (règle 5.4) et ferait de la plateforme un arrangeur de renvois (Directive OSB 1R8) — le modèle qui a coulé Avvo. Il échoue de manière sûre : un engagement non reconnu est traité comme un service juridique et ne paie rien. Des tests unitaires prouvent qu'un engagement avocat/syndic ne génère aucune commission, quel que soit le montant ou le taux. Le registre de paiement et le chemin Stripe suivront, avec une revue d'un spécialiste des paiements.

Palier d'abonnement professionnel : achète de la visibilité, jamais une priorité de routage (+5, #1454)

• Fondations d'un abonnement professionnel à tarif forfaitaire (dont le palier Croissance US à 249 $/mois ratifié) que les cabinets et avocats peuvent acheter pour de la publicité et des outils — et jamais pour une priorité de routage. Trois invariants de conformité sont appliqués dans le code et prouvés par des tests : l'indépendance du routage, une exclusion stricte des syndics autorisés en insolvabilité, et une tarification uniquement forfaitaire (jamais par prospect ni conditionnelle — la ligne de la règle 7.2(b)(1) qui a coulé Avvo). La persistance de l'abonnement et le câblage des prix Stripe suivront, avec une revue d'un spécialiste des paiements.

Renvois d'institutions : non rémunérés par conception, absence de contrepartie prouvée dans le code (+5, #1456)

• Fondations pour modéliser les partenaires institutionnels (cliniques juridiques, organismes d'aide aux immigrants et de conseil en endettement) comme des relations de renvoi explicitement rémunérées ou non. Un renvoi non rémunéré ne doit démontrablement comporter aucune contrepartie — un invariant codé signale toute relation non rémunérée à laquelle de l'argent est rattaché et un garde-fou d'écriture à sûreté intégrée refuse de la conserver, gardant la plateforme à l'écart de la ligne de l'arrangement de renvois / partage d'honoraires (règle 7.2(b) / Directive OSB 1R8). Chaque relation porte une étiquette rémunéré/non rémunéré et, lorsqu'elle est non rémunérée, une attestation d'absence de contrepartie requise, de sorte qu'une console d'administration peut afficher exactement la nature de chaque partenariat. L'interface de la console et l'intégration accord de participation / vérification de licence des syndics s'appuient sur ce modèle.

La précision du triage est désormais un chiffre mesuré — et la mesure a immédiatement attrapé deux bogues (+10, existingToolUpgrade)

• Un ensemble étalon bilingue de 26 récits d'admission réalistes note désormais le classificateur de triage à chaque exécution des tests, avec deux portes indépendantes : un plancher de précision commis qu'aucun changement ne peut faire régresser, et une porte stricte de zéro raté sur les récits critiques — éviction et détention — où un mauvais aiguillage coûte le plus cher. Construire la mesure s'est immédiatement rentabilisé : elle a révélé que les récits de détention n'avaient aucun vocabulaire, et que l'expression anglaise bail hearing entrait en collision avec le mot-clé français bail, envoyant un récit d'arrestation vers le logement. Les deux sont corrigés : le classificateur gagne les vocabulaires carcéral, d'insolvabilité et d'éviction, et la détention gagne désormais toujours l'égalité.

Chaque juridiction a sa porte d'entrée : 18 pages-carrefours ancrent les grappes de contenu (+10, existingToolUpgrade)

• Dix-huit pages-carrefours de juridiction — chaque province et territoire canadien, le palier fédéral et les États de lancement du Texas, de la Floride et de la Géorgie — rassemblent désormais les faits structurels de chaque endroit sur une seule page : ses tribunaux, le plafond et le forum des petites créances, la voie d'appel, les langues de travail et la vérification d'un professionnel auprès du registre officiel. Chaque carrefour recense aussi toutes les questions auxquelles la plateforme répond pour cette juridiction, formant la structure en étoile que les moteurs de recherche récompensent. Tout provient des ensembles de données structurelles vérifiés de la plateforme; la couche éditoriale (personnes-ressources, ressources choisies) est délibérément laissée à un suivi éditorial documenté plutôt qu'inventée.

Que se passe-t-il si… ? — des parcours à embranchements qui mènent quelque part (+10, existingToolUpgrade)

• Un nouveau type de page répond au format de question que les moteurs de recherche ne savent pas traiter : que se passe-t-il ensuite à partir de VOTRE situation. Le premier parcours — que se passe-t-il si mon locateur refuse de faire les réparations — pose quelques questions factuelles (santé et sécurité ? demande écrite envoyée ? une réponse ?) et décrit le processus selon chaque embranchement : la voie accélérée au TAL, le point de départ de la mise en demeure, ou le recours après le silence. Les réponses ne quittent jamais le navigateur; chaque fin achemine vers un parcours guidé, un dossier ou le répertoire de professionnels; et le contenu décrit le processus, jamais les chances — un test prouve qu'aucun embranchement ne peut énoncer un jugement sur la valeur d'une cause.

111 questions, 111 vraies réponses : le moteur de longue traîne entre en service (+25, newStandaloneTool)

• Un nouveau moteur de contenu programmatique répond aux questions que les gens cherchent réellement : le plafond des petites créances dans chaque province, où déposer une demande, quels tribunaux entendent les causes et les appels, comment vérifier le permis d'un avocat, quel professionnel s'occupe de chaque domaine de pratique et que faire face aux problèmes de consommation courants. Chacune des 111 pages est générée à partir des données structurées bilingues de la plateforme — plafonds des petites créances, structures judiciaires, registres des barreaux, taxonomie des domaines du Barreau — jamais du remplissage : une page n'existe que là où de vraies données y répondent. Chaque page paraît en français et en anglais avec le balisage FAQ des moteurs de recherche, achemine les lecteurs vers le pipeline et porte l'avertissement informatif standard.

Le score de risque quitte l'écran : l'analyse est éducative, les signaux passent à l'interne (+25, legalComplianceGate)

• Décision du fondateur : afficher un score numérique de risque à la personne qui a écrit le récit constitue un avis juridique. Corrigé de bout en bout — avant toute analyse, le client reconnaît désormais explicitement que le résultat est de l'information éducative offerte pour l'aider à organiser sa propre situation, et non un avis juridique, et cette reconnaissance est horodatée avec la demande. Le score de risque lui-même n'apparaît plus nulle part où un utilisateur ou un professionnel peut le voir : il migre, avec de nouveaux signaux internes de préqualification (complétude de l'admission, détection des doublons, indicateurs de faible valeur, acheminement d'urgence), vers une table interne verrouillée que même le titulaire de la demande ne peut lire. Des invariants de test imposent chaque pièce : la charge utile épurée, l'insigne disparu, la case de reconnaissance obligatoire et le verrou total sur les signaux.

Le centre de commandement surveille le flux : un entonnoir en direct de l'admission au résultat (+10, existingToolUpgrade)

• Un nouvel onglet Flux dans le centre de commandement du fondateur transforme la télémétrie du cycle de vie en entonnoir ordonné : admission commencée, admission complétée, répertoire consulté, professionnel contacté, résultat enregistré — avec la conversion par étape, le décrochage et le principal goulot d'étranglement mis en évidence. Les décomptes s'agrègent sur une fenêtre de 30 jours dans le point d'accès de métriques existant, réservé aux administrateurs et journalisé; le panneau lui-même n'est que de l'arithmétique sur cet agrégat. Pour la première fois, la plateforme répond d'un coup d'œil : où les gens décrochent-ils entre l'arrivée avec un problème et l'obtention d'aide ?

L'entonnoir devient mesurable : événements d'admission, de répertoire, de contact et de résultat (+10, existingToolUpgrade)

• Cinq événements de cycle de vie circulent désormais dans le canal de télémétrie de croissance : le début d'une admission, la persistance d'une demande structurée, la consultation d'un répertoire de professionnels, la prise de contact directe avec un professionnel et l'enregistrement du résultat d'un dossier. Chacun est typé dans le registre analytique avec un nom de fil documenté, reflété dans la taxonomie canonique, et réellement émis depuis le constructeur de dossier, le catalogue du marché et les profils de professionnels. Les charges utiles ne transportent que des identifiants et des codes — jamais le récit ni des détails personnels, ce qu'un test impose. C'est le substrat que lira ensuite le panneau de surveillance des flux : pour la première fois, la plateforme peut mesurer où les gens décrochent entre leur arrivée et l'obtention d'aide.

L'admission demande où et à quel point c'est urgent — et l'acheminement utilise enfin les réponses (+10, existingToolUpgrade)

• Le constructeur de dossier capte désormais deux champs structurés qu'il ne demandait jamais : votre région (selon l'édition — le Québec, toutes les provinces et territoires sur l'édition canadienne, et les États de lancement Texas/Floride/Géorgie sur l'édition américaine) et le degré d'urgence de la situation. Jusqu'ici, chaque demande était acheminée avec une région inconnue — le poids de 25 % de la juridiction dans l'appariement était mort — et l'urgence retombait toujours par prudence au niveau critique. Les deux champs sont conservés avec la demande, les critères d'acheminement sont divulgués en langage clair directement dans le formulaire, et une nouvelle bibliothèque d'admissibilité fait de la région un filtre strict : l'aide hors région est exclue, jamais simplement rétrogradée, et le paiement ne peut jamais être un intrant.

Par où commencer ? — un vérificateur de problème juridique gratuit et privé (+25, newStandaloneTool)

• Un nouvel outil public répond à la question qui amène la plupart des visiteurs : par où commencer ? Décrivez votre situation dans vos mots — en français, en anglais ou en espagnol — et la plateforme détecte le sujet juridique et indique le bon point de départ : ouvrir un dossier, parcourir les problèmes courants ou trouver un professionnel. L'analyse s'exécute entièrement dans votre navigateur : rien de ce que vous écrivez n'est envoyé ni conservé, et un invariant de test impose cette promesse dans le code. Le résultat est délibérément informatif — il nomme un sujet, jamais une opinion sur votre cause. Chaque page de contenu peut désormais y acheminer ses lecteurs, complétant l'entonnoir de captation d'intention.

Les guides et articles de recherche acheminent désormais les lecteurs vers le pipeline (+10, existingToolUpgrade)

• Chaque guide juridique et publication de recherche se termine désormais par une prochaine étape claire : ouvrir un dossier pour organiser sa situation, ou trouver un professionnel vérifié. Auparavant, les plus grands contenus indexés de la plateforme se terminaient par un avertissement sans suite possible. L'appel à l'action est bilingue, délibérément informatif (aucun langage sur le mérite d'une cause — imposé par un test qui a même attrapé sa propre documentation pendant le développement), et instrumenté pour que l'entonnoir d'acquisition mesure la conversion du contenu vers l'admission.

Des centaines de pages cachées rejoignent le plan du site : parcours de problèmes et taxonomie des domaines juridiques (+10, existingToolUpgrade)

• Deux familles de pages programmatiques s'affichaient pour les utilisateurs mais restaient invisibles aux moteurs de recherche : les parcours de problèmes de consommation (/problems) et la taxonomie québécoise des domaines juridiques (/domaines, index et chaque nœud). Les deux sont désormais énumérées dans les plans de site par langue avec toutes les alternatives hreflang — sensibles à l'édition, de sorte que l'édition américaine expédie son propre ensemble de problèmes et que la taxonomie des domaines reste propre au Québec. C'est la première brique de la couche SEO du plan d'acquisition : des pages de captation d'intention déjà existantes deviennent découvrables.

L'édition américaine ne peut jamais préparer un dépôt de faillite — appliqué dans le code (+5, hardening)

• Un garde-fou à fermeture stricte protège désormais les deux moteurs de documents : sur l'édition américaine, toute demande qui s'apparente à un document de dépôt de faillite — requêtes, formulaires officiels 101 à 199, annexes, test des moyens, états des affaires financières, accords de réaffirmation, preuves de réclamation, matrices de créanciers — est refusée avant tout travail, tant dans le générateur de projets d'actes que dans la capacité de rédaction par IA. Un invariant de test garantit aussi qu'aucun catalogue de documents ne puisse acquérir un type de dépôt de faillite à l'insu de tous. Ceci applique 11 U.S.C. §110 (préparateur de requêtes de faillite) à la porte d'édition : la plateforme éduque, informe et achemine — elle ne prépare jamais de dépôts de faillite. Les éditions canadiennes ne sont pas touchées.

Les syndics quittent le marché : le garde-fou insolvabilité est désormais appliqué dans le code (+5, hardening)

• Les syndics autorisés en insolvabilité n'apparaissent plus nulle part dans le marché payant classé : la catégorie et le profil-témoin de syndic sont retirés du catalogue des prestataires, le moteur d'acheminement de pistes payantes exclut désormais strictement les entités syndic de son bassin de candidats, et la primitive d'appariement des syndics a été reconstruite en répertoire non classé fondé sur la seule admissibilité — le champ de majoration payante et le classement par score sont supprimés purement et simplement. Un nouveau garde-fou de conformité transforme ces interdictions en invariants de test permanents : toute tentative de réintroduire un champ de paiement ou de classement sur une surface syndic fait échouer l'intégration continue. Ceci applique la spécification de la voie insolvabilité (Règles LFI art. 49, Instruction 1R8 du BSF) au niveau du code.

Le carnet devient la machine : spécification du exécuteur autonome + gabarits de tickets imposés (+2, maintenance)

• Le modèle d'exécution du développement autonome de la plateforme est désormais un contrat committé : docs/AUTONOMOUS_BACKLOG_RUNNER.md définit une exécution monofil à livraison complète (sélectionner → construire la tranche verticale entière → valider contre les critères d'acceptation → livrer → fermer avec preuves), un protocole de blocage qui reséquence au lieu d'arrêter, et une porte de complétion qui traite correctement les décisions du fondateur et des conseillers juridiques comme des portes humaines qu'aucun exécuteur ne peut toucher. De nouveaux gabarits de tickets GitHub (tâche, blocage, porte humaine) rendent obligatoires l'objectif, les détails d'implémentation, les dépendances et des critères d'acceptation testables sur chaque unité de travail suivie.

La voie insolvabilité tracée : spécifications CA/QC et É.-U. séparées par marché, avec garde-fous réglementaires (+25, legalComplianceGate)

• Deux spécifications de phase 1 arrivent pour le pilote faillite et insolvabilité, délibérément séparées par marché. La voie Canada/Québec s'appuie sur les Règles générales de la LFI (art. 49/51/52) et l'Instruction 1R8 du BSF : un répertoire gratuit et non classé de syndics autorisés en insolvabilité avec admission des débiteurs et contenu éducatif — découplé de tout produit payant par décision du fondateur, la publicité financée par les syndics étant interdite en permanence. La voie américaine (judge911.com) s'appuie sur 11 U.S.C. §110 : la plateforme ne préparera jamais de documents de faillite, achemine les débiteurs vers des avocats et des agences approuvées par le UST au Texas et en Floride (Géorgie en option), et monétise la publicité forfaitaire côté avocats à 249 $/mois fixe, les campagnes gérées étant reportées à la phase 2. Les deux voies sont conditionnées à l'aval des conseillers juridiques avant toute interface destinée aux professionnels. Une stratégie d'acquisition sans publicité payante, réconciliée avec la réglementation, accompagne les spécifications.

Le récapitulatif de litige atterrit sur la vue de portefeuille (+5, cœur de lecture ADR-0003 C4)

• La vue de portefeuille reçoit une bande récapitulative inter-dossiers — dossiers, échéances ouvertes et en retard, documents, et étapes de résolution requises ouvertes, sommés sur les dossiers affichés — à partir d'une agrégation pure et testée unitairement. C'est le cœur de lecture de l'ADR-0003 C4; le regroupement complet à la racine de navigation par litige nécessite en plus que le modèle de dossier client porte son identifiant de litige transmis via la synchronisation, ce qui est du câblage pur au-dessus de cette logique.

Les nouveaux dossiers naissent toujours dans un litige (+5, ADR-0003 C3)

• Le chemin de synchronisation des dossiers écrit désormais en double : créer un nouveau dossier auto-crée son litige englobant (portefeuille) et le relie dans la même requête, de sorte qu'aucun dossier ne peut atterrir sans litige — un changement invisible pour le flux à dossier unique. Les dossiers existants gardent le litige qu'ils ont déjà; un échec de création de litige fait échouer toute la synchronisation bruyamment afin qu'aucun dossier orphelin ne soit écrit. Une fois le remplissage C2 exécuté, aucun dossier nulle part ne manque de litige, dégageant la voie pour la finale non-null.

Outil de remplissage des litiges : envelopper chaque dossier, de façon idempotente et à sec d'abord (+5, ADR-0003 C2)

• Le remplissage 1:1 qui enveloppe chaque dossier existant dans un litige arrive sous forme de script exécuté par l'opérateur — à sec par défaut, idempotent (les dossiers déjà enveloppés ne produisent aucun travail), par lots, héritant du propriétaire, de l'organisation et du titre du dossier, et marquant les litiges auto-créés pour qu'ils restent réversibles avant la finale non-null. Il affirme l'acceptation de l'ADR (zéro dossier non enveloppé restant) après application. La logique de planification pure est testée unitairement.

Le litige-parent atterrit sur le substrat de portefeuille (+10, ADR-0003 C1)

• L'entité litige-parent de l'ADR-0003 est construite de façon additive sur la table portefeuille existante (option a — l'objet d'admission disputes de Judge911 garde son sens opposé) : un statut de cycle de vie avec un état de conservation légale, un lien d'organisation et une étiquette de grappe-de-problème s'y ajoutent, les lectures de portefeuille dérivent désormais vers le bas de sorte qu'un collaborateur de dossier voit le litige englobant (réutilisant la fonction d'accès aux dossiers sans modification), et une conservation légale sur le litige se répercute pour bloquer chaque transition de cycle de vie des dossiers enfants au niveau de la base de données. Une matrice d'accès à sept cas et des invariants de migration l'accompagnent.

La liste blanche des partages devient l'unique mur de sous-ensemble — abandon auto-vérifié des tableaux (+5, finale ADR-0001)

• La migration 0115 complète la migration de liste blanche sans fuite : le prédicat de tableaux uuid[] hérité est retiré des politiques SELECT des documents, pièces et preuves, de sorte que les tables de liste blanche à intégrité référentielle sont l'unique mur des partages restreints. L'abandon est auto-vérifié — un garde en transaction affirme que chaque octroi restreint actif est couvert par une ligne de liste blanche non révoquée et lève une erreur à fermeture sûre en cas d'écart, ne nécessitant donc aucune vérification manuelle de parité en préproduction et ne pouvant jamais changer silencieusement l'accès. La fonction et les colonnes de tableaux sont conservées, gardant la migration réversible.

La fumée Playwright de nouveau au vert — les 503 d'artefact CI ne sont plus lus comme des erreurs d'app (+5 correctif, #1406)

• L'échec de fumée généralisé est résolu à sa vraie racine : l'environnement CI n'a ni Supabase ni CDN, donc les routes d'API de l'app répondent correctement 503 (backend désactivé) et certains actifs 404 — des échecs de chargement de ressource réseau que le test d'intégrité prenait pour des erreurs d'exécution applicatives. Le test filtre désormais ces chargements réseau tout en échouant sur les vraies exceptions JS et toute page d'erreur dans le corps; la CI démarre aussi le serveur de production (stable en mémoire) plutôt que le serveur de dev dont le garde redémarrait en pleine balayage.

Superviseur de limite de débit : la boucle autonome survit à un 429 sans surveillance (+10)

• Un superviseur de résilience enveloppe n'importe quelle commande — l'agent sans interface, un déploiement — et, lorsque sa sortie porte le 429 transitoire « Server is temporarily limiting requests · Rate limited » (celui qui survient au changement de modèle), plus 529/surcharge/réinitialisations de connexion, rétablit et relance la commande après un Retry-After respecté ou un recul exponentiel. Les vraies erreurs de compilation ou de test ne sont jamais masquées; elles remontent immédiatement. La logique pure de détection et de recul est testée unitairement; un workflow GitHub compagnon pour l'exécuter sans surveillance est fourni pour qu'un humain l'applique (le jeton de l'agent ne peut pousser de fichiers de workflow).

Compte rendu de session de la journée : quatre dossiers clos, deux programmes d'ADR exécutés (+1 docs)

• SESSION_20260702_full-day.md consigne la journée de bout en bout — les quatre clôtures, la séance de décisions et les deux programmes d'ADR, la voie espagnole, l'incident de production, la réconciliation du versionnage, et la carte complète de qui-débloque-quoi pour les vingt-deux dossiers restants.

Les constats de portefeuille parlent espagnol — la voie de contenu rédigé clôt sa liste (+1 copie)

• Les huit gabarits de constats inter-dossiers — parties communes, avocat commun, témoins communs, grappes de retards, collisions d'échéances, semaines chargées, dossiers devant le même foro et charge de portefeuille — sont rédigés en espagnol, titres et détails avec leurs interpolations vivantes intactes. Chaque surface nommée de la voie de contenu espagnol est désormais rédigée : catalogue, pipelines, parcours, étapes, détails, préparation, escalade et intelligence de portefeuille.

Les constats de portefeuille reçoivent leur couture espagnole (+1 copie)

• Les constats d'axes inter-dossiers reçoivent le champ de titre espagnol et le tableau de portefeuille résout désormais les titres de constats via la couture trilingue — une ternaire brute de plus éliminée — de sorte que les neuf gabarits de constats générés pourront être rédigés en espagnol sans autre câblage.

Les détails d'étapes complètent l'expérience de résolution en espagnol (+1 copie)

• Les quatorze détails d'étapes propres aux catégories — dépôts auprès des régulateurs avec leurs délais, fenêtres de griefs syndicaux, limites de la CNESST, contestations devant les tribunaux administratifs, réclamations de garantie, niveaux de griefs des détenus, présentations à la Commission des libérations conditionnelles et révision en Cour fédérale — sont rédigés en espagnol. Chaque parcours, étape, étiquette et détail du système de résolution s'affiche désormais nativement pour les citoyens hispanophones.

Chaque étiquette d'étape de parcours parle espagnol (+1 copie)

• Les quatorze étiquettes d'étapes propres aux catégories — escalade interne, régulateurs (consommation, travail, finance), conciliation, griefs syndicaux, tribunaux administratifs, comités de révision, recours en garantie, projets de règlement, griefs de détenus, la Commission des libérations conditionnelles et la révision judiciaire — sont rédigées en espagnol, complétant les étiquettes espagnoles de chaque étape des douze parcours de résolution. (Corrige aussi la note de calibrage de l'entrée précédente : c'était une version d'un point.)

Les pipelines de services se suivent en espagnol (+2 maintenance)

• Les neuf pipelines de jalons de services — de la validation du document à l'assermentation, aux tentatives de signification, à la traduction, aux rapports d'expert, aux consultations, à l'impression, à la transcription et à la notarisation jusqu'à la livraison finale — sont rédigés en espagnol, et la fonction d'instantané du pipeline résout désormais les étiquettes via la couture trilingue, rendant le suivi des commandes en espagnol opérationnel de bout en bout.

L'échelle d'escalade parle espagnol (+1 copie)

• Les cinq voies d'escalade — réclamation, suivi au superviseur, direction ou régulateur, ombudsman et médiation — sont rédigées en espagnol et s'affichent instantanément sur le tableau du cycle de vie via la couture de sélection existante.

La liste de préparation au recours parle espagnol (+1 copie)

• Les sept vérifications de préparation — type de différend identifié, plainte initiale envoyée, étapes requises complétées, délais écoulés, preuve préservée, chronologie constituée, tentatives de règlement consignées — sont rédigées en espagnol et s'affichent immédiatement via la couture de sélection existante sur le tableau de résolution.

Les textes de détail portent l'espagnol à travers chaque site de sélection (+1 copie)

• Les trois sites de rendu des détails d'étapes — le tableau des parcours de résolution, les cartes publiques de parcours et les constats d'axes du portefeuille — transmettent désormais le champ de détail espagnol à travers la couture de sélection, de sorte que les détails d'étapes fraîchement rédigés s'affichent pour les lecteurs hispanophones, et le registre des constats d'axes reçoit sa couture de rédaction espagnole.

L'espagnol atteint les étapes des parcours de résolution (+1 copie)

• Les trois étapes partagées sur lesquelles chaque parcours se construit — la plainte directe (y compris son gabarit par organisation), la mise en demeure avec sa citation du Code civil, et la vérification de préparation au recours — sont rédigées en espagnol, étiquettes et détails complets, passant par la couture de données vers les douze parcours à la fois.

Les paliers de prix espagnols achèvent le catalogue du marché (+1 copie)

• Les treize étiquettes de paliers de prix des neuf services du marché sont rédigées en espagnol — déclarations standard, le jour même et urgentes, signification personnelle et aux sociétés, devis, références, cahiers et pièces couleur — complétant la couverture espagnole native des noms, descriptions et paliers du catalogue.

Les descriptions espagnoles complètent le catalogue du marché (+1 copie)

• Les neuf descriptions de services du marché des opérations sont rédigées en espagnol — mandat d'huissier, traduction certifiée, rapports d'expert, jumelage avec un avocat, impression de cahiers, transcription, notarisation, assermentation et notification — afin que les citoyens hispanophones lisent le catalogue complet nativement via la couture de données.

L'espagnol atteint le catalogue du marché (+1 copie)

• Les neuf noms de services du marché des opérations — assermentation, signification, traduction certifiée, rapports d'expert, consultation d'avocat, impression et reliure, transcription judiciaire, notarisation et notification procédurale — sont rédigés en espagnol et passent par la couture pickText sans aucun changement de composant. Les interfaces du catalogue reçoivent les champs espagnols optionnels pour que les descriptions et étiquettes de paliers suivent.

i18n tranche 66 (+1 copie) : les dernières chaînes extractibles ont disparu (#1097)

• Les quatre derniers retardataires tombent : l'avis d'urgence du pied de page devient une clé du dictionnaire (son espagnol manuscrit préservé), et les trois sélections d'étiquettes Intl passent par un nouvel assistant localeTag qui donne enfin à l'espagnol un vrai formatage espagnol des nombres, dates et synthèse vocale au lieu de l'anglais. Le codemod d'extraction ignore désormais les étiquettes Intl à dessein. Chaque chaîne codée en dur extractible du code a été migrée : référence 262, tout le résidu étant des sélections de données, des dérivations et l'acheminement des assistants que la couture prend en charge.

La fenêtre de confirmation d'armement complète l'ADR-0004 (+10, interface C3)

• L'onglet des échéances de l'espace de travail reçoit la fenêtre de confirmation : choisissez une trousse de règles publiée (les brouillons sont invisibles par la sécurité au niveau des lignes, pas par confiance), indiquez la date déclencheuse, voyez l'échéance calculée avec la citation applicable et l'avertissement consultatif, et seule votre confirmation explicite l'arme — la base de données refuse tout le reste. Bilingue de bout en bout.

Le recalcul câblé de bout en bout : une publication remplaçante déplace désormais les échéances épinglées (+5, ADR-0004)

• La tâche de recalcul reçoit ses adaptateurs de production : le magasin Supabase, un notificateur de boîte de sortie qui met en file un courriel idempotent par échéance touchée (ancienne date, nouvelle date ou invitation à reconfirmer, et la citation applicable — rien de plus), et la route de publication exécute désormais la tâche automatiquement quand une trousse publiée en remplace une autre, renvoyant le résumé du recalcul dans sa réponse. L'indicateur de fonctionnalité gouverne toujours : désactivé, les échéances gèlent à leurs versions épinglées.

Les brouillons de trousses de départ complètent la décomposition de l'ADR-0004 (+5, C5)

• Deux trousses de départ québécoises arrivent en brouillon — le trio procédural du C.p.c. et deux ancres de prescription du Code civil — reformulant du contenu juridique déjà livré ailleurs sur la plateforme dans le schéma de règles JSONB, validées par le même portail que la route de publication applique, chaque règle étant consultative et liée à l'avertissement unique. La publication attend la revue du fondateur et la réponse du mémo A1 sur l'avertissement, exactement comme l'exige l'ADR.

Routes de publication et d'armement : les humains publient, les utilisateurs confirment (+10, ADR-0004 C3 côté serveur)

• Les deux routes API qui complètent la boucle des trousses de règles : la publication exige la capacité platform-ops (les agents peuvent soumettre des brouillons, qui restent invisibles; chaque publication émet son événement d'audit et la citation est obligatoire), et l'armement passe par la session du demandeur lui-même de sorte que la base de données applique l'accès au dossier et l'auto-confirmation — aucun chemin de rôle de service ne peut armer une échéance. La réponse renvoie la date calculée, la citation et la clé d'avertissement pour que l'interface affiche exactement ce qui a été armé.

Tâche de recalcul des échéances : en ajout seul, idempotente, jamais silencieuse (+10, ADR-0004 C4)

• Quand une trousse de règles est remplacée, les échéances armées épinglées à l'ancienne version se recalculent sous les nouvelles règles : les successeurs héritent de la confirmation humaine d'origine (le recalcul est le seul acte automatique — l'armement ne l'est jamais), la ligne antérieure est marquée remplacée dans une chaîne en ajout seul, rejouer la tâche ne produit aucun doublon, les règles supprimées déclenchent une reconfirmation demandée à l'utilisateur au lieu d'un abandon silencieux, et la tâche entière est derrière un indicateur de fonctionnalité dont la désactivation gèle les échéances à leurs versions épinglées. Les avis portent les anciennes et nouvelles dates et la citation applicable — rien de plus, selon la frontière UPL.

L'ADR-0004 pose ses fondations : trousses de règles versionnées et échéances confirmées par l'humain (+10, C1+C2)

• Les trousses de règles d'échéances deviennent des lignes de base de données versionnées — brouillons invisibles, lignes publiées en données de référence publiques, corrections toujours en nouvelle version — et les échéances armées exigent structurellement une confirmation humaine : confirmed_at et confirmed_by n'ont aucune valeur par défaut, les insertions exigent l'utilisateur confirmant lui-même, et le mur du dossier s'applique sans modification. Le moteur de calcul pur arrive en parallèle avec l'arithmétique des jours civils et ouvrables en dates UTC, éprouvée contre les années bissextiles, les semaines de changement d'heure et le report des fins de semaine.

Premier espagnol rédigé dans la couture de données : les noms de parcours de résolution (+1, #1097)

• Le registre des parcours reçoit les champs espagnols optionnels pour lesquels la couture pickText a été construite, et les douze noms de parcours destinés aux citoyens (banque, logement, emploi, consommation, assurance, gouvernement, discipline professionnelle, construction, contrats, famille, détention fédérale, autre) sont rédigés en espagnol — le premier contenu es porté par les données à traverser la couture sans aucun changement de composant.

Trousses d'échéances révisables : le format atterrit, structurellement inerte jusqu'à la signature du conseiller (+5, #460)

• Les règles d'échéances par juridiction gagnent un format de trousse avec provenance de révision : une trousse ne fournit aucune règle tant que l'identité du conseiller ET l'horodatage ne sont pas consignés, sous l'application d'un test-portail sur le registre — le contenu devient des données que le conseiller révise, jamais du code. La trousse pilote du Québec reformule le registre C.p.c. déjà livré sous la nouvelle forme et arrive inerte, en attente de l'attestation de la table de déblocage.

Le quota de litiges de l'offre gratuite appliqué à la base de données (+10, tranche Phase 1 de l'épopée #100)

• La limite de 25 litiges actifs du niveau Accès citoyen est désormais réelle : un déclencheur de base de données compte les litiges non terminaux à l'insertion (les litiges réglés, abandonnés et convertis libèrent leur place) et refuse le 26e avec une invitation à la mise à niveau — le premier point de conversion de l'épopée. Le constructeur de dossier traduit le refus en message bilingue convivial, et la limite vit dans une seule fonction afin que les droits payants remplacent une seule constante à l'arrivée de la facturation.

Le flux de destruction cryptographique complète la décomposition de l'ADR-0002 (+5, enfant 3)

• Le flux de destruction atterrit : détruire le texte chiffré de la KEK d'un dossier rend chaque clé de document sous-jacente définitivement irrécupérable, le refus sous conservation légale active étant exposé comme un résultat typé — y compris une conservation survenue entre la vérification et l'écriture, où le déclencheur de base de données 0112 demeure le mur. Les trois enfants de l'ADR-0002 sont désormais sur main; l'exécution réelle commence dès que l'ARN de la clé racine entre dans l'environnement.

Les KEK de dossier atterrissent avec destruction bloquée par conservation légale (+5, ADR-0002 enfant 2)

• La migration 0112 ajoute l'étage des KEK de dossier de la hiérarchie d'enveloppe : la clé de chiffrement de clés de chaque dossier n'est stockée qu'en texte chiffré (enveloppée par la racine ca-central-1), la table est réservée au rôle de service, et la destruction cryptographique — suppression de ligne, effacement du texte chiffré ou horodatage — est refusée par un déclencheur de base de données tant qu'une conservation légale non levée existe sur le dossier. Un dossier portant une KEK ne peut être supprimé sous elle.

La création de partage écrit doublement la liste blanche (+5, ADR-0001 enfant 4)

• Les deux chemins de création de partage — le client de l'espace de travail et l'API de partage aux avocats — écrivent désormais des lignes de liste blanche à intégrité référentielle aux côtés des tableaux hérités, en échouant bruyamment si l'écriture de la liste échoue afin qu'un partage à moitié créé ne puisse jamais exister. Un garde de dérive verrouille la double écriture aux deux sites jusqu'à l'abandon des tableaux après parité.

Le fournisseur de clés AWS KMS atterrit derrière le port d'enveloppe (+5, ADR-0002 enfant 1)

• Le KeyProvider de production arrive : un adaptateur AWS KMS ca-central-1 pour le port de chiffrement par enveloppe existant, avec le portail de consentement appliqué avant tout appel réseau (pas de subvention, pas de requête KMS), l'attribution CloudTrail par opération via l'ARN complet de la clé comme kekId, un contexte de chiffrement lié et une sélection pilotée par l'environnement — le LocalKeyProvider demeure pour le développement. S'active dès que AWS_KMS_KEY_ARN entre dans l'environnement; la destruction cryptographique devient un acte que nous accomplissons, pas notre fournisseur de base de données.

La liste blanche des partages de dossier atterrit (+5 durcissement, ADR-0001 enfants 1 et 3)

• La migration 0111 élève le stockage des partages restreints vers des tables de liste blanche à intégrité référentielle avec révocation par document, des politiques de gestion réservées au propriétaire et un remplissage qui élimine les identifiants orphelins — déployée de façon additive selon l'ordre sans fuite, le mur de tableaux 0057 restant actif jusqu'à la parité en préproduction. La matrice d'accès à sept cas et les invariants structurels de la migration rejoignent la suite de tests de sécurité; les deux tables sont inscrites au registre d'audit RLS.

Deux ADR acceptées : le durcissement de la liste de partage et la hiérarchie de clés KMS

• Le bloc immédiat de la séance de conception atterrit en registres de décision d'architecture formels : l'ADR-0001 élève le mur vérifié des partages restreints vers une table de liste blanche à intégrité référentielle avec un ordre de migration sans fuite et une matrice de sept tests SQL, et l'ADR-0002 fixe la garde des clés racines chez AWS KMS ca-central-1 avec des KEK au niveau du dossier, une destruction bloquée par la conservation légale, et l'exposition à la loi CLOUD énoncée clairement avec une sortie souveraine chiffrée. Les deux annexent des décompositions prêtes pour la boucle.

Séance de conception : sept architectures proposées, le mur des partages restreints revérifié

• Une séance de conception convoquée par le fondateur atterrit dans docs/decisions/design-session-2026-07-02.md : le remplissage du cycle de vie (#98), l'entonnoir de conversion litige-dossier (#100), les trousses d'échéances révisables (#460), le registre en partie double et la machine à états des jalons (#465, conception seulement), l'architecture mobile Capacitor (#471/#473/#476), les ports de limitation de débit et de gestion de clés (#488) et le chemin de téléversement en quarantaine à fermeture sûre (#474). Annexe sécurité : le mur des partages restreints est revérifié intact à travers toutes les migrations ultérieures avec la suite de 348 tests au vert, et le durcissement du caviardage est approuvé.

i18n tranche 64 (+2 maintenance) : les dérivations de locale et les assistants de sélection passent par le module trilingue (#1097)

• Les chaînes de dérivation de locale artisanales se replient dans resolveTrilingual, et les assistants de sélection de sept surfaces de l'espace de travail (archives, recours, exécution, recouvrement, renseignement d'actifs, jugement, plaidoirie) délèguent désormais à pickText — mettant à niveau chacun de leurs sites d'appel pour privilégier l'espagnol dès que les données sont rédigées. Référence : 277 → 266, irréversiblement. (Rebasée après la version du devis de construction du marché.)

Devis du marché des syndics autorisés en insolvabilité (SAI) et réparations des gardes-fous CI

• Nouveau devis de construction v1 du marché des syndics autorisés en insolvabilité (docs/lit-marketplace-spec-v1.md) : modèle de données fournisseur générique, import du registre du BSF, annuaire public FR/EN, flux de réclamation de profil, admission des consommateurs et intégration CaseEvent — en attente d'approbation humaine (P1).
• Le garde-fou de lancement « US auto-deadlines are disabled » suit désormais la refonte i18n : il vérifie la clé de dictionnaire de l'avertissement dans le composant et l'engagement textuel dans dictionaries/en.ts, au lieu d'une phrase codée en dur disparue du composant.
• Les clés de liste React sont passées directement (key=) au lieu d'être propagées via un objet — l'avertissement console de React 19 faisait échouer le test d'intégrité de la plateforme sur /fr.
• Le serveur de développement des tests Playwright reçoit un tas de 4 Go : son garde-mémoire le redémarrait en pleine suite, produisant des erreurs 503 transitoires sur /fr/app et /en/app.

i18n tranche 63 (+1 copie) : les derniers littéraux de pages rejoignent une section partagée (#1097)

• Les dernières pages à chaîne unique — conformité notariale, avis des partenariats, et les titres notifications, recommandations et enquêteur — partagent une seule section pageMisc du dictionnaire, et le formateur monétaire des juridictions dérive son étiquette de locale au lieu de la coder en dur. Chaque page du routeur est désormais exempte de ternaires extractibles. Référence : 282 → 277, irréversiblement.

i18n tranche 62 (+1 copie) : les opérations de litige, la revue d'extraction, l'enquête et la coquille perdent leurs résidus (#1097)

• Les noms et paliers de services des opérations de litige passent par pickText, l'acceptation/rejet en masse et les messages de faits d'enquête deviennent des clés paramétrées, et les cartes d'étiquettes d'onglets de la coquille sélectionnent par locale réelle. Référence : 296 → 282, irréversiblement.

i18n tranche 61 (+1 copie) : les résidus de résolution, communications et admission deviennent clés et sélections (#1097)

• Les avis de parcours et pourcentages d'évaluation de la résolution deviennent des clés paramétrées, les métadonnées de type et de classification des communications passent par pickText, et les étiquettes de taxonomie de l'admission reçoivent la locale réelle — Communications est désormais entièrement nettoyé. Référence : 317 → 296, irréversiblement.

i18n tranche 60 (+1 copie) : les dernières chaînes codées du coffre de preuves deviennent des clés paramétrées (#1097)

• Les chaînes résiduelles du coffre de preuves se convertissent : les avis d'importation deviennent des clés paramétrées ({n}, {path}, {name}), les options de chaîne de possession et les résumés d'organisation passent par pickText, et le lecteur de fichiers ainsi que les étiquettes de taxonomie reçoivent désormais la locale réelle — l'espagnol les atteindra sans autre changement de code. Référence : 327 → 317, irréversiblement.

i18n tranche 59 (+2 maintenance) : les données du marché passent par la couture espagnole (#1097)

• La page de domaine du marché (23 sites), la médiation (11), l'index du marché (11) et le journal des communications (3) acheminent leurs textes bilingues portés par les données via pickText/pickList, de sorte que chaque profil de prestataire, liste d'accréditations, témoignage et étiquette de jour privilégie un champ espagnol dès qu'il est rédigé. Référence : 375 → 327, irréversiblement.

i18n tranche 58 (+1 copie) : huit petites surfaces parlent toutes les langues (#1097)

• Les pages réinitialisation et actions collectives, la bannière de sécurité des données, la liste des commandes de service, le bouton d'admission, les résultats de recherche d'experts, le tableau de bord des experts et le portail de session migrent leurs derniers littéraux (2-3 chacun) vers des clés du dictionnaire, plusieurs fusionnant dans des sections existantes. Référence : 392 → 375, irréversiblement.

i18n tranche 57 (+1 copie) : quatre pages admin, nouveau-litige, connexion et partenaires parlent toutes les langues (#1097)

• Sept pages migrent vers des clés du dictionnaire (3 chacune) : les pages admin commissaires, experts, partenariats et professionnels, l'admission de nouveau litige, la page de connexion (y compris son assistant d'erreur de lien magique) et la page partenaires. Référence : 413 → 392, irréversiblement.

i18n tranche 56 (+1 copie) : l'explorateur du journal, les guides, l'accès anticipé, le filtre de domaines et la bannière de développement parlent toutes les langues (#1097)

• Cinq autres surfaces migrent vers des clés du dictionnaire : l'explorateur du journal des modifications (2), les pages d'articles de guide (3), le formulaire d'accès anticipé (4), le filtre de domaines juridiques du marché (4, y compris son espagnol manuscrit) et la bannière de phase de développement (4). Référence : 430 → 413, irréversiblement.

i18n tranche 55 (+1 copie) : les huit pages de réglages parlent toutes les langues (#1097)

• Le chrome de chaque page de réglages — activité, facturation, courriel, préférences, profil, sécurité, accès au soutien et espace de travail (4 clés chacune) — migre vers des sections du dictionnaire, complétant la surface des réglages : les panneaux avaient migré dans des tranches antérieures, leurs pages hôtes suivent désormais. Référence : 462 → 430, irréversiblement.

i18n tranche 54 (+1 copie) : les widgets du tableau de bord expert et l'indicateur de soutien parlent toutes les langues; formulaire d'attente mort supprimé (#1097)

• Les demandes entrantes (5 clés), l'analytique d'expert (4), l'indicateur d'accès au soutien (4), les badges de vérification (5, transmis à la grille de cartes et au profil) et la carte d'expert (1) migrent vers des clés du dictionnaire; le WaitlistForm sans référence est supprimé. Référence : 486 → 462, irréversiblement.

i18n tranche 53 (+1 copie) : les pages contenu admin, commissaire, acceptation d'invitation et aide juridique parlent toutes les langues (#1097)

• Quatre autres pages migrent vers des clés du dictionnaire : contenu admin (5), la page de l'espace commissaire (4), l'acceptation d'invitation d'espace de travail (5) et l'aide juridique du marché (5). Référence : 506 → 486, irréversiblement.

i18n tranche 52 (+1 copie) : le guide d'étapes, les campagnes et l'index des experts parlent toutes les langues (#1097)

• Le guide d'étapes de l'espace de travail (5 clés), la page des campagnes admin (5) et la page d'index des experts (5) migrent vers des clés du dictionnaire. Référence : 521 → 506, irréversiblement.

i18n tranche 51 (+1 copie) : les articles de recherche, la page presse et le centre de commande admin parlent toutes les langues (#1097)

• La page d'article de recherche (8 clés), les chaînes restantes de la page presse (6) et le centre de commande administrateur (6, fusionnées dans sa section command existante) migrent vers des clés du dictionnaire. Référence : 541 → 521, irréversiblement.

i18n tranche 50 (+1 copie) : avisez-moi, acceptation d'invitation, éditeurs d'expert et guides parlent toutes les langues (#1097)

• Cinq autres surfaces migrent vers des clés du dictionnaire : le formulaire avisez-moi (6), le panneau d'acceptation d'invitation (5), l'éditeur de profil d'expert (6) et la configuration des qualifications (6, tous deux transmis via le tableau de bord des experts), et la page des guides (6). Référence : 570 → 541, irréversiblement.

i18n tranche 49 (+1 copie) : acceptation de partage, file éditoriale, bibliothèque de recherche, guide de plateforme et prochaines étapes parlent toutes les langues (#1097)

• Cinq autres surfaces migrent vers des clés du dictionnaire : l'acceptation de partage (8), la file éditoriale (6), la bibliothèque de recherche (6), le guide de plateforme du soutien (8) et le panneau des prochaines étapes de l'espace de travail (8). Référence : 606 → 570, irréversiblement.

i18n tranche 48 (+1 copie) : incident, approbations, recherche admin et cartes de parcours parlent toutes les langues (#1097)

• La page incident (8 clés), la page d'approbations admin (8), la console de recherche admin (9) et les cartes de parcours de résolution (4) migrent vers des clés du dictionnaire. Référence : 637 → 606, irréversiblement.

i18n tranche 47 (+1 copie) : l'admission d'experts et trois files administratives parlent toutes les langues (#1097)

• Le flux d'admission des experts (8 clés, transmis via la chaîne profil-bouton), la file de vérification des professionnels (10), le panneau d'administration des commissaires (9) et la file de revue des partenariats (9, imbriquée dans son contenu partnerships existant) migrent vers des clés du dictionnaire. Référence : 673 → 637, irréversiblement.

Réconciliation des points de version : cinq versions sous-comptées restaurées (+19)

• Une revue externe (Devin) a justement signalé que les versions récentes étaient uniformément augmentées de +1 sans égard à leur classe, contrairement au barème de points du VERSIONING_MASTER_PLAN. Réconciliation selon le précédent 7.65.22 : le portail d'approbation durable (7.66.86) et le durcissement du caviardage des journaux (7.66.89) valaient +5 chacun (correctif de production / garde-fou), le lecteur pdfjs (7.66.92) +10 (amélioration d'outil existant), et la configuration CodeRabbit (7.66.87) et le remaniement pickText (7.66.95) +2 chacun (maintenance à faible risque) — un déficit de +19, reporté au-delà de la frontière de version jusqu'à 7.67.14. Les prochaines augmentations seront calibrées d'après le barème au moment de chaque PR.

i18n tranche 46 : les textes portés par les données gagnent une couture espagnole (#1097)

• Un assistant pickText rejoint le module trilingue : les objets de données (registres de parcours, propositions du cycle de vie, taxonomies d'admission) résolvent désormais leurs textes fr/en par une seule couture qui privilégie un champ espagnol dès qu'il est rédigé, au lieu de ternaires figées français-ou-anglais. Trente-neuf sites convertis dans Resolution, Evidence, Lifecycle, DocumentIntake et Investigation; les formes à tableaux et champs optionnels restent volontairement explicites. Référence : 717 → 673, irréversiblement.

i18n tranche 45 : réinitialisation du mot de passe, accès au soutien et paiement de devis parlent toutes les langues (#1097)

• Le formulaire de réinitialisation du mot de passe (10 clés, entièrement nettoyé), le panneau de réglages d'accès au soutien (9) et le bouton de paiement de devis (8) migrent vers des sections du dictionnaire transmises depuis leurs pages. Référence : 745 → 717, irréversiblement.

i18n tranche 44 : les pages devenir-expert, recherche et paiement de service parlent toutes les langues (#1097)

• Trois autres pages publiques migrent vers des sections du dictionnaire : devenir-expert (9 clés), l'index de recherche (9) et la page de paiement de service (7). Référence : 771 → 745, irréversiblement.

Les PDF de preuve s'affichent en canevas défilables sur tous les appareils (#477)

• L'aperçu des PDF de preuve passe d'un iframe — que Safari iOS aplatit en une seule page non défilable — à un rendu canevas pdfjs-dist avec pagination paresseuse : des espaces réservés dimensionnés selon la géométrie réelle du document ne se rastérisent qu'à l'approche de la fenêtre. La bibliothèque se charge à la demande (jamais dans le paquet principal) et tout échec d'analyse retombe sur l'ancien iframe, de sorte qu'aucun document ne devient invisible. Des gardes de source verrouillent les trois propriétés.

i18n tranche 43 : le parcours de conflit, les demandes de devis et la facturation parlent toutes les langues (#1097)

• La bande du parcours de résolution de conflit (6 clés), le bouton de demande de devis (10, entièrement nettoyé) et le panneau de réglages de facturation (9) migrent vers des sections du dictionnaire transmises depuis leurs pages et l'entonnoir de services. Référence : 797 → 771, irréversiblement.

i18n tranche 42 : la candidature d'expert parle toutes les langues; l'espace avocat mort supprimé (#1097)

• Le formulaire de candidature devenir-expert (14 clés) se scinde en une page serveur et un formulaire client alimenté par le dictionnaire, et le composant AttorneyWorkspace sans référence (12 ternaires périmées) est supprimé purement et simplement. Référence : 823 → 797, irréversiblement.

Les journaux de développement assainis effacent désormais NAS, téléphones et adresses IP (#155)

• Le garde-fou de caviardage des journaux G37 est durci au-delà des courriels et des jetons secrets : les NAS canadiens en forme séparée, les numéros de téléphone NANP et E.164 et les adresses IPv4 à octets stricts sont effacés, tandis que les numéros de dossier judiciaire, les chaînes de version et les suites de chiffres nues passent volontairement intactes — la précision plutôt que les faux positifs, avec une suite de cas prouvant les deux directions.

Fiches de triage des 37 sous-tâches retenues (#541)

• Les 37 sous-tâches d'épopées volontairement retenues par la course autonome sont triées en cinq dispositions (docs/decisions/541-triage-briefs-2026-07-02.md) : cinq promouvables aujourd'hui, six nécessitant chacune une attestation du conseiller juridique, dix-sept en attente de la seule décision de pile mobile, quatre derrière d'autres décisions de fournisseurs, et cinq correctement maintenues. Le scénario de séance du fondateur tient en trois étapes.

Revues automatiques CodeRabbit désactivées — le signal CI nous appartient de nouveau (#1256)

• Les crédits prépayés épuisés de l'application CodeRabbit faisaient échouer son contrôle de statut sur chaque demande de tirage d'origine humaine — un état de facturation, pas un constat de code. Conformément à la séance de décisions du fondateur, les revues automatiques sont désactivées via .coderabbit.yaml; la propre suite de portails du dépôt demeure le signal de fusion faisant autorité.

Le portail d'approbation humaine survit au sans-serveur (#1200)

• Les approbations du plan de contrôle sont désormais durables : les portails en attente sont reflétés dans une table Postgres réservée au rôle de service (migration 0110), de sorte qu'une approbation Slack atterrissant sur une autre instance sans serveur règle la ligne et que l'instance en attente la récupère par interrogation. Les approbations sur la même instance se résolvent toujours instantanément, les portails expirés marquent leur ligne comme expirée, et le portail se replie proprement sur le comportement en mémoire quand le backend n'est pas configuré.

Trousse de décisions fondateur — 12 dossiers bloqués, une seule séance

• Une trousse de décision d'une page (docs/decisions/founder-decision-sprint-2026-07-02.md) associe chaque dossier bloqué par le fondateur ou le conseiller juridique à la décision exacte requise, aux options, à une recommandation et au coût du délai — classés par levier de revenus (versements, contraintes de déploiement, palier de stockage, portails de lancement, hygiène opérationnelle). La vider débloque deux correctifs de sécurité le jour même, les épopées de chiffrement et le rail de versements.

i18n tranche 41 : le centre d'incidents, les filtres d'experts, l'import Google et les approbations parlent toutes les langues (#1097)

• Le centre d'incidents (9 clés), les filtres de recherche d'experts (13), le panneau d'import de prestataires Google (11) et la file d'approbations administrateur (9) migrent vers des sections de premier niveau du dictionnaire transmises depuis leurs pages. Référence : 865 → 823, irréversiblement.

i18n tranche 40 : les réglages profil, préférences et changement de courriel parlent toutes les langues (#1097)

• Trois autres panneaux de réglages — profil (14 clés), préférences d'interface (13) et changement de courriel (13) — migrent vers des sections de premier niveau du dictionnaire transmises depuis leurs pages, chaque fichier entièrement débarrassé de ses ternaires codées en dur. Référence : 906 → 865, irréversiblement.

i18n tranche 39 : l'entonnoir de services et le bouton de paiement parlent toutes les langues (#1097)

• L'entonnoir de services partagé (9 clés — il résout désormais le dictionnaire côté serveur) et le bouton de paiement (13, entièrement nettoyé) migrent vers des sections du dictionnaire. Référence : 930 → 906, irréversiblement.

i18n tranche 38 : les recommandations, le marché administrateur et l'en-tête parlent toutes les langues (#1097)

• Le panneau de recommandations (16 clés), la console d'administration du marché (16, fusionnées dans sa section marketOps existante) et l'en-tête du site (10) migrent vers des clés du dictionnaire. Référence : 977 → 930, irréversiblement.

i18n tranche 37 : les profils d'experts, la sélection de prestataires et le fil d'activité parlent toutes les langues (#1097)

• Le profil public d'expert (12 clés), l'étape de sélection de prestataire du marché (14 — le composant serveur résout désormais sa propre tranche de dictionnaire) et le fil d'activité du compte (17, entièrement nettoyé) migrent vers des sections du dictionnaire. Référence : 1 020 → 977, irréversiblement.

i18n tranche 36 : les derniers littéraux des pages du marché passent au dictionnaire (#1097)

• La page de domaine du marché reçoit une section du dictionnaire (8 clés) et les chaînes plus récentes de l'index du marché rejoignent sa section existante (7 clés, avec leur espagnol manuscrit préservé dans le partiel es). Ce qui reste dans ces deux pages est du contenu bilingue piloté par les données, dont le correctif est des champs espagnols sur les données elles-mêmes. Référence : 1 035 → 1 020, irréversiblement.

i18n tranche 35 : le moteur de contenu, les soumissions de recherche et les membres de l'espace parlent toutes les langues (#1097)

• Le moteur de contenu administrateur (18 clés), le formulaire de soumission de recherche (16) et le panneau des membres de l'espace de travail (17) migrent vers des sections de premier niveau du dictionnaire transmises depuis leurs pages. Référence : 1 086 → 1 035, irréversiblement.

i18n tranche 34 : l'intégration des avocats, gardez-la-date et le planificateur de règlement parlent toutes les langues (#1097)

• L'intégration des avocats (21 clés), le panneau d'échéances gardez-la-date (17) et le planificateur de règlement (18) migrent vers des sections du dictionnaire; le formatage monétaire reste dérivé de la locale plutôt que du dictionnaire. Référence : 1 143 → 1 086, irréversiblement.

i18n tranche 33 : le constructeur de dossier et les formulaires presse et partenaires parlent toutes les langues (#1097)

• Le constructeur de dossier Judge911 (30 clés) et les formulaires de contact presse et partenaires (20 chacun) migrent vers des sections de premier niveau du dictionnaire transmises depuis leurs pages. Référence : 1 214 → 1 143, irréversiblement.

i18n tranche 32 : les panneaux de réglages parlent toutes les langues (#1097)

• Trois panneaux de réglages migrent vers des sections de premier niveau du dictionnaire transmises depuis leurs pages : préférences de notification (28 clés), sécurité et double authentification (24), et la zone de danger de l'espace de travail (18, relayée par le panneau des membres). Un fichier entièrement débarrassé de ses ternaires codées en dur. Référence : 1 288 → 1 214, irréversiblement.

i18n tranche 31 : recouvrement, recours, journal des événements et préparation au dépôt parlent toutes les langues (#1097)

• Quatre autres onglets de l'espace de travail migrent vers des sections imbriquées du dictionnaire app : recouvrement (19 clés — registre, distribution), recours (21 — évaluation, poursuites), le journal des événements (18) et la préparation au dépôt (21 — lignes de vérification). Référence : 1 371 → 1 288, irréversiblement.

i18n tranche 30 : centre de commande, plaidoirie simulée, exécution et engagements parlent toutes les langues (#1097)

• Quatre onglets de l'espace de travail migrent vers des sections imbriquées du dictionnaire app : le centre de commande (32 clés — statuts d'échéance, préparation), la plaidoirie simulée (34 — étapes, tableau de bord), l'exécution (30 — mesures, recouvrabilité) et les engagements (26). Référence : 1 495 → 1 371, irréversiblement.

i18n tranche 29 : l'onglet d'enquête parle toutes les langues (#1097)

• L'onglet d'enquête (75 clés — pistes, hypothèses, liens de preuve, formulaires de champ, métriques) migre vers une section imbriquée du dictionnaire app, recevant la prop dictionnaire qui lui manquait, transmise depuis l'espace de travail. Référence : 1 575 → 1 495, irréversiblement.

i18n tranche 28 : le tableau de bord d'accueil justice parle toutes les langues (#1097)

• Le tableau de bord d'accueil justice (89 clés — liste des dossiers, cartes d'action, flux poser-une-question, liens rapides, métriques), la surface d'atterrissage du citoyen dans l'app, migre vers une section imbriquée du dictionnaire app; une chaîne espagnole manuscrite est préservée via le partiel es. Référence : 1 671 → 1 575, irréversiblement.

i18n tranche 27 : le module de résolution parle toutes les langues (#1097)

• Le module résolution d'abord (65 clés — évaluation de règlement, registre de négociation, et le portail de litige qui invite les parties à tenter la résolution en premier) migre vers une section imbriquée du dictionnaire app. Référence : 1 737 → 1 671, irréversiblement.

i18n tranche 26 : la coquille de l'espace de travail parle toutes les langues (#1097)

• La coquille de l'espace de travail des dossiers (90 clés — chrome des onglets, portail de compte, état du système, réglages, pièces, panneaux d'aperçu) migre vers une section imbriquée du dictionnaire app, y compris une chaîne espagnole manuscrite préservée via le partiel es. Référence : 1 832 → 1 737, irréversiblement.

i18n tranche 25 : la salle de guerre parle toutes les langues (#1097)

• La salle de guerre (93 clés — tableau de stratégie, citations de jurisprudence avec badges de vérification, assemblage du cahier, métriques) migre vers une section imbriquée du dictionnaire app. Référence : 1 937 → 1 832, irréversiblement.

i18n tranche 24 : le coffre de preuves parle toutes les langues (#1097)

• Le coffre de preuves (91 clés — flux de téléversement, tableau des documents, tiroir, menus, avis d'échec infonuagique) migre vers une section imbriquée du dictionnaire app. Référence : 2 039 → 1 937, irréversiblement.

i18n tranche 23 : l'admission de documents — la plus grande surface — parle toutes les langues (#1097)

• L'admission de documents, la plus grande surface de chaînes codées en dur de la plateforme (138 chaînes — téléversement, revue OCR, classification, badges de confiance et revue d'extraction champ par champ), migre vers une section imbriquée du dictionnaire app, transmise aux assistants ClassifyStep, ConfidenceBadge et FieldWithConfidence. Les infobulles de confiance deviennent des clés paramétrées. Référence : 2 191 → 2 039, irréversiblement.

i18n tranche 22 : l'inscription des prestataires et l'espace du commissaire parlent toutes les langues (#1097)

• Le formulaire d'inscription des prestataires du marché (39 chaînes) et l'espace du commissaire à l'assermentation (39 — candidature, file de commandes, cartes de commande) migrent vers des sections de premier niveau du dictionnaire transmises depuis leurs pages. Référence : 2 271 → 2 191, irréversiblement.

i18n tranche 21 : le renseignement d'actifs et le Centre de soutien parlent toutes les langues (#1097)

• L'onglet de renseignement d'actifs (44 chaînes — cartes recouvrement, réseau du débiteur, registres, solvabilité, traçage et stratégie) et le Centre de soutien (43 — rédacteur de billets, base de connaissances, étiquettes de statut) migrent vers des sections du dictionnaire. Le Centre de soutien reçoit sa propre section de premier niveau transmise depuis la page de soutien, et une variable locale nommée t a été renommée pour cesser de masquer le dictionnaire. Référence : 2 362 → 2 271, irréversiblement.

i18n tranche 20 : les opérations de litige et les procédures parlent toutes les langues (#1097)

• L'onglet des opérations de litige (55 chaînes — signification, validation d'affidavit, coordination des huissiers) et le gestionnaire de procédures (46 — audiences, dépôts, matrice d'utilisation preuve-procédure) migrent vers des sections imbriquées du dictionnaire app. Le codemod d'extraction retire désormais les caractères non-identifiants des clés générées (un signe de multiplication s'y était glissé). Référence : 2 468 → 2 362, irréversiblement.

i18n tranche 19 : le cycle de vie du dossier et le journal des communications parlent toutes les langues (#1097)

• Le suivi du cycle de vie du dossier (40 chaînes — étapes, états de verrouillage, badges) et le journal des communications (43 — rédacteur d'entrées, canaux, états de divulgation) migrent vers des sections imbriquées du dictionnaire app; Communications reçoit la prop dictionnaire qui lui manquait, transmise depuis l'espace de travail. Référence : 2 554 → 2 468, irréversiblement.

i18n tranche 18 : les outils de litige et la revue d'extraction parlent toutes les langues (#1097)

• Le panneau d'outils de litige (52 chaînes — Bates, ensembles de revue, dépôts, métriques) et la file de revue d'extraction IA (43 — cartes candidates, décisions, bandes de confiance) migrent vers des sections imbriquées du dictionnaire app, transmises aux assistants DocSection et CandidateCard. Les deux composants déclaraient une prop dictionnaire jamais liée; ils la consomment désormais. Référence : 2 652 → 2 554, irréversiblement.

i18n tranche 17 : le Copilote de litige et l'analyseur de jugement parlent toutes les langues (#1097)

• Le Copilote de litige IA (47 chaînes) et l'analyseur de jugement (47 — cartes dossier, conclusions, issue, recours, options) migrent vers des sections imbriquées du dictionnaire app. Le codemod d'extraction comprend désormais les ternaires trilingues et émet un bloc partiel espagnol, préservant mot pour mot les textes espagnols du Copilote au lieu de retomber sur l'anglais. Référence : 2 747 → 2 652, irréversiblement.

i18n tranche 16 : la coquille d'espace professionnel et l'import Drive parlent toutes les langues (#1097)

• La coquille d'espace de travail professionnel (17 chaînes — états de disponibilité, chrome des modules, tiroir d'audit) et le flux d'import Google Drive (8) migrent vers des sections imbriquées du dictionnaire app, transmises à travers leurs assistants et les deux sites d'appel Drive. Référence : 2 772 → 2 747, irréversiblement. AttorneyWorkspace s'est révélé du code mort (zéro référence) — signalé pour suppression plutôt que migration.

i18n tranche 15 : partage à l'avocat, numérotation Bates, clavardage copilote, tableau enquêteur et portefeuille parlent toutes les langues (#1097)

• Cinq composants d'espace de travail de plus — le partage à l'avocat (18 chaînes, désormais à ZÉRO ternaire en ligne), la numérotation Bates (19), le clavardage copilote (17), le tableau enquêteur (14) et la vue portefeuille (7) — migrent vers des sections imbriquées du dictionnaire app avec passage d'une seule propriété là où nécessaire. Référence : 2 849 → 2 772, irréversiblement.

i18n tranche 14 : les dépôts au greffe et les archives parlent toutes les langues (#1097)

• Deux composants d'espace de travail de plus — la file des dépôts au greffe (16 chaînes) et les archives (17) — migrent vers des sections imbriquées du dictionnaire app sans aucun changement de propriétés. Référence : 2 882 → 2 849, irréversiblement.

i18n tranche 13 : le calculateur d'échéances, la revue de classification et partagé-avec-moi parlent toutes les langues (#1097)

• Trois composants d'espace de travail de plus — le calculateur d'échéances, la file de revue de classification et la liste partagé-avec-moi (27 chaînes ; partagé-avec-moi atteint ZÉRO ternaire en ligne) — migrent vers des sections imbriquées du dictionnaire app ; deux ont nécessité le passage d'une seule propriété depuis leurs parents. Référence : 2 909 → 2 882, irréversiblement.

i18n tranche 12 : la migration de la suite espace de travail commence — six composants, zéro changement de propriétés (#1097)

• La migration de la suite client de l'espace de travail s'ouvre sur sa découverte habilitante : chaque onglet reçoit déjà le dictionnaire app, les sections s'y imbriquent donc et les composants s'y lient directement — aucun nouveau passage de propriétés. Six composants (collaboration, export, cabinet, audience, documents, recherche — 10 chaînes, les six désormais à ZÉRO ternaire en ligne) migrent ainsi. Référence : 2 919 → 2 909, irréversiblement.

i18n tranche 11 (lot de cinq) : les pages experts, lancement presse, intégration, apprendre et soumission de recherche parlent toutes les langues (#1097)

• Cinq pages publiques de plus en un seul lot — disciplines d'experts, la page de lancement presse, l'intégration de la place de marché, le carrefour d'apprentissage et la soumission de recherche (54 chaînes au total ; trois fichiers atteignent ZÉRO ternaire en ligne) — passent aux dictionnaires via le codemod d'extraction. Référence : 2 973 → 2 919, irréversiblement. Le codemod a aussi appris à ne jamais traiter les sélecteurs de code de langue (fr/en) comme des chaînes d'interface.

i18n tranche 10 (lot) : les pages lifecycle, mrkplc et design-system parlent toutes les langues — référence sous les 3 000 (#1097)

• Trois pages publiques en un seul lot — lifecycle (9 chaînes), mrkplc (16, désormais à ZÉRO ternaire en ligne), design-system (15) — passent aux dictionnaires via le codemod d'extraction. Référence : 3 013 → 2 973, passant sous les 3 000 pour la première fois, irréversiblement.

i18n tranche 9 : la page résolution (Conflict OS) parle toutes les langues (#1097)

• La page publique de résolution — 13 chaînes bilingues codées en dur de plus — passe aux dictionnaires via le codemod d'extraction. Référence : 3 026 → 3 013, irréversiblement.

i18n tranche 8 : la page de recrutement des huissiers parle toutes les langues (#1097)

• La page publique de recrutement des huissiers — 14 chaînes bilingues codées en dur de plus — passe aux dictionnaires via le codemod d'extraction. Référence : 3 040 → 3 026, irréversiblement.

i18n tranche 7 : le carrefour des paramètres parle toutes les langues (#1097)

• Le carrefour des paramètres — la totalité de ses 22 chaînes bilingues (cartes de section pour profil, espace de travail, sécurité, courriel, préférences, activité, facturation, notifications et accès au soutien) — passe aux dictionnaires via le codemod d'extraction, ne laissant AUCUN ternaire en ligne dans le fichier. Référence : 3 062 → 3 040, irréversiblement.

i18n tranche 6 : la page de médiation de la place de marché parle toutes les langues (#1097)

• La page publique de médiation — 14 chaînes bilingues codées en dur de plus (cartes de tarifs, états de réservation, insigne le-plus-populaire, métadonnées) — passe aux dictionnaires via le codemod d'extraction. Référence : 3 076 → 3 062, irréversiblement. Les 12 sélections de données bilingues de la page (noms/descriptions des paliers) restent avec les données, selon la règle constante de la migration.

i18n tranche 5 : la page des droits Judge911 aux États-Unis parle toutes les langues (#1097)

• La page publique des droits en justice criminelle américaine /judge911 — 25 chaînes bilingues codées en dur de plus (parcours des droits, échelle de déploiement, cadrage du registre des établissements, métadonnées) — passe aux dictionnaires via le codemod d'extraction. Référence : 3 101 → 3 076, irréversiblement.

i18n tranche 4 : la page des droits en justice criminelle canadienne parle toutes les langues (#1097)

• La page publique de navigation des droits /criminal-justice — 28 chaînes bilingues codées en dur de plus (cadrage des droits de la Charte, cartes de parcours, garde-fous, métadonnées) — passe aux dictionnaires via le codemod d'extraction. Référence : 3 129 → 3 101, irréversiblement.

i18n tranche 3 : le carrefour des services parle toutes les langues (#1097)

• Le carrefour /app/services — 34 chaînes bilingues codées en dur de plus, réparties entre les introductions par service (notarisation, serments, signification, dépôts) et la coquille du carrefour — passe aux dictionnaires via le codemod d'extraction. Référence : 3 163 → 3 129, irréversiblement.

i18n tranche 2 + le codemod : l'index de la place de marché parle toutes les langues ; les prochaines tranches tiennent en une commande (#1097)

• L'index public de la place de marché — 38 chaînes bilingues codées en dur de plus — passe aux dictionnaires (héros, cartes de types de prestataires, états de vérification, recrutement de prestataires). L'espagnol et les langues futures le rendent désormais par la couverture automatique. La référence du cliquet descend encore : 3 201 → 3 163, irréversiblement.
• La migration est désormais mécanisée : un codemod (scripts/i18n-extract-ternaries.mjs) extrait les ternaires littéraux d'un fichier, génère des clés stables, réécrit le fichier avec une liaison à l'épreuve des collisions et imprime des blocs de dictionnaire prêts à coller — en sautant délibérément les sélections de données bilingues et les expressions complexes pour revue humaine. Les tranches restantes tiennent chacune en une commande plus le câblage.

Migration i18n tranche 1 : la page publique de profil de prestataire parle toutes les langues (#1097)

• La page de profil de prestataire de la place de marché — la surface publique qu'un visiteur hispanophone est le plus susceptible d'atteindre — déplace ses 22 chaînes bilingues codées en dur vers les dictionnaires (panneau de portée, insignes de vérification, honoraires, identifiants, références, disponibilités, états de réservation). L'espagnol passe désormais par la couche de dictionnaires à couverture automatique au lieu de retomber silencieusement à l'anglais ; chaque langue future hérite de la section automatiquement.
• Première preuve de la boucle à cliquet : la migration a réduit la référence consignée de 3 223 à 3 201 ternaires en ligne — un nombre qui ne peut désormais plus remonter. Les sélections de DONNÉES bilingues (champs fr/en des objets de contenu comme les descriptions d'accréditation) sont volontairement intouchées : leur correctif est l'ajout de champs es aux données, suivi séparément sur le ticket.

Cliquet i18n des ternaires : les chaînes bilingues en ligne ne peuvent plus croître — la migration vers les dictionnaires ne va que de l'avant (#1097)

• La mesure d'abord : le motif en ligne `locale === "fr" ? … : …` — qui contourne les dictionnaires, de sorte que l'espagnol et toute langue future retombent silencieusement à l'anglais sur ces surfaces — était passé des ~272 chaînes signalées au dépôt du ticket à 3 223 dans 179 fichiers, le motif étant devenu le style de fait des composants client.
• Une porte à cliquet arrête désormais la croissance sans exiger de migration en bloc : aucun fichier ne peut jamais contenir PLUS de ternaires fr en ligne que sa référence consignée, les nouveaux fichiers ne peuvent en introduire aucun, et réduire un fichier fait descendre la référence (jamais monter). La porte s'exécute dans la suite de tests — la CI l'applique donc à chaque PR ; les nouvelles chaînes destinées aux utilisateurs doivent passer par les clés de dictionnaire, que la couverture automatique espagnole reprend alors d'office.
• La migration elle-même avance par tranches mécaniques par surface, suivies sur le ticket (les composants d'espace de travail sont les pires contrevenants avec 40 à 120 ternaires chacun) — chaque tranche réduit la référence et ne peut jamais régresser.

Constructeur de dossier Judge911 : catégorie → récit → structuration IA → votre décision (épopée #100)

• Le flux d'admission Judge911 arrive à /app/disputes/new : choisissez une catégorie (les cinq du schéma d'admission — l'interface et la contrainte de base de données sont testées pour correspondre exactement), racontez votre histoire dans vos mots, et l'appel de structuration mesuré et audité la transforme en dossier structuré — résumé, chronologie, parties, documents à rassembler, et une bande de risque avec une seule définition de découpage partagée entre les écrans.
• Les frontières de consentement sont explicites : le litige est créé sur votre propre session (sécurité au niveau des lignes limitée au propriétaire — visible par vous seulement), et RIEN n'est partagé avec un professionnel avant que vous choisissiez explicitement « Obtenir de l'aide », qui lance le moteur de jumelage et montre qui a été avisé avec ses échéances de réponse. « Continuer seul·e » garde tout sauvegardé et privé. Une absence de jumelage n'est jamais une impasse — la demande reste active et le chemin du Centre de soutien est offert.
• Sécurité intégrée selon le cahier des charges MVP : un échec de structuration vous ramène à votre récit avec une reprise visible et votre brouillon intact — jamais d'état structuré à moitié en silence. Le téléversement de documents et l'édition de chronologie empruntent le pipeline d'admission existant depuis la vue du dossier.

Facturation, un seul chemin payant de bout en bout : Stripe Tax sur chaque paiement, le portail de facturation, un moment d'activation clair (#1268)

• Le paiement d'abonnement calcule désormais les taxes avec Stripe Tax — TPS/TVH/TVQ pour le Canada et TVA à l'international, à partir de l'adresse de facturation exigée, avec collecte des numéros fiscaux pour les entreprises (numéros TPS/TVQ sur les factures) — jamais calculées à la main, exactement comme l'exige la règle d'autorité des frais. Le lancement du paiement est audité.
• L'autogestion arrive à /app/settings/billing : le forfait gratuit obtient un moment d'activation explicite (forfaits, prix, ce qui se débloque), et les comptes payants ouvrent le portail de facturation Stripe pour les cartes, la méthode par défaut, les factures avec lignes de taxes, les changements de forfait au prorata géré par Stripe, et l'annulation. La séance de portail dérive de la PROPRE ligne d'abonnement de l'appelant — ouvrir la facturation d'autrui est structurellement impossible — et chaque ouverture est auditée. Un défaut de paiement dégrade le compte et ne supprime jamais de données (la couche des droits traite déjà past_due comme actif).
• La couverture de la porte de lancement énumère désormais aussi l'arborescence billing : le paiement et le portail passent par leurs propres mérites, et le webhook est exempté avec son motif consigné (la vérification de signature EST la garde d'un appelant système). Une sonde d'attestation des relances intelligentes (STRIPE_SMART_RETRIES_CONFIRMED) complète la posture de recouvrement. Ceci ferme le dernier enfant de l'épopée Réglages et Opérations v1.

La porte de lancement V1 : surface réglages/espace/soutien vérifiée protégée + auditée — et maintenue ainsi par la CI (#1270)

• La porte de lancement de Réglages et Opérations v1 est franchie : chaque route sous settings, workspace et support a été énumérée et vérifiée pour l'autorisation côté serveur (garde de capacité ou portée de session propre), l'émission d'événements d'audit sur chaque mutation, et le câblage du gel juridique sur chaque transition de cycle de vie. Résultat : zéro surface non protégée ou non auditée ; deux exemptions documentées avec motif (le formulaire de soutien délibérément public, et l'audit du paiement qui arrive avec la tranche facturation). Tableau route par route dans docs/security/SETTINGS-CAPABILITY-AUDIT.md.
• Le passage est permanent, pas un instantané : un nouveau test de couverture énumère les mêmes arborescences de routes depuis le système de fichiers — toute future route réglages/espace/soutien est automatiquement vérifiée pour une garde et une couverture d'audit dès que le fichier existe ; une surface non protégée est une compilation en échec, pas un espoir de revue. L'absence de changement de résidence (#1267) est aussi affirmée, basculant en assertion de câblage du gel dès que cette surface apparaîtra. Ceci complète l'étape 10 sur 10 — la séquence de construction de l'épopée Réglages et Opérations v1 est terminée.

Zone de danger : cycle de vie de l'espace avec gel juridique suprême, grâce de 30 jours, purge sombre (#1266)

• Le cycle de vie de l'espace de travail arrive sous forme de machine à états stricte — actif → archivé → suppression-programmée → purgé, avec restauration et annulation — où l'ARCHIVAGE est l'action destructrice par défaut (réversible, préservant les données et l'historique d'audit) et la suppression définitive est enfouie un niveau plus bas : confirmation du nom exact tapé plus une fenêtre de grâce de 30 jours avant que la purge ne soit même possible. La purge est en outre livrée SOMBRE derrière l'indicateur de déploiement WORKSPACE_PURGE_ENABLED jusqu'à la résolution de la décision du conseiller par classe de rétention, et la lentille de capacités restreint déjà l'exécution de la zone de danger au fondateur.
• Le gel juridique est suprême (contrat n°3) : une nouvelle table de gels à l'échelle de l'espace (sœur de celle des dossiers, intouchée) bloque l'archivage, la suppression, la purge et le transfert de propriété à CHAQUE transition, revérifié côté serveur — seules les actions d'annulation (restauration, annulation) en sont exemptées. Les gels s'émettent/se lèvent sous legal_hold.manage, entièrement audités, et toujours visibles aux administrateurs de l'espace. retention_until survit à la purge par conception : la purge n'efface que les données opérationnelles.
• Le transfert de propriété (reporté de la tranche des membres) vit ici : propriétaire actuel seulement, confirmation du nom tapé, et la cible doit déjà être un membre administrateur actif. Chaque transition du cycle de vie est auditée et les actions destructrices déclenchent l'alerte de sécurité insuppressible. Ceci complète le dernier enfant de la séquence de construction de l'épopée Réglages et Opérations v1.

Membres de l'espace de travail : invitations, rôles, suspension, protection du propriétaire, acceptation versionnée des CGU (#1181)

• Les espaces de travail multi-utilisateurs deviennent gérables à /app/settings/workspace : invitation par courriel (invitations expirant après 14 jours, AU PLUS UNE invitation en attente par adresse imposée par un index unique partiel de la base de données), attribution des rôles fixes v1 (la propriété n'est pas un rôle et ne peut jamais être accordée par invitation ou changement de rôle), suspension/réactivation et retrait. Les invitations en attente sont listées distinctement et révocables ; l'invité reçoit un courriel bilingue dont le lien mène à une page d'acceptation dédiée.
• La porte des conditions sans laquelle on ne peut pas opérer : accepter une invitation EXIGE l'acceptation des conditions d'utilisation — le serveur refuse sans elle — et consigne l'horodatage ET la version acceptée sur la ligne d'adhésion ; une nouvelle version des conditions signale chaque membre pour ré-acceptation. L'invitation doit correspondre à l'adresse connectée (l'identifiant d'invitation n'est pas un jeton au porteur).
• Protection du propriétaire : le propriétaire de l'espace ne peut jamais être retiré, suspendu ou rétrogradé par l'API des membres (règle pure et testée appliquée sur chaque chemin de mutation) — la propriété ne se déplace que par un flux de transfert dédié. Chaque mutation du registre est protégée par capacité (workspace.manage_members) et auditée ; les métadonnées d'audit d'invitation ne portent que le DOMAINE de l'adresse.

Sécurité du compte : mot de passe + vérification de fuite, deux étapes TOTP, appareils, historique de connexion (#1180)

• La colonne vertébrale de protection du compte arrive à /app/settings/security. Le changement de mot de passe applique une politique de robustesse fondée sur la longueur et une vérification contre les fuites connues par k-anonymat HIBP — seul un préfixe de hachage de 5 caractères quitte le serveur, le mot de passe lui-même n'est jamais conservé, journalisé ni transmis — avec une déconnexion de tous les autres appareils en un clic. La vérification en deux étapes (TOTP) offre l'activation complète (QR + secret manuel), la vérification et la désactivation sur les propres identifiants de la session.
• L'historique de connexion présente les événements d'authentification récents du compte (connexions, déconnexions, récupérations, défis MFA) avec IP et appareil, lus du journal d'audit d'authentification de Supabase strictement épinglé à l'identifiant de l'appelant. Chaque action conséquente — changement de mot de passe, deux étapes activées/désactivées, déconnexion massive — consigne un événement d'audit infalsifiable et déclenche l'alerte de sécurité de classe requise au courriel du compte (« si ce n'était pas vous… »), que ni la suppression ni les heures de silence ne peuvent faire taire.
• Les routes d'agent des séances de soutien passent de la garde par persona à requireCapability('support.session') maintenant que le modèle de capacités est en production — même couverture, une seule couche de décision. Le carrefour des paramètres gagne des cartes pour Sécurité, Courriel, Préférences et Activité. La posture de récupération est délibérée et documentée dans l'interface : réinitialisation par courriel, auditée — la tension souveraineté/récupération du ticket est résolue vers fort-mais-auditable ; les codes de récupération maison n'ont volontairement pas été construits comme contournement parallèle de l'authentification Supabase.

Préférences : apparence et accessibilité — enregistrement instantané, multi-appareils, mode contraste élevé (#1183)

• Les réglages personnels d'apparence et d'accessibilité arrivent à /app/settings/preferences : thème (sombre / clair / système avec suivi en direct de l'appareil), taille du texte (87,5–150 %), réduction des animations et un vrai nouveau mode contraste élevé. L'enregistrement est instantané et optimiste — aucun bouton Enregistrer ; un refus du serveur rétablit visiblement le réglage précédent.
• Les préférences suivent le compte d'un appareil à l'autre : conservées par utilisateur dans une seule colonne jsonb validée (0107 — aucune nouvelle table, conformément au cahier des charges), appliquées au chargement de l'espace de travail par une synchronisation silencieuse, et reflétées dans les mêmes clés localStorage que lisent déjà le script d'amorçage et le widget d'accessibilité — le premier affichage reste instantané et toutes les surfaces restent cohérentes.
• Le serveur ne conserve que la fusion validée (clés inconnues abandonnées, valeurs hors plage refusées — jamais tronquées en silence), s'exécute exclusivement sur le client à portée RLS de l'appelant, et audite les noms des clés modifiées. La langue reste au sélecteur de l'en-tête (les formats de date et de nombre en découlent) ; le fuseau horaire des rappels reste sous Notifications.

Fil d'activité + vue d'audit : lecture seule, filtrable, export de qualité probante (#1182)

• Les administrateurs d'espace de travail obtiennent la surface de reddition de comptes du magasin d'événements d'audit : un fil d'activité lisible (filtres par acteur, action, cible, date) et une vue d'enregistrement d'audit de qualité probante portant l'événement canonique COMPLET — séquence, chaîne, hachages précédent/d'entrée, charge utile — exportable en JSON délimité par lignes, revérifiable contre la chaîne infalsifiable.
• Lecture seule par construction à chaque couche : la route n'exporte que GET (garde-fou testé), le module de projection ne fait que mettre en forme, et le magasin lui-même rejette UPDATE/DELETE au niveau de la base de données (0104). L'autorisation est en couches — requireCapability('audit.read_workspace') plus le client à portée RLS de l'appelant, de sorte que la politique de lecture d'espace 0104 double la vérification de capacité ligne par ligne ; le rôle de service n'apparaît jamais.
• Règle d'affichage anti-falsification appliquée dans le code : tout ce qu'un humain voit (espace, ip, agent utilisateur) dérive de la charge utile couverte par le hachage — la projection n'accepte même pas les colonnes miroir en entrée, une valeur miroir divergente ne peut donc jamais atteindre un écran. Nouvelle page : /app/settings/activity.

Réparation : livraison de l'implémentation du changement de courriel que la fusion 7.66.33 décrivait sans la contenir

• La fusion 7.66.33 portait l'entrée de journal et le numéro de version du changement de courriel vérifié, mais aucun de ses fichiers (une mauvaise révision source pendant la reconstruction de la branche a omis la tranche, et les portes ont réussi par vacuité puisque les tests manquants manquaient aussi). Cette version livre l'implémentation réelle depuis son commit d'origine : le flux demande → confirmation via la nouvelle adresse → bascule → avis à l'ancienne, l'alerte de classe requise immédiate vers l'adresse actuelle, le finaliseur idempotent aux métadonnées limitées aux domaines, la sonde d'attestation opérateur et la page /app/settings/email — vérifiée par sa suite de 9 tests désormais réellement présente et au vert.

Changement de courriel vérifié : demande → confirmation via la nouvelle adresse → bascule → avis à l'ancienne (#1179)

• Le changement d'adresse courriel ne bascule jamais à la soumission (contrat n°4) : la demande MET EN ATTENTE le changement sur la session de l'appelant (Supabase conserve la nouvelle adresse en attente et lui envoie un lien de vérification), une alerte de sécurité de classe requise part immédiatement vers l'adresse ACTUELLE — une session détournée ne peut pas déplacer le compte en douce — et la bascule n'a lieu que lorsque la NOUVELLE boîte confirme.
• À la bascule, le rappel d'authentification avise l'ANCIENNE adresse (pendant que le miroir du profil la détient encore — l'avis précède délibérément la synchronisation du miroir pour qu'un échec ne puisse jamais faire disparaître l'avis), synchronise profiles.email et consigne l'événement d'audit. Le finaliseur est idempotent (un lien recliqué ne fait rien) et les métadonnées d'audit ne consignent que les DOMAINES, jamais les adresses.
• Sonde d'attestation opérateur ajoutée pour l'interrupteur Secure email change du tableau de bord Supabase (SUPABASE_SECURE_EMAIL_CHANGE_CONFIRMED — l'état du tableau de bord n'est pas lisible par API, les surfaces de préparation s'appuient donc sur l'attestation). Nouvelle page de paramètres : /app/settings/email.

Réparation : restauration du modèle de capacités, des avis requis et de l'accès au soutien annulés par trois fusions défectueuses

• Les fusions 7.66.29 à 7.66.31 provenaient de branches basées sur un main plus ancien, et l'étape d'aplatissement a mis en scène la suppression de tout ce que main avait gagné entre-temps : le modèle de capacités de 7.66.28 (requireCapability, lentilles, refonte des gardes admin, l'approbation du modèle de frais consignée), les classes d'avis requises de 7.66.29 (application dans la voie d'envoi, gabarits security-alert/billing-alert) et le système d'accès au soutien de 7.66.30 (octrois, séances, indicateur, migration 0105) ont chacun été silencieusement annulés par la fusion suivante. Cette version restaure les 28 fichiers touchés depuis leurs branches d'origine — les fonctionnalités décrites dans ces trois entrées du journal sont maintenant réellement sur main, vérifiées par leurs propres suites de tests (matrice de capacités, application des classes requises, invariants de l'accès au soutien) ainsi que la suite complète de portes et une compilation de production.

Coquille des paramètres + Profil : page carrefour, champs d'identité modifiables, avatars traités côté serveur (#1178)

• Le carrefour des paramètres arrive à /app/settings, réunissant Profil (nouveau), Notifications et Accès au soutien. Le profil modifie le nom, le téléphone et l'organisation — en réutilisant les colonnes qui existent depuis 0001, sans quasi-doublons — avec le modèle d'enregistrement du cahier des charges : Enregistrer reste désactivé tant qu'aucun champ n'a changé, les modifications non enregistrées déclenchent une invite avant de quitter, et un clic restaure l'état enregistré. Le courriel est délibérément en lecture seule ici : son changement passe par le flux vérifié étape → confirmation via la nouvelle adresse (#1179), jamais par un enregistrement de profil.
• Les avatars sont traités CÔTÉ SERVEUR, toujours (§4.1) : les téléversements sont validés (JPEG/PNG/WebP, ≤2 Mo — SVG refusé), puis réencodés par sharp en webp 512×512 avant d'atteindre le stockage — le compartiment ne conserve jamais un flux d'octets original du client (EXIF supprimé, fichiers polyglottes neutralisés). Le nouveau compartiment public avatars (migration 0106) épingle chaque écriture au fichier nommé par l'identifiant de l'appelant, au niveau des politiques de stockage.
• Chaque route s'exécute exclusivement sur le client à portée RLS de l'appelant (le rôle de service n'apparaît jamais — garde-fou testé), les champs privilégiés (rôle, forfait, courriel) ne peuvent jamais traverser le validateur, et les changements de profil/avatar sont audités avec les NOMS des champs modifiés seulement — la chaîne d'audit infalsifiable consigne que le téléphone a changé, pas le téléphone.

Accès au soutien niveau 1 : opt-in, expirant, une seule séance en direct, révocable instantanément, entièrement audité (#1269 partie 2)

• L'accès au soutien limité aux transcriptions arrive (migration 0105) : le titulaire du compte donne son accord par un octroi expirant automatiquement après 72 heures ; un agent de soutien peut ouvrir AU PLUS UNE séance en direct sur cet octroi — imposé par un index unique partiel de la base de données, de sorte que la garantie tient même en cas de concurrence, pas seulement dans la logique des routes. La révocation est instantanée et irréversible (la seule modification permise au titulaire consigne revoked_at — prolonger l'échéance ou changer la portée par cette politique est impossible) et met fin immédiatement à toute séance en direct.
• Transparence par construction : l'utilisateur qui accorde l'accès voit toujours chaque séance ouverte sur son compte (politique de visibilité RLS), une bannière persistante le suit dans tout l'espace de travail tant que l'accès est actif — clignotante lorsqu'une séance est en cours — avec révocation en un clic, et chaque octroi, révocation, ouverture et fin de séance est consigné dans la chaîne d'audit infalsifiable avec horodatage serveur. Nouvelle page de paramètres : /app/settings/support.
• Les routes de séance côté agent sont protégées par la garde ops-admin en v1 (les administrateurs de la plateforme sont le soutien de niveau 1), avec mise à niveau documentée vers requireCapability('support.session') dès l'arrivée du modèle de capacités — mêmes personnes, une seule couche de décision.

Classes d'avis requises : Sécurité et Facturation ne peuvent être réduites au silence — appliqué dans la voie d'envoi (#1269 partie 1)

• Chaque gabarit d'avis appartient désormais à exactement une classe (sécurité / facturation / juridique / compte / produit — correspondance totale, vérifiée par test), et les classes Sécurité et Facturation sont REQUISES : sendNotification ne consulte plus la liste de suppression pour elles (une adresse désabonnée reçoit quand même les avis de sécurité et de facturation — ils sont transactionnels, pas du marketing ; le désabonnement continue de faire taire toutes les classes optionnelles), et le répartiteur de rappels ne reporte jamais un message de classe requise aux heures de silence. L'application vit dans la voie d'envoi — l'écran des préférences marque les deux classes Requises avec des interrupteurs verrouillés, mais cela est explicitement cosmétique.
• Les deux premiers gabarits requis arrivent avec la mécanique : security-alert et billing-alert (bilingues), prêts pour les flux de changement de courriel/2FA (#1179/#1180) et les événements de facturation (#1268).

Modèle de capacités : un arbre, 7 lentilles de rôle, requireCapability comme seule garde dorsale (#1177) ; approbation du modèle de frais/référence consignée (#448)

• La couche d'autorisation Réglages & Opérations arrive : un arbre de capacités (18 capacités, chacune avec un niveau de sensibilité) projeté à travers 7 lentilles de rôle (Fondateur/Propriétaire détient tout ; personne d'autre ne détient la zone de danger). requireCapability est la seule primitive d'autorisation des actions serveur — les capacités liées à un espace de travail exigent un workspaceId et l'adhésion active de l'appelant, et chaque chemin est fermé par défaut (sans session 401, espace manquant 403, capacité non détenue 403).
• Réconcilie les deux systèmes de rôles EXISTANTS au lieu de les dupliquer : profiles.role (administrateurs plateforme) et organization_members.role (rôles d'espace, 0084) se projettent dans le même arbre — les administrateurs existants détiennent leurs capacités dès le premier jour, sans reprise. resolveOpsAdmin et requireAdminSession acheminent désormais leur décision par la couche de capacités (platform.ops). <Can> et visibleNav ne sont que des projections cosmétiques ; masquer ne remplace jamais la vérification serveur (#1177).
• L'approbation par le conseiller juridique du modèle de frais/référence est désormais consignée durablement dans le code (FEE_MODEL_COUNSEL_APPROVAL, approuvé le 2026-07-02, lié à l'attestation sur le ticket) : la grille PAR DÉFAUT du moteur de frais devient la grille de production approuvée (FEE_MODEL_VERSION 2026-07-approved-1). Approbation et activation restent délibérément séparées — la voie monétisée demeure fermée tant que l'opérateur n'a pas défini ATTORNEY_ETHICS_MEMO_APPROVED=1 et ATTORNEY_MARKETPLACE_MONETIZATION_LIVE=1 ; les modèles bloqués (pourcentage d'honoraires, honoraires de résultat) restent bloqués (#448).

Magasin d'événements d'audit : append-only au niveau BD + lecture par espace de travail + événements générés côté serveur (#1176)

• Le substrat d'audit à chaîne de hachage (0045) est formalisé comme Magasin d'événements d'audit V1 (migration 0104). UPDATE/DELETE sont désormais révoqués au niveau des privilèges de base de données pour chaque rôle d'API — anon, authenticated ET service_role — sur les deux tables de chaîne : le contrat append-only tient même si un déclencheur était supprimé. workspace_id/ip/user_agent deviennent des colonnes GÉNÉRÉES dérivées de la charge utile couverte par le hachage : elles ne peuvent jamais diverger de ce que couvre le hachage d'entrée, rendant toute falsification des miroirs impossible par construction.
• Les administrateurs d'espace de travail peuvent désormais lire le journal d'audit de leur propre espace : can_read_workspace_audit(w) (SECURITY DEFINER, fermé par défaut, administrateurs d'organisation actifs seulement) alimente une nouvelle politique SELECT qui s'ajoute à la lecture admin-plateforme de 0045 — la capacité que le futur fil d'activité (#1182) consommera en projection.
• Le nouvel émetteur lib/security/audit-events.ts est la seule voie par laquelle le code serveur enregistre un événement d'espace de travail : il dérive ip/user-agent de la requête côté serveur, appose l'espace de travail et délègue à l'écrivain de chaîne, qui attribue l'horodatage d'horloge serveur — la surface de types de l'émetteur ne peut pas transporter d'horodatage client, et les clés de contexte réservées ne peuvent pas être usurpées via les métadonnées. Des tests d'acceptation couvrent les privilèges, les miroirs générés, la capacité et les contrats de l'émetteur.

Les métriques fondateur passent à l'agrégation SQL ; garde-fous des adaptateurs ; tests unitaires auth/facturation ; script de thème externalisé (#1098 #1102 #1106 #1107)

• Les métriques du Centre de commande fondateur s'agrègent désormais dans Postgres (admin_metrics_rollup, migration 0103) au lieu de télécharger jusqu'à 50 000 lignes de growth_events (plus des balayages de 2 à 10K lignes de service_orders, order_tickets, ai_audit_events, procedures et matters) dans la fonction serverless pour des boucles JS. Au-delà des anciens plafonds, les lignes étaient silencieusement abandonnées — les chiffres du tableau de bord étaient une borne inférieure ; à l'échelle, les lectures risquaient l'épuisement mémoire. Le rollup est réservé au rôle de service, conserve la ventilation canonique des billets dans lib/ops/ticket-counts, et un test garde-fou interdit la réintroduction de lectures massives (#1098).
• Les interfaces d'adaptateur Supabase sont désormais vérifiées contre le vrai client : les adaptateurs rpc (récupération ciblée, rappel, garde d'édition de dossier) sont affirmés statiquement dans lib/types/supabase-adapter-compat.ts, et chaque adaptateur à chaîne from() (chaîne d'audit, export/effacement vie privée, propositions, magasins de rappels) est parcouru à l'exécution par un test de forme de chaîne — une mise à niveau de supabase-js qui casse une surface fait désormais échouer la CI en la nommant, au lieu de lever en production (#1102).
• Tests unitaires ajoutés pour les modules lib critiques d'authentification qui n'en avaient aucun : comportement fermé-par-défaut d'assertCanEditMatter (isolation des locataires), routage de portail + liste d'autorisation anti-redirection ouverte, chemins d'erreur du rappel d'authentification et résolution de langue, et appels Stripe de la facturation mesurée du Copilote (#1106).
• Le script de thème pré-affichage passe d'un script en ligne dans <body> au fichier externe /theme-init.js : le code maison n'exige plus 'unsafe-inline' dans la CSP (le JSON-LD est un bloc de données non exécuté que la CSP ignore) ; l'en-tête CSP documente que seuls les scripts d'amorçage propres à Next.js en dépendent encore (#1107).

Sécurité : audit d'accès des routes liées aux dossiers — renforcement de la génération de production ; documentation des routes RLS seules (#1231)

• Audit de chaque route d'API liée à un dossier pour son garde-fou d'isolation des locataires. Résultat : aucune faille inter-locataires ni de contournement RLS — chaque route utilisant le client service-role (admin) est protégée par une vérification de propriété explicite, une relecture RLS, ou est limitée à la propre ligne de l'appelant. Une route privilégiée, /api/production/[id]/build, ne s'appuyait que sur RLS : elle renvoie désormais un 401 propre aux appelants non authentifiés et applique can_edit_matter (403) afin qu'un collaborateur en lecture seule ne puisse plus déclencher une production destinée au tribunal — conformément au précédent accept/reject des extractions. L'audit complet (chaque route et son garde-fou, ainsi que les routes délibérément RLS seules et les routes système/cron) est documenté dans docs/security/MATTER-ROUTE-ACCESS-AUDIT.md.

Correctif : le garde-fou version-advances ne provoque plus de faux échec sur main (build-and-test au vert)

• Le garde-fou check:version-advances ne s'esquivait que lorsque le SHA de HEAD était exactement égal à origin/main. Après chaque fusion, le workflow auto-version-bump pousse un commit de version « [skip ci] » : au moment où la CI s'exécute, origin/main a donc avancé vers un SHA différent portant la même version — l'esquive par égalité stricte échouait et le garde-fou tombait en erreur sur des versions égales, mettant main au rouge après chaque fusion sans qu'aucune régression n'ait eu lieu. Le garde-fou s'esquive désormais dès que HEAD est contenu dans origin/main (sur main, sur un commit post-fusion, ou sur un commit qu'origin/main a depuis dépassé), tout en exigeant toujours une progression stricte de version sur une véritable branche de fonctionnalité ouverte. Rétablit un build-and-test vert sur main.

Correctif : consolidation de l'IA draft + copilot sur le limiteur de débit partagé par utilisateur (main au vert)

• La consolidation des limiteurs de débit des routes IA (#1222) n'avait pas atteint /api/ai/draft ni /api/ai/copilot — ils conservaient des limiteurs en ligne distincts (et copilot renvoyait encore le jeton incohérent « rate-limited »). Les deux utilisent désormais aiUserRateLimiter partagé et le jeton canonique AI_RATE_LIMITED, de sorte que les six routes IA orchestrées appliquent un plafond agrégé unique par utilisateur. Le test garde-fou #1112 a été mis à jour pour vérifier le câblage du limiteur partagé, rétablissant un build-and-test vert sur main.

Rétention : réconciliation des catégories divulguées et appliquées ; les notifications liées à un dossier suivent le dossier (#1229)

• La politique de rétention divulguée couvre désormais toutes les catégories réellement appliquées par le moteur de balayage (télémétrie, croissance, file de notifications, partages de dossier étaient appliquées sans être divulguées — une lacune Loi 25), chacune annotée de son mécanisme d'application, avec un test garantissant qu'aucune catégorie appliquée ne peut plus être omise de la divulgation.
• L'historique de livraison des notifications lié à un dossier n'est plus purgé à 180 jours — les lignes liées à un dossier sont conservées pour la durée de vie du dossier (jamais balayées par âge tant qu'elles sont liées ; libérées vers un délai de grâce de 180 jours seulement une fois le dossier supprimé), de sorte qu'un dossier relancé des années plus tard conserve son historique complet. Les notifications opérationnelles sans dossier continuent d'être purgées à 180 jours. Le test de rétention a été converti de vitest vers node:test et enregistré.

Correctif : la porte de sécurité CSAM liste ses trois contrôles requis (#1213)

• L'élément de sécurité CSAM de la file d'actions opérateur liste désormais CSAM_REPORTING_CONTACT aux côtés de CSAM_SAFETY_LIVE et CSAM_HASH_MATCHER_URL dans sa liste de prérequis, conformément à ce que sa vérification satisfied (et la porte canonique csamSafetyReadiness) appliquent réellement — fin de l'incohérence où les prérequis affichés sous-estimaient la porte réelle à trois variables.

Vague d'hygiène dorsale, d'accès aux espaces de travail et d'UX (15 correctifs)

• Vie privée et exploitation : renseignements personnels (courriels, identifiants d'utilisateur/dossier) expurgés des journaux de routes publiques et traces de copilote retirées hors de la chaîne d'audit ; 11 portes d'administration en ligne regroupées sur resolveOpsAdmin() ; /api/ai/draft et /api/ai/copilot limités en débit avant toute dépense de modèle ; l'indicateur rateLimiting reflète l'application réelle ; erreurs serveur capturées sur toutes les routes via l'instrumentation Next ; crons brain/memory-consolidation/reconciliation/uptime planifiés.
• Accès aux espaces de travail et portes de révision : visibilité des modules en refus par défaut (G1) appliquée avec des slugs injectifs ; un limiteur de débit IA partagé par utilisateur avec une erreur rate_limited canonique ; analyse YAML robuste et validation complète des approbations pour les portes de révision juridique/native, câblées comme scripts check:*.
• UX et i18n : limites error.tsx/loading.tsx localisées sous app/[lang] ; étiquettes de disponibilité/vérification de ProviderCard déplacées dans le dictionnaire ; truncate() protégé contre les limites non positives et safeNext retiré du baril client ; nettoyages du tri par défaut des experts, des revendications de propriété et du formateur de dates de faits partagé.

Dorsal du MVP Judge911 : admission de litige, structuration IA, mise en relation de prestataires (épopée #100)

• La migration 0102 ajoute des champs d'admission aux litiges (catégorie, niveau d'urgence, données structurées, juridiction) et match_score/lead_expires_at aux mandats. Nouvelles routes : /api/disputes/[id]/structure (structuration IA via l'orchestrateur avec sorties structurées, mesurée, à sécurité intégrée en cas d'erreur), /api/disputes/[id]/match (mise en relation par règles, top-3, création de pistes + diffusion en temps réel), /api/leads/[id] (acceptation/refus par le prestataire avec contrôle de propriété de l'entité et concurrence optimiste), /api/providers/leads (boîte de réception des pistes par entité) et un cron horaire d'expiration des pistes protégé par requireCronAuth.
• Le triage d'urgence échoue en sécurité (l'inconnu est escaladé, jamais rétrogradé) ; chaque mutation passe par la chaîne d'audit inviolable ; les paiements restent verrouillés (aucun mouvement d'argent en v1). L'interface du générateur de dossier est un suivi répertorié.

Système d'exploitation des revenus Judge911 (doctrine corrigée pour la conformité)

• Publication de docs/doctrine/JUDGE911-REVENUE-OS.md — le document directeur unique régissant la vente, le marketing, la tarification et la représentation de Judge911 par chaque personne et système d'IA, après une revue contradictoire UPL/vie privée. Corrections : aucune évaluation du bien-fondé ou du résultat dans le texte ou les noms de fonctionnalités (un indicateur d'exhaustivité/d'urgence remplace l'indicateur de risque rejeté) ; les sections de conformité interdisent d'appliquer le droit aux faits d'un utilisateur, quel que soit l'étiquetage ou l'avertissement ; la mise en relation d'avocats comporte une porte indépendante de service de référence par juridiction en plus de la porte de frais ; les affirmations commerciales sont conditionnées à des données mesurées et les affirmations de sécurité à des indicateurs de disponibilité au vert.
• Renforcement de la posture de vie privée (responsable Loi 25, évaluation transfrontalière, registre d'incidents, divulgation de décision automatisée, consentement exprès pour les données sensibles) et ajout des exigences de consentement, d'identification de l'expéditeur et de désabonnement CASL/Loi 25 au plan marketing ; ajout d'une règle obligatoire de divulgation « information et non conseil » par réponse pour l'IA en produit. Doctrine seulement — aucun changement de comportement d'exécution.

Correctif : la porte trust-gaps des rails de paiement suit la configuration dédupliquée

• L'assertion des rails de paiement de check:trust-gaps lit désormais lib/payouts/config.ts en plus de release-readiness.ts, afin de continuer à détecter les contrôles Stripe Connect / TEF-CA / paiements-fournisseurs après leur regroupement dans l'assistant de configuration partagé. Rétablit un build-and-test vert sur main ; aucun changement de comportement des portes de paiement.

Devis de construction Paramètres et Opérations v1

• Publication de docs/spec/SETTINGS-OPS-V1.md — l'architecture synthétisée de l'épopée Paramètres et Opérations (le magasin d'événements d'audit et le modèle de capacités comme substrat, chaque surface de paramètres étant consommatrice de capacités et émettrice d'audit), avec chacune des 11 sous-tâches rattachée à des tables existantes plutôt qu'à de nouvelles (extension de la chaîne de hachage inviolable, réconciliation des deux systèmes de rôles existants, réutilisation des tables de profil/préférences/effacement).
• Consigne la règle de sécurité bloquante relevée par la revue de conception : toute vue de base de données d'événements d'audit doit être déclarée security_invoker avec des droits verrouillés, sinon elle expose silencieusement la chaîne d'audit inter-locataires en contournant la sécurité au niveau des lignes. Inclut le plan de construction ordonné en 6 trains avec la passe de couverture permissions/audit comme fourgon de vérification. Documentation de planification uniquement — aucun changement d'exécution.

Performance de l'espace de travail : mémoïsation + panneaux différés (6 correctifs)

• Les agrégats de JusticeHome, les listes filtrées et les dérivations par carte sont mémoïsés ; la recherche du dossier sélectionné, la détection de conflits et les rappels de JusticeHome ne se recréent plus à chaque rendu ; plus de 30 panneaux à onglets se chargent en différé via React.lazy/Suspense.
• importStrandedLocalMatters signale les résultats par dossier au lieu d'un échec global quand une écriture infonuagique partielle a réussi ; le retrait d'un paquet dans FilingReadiness et les boutons désactivés d'ActionCard gagnent des confirmations/indices. Le garde-fou de conservation légale (#1201) sur la suppression locale de dossier est préservé à travers la refactorisation des rappels.

Vague de correctifs : sécurité, paiements, logique, tests, i18n, accessibilité (37 correctifs)

• Sécurité et données : durcissement de la RLS de service_orders contre l'injection inter-locataires de matter_id, avec verrouillage optimiste (migration 0101) ; la conservation légale bloque désormais les balayages de rétention, la purge locale et la suppression globale, avec un historique de conservation en ajout seul ; garde-fous 0093 qualifiés par schéma ; registre/harnais RLS réconciliés.
• Paiements et conformité : le requestId de paiement Stripe est validé sur le propriétaire authentifié ; le décaissement en direct est conditionné à la vérification de disponibilité des paiements ; le calcul de prix ajoute la TVP SK/MB/BC et réconcilie les taux QC/NS dans les modules d'autorité des frais ; la validation des sous-traitants ne se contourne plus sur des dates invalides.
• Logique : l'évaluateur de prescription échoue désormais en sécurité (un champ manquant est signalé pour révision au lieu d'être déclaré prescrit) ; le réducteur d'audience préserve l'horodatage d'AJOURNEMENT et encadre les transitions ; correctif de casse de la liste blanche de juridictions + audit de qui l'a activée ; correctifs de langue/obsolescence du classificateur de taxonomie documentaire.
• i18n et accessibilité : bannière d'erreur de téléversement en français et actions de préparation au litige en espagnol localisées ; validation du permis d'avocat par juridiction (ON/BC/QC) ; apple-app-site-association servi en application/json ; étiquettes ARIA de ScrollNav/NotificationBell localisées ; pièges de focus + cibles de 44 px pour les fenêtres OutboundLink et de sortie ; contraste du mode clair relevé au niveau WCAG AA ; étiquettes, états de chargement et messages d'erreur du formulaire d'expert.
• Tests et exploitation : correction de la fuite de promesse de health-probe qui annulait les tests voisins ; variable d'environnement d'alerte d'incident et sur-déclaration de canaux corrigées.

Judge911 MVP v1 : devis de construction adapté à l'architecture

• Publication de docs/spec/JUDGE911-MVP-V1.md — le plan MVP de Judge911 (édition américaine) adapté à l'architecture réelle : les litiges reçoivent les champs d'admission via la migration 0102, les prestataires et les pistes s'appuient sur le cœur unifié de la place de marché (0100), les documents passent par le pipeline de stockage analysé, et les événements transitent par la chaîne d'audit inviolable plutôt que par une nouvelle table.
• Les garde-fous de conformité sont consignés comme bloquants : le triage d'urgence échoue vers l'urgence supérieure (un mauvais triage est un incident P0), l'admission respecte la minimisation des données de la Loi 25, et la v1 ne déplace aucun argent — les portes de monétisation sous revue juridique restent fermées. Les infrastructures reportées conservent des déclencheurs de réexamen explicites.

Cœur de la place de marché : invariants RLS verrouillés en CI

• Le harnais d'audit RLS gagne une section pour le cœur de la place de marché : la CI échoue désormais si la table de séquestre acquiert un chemin d'écriture utilisateur (elle est réservée au rôle de service par conception), si les vérifications de conflits perdent leur restriction administrateur, si l'auto-inscription d'une entité cesse d'imposer le statut « en attente », ou si le déclencheur de protection des champs de vérification disparaît.
• Les deux défauts corrigés lors du déploiement de la migration 0100 sont épinglés comme tests de régression : chaque création d'énumération doit rester gardée pour l'idempotence, et la référence à la colonne fantôme e.status ne peut jamais réapparaître.

Cœur de la place de marché : schéma unifié déployé (migration 0100)

• Promotion de la migration du cœur unifié de la place de marché (0100) : sept tables — entités, annonces, mandats, disponibilités, recommandations, vérifications de conflits, séquestre — consolidant les places de marché fragmentées (huissiers, experts, prestataires) en une seule couche d'échange avec sécurité au niveau des lignes sur chaque table.
• Posture de sécurité : le séquestre est en lecture seule pour les parties et modifiable uniquement par le rôle de service (l'état monétaire n'est jamais modifiable par un utilisateur) ; les vérifications de conflits sont réservées aux administrateurs ; les champs de vérification sont protégés par un déclencheur dédié. Deux défauts corrigés à la promotion : les huit créations d'énumérations sont gardées pour l'idempotence, et la politique de disponibilité référençait une colonne inexistante (e.status → e.entity_status).
• Les sept tables sont inscrites au registre RLS avec leur portée attendue, de sorte que le harnais d'audit CI applique le modèle d'isolation dès cette version.

Authentification des crons : une seule garde partagée pour chaque point de terminaison planifié

• Les neuf points de terminaison cron (retention, uptime, filing-status, memory-consolidation, reconciliation, brain, ai-index et les deux routes de notifications) s'authentifient désormais par une unique garde partagée requireCronAuth dans lib/notifications/cron — CRON_SECRET par en-tête Bearer uniquement, comparaison à temps constant et un seul corps 401 générique pour tout échec d'authentification. Les sept routes qui renvoyaient encore un corps distinct cron_not_configured ne révèlent plus l'état de configuration aux appelants externes ; la mauvaise configuration est plutôt journalisée côté serveur par tâche.
• Nouveau test statique anti-dérive (lib/__tests__/cron-auth-consistency.test.ts) : il balaie chaque route cron et échoue si l'une d'elles réimplante sa propre vérification de CRON_SECRET ou réintroduit le corps divulguant l'état de configuration — la garde partagée est désormais imposée par la CI, pas par convention.

Outillage de versionnage : package-lock.json rejoint le verrouillage de version

• scripts/sync-version-to-changelog.ts reflète désormais aussi la version du journal des modifications dans les deux champs de version racine de package-lock.json (niveau supérieur et packages[""]), comblant l'écart qui laissait le fichier de verrouillage prendre du retard sur des trains de versions entiers (il restait à 7.65.57 alors que package.json atteignait 7.66.x), malgré l'exigence de docs/VERSIONING_MASTER_PLAN.md d'une version unique dans les quatre fichiers.
• La mise à jour du fichier de verrouillage est un remplacement de chaîne ciblé portant uniquement sur les chaînes de version racine du projet — l'arbre de dépendances reste identique octet pour octet, donc la résolution de npm ci n'est pas affectée. L'estampille de version de cette parution a été produite par le script corrigé, comme preuve de bout en bout.

Politique de validation CI v1 — contrôles bloquants, souples et informatifs

• Publication de docs/ci-policy.md : une politique de validation à trois niveaux pour la surface CI du dépôt — niveau 1 bloquant (build-and-test, doit être vert pour fusionner), niveau 2 souple (suites de bout en bout Playwright/Momentic/Testim, bloquantes seulement quand un changement touche la surface d'interface), niveau 3 informatif (aperçus, analyseurs heuristiques, revues automatisées).
• La politique comprend une clause de primauté (la configuration de la plateforme prévaut sur le document), un plan d'application à exécuter par un humain pour la protection de branche, et un audit de vérification afin que la politique écrite et la configuration GitHub réelle ne puissent pas diverger silencieusement.

Téléversements volumineux : progression réelle + traitement robuste des chemins

• Les téléversements de preuves au-delà de 25 Mo affichent désormais une progression réelle par octets (voie XMLHttpRequest avec repli SDK), remplaçant l'indicateur indéterminé ; au-delà de 100 Mo, la posture de quarantaine existante est inchangée — les fichiers restent exclus de la diffusion jusqu'à leur analyse.
• Correction du chemin du point de terminaison de téléversement direct : chaque segment est encodé individuellement, de sorte que le chemin de stockage par dossier (matterId/fichier) parvient intact à Supabase Storage au lieu d'un segment unique encodé %2F.

Place de marché des experts : API du répertoire public

• Nouvelle route GET /api/marketplace/experts — liste les profils d'experts publiés avec filtrage paginé par discipline, région et langue. La lecture via le rôle de service projette une liste blanche explicite de colonnes publiques (EXPERT_PUBLIC_COLUMNS) — jamais select(*) — de sorte que les identifiants d'authentification, numéros de membre, dates d'assurance, palier d'abonnement et données internes de qualification ne peuvent jamais fuir par le répertoire public.
• Ajout de tests unitaires couvrant le calcul de pagination, la transmission des filtres, le contrat de forme de réponse et la projection des colonnes publiques.

Cron des notifications : un seul gestionnaire partagé et durci

• La route canonique /api/cron/notifications et son alias /api/notifications/cron réexportent désormais un seul gestionnaire partagé (handleNotificationsCronRequest dans lib/notifications/cron) : l'authentification et le déclenchement sont définis exactement une fois, de sorte que les deux routes ne peuvent plus diverger en comportement, en authentification ou en forme d'erreur.
• Le gestionnaire partagé conserve la posture d'authentification stricte du durcissement 7.65.59 sur LES DEUX routes : seul l'en-tête Authorization: Bearer est accepté (le canal de requête ?secret= est refusé afin que le secret ne fuie pas dans les journaux d'accès), et toute requête non autorisée reçoit le même 401 générique, que CRON_SECRET soit absent ou que l'identifiant soit erroné — la mauvaise configuration est journalisée côté serveur, jamais exposée.

Correctif CI : consolidation du chargeur de la porte de pureté d'édition

• La porte check:edition-purity s'exécute désormais via le chargeur standard du dépôt (`node --import tsx`) avec des imports de modules réguliers, corrigeant l'échec MODULE_NOT_FOUND dépendant de l'environnement (billet #1252) que le chargeur tsImport ciblé pouvait rencontrer sur des require CommonJS imbriqués.
• Ajout d'un test d'invariant sur le câblage du chargeur afin que le chemin d'exécution de la porte reste aligné avec les autres vérifications TypeScript (check:locales, check:security-scan).

Garde-fou CI : collisions de migrations (aucun nouveau numéro de migration en double)

• Ajout de la porte check:migration-collisions (scripts/check-migration-collisions.mjs) : la compilation échoue si deux fichiers de migration Supabase partagent le même préfixe numérique à 4 chiffres, de sorte que des branches concurrentes ne peuvent plus revendiquer silencieusement le même « prochain » numéro de migration.
• Les cinq groupes de doublons hérités déjà appliqués en production (0043, 0045, 0069, 0092, 0093 — 14 fichiers) sont gelés exactement tels quels ; ajouter un fichier à un groupe gelé échoue aussi. Le garde-fou s'exécute avant apply-migrations dans la compilation, couvrant la CI et les déploiements en production.

Synchronisation de dossier : ingestion + provenance (dorsal)

• Ajout du dorsal sécurisé pour la synchronisation bidirectionnelle des dossiers : la migration 0095 ajoute des colonnes de miroir-disque et de provenance à documents et un compartiment de stockage privé matter-documents avec RLS par dossier.
• Nouvelle route /api/matters/ingest qui valide les fichiers téléversés et synchronisés (auth par témoin, revérification can_edit_matter côté serveur, analyse antimaliciel avant écriture durable, empreinte SHA-256, provenance source) — Supabase est le système de référence.
• Nouvelle route /api/matters/mirror-status qui enregistre le résultat du miroir-disque au mieux pour un document, avec contrôle de propriété ; l'audit passe par la chaîne de hachage inviolable existante (aucune table d'audit parallèle).

Docs : spécification Espace-dossier v1 + découpage en tickets

• Ajout de la spécification v1 de l'Espace-dossier (espace local-first, sauvegarde chiffrée à connaissance nulle) et de son découpage en 8 épopées / 30 tickets sous docs/spec/, arrimé au modèle de données Supabase.
• Documentation du modèle de posture de sécurité configurable (confidentialité de sauvegarde par dossier Hard/Soft/Hybrid + plancher de consentement à l'enregistrement imposé selon la juridiction) et de la synchronisation bidirectionnelle des dossiers (Supabase système de référence, disque miroir au mieux, provenance source).
• Signalement de la décision ouverte sur les paliers de stockage (coffre de preuves à connaissance nulle vs. couche de travail lisible par le serveur). Documentation de planification uniquement — aucun changement de code ou de comportement d'exécution.

Garde-fou CI : autorité des frais (source unique de vérité pour le calcul monétaire)

• Ajout de la porte check:fee-authority (scripts/check-fee-authority.mjs) : échoue si un fichier hors des modules autoritatifs de frais/taxes (lib/marketplace/fee-engine.ts, lib/payouts/ledger.ts et les autres autorités listées) définit une table de taux de frais/taxes, multiplie un montant par un taux de frais/taxes, ou code en dur une constante de TVQ.
• Empêche la réapparition du motif rejeté #1064 — un moteur de tarification parallèle piloté par l'IU qui inversait le sens des frais et divergeait du grand livre. La couche de présentation doit afficher des valeurs calculées côté serveur ; une exception révisée utilise un commentaire `fee-authority-allow`.

Versements : porte de pré-activation « posture fiscale + runbook de versements » (#449)

• Renforcement de la porte d'aptitude des versements : aucun canal (Stripe Connect US ou EFT CA) n'est déclaré prêt tant que TAX_POSTURE_APPROVED et PAYOUT_RUNBOOK_APPROVED ne sont pas tous deux définis — attestations humaines pour la note de posture fiscale et le runbook opérateur de versements.
• Les deux indicateurs sont intégrés (ET logique) au rapport existant payoutRailReadiness().live et au signal de confiance providerPayouts — sans porte parallèle. Comme le paiement des lanes réglementées (expert/avocat) dépend de providerPayouts, une porte non satisfaite bloque ces paiements. Les deux indicateurs figurent dans la liste des bloqueurs par canal.
• Sens sécuritaire par défaut : si les indicateurs ne sont pas définis, le signal d'aptitude des versements est retenu (non vert). Les opérateurs doivent définir les deux variables — avec PROVIDER_PAYOUTS_LIVE et les identifiants du canal — avant que les versements réglementés soient considérés prêts.

Renforcement de la sécurité — correction XSS dans les blocs JSON-LD + correction de l'exposition de CRON_SECRET dans les journaux

• Ajout de jsonLdSafe() dans lib/seo.ts : échappe les séquences </script> dans les données structurées JSON-LD pour prévenir l'injection de scripts lorsqu'un champ provient d'un enregistrement modifiable par l'utilisateur (recommandation RFC 4627 / Google Structured Data).
• Application de jsonLdSafe() sur les 6 blocs dangerouslySetInnerHTML JSON-LD : layout.tsx, research/[slug], guides/[slug], editions/[country], experts/[discipline]/[expertId] et press/lancement.
• Correction de l'exposition de CRON_SECRET dans les journaux pour /api/cron/retention et /api/cron/notifications : ajout de { allowQuery: false } afin que le secret ne puisse plus être transmis via le paramètre ?secret= (lequel est enregistré en clair dans les journaux Vercel). Conforme aux 6 autres routes cron utilisant déjà ce drapeau.

Maintenance des dépendances : mises à niveau sûres dans les plages existantes

• Mise à niveau de dépendances à faible risque dans leurs plages semver existantes : @supabase/supabase-js 2.108→2.110, @playwright/test 1.60→1.61.1, pg 8.21→8.22, nodemailer 9.0.1→9.0.3, vitest 4.1.8→4.1.9, le SDK IA de Vercel (ai) 6.0.202→6.0.217 et @anthropic-ai/sdk 0.104.1→0.104.2.
• Mise à niveau conjointe de la chaîne CSS épinglée : autoprefixer 10.4.20→10.5.2 et postcss 8.5.15→8.5.16 ; la dépendance directe et la substitution postcss à l'échelle de l'arbre ont été déplacées ensemble pour conserver une seule version de postcss.
• Aucune modification du code source — tsc --noEmit reste au vert et npm audit ne signale aucune vulnérabilité.
• Mises à niveau majeures volontairement reportées à leurs propres PR révisées : Next 16, React 19, Tailwind 4, TypeScript 6, le SDK Stripe 22, @supabase/ssr 0.12, pdfjs-dist 6 et le SDK IA v7.

Automatisation du gel légal (#435)

• Ajout d'un drapeau de gel légal sur les dossiers : les fonctions applyLegalHold / removeLegalHold dans lib/legal-hold/index.ts posent et lèvent un champ LegalHoldMeta sur l'objet LegalCase.
• Le composant LegalHoldBanner affiche une bannière d'alerte jaune dès qu'un dossier est sous gel, avec le motif, la date et l'auteur.
• Chaînes i18n bilingues EN/FR ajoutées pour tous les textes de l'interface de gel légal.
• Commentaire de migration de base de données ajouté (révision DBA requise) : colonnes legal_hold boolean et legal_hold_reason text sur la table matters.
• Tests unitaires couvrant apply/remove/guard et cas limites (rejet de motif vide, suppression idempotente).

Liste de juridictions autorisées et mécanisme d'activation/désactivation (#452)

• Ajout de lib/jurisdictions/allow-list.ts avec la constante typée JURISDICTION_ALLOW_LIST couvrant toutes les provinces et territoires canadiens, le fédéral, les États américains de lancement et la France (national), chacun portant les indicateurs enabled, phase et counselVerified.
• Ajout de l'assistant isJurisdictionEnabled(code) : consulte la liste autorisée compilée par défaut; respecte la variable d'environnement JURISDICTIONS_ENABLED (liste séparée par des virgules ou '*') comme dérogation d'exécution — aucun déploiement requis pour basculer une juridiction.
• Ajout des assistants getEnabledJurisdictions() et getJurisdictionEntry() pour lister et rechercher des entrées.
• Ajout de scripts/audit-jurisdictions.mjs : lit la liste autorisée et imprime un rapport structuré (texte ou JSON via AUDIT_FORMAT) avec des vérifications d'intégrité — codes en double, codes inconnus dans la dérogation d'environnement, violations activées-mais-non-vérifiées.
• Ajout de tests unitaires couvrant l'intégrité structurelle, le comportement d'activation/désactivation par défaut, les chemins de dérogation par variable d'environnement (y compris le caractère générique '*') et les recherches insensibles à la casse.
• Ajout de chaînes i18n bilingues EN/FR pour les libellés d'interface de la liste autorisée (panneaux d'administration, outils d'audit).

Liens profonds mobiles et liens universels (#478)

• Ajout de lib/mobile/deep-links.ts avec les assistants deepLinkPath(type, id), universalLink() et customSchemeLink() — source unique de vérité pour toutes les URL ouvertes en lien profond par l'application native.
• Ajout des fichiers de substitution public/.well-known/apple-app-site-association (AASA) et public/.well-known/assetlinks.json; les deux sont des ébauches vides prêtes à être complétées à l'enregistrement du premier build natif.
• Ajout de docs/mobile/DEEP_LINKING.md expliquant le schéma de lien profond, l'API de génération, les étapes de remplissage de l'AASA/assetlinks et la marche à suivre pour ajouter un nouveau type de lien.
• Ajout de chaînes bilingues FR/EN sous la clé mobileLinks (openInApp, copyLink, deepLinkFallback, downloadApp et une étiquette par cible de lien).
• Ajout de tests unitaires couvrant deepLinkPath, universalLink, customSchemeLink et la constante DEEP_LINK_PATH_PREFIXES.

Exploitation : auditeur de conformité AUP multi-fournisseurs (#1235)

• Ajout de scripts/aup-agent.mjs — un auditeur HTML statique autonome qui vérifie nos sites par rapport aux obligations d'utilisation de l'IA (divulgation de l'IA, révision humaine en sortie, mention « pas un avis juridique », vérification d'âge) de chaque fournisseur de modèle dans la chaîne d'appel (Anthropic, OpenAI, HuggingFace/Llama, Qwen). Rapporte ÉCHEC / NON CONFIRMÉ avec des vérifications manuelles explicites. Auto-audit de juge.ca : 0 ÉCHEC.

CI : l'analyse de sécurité cesse de signaler à tort les appels `.exec()` et les URL de l'outillage (#1242)

• Resserrement du détecteur de l'analyse de sécurité (lib/security/secret-scan.ts) : la vérification des commandes dangereuses ne correspond plus aux appels de méthode `.exec()` (méthodes RegExp/String — omniprésentes et sûres), seulement aux invocations brutes exec/execSync et au module child-process de Node. Les heuristiques de type exec et « URL externes » sont désormais ignorées pour les chemins d'outillage dev/CI (le répertoire scripts, les fichiers .mjs, les fichiers config) qui appellent légitimement git et citent des URL de fournisseurs — mais les constructions véritablement destructrices (suppression récursive de fichiers, élévation de privilèges, redirection distante vers un shell, évaluation dynamique) et la vérification des identifiants codés en dur s'appliquent toujours à chaque fichier, outillage compris. Cela élimine les derniers faux positifs qui faisaient échouer les PR livrant de l'outillage (p. ex. le planificateur de vagues de PR et l'auditeur AUP), tout en conservant la rigueur du contrôle pour le code d'exécution et les scripts.

Planificateur de vagues de PR + détecteur de collisions de version entre PR ouverts (#1246)

• Ajout d'un outil de publication consultatif (lib/release/pr-wave.ts + scripts/pr-wave.ts, npm run pr-wave) : il classe les PR ouverts par chemin de fichier (INFRA → SCHEMA → CONSUMER → RELEASE), affiche l'ordre déterministe des vagues de fusion et signale les collisions et régressions de version entre PR ouverts — l'angle mort de check:version-advances, qui ne compare chaque PR qu'à origin/main. La première exécution a révélé 5 grappes de collisions réelles et environ 18 PR périmés dont la version n'avance plus au-delà de main. Consultatif seulement ; l'application au moment de la fusion est déléguée aux vérifications requises et à la file d'attente de fusion natives de GitHub.

Taxonomie des problèmes — détention/libération fédérale (#1244)

• Ajout d'une taxonomie de problèmes en langage clair pour le système fédéral de détention et de libération conditionnelle (lib/litigation/corrections-problems.ts) : 14 groupes thématiques (griefs, cote de sécurité, transfèrements, UIS/isolement, discipline, santé, libération conditionnelle, conditions, contacts, effets, détenus autochtones art. 81/84, dossier, réinsertion, sécurité), chaque problème étant acheminé vers l'étape de recours qu'il déclenche dans le parcours de résolution « corrections ». Information générale structurée à partir de la LSCMLC et du cadre SCC/CLCC, explicitement marquée non vérifiée (verifiedAt null) — orientation seulement, à faire valider par un conseiller juridique ; le délai applicable est celui inscrit sur la décision.

CI : analyse de sécurité précise — cesser de signaler à tort les champs « key » des parcours (#1242)

• Remplacement du grep par mot brut de l'analyse de sécurité des PR autonomes (qui matchait le nom de propriété « key » et faisait échouer chaque PR touchant les parcours de résolution) par un détecteur testé dans lib/security/secret-scan.ts : il ne signale un identifiant que lorsqu'un mot-clé de secret est suivi d'une affectation et d'une valeur entre guillemets d'au moins 16 caractères, n'analyse que les lignes ajoutées et met en liste blanche les références aux variables d'environnement et aux secrets GitHub — tout en continuant de détecter les vrais secrets codés en dur, les commandes shell dangereuses et les URL externes non autorisées.

Parcours de résolution — détention/libération fédérale + déduplication du module gouvernemental (#1240)

• Ajout du parcours de résolution pour la détention fédérale et la libération conditionnelle : une nouvelle catégorie de différend « corrections » suit la filière fédérale distincte — demande à l'établissement (SCC) → grief du délinquant (palier initial puis final) → Bureau de l'enquêteur correctionnel → Commission des libérations conditionnelles + Section d'appel → contrôle judiciaire en Cour fédérale / habeas corpus — avec le piège de compétence que le parcours générique manque (le Protecteur du citoyen n'a pas compétence en milieu fédéral ; une plainte à l'ombudsman ne suspend aucun délai d'appel ni de contrôle judiciaire). Intégration du corps corrections-canada au répertoire canonique des recours gouvernementaux (lib/litigation/government-recourses.ts) et retrait du module parallèle redondant lib/litigation/government-bodies.ts introduit dans #1238.

Répertoire des recours des services gouvernementaux (#1238)

• Ajout d'une passerelle para-judiciaire : lib/litigation/government-bodies.ts associe 21 organismes publics québécois et fédéraux (RAMQ, SAQ, SAAQ, Revenu Québec, Hydro-Québec, réseau de la santé, aide sociale, Retraite Québec, municipalité, école, déontologie policière, CNESST, IVAC, ARC, AE/IRCC, pensions fédérales, aide financière aux études, PCU, détention/libération fédérale…) à leur échelle de recours précise — l'ordre exact qu'un justiciable non représenté doit épuiser avant le tribunal, avec les pièges de compétence que le parcours générique manque (le Protecteur du citoyen couvre la RAMQ/SAAQ mais pas la SAQ/Hydro ; avis municipal de 15 jours ; opposition fiscale de 90 jours). Bilingue, éditions modulables, délais d'orientation seulement.

Correctif : restauration des chaînes de dictionnaire commandCenter.migrationGaps (bloquait la compilation)

• Correction d'un échec de compilation en production : #1073 a ajouté un type requis commandCenter.migrationGaps mais ses chaînes de dictionnaire en/fr ont été perdues lors du rebase, de sorte que tsc échouait pendant next build et que chaque déploiement depuis 7.65.43 était en erreur. Restauration des chaînes migrationGaps bilingues pour que le site compile et se déploie à nouveau.

Plan de renumérotation des migrations + suivi du vérificateur d'écarts (#939)

• Ajout du document de transfert MIGRATION_RENUMBER_PLAN.md décrivant les migrations à numéro dupliqué à renuméroter, et correction du décompte de « 12 doublons » aux 7 fichiers excédentaires réels. Conservation du vérificateur d'écarts existant sur main (scripts/check-migration-gaps.mjs) et ajout d'un test de garde tolérant à la dérive.

Audit de configuration de l'authentification par courriel / lien magique (#103)

• Ajout d'un utilitaire d'audit de la configuration de l'authentification par courriel (lib/auth/email-config.ts) indiquant si l'environnement lien magique/SMTP est défini. Correction de la vérification de présence pour couper les espaces des valeurs d'environnement, de sorte que les variables ne contenant que des espaces sont correctement considérées comme non configurées.

Correctif : réparation de la structure JSON du changelog (bloquait la compilation)

• Correction d'un objet de changelog malformé dans dictionaries/en.ts et fr.ts introduit lors de l'empilement de l'entrée 7.65.40 pendant un rebase — le tableau changes et l'objet de l'entrée 7.65.40 étaient restés non fermés, cassant l'analyse TypeScript/compilation. Rétablit une structure valide pour que le site compile et se déploie.

Correctif de contraste WCAG AA — lisibilité de SafetyNotice en thème clair

• Correction des échecs de contraste WCAG 2.1 AA de la bannière de sécurité SafetyNotice sous le thème clair manuel (data-theme="light") ; le thème sombre par défaut est inchangé.
• Bannière proéminente/urgence (et la variante de page /emergency) : remplacement de text-rose-50 (#fff1f2) par text-fg afin que le texte de clause de non-responsabilité s'affiche en bleu marine foncé (#16213e) sur le fond rose clair — le contraste passe de ~1,23:1 à ~11,8:1.
• Bannière discrète (édition institutionnelle du Québec) : ajout d'une classe safety-notice-subtle avec une substitution en thème clair qui remplace la teinte dorée pâle par la surface quasi blanche standard et fonce les accents dorés (#8a6516), les faisant passer de ~1,4:1 à ~5,2:1.

Correctifs à sévérité élevée : intégrité de l'audit, course OCR, éditions perdues, couverture de tests, porte d'approbation

• Correctif (#1199) : la caviardage du journal d'audit ne supprime plus les champs médico-légaux légitimes (author/authority/signingDate) via une correspondance de préfixe trop large, et les entrées sans métadonnées ne sont plus faussement signalées comme ALTÉRÉES — les charges utiles stockées et hachées concordent désormais.
• Correctif (#1202) : l'OCR en arrière-plan utilise un compteur de génération monotone au lieu d'un drapeau d'abandon booléen, de sorte qu'un lot remplacé ne peut plus mélanger ses résultats dans un nouvel import ; le worker Tesseract est libéré à chaque abandon, et les fichiers en erreur affichent désormais un marqueur Erreur en ligne au lieu d'un faux ✓.
• Correctif (#1203) : Workspace.update() utilise une mise à jour d'état fonctionnelle et persiste la valeur validée, de sorte que des éditions concurrentes provenant de panneaux différents ne s'écrasent plus silencieusement, ni localement ni sur le serveur.
• Correctif (#1205) : la suite de tests est désormais découverte par glob (scripts/run-tests.mjs) au lieu d'une liste de fichiers maintenue à la main, de sorte que les nouvelles suites s'exécutent toujours en CI et qu'un seul mauvais chemin ne peut plus interrompre toute l'exécution.
• Correctif (#1200) : la porte d'approbation humaine lit son délai d'expiration à chaque appel (débloquant la surcharge de test) et supprime du code mort ; l'exigence d'un stockage partagé pour les rappels sans serveur est suivie en tâche de fond.

Correctif : déblocage des déploiements de production (la compilation ne meurt plus sur une base inaccessible)

• Critique (#1192) : chaque déploiement de production échouait parce que la compilation exécute d'abord scripts/apply-migrations.mjs, qui tentait d'atteindre l'endpoint Postgres direct de Supabase (IPv6 uniquement) depuis le conteneur de build de Vercel et recevait ENETUNREACH — tuant la compilation avant l'exécution de next build, de sorte que le site en ligne restait figé sur une ancienne version quoi qu'il soit fusionné. Le moteur de migration considère désormais les erreurs de connexion/réseau comme un saut propre (la compilation Next.js n'a pas besoin de la base) tout en gardant les vraies erreurs SQL fatales ; REQUIRE_MIGRATIONS=1 force la rigueur. Les déploiements de production peuvent réussir à nouveau, de sorte que les changements de version et le contenu atteignent réellement le site.

Réconciliation de version — créditer le travail fusionné non versionné

• Réconciliation de la version de la plateforme de 7.56.46 à 7.65.22. De nombreuses PR de fonctionnalités (moteur de salle d'audience, propriété cryptographique, journal d'audit, contrôles de sauvegarde/rétention/incident, paiements aux prestataires, sécurité maliciel/CSAM, système de rappels, taxonomie documentaire, registres de professions, entonnoirs de services, adaptateur EFSP, et plus) avaient été fusionnées à partir d'anciennes bases de branche en portant des numéros de version périmés ; elles n'ont donc fait avancer la version d'aucun point et leurs points de version ont été perdus. Ce bump unique crédite 876 points de version — 816 provenant de 65 fusions à version périmée, plus la migration vers la nouvelle base de données, l'intégration de la connexion Google et les fondations Paramètres et Opérations v7.0 — selon le barème lib/versioning/release-points. Source unique de vérité pour juge.ca et judge911.com ; audit complet par PR dans docs/VERSION_RECONCILIATION_7.65.md.

Note d'architecture : Paramètres et Opérations v7.0 (conception)

• Docs (#1175–#1183) : ajout d'une note d'architecture de conception uniquement (docs/architecture/settings-operations-v7-brief.md) pour Paramètres et Opérations v7.0 — modèle de capacités et lentilles de rôles, un journal d'événements d'audit en ajout-seul par-dessus le substrat à chaîne de hachage existant, espace de travail/CLUF, surfaces d'authentification, coquille des paramètres, un graphe de dépendances et les considérations Loi 25 / RLS. Aucun code de production ; l'implémentation suit après la revue de conception.

Locale espagnole pour le panneau Copilote

• i18n (#1128) : localisation en espagnol (es) des 41+ chaînes visibles du panneau Copilote et de son client, y compris les messages critiques de quota / abonnement / échec de paiement, afin que les utilisateurs es ne voient plus d'anglais. check:i18n-gap indique une parité es de 100 %.

Limitation de débit par utilisateur sur les routes d'IA

• Sécurité (#1131) : ajout d'une limitation de débit par utilisateur authentifié (20 req/min, HTTP 429 + Retry-After) sur 5 routes d'IA (traduction, chronologie, marketplace, extraction, note de recherche) qui pouvaient épuiser le budget Anthropic, en réutilisant le SlidingWindowRateLimiter existant. Clé sur l'identifiant utilisateur ; le contrôle s'exécute avant toute dépense de modèle ; la sortie de l'IA est inchangée.

Défense en profondeur : contrôle d'authentification explicite sur 7 routes d'API de litige

• Sécurité (#1122) : ajout d'un contrôle d'autorisation explicite getUser() → 401 puis can_access_matter → 403 sur 7 routes d'API de litige (vues de preuves, faits, aveux, pièces, témoins, Bates, production — 13 gestionnaires) qui ne reposaient auparavant que sur la sécurité au niveau des lignes. Défense en profondeur par-dessus la RLS — aucune politique modifiée ; les lectures non authentifiées renvoient désormais 401 au lieu d'un 200 vide.

Lot sécurité et QA : durcissement des secrets (récupération/relais), limitation de débit de l'activité, contrôle de propriété, correctifs d'accessibilité et de gestion des erreurs

• Sécurité — récupération fondateur (#1129) : le secret de récupération n'est désormais accepté que via l'en-tête x-auth-recovery-secret (plus de repli sur le corps de la requête, journalisé par les proxys/WAF), et le lien magique actif n'est plus renvoyé dans la réponse de l'API — il est plutôt envoyé par courriel.
• Sécurité — télémétrie d'activité (#1132) : POST /api/activity applique maintenant une limitation de débit par IP et n'accepte les signaux liés à un dossier que de la part d'appelants authentifiés ayant accès à ce dossier, fermant une voie d'inondation de la base de données et d'empoisonnement des analyses.
• Sécurité — relais de courriel entrant (#1130) : le secret du courriel entrant n'est plus lu depuis la chaîne de requête de l'URL (journalisée par les proxys/CDN) ; il est accepté via en-tête, authentification HTTP Basic ou corps de requête, avec une comparaison à temps constant.
• Sécurité — réclamants d'action collective (#1149) : ajout d'un contrôle d'autorisation explicite propriétaire/administrateur en plus de la sécurité au niveau des lignes avant toute lecture ou écriture des données de réclamants.
• Correctif — ChronologyGrid (#1143, #1144) : l'action « Fait prouvé par l'IA » est encadrée d'un try/finally pour que son bouton ne puisse plus rester désactivé, et les erreurs de l'IA s'affichent désormais en ligne au lieu d'échouer silencieusement.
• Correctif — JusticeHome (#1148) : les échecs d'import d'une sauvegarde JSON affichent maintenant un avis d'erreur en ligne et localisé au lieu d'une alerte alert() native du navigateur.
• Correctif — AskQuestion (#1133) : le code d'état HTTP brut, le nom du fournisseur et l'identifiant de requête ne sont plus montrés aux utilisateurs ; un message générique localisé est affiché et les détails sont journalisés dans la console.
• Accessibilité — NotificationBell (#1136) : la boîte de dialogue des notifications reçoit désormais le focus à l'ouverture, le restitue à la fermeture et se ferme avec Échap (WCAG 2.4.3).
• Accessibilité — Recours et boîte de dialogue de clôture (#1138, #1139) : les listes déroulantes d'état du recours et de résultat du dossier ont maintenant des étiquettes accessibles, et la boîte de dialogue de clôture gère le focus et se ferme avec Échap.
• Accessibilité — DocumentIntake (#1137) : les indicateurs de priorité du Copilote portent désormais une étiquette texte visible afin que la priorité ne dépende plus de la couleur seule (WCAG 1.4.1).
• Correctif — disponibilité OAuth Google (#1118) : la vérification exige maintenant le GOOGLE_CLIENT_ID côté serveur, et non plus seulement l'identifiant client public du navigateur, avant de déclarer l'intégration configurée.
• Entretien : déplacement des fichiers épars de la racine vers un dossier .attic/ ignoré par git et arrêt de la pollution de l'état git par les copies de travail jetables .claude/worktrees.
• Correctif — audit RLS (CI) : suppression des entrées fantômes `orgs`/`org_memberships` du registre des tables RLS ; les tables canoniques sont `organizations`/`organization_members` sous la migration 0084, et la migration 0092 interdit explicitement les tables `orgs` parallèles — rétablissant l'intégrité du harnais d'audit RLS.

Correctif : restauration d'un package.json valide (erreur de syntaxe JSON bloquant la compilation)

• Correctif du script « test » dans package.json : un guillemet parasite et une virgule manquante (introduits par le rebase de #1169) produisaient un JSON invalide qui faisait échouer la compilation Vercel avant même le démarrage de Next.js. Restaure un JSON analysable pour que les déploiements réussissent.

Correctifs QA : badge i18n aide juridique, paramètres statiques notaire, aperçu IA ChronologyGrid, code statut Copilot

• Correctif /marketplace/legal-aid : le badge « Recommandé » et la visibilité du suffixe /mois sont désormais adaptés à la langue — badge via prop FR/EN, détection du palier gratuit par config (tier.maxMonthlyCAD === 0) au lieu d'une comparaison de chaînes fragile.
• Correctif /marketplace/notary : ajout de generateStaticParams pour que la page soit pré-rendue à la compilation et que les chemins du plan de site soient correctement résolus.
• Correctif ChronologyGrid bouton ✨ IA Fait prouvé : la suggestion IA peuple désormais le champ pour révision avant engagement — onBlur valide lorsque l'utilisateur accepte ou modifie.
• Correctif Copilot : le chemin d'erreur « not-configured » inclut maintenant le code HTTP pour faciliter le débogage, conformément à la branche d'erreur générique.

Gabarit de contenu juridictionnel + vérification des URL de tribunal (#454, #1154)

• Ajout de lib/jurisdictions/content-scaffold.ts : interface JurisdictionContentScaffold, validateScaffold() vérifie maintenant les URL https:// des tribunaux, fabrique createEmptyScaffold().
• Ajout de scripts/generate-jurisdiction-scaffold.mjs : générateur de gabarit JSON par code ISO 3166.
• Ajout de lib/__tests__/jurisdiction-content-scaffold.test.ts : tests unitaires couvrant les règles de validation, la forme du gabarit vide et la couverture de types.
• Ajout de docs/jurisdictions/CONTENT_SCAFFOLD.md : spécification éditoriale en 5 sections.
• Ajout des chaînes i18n jurisdictions.contentScaffold (EN + FR).

ChronologyGrid : formatage des dates selon la langue

• Les dates des faits dans la grille de chronologie et la vue Juge (prête à imprimer) s'affichent désormais dans un format court adapté à la langue (ex. « 15 janv. 2024 » en français, « Jan. 15, 2024 » en anglais, « 15 ene. 2024 » en espagnol) au lieu de chaînes ISO brutes. Le champ de saisie de date utilisé lors de l'édition conserve toujours la valeur ISO requise par le sélecteur de date HTML.

Moteur de réducteur procédural pour la salle d'audience

• Ajout de lib/courtroom/types.ts — types canoniques pour la machine à états déterministe : TrialPhase (ARRAIGNMENT → BAIL_HEARING → PRELIMINARY_INQUIRY → TRIAL_PREP → TRIAL → DELIBERATION → SENTENCING), PartyRole, union CourtAction, TrialState et ReducerResult.
• Ajout de lib/courtroom/reducer.ts — fonction pure reduceTrialState() appliquant cinq règles procédurales : (1) Verrou d'objection (la parole des témoins et les dépôts de pièces sont bloqués tant qu'une objection est EN ATTENTE), (2) Pouvoirs exclusifs du juge pour statuer sur les objections, admettre ou exclure des pièces, et faire avancer les phases, (3) Pouvoirs exclusifs des avocats pour soulever des objections et déposer des pièces, (4) Portail des témoins (un témoin ne peut prendre la parole qu'en phase TRIAL et uniquement s'il est désigné activeWitnessId), (5) Portail de délibération (seuls les jurés peuvent prendre la parole durant la phase DELIBERATION).
• Ajout de lib/courtroom/__tests__/courtroom.test.ts avec 25 tests unitaires déterministes couvrant les cinq règles, la progression complète des phases, l'intégrité du journal d'audit et les cas limites.

Version v7.56.13

• Publication de la version v7.56.13.

Date de dernière activité sur les fiches de dossier

• Chaque dossier de l’accueil affiche maintenant sa date d’activité la plus récente, déduite des faits, de la création et de la clôture du dossier — pour voir d’un coup d’œil quels dossiers avancent.

Navigation mobile par section dans l’espace de travail

• Ajout d’une barre de navigation mobile au bas de l’espace de travail : les quatre sections principales (Résumé, Mes documents, Conseils, Échéances) plus un menu « Plus » pour les autres.
• Chaque section conserve sa propre position de défilement lors du changement d’onglet — fini le retour automatique en haut de la page.
• Le dossier ouvert et la section sont maintenant accessibles par lien direct via l’URL, pour reprendre exactement où vous étiez.

Correction de l'état de préparation à l'audience (Correctif #1027)

• Nouveau score d'audience spécifique (lib/litigation/hearing-readiness) : évalue les livrables concrets de préparation (date d'audience, interrogatoires, points d'argumentation, liste de vérification, pièces déposées, questions en litige, notes d'audience) en démarrant à 0 % pour un dossier vide, évitant les scores faussement élevés.
• Correction des scores par défaut dans la préparation au tribunal (lib/litigation/readiness) : les dimensions vides (procédures, échéances, pièces) obtiennent 0 % au lieu de valeurs par défaut élevées.
• Mise à jour du Copilote (components/workspace/Copilot.tsx) : la carte 5 utilise désormais le nouveau score spécifique d'audience plutôt que la préparation globale au tribunal.
• Ajout et mise à jour de tests unitaires pour valider les comportements déterministes et les nouveaux cas limites de la triade de préparation.

Centre de commande de la preuve — chronologie

• Refonte de la chronologie du dossier — dans l'onglet Chronologie comme dans le mur chronologique de préparation d'audience — sous forme de grille vérifiable : colonnes Date, Événement, Fait prouvé, Récit, Source et Statut.
• Cliquez sur la source d'une ligne pour ouvrir le document original (PDF/image) et vérifier l'entrée; les badges de statut indiquent le niveau de confiance (vérifié par un humain, corroboré par plusieurs documents, extrait par IA ou en conflit).
• Correction de la normalisation des dates : les formats ambigus (p. ex. 6/9/26 à l'américaine) sont résolus correctement et l'incertitude est signalée au lieu de fausser silencieusement l'ordre de la chronologie.
• Ajout de la détection de conflits entre sources, de filtres instantanés par enjeu/témoin et de cinq vues par rôle (Enquête, Avocat, Juge — une page/impression, Témoins, Dommages), ainsi qu'un nettoyage IA consultatif qui reformule un événement à partir de sa citation source.
• Un seul centre de commande de la chronologie partagé entre l'espace du justiciable autoreprésenté et celui de l'avocat.

Microservice d'ingestion du plan de contrôle et vérification HMAC

• Introduction d'un nouveau microservice d'ingestion sécurisé et piloté par événements sous services/control-plane-ingest pour traiter les événements de webhook Vercel.
• Implémentation de la vérification de signature HMAC-SHA1 à l'aide de tampons de corps de requête bruts pour authentifier les webhooks de manière sécurisée.
• Intégration de la logique de publication Pub/Sub pour transférer les événements vérifiés et normalisés vers Google Cloud Pub/Sub en vue de l'évaluation des règles en aval.
• Isolation de la compilation du projet Next.js principal en excluant le répertoire services dans tsconfig.

Correctif 500 du rappel d’authentification

• Correction d’une erreur HTTP 500 sur /auth/callback et /auth/confirm qui empêchait toute connexion (OAuth, lien magique et confirmation par courriel) : les gestionnaires de route côté serveur importaient l’utilitaire de redirection safeNext depuis un module « use client », ce qui levait une exception à l’exécution côté serveur.
• Déplacement des fonctions de routage pures safeNext et portalFor vers un module sûr côté serveur (lib/auth/portal-routing.ts), réexportées depuis le module client, afin que les gestionnaires de route ne franchissent plus la frontière client/serveur. Aucun changement au comportement de redirection.

Durcissement du rappel d'authentification et routes force-dynamic

• Définition des routes de rappel et confirmation d'authentification comme force-dynamic pour éviter les erreurs de rendu statique sous Next.js 15.
• Encapsulation des échanges de code/OTP et des gestionnaires de route dans des blocs try-catch pour rediriger gracieusement les utilisateurs en cas d'erreur ou d'expiration de session, au lieu d'afficher une page 500.
• Correction d'un bogue de test sensible au temps dans le suivi des échéances administratives.

Correction du chemin des liens de réinitialisation

• Les courriels de réinitialisation utilisent désormais un chemin dédié /auth/callback/reset afin que la liste blanche Supabase ne supprime plus la destination après connexion.
• La page de réinitialisation attend l'établissement de la session de récupération avant de retirer les jetons d'authentification de l'URL, et peut échanger un ?code= résiduel si le lien y atterrit directement.

Durcissement du flux de connexion

• Normalisation du courriel avant les appels Supabase afin d'éviter les échecs causés par les espaces ou la casse.
• Distinction du cas courriel non confirmé avec un message actionnable plutôt qu'un simple échec d'identifiants.
• Ajout d'une redirection de secours après connexion réussie si la lecture du profil/portail est temporairement indisponible.
• Déplacement de la validation des redirections d'authentification dans un module compatible serveur afin que les rappels courriel, lien magique et réinitialisation ne bloquent plus à la frontière serveur/client.
• Transmission des erreurs de lien expiré vers les écrans de réinitialisation et de connexion avec une consigne plus claire de demander le courriel le plus récent.

Filet de rapprochement des versements + modeles d'artefacts de mise en service

• Mise en oeuvre du sondage de rapprochement des versements Stripe Connect comme filet de securite du webhook de reglement : une annulation ou une confirmation de transfert manquee est corrigee au prochain passage (idempotent, inerte tant que les versements ne sont pas configures).
• Ajout de tests unitaires pour le sondage de rapprochement et integration des tests webhook/rapprochement des versements dans la CI.
• Ajout de modeles d'artefacts non signes (avocat / comptable / reviseur natif) pour les portes de pre-activation revue juridique, revue en langue native, posture fiscale et runbook des versements — aucun de ces brouillons ne ferme ni n'active une porte.

Controle des issues vie privee ouvertes

• Ajout d'un registre teste des issues ouvertes liees a la vie privee, reliant chaque item aux modules livres, aux criteres d'acceptation et aux portes humaines restantes.
• Ajout d'une divulgation dans les reglages pour la suppression de compte et les droits des donnees, dirigee vers le flux audite Loi 25 plutot que vers une suppression destructrice immediate.
• Formalisation des reponses App Store et Google Play sur les donnees, avec stockage canadien, absence de vente de donnees et exclusions explicites pour les declarations et approbations humaines.

Batch plateforme des 20 prochaines issues ouvertes

• Clôture des 20 prochaines issues ouvertes sans porte humaine, couvrant liquidité marketplace, conformité, mobile hors ligne, préparation des fonctionnalités riches, continuité du cycle de vie, dépôt, notifications et finition produit.
• Ajout d'un cadrage procédural tri-édition afin que les modèles québécois revus ne s'affichent pas comme procédure en direct pour le Canada hors Québec ou les États-Unis.
• Ajout d'une posture mobile hors ligne sécurisée testée et d'un registre de complétion reliant les 20 issues aux modules livrés et aux preuves d'acceptation.

Correctif de deploiement des migrations huissier

• Rendre la migration corrective des tarifs d'huissier rejouable lorsque la production a deja promu la colonne id des tarifs en cle primaire.
• Ajout d'une couverture de regression pour la promotion gardee de la cle primaire et maintien des metadonnees de release du bloqueur de deploiement en synchronisation.

Validation de handoff de release

• Ajout d'une mise a jour de release de suivi apres la revue de securite manuelle du PR autonome.
• Maintien de lib/version.ts, package.json, package-lock.json et du journal bilingue en synchronisation pour le handoff GitHub.

Batch de 25 issues fondation

• Clôture d'un nouveau batch de 25 issues ouvertes sans toucher aux portes humaines, aux validations avocat, aux paiements, au CSAM, aux lancements juridictionnels ni aux intégrations fournisseur en direct.
• Ajout d'une fondation mobile testée couvrant identité par édition, redirections d'authentification, liens profonds, capture de preuve, annotations documentaires, préparation push et portes de publication native.
• Ajout d'un registre de complétion testé reliant chaque issue sélectionnée aux modules livrés, aux critères d'acceptation et à la preuve de versionnement du batch.

Mise à jour des métadonnées de release

• Passage des métadonnées de release de la plateforme de 7.54.17 à 7.54.18.
• Maintien de lib/version.ts, package.json, package-lock.json et du journal bilingue en synchronisation.

Service tarifaire d'huissier et extension de l'estimateur

• Ajout d'un TariffRuleService côté serveur pour l'estimateur d'huissier : les lignes actives de bailiff_tariff_rules priment désormais, et le placeholder en code est utilisé seulement lorsqu'aucune ligne tarifaire active n'existe.
• Extension de l'estimateur statique au-delà de la signification vers l'exécution de jugement et l'éviction, avec provisions de temps d'exécution et de complexité dans le calcul Bas / Probable / Haut.
• Maintien des OQ-29 à OQ-32 sous validation humaine : les tarifs placeholders restent à faible confiance en attendant les intrants de tarif, taxes, distance et recouvrement maintenus par avocat.

Batch de 25 issues avec autorisation admin

• Clôture du dernier batch de 25 issues avec portes autorisées par l'admin, incluant la prédiction huissier de l'Epic 20, le routage marketplace, le retour de coûts réels, l'hygiène racine phase 1 et la preuve v3.0.
• Ajout des prédictions huissier liées au dossier, des libellés de recommandation non-conseil, des disclaimers obligatoires d'export, de la variance coûts réels et des benchmarks régionaux.
• Inscription des décisions OQ-29 à OQ-32 comme autorisées par l'admin, tout en conservant l'approbation humaine pour la dispatch et les libellés faible confiance jusqu'à maturité des données revues.

Clôture audit WCAG

• Inscription de l'audit WCAG 2.2 AA du Command Center pour la tâche #631 avec calculs de contraste, câblage ARIA des onglets et preuve de revue.
• Ajout d'un registre de complétion accessibilité testé prouvant que l'audit correspond à des modules, tests et invariants concrets.
• Documentation de la posture de revue manuelle par onglet pour Command, juridictions, impact, éditions, surfaces, sous-systèmes et DevOps.

Clôture fondations Command Center

• Inscription du fil des changements, du donut de préparation par édition, de la matrice de préparation et du diagnostic du tunnel pour les tâches #649, #650 et #652.
• Ajout d'un registre de complétion Command Center testé prouvant que chaque tâche correspond à des modules livrés, des tests vérifiables et des invariants opérateur.
• Maintien d'un Command Center déterministe : ordre du fil stable, calculs de préparation finis et correctifs de tunnel reliés à des libellés mesurables.

Clôture fondations d'actionnement

• Inscription du runner gouverné, du workflow de décision des propositions et du seuil de confiance avec escalade pour les tâches #670, #672 et #679.
• Ajout d'un registre de complétion testé prouvant que chaque tâche fondation correspond à des modules livrés, des tests vérifiables et des invariants de contrôle humain.
• Maintien de l'actionnement en mode désactivé par défaut : le runner ouvre seulement des pull requests, les tâches à validation humaine sont sautées et le raisonnement à faible confiance est escaladé avant tout effet externe.

Complétion cognition du brain

• Inscription du brain en lecture seule déjà livré, des playbooks de raisonnement, des briefs CEO/CTO/CFO, du détecteur d'anomalies et de la file de saillance pour les tâches #665 à #669.
• Ajout d'un registre de complétion vérifié par test prouvant que chaque tâche correspond à un module livré et à au moins deux points de preuve vérifiables.
• Maintien du brain en posture consultative : lectures monde/mémoire, ajout brain_log, audit de gouvernance et lecture de la file fondateur restent les seules surfaces approuvées.

Liaisons d'intégrations en lecture

• Ajout de lecteurs GitHub et Vercel en lecture seule pour la branche de production, l'état du commit et les projets de déploiement liés.
• Ajout des cartes de revenus Stripe par client injecté, agrégeant brut, net, frais et nombre de transactions par devise sans mouvement d'argent.
• Ajout de la normalisation Vercel Analytics par édition et surface avec lectures liées aux projets, état de préparation fournisseur et couverture mock complète.

Décisions propriétaire de gouvernance

• Résolution des OQ-13 à OQ-22 sous forme de décisions propriétaire typées couvrant repo/Vercel, poids d'impact, responsabilité du mémo éthique, portée Judge911, analytique, appétit au risque, voies d'approbation et plafond d'autonomie.
• Ajout d'une couverture de régression prouvant que les questions ouvertes du plan maître sont répondues tout en conservant l'approbation obligatoire pour les actions à conséquence et le blocage de l'actionnement phase_3 par le plafond courant.
• Documentation du registre de décisions de gouvernance du 2026-06-22 sans affaiblir l'interrupteur d'urgence, le cliquet, les approbations ou les seuils de confiance existants.

Fondations cycle de vie

• Fermeture du premier batch fondation avec câblage éditionnel des parcours de résolution, des échéances manuelles et de la rétention d'archive afin qu'un dossier non Québec n'affiche plus de contenu Québec non revu.
• Ajout du moteur de cascade du cycle de vie : propositions d'échéances confirmables pour la signification et le jugement, panneau des préconditions bloquantes, registre d'audit lifecycleAudit et confirmation humaine obligatoire avant toute inscription d'échéance.

Réconciliation des PR brouillons

• Réconciliation des PR brouillons approuvés restants après le batch de 23 PR, en conservant le train de release production courant.
• Publication des voies de partenariat pour professionnels du droit, institutions de justice, milieux universitaires, OBNL, plateformes technologiques, entreprises et partenaires financiers.
• Fermeture des anciens travaux brouillons sitemap/thème comme déjà supplantés par l'implémentation actuelle de main, sans réintroduire leur ancien état de layout et de changelog.

Batch de 23 PR et 10 issues fermées

• Intégration groupée des 23 PR restants prêts à fusionner, avec résolution centralisée des conflits de version et de registre.
• Clôture des 10 issues ouvertes sélectionnées (#502, #500, #493, #451, #445, #443, #442, #440, #436, #433) via leurs correctifs complets déjà préparés en PR.
• Ajout des surfaces de résilience opérations, paiements, notifications, filing EFSP, marketplace, sécurité documentaire et garde-fous de contenu dans une seule release traçable.

Correctif du paquet de déploiement Vercel

• Ancrage des règles .vercelignore aux dossiers racine afin d'exclure les gros artefacts locaux sans retirer lib/docs du build Next.js.
• Rétablissement de la compilation production après l'échec Module not found sur les modèles de documents importés par l'espace de travail.

Train de 82 PR et tarification résolution

• Fermeture de 82 PR approuvés du train de release et application du rattrapage de +820 points, de 7.40.56 à 7.48.76.
• Repositionnement de la page Tarifs autour de Preuve des démarches™ : 50 problèmes gratuits, puis tarification par problème et crédits prépayés.
• Ajout des lots de crédits, de l'échelle d'escalade Problème → Cour, des paliers publics mis à jour, des attentes de tests pricing/persona et de l'entrée RLS manquante pour filing_submissions.

Fondation d'estimation des coûts d'huissier

• Ajout de la planification Epic 20 et de la spec §35 sur la prédiction des frais d'huissier comme fondation contrôlée des estimations opérationnelles de coûts de signification.
• Ajout d'une table tarifaire d'huissier sous barrière et d'une logique déterministe Bas / Probable / Haut avec lignes pour service de base, tentatives, déplacement, provision hors heures, frais de tiers et provision taxes.
• Ajout du panneau d'estimation manuelle au formulaire de signification sans changer le montant facturé aujourd'hui ni le flux d'assignation.

Durcissement du build Vercel release-global

• Réduction de la concurrence de build Next.js et de génération statique sur les builders Vercel afin que le déploiement release-global complète dans le conteneur standard de 8 Go.
• Conservation du comportement de développement local et des builds hors Vercel, tout en gardant les fonctions brain et attention dans un périmètre consultatif en lecture seule.
• Documentation de l'échec de déploiement du PR #847 comme un OOM de build Vercel, et non comme une erreur d'exécution du brain ou d'autorisation du cron.

Désabonnement des rappels et liste de suppression

• Ajout d'un point d'accès de désabonnement en un clic pour les rappels par courriel et SMS, validé par jetons signés et relié à une liste de suppression persistante.
• Connexion de la couche de livraison à cette liste afin qu'un rappel supprimé soit journalisé sans appeler le fournisseur courriel/SMS.
• Ajout d'une migration RLS en refus par défaut et de tests de régression couvrant le blocage avant envoi et les liens de désabonnement signés.

Alertes d'échéances proactives

• Remplacement de la courte cadence de rappel des échéances par l'escalade proactive 90/60/30/14/7/3/1 jours requise par l'EPIC 17.
• Conservation des rappels d'audience et de rendez-vous sur leurs cadences opérationnelles existantes, sans fuite entre éditions ni conseil juridique automatisé.
• Ajout d'une couverture de régression pour la fenêtre d'envoi, la livraison multi-canaux courriel/SMS, les clés d'idempotence par canal et le strip rouge des échéances en retard.

Couche d'actions par connecteur, banc d'essai d'isolation et contrôles d'attention

• Ajout d'une couche d'actions par connecteur gouvernée, en mode désactivé par défaut : chaque action doit franchir le registre d'actions, l'inhibiteur EJN/Loi 25, la barrière de gouvernance et un consentement explicite d'exécuteur avant tout effet — et le registre livré n'active aucun exécuteur.
• Renforcement de la barrière d'actionnement afin qu'elle refuse toute requête sous une phase de maturité actionnable, garantissant que le plafond par défaut demeure à zéro exécution.
• Ajout d'un banc d'essai de sécurité au niveau des lignes (RLS) qui verrouille l'isolation inter-locataires des dossiers comme test de non-régression continu.
• Ajout d'un filtre par axe d'attention et d'un suivi de conformité et de blocages aux panneaux d'opérateur du Centre de commande.

Opérations gouvernées, délais, garde-fous et apprentissage

• Ajout de la couche d'actuation gouvernée en mode désactivé par défaut : le runner ouvre des PR seulement après plafond de phase, ratchet, coupe-circuit, confiance et approbation humaine.
• Ajout du flux proposition puis approbation pour les actions d'administration, avec journal d'audit et nouvelle surface d'approbation avant toute mise en oeuvre.
• Ajout du registre d'accès fondateur Law 25/PIPEDA pour tracer les lectures transversales de dossiers, avec journal immuable et lecture réservée au rôle founder_admin.
• Ajout des onglets Command Center pour éditions, surfaces, sous-systèmes, DevOps, préparation et panneaux opérateur, avec routes d'administration et couverture de régression.
• Ajout de la couche d'inhibition dure UPL/Law 25 et de la porte d'évaluation UPL adversariale afin qu'une sortie du cerveau bloquée ne soit pas persistée et que les sondes de conseil non sécuritaires restent fail-closed.
• Ajout de la couche d'apprentissage par récompense consultative qui note les résultats selon des objectifs typés et émet des signaux d'affinement bornés et auditables sous le ratchet de gouvernance.
• Ajout de la présentation des délais sécurisée contre l'UPL et d'un cadre de délais multi-juridictions, avec couverture de régression pour les packs de juridiction et la présentation.
• Correction de l'ingestion des vues de surface analytics pour que les pages publiques instrumentées ne produisent plus d'erreur 400 côté navigateur.
• Correction de l'inférence des catégories du journal afin que les portes d'entrée par problème et les registres de gouvernance ne soient plus classés comme des déploiements de juridictions.

Porte de migration obligatoire avant build

• Le script build échoue maintenant bruyamment si l'application des migrations échoue, afin d'éviter un déploiement avec un schéma manquant ou partiel.
• La vérification RLS demeure consultative pendant le build : elle signale les écarts sans masquer l'échec obligatoire des migrations.
• Alignement de la version, du lockfile et du journal bilingue pour tracer ce durcissement CI comme une release distincte.

Portes d'entrée par problème juridique selon l'édition

• Ajout des routes publiques /problems et /problems/[slug] pour rendre les groupes d'entrée, les pages de catégorie et les parcours guidés selon l'édition active.
• Ajout de taxonomies de problèmes consommateurs pour les États-Unis, le Québec et le global, avec libellés localisés, résumés, étapes de parcours, résolution de route et couverture d'unicité des slugs.
• Branchement de la page d'accueil Québec sur des cartes de problèmes juridiques en français d'abord, tandis que Judge911 obtient une section guidée pour les problèmes américains.

Cycle de vie partagé des espaces professionnels

• Ajout de la fondation partagée des espaces professionnels : bibliothèque de modules commune, sélecteur de contexte par portée invitée, porte de disponibilité et cycle de vie d'affectation fermé unique pour les espaces de rôle.
• Ajout d'enregistrements d'audit d'affectation chaînés par hash, d'un traitement idempotent accept/decline/revoke, de la révocation immédiate et d'un accès aux modules default-deny pour les portées invitées.
• Ajout d'aides d'échéances stockage UTC/rendu local et d'une couverture de régression pour les transitions, la portée, le chaînage d'audit, la disponibilité, la révocation et le comportement des échéances.

Registre canonique des portes humaines

• Ajout du registre typé des portes humaines pour les surfaces jamais automatiques : écritures CRM, activation de surfaces réglementées, changements au plancher A2J gratuit, canaris/break-glass de sécurité et bumps spec/version.
• Ajout d'aides pures qui classent les sujets soumis à porte et exigent un GovernanceApproval explicitement approved, avec approbateur et horodatage, avant de lever une porte.
• Documentation des catégories de portes, de la convention de handoff et des tests de registre afin qu'un enjeu human-gate ne puisse pas passer à Done par travail autonome seul.

Canaris d'exclusion opérateur dans l'IC

• Ajout d'un harnais de canaris d'exclusion opérateur qui exerce le déverrouillage conditionné au consentement, le comportement fail-closed de commit d'audit et les portes d'attestation matérielle avant toute libération de texte protégé.
• Ajout de tests de contrôle négatif et de méta-canari pour G46, G102, G104 et G107 afin que les fournisseurs qui affaiblissent le mur fassent échouer la suite.
• Ajout d'une étape IC dédiée et d'un script npm pour exécuter ces canaris en continu sur les pull requests et les pushes, sans secrets.

Export d'ancrages de chaîne d'audit

• Ajout de l'ancrage de chaîne d'audit : lecture d'une chaîne locataire, vérification complète, calcul de la racine Merkle et du hash de tête, signature d'un ancrage notarial indépendant et persistance dans audit_chain_anchors.
• Ajout de l'export de proof bundles hors ligne pour les enregistrements d'audit afin que des tiers puissent vérifier l'intégrité d'un enregistrement avec seulement l'ancrage signé et le secret notarial.
• Ajout d'une couverture de régression pour les lectures ordonnées par séquence, la persistance d'ancrage signé, le refus des chaînes vides ou brisées, la vérification hors ligne, l'échec en cas de falsification et l'absence d'ancrage.

Noyau break-glass à quorum

• Ajout du noyau de décision G48 break-glass pour le seul chemin opérateur sans consentement vers un objet protégé, avec liaison objet/portée et métadonnée d'indicateur propriétaire.
• Application d'approbateurs distincts sécurité, juridique et exécutif, avec refus single-operator, fenêtres temporelles plafonnées par politique et autorisation fail-closed.
• Ajout des constructeurs et enregistreurs d'événements d'audit trigger/release vers la chaîne d'audit inviolable, avec tests déterministes pour le quorum, l'expiration, la portée objet et les pistes d'audit vérifiables.

Surface produit pour recours collectifs

• Ajout d'une console privée /app/class-actions pour créer des recours collectifs, consulter les sommaires des membres, exécuter les distributions de règlement et envoyer les avis à la classe.
• Ajout de routes API pour la gestion propriétaire, l'adhésion/retrait des membres, les décisions d'admissibilité, les distributions prorata persistées et les avis de masse via SMTP avec dégradation sûre lorsque le courriel n'est pas configuré.
• Extension du moteur de recours collectifs avec persistDistribution(), qui upsert les claimant_distributions de façon idempotente et passe le recours à distributing, avec couverture de régression pour le contrat de persistance.

Substrat de signature électronique Adobe Sign

• Ajout de la migration 0086 pour esign_agreements et esign_recipients, avec une portée limitée aux dossiers, documents et commandes de service.
• Ajout du modèle pur d'accords pour les demandes de signature d'assermentation et de trousses de procédure, la normalisation des statuts Adobe, les chemins de stockage des documents signés et certificats d'audit, et le mappage vers l'activité du dossier.
• Ajout du façonnage de requêtes Adobe Sign derrière variables d'environnement et de tests RLS/persistance service-role-only afin que les utilisateurs ne puissent pas forger les statuts de signature ou références d'audit.

Moteur de sessions vidéo pour assermentation

• Ajout de la migration 0085 avec les tables video_sessions et video_session_participants reliées aux dossiers, commandes d'assermentation et commandes de service.
• Ajout d'un moteur typé de cycle de vie vidéo : planification, entrée en session, vérification des participants, présence, contrôle de l'enregistrement selon les règles RON et clôture/cancelation auditée.
• Séparation des droits de lecture et de gestion dans les RPC afin que les participants ou lecteurs review ne puissent pas démarrer, annuler, compléter ou activer l'enregistrement sans rôle autorisé.

Route IA de note de recherche

• Ajout de POST /api/ai/research-memo pour faire passer l'assembleur déterministe §29.9 par runAiRequest avec contrôle de capacité, portée dossier et audit fail-closed.
• Ajout d'un rendu texte déterministe de la note de recherche, avec bannière advisory, questions, analyse par proposition, autorités citées et lacunes de recherche.
• Ajout de tests de forme sans réseau pour le rendu, la localisation et le mappage des résultats de l'orchestrateur, plus l'inscription du test dans npm test.

Échafaudage TPR Québec

• Ajout d'un module pur lib/taxonomy/tpr.ts pour la Taxonomie Professionnelle de Référence Québec, avec les types TprCode/TprEntry et les fonctions tprByCode, allTprCodes et isTprCode.
• Publication seulement des quatre codes déjà nommés dans la spécification comme contenu provisoire counsel-pending, sans câblage aux prestataires, au moteur de correspondance ou aux décisions de portée.
• Ajout de tests d'intégrité pour les codes uniques, les libellés bilingues, les parents résolus et le statut counsel-pending afin que la taxonomie confirmée par conseil puisse remplacer le contenu provisoire sans changer l'API.

Fondation organisations et partage inter-cabinets

• Ajout de la migration 0084 avec les entités organisations, membres d'organisation et partages de dossier entre organisations pour modéliser les cabinets et équipes juridiques.
• Connexion du partage inter-cabinets au prédicat RLS can_access_matter_via_org, limité aux membres actifs d'une organisation, aux partages acceptés, non expirés, pleine portée et aux dossiers non archivés.
• Préservation explicite des bras d'accès existants propriétaire, matter_access, partage review pleine portée et fondateur/admin, avec un test structurel couvrant le numéro de migration, l'accès live-only et l'acceptation auditée.

Fondation Portefeuilles et litiges pré-dossier

• Ajout de la migration 0083 qui introduit les portefeuilles, les litiges pré-dossier et le rattachement optionnel des dossiers à un portefeuille.
• Ajout d'une conversion atomique dispute→matter qui préserve le litige d'origine, conserve le propriétaire, relie le dossier créé et inscrit l'audit ainsi que l'activité immuable du dossier.
• Ajout d'un wrapper serveur typé et d'un test structurel de migration couvrant le numéro de migration, les politiques RLS propriétaire et les invariants de conversion.

Chronologie générée depuis l'activité du dossier

• Connexion de la chronologie de litige au flux immuable matter_activity afin de fusionner les faits saisis avec les événements système de consultation, téléchargement, partage et autres actions d'objet.
• Ajout d'une provenance fact/activity aux éléments de chronologie et exclusion des événements système de la détection de contradictions entre faits allégués.
• Mise à jour du panneau des outils de litige avec les compteurs faits, événements et contradictions, ainsi qu'un badge auto pour les événements générés automatiquement.

Inventaire gouverné des promesses marketing

• Ajout d'un registre typé des promesses marketing à réaligner, couvrant la chronologie automatique, les types de documents illimités, les fonctions présentées comme disponibles aujourd'hui et les messages de stratégie/prédiction.
• Ajout d'un inventaire lisible dans la documentation et d'un détecteur inertiel qui pourra alimenter une future garde CI sans bloquer les copies actuelles avant validation produit et juridique.
• Ajout de tests qui verrouillent la forme du registre, les familles de promesses, le caractère juridique des mentions stratégie/prédiction et l'absence d'exceptions approuvées à ce stade.

Plan des modèles de procédure multi-éditions

• Ajout du plan #587 pour remplacer les modèles de procédure québécois appliqués à toutes les éditions par des profils de procédure conscients de l'édition et de la juridiction.
• Définition d'un premier incrément sans changement fonctionnel qui conserve le profil Québec tel quel et introduit un état indisponible pour les éditions sans contenu révisé par les juristes.
• Identification des décisions humaines et juridiques nécessaires avant d'activer des profils de procédure non québécois.

Séquence de fermeture des écarts v2.3/v2.5

• Ajout d'un plan directeur pour l'épic #590 qui groupe les écarts Master Spec par fondations, hiérarchie, moteurs manquants, surface IA, produits multi-éditions et durcissement.
• Définition d'une séquence de livraison qui commence par le substrat événementiel et d'accès, puis enchaîne la hiérarchie Portfolio/Dispute, les moteurs vidéo et signature, l'IA gouvernée, les surfaces produit et le durcissement.
• Mise à jour du premier incrément sûr pour tenir compte de la ligne de migrations actuelle et réserver les migrations 0083 et suivantes aux travaux additifs de l'épic.

Archivage récupérable des dossiers

• Ajout de la migration 0082 qui introduit les colonnes deleted_at/deleted_by sur les dossiers et des RPC archive_matter/restore_matter pour remplacer le retrait utilisateur par un archivage récupérable.
• Mise à jour des aides RLS afin que les dossiers archivés disparaissent des vues normales tout en préservant, pour les dossiers actifs, les accès propriétaire, collaborateur, partage de revue complet et fondateur/admin en lecture seule.
• Ajout d'un test structurel de migration et d'un plan durci qui nomme les tables enfants protégées et l'ancrage attendu dans la chaîne d'audit existante.

Liste d'autorisation des agents IA

• Ajout d'une porte d'orchestration IA qui refuse par défaut tout agent inconnu avant l'appel au modèle et consigne le refus dans la chaîne d'audit inviolable.
• Mappage explicite des capacités IA vers les actions autorisées du registre d'agents afin qu'une surface ne puisse demander que les capacités prévues pour son agent.
• Ajout de tests couvrant les agents inconnus, les capacités non autorisées, les alias des surfaces en production et l'option de test explicite pour contourner la liste d'autorisation.

Épine dorsale cognition et attention en lecture seule

• Ajout du service brain en lecture seule qui assemble les signaux de salience, anomalies, projections, mémoire et gouvernance en brief exécutif consultatif sans exécuter d'action autonome.
• Ajout des routes admin et cron protégées pour produire des instantanés de cognition et d'attention, avec journalisation brain_log et adaptateur Supabase cloisonné par locataire.
• Ajout d'une suite de tests couvrant les anomalies, les playbooks, les limites de capacité, les refus de gouvernance et le fait que cette couche demeure consultative par défaut.

Preuve RLS fondateur lecture seule

• Ajout d'une migration RLS qui donne aux rôles admin et founder_admin une lecture transversale des dossiers tout en gardant les écritures strictement limitées aux propriétaires et collaborateurs autorisés.
• Ajout d'un modèle exécutable des politiques RLS et d'une suite de preuve couvrant l'isolement entre locataires, les partages complets et partiels, les partages expirés ou révoqués, et les appels non authentifiés.
• Renforcement des portes d'insertion qui réutilisaient can_access_matter afin qu'un fondateur puisse auditer les dossiers sans insérer de commentaires, documents ou éléments de preuve dans le dossier d'un client.

Garde-fous UPL du copilote de litige

• Ajout d'un écran pré-modèle qui redirige les demandes d'avis juridique vers une réponse informationnelle validée, sans appeler le modèle, afin que le copilote ne réponde pas aux questions du type « devrais-je poursuivre » ou « vais-je gagner ».
• Ajout d'un écran post-sortie qui bloque toute réponse directive ou prédictive restante, consigne l'événement dans la chaîne d'audit inviolable et ajoute une mise en garde UPL propre à la juridiction à chaque réponse livrée.
• Ajout d'une suite de tests adversariaux pour les entrées et sorties en français, anglais et espagnol afin de maintenir une fuite d'avis juridique à zéro tout en laissant passer les demandes légitimes d'organisation du dossier.

Plans d'épic pour le parcours fondateur accéléré et le nettoyage des utilisateurs

• Ajout du plan d'épic pour le parcours fondateur accéléré, avec une carte vérifiée de ce qui est bâti et de ce qui reste à faire, des portes explicites pour la résidence des données, les rappels et les sauvegardes, et un périmètre étroit réservé au fondateur qui ne signifie pas une préparation au lancement public.
• Ajout du plan d'épic pour l'effacement d'utilisateurs et l'export HubSpot, avec un inventaire et une classification en lecture seule, des portes pour toute suppression destructive ou export de renseignements personnels, et des exigences Loi 25 de consentement et de sauvegarde avant toute action.
• Mise à jour des deux plans afin d'éviter les anciennes hypothèses de numéros de migration et de s'aligner sur le flux de migrations actuel de main avant tout futur travail additif.

Plans d'épic pour la bêta avocat et la sauvegarde/restauration

• Ajout du plan d'épic pour la bêta avocat de phase 1, avec une carte honnête de ce qui est déjà bâti et de ce qui reste à faire, les vrais écarts M4 plaidoyers/portage UI/conformité, et des portes humaines/conseil avant toute ouverture bêta.
• Ajout du plan d'épic pour les sauvegardes automatisées et la restauration testée, avec un périmètre de test de restauration gardé, des portes humaines pour la région canadienne/PITR, et aucun changement de comportement ni bascule de porte en production.
• Mise à jour des deux plans afin de réserver les numéros de migration seulement au moment de l'implémentation, évitant les anciennes hypothèses 0075 pendant que le flux de migrations actif de Claude continue sur main.

Noyau de gouvernance + mémoire épisodique + onglet juridictions + analytique des surfaces — vague 3 v3.0 (5 PR)

• Politique HITL + portes d'approbation à fermeture sécurisée (lib/governance/policy, TÂCHE-14.2, #821) : taxonomie des actions à conséquences — argent, dossiers, juridique, communications, temps réel — avec un modèle d'exécution à fermeture sécurisée qui bloque chaque action dans ces catégories jusqu'à ce qu'un enregistrement d'approbation explicite soit écrit dans la chaîne d'audit inviolable de la TÂCHE-14.1. Chaque décision est auditée, qu'elle soit approuvée, refusée ou expirée. 14 tests. Complète la couche préfrontale de gouvernance EPIC 14.
• Interrupteur d'urgence + cliquet de capacités (lib/governance/ratchet, TÂCHE-14.3, #822) : arrêt global qui interrompt immédiatement toute action autonome, plus un escalier de phases (phase_0–phase_4) qui impose que l'autonomie ≤ gouvernance à chaque niveau — la plateforme ne peut pas débloquer une phase d'autonomie supérieure tant que la porte de gouvernance correspondante n'est pas certifiée. Le plafond par défaut est phase_0. 21 tests. Avec #821 et #767, l'EPIC 14 (noyau de gouvernance préfrontal) est maintenant complet.
• Mémoire épisodique (lib/memory/episodic, TÂCHE-9.1, #823) : chronologie unifiée en ajout seulement et interrogeable qui fusionne event_bus, audit_chain et matter_activity en un seul enregistrement épisodique cohérent — tout composant peut demander « qu'est-il arrivé, dans l'ordre, toutes sources confondues » sans joindre trois tables manuellement. La migration 0076 ajoute la table episodic_memory avec une RLS en ajout seulement. 25 tests. Première livraison de l'EPIC 9 (mémoire). (Remarque : #823 sera fusionné sous peu; cette entrée le couvre à son arrivée.)
• Onglet Juridictions dans la console de commande (TÂCHE-2.2, #824) : les regroupements par région et la matrice de préparation affichent l'état de couverture par juridiction en un coup d'œil; un tiroir d'édition admin adossé à une route d'écriture réservée à l'admin met à jour la configuration des juridictions et consigne chaque modification dans la chaîne d'audit de gouvernance. 10 tests. (Remarque : #824 sera fusionné sous peu; cette entrée le couvre à son arrivée.)
• Événements d'engagement sur les surfaces (lib/analytics, TÂCHE-4.3, #831) : des événements de vue étiquetés sur 7 surfaces publiques (accueil, à propos, centre de recherche, marché, tarifs, avocats, juridictions) alimentent la couche d'instrumentation de l'entonnoir afin que le fondateur puisse voir quelles pages génèrent des conversions sans qu'aucune donnée personnelle brute ne quitte le serveur. 36 tests. (Remarque : #831 sera fusionné sous peu; cette entrée le couvre à son arrivée.)

Bus d'ingestion d'événements + vue d'attention fondateur — vague 2 v3.0 (2 PR)

• Bus d'ingestion d'événements (lib/events, TÂCHE-8.1, #791) : les webhooks Stripe, GitHub, Vercel, Supabase et HubSpot sont désormais normalisés en un format d'événement rejouable unique — {source, type, charge utile, ts} — avec des clés d'idempotence afin que les livraisons en double soient supprimées sans risque. La migration 0074 ajoute la table event_bus avec une RLS en ajout seulement (lecture admin, écriture par service). 29 tests. Il s'agit de la couche d'infrastructure de perception sur laquelle s'appuie la console de commande opérateur.
• Vue « Quoi d'urgent pour moi? » du fondateur (TÂCHE-15.1, #795) : l'onglet par défaut de la console de commande affiche désormais une surface d'attention active construite depuis l'agrégateur selectCommandSignals — délais dépassés, lignes signalées à l'attention et sous-systèmes défaillants remontent par ordre de priorité, avec un état vide « Tout est bon » lorsqu'aucune action n'est requise. 7 tests. (Remarque : #795 sera fusionné sous peu; cette entrée le couvre à son arrivée.)

Infrastructure opérationnelle de la plateforme — vague 1 du Plan directeur v3.0 (14 PR)

• Colonne vertébrale du schéma opérationnel : tables d'éditions, de juridictions, de surfaces, de sous-systèmes et de métriques avec sécurité au niveau ligne complète — le socle persistant sur lequel s'appuie le graphe de tâches v3.0 (TÂCHE-1.1, #705).
• Importateur de données d'amorçage opérationnel : données de base reproductibles pour toutes les éditions et juridictions, permettant à la plateforme de démarrer dans un état connu sur tout déploiement vierge (TÂCHE-1.2, #726).
• Console de commande fondateur : tableau de bord à onglets avec jetons de préparation et d'attention donnant au fondateur une vue unifiée sur la santé de la plateforme, les portes ouvertes et les actions humaines requises (TÂCHE-2.1, #749).
• Éventail d'état de santé des sous-systèmes (/api/health) : chaque sous-système de la plateforme rapporte son propre état; le point de terminaison agrège ces rapports en un signal de préparation structuré pour la surveillance et les vérifications Vercel (TÂCHE-3.1, #771).
• Taxonomie d'événements analytiques typée et consciente de l'édition : chaque événement clé du produit (accueil, inscription, premier dossier, surface de travail, intention de marché, soutien) porte l'édition, la surface et des propriétés catégorielles obligatoires; les propriétés ressemblant à des données personnelles sont rejetées au niveau du schéma afin que la télémétrie reste minimale et non sensible (TÂCHE-4.1, #712).
• Instrumentation de l'entonnoir de bout en bout : l'entonnoir de conversion accueil→compte→inscription→premier-dossier est maintenant câblé avec des événements typés et agrégé côté serveur afin que le fondateur puisse voir où les utilisateurs abandonnent sans qu'aucune donnée personnelle brute ne quitte le serveur (TÂCHE-4.2, #780).
• Points de terminaison des droits des personnes concernées (Loi 25) : les routes d'accès, de suppression, de rétention et de signalement des atteintes satisfont aux obligations de la loi québécoise sur la protection des renseignements personnels — l'accès retourne un export structuré, la suppression est conditionnée à la clôture du dossier, et la journalisation des atteintes est en ajout seulement et auditable (TÂCHE-5.2, #750).
• Analyse à l'envoi et sécurité CSAM (échec fermé) : chaque fichier téléversé est analysé avant d'être stocké; la détection CSAM échoue fermée — le fichier est mis en quarantaine et un rapport auditable est écrit avant toute opération de stockage (TÂCHE-5.5, #730).
• Lien des pièces orphelines : les pièces téléversées mais jamais attachées à un dossier sont détectées et exposées pour que le fondateur puisse résoudre les preuves en suspens avant qu'elles ne créent une lacune dans la chaîne de possession (TÂCHE-6.3, #725).
• Alerte rouge fondateur sur les délais dépassés : les délais passés sans résolution sont promus en jeton d'attention rouge sur le tableau de bord de la console afin que le fondateur ne puisse pas les manquer lors d'une session de révision (TÂCHE-6.1, #737).
• Registre canonique des métriques : les définitions de métriques à l'échelle de la plateforme résident dans un registre typé unique — aucune chaîne de métrique ad hoc, des dimensions cohérentes et un contrat stable pour le pipeline analytique (TÂCHE-6.5, #765).
• Journal d'audit de gouvernance (TÂCHE-14.1, #767) : journal immuable en ajout seulement de chaque décision de gouvernance et action d'opérateur; appliqué au niveau du schéma afin que les entrées ne puissent être mises à jour ni supprimées.
• Ensemble de règles de prescription du CcQ (Québec) : les délais de prescription du Code civil du Québec sont modélisés comme données structurées versionnées avec un lecteur typé — la source faisant autorité pour toute logique de calcul de délai dans l'édition QC (TÂCHE-17.1, #738).
• Calculateur de délai de prescription : dérive le délai de prescription à partir de l'ensemble de règles CcQ en fonction du type de dossier et de la date de départ, le surface dans la chronologie de l'espace de travail et signale les dossiers en retard (TÂCHE-17.2, #778).
• Correction du rebond à 100 % sur /fr/connexion : le portail d'authentification de l'édition française a été durci pour intercepter les échecs de getSession et se replier sur une sentinelle INITIAL_SESSION, éliminant le spinner bloqué qui causait un rebond de 100 % sur /fr/connexion (#716).

File d'actions opérateur avec séparation agent/humain

• Ajout d'un plan suivi pour les éléments bloqués par l'opérateur : accès Supabase, opérations destructives, Stripe Connect, monétisation avocat, courriels/SMS, sécurité CSAM, analyse antivirus, import Google Drive et paiements de services sur devis. Le document distingue ce qui est déjà réalisable par agent de ce qui exige une décision humaine, des identifiants ou une validation juridique; aucun drapeau de production n'est activé.

Plan du connecteur EFSP réel pour les dépôts judiciaires

• Ajout d'un plan de mise en oeuvre pour remplacer l'état 501 du dépôt judiciaire par un adaptateur EFSP réel : choix du fournisseur, mappage des enveloppes, validation des documents, suivi de statut, erreurs structurées, idempotence et audit. Le plan reste derrière les décisions humaines et les identifiants fournisseur; aucun drapeau de dépôt en direct n'est activé.

Taxonomie analytique sûre pour les événements produit

• Ajout d'un contrat analytique typé et sans fournisseur : les événements clés (accueil, inscription, premier dossier, surface de travail, intention de marché et soutien) portent maintenant l'édition, la surface et des propriétés catégorielles obligatoires. Les propriétés qui ressemblent à du contenu de dossier, de preuve, de document, de message ou de données personnelles sont refusées afin que la télémétrie reste minimale et non sensible.

La chronologie du dossier affiche désormais l'activité réelle (§17)

• L'activité enregistrée de votre dossier — téléchargements de documents, productions assemblées, et davantage à mesure que les points d'émission se branchent — apparaît désormais comme un flux « Activité récente » dans la chronologie de litige, lu de façon sécurisée afin que vous ne voyiez que l'activité des dossiers auxquels vous avez accès. La piste d'audit n'est plus seulement capturée; elle est visible.

La chronologie auditable s'active — premiers vrais événements d'accès (§15/§17)

• Le flux d'activité du dossier capture désormais de vrais événements : chaque téléchargement de preuve est journalisé, et l'assemblage d'une production de documents (ensemble de divulgation) enregistre un événement de chaîne de possession. Les événements d'accès ne sont enregistrés qu'après que le serveur a revérifié votre accès au dossier — le journal ne reflète donc que l'activité autorisée — et les jalons substantiels (jugements, audiences) ne peuvent jamais être déclarés par un navigateur, seulement émis par la plateforme à leur source. Premiers points d'émission de la fondation de fermeture d'écart (#578); d'autres événements de cycle de vie suivront.

Flux d'activité du dossier — fondation d'une véritable chronologie auditable (§15/§17)

• Mise en place de la fondation de la chronologie automatique et auditable promise de longue date : un registre d'événements d'activité propre au dossier, en ajout seulement, doté du vocabulaire complet du §17 (créé/téléversé/partagé/téléchargé/consulté/signifié/audience/jugement/exécution, etc.). Les événements sont immuables une fois enregistrés, lisibles uniquement par les collaborateurs du dossier (sécurité au niveau ligne) et écrits uniquement par la plateforme — le substrat auquel chaque action sur un objet et chaque accès à un document s'enregistreront, afin que la chaîne de possession et la chronologie reflètent enfin ce qui s'est réellement passé. Première étape d'une fermeture d'écart suivie (issue #578); les points d'émission d'événements suivront.

Classification des documents — meilleure reconnaissance des actes de procédure et des courriels (§29.4/§29.20)

• Donnant suite aux nouveaux garde-fous d'évaluation IA, amélioration du classificateur de documents là où il était le plus faible selon la mesure : il reconnaît désormais le langage des actes de procédure (une partie qui plaide des faits matériels / une demande introductive d'instance) et les blocs d'en-tête de courriel structurés (De:/Objet:/À:) à partir du texte d'un document — des cas qu'il étiquetait mal auparavant. Sur l'évaluation de classification, cela fait passer l'exactitude sur texte seul de 60 % à 100 %, et le garde-fou de non-régression de l'évaluation a été relevé pour le verrouiller. Aucun changement à la classification basée sur le nom de fichier.

Évaluation IA — qualité mesurable et garde-fous de non-régression pour la couche IA (§29.20)

• La qualité de l'IA est désormais mesurée, et non présumée. Un nouveau moteur d'évaluation note les primitives IA de la plateforme par rapport à des jeux de données de référence — exactitude de la classification des documents, précision/rappel de l'extraction des citations juridiques, et fiabilité avec laquelle le garde-fou contre l'injection d'invite détecte les entrées adverses sans fausses alertes — et ces évaluations s'exécutent en intégration continue comme garde-fous de non-régression, de sorte qu'un changement qui dégrade la qualité de l'IA fait échouer la compilation. Le centre de commande du fondateur gagne une vue d'évaluation IA des résultats. Renforcement également d'un chemin d'authentification de tâche d'arrière-plan pour éviter de journaliser un secret partagé.

Rédaction IA — ancrage automatique pour que vos brouillons utilisent toujours vos documents récents (§29.22)

• Les brouillons restent désormais ancrés automatiquement. Une tâche de réconciliation en arrière-plan embarque périodiquement les documents d'un dossier qui sont nouveaux ou modifiés depuis leur dernière indexation, de sorte que lorsque vous demandez un brouillon, il s'appuie sur votre ensemble de documents actuel sans que vous ayez à indexer quoi que ce soit manuellement. La tâche s'exécute avec une isolation stricte — elle n'écrit des fragments interrogeables qu'au sein du dossier propre à chaque document, de sorte que la récupération ne peut toujours lire que les documents que vous êtes autorisé à voir — et est bornée par exécution pour garder un coût prévisible.

Rédaction IA — vos premiers brouillons IA soumis à approbation (§29.8/§29.23)

• La première capacité de rédaction IA est en ligne, et elle met à l'épreuve toute la chaîne gouvernée. Choisissez un dossier auquel vous avez accès et un type de document — mise en demeure, résumé chronologique, note sur les questions en litige, résumé de la preuve ou proposition de règlement — et l'IA produit un BROUILLON ancré dans les documents indexés de ce dossier. Élément crucial : le brouillon n'est jamais utilisé automatiquement : il est conservé comme brouillon « suggéré » nécessitant votre approbation, apparaît dans votre file de revue pour approuver / modifier / rejeter, et est entièrement audité sur la chaîne infalsifiable. Chaque brouillon énonce ses hypothèses, signale l'incertitude, et ne prétend jamais être un avocat ni déposer quoi que ce soit. Un nouveau panneau sur la page des revues IA permet d'en demander un.

Orchestration IA, phase 4 — boucle de rétroaction IA et métriques de qualité du centre de commande (§29.20/§29.21)

• Bouclage de la qualité de l'IA. Vous pouvez désormais évaluer toute sortie de l'IA — utile, ou la signaler comme incorrecte / incomplète / hors sujet / dangereuse / à réviser — avec une note facultative; les évaluations sont conservées de façon privée (sécurité au niveau ligne) et servent de leviers pour améliorer les invites et la récupération. Le centre de commande du fondateur gagne une vue de qualité IA qui lit la chaîne d'audit infalsifiable (volume de requêtes, taux de blocage par garde-fou et d'échec) en parallèle de la distribution des évaluations, rendant la qualité du système mesurable. La chaîne étant désormais l'unique source de vérité de l'IA, l'ancienne table ai_audit_events est officiellement obsolète.

Orchestration IA, phase 3 — récupération ancrée dans vos propres documents de dossier (§29.17/§29.22)

• Le Copilote de litige peut désormais ancrer ses réponses dans les documents réels de votre dossier (génération augmentée par récupération). Un nouveau magasin vectoriel conserve des fragments embarqués des documents d'un dossier; lorsque vous interrogez le copilote au sujet d'un dossier auquel vous avez accès, il récupère sémantiquement les passages les plus pertinents et travaille à partir d'eux. L'isolation est imposée par la base de données : la récupération passe par votre propre session de sécurité au niveau ligne, de sorte qu'elle ne peut jamais lire que les documents des dossiers que vous êtes autorisé à voir — jamais ceux d'autrui. Un point d'accès d'indexation embarque les documents d'un dossier (protégé par l'accès en modification et audité à échec fermé), et le modèle d'embarquement est interchangeable sans toucher au reste de la couche.

Orchestration IA, phase 2 — revue et approbation humaines des brouillons IA (§29.18/§29.23)

• Ajout du système de revue et d'approbation qui permet à une personne d'approuver, modifier ou rejeter les brouillons générés par l'IA avant qu'ils puissent être utilisés — l'exigence du §29.23 selon laquelle aucune sortie matérielle de l'IA ne contourne la revue lorsqu'une approbation est requise. Un nouveau registre privé au propriétaire (protégé par RLS, écriture par rôle de service uniquement) conserve les brouillons qu'un humain doit valider; l'orchestrateur persiste à échec fermé toute sortie soumise à approbation comme brouillon « suggéré ». Une nouvelle page de file de revue permet au propriétaire d'approuver / modifier / rejeter chaque brouillon, chaque décision étant validée contre la machine à états de revue et un contrôle de propriété au niveau applicatif avant toute écriture. Disponible en anglais, français et espagnol.

Orchestration IA, phase 1 — copilote, marché et extraction sous la couche gouvernée (§29.23)

• Migration des routes IA restantes vers la couche de service contrôlée. Le Copilote de litige passe désormais par l'orchestrateur (contrôles de capacité et de portée, garde-fous de sortie, audit infalsifiable À ÉCHEC FERMÉ) tout en préservant son mode de réflexion Anthropic, sa barrière de quota, sa facturation à l'usage et sa vérification des citations. Les assistants du marché gagnent un audit qu'ils n'avaient pas (additif). L'extraction de preuves — un traitement multi-appels qui écrit en base — est désormais auditée à échec fermé avant son exécution, de sorte qu'aucune extraction n'a lieu sans enregistrement infalsifiable. Les formes de réponse dont dépendent les appelants sont préservées.

Orchestration IA — fondation de la barrière d'approbation pour les phases 1 et 2 (§29.23)

• Extension du contrat de l'orchestrateur avant de migrer les routes IA restantes : le résultat expose désormais séparément les détails d'innocuité d'invite et les avertissements de garde-fou (pour préserver la forme de la surface copilote), accepte un identifiant de requête fourni par l'appelant, et ajoute la barrière d'approbation humaine du §29.23 — une politique capacité→approbation validée par le conseil juridique (rédaction/génération de flux exigent une approbation humaine; les capacités consultatives non). Une sortie soumise à approbation est conservée comme brouillon « suggéré » et persistée À ÉCHEC FERMÉ pour revue avant tout usage. Interne seulement; aucun changement de comportement des routes pour l'instant.

Orchestration IA, phase 0b — la couche de service IA contrôlée + traduction migrée (§29.23)

• Introduction de lib/ai/orchestrator.ts : le point d'entrée unique par lequel toute requête IA transitera (permission → orchestration → récupération → modèle → revue de sortie → audit → approbation), avec des ports Récupération/Modèle interchangeables (passe-système dans cette phase). Il impose les invariants du §29.23 — contrôles de capacité par refus-par-défaut, application de la portée, assainissement des injections d'invite, garde-fous de sortie juridique post-génération, et audit À ÉCHEC FERMÉ (l'écriture dans la chaîne infalsifiable doit réussir avant qu'une sortie IA ne soit renvoyée). Migration de la route de traduction comme premier consommateur ; la réponse visible par l'appelant est inchangée. Le streaming (pour le copilote) est volontairement reporté — suivi en TODO.

Orchestration IA, phase 0a — sérialiser la chaîne d'audit infalsifiable (§29.23)

• Renforcement du registre d'audit avant d'y faire transiter les requêtes IA : des ajouts concurrents pouvaient lire la même tête de chaîne et l'un échouait à tort, perdant un événement d'audit. appendAuditChainEvent réessaie désormais sur la tête avancée en cas de conflit de sérialisation (borné, échec immédiat sur les vraies erreurs), et un nouveau déclencheur BEFORE INSERT (migration 0062) fait rejeter par la base elle-même toute ligne qui ne s'enchaîne pas sur la tête validée — transformant « faire confiance au hachage calculé par l'app » en invariant imposé par la base. Fondation de la couche d'orchestration IA à contrôle de permissions du §29.23.

Couche IA, lot 6 — anomalie, abandon, red-team et mention stratégique (§29)

• Dernier lot IA additif : détection d'abandon de flux/d'échecs (§29.13), une primitive d'anomalie de volume par score-z (§29.13), une enveloppe de mention juridiction+rôle pour les sorties stratégiques (§29.10), et un corpus d'évaluation red-team / injection d'invite exerçant le garde-fou d'entrée en direct (§29.20) — plus un test de seuil de cohorte auparavant orphelin intégré à l'IC. Complète la couche additive de gouvernance/primitives IA du §29.

Couche IA, lot 5 — audit de contexte, jeux d'évaluation, aides documentaires et de recherche (§29)

• 6 autres modules IA purs : un auditeur d'évènements d'accès au contexte cloisonné qui alimente la chaîne d'audit existante (§29.17), un échafaudage typé de cas et de jeux de données de référence (§29.20), une comparaison de versions de document ligne/clause (§29.4), un scanner consultatif d'indices de privilège et de signature/sceau (§29.4), une machine à états d'évènements proposés de chronologie (§29.6) et un assembleur de note de recherche (§29.9). Purs, additifs et consultatifs seulement.

Couche IA, lot 4 — garde-fous, cartographie de recherche et analytique (§29)

• 6 autres modules IA purs : un garde-fou de divulgation (vérifie que la sortie juridique IA énonce sa mise en garde/incertitude/juridiction et signale les affirmations sans citation, §29.19), un constructeur de carte d'arguments liant prétentions→fondements→réfutations (§29.9), un décompte agrégé d'utilisation IA protégé par seuil de cohorte (§29.13), un lieur d'évènements de chronologie aux parties (§29.6), un registre de versions d'invite (§29.22) et un typage de matrice de risque probabilité×impact (§29.10). Purs et consultatifs seulement.

Couche IA, lot 3 — extraction, suffisance, analytique et aides à la recherche (§29)

• 6 autres modules IA purs : un extracteur de montants bilingue avec spans verbatim (§29.4), un évaluateur de suffisance de preuve par enjeu (§29.10), de l'analytique d'entonnoir/conversion agrégée (§29.13), une primitive d'état de politique de reprise/échec d'agent (§29.16), un projecteur de variantes de chronologie (§29.6) et un classificateur de type d'autorité juridique — contraignante/persuasive/secondaire/procédurale/réglementaire (§29.9). Purs et consultatifs seulement.

Couche IA, lot 2 — aides d'appariement, d'état de préparation, de documents et d'évaluation (§29)

• 6 autres modules IA purs : la matrice de capacités IA + verdict de gouvernance (§29.1), un moteur d'appariement professionnel explicable montrant pourquoi chaque prestataire est recommandé (§29.11), un triade unifiée d'état de préparation litige/résolution/exécution (§29.10), la détection de doublons et de différences de versions entre documents (§29.4), le marquage du risque d'échéance sur la chronologie (§29.6), et l'échafaudage de métriques/jeux de données d'évaluation IA (§29.20). Purs, déterministes, consultatifs seulement.

Fondations de la couche IA — primitives de gouvernance (§29)

• Démarrage de la couche IA (spéc §29) avec 6 modules de fondation purs et additifs + 81 tests : machine à états de révision des sorties IA (Brouillon→…→Remplacé), types d'évaluation de rétroaction IA, registre de modèles typé avec aides de routage/coût, registre des 12 agents avec garde-fous de capacités, modèle de contexte cloisonné avec garde anti-fuite inter-entités, et contrôles de garde-fou juridiques post-génération. Types et aides uniquement — aucune surface LLM en direct, RLS ou données.

Intégration des tests de régression RON et de preuve dans l'IC

• Fusion de deux PR de tests de régression révisées (désormais inscrites dans la suite de tests IC) : couverture du filtrage par juridiction RON (US FL/TX/VA/WA + Québec uniquement, fermé par défaut) et l'invariant #74 « aucune preuve privilégiée dans le navigateur » (une erreur de stockage ne bascule jamais vers IndexedDB local).

Utilitaire temps réel, primitive de seuil de cohorte et doc sécurité hors-ligne

• Révision et fusion de 3 des PR en attente après une passe adverse multi-agents : un abonné temps réel réutilisable (isolation des données préservée), une primitive dormante de seuil minimal de cohorte pour l'analytique anonymisée future, et le document sur la posture de sécurité hors-ligne chiffrée.

Mention de traduction automatique sur l'API de traduction

• Le point de terminaison de traduction IA renvoie désormais une mention de provenance explicite de traduction automatique (bilingue FR·EN, « à vérifier par rapport à la source faisant autorité ») et un indicateur machineTranslated, afin que les appelants divulguent toujours que le résultat est généré par machine — conformément au garde-fou de divulgation systématique et à la Loi 96.

Journalisation d'audit IA sur la route de traduction

• Le point de terminaison de traduction IA enregistre désormais un évènement d'audit de métadonnées seulement par requête (nombre de caractères, modèle, identifiant de requête — jamais le texte traduit), rattaché à l'utilisateur connecté, à des fins de responsabilité et de surveillance des abus.

Sécurité : correction d'une redirection ouverte à l'authentification

• Correction d'une redirection ouverte dans le flux d'authentification par lien magique/confirmation : la destination `next` après connexion est désormais restreinte aux chemins de même origine (rejet de //hôte, /\\hôte et des URL absolues/à schéma), avec défense en profondeur sur le résolveur de portail.

Conséquences d'agenda, gravité des échéances et tests de couverture

• L'export d'agenda de litige porte désormais la conséquence de chaque échéance (ICS + CSV), et le Centre de commande affiche un badge de gravité (délai de rigueur/strict).
• Ajout de tests de pureté d'édition, du cycle de vie Niveau 0, E2E du tunnel de catalogue et de couverture du registre professionnel pour verrouiller ces comportements.

Garde de déterminisme du cycle de vie, tests d'édition et agenda maître

• Ajout d'une garde de déterminisme de la machine à états du dossier (chaque étape a un chemin avant satisfaisable — aucune impasse silencieuse), ainsi que des tests verrouillant le filtrage par édition des parcours et une garde anti-dérive du registre des espaces de travail.
• Les rappels peuvent désormais citer leur propre source (pureté d'édition), et le Centre de commande affiche une liste d'agenda maître par échéance avec statut.

Machine à états du cycle de vie, parcours selon l'édition et import d'agenda

• Les parcours de résolution et recours gouvernementaux sont désormais adaptés à l'édition (filtrables, par défaut le Québec), et ajout d'un utilitaire associant les types de documents aux étapes du cycle de vie.
• Enrichissement de la page /lifecycle avec des métadonnées SEO OpenGraph/Twitter, ajout de l'import d'agenda ICS, d'accesseurs de palier du registre professionnel et d'une passe d'accessibilité sur le parcours Conflict-OS.

Note de disponibilité communautaire et bannière Smart App iOS

• Ajout d'une note « où Juge.ca est en service » sur la page communauté juridique, dérivée des données de phase par juridiction (actuellement le Québec) — information générale, pas un avis juridique.
• Ajout d'une bannière Smart App iOS adaptée à l'édition pour faire apparaître l'application native dans Safari mobile lorsque configurée.

Aperçu Communauté/Académie, liens profonds mobiles et chronologie de dossier

• Ajout des sections d'aperçu « Questions et réponses de la communauté » et « Académie Juge » (à venir) sur la page communauté juridique (information générale seulement, pas un avis juridique).
• Bases du lien profond mobile : une route assetlinks.json Android par édition, un document d'architecture deux-listings-un-codebase et un test de fumée mobile droite-à-gauche pour l'arabe et l'hébreu.
• Ajout d'un modèle de lecture de chronologie de dossier unifié (faits, échéances et jalons de signification) et correction d'une mise en garde obsolète sur l'écran de partage à un avocat.

PWA mobile, nettoyage i18n et bases d'analytique

• Ajout d'un manifeste d'application web (PWA) et de métadonnées viewport/couleur de thème pour une application installable et un rendu pleine largeur sur mobile, adapté à l'édition (Juge.ca ou Judge911).
• Déplacement du texte restant de la visionneuse de fichiers vers le dictionnaire de traduction avec parité complète en/fr/es, et extension des libellés de règles d'assermentation en ligne (RON) à toutes les langues prises en charge.
• Ajout d'un document de référence pour la soumission aux magasins d'applications, d'une enveloppe typée de confiance/provenance pour l'analytique, et d'une bannière lecture seule/sans copilote sur la vue d'acceptation de dossier partagé.

Échéances selon l'édition, sécurité de la numérisation et bases RTL/mobile

• Les avis d'échéance suivent désormais la juridiction/édition propre au dossier au lieu d'afficher toujours la mention américaine — les dossiers québécois ne voient plus de note d'échéance de type américain.
• La saisie de documents vérifie le type et la taille des fichiers côté client avant toute ROC/téléversement — un garde-fou d'expérience qui s'ajoute à l'analyse de sécurité serveur faisant autorité.
• La réponse du copilote IA affiche maintenant une référence d'audit et une mention « vérification humaine requise avant dépôt » lorsque les citations ne sont pas vérifiées.
• Bases internes pour les langues de droite à gauche et la coque applicative mobile : un utilitaire de locale RTL + garde CI, une matrice de configuration mobile par édition et l'association de site Apple par édition pour les liens profonds.

Exports d'agenda, accessibilité et découvrabilité mobile

• Les exports d'agenda (.ics) comportent désormais des dates de fin pour les évènements d'une journée et marquent les échéances terminées comme annulées, pour un affichage et un barré corrects dans Outlook et Google Agenda.
• Accessibilité : la visionneuse de fichiers et les bascules d'assermentation en ligne du commissaire exposent maintenant des libellés, le focus de dialogue et les motifs d'état désactivé aux lecteurs d'écran.
• Les vérifications de localisation et les tests d'isolation de domaine des liens profonds couvrent désormais les 18 langues et les deux éditions, et un nœud de données structurées MobileApplication (avec mention « pas un tribunal ») a été ajouté pour la découvrabilité.

Améliorations mobiles et d'accessibilité — cibles tactiles, numérisation, mention de traduction

• Visionneuse de fichiers et saisie de documents adaptées au tactile sur téléphone : fenêtres pleine largeur, cibles tactiles de 44 px, capture photo multipage et défilement tactile fluide.
• Ajout d'utilitaires CSS pour les zones sûres et les cibles tactiles minimales, limités à la coque applicative native afin de ne pas modifier la version Web.
• Ajout d'un badge en ligne « traduit automatiquement — à vérifier par rapport à la source » pour le contenu traduit, ainsi qu'un contrôle CI de la couverture française des chaînes juridiques québécoises.
• Ajout d'un module typé de contrat d'agent (provenance et niveau de confiance) pour la flotte d'agents IA du cycle de vie.

Cycle de vie : masquer les modules non fonctionnels pour la bêta

• Nettoyage de la vue du cycle de vie du dossier pour la bêta — un contrôle « à venir » réellement non fonctionnel est désormais masqué derrière un indicateur explicite unique au lieu d'afficher un bouton inerte, tandis que tout ce qui fonctionne reste visible. La bascule est un interrupteur réversible unique, sans fonctionnalité surévaluée.

Automatisation de la conservation et de la suppression (respectant les obligations de conservation)

• Ajout d'une politique de conservation des données configurable et d'un nettoyage planifié qui supprime les anciens enregistrements au-delà de leur période de conservation — en ignorant toujours tout élément sous une obligation de conservation active, par-dessus le garde-fou de suppression existant. Le balayage destructif ne s'exécute que derrière une tâche planifiée protégée par un secret, prend en charge un mode simulation et consigne chaque action dans le journal d'audit.

Garde-fou de pureté des éditions — aucune fuite d'une autre juridiction

• Ajout d'une vérification automatique garantissant que le contenu de chaque édition reste dans le vocabulaire de sa propre juridiction — signalant par exemple un type de tribunal québécois apparaissant dans l'édition américaine, ou un rôle américain au Québec. Elle dérive les marqueurs du registre des éditions lui-même (les nouvelles éditions sont donc vérifiées automatiquement) et peut bloquer l'intégration continue; les trois éditions en service passent sans erreur aujourd'hui.

Export de déclaration fiscale des prestataires (1099-K/NEC, T4A)

• Ajout d'un générateur de reporting uniquement qui totalise les sommes versées à chaque prestataire au cours d'une année d'imposition et produit des lignes d'export 1099-K/1099-NEC (É.-U.) et T4A (Canada) + CSV. Il ne fait que résumer les versements existants — il ne calcule aucun impôt dû, ne produit aucune déclaration et ne déplace aucun fonds; les seuils de déclaration sont configurables et signalés pour confirmation par les finances/le conseil juridique.

La progression du professionnel revient dans le dossier

• Lorsqu'un professionnel que vous avez mandaté depuis un dossier met à jour sa commande (acceptée, en cours, signifiée/terminée, annulée), cette progression se reporte désormais sur la demande de service du dossier et coche ses jalons — de sorte que « Signifié » pourra ensuite déclencher le délai de réponse, sans jamais quitter le dossier.

Couverture de tests du moteur de rappels

• Renforcement du moteur de rappels d'échéances, d'audiences et de rendez-vous par une suite de tests complète — délais adaptés à l'édition, suppression des doublons, intégrité des liens de désabonnement, respect des heures de silence et des préférences, et entrées atypiques comme des dates passées ou mal formées.

Mandater un professionnel depuis un dossier — commande liée + partage limité

• Mandater un huissier ou un service depuis un dossier crée désormais une véritable commande du marché reliée à ce dossier, et mémorise la commande sur la demande pour que son statut puisse y revenir ultérieurement.
• Ajout d'un partage limité et temporisé d'un dossier avec le professionnel mandaté — un accès en lecture seule restreint aux documents que vous choisissez, expirant après une période définie (30 jours par défaut), sans jamais ouvrir l'ensemble du dossier.

Les commandes du marché sont reliées au dossier

• Une commande du marché peut désormais indiquer quel dossier elle dessert et quels documents/preuves ont été partagés avec le professionnel — le lien de données qui permet de mandater un huissier, un notaire ou un expert depuis un dossier. Vous ne pouvez relier une commande qu'à un dossier qui vous appartient, ce qui est appliqué par la base de données.

Garde-fou de suppression sous obligation de conservation + runbook de sauvegarde/restauration

• Un dossier sous obligation de conservation active ne peut plus être supprimé — la base de données refuse la suppression (pour tous, y compris les processus automatisés) au lieu de détruire silencieusement des preuves à conserver. L'application affiche un message clair invitant à lever d'abord l'obligation.
• Ajout d'un runbook opérateur pour la sauvegarde de la base de données et un exercice de restauration testée, et extension des vérifications d'isolation des données pour confirmer le nouveau garde-fou de suppression.

Vérifications comportementales d'isolation des données

• Ajout d'un outil de vérification qui sollicite la base de données en direct pour confirmer qu'un compte ne peut pas lire le dossier d'un autre, et que le journal d'audit infalsifiable rejette réellement les modifications et les suppressions. Il s'exécute entièrement dans une transaction annulée, sans rien écrire.

Intégrité des preuves vérifiée avant la production judiciaire

• Lors de l'assemblage d'une production judiciaire estampillée Bates, les octets stockés de chaque fichier sont désormais revérifiés par rapport à l'empreinte SHA-256 enregistrée lors de l'ingestion. Si un fichier a été modifié dans le stockage depuis, la production est interrompue avec un avertissement clair de falsification au lieu de produire une preuve compromise.

Empreinte d'intégrité des preuves côté serveur (chaîne de possession)

• Les preuves téléversées reçoivent désormais une empreinte SHA-256 calculée sur le serveur à partir des octets réellement stockés — et non d'une valeur fournie par le navigateur — afin de pouvoir prouver ultérieurement que le fichier n'a pas été modifié. L'empreinte est enregistrée dans la preuve et marque son statut de chaîne de possession comme « enregistré ».

Vérification automatisée de la sécurité au niveau des lignes au déploiement

• Chaque déploiement vérifie désormais que les règles de sécurité au niveau des lignes (qui peut lire et modifier un dossier et ses copies partagées) sont réellement en vigueur dans la base de données, et pas seulement que les fichiers de migration se sont exécutés — avec un résultat clair réussite/échec.

Migrations de base de données débloquées + surveillance des écarts

• Correction d'une migration (0046) qui bloquait silencieusement la chaîne de migrations de la base de données, afin qu'un arriéré de mises à jour de schéma et de sécurité — dont le renforcement de la sécurité au niveau des lignes — puisse enfin atteindre la base de données au déploiement.
• Ajout d'un indicateur d'écart de migration à la vérification d'état de l'administration, pour qu'une migration bloquée se révèle immédiatement au lieu de se cacher derrière une compilation réussie.

Indication en langage clair à l'étape du tribunal

• L'étape « cour / tribunal » de l'entrevue affiche maintenant une courte indication rassurante pour ceux qui ne savent pas lequel s'applique — choisissez au mieux, vous pourrez le modifier plus tard, et un professionnel pourra confirmer le bon tribunal.

Risques classés par gravité dans la vue stratégie

• La vue stratégie classe désormais les risques selon leur gravité plutôt que de les afficher en texte uniforme : une échéance fatale dépassée (p. ex. un délai d'appel) est marquée « fatale » et affichée en premier, avec des pastilles de gravité colorées et étiquetées jusqu'aux lacunes de moindre priorité.
• Sous le capot, chaque risque est maintenant un indicateur typé (gravité, message et montant d'exposition financière facultatif) — préparant l'ajout ultérieur de montants en dollars — et la gravité du risque découle de la cote fatale/stricte/souple propre à chaque échéance.

Avis de sécurité avant toute étape juridique

• Ajout d’un avis de sécurité clair — affiché sur la page d’accueil avant la connexion et sur une nouvelle page /emergency — indiquant à toute personne en danger immédiat d’appeler d’abord les services d’urgence, et précisant clairement que la plateforme n’est pas un service d’urgence.
• L’avis s’adapte à l’édition : il mentionne le 911 uniquement là où ce numéro est valide (États-Unis et Canada) et renvoie sinon aux services d’urgence locaux, afin de ne jamais afficher un numéro impossible à vérifier pour le pays concerné.

Renforcement de la sécurité — points d’accès notifications, IA et partages

• Fermeture d’une voie d’abus où un utilisateur connecté pouvait envoyer un courriel ou un SMS aux couleurs de la plateforme à n’importe quelle adresse : les notifications doivent désormais être rattachées à un dossier que vous pouvez modifier.
• L’assistant IA et le vérificateur d’autorités juridiques refusent maintenant de s’exécuter si le système central n’est pas configuré, au lieu de répondre sans authentification ; l’ingestion de preuves valide l’identifiant du dossier ; et révoquer un partage qui ne vous appartient pas renvoie désormais une erreur claire.

Avis de sécurité des données + alerte de stockage saturé

• Lorsque vos dossiers ne sont enregistrés que dans ce navigateur (aucun compte infonuagique connecté), l’espace de travail vous avertit désormais que les données ne résident que sur cet appareil et vous rappelle d’exporter une sauvegarde — le rappel réapparaît après une semaine pour ne pas être oublié.
• Si le stockage de votre navigateur est saturé, l’espace de travail vous alerte maintenant que vos dernières modifications n’ont peut-être pas été enregistrées, au lieu d’échouer en silence.

Sécurité des paiements + vérifications d’état exactes + modèle d’environnement

• Renforcement des chemins de paiement : le paiement de l’espace de travail exige désormais un utilisateur connecté (plus question d’ouvrir un paiement pour une adresse arbitraire), et le signal de disponibilité des versements canadiens ne devient pas vert sans la clé de chiffrement dont il dépend.
• Ops : la vérification d’état signale maintenant séparément les sources d’autorité juridique américaine et canadienne (au lieu d’un indicateur trompeur), et un fichier .env.example documenté énumère les variables d’environnement utilisées par la plateforme.

Correctif du marché en espagnol + métadonnées SEO + image de partage

• Les utilisateurs hispanophones ne voient plus le contenu éditorial des tunnels de services en anglais — le bloc non traduit est masqué sur /es tandis que l’en-tête et les étapes localisés du tunnel s’affichent toujours. Les badges de statut des prestataires sont aussi traduits.
• SEO : les pages de services et de prestataires du marché émettent désormais des balises canoniques et hreflang entre les locales, et l’image de partage social de Juge.ca est une vraie carte 1200×630 (c’était le logo à la mauvaise taille).

Avertissements de délais de rigueur + renforcement de la sécurité

• Les délais portent désormais une gravité : un délai de rigueur (p. ex. le délai d’appel — aucune prolongation possible) s’affiche en rouge avec une mention « Délai de rigueur » et une conséquence en langage clair, afin qu’un délai irrécupérable ne ressemble plus à un simple rappel. Les rappels incluent cette conséquence.
• Renforcement supplémentaire de la sécurité : en-têtes de téléchargement assainis, limitation de débit du point d’entrée public de télémétrie d’erreurs, restriction des détails d’intégration du point de santé aux administrateurs, et acceptation de partage rendue à l’épreuve des conditions de concurrence au niveau de la base de données.

Renforcement de la sécurité — partage de dossier, ingestion de preuves, télémétrie

• Resserrement des contrôles d’accès aux données : les partages « révision » à portée complète acceptés accordent désormais correctement un accès en lecture seule à un dossier au niveau de la base de données (ils n’en accordaient aucun auparavant), sans affaiblir la limite des partages par sous-ensemble; le point d’entrée d’ingestion de preuves applique la propriété du dossier; et les événements d’activité/analytique enregistrent l’utilisateur authentifié plutôt qu’un identifiant fourni par le client. Aucun changement à ce que les propriétaires et collaborateurs peuvent déjà voir.

Admission axée sur la sécurité + inscription accessible

• L’admission d’un dossier commence désormais par une vérification de sécurité : un avis bien visible « en cas de danger immédiat, composez le 911 » et une question demandant si vous avez besoin d’aide dans les 24 heures — les cas urgents sont dirigés directement vers de l’aide disponible plutôt que vers un long formulaire. Affiché sur les deux éditions; aucune ligne d’urgence inventée.
• Le formulaire d’inscription/connexion est maintenant accessible : étiquettes et remplissage automatique appropriés sur les champs nom, courriel et mot de passe (pour que les navigateurs et gestionnaires de mots de passe fonctionnent), exigences de mot de passe affichées en amont, et une case de consentement plus grande et plus facile à toucher.

Les notifications se déclenchent — courriel de confirmation de commande + tâche planifiée

• Les commandes de services payées envoient désormais automatiquement un courriel de confirmation, et une tâche quotidienne sécurisée réessaie les envois échoués et relance les commandes en cours — comblant l’écart où le moteur de notifications existait mais rien ne le déclenchait. Le courriel fonctionne dès qu’un expéditeur est connecté (testable maintenant via le webhook de courriel); les rappels proactifs d’échéances de dossiers s’activeront une fois les dossiers migrés côté serveur (suivi séparément).

Bases de la phase 1 — moteur de rappels de commandes + configuration Supabase en tant que code

• Ajout du moteur de rappels de commandes et d’échéances sur les rails de livraison existants : règles de délais adaptées à l’édition (échéance, audience, rendez-vous), planification idempotente et exacte au fuseau horaire, gabarits bilingues, jetons de désabonnement signés et modèle de préférences de notification — entièrement testé, prêt à brancher au courriel/SMS dès la connexion des fournisseurs.
• Configuration d’authentification Supabase consignée en tant que code (supabase/config.toml — URL du site, liste d’autorisation de redirection, espace réservé SMTP) pour qu’un blocage du tableau de bord ne puisse plus jamais empêcher la configuration de l’authentification (#103).

Fiabilité des builds — réduction du nombre de pages statiques pour éliminer les échecs OOM

• Le build de production pré-générait ~2 576 pages statiques (builds de 16 minutes, échecs de déploiement intermittents par manque de mémoire). Il ne pré-génère désormais que les éditions actives et les locales au contenu distinct; les ~200 éditions « bientôt disponibles » et les locales à contenu dupliqué sont rendues à la demande et restent indexables. Le build est passé à ~1 569 pages et à quelques secondes au lieu de minutes — sans changement de référencement ni de contenu.

Pierre angulaire A→Z — l’étape du tribunal à l’admission tient compte de l’édition

• L’étape de sélection du tribunal n’affiche plus les tribunaux québécois (Cour du Québec, TAL/TAQ) sur l’édition américaine. Le Québec conserve sa sélection inchangée; les autres éditions affichent un avis honnête « la sélection du tribunal est en préparation avec des conseillers locaux » et un champ de juridiction libre — jamais une liste de tribunaux fabriquée.

Suivi du test fumigène du marché

• Mise à jour du test fumigène Playwright du tunnel de services pour l’admission de devis sans paiement introduite dans #483 : les libellés de forfait sont ciblés dans la section des tarifs et les appels à demander un devis sont vérifiés comme boutons plutôt que comme anciens liens.

Pierre angulaire A→Z (juridiction sur chaque dossier) + correctif de sécurité du partage par sous-ensemble

• Pierre angulaire (#457) : chaque dossier porte désormais une édition/juridiction/locale; les dossiers existants migrent vers le Québec par défaut et se chargent sans changement; le moteur de délais renvoie un avis de délai manuel (jamais une date fabriquée) pour toute édition sans pack de règles révisé.
• Sécurité (#469) : l’accès en lecture aux documents/pièces/preuves applique désormais le sous-ensemble enregistré d’un partage « révision » au niveau de la base de données (RLS), pas seulement dans l’interface. Approche prudente et additive — aucun accès existant n’est réduit.

Feuille de route — plateforme A→Z au-delà du MVP + plan iOS/Android

• Publication de la feuille de route au-delà du MVP pour faire de cette plateforme la première au monde à mener un dossier de A à Z sans rupture : 21 épopées réparties en trois domaines (complétude du cycle de vie, fonctionnalités différenciantes riches, mobile natif), chacune décomposée en étapes délégables à des agents, plus un correctif de sécurité critique relevé. Recommandation mobile : Capacitor (hybride) pour iOS + Android. Voir docs/BEYOND_MVP_ROADMAP.md et les suivis #462 / #470 / #481.

Ops — guide de récupération d’accès et de reconstruction de Supabase

• Documentation de la marche à suivre en cas de blocage du tableau de bord Supabase, sans changer de fournisseur : le backend (103 tables, 234 politiques RLS) est entièrement reproductible à partir des 56 migrations du dépôt — un nouveau projet + « supabase db push » + repointage des variables d’environnement le reconstruit en quelques minutes. Inclut l’exportation des données, la configuration d’authentification/SMTP qui règle le problème des liens magiques, et la configuration en tant que code. Voir docs/SUPABASE_RECOVERY_RUNBOOK.md.

Pureté des éditions — les tunnels de services américains n’affichent plus de termes de droit québécois

• Le contenu éditorial des tunnels de services du marché (déroulement, FAQ, notes sur la preuve de signification) est rédigé en termes de droit civil québécois (huissier, procès-verbal, Barreau du Québec, « dépôt au Québec »). Il est désormais masqué sur l’édition américaine, qui conserve plutôt son en-tête de tunnel et son pipeline de jalons adaptés à la juridiction. Un contenu éditorial propre aux É.-U. est suivi en tâche de suivi.

Écusson Judge911 — uniforme sur toutes les surfaces américaines

• Harmonisation de la marque de l’édition américaine : le favicon, l’image de partage social et le logo pour moteurs de recherche utilisent désormais le nouvel écusson Judge911 plat (bouclier marine, balance dorée, base rouge) déjà présent dans l’en-tête et le héros — la même marque apparaît partout au lieu d’une autre dans l’onglet du navigateur et les aperçus de liens.

Hygiène INP — gestionnaires d’événements globaux allégés

• Allègement des écouteurs d’analytique au niveau du document : l’indicateur d’intention de sortie est lu une seule fois plutôt qu’à chaque sortie de souris, et les écouteurs de clic et de sortie sont passifs, de sorte que le navigateur n’attend jamais après eux avant d’afficher. Hygiène d’interaction-à-l’affichage; les balises de clic d’appel à l’action restent synchrones pour survivre à la navigation.

Pureté des éditions — catalogue de services patriotisé + routes québécoises bloquées

• Le catalogue de services d’exécution tient maintenant compte de la juridiction : l’édition américaine affiche « Notarisation (notaire public) » et « Signification (agent de signification) » plutôt que les services québécois d’assermentation et d’huissier.
• Blocage des dernières routes propres au Québec sur l’édition américaine (les pages publiques d’huissier renvoient une erreur 404), et le bouton « Signifier des documents » du marché pointe désormais vers le flux américain de signification.

Éditions par juridiction — inscription, marché et rôles américains

• Chaque édition est désormais propre à sa juridiction : les États-Unis (judge911.com) et le Québec (juge.ca) ne font plus référence au système juridique de l’autre. Un nouveau registre des professions par édition devient la source unique des rôles et des organismes d’accréditation offerts dans chaque pays.
• L’inscription et l’intégration des partenaires aux États-Unis présentent des rôles propres aux É.-U. — avocats (State Bar), notaires publics, agents de signification et enquêteurs privés — sans jamais demander de titres québécois (Barreau, Chambre des notaires, BSP).
• Le marché, les services et les types de compte américains retirent les rôles propres au Québec (huissier, commissaire à l’assermentation); les portails huissier et commissaire renvoient une erreur 404 sur l’édition américaine.
• Ajout du nouvel écusson Judge911 dans le héros de la page d’accueil américaine.