Initial commit

.local/AGENTS.md

@@ -0,0 +1,27 @@
+# AGENTS.md — Arena Mod
+
+## Mission
+Build a server-first NeoForge 1.21.1 PvE arena mod. The mod must remain usable without Cobblemon, EasyNPC, Create, or any boss mod.
+
+## Working rules
+1. `SPEC.md` is the functional source of truth. `ARCHITECTURE.md` is the technical source of truth.
+2. Work only on the current unchecked phase in `TODO.md`, unless explicitly asked otherwise.
+3. Inspect the existing project and dependency versions before coding. Never invent an API.
+4. For optional integrations (Cobblemon/EasyNPC/third-party entities), verify the actual installed API/source before writing integration code.
+5. Keep optional integrations isolated; absence of an optional mod MUST NOT prevent startup.
+6. Prefer Minecraft/NeoForge registries and resource IDs (`namespace:path`) over hard-coded vanilla lists.
+7. Content must be data-driven where specified. Invalid content disables only the affected definition and produces a useful diagnostic; it must not crash the server.
+8. Inventory safety is critical. Never clear a player's original inventory until its recovery snapshot has been durably persisted.
+9. Avoid unrelated refactors. Keep commits/changes scoped and easy to review.
+10. Compile/test after each phase. Fix compilation errors before declaring a phase complete.
+11. Add focused tests where practical, especially for pure logic (wave budgeting, rank thresholds, validation, state transitions).
+12. If implementation must diverge from these docs, document the reason in `ARCHITECTURE.md` before proceeding.
+13. Update `TODO.md` only for work actually completed.
+
+## Definition of done for a phase
+- Project compiles.
+- Existing tests still pass.
+- New behavior has a minimal test or reproducible manual test procedure.
+- No optional dependency became mandatory.
+- No known inventory-loss/duplication path was introduced.
+- `TODO.md` reflects reality.

.local/ARCHITECTURE.md

@@ -0,0 +1,81 @@
+# Architecture — NeoForge 1.21.1 Arena
+
+This document fixes responsibilities, not exact Java package names.
+
+## Modules/components
+### ArenaManager
+Owns registered arena definitions/controllers and active sessions. V1 may enforce one active arena, but APIs should accept arena/session IDs.
+
+### ArenaDefinition / ArenaControllerBlockEntity
+Persistent spatial configuration: relative bounds, locations, tagged spawn points, water baseline/max, presentation/config metadata. Controller is the coordinate origin.
+
+### ArenaSession
+Runtime state machine. Holds immutable starting roster/config snapshot plus mutable participant states, wave state, lives, tracked entities, environment transaction and reward progress.
+
+### ParticipantState
+UUID, class, ready/eliminated status, remaining arena kit state, reputation progress, recovery reference.
+
+### InventoryRecoveryService
+Durable, idempotent recovery snapshots. Owns save-before-clear, restore-on-exit/login, unfinished-session recovery and anti-duplication state transitions. Keep this isolated and heavily tested.
+
+### ContentRepository
+Loads/reloads/validates JSON definitions: classes, ranks, themes, mob variants, bosses, progression/balance config. Registry-aware validation produces diagnostics and disabled-definition lists.
+
+### ItemStackCodec / CaptureService
+Uses Minecraft's supported ItemStack serialization/data-component mechanisms for target version. In-game capture normalizes durability only, preserves stack count and other components, then writes canonical JSON.
+
+### WaveDirector
+Pure-ish deterministic logic where possible. Inputs: wave index, target budget, eligible themes, recent theme history, player scaling, RNG seed. Output: planned composition. Does not directly spawn entities.
+
+### SpawnService
+Turns planned entries into entities at validated tagged spawn points. Supports equipment, attributes, scale, vehicles/passengers and session tagging.
+
+### ArenaIsolationService
+Event-driven boundary/protection rules: entry/exit, teleport containment, block break/place, explosions, endermen, targeting, projectile crossing, loot/XP, interaction rules.
+
+### EnvironmentService
+Transactional temporary water modifications and restoration. Persist enough recovery information to undo interrupted flooding.
+
+### Reward/ReputationService
+UUID reputation/ranks, wave validation, victory currency, admin configuration.
+
+### Presentation/UI
+Titles/action bar, intuitive registration/class/ready screens or interactions. Player commands are not required. Admin commands remain separate.
+
+### Optional integrations
+Separate compatibility adapters loaded only when the mod is present:
+- Cobblemon: block/allow Pokémon actions according to arena rule.
+- EasyNPC: optional hooks/commands/API bridge if verified and useful.
+No Create dependency.
+
+## Persistence
+Use NeoForge/Minecraft-supported persistent data facilities appropriate to 1.21.1. Do not invent ad-hoc unsafe serialization when native codecs/registries are available.
+
+Persist at least:
+- controller/arena definition;
+- reputation/ranks data as appropriate;
+- inventory recovery records;
+- enough active-session recovery marker to detect an interrupted session;
+- temporary environment restoration data while modifications exist.
+
+## State machine invariants
+- Only registered participants may enter participant states.
+- Inventory snapshot success precedes inventory clearing.
+- Starting roster, average reputation tier, wave count and mode are frozen at countdown start.
+- Session-created entities carry session identity.
+- Cleanup is idempotent: running it twice must not duplicate rewards/items or damage the world.
+- Reward payout is idempotent.
+- Recovery is safe after abrupt server termination.
+
+## Data-driven compatibility
+Use ResourceLocations/registries for Item, EntityType, Attribute, enchantment/data component references supported by the target APIs. A definition may reference another mod without compile-time linkage.
+
+## Networking
+Keep authority server-side. Client packets are requests/UI actions only; server validates class unlocks, readiness, arena membership, admin permissions and configuration changes.
+
+## Performance
+- Do not scan the entire arena every tick.
+- Track session entities directly.
+- Boundary checks should be event-driven where possible; low-frequency sanity checks may repair missed crossings.
+- Water changes should be batched/throttled.
+- Spawn validation should inspect only candidate locations/entity dimensions.

