docs: document the storage format and record M3 results; bump to 0.3.0v0.3.0

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

1 files changed, 6 insertions, 0 deletions

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: