# Working in this repo

Instructions for Claude when assisting on Naked Desire. Read this first; it is short by design.

## What this project is

- Unreal Engine **5.7** game. Single primary module: `NakedDesire`.
- NSFW exhibitionist sandbox / life-sim. Adult content is part of the design, not a bug.
- Single-player only. Multiplayer is out of scope (GDD §17.3) — do not add networking complexity.
- C++ for systems, Blueprint for content / animation hookups / UI widgets (GDD §17.5).

## Canonical documents (read in this order before non-trivial work)

1. **`README.md`** — Game Design Document. The design source of truth. Per GDD §23: when this doc and the code disagree, the doc wins until updated.
2. **`PLAN.md`** — phased dev plan + live status of what's implemented / partial / missing / conflicting. Update this when state changes.
3. The relevant `Source/NakedDesire/<Subsystem>/` folder.

If a request would change the design, update `README.md` first, then `PLAN.md`, then code. If a request changes implementation status, update `PLAN.md` in the same change.

## Repo layout

```
Source/NakedDesire/
  Clothing/         # Definitions, instance data, manager, slot data
  Global/           # GameMode, GameInstance, Constants, user settings, movement enums
  Interactables/    # Wardrobe, base interactable
  InteractionSystem/# Interaction manager + target interface
  Locations/        # LocationData + LocationTrigger (gameplay tag-driven areas)
  MissionBuilder/   # Mission/Goal/Restriction composition + concrete Goals/Restrictions
  NPC/              # NPC pawn, AI controller, spawner, target locations
  Player/           # NakedDesireCharacter, body part type, impostor, cinematic
  SaveGame/         # GlobalSaveGameData (single slot today)
  Stats/            # StatsManager (custom, not GAS yet)
Content/Blueprints/ # GameMode, GI, Player, NPC, Interactables, Data
Content/UI/         # Phone, HUD, Wardrobe, Shop, Inventory, etc. (BP widgets)
```

## Code conventions observed

- Copyright header on every C++ file: `// © 2025 Naked People Team. All Rights Reserved.` (some older files use the default "Fill out your copyright notice..." — replace when editing).
- `#pragma once` at the top of every header.
- Module export macro: `NAKEDDESIRE_API`.
- One class per file; folder per subsystem.
- DataAssets for static definitions (`UPrimaryDataAsset`); UObjects for instance / runtime data.
- BlueprintAssignable `DECLARE_DYNAMIC_MULTICAST_DELEGATE_*` for BP-exposed events; `DECLARE_MULTICAST_DELEGATE_*` for C++-only events.
- Localized strings use `LOCTEXT` with a `#define LOCTEXT_NAMESPACE "..."` / `#undef` block per file.
- Magic constants live in `Global/Constants.h` (e.g., `SLOT_NAME`, `IS_DEMO`).
- BlueprintImplementableEvents are widely used (time of day, end-game) — assume non-trivial logic lives in BP and grep `Content/` for asset usage when something seems "missing" from C++.

## Architectural rules (load-bearing)

- **Item identity (GDD §6.1)**: every item is a unique physical instance with a stable runtime ID. The current `UClothingItemData` does **not** satisfy this — Phase 1 of `PLAN.md` fixes it. Don't pile new content on top of the broken identity model.
- **Session loss (GDD §4.4)**: all "what gets lost" logic must live in a single `SessionLossResolver`. Do not scatter loss-handling into multiple components.
- **GAS-friendly attributes (GDD §17.2)**: attributes should map to a `UAttributeSet` eventually. Until Phase 4 lands, the custom `UStatsManager` is the source of truth — add new attributes there, but write them so they can migrate to GAS.
- **Data-driven content (GDD §17.4)**: clothing / commissions / food / NPC templates are DataAssets. Don't hardcode content into C++.

## When making changes

- **Match the surrounding code** — naming, copyright header, `UPROPERTY` metadata patterns, delegate style. If a folder has a convention, follow it before introducing a new one.
- **No premature abstractions** — three similar lines beat a half-built generic system. The GDD is detailed; let the actual systems drive shared interfaces, not speculation.
- **No backwards-compat shims** unless the user explicitly asks for one. Single-player game, no shipped saves to preserve unless the user says otherwise.
- **Don't mass-rename or restructure** without clearing it with the user first — Blueprint references to C++ classes / properties break silently when names change.

## Build / verify

- Mac project file: `NakedDesire (Mac).xcworkspace`. Can be built via Xcode or `xcodebuild` from CLI for a quick compile check.
- The user typically runs the editor — don't assume you can launch UE from CLI. After a code change, the build verification path is:
  1. Static code review (Read + reason).
  2. If unsure, ask the user to compile in-editor and report errors.
- Do not run destructive `git` actions (force push, reset --hard, branch -D) without explicit approval.

## Things to avoid

- Adding GAS bits piecemeal before Phase 4 (creates a split system).
- Editing `EClothingSlotType` casually — it currently mixes equipment slots and body parts; the cleanup is sequenced in Phase 1.
- Indexing `MissionsConfig->DailyMissions[DaysPassed]` without bounds checking — this is a known crash path (`NakedDesireGameMode.cpp:69`).
- Treating `Money` on `ANakedDesireCharacter` as authoritative — it is duplicated on the save game; both will be reconciled in the Phase 1 save refactor.
- Adding new persisted state to `UGlobalSaveGameData` directly — the schema is going to be rewritten in Phase 1. Coordinate before adding fields.

## Communication style

- The user is the game's developer (Oleh). Skip over-explanation of UE5 basics; do explain non-obvious design tradeoffs.
- Keep responses tight; cite `file:line` so the user can jump.
- If a task is ambiguous, ask before implementing. The GDD is long; assumptions are risky.