---
type: User Story
title: "US-005: Configure and persist stealth progression"
description: Give operators validated settings and durable, defensive storage for stealth behavior.
status: backlog
---

# US-005: Configure and persist stealth progression

As a **server operator**, I want stealth progression to be configurable and durable so that the plugin remains predictable across restarts and balance changes.

## Acceptance criteria

- [ ] The qualifying-time threshold is configurable and defaults to eight hours.
- [ ] Player-facing progress, unlock, prepared-login, and concealed-session messages are configurable.
- [ ] Startup validates required settings before registering partially functional listeners, commands, or tasks.
- [ ] Invalid required configuration prevents initialization and produces a clear server log message.
- [ ] UUID-keyed state stores accumulated qualifying duration, unlock ownership, active qualifying timing data, prepared-login state, and any current concealment metadata needed for safe recovery.
- [ ] Qualifying runtime intervals use a monotonic elapsed-time source so wall-clock adjustments cannot grant or remove progress.
- [ ] Durable timestamps, when required, use RFC 3339 UTC notation.
- [ ] State is saved periodically, after material state changes, and during orderly plugin disable.
- [ ] State uses atomic replacement where supported so an interrupted write does not replace valid data with a partial file.
- [ ] Corrupt, unknown, or invalid records cannot silently grant time, an unlock, a prepared login, or concealment.
- [ ] Unknown forward-compatible fields are preserved where practical.
- [ ] Persistence work does not perform blocking file operations on the server tick thread.

## Related

- [Accumulate invisibility time and unlock stealth](us-001-accumulate-invisibility-and-unlock.md)
- [Rejoin without a visible identity](us-002-rejoin-without-visible-identity.md)
- [Inspect and manage player stealth](us-004-administer-player-stealth.md)