Wissensanspruchs-Konsolidierung

Überprüfung zur Anspruchskonsolidierung

Lies die gemeinsamen Konventionen und die Publikation vor dem Schreiben.

Ansprüche sammeln sich schneller an, als Seiten kuratiert werden. knowledge_remember speichert einen Anspruch ohne Themenseite, wenn kein darin enthaltener Name genau mit einer Seite übereinstimmt, und die eingeplante Wartung mittels knowledge_relink verknüpft nur Ansprüche, deren Quellseite eine Entitätsseite ist oder deren Text genau eine Seite benennt. Auch verknüpfte Ansprüche häufen sich an: Eine Hub-Seite sammelt Status-Snapshots, Duplikate und Ansprüche, die zu einem spezifischeren Thema gehören. Diese Überprüfung führt einen einzigen Prozess über einen gewählten Bereich durch. Arbeite in dieser Reihenfolge: Wähle den Bereich, verknüpfe, dann Duplikate, ersetzte Ansprüche und Snapshot-Serien, dann den Seitentext.

1. Wähle den Bereich und zähle ihn auf

Rufe knowledge_status für den beabsichtigten Bereich und knowledge_ontology für den aktuellen Fingerprint auf. Zähle dann genau eine Startmenge auf:

• Unverknüpfter Rückstand (die Voreinstellung und der einzige Bereich von Schreiber-Durchläufen). Führe zuerst knowledge_relink ohne dryRun aus, sodass jeder erinnerte Anspruch, den es verknüpfen kann, verknüpft ist. Liste dann den Rückstand mit knowledge_relink dryRun: true, include: "all" und limit: 10 auf, folge dabei nextCursor: jeder aktuelle Anspruch ohne verknüpfte Seite und ohne Quellseite, unabhängig davon, welches Tool ihn gespeichert hat. Jeder Aufruf meldet höchstens 10 Beispiele pro Ergebnis, daher liefert ein Limit von 10 jeden Anspruch, den er untersucht hat.
• Eine Seite, für eine Hub-Seite oder eine Seite, die ihr Größenbudget überschreitet. Liste ihre aktuellen Ansprüche mit knowledge_connections id, direction: "claims", view: "full" und includeCards: true auf, folge nextOffset mit denselben Filtern. Starte neu, wenn sich snapshot ändert. Gruppiere auf einer Hub-Seite zuerst aus den Karten und arbeite eine Gruppe nach der anderen; lies nicht jeden Anspruch im Voraus vollständig.
• Ein Thema, optional seit einem Datum. Wenn das Thema eine Seite hat, liste seine Ansprüche mit knowledge_timeline entity, timeField: "recorded_at" und since auf, folge nextOffset. Suche auch nach Ansprüchen, die anderswo abgelegt oder unverknüpft sind, mit knowledge_grep kind: "claim", den unverwechselbaren Namen des Themas (eine PR-Nummer, ein Commit-Hash, ein Feature-Name) und dem gleichen since/timeField. Behalte nur Ansprüche, die tatsächlich das Thema betreffen.

Gib den Bereich im Bericht an. Lies jeden Anspruch, den du ändern wirst, mit knowledge_record und metadataView: "full". Sein subject_hint ist, falls vorhanden, die eigene Beschreibung des Speichernden, worum es in dem Anspruch geht, und der stärkste Hinweis auf sein Thema. Gruppiere die Ansprüche nach ihrem Inhalt (ein Feature, PR, Commit, Entscheidungsfaden, Person oder Präferenz), bevor du Seiten auswählst. Die meisten Ansprüche ergeben nur im Kontext ihrer Nachbarn Sinn: Eine Serie von Status-Snapshots zu einer PR endet meist in einem Ergebnisanspruch.

2. Wähle Themenseiten

Finde für jede Gruppe Kandidatenseiten mit knowledge_grep und knowledge_lookup und lies deren Status. Ignoriere zurückgezogene Seiten und Fixture-Seiten.

