knowledge-unlinked-claims

Überprüfung nicht verknüpfter Einträge

Lies die gemeinsamen Konventionen und die Publikationsrichtlinien vor dem Schreiben.

knowledge_remember speichert einen Eintrag ohne Subjektseite, wenn kein Name darin genau einer Seite entspricht. Die geplante Wartung führt dann knowledge_relink aus, das nur solche Einträge verknüpft, deren aufgezeichnete Quellseite eine Entitätsseite ist oder deren Text genau eine Seite benennt. Der Rest bleibt unverknüpft und ist von den betreffenden Seiten aus unsichtbar. Dieser Skill bearbeitet diesen Rest mit Bedacht. Arbeite in der folgenden Reihenfolge: verknüpfen, dann Duplikate und ersetzte Einträge, dann Seitenprosa.

1. Auflistung des Rests

Rufe knowledge_status für den beabsichtigten Umfang und knowledge_ontology für den aktuellen Fingerabdruck auf. Führe zuerst knowledge_relink ohne dryRun aus, damit jeder gespeicherte Eintrag, der verknüpft werden kann, auch verknüpft wird. Liste dann den Rest mit knowledge_relink dryRun: true, include: "all" und limit: 10, gefolgt von nextCursor: jeder aktuelle Eintrag ohne verknüpfte Seite und ohne Quellseite, unabhängig vom Tool, das ihn gespeichert hat. Jeder Aufruf meldet maximal 10 Beispiele pro Ergebnis, daher gibt ein Limit von 10 jeden untersuchten Eintrag zurück.

Lies jeden Eintrag mit knowledge_record und metadataView: "full". Sein subject_hint, falls vorhanden, ist die eigene Beschreibung des Speicherers darüber, worum es in dem Eintrag geht, und der stärkste Hinweis auf sein Subjekt. Gruppiere die Einträge danach, worüber sie handeln (ein Feature, PR, Entscheidungsfaden, Person oder Präferenz), bevor du Seiten auswählst. Die meisten Einträge ergeben nur im Kontext ihrer Nachbarn Sinn: Eine Reihe von Status-Snapshots zu einem PR endet normalerweise in einem Ergebniseintrag.

2. Subjektseiten auswählen

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

• Das primäre Subjekt ist das, worüber der Eintrag etwas aussagt. Füge ein sekundäres Subjekt nur hinzu, wenn der Eintrag 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 Subjekt. Zwei oder drei Subjekte sind normalerweise ausreichend.
• Eine Präferenz oder Entscheidung, die von einer Person geäußert wurde, gehört auf die Seite dieser Person. Mache die Präferenz einer Person nicht zu einer Projekt- oder Unternehmensrichtlinie.
• Gleiche die Identität anhand von Beweisen ab, nicht anhand ähnlicher Namen. Wenn ein Eintrag etwas benennt, 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, lasse den Eintrag unverknüpft 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 Eintrags. Aussagetext, Beweise und Lebenszyklus bleiben unverändert.

3. Fehlende Seiten erstellen

Das Verknüpfen jedes Eintrags mit der nächstgelegenen vorhandenen Seite kann ein echtes Subjekt in der Timeline einer breiten Seite begraben. Erstelle eine Seite, wenn:

• ein diskretes Subjekt (ein Feature, Projekt, Tool oder substanzieller PR) etwa fünf oder mehr Einträge hat oder eine eigene Design-, Beweis- und Ergebnishistorie aufweist; oder
• eine Person oder Organisation etwas in den Einträgen 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 eine einmalige Korrektur, die ein Timeline-Eintrag abdeckt. Verwende knowledge_save_page mit dem Ontologie-typ, Aliasen und dem Identitätsnachweis als Quelle. Personenseiten verwenden identity.status: partial, es sei denn, die Identität ist vollständig geklärt. Schreibe einen kurzen Status, der die Einträge zitiert, und eine datierte Timeline. Verknüpfe dann die Einträge mit der neuen Seite, wobei ihre vorhandenen Subjekte als sekundäre erhalten bleiben, und verknüpfe die neue Seite von ihrer übergeordneten Seite.

4. Duplikate und ersetzte Einträge entfernen

• Duplikat: Zwei Einträge behaupten dieselbe Tatsache, Entscheidung oder Präferenz zum selben Ereignis. Behalte denjenigen mit besitzerbestätigtem Abruf, ansonsten den früheren, ansonsten denjenigen mit umfassenderer Quellenangabe. Kopiere alle Beweise, die dem Überlebenden fehlen, mit knowledge_annotate addEvidence, ziehe dann den anderen mit knowledge_withdraw und einem Grund zurück, der die ID des Überlebenden nennt.
• Ersetzt: Ein späterer Eintrag korrigiert den früheren explizit (z. B. ein Assistent, der seinen eigenen Bericht korrigiert), entscheidet eine Frage, die der frühere Eintrag offen gelassen hat, oder meldet den Endzustand desselben spezifischen Elements (gleicher PR, Commit oder Entscheidung). Ziehe den früheren Eintrag mit einem Grund zurück, der den ersetzenden Eintrag nennt. Verwende hier nicht knowledge_correct: Es veröffentlicht eine neue Kopie des Ersatzes, was ein weiteres Duplikat erzeugt.
• Weder noch: Schnappschüsse verschiedener Momente (CI rot an einem Head, später ein Merge) sind Geschichte, keine Fehler. Behalte sie. Widerspruch allein rechtfertigt keinen Rückzug. Wenn unsicher, behalte beide und melde das Paar.

