mustflow 2.117.0 → 2.117.1

package/templates/default/locales/en/.mustflow/skills/memory-lifetime-review/SKILL.md

@@ -2,11 +2,11 @@
 mustflow_doc: skill.memory-lifetime-review
 locale: en
 canonical: true
-revision: 3
+revision: 5
 lifecycle: mustflow-owned
 authority: procedure
 name: memory-lifetime-review
-description: Apply this skill when code is created, changed, reviewed, or reported and object lifetime, retained references, cleanup symmetry, event listeners, timers, subscriptions, goroutines, threads, workers, streams, native handles, caches, queues, or memory/resource leak risk may matter.
+description: Apply this skill when code is created, changed, reviewed, diagnosed, validated, or reported and object lifetime, retained references, cleanup symmetry, event listeners, timers, subscriptions, goroutines, threads, workers, streams, native handles, caches, queues, RSS, heap, external memory, ArrayBuffer or Buffer retention, allocator fragmentation, unbounded buffering, cross-runtime reproduction, backpressure, or memory/resource leak risk may matter.
 metadata:
   mustflow_schema: "1"
   mustflow_kind: procedure
@@ -41,6 +41,11 @@ The question is not only "where was it allocated?" The stronger review question
 - Code adds lifecycle setup such as `new`, `open`, `connect`, `subscribe`, `observe`, `addEventListener`, `setInterval`, `setTimeout`, `context.WithCancel`, `ThreadLocal.set`, `malloc`, `retain`, `shared_ptr`, `Rc`, task spawning, stream creation, or cache insertion.
 - Code uses closures, callbacks, lambdas, async work, promises, channels, effects, refs, logging queues, metrics queues, debug arrays, maps, or registries that may capture or store large or short-lived objects.
 - A review or final report claims that a path is leak-free, bounded, cleaned up, disposable, safe for repeated mount/unmount, safe for long-running processes, safe under retries, or safe for repeated requests.
+- A Node.js service or streaming pipeline needs to distinguish JavaScript heap retention, external
+  buffers, native allocations, cache growth, handle leakage, allocator residency, and live
+  backpressure backlog instead of naming all RSS growth a memory leak.
+- A Node-compatible memory or stream symptom needs a same-source Node.js, Bun, adapter, runtime
+  version, or operating-system reproduction matrix without mixing application and runtime changes.
 
 <!-- mustflow-section: do-not-use-when -->
 ## Do Not Use When
@@ -60,7 +65,18 @@ The question is not only "where was it allocated?" The stronger review question
 - Repetition path: repeated requests, screen open/close, route changes, tab switches, reconnects, retries, scheduled runs, test cases, or long-running sessions that can accumulate retained state.
 - Error and success paths: normal completion, early return, partial read, cancellation, timeout, retry, exception, unmount, shutdown, and dependency failure behavior.
 - Diagnostic evidence for native or low-level memory faults: first sanitizer or memory-checker report, invalid write/read address, watchpoint condition, allocator or quarantine behavior, fuzzing input, core dump, symbols, build id, shared library list, and configured or manual diagnostic boundary.
+- Measurement classification for memory diagnosis: storage location, retention owner, terminal
+  status, post-GC or post-quiescent slope, queue-byte ledgers, process and protocol resource counts,
+  workload phases, and the statistical tolerance used for a leak or fragmentation claim.
 - Relevant command-intent contract entries for tests, builds, docs, release checks, and mustflow validation.
+- For Node.js RSS, heap, external-memory, Buffer, native-handle, cache, streaming, HTTP/2, HTTP/3,
+  or cross-layer backpressure diagnosis, read
+  `references/node-memory-resource-backpressure-diagnostics.md` before classifying cause or claiming
+  that a queue, leak, or allocator problem is resolved.
+- For a Node.js or Bun cross-runtime memory, stream, socket, descriptor, handle, allocator, or
+  runtime-version reproducer, read
+  `references/cross-runtime-memory-stream-reproduction-harness.md` before designing the process
+  harness, comparator matrix, result manifest, or permanent-resolution gate.
 
 <!-- mustflow-section: preconditions -->
 ## Preconditions
@@ -71,6 +87,12 @@ The question is not only "where was it allocated?" The stronger review question
 - If authorization, secrets, personal data, telemetry, or audit records are retained, also use `security-privacy-review`.
 - If queue, cache, retry, worker, health, or operational behavior changes, also use `backend-reliability-change`.
 - If user-perceived latency, throughput, allocation churn, GC pressure, or memory budget is claimed, also use `performance-budget-check`.