.local/CODEX_PROMPTS.md

@@ -0,0 +1,13 @@
+# Minimal Codex prompts
+
+## First run
+Read `AGENTS.md`, `SPEC.md`, `ARCHITECTURE.md`, and `TODO.md`. Inspect the repository and implement **Phase 0 only**. Do not implement later phases. Compile/test, fix errors, then update `TODO.md` only for work actually completed.
+
+## Subsequent run
+Implement the next unchecked phase in `TODO.md`. Follow `AGENTS.md`; read only the relevant sections of `SPEC.md` and `ARCHITECTURE.md`, then inspect existing code before editing. Do not implement later phases. Compile/test, fix errors, and update `TODO.md` accurately.
+
+## Bug-fix run
+Investigate this bug against `SPEC.md` and `ARCHITECTURE.md`: <BUG>. Reproduce or identify the failing path first. Make the smallest safe fix, add a regression test when practical, compile/test, and do not refactor unrelated code.
+
+## Integration run
+Implement <INTEGRATION> only after inspecting the exact installed dependency/API version. Do not guess API names. Keep the integration optional and verify the mod still starts without that dependency.

.local/SPEC.md

@@ -0,0 +1,213 @@
+# Functional Specification — PvE Arena
+
+Target: Minecraft Java 1.21.1, NeoForge. Server-first multiplayer PvE arena, initially designed for up to ~4 simultaneous participants.
+
+## 1. Core principles
+- One arena is required for V1, but core code SHOULD avoid an irreversible singleton design.
+- A placed **Arena Controller** is the spatial reference for the arena.
+- Arena geometry is builder-owned. The mod manages combat/session rules, not arena construction.
+- Coordinates for arena points are stored relative to the controller.
+- Player-facing flow MUST be intuitive and MUST NOT require player commands.
+- Admin commands/tools MAY be used for setup and content editing.
+- Vanilla and modded items/entities are referenced by registry IDs. Unknown IDs invalidate only the affected definition.
+
+## 2. Arena Controller and bounds
+The controller stores/configures:
+- asymmetric 3D bounding box (`x-`, `x+`, `y-`, `y+`, `z-`, `z+`);
+- lobby/hall location;
+- participant entry/ready location(s);
+- respawn location;
+- exit location;
+- boss spawn;
+- tagged mob spawn points (`GROUND`, `WATER`, optional future tags);
+- water baseline/max level;
+- optional environment/redstone hooks.
+
+Admin MUST be able to visualize bounds and configured points using temporary client-visible effects/particles. Bounds MUST be adjustable without rebuilding the arena.
+
+Spawn validation MUST reject points that cannot fit the entity's actual dimensions (including scale), are obstructed, lack appropriate support/fluid, or are dangerously close to a participant. The director retries another compatible point.
+
+## 3. Session lifecycle
+Nominal states:
+`IDLE -> REGISTRATION -> CLASS_SELECTION -> READY -> COUNTDOWN -> WAVES -> BOSS -> VICTORY -> CLEANUP -> IDLE`
+
+Exceptional endings:
+`DEFEAT`, `ABORTED`, `SERVER_RECOVERY` -> `CLEANUP`.
+
+Flow:
+1. Player registers.
+2. Original player state is durably snapshotted.
+3. Only after successful persistence, arena-controlled inventory/state is applied.
+4. Player enters hall and chooses an unlocked class.
+5. Player enters ready area and marks Ready.
+6. When all registered participants are ready, registration closes and countdown starts.
+7. Waves run.
+8. Final boss encounter runs.
+9. Victory/defeat/abort cleans all arena entities/environment and restores players.
+
+Late joining after countdown is forbidden.
+
+## 4. Inventory safety
+This is a hard requirement.
+- Persist recovery data BEFORE clearing/changing the player's original inventory.
+- Snapshot at minimum: main inventory, hotbar, armor, offhand; include other player state only if implementation deliberately modifies it.
+- On normal exit/elimination: remove arena kit, restore original snapshot, then mark recovery complete.
+- On disconnect/crash: remove player from active session. If restoration cannot happen while offline, restore automatically on next login.
+- On server restart with an unfinished session: cancel/recover the session. Online participants are moved outside and restored; offline participants are restored on next login.
+- A failed snapshot MUST prevent arena entry and MUST NOT clear inventory.
+- Restoration logic MUST be designed to avoid both loss and duplication.
+
+## 5. Classes
+Classes are JSON-defined and include:
+- ID/display name;
+- required reputation rank;
+- armor slots, offhand and inventory;
+- optional descriptive metadata.
+
+Item definitions MUST support full `ItemStack` data/components so vanilla or modded items can retain enchantments, custom name/lore, dyes, banner/shield patterns, armor trims, attributes and other registered data components.
+
+Admin editing:
+- `addItemFromHand` (or equivalent) copies the full held stack into the class JSON.
+- Captured stack quantity MUST equal held quantity for stackable items.
+- Captured damage/durability MUST be normalized to fully repaired.
+- Capture MUST NOT consume the admin's held item.
+- Armor/offhand slot capture commands SHOULD exist.
+- JSON remains the source of truth; in-game editing updates the JSON and revalidates/reloads the class.
+- `/arena class give <class> [player]` gives a copy of the complete class kit for testing/display (e.g. armor racks), without registering a session.
+
+Class choice locks when the player becomes Ready. Multiple players MAY choose the same class unless later configured otherwise.
+
+On participant death with lives remaining:
+- arena kit does not drop;
+- consumed items are NOT restocked;
+- durability/remaining stack counts are preserved;
+- player respawns in the arena respawn zone with the same remaining kit state.
+
+## 6. Reputation and ranks
+- Reputation is permanent, per-player progression keyed by UUID.
+- Currency is separate and spendable.
+- Ranks are JSON-defined thresholds, e.g. Recruit/Fighter/Veteran/Champion.
+- Classes SHOULD require a rank ID rather than duplicate numeric thresholds.
+- Average reputation/rank of the starting group determines the session's configured wave-count tier. This is frozen at session start and never recalculated after disconnect/elimination.
+- Reputation is earned per validated wave.
+- In clear-to-progress mode, wave N validates when its required mobs are defeated.
+- In timed-pressure mode, wave N validates when wave N+2 is reached; victory validates any remaining pending waves.
+- Eliminated players keep reputation already earned.
+
+## 7. Lives and modes
+Keep "mode" separate from wave power/budget.
+
+Default modes:
+### Clear-to-progress (easy-style)
+- Lives are individual.
+- Next wave begins after all required arena mobs for current wave are defeated.
+- Wave validation occurs on clear.
+
+### Timed-pressure (hard-style)
+- Lives are shared by the team.
+- Each wave starts after a configured timer even if previous-wave enemies remain.
+- Wave N reputation validates when N+2 is reached.
+
+Exact life counts/timers/multipliers are configurable balancing values.
+
+When a player has no applicable life remaining, they are eliminated:
+- removed from session participation;
+- teleported outside;
+- original inventory restored.
+Remaining participants continue. Defeat occurs when no active participants remain (subject to mode rules).
+
+## 8. Wave Director
+Wave difficulty is budget/score-driven, not encoded as `easy/hard` on themes.
+
+Each theme JSON defines:
+- ID/display name;
+- selection weight;
+- mob/variant pool;
+- each entry: cost, weight, optional min/max, compatible spawn tags;
+- optional environmental requirement such as water level.
+
+For each wave:
+1. Determine target score/budget from wave progression, player-count scaling and configurable session scaling.
+2. Select a valid theme.
+3. A theme used recently is excluded for the next 5 waves by default (`themeCooldown`, configurable).
+4. If too few themes exist, gracefully relax cooldown using least-recently-used fallback.
+5. Compose mobs until near target budget while respecting weights/min/max.
+6. Spawn progressively through validated compatible spawn points.
+
+Player-count scaling SHOULD primarily increase mob budget/count. Health scaling MAY increase modestly and MUST be separately configurable; avoid turning normal mobs into excessive HP sponges.
+
+At wave start, participants receive a Title:
+- title: `Vague <N>`
+- subtitle: theme display name.
+Action bar MAY show useful mode-specific status (remaining enemies or next-wave timer).
+
+## 9. Mob variants, equipment, mounts
+Mob definitions MAY include equipment/full item stack components and configurable registered attributes such as max health, attack damage, armor, movement and `minecraft:scale`.
+
+Composite spawns MUST support vehicles/passengers (e.g. spider jockey, mounted skeleton). Treat a composite as one director selection with one total cost. Limit nesting depth.
+
+Third-party registered entity IDs MAY be used without a compile-time dependency. Missing entity/item/attribute IDs invalidate the affected definition with diagnostics, not server startup.
+
+## 10. Bosses
+- Wither MAY be the default boss but is not mandatory.
+- Boss definitions are data-driven and MAY reference vanilla or modded registered entities.
+- Pseudo-bosses MAY apply name, scale, attributes, equipment, boss bar and optional adds/minions.
+- Third-party boss compatibility is best-effort; arena containment and cleanup still apply.
+- Boss rewards scale with completed session/wave tier.
+- Optional boss mods must never become required dependencies.
+
+## 11. Arena isolation and protection
+During an active session, the arena bounding box is a logical sealed boundary.
+- Participants cannot leave except through arena-controlled teleport/exit.
+- Non-participant players cannot enter.
+- Arena mobs cannot leave; outside mobs cannot enter.
+- Projectiles/effects must not cross the boundary in either direction where technically interceptable; unsafe crossing projectiles should be cancelled/removed.
+- Arena mobs SHOULD NOT target non-participants.
+- Endermen cannot move arena blocks and cannot teleport outside.
+- Explosions can retain combat effects but MUST NOT destroy arena blocks.
+- Participants cannot place or break arena blocks.
+- Existing arena interactions remain usable where safe: ladders, slime blocks, doors/trapdoors/buttons, wind charges, etc.
+- Arena mobs SHOULD drop no normal loot/XP unless explicitly configured.
+- All session-spawned entities (mobs, mounts, passengers, minions, relevant projectiles) are tagged/tracked by session and cleaned on end/recovery.
+- Spectator stands may exist immediately outside the bounding box; spectators must not influence combat.
+
+## 12. Water environment
+No dynamic obstacle system in V1. Builders own obstacles.
+
+Themes MAY request temporary arena flooding by 0..N block layers above a configured water baseline.
+- Only safe/replaceable positions may be temporarily filled.
+- Never overwrite permanent arena geometry blindly.
+- Track every modified position needed for exact restoration.
+- Water MAY rise/fall progressively for presentation.
+- Restore on theme transition as designed, session end, abort and recovery.
+- Recovery MUST handle server restart without leaving permanent unintended flooding.
+- `WATER` spawn points become eligible when appropriate.
+
+## 13. Cobblemon and other integrations
+Cobblemon support is OPTIONAL.
+- If absent, arena works normally.
+- If present, arena rules can allow or block Pokémon use/sending/battling during a session.
+- Integration code must be isolated and written only against verified APIs for the installed target version.
+
+EasyNPC is OPTIONAL presentation/integration only. Core registration/readiness/session behavior must work without it.
+Create is NOT a dependency. Builders may use Create/redstone around the arena independently.
+
+## 14. Rewards and forfeit
+- Currency reward is equal per qualifying starting participant; do not create a pot that grows for survivors when teammates are eliminated.
+- Default: currency is awarded on final victory; amount depends on completed wave/session tier and configurable scaling.
+- Reward item/currency can be configured in-game from a held ItemStack and persisted in configuration.
+- Reputation is progression-based as described above.
+- Collective forfeit is available through an in-chat vote among active participants.
+- Default vote: absolute majority; solo = immediate. Duration/config is configurable.
+- Successful forfeit -> ABORTED -> cleanup, exit and inventory restoration; no victory currency.
+
+## 15. Validation philosophy
+Provide useful startup/reload/admin diagnostics for:
+- missing registry IDs;
+- malformed class/theme/boss definitions;
+- impossible min/max/cost values;
+- missing required arena points;
+- invalid bounds/spawn points;
+- incompatible boss size warning.
+
+Invalid content should be disabled locally whenever safe instead of crashing the server.

