Transparency
VTTForge is two halves. One runs inside Foundry, in your players' browsers. The other runs on your own machine, in your terminal.
What runs inside Foundry
@vttforge/core, @vttforge/styles and @vttforge/dev-module are what a system or module built on VTTForge ships to a world.
No network calls. There is no telemetry, no analytics, no version check, no phone-home, because none of these packages holds code that can make a request. The one exception is deliberate and local: while vttforge dev is running, the companion module opens a WebSocket to localhost (or host.docker.internal when Foundry is in a container) to hear that a file changed. It never goes into a world you publish.
No third-party runtime dependencies. styles, testing, types, vite-plugin and dev-module have none at all. core has one, @vttforge/types, which is types only and disappears at build time.
The SDK does not read your world or send it anywhere. It registers your data models, your sheets and your settings with Foundry, and stops there. It does not inspect your actors, your players, or your compendia.
What runs on your machine
@vttforge/cli is a program you run in your terminal. Everything it touches:
| It does | Where |
|---|---|
| Writes the project it scaffolds | The directory you named |
| Remembers where Foundry keeps its data | <project>/.vttforge/config.json |
| Creates a symlink to your build | <Foundry data>/Data/systems/<id> or modules/<id> |
| Runs Vite | Your project |
| Serves the hot-reload bridge | localhost:31313, while dev is running |
| Writes a release zip | Your project root |
It makes no network requests of its own. The one download happens when init installs dependencies, and that is your own package manager, running the command you approved.
How it is published
Every package goes to npm through OIDC trusted publishing, with a provenance attestation tying the tarball to the commit and the workflow that built it. Nothing is published from a laptop, and no long-lived npm token exists to leak. You can check any version yourself:
npm audit signaturesHow it is built
I write VTTForge with the help of AI coding agents.
Every change, mine or an agent's, goes through a pull request and has to pass the same gates:
| Gate | What it does |
|---|---|
| Typecheck | TypeScript strict across every package |
| Tests | 664 of them |
| Lint | Biome, plus a dependency-version check and a check that the scaffolding templates pin versions that exist |
| Dead code | Unused exports and dependencies fail the build |
| Package quality | publint and attw, so the published shape is correct |
| A real Foundry | Every push to main boots Foundry v14 in a container, installs the example system and module, joins a world, and drives them. Any console error naming VTTForge fails it |
The unit tests run against a mocked Foundry, so they prove the SDK calls the right things. Only a running Foundry proves Foundry accepted them.
I read what ships and I merge it. No agent merges its own work or publishes a release.
The gaps: there are no staged release channels, no visual regression captures, and the end-to-end run covers v14 only. Every package is below 1.0, and a minor may break you. The stability policy says exactly how much.
If you would rather not
Some people would rather not build on AI-assisted software, which is fair. Nothing here is hidden: the repository is public, every change went through a pull request you can read, and the packages carry provenance back to the commit that built them. Pin a version and stay on it, or read the code before you install it.