CRYPTOSPORA SILENTIS — OFFICIAL TEST REPORT Test ID: CS-REAL-005 (v1.3 — Streamed Fold, Memory-Safe) Species: Cryptospora silentis (The Hidden Spore) Creator: Wagg · Owner: Family Tree Trust Date: 2026-09-27 System: Diamond Server (Python 3, real engine, 2 GB RAM) Document Type: Full Technical Record PURPOSE OF TEST CS-REAL-004 killed the process during the fold. The engine loaded all 56 logogram images into memory at once and ran out of RAM. The v1.3 engine was built to fix this by processing the core one file at a time. This test reruns the same setup and the same 56 logograms to confirm the fix. THE FIX The fold now walks the core file by file. For each file: 1. Read it. 2. Encrypt it. 3. Write its record to the fragment files. 4. Release the memory. 5. Move to the next file. Memory holds only one file at a time. The size of the core no longer matters. ACTUAL RESULTS | Step | Result | | Fold | PASS — 56 files folded, no crash | | Fragment size | 359,736,712 bytes each | | Unfold | FAILED — UnicodeDecodeError on first record | WHAT PASSED The streamed fold worked. All 56 files were folded. The process survived. The memory fix is real. The core of the problem from CS-REAL-004 is gone. WHAT FAILED The unfold crashed on the very first record. Error: UnicodeDecodeError: 'utf-8' codec can't decode byte 0x9e in position 0: invalid start byte Cause: The engine separates records with a newline byte (\n). But the encrypted data is random — and random bytes sometimes equal \n. When the unfold reads the file line by line, it splits records in the middle of encrypted data. The reader then tries to parse encrypted bytes as the record header and fails. The record separator is unsafe. This is not a bug in the encryption. It is a bug in how the records are framed. SECOND OBSERVATION: FRAGMENT SIZE Each fragment file is 359,736,712 bytes — 359 MB — for a folder whose contents are far smaller. This suggests the engine is duplicating work or expanding far more than base64 accounting alone would explain. This needs to be investigated. It is not the cause of the unfold crash, but it is a real problem. THIRD OBSERVATION: DUPLICATE LOCATION The setup file lists loc1 twice — the buyer typed the same path in two of the three location boxes. The engine wrote fragments to the same folder twice. The setup page should have caught this. The engine should also refuse to write two fragments to the same path. SCORECARD | Item | Result | | Memory-safe fold | PASS | | Files folded | PASS (56) | | Unfold | FAILED | | Record framing | FAILED | | Fragment size | Needs investigation | | Duplicate locations | Needs handling | WHAT THIS TEST PROVES 1. The streamed fold fixes the CS-REAL-004 crash. The engine no longer dies on a 56-file core. 2. The unfold has a fundamental framing bug. Records cannot be separated by newlines when encrypted data may contain newlines. 3. Two more problems were identified — fragment bloat and duplicate locations. THE DESIGN RULE THIS CONFIRMS The species must process the core one file at a time, write every piece to disk as it goes, and use the file's own length to know where it ends — never a delimiter that could appear in encrypted bytes. NEXT STEPS - Fix the record framing. Use length-prefixed records with no delimiter between them. Each record is exactly as long as it says it is. - Add a breadcrumb inside each record. The record stores the original path of the file. On unfold, the engine rebuilds the path and writes the file back where it belongs. - Investigate the fragment size — find out why each fragment is 359 MB. - Handle duplicate locations at setup and at fold. - Retest. OUTPUT ARTIFACT Engine: engine/cryptospora_v13.py Script: tests/test_cs_real_005.py Results: results/cs_real_005.json Signed: Wagg · Owner: Family Tree Trust · Date: 2026-09-27 © 2026 Family Tree Trust. All rights reserved. Distributed by CTW, LLC.

CRYPTOSPORA SILENTIS — OFFICIAL TEST REPORT Test ID: CS-REAL-006 (v1.4 — Length-Prefixed Records) Species: Cryptospora silentis (The Hidden Spore) Creator: Wagg · Owner: Family Tree Trust Date: 2026-09-27 System: Diamond Server (Python 3, real engine, 2 GB RAM) Document Type: Full Technical Record PURPOSE OF TEST CS-REAL-005 folded 56 logograms successfully but crashed on unfold. Cause: the engine used newlines as record separators, but encrypted bytes sometimes contain newlines. The reader split records in the middle of encrypted data. The v1.4 engine replaces newline separators with length-prefixed records: - 4 bytes: big-endian unsigned int = length of the encrypted payload - 32 bytes: SHA-256 checksum of the encrypted payload - N bytes: the encrypted payload itself No delimiters. The length is the boundary. Each record also carries the file's original path as a breadcrumb, so on unfold the engine rebuilds the folder tree exactly. Duplicate locations are also handled. If the buyer typed the same path twice, the engine now writes only one fragment per unique folder. ACTUAL RESULTS | Step | Result | | Source files in core | 56 | | Locations (raw) | 3 (with one duplicate) | | Locations (deduplicated) | 2 | | Fold | PASS — 56 files, no crash | | Fragment size per location | 359,734,584 bytes | | Unfold | PASS — 56 files restored | | Hash matches | 56 of 56 | | Hash mismatches | 0 | | Wrong password | REFUSED — 0 files decrypted | | Kill switch | PASS — 0 fragments remaining | Result: PASS — the species works end to end. WHAT THIS SHOWS 1. The framing bug is fixed. Length-prefixed records mean the unfold reads exactly the bytes it needs. No delimiters, no ambiguity, no crash. 2. The breadcrumb works. Every file returned to its original relative path. The restored folder tree is byte-for-byte identical to the original — 56 of 56 hash matches. 3. The memory fix holds. All 56 files folded without any memory pressure on a 2 GB server. 4. Duplicate locations are handled. The buyer typed loc1 twice. The engine deduplicated. It wrote one fragment per unique folder, not two to the same place. 5. The password still guards. A wrong password decrypted nothing. 6. The kill switch still works. All fragments removed. THE ONE REMAINING PROBLEM Each fragment file is 359,734,584 bytes — 359 MB — for a folder whose contents are far smaller. This is not a blocker for the test, but it is a real problem to fix. It suggests the encrypted payload is being stored in a form larger than it needs to be. This becomes the focus of v1.5. HONEST BOUNDARY The test proves the species works end to end on 56 real image files on a real server. It does not yet prove it works at larger scale, on other systems, or under a real crash. Those tests come next. OUTPUT ARTIFACT Engine: engine/cryptospora_v14.py Script: tests/test_cs_real_006.py Results: results/cs_real_006.json Signed: Wagg · Owner: Family Tree Trust · Date: 2026-09-27 © 2026 Family Tree Trust. All rights reserved. Distributed by CTW, LLC.