5.5 KiB
type, title, description, status
| type | title | description | status |
|---|---|---|---|
| User Story | US-023: Complete the legacy collection with an unbreakable Elytra | Reward a completed current-reign legacy collection with one final transferable Elytra. | done |
US-023: Complete the legacy collection with an unbreakable Elytra
As the active Tyrant, I want a final unbreakable Elytra after completing my reign's collection so that continued victories earn a lasting trophy.
Acceptance criteria
- After all six standard unlocks and all nine regular armor, tool, and weapon claims in the current reign, the active Tyrant can spend one additional choice on one Elytra; possession of earlier rewards is not required.
- The nine regular rewards remain independent of one another and of Elytra; Elytra is not its own prerequisite.
- The reward is Minecraft Elytra with the Unbreakable flag and no enchantments, including no Mending or Unbreaking.
- The gold display name is
Tyrant's <player name> Elytra; gray lore isForged for Tyrant <name>.,A lasting reward from <name>'s reign., andEarned by completing the Tyrant's legacy collection.. - The ordinary item can be traded, stored, repaired, retained after the reign, lost, or destroyed; no binding or replacement is provided.
- The menu explains unmet prerequisites and confirms Elytra, unbreakability, and the one-choice cost before using the authoritative command path.
/tyrant gear elytrapurchases the reward and contextual completion includes Elytra, case-insensitive prefixes, and no extra arguments; armor commands remain unchanged.- Claims persist under backward-compatible storage and reset each reign without touching delivered items.
- Full inventory, paused/inactive games, unauthorized claimants, incomplete prerequisites, no choices, and duplicate or stale requests cannot issue rewards or consume choices.
Implementation
Reuse historical armor-named reward types and the game.claimed-armor key. Use an explicit nine-item prerequisite set, not all reward enum values. The approved Unbreakable design replaces the initial enchantment proposal.
Implementation references
- Explicit reward set and parsing and claim rules
- Item specification and Bukkit metadata creation
- Command delivery, contextual completion, menu policy, and renderer/confirmation dispatch
- Historical-key persistence and restart/reset tests
Verification scope and limitations
Verified on 2026-09-09: ./gradlew clean check jar passed with 221 tests, zero failures/errors/skips, Java 17 warnings-as-errors compilation, and JAR packaging. OKF v0.1 structural validation passed for all 30 design Markdown documents (YAML frontmatter, required story fields/statuses/criteria, reserved index/log structure, and local links); git diff --check passed.
Automated coverage includes each missing regular claim and standard unlock, no prior item possession, one-choice purchase, repeated command input, full inventory, lifecycle/authorization guards, malformed and cross-category requests, contextual completion, exact item metadata and confirmation text, ten distinct menu slots, missing-prerequisite menu explanations, older saves, Elytra restart round trips, and succession reset. The initial test run failed to compile because the partial implementation lacked the Elytra enum value; the first complete build also caught three obsolete nine-reward regression assumptions.
No live Spigot smoke test has been performed. Item metadata calls are verified with Mockito; actual flight, durability, trading, storage, loss/destruction, and post-reign inventory behavior rely on ordinary Minecraft item semantics and are not live-server tested. Renderer layout, menu policy, confirmation specification, and command delivery are tested separately rather than through a real client click sequence. Bukkit serializes these command and inventory handlers on the server thread; this does not provide arbitrary asynchronous callers with thread safety.
The existing persistence/delivery path is retained: YAML claims and Minecraft inventory saves are not a cross-store atomic transaction. Abrupt crashes or disk failures during delivery retain the preexisting risk of loss or duplication, and the existing state manager performs synchronous saves. No persistence architecture change or crash-atomicity guarantee is introduced. Backward compatibility means loading old saves in the new plugin, not downgrading to older binaries that do not recognize ELYTRA.