Orelius

Plugin Obsidian desktop pour discuter avec l’installation locale de Codex dans un panneau latéral. Ce socle comprend les réglages de connexion, le chat en Markdown, les réponses progressives, l’interruption et la reprise de la dernière conversation.

Utilisation

Activez Orelius dans les modules complémentaires d’Obsidian. Ouvrez ensuite Orelius : Ouvrir le chat depuis la palette de commandes, ou cliquez sur l’icône de discussion du ruban.

Dans Réglages → Orelius, l’installation de Codex est détectée automatiquement. Si elle n’est pas trouvée, utilisez Rechercher Codex ; un champ de chemin manuel apparaît si cette recherche échoue. Tester Codex, juste sous l’installation, vérifie l’exécutable et son authentification indépendamment du dossier de travail. Codex utilise son authentification existante ; si nécessaire, lancez codex login dans le terminal.

Le bouton Parcourir… ouvre le sélecteur Obsidian pour choisir un dossier du coffre, y compris sa racine. Les modifications sont enregistrées automatiquement.

Dans Organisation du projet, les noms des dossiers sont personnalisables : Archives, Manuscript, Model et Bible par défaut. Les dossiers du manuscrit et des textes modèles contiennent chacun Chapitres, Personnages, Plan et Resume. Model accueille une version antérieure du texte ou un texte à adapter ; Codex consulte ces sources et écrit le résultat dans Manuscript, en préservant les sources sauf demande explicite de modification. Le dossier d’archives reprend la structure sous Archives/Manuscript/, Archives/Model/ et Archives/Bible/, avec les noms configurés. Les dossiers manquants sont créés au choix du dossier de travail, à la sortie d’un champ de nom ou à l’ouverture du chat. Un changement de nom utilise de nouveaux chemins ; les dossiers et fichiers existants, y compris les anciennes archives dans _Archives, sont conservés sur place. Ces noms s’appliquent aux différents dossiers de travail.

Dans l’explorateur de fichiers, cliquer sur le dossier de travail, un sous-dossier ou une note qu’il contient ouvre automatiquement le chat. La navigation entre notes par onglets ou liens suit le même comportement. Sortir des dossiers connus masque le panneau et restaure l’état ouvert ou replié de la barre latérale droite avant l’ouverture du chat ; revenir dans le dossier le réaffiche avec ses messages à jour. Un dossier dont la conversation est déjà enregistrée retrouve sa propre session. Si plusieurs dossiers associés sont imbriqués, le plus précis est utilisé. Pendant une tâche, naviguer dans un autre dossier masque le chat et laisse Codex continuer dans son dossier initial ; une autre session ne peut être activée qu’une fois la tâche terminée ou arrêtée.

Écrivez un message, puis utilisez Envoyer ou ⌘/Ctrl + Entrée. Pendant le travail, la saisie reste disponible : Envoyer à la tâche transmet une consigne supplémentaire au tour courant avec turn/steer, sans l’interrompre ni créer une autre conversation. Un indicateur animé près du champ affiche l’activité ; une consigne acceptée est confirmée dans le chat. Pendant la connexion, l’interruption ou l’enregistrement du suivi, vous pouvez préparer le message suivant. Arrêter interrompt la tâche ; pendant une connexion, il ferme cette connexion. Nouvelle conversation détache la conversation courante sans supprimer son historique Codex. Fermer ou masquer le panneau conserve la connexion et la tâche en arrière-plan. Désactiver le plugin arrête les processus lancés par Orelius.

Le panneau affiche le modèle actif dans un sélecteur alimenté par le catalogue de Codex. Le changer reprend la même session avec le modèle choisi et conserve l’historique ; la sélection est indisponible pendant une tâche. À l’ouverture du panneau, la connexion charge le catalogue sans créer de conversation vide. Contexte disponible indique le pourcentage de la fenêtre de contexte restant selon la dernière mesure Codex, à partir du dernier usage et de la capacité annoncée par le serveur. — signifie qu’aucune mesure exploitable n’est disponible, notamment avant la première réponse ou après un changement de modèle. La valeur se met à jour lors des événements d’usage, y compris après compaction.

