@zeix/cause-effect 0.18.5 → 1.0.1

package/skills/cause-effect-dev/references/error-classes.md

@@ -0,0 +1,97 @@
+<overview>
+Error classes thrown by @zeix/cause-effect and the conditions that trigger them. Read this when writing error-handling code, testing error conditions, or diagnosing an unexpected throw.
+</overview>
+
+<error_table>
+| Class | When thrown |
+|---|---|
+| `NullishSignalValueError` | Signal value is `null` or `undefined` |
+| `InvalidSignalValueError` | Value fails the `guard` predicate |
+| `InvalidCallbackError` | A required callback argument is not a function |
+| `DuplicateKeyError` | List/Collection key collision on insert |
+| `UnsetSignalValueError` | Reading a Sensor or Task before it has produced its first value |
+| `ReadonlySignalError` | Attempting to write to a read-only signal |
+| `RequiredOwnerError` | `createEffect` called outside an owner (effect or scope) |
+| `CircularDependencyError` | A cycle is detected in the reactive graph |
+
+All error classes are defined in `src/errors.ts`.
+</error_table>
+
+<error_details>
+
+<NullishSignalValueError>
+Thrown when a signal's value is `null` or `undefined`. Because all signal generics use `T extends {}`, nullish values are excluded by type — this error surfaces the constraint at runtime for cases where type safety is bypassed (e.g. untyped interop, type assertions).
+</NullishSignalValueError>
+
+<InvalidSignalValueError>
+Thrown when a value passed to `set()` fails the `guard` predicate supplied in the signal's options. This is the runtime enforcement of custom type narrowing at signal boundaries.
+
+```typescript
+const age = createState(0, {
+  guard: (v): v is number => typeof v === 'number' && v >= 0,
+})
+age.set(-1) // throws InvalidSignalValueError
+```
+</InvalidSignalValueError>
+
+<InvalidCallbackError>
+Thrown when a required callback argument (e.g. the computation function passed to `createMemo`, `createTask`, or `createEffect`) is not a function. Catches programming errors like passing `undefined` or a non-function value.
+</InvalidCallbackError>
+
+<DuplicateKeyError>
+Thrown when inserting an item into a List or Collection whose key already exists. Keys must be unique within a given List or Collection. Use `update()` or `set()` to change an existing entry instead.
+</DuplicateKeyError>
+
+<UnsetSignalValueError>
+Thrown when `.get()` is called on a Sensor or Task before it has emitted its first value. Unlike State, Sensor and Task have no initial value — they start in an explicitly unset state.
+
+Handle this with `match`, which provides a `nil` branch for the unset case:
+
+```typescript
+match([sensor, task], {
+  ok: ([s, t]) => render(s, t),
+  nil: () => showSpinner(),
+})
+```
+</UnsetSignalValueError>
+
+<ReadonlySignalError>
+Thrown when code attempts to call `.set()` on a signal that was created as or converted to a read-only signal. Derived signals (Memo, Task) are inherently read-only; certain factory options can also produce read-only State or Sensor instances.
+</ReadonlySignalError>
+
+<RequiredOwnerError>
+Thrown when `createEffect` is called without an active owner in the current execution context. Effects must be created inside a `createScope` callback or inside another `createEffect` callback so that their cleanup can be registered.
+
+```typescript
+// Wrong — no active owner
+createEffect(() => console.log('runs'))  // throws RequiredOwnerError
+
+// Correct — wrapped in a scope
+const dispose = createScope(() => {
+  createEffect(() => console.log('runs'))
+})
+```
+</RequiredOwnerError>
+
+<CircularDependencyError>
+Thrown when the graph engine detects a cycle during propagation — a signal that, directly or transitively, depends on itself. Cycles make it impossible to determine a stable evaluation order and are always a programming error.
+
+Common cause: a Memo or Task that writes to a State it also reads, or two Memos that read each other.
+</CircularDependencyError>
+
+</error_details>
+
+<testing_error_conditions>
+Use `expect(() => ...).toThrow(ErrorClass)` to assert that a specific error is thrown:
+
+```typescript
+import { InvalidSignalValueError, createState } from '@zeix/cause-effect'
+
+test('rejects negative age', () => {
+  const age = createState(0, { guard: (v): v is number => typeof v === 'number' && v >= 0 })
+  expect(() => age.set(-1)).toThrow(InvalidSignalValueError)
+})
+```
+
+Import error classes directly from `src/errors.ts` in internal tests, or from the package root in consumer-facing tests.
+</testing_error_conditions>

