Hammed Abass
6ab658fea2
Add the VniDrop-specific Compose architecture skill, unify invitation and targeted transfer drafts, and promote Saved devices to an adaptive first-class destination.
2.2 KiB
VniDrop
Local peer-to-peer file transfer. This glossary is the product/core ubiquitous language — not an implementation guide.
Transfers
Transfer draft: A temporary, local selection of files or one folder, an editable transfer name, and a destination intent before a transfer is created. A draft may produce an Invitation transfer or a Targeted transfer; it is neither until creation succeeds. Avoid: pending transfer, temporary transfer, share draft
Invitation transfer: A share anyone with the ticket can request, subject to approval and access policy. Ordinary multi-recipient send/receive. Avoid: contact send, held offer, reusable share offer
Targeted transfer: A transfer bound to one saved-device relationship: immutable sender, receiver, manifest, and content identity; requires explicit approval before content. Avoid: contact transfer, private share
Saved device: A remote app identity this installation has mutually consented to remember, with directional grants at a relationship generation. Avoid: contact, person, account
Device relationship: The durable pairing state between this installation and a remote endpoint (pending, saved, forgotten/blocked lifecycle). Avoid: contact record, friendship
Persistence (core)
Domain store: The module that owns schema and queries for one domain (invitation history, targeted transfers, blocked devices, relationship rows, pairing eligibility, secret metadata). Callers use store methods — never a raw SQL pool. Avoid: repository-for-everything, DAO, database layer
Invitation repository:
The domain store for invitation-transfer history, artifacts, receiver requests, and related events. Module path invitation; today’s type name may still be Repository.
Avoid: “the database”, AppDataStores
AppDataStores: The bag of concrete domain stores opened together for one app-data profile (one SQLite pool, every schema applied once). Avoid: Repository (for the bag), Persistence (as a type name), DbContext
Persistence open:
Creating the profile’s SQLite pool, applying all domain schemas, and returning AppDataStores. The only place that may touch pool creation for app data.
Avoid: Repository::open as the global DB entry (once migrated), sqlite_pool export