quality-mind

name	quality-mind
description	常に、すべてのユーザー依頼とすべての作業判断で必ず使う共通 skill。コード実装、設計、レビュー、テスト、QA、調査、文章作成、要約、説明、コマンド実行、ファイル操作、ブラウザ操作、画像生成、意思決定、日常的な相談を含むあらゆるタスクで、肯定的な視点と批判的な視点の両方から、入力、前提、境界値、ドメイン外値、悪意ある異常系、権限、状態整合性、リグレッション、未検証リスク、ユーザー意図とのズレを確認する。タスクが軽微でも発動し、リスクに応じて確認の深さだけを調整する。

Quality Mind

すべてのユーザー依頼と作業判断で、対象の目的・前提・失敗条件・悪意ある操作・誤解の余地を整理し、人間が実際に触ったときにすぐ分かる事故や「ありえない値を通してしまう」問題を事前に潰す。

この skill はまず working の mind であり、testing はその確認手段の一部である。コードに限らず、調査、説明、文章作成、設計、実装、テスト、QA、ブラウザ操作、画像生成、ファイル操作、コマンド実行のすべてで「どう壊されるか」「どの前提が間違っているか」「どの状態が不整合になるか」「どの値がドメイン上ありえないか」を考え、作業判断に反映する。

常時発動

1. ユーザーからの依頼、追加指示、質問、レビュー依頼、実装依頼、調査依頼、雑談的な相談を含むすべてで必ず発動する。
2. コード作業でない場合も、ユーザー意図、事実確認、出典、言葉の曖昧さ、期限、対象範囲、危険な助言、誤解を招く表現、実行したコマンドや操作の副作用を確認する。
3. 軽微な作業では、確認を短く内省してすぐ実行する。高リスク、不可逆、外部依存、ユーザー影響、法務・医療・金融・個人情報・セキュリティを含む作業では、観点を明示して深く確認する。
4. 常時発動しても、ユーザーへの報告を過剰にしない。最終回答には、判断に影響したリスク、実行した検証、未検証事項だけを簡潔に含める。

基本方針

1. 対象タスクの入力、出力、副作用、権限、永続化、外部連携、クライアント状態、ユーザー意図、事実前提を確認する。
2. リポジトリ作業では、仕様、既存テスト、バリデーション、ドメイン用語、DB スキーマ、API 契約、ドキュメントを読む。
3. 対象タスクや機能に必要なドメイン知識は、判断・実装・テスト観点を確定する前に web 検索で確認する。医療、法務、労務、税務、金融、物流など正確性が重要な領域や、現行制度・法律・料金・規格など変わり得る情報は、最新の一次情報を優先して確認し、確認した制約を境界値・ドメイン外値・状態遷移・整合性の観点へ落とす。
4. 必ず肯定的な視点と批判的な視点の両方で考える。期待どおり動く理由と、壊れる理由・悪用される理由を両方洗い出す。
5. 判断と検証観点を、正常系、境界値、ドメイン外値、悪意ある異常系、状態整合性、リグレッションに分けて作る。
6. 仕様やバリデーション不足が見つかった場合は、テストで期待値を固定するだけで終わらせず、実装で防ぐ。

非自明な変更では、確認した仕様、ドメイン前提、品質観点、未検証リスクを memory（MEMORY.md）やプロジェクトの plan / QA 系 md へ適宜記載して残す。軽微な作業や read-only 調査では記録を増やさない。

レビュー・QA 指摘への横展開

レビューや QA で指摘された内容は、指摘箇所だけを直して完了してはいけない。必ず指摘を「失敗パターン」に変換し、同種の品質事故が別の場所に残っていないか横断確認する。

1. 指摘を具体行ではなく失敗パターンに変換する。
   • 直書き文字列: 同じ意味の定数化漏れ、i18n 漏れ、エラー契約の分散。
   • View / serializer / component での永続化や副作用: repository / service 境界違反、責務の混在。
   • 重複した lock / state / queue / retry 管理: 共通化漏れ、状態遷移の再実装。
   • catch、return null、fallback、best-effort: 不整合を隠すエラー処理。
   • UI disable や hidden field だけの制御: サーバー側検証・権限・状態遷移チェック漏れ。
2. 失敗パターンごとに repo 全体を横断検索する。文字列だけでなく、model 名、API 名、private field 名、類似メソッド名、エラー文言、権限チェック、永続化、副作用、fallback を検索対象に含める。
3. 検索結果を OK、修正対象、判断保留 に分類する。
   • OK: 定数定義、repository 内の ORM、test expectation、migration、明確に別責務の既存コード。
   • 修正対象: presentation 層からの直接永続化、同じ責務の再実装、同じエラー文言の分散、UI だけで守っている権限・状態制御、不整合を隠す fallback。
   • 判断保留: 仕様・責務境界・互換性・影響範囲が曖昧で、修正すると別機能に波及する可能性があるもの。保留する場合も理由と次アクションを明示する。
