effect

Effect

このコードベースでは、型付けされた合成可能な TypeScript のサービス、スキーマ、ワークフローに Effect を使用しています。

信頼できる情報源

記憶や古い Effect v2/v3 の例ではなく、現在の Effect v4 のソースを使用してください。

1. .opencode/references/effect が存在しない場合は、https://github.com/Effect-TS/effect をそこにクローンしてください。スキルフォルダーではなく、プロジェクト内で実行してください。
2. Effect 固有のコードについて回答または実装する前に、.opencode/references/effect を検索し、正確な API、例、テスト、命名パターンを確認してください。
3. 新しいパターンを導入する前に、既存のリポジトリコードも調べ、そのプロジェクト固有のスタイルを確認してください。
4. 具体的なソースファイルや近くにあるリポジトリ内の例に基づいた回答や実装を優先してください。

ガイドライン

• 古いブログ記事や例、パッケージに関する記憶に頼った推測よりも、現在の Effect v4 API とプロジェクト固有のパターンを優先してください。
• 複数ステップのワークフローには Effect.gen(function* () { ... }) を使用してください。
• 再利用可能なサービスメソッドや重要なワークフローを追加する際は、名前付きエフェクトに Effect.fn("Name") または Effect.fnUntraced(...) を使用してください。
• API およびドメインデータの形状には Effect Schema を優先してください。新たなエラーの表面をモデル化する場合は、ID にブランド付きスキーマを、型付きドメインエラーに Schema.TaggedErrorClass を使用してください。
• HTTP ハンドラーは薄く保ってください。入力をデコードし、リクエストコンテキストを読み取り、サービスを呼び出し、トランスポートエラーをマッピングします。ビジネスルールはサービスに記述してください。
• Effect のサービスコードでは、周囲のコードですでに使用されている場合、場当たり的な Promise よりも Effect 対応のプラットフォーム抽象化と依存関係を優先してください。
• レイヤーの合成は明示的にしてください。不足している依存関係を見つけにくくする、広範で隠れたプロビジョニングは避けてください。
• テストでは、ファイルシステム、Git、子プロセス、ロック、タイミングの動作に対して、リポジトリ既存の Effect テストヘルパーとライブテストを優先してください。
• 型を満たすためだけに any、非 null アサーション、未チェックのキャスト、古い Effect API を導入しないでください。
• 記憶に頼って回答しないでください。まず .opencode/references/effect または近くのコードで確認してください。

テストのパターン

• Effect サービス、レイヤー、ランタイムコンテキスト、スコープ付きリソース、またはプラットフォーム統合をテストする場合は、packages/core/test/lib/effect.ts の testEffect(...) を使用してください。
• ファイルシステム、Git リポジトリ、HTTP サーバー、ソケット、子プロセス、ロック、実時間、その他のライブなプラットフォーム動作には it.live(...) を使用してください。
• テストは packages/core などのパッケージディレクトリから実行してください。リポジトリのルートからパッケージテストを実行しないでください。
• 場当たり的なマネージドランタイムよりも、明示的なテストレイヤーを優先してください。依存関係のプロビジョニングはテストファイル内で見えるようにしてください。
• 一時ディレクトリ、フラグ、データベース、ファイバー、サーバー、グローバル状態など、クリーンアップが必要なリソースには、スコープ付きフィクスチャーとファイナライザーを使用してください。