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 also supports request-gated deletion, but its source warns that deleting with installed components may leave 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.