Devlog

Ein öffentliches Protokoll dessen, was sich bewegt hat.

Dieses Log bleibt praktisch: was ausgeliefert wurde, was straffer geworden ist und was sich an der öffentlichen Oberfläche verändert hat, ohne zur laufenden Tagebuchform zu werden.

Beim ersten Besuch folgt die Website jetzt der Gerätesprache, wenn keine Seitensprache gespeichert ist.

Wenn im Browser keine Ronova-Seitensprache gespeichert ist, prüft die öffentliche Website die Sprachliste von Browser und Betriebssystem und öffnet die passende englische, deutsche, französische, japanische oder traditionell-chinesische Route.

  • Eine auf der Website gewählte Sprache oder eine ausdrücklich geöffnete lokalisierte Route wird gespeichert und hat Vorrang vor einer späteren Umgebungserkennung.
  • Nicht unterstützte Sprachen bleiben auf Englisch, vereinfachtes Chinesisch wird nicht als traditionelles Chinesisch ausgegeben, und es entsteht kein zusätzlicher Identitäts- oder Kontostatus.

0XX-Institutionskonten haben jetzt eine freiwillige Ehrentafel und einen Courtesy-E-Mail-Ablauf.

Berechtigte menschliche Ronova-ID-Mitglieder koennen ein standardmaessig privates Anerkennungsprofil vorbereiten und genau eine verifizierte @triluna.org-Weiterleitungsadresse beantragen, ohne ein weiteres Konto oder Verwaltungsrechte zu erhalten.

  • Jedes oeffentliche Feld wird getrennt gesteuert; unveroeffentlichte Mitglieder, Zieladressen, interne Notizen, Verifizierungsdaten und Provider-Metadaten bleiben privat.
  • Die E-Mail-Aktivierung bleibt ausstehend, bis ein gepruefter Produktions-Routing-Provider, ein eigener Verschluesselungsschluessel und die Domain-Mailkonfiguration Ende-zu-Ende verifiziert sind.

Archon verwaltet Praefixe und Rollen gewoehnlicher Konten jetzt in einem Kontodashboard.

Archon beginnt jetzt mit einer exakten UID-Suche im Format `XXX XXXXX XXXXX`. Gewoehnliche universelle Ronova-ID-Konten koennen mehrere aus Praefixen abgeleitete IDs gleichzeitig gueltig halten, eine primaere ID waehlen und getrennte Rollenzuweisungen im ausgewaehlten Kontodashboard verwalten.

  • Ein Wechsel des primaeren Praefixes bewahrt die vorherige ID als ausdruecklich aktiven Alias desselben unveraenderlichen Kontos; jede aktive ID loest zu diesem einen Konto auf und gewaehrt selbst keine Berechtigung.
  • Das Dashboard verbindet zugewiesene IDs, Rollen, wirksame Berechtigungen, Sitzungen, Authenticator-Zusammenfassungen, letzte Aktivitaet und UID-Verlauf, ohne E-Mail, Credential-Material, Sitzungshashes oder Audit-Metadaten offenzulegen.
  • Die exakten Konten 000 00000 00000 und 999 99999 99999 erscheinen weder in der Archon-Suche noch in Kontodashboards und bleiben an API-, Koordinator-, Executor- und Datenbankgrenze unveraenderbar.

Omni Archon hat seinen ersten privaten Gekka-Reader erhalten.

Archon kann jetzt eine begrenzte und redigierte Ansicht von Gekka-Governance-Code-Metadaten über einen privaten, Gekka-eigenen Executor durchsuchen. Ronova signiert die Anfrage, der Koordinator ergänzt eine Executor-spezifische Assertion, und Gekka prüft Vertrag und Zielgruppe unabhängig, bevor es die eigene Datenbank liest.

  • Ergebnisse enthalten nur opake Code-IDs, Bezeichnungen, Status, erlaubte Kontexte, Nutzungslimits, Datumsangaben und eine opake Version; Bearer-Werte, Hashes, Fragmente, Grants, Notizen, Akteuridentitäten, Cookies und Zugangsdaten überschreiten die Grenze nie.
  • Code-Erstellung, Widerruf, Wiederherstellung, Rollen, Releases, Notfallsteuerung, Abrechnung und Rohgeheimnisse bleiben deaktiviert, bis ihre projekteigenen Mutations-, Wiederherstellungs- und Freigabeverträge separate Übungen bestanden haben.

Travel Evaluation verwaltet jetzt Ronova-ID-eigene Serverdatensätze.

Travel Evaluation speichert Bewertungen jetzt als serverseitige Datensätze im Besitz einer Ronova ID. Öffentliche Archive laden veröffentlichte Datensätze, während nur der authentifizierte Besitzer eigene Datensätze erstellen, aktualisieren oder löschen kann.

  • Lokale Entwürfe bleiben bis zum ausdrücklichen Speichern durch den Besitzer im Browser; öffentliche Archivabfragen legen keine Entwurfsdaten offen.
  • Bei getippten Änderungen bleibt das aktive Eingabefeld eingebunden, sodass der Fokus während des Speicherns von Datensatzänderungen erhalten bleibt.

Ronova-ID-Anzeigen werden jetzt von einer Autoritaet aufgeloest.

Konto-, Archon- und Travel-Workbench-Oberflaechen rufen die aktuelle veraenderliche Ronova ID jetzt ueber eine authentifizierte No-Store-API auf ronova.dev ab und akzeptieren sie nur, wenn ihr unveraenderlicher Subject zur Sitzung des aufrufenden Hosts passt.

  • Die Anzeigeantwort enthaelt nur den unveraenderlichen Subject, den aktuellen Identitaetsdeskriptor, den Anzeigenamen und die Anmelde-URL; Rollen, Berechtigungen, Zugangsdaten, Sitzungsmaterial und Legacy-Aliasse bleiben verborgen.
  • id.ronova.dev und archon.ronova.dev behalten hostgebundene Sitzungen, loesen die angezeigte ID aber bei ronova.dev auf, auch nach einer Wiederherstellung aus dem Vor-/Zurueck-Cache.
  • Exakte v1-Werte bleiben bis zum Produktions-Cutover sichtbar als Legacy Ronova ID gekennzeichnet; kein alter Praefix wird zu einer erfundenen aktuellen Identitaet umgeschrieben.
  • Eine Ronova ID bleibt ein Identifikator und niemals eine Autorisierung. Geschuetzter Principal, Rolle, Berechtigung, Kontostatus und starke Sitzung werden weiter serverseitig geprueft.

Travel Evaluation behaelt Bearbeitungen an Ort und Stelle und Archive kompakt.

Das Travel-Evaluation-Notizbuch baut sein aktives Blatt bei einer Feldänderung nicht mehr neu auf. Dadurch bleiben Fokus, Scroll-Position und browser-lokaler Entwurf bei aufeinanderfolgender Eingabe erhalten. Erstellen, Flugarchiv, Loungearchiv und Hotelarchiv sind jetzt kompakte Ansichten im selben Dokument statt einer langen gemischten Seite. Die Archiv-Taxonomie nutzt zurückhaltende Klassen- und Kategorieakzente, während Ergebnis-Badges ihre eigene Qualitätsskala behalten.

  • Text-, Metadaten- und Punkteänderungen aktualisieren nur das betroffene Blatt; die Archivfilterung zeichnet erst nach einer kurzen Eingabepause neu, nicht bei jedem Zeichen.
  • Die vier Ansichten sind als Lesezeichen im selben Dokument erreichbar; der Wechsel zwischen privatem Entwurf und Kategoriearchiv lädt nicht neu und verwirft kein eingebundenes Blatt.
  • Lounge-, Hotel- und Flug-Taxonomie tragen nun einen konsistenten Akzent durch Archiv und Editor, während Ergebnislabels eine getrennte, gut unterscheidbare Tonalität verwenden.
  • Das Workbench bleibt browser-lokal hinter der bestehenden Ronova-ID-Grenze; diese Verfeinerung impliziert kein zweites Kontosystem, keine Remote-Datenänderung und keine Bereitstellung.

Universelle Bewegung veröffentlicht und verifiziert.

Diese Produktionsveröffentlichung ergänzt, wo passend, richtungsbezogene Bewegung von oben und unten, gedrücktes Feedback für Bedienelemente und Unterstützung reduzierter Bewegung. Sie wurde auf ronova.dev veröffentlicht und verifiziert.

  • Bekannter Umfang: richtungsbezogene Bewegung von oben und unten, wo passend, gedrücktes Feedback und Unterstützung reduzierter Bewegung.
  • Auf ronova.dev veröffentlicht und verifiziert; es lief keine Remote-D1-Migration und keine Nutzerdatenmutation, und die universelle Ronova-ID-Grenze bleibt erhalten.

Projekt-Siegel teilen jetzt eine ruhige einheitliche Kartenbehandlung.

Das Ronova-Projektverzeichnis und die Startseiten-Karten rendern jedes Projekt-Siegel nun über dieselbe vollständig sichtbare Maske unten rechts: Weiß bei 15 % Deckkraft, innerhalb der Karte statt über die volle Höhe abgeschnitten. Travel Evaluation verwendet nun sein vorhandenes einfarbiges Image-2-Siegel.

  • Alle aktuellen Karten verwenden dasselbe Feld unten rechts für Größe und Abstand; jedes Siegel behält seine eigene Alpha-Silhouette, auch die nicht quadratische Borealis-Marke.
  • Travel Evaluation behält die farbige SVG-Marke für die Projektseite, während die Katalogkarte das vorhandene einfarbige Image-2-Reisesiegel verwendet.
  • Routen, Kontoverhalten, Projektzugriff, Daten und die Ronova-ID-Grenze bleiben unverändert.