package/skills/cause-effect-dev/references/internal-types.md

@@ -0,0 +1,54 @@
+<overview>
+Internal node shapes and global pointers in the @zeix/cause-effect graph engine. Read this when working on graph propagation, ownership, or cleanup.
+</overview>
+
+<node_shapes>
+Five node shapes are used internally. Source files are authoritative — these are summaries only.
+
+| Shape | Role | File |
+|---|---|---|
+| `StateNode<T>` | Source only — holds a value, no dependencies | `src/nodes/state.ts` |
+| `MemoNode<T>` | Source + sink — derives a value from dependencies | `src/nodes/memo.ts` |
+| `TaskNode<T>` | Source + sink + `AbortController` — async derivation with cancellation | `src/nodes/task.ts` |
+| `EffectNode` | Sink + owner — runs side effects, owns child effects/scopes | `src/nodes/effect.ts` |
+| `Scope` | Owner only — groups cleanup registrations, no reactive tracking | `src/graph.ts` |
+
+`Slot`, `Store`, `List`, and `Collection` are built on top of `MemoNode<T>` internally.
+</node_shapes>
+
+<global_pointers>
+Two independent global pointers are maintained by `src/graph.ts`:
+
+**`activeSink`**
+- Set to the currently-running Memo, Task, or Effect during its computation
+- Any signal read while `activeSink` is set records a dependency edge to it
+- Nulled by `untrack(fn)` — reads inside `fn` do not create edges
+- Reset to `null` after each computation completes
+
+**`activeOwner`**
+- Set to the currently-running Effect or Scope
+- Any cleanup registered while `activeOwner` is set is attached to that owner
+- Nulled by `unown(fn)` — cleanups registered inside `fn` are not owned by the current context
+- Use `unown` in `connectedCallback` for nodes whose lifecycle is managed by the DOM, not by the reactive graph
+</global_pointers>
+
+<ownership_vs_tracking>
+The two pointers are independent and serve different purposes:
+
+| Pointer | Purpose | Nulled by |
+|---|---|---|
+| `activeSink` | Dependency tracking (what re-runs when a source changes) | `untrack()` |
+| `activeOwner` | Cleanup registration (what is disposed when an owner is disposed) | `unown()` |
+
+A computation can track dependencies without owning cleanups, and vice versa. These are not the same concept.
+</ownership_vs_tracking>
+
+<flag_semantics>
+Propagation is driven by bitmask flags defined in `src/graph.ts`. Read that file and `ARCHITECTURE.md` for the full semantics. Key flags:
+
+- `FLAG_DIRTY` — node's value is stale and must recompute
+- `FLAG_CHECK` — node may be stale; check sources before deciding whether to recompute
+- `FLAG_NOTIFIED` — node has already been scheduled in the current flush
+
+`FLAG_CHECK` is how `equals` suppresses subtrees: when a Memo recomputes to the same value, downstream nodes are marked `FLAG_CHECK` instead of `FLAG_DIRTY`, and they skip recomputation if their sources have not actually changed.
+</flag_semantics>

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

