Architecture and lifecycle

v0’s world package models concrete shared assemblies. An assembly owns fixed fields such as its deterministic tenant/item key, owner-cap ID, status, location, energy, and metadata; anchoring and sharing are direct lifecycle operations.

v1’s active packages include core, character, inventory, metadata, and currency; the former world package is archived. An Entity is deterministically derived from a tenant-scoped key and holds dynamically installed typed Component<T> values. A numeric component ID is the storage key; an optional name is only a display label.

flowchart LR
  V0[Fixed shared assembly] --> Fields[Fixed domain fields]
  V1[Entity] --> Components[Installed Component values]
  Components --> Action[Named Action]
  Action --> Request[Locked Request]
  Request --> Requirements[Typed requirements]
  Requirements --> Complete[Unlock and complete]

install, uninstall, action changes, and interaction lock an entity and return a no-ability Request. Each Requirement must be consumed before completion. GenericModule can store opaque type ID and bytes for fittings without on-chain logic; this does not make their gameplay behaviors active.

The active Entity supports request-gated deletion; its source now aborts while any component is still installed, so deletion no longer leaves orphaned dynamic fields. Modules carry local version checks, but the reviewed active source has no universal cross-package data migration function. Treat upgrades and deletion as explicit integration and lifecycle work, not automatic compatibility.