貢献コード

実装を見つける

まずは行動を変えることから始めましょう。デスクトップアクションについては、次のとおりです apps/desktop/src/app/routes.tsx ページアダプターと機能画面に移動します。クライアントまたは機能ヘルパーでリクエストを見つけます。エンドポイント スキーマは packages/apiのハンドラー apps/sidecar/src/http、およびその下のサービスまたはリポジトリ。

ジオメトリまたは NC 出力の変更の場合は、次の手順から始めてください。 packages/core およびそれに隣接するテスト。永続性の問題については、リポジトリ クエリを検査し、 packages/db/src/schema.ts。ネイティブのライフサイクル、ファイル ダイアログ、キーチェーン、またはアップデーターの動作については、検査してください。 apps/desktop/src-tauri/src。これにより、変更が実際の責任に近い状態に保たれます。

ワークスペースの責任

利用可能な場合は、モジュールのパブリック エントリ ポイントを使用します。コア ジオメトリやクライアントから SQLite アクセスを遮断します。機能画面では、サイドカー認証をバイパスしたり、サーバー資格情報を埋め込んだりしないでください。横断的な変更では、影響を受ける各境界を明示的に更新する必要があります。

共有契約を意図的に変更する

1. コントラクト パッケージでリクエスト、レスポンス、および型付きエラーのスキーマを定義します。
2. ハンドラーとそのサービス/リポジトリの動作 (所有権チェックを含む) を実装します。
3. クライアントを再生成し、生成された出力が最新であることを確認します。
4. 変更されたサーフェスを使用するデスクトップ、コンパニオン、プラグイン、または外部クライアント コンシューマを更新します。
5. サポートされている入力、出力、障害動作、および動作制限を文書化します。

bun run generate
bun run generate:check
bun run --filter @cadcamfun/api typecheck
bun run --filter @cadcamfun/sidecar typecheck

生成されたクライアントは、コントラクト ジェネレーターの出力です。コントラクトまたはジェネレーターの形状が間違っている場合は修正します。生成された出力に対する手書きの修正は、再生成時に失われます。既存のクライアント セマンティクスを維持するか、意図的な API 変更による互換性への影響を特定します。

実装規約

コード、コメント、ドキュメントは英語で記述してください。エクスポートされた TypeScript インターフェイスを明示的に保ち、使用します unknown さらに、信頼できない値のスキーマ検証も行います。相対 TypeScript インポートは使用します .ts 拡張子。 CAD 距離にはミリメートルが使用され、描画角度にはラジアンが使用されます。明示的に次数値の特徴と CAM ロータリー入力を尊重します。ポスト境界で NC 番号をフォーマットします。

エフェクト コードは、固定バージョンのサービス/レイヤー/エラー API を使用します。サービスは外部依存関係を所有します。スコープ付きレイヤーは独自のリソースを持ちます。ドメイン モジュール内に非表示のプロセス構成読み取りを追加しないでください。ジオメトリ計算を純粋に保ち、ファイルシステム、ネットワーク、データベースの操作をアダプターの背後に分離します。

スキーマを変更する場合は、変更します schema.ts、移行を生成し、既存のデータベースの新規作成とアップグレードの両方を実行します。 UI を変更する場合は、ルート アダプターを小さく保ち、対話ロジックを関連する機能に配置します。ネイティブ作業の場合は、ジオメトリとリポジトリ ロジックを Rust に移動するのではなく、サイドカー/コアに保持します。

レビュー前の検証

• 影響を受けるパッケージのタイプチェックと、変更された動作についての意味のあるテストを実行します。
• バグ修正の場合は、失敗した状態とその修正結果を示します。
• 共有コントラクトについては、生成されたクライアントと影響を受けるコンシューマを確認してください。
• 永続性を確保するには、分離されたデータベースを使用して移行動作とデータの整合性を検証します。
• ネイティブまたはレンダリングされたインタラクションの場合は、ロジック テストに加えて実際のターゲット ランタイムを実行します。
• ユーザー/開発者のドキュメントを更新し、残っている運用上の制限について説明します。

ルートチェックは、 bun run typecheck そして bun run test。 CI には Rust とコンパニオン固有のジョブもあります。実行内容と障害、または利用できないランタイム カバレッジを報告します。構成されたワークフローと正常な実行を区別します。

変更をレビュー可能な状態に保つ

生成されたアーティファクト、依存関係の更新、動作の変更、ドキュメントの変更を、同じ具体的な目的に追跡できるようにします。無関係なモジュールを再フォーマットしないでください。既存のユーザーの作業を保存し、実験には使い捨てのデータ ディレクトリを使用します。

パッチやスクリーンショットには、起動トークン、デバイス ペアリング リンク、モデル キー、データベース コンテンツ、または署名資格情報を含めないでください。例ではプレースホルダーを使用する必要があります。ローカル フィクスチャまたはモックされたプロバイダーは、決定的なフローを検証できます。実際のプロバイダーまたはネイティブ統合が引き続き必要な場合は、文書化してください。

便利なチェック

bun run --filter @cadcamfun/core typecheck
bun test packages/core
bun test apps/sidecar/test
bun test apps/desktop/src
bun run --cwd apps/mobile typecheck
bun run --cwd apps/mobile test
bun run --cwd packages/web check
bun run --cwd packages/web build

