Devlog

Un registre public de ce qui a avancé.

Ce journal reste pratique : ce qui a été livré, resserré, ou rendu visible sur la surface publique.

La première visite suit désormais la langue de l’appareil lorsqu’aucune langue du site n’est enregistrée.

Si le navigateur ne contient aucun choix de langue pour le site Ronova, le site public consulte la liste des langues du navigateur et du système, puis ouvre la route anglaise, allemande, française, japonaise ou chinoise traditionnelle correspondante.

  • Une langue choisie sur le site, ou une route localisée ouverte explicitement, est mémorisée et prévaut sur toute détection ultérieure de l’environnement.
  • Les langues non prises en charge restent en anglais, le chinois simplifié n’est pas présenté comme du chinois traditionnel et aucun état d’identité ou de compte supplémentaire n’est créé.

Les comptes institutionnels 0XX disposent désormais d’un tableau d’honneur et d’un parcours d’e-mail de courtoisie facultatifs.

Les membres humains Ronova ID éligibles peuvent préparer un profil de reconnaissance privé par défaut et demander une adresse de transfert @triluna.org vérifiée, sans créer un autre compte ni obtenir d’autorité administrative.

  • Chaque champ public est contrôlé séparément ; membres non publiés, destinations, notes internes, données de vérification et métadonnées du fournisseur restent privés.
  • L’activation e-mail reste en attente jusqu’à la vérification de bout en bout d’un fournisseur de routage de production, d’une clé de chiffrement dédiée et de la configuration mail du domaine.

Archon gère désormais les préfixes et rôles des comptes ordinaires depuis un tableau de bord unique.

Archon commence désormais par une recherche UID exacte au format `XXX XXXXX XXXXX`. Un compte Ronova ID universel ordinaire peut conserver plusieurs identifiants issus de préfixes valides en même temps, choisir un identifiant principal et gérer des rôles indépendants dans son tableau de bord.

  • Changer le préfixe principal conserve l’identifiant précédent comme alias explicitement actif du même compte immuable ; chaque identifiant actif se résout vers ce compte unique et n’accorde jamais d’autorité par lui-même.
  • Le tableau réunit identifiants attribués, rôles, permissions effectives, sessions, résumés d’authentificateurs, activité récente et historique UID sans exposer e-mail, matériel d’identification, hachage de session ni métadonnées d’audit.
  • Les comptes exacts 000 00000 00000 et 999 99999 99999 n’apparaissent ni dans la recherche Archon ni dans les tableaux de compte et restent immuables aux niveaux API, coordinateur, exécuteur et base de données.

Omni Archon dispose de son premier lecteur Gekka privé.

Archon peut désormais rechercher une vue bornée et expurgée des métadonnées de codes de gouvernance Gekka au moyen d’un exécuteur privé appartenant à Gekka. Ronova signe la requête, le coordinateur ajoute une assertion propre à l’exécuteur, puis Gekka vérifie indépendamment le contrat et l’audience avant de lire sa propre base.

  • Les résultats ne contiennent que des identifiants de code opaques, libellés, états, contextes autorisés, limites d’usage, dates et une version opaque ; valeurs porteuses, hachages, fragments, attributions, notes, identités d’acteurs, cookies et identifiants secrets ne franchissent jamais la frontière.
  • Création, révocation et restauration de codes, rôles, versions, contrôles d’urgence, facturation et secrets bruts restent désactivés jusqu’à la validation séparée de leurs contrats de mutation, de récupération et d’approbation propres au projet.

Travel Evaluation conserve désormais des enregistrements serveur par Ronova ID.

Travel Evaluation stocke désormais les évaluations comme des enregistrements côté serveur appartenant à un Ronova ID. Les archives publiques récupèrent les enregistrements publiés, tandis que seul le propriétaire authentifié peut créer, mettre à jour ou supprimer ses propres enregistrements.

  • Les brouillons locaux restent dans le navigateur jusqu’à ce que leur propriétaire choisisse explicitement de les enregistrer ; les consultations des archives publiques n’exposent aucune donnée de brouillon.
  • Pendant une modification saisie, le champ actif reste monté, ce qui préserve le focus pendant l’enregistrement des changements de fiche.

L’affichage Ronova ID dépend désormais d’une autorité unique.

Les surfaces Compte, Archon et workbench Travel récupèrent maintenant la Ronova ID actuelle et mutable depuis une API authentifiée no-store sur ronova.dev, et ne l’acceptent que si son sujet immuable correspond à la session du domaine appelant.

  • La réponse d’affichage ne contient que le sujet immuable, le descripteur d’identité actuel, le nom affiché et l’URL de connexion ; elle n’expose ni rôle, droit, identifiant secret, donnée de session, ni alias legacy.
  • id.ronova.dev et archon.ronova.dev conservent des sessions propres à leur hôte, mais résolvent l’ID affichée auprès de ronova.dev, y compris après une restauration du cache précédent/suivant.
  • Les valeurs v1 exactes restent explicitement libellées Ronova ID legacy jusqu’au cutover de production v2 ; aucun ancien préfixe n’est réécrit en identité actuelle fabriquée.
  • Une Ronova ID reste un identifiant, jamais une autorisation. Les contrôles du principal protégé, des rôles, des droits, de l’état du compte et de la session forte restent côté serveur.

Travel Evaluation conserve la saisie sur place et compacte les archives.

Le carnet Travel Evaluation ne reconstruit plus sa feuille active lorsqu’un champ change : la saisie successive conserve donc le focus, la position de défilement et le brouillon local au navigateur. Créer, archive des vols, archive des lounges et archive des hôtels sont désormais des vues compactes du même document plutôt qu’une longue page mélangée. La taxonomie de l’archive emploie des accents de classe et de catégorie retenus, tandis que les badges de résultat gardent leur propre échelle de qualité.

  • Les modifications de texte, métadonnées et score ne mettent à jour que la feuille concernée ; le filtrage de l’archive se redessine après une courte pause de saisie, pas à chaque caractère.
  • Les quatre vues sont accessibles comme repères dans le même document : passer du brouillon privé à une archive de catégorie ne recharge pas et ne jette pas la feuille montée.
  • Les taxonomies lounge, hôtel et vol portent désormais un accent cohérent dans l’archive et l’éditeur, tandis que les résultats utilisent une tonalité accessible distincte.
  • Le workbench reste local au navigateur derrière la frontière Ronova ID existante ; cette finition n’implique ni second système de compte, ni changement de données distantes, ni déploiement.

Mouvement universel publié et vérifié.

