Engineering a Lean Experimental-Methods Lifecycle for TinyRustLM

Full report

On this page

The primary recommendation of this comprehensive analysis is to institute an immutable, append-only experimental lifecycle utilizing the formal Delta Debugging algorithm for causal isolation, paired with strict operating-system-level environment allowlisting for preflight checks. Furthermore, the engineering process must adopt a structured, Git-tracked ledger for extracting durable engineering lessons while enforcing aggressive, immediate deletion of superseded model artifacts. The most significant risk to this recommendation is that enforcing strict preflight and immutable ledgers introduces operational friction that could initially slow developer velocity, potentially leading engineers to bypass the system for quick, undocumented trials if the tooling is not seamlessly integrated into the orchestration pipeline.

Operating as an independent research agent without direct access to the project's private source code, machines, or credentials, this analysis relies entirely on the provided project-supplied facts and externally verified literature. Because direct internet access to audit current live repositories is unavailable, all externally verified facts are drawn from the provided canonical research corpus, distinguishing strictly between local unverified conditions and established systems engineering standards.

\[Project-Supplied Fact\] The TinyRustLM project currently lacks an established qualified default model or proven live initial seed in the supplied engineering checkpoint. \[Project-Supplied Fact\] Structural conversion and synthetic tests passing do not establish useful model behavior. \[Project-Supplied Fact\] The sole current composition is bound to six specific artifact identities: model.slm2, tokenizer.tokenizer2, template.template2, sampling.sampling2, prompt.prompt2, and composition.acg2. \[Recommendation\] The system must automatically restore a usable installed model or obtain a small working default through MiniModel.org upon first launch, relegating Hugging Face integrations, custom peers, and local-file imports strictly to advanced configuration layers. MiniModel.org is explicitly authorized to supply these initial server seeds, superseding any historical project prose to the contrary.

Decoupling Execution from Product Claims

A fundamental breakdown in experimental engineering occurs when the vocabulary used to describe system behavior conflates toolchain execution with product success. An execution environment, input identity, procedure, observation, and interpretation must be explicitly separated to establish a rigorous experimental lifecycle.

Source and tool identity define the exact binaries and scripts used to execute a run, managed strictly via Git under E:\\Source\\Rust\\TinyRustLM.com. The execution environment constitutes the complete hardware and OS-level state during the run, including memory limits, environment variables, and filesystem mounts. Input and model identity encompass the exact cryptographic hashes of the six composition artifacts stored in D:\\LLMs\\TinyRustLM. The procedure is the sequence of operations applied, while the observation is the raw, uninterpreted telemetry, such as exit codes, byte outputs, and trace logs. Interpretation is the human or algorithmic classification of that observation.

A "verification pass" strictly means that the procedure executed without fatal interruption and that the prior failure mode was faithfully preserved or averted. It does not mean "the product works." If a structural conversion script successfully outputs a model.slm2 file without throwing an exception, the observation is merely that a file was written to the disk. The interpretation is that the structural conversion phase passed. Claiming that the model is qualified based on a structural pass is a severe epistemological error.

Product claims require end-to-end evaluation against human-perceptible quality gates, such as generating coherent natural language within defined latency bounds inside the browser-local WebAssembly (WASM) runtime. \[Externally Verified Fact\] According to the ISO/IEC 25059 quality model for artificial intelligence systems, "functional correctness" in machine learning encompasses probabilistic outputs and expected error rates, differing fundamentally from deterministic software correctness1. Because AI systems produce probabilistic outputs rather than deterministic answers, evaluating functional correctness requires measuring instances where the system functions correctly alongside instances where it fails, utilizing metrics like accuracy, recall, and F1-score over a statistically significant sample2. A single successful token generation does not validate the sampling.sampling2 or prompt.prompt2 configurations.