+- If counter, slope, denominator, benchmark, or regression-gate semantics dominate, also use
+  `performance-measurement-integrity-review`.
+- If socket, session, request-body, FIN/RST, pool reuse, or transport shutdown semantics dominate,
+  also use `connection-lifecycle-integrity-review`.
+- If the reported symptom does not yet have a deterministic reproduction, also use
+  `repro-first-debug` and keep exploratory runs separate from causal proof.
 - If UI lifecycle, rendering, or browser behavior changes, also use the matching UI or framework skill.
 
 <!-- mustflow-section: allowed-edits -->
@@ -79,6 +101,9 @@ The question is not only "where was it allocated?" The stronger review question
 - Add or tighten teardown, cancellation, ownership, weak-reference, eviction, queue-bound, stream-close, worker-shutdown, and lifecycle-symmetry code tied to the task.
 - Refactor setup and cleanup into a shared lifecycle boundary when it prevents duplicate registration or forgotten teardown.
 - Add focused tests, fixtures, probes, or docs that prove cleanup symmetry, bounded retention, repeated lifecycle behavior, or native-resource disposal when repository evidence supports them.
+- Add bounded owner, byte-flow, queue, post-GC, post-quiescent, handle, cache, or backpressure
+  instrumentation when it proves the changed lifetime boundary without retaining payloads or
+  sensitive context.
 - Do not hide leak warnings by raising listener limits, disabling strict lifecycle checks, adding finalizers as primary cleanup, or weakening tests.
 - Do not add object pools as a default leak or GC fix. Pool only heavy buffers, large arrays, native handles, or repeatedly allocated expensive objects after allocation evidence shows churn; ordinary short-lived records are often cheaper to let the generational collector reclaim.
 - Do not use weak references as a design cover-up when the real owner and cleanup point should be explicit.
@@ -136,6 +161,53 @@ The question is not only "where was it allocated?" The stronger review question
 15. Reject finalizers as the main plan. Finalizers, destructors, drop hooks, or weak callbacks can be last-resort diagnostics or safety nets, but the review should still identify deterministic cleanup for resources and reference removal.
 16. Separate allocation churn from retained memory. High allocation rate, GC pauses, retained heap, external memory, and RSS growth point to different fixes. Prefer allocation timeline, heap snapshot, retaining-path, `--trace-gc`, sanitizer, or runtime memory evidence when configured; report unconfigured tools as manual evidence instead of guessing from RSS alone.
 17. Add a repeated-lifecycle proof when feasible. Prefer a focused test or probe that repeats the risky lifecycle, then asserts listener count, registry size, cache size, goroutine/task completion, handle closure, queue depth, or retained object count. If heap snapshots, leak profilers, sanitizer runs, memory-checker runs, fuzzers, core dump inspection, or platform-specific diagnostics are not configured intents, report them as manual evidence gaps instead of running raw commands.
