effect

Source excerpt starting at line 1.

1---2name: effect3description: Work with Effect v4 / effect-smol TypeScript code in this repo4---5 6# Effect7 8This codebase uses Effect for typed, composable TypeScript services, schemas, and workflows.9 10## Source Of Truth11 12Use the current Effect v4 / effect-smol source, not memory or older Effect v2/v3 examples.13 141. If `.opencode/references/effect-smol` is missing, clone `https://github.com/Effect-TS/effect-smol` there. Do this in the project, not in the skill folder.152. Search `.opencode/references/effect-smol` for exact APIs, examples, tests, and naming patterns before answering or implementing Effect-specific code.163. Also inspect existing repo code for local house style before introducing new patterns.174. Prefer answers and implementations backed by specific source files or nearby repo examples.18 19## Guidelines20 21- Prefer current Effect v4 APIs and project-local patterns over old blog posts, examples, or package-memory guesses.22- Use `Effect.gen(function* () { ... })` for multi-step workflows.23- Use `Effect.fn("Name")` or `Effect.fnUntraced(...)` for named effects when adding reusable service methods or important workflows.24- Prefer Effect `Schema` for API and domain data shapes. Use branded schemas for IDs and `Schema.TaggedErrorClass` for typed domain errors when modeling new error surfaces.25- Keep HTTP handlers thin: decode input, read request context, call services, and map transport errors. Put business rules in services.26- In Effect service code, prefer Effect-aware platform abstractions and dependencies over ad hoc promises where the surrounding code already does so.27- Keep layer composition explicit. Avoid broad hidden provisioning that makes missing dependencies hard to see.28- In tests, prefer the repo's existing Effect test helpers and live tests for filesystem, git, child process, locks, or timing behavior.29- Do not introduce `any`, non-null assertions, unchecked casts, or older Effect APIs just to satisfy types.30- Do not answer from memory. Verify against `.opencode/references/effect-smol` or nearby code first.31 32## Testing Patterns33 34- Use `testEffect(...)` from `packages/opencode/test/lib/effect.ts` for tests that exercise Effect services, layers, runtime context, scoped resources, or platform integrations.35- Use `it.live(...)` for filesystem, git repositories, HTTP servers, sockets, child processes, locks, real time, and other live platform behavior.36- Run tests from package directories such as `packages/opencode`; never run package tests from the repo root.37- Prefer explicit test layers over ad hoc managed runtimes. Keep dependency provisioning visible in the test file.38- Use scoped fixtures and finalizers for resources that must be cleaned up, including temporary directories, flags, databases, fibers, servers, and global state.39