scchearn/loam

Utiliser loam

Ceci est le routeur pour l'espace de noms de la compétence loam. Il n'effectue pas de travail lui-même. Il vous indique quelle compétence loam invoquer pour une intention donnée, ainsi que les règles qui s'appliquent à toutes.

Ceci est une compétence de routage/méta-compétence. Lorsque vous reconnaissez la compétence correspondante, invoquez-la via le chargeur de compétences du hôte hôte. N'effectuez pas le travail ici.

Non-négociables

Trois règles maintiennent le travail loam aligné sur le modèle mémoire.

1. Invoquez la compétence concernée avant toute action loam. Pas seulement les appels d'outils. Avant de planifier, rechercher, commencer, reprendre, vérifier, débattre ou parvenir à un consensus, modifier un plan, ajouter à la mémoire, interroger la mémoire, modifier la mémoire, linter la mémoire, normaliser la mémoire, réviser la mémoire, capturer les apprentissages, auditer les directives, échafauder le wiki ou initialiser un coffre : invoquez la compétence correspondante. Ce document est un routeur. Le corps de la compétence contient les règles réelles. La responsabilité vous incombe pour tout le reste. En cas de doute, invoquez.
2. Mémoire d'abord, substrat ensuite. Parlez de « mémoire » en premier. N'utilisez « wiki » que pour distinguer le substrat markdown des substrats de directives ou de points de contrôle. Ne dites jamais « le wiki » quand vous voulez dire « mémoire » — le wiki est un substrat de la mémoire, pas la totalité.
3. Écritures mémoire détenues par l'agent. L'agent écrit, corrige, route et archive la mémoire sans pré-approbation. L'humain peut signaler un contenu obsolète ou erroné, ce qui déclenche le même flux de correction qu'une contradiction découverte par l'agent.

Le modèle mémoire

La mémoire est le concept générique pour tout ce que loam capture. Trois substrats existent :

Substrat	Ce que c'est	Qui le maintient
wiki	Notes markdown durables compatibles Obsidian sous wiki/. Pages de sujet, d'entité, de concept, d'analyse.	Groupe loam-memory (la plupart des compétences)
guidage	AGENTS.md est le fichier de directives canonique. CLAUDE.md est un import shim léger (@AGENTS.md uniquement). .claude.local.md pour les surcharges personnelles.	Groupe loam-memory (auditing-guidance, learning-from-session chemin de directives)
points de contrôle	État de travail transitoire sous wiki/checkpoints/. Notes de redémarrage, pas de connaissance durable.	Groupe loam-work (checkpointing écrit, resuming lit)

Le substrat wiki est ce que qmd indexe. Le substrat guidage est ce que les hôtes chargent comme contexte d'invite. Les points de contrôle sont un état de travail, pas une connaissance — ils refusent de toucher index.md ou log.md et ne doivent pas devenir des affirmations durables.

Parlez de « mémoire » en premier. N'utilisez « wiki » que lorsque la distinction de substrat importe. Une compétence qui opère sur les notes markdown travaille sur le substrat wiki de la mémoire. Une compétence qui édite AGENTS.md travaille sur le substrat guidage de la mémoire. Les deux sont de la mémoire.

Grille d'admission en mémoire durable

Utilisez cette grille avant de créer une page wiki. Les compétences créant des pages référencent cette section au lieu de la copier.

Une affirmation mérite une page wiki uniquement si elle passe les trois critères :

• R1 Réutilisable — une session future sur une tâche différente en aurait plausiblement besoin.
• R2 À propos du projet/domaine — codebase, architecture, décisions, conventions, dépendances externes, ou faits externes durables ; pas la conversation, l'agent, ou l'état utilisateur transitoire.
• R3 Coûteux à reconstruire & re-vérifiable — re-dériver l'affirmation à partir d'une source vivante (code, config, calendrier, liste de tâches) coûterait plus que ce que la page coûte à maintenir. Si une commande ou une lecture de fichier la retrouve, elle ne mérite pas de page. Lorsqu'une source externe existe, la page la nomme afin que la fraîcheur puisse revalider. Les décisions pures et les justifications sont auto-sourcées et satisfont ce critère en énonçant leur raisonnement.