.local/TODO.md

@@ -0,0 +1,132 @@
+# Implementation Plan
+
+Do one phase at a time. Keep the project compiling after every phase.
+
+- [x] **Phase 0 — Bootstrap**
+  - Confirm exact NeoForge/Minecraft/Java versions and mappings from the project.
+  - Create minimal mod entrypoint/config/logging.
+  - Establish packages and basic test setup.
+  - No gameplay yet.
+  - Completed: `arena` entrypoint, server config/startup logging, `com.shinuwa.arena`
+    and `config` packages; removed template gameplay/client examples.
+  - Versions confirmed: Minecraft 1.21.1, NeoForge 21.1.235, Java 21
+    (local JDK 21.0.8), NeoGradle 7.1.38, Gradle 9.2.1,
+    NeoForm 1.21.1-20240808.144430, Parchment 1.21.1 / 2024.11.17.
+  - Validation: `./gradlew build test --offline` succeeded; 3 JUnit 5.11.4
+    configuration tests passed. Rebuilt and inspected `arena-1.0.0.jar`:
+    correct metadata, no template content, only Minecraft/NeoForge dependencies.
+  - README documents build instructions and dedicated/integrated server smoke
+    tests. Full server/client startup remains a manual check, not executed here.
+
+- [ ] **Phase 1 — Data model + content loading**
+  - Resource IDs, ranks, class definitions, themes, mob variants, bosses, balance/progression.
+  - JSON loading/reload and validation diagnostics.
+  - Add example built-in/default data.
+  - Unit-test pure validators where practical.
+
+- [ ] **Phase 2 — Arena Controller + admin setup**
+  - Controller block/block entity.
+  - Relative asymmetric bounding box.
+  - Configurator/admin commands for bounds and points.
+  - Particle visualization of bounds/points.
+  - Tagged spawn points and validation diagnostics.
+  - Export/import arena definition if cleanly supportable.
+
+- [ ] **Phase 3 — Inventory recovery foundation**
+  - Durable snapshot-before-clear transaction.
+  - Restore and idempotency.
+  - Restore-on-login for disconnected/offline players.
+  - Interrupted-session recovery marker.
+  - Test failure paths before adding full sessions.
+
+- [ ] **Phase 4 — Session state machine**
+  - Registration, class selection, ready, countdown, active, victory/defeat/abort, cleanup.
+  - Starting roster/config freeze.
+  - Disconnect = remove participant + pending restoration.
+  - Server restart = cancel/recover.
+  - No waves yet; use simple admin-driven state transitions for tests.
+
+- [ ] **Phase 5 — Classes + reputation**
+  - Class unlock by JSON rank.
+  - Full kit application.
+  - Death handling: no drops, preserve remaining kit state, respawn if life remains.
+  - Elimination restores original inventory.
+  - `addItemFromHand`/slot capture writes JSON, preserves components/count, repairs durability.
+  - `/arena class give`.
+  - Reputation persistence/ranks.
+
+- [ ] **Phase 6 — Wave Director**
+  - Budget-driven composition.
+  - Theme weights, 5-wave default cooldown + graceful fallback.
+  - Entry cost/weight/min/max.
+  - Player-count budget scaling and modest configurable health scaling.
+  - Deterministic tests with seeded RNG.
+  - Wave Title/subtitle.
+
+- [ ] **Phase 7 — Spawning + advanced mob variants**
+  - Spawn-point validation.
+  - Equipment/components/attributes/scale.
+  - Vehicles/passengers with nesting limit.
+  - Session entity tagging/tracking.
+  - Modded registry entity support without compile dependency.
+
+- [ ] **Phase 8 — Modes, lives, progression**
+  - Clear-to-progress individual lives.
+  - Timed-pressure shared lives.
+  - N+2 reputation validation for timed mode.
+  - Wave count tier from frozen group average reputation.
+  - Action bar status.
+  - Defeat conditions.
+
+- [ ] **Phase 9 — Arena isolation**
+  - Block break/place protection.
+  - Explosion terrain protection.
+  - Entity/player boundary entry/exit.
+  - Enderman restrictions.
+  - Projectile crossing.
+  - Targeting isolation.
+  - Loot/XP suppression.
+  - Cleanup of all tracked arena entities.
+  - Verify spectator stands outside bounds cannot influence session.
+
+- [ ] **Phase 10 — Boss system + rewards**
+  - Data-driven vanilla/modded boss EntityType.
+  - Pseudo-boss attributes/scale/equipment/boss bar/adds.
+  - Victory detection.
+  - Equal per-player victory currency, scaled by completed tier.
+  - Held-item currency configuration.
+  - Idempotent payout.
+
+- [ ] **Phase 11 — Water environment**
+  - Configurable baseline/max.
+  - Safe temporary fill for requested layers.
+  - Progressive batched rise/fall.
+  - Exact transactional restoration.
+  - Crash/restart recovery.
+  - WATER spawn integration.
+
+- [ ] **Phase 12 — Player UX + forfeit**
+  - Intuitive registration/class/ready UX; no player commands required.
+  - Participant/class/ready recap.
+  - In-chat forfeit vote and timeout.
+  - Polish titles/action bar/errors.
+  - Accessibility/readability pass.
+
+- [ ] **Phase 13 — Optional Cobblemon integration**
+  - Verify actual target Cobblemon API first.
+  - Optional adapter only.
+  - Configurable allow/block Pokémon use/battles during arena session.
+  - Test startup with Cobblemon absent and present.
+
+- [ ] **Phase 14 — Optional EasyNPC bridge**
+  - Only if useful and actual API is verified.
+  - NPC may initiate/open arena services but must not own core logic.
+  - Test startup with EasyNPC absent.
+
+- [ ] **Phase 15 — Hardening/release**
+  - Multiplayer tests (1–4 players).
+  - Disconnect/reconnect, kill server mid-session, abort, repeated cleanup.
+  - Duplication/loss tests.
+  - Invalid JSON/mod removed between restarts.
+  - Performance profiling with high mob counts.
+  - Admin documentation and example configs.

.local/examples/bosses/raider_lord.json

@@ -0,0 +1,13 @@
+{
+  "id": "raider_lord",
+  "display_name": "Seigneur des Pillards",
+  "entity": "minecraft:ravager",
+  "spawn_tag": "BOSS",
+  "attributes": {
+    "minecraft:scale": 1.25,
+    "minecraft:max_health": 180.0,
+    "minecraft:armor": 12.0,
+    "minecraft:attack_damage": 16.0
+  },
+  "boss_bar": true
+}

.local/examples/classes/warrior.json

@@ -0,0 +1,32 @@
+{
+  "id": "warrior",
+  "display_name": "Guerrier",
+  "required_rank": "recruit",
+  "equipment": {
+    "head": {
+      "item": "minecraft:iron_helmet"
+    },
+    "chest": {
+      "item": "minecraft:iron_chestplate"
+    },
+    "legs": {
+      "item": "minecraft:iron_leggings"
+    },
+    "feet": {
+      "item": "minecraft:iron_boots"
+    },
+    "offhand": {
+      "item": "minecraft:shield"
+    }
+  },
+  "inventory": [
+    {
+      "item": "minecraft:iron_sword",
+      "count": 1
+    },
+    {
+      "item": "minecraft:cooked_beef",
+      "count": 16
+    }
+  ]
+}

.local/examples/progression.json

@@ -0,0 +1,30 @@
+{
+  "theme_cooldown": 5,
+  "party_scaling": {
+    "1": 1.0,
+    "2": 1.75,
+    "3": 2.5,
+    "4": 3.25
+  },
+  "health_scaling": {
+    "1": 1.0,
+    "2": 1.1,
+    "3": 1.2,
+    "4": 1.3
+  },
+  "reputation_wave_tiers": [
+    {
+      "min_average_reputation": 0,
+      "wave_count": 10
+    },
+    {
+      "min_average_reputation": 500,
+      "wave_count": 15
+    },
+    {
+      "min_average_reputation": 1500,
+      "wave_count": 20
+    }
+  ],
+  "note": "Illustrative balancing values; tune during playtesting."
+}

.local/examples/ranks.json

@@ -0,0 +1,24 @@
+{
+  "ranks": [
+    {
+      "id": "recruit",
+      "display_name": "Recrue",
+      "min_reputation": 0
+    },
+    {
+      "id": "fighter",
+      "display_name": "Combattant",
+      "min_reputation": 250
+    },
+    {
+      "id": "veteran",
+      "display_name": "Vétéran",
+      "min_reputation": 750
+    },
+    {
+      "id": "champion",
+      "display_name": "Champion",
+      "min_reputation": 2000
+    }
+  ]
+}