To prevent evidence sprawl, the engineering process must distinguish between a lightweight development test and a formal experiment. A lightweight development test requires no preregistration; its artifacts are ephemeral, and its purpose is syntax checking, compiler verification, or sanity-checking a script modification. An experiment deserves preregistration and immutable evidence when it seeks to qualify a new model payload, test a novel architectural hypothesis, or resolve a causal debugging query where the result will alter the canonical codebase or the default MiniModel.org seed. \[Recommendation\] Immutable evidence should consist of the input hashes, the environment preflight signature, and the quantitative summary of the output. Massive intermediate trace logs and raw activations must be discarded immediately upon the successful extraction of the lesson to prevent storage exhaustion.

Bounded Environment Preflight

\[Project-Supplied Fact\] Historical failures within the project include a Rust child process lacking the MSVC linker (link.exe), Python environment setups producing invalid package metadata, virtual environment probes leaving dangling links, and Node.js propagating an unwanted NODE\_V8\_COVERAGE variable. These are environmental contamination failures, not model failures, and they routinely destroy the integrity of experimental control.

To eliminate redundant setup failures, a bounded environment preflight must execute before any expensive model conversion or inference experiment. This preflight proves that the child process can utilize required compiler runtimes and load the model artifacts safely in strict isolation.

Python isolation requires aggressive execution flags to prevent user-site package metadata from poisoning the virtual environment, which historically caused invalid package metadata and dangling links. \[Externally Verified Fact\] Executing the Python interpreter with the \-I (isolated) flag forces the runtime to ignore all PYTHON\* environment variables, such as PYTHONPATH and PYTHONHOME, and explicitly prevents the addition of the user's site-packages directory (\~/.local/lib or %APPDATA%\\Python) to sys.path6. This guarantees that the Python scripts manipulating model.slm2 execute identically across different developer machines.

Node.js isolates must explicitly nullify coverage variables. \[Project-Supplied Fact\] Node 24 propagates its parent's NODE\_V8\_COVERAGE into an explicit environment when that property is absent, causing launch failures when environments are nominally frozen. \[Externally Verified Fact\] The NODE\_V8\_COVERAGE environment variable is automatically inherited by child processes spawned by Node.js, and the only supported mechanism to prevent this propagation is explicitly setting the variable to an empty string (NODE\_V8\_COVERAGE="")9. Freezing the environment by copying process.env is insufficient because the operating system environment block still contains the key.

Rust and MSVC linker isolation on Windows requires deliberate handling of the environment block passed to the underlying CreateProcessW API. \[Project-Supplied Fact\] A Rust child process previously failed because it lacked the installed MSVC linker in its effective PATH. \[Externally Verified Fact\] The std::process::Command::env\_clear() method in Rust strips all environment variables to create a sterile execution state13. However, the MSVC toolchain, specifically link.exe, fundamentally relies on the PATH, SYSTEMROOT, and LIB environment variables to locate the Windows SDK and necessary dynamically linked libraries like mspdbcore.dll16. Stripping these variables guarantees a linker failure. \[Recommendation\] The preflight orchestrator must use an allowlist approach, capturing SYSTEMROOT, PATH (filtered strictly to the MSVC toolchain and Git), and LIB, explicitly passing them to the child process using .envs() rather than relying on a blind .env\_clear().

Bounded Preflight Schema

 

Failure Taxonomy and Recording Methodology

Treating missing evidence as a measured negative or fabricating causal diagnoses from generic errors severely degrades engineering knowledge. A missing log file means the logging system failed or the process was interrupted; it does not mean the model generated zero tokens.

\[Project-Supplied Fact\] A historical failure occurred where the converter confused physical tensor inventory with logical tied weights. This is an example of an architectural metadata failure heavily dependent on the underlying tensor storage format. \[Externally Verified Fact\] The Safetensors format forbids two tensor names from pointing at overlapping byte ranges to prevent security vulnerabilities related to polyglot file execution21. When an architecture logically ties the token embedding matrix to the output projection matrix, a converter must either physically duplicate the tensor payload into two distinct byte ranges or drop one name and rely on an architectural configuration flag like tie\_word\_embeddings21. A failure here is a semantic tooling rejection, not a numerical inference failure. Similarly, a real source-model trace failing at load time before numerical comparisons run is a structural rejection, which must not be conflated with a mathematical divergence.