Les disqualifiants remplacent la grille :

• D1 éphémère — état de build, branche courante, « aujourd'hui j'ai exécuté X » -> rapport opérationnel.
• D2 doublon — une page existante le couvre -> modifiez la page existante au lieu d'en créer une autre.

Départage : admettez si non reconstruisible à partir d'une source vivante ; rejetez si reconstruisible. wiki/.archive/ est uniquement pour le contenu qui était durable mais maintenant remplacé. Le matériel jamais durable n'est pas écrit dans le wiki et n'est jamais archivé.

Matrice de routage

Matériel	Destination	Chemin de compétence
Fait de projet/domaine réutilisable, passe la grille	page wiki durable	loam::adding-to-memory, auto-correction
Convention/commande/astuce de comportement d'agent	AGENTS.md / CLAUDE.md	loam::learning-from-session chemin de directives
État de session pour reprise/transfert	wiki/checkpoints/<slug>.md	loam::checkpointing
Contexte par tâche attaché à une unité de travail	annotation de tâche / fichier de plan	loam::planning, loam::starting
Sortie de build, état de branche, ponctuel, non vérifiable, ou échec de la grille	rejeter, optionnellement avec une ligne de journal log.md	aucun

Déclencheurs d'auto-correction et de signalement humain

• Auto-correction : lorsque l'agent lit la mémoire et trouve une contradiction avec les preuves actuelles, déplacez la page durable remplacée vers wiki/.archive/ avec un en-tête d'archivage, écrivez la correction à l'emplacement actif, ajoutez une entrée self-correct à log.md, et continuez la tâche d'origine.
• Signalement humain : lorsque l'humain dit qu'une page mémoire est erronée ou obsolète, traitez cela comme un déclencheur de correction, pas une demande d'approbation. Lisez la page signalée et les preuves actuelles, archivez la page durable remplacée, écrivez la correction, enregistrez-la, et rapportez ce qui a changé.
• Périmètre d'archivage : .archive/ est uniquement pour les pages qui étaient durables et sont devenues erronées, obsolètes ou remplacées. Le matériel jamais durable est routé ailleurs ou rejeté.

Déclencheurs de validation de fraîcheur

Utilisez updated_at existant plus les preuves de lint ; n'ajoutez pas de métadonnées de fraîcheur.

• F1 un chemin de fichier cité a changé depuis updated_at de la page.
• F2 un refactoring, renommage, suppression ou migration a touché un chemin référencé (loam::syncing-code-graph --touched).
• F3 une version épinglée, API ou documentation externe que la page nomme a une mention plus récente.
• F4 updated_at est plus ancien que 90 jours et la page cite des surfaces volatiles telles que des API, configurations, versions ou chemins de code. Le lint signale cela pour revalidation et n'archive pas automatiquement.
• F5 contradiction à la lecture, gérée par auto-correction.

Le résultat de validation est l'un des : confirmé (mettez à jour updated_at), corrigé (archive + réécriture + journal), ou rétrogradé (archive avec la raison « ne s'applique plus »).

Drapeaux rouges : pensées qui signifient STOP et invoquer

Ces rationalisations font que les compétences sont sautées. Si vous vous surprenez à penser à l'une d'elles, invoquez la compétence concernée même si vous l'avez « déjà lue » plus tôt dans la session.

