本文へスキップ
ai-memory
EnglishPortuguês (Brasil)Españolעברית日本語한국어
メニュー

プロダクト

ソリューション

連携

開発者

言語

はじめるGitHub

開発者

ai-memoryにコントリビュートする

これまでに101人のコードが取り込まれています。このページは、アイデアから適切なIssue、適切なクレート、一度でレビューを通るプルリクエストまでを案内します。

参加方法を選ぶCONTRIBUTING.mdを読む

数字で見る、活発なプロジェクト

件数は、このサイトのビルド時にGitHub APIから取得しています。

7,660
GitHubスター
101
コントリビューター
486
マージ済みプルリクエスト
272
クローズ済みIssue

上位のコントリビューター

GitHubで101人のコントリビューター全員を見る

参加方法を選ぶ

どれも、GitHubの該当ページに直接つながります。

バグを報告する

テンプレートでは、バージョン、OS、エージェント、トランスポート、関連するサーバーログの行を尋ねます。

バグ報告を作成

機能を提案する

提案はIssueで行います。このリポジトリにDiscussionsはありません。テンプレートでは、どんな問題を解決するのか、既存のインストールを壊すかどうかを尋ねます。

機能リクエストを作成

最初のIssueを見つける

good first issueラベルは、初めての人に向いた作業に付いています。それ以外にはhelp wantedが付いています。

good first issueを見る

ハーネスを追加または修正する

マネージドハーネスの対応には、文書化されたプロトコルがあります。ネイティブのセッション契約を証明すること、ストアは読み取り専用で読むこと、コンテキストは受領を確定する前に届けること、必須のテストを同梱することです。

ハーネスのプロトコルを読む

ドキュメントを改善する

ガイドはdocs/にmarkdownで置かれています。ドキュメントの修正は通常のプルリクエストで、ユーザーに見える変更がなければ変更履歴への追記は不要です。

docs/を見る

周辺ツールを作る

インポーター、よりリッチなUI、チャットのフロントエンドは、公開されているHTTPとMCPのインターフェースを使うコンパニオンプロジェクトとして作ります。

コンパニオンのルールを読む
図：コントリビューションは6つの段階を進む。Issue、ブランチ、ローカルチェック、プルリクエスト、レビューを経て、次のリリースで出荷される。
アイデアからリリースまで。修正は次のパッチで、追加型の機能は次のマイナーで出荷されます。

ビルドできる状態にする

ビルドは自己完結しています。以下のコマンドに環境変数が必要なものはありません。

  1. クローンしてビルドする

    Rust 1.95が必須で、rustfmtとclippyとともにrust-toolchain.tomlで固定されているので、初回ビルド時にrustupが正しいツールチェーンをインストールします。SQLiteは同梱、libgit2はベンダリング済みです。必要なのは標準的なCツールチェーンだけです。

    開発環境のセットアップ
    git clone https://github.com/akitaonrails/ai-memory
cd ai-memory
cargo build --workspace
cargo test --workspace --all-targets

  2. 日常のループを回す

    cargo tにはnextestが必要です：cargo install cargo-nextest --locked。slowやstressという名前のモジュールはスキップされますが、pre-pushフックとCIでは実行されます。

    作業中に
    cargo t                        # slow層以外すべて、ウォーム状態で約20秒
cargo t -p ai-memory-store     # クレート1つ：そのテストバイナリだけをビルド
cargo t -E 'test(/purge/)'     # トピック1つ（すべてビルドし、一部を実行）

  3. pre-pushフックをインストールする

    クローンごとに1回です。.git/hooks/pre-pushの中の自分のブロックにしか触れません。作業途中のブランチでは、git push --no-verifyでスキップできます。

    クローンごとに1回
    scripts/install-git-hooks.sh

  4. pushする前にチェックを通す

    CIは5つすべてを強制します。nextestがない場合、cargo test --workspace --all-targetsがcargo tfに相当します。最後のチェック用のツールがなければ：cargo install cargo-deny cargo-audit。

    必須チェック
    cargo fmt --all -- --check
git diff --check
cargo clippy --workspace --all-targets -- -D warnings
cargo tf                            # 全テスト（エイリアス：cargo nextest run -P full）
cargo deny check                    # 依存関係のポリシー

  5. コミットの作者情報を確認する

    GitHubアカウントで検証済みのメールアドレスか、noreplyアドレスを使ってください。作者情報を直すためにmainの履歴を書き換えることはありません。

    コミットの作者情報
    git log --format='%h %an <%ae>' "$(git merge-base HEAD origin/main)"..HEAD

基本ルールと受け入れ基準

AGENTS.mdは、人にもコーディングエージェントにも適用される正式なルールファイルです。CONTRIBUTING.mdはそれを次のように要約しています。