Die Community öffnet sich jetzt schneller, und Nachrichten haben einen fokussierten privaten Arbeitsbereich.

Die Community wählt nun für jede Sprache zuerst einen kompakten, lokal gehosteten Yuji-Syuku-Teilsatz und fällt bei seltenen oder von Nutzern eingegebenen Glyphen auf die vollständige lokale Schrift zurück. Private Nachrichten öffnen sich nun als ein einziger raumhoher Arbeitsbereich statt in der öffentlichen Seitengestaltung und bleiben no-store.

  • Nachrichten bündeln Raumleiste, aktive Unterhaltung, Datenschutzhinweis und verschlüsselten Composer in einem fokussierten Fenster; auf dem Telefon werden Raumliste und Unterhaltung zu bewusst getrennten Ansichten.
  • ID-Räume kennzeichnen jede sendende Person als Ronova mit formatierter Ronova ID; Sitzungsräume bleiben bewusst Gast / Sitzungs-ID. Vor dem Erstellen oder Beitreten prüft der Browser E2EE und lokale Schlüsselspeicherung; eine verweigerte dauerhafte Speicherung benötigt eine ausdrückliche Bestätigung.
  • Yuji Syuku bleibt unter der bestehenden OFL-Lizenz vollständig lokal gehostet; sprachspezifische Teilsätze verringern die Übertragungsmenge beim ersten Laden, ohne seltenen Text auszuschließen.
  • Ausdrückliche Release-Versionen erlauben es, öffentliche Styles und Skripte der Community und der gemeinsamen Shell unveränderlich zwischenzuspeichern, statt sie unnötig zu revalidieren.
  • Die unveränderliche Cache-Regel gilt nur für versionierte statische Community- und Shell-Assets. Private Nachrichtendokumente und ihre Verschlüsselungsgrenze bleiben unverändert.

Die Ronova Community unterstützt jetzt direkte Ende-zu-Ende-verschlüsselte Anfragen und eine eigene Gesprächsoberfläche.

Eine Laufzeitreparatur stellt das Laden des öffentlichen Forums und die angemeldete Teilnahme wieder her. Private Sitzungsräume werden korrekt mit einer widerrufbaren Sitzungseinladung eingerichtet; direkte Ende-zu-Ende-verschlüsselte Anfragen können jetzt eine Ronova ID oder ihre deterministische virtuelle Adresse verwenden, ohne die Datenschutzgrenze zu verändern: Eine E-Mail-Adresssuche verrät nicht, ob ein Konto existiert, und die Zustimmung des Empfängers kommt vor Raum-, Geräte- oder Chiffretextzugriff. Die Nachrichtenoberfläche ist nun eine eigenständige Ronova-Gesprächsoberfläche für aktive Chats und kleine Gruppen, mit klarer Absenderzuordnung und Zeitstempeln, ohne eine bekannte Messenger-Oberfläche nachzuahmen.

  • Alle können Forum-Threads lesen; Veröffentlichen, Antworten, Reagieren, Melden und eigene Beiträge entfernen benötigen eine aktive menschliche Ronova-ID-Sitzung. Ein zweites Kontosystem entsteht nicht.
  • Jede Ronova ID hat für die Community die deterministische interne Adresse `[email protected]`. Sie ist kein SMTP-Postfach; das Senden und Empfangen von E-Mails ist standardmäßig deaktiviert.
  • Eine direkte Ende-zu-Ende-verschlüsselte Anfrage kann mit einer Ronova ID oder virtuellen Adresse beginnen. Die E-Mail-Suche bleibt absichtlich mehrdeutig, und vor Raum-, Geräte- oder Chiffretextzugriff ist die Zustimmung des Empfängers erforderlich.
  • Private Sitzungsräume verwenden eine widerrufbare Sitzungseinladung. Der Dienst speichert Chiffretext und begrenzte Betriebsmetadaten, keine lesbaren Nachrichteninhalte.
  • Die erste Version benennt ihre Grenzen offen: keine Anhänge, keine Cloud-Schlüsselwiederherstellung, kein Forward-Secrecy-Versprechen und kein Schutzversprechen für kompromittierte Clients.
  • Nachrichten verwenden eine eigene Ronova-Gesprächsoberfläche für aktive Chats und kleine Gruppen, mit klarer Absenderzuordnung und Zeitstempeln — ohne Präsenzanzeigen, Lesebestätigungen oder Servicezugriff auf Klartext.
  • Community-Layouts werden gestapelt, bevor eine schmale Shell im goldenen Schnitt zu eng wird; die Auswahl eines Themas führt den Fokus zur beschrifteten Diskussionsüberschrift, und der Nachrichtenverlauf kündigt beim Polling keine früheren Nachrichten erneut an.

Omni Archon aktiviert zwei eng begrenzte Ronova-ID-Mutationen.

Der Katalog mit 252 Fähigkeiten bleibt bestehen. Genau zwei Ronova-ID-Mutationen sind nach einer aktionsgebundenen Passkey-Bestätigung nutzbar: eine einzelne Sitzung eines anderen, nicht geschützten Nutzers widerrufen oder den Status eines anderen, nicht geschützten Kontos per Compare-and-swap auf aktiv, gesperrt oder deaktiviert setzen.

  • Das Sperren oder Deaktivieren eines Kontos widerruft zugleich alle aktiven Sitzungen dieses Kontos; weder diese noch die Sitzungsaktion kann den geschützten menschlichen Principal oder das Root System treffen.
  • ronova.dev behaelt die kanonische Anmeldesitzung und die Autoritaet fuer die Identitaetsanzeige; id, portal und archon erhalten getrennte hostgebundene `__Host-`-Sitzungen ueber exakte einmalige Authorization-Code-Callbacks mit signiertem State und PKCE S256.
  • Nur verifizierte E-Mail-Adressen duerfen sich anmelden. Verifizierungswiederholungen sind begrenzt, alte unverifizierte Aliasse eng rueckgewinnbar, und Datenbankregeln schuetzen den letzten menschlichen Zugang sowie den letzten Passkey des geschuetzten Owners.
  • Pages erreicht ausschließlich einen signierten privaten Koordinator und Executor über ein Service Binding. Idempotente Belege, Audit-Einträge und Ressourcensperren werden atomar geschrieben.
  • Nur der geschützte menschliche `000`-Principal darf diese Aktionen ausführen; das `999` Root System bleibt nicht interaktiv. Eine UID autorisiert nie, und die universelle Ronova ID bleibt das einzige Identitätssystem.
  • Die übrigen 250 Mutations- und externen Fähigkeiten – darunter Gekka, VPN, Domains, UID-Lebenszyklus, Freigaben und Rollback, Billing sowie Raw Secrets – bleiben bis zur Prüfung ihrer Executors und Recovery-Drills fail-closed.

Ronova ID verwendet jetzt ein kanonisches dreizehnstelliges Format.

Ronova ID v2 zeigt `AAA XXXXX XXXXX`, bewahrt unveraenderliche Subjects und Zugangsdaten und trennt die kanonische Identitaetsklasse von Berechtigungen.

  • Der geschuetzte menschliche Ronova-Principal ist exakt `000 00000 00000`; seine fruehere ID bleibt dauerhaft als reservierte Historie erhalten.
  • Der deaktivierte Root-System-Principal ist exakt `999 99999 99999` und besitzt kein Passwort, keinen Passkey, Wiederherstellungscode, keine Sitzung und keinen normalen Login-Pfad.
  • Exakt gespeicherte Legacy-IDs bleiben unveraenderliche Aliasse; aktuelle Oberflaechen kopieren dreizehn kompakte Ziffern und zeigen die gruppierte ID ohne Umbruch.

Porta Ronovae ist jetzt die einzige Eingangstuer.

Das authentifizierte Gateway unter portal.ronova.dev fuehrt jede Ronova ID nur zu Zielen, die Rollen und Grants erlauben; ein UID-Praefix darf eine Tuer bevorzugen, aber niemals Zugang verleihen.

  • Ein erlaubtes Ziel oeffnet direkt, mehrere ergeben einen reinen Ziel-Launcher, und ein Konto ohne Sondergrant kehrt zur persoenlichen Ronova ID zurueck.
  • ronova.dev besitzt die kanonische Anmeldung und die Aufloesung der aktuellen ID, id.ronova.dev bleibt fuer Konto und Sicherheit, und externe Bereiche behalten host-lokale Sitzungen mit exakter Redirect-Registrierung und Authorization Code plus PKCE S256.
  • Die exakte Root-System-UID bleibt nicht interaktiv, der Cache-Shell enthaelt keine Personendaten, und Support kann Anfragen zu Porta Ronovae routen.

Das Archon Panel schliesst jetzt ueber geschuetzte Principal-Autoritaet sicher ab.

Das Archon Panel mit vollstaendigem Root-Zugriff verlangt den geschuetzten menschlichen Ronova-Principal, die globale Owner-Rolle, ausdrueckliche Archon-Berechtigung und eine starke Passkey-Sitzung; ein ID-Praefix gewaehrt nichts.

  • Fehlende oder abgemeldete Sitzungen kehren mit einer festen internen Fortsetzung zum Konto zurück; berechtigte Konten setzen Archon nach der Anmeldung fort.
  • Die deaktivierte Root-System-Identitaet bleibt nicht interaktiv; jede fruehere Ronova ID bleibt ein unveraenderlicher Kompatibilitaetsalias ihres urspruenglichen Principals.
  • Die getrennten Archon-Zugangscode- und Content-Grant-Oberflächen bleiben außerhalb des Full-Root-Panel-Gates.

Ronova ID beginnt jetzt mit einer einfacheren Anmeldung.

