knowledge-unlinked-claims

Examiner les revendications non liées

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

knowledge_remember enregistre une revendication sans page sujet lorsqu'aucun nom qu'elle contient ne correspond exactement à une page. Une maintenance planifiée exécute alors knowledge_relink, qui ne lie que les revendications dont la page source enregistrée est une page d'entité ou dont le texte nomme exactement une page. Le reste reste non lié et est invisible depuis les pages concernées. Cette compétence traite ce résidu avec discernement. Travaillez dans cet ordre : lier, puis doublons et revendications remplacées, puis prose de page.

1. Énumérer le résidu

Appelez knowledge_status pour le périmètre prévu et knowledge_ontology pour l'empreinte actuelle. Exécutez d'abord knowledge_relink sans dryRun pour que chaque revendication mémorisée qu'elle peut lier soit liée. Listez ensuite le résidu avec knowledge_relink dryRun: true, include: "all" et limit: 10, en suivant nextCursor : chaque revendication actuelle sans page liée et sans page source, quel que soit l'outil qui l'a enregistrée. Chaque appel rapporte au maximum 10 exemples par résultat, donc une limite de 10 renvoie chaque revendication examinée.

Lisez chaque revendication avec knowledge_record et metadataView: "full". Son subject_hint, lorsqu'il est présent, est la propre description de l'enregistreur de ce dont parle la revendication et l'indice le plus fort de son sujet. Regroupez les revendications par ce dont elles parlent (une fonctionnalité, une PR, un fil de décision, une personne ou une préférence) avant de choisir les pages. La plupart des revendications n'ont de sens qu'à côté de leurs voisines : une série d'instantanés d'état concernant une PR se termine généralement par une revendication de résultat.

2. Choisir les pages sujets

Pour chaque groupe, trouvez les pages candidates avec knowledge_grep et knowledge_lookup, et lisez leur État et leur Chronologie. Ignorez les pages retirées et les pages de fixture.

• Le sujet principal est ce sur quoi la revendication affirme quelque chose. Ajoutez un sujet secondaire uniquement lorsque la revendication énonce également quelque chose à propos de cette entité, comme la personne qui a pris la décision ou l'entreprise dont le produit a été configuré. Une mention passagère n'est pas un sujet. Deux ou trois sujets suffisent généralement.
• Une préférence ou une décision énoncée par une personne appartient à la page de cette personne. Ne transformez pas la préférence d'une personne en politique de projet ou d'entreprise.
• Faites correspondre l'identité sur des preuves, pas sur des noms similaires. Lorsqu'une revendication nomme quelque chose qui pourrait être une page existante (par exemple un nom de produit qui pourrait être un service différent), confirmez-le à partir de preuves telles que la configuration, une URL ou les alias de la page elle-même. Si l'incertitude persiste, laissez la revendication non liée et signalez-la.

Liez avec knowledge_annotate entities, en passant la liste complète (elle remplace la liste existante) et la révision et le hachage actuels de la revendication. Le texte d'assertion, les preuves et le cycle de vie restent inchangés.

3. Créer les pages manquantes

Lier chaque revendication à la page existante la plus proche peut enterrer un véritable sujet dans la Chronologie d'une page large. Créez une page lorsque :