@@ -0,0 +1,146 @@
+<overview>
+Counterintuitive behaviors in @zeix/cause-effect that commonly cause bugs or confusion. Read this when debugging unexpected reactive behavior, or when writing tests that cover edge cases.
+</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 that is `equals` to the previous one, all downstream nodes receive `FLAG_CHECK` instead of `FLAG_DIRTY`. Those nodes skip recomputation entirely without running their callbacks.
+
+This is a powerful optimization, 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` and then `watched` again — the callback remains active for the lifetime of the subscription.
+
+```typescript
+const list = createList(
+  () => fetchItems(),         // watched: start polling / open WebSocket
+  () => stopPolling(),        // unwatched: stop polling / close WebSocket
+)
+
+// Adding or removing items from the list does 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 callback is NOT called again
+list.delete('1')                          // watched callback 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; 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 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` or by checking the signal's status before reading:
+
+```typescript
+const sensor = createSensor(set => {
+  const id = setInterval(() => set(Date.now()), 1000)
+  return () => clearInterval(id)
+})
+
+// Wrong — throws UnsetSignalValueError on first run, before the interval fires
+createEffect(() => {
+  console.log(sensor.get())
+})
+
+// Correct — match handles the nil (unset) case explicitly
+createEffect(() => {
+  match([sensor], {
+    ok: ([timestamp]) => console.log(timestamp),
+    nil: () => console.log('waiting for first value…'),
+  })
+})
+```
+</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 flush (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-dev/references/source-map.md

@@ -0,0 +1,45 @@
+<overview>
+Where to find things in the @zeix/cause-effect codebase. Read this before locating any source file.
+</overview>
+
+<authoritative_documents>
+| What you need | Where to look |
+|---|---|
+| Vision, audience, constraints, non-goals | `REQUIREMENTS.md` |
+| Mental model, non-obvious behaviors, TS constraints | `CLAUDE.md` |
+| Full API reference with examples | `README.md` |
+| Mapping from React/Vue/Angular patterns; when to use each signal type | `GUIDE.md` |
+| Graph engine architecture, node shapes, propagation | `ARCHITECTURE.md` |
+| Public API surface (all exports, types) | `index.ts` |
+| Core graph engine (flags, propagation, flush, ownership) | `src/graph.ts` |
+| Error classes | `src/errors.ts` |
+| Signal base types and type guards | `src/signal.ts` |
+| Shared utilities | `src/util.ts` |
+</authoritative_documents>
+
+<signal_source_files>
+Each signal type lives in its own file under `src/nodes/`:
+
+| Signal | File | Factory | Type guard |
+|---|---|---|---|
+| State | `src/nodes/state.ts` | `createState()` | `isState()` |
+| Sensor | `src/nodes/sensor.ts` | `createSensor()` | `isSensor()` |
+| Memo | `src/nodes/memo.ts` | `createMemo()` | `isMemo()` |
+| Task | `src/nodes/task.ts` | `createTask()` | `isTask()` |
+| Effect | `src/nodes/effect.ts` | `createEffect()` | — |
+| Slot | `src/nodes/slot.ts` | `createSlot()` | `isSlot()` |
+| Store | `src/nodes/store.ts` | `createStore()` | `isStore()` |
+| List | `src/nodes/list.ts` | `createList()` | `isList()` |
+| Collection | `src/nodes/collection.ts` | `createCollection()` / `deriveCollection()` | `isCollection()` |
+
+`match()` and `MatchHandlers` live in `src/nodes/effect.ts` alongside `createEffect`.
+</signal_source_files>
+
+<quick_lookup>
+- Changing a signal's public API → read the signal's source file + `index.ts` + the relevant section of `README.md`
+- Changing graph traversal, flags, or flush order → read `src/graph.ts` + `ARCHITECTURE.md`
+- Adding or changing error conditions → read `src/errors.ts`
+- Adding a shared utility → check `src/util.ts` first; add there if it belongs to multiple nodes
+- Checking type constraints or TS-specific decisions → read `CLAUDE.md`
+- Verifying a feature is in scope → read `REQUIREMENTS.md`
+</quick_lookup>

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

@@ -0,0 +1,55 @@
+<required_reading>
+Load references based on the question type — only what is needed:
+
+- API usage or call signatures → references/api-facts.md + references/source-map.md
+- Internal architecture, node shapes, ownership → references/internal-types.md
+- Graph propagation, flags, flush order → references/internal-types.md (then read `ARCHITECTURE.md` if still unclear)
+- Unexpected or counterintuitive behavior → references/non-obvious-behaviors.md
+- A thrown error → references/error-classes.md
+- Design rationale or constraints → `REQUIREMENTS.md` + `CLAUDE.md`
+- Comparing signal types or migration from React/Vue/Angular → references/source-map.md (then read `GUIDE.md`)
+</required_reading>
+
+<process>
+## Step 1: Categorise the question
+
+Identify which category applies:
+
+| Category | Signal words |
+|---|---|
+| API / call signature | "how do I use", "what does X return", "what are the options for" |
+| Internal architecture | "how does it work internally", "what is a node", "how is ownership tracked" |
+| Graph / propagation | "when does it re-run", "why did X not update", "what is FLAG_CHECK" |
+| Non-obvious behavior | "why does this not work", "is this a bug", "why is `watched` not firing" |
+| Error meaning | "what does X error mean", "when is Y thrown" |
+| Design rationale | "why was X designed this way", "why is null excluded", "why no X signal type" |
+| Signal type comparison | "when should I use Memo vs Task", "what is a Slot", "Sensor vs State" |
+
+## Step 2: Load the relevant references
+
+Read only the reference files listed for that category above. Do not load references speculatively.
+
+If a reference points to an authoritative document (`ARCHITECTURE.md`, `GUIDE.md`, `REQUIREMENTS.md`, `CLAUDE.md`), read that document only if the reference files do not fully resolve the question.
+
+## Step 3: Read source if needed
+
+If the question requires knowing exact implementation details (option defaults, internal flag values, exact type signatures), use references/source-map.md to locate and read the relevant source file.
+
+Never guess at implementation details. If uncertain, read the source.
+
+## Step 4: Answer
+
+Ground every claim in a source. Cite the file when the answer is non-obvious (e.g. "per `ARCHITECTURE.md`…" or "in `src/nodes/memo.ts`…").
+
+For counterintuitive behaviors, include a minimal code example showing the correct pattern alongside the incorrect one. Use the examples in references/non-obvious-behaviors.md as a model.
+
+For design rationale questions, distinguish between hard constraints (stated in `REQUIREMENTS.md`) and soft conventions (described in `CLAUDE.md`).
+</process>
+
+<success_criteria>
+- Answer is grounded in authoritative sources, not inference
+- Source cited when the answer is non-obvious
+- Counterintuitive behaviors include a correct vs incorrect code example
+- Design answers distinguish constraints from conventions
+- No reference files loaded beyond what the question required
+</success_criteria>

package/skills/cause-effect-dev/workflows/fix-bug.md

@@ -0,0 +1,63 @@
+<required_reading>
+1. references/source-map.md — locate the relevant source file(s)
+2. references/non-obvious-behaviors.md — the bug may be a known gotcha
+3. references/internal-types.md — if the bug involves graph propagation, ownership, or node state
+4. references/error-classes.md — if the bug manifests as an unexpected thrown error
+</required_reading>
+
+<process>
+## Step 1: Reproduce
+
+Identify the smallest possible reproduction. If a failing test exists, run it:
+
+```bash
+bun test --test-name-pattern "name of failing test"
+```
+
+If no test exists, write one that demonstrates the incorrect behavior before touching any source.
+
+## Step 2: Read the relevant source
+
+Use references/source-map.md to locate the source file(s) involved. Read them in full. Do not guess at the cause before reading.
+
+## Step 3: Check known gotchas
+
+Read references/non-obvious-behaviors.md. Many apparent bugs are actually expected behaviors:
+- Lookup methods (`byKey`, `at`, `keyAt`, `indexOfKey`) do not create graph edges
+- Conditional signal reads can delay `watched` activation
+- A custom `equals` on an intermediate Memo suppresses entire downstream subgraphs
+
+If the reported behavior matches a known non-obvious behavior, explain it rather than patching it.
+
+## Step 4: Check graph-level issues
+
+If the bug involves unexpected re-runs, missing updates, or ownership/cleanup problems, read `ARCHITECTURE.md` for flag semantics and propagation rules.
+
+## Step 5: Identify the root cause
+
+Trace the failure to its origin — do not fix the symptom. Confirm the root cause by reasoning through the propagation path or ownership chain before writing any fix.
+
+## Step 6: Fix
+
+Apply the minimal change that addresses the root cause. Follow existing conventions:
+- Flag names and bitmask operations from `src/graph.ts`
+- Error types from `src/errors.ts`
+- Do not introduce new utilities if `src/util.ts` already covers the need
+
+## Step 7: Verify
+
+Run the full test suite:
+
+```bash
+bun test
+```
+
+All tests must pass. If the reproduction test did not exist before Step 1, confirm it now passes too.
+</process>
+
+<success_criteria>
+- Root cause identified (not just symptom suppressed)
+- Minimal fix applied
+- Reproduction test passes
+- `bun test` passes with no regressions
+</success_criteria>

package/skills/cause-effect-dev/workflows/implement-feature.md

@@ -0,0 +1,46 @@
+<required_reading>
+1. references/source-map.md — locate the relevant source file(s)
+2. references/api-facts.md — API constraints and callback patterns
+3. references/non-obvious-behaviors.md — if the change touches graph edges, ownership, or reactive tracking
+</required_reading>
+
+<process>
+## Step 1: Confirm scope
+
+Read `REQUIREMENTS.md`. Verify the feature is in scope — the signal type set is complete and new types are explicitly out of scope. If the request would add a new signal type, stop and explain this constraint.
+
+## Step 2: Locate relevant source
+
+Use references/source-map.md to identify:
+- Which signal file(s) in `src/nodes/` are involved
+- Which authoritative documents to read (README.md for API shape, ARCHITECTURE.md for graph-level changes)
+
+## Step 3: Read before writing
+
+Read the identified source file(s) in full. Do not propose or write any code before doing this.
+
+If the change touches graph propagation, flag semantics, or ownership: read `ARCHITECTURE.md` in full.
+
+If the change affects the public API surface: read the relevant section of `README.md` and `index.ts`.
+
+## Step 4: Implement
+
+Make the change. Follow existing conventions in the file:
+- Naming patterns (`createX`, `isX`, node shape fields)
+- Internal flag usage (defined in `src/graph.ts`)
+- Error types from `src/errors.ts`
+- Utility functions from `src/util.ts` before writing new ones
+
+## Step 5: Verify
+
+Run `bun test`. Fix any failures before considering the task done.
+
+If the public API changed, check that `README.md` and `index.ts` are consistent with the new behavior.
+</process>
+
+<success_criteria>
+- Feature works as specified
+- Follows existing naming and structural conventions
+- `bun test` passes with no regressions
+- Public API surface in `index.ts` and `README.md` is consistent with the change
+</success_criteria>

package/skills/cause-effect-dev/workflows/write-tests.md

@@ -0,0 +1,64 @@
+<required_reading>
+1. references/source-map.md — locate the signal type or module being tested
+2. references/api-facts.md — correct API usage for test cases
+3. references/non-obvious-behaviors.md — ensure gotchas are covered
+4. references/error-classes.md — cover expected error conditions
+</required_reading>
+
+<process>
+## Step 1: Identify what to test
+
+Clarify the scope before writing anything:
+- Which signal type or behavior is under test?
+- Is this a new test, an extension of existing coverage, or a regression test for a known bug?
+
+## Step 2: Read the source
+
+Use references/source-map.md to locate the relevant source file in `src/nodes/`. Read it in full. Tests must match what the implementation actually does, not what you expect it to do.
+
+## Step 3: Read existing tests
+
+Find the existing test file for the signal type (look adjacent to or named after the source file). Read it to understand:
+- Test structure and helper patterns in use
+- Which behaviors are already covered
+- Naming conventions
+
+## Step 4: Identify gaps
+
+Cross-reference the source, existing tests, and these reference files:
+- references/non-obvious-behaviors.md — are gotchas covered?
+- references/error-classes.md — are thrown errors tested?
+- references/api-facts.md — are all option variants exercised (e.g. `equals`, `guard`)?
+
+## Step 5: Write tests
+
+Follow the conventions of the existing test suite. Each test should:
+- Have a descriptive name that states the expected behavior
+- Be self-contained (no shared mutable state between tests)
+- Cover one specific behavior per test
+
+Priority order for coverage:
+1. Happy path (normal usage)
+2. Edge cases and boundary conditions
+3. Expected error throws (use `expect(() => ...).toThrow(ErrorClass)`)
+4. Non-obvious behaviors from references/non-obvious-behaviors.md
+5. Interaction with `batch`, `untrack`, `unown` if the signal participates in those
+
+## Step 6: Verify
+
+Run the full test suite:
+
+```bash
+bun test
+```
+
+All tests — new and existing — must pass.
+</process>
+
+<success_criteria>
+- Tests cover the specified signal type or behavior
+- Each test is self-contained and has a descriptive name
+- Expected error conditions are tested with the correct error class
+- At least one relevant non-obvious behavior is covered if applicable
+- `bun test` passes with no regressions
+</success_criteria>