Ronova ID öffnet jetzt als ruhige Anmeldeseite: Sign in wählen, Namen oder UID eingeben und dann Passkey oder Passwort auswählen.

  • Die öffentliche Übersicht wurde von der Standard-Identitätsroute entfernt; Sign up und Wiederherstellung bleiben neben dem Anmeldefluss erreichbar.
  • Pages Functions werden mit gemeinsamem Quellcode und D1-Bindung veröffentlicht, sodass nicht verfügbare Passkeys und fehlgeschlagene Passwörter kontrollierte Antworten statt leerer Seiten liefern.
  • Die bestehende selbst gehostete Typografie, das Farbsystem und die universelle Ronova-ID-Grenze bleiben unverändert.

AI Usage vergibt jetzt Archivements mit Image-2-Badge-Art.

Die AI-Usage-Route ist jetzt ein mehrseitiges Sammlerregister fuer messbare Coding-Folgen mit 29 einzigartigen Image-2-Badge-Flaechen, Produktionsvarianten und einem getesteten Cross-Agent-Verifier-Vertrag.

  • 42 verschachtelte Profil-, Sammlungs-, Familien-, Detail-, Badge-, Methodik-, Verifier-, Ledger- und Einstellungsrouten sowie alle elf Tokenburner-Stufen wurden ergaenzt.
  • Jeder Datensatz erhielt eine eigene chroma-keyed Image-2-PNG-Flaeche sowie Hero-, Galerie-, Klein-, Social- und Locked-Varianten, einschliesslich des 300B-Hero-Badges The Y-Axis Broke.
  • Lokale Filter, Display-Einstellungen, Wear-Previews, PNG-Export, sechs Verifikationsklassen, Evaluator und Ed25519-Pruefvertrag funktionieren ohne zweites Kontosystem.

Deployments erfordern jetzt einen frischen Ronova-Build.

Der Deployment-Vertrag baut die Website jetzt neu und prüft den bestehenden Ronova-ID-Lebenszyklus erneut, bevor Wrangler auf das feste Ziel ronova-dev veröffentlichen kann.

  • TypeScript und die Prüfung des Ronova-ID-Lebenszyklus müssen vor dem Erzeugen eines neuen statischen Builds bestehen.
  • Die neu gebaute Website wird validiert und abschließend auf nummerierte Artefakte geprüft, bevor eine Veröffentlichung beginnen kann.
  • Ein abhängigkeitenfreier Vertragstest fixiert Reihenfolge und Produktionsziel, ohne Authentifizierung oder Kontoverhalten zu verändern.

Die öffentlichen Projektstatus entsprechen jetzt der geprüften Verfügbarkeit.

Das Projektverzeichnis unterscheidet jetzt öffentliche, gewartete, veröffentlichungsbereite und noch nicht gestartete Arbeit, damit kein Label und keine Aktion einer geprüften Route vorausläuft.

  • Das Fundatio-Label folgt der wiederhergestellten kanonischen Oberfläche; Ronova VPN bleibt ohne ausgehende Portalaktion startausstehend.
  • Die universelle Ronova ID bleibt die einzige Kontogrenze für künftigen VPN-Zugang; es wurde kein zweites Kontosystem hinzugefügt.
  • Gekka bleibt aktiv, während die nächste Veröffentlichung auf Produktionsnachweise wartet; OpenPractice und Casino sind klar als Wartungsflächen markiert.

Borealis wird jetzt aus einem geprueften Quelldossier veroeffentlicht.

Das eigenstaendige Borealis-Alliance-Dossier und der Seatmap-Generator sind jetzt die Quelle fuer beide oeffentlichen Ronova-Routen; eine gepruefte Allowlist verhindert unbemerkte Abweichungen der Spiegel.

  • Dossier, oeffentlichen Brief und beide generierten TSE-Sitzplaene aus einer eigenstaendigen Quelle nach /projects/borealis/ und auf die Route /alliance/ synchronisiert.
  • Alle 350 und 700 editierbaren Sitzplatzierungen, das konstante Zeichenmodell 1:50, die lokale Yuji-Syuku-Typografie und die Gestaltung im goldenen Schnitt bleiben erhalten.
  • Ein Build-Vertrag lehnt fehlende, zusaetzliche oder byteweise abweichende oeffentliche Dateien ab, ohne die universelle Ronova-ID-Grenze zu veraendern.

Ronova ID beginnt jetzt mit einem Schritt fuer Name oder UID.

Die Ronova-ID-Anmeldung oeffnet jetzt zuerst mit einem einzelnen Feld fuer Name oder UID und laesst danach zwischen Passkey und Passwort waehlen, ohne Schrift, Farbpalette oder die universelle Kontogrenze zu aendern.

  • Die Passkey-Anmeldung kann jetzt auf Ronova-Handle, Gekka-Name, UID oder E-Mail eingegrenzt werden, bevor das Geraet nach der passenden Credential fragt.
  • Der Passwort-Fallback liegt jetzt im zweiten Schritt statt direkt auf der ersten Flaeche, und fehlgeschlagene Passwortversuche oeffnen dieselbe Stufe mit lokal bewahrter Kennung erneut.
  • Registrieren fuehrt jetzt in den bestehenden Ronova-Support- und Pruefpfad, statt ein zweites oeffentliches Kontosystem zu erfinden.

Der Ronova-Footer liest sich jetzt wie eine klarere Seitenkarte.

Der gemeinsame Footer trennt jetzt Website-Identitaet, interne Routen, externe Ziele und Vertrauenslinks in ruhigere Spalten, damit sich oeffentliche Seiten leichter scannen lassen, ohne Fuellmaterial hinzuzufuegen.

  • Identitaetssiegel, Copyright-Zeile, offizieller Website-Hinweis und Sprachauswahl bleiben jetzt gesammelt an einer Stelle.
  • Interne Ronova-Routen und externe Ziele stehen jetzt in getrennten Spalten, damit lokale Seiten nicht mehr mit Auswaertslinks konkurrieren.
  • Vertrauenslinks bleiben auf den oeffentlichen Routen sichtbar, ohne die universelle Ronova-ID-Grenze zu veraendern oder ein zweites Kontosystem hinzuzufuegen.

Ronova ID fuehrte E-Mail-Verifizierung und Legacy-UID-Rollenpraefixe ein.

Historisch fuehrten die Kontoeinstellungen Verifizierungs-E-Mails ein, und sichtbare Legacy-Ronova-UID-Handles mit 14 Stellen nutzten rollenbezogene vierstellige Praefixe statt des alten universellen `1000`-Namensraums.

  • Eine echte Verifizierungs-E-Mail-Strecke nutzt signierte Einmal-Tokens, Konto-Resend-Controls und lesbare Erfolgs- oder Ablaufmeldungen.
  • Primaere E-Mail bleibt an verifizierte Adressen gebunden, und die erste bestaetigte Adresse wird automatisch primaer.
  • Diese historische vierstellige Klassifizierung bleibt nur als Legacy-Historie erhalten; alte `1000`-Handles bleiben unveraenderliche Kompatibilitaets-Aliasse.

Travel Evaluation oeffnet jetzt als oeffentliches Archiv mit Ronova-ID-Notizbuch.

Die kanonische Route /projects/travel-evaluation/ verlinkt jetzt auf eine ruhigere eigenstaendige Website, auf der das Archiv als read-only Zusammenfassungen startet, jede Zusammenfassung per Tippen die volle Bewertungstabelle oeffnet, veroeffentlichte Ronova-Bewertungen bereits enthalten sind und persoenliches Ausfuellen hinter Ronova ID liegt.

  • Die Ronova-Projektseite dient jetzt nur noch als Startflaeche: Sie verlinkt auf die Website statt eine Vorschau einzubetten, waehrend der kanonische Workbench-Pfad /projects/travel-evaluation/workbench/ bleibt.
  • Die Website behaelt dieselben Filter fuer Lounge-Klasse, Ort, Airline und Qualitaet fuer ein read-only Archiv, startet jetzt aber nur mit Zusammenfassungs-Karten und oeffnet die volle Tabelle mit exakter Punktevergabe, Bildern und Kommentaren erst nach dem Antippen einer Zusammenfassung.
  • Persoenliche Bewertungen auszufuellen verlangt die bestehende Ronova-ID-Grenze; jedes veroeffentlichte Blatt bewahrt den unveraenderlichen Autor-Principal und einen Ronova-ID-Snapshot zum Veroeffentlichungszeitpunkt.

Travel Evaluation bekommt eine ruhigere Workbench im Notizbuchstil.

Die same-origin Ronova-Workbench wirkt jetzt ruhiger und persoenlicher: jeweils nur ein ausgewaehltes Blatt, sanftere Controls, klarere Akzente und browser-lokale Reisenotizen fuer Lounges, Fluege und Hotels.

  • Die browser-lokale Workbench unter /projects/travel-evaluation/workbench/ zeigt jetzt jeweils nur ein ausgewaehltes Blatt und behaelt Hinzufuegen, Filter, Autosave, Export/Import, Snapshots und Scoring bei.
  • Leere Textfelder starten jetzt mit verschwindenden Platzhaltern statt Startfuellungen, und die dunkle Notizbuchoberflaeche nutzt Klassenakzente fuer First, Gold, Business und Other sowie passende Flugkabinenbaender.
  • Die universelle Ronova-ID-Grenze bleibt erhalten: keine Buchungsschicht, kein Review-Marktplatz und kein zweites Kontosystem.

OpenPractice hat jetzt eine ruhigere Bewegungsschicht.