Si le modèle est temporairement saturé côté OpenAI, un encadré persistant précise que votre quota n’est pas épuisé et propose Relancer. Cet encadré reste visible avec les activités masquées et retrouve le dernier échec à la réouverture de la conversation. La relance conserve la demande, la conversation et les protections de révision ; l’archivage reste obligatoire. Si le chapitre a changé depuis l’échec, utilisez Réviser pour préparer une nouvelle demande. Aucune relance n’est automatique.

Pour reprendre un chapitre après vos corrections, ouvrez-le puis cliquez sur Réviser, à côté d’Envoyer. Le message peut rester vide ; son contenu éventuel ajoute des précisions. Le plugin enregistre les corrections de l’éditeur, actualise le suivi et délimite les paragraphes corrigés ou annotés à partir de la dernière version Codex connue. Le contexte et la Bible sont lus pour comprendre ces zones. Les autres passages, espaces et sauts de ligne sont protégés : toute proposition qui les modifie est refusée avant archivage et écriture. Seuls le chapitre ciblé et Bible/Suivi/Connaissances.md peuvent être écrits pendant cette tâche. Codex doit d’abord consigner dans cette base l’intention comprise, sa portée et ses sources ; le plugin exige cette étape avant l’écriture du chapitre. Les coupes, réécritures et demandes (((...))) servent à comprendre les raisons de la reprise. Si le chapitre est intact et sans annotation, écrivez votre demande dans le chat puis cliquez sur Réviser : aucune correction préalable dans la note n’est nécessaire. Le chapitre entier est autorisé, selon la portée de votre demande, avec le même archivage et surlignage. Si des corrections humaines existent, le message les précise sans élargir les zones autorisées. Sans référence connue, les paragraphes annotés délimitent la révision ; en leur absence, une demande dans le chat suffit. Sans correction ni demande, la révision est refusée. Une coupe seule ne permet pas de réintroduire le passage supprimé. Une retouche humaine pendant le travail bloque la publication et demande un nouvel envoi. Le bouton attend la fin d’une tâche en cours et nécessite un chapitre dans le dossier Chapitres du manuscrit configuré.

Après une révision ciblée, les mots ajoutés ou remplacés par Codex apparaissent sur fond jaune dans l’éditeur, en mode source comme en aperçu en direct. Un petit repère jaune indique une suppression ; son infobulle contient le texte retiré. Ces décorations CodeMirror ne modifient pas le Markdown : aucune balise de surlignage n’est ajoutée. Les références sont conservées dans les données du plugin pour retrouver le surlignage après réouverture. Les repères suivent les déplacements de texte ; une intervention humaine dans une zone surlignée retire son repère. Les relevés de correction distinguent les passages modifiés, sans englober les paragraphes intacts qui les séparent.

Le bouton Accepter apparaît pour le chapitre ouvert lorsqu’une révision reste à accepter. Il retire son surlignage et conserve la version actuelle comme exemple positif dans un relevé horodaté de Bible/Suivi/, référencé dans Bible/suivi.md et Bible/Suivi/Connaissances.md. Le texte saisi dans le chat accompagne l’acceptation et reste conservé mot pour mot, même pour un retour bref comme « Enfin, voilà ce que je voulais ». Codex consulte ces exemples et ces retours lors des prochaines demandes. L’acceptation conserve le manuscrit et ses archives ; les références de diff restent disponibles pour les futures corrections. Si l’enregistrement échoue, le surlignage et le message restent disponibles. Accepter ne lance aucune requête au modèle.

Les chapitres comportant des corrections humaines sont également protégés lors d’un envoi ordinaire dans le chat : les zones sont figées avant le lancement de la tâche. Les consignes ajoutées pendant son exécution ne les élargissent pas. L’écriture d’un chapitre sans correction humaine connue et la création d’un nouveau texte restent disponibles dans les demandes ordinaires.