Failures must be classified strictly based on the exact stage of execution at which the procedure halted or diverged from the expected baseline. \[Recommendation\] When recording interrupted execution, timeouts, or partial outputs, the experiment record must state exactly how many bytes were processed, the exact timestamp of the interruption, and the system state at that moment. Stages never started must be logged as UNREACHED, never as FAILED or PASSED. Inventing a causal diagnosis from a generic "process exited with code 1" error masks the true nature of the failure.

Taxonomy of Experimental Failures

Causal Debugging and Factor Isolation

Changing multiple variables simultaneously and keeping the "best" outcome is unauthorized replay and meaningless best-of\-[Figure omitted from source export] selection. It results in superstitious programming where engineers do not know why a configuration works, only that it happened to pass once. Causal debugging requires stating competing hypotheses, changing precisely one material factor at a time, and utilizing algorithmic isolation to pinpoint faults.

When a payload or configuration fails, isolating the exact failure-inducing parameter requires systematic reduction. \[Externally Verified Fact\] The Delta Debugging algorithm (ddmin), originally formalized by Zeller and Hildebrandt, is a systematic iterative approach for reducing a failure-inducing input to a 1-minimal subset that still produces the failure22. The algorithm operates on a set of atomic units representing the test case, splitting the configuration into subsets ([Figure omitted from source export]) and testing if the subset alone triggers the failure ("reduce to subset"). If not, it tests the complements ([Figure omitted from source export]) to see if the failure persists when a subset is removed ("reduce to complement"). If neither triggers the failure, it increases the granularity of the split23.

\[Externally Verified Fact\] The worst-case asymptotic complexity of the ddmin algorithm is [Figure omitted from source export], where [Figure omitted from source export] is the number of elements in the configuration26. Because this can be computationally expensive for massive language model configurations, the application of Delta Debugging must be strictly bounded by information value and computational cost.

If a newly constructed model.slm2 payload fails to load in the composition.acg2 WASM runtime, the engineer must not simply re-run the entire conversion pipeline with different random seeds. Instead, the engineer must formulate competing hypotheses: Hypothesis A: The payload exceeds the 4GB WASM linear memory limit. Hypothesis B: The payload contains overlapping tensor byte offsets that violate the zero-copy memory mapping format.

The next experiment is selected based on information value and cost. Checking the payload size (Hypothesis A) takes milliseconds and costs virtually zero compute. Running a Python script to validate non-overlapping byte offsets (Hypothesis B) takes seconds. Re-quantizing the entire model to test a different data type takes hours. Therefore, Hypothesis A and B are tested first. If both pass, the engineer applies Delta Debugging to the tensor payload: artificially truncating the model.slm2 file to contain only the first half of the layers, bypassing actual inference, and merely testing the memory-mapping load phase to see if the engine panics on a specific corrupted layer.

Repeating a run is only valid when testing for environmental non-determinism, such as race conditions, hardware thermal throttling, or thread scheduling jitter. When repeating a run for this purpose, it must be explicitly preregistered and recorded as a stability test, not a feature test.

Hypothesis-to-Experiment Matrix

Compact Experiment Ledger and Reusable Lessons

To learn from experiments without creating evidence sprawl, historical log files must be distilled into a compact ledger. Huge logs, copied source code, and historical gigabyte checkpoints must not proliferate. The ledger preserves exact identities, numerical summaries, representative failure strings, uncertainty, and links to the canonical Git commit.

\[Locally Unverified Condition\] Assuming the project utilizes a standard text-based tracking system, the ledger should be maintained as an append-only Markdown or JSONL file tracked directly in the E:\\Source\\Rust\\TinyRustLM.com repository. This ensures that the ledger evolves alongside the code and is subject to the same version control, providing immutable cryptographic provenance via Git SHA. The ledger must not turn into a stale source of authority; if the code diverges, the code is the source of truth, and the ledger is merely the historical record of why the code was written.

Summarizing Ten Failed Runs Without Erasure

