AssetGuy

assetguy library reads the configured database. assetguy sync refreshes it; assetguy search queries Fab’s public catalogue; assetguy download fetches files. This makes each action’s cost explicit. assetguy add requires cached files and, when they are missing, names the download command instead of silently transferring gigabytes.

Thumbnail URLs arrive with metadata, but image files are optional because a terminal does not draw them and a large library can contain gigabytes of pictures. The interface is a CLI first so the underlying behaviour can stabilise before a GUI depends on it.

The catalogue can become stale between synchronisations. I accepted that tradeoff to make query cost predictable and independent of marketplace availability. Missing metadata remains visible: an empty listing does not prove there are no compatible assets.

Fab’s owned library, public detail, public search and CDN have different authentication requirements. A generic authenticated HTTP client would carry the wrong assumptions across those routes. The provider contract instead describes operations such as owned assets, listing detail, authentication and delivery.

Separate roles and capabilities let a command explain an unsupported operation by name. Fab is the implemented provider today. The download boundary is a DownloadPlan: the provider converts its manifest into a plan, while chunk fetching and file assembly consume the plan without depending on Epic’s API types.

This boundary makes workflows testable without HTTP details and concentrates Fab API changes inside its provider implementation. It does not yet prove support for another store: a second provider will need to satisfy those contracts against its own real cases.

SQLite is the zero-configuration default; PostgreSQL is already implemented. The chosen backend holds the catalogue, curation and download/install state. Four storage roles narrow what each caller may do: AssetStore, CatalogWriteStore, CurationStore and DownloadStore. A download does not need the ability to rewrite category rules.

Storage contracts use synchronous calls to match the blocking SQLite driver, while provider/network operations are asynchronous. Backend-specific SQL sits behind a dialect boundary. Backend selection is persistent configuration, and an invalid connection fails explicitly rather than falling back to a different library. Switching databases does not migrate the existing data.

I chose SQLite as the default so individual use does not require server administration. PostgreSQL provides a common catalogue at the cost of connections, credentials and database operations. Shared metadata and paths do not make the files available on other machines; that requires the shared cache that is still unimplemented.

Custom categories express matching rules rather than a frozen set of tags. Newly synchronised assets can fall into the same organisation automatically. Engine version, format, marketplace category and cached state are separate filter dimensions because they answer different questions.

Unreal version matching respects dotted components: UE4.1 must not also mean UE4.10. Engine and format metadata stay separate; a Unity format does not imply Fab supplies Unity version information. Missing metadata and partial search coverage are reported, so an empty result is not mistaken for complete knowledge of the marketplace.

Sync first fetches the owned list, whose cursor pagination is sequential. It then enriches each asset with details using bounded parallel workers. The request budget controls API pressure; it is not advertised as a percentage of network throughput.

Owned-list requests use the account session, while public detail requests use an anonymous client. This distinction follows the API’s observed behaviour. A removed public listing can still be owned and downloadable, and an absent byte count is unknown rather than zero. Manifest inspection is a separate way to learn Unreal download sizes.

Downloads fetch chunks concurrently but assemble files through an ordered writer, calculating SHA1 as bytes are written. Completed, verified files form the resume state; the manifest identity prevents mixing different builds. Downloaded files are promoted from a partial directory only after the work completes.

Chunks reused by several files have a bounded in-memory cache. Because the plan already knows the write order, eviction can drop the chunk whose next use is furthest away. This trades an occasional refetch for a predictable memory ceiling instead of storing the entire asset twice on disk.

An ordered writer simplifies verification and resumption, but may wait for a delayed chunk while others have arrived. A cache limit may require fetching a chunk again. The choice prioritises integrity and predictable memory over maximising parallelism at any cost.

Content packs go into a project’s Content directory; full projects can be copied as projects; engine plugins follow the manifest’s paths. Dry run previews the action, and collisions require an explicit force choice. Project copies are staged on the destination volume before promotion; engine staging stays outside the plugin scanner’s directory.

Plugin installation only accepts a registered engine root. Files come before the launcher records, and installation maintains the launcher’s manifest, item, installed-list and EOSH records. Backups and read-back checks protect the installed-list update. The launcher must be closed because it can rewrite those records from its own in-memory state.

Installing content into a project and installing a plugin into an engine affect different structures. Separate commands make the destination and effect explicit. Launcher records are the most sensitive integration point: copying a folder alone does not make Epic’s tool recognise installation and removal.

Configuration lives in the roaming profile; OAuth credentials, cache and audit files live in the local profile. Login happens in the user’s browser and returns an authorisation code, which is redacted by command identity in the audit log. Database passwords are supplied separately from the stored connection URL.

The launcher’s state is read-only for browsing and synchronisation. install, uninstall and repair are the explicit exceptions that write its records. A monthly local audit records operations; doctor exposes integrity and launcher-state issues without relying on a developer to invent diagnostic database queries.