Pendant une tâche Codex, la note active du projet et les notes dont Codex demande l’écriture passent temporairement en lecture seule dans tous leurs éditeurs ouverts. La saisie, le collage et les commandes d’annulation sont bloqués ; la sélection, la copie et les mises à jour du fichier restent possibles. Les autres notes restent éditables. Le verrou est levé à la fin de la tâche, après son arrêt ou une déconnexion ; désactiver le plugin retire aussi ce verrou. Un état de lecture seule déjà imposé par Obsidian ou une autre extension est conservé.

Codex demande les créations et modifications à l’outil MCP local Orelius ecrire_fichier(chemin, contenu). Le plugin contrôle le chemin, archive le contenu original et une copie exacte du nouveau texte, puis publie lui-même le fichier de manière atomique. La version générée est conservée dès la première création pour permettre un diff avec les corrections humaines ultérieures. L’arborescence est reproduite et chaque copie reçoit une date et un identifiant distincts : avec les noms par défaut, Manuscript/Chapitres/texte.md devient par exemple Archives/Manuscript/Chapitres/texte.<date>-<identifiant>.md. Les fichiers de la bible sont conservés sous Archives/Bible/. Les versions précédentes sont conservées. Si l’archivage échoue ou si la note contient des modifications non enregistrées dans l’éditeur, l’écriture est refusée. Une création n’a pas d’original à archiver, mais son texte généré est archivé avant publication. Le plugin confirme le résultat à Codex après l’écriture et l’enregistrement de la référence de suivi.

Les commandes de Codex restent dans un bac à sable en lecture seule. Les écritures directes, patches et extensions de permissions sont refusés automatiquement ; seules les écritures du plugin passent. Le serveur MCP Orelius est intégré au processus Obsidian, écoute uniquement sur 127.0.0.1 avec un jeton éphémère et reste lié à la tâche active. Le jeton est transmis à Codex par une variable d’environnement ; il n’est pas enregistré dans la configuration ou l’historique. Les autres serveurs MCP, apps, plugins Codex et la délégation sont désactivés dans le processus lancé par Orelius. La configuration globale de Codex n’est pas modifiée. L’outil est également disponible à la reprise des conversations existantes. Les suppressions, déplacements, liens symboliques et modifications du dossier d’archives configuré, de _Archives, du dossier de configuration réel d’Obsidian ou de .git ne sont pas pris en charge. Les lectures utilisent les permissions de Codex : choisir un dossier de travail ne constitue pas une restriction de lecture à ce dossier. Une réponse textuelle dans le chat ne crée pas de texte littéraire sans demande ; les attentes éditoriales nouvelles peuvent enrichir la base de connaissances du suivi.

Messages et questions partagent une zone de défilement ; les commandes et le champ de saisie restent visibles. Le panneau suit les nouvelles réponses tant que vous restez en bas de la conversation ; remonter permet de relire l’historique. Le contenu précédent reste affiché pendant la préparation du nouveau rendu Markdown et le suivi tient compte des changements de taille, notamment au chargement des images. Une question en attente devient visible avec son champ de réponse, ses choix éventuels et le bouton Répondre. La touche Entrée valide le formulaire de réponse.

Les messages d’activité sont masqués par défaut. Le réglage Afficher les messages d’activité permet de les afficher ou de les masquer immédiatement, y compris les activités déjà reçues. Ce choix est enregistré automatiquement ; l’indicateur de travail, les erreurs et les questions de Codex restent visibles.

Sous chaque réponse finale de Codex, les boutons cœur, pouce levé et pouce baissé permettent de noter l’échange. Le texte éventuellement saisi dans le chat accompagne la réaction, mot pour mot. Une note reste sélectionnée après réouverture ; la changer remplace l’avis courant dans la base de connaissances et conserve les avis précédents dans les relevés horodatés de Bible/Suivi/. Chaque relevé conserve les demandes, la réponse évaluée et les précisions de l’auteur. Codex peut en tirer des consignes et des exemples de ce qu’il faut reproduire ou éviter lors des prochains échanges, sans réentraîner le modèle. Noter ne lance aucune requête au modèle et ne retire pas le surlignage du manuscrit.