When an engineer conducts ten attempts to resolve the NODE\_V8\_COVERAGE poisoning issue, keeping all ten identical stack traces is evidence sprawl. However, erasing the nine failed attempts to only document the tenth successful run erases inconvenient outcomes and destroys the causal history, leaving future engineers vulnerable to repeating the exact same nine mistakes.

The correct methodology is to collapse the ten runs into a single ledger entry that documents the trajectory of the Delta Debugging process. The entry records the bounded inputs tested, the invariant failure mode observed across the first nine runs, and the specific isolated factor that flipped the outcome on the tenth run.

Example Experiment Records

1\. Environment Failure (S-Class)Question: Does passing an empty string to NODE\_V8\_COVERAGE prevent WASM initialization panics inherited from the parent Node process?Exact Inputs: composition.acg2 (SHA: 8f4a...), Node.js v24 executable.Method: Spawn child process via orchestrator with env("NODE\_V8\_COVERAGE", "") applied to the Rust Command builder, overriding the inherited block.Result: Process successfully initialized WASM runtime. Internal diagnostic log confirmed process.env.NODE\_V8\_COVERAGE was strictly empty.Uncertainty: Minimal. Behavior matches official Node.js documentation regarding variable propagation.Decision: Hardcode the empty string override in the orchestrator pipeline.Reusable Lesson: Node.js explicitly requires empty string assignment to halt prototype environment inheritance; env\_clear() or cloning process.env does not sanitize parent coverage flags passed via the OS block.Evidence Identity: Git Commit 4a2b9f.

2\. Structural Pass (F-Class)Question: Can the model.slm2 converter handle tied word embeddings without duplicating tensor payloads?Exact Inputs: Source weights (SHA: 1c8e...), Conversion Script (SHA: 9d3c...).Method: Run conversion script with configuration flag duplicate\_tied=false.Result: File generated successfully, but the Rust loader's header validation panicked during mmap. Error string: "Overlapping tensor data offsets detected".Uncertainty: None. The binary format specification strictly forbids overlap to prevent security exploits.Decision: Mandate payload byte duplication for tied weights in the model.slm2 generator script.Reusable Lesson: Physical file size must linearly increase for tied-weight models because the chosen serialization format enforces strict byte-range uniqueness for zero-copy memory mapping validation.Evidence Identity: Git Commit 77b1a2.

3\. Numerical Disagreement (N-Class)Question: Does the WebAssembly v128 SIMD implementation of the GELU activation function match the scalar baseline?Exact Inputs: Synthetic input tensor (SHA: 22d1...), composition.acg2 SIMD branch.Method: Run 10,000 forward passes, compute mean absolute error (MAE) against deterministic scalar output.Result: MAE \= 0.0042. Maximum absolute error \= 0.015.Uncertainty: The error distribution is non-uniform; the largest divergence occurs near the origin due to polynomial approximation limits.Decision: Reject SIMD branch for current deployment. Error exceeds the project-defined epsilon threshold of 0.001.Reusable Lesson: Polynomial approximations used in the WASM SIMD GELU kernel lack sufficient precision for current quantization thresholds, causing unacceptable numerical drift in deep networks.Evidence Identity: Git Commit 55e8c1.

4\. Quality Failure (Q-Class)Question: Does setting the default repetition penalty to 1.15 improve MiniModel.org seed conversational coherence?Exact Inputs: sampling.sampling2 (rep\_penalty=1.15), MiniModel.org seed model (SHA: 99a4...).Method: Generate 50 outputs using the standard evaluation prompt suite, measured against human-perceptible utility gates.Result: 14 out of 50 outputs degraded into endless loops of whitespace and punctuation.Uncertainty: High. Model behavior is highly sensitive to the exact prompt template used in prompt.prompt2.Decision: Roll back to 1.0 (no penalty).Reusable Lesson: The specific model.slm2 architecture reacts catastrophically to repetition penalties \> 1.1, destroying vocabulary probability distributions and triggering degenerative whitespace loops.Evidence Identity: Git Commit 33f9b2.

