@zeix/cause-effect 1.0.0 → 1.0.1

package/skills/cause-effect/references/non-obvious-behaviors.md

@@ -0,0 +1,173 @@
+<overview>
+Counterintuitive behaviors in @zeix/cause-effect that commonly cause bugs or confusion.
+All knowledge is self-contained — no library source files required. Read this when debugging
+unexpected reactive behavior, or when writing code that involves collections, conditional
+reads, async operations, or ownership.
+</overview>
+
+<direct_lookups_do_not_track>
+**`byKey()`, `at()`, `keyAt()`, and `indexOfKey()` do not create graph edges.** They are
+direct lookups into the internal map/array — calling them inside an effect or memo does not
+subscribe to structural changes.
+
+To react to structural changes (key added, key removed, order changed), read a tracking
+accessor instead:
+
+| You want to react to | Read this |
+|---|---|
+| Any structural change | `collection.get()` or `list.get()` |
+| Key set membership | `collection.keys()` |
+| Length / item count | `collection.length` |
+| A specific item's value | `collection.get()` then access the item |
+
+```typescript
+// Wrong — effect does not re-run when keys are added or removed
+createEffect(() => {
+  const item = collection.byKey('id-123')
+  render(item)
+})
+
+// Correct — reading keys() creates a dependency on structural changes
+createEffect(() => {
+  const keys = collection.keys()           // tracks structure
+  const item = collection.byKey('id-123') // safe after establishing the edge
+  render(item)
+})
+```
+</direct_lookups_do_not_track>
+
+<conditional_reads_delay_watched>
+**Conditional signal reads delay `watched` activation.** The `watched` callback on a State
+or Sensor fires when the first downstream effect subscribes. If a signal is only read inside
+a branch that hasn't executed yet, `watched` does not fire until that branch runs.
+
+Read all signals you care about eagerly — before any conditional logic — to ensure `watched`
+fires on the first effect run:
+
+```typescript
+// Bad — `derived` is only read after `task` resolves to `ok`
+// `derived.watched` does not fire until the task has a value
+createEffect(() => {
+  match([task], {
+    ok: ([result]) => render(derived.get(), result),
+    nil: () => showSpinner(),
+  })
+})
+
+// Good — both signals are read on every run, regardless of task state
+// Both `watched` callbacks fire immediately when the effect is created
+createEffect(() => {
+  match([task, derived], {
+    ok: ([result, value]) => render(value, result),
+    nil: () => showSpinner(),
+  })
+})
+```
+
+This also applies to plain `if` / ternary / `&&` patterns — any signal read gated behind a
+condition may not establish its dependency edge until the condition is true.
+</conditional_reads_delay_watched>
+
+<equals_suppresses_subtrees>
+**`equals` suppresses entire downstream subgraphs, not just the node it is set on.** When a
+Memo or State recomputes to a value considered equal to the previous one, all downstream
+nodes skip recomputation entirely without running their callbacks.
+
+This is a powerful optimisation, but it has a non-obvious consequence: a custom `equals` on
+an intermediate Memo can silently prevent large parts of the graph from updating, even if
+upstream sources changed.
+
+```typescript
+const source = createState({ x: 1, y: 2 })
+
+// This memo compares by x only
+const xOnly = createMemo(
+  () => source.get().x,
+  { equals: (a, b) => a === b }
+)
+
+// This effect depends on xOnly.
+// It will NOT re-run if source changes but x stays the same,
+// even if y changed dramatically.
+createEffect(() => {
+  console.log('x is', xOnly.get())
+})
+```
+
+When debugging "why did my effect not re-run", check for custom `equals` on intermediate
+memos in the dependency chain.
+</equals_suppresses_subtrees>
+
+<watched_stable_through_mutations>
+**`watched` stays active through structural mutations.** The `watched` callback on a List or
+Collection source is called once when the first downstream effect subscribes, and `unwatched`
+is called when the last downstream effect unsubscribes. Structural mutations (adding items,
+removing items, updating values) do not call `unwatched` then `watched` again — the callback
+remains active for the lifetime of the subscription.
+
+```typescript
+const list = createList(
+  () => startPolling(),   // watched:   called once when first effect subscribes
+  () => stopPolling(),    // unwatched: called once when last effect unsubscribes
+)
+
+// These mutations do NOT restart the watched/unwatched cycle.
+// The data source stays open as long as at least one effect is subscribed.
+list.push({ id: '1', name: 'Item 1' })  // watched is NOT called again
+list.delete('1')                         // watched is NOT called again
+```
+</watched_stable_through_mutations>
+
+<task_abort_on_dependency_change>
+**A Task's `AbortSignal` is aborted when dependencies change before the async operation
+completes.** If a Task's sources update while the previous `Promise` is still pending, a new
+run is scheduled and the previous `AbortController` is aborted. Not forwarding the signal to
+cancellable async operations will cause stale results to overwrite fresh ones.
+
+```typescript
+// Wrong — fetch is not cancellable; a stale response may arrive after a newer one
+const results = createTask(async () => {
+  return fetch(`/api/search?q=${query.get()}`).then(r => r.json())
+})
+
+// Correct — abort signal forwarded; stale in-flight requests are cancelled
+const results = createTask(async (prev, signal) => {
+  return fetch(`/api/search?q=${query.get()}`, { signal }).then(r => r.json())
+})
+```
+</task_abort_on_dependency_change>
+
+<sensor_unset_before_first_value>
+**Reading a Sensor or Task before it has produced a value throws `UnsetSignalValueError`.**
+Unlike State, these signals have no initial value — they are explicitly "unset" until the
+first value arrives.
+
+Guard against this with `match`, which provides a `nil` branch for the unset case:
+
+```typescript
+const tick = createSensor<number>(set => {
+  const id = setInterval(() => set(Date.now()), 1000)
+  return () => clearInterval(id)
+})
+
+// Wrong — throws UnsetSignalValueError on first run, before the interval fires
+createEffect(() => {
+  console.log(tick.get())
+})
+
+// Correct — match handles the nil (unset) case explicitly
+createEffect(() => {
+  match([tick], {
+    ok:  ([timestamp]) => console.log('tick:', timestamp),
+    nil: () => console.log('waiting for first tick…'),
+  })
+})
+```
+</sensor_unset_before_first_value>
+
+<scope_cleanup_is_synchronous>
+**Scope and Effect cleanup runs synchronously when the returned `Cleanup` function is
+called.** It does not wait for the current flush to complete. Calling cleanup during a batch
+(e.g. inside a `batch` callback) is safe but will immediately dispose the owner and all its
+children.
+</scope_cleanup_is_synchronous>