Une gomme Effacer le surlignage apparaît après ces trois réactions lorsque le chapitre ouvert contient des marques de révision. Elle retire les marques de ce chapitre, y compris après réouverture, sans accepter les modifications ni enregistrer d’avis. Le texte, les références de diff et le message en préparation dans le chat sont conservés.

Les réglages et l’identifiant de la conversation de chaque dossier sont enregistrés dans les données du plugin. Revenir dans un dossier retrouve sa conversation, y compris après un redémarrage d’Obsidian. L’historique reste géré par Codex et est rechargé à la reprise. Nouvelle conversation remplace uniquement l’association du dossier actif ; les anciens historiques restent dans Codex. Une conversation enregistrée avec l’ancien format est conservée pour son dossier. Les messages et les documents que Codex consulte peuvent être transmis au fournisseur configuré dans Codex. Orelius ne conserve aucune clé d’API.

Agent du projet

Le journal Bible/Suivi/Conversation.md conserve les prompts de l’utilisateur et les réponses finales de Codex, sous des titres de date comme # Lundi 26 octobre 2026. Les commentaires intermédiaires, raisonnements, commandes et événements techniques sont exclus. Il est actualisé après chaque tâche terminée et à la reprise d’une session, à partir de l’historique Codex. Les anciennes sessions du même projet sont conservées ; reprendre la même session ne crée aucun doublon. Les dates manquantes dans un ancien historique sont indiquées comme inconnues. Pour les anciens messages sans phase, seul le dernier message assistant d’un échange terminé est retenu. Le nom de la bible suit les réglages. Le plugin gère les sections de session du journal ; les notes personnelles placées ailleurs sont conservées et chaque modification archive d’abord l’original.

Bible/Style/Narration.md définit le mode narratif et le style narratif des textes romanesques. Si ce fichier manque et que l’ancien Bible/Narration.md existe, son contenu est copié vers le nouvel emplacement en conservant l’ancien fichier. Sinon, le plugin crée un canevas à compléter. Une narration déjà présente dans Style est conservée. Bible/Personnages/ accueille les fiches générales des personnages : identité, caractère, parcours et relations. Codex consulte la narration et les fiches pertinentes avant d’écrire ou de réviser, pour respecter le point de vue, les temps du récit et la continuité des personnages. Ces chemins suivent le nom de bible configuré ; les documents existants sont conservés.

Le dossier Bible/Style/ accueille les consignes d’écriture de l’auteur et, éventuellement, des textes exemples. Codex les consulte avant d’écrire ou de réviser, en distinguant les consignes explicites des préférences déduites des exemples. Le nom de la bible suit les réglages ; le dossier Style et son miroir dans les archives sont créés automatiquement, sans modifier les documents existants.

Le suivi des corrections est vérifié au retour dans le chat et juste avant chaque envoi, sans surveillance en temps réel. Le plugin garde comme référence le dernier texte de chaque chapitre effectivement écrit par Codex, y compris après redémarrage. Les coupes, réécritures, passages barrés ~~...~~ et commentaires (((destinés à Codex))) sont consignés dans des relevés horodatés sous Bible/Suivi/, indexés par Bible/suivi.md. Le nom de Bible suit le réglage du projet. Un texte inchangé ne produit aucun relevé supplémentaire. Les consignes personnelles de l’index sont conservées.

Codex construit aussi Bible/Suivi/Connaissances.md, une base éditoriale propre au projet, consultée à chaque demande et conservée entre les sessions. Il la crée dès qu’un enseignement utile apparaît dans un échange éditorial ou des corrections, puis la complète avant sa réponse finale. La synthèse distingue les consignes explicites, les hypothèses tirées des exemples et les contradictions ou évolutions. Chaque attente précise sa portée, sa date et ses sources ; une coupe isolée ne devient pas une règle générale. Les demandes actuelles de l’auteur priment, les attentes remplacées sont signalées et les notes personnelles sont conservées. Sans enseignement nouveau, le fichier reste inchangé. Ce fichier peut être écrit par Codex via l’outil du plugin, avec archivage de l’original et du résultat ; les relevés horodatés, leur index et le journal restent protégés. Aucun apprentissage n’est lancé en temps réel ou en arrière-plan : la synthèse est réalisée par Codex pendant les demandes, sans modification des paramètres du modèle.

