player-data — module 0.4

The player record: the one place that owns the players table ("one owner per table"). Other modules read and update records through the published PlayerRecords service instead of touching the database. Source in modules/player-data/; the record type lives in the data library.

What it does

• Loads (or creates, logging a player.first-join GAME event) a PlayerRecord during the player's configuration phase, before they spawn, and caches it while they are online.
• Publishes PlayerRecords: get(uuid), update(uuid, fn) (versioned, write-behind), cached().
• Saves and drops the record on quit; saves everything on disable.
• Picks up players who are already online when the module enables.

Manifest

Field	Value
id	player-data
version	0.1.0
security class	CRITICAL — owns player identity data
kernel	yes
dependencies	none

Settings

None of its own. Database settings come from the data library.

Commands

None.

Events

• Listens: AsyncPlayerConfigurationEvent (load, before spawn), PlayerDisconnectEvent (save and drop).
• Sends: player.first-join (GAME) the first time a UUID is seen.

Security

• Trusted input: the player's UUID and name as verified by the login (online mode). Nothing else from the client is read.
• Settings written through update are bounded (PlayerRecord.MAX_SETTING_LENGTH, key format), and records are immutable, so a module can't corrupt another's view.
• A record with a lower version never overwrites a higher one.

When disabled

Never at runtime (kernel). Without a database, records live in memory for the session only and the module says so once.

Tests

PlayerDataModuleTest: manifest, the toggle test (service withdrawn), the load → cache → update → quit cycle on the Minestom test process including the player.first-join event, and picking up already-online players.