Custodia · TDS 1.0
Une norme pour chaque document.
Le Triluna Document Standard (TDS) est le système documentaire commun, actuellement en version 1.0, utilisé par Triluna, RENKAN et Gekka Harae. Il régit le document lui-même, et pas seulement son format de livraison : principalement le PDF, mais aussi le HTML, les sources Python, le Markdown et les autres sorties gérées.
Portée
Un document a un type, pas seulement une extension.
Un PDF, une page HTML et un fichier source Python peuvent suivre des règles de sortie différentes tout en étant gérés comme des documents TDS. Le TDS indique le but du document, sa responsabilité, la version consultée, les éléments de preuve qu’il contient et son statut : brouillon, examiné, canonique ou remplacé.
Le PDF est la forme principale de publication officielle. Le HTML peut porter le même ordre de lecture et les mêmes métadonnées sur le Web. Python et les autres fichiers sources peuvent être gérés lorsqu’ils font partie d’un document, d’une preuve reproductible, d’un lot de modèles ou d’un paquet de publication. L’extension ne détermine pas l’autorité du document.
La version 1.0 est utilisée dans la famille Triluna. Les règles communes restent communes ; un projet peut ajouter son contenu, son accent ou son contexte de publication sans créer une norme documentaire distincte.
Fondation
Un document est composé avant d’être exporté.
Composition du document
- Le titre et le but viennent d’abord, puis les métadonnées TDS, le statut, la portée et la route.
- Un seul ordre de lecture relie la prose, les tableaux, les notes et les marqueurs de preuve.
- Les tableaux portent les correspondances et registres exacts ; la prose porte le raisonnement et les réserves.
- Les éléments manquants restent visibles sous forme de constat, par exemple
[EVIDENCE REQUIRED].
Expression commune
- La base TDS commune déclare Yuji Syuku comme police locale actuelle de l’interface publique de Triluna.
- La typographie, la couverture des glyphes, la géométrie, la couleur, les espacements et le comportement responsive sont documentés comme des entrées.
- Triluna peut employer son expression violette retenue et son motif de double ligne sans changer le contrat commun.
- L’identité et l’autorisation du projet restent hors de la norme documentaire ; Renkan ID demeure la frontière d’identité universelle.
Contrat documentaire
Les mêmes questions accompagnent chaque sortie.
- Géométrie
- Le TDS consigne la géométrie de page et les contraintes de mise en page de chaque sortie, y compris les géométries Ronova Legacy lorsqu’un profil examiné existe. RL-144, RL-233 et RL-377 ne sont pas présentés ici comme des profils actifs : aucune définition canonique de géométrie pour ces identifiants n’est présente dans la source publique de Triluna.
- Police et couverture des glyphes
- La police déclarée et les caractères qu’elle doit couvrir sont vérifiés ensemble. Les glyphes manquants, la ponctuation non prise en charge ou une plage linguistique non déclarée restent des constats de preflight ; une police de remplacement silencieuse n’est pas une solution.
- Lots de modèles
- Un lot réutilisable réunit l’en-tête de métadonnées, l’ordre du corps, les motifs de tableaux, les notes, les règles de nommage et les instructions de sortie. Les modèles restent du matériel de travail tant que leur statut n’en dispose pas autrement.
- Métadonnées, nommage et versions
- Chaque document indique son titre, son type, sa version, sa date, sa langue, le projet ou responsable chargé de sa gestion, sa source, son statut, sa visibilité, son statut canonique, sa publication associée et son état de vérification. Le nom du fichier et la révision doivent correspondre à ces champs.
- Preflight et absence de fallback
- Le preflight vérifie la géométrie déclarée, la police et la couverture des glyphes, les métadonnées, les liens, les ressources, la limite de confidentialité et les preuves en suspens. Un échec requis bloque la sortie officielle au lieu d’être masqué par un fallback ou un placeholder.
- PDF de publication officielle
- Un PDF officiel doit porter la version et l’ordre de lecture examinés, réussir les contrôles de géométrie et de glyphes, contenir les métadonnées requises, lever les constats de publication non résolus et conserver sa provenance publique. Une somme de contrôle identifie les octets ; elle ne rend pas à elle seule un document approuvé ou signé cryptographiquement.
Discipline de publication
Officiel signifie lisible et traçable.
Le chemin de publication est volontairement court. Un document ne passe de la source à une sortie examinée que lorsque son but, son statut, sa responsabilité, sa version, sa langue, sa géométrie, sa police et sa couverture des glyphes, ses preuves et sa route publique sont lisibles ensemble.
- 1Composer
- 2Déclarer les métadonnées et le statut
- 3Exécuter le preflight
- 4Examiner la sortie rendue
- 5Publier ou conserver comme matériel de travail
Téléchargements · source anglaise
Commencer avec un document qui déclare son propre état.
Voici du matériel de travail réutilisable pour le TDS 1.0. Il ne s’agit pas d’un PDF de publication officielle, il ne crée pas d’archive canonique et ne rend pas Ronova Syuku disponible.
- Télécharger le modèle de document TDS 1.0
Modèle source Markdown avec type de document, portée, métadonnées, versions, preflight et champs de publication. - Télécharger la source de l’exemple HTML TDS 1.0
Source d’exemple anglaise autonome montrant l’état déclaré, l’ordre de lecture, les métadonnées et la limite explicite d’un exemple non officiel.
État du composant
Ronova Syuku n’est pas prêt à l’emploi.
Ronova Syuku est prévu comme composant TDS pour le travail de typographie et de glyphes dans la famille Ronova. Son développement n’est pas terminé. Cette page ne revendique ni publication, ni paquet de police, ni téléchargement, ni disponibilité en production.
En développement · pas prêt