Cette version de production ajoute, lorsque pertinent, un mouvement directionnel depuis le haut et le bas, un retour d’appui pour les contrôles et une prise en charge du mouvement réduit. Elle a été publiée et vérifiée sur ronova.dev.

  • Portée connue : mouvement directionnel haut et bas lorsque pertinent, retour d’appui et prise en charge du mouvement réduit.
  • Publié et vérifié sur ronova.dev ; aucune migration D1 distante ni mutation de données utilisateur n’a été exécutée, et la frontière Ronova ID universelle reste intacte.

Les sceaux de projet partagent désormais un traitement de carte discret.

Le répertoire des projets Ronova et les cartes de la page d’accueil rendent désormais chaque sceau de projet par le même masque entièrement visible en bas à droite : blanc à 15 % d’opacité, à l’intérieur de la carte plutôt que rogné à pleine hauteur. Travel Evaluation réutilise son sceau Image 2 existant, en une seule couleur.

  • Toutes les cartes actuelles utilisent le même champ de taille et de retrait en bas à droite ; chaque sceau garde sa propre silhouette alpha, y compris la marque Borealis non carrée.
  • Travel Evaluation conserve sa marque SVG colorée pour la page projet, tandis que sa carte de catalogue utilise le sceau de voyage Image 2 existant, monochrome.
  • Aucune route, aucun comportement de compte, accès projet, donnée ni frontière Ronova ID n’a changé.

La Communauté s’ouvre désormais plus vite et Messages dispose d’un espace privé concentré.

Pour chaque langue, Community sélectionne désormais un sous-ensemble local compact de Yuji Syuku avant de se replier sur la police locale complète pour les glyphes rares ou saisis par les utilisateurs. Les Messages privés s’ouvrent maintenant dans un seul espace de salon en pleine hauteur, plutôt que dans le chrome public du site, et leurs documents restent no-store.

  • Messages réunit la liste des salons, la conversation active, l’avis de confidentialité et le compositeur chiffré dans une fenêtre concentrée ; sur téléphone, la liste et la conversation deviennent deux vues distinctes et assumées.
  • Les salons d’identité identifient chaque expéditeur comme Ronova avec une Ronova ID formatée ; les salons de session restent volontairement Invité / ID de session. Avant de créer ou rejoindre un salon, le navigateur vérifie l’E2EE et le stockage local des clés ; un refus de stockage persistant demande une confirmation explicite.
  • Yuji Syuku reste entièrement auto-hébergée sous sa licence OFL existante ; les sous-ensembles par langue réduisent le transfert au premier chargement sans exclure les textes rares.
  • Des versions de livraison explicites permettent de mettre en cache immuablement les styles et scripts publics de la Communauté et de l’enveloppe partagée plutôt que de les revalider inutilement.
  • La règle de cache immuable s’applique uniquement aux ressources statiques versionnées de la Communauté et de l’enveloppe partagée. Les documents Messages privés et leur limite de chiffrement restent inchangés.

La Communauté Ronova prend désormais en charge les demandes E2EE directes et un espace de conversation dédié.

Une correction d’exécution rétablit le chargement du forum public et la participation authentifiée. Les salons de session privés s’initialisent correctement avec une invitation de session révocable ; les demandes E2EE directes peuvent maintenant viser une Ronova ID ou son adresse virtuelle déterministe sans modifier la limite de confidentialité : une recherche de type e-mail ne révèle pas l’existence d’un compte et l’approbation du destinataire précède tout accès au salon, à l’appareil ou au texte chiffré. L’espace Messages devient une surface de conversation Ronova distincte pour les discussions actives et petits groupes, avec attribution de l’expéditeur et horodatages plutôt que de reprendre une interface de messagerie grand public.

  • Tout le monde peut lire les fils du forum ; publier, répondre, réagir, signaler et retirer ses propres contenus exige une session Ronova ID humaine active. Aucun second système de compte n’est créé.
  • Chaque Ronova ID a l’adresse interne déterministe `[email protected]` pour l’adressage Community. Ce n’est pas une boîte SMTP et l’envoi ou la réception de courriels est désactivé par défaut.
  • Une demande E2EE directe peut commencer avec une Ronova ID ou une adresse virtuelle. La recherche d’e-mail reste volontairement ambiguë, et l’approbation du destinataire est requise avant tout accès au salon, à l’appareil ou au texte chiffré.
  • Les salons de session privés utilisent une invitation révocable. Le service conserve le texte chiffré et des métadonnées opérationnelles limitées, jamais des corps de messages lisibles.
  • La première version énonce clairement ses limites : aucune pièce jointe, aucune récupération de clé dans le cloud, aucune promesse de forward secrecy et aucune protection promise contre un client compromis.
  • Les messages utilisent un espace de conversation Ronova distinct pour les discussions actives et petits groupes, avec attribution de l’expéditeur et horodatages — sans indicateur de présence, accusé de lecture ni accès du service au texte en clair.
  • Les mises en page de la Communauté passent en pile avant qu’une coque étroite au ratio d’or ne devienne trop serrée ; la sélection d’une discussion place le focus sur son titre identifié, et le fil de messages ne réannonce plus les messages précédents lors de l’interrogation.

Omni Archon active deux mutations d’identité Ronova strictement bornées.

Le catalogue de 252 capacités reste intact. Exactement deux mutations d’identité Ronova sont désormais utilisables après une confirmation par passkey liée à l’action : révoquer une session d’un autre utilisateur non protégé, ou modifier par compare-and-swap l’état d’un autre compte non protégé entre actif, verrouillé et désactivé.

  • Verrouiller ou désactiver un compte révoque aussi toutes ses sessions actives ; ni cette action ni la révocation de session ne peuvent viser le principal humain protégé ou le Root System.
  • ronova.dev conserve la session de connexion canonique et l’autorité d’affichage d’identité ; id, portal et archon reçoivent des sessions `__Host-` distinctes via des callbacks exacts à code d’autorisation unique, avec state signé et PKCE S256.
  • Seules les adresses e-mail vérifiées peuvent se connecter. Les renvois sont bornés, la reprise d’un alias non vérifié ancien reste étroite, et des gardes de base de données préservent le dernier identifiant humain et le dernier passkey de l’owner protégé.
  • Pages ne peut joindre qu’un coordinateur et un executor privés, signés, par Service Binding. Les reçus idempotents, les traces d’audit et les verrous de ressource sont enregistrés atomiquement.
  • Seul le principal humain protégé `000` peut exécuter ces actions ; le Root System `999` reste non interactif. Un UID n’autorise jamais, et Ronova ID universel demeure l’unique système d’identité.
  • Les 250 autres capacités de mutation ou externes — Gekka, VPN, domaines, cycle de vie UID, approbations et rollback, facturation et secrets bruts compris — restent fermées par défaut jusqu’à la validation de leurs executors et exercices de récupération.

