#Part 15. Testing, Security, And Release Engineering
#Part 15 Section 1. Test Pyramid
Use pure unit tests for parsers, URL normalization, math, allocators, and format code. Use integration tests for compiler-to-runtime behavior, packages, D1 migrations, identity routes, and driver interfaces. Use boot tests for every firmware/architecture pair. Use long-running stress and fault-injection tests for memory, filesystems, networking, updates, and power loss.
Every fixed bug should gain a regression test. Tests that only assert “did not crash” are smoke tests; they are not correctness tests.
#Part 15 Section 2. Threat Modeling
Document assets, trust boundaries, entry points, attacker capabilities, and recovery paths for the kernel, browser, package loader, updater, identity service, crawler, and media tool. High-risk parsers need bounded input, explicit recursion/size limits, and fuzzing. Network services need authentication where appropriate, rate limits, request size limits, timeouts, structured logs, and secret redaction.
The browser renderer, downloaded page data, .cbw packages, images, fonts, archives, and search documents are untrusted. They cannot receive direct kernel, filesystem, token-vault, or arbitrary native-call access.
#Part 15 Section 3. Release Gates
A release candidate needs clean builds, passing automated tests, zero known critical security defects, signed artifacts, generated checksums, dependency and license inventory, supported-hardware matrix, upgrade and rollback tests, recovery media, privacy disclosures, known-issues notes, and reproducible build records.
For ClosedBitOS, add cold/warm boot timing, memory-pressure tests, filesystem power-loss tests, driver fault isolation, network soak, suspend/resume cycles, resolution/scaling tests, keyboard-only recovery, and VM tests on every advertised hypervisor.
#Part 15 Section 4. Performance Evidence
“Maximum performance” is a measurement program, not a compiler flag. Publish the machine, firmware, target, build digest, dataset, warm-up, number of runs, power state, and metric definition. Track boot time, resident memory, allocation rate, input latency, frame-time percentiles, compile time, package size, search latency, crawl throughput, and failure rate.
Optimize only after capturing a baseline and profile. Keep the benchmark that justified the optimization so future changes cannot silently erase the gain.