manage-report-lifecycle

レポートのライフサイクルを管理する

すべてのソース項目と前身を保持しながら、権威あるホスト済みレポートを1つ確立します。このスキルでは、ここでのライフサイクルの意味付け、preflight-mutations を通じた共有状態の認可、および done を通じた最終受け入れを調整します。

1. レポート一式を棚卸しする

レポートのタイトル、安定 ID、ソース URL、または主題に一致するホスト済みの分析成果物をすべて見つけられるよう、対象範囲を広く取った、権威あるホストまたはワークスペースの検出クエリを1つ実行します。正確なクエリ、該当するすべての項目の安定したホスト ID と現在のガードを記録し、それぞれを根拠とともに source、canonical-candidate、または unrelated に分類します。

すべてのソースと正規候補について、レンダリング済みのコンテンツと安定 URL を取得します。それぞれについて、URL、タイトル、書き込み権限、現在の権限または置き換えを示すマーカー、およびソースが所有する調査結果または項目の ID とそれらの直接的な根拠 URL を記録します。ソースワークフロー ID は保持します。レポートに ID がない場合は、ソースを変更せずに成果物のスコープ内で ID を割り当てます。

読み取り専用の棚卸しとステージングの間は、この作業記録をインラインで保持します。複数の書き込みを伴う公開を開始する前に、このワークフローでの書き込みをユーザーが許可した既存の永続的な台帳に記録を保存します。その安定 URL またはパスを記録し、実行中は正規公開先および前身の公開先のいずれからも外れていることを確認します。そのような台帳がない場合は、適切な既存の成果物への書き込み認可を次のアクションとして明示し、作業を停止します。ライフサイクルレジストリは作成しません。

ゲート条件は、正確な検出クエリと分類したすべての項目が記録されていること、すべてのソース、正規候補、ソース項目がそれぞれ1回ずつ記載されていること、書き込み権限が判明していること、そして権限に関する競合する主張が明示されていることです。

2. ステージングする正式レコード

既存のホストされた書き込み可能な正式候補の中から、安定した URL と現在の書き込みガードが確認できるものを 1 つ選びます。該当するものがない場合は、そこで停止し、そのホストされた候補の作成または選定を次のアクションとして示します。このスキルでは、最初の正式オブジェクトは作成しません。

選定後、すべての検出結果を canonical、writable-predecessor、unwritable-predecessor、unrelated のいずれかに再分類し、無関係とした各検出結果には理由を付けます。現在の正式な情報源を名乗る非正式な検出結果は、いずれかの先行物のクラスに分類し、ライフサイクルレコードと公開計画に記載する必要があります。

ライフサイクルの Artifact ID は、ホストされたバージョンとは独立させます。既存のライフサイクル ID を再利用するか、一度だけ割り当て、置き換え後も維持します。また、選定したバージョンのホスト側オブジェクト ID と URL は別途記録します。

このセクションを正式レポートにステージングします。

## Report lifecycle

- **Artifact ID:** <stable ID>
- **Current host object ID:** <host ID>
- **Canonical URL:** <exact URL>
- **Source reports:** <complete URL list>
- **Supersedes:** <complete predecessor ID and URL list>
- **Unwritable predecessors:** <URL and reason, or none>

書き込み可能な先行物ごとに、取得したレポート全体と Superseded by [<artifact ID>](<canonical URL>). をステージングします。元の本文と出典を明記した証拠は、バイト単位でそのまま保持します。マーカーだけの置き換えは有効なペイロードではありません。書き込み不可の先行物とその理由は、マーカーがないことを成功として扱わず、正式レポートに記録します。

各ソース項目について、次のいずれか 1 つの扱いを選択します。

ソース項目 ID	ソース証拠 URL	扱い	正式な格納先または理由
		carried | merged | dismissed | retained-by-reference	<正式項目／アンカー ID または却下理由>

carried と merged では、既存の正式な格納先 ID を指定します。dismissed では理由を記録します。retained-by-reference では、元の証拠へのアクセスを維持する正式なアンカーを指定します。本当に同等な項目だけを統合します。固有の調査結果は、ソースレポート全体をコピーするのではなく、個別の格納先または参照として保持します。

公開用ペイロードをレンダリングする前に、扱いの対応表を確定して検証します。ソース項目 ID がインベントリと完全に一致し、行の重複がなく、指定された正式な格納先またはアンカーがすべてステージング済みの正式レコードに存在することを必須とします。

正式なペイロード全体と、書き込み可能な先行物ごとのペイロード全体を、それぞれ別個の不変なローカルステージングパスにレンダリングし、各パスは一度だけ書き込みます。各パスと SHA-256 ダイジェストをライフサイクル台帳に記録します。凍結済みファイルを上書きまたは再生成してはいけません。バイト列を変更する場合は、新しいパス、ダイジェスト、プレビュー、事前チェックが必要です。

ゲートの要件は、既存のホストされた書き込み可能な正式候補とガードが確認されていること、すべての検出結果の最終分類が完了していること、正式な情報源を名乗るすべての非正式な候補が先行物として関連付けられていること、正式なペイロード、先行レポートとマーカーのペイロード、および項目対応表が完全にステージングされ、各ソース項目に有効な扱いがちょうど 1 つ割り当てられていることです。

