ナレッジ未リンク主張のレビュー

未リンク主張のレビュー

書き込みの前に共有コンベンションと公開ルールを読んでください。

knowledge_rememberは、主張のテキスト内の名前が正確に1つのページと一致しない場合、サブジェクトページなしで主張を保存します。定期メンテナンスのknowledge_relinkは、記録されたソースページがエンティティページであるか、テキストが正確に1つのページを指定している主張のみをリンクします。残りはリンクされず、関連するページからは見えません。このスキルは、その残差を判断して処理します。以下の順序で作業してください：リンク、次に重複と置き換えられた主張、最後にページの散文。

1. 残差をリストアップする

対象範囲のknowledge_statusと現在のフィンガープリントのknowledge_ontologyを呼び出します。最初にdryRunなしでknowledge_relinkを実行し、リンク可能なすべての記憶された主張をリンクします。次に、knowledge_relinkをdryRun: true、include: "all"、limit: 10で実行し、残差をリストアップします。nextCursorに従って、リンクされたページがなく、ソースページもないすべての現在の主張（保存したツールを問わず）を取得します。各呼び出しは、結果タイプごとに最大10件の例を報告するため、limit 10は検査したすべての主張を返します。

各主張はknowledge_recordとmetadataView: "full"で読みます。subject_hintがある場合は、保存者自身の主張内容の説明であり、そのサブジェクトの最も強力な手がかりです。主張を、何についてのものか（1つの機能、PR、決定スレッド、人物、または設定）でグループ化してからページを選択します。ほとんどの主張は隣接する主張とのコンテキストでのみ意味をなします：1つのPRに関する一連のステータススナップショットは、通常、結果の主張で終わります。

2. サブジェクトページを選択する

各グループについて、knowledge_grepとknowledge_lookupで候補ページを検索し、そのStateとTimelineを読みます。取り下げられたページとフィクスチャページは無視します。

• プライマリサブジェクトとは、主張が何かについてアサートするものです。主張がそのエンティティについても何かを述べている場合にのみ、セカンダリサブジェクトを追加します（例：決定を下した人物、製品が設定された会社）。単なる言及はサブジェクトではありません。2～3のサブジェクトで十分なことが多いです。
• 人物によって述べられた設定や決定は、その人物のページに属します。一人の人物の設定をプロジェクトや会社のポリシーにしないでください。
• 同一性は証拠に基づいて判断し、類似した名前だけに基づかないでください。主張が既存のページである可能性のあるもの（例えば、別のサービスの可能性がある製品名）を指定している場合、設定、URL、ページ自身のエイリアスなどの証拠から確認します。不確かである場合は、主張をリンクせずに報告します。

knowledge_annotate entitiesでリンクし、完全なリスト（既存のリストを置き換えます）と主張の現在のリビジョンおよびハッシュを渡します。アサーションテキスト、証拠、ライフサイクルは変更しません。

3. 不足しているページを作成する

すべての主張を最も近い既存のページにリンクすると、実際のサブジェクトが広いページのTimelineに埋もれてしまう可能性があります。以下の場合にページを作成します：

• 個別のサブジェクト（機能、プロジェクト、ツール、または重要なPR）に約5つ以上の主張があるか、独自の設計、証明、結果の履歴がある場合。
• 主張内で作成、所有、または決定した人物または組織にページがなく、同一性の証拠がある場合（例：gh pr viewで表示されるPR作成者）。

単一の言及や、Timelineエントリでカバーされる一回限りの修正のためにページを作成しないでください。knowledge_save_pageを使用し、オントロジのtype、エイリアス、および同一性の証拠をsourceとして指定します。人物ページでは、同一性が完全に確立されていない限りidentity.status: partialを使用します。主張を引用する短いStateと、日付付きのTimelineを記述します。次に、主張を新しいページにリンクし、既存のサブジェクトをセカンダリとして維持し、新しいページをその親ページからリンクします。

4. 重複と置き換えられた主張を破棄する

• 重複： 2つの主張が同じイベントについて同じ事実、決定、設定をアサートしています。所有者承認のリコールがあるものを保持し、そうでなければより古いもの、そうでなければより完全な帰属があるものを保持します。生存者に不足している証拠をknowledge_annotate addEvidenceでコピーし、次にknowledge_withdrawで他方を生存者のIDを理由に挙げて取り下げます。
• 置き換えられた： 後の主張が前の主張を明示的に訂正している（例：アシスタントが自分のレポートを訂正する、前の主張が未解決のままにした質問を決定する、同じ特定のアイテム（同じPR、コミット、決定）の最終状態を報告する）。前の主張を、置き換えた主張のIDを理由に挙げて取り下げます。ここではknowledge_correctを使用しないでください：それは置き換えの新しいコピーを公開し、別の重複を作成します。
• どちらでもない： 異なる瞬間のスナップショット（CIの赤、後のマージ）は履歴であり、エラーではありません。それらを保持します。矛盾だけでは取り下げの正当な理由にはなりません。不明な場合は両方を保持し、ペアを報告します。