Ronova ID utilise maintenant un format canonique de treize chiffres.

Ronova ID v2 affiche `AAA XXXXX XXXXX`, preserve les subjects et credentials immuables et separe la classe d'identite canonique des autorisations.

  • Le principal humain Ronova protege est exactement `000 00000 00000`; son ancien identifiant reste reserve a jamais comme historique.
  • Le principal Root System desactive est exactement `999 99999 99999` et ne possede ni mot de passe, passkey, code de recuperation, session, activation ni voie de connexion ordinaire.
  • Les identifiants legacy enregistres exactement restent des alias immuables; les surfaces actuelles copient treize chiffres compacts et affichent l'identifiant groupe sans retour a la ligne.

Porta Ronovae est maintenant la porte d’entrée unique.

La passerelle authentifiée sur portal.ronova.dev ne dirige chaque Ronova ID que vers les destinations autorisées par ses rôles et ses droits ; un préfixe UID peut préférer une porte, jamais l’accorder.

  • Une destination autorisée redirige directement, plusieurs affichent un lanceur limité aux destinations, et un compte sans droit spécial revient à son espace Ronova ID.
  • ronova.dev gère la connexion canonique et la résolution de l’ID actuelle, id.ronova.dev reste dédié au compte et à la sécurité, et les domaines externes gardent leurs sessions locales avec redirect exact et authorization code plus PKCE S256.
  • L’UID Root System exact reste non interactif, le shell en cache ne contient aucune donnée personnelle et le support peut maintenant router Porta Ronovae.

Le panneau Archon se ferme maintenant par defaut selon l'autorite du principal protege.

Le panneau Archon a acces root complet exige le principal humain Ronova protege, le role owner global, la permission Archon explicite et une session passkey forte; un prefixe d'ID n'accorde rien.

  • Une session absente ou déconnectée revient vers le compte avec une continuation interne fixe; un compte éligible reprend Archon après connexion.
  • L'identite Root System desactivee reste non interactive; chaque ancienne Ronova ID demeure un alias de compatibilite immuable de son principal d'origine.
  • Les surfaces séparées de codes d'accès Archon et de grants de contenu restent hors de la porte du panneau root.

Ronova ID commence maintenant par un choix de connexion plus simple.

Ronova ID ouvre maintenant sur une page de connexion calme : choisir Sign in, saisir un nom ou un UID, puis choisir une passkey ou un mot de passe.

  • La vue d'ensemble publique a été retirée de la route d'identité par défaut ; l'inscription et la récupération restent accessibles dans le flux de connexion.
  • Les Pages Functions sont publiées avec leur source partagée et leur liaison D1, afin que les passkeys indisponibles et les mots de passe refusés renvoient des réponses contrôlées au lieu de pages blanches.
  • La typographie auto-hébergée, le système de couleurs et la frontière universelle Ronova ID restent inchangés.

AI Usage attribue maintenant des Archivements illustrés par Image 2.

La route AI Usage est devenue un registre collectionnable multi-page de conséquences de code mesurables, avec 29 faces de badge Image 2 uniques, leurs variantes de production et un contrat de vérification inter-agents testé.

  • Ajout de 42 routes de profil, collection, famille, détail, badges, méthodologie, vérification, registre et réglages, ainsi que les onze niveaux Tokenburner.
  • Chaque enregistrement dispose désormais de sa propre face PNG Image 2 détourée par chroma key, avec variantes héros, galerie, petite, sociale et verrouillée, y compris The Y-Axis Broke à 300B.
  • Filtres locaux, réglages, aperçus portés, export PNG, six classes de preuve, évaluateur et contrat Ed25519 fonctionnent sans second système de comptes.

Les déploiements exigent désormais un build Ronova neuf.

Le contrat de déploiement reconstruit maintenant le site et revérifie le cycle de vie Ronova ID existant avant que Wrangler puisse publier vers la cible fixe ronova-dev.

  • TypeScript et le contrôle du cycle de vie Ronova ID doivent réussir avant la génération d'un nouveau build statique.
  • Le site reconstruit est validé puis soumis à un dernier contrôle des artefacts numérotés avant toute publication.
  • Un test de contrat sans dépendance verrouille l'ordre des étapes et la cible de production sans modifier l'authentification ni les comptes.

Les statuts publics des projets correspondent maintenant à leur disponibilité vérifiée.

Le répertoire distingue maintenant les travaux publics, en maintenance, en attente de publication et en attente de lancement, afin qu'aucun libellé ni action ne devance une route vérifiée.

  • Le statut de Fundatio suit sa surface canonique restaurée, tandis que Ronova VPN reste en attente de lancement sans action sortante vers un portail.
  • Ronova ID universel reste la seule frontière de compte pour le futur accès VPN; aucun second système de compte n'a été ajouté.
  • Gekka reste actif avec sa prochaine publication en attente de preuve de production; OpenPractice et Casino sont clairement indiqués comme surfaces en maintenance.

Borealis est maintenant publie depuis un dossier source verifie.

Le dossier autonome Borealis Alliance et le generateur de plans de siege sont maintenant la source de verite des deux routes publiques Ronova, avec une liste autorisee verifiee qui bloque toute derive silencieuse des copies.

  • Le dossier, le brief public et les deux plans TSE generes sont synchronises depuis une seule source autonome vers /projects/borealis/ et sa route /alliance/.
  • Les 350 et 700 placements de siege editables, le modele constant a l'echelle 1:50, la typographie locale Yuji Syuku et la presentation au nombre d'or sont conserves.
  • Un contrat de build refuse les fichiers publics manquants, supplementaires ou differents octet par octet, sans modifier la frontiere Ronova ID universelle.

Ronova ID dispose maintenant d'un parcours de recuperation autonome complet.

Ronova ID prend maintenant en charge la creation directe de compte, des codes a usage unique pour recuperer le mot de passe et une voie Support claire lorsqu'une passkey est perdue; les passkeys restent la methode de session forte pour les actions sensibles.

  • Historiquement, l'inscription Ronova ID native generait un UID player legacy a 14 chiffres et montrait les codes de recuperation une seule fois lors de la creation.
  • Ajout d'un reset de mot de passe par code de recuperation a usage unique qui revoque les anciennes sessions avant d'ouvrir une nouvelle session standard.
  • Ajout de routes d'inscription et de recuperation dediees sur id.ronova.dev, avec un relais Support pour les passkeys perdues, sans creer de second systeme de compte.

La connexion Ronova ID suit de nouveau le flux par nom en deux étapes.