Die OpenPractice-Toolkit-Projektseite liest sich jetzt stärker wie eine Übungsfläche: balancierter Hero, kleine Metronom-Bewegung und ruhigere Übergänge, ohne die Projektgrenzen zu ändern.

  • Ein responsives Metronom-Panel nutzt das bestehende OpenPractice-Zeichen und respektiert reduzierte Bewegung.
  • Projektnotizen, Statusblock und Roadmap-Karten sind auf Desktop strukturierter, bleiben mobil aber einspaltig und gut lesbar.
  • Founding-Phase, local-first, Open Source und Ronova-ID-Grenze bleiben unverändert.

AI Usage ist jetzt ein Open-Source-Skill-Projekt.

Der Parallel-Agent-Orchestration-Gedanke hat nun eine Ronova-Projektseite und ein oeffentliches Skill-Paket, damit mehrere Codex-Agenten ohne gemeinsame Branch- oder Port-Kollisionen arbeiten koennen.

  • /projects/ai-usage/ wurde als Ronova-Projektseite mit direktem GitHub-Quelllink ergaenzt.
  • AI Usage steht jetzt im Projektverzeichnis, Homepage-Reel, Drawer-Projektmenue, in der Sitemap und im verschluesselten Support-Kontext.
  • Das Projekt bleibt Skill- und Dokumentationsschicht: kein zweites Kontosystem, keine automatische Deploy-Berechtigung und keine versteckten Produktionsaktionen.

Borealis hat die TSE-Sitzplaene mit konstantem Massstab 1:50 neu gezeichnet.

Die eingebetteten TSE-Rail-Sitzplaene wurden um einen echten 1:50-Zeichnungsmassstab, klarere Draufsicht-Module und deutlich kleinere, von den Nahaufnahmen abgeleitete Sitzsymbole herum neu aufgebaut, damit das Verhaeltnis von Mobiliar zu Wagen naeher an der realen Groesse liegt.

  • Der Generator wurde auf ein konstantes 1:50-Verhaeltnis fuer Wagen-, Zonen- und Sitz-Footprints zurueckgesetzt.
  • Die vier wiederverwendbaren Klassensymbole wurden aus der gelieferten Nahaufnahme-Sprache neu gezeichnet und innerhalb jedes gemessenen Footprints deutlich kleiner eingesetzt; jeder Fahrgastplatz bleibt editierbar und jede zweite Magna-Platzierung wird weiterhin horizontal gespiegelt.
  • Die neu gestalteten SVGs und der aktualisierte Borealis-Text wurden unter /projects/borealis/ mit einem frischen gemeinsamen Static-Asset-Key synchronisiert, ohne ein zweites Kontosystem einzufuehren.

Borealis balanciert die erste Ansicht jetzt auf breiten Desktops.

Die breitere Borealis-Dossier-Huelle hat jetzt eine echte Wide-Screen-Komposition: Hero-Text, Siegelfeld und Kennzahlenleiste bilden eine gemeinsame Buehne, statt nur weiter auseinandergezogen zu werden.

  • Es gibt nun einen Ultra-Wide-Layoutzustand, in dem der Hero-Text bewusst auf einer linken Spur sitzt, waehrend die rechte Seite fuer Siegel und atmosphaerische Linien reserviert bleibt.
  • Die Kennzahlenleiste wurde mit etwas staerkerer Ueberlappung und ruhigerer Spaltenbalance fuer die breite Desktop-Buehne nachjustiert.
  • Normales Desktop-, Tablet- und Mobilverhalten bleibt unveraendert; die neue Komposition greift nur, wenn das Viewport wirklich genug Raum bietet.

Borealis nutzt jetzt eine breitere Dossier-Huelle.

Das direkte Borealis-Dossier sitzt auf grossen Bildschirmen nicht mehr in einer schmalen Mittelspalte; die gemeinsame Huelle nutzt jetzt deutlich mehr Seitenbreite, waehrend die Textlaengen lesbar bleiben.

  • Die gemeinsame Breitenbegrenzung wurde angehoben, sodass Navigation, Hero, Kennzahlenleiste und Abschnittsbaender dieselbe breitere Huelle verwenden.
  • Ueberschriften und Absaetze bleiben innerhalb dieser Huelle lokal begrenzt, damit die Seite angenehm lesbar bleibt und nicht zur Textwand wird.
  • Der gemeinsame Static-Asset-Key wurde erhoeht, damit /projects/borealis/ und das Standalone-Dossier die breitere Fassung laden statt eine schmale Cache-Kopie festzuhalten.

Borealis hat die TSE-Sitzicons verfeinert.

Das Borealis-Dossier enthält jetzt editierbare TSE-Rail-Sitzpläne, bei denen jeder Fahrgastplatz editierbar bleibt, während die Sitzgrafik aus einem detaillierten, von TSE-8 inspirierten SVG-Sitzicon pro Klasse kopiert wird.

  • Optimized und Compact wurden mit vier wiederverwendbaren Klassen-Icons neu aufgebaut, die in 700 beziehungsweise 350 editierbare Platzierungsgruppen kopiert werden.
  • Lavatories und Servicepunkte folgen in beiden Kandidaten einem konstanten Fahrgastverhältnis von 1:50.
  • Das Magna-Icon hat einen verkürzten Sitz, einen gleich breiten Seitentisch, Panel-Linien und Tischmarker; jede zweite Platzierung ist horizontal gespiegelt.
  • Die generierten SVG-Zeichnungen und der Brief liegen jetzt beim direkten Borealis-Dossier unter /projects/borealis/; es wurde kein zweites Kontosystem ergänzt.

Projektverweise wurden konkret.

Öffentliche Links und Projektkarten vermeiden jetzt falsche Aktionen: Projekte führt ins Verzeichnis, VPN öffnet das Triluna-Portal, und experimentelle Karten erscheinen nicht mehr im Verzeichnis.

  • Die offizielle Projektreferenz-Karte verweist jetzt auf das Projektverzeichnis.
  • Ronova VPN ist mit `https://vpn.triluna.org/` verbunden, ohne die universelle Ronova-ID-Grenze aufzuweichen.
  • Scriptura und Experimente wurden aus den öffentlichen Projektkarten entfernt, bis konkrete Ziele oder Seiten existieren.

Borealis hat jetzt eine vollständige Projektseite.

Die Borealis-Karte öffnet jetzt eine Ronova-Projektseite mit eingebettetem vollständigem Borealis-Alliance-HTML-Dossier.

  • Das kompakte eingebettete Borealis-Logo wurde aus der eigenständigen Borealis-Alliance-Seite übernommen.
  • Das Siegel erscheint im Homepage-Projektreel und im Projektverzeichnis als zurückhaltender CSS-Hintergrund.
  • Die Route /projects/borealis/ wurde als öffentliche Projektbeschreibung ergänzt, während Ronova ID die einzige Identitätsgrenze bleibt und Borealis als Konzept statt Live-Service gerahmt wird.

Ronova VPN ist auf vpn.triluna.org umgezogen.

Das VPN-Portal ist jetzt als Triluna-gehosteter Ronova-ID-Redirect-Code-Client registriert statt als Ronova-Subdomain-Oberflaeche.

  • Die Ronova-ID-App- und Client-Registry fuer `ronova-vpn` wurde auf `https://vpn.triluna.org` verschoben.
  • Der VPN-Callback nutzt jetzt `https://vpn.triluna.org/api/auth/ronova/callback` mit Redirect-Code-Austausch.
  • Die universelle Ronova-ID-Grenze bleibt erhalten: Das VPN nutzt bestehende verknuepfte Kontodatensaetze und fuegt kein zweites Kontosystem hinzu.

Ronova ID hat jetzt einen vollstaendigen Self-Service-Wiederherstellungsweg.

Ronova ID unterstuetzt jetzt direkte Kontoerstellung, einmalige Wiederherstellungscodes fuer die Passwort-Wiederherstellung und einen klaren Support-Weg bei verlorenem Passkey; Passkeys bleiben die starke Sitzungsmethode fuer sensible Aktionen.

  • Historisch erzeugte die First-Party-Ronova-ID-Registrierung eine Legacy-Player-UID mit 14 Stellen und zeigte Wiederherstellungscodes nur bei der Erstellung.
  • Einmaliger Wiederherstellungscode-Reset fuer Passwoerter hinzugefuegt, der alte Sitzungen widerruft und danach eine neue Standardsitzung erstellt.
  • Eigene Sign-up- und Recovery-Routen auf id.ronova.dev samt Support-Uebergabe fuer verlorene Passkeys hinzugefuegt, ohne ein zweites Kontosystem einzufuehren.

Ronova-ID-Anmeldung folgt wieder dem gestuften Namens-Start.

Die Live-Auth-Routen wurden mitsamt ihren Pages Functions wiederhergestellt, die Anzeigenamen-Aufloesung passt jetzt zum gestuften Namensfeld, und der dedizierte Identity-Host haelt die umgeschriebenen Rueckwege mit den Passkey- und Passwort-Steuerelementen synchron.

  • Die Live-Oberflaeche unter `/api/auth/*` und `/api/identity/*` wurde wiederhergestellt, indem das Ronova-Bundle vom Projektwurzelpfad neu deployed wurde, sodass Pages Functions zusammen mit dem statischen Build ausgeliefert werden.
  • Die Ronova-ID-Identifier-Aufloesung akzeptiert jetzt auch einen exakten Anzeigenamen, damit derselbe gestufte Passkey-/Passwort-Fluss wie bei Handle, UID, migriertem Gekka-Namen oder E-Mail funktioniert.
  • Die `data-redirect-to`-Werte werden fuer `id.ronova.dev`-HTML jetzt ebenfalls umgeschrieben, damit Passkey- und Passwort-Rueckwege auf `/` und `/account/` bleiben statt auf Ersatzpfade unter `/id/*` auszuweichen.

OpenPractice Toolkit ist jetzt auf ronova.dev gelistet.

