consolidation-des-revendications

Examen de consolidation des revendications

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

Les revendications s'accumulent plus vite que les pages ne sont organisées. knowledge_remember sauvegarde une revendication sans page de sujet lorsqu'aucun nom dedans ne correspond exactement à une page, et la maintenance planifiée de knowledge_relink ne lie que les revendications dont la page source est une page d'entité ou dont le texte nomme exactement une page. Les revendications liées s'empilent aussi : une page hub collecte des instantanés de statut, des doublons et des revendications qui devraient être sur un sujet plus spécifique. Cet examen exécute une procédure sur un périmètre choisi. Travaillez dans cet ordre : choisissez le périmètre, liez, puis les doublons, les revendications remplacées et les séries d'instantanés, puis le texte de la page.

1. Choisir le périmètre et l'énumérer

Appelez knowledge_status pour le périmètre prévu et knowledge_ontology pour l'empreinte actuelle. Énumérez ensuite exactement un ensemble de départ :

• Résidu non lié (par défaut, et le seul périmètre des exécutions de scribe). Exécutez d'abord knowledge_relink sans dryRun pour que chaque revendication mémorisée qu'il peut lier soit liée. Ensuite, listez 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 sauvegardée. Chaque appel rapporte au plus 10 exemples par résultat, donc une limite de 10 renvoie chaque revendication examinée.
• Une page, pour une page hub ou une page dépassant son budget de taille. Listez ses revendications actuelles avec knowledge_connections id, direction: "claims", view: "full" et includeCards: true, en suivant nextOffset avec les mêmes filtres. Redémarrez lorsque snapshot change. Sur un hub, regroupez d'abord à partir des cartes et travaillez un groupe à la fois ; ne lisez pas chaque revendication en détail immédiatement.
• Un sujet, éventuellement depuis une date. Lorsque le sujet a une page, listez ses revendications avec knowledge_timeline entity, timeField: "recorded_at" et since, en suivant nextOffset. Recherchez également les revendications déposées ailleurs ou non liées avec knowledge_grep kind: "claim", les noms distinctifs du sujet (un numéro de PR, un SHA de commit, un nom de fonctionnalité) et le même since/timeField. Ne conservez que les revendications qui concernent réellement le sujet.

Indiquez le périmètre dans le rapport. Lisez chaque revendication que vous allez modifier avec knowledge_record et metadataView: "full". Son subject_hint, lorsqu'il est présent, est la propre description par le sauvegardeur de ce que la revendication concerne et l'indice le plus fort de son sujet. Regroupez les revendications par ce qu'elles concernent (une fonctionnalité, PR, commit, fil de décision, personne ou 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 de statut sur une PR se termine généralement par une revendication de résultat.

2. Choisir les pages de sujet

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

• Le sujet principal est ce sur quoi la revendication affirme quelque chose ; listez-le en premier dans entities. Ajoutez un sujet secondaire seulement lorsque la revendication énonce également quelque chose sur 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.
• Le sujet principal est la page la plus spécifique que la revendication concerne : une revendication sur une PR appartient à la page de cette PR, pas seulement au projet auquel la PR appartient. La page plus large reste un sujet seulement lorsque la revendication dit quelque chose à son sujet, comme une décision au niveau du projet, une politique ou une version.
• 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 où elle est et signalez-la.

Lieze avec knowledge_annotate entities, en passant la liste complète (elle remplace la liste existante) ainsi que la révision et le hachage actuels de la revendication. Le texte d'affirmation, les preuves et le cycle de vie restent inchangés. Liez une revendication avant de la remplacer : les revendications remplacées ne peuvent pas être reliées.

3. Créer les pages manquantes et relier à elles

Lier chaque revendication à la page existante la plus proche peut enterrer un sujet réel dans 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 design, preuve et historique de résultat ; ou
• une personne ou une organisation a rédigé, possède ou a décidé quelque chose dans les revendications, n'a pas de page, et a 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 revendication datée 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 état court qui cite les revendications ; sa chronologie en est dérivée. Liez la nouvelle page depuis sa page parente.

Ensuite, reliez les revendications du groupe, y compris les instantanés que l'étape 4 remplacera. La nouvelle page devient le sujet principal de chaque revendication. Conservez la page large sur laquelle les revendications ont été déposées (souvent le hub par lequel cet examen a commencé) uniquement pour les revendications qui disent quelque chose à son sujet, selon la règle de l'étape 2 ; supprimez-la des autres. Conservez les autres sujets secondaires existants qui remplissent encore les conditions. En dessous du seuil, laissez les revendications sur leurs pages actuelles.

4. Retirer les doublons, les revendications remplacées et les séries d'instantanés

