DEMI Vault — deployed at the demicapsule Vault address, first test passed; v0.3 Simplicity Brief

PropositionsT1: Deployment confirmed at vault.demicapsule.com on 3 November 2026, first end-to-end test passed (fingerprint match, private storage, expiring download link emailed by Claude, byte-identical retrieval) | T2: v0.3 replaces password login with a one-time code sent to the owner's email | T3: Single page 'My Vault' presents all files on four named, coloured shelves: Free, For sale, On request, Private | T4: Shelf assignment is a label only; one physical copy exists and moves between shelves by drag and drop | T5: Per-file owner buttons: download to PC, send a link, open certificate, open public page, open AI package | T6: Whole-folder drop-in supported; registered files auto-recognised and stored in one click | T7: A strongly private store is air-gapped from the web so no AI can access it | T8: Reader view shows author's public shelf with one contextual button per file (download free / buy / ask author / not released) plus a button to continue ideas with an AI | T9: Design reuses conventions from file-sharing services, digital shops and research archives to keep rules invisible

ConstraintsLogin: one-time email code only, no password | Storage: single copy per file, shelf is metadata label not a folder | Private store: no web connectivity permitted | File ingestion: fingerprint must match the Registry before a manuscript is accepted | Access links: must be expiring | Retrieval integrity: byte-for-byte identity required | Scope: v0.3 targets simplicity first; underlying token/permit/fingerprint rules must be preserved but hidden | Environment: web-based, owner and reader interfaces distinct | AI access: blocked entirely for air-gapped private store; permitted only where shelf label allows

MechanismsT1: Re-run end-to-end test: submit a registered manuscript, verify fingerprint check blocks unregistered files, confirm storage, trigger expiring link generation via Claude email, download and diff bytes against original | T2: Trigger login flow, confirm no password field exists, verify one-time code arrives by email, confirm code expires after single use | T3: Render My Vault page, assert exactly four shelves present with correct colour coding and correct file assignments | T4: Drag a file between shelves, confirm single copy in storage, confirm only label metadata changes in database | T5: For a sample file assert all five buttons are present and each opens the correct target without error | T6: Drop a folder containing mixed registered and unregistered files; verify registered files are stored in one click and unregistered are rejected or flagged | T7: Attempt AI or HTTP access to private store endpoint; confirm connection is refused or not exposed | T8: Render reader view; assert one button per file matches shelf label logic; assert AI-continue button present | T9: UX review against file-sharing, shop and archive conventions to confirm no novel terminology is surfaced to the user

BoundariesOut of scope for v0.3: rebuilding or changing the underlying token, permit, fingerprint or Registry logic; changing the expiring-link generation mechanism; altering the byte-integrity or fingerprint-match rules | Not yet built: full simplicity redesign (v0.3 is the stated goal, not a completed deliverable at time of document); details of AI package contents; payment flow for 'buy' button; 'ask the author' request handling; certificate display design | OPEN: What happens when a dropped file's fingerprint is not in the Registry — rejected silently, flagged, or queued? | OPEN: How long do expiring links remain valid, and is duration configurable? | OPEN: Is the air-gapped private store a separate physical or logical deployment? | OPEN: How is the one-time email code invalidated if unused?