ネイティブパッケージの用途 scripts/build.ts;使用 --help または --dry-run その段階を検査します。単体テストは、ビルド パイプラインの型チェック ステージとは別のものです。署名、ターゲット アーキテクチャ、およびアップデータの検証については、リリース ガイドを参照してください。

例: プロジェクトの変更の検証

プロジェクトの作成/更新ルールが変更されたとします。リクエストのスキーマは packages/api/src/projects.ts、HTTP アダプターは apps/sidecar/src/http/projects.ts、永続性は次のように実装されます。 ProjectRepo。現在のスキーマは name オプションですが、ハンドラーは作成と更新にこれを必要とします。スキーマが有効なリクエストが成功することを保証する前に、両方のレベルを検査してください。

1. 対象となる入力ケースを定義します: 名前の欠落、無効なタイプ、空のテキスト、アクセス可能な組織、およびアクセスできない組織。
2. どの状態がデコードエラーで、どの状態がビジネス検証であるかを決定します。エンドポイントの文書化されたステータス/エラーの形式を保持します。
3. 関連するハンドラー/サービス境界にアサーションを追加し、未承認または非メンバーの呼び出し元がルールをバイパスできないことを確認します。
4. パブリック スキーマが変更された場合は、クライアント ファミリとタイプチェック コンシューマの両方を再生成します。
5. デスクトップ フォームを実行し、変更されたリクエスト要件を文書化します。

現在、作成では HTTP 201 を使用して裸のプロジェクト行が返されます。リレーションが強化された行をリスト/取得して返します。契約と消費者を更新せずに、このファミリーに一般的な成功の枠を課さないでください。他のエンドポイント ファミリは意図的に異なるエンベロープを使用します。

ジェネレーターのエントリーポイントは packages/api/scripts/generate-clients.ts。その出力は以下に存在します src/client/generated そして src/sdk/generated。契約内容への変更はソース契約に属します。生成された出力は再現可能である必要があります。

適切な深さの回帰を選択する

ジオメトリ回帰では、変更された計算を繰り返すだけでなく、ジオメトリをアサートする必要があります。既存の衝突テストは有用なパターンを提供します。定常的なオーバーラップは時間 0 での衝突です。中間の回転スイープは、エンドポイントが明確な場合でも衝突する可能性があります。不十分な境界は未解決です。そして、認定されたクリアランスが密な独立した参照と比較されます。

bun test packages/core/src/cam/kernel/collision.test.ts
bun run --filter @cadcamfun/core typecheck
bun test packages/core

他の作業にも同様の境界を選択してください。データベースの移行には、フレッシュ/アップグレードのケースとバックアップの失敗時の動作が必要です。ストリームパーサーにはフレームの分割とキャンセルが必要です。 UI の変更の保存には、宛先の選択、リクエストの失敗、再試行、および保存された状態の再オープンが必要です。ネイティブ コマンドには、フロントエンドの型チェックに加えて、検証とライフサイクル動作が必要です。

変化に比例してチェックを続けます。コンテンツの編集にはナビゲーション/テンプレートの検証が必要です。新しいドメイン テストを考案する必要はありません。合格した狭いテストでは、アサートされた動作のみがサポートされるため、変更されたパブリック サーフェスに必要なパッケージまたは統合チェックが含まれます。

ドキュメントの提供

ウェブサイトは次のとおりです packages/web。ドキュメントページで使用されるもの DocsLayout、目次、セクション識別子、および共有コード/吹き出し/関連リンク コンポーネント。コンテンツを改善しながら、これらのページ規則と既存のビジュアル デザインを維持します。

1. 文書化するすべての動作の実装、マニフェスト、構成を読みます。
2. サポートされているコマンドまたはリクエスト シェイプを使用し、必要な作業ディレクトリ、資格情報、データ パス、およびネイティブの前提条件を指定します。
3. 結果とその故障モードを説明します。例に例としてラベルを付けます。実際にキャプチャされた場合にのみ、キャプチャされた応答を呼び出します。
4. ルートを追加または名前変更するときにナビゲーションと取得のメタデータを更新し、古い場所へのすべてのローカル リンクを修正します。
5. インデックス チェックと Astro ビルドを実行し、レンダリングされたページとそのアンカーを検査します。

bun run --cwd packages/web check
bun run --cwd packages/web typecheck
bun run --cwd packages/web build

構成された CI に関する主張には、ワークフローが何を行うかを示す必要があります。出版の成功または実行時の承認についての主張には、証拠として特定の実行/成果物が必要です。ドキュメントでは、社内の計画メモを製品の指示に変えることなく、実装された動作、デフォルト、および制限を区別する必要があります。

プルリクエストのチェックリスト

• bun run typecheck 根元を通過します。
• bun run test 合格します。新しい動作にはコードの横にテストがあります。
• 契約の変更は次のように再生成されます。 bun run generate:check そして bun run --filter @cadcamfun/web check きれいです。
• スキーマの変更には、生成された移行フォルダーが含まれますが、適用された移行の編集ではありません。
• Rust 変更パス cargo clippy そして cargo test (CI は両方を実行します)。
• ユーザーに表示される動作は、それを説明するドキュメント ページに反映されます。

CI はプッシュごとに同じコマンドを実行するため、グリーン ローカル実行はグリーン プル リクエストの最良の予測子となります。

3Dで