La création d’un relevé ne modifie pas le chapitre. Avant une réécriture demandée par Codex, le texte actuel est archivé ; s’il diffère de la référence Codex, le nom de cette version humaine se termine par -h.md. Le nouveau texte produit par Codex possède ensuite sa propre copie archivée, sans suffixe -h, préparée avant publication. Les références utilisées par le suivi sont aussi enregistrées dans les données locales du plugin. Un chapitre écrit avant l’installation de ce suivi n’a pas de référence fiable : la comparaison devient disponible après sa prochaine écriture par Codex. Les relevés conservent les différences observées ; ils ne fabriquent aucune conclusion stylistique. Le modèle d’agent demande à Codex de les consulter avant une reprise ou un nouveau passage.

Le générateur generate-agent.ts, à la racine de ce dépôt, crée AGENTS.md à la racine de chaque projet d’écriture lors de sa préparation. Le modèle prompts/agent.md décrit les dossiers et le rôle de l’assistant d’écriture. Ses variables {folder}, {manuscriptFolder}, {modelFolder}, {bibleFolder} et {archiveFolder} reçoivent les valeurs des réglages du plugin ; toute variable inconnue est signalée.

Le générateur gère uniquement la section comprise entre <!-- orelius:agent:start --> et <!-- orelius:agent:end -->. Les consignes personnelles situées ailleurs sont conservées. Si le fichier existe sans ces marqueurs, la section est ajoutée à la suite. Chaque modification d’un AGENTS.md existant conserve d’abord son original dans le sous-dossier Agents du dossier d’archives configuré, soit Archives/Agents/ par défaut. Une génération identique ne modifie rien. Des marqueurs incomplets, un lien ou un échec d’archivage bloquent la mise à jour.

Le même modèle alimente le contexte envoyé à Codex lors de l’ouverture ou de la reprise d’une session, pour que les dossiers et le rôle restent cohérents avec les réglages actuels. Après modification du modèle, recompilez puis rechargez le plugin.

Développement

Obsidian 1.7.2 ou plus récent, Node.js 24 ou plus récent et Codex CLI avec App Server sont nécessaires. La compatibilité dépend des échanges utilisés, sans blocage sur un numéro de version mineure ou majeure : initialisation, authentification, configuration et catalogue des modèles sont vérifiés à la connexion. Les réponses utilisées pour les permissions et la reprise restent contrôlées ; une nouvelle version ne désactive aucune protection d’archivage. Une méthode absente est signalée avec la version détectée et son nom. Tester Codex affiche la version du serveur connecté. Après une mise à jour de Codex, la connexion suivante lance l’exécutable installé et peut reprendre la conversation enregistrée ; une tâche déjà lancée continue avec son processus existant.

npm ci --ignore-scripts
npm run build
npm run check

Le dossier plugin/ contient les sources TypeScript, les styles, le manifeste et le fichier compilé du plugin. La compilation intègre le modèle Markdown dans plugin/main.js, puis copie main.js, manifest.json et styles.css à la racine du dépôt, qui sert ici de dossier d’installation Obsidian. Ces copies racine ne sont pas les sources à modifier. Pour une autre installation, copiez ces trois fichiers depuis plugin/ dans .obsidian/plugins/orelius/. Le générateur et le modèle sont intégrés au fichier compilé ; aucun fichier de développement supplémentaire n’est nécessaire dans le coffre cible. Les réglages du coffre restent dans son data.json.

Le contrôle vérifie le générateur d’agent, les réglages, la structure des projets, les archives et Codex local authentifié : dossier effectif, refus d’une écriture directe, reprise avec l’outil MCP Orelius, appel de cet outil avec archivage et arrêt des processus. Il n’envoie aucun message au modèle.

node scripts/check-session.mjs vérifie l’envoi d’une consigne pendant une tâche réelle : ce contrôle appelle le modèle, écrit uniquement dans un projet temporaire et vérifie les fichiers, les archives humaines et générées ainsi que le journal. Il vérifie aussi la création de connaissances éditoriales et leur enrichissement après reprise, en conservant une note personnelle, puis supprime sa session de test.