5. Seitenprosa aktualisieren

Das Verknüpfen macht die Einträge von ihren Seiten aus erreichbar; es ändert nicht, was eine Seite aussagt. Bearbeite eine Seite nur, wenn die Einträge 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, der sich durch spätere Einträge als falsch erweist.

• Reduziere eine Reihe von Fortschrittsschnappschüssen auf ihr Ergebnis. Schnappschüsse (CI-Läufe, offene PRs, lokale Commits) sind allenfalls datierte Timeline-Einträge, 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 ü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 ein Design- oder Entscheidungsentwurf 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 Einträgen.

Verwende knowledge_edit_body für Abschnittsbearbeitungen. Berechne UTF-16-Offsets aus einer frischen Vollständigkeitslesung 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 vorhandenen Eintragslinks.

6. Überprüfen und berichten

Führe knowledge_verify mit expectedEntities für jeden verknüpften Eintrag und expectedLinks für jede neue oder bearbeitete Seite aus. Liste den Rest erneut auf: Möglicherweise sind während der Arbeit neue gespeicherte Einträge eingetroffen. Behandle sie auf die gleiche Weise oder melde sie.

Berichte die Anzahl der untersuchten und verknüpften Einträge, erstellten Seiten, zurückgezogenen Einträge (mit dem überlebenden oder ersetzenden Eintrag für jeden), bearbeiteten Seiten und der nicht verknüpften Einträge mit dem Grund für jeden. Wenn unbeaufsichtigt ausgeführt, frage niemals nach einer Entscheidung: Lasse unsichere Identitäten, unsichere Duplikate und Seiten, die du nur auf Basis einer Vermutung erstellen würdest, unberührt, und liste sie im Bericht für eine Person auf.

Ausführung als geplanter Review

Die Wissensverwaltung stellt diesen Review nach ihrem nächtlichen Neuverknüpfungslauf in die Warteschlange, wenn private gespeicherte Einträge noch unverknüpft sind (maintenance.reviewJobId). Der Lauf erfolgt unbeaufsichtigt:

• Rufe zuerst knowledge_status auf. Wenn der Umfang nicht private ist oder Schreibvorgänge deaktiviert sind, antworte mit AUTOMATION_FAILED in der ersten eigenen Zeile und dem Grund: Der Worker hat den Zugriff des Besitzers verloren und muss neu eingerichtet werden.
• Arbeite die Schritte 1 bis 6 durch. Überprüfe den Rest vor dem Stoppen erneut, da während des Laufs gespeicherte Einträge Teil desselben Backlogs sind.
• Wenn nichts zu tun ist, antworte mit NO_REPLY. Andernfalls antworte mit dem Bericht aus Schritt 6.

Einrichten des geplanten Reviews

Der Review benötigt besitzerprivaten Zugriff, den nur eine Sitzung hat, die von der direkten Unterhaltung des Besitzers abstammt. Richte ihn von dieser Unterhaltung aus ein:

1. Erstelle einen dauerhaften Worker: sessions_spawn mit runtime: "subagent", cleanup: "keep" und context: "isolated", dessen Aufgabe es ist, knowledge_status aufzurufen und den Umfang zu melden. Fahre nur fort, wenn es private mit aktivierten Schreibvorgängen meldet. Behalte den zurückgegebenen Sitzungsschlüssel.

2. Erstelle die Automation, die an diesen Worker gebunden ist. Sie benötigt einen Zeitplan, also gib ihr ein einmaliges Datum in Jahren; die Wartung führt sie bei Bedarf aus.

   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 "Befolge den knowledge-unlinked-claims-Skill als geplanten Review."
   

   Der Job zeichnet das Inferenzkonto auf, mit dem er erstellt wurde. Wähle ein Modell, das dieses Konto verwendet (ein Anbieter mit einem Auth-Profil); andernfalls schlägt jeder Lauf fehl, bevor das Modell aufgerufen wird.

3. Setze plugins.entries.knowledge.config.maintenance.reviewJobId auf die Job-ID.

4. Beweise es: openclaw automations run <job-id> --wait muss mit dem Worker beendet werden, der den privaten Umfang meldet, und maintenance_status meldet das Review-Ergebnis nach dem nächsten Durchlauf.

Deaktiviere die Automation, um den Review zu pausieren. Das Zurücksetzen oder Entfernen der Besitzerunterhaltung, von der der Worker stammt, widerruft seinen Zugriff; richte den Review dann neu ein.