dogfood

ドッグフーディング

ドッグフーディングでは、人が実際のアプリを操作し、ユーザー向けのすべての機能を試して、目にする内容を評価します。成果物はケースカタログと人間向けガイドのレンダリング版です。アプリ自体のレンダリングを根拠として、機能ケースごとに1行を設け、要件 ID とケース種別を付けます。成果物を作成してください。チャットメッセージは成果物ではありません。正常系だけのガイドでは不十分です。

ケース分類（すべてのガイドで次の種別を使用）

kind	意味	典型的な参照元
happy	機能が本来の目的どおりに動作する	要件に記載された主要なユーザーストーリー
edge	境界値／空／重複／最大文字数／空白	同じ ID または関連する ID にある境界条件
error	ユーザーに見える失敗経路（バリデーションチップ、4xx メッセージ、入力が保持されるなど）	要件に記載されたエラー条件
nonbehavior	発生してはならないこと	対象外事項、否定形の SHALL
persist	リロード／再オープン／クライアントの再起動後も保持される	「保持される」と記載された条件、またはストアが管理する状態
visual	レイアウト、色、空状態の文言、見た目 — 人の目による確認	表示要件。サーバーへの書き込みなし
journey	複数の手順で個別ケースをつなぐワークフロー（任意、ガイドごとに最大2件）	複数のストーリーをまたぐユーザーパス

この場でカオス、負荷、競合、セキュリティファズのテストスイートを作らないでください。これらは、1人のユーザーによる操作確認の対象ではありません。権限／ロールのケースは、UI で公開されている場合に含めます（ロール用の setup を伴う edge または error）。

1. すべての機能を対象にする — カバレッジのゲート

対象機能の requirements.md、design.md、tasks.md を読みます。ユーザーが確認できる機能をすべて列挙してください。新機能だけでなく、同じユーザーワークフローに隣接する機能も含めます。

カバレッジのルール（§4 の完了前にすべて満たすこと）：

1. ユーザー向けの要件 ID すべてに、1件以上のケースがあること。
2. 機能領域（ガイドの各セクション）に、1件以上の happy と、1件以上の edge | error | nonbehavior | persist のいずれかがあること。
3. ユーザーが試せる対象外事項／意図的に動作させない仕様すべてに、nonbehavior ケースを設けること（または、引き継ぎ資料に これを試すユーザー向けの方法がないためスキップ と明記すること）。
4. 永続性を主張する条件すべてに、persist ケースを設けること（または、リロード／ストアを確認できる happy／edge ケースの Expect + backend で証明すること。専用の persist 行を設けて、スキップされないようにすることを推奨します）。
5. 仕様に edge、error、nonbehavior、persist に関する情報がない機能領域については、そのセクションに次の1行を記載してください：カバレッジ例外：仕様に edge/error/nonbehavior/persist の記載なし — 製品の動作をでっち上げないでください。この例外は検索可能な誠実さを示すためのものであり、仕様に該当情報があるのに省略してよいという意味ではありません。

ID または関連する ID に境界条件が記載されている場合、ID ごとに happy ケースを1件設けるだけでは不十分です。

完了条件：上記のカバレッジルールを満たすか、すべての例外をガイドに記載していること。

2. 各ケースを実際のコードに基づかせる

各ケースについて、コードを読み、ユーザーが実際に目にする内容を確認します。正確な用語（キーワード、コマンド名、ラベル）、キーボードショートカット、実際のレンダリング（バッジの色、チップのスタイル、アイコンなど）を、推測ではなくソース（テーマトークン、CSS）から確認してください。コードから明らかな注意点（区切り文字が削除されず薄く表示される、ステータスにまだ UI がないなど）があれば、ケースに記載します。

3. 実際のアプリを起動し、確実に観察できる方法を見つける

docs/agents/project.md に記載された Run locally (dev) コマンドでアプリを起動します。見つからない場合は確認して記録してください（acceptance-ui を参照）。機能にキーが必要、サブ機能がまだ未実装など、制約のある領域は最初に明示します。UI がない動作にもケースを設け、実際に確認できる方法（devtools の invoke(...)、読み取り専用の DB 確認など）を使ってください。画面があるかのように装わないでください。完了条件：アプリが起動しており、まだ可視化されていないすべての動作に観察方法が用意されていること。

