AGENTS.md git:20260320.f8c7064A

Immutable. This exact content never changes and is served at /api/v1/blob/3c140ee8269047e0.

# AGENTS

- Premature Optimization is the Root of All Evil
- 一切忖度しないこと
- 常に日本語を利用すること
- 全角と半角の間には半角スペースを入れること
- 絵文字を使わないこと

## レビューについて

- レビューはかなり厳しくすること
- レビューの表現は、シンプルにすること
- レビューの表現は、日本語で行うこと
- レビューの表現は、指摘内容を明確にすること
- レビューの表現は、指摘内容を具体的にすること
- レビューの表現は、指摘内容を優先順位をつけること
- レビューの表現は、指摘内容を優先順位をつけて、重要なものから順に記載すること
- ドキュメントは別に書いているので、ドキュメトに付いては考慮しないこと
- 変更点とリリースノートの整合性を確認すること

## コミットについて

- 勝手にコミットしないこと
- コミットメッセージは確認すること
- コミットメッセージは日本語で書くこと
- コミットメッセージは命令形で書くこと
- コミットメッセージは〜するという形で書くこと

## カットオフ

- rustc 1.94.0
- rust edition 2024

## カバレッジ

- PBT のみで取得すること
  - 単体テストは作らないこと
- 90% 以上を目指すこと
- バグを見つけることを目的とすること
- テストで問題を回避しないこと
- llvm-cov を利用すること

## サンプルについて

- サンプルは **お手本** なので性能と堅牢性を両立させること
- サンプルは RFC に準拠していること

## テストについて

- pbt 以下に unittest を書かないこと
- unittest は pbt で実現できないものだけを書くこと

## CHANGES の記載方法について

- 同一バージョンのリリース内では、同じカテゴリ（ UPDATE / ADD / CHANGE / FIX）のエントリー同士は連続して配置するようにする
  - OK:
    - [UPDATE] 更新 1
    - [UPDATE] 更新 2
    - [ADD] 追加 1
    - [CHANGE] 変更 1
    - [CHANGE] 変更 2
    - [FIX] 修正 1
  - NG:
    - [UPDATE] 更新 1
    - [ADD] 追加 1
    - [CHANGE] 変更 1
    - [UPDATE] 更新 2  # <- 連続していない
    - [FIX] 修正 1
    - [CHANGE] 変更 2  # <- 連続していない
- それぞれのカテゴリの配置順番は CHANGES.md の冒頭の「# 変更履歴」セクションの記載順に合わせることとする
- `### misc` サブセクションが存在する場合には、その中のエントリー群についても（misc の外側のエントリー群からは独立して）上記のカテゴリ連続配置ルールを適用するものとする

## Rust

- 入力バイナリデータをデコードする際には `Vec::with_capacity()` などのメモリを事前に割り当てるメソッドを原則として使用しないこと
  - 入力データが破損している場合などに、サイズやカウントを示す値のデコード結果が極端に大きくなり、メモリを大量に消費してしまうリスクがあるため
  - このケースでも `Vec::new()` を使っておけば、メモリ消費量のオーダーは実際の入力データのサイズから大きく乖離することはない
  - なお、性能がきわめて重要な箇所でもなければ、現実的には `Vec::with_capacity()` と `Vec::new()` の性能差は誤差程度という認識（そのため、基本的に後者を使っていればいい）
- lint 警告を抑制する必要がある時は `#[allow(...)]` ではなく `#`[expect(...)]` を使う
  - allow では、その lint 項目がなくなったり、コードの修正によって不要になった時に気づけないため
- `.unwrap()` ではなく `.expect("MESSAGE")` を使用する
  - `.unwrap()` では情報が少ない
  - `.expect("MESSAGE")` を使用して、最低限「このパニックが状況によっては発生する可能性がある」のか、それとも「絶対に発生しない想定（発生した場合は実装バグ）」なのかがメッセージから分かるようにすること
- 性能より堅牢性を優先すること
- PBT(Property-Based Testing) や Fuzzing で必ずテストを行うこと