feat: lock activity rewards for the whole week

[XxFran10xX]

Why

Rewards were read when a player claimed. So a /activity reload in the middle of a week (for example switching pool_prologue to an Act 1 pool) changed the current week. Unclaimed 10/20-point milestones paid from the new act, the weekly preview changed, and players got different loot for the same week.

What changes

• Week lock: the first load of each week copies rewards, bar.milestones and daily-reward.groups to plugins/activity/reward-lock.yml, tagged with the week key. Claims, the GUI preview, daily pool rewards and the claimable placeholder all use the locked copy.
• Reload / restart: config.yml's rewards are only staged (and still warned about). If they differ from the lock, the console says so and gives the reset time. The locked copy is re-read quietly so old warnings aren't repeated.
• Weekly reset: the first player-week roll of a new week locks the staged rewards for it (PlayerStore.get/rolled), before that player's points reset.
• /activity rewards (activity.admin): shows the locked week and whether changes are waiting. /activity reload prints the same status.
• /activity rewards apply: reloads and locks config.yml's rewards for the current week right away. If the lock can't be saved, the week keeps its locked rewards.
• The first start with this jar locks whatever config.yml has, so no migration is needed. The new messages fall back to the jar's messages.yml.

Tests

mvn verify: 816 tests pass, including the new ActivityConfigurationRewardLockTest (first lock, same-week reload keeps the lock, next week switches, roll, apply now, failed save, broken lock file, no jar-default pools, fixed drop blocks) and the command tests for rewards.

🤖 Generated with Claude Code

[coderabbitai]

No actionable comments were generated in the recent review. 🎉

ℹ️ Recent review info

⚙️ Run configuration

• Configuration used: Organization UI
• Review profile: CHILL
• Plan: Advanced
• Run ID: 7f0a90a2-1807-4b93-9321-c136454ccf0f

📥 Commits

Reviewing files that changed from the base of the PR and between e0bfb4a and fcfc082.

📒 Files selected for processing (9)

• README.md
• src/main/java/net/tfminecraft/activitytf/commands/ActivityCommand.java
• src/main/java/net/tfminecraft/activitytf/config/ActivityConfiguration.java
• src/main/java/net/tfminecraft/activitytf/store/PlayerStore.java
• src/main/resources/config.yml
• src/main/resources/messages.yml
• src/main/resources/plugin.yml
• src/test/java/net/tfminecraft/activitytf/commands/ActivityAdminCommandTest.java
• src/test/java/net/tfminecraft/activitytf/config/ActivityConfigurationRewardLockTest.java

Included review availability: This review used your included allowance. Your plan provides up to 10 included reviews per hour; 6 remain after this review.

---

📝 Summary

Summary by CodeRabbit

• New Features
  • Weekly rewards now remain fixed for the current week. Reward configuration changes take effect at the next weekly reset unless applied immediately.
  • Use /activity rewards to check the active reward week and whether changes are pending, or /activity rewards apply to apply them now.
  • /activity reload also displays reward status.
• Improvements
  • If immediate changes cannot be saved, the current week’s locked rewards remain in place and the command reports the failure.

Walkthrough

Weekly reward settings are now locked in reward-lock.yml for the active week. Configuration changes remain staged until the next weekly reset or an administrator applies them with /activity rewards apply.

Changes

Weekly reward locking

Layer / File(s)	Summary
Reward snapshots and weekly rollover src/main/java/net/tfminecraft/activitytf/config/ActivityConfiguration.java, src/main/java/net/tfminecraft/activitytf/store/PlayerStore.java, src/main/resources/config.yml, src/test/java/net/tfminecraft/activitytf/config/ActivityConfigurationRewardLockTest.java	Reward settings are saved for the active week. Changes to configuration remain pending until the next weekly reset or immediate application. Player data access triggers the reward-week check. Tests cover snapshot creation, rollover, save failures, and malformed lock data.
Reward status and immediate application src/main/java/net/tfminecraft/activitytf/commands/ActivityCommand.java, src/main/resources/messages.yml, src/main/resources/plugin.yml, README.md, src/test/java/net/tfminecraft/activitytf/commands/ActivityAdminCommandTest.java	/activity rewards reports the locked week and pending changes. /activity rewards apply attempts to apply them immediately. The command usage, messages, documentation, tab completion, and tests include the new subcommand.

Priority: ➖ Normal

Estimated code review effort: 3 (Moderate) | ~25 minutes

Change: Feature

Sequence Diagram(s)

sequenceDiagram
  participant Admin
  participant ActivityCommand
  participant ActivityConfiguration
  participant RewardLockFile as reward-lock.yml
  Admin->>ActivityCommand: run /activity rewards apply
  ActivityCommand->>ActivityConfiguration: reload and apply rewards
  ActivityConfiguration->>RewardLockFile: save current week's reward snapshot
  RewardLockFile-->>ActivityConfiguration: save result
  ActivityConfiguration-->>ActivityCommand: application result
  ActivityCommand-->>Admin: report success or save failure

Loading

Suggested reviewers: justinasla, ryanbarlow97

Merge Risk: ⚪ Minimal · up to fcfc0

Weekly rewards stay locked until the next reset or an admin apply, and a failed save leaves the current week's rewards unchanged. No concrete merge-blocking issue was found in the supplied changes.

Security Architecture Review

Security architecture risk: 🟡 Moderate · up to fcfc0

Administrative access remains protected, but failed snapshot writes can still activate rewards and report the week as locked. This weakens recovery guarantees and can leave all players using rewards that reloads or restarts do not preserve.

Retained concerns

• Medium · reliability · observed: Failed ordinary snapshot writes still activate staged rewards, advance the locked week, and clear pending status. Rollover ignores the save result, so repeated player accesses do not retry persistence and player resets and claims continue. The new durable authority can therefore disagree with active payouts, undermining restart recovery and the reported locked-week state. Immediate apply's safer failed-write branch does not protect ordinary rollover.

Security review details

Security Blast Radius

• inferred — The shared reward configuration affects all players served by one plugin instance. Configured reward commands retain server-console authority, so activation drift can affect both item payouts and configured command effects. That execution privilege predates this PR; its scope depends on the configured commands.

Trust Boundaries and Controls

• observed — The registered command executor checks activity.admin before dispatching rewards status or apply. The permission defaults to op, and a check-only sender is denied in the supplied test. These repository controls do not establish which production groups receive administrative permission.

Resilience and Maintainability Implications

• observed — Lock transitions are synchronized, and write failures produce a severe log message. Nevertheless, ordinary failed activation clears pending status and advances the week, preventing subsequent player rollover checks from retrying the failed commit. Serialization and logging therefore do not preserve durable reward ownership.

Hardening Proposals

• proposed — Use one durable activation protocol for rollover and immediate apply: commit a recoverable snapshot before advancing the locked week or permitting payouts, keep failed activation visible and retryable, and preserve a last-good snapshot during interrupted-write recovery.

• Autopilot · Keep fixing CodeRabbit findings and required CI, and resolving merge conflicts

---

_{Comment @coderabbitai help to get the list of available commands.}