.local/examples/themes/aquatic.json

@@ -0,0 +1,30 @@
+{
+  "id": "aquatic",
+  "display_name": "Les profondeurs",
+  "weight": 6,
+  "environment": {
+    "water_level": 3
+  },
+  "mobs": [
+    {
+      "entity": "minecraft:drowned",
+      "cost": 2.0,
+      "weight": 10,
+      "min": 2,
+      "max": 18,
+      "spawn_tags": [
+        "WATER"
+      ]
+    },
+    {
+      "entity": "minecraft:guardian",
+      "cost": 5.0,
+      "weight": 3,
+      "min": 0,
+      "max": 4,
+      "spawn_tags": [
+        "WATER"
+      ]
+    }
+  ]
+}

.local/examples/themes/cavern.json

@@ -0,0 +1,40 @@
+{
+  "id": "cavern",
+  "display_name": "Monstres des cavernes",
+  "weight": 10,
+  "environment": {
+    "water_level": 0
+  },
+  "mobs": [
+    {
+      "entity": "minecraft:zombie",
+      "cost": 1.0,
+      "weight": 10,
+      "min": 0,
+      "max": 20,
+      "spawn_tags": [
+        "GROUND"
+      ]
+    },
+    {
+      "entity": "minecraft:spider",
+      "cost": 1.5,
+      "weight": 8,
+      "min": 0,
+      "max": 12,
+      "spawn_tags": [
+        "GROUND"
+      ]
+    },
+    {
+      "entity": "minecraft:cave_spider",
+      "cost": 2.5,
+      "weight": 4,
+      "min": 0,
+      "max": 5,
+      "spawn_tags": [
+        "GROUND"
+      ]
+    }
+  ]
+}