code-craft

コードの作法

型で証明できることは型で証明し、型では証明できないことだけをテストします。不変条件はそれぞれ、実際に証明できる証明の階段の最も強い段に担当させます。順番は、型とリンター、エフェクト、証明、データベース制約、単体テスト、統合テスト、エンドツーエンドテストです。

リポジトリの現在の指示と、確立された規約に従ってください。依頼された変更で設計上の判断が必要な場合は、以下の既定値を適用します。これらは、無関係な再構成や新しいツールの導入を認めるものではありません。

対象となる判断の参考資料を読んでください。

判断	参考資料
不変条件をどの段に担当させるか決める	証明の階段
状態、ワークフロー、ドメインの識別子を表現する	不正な状態
外部入力を有用な型にデコードする	検証ではなく解析
依存関係、失敗、リソースのライフタイムを型付けする	エフェクト
回復可能なエラーと必須のゲートをモデル化する	値としてのエラー
機密性の高い前提条件を保護する	証明パラメーター
抽象化を選ぶ、またはパフォーマンスを調査する	シンプルさ
モジュール境界とそのドキュメントを維持する	アーキテクチャドキュメント

言語特有の慣用表現、並行処理、またはツールの詳細が重要な場合に限り、言語別の参考資料を読んでください：TypeScript、Rust、Go、Python。

新しいTypeScriptコードとプロジェクト全体のテンプレートでは、JessのスタックはEffect、Effect SchemaまたはZod、xstate、gdp-tsです。新しいRustサーバーでは、tokio、axum、snafu、aerosol、sqlxです。既存のリポジトリでは、そのリポジトリに相当するものを使用してください。これらを追加する場合は、まずアーキテクチャ変更について相談してください。

スキーマ、制約、クエリ、ジョブにはdatabase-craftを、テストの各段にはtesting-craftを使用してください。リポジトリのセットアップを依頼された場合、そのセットアップはproject-bootstrapの対象です。プロジェクトで必須とされている検証に従ってください。レビューのたびにテストスイート全体を実行する必要はありません。

leonardomso/rust-skills（MIT）、MatkladのRust100kシリーズ、解析と型安全性に関するAlexis Kingの著作、Matt NoonanのGhosts of Departed Proofsを参考にしています。