@danieljvdm/dev-kit 0.11.3 → 0.13.0

package/skills/effect-architecture-audit/references/service-and-boundary-audit.md

@@ -0,0 +1,150 @@
+# Service And Boundary Audit
+
+## Contents
+
+- [Establish authority](#establish-authority)
+- [Build the inventory](#build-the-inventory)
+- [Trace requirements](#trace-requirements)
+- [Classify candidates](#classify-candidates)
+- [Audit type boundaries](#audit-type-boundaries)
+- [Audit test substitutes](#audit-test-substitutes)
+- [Report findings](#report-findings)
+
+## Establish authority
+
+Read the repository's architecture guidance and version-matched Effect package
+instructions. Treat installed declarations and source as the authority for API
+signatures. Record local conventions that affect service ownership, adapter
+placement, error translation, and testing.
+
+## Build the inventory
+
+Find every:
+
+- Effect service, tag, Layer, constructor, and provisioning call.
+- Service-shaped interface, class, dependency bag, registry, or callback.
+- Direct use of time, randomness, IDs, configuration, credentials, HTTP,
+  persistence, filesystems, runtime bindings, or mutable globals.
+- Test Layer, fake, in-memory implementation, and module mock.
+- Public Effect with an `unknown` or overly broad error channel.
+- `any`, assertion, non-null assertion, custom predicate, structural probe,
+  unvalidated JSON parse, Promise rejection mapper, and expected throw.
+- Schema or codec that overlaps another representation of the same logical
+  model.
+
+Record one row per service or candidate:
+
+| Field        | Question                                             |
+| ------------ | ---------------------------------------------------- |
+| Owner        | Which module owns the capability's meaning?          |
+| Contract     | Where is its public contract defined?                |
+| Construction | Are all construction requirements visible?           |
+| Production   | Who chooses the concrete implementation?             |
+| Consumers    | Is the capability yielded or drilled as a value?     |
+| Boundary     | Who owns decoding, narrowing, and error translation? |
+| Tests        | Is its substitute strategy intentional and honest?   |
+| Verdict      | Keep, deepen, relocate, merge, remove, or create?    |
+
+Complete the inventory when each discovered capability and unsafe boundary
+appears exactly once.
+
+## Trace requirements
+
+For each row:
+
+1. Trace one caller-visible operation through every effect it performs.
+2. Mark where each dependency first appears and whether code yields, passes,
+   captures, or concretely provides it.
+3. Verify that the module selecting a concrete Layer owns that implementation
+   choice.
+4. Follow every Layer requirement to a composition root or an explicit value
+   boundary.
+5. Check version-matched Effect capabilities before recommending an
+   application wrapper.
+
+Flag hidden requirements created by inner provisioning, dependency bags,
+handler-builder service values, mutable registries, or Layer selection inside
+business operations. Prefer provision at a program or subsystem edge. Avoid
+thin exported helpers that only yield a service and forward one method.
+
+## Classify candidates
+
+Assign one evidence-backed classification:
+
+- **Built-in Effect capability** — yield the existing capability directly.
+- **Application-owned authority** — define a narrow port beside the operation
+  whose policy gives it meaning.
+- **Technology adapter** — implement an application-owned port at the external
+  boundary.
+- **Request or domain value** — keep deterministic, per-call data explicit.
+- **Framework boundary** — contain framework-required state or assertions in
+  the adapter or composition root.
+- **Pass-through abstraction** — fold it into the actual owner.
+
+Apply the deletion test: if removing an abstraction leaves equally clear code
+without spreading authority, resource ownership, or policy, remove it. Prefer
+an existing owner or a merge over a generic registry.
+
+## Audit type boundaries
+
+Assign every `unknown` value a boundary owner.
+
+- Reserve `unknown` for external input, foreign library output, and opaque
+  diagnostic causes.
+- Decode structured external data once, at the earliest boundary that owns its
+  meaning.
+- Pass decoded values and concrete error unions through internal services.
+- Keep unavoidable framework assertions at the narrowest adapter and document
+  the contract they bridge.
+- Remove runtime narrowing already guaranteed by the inferred type.
+- Preserve irreducible foreign causes as diagnostic fields inside concrete
+  domain errors instead of broadening public error channels.
+
+Prefer one source Schema per logical model. Use Schema transformations or
+derived variants when a storage or transport representation differs without
+changing the model's meaning. Create a separate Schema only for a real semantic
+difference.
+
+Keep a helper only when it owns domain policy, reusable refinement, repeated
+non-trivial mechanics, or a meaningful observability boundary. Inline one-use
+tag comparisons and structural checks that add no meaning.
+
+## Audit test substitutes
+
+Record the intended test strategy for every production service.
+
+- Make a shared test Layer's name match the behavior it fully provides.
+- Keep partial fixtures local instead of publishing them as general in-memory
+  implementations.
+- Use a real local adapter when persistence, transactions, serialization, or
+  lifecycle behavior is the subject under test.
+- Keep timing deterministic; never add wall-clock sleeps to stabilize a test.
+- Test protocol round trips when encoding or decoding behavior is a durable,
+  regression-prone public seam.
+
+An explicit production-only rationale is valid when a substitute would not
+protect durable behavior.
+
+## Report findings
+
+Prioritize findings by impact:
+
+- **P0** — hidden authority, unsafe runtime access, wrong implementation
+  ownership, unchecked external data, or expected failures escaping the typed
+  channel.
+- **P1** — dependency drilling, hidden Layer requirements, duplicated
+  capabilities, manual shape discovery, unjustified assertions, pass-through
+  abstractions, or dishonest test substitutes.
+- **P2** — naming and co-location cleanup that belongs with a nearby change.
+
+For each finding, include:
+
+1. File, line, or symbol evidence.
+2. The hidden requirement or caller burden.
+3. The smallest target shape and its owner.
+4. Composition-root and testing impact.
+5. Behavior and modules that must remain unchanged.
+
+End with explicit keep decisions for pure functions, request values, framework
+boundaries, correctly separated ports and adapters, and services whose
+requirements already remain visible.

package/skills/effect-ts/SKILL.md

@@ -1,270 +1,35 @@
 ---
 name: effect-ts
-description: Use this skill whenever working in a repository that uses Effect, even if the current task is in a new file or the user does not explicitly ask for Effect help. Apply it to Effect patterns, services, layers, schemas, streams, runtimes, typed errors, DateTime, Effect Atom, observability, testing, HTTP, SQL, command-line scripts, project automation, and supporting tooling.
+description: Use this skill when setting up a repository that uses the Effect Typescript library.
 ---
 
-# Effect Expert
+# Step 1: Install effect
 
-Expert guidance for programming with the Effect library, covering error handling, dependency injection, composability, and testing patterns.
+Use the users preferred package manager:
 
-## Version Baseline
+```
+pnpm add effect@beta
+```
 
-This skill targets Effect v4. The guidance was last reviewed against
-`effect@4.0.0-beta.102` and the matching `@effect/*` v4 packages.
+If in a monorepo, install it as a dev dependency at the root, so you can access
+the source code from `node_modules/effect/src`.
 
-Before changing code, determine the version installed by the target repository.
-The target repository's manifest and lockfile are authoritative. Do not migrate
-or upgrade it merely to match this review baseline.
+```
+pnpm add -D effect@beta
+```
 
-Read `./references/version-and-source.md` before installing packages, resolving
-version-sensitive APIs, or using upstream source as evidence.
+# Step 2: Update AGENTS.md / CLAUDE.md
 
-## Research Strategy
+Ensure that the agent instructions contain the following:
 
-Effect has many ways to accomplish the same task. Proactively research best practices when working with Effect patterns, especially for moderate to high complexity tasks.
+```md
+# Learning more about the Effect
 
-Use the local guides in `./references/` first. They are the preferred source for best practices, conventions, and common implementation patterns.
+This repository uses the Effect Typescript library.
 
-Only go directly to the canonical Effect source when:
+Before writing any Effect code, first read `node_modules/effect/AGENTS.md`
+**completely**, and follow the links in the file when required.
 
-- the guides do not cover the question
-- you need exact API details or signatures
-- you need deeper implementation details
-- you need to verify a behavior against the source
-
-### Research Sources
-
-1. Local skill guides first. Start with the relevant files in `./references/`
-   before doing deeper research.
-2. Codebase patterns second. Examine similar patterns in the current project
-   before implementing. If Effect patterns already exist, follow them for
-   consistency unless they conflict with an explicit local policy in this
-   skill.
-3. Installed package source third. Use the target repository's resolved
-   `effect` and `@effect/*` packages for exact exports, declarations, and API
-   signatures.
-4. Version-matched upstream source last. For gaps in the guides, complex type
-   errors, unclear behavior, or implementation details, inspect the canonical
-   `Effect-TS/effect` source at the tag or commit matching the installed
-   version. A project-local source checkout is optional, never a prerequisite.
-
-### When To Research
-
-- Always research for services, layers, or complex dependency injection.
-- Always research for error handling with multiple error types or complex error hierarchies.
-- Always research for stream-based operations and reactive patterns.
-- Always research for resource management with scoped effects and cleanup.
-- Always research for concurrent or performance-critical code.
-- Always research for unfamiliar testing patterns.
-- Research when needed for complex refactors from promises or try/catch into Effect.
-- Research when needed for new service dependencies or layer restructuring.
-- Research when needed for custom error types or extensions of existing error hierarchies.
-- Research when needed for integrations with external systems such as databases, APIs, or third-party services.
-
-### Research Approach
-
-- Focus on canonical, readable, and maintainable solutions rather than clever optimizations.
-- Verify suggested approaches against existing codebase patterns when those
-  patterns exist.
-- When multiple approaches are possible, prefer the most idiomatic Effect
-  solution supported by the codebase, these local policies, and version-matched
-  Effect source.
-
-### Codebase Pattern Discovery
-
-When working in a project that uses Effect, check for existing patterns before implementing new code:
-
-1. Search for Effect imports and existing module usage to understand current conventions.
-2. Identify how services and layers are structured in the project.
-3. Note how errors are defined and propagated.
-4. Examine how Effect code is tested in the project.
-
-If no Effect patterns exist in the codebase, proceed using these guides and
-canonical patterns from version-matched Effect source and examples. Do not
-block on missing codebase patterns or a missing source checkout.
-
-### Feature Discovery
-
-When you need to discover available Effect modules, packages, or capabilities, search `./references/features.md` first.
-
-- Use it to identify the right package or module for a task.
-- Treat listed repo paths as discovery hints. Confirm them against the target
-  repository's installed version before relying on exact names or signatures.
-- Use it before inventing custom abstractions when Effect may already provide the functionality.
-
-### Guide Discovery
-
-When the task touches one of these areas, consult the matching guide before implementing:
-
-- `./references/guide-effect.md` for core `Effect` usage patterns, common constructors, composition, provisioning, and runtime boundaries
-- `./references/guide-error-handling.md` for defining errors, schema-based errors, failure handling, defects, and interrupts
-- `./references/guide-layers.md` for service ownership, service design, layer
-  construction, dependency visibility, composition, and provisioning
-- `./references/guide-observability.md` for `Effect.fn`, spans, structured
-  logging, metrics, annotations, and telemetry wiring
-- `./references/guide-retries.md` for retry policies, retry conditions, fallback strategies, and `ExecutionPlan`
-- `./references/guide-schedule.md` for retries, repeats, backoff, polling, cron, and schedule composition
-- `./references/guide-schema.md` for schema-first application modeling,
-  service contracts, transformations, unions, recursion, and branded types
-- `./references/guide-datetime.md` for current time, parsing, UTC and zoned
-  values, time zones, DST-safe arithmetic, formatting, Date interoperability,
-  and deterministic `TestClock` tests
-- `./references/guide-atom-data-fetching.md` for the core Effect Atom HTTP
-  data-fetching workflow, React hook choice, and action-lifetime ownership rules
-- `./references/atom-cache-lifecycle.md` for Effect Atom registry scope,
-  runtime memoization, families, TTL, SWR, polling, and aggregation resets
-- `./references/atom-http-and-invalidation.md` for `AtomHttpApi.Service`,
-  queries, mutations, reactivity keys, and invalidation
-- `./references/atom-tanstack-start.md` only for TanStack Start provider
-  placement, SSR isolation, hydration, and focus guidance
-- `./references/atom-testing.md` when adding or diagnosing deterministic Effect
-  Atom lifecycle tests
-- `./references/guide-sql.md` for Effect SQL usage, transactions, resolvers, schema-aware SQL, and migrations
-- `./references/guide-testing.md` for `@effect/vitest`, deterministic testing,
-  honest test Layers, property tests, and protocol round trips
-- `./references/guide-cli.md` for Effect-powered command-line scripts and
-  project automation
-- `./references/guide-http-boundaries.md` for `HttpApi` contracts, handlers,
-  DTOs, transport errors, and route boundaries
-- `./references/audit-services.md` for a complete service and type-boundary
-  audit workflow
-- `./references/guide-type-safety-and-boundaries.md` for `unknown`, assertions,
-  runtime shape checks, external decoding, and boundary ownership
-
-Treat each topic guide as the single authority for that topic. Do not skip the
-guides and jump straight to source unless source-level confirmation is needed
-or the guides do not answer the question.
-
-## Effect Principles
-
-Apply these core principles when writing Effect code.
-
-## Installation
-
-When installing Effect v4 packages in a user repository:
-
-- use the current `effect@beta` version only for a new v4 installation
-- preserve the repository's resolved v4 beta for existing installations unless
-  the user asks for an upgrade
-- keep `effect` and all v4 `@effect/*` packages on the exact same beta version
-- install only the packages needed for the user's runtime and actual task
-
-### Version Rules
-
-- `effect@latest` is still the v3 release line; use `effect@beta` when creating
-  a new v4 repository.
-- Resolve the beta tag at installation time. Do not assume the review baseline
-  is still current.
-- If you install any v4 `@effect/*` package, make sure it and `effect` use the
-  same exact beta version.
-- Do not mix v3 integration packages with Effect v4 packages.
-
-### Package Selection
-
-Choose packages based on the runtime and the work being done.
-
-- core library: `effect@beta`
-- Node.js runtime needs: install the matching `@effect/platform-node@beta`
-- browser runtime needs: install the matching `@effect/platform-browser@beta`
-- Bun runtime needs: install the matching `@effect/platform-bun@beta`
-- Vitest integration needs: install the matching `@effect/vitest@beta`
-- OpenTelemetry integration needs: install the matching
-  `@effect/opentelemetry@beta`
-
-Install additional `@effect/*` packages only when the user task actually needs them.
-
-### Practical Rule
-
-- start with the current resolved `effect@beta`
-- add matching v4 `@effect/*` packages only as needed by runtime and features
-- pin the full installed Effect v4 package set to the same exact beta
-
-### Error Handling
-
-- Use Effect's typed error system instead of throwing exceptions.
-- Define descriptive error types with proper error propagation.
-- Prefer `Schema.TaggedErrorClass` when the error can be schema-defined.
-- Use `Effect.fail`, `Effect.catchTag`, and `Effect.catch` for error control flow.
-
-### Dependency Injection
-
-- Implement dependency injection using services and layers.
-- Define services with `Context.Service`.
-- Compose layers with `Layer.merge` and `Layer.provide`.
-- Use `Effect.provide` to inject dependencies at the edge, avoid providing locally.
-- Keep services encapsulated; avoid exporting trivial accessor wrappers that only forward to one service method.
-
-### Composability
-
-- Leverage Effect composability for complex operations.
-- Use appropriate constructors such as `Effect.succeed`, `Effect.fail`, `Effect.tryPromise`, `Effect.try`, and `Effect.sync`.
-- Apply proper resource management with scoped effects.
-- Chain operations with `Effect.flatMap`, `Effect.map`, and `Effect.tap`.
-
-### Business Logic Functions
-
-- Prefer `Effect.fn` for reusable business-logic functions that return `Effect`.
-- Prefer `Effect.fn` over raw `Effect.gen` definitions even when the function takes no arguments.
-- If you do not want an explicit named span, use `Effect.fn` without a span name.
-- Do not use `Effect.fnUntraced` as the default.
-- Use `Effect.fnUntraced` only for edge cases with a concrete low-level reason, such as measured hot-path overhead.
-
-### TypeScript Preferences
-
-- Do not use `any` in Effect application, service, or workflow code.
-- Decode external values instead of asserting their shape.
-- Isolate unavoidable compiler or framework adapter assertions at the
-  narrowest boundary and document the contract they bridge.
-- Do not use `namespace` to hide services, layers, or mutable state.
-- Prefer correct typing, schema-driven decoding, narrowing, and proper generic constraints instead of forcing types.
-- If a value comes from an external boundary, validate or decode it instead of asserting its type.
-- If a type is hard to express, simplify the design or introduce a properly typed helper instead of using unsafe TypeScript.
-- For layers, do not hide them inside `namespace` blocks. Prefer either `static` members on the service class or plain exported layer constants.
-
-### Date and Time
-
-- Prefer Effect `DateTime` over vanilla JavaScript `Date` for application
-  logic. Keep `Date` as an interoperability type at external boundaries.
-- Use `DateTime.now` inside Effect programs so current time remains driven by
-  the `Clock` service and deterministic under `TestClock`.
-- Preserve the distinction between instants, zoned wall-clock values, and
-  date-only domain values.
-
-### Code Quality
-
-- Write type-safe code that leverages Effect's type system.
-- Use `Effect.gen` for readable sequential code.
-- Implement proper testing patterns using Effect testing utilities.
-- Prefer existing Effect primitives before introducing custom helpers.
-- Prefer `Schema.Class` / `Schema.TaggedClass` variants over plain `Schema.Struct` for named reusable schemas when possible.
-
-### Explaining Solutions
-
-When providing solutions, explain the Effect concepts being used and why they
-fit the specific use case. If you encounter patterns not covered in local
-references, prefer consistency with the codebase when possible and otherwise
-rely on installed declarations and version-matched canonical Effect source.
-
-## References
-
-- `./references/features.md`
-- `./references/guide-effect.md`
-- `./references/guide-error-handling.md`
-- `./references/guide-layers.md`
-- `./references/guide-observability.md`
-- `./references/guide-retries.md`
-- `./references/guide-schedule.md`
-- `./references/guide-schema.md`
-- `./references/guide-datetime.md`
-- `./references/guide-atom-data-fetching.md`
-- `./references/atom-cache-lifecycle.md`
-- `./references/atom-http-and-invalidation.md`
-- `./references/atom-tanstack-start.md`
-- `./references/atom-testing.md`
-- `./references/guide-sql.md`
-- `./references/guide-testing.md`
-- `./references/guide-cli.md`
-- `./references/guide-http-boundaries.md`
-- `./references/audit-services.md`
-- `./references/guide-type-safety-and-boundaries.md`
-- `./references/version-and-source.md`
+If you need to learn more about particular Effect apis and concepts that the
+guide doesn't cover, search through the source code in `node_modules/effect/src`.
+```

package/skills/effect-ts/agents/openai.yaml

@@ -1,4 +1,4 @@
 interface:
-  display_name: "Effect Expert"
-  short_description: "Apply current Effect v4 patterns and tooling"
-  default_prompt: "Use $effect-ts to apply the relevant Effect architecture, DateTime, Atom, schema, service, error, testing, HTTP, SQL, observability, or CLI guidance."
+  display_name: "Effect TypeScript Setup"
+  short_description: "Set up version-matched Effect guidance"
+  default_prompt: "Use $effect-ts to set up Effect and its package-bundled agent guidance."

package/skills/testing/SKILL.md

@@ -21,3 +21,8 @@ Write a test only when every condition holds:
 If any condition fails, skip the test and use the cheapest sufficient verification instead. Moving MVP behavior often warrants no committed tests.
 
 Test capabilities, not files. Use the fewest tests that protect the risk, and ignore coverage targets unless the user explicitly asks for them.
+
+Never commit an intentionally failing or red-only suite. Keep time-driven tests
+deterministic instead of stabilizing them with wall-clock sleeps. A shared fake
+or in-memory implementation must fully provide the behavior its name promises;
+keep partial substitutes local to the tests that need them.

package/src/catalog-manager.ts

@@ -36,10 +36,9 @@ export type CatalogAddOptions = CatalogCommandOptions & {
   readonly dryRun?: boolean;
 };
 
-class CatalogManagerError extends Schema.TaggedErrorClass<CatalogManagerError>()(
-  "CatalogManagerError",
-  { message: Schema.String },
-) {}
+class CatalogManagerError extends Schema.TaggedError<CatalogManagerError>()("CatalogManagerError", {
+  message: Schema.String,
+}) {}
 
 const formattingOptions = { insertSpaces: true, tabSize: 2 } as const;
 
@@ -63,17 +62,17 @@ const readJsonc = Effect.fn("readCatalogManagerJsonc")(function* <A>(
   const fs = yield* FileSystem.FileSystem;
 
   if (!(yield* fs.exists(filePath))) {
-    return yield* new CatalogManagerError({ message: `file not found: ${filePath}` });
+    return yield* CatalogManagerError.make({ message: `file not found: ${filePath}` });
   }
   const raw = yield* fs.readFileString(filePath);
   const errors: Array<ParseError> = [];
   const parsed = parseJsonc(raw, errors, { allowTrailingComma: true });
 
   if (errors.length > 0) {
-    return yield* new CatalogManagerError({ message: `could not parse ${filePath}` });
+    return yield* CatalogManagerError.make({ message: `could not parse ${filePath}` });
   }
   const value = yield* Schema.decodeUnknownEffect(schema)(parsed).pipe(
-    Effect.mapError((error) => new CatalogManagerError({ message: error.message })),
+    Effect.mapError((error) => CatalogManagerError.make({ message: error.message })),
   );
 
   return { raw, value };
@@ -105,7 +104,7 @@ const selectSkills = Effect.fn("selectCatalogSkills")(function* (
   const unknown = requested.filter((skill) => !available.has(skill));
 
   if (unknown.length > 0) {
-    return yield* new CatalogManagerError({
+    return yield* CatalogManagerError.make({
       message: `repository does not contain: ${unknown.join(", ")}`,
     });
   }
@@ -117,7 +116,7 @@ const selectSkills = Effect.fn("selectCatalogSkills")(function* (
   if (requested.length > 0)
     return { include: [...new Set(requested)], selected: [...new Set(requested)] };
   if (!(yield* isInteractiveTerminal)) {
-    return yield* new CatalogManagerError({
+    return yield* CatalogManagerError.make({
       message: "choose skills with --skill <name>, or pass --all",
     });
   }
@@ -194,7 +193,7 @@ export const addCatalogSource = Effect.fn("addCatalogSource")(function* (
   options: CatalogAddOptions,
 ) {
   if (options.all && (options.skills?.length ?? 0) > 0) {
-    return yield* new CatalogManagerError({ message: "use either --all or --skill, not both" });
+    return yield* CatalogManagerError.make({ message: "use either --all or --skill, not both" });
   }
   const state = yield* readState(options);
   const inspection = yield* inspectCatalogRepository({
@@ -210,12 +209,12 @@ export const addCatalogSource = Effect.fn("addCatalogSource")(function* (
   const byRepository = sources.findIndex((source) => source.repository === inspection.repository);
 
   if (byId >= 0 && sources[byId]?.repository !== inspection.repository) {
-    return yield* new CatalogManagerError({
+    return yield* CatalogManagerError.make({
       message: `source id ${inspection.id} is already used by ${sources[byId]?.repository}`,
     });
   }
   if (byRepository >= 0 && sources[byRepository]?.id !== inspection.id) {
-    return yield* new CatalogManagerError({
+    return yield* CatalogManagerError.make({
       message: `repository is already cataloged as ${sources[byRepository]?.id}`,
     });
   }
@@ -226,7 +225,7 @@ export const addCatalogSource = Effect.fn("addCatalogSource")(function* (
     const existing = sources[existingIndex];
 
     if (existing === undefined) {
-      return yield* new CatalogManagerError({ message: "catalog source index is out of bounds" });
+      return yield* CatalogManagerError.make({ message: "catalog source index is out of bounds" });
     }
     const approved =
       state.lock?.value.sources.find((source) => source.id === existing.id)?.skills ?? [];
@@ -308,12 +307,12 @@ export const removeCatalogEntry = Effect.fn("removeCatalogEntry")(function* (
     const owner = state.lock?.value.sources.find((source) => source.skills.includes(name));
 
     if (!owner)
-      return yield* new CatalogManagerError({ message: `catalog entry not found: ${name}` });
+      return yield* CatalogManagerError.make({ message: `catalog entry not found: ${name}` });
     const index = sources.findIndex((source) => source.id === owner.id);
     const source = sources[index];
 
     if (!source)
-      return yield* new CatalogManagerError({ message: `source not found: ${owner.id}` });
+      return yield* CatalogManagerError.make({ message: `source not found: ${owner.id}` });
     if (source.include.includes("*")) {
       const exclude = [...new Set([...(source.exclude ?? []), name])];
 
@@ -342,7 +341,7 @@ export const removeCatalogEntry = Effect.fn("removeCatalogEntry")(function* (
   }
   if (!options.yes) {
     if (!(yield* isInteractiveTerminal)) {
-      return yield* new CatalogManagerError({
+      return yield* CatalogManagerError.make({
         message: "catalog removal requires --yes outside a terminal",
       });
     }
@@ -388,7 +387,7 @@ export const showCatalogSource = Effect.fn("showCatalogSource")(function* (
   const source = state.sources.value.sources.find((candidate) => candidate.id === id);
 
   if (!source)
-    return yield* new CatalogManagerError({ message: `catalog source not found: ${id}` });
+    return yield* CatalogManagerError.make({ message: `catalog source not found: ${id}` });
   const locked = state.lock?.value.sources.find((candidate) => candidate.id === id);
 
   yield* printLine(source.id);