2.2 KiB
2.2 KiB
type, title, description, status
| type | title | description | status |
|---|---|---|---|
| User Story | US-006: Configure and persist Leaf | Provide validated configuration and durable, defensive storage for Leaf behavior. | done |
US-006: Configure and persist Leaf
As a server operator, I want Leaf settings and player state to be validated and durable so that protection remains predictable across restarts.
Acceptance criteria
- Configuration supports the global enabled state, Resistance and Strength levels, leaf prefix, onboarding duration, and player-facing messages.
- Resistance strength defaults to level I and accepts only Minecraft Resistance levels I through V.
- Strength defaults to level I and accepts only Minecraft Strength levels I through V.
- Runtime changes made through
/leaf enabledand/leaf effectare persisted for subsequent restarts. - UUID-keyed player state persists the latest known name, saved opt-in choice, administrative lock, and first-join timestamp.
- Date-times use RFC 3339 UTC notation with a
Zsuffix. - State is saved safely so that a failed write does not replace valid persisted state with a partial document.
- Invalid required configuration prevents partial plugin initialization and produces a clear server log message.
- Corrupt or invalid player records are handled defensively and cannot silently grant protection or privileges.
- Removing Leaf-managed Resistance or Strength does not remove a distinct corresponding effect that Leaf does not own when the API provides enough information to distinguish it.
- A temporary external Resistance or Strength effect is preserved instead of overwritten, and Leaf restores its configured effect after the external effect ends.
- The leaf prefix remains visible while an external effect temporarily replaces a Leaf-managed effect.
- Unknown forward-compatible configuration and player-state fields are preserved where practical.