Refactor character persistence to use DataManager pattern

[FirebrickRed]

Priority: MEDIUM
Status: TODO

Description

CharacterPersistenceLoader currently implements its own loading/saving logic separate from the rest of the data loading architecture. It should follow the same pattern as RaceLoader, ClassLoader, etc. and integrate with DataManager.

Problem

Current Architecture:

• RaceLoader, ClassLoader, SpellLoader, etc. → All called from DataManager
• CharacterPersistenceLoader → Has its own static methods, called independently

This creates inconsistency:

• Different initialization patterns
• Different error handling
• Harder to understand data flow
• Character data not managed centrally like other D&D content

Goal

Make character persistence follow the same architectural pattern as other data loaders.

Acceptance Criteria

• Integrate CharacterPersistenceLoader with DataManager initialization
• Follow same pattern as other loaders (static registry, getter methods)
• Consistent error handling and logging
• Update CharacterSheetManager to use new pattern
• Ensure backward compatibility with existing saved characters
• Update CLAUDE.md documentation

Technical Notes

Likely involves:

• Moving character registry to be managed by DataManager
• Standardizing the loader interface/pattern
• May need to create a unified loader base class if pattern keeps repeating

Reference

See RaceLoader.java, ClassLoader.java for the pattern to follow.

Related Issues

This is part of architectural consistency - similar to how we refactored the selection menus (issue #7).

[FirebrickRed]

Additional Standardization Needed: File Storage Location

Current Problem:

CharacterPersistenceLoader stores files in a different location than other loaders:

// CharacterPersistenceLoader (line 26):
dataFolder = new File(plugin.getDataFolder(), "Characters");
// Saves to: plugins/jkvttplugin/Characters/*.yml

// All other loaders (via DataManager):
File dmContentFolder = new File(plugin.getDataFolder().getParentFile(), "DMContent");
// Loads from: DMContent/Races/*.yml, DMContent/Classes/*.yml, etc.

Issues This Creates:

1. Inconsistent Data Organization

   • D&D content (races, classes, spells, etc.) → DMContent/ folder
   • Character data → plugins/jkvttplugin/Characters/ folder
   • Makes it unclear where data lives

2. Different Initialization Pattern

   • Other loaders: Called from DataManager with consistent folder structure
   • Character loader: Has its own initialize() method with different folder logic

3. Confusing for Users

   • DMContent folder is outside the plugin folder for easy editing
   • Character data is inside plugin folder (harder to find/backup)

Proposed Solution:

Option A: Move to DMContent folder (Recommended)

DMContent/
├── Races/
├── Classes/
├── Spells/
└── Characters/     ← Move here

Option B: Keep separate but standardize pattern

• Still use plugins/jkvttplugin/Characters/
• But integrate with DataManager for consistency
• Add clear() method like other loaders

Benefits of Option A:

• All D&D-related data in one place
• Easier for users to backup/migrate servers
• Can use /reloadyaml to reload characters too
• More consistent with "DMContent" concept

Implementation Notes:

When refactoring, ensure:

• Backward compatibility (migrate existing character files)
• Update CLAUDE.md documentation
• Add migration logic or clear instructions for users
• Consider if characters should be reloadable via /reloadyaml

Related Code Locations:

• CharacterPersistenceLoader.java:26 - File location initialization
• DataManager.java - Where other content folders are defined
• JkVttPlugin.java - Where CharacterPersistenceLoader is initialized separately