Pour tester le panneau et les réglages dans une instance Obsidian isolée, utilisez npm run check:obsidian. Ce contrôle macOS crée un coffre temporaire, envoie un court message au modèle via Codex, puis vérifie l’affichage de la réponse et sa reprise après rechargement. Il ferme son instance de test et conserve une capture dans le dossier temporaire indiqué. Les essais ont été réalisés avec Obsidian 1.12.4.

Le code est réparti entre l’intégration Obsidian, les données des réglages, leur interface, le panneau de chat, la connexion Codex, la conversation, le serveur MCP local et l’archivage des originaux. Ce socle ne comprend pas encore les sélecteurs de zones et d’anciennes conversations ni les fonctions littéraires avancées décrites dans le cahier des charges.

Publication

Le script release.sh reprend celui de Bookbinder. Lancez ./release.sh depuis la branche par défaut : il exécute les contrôles et la compilation, commite et pousse les modifications en cours, incrémente la version corrective, synchronise les deux manifestes et le paquet npm, puis crée et pousse le commit de version et son tag. La version de départ est celle de manifest.json. GitHub Actions compile depuis ce tag et publie main.js, manifest.json et styles.css comme pièces jointes de la release. Le workflow reprend aussi les contrôles de reproductibilité, de taille et les attestations de provenance de Bookbinder.

Prérequis locaux : Node.js 24 ou ultérieur, npm, Git, jq, GitHub CLI authentifié et Codex authentifié pour npm run check. Les tests de publication utilisent Ruby pour lire le workflow YAML ; aucune requête au modèle n’est envoyée. GitHub Actions vérifie aussi le script avec ShellCheck.

La soumission initiale à Obsidian se fait après la création de la première release GitHub. Les versions suivantes utilisent le même script.

Livres d’exemple sur le web

Le lecteur statique dans scripts/web utilise epub.js. L’accueil présente uniquement les titres disponibles. Un clic ouvre le livre en pleine fenêtre, au format livre paginé par défaut. Les pages se tournent avec les flèches du clavier, par balayage tactile ou par un clic sur les bords du texte. Le seul bouton visible en lecture ouvre un menu hamburger : taille du texte, choix d’une police locale, format livre ou défilement continu, sommaire et retour à l’accueil. Le changement de format conserve la position de lecture. Les scripts embarqués dans les EPUB restent désactivés. Les versions d’epub.js et de JSZip chargées depuis le CDN sont figées et vérifiées par une empreinte d’intégrité.

Déposer les livres à publier dans samples, à la racine du dépôt. Les sous-dossiers et les noms avec espaces ou accents sont acceptés. Le catalogue utilise les noms des fichiers ; le titre du livre ouvert provient de ses métadonnées EPUB.

npm run check:web
npm run build:web
python3 -m http.server 8000 --directory _site

Ouvrir ensuite http://localhost:8000. La génération utilise seulement Node.js ; les contrôles utilisent aussi Ruby, comme les tests de publication du plugin. Le dossier _site/ contient uniquement les fichiers du site, son catalogue et les EPUB de samples/. Il est généré et ignoré par Git.

Pour la première publication, sélectionner Settings → Pages → Build and deployment → Source → GitHub Actions dans le dépôt GitHub. Le workflow Pages publie ensuite les modifications du lecteur et de samples/ poussées sur main. Il peut aussi être lancé manuellement depuis Actions. L’adresse prévue est tcrouzet.github.io/orelius.

Références techniques

• Codex Panel, licence Apache-2.0 : transport local app-server et séparation de la connexion et de l’interface.
• Codex AI Agent, licence MIT : événements de conversation et demandes d’autorisation.
• Documentation officielle OpenAI — Codex App Server et schémas produits par l’exécutable local : initialisation, sessions, historique paginé, permissions et interruption.
• Documentation officielle OpenAI — MCP et transport Streamable HTTP : outil d’écriture local, configuration par session et authentification.

Ces projets ont été examinés comme références ; aucun de leurs composants n’est requis à l’exécution.