Custodia · TDS 1.0

Ein Standard für jedes Dokument.

Der Triluna Document Standard (TDS) ist das gemeinsame Dokumentensystem in der aktuellen Version 1.0 für Triluna, RENKAN und Gekka Harae. Er verwaltet das Dokument selbst, nicht nur das Ausgabeformat: vor allem PDF, aber auch HTML, Python-Quelltext, Markdown und andere verwaltete Ausgaben.

Geltungsbereich

Dokumente haben einen Typ, nicht nur eine Dateiendung.

Ein PDF, eine HTML-Seite und eine Python-Quelldatei können unterschiedliche Ausgaberegeln haben und trotzdem als TDS-Dokumente verwaltet werden. TDS hält fest, welchem Zweck das Dokument dient, wer dafür verantwortlich ist, welche Version gelesen wird, welche Nachweise enthalten sind und ob der Status Entwurf, geprüft, kanonisch oder abgelöst ist.

PDF ist die wichtigste Form der offiziellen Veröffentlichung. HTML kann dieselbe Lesereihenfolge und dieselben Metadaten im Web tragen. Python und andere Quelldateien können verwaltet werden, wenn sie Teil eines Dokuments, eines reproduzierbaren Nachweises, eines Vorlagenpakets oder einer Veröffentlichung sind. Die Endung entscheidet nicht über die Gültigkeit.

Version 1.0 wird in der Triluna-Familie verwendet. Gemeinsame Regeln bleiben gemeinsam; ein Projekt kann eigene Inhalte, Akzente und Veröffentlichungskontexte ergänzen, ohne einen separaten Dokumentstandard zu schaffen.

Grundlage

Ein Dokument wird vor dem Export zusammengesetzt.

Dokumentaufbau

Titel und Zweck stehen zuerst, danach folgen TDS-Metadaten, Status, Umfang und Route.
Eine Lesereihenfolge verbindet Prosa, Tabellen, Hinweise und Nachweismarker.
Tabellen enthalten genaue Zuordnungen und Register; Prosa trägt Begründungen und Vorbehalte.
Fehlende Nachweise bleiben als Befund sichtbar, etwa [EVIDENCE REQUIRED].

Gemeinsame Gestaltung

Die gemeinsame TDS-Grundlage verwendet Yuji Syuku als aktuelle lokal eingebundene Schrift der öffentlichen Triluna-Oberfläche.
Typografie, Glyphenabdeckung, Geometrie, Farbe, Abstände und responsive Darstellung werden als Dokumenteingaben festgehalten.
Triluna kann seinen zurückhaltenden Violettausdruck und das Doppellinienmotiv verwenden, ohne den gemeinsamen Vertrag zu ändern.
Projektidentität und Autorisierung liegen außerhalb des Dokumentstandards; Renkan ID bleibt die universelle Identitätsgrenze.

Dokumentenvertrag

Dieselben Fragen begleiten jede Ausgabe.

Geometrie: TDS hält Seitengeometrie und Layoutgrenzen für die jeweilige Ausgabe fest, einschliesslich Ronova-Legacy-Geometrien, sobald ein geprüftes Profil besteht. RL-144, RL-233 und RL-377 werden auf dieser Seite nicht als aktive Profile behauptet, weil im öffentlichen Triluna-Quelltext keine kanonischen Geometriedefinitionen für diese Bezeichnungen vorliegen.
Schrift und Glyphenabdeckung: Die deklarierte Schrift und die abzudeckenden Zeichen werden gemeinsam geprüft. Fehlende Glyphen, nicht unterstützte Interpunktion oder ein nicht erfasster Sprachbereich bleiben Preflight-Befunde; eine stille Ersatzschrift ist keine Lösung.
Vorlagenpakete: Ein wiederverwendbares Paket verbindet Metadatenkopf, Textreihenfolge, Tabellenmuster, Hinweise, Namensregeln und Ausgabeanweisungen. Vorlagen bleiben Arbeitsmaterial, solange ihr Status nichts anderes sagt.
Metadaten, Namensgebung und Versionierung: Jedes Dokument nennt Titel, Typ, Version, Datum, Sprache, verantwortliches Projekt oder Betreuung, Quelle, Status, Sichtbarkeit, kanonischen Status, zugehörige Veröffentlichung und Verifikationsstand. Dateiname und Revision müssen zu diesen Feldern passen.
Preflight und kein Fallback: Preflight prüft deklarierte Geometrie, Schrift und Glyphenabdeckung, Metadaten, Links, Assets, Datenschutzgrenze und offene Nachweise. Ein erforderlicher Fehler blockiert die offizielle Ausgabe, statt durch Fallback oder Platzhalter verborgen zu werden.
Offizielles Release-PDF: Ein offizielles PDF muss geprüfte Version und Lesereihenfolge tragen, Geometrie- und Glyphenprüfung bestehen, die erforderlichen Metadaten enthalten, offene Release-Befunde klären und seine öffentliche Herkunft bewahren. Eine Prüfsumme identifiziert Bytes; sie macht ein Dokument allein weder genehmigt noch kryptografisch signiert.

Veröffentlichungsdisziplin

Offiziell heisst: lesbar und nachvollziehbar.

Der Veröffentlichungsweg ist bewusst kurz. Ein Dokument geht erst dann von der Quelle in eine geprüfte Ausgabe über, wenn Zweck, Status, Betreuung, Version, Sprache, Geometrie, Schrift und Glyphenabdeckung, Nachweise und öffentliche Route gemeinsam lesbar sind.

1Zusammensetzen
2Metadaten und Status deklarieren
3Preflight ausführen
4Gerenderte Ausgabe prüfen
5Veröffentlichen oder Arbeitsmaterial behalten

Downloads · englische Quelle

Beginnen Sie mit einem Dokument, das seinen eigenen Stand erklärt.

Dies sind wiederverwendbare Arbeitsmaterialien für TDS 1.0. Sie sind kein offizielles Release-PDF, schaffen keinen kanonischen Archiveintrag und machen Ronova Syuku nicht verfügbar.

TDS-1.0-Dokumentvorlage herunterladen
Markdown-Quellvorlage mit Dokumenttyp, Umfang, Metadaten, Versionierung, Preflight- und Veröffentlichungsfeldern.
TDS-1.0-HTML-Quellbeispiel herunterladen
Eigenständiger englischer Beispielquelltext mit deklariertem Status, Lesereihenfolge, Metadaten und klarer Grenze als nicht offizielles Beispiel.

Komponentenstatus

Ronova Syuku ist noch nicht bereit.

Ronova Syuku ist als TDS-Komponente für Schrift- und Glyphenarbeit in der Ronova-Familie vorgesehen. Die Entwicklung ist nicht abgeschlossen. Diese Seite behauptet keine Veröffentlichung, kein Schriftpaket, keinen Download und keine Verfügbarkeit in Produktion.

In Entwicklung · nicht bereit