Zero-dependency runtime policy

Examines the actual no-crate policy, its supply-chain advantage, engineering costs, review implications, and criteria for future dependency exceptions.

What zero dependency means here #

Every Cargo [dependencies] section is empty. The browser app also avoids npm packages, frontend frameworks, CDN assets, tokenizer libraries, inference frameworks, and remote inference APIs.

Benefits #

• Small and auditable lockfile.
• No transitive build scripts or procedural macros.
• Stable offline build boundary after the Rust toolchain is present.
• Direct ownership of binary formats, error contracts, and memory behavior.

Costs #

• Project-owned cryptography is deliberately absent, so authenticity remains external.
• Handwritten parsers, tensor kernels, HTTP handling, JSON serialization, BPE, and test harnesses require dedicated fuzzing and review.
• Performance portability is limited without specialized SIMD/GPU libraries.
• Standards compatibility must be implemented and maintained locally.

Exception gate #

A dependency exception should identify the missing capability, source and maintenance health, license, unsafe/build-script surface, binary impact, supported targets, replacement cost, and rollback plan. “No dependency” must not become a reason to write unreviewed security-critical code.

Scope #

This starter page defines the questions, boundaries, evidence, and failure modes that should be recorded before a capability is presented as supported.

Engineering considerations #

• Identify the source, version, target environment, and owner.
• Separate observed values from estimates and externally reported values.
• Record trade-offs, unsupported cases, and fallback behavior.
• Link performance statements to a compatible benchmark methodology.

Verification questions #

• What exact artifact, revision, backend, and environment were reviewed?
• Which assumptions could change the result?
• Which data should be retained so another engineer can reproduce the conclusion?