ZOA Foundry

The umbrella holds one runtime file. `FoundryVersion` is a static class with `Version`, `MinUnityVersion`, and `PackageCount`, and its own summary says so plainly: it is the sole runtime content of the umbrella package, and all gameplay logic lives in the sub-packages. Nothing in your game should reference it except a build stamp or a support diagnostic.

The editor assembly is where the package earns its place. It ships two architectural linters, a package and asset inventory service, a profile-driven exporter, a pre-export cleanup tool, and a help menu. All of that is publisher and integrator tooling: it validates and packages the stack rather than running any part of the game.

For a shipping project the umbrella is safe to keep installed. It adds no components, no services, no scene requirements, and no runtime cost: it is the manifest, the version, and the tools.

The twelve direct dependencies are the stack's spine plus the two ends of the product. `com.zoa.foundation`, `com.zoa.common`, and `com.zoa.ui.theming` are the base layer. `com.zoa.inventory`, `com.zoa.equipment`, `com.zoa.weaponmodding`, `com.zoa.armory`, and `com.zoa.nucleon` are the systems most integrators touch directly. `com.zoa.persistence`, `com.zoa.platform`, and `com.zoa.platform.steam` cover save and platform services. `com.zoa.demo` is the last one and the widest.

`com.zoa.demo` is the reason the resolved graph is much larger than twelve. It depends on nearly thirty first-party packages of its own, including AI, animation, audio, combat, objectives, progression, loot, economy, minimap, terrain, VFX, and the frontend. `com.zoa.content` in turn brings crafting and quantities. So the gameplay-tier systems arrive transitively through the demo and content packages rather than by being named on the umbrella.

Resolve the whole closure and you land at around forty `com.zoa.*` packages. The repository carries a little over fifty, so a handful sit outside the umbrella's graph and are opt-in additions rather than part of a default install.

Plan a trim with that in mind. Removing the demo package from the manifest takes out an entire tier of the graph, and anything you were using from that tier has to be re-declared explicitly.

The umbrella is at 1.0.0 while the packages beneath it sit at 0.4.0 and 0.1.0. The 1.0.0 is the release contract with the customer: this specific resolved set of packages, at these specific versions, was built and validated together and is what the 1.0.0 documentation describes.

Sub-package versions move on their own cadence underneath that line. A package at 0.1.0 is telling you its own API surface is still settling; a package at 0.4.0 has been through more revisions. Neither number is a promise to you directly. The number you pin, ship against, and file a bug against is the umbrella's.

`FoundryVersion.Version` carries the same string in code so a build can stamp it, and the About dialog reads the live version out of the package manifest at runtime rather than hard-coding it, so the dialog cannot drift out of sync with what is installed.

The 1.0.0 release is a first release: its changelog is a single Added section covering the Start Here experience, the system builder, the Workbench, and every sub-package from foundation through demo. Read it as the inventory of what shipped in the box rather than as a diff.

Two editor linters check the modular claim. `AsmdefBoundaryValidator` scans every assembly definition under `Packages/` and reports any runtime assembly that references an editor-only one, which is the failure that compiles fine in the editor and breaks the player build.

`AsmdefDependencyLinter` builds the directed graph of assembly references and does two passes. A depth-first search with node colouring finds circular dependencies and reports the full cycle path. A rule pass finds forbidden edges: armory referencing equipment or the reverse, inventory referencing nucleon, and anything whose assembly name contains Rendering referencing armory, equipment, inventory, nucleon, or weapon modding.

Those specific rules encode the architecture's load-bearing separations. Armory and equipment must stay independent so a weapon can exist without a slot system and a slot system without ballistics. Rendering must never reach into gameplay, which keeps the render-pipeline packages swappable.

Both linters log every violation to the console with the offending pair and then summarise in a dialog, so they are usable both interactively and as a step in a build script.

Not every downstream project wants all forty packages, and `FoundryExportProfileCatalog` names four profiles that carve the graph differently: `swarms-host-client`, `swarms-authoring`, `steam-demo-reference`, and `full-foundry`. A profile declares seed packages, excluded packages, which asset roots and asset roles to include, and whether samples, tests, and generated demo output come along.

`FoundryPackageInventory.Discover` walks `Packages/` and builds a record per package: id, display name, version, path, dependencies split into local and external, assembly definitions, and role tags. `ComputeClosure` then resolves a profile's seeds into the full transitive set, flagging a seed that is missing from disk or that the profile also excludes as an error finding rather than silently dropping it.

`FoundryExportPipeline.BuildPlan` combines the inventory, the closure, the asset scan, and the profile's third-party dependency list into a `FoundryExportPlan`, whose `HasBlockingFindings` is the gate. `GenerateReadinessReport` and `GenerateExportArtifacts` write markdown reports and import plans, and both have CI entry points so the same check that runs in the editor runs in a pipeline.

This is the machinery behind the changelog's note that UPM publishing for paid Asset Store products is still in beta, so 1.0.0 ships as a hybrid unitypackage. The profile system is how a deterministic subset gets mirrored regardless of which distribution channel is available.

Take the umbrella when you are building the kind of game it was built for: a first-person action, shooter, survival, or RPG project that will use most of the stack, and where a wired starting point beats assembling one. That is the overwhelmingly common case and the one every wizard, validator, and default asset path assumes.

Take individual packages when you want one primitive and not a platform. `com.zoa.messaging` on its own is a bus and a service registry with no dependencies. `com.zoa.quantities` is a named ledger that needs only foundation and messaging. `com.zoa.crafting` needs only foundation. Each has its own manifest and its own dependency list, so a targeted install resolves a handful of packages rather than forty.

The mixed approach is also legitimate and is what the export profiles exist to support: a project that already has its own player controller and rendering stack but wants Foundry's inventory, equipment, and weapon modding can seed on those three and let the closure resolve what they actually need.

The cost of going piecemeal is that the Workbench's guided flows, the Start Here scaffolder, and the clean-install validator all assume the full set. You keep the runtime systems and give up some of the on-ramp, which is the right trade when you are integrating into an existing project and the wrong one when you are starting fresh.

A project built through the Start Here flow accumulates generated content: definition assets under `Assets/ZOA/Generated`, imported samples and content packs, feature-set installer output, test output, demo content, local save state, and third-party assets that must never be redistributed.

`FoundryCleanupTool` scans for all of that and presents it as selectable categories with per-category counts, so a publisher strips a project back to a distributable state from a list instead of from memory. The third-party category is pre-selected by default, because that is the one where shipping the wrong file is a licensing problem rather than a size problem.

`FoundryAssetInventory` is the service underneath, classifying every asset root by a `FoundryAssetRole`: first-party runtime, first-party docs, generated output, generated demo output, test output, third-party dependency, project setting, review-required, or unknown. The Review Required and Unknown roles are the interesting ones, because they are the tool admitting it cannot decide and asking a human to look.