knowledge-correct

Corriger les connaissances enregistrées via les outils de l'agent

Lisez les conventions partagées et la publication avant d'écrire.

Identifier l'enregistrement propriétaire

Utilisez un ID d'enregistrement/affirmation structuré fourni et une révision comme cible principale, et non seulement son libellé affiché. Lisez knowledge_record avec les métadonnées et les preuves ; confirmez sa révision/empreinte actuelle. Une révision référencée qui a changé nécessite de relire et de concilier la demande, et non d'agir silencieusement sur une nouvelle assertion. Sans référence exacte, utilisez la recherche/l'exploration, inspectez les candidats, et ne demandez que lorsque la cible ou la correction demandée reste matériellement ambiguë.

Distinguer une affirmation enregistrée erronée d'une réponse non étayée, de déclarations sources contradictoires et d'un fait qui a changé avec le temps. La contradiction seule n'autorise pas la substitution ; le seul cas non-utilisateur est une déclaration permanente que son propre détenteur a explicitement remplacée, conformément à la publication. Ne fabriquez pas de « fait de garde » stocké quand aucun enregistrement n'existe, et ne traitez pas un retrait comme une preuve de son contraire.

Appliquer la bonne opération

• Correction d'affirmation ou de relation explicite : appelez knowledge_correct avec l'ID exact, expectedRevision et expectedHash observés, la raison, l'UUID de l'espace de travail et l'empreinte de l'ontologie observés, et un replacement complet de même kind. Les champs de remplacement utilisent le contrat de création d'affirmation/de relation ; il y a un ID de demande externe, pas un deuxième ID de demande de remplacement. Préservez le contexte pris en charge, l'attribution, les dates précises et les preuves ; supprimez ou révisez ce que la correction modifie réellement. L'opération publie le remplacement et remplace l'ancienne assertion ensemble, avec des liens dans les deux directions.
• Retrait sans remplacement : appelez knowledge_withdraw avec l'ID exact, la révision/empreinte, la raison et l'UUID de l'espace de travail. Il accepte les pages, les affirmations et les relations explicites. Une arête est identifiée par son propre ID, et non par sa paire de nœuds d'extrémité. Il préserve les preuves/l'historique d'origine et n'est pas une suppression de fichier.
• Correction de texte de page : utilisez knowledge_save_page avec une révision ordinaire, en préservant le contenu non concerné et les sources. Les corrections de page sont des révisions, et non des identités d'entité de remplacement.
• Deux pages pour une même entité : appelez knowledge_merge avec la page survivante, le doublon, la révision/empreinte actuelle des deux pages et une raison. Conservez la page avec l'identité la plus complète (nom réel, plus de connexions) comme survivante ; passez title pour la renommer et body quand la page combinée doit en dire plus que le texte actuel de la survivante. L'ID, le titre, les alias, les affirmations, les relations et les liens du doublon sont alors résolus vers la survivante ; rien n'est corrigé un par un. Annulez une fusion erronée avec knowledge_unmerge.

Une correction explicite de l'utilisateur peut fournir des preuves : conservez sa déclaration exacte avec knowledge_attach, attribuez-la à l'utilisateur et référencez son localisateur vérifié. Utilisez assertion_origin: user_belief pour distinguer une assertion utilisateur d'une déclaration sourcée indépendamment ; ne revendiquez pas de vérification documentaire. L'inférence de l'agent a toujours besoin de preuves de prémisse conservées, et non d'une citation inventée.

Résoudre un pseudonyme ou une identité erronée

Utilisez knowledge-entities pour trouver et lire le profil du pseudonyme, la personne établie et ses enregistrements connexes. Conservez l'identification exacte de l'utilisateur comme preuve. Mettez à jour les alias pris en charge et le contexte d'identité sur les pages existantes ; préservez le contenu non concerné et décrivez le lien avec la personne établie. Utilisez l'ID existant de cette personne pour les enrichissements futurs. Lorsque le pseudonyme a déjà sa propre page, fusionnez-la dans la page de la personne établie avec knowledge_merge au lieu d'écrire une page pointeur, de la retirer ou de corriger ses affirmations une par une. Ne fusionnez que sur la base d'une preuve d'identité (la déclaration de l'utilisateur, une auto-présentation, un identifiant de compte stable partagé), jamais sur la similitude de nom ; knowledge_diagnostics mergeCandidates liste les pages à vérifier, pas les pages à fusionner. Conservez la preuve d'identité avec knowledge_attach et transmettez-la comme evidence.

Inspectez le texte, les affirmations, les chronologies et les relations affectés dans le périmètre de la correction. Corrigez l'attribution erronée et l'identité non résolue là où les nouvelles preuves le permettent, en utilisant les opérations de page/d'affirmation ci-dessus ; préservez les étiquettes de source, les citations textuelles, les dates d'événement et la provenance de la correction. Une identité d'auteur confirmée ne vérifie pas indépendamment les affirmations factuelles de cet auteur.

Les modifications passent par ces outils, et non par des éditions manuelles de Markdown, des formulaires de navigateur, SQL, ou des appels séparés « créer puis retirer ». Aucun rituel d'approbation supplémentaire ne s'applique à une correction non ambiguë autorisée par l'utilisateur. Suivez la gestion des tentatives/conflits de publication ; un reçu à l'état accepté/conflit n'est pas une réparation terminée.

Inspecter la propagation et rapporter honnêtement

Le impact.items du reçu identifie les dépendants directs/transitifs connus à l'acceptation. Il ne les met pas à jour. Lisez les enregistrements affectés par ID exact et inspectez leurs preuves. Ne réparez que les changements pris en charge dans le périmètre de la demande ; ne remplacez pas aveuglément les ID de dépendance ou les citations sources par la nouvelle affirmation. Les enregistrements dépendant d'une assertion inactive sont exclus de la découverte courante jusqu'à leur réparation ; l'inspection exacte des enregistrements/de l'historique reste disponible.

Recherchez les copies textuelles plausibles comme vérification complémentaire. Les échecs de recherche, le texte non lié, les périmètres cachés et les index incomplets empêchent une promesse universelle de « toutes les copies corrigées ». Ne modifiez pas les systèmes de mémoire ou d'identité non liés comme conséquence automatique d'une correction de Connaissances.

Relisez l'original et le remplacement (ou la cible retirée), vérifiez le cycle de vie et les preuves, et vérifiez que la recherche actuelle exclut l'ancienne assertion. Répondez avec l'ID du reçu/de la demande, les ID des enregistrements affectés, la raison de la correction/du retrait, et les dépendances réparées par rapport à celles non résolues. Ne mentionnez l'historique conservé que lorsque cela est pertinent ; ne promettez jamais d'effacement des originaux, des exportations ou des sauvegardes.