The package kinds
When to write a system, a module, or a mod, and why the boundary matters.
Every package declares a kind in its manifest, and the kind decides what it is allowed to do.
Picking the right one is the first design decision you make.
#system
A system is a game's rules. Exactly one is active per world, because two rulesets cannot both own what a character is.
A system contributes document types, sheets, an initiative expression, and automation. It is the only kind that may define what a character or a monster is.
#module
A module adds content or features on top of a system, or on top of the bare engine. Many can be active at once.
Modules ship content packs: documents, extra document types, sheets, and assets. A bestiary is a module. A pack of map tiles is a module. A house-rules tweak that adds a document type is a module.
#mod
A mod extends the engine itself: a new UI panel, a scene layer, a tool. Mod code is not trusted, so it runs in a sandboxed iframe and reaches the engine only through capabilities it requests and the GM grants.
#Declarative first
Everything above is data except automation scripts, and those run only in the sandbox. This is deliberate: data can be validated, versioned, diffed, and safely hosted for other people, and code cannot. If you find yourself wanting to run code where data would do, that is usually a sign the declarative surface is missing something. Open an issue rather than reaching for a mod.
#Dependencies point downward
core -> protocol -> sdk -> (server, client, renderer, ui) -> apps
Your package depends on @aether/sdk, and on @aether/core for types. Never the reverse.