Der Open-Source-Bootstrap fuer Musikuebung hat jetzt eine oeffentliche Ronova-Projektseite, eine Projektkarte, Support-Routing und lokalisierte Routen.

  • /projects/open-practice-toolkit/ wurde als Ronova-Projektseite mit Link zum oeffentlichen GitHub-Repository ergaenzt.
  • OpenPractice Toolkit steht jetzt im Homepage-Projektreel, in der Projektuebersicht, im Drawer-Projektmenue, in der Sitemap und im verschluesselten Support-Kontext.
  • Die Darstellung bleibt local-first und open-source, ohne zweites Kontosystem oder bezahlte API-Pflicht fuer Kernfunktionen.

Roulette Probability Lab landet unter Casino Statistics.

Das Roulette-Modul ist jetzt ein eigenständiger Lernsimulator mit spielbarem Tisch, sichtbarem Rad, rollender Kugel, Seed-Simulationen, Strategiebots und No-Money-Grenzen.

  • /projects/casino/roulette/ wurde als statisches öffentliches Labor fuer europäische und amerikanische Roulette-Wahrscheinlichkeiten ergänzt.
  • Das Modul bleibt single-player und offline im Verhalten: keine Zahlungen, keine Konten, keine Einzahlungen, keine Auszahlungen und keine Casino-Verbindung.
  • Die gewünschte ruhige Matcha-, Sakura-, Dark-Wood- und Burgundy-Oberfläche ist mit Erwartungswert, Bias-Tests, Debug-Modus und Diagrammen veröffentlicht.

月影銅円台 startet als Pascal-Coin-Pusher-Modul.

Casino Statistics zeigt den rekursiven Pascal-Coin-Pusher jetzt als langsameren physischen Simulator mit A-Frame-Gurtlift, ebenen Körben, Tischablauf, Eingängen, größeren gleich skalierten Bonus-Pascal-Boards, kompakten Münz-Controls und optionalem Blueprint-Guide.

  • /projects/casino/coin-pusher/ wurde so aufgefrischt, dass der eingebettete 3D-Simulator 月影銅円台 den ersten Bildschirm prägt.
  • Ergänzt wurden kontinuierlich gestaffelte Münzbewegung mit Kontakt-Bounces, normale Löcher mit Tischablauf, ein rechter Hebel in den linken Liftkorb, diagonale Gurte, M/G-Eingänge, verbundene n=3/n=4/n=5-Bonuslagen, eine kleine Endgabel und ein 10-Muenzen-Wurf.
  • Fallbewegung und Elevator-Reise wurden verlangsamt, sichtbare Münzen auf 75% skaliert, Bonusgutschriften als physische G-Entry-Drops ausgespielt und ein großer burgundy Bonus-Burst hinzugefügt, der weich verwischt.
  • Ergänzt wurde ein standardmäßig ausgeschalteter Blueprint-Guide, der Beispielpfade, Fangkoerbe, X-Rinnen und Label-Linien zeigt, ohne Seed-Ergebnisse oder Auszahlungen zu verändern.
  • Die Simulator-Typografie nutzt nur noch Yuji Syuku, inklusive Bonus-Burst und canvas-gerenderten Board-Labels.
  • Die No-Money-Grenze bleibt erhalten: nur virtuelle Kupfermuenzen, keine Einzahlungen, keine Auszahlungen, kein Glücksspielkonto.

Casino Statistics startet als Simulator ohne echtes Geld.

Die neue Projektseite Casino Statistics erklärt House Edge mit virtuellen Chips, Erwartungswert und kurzfristiger Varianz, bevor spätere Spielmodule ergänzt werden.

  • /projects/casino/ wurde als lokalisierte Ronova-Projektseite mit spielbarem Virtual-Chip-Simulator ergänzt.
  • Casino Statistics wurde in Projektverzeichnis, Homepage-Reel, Drawer-Projektliste und verschlüsseltes Support-Routing aufgenommen.
  • Das Projekt bleibt getrennt von Ronova-ID-Kontoflüssen und echten Zahlungen.

Archon verankert jetzt die drei Website-Roots.

Ronova, Gekka und Triluna teilen jetzt ein Owner-/Root-Control-Modell: normale Kontoverwaltung bleibt auf id.ronova.dev, während archon.ronova.dev die einzige Root-Control-Ebene ist.

  • Eine Website-Root-Registry fuer ronova.dev, gekka-harae.com und triluna.org zeigt root control auf archon.ronova.dev.
  • Triluna / Fundatio ist als Ronova-ID-Redirect-Code-Client registriert, ohne ein zweites Kontosystem zu erzeugen.
  • Fundatio / Triluna wurde ins Support-Routing aufgenommen und das owner-only Archon-Dashboard zeigt die drei public roots.

Crawl-Metadaten haben jetzt einen geschuetzten Owner.

Die robots.txt-Antwort kommt jetzt aus einer exakten Pages Function mit gemeinsamer Quelle; die verbleibende Live-Cache-Abweichung ist auf eine Cloudflare-Zonenregel eingegrenzt.

  • Der kanonische robots-Text liegt jetzt in einer gemeinsamen Quelle, die Pages Function und Validatoren nutzen.
  • Der Build verhindert jetzt, dass public/ oder dist/ still wieder ein statisches robots.txt-Asset einfuehren.
  • Die neueste Pages-Preview liefert max-age=0; ronova.dev braucht noch eine Aenderung der Cloudflare-Zonen-Cache-Regel.

Das Menue zeigt jetzt aktive Projekte und Account.

Der Drawer listet aktive Projekteintraege unter Projekte und ergaenzt unter Zugang einen Account-Pfad fuer Ronova-ID-Anmeldung und Registrierung.

  • Die Projektlinks im Drawer kommen jetzt aus den aktiven und experimentellen Projektkarten statt aus einem getrennt gepflegten Shortcut.
  • Zugang enthaelt jetzt Account und fuehrt zur bestehenden Ronova-ID-Kontoseite, ohne ein zweites Kontosystem zu erzeugen.
  • AGENTS.md haelt jetzt fest, dass neue Projekte auch in die Routing-Optionen des Feedback-/Supportformulars aufgenommen werden muessen.

Der verschlüsselte Support nutzt jetzt den Produktionsschlüssel.

Ronova.dev baut das Supportformular jetzt mit dem echten öffentlichen ECDH-Schlüssel, hält den privaten Schlüssel lokal und prüft, dass das verschlüsselte Formular nicht still deaktiviert ausgeliefert wird.

  • PUBLIC_ENCRYPTION_KEY wird beim Site-Build aus dem lokalen öffentlichen JWK geladen, wenn kein Umgebungswert gesetzt ist.
  • Der Built-Site-Validator prüft jetzt den konfigurierten P-256-Public-Key, den verschlüsselten Submit-Button und fehlendes privates Schlüsselmaterial in der Seite.
  • Der gemeinsame Static-Asset-Key wurde für die ausgelieferte Supportfläche aktualisiert.

Projektvorschauen laufen jetzt einzeln weiter.

Die Projektsektion der Startseite enthält jetzt alle Projekte in einem horizontalen Ein-Karten-Reel mit Punkten, Statuszeile und Sieben-Sekunden-Automatik.

  • Sichtbare Carousel-Buttons und Scrollbar entfernt, horizontales Scrollen bleibt natürlich möglich.
  • Punkte und eine Aktuell-Zeile zeigen die aktive Karte ohne Erklärungstext.
  • Das Reel springt alle sieben Sekunden weiter und beginnt danach wieder von vorn.
  • Gekka-Harae-Logo und Fundatio-Trilunae-Siegel liegen jetzt als zurückhaltende einfarbige Hintergründe in den Projektkarten.

Ronova ID und Zugangstexte sind klarer.

Das Identitätsportal erklärt jetzt, wer eine Ronova ID erhalten kann, beschriftet die Passwort-Fallback-Felder sichtbar und hält Zugangscode-Hinweise vollständig lokalisiert.

  • Sichtbare Labels, Hilfetexte und eigene Validierungsmeldungen für die Ronova-ID-Passwortanmeldung ergänzt.
  • Klargestellt, dass Ronova ID per Einladung, Migration oder geprüfter Anfrage vergeben wird, ohne ein zweites Kontosystem einzuführen.
  • Zugangscode-Warnhinweise lokalisiert und gemischte Projektlabels auf der öffentlichen Website geglättet.

Öffentliche Rollenformulierungen sind jetzt einheitlich.

Die öffentliche i18n-Kopie nutzt für Ronova überall dort feminine Rollenformen, wo die Sprache grammatisches Geschlecht markiert; Ronova ID und Kontoflüsse bleiben unverändert.

  • Deutsche Beschreibungen verwenden nun Entwicklerin, Studentin und Schöpferin.
  • Französische Gekka-Formulierungen folgen der bestehenden `créatrice`-Linie.
  • Japanische und traditionell-chinesische Rollenformulierungen bleiben in ihrer natürlichen, nicht gegenderten Grammatik erhalten; die öffentliche i18n-CSV wurde neu gebaut.

Ronova-ID-UIDs werden jetzt gruppiert angezeigt.

Historisch gruppierten sichtbare Ronova-ID-Oberflaechen Legacy-UID-Handles mit 14 Stellen als `UID: 1000 12345 67890`; Konto- und Admin-Routen blieben fokussiert.

  • UID-Handles werden in Kontoeinstellungen, controlled Archon, Archon-Redemption-Status, Sign-in-Status und Passkey-Enrollment-Labels formatiert.
  • Rohwerte fuer UID bleiben fuer Login-Lookup, Speicherung und API-Vertraege unveraendert.
  • Die vollstaendige Ronova-ID-Uebersicht bleibt auf `/id/`; `/id/account/` und `/id/admin/` bleiben auf ihre Aufgaben konzentriert.
  • Button-Controls nutzen explizit Yuji Syuku, und Identity-Panels bleiben in einer einspaltigen Lesefuehrung.

