diff --git a/.gitignore b/.gitignore
index d80e42e8..5b69bc8e 100644
--- a/.gitignore
+++ b/.gitignore
@@ -32,3 +32,8 @@ grimoires/
 # Superpowers implementation plans are local scratch artifacts, never commit them.
 /docs/superpowers/plans/
 /docs/superpowers/plans/**/*.md
+
+# PR follow-up code-review notes are local scratch, keep them untracked.
+/docs/pr-*-follow-up-*code-review*.md
+# GA cleanup backlog is a local working note, keep it untracked.
+/docs/ga-cleanup-backlog.md
diff --git a/docs/superpowers/specs/ 2026-08-04-nodejs-external-modules-design.md b/docs/superpowers/specs/2026-08-04-nodejs-external-modules-design.md
similarity index 100%
rename from docs/superpowers/specs/ 2026-08-04-nodejs-external-modules-design.md
rename to docs/superpowers/specs/2026-08-04-nodejs-external-modules-design.md
diff --git a/docs/superpowers/specs/2026-08-07-native-lib-multi-engine-design.md b/docs/superpowers/specs/2026-08-07-native-lib-multi-engine-design.md
new file mode 100644
index 00000000..5a491acc
--- /dev/null
+++ b/docs/superpowers/specs/2026-08-07-native-lib-multi-engine-design.md
@@ -0,0 +1,169 @@
+# Design: Multiple Isolated DataWeave Engines per Process (native-lib, Node)
+
+**Date:** 2026-08-07
+**Status:** Approved for implementation
+**Tracks:** GUS [W-23692110](https://gus.my.salesforce.com/lightning/r/ADM_Work__c/a07EE00002gS7SOYA0/view) — "Native-lib: support multiple DataWeave engine instances with independent module resolvers"
+**Related:** [docs/superpowers/specs/2026-08-04-nodejs-external-modules-design.md](./2026-08-04-nodejs-external-modules-design.md) (the design during which this limitation was discovered)
+
+## Goal
+
+Let multiple `DataWeave` instances coexist in one Node process, each with its own module resolver and script cache, so that different resolvers never collide. Today the second `new DataWeave({ resolveModule })` in a process silently keeps the first instance's resolver.
+
+## Background
+
+`native-lib`'s `ScriptRuntime` (`native-lib/src/main/java/org/mule/weave/lib/ScriptRuntime.java`) is a `static final` singleton (`:33`) holding one `engine` and a **write-once** `static volatile resolver` (`:36`). `setResolver` refuses to run a second time per process (`:58-63`, logs a warning and returns). Every `@CEntryPoint` in `NativeLib.java` routes through `ScriptRuntime.getInstance()`. So two `DataWeave` instances in one process cannot have independent module sets — whichever calls a resolver-backed `run()` first wins.
+
+**This is not a GraalVM constraint.** `native-cli`'s `NativeRuntime` (`native-cli/src/main/scala/org/mule/weave/dwnative/NativeRuntime.scala:50-60`) already builds one independent `DataWeaveScriptingEngine` + `CompositeWeaveResourceResolver` per instance — there is no shared static state there. GraalVM Java statics are scoped per-isolate, which is also why the Python binding (one GraalVM isolate per `DataWeave()` instance) already gets resolver isolation "for free" today. The limitation is specific to `native-lib`'s deliberate Java static singleton plus the Node C addon's global resolver bridge.
+
+## Scope
+
+**In scope:**
+- `native-lib` Java layer: turn `ScriptRuntime` from a static singleton into a handle-addressable registry of instances, each with its own engine + resolver.
+- Node C addon (`addon.c`): per-handle resolver bridge state instead of one process-global bridge.
+- Node TypeScript layer (`ffi.ts`, `dataweave.ts`): each `DataWeave` instance owns an engine handle for its whole lifecycle.
+
+**Out of scope:**
+- Python binding changes. Python already achieves isolation via one isolate per instance; unifying it onto the same handle-based API is a **follow-up task** (see Verification).
+- Separate GraalVM isolates per engine — rejected as the isolation mechanism (see Alternatives Considered).
+- Solving streaming/transform + **custom-module** resolution across the background-thread boundary. This is an existing, documented hazard (`NativeLib.java:386-390,471-475`) and stays as-is: streaming against a resolver-backed engine still fails closed (returns "not found") for custom modules reached from the background thread; built-in modules continue to resolve normally in all cases.
+
+## Alternatives Considered
+
+**Separate GraalVM isolates per engine (rejected).** Each engine gets its own isolate — the most complete form of isolation (own heap, own JIT, own Java statics), and what Python already does per-instance. Rejected for Node because:
+- `addon.c` currently assumes exactly one isolate as global state (`g_isolate`, `g_thread`, `g_ref_count`); supporting N isolates means restructuring all of that into per-handle structs.
+- Isolate teardown is documented as fragile: `graal_tear_down_isolate` blocks until every attached thread reaches a safepoint (`addon.c:172-178`), and multiple concurrent isolates multiply that fragility.
+- It is unnecessarily heavy for the actual need: independent module resolution and script caching, not full JVM-level sandboxing between tenants.
+
+**Chosen: object-level engines in one shared isolate.** Multiple `DWScriptingEngine` Java objects, each with its own resolver and compiled-script cache, all living in the single existing GraalVM isolate, addressed by an opaque handle. This mirrors what `native-cli` already does and requires no changes to isolate lifecycle management.
+
+## Architecture
+
+Three-layer change, following the existing callback/FFI layering.
+
+### Layer 1 — Java (`native-lib/src/main/java/org/mule/weave/lib/`)
+
+**`ScriptRuntime.java`** — from static singleton to per-instance + registry:
+- Constructor becomes `ScriptRuntime(CallbackWeaveResourceResolver resolver)` (null ⇒ ClassLoader-only resolver, same as today's default). The resolver is now bound once at construction — immutable for the instance's lifetime. **Remove** the `static setResolver` write-once mutation entirely.
+- Add a static registry:
+  ```java
+  private static final ConcurrentHashMap<Long, ScriptRuntime> REGISTRY = new ConcurrentHashMap<>();
+  private static final AtomicLong NEXT_HANDLE = new AtomicLong(1);
+
+  static long register(ScriptRuntime rt) {
+      long handle = NEXT_HANDLE.getAndIncrement();
+      REGISTRY.put(handle, rt);
+      return handle;
+  }
+  static ScriptRuntime get(long handle) { return REGISTRY.get(handle); }
+  static void destroy(long handle) { REGISTRY.remove(handle); }
+  ```
+- `compositeResolver()` / `createModuleComponentsFactory()` become instance methods operating on the instance's own resolver field instead of a static field.
+- **Keep `getInstance()`** returning a lazily-created default (ClassLoader-only, handle-less) instance, so the existing resolver-less `@CEntryPoint`s (`run_script`, `run_script_callback`, `run_script_input_output_callback`) — used by the Python binding — are untouched.
+
+**`CallbackWeaveResourceResolver.java`** — store a `PointerBase ctx` alongside the callback, forwarded on every `callback.invoke(...)` call (see Layer 2 crux below). Constructor becomes `(ResolveModuleCallback callback, PointerBase ctx)`.
+
+**`NativeCallbacks.java`** — add a context parameter to the resolver callback, mirroring the existing `WriteCallback`/`ReadCallback` `ctx` idiom (`:31-49`):
+```java
+public interface ResolveModuleCallback extends CFunctionPointer {
+    @InvokeCFunctionPointer
+    CCharPointer invoke(IsolateThread thread, PointerBase ctx, CCharPointer modulePath);
+}
+```
+This is what lets one shared native callback dispatch to the correct per-handle JS resolver on the C side.
+
+**`NativeLib.java`** — add lifecycle + handle-based execution entrypoints; keep all existing entrypoints unchanged for Python:
+- `create_engine(IsolateThread) -> long`
+- `create_engine_with_resolver(IsolateThread, ResolveModuleCallback, PointerBase ctx) -> long`
+- `destroy_engine(IsolateThread, long handle)`
+- `run_script_engine(IsolateThread, long handle, CCharPointer script, CCharPointer inputs) -> CCharPointer`
+- `run_script_callback_engine(...)` / `run_script_input_output_callback_engine(...)` — same bodies as today's streaming methods, but resolving the `ScriptRuntime` via `ScriptRuntime.get(handle)` instead of `getInstance()`.
+
+The existing `run_script_with_resolver`, `run_script_callback_with_resolver`, and `run_script_input_output_callback_with_resolver` entrypoints (`NativeLib.java:348-566`) are **removed** — they are not called from any stable release path (per their own doc comments) and their functionality is fully subsumed by `create_engine_with_resolver` + the handle-based run methods.
+
+### Layer 2 — C addon (`native-lib/node/src/addon.c`)
+
+- Replace the process-global resolver bridge state (`g_resolver_env`, `g_resolver_ref`, `g_resolver_thread`, `:73-86`) with a small per-handle registry: `{ napi_env env; napi_ref resolver_js; uv_thread_t owner; }` keyed by handle (a fixed-size array or linked list is sufficient — engine counts per process are expected to be small).
+- **Crux — dispatching to the right resolver.** `ResolveModuleCallback` gains a `ctx` parameter (Layer 1). `createEngineWithResolver` allocates the per-handle bridge struct and passes its address as `ctx` down through `create_engine_with_resolver`. When Java invokes `resolve_module_callback(thread, ctx, path)`, C casts `ctx` back to the bridge struct and calls the JS resolver it holds — synchronously on the JS thread, exactly as today (no `napi_threadsafe_function`; the existing deadlock rationale at `:62-72` still applies, since `createEngineWithResolver`'s native call runs synchronously on the calling JS thread).
+- Keep the thread-affinity guard, now scoped per-handle: if `resolve_module_callback` is reached from a thread other than the bridge's recorded `owner` (e.g. from `streaming_thread_fn`/`transform_thread_fn`), fail closed — return "not found" — instead of touching `napi_env` from the wrong thread. This preserves today's safety property, just per-engine instead of process-wide.
+- Reuse the existing per-call result-buffer tracking (`resolver_results_track`/`resolver_results_free_all`, `:94-118`) unchanged — it is already scoped to a single native call.
+- New N-API methods: `createEngine()`, `createEngineWithResolver(resolverFn)`, `destroyEngine(handle)`, and handle-taking `runScriptEngine`, `runScriptStreamingEngine`, `runScriptTransformEngine` — each attaches/detaches an isolate thread exactly like the current per-call pattern (`fn_attach_thread`/`fn_detach_thread`).
+
+### Layer 3 — Node TypeScript (`native-lib/node/src/`)
+
+**`ffi.ts`** — add `createEngine()`, `createEngineWithResolver(resolver)`, `destroyEngine(handle)`, and handle-taking `runScriptEngine`, `runScriptStreamingEngine`, `runScriptTransformEngine`. Remove `runWithResolver`.
+
+**`dataweave.ts`** — `DataWeave` gains a `private engineHandle?: number`:
+- `initialize()`: after `ffi.initialize()`, call `ffi.createEngineWithResolver(this.resolveModule)` if a resolver was supplied at construction, else `ffi.createEngine()`; store the returned handle.
+- `run()` / `runStreaming()` / `runTransform()`: always route through the handle-based FFI methods, passing `this.engineHandle`. Drop the `if (this.resolveModule) { ffi.runWithResolver(...) } else { ffi.runScript(...) }` branch (current `dataweave.ts:123-129`) — there is now exactly one code path per method, parameterized by handle.
+- `cleanup()`: call `ffi.destroyEngine(this.engineHandle)` before releasing the library reference.
+- Update the `resolveModule` docstring (`dataweave.ts:20-48`): remove the "one resolver per process / first instance wins / different-thread" caveats (`:26-42`) — this limitation is what this design fixes. Keep the synchronous-resolver requirement and the security/trust-model note (`:44-46`).
+
+## Data Flow
+
+```
+new DataWeave({ resolveModule: A }).initialize()
+  → ffi.createEngineWithResolver(A)
+  → addon.c: createEngineWithResolver
+      allocate bridge_A { env, ref to A, owner=thisThread }
+      call create_engine_with_resolver(thread, resolve_module_callback, &bridge_A)
+  → Java: new CallbackWeaveResourceResolver(callback, ctx=&bridge_A)
+          new ScriptRuntime(resolver) → handle_A = ScriptRuntime.register(rt)
+  → returns handle_A to JS, stored as this.engineHandle
+
+dwA.run(script importing "custom/lib.dwl")
+  → ffi.runScriptEngine(handle_A, script, inputs)
+  → Java: ScriptRuntime.get(handle_A).run(...)
+      compositeResolver: ClassLoader (miss) → CallbackWeaveResourceResolver
+        callback.invoke(thread, ctx=&bridge_A, "custom/lib.dwl")
+  → C: resolve_module_callback(thread, &bridge_A, path)
+      cast ctx → bridge_A; thread == bridge_A.owner? yes
+      call bridge_A.resolver_js(path) synchronously  →  resolver A's source
+  → result flows back through Java, script compiles
+
+// Second, independent instance in the SAME process:
+new DataWeave({ resolveModule: B }).initialize()  →  handle_B, bridge_B (different resolver, different owner-checked bridge)
+dwB.run(script importing "custom/lib.dwl")
+  → resolves via resolver B, NOT resolver A — no cross-talk, and A's cache is untouched
+```
+
+## Error Handling
+
+Unchanged from the existing resolver design (`ScriptRuntime` compositeResolver, `CallbackWeaveResourceResolver.resolve`) except scoped per-handle:
+- **Module not found:** resolver returns `null` → `Option.empty()` → composite resolver falls through → standard DataWeave "unable to resolve module" error, same as today.
+- **Resolver throws / callback fails:** caught in `CallbackWeaveResourceResolver.resolve`'s existing try/catch, logged, treated as not-found — unchanged.
+- **Wrong-thread resolver invocation (streaming/transform against a resolver-backed engine):** the per-handle `owner` check in `addon.c` fails closed to "not found" instead of touching `napi_env` cross-thread. This is the same safety property as today's process-wide guard, just correctly scoped to the specific engine instance instead of the whole process.
+- **Invalid/unknown handle** (`run_script_engine` called after `destroy_engine`, or with a bogus value): `ScriptRuntime.get(handle)` returns `null`; the `@CEntryPoint` returns a `{"success":false,"error":"Unknown engine handle"}` JSON error rather than throwing an NPE.
+
+## Backward Compatibility
+
+- **Python binding:** zero changes. It never called the `*_with_resolver` entrypoints being removed, and continues using `run_script`/`run_script_callback`/`run_script_input_output_callback` against the default `getInstance()` runtime.
+- **Node, resolver-less usage:** `new DataWeave()` with no `resolveModule` behaves identically — `initialize()` calls `createEngine()` (no resolver), execution unchanged from the caller's perspective.
+- **Node, single-resolver usage:** existing tests that construct exactly one `DataWeave({ resolveModule })` per process continue to pass — the new code path is functionally a superset (it now also supports a second, independent instance).
+- **Breaking (internal-only) change:** `ResolveModuleCallback`'s native signature gains a `ctx` parameter. This is an internal FFI contract with no external callers documented outside this repo (the Node addon is the sole consumer), so it is not a public API break.
+
+## Testing Strategy
+
+1. **Java unit test** (`native-lib:test`, new test class alongside `ScriptRuntime`): register two `ScriptRuntime` instances with different in-memory `CallbackWeaveResourceResolver`s; assert each instance's `run()` resolves only its own module; assert `destroy()` removes an instance so `get()` returns `null` afterward.
+2. **Node integration test** (`native-lib:nodeTest`) — the direct W-23692110 regression: construct two `DataWeave` instances in the same process with different `modulesFromMap` resolvers; assert each `run()` resolves its own import and fails to resolve the other's; assert built-in modules (e.g. `dw::core::Strings`) resolve correctly through both.
+3. **Backward-compat regression:** existing resolver-less and single-resolver Node tests continue to pass unchanged. Full Python test suite (`native-lib:pythonTest`) passes unchanged (no Python-facing code touched).
+4. **Native image build:** `./gradlew native-lib:nativeCompile` stays green; check build output for any new `--initialize-at-run-time` requirement introduced by the registry (`ConcurrentHashMap`/`AtomicLong` are standard JDK classes already used elsewhere in this codebase, so none expected).
+
+## Follow-Up Work
+
+- **Python binding parity:** file a GUS work item (child of W-23692110) to port the handle-based `create_engine`/`run_script_engine` API to the Python binding, so both bindings share one mental model instead of Python's implicit "one isolate per instance" and Node's explicit "one handle per instance."
+- **Streaming/transform + custom-module resolution:** the cross-thread hazard preventing custom-module resolution during streaming/transform (documented in `NativeLib.java`) is unrelated to the singleton fix and remains a separate, not-yet-scoped effort.
+
+## References
+
+| Item | Location |
+|------|----------|
+| GUS ticket | W-23692110 |
+| Singleton root cause | `native-lib/src/main/java/org/mule/weave/lib/ScriptRuntime.java:33-45` |
+| Write-once resolver guard | `native-lib/src/main/java/org/mule/weave/lib/ScriptRuntime.java:58-63` |
+| CLI's per-instance pattern (proof it's not a GraalVM constraint) | `native-cli/src/main/scala/org/mule/weave/dwnative/NativeRuntime.scala:50-60` |
+| Existing resolver-aware entrypoints (to be removed) | `native-lib/src/main/java/org/mule/weave/lib/NativeLib.java:348-566` |
+| Existing WriteCallback/ReadCallback ctx idiom | `native-lib/src/main/java/org/mule/weave/lib/NativeCallbacks.java:31-49` |
+| C addon process-global resolver bridge (to be made per-handle) | `native-lib/node/src/addon.c:62-118` |
+| Documented streaming/transform cross-thread hazard | `native-lib/src/main/java/org/mule/weave/lib/NativeLib.java:386-390,471-475` |
+| Node dataweave.ts resolver caveats (to be removed) | `native-lib/node/src/dataweave.ts:26-46` |
+| Original external-modules design (where this limitation was discovered) | `docs/superpowers/specs/2026-08-04-nodejs-external-modules-design.md` |
diff --git a/docs/superpowers/specs/2026-08-11-cleanup-teardown-deadlock-fix-design.md b/docs/superpowers/specs/2026-08-11-cleanup-teardown-deadlock-fix-design.md
new file mode 100644
index 00000000..4ae676c2
--- /dev/null
+++ b/docs/superpowers/specs/2026-08-11-cleanup-teardown-deadlock-fix-design.md
@@ -0,0 +1,101 @@
+# Fix `cleanup()`-During-Active-Stream Deadlock — Design
+
+**Goal:** Eliminate a process-wide deadlock where calling `DataWeave.cleanup()` while any `runStreaming()`/`runTransform()` operation is still in flight (on any engine, in any thread) can freeze the process, by making isolate teardown wait for active operations to drain instead of blocking the JS thread they depend on.
+
+**Architecture:** `napi_cleanup` becomes async: when it's the last release and no ops are active, it keeps today's synchronous spawn+join fast path unchanged. When ops are active, it defers teardown to a dedicated waiter thread that blocks on a condition variable until every op drains, then performs teardown and signals completion back into JS via a `napi_threadsafe_function` — the same pattern this addon already uses for streaming chunk delivery.
+
+**Tech Stack:** N-API C addon (`napi_*`, `uv_thread`/`uv_mutex`/`uv_cond`), TypeScript (`DataWeave.cleanup()` signature change), vitest.
+
+## Global Constraints
+
+- Node binding only — do not touch `native-lib/python/**`.
+- Legacy singleton entrypoints (`run_script`, `run_script_callback`, `run_script_input_output_callback`) and `ScriptRuntime.getInstance()` on the Java side are untouched by this fix; the bug and fix are entirely within `native-lib/node/src/addon.c` and `dataweave.ts`.
+- Handle width stays C `long long` everywhere (unaffected by this fix, but any touched signature must not regress it).
+- The existing per-bridge `in_flight`/`destroy_pending` accounting (F1 remediation, PR #157) is untouched — this fix adds a **separate, process-global** `g_active_ops` counter that covers all streaming/transform ops (resolver-backed or not), because isolate teardown blocks on *any* attached worker thread, not just resolver-backed ones.
+- `DataWeave.cleanup()` signature changes from `void` to `Promise<void>` (async). This is acceptable pre-GA; no external ABI-stability commitment exists yet for the Node package.
+- The module-level `process.on("exit", () => cleanup())` hook (`dataweave.ts:222`) stays fire-and-forget — not awaited. This is a pre-existing, acceptable tradeoff, not a new one.
+
+---
+
+## Background
+
+### The bug
+
+`napi_cleanup` (`addon.c:1189-1218`) decrements the process-global `g_ref_count`. When it drops to 0, it spawns a thread that calls `graal_tear_down_isolate`, then calls **`uv_thread_join` on that thread synchronously, blocking the calling JS thread** until teardown finishes.
+
+`graal_tear_down_isolate` blocks until every GraalVM-attached thread reaches a safepoint/detaches. A `runStreaming()`/`runTransform()` background worker (`streaming_thread_fn`/`transform_thread_fn`) stays attached to the isolate for the duration of its native call, and delivers each chunk via `napi_call_threadsafe_function(..., napi_tsfn_blocking)`, which requires the JS event loop to run the corresponding `call_js_write`/`call_js_transform_write` callback before the worker can proceed.
+
+If `cleanup()` is the call that drops `g_ref_count` to 0 while such a worker is still attached and mid-delivery, this produces a real circular wait:
+
+```
+JS thread: cleanup() -> uv_thread_join(teardown thread) -> blocked
+Teardown thread: graal_tear_down_isolate() -> waiting for worker to detach -> blocked
+Worker thread: napi_call_threadsafe_function(..., blocking) -> waiting for JS thread to run callback -> blocked
+```
+
+`g_isolate`/`g_ref_count` are process-global, so this is reachable even when the streaming op and the `cleanup()` call belong to different, unrelated `DataWeave` instances — not just same-instance self-cleanup.
+
+### Why the existing F1 regression test didn't catch it
+
+The Task 4 F1 test (added during the PR-157 remediation) uses a resolver that throws before emitting any data, so the streaming operation fails fast and the worker thread never reaches the mid-delivery, blocked-on-`napi_tsfn_blocking` state this bug requires.
+
+---
+
+## Design
+
+### New global state (guarded by the existing `g_mutex`)
+
+- **`g_active_ops`** (`int`) — count of all currently-running streaming/transform native calls, across every engine (resolver-backed or not) and every Worker thread.
+- **`g_teardown_pending`** (`bool`) — true from the moment `cleanup()` drops `g_ref_count` to 0 while `g_active_ops > 0`, until teardown actually completes.
+- **`g_teardown_cond`** (`uv_cond_t`) — condition variable the waiter thread blocks on; signaled by each op's completion sentinel after decrementing `g_active_ops`.
+- **`g_teardown_waiters`** (linked list, each node `{napi_env env, napi_deferred deferred, napi_threadsafe_function tsfn}`) — one entry per `cleanup()` call currently waiting on the same in-progress teardown. A list rather than a single slot because a second (or third) `cleanup()` call can arrive from a **different** `napi_env` (a different Worker thread) while the first teardown is still pending — `napi_env`/`napi_deferred`/`napi_threadsafe_function` are thread-affine, so each waiting caller needs its own tsfn created on its own env; there is no way to resolve one env's deferred from another env's thread.
+
+### Op accounting
+
+Every streaming/transform entrypoint (`napi_run_script_streaming_engine`, `napi_run_script_transform_engine`) increments `g_active_ops` under `g_mutex`, immediately alongside the existing `bridge_begin_op` call and before spawning its worker thread — same timing, same "no early return in between" invariant already documented for `bridge_begin_op`.
+
+The completion sentinel branch (`chunk->len == -1`) in `call_js_write`/`call_js_transform_write` decrements `g_active_ops` under `g_mutex`, alongside the existing `bridge_end_op` call, and signals `g_teardown_cond`. This is the only new responsibility added to the sentinel — it does not spawn anything or run teardown itself.
+
+### `napi_cleanup` behavior
+
+1. Lock `g_mutex`, decrement `g_ref_count` only if it's currently `> 0` (a second `cleanup()` call while one is already pending, with `g_ref_count` already at 0, must not decrement further into negative values).
+2. If `g_ref_count > 0` after decrementing: unlock, return an already-resolved promise (today's "no-op until last release" behavior, promise-shaped). Every branch that returns "already resolved" (this one and case 4) creates a `napi_deferred`/promise and resolves it immediately before returning, rather than inventing a separate no-promise return path — keeps `napi_cleanup`'s return type uniformly "a promise" regardless of which branch runs.
+3. If `g_ref_count <= 0` and `g_teardown_pending` is already true (re-entrant call — see Edge Cases): create a new deferred/promise + threadsafe function on *this call's* env, append it to `g_teardown_waiters`, unlock, return the pending promise. No second waiter thread is spawned — this call's node just joins the list the existing waiter thread will drain on completion.
+4. If `g_ref_count <= 0`, `g_teardown_pending` is false, and `g_active_ops == 0`: unchanged fast path — spawn+join the teardown thread inline (`cleanup_thread_fn`, unmodified), reset `g_thread`/`g_isolate`/`g_initialized`/`g_ref_count`, unlock, return an already-resolved promise.
+5. If `g_ref_count <= 0`, `g_teardown_pending` is false, and `g_active_ops > 0`: set `g_teardown_pending = true`; create a deferred/promise + threadsafe function on this env, append it as the first node of `g_teardown_waiters`; spawn the **waiter thread**; unlock; return the pending promise.
+
+### Waiter thread
+
+A dedicated thread (spawned only in case 5 above) that:
+1. Locks `g_mutex`, waits on `g_teardown_cond` while `g_active_ops > 0`.
+2. Once drained, runs teardown exactly as `cleanup_thread_fn` does today (attach a local thread to the isolate, call `graal_tear_down_isolate`, ignoring its return code — matching today's behavior of not propagating a teardown failure).
+3. Resets `g_thread`/`g_isolate`/`g_initialized`/`g_ref_count`/`g_teardown_pending` under `g_mutex`, signals `g_teardown_cond` again (to release any `initialize()` call blocked in the re-entrant-init path below).
+4. Walks `g_teardown_waiters`: for each node, calls its `tsfn` to resolve its `deferred` back on its own env, then releases that threadsafe function. Clears the list once every node has been signaled.
+
+This thread is dedicated to this one teardown — no unrelated Worker's event loop is ever blocked as a side effect of finishing its own streaming op (rejected alternative: piggybacking teardown onto the last op's own completion sentinel, which would stall whichever unrelated thread happens to run that sentinel for the full teardown duration).
+
+### `DataWeave.cleanup()` (TypeScript)
+
+`cleanup(): Promise<void>` (was `void`). Awaits `ffi.cleanup()`'s now-Promise-returning addon call. Callers that need the old synchronous-fire-and-forget behavior (e.g. the module-level process-exit hook) simply don't await it — unchanged behavior for them, since the promise resolving or not doesn't block anything if nobody awaits it.
+
+---
+
+## Edge Cases
+
+**Re-entrant `cleanup()` while teardown is pending, possibly from a different Worker/env.** Handled by case 3 above — `g_ref_count` doesn't go negative, no second waiter thread is spawned, and each caller's own env gets its own list node (deferred + tsfn) so it can be resolved on its own thread when teardown finishes, regardless of which env made the original triggering call. Preserves `cleanup()`'s documented idempotency (`dataweave.ts:105`, "a no-op if not initialized") at the addon layer, including across Workers.
+
+**`initialize()` called while a teardown is pending.** `napi_initialize` must not re-create the isolate while the old one is still tearing down (risk of two live isolates, or use of a half-torn-down one). Add a check: if `g_teardown_pending` is true, block on `g_teardown_cond` until it's false and `g_isolate == NULL` is confirmed, then proceed with the existing create-isolate logic. This is a narrow, rare path (re-initializing mid-drain) but must not be skipped.
+
+**`graal_tear_down_isolate` returning a non-zero/failure code.** Unchanged from today — the existing fast path already ignores this return value; the waiter thread preserves that (no new failure-propagation behavior invented for this fix).
+
+**Process exit while ops are active and teardown is pending.** No new behavior introduced; an active native worker thread at process exit is already an existing, out-of-scope condition handled by libuv/Node's own exit sequencing, not this addon.
+
+---
+
+## Testing
+
+1. **Deadlock regression (the core test).** For both `runStreaming()` and `runTransform()`: start an operation whose script produces multiple chunks with real volume/delay between them (so the worker is genuinely attached and mid-delivery, not failing fast like the existing F1 test). Call `gen.next()` once to pin the operation, then `await dw.cleanup()` before draining the generator. Assert the returned promise resolves within a bounded timeout (test-level timeout or explicit `Promise.race`) rather than hanging, and that the streaming generator itself eventually settles.
+2. **Fast-path regression guard.** `cleanup()` called after a stream has already fully drained (`g_active_ops == 0` at the moment of last release) still resolves via the unchanged inline fast path — confirms the new branch didn't silently become the only path.
+3. **Idempotency / re-entrant cleanup.** Two concurrent (or sequential, unawaited-then-awaited) `cleanup()` calls while a stream is active both resolve off the same underlying teardown, without spawning a second waiter thread or throwing.
+4. **Re-initialize during pending teardown.** Start a stream, call `cleanup()` without awaiting, then immediately call `initialize()` again — confirms it blocks until the pending teardown finishes and the instance is usable afterward (a subsequent `run()` succeeds).
+5. **No regression in the existing suite.** All current streaming/transform/lifecycle tests, including the Task 4 F1/F4/F6 additions from the PR-157 remediation, continue passing unmodified.
diff --git a/docs/superpowers/specs/2026-08-14-instance-lifecycle-state-fix-design.md b/docs/superpowers/specs/2026-08-14-instance-lifecycle-state-fix-design.md
new file mode 100644
index 00000000..7d67e352
--- /dev/null
+++ b/docs/superpowers/specs/2026-08-14-instance-lifecycle-state-fix-design.md
@@ -0,0 +1,111 @@
+# DataWeave Instance Lifecycle State Fix — Round 6 (W-23692110)
+
+**Status:** Design approved, ready for planning.
+
+**Source review:** `docs/pr-157-follow-up-andy-code-review-6.md` (three findings, all verified against live source at commit `49d2881`).
+
+**Scope:** `native-lib/node` only — `src/dataweave.ts`, `src/addon.c`, and new tests under `tests/`. Do **not** touch `native-lib/python/**`.
+
+## Problem
+
+The sixth "andy" follow-up review of PR #157 raised three findings. All three were verified against the live source and are **new** (distinct from rounds 1–5, whose fixes remain intact at HEAD). Rounds 1–5 targeted the module-level singleton and the native isolate teardown; round 6 is the first to attack the **per-instance (`new DataWeave()`) lifecycle** and the **unguarded native lifecycle/handle reads**.
+
+### Root cause
+
+Lifecycle state is under-modeled at two layers:
+
+1. **JS layer:** `DataWeave` uses a single boolean `initialized`. The real lifecycle has an intermediate "cleaning up" phase (`cleanup()` started but `await ffi.cleanup()` not yet settled), which a boolean cannot represent. Every `if (this.initialized)` check therefore treats the cleanup window as "ready." This is exactly what findings #1 and #3 exploit.
+2. **C layer:** `napi_run_script_streaming_engine` / `napi_run_script_transform_engine` read the lifecycle flag `g_initialized` **outside** the `g_mutex` that guards it, then reserve `g_active_ops` in a later, separate critical section — a check-and-reserve TOCTOU (finding #2).
+
+### The three findings (all confirmed)
+
+**#1 (P1) — cleanup makes the engine handle invalid before marking the instance unavailable.**
+`dataweave.ts` `doCleanup()` sets `engineHandle = null` synchronously, but `initialized` only flips to `false` in the `finally` *after* `await ffi.cleanup()`. In that window `initialized === true` && `engineHandle === null`, so `run()`/`runStreaming()`/`runTransform()` pass `ensureInitialized()` and send `null` as the handle. On the C side, `napi_get_value_int64` at addon.c:724-725, 1105-1106, and 1474 does not check its return status; on a null argument it leaves `handle64` as uninitialized stack data, then uses it as the engine handle.
+
+**#2 (P1) — a Worker can tear down the isolate between stream admission and active-op registration.**
+`napi_run_script_streaming_engine` (addon.c:706) and `napi_run_script_transform_engine` (addon.c:1084) read `g_initialized` without `g_mutex`, then take the lock only later to increment `g_active_ops` (addon.c:756-758 / 1155-1157). The C globals are process-shared `static`s, so a second Node Worker can call `napi_cleanup`, hit Case 4 (last ref, `g_active_ops == 0`, addon.c:1745-1781), and synchronously tear down the isolate in that gap. The first Worker's newly spawned thread then attaches to a dead isolate.
+
+**#3 (P2) — `initialize()` during the same instance's pending cleanup is silently lost.**
+`initialize()` (dataweave.ts:77) returns early on `if (this.initialized) return;`. During the cleanup window `initialized` is still `true`, so a second `initialize()` is a no-op; when cleanup then settles it sets `initialized = false`. Net: `dw.cleanup(); dw.initialize();` leaves the instance **uninitialized** despite the explicit second call. Round 5's regression coverage used two instances, so this same-instance path was never exercised.
+
+## Design
+
+### 1. JS instance lifecycle state (findings #1 + #3)
+
+Replace `private initialized = false` with an explicit three-state field:
+
+```ts
+type LifecycleState = "uninitialized" | "ready" | "cleaning-up";
+private state: LifecycleState = "uninitialized";
+```
+
+Transitions and gates:
+
+- **`initialize()`**
+  - `ready` → no-op (unchanged idempotency).
+  - `cleaning-up` → **throw** `DataWeaveError("Cannot initialize while cleanup is in progress; await cleanup() first.")` (finding #3 — no more silent no-op).
+  - `uninitialized` → run the existing load/create-engine work; on success set `state = "ready"`. On failure the existing ref-count-release path runs and state stays `uninitialized`.
+- **`run()` / `runStreaming()` / `runTransform()`** — gated by `ensureReady()` (renamed from `ensureInitialized`): throw `DataWeaveError` unless `state === "ready"`.
+  - In `uninitialized`: existing message ("DataWeave runtime not initialized. Call initialize() first.").
+  - In `cleaning-up`: `DataWeaveError("DataWeave runtime is cleaning up; await cleanup() before running again.")` (finding #1 — the null handle can no longer reach C).
+- **`cleanup()` / `doCleanup()`** — set `state = "cleaning-up"` **synchronously before** `ffi.destroyEngine` / `ffi.cleanup` (the key ordering fix). The `finally` sets `state = "uninitialized"` on both fulfilment and rejection. The existing `cleanupPromise` coalescing (round-4 F1) is preserved: the guard becomes `if (this.state !== "ready") return;` at the top of `cleanup()` for the not-ready early return, and the `if (this.cleanupPromise) return this.cleanupPromise;` coalescing check stays.
+
+Notes:
+- The `engineHandle === null` window still exists internally, but is now unreachable by any public method because every entry point checks `state` first.
+- The `constructor` sets `state = "uninitialized"` (replacing `initialized = false`).
+
+### 2. C admission atomicity (finding #2)
+
+In both `napi_run_script_streaming_engine` and `napi_run_script_transform_engine`, fold the lifecycle check into the **same** `g_mutex` critical section that increments `g_active_ops`:
+
+```c
+uv_mutex_lock(&g_mutex);
+if (!g_initialized || g_teardown_state != TEARDOWN_NONE) {
+  uv_mutex_unlock(&g_mutex);
+  napi_throw_error(env, NULL, "Not initialized. Call initialize() first.");
+  return NULL;   // reject admission BEFORE any promise/work struct/tsfn is created
+}
+g_active_ops++;
+uv_mutex_unlock(&g_mutex);
+```
+
+This must be positioned **before** any work struct allocation, tsfn creation, promise creation, or `bridge_begin_op`, so the rejection path frees nothing (mirrors the existing top-of-function `!g_initialized` throw). The cheap top-of-function `!g_initialized` fast-path guard stays; the authoritative check is the one under the lock. Rejecting on `g_teardown_state != TEARDOWN_NONE` also prevents admitting a new op once teardown is queued/underway.
+
+**Constraint:** must not disturb round 5's `TEARDOWN_*` state machine, the deadlock-free `napi_initialize` adoption path, or the `g_active_ops` decrement-on-worker-thread invariant. Handle width stays `long long`. No `napi_reject_deferred` introduced (rejection here is a synchronous `napi_throw_error` at admission, before any deferred exists — consistent with the existing pattern).
+
+### 3. N-API handle validation, defense-in-depth (finding #1)
+
+At the three handle-read sites (addon.c:724-725, 1105-1106, 1474), check the return status of `napi_get_value_int64` (and, where cheap, the arg type via `napi_typeof`); on failure `napi_throw_error` and return `NULL` **before** allocating any work struct or reserving `g_active_ops`. Scope is deliberately these cited handle conversions only — not a blanket audit of every `napi_*` call in the file (YAGNI). This is belt-and-suspenders behind Section 1's JS guard, and the sole protection if the addon is driven directly.
+
+### 4. Testing
+
+New regression tests use the **real addon** (no `vi.mock` of `ffi`), mirroring `tests/integration/independent-engines.test.ts`, and are all **same-instance** (round 5's cross-instance coverage is exactly what let #3 slip through):
+
+1. **Finding #3 — init-during-cleanup rejects, then recovers.** `dw.initialize(); const closing = dw.cleanup(); expect(() => dw.initialize()).toThrow(DataWeaveError)` (message mentions cleanup in progress). Then `await closing; dw.initialize();` succeeds and `dw.run(...)` works.
+2. **Finding #1 — op-during-cleanup throws, no null handle to C.** `dw.initialize(); const closing = dw.cleanup(); expect(() => dw.run(...)).toThrow(DataWeaveError)`. Same for `runStreaming`/`runTransform` (their generators reject/throw on first pull). Then `await closing`.
+3. **Finding #2 — admission rejected while teardown pending.** Deterministically forcing the cross-Worker isolate-teardown race from JS is not reliably possible; instead assert the admission-rejection path (attempt a streaming/transform op while a module-level teardown is pending → throws/rejects rather than sending work to a dead isolate). Document in the test that the genuine multi-Worker TOCTOU is covered by the C-level reasoning (the check-and-reserve is now atomic under `g_mutex`), not by this test.
+
+All tests fully clean up (await the cleanup promise; idempotent final `cleanup()`) so they don't perturb sibling integration tests sharing the one process-wide isolate.
+
+## Verification
+
+- `cd native-lib/node && npm run build:addon` clean (no new warnings in the touched C regions); `npm run build` (tsc) clean.
+- `npm test` green: current baseline **866 passed / 59 skipped / 0 failed**, plus the new same-instance regression tests.
+- Optional: `./gradlew native-lib:nodeTest`, `git diff --check`.
+
+## Global Constraints
+
+- Node-binding-only. Never touch `native-lib/python/**`.
+- Never touch the legacy singleton entrypoints (`run_script`, `run_script_callback`, `run_script_input_output_callback`) or `ScriptRuntime.getInstance()`.
+- Handle width stays C `long long` everywhere.
+- Errors for run/streaming/transform APIs surface as **resolved** JSON string values or thrown `DataWeaveError`/`napi_throw_error` at admission — never `napi_reject_deferred` (absent from addon.c; do not introduce).
+- `napi_env`/`napi_ref`/`napi_deferred`/`napi_threadsafe_function` are thread-affine to the env's JS thread.
+- All shared C state (`g_initialized`, `g_active_ops`, `g_teardown_state`, `g_teardown_cancelled`, `g_ref_count`) is read/written only under `g_mutex`.
+- Preserve every round-1..5 fix: coalesced `cleanup()`, the `TEARDOWN_*` state machine and `napi_initialize` adoption path, the worker-thread `g_active_ops` decrement, guarded cross-thread `destroyEngine`, N-API allocation checks in `teardown_waiter_create`, the enqueue-failure waiter free.
+- Node vitest baseline **866 passed / 59 skipped / 0 failed** — every task leaves the suite green.
+
+## Rejected Alternatives
+
+- **Finding #3 — queue a re-init after cleanupPromise, or make `initialize()` async.** Rejected: queuing adds async state to a synchronous API and gives queued-init errors no synchronous surface; making `initialize()` async is an API break (`run()` depends on `initialize()` completing synchronously). Deterministic rejection matches the synchronous API and forces callers to `await cleanup()` — chosen.
+- **Finding #1 — return an error `ExecutionResult` from `run()` during cleanup instead of throwing.** Rejected for cross-method inconsistency: the streaming generators would still have to throw/yield-error, so behavior would diverge across the three entry points. Throwing `DataWeaveError` uniformly is symmetric with the existing not-initialized behavior and with the init-during-cleanup rejection — chosen.
+- **Finding #1 — blanket-audit and validate every `napi_*` return in addon.c.** Rejected as scope creep (YAGNI). Validate the three cited handle conversions; the JS state guard is the primary protection.
diff --git a/docs/superpowers/specs/2026-08-18-engine-lifecycle-and-worker-oom-hardening-design.md b/docs/superpowers/specs/2026-08-18-engine-lifecycle-and-worker-oom-hardening-design.md
new file mode 100644
index 00000000..92eab942
--- /dev/null
+++ b/docs/superpowers/specs/2026-08-18-engine-lifecycle-and-worker-oom-hardening-design.md
@@ -0,0 +1,116 @@
+# Engine Lifecycle & Worker-OOM Hardening — Round 9 (W-23692110)
+
+**Status:** Design approved, ready for planning.
+
+**Source review:** `docs/pr-157-follow-up-andy-code-review-9.md` (three findings, all verified against live source at commit `05f8b31`, the round-8 tip).
+
+**Scope:** `native-lib/node` only — `src/addon.c` and `src/dataweave.ts` if needed. Do **not** touch `native-lib/python/**`, the legacy singleton entrypoints, or `ScriptRuntime.getInstance()`. The Java side (`NativeLib.java`, `ScriptRuntime`) is read for context but not modified — the fix keeps the C addon from calling `fn_destroy_engine` too early rather than changing Java's registry semantics.
+
+## Problem
+
+The ninth "andy" follow-up review raised three findings. All three verified against live source and are real.
+
+### #1 (P1) — `cleanup()` can invalidate an already-admitted stream/transform before its worker begins execution
+
+`doCleanup()` (dataweave.ts:151-155) calls `ffi.destroyEngine(handle)` and only then `await ffi.cleanup()`. `napi_destroy_engine` (addon.c:1543-1546) calls `fn_destroy_engine(thread, handle)` **unconditionally and synchronously**, which removes the handle from `ScriptRuntime.REGISTRY`. A streaming/transform op that already passed admission (`g_active_ops++` at addon.c:753 / 1166) but whose background worker has not yet called `fn_run_script_callback_engine` / `fn_run_script_input_output_callback_engine` will then hit `ScriptRuntime.get(handle) == null` (NativeLib.java:457-460) and return `{"success":false,"error":"Unknown engine handle"}` instead of completing.
+
+**Why the existing deferral does not cover this:** the `in_flight`/`destroy_pending` machinery (addon.c:91-107, 259-281, 1554-1568) defers only the resolver **bridge** free, and it exists **only for resolver-backed engines** (`bridge_begin_op` increments `in_flight` only when `bridge_find != NULL`, addon.c:262). The registry removal (`fn_destroy_engine`) is never deferred, and resolver-less engines have no per-engine op accounting at all. So the registry entry is yanked regardless of in-flight ops.
+
+### #2 (P2) — output-callback / worker allocations crash on OOM
+
+Unchecked allocations in the streaming/transform worker + callback machinery dereference NULL / `strlen(NULL)` / strand worker state on OOM:
+- `streaming_write_cb` (addon.c:616-619): `malloc(sizeof chunk)` and `malloc(len)` then `memcpy`.
+- `transform_write_cb` (addon.c:985-988): same shape.
+- Worker `strdup`/sentinel sites: streaming (640, 646, 649, 666-669), transform (1072, 1081, 1084, 1097-1100).
+
+### #3 (P3) — N-API resource creation unchecked after reserving `g_active_ops`
+
+Streaming (addon.c:798-803) and transform (1243-1250) ignore the status of `napi_create_string_utf8`, `napi_create_threadsafe_function`, and `napi_create_promise`. A failed TSFN/promise leaves `w->tsfn` / `w->deferred` zeroed for the worker → crash or a stranded `g_active_ops` (teardown wedge).
+
+### Recurrence note
+
+#2 and #3 are the structurally-identical siblings of round 8's setup-allocation fix — round 8 hardened the *setup* mallocs because review #8 named those; review #9 walks to the *worker/callback* allocations and the *resource-creation* checks. Round 9 sweeps the whole class (**every fallible native op in the streaming/transform worker + callback paths**: `malloc`/`strdup`/`memcpy`, `napi_create_*`) so no structurally-identical site is left for a round 10. #1 is a distinct cross-layer lifecycle race, fixed on its own.
+
+## Design
+
+### 1. Defer registry removal until this engine's admitted ops drain (finding #1)
+
+Generalize the existing per-engine deferral so the **registry removal** (`fn_destroy_engine`) is deferred exactly like the bridge free already is, and make the per-engine in-flight count exist for **all** engines (resolver-backed and resolver-less).
+
+**Data model (user decision — extend the record to all engines):** every engine gets a per-engine record (today's `engine_bridge_t`) at `createEngine` time, carrying `handle`, `in_flight`, `destroy_pending`. The resolver-specific fields (`resolver_js`, `env`, `owner`, `results`, the env cleanup hook) remain populated **only for resolver-backed engines**; a resolver-less engine gets a record with those fields zero/NULL.
+
+**Admission (JS thread, both streaming + transform), before spawning the worker:** increment this engine's `in_flight` for **every** engine (not just `bridge_find != NULL`). Store the record pointer on `w` (`w->bridge` already exists; it now is non-NULL for all engines). The completion sentinel already calls `bridge_end_op(w->bridge, ...)`, which decrements `in_flight` and finalizes on drain — this now runs for all engines.
+
+**`napi_destroy_engine`:** under `g_mutex`, if the engine's `in_flight > 0`, set `destroy_pending = true` and **defer** the `fn_destroy_engine` registry-removal call (do not call it now); the last op to drain (`bridge_end_op` → finalize) performs `fn_destroy_engine` on completion. If `in_flight == 0`, call `fn_destroy_engine` now, as today. `fn_destroy_engine` attaches its own fresh isolate thread (addon.c:1544-1545), so it is **not** JS-thread-affine and is safe to call from the completion sentinel (which runs on the owner JS thread) or from `destroyEngine` directly.
+
+**Finalize path:** `bridge_finalize` gains responsibility for the deferred `fn_destroy_engine` call (guarded so it happens exactly once, only when it was deferred). The resolver `napi_ref` deletion + env-cleanup-hook removal stay exactly as today, only for resolver-backed engines, on the owner thread.
+
+**CRITICAL invariant to preserve — do NOT change the owner-thread destroy restriction's scope.** Today the cross-thread guard (addon.c:1530-1541) fires only for resolver-backed engines (`bridge_find != NULL`) because only they hold thread-affine `napi_ref`/cleanup-hook state. Now that resolver-less engines also have a record, the guard must still fire **only when the record has resolver state** (`resolver_js != NULL` / an env-cleanup hook was registered) — a resolver-less engine must remain destroyable from any thread, unchanged. Gate the owner check on "has resolver napi state," not on "record exists."
+
+**Ordering / correctness to confirm during review:**
+- The `in_flight++` at admission happens under `g_mutex` on the JS thread before the worker is spawned, so `destroyEngine` either sees `in_flight > 0` (defers) or the op has not yet been admitted (nothing to protect). No admitted op can have its registry entry removed before it runs.
+- `fn_destroy_engine` is called **exactly once** per handle — either the immediate path (in_flight == 0) or the deferred finalize path (last drain), never both. Guard with the same `destroy_pending`/unlink-once discipline the bridge free already uses.
+- Resolver-less engines: `bridge_end_op` now runs for them (previously `w->bridge == NULL` short-circuited). Confirm `bridge_finalize` on a resolver-less record deletes no `napi_ref` (there is none) and removes no cleanup hook (none registered), just performs the deferred `fn_destroy_engine` (if pending) and frees the record.
+- `g_active_ops` (global isolate drain) and the per-engine `in_flight` (per-handle registry drain) are **distinct** counters with distinct jobs; this round does not merge them. `g_active_ops` still gates isolate teardown; `in_flight` now gates registry removal.
+
+### 2. Worker/callback OOM → terminal error result (finding #2)
+
+Every allocation in the worker + callback machinery checks its result and fails the op cleanly, with **no `g_active_ops` / `in_flight` leak** (user decision — terminal error result, never a hung promise):
+
+- **`streaming_write_cb` / `transform_write_cb`:** if `malloc(sizeof chunk)` or `malloc(len)` returns NULL, free any partial (`free(chunk)` if the inner malloc failed) and `return -1`. Returning -1 aborts the native run cleanly (the existing contract: write callback returns non-zero → the DataWeave run stops), and the worker still produces a terminal `meta_result` and sentinel.
+- **Worker `strdup` of `meta_result`** (streaming 640/646/649, transform 1072/1081/1084): if `strdup` returns NULL, fall back to a **static** const OOM JSON string (e.g. `"{\"success\":false,\"error\":\"Out of memory\"}"`). The sentinel-drop / `call_js_write` completion path must then **not** `free()` a static pointer — introduce a flag or a convention (e.g. only `free(sentinel->buf)` when it was heap-allocated) so the static string is never freed. Simplest: keep a `static const char OOM_JSON[]` and a small helper that returns either a `strdup` or, on failure, sets a "do not free" marker. Design detail deferred to the plan; the invariant is: **the op always resolves with a terminal result and no buffer is double-freed or freed-if-static.**
+- **Sentinel `malloc`** (streaming 666-669, transform 1097-1100): if the sentinel `malloc` returns NULL, skip the `napi_call_threadsafe_function` enqueue and run the same finalize-here path the env-dead (`napi_closing`) branch already runs (release tsfn, `bridge_end_op`, free `w`, free `meta_result` if heap) — so `g_active_ops`/`in_flight` are released and nothing is stranded. `g_active_ops` is already decremented before the sentinel block, so only `bridge_end_op` + resource frees remain.
+
+The bare error string wording matches the existing worker error style (`"Empty response"`, `"Failed to attach thread"`). Keep it terse.
+
+### 3. Check N-API resource creation after the reservation (finding #3)
+
+In both `napi_run_script_streaming_engine` (798-803) and `napi_run_script_transform_engine` (1243-1250), check the status of every `napi_create_string_utf8`, `napi_create_threadsafe_function`, and `napi_create_promise`. On any failure, unwind in reverse order of what was created so far:
+- release any already-created threadsafe function(s) (`napi_release_threadsafe_function`),
+- release the per-engine `in_flight` hold if `bridge_begin_op` already ran (it runs *after* these creates today — confirm ordering; if the creates are above `bridge_begin_op`, no `in_flight` unwind is needed there),
+- release `g_active_ops` with the verbatim pattern,
+- free `w` (and its buffers),
+- `napi_throw_error(env, NULL, "...")` and return NULL.
+
+Because these creates sit **after** `g_active_ops++` but the exact position relative to `bridge_begin_op` matters, the plan must place each check so the unwind set is complete and ordered. The worker must never observe a zeroed `w->tsfn` / `w->write_tsfn` / `w->read_tsfn` / `w->deferred`.
+
+### 4. Testing
+
+**No new runtime test — all three findings are covered by C-level code reasoning.** This is the same documented limitation as rounds 6–8: the failure paths are not deterministically forceable from JS/vitest.
+
+- **#2 / #3** — the OOM and N-API-create-failure paths need allocator / N-API fault injection at the addon boundary, which does not exist. Coverage is code reasoning: every allocation/create is checked before use; every failure path unwinds `g_active_ops`, `in_flight`, and frees partials; no double-free; no hung promise.
+- **#1** — despite the spec's earlier draft, this is **not** deterministically forceable either. `ScriptRuntime.get(handle)` (`NativeLib.java:457`, `:492`) is the **first statement** of the worker's Java entrypoint — it runs *before* any read/write callback fires. So the observable "Unknown engine handle" window is the gap between op **admission** (worker spawned, promise returned) and the worker's Java **lookup**, which is entirely *before* the first chunk. A test that fires `destroyEngine` from inside a callback cannot reproduce it (the lookup already succeeded; the worker holds its `runtime` locally and completes fine even on unfixed code). The review itself calls the symptom "nondeterministic." A synchronous-fire-after-admission race-window loop would be green-on-fixed but only *probabilistically* red-on-unfixed — not the deterministic guard rounds 5's test provides — so per the round-9 decision #1 gets **no new runtime test**; its correctness is established by code reasoning against the ordering invariants below.
+
+Baseline is therefore unchanged at **878 passed / 59 skipped / 0 failed** — no new test, no regression.
+
+## Verification
+
+- `cd native-lib/node && npm run build:addon` clean (no new warnings in the touched regions); `npm run build` (tsc) clean.
+- `npm test` green: baseline **878 passed / 59 skipped / 0 failed**, unchanged (no new test — see §4).
+- `git diff --check`.
+
+## Global Constraints
+
+- Node-binding-only. Never touch `native-lib/python/**`.
+- Never touch the legacy singleton entrypoints (`run_script`, `run_script_callback`, `run_script_input_output_callback`), `dw_napi_run_script`, or `ScriptRuntime.getInstance()`. The Java side is not modified.
+- Handle width stays C `long long` everywhere.
+- Errors for run/streaming/transform APIs surface as **resolved** JSON string values (the worker's terminal `meta_result`) or a synchronous `napi_throw_error` at admission / argument validation / allocation / resource-creation failure — never `napi_reject_deferred`.
+- Allocation-failure rejections at the synchronous admission layer use `napi_throw_error` (generic Error). Worker-thread OOM produces a terminal error JSON result string (static when the copy itself failed).
+- `napi_env`/`napi_ref`/`napi_deferred`/`napi_threadsafe_function` are thread-affine to the env's JS thread. No env-affine call from the worker thread except through the existing tsfn.
+- All shared C state (`g_initialized`, `g_active_ops`, `g_teardown_state`, `g_teardown_cancelled`, `g_ref_count`, and every engine record's `in_flight`/`destroy_pending`) is read/written only under `g_mutex`.
+- The `g_active_ops` release pattern is EXACTLY, verbatim: `uv_mutex_lock(&g_mutex); g_active_ops--; uv_cond_broadcast(&g_teardown_cond); uv_mutex_unlock(&g_mutex);`
+- `fn_destroy_engine` is called **exactly once** per handle — never both the immediate and the deferred path.
+- The owner-thread `destroyEngine` restriction stays scoped to engines with resolver `napi_ref` state; resolver-less engines remain destroyable from any thread.
+- Preserve every round-1..8 fix: coalesced `cleanup()`, the JS three-state lifecycle machine, the `TEARDOWN_*` state machine and `napi_initialize` adoption path (incl. round-7's `g_teardown_cancelled` admission carve-out), the worker-thread `g_active_ops` decrement, the streaming/transform atomic admission blocks, the round-6 handle-read validations, the round-7 conversion-status checks, the round-8 setup-allocation NULL checks, guarded cross-thread `destroyEngine`, N-API allocation checks in `teardown_waiter_create`, the enqueue-failure waiter free, the resolver-bridge `in_flight`/`destroy_pending` deferral and its owner-thread `napi_ref` discipline.
+- Node vitest baseline **878 passed / 59 skipped / 0 failed** — every task leaves the suite green.
+
+## Rejected Alternatives
+
+- **#1 via a JS-side reorder in `doCleanup()` (await per-engine drain before `destroyEngine`).** Rejected: there is no per-engine "await my ops" primitive at the JS layer; streaming is an abandonable generator and `run()` is synchronous, so the class cannot reliably await outstanding ops, and `destroyEngine`'s owner-thread `napi_ref` deletion cannot move into the global `ffi.cleanup()` isolate teardown. The authoritative drain state lives in C.
+- **#1 via a separate per-handle op map alongside the resolver-only bridge.** Considered (keeps `engine_bridge_t` focused on resolver state). Rejected in favor of extending the existing record to all engines (user decision) — one structure, one deferral path, no second linked list to keep in sync with the first.
+- **#2 abort-op-without-result on worker OOM.** Rejected (user decision): leaving the op's promise unresolved is a worse failure than a terminal error result; the static-OOM-JSON terminal result keeps the op's contract (always resolves) intact.
+- **#2/#3 fixing only the cited lines.** Rejected: the per-site habit that produced the round-N-finds-the-sibling recurrence. Round 9 sweeps the whole worker/callback allocation + resource-creation class.
+- **Merging `g_active_ops` and per-engine `in_flight` into one counter.** Rejected: they gate different resources (global isolate teardown vs. per-handle registry removal) with different lifetimes; conflating them would reintroduce the class of bug rounds 5–7 fixed.
+- **Adding an allocator/N-API fault-injection hook to test #2/#3.** Rejected as test-only production surface (YAGNI), consistent with rounds 6–8.
+- **A race-window loop test for #1** (synchronous `destroyEngine` right after admission, looped N times). Rejected: green-on-fixed but only *probabilistically* red-on-unfixed, so it is not the deterministic guard round 5's deadlock test is — it would pass on the unfixed code whenever the worker's Java lookup happens to win the race. Not worth a permanently-running probabilistic test; #1's correctness rests on the ordering invariants in §Design.1 verified by code reasoning.
+- **Modifying the Java `ScriptRuntime` registry to tolerate late lookups.** Rejected as out of scope and the wrong layer — the C addon must not remove the entry early in the first place; changing Java semantics would mask the ordering bug rather than fix it.
diff --git a/docs/superpowers/specs/2026-08-18-ffi-admission-and-conversion-sweep-design.md b/docs/superpowers/specs/2026-08-18-ffi-admission-and-conversion-sweep-design.md
new file mode 100644
index 00000000..4fa2c0a1
--- /dev/null
+++ b/docs/superpowers/specs/2026-08-18-ffi-admission-and-conversion-sweep-design.md
@@ -0,0 +1,120 @@
+# FFI Admission & Conversion Sweep — Round 7 (W-23692110)
+
+**Status:** Design approved, ready for planning.
+
+**Source review:** `docs/pr-157-follow-up-andy-code-review-7.md` (three findings, all verified against live source at commit `d6cd4ec`, the round-6 tip).
+
+**Scope:** `native-lib/node` only — `src/addon.c`, `docs/external-modules.md`, and new tests under `tests/`. Do **not** touch `native-lib/python/**`.
+
+## Problem
+
+The seventh "andy" follow-up review of PR #157 raised three findings. All three were verified against live source and are real. Two of them (#1 and #2) are the **structurally-identical siblings** of sites that round 6 fixed — round 6's own final review flagged them as "Minor / pre-existing, out-of-scope," and this review escalates #1 to P1.
+
+### Root cause of the recurrence
+
+The concurrency machinery introduced across rounds 3–6 is sound; the recurrence is a **scoping habit**, not a new class of bug each round. Each round fixed exactly the sites its review named, and the next review walked to the sibling site with the same defect:
+
+- Round 6 made **streaming + transform** admission atomic under `g_mutex`, but left the **synchronous `run()`** path out because that review cited only streaming/transform. → round-7 #1.
+- Round 6 validated the **three handle-read** `napi_get_value_int64` conversions, but not the **string-length reads** or **`destroyEngine`**, because those weren't cited. → round-7 #2.
+
+Round 7 breaks the cycle by fixing both defect **classes** uniformly, so no structurally-identical site is left for a round 8 to find.
+
+### The three findings (all confirmed)
+
+**#1 (P1) — buffered `run()` is not protected from concurrent isolate teardown.**
+`napi_run_script_engine` (addon.c:1500-1534) touches the isolate (`fn_attach_thread` → `fn_run_script_engine` → `fn_detach_thread`) with only the top-of-function `if (!g_initialized)` fast-path. It never reserves `g_active_ops` under `g_mutex`. A second Node Worker performing the last `cleanup()` can observe `g_active_ops == 0` (`napi_cleanup` Case 4), tear down `g_isolate`, and leave this synchronous op attaching to / executing in a dead isolate — a use-after-free.
+
+**#2 (P2) — raw addon callers can pass malformed values that become uninitialized native inputs.**
+Multiple FFI-facing entrypoints ignore the return status of `napi_get_value_*` conversions:
+- `destroyEngine` (addon.c:1441) — ignores `napi_get_value_int64`; a non-integer handle yields an indeterminate `handle64` and could destroy an unrelated engine.
+- `run` string lengths (addon.c:1513-1514), `streaming` (addon.c:751-752), `transform` (addon.c:1146-1167) — ignore the `napi_get_value_string_utf8` size-probe status; on a non-string argument `*_len` stays uninitialized before `malloc(len + 1)` and the subsequent buffer write.
+
+**#3 (P2) — documentation examples do not await asynchronous `cleanup()`.**
+`native-lib/node/docs/external-modules.md:197-198` and `:310` call `cleanup()` without `await`, contradicting round 6's new async lifecycle contract (`cleanup(): Promise<void>`).
+
+## Design
+
+### 1. Atomic admission for synchronous `run()` (finding #1)
+
+Give `napi_run_script_engine` the same mutex-protected lifecycle admission that streaming/transform got in round 6, but reserve **late** — immediately before `fn_attach_thread`, not at the top of the function.
+
+```c
+uv_mutex_lock(&g_mutex);
+if (!g_initialized || g_teardown_state != TEARDOWN_NONE) {
+  uv_mutex_unlock(&g_mutex);
+  free(script); free(inputs);
+  napi_throw_error(env, NULL, "Not initialized. Call initialize() first.");
+  return NULL;
+}
+g_active_ops++;
+uv_mutex_unlock(&g_mutex);
+
+void* thread = NULL;
+if (fn_attach_thread(g_isolate, &thread) != 0) {
+  uv_mutex_lock(&g_mutex); g_active_ops--; uv_cond_broadcast(&g_teardown_cond); uv_mutex_unlock(&g_mutex);
+  free(script); free(inputs);
+  napi_throw_error(env, NULL, "Failed to attach thread");
+  return NULL;
+}
+
+char* result = (char*)fn_run_script_engine(thread, handle, script, inputs);
+// ... existing resolver_results_free_all, strdup, fn_free_cstring, fn_detach_thread, free(script/inputs) ...
+
+uv_mutex_lock(&g_mutex); g_active_ops--; uv_cond_broadcast(&g_teardown_cond); uv_mutex_unlock(&g_mutex);
+```
+
+**Why late, not early (unlike streaming/transform):** the string `malloc`s and argument extraction don't touch the isolate, so the reservation only needs to span `attach → detach`. Reserving just before attach yields exactly **two** unwind sites — the attach-failure branch and normal completion — instead of additionally having to unwind the OOM/allocation path. `run()` is fully synchronous on the JS thread, so both the reservation and the release happen inline; there is no worker thread. The `uv_cond_broadcast(&g_teardown_cond)` on decrement is what wakes a `teardown_waiter_thread_fn` blocked on `g_active_ops > 0`, matching how the streaming/transform worker threads decrement.
+
+**Ordering vs. Part 2:** the string-length checks (Part 2) run before the reservation, so a malformed-input throw there returns before `g_active_ops++` and needs no unwind. The reservation block is placed after the buffers are populated and before attach.
+
+**Keep the top-of-function `!g_initialized` fast-path** as a cheap early reject; the authoritative check is the one under the lock. The already-validated handle `int64` read (round 6, addon.c:1505-1510) is unchanged.
+
+### 2. Uniform `napi_get_value_*` status checks (finding #2 → whole class)
+
+Every FFI-facing entrypoint checks the status of **every** `napi_get_value_*` conversion and throws via `napi_throw_error` (consistent with all existing throws in the file — round-6 handle validation, "Not initialized", "OOM") **before** using the converted value.
+
+Guiding invariant: **no converted value is read before its conversion status is confirmed `napi_ok`, and no throw leaves `g_active_ops` reserved.**
+
+Sites:
+- **`destroyEngine` (addon.c:1441):** check `napi_get_value_int64`; throw "destroyEngine: handle must be an integer" before any registry lookup or destroy. No `g_active_ops` on this path.
+- **`run` (addon.c:1513-1519):** check both `napi_get_value_string_utf8` size probes; throw before `malloc(len + 1)`. These checks run **before** the Part 1 reservation, so no unwind needed. Also check the fill-phase `napi_get_value_string_utf8` calls.
+- **`streaming` (addon.c:751-759):** check both size probes and both fills. A throw here happens **after** `g_active_ops++` (round-6 admission block sits above), so each must `g_active_ops--; uv_cond_broadcast(&g_teardown_cond);` under `g_mutex` and free any already-allocated buffers before returning.
+- **`transform` (addon.c:1146-1167):** same — check every size probe and fill, and the `napi_typeof` for `argv[5]`; throw-after-reservation paths must unwind `g_active_ops` and free partial allocations.
+
+The already-validated handle `int64` reads at the streaming/transform sites (round 6) are left as-is. Scope is the FFI-facing entrypoints' conversions — not a blanket audit of unrelated `napi_*` calls (YAGNI).
+
+### 3. Docs await `cleanup()` (finding #3)
+
+In `native-lib/node/docs/external-modules.md`, make the example functions that call `cleanup()` `async` and `await cleanup()` in their `finally` blocks (lines 197-198, 310). Sweep the whole document for any other bare `cleanup()` call and fix consistently.
+
+### 4. Testing
+
+New regression tests use the **real addon** (no `vi.mock` of `ffi`), mirroring `tests/integration/handle-validation.test.ts` and `admission-during-teardown.test.ts`, and all fully clean up (balance every `ffi.initialize()` with `await ffi.cleanup()`) so they do not perturb the shared process-wide isolate for sibling integration tests.
+
+1. **Finding #1 — `run()` admission.** Drive raw `ffi.runScriptEngine` and assert the admission-rejection path: a `run()` attempted while teardown is pending throws rather than attaching to a dead isolate. Document in the test that the genuine cross-Worker TOCTOU is not reliably forceable from JS (same limitation as round-6 #2); the C-level reasoning — check-and-reserve is now atomic under `g_mutex` on the `run()` path — is what covers the race.
+2. **Finding #2 — malformed inputs throw, nothing allocated on an uninitialized length.** Raw-`ffi` calls: a non-integer handle to `destroyEngine`; non-string `script`/`inputs` to `run`, `runStreaming`, `runTransform`. Each throws synchronously. Extends the `handle-validation.test.ts` pattern.
+3. **Finding #3 — docs only.** No automated test; verified by inspection.
+
+## Verification
+
+- `cd native-lib/node && npm run build:addon` clean (no new warnings in the touched C regions); `npm run build` (tsc) clean.
+- `npm test` green: current baseline **873 passed / 59 skipped / 0 failed**, plus the new regression tests.
+- `git diff --check`.
+
+## Global Constraints
+
+- Node-binding-only. Never touch `native-lib/python/**`.
+- Never touch the legacy singleton entrypoints (`run_script`, `run_script_callback`, `run_script_input_output_callback`) or `ScriptRuntime.getInstance()`.
+- Handle width stays C `long long` everywhere.
+- Errors for run/streaming/transform APIs surface as **resolved** JSON string values or a synchronous `napi_throw_error` at admission / argument validation — never `napi_reject_deferred` (absent from addon.c; do not introduce).
+- `napi_env`/`napi_ref`/`napi_deferred`/`napi_threadsafe_function` are thread-affine to the env's JS thread.
+- All shared C state (`g_initialized`, `g_active_ops`, `g_teardown_state`, `g_teardown_cancelled`, `g_ref_count`) is read/written only under `g_mutex`. (The cheap top-of-function `!g_initialized` fast-path read is a benign optimization; the authoritative check is under the lock.)
+- Preserve every round-1..6 fix: coalesced `cleanup()`, the JS three-state lifecycle machine, the `TEARDOWN_*` state machine and `napi_initialize` adoption path, the worker-thread `g_active_ops` decrement, the streaming/transform atomic admission blocks, the round-6 handle-read validations, guarded cross-thread `destroyEngine`, N-API allocation checks in `teardown_waiter_create`, the enqueue-failure waiter free.
+- Node vitest baseline **873 passed / 59 skipped / 0 failed** — every task leaves the suite green.
+
+## Rejected Alternatives
+
+- **Finding #1 — reserve early (top of function) like streaming/transform.** Rejected: the string `malloc`s and argument extraction don't touch the isolate, so an early reservation would force the OOM/allocation-failure path to also unwind `g_active_ops`, adding a third unwind site for no safety benefit. Late reservation (just before attach) spans exactly the isolate-touching window with two unwind sites.
+- **Finding #2 — `napi_throw_type_error` (TypeError).** Considered because the review says "JavaScript type error" and TypeError is the N-API convention for wrong-type args. Rejected in favor of `napi_throw_error` (generic Error) for consistency with every existing throw in addon.c; the message text conveys the type problem. (User decision.)
+- **Finding #2 — blanket-audit every `napi_*` call in addon.c.** Rejected as scope creep (YAGNI). Sweep the conversions in the FFI-facing entrypoints — the defect class the review names — not unrelated N-API calls.
+- **Finding #1 — only fix the exact cited lines without sweeping `run()`'s siblings.** Rejected: this is the very habit that produced the round-N-finds-the-sibling recurrence. Round 7 covers both defect classes uniformly.
diff --git a/docs/superpowers/specs/2026-08-18-oom-safe-streaming-transform-setup-design.md b/docs/superpowers/specs/2026-08-18-oom-safe-streaming-transform-setup-design.md
new file mode 100644
index 00000000..855f9fdc
--- /dev/null
+++ b/docs/superpowers/specs/2026-08-18-oom-safe-streaming-transform-setup-design.md
@@ -0,0 +1,127 @@
+# OOM-Safe Allocation in Streaming/Transform Setup — Round 8 (W-23692110)
+
+**Status:** Design approved, ready for planning.
+
+**Source review:** `docs/pr-157-follow-up-andy-code-review-8.md` (one finding, P1, verified against live source at commit `3622179`, the round-7 tip).
+
+**Scope:** `native-lib/node` only — `src/addon.c`, functions `napi_run_script_streaming_engine` and `napi_run_script_transform_engine`. Do **not** touch `native-lib/python/**` or the legacy singleton `dw_napi_run_script`.
+
+## Problem
+
+The eighth "andy" follow-up review of PR #157 raised one finding (escalated to P1). It was verified against live source and is real.
+
+**Finding (P1) — OOM in streaming or transform setup can crash the process and strand active-operation state.**
+
+Both `napi_run_script_streaming_engine` (addon.c:770-780) and `napi_run_script_transform_engine` (addon.c:1174-1207) reserve `g_active_ops` (streaming at :753, transform at :1166) and then, **after** the reservation, allocate a work struct and its string buffers and immediately use them without checking for allocation failure:
+
+- Streaming: `struct streaming_work* w = calloc(...)` (:770) is dereferenced at `w->handle` (:771); `w->script = malloc(...)` / `w->inputs_json = malloc(...)` (:772-773) are passed to `napi_get_value_string_utf8` (:774-775) with no NULL check.
+- Transform: `struct transform_work* w = calloc(...)` (:1174) is dereferenced at `w->handle` (:1176); each `w->field = malloc(len + 1)` (:1187, :1191, :1195, :1199, :1206) is passed to the fill `napi_get_value_string_utf8` with no NULL check.
+
+If an allocation fails, the NULL dereference is a SIGSEGV that crashes the host Node process (not a catchable JS error). Because both sites sit *after* the `g_active_ops` reservation, the reservation is also never released — though in practice the segfault terminates the process first, so the crash is the dominant harm; releasing the reservation is the correct behavior on the (theoretical) non-crashing path and keeps the invariant clean.
+
+### History / context (not a new defect)
+
+This is the same gap logged as item 6 in `docs/ga-cleanup-backlog.md` and flagged as Minor/deferred by both the round-7 task review and the round-7 final whole-branch review (OOM-only, out of scope for round 7's conversion-*status* sweep). The eighth review escalates it from Minor to P1. It is a known deferred item re-prioritized, not a newly discovered class.
+
+The fix pattern already exists in the same file: `napi_run_script_engine` checks its `malloc` results and throws `"OOM"` (addon.c ~1568). Streaming/transform simply never received the same treatment. `dw_napi_run_script` (the legacy singleton) has the identical gap but is off-limits by the Global Constraints.
+
+## Design
+
+Add allocation-failure checks at both sites, mirroring the existing `napi_run_script_engine` OOM pattern, so **no allocation result is dereferenced before its NULL check, and no OOM path leaves `g_active_ops` reserved or a partial `w` leaked.**
+
+### 1. Streaming (`napi_run_script_streaming_engine`)
+
+Immediately after `struct streaming_work* w = calloc(1, sizeof(struct streaming_work));` and **before** `w->handle = ...`, check `w == NULL`:
+
+```c
+struct streaming_work* w = calloc(1, sizeof(struct streaming_work));
+if (w == NULL) {
+  uv_mutex_lock(&g_mutex); g_active_ops--; uv_cond_broadcast(&g_teardown_cond); uv_mutex_unlock(&g_mutex);
+  napi_throw_error(env, NULL, "OOM");
+  return NULL;
+}
+w->handle = (long long)handle64;
+w->script = malloc(script_len + 1);
+w->inputs_json = malloc(inputs_len + 1);
+if (w->script == NULL || w->inputs_json == NULL) {
+  free(w->script); free(w->inputs_json); free(w);
+  uv_mutex_lock(&g_mutex); g_active_ops--; uv_cond_broadcast(&g_teardown_cond); uv_mutex_unlock(&g_mutex);
+  napi_throw_error(env, NULL, "OOM");
+  return NULL;
+}
+if (napi_get_value_string_utf8(env, argv[1], w->script, script_len + 1, NULL) != napi_ok ||
+    napi_get_value_string_utf8(env, argv[2], w->inputs_json, inputs_len + 1, NULL) != napi_ok) {
+  free(w->script); free(w->inputs_json); free(w);
+  uv_mutex_lock(&g_mutex); g_active_ops--; uv_cond_broadcast(&g_teardown_cond); uv_mutex_unlock(&g_mutex);
+  napi_throw_error(env, NULL, "runScriptStreamingEngine: failed to read script/inputsJson");
+  return NULL;
+}
+```
+
+- The `w == NULL` branch must **not** free `w->script`/`w->inputs_json` (w is NULL — those dereferences would themselves crash); it frees nothing and unwinds.
+- The combined `w->script == NULL || w->inputs_json == NULL` guard reuses the existing free-set (`free(w->script); free(w->inputs_json); free(w);` — all `free(NULL)`-safe since `calloc` zeroed `w` and a failed `malloc` returns NULL) and the verbatim `g_active_ops` unwind, sitting **before** the existing fill-status check.
+
+### 2. Transform (`napi_run_script_transform_engine`)
+
+Add a `w == NULL` check immediately after `calloc` and before `w->handle`, then a NULL check after each `malloc` via the existing `TRANSFORM_FAIL` macro (which already frees all five char* fields + `w` and unwinds `g_active_ops`):
+
+```c
+struct transform_work* w = calloc(1, sizeof(struct transform_work));
+if (w == NULL) {
+  uv_mutex_lock(&g_mutex); g_active_ops--; uv_cond_broadcast(&g_teardown_cond); uv_mutex_unlock(&g_mutex);
+  napi_throw_error(env, NULL, "OOM");
+  return NULL;
+}
+size_t len;
+w->handle = (long long)handle64;
+
+#define TRANSFORM_FAIL(msg) do { ... } while (0)   // unchanged
+
+if (napi_get_value_string_utf8(env, argv[1], NULL, 0, &len) != napi_ok) TRANSFORM_FAIL("runScriptTransformEngine: script must be a string");
+w->script = malloc(len + 1);
+if (w->script == NULL) TRANSFORM_FAIL("OOM");
+if (napi_get_value_string_utf8(env, argv[1], w->script, len + 1, NULL) != napi_ok) TRANSFORM_FAIL("runScriptTransformEngine: failed to read script");
+```
+
+…and the same `if (w->field == NULL) TRANSFORM_FAIL("OOM");` line after each of `w->inputs_json`, `w->input_name`, `w->input_mime_type`, and `w->input_charset` mallocs, placed **before** the corresponding fill `napi_get_value_string_utf8`.
+
+- The `w == NULL` branch is a standalone unwind (it cannot use `TRANSFORM_FAIL`, which dereferences `w`).
+- Each per-field NULL check uses `TRANSFORM_FAIL("OOM")`; because `calloc` zeroed `w` and any not-yet-reached field is still NULL, the macro's free-set is `free(NULL)`-safe for the unreached fields and frees the successfully-allocated ones exactly once.
+
+### 3. Error message
+
+Bare `napi_throw_error(env, NULL, "OOM")` for every allocation-failure throw, identical to `napi_run_script_engine`'s existing pattern. (User decision — maximum consistency with the current file over the descriptive per-entrypoint style of the conversion-status throws.) The existing conversion-status and read-failure messages in these functions are unchanged.
+
+### 4. Testing
+
+`malloc`/`calloc` failure is not deterministically forceable from JS/vitest (no allocator-injection hook at the addon boundary), the same limitation documented for the round-6/7 cross-Worker TOCTOU. So this round adds **no new runtime test**; coverage is:
+
+- C-level code reasoning: every allocation result is NULL-checked before any dereference; every OOM path unwinds `g_active_ops` with the verbatim pattern and frees any partial `w` with no double-free.
+- The full Node vitest suite stays green at **878 passed / 59 skipped / 0 failed** with no regression (the OOM branches are unreachable under normal allocation, so existing behavior is unchanged).
+
+## Verification
+
+- `cd native-lib/node && npm run build:addon` clean (no new warnings in the touched regions); `npm run build` (tsc) clean.
+- `npm test` green: **878 passed / 59 skipped / 0 failed** (unchanged — no new test, no regression).
+- `git diff --check`.
+
+## Global Constraints
+
+- Node-binding-only. Never touch `native-lib/python/**`.
+- Never touch the legacy singleton entrypoints (`run_script`, `run_script_callback`, `run_script_input_output_callback`), `dw_napi_run_script`, or `ScriptRuntime.getInstance()`.
+- Handle width stays C `long long` everywhere.
+- Errors for run/streaming/transform APIs surface as **resolved** JSON string values or a synchronous `napi_throw_error` at admission / argument validation / allocation failure — never `napi_reject_deferred` (absent from addon.c; do not introduce).
+- Allocation-failure rejections use `napi_throw_error` (generic Error) with the bare message `"OOM"`, matching `napi_run_script_engine`.
+- `napi_env`/`napi_ref`/`napi_deferred`/`napi_threadsafe_function` are thread-affine to the env's JS thread.
+- All shared C state (`g_initialized`, `g_active_ops`, `g_teardown_state`, `g_teardown_cancelled`, `g_ref_count`) is read/written only under `g_mutex`. (The cheap top-of-function `!g_initialized` fast-path read is a benign optimization.)
+- The `g_active_ops` release pattern is EXACTLY, verbatim: `uv_mutex_lock(&g_mutex); g_active_ops--; uv_cond_broadcast(&g_teardown_cond); uv_mutex_unlock(&g_mutex);` (matches the worker-thread decrement and every round-6/7 unwind site).
+- Preserve every round-1..7 fix: coalesced `cleanup()`, the JS three-state lifecycle machine, the `TEARDOWN_*` state machine and `napi_initialize` adoption path (including round-7's `g_teardown_cancelled` admission carve-out), the worker-thread `g_active_ops` decrement, the streaming/transform atomic admission blocks, the round-6 handle-read validations, the round-7 conversion-status checks, guarded cross-thread `destroyEngine`, N-API allocation checks in `teardown_waiter_create`, the enqueue-failure waiter free.
+- Node vitest baseline **878 passed / 59 skipped / 0 failed** — every task leaves the suite green.
+
+## Rejected Alternatives
+
+- **Descriptive per-entrypoint OOM messages** (`"runScriptStreamingEngine: out of memory"`). Considered for parity with the round-7 conversion-check message style in these same functions. Rejected in favor of bare `"OOM"` for consistency with `napi_run_script_engine`'s existing allocation-failure throw. (User decision.)
+- **Abort/`ENOMEM`-style hard failure instead of a throwable error.** Rejected: a library must not take down the host process on a recoverable condition; surfacing a catchable N-API error is the contract used everywhere else in these entrypoints.
+- **Also fixing `dw_napi_run_script`'s identical gap.** Rejected as out of scope — it is a forbidden legacy singleton entrypoint per the Global Constraints. Noted separately; not part of this round.
+- **Adding a fault-injection test hook to force `malloc` failure.** Rejected as scope creep / test-only production surface (YAGNI). The OOM branches are covered by code reasoning, consistent with how the round-6/7 non-forceable paths were handled.
+- **Retrofitting the whole file's allocations.** Rejected — this round fixes the two P1 sites the review names; a blanket allocation audit is out of scope (the same class-vs-blanket boundary drawn in round 7).
diff --git a/docs/superpowers/specs/2026-08-19-engine-pin-and-cleanup-hook-hardening-design.md b/docs/superpowers/specs/2026-08-19-engine-pin-and-cleanup-hook-hardening-design.md
new file mode 100644
index 00000000..fb933c9e
--- /dev/null
+++ b/docs/superpowers/specs/2026-08-19-engine-pin-and-cleanup-hook-hardening-design.md
@@ -0,0 +1,147 @@
+# Engine-Pin & All-Engines-Cleanup Hardening — Round 11 (W-23692110)
+
+**Status:** Design approved, ready for planning.
+
+**Source reviews:** `docs/pr-157-follow-up-andy-code-review-11.md` (2 findings) and `docs/pr-157-follow-up-code-review-2.md` (6 findings). All overlapping; deduplicated into 6 work items below. Verified against live source at commit `50b2930` (round-10 tip).
+
+**Scope:** `native-lib/node` only — `src/addon.c`, `src/dataweave.ts`, and Node integration tests under `tests/`. Do **not** touch `native-lib/python/**`, the legacy singleton entrypoints (`run_script`, `run_script_callback`, `run_script_input_output_callback`), `dw_napi_run_script`, or `ScriptRuntime.getInstance()`. The Java side (`NativeLib.java`, `ScriptRuntime`) is read for context but not modified.
+
+## Problem
+
+The 11th "andy" review and a second general code review together raise 7 findings; 6 are real and one (the C ABI break) is a documented-by-design decision, not a code change.
+
+### #1 (P1) — Resolver-less engines leak on Worker exit (no env cleanup hook)
+
+`napi_create_engine` (resolver-less, `addon.c:1644`) links a per-engine record into `g_bridges` but registers **no** `napi_add_env_cleanup_hook`; only `napi_create_engine_with_resolver` does (`addon.c:1695`). A Worker (or the main thread) that creates a resolver-less `DataWeave` instance and terminates without calling `destroyEngine()` strands: the native `engine_bridge_t` record, the Java `ScriptRuntime` registry entry, and the native-library reference (`g_ref_count` never decremented for that instance). Repeated Worker create/terminate cycles leak engines and prevent isolate teardown.
+
+### #2 (P1) — Streaming/transform admission reserves the isolate before pinning the engine
+
+`napi_run_script_streaming_engine` reserves `g_active_ops++` at `addon.c:841` but does not pin the engine (`bridge_begin_op`) until `addon.c:925` — a wide window (arg extraction, `w`/tsfn/promise allocation) in which a concurrent Worker's `destroyEngine(handle)` observes `in_flight == 0`, unlinks and frees the bridge, and removes the Java registry entry. The already-admitted op then spawns its worker with `w->bridge` pointing at freed memory (or NULL after the fact) and can fail with "Unknown engine handle" or dereference the freed bridge in `resolve_module_callback`. `napi_run_script_transform_engine` has the identical shape (`g_active_ops++` at `addon.c:1324`, `bridge_begin_op` at `addon.c:1429`).
+
+### #3 (P1) — Synchronous `runScriptEngine` never pins the engine at all
+
+`napi_run_script_engine` (`addon.c:1791-1879`) increments `g_active_ops` (`:1847`) to protect the isolate but never calls `bridge_begin_op`. A concurrent Worker can `destroyEngine(handle)` while this synchronous call is attaching to Graal or executing `fn_run_script_engine` (`:1858`); for a resolver-backed engine that frees the bridge Java still holds as the resolver ctx → `resolve_module_callback` dereferences freed memory. `g_active_ops` gates only the *global isolate*, not the *per-engine* record.
+
+### #4 (documented, not a code change) — dwlib C ABI break
+
+This branch removes the exported `run_script_with_resolver` / `run_script_callback_with_resolver` / `run_script_input_output_callback_with_resolver` entrypoints (present on master) and replaces them with `create_engine` / `create_engine_with_resolver` / `destroy_engine` / `run_script_engine` / `run_script_callback_engine` / `run_script_input_output_callback_engine`, and inserts a `ctx` parameter into the `ResolveModuleCallback` signature. The three legacy singleton entrypoints (`run_script`, `run_script_callback`, `run_script_input_output_callback`) are preserved. This is the intended multi-engine redesign; dwlib is consumed by this repo's own Python and Node bindings in lockstep. **Decision (user):** document the break in the PR/spec; do NOT add compatibility shims. No code change in this round.
+
+### #5 (Medium) — Process exit listeners accumulate across singleton re-creation
+
+`getGlobalInstance` (`dataweave.ts:289-304`) attaches a `beforeExit` and an `exit` listener every time it (re)creates `globalInstance`; the module-level `cleanup()` (`:341-353`) nulls the singleton but never removes those listeners. Repeated init→cleanup→reinit cycles accumulate two listeners per cycle and eventually emit Node's `MaxListenersExceededWarning`.
+
+### #6 (Medium) — Unknown-handle coverage does not exercise the native entrypoints
+
+`ScriptRuntimeTest.unknownEngineHandleProducesExactErrorJson` (`ScriptRuntimeTest.java:677-683`) only asserts on the `UNKNOWN_ENGINE_HANDLE_JSON` constant and `ScriptRuntime.get`; it deliberately cannot invoke the `@CEntryPoint` methods (GraalVM word types don't box in a hosted JVM). So no test drives the `*_engine` entrypoints against unknown/destroyed handles through the real addon, nor exercises the cross-Worker run-vs-destroy race in #2/#3.
+
+## Design
+
+### 1. Register an env cleanup hook for every engine + extend the owner-thread destroy guard (finding #1)
+
+**Cleanup hook for all engines.** In `napi_create_engine`, store `rec->env = env` and register `napi_add_env_cleanup_hook(env, bridge_env_cleanup, rec)` — exactly as `napi_create_engine_with_resolver` already does. `bridge_env_cleanup` and `bridge_finalize` already handle a resolver-less record correctly: `resolver_js == NULL` → skip `napi_delete_reference`, still unlink from `g_bridges`, remove the Java registry entry (round-10 `do_registry_remove=true`), and free the record. So the round-10 registry-removal path now also reclaims resolver-less engines abandoned by a terminating env. `rec->owner` is already recorded (`addon.c:1643`).
+
+**Owner-thread destroy guard extends to all engines (approved contract change).** Registering a cleanup hook gives every engine env-affine state: the hook is bound to its creating env, and `napi_remove_env_cleanup_hook` (called by `destroyEngine` before an early free, `addon.c:1738`) is only valid on that owner env/thread. Today the cross-thread guard in `napi_destroy_engine` (`addon.c:1703`) fires only when `owned->resolver_js != NULL`. Change it to fire for **any** record (`owned != NULL`), so a resolver-less engine is also only destroyable from its creating thread.
+
+- **Why this is safe:** every JS `DataWeave` instance is constructed and destroyed on a single thread (its owning env), so the guard never rejects a legitimate call. This reverses the round-9 invariant "resolver-less engines remain destroyable from any thread," which was only ever exercised by the (now-closed) case of a resolver-less engine having no env-affine state.
+- **Why the alternative is worse:** leaving the guard resolver-only while registering a hook means a cross-thread `destroyEngine` would either skip `napi_remove_env_cleanup_hook` (leaving Node holding a hook pointing at a freed record → UAF at env teardown) or call it cross-thread (undefined behavior). Extending the guard is the correct closure.
+
+Update the guard's comment block (`addon.c:1683-1700`) to state the guard now keys on "a record exists" because every engine carries an env cleanup hook, not just resolver `napi_ref` state.
+
+**`bridge_finalize` napi_ref deletion stays resolver-gated** (`addon.c:237`: `resolver_js != NULL && env != NULL`) — a resolver-less record has no ref to delete; only the hook registration and the owner guard change.
+
+### 2. Fold engine lookup + `in_flight++` into the locked admission transaction (findings #2, #3)
+
+Introduce a locked-admission variant so the per-engine pin happens in the **same** critical section as the `g_active_ops` reservation and lifecycle check, before any window a concurrent `destroyEngine` could use.
+
+**New helper** (`addon.c`, near `bridge_begin_op`):
+```c
+// Increment this engine's in_flight while g_mutex is ALREADY held (admission
+// transaction). Caller must hold g_mutex. Returns the record (NULL if unknown
+// handle -- nothing to pin, worker will surface "Unknown engine handle").
+static engine_bridge_t* bridge_begin_op_locked(long long handle) {
+    engine_bridge_t* b = bridge_find(handle);
+    if (b != NULL) b->in_flight++;
+    return b;
+}
+```
+`bridge_begin_op` stays for callers that need the self-locking form; internally it becomes `lock; b = bridge_begin_op_locked(handle); unlock; return b;`.
+
+**Streaming / transform:** in the admission critical section (`addon.c:835-842` / `1318-1325`), after `g_active_ops++`, also call `w->bridge = bridge_begin_op_locked(handle64)` **before** unlocking, and delete the later standalone `bridge_begin_op` call (`:925` / `:1429`). Every existing failure path between admission and the worker spawn (conversion errors, OOM, tsfn/promise creation failures, `spawn_rc != 0`) must now **also** release the pin. Because those paths currently only do the `g_active_ops--` release, each must additionally call `bridge_end_op(w->bridge, /*env_still_alive=*/true)` (the env is live on the JS admission thread) to balance `in_flight` and finalize if a concurrent destroy is now pending. The completion sentinel path is unchanged — it already calls `bridge_end_op`.
+
+- **Ordering:** with the pin taken under the same lock as the admission check, a concurrent `destroyEngine` either runs entirely before admission (then `bridge_find` in admission returns the record only if not yet destroyed; if already destroyed, the record is gone and the worker surfaces "Unknown engine handle" — no freed access) or entirely after (then `in_flight > 0`, so destroy defers per round-9/10). There is no interleaving where an admitted op observes a freed bridge.
+- **Unwind completeness:** the plan must enumerate every early-return between the locked admission and the spawn and add the `bridge_end_op` release, mirroring how each already releases `g_active_ops`. A pin leaked here would wedge `destroyEngine` (never drains) exactly like a leaked `g_active_ops` wedges teardown.
+
+**Synchronous `runScriptEngine`:** pin the engine for the isolate-touching window. Because this path reserves `g_active_ops` *late* (`addon.c:1840-1848`, after arg extraction), take the pin in that same critical section:
+```c
+uv_mutex_lock(&g_mutex);
+if (!g_initialized || (g_teardown_state != TEARDOWN_NONE && !g_teardown_cancelled)) { ... release, throw ... }
+g_active_ops++;
+engine_bridge_t* bridge = bridge_begin_op_locked(handle);
+uv_mutex_unlock(&g_mutex);
+```
+Then release the pin in **both** the attach-failure path and normal completion, alongside the existing `g_active_ops--`. The current post-run `bridge_find` + `resolver_results_free_all` (`addon.c:1860-1863`) uses the pinned `bridge` directly (no second lookup needed; the pin kept it alive). Release ordering at completion: after `resolver_results_free_all` and detach, call `bridge_end_op(bridge, /*env_still_alive=*/true)` — which may finalize a deferred destroy — then the existing `g_active_ops--` broadcast. `bridge_end_op` handles `NULL` (unknown handle) as a no-op.
+
+- **Sync-path note:** unlike streaming/transform there is no background thread, so `env_still_alive` is always true here (the JS thread runs the whole op). An unknown handle (`bridge == NULL`) still runs `fn_run_script_engine`, which returns the resolved "Unknown engine handle" JSON — behavior unchanged.
+
+### 3. Register process exit listeners exactly once (finding #5)
+
+Move the `beforeExit`/`exit` registration out of `getGlobalInstance` so it runs once per module, guarded by a module-scoped `let exitHooksRegistered = false` that is **never reset** (unlike `cleanupStarted`). The listeners already tolerate a null `globalInstance`: `cleanup()` no-ops when `globalInstance` is null, and `cleanupStarted` still coalesces `beforeExit`/`exit` for a given shutdown. So one registration covers every current and future revived singleton, and init→cleanup→reinit cycles no longer accumulate listeners.
+
+```ts
+let exitHooksRegistered = false;
+function registerExitHooksOnce(): void {
+  if (exitHooksRegistered) return;
+  exitHooksRegistered = true;
+  process.on("beforeExit", async () => { if (cleanupStarted) return; cleanupStarted = true; await cleanup(); });
+  process.on("exit", () => { if (cleanupStarted) return; cleanup(); });
+}
+```
+`getGlobalInstance` calls `registerExitHooksOnce()` after `globalInstance.initialize()`. Update the doc comment (`dataweave.ts:267-287`) to say the hooks are registered once for the process, not per singleton.
+
+### 4. Real *_engine unknown/destroyed-handle + run-vs-destroy tests (finding #6)
+
+Add **Node integration tests** (real addon, `vi.mock` of `ffi` is forbidden — mirror `tests/integration/independent-engines.test.ts`):
+
+- **Unknown / destroyed handle envelope:** for each of `runScriptEngine` (sync), `runScriptStreamingEngine`, `runScriptTransformEngine`, invoke against (a) a never-registered handle and (b) a handle whose engine was `destroyEngine`'d, and assert the result is the terminal `{"success":false,"error":"Unknown engine handle"}` envelope (resolved, not thrown for the async ops; the sync op returns the JSON string) and that the process does not crash and no C string leaks (the op resolves/returns cleanly).
+- **Cross-Worker run-vs-destroy (findings #2/#3):** spin a `worker_threads` Worker that creates an engine and runs a stream/transform, and from another context destroy/cleanup during the admission window, asserting no crash and a clean terminal result. Note in the test file that this race is **not** deterministically forceable at a fixed interleaving (same limitation rounds 5–10 documented); the test is a best-effort probabilistic guard (loop N iterations) that is green on fixed code and cannot false-fail on it. If a deterministic hook proves infeasible, the test still asserts the unknown/destroyed-handle envelope contract, which is deterministic, and the concurrency correctness rests on the code reasoning in §2.
+
+These raise the vitest baseline above 878. The plan sets the exact new counts.
+
+## Testing
+
+- New Node integration tests per §4 (deterministic envelope assertions + best-effort race guard).
+- No Java test change (the `@CEntryPoint` hosted-JVM limitation is real; coverage moves to the Node integration layer against the real addon, which is the correct layer).
+- Findings #1/#2/#3 lifecycle correctness that is not deterministically forceable is covered by code reasoning against the invariants in §Design (same documented posture as rounds 5–10).
+
+## Verification
+
+- `cd native-lib/node && npm run build:addon` clean (no new warnings in touched regions); `npm run build` (tsc) clean.
+- `npm test` green at the new baseline (set in the plan; ≥ 878 + new tests).
+- `git diff --check`.
+
+## Global Constraints
+
+- Node-binding-only. Never touch `native-lib/python/**`.
+- Never touch the legacy singleton entrypoints (`run_script`, `run_script_callback`, `run_script_input_output_callback`), `dw_napi_run_script`, or `ScriptRuntime.getInstance()`. The Java side is not modified.
+- Handle width stays C `long long` everywhere.
+- Errors for run/streaming/transform APIs surface as **resolved** JSON string values (async) or a synchronous `napi_throw_error` (admission/arg/alloc/resource failures) — never `napi_reject_deferred`.
+- `napi_env`/`napi_ref`/`napi_deferred`/`napi_threadsafe_function` are thread-affine to the env's JS thread.
+- All shared C state (`g_initialized`, `g_active_ops`, `g_teardown_state`, `g_teardown_cancelled`, `g_ref_count`, every engine record's `in_flight`/`destroy_pending`/`deferred_registry_remove`) is read/written only under `g_mutex`, except the documented lock-free `g_isolate` NULL-check in `bridge_finalize`.
+- The `g_active_ops` release pattern is EXACTLY, verbatim: `uv_mutex_lock(&g_mutex); g_active_ops--; uv_cond_broadcast(&g_teardown_cond); uv_mutex_unlock(&g_mutex);`
+- `fn_destroy_engine` is called **exactly once** per handle.
+- Every engine now carries an env cleanup hook, so the owner-thread `destroyEngine` guard keys on "a record exists," not on resolver `napi_ref` state. `bridge_finalize`'s `napi_ref` deletion stays resolver-gated.
+- Per-engine `in_flight` and global `g_active_ops` stay **distinct** counters (per-handle registry drain vs. global isolate teardown) — not merged.
+- Preserve every round-1..10 fix: coalesced `cleanup()`, the JS three-state lifecycle machine, the `TEARDOWN_*` state machine + `napi_initialize` adoption path (incl. round-7's `g_teardown_cancelled` carve-out), the worker-thread `g_active_ops` decrement, the atomic admission blocks, the round-6 handle-read validations, round-7 conversion-status checks, round-8 setup-allocation NULL checks, round-9 worker/callback OOM + N-API-create checks + deferred registry removal, round-10 env-cleanup registry removal + `g_isolate`-guarded finalize.
+- Node vitest baseline currently **878 passed / 59 skipped / 0 failed**; this round raises it (new tests) and must stay green.
+
+## Rejected Alternatives
+
+- **#1 via a teardown-time sweep of `g_bridges` instead of per-engine hooks.** Rejected: a global sweep would run on whatever thread triggers isolate teardown, deleting env-affine records off their owner thread — the exact thread-affinity violation the per-env-hook design (F2) exists to avoid. Per-engine hooks dispose each record on its own env's thread.
+- **#1 leaving the owner guard resolver-only while adding a hook to resolver-less engines.** Rejected: `napi_remove_env_cleanup_hook` on an early destroy would then run cross-thread (UB) or be skipped (dangling hook → UAF at env teardown). The guard must cover every hooked engine.
+- **#2/#3 via a JS-side lease (await per-engine drain before destroy).** Rejected (same as round-9): no per-engine "await my ops" primitive exists at the JS layer; `run()` is synchronous and streaming is an abandonable generator. The authoritative pin lives in C, taken atomically at admission.
+- **#2/#3 by re-looking-up the bridge after admission.** Rejected: a second lookup still races destroy in the gap; only holding the pin (`in_flight++`) under the admission lock closes the window.
+- **#3 pinning the sync run at the top (before arg extraction).** Rejected: the arg-extraction/OOM path does not touch the engine, so pinning there only adds unwind sites; pin in the same late critical section as `g_active_ops`, matching the existing round-7 reasoning for that path.
+- **#4 compatibility shims for the removed `*_with_resolver` ABI.** Rejected (user decision): dwlib is consumed by this repo's own bindings in lockstep; the redesign intentionally replaces that ABI. Documented as an intended break; no shims.
+- **#5 removing listeners in `cleanup()` (retain references, `removeListener`).** Rejected in favor of register-once: simpler, no per-instance bookkeeping, and the hooks already tolerate a null singleton, so a single lifetime registration is correct and leak-free.
+- **#6 adding a native fault-injection hook to force the race deterministically.** Rejected as test-only production surface (YAGNI), consistent with rounds 6–10; the deterministic envelope assertions plus a best-effort probabilistic race guard are the coverage.
+- **Modifying the Java `ScriptRuntime` registry to tolerate late lookups.** Rejected as out of scope and the wrong layer — the C addon must hold the pin so the registry entry is never removed under an admitted op.
diff --git a/docs/superpowers/specs/2026-08-19-worker-ref-leak-and-teardown-race-hardening-design.md b/docs/superpowers/specs/2026-08-19-worker-ref-leak-and-teardown-race-hardening-design.md
new file mode 100644
index 00000000..fc80c61b
--- /dev/null
+++ b/docs/superpowers/specs/2026-08-19-worker-ref-leak-and-teardown-race-hardening-design.md
@@ -0,0 +1,203 @@
+# Worker Ref-Leak & Teardown-Race Hardening — Round 12 (W-23692110)
+
+**Status:** Design approved, ready for planning.
+
+**Source review:** `docs/pr-157-follow-up-code-review-3.md` (9 findings), verified against live source at commit `e1b9ee0` (round-12 tip; round-11 code + the #7 doc fix). Two findings are already resolved and are out of scope for the implementation round below:
+
+- **#7 (docs)** — the two `cleanup()` README bugs (false "fatal signals" claim; over-broad "drains anywhere in the process" claim) are fixed in `e1b9ee0`.
+- **#1 (dwlib C ABI break)** — factual and by design. The project is **pre-GA**; the multi-engine redesign intentionally replaces the `run_script_*_with_resolver` exports with the `*_engine` entrypoints and adds `ctx` to `ResolveModuleCallback`. No compatibility shims, no major-version ceremony required at this stage. **Decision (user): OK, not addressed.** No code change.
+
+**Scope:** `native-lib/node` only — `src/addon.c`, `src/dataweave.ts`, and Node integration tests under `tests/`. Do **not** touch `native-lib/python/**`, the legacy singleton entrypoints (`run_script`, `run_script_callback`, `run_script_input_output_callback`), `dw_napi_run_script`, or `ScriptRuntime.getInstance()`. The Java side (`NativeLib.java`, `ScriptRuntime`) is read for context but not modified.
+
+## Problem
+
+Round 11 gave every engine an env cleanup hook so an abandoned Worker's env teardown reclaims the engine record and Java registry entry. A follow-up review found that reclamation is **incomplete** (the init reference leaks — #2) and that the deferred finalize path it relies on has a **teardown race** (#3), plus three medium code issues (#4, #5, #6) and two test-coverage gaps (#8, #9). All seven are verified real against live source.
+
+### #2 (High) — Abandoned-env teardown leaks the initialization reference
+
+Every `DataWeave` instance calls `ffi.initialize()` on construction (`dataweave.ts:87`), which does `g_ref_count++` (`addon.c:506`; also the fast-path `:477` and the adoption path `:463`). The only `g_ref_count--` is in `napi_cleanup` (`addon.c:2153`), reached from JS via `ffi.cleanup()`. When a Worker (or the main env) terminates **without** calling `cleanup()`, the env cleanup hook `bridge_env_cleanup` → `bridge_finalize` (`addon.c:252-293`) frees the engine record, deletes the napi_ref, and removes the Java registry entry — but never decrements `g_ref_count`. So the shared isolate's reference count never returns to zero and the isolate is never torn down. Repeated Worker create/terminate cycles without explicit `cleanup()` keep the isolate alive indefinitely. This directly contradicts the round-11 comment at `addon.c:1686` claiming the hook prevents leaking "the native-lib reference."
+
+### #3 (High) — Deferred registry removal attaches to an isolate that teardown may be destroying
+
+`bridge_finalize` (`addon.c:224-243`) reads `g_isolate` **without `g_mutex`** and calls `fn_attach_thread(g_isolate, &thread)` then `fn_destroy_engine(thread, …)` to remove the Java registry entry. The streaming/transform worker threads release their `g_active_ops` reservation (`addon.c:745-748` for streaming; the transform analogue) **before** the completion sentinel runs `bridge_end_op` → `bridge_finalize`. Once `g_active_ops` reaches 0, the `teardown_waiter_thread_fn` is free to begin `graal_tear_down_isolate()`. So the sequence
+
+1. worker releases `g_active_ops` (now 0),
+2. waiter wakes, transitions `TEARING_DOWN`, calls `graal_tear_down_isolate()`,
+3. sentinel's `bridge_finalize` reads `g_isolate` (passes the NULL check because step 2's clear hasn't landed / is racing) and calls `fn_attach_thread` on an isolate being destroyed
+
+is possible. This is **both** a C data race on `g_isolate` (lock-free read racing a write under lock) **and** an attach-vs-teardown TOCTOU. The round-11 whole-branch review adjudicated the *spawn-failure* variant benign because it runs with the reservation still held / isolate guaranteed alive; the **deferred-finalize** variant is not benign because it can run after `g_active_ops` is already 0.
+
+### #4 (Medium) — `runTransform` can dispatch on an engine cleaned up during input pre-buffering
+
+`runTransform` (`dataweave.ts:221-248`) calls `ensureReady()` (`:226`), then `await createChunkReader(input)` (`:234`) — a suspension point that, for async input, can take arbitrary time — then dispatches with `this.engineHandle!` (`:238`). A caller can start the transform, `cleanup()` the instance while the reader is pre-buffering, then resume into a dispatch with a cleared/destroyed handle. The round-11 C admission pin makes this **memory-safe** (worst case is a resolved `Unknown engine handle` envelope, not a UAF), but the readiness check is stale by the time of dispatch.
+
+### #5 (Medium) — Module-level `cleanup()` does not coalesce overlapping calls
+
+The module-level `cleanup()` (`dataweave.ts:371-383`) nulls `globalInstance` **synchronously** before awaiting `instance.cleanup()`. A second overlapping call sees `globalInstance === null` and resolves immediately, even though the first call's native teardown is still draining. The instance-level `cleanup()` correctly coalesces via `this.cleanupPromise` (`:131`); the module wrapper does not, so its contract ("resolves once native teardown has finished") is violated for the second caller.
+
+### #6 (Medium) — Ignored `napi_add_env_cleanup_hook` status leaks a returned handle
+
+`napi_create_engine` (`addon.c:1692`) and `napi_create_engine_with_resolver` (`addon.c:1743`) ignore the return status of `napi_add_env_cleanup_hook`. If registration fails, the function still returns a usable handle, but the engine now has **no** env cleanup hook, so an abandoned Worker permanently strands its engine record, Java registry entry, and (per #2) init reference. Engine creation is not all-or-nothing.
+
+### #8 (Medium) — The run-vs-destroy test cannot prove the pin guarantee
+
+`engine-handle-contract.test.ts:177-231` fires `destroyEngine()` on the same JS thread **after** admission, then accepts *either* success *or* the `Unknown engine handle` envelope. On fixed code the pin was already acquired at admission, so this ordering must deterministically succeed; accepting the error envelope means a regression that removes the pin still passes the test. The assertion is too weak to detect the very regression it exists to guard.
+
+### #9 (Medium) — No Worker integration coverage for the documented per-Worker model
+
+The README (`README.md:445-456`) instructs users to construct a separate resolver-backed `DataWeave` instance per Worker, but no test creates a `worker_threads` Worker. There is no coverage for resolver-backed/resolver-less engines inside a Worker, normal Worker exit without `cleanup()` (the #2 scenario), `Worker.terminate()`, independent module resolution, or subsequent main-thread initialization.
+
+## Design
+
+The two correctness fixes (#2, #3) share the teardown-coordination trio `g_ref_count` / `g_active_ops` / the lock-free `g_isolate` read. Per the approved approach, the fix is **robust but bounded**: close the race for real and track the init reference properly, using **targeted consolidation of only the ref-release/finalize step** where sharing is warranted — without re-opening the broader coordination substructure (the round-5 `TEARDOWN_*` state machine + adoption path, the round-9/10 deferred-removal logic) that took six rounds to stabilize.
+
+### 1. Release the init reference on abandoned-env teardown (#2)
+
+**New helper — `release_isolate_ref_locked()`** (caller holds `g_mutex`). It carries the exact "one initialization reference is going away" logic that `napi_cleanup` Case 5 already implements: decrement `g_ref_count`; if it reaches 0, drive the **existing** teardown decision (immediate teardown when `g_active_ops == 0`, or queue the `teardown_waiter` when `g_active_ops > 0`, setting `TEARDOWN_PENDING_WAIT`). This is *targeted* consolidation — only the decrement-and-maybe-teardown step, not the surrounding machinery. `napi_cleanup` is refactored to call it (behavior-preserving); the env-cleanup path calls it too.
+
+**Env-cleanup path releases the ref.** `bridge_env_cleanup` reclaims an abandoned env's engine. Because that env's `initialize()` did one `g_ref_count++` per engine it created, the reclamation must do one matching release per engine:
+
+- In `bridge_env_cleanup`'s **direct finalize** path (`in_flight == 0`, `addon.c:279-293`): after finalizing the record, call `release_isolate_ref_locked()` once, under `g_mutex`.
+- In its **deferred-drain** path (`in_flight > 0`, marks `destroy_pending`/`deferred_registry_remove`, `addon.c:269-278`): the last op to drain (`bridge_end_op` → finalize) must perform the release. Thread a flag on the record — `deferred_ref_release` — set alongside `deferred_registry_remove` in the env-cleanup deferral, so `bridge_end_op` knows to release the ref exactly once when it finalizes. (The `destroyEngine` deferral does **not** set it — that path is paired with an explicit `ffi.cleanup()` in JS and must not double-release.)
+
+**Ownership rule (the invariant):** exactly one `g_ref_count` release per `initialize()`. `napi_cleanup` releases for instances torn down via explicit JS `cleanup()`; the env-cleanup path releases for instances abandoned by a terminating env. `destroyEngine` never releases (its JS caller always follows with `ffi.cleanup()`). These are mutually exclusive per engine because `destroyEngine` removes the env hook (so an engine reclaimed by the hook was never explicitly destroyed) and JS `cleanup()` calls `destroyEngine` then `ffi.cleanup()` on the *live* env (so the hook never fires for it).
+
+This makes the round-11 comment at `addon.c:1686` accurate. Update that comment to state the hook now also releases the init reference.
+
+### 2. Guard the isolate-touching finalize with a transient admission reservation (#3)
+
+`g_active_ops > 0` is the exact invariant that keeps the isolate alive (the waiter blocks on `while (g_active_ops > 0)`; the Case-4 synchronous fast path holds `g_mutex` throughout its `g_active_ops == 0` check + teardown). The fix moves the lock-free `g_isolate` read + registry-removal attach into a **short, self-contained `g_active_ops` reservation taken under `g_mutex`**, gated on teardown state — so the isolate provably cannot begin teardown across the attach, and the record-lifecycle machinery (`in_flight`, the worker-thread `g_active_ops--`, `bridge_end_op`) is **not** restructured.
+
+> **Mechanism decision:** the approved approach is the **transient reservation** below, not the more invasive "move `in_flight--`/`g_active_ops--` onto the worker thread and split the completion path across threads." In the live code the op's own `g_active_ops--` happens on the worker thread (`streaming_thread_fn:746` / `transform_thread_fn:1241`) while the finalize decision runs later on the JS thread (`call_js_write` → `bridge_end_op` → `bridge_finalize`); threading the reservation through that split would re-open the round-5/9/10/11 completion coordination the "bounded" constraint keeps closed. The transient reservation closes the identical race by taking a *fresh* reservation only around the attach, wherever finalize happens.
+
+**Split `bridge_finalize` into two phases:**
+
+- `bridge_finalize_registry(b)` — the isolate-touching phase. It takes its **own** transient `g_active_ops` reservation, checking teardown state in the *same critical section* as the increment:
+
+  ```c
+  static void bridge_finalize_registry(engine_bridge_t* b) {
+      if (b == NULL || !fn_destroy_engine) return;
+      uv_mutex_lock(&g_mutex);
+      // If the isolate is already being physically torn down, or is gone, the
+      // Java registry died (or is dying) with it -- nothing to remove, and an
+      // attach would race graal_tear_down_isolate. Skip. The check and the
+      // g_active_ops++ are ONE critical section, so no teardown path (Case-4
+      // sync, which holds g_mutex throughout; the waiter's TEARING_DOWN publish,
+      // also under g_mutex) can interleave between them.
+      if (g_teardown_state == TEARDOWN_TEARING_DOWN || g_isolate == NULL) {
+          uv_mutex_unlock(&g_mutex);
+          return;
+      }
+      g_active_ops++;              // pins the live isolate against teardown
+      uv_mutex_unlock(&g_mutex);
+
+      void* thread = NULL;
+      if (fn_attach_thread(g_isolate, &thread) == 0) {
+          fn_destroy_engine(thread, b->handle);
+          fn_detach_thread(thread);
+      }
+
+      uv_mutex_lock(&g_mutex);
+      g_active_ops--;
+      uv_cond_broadcast(&g_teardown_cond);   // verbatim release pattern
+      uv_mutex_unlock(&g_mutex);
+  }
+  ```
+
+- `bridge_finalize_free(b, env_still_alive)` — the non-isolate phase: napi_ref deletion (owner JS thread, env alive; stays resolver-gated `resolver_js != NULL && env != NULL`) + `resolver_results_free_all` + `free(b)`. Touches no GraalVM isolate state.
+
+`bridge_finalize(b, env_still_alive, do_registry_remove)` becomes a thin wrapper preserving its exact current signature and every call site: `if (do_registry_remove) bridge_finalize_registry(b); bridge_finalize_free(b, env_still_alive);`. All existing callers (the two creators' rollback, `bridge_env_cleanup` direct path, `bridge_end_op`, `napi_destroy_engine` immediate path) keep calling `bridge_finalize` unchanged — the reservation-guarded registry removal is now automatic for all of them.
+
+**No completion-path restructuring.** `streaming_thread_fn` / `transform_thread_fn` keep their existing worker-thread `g_active_ops--` (verbatim) and `bridge_end_op` calls exactly as-is; `bridge_end_op` keeps its `in_flight--` + finalize-decision logic exactly as-is. Only the *body* of the registry-removal step (now inside `bridge_finalize_registry`) changes.
+
+**Why this closes the race, against all three teardown paths:**
+- **Waiter (Case 5 → `TEARING_DOWN`):** the waiter publishes `TEARDOWN_TEARING_DOWN` under `g_mutex` *before* dropping the lock to call `graal_tear_down_isolate`. `bridge_finalize_registry`'s check+increment is one critical section: either it runs first (increments `g_active_ops`, so the waiter's `while (g_active_ops > 0 ...)` blocks until the attach completes and releases), or the waiter wins and publishes `TEARING_DOWN`/clears `g_isolate` first (so the check skips). No attach ever overlaps `graal_tear_down_isolate`.
+- **Sync fast path (Case 4):** holds `g_mutex` across its `g_active_ops == 0` check *and* the spawn/join of `cleanup_thread_fn`. `bridge_finalize_registry` cannot acquire the lock mid-teardown; it either increments before Case 4 reads `g_active_ops` (Case 4 then sees > 0 and defers to a waiter) or runs after Case 4 cleared `g_isolate`/`g_initialized` (check skips).
+- **Adoption:** never tears down (`g_teardown_cancelled`), so `g_isolate` stays valid; a stray attach is harmless.
+
+**Deadlock-safety (the load-bearing review gate):** the transient reservation must not re-introduce the round-5 deadlock. Round-5's deadlock was a *blocking wait on the JS event loop* while an op needed that loop. `bridge_finalize_registry` attaches its **own** Graal thread, makes **no** env-affine N-API call and **no** wait on the JS loop, and its reservation is released in the same function after a bounded `fn_destroy_engine` — it cannot depend on the event loop turning, and its reservation is never held across a JS callback. This must be explicitly confirmed in review.
+
+**Preserves round-5's decrement-on-worker-thread reasoning:** the op's own `g_active_ops--` stays on the worker thread, untouched. `bridge_finalize_registry`'s reservation is an additional, independent, short-lived one.
+
+### 3. `runTransform` readiness re-check after pre-buffering (#4)
+
+In `runTransform` (`dataweave.ts`), call `this.ensureReady()` again immediately after `await createChunkReader(input)`, before `streamFromNative(...)`. If the instance was cleaned up during the await, the caller gets a synchronous `DataWeaveError` (the same error `ensureReady` throws elsewhere) instead of a resolved `Unknown engine handle` envelope. No lease is introduced — the authoritative guard is the C admission pin (round 11 #2/#3); this only improves the failure ergonomics for a misused instance. The first `ensureReady()` at the top stays (fail fast before pre-buffering when already not-ready).
+
+### 4. Module-level `cleanup()` coalescing (#5)
+
+Add a module-scoped `cleanupPromise: Promise<void> | null`. The module `cleanup()` becomes: if `cleanupPromise` is set, return it; else if `globalInstance` is null, return; else capture the instance, null `globalInstance`, store `cleanupPromise = instance.cleanup()`, `await` it in a `try`, and clear `cleanupPromise` in `finally`. Overlapping callers all await the same promise and resolve only when the underlying native teardown finishes — matching the instance-level coalescing pattern. The `cleanupStarted` exit-hook coalescer is unchanged (it coalesces `beforeExit`/`exit` for a shutdown; this coalesces overlapping manual calls). Keep the `cleanupStarted = false` reset last, as today.
+
+### 5. Check `napi_add_env_cleanup_hook` status; make creation all-or-nothing (#6)
+
+In both `napi_create_engine` and `napi_create_engine_with_resolver`, capture the `napi_status` from `napi_add_env_cleanup_hook`. On non-`napi_ok`:
+
+- unlink the just-linked record from `g_bridges` (under `g_mutex`),
+- `bridge_finalize_registry(record)` to remove the Java registry entry (the engine was just created on this same live thread; the isolate is alive and `g_active_ops` need not be held because we are on the creating JS thread before returning — `g_isolate` is stable here, the same condition the existing destroyEngine fallback relies on),
+- `release_isolate_ref_locked()` to release this creation's init reference (this instance's `initialize()` bumped it),
+- `bridge_finalize_free(record, /*env_still_alive=*/true)`,
+- `napi_throw_error` and return NULL — no usable handle escapes.
+
+Because the record was just constructed and linked on this thread and no op could have been admitted against it yet (`in_flight == 0`, no concurrent admission — the JS wrapper hasn't returned the handle), the unlink-and-finalize is race-free.
+
+### 6. Strengthen the run-vs-destroy test (#8)
+
+In `engine-handle-contract.test.ts`, for the **admitted ordering** (destroy fired after the streaming/transform op is admitted), require **success + complete chunks** — remove the "or Unknown engine handle" acceptance for that specific ordering. On fixed code the pin is already held at admission, so success is guaranteed; a regression that drops the pin would now produce the error envelope and **fail** the test. Keep any genuinely-unforceable cross-thread interleaving as a separately-labeled best-effort probe.
+
+### 7. Worker integration tests (#9)
+
+Create `native-lib/node/tests/integration/worker-lifecycle.test.ts` using real `worker_threads` Workers loading the real compiled addon. Coverage:
+
+- **Resolver-backed engine in a Worker:** create, run a script that resolves a custom module via the Worker's `resolveModule`, assert correct output — proving per-Worker resolver binding.
+- **Resolver-less engine in a Worker:** create, run, assert output.
+- **Normal Worker exit without `cleanup()` (the #2 proof):** run N cycles of {spawn Worker → create engine → run → let the Worker exit without `cleanup()`}, then assert the main thread can still `initialize()` and run, and that the process is not wedged. This is the behavioral observation of the #2 ref release (pre-fix, the leaked ref would keep the isolate alive; the test asserts continued healthy operation and clean final teardown).
+- **`Worker.terminate()` mid-life** then subsequent main-thread `initialize()`/run succeeds.
+- **Explicit `cleanup()` inside a Worker** resolves and leaves the main thread healthy.
+
+**Shared-state discipline:** these Worker tests share the parent process's isolate. Each Worker's own engine lifecycle must be balanced, and the file must end with a final main-thread `cleanup()` so it doesn't perturb sibling integration files — the same discipline `independent-engines.test.ts` follows. Vitest `pool: "forks"` isolates per file, so the file's residual state does not leak across files, but within-file balance still matters for the assertions.
+
+**Determinism posture (stated in the test file):** exact cross-thread timing interleavings (#3's race) are **not** deterministically forceable — matching the rounds 5–11 posture. The deterministic teeth are #8's required-success admitted-ordering assertion and #2's "Worker exits → main thread still works + final teardown clean" assertion. #3's correctness rests on the code reasoning in Design §2 (the reservation window), with the Worker tests as best-effort probabilistic guards over N iterations that are green on fixed code and cannot false-fail on it.
+
+## Testing
+
+- Strengthened `engine-handle-contract.test.ts` admitted-ordering assertion (#8).
+- New `worker-lifecycle.test.ts` (#9), doubling as behavioral coverage for #2 (and best-effort for #3).
+- Unit coverage for the module-level `cleanup()` coalescing (#5): two overlapping `cleanup()` calls both await the same drain and neither resolves before native teardown completes.
+- Unit coverage for `runTransform` re-check (#4): consuming a transform generator after the instance was cleaned up during the input await surfaces a `DataWeaveError` synchronously at resume, not a resolved error envelope.
+- No Java test change (the `@CEntryPoint` hosted-JVM limitation is unchanged; coverage stays at the Node integration layer).
+- #2/#3 lifecycle correctness that is not deterministically forceable is covered by code reasoning against the invariants in §Design plus the best-effort Worker guards (same documented posture as rounds 5–11).
+
+## Verification
+
+- `cd native-lib/node && npm run build:addon` clean (no new warnings in the touched regions: `bridge_finalize*`, `bridge_env_cleanup`, `bridge_end_op`, `napi_cleanup`, the two creators, the streaming/transform completion sentinels); `npm run build` (tsc) clean.
+- `npm test` green at the new baseline (currently 885 passed / 59 skipped / 0 failed; this round adds the #5, #4, #8 assertions and the #9 Worker suite — the plan sets the exact new counts).
+- `git diff --check`.
+
+## Global Constraints
+
+- Node-binding-only. Never touch `native-lib/python/**`.
+- Never touch the legacy singleton entrypoints (`run_script`, `run_script_callback`, `run_script_input_output_callback`), `dw_napi_run_script`, or `ScriptRuntime.getInstance()`. The Java side is not modified.
+- Handle width stays C `long long` everywhere.
+- Errors for run/streaming/transform APIs surface as **resolved** JSON string values (async) or a synchronous `napi_throw_error` (admission/arg/alloc/resource failures) — never `napi_reject_deferred`.
+- `napi_env`/`napi_ref`/`napi_deferred`/`napi_threadsafe_function` are thread-affine to the env's JS thread. No env-affine napi call may be made off the owning thread. `bridge_finalize_free`'s napi_ref deletion stays resolver-gated (`resolver_js != NULL && env != NULL`) and on the owner thread.
+- All shared C state (`g_initialized`, `g_active_ops`, `g_teardown_state`, `g_teardown_cancelled`, `g_ref_count`, every engine record's `in_flight`/`destroy_pending`/`deferred_registry_remove`/the new `deferred_ref_release`) is read/written only under `g_mutex`. In `bridge_finalize_registry` the `g_teardown_state`/`g_isolate` check and the transient `g_active_ops++` are one critical section under `g_mutex`; the subsequent `g_isolate` read for the attach happens only after that increment pinned the isolate alive (the check having ruled out `TEARING_DOWN`/NULL) — closing the round-12 #3 race.
+- The `g_active_ops` release pattern is EXACTLY, verbatim: `uv_mutex_lock(&g_mutex); g_active_ops--; uv_cond_broadcast(&g_teardown_cond); uv_mutex_unlock(&g_mutex);`
+- **Exactly one `g_ref_count` release per `initialize()`** (the #2 invariant): `napi_cleanup` for explicitly-cleaned instances; the env-cleanup path for abandoned envs; `destroyEngine` never releases. Mutually exclusive per engine.
+- `fn_destroy_engine` is called **exactly once** per handle.
+- Per-engine `in_flight` and global `g_active_ops` stay **distinct** counters — not merged.
+- The round-5 deadlock fix must be preserved: the op's own `g_active_ops--` stays on the worker/completion thread, never moved to a JS-thread callback; and no blocking wait on the JS event loop is introduced. `bridge_finalize_registry`'s transient reservation is taken and released within that one function, never held across a JS callback, and its guarded step makes no env-affine/JS-loop-dependent call — confirm in review.
+- Preserve every round-1..11 fix: coalesced instance `cleanup()`, the JS three-state lifecycle machine, the `TEARDOWN_*` state machine + `napi_initialize` adoption path (incl. round-7's `g_teardown_cancelled` carve-out), the worker-thread `g_active_ops` decrement, the atomic admission blocks + round-11 admission-time engine pin (`bridge_begin_op_locked`) in all three run paths, the round-6 handle-read validations, round-7 conversion-status checks, round-8 setup-allocation NULL checks, round-9 worker/callback OOM + N-API-create checks + deferred registry removal, round-10 env-cleanup registry removal + `g_isolate`-guarded finalize, round-11 env cleanup hook for every engine + owner-thread destroy guard for every record + register-once exit hooks.
+- Node vitest baseline currently **885 passed / 59 skipped / 0 failed**; this round raises it (new tests) and must stay green.
+
+## Rejected Alternatives
+
+- **#2 by decrementing `g_ref_count` inline in `bridge_finalize` without the shared helper.** Rejected: the "reached zero → immediate teardown vs. queue the waiter" decision already lives in `napi_cleanup` Case 5; duplicating it invites divergence. A single `release_isolate_ref_locked()` keeps both paths identical.
+- **#2 by having `destroyEngine` also release the ref.** Rejected: `destroyEngine`'s JS caller (`doCleanup`) always follows with `ffi.cleanup()`, which releases the ref; adding a release in `destroyEngine` would double-release and tear the isolate down under live instances.
+- **#3 by taking `g_mutex` around the `g_isolate` read + attach in `bridge_finalize`.** Rejected: `fn_attach_thread`/`fn_destroy_engine` enter GraalVM and can block; holding `g_mutex` across them would serialize all teardown coordination behind a GraalVM call and risk lock-ordering issues with the waiter. The transient reservation holds `g_mutex` only for the check+increment, then releases it before the GraalVM attach.
+- **#3 by moving `in_flight--`/`g_active_ops--` onto the worker thread and reusing the op's own reservation across the finalize (spec's earlier literal wording).** Rejected as re-opening the round-5/9/10/11 completion coordination the approved approach keeps bounded: in the live code the op's `g_active_ops--` is on the worker thread while the finalize decision runs later on the JS thread via `bridge_end_op`; threading one reservation across that split would restructure `bridge_end_op` and both completion sentinels across thread boundaries. The transient reservation closes the identical race by taking a *fresh* short-lived reservation only around the attach, wherever finalize runs — no completion-path restructuring.
+- **#3 with a dedicated `g_finalizing` counter separate from `g_active_ops`.** Rejected as re-opening the coordination substructure the approved approach keeps bounded: it adds a second teardown-gating counter that the waiter must also wait on, duplicating what `g_active_ops` already expresses. A transient `g_active_ops` reservation reuses the counter the waiter already blocks on and is provably correct.
+- **#4 via a JS-side operation lease that blocks `cleanup()` until the transform completes.** Rejected (same as rounds 9/11): no per-engine "await my ops" primitive exists at the JS layer, and the authoritative pin already lives in C. The re-check is the minimal ergonomic close; the lease would duplicate the C pin's guarantee at a layer that cannot enforce it.
+- **#5 by not nulling `globalInstance` until the drain settles.** Rejected: a concurrent convenience-API call would then revive/return the instance mid-teardown. Nulling synchronously (so new work builds a fresh instance) plus a module `cleanupPromise` (so overlapping `cleanup()`s coalesce) matches the instance-level design and is correct.
+- **#6 by leaving the handle valid and logging on hook-registration failure.** Rejected: a handle with no env cleanup hook silently reintroduces exactly the #2 leak the round is closing. Creation must be all-or-nothing.
+- **#8 keeping the "success OR error envelope" acceptance for the admitted ordering.** Rejected: that acceptance is precisely what lets a pin regression pass. The admitted ordering is deterministic on correct code, so the test must require success.
+- **#9 driving the "cross-thread" scenario on a single JS thread only.** Rejected as insufficient for the documented per-Worker model: real `worker_threads` Workers are needed to exercise per-Worker engine binding and the abandoned-env (#2) path. The exact race remains best-effort, but the Worker lifecycle itself must be really exercised.
+- **Modifying the Java `ScriptRuntime` to reference-count or tolerate late lookups.** Rejected as out of scope and the wrong layer — the C addon owns the isolate reference and the pin.
diff --git a/docs/superpowers/specs/2026-08-19-worker-teardown-dangling-resolver-ctx-design.md b/docs/superpowers/specs/2026-08-19-worker-teardown-dangling-resolver-ctx-design.md
new file mode 100644
index 00000000..69686ae2
--- /dev/null
+++ b/docs/superpowers/specs/2026-08-19-worker-teardown-dangling-resolver-ctx-design.md
@@ -0,0 +1,104 @@
+# Worker-Teardown Dangling Resolver Ctx & Shutdown-Doc Accuracy — Round 10 (W-23692110)
+
+**Status:** Design approved (lightweight round), ready for direct implementation.
+
+**Source review:** `docs/pr-157-follow-up-andy-code-review-10.md` (two findings, both verified against live source at commit `d504c0f`, the round-9 tip).
+
+**Scope:** `native-lib/node` only — `src/addon.c` (finding 1) and `src/dataweave.ts` (finding 2). Do **not** touch `native-lib/python/**`, the legacy singleton entrypoints, or `ScriptRuntime.getInstance()`. The Java side is not modified — the C addon must stop leaving a live registry entry pointed at freed memory rather than change Java's registry semantics.
+
+## Problem
+
+### #1 (P1) — Worker teardown frees a resolver bridge but leaves its Java registry entry (and resolver ctx) dangling
+
+`napi_create_engine_with_resolver` passes the `engine_bridge_t* bridge` to Java as the resolver ctx (`addon.c:1640`); Java's `CallbackWeaveResourceResolver` retains it, and `resolve_module_callback` casts that same ctx word back to `engine_bridge_t*` (`addon.c:1450`).
+
+When the owning Worker/main env tears down, the per-env cleanup hook `bridge_env_cleanup` runs. It **frees** the bridge — `bridge_finalize(b, /*env_still_alive=*/true, /*do_registry_remove=*/false)` at `addon.c:265` — but deliberately passes `do_registry_remove=false`, so it does **not** call `fn_destroy_engine`. The `ScriptRuntime` stays in the Java registry with a `CallbackWeaveResourceResolver` whose ctx now points at freed native memory. A subsequent invocation of that handle dereferences freed memory (UAF).
+
+This is exactly the round-9 decision: round 9 gave every engine a record and deferred registry removal for the `destroyEngine` path, but chose `do_registry_remove=false` on the env-cleanup path (`addon.c:105-108`) out of caution about calling `fn_destroy_engine` during env teardown. Round 10 shows that caution was wrong: leaving the registry entry is a UAF.
+
+**Both env-cleanup sub-paths have the gap:**
+- Direct free (`in_flight == 0`, `addon.c:265`): frees with `do_registry_remove=false`.
+- Deferred (`in_flight > 0`, `addon.c:254-258`): sets `destroy_pending=true` but leaves `destroy_via_destroy_engine=false`, so the later `bridge_end_op` → `bridge_finalize` drain (`addon.c:297-303`) also skips the registry removal.
+
+### #2 (P2) — Shutdown doc over-promises `exit`-hook coverage
+
+`dataweave.ts:276-280` says the synchronous `exit` hook is "the last-ditch fallback for `process.exit()`, uncaught exceptions, and fatal signals." Node does **not** emit `exit` for termination signals such as SIGTERM/SIGKILL (absent a JS signal handler), nor for all fatal failure modes. The comment should describe `exit` as best-effort only and tell callers who need guaranteed graceful shutdown to register and await their own signal handlers.
+
+## Design
+
+### 1. Remove the registry entry during env cleanup (finding #1)
+
+Make `bridge_env_cleanup` remove the Java registry entry before/when it frees the bridge, on **both** sub-paths, guarded on isolate liveness.
+
+**Why calling `fn_destroy_engine` here is safe (the round-9 caution, resolved):**
+- `bridge_env_cleanup` is registered **only for resolver-backed engines** (`addon.c:1666`; resolver-less engines register no hook, `addon.c:1598-1601`), so this path is exactly the dangling-ctx case.
+- `destroyEngine` removes the hook (`napi_remove_env_cleanup_hook`, `addon.c:1738`) for any engine it handles — deferred or not — so `bridge_env_cleanup` only ever fires for an engine that was **never** passed to `destroyEngine`. Such an engine's `initialize()` ref was likewise never released (both go through `doCleanup()`), so `g_ref_count > 0` and the process-wide GraalVM isolate is still alive: `fn_destroy_engine`'s fresh-thread attach is legal.
+- `fn_destroy_engine` attaches its **own** isolate thread (not JS-thread-affine), so it is safe from the env-cleanup hook thread — the same property `destroyEngine`'s deferred-drain finalize already relies on.
+- **The one exception:** the main env can tear down *after* `napi_cleanup` already tore down the isolate (`g_isolate == NULL`). Then the Java registry died with the isolate and there is nothing to remove — so the registry removal must be **guarded on `g_isolate != NULL`**.
+
+**Exactly-once preserved:** `destroyEngine` and `bridge_env_cleanup` are mutually exclusive per handle (destroyEngine removes the hook), so `fn_destroy_engine` still runs at most once per handle.
+
+**Changes (`addon.c`):**
+
+a. **Harden `bridge_finalize`'s registry-removal guard** to skip when the isolate is gone — protects every caller and covers the "isolate torn down by drain time" case for the deferred path:
+```c
+if (do_registry_remove && fn_destroy_engine && g_isolate) {
+    void* thread = NULL;
+    if (fn_attach_thread(g_isolate, &thread) == 0) { fn_destroy_engine(thread, b->handle); fn_detach_thread(thread); }
+}
+```
+(`g_isolate` is read outside `g_mutex` here — the same accepted pattern as `napi_destroy_engine`'s fallback at `addon.c:1753-1756`; the NULL check narrows the window and makes a torn-down isolate a no-op instead of an unsafe `fn_attach_thread(NULL, …)`.)
+
+b. **`bridge_env_cleanup` direct path** (`addon.c:265`): pass `do_registry_remove=true`:
+```c
+bridge_finalize(b, /*env_still_alive=*/true, /*do_registry_remove=*/true);
+```
+
+c. **`bridge_env_cleanup` deferred path** (`addon.c:254-258`): set the deferred-registry-removal flag so the draining op removes the entry:
+```c
+if (b->in_flight > 0) {
+    b->destroy_pending = true;
+    b->deferred_registry_remove = true;   // env-cleanup, like destroyEngine, must remove the registry on drain
+    uv_mutex_unlock(&g_mutex);
+    return;
+}
+```
+
+d. **Rename `destroy_via_destroy_engine` → `deferred_registry_remove`.** The field now gates the deferred registry removal for **both** `destroyEngine` and `bridge_env_cleanup`, so the old name (implying "only via destroyEngine") is actively misleading. Update the declaration/comment (`addon.c:105-109`), the set site in `napi_destroy_engine` (`addon.c:1729`), the new set site in `bridge_env_cleanup`, and the read in `bridge_end_op` (`addon.c:298`). Update the stale comments at `addon.c:105-108`, `261-265`, and `300-302` to state that the env-cleanup path now removes the registry.
+
+### 2. Correct the shutdown doc (finding #2)
+
+Reword `dataweave.ts:276-280` so the `exit` hook is described as best-effort synchronous cleanup that runs for `process.exit()`, uncaught exceptions, and normal process end — and explicitly note that Node does **not** emit `exit` for termination signals (SIGTERM/SIGKILL) or all fatal failure modes, so callers needing guaranteed graceful shutdown must register and await their own signal handlers. Doc-only; no behavior change.
+
+## Testing
+
+**No new runtime test.** Consistent with rounds 6–9: the env-teardown UAF path is not deterministically forceable from JS/vitest (it requires a Worker to exit with a live resolver engine and then re-invoke a freed handle across the teardown boundary — no addon-boundary fault-injection exists). Coverage is code reasoning against the exactly-once and isolate-liveness invariants above. #2 is doc-only.
+
+Baseline unchanged: **878 passed / 59 skipped / 0 failed**.
+
+## Verification
+
+- `cd native-lib/node && npm run build:addon` clean (no new warnings in the touched regions); `npm run build` (tsc) clean.
+- `npm test` green: **878 passed / 59 skipped / 0 failed**, unchanged.
+- `git diff --check`.
+
+## Global Constraints
+
+- Node-binding-only. Never touch `native-lib/python/**`.
+- Never touch the legacy singleton entrypoints (`run_script`, `run_script_callback`, `run_script_input_output_callback`), `dw_napi_run_script`, or `ScriptRuntime.getInstance()`. The Java side is not modified.
+- Handle width stays C `long long` everywhere.
+- Errors for run/streaming/transform APIs surface as **resolved** JSON string values or a synchronous `napi_throw_error` — never `napi_reject_deferred`.
+- `napi_env`/`napi_ref`/`napi_deferred`/`napi_threadsafe_function` are thread-affine to the env's JS thread.
+- All shared C state (incl. every engine record's `in_flight`/`destroy_pending`/`deferred_registry_remove`) is read/written only under `g_mutex`, except the documented lock-free `g_isolate` NULL-check in `bridge_finalize` (matching the existing `napi_destroy_engine` fallback pattern).
+- `fn_destroy_engine` is called **exactly once** per handle — the `destroyEngine` and `bridge_env_cleanup` paths stay mutually exclusive via hook removal.
+- The owner-thread `destroyEngine` restriction stays scoped to engines with resolver `napi_ref` state.
+- Preserve every round-1..9 fix.
+- Node vitest baseline **878 passed / 59 skipped / 0 failed**.
+
+## Rejected Alternatives
+
+- **Leave the env-cleanup path as `do_registry_remove=false` and instead make Java's registry tolerate a freed ctx.** Rejected: out of scope (Node-binding-only) and the wrong layer — the addon must not leave a live registry entry pointing at freed memory. It also cannot: the ctx is opaque to Java.
+- **Null the bridge's resolver fields instead of removing the registry entry, so a later `resolve_module_callback` fails closed.** Rejected: the bridge memory is freed, so there is nothing left to null; and the `ScriptRuntime` itself (script cache, module loader) would leak in the Java registry forever. Removing the registry entry reclaims both.
+- **Unconditionally call `fn_destroy_engine` without the `g_isolate` guard.** Rejected: at main-env teardown after isolate destruction, `g_isolate == NULL` and `fn_attach_thread(NULL, …)` is unsafe; the registry is already gone, so the call is both dangerous and pointless.
+- **Add a runtime regression test.** Rejected: not deterministically forceable (rounds 6–9 precedent); no addon-boundary fault injection for the Worker-exit-then-reinvoke race.
+- **Keep the field name `destroy_via_destroy_engine`.** Rejected: after this change it also gates the env-cleanup path, so the name would misdescribe half its uses.
diff --git a/docs/superpowers/specs/2026-08-20-per-env-init-reference-ownership-design.md b/docs/superpowers/specs/2026-08-20-per-env-init-reference-ownership-design.md
new file mode 100644
index 00000000..92563a58
--- /dev/null
+++ b/docs/superpowers/specs/2026-08-20-per-env-init-reference-ownership-design.md
@@ -0,0 +1,184 @@
+# Per-Env Init-Reference Ownership — Round 13 (W-23692110)
+
+**Status:** Design approved (user), ready for planning.
+
+**Source review:** `docs/pr-157-follow-up-code-review-4.md`, Finding #5 (Medium), verified against live source at commit `765c273` (round-12 tip). Findings #1, #2, #3, #4, #6 in that review are test-quality/coverage items or already-shipped fixes and are **out of scope** for this round (they may be addressed in a separate test-hardening round); this round fixes only #5, the one production-correctness finding.
+
+**Scope:** `native-lib/node` only — `src/addon.c` and Node integration tests under `tests/`. Do **not** touch `native-lib/python/**`, the legacy singleton entrypoints (`run_script`, `run_script_callback`, `run_script_input_output_callback`), `dw_napi_run_script`, or `ScriptRuntime.getInstance()`. The Java side is read for context but not modified. `src/dataweave.ts` is **not** modified — the product-facing `DataWeave` class already maintains the sanctioned 1:1 pairing, so no JS change is needed; the fix hardens the C boundary underneath it.
+
+## Problem
+
+### #5 (Medium) — Abandoned-env reference release relies on an unenforced raw-addon invariant
+
+`g_ref_count` (`addon.c:37`) is a single process-global reference counter with **no notion of which `napi_env` owns each reference**. Its accounting assumes a strict **1 `initialize()` ↔ 1 engine ↔ 1 `cleanup()`** pairing:
+
+- `napi_initialize` does `g_ref_count++` at three sites: the adoption path (`:531`), the already-initialized fast path (`:545`), and the create path (`:574`).
+- `napi_cleanup` → `release_isolate_ref_locked` does the matching `g_ref_count--` (`:2358-2359`) and, on the last release, drives isolate teardown.
+- An **abandoned engine's** env-cleanup hook also releases one reference: `bridge_env_cleanup` (`:339`, direct path) or `bridge_end_op` (`:404`, deferred path), gated by `engine_bridge_t.deferred_ref_release`, calling `isolate_ref_release_core_locked()`.
+
+The defect: the **per-engine** env-cleanup hook releases a reference that logically belongs to **`initialize()`**, not to the engine. The product `DataWeave` class calls `initialize()` exactly once per engine and releases them together via one `cleanup()`, so the counts happen to match. But the addon exports raw `initialize`, `createEngine`, and `createEngineWithResolver` (`addon.c:2494-2504`) with **nothing enforcing the pairing**. A raw consumer that does `initialize()` **once**, then `createEngine()` **N times**, registers **N** per-engine cleanup hooks against a reference count of **1**. When that env is abandoned:
+
+1. the first engine's hook (`bridge_env_cleanup` → `isolate_ref_release_core_locked`) drives `g_ref_count` `1 → 0`,
+2. `isolate_ref_release_core_locked` (`:2297-2338`) sees zero and **tears the isolate down** (synchronously when `g_active_ops == 0`, or queues the waiter otherwise),
+3. the remaining `N-1` engines — and, in a multi-env process, **another env's still-valid engines** — are now operating on a torn-down isolate.
+
+This is a use-after-free / premature-teardown hazard, documented but unenforced in the comment at `addon.c:2289-2296`. Finding #5 asks that the addon boundary either enforce the pairing, track init ownership separately from engine records, or make the raw surface inaccessible. The raw `.node` file cannot truly be made inaccessible (anything can `require()` it), and enforcing one-engine-per-init would reject valid multi-engine usage. **Decision (user): track initialization ownership separately from engine records** — the robust option that fixes the UAF while preserving the multi-engine feature.
+
+## Design
+
+Introduce **per-`napi_env` init-reference accounting** so `g_ref_count` becomes a derived total rather than a bare global that any engine hook can drive to zero. One invariant governs the whole design:
+
+> **`g_ref_count` == Σ `init_refs` over all live env records.**
+
+Every reference in the global count is owned by exactly one env's record; a reference can only be released by the same env that acquired it (via that env's `cleanup()`) or by that env's death hook (releasing all of that env's outstanding references at once). The per-engine cleanup hook stops touching `g_ref_count` entirely — which is the actual bug fix. The teardown decision still fires only on the true global last-release, and only from an env-scoped release path, so it can never tear the isolate down while another env holds a reference.
+
+### 1. New per-env record and registry
+
+```c
+// One record per napi_env that has ever taken an init reference (via
+// initialize()). init_refs is that env's net initialize()-minus-cleanup()
+// balance. The record is created lazily on the env's first initialize(),
+// registers exactly one env-death hook (env_init_cleanup) at creation, and is
+// freed when its env dies (that hook) after releasing every reference the env
+// still holds. All fields mutated only under g_mutex.
+//
+// INVARIANT: g_ref_count == sum of init_refs over all records in g_env_recs.
+typedef struct env_init_rec {
+    napi_env env;
+    int init_refs;
+    struct env_init_rec* next;
+} env_init_rec_t;
+static env_init_rec_t* g_env_recs = NULL;  // linked list, guarded by g_mutex
+```
+
+Helpers (all require the caller to hold `g_mutex`):
+
+- `env_init_rec_t* env_init_rec_find_locked(napi_env env)` — linear scan of `g_env_recs`, returns the record or NULL. Mirrors `bridge_find`.
+- `env_init_rec_t* env_init_rec_acquire_locked(napi_env env, bool* is_new)` — find-or-create the record and `init_refs++`. Sets `*is_new = true` when it just allocated the record (the caller must then register the env-death hook, outside any napi-illegal context — see §3). Returns NULL only on `calloc` failure (caller treats as a hard error and does not bump `g_ref_count`).
+
+### 2. `napi_initialize` — acquire a per-env reference alongside `g_ref_count`
+
+Each of the three `g_ref_count++` sites gains a paired `init_refs` acquire on the calling env, under the same `g_mutex` hold that already guards the `g_ref_count++`:
+
+- **Adoption path (`:530-534`):** currently `g_teardown_cancelled = true; g_ref_count++; broadcast; unlock; return`. Add `env_init_rec_acquire_locked(env, &is_new)` before the `g_ref_count++`. On `calloc` failure: do **not** cancel the teardown, do **not** bump `g_ref_count`; unlock and `napi_throw_error(env, NULL, "Failed to allocate env init record")`, return NULL. (The teardown stays queued; the caller's initialize failed cleanly.)
+- **Fast path (`:544-548`):** `if (g_initialized) { g_ref_count++; ... }` — add the acquire before the bump, same failure handling (unlock + throw, no bump).
+- **Create path (`:573-575`):** after a successful isolate build, before `g_ref_count++`, do the acquire. Perform the `env_init_rec_acquire_locked` **first** (it only allocates a small node); only if it succeeds proceed to `g_initialized = 1; g_ref_count++`. On acquire failure, `g_isolate` is already non-NULL (the create path's `init_thread_fn` just built it) while `g_initialized` is still 0 — simply unlocking and throwing would leave that combination in place, which the wait loop's `g_isolate != NULL && !g_initialized` clause treats as "a teardown is in flight," permanently hanging every subsequent `initialize()` in `uv_cond_wait` with nothing left to broadcast. So on this failure the just-built isolate is torn down (via the same `cleanup_thread_fn` idiom used elsewhere) before throwing, clearing `g_isolate`/`g_initialized` back to NULL/0 and restoring the same recoverable state the sibling spawn-failure/`init`-error paths already leave (they never built an isolate in the first place). If the teardown itself cannot attach to the isolate, `g_isolate` is left non-NULL as a best-effort degradation — the same posture already accepted for `cleanup_thread_fn`'s attach-failure path elsewhere.
+
+**Hook registration for a new record.** When `env_init_rec_acquire_locked` reports `is_new`, register exactly one env-death hook for the init record:
+`napi_add_env_cleanup_hook(env, env_init_cleanup, rec)`. This is legal in all three paths (they run on the env's own JS thread with the env alive). If the hook registration **fails**, the record cannot guarantee its references are reclaimed on env death — roll back: decrement the just-acquired `init_refs` (freeing the record if it drops to 0), do not bump `g_ref_count`, unlock, throw. This mirrors round-12 #6's all-or-nothing posture for the per-engine hook.
+
+Ordering note (LIFO): because the init-record hook is registered on the **first** `initialize()` for an env — before any engine is created — Node's env-cleanup hooks run **LIFO**, so `env_init_cleanup` runs **after** every per-engine `bridge_env_cleanup` for that env. Every engine bridge is thus finalized (Java registry entry removed, napi_ref deleted) while the isolate is **still alive**, and only then does the init record release the isolate reference(s). This preserves the exact ordering the round-10/11/12 fixes rely on.
+
+### 3. `env_init_cleanup` — release all of a dead env's references, once
+
+New env-death hook, registered per §2. Runs on the dying env's own thread with the env still alive (standard env-cleanup-hook contract):
+
+```c
+static void env_init_cleanup(void* arg) {
+    env_init_rec_t* rec = (env_init_rec_t*)arg;
+    if (rec == NULL) return;
+    uv_mutex_lock(&g_mutex);
+    // Unlink from g_env_recs.
+    env_init_rec_t** pp = &g_env_recs;
+    while (*pp != NULL) { if (*pp == rec) { *pp = rec->next; break; } pp = &(*pp)->next; }
+    int n = rec->init_refs;
+    rec->init_refs = 0;
+    free(rec);
+    // Release exactly the references this env still held. release_n... makes the
+    // teardown decision at most ONCE, after decrementing all n, so it never
+    // spawns a second waiter or tears down an already-torn isolate mid-loop.
+    isolate_ref_release_n_locked(n);
+    uv_mutex_unlock(&g_mutex);
+}
+```
+
+The env that reaches `env_init_cleanup` without having called `cleanup()` for each of its references (the abandoned-Worker case, and the raw multi-engine-per-init case) releases them here — **all at once, from a single env-scoped decision point.** Because `g_ref_count == Σ init_refs`, releasing this env's `n` reaches 0 **only** if no other env holds a reference, so an abandoned env-A can never tear down the isolate under a live env-B.
+
+### 4. Bounded multi-release helper `isolate_ref_release_n_locked`
+
+`isolate_ref_release_core_locked` (`:2297-2338`) currently decrements **one** reference and then makes the teardown decision. A naive loop calling it `n` times would, after the reference that reaches 0 tears down and sets `g_ref_count = 0`, make the remaining iterations no-op on an already-zero count — correct by luck, but it also re-runs the `g_teardown_state != TEARDOWN_NONE` early-return and would mis-handle the `g_active_ops > 0` waiter case if a second "last release" were computed. Make it explicit and single-decision:
+
+```c
+// Release n (>=0) initialization references at once, then make the teardown
+// decision AT MOST ONCE. Caller holds g_mutex; this KEEPS it held. Equivalent
+// to n serial core releases for the count, but guarantees the reached-zero
+// teardown/waiter logic runs exactly once. n==0 is a no-op.
+static void isolate_ref_release_n_locked(int n) {
+    if (n <= 0) return;
+    if (g_ref_count >= n) g_ref_count -= n; else g_ref_count = 0;
+    if (g_ref_count > 0) return;                    // other envs still hold refs
+    if (g_teardown_state != TEARDOWN_NONE) return;  // a teardown already drives
+    // ... the SAME reached-zero body as isolate_ref_release_core_locked:
+    //     g_active_ops == 0 -> synchronous cleanup_thread_fn + clear globals;
+    //     g_active_ops  > 0 -> spawn waiter, TEARDOWN_PENDING_WAIT, empty list.
+}
+```
+
+Refactor `isolate_ref_release_core_locked` to `isolate_ref_release_n_locked(1)` (behavior-preserving for the single-release callers). The single-decision reached-zero body is written once and shared.
+
+### 5. `napi_cleanup` — gate the release on the calling env's ownership
+
+`release_isolate_ref_locked(env)` (`:2353`) currently does an unconditional `if (g_ref_count > 0) g_ref_count--;`. Gate it on the calling env's own balance so an env can only release a reference it actually holds (user decision: gate `cleanup()` too, closing the symmetric over-`cleanup()` UAF):
+
+```c
+static napi_value release_isolate_ref_locked(napi_env env) {
+  env_init_rec_t* rec = env_init_rec_find_locked(env);
+  if (rec == NULL || rec->init_refs == 0) {
+    // This env holds no init reference: a cleanup() with no matching
+    // initialize() on this env (or a double-cleanup()). Do NOT touch
+    // g_ref_count -- releasing here would steal another env's reference and
+    // could tear the isolate down under a live user. No-op: resolve immediately.
+    uv_mutex_unlock(&g_mutex);
+    return already_resolved_promise(env);
+  }
+  rec->init_refs--;
+  if (g_ref_count > 0) g_ref_count--;
+  // ... the rest of Cases 1..5 UNCHANGED (the decrement above replaces the old
+  //     unconditional one; g_ref_count-driven teardown decision is identical).
+  ...
+}
+```
+
+The record is **not** freed here even if `init_refs` hits 0 — its env is still alive and may `initialize()` again, and its env-death hook still needs to run (with `init_refs == 0`, `env_init_cleanup` releases nothing, which is correct). This matches the product pattern of `cleanup()` then possibly re-`initialize()` on the same env.
+
+### 6. Per-engine hook stops touching `g_ref_count` (the core fix)
+
+Remove the init-reference release from the per-engine path entirely:
+
+- Delete the `deferred_ref_release` field from `engine_bridge_t` (`:121`) and every write (`bridge_env_cleanup:328`) and read (`bridge_end_op:398,404`).
+- `bridge_env_cleanup`'s direct path (`:339`) no longer calls `isolate_ref_release_core_locked()`.
+- `bridge_end_op` (`:404`) no longer conditionally releases the ref.
+
+The per-engine hooks keep doing everything else — unlink the bridge, remove the Java registry entry (`do_registry_remove`), delete the resolver napi_ref, free the record. They simply no longer own an isolate reference, because they never did: the reference belongs to `initialize()`, now tracked by the env init record.
+
+`isolate_ref_release_core_locked` becomes reachable only via `isolate_ref_release_n_locked`; if no other caller remains, it is folded into the `n==1` path (kept as a thin wrapper only if a call site still reads better with it).
+
+## Invariants preserved / established
+
+1. **`g_ref_count == Σ init_refs`** — established; every `g_ref_count` mutation is paired with an `init_refs` mutation on a specific env (init: both +1; cleanup: both −1 for the calling env; env death: −n for the dying env). The three initialize sites, `release_isolate_ref_locked`, and `env_init_cleanup` are the *only* mutators of `g_ref_count` after this round.
+2. **An env releases only what it owns** — both `cleanup()` (§5) and env-death (§3) are keyed on a specific env's record; neither can drive `g_ref_count` below the references still held by *other* envs. Closes the cross-env UAF (abandoned env) **and** the symmetric over-`cleanup()` UAF.
+3. **Teardown fires only on true global last-release** — the reached-zero body runs only when `g_ref_count` hits 0 after an env-scoped decrement, exactly as before; the multi-release helper makes that decision **once** per env-death.
+4. **`destroyEngine` never releases an init reference** — unchanged; it was never a `g_ref_count` mutator and still isn't.
+5. **`fn_destroy_engine` called exactly once per handle** — unchanged; the per-engine finalize path is untouched except for dropping the ref release.
+6. **Thread affinity** — `env_init_cleanup` runs on its env's own thread with the env alive (env-cleanup-hook contract), doing only `g_mutex`-guarded integer/list work and `free` — no env-affine napi calls, no cross-thread napi. The init-record hook is registered on the env's own thread. Consistent with the round-11/12 per-engine hook design.
+7. **Deadlock/adoption state machine (`TEARDOWN_*`, `g_teardown_cancelled`, the waiter)** — untouched; the reached-zero body it hooks into is the same, now shared via `isolate_ref_release_n_locked`.
+8. **Sanctioned 1:1 usage is behavior-identical** — one env, one `initialize()` (`init_refs 1`, hook registered), one engine, one `cleanup()` (`init_refs 0`, `g_ref_count 0`, teardown as today). All existing round-1..12 tests must stay green with no assertion changes.
+
+## Testing
+
+Real-addon integration tests under `native-lib/node/tests/integration/` (no `vi.mock` of `ffi`), mirroring `instance-lifecycle.test.ts`'s ref-count proxy technique (a subsequent raw engine call throwing `/not initialized/` proves the isolate reached zero refs and was torn down; a call that succeeds proves it is still alive).
+
+1. **Raw multi-engine-per-init does not prematurely tear down (the #5 core).** On one env (the main test thread): `ffi.initialize()` **once**, then `ffi.createEngine()` **twice** (handles h1, h2). Run a script on h2 to prove the isolate is live. `ffi.destroyEngine(h1)` — the isolate must remain alive: a run on h2 still succeeds. Then `ffi.destroyEngine(h2)` and one `ffi.cleanup()` (the single init reference). Now a fresh raw engine call must observe `/not initialized/`. *Pre-fix predicted behavior: acceptable here because destroyEngine (not the env hook) drives per-engine teardown and does not release the ref — so this test alone does not isolate #5; it guards that the multi-engine-per-init shape stays live under partial destroy.* **Primary #5 regression is test 2.**
+2. **Over-`cleanup()` from an env cannot steal a reference / tear down under a live user.** `ffi.initialize()` once, `ffi.createEngine()` (h). Call `ffi.cleanup()` **twice**. The first releases this env's one reference (isolate torn down — this env owned exactly one). The second must be a **no-op** (`init_refs` already 0): it must not throw, and — critically — must not drive `g_ref_count` negative or perturb a *subsequently* re-initialized isolate. Prove: after the double-cleanup, `ffi.initialize()` again + `createEngine` + run succeeds (the second cleanup did not corrupt the count), then balance with one `cleanup()` and assert `/not initialized/`.
+3. **Symmetric-ownership proof via the module API (regression guard for sanctioned path).** The existing `instance-lifecycle.test.ts` ref-count-proxy tests (napi_cleanup refactor; revived-singleton) must remain green unchanged — they already assert the 1:1 path tears down to zero. Add one assertion-level note only if needed; no new test required if these cover it.
+4. **Worker abandonment still releases (round-12 #2 behavior preserved).** The existing `worker-lifecycle.test.ts` "N Workers exit without cleanup" test must remain green: each Worker does one `initialize()` + one engine, so its env-death `env_init_cleanup` releases exactly one reference — identical net behavior to the round-12 `deferred_ref_release` path it replaces. (If review round-4 Finding #1's stronger zero-reference assertion is added in a separate round, it must still pass here.)
+
+All tests balance shared isolate state (final `cleanup()` / `/not initialized/` probe) so they do not perturb sibling integration files sharing the vitest worker process. Full Node suite target: **895 passed / 59 skipped / 0 failed** plus the new tests (2 new integration tests → **897 passed / 59 skipped / 0 failed**), unless a new test file adds more.
+
+## Rejected alternatives
+
+- **Enforce one engine per `initialize()` at the addon boundary (review option 1).** Rejected: rejects valid raw multi-engine-per-init usage, and still requires per-init tracking to detect "this env already has a live engine under its current init reference" — no simpler than per-env accounting, strictly more restrictive.
+- **Make the raw addon private/inaccessible (review option 3).** Rejected: `dwlib_addon.node` is a file on disk; any consumer can `require()` it. Narrowing the package's documented surface is a docs change that leaves the underlying C hazard intact — effectively won't-fix.
+- **Reference-count per engine instead of per env.** Rejected: the reference semantically belongs to `initialize()` (isolate lifetime), not to an engine (Java registry entry lifetime). Coupling it to engines is exactly the mispairing that caused #5.
+- **Keep `deferred_ref_release` and additionally cap releases at the env's engine count.** Rejected: still keyed on engines, still lets an abandoned env with more engines than its true init count over-release; per-env accounting is the correct key.
+- **Store the init record via `napi_set_instance_data`.** Rejected: `napi_set_instance_data` is single-slot per env and may already be reserved by future addon needs; a `g_mutex`-guarded list mirrors the existing `g_bridges` pattern the codebase already reasons about, and is visible to the cross-env teardown decision that instance-data (env-local) is not.
diff --git a/docs/superpowers/specs/2026-08-21-review5-teardown-and-admission-hardening-design.md b/docs/superpowers/specs/2026-08-21-review5-teardown-and-admission-hardening-design.md
new file mode 100644
index 00000000..c15af492
--- /dev/null
+++ b/docs/superpowers/specs/2026-08-21-review5-teardown-and-admission-hardening-design.md
@@ -0,0 +1,236 @@
+# Review #5 Remediation — Engine-Creation Admission + Teardown-Failure Recovery + Regression-Test Strength
+
+**Date:** 2026-08-21
+**Branch:** `w-23692110-multi-engine-design` (PR #157)
+**Round:** 14
+**Addresses:** `docs/pr-157-follow-up-code-review-5.md` (1 High, 5 Medium, 1 Low)
+
+## Context
+
+PR #157 ships the multi-engine Node binding for the DataWeave native library. Round 13 replaced the unsafe per-engine init-reference release with per-`napi_env` init-reference ownership, establishing the invariant **`g_ref_count == Σ (per-env init_refs)`**. Review #5 confirms that fix is correct and turns to three residual risk areas: engine-creation admission (a live concurrency hole), teardown-failure recovery (a live but owner-less isolate can be stranded), and regression-test strength (the round-13 tests do not actually pin the round-12 defect).
+
+The reviewed head is `bd68c70` — the exact round-13 HEAD. The subsequent master merge (`212424d`) touched only `native-lib/python/**` and a `package-lock.json` dep bump, so every line reference in the review is still accurate against the current tree.
+
+This round is **Node-binding only**. It does not touch `native-lib/python/**`, the legacy singleton entrypoints (`run_script`, `run_script_callback`, `run_script_input_output_callback`), `dw_napi_run_script`, or `ScriptRuntime.getInstance()`. The Java side is unchanged. Handle width stays C `long long`. Errors surface as resolved JSON strings (async) or synchronous `napi_throw_error` / thrown `DataWeaveError` — never `napi_reject_deferred`. `napi_env`/`napi_ref`/`napi_deferred`/`napi_threadsafe_function` are thread-affine to the env's JS thread; no env-affine napi call is made from the waiter or a wrong thread.
+
+**Preserved invariant (every g_mutex release):** `g_ref_count == Σ per-env init_refs`. No fix in this round resurrects a reference that no env owns.
+
+## Findings and Fixes
+
+### #1 (High) — engine creation can attach to an isolate being torn down
+
+**Defect.** `napi_create_engine` (addon.c:1837–1923) and `napi_create_engine_with_resolver` (addon.c:1926+) test `g_initialized` **outside** `g_mutex`, then call `fn_attach_thread(g_isolate, …)` and `fn_create_engine(…)` with (a) no requirement that the calling `napi_env` owns an init reference, and (b) no `g_active_ops` reservation pinning the isolate across the attach. An env that never called `initialize()` (or that already released its reference) can observe a still-`g_initialized` isolate while another env drops the final reference and the waiter/cleanup thread begins `graal_tear_down_isolate()`. The create then attaches to / creates an engine on a tearing-down isolate — a use-after-free.
+
+**Fix.** Mirror the proven admission pattern already used by `bridge_finalize_registry` (addon.c:286–313): perform the lifecycle check and the reservation in **one critical section** under `g_mutex`, at the top of each create function:
+
+```c
+uv_mutex_lock(&g_mutex);
+// Admission (one critical section — no teardown can interleave between the
+// checks and the reservation, because every teardown transition and the
+// g_active_ops==0 fast path also hold g_mutex):
+//  (1) isolate must be live and NOT past the point of no return,
+//  (2) the CALLING env must own an init reference (round-13 ownership model:
+//      an env with no reference must not create engines on the shared isolate),
+//  (3) pin the live isolate for the duration of the attach/create.
+env_init_rec_t* self = env_init_rec_find_locked(env);
+if (!g_initialized || g_isolate == NULL ||
+    g_teardown_state == TEARDOWN_TEARING_DOWN ||
+    self == NULL || self->init_refs == 0) {
+  uv_mutex_unlock(&g_mutex);
+  napi_throw_error(env, NULL, "Not initialized. Call initialize() first.");
+  return NULL;
+}
+g_active_ops++;  // pins the live isolate against teardown across the attach
+uv_mutex_unlock(&g_mutex);
+```
+
+After this point, the existing attach/create/detach body runs unchanged, and the `g_active_ops` reservation is **released on every path that leaves the function after the reservation was taken** — success and each failure branch — with the verbatim pattern used everywhere else:
+
+```c
+uv_mutex_lock(&g_mutex); g_active_ops--; uv_cond_broadcast(&g_teardown_cond); uv_mutex_unlock(&g_mutex);
+```
+
+The `fn_create_engine`/`fn_create_engine_with_resolver`/`fn_attach_thread` availability checks (`if (!fn_create_engine) …`) move to *before* the lock (they throw without having taken the reservation) or stay after with the release — the implementer picks whichever keeps the diff minimal, provided every post-reservation exit balances `g_active_ops`.
+
+**Consequence for the record/hook-registration tail.** The existing OOM/hook-failure rollback paths in both create functions (the `calloc`-failure and `napi_add_env_cleanup_hook`-failure branches) must release the `g_active_ops` reservation in addition to their current cleanup (destroy the created engine, unlink, finalize). The reservation is released once, right before the function returns, on both the success path (after `napi_create_int64` produces the return value) and every failure path.
+
+**Retires a caveat.** Round-13's `env_init_cleanup` header documents a "pathological raw-ffi order" where `createEngine()` on env B succeeds because env A already initialized, *before* B's own `initialize()`. With requirement (2), that call is now correctly **rejected** (B owns no reference), so the caveat's premise no longer holds. Update that comment to note the create path now enforces per-env ownership.
+
+**Confirm during review:**
+- The lifecycle check and `g_active_ops++` are in one `g_mutex` critical section; no teardown transition can split them.
+- Every exit after the reservation balances `g_active_ops` exactly once (no double-decrement, no leak). Count the paths: success, invalid-handle, calloc-fail, hook-fail (create-engine); success, invalid-handle, attach-fail, calloc-fail, reference-fail, hook-fail (resolver variant — note attach-fail and the alloc failures *before* the reservation is taken must NOT decrement).
+- An env with `init_refs == 0` (never initialized, or already cleaned up) is rejected with `Not initialized`.
+- `g_ref_count` is untouched by this fix (creation never mutated it post round-13); the invariant is unaffected.
+
+### #2 + #3 (Medium) — teardown-failure paths strand a live, owner-less isolate
+
+**Defect.** On a reached-zero release, three failure modes leave the isolate physically alive with `g_ref_count == 0` and no pending teardown:
+- **#2:** `release_isolate_ref_locked` Case 5 (addon.c:2607–2656) — `teardown_waiter_create` fails (promise/tsfn/resource-name N-API allocation) after `g_ref_count` was decremented to 0. Current code returns `NULL` (throws) with `g_teardown_state` reset to `TEARDOWN_NONE`. Also the Case 5 waiter **spawn** failure restores `g_ref_count = env_init_refs_total_locked()` (= 0) and leaves the isolate live.
+- **#3:** `isolate_ref_release_n_locked` (addon.c:2399–2452, called by `env_init_cleanup` on env death) — waiter thread spawn fails, or `cleanup_thread_fn` attach fails so `torn_down` stays 0. `g_ref_count` is restored to `env_init_refs_total_locked()` (= 0 when the dying env was the last), isolate stays live.
+
+In all three, `g_ref_count == 0` and no env record remains that could call `cleanup()` again, and no `g_teardown_state` is set — so nothing ever retries teardown. The isolate is stranded until an unrelated later `initialize()` happens to adopt it (which may never come). The round-13 invariant (`g_ref_count == Σ init_refs`) is correctly *preserved* by these paths, but preserving it is not sufficient: a zero-owner live isolate needs a retry owner.
+
+**Fix — a `g_mutex`-guarded retry flag, not a phantom reference.** Add:
+
+```c
+// Set under g_mutex when a reached-zero teardown could NOT be carried out
+// (waiter alloc/spawn failed, or cleanup_thread_fn attach failed) and the
+// isolate was therefore left live with g_ref_count == 0 and no pending
+// teardown. This is a RETRY SIGNAL, not an ownership reference: g_ref_count
+// stays 0 so the invariant g_ref_count == Σ init_refs is unaffected. It is
+// cleared when the isolate is (a) actually torn down, or (b) adopted by a
+// later initialize(). While set with g_active_ops > 0, the drain point at op
+// completion retries the teardown once ops reach 0.
+static bool g_teardown_needed = false;
+```
+
+Set `g_teardown_needed = true` in each of the three failure branches (#2 Case-5 waiter-create failure and waiter-spawn failure; #3 `isolate_ref_release_n_locked` waiter-spawn failure and `torn_down == 0` after the sync attempt) **only when** the isolate was left live (`g_isolate != NULL && g_ref_count == 0`).
+
+**Retry trigger at the op-completion drain point.** The natural retry owner is the last active op finishing. Add a helper that runs the reached-zero teardown decision:
+
+```c
+// Caller holds g_mutex, KEEPS it held. If a prior teardown failed and left the
+// isolate live with no owners (g_teardown_needed), and ops have now drained
+// (g_active_ops == 0) with still no owners (g_ref_count == 0) and no teardown
+// in progress, retry the synchronous teardown exactly as Case 4 does.
+static void retry_stranded_teardown_locked(void) {
+  if (!g_teardown_needed) return;
+  if (g_ref_count > 0) { g_teardown_needed = false; return; } // adopted → no retry
+  if (g_teardown_state != TEARDOWN_NONE) return;              // a teardown drives
+  if (g_active_ops > 0) return;                               // wait for drain
+  if (g_isolate == NULL) { g_teardown_needed = false; return; }
+  // g_active_ops == 0, g_ref_count == 0, isolate live: same synchronous
+  // teardown as Case 4 / isolate_ref_release_n_locked's g_active_ops==0 branch.
+  uv_thread_t tid; uv_thread_options_t opts;
+  opts.flags = UV_THREAD_HAS_STACK_SIZE; opts.stack_size = 2 * 1024 * 1024;
+  int torn_down = 0;
+  int spawn_rc = uv_thread_create_ex(&tid, &opts, cleanup_thread_fn, &torn_down);
+  if (spawn_rc == 0) uv_thread_join(&tid);
+  if (torn_down) {
+    g_thread = NULL; g_isolate = NULL; g_initialized = 0; g_ref_count = 0;
+    g_teardown_needed = false;
+  }
+  // else: spawn/attach failed again — leave g_teardown_needed set to retry on
+  // the next drain (or a later initialize() adoption clears it).
+}
+```
+
+Call `retry_stranded_teardown_locked()` under `g_mutex` at each op-completion drain point — i.e. immediately after the existing `g_active_ops--; uv_cond_broadcast(...)` blocks in the streaming/transform completion paths (the `bridge_end_op`/`g_active_ops--` sites). Since those sites already hold `g_mutex` for the decrement, fold the retry call into the same critical section (decrement, broadcast, then retry) to avoid re-locking.
+
+**Adoption clears the flag.** In `napi_initialize`'s adoption path (the `TEARDOWN_PENDING_WAIT` branch and the fast-path ref bump), and anywhere a new reference is acquired on a surviving isolate, set `g_teardown_needed = false` — a new owner means the isolate is wanted again. Concretely: whenever `env_init_acquire_and_hook` succeeds and `g_ref_count` transitions from 0 to 1 on a live isolate, clear the flag. The simplest correct placement is at the acquire sites right after a successful `g_ref_count++` on an already-live isolate.
+
+**Why a flag and not "restore caller ownership on alloc failure".** Restoring `self->init_refs` and `g_ref_count` on the failing env would (a) violate the caller's contract (the JS `cleanup()` promise resolves as if the reference was dropped, but the count says otherwise), and (b) for the env-death path (#3) the record is already freed — there is no env to restore ownership to. A separate retry signal decoupled from the reference count is the only model that works uniformly for both the live-caller and no-surviving-env cases while keeping `g_ref_count == Σ init_refs` exactly true.
+
+**Confirm during review:**
+- `g_teardown_needed` is read/written only under `g_mutex`.
+- The invariant `g_ref_count == Σ init_refs` holds at every g_mutex release — the flag never substitutes for a reference.
+- The retry is idempotent and bounded: it makes the reached-zero teardown decision at most once per drain, and a repeated attach failure simply re-arms for the next drain without spinning.
+- No env-affine napi call is made from any thread but the env's own (the retry runs on the JS thread at op completion; `cleanup_thread_fn` attaches its own GraalVM thread and makes no napi calls).
+- Adoption in `napi_initialize` clears the flag so a re-init does not later tear down a wanted isolate.
+- No deadlock: `retry_stranded_teardown_locked` spawns+joins `cleanup_thread_fn` while holding `g_mutex`, exactly as the existing Case-4 / `isolate_ref_release_n_locked` g_active_ops==0 branch does; `cleanup_thread_fn` takes no lock.
+
+### #4 (Medium) — cross-env regression test that actually pins the round-12 defect
+
+**Defect.** Round-13's `env-init-ownership.test.ts` are single-env smoke tests whose own header admits they pass on the pre-fix addon. `worker-lifecycle.test.ts`'s N-Worker test creates only **one** engine per Worker init, so it never exercises the round-12 over-release (N per-engine releases against one init reference).
+
+**Fix.** Add a Worker-based regression test to `worker-lifecycle.test.ts` (reusing its inline-JS-body + built-addon harness) that:
+1. On the main thread: `initialize()` and create a live engine (`h_main`), run a script to confirm it works.
+2. Spawn a Worker that: `initialize()` once, creates **N ≥ 3** engines (resolver-less is fine), runs a script on one, and exits **without** `cleanup()` and without destroying its engines — so the Worker env dies with N engines under one init reference.
+3. After the Worker exits: assert `h_main` **still runs** (`6 * 7 === 42`) — proving the shared isolate was not torn down by the Worker's env death.
+4. Balance the main reference (`destroyEngine(h_main)` + `cleanup()`), then assert a raw `runScriptEngine(Number.MAX_SAFE_INTEGER, …)` throws `/not initialized/i` — proving the count reached exactly zero (no leak, no over-release).
+
+**Determinism note in the test.** On the **round-12** implementation this goes RED: the Worker's env-death hooks fired N per-engine releases against a count of 1, driving `g_ref_count` negative/to-zero and tearing the isolate down under the live `h_main` → step 3's run fails (isolate gone) or the process wedges. On round-13+ each abandoned env releases exactly one reference regardless of engine count, so `h_main` survives. The test must await Worker `exit` (not just `message`) before asserting step 3, so the env-death hooks have run. Use the stricter `runWorker` helper from #5.
+
+The two existing `env-init-ownership.test.ts` smoke tests stay (they guard the single-env liveness path), but the file header's "known coverage gap … remains a follow-up" paragraph is updated to point at this new cross-env test as the gap's closure.
+
+**Confirm during review:**
+- The test loads the real built addon (no `vi.mock`), spawns a genuine Worker, and creates N ≥ 3 engines in it.
+- It awaits Worker exit before the post-exit assertions.
+- It balances all references so it does not perturb sibling integration files (main `cleanup()` at the end; the file's `afterAll` already calls `ffi.cleanup()` idempotently).
+- The RED-on-round-12 / green-on-round-13 reasoning is documented in a comment.
+
+### #5 (Medium) — Worker lifecycle helper hides a nonzero exit
+
+**Defect.** `runWorker` (worker-lifecycle.test.ts:71–83) resolves as soon as the Worker posts a message, and its `exit` handler only rejects `if (code !== 0 && !msg)`. A Worker that posts its success result and *then* exits nonzero (e.g. an env-cleanup-hook failure during teardown) resolves as success — the failure is hidden.
+
+**Fix.** Rework the promise so that:
+- The message is captured but resolution waits for `exit`.
+- On `exit`: reject **every** nonzero code (`new Error("Worker exited with code " + code + (msg ? "" : " and posted no message"))`).
+- On `exit` code 0 **with** a captured message: resolve with the message.
+- On `exit` code 0 **without** a message: reject as a distinct diagnostic (`"Worker exited 0 without posting a result"`).
+- Keep the `error` handler rejecting.
+
+All existing callers already `await` the result and assert `msg.ok`, so tightening resolution to `exit` is compatible; the abandon-variant Workers exit 0 after posting, so they still resolve.
+
+**Confirm during review:** no caller regresses; the N-Worker abandon test and the new #4 test both still pass; a hypothetical nonzero-exit Worker now rejects.
+
+### #6 (Medium) — `DataWeave.cleanup()` leaks the init reference if `destroyEngine()` throws
+
+**Defect.** `DataWeave.doCleanup()` (dataweave.ts:145–159) calls `ffi.destroyEngine(this.engineHandle)` before `await ffi.cleanup()`. If `destroyEngine` throws (a real path: wrong-thread destruction throws synchronously), the `finally` resets `this.state`/`this.engineHandle` but `ffi.cleanup()` never runs — the native init reference for this env is never released, and the engine handle is no longer reachable from the instance. The reference leaks.
+
+**Fix.** Ensure `ffi.cleanup()` runs even when `destroyEngine()` throws, preserving the primary (destruction) error:
+
+```ts
+private async doCleanup(): Promise<void> {
+  this.state = "cleaning-up";
+  let destroyError: unknown;
+  try {
+    if (this.engineHandle !== null) {
+      try {
+        ffi.destroyEngine(this.engineHandle);
+      } catch (e) {
+        // Preserve the primary error but STILL release the native init
+        // reference below — otherwise a throwing destroyEngine() (e.g.
+        // wrong-thread destruction) would strand this env's reference and
+        // block isolate teardown. The engine handle is cleared regardless so
+        // a retry does not double-destroy.
+        destroyError = e;
+      } finally {
+        this.engineHandle = null;
+      }
+    }
+    await ffi.cleanup();
+  } finally {
+    this.state = "uninitialized";
+  }
+  if (destroyError !== undefined) throw destroyError;
+}
+```
+
+The `await ffi.cleanup()` now always runs (releasing the reference); a destruction error is re-thrown after cleanup so callers still observe it. If `ffi.cleanup()` itself also throws, its error propagates from the `await` (the destruction error is then suppressed — acceptable: the reference-release failure is the more actionable one, and this matches the "report/suppress secondary" guidance).
+
+**Test.** Add a unit test (in the existing `dataweave.ts` unit suite, with `ffi` mocked) where `destroyEngine` is mocked to throw: assert (a) `ffi.cleanup()` was still called, (b) the original destruction error propagates from `cleanup()`, (c) `this.state` ends `uninitialized`.
+
+**Confirm during review:** `ffi.cleanup()` is invoked on the throwing-`destroyEngine` path; the primary error is preserved; `engineHandle` is cleared so a subsequent cleanup does not re-destroy; the coalescing/`cleanupPromise` logic in the public `cleanup()` wrapper is unaffected.
+
+### #7 (Low) — resolver quick-start examples omit cleanup
+
+**Defect.** `external-modules.md:7–25` and `README.md:231–253` show resolver-backed `DataWeave` instances with no `await dw.cleanup()`, though later docs state uncleaned instances retain their engine and resolver closure.
+
+**Fix.** Wrap each complete example's `dw.initialize()`/`dw.run()` in `try { … } finally { await dw.cleanup(); }` and make the surrounding scope `async` (or add a one-line note that the snippet runs inside an async function). Keep the example output comments intact.
+
+**Confirm during review:** both examples show `await dw.cleanup()` in a `finally`; the snippets remain runnable (async context noted); no other doc claims are altered.
+
+## Task Ordering
+
+1. **#1** — engine-creation admission (isolated, High, `addon.c`).
+2. **#2 + #3** — teardown-failure retry flag + drain-point retry + adoption clear (`addon.c`; shared machinery, done as one task).
+3. **#6** — `doCleanup()` reference-leak fix + unit test (`dataweave.ts`).
+4. **#5** — `runWorker` helper strictness (`worker-lifecycle.test.ts`).
+5. **#4** — cross-env Worker regression test (`worker-lifecycle.test.ts`; depends on #5's stricter helper).
+6. **#7** — docs cleanup (`external-modules.md`, `README.md`).
+
+Each task ends green on the full Node vitest suite. Baseline before this round: **897 passed / 59 skipped / 0 failed**. Net new tests: #6 (1 unit) + #4 (1 integration) → target **899 passed / 59 skipped / 0 failed** (the helper change in #5 alters no test count).
+
+## Build & Test
+
+- Build: `cd native-lib/node && npm run build:addon && npm run build:ts`
+- Test: `DATAWEAVE_NATIVE_LIB=/Users/lmariano/dev/mulesoft/data-weave-cli/native-lib/node/native/dwlib.dylib npm test`
+- `dwlib.dylib` is unchanged this round (only `addon.c`, `dataweave.ts`, tests, and docs change — no Java).
+
+## Rejected Alternatives
+
+- **#1: check `g_initialized` under the lock but skip the `g_active_ops` reservation.** Insufficient: the attach happens after the lock is dropped, so a teardown can still start between the check and `fn_attach_thread`. The reservation is what pins the isolate across the attach, exactly as `bridge_finalize_registry` does.
+- **#2/#3: restore the failing caller's ownership (`init_refs`/`g_ref_count`) instead of a flag.** Breaks the JS `cleanup()` contract (promise resolves as released while the count says held) and is impossible for the env-death path (the record is already freed). A retry signal decoupled from the count is the only uniform model.
+- **#2/#3: spawn a dedicated retry thread that polls until teardown succeeds.** Adds a background thread and a spin loop for a rare OOM/spawn-failure path; the op-completion drain point is a natural, already-locked retry owner with no new thread.
+- **#4: keep documenting the gap (round-13 decision).** The reviewer raised this class twice; the user chose to write the real cross-env test this round.
diff --git a/docs/superpowers/specs/2026-08-21-review6-singleton-stream-teardown-hardening-design.md b/docs/superpowers/specs/2026-08-21-review6-singleton-stream-teardown-hardening-design.md
new file mode 100644
index 00000000..4bcd5bf9
--- /dev/null
+++ b/docs/superpowers/specs/2026-08-21-review6-singleton-stream-teardown-hardening-design.md
@@ -0,0 +1,334 @@
+# Review #6 Remediation — Singleton, Stream, and Teardown Hardening (Round 15)
+
+**Status:** Design approved. Ready for implementation plan.
+
+**Scope decision (user):** Fix all 8 code findings (#1–#8). Finding #9 (Python-binding scope) is left as-is with a PR note, not a code change. Full pipeline (spec → plan → SDD). Standing finish: push + update PR #157.
+
+**Reviewed head:** `7017ded` (round-14 HEAD). All 8 code findings validated against live source before this design.
+
+---
+
+## Context
+
+`docs/pr-157-follow-up-code-review-6.md` raised 9 findings against PR #157 head `7017ded`. Eight are code fixes; #9 is a scope/process observation (the PR carries broad Python-binding modernization beyond the Node multi-engine change) handled by a PR comment, not code.
+
+The findings fall into three clusters plus one process note:
+
+- **Cluster A (TypeScript, 2 High):** a real user-facing singleton-poisoning bug (#1) and a real stream-hang bug (#2).
+- **Cluster B (C teardown, 2 Medium):** two hardening gaps (#3, #4) in the round-14 teardown machinery.
+- **Cluster C (C teardown design, 1 Medium):** the drain-reachability gap (#5) that round 14's own final reviewer flagged as a non-blocking observation.
+- **Cluster D (tests, 2 Medium + 1 Low):** test-hygiene fixes (#6, #7, #8) that keep the suite honest.
+
+**Preserved invariant (unchanged from round 14, binding on every C change here):**
+`g_ref_count == Σ per-env init_refs` at every `g_mutex` release. `g_teardown_needed` is a retry SIGNAL, not a reference — set only when `g_ref_count == 0` and the isolate is still live; never added to any count; read/written only under `g_mutex`.
+
+**Global constraints (carried from prior rounds):**
+- Node-binding only. Never touch `native-lib/python/**`, the Java side, or the legacy singleton entrypoints (`run_script`, `run_script_callback`, `run_script_input_output_callback`, `dw_napi_run_script`, `ScriptRuntime.getInstance()`).
+- Handle width stays C `long long`.
+- Errors surface as resolved JSON strings (async) or synchronous `napi_throw_error` / thrown `DataWeaveError` — never `napi_reject_deferred`.
+- `napi_env`/`napi_ref`/`napi_deferred`/`napi_threadsafe_function` are thread-affine to the env's JS thread; no env-affine napi call from the wrong thread.
+
+---
+
+## Cluster A — TypeScript user-facing bugs
+
+### #1 (High): a failed first module-level initialization permanently poisons the singleton
+
+**Defect:** `getGlobalInstance()` (`native-lib/node/src/dataweave.ts:366-372`) assigns `globalInstance` *before* `initialize()` succeeds:
+
+```ts
+function getGlobalInstance(): DataWeave {
+  if (!globalInstance) {
+    globalInstance = new DataWeave();
+    globalInstance.initialize();   // if this throws, globalInstance stays set-but-uninitialized
+    registerExitHooksOnce();
+  }
+  return globalInstance;
+}
+```
+
+If `initialize()` throws (bad `DATAWEAVE_NATIVE_LIB` path, transient native failure), the singleton remains a non-null, uninitialized `DataWeave`. Every later `run*()` reuses it and fails only with "not initialized" — even after the underlying cause is fixed.
+
+**Fix:** construct and initialize a *local candidate*; assign `globalInstance` only after `initialize()` returns; register exit hooks after the successful assignment.
+
+```ts
+function getGlobalInstance(): DataWeave {
+  if (!globalInstance) {
+    // Initialize a LOCAL candidate first; publish the singleton only after
+    // initialize() succeeds. A failed first init (bad lib path / transient
+    // native failure) must NOT leave a poisoned, uninitialized singleton that
+    // makes every later run*() fail "not initialized" even after the fault is
+    // fixed (review #6 #1). On throw, globalInstance stays null and the next
+    // call retries cleanly.
+    const candidate = new DataWeave();
+    candidate.initialize();
+    globalInstance = candidate;
+    registerExitHooksOnce();
+  }
+  return globalInstance;
+}
+```
+
+**Regression:** fail singleton init once (mock `ffi.initialize` to throw), assert the call rejects/throws and `globalInstance` was not published; then correct the fault (mock initialize to succeed) and assert the next `run()` builds a fresh working singleton.
+
+### #2 (High): a rejected native streaming promise can hang the consumer forever
+
+**Defect:** `streamFromNative()` (`native-lib/node/src/stream.ts:39-47`) wires only the fulfilled branch:
+
+```ts
+const metaPromise = start(chunkCb).then((raw) => {
+  metaRaw = raw;
+  done = true;
+  while (pendingResolves.length > 0) {
+    const resolve = pendingResolves.shift();
+    if (resolve) resolve();
+  }
+});
+```
+
+If `start()` rejects, `done` never becomes `true` and parked `next()` consumers (waiting on a `pendingResolves` promise, stream.ts:55) are never woken → the generator hangs forever. The rejection is also unhandled.
+
+**Fix:** handle both settlement branches — on rejection, record the error, set completion, wake all waiters. After the drain loop, if a start error was recorded, throw it (so the consumer sees a rejection, not a silent empty completion). Buffered chunks that arrived before the rejection still drain first.
+
+```ts
+  let startError: unknown;
+  const wakeAll = () => {
+    while (pendingResolves.length > 0) {
+      const resolve = pendingResolves.shift();
+      if (resolve) resolve();
+    }
+  };
+  const metaPromise = start(chunkCb).then(
+    (raw) => { metaRaw = raw; done = true; wakeAll(); },
+    (err) => {
+      // Native start() rejected. Without this branch, `done` stays false and a
+      // consumer parked in next() is never woken -> the generator hangs forever,
+      // and the rejection is unhandled (review #6 #2). Record the failure, mark
+      // completion, and wake every waiter; the error is re-thrown after draining
+      // any chunks that arrived before the rejection.
+      startError = err;
+      done = true;
+      wakeAll();
+    }
+  );
+
+  while (true) {
+    if (chunks.length > 0) { yield chunks.shift()!; continue; }
+    if (done) break;
+    await new Promise<void>((resolve) => { pendingResolves.push(resolve); });
+  }
+
+  while (chunks.length > 0) { yield chunks.shift()!; }
+
+  await metaPromise;              // settles (fulfilled) since we handled rejection above
+  if (startError !== undefined) throw startError;
+  return parseStreamingResult(metaRaw ?? "");
+```
+
+Note: because the `.then(onFulfilled, onRejected)` form handles rejection, `metaPromise` itself always fulfills, so `await metaPromise` never throws and there is no unhandled rejection. The consumer-visible error is the explicit `throw startError`.
+
+**Regression:** `start: () => Promise.reject(new Error("native start boom"))` with a consumer that is already parked in `next()` before the rejection settles — assert `next()` (or the `for await`) rejects with the error and does not hang. A second test: chunks buffered then rejection — assert buffered chunks yield first, then it throws.
+
+---
+
+## Cluster B — C teardown hardening
+
+### #3 (Medium): isolate teardown reports success even when Graal teardown fails
+
+**Defect:** both teardown sites treat calling `graal_tear_down_isolate()` as success without checking its `int` return (`typedef int (*graal_tear_down_isolate_fn)(void*)`, addon.c:12):
+
+- `cleanup_thread_fn` (addon.c:2332): `fn_tear_down_isolate(local_thread); *out_torn_down = 1;`
+- `teardown_waiter_thread_fn` (addon.c:2366-2368): `fn_tear_down_isolate(local_thread); torn_down = true;` (comment at 2360 literally says "Ignore the return code, matching today's behavior.")
+
+If teardown returns nonzero, the callers still clear `g_isolate`/`g_initialized`/`g_ref_count` as if the isolate is gone — orphaning a live isolate and allowing a *second* `graal_create_isolate` in the same process (unsupported).
+
+**Fix:** set `torn_down` only when the call returns 0.
+
+- `cleanup_thread_fn`:
+  ```c
+  *out_torn_down = (fn_tear_down_isolate(local_thread) == 0) ? 1 : 0;
+  // Nonzero: teardown failed, isolate still live -- leave *out_torn_down = 0 so
+  // the caller retains g_isolate/g_initialized and arms the retry (review #6 #3).
+  ```
+- `teardown_waiter_thread_fn`:
+  ```c
+  torn_down = (fn_tear_down_isolate(local_thread) == 0);
+  ```
+  Update the stale comment at 2360.
+
+The existing "attach failed → leave torn_down 0" paths already handle the retained-live-isolate case correctly; #3 just extends that to the "attach succeeded but teardown returned nonzero" case. Arming the retry on a nonzero teardown is handled together with #4 below (both are in `teardown_waiter_thread_fn`'s post-teardown block).
+
+### #4 (Medium): async teardown-waiter attach failure leaves an ownerless isolate without retry
+
+**Defect:** in `teardown_waiter_thread_fn`'s post-teardown lock (addon.c:2379-2389), when `!cancelled && !torn_down` (attach failed, or — after #3 — teardown returned nonzero), the code leaves `g_ref_count == 0`, no owner, no pending waiter, `g_teardown_state = TEARDOWN_NONE`, and does *not* arm `g_teardown_needed`. The comment claims "retried on the next last release" — but this async waiter path IS the last-release path (`isolate_ref_release_n_locked`'s `g_active_ops > 0` branch spawned it). There is no future last-release; the isolate is stranded with no retry signal.
+
+**Fix:** in that post-teardown block, when teardown did not happen and the isolate is still live with zero owners, arm the retry signal:
+
+```c
+  uv_mutex_lock(&g_mutex);
+  if (!cancelled && torn_down) {
+    g_thread = NULL;
+    g_isolate = NULL;
+    g_initialized = 0;
+    g_ref_count = 0;
+  } else if (!cancelled && g_isolate != NULL && g_ref_count == 0) {
+    // Teardown did not happen (attach failed, or graal_tear_down_isolate
+    // returned nonzero -- review #6 #3) and this async-waiter path IS the
+    // last release: g_ref_count is already 0 with no owner and no pending
+    // waiter. Arm the retry signal so a later op-completion drain or an
+    // initialize() retries teardown -- otherwise the live isolate is stranded
+    // with nothing to reclaim it (review #6 #4).
+    g_teardown_needed = true;
+  }
+  g_teardown_state = TEARDOWN_NONE;
+  g_teardown_cancelled = false;
+  ...
+```
+
+This mirrors the arm already present in `isolate_ref_release_n_locked`'s waiter-spawn-failure path (addon.c:2570) and Case-4 sync-failure path.
+
+---
+
+## Cluster C — the #5 drain-reachability gap
+
+### #5 (Medium): stranded-teardown retry is not guaranteed to run when no operation remains
+
+**Defect:** the zero-active-op synchronous failure paths arm `g_teardown_needed`:
+- `isolate_ref_release_n_locked` sync branch (addon.c:2543-2548)
+- `release_isolate_ref_locked` Case-4 (addon.c:2725)
+
+But `retry_stranded_teardown_locked()` is called ONLY from the streaming (addon.c:967) and transform op-completion drains. In the zero-op state there is no pending operation to drain, so the retry never fires. Worse, a later `initialize()` currently *adopts* the isolate and clears the flag (the fast-path / adoption clears at addon.c:623/643/724) instead of completing the pending teardown. `cleanup()` has already resolved, so from the caller's view the reference was released — but the isolate the retry was meant to reclaim is silently kept alive and its retry intent discarded.
+
+**Chosen fix (user decision): make the next `initialize()` complete the pending teardown before adopting — no new async infrastructure.**
+
+At the top of `napi_initialize`, under `g_mutex`, before the existing adoption / fast-path / create-path logic: if `g_teardown_needed` is set (a prior teardown failed and the isolate is stranded with zero owners), call `retry_stranded_teardown_locked()` first.
+
+- If the retry succeeds, `g_isolate` becomes `NULL` and `g_initialized` becomes 0 → `napi_initialize` falls through to the create path and builds a fresh isolate. The pending teardown is honored, not discarded.
+- If the retry fails again (spawn/attach/teardown still failing), the isolate is still live; `napi_initialize` proceeds to adopt it via the existing fast path (which clears the now-still-set flag). Adopting a live isolate whose teardown was merely resource-reclamation (not a malfunction) is safe and functionally identical to normal adoption.
+
+```c
+  uv_mutex_lock(&g_mutex);
+  // A prior last-release could not tear the isolate down and armed the retry
+  // signal (review #6 #3/#4). Because retries otherwise fire only at op
+  // completion, a zero-op stranded isolate would never be reclaimed and a naive
+  // adoption below would silently discard the pending teardown (review #6 #5).
+  // Drive the pending teardown to completion here first: on success g_isolate is
+  // cleared and we build a fresh isolate below; on repeated failure the live
+  // isolate is adopted by the fast path (safe -- teardown was reclamation, not a
+  // malfunction).
+  retry_stranded_teardown_locked();
+  // ... existing TEARDOWN_PENDING_WAIT adoption / fast-path / create-path logic ...
+```
+
+`retry_stranded_teardown_locked()` already no-ops safely when `g_teardown_needed` is false, when `g_active_ops > 0`, or when a teardown is in progress — so this call is a cheap guard on the common path (flag clear → immediate return).
+
+**Documented residual degradation (accepted):** if a teardown fails AND no later `initialize()` or streaming/transform op ever occurs, the stranded isolate lingers until process exit, where the OS reclaims it. This is benign (a single process-lifetime isolate, no correctness or reference-count violation) and is the deliberate tradeoff for avoiding event-loop-affine async retry infrastructure on this concurrency-sensitive code. This residual is documented in a comment at the arming sites and in the spec's Rejected Alternatives.
+
+---
+
+## Cluster D — test hardening
+
+### #6 (Medium): Worker clean-lifecycle scenarios suppress explicit engine-destruction errors
+
+**Defect:** in `runWorker`'s worker body (`native-lib/node/tests/integration/worker-lifecycle.test.ts:62-65`), the `cleanup: true` path swallows `destroyEngine` errors:
+
+```js
+if (workerData.cleanup) {
+  try { addon.destroyEngine(handle); } catch (_) {}
+  await addon.cleanup();
+}
+```
+
+A broken explicit-destruction path can be masked by the subsequent `addon.cleanup()`, so a "clean lifecycle" test still passes.
+
+**Fix:** capture the destruction error, still run `addon.cleanup()` in a `finally`, then fold the original error into the posted message (so the stricter `runWorker` exit handling and the caller's `msg.ok` assertion surface it):
+
+```js
+if (workerData.cleanup) {
+  let destroyErr;
+  try {
+    addon.destroyEngine(handle);
+  } catch (e) {
+    destroyErr = e;   // preserve; do NOT let cleanup() mask a broken destroy path
+  } finally {
+    await addon.cleanup();
+  }
+  if (destroyErr) msg = { ok: false, error: "destroyEngine failed: " + String(destroyErr) };
+}
+```
+
+This keeps all existing clean-path Workers green (destroy succeeds → `destroyErr` undefined → `msg` unchanged) while surfacing a real destruction failure as `ok: false`.
+
+### #7 (Medium): the cross-env regression can contaminate later tests on failure
+
+**Defect:** the round-14 cross-env test (`worker-lifecycle.test.ts:209-272`) acquires `hMain` and a main-thread init reference with no `try/finally`. Any Worker or assertion failure before the final `destroyEngine(hMain)` + `cleanup()` leaves global native state (live isolate, held reference) for subsequent tests.
+
+**Fix:** wrap the test body in `try/finally`. In `finally`, destroy `hMain` if it was acquired and balance the main init reference (`await ffi.cleanup()`), guarded so the balancing does not throw over and mask an original assertion failure:
+
+```ts
+    let hMain: number | null = null;
+    try {
+      ffi.initialize(LIB_PATH);
+      hMain = ffi.createEngine();
+      // ... existing test body, using hMain ...
+    } finally {
+      // Balance global native state even if a Worker/assertion failed above, so
+      // this test cannot strand a live isolate + held reference for sibling
+      // integration tests (review #6 #7). Do not let cleanup errors mask the
+      // original failure.
+      try {
+        if (hMain !== null) ffi.destroyEngine(hMain);
+        await ffi.cleanup();
+      } catch { /* balancing best-effort; original failure (if any) propagates */ }
+    }
+```
+
+The final positive assertions (main engine survives; raw op throws `/not initialized/i` after balancing) stay in the `try` so the test still proves what it did before; only the reference balancing moves to `finally`. Because the `finally` now always balances, the `/not initialized/i` probe must run inside `try` *before* the finally's cleanup (it already does — it is the last positive step of the body). The RED-on-round-12 behavior is unchanged: the main-engine survival assertion still fails on round-12.
+
+### #8 (Low): the initialization unit test can falsely pass when reinitialization is a no-op
+
+**Defect:** `dataweave-initialize.test.ts:248-252` asserts a second `initialize()` via `toHaveBeenLastCalledWith()`, but the *first* `initialize()` already called `createEngine()` with the same (no) arguments — so the assertion passes even if the second init created no engine.
+
+**Fix:** clear the `createEngine` mock before the re-initialization (`vi.mocked(ffi.createEngine).mockClear()`), or assert the call count went from 1 to 2. The design uses `mockClear()` before the second `initialize()` plus `expect(ffi.createEngine).toHaveBeenCalledTimes(1)` after, proving the re-init genuinely created a fresh engine.
+
+---
+
+## File / task structure
+
+Each task ends with an independently testable deliverable and a fresh reviewer gate.
+
+| Task | Finding(s) | Files | Test |
+|------|-----------|-------|------|
+| 1 | #1 | `src/dataweave.ts` (`getGlobalInstance`) | `tests/unit/dataweave-initialize.test.ts` (+1) |
+| 2 | #2 | `src/stream.ts` (`streamFromNative`) | `tests/unit/stream.test.ts` (+2) |
+| 3 | #3, #4 | `src/addon.c` (`cleanup_thread_fn`, `teardown_waiter_thread_fn`) | error-path C hardening; suite unchanged |
+| 4 | #5 | `src/addon.c` (`napi_initialize`) | error-path C hardening; suite unchanged |
+| 5 | #6, #7 | `tests/integration/worker-lifecycle.test.ts` | suite unchanged (all green paths still pass) |
+| 6 | #8 | `tests/unit/dataweave-initialize.test.ts` | tightened assertion; suite unchanged |
+
+**Task ordering rationale:**
+- Tasks 1 and 6 both touch `dataweave-initialize.test.ts`; Task 1 *appends* a new test, Task 6 *tightens an existing* test — no overlap, but Task 6 runs after Task 1 to avoid a stale line-anchor.
+- Tasks 3 and 4 both touch `addon.c` teardown machinery; 3 (thread-fn return codes + arm) precedes 4 (`napi_initialize` drives the retry), since 4's fix relies on 3's arming being correct.
+- Task 5's two changes (#6, #7) are in one file and reviewed together.
+
+**Expected suite deltas:** Task 1 +1 unit, Task 2 +2 unit; Tasks 3–6 no count change (error-path C hardening + test tightening). Round-14 baseline 899/59/0 → **902/59/0** after this round.
+
+---
+
+## Verification (end-to-end)
+
+1. `cd native-lib/node && npm run build:addon` — clean, no new warnings in `cleanup_thread_fn`, `teardown_waiter_thread_fn`, or `napi_initialize`. `npm run build:ts` clean.
+2. `npm test` (with `DATAWEAVE_NATIVE_LIB` set) — **902 passed / 59 skipped / 0 failed**.
+3. **Invariant audit (review gate):** every `g_ref_count` mutation still paired with an `init_refs` mutation or a rollback to `env_init_refs_total_locked()`/0; `g_teardown_needed` set only when `g_ref_count == 0`, never added to a count; all new shared-state access under `g_mutex`. The #3 return-code check must never clear `g_isolate`/`g_initialized`/`g_ref_count` on a nonzero teardown.
+4. #1/#2 regressions genuinely reproduce the bug (fail on the pre-fix code): singleton stays poisoned; stream hangs/rejects unhandled.
+5. `git diff --check` — no whitespace errors.
+
+---
+
+## Rejected Alternatives
+
+- **#1: reset `globalInstance = null` in a `catch` inside `getGlobalInstance` instead of a local candidate.** Works, but the local-candidate pattern is clearer (the singleton is never observably set to a bad value, even transiently across an `await` boundary elsewhere) and matches the "construct-then-publish" idiom the reviewer requested.
+- **#2: reject via `napi_reject_deferred` / a rejected returned promise from the generator.** The generator contract is to throw from `next()`; the codebase deliberately surfaces errors as thrown values, not rejected deferreds (global constraint). An explicit `throw startError` after draining is the idiomatic fit.
+- **#5: dedicated async retry owner (uv_async / uv_timer).** Fully closes the no-future-init-or-op residual, but adds event-loop-affine async infrastructure and new concurrency surface to the most sensitive code in the binding. The user chose init-driven completion + documented degradation as the lower-risk option; the residual (isolate lingers to process exit if nothing else ever happens) is benign.
+- **#5: block `napi_initialize` until the pending teardown physically completes on a helper thread even when it keeps failing.** Could deadlock or spin on a persistently failing `graal_tear_down_isolate`; adopting the live isolate after one retry attempt is safe and bounded.
+- **#9: split the Python-binding work into its own PR now.** User chose to leave the PR as-is and note the bundling in a PR comment; no git surgery this round.
diff --git a/native-lib/node/README.md b/native-lib/node/README.md
index 3f135c41..83a2e250 100644
--- a/native-lib/node/README.md
+++ b/native-lib/node/README.md
@@ -188,15 +188,15 @@ for await (const chunk of generator) {
 
 **Returns:** `StreamingResult`
 
-#### `cleanup(): void`
+#### `cleanup(): Promise<void>`
 
-Clean up the global DataWeave runtime instance. Called automatically on process exit.
+Clean up the global DataWeave runtime instance. Called automatically on process shutdown via two hooks: `beforeExit` awaits it, so a streaming/transform operation still in flight drains gracefully before the process exits normally; `exit` is a synchronous last-ditch fallback for `process.exit()` and uncaught exceptions — cases where `beforeExit` never fires — and cannot await the drain. Neither hook fires on `SIGTERM`, `SIGINT`, or `SIGKILL` (Node does not emit `exit` for signals), so install your own signal handler that calls `cleanup()` if you need a graceful drain on termination. Called manually, it releases this instance's reference to the native runtime; the shared native isolate is torn down only when the **last** initialized instance in the process is released. When this call releases that final reference, it resolves once native teardown has actually finished, waiting for any still-in-flight streaming/transform operation to drain first; otherwise (other instances remain initialized) it resolves as soon as this instance is released, without draining process-wide work.
 
 ```javascript
 import { cleanup } from '@dataweave/native';
 
 // Manual cleanup (usually not needed)
-cleanup();
+await cleanup();
 ```
 
 ### Class-Based API
@@ -213,13 +213,13 @@ try {
   const result = dw.run('2 + 2');
   console.log(result.getString());
 } finally {
-  dw.cleanup();
+  await dw.cleanup();
 }
 ```
 
 **Methods:**
 - `initialize()`: Initialize the native library
-- `cleanup()`: Release native resources
+- `cleanup(): Promise<void>`: Release native resources; resolves once native teardown finishes
 - `run(script, inputs?, opts?)`: Same as module-level `run()`
 - `runStreaming(script, inputs?)`: Same as module-level `runStreaming()`
 - `runTransform(script, input, opts?)`: Same as module-level `runTransform()`
@@ -231,6 +231,7 @@ DataWeave scripts can import external modules using the `resolveModule` option.
 ```typescript
 import { DataWeave, composeResolvers, modulesFromDirectory, modulesFromJars } from '@dataweave/native';
 
+// Inside an async function (uses `await` for modulesFromJars and cleanup()).
 const dw = new DataWeave({
   resolveModule: composeResolvers(
     modulesFromDirectory('./my-modules'),
@@ -238,17 +239,21 @@ const dw = new DataWeave({
   )
 });
 dw.initialize();
-
-const result = dw.run(`
-  %dw 2.0
-  import org::company::utils
-  output application/json
-  ---
-  utils::doSomething()
-`);
-
-if (result.success) {
-  console.log(result.getString());
+try {
+  const result = dw.run(`
+    %dw 2.0
+    import org::company::utils
+    output application/json
+    ---
+    utils::doSomething()
+  `);
+
+  if (result.success) {
+    console.log(result.getString());
+  }
+} finally {
+  // Release the engine and resolver closure when done.
+  await dw.cleanup();
 }
 ```
 
@@ -444,16 +449,16 @@ The Node.js binding uses **N-API** (Node-API) for C addon integration:
 
 **Important:** Do not share a single `DataWeave` instance across Worker threads. Use the module-level functions (which use a global singleton) or create separate instances per thread.
 
-**Custom module resolvers and Worker threads:** the native layer installs at
-most one resolver callback for the whole process lifetime, and it is bound to
-the Worker (main thread or a `worker_threads` Worker) that registered it
-first — see [External Modules: Multiple Resolvers](docs/external-modules.md#multiple-resolvers-in-one-process).
+**Custom module resolvers and Worker threads:** each resolver-backed
+`DataWeave` instance's native engine is bound to the thread that created it
+(main thread or a `worker_threads` Worker) — see
+[External Modules: Multiple Independent Engines](docs/external-modules.md#multiple-independent-engines).
 Custom-module resolution attempted from any *other* thread is not routed to
-that thread's own `resolveModule` callback; it silently falls back to
-built-in modules only (custom module paths resolve as "not found" rather than
-crashing or hanging). If you need per-Worker custom modules, resolve them on
-the thread that first constructs a resolver-backed `DataWeave` instance, or
-avoid resolver-backed instances in worker pools altogether.
+that engine's `resolveModule` callback; it silently falls back to built-in
+modules only (custom module paths resolve as "not found" rather than
+crashing or hanging). If you need custom modules on multiple Workers,
+construct and use a separate resolver-backed `DataWeave` instance on each
+Worker, created on that Worker itself.
 
 ## Platform Support
 
diff --git a/native-lib/node/docs/external-modules.md b/native-lib/node/docs/external-modules.md
index 6b67ae91..791df617 100644
--- a/native-lib/node/docs/external-modules.md
+++ b/native-lib/node/docs/external-modules.md
@@ -7,26 +7,32 @@ DataWeave scripts can import external modules using the `resolveModule` option.
 ```typescript
 import { DataWeave, modulesFromMap } from '@dataweave/native';
 
+// Inside an async function so `await dw.cleanup()` is available.
 const dw = new DataWeave({
   resolveModule: modulesFromMap({
     'org/company/lib.dwl': '%dw 2.0\nfun greet(n) = "Hello " ++ n',
   }),
 });
 dw.initialize();
-
-const result = dw.run(`
-  %dw 2.0
-  import org::company::lib
-  output application/json
-  ---
-  lib::greet("World")
-`);
-console.log(result.getString());  // "Hello World"
+try {
+  const result = dw.run(`
+    %dw 2.0
+    import org::company::lib
+    output application/json
+    ---
+    lib::greet("World")
+  `);
+  console.log(result.getString());  // "Hello World"
+} finally {
+  // Release the engine and the resolver closure; an uncleaned instance retains
+  // both (see the lifecycle notes below).
+  await dw.cleanup();
+}
 ```
 
 **Important:** The module-level convenience functions (`run()`, `runStreaming()`, `runTransform()` exported directly from `@dataweave/native`) operate on a lazily-initialized singleton that takes no constructor options and therefore cannot be configured with `resolveModule` — you **must** construct your own `DataWeave` instance to use external modules, as shown above.
 
-Additionally, external module resolution is currently supported only through `.run()` (the synchronous API). `.runStreaming()` and `.runTransform()` do not yet support external modules and will only have access to built-in modules.
+Additionally, external module resolution is currently supported only through `.run()` (the synchronous API). For a resolver-backed engine, `.runStreaming()` and `.runTransform()` execute on a background thread and cannot invoke that engine's `resolveModule` callback — they always resolve only built-in modules, and any custom-module import fails closed (module "not found") rather than crashing or hanging.
 
 ## Resolver Factories
 
@@ -113,7 +119,7 @@ Best for: Layered resolution with fallbacks (overrides, shared libraries, vendor
 
 ## How It Works
 
-- **One resolver per process**: The native engine maintains a single resolver per process lifetime. Only the first resolver registered is used; subsequent `DataWeave` instances with different resolvers will silently reuse the first one.
+- **Independent engines**: each `DataWeave` instance owns its own native engine, resolver, and script cache; instances with different resolvers coexist with no cross-talk.
 - **Resolution at compile time**: The resolver is invoked during script compilation, not per execution.
 - **Synchronous resolution**: The resolver callback must be synchronous (no `async`/`await`, no Promise return).
 - **Built-in modules**: Built-in modules (CompositeResolver) are always available and work alongside custom resolvers.
@@ -173,70 +179,62 @@ if (!result.success) {
 
 **Debugging:** By default, a resolver failure logs only a fixed, content-free diagnostic line to stderr — the actual exception message and stack are suppressed, since they can carry resolver-controlled data (module source, credentials, filesystem paths). To see the detailed message and stack for diagnosing a failing resolver (e.g., directory does not exist, file unreadable due to permissions), set `DATAWEAVE_RESOLVER_DEBUG=1` in the process environment before running. Only enable this in a trusted debugging context, since the detailed output may expose sensitive resolver-controlled data.
 
-### Multiple Resolvers in One Process
-
-If you construct multiple `DataWeave` instances with different resolvers in the same process:
-
-```typescript
-const dw1 = new DataWeave({
-  resolveModule: modulesFromMap({ 'a.dwl': '...' }),
-});
-dw1.initialize();
-
-const dw2 = new DataWeave({
-  resolveModule: modulesFromMap({ 'b.dwl': '...' }),
-});
-dw2.initialize();  // Only loads/ref-counts the native library — does NOT register a resolver
-
-dw1.run('...');    // First resolver-backed run() in the process: installs dw1's resolver
-dw2.run('...');    // Logs warning, silently reuses dw1's resolver instead of dw2's
-
-// Both dw1 and dw2 use dw1's resolver (only 'a.dwl' is available)
-```
-
-**The rule is "first resolver-backed `run()` wins," not "first `initialize()` wins."**
-`initialize()` only loads and ref-counts the native library; the resolver
-itself is registered lazily, on whichever instance's `run()` executes first
-with a resolver configured. If `dw2.run()` happens to execute before
-`dw1.run()` — even though `dw1.initialize()` ran first — `dw2`'s resolver
-wins instead.
+### Multiple Independent Engines
 
-**Workaround:** Use `composeResolvers()` to combine all modules into a single resolver:
+Each `DataWeave` instance owns its own native engine, resolver, and script
+cache. You can construct as many resolver-backed instances as you want in the
+same process — each one only ever resolves its own modules, with no
+cross-talk between instances:
 
 ```typescript
-const resolver = composeResolvers(
-  modulesFromMap({ 'a.dwl': '...' }),
-  modulesFromMap({ 'b.dwl': '...' })
-);
+async function example() {
+  const dw1 = new DataWeave({
+    resolveModule: modulesFromMap({ 'a.dwl': '...' }),
+  });
+  dw1.initialize();
 
-const dw1 = new DataWeave({ resolveModule: resolver });
-dw1.initialize();
+  const dw2 = new DataWeave({
+    resolveModule: modulesFromMap({ 'b.dwl': '...' }),
+  });
+  dw2.initialize();
 
-const dw2 = new DataWeave({ resolveModule: resolver });
-dw2.initialize();  // Both use the same resolver
+  try {
+    dw1.run('...');  // Only 'a.dwl' is available to dw1
+    dw2.run('...');  // Only 'b.dwl' is available to dw2 — dw1's modules are not visible here
+  } finally {
+    await dw1.cleanup();
+    await dw2.cleanup();
+  }
+}
 ```
 
-**Worker threads:** the same one-resolver-per-process rule applies across
-`worker_threads` Workers, not just across instances on one thread. The
-resolver callback is additionally bound to the specific thread that first
-registered it. A resolver-backed `DataWeave` constructed and initialized on a
-Worker other than the one that registered the process's resolver will not
-have its `resolveModule` invoked at all — custom module paths resolve as "not
-found" (falling back to built-ins only) rather than crashing. There is
-currently no supported way to run distinct custom-module resolvers on
-different Workers in the same process; either resolve modules on the thread
-that owns the process's resolver, or avoid resolver-backed instances in
-worker pools.
-
-**Concurrent resolver-backed runs across Workers are unsupported and
-memory-unsafe.** Beyond the "not found" fallback described above, calling a
-resolver-backed `run()` concurrently from more than one Worker is not just
-unsupported behavior — it is a memory-safety hazard. The native layer tracks
-in-flight resolver results in unsynchronized, process-global state, and one
-Worker's cleanup can free memory another Worker's concurrent call is still
-using. Restrict resolver-backed execution to a single thread (or fully
-serialize resolver-backed calls across Workers) until a future release
-isolates per-instance engine state.
+**`cleanup()` is required for every instance.** Each `DataWeave` instance's
+engine is tracked in a native registry keyed by handle. `cleanup()` destroys
+the engine and removes its registry entry; an instance that is never
+`cleanup()`'d keeps its engine (and the JS `resolveModule` closure it holds a
+reference to) alive for the lifetime of the process, even if the `DataWeave`
+object itself is garbage-collected on the JS side. Always `cleanup()` in a
+`finally` block, as shown throughout this document.
+
+`composeResolvers()` is not a workaround for any resolver-sharing limitation
+— each engine already has its own resolver. It's simply a layering tool for
+building one resolver out of several fallback sources (overrides, then a
+shared directory, then vendor JARs); see [composeResolvers](#composeresolvers)
+above.
+
+**Worker threads and thread ownership:** each resolver-backed engine is bound
+to the thread that created it (the thread that called `new DataWeave(...)`
+and `initialize()` with a `resolveModule` configured). Only that thread's
+synchronous `run()` calls can invoke the engine's `resolveModule` callback.
+`runStreaming()` and `runTransform()` execute on a background thread even
+when called from the owner thread, so they can never invoke that engine's
+resolver — nor can `run()` calls made from any other `worker_threads` Worker.
+In all of these cases the engine fails closed: custom module paths resolve as
+"not found" (falling back to built-ins only) rather than crashing or hanging.
+There is no supported way to invoke one engine's resolver from a thread other
+than the one that created it; if you need custom modules on multiple
+Workers, construct and use a separate resolver-backed `DataWeave` instance
+on each Worker.
 
 ## Security / Trust Model
 
@@ -319,7 +317,7 @@ async function main() {
       console.error('Error:', result.error);
     }
   } finally {
-    dw.cleanup();
+    await dw.cleanup();
   }
 }
 
diff --git a/native-lib/node/src/addon.c b/native-lib/node/src/addon.c
index 5aa31535..57135032 100644
--- a/native-lib/node/src/addon.c
+++ b/native-lib/node/src/addon.c
@@ -3,6 +3,7 @@
 #include <stdio.h>
 #include <stdlib.h>
 #include <string.h>
+#include <stdbool.h>
 
 // GraalVM function pointer types
 typedef int (*graal_create_isolate_fn)(void*, void**, void**);
@@ -13,21 +14,19 @@ typedef void* (*run_script_fn)(void*, const char*, const char*);
 typedef void (*free_cstring_fn)(void*, void*);
 typedef int (*write_callback_t)(void* ctx, const char* buf, int len);
 typedef int (*read_callback_t)(void* ctx, char* buf, int buf_size);
-typedef char* (*resolve_module_callback_t)(void* thread, const char* module_path);
+typedef char* (*resolve_module_callback_t)(void* thread, void* ctx, const char* module_path);
 typedef void* (*run_script_callback_fn)(void*, const char*, const char*, write_callback_t, void*);
 typedef void* (*run_script_input_output_callback_fn)(void*, const char*, const char*, const char*, const char*, const char*, read_callback_t, write_callback_t, void*);
 
-// Resolver-aware entrypoint types
-// NOTE: run_script_with_resolver has no mimeType parameter on the native side
-// (NativeLib.runScriptWithResolver(thread, script, inputsJson, resolverCallback)
-// delegates to ScriptRuntime.run(script, inputsJson), which infers/hardcodes
-// output mime type internally). The JS-facing mimeType argument is accepted
-// for API symmetry with other entrypoints but is NOT forwarded across the FFI
-// boundary — passing it here would misalign the native call's argument
-// registers and corrupt the callback function pointer.
-typedef char* (*run_script_with_resolver_fn)(void*, const char*, const char*, resolve_module_callback_t);
-typedef void* (*run_script_callback_with_resolver_fn)(void*, const char*, const char*, const char*, write_callback_t, void*, resolve_module_callback_t);
-typedef void* (*run_script_input_output_callback_with_resolver_fn)(void*, const char*, const char*, const char*, const char*, const char*, read_callback_t, write_callback_t, void*, resolve_module_callback_t);
+// Per-engine entrypoint types. Handles are Java long values and MUST be C
+// long long everywhere (plain long is 32-bit on Windows LLP64 and would
+// truncate a 64-bit handle).
+typedef long long (*create_engine_fn)(void*);
+typedef long long (*create_engine_with_resolver_fn)(void*, resolve_module_callback_t, void*);
+typedef void (*destroy_engine_fn)(void*, long long);
+typedef void* (*run_script_engine_fn)(void*, long long, const char*, const char*);
+typedef void* (*run_script_callback_engine_fn)(void*, long long, const char*, const char*, write_callback_t, void*);
+typedef void* (*run_script_input_output_callback_engine_fn)(void*, long long, const char*, const char*, const char*, const char*, const char*, read_callback_t, write_callback_t, void*);
 
 // Global state
 static uv_lib_t g_lib;
@@ -54,14 +53,28 @@ static free_cstring_fn fn_free_cstring = NULL;
 static run_script_callback_fn fn_run_script_callback = NULL;
 static run_script_input_output_callback_fn fn_run_script_input_output_callback = NULL;
 
-// Resolver-aware entrypoints
-static run_script_with_resolver_fn fn_run_script_with_resolver = NULL;
-static run_script_callback_with_resolver_fn fn_run_script_callback_with_resolver = NULL;
-static run_script_input_output_callback_with_resolver_fn fn_run_script_input_output_callback_with_resolver = NULL;
+// Per-engine entrypoints
+static create_engine_fn fn_create_engine = NULL;
+static create_engine_with_resolver_fn fn_create_engine_with_resolver = NULL;
+static destroy_engine_fn fn_destroy_engine = NULL;
+static run_script_engine_fn fn_run_script_engine = NULL;
+static run_script_callback_engine_fn fn_run_script_callback_engine = NULL;
+static run_script_input_output_callback_engine_fn fn_run_script_input_output_callback_engine = NULL;
+
+// A single run may trigger resolve_module_callback multiple times (one script
+// can import several modules). Native copies each returned buffer immediately,
+// but the copy is made *after* our callback returns — we don't get a per-call
+// "done freeing" signal, only "the whole run finished". So track every buffer
+// allocated during one run and free them all once the native call returns.
+typedef struct resolver_result_node {
+    char* buf;
+    struct resolver_result_node* next;
+} resolver_result_node_t;
 
-// Resolver bridge state (one resolver per process).
+// Per-engine resolver bridge: one node per resolver-backed engine, passed to
+// Java as the callback ctx word and forwarded back to resolve_module_callback.
 //
-// Unlike the streaming/transform entrypoints, runWithResolver's native call
+// Unlike the streaming/transform entrypoints, runScriptEngine's native call
 // executes synchronously on the very thread that invoked it from JS — no
 // background uv_thread is spawned. So when native code calls back into
 // resolve_module_callback(), we are already on the correct (JS) thread and
@@ -70,51 +83,373 @@ static run_script_input_output_callback_with_resolver_fn fn_run_script_input_out
 // caller on a condition variable until it's serviced — but if the caller
 // *is* the JS thread, it can never service its own queued item, causing a
 // deadlock (a real bug fixed in this codebase — see Task 11 report).
-static napi_env g_resolver_env = NULL;
-static napi_ref g_resolver_ref = NULL;
-
-// The OS thread that first installed the resolver (see napi_run_with_resolver
-// below). ScriptRuntime's engine is a process-wide singleton, so once a
-// resolver is installed, resolve_module_callback() can be reached from ANY
-// entrypoint that later compiles a script against that shared engine —
-// including runScriptStreaming/runScriptTransform, whose native calls run on
-// a background uv_thread (see streaming_thread_fn/transform_thread_fn), not
-// the JS thread. napi_env/napi_ref are thread-affine; calling into them from
-// a thread other than the one that created them is undefined behavior. We
-// record the owning thread here so resolve_module_callback can detect the
-// mismatch and fail closed (return "not found") instead of crashing.
-static uv_thread_t g_resolver_thread;
-
-// A single runWithResolver call may trigger resolve_module_callback multiple
-// times (one script can import several modules). Native copies each
-// returned buffer immediately, but the copy is made *after* our callback
-// returns — we don't get a per-call "done freeing" signal, only "the whole
-// run finished". So track every buffer allocated during one call and free
-// them all once fn_run_script_with_resolver returns.
-typedef struct resolver_result_node {
-    char* buf;
-    struct resolver_result_node* next;
-} resolver_result_node_t;
-static resolver_result_node_t* g_resolver_results = NULL;
-
-static void resolver_results_track(char* buf) {
-    if (buf == NULL) return;
+//
+// napi_env/napi_ref are thread-affine; each bridge records the JS thread that
+// created it (owner) so resolve_module_callback can detect a mismatch — e.g. a
+// streamed/transform custom-module lookup arriving on the background uv_thread
+// — and fail closed (return "not found") instead of crashing.
+typedef struct engine_bridge {
+    long long handle;
+    napi_env env;
+    napi_ref resolver_js;             // NULL => resolver-less engine (no bridge created)
+    uv_thread_t owner;                // JS thread that created and must run this engine
+    resolver_result_node_t* results;  // buffers to free after each run on this engine
+    // Lifecycle accounting, mutated only under g_mutex. A streaming/transform op
+    // runs the native call on a background uv_thread that can still call back into
+    // resolve_module_callback with this bridge as ctx, so the bridge must outlive
+    // every in-flight op. in_flight counts ops that can still dereference this
+    // bridge; destroy_pending marks that destroyEngine ran while in_flight > 0 and
+    // freeing was deferred to the last op draining on the owner thread.
+    int in_flight;
+    bool destroy_pending;
+    // True when a destroy (via destroyEngine OR the env cleanup hook) was
+    // deferred because in_flight > 0; gates the deferred fn_destroy_engine
+    // registry removal in bridge_end_op. round-9 (#1) introduced this for the
+    // destroyEngine path; round-10 (#1) extended it to bridge_env_cleanup, which
+    // must ALSO remove the Java registry entry when its free is deferred --
+    // otherwise a resolver-backed engine's ScriptRuntime is left registered with
+    // a CallbackWeaveResourceResolver whose ctx points at the freed bridge (UAF).
+    bool deferred_registry_remove;
+    struct engine_bridge* next;
+} engine_bridge_t;
+static engine_bridge_t* g_bridges = NULL;  // linked list, guarded by g_mutex
+
+// One record per napi_env that has ever taken an init reference (via
+// initialize()). init_refs is that env's net initialize()-minus-cleanup()
+// balance. Created lazily on the env's first initialize(); registers exactly
+// one env-death hook (env_init_cleanup) at creation; freed by that hook when
+// its env dies (after releasing every reference the env still holds). All
+// fields mutated ONLY under g_mutex.
+//
+// INVARIANT: g_ref_count == sum of init_refs over all records in g_env_recs.
+// This is the round-13 (#5) fix: the isolate's reference count is owned per
+// env, so an abandoned env (or a raw multi-engine-per-initialize() consumer)
+// can only release the references IT holds -- it can never drive g_ref_count
+// to zero and tear the isolate down while ANOTHER env's engines are live.
+typedef struct env_init_rec {
+    napi_env env;
+    int init_refs;
+    struct env_init_rec* next;
+} env_init_rec_t;
+static env_init_rec_t* g_env_recs = NULL;  // linked list, guarded by g_mutex
+
+// --- Teardown-vs-active-ops coordination (deadlock fix) ---
+//
+// napi_cleanup's last-release path used to synchronously join a thread that
+// calls graal_tear_down_isolate(), which blocks until every GraalVM-attached
+// thread detaches. A runStreaming()/runTransform() background worker stays
+// attached and can be mid-delivery in napi_call_threadsafe_function(...,
+// napi_tsfn_blocking), which needs the JS thread to run its callback -- but
+// the JS thread is the one blocked in the join. g_active_ops tracks every
+// in-flight streaming/transform op (resolver-backed or not, since teardown
+// blocks on ANY attached worker) so napi_cleanup can wait for them to drain
+// on a dedicated thread instead of blocking the calling JS thread.
+static int g_active_ops = 0;
+// Teardown lifecycle, all transitions under g_mutex:
+//   NONE         -> no teardown queued or in progress.
+//   PENDING_WAIT -> napi_cleanup Case 5 queued a teardown; the waiter thread is
+//                   blocked waiting for g_active_ops to drain. The isolate is
+//                   STILL LIVE and un-torn-down here, so a fresh initialize()
+//                   may ADOPT it (cancel the teardown) instead of blocking the
+//                   JS thread -- this is the round-5 deadlock fix.
+//   TEARING_DOWN -> the waiter has passed the point of no return and is calling
+//                   graal_tear_down_isolate(). Adoption is unsafe; initialize()
+//                   must block here, which is deadlock-free because g_active_ops
+//                   is already 0 (nothing depends on the JS event loop).
+typedef enum {
+  TEARDOWN_NONE = 0,
+  TEARDOWN_PENDING_WAIT,
+  TEARDOWN_TEARING_DOWN,
+} teardown_state_t;
+static teardown_state_t g_teardown_state = TEARDOWN_NONE;
+// Set by an adopting initialize() to tell the waiter thread to abort its
+// queued teardown and leave the live isolate intact. Read/reset by the waiter.
+static bool g_teardown_cancelled = false;
+// Round-14 (#2/#3): set under g_mutex when a reached-zero teardown could NOT be
+// carried out (teardown-waiter alloc/spawn failed, or cleanup_thread_fn attach
+// failed) and the isolate was therefore left LIVE with g_ref_count == 0 and no
+// pending teardown. This is a RETRY SIGNAL, not an ownership reference:
+// g_ref_count stays 0, so the invariant g_ref_count == sum(init_refs) is
+// unaffected. It is cleared when the isolate is (a) actually torn down by a
+// retry, or (b) adopted by a later initialize() (a new owner wants it kept).
+// While set with g_active_ops > 0, the op-completion drain point retries the
+// teardown once ops reach 0 (retry_stranded_teardown_locked).
+static bool g_teardown_needed = false;
+static uv_cond_t g_teardown_cond;
+
+// One node per cleanup() call that arrived while a teardown was already
+// pending. napi_env/napi_deferred/napi_threadsafe_function are thread-affine,
+// so a second cleanup() call from a different Worker's env cannot have its
+// promise resolved via another env's tsfn -- each waiting caller gets its own
+// node, created on its own env, resolved by the waiter thread on completion.
+typedef struct teardown_waiter {
+    napi_env env;
+    napi_deferred deferred;
+    napi_threadsafe_function tsfn;
+    struct teardown_waiter* next;
+} teardown_waiter_t;
+static teardown_waiter_t* g_teardown_waiters = NULL;  // linked list, guarded by g_mutex
+
+// Returns true if the buffer is now tracked (or there was nothing to track).
+// Returns false only when a buffer was supplied but the tracking node could
+// not be allocated — in that case the caller owns `buf` again and MUST free
+// it itself, since it will never be reachable from b->results.
+static bool resolver_results_track(engine_bridge_t* b, char* buf) {
+    if (b == NULL || buf == NULL) return true;
     resolver_result_node_t* node = (resolver_result_node_t*)malloc(sizeof(resolver_result_node_t));
-    if (node == NULL) return;  // Leak the buffer rather than crash; best-effort tracking.
+    if (node == NULL) return false;  // OOM: caller must free buf to avoid leaking it untracked.
     node->buf = buf;
-    node->next = g_resolver_results;
-    g_resolver_results = node;
+    node->next = b->results;
+    b->results = node;
+    return true;
 }
 
-static void resolver_results_free_all(void) {
-    resolver_result_node_t* node = g_resolver_results;
+static void resolver_results_free_all(engine_bridge_t* b) {
+    if (b == NULL) return;
+    resolver_result_node_t* node = b->results;
     while (node != NULL) {
         resolver_result_node_t* next = node->next;
         free(node->buf);
         free(node);
         node = next;
     }
-    g_resolver_results = NULL;
+    b->results = NULL;
+}
+
+// Call under g_mutex.
+static engine_bridge_t* bridge_find(long long handle) {
+    for (engine_bridge_t* b = g_bridges; b != NULL; b = b->next) {
+        if (b->handle == handle) return b;
+    }
+    return NULL;
+}
+
+// Find this env's init record, or NULL. Caller MUST hold g_mutex.
+static env_init_rec_t* env_init_rec_find_locked(napi_env env) {
+    for (env_init_rec_t* r = g_env_recs; r != NULL; r = r->next) {
+        if (r->env == env) return r;
+    }
+    return NULL;
+}
+
+// Find-or-create this env's init record and increment its init_refs. Sets
+// *is_new = true iff a record was just allocated (the caller must then register
+// the env-death hook on its own thread). Returns the record, or NULL only on
+// calloc failure (caller must NOT bump g_ref_count in that case). Caller MUST
+// hold g_mutex.
+static env_init_rec_t* env_init_rec_acquire_locked(napi_env env, bool* is_new) {
+    *is_new = false;
+    env_init_rec_t* r = env_init_rec_find_locked(env);
+    if (r == NULL) {
+        r = (env_init_rec_t*)calloc(1, sizeof(env_init_rec_t));
+        if (r == NULL) return NULL;
+        r->env = env;
+        r->init_refs = 0;
+        r->next = g_env_recs;
+        g_env_recs = r;
+        *is_new = true;
+    }
+    r->init_refs++;
+    return r;
+}
+
+// Sum of live per-env init references. Caller holds g_mutex. Establishes the
+// value g_ref_count must equal (invariant g_ref_count == sum of init_refs); used
+// to restore g_ref_count coherently when a deferred teardown cannot be spawned.
+static int env_init_refs_total_locked(void) {
+    int total = 0;
+    for (env_init_rec_t* r = g_env_recs; r != NULL; r = r->next) total += r->init_refs;
+    return total;
+}
+
+// Fully dispose of a bridge: delete its napi_ref (if the owning env is still
+// alive), free tracked result buffers, free the struct. napi_ref/napi_env are
+// thread-affine, so napi_delete_reference MUST run on the bridge's owner
+// thread (the JS/Worker thread that created it) while that env is still
+// alive -- `env_still_alive` must be false whenever the caller knows the
+// owning env is tearing down/dead (e.g. the env == NULL sentinel path in
+// call_js_write/call_js_transform_write), even though b->env itself is never
+// cleared and stays non-NULL. When env_still_alive is false the napi_ref is
+// simply skipped -- Node auto-reclaims refs when their env is destroyed, so
+// nothing leaks. The bridge must already be unlinked from g_bridges. Do NOT
+// hold g_mutex across this call — it invokes N-API. Callers that freed a
+// bridge *early* (destroyEngine / streaming completion) must first drop the
+// env cleanup hook via napi_remove_env_cleanup_hook so Node never invokes it
+// on freed memory; the hook path itself (bridge_env_cleanup) must not remove
+// itself and calls this directly.
+// `do_registry_remove` is true when the caller must remove the Java registry
+// entry (fn_destroy_engine) for this handle before freeing the record: the
+// immediate destroyEngine path, or the deferred drain of either destroyEngine
+// (round-9 #1) or the env cleanup hook (round-10 #1). fn_destroy_engine is
+// called at most once per handle because destroyEngine and bridge_env_cleanup
+// are mutually exclusive (destroyEngine removes the hook). It runs on whichever
+// thread finalizes (the owner JS thread from the completion sentinel,
+// destroyEngine's thread, or the env-cleanup hook thread); fn_destroy_engine
+// attaches its own isolate thread, so it is not JS-thread-affine. Must be
+// called WITHOUT g_mutex held (it enters GraalVM and, for env_still_alive,
+// calls N-API).
+// #3 (round 12): the isolate-touching registry removal. Takes a TRANSIENT
+// g_active_ops reservation so graal_tear_down_isolate() cannot run across the
+// attach. The teardown-state check and the g_active_ops++ are ONE critical
+// section: no teardown path can interleave between "isolate is live" and
+// "reservation taken". Callable from any thread NOT holding g_mutex.
+static void bridge_finalize_registry(engine_bridge_t* b) {
+    if (b == NULL || fn_destroy_engine == NULL) return;
+    uv_mutex_lock(&g_mutex);
+    // If the waiter already committed to physical teardown (TEARING_DOWN) or the
+    // isolate is already gone, the Java registry died/dies with it -- nothing to
+    // remove, and attaching would race graal_tear_down_isolate. Skip. Because
+    // the waiter publishes TEARING_DOWN (and Case 4 holds g_mutex across its
+    // g_active_ops==0 check + teardown) under this same lock, this check plus the
+    // increment below cannot be split by a teardown.
+    if (g_teardown_state == TEARDOWN_TEARING_DOWN || g_isolate == NULL) {
+        uv_mutex_unlock(&g_mutex);
+        return;
+    }
+    g_active_ops++;  // pins the live isolate against teardown for this attach
+    uv_mutex_unlock(&g_mutex);
+
+    void* thread = NULL;
+    if (fn_attach_thread(g_isolate, &thread) == 0) {
+        fn_destroy_engine(thread, b->handle);
+        fn_detach_thread(thread);
+    }
+
+    // Verbatim g_active_ops release pattern.
+    uv_mutex_lock(&g_mutex);
+    g_active_ops--;
+    uv_cond_broadcast(&g_teardown_cond);
+    uv_mutex_unlock(&g_mutex);
+}
+
+// The non-isolate finalize phase: delete the resolver napi_ref (owner JS thread
+// only, and only while its env is alive -- resolver-gated), free tracked result
+// buffers, free the record. Touches no GraalVM isolate state, so it is safe to
+// run after the g_active_ops reservation above is released.
+static void bridge_finalize_free(engine_bridge_t* b, bool env_still_alive) {
+    if (b == NULL) return;
+    if (env_still_alive && b->resolver_js != NULL && b->env != NULL) {
+        napi_delete_reference(b->env, b->resolver_js);
+    }
+    resolver_results_free_all(b);
+    free(b);
+}
+
+// Thin wrapper preserving the original signature and every call site. Registry
+// removal (if requested) runs first under its transient reservation, then the
+// record is freed.
+static void bridge_finalize(engine_bridge_t* b, bool env_still_alive, bool do_registry_remove) {
+    if (b == NULL) return;
+    if (do_registry_remove) bridge_finalize_registry(b);
+    bridge_finalize_free(b, env_still_alive);
+}
+
+// Env cleanup hook (F2): registered per resolver-backed bridge at creation via
+// napi_add_env_cleanup_hook, so each Worker/main env disposes its OWN bridges on
+// its OWN thread when that env tears down — instead of napi_cleanup deleting
+// refs from whichever thread happens to release the last DataWeave instance,
+// which is undefined behavior for thread-affine napi_env/napi_ref. Runs on the
+// owner thread with the env still alive, which is exactly where napi_ref deletion
+// is legal.
+static void bridge_env_cleanup(void* arg) {
+    engine_bridge_t* b = (engine_bridge_t*)arg;
+    if (b == NULL) return;
+
+    uv_mutex_lock(&g_mutex);
+    // Unlink from g_bridges if still present (destroyEngine may have already
+    // unlinked it while deferring a free — see below).
+    engine_bridge_t** pp = &g_bridges;
+    while (*pp != NULL) {
+        if (*pp == b) { *pp = b->next; break; }
+        pp = &(*pp)->next;
+    }
+    // An in-flight streaming/transform op holds a live threadsafe function that
+    // keeps this env's event loop alive, so the env should never tear down while
+    // in_flight > 0. Guard defensively anyway: mark destroy_pending and let the
+    // op's completion path drain and finalize it (do NOT finalize here, the op's
+    // background thread could still dereference this bridge).
+    if (b->in_flight > 0) {
+        b->destroy_pending = true;
+        // round-10 (#1): the draining op must ALSO remove the Java registry
+        // entry (like destroyEngine's deferred path), or the resolver engine's
+        // ScriptRuntime is left registered with a resolver ctx pointing at the
+        // freed bridge. Set the deferred-registry-removal flag here.
+        b->deferred_registry_remove = true;
+        uv_mutex_unlock(&g_mutex);
+        return;
+    }
+    // in_flight == 0: finalize now. The abandoned engine's init reference is
+    // NOT released here (round-13 #5) -- it is released by the env-death hook
+    // (env_init_cleanup) when this env dies, which owns the whole per-env
+    // balance. There is nothing left to do under the lock before unlocking in
+    // this branch. bridge_finalize_registry inside finalize checks teardown
+    // state under g_mutex, so a torn-down/TEARING_DOWN isolate makes the
+    // registry removal a correct no-op (the Java registry died with the
+    // isolate).
+    uv_mutex_unlock(&g_mutex);
+
+    // We are inside Node's invocation of this hook, so we must not (and need not)
+    // call napi_remove_env_cleanup_hook for ourselves here. The env is still
+    // alive here -- that is the whole point of this hook's design (see above) --
+    // so the napi_ref deletion in bridge_finalize is legal.
+    // round-10 (#1): remove the Java registry entry too (do_registry_remove=true).
+    // This hook only ever fires for a resolver-backed engine that was never
+    // passed to destroyEngine (destroyEngine removes this hook), so its
+    // initialize() ref was never released either -> the isolate is still live
+    // and fn_destroy_engine's fresh-thread attach is legal (bridge_finalize
+    // guards on g_isolate for the main-env-after-isolate-teardown corner). Not
+    // removing it would leave a CallbackWeaveResourceResolver whose ctx is the
+    // freed bridge -> UAF on a later invocation of this handle.
+    bridge_finalize(b, /*env_still_alive=*/true, /*do_registry_remove=*/true);
+}
+
+// Increment this engine's in_flight while g_mutex is ALREADY held. Used by the
+// run/streaming/transform admission paths so the per-engine pin is taken in the
+// SAME critical section as the g_active_ops reservation and the lifecycle check
+// -- closing the round-11 window where a concurrent destroyEngine could observe
+// in_flight == 0 and free the bridge under an already-admitted op. Returns the
+// record, or NULL for an unknown handle (nothing to pin; the worker/native call
+// surfaces "Unknown engine handle"). Caller MUST hold g_mutex.
+static engine_bridge_t* bridge_begin_op_locked(long long handle) {
+    engine_bridge_t* b = bridge_find(handle);
+    if (b != NULL) b->in_flight++;
+    return b;
+}
+
+// A streaming/transform/run op marks one op in flight on the engine's record so
+// the record (and, for resolver-backed engines, its napi_ref) cannot be freed
+// while the background uv_thread runs -- and, since round-9 (#1), so that
+// destroyEngine defers the Java registry removal until this op drains. Every
+// engine (resolver-backed or resolver-less) now has a record, so
+// bridge_begin_op_locked returns a non-NULL pointer for any known handle; the
+// completion sentinel MUST call bridge_end_op on it to balance in_flight and
+// run any deferred destroy. Returns NULL only for an unknown handle (nothing to
+// protect, no bridge_end_op needed). The returned pointer is stable for the
+// op's lifetime because in_flight > 0 blocks both destroyEngine and the env
+// cleanup hook from freeing the record. Since round-11 (#2), every call site
+// takes the pin atomically with its g_mutex-guarded admission check via
+// bridge_begin_op_locked directly (no self-locking wrapper) -- see
+// napi_run_script_streaming_engine / napi_run_script_transform_engine.
+
+// End a streaming/transform op. Runs on the owner (JS) thread from the completion
+// sentinel. If destroyEngine (or the env cleanup hook) ran while this op was in
+// flight, it deferred the free — already unlinked from g_bridges — so the last op
+// to drain finalizes the bridge here, on the legal (owner) thread. `env_still_alive`
+// must be false when the caller is running the env == NULL sentinel path (the
+// owning env is tearing down/dead), so a finalize triggered from here does not
+// call napi_delete_reference on a dead env.
+static void bridge_end_op(engine_bridge_t* b, bool env_still_alive) {
+    if (b == NULL) return;
+    uv_mutex_lock(&g_mutex);
+    b->in_flight--;
+    bool finalize = (b->destroy_pending && b->in_flight == 0);
+    bool remove_registry = finalize && b->deferred_registry_remove;
+    uv_mutex_unlock(&g_mutex);
+    // remove_registry is true when either destroyEngine (round-9 #1) or the env
+    // cleanup hook (round-10 #1) deferred the registry removal while this op was
+    // in flight; the draining op performs it exactly once here. bridge_finalize
+    // guards the call on g_isolate, so a teardown that raced ahead is a no-op.
+    if (finalize) bridge_finalize(b, env_still_alive, /*do_registry_remove=*/remove_registry);
 }
 
 // --- Initialization ---
@@ -145,15 +480,16 @@ static void init_thread_fn(void* arg) {
   uv_dlsym(&g_lib, "run_script_callback", (void**)&fn_run_script_callback);
   uv_dlsym(&g_lib, "run_script_input_output_callback", (void**)&fn_run_script_input_output_callback);
 
-  // Load resolver-aware entrypoints (optional - newer symbols)
-  uv_dlsym(&g_lib, "run_script_with_resolver", (void**)&fn_run_script_with_resolver);
-  // fn_run_script_callback_with_resolver / fn_run_script_input_output_callback_with_resolver
-  // are resolved here but intentionally never called from this file. Wiring them into
-  // runScriptStreaming/runScriptTransform would put the resolver callback on a background
-  // uv_thread, which is unsafe for the same reason resolve_module_callback() above guards
-  // against cross-thread napi calls — do not wire these up without solving that hazard first.
-  uv_dlsym(&g_lib, "run_script_callback_with_resolver", (void**)&fn_run_script_callback_with_resolver);
-  uv_dlsym(&g_lib, "run_script_input_output_callback_with_resolver", (void**)&fn_run_script_input_output_callback_with_resolver);
+  // Load per-engine entrypoints. Every initialize() call creates an engine via
+  // create_engine/create_engine_with_resolver (see dataweave.ts), so these are
+  // load-time required, not optional, even though they are newer than the
+  // legacy singleton symbols above.
+  uv_dlsym(&g_lib, "create_engine", (void**)&fn_create_engine);
+  uv_dlsym(&g_lib, "create_engine_with_resolver", (void**)&fn_create_engine_with_resolver);
+  uv_dlsym(&g_lib, "destroy_engine", (void**)&fn_destroy_engine);
+  uv_dlsym(&g_lib, "run_script_engine", (void**)&fn_run_script_engine);
+  uv_dlsym(&g_lib, "run_script_callback_engine", (void**)&fn_run_script_callback_engine);
+  uv_dlsym(&g_lib, "run_script_input_output_callback_engine", (void**)&fn_run_script_input_output_callback_engine);
 
   if (!fn_create_isolate || !fn_run_script || !fn_free_cstring) {
     snprintf(args->error, sizeof(args->error), "Missing required symbols in library");
@@ -161,6 +497,21 @@ static void init_thread_fn(void* arg) {
     return;
   }
 
+  // Fail fast, with a clear message, if the loaded dwlib predates the
+  // per-engine ABI (W-23692110). Without this check, the library would load
+  // "successfully" here and every initialize() call would still fail later
+  // deep inside createEngine()/createEngineWithResolver() with a confusing
+  // "not available in native library" error instead of this one.
+  if (!fn_create_engine || !fn_create_engine_with_resolver || !fn_destroy_engine ||
+      !fn_run_script_engine || !fn_run_script_callback_engine ||
+      !fn_run_script_input_output_callback_engine) {
+    snprintf(args->error, sizeof(args->error),
+             "dwlib is missing required per-engine symbols (expected in dwlib "
+             "built with W-23692110 or later) - rebuild/upgrade the native library");
+    args->result = -2;
+    return;
+  }
+
   void* boot_thread = NULL;
   rc = fn_create_isolate(NULL, &g_isolate, &boot_thread);
   if (rc != 0) {
@@ -184,6 +535,50 @@ static void init_thread_fn(void* arg) {
   args->result = 0;
 }
 
+// Forward declaration: the env-death hook that reclaims an abandoned env's
+// init references. Defined below (round-13 #5); registered here (in
+// env_init_acquire_and_hook) because napi_add_env_cleanup_hook is only legal
+// while the env is alive on its own JS thread, which napi_initialize is.
+static void env_init_cleanup(void* arg);  // defined below (round-13 #5)
+
+// Acquire one init reference for `env` under g_mutex, registering the env-death
+// hook on first use. Returns true on success (caller then does g_ref_count++);
+// on failure the caller must NOT bump g_ref_count -- it unlocks and throws.
+// Caller MUST hold g_mutex; this function keeps it held on success and on the
+// calloc-failure return. On hook-registration failure it rolls back the
+// just-acquired init_refs (freeing the record if it drops to 0) so no orphan
+// record without a death hook survives.
+static bool env_init_acquire_and_hook(napi_env env) {
+    bool is_new = false;
+    env_init_rec_t* rec = env_init_rec_acquire_locked(env, &is_new);
+    if (rec == NULL) return false;  // calloc failed
+    if (is_new) {
+        napi_status hs = napi_add_env_cleanup_hook(env, env_init_cleanup, rec);
+        if (hs != napi_ok) {
+            // Roll back: this record has no death hook, so its references would
+            // never be reclaimed. Drop the one we just took; free if now empty.
+            rec->init_refs--;
+            if (rec->init_refs == 0) {
+                env_init_rec_t** pp = &g_env_recs;
+                while (*pp != NULL) { if (*pp == rec) { *pp = rec->next; break; } pp = &(*pp)->next; }
+                free(rec);
+            }
+            return false;
+        }
+    }
+    return true;
+}
+
+// Forward declaration: tears down g_isolate on a dedicated attached thread.
+// Defined below; used here (napi_initialize's create-path acquire-failure
+// recovery) and further down by isolate_ref_release_n_locked.
+static void cleanup_thread_fn(void* arg);
+
+// Forward declaration: retries a stranded teardown (round-14 #2/#3). Defined
+// further below; used by the streaming/transform op-completion drain points,
+// which run earlier in this file than the definition.
+static void retry_stranded_teardown_locked(void);
+
 static napi_value napi_initialize(napi_env env, napi_callback_info info) {
   size_t argc = 1;
   napi_value argv[1];
@@ -199,8 +594,64 @@ static napi_value napi_initialize(napi_env env, napi_callback_info info) {
   napi_get_value_string_utf8(env, argv[0], lib_path, sizeof(lib_path), &len);
 
   uv_mutex_lock(&g_mutex);
+
+  // A prior last-release could not tear the isolate down and armed the retry
+  // signal (review #6 #3/#4). Because retries otherwise fire only at op
+  // completion (the streaming/transform drains), a zero-op stranded isolate
+  // would never be reclaimed and the adoption/fast paths below would silently
+  // discard the pending teardown (review #6 #5). Drive the pending teardown to
+  // completion here first: on success g_isolate/g_initialized are cleared and we
+  // build a fresh isolate below; on repeated failure the live isolate is adopted
+  // by the fast path (safe -- the teardown was resource reclamation, not a
+  // malfunction). No-ops cheaply when nothing is stranded (flag clear -> return).
+  retry_stranded_teardown_locked();
+
+  // If a teardown from a prior cleanup() is still draining (the isolate is
+  // being torn down on the waiter thread from Task 2), do not race a fresh
+  // graal_create_isolate against it -- wait until the isolate is fully gone
+  // before proceeding. This is a narrow, rare path (re-initializing mid-drain),
+  // not a fast path, so a blocking wait here is acceptable and matches this
+  // function's existing fully-synchronous contract -- except in
+  // TEARDOWN_PENDING_WAIT (see below), where blocking would deadlock.
+  while (g_teardown_state != TEARDOWN_NONE || (g_isolate != NULL && !g_initialized)) {
+    if (g_teardown_state == TEARDOWN_PENDING_WAIT) {
+      // A teardown is queued but the waiter has NOT begun physical teardown
+      // (that transition to TEARING_DOWN happens under this same g_mutex), so
+      // g_isolate/g_initialized are still valid. Blocking here would freeze the
+      // JS event loop that an active streaming/transform worker needs in order
+      // to drain g_active_ops -- the waiter would then wait forever and this
+      // wait would never end (the P1 deadlock). Instead, ADOPT the live isolate:
+      // cancel the queued teardown, take a fresh ref, and wake the waiter so it
+      // aborts without tearing down. g_initialized is already 1, so fall through
+      // to the ref-count path below is unnecessary -- return directly.
+      if (!env_init_acquire_and_hook(env)) {
+        uv_mutex_unlock(&g_mutex);
+        napi_throw_error(env, NULL, "Failed to allocate/register env init record");
+        return NULL;
+      }
+      g_teardown_cancelled = true;
+      g_ref_count++;
+      g_teardown_needed = false;  // round-14: a new owner wants the isolate kept
+      uv_cond_broadcast(&g_teardown_cond);
+      uv_mutex_unlock(&g_mutex);
+      return NULL;
+    }
+    // TEARDOWN_TEARING_DOWN (or a transient g_isolate!=NULL && !g_initialized):
+    // g_active_ops has already reached 0, so nothing depends on the JS event
+    // loop -- this blocking wait is deadlock-free and preserves the original
+    // "don't race graal_create_isolate against graal_tear_down_isolate"
+    // guarantee that round 3's Task 3 added.
+    uv_cond_wait(&g_teardown_cond, &g_mutex);
+  }
+
   if (g_initialized) {
+    if (!env_init_acquire_and_hook(env)) {
+      uv_mutex_unlock(&g_mutex);
+      napi_throw_error(env, NULL, "Failed to allocate/register env init record");
+      return NULL;
+    }
     g_ref_count++;
+    g_teardown_needed = false;  // round-14: a new owner wants the isolate kept
     uv_mutex_unlock(&g_mutex);
     return NULL;
   }
@@ -214,7 +665,12 @@ static napi_value napi_initialize(napi_env env, napi_callback_info info) {
   uv_thread_options_t opts;
   opts.flags = UV_THREAD_HAS_STACK_SIZE;
   opts.stack_size = 16 * 1024 * 1024;
-  uv_thread_create_ex(&tid, &opts, init_thread_fn, &args);
+  int spawn_rc = uv_thread_create_ex(&tid, &opts, init_thread_fn, &args);
+  if (spawn_rc != 0) {
+    uv_mutex_unlock(&g_mutex);
+    napi_throw_error(env, NULL, "Failed to spawn initialization thread");
+    return NULL;
+  }
   uv_thread_join(&tid);
 
   if (args.result != 0) {
@@ -223,8 +679,60 @@ static napi_value napi_initialize(napi_env env, napi_callback_info info) {
     return NULL;
   }
 
+  if (!env_init_acquire_and_hook(env)) {
+    // init_thread_fn already built the isolate (g_isolate != NULL) but we have
+    // not yet set g_initialized = 1. If we just unlock and throw here, we leave
+    // g_isolate != NULL && g_initialized == 0 -- the exact condition the wait
+    // loop above (`g_isolate != NULL && !g_initialized`) treats as "a teardown
+    // is in flight". With g_teardown_state == TEARDOWN_NONE that loop cannot
+    // take the TEARDOWN_PENDING_WAIT adoption branch, so it falls into
+    // uv_cond_wait(&g_teardown_cond, ...) with nothing left to ever broadcast --
+    // every subsequent initialize() on any env hangs forever. Every sibling
+    // error path (args.result != 0 above, and the spawn-failure path before it)
+    // leaves g_isolate == NULL instead, which is the recoverable state. Tear
+    // the just-built isolate back down before throwing so we restore that same
+    // recoverable g_isolate == NULL state.
+    //
+    // g_ref_count is still 0 here (we never got past this check to bump it),
+    // and env_init_acquire_and_hook leaves no orphan record behind on failure
+    // (calloc failure never created one; hook-registration failure rolls its
+    // own record back) -- so the invariant g_ref_count == sum(init_refs) holds
+    // with both sides at 0 both before and after this block.
+    uv_thread_t cleanup_tid;
+    uv_thread_options_t cleanup_opts;
+    cleanup_opts.flags = UV_THREAD_HAS_STACK_SIZE;
+    cleanup_opts.stack_size = 2 * 1024 * 1024;
+    int torn_down = 0;
+    int cleanup_spawn_rc = uv_thread_create_ex(&cleanup_tid, &cleanup_opts, cleanup_thread_fn, &torn_down);
+    if (cleanup_spawn_rc == 0) {
+      uv_thread_join(&cleanup_tid);
+    }
+    if (torn_down) {
+      // Teardown ran (or there was nothing to tear down) -- clear the globals
+      // so the next initialize() sees a clean slate. g_ref_count is already 0.
+      g_thread = NULL;
+      g_isolate = NULL;
+      g_initialized = 0;
+    }
+    // else: spawn failed, or cleanup_thread_fn's attach to the isolate failed.
+    // The isolate is genuinely still alive -- leave g_isolate/g_thread as-is
+    // rather than orphaning it. This re-arms the same trap on a subsequent
+    // initialize(), but that is the pre-existing best-effort degradation
+    // policy already accepted for cleanup_thread_fn's attach-failure path
+    // elsewhere in this file; we don't invent new behavior for it here.
+    uv_mutex_unlock(&g_mutex);
+    napi_throw_error(env, NULL, "Failed to allocate/register env init record");
+    return NULL;
+  }
   g_initialized = 1;
   g_ref_count++;
+  // Round-14: defensive clear. A brand-new isolate can never carry a stale
+  // stranded-teardown signal for itself (a new graal_create_isolate only runs
+  // when g_isolate == NULL, so this path cannot reuse a surviving stranded
+  // isolate) -- but clear it here anyway at the single create-path success
+  // point so no later drain retries a teardown against the isolate this
+  // initialize() just created and now owns.
+  g_teardown_needed = false;
   uv_mutex_unlock(&g_mutex);
   return NULL;
 }
@@ -293,7 +801,13 @@ static napi_value dw_napi_run_script(napi_env env, napi_callback_info info) {
   uv_thread_options_t opts;
   opts.flags = UV_THREAD_HAS_STACK_SIZE;
   opts.stack_size = 2 * 1024 * 1024;
-  uv_thread_create_ex(&tid, &opts, run_script_thread_fn, &call_args);
+  int spawn_rc = uv_thread_create_ex(&tid, &opts, run_script_thread_fn, &call_args);
+  if (spawn_rc != 0) {
+    free(script);
+    free(inputs);
+    napi_throw_error(env, NULL, "Failed to spawn script execution thread");
+    return NULL;
+  }
   uv_thread_join(&tid);
 
   free(script);
@@ -311,6 +825,13 @@ static napi_value dw_napi_run_script(napi_env env, napi_callback_info info) {
 
 // --- Streaming output ---
 
+// Round-9 (#2): static terminal-error JSON used when a worker thread cannot
+// even strdup its result string (OOM). It is a file-scope constant, never
+// heap-allocated, so any code path that would free a sentinel/chunk buffer
+// must first check `buf != OOM_JSON` -- freeing a static pointer is UB. The
+// wording matches the existing terse worker error style ("Empty response").
+static const char OOM_JSON[] = "{\"success\":false,\"error\":\"Out of memory\"}";
+
 // chunk_data with len == -1 is a sentinel indicating completion (buf holds meta JSON)
 struct chunk_data {
   char* buf;
@@ -321,31 +842,63 @@ struct streaming_work {
   uv_thread_t tid;
   napi_threadsafe_function tsfn;
   napi_deferred deferred;
+  long long handle;
   char* script;
   char* inputs_json;
+  // The engine's record whose in_flight count this op holds. Since round-9 (#1)
+  // every engine has a record, so this is non-NULL for any known handle (NULL only
+  // for an unknown handle). The completion sentinel calls bridge_end_op on it to
+  // balance in_flight and run any deferred destroy (F1).
+  engine_bridge_t* bridge;
 };
 
 static void call_js_write(napi_env env, napi_value js_callback, void* context, void* data) {
-  if (env == NULL || data == NULL) return;
+  // data == NULL: nothing was queued, nothing to free or finalize.
+  if (data == NULL) return;
   struct chunk_data* chunk = (struct chunk_data*)data;
   struct streaming_work* w = (struct streaming_work*)context;
 
   if (chunk->len == -1) {
-    napi_value result;
-    napi_create_string_utf8(env, chunk->buf, strlen(chunk->buf), &result);
-    napi_resolve_deferred(env, w->deferred, result);
+    // Completion sentinel. env == NULL means the environment is tearing down
+    // (e.g. a Worker terminating mid-op): we must not call any napi value or
+    // JS-calling API (napi_create_string_utf8/napi_resolve_deferred need a
+    // live env), but we must still perform every bit of native finalization
+    // -- join the worker, release the tsfn, drop the bridge in-flight hold,
+    // and free every heap field -- exactly once. Skipping this on env == NULL
+    // would leak `w` and could strand a bridge marked for deferred destruction
+    // indefinitely.
+    if (env != NULL) {
+      napi_value result;
+      napi_create_string_utf8(env, chunk->buf, strlen(chunk->buf), &result);
+      napi_resolve_deferred(env, w->deferred, result);
+    }
 
-    free(chunk->buf);
+    if (chunk->buf != OOM_JSON) free(chunk->buf);
     free(chunk);
     free(w->script);
     free(w->inputs_json);
 
     uv_thread_join(&w->tid);
     napi_release_threadsafe_function(w->tsfn, napi_tsfn_release);
+    // Drop the in-flight hold last, on this owner thread: if destroyEngine ran
+    // during the op it deferred the free to here (F1). After this the bridge may
+    // be freed, so touch nothing on it afterward. env == NULL means this env is
+    // dead/tearing down -- tell bridge_end_op (and any bridge_finalize it
+    // triggers) not to touch the napi_ref, since b->env is this same dead env.
+    bridge_end_op(w->bridge, /*env_still_alive=*/env != NULL);
     free(w);
     return;
   }
 
+  // Non-sentinel data chunk. If env == NULL the environment is gone and we
+  // cannot deliver it to JS; free it and return without touching `w` (its
+  // finalization happens only on the sentinel, above).
+  if (env == NULL) {
+    free(chunk->buf);
+    free(chunk);
+    return;
+  }
+
   napi_value buffer;
   void* buf_data;
   napi_create_buffer_copy(env, chunk->len, chunk->buf, &buf_data, &buffer);
@@ -360,8 +913,14 @@ static void call_js_write(napi_env env, napi_value js_callback, void* context, v
 
 static int streaming_write_cb(void* ctx, const char* buf, int len) {
   napi_threadsafe_function tsfn = (napi_threadsafe_function)ctx;
+  // Round-9 (#2): OOM here must not deref NULL / memcpy into NULL. Returning -1
+  // aborts the native run cleanly (write-callback contract: non-zero stops the
+  // DataWeave run); the worker then still produces a terminal meta_result and
+  // sentinel, so the op resolves.
   struct chunk_data* chunk = malloc(sizeof(struct chunk_data));
+  if (chunk == NULL) return -1;
   chunk->buf = malloc(len);
+  if (chunk->buf == NULL) { free(chunk); return -1; }
   memcpy(chunk->buf, buf, len);
   chunk->len = len;
 
@@ -380,70 +939,273 @@ static void streaming_thread_fn(void* arg) {
   void* worker_thread = NULL;
   int rc = fn_attach_thread(g_isolate, &worker_thread);
 
+  // Round-9 (#2): strdup can fail under OOM. meta_result must still be a valid
+  // C string so the sentinel path below can deliver a terminal result -- fall
+  // back to the OOM_JSON static (which must never be freed; see the guarded
+  // frees below and in call_js_write).
   char* meta_result = NULL;
   if (rc != 0) {
     char err[256];
     snprintf(err, sizeof(err), "{\"success\":false,\"error\":\"Failed to attach thread (code %d)\"}", rc);
     meta_result = strdup(err);
+    if (meta_result == NULL) meta_result = (char*)OOM_JSON;
   } else {
-    void* result_ptr = fn_run_script_callback(
-      worker_thread, w->script, w->inputs_json, streaming_write_cb, (void*)w->tsfn
+    void* result_ptr = fn_run_script_callback_engine(
+      worker_thread, w->handle, w->script, w->inputs_json, streaming_write_cb, (void*)w->tsfn
     );
     if (result_ptr) {
       meta_result = strdup((const char*)result_ptr);
+      if (meta_result == NULL) meta_result = (char*)OOM_JSON;
       fn_free_cstring(worker_thread, result_ptr);
     } else {
       meta_result = strdup("{\"success\":false,\"error\":\"Empty response\"}");
+      if (meta_result == NULL) meta_result = (char*)OOM_JSON;
     }
     fn_detach_thread(worker_thread);
   }
 
+  // Decrement here, once this thread has fully detached from the isolate --
+  // not in call_js_write's completion branch. call_js_write only runs when
+  // the JS thread's event loop turns, and napi_initialize's pending-teardown
+  // wait (Task 3) can block that same event loop indefinitely; decrementing
+  // from the JS-thread callback made the two waits circular. Decrementing
+  // here ties g_active_ops to the actual invariant isolate teardown needs
+  // (no GraalVM-attached thread remains), independent of the event loop.
+  uv_mutex_lock(&g_mutex);
+  g_active_ops--;
+  uv_cond_broadcast(&g_teardown_cond);
+  // Round-14 (#2/#3): if a prior last-release could not tear the isolate down
+  // and left it stranded (g_teardown_needed), retry now that this op has drained.
+  retry_stranded_teardown_locked();
+  uv_mutex_unlock(&g_mutex);
+
+  // Round-9 (#2): if even the sentinel struct cannot be allocated, we cannot
+  // enqueue a completion -- run the SAME native finalize the env-dead
+  // (napi_closing) branch below runs, so g_active_ops (already decremented
+  // above) plus the bridge in-flight hold and w are released and nothing is
+  // stranded. This is the "sentinel malloc NULL -> skip enqueue + unwind like
+  // the env-dead sentinel branch" path.
   struct chunk_data* sentinel = malloc(sizeof(struct chunk_data));
+  if (sentinel == NULL) {
+    if (meta_result != OOM_JSON) free(meta_result);
+    free(w->script);
+    free(w->inputs_json);
+    bridge_end_op(w->bridge, /*env_still_alive=*/false);
+    free(w);
+    return;
+  }
   sentinel->buf = meta_result;
   sentinel->len = -1;
-  napi_call_threadsafe_function(w->tsfn, sentinel, napi_tsfn_blocking);
+  napi_status enq = napi_call_threadsafe_function(w->tsfn, sentinel, napi_tsfn_blocking);
+  if (enq != napi_ok) {
+    // The env is tearing down (napi_closing): the sentinel was dropped and
+    // call_js_write will never run, so finalize here instead -- the exact same
+    // native cleanup as call_js_write's sentinel branch, minus the things
+    // that are illegal, impossible, or already done on this worker thread:
+    //   - no napi value / deferred call (env is dead; those are env-affine)
+    //   - no uv_thread_join(&w->tid): we ARE w->tid; a thread cannot join
+    //     itself. The handle goes unreaped -- an unavoidable, negligible leak
+    //     during a Worker teardown that is already discarding this env.
+    //   - no napi_release_threadsafe_function(w->tsfn, ...): this tsfn was
+    //     created with initial_thread_count = 1 and this worker is its sole
+    //     producer, so Node's internal thread_count for it is exactly 1 on
+    //     entry to this Push call. Node's ThreadSafeFunction::Push (the
+    //     implementation behind napi_call_threadsafe_function) decrements
+    //     thread_count for the calling thread BEFORE returning napi_closing,
+    //     and -- if that decrement brings thread_count to 0 while the
+    //     internal state is already kClosed -- Push runs `delete this` on
+    //     the tsfn right there. So receiving napi_closing here already IS
+    //     this thread's discharge of the tsfn (matches the doc's "destroyed
+    //     when every thread ... has called napi_release_threadsafe_function()
+    //     or has received a return status of napi_closing"); calling release
+    //     again afterward would be a double-discharge and, whenever Push
+    //     already deleted the object, a use-after-free. Omit it.
+    // End the bridge op with env_still_alive=false so bridge_finalize skips
+    // the thread-affine napi_delete_reference (Node auto-reclaims the ref
+    // when the dead env is destroyed).
+    if (sentinel->buf != OOM_JSON) free(sentinel->buf);
+    free(sentinel);
+    free(w->script);
+    free(w->inputs_json);
+    bridge_end_op(w->bridge, /*env_still_alive=*/false);
+    free(w);
+  }
 }
 
-static napi_value napi_run_script_streaming(napi_env env, napi_callback_info info) {
+static napi_value napi_run_script_streaming_engine(napi_env env, napi_callback_info info) {
   if (!g_initialized) {
     napi_throw_error(env, NULL, "Not initialized. Call initialize() first.");
     return NULL;
   }
-  if (!fn_run_script_callback) {
-    napi_throw_error(env, NULL, "run_script_callback not available in native library");
+  if (!fn_run_script_callback_engine) {
+    napi_throw_error(env, NULL, "run_script_callback_engine not available in native library");
     return NULL;
   }
 
-  size_t argc = 3;
-  napi_value argv[3];
+  size_t argc = 4;
+  napi_value argv[4];
   napi_get_cb_info(env, info, &argc, argv, NULL, NULL);
 
-  if (argc < 3) {
-    napi_throw_error(env, NULL, "runScriptStreaming requires (script, inputsJson, chunkCallback)");
+  if (argc < 4) {
+    napi_throw_error(env, NULL, "runScriptStreamingEngine requires (handle, script, inputsJson, chunkCallback)");
+    return NULL;
+  }
+
+  // Validate the handle before admission (round-6 #1, defense-in-depth): a
+  // non-integer handle must be rejected before g_active_ops is ever reserved,
+  // so there is nothing to unwind here -- simpler than reserving first and
+  // unwinding on failure.
+  int64_t handle64;
+  if (napi_get_value_int64(env, argv[0], &handle64) != napi_ok) {
+    napi_throw_error(env, NULL, "runScriptStreamingEngine: handle must be an integer");
+    return NULL;
+  }
+
+  // Atomic admission: check lifecycle state and reserve the op in ONE critical
+  // section, before allocating any work/tsfn/promise/bridge. Reading
+  // g_initialized outside the lock and reserving g_active_ops later (the old
+  // shape) let a second Worker's napi_cleanup Case-4 tear the isolate down in
+  // the gap, so a freshly spawned worker attached to a dead isolate (round-6
+  // #2). Rejecting on g_teardown_state != TEARDOWN_NONE also refuses new ops
+  // once a teardown is queued/underway. Admit an ADOPTED isolate:
+  // napi_initialize's adoption branch sets g_teardown_cancelled = true on a
+  // still-live PENDING_WAIT isolate but does not reset g_teardown_state (only
+  // the async waiter does), so a merely-cancelled teardown must not reject
+  // here -- otherwise a valid post-adoption op throws "Not initialized". A
+  // genuine (non-cancelled) PENDING_WAIT or a committed TEARING_DOWN still
+  // rejects.
+  uv_mutex_lock(&g_mutex);
+  if (!g_initialized || (g_teardown_state != TEARDOWN_NONE && !g_teardown_cancelled)) {
+    uv_mutex_unlock(&g_mutex);
+    napi_throw_error(env, NULL, "Not initialized. Call initialize() first.");
     return NULL;
   }
+  g_active_ops++;
+  // Round-11 (#2): pin the engine in the SAME critical section as the
+  // g_active_ops reservation, before any window a concurrent destroyEngine
+  // could use. NULL for an unknown handle (the worker surfaces "Unknown engine
+  // handle"). Stashed on w->bridge once w is allocated; every early-return
+  // below releases it via bridge_end_op alongside g_active_ops.
+  engine_bridge_t* pinned = bridge_begin_op_locked((long long)handle64);
+  uv_mutex_unlock(&g_mutex);
 
+  // Conversions run after the admission reservation above, so any throw here
+  // must release g_active_ops before returning (round-7 #2).
   size_t script_len, inputs_len;
-  napi_get_value_string_utf8(env, argv[0], NULL, 0, &script_len);
-  napi_get_value_string_utf8(env, argv[1], NULL, 0, &inputs_len);
+  if (napi_get_value_string_utf8(env, argv[1], NULL, 0, &script_len) != napi_ok) {
+    bridge_end_op(pinned, /*env_still_alive=*/true);
+    uv_mutex_lock(&g_mutex); g_active_ops--; uv_cond_broadcast(&g_teardown_cond); uv_mutex_unlock(&g_mutex);
+    napi_throw_error(env, NULL, "runScriptStreamingEngine: script must be a string");
+    return NULL;
+  }
+  if (napi_get_value_string_utf8(env, argv[2], NULL, 0, &inputs_len) != napi_ok) {
+    bridge_end_op(pinned, /*env_still_alive=*/true);
+    uv_mutex_lock(&g_mutex); g_active_ops--; uv_cond_broadcast(&g_teardown_cond); uv_mutex_unlock(&g_mutex);
+    napi_throw_error(env, NULL, "runScriptStreamingEngine: inputsJson must be a string");
+    return NULL;
+  }
 
+  // OOM safety (round-8): every allocation is NULL-checked before it is
+  // dereferenced, and every failure path releases the g_active_ops reservation
+  // taken above (mirroring napi_run_script_engine's "OOM" throw). Without this
+  // an allocation failure segfaults the host process AND strands g_active_ops.
   struct streaming_work* w = calloc(1, sizeof(struct streaming_work));
+  if (w == NULL) {
+    // w is NULL -- do not touch w->script/w->inputs_json here.
+    bridge_end_op(pinned, /*env_still_alive=*/true);
+    uv_mutex_lock(&g_mutex); g_active_ops--; uv_cond_broadcast(&g_teardown_cond); uv_mutex_unlock(&g_mutex);
+    napi_throw_error(env, NULL, "OOM");
+    return NULL;
+  }
+  w->handle = (long long)handle64;
   w->script = malloc(script_len + 1);
   w->inputs_json = malloc(inputs_len + 1);
-  napi_get_value_string_utf8(env, argv[0], w->script, script_len + 1, NULL);
-  napi_get_value_string_utf8(env, argv[1], w->inputs_json, inputs_len + 1, NULL);
+  if (w->script == NULL || w->inputs_json == NULL) {
+    free(w->script); free(w->inputs_json); free(w);
+    bridge_end_op(pinned, /*env_still_alive=*/true);
+    uv_mutex_lock(&g_mutex); g_active_ops--; uv_cond_broadcast(&g_teardown_cond); uv_mutex_unlock(&g_mutex);
+    napi_throw_error(env, NULL, "OOM");
+    return NULL;
+  }
+  if (napi_get_value_string_utf8(env, argv[1], w->script, script_len + 1, NULL) != napi_ok ||
+      napi_get_value_string_utf8(env, argv[2], w->inputs_json, inputs_len + 1, NULL) != napi_ok) {
+    free(w->script); free(w->inputs_json); free(w);
+    bridge_end_op(pinned, /*env_still_alive=*/true);
+    uv_mutex_lock(&g_mutex); g_active_ops--; uv_cond_broadcast(&g_teardown_cond); uv_mutex_unlock(&g_mutex);
+    napi_throw_error(env, NULL, "runScriptStreamingEngine: failed to read script/inputsJson");
+    return NULL;
+  }
 
+  // Round-9 (#3, updated round-11 #2): the resource creations below run AFTER
+  // g_active_ops was reserved (and after w + its buffers were allocated), and
+  // the engine pin (`pinned`) was already taken at admission. A failed create
+  // must release both the pin (bridge_end_op) and g_active_ops (verbatim
+  // pattern), free any tsfn already created, free w + buffers, and throw --
+  // otherwise the worker sees a zeroed w->tsfn/w->deferred (crash), the pin is
+  // stranded (blocks destroyEngine forever), or g_active_ops is stranded
+  // (teardown wedge).
   napi_value resource_name;
-  napi_create_string_utf8(env, "dwStreaming", NAPI_AUTO_LENGTH, &resource_name);
-  napi_create_threadsafe_function(env, argv[2], NULL, resource_name, 0, 1, NULL, NULL, w, call_js_write, &w->tsfn);
+  if (napi_create_string_utf8(env, "dwStreaming", NAPI_AUTO_LENGTH, &resource_name) != napi_ok) {
+    free(w->script); free(w->inputs_json); free(w);
+    bridge_end_op(pinned, /*env_still_alive=*/true);
+    uv_mutex_lock(&g_mutex); g_active_ops--; uv_cond_broadcast(&g_teardown_cond); uv_mutex_unlock(&g_mutex);
+    napi_throw_error(env, NULL, "runScriptStreamingEngine: failed to create resource name");
+    return NULL;
+  }
+  if (napi_create_threadsafe_function(env, argv[3], NULL, resource_name, 0, 1, NULL, NULL, w, call_js_write, &w->tsfn) != napi_ok) {
+    free(w->script); free(w->inputs_json); free(w);
+    bridge_end_op(pinned, /*env_still_alive=*/true);
+    uv_mutex_lock(&g_mutex); g_active_ops--; uv_cond_broadcast(&g_teardown_cond); uv_mutex_unlock(&g_mutex);
+    napi_throw_error(env, NULL, "runScriptStreamingEngine: failed to create threadsafe function");
+    return NULL;
+  }
 
   napi_value promise;
-  napi_create_promise(env, &w->deferred, &promise);
+  if (napi_create_promise(env, &w->deferred, &promise) != napi_ok) {
+    // The tsfn was created above; release it before freeing w (it holds w as
+    // its context). No worker exists yet, so this release is the sole discharge.
+    napi_release_threadsafe_function(w->tsfn, napi_tsfn_release);
+    free(w->script); free(w->inputs_json); free(w);
+    bridge_end_op(pinned, /*env_still_alive=*/true);
+    uv_mutex_lock(&g_mutex); g_active_ops--; uv_cond_broadcast(&g_teardown_cond); uv_mutex_unlock(&g_mutex);
+    napi_throw_error(env, NULL, "runScriptStreamingEngine: failed to create promise");
+    return NULL;
+  }
+
+  // Round-11 (#2): the pin was taken at admission (bridge_begin_op_locked) in
+  // the same critical section as g_active_ops, so a concurrent destroyEngine
+  // could never free this bridge under the admitted op. Just record it on w;
+  // the completion sentinel releases it via bridge_end_op. NULL for a
+  // resolver-less/unknown engine, handled everywhere as a no-op.
+  w->bridge = pinned;
 
   uv_thread_options_t opts;
   opts.flags = UV_THREAD_HAS_STACK_SIZE;
   opts.stack_size = 2 * 1024 * 1024;
-  uv_thread_create_ex(&w->tid, &opts, streaming_thread_fn, w);
+  int spawn_rc = uv_thread_create_ex(&w->tid, &opts, streaming_thread_fn, w);
+
+  if (spawn_rc != 0) {
+    // The worker never ran, so nothing will ever decrement g_active_ops,
+    // release the bridge hold, or resolve the promise -- unwind everything
+    // committed above ourselves, in reverse order, mirroring call_js_write's
+    // completion branch (minus uv_thread_join: there is no thread to join).
+    uv_mutex_lock(&g_mutex);
+    g_active_ops--;
+    uv_cond_broadcast(&g_teardown_cond);
+    uv_mutex_unlock(&g_mutex);
+
+    // Synchronous call on the JS thread -- env is live here.
+    bridge_end_op(w->bridge, /*env_still_alive=*/true);
+    napi_release_threadsafe_function(w->tsfn, napi_tsfn_release);
+
+    napi_value result;
+    napi_create_string_utf8(env, "{\"success\":false,\"error\":\"Failed to spawn streaming worker thread\"}", NAPI_AUTO_LENGTH, &result);
+    napi_resolve_deferred(env, w->deferred, result);
+
+    free(w->script);
+    free(w->inputs_json);
+    free(w);
+  }
 
   return promise;
 }
@@ -455,11 +1217,17 @@ struct transform_work {
   napi_threadsafe_function read_tsfn;
   napi_threadsafe_function write_tsfn;
   napi_deferred deferred;
+  long long handle;
   char* script;
   char* inputs_json;
   char* input_name;
   char* input_mime_type;
   char* input_charset;
+  // The engine's record whose in_flight count this op holds. Since round-9 (#1)
+  // every engine has a record, so this is non-NULL for any known handle (NULL only
+  // for an unknown handle). The completion sentinel calls bridge_end_op on it to
+  // balance in_flight and run any deferred destroy (F1).
+  engine_bridge_t* bridge;
 };
 
 struct read_request {
@@ -472,66 +1240,78 @@ struct read_request {
 };
 
 static void call_js_read(napi_env env, napi_value js_callback, void* context, void* data) {
-  if (env == NULL || data == NULL) return;
+  if (data == NULL) return;  // nothing to signal
   struct read_request* req = (struct read_request*)data;
 
-  napi_value buf_size_val;
-  napi_create_int32(env, req->buffer_size, &buf_size_val);
+  if (env == NULL) {
+    // N-API can invoke a threadsafe-function callback with env == NULL when
+    // the environment is tearing down with items still queued (e.g. a Worker
+    // terminating mid-transform). transform_read_cb is synchronously blocked
+    // on req->cond waiting for this callback to signal it -- unlike
+    // call_js_write/call_js_transform_write, there is no sentinel-driven path
+    // that would otherwise unblock it. Treat this as a terminal read error so
+    // the blocked thread wakes up, detects the failure via bytes_read == -1,
+    // and the worker can detach from the isolate instead of hanging forever.
+    req->bytes_read = -1;
+  } else {
+    napi_value buf_size_val;
+    napi_create_int32(env, req->buffer_size, &buf_size_val);
 
-  napi_value global;
-  napi_get_global(env, &global);
+    napi_value global;
+    napi_get_global(env, &global);
 
-  napi_value result;
-  napi_status status = napi_call_function(env, global, js_callback, 1, &buf_size_val, &result);
-
-  if (status == napi_ok && result != NULL) {
-    bool is_buffer;
-    napi_is_buffer(env, result, &is_buffer);
-    if (is_buffer) {
-      void* buf_data;
-      size_t buf_len;
-      napi_get_buffer_info(env, result, &buf_data, &buf_len);
-      int n = (int)buf_len < req->buffer_size ? (int)buf_len : req->buffer_size;
-      if (n > 0) memcpy(req->buffer, buf_data, n);
-      req->bytes_read = n;
-    } else {
-      req->bytes_read = 0;
-    }
-  } else {
-    // Clear pending exception to prevent propagation
-    if (status == napi_pending_exception) {
-      napi_value exception;
-      napi_get_and_clear_last_exception(env, &exception);
-
-      // Extract and log exception details before discarding
-      napi_value message_prop, stack_prop;
-      char message_buf[512] = {0};
-      char stack_buf[2048] = {0};
-      size_t message_len = 0, stack_len = 0;
-
-      // Try to get the message property
-      if (napi_get_named_property(env, exception, "message", &message_prop) == napi_ok) {
-        napi_get_value_string_utf8(env, message_prop, message_buf, sizeof(message_buf), &message_len);
+    napi_value result;
+    napi_status status = napi_call_function(env, global, js_callback, 1, &buf_size_val, &result);
+
+    if (status == napi_ok && result != NULL) {
+      bool is_buffer;
+      napi_is_buffer(env, result, &is_buffer);
+      if (is_buffer) {
+        void* buf_data;
+        size_t buf_len;
+        napi_get_buffer_info(env, result, &buf_data, &buf_len);
+        int n = (int)buf_len < req->buffer_size ? (int)buf_len : req->buffer_size;
+        if (n > 0) memcpy(req->buffer, buf_data, n);
+        req->bytes_read = n;
+      } else {
+        req->bytes_read = 0;
       }
+    } else {
+      // Clear pending exception to prevent propagation
+      if (status == napi_pending_exception) {
+        napi_value exception;
+        napi_get_and_clear_last_exception(env, &exception);
+
+        // Extract and log exception details before discarding
+        napi_value message_prop, stack_prop;
+        char message_buf[512] = {0};
+        char stack_buf[2048] = {0};
+        size_t message_len = 0, stack_len = 0;
+
+        // Try to get the message property
+        if (napi_get_named_property(env, exception, "message", &message_prop) == napi_ok) {
+          napi_get_value_string_utf8(env, message_prop, message_buf, sizeof(message_buf), &message_len);
+        }
 
-      // Try to get the stack property
-      if (napi_get_named_property(env, exception, "stack", &stack_prop) == napi_ok) {
-        napi_get_value_string_utf8(env, stack_prop, stack_buf, sizeof(stack_buf), &stack_len);
-      }
+        // Try to get the stack property
+        if (napi_get_named_property(env, exception, "stack", &stack_prop) == napi_ok) {
+          napi_get_value_string_utf8(env, stack_prop, stack_buf, sizeof(stack_buf), &stack_len);
+        }
 
-      // Log the exception to stderr for diagnostics
-      fprintf(stderr, "[DataWeave Node addon] Read callback threw exception:\n");
-      if (message_len > 0) {
-        fprintf(stderr, "  Message: %s\n", message_buf);
-      }
-      if (stack_len > 0) {
-        fprintf(stderr, "  Stack:\n%s\n", stack_buf);
-      }
-      if (message_len == 0 && stack_len == 0) {
-        fprintf(stderr, "  (Unable to extract exception details)\n");
+        // Log the exception to stderr for diagnostics
+        fprintf(stderr, "[DataWeave Node addon] Read callback threw exception:\n");
+        if (message_len > 0) {
+          fprintf(stderr, "  Message: %s\n", message_buf);
+        }
+        if (stack_len > 0) {
+          fprintf(stderr, "  Stack:\n%s\n", stack_buf);
+        }
+        if (message_len == 0 && stack_len == 0) {
+          fprintf(stderr, "  (Unable to extract exception details)\n");
+        }
       }
+      req->bytes_read = -1;  // Signal error
     }
-    req->bytes_read = -1;  // Signal error
   }
 
   uv_mutex_lock(&req->mutex);
@@ -572,8 +1352,12 @@ static int transform_read_cb(void* ctx, char* buf, int buf_size) {
 
 static int transform_write_cb(void* ctx, const char* buf, int len) {
   struct transform_work* w = (struct transform_work*)ctx;
+  // Round-9 (#2): OOM-safe, mirrors streaming_write_cb. Return -1 to abort the
+  // native run cleanly; the worker still delivers a terminal sentinel.
   struct chunk_data* chunk = malloc(sizeof(struct chunk_data));
+  if (chunk == NULL) return -1;
   chunk->buf = malloc(len);
+  if (chunk->buf == NULL) { free(chunk); return -1; }
   memcpy(chunk->buf, buf, len);
   chunk->len = len;
 
@@ -587,16 +1371,27 @@ static int transform_write_cb(void* ctx, const char* buf, int len) {
 }
 
 static void call_js_transform_write(napi_env env, napi_value js_callback, void* context, void* data) {
-  if (env == NULL || data == NULL) return;
+  // data == NULL: nothing was queued, nothing to free or finalize.
+  if (data == NULL) return;
   struct chunk_data* chunk = (struct chunk_data*)data;
   struct transform_work* w = (struct transform_work*)context;
 
   if (chunk->len == -1) {
-    napi_value result;
-    napi_create_string_utf8(env, chunk->buf, strlen(chunk->buf), &result);
-    napi_resolve_deferred(env, w->deferred, result);
+    // Completion sentinel. env == NULL means the environment is tearing down
+    // (e.g. a Worker terminating mid-op): we must not call any napi value or
+    // JS-calling API (napi_create_string_utf8/napi_resolve_deferred need a
+    // live env), but we must still perform every bit of native finalization
+    // -- join the worker, release both tsfns, drop the bridge in-flight hold,
+    // and free every heap field -- exactly once. Skipping this on env == NULL
+    // would leak `w` and could strand a bridge marked for deferred destruction
+    // indefinitely.
+    if (env != NULL) {
+      napi_value result;
+      napi_create_string_utf8(env, chunk->buf, strlen(chunk->buf), &result);
+      napi_resolve_deferred(env, w->deferred, result);
+    }
 
-    free(chunk->buf);
+    if (chunk->buf != OOM_JSON) free(chunk->buf);
     free(chunk);
     free(w->script);
     free(w->inputs_json);
@@ -607,10 +1402,25 @@ static void call_js_transform_write(napi_env env, napi_value js_callback, void*
     uv_thread_join(&w->tid);
     napi_release_threadsafe_function(w->read_tsfn, napi_tsfn_release);
     napi_release_threadsafe_function(w->write_tsfn, napi_tsfn_release);
+    // Drop the in-flight hold last, on this owner thread: if destroyEngine ran
+    // during the op it deferred the free to here (F1). After this the bridge may
+    // be freed, so touch nothing on it afterward. env == NULL means this env is
+    // dead/tearing down -- tell bridge_end_op (and any bridge_finalize it
+    // triggers) not to touch the napi_ref, since b->env is this same dead env.
+    bridge_end_op(w->bridge, /*env_still_alive=*/env != NULL);
     free(w);
     return;
   }
 
+  // Non-sentinel data chunk. If env == NULL the environment is gone and we
+  // cannot deliver it to JS; free it and return without touching `w` (its
+  // finalization happens only on the sentinel, above).
+  if (env == NULL) {
+    free(chunk->buf);
+    free(chunk);
+    return;
+  }
+
   napi_value buffer;
   void* buf_data;
   napi_create_buffer_copy(env, chunk->len, chunk->buf, &buf_data, &buffer);
@@ -629,94 +1439,295 @@ static void transform_thread_fn(void* arg) {
   void* worker_thread = NULL;
   int rc = fn_attach_thread(g_isolate, &worker_thread);
 
+  // Round-9 (#2): strdup can fail under OOM; fall back to the OOM_JSON static
+  // so the sentinel below still delivers a terminal result. Mirrors
+  // streaming_thread_fn.
   char* meta_result = NULL;
   if (rc != 0) {
     char err[256];
     snprintf(err, sizeof(err), "{\"success\":false,\"error\":\"Failed to attach thread (code %d)\"}", rc);
     meta_result = strdup(err);
+    if (meta_result == NULL) meta_result = (char*)OOM_JSON;
   } else {
-    void* result_ptr = fn_run_script_input_output_callback(
-      worker_thread, w->script, w->inputs_json,
+    void* result_ptr = fn_run_script_input_output_callback_engine(
+      worker_thread, w->handle, w->script, w->inputs_json,
       w->input_name, w->input_mime_type, w->input_charset,
       transform_read_cb, transform_write_cb, (void*)w
     );
 
     if (result_ptr) {
       meta_result = strdup((const char*)result_ptr);
+      if (meta_result == NULL) meta_result = (char*)OOM_JSON;
       fn_free_cstring(worker_thread, result_ptr);
     } else {
       meta_result = strdup("{\"success\":false,\"error\":\"Empty response\"}");
+      if (meta_result == NULL) meta_result = (char*)OOM_JSON;
     }
     fn_detach_thread(worker_thread);
   }
 
+  // See streaming_thread_fn's comment: decrement here (after detach), not in
+  // call_js_transform_write's completion branch, to avoid the same
+  // circular-wait deadlock against napi_initialize's pending-teardown wait.
+  uv_mutex_lock(&g_mutex);
+  g_active_ops--;
+  uv_cond_broadcast(&g_teardown_cond);
+  // Round-14 (#2/#3): retry a stranded teardown now that this op has drained.
+  retry_stranded_teardown_locked();
+  uv_mutex_unlock(&g_mutex);
+
+  // Round-9 (#2): sentinel malloc NULL -> skip enqueue and run the same native
+  // finalize as the env-dead branch below (release the bridge hold + free w and
+  // all fields), so g_active_ops (already decremented above) and the in-flight
+  // hold are released. No self-join, no env-affine napi call, no tsfn release
+  // (see the env-dead branch's citation for why releasing the tsfns here is
+  // unsafe).
   struct chunk_data* sentinel = malloc(sizeof(struct chunk_data));
+  if (sentinel == NULL) {
+    if (meta_result != OOM_JSON) free(meta_result);
+    free(w->script);
+    free(w->inputs_json);
+    free(w->input_name);
+    free(w->input_mime_type);
+    free(w->input_charset);
+    bridge_end_op(w->bridge, /*env_still_alive=*/false);
+    free(w);
+    return;
+  }
   sentinel->buf = meta_result;
   sentinel->len = -1;
-  napi_call_threadsafe_function(w->write_tsfn, sentinel, napi_tsfn_blocking);
+  napi_status enq = napi_call_threadsafe_function(w->write_tsfn, sentinel, napi_tsfn_blocking);
+  if (enq != napi_ok) {
+    // See streaming_thread_fn: env tearing down, sentinel dropped, finalize
+    // here. No self-join, no env-affine napi call.
+    //
+    // Do NOT release write_tsfn: this worker is its sole producer
+    // (initial_thread_count = 1), so receiving napi_closing from this same
+    // Push call already decremented Node's internal thread_count for it to 0
+    // and, if the tsfn's internal state was already kClosed, already ran
+    // `delete this` on it inside Push -- see streaming_thread_fn's comment
+    // for the full citation. Releasing it again here would be a
+    // double-discharge and potentially a use-after-free.
+    //
+    // Do NOT release read_tsfn either, even though this same worker is also
+    // its sole producer: whether *it* has already received napi_closing (and
+    // so already discharged/deleted itself the same way) depends on whether
+    // the script issued reads during teardown, which this code path has no
+    // way to know. We cannot prove read_tsfn's discharge state here, so --
+    // consistent with the env == NULL dead-env handling elsewhere in this
+    // file -- we accept the small leak of an already-tearing-down tsfn
+    // rather than risk a use-after-free on an object whose state is unknown.
+    //
+    // End the bridge op with env_still_alive=false so bridge_finalize skips
+    // the thread-affine napi_delete_reference (Node auto-reclaims the ref
+    // when the dead env is destroyed).
+    if (sentinel->buf != OOM_JSON) free(sentinel->buf);
+    free(sentinel);
+    free(w->script);
+    free(w->inputs_json);
+    free(w->input_name);
+    free(w->input_mime_type);
+    free(w->input_charset);
+    bridge_end_op(w->bridge, /*env_still_alive=*/false);
+    free(w);
+  }
 }
 
-static napi_value napi_run_script_transform(napi_env env, napi_callback_info info) {
+static napi_value napi_run_script_transform_engine(napi_env env, napi_callback_info info) {
   if (!g_initialized) {
     napi_throw_error(env, NULL, "Not initialized. Call initialize() first.");
     return NULL;
   }
-  if (!fn_run_script_input_output_callback) {
-    napi_throw_error(env, NULL, "run_script_input_output_callback not available in native library");
+  if (!fn_run_script_input_output_callback_engine) {
+    napi_throw_error(env, NULL, "run_script_input_output_callback_engine not available in native library");
     return NULL;
   }
 
-  size_t argc = 7;
-  napi_value argv[7];
+  size_t argc = 8;
+  napi_value argv[8];
   napi_get_cb_info(env, info, &argc, argv, NULL, NULL);
 
-  if (argc < 7) {
-    napi_throw_error(env, NULL, "runScriptTransform requires 7 arguments");
+  if (argc < 8) {
+    napi_throw_error(env, NULL, "runScriptTransformEngine requires 8 arguments");
+    return NULL;
+  }
+
+  // Validate the handle before admission (round-6 #1, defense-in-depth): a
+  // non-integer handle must be rejected before g_active_ops is ever reserved,
+  // so there is nothing to unwind here -- simpler than reserving first and
+  // unwinding on failure. Keep this consistent with
+  // napi_run_script_streaming_engine's ordering.
+  int64_t handle64;
+  if (napi_get_value_int64(env, argv[0], &handle64) != napi_ok) {
+    napi_throw_error(env, NULL, "runScriptTransformEngine: handle must be an integer");
     return NULL;
   }
 
+  // Atomic admission (see napi_run_script_streaming_engine for the full
+  // rationale, round-6 #2): check lifecycle + reserve g_active_ops in one
+  // critical section, before any work/tsfn/promise/bridge is committed.
+  // Admit an ADOPTED isolate: napi_initialize's adoption branch sets
+  // g_teardown_cancelled = true on a still-live PENDING_WAIT isolate but does
+  // not reset g_teardown_state (only the async waiter does), so a
+  // merely-cancelled teardown must not reject here -- otherwise a valid
+  // post-adoption op throws "Not initialized". A genuine (non-cancelled)
+  // PENDING_WAIT or a committed TEARING_DOWN still rejects.
+  uv_mutex_lock(&g_mutex);
+  if (!g_initialized || (g_teardown_state != TEARDOWN_NONE && !g_teardown_cancelled)) {
+    uv_mutex_unlock(&g_mutex);
+    napi_throw_error(env, NULL, "Not initialized. Call initialize() first.");
+    return NULL;
+  }
+  g_active_ops++;
+  // Round-11 (#2): pin the engine in the SAME critical section as the
+  // g_active_ops reservation, before any window a concurrent destroyEngine
+  // could use. NULL for an unknown handle (the worker surfaces "Unknown engine
+  // handle"). Stashed on w->bridge once w is allocated; every early-return
+  // below releases it via bridge_end_op alongside g_active_ops.
+  engine_bridge_t* pinned = bridge_begin_op_locked((long long)handle64);
+  uv_mutex_unlock(&g_mutex);
+
+  // Conversions run after the admission reservation above, so any throw here
+  // must free the partially-populated work struct AND release g_active_ops
+  // before returning (round-7 #2). calloc zeroed w, so free() on an unset
+  // field pointer is a safe free(NULL). TRANSFORM_FAIL centralizes the
+  // unwind.
+  // OOM safety (round-8): NULL-check the work struct before dereferencing it,
+  // releasing the g_active_ops reservation taken above. The per-field malloc
+  // checks below reuse TRANSFORM_FAIL (which frees all fields + w and unwinds);
+  // this standalone branch cannot use it (the macro dereferences w).
   struct transform_work* w = calloc(1, sizeof(struct transform_work));
+  if (w == NULL) {
+    bridge_end_op(pinned, /*env_still_alive=*/true);
+    uv_mutex_lock(&g_mutex); g_active_ops--; uv_cond_broadcast(&g_teardown_cond); uv_mutex_unlock(&g_mutex);
+    napi_throw_error(env, NULL, "OOM");
+    return NULL;
+  }
   size_t len;
-
-  napi_get_value_string_utf8(env, argv[0], NULL, 0, &len);
+  w->handle = (long long)handle64;
+
+  #define TRANSFORM_FAIL(msg) do { \
+      bridge_end_op(pinned, /*env_still_alive=*/true); \
+      free(w->script); free(w->inputs_json); free(w->input_name); \
+      free(w->input_mime_type); free(w->input_charset); free(w); \
+      uv_mutex_lock(&g_mutex); g_active_ops--; uv_cond_broadcast(&g_teardown_cond); uv_mutex_unlock(&g_mutex); \
+      napi_throw_error(env, NULL, (msg)); \
+      return NULL; \
+  } while (0)
+
+  if (napi_get_value_string_utf8(env, argv[1], NULL, 0, &len) != napi_ok) TRANSFORM_FAIL("runScriptTransformEngine: script must be a string");
   w->script = malloc(len + 1);
-  napi_get_value_string_utf8(env, argv[0], w->script, len + 1, NULL);
+  if (w->script == NULL) TRANSFORM_FAIL("OOM");
+  if (napi_get_value_string_utf8(env, argv[1], w->script, len + 1, NULL) != napi_ok) TRANSFORM_FAIL("runScriptTransformEngine: failed to read script");
 
-  napi_get_value_string_utf8(env, argv[1], NULL, 0, &len);
+  if (napi_get_value_string_utf8(env, argv[2], NULL, 0, &len) != napi_ok) TRANSFORM_FAIL("runScriptTransformEngine: inputsJson must be a string");
   w->inputs_json = malloc(len + 1);
-  napi_get_value_string_utf8(env, argv[1], w->inputs_json, len + 1, NULL);
+  if (w->inputs_json == NULL) TRANSFORM_FAIL("OOM");
+  if (napi_get_value_string_utf8(env, argv[2], w->inputs_json, len + 1, NULL) != napi_ok) TRANSFORM_FAIL("runScriptTransformEngine: failed to read inputsJson");
 
-  napi_get_value_string_utf8(env, argv[2], NULL, 0, &len);
+  if (napi_get_value_string_utf8(env, argv[3], NULL, 0, &len) != napi_ok) TRANSFORM_FAIL("runScriptTransformEngine: inputName must be a string");
   w->input_name = malloc(len + 1);
-  napi_get_value_string_utf8(env, argv[2], w->input_name, len + 1, NULL);
+  if (w->input_name == NULL) TRANSFORM_FAIL("OOM");
+  if (napi_get_value_string_utf8(env, argv[3], w->input_name, len + 1, NULL) != napi_ok) TRANSFORM_FAIL("runScriptTransformEngine: failed to read inputName");
 
-  napi_get_value_string_utf8(env, argv[3], NULL, 0, &len);
+  if (napi_get_value_string_utf8(env, argv[4], NULL, 0, &len) != napi_ok) TRANSFORM_FAIL("runScriptTransformEngine: inputMimeType must be a string");
   w->input_mime_type = malloc(len + 1);
-  napi_get_value_string_utf8(env, argv[3], w->input_mime_type, len + 1, NULL);
+  if (w->input_mime_type == NULL) TRANSFORM_FAIL("OOM");
+  if (napi_get_value_string_utf8(env, argv[4], w->input_mime_type, len + 1, NULL) != napi_ok) TRANSFORM_FAIL("runScriptTransformEngine: failed to read inputMimeType");
 
   napi_valuetype type;
-  napi_typeof(env, argv[4], &type);
+  if (napi_typeof(env, argv[5], &type) != napi_ok) TRANSFORM_FAIL("runScriptTransformEngine: invalid inputCharset argument");
   if (type == napi_string) {
-    napi_get_value_string_utf8(env, argv[4], NULL, 0, &len);
+    if (napi_get_value_string_utf8(env, argv[5], NULL, 0, &len) != napi_ok) TRANSFORM_FAIL("runScriptTransformEngine: inputCharset must be a string");
     w->input_charset = malloc(len + 1);
-    napi_get_value_string_utf8(env, argv[4], w->input_charset, len + 1, NULL);
+    if (w->input_charset == NULL) TRANSFORM_FAIL("OOM");
+    if (napi_get_value_string_utf8(env, argv[5], w->input_charset, len + 1, NULL) != napi_ok) TRANSFORM_FAIL("runScriptTransformEngine: failed to read inputCharset");
   } else {
     w->input_charset = NULL;
   }
-
+  #undef TRANSFORM_FAIL
+
+  // Round-9 (#3, updated round-11 #2): check each resource creation; on
+  // failure release the engine pin (`pinned`, taken at admission) via
+  // bridge_end_op, release g_active_ops (verbatim), release any tsfn already
+  // created, free w + all five string buffers, and throw. read_tsfn has no
+  // context (NULL); write_tsfn holds w as context, so release write_tsfn
+  // before freeing w if it was created.
   napi_value resource_name;
-  napi_create_string_utf8(env, "dwTransform", NAPI_AUTO_LENGTH, &resource_name);
+  if (napi_create_string_utf8(env, "dwTransform", NAPI_AUTO_LENGTH, &resource_name) != napi_ok) {
+    free(w->script); free(w->inputs_json); free(w->input_name); free(w->input_mime_type); free(w->input_charset); free(w);
+    bridge_end_op(pinned, /*env_still_alive=*/true);
+    uv_mutex_lock(&g_mutex); g_active_ops--; uv_cond_broadcast(&g_teardown_cond); uv_mutex_unlock(&g_mutex);
+    napi_throw_error(env, NULL, "runScriptTransformEngine: failed to create resource name");
+    return NULL;
+  }
 
-  napi_create_threadsafe_function(env, argv[5], NULL, resource_name, 0, 1, NULL, NULL, NULL, call_js_read, &w->read_tsfn);
-  napi_create_threadsafe_function(env, argv[6], NULL, resource_name, 0, 1, NULL, NULL, w, call_js_transform_write, &w->write_tsfn);
+  if (napi_create_threadsafe_function(env, argv[6], NULL, resource_name, 0, 1, NULL, NULL, NULL, call_js_read, &w->read_tsfn) != napi_ok) {
+    free(w->script); free(w->inputs_json); free(w->input_name); free(w->input_mime_type); free(w->input_charset); free(w);
+    bridge_end_op(pinned, /*env_still_alive=*/true);
+    uv_mutex_lock(&g_mutex); g_active_ops--; uv_cond_broadcast(&g_teardown_cond); uv_mutex_unlock(&g_mutex);
+    napi_throw_error(env, NULL, "runScriptTransformEngine: failed to create read threadsafe function");
+    return NULL;
+  }
+  if (napi_create_threadsafe_function(env, argv[7], NULL, resource_name, 0, 1, NULL, NULL, w, call_js_transform_write, &w->write_tsfn) != napi_ok) {
+    napi_release_threadsafe_function(w->read_tsfn, napi_tsfn_release);
+    free(w->script); free(w->inputs_json); free(w->input_name); free(w->input_mime_type); free(w->input_charset); free(w);
+    bridge_end_op(pinned, /*env_still_alive=*/true);
+    uv_mutex_lock(&g_mutex); g_active_ops--; uv_cond_broadcast(&g_teardown_cond); uv_mutex_unlock(&g_mutex);
+    napi_throw_error(env, NULL, "runScriptTransformEngine: failed to create write threadsafe function");
+    return NULL;
+  }
 
   napi_value promise;
-  napi_create_promise(env, &w->deferred, &promise);
+  if (napi_create_promise(env, &w->deferred, &promise) != napi_ok) {
+    napi_release_threadsafe_function(w->read_tsfn, napi_tsfn_release);
+    napi_release_threadsafe_function(w->write_tsfn, napi_tsfn_release);
+    free(w->script); free(w->inputs_json); free(w->input_name); free(w->input_mime_type); free(w->input_charset); free(w);
+    bridge_end_op(pinned, /*env_still_alive=*/true);
+    uv_mutex_lock(&g_mutex); g_active_ops--; uv_cond_broadcast(&g_teardown_cond); uv_mutex_unlock(&g_mutex);
+    napi_throw_error(env, NULL, "runScriptTransformEngine: failed to create promise");
+    return NULL;
+  }
+
+  // Round-11 (#2): the pin was taken at admission (bridge_begin_op_locked) in
+  // the same critical section as g_active_ops, so a concurrent destroyEngine
+  // could never free this bridge under the admitted op. Just record it on w;
+  // the completion sentinel releases it via bridge_end_op. NULL for a
+  // resolver-less/unknown engine, handled everywhere as a no-op.
+  w->bridge = pinned;
 
   uv_thread_options_t opts;
   opts.flags = UV_THREAD_HAS_STACK_SIZE;
   opts.stack_size = 2 * 1024 * 1024;
-  uv_thread_create_ex(&w->tid, &opts, transform_thread_fn, w);
+  int spawn_rc = uv_thread_create_ex(&w->tid, &opts, transform_thread_fn, w);
+
+  if (spawn_rc != 0) {
+    // The worker never ran, so nothing will ever decrement g_active_ops,
+    // release the bridge hold, or resolve the promise -- unwind everything
+    // committed above ourselves, in reverse order, mirroring
+    // call_js_transform_write's completion branch (minus uv_thread_join:
+    // there is no thread to join).
+    uv_mutex_lock(&g_mutex);
+    g_active_ops--;
+    uv_cond_broadcast(&g_teardown_cond);
+    uv_mutex_unlock(&g_mutex);
+
+    // Synchronous call on the JS thread -- env is live here.
+    bridge_end_op(w->bridge, /*env_still_alive=*/true);
+    napi_release_threadsafe_function(w->read_tsfn, napi_tsfn_release);
+    napi_release_threadsafe_function(w->write_tsfn, napi_tsfn_release);
+
+    napi_value result;
+    napi_create_string_utf8(env, "{\"success\":false,\"error\":\"Failed to spawn transform worker thread\"}", NAPI_AUTO_LENGTH, &result);
+    napi_resolve_deferred(env, w->deferred, result);
+
+    free(w->script);
+    free(w->inputs_json);
+    free(w->input_name);
+    free(w->input_mime_type);
+    free(w->input_charset);
+    free(w);
+  }
 
   return promise;
 }
@@ -724,35 +1735,36 @@ static napi_value napi_run_script_transform(napi_env env, napi_callback_info inf
 // --- Resolver callback bridge ---
 
 // Called by native code, synchronously, on the same JS thread that invoked
-// runWithResolver (see the comment on g_resolver_env above for why this must
-// NOT hop through napi_threadsafe_function). Calls the JS resolver directly
-// and returns its result copied onto the heap; the caller (napi_run_with_resolver)
-// frees it via g_resolver_last_result after the native side has copied it.
-static char* resolve_module_callback(void* thread, const char* module_path) {
+// runScriptEngine for a resolver-backed engine (see the comment on
+// engine_bridge_t above for why this must NOT hop through
+// napi_threadsafe_function). The ctx word is the engine's own engine_bridge_t*,
+// passed to Java in create_engine_with_resolver and forwarded back here. Calls
+// the JS resolver directly and returns its result copied onto the heap; the
+// caller frees the tracked buffers after the native side has copied them.
+static char* resolve_module_callback(void* thread, void* ctx, const char* module_path) {
     (void)thread;
 
-    if (g_resolver_env == NULL || g_resolver_ref == NULL) {
-        return NULL;  // No resolver set
+    engine_bridge_t* bridge = (engine_bridge_t*)ctx;
+    if (bridge == NULL || bridge->env == NULL || bridge->resolver_js == NULL) {
+        return NULL;  // No resolver for this engine
     }
 
-    // Guard against cross-thread napi calls. The engine that triggers this
-    // callback is a process-wide singleton shared by run()/runStreaming()/
-    // runTransform(); streaming and transform execute their native call on a
-    // background uv_thread (streaming_thread_fn/transform_thread_fn), not the
-    // JS thread that registered g_resolver_env/g_resolver_ref. If we're not
-    // on the thread that owns this napi_env, calling napi_get_reference_value
+    // Guard against cross-thread napi calls. Streaming and transform execute
+    // their native call on a background uv_thread (streaming_thread_fn/
+    // transform_thread_fn), not the JS thread that created this bridge. If we're
+    // not on the thread that owns this napi_env, calling napi_get_reference_value
     // or napi_call_function here is undefined behavior (typically a crash).
     // Fail closed instead: report "not found", which matches the documented
     // built-ins-only fallback for streaming/transform.
     uv_thread_t current = uv_thread_self();
-    if (!uv_thread_equal(&current, &g_resolver_thread)) {
+    if (!uv_thread_equal(&current, &bridge->owner)) {
         return NULL;
     }
 
-    napi_env env = g_resolver_env;
+    napi_env env = bridge->env;
 
     napi_value js_callback;
-    if (napi_get_reference_value(env, g_resolver_ref, &js_callback) != napi_ok) {
+    if (napi_get_reference_value(env, bridge->resolver_js, &js_callback) != napi_ok) {
         return NULL;
     }
 
@@ -849,136 +1861,467 @@ static char* resolve_module_callback(void* thread, const char* module_path) {
     }
     // null/undefined/other → not found (result_source stays NULL)
 
-    resolver_results_track(result_source);
+    if (!resolver_results_track(bridge, result_source)) {
+        // Tracking-node allocation failed (OOM): result_source would otherwise
+        // be an untracked buffer that nothing ever frees. Free it here and
+        // report "unresolved" instead of leaking it.
+        free(result_source);
+        return NULL;
+    }
     return result_source;  // Native copies this immediately; we free the original after the call.
 }
 
-// N-API method: runWithResolver
-static napi_value napi_run_with_resolver(napi_env env, napi_callback_info info) {
-    if (!g_initialized) {
+// --- Per-engine N-API methods ---
+
+// createEngine() -> number
+static napi_value napi_create_engine(napi_env env, napi_callback_info info) {
+    (void)info;
+    if (!fn_create_engine) { napi_throw_error(env, NULL, "create_engine not available in native library"); return NULL; }
+
+    // Round-14 (#1): admission in ONE g_mutex critical section (mirrors
+    // bridge_finalize_registry). Require (a) a live isolate not past the point
+    // of no return, (b) that THIS env owns an init reference (round-13 ownership
+    // model: an env with no reference must not create engines on the shared
+    // isolate -- it could otherwise attach to an isolate another env is tearing
+    // down), and (c) pin the isolate with a g_active_ops reservation so
+    // graal_tear_down_isolate() cannot run across the attach/create below. The
+    // check and the g_active_ops++ cannot be split by a teardown because every
+    // teardown transition and the g_active_ops==0 fast path also hold g_mutex.
+    uv_mutex_lock(&g_mutex);
+    env_init_rec_t* self = env_init_rec_find_locked(env);
+    if (!g_initialized || g_isolate == NULL ||
+        g_teardown_state == TEARDOWN_TEARING_DOWN ||
+        self == NULL || self->init_refs == 0) {
+        uv_mutex_unlock(&g_mutex);
         napi_throw_error(env, NULL, "Not initialized. Call initialize() first.");
         return NULL;
     }
-    if (!fn_run_script_with_resolver) {
-        napi_throw_error(env, NULL, "run_script_with_resolver not available in native library");
+    g_active_ops++;  // pins the live isolate against teardown across the attach
+    uv_mutex_unlock(&g_mutex);
+
+    void* thread = NULL;
+    if (fn_attach_thread(g_isolate, &thread) != 0) {
+        uv_mutex_lock(&g_mutex); g_active_ops--; uv_cond_broadcast(&g_teardown_cond); uv_mutex_unlock(&g_mutex);
+        napi_throw_error(env, NULL, "Failed to attach thread"); return NULL;
+    }
+    long long handle = fn_create_engine(thread);
+    fn_detach_thread(thread);
+    // A GraalVM @CEntryPoint that throws on the Java side returns the return
+    // type's default value instead of propagating the exception — 0 for a
+    // long long. The real handle registry only ever hands out handles >= 1, so
+    // any handle <= 0 means construction failed; never hand that back to JS as
+    // if it were usable.
+    if (handle <= 0) {
+        uv_mutex_lock(&g_mutex); g_active_ops--; uv_cond_broadcast(&g_teardown_cond); uv_mutex_unlock(&g_mutex);
+        napi_throw_error(env, NULL, "create_engine returned an invalid handle"); return NULL;
+    }
+
+    // Round-9 (#1): every engine -- resolver-backed or not -- gets a per-engine
+    // record so destroyEngine can defer the registry removal (fn_destroy_engine)
+    // until this engine's in-flight streaming/transform ops drain. A resolver-less
+    // record leaves resolver_js/results NULL. Round-11 (#1): it now ALSO registers
+    // an env cleanup hook (mirroring napi_create_engine_with_resolver), because
+    // without one a Worker that creates a resolver-less engine and exits without
+    // destroyEngine() would strand this record, the Java registry entry, and the
+    // native-lib reference. Round-12 (#2) closed the record/registry gap via
+    // bridge_finalize; round-13 (#5) moved ownership of the native-lib
+    // initialize() reference to the env itself (env_init_rec), released by the
+    // env-death hook env_init_cleanup, not per-engine.
+    // owner is recorded for symmetry but is NOT used to restrict destruction based
+    // on resolver state (see the owner guard in napi_destroy_engine, which now
+    // fires for any record).
+    engine_bridge_t* rec = (engine_bridge_t*)calloc(1, sizeof(engine_bridge_t));
+    if (rec == NULL) {
+        // Roll back the engine we just created so we don't leak a registered but
+        // unrecorded handle. fn_destroy_engine attaches its own thread.
+        if (fn_destroy_engine) {
+            void* t2 = NULL;
+            if (fn_attach_thread(g_isolate, &t2) == 0) { fn_destroy_engine(t2, handle); fn_detach_thread(t2); }
+        }
+        uv_mutex_lock(&g_mutex); g_active_ops--; uv_cond_broadcast(&g_teardown_cond); uv_mutex_unlock(&g_mutex);
+        napi_throw_error(env, NULL, "Failed to allocate engine record");
+        return NULL;
+    }
+    rec->handle = handle;
+    rec->owner = uv_thread_self();
+    rec->env = env;
+    uv_mutex_lock(&g_mutex); rec->next = g_bridges; g_bridges = rec; uv_mutex_unlock(&g_mutex);
+    // Round-11 (#1): register an env cleanup hook for EVERY engine, not just
+    // resolver-backed ones. Without it, a Worker that creates a resolver-less
+    // engine and exits without destroyEngine() would strand this record, the Java
+    // ScriptRuntime registry entry, and the native-lib reference -- leaking
+    // engines and blocking isolate teardown across Worker churn. bridge_env_cleanup
+    // + bridge_finalize already handle a resolver-less record (resolver_js == NULL):
+    // skip the napi_ref delete, still unlink, remove the registry entry (round-10
+    // do_registry_remove=true), and free. Round-13 (#5) moved ownership of the
+    // native-lib initialize() reference to the env itself (env_init_rec): this
+    // per-engine hook no longer touches g_ref_count -- the reference is released
+    // by the env-death hook env_init_cleanup (or by cleanup()), so an abandoned
+    // env releases exactly one reference regardless of how many engines it made.
+    // destroyEngine removes this hook before an early free so Node never invokes
+    // it on freed memory.
+    napi_status hook_st = napi_add_env_cleanup_hook(env, bridge_env_cleanup, rec);
+    if (hook_st != napi_ok) {
+        // Creation must be all-or-nothing (round-12 #6): without a cleanup hook a
+        // Worker that abandons this engine would strand the record and the Java
+        // registry entry. Unlink, remove the registry entry, free, and throw --
+        // no usable handle escapes. The record was just linked on this thread
+        // with in_flight==0 and its handle was never returned to JS, so no op
+        // can be in flight against it.
+        // Do NOT release the init reference here (fix round 1): this throw
+        // propagates to initialize()'s TS catch (dataweave.ts), which sees
+        // libRefAcquired==true and calls ffi.cleanup() -- that is the ONE
+        // release for this creation's ref, matching every sibling
+        // creation-failure path (invalid-handle guard, alloc failure) that also
+        // leaves the release to the TS catch. Releasing natively here too would
+        // double-decrement g_ref_count -- masked in a single-instance process
+        // (the guard no-ops a second release at 0) but a live UAF hazard with a
+        // second engine instance still holding a reference.
+        uv_mutex_lock(&g_mutex);
+        engine_bridge_t** pp = &g_bridges;
+        while (*pp != NULL) { if (*pp == rec) { *pp = rec->next; break; } pp = &(*pp)->next; }
+        uv_mutex_unlock(&g_mutex);
+        bridge_finalize_registry(rec);
+        bridge_finalize_free(rec, /*env_still_alive=*/true);
+        uv_mutex_lock(&g_mutex); g_active_ops--; uv_cond_broadcast(&g_teardown_cond); uv_mutex_unlock(&g_mutex);
+        napi_throw_error(env, NULL, "Failed to register engine cleanup hook");
         return NULL;
     }
 
-    size_t argc = 5;
-    napi_value args[5];
-    napi_get_cb_info(env, info, &argc, args, NULL, NULL);
+    napi_value out; napi_create_int64(env, (int64_t)handle, &out);
+    uv_mutex_lock(&g_mutex); g_active_ops--; uv_cond_broadcast(&g_teardown_cond); uv_mutex_unlock(&g_mutex);
+    return out;
+}
 
-    if (argc < 5) {
-        napi_throw_error(env, NULL, "Expected 5 arguments: script, inputs, mimeType, resolverCallback, isolate");
-        return NULL;
+// createEngineWithResolver(resolver) -> number
+static napi_value napi_create_engine_with_resolver(napi_env env, napi_callback_info info) {
+    if (!fn_create_engine_with_resolver) { napi_throw_error(env, NULL, "create_engine_with_resolver not available in native library"); return NULL; }
+    size_t argc = 1; napi_value argv[1];
+    napi_get_cb_info(env, info, &argc, argv, NULL, NULL);
+    if (argc < 1) { napi_throw_error(env, NULL, "createEngineWithResolver requires (resolverCallback)"); return NULL; }
+
+    engine_bridge_t* bridge = (engine_bridge_t*)calloc(1, sizeof(engine_bridge_t));
+    if (bridge == NULL) { napi_throw_error(env, NULL, "Failed to allocate engine bridge"); return NULL; }
+    if (napi_create_reference(env, argv[0], 1, &bridge->resolver_js) != napi_ok) {
+        free(bridge); napi_throw_error(env, NULL, "Failed to reference resolver callback"); return NULL;
     }
+    bridge->env = env; bridge->owner = uv_thread_self(); bridge->results = NULL;
 
-    // Extract script, inputs, mimeType
-    size_t script_len, inputs_len, mime_len;
-    napi_get_value_string_utf8(env, args[0], NULL, 0, &script_len);
-    napi_get_value_string_utf8(env, args[1], NULL, 0, &inputs_len);
-    napi_get_value_string_utf8(env, args[2], NULL, 0, &mime_len);
+    // Round-14 (#1): same admission block as napi_create_engine. Taken AFTER the
+    // bridge/resolver-ref allocation (those failures touch no isolate state and
+    // must not decrement a reservation not yet held) and BEFORE fn_attach_thread.
+    uv_mutex_lock(&g_mutex);
+    env_init_rec_t* self = env_init_rec_find_locked(env);
+    if (!g_initialized || g_isolate == NULL ||
+        g_teardown_state == TEARDOWN_TEARING_DOWN ||
+        self == NULL || self->init_refs == 0) {
+        uv_mutex_unlock(&g_mutex);
+        napi_delete_reference(env, bridge->resolver_js); free(bridge);
+        napi_throw_error(env, NULL, "Not initialized. Call initialize() first.");
+        return NULL;
+    }
+    g_active_ops++;  // pins the live isolate against teardown across the attach
+    uv_mutex_unlock(&g_mutex);
 
-    char* script = (char*)malloc(script_len + 1);
-    char* inputs = (char*)malloc(inputs_len + 1);
-    char* mime_type = (char*)malloc(mime_len + 1);
+    void* thread = NULL;
+    if (fn_attach_thread(g_isolate, &thread) != 0) {
+        uv_mutex_lock(&g_mutex); g_active_ops--; uv_cond_broadcast(&g_teardown_cond); uv_mutex_unlock(&g_mutex);
+        napi_delete_reference(env, bridge->resolver_js); free(bridge);
+        napi_throw_error(env, NULL, "Failed to attach thread"); return NULL;
+    }
+    long long handle = fn_create_engine_with_resolver(thread, resolve_module_callback, (void*)bridge);
+    fn_detach_thread(thread);
 
-    if (script == NULL || inputs == NULL || mime_type == NULL) {
-        free(script);
-        free(inputs);
-        free(mime_type);
-        napi_throw_error(env, NULL, "Failed to allocate memory for arguments");
+    // Same invalid-handle guard as napi_create_engine: a Java-side construction
+    // failure surfaces here as handle == 0 (GraalVM @CEntryPoint default-value
+    // semantics), and any handle <= 0 is never valid. Reject before this bridge
+    // is linked into g_bridges or a cleanup hook is registered for it — at this
+    // point neither has happened, so there's nothing to unlink/unhook. Still use
+    // bridge_finalize (not a manual napi_delete_reference+free) because the failed
+    // construction may have called resolve_module_callback (e.g. during eager
+    // module setup) before ultimately failing, which can have already populated
+    // bridge->results via resolver_results_track; bridge_finalize frees those
+    // tracked buffers too, so nothing is dropped on the floor.
+    if (handle <= 0) {
+        uv_mutex_lock(&g_mutex); g_active_ops--; uv_cond_broadcast(&g_teardown_cond); uv_mutex_unlock(&g_mutex);
+        // Synchronous call on the JS thread -- env is live here.
+        bridge_finalize(bridge, /*env_still_alive=*/true, /*do_registry_remove=*/false);
+        napi_throw_error(env, NULL, "create_engine_with_resolver returned an invalid handle");
         return NULL;
     }
 
-    napi_get_value_string_utf8(env, args[0], script, script_len + 1, NULL);
-    napi_get_value_string_utf8(env, args[1], inputs, inputs_len + 1, NULL);
-    napi_get_value_string_utf8(env, args[2], mime_type, mime_len + 1, NULL);
+    bridge->handle = handle;
+    uv_mutex_lock(&g_mutex); bridge->next = g_bridges; g_bridges = bridge; uv_mutex_unlock(&g_mutex);
+    // Register a per-env cleanup hook so THIS Worker/main thread disposes this
+    // bridge's napi_ref on its own thread when its env tears down (F2). napi_cleanup
+    // no longer touches bridge refs. destroyEngine removes this hook before an
+    // early free so Node never calls it on freed memory.
+    napi_status hook_st = napi_add_env_cleanup_hook(env, bridge_env_cleanup, bridge);
+    if (hook_st != napi_ok) {
+        // Creation must be all-or-nothing (round-12 #6): without a cleanup hook a
+        // Worker that abandons this engine would strand the record and the Java
+        // registry entry. Unlink, remove the registry entry, free, and throw --
+        // no usable handle escapes. The record was just linked on this thread
+        // with in_flight==0 and its handle was never returned to JS, so no op
+        // can be in flight against it.
+        // Do NOT release the init reference here (fix round 1): this throw
+        // propagates to initialize()'s TS catch (dataweave.ts), which sees
+        // libRefAcquired==true and calls ffi.cleanup() -- that is the ONE
+        // release for this creation's ref, matching every sibling
+        // creation-failure path (resolver invalid-handle guard uses
+        // bridge_finalize with do_registry_remove=false and also does NOT
+        // release) that also leaves the release to the TS catch. Releasing
+        // natively here too would double-decrement g_ref_count -- masked in a
+        // single-instance process (the guard no-ops a second release at 0) but
+        // a live UAF hazard with a second engine instance still holding a
+        // reference.
+        uv_mutex_lock(&g_mutex);
+        engine_bridge_t** pp = &g_bridges;
+        while (*pp != NULL) { if (*pp == bridge) { *pp = bridge->next; break; } pp = &(*pp)->next; }
+        uv_mutex_unlock(&g_mutex);
+        bridge_finalize_registry(bridge);
+        bridge_finalize_free(bridge, /*env_still_alive=*/true);
+        uv_mutex_lock(&g_mutex); g_active_ops--; uv_cond_broadcast(&g_teardown_cond); uv_mutex_unlock(&g_mutex);
+        napi_throw_error(env, NULL, "Failed to register engine cleanup hook");
+        return NULL;
+    }
+    napi_value out; napi_create_int64(env, (int64_t)handle, &out);
+    uv_mutex_lock(&g_mutex); g_active_ops--; uv_cond_broadcast(&g_teardown_cond); uv_mutex_unlock(&g_mutex);
+    return out;
+}
 
-    // Resolver is installed once per process lifetime. Subsequent calls with
-    // different resolver callbacks will reuse the first resolver, as enforced by
-    // ScriptRuntime.setResolver() on the native side (one resolver per engine).
-    //
-    // No thread-hop machinery is needed: fn_run_script_with_resolver() below
-    // runs on this very thread, so resolve_module_callback() (invoked from
-    // inside that call) can call directly back into JS via the stored
-    // napi_ref. See the comment on g_resolver_env for why napi_threadsafe_function
-    // must NOT be used here.
+// destroyEngine(handle) -> void
+static napi_value napi_destroy_engine(napi_env env, napi_callback_info info) {
+    if (!g_initialized) return NULL;
+    size_t argc = 1; napi_value argv[1];
+    napi_get_cb_info(env, info, &argc, argv, NULL, NULL);
+    if (argc < 1) { napi_throw_error(env, NULL, "destroyEngine requires (handle)"); return NULL; }
+    int64_t handle64;
+    if (napi_get_value_int64(env, argv[0], &handle64) != napi_ok) {
+        napi_throw_error(env, NULL, "destroyEngine: handle must be an integer");
+        return NULL;
+    }
+    long long handle = (long long)handle64;
+
+    // F2: a resolver-backed engine's bridge owns thread-affine N-API state --
+    // a napi_ref and an env cleanup hook, both created on the engine's owning
+    // JS thread. Deleting that ref (bridge_finalize) or removing that hook
+    // (napi_remove_env_cleanup_hook) from another Worker's thread is undefined
+    // behavior. Reject cross-thread destruction, mirroring the fail-closed
+    // owner check in resolve_module_callback; the owner env's cleanup hook
+    // disposes the bridge when that Worker tears down. We are on the owner
+    // thread past this point, so the env cannot be concurrently tearing down
+    // and the bridge stays stable between this check and the unlink below.
+    // Owner-thread guard: round-11 (#1) registers an env cleanup hook for EVERY
+    // engine (resolver-backed or not), so every record now carries env-affine
+    // N-API state -- napi_remove_env_cleanup_hook (called below before an early
+    // free) can only be invoked legally on the owner thread. The guard
+    // therefore fires for any record (owned != NULL), not just resolver-backed
+    // ones. bridge_finalize's napi_ref deletion stays resolver-gated
+    // (resolver_js != NULL && env != NULL) -- that part is unchanged.
     uv_mutex_lock(&g_mutex);
-    if (g_resolver_ref == NULL) {
-        napi_status status = napi_create_reference(env, args[3], 1, &g_resolver_ref);
-        if (status != napi_ok) {
+    engine_bridge_t* owned = bridge_find(handle);
+    if (owned != NULL) {
+        uv_thread_t self = uv_thread_self();
+        if (!uv_thread_equal(&self, &owned->owner)) {
             uv_mutex_unlock(&g_mutex);
-            free(script);
-            free(inputs);
-            free(mime_type);
-            napi_throw_error(env, NULL, "Failed to reference resolver callback");
+            napi_throw_error(env, NULL,
+                "destroyEngine must be called from the thread that created the engine");
             return NULL;
         }
-        g_resolver_env = env;
-        g_resolver_thread = uv_thread_self();
     }
-    // Note: subsequent calls reuse the first resolver for this process lifetime.
+
+    // Round-9 (#1): unlink the record and decide, under the lock, whether the
+    // registry removal (fn_destroy_engine) and the record free must be DEFERRED.
+    // If an op is in flight, its worker may not yet have called
+    // ScriptRuntime.get(handle) (the first statement of the Java entrypoint) --
+    // removing the registry entry now would make that lookup fail with
+    // "Unknown engine handle". So defer BOTH the registry removal and the free
+    // to the last op draining (bridge_end_op -> bridge_finalize with
+    // do_registry_remove=true), which runs on this same owner thread. When no op
+    // is in flight, remove the registry entry and finalize immediately, as
+    // before. Every engine now has a record, so `found` is non-NULL for both
+    // resolver-backed and resolver-less engines.
+    engine_bridge_t** pp = &g_bridges; engine_bridge_t* found = NULL;
+    while (*pp != NULL) { if ((*pp)->handle == handle) { found = *pp; *pp = found->next; break; } pp = &(*pp)->next; }
+    bool defer = false;
+    // deferred_registry_remove gates the deferred registry removal in
+    // bridge_end_op; set it together with destroy_pending here.
+    if (found != NULL && found->in_flight > 0) { found->destroy_pending = true; found->deferred_registry_remove = true; defer = true; }
     uv_mutex_unlock(&g_mutex);
 
-    // Need to attach thread for this call
-    void* thread = NULL;
-    int rc = fn_attach_thread(g_isolate, &thread);
-    if (rc != 0) {
-        free(script);
-        free(inputs);
-        free(mime_type);
-        napi_throw_error(env, NULL, "Failed to attach thread");
-        return NULL;
+    if (found != NULL) {
+        // Drop the env cleanup hook. Round-11 (#1): every engine now registers
+        // one at creation (napi_create_engine / napi_create_engine_with_resolver),
+        // so this removal must run unconditionally, not just for resolver-backed
+        // engines. Whether we finalize now or defer, the free happens explicitly,
+        // so Node must never invoke the hook on this (soon-to-be or already)
+        // freed record.
+        napi_remove_env_cleanup_hook(env, bridge_env_cleanup, found);
+        if (!defer) {
+            // Not in flight: remove the registry entry AND finalize now, on this
+            // owner thread (env live). do_registry_remove=true folds the
+            // fn_destroy_engine call into bridge_finalize so it happens exactly
+            // once regardless of path.
+            bridge_finalize(found, /*env_still_alive=*/true, /*do_registry_remove=*/true);
+        }
+        // else: the draining op's bridge_end_op -> bridge_finalize performs both
+        // the registry removal and the free (see Step 5).
+    } else {
+        // No record found (should not happen now that every engine has one, but
+        // stay robust to a double-destroy or an unknown handle): fall back to the
+        // pre-round-9 behavior of removing the registry entry directly.
+        if (fn_destroy_engine) {
+            void* thread = NULL;
+            if (fn_attach_thread(g_isolate, &thread) == 0) { fn_destroy_engine(thread, handle); fn_detach_thread(thread); }
+        }
     }
+    return NULL;
+}
 
-    // Call native with resolver callback. mime_type is accepted from JS for API
-    // symmetry but is not part of the native run_script_with_resolver signature
-    // (see run_script_with_resolver_fn typedef comment) — do not forward it.
-    char* result = fn_run_script_with_resolver(
-        thread,
-        script,
-        inputs,
-        resolve_module_callback
-    );
-
-    // Native has copied every resolver result returned during this call; free
-    // our copies now that it's done.
-    resolver_results_free_all();
-
-    // result (if non-NULL) is a GraalVM UnmanagedMemory.malloc'd buffer, like
-    // every other native result pointer in this file; it must be released via
-    // fn_free_cstring(), not libc free(), and while the isolate thread is
-    // still attached. Copy it to a libc-owned buffer first so we can build
-    // the JS string after detaching, matching the strdup + fn_free_cstring
-    // pattern used by run_script_thread_fn/streaming_thread_fn/transform_thread_fn.
-    char* result_copy = result ? strdup(result) : NULL;
-    if (result != NULL) {
-        fn_free_cstring(thread, result);
+// runScriptEngine(handle, script, inputsJson) -> string
+static napi_value napi_run_script_engine(napi_env env, napi_callback_info info) {
+    if (!g_initialized) { napi_throw_error(env, NULL, "Not initialized. Call initialize() first."); return NULL; }
+    if (!fn_run_script_engine) { napi_throw_error(env, NULL, "run_script_engine not available in native library"); return NULL; }
+    size_t argc = 3; napi_value argv[3];
+    napi_get_cb_info(env, info, &argc, argv, NULL, NULL);
+    if (argc < 3) { napi_throw_error(env, NULL, "runScriptEngine requires (handle, script, inputsJson)"); return NULL; }
+    int64_t handle64;
+    if (napi_get_value_int64(env, argv[0], &handle64) != napi_ok) {
+        napi_throw_error(env, NULL, "runScriptEngine: handle must be an integer");
+        return NULL;
     }
+    long long handle = (long long)handle64;
 
-    fn_detach_thread(thread);
+    size_t script_len, inputs_len;
+    if (napi_get_value_string_utf8(env, argv[1], NULL, 0, &script_len) != napi_ok) {
+        napi_throw_error(env, NULL, "runScriptEngine: script must be a string");
+        return NULL;
+    }
+    if (napi_get_value_string_utf8(env, argv[2], NULL, 0, &inputs_len) != napi_ok) {
+        napi_throw_error(env, NULL, "runScriptEngine: inputsJson must be a string");
+        return NULL;
+    }
+    char* script = (char*)malloc(script_len + 1);
+    char* inputs = (char*)malloc(inputs_len + 1);
+    if (script == NULL || inputs == NULL) { free(script); free(inputs); napi_throw_error(env, NULL, "OOM"); return NULL; }
+    if (napi_get_value_string_utf8(env, argv[1], script, script_len + 1, NULL) != napi_ok ||
+        napi_get_value_string_utf8(env, argv[2], inputs, inputs_len + 1, NULL) != napi_ok) {
+        free(script); free(inputs);
+        napi_throw_error(env, NULL, "runScriptEngine: failed to read script/inputsJson");
+        return NULL;
+    }
 
-    free(script);
-    free(inputs);
-    free(mime_type);
+    // Round-7 #1: reserve an active op across the isolate-touching window
+    // (attach -> run -> detach) so a concurrent Worker's last cleanup()
+    // (napi_cleanup Case 4) cannot observe g_active_ops == 0 and tear down
+    // g_isolate while this synchronous op is attaching to or executing in it.
+    // Reserve LATE (here, not at the top): the malloc/arg-extraction above do
+    // not touch the isolate, so the reservation only needs to span attach..
+    // detach -- giving exactly two unwind sites (attach-failure and normal
+    // completion) instead of also unwinding the OOM path. Rejecting on
+    // g_teardown_state != TEARDOWN_NONE also refuses to start once a teardown
+    // is queued/underway. run() is fully synchronous on the JS thread, so the
+    // reserve and release both happen inline (no worker thread). Admit an
+    // ADOPTED isolate: napi_initialize's adoption branch sets
+    // g_teardown_cancelled = true on a still-live PENDING_WAIT isolate but
+    // does not reset g_teardown_state (only the async waiter does), so a
+    // merely-cancelled teardown must not reject here -- otherwise a valid
+    // post-adoption op throws "Not initialized". A genuine (non-cancelled)
+    // PENDING_WAIT or a committed TEARING_DOWN still rejects.
+    uv_mutex_lock(&g_mutex);
+    if (!g_initialized || (g_teardown_state != TEARDOWN_NONE && !g_teardown_cancelled)) {
+      uv_mutex_unlock(&g_mutex);
+      free(script); free(inputs);
+      napi_throw_error(env, NULL, "Not initialized. Call initialize() first.");
+      return NULL;
+    }
+    g_active_ops++;
+    // Round-11 (#3): pin the engine in the same critical section as the
+    // g_active_ops reservation so a concurrent destroyEngine cannot free the
+    // resolver bridge (still held by Java as the resolver ctx) while this
+    // synchronous op attaches to Graal or runs. NULL for a resolver-less/unknown
+    // handle -- bridge_end_op no-ops on NULL. Released in the attach-failure and
+    // completion paths below, alongside g_active_ops.
+    engine_bridge_t* bridge = bridge_begin_op_locked(handle);
+    uv_mutex_unlock(&g_mutex);
 
-    if (result_copy == NULL) {
-        napi_throw_error(env, NULL, "Script execution failed");
-        return NULL;
+    void* thread = NULL;
+    if (fn_attach_thread(g_isolate, &thread) != 0) {
+      bridge_end_op(bridge, /*env_still_alive=*/true);
+      uv_mutex_lock(&g_mutex); g_active_ops--; uv_cond_broadcast(&g_teardown_cond); uv_mutex_unlock(&g_mutex);
+      free(script); free(inputs);
+      napi_throw_error(env, NULL, "Failed to attach thread");
+      return NULL;
     }
 
-    napi_value result_str;
-    napi_create_string_utf8(env, result_copy, NAPI_AUTO_LENGTH, &result_str);
-    free(result_copy);
+    char* result = (char*)fn_run_script_engine(thread, handle, script, inputs);
 
-    return result_str;
+    // The pin taken at admission kept this record alive across the run, so no
+    // second lookup is needed. resolver_results_free_all is a no-op for a
+    // resolver-less/unknown engine (bridge == NULL).
+    if (bridge != NULL) resolver_results_free_all(bridge);
+
+    char* result_copy = result ? strdup(result) : NULL;
+    if (result != NULL) fn_free_cstring(thread, result);
+    fn_detach_thread(thread);
+    free(script); free(inputs);
+
+    // Round-11 (#3): release the per-engine pin (may finalize a destroy that a
+    // concurrent Worker deferred while this op held in_flight > 0), then release
+    // the global op reservation. env is live on this JS thread, so env_still_alive
+    // is true. Order: bridge_end_op before the g_active_ops release, mirroring
+    // streaming/transform completion.
+    bridge_end_op(bridge, /*env_still_alive=*/true);
+    uv_mutex_lock(&g_mutex); g_active_ops--; uv_cond_broadcast(&g_teardown_cond); uv_mutex_unlock(&g_mutex);
+
+    napi_value out;
+    if (result_copy) { napi_create_string_utf8(env, result_copy, NAPI_AUTO_LENGTH, &out); free(result_copy); }
+    else { napi_create_string_utf8(env, "", 0, &out); }
+    return out;
 }
 
 // --- Cleanup (must run on a separate thread to avoid V8 signal handler conflict) ---
 
+// Called on each waiter's own env/thread (via its own napi_threadsafe_function)
+// once the waiter thread has finished isolate teardown. Resolves that specific
+// caller's promise, then releases its tsfn and frees the node. `data` is
+// unused (NULL) -- there is nothing to report beyond "done".
+//
+// napi_call_threadsafe_function(..., napi_tsfn_blocking) only ENQUEUES this
+// callback for the target env's event loop to run later; it does not wait for
+// it to actually execute. So the waiter node and its tsfn must stay alive
+// until this callback runs and must be released/freed HERE, not by the
+// thread that enqueued the call (teardown_waiter_thread_fn) -- freeing there
+// right after the enqueueing call would be a use-after-free once this
+// callback later dereferences `context`. Same ownership pattern as
+// call_js_write/call_js_transform_write freeing their own work struct from
+// inside their own completion branch.
+static void call_js_teardown_done(napi_env env, napi_value js_callback, void* context, void* data) {
+  (void)js_callback;
+  (void)data;
+  teardown_waiter_t* waiter = (teardown_waiter_t*)context;
+  if (waiter == NULL) return;
+
+  if (env != NULL) {
+    napi_value undefined;
+    napi_get_undefined(env, &undefined);
+    napi_resolve_deferred(env, waiter->deferred, undefined);
+  }
+
+  napi_release_threadsafe_function(waiter->tsfn, napi_tsfn_release);
+  free(waiter);
+}
+
+// `arg` is an int* out-param: the caller (napi_cleanup's case 4) must set it
+// to 0 before spawning this thread and read it after uv_thread_join returns.
+// Mirrors teardown_waiter_thread_fn's `torn_down` local exactly, so the
+// caller can tell "isolate torn down / nothing to tear down" (safe to clear
+// g_thread/g_isolate/g_initialized/g_ref_count) apart from "attach failed,
+// isolate still alive" (must leave those globals set, or the isolate becomes
+// unreachable and can never be torn down).
 static void cleanup_thread_fn(void* arg) {
-  (void)arg;
+  int* out_torn_down = (int*)arg;
   // graal_tear_down_isolate() must be passed the IsolateThread belonging to the
   // *calling* OS thread. g_thread was created by graal_create_isolate() on the
   // (now-exited, already-joined) init thread, so it is invalid here — passing it
@@ -986,49 +2329,515 @@ static void cleanup_thread_fn(void* arg) {
   // StackOverflowError during teardown. Attach this cleanup thread to the isolate
   // to obtain a valid local IsolateThread, then tear down with that.
   if (!fn_tear_down_isolate || !fn_attach_thread || !g_isolate) {
+    // Nothing to tear down (no isolate / FFI unavailable) -- safe to clear.
+    *out_torn_down = 1;
     return;
   }
   void* local_thread = NULL;
   if (fn_attach_thread(g_isolate, &local_thread) != 0 || local_thread == NULL) {
+    // Attach failed -- the isolate is still alive. Leave *out_torn_down at 0
+    // (its caller-initialized value) so the caller does NOT clear g_isolate,
+    // or it becomes unreachable and can never be torn down.
     return;
   }
-  fn_tear_down_isolate(local_thread);
+  // Check the teardown return code (0 == success). On nonzero the isolate is
+  // still live: leave *out_torn_down at 0 so the caller retains
+  // g_isolate/g_initialized/g_ref_count and (per its own logic) arms the retry,
+  // rather than orphaning a live isolate (review #6 #3).
+  *out_torn_down = (fn_tear_down_isolate(local_thread) == 0) ? 1 : 0;
 }
 
-static napi_value napi_cleanup(napi_env env, napi_callback_info info) {
+// Spawned only when napi_cleanup finds g_active_ops > 0 on the last release
+// (case 5 in the design doc). Blocks until every active streaming/transform
+// op has drained, performs isolate teardown exactly like cleanup_thread_fn
+// does on the unchanged fast path, then resolves every caller who is waiting
+// on this same teardown (there may be more than one -- see g_teardown_waiters).
+static void teardown_waiter_thread_fn(void* arg) {
+  (void)arg;
+
   uv_mutex_lock(&g_mutex);
-  if (g_initialized) {
-    g_ref_count--;
-    if (g_ref_count <= 0) {
-      // Clean up resolver reference
-      if (g_resolver_ref != NULL && g_resolver_env != NULL) {
-        napi_delete_reference(g_resolver_env, g_resolver_ref);
-      }
-      g_resolver_ref = NULL;
-      g_resolver_env = NULL;
-      resolver_results_free_all();
-
-      uv_thread_t tid;
-      uv_thread_options_t opts;
-      opts.flags = UV_THREAD_HAS_STACK_SIZE;
-      opts.stack_size = 2 * 1024 * 1024;
-      uv_thread_create_ex(&tid, &opts, cleanup_thread_fn, NULL);
+  while (g_active_ops > 0 && !g_teardown_cancelled) {
+    uv_cond_wait(&g_teardown_cond, &g_mutex);
+  }
+  bool cancelled = g_teardown_cancelled;
+  if (!cancelled) {
+    // Point of no return: from here an adopting initialize() must NOT reuse the
+    // isolate, so publish TEARING_DOWN under the lock before we drop it to call
+    // graal_tear_down_isolate().
+    g_teardown_state = TEARDOWN_TEARING_DOWN;
+  }
+  uv_mutex_unlock(&g_mutex);
+
+  // Perform teardown exactly as the unchanged fast path does: attach a local
+  // thread to the isolate (g_thread from graal_create_isolate's bootstrap
+  // thread is invalid here -- see cleanup_thread_fn's comment), then tear
+  // down. Honor the return code (0 == success); a nonzero teardown leaves the
+  // isolate live (review #6 #3). Skipped entirely
+  // when an initialize() call adopted the live isolate instead (see
+  // napi_initialize's TEARDOWN_PENDING_WAIT branch).
+  bool torn_down = false;
+  if (!cancelled && fn_tear_down_isolate && fn_attach_thread && g_isolate) {
+    void* local_thread = NULL;
+    if (fn_attach_thread(g_isolate, &local_thread) == 0 && local_thread != NULL) {
+      // Check the teardown return code (0 == success). On nonzero the isolate is
+      // still live -- leave torn_down false so the post-teardown block below
+      // retains the isolate globals and arms the retry (review #6 #3).
+      torn_down = (fn_tear_down_isolate(local_thread) == 0);
+    }
+    // else: attach failed -- the isolate is still alive. Do NOT clear g_isolate,
+    // or it becomes unreachable and can never be torn down.
+  } else if (!cancelled) {
+    // Nothing to tear down (no isolate / FFI unavailable) -- safe to clear.
+    torn_down = true;
+  }
+  // if (cancelled): leave torn_down = false -- the isolate stays live for the
+  // adopter; we tear nothing down.
+
+  uv_mutex_lock(&g_mutex);
+  if (!cancelled && torn_down) {
+    g_thread = NULL;
+    g_isolate = NULL;
+    g_initialized = 0;
+    g_ref_count = 0;
+  } else if (!cancelled && g_isolate != NULL && g_ref_count == 0) {
+    // Teardown did not happen (attach failed, or graal_tear_down_isolate
+    // returned nonzero -- review #6 #3) and this async-waiter path IS the last
+    // release: g_ref_count is already 0 with no owner and no pending waiter.
+    // Arm the retry signal so a later op-completion drain or a fresh
+    // initialize() retries teardown -- otherwise the live isolate is stranded
+    // with nothing to reclaim it (review #6 #4). Mirrors the twin arm in
+    // isolate_ref_release_n_locked's waiter-spawn-failure path.
+    g_teardown_needed = true;
+  }
+  // If cancelled: g_isolate/g_initialized/g_ref_count are left exactly as the
+  // adopting initialize() set them (it already did g_ref_count++ on the live
+  // isolate).
+  g_teardown_state = TEARDOWN_NONE;
+  g_teardown_cancelled = false;
+  // Release any initialize() call blocked waiting for teardown to finish
+  // (see Task 3).
+  uv_cond_broadcast(&g_teardown_cond);
+  teardown_waiter_t* waiters = g_teardown_waiters;
+  g_teardown_waiters = NULL;
+  uv_mutex_unlock(&g_mutex);
+
+  // Resolve every waiting caller's promise on its own env/thread via its own
+  // tsfn -- napi_deferred/napi_env are thread-affine, so this cannot be done
+  // from this waiter thread directly. napi_call_threadsafe_function only
+  // ENQUEUES the call for the target thread to run later; it does not wait
+  // for call_js_teardown_done to execute. So do NOT free/release here --
+  // call_js_teardown_done owns and releases each node after it actually runs
+  // (freeing it here instead would be a use-after-free the moment the
+  // enqueued callback later dereferences it).
+  while (waiters != NULL) {
+    teardown_waiter_t* next = waiters->next;
+    napi_status enq = napi_call_threadsafe_function(waiters->tsfn, waiters, napi_tsfn_blocking);
+    if (enq != napi_ok) {
+      // The waiter's env is tearing down (napi_closing): call_js_teardown_done
+      // will never run, so it can neither resolve waiter->deferred nor release
+      // the tsfn nor free the node. Free the node here instead of leaking it
+      // (one leak per Worker that terminated while this teardown was pending).
+      // Do NOT napi_release_threadsafe_function(waiters->tsfn, ...): a
+      // napi_closing return already discharges this tsfn's registration (Node
+      // may have destroyed the tsfn object), so a release would be a
+      // double-discharge/UAF -- same reasoning as the sentinel-enqueue-failure
+      // paths in streaming_thread_fn/transform_thread_fn. The unresolved
+      // deferred is env-affine and reclaimed when the dead env is destroyed.
+      free(waiters);
+    }
+    waiters = next;
+  }
+}
+
+// Creates a promise, a threadsafe function bound to call_js_teardown_done for
+// THIS call's env, and a teardown_waiter_t node carrying both. The node is
+// NOT linked into g_teardown_waiters here -- the caller does that under
+// g_mutex, since callers append at two different points in napi_cleanup
+// (case 3: joining an existing pending teardown; case 5: starting a new one).
+// Returns NULL (and throws) if node allocation fails.
+static teardown_waiter_t* teardown_waiter_create(napi_env env, napi_value* out_promise) {
+  teardown_waiter_t* waiter = (teardown_waiter_t*)calloc(1, sizeof(teardown_waiter_t));
+  if (waiter == NULL) {
+    napi_throw_error(env, NULL, "Failed to allocate teardown waiter");
+    return NULL;
+  }
+  waiter->env = env;
+
+  if (napi_create_promise(env, &waiter->deferred, out_promise) != napi_ok) {
+    free(waiter);
+    napi_throw_error(env, NULL, "Failed to create teardown promise");
+    return NULL;
+  }
+
+  napi_value resource_name;
+  if (napi_create_string_utf8(env, "dwTeardown", NAPI_AUTO_LENGTH, &resource_name) != napi_ok) {
+    free(waiter);
+    napi_throw_error(env, NULL, "Failed to create teardown resource name");
+    return NULL;
+  }
+
+  if (napi_create_threadsafe_function(
+        env, NULL, NULL, resource_name, 0, 1, NULL, NULL, waiter, call_js_teardown_done, &waiter->tsfn
+      ) != napi_ok) {
+    free(waiter);
+    napi_throw_error(env, NULL, "Failed to create teardown threadsafe function");
+    return NULL;
+  }
+
+  return waiter;
+}
+
+// Creates an already-resolved promise -- used by napi_cleanup's two
+// "nothing to wait for" branches (not-the-last-release, and last-release
+// with no active ops) so the function's return type is uniformly "a
+// promise" regardless of which branch runs.
+static napi_value already_resolved_promise(napi_env env) {
+  napi_deferred deferred;
+  napi_value promise;
+  napi_create_promise(env, &deferred, &promise);
+  napi_value undefined;
+  napi_get_undefined(env, &undefined);
+  napi_resolve_deferred(env, deferred, undefined);
+  return promise;
+}
+
+// Release n (>=0) initialization references at once, then make the teardown
+// decision AT MOST ONCE. Caller holds g_mutex and this KEEPS it held. n==0 is a
+// no-op. Equivalent to n serial single-releases for the COUNT, but guarantees
+// the reached-zero teardown/waiter logic runs exactly once (a serial loop would
+// re-enter the decision on an already-zero count). Used by env_init_cleanup
+// (round-13 #5) to release all of a dead env's references from one decision
+// point. (Previously also used by a single-release wrapper,
+// isolate_ref_release_core_locked, retired in round-13 #5 once the per-engine
+// finalize path stopped releasing init references directly.)
+// Round-14 (#2/#3): retry a teardown that a prior last-release could not carry
+// out. Caller holds g_mutex and this KEEPS it held. No-op unless a stranded
+// live isolate is waiting (g_teardown_needed) with no owners and no teardown in
+// progress and ops drained. Makes the reached-zero teardown decision at most
+// once per call (same synchronous cleanup_thread_fn path as Case 4); on repeated
+// failure it leaves g_teardown_needed set to retry on the next drain. Spawns+joins
+// cleanup_thread_fn while holding g_mutex, exactly as the Case-4 /
+// isolate_ref_release_n_locked g_active_ops==0 branch does; cleanup_thread_fn
+// takes no lock and makes no napi call, so this is deadlock-free and thread-safe
+// from any drain site.
+static void retry_stranded_teardown_locked(void) {
+  if (!g_teardown_needed) return;
+  if (g_ref_count > 0) { g_teardown_needed = false; return; }  // adopted -> keep
+  if (g_teardown_state != TEARDOWN_NONE) return;               // a teardown drives
+  if (g_active_ops > 0) return;                                // wait for drain
+  if (g_isolate == NULL) { g_teardown_needed = false; return; } // nothing to do
+  uv_thread_t tid;
+  uv_thread_options_t opts;
+  opts.flags = UV_THREAD_HAS_STACK_SIZE;
+  opts.stack_size = 2 * 1024 * 1024;
+  int torn_down = 0;
+  int spawn_rc = uv_thread_create_ex(&tid, &opts, cleanup_thread_fn, &torn_down);
+  if (spawn_rc == 0) uv_thread_join(&tid);
+  if (torn_down) {
+    g_thread = NULL;
+    g_isolate = NULL;
+    g_initialized = 0;
+    g_ref_count = 0;
+    g_teardown_needed = false;
+  }
+  // else: spawn/attach failed again -- leave g_teardown_needed set so the next
+  // drain (or a later initialize() adoption) retries.
+}
+
+static void isolate_ref_release_n_locked(int n) {
+  if (n <= 0) return;
+  if (g_ref_count >= n) g_ref_count -= n; else g_ref_count = 0;
+  if (g_ref_count > 0) return;              // other envs still hold references
+  if (g_teardown_state != TEARDOWN_NONE) return;  // a teardown already drives
+
+  if (g_active_ops == 0) {
+    uv_thread_t tid;
+    uv_thread_options_t opts;
+    opts.flags = UV_THREAD_HAS_STACK_SIZE;
+    opts.stack_size = 2 * 1024 * 1024;
+    int torn_down = 0;
+    int spawn_rc = uv_thread_create_ex(&tid, &opts, cleanup_thread_fn, &torn_down);
+    if (spawn_rc == 0) {
       uv_thread_join(&tid);
+    }
+    if (torn_down) {
+      g_thread = NULL;
+      g_isolate = NULL;
+      g_initialized = 0;
+      g_ref_count = 0;
+    } else if (g_isolate != NULL && g_ref_count == 0) {
+      // Sync teardown failed (spawn or cleanup_thread_fn attach) with the isolate
+      // still live and no owners: arm the retry signal (round-14 #3). g_active_ops
+      // is already 0 here, but a later op could still re-pin; the flag is cleared
+      // on adoption and retried on drain or by the next initialize() (review #6
+      // #5). Documented residual: if NO later op or initialize() ever occurs, the
+      // isolate lingers until process exit, where the OS reclaims it -- benign
+      // (single process-lifetime isolate, no ref-count violation).
+      g_teardown_needed = true;
+    }
+    return;
+  }
+
+  // g_active_ops > 0: defer to the waiter thread, no promises attached.
+  g_teardown_state = TEARDOWN_PENDING_WAIT;
+  g_teardown_cancelled = false;
+  g_teardown_waiters = NULL;  // no JS caller waiting
+  uv_thread_t waiter_tid;
+  uv_thread_options_t waiter_opts;
+  waiter_opts.flags = UV_THREAD_HAS_STACK_SIZE;
+  waiter_opts.stack_size = 2 * 1024 * 1024;
+  int spawn_rc = uv_thread_create_ex(&waiter_tid, &waiter_opts, teardown_waiter_thread_fn, NULL);
+  if (spawn_rc != 0) {
+    // Best-effort degradation: the waiter thread never started, so nothing will
+    // drain the isolate. Restore g_ref_count to the true remaining ownership
+    // (Σ init_refs, = 0 here) to keep the invariant, and ARM the retry signal so
+    // the next op-completion drain retries teardown -- otherwise this live
+    // isolate has zero owners and nothing would ever tear it down (round-14 #3).
+    g_teardown_state = TEARDOWN_NONE;
+    g_ref_count = env_init_refs_total_locked();
+    if (g_isolate != NULL && g_ref_count == 0) g_teardown_needed = true;
+  }
+}
+
+// Env-death hook for a per-env init record (round-13 #5). Registered once per
+// env by initialize()'s first acquire (env_init_acquire_and_hook). Node runs
+// env-cleanup hooks LIFO. In the normal initialize()-then-createEngine() order
+// this hook is registered BEFORE any engine's bridge_env_cleanup for the same
+// env, so it runs AFTER every engine bridge has finalized on a live isolate.
+// The pathological raw-ffi order (createEngine() on this env -- succeeding
+// because another env already initialized -- THEN initialize() here) can
+// register this hook after an engine hook, so it may run first; that is still
+// safe, because bridge_finalize_registry re-checks teardown state under g_mutex
+// (registry removal no-ops on a torn-down isolate) and the napi_ref delete runs
+// with env_still_alive=true on this env's own live thread. Releases exactly the
+// references this env still holds (n), from a single env-scoped decision point:
+// because g_ref_count == sum of init_refs, releasing this env's n reaches zero
+// ONLY if no other env holds a reference, so an abandoned env can never tear the
+// isolate down under a live env. Runs on the dying env's own thread with the
+// env alive; does only g_mutex-guarded integer/list work + free (no env-affine
+// napi calls).
+// Round-14 (#1): the create path now enforces per-env ownership (an env with
+// init_refs == 0 is rejected), so the pathological order below -- createEngine()
+// on this env BEFORE its own initialize() -- is now rejected at the create call
+// rather than relying on the finalize-time teardown-state re-check.
+static void env_init_cleanup(void* arg) {
+    env_init_rec_t* rec = (env_init_rec_t*)arg;
+    if (rec == NULL) return;
+    uv_mutex_lock(&g_mutex);
+    // Unlink from g_env_recs if still present.
+    env_init_rec_t** pp = &g_env_recs;
+    while (*pp != NULL) {
+        if (*pp == rec) { *pp = rec->next; break; }
+        pp = &(*pp)->next;
+    }
+    int n = rec->init_refs;
+    rec->init_refs = 0;
+    free(rec);
+    // Release all n references and make the teardown decision at most once.
+    isolate_ref_release_n_locked(n);
+    uv_mutex_unlock(&g_mutex);
+}
+
+// Promise-less core of an isolate-reference release. Caller holds g_mutex and
+// this function KEEPS it held (does not unlock). Decrements g_ref_count and, on
+// the last release, drives teardown WITHOUT binding any napi promise/waiter:
+//   - g_active_ops == 0 -> synchronous cleanup_thread_fn (same as Case 4).
+//   - g_active_ops  > 0 -> spawn the waiter thread with an EMPTY waiter list
+//                          (TEARDOWN_PENDING_WAIT); it tears down (or is adopted)
+//                          with no promises to resolve.
+//   - a teardown already pending (TEARDOWN_NONE != state) -> nothing to do; the
+//                          existing waiter will tear down; this release just
+//                          drops the count.
+// Used by env_init_cleanup (round-13 #5), the env-death hook, which has no
+// live JS caller to hand a promise to.
+//
+// Deliberately does NOT call (or get called by) release_isolate_ref_locked
+// below: that promise-bearing sibling needs per-caller promise plumbing this
+// core omits on purpose (binding a waiter/promise to a tearing-down env is a
+// thread-affinity hazard). They share the last-release *policy* only; see
+// release_isolate_ref_locked's header comment for the promise-bearing twin.
+//
+// The isolate reference is now owned per env (env_init_rec), not per engine
+// bridge (round-13 #5): initialize()'s acquire sites and env_init_cleanup are
+// the only callers that mutate g_ref_count via this function, alongside
+// release_isolate_ref_locked below for the explicit cleanup() path. The
+// per-engine finalize path (bridge_env_cleanup / bridge_end_op) no longer
+// touches g_ref_count at all, so a raw multi-engine-per-initialize() caller's
+// abandoned env fires exactly one release for the whole balance it holds,
+// regardless of how many engines it created.
+
+// Releases ONE initialization reference on the shared isolate. Caller MUST
+// hold g_mutex; this function UNLOCKS g_mutex before returning (the sync and
+// waiter teardown paths both require dropping the lock). Returns the napi
+// promise to hand back to the JS caller. This is napi_cleanup's original
+// Case 1..5 body.
+static napi_value release_isolate_ref_locked(napi_env env) {
+  // Case 1/2: not the last release (or nothing was ever initialized). Decrement
+  // only if positive -- a second cleanup() call while g_ref_count is already at
+  // 0 (e.g. one already dropped it while teardown is pending) must not go
+  // negative.
+  // Round-13 (#5): an env may release only a reference IT owns. If this env has
+  // no outstanding init reference (a cleanup() with no matching initialize() on
+  // this env, or a double-cleanup()), do NOT touch g_ref_count -- releasing here
+  // would steal another env's reference and could tear the isolate down under a
+  // live user. No-op: resolve immediately. (g_ref_count == sum of init_refs, so
+  // this env's zero balance means it contributes nothing to release.)
+  env_init_rec_t* self = env_init_rec_find_locked(env);
+  if (self == NULL || self->init_refs == 0) {
+    uv_mutex_unlock(&g_mutex);
+    return already_resolved_promise(env);
+  }
+  self->init_refs--;
+  if (g_ref_count > 0) {
+    g_ref_count--;
+  }
+  if (g_ref_count > 0) {
+    uv_mutex_unlock(&g_mutex);
+    return already_resolved_promise(env);
+  }
 
+  // Case 3: a teardown from an earlier cleanup() call is already pending
+  // (possibly triggered from a different Worker/env). Join its waiter list
+  // instead of spawning a second waiter thread.
+  if (g_teardown_state != TEARDOWN_NONE) {
+    napi_value promise;
+    teardown_waiter_t* waiter = teardown_waiter_create(env, &promise);
+    if (waiter == NULL) {
+      uv_mutex_unlock(&g_mutex);
+      return NULL;  // teardown_waiter_create already threw
+    }
+    waiter->next = g_teardown_waiters;
+    g_teardown_waiters = waiter;
+    uv_mutex_unlock(&g_mutex);
+    return promise;
+  }
+
+  // Case 4: last release, no teardown pending, and nothing active -- the
+  // original, unchanged synchronous fast path.
+  if (g_active_ops == 0) {
+    uv_thread_t tid;
+    uv_thread_options_t opts;
+    opts.flags = UV_THREAD_HAS_STACK_SIZE;
+    opts.stack_size = 2 * 1024 * 1024;
+    // torn_down is cleanup_thread_fn's out-param (mirrors teardown_waiter_thread_fn's
+    // `torn_down` local exactly): must be initialized to 0 before the thread runs so
+    // the attach-failure early-return path (which never touches it) leaves it false.
+    // uv_thread_join is synchronous, so when spawn_rc == 0 this stack variable safely
+    // outlives the thread's write to it.
+    int torn_down = 0;
+    int spawn_rc = uv_thread_create_ex(&tid, &opts, cleanup_thread_fn, &torn_down);
+    if (spawn_rc == 0) {
+      uv_thread_join(&tid);
+    }
+    // Only clear global state if the isolate was actually torn down (or there
+    // was nothing to tear down). If spawn failed, the thread never ran and
+    // torn_down stays 0 -- leave the globals set rather than orphaning a live
+    // isolate (unreachable via these globals, could never be torn down), which
+    // is a strict improvement over unconditionally clearing them here. Same
+    // reasoning for cleanup_thread_fn's internal attach-failure path: the
+    // isolate is still alive, g_initialized stays 1, and g_ref_count was
+    // already decremented to 0 above without being reset here, so a later
+    // initialize() correctly ref-counts the surviving isolate instead of
+    // building a second one (identical semantics to teardown_waiter_thread_fn's
+    // attach-failure path).
+    if (torn_down) {
       g_thread = NULL;
       g_isolate = NULL;
       g_initialized = 0;
       g_ref_count = 0;
+    } else if (g_isolate != NULL && g_ref_count == 0) {
+      // cleanup_thread_fn spawn/attach failed: the isolate is still live with
+      // zero owners. Arm the retry signal so a later op-completion drain or the
+      // next initialize() (review #6 #5) tears it down instead of stranding it —
+      // mirrors the twin arm in isolate_ref_release_n_locked. Documented residual:
+      // if no later op or initialize() ever runs, the isolate lingers to process
+      // exit (OS reclaims it) -- benign, no ref-count violation.
+      g_teardown_needed = true;
     }
+    uv_mutex_unlock(&g_mutex);
+    return already_resolved_promise(env);
   }
+
+  // Case 5: last release, but streaming/transform ops are still active.
+  // Defer teardown to a dedicated waiter thread instead of blocking this JS
+  // thread -- this is the deadlock fix. g_initialized/g_isolate/g_thread stay
+  // set until the waiter thread finishes, matching today's behavior of
+  // treating "still tearing down" as "still initialized" for concurrent
+  // initialize() calls (see Task 3).
+  g_teardown_state = TEARDOWN_PENDING_WAIT;
+  g_teardown_cancelled = false;
+  napi_value promise;
+  teardown_waiter_t* waiter = teardown_waiter_create(env, &promise);
+  if (waiter == NULL) {
+    // The last reference was already dropped (g_ref_count == 0) but we cannot
+    // build the waiter to drain the isolate. Arm the retry signal so the op
+    // drain retries teardown -- without it this live isolate would have zero
+    // owners and nothing to tear it down (round-14 #2).
+    g_teardown_state = TEARDOWN_NONE;
+    if (g_isolate != NULL && g_ref_count == 0) g_teardown_needed = true;
+    uv_mutex_unlock(&g_mutex);
+    return NULL;  // teardown_waiter_create already threw
+  }
+  waiter->next = NULL;
+  g_teardown_waiters = waiter;
+
+  uv_thread_t waiter_tid;
+  uv_thread_options_t waiter_opts;
+  waiter_opts.flags = UV_THREAD_HAS_STACK_SIZE;
+  waiter_opts.stack_size = 2 * 1024 * 1024;
+  int spawn_rc = uv_thread_create_ex(&waiter_tid, &waiter_opts, teardown_waiter_thread_fn, NULL);
+  // Deliberately not joined -- this thread finishes on its own and resolves
+  // every waiter's promise itself; joining here would reintroduce exactly
+  // the blocking-JS-thread problem this fix removes.
+
+  if (spawn_rc != 0) {
+    // Best-effort degradation: if the waiter thread never starts, nothing
+    // will ever clear g_teardown_state, which would otherwise permanently
+    // wedge every future initialize()/cleanup() call. Roll back to "teardown
+    // did not start" -- the isolate stays up and the caller's promise still
+    // resolves, mirroring the fast path's ignore-teardown-return-code posture.
+    g_teardown_state = TEARDOWN_NONE;
+    g_teardown_waiters = NULL;
+
+    napi_value undefined;
+    napi_get_undefined(env, &undefined);
+    napi_resolve_deferred(env, waiter->deferred, undefined);
+
+    napi_release_threadsafe_function(waiter->tsfn, napi_tsfn_release);
+    free(waiter);
+
+    // Best-effort degradation: the isolate stays live (g_initialized/g_isolate
+    // untouched) but no waiter will drain it. Restore g_ref_count to the true
+    // remaining ownership (Σ init_refs) rather than a hardcoded 1: this env just
+    // decremented its own init_refs above, and reaching Case 5 means g_ref_count
+    // hit 0, so the sum is 0 (or whatever surviving envs still own). Hardcoding 1
+    // here would strand a reference no env owns -- unreleasable by any cleanup()
+    // or env-death hook -- and would break the invariant g_ref_count == Σ
+    // init_refs. A later initialize() will re-acquire on the surviving isolate.
+    g_ref_count = env_init_refs_total_locked();
+    // Arm the retry signal: the isolate stays live with no owners and no waiter,
+    // so the op-completion drain must retry teardown (round-14 #2).
+    if (g_isolate != NULL && g_ref_count == 0) g_teardown_needed = true;
+
+    uv_mutex_unlock(&g_mutex);
+    return promise;
+  }
+
   uv_mutex_unlock(&g_mutex);
-  return NULL;
+  return promise;
+}
+
+static napi_value napi_cleanup(napi_env env, napi_callback_info info) {
+  (void)info;
+  uv_mutex_lock(&g_mutex);
+  return release_isolate_ref_locked(env);  // unlocks g_mutex, returns the promise
 }
 
 // --- Module init ---
 
 static void init_g_mutex(void) {
   uv_mutex_init(&g_mutex);
+  uv_cond_init(&g_teardown_cond);
 }
 
 static napi_value Init(napi_env env, napi_value exports) {
@@ -1042,14 +2851,23 @@ static napi_value Init(napi_env env, napi_value exports) {
   napi_create_function(env, "runScript", NAPI_AUTO_LENGTH, dw_napi_run_script, NULL, &fn);
   napi_set_named_property(env, exports, "runScript", fn);
 
-  napi_create_function(env, "runScriptStreaming", NAPI_AUTO_LENGTH, napi_run_script_streaming, NULL, &fn);
-  napi_set_named_property(env, exports, "runScriptStreaming", fn);
+  napi_create_function(env, "createEngine", NAPI_AUTO_LENGTH, napi_create_engine, NULL, &fn);
+  napi_set_named_property(env, exports, "createEngine", fn);
+
+  napi_create_function(env, "createEngineWithResolver", NAPI_AUTO_LENGTH, napi_create_engine_with_resolver, NULL, &fn);
+  napi_set_named_property(env, exports, "createEngineWithResolver", fn);
+
+  napi_create_function(env, "destroyEngine", NAPI_AUTO_LENGTH, napi_destroy_engine, NULL, &fn);
+  napi_set_named_property(env, exports, "destroyEngine", fn);
+
+  napi_create_function(env, "runScriptEngine", NAPI_AUTO_LENGTH, napi_run_script_engine, NULL, &fn);
+  napi_set_named_property(env, exports, "runScriptEngine", fn);
 
-  napi_create_function(env, "runScriptTransform", NAPI_AUTO_LENGTH, napi_run_script_transform, NULL, &fn);
-  napi_set_named_property(env, exports, "runScriptTransform", fn);
+  napi_create_function(env, "runScriptStreamingEngine", NAPI_AUTO_LENGTH, napi_run_script_streaming_engine, NULL, &fn);
+  napi_set_named_property(env, exports, "runScriptStreamingEngine", fn);
 
-  napi_create_function(env, "runWithResolver", NAPI_AUTO_LENGTH, napi_run_with_resolver, NULL, &fn);
-  napi_set_named_property(env, exports, "runWithResolver", fn);
+  napi_create_function(env, "runScriptTransformEngine", NAPI_AUTO_LENGTH, napi_run_script_transform_engine, NULL, &fn);
+  napi_set_named_property(env, exports, "runScriptTransformEngine", fn);
 
   napi_create_function(env, "cleanup", NAPI_AUTO_LENGTH, napi_cleanup, NULL, &fn);
   napi_set_named_property(env, exports, "cleanup", fn);
diff --git a/native-lib/node/src/dataweave.ts b/native-lib/node/src/dataweave.ts
index dbaa63a3..1d9024a9 100644
--- a/native-lib/node/src/dataweave.ts
+++ b/native-lib/node/src/dataweave.ts
@@ -23,23 +23,10 @@ export interface DataWeaveOptions {
    *
    * MUST be synchronous (cannot return Promise).
    *
-   * Note: the native layer installs at most one resolver per process
-   * lifetime, bound on the first resolver-backed {@link DataWeave.run} call
-   * (not on {@link DataWeave.initialize}, which only loads/ref-counts the
-   * native library) and to the thread (main thread or `worker_threads`
-   * Worker) that made that first call. If you construct multiple `DataWeave`
-   * instances with different `resolveModule` callbacks in the same process,
-   * whichever instance's `run()` executes first wins; later instances
-   * silently reuse that resolver instead of their own. If a later instance's
-   * `run()` executes on a *different* thread, its resolver is not invoked at
-   * all and custom module paths resolve as "not found" (see
-   * docs/external-modules.md#multiple-resolvers-in-one-process).
-   *
-   * Concurrency warning: calling a resolver-backed `run()` concurrently from
-   * more than one Worker is not just unsupported — it is memory-unsafe (see
-   * docs/external-modules.md, Worker threads section). Restrict
-   * resolver-backed execution to a single thread, or serialize calls across
-   * Workers.
+   * Each DataWeave instance owns an independent native engine, so multiple
+   * instances with different resolvers coexist in one process with no
+   * cross-talk. Streaming/transform still resolve only built-in modules for a
+   * resolver-backed engine (custom modules fail closed); see external-modules.md.
    *
    * Security: the resolver runs with full process permissions and no
    * sandboxing (same trust model as the CLI resolving `.dwl` files from
@@ -61,7 +48,9 @@ export interface DataWeaveOptions {
 export class DataWeave {
   private readonly libPath: string;
   private readonly resolveModule?: ModuleResolver;
-  private initialized = false;
+  private state: "uninitialized" | "ready" | "cleaning-up" = "uninitialized";
+  private engineHandle: number | null = null;
+  private cleanupPromise: Promise<void> | null = null;
 
   /**
    * @param options - Configuration options or a legacy libPath string.
@@ -83,25 +72,106 @@ export class DataWeave {
    * initialized.
    *
    * @throws DataWeaveError if the native library fails to load or initialize.
+   * @throws DataWeaveError if called while a `cleanup()` is still in progress
+   *   — await the cleanup first.
    */
   initialize(): void {
-    if (this.initialized) return;
+    if (this.state === "ready") return;
+    if (this.state === "cleaning-up") {
+      throw new DataWeaveError(
+        "Cannot initialize while cleanup is in progress; await cleanup() first."
+      );
+    }
+    let libRefAcquired = false;
     try {
       ffi.initialize(this.libPath);
+      libRefAcquired = true;
+      this.engineHandle = this.resolveModule
+        ? ffi.createEngineWithResolver(this.resolveModule)
+        : ffi.createEngine();
     } catch (e: unknown) {
+      // If ffi.initialize() already succeeded but engine creation then threw,
+      // we already hold an increment of the native library's ref-counted
+      // handle. this.state stays "uninitialized" below (we're about to throw),
+      // so cleanup()'s early-return guard (`if (this.state !== "ready") return;`)
+      // means nothing else will ever call ffi.cleanup() for this instance --
+      // release the ref-count ourselves here or it leaks for the process
+      // lifetime.
+      if (libRefAcquired) {
+        ffi.cleanup();
+      }
+      this.engineHandle = null;
       throw new DataWeaveError(`Failed to initialize: ${e instanceof Error ? e.message : e}`);
     }
-    this.initialized = true;
+    this.state = "ready";
   }
 
   /**
    * Releases the native runtime. Idempotent — a no-op if not initialized. After
    * cleanup the instance can be re-initialized via {@link DataWeave.initialize}.
+   *
+   * Resolves once the underlying native isolate has actually finished tearing
+   * down. If a streaming/transform operation on this or any other instance is
+   * still in flight when the last reference is released, native teardown
+   * waits for it to drain before resolving — awaiting this rather than
+   * firing-and-forgetting avoids racing a subsequent {@link initialize} against
+   * an isolate that is still tearing down.
    */
-  cleanup(): void {
-    if (!this.initialized) return;
-    ffi.cleanup();
-    this.initialized = false;
+  async cleanup(): Promise<void> {
+    // Coalesce first: doCleanup() flips `state` to "cleaning-up" synchronously
+    // as its first statement, so by the time a second overlapping call runs,
+    // `state` has already left "ready". If the not-ready guard below ran
+    // first, that second caller would resolve immediately instead of
+    // awaiting the first caller's in-flight native teardown -- contradicting
+    // this method's contract of resolving only once the isolate has actually
+    // finished tearing down (round-6 review, task-1 fix round 1). Checking
+    // `cleanupPromise` first ensures every concurrent caller that overlaps
+    // with an in-flight doCleanup() awaits that SAME promise, so the native
+    // teardown (ffi.destroyEngine/ffi.cleanup) still happens exactly once.
+    if (this.cleanupPromise) return this.cleanupPromise;
+    // Not coalescing with an in-flight cleanup: nothing to do unless we're
+    // "ready" (covers both never-initialized and already-settled cleanup).
+    if (this.state !== "ready") return;
+    this.cleanupPromise = this.doCleanup();
+    try {
+      await this.cleanupPromise;
+    } finally {
+      // Clear on both fulfilment and rejection so a later cleanup() (after a
+      // re-initialize, or a retry of a rejected cleanup) can run again.
+      this.cleanupPromise = null;
+    }
+  }
+
+  private async doCleanup(): Promise<void> {
+    // Transition BEFORE releasing the engine so run()/initialize() called
+    // during the async teardown window are rejected deterministically rather
+    // than seeing a stale "ready" state with a null engineHandle (round-6 #1/#3).
+    this.state = "cleaning-up";
+    let destroyError: unknown;
+    try {
+      if (this.engineHandle !== null) {
+        try {
+          ffi.destroyEngine(this.engineHandle);
+        } catch (e) {
+          // Round-14 (#6): a throwing destroyEngine() (e.g. wrong-thread
+          // destruction) must NOT skip ffi.cleanup() -- that would strand this
+          // env's native init reference and block isolate teardown. Capture the
+          // primary error, clear the handle so a retry does not double-destroy,
+          // and fall through to release the reference below.
+          destroyError = e;
+        } finally {
+          this.engineHandle = null;
+        }
+      }
+      await ffi.cleanup();
+    } finally {
+      this.state = "uninitialized";
+    }
+    // Surface the primary destruction error after the reference was released. If
+    // ffi.cleanup() itself rejected, its error already propagated from the await
+    // (the more actionable reference-release failure wins; the destroy error is
+    // then suppressed).
+    if (destroyError !== undefined) throw destroyError;
   }
 
   /**
@@ -116,17 +186,10 @@ export class DataWeave {
    * @throws DataWeaveScriptError if the script fails and `opts.raiseOnError` is set.
    */
   run(script: string, inputs?: Inputs, opts?: { raiseOnError?: boolean }): ExecutionResult {
-    this.ensureInitialized();
+    this.ensureReady();
     const inputsJson = buildInputsJson(inputs ?? {});
 
-    let raw: string;
-    if (this.resolveModule) {
-      // Use resolver-aware entrypoint
-      raw = ffi.runWithResolver(script, inputsJson, "application/json", this.resolveModule);
-    } else {
-      // Use standard entrypoint (backward compatible)
-      raw = ffi.runScript(script, inputsJson);
-    }
+    const raw = ffi.runScriptEngine(this.engineHandle!, script, inputsJson);
 
     const result = parseNativeResponse(raw);
 
@@ -148,9 +211,11 @@ export class DataWeave {
    * @throws DataWeaveError if the runtime is not initialized.
    */
   async *runStreaming(script: string, inputs?: Inputs): AsyncGenerator<Buffer, StreamingResult, undefined> {
-    this.ensureInitialized();
+    this.ensureReady();
     const inputsJson = buildInputsJson(inputs ?? {});
-    return yield* streamFromNative((chunkCb) => ffi.runScriptStreaming(script, inputsJson, chunkCb));
+    return yield* streamFromNative((chunkCb) =>
+      ffi.runScriptStreamingEngine(this.engineHandle!, script, inputsJson, chunkCb)
+    );
   }
 
   /**
@@ -174,7 +239,7 @@ export class DataWeave {
     input: AsyncIterable<Buffer | Uint8Array> | Iterable<Buffer | Uint8Array>,
     opts?: TransformOptions
   ): AsyncGenerator<Buffer, StreamingResult, undefined> {
-    this.ensureInitialized();
+    this.ensureReady();
 
     const inputName = opts?.inputName ?? "payload";
     const inputMimeType = opts?.mimeType ?? "application/json";
@@ -184,30 +249,132 @@ export class DataWeave {
 
     const readCb = await createChunkReader(input);
 
+    // The instance may have been cleaned up while an async input pre-buffered
+    // (createChunkReader can await arbitrarily long). Re-check readiness so a
+    // caller that raced cleanup() gets a synchronous DataWeaveError rather than
+    // a resolved "Unknown engine handle" envelope. The C admission pin is the
+    // authoritative memory-safety guard (round 11 #2/#3); this only improves the
+    // failure ergonomics for a misused instance. (round 12 #4)
+    this.ensureReady();
+
     return yield* streamFromNative((writeCb) =>
-      ffi.runScriptTransform(script, inputsJson, inputName, inputMimeType, inputCharset, readCb, writeCb)
+      ffi.runScriptTransformEngine(
+        this.engineHandle!,
+        script,
+        inputsJson,
+        inputName,
+        inputMimeType,
+        inputCharset,
+        readCb,
+        writeCb
+      )
     );
   }
 
-  private ensureInitialized(): void {
-    if (!this.initialized) {
-      throw new DataWeaveError("DataWeave runtime not initialized. Call initialize() first.");
+  private ensureReady(): void {
+    if (this.state === "ready") return;
+    if (this.state === "cleaning-up") {
+      throw new DataWeaveError(
+        "DataWeave runtime is cleaning up; await cleanup() before running again."
+      );
     }
+    throw new DataWeaveError("DataWeave runtime not initialized. Call initialize() first.");
   }
 }
 
 // Module-level convenience API with lazy singleton
 let globalInstance: DataWeave | null = null;
+// Guards against beforeExit and exit both driving cleanup for the same
+// shutdown. Belt-and-suspenders on top of cleanup()'s own idempotency.
+let cleanupStarted = false;
+// Coalesces overlapping module-level cleanup() calls, mirroring the
+// instance-level DataWeave.cleanupPromise. Without it, the second of two
+// overlapping module cleanup() calls sees globalInstance already nulled and
+// resolves immediately -- before the first call's native teardown finishes,
+// violating cleanup()'s "resolves once native teardown has finished" contract
+// for the last reference. (round 12 #5)
+let cleanupPromise: Promise<void> | null = null;
+// The instance that `cleanupPromise` is currently draining. Needed because
+// coalescing must NOT be keyed on the module-global promise alone: if a
+// caller revives the singleton (via run()/getGlobalInstance()) while a prior
+// drain is still in flight, a subsequent cleanup() must clean the freshly
+// revived instance rather than returning the stale promise as if it had
+// covered it too -- otherwise the revived instance's native ref is silently
+// leaked (final-review round 12 #1, fixing round 12 Task 6's regression).
+let cleaningInstance: DataWeave | null = null;
+// Process exit hooks are registered exactly once for the lifetime of the
+// module, NOT per singleton. Re-creating the singleton after cleanup() must
+// not attach a second pair of listeners (that accumulates until Node emits
+// MaxListenersExceededWarning). The listeners tolerate a null globalInstance:
+// cleanup() no-ops when there is nothing to release, and cleanupStarted
+// coalesces beforeExit/exit for a given shutdown. Unlike cleanupStarted, this
+// guard is never reset — that is the whole point.
+let exitHooksRegistered = false;
+
+/**
+ * Registers the process-wide exit-cleanup hooks exactly once for this
+ * module. Subsequent calls (e.g. from a revived singleton after cleanup())
+ * are no-ops: the hooks registered on first use are reused for the rest of
+ * the process's lifetime, which is safe because they tolerate a null
+ * `globalInstance` and `cleanupStarted` coalesces beforeExit/exit for a
+ * given shutdown.
+ *
+ * Two hooks are registered, covering complementary cases:
+ * - `beforeExit` fires when the event loop is about to drain naturally and
+ *   CAN run async work (Node keeps the loop alive until it settles), so it
+ *   drains any in-flight streaming/transform operation gracefully. This is
+ *   the common case.
+ * - `exit` runs strictly synchronously and is only a best-effort fallback for
+ *   the paths that skip `beforeExit` — `process.exit()`, an uncaught
+ *   exception, and normal process termination. Because it is synchronous it
+ *   can only run the fast cleanup path, so an in-flight async operation may be
+ *   abandoned. Node does NOT emit `exit` (nor `beforeExit`) for termination
+ *   signals such as SIGTERM/SIGINT/SIGKILL, nor for every fatal failure mode,
+ *   so this is not a guarantee: callers that require graceful shutdown must
+ *   register and await their own handlers for the catchable signals (e.g.
+ *   `process.on("SIGTERM", async () => { await cleanup(); process.exit(0); })`);
+ *   SIGKILL cannot be caught, so no in-process cleanup can run for it.
+ * The `cleanupStarted` guard ensures only one of the two hooks actually
+ * runs cleanup for a given shutdown.
+ */
+function registerExitHooksOnce(): void {
+  if (exitHooksRegistered) return;
+  exitHooksRegistered = true;
+  process.on("beforeExit", async () => {
+    if (cleanupStarted) return;
+    cleanupStarted = true;
+    await cleanup(); // beforeExit can await: drains in-flight ops
+  });
+  process.on("exit", () => {
+    if (cleanupStarted) return; // beforeExit already handled it
+    cleanup(); // fallback: best-effort sync fast path
+  });
+}
 
 /**
  * Returns the process-wide {@link DataWeave} singleton, creating and
- * initializing it (and registering a process-exit cleanup hook) on first use.
+ * initializing it on first use (or after a prior {@link cleanup}).
+ *
+ * The exit-cleanup hooks are registered exactly once for the process via
+ * {@link registerExitHooksOnce}, not once per singleton: a singleton revived
+ * after cleanup() reuses the same pair of listeners rather than adding new
+ * ones, which would otherwise accumulate a pair per init/cleanup cycle until
+ * Node emits `MaxListenersExceededWarning`. Reuse is safe because the
+ * listeners tolerate a null `globalInstance` and `cleanupStarted` coalesces
+ * beforeExit/exit for a given shutdown.
  */
 function getGlobalInstance(): DataWeave {
   if (!globalInstance) {
-    globalInstance = new DataWeave();
-    globalInstance.initialize();
-    process.on("exit", () => cleanup());
+    // Initialize a LOCAL candidate first; publish the singleton only after
+    // initialize() succeeds. A failed first init (bad DATAWEAVE_NATIVE_LIB
+    // path / transient native failure) must NOT leave a poisoned, uninitialized
+    // singleton that makes every later run*() fail "not initialized" even after
+    // the fault is fixed (review #6 #1). On throw, globalInstance stays null and
+    // the next call retries cleanly with a fresh instance.
+    const candidate = new DataWeave();
+    candidate.initialize();
+    globalInstance = candidate;
+    registerExitHooksOnce();
   }
   return globalInstance;
 }
@@ -247,9 +414,50 @@ export function runTransform(
  * Releases the shared {@link DataWeave} singleton, if one was created. A fresh
  * singleton is created lazily on the next convenience-API call.
  */
-export function cleanup(): void {
-  if (globalInstance) {
-    globalInstance.cleanup();
-    globalInstance = null;
+export async function cleanup(): Promise<void> {
+  // Coalesce overlapping calls onto one drain (round 12 #5) -- but ONLY when
+  // nothing new has been revived since that drain started. If `globalInstance`
+  // is still the same instance the in-flight promise is draining, or is null
+  // (nobody has revived since), it's safe to piggyback on the existing
+  // promise. If a DIFFERENT instance is now the singleton (a caller called
+  // run() and revived it while the old drain was still in flight), that new
+  // instance has never been handed to a cleanup() call -- returning the old
+  // promise here would resolve as if it had been cleaned when it hasn't,
+  // leaking its native ref for the rest of the process (final-review round 12
+  // #1). Fall through and drain the current instance instead.
+  if (cleanupPromise && (globalInstance === null || globalInstance === cleaningInstance)) {
+    return cleanupPromise;
   }
-}
\ No newline at end of file
+  if (!globalInstance) return;
+  const instance = globalInstance;
+  globalInstance = null;
+  // Chosen semantics for overlapping different-instance drains: coalescing
+  // tracks only the MOST RECENT drain. An older drain that is still in flight
+  // when a newer one starts is not stomped -- it keeps running against its own
+  // promise, which whoever started it already holds and will await -- but it
+  // stops being the thing later cleanup() calls coalesce onto. Two distinct
+  // instances tearing down concurrently is fine: each owns its own engine
+  // handle and native ref, exactly like two DataWeave instances calling
+  // .cleanup() independently. This keeps the invariant that matters: no
+  // cleanup() call ever returns as if it drained an instance it didn't.
+  cleaningInstance = instance;
+  cleanupPromise = instance.cleanup();
+  try {
+    await cleanupPromise;
+  } finally {
+    // Only clear the shared coalescing state if it's still ours to clear --
+    // i.e. nobody has started a newer drain (for a newer revived instance)
+    // that has since taken over `cleanupPromise`/`cleaningInstance`. Guards
+    // against this drain's finally clobbering a later drain's in-flight state.
+    if (cleaningInstance === instance) {
+      cleanupPromise = null;
+      cleaningInstance = null;
+    }
+    // Reset the exit-hook guard only after THIS drain has fully completed, so
+    // a revived singleton gets its own live hooks for the next real exit.
+    // Must stay last: resetting earlier could let a concurrent `exit` firing
+    // on this same shutdown re-enter cleanup while the async drain above is
+    // in flight.
+    cleanupStarted = false;
+  }
+}
diff --git a/native-lib/node/src/ffi.ts b/native-lib/node/src/ffi.ts
index 924de436..24711ea0 100644
--- a/native-lib/node/src/ffi.ts
+++ b/native-lib/node/src/ffi.ts
@@ -4,8 +4,18 @@ import type { ModuleResolver } from "./resolver";
 interface NativeAddon {
   initialize(libPath: string): void;
   runScript(script: string, inputsJson: string): string;
-  runScriptStreaming(script: string, inputsJson: string, chunkCb: (chunk: Buffer) => void): Promise<string>;
-  runScriptTransform(
+  createEngine(): number;
+  createEngineWithResolver(resolver: ModuleResolver): number;
+  destroyEngine(handle: number): void;
+  runScriptEngine(handle: number, script: string, inputsJson: string): string;
+  runScriptStreamingEngine(
+    handle: number,
+    script: string,
+    inputsJson: string,
+    chunkCb: (chunk: Buffer) => void
+  ): Promise<string>;
+  runScriptTransformEngine(
+    handle: number,
     script: string,
     inputsJson: string,
     inputName: string,
@@ -14,14 +24,7 @@ interface NativeAddon {
     readCb: (bufSize: number) => Buffer | null,
     writeCb: (chunk: Buffer) => void
   ): Promise<string>;
-  runWithResolver(
-    script: string,
-    inputsJson: string,
-    mimeType: string,
-    resolverCallback: ModuleResolver,
-    isolate: null
-  ): string;
-  cleanup(): void;
+  cleanup(): Promise<void>;
 }
 
 let addon: NativeAddon | null = null;
@@ -42,15 +45,33 @@ export function runScript(script: string, inputsJson: string): string {
   return getAddon().runScript(script, inputsJson);
 }
 
-export function runScriptStreaming(
+export function createEngine(): number {
+  return getAddon().createEngine();
+}
+
+export function createEngineWithResolver(resolver: ModuleResolver): number {
+  return getAddon().createEngineWithResolver(resolver);
+}
+
+export function destroyEngine(handle: number): void {
+  getAddon().destroyEngine(handle);
+}
+
+export function runScriptEngine(handle: number, script: string, inputsJson: string): string {
+  return getAddon().runScriptEngine(handle, script, inputsJson);
+}
+
+export function runScriptStreamingEngine(
+  handle: number,
   script: string,
   inputsJson: string,
   chunkCb: (chunk: Buffer) => void
 ): Promise<string> {
-  return getAddon().runScriptStreaming(script, inputsJson, chunkCb);
+  return getAddon().runScriptStreamingEngine(handle, script, inputsJson, chunkCb);
 }
 
-export function runScriptTransform(
+export function runScriptTransformEngine(
+  handle: number,
   script: string,
   inputsJson: string,
   inputName: string,
@@ -59,18 +80,18 @@ export function runScriptTransform(
   readCb: (bufSize: number) => Buffer | null,
   writeCb: (chunk: Buffer) => void
 ): Promise<string> {
-  return getAddon().runScriptTransform(script, inputsJson, inputName, inputMimeType, inputCharset, readCb, writeCb);
-}
-
-export function runWithResolver(
-  script: string,
-  inputsJson: string,
-  mimeType: string,
-  resolverCallback: ModuleResolver
-): string {
-  return getAddon().runWithResolver(script, inputsJson, mimeType, resolverCallback, null);
+  return getAddon().runScriptTransformEngine(
+    handle,
+    script,
+    inputsJson,
+    inputName,
+    inputMimeType,
+    inputCharset,
+    readCb,
+    writeCb
+  );
 }
 
-export function cleanup(): void {
-  getAddon().cleanup();
+export function cleanup(): Promise<void> {
+  return getAddon().cleanup();
 }
diff --git a/native-lib/node/src/stream.ts b/native-lib/node/src/stream.ts
index 855807f6..5f4dadaa 100644
--- a/native-lib/node/src/stream.ts
+++ b/native-lib/node/src/stream.ts
@@ -36,15 +36,25 @@ export async function* streamFromNative(
     }
   };
 
-  const metaPromise = start(chunkCb).then((raw) => {
-    metaRaw = raw;
-    done = true;
-    // Wake all waiting consumers
+  let startError: unknown;
+  const wakeAll = () => {
     while (pendingResolves.length > 0) {
       const resolve = pendingResolves.shift();
       if (resolve) resolve();
     }
-  });
+  };
+
+  // Handle BOTH settlement branches. Without the rejection handler, a rejected
+  // start() leaves `done` false forever: a consumer parked in next() below is
+  // never woken and the generator hangs, and the rejection is unhandled
+  // (review #6 #2). On rejection we record the error, mark completion, and wake
+  // every waiter; the error is re-thrown after draining any chunks that arrived
+  // before the rejection. Because we handle rejection here, metaPromise itself
+  // always fulfills -- `await metaPromise` below never throws.
+  const metaPromise = start(chunkCb).then(
+    (raw) => { metaRaw = raw; done = true; wakeAll(); },
+    (err) => { startError = err; done = true; wakeAll(); }
+  );
 
   while (true) {
     if (chunks.length > 0) {
@@ -55,11 +65,12 @@ export async function* streamFromNative(
     await new Promise<void>((resolve) => { pendingResolves.push(resolve); });
   }
 
-  // Drain remaining chunks
+  // Drain remaining chunks buffered before completion/rejection.
   while (chunks.length > 0) {
     yield chunks.shift()!;
   }
 
   await metaPromise;
+  if (startError !== undefined) throw startError;
   return parseStreamingResult(metaRaw ?? "");
 }
\ No newline at end of file
diff --git a/native-lib/node/tests/integration/admission-during-teardown.test.ts b/native-lib/node/tests/integration/admission-during-teardown.test.ts
new file mode 100644
index 00000000..a87b7f18
--- /dev/null
+++ b/native-lib/node/tests/integration/admission-during-teardown.test.ts
@@ -0,0 +1,136 @@
+import { describe, it, expect } from "vitest";
+import * as ffi from "../../src/ffi";
+import { findLibrary, buildInputsJson } from "../../src/utils";
+
+// Round-6 finding #2: napi_run_script_streaming_engine/napi_run_script_transform_engine
+// used to read g_initialized outside g_mutex, then reserve g_active_ops in a
+// LATER, separate critical section right before spawning the worker thread --
+// with no reference to g_teardown_state at all. The fix folds the lifecycle
+// check (including g_teardown_state) and the g_active_ops reservation into one
+// atomic critical section, before any work/tsfn/promise/bridge is allocated,
+// and rejects admission once a teardown is queued/underway
+// (g_teardown_state != TEARDOWN_NONE), not just when the isolate is fully gone.
+//
+// Why this test drives the addon through the raw `ffi` module instead of the
+// module-level `run`/`runStreaming`/`runTransform`/`cleanup` singleton (as the
+// original brief sketch does): the module-level `cleanup()` nulls the
+// singleton, so a later module-level `runStreaming()`/`runTransform()` call
+// re-creates a fresh `DataWeave` instance and calls `initialize()` again.
+// `napi_initialize`'s TEARDOWN_PENDING_WAIT branch (round-5's deadlock fix)
+// treats that as a legitimate ADOPTION of the still-live isolate: it sets
+// g_teardown_cancelled = true and cancels the pending teardown *before* the
+// second op's admission check ever runs -- so by the time streaming/transform
+// admission is checked, g_teardown_state is already back to TEARDOWN_NONE
+// (verified empirically while developing this test: the brief's literal shape
+// resolves the second op cleanly on both pre-fix and post-fix code, so it
+// cannot distinguish them -- it never reaches the vulnerable window because
+// the intervening initialize() call cancels the teardown as a side effect).
+//
+// To actually observe admission-during-pending-teardown, the second op must
+// run against the SAME still-live handle/isolate WITHOUT any intervening
+// ffi.initialize() call. Calling `ffi.cleanup()` directly (skipping
+// `destroyEngine`) triggers exactly napi_cleanup's Case 5 (last ref release
+// with an active op) and sets g_teardown_state = TEARDOWN_PENDING_WAIT
+// synchronously, under g_mutex, before napi_cleanup returns its Promise to
+// JS -- with no adoption path involved, since nothing calls initialize()
+// afterward.
+//
+// Determinism: `ffi.cleanup()`'s synchronous prefix (native napi_cleanup body)
+// runs entirely synchronously up to the point where it returns a Promise; the
+// TEARDOWN_PENDING_WAIT transition happens on that same synchronous call, not
+// after an await. The immediately-following `ffi.runScriptStreamingEngine`
+// call re-enters native code synchronously (it's a plain N-API call), on the
+// very same JS callstack, so it deterministically observes
+// g_teardown_state == TEARDOWN_PENDING_WAIT with no timing assumptions --
+// mirroring the round-5 teardown-deadlock test's use of a synchronous native
+// read-callback to force deterministic ordering instead of timers.
+//
+// Real addon, no mocking.
+describe("admission rejected while teardown pending (round 6 #2)", () => {
+  it("a streaming op started on the same handle during pending teardown is rejected, not admitted", async () => {
+    ffi.initialize(findLibrary());
+    const handle = ffi.createEngine();
+
+    let cleanupPromise: Promise<void> | undefined;
+    let admitErr: unknown;
+    let admitted = false;
+    let secondOpSettled: Promise<void> = Promise.resolve();
+
+    let firstRead = true;
+    const readCb = (_bufSize: number): Buffer | null => {
+      if (firstRead) {
+        firstRead = false;
+
+        // Trigger Case 5 of napi_cleanup: last release of the shared library
+        // ref-count while this transform's worker is attached and
+        // g_active_ops > 0. Synchronously sets g_teardown_state =
+        // TEARDOWN_PENDING_WAIT before returning. Not awaited -- the point is
+        // to observe the state it leaves behind, not its eventual settlement.
+        cleanupPromise = ffi.cleanup();
+
+        // Attempt a second admission on the SAME still-live handle/isolate
+        // while teardown is pending. Fixed code rejects admission with a
+        // synchronous napi_throw_error (the atomic admission check sees
+        // g_teardown_state != TEARDOWN_NONE, before any promise is even
+        // created). Pre-fix code admits it: the unlocked g_initialized check
+        // passes (the isolate genuinely hasn't been torn down yet --
+        // TEARDOWN_PENDING_WAIT hasn't reached physical teardown) and
+        // g_active_ops is reserved without ever consulting g_teardown_state,
+        // so the call returns a promise that goes on to resolve successfully.
+        //
+        // On rejection, napi_throw_error fires synchronously from this very
+        // call (admission fails before any promise is created), so it must
+        // be caught here rather than only via a rejected-promise `.then` --
+        // mirroring the round-5 teardown-deadlock test's care not to let a
+        // thrown exception escape a native read-callback body (it would be
+        // reinterpreted as a read error, masking the real outcome).
+        try {
+          secondOpSettled = ffi
+            .runScriptStreamingEngine(
+              handle,
+              "%dw 2.0\noutput application/json\n---\n[1,2,3]",
+              buildInputsJson({}),
+              () => {}
+            )
+            .then(
+              () => { admitted = true; },
+              (e) => { admitErr = e; }
+            );
+        } catch (e) {
+          admitErr = e;
+        }
+
+        return Buffer.from("[1,2,3]");
+      }
+      return null; // EOF after the first chunk
+    };
+
+    const chunks: Buffer[] = [];
+    const writeCb = (chunk: Buffer) => { chunks.push(chunk); };
+
+    const resultRaw = await ffi.runScriptTransformEngine(
+      handle,
+      "output application/json\n---\npayload",
+      "{}",
+      "payload",
+      "application/json",
+      null,
+      readCb,
+      writeCb
+    );
+    const result = JSON.parse(resultRaw);
+    expect(result.success).toBe(true);
+
+    // Let the second op settle (whichever branch it took) before asserting,
+    // and drain the pending teardown so the shared native isolate is left in
+    // a clean, consistent state for sibling test files in this process.
+    await secondOpSettled;
+    await cleanupPromise;
+
+    // The second op admitted while teardown was pending must have been
+    // rejected, not silently admitted against an isolate a concurrent
+    // teardown could tear down out from under it.
+    expect(admitErr).toBeTruthy();
+    expect(admitted).toBe(false);
+  }, 20000);
+});
diff --git a/native-lib/node/tests/integration/dataweave-resolver.test.ts b/native-lib/node/tests/integration/dataweave-resolver.test.ts
index 6578bb6b..6f5b5eb0 100644
--- a/native-lib/node/tests/integration/dataweave-resolver.test.ts
+++ b/native-lib/node/tests/integration/dataweave-resolver.test.ts
@@ -1,15 +1,16 @@
 import { describe, it, expect, afterAll } from "vitest";
 import { DataWeave, cleanup } from '../../src/dataweave';
+import { DataWeaveError } from '../../src/errors';
 import { modulesFromMap } from '../../src/resolver';
 
 // Every test below constructs its own explicit DataWeave instance (rather
 // than the module-level singleton) so each can configure its own resolver.
 // `cleanup()` above only releases the *singleton* (`globalInstance`), which
 // nothing in this file ever creates -- so without this tracking, every
-// explicit instance's native library reference (and the shared addon-level
-// ref-count, see addon.c's g_ref_count) would leak for the lifetime of the
-// test process. Track every instance created in this file and release them
-// all in afterAll.
+// explicit instance's native library reference (and its own engine handle,
+// see addon.c's create_engine/destroy_engine) would leak for the lifetime of
+// the test process. Track every instance created in this file and release
+// them all in afterAll.
 const instances: DataWeave[] = [];
 function trackedDataWeave(...args: ConstructorParameters<typeof DataWeave>): DataWeave {
   const dw = new DataWeave(...args);
@@ -17,31 +18,19 @@ function trackedDataWeave(...args: ConstructorParameters<typeof DataWeave>): Dat
   return dw;
 }
 
-afterAll(() => {
+afterAll(async () => {
   for (const dw of instances) {
-    dw.cleanup();
+    await dw.cleanup();
   }
-  cleanup();
+  await cleanup();
 });
 
-// ScriptRuntime installs at most one resolver for the whole process lifetime
-// (see ScriptRuntime.setResolver()): whichever DataWeave instance's resolver
-// gets installed first "wins", and every later DataWeave instance in this
-// file — regardless of its own resolveModule map — silently reuses it. Since
-// vitest runs the `it` blocks in this file sequentially in the same process,
-// that's always this first module-map, so it must contain every module path
-// any test below needs to resolve for the first time (including the
-// cross-thread regression test's two never-before-resolved paths).
-const SHARED_RESOLVER_MODULES: Record<string, string> = {
-  'org/test/lib.dwl': '%dw 2.0\nfun greet(n: String) = "Hello " ++ n',
-  'org/test/resolverGuardInstall.dwl': '%dw 2.0\nfun greet(n: String) = "Hello " ++ n',
-  'org/test/resolverGuardStreamed.dwl': '%dw 2.0\nfun greet(n: String) = "Hello " ++ n',
-};
-
 describe('DataWeave with resolver', () => {
   it('resolves imported module from map', () => {
     const dw = trackedDataWeave({
-      resolveModule: modulesFromMap(SHARED_RESOLVER_MODULES),
+      resolveModule: modulesFromMap({
+        'org/test/lib.dwl': '%dw 2.0\nfun greet(n: String) = "Hello " ++ n',
+      }),
     });
     dw.initialize();
 
@@ -106,46 +95,27 @@ describe('DataWeave with resolver', () => {
     expect(JSON.parse(result.getString()!)).toBe("Hello");
   });
 
-  // Regression test for the cross-thread resolver hazard: ScriptRuntime's engine
-  // is a process-wide singleton, so once any .run() call installs a resolver on
-  // it, that same composite resolver is used by ALL later execution paths --
-  // including runStreaming()/runTransform(), whose native call executes on a
-  // background uv_thread (see addon.c's streaming_thread_fn), not the JS thread
-  // that registered the resolver. Before the thread-identity guard in addon.c's
-  // resolve_module_callback, a streamed script importing a non-built-in module
-  // would trigger a napi call from that background thread -- undefined behavior,
-  // typically a crash of the whole process. After the guard, the callback fails
-  // closed (reports "not found" instead of calling back into JS), so the script
-  // fails cleanly with a compile error and the process survives.
-  it('runStreaming fails cleanly (does not crash) for a custom module on the shared singleton engine', async () => {
-    // Once a module name has been resolved anywhere in the process, the
-    // DataWeave compiler caches it and won't call back into the resolver for
-    // that same name again — so the install script and the streaming script
-    // below import two module paths that no earlier test in this file has
-    // imported yet (both pre-registered in SHARED_RESOLVER_MODULES above,
-    // since only the first-installed resolver's map is ever consulted).
+  // Regression test for the cross-thread resolver hazard: each DataWeave
+  // instance now owns its own native engine (see engine_bridge_t in addon.c),
+  // but a resolver-backed engine's runStreaming()/runTransform() still
+  // executes the native call on a background uv_thread (see addon.c's
+  // streaming_thread_fn/transform_thread_fn), not the JS thread that created
+  // the engine and its resolver bridge. resolve_module_callback detects that
+  // thread-identity mismatch and fails closed (reports "not found" instead of
+  // calling back into JS) rather than making an unsafe cross-thread napi
+  // call, so the script fails cleanly with a compile error and the process
+  // survives.
+  it('runStreaming fails cleanly for a custom module on its own resolver-backed engine', async () => {
     const dw = trackedDataWeave({
-      resolveModule: modulesFromMap(SHARED_RESOLVER_MODULES),
+      resolveModule: modulesFromMap({
+        'org/test/resolverGuardStreamed.dwl': '%dw 2.0\nfun greet(n: String) = "Hello " ++ n',
+      }),
     });
     dw.initialize();
 
-    // Install (or confirm already-installed) resolver on the shared singleton
-    // engine via a synchronous run() call. Per ScriptRuntime.setResolver(), only
-    // the first resolver registered for the process is ever used, so this is
-    // safe to call even if an earlier test in this file already installed one.
-    const installResult = dw.run(`
-      %dw 2.0
-      import org::test::resolverGuardInstall
-      output application/json
-      ---
-      resolverGuardInstall::greet("Installer")
-    `);
-    expect(installResult.success).toBe(true);
-
-    // Now stream a script that imports a DIFFERENT non-built-in module, never
-    // resolved before in this process. The singleton engine's composite
-    // resolver (ClassLoader + Callback) will miss in the ClassLoader half (not
-    // a built-in) and fall through to the Callback half, invoking
+    // Stream a script that imports a non-built-in module. This engine's
+    // composite resolver (ClassLoader + Callback) misses in the ClassLoader
+    // half (not a built-in) and falls through to the Callback half, invoking
     // resolve_module_callback from runStreaming's background thread.
     const chunks: Buffer[] = [];
     const gen = dw.runStreaming(`
@@ -167,4 +137,333 @@ describe('DataWeave with resolver', () => {
     expect(metadata.error).toBeTruthy();
     expect(chunks.length).toBe(0);
   });
+
+  // resolve_module_callback in addon.c catches a JS exception thrown by the
+  // user-supplied resolver (napi_call_function returning napi_pending_exception),
+  // clears it via napi_get_and_clear_last_exception, logs a content-free
+  // diagnostic (see the DATAWEAVE_RESOLVER_DEBUG gating), and reports "not
+  // found" back to the DataWeave runtime -- rather than letting the pending
+  // exception leak into a later napi call or crash the process. This is a
+  // synchronous run() on the JS thread that created the bridge (the "owner"
+  // thread check in resolve_module_callback passes), so the callback is
+  // actually invoked, unlike the streaming/transform cross-thread case above.
+  it('throwing resolver makes run() fail cleanly instead of crashing the process', () => {
+    const dw = trackedDataWeave({
+      resolveModule: () => {
+        throw new Error('resolver blew up');
+      },
+    });
+    dw.initialize();
+
+    const result = dw.run(`
+      %dw 2.0
+      import org::test::throwingResolverLib
+      output application/json
+      ---
+      {}
+    `);
+
+    // The test itself completing (no uncaught exception / segfault) is the
+    // crash-check; we don't assert on the internal error message wording.
+    expect(result.success).toBe(false);
+  });
+
+  // Regression test for a resolver-backed engine's initialize -> cleanup ->
+  // initialize cycle. Unlike the resolver-less reinit test in
+  // edge-cases.test.ts, this exercises createEngineWithResolver's bridge
+  // (engine_bridge_t) lifecycle: cleanup() destroys the bridge and its engine
+  // handle, and the following initialize() must build a brand new bridge
+  // (new napi_ref on the resolver, new owner-thread record) that resolves
+  // custom modules again, not a stale or dangling one.
+  it('resolver-backed instance resolves a custom module again after initialize -> cleanup -> initialize', async () => {
+    const dw = trackedDataWeave({
+      resolveModule: modulesFromMap({
+        'org/test/reinitLib.dwl': '%dw 2.0\nfun greet(n: String) = "Hello " ++ n',
+      }),
+    });
+    dw.initialize();
+    await dw.cleanup();
+    dw.initialize();
+
+    const result = dw.run(`
+      %dw 2.0
+      import org::test::reinitLib
+      output application/json
+      ---
+      reinitLib::greet("Reinit")
+    `);
+
+    expect(result.success).toBe(true);
+    expect(JSON.parse(result.getString()!)).toBe("Hello Reinit");
+  });
+
+  // Regression test for the F1 use-after-free fix: a resolver-backed engine's
+  // engine_bridge_t used to be freed by destroy_engine (called from cleanup())
+  // even while a background uv_thread (streaming_thread_fn) was still
+  // mid-flight and could call resolve_module_callback with that bridge as
+  // ctx -- a use-after-free. The fix adds in-flight accounting under g_mutex:
+  // destroy_engine now defers the actual free until the background operation
+  // decrements in_flight back to zero in its completion sentinel.
+  //
+  // To race cleanup() against the in-flight operation deterministically, we
+  // start the generator's *first* `.next()` call but do not await it before
+  // calling cleanup(). Calling an async generator's .next() runs its body
+  // synchronously up to the first suspension point (an `await`); by that
+  // point runStreaming's synchronous prefix -- including the native
+  // runScriptStreamingEngine call that hands the operation to a libuv
+  // worker-pool thread -- has already executed. cleanup() is then called
+  // from the JS thread while that native call may already be running
+  // concurrently on the worker thread, which is exactly the race the F1 fix
+  // guards against. Before that fix this was a real crash/UAF risk; after it,
+  // this must complete cleanly (settle, not crash, not hang) regardless of
+  // which side of the race wins.
+  it('cleanup() racing an in-flight resolver-backed runStreaming() does not crash (F1 regression)', async () => {
+    const dw = trackedDataWeave({
+      resolveModule: modulesFromMap({
+        'org/test/cleanupDuringStream.dwl': '%dw 2.0\nfun greet(n: String) = "Hello " ++ n',
+      }),
+    });
+    dw.initialize();
+
+    const gen = dw.runStreaming(`
+      %dw 2.0
+      import org::test::cleanupDuringStream
+      output application/json
+      ---
+      cleanupDuringStream::greet("Streaming")
+    `);
+
+    // Start the native call without awaiting it, then immediately race
+    // cleanup() against it.
+    const firstNext = gen.next();
+    dw.cleanup();
+
+    // The outcome (a settled chunk, the terminal metadata, or a rejection)
+    // doesn't matter -- what matters is that it settles instead of crashing
+    // the process or hanging, and that no unhandled rejection escapes this
+    // test. We explicitly catch here (rather than asserting a specific
+    // resolution) and prove settlement, one way or the other.
+    let settled = false;
+    try {
+      await firstNext;
+      settled = true;
+    } catch (err) {
+      settled = true;
+      expect(err).toBeDefined();
+    }
+    expect(settled).toBe(true);
+
+    // Drain whatever remains so no background callback fires after this test
+    // (and this file's process) moves on.
+    try {
+      let result = await gen.next();
+      while (!result.done) {
+        result = await gen.next();
+      }
+    } catch {
+      // Draining after a mid-stream cleanup may itself reject; that's fine.
+    }
+  });
+
+  // Deadlock regression: unlike the F1 test above (which races cleanup()
+  // against a stream that fails before emitting data), this test uses a
+  // script that produces real output with enough volume that the worker
+  // thread is genuinely attached and mid-delivery -- blocked in
+  // napi_call_threadsafe_function(..., napi_tsfn_blocking) -- when cleanup()
+  // drops the last native reference. Before the fix (napi_cleanup's
+  // synchronous uv_thread_join), this scenario hung the process; after the
+  // fix, cleanup() defers teardown to a waiter thread until this op drains,
+  // so both the cleanup() promise and the streaming generator settle.
+  it('cleanup() during an active, output-producing runStreaming() does not deadlock', async () => {
+    const dw = trackedDataWeave();
+    dw.initialize();
+
+    const gen = dw.runStreaming(
+      'output application/json --- (1 to 5000) map {id: $, name: "item_" ++ $}'
+    );
+
+    // Pin the operation without draining it: exactly one .next() call runs
+    // the generator's synchronous prefix (including the native call that
+    // hands the op to a background thread) up to its first await.
+    const firstNext = gen.next();
+
+    const cleanupPromise = dw.cleanup();
+
+    await expect(
+      Promise.race([
+        cleanupPromise,
+        new Promise((_, reject) => setTimeout(() => reject(new Error('cleanup() timed out')), 10000)),
+      ])
+    ).resolves.toBeUndefined();
+
+    // Drain whatever remains; the stream itself must also settle, not hang.
+    let result = await firstNext;
+    while (!result.done) {
+      result = await gen.next();
+    }
+    expect(result.value).toBeDefined();
+  }, 15000);
+
+  // Same deadlock regression as above, for runTransform() -- the design doc
+  // notes the same problem applies to transform's write_tsfn delivery path.
+  it('cleanup() during an active, output-producing runTransform() does not deadlock', async () => {
+    const dw = trackedDataWeave();
+    dw.initialize();
+
+    const parts: Buffer[] = [Buffer.from("[")];
+    for (let i = 1; i <= 2000; i++) {
+      if (i > 1) parts.push(Buffer.from(","));
+      parts.push(Buffer.from(`{"id":${i}}`));
+    }
+    parts.push(Buffer.from("]"));
+    const inputData = [Buffer.concat(parts)];
+
+    const gen = dw.runTransform(
+      "output application/json\n---\npayload map $",
+      inputData,
+      { mimeType: "application/json" }
+    );
+
+    const firstNext = gen.next();
+
+    // Unlike runStreaming (whose native call is synchronous up to its first
+    // await), runTransform's generator body awaits createChunkReader(input)
+    // -- itself a microtask, not real async work for a sync-iterable input --
+    // before reaching the native runScriptTransformEngine call. A single
+    // un-awaited .next() only advances the generator to that intermediate
+    // await, not past it, so the native op would not yet be dispatched
+    // (g_active_ops still 0) when cleanup() below fires. One extra microtask
+    // tick lets that internal await settle so the native call is actually
+    // in flight, which is what this test needs to race against.
+    await Promise.resolve();
+
+    const cleanupPromise = dw.cleanup();
+
+    await expect(
+      Promise.race([
+        cleanupPromise,
+        new Promise((_, reject) => setTimeout(() => reject(new Error('cleanup() timed out')), 10000)),
+      ])
+    ).resolves.toBeUndefined();
+
+    let result = await firstNext;
+    while (!result.done) {
+      result = await gen.next();
+    }
+    expect(result.value).toBeDefined();
+  }, 15000);
+
+  // Fast-path regression guard: cleanup() called once a stream has already
+  // fully drained (g_active_ops back to 0 by the time the last reference is
+  // released) must still resolve via the original, unchanged inline fast
+  // path -- confirming the new deferred-teardown branch didn't silently
+  // become the only path through napi_cleanup.
+  it('cleanup() after a stream has already fully drained resolves via the fast path', async () => {
+    const dw = trackedDataWeave();
+    dw.initialize();
+
+    const gen = dw.runStreaming('output application/json --- {a: 1}');
+    let result = await gen.next();
+    while (!result.done) {
+      result = await gen.next();
+    }
+    expect(result.value.success).toBe(true);
+
+    await expect(dw.cleanup()).resolves.toBeUndefined();
+  });
+
+  // Idempotency / re-entrant cleanup: two cleanup() calls that both arrive
+  // while a stream is active must both resolve off the same underlying
+  // teardown -- without spawning a second waiter thread, throwing, or
+  // decrementing g_ref_count below 0.
+  it('two concurrent cleanup() calls during an active stream both resolve cleanly', async () => {
+    const dw = trackedDataWeave();
+    dw.initialize();
+
+    const gen = dw.runStreaming(
+      'output application/json --- (1 to 3000) map {id: $}'
+    );
+    const firstNext = gen.next();
+
+    const [r1, r2] = await Promise.all([
+      Promise.race([
+        dw.cleanup(),
+        new Promise((_, reject) => setTimeout(() => reject(new Error('first cleanup() timed out')), 10000)),
+      ]),
+      Promise.race([
+        dw.cleanup(),
+        new Promise((_, reject) => setTimeout(() => reject(new Error('second cleanup() timed out')), 10000)),
+      ]),
+    ]);
+    expect(r1).toBeUndefined();
+    expect(r2).toBeUndefined();
+
+    let result = await firstNext;
+    while (!result.done) {
+      result = await gen.next();
+    }
+  }, 15000);
+
+  // Re-initialize during pending teardown: starting a stream, calling
+  // cleanup() without awaiting it, then immediately calling initialize()
+  // again must block (at the native layer, inside napi_initialize) until the
+  // pending teardown finishes, rather than racing a second
+  // graal_create_isolate against an isolate that is still tearing down. The
+  // instance must be fully usable afterward.
+  it('initialize() called during a pending teardown waits for it and then works', async () => {
+    const dw = trackedDataWeave();
+    dw.initialize();
+
+    const gen = dw.runStreaming(
+      'output application/json --- (1 to 3000) map {id: $}'
+    );
+    const firstNext = gen.next();
+
+    // Deliberately not awaited -- this is the pending-teardown state under test.
+    const cleanupPromise = dw.cleanup();
+
+    // dw.cleanup() already set dw's own initialized flag false only after its
+    // internal await resolves; to exercise the *native* pending-teardown path
+    // independent of this specific instance's TS-level guard, drive a second,
+    // fresh instance's initialize() concurrently -- it shares the same
+    // process-global isolate/g_ref_count.
+    const dw2 = trackedDataWeave();
+    const secondInitDone = new Promise<void>((resolve) => {
+      dw2.initialize();
+      resolve();
+    });
+
+    await Promise.race([
+      Promise.all([cleanupPromise, secondInitDone]),
+      new Promise((_, reject) => setTimeout(() => reject(new Error('initialize()-during-teardown timed out')), 10000)),
+    ]);
+
+    expect(dw2.run("6 * 7").getString()).toBe("42");
+
+    let result = await firstNext;
+    while (!result.done) {
+      result = await gen.next();
+    }
+  }, 15000);
+
+  // Node-layer contract (F4-adjacent): once cleanup() has torn an instance
+  // down, run() must be rejected by dataweave.ts's own ensureInitialized()
+  // guard -- a DataWeaveError with a "not initialized" message -- rather than
+  // reaching the native addon at all with a handle that no longer refers to a
+  // live engine. This is the TS-level half of the destroyed/unknown-handle
+  // contract; the native "Unknown engine handle" string is the deeper
+  // contract the addon enforces if it were ever called with a stale handle,
+  // which this guard prevents from happening via the public API.
+  it('run() after cleanup() throws a DataWeaveError via the TS-level ensureInitialized guard', async () => {
+    const dw = trackedDataWeave({
+      resolveModule: modulesFromMap({
+        'org/test/destroyedHandleLib.dwl': '...',
+      }),
+    });
+    dw.initialize();
+    await dw.cleanup();
+
+    expect(() => dw.run('1 + 1')).toThrow(DataWeaveError);
+    expect(() => dw.run('1 + 1')).toThrow(/DataWeave runtime not initialized/);
+  });
 });
diff --git a/native-lib/node/tests/integration/dataweave.test.ts b/native-lib/node/tests/integration/dataweave.test.ts
index bacf1606..e5af4608 100644
--- a/native-lib/node/tests/integration/dataweave.test.ts
+++ b/native-lib/node/tests/integration/dataweave.test.ts
@@ -3,8 +3,8 @@ import { readFileSync } from "node:fs";
 import { join } from "node:path";
 import { DataWeave, run, runStreaming, runTransform, cleanup } from "../../src/index";
 
-afterAll(() => {
-  cleanup();
+afterAll(async () => {
+  await cleanup();
 });
 
 describe("DataWeave Node.js API", () => {
@@ -21,7 +21,7 @@ describe("DataWeave Node.js API", () => {
       expect(result.getString()).toBe("42");
     });
 
-    it("explicit instance lifecycle", () => {
+    it("explicit instance lifecycle", async () => {
       const dw = new DataWeave();
       dw.initialize();
       try {
@@ -30,7 +30,7 @@ describe("DataWeave Node.js API", () => {
         const r2 = dw.run("sqrt(10000)");
         expect(r2.getString()).toBe("100");
       } finally {
-        dw.cleanup();
+        await dw.cleanup();
       }
     });
 
diff --git a/native-lib/node/tests/integration/edge-cases.test.ts b/native-lib/node/tests/integration/edge-cases.test.ts
index d1077e67..099659ab 100644
--- a/native-lib/node/tests/integration/edge-cases.test.ts
+++ b/native-lib/node/tests/integration/edge-cases.test.ts
@@ -6,8 +6,8 @@ import { describe, it, expect, afterAll } from "vitest";
 import { DataWeave, run, runStreaming, runTransform, cleanup } from "../../src/index";
 import type { StreamingResult } from "../../src/types";
 
-afterAll(() => {
-  cleanup();
+afterAll(async () => {
+  await cleanup();
 });
 
 /** Drains a streaming/transform generator, returning its chunks and terminal metadata. */
@@ -61,7 +61,7 @@ describe("runTransform with async-iterable input", () => {
 });
 
 describe("multi-instance lifecycle", () => {
-  it("runs two independent instances and cleans them up independently", () => {
+  it("runs two independent instances and cleans them up independently", async () => {
     const a = new DataWeave();
     const b = new DataWeave();
     a.initialize();
@@ -70,8 +70,8 @@ describe("multi-instance lifecycle", () => {
       expect(a.run("1 + 1").getString()).toBe("2");
       expect(b.run("2 + 3").getString()).toBe("5");
     } finally {
-      a.cleanup();
-      b.cleanup();
+      await a.cleanup();
+      await b.cleanup();
     }
     // After cleanup, a fresh instance still works (runtime not permanently torn down).
     const c = new DataWeave();
@@ -79,22 +79,22 @@ describe("multi-instance lifecycle", () => {
     try {
       expect(c.run("6 * 7").getString()).toBe("42");
     } finally {
-      c.cleanup();
+      await c.cleanup();
     }
   });
 
-  it("initialize is idempotent and re-initialization after cleanup works", () => {
+  it("initialize is idempotent and re-initialization after cleanup works", async () => {
     const dw = new DataWeave();
     dw.initialize();
     dw.initialize(); // no-op, must not throw
     expect(dw.run("1").getString()).toBe("1");
-    dw.cleanup();
-    dw.cleanup(); // double cleanup, must not throw
+    await dw.cleanup();
+    await dw.cleanup(); // double cleanup, must not throw
     dw.initialize(); // re-init
     try {
       expect(dw.run("2").getString()).toBe("2");
     } finally {
-      dw.cleanup();
+      await dw.cleanup();
     }
   });
 
diff --git a/native-lib/node/tests/integration/engine-handle-contract.test.ts b/native-lib/node/tests/integration/engine-handle-contract.test.ts
new file mode 100644
index 00000000..04a192c2
--- /dev/null
+++ b/native-lib/node/tests/integration/engine-handle-contract.test.ts
@@ -0,0 +1,279 @@
+import { describe, it, expect, beforeAll, afterAll } from "vitest";
+import * as ffi from "../../src/ffi";
+import { findLibrary, buildInputsJson } from "../../src/utils";
+
+// W-23692110 round 11 finding #6.
+//
+// The Java `ScriptRuntimeTest` only asserts on the UNKNOWN_ENGINE_HANDLE_JSON
+// constant -- the @CEntryPoint methods it wraps cannot run in a hosted JVM, so
+// nothing has ever driven the real `*_engine` entrypoints through the
+// compiled addon against an unknown or destroyed handle. This file closes
+// that gap: it loads the REAL addon (no `vi.mock` of ffi) and drives
+// `runScriptEngine` / `runScriptStreamingEngine` / `runScriptTransformEngine`
+// directly through the raw `ffi` module -- the addon boundary the finding is
+// about -- against handles that were never registered and against handles
+// that were registered and then destroyed.
+//
+// Confirmed empirically (see task-6-report.md) against the real addon:
+//   - sync `runScriptEngine` RETURNS the JSON string
+//     `{"success":false,"error":"Unknown engine handle"}` -- it does not throw.
+//   - `runScriptStreamingEngine` / `runScriptTransformEngine` RESOLVE (never
+//     reject) their promise with that same JSON string as the terminal
+//     metadata; no chunk callback fires for an unknown/destroyed handle.
+// This is the same envelope produced by NativeLib.UNKNOWN_ENGINE_HANDLE_JSON
+// on the Java side (native-lib/src/main/java/org/mule/weave/lib/NativeLib.java),
+// threaded back through addon.c's engine entrypoints and unmodified by the TS
+// parsing layer (parseNativeResponse / parseStreamingResult in src/result.ts).
+//
+// The native addon globals (g_ref_count, g_initialized, g_bridges, etc.) are
+// process-wide C statics -- vitest's per-file module isolation does NOT reset
+// them, and napi_initialize/napi_cleanup are plain integer ref-counts (one
+// increment per initialize(), one decrement per cleanup(), teardown only on
+// the transition to zero). So this file calls ffi.initialize() exactly ONCE
+// for the whole suite (beforeAll), balanced by exactly one ffi.cleanup() that
+// brings the ref count to zero (in the last real test, "final cleanup..."
+// below) -- mirroring independent-engines.test.ts's single
+// initialize()/cleanup() pair rather than handle-validation.test.ts's
+// per-test balancing (that file calls initialize()/cleanup() once per test,
+// which does not fit here since several tests below deliberately build on a
+// still-live engine/isolate from a prior test). The trailing afterAll is a
+// pure safety net (idempotent no-op on the happy path) in case an earlier
+// assertion throws before the drainage test runs, so this file never strands
+// a ref-count bump for sibling integration test files sharing the same
+// vitest worker process.
+describe("*_engine unknown/destroyed-handle contract (round 11 #6)", () => {
+  beforeAll(() => {
+    ffi.initialize(findLibrary());
+  });
+
+  afterAll(async () => {
+    // Idempotent: a no-op if the ref count already reached zero (the normal
+    // case -- the drainage test below already did that). A genuine safety
+    // net only if an earlier test threw before reaching that point.
+    await ffi.cleanup();
+  });
+
+  // A handle value that was never handed out by createEngine()/
+  // createEngineWithResolver() (those only ever return small positive
+  // handles from the Java-side registry) and can never collide with one.
+  const UNKNOWN_HANDLE = Number.MAX_SAFE_INTEGER;
+  const UNKNOWN_ENVELOPE = { success: false, error: "Unknown engine handle" };
+
+  it("runScriptEngine on a never-registered handle returns the terminal envelope, does not throw", () => {
+    let raw: string | undefined;
+    expect(() => {
+      raw = ffi.runScriptEngine(
+        UNKNOWN_HANDLE,
+        "%dw 2.0\noutput application/json\n---\n1 + 1",
+        buildInputsJson({})
+      );
+    }).not.toThrow();
+
+    expect(JSON.parse(raw!)).toEqual(UNKNOWN_ENVELOPE);
+  });
+
+  it("runScriptStreamingEngine on a never-registered handle resolves (never rejects) with the terminal envelope", async () => {
+    const chunks: Buffer[] = [];
+    const raw = await ffi.runScriptStreamingEngine(
+      UNKNOWN_HANDLE,
+      "%dw 2.0\noutput application/json\n---\n[1, 2, 3]",
+      buildInputsJson({}),
+      (chunk) => chunks.push(chunk)
+    );
+
+    expect(JSON.parse(raw)).toEqual(UNKNOWN_ENVELOPE);
+    // No output was ever produced for an engine that doesn't exist.
+    expect(chunks).toHaveLength(0);
+  });
+
+  it("runScriptTransformEngine on a never-registered handle resolves (never rejects) with the terminal envelope", async () => {
+    let readCalls = 0;
+    let firstRead = true;
+    const readCb = (_bufSize: number): Buffer | null => {
+      readCalls++;
+      if (firstRead) {
+        firstRead = false;
+        return Buffer.from("1");
+      }
+      return null;
+    };
+    const chunks: Buffer[] = [];
+    const writeCb = (chunk: Buffer) => chunks.push(chunk);
+
+    const raw = await ffi.runScriptTransformEngine(
+      UNKNOWN_HANDLE,
+      "output application/json\n---\npayload",
+      "{}",
+      "payload",
+      "application/json",
+      null,
+      readCb,
+      writeCb
+    );
+
+    expect(JSON.parse(raw)).toEqual(UNKNOWN_ENVELOPE);
+    // The unknown-handle rejection happens before a worker is ever spawned,
+    // so the read/write callbacks are never invoked.
+    expect(readCalls).toBe(0);
+    expect(chunks).toHaveLength(0);
+  });
+
+  it("all three entrypoints on a destroyed handle return/resolve the same terminal envelope, after proving the handle worked", async () => {
+    const handle = ffi.createEngine();
+
+    // Prove the handle is genuinely live before destroying it.
+    const preDestroy = JSON.parse(
+      ffi.runScriptEngine(handle, "%dw 2.0\noutput application/json\n---\n1 + 1", buildInputsJson({}))
+    );
+    expect(preDestroy.success).toBe(true);
+
+    ffi.destroyEngine(handle);
+
+    // Sync entrypoint: returns the envelope, does not throw.
+    let syncRaw: string | undefined;
+    expect(() => {
+      syncRaw = ffi.runScriptEngine(handle, "%dw 2.0\noutput application/json\n---\n1", buildInputsJson({}));
+    }).not.toThrow();
+    expect(JSON.parse(syncRaw!)).toEqual(UNKNOWN_ENVELOPE);
+
+    // Streaming entrypoint: resolves with the envelope.
+    const streamChunks: Buffer[] = [];
+    const streamRaw = await ffi.runScriptStreamingEngine(
+      handle,
+      "%dw 2.0\noutput application/json\n---\n[1, 2, 3]",
+      buildInputsJson({}),
+      (chunk) => streamChunks.push(chunk)
+    );
+    expect(JSON.parse(streamRaw)).toEqual(UNKNOWN_ENVELOPE);
+    expect(streamChunks).toHaveLength(0);
+
+    // Transform entrypoint: resolves with the envelope.
+    let transformReadCalls = 0;
+    let transformFirstRead = true;
+    const transformReadCb = (_bufSize: number): Buffer | null => {
+      transformReadCalls++;
+      if (transformFirstRead) {
+        transformFirstRead = false;
+        return Buffer.from("1");
+      }
+      return null;
+    };
+    const transformChunks: Buffer[] = [];
+    const transformRaw = await ffi.runScriptTransformEngine(
+      handle,
+      "output application/json\n---\npayload",
+      "{}",
+      "payload",
+      "application/json",
+      null,
+      transformReadCb,
+      (chunk) => transformChunks.push(chunk)
+    );
+    expect(JSON.parse(transformRaw)).toEqual(UNKNOWN_ENVELOPE);
+    expect(transformReadCalls).toBe(0);
+    expect(transformChunks).toHaveLength(0);
+  });
+
+  // Same-thread post-admission ordering (deterministic, not best-effort):
+  // destroyEngine() is fired synchronously immediately after admission of the
+  // op (right after starting runScriptStreamingEngine, before awaiting it).
+  // The round-11 #2/#3 pin is taken atomically at admission, under g_mutex, in
+  // bridge_begin_op_locked -- so this same-thread ordering deterministically
+  // lands AFTER the pin is already held. That means the op MUST complete
+  // successfully with complete chunks; there is no closed set of "success or
+  // Unknown-engine-handle envelope" to tolerate here, because the envelope can
+  // only arise if the pin were NOT held at admission. Requiring success (and
+  // no longer accepting the envelope) makes this test fail if a future
+  // regression drops the admission-time pin, instead of silently passing by
+  // returning the accepted terminal envelope.
+  //
+  // Genuinely concurrent cross-thread interleavings (a real Worker racing
+  // destroyEngine() against admission on a different thread) are a distinct,
+  // non-deterministic window that this same-thread ordering does not exercise
+  // and cannot stand in for. That case remains covered best-effort by the
+  // forthcoming Worker-based suite (Task 8), matching the documented posture
+  // of rounds 5-10's cross-Worker races (see run-admission.test.ts /
+  // admission-during-teardown.test.ts) -- it is not tolerated away in this
+  // test.
+  it(
+    "destroyEngine() fired right after admission of an in-flight streaming op deterministically succeeds (pin held at admission)",
+    async () => {
+      const ITERATIONS = 50;
+      for (let i = 0; i < ITERATIONS; i++) {
+        const handle = ffi.createEngine();
+        const chunks: Buffer[] = [];
+        const resultPromise = ffi.runScriptStreamingEngine(
+          handle,
+          "%dw 2.0\noutput application/json\n---\n[1, 2, 3]",
+          buildInputsJson({}),
+          (chunk) => chunks.push(chunk)
+        );
+        // Fire destroy immediately after admission, before awaiting. The round-11
+        // pin is taken atomically at admission (under g_mutex, in
+        // bridge_begin_op_locked), so this ordering lands AFTER the pin and the
+        // op MUST complete successfully. Requiring success (not tolerating the
+        // Unknown-engine-handle envelope) makes this test fail if a regression
+        // drops the admission-time pin.
+        expect(() => ffi.destroyEngine(handle)).not.toThrow();
+
+        const raw = await resultPromise;
+        const parsed = JSON.parse(raw);
+        expect(parsed.success).toBe(true);
+        expect(JSON.parse(Buffer.concat(chunks).toString("utf-8"))).toEqual([1, 2, 3]);
+      }
+    },
+    60000
+  );
+
+  it("deferred registry removal after an in-flight op finalizes without wedging the isolate (round 12 #3)", async () => {
+    // Uses the shared beforeAll isolate. Create an engine, start a streaming
+    // op, destroy the engine while the op is admitted, drain the op. The
+    // deferred finalize (bridge_end_op -> bridge_finalize_registry) must
+    // complete and a subsequent run on a fresh engine must still work
+    // (isolate not torn down / not wedged by the transient reservation).
+    const handle = ffi.createEngine();
+    const chunks: Buffer[] = [];
+    const resultPromise = ffi.runScriptStreamingEngine(
+      handle,
+      "%dw 2.0\noutput application/json\n---\n[1, 2, 3]",
+      buildInputsJson({}),
+      (chunk) => chunks.push(chunk)
+    );
+    expect(() => ffi.destroyEngine(handle)).not.toThrow();
+    const raw = await resultPromise;
+    const parsed = JSON.parse(raw);
+    // Pin held at admission (round 11) -> success expected; either way no crash.
+    if (parsed.success) {
+      expect(JSON.parse(Buffer.concat(chunks).toString("utf-8"))).toEqual([1, 2, 3]);
+    }
+    // Isolate still healthy after the deferred finalize ran:
+    const h2 = ffi.createEngine();
+    const envelope = JSON.parse(
+      ffi.runScriptEngine(h2, "%dw 2.0\noutput application/json\n---\n2 + 2", buildInputsJson({}))
+    );
+    expect(envelope.success).toBe(true);
+    expect(JSON.parse(Buffer.from(envelope.result, "base64").toString("utf-8"))).toBe(4);
+    ffi.destroyEngine(h2);
+  });
+
+  it("final cleanup drains the shared isolate (idempotent)", async () => {
+    // Exactly one ffi.initialize() ran for this whole file (beforeAll), so
+    // this is the ONE balancing ffi.cleanup() that brings the native
+    // g_ref_count to zero and genuinely tears the isolate down (napi_cleanup
+    // Case 4, since no op is in flight) -- not a no-op decrement of a
+    // still-positive count left over from other tests. Prove that teardown
+    // actually happened, not just that the call resolved: a subsequent
+    // engine-level call must now observe "not initialized" rather than
+    // silently succeeding against a still-live isolate.
+    await ffi.cleanup();
+
+    expect(() =>
+      ffi.runScriptEngine(UNKNOWN_HANDLE, "%dw 2.0\noutput application/json\n---\n1", buildInputsJson({}))
+    ).toThrow(/not initialized/i);
+
+    // A second cleanup() call after the ref count already reached zero must
+    // remain a safe no-op, mirroring independent-engines.test.ts's final
+    // teardown discipline.
+    await expect(ffi.cleanup()).resolves.toBeUndefined();
+  });
+});
diff --git a/native-lib/node/tests/integration/env-init-ownership.test.ts b/native-lib/node/tests/integration/env-init-ownership.test.ts
new file mode 100644
index 00000000..fe30aa90
--- /dev/null
+++ b/native-lib/node/tests/integration/env-init-ownership.test.ts
@@ -0,0 +1,94 @@
+import { describe, it, expect } from "vitest";
+import * as ffi from "../../src/ffi";
+import { findLibrary, buildInputsJson } from "../../src/utils";
+
+// W-23692110 round 13 #5: the init reference is owned per napi_env, not per
+// engine. These raw-ffi tests (no vi.mock) drive the addon boundary directly --
+// the exact surface the finding is about -- and use the ref-count proxy from
+// instance-lifecycle.test.ts: after balancing to zero refs a raw engine call
+// throws /not initialized/; while the isolate is live a run succeeds.
+//
+// IMPORTANT -- these are single-env SMOKE tests, NOT true #5 regression teeth.
+// #5 is a CROSS-ENV bug: an abandoned/dying env with N engines under one
+// initialize() firing N per-engine releases against the one reference it owns,
+// or one env's cleanup()/env-death releasing a reference another env owns. Both
+// require either a real dying env or two distinct napi_envs with asymmetric
+// init/cleanup. Vitest runs these on the single main-thread env, so they cannot
+// distinguish the fixed isolate from the pre-fix (buggy) one -- it was verified
+// empirically that both cases below pass unchanged when rebuilt against the
+// pre-round-13 addon (destroyEngine() never released the init ref in any
+// revision, and the second cleanup() was already a no-op via the long-standing
+// `if (g_ref_count > 0)` floor). They guard that the sanctioned single-env path
+// still behaves (liveness + no double-decrement corruption); they do NOT prove
+// #5 is fixed. The cross-env behavior that #5 is actually about -- an abandoned env with N
+// engines under one initialize() -- is now pinned by the dedicated cross-env
+// regression test in worker-lifecycle.test.ts ("a Worker that inits once +
+// creates N engines + exits without cleanup() does NOT tear down the isolate
+// under a live main engine"), which fails RED on the round-12 implementation
+// and passes at round 13+. These single-env smoke tests remain as a fast guard
+// on the sanctioned single-env liveness path.
+
+const LIB = findLibrary();
+
+function runOn(handle: number, expr: string): unknown {
+  const envelope = JSON.parse(
+    ffi.runScriptEngine(handle, `%dw 2.0\noutput application/json\n---\n${expr}`, buildInputsJson({}))
+  );
+  expect(envelope.success).toBe(true);
+  return JSON.parse(Buffer.from(envelope.result, "base64").toString("utf-8"));
+}
+
+describe("per-env init-reference ownership -- single-env smoke tests (round 13 #5)", () => {
+  // Smoke test (NOT a #5 regression test -- see file header): destroyEngine()
+  // never released the init reference in any revision, so this held pre-fix too.
+  it("smoke: one initialize() + multiple engines stays live when a single engine is destroyed", () => {
+    ffi.initialize(LIB); // ONE init reference for this env
+    const h1 = ffi.createEngine();
+    const h2 = ffi.createEngine();
+    expect(runOn(h2, "6 * 7")).toBe(42);
+
+    // Destroy one engine. The isolate reference belongs to initialize(), not to
+    // an engine, so the isolate must stay alive and h2 must still run.
+    ffi.destroyEngine(h1);
+    expect(runOn(h2, "1 + 1")).toBe(2);
+
+    // Balance: destroy the other engine and release the single init reference.
+    ffi.destroyEngine(h2);
+    // eslint-disable-next-line @typescript-eslint/no-floating-promises
+    return ffi.cleanup().then(() => {
+      expect(() =>
+        ffi.runScriptEngine(Number.MAX_SAFE_INTEGER, "%dw 2.0\noutput application/json\n---\n1", buildInputsJson({}))
+      ).toThrow(/not initialized/i);
+    });
+  });
+
+  // Smoke test (NOT a #5 regression test -- see file header): the second
+  // cleanup() was already a no-op pre-fix via the `if (g_ref_count > 0)` floor,
+  // so with one env this passes on the buggy addon too. #5's gate protects the
+  // CROSS-env case (one env stealing another's reference), not observable here.
+  it("smoke: a second cleanup() on an env that owns no reference does not corrupt the count", async () => {
+    ffi.initialize(LIB); // init_refs = 1
+    const h = ffi.createEngine();
+    expect(runOn(h, "2 + 2")).toBe(4);
+    ffi.destroyEngine(h);
+
+    // First cleanup releases this env's one reference -> isolate torn down.
+    await ffi.cleanup();
+    // Second cleanup: this env's init_refs is already 0. Must be a no-op --
+    // it must NOT drive g_ref_count negative or perturb a later isolate.
+    await ffi.cleanup();
+
+    // Prove the count was not corrupted: a fresh, fully-balanced init/run/cleanup
+    // cycle still nets to zero (a corrupted negative count would leave the next
+    // isolate un-torn-down and this final probe would NOT report not-initialized).
+    ffi.initialize(LIB);
+    const h2 = ffi.createEngine();
+    expect(runOn(h2, "3 + 4")).toBe(7);
+    ffi.destroyEngine(h2);
+    await ffi.cleanup();
+
+    expect(() =>
+      ffi.runScriptEngine(Number.MAX_SAFE_INTEGER, "%dw 2.0\noutput application/json\n---\n1", buildInputsJson({}))
+    ).toThrow(/not initialized/i);
+  });
+});
diff --git a/native-lib/node/tests/integration/first-resolver-wins.test.ts b/native-lib/node/tests/integration/first-resolver-wins.test.ts
deleted file mode 100644
index 75e7da59..00000000
--- a/native-lib/node/tests/integration/first-resolver-wins.test.ts
+++ /dev/null
@@ -1,34 +0,0 @@
-// Verifies the process-wide "first resolver wins" behavior documented in
-// docs/external-modules.md#multiple-resolvers-in-one-process and
-// ScriptRuntime.setResolver(): once a DataWeave instance's resolver is
-// installed on the native engine singleton, a second instance constructed
-// with a *different* resolver in the same process never has its resolver
-// installed. That's only observable when the second instance's resolver is
-// the second one ever installed for the whole process, so — like
-// init-bad-path.test.ts — this runs in a dedicated child process rather than
-// in-lane, making it order- and pool-configuration-independent.
-import { describe, it, expect } from "vitest";
-import { execFileSync } from "node:child_process";
-import { join } from "node:path";
-import { existsSync } from "node:fs";
-
-const FIXTURE = join(__dirname, "fixtures", "first-resolver-wins.cjs");
-const DIST_ENTRY = join(__dirname, "..", "..", "dist", "index.js");
-
-describe("first-resolver-wins (isolated process)", () => {
-  it("a second DataWeave instance's resolver is silently ignored in favor of the first", () => {
-    expect(existsSync(DIST_ENTRY), `built entry missing at ${DIST_ENTRY} — run \`npm run build:ts\``).toBe(true);
-
-    // execFileSync throws on a non-zero exit, so a "wrong resolver won" /
-    // native-crash outcome in the child fails this test. A timeout is also
-    // required: execFileSync blocks synchronously with no way for Vitest to
-    // interrupt it, so a native deadlock in the child would otherwise hang
-    // the whole suite instead of failing this one test.
-    const stdout = execFileSync(process.execPath, [FIXTURE], {
-      encoding: "utf-8",
-      timeout: 30_000,
-    });
-
-    expect(stdout).toContain("OK:first-resolver-wins");
-  });
-});
diff --git a/native-lib/node/tests/integration/fixtures/first-resolver-wins.cjs b/native-lib/node/tests/integration/fixtures/first-resolver-wins.cjs
deleted file mode 100644
index 3dc2fd42..00000000
--- a/native-lib/node/tests/integration/fixtures/first-resolver-wins.cjs
+++ /dev/null
@@ -1,103 +0,0 @@
-// Child-process fixture for the first-resolver-wins regression test.
-//
-// Runs in a FRESH process (spawned by first-resolver-wins.test.ts) so the
-// process-wide ScriptRuntime singleton in the native layer starts with no
-// resolver installed (see ScriptRuntime.setResolver(): once any DataWeave
-// instance's resolver is installed, every later instance's resolver is
-// silently ignored — a warning is logged and the first resolver keeps being
-// used). That behavior is only observable on the FIRST resolver installation
-// of a process, so this fixture -- not an in-lane vitest test -- is the only
-// reliable way to exercise it.
-//
-// Contract with the parent:
-//   - Requires the built CommonJS entry at ../../../dist/index.js.
-//   - Constructs dw1 with a resolver for 'first.dwl' and dw2 with a
-//     *different* resolver for 'second.dwl', then initializes both.
-//   - Runs a script through dw1 that imports 'first.dwl' to force-install
-//     dw1's resolver on the singleton engine (must succeed).
-//   - Runs a script through dw2 that imports 'second.dwl'. Per the singleton
-//     semantics, dw2's resolver is never installed, so this import must fail.
-//   - Runs a THIRD script, through dw2, that imports 'first.dwl' again and
-//     asserts it still returns "Hello World". This is the check that actually
-//     distinguishes "the first resolver remains active" from "custom
-//     resolution broke entirely after the first call" — the second script
-//     alone would fail identically under either explanation.
-//   - Always calls cleanup() on both instances via try/finally, so teardown
-//     is exercised even on failure, then exits naturally (no process.exit()).
-//   - Prints "OK:first-resolver-wins" when all three expectations hold, or
-//     "FAIL:<reason>" (with a non-zero exitCode) otherwise. A native crash
-//     surfaces as a non-zero signal exit, which the parent also treats as
-//     failure.
-const path = require("node:path");
-
-const { DataWeave, modulesFromMap } = require(path.join(__dirname, "..", "..", "..", "dist", "index.js"));
-
-const dw1 = new DataWeave({
-  resolveModule: modulesFromMap({
-    "first.dwl": '%dw 2.0\nfun greet(n: String) = "Hello " ++ n',
-  }),
-});
-
-const dw2 = new DataWeave({
-  resolveModule: modulesFromMap({
-    "second.dwl": '%dw 2.0\nfun shout(n: String) = n ++ "!"',
-  }),
-});
-
-let failure = null;
-
-try {
-  dw1.initialize();
-  dw2.initialize();
-
-  const firstResult = dw1.run(`
-    %dw 2.0
-    import first
-    output application/json
-    ---
-    first::greet("World")
-  `);
-
-  if (!firstResult.success) {
-    failure = "first-resolver-did-not-resolve:" + firstResult.error;
-  } else {
-    const secondResult = dw2.run(`
-      %dw 2.0
-      import second
-      output application/json
-      ---
-      second::shout("hi")
-    `);
-
-    if (secondResult.success) {
-      failure = "second-resolver-unexpectedly-won";
-    } else {
-      // Prove the first resolver is still ACTIVE on dw2 (not merely that
-      // dw2's own resolver lost). A resolver that died entirely after the
-      // first call would also make second.dwl fail above -- this second
-      // check on dw2 is what actually distinguishes "first resolver wins"
-      // from "custom resolution stopped working after the first run".
-      const stillFirstResult = dw2.run(`
-        %dw 2.0
-        import first
-        output application/json
-        ---
-        first::greet("World")
-      `);
-
-      if (!stillFirstResult.success || JSON.parse(stillFirstResult.getString()) !== "Hello World") {
-        failure = "first-resolver-no-longer-active-on-dw2:" + (stillFirstResult.error || stillFirstResult.getString());
-      }
-    }
-  }
-} finally {
-  dw1.cleanup();
-  dw2.cleanup();
-}
-
-if (failure) {
-  console.log("FAIL:" + failure);
-  process.exitCode = 1;
-} else {
-  console.log("OK:first-resolver-wins");
-}
diff --git a/native-lib/node/tests/integration/handle-validation.test.ts b/native-lib/node/tests/integration/handle-validation.test.ts
new file mode 100644
index 00000000..2feddfb8
--- /dev/null
+++ b/native-lib/node/tests/integration/handle-validation.test.ts
@@ -0,0 +1,73 @@
+import { describe, it, expect, afterEach } from "vitest";
+import * as ffi from "../../src/ffi";
+import { findLibrary } from "../../src/utils";
+
+// Round-6 finding #1 (defense-in-depth): the native handle-read sites
+// (napi_get_value_int64 in napi_run_script_engine,
+// napi_run_script_streaming_engine, napi_run_script_transform_engine) must
+// reject a non-integer handle argument instead of silently using
+// uninitialized/garbage stack data as the engine handle.
+//
+// This is driven through `ffi` (the raw addon boundary), not through the
+// `DataWeave` class, because Task 1's JS-layer state guard only ever passes
+// `this.engineHandle` (always a number once initialized) down to the native
+// call -- so a bad handle can never reach these C sites through the public
+// TS API. Each `ffi.xxx` export is a pure pass-through to the native addon
+// (see src/ffi.ts: no validation of its own), so calling them directly with
+// a non-numeric "handle" exercises the raw C boundary while reusing the same
+// initialize()/findLibrary() bootstrap the other integration tests use.
+//
+// One test covers all three sites (rather than three separate tests) to keep
+// the suite's test count increasing by exactly one for this task.
+//
+// Real addon, no mocking.
+//
+// The native addon globals (g_ref_count, g_initialized, etc.) are
+// process-wide C statics -- vitest's per-file module isolation does NOT
+// reset them. Every ffi.initialize() here must be balanced by a matching
+// ffi.cleanup() so this file doesn't leak a ref-count bump into sibling
+// integration test files sharing the same vitest worker process (mirrors
+// admission-during-teardown.test.ts's care to drain/settle before the file
+// ends, and instance-lifecycle.test.ts's afterEach cleanup pattern).
+describe("native handle validation (round 6 #1)", () => {
+  afterEach(async () => {
+    await ffi.cleanup();
+  });
+
+  it("runScriptEngine/runScriptStreamingEngine/runScriptTransformEngine all throw on a non-integer handle rather than using garbage", () => {
+    ffi.initialize(findLibrary());
+
+    // napi_get_value_int64 must fail (and be checked) for a non-numeric
+    // handle argument; each site must throw cleanly instead of proceeding
+    // with whatever `handle64` happened to contain on the stack.
+    expect(() =>
+      ffi.runScriptEngine(
+        {} as unknown as number,
+        "%dw 2.0\noutput application/json\n---\n1",
+        "{}"
+      )
+    ).toThrow();
+
+    expect(() =>
+      ffi.runScriptStreamingEngine(
+        {} as unknown as number,
+        "%dw 2.0\noutput application/json\n---\n1",
+        "{}",
+        () => {}
+      )
+    ).toThrow();
+
+    expect(() =>
+      ffi.runScriptTransformEngine(
+        {} as unknown as number,
+        "output application/json\n---\npayload",
+        "{}",
+        "payload",
+        "application/json",
+        null,
+        () => null,
+        () => {}
+      )
+    ).toThrow();
+  });
+});
diff --git a/native-lib/node/tests/integration/independent-engines.test.ts b/native-lib/node/tests/integration/independent-engines.test.ts
new file mode 100644
index 00000000..6dfdc7f9
--- /dev/null
+++ b/native-lib/node/tests/integration/independent-engines.test.ts
@@ -0,0 +1,108 @@
+import { describe, it, expect, afterAll } from "vitest";
+import { DataWeave, cleanup } from "../../src/dataweave";
+import { modulesFromMap } from "../../src/resolver";
+
+const instances: DataWeave[] = [];
+function tracked(...args: ConstructorParameters<typeof DataWeave>): DataWeave {
+  const dw = new DataWeave(...args);
+  instances.push(dw);
+  return dw;
+}
+afterAll(async () => {
+  for (const dw of instances) await dw.cleanup();
+  await cleanup();
+});
+
+const scriptImporting = (mod: string) =>
+  `%dw 2.0\nimport org::test::${mod}\noutput application/json\n---\n${mod}::greet("X")`;
+
+describe("independent engines (W-23692110)", () => {
+  it("two instances resolve only their OWN module, with no cross-talk", () => {
+    const dwA = tracked({ resolveModule: modulesFromMap({
+      "org/test/a.dwl": '%dw 2.0\nfun greet(n: String) = "A:" ++ n' }) });
+    const dwB = tracked({ resolveModule: modulesFromMap({
+      "org/test/b.dwl": '%dw 2.0\nfun greet(n: String) = "B:" ++ n' }) });
+    dwA.initialize();
+    dwB.initialize();
+
+    expect(JSON.parse(dwA.run(scriptImporting("a")).getString()!)).toBe("A:X");
+    expect(JSON.parse(dwB.run(scriptImporting("b")).getString()!)).toBe("B:X");
+
+    // Each engine misses the other's module.
+    expect(dwA.run(scriptImporting("b")).success).toBe(false);
+    expect(dwB.run(scriptImporting("a")).success).toBe(false);
+  });
+
+  it("built-in modules resolve in a resolver-backed engine", () => {
+    const dw = tracked({ resolveModule: modulesFromMap({ "x.dwl": "..." }) });
+    dw.initialize();
+    const r = dw.run('%dw 2.0\nimport dw::core::Strings\noutput application/json\n---\nStrings::capitalize("hello")');
+    expect(r.success).toBe(true);
+    expect(JSON.parse(r.getString()!)).toBe("Hello");
+  });
+
+  // Carried forward from Task 3's review: runScriptEngine now returns "" (not
+  // a thrown error) for a NULL native result, pushing error interpretation
+  // entirely to parseNativeResponse() in this TS layer. A genuine script
+  // error (as opposed to a NULL/empty native response) must still surface as
+  // an ordinary unsuccessful ExecutionResult through the new handle-based
+  // path -- not an unhandled parse exception or process crash.
+  it("a genuine script error on a resolver-backed engine surfaces as success:false, not a throw", () => {
+    const dw = tracked({ resolveModule: modulesFromMap({ "x.dwl": "..." }) });
+    dw.initialize();
+
+    let result: ReturnType<DataWeave["run"]> | undefined;
+    expect(() => { result = dw.run("invalid_var_xyz"); }).not.toThrow();
+    expect(result!.success).toBe(false);
+    expect(result!.error).toBeTruthy();
+  });
+
+  // Confirms addon.c's argument-shifted runScriptStreamingEngine wiring (handle
+  // as first argument, per Task 3) actually threads the handle through to a
+  // real per-engine streaming run, not just the non-streaming run() path
+  // exercised above. Uses a built-in import (not a custom resolver module):
+  // runStreaming's native call executes on a background uv_thread whose
+  // identity differs from the engine's owner thread, so a resolver-backed
+  // engine fails closed for *custom* modules over streaming by design (see
+  // dataweave-resolver.test.ts) -- that's not what this test is checking.
+  it("runStreaming produces output on its own resolver-backed engine", async () => {
+    const dw = tracked({ resolveModule: modulesFromMap({ "x.dwl": "..." }) });
+    dw.initialize();
+
+    const chunks: Buffer[] = [];
+    const gen = dw.runStreaming(
+      '%dw 2.0\nimport dw::core::Strings\noutput application/json\n---\nStrings::capitalize("stream")'
+    );
+    let result = await gen.next();
+    while (!result.done) {
+      chunks.push(result.value);
+      result = await gen.next();
+    }
+    const metadata = result.value;
+
+    expect(metadata.success).toBe(true);
+    expect(JSON.parse(Buffer.concat(chunks).toString("utf-8"))).toBe("Stream");
+  });
+
+  // Confirms addon.c's argument-shifted runScriptTransformEngine wiring
+  // likewise threads the handle through to a real per-engine transform run.
+  it("runTransform produces output on its own resolver-backed engine", async () => {
+    const dw = tracked({ resolveModule: modulesFromMap({ "x.dwl": "..." }) });
+    dw.initialize();
+
+    const inputData = [Buffer.from("[1, 2, 3]")];
+    const script = "output application/json\n---\npayload map ($ * 10)";
+
+    const chunks: Buffer[] = [];
+    const gen = dw.runTransform(script, inputData, { mimeType: "application/json" });
+    let result = await gen.next();
+    while (!result.done) {
+      chunks.push(result.value);
+      result = await gen.next();
+    }
+    const metadata = result.value;
+
+    expect(metadata.success).toBe(true);
+    expect(JSON.parse(Buffer.concat(chunks).toString("utf-8"))).toEqual([10, 20, 30]);
+  });
+});
diff --git a/native-lib/node/tests/integration/instance-lifecycle.test.ts b/native-lib/node/tests/integration/instance-lifecycle.test.ts
new file mode 100644
index 00000000..ee1a1675
--- /dev/null
+++ b/native-lib/node/tests/integration/instance-lifecycle.test.ts
@@ -0,0 +1,226 @@
+import { describe, it, expect, afterEach } from "vitest";
+import { DataWeave, run, cleanup } from "../../src/dataweave";
+import { DataWeaveError } from "../../src/errors";
+import * as ffi from "../../src/ffi";
+import { findLibrary, buildInputsJson } from "../../src/utils";
+
+// Same-instance lifecycle regression tests (round 6, W-23692110). Round 5's
+// coverage used a second instance; the same-instance cleanup window is exactly
+// what findings #1 and #3 exploit. Real addon, no mocking.
+describe("instance lifecycle during cleanup (round 6)", () => {
+  let dw: DataWeave | undefined;
+  afterEach(async () => {
+    // Whatever state each test leaves it in, drain and release so the shared
+    // process-wide isolate is clean for sibling tests.
+    if (dw) {
+      try { await dw.cleanup(); } catch { /* already released */ }
+      dw = undefined;
+    }
+  });
+
+  // Finding #3: initialize() during the same instance's pending cleanup must
+  // reject deterministically, not be a silent no-op that leaves the instance
+  // uninitialized after cleanup settles.
+  it("initialize() during pending cleanup throws, and re-init works after cleanup settles", async () => {
+    dw = new DataWeave();
+    dw.initialize();
+    const closing = dw.cleanup(); // not awaited: instance is now "cleaning-up"
+    expect(() => dw!.initialize()).toThrow(DataWeaveError);
+    expect(() => dw!.initialize()).toThrow(/cleanup is in progress/i);
+    await closing; // now "uninitialized"
+    // Explicit re-init now succeeds and the instance is usable again.
+    dw.initialize();
+    const r = dw.run("%dw 2.0\noutput application/json\n---\n1 + 1");
+    expect(r.success).toBe(true);
+    expect(JSON.parse(r.getString()!)).toBe(2);
+  });
+
+  // Finding #1: run() during the cleanup window must throw a clean DataWeaveError
+  // (never send a null handle to C), because doCleanup() nulls engineHandle
+  // synchronously before awaiting native cleanup.
+  it("run() during pending cleanup throws DataWeaveError, not a native/null-handle error", async () => {
+    dw = new DataWeave();
+    dw.initialize();
+    const closing = dw.cleanup();
+    expect(() => dw!.run("%dw 2.0\noutput application/json\n---\n1")).toThrow(DataWeaveError);
+    expect(() => dw!.run("%dw 2.0\noutput application/json\n---\n1")).toThrow(/cleaning up/i);
+    await closing;
+  });
+
+  // Finding #1, streaming/transform variants: the async generators must reject
+  // on first pull when started during the cleanup window.
+  it("runStreaming()/runTransform() during pending cleanup reject on first pull", async () => {
+    dw = new DataWeave();
+    dw.initialize();
+    const closing = dw.cleanup();
+
+    const sgen = dw.runStreaming("%dw 2.0\noutput application/json\n---\n[1,2,3]");
+    await expect(sgen.next()).rejects.toThrow(DataWeaveError);
+
+    const tgen = dw.runTransform(
+      "output application/json\n---\npayload",
+      [Buffer.from("[1,2,3]")],
+      { mimeType: "application/json" }
+    );
+    await expect(tgen.next()).rejects.toThrow(DataWeaveError);
+
+    await closing;
+  });
+
+  // Idempotency preserved: cleanup() before initialize() is a no-op; double
+  // cleanup() coalesces (round-4 F1 must survive this refactor).
+  it("cleanup() is a no-op when uninitialized and coalesces when called twice", async () => {
+    dw = new DataWeave();
+    await expect(dw.cleanup()).resolves.toBeUndefined(); // uninitialized no-op
+    dw.initialize();
+    const a = dw.cleanup();
+    const b = dw.cleanup(); // must return the same in-flight settlement, one native teardown
+    await Promise.all([a, b]);
+  });
+});
+
+// Round 12, Task 1: napi_cleanup's Case 1..5 decrement-and-teardown body was
+// lifted verbatim into release_isolate_ref_locked() so a later task (round-12
+// #2) can reuse it from the abandoned-env path. This is a behavior-preserving
+// refactor; this test pins the observable contract it must not disturb: the
+// balancing cleanup() call that drops the ref count to zero must actually
+// tear the isolate down synchronously, not leave it silently live.
+//
+// Driven through the raw `ffi` boundary (like handle-validation.test.ts and
+// engine-handle-contract.test.ts), with a balanced initialize()/cleanup()
+// pair, so this file doesn't leak a ref-count bump into sibling integration
+// test files sharing the same vitest worker process.
+describe("napi_cleanup refactor preserves last-release teardown (round 12 Task 1)", () => {
+  it("the balancing cleanup() actually tears the isolate down (subsequent engine call sees not-initialized)", async () => {
+    ffi.initialize(findLibrary());
+    const h = ffi.createEngine();
+    const envelope = JSON.parse(
+      ffi.runScriptEngine(h, "%dw 2.0\noutput application/json\n---\n1 + 1", buildInputsJson({}))
+    );
+    expect(envelope.success).toBe(true);
+    expect(JSON.parse(Buffer.from(envelope.result, "base64").toString("utf-8"))).toBe(2);
+    ffi.destroyEngine(h);
+    await ffi.cleanup();
+    // Ref count reached 0 and the isolate was torn down: a fresh engine call
+    // must observe "not initialized", not silently run on a live isolate.
+    expect(() =>
+      ffi.runScriptEngine(Number.MAX_SAFE_INTEGER, "%dw 2.0\noutput application/json\n---\n1", buildInputsJson({}))
+    ).toThrow(/not initialized/i);
+  });
+});
+
+// Round 12, Task 4: createChunkReader pre-buffers async inputs by awaiting
+// the entire iterable up front (see reader.ts), because the native read
+// callback is invoked synchronously and cannot await. That await can span
+// arbitrarily long, so if the caller cleans up the instance while it's in
+// flight, runTransform must re-check readiness on resume rather than
+// dispatching to a nulled/destroyed engine handle.
+describe("runTransform re-checks readiness after async input pre-buffering (round 12 Task 4)", () => {
+  it("throws a synchronous DataWeaveError if cleanup() runs during createChunkReader's await, instead of resolving an error envelope", async () => {
+    const dw = new DataWeave();
+    dw.initialize();
+
+    // An async input whose iterator blocks until released, so cleanup() can
+    // run while createChunkReader is still pre-buffering it.
+    let release!: () => void;
+    const gate = new Promise<void>((r) => { release = r; });
+    async function* slowInput(): AsyncGenerator<Buffer> {
+      await gate;
+      yield Buffer.from("[1,2,3]");
+    }
+
+    const gen = dw.runTransform("%dw 2.0\noutput application/json\n---\npayload", slowInput(), {
+      mimeType: "application/json",
+    });
+
+    // Start driving the generator; it suspends awaiting createChunkReader ->
+    // slowInput's gate.
+    const firstNext = gen.next();
+    // Clean up while the input is still pre-buffering.
+    await dw.cleanup();
+    // Release the gate so createChunkReader's await resolves; the readiness
+    // re-check must now throw synchronously rather than proceeding to a
+    // nulled engine handle.
+    release();
+
+    await expect(firstNext).rejects.toBeInstanceOf(DataWeaveError);
+  });
+});
+
+// Round 12, Task 6: the exported module-level cleanup() nulls globalInstance
+// synchronously, then awaits instance.cleanup(). A second overlapping
+// module-level cleanup() call must coalesce onto the SAME in-flight drain
+// rather than seeing globalInstance already nulled and resolving immediately
+// -- before the first call's native teardown actually finishes.
+describe("module-level cleanup() coalescing (round 12 Task 6)", () => {
+  it("module-level cleanup() coalesces overlapping calls (round 12 #5)", async () => {
+    // Create the singleton.
+    expect(run("%dw 2.0\noutput application/json\n---\n1 + 1").success).toBe(true);
+
+    let firstSettled = false;
+    const p1 = cleanup().then(() => { firstSettled = true; });
+    // Second call overlaps the first's in-flight drain.
+    const p2 = cleanup();
+    // The coalesced second call must not resolve before the first's drain does.
+    await p2;
+    expect(firstSettled).toBe(true);
+    await p1;
+
+    // A subsequent run lazily revives the singleton (no wedged state).
+    expect(run("%dw 2.0\noutput application/json\n---\n2 + 2").success).toBe(true);
+    await cleanup();
+  });
+});
+
+// Final review round 12 #1: Task 6's coalescing guard (`if (cleanupPromise)
+// return cleanupPromise;`) is unconditional, so a caller that revives the
+// singleton (via run()) while an OLDER drain is still in flight gets the OLD
+// drain's promise handed back by the newer cleanup() call -- the freshly
+// revived instance is never hooked up to any doCleanup()/ffi.cleanup() call
+// and its native ref leaks for the rest of the process. Pinned via the same
+// ref-count proxy as the "napi_cleanup refactor" test above: after both
+// cleanup() calls settle, the isolate's ref count must have actually returned
+// to zero (not be left at 1 by a leaked, unrevived-then-abandoned instance).
+describe("module-level cleanup() does not orphan a revived singleton (final review round 12 #1)", () => {
+  it("cleanup() started during an in-flight drain cleans the CURRENT (revived) singleton, not the stale one", async () => {
+    // (a) Create the singleton (instance A).
+    expect(run("%dw 2.0\noutput application/json\n---\n1 + 1").success).toBe(true);
+
+    // (b) Start draining A WITHOUT awaiting.
+    const p1 = cleanup();
+
+    // (c) Revive a FRESH singleton (instance B) while A's drain is in flight.
+    expect(run("%dw 2.0\noutput application/json\n---\n2 + 2").success).toBe(true);
+
+    // (d) Call cleanup() again. Under the bug this returns p1 verbatim,
+    // leaving B's native ref uncleaned once both promises settle.
+    const p2 = cleanup();
+    await Promise.all([p1, p2]);
+
+    // (e) Prove B was actually torn down via the isolate's ref count, the same
+    // technique as "napi_cleanup refactor preserves last-release teardown"
+    // above: do one extra balanced initialize()/cleanup() pair. If the ref
+    // count was already back to zero (both A and B cleaned), this nets back
+    // to zero and a subsequent raw engine call observes "not initialized". If
+    // B's ref instead leaked, the ref count is already >=1 going into this
+    // balanced pair, so it nets to >=1 afterward and the isolate stays alive
+    // -- the subsequent call would NOT report "not initialized".
+    ffi.initialize(findLibrary());
+    const h = ffi.createEngine();
+    const envelope = JSON.parse(
+      ffi.runScriptEngine(h, "%dw 2.0\noutput application/json\n---\n5 + 5", buildInputsJson({}))
+    );
+    expect(envelope.success).toBe(true);
+    expect(JSON.parse(Buffer.from(envelope.result, "base64").toString("utf-8"))).toBe(10);
+    ffi.destroyEngine(h);
+    await ffi.cleanup(); // Balances the initialize() just above, ONLY.
+
+    expect(() =>
+      ffi.runScriptEngine(Number.MAX_SAFE_INTEGER, "%dw 2.0\noutput application/json\n---\n1", buildInputsJson({}))
+    ).toThrow(/not initialized/i);
+
+    // The singleton revives cleanly again afterward -- no wedged module state.
+    expect(run("%dw 2.0\noutput application/json\n---\n3 + 3").success).toBe(true);
+    await cleanup();
+  });
+});
diff --git a/native-lib/node/tests/integration/malformed-inputs.test.ts b/native-lib/node/tests/integration/malformed-inputs.test.ts
new file mode 100644
index 00000000..3deae4c7
--- /dev/null
+++ b/native-lib/node/tests/integration/malformed-inputs.test.ts
@@ -0,0 +1,70 @@
+import { describe, it, expect, afterEach } from "vitest";
+import * as ffi from "../../src/ffi";
+import { findLibrary, buildInputsJson } from "../../src/utils";
+
+// Round-7 finding #2 (whole-class sweep): every FFI-facing entrypoint must
+// check the status of each napi_get_value_* conversion and throw before using
+// the converted value. Pre-fix, non-string script/inputs left *_len
+// uninitialized before malloc(len+1) and the buffer write, and destroyEngine
+// used an indeterminate handle64 from an ignored napi_get_value_int64.
+//
+// Driven through the raw `ffi` boundary (the DataWeave TS class always passes
+// well-typed values), so these calls exercise the C conversion checks directly.
+// The addon globals are process-wide C statics -- balance every initialize()
+// with a cleanup() so this file does not leak a ref-count into siblings.
+//
+// Real addon, no mocking.
+describe("malformed raw-ffi inputs throw (round 7 #2)", () => {
+  afterEach(async () => {
+    await ffi.cleanup();
+  });
+
+  it("destroyEngine throws on a non-integer handle", () => {
+    ffi.initialize(findLibrary());
+    expect(() => ffi.destroyEngine({} as unknown as number)).toThrow();
+  });
+
+  it("runScriptEngine throws on non-string script/inputs", () => {
+    ffi.initialize(findLibrary());
+    const handle = ffi.createEngine();
+    expect(() =>
+      ffi.runScriptEngine(handle, {} as unknown as string, buildInputsJson({}))
+    ).toThrow();
+    expect(() =>
+      ffi.runScriptEngine(handle, "%dw 2.0\n---\n1", {} as unknown as string)
+    ).toThrow();
+    ffi.destroyEngine(handle);
+  });
+
+  it("runScriptStreamingEngine throws on non-string script/inputs", () => {
+    ffi.initialize(findLibrary());
+    const handle = ffi.createEngine();
+    expect(() =>
+      ffi.runScriptStreamingEngine(
+        handle,
+        {} as unknown as string,
+        buildInputsJson({}),
+        () => {}
+      )
+    ).toThrow();
+    ffi.destroyEngine(handle);
+  });
+
+  it("runScriptTransformEngine throws on non-string script", () => {
+    ffi.initialize(findLibrary());
+    const handle = ffi.createEngine();
+    expect(() =>
+      ffi.runScriptTransformEngine(
+        handle,
+        {} as unknown as string,
+        "{}",
+        "payload",
+        "application/json",
+        null,
+        () => null,
+        () => {}
+      )
+    ).toThrow();
+    ffi.destroyEngine(handle);
+  });
+});
diff --git a/native-lib/node/tests/integration/run-admission.test.ts b/native-lib/node/tests/integration/run-admission.test.ts
new file mode 100644
index 00000000..88dea6a2
--- /dev/null
+++ b/native-lib/node/tests/integration/run-admission.test.ts
@@ -0,0 +1,93 @@
+import { describe, it, expect } from "vitest";
+import * as ffi from "../../src/ffi";
+import { findLibrary, buildInputsJson } from "../../src/utils";
+
+// Round-7 finding #1: the synchronous napi_run_script_engine touched the
+// isolate (fn_attach_thread -> fn_run_script_engine -> fn_detach_thread) with
+// only a top-of-function !g_initialized fast-path and NO g_active_ops
+// reservation under g_mutex. A second Worker's last cleanup() (napi_cleanup
+// Case 4) could observe g_active_ops == 0 and tear down g_isolate while this
+// op was attaching/executing -- a use-after-free.
+//
+// The genuine cross-Worker TOCTOU is not reliably forceable from single-thread
+// JS (same limitation the round-6 #2 admission-during-teardown test documents:
+// re-init would trigger the adoption path and cancel the pending teardown
+// before the admission check runs). What we CAN assert deterministically is
+// the admission-rejection path the fix introduces: once a teardown is pending
+// (g_teardown_state != TEARDOWN_NONE), a freshly started run() is rejected with
+// a synchronous throw rather than attaching to an isolate a concurrent teardown
+// could pull out from under it. The C-level reasoning -- check-and-reserve is
+// now one atomic critical section on the run() path -- is what covers the race
+// itself.
+//
+// We drive the addon through the raw `ffi` module (not the module-level
+// singleton) so the second op runs against the SAME still-live handle/isolate
+// with no intervening ffi.initialize() call to trigger adoption. Calling
+// ffi.cleanup() directly triggers napi_cleanup Case 5 and sets
+// g_teardown_state = TEARDOWN_PENDING_WAIT synchronously, before its Promise is
+// returned; the immediately-following ffi.runScriptEngine re-enters native code
+// synchronously on the same callstack and deterministically observes it.
+//
+// Real addon, no mocking.
+describe("run() admission rejected while teardown pending (round 7 #1)", () => {
+  it("a synchronous run() started during pending teardown throws, not attach to a dead isolate", async () => {
+    ffi.initialize(findLibrary());
+    const handle = ffi.createEngine();
+
+    // Keep one op in flight so the ref release becomes Case 5 (pending
+    // teardown) rather than Case 4 (immediate teardown): use a transform whose
+    // read callback triggers cleanup() and then attempts a run() on the same
+    // handle, all on the same synchronous callstack.
+    let cleanupPromise: Promise<void> | undefined;
+    let runErr: unknown;
+    let ran = false;
+
+    let firstRead = true;
+    const readCb = (_bufSize: number): Buffer | null => {
+      if (firstRead) {
+        firstRead = false;
+        // Case 5: last ref release with g_active_ops > 0 -> TEARDOWN_PENDING_WAIT,
+        // set synchronously before this returns. Not awaited.
+        cleanupPromise = ffi.cleanup();
+        // Synchronous run() on the same still-live handle while teardown is
+        // pending. Fixed code rejects admission with a synchronous throw
+        // (g_teardown_state != TEARDOWN_NONE). Must be caught here -- it is a
+        // synchronous throw, not a rejected promise. Do not let it escape the
+        // native read-callback body.
+        try {
+          ffi.runScriptEngine(
+            handle,
+            "%dw 2.0\noutput application/json\n---\n1 + 1",
+            buildInputsJson({})
+          );
+          ran = true;
+        } catch (e) {
+          runErr = e;
+        }
+        return Buffer.from("[1,2,3]");
+      }
+      return null;
+    };
+
+    const writeCb = (_chunk: Buffer) => {};
+
+    const resultRaw = await ffi.runScriptTransformEngine(
+      handle,
+      "output application/json\n---\npayload",
+      "{}",
+      "payload",
+      "application/json",
+      null,
+      readCb,
+      writeCb
+    );
+    const result = JSON.parse(resultRaw);
+    expect(result.success).toBe(true);
+
+    await cleanupPromise;
+
+    // run() started while teardown was pending must have been rejected.
+    expect(runErr).toBeTruthy();
+    expect(ran).toBe(false);
+  }, 20000);
+});
diff --git a/native-lib/node/tests/integration/teardown-deadlock.test.ts b/native-lib/node/tests/integration/teardown-deadlock.test.ts
new file mode 100644
index 00000000..efa44cec
--- /dev/null
+++ b/native-lib/node/tests/integration/teardown-deadlock.test.ts
@@ -0,0 +1,120 @@
+import { describe, it, expect } from "vitest";
+import { run, runTransform, cleanup } from "../../src/dataweave";
+
+// Regression test for W-23692110 round 5 (Task 1 fix in native-lib/node/src/addon.c).
+//
+// Bug: napi_initialize used to block the JS thread forever whenever it ran
+// while a teardown was pending on the shared native isolate and a
+// streaming/transform op was still active elsewhere -- because draining that
+// active op can need the very same JS thread napi_initialize was blocking.
+// The fix makes napi_initialize adopt the still-live isolate instead of
+// waiting, in the window before the teardown waiter thread commits to
+// physical teardown.
+//
+// This loads the REAL native addon (no `vi.mock` of ffi) -- the deadlock is
+// entirely in C and cannot be reproduced at the mocked-ffi layer.
+//
+// Why runTransform (not runStreaming) drives this repro: runStreaming's
+// output-chunk delivery uses an unbounded napi_threadsafe_function queue, and
+// g_active_ops is decremented on the background worker thread right after it
+// detaches from the isolate -- independent of whether the JS event loop ever
+// turns. So a blocked JS thread does NOT stop a runStreaming() op from
+// draining; there is no genuine circular wait on that path (verified
+// empirically: the brief's originally-suggested runStreaming shape resolves
+// promptly even against pre-Task-1 addon.c, because an earlier round already
+// moved that decrement off the JS thread -- see commit ac8d520).
+//
+// runTransform's INPUT side is different: transform_read_cb (addon.c) calls
+// napi_call_threadsafe_function(w->read_tsfn, &req, napi_tsfn_blocking) and
+// then genuinely blocks the background worker thread on a condition variable
+// until call_js_read runs on the JS thread and signals it. That JS-thread
+// callback synchronously invokes our JS read callback (a plain
+// Iterable<Buffer> consumed by a sync generator) via napi_call_function --
+// so firing cleanup() and a concurrent run() from *inside* that generator
+// deterministically executes them while the background worker is attached
+// and blocked waiting for this exact call to return. No timing assumptions
+// (no setTimeout/microtask races) are needed: the call graph itself
+// guarantees the ordering "worker attached and mid-read" -> "cleanup()
+// fired" -> "run() fired", all on the JS thread, before the generator call
+// returns and the worker can proceed.
+describe("re-init during pending teardown (W-23692110, round 5 P1)", () => {
+  // On the UNFIXED addon.c this deadlocks for real: the JS thread never
+  // returns from run()'s napi_initialize (blocked waiting for g_active_ops to
+  // drain), so the background transform worker -- itself blocked waiting for
+  // the JS thread to service its read callback -- can never proceed either.
+  // Vitest kills the test at the timeout below, a bounded/deterministic red.
+  // On the fixed code, napi_initialize adopts the still-live isolate and
+  // run() returns promptly, letting everything drain normally.
+  it(
+    "module-level cleanup() during an active transform read does not deadlock a concurrent run()",
+    async () => {
+      let fired = false;
+      let cleanupPromise: Promise<void> | undefined;
+      let runResult: ReturnType<typeof run> | undefined;
+      let runError: unknown;
+
+      // Large enough that, at the moment of the very first read pull, the
+      // vast majority of reads (and thus the transform op) are still
+      // genuinely ahead -- not a timing-sensitive assumption, since the
+      // trigger below fires unconditionally on the first pull regardless of
+      // how many total reads there are.
+      const totalReads = 200000;
+
+      function* input(): Generator<Buffer> {
+        for (let i = 0; i < totalReads; i++) {
+          if (!fired) {
+            fired = true;
+            // We are executing synchronously inside the native read
+            // callback (call_js_read in addon.c), on the JS thread, while
+            // the background transform worker thread is blocked inside
+            // transform_read_cb waiting for this exact call to return.
+            // Deliberately do NOT await cleanup() here, and do NOT let an
+            // assertion throw from inside this generator -- a thrown
+            // exception here would be caught by the native read-callback
+            // wrapper and reinterpreted as a read error, silently masking a
+            // real assertion failure instead of surfacing it as a test
+            // failure. Capture results and assert on them after the
+            // generator (and the transform) have fully drained.
+            cleanupPromise = cleanup();
+            try {
+              runResult = run('%dw 2.0\noutput application/json\n---\n1 + 1');
+            } catch (e) {
+              runError = e;
+            }
+          }
+          yield Buffer.from("x");
+        }
+      }
+
+      const gen = runTransform(
+        "output application/octet-stream\n---\npayload",
+        input(),
+        { mimeType: "application/octet-stream" }
+      );
+
+      // Drain the whole transform. On unfixed code, execution never reaches
+      // here: the trigger inside input() already froze the JS thread
+      // forever before the first read even returns.
+      let result = await gen.next();
+      while (!result.done) {
+        result = await gen.next();
+      }
+
+      expect(fired).toBe(true);
+      expect(runError).toBeUndefined();
+      expect(runResult?.success).toBe(true);
+      expect(JSON.parse(runResult!.getString()!)).toBe(2);
+      expect(result.value.success).toBe(true);
+
+      // Let both the deferred teardown/cleanup and this test settle cleanly.
+      // This is essential: the process shares one native isolate across all
+      // integration test files, so leaving an unresolved cleanup here would
+      // perturb sibling test files.
+      await cleanupPromise;
+      // Idempotent final cleanup: a no-op if the singleton is already fully
+      // released, leaving the module in a clean state for subsequent tests.
+      await cleanup();
+    },
+    20000
+  );
+});
diff --git a/native-lib/node/tests/integration/worker-lifecycle.test.ts b/native-lib/node/tests/integration/worker-lifecycle.test.ts
new file mode 100644
index 00000000..b5c757e4
--- /dev/null
+++ b/native-lib/node/tests/integration/worker-lifecycle.test.ts
@@ -0,0 +1,293 @@
+import { describe, it, expect, afterAll } from "vitest";
+import { Worker } from "node:worker_threads";
+import { join } from "node:path";
+import * as ffi from "../../src/ffi";
+import { findLibrary, buildInputsJson } from "../../src/utils";
+
+// W-23692110 round 12 #9: real worker_threads coverage for the documented
+// per-Worker engine model (README "Custom module resolvers and Worker threads").
+//
+// Workers cannot execute the TS sources (npm test runs vitest with no build for
+// worker code, and a Worker spawns a fresh Node runtime), so each worker body is
+// an inline JS string (eval:true) that require()s the BUILT addon directly --
+// the same raw-addon boundary engine-handle-contract.test.ts drives. addonPath
+// and the dwlib path are resolved on the main thread and passed via workerData.
+//
+// Determinism posture: exact cross-thread teardown interleavings are NOT
+// deterministically forceable (best-effort, matching rounds 5-11). The
+// deterministic assertions here are: resolver-backed/less engines produce
+// correct output inside a Worker, and after N Worker create/exit-without-
+// cleanup() cycles the main thread still initializes/runs and the final
+// teardown is clean (the round-12 #2 behavioral proof).
+
+const ADDON_PATH = join(__dirname, "..", "..", "build", "Release", "dwlib_addon.node");
+const LIB_PATH = findLibrary();
+
+// Runs one Worker to completion and returns its posted message. `mode` selects
+// resolver-backed vs resolver-less and whether the Worker cleans up or abandons.
+function runWorker(opts: {
+  mode: "resolver" | "plain";
+  cleanup: boolean;
+  script: string;
+}): Promise<{ ok: boolean; output?: string; error?: string }> {
+  const body = `
+    const { parentPort, workerData } = require('node:worker_threads');
+    (async () => {
+      const addon = require(workerData.addonPath);
+      addon.initialize(workerData.libPath);
+      let handle;
+      if (workerData.mode === 'resolver') {
+        const resolver = (modulePath) =>
+          modulePath === 'org/test/w.dwl'
+            ? '%dw 2.0\\nfun greet(n) = "W:" ++ n'
+            : null;
+        handle = addon.createEngineWithResolver(resolver);
+      } else {
+        handle = addon.createEngine();
+      }
+      let msg;
+      try {
+        const raw = addon.runScriptEngine(handle, workerData.script, '{}');
+        const parsed = JSON.parse(raw);
+        if (parsed.success === false) {
+          msg = { ok: false, error: parsed.error };
+        } else {
+          // Non-streaming engine result carries base64 'result'; decode it.
+          const out = parsed.result ? Buffer.from(parsed.result, 'base64').toString('utf-8') : '';
+          msg = { ok: true, output: out };
+        }
+      } catch (e) {
+        msg = { ok: false, error: String(e) };
+      }
+      if (workerData.cleanup) {
+        let destroyErr;
+        try {
+          addon.destroyEngine(handle);
+        } catch (e) {
+          destroyErr = e; // preserve; do NOT let cleanup() mask a broken destroy
+        } finally {
+          await addon.cleanup();
+        }
+        if (destroyErr) msg = { ok: false, error: 'destroyEngine failed: ' + String(destroyErr) };
+      }
+      parentPort.postMessage(msg);
+      // For the abandon variant we deliberately return WITHOUT cleanup so the
+      // env cleanup hook fires as the Worker env tears down.
+    })().catch((e) => { parentPort.postMessage({ ok: false, error: String(e) }); });
+  `;
+  return new Promise((resolve, reject) => {
+    const w = new Worker(body, {
+      eval: true,
+      workerData: { addonPath: ADDON_PATH, libPath: LIB_PATH, mode: opts.mode, cleanup: opts.cleanup, script: opts.script },
+    });
+    let msg: { ok: boolean; output?: string; error?: string } | undefined;
+    w.once("message", (m) => { msg = m; });
+    w.once("error", reject);
+    // Resolve only on a CLEAN exit that posted a result. A Worker can post a
+    // success message and THEN exit nonzero (e.g. an env-cleanup-hook failure
+    // during teardown) -- resolving on the message alone would hide that. So
+    // wait for exit: reject every nonzero code, and treat a zero exit with no
+    // posted message as its own diagnosable failure (round-14 #5).
+    w.once("exit", (code) => {
+      if (code !== 0) {
+        reject(new Error("Worker exited with code " + code + (msg ? "" : " and posted no message")));
+      } else if (msg === undefined) {
+        reject(new Error("Worker exited 0 without posting a result"));
+      } else {
+        resolve(msg);
+      }
+    });
+  });
+}
+
+describe("worker_threads engine lifecycle (round 12 #9)", () => {
+  afterAll(async () => {
+    // Final main-thread balancing cleanup so this file does not perturb sibling
+    // integration files sharing the vitest worker process.
+    await ffi.cleanup();
+  });
+
+  it("a resolver-backed engine in a Worker resolves the Worker's own module", async () => {
+    const script = "%dw 2.0\nimport org::test::w\noutput application/json\n---\nw::greet(\"X\")";
+    const msg = await runWorker({ mode: "resolver", cleanup: true, script });
+    expect(msg.ok).toBe(true);
+    expect(JSON.parse(msg.output!)).toBe("W:X");
+  });
+
+  it("a resolver-less engine in a Worker runs a plain script", async () => {
+    const script = "%dw 2.0\noutput application/json\n---\n6 * 7";
+    const msg = await runWorker({ mode: "plain", cleanup: true, script });
+    expect(msg.ok).toBe(true);
+    expect(JSON.parse(msg.output!)).toBe(42);
+  });
+
+  it("built-in modules resolve in a resolver-backed engine inside a Worker", async () => {
+    const script =
+      "%dw 2.0\nimport dw::core::Strings\noutput application/json\n---\nStrings::capitalize(\"hello\")";
+    const msg = await runWorker({ mode: "resolver", cleanup: true, script });
+    expect(msg.ok).toBe(true);
+    expect(JSON.parse(msg.output!)).toBe("Hello");
+  });
+
+  it("N Workers that exit WITHOUT cleanup() do not wedge the isolate; main thread stays healthy (round 12 #2)", async () => {
+    const CYCLES = 5;
+    for (let i = 0; i < CYCLES; i++) {
+      const msg = await runWorker({
+        mode: "resolver",
+        cleanup: false, // exit without cleanup -> env cleanup hook fires
+        script: "%dw 2.0\noutput application/json\n---\n" + i,
+      });
+      expect(msg.ok).toBe(true);
+    }
+    // After all those abandoned Workers, the main thread must still initialize
+    // and run. Pre-fix, each abandoned Worker leaked its init reference and the
+    // isolate never returned to zero; the assertion here is behavioral (the
+    // process is not wedged and cleanup still tears down cleanly at afterAll).
+    ffi.initialize(LIB_PATH);
+    const h = ffi.createEngine();
+    const envelope = JSON.parse(
+      ffi.runScriptEngine(h, "%dw 2.0\noutput application/json\n---\n1 + 1", buildInputsJson({}))
+    );
+    expect(envelope.success).toBe(true);
+    expect(JSON.parse(Buffer.from(envelope.result, "base64").toString("utf-8"))).toBe(2);
+    ffi.destroyEngine(h);
+    await ffi.cleanup();
+  });
+
+  it("Worker.terminate() mid-life leaves the main thread able to initialize and run", async () => {
+    const body = `
+      const { parentPort, workerData } = require('node:worker_threads');
+      const addon = require(workerData.addonPath);
+      addon.initialize(workerData.libPath);
+      addon.createEngineWithResolver((p) => null);
+      // Signal readiness only once the engine is actually live, so the parent
+      // terminates a worker that genuinely has a live engine rather than
+      // racing a fixed sleep against initialize()/createEngineWithResolver on
+      // a possibly-loaded box (final review round 12 #3).
+      parentPort.postMessage('ready');
+      // Spin so the parent can terminate() us mid-life (no message posted).
+      setInterval(() => {}, 10);
+    `;
+    const w = new Worker(body, {
+      eval: true,
+      workerData: { addonPath: ADDON_PATH, libPath: LIB_PATH },
+    });
+    // A throw in the worker body (e.g. a bad addon path) must fail this test
+    // cleanly rather than crash the vitest process -- the ad hoc Worker here,
+    // unlike runWorker() above, previously had no error listener wired up
+    // (final review round 12 #2).
+    const workerError = new Promise<never>((_, reject) => w.once("error", reject));
+    // Avoid an unhandled-rejection warning if "error" fires (or would fire)
+    // after the race below has already settled via the "ready" path.
+    workerError.catch(() => {});
+    // Wait for the worker to report the engine is live, racing against a
+    // generous timeout so a slow box doesn't false-fail this test, then
+    // terminate abruptly.
+    const ready = new Promise<void>((resolve) => w.once("message", (m) => { if (m === "ready") resolve(); }));
+    await Promise.race([
+      ready,
+      workerError,
+      new Promise((_, reject) => setTimeout(() => reject(new Error("worker did not signal ready in time")), 10000)),
+    ]);
+    await w.terminate();
+
+    ffi.initialize(LIB_PATH);
+    const h = ffi.createEngine();
+    const envelope = JSON.parse(
+      ffi.runScriptEngine(h, "%dw 2.0\noutput application/json\n---\n3 + 4", buildInputsJson({}))
+    );
+    expect(envelope.success).toBe(true);
+    expect(JSON.parse(Buffer.from(envelope.result, "base64").toString("utf-8"))).toBe(7);
+    ffi.destroyEngine(h);
+    await ffi.cleanup();
+  });
+
+  it("a Worker that inits once + creates N engines + exits without cleanup() does NOT tear down the isolate under a live main engine (round 13 #5)", async () => {
+    // This is the cross-env regression the round-13 smoke tests could not pin
+    // (env-init-ownership.test.ts is single-env). It fails RED on the round-12
+    // implementation: the Worker's env death fired N per-engine init-reference
+    // releases against the ONE reference the Worker owned, driving g_ref_count to
+    // zero and tearing the shared isolate down under the live main engine -> the
+    // main engine's run below would fail (isolate gone) or the process wedges. On
+    // round-13+ each abandoned env releases exactly one reference regardless of
+    // engine count, so the main engine survives.
+    const N = 3;
+
+    let hMain: number | null = null;
+    try {
+      // 1. Main thread: initialize and keep a live engine.
+      ffi.initialize(LIB_PATH);
+      hMain = ffi.createEngine();
+      const first = JSON.parse(
+        ffi.runScriptEngine(hMain, "%dw 2.0\noutput application/json\n---\n6 * 7", buildInputsJson({}))
+      );
+      expect(first.success).toBe(true);
+      expect(JSON.parse(Buffer.from(first.result, "base64").toString("utf-8"))).toBe(42);
+
+      // 2. Worker: initialize ONCE, create N engines, run one, exit WITHOUT cleanup.
+      const workerBody = `
+        const { parentPort, workerData } = require('node:worker_threads');
+        (async () => {
+          const addon = require(workerData.addonPath);
+          addon.initialize(workerData.libPath); // ONE init reference for this env
+          const handles = [];
+          for (let i = 0; i < workerData.n; i++) handles.push(addon.createEngine());
+          const raw = addon.runScriptEngine(handles[0], workerData.script, '{}');
+          const parsed = JSON.parse(raw);
+          parentPort.postMessage({ ok: parsed.success !== false, count: handles.length });
+          // Return WITHOUT destroyEngine/cleanup: the env dies with N engines under
+          // one init reference -> env_init_cleanup releases exactly ONE reference.
+        })().catch((e) => { parentPort.postMessage({ ok: false, error: String(e) }); });
+      `;
+      const workerMsg = await new Promise<{ ok: boolean; count?: number; error?: string }>((resolve, reject) => {
+        const w = new Worker(workerBody, {
+          eval: true,
+          workerData: {
+            addonPath: ADDON_PATH,
+            libPath: LIB_PATH,
+            n: N,
+            script: "%dw 2.0\noutput application/json\n---\n1 + 1",
+          },
+        });
+        let msg: { ok: boolean; count?: number; error?: string } | undefined;
+        w.once("message", (m) => { msg = m; });
+        w.once("error", reject);
+        // Wait for EXIT (not just message) so the Worker env's death hooks
+        // (env_init_cleanup) have run before we assert the main engine survived.
+        w.once("exit", (code) => {
+          if (code !== 0) reject(new Error("Worker exited with code " + code + (msg ? "" : " and posted no message")));
+          else if (msg === undefined) reject(new Error("Worker exited 0 without posting a result"));
+          else resolve(msg);
+        });
+      });
+      expect(workerMsg.ok).toBe(true);
+      expect(workerMsg.count).toBe(N);
+
+      // 3. The Worker abandoned N engines under one init reference and its env
+      // died. The main engine's reference must be intact and the isolate live.
+      const second = JSON.parse(
+        ffi.runScriptEngine(hMain, "%dw 2.0\noutput application/json\n---\n1 + 1", buildInputsJson({}))
+      );
+      expect(second.success).toBe(true);
+      expect(JSON.parse(Buffer.from(second.result, "base64").toString("utf-8"))).toBe(2);
+
+      // 4. Balance the main reference and prove the count reached exactly zero
+      // (no leak, no over-release): a raw op now throws "not initialized".
+      ffi.destroyEngine(hMain);
+      hMain = null; // destroyed; finally must not double-destroy
+      await ffi.cleanup();
+      expect(() =>
+        ffi.runScriptEngine(Number.MAX_SAFE_INTEGER, "%dw 2.0\noutput application/json\n---\n1", buildInputsJson({}))
+      ).toThrow(/not initialized/i);
+    } finally {
+      // Balance global native state even if a Worker/assertion above threw, so
+      // this test cannot strand a live isolate + held reference for sibling
+      // integration tests (review #6 #7). Best-effort: do not let a cleanup
+      // error mask the original failure.
+      try {
+        if (hMain !== null) ffi.destroyEngine(hMain);
+        await ffi.cleanup();
+      } catch { /* original failure (if any) propagates from the try */ }
+    }
+  }, 20000);
+});
diff --git a/native-lib/node/tests/unit/dataweave-initialize.test.ts b/native-lib/node/tests/unit/dataweave-initialize.test.ts
new file mode 100644
index 00000000..eabc9538
--- /dev/null
+++ b/native-lib/node/tests/unit/dataweave-initialize.test.ts
@@ -0,0 +1,289 @@
+import { describe, it, expect, vi, beforeEach } from "vitest";
+
+// Pure-logic test of DataWeave.initialize()'s lifecycle/error handling, with
+// the native addon mocked out entirely -- no dwlib required (see the "unit"
+// project in vitest.config.ts). This covers a ref-count leak that is only
+// observable in the sequencing of calls into ffi.ts, not in any externally
+// visible native state, so a real end-to-end native failure isn't a
+// practical way to assert on it (see task-4-report.md's fix report for why).
+vi.mock("../../src/ffi", () => ({
+  initialize: vi.fn(),
+  createEngine: vi.fn(),
+  createEngineWithResolver: vi.fn(),
+  destroyEngine: vi.fn(),
+  runScriptEngine: vi.fn(),
+  runScriptStreamingEngine: vi.fn(),
+  runScriptTransformEngine: vi.fn(),
+  cleanup: vi.fn(),
+}));
+
+import * as ffi from "../../src/ffi";
+import { DataWeave, run, cleanup } from "../../src/dataweave";
+import { DataWeaveError } from "../../src/errors";
+
+describe("DataWeave.initialize() native ref-count safety", () => {
+  beforeEach(() => {
+    vi.mocked(ffi.initialize).mockReset();
+    vi.mocked(ffi.createEngine).mockReset();
+    vi.mocked(ffi.createEngineWithResolver).mockReset();
+    vi.mocked(ffi.destroyEngine).mockReset();
+    vi.mocked(ffi.cleanup).mockReset();
+  });
+
+  it("releases the native library ref-count if engine creation fails after ffi.initialize() succeeded", () => {
+    vi.mocked(ffi.initialize).mockImplementation(() => {});
+    vi.mocked(ffi.createEngineWithResolver).mockImplementation(() => {
+      throw new Error("native engine creation boom");
+    });
+
+    const dw = new DataWeave({ libPath: "mock-lib-path", resolveModule: () => null });
+
+    expect(() => dw.initialize()).toThrow(DataWeaveError);
+
+    // ffi.initialize() already succeeded, incrementing the native library's
+    // ref count. Since `initialized` never became true, cleanup()'s
+    // early-return guard means nothing else would ever call ffi.cleanup() --
+    // initialize()'s own catch block must have released it.
+    expect(ffi.cleanup).toHaveBeenCalledTimes(1);
+  });
+
+  it("does not call ffi.cleanup() when ffi.initialize() itself is what fails", () => {
+    vi.mocked(ffi.initialize).mockImplementation(() => {
+      throw new Error("library not found");
+    });
+
+    const dw = new DataWeave({ libPath: "mock-lib-path" });
+
+    expect(() => dw.initialize()).toThrow(DataWeaveError);
+
+    // No ref count was ever acquired, so there is nothing to release.
+    expect(ffi.cleanup).not.toHaveBeenCalled();
+  });
+
+  it("leaves engineHandle unset and the instance cleanly re-initializable after a failed attempt", () => {
+    vi.mocked(ffi.initialize).mockImplementation(() => {});
+    vi.mocked(ffi.createEngine)
+      .mockImplementationOnce(() => {
+        throw new Error("transient native failure");
+      })
+      .mockImplementationOnce(() => 42);
+
+    const dw = new DataWeave({ libPath: "mock-lib-path" });
+
+    expect(() => dw.initialize()).toThrow(DataWeaveError);
+    expect(ffi.cleanup).toHaveBeenCalledTimes(1);
+
+    // A later initialize() call (e.g. once the transient failure clears)
+    // must succeed cleanly -- the failed attempt must not have left the
+    // instance permanently "half-initialized" (this.initialized stuck true
+    // without an engine handle, or vice versa).
+    vi.mocked(ffi.cleanup).mockClear();
+    dw.initialize();
+    expect(ffi.createEngine).toHaveBeenCalledTimes(2);
+
+    dw.cleanup();
+    expect(ffi.destroyEngine).toHaveBeenCalledWith(42);
+    expect(ffi.cleanup).toHaveBeenCalledTimes(1);
+  });
+
+  it("does not call ffi.cleanup() from initialize() on the successful path", () => {
+    vi.mocked(ffi.initialize).mockImplementation(() => {});
+    vi.mocked(ffi.createEngine).mockImplementation(() => 7);
+
+    const dw = new DataWeave({ libPath: "mock-lib-path" });
+    dw.initialize();
+
+    expect(ffi.cleanup).not.toHaveBeenCalled();
+
+    dw.cleanup();
+    expect(ffi.destroyEngine).toHaveBeenCalledWith(7);
+    expect(ffi.cleanup).toHaveBeenCalledTimes(1);
+  });
+
+  it("still clears `initialized` when ffi.cleanup() rejects, so the instance is re-initializable", async () => {
+    vi.mocked(ffi.initialize).mockImplementation(() => {});
+    vi.mocked(ffi.createEngine).mockImplementation(() => 7);
+    vi.mocked(ffi.cleanup).mockRejectedValueOnce(new Error("native cleanup boom"));
+
+    const dw = new DataWeave({ libPath: "mock-lib-path" });
+    dw.initialize();
+
+    await expect(dw.cleanup()).rejects.toThrow("native cleanup boom");
+
+    // Even though ffi.cleanup() rejected, the engine handle was already
+    // destroyed and nulled -- `initialized` must not stay stuck `true`, or a
+    // later initialize() call becomes a permanent no-op (the early-return
+    // guard `if (this.initialized) return;`) and the instance is stranded
+    // with a null engineHandle.
+    vi.mocked(ffi.initialize).mockClear();
+    vi.mocked(ffi.createEngine).mockClear();
+    vi.mocked(ffi.createEngine).mockImplementation(() => 9);
+
+    dw.initialize();
+
+    expect(ffi.initialize).toHaveBeenCalledTimes(1);
+    expect(ffi.createEngine).toHaveBeenCalledTimes(1);
+  });
+
+  it("coalesces concurrent cleanup() calls into a single native teardown", async () => {
+    vi.mocked(ffi.createEngine).mockReturnValue(1);
+    let resolveNative!: () => void;
+    vi.mocked(ffi.cleanup).mockReturnValue(
+      new Promise<void>((resolve) => {
+        resolveNative = resolve;
+      })
+    );
+
+    const dw = new DataWeave("/fake/lib");
+    dw.initialize();
+
+    // Two overlapping cleanup() calls while ffi.cleanup() is still pending.
+    const p1 = dw.cleanup();
+    const p2 = dw.cleanup();
+    resolveNative();
+    await Promise.all([p1, p2]);
+
+    // The native ref-count decrement (ffi.cleanup) and destroyEngine each run
+    // exactly once, not once per caller -- this is the double-decrement fix.
+    expect(ffi.cleanup).toHaveBeenCalledTimes(1);
+    expect(ffi.destroyEngine).toHaveBeenCalledTimes(1);
+  });
+
+  it("second overlapping cleanup() call awaits the SAME in-flight native teardown, not an early resolution", async () => {
+    // Regression test for task-1 fix round 1: doCleanup() flips `state` to
+    // "cleaning-up" synchronously as its first statement (an async function
+    // body runs synchronously up to its first await). If cleanup()'s
+    // not-ready guard (`if (this.state !== "ready") return;`) ran BEFORE the
+    // `cleanupPromise` coalescing check, a second overlapping call would see
+    // state already left "ready" and resolve immediately -- never actually
+    // awaiting the first call's in-flight native teardown. That would
+    // contradict cleanup()'s documented contract ("resolves once the
+    // underlying native isolate has actually finished tearing down") and
+    // silently regress round-4's coalescing timing. This test asserts the
+    // second call's promise has NOT settled while ffi.cleanup() is still
+    // pending, by racing it against a marker that only resolves after
+    // ffi.cleanup() is allowed to settle.
+    vi.mocked(ffi.createEngine).mockReturnValue(1);
+    let resolveNative!: () => void;
+    vi.mocked(ffi.cleanup).mockReturnValue(
+      new Promise<void>((resolve) => {
+        resolveNative = resolve;
+      })
+    );
+
+    const dw = new DataWeave("/fake/lib");
+    dw.initialize();
+
+    const p1 = dw.cleanup();
+    const p2 = dw.cleanup(); // overlaps while doCleanup() is in flight
+
+    const SETTLED = Symbol("settled");
+    const PENDING = Symbol("pending");
+    // A same-tick race: if p2 resolved early (the regression), it wins;
+    // Promise.resolve() flushes on the same microtask queue, so this
+    // reliably distinguishes "already settled" from "still pending" without
+    // relying on real timers.
+    const raceResult = await Promise.race([
+      p2.then(() => SETTLED),
+      Promise.resolve().then(() => PENDING),
+    ]);
+    expect(raceResult).toBe(PENDING);
+
+    resolveNative();
+    await Promise.all([p1, p2]);
+
+    expect(ffi.cleanup).toHaveBeenCalledTimes(1);
+    expect(ffi.destroyEngine).toHaveBeenCalledTimes(1);
+  });
+
+  it("does not accumulate process exit listeners across init/cleanup cycles", async () => {
+    // The module-level `run`/`cleanup` convenience API drives the lazily
+    // created singleton through `getGlobalInstance()`, which is what
+    // registers the process-wide beforeExit/exit hooks (registerExitHooksOnce
+    // in src/dataweave.ts). Unlike the other tests in this file, this doesn't
+    // construct DataWeave directly, so it hits DataWeave's default
+    // `findLibrary()` lookup. Point DATAWEAVE_NATIVE_LIB at this test file
+    // (guaranteed to exist) so that lookup succeeds without depending on a
+    // real built dwlib -- ffi.initialize() is mocked, so the path's contents
+    // are never touched.
+    const prevEnvLib = process.env.DATAWEAVE_NATIVE_LIB;
+    process.env.DATAWEAVE_NATIVE_LIB = __filename;
+    try {
+      const before = process.listenerCount("exit") + process.listenerCount("beforeExit");
+      // Drive several singleton create -> cleanup cycles via the module API.
+      for (let i = 0; i < 5; i++) {
+        run("%dw 2.0\noutput application/json\n---\n1 + 1"); // creates the singleton (+ hooks on first)
+        await cleanup(); // releases the singleton
+      }
+      const after = process.listenerCount("exit") + process.listenerCount("beforeExit");
+      // Register-once: at most the single pair added on the very first create,
+      // never one pair per cycle.
+      expect(after - before).toBeLessThanOrEqual(2);
+    } finally {
+      if (prevEnvLib === undefined) delete process.env.DATAWEAVE_NATIVE_LIB;
+      else process.env.DATAWEAVE_NATIVE_LIB = prevEnvLib;
+    }
+  });
+
+  it("still calls ffi.cleanup() (releasing the native init reference) when destroyEngine() throws", async () => {
+    // Real path: wrong-thread destroyEngine() throws synchronously. If cleanup()
+    // skipped ffi.cleanup() on that throw, the native init reference for this env
+    // would leak and block isolate teardown. cleanup() must release it anyway and
+    // still surface the primary destruction error.
+    vi.mocked(ffi.initialize).mockImplementation(() => {});
+    vi.mocked(ffi.createEngine).mockReturnValue(7);
+    vi.mocked(ffi.destroyEngine).mockImplementation(() => {
+      throw new Error("wrong-thread destroy boom");
+    });
+    vi.mocked(ffi.cleanup).mockResolvedValue(undefined);
+
+    const dw = new DataWeave("/fake/lib");
+    dw.initialize();
+
+    await expect(dw.cleanup()).rejects.toThrow("wrong-thread destroy boom");
+
+    // The native init reference was still released despite the destroy throw.
+    expect(ffi.cleanup).toHaveBeenCalledTimes(1);
+
+    // The instance is not stranded "ready": a later initialize() works.
+    vi.mocked(ffi.destroyEngine).mockReset();
+    vi.mocked(ffi.createEngine).mockReturnValue(9);
+    vi.mocked(ffi.createEngine).mockClear(); // ignore the first init's call
+    dw.initialize();
+    // Prove the re-init genuinely created a fresh engine (not a no-op that
+    // false-passes toHaveBeenLastCalledWith because the FIRST init already
+    // called createEngine() with the same args -- review #6 #8).
+    expect(ffi.createEngine).toHaveBeenCalledTimes(1);
+  });
+
+  it("does not publish a poisoned singleton when the first module-level init fails", async () => {
+    // Isolate module state: a fresh import gives a null globalInstance so this
+    // test controls the very first getGlobalInstance() call.
+    vi.resetModules();
+    const ffiMod = await import("../../src/ffi");
+    const dwMod = await import("../../src/dataweave");
+
+    // First module-level run(): ffi.initialize() throws (e.g. bad lib path).
+    vi.mocked(ffiMod.initialize).mockImplementationOnce(() => {
+      throw new Error("library not found");
+    });
+    expect(() => dwMod.run("%dw 2.0\noutput application/json\n---\n1")).toThrow();
+
+    // The fault is corrected; the NEXT module-level run() must build a fresh,
+    // working singleton -- not reuse a poisoned, uninitialized one that fails
+    // "not initialized" forever (review #6 #1).
+    vi.mocked(ffiMod.initialize).mockImplementation(() => {});
+    vi.mocked(ffiMod.createEngine).mockReturnValue(1);
+    vi.mocked(ffiMod.runScriptEngine).mockReturnValue(
+      JSON.stringify({
+        success: true,
+        result: Buffer.from("1").toString("base64"),
+        mimeType: "application/json",
+        charset: "utf-8",
+        binary: false,
+      })
+    );
+    const result = dwMod.run("%dw 2.0\noutput application/json\n---\n1");
+    expect(result.success).toBe(true);
+  });
+});
diff --git a/native-lib/node/tests/unit/stream.test.ts b/native-lib/node/tests/unit/stream.test.ts
index 46ca0e4a..6e71c677 100644
--- a/native-lib/node/tests/unit/stream.test.ts
+++ b/native-lib/node/tests/unit/stream.test.ts
@@ -20,8 +20,9 @@ async function collect(
 
 function deferred<T>() {
   let resolve!: (v: T) => void;
-  const promise = new Promise<T>((res) => { resolve = res; });
-  return { promise, resolve };
+  let reject!: (e: unknown) => void;
+  const promise = new Promise<T>((res, rej) => { resolve = res; reject = rej; });
+  return { promise, resolve, reject };
 }
 
 describe("streamFromNative", () => {
@@ -95,4 +96,35 @@ describe("streamFromNative", () => {
     expect(result.success).toBe(false);
     expect(result.error).toBe("Empty response");
   });
+
+  it("rejects a parked consumer when native start() rejects (no hang)", async () => {
+    const startGate = deferred<string>();
+    const gen = streamFromNative(() => startGate.promise);
+
+    // Park a consumer in next() BEFORE the start promise settles: no chunk is
+    // ready and done is false, so next() awaits on pendingResolves.
+    const pending = gen.next();
+
+    // Now reject the native start. The parked consumer must be woken and see a
+    // rejection -- on the pre-fix code done never flips and this hangs forever.
+    startGate.reject(new Error("native start boom"));
+
+    await expect(pending).rejects.toThrow("native start boom");
+  });
+
+  it("drains buffered chunks, then throws, when start() rejects after pushing chunks", async () => {
+    const gen = streamFromNative((cb) => {
+      cb(Buffer.from("x"));
+      cb(Buffer.from("y"));
+      return Promise.reject(new Error("late boom"));
+    });
+
+    // Buffered chunks yield first...
+    const a = await gen.next();
+    const b = await gen.next();
+    expect([a.value?.toString(), b.value?.toString()]).toEqual(["x", "y"]);
+
+    // ...then the drained generator surfaces the start error.
+    await expect(gen.next()).rejects.toThrow("late boom");
+  });
 });
\ No newline at end of file
diff --git a/native-lib/src/main/java/org/mule/weave/lib/CallbackWeaveResourceResolver.java b/native-lib/src/main/java/org/mule/weave/lib/CallbackWeaveResourceResolver.java
index d6b80912..c2596084 100644
--- a/native-lib/src/main/java/org/mule/weave/lib/CallbackWeaveResourceResolver.java
+++ b/native-lib/src/main/java/org/mule/weave/lib/CallbackWeaveResourceResolver.java
@@ -3,6 +3,7 @@
 import org.graalvm.nativeimage.CurrentIsolate;
 import org.graalvm.nativeimage.c.type.CCharPointer;
 import org.graalvm.nativeimage.c.type.CTypeConversion;
+import org.graalvm.word.PointerBase;
 import org.mule.weave.v2.parser.ast.variables.NameIdentifier;
 import org.mule.weave.v2.sdk.NameIdentifierHelper;
 import org.mule.weave.v2.sdk.WeaveResource;
@@ -20,12 +21,14 @@
  */
 public class CallbackWeaveResourceResolver implements WeaveResourceResolver {
     private final NativeCallbacks.ResolveModuleCallback callback;
+    private final PointerBase ctx;
 
-    public CallbackWeaveResourceResolver(NativeCallbacks.ResolveModuleCallback callback) {
+    public CallbackWeaveResourceResolver(NativeCallbacks.ResolveModuleCallback callback, PointerBase ctx) {
         if (callback.isNull()) {
             throw new IllegalArgumentException("Resolver callback cannot be null");
         }
         this.callback = callback;
+        this.ctx = ctx;
     }
 
     @Override
@@ -42,6 +45,7 @@ public Option<WeaveResource> resolve(NameIdentifier nameIdentifier) {
                 // Invoke callback (blocks if threadsafe function is in use)
                 CCharPointer resultPtr = callback.invoke(
                     CurrentIsolate.getCurrentThread(),
+                    ctx,
                     pathPtr
                 );
 
@@ -59,8 +63,21 @@ public Option<WeaveResource> resolve(NameIdentifier nameIdentifier) {
                 );
             }
         } catch (Exception e) {
-            // Log and return empty on any error
-            System.err.println("Error resolving module " + path + ": " + e.getMessage());
+            // Log and return empty on any error. Mirrors the C-side resolver bridge's
+            // policy (see resolve_module_callback in addon.c): both the exception
+            // message AND the module path are resolver-controlled/dynamic content
+            // (module source, file paths, credentials can leak through either), so
+            // the default log line is fully static/content-free, with no path and no
+            // message. Only include them when the caller has opted in via
+            // DATAWEAVE_RESOLVER_DEBUG=1.
+            if ("1".equals(System.getenv("DATAWEAVE_RESOLVER_DEBUG"))) {
+                System.err.println("Error resolving module " + path + ": " + e.getMessage());
+            } else {
+                System.err.println(
+                    "Error resolving module (details suppressed; set "
+                    + "DATAWEAVE_RESOLVER_DEBUG=1 to log path/message — may expose "
+                    + "resolver-controlled data).");
+            }
             return Option.empty();
         }
     }
diff --git a/native-lib/src/main/java/org/mule/weave/lib/NativeCallbacks.java b/native-lib/src/main/java/org/mule/weave/lib/NativeCallbacks.java
index 3e993c7e..2deaddd3 100644
--- a/native-lib/src/main/java/org/mule/weave/lib/NativeCallbacks.java
+++ b/native-lib/src/main/java/org/mule/weave/lib/NativeCallbacks.java
@@ -55,6 +55,6 @@ public interface ReadCallback extends CFunctionPointer {
      */
     public interface ResolveModuleCallback extends CFunctionPointer {
         @InvokeCFunctionPointer
-        CCharPointer invoke(IsolateThread thread, CCharPointer modulePath);
+        CCharPointer invoke(IsolateThread thread, PointerBase ctx, CCharPointer modulePath);
     }
 }
diff --git a/native-lib/src/main/java/org/mule/weave/lib/NativeLib.java b/native-lib/src/main/java/org/mule/weave/lib/NativeLib.java
index 549ea3ac..f635ccf0 100644
--- a/native-lib/src/main/java/org/mule/weave/lib/NativeLib.java
+++ b/native-lib/src/main/java/org/mule/weave/lib/NativeLib.java
@@ -19,6 +19,17 @@
  */
 public class NativeLib {
 
+    /**
+     * The exact JSON error payload returned by the per-engine entrypoints
+     * ({@link #runScriptEngine}, {@link #runScriptCallbackEngine},
+     * {@link #runScriptInputOutputCallbackEngine}) when {@code handle} does not identify a
+     * live engine. Package-visible (rather than embedded as a string literal at each call
+     * site) so the exact contract can be asserted directly from a JVM unit test, since the
+     * {@code @CEntryPoint} methods themselves rely on GraalVM word types that only resolve
+     * inside a compiled native image.
+     */
+    static final String UNKNOWN_ENGINE_HANDLE_JSON = "{\"success\":false,\"error\":\"Unknown engine handle\"}";
+
     /**
      * Native method that executes a DataWeave script with inputs and returns the result.
      * Can be called from Python via FFI.
@@ -89,6 +100,17 @@ public static CCharPointer runScriptCallback(
         String inputs = inputsJson.isNull() ? null : CTypeConversion.toJavaString(inputsJson);
 
         ScriptRuntime runtime = ScriptRuntime.getInstance();
+        return streamToWriteCallback(runtime, dwScript, inputs, writeCallback, ctx);
+    }
+
+    /**
+     * Runs the streaming write-callback loop shared by the legacy singleton entrypoint
+     * ({@link #runScriptCallback}) and the per-engine entrypoint
+     * ({@link #runScriptCallbackEngine}).
+     */
+    private static CCharPointer streamToWriteCallback(
+            ScriptRuntime runtime, String dwScript, String inputs,
+            NativeCallbacks.WriteCallback writeCallback, PointerBase ctx) {
         StreamSession session = runtime.runStreaming(dwScript, inputs);
 
         if (session.isError()) {
@@ -170,6 +192,22 @@ public static CCharPointer runScriptInputOutputCallback(
         String inMime = CTypeConversion.toJavaString(inputMimeType);
         String inCharset = inputCharset.isNull() ? null : CTypeConversion.toJavaString(inputCharset);
 
+        ScriptRuntime runtime = ScriptRuntime.getInstance();
+        return transformViaCallbacks(runtime, dwScript, inputs, inName, inMime, inCharset,
+                readCallback, writeCallback, ctx);
+    }
+
+    /**
+     * Runs the input-feeder + output-streaming loop shared by the legacy singleton entrypoint
+     * ({@link #runScriptInputOutputCallback}) and the per-engine entrypoint
+     * ({@link #runScriptInputOutputCallbackEngine}).
+     */
+    private static CCharPointer transformViaCallbacks(
+            ScriptRuntime runtime, String dwScript, String inputs,
+            String inName, String inMime, String inCharset,
+            NativeCallbacks.ReadCallback readCallback, NativeCallbacks.WriteCallback writeCallback,
+            PointerBase ctx) {
+
         // Create a piped input stream session for the callback-supplied input
         InputStreamSession inputSession = new InputStreamSession(inMime, inCharset);
         long inputHandle = inputSession.register();
@@ -191,7 +229,6 @@ public static CCharPointer runScriptInputOutputCallback(
         feeder.start();
 
         // Execute the script and stream output via the writeCallback
-        ScriptRuntime runtime = ScriptRuntime.getInstance();
         StreamSession session = runtime.runStreaming(dwScript, mergedInputs);
 
         if (session.isError()) {
@@ -330,239 +367,139 @@ private static CCharPointer toUnmanagedCString(String value) {
         return ptr;
     }
 
-    // ── Resolver-aware FFI Entrypoints ───────────────────────────────────
+    // ── Multi-Engine FFI Entrypoints (W-23692110) ────────────────────────
 
     /**
-     * Runs a DataWeave script with module resolver callback.
+     * Creates a new isolated engine (ClassLoader-only resolver) and returns its handle.
      *
-     * <p>This variant accepts a {@link NativeCallbacks.ResolveModuleCallback} to resolve
-     * external modules during script execution. The resolver is installed before script
-     * execution and remains active for the lifetime of the process.</p>
+     * @param thread the isolate thread
+     * @return a non-zero handle identifying the new engine
+     */
+    @CEntryPoint(name = "create_engine")
+    public static long createEngine(IsolateThread thread) {
+        return ScriptRuntime.register(new ScriptRuntime(null));
+    }
+
+    /**
+     * Creates a new isolated engine backed by a caller-supplied module resolver callback,
+     * and returns its handle.
      *
-     * @param thread GraalVM isolate thread
-     * @param script DataWeave script source (C string)
-     * @param inputsJson JSON string of inputs (C string)
-     * @param resolverCallback Callback for resolving external modules
-     * @return JSON result or error message (unmanaged C string, must be freed)
+     * @param thread           the isolate thread
+     * @param resolverCallback callback used to resolve external modules for this engine only
+     * @param ctx              opaque context pointer forwarded to every resolver invocation
+     * @return a non-zero handle identifying the new engine
      */
-    @CEntryPoint(name = "run_script_with_resolver")
-    public static CCharPointer runScriptWithResolver(
+    @CEntryPoint(name = "create_engine_with_resolver")
+    public static long createEngineWithResolver(
             IsolateThread thread,
-            CCharPointer script,
-            CCharPointer inputsJson,
-            NativeCallbacks.ResolveModuleCallback resolverCallback) {
-
-        try {
-            // Install resolver (idempotent if already set)
-            ScriptRuntime.setResolver(resolverCallback);
-
-            // Delegate to existing run logic
-            String dwScript = CTypeConversion.toJavaString(script);
-            String inputs = CTypeConversion.toJavaString(inputsJson);
+            NativeCallbacks.ResolveModuleCallback resolverCallback,
+            PointerBase ctx) {
+        CallbackWeaveResourceResolver resolver =
+                new CallbackWeaveResourceResolver(resolverCallback, ctx);
+        return ScriptRuntime.register(new ScriptRuntime(resolver));
+    }
 
-            ScriptRuntime runtime = ScriptRuntime.getInstance();
-            String result = runtime.run(dwScript, inputs);
-            return toUnmanagedCString(result);
-        } catch (Exception e) {
-            return toUnmanagedCString("{\"success\":false,\"error\":\""
-                + escapeJsonString(e.getMessage()) + "\"}");
-        }
+    /**
+     * Destroys an engine created by {@link #createEngine} / {@link #createEngineWithResolver}.
+     * A no-op if the handle is unknown or already destroyed.
+     *
+     * @param thread the isolate thread
+     * @param handle the engine handle to remove
+     */
+    @CEntryPoint(name = "destroy_engine")
+    public static void destroyEngine(IsolateThread thread, long handle) {
+        ScriptRuntime.destroy(handle);
     }
 
     /**
-     * Runs a DataWeave script with streaming output and module resolver.
+     * Executes a DataWeave script against a specific engine.
      *
-     * <p>This variant combines streaming output via a write callback with external module
-     * resolution. The resolver is installed before script execution.</p>
+     * <p>If {@code handle} does not identify a live engine, returns
+     * {@code {"success":false,"error":"Unknown engine handle"}} rather than throwing.</p>
      *
-     * @param thread GraalVM isolate thread
-     * @param script DataWeave script source (C string)
+     * @param thread     the isolate thread
+     * @param handle     the target engine's handle
+     * @param script     the DataWeave script (C string)
      * @param inputsJson JSON-encoded inputs map (C string), may be null
-     * @param writeCallback function pointer invoked with each output chunk
-     * @param ctx opaque context pointer forwarded to callback
-     * @param resolverCallback Callback for resolving external modules
-     * @return an unmanaged C string with JSON metadata/error (must be freed)
-     *
-     * <p><b>NOTE:</b> compiled/linked but intentionally NOT invoked from the Node binding's
-     * TypeScript layer. runStreaming() deliberately uses the resolver-less streaming entrypoint
-     * instead: streaming runs its native call on a background thread, and wiring a resolver
-     * callback there would call back into JS from a non-owning OS thread (undefined behavior /
-     * crash). Do not wire this up without first solving that cross-thread hazard.</p>
+     * @return the script execution result (unmanaged C string, must be freed)
      */
-    @CEntryPoint(name = "run_script_callback_with_resolver")
-    public static CCharPointer runScriptCallbackWithResolver(
-            IsolateThread thread,
-            CCharPointer script,
-            CCharPointer inputsJson,
-            NativeCallbacks.WriteCallback writeCallback,
-            PointerBase ctx,
-            NativeCallbacks.ResolveModuleCallback resolverCallback) {
-
-        try {
-            // Install resolver
-            ScriptRuntime.setResolver(resolverCallback);
-
-            // Delegate to existing streaming logic
-            String dwScript = CTypeConversion.toJavaString(script);
-            String inputs = inputsJson.isNull() ? null : CTypeConversion.toJavaString(inputsJson);
-
-            ScriptRuntime runtime = ScriptRuntime.getInstance();
-            StreamSession session = runtime.runStreaming(dwScript, inputs);
-
-            if (session.isError()) {
-                return toUnmanagedCString("{\"success\":false,\"error\":\""
-                        + escapeJsonString(session.getError()) + "\"}");
-            }
-
-            try {
-                byte[] buf = new byte[CALLBACK_BUFFER_SIZE];
-                CCharPointer nativeBuf = UnmanagedMemory.malloc(CALLBACK_BUFFER_SIZE);
-                try {
-                    int n;
-                    while ((n = session.read(buf, buf.length)) > 0) {
-                        for (int i = 0; i < n; i++) {
-                            nativeBuf.write(i, buf[i]);
-                        }
-                        int rc = writeCallback.invoke(ctx, nativeBuf, n);
-                        if (rc != 0) {
-                            return toUnmanagedCString("{\"success\":false,\"error\":\""
-                                    + "Write callback returned error: " + rc + "\"}");
-                        }
-                    }
-                } finally {
-                    UnmanagedMemory.free(nativeBuf);
-                }
-            } catch (IOException e) {
-                return toUnmanagedCString("{\"success\":false,\"error\":\""
-                        + escapeJsonString(e.getMessage()) + "\"}");
-            } finally {
-                session.closeStream();
-            }
+    @CEntryPoint(name = "run_script_engine")
+    public static CCharPointer runScriptEngine(
+            IsolateThread thread, long handle, CCharPointer script, CCharPointer inputsJson) {
+        ScriptRuntime runtime = ScriptRuntime.get(handle);
+        if (runtime == null) {
+            return toUnmanagedCString(UNKNOWN_ENGINE_HANDLE_JSON);
+        }
+        String dwScript = CTypeConversion.toJavaString(script);
+        String inputs = inputsJson.isNull() ? null : CTypeConversion.toJavaString(inputsJson);
+        return toUnmanagedCString(runtime.run(dwScript, inputs));
+    }
 
-            return toUnmanagedCString("{\"success\":true"
-                    + ",\"mimeType\":\"" + session.getMimeType() + "\""
-                    + ",\"charset\":\"" + session.getCharset() + "\""
-                    + ",\"binary\":" + session.isBinary()
-                    + "}");
-        } catch (Exception e) {
-            return toUnmanagedCString("{\"success\":false,\"error\":\""
-                + escapeJsonString(e.getMessage()) + "\"}");
+    /**
+     * Executes a DataWeave script against a specific engine, streaming the result to a
+     * caller-supplied write callback. See {@link #runScriptCallback} for the callback contract.
+     *
+     * <p>If {@code handle} does not identify a live engine, returns
+     * {@code {"success":false,"error":"Unknown engine handle"}} rather than throwing.</p>
+     *
+     * @param thread        the isolate thread
+     * @param handle        the target engine's handle
+     * @param script        the DataWeave script (C string)
+     * @param inputsJson    JSON-encoded inputs map (C string), may be null
+     * @param writeCallback function pointer invoked with each output chunk; must return 0 on success
+     * @param ctx           opaque context pointer forwarded to every callback invocation
+     * @return an unmanaged C string with JSON metadata/error
+     */
+    @CEntryPoint(name = "run_script_callback_engine")
+    public static CCharPointer runScriptCallbackEngine(
+            IsolateThread thread, long handle, CCharPointer script, CCharPointer inputsJson,
+            NativeCallbacks.WriteCallback writeCallback, PointerBase ctx) {
+        ScriptRuntime runtime = ScriptRuntime.get(handle);
+        if (runtime == null) {
+            return toUnmanagedCString(UNKNOWN_ENGINE_HANDLE_JSON);
         }
+        String dwScript = CTypeConversion.toJavaString(script);
+        String inputs = inputsJson.isNull() ? null : CTypeConversion.toJavaString(inputsJson);
+        return streamToWriteCallback(runtime, dwScript, inputs, writeCallback, ctx);
     }
 
     /**
-     * Runs a DataWeave script with streaming input/output and module resolver.
+     * Executes a DataWeave script against a specific engine, with a callback-supplied input
+     * and callback-streamed output. See {@link #runScriptInputOutputCallback} for the callback
+     * contract.
      *
-     * <p>This variant combines streaming input via read callback, streaming output via write
-     * callback, and external module resolution. The resolver is installed before script execution.</p>
+     * <p>If {@code handle} does not identify a live engine, returns
+     * {@code {"success":false,"error":"Unknown engine handle"}} rather than throwing.</p>
      *
-     * @param thread GraalVM isolate thread
-     * @param script DataWeave script source (C string)
-     * @param inputsJson JSON-encoded inputs map (C string), may be null
-     * @param inputName the binding name for the callback-supplied input (C string)
+     * @param thread        the isolate thread
+     * @param handle        the target engine's handle
+     * @param script        the DataWeave script (C string)
+     * @param inputsJson    JSON-encoded inputs map (C string), may be null
+     * @param inputName     the binding name for the callback-supplied input (C string)
      * @param inputMimeType the MIME type of the callback-supplied input (C string)
-     * @param inputCharset the charset of the callback-supplied input (C string), may be null
-     * @param readCallback function pointer invoked to read input chunks
-     * @param writeCallback function pointer invoked with output chunks
-     * @param ctx opaque context pointer forwarded to callbacks
-     * @param resolverCallback Callback for resolving external modules
-     * @return an unmanaged C string with JSON metadata/error (must be freed)
-     *
-     * <p><b>NOTE:</b> compiled/linked but intentionally NOT invoked from the Node binding's
-     * TypeScript layer. runTransform() deliberately uses the resolver-less transform entrypoint
-     * instead: transform runs its native call on a background thread, and wiring a resolver
-     * callback there would call back into JS from a non-owning OS thread (undefined behavior /
-     * crash). Do not wire this up without first solving that cross-thread hazard.</p>
+     * @param inputCharset  the charset of the callback-supplied input (C string), may be null for UTF-8
+     * @param readCallback  function pointer invoked to read the next chunk
+     * @param writeCallback function pointer invoked with each output chunk; must return 0 on success
+     * @param ctx           opaque context pointer forwarded to every callback invocation
+     * @return an unmanaged C string with JSON metadata/error
      */
-    @CEntryPoint(name = "run_script_input_output_callback_with_resolver")
-    public static CCharPointer runScriptInputOutputCallbackWithResolver(
-            IsolateThread thread,
-            CCharPointer script,
-            CCharPointer inputsJson,
-            CCharPointer inputName,
-            CCharPointer inputMimeType,
-            CCharPointer inputCharset,
-            NativeCallbacks.ReadCallback readCallback,
-            NativeCallbacks.WriteCallback writeCallback,
-            PointerBase ctx,
-            NativeCallbacks.ResolveModuleCallback resolverCallback) {
-
-        try {
-            // Install resolver
-            ScriptRuntime.setResolver(resolverCallback);
-
-            // Delegate to existing streaming I/O logic
-            String dwScript = CTypeConversion.toJavaString(script);
-            String inputs = inputsJson.isNull() ? null : CTypeConversion.toJavaString(inputsJson);
-            String inName = CTypeConversion.toJavaString(inputName);
-            String inMime = CTypeConversion.toJavaString(inputMimeType);
-            String inCharset = inputCharset.isNull() ? null : CTypeConversion.toJavaString(inputCharset);
-
-            // Create a piped input stream session for the callback-supplied input
-            InputStreamSession inputSession = new InputStreamSession(inMime, inCharset);
-            long inputHandle = inputSession.register();
-
-            // Merge the stream handle into the inputs JSON
-            String streamEntry = "{\"streamHandle\":\"" + inputHandle + "\",\"mimeType\":\"" + inMime + "\""
-                    + (inCharset != null ? ",\"charset\":\"" + inCharset + "\"" : "") + "}";
-            String mergedInputs = mergeInputEntry(inputs, inName, streamEntry);
-
-            // Start background thread for reading input
-            final long readCallbackAddr = readCallback.rawValue();
-            final long ctxAddr = ctx.rawValue();
-            Thread feeder = new Thread(new InputCallbackFeeder(
-                    readCallbackAddr, ctxAddr, inputSession), "dw-input-callback-feeder");
-            feeder.setDaemon(true);
-            feeder.start();
-
-            // Execute the script and stream output via the writeCallback
-            ScriptRuntime runtime = ScriptRuntime.getInstance();
-            StreamSession session = runtime.runStreaming(dwScript, mergedInputs);
-
-            if (session.isError()) {
-                cleanupFeeder(feeder, inputHandle);
-                return toUnmanagedCString("{\"success\":false,\"error\":\""
-                        + escapeJsonString(session.getError()) + "\"}");
-            }
-
-            try {
-                byte[] buf = new byte[CALLBACK_BUFFER_SIZE];
-                CCharPointer writeBuf = UnmanagedMemory.malloc(CALLBACK_BUFFER_SIZE);
-                try {
-                    int n;
-                    while ((n = session.read(buf, buf.length)) > 0) {
-                        for (int i = 0; i < n; i++) {
-                            writeBuf.write(i, buf[i]);
-                        }
-                        int rc = writeCallback.invoke(ctx, writeBuf, n);
-                        if (rc != 0) {
-                            cleanupFeeder(feeder, inputHandle);
-                            return toUnmanagedCString("{\"success\":false,\"error\":\""
-                                    + "Write callback returned error: " + rc + "\"}");
-                        }
-                    }
-                } finally {
-                    UnmanagedMemory.free(writeBuf);
-                }
-            } catch (IOException e) {
-                cleanupFeeder(feeder, inputHandle);
-                return toUnmanagedCString("{\"success\":false,\"error\":\""
-                        + escapeJsonString(e.getMessage()) + "\"}");
-            } finally {
-                session.closeStream();
-            }
-
-            cleanupFeeder(feeder, inputHandle);
-
-            return toUnmanagedCString("{\"success\":true"
-                    + ",\"mimeType\":\"" + session.getMimeType() + "\""
-                    + ",\"charset\":\"" + session.getCharset() + "\""
-                    + ",\"binary\":" + session.isBinary()
-                    + "}");
-        } catch (Exception e) {
-            return toUnmanagedCString("{\"success\":false,\"error\":\""
-                + escapeJsonString(e.getMessage()) + "\"}");
+    @CEntryPoint(name = "run_script_input_output_callback_engine")
+    public static CCharPointer runScriptInputOutputCallbackEngine(
+            IsolateThread thread, long handle, CCharPointer script, CCharPointer inputsJson,
+            CCharPointer inputName, CCharPointer inputMimeType, CCharPointer inputCharset,
+            NativeCallbacks.ReadCallback readCallback, NativeCallbacks.WriteCallback writeCallback,
+            PointerBase ctx) {
+        ScriptRuntime runtime = ScriptRuntime.get(handle);
+        if (runtime == null) {
+            return toUnmanagedCString(UNKNOWN_ENGINE_HANDLE_JSON);
         }
+        String dwScript = CTypeConversion.toJavaString(script);
+        String inputs = inputsJson.isNull() ? null : CTypeConversion.toJavaString(inputsJson);
+        String inName = CTypeConversion.toJavaString(inputName);
+        String inMime = CTypeConversion.toJavaString(inputMimeType);
+        String inCharset = inputCharset.isNull() ? null : CTypeConversion.toJavaString(inputCharset);
+        return transformViaCallbacks(runtime, dwScript, inputs, inName, inMime, inCharset,
+                readCallback, writeCallback, ctx);
     }
 
 }
diff --git a/native-lib/src/main/java/org/mule/weave/lib/ScriptRuntime.java b/native-lib/src/main/java/org/mule/weave/lib/ScriptRuntime.java
index 3371127a..d8db13ba 100644
--- a/native-lib/src/main/java/org/mule/weave/lib/ScriptRuntime.java
+++ b/native-lib/src/main/java/org/mule/weave/lib/ScriptRuntime.java
@@ -20,9 +20,16 @@
 import java.io.InputStream;
 import java.nio.charset.Charset;
 import java.util.Base64;
+import java.util.concurrent.ConcurrentHashMap;
+import java.util.concurrent.atomic.AtomicLong;
 
 /**
- * Singleton wrapper around a {@link DWScriptingEngine} used to compile and execute DataWeave scripts.
+ * Wrapper around a {@link DWScriptingEngine} used to compile and execute DataWeave scripts.
+ *
+ * <p>Each {@link ScriptRuntime} instance owns its own engine (and therefore its own module
+ * resolver and script cache), so multiple isolated engines can coexist within one process.
+ * Instances are tracked in a handle-keyed registry so native callers can address a specific
+ * engine by an opaque {@code long} handle.</p>
  *
  * <p>Execution results are returned as a JSON string containing a base64-encoded payload plus metadata
  * (mime type, charset, and whether the result is binary). Errors are returned as a JSON string with
@@ -30,84 +37,82 @@
  */
 public class ScriptRuntime {
 
-    private static final ScriptRuntime INSTANCE = new ScriptRuntime();
+    // ── Handle registry ──────────────────────────────────────────────────
+    private static final ConcurrentHashMap<Long, ScriptRuntime> REGISTRY = new ConcurrentHashMap<>();
+    private static final AtomicLong NEXT_HANDLE = new AtomicLong(1);
+
+    /** Registers a runtime and returns its non-zero handle. */
+    public static long register(ScriptRuntime runtime) {
+        long handle = NEXT_HANDLE.getAndIncrement();
+        REGISTRY.put(handle, runtime);
+        return handle;
+    }
+
+    /** Returns the runtime for a handle, or {@code null} if unknown/destroyed. */
+    public static ScriptRuntime get(long handle) {
+        return REGISTRY.get(handle);
+    }
+
+    /** Removes a runtime; returns {@code true} if one was present. */
+    public static boolean destroy(long handle) {
+        return REGISTRY.remove(handle) != null;
+    }
 
-    // Static field for callback resolver, volatile for thread-safe double-checked locking
-    private static volatile CallbackWeaveResourceResolver resolver = null;
+    // ── Legacy singleton (ClassLoader-only) for Python entrypoints ────────
+    private static volatile ScriptRuntime defaultInstance = null;
 
     /**
-     * Returns the singleton instance.
+     * Returns the process-wide legacy singleton instance (ClassLoader-only resolver).
      *
      * @return the shared {@link ScriptRuntime}
      */
     public static ScriptRuntime getInstance() {
-        return INSTANCE;
+        ScriptRuntime local = defaultInstance;
+        if (local == null) {
+            synchronized (ScriptRuntime.class) {
+                local = defaultInstance;
+                if (local == null) {
+                    local = new ScriptRuntime(null);
+                    defaultInstance = local;
+                }
+            }
+        }
+        return local;
     }
 
+    // ── Per-instance engine ───────────────────────────────────────────────
+    private final DWScriptingEngine engine;
+
     /**
-     * Sets the module resolver callback and rebuilds the engine.
-     * Can only be called once per process (engine is a singleton).
-     * Thread-safe but should be called early in application lifecycle before script execution.
-     *
-     * <p><strong>IMPORTANT:</strong> The callback function must be thread-safe if using
-     * GraalVM's threadsafe function pointers, as it may be invoked from multiple threads
-     * during concurrent module resolution.</p>
+     * Builds an engine whose resolver is Composite(ClassLoader-built-ins + {@code customResolver});
+     * a null {@code customResolver} yields ClassLoader-only.
      *
-     * @param callback Thread-safe function pointer for resolving modules
+     * @param customResolver additional resolver for user-supplied modules, or {@code null}
      */
-    public static synchronized void setResolver(NativeCallbacks.ResolveModuleCallback callback) {
-        if (resolver != null) {
-            System.err.println("WARNING: Module resolver already set for this process. " +
-                              "Only one resolver configuration is supported. Ignoring new resolver.");
-            return;
-        }
-
-        if (callback.isNull()) {
-            System.err.println("WARNING: Attempted to set null resolver, ignoring.");
-            return;
-        }
-
-        resolver = new CallbackWeaveResourceResolver(callback);
-
-        // Rebuild engine with composite resolver (built-ins + callback)
-        synchronized (INSTANCE) {
-            INSTANCE.engine = DWScriptingEngine.builder()
-                    .withDWModuleComponentsFactory(createModuleComponentsFactory())
-                    .build();
-        }
+    public ScriptRuntime(WeaveResourceResolver customResolver) {
+        this.engine = DWScriptingEngine.builder()
+                .withDWModuleComponentsFactory(createModuleComponentsFactory(customResolver))
+                .build();
     }
 
     /**
-     * Creates composite resolver: ClassLoader (built-ins) + Callback (user modules).
-     * If no callback resolver is set, returns ClassLoader only.
+     * Creates composite resolver: ClassLoader (built-ins) + custom (user modules).
+     * If no custom resolver is provided, returns ClassLoader only.
      */
-    private static WeaveResourceResolver compositeResolver() {
+    private static WeaveResourceResolver compositeResolver(WeaveResourceResolver customResolver) {
         WeaveResourceResolver classLoaderResolver = ClassLoaderWeaveResourceResolver.apply();
-
-        CallbackWeaveResourceResolver currentResolver = resolver;
-        if (currentResolver == null) {
+        if (customResolver == null) {
             return classLoaderResolver;
         }
-
         return CompositeWeaveResourceResolver.apply(
             classLoaderResolver,  // Try built-ins first
-            currentResolver       // Then callback for user modules
+            customResolver        // Then callback for user modules
         );
     }
 
-    private static DWModuleComponentsFactory createModuleComponentsFactory() {
+    private static DWModuleComponentsFactory createModuleComponentsFactory(WeaveResourceResolver customResolver) {
         return DWModuleComponentsFactory.createSimpleDWModuleComponentsFactoryBuilder()
-                .withWeaveResourceResolver(compositeResolver())
-                .build();
-    }
-
-    // Instance field for the scripting engine, access synchronized in setResolver
-    private volatile DWScriptingEngine engine;
-
-    private ScriptRuntime() {
-        // Initialize with ClassLoader-only resolver (no callback yet)
-        engine = DWScriptingEngine.builder()
-                .withDWModuleComponentsFactory(createModuleComponentsFactory())
+                .withWeaveResourceResolver(compositeResolver(customResolver))
                 .build();
     }
 
diff --git a/native-lib/src/test/java/org/mule/weave/lib/ScriptRuntimeTest.java b/native-lib/src/test/java/org/mule/weave/lib/ScriptRuntimeTest.java
index 70f8044b..bf35264a 100644
--- a/native-lib/src/test/java/org/mule/weave/lib/ScriptRuntimeTest.java
+++ b/native-lib/src/test/java/org/mule/weave/lib/ScriptRuntimeTest.java
@@ -580,6 +580,108 @@ void callbackOutputStreamingError() {
         System.out.println("=".repeat(50));
     }
 
+    // --- Multi-engine registry (W-23692110) ---
+
+    /** In-memory WeaveResourceResolver fake — the JVM-constructable seam standing
+     *  in for CallbackWeaveResourceResolver (a CFunctionPointer, which cannot be
+     *  built in test mode). */
+    static final class MapResolver
+            implements org.mule.weave.v2.sdk.WeaveResourceResolver {
+        private final java.util.Map<String, String> modules;
+        MapResolver(java.util.Map<String, String> modules) { this.modules = modules; }
+
+        @Override
+        public scala.Option<org.mule.weave.v2.sdk.WeaveResource> resolve(
+                org.mule.weave.v2.parser.ast.variables.NameIdentifier id) {
+            String path = org.mule.weave.v2.sdk.NameIdentifierHelper.toWeaveFilePath(id, "/");
+            String key = path.startsWith("/") ? path.substring(1) : path;
+            String src = modules.get(key);
+            if (src == null) return scala.Option.empty();
+            return scala.Option.apply(org.mule.weave.v2.sdk.WeaveResource.apply(path, src));
+        }
+
+        @Override
+        public scala.collection.immutable.Seq<org.mule.weave.v2.sdk.WeaveResource> resolveAll(
+                org.mule.weave.v2.parser.ast.variables.NameIdentifier id) {
+            scala.Option<org.mule.weave.v2.sdk.WeaveResource> r = resolve(id);
+            if (r.isDefined()) {
+                return scala.collection.JavaConverters
+                        .asScalaBuffer(java.util.Collections.singletonList(r.get())).toList();
+            }
+            return (scala.collection.immutable.Seq<org.mule.weave.v2.sdk.WeaveResource>)
+                    scala.collection.immutable.Seq$.MODULE$.<org.mule.weave.v2.sdk.WeaveResource>empty();
+        }
+    }
+
+    private static final String IMPORT_A =
+            "%dw 2.0\nimport org::test::a\noutput application/json\n---\na::greet(\"X\")";
+    private static final String IMPORT_B =
+            "%dw 2.0\nimport org::test::b\noutput application/json\n---\nb::greet(\"X\")";
+
+    @Test
+    void twoEnginesResolveOnlyTheirOwnModule() {
+        ScriptRuntime engineA = new ScriptRuntime(new MapResolver(java.util.Map.of(
+                "org/test/a.dwl", "%dw 2.0\nfun greet(n: String) = \"A:\" ++ n")));
+        ScriptRuntime engineB = new ScriptRuntime(new MapResolver(java.util.Map.of(
+                "org/test/b.dwl", "%dw 2.0\nfun greet(n: String) = \"B:\" ++ n")));
+
+        long hA = ScriptRuntime.register(engineA);
+        long hB = ScriptRuntime.register(engineB);
+        assertNotNull(ScriptRuntime.get(hA));
+        assertNotNull(ScriptRuntime.get(hB));
+
+        // Each engine resolves its own module...
+        assertEquals("\"A:X\"", Result.parse(ScriptRuntime.get(hA).run(IMPORT_A)).result);
+        assertEquals("\"B:X\"", Result.parse(ScriptRuntime.get(hB).run(IMPORT_B)).result);
+
+        // ...and NOT the other's (no cross-talk).
+        assertNotNull(Result.parse(ScriptRuntime.get(hA).run(IMPORT_B)).error);
+        assertNotNull(Result.parse(ScriptRuntime.get(hB).run(IMPORT_A)).error);
+
+        // destroy removes it; a fresh handle is distinct.
+        assertTrue(ScriptRuntime.destroy(hA));
+        assertNull(ScriptRuntime.get(hA));
+        assertFalse(ScriptRuntime.destroy(hA)); // already gone
+        assertNotNull(ScriptRuntime.get(hB));
+
+        ScriptRuntime.destroy(hB);
+    }
+
+    @Test
+    void engineWithoutResolverStillRunsBuiltins() {
+        ScriptRuntime engine = new ScriptRuntime(null); // ClassLoader-only
+        long h = ScriptRuntime.register(engine);
+        String r = ScriptRuntime.get(h).run(
+                "%dw 2.0\nimport dw::core::Strings\noutput application/json\n---\nStrings::capitalize(\"hello\")");
+        assertEquals("\"Hello\"", Result.parse(r).result);
+        ScriptRuntime.destroy(h);
+    }
+
+    /**
+     * Locks in the hard contract for the per-engine FFI entrypoints
+     * ({@code run_script_engine}, {@code run_script_callback_engine},
+     * {@code run_script_input_output_callback_engine} in {@link NativeLib}): running a
+     * script against an unknown or already-destroyed engine handle must return exactly
+     * {@code {"success":false,"error":"Unknown engine handle"}} rather than throwing.
+     *
+     * <p>The {@code @CEntryPoint} methods themselves cannot be invoked from a plain JVM
+     * unit test — they take GraalVM word types ({@code IsolateThread}, {@code CCharPointer})
+     * whose boxing infrastructure is only initialized inside a compiled native image (calling
+     * e.g. {@code WordFactory.nullPointer()} from a hosted JVM test throws
+     * {@code NullPointerException} from {@code WordBoxFactory}). All three entrypoints funnel
+     * the unknown-handle case through the same {@code UNKNOWN_ENGINE_HANDLE_JSON} constant, so
+     * asserting on that constant — combined with {@link #twoEnginesResolveOnlyTheirOwnModule}
+     * proving {@link ScriptRuntime#get} returns {@code null} for an unregistered/destroyed
+     * handle — verifies the full contract without needing the native runtime.</p>
+     */
+    @Test
+    void unknownEngineHandleProducesExactErrorJson() {
+        long unregisteredHandle = Long.MAX_VALUE;
+        assertNull(ScriptRuntime.get(unregisteredHandle));
+        assertEquals("{\"success\":false,\"error\":\"Unknown engine handle\"}",
+                NativeLib.UNKNOWN_ENGINE_HANDLE_JSON);
+    }
+
     static class Result {
         boolean success;
         String result;