+18. Classify memory growth on independent axes before choosing a fix.
+    - Name the storage location: managed heap, external or backing-store memory, other native
+      allocation, mapping, allocator residency, cache, application queue, or kernel buffer.
+    - Name the retaining owner: request, attempt, branch, stream, task, cache, pool, connection,
+      native operation, retry, or process service.
+    - Name the terminal state: legitimate in-flight work, bounded backlog, unbounded backlog,
+      terminal retained resource, or released allocation whose pages remain resident.
+    - Do not derive native memory by subtracting overlapping process and runtime totals.
+19. Compare floors and slopes under controlled lifecycle phases.
+    - Fix concurrency, payload and chunk size, compression, protocol, retries, cache, branch count,
+      consumer rate, runtime, and allocator before comparison.
+    - Separate idle baseline, warmup, normal consumer, slow consumer, stopped consumer, admission
+      stop and drain, pool idle expiry, and optional isolated-GC phases.
+    - Prefer post-major-GC and post-quiescent growth per completed lifecycle with a predeclared
+      statistical tolerance over one RSS peak or literal zero-noise assertions.
+20. Model shared and branched work as an ownership DAG.
+    - Separate process, pool, connection or session, logical request, retry or hedge attempt,
+      protocol stream, clone or tee branch, file, transform, and telemetry ownership.
+    - Require every request-owned lease and byte reservation to return once while allowing a healthy
+      shared connection, session, or bounded cache to outlive the request.
+21. Trace backpressure from final commitment toward transport.
+    - Distinguish admitted, accepted, committed, released, cancelled, and discarded bytes at every
+      edge, keeping compressed, decoded, transformed, and durable byte domains separate.
+    - Stop the sink and identify the first edge whose queue continues to grow instead of plateauing
+      within its byte envelope; then resume and require drain and upstream progress to recover.
+    - Treat high-water marks as thresholds, not total caps, and include maximum chunk, in-flight
+      operations, side queues, branches, retries, codec expansion, protocol windows, and transport
+      buffers in the envelope.
+22. Calibrate the diagnosis to available evidence.
+    - Call growth a terminal leak only when the owner should have ended and retained counts or bytes
+      grow with completed lifecycle repetitions.
+    - Call fragmentation only after live heap, external memory, cache, queues, handles, mappings,
+      and native allocation evidence no longer explains resident growth.
+    - Report heap snapshots, native profilers, platform handle inspection, packet capture, qlog, and
+      long-running load as manual-only or missing unless configured by the selected repository.
+23. Design cross-runtime reproduction without changing the application and runtime together.
+    - Keep one shared compatibility-source case, a fixed observer, isolated server and client target
+      processes, explicit baseline/load/admission-stop/drain/quiescence phases, and fresh target
+      processes per measured run.
+    - Compare one factor at a time across producer rate, consumer delay, backpressure obedience,
+      finite versus continuing work, cancellation, reconnect, peer loss, concurrency, adapter,
+      runtime build, and operating-system cell. Treat ramps and multi-factor runs as exploratory.
+    - Record a versioned allowlisted manifest with configuration hash, observer identity, target
+      binary digest and build identity, environment cell, raw samples, completed work, queue and
+      resource conservation, repetitions, dispersion, and unsupported diagnostic phases.
+    - Call a newer green runtime version-localized or a fix candidate until last-bad, first-good,
+      comparable work, narrowed change, and forward or reverse change evidence establish cause.
 
 <!-- mustflow-section: postconditions -->
 ## Postconditions
@@ -147,6 +219,13 @@ The question is not only "where was it allocated?" The stronger review question
 - Async, stream, worker, goroutine, thread, and native-resource paths have deterministic cancellation, close, shutdown, or release behavior where the platform supports it.
 - Native or low-level memory fault analysis names the first invalid access evidence or reports the missing diagnostic boundary instead of blaming the final crash line.
 - Tests or configured verification cover the highest-risk repeated lifecycle when feasible.
+- Memory-growth conclusions identify storage location, retention owner, terminal status, controlled
+  workload phase, and evidence level; RSS alone does not establish leak or fragmentation.
+- Streaming and queue claims include accepted-versus-committed byte ownership, bounded plateau,
+  resume behavior, and a calculated envelope, or name the missing evidence.
+- Cross-runtime claims preserve shared source, fixed observer, single-factor comparators, target
+  binary and environment identity, completed-work normalization, repeated samples, and causal-fix
+  boundaries, or remain exploratory or version-localized.
 
 <!-- mustflow-section: verification -->
 ## Verification
@@ -173,6 +252,14 @@ Use the narrowest configured test, build, docs, release, or mustflow intent that
 - If setup and cleanup live in separate owners, make the ownership transfer explicit or report the split as a residual leak risk.
 - If repeated-lifecycle proof requires unconfigured heap, profiler, sanitizer, browser, device, or load-test access, report the missing manual evidence and complete the configured checks that are available.
 - If leak reduction conflicts with product semantics, authorization, durability, observability, or retry behavior, use the relevant stronger skill and report the tradeoff.
+- If queues drain but their maximum is unbounded, report an OOM or admission-control defect rather
+  than clearing the path merely because it is not a terminal leak.
+- If RSS remains high after live owners fall, do not jump directly to fragmentation; report the
+  missing allocator, mapping, native-allocation, or platform evidence.
+- If a runtime comparison changes source behavior, adapter, workload, environment, and runtime
+  together, reject causal attribution and split it into single-factor cells.
+- If an external or attachment-linked harness file was not supplied as repository source, do not
+  claim it was implemented or executed; adapt only the observable procedure contract.
 
 <!-- mustflow-section: output-format -->
 ## Output Format