4. 修正後に同じ検索を再実行し、残ったヒットがなぜ安全か説明できる状態にする。
5. 最終報告には、対応した指摘だけでなく、横展開した検索観点、残ったヒットの理由、実行したテスト、未検証リスクを含める。

実装時の防御設計

• 肯定的な視点では、ユーザーが正しく操作したときに最短で価値へ到達できるか、自然な入力・既存データ・期待される状態遷移で破綻しないかを確認する。
• 批判的な視点では、仕様の穴、過剰な楽観、暗黙の前提、改ざん可能な値、競合状態、権限漏れ、DB 不整合、観測できない失敗を探す。
• 例: 「プロフィール更新」は、肯定的には正しい名前・住所・メールが保存され画面と API が一致することを確認し、批判的には他人の userId、空白名、巨大文字列、重複メール、localStorage 改ざん、二重送信で壊れないか確認する。
• 例: 「支払い」は、肯定的には正常な金額・通貨・支払い状態で注文が完了することを確認し、批判的には負の金額、小数桁不一致、期限切れ token、二重クリック、支払い成功後の DB 部分失敗、他 tenant の注文 ID を確認する。
• 実装時は、入力を受けた瞬間、状態を変える瞬間、外部へ出す瞬間、永続化する瞬間、表示する瞬間の各境界で、何を拒否し、何を正規化し、何を記録し、何を返すかを決める。
• エラー処理は「落ちないようにする」ではなく「不正状態に入らないようにする」ために設計する。握りつぶし、空配列返却、null fallback、best-effort 更新で整合性を壊さない。
• 妥協した実装で終わらせない。フォールバック、互換レイヤー、暫定分岐、握りつぶし、二重実装で問題を隠す前に、本質的な実装で解決する手段を探す。
• ユーザーから互換性維持の明示がない限り、古い挙動や旧 API との互換性を目的にした過剰実装を入れない。正しい設計へ寄せるための破壊的変更を避けない。
• 破壊的変更が必要な場合は、影響範囲を具体的に洗い出し、テストと移行作業で吸収できるなら実装する。
• 影響範囲やリグレッション範囲が大きく、複数機能・複数サービス・永続データ移行・公開 API・ユーザー操作フロー・権限モデルにまたがる場合は、実装前にユーザーへ確認する。
• フォールバックを入れる場合は、なぜ本質的な実装では不十分なのか、いつ削除できるのか、テストでどう保証するのかを明示する。
• UI、API、DB、外部連携のどこで防御するかを分けて考える。UI の制御だけで安全とみなさない。
• サーバー側で必ず権限、所有者、状態遷移、入力形式、範囲、単位、参照整合性を検証する。
• DB 制約、型、enum、unique、foreign key、transaction、idempotency が必要か確認する。
• cookie、localStorage、sessionStorage、URL query、hidden field、API request body はユーザーが改ざんできる前提で扱う。
• API response は UI 表示だけでなく、値の意味、権限外データの混入、不要な個人情報や内部情報の露出まで確認する。

実装・検証の共通観点

正常系

• 実装時は、正しい入力と状態で最短経路が自然に通る設計にする。正常系のために例外的な分岐や hidden な前提を増やさない。
• 代表的な成功ルートを 1 つだけに固定しない。入力、状態、権限、既存データの組み合わせが複数あり得る場合は、最低 3 パターンを検討する。
• ユーザーが実際に使う自然な値を使う。金額、年齢、日付、時刻、住所、メールアドレス、ID、長文などは対象ドメインで妥当な形式にする。
• 仕様上重要な副作用を確認する。DB 更新、通知、ログ、イベント発行、権限変更、画面遷移、キャッシュ更新、外部 API 呼び出しなど。

境界値

• 実装時は、境界条件を UI だけでなくサーバー側・DB 制約・型・schema でも表現する。境界値の扱いを呼び出し元の善意に任せない。
• 数値は min - 1、min、min + 1、max - 1、max、max + 1、0、1、-1、小数、巨大値、丸め誤差、桁あふれを確認する。
• 比較条件は <、<=、>、>=、=== の違いを明示して確認する。
• 日付と時刻は月初、月末、年初、年末、うるう年、存在しない日付、タイムゾーン、DST、当日境界、期限ちょうど、期限切れ直後、未来日、過去日を検討する。
• 文字列は空文字、空白のみ、前後空白、最大長、最大長超過、改行、タブ、絵文字、マルチバイト、結合文字、正規化差分、大文字小文字差分、制御文字を検討する。
• UI の文字入力は、IME での入力途中(composing)、変換確定前の値、入力中のフォーカス喪失・再レンダリング・他ユーザーの更新で壊れないかを検討する。
• 配列やリストは 0 件、1 件、上限件数、上限超過、重複、順序違い、ページング境界を確認する。
• ファイルは 0 byte、上限サイズ、上限超過、拡張子偽装、MIME 不一致、壊れたファイル、同名ファイルを確認する。

ドメイン外値

