product

Product

ユーザーの権限のもと、プロダクトの契約を作成または改善します。

この契約が機能するのは、すべての主張を根拠または明示された希望に分類するためです。読者が両者を区別できない場合、そのドキュメントは失敗です。

1. 既存のプロダクト、README、目標、リリース、根拠となる情報源を確認します。
2. それらの情報源から安全に判断できない事柄についてのみ、決定を求めます。
3. ミッション、ユーザー、課題、価値、差別化要因、対象外事項を明示します。このリポジトリ独自のプロダクトの領域については、docs/contracts/ubiquitous-language.md の標準カテゴリ（AgentOps はエージェント型エンジニアリングの運用レイヤー）を出発点とし、小さな責任範囲を維持します。AgentOps を実行オーケストレーター、ファクトリー、またはループとして再定義してはいけません。
4. 根拠と期待を、必須の 2 つの見出しの下で分けます。根拠のある主張はすべて ## Proven の下に記載し、それぞれ解決可能な引用（README、リリース、テスト、または根拠となる情報源）を付けます。未実証の期待、根拠の不足、未測定の成功指標はすべて ## Assumptions の下に記載します。情報源を引用できない主張は ## Proven ではなく、## Assumptions に記載します。
5. ユーザーが置き換えを許可しない限り、既存の PRODUCT.md を維持します。
6. ドキュメントを呼び出し元に返します。Plan はこれを意図のコンテキストとして使用できます。

名前付きの失敗モード — 期待のロンダリング：未実証の期待を ## Proven セクションに記載することです。いったんロンダリングされると、後続のすべての計画が誤った前提を引き継ぎます。検出方法：解決可能な引用のない ## Proven の主張は、すべてロンダリングされた期待です。## Assumptions に移すか、引用を付けてください。

アンチパターン：セッションで新たな意見が出たという理由で、健全な PRODUCT.md を全面的に書き換えること。是正策：ユーザーが変更を求めたセクションのみを改善し、残りはバイト単位でそのまま維持します。

Product は作業を選択せず、ループを起動せず、自身を修復または検証せず、デリバリー方法も選択しません。