Les routes d'authentification en direct ont été rétablies avec leurs Pages Functions, la résolution par nom affiché correspond maintenant au champ d'entrée par nom, et l'hôte d'identité dédié garde les chemins de retour réécrits alignés avec les contrôles passkey et mot de passe.

  • La surface en direct sous `/api/auth/*` et `/api/identity/*` a été rétablie en redéployant le bundle Ronova depuis la racine du projet, afin que les Pages Functions partent avec le build statique.
  • La résolution d'identifiant Ronova ID accepte maintenant un nom affiché exact, pour que le même flux passkey ou mot de passe fonctionne aussi bien qu'avec le handle, l'UID, le nom Gekka migré ou l'e-mail.
  • Les valeurs `data-redirect-to` sont maintenant réécrites aussi pour le HTML de `id.ronova.dev`, afin que les retours passkey et mot de passe restent sur `/` et `/account/` au lieu de retomber vers des chemins `/id/*`.

Ronova ID commence maintenant par une etape nom ou UID.

La page de connexion Ronova ID s'ouvre maintenant sur un seul champ nom ou UID, puis laisse choisir passkey ou mot de passe sans changer la police, la palette ou la frontiere de compte universelle.

  • La connexion par passkey peut maintenant se resserrer sur le handle Ronova, le nom Gekka, l'UID ou l'e-mail saisi avant de demander l'identifiant a l'appareil.
  • Le repli par mot de passe passe a la deuxieme etape au lieu de partager le premier ecran, et un echec mot de passe rouvre la meme etape avec l'identifiant garde localement.
  • L'inscription passe maintenant par le chemin existant de support Ronova et de demande examinee, au lieu d'inventer un deuxieme systeme de compte public.

Le footer Ronova se lit maintenant comme une carte du site plus claire.

Le footer partage maintenant l'identité du site, les routes internes, les destinations externes et les liens de confiance en colonnes plus calmes, pour que les pages publiques se parcourent plus facilement sans ajouter de remplissage.

  • Le sceau officiel regroupe maintenant la ligne de copyright, le repère du site officiel et le choix de langue au même endroit.
  • Les routes internes Ronova et les destinations externes sont maintenant séparées en colonnes distinctes, pour que les pages locales ne rivalisent plus avec les liens sortants.
  • Les liens de confiance restent visibles sur les routes publiques sans changer la frontière Ronova ID universelle ni ajouter de second système de comptes.

Ronova ID avait ajoute la verification e-mail et les prefixes de role UID legacy.

Historiquement, les parametres de compte ont ajoute l'e-mail de verification et les handles Ronova UID legacy a 14 chiffres ont utilise quatre chiffres lies au role au lieu de l'ancien espace universel `1000`.

  • Ajout d'un vrai flux de verification par e-mail avec tokens signes a usage unique, renvoi depuis le compte, et statuts lisibles de succes ou d'expiration.
  • Le passage en e-mail principal demande toujours une adresse verifiee, et la premiere adresse confirmee devient principale automatiquement.
  • Cette classification historique a quatre chiffres ne subsiste que comme historique legacy; les anciens handles `1000` restent des alias de compatibilite immuables.

Travel Evaluation s'ouvre maintenant comme archive publique avec carnet Ronova ID.

La route canonique /projects/travel-evaluation/ ouvre maintenant un site autonome plus calme ou l'archive commence comme une serie de fiches resumees en lecture seule, ou chaque fiche ouvre la table complete au toucher, ou des evaluations Ronova publiees sont deja presentes, et ou la saisie personnelle passe derriere Ronova ID.

  • La page projet Ronova sert maintenant uniquement de surface de lancement : elle mene au site sans embarquer d'aperçu, tandis que le chemin canonique du workbench reste /projects/travel-evaluation/workbench/.
  • Le site garde les memes filtres de classe lounge, lieu, compagnie et qualite pour une archive en lecture seule, mais il commence maintenant par des fiches resumees et n'ouvre la table complete avec points exacts, images et commentaires qu'apres avoir touche un resume.
  • Remplir sa propre evaluation demande la frontiere Ronova ID existante; chaque feuille publiee conserve le principal auteur immuable et un snapshot de sa Ronova ID au moment de la publication.

Travel Evaluation reçoit un workbench plus calme, en style carnet.

Le workbench same-origin sur Ronova est maintenant plus calme et plus personnel : une seule feuille sélectionnée à la fois, des contrôles plus doux, des accents plus clairs et des notes browser-local pour lounges, vols et hôtels.

  • Le workbench browser-local sur /projects/travel-evaluation/workbench/ affiche maintenant une seule feuille choisie tout en gardant l'ajout, les filtres, l'autosave, l'export/import, les instantanés et le scoring.
  • Les champs texte vides utilisent maintenant des placeholders qui disparaissent à la saisie, et la surface sombre du carnet emploie des accents distincts pour First, Gold, Business, Other, ainsi que pour les cabines de vol.
  • La frontière Ronova ID universelle reste intacte : aucune couche de réservation, aucun marché d'avis et aucun second système de comptes.

OpenPractice gagne une couche de mouvement plus calme.

La page projet OpenPractice Toolkit se lit davantage comme une surface de pratique : hero équilibré, petit balancement de métronome et transitions plus discrètes, sans changer les limites du projet.

  • Ajout d'un panneau métronome responsive qui utilise la marque OpenPractice existante et respecte la réduction de mouvement.
  • Les notes projet, le bloc statut et les cartes roadmap sont mieux structurés sur desktop tout en restant lisibles en colonne unique sur mobile.
  • Le cadrage founding phase, local-first, open source et Ronova ID reste intact.

AI Usage devient un projet skill open source.

L'idée d'orchestration d'agents parallèles a maintenant une page projet Ronova et un package public pour coordonner plusieurs agents Codex sans collisions de branches ou de ports.

  • Ajout de /projects/ai-usage/ comme page projet côté Ronova avec lien direct vers le code GitHub.
  • AI Usage rejoint le répertoire Projects, le reel d'accueil, le drawer, la sitemap et le sélecteur de contexte du support chiffré.
  • Le projet reste une couche de skill et de documentation : aucun second système de comptes, aucune autorité de deploy automatique et aucune action de production cachée.

Borealis a redessiné les seatmaps TSE avec un ratio constant de 1:50.