• 実装時は、ドメイン上ありえない値が保存・送信・表示される前に拒否する。DB に入れてから画面で隠す実装にしない。
• ドメイン上ありえない値を必ず洗い出す。例: 負の年齢、未来の誕生日、存在しない郵便番号、負の金額、通貨と小数桁の不一致、開始日が終了日より後、退職日が入社日より前。
• 単位、通貨、税率、丸め、タイムゾーン、営業日、締め日、法定上限、契約状態など、対象ドメイン固有の制約を確認する。
• 状態遷移の不正を確認する。例: 下書きでないものを再編集、承認済みを未承認に戻す、削除済みを更新、支払い済みを二重請求。
• 権限と所有関係の不正を確認する。例: 他人の ID を指定、別 tenant のデータ参照、管理者専用 API を一般ユーザーで実行。

悪意ある異常系

• 実装時は、ユーザーが改ざんできる値を信頼しない。権限、所有者、tenant、状態遷移、金額、時刻、ロール、ID はサーバー側の信頼できる情報から再計算・再検証する。
• 悪意しかない利用者を前提にする。入力、URL、cookie、localStorage、API payload、ヘッダー、ID、時刻、実行順序、通信回数はすべて改ざんされるものとして見る。
• SQL/NoSQL injection、XSS、CSRF、SSRF、パストラバーサル、オープンリダイレクト、認可漏れ、IDOR、過大 payload、rate limit 回避を対象に応じて確認する。
• 必須項目欠落、不正形式、存在しない ID、削除済みデータ、期限切れ token、改ざん token、ネットワーク失敗、外部 API 失敗、部分失敗を検討する。
• 連打、二重送信、戻る進む、複数タブ、並列 request、リロード、途中離脱で状態が壊れないか確認する。
• エラー時の挙動を確認する。安全な失敗、分かりやすいバリデーションメッセージ、機密情報の非露出、ロールバック、再試行可否を確認する。

状態整合性

• 実装時は、状態変更を transaction、idempotency、unique 制約、foreign key、監査ログ、再試行設計で守る。部分成功・二重実行・途中失敗が不整合を残さないようにする。
• 操作後、確認可能であればローカル DB の値を直接確認し、値が適切で整合性があり、期待した consistency を満たすか確認する。
• 作成、更新、削除、キャンセル、承認、支払い、権限変更などの操作後は、関連テーブル、履歴、集計、キャッシュ、監査ログまで確認する。
• API の response body、status code、headers、error code、pagination、権限外フィールドの有無を確認する。
• cookie、localStorage、sessionStorage の値、期限、secure/httpOnly/sameSite 相当の設定、ログアウト後の消去、権限変更後の更新を確認する。
• UI 表示と DB/API の実体が食い違っていないか確認する。画面だけ成功して DB が未更新、DB は更新されたが UI が stale、API は余計な値を返す、などを拾う。

リグレッション

• 実装時は、変更対象の呼び出し元、共有型、schema、API 契約、権限モデル、永続データへの波及を先に洗い出す。必要なら本質的な設計変更を優先し、互換性維持のための暫定分岐に逃げない。
• 今回の変更が触る呼び出し元、共有コンポーネント、スキーマ、既存 API、既存画面、既存データに波及しないか確認する。
• 既存テストがある場合は近いテストを優先して拡張し、同じ意図の重複テストを増やさない。
• 既存仕様が曖昧な場合は、現在の挙動を確認してから期待値を固定する。

検証に落とす

• まずテスト対象に最も近い粒度を選ぶ。純粋関数やバリデーションは unit、DB や API 境界は integration、ユーザー導線とクライアント状態は E2E を優先する。
• 条件が複数軸(新旧実装、設定の ON/OFF、権限、言語など)にまたがる場合は、直交マトリクスで組み合わせを列挙してから対象を選ぶ。省いた組み合わせは未検証として明示する。
• 1 テスト 1 意図を基本にし、複数条件を詰め込みすぎない。
• fixture は現実的な値にする。foo、test、123 だけで済ませず、ドメイン上あり得るデータと、ドメイン上ありえないデータの両方を明示的に作る。
• ランダム値や現在時刻に依存する場合は固定する。
• 外部サービス、時刻、乱数、権限、環境変数、DB の既存状態の差で flaky にならないようにする。
• バグ修正では、修正前に落ちる失敗再現テストを優先する。

仕上げ

1. 実装が本質的な解決になっているか、フォールバックや暫定分岐で問題を隠していないか見直す。
2. 追加または更新したテストを実行する。fail した場合は、修正 → 当該テストの再実行 → 最後に冒頭から通しで再実行し、すべて green の状態で完了とする。skip・未実行のテストを pass 扱いにしない。
3. 関連する lint、typecheck、build がある場合は必要範囲で実行する。
4. 実装後、可能ならローカル DB、API response、cookie、localStorage、sessionStorage を確認し、操作後の状態が仕様と整合していることを確認する。あわせてサーバー・コンテナのログとブラウザコンソールを確認し、エラーが残った状態を pass にしない。
5. 未検証の観点、環境制約、外部依存、ユーザー確認が必要な仕様を明示する。
6. 見つけた仕様不足、バリデーション不足、セキュリティ懸念は、実装修正または次アクションとして報告する。