3. 公開計画を事前チェックする

次の要素をすべて含む、完全な論理的公開計画を1つ作成します。

• 完全な正規ペイロードとその現在の書き込みガード。
• すべての正規ペイロードおよび書き込み可能な先行ペイロードについて、凍結されたローカルパス、SHA-256 ダイジェスト、現在の書き込みガード。
• アーティファクト ID、正規 URL、ソース URL、置き換え対象のリスト、書き込み不可能な先行項目の記録。
• すべてのソース項目の処置と、移動先またはその理由。
• 権威あるレンダリング済みリンクと重複ステータスの読み戻し計画。
• すべての書き込みにまたがる依存関係の順序。

所有権、環境、可逆性、確認の各ドメインが異なる箇所で、preflight-mutations の要件に従って計画を1つ以上の変更カードに分割します。すべてのカードをまとめてプレビューします。各カードについて、最初の書き込みの直前に preflight-mutations を呼び出し、正確な対象、認可、ガード、復旧、無効化要因、順序付き項目、依存関係、読み戻し計画を渡します。

プレビューした依存関係の順序に従って、各カードに対する preflight-mutations の結果契約を適用します。ブロック中または確認が必要なカードと、それに依存する書き込みは保留のままにします。新しい対象、マーカー、または内容の変更があった場合は、計画全体をプレビューに戻します。無効化されたカードのみを再度事前チェックします。

ゲートの条件は、完全なプレビューがすべてのライフサイクル書き込みを網羅し、各書き込みがドメインに適合するカードにちょうど1つだけ属し、プレビューされていない書き込みや依存関係に違反する書き込みを実行できないことです。

4. 公開して整合性を確認する

生成し直さずに、ステージング済みの正規ペイロードと、先行項目の報告＋マーカーペイロードを適用します。各書き込みの直前に、凍結ファイルのハッシュを再計算し、ダイジェストが台帳および現在の変更カードと一致することを確認します。一致しない場合は、書き込みの前にそのカードを無効化します。永続的な台帳で、その項目を pending から attempting にアトミックに遷移させ、期待される状態からの遷移が成功した場合にのみ続行します。公開計画の依存関係の順序と結合された項目台帳を維持しながら、各カードについて preflight-mutations の実行および部分状態の契約に従います。各書き込みを試行した後、本文とガードを権威ある方法で読み戻し、次の書き込みに進む前に、その項目の結果、読み戻したガード、観測した本文ダイジェストを永続的な台帳にアトミックに保存します。台帳の遷移が利用できない、または曖昧な場合は、依存する残りの処理を停止します。読み戻した完全な本文が凍結バイト列と一致する場合にのみ、項目を landed として記録します。マーカーの書き込みを landed として記録する前に、すべての先行項目について取得済みコンテンツと帰属が確認された証拠が損なわれていないことを確認し、読み戻したガードをその対象の期待される書き込み後ガードとして記録します。

ゲートの条件は、すべての公開計画項目に権威ある結果があり、すべての landed ペイロードがステージング済みの内容と一致し、正規レポートと各書き込み可能な先行項目について、権威ある読み戻しから期待される書き込み後ガードが取得できていることです。

5. 権威性とエビデンスを検証する

レンダリングされた正規レポートとすべての先行項目を再取得して読み直します。正規リンク、ソースリンク、先行項目へのリンク、エビデンスへのリンクをすべて確認します。フェーズ 1 の検索クエリをそのまま再実行し、安定したホスト ID とガードを期待されるセットと比較します。反映済みの対象にはフェーズ 4 の権威ある書き込み後ガードを使用し、変更されていない一致項目にはフェーズ 1 のガードを使用します。期待される反映済みガードはドリフトではありません。安定した ID がない、新しい一致項目がある、または期待されるセット外のガードがある場合は、棚卸し、ステージング、事前チェックに戻ります。続行する前に、予期しない一致項目をすべて取得します。

完了には、次の条件を満たす必要があります。

• 正規レポートに、正確なライフサイクルアーティファクト ID、現在のホストオブジェクト ID、正規 URL、完全なソース URL、置き換えられた項目のリストが記載されていること。
• 書き込み可能な先行項目すべてに、正規の置換マーカーとリンクが表示されること。
• 書き込み不可能な先行項目とその理由がすべて正規レポートに記載されていること。
• すべてのソース項目が項目マップに一度だけ記載され、到達可能な移行先または記録された除外理由があること。
• レンダリングされた必須リンクがすべて解決されること。
• 書き込み可能な競合する権威情報や、現在の権威情報として示される重複項目が残っていないこと。

完了前に、不足しているエビデンスやリンクを修復して再確認します。書き込み可能な競合する権威情報、必須リンクの破損、または未処理のソース項目がある場合は、完了できません。

該当する最終ドキュメント、外部メタデータ、公開の各レーンについて done を実行します。最終項目台帳、レンダリングされたリンクの結果、重複ステータスのクエリ、書き込み不可能な先行項目、正確な次のアクションを含めます。

ホストされたレポートが 1 つ正規のものとして検証され、すべての先行項目にマークまたは説明があり、すべてのソース項目が処理され、完了の主張が done のエビデンスの上限と一致した時点で、実行は完了です。