Reference
What gets generated from source, and why none of it is hand-written.
The reference section is generated. Hand-written reference docs drift from the code within a release or two, and a drifted API reference is worse than none: it costs a developer an hour before they stop believing it.
Four generators feed this section. None of them exist yet; this page records the plan, and shows the surfaces they will render into.
#@aether/sdk types and functions
Hand-written pages embed live type tables pulled from packages/sdk source, so a signature change
shows up here on the next build.
| Parameter | Type | Default | Description |
|---|---|---|---|
| manifest* | SystemManifest | - | Identity, version, and the SDK range the system supports. |
| setup* | () => SystemContributions | - | Called once at load. Returns document types, sheets, initiative, and automation. |
| onReady | () => void|undefined | - | Runs after the world has loaded. Use it for one-off migrations. |
#Document schemas
Document types are declared as Zod schemas, so their reference is derived from the schema itself: field paths, types, defaults, and the per-field visibility level.
Every document type also states which engine capabilities it composes, which is what decides what the engine will do with it:
#Protocol messages
@aether/protocol is a versioned contract negotiated in the handshake. Its message reference is
generated and stamped with the PROTOCOL_VERSION it describes, because a stale protocol page is a
debugging trap.
#The capability catalog
Mods request capabilities and GMs grant them. The catalog is generated from the registry, since it doubles as the security surface a GM is agreeing to.