貢献

このセクションは、Neat Library 自体を変更するコントリビューター向けです。リポジトリの構造、変更のビルドとテストの方法、およびアプリケーション開発者が維持する必要がある契約について説明します。

貢献者向けオリエンテーション

このリポジトリにある Neat Library は、C++/Pythonライブラリとランタイムです。 モデルアーカイブをロードし、パイプラインを構成および検証し、Modalix ハードウェア上で実行し、パブリックなアプリケーションAPIを公開します。Neat SDK と DevKit Sync は、それらを取り巻く開発ワークフローです。

このリポジトリを変更する際には、人間とエージェントによる開発の両方を支援する、フレームワークの特性を最適化してください。具体的には、明確なAPI、決定的な動作、構造化された診断、厳格な検証、および安定したパブリックコントラクトです。

貢献者向けガイドライン

• 決定性こそが重要 — 要素名、生成されたパイプライン、レポート、およびテストを再現可能に保つ。
• デバッグの容易性を最優先 — 失敗時には、文字列だけでなく、構造化されたデータを出力する。
• 無言のフォールバックは行わない — モデル入力のバグやハードウェア/ランタイムの障害を隠蔽しない。
• 実行前に検証する — 構造、上限、形状、および契約に関するエラーをランタイム前に検出する。
• 公開 API は安定性を維持する — include/* にインストールされたヘッダーには、追加的で互換性のある変更のみを適用する。
• 並行処理は制限され、監視可能でなければならない — クリーンアップ処理がハングアップせず、診断がスレッドセーフでなければならない。

ここから始めましょう。

コードを変更する前に、リポジトリ、命名規則、および期待される動作について理解しておいてください。

• アーキテクチャリポジトリの構造、モジュールの所有権、ランタイムのフロー、および拡張ポイントについて学びましょう。
• 契約書の名称一貫して、標準化された製品名、API名、パッケージ名、および型名を使用してください。
• コーディング規約C++のスタイル、公開API、互換性、およびドキュメントに関する規定に従ってください。

構築とテスト

フレームワークを構築し、変更を検証し、Pythonバインディングの作業を行います。

• 構築するソースコードから Neat をビルドし、CMake プロファイルまたはビルドオプションを選択します。
• テスト要件各変更の種類に対して、どのようなテストとドキュメントの更新が必要になるかを把握しておきましょう。
• Pythonバインディングコントリビューターとして、PyNeat のバインディングを構築、テスト、パッケージ化します。

契約と内部構造

モデルアーカイブ、プラグインコントラクト、または内部パッケージを変更する際にこれらを使用してください。

• MPK契約モデルアーカイブの取り込み、検証、およびセキュリティルールを理解してください。
• プラグイン JSON 真偽マップフリーズされた SIMA プラグインの JSON 契約マップを確認してください。
• AppComplex パッケージゲート付きのアプリケーション複合ワークスペースサービスパッケージを構築およびインストールします。

リリースとメンテナンス

これらは、リリース時のチェックポイント、クリーンアップ計画、および長期にわたる設計指針として使用してください。

• リリースチェックリストリリースを妨げる条件、必要な確認事項、および再現可能な手順に従ってください。
• エラー分類の展開構造化されたエラーコードの移行と検証の状況を追跡します。
• エージェントによるワークフローAPIが、人間とAIによる共同開発を支援するように設計されている理由をご覧ください。