5. ページの散文を更新する

リンクにより、主張がそのページから到達可能になりますが、ページの内容は変わりません。主張がページの耐久性のある状態を変更する場合にのみページを編集します：決定、設定、着地またはリリースされた変更、新しい機能、解決された未解決の質問、または後の主張が間違っていることを示すページテキスト。

• 一連の進捗スナップショットをその結果にまとめます。スナップショット（CI実行、オープンPR、ローカルコミット）は、最大でも日付付きのTimelineエントリであり、Stateにはなりません。
• 可変ステータスを現在のものとして書き込む前に、ライブで確認します（例：マージ状態のgh pr view）し、確認した日時を記載します。マージはデプロイメントではなく、デプロイメントは特定のGatewayがコードを実行していることの証明ではありません。
• 設計や決定ページが後の決定と矛盾する場合、元のテキストを書き換えるのではなく、日付付きの修正を元のテキストの隣に追加します。回答済みの未解決質問は解決済みとしてマークし、元の質問は保持します。
• 追加するすべての文に、[[claim-id|label]]リンクで主張を引用します。

セクション編集にはknowledge_edit_bodyを使用します。UTF-16オフセットを新しい完全読み取りから計算し、編集のたびにリビジョンとハッシュを再読み取りします：他のセッションが同時にビジーページを編集する可能性があります。テキストの置き換えよりも挿入を優先します。Stateセクション全体を置き換えるのは、そのすべてが古くなっている場合のみにし、既に持っている主張リンクは保持します。

6. 検証して報告する

リンクされた各主張に対してexpectedEntitiesを、新規または編集された各ページに対してexpectedLinksを指定してknowledge_verifyを実行します。再度残差をリストアップします：作業中に新しい記憶された主張が到着している可能性があります。それらを同じ方法で処理するか、報告します。

検査およびリンクされた主張の数、作成されたページの数、取り下げられた主張（各々の生存または置き換えた主張のID）、編集されたページの数、およびリンクされずに残った主張とその理由を報告します。無人実行の場合、決定を求めないでください：不確かな同一性、不確かな重複、推測でのみ作成するページはそのままにし、それらを人間が確認するためにレポートにリストします。

定期レビューとしての実行

ナレッジメンテナンスは、夜間の再リンクパス後にプライベートの記憶された主張がまだリンクされていない場合、このレビューをキューに入れます（maintenance.reviewJobId）。実行は無人です：

• 最初にknowledge_statusを呼び出します。スコープがprivateでないか、書き込みが無効になっている場合、最初の行にAUTOMATION_FAILEDとその理由を返信します：ワーカーが所有者のアクセスを失っており、再設定が必要です。
• ステップ1から6まで作業します。停止する前に再度残差を確認します。実行中に保存された主張も同じバックログの一部だからです。
• 何もすることがない場合はNO_REPLYを返信します。それ以外の場合は、ステップ6のレポートを返信します。

定期レビューの設定

レビューには所有者プライベートアクセスが必要であり、これは所有者の直接会話から派生したセッションのみが持つことができます。その会話から設定します：

1. キープされたワーカーを生成します：runtime: "subagent"、cleanup: "keep"、context: "isolated"のsessions_spawnを使用し、タスクはknowledge_statusを呼び出してスコープを報告することです。privateで書き込みが有効になっていると報告した場合のみ続行します。返されたセッションキーを保持します。

2. そのワーカーにバインドされた自動化を作成します。スケジュールが必要なため、数年先のワンショット日付を指定します。メンテナンスがオンデマンドで実行します。

   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."
   

   ジョブは作成時に使用された推論アカウントを記録します。そのアカウント（認証プロファイルを持つプロバイダ）を使用するモデルを選択します。そうしないと、モデルが呼び出される前にすべての実行が失敗します。

3. plugins.entries.knowledge.config.maintenance.reviewJobIdをジョブIDに設定します。

4. 証明します：openclaw automations run <job-id> --waitが、ワーカーがプライベートスコープを報告して完了し、maintenance_statusが次のパス後にレビュー結果を報告する必要があります。

自動化を無効にしてレビューを一時停止します。ワーカーが由来する所有者会話をリセットまたは削除すると、そのアクセスが取り消されます。再度レビューを設定してください。