• Doublon : deux revendications affirment le même fait, décision ou préférence sur le même événement. Conservez celle avec un rappel approuvé par le propriétaire, sinon la plus ancienne, sinon celle avec l'attribution la plus complète. Copiez les preuves manquantes au survivant avec knowledge_annotate addEvidence, puis retirez l'autre avec knowledge_withdraw 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) ou décide d'une question que la revendication précédente laissait ouverte. Remplacez la revendication précédente par la suivante avec knowledge_supersede, avec une raison qui dit ce qui l'a remplacée. N'utilisez pas knowledge_correct ici : cela publie une nouvelle copie du remplacement, ce qui crée un autre doublon.
• Série d'instantanés : plusieurs instantanés de statut sur un élément spécifique (la même PR, commit ou fil de décision : CI rouge à une tête, revue demandée, CI verte) suivis d'une revendication de résultat sur le même élément (fusionné, fermé, reverti, publié, décidé, abandonné). Remplacez chaque instantané de la série par le résultat en un seul appel knowledge_supersede (jusqu'à 25 revendications). Toutes ces conditions doivent être remplies, d'après le texte et les dates des revendications :
  • chaque instantané et le résultat nomment le même élément spécifique, pas seulement le même projet ;
  • le résultat est daté après chaque instantané qu'il remplace et indique un état final, pas un autre état intermédiaire ;
  • le résultat et les instantanés partagent une page de sujet (liez-les d'abord, étape 3) ; l'outil rejette les revendications sans page commune. Un instantané daté après le résultat, ou concernant une tête différente ou un élément différent, reste.
• Ni l'un ni l'autre : les instantanés de moments différents qu'aucun résultat ultérieur ne remplace (CI rouge, puis CI verte, sans fusion pour l'instant) sont de l'histoire, pas des erreurs. Conservez-les. La contradiction seule ne justifie pas un retrait ou un remplacement. En cas de doute, conservez les deux et signalez la paire.

knowledge_supersede conserve le texte, les preuves, la provenance et l'historique de chaque revendication remplacée, enregistre superseded_by et la raison sur celle-ci, et laisse la revendication remplaçante inchangée. Les lectures par défaut cessent d'afficher les revendications remplacées ; les lectures historiques (historical: true, lifecycle: "all") et knowledge_history le font toujours. Si un remplacement était erroné, appelez-le à nouveau avec undo: true, la même revendication by et les barrières de son accusé de réception dans items.

5. Mettre à jour le texte de la page

Lier rend les revendications accessibles depuis leurs pages ; cela ne change pas ce qu'une page dit. Modifiez une page seulement 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 erroné.

• 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 plus des revendications d'événement datées, jamais un état.
• Vérifiez l'état mutable en direct avant de l'écrire comme actuel (par exemple gh pr view pour l'état de fusion) et indiquez quand vous avez vérifié. Une fusion n'est pas un déploiement, et un déploiement n'est pas une preuve qu'une passerelle donnée exécute le code.
• Lorsqu'une page de design ou 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 comme résolues et conservez la question originale.
• Citez chaque phrase ajoutée avec des liens [[claim-id|label]] vers les revendications.
• Les corps de page ont un budget de taille (budgets de page). Une modification avec state: "rejected" n'a rien sauvegardé, mais les revendications liées contiennent déjà les faits. Déplacez une section vers la page de son sujet avec knowledge_extract_section (en créant la page selon l'étape 3 si nécessaire), relisez et réessayez. Ne raccourcissez jamais d'autre texte pour faire de la place. L'extraction fait de la destination le premier sujet des revendications que la section cite et conserve leurs sujets existants, y compris la page d'où vous avez extrait. Appliquez l'étape 2 à chacune de ces revendications et supprimez la page source avec knowledge_annotate entities là où la revendication ne dit rien à son sujet.

Utilisez knowledge_edit_body pour les modifications de section. Calculez les décalages UTF-16 à partir d'une lecture complète récente, et relisez la révision et le hachage avant chaque modification : d'autres sessions modifient les pages actives simultanément. Préférez insérer du texte plutôt que le remplacer. Remplacez une section d'état entière seulement si elle est entièrement 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 périmètre : de nouvelles revendications peuvent être arrivées pendant que vous travailliez. Traitez-les de la même manière ou signalez-les.

Signalez le périmètre, le nombre de revendications examinées, liées et reliées, les pages créées, les revendications remplacées (avec la revendication remplaçante pour chaque série), les revendications retirées (avec la revendication survivante pour chaque), les pages modifiées, et les revendications laissées inchangées que vous avez considérées, avec la raison pour chacune. Lors d'une exécution non supervisée, ne demandez jamais de décision et ne devinez jamais : laissez les identités incertaines, les doublons incertains, les séries d'instantanés dont le résultat n'est pas certain, et les pages que vous ne créeriez que sur un coup de devinette intacts, et listez-les dans le rapport pour une personne.

Exécutions de scribe

Le scribe Consolidation des connaissances exécute cet examen sans surveillance sur le résidu non lié, selon le planning de son prompt. Son prompt vérifie l'accès et configure son automatisation ; cette section n'est que le travail d'une seule exécution.

• Exécutez l'étape 1 pour le résidu non lié. Lorsque le résidu est vide, signalez zéro revendication examinée et passez aux chronologies écrites ci-dessous.
• Sinon, travaillez à travers les étapes 2 à 6, et vérifiez à nouveau le résidu avant de vous arrêter, car les revendications sauvegardées pendant l'exécution font partie du même arriéré.
• Ensuite, retirez jusqu'à 10 sections ## Chronologie écrites, les plus grandes en premier (retirer une chronologie écrite). Trouvez-les avec knowledge_grep pour Chronologie et confirmez l'en-tête dans le corps de la page. Comptez les sections retirées et les pages qui en portent encore une.
• Ne posez pas de questions. Donnez le rapport de l'étape 6 ; la ligne de statut de clôture compte les revendications examinées, liées, remplacées, retirées et laissées, puis les chronologies retirées et laissées.