Archon-Zugriffscodes unterstuetzen jetzt Gast- und Ronova-ID-Einloesung.

Die Archon-Oberflaeche kann Codes mit gemeinsamem Sitzlimit, zehnminuetigen Gastreservierungen, accountgebundenen Ronova-ID-Freigaben, optionaler ID-Pflicht und Owner-Widerruf ausgeben.

  • Ein eigenes Archon-Code-Modell mit gehashten Codes, Account-Freigaben, Gastreservierungen und D1-erzwungenen Sitzlimits wurde hinzugefuegt.
  • Anonyme Einloesung blockiert jetzt einen Sitz fuer zehn Minuten, statt eine lange private Sitzung zu erstellen.
  • Ronova-ID-Einloesung bindet die Freigabe an den Account, sodass aktive Sitzungen dieses Accounts autorisierte Inhalte sehen koennen, bis Archon sie widerruft.
  • Der owner-only controlled Archon erhielt Steuerung fuer Ausgabe, Code-Widerruf und Widerruf einzelner Account-Freigaben.

Die oeffentliche Website liest jetzt konsequent einspaltig.

Grosse oeffentliche Layouts stapeln sich nun auf Desktop, Tablet und Mobile in einer ruhigen Lesespalte; kleine Controls, Tags und Buttons duerfen weiterhin inline bleiben.

  • Split-Grids, Projektlisten, Devlog-Eintraege, Drawer-Sektionen, Footer-Gruppen, Fundatio-Panels und Ronova-ID-Karten wurden einspaltig gestapelt.
  • Das breite Desktop-Raster fuer Projektkarten ist entfernt, damit Projektseiten und Startseiten-Auszug denselben Leserhythmus behalten.
  • Kleine Control-Zeilen wie Tags, Buttons, Filter und Formularauswahl bleiben flexibel, ohne Seiteninhalte in Spalten zu ziehen.
  • Bestehende Routen, Ronova ID, Access-Logik und i18n-Struktur bleiben unveraendert.

Das oeffentliche Website-Layout wurde lesbarer.

Die oeffentliche Seite nutzt jetzt eine ruhigere Hero-Struktur, stabilere Projektkarten, lesbarere Devlog-Karten und robustere responsive Controls, ohne Ronova ID oder Access-Logik zu aendern.

  • Der Haupt-Hero der Startseite ist nicht mehr als gestapelte Karte gefasst, sondern liest sich direkter als Schöpferinnen-Hub.
  • Devlog-Eintraege wurden zu breiten Karten mit Datum/Tags-Schiene und lesbarer Inhalts-Spalte umgebaut.
  • Die Abstaende der Projektkarten wurden beruhigt, damit der Lesepfad stabil bleibt.
  • Viewport-skalierte Ueberschriften wurden durch ruhigere responsive Stufen ersetzt; negative Buchstabenabstaende in Headings sind entfernt.
  • Access-Formularaktionen haben eine eigene Button-Zeile, damit lokalisierte Buttontexte stabiler umbrechen.

Ronova-ID-Passwortlogin bleibt jetzt im Login-Fluss.

Fehlgeschlagene Passwort-Anmeldung laesst den Browser nicht mehr auf einer rohen API-JSON-Seite stehen; migrierte Gekka-Usernamen wurden historisch neben einer ausdruecklichen Legacy-Ronova-UID mit 14 Stellen aufgeloest.

  • Browser-Formularfehler fuehren zurueck zu Ronova ID mit lesbarer Statusmeldung.
  • API- und Fetch-Aufrufe erhalten `login-failed` mit sicherem Statuscode und Redirect-Ziel.
  • Historisch importierte Gekka-Usernamen behielten Legacy-Passwortdaten; alte zehnstellige UIDs wurden zu ausdruecklichen Legacy-Ronova-UID-Aliassen mit 14 Stellen und E-Mail-Aliasse behielten Gekkas HMAC-Lookup-Format.
  • Die reine Browser-Grenze von 12 Zeichen wurde aus der Anmeldung entfernt, damit migrierte Gekka-Legacy-Passwoerter die Serverpruefung erreichen.
  • Passwort-Anmeldung behaelt den urspruenglichen Autorisierungs-Continue-Pfad, damit registrierte Apps nach dem Login fortsetzen koennen.

Die Gekka-Anmeldung landet jetzt unter Ronova ID.

Gekka Account behaelt Spielerakten und Speicherstaende, waehrend die Anmeldung jetzt Ronova ID gehoert statt einem zweiten Gekka-Login.

  • Die Gekka-Account-Bruecke akzeptiert jetzt Standard-Ronova-ID-Sitzungen fuer normale Anmeldung, einschliesslich des verwalteten Passwort-Fallbacks.
  • Transfer und wiederherstellungssensible Aktionen bleiben hinter starker passkey-gestuetzter Ronova-ID-Vertrauensstufe.
  • Sichtbare Gekka-Account-Sprache wurde von Verbinden/Verknuepfen auf Login-Uebertragung zu Ronova ID umgestellt.

Die öffentliche i18n-CSV deckt jetzt alle fünf Sprachen ab.

Der öffentliche Textexport bezieht Katalog-, statische Shell- und sichtbare Admin-Texte jetzt aus lokalisierten Quellen für Englisch, Deutsch, Französisch, Japanisch und Traditionelles Chinesisch.

  • Ronova-ID-Kataloglabels, statische Shell-Texte, Structured-Data-Begriffe, vCard-Text und Admin-Konsolenlabels liegen jetzt in lokalisierten Quellobjekten.
  • `ronova-public-i18n.csv` wurde mit 5.548 lokalisierten Zeilen und ohne englisch-only Statuszeilen neu erzeugt.
  • Drawer- und Kontaktkarten-Sprache wurde gestrafft, damit öffentliche Wege wie Orientierung und Bestätigung wirken, nicht wie Arbeitsschritte.

Ronova ID hat jetzt einen verwalteten Legacy-Passwort-Login.

Die Kontoverwaltung kann einen Passwort-Fallback setzen oder deaktivieren, Passkeys nur mit weiterer Zugangsmethode entfernen und die Login-Historie anzeigen.

  • `legacy-password` wurde fuer Konten ergaenzt, die in der Kontoverwaltung ein Passwort aktivieren.
  • Add Passkey und Remove Passkey sind jetzt Kontoaktionen mit Schutz fuer die letzte Zugangsmethode.
  • Die Kontoansicht zeigt Login-Historie fuer Passkey-, Passwort-, Bridge- und Logout-Ereignisse.

Die ausgehende Fundatio-Aktion wurde gestrafft.

Die Fundatio-Bruecke zeigt im ersten Viewport nur noch einen sichtbaren triluna.org-Button und staerkt den Kontrast des External-Labels.

  • Der wiederholte triluna.org-Button wurde aus dem Seitenpanel entfernt, damit derselbe externe CTA nicht doppelt im selben Blickfeld erscheint.
  • Der Beziehungstext der Seite bleibt erhalten; der Hero bleibt die einzige Uebergabe zu triluna.org.
  • Der External-Chip auf Primary-Buttons wurde kontrastreicher gemacht, damit er auf dem Lavendel-Gold-Verlauf klar lesbar bleibt.

Ronova ID koordiniert jetzt die Ronova-Subdomains.

Dieser Eintrag dokumentiert eine fruehere Shared-Session-Phase. Der Host-only-Autorisierungscode-Cutover vom 2026-07-18 ersetzt dieses Design.

  • Die fruehere Same-Site-Koordination bleibt als Release-Historie dokumentiert, ist aber nicht mehr die aktive Session-Architektur.
  • `ronova-archon` und `ronova-vpn` wurden im Identity-App-/Client-Katalog und in der D1-Migration registriert.
  • Der Eintrag vom 2026-07-18 beschreibt die aktuelle isolierte Host-Session mit einmaligem Code.

Archon- und VPN-Subdomains sind jetzt auf Cloudflare live.

`archon.ronova.dev` und `vpn.ronova.dev` laufen jetzt über Cloudflare Pages, statt an fehlendem DNS zu scheitern.

  • Die nötigen proxied Cloudflare-CNAME-Routen für die Archon- und VPN-Pages-Projekte wurden ergänzt.
  • `archon.ronova.dev` liefert die owner-only Steuerungsebene mit no-store/noindex-Headern aus.
  • Das Ronova-VPN-Pages-Bundle wurde neu deployed; `vpn.ronova.dev` liefert das Ronova VPN Portal, während der pages.dev-Host dorthin weiterleitet.

Fundatio Trilunae steht jetzt unter Projekte.

Die Startseite behandelt Fundatio Trilunae jetzt als Projekteintrag statt als eigenes Feature-Band, mit transparentem Siegel und einer Ronova-seitigen Projektseite.

  • Der sichtbare Fundatio-Eintrag wurde in die vorhandene Projektkartenliste verschoben, statt als eigener Startseitenabschnitt zu bleiben.
  • Die Karte verweist auf `/fundatio/` als Projektbeschreibung, während `https://triluna.org` das externe Fundatio-Ziel bleibt.
  • Die weiße Siegelplatte wurde durch ein transparentes Siegel ersetzt, das direkt auf der Projektkarte liegt.

Der kontrollierte Archon liegt jetzt auf archon.ronova.dev.

