Developer Documentation
Domain Model
Vocabulary and ownership boundaries for mod discovery, installation, and profiles
Domain Model
Use these terms when changing discovery, downloads, installation, or profiles. Check the linked types before assuming two identifiers represent the same entity.
| Term | Meaning | Source |
|---|---|---|
| Submission | A provider listing. Its identity includes the provider and submission kind as well as the provider ID; a bare numeric ID is not a universal identity. | packages/shared/src/providers/game-banana.ts, apps/desktop/src-tauri/src/providers/submission_ref.rs |
| Mod | The discoverable catalog entity or the locally managed entry, depending on the layer. State whether you mean the remote catalog record or local installation. | packages/shared/src/dto/mod.dto.ts, apps/desktop/src/types/mods.ts |
| Download | A selected provider file/archive and the operation that retrieves it. One submission can offer multiple files. Download completion does not prove installation. | ModDownloadItem in apps/desktop/src/types/mods.ts |
| Mod file | A file selected or discovered within a mod's file tree, with its own path, size, and selection state. | ModFile and ModFileTree in apps/desktop/src/types/mods.ts |
| VPK | Valve's archive format. A VPK is an artifact, not a provider submission or profile. A mod can install multiple VPKs. | packages/vpk-parser, LocalMod.installed_vpks |
| Installed addon | A game-visible local artifact managed by the Rust addon/VPK logic. Catalog metadata alone does not prove the artifact exists on disk. | apps/desktop/src-tauri/src/mod_manager |
| Profile | A named local configuration with mod membership, enablement, and associated VPK state. Its ID is separate from submission identity. | ModProfile in apps/desktop/src/types/profiles.ts |
| VPK manifest | Per-profile bookkeeping for enabled/disabled files, ordering, shards, and original names. Keep manifest changes aligned with physical file operations. | VpkManifest in apps/desktop/src/types/profiles.ts |
Ownership
- The API and database own remote catalog data and provider synchronization.
- The desktop Rust backend owns local game-file operations and installation state.
- The desktop frontend presents state and invokes backend operations through existing IPC bindings.
- Shared packages provide contracts; they do not import application internals.
For changes spanning these layers, trace the DTO, IPC command, file operation, and persistence together. Read Architecture for service boundaries and Project Structure for package ownership.