---
type: User Story
title: "US-006: Configure and persist Leaf"
description: Provide validated configuration and durable, defensive storage for Leaf behavior.
status: backlog
---

# 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 strength, leaf prefix, onboarding duration, and player-facing messages.
- [ ] Resistance strength defaults to level I and accepts only Minecraft Resistance levels I through V.
- [ ] Runtime changes made through `/leaf enabled` and `/leaf strength` are 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 `Z` suffix.
- [ ] 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 does not remove a distinct Resistance effect that Leaf does not own when the API provides enough information to distinguish it.
- [ ] Unknown forward-compatible configuration and player-state fields are preserved where practical.

## Related

- [US-001: Opt into Leaf protection](us-001-opt-into-leaf-protection.md)
- [US-004: Introduce new players to Leaf](us-004-introduce-new-players-to-leaf.md)
- [US-005: Administer Leaf](us-005-administer-leaf.md)
- [US-007: Build and release Leaf](us-007-build-and-release-leaf.md)