Les seatmaps TSE Rail intégrés ont été reconstruits autour d'un vrai ratio 1:50, de modules de cabine plus nets en vue de dessus et de symboles de sièges bien plus petits inspirés des gros plans, afin que le rapport entre le mobilier et la voiture paraisse plus proche de l'échelle réelle.

  • Le générateur a été remis à un ratio constant de 1:50 pour les empreintes de voiture, de zone et de siège.
  • Les quatre symboles de classe réutilisables ont été redessinés à partir du langage visuel des gros plans fournis, puis réduits nettement à l'intérieur de chaque empreinte mesurée, tout en gardant chaque place éditable et un pod Magna sur deux retourné horizontalement.
  • Les SVG redessinés et le texte Borealis mis à jour ont été resynchronisés vers /projects/borealis/ sous une nouvelle clé d'asset statique partagée, sans ajouter de second système de comptes.

Borealis équilibre maintenant son premier écran sur grand bureau.

La trame élargie du dossier Borealis reçoit maintenant une vraie composition large écran : le texte du hero, le champ du sceau et la bande de repères forment une seule scène au lieu de simplement s'étirer.

  • Ajout d'un état ultra-large où le texte du hero repose sur une piste gauche assumée, tandis que la droite reste réservée au sceau et aux lignes d'ambiance.
  • La bande de repères a été retendue avec un chevauchement un peu plus marqué et un équilibre de colonnes plus calme pour cette scène large.
  • Le comportement desktop ordinaire, tablette et mobile reste intact ; cette composition ne s'active que lorsque l'écran dispose réellement de l'espace nécessaire.

Borealis utilise maintenant une trame de dossier plus large.

Le dossier Borealis direct ne reste plus coincé dans une colonne centrale étroite sur grand écran ; sa trame commune occupe maintenant beaucoup plus de largeur tout en gardant des blocs de texte lisibles.

  • Le plafond de largeur commun a été relevé pour que la navigation, le hero, la bande de chiffres et les sections partagent la même trame élargie.
  • Les titres et paragraphes gardent une mesure locale plus courte à l'intérieur de cette trame afin d'éviter un mur de texte.
  • La clé d'asset statique partagée a été renouvelée pour que /projects/borealis/ et le dossier autonome chargent bien la version élargie au lieu d'une copie étroite en cache.

Borealis affine les icônes de sièges TSE.

Le dossier Borealis contient maintenant des seatmaps TSE Rail éditables où chaque place passager reste modifiable, tandis que le dessin du siège est copié depuis une icône SVG détaillée par classe, inspirée de TSE-8.

  • Reconstruction des SVG Optimized et Compact avec quatre icônes de classe réutilisables copiées dans 700 et 350 groupes de placement éditables.
  • Maintien d'un ratio constant de 1:50 pour les toilettes et points de service dans les deux candidats.
  • L'icône Magna combine siège raccourci, table latérale de même largeur, lignes de panneaux et marqueur de table; un placement Magna sur deux est retourné horizontalement.
  • Les SVG générés et le brief sont livrés avec le dossier Borealis direct sur /projects/borealis/, sans ajouter de second système de comptes.

Les liens de projets sont maintenant concrets.

Les références publiques évitent maintenant les fausses actions : Projets pointe vers l'annuaire, VPN ouvre le portail Triluna, et les entrées exploratoires ne sont plus affichées.

  • La carte officielle Projets pointe vers l'annuaire Ronova.
  • Ronova VPN est relié à `https://vpn.triluna.org/`, tout en gardant Ronova ID universel comme frontière d'identité.
  • Scriptura et Expériences ont été retirées des cartes publiques jusqu'à ce qu'elles disposent d'une destination ou d'une page concrète.

Borealis a maintenant une page projet complète.

La carte Borealis ouvre maintenant directement le dossier HTML complet de Borealis Alliance sur la route Ronova.

  • Le logo Borealis compact intégré dans la page autonome Borealis Alliance a été extrait.
  • Le sceau apparaît dans le reel de projets de la page d'accueil et dans l'annuaire Projets comme arrière-plan CSS à faible opacité.
  • La route /projects/borealis/ devient la route directe du dossier public, tout en conservant la frontière Ronova ID universelle et le cadrage conceptuel.

Ronova VPN passe sur vpn.triluna.org.

Le portail VPN est maintenant enregistré comme client Ronova ID à code de redirection hébergé sur Triluna, plutôt que comme surface de sous-domaine Ronova.

  • Déplacement du registre d'app et de client Ronova ID pour `ronova-vpn` vers `https://vpn.triluna.org`.
  • Le callback VPN utilise maintenant `https://vpn.triluna.org/api/auth/ronova/callback` avec échange par code de redirection.
  • La frontière Ronova ID universelle reste intacte : le VPN utilise les comptes liés existants et n'ajoute pas de second système de comptes.

OpenPractice Toolkit est maintenant listé sur ronova.dev.

Le bootstrap open source de pratique musicale dispose maintenant d'une page projet Ronova publique, d'une carte projet, d'un contexte de support et de routes localisées.

  • Ajout de /projects/open-practice-toolkit/ comme page projet côté Ronova avec lien vers le dépôt GitHub public.
  • OpenPractice Toolkit rejoint le reel d'accueil, le répertoire Projects, la liste projets du drawer, le sitemap et le sélecteur de contexte du support chiffré.
  • Le cadrage reste local-first et open source, sans second système de comptes ni API payante requise pour les fonctions centrales.

Roulette Probability Lab rejoint Casino Statistics.

Le module roulette est maintenant un simulateur pédagogique autonome avec table jouable, roue visible, bille animée, simulations à seed, bots de stratégie et limites sans argent réel.

  • Ajout de /projects/casino/roulette/ comme lab public statique pour analyser les probabilités de la roulette européenne et américaine.
  • Le module reste single-player et offline dans son comportement : aucun paiement, compte, dépôt, retrait ou lien casino.
  • Publication de l'interface demandée, sobre et inspirée matcha, sakura, bois sombre et burgundy, avec valeur attendue, test de biais, debug mode et graphiques.

月影銅円台 ouvre comme module coin pusher Pascal.

Casino Statistics présente maintenant le coin pusher Pascal récursif comme un simulateur physique plus lent avec lift en A-frame, paniers horizontaux, sorties vers la table, entrées nommées, grands plateaux bonus Pascal de taille égale, contrôles compacts et guide blueprint optionnel.

  • Rafraîchissement de /projects/casino/coin-pusher/ pour que le simulateur 3D intégré 月影銅円台 domine le premier écran.
  • Ajout du mouvement continu et échelonné des pièces avec rebonds de contact, trous ordinaires vers la table, levier côté droit vers le panier gauche, courroies diagonales, entrées M/G, couches bonus n=3/n=4/n=5 reliées, petite fourche finale et lancer x10.
  • Les chutes et l'elevator sont plus lents, les pièces visibles passent à 75%, les bonus tombent physiquement depuis G au lieu d'être crédités d'un coup, et un grand texte burgundy apparaît puis se floute.
  • Ajout d'un guide blueprint désactivé par défaut pour tracer chemins exemples, paniers de réception, chutes X et lignes de labels sans changer les résultats seedés ni les gains.
  • La typographie du simulateur utilise uniquement Yuji Syuku, y compris le burst bonus et les labels rendus sur canvas.
  • La limite sans argent réel reste claire : pièces virtuelles seulement, aucun dépôt, retrait ou compte de jeu d'argent.

