Test and distribute a package
Validate the built package, exercise it in a real world, and choose the supported publishing path.
Test the same files you intend to publish. A passing source test does not prove that the built package contains the right files, requests the right permissions, or works after installation.
#1. Validate the package
For a hosted system, run:
aether system validate .
aether system build .
aether system inspect dist/system.aethersystem.zipKeep the inspection output with the release review. Building the same source twice must produce the same package identity.
For a mod, build the project and inspect the resulting bundle. The ZIP must contain mod.json at its
root. Confirm that every requested permission appears in the
mod capability reference, and remove permissions the mod does
not use.
For a content or soundscape pack, validate the exported package rather than only the source project. Check every included file, reference, attribution, and rights declaration before uploading it.
#2. Exercise the real behavior
Install the built package in a disposable local or test world. Test with the least powerful role that should use each feature, then confirm that a user without the required role or permission is refused.
Cover the behavior that belongs to the package:
- Systems: world creation, starter content, every document type and sheet, rolls, automation, companion applications, required packages, restart, and each declared upgrade path.
- Mods: installation consent, panels and background behavior, requested permissions, reconnect, disable, update, and uninstall.
- Content packs: import choices, id remapping, references, duplicate import behavior, and removal of content owned by the importing world.
- Soundscape packs: included audio, cue and sequence playback, permissions, missing assets, and uninstall behavior.
Exercise one deliberate failure for every operation that changes a world. The previous working state must remain usable or produce a clear recovery instruction.
#3. Review what the user will see
Read the listing as a GM who has not seen the source project. It should name the actual contents, requested permissions, required packages, compatibility, limits, license, and creator-supplied rights declaration. Verify the cover and alt text at desktop and phone widths.
A Creator Studio draft saves the publication form but is not an installable test release. An Unlisted, link only item is already published and its version is immutable. Until private test releases are supported, use a local or dedicated test installation before publishing either a public or link-only version.
#Distribution paths
| Package | Development and testing | Publication |
|---|---|---|
| Hosted system | Build and inspect with the Aether CLI; install in a local or test world | Upload .aethersystem.zip through Creator Studio, or use the supported local/test CLI |
| Mod | Install the built development manifest in a local or test world | Upload a ZIP with mod.json at its root through Creator Studio |
| Content pack | Import the exported .aetherpack.json in a disposable world | Upload .aetherpack.json through Creator Studio |
| Soundscape pack | Import the exported package and exercise its included audio | Upload .aethersoundscape.json through Creator Studio |
Published package versions cannot be replaced with different bytes. If any file changes after the review, update the package version and repeat the validation and real-world checks.
See Publish a system for the complete hosted-system publication flow and Build a mod interface for the mod development loop.