Pensée	Action
« Je vais juste écrire ceci dans le wiki »	Invoquez loam-adding-to-memory. Appliquez la grille d'admission, puis écrivez ou routez.
« Je vais juste le planifier, c'est simple »	Invoquez loam-writing-spec. Les specs sont requises avant loam-planning.
« Je vais juste lancer un petit débat entre agents »	Invoquez loam-configuring-agents. Les débats sont verrouillés par approbation ; pas d'envois avant la porte.
« Je vais juste éditer ce plan directement »	Invoquez loam-amending-plan. Les changements de plan se répercutent ; la compétence évalue l'impact.
« Je vais écrire cette page mémoire parce que cela pourrait aider plus tard »	Appliquez d'abord la grille d'admission. Si elle échoue, routez ou rejetez.
« Le wiki est obsolète, je vais le corriger en ligne »	Archivez la page durable remplacée, écrivez la correction, enregistrez-la et continuez.
« Je vais juste capturer cet apprentissage comme une note »	Invoquez loam-learning-from-session. Cela route vers wiki ou guidage, pas vous.
« Je vais juste vérifier le wiki rapidement »	Invoquez loam-querying-memory. Restez ancré dans la mémoire, pas dans un contexte obsolète.
« Je vais juste ajouter cette commande à AGENTS.md »	Invoquez loam-learning-from-session (chemin de guidage) ou loam-auditing-guidance pour un audit complet.
« Je vais juste m'arrêter et reprendre plus tard »	Invoquez loam-checkpointing. Un point de contrôle est un artefact reprisable, pas une note mentale.
« Je vais reprendre là où je me suis arrêté »	Invoquez loam-resuming. Vérifiez l'état actif avant d'agir.
« Je vais configurer le wiki »	Invoquez loam-scaffolding-wiki d'abord, puis loam-initializing-vault pour la config Obsidian.

Le cycle de vie loam

Pour toute tâche loam :

1. Orientez. Reconnaissez la compétence correspondante à partir du graphe de décision ci-dessous. Si deux compétences semblent pertinentes, appliquez les règles de précédence.
2. Choisissez la compétence. Invoquez-la via le chargeur de compétences du hôte hôte.
3. Préservez les limites de substrat. N'écrivez pas de points de contrôle dans des pages durables. N'écrivez pas de guidage dans des pages wiki. N'écrivez pas de contenu wiki dans AGENTS.md. Chaque substrat a sa compétence.
4. Appliquez l'admission et le routage avant les écritures mémoire. Les pages wiki durables doivent passer la grille ; tout le reste va au guidage, aux points de contrôle, aux annotations de tâche, ou est rejeté.
5. Mettez à jour plans / points de contrôle / guidage uniquement via la compétence correspondante. N'éditez pas un plan en ligne — utilisez loam-amending-plan. N'écrivez pas un point de contrôle en ligne — utilisez loam-checkpointing. N'éditez pas AGENTS.md en ligne — utilisez loam-learning-from-session ou loam-auditing-guidance.

Règles de conflit (quand deux compétences semblent pertinentes)

• Les compétences de processus / travail courant gagnent avant les compétences de maintenance mémoire. Si vous êtes en cours d'exécution et découvrez un problème mémoire, terminez d'abord l'étape de travail courant (ou vérifiez-la), puis invoquez la compétence mémoire.
• Les écritures mémoire sont détenues par l'agent. Si le travail courant produit un apprentissage, routez-le via la matrice ; s'il expose une mémoire obsolète, corrigez-le en ligne avec archive + journal.
• Les points de contrôle sont transitoires. Ils vivent sous wiki/checkpoints/ mais ne sont pas des affirmations durables. Ils refusent de mettre à jour index.md ou log.md. Ne promouvez pas un point de contrôle en note durable sans passer par loam-adding-to-memory.
• Amender vs linter. loam-amending-memory corrige des affirmations erronées spécifiques. loam-linting-memory vérifie la santé de l'ensemble du graphe. Si vous avez trouvé une erreur spécifique, amendez. Si vous voulez une vérification générale, lintez.
• Interroger vs réviser. loam-querying-memory répond à une question. loam-reviewing-memory fait apparaître les lacunes. Si vous voulez une réponse, interrogez. Si vous voulez savoir ce qui n'est pas résolu, révisez.
• Ajouter vs apprendre. loam-adding-to-memory ingère une source (fichier, article, conversation-en-tant-que-note). loam-learning-from-session capture les informations issues de la session et les route vers wiki ou guidage. Si vous avez une source, ajoutez. Si la session a produit une information, apprenez.

Graphe de décision