Casino Statistics ouvre comme simulateur sans argent.

La nouvelle route Casino Statistics explique l'avantage maison avec des jetons virtuels, la valeur attendue et la variance courte avant de futurs modules de jeu.

  • Ajout de /projects/casino/ comme page projet Ronova localisée avec un simulateur jouable à jetons virtuels.
  • Casino Statistics rejoint le répertoire projets, le reel d'accueil, la liste projets du drawer et le routage support chiffré.
  • Le projet reste séparé des flux de compte Ronova ID et des paiements réels.

Archon ancre maintenant les trois racines de sites.

Ronova, Gekka et Triluna partagent maintenant un seul modèle de contrôle owner/root : la gestion normale des comptes reste sur id.ronova.dev, tandis qu'archon.ronova.dev est le seul plan de contrôle root.

  • Ajout d'un registre de racines pour ronova.dev, gekka-harae.com et triluna.org, avec le contrôle root pointé vers archon.ronova.dev.
  • Triluna / Fundatio est enregistré comme client Ronova ID à code de redirection, sans créer de second système de compte.
  • Fundatio / Triluna a été ajouté au routage support, et le tableau Archon owner-only affiche les trois racines publiques.

Les métadonnées de crawl ont maintenant un propriétaire gardé.

La réponse robots.txt vient maintenant d'une Pages Function exacte avec une source partagée, tandis que le dernier écart de cache live est isolé dans une règle de zone Cloudflare.

  • Le texte canonique de robots.txt vit maintenant dans une source partagée entre la Pages Function et les validateurs.
  • Le build empêche public/ et dist/ de réintroduire discrètement un asset robots.txt statique.
  • La dernière preview Pages sert max-age=0; ronova.dev demande encore une modification de règle de cache Cloudflare.

Le menu pointe maintenant vers les projets actifs et le compte.

Le drawer liste les projets actifs sous Projets et ajoute un chemin Compte sous Acces pour les flux de connexion et d'inscription Ronova ID.

  • Les liens Projets du drawer viennent maintenant des cartes projet actives et experimentales au lieu d'un raccourci separe.
  • Acces inclut maintenant Compte et pointe vers la page de compte Ronova ID existante, sans creer de second systeme de compte.
  • AGENTS.md indique maintenant que tout nouveau projet doit aussi etre ajoute aux options de routage du formulaire feedback/support.

Le support chiffré utilise maintenant sa clé de production.

Ronova.dev construit maintenant le formulaire de support avec la vraie clé publique ECDH, garde la clé privée en local et vérifie que le formulaire chiffré ne peut pas être livré discrètement désactivé.

  • PUBLIC_ENCRYPTION_KEY est chargé depuis le JWK public local pendant le build si aucune valeur d'environnement n'est fournie.
  • Le validateur du site généré vérifie maintenant la clé publique P-256 configurée, le bouton d'envoi chiffré et l'absence de matériau privé dans la page.
  • La clé commune des assets statiques a été rafraîchie pour la surface de support déployée.

Les aperçus projet bouclent maintenant un par un.

La section projets de l'accueil contient maintenant tous les projets dans un reel horizontal à carte unique, avec points, ligne d'état et avance automatique toutes les sept secondes.

  • Suppression des boutons visibles et de la barre de défilement, tout en gardant le scroll horizontal naturel.
  • Ajout de points et d'une ligne de projet affiché pour signaler la carte active sans texte d'instruction.
  • Le reel avance toutes les sept secondes et reprend au début.
  • Le logo Gekka Harae et le sceau Fundatio Trilunae deviennent des arrière-plans monochromes discrets dans les cartes projet.

Ronova ID et les textes d'accès sont plus clairs.

Le portail d'identité explique maintenant qui peut recevoir un Ronova ID, affiche des libellés visibles pour le repli par mot de passe et garde les consignes de code d'accès entièrement localisées.

  • Ajout de libellés visibles, d'aides et de messages de validation personnalisés pour la connexion par mot de passe Ronova ID.
  • Précision que Ronova ID est émis par invitation, migration ou demande examinée, sans créer de second système de compte.
  • Localisation des avertissements sur les codes d'accès et lissage des libellés de projet mêlant plusieurs langues.

La formulation féminine reste cohérente dans l'i18n publique.

La copie publique garde les formes féminines de Ronova là où la langue marque le genre, sans modifier Ronova ID ni les flux de compte.

  • Les descriptions allemandes utilisent maintenant les formes féminines pour développeuse, étudiante et créatrice.
  • Les formulations françaises côté Gekka suivent la ligne féminine `créatrice` déjà présente.
  • Les formulations japonaises et chinoises traditionnelles restent naturelles dans leur grammaire non genrée, et le CSV i18n public a été régénéré.

Les UID Ronova ID s'affichent maintenant en groupes.

Historiquement, les surfaces Ronova ID groupaient les handles UID legacy a 14 chiffres sous la forme `UID: 1000 12345 67890`; les routes compte et admin restaient concentrees.

  • Les handles UID sont formates dans les parametres de compte, le controlled Archon, le statut de redemption Archon, le statut de connexion et les labels d'inscription passkey.
  • Les UID bruts restent inchanges pour la recherche de connexion, le stockage et les contrats API.
  • La vue complete Ronova ID reste sur `/id/`; `/id/account/` et `/id/admin/` restent des sous-pages centrees sur la tache.
  • Les boutons utilisent explicitement Yuji Syuku, et les panneaux identite gardent un flux de lecture en une colonne.

Les codes d'acces Archon gerent maintenant invite et Ronova ID.

La surface Archon peut emettre des codes avec limite de places partagee, reservations invite de dix minutes, grants lies au compte Ronova ID, option ID obligatoire et revocation owner.

  • Ajout d'un modele Archon dedie avec codes haches, grants de compte, reservations invite et limites de places imposees par D1.
  • Une redemption anonyme bloque maintenant une place pendant dix minutes au lieu de creer une longue session privee.
  • Une redemption Ronova ID lie l'autorisation au compte pour que ses sessions actives puissent voir le contenu autorise jusqu'a revocation.
  • Le controlled Archon owner-only gere maintenant la distribution, la revocation de codes et la revocation de grants de compte.

Le site public privilégie maintenant une lecture en une colonne.