5\. Genuine ImprovementQuestion: Does aligning all tensor offsets to 32-byte boundaries decrease WASM mmap load time?Exact Inputs: model.slm2 (Aligned, SHA: 44b2...), model.slm2 (Unaligned, SHA: 11c3...).Method: Execute composition.acg2 load sequence 100 times for each payload to calculate a statistical mean.Result: Aligned load mean: 45ms. Unaligned load mean: 310ms.Uncertainty: Negligible. Results are highly deterministic across runs.Decision: Update structural converter to permanently enforce 32-byte padding.Reusable Lesson: WASM memory-mapped I/O incurs massive page-fault penalties when misaligned; padding wastes trivial disk space but yields an 85% reduction in latency.Evidence Identity: Git Commit 88d4e5.

Artifact Retention, Windows File Locks, and Deletion

Historical model copies must not proliferate in D:\\LLMs\\TinyRustLM. Retaining obsolete artifacts wastes storage, creates evidence sprawl, and introduces severe ambiguity regarding which payload is canonical. \[Recommendation\] Once a replacement payload is validated and marked active in the ledger, the superseded payload must be securely deleted from the local disk after an exact identity review.

\[Project-Supplied Fact\] The project explicitly asks that source and model copies must not proliferate, but some old cleanup output remains because deletion was blocked. No alternate deletion route is authorized by that fact.

\[Externally Verified Fact\] On the Windows operating system, attempting to delete a file that is currently memory-mapped or locked by an active file handle will fail, resulting in either an access denied error or placing the file into a deferred deletion state where the unlinking is delayed until all handles are closed28. If child processes (such as a crashed Python diagnostic probe or a detached Node.js worker) inherit file handles during CreateProcessW because the bInheritHandles flag was improperly managed, the file remains locked indefinitely, even if the parent orchestrator exits successfully30.

To enforce strict deletion on Windows and comply with project directives, the orchestrator must explicitly invoke CloseHandle on all memory mappings and file streams. The implementation must ensure all child processes spawned during the experiment are forcefully terminated if they panic, and it must implement a retry loop with exponential backoff for file deletion to account for asynchronous antivirus scanning locks that briefly seize file handles immediately after modification.

Deletion and Retirement Criteria

Incorporating External Research Reports

External research reports frequently present marketing claims and benchmark tables that lack rigorous applicability to the specific constraints of browser-local WASM execution. Relying solely on these tables generates redundant experiments that fail because fundamental architectural constraints were ignored. \[Recommendation\] New research reports must be subjected to a strict filtering matrix: Validate, Decide, Test, and Update.

1. Validate Claims: Cross-reference external claims against the project's non-negotiable requirements. If a paper claims a massive inference speedup but the methodology relies on NVIDIA CUDA kernels or PyTorch custom operators, the claim is instantly rejected because TinyRustLM requires strictly local WASM/CPU execution.

2. Decide (Apply/Reject/Test/Defer): If the research claims a novel sampling algorithm reduces repetition without requiring hardware acceleration, decide to Test.

3. Run the Smallest Discriminating Experiment: Do not implement the entire paper end-to-end. Implement the isolated mathematical kernel in a Rust unit test. Measure its latency and output distribution against a synthetic logit tensor. This is the smallest experiment capable of falsifying the paper's claim in the local environment, reducing wasted engineering time on full-scale integrations that are doomed to fail.

4. Update Current Guidance: If the local experiment passes, update the ledger. Never treat external recommendations as local results. A statement like "Paper X proved algorithm Y" is invalid and constitutes an epistemological failure; the ledger must read, "Local implementation of Algorithm Y (Commit Z) on architecture W yielded result V."

Process controls whose cost exceeds their benefit for this prerelease product include requiring peer-reviewed statistical significance testing (like ANOVA) for minor UI changes, or maintaining full historical archives of every generated test token. These practices create unacceptable friction. Conversely, the metric for reducing wasted engineering time is the "Time-to-Falsification": the duration between an engineer proposing a hypothesis and the preflight or ddmin script definitively rejecting it. Driving this metric down to seconds is the core objective of this methodology.

Specific Engineering Implementations and Falsifiability

An engineer must be able to act on this methodology without requiring another broad literature review. The exact sequence of implementation to establish this lean lifecycle is as follows:

