DEMI Vault Gate v0.2.1 – private Vault for registered Main Files (built and tested, not deployed)

PropositionsT1: Separate Cloudflare Worker serves as the Vault Gate, operating independently from the main Registry | T2: Storage bucket demi-main-files holds registered files; a second bucket demi-private is intentionally network-isolated | T3: File ingestion requires SHA-256 fingerprint match against the DEMI record's main file or any listed alternate file; non-matching files are refused and nothing is stored | T4: Four permit levels per record — Closed (fingerprint public only), Private (owner-made links only), On request (owner decides per request), Open | T5: Egress is link-based only; links are owner-created, time-limited, revocable, and fully logged with timestamp and registry code | T6: Owner page generates links and a ready-to-send message; Claude emails it from the owner's account | T7: Claude never holds owner keys or Vault keys | T8: Recipients can independently verify file authenticity by comparing its SHA-256 fingerprint against the Registry

ConstraintsPlatform: Cloudflare Workers. Storage: bucket demi-main-files (active), bucket demi-private (no web connectivity by design). Ingestion rule: SHA-256 fingerprint must match main file or a file explicitly listed in the corresponding DEMI record — no exceptions. Permit system is per-record and must be enforced at both ingestion and egress. All links must carry expiry; revocation must be supported. Every action must be logged with timestamp and registry code. AI (Claude) operates only on owner-page output; it must not be granted access to owner keys or Vault keys. v0.2.1 is built and tested but not deployed. No selling or payment integration exists in this version.

MechanismsT1: Verify Worker is isolated from Registry codebase and deploys independently | T2: Confirm demi-main-files accepts uploads; confirm demi-private has no public or Worker-accessible route | T3: Submit a file with a correct SHA-256 — confirm storage; submit a non-matching file — confirm refusal and zero storage side-effects | T4: For each permit level, attempt access via each allowed and disallowed path and confirm correct allow/deny behaviour | T5: Generate a link, let it expire, attempt access — confirm denial; revoke an active link, attempt access — confirm denial; check log for timestamp and registry code after each action | T6: Simulate owner page flow — confirm link and message are produced; confirm Claude sends email without receiving keys | T7: Audit Claude integration points for absence of key parameters or storage credentials | T8: Hash a delivered file independently and compare to Registry record — confirm match

BoundariesOut of scope for v0.2.1: deployment to production, payment or commerce functionality, any selling workflow. demi-private bucket is intentionally excluded from all web access and has no defined use case in this version. Planned but not built: v0.3 adds Lemon Squeezy payment integration without altering the Vault Gate design. OPEN: behaviour under Open permit level is named but not described in detail — it is unclear whether Open permits unauthenticated direct download or still requires a link. No detail given on link expiry duration options, log storage location, or how 'On request' notifications reach the owner.