Effect

Use Effect throughout the application code covered by the task. A Promise application wrapped in one Effect is incomplete adoption.

The verified reference snapshot is effect@4.0.0 (first stable v4 release, npm latest, LTS). Check installed versions before changing dependencies. Do not mix v3 and v4 APIs. Projects still on 4.0.0-rc.* / beta.* must apply the RC → 4.0 upgrade in migration.md (import paths and several renames changed).

Required adoption policy

• Keep use cases, service methods, I/O, expected failures, resource ownership, and concurrent work inside Effect.
• Choose the matching Effect capability before writing a custom helper or adding an overlapping library. Consult the index below.
• Use Effect Schema for application-owned validation and codecs; Context and Layer for dependencies; Scope for cleanup.
• Use Effect scheduling, concurrency, state, configuration, and observability instead of parallel custom systems for the same responsibility.
• Keep Promise, callback, framework, and vendor APIs at named adapters. Convert once on entry and once on exit.
• Existing Elysia routes may return Promises. Their handlers delegate to Effect use cases; business logic stays outside handlers.
• Never call a runtime runner inside a domain service to make Effect look like a Promise API.
• Keep pure calculations and ordinary TypeScript data simple. They need no Effect wrapper unless they fail or perform effects.
• Prefer Effect's standard library over new duplicate utilities. Do not mechanically replace clear language operators or native data structures.
• Respect the requested scope. Convert each touched use case end to end; do not start an unrelated repository-wide migration.
• Record remaining non-Effect boundaries and their concrete constraints. Convenience alone does not justify a second application architecture.