Die owner-only Steuerungsebene nutzt jetzt eine eigene Subdomain; alte Admin-Pfade leiten dorthin weiter, während Access-Key-, Grant-, Private-Page-, Registry- und Audit-Kontrollen passkey-pflichtig bleiben.

  • `archon.ronova.dev` ist jetzt der kanonische Host für den kontrollierten Archon; `/id/admin/` und `id.ronova.dev/admin/` leiten dorthin weiter.
  • Access Keys können einmalig ausgegeben, nur als keyed hashes gespeichert und zusammen mit aktiven Private-Page-Sitzungen widerrufen werden.
  • `/api/admin/archon` ist an den Archon-Host gebunden und verlangt weiterhin die globale Owner-Rolle plus eine starke passkey-gestützte Ronova-ID-Sitzung.

Die Gekka-Seite und die Drawer-Navigation wurden vereinfacht.

Die Projektseite erklärt die Grenze zwischen Schöpferinnen-Hub und offizieller Projektseite schneller; das Overlay-Menü ist ruhiger, leichter und besser scannbar.

  • Der Drawer ist jetzt um Main, Projects, Access, Language, External und Trust aufgebaut, statt wie eine volle Sitemap zu wirken.
  • Die Gekka-Seite hält Ronova.dev als Schöpferinnen-Kontext fest und verweist offizielle Informationen, Versionen und Einstiege klar auf gekka-harae.com.
  • Der Footer wiederholt weniger Navigation und bleibt bei Copyright, Sprache, offizieller Projektseite und wesentlichen Vertrauenslinks.

Das Deploy-Gate prueft jetzt Cache-Keys fuer veraenderliche oeffentliche Assets.

Generierte Seiten fallen nun durch die Validierung, wenn Scripts, Styles, Social Images, Favicons oder die Kontaktkarte die gemeinsame Cache-Busting-Version umgehen.

  • Access-, Support- und Kontaktkarten-Seiten nutzen jetzt die gemeinsame Static-Asset-Version fuer ihre seitenspezifischen Assets.
  • Der Built-Site-Validator scannt jede generierte HTML-Datei vor dem Release auf unversionierte veraenderliche Public Assets.
  • Die statische Header-Policy verlangt jetzt auch `X-Content-Type-Options: nosniff` fuer die oeffentliche Kontaktkarte.

Ronova ID schützt wiederherstellungssensible Einstellungen jetzt per Step-up.

Kontoeinstellungen nahe an Wiederherstellung und Kontinuität erfordern jetzt eine starke passkey-gestützte Ronova-ID-Sitzung, wenn Step-up für die Identität gilt.

  • E-Mail-Hinzufügen, Primär-E-Mail-Änderungen, E-Mail-Entfernung, Passkey-Deaktivierung und Widerruf anderer Sitzungen geben nun `step-up-required` zurück, solange die Sitzung nicht stark ist.
  • Passkey-Einrichtung und reine Profiländerungen bleiben verfügbar, damit Bootstrap ohne Passwort-Fallback weiterkommt.
  • Das Konto-Einstellungsfeld zeigt den blockierten Zustand und hält Passwort-Login weiter deaktiviert.

Ronova ID hat jetzt eine echte Konto-Einstellungsfläche.

Die Ronova-ID-Kontoansicht lädt jetzt Live-Einstellungen für Profil, E-Mails, passwortlosen Status, Passkeys, aktive Sitzungen, Wiederherstellungsstand und App-Zugriff.

  • Authentifizierte Settings-APIs für Profiländerungen, unverifizierte E-Mail-Zeilen, Passkey-Deaktivierung und Widerruf anderer Sitzungen wurden ergänzt.
  • Passwortverwaltung bleibt ausdrücklich passwortlos: Ronova ID erstellt und speichert kein Passwort.
  • Die Ronova-ID-Kontoseite hat jetzt ein Live-Einstellungsfeld mit cache-gebrochenen Scripts und Styles.

Ronova ID hat jetzt einen aktiven Passkey-Login.

Die Identity-Runtime hat jetzt WebAuthn-Challenge-Speicher, Passkey-Einrichtung, Passkey-Anmeldung und klarere Trust-Felder beim Code-Austausch, damit Cross-Project-Clients erkennen konnen, wann ein Ronova-ID-Nachweis nutzerverifiziert per Passkey war.

  • Die D1-Migration `0004_ronova_passkey_runtime` erganzt WebAuthn-Challenges und Passkey-Metadaten.
  • Die Ronova-ID-Kontoseite bietet jetzt Passkey-Anmeldung und Passkey-Einrichtung; die alte Bridge bleibt nur ein enger Owner-Bootstrap.
  • Der Authorization-Code-Austausch meldet jetzt passkey-gestutzte Trust-Felder fur die spatere Gekka-Account-Prufung.

Ronova ID ist jetzt als kontoübergreifende Projektschicht gefasst.

Das Identity-Register führt account.gekka-harae.com jetzt als eigenen Gekka-Account-Center-Client, damit das Gekka-Projekt ein konkretes Ronova-ID-Ziel fuer Anmeldung und Login-Uebertragung hat.

  • Eine eigene `gekka-account`-App mit Client für `https://account.gekka-harae.com/api/auth/ronova/callback` wurde ergänzt.
  • `gekka.account.login`, `gekka.account.link` und `gekka.account.recovery` trennen Kontoidentität von Play-, Senate- und Archon-Autorität.
  • Die Architekturnotiz erklärt jetzt, wie Gekka Login-Autoritaet an Ronova ID uebertragen kann, ohne eine Gekka-Sitzung als Ronova-private Sitzung zu behandeln.

Ronova ID hat jetzt einen vollständigen Shared-Identity-Entwurf.

Die Ronova-ID-Architekturnotiz beschreibt jetzt das geplante passkey-first-Identitätssystem für ronova.dev, id.ronova.dev und verwandte Projekte, einschließlich D1-Schema-Richtung, Wiederherstellung, privatem Seitenzugriff und Gekka-Berechtigungsbrücke.

  • Ronova ID ist als zentrale Identitätsebene dokumentiert, während jede nutzende Anwendung ihre eigene abgegrenzte Sitzung behält.
  • Das langfristige D1-Modell für Nutzer, Passkeys, WebAuthn-Challenges, Wiederherstellungscodes, Zugangsschlüssel, App-Grants, Sitzungen, Tickets und Audit-Ereignisse ist beschrieben.
  • Gekka-Kontoflüsse dürfen Ronova-Berechtigungen anfragen, aber private ronova.dev-Seiten werden nur durch explizite Ronova-ID-Grants und kurzlebige audience-gebundene Tickets freigeschaltet.

Die Unterseiten wurden mit sicherheitsbewusster Politur verfeinert.

ronova.dev hat einen fokussierten Feinschliff für öffentliche Darstellung und Runtime-Verhalten erhalten: Der Statusbereich der Startseite ist jetzt lokalisiert, Vertrauensseiten sind leichter zu scannen, Devlog-Tags treten klarer hervor, und Ronova-ID-Anfragen folgen dem begrenzten Body-Muster der älteren Zugangs- und Support-Endpunkte.

  • Der Statusbereich auf der Startseite wurde lokalisiert, damit nicht-englische Oberflächen im ersten Viewport keine hart codierten englischen Labels mehr zeigen.
  • Devlog und Vertrauensseiten wurden mit besser scanbaren Tags und ruhigeren Hinweis-Panels geschärft.
  • Ronova-ID-Auth-Anfragebodies werden für JSON und URL-kodierte Formulare begrenzt, bevor Login, Logout und Code-Austausch verarbeitet werden.

Ronova ID hat jetzt eine eigene Subdomain-Route.

id.ronova.dev führt jetzt in das bestehende Ronova-ID-Portal, statt als noch nicht verdrahtete Zukunftsadresse offen zu bleiben.

  • Host-bewusstes Pages-Routing ergänzt, damit Übersicht, Kontoansicht und Admin-Ansicht unter `id.ronova.dev`, `/account/` und `/admin/` erreichbar sind.
  • `ronova.dev/id/` bleibt als Pfad-Fallback erhalten, während der dedizierte Identitäts-Hostname im öffentlichen App-Katalog ausgewiesen wird.
  • Die Noindex- und No-Store-Haltung für Ronova ID bleibt bestehen; andere Subdomain-Pfade führen zurück zur öffentlichen Hauptseite.

Die Grundlagen von Ronova ID existieren jetzt als echte öffentliche Flächen und Runtime-APIs.

ronova.dev zeigt jetzt eine erste Ronova-ID-Grundlage mit eigenen Identitätsseiten, einem zentralen App- und Client-Register und dem Anfang eines redirect-basierten Autorisierungsflusses, der Sitzungen pro Anwendung getrennt hält.

  • Echte Flächen unter `/id/` und `/id/account/` wurden ergänzt, dazu die Admin-Quellroute, die inzwischen nach `archon.ronova.dev` weiterleitet, mit lokalisierten Varianten für Englisch, Deutsch, Französisch, Japanisch und Traditionelles Chinesisch.
  • Ein zentrales Ronova-ID-D1-Register für First-Party-Apps, vertrauenswürdige Clients, Rollen, Berechtigungen, Sitzungen, Autorisierungscodes und Audit-Ereignisse wurde angelegt.
  • Der erste migrationssichere Bootstrap-Pfad ist jetzt vorhanden: eine enge Legacy-Brücke über die bestehende private Ronova-Admin-Sitzung, ohne Cross-Domain-Cookies zum Vertrauensmodell zu machen.

Die Navigation trennt jetzt Primärwege, Tiefenstruktur und Vertrauenslinks.