« Je veux... »
├─ commencer quelque chose de nouveau
│  ├─ rechercher une question ──────────── /loam::writing-spec
│  ├─ planifier un travail approuvé ────── /loam::planning
│  └─ débattre / parvenir à un consensus ─ /loam::configuring-agents
├─ exécuter un travail
│  ├─ commencer un plan ─────────────────── /loam::starting
│  ├─ faire une pause / transférer ──────── /loam::checkpointing
│  ├─ reprendre après une pause ────────── /loam::resuming
│  └─ modifier un plan en cours ────────── /loam::amending-plan
├─ travailler avec la mémoire
│  ├─ ajouter une source ────────────────── /loam::adding-to-memory
│  ├─ ingérer une codebase ─────────────── /loam::ingesting-codebase
│  ├─ synchroniser la dérive du graphe de code ─ /loam::syncing-code-graph
│  ├─ poser une question ────────────────── /loam::querying-memory
│  ├─ corriger ce qui ne va pas ────────── /loam::amending-memory
│  ├─ vérifier la santé ─────────────────── /loam::linting-memory
│  ├─ normaliser un corpus désordonné ──── /loam::normalizing-memory
│  ├─ voir ce qui n'est pas résolu ──────── /loam::reviewing-memory
│  ├─ capturer les apprentissages de session ─ /loam::learning-from-session
│  └─ auditer les directives de l'agent ─── /loam::auditing-guidance
└─ configurer le substrat
   ├─ échafauder le wiki ─────────────────── /loam::scaffolding-wiki
   └─ initialiser le coffre Obsidian ───── /loam::initializing-vault

Note de précédence pour les cas ambigus

Si une intention correspond à deux compétences, l'arbre ci-dessus est le routeur principal. Lorsque l'arbre ne lève pas l'ambiguïté, appliquez les règles de conflit dans la section cycle de vie. Si vous êtes toujours incertain : demandez à l'utilisateur quelle intention est la plus proche.

Référence compacte des compétences

Une ligne par compétence. Le graphe de décision est le routeur principal ; ceci est pour une consultation rapide.

• loam-writing-spec — rechercher une question, produire specs/<slug>.md
• loam-planning — compiler une spec approuvée en plan prêt à exécuter
• loam-starting — commencer ou reprendre l'exécution d'un plan
• loam-resuming — reprendre à partir de notes de point de contrôle
• loam-checkpointing — écrire un point de contrôle reprisable avant une pause
• loam-configuring-agents — exécuter un débat structuré ou une conférence entre agents, soumis à approbation, avec des positions distinctes et un livrable de convergence
• loam-amending-plan — mettre à jour un plan en cours après un changement de périmètre
• loam-adding-to-memory — ingérer une source dans la mémoire (substrat wiki)
• loam-ingesting-codebase — ingérer une codebase sous forme de pages d'entités avec des arêtes wikilink
• loam-syncing-code-graph — reconcilier le graphe de code avec le dépôt à une porte de plan ou à la demande
• loam-querying-memory — répondre à une question à partir de la mémoire
• loam-amending-memory — corriger des affirmations mémoire spécifiques, erronées ou obsolètes
• loam-linting-memory — vérifier la santé du graphe mémoire
• loam-normalizing-memory — rétro-ingénierie de la structure sur un corpus mémoire désordonné
• loam-reviewing-memory — faire apparaître les lacunes non résolues dans la mémoire
• loam-learning-from-session — capturer les apprentissages de session, router vers wiki ou guidage
• loam-auditing-guidance — auditer et améliorer AGENTS.md / CLAUDE.md / .claude.local.md
• loam-scaffolding-wiki — instancier un nouvel échafaudage de substrat wiki
• loam-initializing-vault — configurer un coffre Obsidian avec configuration

Installation des commandes slash

Si l'utilisateur souhaite /checkpoint et /resume comme commandes raccourcies (au lieu de taper /loam::checkpointing et /loam::resuming), vous pouvez les installer. Les fichiers de commande sont livrés dans le dépôt loam sous commands/.

Lisez references/commands-install.md pour le protocole complet. Il couvre :

• Quel hôte vous utilisez (signaux de détection)
• Quel format de commande votre hôte attend (markdown vs TOML)
• Où installer (global vs local au projet)
• Le protocole demander-permission-avant-de-copier

Les fichiers de commande sont regroupés en tant qu'actifs sous assets/commands/

…

[tronqué pour la traduction]