1. Phase 1: Sterile Execution. Implement the Bounded Environment Preflight script within the orchestrator entry point. This script must actively enforce the Node.js NODE\_V8\_COVERAGE sanitization via empty string assignment, enforce Python \-I isolation to cut off \~/.local/lib, and construct the MSVC PATH/LIB allowlist to ensure link.exe operates flawlessly.

2. Phase 2: Handle Architecture. Enforce the Windows handle-closure architecture. Wrap all file I/O and mmap calls in strict RAII (Resource Acquisition Is Initialization) drop guards. This ensures OS-level locks are released upon scope exit, allowing the immediate deletion of superseded \*.slm2 files in D:\\LLMs\\TinyRustLM without triggering access violations.

3. Phase 3: The Immutable Ledger. Instantiate the Markdown-based Experiment Ledger in the source repository.

4. Phase 4: First Formal Payload Qualification. Execute the first formal experiment to validate the MiniModel.org initial server seed. Utilize the Delta Debugging (ddmin) methodology to systematically resolve any F-Class structural load failures or N-Class numerical divergences.

Ship / No-Ship Criteria for the Replacement Architecture

• SHIP: The preflight passes 100% of environment checks. The structural converter emits the 6 exact artifact files without overlap or parsing errors. The WASM runtime loads the model without exceeding 65,536 memory pages (4GB). The model generates coherent output from the MiniModel.org seed that passes human-perceptible quality gates. Old payloads are successfully unlinked and deleted from the Windows disk.
• NO-SHIP: Any file handles leak, placing artifacts into a deferred deletion state. The environment preflight requires manual shell configuration or local user-site modifications. The output relies on undocumented compatibility paths or retired SLM1 readers.

What to Stop Doing

• Stop preserving gigabytes of trace logs; keep only the numerical summary and the Git SHA in the ledger.
• Stop using blind env\_clear() on Windows; use an explicit allowlist for PATH, SYSTEMROOT, and LIB to preserve toolchain functionality.
• Stop treating missing logs or crashed scripts as "model failures"; classify them accurately as S-Class setup failures or E-Class execution interruptions.
• Stop re-running non-deterministic pipelines in hopes of a better outcome; isolate the failing factor systematically using Delta Debugging.

Unresolved Local Measurements

The project-supplied facts do not establish the exact WASM engine being used locally (e.g., V8, Wasmtime, Wasmer). This dictates the exact strictness of SIMD memory alignment, the engine's garbage collection behavior, and maximum memory allocation behavior prior to the 4GB cap. Measuring the specific allocator overhead of the local WASM host is unresolved and must be the subject of an early F-Class experiment to ensure payloads do not trigger out-of-memory traps.

Smallest Falsifying Experiment

To falsify the recommendation that strict environment allowlisting and isolation resolves the MSVC linker and Node.js poisoning issues:

1. Hardcode the exact NODE\_V8\_COVERAGE="" override and the precise SYSTEMROOT/PATH allowlist in the execution orchestrator.