• Das primäre Thema ist das, worüber der Anspruch etwas behauptet; führe es zuerst in entities auf. Füge ein sekundäres Thema nur hinzu, wenn der Anspruch auch etwas über diese Entität aussagt, z. B. die Person, die die Entscheidung getroffen hat, oder das Unternehmen, dessen Produkt konfiguriert wurde. Eine beiläufige Erwähnung ist kein Thema. Zwei oder drei Themen sind in der Regel ausreichend.
• Das primäre Thema ist die spezifischste Seite, auf die sich der Anspruch bezieht: Ein Anspruch über eine bestimmte PR gehört auf die Seite dieser PR, nicht nur auf das Projekt, zu dem die PR gehört. Die übergeordnete Seite bleibt nur dann ein Thema, wenn der Anspruch etwas über sie aussagt, z. B. eine Entscheidung auf Projektebene, eine Richtlinie oder eine Veröffentlichung.
• Eine von einer Person geäußerte Präferenz oder Entscheidung gehört auf die Seite dieser Person. Mache die Präferenz einer Person nicht zu einer Projekt- oder Unternehmensrichtlinie.
• Gleiche Identität anhand von Beweisen ab, nicht anhand ähnlicher Namen. Wenn ein Anspruch etwas nennt, das eine bestehende Seite sein könnte (z. B. ein Produktname, der ein anderer Dienst sein könnte), bestätige dies anhand von Beweisen wie Konfiguration, einer URL oder den eigenen Aliasen der Seite. Wenn es unsicher bleibt, belasse den Anspruch dort, wo er ist, und melde ihn.

Verknüpfe mit knowledge_annotate entities, übergib die vollständige Liste (sie ersetzt die vorhandene) sowie die aktuelle Revision und den Hash des Anspruchs. Assertion-Text, Beweise und Lebenszyklus bleiben unverändert. Verknüpfe einen Anspruch, bevor du ihn ersetzt: Ersetzte Ansprüche können nicht neu verknüpft werden.

3. Erstelle fehlende Seiten und verknüpfe sie neu

Das Verknüpfen jedes Anspruchs mit der nächstgelegenen vorhandenen Seite kann ein echtes Thema in einer breiten Seite vergraben. Erstelle eine Seite, wenn:

• ein diskretes Thema (ein Feature, Projekt, Tool oder eine umfangreiche PR) etwa fünf oder mehr Ansprüche hat oder eine eigene Entwurfs-, Nachweis- und Ergebnisgeschichte aufweist; oder
• eine Person oder Organisation etwas in den Ansprüchen verfasst, besitzt oder entschieden hat, keine Seite hat und Identitätsnachweise vorliegen (z. B. der PR-Autor, angezeigt durch gh pr view).

Erstelle keine Seite für eine einzelne Erwähnung oder einen einmaligen Fix, der von einem datierten Anspruch abgedeckt wird. Verwende knowledge_save_page mit dem Ontologie-type, Aliasen und den Identitätsnachweisen als source. Personen-Seiten verwenden identity.status: partial, es sei denn, die Identität ist vollständig geklärt. Schreibe einen kurzen Status, der die Ansprüche zitiert; sein Zeitstrahl wird daraus abgeleitet. Verlinke die neue Seite von ihrer übergeordneten Seite.

Verknüpfe dann die Ansprüche der Gruppe neu, einschließlich der Snapshots, die Schritt 4 ersetzen wird. Die neue Seite wird zum primären Thema jedes Anspruchs. Behalte die breite Seite, auf der die Ansprüche abgelegt wurden (oft die Hub-Seite, mit der diese Überprüfung begann), nur für Ansprüche, die etwas über sie aussagen, gemäß der Regel in Schritt 2; entferne sie aus den übrigen. Behalte andere vorhandene sekundäre Themen, die weiterhin qualifiziert sind. Unterhalb der Schwelle belasse die Ansprüche auf ihren derzeitigen Seiten.

4. Ziehe Duplikate, ersetzte Ansprüche und Snapshot-Serien zurück