Les grands layouts publics s'empilent maintenant en une colonne calme sur desktop, tablette et mobile, tandis que les petits contrôles, tags et boutons gardent leur comportement inline.

  • Les split grids, listes projet, entrées devlog, sections du drawer, groupes de footer, panneaux Fundatio et cartes Ronova ID passent en piles à une colonne.
  • La grille desktop large des cartes projet a été retirée pour garder le même rythme de lecture sur l'accueil et les pages projet.
  • Les petites rangées de contrôles, tags, boutons, filtres et choix de formulaire restent flexibles sans transformer le contenu en colonnes.
  • Les routes existantes, Ronova ID, la logique d'accès et la structure i18n sont préservées.

La mise en page publique est devenue plus lisible.

Le site public utilise maintenant un hero plus calme, des cartes projet plus stables, des cartes devlog plus lisibles et des contrôles responsives plus solides, sans changer Ronova ID ni la logique d'accès.

  • Le texte principal du hero d'accueil sort du cadre carte afin de lire plus clairement comme hub de créatrice.
  • Les entrées devlog deviennent des cartes pleine largeur avec rail date/tags et colonne de lecture.
  • L'espacement des cartes projet a été resserré pour garder un chemin de lecture stable.
  • Les titres ne dépendent plus d'une taille viewport et les espacements négatifs de heading ont été retirés.
  • Les actions du formulaire d'accès ont leur propre rangée, plus sûre pour les libellés localisés.

Le login par mot de passe Ronova ID reste dans le flux.

Un echec de connexion par mot de passe ne bloque plus le navigateur sur une page JSON API brute; historiquement, les usernames Gekka se resolvaient avec un UID Ronova legacy explicite a 14 chiffres.

  • Les erreurs de formulaire navigateur reviennent vers Ronova ID avec un statut lisible.
  • Les appels API et fetch recoivent `login-failed` avec un code sur et une cible de redirection.
  • Historiquement, les usernames Gekka ont conserve les credentials legacy, les anciens UIDs a dix chiffres sont devenus des alias UID Ronova legacy explicites a 14 chiffres, et les alias e-mail ont garde le format HMAC Gekka.
  • La limite navigateur de 12 caracteres a ete retiree de la connexion afin que les mots de passe legacy Gekka migres atteignent la verification serveur.
  • La connexion par mot de passe conserve le chemin de continuation d'autorisation pour que les apps inscrites reprennent apres login.

La connexion Gekka passe maintenant sous Ronova ID.

Gekka Account garde les dossiers joueur et les sauvegardes, tandis que l'autorite de connexion appartient maintenant a Ronova ID au lieu d'un second login Gekka.

  • Le pont Gekka Account accepte maintenant les sessions Ronova ID standard pour la connexion ordinaire, y compris le fallback mot de passe gere.
  • Le transfert et les actions sensibles de recuperation restent proteges par une confiance Ronova ID forte, appuyee par passkey.
  • Le langage visible de Gekka Account passe de lien/connexion a transfert de l'autorite de connexion vers Ronova ID.

Le CSV i18n public couvre maintenant les cinq langues.

L'export public des textes puise maintenant les catalogues, shells statiques et libellés visibles d'administration dans des sources localisées pour l'anglais, l'allemand, le français, le japonais et le chinois traditionnel.

  • Les labels du catalogue Ronova ID, les textes de shell statiques, les termes de données structurées, la vCard et les labels de console admin vivent maintenant dans des objets localisés.
  • `ronova-public-i18n.csv` a été régénéré avec 5 548 lignes localisées et aucune entrée de statut anglaise seule.
  • Le drawer et la carte de contact ont été resserrés pour lire comme orientation et confirmation, non comme consigne procédurale.

Ronova ID a maintenant une connexion par mot de passe legacy geree.

La gestion du compte peut definir ou desactiver un mot de passe de secours, retirer une passkey seulement quand un autre moyen existe, et afficher l'historique de connexion.

  • `legacy-password` est disponible pour les comptes qui activent un mot de passe dans la gestion du compte.
  • Les actions Add Passkey et Remove Passkey protegent la derniere methode d'acces restante.
  • La page de compte affiche l'historique des evenements passkey, mot de passe, bridge et logout.

L'action sortante de Fundatio a été resserrée.

La page passerelle Fundatio garde maintenant un seul bouton visible vers triluna.org dans le premier viewport, avec un label externe plus contrasté.

  • Le bouton triluna.org répété a été retiré du panneau latéral afin que le même CTA externe ne se répète plus dans le même champ de vue.
  • Le texte qui explique la relation reste intact; le hero devient le seul passage vers triluna.org.
  • Le chip External des boutons primaires a été renforcé pour rester lisible sur le dégradé lavande et or.

Ronova ID coordonne maintenant les sous-domaines Ronova.

Cette entree conserve une ancienne phase de session partagee. Le basculement host-only par code d'autorisation du 2026-07-18 remplace cette conception.

  • L'ancienne coordination same-site reste dans l'historique de livraison, mais n'est plus l'architecture de session active.
  • `ronova-archon` et `ronova-vpn` sont enregistrés dans le catalogue d'apps/clients d'identité et dans la migration D1.
  • L'entree du 2026-07-18 decrit la session isolee par host et le flux de code a usage unique actuels.

Les sous-domaines Archon et VPN sont maintenant actifs sur Cloudflare.

`archon.ronova.dev` et `vpn.ronova.dev` passent maintenant par Cloudflare Pages au lieu de bloquer sur un DNS manquant.

  • Ajout des routes CNAME proxied nécessaires dans Cloudflare pour les projets Pages Archon et VPN.
  • `archon.ronova.dev` sert le plan de contrôle owner-only avec les headers no-store/noindex.
  • Le bundle Ronova VPN Pages a été redéployé; `vpn.ronova.dev` sert le Ronova VPN Portal et l'hôte pages.dev redirige vers lui.

Fundatio Trilunae vit maintenant sous Projets.

La page d'accueil traite maintenant Fundatio Trilunae comme une entrée de projet plutôt qu'un bandeau séparé, avec un sceau transparent et une page projet côté Ronova.

  • L'entrée Fundatio visible a été déplacée dans la liste de cartes Projets au lieu de rester une section autonome sur l'accueil.
  • La carte pointe vers `/fundatio/` comme description de projet, tandis que `https://triluna.org` reste la destination Fundatio externe.
  • Le sceau sur disque blanc a été remplacé par un sceau transparent rendu directement sur la carte projet.

L'archon controle vit maintenant sur archon.ronova.dev.

