# セルフチェックの観点

`/selfcheck` が点検の順番と深さを決めるときに読む基準です。観点そのものの一覧は `.claude/skills/kadaia-review/SKILL.md` にあります。こちらは「どう判定するか」を決めます。

## 深刻度の判定基準

| 深刻度 | 判定の目安 | 例 |
|---|---|---|
| 高 | そのままでは動かない、データが壊れる、利用者の入力がそのまま実行・表示される | 一覧が表示されない、`fetch` でローカル CSV を読もうとしてブラウザに止められる、利用者の入力を `innerHTML` にそのまま入れている |
| 中 | 動くが、仕様との食い違い・境界の取り違え・保守しづらさがある | 在庫のしきい値が「未満」になっている、日付の表記が画面ごとに違う、同じ処理が3箇所にコピーされている |
| 低 | 好みの範囲、または今日の演習の範囲外 | 変数名の揺れ、インデント、CSS の細かい体裁 |

判断に迷ったら、次の順に問います。

1. ブラウザで開いて、依頼どおりに動くか。動かないなら「高」。
2. `kadaiA/docs/お題シート.md` の要件と食い違うか。食い違うなら「高」。
3. `docs/セキュリティチェックリスト.md` の項目に触れるか。触れるなら「高」または「中」。
4. `docs/コーディング規約.md` に反するか。反するなら「中」。
5. どれにも当てはまらないなら「低」。

## 点検の順番

深刻度が高くなりやすい順に見ます。時間切れになったときに、重い指摘から先に手元に残るようにするためです。

1. 動作（ブラウザで開くだけで動くか、50件表示されるか、検索と詳細が動くか）
2. データの扱い（`dummy_data.csv` を書き換えていないか、読み込み方法がブラウザの制限に当たらないか）
3. 入力値と表示（利用者の入力をそのまま HTML に入れていないか、件数0のときの表示があるか）
4. 仕様との突き合わせ（`kadaiA/docs/お題シート.md` の必須項目が揃っているか）
5. 読みやすさと保守（規約違反、重複、マジックナンバー）

## 指摘に必ず付けるもの

指摘は1件ずつ、次の3つを揃えて書きます。揃わない指摘は書きません。

- 場所：ファイルの相対パスと行番号
- 事象：何がどうなるか（推測ではなく、コードのどの記述から言えるか）
- 根拠：どの観点・どの規約に基づくか。参照元のファイル名と見出し名を書く

「一般的にはこうすべき」という書き方は使いません。今回の題材のどこに当たるかを書きます。

## 直さないと決めてよいもの

`/selfcheck` は全件を直しません。次に当てはまるものは `.work/03_fix_plan.md` に「直さない」と理由付きで記録し、`kadaiA/REPORT.md` の未対応欄に載せます。

- 深刻度「低」のもの
- 直すと依頼していない機能追加になるもの
- 直し方が複数あり、どれを選ぶかで仕様が変わるもの（これは REPORT.md の「人間に判断してほしいこと」へ回します）
- `dummy_data.csv` の変更が必要になるもの

## 人間に判断してほしいことの書き方

AI が決めきれなかったものを、次の形で書きます。曖昧な「ご確認ください」は書きません。

```
- 論点: <何を決める必要があるか>
  選択肢: A) <案> / B) <案>
  影響: <どちらを選ぶと何が変わるか>
  AI の見立て: <どちらが有力か、その理由>
```