• Duplikat: Zwei Ansprüche behaupten dieselbe Tatsache, Entscheidung oder Präferenz über dasselbe Ereignis. Behalte denjenigen mit vom Eigentümer genehmigtem Recall, ansonsten den früheren, ansonsten denjenigen mit vollständigerer Zuschreibung. Kopiere alle Beweise, die dem Überlebenden fehlen, mit knowledge_annotate addEvidence, dann ziehe den anderen mit knowledge_withdraw zurück, mit einem Grund, der die ID des Überlebenden nennt.
• Ersetzt: Ein späterer Anspruch korrigiert den früheren explizit (z. B. ein Assistent, der seinen eigenen Bericht korrigiert) oder entscheidet eine Frage, die der frühere Anspruch offen ließ. Ersetze den früheren Anspruch durch den späteren mit knowledge_supersede, mit einem Grund, der angibt, was ihn ersetzt hat. Verwende hier nicht knowledge_correct: Es veröffentlicht eine neue Kopie des Ersatzes, was ein weiteres Duplikat erzeugt.
• Snapshot-Serie: Mehrere Status-Snapshots zu einem bestimmten Element (derselben PR, derselbe Commit oder Entscheidungsfaden: CI rot bei einem Head, Review angefordert, CI grün), gefolgt von einem Ergebnisanspruch zum selben Element (gemerged, geschlossen, zurückgesetzt, veröffentlicht, entschieden, aufgegeben). Ersetze jeden Snapshot in der Serie durch das Ergebnis in einem einzigen knowledge_supersede-Aufruf (bis zu 25 Ansprüche). Alle diese Bedingungen müssen aus den Texten und Daten der Ansprüche selbst erfüllt sein:
  • jeder Snapshot und das Ergebnis nennen dasselbe bestimmte Element, nicht nur dasselbe Projekt;
  • das Ergebnis ist datiert nach jedem Snapshot, den es ersetzt, und gibt einen endgültigen Status an, keinen weiteren Zwischenstatus;
  • das Ergebnis und die Snapshots teilen eine Themenseite (verknüpfe sie zuerst, Schritt 3); das Tool lehnt Ansprüche ohne gemeinsame Seite ab. Ein Snapshot, der nach dem Ergebnis datiert ist, oder einer, der sich auf einen anderen Head oder ein anderes Element bezieht, bleibt bestehen.
• Weder noch: Snapshots verschiedener Momente, die durch kein späteres Ergebnis ersetzt werden (CI rot, dann CI grün, ohne Merge bisher) sind Geschichte, keine Fehler. Behalte sie. Ein Widerspruch allein rechtfertigt weder einen Rückzug noch eine Ersetzung. Bei Unsicherheit behalte beide und melde das Paar.

knowledge_supersede behält den Text, die Beweise, die Herkunft und die Historie jedes ersetzten Anspruchs, zeichnet superseded_by und den Grund darauf auf und lässt den ersetzenden Anspruch unverändert. Standard-Lesevorgänge zeigen ersetzte Ansprüche nicht mehr an; historische Lesevorgänge (historical: true, lifecycle: "all") und knowledge_history tun dies weiterhin. Wenn eine Ersetzung falsch war, rufe es erneut mit undo: true auf, zusammen mit demselben by-Anspruch und den Grenzen aus den items der Quittung.

5. Aktualisiere den Seitentext

Das Verknüpfen macht die Ansprüche von ihren Seiten aus erreichbar; es ändert nicht, was eine Seite aussagt. Bearbeite eine Seite nur, wenn die Ansprüche ihren dauerhaften Zustand ändern: eine Entscheidung, eine Präferenz, eine gelandete oder veröffentlichte Änderung, eine neue Fähigkeit, eine geklärte offene Frage oder Seitentext, den spätere Ansprüche als falsch erweisen.

