クレーム統合レビュー
クレームはページがキュレーションされるより速く蓄積されます。knowledge_remember は、保存されたクレームの名前が正確に1つのページと一致しない場合、主題ページなしでクレームを保存します。また、スケジュールされたメンテナンスの knowledge_relink は、ソースページがエンティティページであるか、そのテキストが正確に1つのページを指名するクレームのみをリンクします。リンクされたクレームも積み重なります。ハブページはステータススナップショット、重複、およびより具体的な主題に属するクレームを収集します。このレビューでは、選択された範囲に対して1つの手順を実行します。この順序で作業します：範囲を選択し、リンクし、次に重複、置き換えられたクレームとスナップショット系列、次にページの散文を処理します。
1. 範囲を選択し列挙する
意図した範囲に対して knowledge_status を、現在のフィンガープリントに対して knowledge_ontology を呼び出します。次に、正確に1つの開始セットを列挙します。
- 未リンク残差（デフォルト、スクライブランの唯一の範囲）。最初に
knowledge_relinkをdryRunなしで実行し、リンク可能なすべての記憶されたクレームをリンクします。次に、knowledge_relinkをdryRun: true、include: "all"、limit: 10で使用して残差をリストし、nextCursorをたどります：リンクされたページもソースページもない現在のすべてのクレーム（どのツールで保存されたかは問いません）。各呼び出しは結果ごとに最大10件の例を報告するため、limit 10 は調査されたすべてのクレームを返します。 - 1つのページ。ハブページまたはサイズ予算を超えるページに使用します。その現在のクレームを
knowledge_connectionsのid、direction: "claims"、view: "full"、includeCards: trueでリストし、同じフィルターでnextOffsetをたどります。snapshotが変わったら再開します。ハブでは、最初にカードからグループ化し、一度に1グループずつ作業します。事前にすべてのクレームを完全に読まないでください。 - 1つの主題、オプションで特定の日付以降。主題にページがある場合、そのクレームを
knowledge_timelineのentity、timeField: "recorded_at"、sinceでリストし、nextOffsetをたどります。また、knowledge_grepをkind: "claim"、主題の特徴的な名前（PR番号、コミットSHA、機能名）、同じsince/timeFieldで使用して、他の場所にファイルされたクレームや未リンクのクレームを検索します。実際にその主題に関するクレームのみを保持します。
レポートに範囲を明記します。変更する各クレームを knowledge_record と metadataView: "full" で読み取ります。subject_hint は、保存者がそのクレームが何に関するものであるかを説明したものであり、その主題の最強の手がかりです。ページを選択する前に、クレームをそれらが何に関するものか（1つの機能、PR、コミット、決定スレッド、人物、または設定）でグループ化します。ほとんどのクレームは隣接するクレームの隣でのみ意味をなします。1つのPRに関する一連のステータススナップショットは、通常、結果クレームで終わります。
2. 主題ページを選択する
各グループについて、knowledge_grep と knowledge_lookup で候補ページを見つけ、そのStateを読み取ります。撤回されたページとフィクスチャページは無視します。
- 主主題 は、クレームが何かについて主張するものです。
entitiesの最初にリストします。二次主題は、クレームがそのエンティティについても何かを述べている場合にのみ追加します。たとえば、決定を下した人物や製品が設定された会社などです。単なる言及は主題ではありません。2つまたは3つの主題で通常十分です。 - 主主題は、クレームが対象とする最も具体的なページです。1つのPRに関するクレームは、そのPRのページに属し、PRが属するプロジェクトのみに属するわけではありません。より広いページは、クレームがそのページについて何かを述べている場合（プロジェクトレベルの決定、ポリシー、リリースなど）にのみ主題として残ります。
- 人物によって述べられた設定や決定は、その人物のページに属します。ある人物の設定をプロジェクトや会社のポリシーにしないでください。
- 同一性は、類似した名前ではなく、証拠に基づいて一致させます。クレームが既存のページである可能性のあるもの（たとえば、別のサービスである可能性のある製品名）を指名する場合、構成、URL、またはページ自身のエイリアスなどの証拠から確認します。不確かな場合は、クレームをそのままにして報告します。
knowledge_annotate の entities を使用してリンクし、完全なリスト（既存のものを置き換えます）とクレームの現在のリビジョンとハッシュを渡します。アサーションテキスト、証拠、ライフサイクルは変更されません。クレームを取って代わる前にリンクします。取って代わられたクレームは再リンクできません。
3. 欠落しているページを作成し、それらに再リンクする
すべてのクレームを最も近い既存のページにリンクすると、実際の主題が広いページに埋もれる可能性があります。次の場合にページを作成します。
- 個別の主題（機能、プロジェクト、ツール、または実質的なPR）に、おおよそ5つ以上のクレームがある、または独自の設計、証明、および結果の履歴がある場合、または
- 人物または組織がクレームの中で何かを執筆、所有、または決定し、ページがなく、同一性の証拠（たとえば
gh pr viewで示されるPR作成者）がある場合。
1回の言及や、日付のあるクレームでカバーされる1回限りの修正のためにページを作成しないでください。オントロジーの type、エイリアス、同一性の証拠を source として knowledge_save_page を使用します。人物ページは、同一性が完全に確立されていない限り identity.status: partial を使用します。クレームを引用する短いStateを書き、そのTimelineはそれらから派生します。新しいページをその親ページからリンクします。
次に、グループのクレームを再リンクします（ステップ4で取って代わるスナップショットを含む）。新しいページが各クレームの主主題になります。クレームがファイルされていた広いページ（多くの場合、このレビューを開始したハブ）は、ステップ2のルールに従って、クレームがそのページについて何かを述べている場合にのみ保持します。それ以外からは削除します。引き続き適格な既存の二次主題は保持します。しきい値を下回る場合は、クレームを現在のページに残します。
4. 重複、置き換えられたクレーム、スナップショット系列を退役させる
- 重複： 2つのクレームが同じイベントについて同じ事実、決定、または設定を主張します。所有者承認のリコールがあるものを保持し、それ以外ではより古いもの、さらにそれ以外ではより完全な帰属があるものを保持します。生存者が欠けている証拠を
knowledge_annotateのaddEvidenceでコピーし、次にknowledge_withdrawで他方を、生存者のIDを理由に名前を挙げて退役させます。 - 置き換えられた： 後のクレームが以前のクレームを明示的に修正する（たとえばアシスタントが自身の報告を修正する）か、以前のクレームが未解決のままにした質問を決定します。
knowledge_supersedeで以前のクレームを後のクレームで取って代わり、何が置き換えたかを示す理由を付けます。ここでknowledge_correctを使用しないでください。置き換えの新しいコピーを公開し、別の重複を作成します。 - スナップショット系列： 1つの特定のアイテム（同じPR、コミット、または決定スレッド：あるヘッドでのCIレッド、レビューリクエスト、CIグリーン）に関するいくつかのステータススナップショットと、それに続く同じアイテムに関する結果クレーム（マージ、クローズ、リバート、リリース、決定、放棄）。1回の
knowledge_supersede呼び出し（最大25クレーム）で系列内のすべてのスナップショットを結果で取って代わります。クレーム自身のテキストと日付から、次のすべてが成立する必要があります。- すべてのスナップショットと結果は、同じプロジェクトだけでなく、同じ特定のアイテムを指名している。
- 結果は、それが取って代わるすべてのスナップショットより後日であり、別の中間状態ではなく最終状態を述べている。
- 結果とスナップショットは主題ページを共有している（最初にリンクする、ステップ3）。ツールは共通ページのないクレームを拒否する。 結果より後の日付のスナップショット、または異なるヘッドや異なるアイテムに関するスナップショットはそのまま残ります。
- どちらでもない： 後の結果で置き換えられない異なる瞬間のスナップショット（CIレッド、次にCIグリーン、まだマージなし）は履歴であり、エラーではありません。保持します。矛盾だけでは撤回や取って代わりを正当化しません。不明な場合は両方を保持し、ペアを報告します。
knowledge_supersede は、取って代わられたすべてのクレームのテキスト、証拠、出所、履歴を保持し、それに superseded_by と理由を記録し、取って代わるクレームは変更しません。デフォルトの読み取りでは、取って代わられたクレームは表示されなくなります。履歴読み取り（historical: true、lifecycle: "all"）と knowledge_history は引き続き表示します。取って代わりが間違っていた場合は、undo: true、同じ by クレーム、およびその受領の items からのフェンスを指定して再度呼び出します。
5. ページの散文を更新する
リンクにより、クレームはページから到達可能になります。ページの内容は変わりません。クレームがページの耐久性のある状態を変更する場合にのみページを編集します：決定、設定、実装またはリリースされた変更、新しい機能、解決された未解決の質問、または後続のクレームが間違っていることを示すページテキスト。
- 一連の進捗スナップショットをその結果に折りたたみます。スナップショット（CI実行、オープンPR、ローカルコミット）は、せいぜい日付のあるイベントクレームであり、決してStateではありません。
- 現在のものとして書き込む前に、可変ステータスをライブで確認し（たとえばマージ状態の
gh pr view）、いつ確認したかを記述します。マージはデプロイメントではなく、デプロイメントは特定のGatewayがそのコードを実行していることの証明ではありません。 - デザインまたは決定ページが後の決定と矛盾する場合、元のテキストを書き換えるのではなく、日付を付けた修正を元のテキストの隣に追加します。回答済みの未解決の質問は解決済みとしてマークし、元の質問は保持します。
- 追加された各文を
[[claim-id|label]]リンクでクレームに引用します。 - ページ本文にはサイズ予算があります（ページ予算）。
state: "rejected"の編集は何も保存しませんが、リンクされたクレームは既に事実を保持しています。knowledge_extract_sectionでセクションをその主題のページに移動し（必要に応じてステップ3に従ってページを作成）、再読み取りして再試行します。他の散文を短縮してスペースを作らないでください。抽出により、セクションが引用するクレームの最初の主題が宛先になり、既存の主題（抽出元のページを含む）は保持されます。それらのクレームのそれぞれにステップ2を適用し、クレームがそのページについて何も述べていない場合はknowledge_annotateのentitiesでソースページを削除します。
セクション編集には knowledge_edit_body を使用します。UTF-16オフセットは完全な読み取りから計算し、編集のたびにリビジョンとハッシュを再読み取りします。他のセッションがビジーページを同時に編集します。テキストの挿入を置き換えより優先します。Stateセクション全体が古くなっている場合にのみ置き換え、それが既に持っていたクレームリンクは保持します。
6. 確認して報告する
リンクされた各クレームに expectedEntities を、新規または編集された各ページに expectedLinks を指定して knowledge_verify を実行します。再度範囲を列挙します。作業中に新しいクレームが到着している可能性があります。同じ方法で処理するか、報告します。
範囲、調査、リンク、再リンクされたクレームの数、作成されたページ、取って代わられたクレーム（各系列の取って代わるクレームを含む）、撤回されたクレーム（各ペアの生存クレームを含む）、編集されたページ、および検討したが変更されなかったクレームとその理由を報告します。無人実行の場合は、決定を求めたり推測したりしないでください。不確かな同一性、不確かな重複、結果が確実でないスナップショット系列、および推測でのみ作成するページはそのままにし、人物が確認するためにレポートにリストします。
スクライブラン
知識統合スクライブは、このレビューを無人で未リンク残差に対して実行します。スケジュールはプロンプトで指定します。プロンプトはアクセスを確認し、自動化を設定します。このセクションは1回の実行の作業のみです。
- 未リンク残差に対してステップ1を実行します。残差が空の場合は、ゼロのクレームを調査したと報告し、以下の書き込まれたTimelineに進みます。
- それ以外の場合は、ステップ2から6を実行し、停止する前に残差を再度確認します。実行中に保存されたクレームは同じバックログの一部です。
- 次に、最大10個の書き込まれた
## Timelineセクションを、大きいものから順に退役させます（書き込まれたTimelineを退役させる）。knowledge_grepでTimelineを検索し、ページ本文の見出しを確認します。退役させたセクションの数と、まだ保持しているページの数を数えます。 - 質問をしないでください。ステップ6の報告を行います。終了ステータス行では、調査、リンク、取って代わり、撤回、および残されたクレームの数をカウントし、次に退役および残されたTimelineの数をカウントします。