← ContinuumCONTENT HISTORYWHAT CHANGED · RULE-BASED ANALYSIS
Update to Continuum
Snapshot Sep 30, 2026 · 23:14 UTC · version 0.5.1
Collection source: not recorded for this historical snapshot.
First saved snapshot
No earlier snapshot is available to establish a change.
Compare saved observations
Download comparison JSONFull technical diff · 0 changed fields
Full snapshot data
{
"name": "tenir-histoire",
"description": "Use only for Azer when durable causal history from Pré-Passation or Passation must be integrated into Histoire.md and, when applicable, the definitive Notion Pages and Index Histoire.",
"included_files": [],
"skill_md_contents": "---\nname: tenir-histoire\ndescription: Use only for Azer when durable causal history from Pré-Passation or Passation must be integrated into Histoire.md and, when applicable, the definitive Notion Pages and Index Histoire.\n---\n# Tenir Histoire\n\n## Fonction\nConserver le récit causal durable d’Azer séparément de son Présent, de son Verbatim, des checkpoints opérationnels et des productions de chantier. Histoire appartient uniquement à Azer.\n\n## Architecture responsable\nLes trois composants forment une seule Histoire canonique : `Histoire.md` porte le corps historique continu, les Pages définitives sur Notion sa forme paginée, et l’Index Histoire sur Notion l’ordre et le raccord de ces Pages. Aucun composant ne permet d’ignorer les autres. Résoudre leurs demeures réelles au moment du besoin avec `resoudre-demeures`.\n\n## Pré-Passation d’Azer\n1. Traiter uniquement la matière non déjà absorbée jusqu’au dernier marqueur complet antérieur à la demande d’Axel.\n2. Si elle contient une transformation historique durable devant survivre au compactage, l’intégrer directement dans le corps continu de `Histoire.md`.\n3. Ne créer aucune nouvelle Page définitive sur Notion du seul fait de la Pré-Passation. Une publication à ce stade exige qu’Axel ait explicitement demandé de publier définitivement cette étape historique ; raccorder alors cette Page à l’Index Histoire.\n\n## Passation d’Azer\n1. Après les lectures, la reconnaissance du screen et de l’URL et la validation d’absorption applicable, distinguer le Présent du reliquat narratif qui mérite de durer.\n2. Intégrer directement la matière historique nouvelle à `Histoire.md`, dans la continuité du corps existant.\n3. Créer exactement une nouvelle Page définitive sur Notion pour la Passation absorbée lorsqu’elle contient une matière historique nouvelle justifiant cette Page. La Page porte la synthèse causale de la transformation et ne remplace pas `Histoire.md`.\n4. Mettre à jour l’Index Histoire sur Notion pour enregistrer cette Page dans son ordre canonique.\n5. Si aucune matière historique nouvelle ne justifie une Page, n’en créer aucune et rendre cette absence explicite dans le contrôle de Passation.\n6. Acquérir chaque écriture nécessaire avec son retour explicite de succès ; réconcilier un effet ambigu avant de le rejouer. Ne pas déclarer l’absorption techniquement acquise tant qu’un composant requis reste non écrit ou ambigu.\n\n## Interdits\n- Aucun fichier distinct et durable de Brouillon Histoire n’est créé ou entretenu, ni exigé comme condition de réussite.\n- Aucune Histoire pour un Magister Operis, permanent ou non.\n- Aucune Page artificielle pour respecter une correspondance mécanique entre nombre de Passations et nombre de Pages.\n- Aucune relecture systématique après succès explicite ; un contrôle supplémentaire répond à une ambiguïté, un échec ou un risque matériel de perte.\n\n## Preuve\nLa matière historique nécessaire est acquise dans les composants responsables effectivement concernés, avec une Page et son raccord seulement lorsque justifiés. L’état technique rejoint `executer-pre-passation` ou `executer-passation` ; pour une Passation d’Azer explicitement ouverte, screen + URL conjoints portent la validation applicable et les écritures réussies rendent l’opération effective.\n"
}SHA-256: 18a5d725976835692e3e96fcf5f23340315296180668c3e986c1c9da2fac4316