作業を取り込むための前提

  • 変更履歴はマージの条件

    ユーザーに見える変更はすべて、同じプルリクエストの中で[Unreleased]にエントリを追加します。レビュアーは、エントリがなければマージをブロックします。リファクタリングとテストだけの変更は対象外です。

  • 「完了」の前にテスト

    作業はテストが付いて初めて完了と見なされます。特にパーサー、IDの導出、保持期間の計算が対象です。

  • デッドコードも作りかけの機能も入れない

    スタブは、それを完成させるマイルストーンとともにモジュールコメントに記載します。

  • 変更の範囲を守る

    現在のマイルストーンに必要のないコードはリファクタリングしないでください。

  • コメントは理由を説明する

    直前の行を言い直すだけのコメントは削除されます。

プルリクエストが破ってはならない不変条件

  • SQLiteへの書き込みはすべて、単一のライターアクターWriterHandleを通します。
  • 設定は起動時に1回だけ読み込みます。Config::loadの外でstd::env::varを使ってはいけません。
  • ファイルの書き込みはアトミックです。tmp、rename、fsyncの順で行い、その場での上書きはしません。
  • wikiページはすべて(workspace_id, project_id)で名前空間が分かれています。
  • CLIは薄いHTTPクライアントです。SQLiteファイルやwikiディレクトリを開くことはありません。

全リストと、それぞれが防ぐバグはAGENTS.mdにあります

コードベースの地図

バイナリには10個のクレートが入っています。それぞれが1つの責務と型付きのAPIを持ち、循環依存はありません。

図：4層に分かれたクレート。最上段はcliクレート。その下にhooks、mcp、web、consolidate、workstream。さらに下にstore、wiki、llm。すべての土台がcoreクレート。
クレート名はai-memory-プレフィックスを省いています。すべてがcoreに依存し、すべてに依存するのはcliクレートだけです。
クレート中身
ai-memory-coreドメイン型、エラー、ID。IOなし。
ai-memory-storeSQLite、ライターアクター、リーダープール、減衰の計算。
ai-memory-wikimarkdownのアトミックな書き込み、ファイルウォッチャー、git。
ai-memory-mcpMCPトランスポート、ツールルーター、管理用ルート。
ai-memory-hooksフックペイロードのスキーマ、サニタイザー、/hookエンドポイント。
ai-memory-llmプロバイダー認証の境界と、LLMおよびembedderのトレイト。
ai-memory-consolidate取り込み、lint、スイープ、自動改善のパイプライン。
ai-memory-web読み取り専用の/webブラウザと、/api/v1のJSONルート。
ai-memory-workstream読み取り専用のネイティブトランスクリプトリーダーと、ai-memory runの裏にある起動アダプター。
ai-memory-cliai-memoryバイナリと、その薄いHTTPサブコマンド。

crates/の外

ディレクトリ中身
companions/ai-memory-importer。ルートのワークスペース外にあるスタンドアロンのパッケージです。--manifest-pathを付けてビルドします。
hooks/ライフサイクルフックのバンドル。エージェントごとに1フォルダで、シェル版とネイティブ版があります。
evals/ベンチマークのハーネス。ワークスペースのメンバーですが、出荷はされません。
docs/アーキテクチャ、設計上の決定、インストール、デプロイ、利用のガイド。
tests/エンドツーエンドのスモークテスト、フックのシェルテスト、フィクスチャ。

統合テストは各クレート内のtests/suite/にあります。クレート間で共有するヘルパーはcrates/ai-memory-test-supportに置き、これは出荷されません。

プルリクエストのレビューの進み方

レビューはプルリクエストのテンプレートに沿って行われるので、テンプレートを正直に埋めることが作業の大半です。

  • テンプレートがチェックリスト

    何を変えたか、なぜ変えたか、チェック項目に印を付けたテスト計画、コミットの作者情報、リリースへの影響、変更履歴のエントリを尋ねます。

  • リリースの種類を明記する

    パッチ、マイナー、メジャーのいずれかに印を付けます。修正を「Added」に入れると誤ったバージョンが上がることがあるので、変更履歴のエントリは正しい見出しの下に置いてください。

  • 破壊的変更はメジャーを待つ

    説明文で明示してください。breaking-changeラベルが付いてスケジュールに組み込まれるので、パッチやマイナーのリリースを止めることはありません。

  • マージごとのCIは速い

    マージの条件になるのは、速いLinuxのジョブです。macOSとWindowsのジョブは、ラベル指定、夜間、または手動で実行され、リリース前には必ず実行されます。

  • 修正が先に出荷される

    バグ修正は次のパッチリリースで出荷され、機能開発のために保留されることはありません。新しいハーネスやプロバイダーは次のマイナーで出荷されます。

ハーネスのプルリクエストでは、この短縮版のチェックを実行し、テスト対象にしたCLIのバージョンを記録し、実際のハーネスに対する手動の確認を含めます。

managed-harness-contributions.mdより
cargo fmt --check
git diff --check
cargo test --workspace
cargo clippy --workspace --all-targets -- -D warnings

続けて読む

変更する前に、まず使ってみてください。

自分のプロジェクトで1日動かしてみてください。そこで見つけたバグが、あなたの最初のIssueです。

今すぐインストールGitHubでスターする