• Fasse eine Serie von Fortschritts-Snapshots zu ihrem Ergebnis zusammen. Snapshots (CI-Läufe, offene PRs, lokale Commits) sind bestenfalls datierte Ereignisansprüche, niemals Status.
• Überprüfe den veränderlichen Status live, bevor du ihn als aktuell schreibst (z. B. gh pr view für den Merge-Status) und gib an, wann du ihn überprüft hast. Ein Merge ist kein Deployment, und ein Deployment ist kein Beweis dafür, dass ein bestimmtes Gateway den Code ausführt.
• Wenn eine Entwurfs- oder Entscheidungsseite einer späteren Entscheidung widerspricht, füge einen datierten Zusatz neben dem Originaltext hinzu, anstatt ihn umzuschreiben. Markiere beantwortete offene Fragen als gelöst und behalte die ursprüngliche Frage.
• Zitiere jeden hinzugefügten Satz mit [[claim-id|label]]-Links zu den Ansprüchen.
• Seitentexte haben ein Größenbudget (Seitenbudgets). Ein state: "rejected"-Bearbeitung hat nichts gespeichert, aber die verknüpften Ansprüche enthalten die Fakten bereits. Verschiebe einen Abschnitt auf die Seite seines Themas mit knowledge_extract_section (erstelle die Seite gemäß Schritt 3 bei Bedarf), lies erneut und versuche es erneut. Kürze niemals andere Prosa, um Platz zu schaffen. Die Extraktion macht das Ziel zum ersten Thema der Ansprüche, die der Abschnitt zitiert, und behält ihre vorhandenen Themen, einschließlich der Seite, von der du extrahiert hast. Wende Schritt 2 auf jeden dieser Ansprüche an und entferne die Quellseite mit knowledge_annotate entities, wenn der Anspruch nichts über sie aussagt.

Verwende knowledge_edit_body für Abschnittsbearbeitungen. Berechne UTF-16-Offsets aus einer frischen vollständigen Lektüre und lies die Revision und den Hash vor jeder Bearbeitung erneut: Andere Sitzungen bearbeiten gleichzeitig vielbesuchte Seiten. Bevorzuge das Einfügen von Text gegenüber dem Ersetzen. Ersetze einen gesamten Statusabschnitt nur, wenn er vollständig veraltet ist, und behalte die Anspruchslinks, die er bereits hatte.

6. Überprüfe und berichte

Führe knowledge_verify mit expectedEntities für jeden verknüpften Anspruch und expectedLinks für jede neue oder bearbeitete Seite aus. Zähle den Bereich erneut auf: Neue Ansprüche können während der Bearbeitung eingetroffen sein. Behandle sie auf die gleiche Weise oder melde sie.

Berichte den Bereich, die Anzahl der untersuchten, verknüpften und neu verknüpften Ansprüche, der erstellten Seiten, der ersetzten Ansprüche (mit dem ersetzenden Anspruch für jede Serie), der zurückgezogenen Ansprüche (mit dem überlebenden Anspruch für jeden), der bearbeiteten Seiten und der unverändert gebliebenen Ansprüche, die du in Betracht gezogen hast, mit dem Grund für jeden. Führe bei unbeaufsichtigten Durchläufen niemals eine Entscheidung herbei und rate niemals: Lasse unsichere Identitäten, unsichere Duplikate, Snapshot-Serien, deren Ergebnis nicht sicher ist, und Seiten, die du nur aufgrund einer Vermutung erstellen würdest, unberührt und liste sie im Bericht für eine Person auf.

Schreiber-Durchläufe

Der Wissenskonsolidierungs-Schreiber führt diese Überprüfung unbeaufsichtigt über den unverknüpften Rückstand durch, gemäß dem Zeitplan in seiner Eingabeaufforderung. Seine Eingabeaufforderung prüft den Zugriff und richtet seine Automatisierung ein; dieser Abschnitt ist nur die Arbeit eines einzelnen Durchlaufs.

• Führe Schritt 1 für den unverknüpften Rückstand aus. Wenn der Rückstand leer ist, melde null untersuchte Ansprüche und fahre mit den unten stehenden geschriebenen Zeitstrahlen fort.
• Andernfalls arbeite die Schritte 2 bis 6 ab und überprüfe den Rückstand erneut, bevor du anhältst, da während des Durchlaufs gespeicherte Ansprüche Teil desselben Rückstands sind.
• Ziehe dann bis zu 10 geschriebene ## Timeline-Abschnitte zurück, beginnend mit dem größten (einen geschriebenen Zeitstrahl zurückziehen). Finde sie mit knowledge_grep nach Timeline und bestätige die Überschrift im Seitentext. Zähle die zurückgezogenen Abschnitte und die Seiten, die noch einen tragen.
• Stelle keine Fragen. Gib den Bericht aus Schritt 6 ab; die abschließende Statuszeile zählt die untersuchten, verknüpften, ersetzten, zurückgezogenen und verbleibenden Ansprüche, dann die zurückgezogenen und verbleibenden Zeitstrahlen.