• un sujet discret (une fonctionnalité, un projet, un outil ou une PR substantielle) a environ cinq revendications ou plus, ou a son propre historique de conception, de preuve et de résultat ; ou
• une personne ou organisation a écrit, possède ou a décidé quelque chose dans les revendications, n'a pas de page, et possède des preuves d'identité (par exemple l'auteur de la PR montré par gh pr view).

Ne créez pas de page pour une seule mention ou un correctif ponctuel qu'une entrée de Chronologie couvre. Utilisez knowledge_save_page avec le type de l'ontologie, les alias, et la preuve d'identité comme source. Les pages de personnes utilisent identity.status: partial sauf si l'identité est entièrement établie. Rédigez un court État qui cite les revendications et une Chronologie datée. Liez ensuite les revendications à la nouvelle page, en conservant leurs sujets existants comme sujets secondaires, et liez la nouvelle page depuis sa page parente.

4. Retirer les doublons et les revendications remplacées

• Doublon : deux revendications affirment le même fait, la même décision ou la même préférence concernant le même événement. Gardez celle dont le rappel est approuvé par le propriétaire, sinon la plus ancienne, sinon celle avec l'attribution la plus complète. Copiez toute preuve manquante au survivant avec knowledge_annotate addEvidence, puis knowledge_withdraw l'autre avec une raison qui nomme l'ID du survivant.
• Remplacé : une revendication ultérieure corrige explicitement la précédente (par exemple un assistant corrigeant son propre rapport), décide d'une question que la revendication précédente laissait ouverte, ou rapporte l'état final du même élément spécifique (même PR, commit ou décision). Retirez la revendication précédente avec une raison qui nomme la revendication de remplacement. N'utilisez pas knowledge_correct ici : cela publie une nouvelle copie du remplacement, ce qui crée un autre doublon.
• Ni l'un ni l'autre : les instantanés de moments différents (CI rouge à un commit, un merge plus tard) sont de l'histoire, pas des erreurs. Gardez-les. La contradiction seule ne justifie pas un retrait. En cas de doute, gardez les deux et signalez la paire.

5. Mettre à jour la prose de la page

Lier rend les revendications accessibles depuis leurs pages ; cela ne change pas ce qu'une page dit. Modifiez une page uniquement lorsque les revendications changent son état durable : une décision, une préférence, un changement livré ou publié, une nouvelle capacité, une question ouverte résolue, ou un texte de page que des revendications ultérieures montrent comme étant faux.

• Réduisez une série d'instantanés de progression en son résultat. Les instantanés (exécutions CI, PR ouvertes, commits locaux) sont au maximum des entrées de Chronologie datées, jamais d'État.
• Vérifiez l'état mutable en direct avant de l'écrire comme actuel (par exemple gh pr view pour l'état de merge) et dites quand vous avez vérifié. Un merge n'est pas un déploiement, et un déploiement n'est pas la preuve qu'une passerelle donnée exécute le code.
• Lorsqu'une conception ou une page de décision contredit une décision ultérieure, ajoutez un amendement daté à côté du texte original plutôt que de le réécrire. Marquez les questions ouvertes auxquelles il a été répondu comme résolues et conservez la question originale.
• Citez chaque phrase ajoutée avec des liens [[claim-id|label]] vers les revendications.

Utilisez knowledge_edit_body pour les modifications de sections. Calculez les décalages UTF-16 à partir d'une lecture complète fraîche, et relisez la révision et le hachage avant chaque modification : d'autres sessions modifient les pages occupées simultanément. Préférez insérer du texte plutôt que de le remplacer. Remplacez une section d'État entière uniquement lorsque tout est obsolète, et conservez les liens de revendication qu'elle avait déjà.

6. Vérifier et signaler

Exécutez knowledge_verify avec expectedEntities pour chaque revendication liée et expectedLinks pour chaque page nouvelle ou modifiée. Énumérez à nouveau le résidu : de nouvelles revendications mémorisées peuvent être arrivées pendant que vous travailliez. Traitez-les de la même manière ou signalez-les.

Signalez le nombre de revendications examinées et liées, les pages créées, les revendications retirées (avec la revendication survivante ou de remplacement pour chacune), les pages modifiées, et les revendications laissées non liées avec la raison pour chacune. En mode non supervisé, ne demandez jamais de décision : laissez intacts les identités incertaines, les doublons incertains et les pages que vous ne créeriez que sur une supposition, et listez-les dans le rapport pour une personne.

S'exécuter en tant que révision planifiée

La maintenance des connaissances met en file d'attente cette révision après son passage de relink nocturne lorsque des revendications mémorisées privées sont toujours non liées (maintenance.reviewJobId). L'exécution est non supervisée :

• Appelez d'abord knowledge_status. Si le périmètre n'est pas private ou si les écritures sont désactivées, répondez avec AUTOMATION_FAILED sur sa propre première ligne et la raison : le worker a perdu l'accès du propriétaire et doit être configuré à nouveau.
• Travaillez à travers les étapes 1 à 6. Vérifiez à nouveau le résidu avant de vous arrêter, car les revendications enregistrées pendant l'exécution font partie du même backlog.
• S'il n'y a rien à faire, répondez NO_REPLY. Sinon, répondez avec le rapport de l'étape 6.

Configurer la révision planifiée

La révision nécessite un accès privé propriétaire, que seule une session descendant de la conversation directe du propriétaire a. Configurez-la à partir de cette conversation :

1. Créez un worker conservé : sessions_spawn avec runtime: "subagent", cleanup: "keep" et context: "isolated", dont la tâche est d'appeler knowledge_status et de signaler le périmètre. Continuez uniquement s'il signale private avec les écritures activées. Conservez la clé de session renvoyée.

2. Créez l'automatisation liée à ce worker. Elle a besoin d'un calendrier, donnez-lui donc une date unique dans des années ; la maintenance l'exécute à la demande.

   openclaw automations add --agent <agent> --name knowledge-unlinked-claims-review \
     --session "session:<worker-session-key>" --at <date-years-ahead> --keep-after-run \
     --model <provider/model> --no-deliver --timeout-seconds 3600 \
     --message "Follow the knowledge-unlinked-claims skill as the scheduled review."
   

   Le travail enregistre le compte d'inférence avec lequel il a été créé. Choisissez un modèle qui utilise ce compte (un fournisseur avec un profil d'authentification) ; sinon chaque exécution échoue avant que le modèle ne soit appelé.

3. Définissez plugins.entries.knowledge.config.maintenance.reviewJobId sur l'ID du travail.

4. Prouvez-le : openclaw automations run <job-id> --wait doit se terminer avec le worker signalant le périmètre privé, et maintenance_status signale le résultat de la révision après le passage suivant.

Désactivez l'automatisation pour suspendre la révision. La réinitialisation ou la suppression de la conversation propriétaire dont provient le worker révoque son accès ; configurez à nouveau la révision.