From 97a366e8b7c540b246c7bf9d04625526cbdc88ba Mon Sep 17 00:00:00 2001 From: cirakg Date: Mon, 19 Oct 2026 15:27:37 +0200 Subject: docs: document the storage format and record M3 results; bump to 0.3.0 Co-Authored-By: Claude Opus 5.5 --- docs/FEASIBILITY.md | 6 ++++++ 1 file changed, 6 insertions(+) (limited to 'docs/FEASIBILITY.md') diff --git a/docs/FEASIBILITY.md b/docs/FEASIBILITY.md index 8665139..c16b0ce 100644 --- a/docs/FEASIBILITY.md +++ b/docs/FEASIBILITY.md @@ -261,6 +261,12 @@ With SDK 9.2.0 and the device files of all 72 products installed: - **64-bit arithmetic:** `Long` overflow wraps like unsigned arithmetic, `>>` copies the sign bit, and hex literals above 2^63 parse correctly, which is what the SHA-512 implementation relies on. ByteArrays throw on values above 255 rather than wrapping. - **Watchdog in the simulator:** not enforced in test runs (a 300,000-iteration loop passed on a 120,000-bytecode profile), so the job design is the protection and the real limits are checked on the watch. +## Verified during M3 (2026-10-19) + +- **Storage (4): ByteArrays are storable.** `Application.Storage.ValueType` includes `ByteArray`, so each record is one value whose size is known exactly. A typical OTP record is 239 bytes; the entry cap stays at 150 ([SECURITY.md](SECURITY.md)). +- **Invalid UTF-8 crashes the string conversion.** `StringUtil.convertEncodedString` stops the app with an uncatchable system error instead of throwing; stored text is validated before decoding. +- **Store-full handling is tested only against a simulated store.** The in-memory test store throws `StorageFullException` at a set size. How the real store behaves when full is checked on the watch (real-watch checklist in [TESTING.md](TESTING.md)). + ## Decisions Answered on 2026-10-18: -- cgit v1.2.3