effect-ts

Effect 4

プロジェクト内のアーキテクチャ、該当範囲が最も狭いリファレンス、および対象にインストールされているパッケージに一致するソースに基づいて、Effect 4 のセマンティクスを適用します。

ワークフロー

ファイルが effect をインポートしているという理由だけで、このワークフローを開始しないでください。複雑な Effect の作業では、次の手順に従ってください。

1. 対象のパッケージまたはワークスペースと、そこにインストールされている正確な effect および関連する @effect/* のバージョンを特定します。effect が 4.x でない場合は、このスキルの対象外のため中止します。3.x の場合は、ユーザーに v3 スキルを案内します。 npx skills add PaulRBerg/agent-skills#shelved --skill effect-ts-v3
2. バージョンがそろっていることを確認します。すべての @effect/* パッケージは、インストールされている effect と完全に同じバージョンでなければなりません。コードで回避せず、不一致を報告してください。
3. 近隣のサービス、レイヤー、エラー、スキーマ、ランタイム境界、テストを調べます。構成はローカルの規約に従い、API の事実はインストール済みパッケージの根拠に基づいて判断します。
4. references/critical-rules.md を読み、続いて以下のタスク固有のリファレンスのみを読みます。
5. 編集前に、不確かなインポート、シグネチャ、動作のすべてを、対象ワークスペースから参照できるパッケージのインストール内容と照合します。記憶を頼りに v3 の名前を持ち込まないでください。多くの名前は変更または削除されています。
6. プロジェクトに合った最小限のパターンを実装し、変更したセマンティクスをカバーする最も限定的なテストまたは型チェックを実行します。

根拠の優先順位

対象ワークスペースのマニフェストとロックファイルでバージョンを特定します。次の順に優先してください。

1. インストール済みパッケージの src/、README、テスト、変更履歴。
2. ソースが同梱されていない場合は、生成済みの宣言ファイル。
3. 対応する公式パッケージのアーティファクトまたはソースタグ。

モノレポのソース、テスト、パッケージ横断検索には、scripts/effect-source.sh を実行します。このスクリプトは、Effect-TS/effect のクローンをキャッシュし、最新リリースにチェックアウトします。取得は最長でも 24 時間に 1 回で、それ以外はキャッシュを再利用し、path= と release= を出力します。release がインストール済みの effect のバージョンと異なる場合は、チェックアウトせずに一致するタグを読みます。例：git -C <path> grep <pattern> effect@<version> -- packages/ または git -C <path> show effect@<version>:<file>。キャッシュは編集しないでください。

ドキュメントを取得することだけを目的に、依存関係をインストールまたは更新しないでください。v3 の例や、対象にインストールされているバージョンと一致しないソースを信用しないでください。正確な動作を確認できない場合は、推測せず中止してください。

以前は @effect/platform、@effect/rpc、@effect/cli、@effect/cluster などにあったモジュールは、現在 effect/http、effect/http-api、effect/rpc、effect/cli、effect/ai、effect/sql、effect/schema、effect/reactivity、effect/workflow などのサブパスから effect に含まれています。正確なサブパス一覧は、インストール済みパッケージの package.json にある exports で確認してください。これらのモジュールには @stability unstable と記載されており、マイナーリリースで破壊的変更が発生する可能性があります。effect/unstable/* の互換パスはありません。プラットフォーム、ドライバー、プロバイダーについては、@effect/platform-*、@effect/sql-*、@effect/ai-*、@effect/atom-*、@effect/opentelemetry、@effect/vitest の個別パッケージが引き続き使われます。これらのモジュールにも @stability unstable と記載されています。

4.0.2 以降、すべてのモジュールと直接インポート可能なエクスポートに @stability が宣言されています。API に依存する前にタグを確認してください。stable は厳密なセマンティック バージョニングに従います。effect/graphql や effect/net の一部などの experimental モジュールは、パッチリリースで破壊的変更が発生する可能性があります。Arbitrary、Crypto、FileSystem、Path など、ルートモジュールの一部も unstable です。

リファレンス案内

タスク	リファレンス
Services、Layers、Context.Service、fn	references/services-layers.md
Config プロバイダーとシークレット	references/config.md
Schema、JSON Schema、エンコードされたエラー／モデル	references/schema-jsonschema.md
@effect/vitest、クロック、ファイバー、リトライ	references/testing.md
リソース、スケジューリング、参照、並行処理	references/runtime.md
ストリームとバックプレッシャー	references/streams.md
パターンマッチングとタグ付きユニオン	references/pattern-matching.md
effect/ai と @effect/ai-*	references/ai.md
effect/sql と @effect/sql-*	references/sql.md
Next.js / @prb/effect-next	references/next-js.md
Effect Atom（effect/reactivity、@effect/atom-*）	references/effect-atom.md
null 許容の境界での Option	references/option-null.md

effect/http、effect/http-api、effect/rpc、effect/cli、コレクションユーティリティ、非推奨項目、コンストラクターの 検索については、ローカルの API 一覧を読み込むのではなく、インストール済みパッケージのソースを直接確認してください。

境界

• Effect の境界によって具体的な依存関係、テスト容易性、リソース安全性、またはエラーモデル上のメリットが得られる場合を除き、純粋なヘルパー、定数、パス操作は純粋なままにしてください。
• ユーザーが再設計を求めていない限り、既存のドメインファサードとサービス／ランタイムの境界を維持してください。
• IO の境界では、型付きの失敗とスコープ付きリソースを優先してください。Schema に基づくエラー／モデルを選ぶのは、エンコードや境界での検証が必要な場合に限ります。
• 小規模なプラットフォーム呼び出しを置き換えるためだけに、環境要件を拡大しないでください。

変更作業では、ローカルの Effect アーキテクチャ、選択したリファレンス、および必要に応じて確認したインストール済みソースに沿ったコードにする必要があります。また、変更したセマンティクスを実行する、最小範囲のテスト／型チェックを完了してください。読み取り専用の作業では、報告する結論を裏付ける根拠が必要です。検証済みの編集を行った場合は ### ⚡ Effect — ✅ change complete、読み取り専用の作業の場合は ### ⚡ Effect — 🔎 reviewed, no files written で締めくくり、使用した境界またはパターンを示す一文と、正確な対象範囲のコマンド／結果を記した ### 🧪 Verification を含めてください。必要な検証が未完了の場合は、代わりに ### ⚡ Effect — ⛔ blocked を使用してください。ブロッキングではない注意事項がある場合に限り、### ⚠️ Limitation を追加してください。型付きエラー、Schema メッセージ、ログ、テスト、生成された JSON／API レスポンス、コマンド出力には、決して装飾を加えないでください。