2. Introduce a deliberately toxic parent environment before executing the orchestrator (e.g., set NODE\_V8\_COVERAGE=/invalid/path in the shell and mutate the user's global PATH to point to a broken linker).

3. If the Rust child process fails to link, or the WASM runtime fails to initialize due to coverage inheritance, the hypothesis is falsified. This would prove that implicit inheritance is bypassing the orchestrator's isolation layer at the OS level, necessitating a deeper, hardware-level containerization strategy rather than application-layer environment filtering.

Works cited

1. ISO IEC 25059 AI Quality Standard 2025 | Assess with Nemko, https://digital.nemko.com/standards/iso-iec-25059

2. Practical Insights Into AI System Product Quality Evaluation, https://www.computer.org/csdl/magazine/it/2026/01/11399545/2edaS4xNHUY

3. ISO/IEC 25059:2023 | iTeh Standards, https://cdn.standards.iteh.ai/samples/80655/168addf09e0a4d8181b9172dc7404fab/ISO-IEC-25059-2023.pdf

4. ISTQB CT-AI v2.0 vs v1.0: What Changed in the New Syllabus, https://www.istqb.guru/istqb-ct-ai-v2-syllabus-changes-vs-v1/

5. Quality Assessment of Artificial Intelligence Systems: A Metric-Based, https://www.mdpi.com/2079-9292/15/3/691

6. 1\. Command line and environment — Python 3.14.7 documentation, https://docs.python.org/3/using/cmdline.html

7. 1\. Command line and environment — documentation Python 3.7.0a0, https://python.readthedocs.io/fr/latest/using/cmdline.html

8. Behaviour change in Python 3.11. Compatibility break or genuine fix?, https://discuss.python.org/t/behaviour-change-in-python-3-11-compatibility-break-or-genuine-fix/54729

9. node(1) \- Arch Linux manual pages, https://man.archlinux.org/man/extra/nodejs/node.1.en

10. Test runner | Node.js 26.8.1 Documentation, https://beta.docs.nodejs.org/test

11. rules\_js/js/private/js\_binary.bzl at main \- GitHub, https://github.com/aspect-build/rules\_js/blob/main/js/private/js\_binary.bzl

12. CLI 命令行| Node.js v26 文档, https://nodejs.cn/api/cli.html

13. process::Command resolve() to avoid security issues on Windows, https://internals.rust-lang.org/t/std-command-resolve-to-avoid-security-issues-on-windows/14800

14. std::process::Command::env\_clear is unusable on Windows \#114737, https://github.com/rust-lang/rust/issues/114737

15. Command in std::process \- Rust, https://doc.rust-lang.org/std/process/struct.Command.html

16. MSVC linker reference | Microsoft Learn, https://learn.microsoft.com/en-us/cpp/build/reference/linking?view=msvc-170

17. Need to point rust to the 'link.exe" to run any code. \- Reddit, https://www.reddit.com/r/rust/comments/9rc8ir/need\_to\_point\_rust\_to\_the\_linkexe\_to\_run\_any\_code/

18. WebAssembly.Memory \- MDN Web Docs, https://developer.mozilla.org/en-US/docs/WebAssembly/Reference/JavaScript\_interface/Memory

19. Up to 4GB of memory in WebAssembly \- V8 JavaScript engine, https://v8.dev/blog/4gb-wasm-memory

20. Why does WebAssembly.Memory take \initial\ and \maximum\ in, https://stackoverflow.com/questions/74229102/why-does-webassembly-memory-take-initial-and-maximum-in-units-of-number-of-p

21. Checkpoint Formats: Safetensors, GGUF, ONNX, and the Pickle, https://blog.ecitis.org/checkpoint-formats/

22. Simplifying and isolating failure-inducing input \- ResearchGate, https://www.researchgate.net/publication/3188209\_Simplifying\_and\_Isolating\_Failure-Inducing\_Input

23. Practical Improvements to the Minimizing Delta Debugging Algorithm, https://www.scitepress.org/papers/2016/59886/59886.pdf

24. Extending Hierarchical Delta Debugging with Hoisting \- arXiv, https://arxiv.org/html/2104.03637v1

25. Generalizing the Split Factor of the Minimizing Delta Debugging, http://www.inf.u-szeged.hu/\~akiss/pub/fulltext/kiss2020generalizing.pdf

26. Probabilistic Delta Debugging \- Yingfei Xiong, https://xiongyingfei.github.io/papers/FSE21a.pdf

27. Finding Failure Causes through Automated Testing \- arXiv, https://arxiv.org/html/cs/0012009v1

28. LockFile function (fileapi.h) \- Win32 apps | Microsoft Learn, https://learn.microsoft.com/en-us/windows/win32/api/fileapi/nf-fileapi-lockfile

29. What prevents windows from deleting a file that is in use?, https://stackoverflow.com/questions/62743404/what-prevents-windows-from-deleting-a-file-that-is-in-use

30. CreateProcessA function (processthreadsapi.h) \- Win32 apps, https://learn.microsoft.com/en-us/windows/win32/api/processthreadsapi/nf-processthreadsapi-createprocessa