4. ケースを作成してシェルをレンダリングする（CSSは作り込まない）

作成時の信頼できる唯一の情報源（SSOT）はケースファイルであり、手書きのHTMLではありません。

1. .skills/<slug>-dogfood.cases.yaml を作成します（スキーマがわからない場合は、同階層の references/cases-schema.md を読み込んでください）。各ケースには、必須項目をすべて含めます：id、req、kind、title、setup、try、expect、backend（backend はサーバー側のアサーション、または文字列 presentational です）。

2. 人間向けガイドは、チェックイン済みのシェルからレンダリングします。ユーザーからカスタムの作り込みを明示的に求められない限り、design-page を読み込んだり、配色やレイアウトを独自に考案したりしないでください：

   python3 <skill-root>/scripts/dogfood render .skills/<slug>-dogfood.cases.yaml \
     -o .skills/<slug>-dogfood.html
   

   <skill-root> は、このスキルのインストール先パスに解決します（このモノレポでは skills/acceptance/dogfood）。シェルは shell/guide.html です。テーマ対応のCSS/JS、種別チップ、人間が操作するlocalStorageのチェック欄、旧形式のリーダー向けの data-* 属性を備えています。

3. カバレッジのセルフチェック： セクションごとに kind 別のケース数を数えます。非ハッピー系の種別がなく、カバレッジ例外の行もない能力領域があれば、引き渡し前に不足しているケースを追加します。

任意：journey 行は最大2つまでとし、個別のカバレッジの代わりにはなりません。

チャットだけのチェックリストを納品しないでください。デフォルトの手順として、カスタムHTMLページ全体を再生成しないでください。ケースを作成して render するのが正しい手順です。

完了条件：ケースYAMLとレンダリング済みHTMLが既知のパスに保存され、カバレッジが満たされ、すべてのケースに必須項目がそろっていること。

5. 引き渡す

両方のパス（ケースYAMLとHTML）と、最速で始める方法を伝えます。機能が動く約30秒の初回確認手順（通常は最初の happy 行）を案内し、その後に機能縮退時の注意事項とカバレッジ例外を伝えます。HTMLのチェックボックスへのチェックは、任意のlocalStorageの便利機能であることも伝えてください。エージェントにガイドを実行させる場合は、drive-dogfood とケース（またはHTML）のパスを指定します。進捗には、ガイド上のChromeのチェックではなく、CLIの台帳が使われます。

完了条件：成果物がディスク上にあり、根拠に基づいていて、§1のカバレッジゲートを満たし、すべてのケースに必要な項目がそろっていること。

よくある正当化

考え	実際
「チャットにMarkdownのチェックリストを載せれば十分」	チェック状態を保存できず、実際のバッジと照らし合わせていることも示せず、スクロールすると見えなくなります。納品物はケースとレンダリング済みガイドです。
「この機能専用の独自レイアウトをdesign-pageで作ろう」	デフォルトではチェックイン済みのシェルを使います。カスタムの作り込みはユーザーから求められた場合に限ります。
「ブラウザーではなくネイティブのデスクトップアプリだから、成果物は合わない」	成果物はアプリの横に開いておく補助資料です。アプリがネイティブであることは、ガイドをチャットに埋め込む理由にはなりません。
「バッジを言葉で説明しよう」	ユーザーは実際に見えるものを基準に確認します。実際の表示を再現しなければ、期待結果を検証できません。
「要件ごとにハッピーケースが1つあれば十分」	カバレッジゲートでは、非ハッピー系の種別（または明記された例外）が必要です。ハッピーケースだけではデモであり、ドッグフードテストではありません。
「境界ケースはガイドではなくユニットテストに入れるべき」	ドッグフードテストはユーザー向けの実際の操作面です。ユーザーが遭遇し得る境界ケースは、行として追加します。
「悪いケースとは負荷・カオス・ファジングのことだ」	それらは別のハーネスで扱います。ドッグフードテストの悪いケースは、境界、エラー、無動作、永続化です。

危険信号

• ケースYAMLと dogfood render の代わりに、HTML/CSSページ全体を手書きしている
• いずれかのケースで backend／setup／kind が欠けている
• grepで見つけられるカバレッジ例外がないまま、セクションがハッピーケースだけになっている
• HTMLのlocalStorageのチェックだけで進捗を記録するよう、エージェントに指示している