Answer architecture round 1: a custom CLI names itself by its file, --version names its module beside fejkdata's and follows a replace, the module path comes from the library's type, the end-to-end test runs main in a subprocess, the CLI tests find the shipped modules by their manifests, and Your own CLI sits under Library

CHANGELOG.md

@@ -138,9 +138,10 @@ replacement, and each removed path, column or flag.
   the folders `WithDataPath` names, and fails, naming `WithDataFS`, where no such option
   is given. A manifest's `namespace` mounts its source under a dot path.
 - Package `github.com/larvit/fejkdata/cli` is the `fejkdata` command: `cli.Main(modules...)`
-  runs it over the modules given, and returns its exit code, so a `main` package passing
-  `append(data.Modules(), mydata)` builds a CLI carrying your own data. `--version` prints
-  the fejkdata module's version, `devel` in a build from a checkout.
+  runs it over the modules given, and returns its exit code, so a `main` package calling
+  `cli.Main(append(data.Modules(), mydata)...)` builds a CLI carrying your own data, which
+  names itself by its file in its help and errors. `--version` prints the fejkdata
+  module's version, after the custom CLI's own where the CLI is one.
 - A data source whose root holds a `.fejkdata.json` manifest with an `index` loads each
   category on the first call reaching it, as each shipped module does. Data failing to load,
   in `New` or on that first call, gives an error matching `ErrLoad`, and the CLI exits 1.