@@ -183,6 +270,11 @@ Use the narrowest configured test, build, docs, release, or mustflow intent that
 - Long-lived owners and short-lived objects checked
 - Timers, listeners, subscriptions, streams, workers, goroutines, threads, native handles, caches, queues, registries, closures, and logs checked where relevant
 - Weak metadata, object pooling, allocation churn, and GC diagnostics checked where relevant
+- Storage location, retention owner, terminal status, post-GC and post-quiescent slope classification
+- Request, attempt, branch, stream, shared-pool, cache, file, and native-operation ownership DAG
+- Backpressure edge ledger, stopped-consumer plateau, resume behavior, and memory envelope
+- Cross-runtime observer and target isolation, lifecycle phases, comparator matrix, result identity,
+  environment cells, completed-work normalization, and causal-fix classification
 - First invalid access, diagnostic build axis, dangling ownership, fuzzing or core-dump evidence where relevant
 - Cleanup symmetry changes made or recommended
 - Repeated-lifecycle proof: configured, manual-only, missing, or not applicable

package/templates/default/locales/en/.mustflow/skills/memory-lifetime-review/references/cross-runtime-memory-stream-reproduction-harness.md

@@ -0,0 +1,289 @@
+# Cross-Runtime Memory and Stream Reproduction Harness
+
+Use this reference when a memory, external-buffer, stream-queue, socket, file-descriptor, handle,
+or allocator symptom must be reproduced across Node-compatible runtimes such as Node.js and Bun.
+Use the main skill first for ownership and diagnosis. Use this reference to design the controlled
+process harness and comparison evidence.
+
+## Contents
+
+1. [Freeze the comparison boundary](#1-freeze-the-comparison-boundary)
+2. [Separate observer and target processes](#2-separate-observer-and-target-processes)
+3. [Run explicit lifecycle phases](#3-run-explicit-lifecycle-phases)
+4. [Collect a non-overlapping metric ledger](#4-collect-a-non-overlapping-metric-ledger)
+5. [Change one factor per comparator](#5-change-one-factor-per-comparator)
+6. [Make result identity reproducible](#6-make-result-identity-reproducible)
+7. [Compare slopes, floors, and conservation](#7-compare-slopes-floors-and-conservation)
+8. [Separate runtime, adapter, and operating-system cells](#8-separate-runtime-adapter-and-operating-system-cells)
+9. [Narrow application versus runtime ownership](#9-narrow-application-versus-runtime-ownership)
+10. [Require causal fix evidence](#10-require-causal-fix-evidence)
+11. [Keep commands and artifacts bounded](#11-keep-commands-and-artifacts-bounded)
+12. [Acceptance gate](#12-acceptance-gate)
+
+## 1. Freeze the comparison boundary
+
+Start with one source program that uses only the compatibility surface shared by every target
+runtime. For a Node-compatible HTTP stream symptom, keep the request, response, Buffer,
+EventEmitter, chunk production, consumer delay, cancellation, and accounting logic identical.
+
+Do not replace the application API and runtime in the same comparison. If a native server adapter
+such as `Bun.serve` is suspected, first establish the shared `node:http` comparator. Change only the
+server adapter in the next cell. Otherwise an API difference, application rewrite, and runtime
+difference become one confounded observation.
+
+Freeze before measuring:
+
+- scenario and expected terminal outcome;
+- payload, chunk size, burst size, production rate, consumer rate, and compression;
+- concurrency, connection reuse, retries, cancellation schedule, and total offered work;
+- observation interval, warmup, load duration, quiescence interval, and stop deadline;
+- runtime flags, allocator settings, container limits, CPU quota, and cache state;
+- measurement schema, thresholds, normalization, repetitions, and statistical rule.
+
+Treat an exploratory threshold as a trigger for a narrower experiment, not as a portable proof.
+Queue, retained-memory, and RSS thresholds depend on chunk size, concurrency, runtime, allocator,
+host pressure, and instrumentation overhead.
+
+## 2. Separate observer and target processes
+
+Use a fixed observer process to launch and sample separate server and client target processes. Keep
+the observer runtime and implementation unchanged while target runtimes or versions vary.
+
+The process split should preserve evidence when either target exits, crashes, is cancelled, or is
+forcibly terminated. Use loopback or an equivalently isolated local transport unless the production
+network path is the variable under study. Start every measured run in fresh target processes so
+allocator and runtime state from a previous case does not contaminate the next case.
+
+Keep three ledgers distinct:
+
+| Ledger | Owner | Examples |
+|---|---|---|
+| Observer | Fixed harness process | target identity, OS samples, deadlines, result writing |
+| Server target | Runtime under test | response queues, accepted writes, sockets, request lifecycle |
+| Client target | Runtime under test | readable queues, consumed bytes, cancellation, client sockets |
+
+Do not count observer timers, pipes, handles, listeners, or output buffers as target resources. Do
+not let a killed client destroy the only copy of the server or OS evidence.
+
+## 3. Run explicit lifecycle phases
+
+Use the same ordered phases for every measured run:
+
+| Phase | Required action | Evidence |
+|---|---|---|
+| Baseline | Start targets, complete runtime initialization, perform only configured or manual GC, then sample | Memory floors, sockets, descriptors or handles, listeners, timers |
+| Warmup | Exercise enough work to initialize JIT, pools, parsers, and caches without entering the measured interval | Warm state and any one-time growth |
+| Load | Run exactly one fixed case and sample at a declared cadence | Slopes, peaks, throughput, queue and request maxima |
+| Admission stop | Stop creating new work while keeping targets alive | Closed cohort and remaining in-flight work |
+| Drain or cancellation | Consume, cancel, disconnect, or kill according to the case | Terminal outcomes and resource-release progress |
+| Quiescence | Wait a bounded interval for close, abort, error, native release, and pool expiry | Post-quiescent floor and unresolved owners |
+| Post-GC observations | When supported and authorized, take at least two separated observations | Reachable heap or external retention versus delayed reclamation |
+| Shutdown | End targets through the case-specific path and preserve the observer result | Exit status, final resource counts, incomplete cleanup |
+
+Mark GC support per runtime and run. Exclude unsupported or failed GC phases from GC-retention claims
+instead of treating them as zero. A forced collection is a diagnostic separator, not an application
+cleanup mechanism.
+
+## 4. Collect a non-overlapping metric ledger
+
+Record runtime-internal and independent OS observations together, but preserve their semantics.
+
+| Metric | What it supports | What it does not prove |
+|---|---|---|
+| Runtime RSS | Process resident growth as reported by the runtime | JavaScript leak or allocator cause |
+| OS resident or working set | Independent process-residency observation | Live ownership or reclaimability |
+| `heapUsed` | Managed heap currently used according to the runtime | Buffer, kernel, or all native ownership |
+| `heapTotal` | Managed heap capacity reserved by the runtime | Live heap or leak size |
+| `external` | Runtime-defined memory associated with managed objects | Every native allocation |
+| `arrayBuffers` | Runtime-defined ArrayBuffer and Buffer backing-store memory | Cross-runtime identical accounting |
+| Active socket registry | Application-observed live sockets | Kernel `TIME_WAIT` or every handle |
+| File descriptors | Open files, sockets, pipes, and other descriptors | Exact leaked resource type without classification |
+| Windows handle count | Open process handles across Windows object types | Socket count or Unix-FD equivalence |
+| Active resource types | Runtime resource-type summary that may keep the event loop alive | Concrete handle identity or full OS inventory |
+| Listener and timer ledger | Harness-known registrations and pending scheduled work | Every runtime-internal callback |
+| Readable and writable queue lengths | Visible stream-layer queued bytes or objects | Kernel, TLS, parser, or hidden native queues |
+| Per-request queue maximum | A single request or stream dominating memory | Whole-process memory |
+| Open and terminal event counts | Missing lifecycle settlement or close imbalance | Cause without owner and path evidence |
+
+For Node.js, `arrayBuffers` is included in `external`; do not add them as disjoint totals. Confirm
+equivalent fields against the target runtime version because a Node-compatible API name does not
+guarantee identical engine accounting. In object mode, queue lengths may count objects rather than
+bytes; record the unit.
+
+Track at least produced, accepted, committed or consumed, cancelled, discarded, and released bytes.
+Keep server and client totals separate. A produced-minus-consumed gap can reside in application,
+stream, runtime, kernel, or discarded work, so localize it with per-edge queues and terminal events.
+
+## 5. Change one factor per comparator
+
+Use paired cases that isolate one causal question:
+
+| Comparator | Only changed factor | Question |
+|---|---|---|
+| Paced producer / fast producer | Production interval | Does producer rate trigger the symptom? |
+| Fast consumer / slow consumer | Consumer delay | Does sink speed expose backlog? |
+| Obey backpressure / ignore backpressure | Production admission after backpressure | Is growth application-created buffering? |
+| Finite stream / continuing stream | Terminal production bound | Does cleanup depend on natural completion? |
+| Graceful completion / mid-stream cancel | Cancellation schedule | Does abort cleanup release every owner? |
+| One cancel / repeated reconnect | Lifecycle repetition | Does each completed cycle leave residue? |
+| Graceful peer exit / forced peer loss | Peer termination mode | Does abrupt loss break finalization? |
+| Fixed low / medium / high concurrency | Concurrency | Is cost linear, bounded, or explosive? |
+
+A concurrency ramp is useful for finding a threshold, but it changes load continuously. Use it only
+for exploration. Re-run fixed cells on both sides of the discovered threshold before attributing
+cause.
+
+The ignore-backpressure case is an intentional positive control, not a healthy implementation. It
+should demonstrate that the harness can detect a growing visible queue. The obey-backpressure case
+should plateau within a predeclared envelope and resume after drain.
+
+## 6. Make result identity reproducible
+
+Write a versioned allowlisted result manifest with:
+
+- scenario name and configuration hash;
+- absolute target binary identity represented safely, binary digest, runtime version, and runtime
+  revision or build identifier when available;
+- observer build identity and result-schema version;
+- operating-system release, architecture, CPU count, memory limit, container or cgroup boundary,
+  allocator class, and relevant runtime flags;
+- payload, chunk, burst, production, consumer, concurrency, cancellation, and duration settings;
+- warmup count, measured repetitions, order block, sample cadence, and GC support;
+- terminal outcomes, throughput, queue maxima, slopes, post-quiescent floors, and evidence gaps.
+
+Do not emit unrestricted arguments, environment variables, paths, URLs, headers, payloads, or
+credentials. Store logical path labels or allowlisted environment fields. Treat NDJSON, heap,
+allocation, trace, packet, and native-profile artifacts as sensitive evidence.
+
+Reject a same-case runtime comparison when configuration hashes differ. For an intentional paired
+case, allow the declared factor and reject every undeclared difference. A multi-factor exploratory
+run may guide the next test but cannot prove a cause.
+
+## 7. Compare slopes, floors, and conservation
+
+Compare server and client separately. Use raw samples and report at least:
+
+- runtime and OS residency slopes during the fixed load phase;
+- managed heap, external, and ArrayBuffer slopes and post-quiescent deltas;
+- visible stream-queue slope, maximum total queue, and maximum per-request queue;
+- active sockets, descriptors or handles, listeners, timers, and open-minus-terminal counts;
+- produced, accepted, committed or consumed, cancelled, discarded, and released byte differences;
+- throughput-normalized memory growth when runtimes complete materially different work;
+- median, dispersion, practical threshold, uncertainty decision, and rejected outliers.
+
+Do not call a faster runtime leakier merely because it processed more bytes in the same wall time.
+Preserve absolute memory and memory per completed unit. Likewise, a slower candidate is not fixed if
+it merely produces fewer bytes before the deadline.
+
+Use interleaved or randomized comparison blocks on the same machine when feasible. Avoid running
+every old-runtime sample before every new-runtime sample because temperature, CPU boost, file cache,
+system load, and memory pressure drift with time. Never rerun until a favorable sample appears.
+
+Require conservation within a declared snapshot tolerance. Examples include started equals terminal
+plus in-flight, accepted writes equal settled writes plus pending writes, and reserved bytes equal
+current plus released or terminally discarded bytes.
+
+## 8. Separate runtime, adapter, and operating-system cells
+
+Build the matrix in layers:
+
+1. Compare the same compatibility-source case on the problem runtime and a control runtime.
+2. Compare the problem runtime with the immediately relevant prior or candidate build.
+3. Change only the server adapter, such as compatibility HTTP versus a native server surface.
+4. Change only the protocol layer, such as HTTP versus a raw TCP stream.
+5. Repeat the same bad and good pair on a second representative operating-system cell.
+
+Keep Linux glibc, Linux musl, container or cgroup Linux, macOS architectures, Windows architectures,
+and WSL as distinct environment cells. Compare absolute RSS only within compatible OS,
+architecture, allocator, and resource-limit boundaries. WSL is a Linux kernel environment for this
+purpose, not a Windows IOCP cell.
+
+Record allocator and memory-limit evidence. A stable managed heap with elevated RSS can reflect
+allocator residency or unmeasured native ownership, but this pattern alone does not distinguish the
+two.
+
+## 9. Narrow application versus runtime ownership
+
+Use the smallest next single change supported by the result:
+
+| Observation | Next boundary |
+|---|---|
+| Ignore-backpressure grows on all runtimes; obey case is bounded | Application admission and queue policy |
+| Shared compatibility source fails on only one runtime | That runtime's compatibility HTTP, stream, or socket bridge |
+| Compatibility and native server adapters both fail | Shared stream, socket, allocator, or engine layer |
+| Only the native server adapter fails | Native response sink, abort, and backpressure path |
+| Raw TCP also fails | HTTP parser is below the likely boundary; inspect TCP, buffer, poller, or event loop |
+| Raw TCP is bounded | HTTP request, response, parser, or adapter lifecycle |
+| Fresh Buffer allocation fails but reuse is bounded | Backing-store allocation and release path |
+| Buffer reuse also fails | Request, stream, socket, or hidden queue ownership |
+| Descriptors or handles remain after close | Socket, poll, watcher, file, or process-resource finalization |
+| All owned resources return but RSS remains | Allocator or unmeasured native-memory diagnostics |
+
+Classify the owner as application, library or adapter, runtime, dependency, allocator, operating
+system, or unresolved. A green case at one layer only removes hypotheses that the comparator
+actually held constant.
+
+## 10. Require causal fix evidence
+
+A symptom disappearing in a newer runtime is a candidate signal, not root-cause proof. Large runtime
+or engine changes can alter allocator behavior, HTTP implementation, throughput, scheduling, and
+object lifetime together.
+
+For a permanent-resolution claim, require where feasible:
+
+- exact last-bad and first-good build identities and binary digests;
+- comparable completed work and the healthy control case remaining healthy;
+- a narrowed runtime or dependency change interval;
+- the candidate change applied to the bad base and the symptom removed;
+- the candidate change removed from the good base and the symptom restored;
+- upstream cause identity for vendored engine, allocator, parser, or event-loop changes;
+- a regression guard on bounded queues, post-quiescent ownership, and resource return rather than
+  an RSS-only literal threshold;
+- repeated results and at least one second relevant environment cell.
+
+If patch and revert builds are unavailable, report the result as version-localized or a fix
+candidate. Do not upgrade the claim to causal resolution.
+
+## 11. Keep commands and artifacts bounded
+
+This reference does not authorize launching servers, load generators, child-process campaigns,
+runtime downloads, profilers, packet tools, heap snapshots, dependency installs, network calls, or
+long-running loops. Map execution to configured one-shot command intents. Mark unavailable runtime,
+OS, profiler, or soak cells as manual-only or missing.
+
+When authoring a durable repository harness, follow the repository's supported scripting runtime and
+place it under the repository's declared test or tooling boundary. Give every run a hard deadline,
+closed stdin, output cap, process-tree cleanup, isolated output directory, and maximum memory or
+workload safety stop. Preserve the primary failure if cleanup also fails.
+
+Do not claim an attachment-linked or external harness file exists in the repository unless its bytes
+were supplied and admitted as a source artifact. A prose design can justify a reference contract,
+not an executable harness implementation.
+
+## 12. Acceptance gate
+
+Accept the reproduction design only when:
+
+- observer, server, client, and OS evidence owners are separated;
+- shared-source runtime comparison changes no application behavior;
+- lifecycle phases and closed-cohort termination are explicit;
+- metric units do not overlap or silently change across runtimes;
+- every paired comparator declares exactly one changed factor;
+- result identity includes runtime build and configuration evidence;
+- comparison uses repeated raw samples, dispersion, and completed-work normalization;
+- environment cells are compared within compatible boundaries;
+- application, adapter, runtime, allocator, and OS attribution remains no broader than the evidence;
+- a newer green version is not called causal without last-bad, first-good, and forward or reverse
+  change evidence;
+- unconfigured runtime, load, GC, profiler, packet, and OS diagnostics remain manual-only or missing;
+- sensitive result artifacts have a versioned allowlisted schema and bounded retention.
+
+## Primary references
+
+- Node.js process memory and active-resource documentation
+- Node.js stream backpressure and queue introspection documentation
+- Bun runtime and memory-profiling documentation for the exact target version
+- Operating-system process-memory, descriptor, and handle documentation for the tested cell
+
+Verify version-sensitive behavior against the exact runtime build under test. A compatibility API
+name is not evidence that two engines report memory or resource state identically.