Die öffentliche Shell hält den Header jetzt fokussiert, verschiebt den vollständigen Seitenplan in ein echtes Drawer-Menü an der rechten Kante und verankert den Footer in Kontakt, offizieller Verifikation und Vertrauens-Metadaten.

  • Der dauerhaft sichtbare Header wurde auf Identität, die wichtigsten öffentlichen Seiten, eine direkte Zugangsaktion und einen Hamburger-Auslöser ganz rechts reduziert.
  • Ein vollständiges, höhenfüllendes Drawer-Menü an der rechten Seite liegt jetzt auf der Site-Ebene statt im Header-Band und bündelt Projekt-, Support-, Privat-, Sprach-, offizielle und Vertrauens-Routen mit Tastatursteuerung, Fokus-Rückgabe, Backdrop-Schließen und reduzierter Bewegung.
  • Der Footer gruppiert Kontaktwege, offizielle externe Verifikation und Vertrauenslinks neu, ohne die öffentliche Telefonnummer dauerhaft auf jeder Seite auszubreiten.

Projektrouten laufen jetzt zuerst über Ronova-Seiten.

Die öffentliche Projektführung stellt die Arbeit jetzt zuerst auf ronova.dev vor, bevor es nach außen weitergeht. Gleichzeitig bekommt der Footer `gekka-harae.com` wieder als direkte Abkürzung zurück.

  • Der Gekka-Eintrag auf der Projektfläche öffnet jetzt die Ronova-Brückenseite statt sofort zur externen Website zu springen.
  • Auf der Gekka-Brückenseite wurde der Ausgangsbutton zur offiziellen Projektseite wiederhergestellt, damit die Beschreibungsseite bewusst nach außen weiterleiten kann.
  • `gekka-harae.com` wurde in die externen Footer-Links als direktes Ziel zurückgelegt.

Kontaktkarten-Downloads halten jetzt an einer Klartext-Prüfstelle an.

Footer und Kontaktflächen stoßen die Adressbuchdatei nicht mehr sofort an. Stattdessen öffnet sich zuerst eine Prüffläche, die den Inhalt der Karte vor dem Download erklärt.

  • Direkte Kontaktkarten-Downloads im Footer, auf der Kontaktseite und in den offiziellen Linkkarten wurden auf eine gemeinsame Prüfroutenfläche umgestellt.
  • Die tatsächlich gespeicherten Felder werden jetzt in Alltagssprache aufgelistet: Name, E-Mail, Telefon, offizielle Website, GitHub-Profil, Bilibili-Profil und die kurze Seitennotiz.
  • Die eigentliche .vcf-Datei bleibt erst hinter einer ausdrücklichen Bestätigen-und-Herunterladen-Aktion erreichbar.

Scroll-Reveals atmen jetzt statt zu springen.

Karten, Panels und Textbereiche folgen jetzt einer wiederverwendbaren 0-bis-100%-Viewport-Kanten-Skala und lösen sich weich durch die oberen und unteren zehn Prozent des Bildschirms ein.

  • Die bisherige einmalige Ladeanimation wurde durch ein gemeinsames Scroll-Fortschritts-Reveal-System ersetzt.
  • Der Reveal-Fortschritt wird jetzt innerhalb der oberen und unteren 10-%-Viewport-Zonen von 0 % bis 100 % gemappt, statt Blöcke nur komplett an oder aus zu schalten.
  • Der blur-basierte Pixel-Resolve bleibt erhalten, sodass Textboxen und Karten beim Herunter- und Hochscrollen sowie in neu sortierten Projektlisten weiter sanft klarziehen.

Die Sprachwahl ist aus dem Header in den Footer gewandert.

Der Header bleibt jetzt bei der Primärnavigation, während die Sprachwahl in ein eigenes sekundäres natives Pull-down im Footer mit Globus-Symbol verlegt wurde.

  • Die Sprachumschaltung wurde sowohl aus dem Desktop- als auch aus dem Mobile-Header entfernt.
  • Im Footer wurde ein Sprach-Pull-down mit nativen HTML-Details und Summary aufgebaut, statt den bisherigen eingebauten Switcher weiterzuverwenden.
  • Die Sprachwahl bleibt unter dem Copyright-Block, damit routenbezogene Hilfsfunktionen an einer Stelle im Footer gebündelt bleiben.

Externe Ziele wurden eingegrenzt und der Footer wurde fest verankert.

Projektziele bleiben jetzt auf der eigenen Projektseite, Plattformlinks wurden im Footer gebündelt, und kurze Seiten lassen ihren Leerraum oberhalb des Footers statt darunter.

  • Direkte externe Sprünge wurden aus Home-Hero, Featured-Project-Karten, Kontakt-Aktionen und der Gekka Harae-Brückenseite entfernt.
  • Der Footer wurde in getrennte Spalten für Identität, interne Links und externe Links aufgeteilt; die Sprachlinks stehen jetzt direkt unter der Copyright-Zeile.
  • Die Seitenschale wurde so umgestellt, dass der Footer auf kurzen Seiten am unteren Rand des Viewports bleibt.

Die öffentlichen Kontaktlinks wurden erweitert.

Die öffentlichen Kontaktflächen zeigen jetzt ein echtes Bilibili-Profil, eine Schweizer Telefonnummer und eine aktualisierte Kontaktkarte statt weiterhin teils versteckter Social-Platzhalter.

  • Der letzte Social-Platzhalter wurde durch das offizielle Bilibili-Profil von Ronova27 ersetzt.
  • Die öffentliche Telefonnummer wurde auf Kontaktseite, Footer, strukturierte Identitätsdaten und Tap-to-Call-Links ausgerollt.
  • Die herunterladbare .vcf-Karte enthält jetzt sowohl die Telefonnummer als auch die Bilibili-URL.

Die Identitätssignale für Suchmaschinen wurden geschärft.

Öffentliche Metadaten, Profil-Schema, Sitemap-Abdeckung und Crawl-Sperren für geschützte Routen wurden so ausgerichtet, dass ronova.dev klarer als offizielle Website von Ronova Deng lesbar ist.

  • Ein stärkeres ProfilePage- und Person-Schema verbindet jetzt Ronova, Ronova Deng, ronova.dev, GitHub und gekka-harae.com.
  • Der Alternativsprachen-Graph wurde bereinigt und die öffentlichen Devlog-Routen kamen in die Sitemap, damit frische öffentliche Inhalte leichter gefunden werden.
  • Für /private/* und /api/* wurden X-Robots-Tag-noindex-Header ergänzt, damit geschützte Oberflächen aus Suchindizes herausbleiben.

Die öffentliche Palette wurde auf Dämmerung und Amethyst umgestellt.

Die gemeinsame Shell trägt jetzt eine tiefere Ink-Palette mit Amethyst- und Mondgold-Akzenten über Navigation, Karten, Formulare und Social-Assets hinweg.

  • Die bisher blau geprägten Shell-Tokens wurden im gemeinsamen Stylesheet durch eine zusammenhängende Deep-Ink-, Amethyst- und Moon-Gold-Palette ersetzt.
  • Dieselbe Palette wurde durch Buttons, Status-Pills, Formularfelder und die private Zugriffsshell gezogen, damit Laufzeit- und öffentliche Seiten nicht mehr auseinanderlaufen.
  • Favicon, Social-Card und Browser-Theme-Farbe wurden mitgezogen, damit gemeinsame Assets nicht im alten Farbraum zurückbleiben.

Projektbenennung wurde sprachweise vereinheitlicht.

Die sichtbare Projektbenennung kommt jetzt aus einer gemeinsamen Ausdruckstabelle, sodass lateinische Oberflächen Gekka Harae verwenden und chinesische Oberflächen den Titel in eigener Schrift ohne Mischformen behalten.

  • Eine gemeinsame Ausdruckstabelle ersetzt wiederholte gemischte Projektnamen in den Locale-Dateien.
  • Die deutsche und englische Oberfläche verwendet jetzt Gekka Harae, während Traditionelles Chinesisch bei sichtbaren Labels den Titel in eigener Schrift beibehält.
  • Technische Kennungen wie gekka-harae.com bleiben unverändert, während Überschriften, Metadaten und Support-Optionen bereinigt wurden.

Die öffentliche Shell ist live gegangen.

ronova.dev läuft jetzt als mehrsprachige Astro-Seite mit klarer öffentlicher Shell, eigener Projektroutenstruktur und echtem Cloudflare-Pages-Auslieferungspfad.

  • Die erste öffentliche Shell wurde mit Englisch, Deutsch und Traditionellem Chinesisch als Routen ausgeliefert.
  • Schöpferinnen-Hub-Seiten und Projektziel-Seiten wurden sauber getrennt, damit ronova.dev und gekka-harae.com jeweils eine klare Rolle behalten.
  • Der Custom-Domain-Pfad für ronova.dev wurde auf dem Pages-Projekt verifiziert.

Privater Kontakt und Zugriff wurden gehärtet.

Support und privater Zugriff sind über Platzhalter hinausgewachsen und laufen jetzt über einen servergestützten Fluss mit Verschlüsselung, Scopes und D1-validierten Sitzungen.

  • Browserseitige Verschlüsselung für Support-Nachrichten wurde vor der Speicherung ergänzt.
  • Private Seiten bleiben hinter gescopten Zugangscodes mit servervalidierten Sitzungen.
  • Der Anfragepfad wurde gegen die lokale Pages-Laufzeit geprüft statt nur gegen statische Annahmen.

Typografie und Layout bekamen einen strafferen Pass.

Der visuelle Feinschliff zielte auf Konsistenz: eine Schriftfamilie, ein korrigiertes responsives Grid und eine sauberere produktionsreife Shell.

  • Die öffentliche Typografie wurde auf Yuji Syuku über die Hauptseite und die Social-Card vereinheitlicht.
  • Der gemeinsame Project-Card-Rhythmus wurde so korrigiert, dass Tablet-Safari das geplante Full-Width-Leselayout beibehält.
  • Nach der Layout-Korrektur wurde neu gebaut und erneut ausgeliefert, um den Produktionspfad zu bestätigen.