Le plan de controle reserve au owner utilise maintenant un sous-domaine dedie; les anciens chemins admin y redirigent et les controles de cles, grants, pages privees, registre et audit restent proteges par passkey.

  • `archon.ronova.dev` est maintenant l'hote canonique du controlled archon; `/id/admin/` et `id.ronova.dev/admin/` y redirigent.
  • Les cles d'acces peuvent etre emises une seule fois, stockees seulement sous forme de keyed hashes, puis revoquees avec leurs sessions privees actives.
  • `/api/admin/archon` est limite a l'hote archon et exige toujours le role owner global plus une session Ronova ID forte appuyee par passkey.

La page Gekka et la navigation overlay ont été simplifiées.

La page projet explique plus vite la limite entre hub de créatrice et site officiel, tandis que le menu overlay devient plus calme, moins dense et plus lisible.

  • Le drawer est maintenant structuré autour de Main, Projects, Access, Language, External et Trust au lieu d'une sitemap lourde.
  • La page Gekka garde Ronova.dev comme contexte de créatrice et renvoie les informations officielles, versions et entrées vers gekka-harae.com.
  • Le footer évite les répétitions et conserve seulement le copyright, la langue, le site officiel du projet et les liens de confiance essentiels.

La porte de deploiement verifie maintenant les cles de cache des assets publics mutables.

Les pages generees echouent maintenant si des scripts publics, styles, images sociales, favicons ou la carte de contact ignorent la version de cache commune.

  • Les pages acces, assistance et carte de contact utilisent maintenant la version statique commune pour leurs assets propres.
  • Le validateur du build scanne chaque fichier HTML genere avant release pour trouver les assets publics mutables non versionnes.
  • La politique statique de headers exige aussi `X-Content-Type-Options: nosniff` sur la carte de contact publique.

Ronova ID protège maintenant les réglages sensibles à la récupération par step-up.

Les réglages de compte liés à la récupération exigent maintenant une session Ronova ID forte, appuyée par passkey, lorsque l'identité demande un step-up.

  • Ajout d'e-mail, changement d'e-mail principal, retrait d'e-mail, désactivation de passkey et révocation d'autres sessions renvoient maintenant `step-up-required` si la session n'est pas forte.
  • L'inscription de passkey et les changements de profil seuls restent disponibles pour que le bootstrap avance sans fallback par mot de passe.
  • Le panneau de compte reflète l'état bloqué et garde la connexion par mot de passe indisponible.

Ronova ID dispose maintenant d'une vraie surface de parametres de compte.

La vue de compte Ronova ID charge maintenant des parametres actifs pour le profil, les e-mails, le statut sans mot de passe, les passkeys, les sessions actives, la recuperation et l'acces aux applications.

  • Ajout d'APIs de parametres authentifiees pour le profil, les adresses e-mail non verifiees, la desactivation de passkey et la revocation des autres sessions.
  • La gestion du mot de passe reste explicitement sans mot de passe : Ronova ID ne cree ni ne stocke de mot de passe.
  • La page de compte Ronova ID contient maintenant un panneau de parametres actif avec scripts et styles cache-bustes.

Ronova ID dispose maintenant d'une connexion passkey active.

Le runtime d'identite a maintenant le stockage des challenges WebAuthn, l'inscription passkey, la connexion passkey et des champs de confiance plus nets dans l'echange de code, afin que les clients entre projets sachent quand une preuve Ronova ID vient d'une passkey verifiee par l'utilisateur.

  • La migration D1 `0004_ronova_passkey_runtime` ajoute les challenges WebAuthn et les metadonnees de passkey.
  • La page de compte Ronova ID propose maintenant la connexion par passkey et l'inscription de passkey, en gardant l'ancienne passerelle comme bootstrap owner etroit.
  • L'echange de code d'autorisation renvoie maintenant des champs de confiance passkey pour la future validation Gekka Account.

Ronova ID devient une couche de compte entre projets.

Le registre d'identité nomme maintenant account.gekka-harae.com comme client propre du Gekka Account Center, donnant au projet Gekka une cible Ronova ID concrete pour la connexion et le transfert de login.

  • Ajout d'une app et d'un client `gekka-account` pour `https://account.gekka-harae.com/api/auth/ronova/callback`.
  • Ajout des permissions `gekka.account.login`, `gekka.account.link` et `gekka.account.recovery` pour séparer l'identité de compte de l'autorité play, Senate et Archon.
  • La note d'architecture explique comment Gekka peut transferer l'autorite de connexion a Ronova ID sans transformer une session Gekka en session privée Ronova.

Ronova ID dispose maintenant d'un vrai plan d'identité partagée.

La note d'architecture Ronova ID décrit maintenant le système d'identité passkey-first prévu pour ronova.dev, id.ronova.dev et les projets liés, avec la direction du schéma D1, la récupération, l'accès privé et le pont de permissions Gekka.

  • Ronova ID est documenté comme plan d'identité central, tandis que chaque application garde sa propre session bornée.
  • Le modèle D1 cible couvre les utilisateurs, passkeys, challenges WebAuthn, codes de récupération, clés d'accès, grants d'application, sessions, tickets et événements d'audit.
  • Les flux de compte Gekka peuvent demander des permissions Ronova, mais les pages privées ronova.dev ne s'ouvrent qu'avec des grants Ronova ID explicites et des tickets courts liés à leur audience.

Les sous-pages ont reçu une passe de finition attentive à la sécurité.

ronova.dev a reçu un raffinement ciblé de la présentation publique et du comportement runtime : le panneau de statut de l'accueil est maintenant localisé, les pages de confiance se lisent plus clairement, les tags du devlog se scannent mieux, et les requêtes Ronova ID suivent le même modèle de corps borné que les anciens endpoints d'accès et d'assistance.

  • Le rail de statut de l'accueil est localisé pour éviter des libellés anglais codés en dur dans les surfaces non anglaises.
  • Le devlog et les pages de confiance ont reçu des tags plus lisibles et des panneaux de notes plus calmes.
  • Le parsing des corps de requête Ronova ID est borné pour JSON et formulaires URL-encodés avant le login, le logout et l'échange de code.

Ronova ID dispose maintenant de sa propre route de sous-domaine.

id.ronova.dev ouvre maintenant le portail Ronova ID existant au lieu de rester une adresse future non reliee.

  • Ajout d'un routage Pages sensible au nom d'hote pour servir la vue centrale, le compte et l'administration depuis `id.ronova.dev`, `/account/` et `/admin/`.
  • `ronova.dev/id/` reste le chemin de secours tandis que le catalogue public des apps declare le nom d'hote dedie a l'identite.
  • La posture noindex et no-store de Ronova ID reste en place, et les chemins sans rapport sur le sous-domaine reviennent vers le site public principal.