kamae-review

Kamae コードレビュー

kamae の原則に照らした敵対的レビューです。ナレッジベースは ../kamae/ にあり、このスキルは内容を重複させずにリンクします。

ステップ 0：適用されるルールを読み込む

他のステップに進む前に、優先順位に従って glob でルールを検索し、読み込みます。

1. .claude/rules/*.md（作業ツリーのルートにあるプロジェクトレベルのオーバーライド）
2. ~/.claude/rules/*.md（ユーザーのグローバル設定）
3. この SKILL.md からの相対パス ../../rules/defaults/*.md（プラグインのデフォルト）

各ファイルについて：

• YAML frontmatter を読みます。applies-to が kamae-review または * でないルールはスキップします。
• name ごとにグループ化します。同じ name では、最も優先度の高い階層のものだけを残します（1 > 2 > 3）。同じ階層内では、ファイル名の辞書順で最後のものを残します。
• enabled: false の check-toggle ルールは、以下のステップ 3 のチェック項目から指定されたチェックを除外します。
• convention ルールは、レビューで尊重するプロジェクト固有の期待事項を定めます（例：Branded Types の指定場所）。

ルールが見つからない場合は、すべてのチェックを有効にして続行します。ルールの形式については、../../rules/README.md を参照してください。

レビュープロセス

1. 原則に関するナレッジを読み込みます。 レビュー対象のコードを読む前に、以下を読みます。

   • ../kamae/SKILL.md — 原則のインデックス
   • ../kamae/validation-libraries/ にある、プロジェクトの package.json に一致するバリデーションライブラリのガイド（zod.md / valibot.md / arktype.md）
   • ../kamae/result-libraries/ にある、プロジェクトの package.json に一致する Result ライブラリのガイド（neverthrow.md / byethrow.md / fp-ts.md / option-t.md）
   • 読み込んだチェックリストのサブファイルで参照されている、../kamae/ 配下の各トピックファイル

2. レビュー対象のファイルを読みます。

3. チェックリストを確認します。 チェックリストの各サブファイルを順に読み、指摘事項を項目に照らし合わせます。

   • checklist/domain-modeling.md — 判別可能なユニオン、コンパニオンオブジェクト、Branded Types、ファイル構成、ドメイン所有のポート、単一操作ごとに分けたリゾルバー／ストア（項目 1.x）
   • checklist/state-transitions.md — 純粋な状態遷移、網羅性（項目 2.x）
   • checklist/error-handling.md — Result 型、エラー境界の分類、DU エラー型（項目 3.x）
   • checklist/boundary.md — スキーマ検証、as アサーションの禁止、スキーマから導出される型（項目 4.1、4.2、4.4）
   • checklist/pii-protection.md — PII に対する Sensitive<T>（項目 4.3）
   • checklist/declarative-and-tests.md — 配列操作、イベント、フィクスチャ（項目 5.x、6.x）

4. 指摘事項を報告します。 違反ごとに、以下を示します。

   1. 場所（path:line）。
   2. 問題である理由 — 原則を引用（../kamae/... へのリンク）し、違反によるリスクを説明します。
   3. 修正方法 — 修正後のコード例を示します。

5. 提案（違反ではないものの改善の余地がある項目）も、指摘事項ではなく提案として示し、同じ形式で伝えます。

重大度の分類

各チェックリスト項目には、High／Medium／Low のいずれかが付けられています。

• High — 実行時エラーまたはコンプライアンス違反の直接的な原因（as、PII 保護の欠如、スキーマ検証の欠如、意味的に異なるプリミティブに対する Branded Types の欠如）。
• Medium — 無効な状態表現、一貫性のないエラー処理、網羅性の欠如、すべてを含む型ファイル、ドメインモデルにクラスを使用、ドメインコントラクトがインフラストラクチャ型に結合している状態。
• Low — スタイル、可読性、エッジケースの正確性に関する問題（メソッド記法、ドメイン型での interface の使用、Readonly<> の欠如、kind 以外の判別子、命令型の配列ループ、as const satisfies を使わないフィクスチャ、スキーマと型の重複、外向きの依存関係がない場所へのポート配置、必要以上に広範な依存コントラクト）。既存のスキーマと型の不一致は、誤った受け入れ、拒否、またはデータ露出による影響に基づいて指摘します。

Example Finding

### Use of method notation

`src/domain/task/task-store.ts:15`

`save(task: Task): Promise<void>` uses method notation. Per
[`../kamae/SKILL.md` §1 "Use function property notation"](../kamae/SKILL.md),
parameters become bivariant under method notation, so a narrower implementation
such as `save(task: DoingTask): Promise<void>` will pass type checking at the
injection site.

Suggested fix:
\`\`\`typescript
type TaskStore = {
  save: (task: Task) => Promise<void>;
};
\`\`\`