package/skills/cause-effect/references/signal-types.md

@@ -0,0 +1,288 @@
+<overview>
+What each signal type in @zeix/cause-effect is for, when to use each one, and how to choose between similar types. All knowledge is embedded — no external files required.
+</overview>
+
+<signal_catalog>
+
+<State>
+**What it is:** A mutable reactive value you own and update explicitly.
+
+**Use when:**
+- You control when and how the value changes
+- The value is UI state, form input, a counter, a toggle, a selection
+- You need to write to it directly with `.set()`
+
+**Key facts:**
+- Requires an initial value
+- Synchronous reads and writes
+- Supports `equals` (default `===`) and `guard` options
+
+```typescript
+const count = createState(0)
+count.set(count.get() + 1)
+count.update(n => n + 1)   // if update helper exists; else use set
+```
+</State>
+
+<Sensor>
+**What it is:** A reactive value produced by an external source you don't control.
+
+**Use when:**
+- The value comes from outside the reactive graph: DOM events, timers, WebSocket messages, geolocation, device orientation, IntersectionObserver, etc.
+- You need `watched`/`unwatched` hooks to start and stop the external subscription efficiently
+- The value has no meaningful initial state before the source fires
+
+**Key facts:**
+- Starts **unset** — reading before the first value throws `UnsetSignalValueError`; use `match` to handle the initial state
+- `watched` fires when the first downstream effect subscribes; `unwatched` fires when the last one unsubscribes
+- The setup function receives a `set` callback; return a cleanup function to tear down the subscription
+
+```typescript
+const pointer = createSensor<{ x: number; y: number }>(set => {
+  const handler = (e: PointerEvent) => set({ x: e.clientX, y: e.clientY })
+  window.addEventListener('pointermove', handler)
+  return () => window.removeEventListener('pointermove', handler)
+})
+```
+</Sensor>
+
+<Memo>
+**What it is:** A synchronously derived value that stays in sync with its dependencies.
+
+**Use when:**
+- The value can be computed from other signals without async work
+- You want to avoid recomputing an expensive derivation on every read
+- You need a stable reference: Memo caches the last computed value and only recomputes when dependencies change
+
+**Key facts:**
+- Lazy — only recomputes when read after a dependency has changed
+- Receives `prev` as its first argument (enables referential stability patterns)
+- Supports `equals` to suppress downstream propagation when the new value is equivalent
+
+```typescript
+const fullName = createMemo(() => `${firstName.get()} ${lastName.get()}`)
+```
+</Memo>
+
+<Task>
+**What it is:** An asynchronously derived value — like Memo, but async.
+
+**Use when:**
+- The derivation requires `await` (data fetching, async transforms, indexed DB reads)
+- You want automatic cancellation of in-flight work when dependencies change
+
+**Key facts:**
+- Starts **unset** until the first async operation completes; use `match` for the loading state
+- Receives `(prev, signal: AbortSignal)` — always forward `signal` to `fetch` or any cancellable async operation to prevent stale responses overwriting fresh ones
+- Re-runs automatically when tracked dependencies change, aborting the previous run
+
+```typescript
+const results = createTask(async (prev, signal) => {
+  const res = await fetch(`/api/search?q=${query.get()}`, { signal })
+  return res.json()
+})
+```
+</Task>
+
+<Effect>
+**What it is:** A side effect that runs when its tracked dependencies change.
+
+**Use when:**
+- You need to synchronise reactive state with the outside world: update the DOM, write to localStorage, send analytics, call an imperative library
+- You need a reactive subscription that runs code (not just derives a value)
+
+**Key facts:**
+- **Must be created inside an owner** (`createScope` or another effect) — throws `RequiredOwnerError` otherwise
+- Runs immediately on creation, then re-runs on dependency changes
+- Returns a `Cleanup` function; calling it disposes the effect and all its children
+- Use `unown` inside `connectedCallback` / `disconnectedCallback` when the DOM manages the element's lifetime
+
+```typescript
+const dispose = createScope(() => {
+  createEffect(() => {
+    document.title = pageTitle.get()
+  })
+})
+// later: dispose()
+```
+</Effect>
+
+<Slot>
+**What it is:** A reactive property descriptor — a signal packaged as a getter/setter pair compatible with `Object.defineProperty`.
+
+**Use when:**
+- You need to attach a reactive value as a property on an object (e.g. a Web Component's observed attribute)
+- You want property access (`element.name`) to participate in the reactive graph
+
+**Key facts:**
+- Has `get`, `set`, `configurable`, and `enumerable` fields
+- Can be passed directly to `Object.defineProperty`
+- Backed by a `State` internally
+
+```typescript
+const nameSlot = createSlot(store, 'name')
+Object.defineProperty(element, 'name', nameSlot)
+```
+</Slot>
+
+<Store>
+**What it is:** A reactive object whose properties are individually reactive.
+
+**Use when:**
+- You have a group of related values that are read and updated independently
+- You want fine-grained reactivity on an object's fields rather than replacing the whole object
+
+**Key facts:**
+- Reading a property inside an effect creates a dependency on that property only
+- Updating one property does not re-run effects that only read other properties
+
+```typescript
+const user = createStore({ name: 'Alice', age: 30 })
+user.name = 'Bob'   // only effects reading `user.name` re-run
+```
+</Store>
+
+<List>
+**What it is:** An ordered, keyed reactive collection — an array where each item has a stable identity.
+
+**Use when:**
+- Order matters and items have identity (drag-and-drop lists, ranked results, timelines)
+- You need to react to structural changes (items added, removed, reordered) as well as value changes
+
+**Key facts:**
+- Items are identified by a key; keys must be unique
+- `byKey()`, `at()`, `keyAt()`, and `indexOfKey()` are direct lookups — they **do not create graph edges**
+- To react to structural changes, read `get()`, `keys()`, or `length` instead
+
+```typescript
+const todos = createList<Todo, 'id'>('id', [
+  { id: '1', text: 'Buy milk', done: false },
+])
+todos.push({ id: '2', text: 'Walk dog', done: false })
+```
+</List>
+
+<Collection>
+**What it is:** A keyed reactive collection — a reactive Map.
+
+**Use when:**
+- Items are identified by key and order is not meaningful or variable
+- You need fast key-based lookup with reactive tracking on the key set and individual entries
+- Use cases: entity caches, normalised data stores, lookup tables
+
+**Key facts:**
+- `createCollection` creates a collection from an initial set of entries
+- `deriveCollection` creates a collection derived from another reactive source
+- Same tracking rules as List: `byKey()` does not create graph edges; read `get()`, `keys()`, or `length` to subscribe to structural changes
+
+```typescript
+const users = createCollection<string, User>(
+  existingUsers.map(u => [u.id, u])
+)
+```
+</Collection>
+
+</signal_catalog>
+
+<decision_guide>
+
+<choose_by_value_source>
+**Who controls the value?**
+
+- You set it explicitly → **State**
+- An external event or subscription provides it → **Sensor**
+- It is computed from other signals (sync) → **Memo**
+- It is computed from other signals (async) → **Task**
+</choose_by_value_source>
+
+<choose_by_purpose>
+**What do you need to do with it?**
+
+- Read a derived value without side effects → **Memo** or **Task**
+- Run a side effect when something changes → **Effect**
+- Expose a reactive value as an object property → **Slot**
+- Group related reactive values on an object → **Store**
+- Maintain an ordered list of keyed items → **List**
+- Maintain an unordered map of keyed items → **Collection**
+</choose_by_purpose>
+
+<direct_comparisons>
+
+**State vs Sensor**
+Use `State` when you call `.set()` yourself. Use `Sensor` when an external source calls the setter — the library manages the subscription lifecycle via `watched`/`unwatched`.
+
+**Memo vs Task**
+Use `Memo` for synchronous derivations. Use `Task` when derivation requires `await`. Both receive `prev` and both support `equals`.
+
+**Memo vs Effect**
+`Memo` derives a value (no side effects, lazy). `Effect` runs side effects (imperative, eager, requires owner).
+
+**State vs Store**
+Use `State` for a single primitive or object that is always replaced wholesale. Use `Store` for an object whose individual properties are read and updated independently — Store gives you field-level reactivity.
+
+**List vs Collection**
+Both are keyed. Use `List` when order is significant (rendering order, ranking, sorting). Use `Collection` when items are looked up by key and order is not meaningful.
+
+**List / Collection vs Store**
+Use `Store` for a fixed set of named properties on a single object. Use `List` or `Collection` for a dynamic number of items with uniform shape.
+
+</direct_comparisons>
+
+</decision_guide>
+
+<common_patterns>
+
+<loading_state>
+Sensor and Task start unset. Use `match` to handle all states in one expression:
+
+```typescript
+createEffect(() => {
+  match([task], {
+    ok: ([data]) => renderData(data),
+    err: ([error]) => renderError(error),
+    nil: () => renderSpinner(),
+  })
+})
+```
+</loading_state>
+
+<grouping_effects>
+Always wrap top-level effects in `createScope` to control their lifetime:
+
+```typescript
+const dispose = createScope(() => {
+  createEffect(() => { /* ... */ })
+  createEffect(() => { /* ... */ })
+})
+
+// When done (e.g. component unmounted):
+dispose()
+```
+</grouping_effects>
+
+<coalescing_updates>
+Use `batch` when multiple state writes should trigger only one downstream propagation:
+
+```typescript
+batch(() => {
+  x.set(1)
+  y.set(2)
+  z.set(3)
+  // downstream effects run once, after all three are set
+})
+```
+</coalescing_updates>
+
+<reading_without_subscribing>
+Use `untrack` to read a signal's current value without creating a dependency edge:
+
+```typescript
+createEffect(() => {
+  const primary = primary.get()           // tracked — re-runs when primary changes
+  const snapshot = untrack(() => log.get()) // not tracked — just reads current value
+  console.log(primary, snapshot)
+})
+```
+</reading_without_subscribing>
+
+</common_patterns>

package/skills/cause-effect/workflows/answer-question.md

@@ -0,0 +1,54 @@
+<required_reading>
+Load references based on question type — only what is needed:
+
+- Which signal to use → references/signal-types.md
+- API usage, call signatures, options → references/api-facts.md
+- Unexpected or counterintuitive behavior → references/non-obvious-behaviors.md
+- A thrown error → references/error-classes.md
+- Design rationale or constraints → references/signal-types.md + references/api-facts.md
+</required_reading>
+
+<process>
+## Step 1: Categorise the question
+
+| Category | Signal words | Load |
+|---|---|---|
+| Which signal to use | "should I use", "difference between", "when to use", "State vs", "Memo vs" | signal-types.md |
+| API usage / call signature | "how do I", "what does X return", "what are the options for", "how to create" | api-facts.md |
+| Unexpected behavior | "why does this not work", "is this a bug", "why is watched not firing", "not re-running" | non-obvious-behaviors.md |
+| Error meaning | "what does X error mean", "when is Y thrown", "getting RequiredOwnerError" | error-classes.md |
+| Design rationale | "why was X designed this way", "why no null", "why is T extends {}" | signal-types.md + api-facts.md |
+
+## Step 2: Load only the relevant references
+
+Do not load all references speculatively. Load only the file(s) listed for the identified category.
+
+## Step 3: Answer from embedded knowledge
+
+All knowledge needed to answer public-API questions is in `references/`. Ground every claim in a reference. Cite the section when the answer is non-obvious (e.g. "per `non-obvious-behaviors.md`…").
+
+For counterintuitive behaviors, always show a correct vs incorrect code example alongside the explanation.
+
+## Step 4: When embedded knowledge is insufficient
+
+If the question requires detail beyond what the references cover (e.g. exact internal flag values, propagation algorithm specifics, architecture decisions), do not guess. Instead:
+- Point to the library's README and GUIDE in the npm package or GitHub repository for public API depth
+- Note that library internals are available in `node_modules/@zeix/cause-effect/src/` if truly needed, but internal details are not part of the public API contract and may change
+
+## Step 5: Design rationale questions
+
+When asked why the library was designed a certain way, distinguish between:
+- **Hard constraints** (e.g. `T extends {}` excludes null/undefined by design to guarantee signals always have a value; the signal type set is intentionally minimal and closed to new types)
+- **Soft conventions** (naming patterns, file organisation, option defaults)
+
+If the distinction is unclear from the embedded references, say so rather than speculating.
+</process>
+
+<success_criteria>
+- Answer is grounded in embedded reference knowledge
+- No references to external files that may not exist in the consumer project (REQUIREMENTS.md, ARCHITECTURE.md, src/, etc.)
+- Source cited when the answer is non-obvious
+- Counterintuitive behaviors include correct vs incorrect code examples
+- When knowledge is insufficient, points to upstream documentation rather than guessing
+- No reference files loaded beyond what the question required
+</success_criteria>

package/skills/cause-effect/workflows/debug.md

@@ -0,0 +1,71 @@
+<required_reading>
+1. references/non-obvious-behaviors.md — most reactive bugs are documented here
+2. references/error-classes.md — if a specific error is thrown
+3. references/api-facts.md — to verify the signal is being used correctly
+</required_reading>
+
+<process>
+## Step 1: Categorise the symptom
+
+Match the symptom to the most likely cause before reading any code:
+
+| Symptom | Most likely cause | Where to look |
+|---|---|---|
+| Effect doesn't re-run when a signal changes | No graph edge established (conditional read or direct lookup) | non-obvious-behaviors: `conditional-reads-delay-watched`, `direct-lookups-do-not-track` |
+| Effect re-runs too often | Missing `equals` option, or mutable reference without `SKIP_EQUALITY` | api-facts: `options.equals`, `SKIP_EQUALITY` |
+| `watched` never fires | Signal only read inside a conditional branch | non-obvious-behaviors: `conditional-reads-delay-watched` |
+| Collection/List update not reflected in effect | Using `byKey()`, `at()`, `keyAt()`, or `indexOfKey()` | non-obvious-behaviors: `direct-lookups-do-not-track` |
+| Stale async result overwrites fresh one | `AbortSignal` not forwarded to `fetch` or async operation | non-obvious-behaviors: `task-abort-on-dependency-change` |
+| `UnsetSignalValueError` thrown | Reading Sensor or Task before first value | non-obvious-behaviors: `sensor-unset-before-first-value` |
+| `RequiredOwnerError` thrown | `createEffect` called outside a `createScope` or parent effect | api-facts: `createEffect`, `createScope` |
+| `CircularDependencyError` thrown | A signal depends on itself, directly or transitively | error-classes: `CircularDependencyError` |
+| Downstream Memo or Effect never updates despite source changing | Custom `equals` on an intermediate Memo is suppressing the subgraph | non-obvious-behaviors: `equals-suppresses-subtrees` |
+| Cleanup not running / memory leak suspected | Effect created without an active owner, or `unown` used incorrectly | api-facts: `unown`, `createScope` |
+
+## Step 2: Read the relevant section
+
+Read the specific section in references/non-obvious-behaviors.md or references/error-classes.md that matches the symptom. Compare the pattern shown there to the code in question.
+
+## Step 3: Verify API usage
+
+If the symptom does not match a known gotcha, read references/api-facts.md to confirm:
+- Signal generics use `T extends {}` (no `null` or `undefined`)
+- `createEffect` is inside an owner (`createScope` or another effect)
+- `unown` is used only for DOM-owned lifecycles, not to bypass ownership generally
+- `batch` is used if multiple state writes should coalesce
+
+## Step 4: Inspect library source (last resort)
+
+If the embedded references do not explain the behavior, the library source is available at:
+
+```
+node_modules/@zeix/cause-effect/src/
+```
+
+Read the relevant file there — do **not** assume library source files exist at the project root.
+
+## Step 5: Fix
+
+Apply the minimal change that addresses the root cause. Do not suppress the symptom (e.g. wrapping a read in `untrack`) without first confirming that is the intended behavior.
+
+## Step 6: Verify
+
+Run the project's own test suite:
+
+```bash
+# use whichever applies to this project
+npm test
+pnpm test
+yarn test
+npx vitest
+npx jest
+```
+
+Do not assume `bun` or any specific test runner is available.
+</process>
+
+<success_criteria>
+- Root cause identified, not symptom suppressed
+- Fix matches the correct pattern from references/non-obvious-behaviors.md where applicable
+- Project test suite passes after the fix
+</success_criteria>

package/skills/cause-effect/workflows/use-api.md

@@ -0,0 +1,63 @@
+<required_reading>
+1. references/signal-types.md — choose the right signal type(s) for the task
+2. references/api-facts.md — correct API usage, constraints, and callback patterns
+3. references/non-obvious-behaviors.md — avoid common pitfalls before writing any code
+</required_reading>
+
+<process>
+## Step 1: Choose the right signal type
+
+Read references/signal-types.md. Match the task to the appropriate signal(s) using the decision guide. If multiple signal types seem applicable, the guide has explicit comparisons.
+
+## Step 2: Check ownership requirements
+
+Before writing any `createEffect` call, confirm there is an active owner in scope:
+- Top-level effects must be wrapped in `createScope`
+- Effects in Web Component lifecycle methods that use DOM-managed lifetime should use `unown`
+
+See references/api-facts.md → `<core_functions>` for the rules.
+
+## Step 3: Check for known pitfalls
+
+Skim references/non-obvious-behaviors.md for anything that applies to the task:
+
+| If the task involves… | Check… |
+|---|---|
+| List or Collection | direct-lookups-do-not-track |
+| Conditional rendering or `match` | conditional-reads-delay-watched |
+| Async data fetching | task-abort-on-dependency-change |
+| Sensor or Task before first value | sensor-unset-before-first-value |
+| Multiple state updates at once | references/api-facts.md → `batch` |
+
+## Step 4: Import what you need
+
+All public API is imported from the package root:
+
+```typescript
+import {
+  createState, createSensor, createMemo, createTask,
+  createEffect, createScope, createSlot, createStore,
+  createList, createCollection, deriveCollection,
+  batch, untrack, unown, match,
+  SKIP_EQUALITY,
+} from '@zeix/cause-effect'
+```
+
+Only import what the task requires.
+
+## Step 5: Implement
+
+Write the code following the patterns in references/. Prefer the examples shown there over inventing new patterns — the non-obvious behaviors exist precisely because intuitive patterns are often wrong.
+
+## Step 6: Verify
+
+Run the project's own test suite using whatever command applies to this project (e.g. `npm test`, `pnpm test`, `npx vitest`, `deno test`). Do not assume a specific test runner or package manager.
+</process>
+
+<success_criteria>
+- Correct signal type(s) chosen for the task
+- No `null` or `undefined` in signal generics (`T extends {}`)
+- Every `createEffect` is inside a `createScope` or another effect
+- Code follows the patterns from references/ rather than inventing new ones
+- Project's own test suite passes (if applicable)
+</success_criteria>