> ## Documentation Index
> Fetch the complete documentation index at: https://koharu.rs/llms.txt
> Use this file to discover all available pages before exploring further.

# Koharu への貢献

> プロジェクトがレビューと保守を続けられる、範囲の明確な変更を準備します。

バグ修正、ドキュメント、翻訳、モデル移植の修正、焦点を絞った機能改善を歓迎します。[初めての貢献向け issue](https://github.com/koharu-rs/koharu/contribute)、既存の [issue](https://github.com/koharu-rs/koharu/issues) と PR を確認し、[Discord](https://discord.gg/mHvHkxGnUY)で範囲を相談できます。

<Steps>
  <Step title="問題と範囲を合わせる">
    小さな修正やドキュメント変更は通常そのまま提出できます。新機能、大きな UI 変更、モデル、プロバイダー、プラットフォーム連携、依存関係、公開 API、スキーマ、構造の変更は、実装前に issue で方向を相談してください。issue、動く実装、方向への合意があっても採用を保証するものではありません。
  </Step>

  <Step title="担当するコンポーネントに従う">
    該当 crate の README とリポジトリ規則を読みます。API やスキーマを変える場合は全利用箇所を更新し、互換エイリアスを追加しません。プロバイダー既定値はその実装に置き、安全な API を unsafe FFI や動的ロードから分離します。

    モデル移植ではチェックポイントに影響する構造を保ち、同じ入力の構造化出力を比較します。コメントは所有関係、不変条件、上流対応、意図した差異を説明します。
  </Step>

  <Step title="変更を確認する">
    diff 全体を読み、最小限の debug チェックか対象テストを一度実行し、整形して `git diff --check` を行います。

    UI にはスクリーンショット、性能変更にはデバイス・入力・基準・結果・正しさ、モデル移植には構造化比較を添えます。実行できなかったチェックも明記します。
  </Step>

  <Step title="焦点を絞った PR を作る">
    問題、解決方法、重要な挙動や所有関係の変化、検証を説明します。無関係なリファクタリングを避け、修正に対応し、不明な指摘は質問してください。
  </Step>
</Steps>

資格情報、モデルの重み、データセット、生成物、ビルド成果物、端末固有ファイルはコミットしません。

## 提案の判断基準

製品の方向性、利用者への価値と広さ、UX、構造、性能、安全性、プライバシー、OS 対応、テスト、ドキュメント、依存関係、運用の複雑さを検討します。

提案の見送り、延期、縮小、再設計、コア外での実装を提案することがあります。マージ後はプロジェクトが保守を担うため、貢献者が参加できなくなっても継続可能である必要があります。

## AI を使った貢献

人間の貢献者が提出物の著者であり責任者である必要があります。設計や実装への大きな AI 支援は、範囲と目的を開示してください。通常の補完、文法修正、翻訳に詳しい開示は不要です。

提出前に diff 全体を自分で確認し、生成された主張をコードで検証し、報告した問題を再現し、変更と境界ケースを理解して修正できるようにします。他の貢献と同じ検証と証拠が必要です。

<Warning>
  自律的・未確認の
  issue、PR、レビューコメント、セキュリティ報告は提出しないでください。生成出力は下書きとして扱い、説明と応答は自分の理解に基づいて書きます。
</Warning>

未確認に見えるもの、推測や捏造を含むもの、説明や修正ができないもの、価値に比べレビュー負担が大きすぎるものは、詳細レビューなしで閉じる場合があります。不明な場合は相談してください。

続いて[開発環境](/ja/development/setup)を準備します。