diff --git a/.superpowers/sdd/2026-08-18-first-visible-vertical-slice/task-4-report.md b/.superpowers/sdd/2026-08-18-first-visible-vertical-slice/task-4-report.md
deleted file mode 100644
index 923642b..0000000
--- a/.superpowers/sdd/2026-08-18-first-visible-vertical-slice/task-4-report.md
+++ /dev/null
@@ -1,50 +0,0 @@
-# Task 4: Health and demo-character API report
-
-## RED
-
-- Re-read every Markdown document below `docs/` and inspected `combat-screen.png`, `hunting-screen.png`, and `world-travel-screen.png` before implementation.
-- Added focused health and character-service tests, then ran:
-
-  ```powershell
-  npm test --workspace=@ashen-realms/api -- health.controller.spec.ts characters.service.spec.ts --runInBand
-  ```
-
-- Observed the expected RED result: both suites failed because `HealthController` and `CharactersService` did not exist.
-
-## GREEN
-
-- Replaced the scaffold root controller/service with `HealthModule` and `CharactersModule`.
-- `GET /api/health` returns `{ status: 'ok' }` without a database query.
-- `GET /api/characters/me` obtains the fixed demo ID server-side, loads `currentLocation`, maps `baseHp` to `maxHp` and `baseAttack` to `attack`, and raises `NotFoundException` when the seed is absent.
-- Preserved the existing tested `configureApplication()` global-prefix seam and enabled Nest shutdown hooks in `main.ts` without repeating prefix configuration.
-- Updated the E2E assertion from the retired hello-world root route to `/api/health`; it replaces both database-dependent modules so the health test remains database independent.
-
-## Verification
-
-| Command | Result |
-| --- | --- |
-| `npm test --workspace=@ashen-realms/api -- health.controller.spec.ts characters.service.spec.ts --runInBand` | PASS: 2 suites, 3 tests |
-| `npm run test:e2e --workspace=@ashen-realms/api -- --runInBand` | PASS: 1 suite, 2 tests |
-| `npm test --workspace=@ashen-realms/api -- --runInBand` | PASS: 5 suites, 9 tests |
-| `npm run build:api` | PASS |
-| `apps/api/node_modules/.bin/prettier.cmd --check <task files>` | PASS |
-| `git diff --check` | PASS |
-
-`npx prettier` did not resolve the workspace-local executable in this environment; the checked-in workspace binary at `apps/api/node_modules/.bin/prettier.cmd` was used for the formatting check.
-
-## Files
-
-- Added `apps/api/src/health/*` and character controller/service/module plus unit tests.
-- Updated `apps/api/src/app.module.ts`, `apps/api/src/main.ts`, and `apps/api/test/app.e2e-spec.ts`.
-- Removed `apps/api/src/app.controller.ts`, `app.controller.spec.ts`, and `app.service.ts`.
-
-## Self-review and concerns
-
-- Confirmed the repository query loads only the required current-location relation and response does not expose persistence-only base-stat names.
-- Confirmed the missing seed path is tested as a 404-producing Nest exception.
-- Confirmed `/` remains a 404 while `/api/health` is available through the existing global prefix.
-- No task-specific concerns remain. Pre-existing untracked `apps/web/public/images/` and `docs/references/Ashen_Realms_Visual_Asset_Style_Guide_V1.md` are intentionally excluded.
-
-## Commit
-
-- Pending: `feat: expose health and demo character APIs`
diff --git a/.superpowers/sdd/2026-08-18-first-visible-vertical-slice/task-5-report.md b/.superpowers/sdd/2026-08-18-first-visible-vertical-slice/task-5-report.md
deleted file mode 100644
index 2ddf12b..0000000
--- a/.superpowers/sdd/2026-08-18-first-visible-vertical-slice/task-5-report.md
+++ /dev/null
@@ -1,105 +0,0 @@
-# Task 5 Report: Server-authoritative travel
-
-## Outcome
-
-Implemented the NestJS travel domain and public endpoints:
-
-- `POST /api/travel`
-- `GET /api/travel/current`
-- injected deterministic/system clock abstraction
-- exact `StartTravelDto` input validation
-- stable idle, travelling, completed, and domain-error response shapes
-- `TravelModule` registration in the application
-
-Travel start and completion use `DataSource.transaction`. Both operations acquire a pessimistic write lock on the character row followed by the active travel row. Relations are deliberately not joined into either locking query, which keeps the queries compatible with TypeORM/PostgreSQL `FOR UPDATE` behavior. Due completion changes the travel status and character location through repositories owned by the same transaction; a failed second save rolls back both mutations.
-
-No ambush evaluation or other later-slice logic was added. Existing untracked frontend images and the visual asset guide were preserved and excluded from the commit.
-
-## RED evidence
-
-Command:
-
-```powershell
-npm test --workspace=@ashen-realms/api -- travel.service.spec.ts travel.controller.spec.ts --runInBand
-```
-
-Initial result: exit code 1. Both suites failed to resolve the missing production modules:
-
-```text
-Cannot find module './travel.service' from 'travel/travel.service.spec.ts'
-Cannot find module './travel.controller' from 'travel/travel.controller.spec.ts'
-Test Suites: 2 failed, 2 total
-Tests:       0 total
-```
-
-The active-travel regression test was also mutation-checked. Temporarily removing the `TRAVEL_ALREADY_ACTIVE` guard produced the expected focused failure (`Expected constructor: TravelDomainError; Received constructor: Object`); restoring the guard returned the test to green.
-
-## GREEN evidence
-
-Focused travel tests:
-
-```powershell
-npm test --workspace=@ashen-realms/api -- travel.service.spec.ts travel.controller.spec.ts --runInBand
-```
-
-```text
-Test Suites: 2 passed, 2 total
-Tests:       9 passed, 9 total
-Time:        10.973 s
-```
-
-The service suite covers all five required behaviors plus active-travel rejection, public current-travel mapping, idempotent repeat completion, pessimistic-lock observation, and rollback when the second completion save fails. The controller suite drives a real Nest HTTP pipeline and verifies that server-owned timestamp/duration fields receive HTTP 400.
-
-Full API suite:
-
-```powershell
-npm test --workspace=@ashen-realms/api -- --runInBand
-```
-
-```text
-Test Suites: 7 passed, 7 total
-Tests:       18 passed, 18 total
-Time:        15.87 s
-```
-
-API E2E:
-
-```powershell
-npm run test:e2e --workspace=@ashen-realms/api -- --runInBand
-```
-
-```text
-Test Suites: 1 passed, 1 total
-Tests:       2 passed, 2 total
-Time:        9.406 s
-```
-
-API build:
-
-```powershell
-npm run build:api
-```
-
-Result: exit code 0 (`nest build`).
-
-Formatting and lint:
-
-```powershell
-apps/api/node_modules/.bin/prettier.cmd --check <Task 5 files>
-node_modules/.bin/eslint.cmd <Task 5 files>
-```
-
-Both commands exited 0. Prettier reported `All matched files use Prettier code style!`; ESLint reported no findings.
-
-## Integration notes and self-review
-
-- The first build exposed TypeScript `TS1272` for a decorated `Clock` parameter under `isolatedModules`; importing `Clock` as a type fixed the root cause, after which tests and build were rerun.
-- Registering the database-backed `TravelModule` exposed that the existing health E2E test replaced `DatabaseModule` and `CharactersModule` but not travel. The harness now replaces `TravelModule` as well, preserving the database-free health test.
-- Lock order is identical in start and completion, reducing deadlock risk.
-- The character row serializes concurrent starts even when no active travel row exists yet; the partial unique database index remains the final invariant.
-- The due comparison treats `arrivesAt === now` as due and never moves the character earlier.
-- Public responses contain only location summaries and travel timestamps/status, never entities, duration input, ambush probability, or persistence metadata.
-
-## Remaining concern
-
-No live-PostgreSQL travel integration test was added because the repository's current E2E harness intentionally runs without a database; clean migration/seed/API database smoke coverage belongs to Task 10. The transaction code uses supported real `EntityManager.getRepository`, `Repository.findOne` lock options, `findOneBy`, `create`, and `save` behavior, and the stateful fake verifies transaction commit/rollback semantics rather than mock call counts.
diff --git a/.superpowers/sdd/2026-08-18-first-visible-vertical-slice/task-6-report.md b/.superpowers/sdd/2026-08-18-first-visible-vertical-slice/task-6-report.md
deleted file mode 100644
index 2ed8589..0000000
--- a/.superpowers/sdd/2026-08-18-first-visible-vertical-slice/task-6-report.md
+++ /dev/null
@@ -1,83 +0,0 @@
-# Task 6 — Current-location World API report
-
-## Scope delivered
-
-- Added `WorldService.getCurrentLocation(characterId)`.
-- Added `GET /api/world/current-location` using the stable demo character.
-- Added `WorldModule`, including TypeORM repositories for `Character` and
-  `LocationConnection`, and imported it through `AppModule`.
-- `WorldService` completes due travel before loading the character, returns the
-  complete current-location DTO, returns only enabled outgoing connections, and
-  exposes a target summary, duration, and textual danger rating only. The raw
-  `ambushChance` is not part of the public DTO; `0.0500` maps to `LOW`.
-- Kept the existing database-free health E2E harness valid by overriding the
-  newly imported `WorldModule`, just as it already overrides the database,
-  character, and travel modules.
-
-## Required preflight
-
-- Read the complete Task-6 brief and the binding project documentation,
-  including the visual asset style guide.
-- Inspected `world-travel-screen.png`, `combat-screen.png`, and
-  `hunting-screen.png` in `docs/references/`.
-- Preserved the user-owned untracked `apps/web/public/images/` directory and
-  `docs/references/Ashen_Realms_Visual_Asset_Style_Guide_V1.md` unchanged.
-
-## TDD evidence
-
-### RED
-
-Command:
-
-```powershell
-npm test --workspace=@ashen-realms/api -- world.service.spec.ts --runInBand
-```
-
-Initial result: failed because `./world.service` did not exist. After the
-minimal initial implementation, the test exposed that a disabled connection
-could still be returned by an unexpected repository result. The service now
-defensively filters disabled connections in addition to querying with
-`enabled: true`.
-
-### GREEN
-
-```powershell
-npm test --workspace=@ashen-realms/api -- world.service.spec.ts --runInBand
-```
-
-Result: 1 suite passed, 2 tests passed.
-
-## Verification evidence
-
-```powershell
-npm test --workspace=@ashen-realms/api -- --runInBand
-# 8 suites passed, 20 tests passed
-
-npm run test:e2e --workspace=@ashen-realms/api -- --runInBand
-# 1 suite passed, 2 tests passed
-
-npm run build:api
-# Nest build completed successfully
-
-# From apps/api:
-.\node_modules\.bin\prettier.cmd --check <Task-6 TypeScript files>
-npx eslint <Task-6 TypeScript files>
-# Prettier: all matched files use Prettier code style; ESLint exit 0
-
-git diff --check -- apps/api/src/app.module.ts apps/api/src/world apps/api/test/app.e2e-spec.ts
-# exit 0
-```
-
-The initial E2E run was reproducibly red because the new `WorldModule` caused
-TypeORM repository construction after the test had intentionally replaced the
-database module. Adding its corresponding empty module override restored the
-existing database-free health test without changing product behavior.
-
-## Deliberate limits and concerns
-
-- The approved first slice only needs the seeded 5% route, so the public
-  connection danger mapping currently distinguishes `LOW` (at or below 5%) and
-  `HIGH` (above 5%). Future routes may require finer danger tiers when their
-  product thresholds are specified.
-- This task adds no database-backed route E2E assertion; the dedicated
-  migration/seed route smoke test is scheduled for Task 10.
diff --git a/.superpowers/sdd/2026-08-18-first-visible-vertical-slice/task-7-report.md b/.superpowers/sdd/2026-08-18-first-visible-vertical-slice/task-7-report.md
deleted file mode 100644
index 372b9cc..0000000
--- a/.superpowers/sdd/2026-08-18-first-visible-vertical-slice/task-7-report.md
+++ /dev/null
@@ -1,151 +0,0 @@
-# Task 7 — Angular typed API and signal-driven WorldStore report
-
-## Scope delivered
-
-- Added typed public response models and `GameApiService` methods for character,
-  current location, travel start, and current travel.
-- Configured Angular's application providers with `HttpClient`.
-- Added `WorldStore` with private writable and public read-only signals for
-  character, world location, selection, travel, countdown, loading, and errors.
-- The store derives presentation-only countdown seconds from server `arrivesAt`.
-  At zero it polls the API and never assigns the target location locally.
-- Character and location are reloaded only after the API returns `COMPLETED`.
-
-## Required preflight
-
-- Re-read every document under `docs/`, including the approved design and
-  implementation plan, and inspected all three PNG reference images.
-- Read the user-supplied visual asset guide. The untracked `apps/web/public/images/`
-  directory and `docs/references/Ashen_Realms_Visual_Asset_Style_Guide_V1.md`
-  remain unchanged and unstaged.
-
-## TDD evidence
-
-### RED
-
-```powershell
-npm test --workspace=@ashen-realms/web -- --watch=false
-```
-
-Initial result: failed as expected because `game-api.service`,
-`game-api.models`, and `world.store` did not exist. The compiler reported only
-their unresolved imports from the newly added tests.
-
-### GREEN
-
-```powershell
-npm test --workspace=@ashen-realms/web -- --watch=false --include='src/app/core/api/game-api.service.spec.ts' --include='src/app/features/world/world.store.spec.ts'
-```
-
-Result: 2 test files passed, 7 tests passed.
-
-The store tests cover initial loading, target-only travel start, `arrivesAt`
-countdown calculation, polling at zero without local arrival, and reload only
-after `COMPLETED`.
-
-## Verification evidence
-
-```powershell
-npm test --workspace=@ashen-realms/web -- --watch=false
-# 3 test files passed, 9 tests passed
-
-npm run build:web
-# Angular production build completed successfully
-
-npm exec --workspace=@ashen-realms/web -- prettier --check <Task-7 files>
-# All matched files use Prettier code style
-
-git diff --check -- <Task-7 files>
-# exit 0
-```
-
-## Review fix round 2
-
-The transient-poll regression now asserts both phases: the failed poll exposes
-`Temporary failure`, and the successful authoritative `IDLE` retry clears it.
-The new assertion was RED against the prior implementation because the error
-remained set after the retry. `refreshCurrentTravel()` now clears the polling
-error only after a successful API response and before applying that response;
-the countdown contract and all other error paths are unchanged.
-
-Fresh verification:
-
-```powershell
-npm test --workspace=@ashen-realms/web -- --watch=false --include='src/app/features/world/world.store.spec.ts'
-# 1 test file passed, 9 tests passed
-
-npm test --workspace=@ashen-realms/web -- --watch=false
-# 3 test files passed, 13 tests passed
-
-npm run build:web
-# Angular production build completed successfully
-
-npm exec --workspace=@ashen-realms/web -- prettier --check <Task-7 files>
-# All matched files use Prettier code style
-
-git diff --check -- <Task-7 files>
-# exit 0
-```
-
-The web workspace declares neither a `lint` script nor an ESLint dependency, so
-there is no repository-configured lint command to run for this task.
-
-## Deliberate limits and concerns
-
-- The store retains a `COMPLETED` travel response after its authoritative
-  character/location refresh. The following API poll returns `IDLE`; the later
-  world UI can decide when to clear the completion presentation.
-- The mandated code-review workflow normally requires a reviewer subagent, but
-  this task explicitly prohibited subagents. The implementation was instead
-  reviewed directly against the task brief and verified through the focused and
-  complete web test/build checks above.
-
-## Review fix round 1
-
-### Findings addressed
-
-- A journey whose `arrivesAt` was already in the past made an immediate poll
-  but also installed a countdown interval. This could overlap an outstanding
-  request.
-- A late response after store destruction could still apply state and start
-  follow-on work.
-
-The store now makes a single immediate poll at local zero with no countdown
-interval. It uses one in-flight poll at a time and schedules a deliberate
-one-second retry when the server still returns `TRAVELLING` or a poll fails.
-All late async continuations check the destroy flag before changing state or
-scheduling timers. The browser still never declares arrival or changes the
-location itself.
-
-### TDD evidence
-
-```powershell
-npm test --workspace=@ashen-realms/web -- --watch=false --include='src/app/features/world/world.store.spec.ts'
-```
-
-RED result: 2 of 9 tests failed against the previous implementation. The
-already-expired test observed three calls where a pending request must allow
-only two, and the destroy test observed an unwanted second character/location
-reload after a late `COMPLETED` response.
-
-GREEN result: 1 test file passed, 9 tests passed. The expanded cases establish
-that `IDLE` and continuing `TRAVELLING` do not reload authoritative character
-or location data, expired/skewed client time remains single-flight/throttled,
-a transient poll error retries and recovers, and destruction ignores a late
-response.
-
-### Fresh verification
-
-```powershell
-npm test --workspace=@ashen-realms/web -- --watch=false
-# 3 test files passed, 13 tests passed
-
-npm run build:web
-# Angular production build completed successfully
-
-npm exec --workspace=@ashen-realms/web -- prettier --check <Task-7 files>
-# All matched files use Prettier code style
-
-git diff --check -- <Task-7 files>
-# exit 0
-```
diff --git a/.superpowers/sdd/2026-08-18-first-visible-vertical-slice/task-8-report.md b/.superpowers/sdd/2026-08-18-first-visible-vertical-slice/task-8-report.md
deleted file mode 100644
index 134ed2e..0000000
--- a/.superpowers/sdd/2026-08-18-first-visible-vertical-slice/task-8-report.md
+++ /dev/null
@@ -1,74 +0,0 @@
-# Task 8 report: reusable Angular application shell
-
-## Scope delivered
-
-- Replaced the Angular scaffold with a route-hosting root component and a reusable dark-fantasy shell.
-- Added focused standalone components for the app shell, store-driven top bar, side navigation, footer, and context-panel frame.
-- Added requested design tokens, spacing, motion, elevation, global reset, responsive shell grid, and reduced-motion protection.
-- Configured `/` and fallback routing to `/world`; the route lazy-loads a deliberately scene-free `WorldPageComponent` placeholder so Task 9 can add the world composition without changing the route contract.
-- Made Karte the only enabled active navigation entry. Jagd, Quests, Inventar, and Charakter are disabled buttons with accessible explanatory labels. Shop is not rendered.
-- Top-bar character identity, level, and hit points are rendered only from `WorldStore.character`; it has no hardcoded character statistics.
-
-## Preflight and asset evidence
-
-- Re-read the Task 8 brief, visible-slice implementation plan, progress ledger, prior task reports, and the full user-provided visual asset style guide.
-- Visually inspected `combat-screen.png`, `hunting-screen.png`, and `world-travel-screen.png` before editing.
-- Visually inspected the relevant user HUD assets before use. The shell uses only:
-  - `apps/web/public/images/hud/CharacterIcon.png`
-  - `apps/web/public/images/hud/MapsIcon.png`
-  - `apps/web/public/images/hud/HuntIcon.png`
-  - `apps/web/public/images/hud/QuestsIcon.png`
-  - `apps/web/public/images/hud/InventoryIcon.png`
-
-## TDD evidence
-
-### RED
-
-`npm test --workspace=@ashen-realms/web -- --watch=false` failed as intended before production work: the new shell specification expected `app-top-bar`, but the scaffold only contained a router outlet. The existing two test files remained green (11 passing tests).
-
-### GREEN
-
-`npm test --workspace=@ashen-realms/web -- --watch=false` passed with 3 test files and 12 tests. The added shell test asserts top bar, side navigation, semantic main content, footer, enabled active Karte, disabled future destinations, and Shop absence.
-
-## Final verification
-
-- `npm test --workspace=@ashen-realms/web -- --watch=false`: 3 files and 12 tests passing.
-- `npm run build:web`: production Angular build passed and emits a lazy `world-page-component` chunk.
-- `npm exec --workspace=@ashen-realms/web -- prettier --check ...`: all Task 8 files formatted.
-- `git diff --check`: no whitespace errors.
-
-## Visual QA limitation
-
-The Browser plugin is not available in this session. The repository has no installed Playwright package, and a non-mutating `npm exec --workspace=@ashen-realms/web -- playwright --version` check could not resolve a local runner and timed out. No browser dependency was added outside task scope. Rendered browser verification remains for Task 11, which owns final browser workflow and fidelity captures.
-
-## Intentional limits
-
-- The world route placeholder contains no scene, nodes, API loading, or travel panel; Task 9 owns those surfaces.
-- The context panel is only a reusable framed shell until Task 9 supplies world data.
-
-## Review fix round 1
-
-### Accessibility and responsive behavior
-
-- The active Karte button now has the explicit accessible name `Karte`, so its label remains available when the compact viewport hides visible navigation text.
-- At widths below 900px, the context panel now reflows into a full-width row below main content instead of being hidden. At widths below 620px it remains in DOM order after main content.
-
-### Runtime HUD derivatives
-
-The five original 1254 x 1254 user assets remain unmodified. The shell now loads deterministic 128 x 128 PNG derivatives from `images/hud/runtime/`; each was resized locally with high-quality bicubic interpolation and no creative image change.
-
-| Asset | Original bytes | Runtime derivative bytes |
-| --- | ---: | ---: |
-| CharacterIcon | 2,283,892 | 26,670 |
-| MapsIcon | 2,144,772 | 27,774 |
-| HuntIcon | 2,313,949 | 29,486 |
-| QuestsIcon | 2,235,955 | 29,554 |
-| InventoryIcon | 2,060,169 | 26,142 |
-
-The combined persistent-icon payload is reduced from 11,038,737 bytes to 139,626 bytes (about 98.7%). The resized Maps icon was visually inspected after generation.
-
-### Regression evidence
-
-RED: the added explicit accessible-name assertion failed before the fix because the active Karte control had no `aria-label`.
-
-GREEN: `npm test --workspace=@ashen-realms/web -- --watch=false` passed with 3 test files and 14 tests. The added coverage verifies the explicit Karte name, non-null WorldStore character rendering, and root/wildcard `/world` route redirects.
diff --git a/.superpowers/sdd/2026-08-18-first-visible-vertical-slice/task-9-report.md b/.superpowers/sdd/2026-08-18-first-visible-vertical-slice/task-9-report.md
deleted file mode 100644
index a015e6d..0000000
--- a/.superpowers/sdd/2026-08-18-first-visible-vertical-slice/task-9-report.md
+++ /dev/null
@@ -1,51 +0,0 @@
-# Task 9 Report: World UI
-
-## Reference inventory
-
-- `world-travel-screen.png`: persistent top bar and left navigation, a dominant central map, labelled current/reachable nodes with a dotted path, dense right context, and a bottom-centred travel decision panel.
-- `hunting-screen.png`: confirms the shared dark iron/bronze material treatment, restrained gold highlights, readable serif display hierarchy, and dense information without white cards or modern pills.
-- `combat-screen.png`: confirms the same persistent shell, dark desaturated palette, thin ornate borders, and blue only as a controlled active-state accent.
-
-The reference screenshots were inspected but are not shipped or referenced by the application.
-
-## Artwork and layout decision
-
-- No ImageGen was used: the controller ruling makes the delivered user artwork final.
-- `/images/backgrounds/map_ashen_realm.png` is the dominant WorldPage scene. Its wide path, city, watchtower, and ash-field composition provides a clearer interactive map than either location image.
-- The server-delivered location paths are `/images/backgrounds/Suedtor.png` and `/images/backgrounds/Aschestrasse.png`; the ContextPanel renders the authoritative current-location image, so it changes only after server-confirmed arrival.
-- This deliberately supersedes the older brief wording that asked for generated assets and API artwork as the main scene background. It preserves the binding controller ruling while retaining the server-provided artwork as context.
-
-## Delivered behavior
-
-- `WorldPageComponent` loads `WorldStore` on init, renders a code-native SVG connection and two code-native location buttons, shows loading/error/retry states, and never advances location locally.
-- `LocationNodeComponent` exposes current, selected, reachable, disabled, hover, and focus states with textual labels.
-- `TravelPanelComponent` presents no-selection guidance, selected target/travel-time/danger with `Reise beginnen`, and an arrivesAt-derived travelling countdown with disabled action.
-- `ContextPanelComponent` renders the current/selected location, description, recommended level, safe status, hunting status, and server artwork.
-- Seed paths now match the delivered assets and are covered by the API seed test.
-
-## Review-fix round
-
-- Map-node geography is now anchored to the stable location keys (`south-gate` and `burned-road`). Current, reachable, and selected state only changes presentation; a regression test swaps the authoritative current location without moving either node.
-- On a server `COMPLETED` response, the selected connection is cleared and the store stays loading until the authoritative character/location/travel reload completes. All travel actions are disabled in that interval; no local arrival or location update is performed.
-- The moving countdown is a `<time role="timer">` without a broad live region. The selected and travelling mode headings remain labelled for assistive technology.
-- The decision panel now occupies normal document flow below the map scene, reserving a non-overlapping zone at desktop and narrow breakpoints.
-- The original delivered PNGs remain untouched. A deterministic local System.Drawing JPEG conversion (quality 86, high-quality bicubic) provides runtime derivatives: `map_ashen_realm-1440.jpg` (1440x810, 233,778 B), `Suedtor-960.jpg` (960x540, 94,286 B), and `Aschestrasse-960.jpg` (960x540, 93,277 B). The WorldPage and ContextPanel prefer these derivatives while retaining each server artwork path as the `<img>` fallback.
-- The load error is exposed as an alert and its retry control is covered by a store-load regression test.
-- The map no longer declares the runtime JPEG and original PNG as comma-separated background layers. It uses the original PNG as the classic CSS fallback and, where `image-set` with JPEG is supported, replaces it with one runtime JPEG candidate. The WorldPage regression test verifies there is no inline multi-layer binding or `mapBackground` source left to reintroduce the double load.
-
-## Verification
-
-- RED confirmed: four new WorldPage contracts failed against the empty placeholder; seed artwork-path assertion failed against the former WebP paths.
-- Focused WorldPage test: 4/4 pass.
-- Full web tests: 18/18 pass.
-- Affected API seed tests: 2/2 pass.
-- `npm run build:web` and `npm run build:api` pass.
-- Review focused World/Store/Context tests: 19 pass (4 files; 4 pre-existing skips).
-- Review full web suite: 23/23 pass.
-- Affected API seed test: 2/2 pass.
-- Both review builds (`npm run build:web`, `npm run build:api`) pass.
-- Review-fix round 2: focused WorldPage test 7/7 pass; full web suite and web build re-run after the fallback change.
-
-## Remaining concern
-
-Rendered browser fidelity QA is intentionally deferred to Task 11, as instructed. The Browser plugin is unavailable and no Playwright fallback was started for this task.
diff --git a/docs/playable-slices/Ashen Realms – Playable Slice 0.2_ First Hunt.md b/docs/playable-slices/Ashen Realms – Playable Slice 0.2_ First Hunt.md
new file mode 100644
index 0000000..dcfeabb
--- /dev/null
+++ b/docs/playable-slices/Ashen Realms – Playable Slice 0.2_ First Hunt.md	
@@ -0,0 +1,1803 @@
+# Ashen Realms – Playable Slice 0.2: First Hunt
+
+**Status:** Ready for implementation  
+**Scope:** Hunting / Encounter Selection  
+**Prerequisite:** Playable Slice 0.1 – World & Travel is implemented and working  
+**Primary Location:** Verbrannte Straße  
+**Primary Goal:** The player can start a hunt at the Verbrannte Straße, receive 2–3 server-generated encounters, view them in the Angular UI, refresh the hunt, and select one encounter for the future combat flow.
+
+---
+
+# 1. Goal
+
+Implement the next playable step of the Ashen Realms core loop:
+
+```text
+Travel
+→ arrive at Verbrannte Straße
+→ start hunt
+→ receive encounters
+→ inspect enemies
+→ choose an enemy
+```
+
+This slice must prove that:
+
+- hunting is tied to the current authoritative location
+- encounter generation happens only on the server
+- available monsters are data-driven
+- the player cannot freely request arbitrary monster IDs
+- the frontend presents encounters visually instead of as a plain list
+- the existing Ashen Realms application shell and visual language remain consistent
+
+This slice deliberately stops before actual combat resolution.
+
+The next slice will be:
+
+```text
+Playable Slice 0.3 – First Combat
+```
+
+---
+
+# 2. Non-goals
+
+Do **not** implement the following in this slice:
+
+- combat engine
+- combat persistence
+- combat actions
+- damage calculation
+- loot
+- XP rewards
+- silver rewards
+- inventory
+- equipment
+- item drops
+- quests
+- merchants
+- area currencies
+- bosses
+- elites beyond data preparation
+- authentication
+- random travel ambushes
+- advanced status effects
+- timers for hunting
+- real-time communication
+- WebSockets
+- background jobs
+
+Do not expand the architecture for systems that are not required by this slice.
+
+---
+
+# 3. Existing assumptions
+
+The project already contains:
+
+```text
+Angular frontend
+NestJS backend
+PostgreSQL
+TypeORM
+npm workspace monorepo
+```
+
+Existing gameplay systems already provide:
+
+```text
+Character
+LocationDefinition
+LocationConnection
+Travel
+current character location
+world screen
+travel between Südtor and Verbrannte Straße
+server-authoritative travel completion
+```
+
+The existing application shell must remain unchanged:
+
+```text
+TopBar
+SideNavigation
+Main Content
+Context Panel
+Footer
+```
+
+The new hunting UI must integrate into this shell.
+
+---
+
+# 4. Core gameplay flow
+
+The intended player flow is:
+
+```text
+Player travels to Verbrannte Straße
+↓
+Travel completes on the server
+↓
+Player opens "Jagd"
+↓
+Frontend loads current location
+↓
+Player clicks "Jagd beginnen"
+↓
+POST /api/hunts
+↓
+Server verifies that hunting is allowed
+↓
+Server loads monster pool for current location
+↓
+Server selects 2–3 encounters
+↓
+Hunt and HuntEncounter records are persisted
+↓
+Frontend displays encounter cards
+↓
+Player may:
+    choose an encounter
+    or
+    click "Neu suchen"
+```
+
+Selecting an encounter does not yet start real combat.
+
+The selected `HuntEncounter.id` must already be usable by the future combat slice.
+
+---
+
+# 5. Domain rules
+
+## 5.1 Hunting availability
+
+Hunting is only allowed when:
+
+```text
+character.currentLocation.huntingEnabled === true
+```
+
+For the current slice:
+
+```text
+Südtor von Graufurt
+huntingEnabled = false
+
+Verbrannte Straße
+huntingEnabled = true
+```
+
+If hunting is started at a location where hunting is disabled, the backend must reject the request.
+
+Example domain error:
+
+```json
+{
+  "statusCode": 400,
+  "code": "HUNTING_NOT_AVAILABLE",
+  "message": "Hunting is not available at the current location."
+}
+```
+
+---
+
+# 6. Monster content model
+
+Introduce a persistent content definition for monsters.
+
+## 6.1 MonsterDefinition
+
+Create:
+
+```text
+apps/api/src/monsters/entities/monster-definition.entity.ts
+```
+
+Required fields:
+
+```ts
+id: uuid
+
+key: string
+name: string
+
+level: number
+
+maxHp: number
+attack: number
+armor: number
+
+experienceReward: number
+
+silverMin: number
+silverMax: number
+
+artworkPath: string
+
+createdAt: timestamptz
+updatedAt: timestamptz
+```
+
+Constraints:
+
+```text
+key must be unique
+```
+
+Examples:
+
+```text
+ash-rat
+road-bandit
+```
+
+The backend must use `key` for stable content references.
+
+UUIDs remain persistence identifiers.
+
+---
+
+# 7. Location monster pool
+
+Create the relationship between a location and its possible monsters.
+
+## 7.1 LocationMonster
+
+Create:
+
+```text
+apps/api/src/monsters/entities/location-monster.entity.ts
+```
+
+Fields:
+
+```ts
+id: uuid
+
+locationId: uuid
+monsterId: uuid
+
+weight: number
+
+encounterType: string
+
+enabled: boolean
+```
+
+Recommended initial encounter types:
+
+```text
+NORMAL
+RARE
+ELITE
+BOSS
+```
+
+For this slice only:
+
+```text
+NORMAL
+```
+
+is required.
+
+The relationship must allow the same monster definition to appear at multiple locations later.
+
+---
+
+# 8. Initial monster content
+
+Seed exactly two monsters for this slice.
+
+## 8.1 Aschenratte
+
+Stable key:
+
+```text
+ash-rat
+```
+
+Display name:
+
+```text
+Aschenratte
+```
+
+Values:
+
+```text
+Level: 1
+XP reward: 8
+Silver: 4–7
+```
+
+Combat values may use provisional deterministic numbers if they are not already defined elsewhere.
+
+They are not used for actual combat in this slice.
+
+Recommended placeholder values:
+
+```text
+maxHp: 45
+attack: 5
+armor: 0
+```
+
+If existing project content already defines different values, preserve the existing values instead.
+
+Artwork:
+
+```text
+/assets/monsters/ash-rat.webp
+```
+
+or use the actual existing asset path in the repository.
+
+Do not invent a duplicate asset if an appropriate one already exists.
+
+---
+
+# 9. Straßenräuber
+
+Stable key:
+
+```text
+road-bandit
+```
+
+Display name:
+
+```text
+Straßenräuber
+```
+
+Values:
+
+```text
+Level: 2
+XP reward: 16
+Silver: 9–15
+```
+
+Recommended provisional combat values:
+
+```text
+maxHp: 75
+attack: 9
+armor: 5
+```
+
+Again:
+
+If the repository already contains finalized values, use those instead.
+
+Artwork:
+
+```text
+/assets/monsters/road-bandit.webp
+```
+
+or the actual existing asset path.
+
+---
+
+# 10. Location pool for Verbrannte Straße
+
+Both monsters must be assigned to:
+
+```text
+burned-road
+```
+
+Example:
+
+```text
+Aschenratte
+weight = 70
+
+Straßenräuber
+weight = 30
+```
+
+The exact weight numbers are implementation values for this technical slice and may later be rebalanced.
+
+The system must not hardcode monster selection based on location keys inside the HuntingService.
+
+The service must load the pool from persisted `LocationMonster` records.
+
+---
+
+# 11. Hunt persistence
+
+Create:
+
+```text
+apps/api/src/hunting/entities/hunt.entity.ts
+```
+
+## 11.1 Hunt
+
+Fields:
+
+```ts
+id: uuid
+
+characterId: uuid
+locationId: uuid
+
+status: enum
+
+createdAt: timestamptz
+```
+
+For this slice the status may contain:
+
+```text
+ACTIVE
+SUPERSEDED
+```
+
+Optional:
+
+```text
+SELECTED
+```
+
+if useful for the later combat handoff.
+
+Keep the state model small.
+
+---
+
+# 12. HuntEncounter persistence
+
+Create:
+
+```text
+apps/api/src/hunting/entities/hunt-encounter.entity.ts
+```
+
+Fields:
+
+```ts
+id: uuid
+
+huntId: uuid
+monsterDefinitionId: uuid
+
+position: number
+
+createdAt: timestamptz
+```
+
+Recommended positions:
+
+```text
+0
+1
+2
+```
+
+The encounter must persist the monster that was rolled.
+
+A later combat flow must reference:
+
+```text
+HuntEncounter.id
+```
+
+and not accept arbitrary `MonsterDefinition.id` values from the frontend.
+
+This is a critical server-authority requirement.
+
+---
+
+# 13. Hunting module
+
+Create:
+
+```text
+apps/api/src/hunting/
+```
+
+Recommended structure:
+
+```text
+hunting/
+├── dto/
+│   └── hunt-response.dto.ts
+├── entities/
+│   ├── hunt.entity.ts
+│   └── hunt-encounter.entity.ts
+├── hunting.controller.ts
+├── hunting.module.ts
+├── hunting.service.ts
+└── hunting.service.spec.ts
+```
+
+---
+
+# 14. HuntingService
+
+Required service:
+
+```ts
+class HuntingService
+```
+
+Primary method:
+
+```ts
+startHunt(characterId: string): Promise<HuntResultDto>
+```
+
+Responsibilities:
+
+```text
+load character
+↓
+resolve authoritative current location
+↓
+verify no active travel prevents interaction
+↓
+verify location exists
+↓
+verify huntingEnabled
+↓
+load enabled LocationMonster records
+↓
+validate that pool is not empty
+↓
+select 2–3 encounters
+↓
+persist Hunt
+↓
+persist HuntEncounter records
+↓
+return DTO
+```
+
+The entire operation should use a transaction where appropriate.
+
+---
+
+# 15. Travel interaction
+
+A player who is currently travelling must not be able to hunt.
+
+The backend must remain authoritative.
+
+If an active travel exists:
+
+```json
+{
+  "statusCode": 409,
+  "code": "CHARACTER_TRAVELLING",
+  "message": "The character cannot hunt while travelling."
+}
+```
+
+Do not rely on Angular to enforce this rule.
+
+---
+
+# 16. Empty monster pool
+
+If hunting is enabled but no enabled monster definitions exist for the location, return a clear server error.
+
+Example:
+
+```json
+{
+  "statusCode": 409,
+  "code": "NO_HUNT_ENCOUNTERS_AVAILABLE",
+  "message": "No encounters are currently available at this location."
+}
+```
+
+Do not silently return an empty hunt.
+
+---
+
+# 17. Encounter count
+
+The desired gameplay rule is:
+
+```text
+2–3 encounters
+```
+
+For the first implementation, the server may choose:
+
+```text
+3 encounters by default
+```
+
+if the pool contains enough valid entries.
+
+Duplicate monster types are allowed.
+
+Example:
+
+```text
+Aschenratte
+Straßenräuber
+Aschenratte
+```
+
+This is acceptable.
+
+Each encounter still receives its own unique `HuntEncounter.id`.
+
+---
+
+# 18. Weighted random selection
+
+Encounter selection must be server-side and based on `LocationMonster.weight`.
+
+Do not use:
+
+```ts
+Math.random()
+```
+
+directly throughout business logic.
+
+Introduce a small injectable random source.
+
+Example:
+
+```ts
+export interface RandomSource {
+  next(): number;
+}
+```
+
+Production implementation:
+
+```ts
+next(): number {
+  return Math.random();
+}
+```
+
+Tests must inject deterministic values.
+
+This is required so encounter selection tests remain reproducible.
+
+---
+
+# 19. Weighted selection behavior
+
+Conceptually:
+
+```text
+Aschenratte weight 70
+Straßenräuber weight 30
+```
+
+means the rat is more likely to appear.
+
+Selection may be performed independently for each encounter slot.
+
+No duplicate prevention is required for this slice.
+
+---
+
+# 20. API
+
+Create:
+
+```http
+POST /api/hunts
+```
+
+No request body is required.
+
+The server already knows the current demo character.
+
+Do not send:
+
+```json
+{
+  "locationId": "...",
+  "monsterId": "..."
+}
+```
+
+The client must not determine the hunting location or monster pool.
+
+The server derives both from the current character state.
+
+---
+
+# 21. Hunt response DTO
+
+Example response:
+
+```json
+{
+  "id": "hunt-uuid",
+  "location": {
+    "id": "location-uuid",
+    "key": "burned-road",
+    "name": "Verbrannte Straße"
+  },
+  "encounters": [
+    {
+      "id": "encounter-uuid-1",
+      "monster": {
+        "key": "ash-rat",
+        "name": "Aschenratte",
+        "level": 1,
+        "artworkPath": "/assets/monsters/ash-rat.webp"
+      },
+      "dangerRating": "MATCH"
+    },
+    {
+      "id": "encounter-uuid-2",
+      "monster": {
+        "key": "road-bandit",
+        "name": "Straßenräuber",
+        "level": 2,
+        "artworkPath": "/assets/monsters/road-bandit.webp"
+      },
+      "dangerRating": "STRONG"
+    },
+    {
+      "id": "encounter-uuid-3",
+      "monster": {
+        "key": "ash-rat",
+        "name": "Aschenratte",
+        "level": 1,
+        "artworkPath": "/assets/monsters/ash-rat.webp"
+      },
+      "dangerRating": "MATCH"
+    }
+  ]
+}
+```
+
+Do not expose:
+
+```text
+monster attack
+monster armor
+monster maxHp
+loot tables
+drop chances
+internal weights
+raw Combat Power
+```
+
+through the hunt overview unless required later.
+
+---
+
+# 22. Danger rating
+
+Ashen Realms uses these visible ratings:
+
+```text
+WEAK
+MATCH
+STRONG
+VERY_DANGEROUS
+DEADLY
+```
+
+For this slice, danger rating must still be determined by the backend.
+
+Do not calculate it in Angular.
+
+If the full `CharacterStatsService` already exists, use the existing combat-power logic.
+
+If not, create a deliberately small temporary server-side calculation.
+
+For this slice it is acceptable to return sensible values for the demo character:
+
+```text
+Aschenratte → MATCH
+Straßenräuber → STRONG
+```
+
+Do not implement the full equipment progression system solely for this feature.
+
+The API contract should already use the final enum.
+
+---
+
+# 23. Refreshing the hunt
+
+The player must be able to click:
+
+```text
+Neu suchen
+```
+
+This should call:
+
+```http
+POST /api/hunts
+```
+
+again.
+
+The previous hunt may be marked:
+
+```text
+SUPERSEDED
+```
+
+before the new hunt becomes active.
+
+Do not delete historical hunt data.
+
+Only one current active hunt should exist per character.
+
+Enforce this through service logic and, if practical, a database constraint.
+
+---
+
+# 24. Frontend route
+
+Create or activate:
+
+```text
+/hunt
+```
+
+The navigation entry:
+
+```text
+Jagd
+```
+
+must become enabled.
+
+Karte remains available.
+
+Other unfinished routes should remain disabled or unchanged.
+
+---
+
+# 25. Hunt page behavior
+
+Create a hunting feature under:
+
+```text
+apps/web/src/app/features/hunting/
+```
+
+Recommended structure:
+
+```text
+hunting/
+├── hunt-page/
+├── encounter-card/
+├── hunting-api.service.ts
+└── hunting.store.ts
+```
+
+Adapt this to the existing frontend architecture if equivalent abstractions already exist.
+
+Do not introduce a second competing state-management pattern.
+
+---
+
+# 26. Hunt page initial state
+
+When opening `/hunt`, the frontend must load enough data to know:
+
+```text
+current location
+whether hunting is available
+whether character is travelling
+```
+
+Reuse existing world/character state where appropriate.
+
+Avoid duplicate API requests if an existing store already owns authoritative location data.
+
+---
+
+# 27. Location without hunting
+
+If the player opens `/hunt` while at Südtor:
+
+Display an in-world empty state.
+
+Example:
+
+```text
+Keine Jagd verfügbar
+
+Am Südtor von Graufurt gibt es keine regulären Jagdgebiete.
+Reise in ein gefährlicheres Gebiet, um nach Gegnern zu suchen.
+```
+
+Primary action:
+
+```text
+Zur Karte
+```
+
+Do not show an enabled "Jagd beginnen" button.
+
+---
+
+# 28. Hunt start state
+
+At Verbrannte Straße, before a hunt has been started:
+
+The main content should show:
+
+```text
+location artwork / thematic background
+location name
+short hunting description
+primary button:
+Jagd beginnen
+```
+
+Do not automatically start a hunt merely by opening `/hunt`.
+
+The player should explicitly trigger the action.
+
+---
+
+# 29. Encounter presentation
+
+After `POST /api/hunts`, display the returned encounters as large visual cards.
+
+Each card must contain:
+
+```text
+monster artwork
+monster name
+level
+danger rating
+short descriptive label if already available
+Angreifen button
+```
+
+The monster artwork is the visual focus.
+
+Do not render the hunt as:
+
+```text
+plain HTML table
+compact admin list
+generic Material cards
+Bootstrap dashboard tiles
+```
+
+---
+
+# 30. Encounter card layout
+
+Desktop target:
+
+```text
+2–3 large cards in one row
+```
+
+Each card should provide enough artwork space that the monster is visually prominent.
+
+Example structure:
+
+```text
+┌──────────────────────┐
+│                      │
+│     Monster Art      │
+│                      │
+├──────────────────────┤
+│ Aschenratte          │
+│ Stufe 1              │
+│ Passend              │
+│                      │
+│ [ Angreifen ]        │
+└──────────────────────┘
+```
+
+The visual language must match the existing Ashen Realms UI.
+
+---
+
+# 31. Danger badge
+
+Create or reuse:
+
+```text
+DangerBadgeComponent
+```
+
+Supported states:
+
+```text
+Schwach
+Passend
+Stark
+Sehr gefährlich
+Tödlich
+```
+
+Color must not be the only communication method.
+
+Always include readable text.
+
+Use the existing design token system.
+
+Do not hardcode independent colors inside the hunt component if equivalent global tokens already exist.
+
+---
+
+# 32. Right context panel
+
+While on the hunt screen, the right-side context panel should show:
+
+```text
+Verbrannte Straße
+
+Gebiet:
+Aschenfelder
+
+Empfohlene Stufe:
+1–3
+
+Gefahr:
+Niedrig
+
+Mögliche Begegnungen:
+Aschenratte
+Straßenräuber
+```
+
+Do not expose exact encounter probabilities.
+
+Do not expose hidden weights.
+
+The context panel should complement the encounter cards rather than repeat every detail.
+
+---
+
+# 33. Hunt actions
+
+Required actions:
+
+```text
+Jagd beginnen
+Neu suchen
+Angreifen
+Zur Karte
+```
+
+For this slice:
+
+### Jagd beginnen
+
+Creates first hunt.
+
+### Neu suchen
+
+Creates another hunt.
+
+### Angreifen
+
+Selects the encounter for future combat.
+
+### Zur Karte
+
+Navigates back to:
+
+```text
+/world
+```
+
+---
+
+# 34. Angreifen behavior in this slice
+
+Combat does not exist yet.
+
+Therefore the button must **not** create fake client-side combat.
+
+When clicked:
+
+Store or route with:
+
+```text
+HuntEncounter.id
+```
+
+Recommended implementation:
+
+```text
+navigate to:
+/combat/new?encounterId=<uuid>
+```
+
+or prepare an equivalent route consistent with the application.
+
+If `/combat` is not yet implemented, display a clearly intentional placeholder state such as:
+
+```text
+Kampf wird im nächsten Playable Slice implementiert.
+```
+
+However:
+
+Do not build a fake combat screen.
+
+Do not generate damage.
+
+Do not mark the monster as defeated.
+
+Do not grant loot.
+
+The encounter ID must remain intact for Slice 0.3.
+
+---
+
+# 35. Loading states
+
+While starting or refreshing a hunt:
+
+- disable hunting action buttons
+- keep the current layout stable
+- show an in-world loading state
+
+Example:
+
+```text
+Du suchst nach Spuren...
+```
+
+Do not use browser alerts.
+
+Do not blank the entire application shell.
+
+---
+
+# 36. Error handling
+
+Errors must appear inside the Ashen Realms UI.
+
+Relevant errors include:
+
+```text
+HUNTING_NOT_AVAILABLE
+CHARACTER_TRAVELLING
+NO_HUNT_ENCOUNTERS_AVAILABLE
+NETWORK_ERROR
+```
+
+The player should have an appropriate retry action when possible.
+
+Example:
+
+```text
+Die Jagd konnte nicht gestartet werden.
+
+[ Erneut versuchen ]
+```
+
+---
+
+# 37. Frontend state
+
+Recommended state:
+
+```ts
+currentLocation
+currentHunt
+encounters
+loading
+error
+selectedEncounter
+```
+
+Use Angular signals if the existing world feature already uses signals.
+
+Do not introduce NgRx solely for this slice.
+
+Do not calculate random encounters in Angular.
+
+Do not calculate danger ratings in Angular.
+
+---
+
+# 38. API client
+
+Add a focused method to the existing typed API layer.
+
+Example:
+
+```ts
+startHunt(): Observable<HuntResponseDto>
+```
+
+Request:
+
+```http
+POST /api/hunts
+```
+
+with either:
+
+```ts
+{}
+```
+
+or no meaningful request payload.
+
+Do not send:
+
+```text
+characterId
+locationId
+monsterId
+dangerRating
+weights
+```
+
+from the client.
+
+---
+
+# 39. Database migration
+
+Create a TypeORM migration for:
+
+```text
+monster_definition
+location_monster
+hunt
+hunt_encounter
+```
+
+The migration must:
+
+- use UUID primary keys
+- create foreign keys
+- create required indexes
+- create unique key for MonsterDefinition.key
+- preserve existing world/travel data
+- not drop or recreate unrelated tables
+- not use `synchronize`
+
+Review generated SQL before accepting it.
+
+---
+
+# 40. Seed behavior
+
+Extend the existing idempotent seed.
+
+Seed:
+
+```text
+ash-rat
+road-bandit
+```
+
+Assign both to:
+
+```text
+burned-road
+```
+
+The seed must remain idempotent.
+
+Running it multiple times must:
+
+```text
+not duplicate monsters
+not duplicate location-monster relationships
+not reset character location
+not delete travel history
+not delete hunt history
+```
+
+If values change later, the seed may update definition fields.
+
+---
+
+# 41. Backend tests
+
+Implement tests before or alongside production code.
+
+At minimum cover:
+
+## Hunting availability
+
+```text
+reject hunt at south-gate
+```
+
+Expected:
+
+```text
+HUNTING_NOT_AVAILABLE
+```
+
+---
+
+## Valid hunt
+
+Character at:
+
+```text
+burned-road
+```
+
+Expected:
+
+```text
+hunt created
+2–3 encounters returned
+```
+
+---
+
+## Empty pool
+
+Location hunting enabled but no enabled monsters.
+
+Expected:
+
+```text
+NO_HUNT_ENCOUNTERS_AVAILABLE
+```
+
+---
+
+## Travelling character
+
+Character has an active travel.
+
+Expected:
+
+```text
+CHARACTER_TRAVELLING
+```
+
+---
+
+## Weighted random selection
+
+Inject deterministic random source.
+
+Given:
+
+```text
+ash-rat weight 70
+road-bandit weight 30
+```
+
+verify predictable selection for fixed random values.
+
+Do not write probabilistic flaky tests.
+
+---
+
+## Persistence
+
+Verify:
+
+```text
+Hunt is persisted
+HuntEncounter rows are persisted
+each encounter has unique ID
+monster relationship is correct
+```
+
+---
+
+## Refresh hunt
+
+Start first hunt.
+
+Start second hunt.
+
+Verify:
+
+```text
+first hunt = SUPERSEDED
+second hunt = ACTIVE
+```
+
+---
+
+# 42. Frontend tests
+
+At minimum cover:
+
+## Hunt page at unsupported location
+
+Given:
+
+```text
+south-gate
+```
+
+Expected:
+
+```text
+empty state
+no active hunt button
+link to map
+```
+
+---
+
+## Start hunt
+
+Click:
+
+```text
+Jagd beginnen
+```
+
+Verify:
+
+```text
+POST /api/hunts
+```
+
+is called.
+
+---
+
+## Encounter rendering
+
+Given API response with:
+
+```text
+Aschenratte
+Straßenräuber
+Aschenratte
+```
+
+verify:
+
+```text
+3 cards rendered
+names visible
+levels visible
+danger labels visible
+artwork paths used
+```
+
+---
+
+## Refresh
+
+Click:
+
+```text
+Neu suchen
+```
+
+Verify another:
+
+```text
+POST /api/hunts
+```
+
+occurs.
+
+---
+
+## Encounter selection
+
+Click:
+
+```text
+Angreifen
+```
+
+Verify only:
+
+```text
+HuntEncounter.id
+```
+
+is used for navigation / future combat handoff.
+
+The frontend must not send:
+
+```text
+monsterId
+damage
+monster HP
+loot request
+```
+
+---
+
+# 43. Visual requirements
+
+The hunt screen must follow the established Ashen Realms visual language:
+
+```text
+dark fantasy
+large illustrated content
+dark metal / stone panels
+thin bronze details
+restrained blue and gold accents
+serif display headings
+readable UI text
+```
+
+Avoid:
+
+```text
+white cards
+glassmorphism
+SaaS layout
+generic dashboard cards
+Material default styles
+Bootstrap look
+bright neon effects
+```
+
+The UI must feel like part of the same application as the world map.
+
+---
+
+# 44. Accessibility
+
+Encounter cards and actions must be keyboard accessible.
+
+Required:
+
+```text
+visible focus state
+real buttons
+readable danger text
+meaningful alt text for artwork where appropriate
+disabled state during loading
+```
+
+Do not encode danger only by color.
+
+Support:
+
+```css
+prefers-reduced-motion
+```
+
+for decorative motion.
+
+---
+
+# 45. Performance
+
+Do not preload unnecessary future gameplay systems.
+
+The hunt page should load only:
+
+```text
+current required state
+encounter artwork
+hunt API response
+```
+
+Reuse existing image-loading patterns.
+
+Avoid introducing large dependencies.
+
+---
+
+# 46. Server authority checklist
+
+The backend must decide:
+
+```text
+whether hunting is allowed
+which location is used
+which monsters are available
+which encounters are rolled
+how encounter weights work
+which danger rating is returned
+which HuntEncounter IDs exist
+```
+
+The frontend may decide only:
+
+```text
+when the player requests a hunt
+which returned encounter the player clicks
+```
+
+The frontend must never be authoritative over gameplay state.
+
+---
+
+# 47. Definition of Done
+
+Playable Slice 0.2 is complete when the following manual flow works:
+
+```text
+Start application
+↓
+Character is at Südtor
+↓
+Open Jagd
+↓
+UI explains that hunting is unavailable
+↓
+Open Karte
+↓
+Travel to Verbrannte Straße
+↓
+Server completes travel
+↓
+Open Jagd
+↓
+Click "Jagd beginnen"
+↓
+Server creates Hunt
+↓
+Server creates 2–3 HuntEncounter records
+↓
+Angular renders 2–3 large encounter cards
+↓
+Cards show monster artwork, name, level and danger
+↓
+Click "Neu suchen"
+↓
+New server-generated hunt appears
+↓
+Click "Angreifen" on one encounter
+↓
+The selected HuntEncounter.id is preserved for the next combat slice
+```
+
+---
+
+# 48. Required verification
+
+Before considering the slice complete, run:
+
+```text
+API unit tests
+API integration tests
+Angular tests
+API build
+Angular build
+TypeORM migration compilation
+seed execution
+```
+
+Perform a browser walkthrough at minimum for:
+
+```text
+Südtor → Jagd unavailable
+Südtor → Verbrannte Straße travel
+Verbrannte Straße → Jagd
+first hunt
+refresh hunt
+encounter selection
+```
+
+---
+
+# 49. Explicit implementation constraints
+
+Do not:
+
+```text
+implement combat
+implement loot
+implement inventory
+implement equipment
+implement XP progression
+add authentication
+add quests
+add shops
+add WebSockets
+add background jobs
+add microservices
+add Redis
+add CQRS
+add event sourcing
+add NgRx
+hardcode monster arrays in Angular
+trust client location IDs
+trust client monster IDs
+calculate encounters client-side
+calculate danger client-side
+```
+
+Keep the implementation intentionally small.
+
+---
+
+# 50. Expected repository additions
+
+Likely backend additions:
+
+```text
+apps/api/src/monsters/
+apps/api/src/hunting/
+apps/api/src/database/migrations/
+apps/api/src/database/seeds/
+```
+
+Likely frontend additions:
+
+```text
+apps/web/src/app/features/hunting/
+```
+
+Reuse existing:
+
+```text
+API client
+application shell
+design tokens
+world state where sensible
+shared components
+error presentation
+loading presentation
+```
+
+Do not duplicate working infrastructure.
+
+---
+
+# 51. Acceptance criteria
+
+The implementation is accepted when:
+
+- `Verbrannte Straße` supports hunting
+- `Südtor` does not
+- hunting uses server-authoritative current location
+- encounter pools come from PostgreSQL content data
+- Aschenratte and Straßenräuber are seeded
+- 2–3 encounters are generated server-side
+- weighted selection is testable deterministically
+- Hunt and HuntEncounter are persisted
+- refreshing creates a new hunt
+- old hunt is no longer active
+- Angular renders large visual encounter cards
+- danger rating is server-provided
+- the hunt page matches the existing Ashen Realms design
+- the client cannot freely choose arbitrary monster IDs
+- clicking Angreifen preserves only the returned HuntEncounter ID
+- no combat, loot or inventory system is implemented prematurely
+- all relevant tests pass
+- API and frontend builds succeed
+
+---
+
+# 52. Next slice
+
+After this slice is fully working, continue with:
+
+```text
+Playable Slice 0.3 – First Combat
+```
+
+That slice will begin from:
+
+```text
+HuntEncounter.id
+```
+
+and implement:
+
+```text
+Encounter
+→ Combat creation
+→ player vs monster screen
+→ turn-based actions
+→ deterministic server-side combat
+→ victory / defeat
+```
+
+Do not begin Slice 0.3 until Slice 0.2 is fully verified.
\ No newline at end of file
diff --git a/docs/playable-slices/Ashen Realms – Playable Slice 0.3_ First Combat.md b/docs/playable-slices/Ashen Realms – Playable Slice 0.3_ First Combat.md
new file mode 100644
index 0000000..446a047
--- /dev/null
+++ b/docs/playable-slices/Ashen Realms – Playable Slice 0.3_ First Combat.md	
@@ -0,0 +1,1918 @@
+# Ashen Realms – Playable Slice 0.3: First Combat
+
+**Status:** Ready for implementation  
+**Prerequisite:** Playable Slice 0.2 – First Hunt  
+**Scope:** First persistent, server-authoritative combat  
+**Primary Enemies:** Aschenratte, Straßenräuber  
+**Next Slice:** Playable Slice 0.4 – First Loot
+
+---
+
+# 1. Goal
+
+Playable Slice 0.3 implements the first real combat in Ashen Realms.
+
+The existing flow:
+
+```text
+World
+→ Travel
+→ Hunt
+→ Encounter selection
+```
+
+is extended to:
+
+```text
+World
+→ Travel
+→ Hunt
+→ Encounter selection
+→ Combat
+→ Victory or defeat
+```
+
+The slice must prove that:
+
+- combat can only start from a valid `HuntEncounter`
+- combat state is persisted on the server
+- the client sends decisions, never results
+- combat resolution is deterministic
+- player and monster HP are server-authoritative
+- combat proceeds round by round
+- combat events can drive frontend presentation
+- victory and defeat are persisted
+- refreshing the browser does not lose the fight
+
+This slice deliberately ends when the combat reaches:
+
+```text
+WON
+```
+
+or:
+
+```text
+LOST
+```
+
+No rewards are granted yet.
+
+---
+
+# 2. Core player flow
+
+```text
+Verbrannte Straße
+↓
+Jagd beginnen
+↓
+Encounter auswählen
+↓
+Angreifen
+↓
+Server validates HuntEncounter
+↓
+Combat created
+↓
+/combat/:combatId
+↓
+Player and monster are displayed
+↓
+Player chooses Angriff
+↓
+Server resolves round
+↓
+CombatEvents returned
+↓
+Frontend updates HP and combat log
+↓
+next round
+↓
+monster reaches 0 HP
+↓
+Combat = WON
+```
+
+Defeat must also work:
+
+```text
+player reaches 0 HP
+↓
+Combat = LOST
+```
+
+---
+
+# 3. Scope
+
+Implement:
+
+```text
+Combat entity
+CombatEvent entity
+CombatEngineService
+CombatService
+CombatController
+
+combat creation from HuntEncounter
+
+ATTACK player action
+
+basic monster attack
+
+server-side damage calculation
+
+round progression
+
+player HP
+
+monster HP
+
+combat status
+
+combat event persistence
+
+combat page
+
+player presentation
+
+monster presentation
+
+HP bars
+
+Angriff action
+
+round display
+
+combat log
+
+victory state
+
+defeat state
+```
+
+---
+
+# 4. Explicit non-goals
+
+Do not implement:
+
+```text
+loot
+XP granting
+silver granting
+inventory
+equipment management
+item drops
+quests
+bosses
+elites
+sets
+area currencies
+random combat rewards
+combat animations requiring complex timing
+WebSockets
+PvP
+multiplayer combat
+```
+
+Also do not implement the complete final action system yet.
+
+The first playable combat uses only:
+
+```text
+ATTACK
+```
+
+for player input.
+
+Future slices may add:
+
+```text
+HEAVY_STRIKE
+SHIELD_BASH
+DEFEND
+POTION
+FLEE
+```
+
+The combat architecture must allow these later without implementing them prematurely.
+
+---
+
+# 5. Combat design principle
+
+Combat is turn-based.
+
+The player makes exactly one primary decision per round.
+
+For Slice 0.3:
+
+```text
+Player chooses ATTACK
+↓
+player attack resolves
+↓
+if monster survives:
+    monster attack resolves
+↓
+round ends
+```
+
+The next round begins only after the server has resolved the previous round.
+
+Angular must never independently resolve a combat round.
+
+---
+
+# 6. Combat start boundary
+
+A combat may only be created from:
+
+```text
+HuntEncounter.id
+```
+
+Never from:
+
+```text
+MonsterDefinition.id
+```
+
+directly supplied by the frontend.
+
+Required endpoint:
+
+```http
+POST /api/hunt-encounters/:encounterId/attack
+```
+
+The backend must validate:
+
+```text
+HuntEncounter exists
+↓
+encounter belongs to current character's Hunt
+↓
+Hunt belongs to current character
+↓
+Hunt is valid/current
+↓
+encounter has not already been consumed
+↓
+character is not travelling
+↓
+character does not already have another ACTIVE combat
+```
+
+Only then may combat be created.
+
+---
+
+# 7. Encounter consumption
+
+A HuntEncounter must not be usable repeatedly to create unlimited combats.
+
+Introduce an appropriate state or relation.
+
+Possible states:
+
+```text
+AVAILABLE
+SELECTED
+CONSUMED
+```
+
+For this slice it is sufficient if the selected encounter becomes:
+
+```text
+CONSUMED
+```
+
+when combat is successfully created.
+
+The exact persistence model may follow existing project conventions.
+
+The important invariant is:
+
+> One HuntEncounter may create at most one Combat.
+
+Prefer protecting this through both service validation and a database uniqueness constraint where practical.
+
+---
+
+# 8. Combat entity
+
+Create:
+
+```text
+apps/api/src/combat/entities/combat.entity.ts
+```
+
+Required conceptual fields:
+
+```ts
+id: uuid;
+
+characterId: uuid;
+huntEncounterId: uuid;
+monsterDefinitionId: uuid;
+
+status: CombatStatus;
+
+round: number;
+
+playerMaxHp: number;
+playerCurrentHp: number;
+
+monsterMaxHp: number;
+monsterCurrentHp: number;
+
+playerState: jsonb;
+monsterState: jsonb;
+
+createdAt: timestamptz;
+updatedAt: timestamptz;
+completedAt?: timestamptz;
+```
+
+Supported statuses:
+
+```text
+ACTIVE
+WON
+LOST
+```
+
+Do not add reward-related states yet.
+
+---
+
+# 9. Combat snapshot principle
+
+Combat must snapshot the relevant stats at combat creation.
+
+A running combat must not unexpectedly change because content definitions or character state are edited elsewhere.
+
+The combat snapshot should contain enough information to reproduce its deterministic calculations.
+
+Conceptually:
+
+```ts
+playerState = {
+  attack: number,
+  weaponDamage: number,
+  armor: number
+}
+
+monsterState = {
+  attack: number,
+  armor: number
+}
+```
+
+The exact JSON structure may be strongly typed in TypeScript.
+
+Avoid unstructured arbitrary JSON access throughout the engine.
+
+---
+
+# 10. Player stats for the first combat
+
+The final game uses effective character values derived from:
+
+```text
+base character stats
++
+equipment
+```
+
+For the first combat slice, reuse `CharacterStatsService` if it already exists.
+
+If equipment has not yet been implemented, do not implement the entire inventory/equipment system solely for Slice 0.3.
+
+The demo character starts conceptually with:
+
+```text
+100 HP
+6 base attack
+8 weapon damage
+6 armor
+```
+
+These correspond to the established starting reference character.
+
+Any temporary mechanism needed to supply the starting weapon/armor values must:
+
+- remain server-side
+- be isolated behind the character/combat stats boundary
+- not leak into Angular
+- be easy to replace when Slice 0.5 introduces real equipment
+- not change the public combat API
+
+Do not create fake frontend equipment state.
+
+---
+
+# 11. Damage formula
+
+Use the established Ashen Realms damage model.
+
+Raw damage:
+
+```text
+Raw Damage =
+Weapon Damage + Attack
+```
+
+Armor mitigation:
+
+```text
+Damage =
+Raw Damage × 60 / (60 + Armor)
+```
+
+Round to the nearest integer.
+
+Minimum damage:
+
+```text
+1
+```
+
+Conceptual implementation:
+
+```ts
+const rawDamage =
+  attack + weaponDamage;
+
+const mitigatedDamage =
+  rawDamage * 60 / (60 + targetArmor);
+
+return Math.max(
+  1,
+  Math.round(mitigatedDamage),
+);
+```
+
+For monsters without explicit weapon damage, their `attack` may represent their complete offensive base value for this first slice.
+
+Keep this distinction explicit in engine types.
+
+---
+
+# 12. No combat randomness
+
+Slice 0.3 combat contains no random damage range.
+
+Do not implement:
+
+```text
+critical hits
+dodge
+block chance
+accuracy
+hit chance
+random damage variance
+elemental damage
+resistances
+```
+
+Given the same combat state and action:
+
+> the same result must be produced.
+
+This is intentional.
+
+---
+
+# 13. CombatEngineService
+
+Create a framework-light engine:
+
+```text
+apps/api/src/combat/combat-engine.service.ts
+```
+
+The engine should not directly access PostgreSQL.
+
+Required conceptual API:
+
+```ts
+resolveAction(
+  state: CombatEngineState,
+  action: CombatActionInput,
+): CombatEngineResult
+```
+
+The engine receives:
+
+```text
+current round
+player stats/state
+monster stats/state
+requested player action
+```
+
+and returns:
+
+```text
+new combat state
+events
+status/result
+```
+
+The engine must be unit-testable without Nest repositories.
+
+---
+
+# 14. Combat action enum
+
+Introduce:
+
+```text
+ATTACK
+```
+
+as a real enum/API value.
+
+Design the enum so future values can be added:
+
+```text
+HEAVY_STRIKE
+SHIELD_BASH
+DEFEND
+POTION
+FLEE
+```
+
+But do not implement their behavior in Slice 0.3.
+
+If an unsupported action is submitted, return a domain validation error.
+
+---
+
+# 15. Round resolution
+
+For:
+
+```text
+ATTACK
+```
+
+resolve:
+
+## Step 1 – Player attack
+
+Calculate damage against monster armor.
+
+Reduce:
+
+```text
+monsterCurrentHp
+```
+
+but never below:
+
+```text
+0
+```
+
+Create a combat event.
+
+---
+
+## Step 2 – Victory check
+
+If:
+
+```text
+monsterCurrentHp <= 0
+```
+
+then:
+
+```text
+status = WON
+```
+
+The monster must not receive another attack.
+
+The round ends.
+
+---
+
+## Step 3 – Monster attack
+
+If the monster survived:
+
+Calculate monster damage against player armor.
+
+Reduce:
+
+```text
+playerCurrentHp
+```
+
+but never below:
+
+```text
+0
+```
+
+Create a combat event.
+
+---
+
+## Step 4 – Defeat check
+
+If:
+
+```text
+playerCurrentHp <= 0
+```
+
+then:
+
+```text
+status = LOST
+```
+
+---
+
+## Step 5 – Round progression
+
+If combat remains active:
+
+```text
+round += 1
+```
+
+Use one consistent round-number convention throughout API, persistence and UI.
+
+Recommended:
+
+```text
+Combat starts at round 1.
+After resolving round 1 successfully:
+round becomes 2.
+```
+
+---
+
+# 16. CombatEvent entity
+
+Create:
+
+```text
+apps/api/src/combat/entities/combat-event.entity.ts
+```
+
+Fields should support ordered event history.
+
+Conceptually:
+
+```ts
+id: uuid;
+
+combatId: uuid;
+
+round: number;
+sequence: number;
+
+type: CombatEventType;
+
+source: PLAYER | MONSTER;
+target: PLAYER | MONSTER;
+
+amount?: number;
+
+createdAt: timestamptz;
+```
+
+Initial event types should include:
+
+```text
+DAMAGE
+COMBAT_WON
+COMBAT_LOST
+```
+
+Avoid storing presentation sentences as the authoritative event format.
+
+Store structured events.
+
+Angular may transform them into German display text.
+
+---
+
+# 17. Example events
+
+Player attacks Aschenratte:
+
+```json
+{
+  "type": "DAMAGE",
+  "source": "PLAYER",
+  "target": "MONSTER",
+  "amount": 14
+}
+```
+
+Monster attacks player:
+
+```json
+{
+  "type": "DAMAGE",
+  "source": "MONSTER",
+  "target": "PLAYER",
+  "amount": 5
+}
+```
+
+Combat victory:
+
+```json
+{
+  "type": "COMBAT_WON",
+  "source": "PLAYER",
+  "target": "MONSTER"
+}
+```
+
+---
+
+# 18. Combat creation transaction
+
+Creating combat should be atomic.
+
+Conceptual transaction:
+
+```text
+lock/validate HuntEncounter
+↓
+verify no active combat
+↓
+load monster
+↓
+calculate/snapshot player stats
+↓
+create Combat
+↓
+consume HuntEncounter
+↓
+commit
+```
+
+Concurrent requests for the same encounter must not create two combats.
+
+---
+
+# 19. CombatService
+
+`CombatService` owns persistence and orchestration.
+
+Responsibilities:
+
+```text
+create combat from encounter
+
+load combat
+
+validate combat ownership/state
+
+call CombatEngineService
+
+persist updated HP/state
+
+persist ordered CombatEvents
+
+persist WON/LOST status
+
+return combat DTO
+```
+
+Do not put damage formulas into the controller.
+
+Do not put TypeORM repository access into the pure combat engine.
+
+---
+
+# 20. Combat API
+
+Required endpoints:
+
+```http
+POST /api/hunt-encounters/:encounterId/attack
+
+GET /api/combats/:combatId
+
+POST /api/combats/:combatId/actions
+```
+
+---
+
+# 21. Start combat request
+
+Example:
+
+```http
+POST /api/hunt-encounters/abc123/attack
+```
+
+No body containing combat values is required.
+
+The server derives:
+
+```text
+character
+monster
+player stats
+monster stats
+starting HP
+```
+
+Response should return the newly created combat.
+
+---
+
+# 22. Combat action request
+
+Request:
+
+```json
+{
+  "action": "ATTACK"
+}
+```
+
+The frontend must never send:
+
+```text
+damage
+playerHp
+monsterHp
+armor
+attack
+weaponDamage
+round
+combat status
+```
+
+These values are entirely server-owned.
+
+---
+
+# 23. Combat response DTO
+
+Conceptually:
+
+```json
+{
+  "id": "combat-uuid",
+  "status": "ACTIVE",
+  "round": 2,
+
+  "player": {
+    "name": "Aric Duskwalker",
+    "maxHp": 100,
+    "currentHp": 95
+  },
+
+  "monster": {
+    "key": "ash-rat",
+    "name": "Aschenratte",
+    "level": 1,
+    "maxHp": 45,
+    "currentHp": 31,
+    "artworkPath": "/assets/monsters/ash-rat.webp"
+  },
+
+  "events": [
+    {
+      "round": 1,
+      "sequence": 1,
+      "type": "DAMAGE",
+      "source": "PLAYER",
+      "target": "MONSTER",
+      "amount": 14
+    },
+    {
+      "round": 1,
+      "sequence": 2,
+      "type": "DAMAGE",
+      "source": "MONSTER",
+      "target": "PLAYER",
+      "amount": 5
+    }
+  ]
+}
+```
+
+Do not expose unnecessary internal engine state.
+
+---
+
+# 24. GET combat
+
+`GET /api/combats/:combatId` must allow the browser to restore the fight after:
+
+```text
+refresh
+route reload
+browser reconnect
+```
+
+The frontend must not depend on transient local state for current HP or round.
+
+The server response remains authoritative.
+
+---
+
+# 25. Finished combat behavior
+
+If combat status is:
+
+```text
+WON
+```
+
+or:
+
+```text
+LOST
+```
+
+then further calls to:
+
+```http
+POST /api/combats/:combatId/actions
+```
+
+must be rejected.
+
+Example error:
+
+```json
+{
+  "statusCode": 409,
+  "code": "COMBAT_ALREADY_FINISHED",
+  "message": "This combat has already finished."
+}
+```
+
+---
+
+# 26. Active combat restriction
+
+A character may have at most one:
+
+```text
+ACTIVE
+```
+
+combat.
+
+Starting another encounter while a combat is active must fail.
+
+Example:
+
+```text
+COMBAT_ALREADY_ACTIVE
+```
+
+Where practical, protect this invariant using a partial unique database index in addition to service validation.
+
+---
+
+# 27. Invalid encounter errors
+
+Use stable domain errors.
+
+Examples:
+
+```text
+HUNT_ENCOUNTER_NOT_FOUND
+HUNT_ENCOUNTER_ALREADY_CONSUMED
+INVALID_HUNT_ENCOUNTER
+CHARACTER_TRAVELLING
+COMBAT_ALREADY_ACTIVE
+```
+
+Do not expose raw TypeORM/PostgreSQL errors to the client.
+
+---
+
+# 28. Database migration
+
+Create a reviewed TypeORM migration for:
+
+```text
+combat
+combat_event
+```
+
+and any required HuntEncounter state/constraint changes.
+
+The migration must:
+
+- preserve existing world/travel/hunting data
+- use UUID primary keys
+- create foreign keys
+- create useful indexes
+- prevent obvious duplicate active-combat states where practical
+- not recreate unrelated tables
+- keep `synchronize` disabled
+
+---
+
+# 29. Angular route
+
+Implement:
+
+```text
+/combat/:combatId
+```
+
+The Hunt screen's:
+
+```text
+Angreifen
+```
+
+action changes from the Slice 0.2 placeholder to:
+
+```text
+POST combat from encounter
+↓
+receive combat ID
+↓
+navigate to /combat/:combatId
+```
+
+Remove the temporary combat placeholder from Slice 0.2.
+
+---
+
+# 30. Combat screen composition
+
+The combat screen follows the established Ashen Realms layout:
+
+```text
+player left
+monster right
+location background
+combat actions below
+combat information clearly visible
+combat log in contextual area/right side
+```
+
+The fight must visually feel like a confrontation.
+
+Do not render combat as a statistics table.
+
+---
+
+# 31. Player presentation
+
+Display:
+
+```text
+character artwork
+character name
+current HP
+maximum HP
+HP bar
+```
+
+Use existing player artwork.
+
+Do not introduce a new art style.
+
+---
+
+# 32. Monster presentation
+
+Display:
+
+```text
+monster artwork
+monster name
+monster level
+current HP
+maximum HP
+HP bar
+```
+
+Use the artwork path supplied by the API/content definition.
+
+The monster should receive similar visual weight to the player.
+
+---
+
+# 33. Background
+
+Use the current combat location:
+
+```text
+Verbrannte Straße
+```
+
+as the scene context.
+
+Reuse the existing location artwork where appropriate.
+
+The background must support the confrontation rather than compete with HP/action readability.
+
+---
+
+# 34. Combat action bar
+
+Slice 0.3 shows one functional action:
+
+```text
+Angriff
+```
+
+The action should be implemented using the visual language intended for future combat buttons.
+
+Recommended display:
+
+```text
+icon
+Angriff
+optional hotkey
+```
+
+Do not show fake functional buttons for unimplemented mechanics.
+
+It is acceptable to reserve visual space for future actions, but disabled placeholders should only be used if they improve layout validation.
+
+---
+
+# 35. Input locking
+
+When an action request is in progress:
+
+```text
+disable combat actions
+```
+
+The player must not accidentally submit the same round multiple times.
+
+The backend must still protect against concurrency.
+
+Frontend locking is only UX protection.
+
+Server validation remains authoritative.
+
+---
+
+# 36. Combat log
+
+Display structured events as readable German log entries.
+
+Example:
+
+```text
+Runde 1
+
+Aric trifft Aschenratte für 14 Schaden.
+Aschenratte trifft Aric für 5 Schaden.
+```
+
+Do not persist these sentences as domain truth.
+
+Build them from structured `CombatEventDto` objects.
+
+---
+
+# 37. Round display
+
+Clearly show:
+
+```text
+Runde 1
+Runde 2
+...
+```
+
+Round state must come from the API.
+
+Angular must never independently increment the authoritative round value.
+
+---
+
+# 38. Victory state
+
+When:
+
+```text
+status = WON
+```
+
+show a clear victory state.
+
+Example:
+
+```text
+Sieg
+
+Die Aschenratte wurde besiegt.
+```
+
+At this point Slice 0.3 ends.
+
+Do not grant or invent rewards.
+
+A small deliberate message may indicate:
+
+```text
+Belohnungen werden im nächsten Schritt verarbeitet.
+```
+
+Primary action may be:
+
+```text
+Zur Jagd
+```
+
+Do not automatically create another hunt.
+
+---
+
+# 39. Defeat state
+
+When:
+
+```text
+status = LOST
+```
+
+show a clear defeat state.
+
+Example:
+
+```text
+Niederlage
+
+Aric wurde im Kampf besiegt.
+```
+
+For Slice 0.3, do not build the complete long-term defeat/reset system unless it already exists.
+
+The combat must remain persisted as:
+
+```text
+LOST
+```
+
+A simple return action to the world/hunt context is sufficient for this slice.
+
+Any final safe-location reset should be defined in a later dedicated slice unless already implemented.
+
+---
+
+# 40. Refresh/recovery behavior
+
+Refreshing:
+
+```text
+/combat/:combatId
+```
+
+must reload combat from the server.
+
+The UI must restore:
+
+```text
+combat status
+round
+player HP
+monster HP
+monster
+combat history
+```
+
+No combat-critical state may exist only in Angular memory.
+
+---
+
+# 41. Frontend state
+
+Recommended state:
+
+```ts
+combat
+loading
+actionPending
+error
+```
+
+Derived presentation state may include:
+
+```text
+player hp percentage
+monster hp percentage
+formatted combat events
+```
+
+Do not duplicate authoritative gameplay values in mutable frontend state.
+
+---
+
+# 42. Combat API service
+
+Add focused methods equivalent to:
+
+```ts
+startCombat(
+  encounterId: string,
+): Observable<CombatDto>
+
+getCombat(
+  combatId: string,
+): Observable<CombatDto>
+
+performAction(
+  combatId: string,
+  action: CombatAction,
+): Observable<CombatDto>
+```
+
+Only send the action enum for combat actions.
+
+---
+
+# 43. CombatEngine unit tests
+
+At minimum cover:
+
+## Damage formula
+
+Example established case:
+
+```text
+attack = 12
+weaponDamage = 15
+target armor = 20
+```
+
+Expected:
+
+```text
+20 damage
+```
+
+---
+
+## Minimum damage
+
+Extremely high armor must still result in:
+
+```text
+1 damage minimum
+```
+
+---
+
+## Player attack
+
+Verify:
+
+```text
+monster HP decreases correctly
+DAMAGE event created
+```
+
+---
+
+## Monster retaliation
+
+If the monster survives:
+
+```text
+player HP decreases
+monster DAMAGE event created
+```
+
+---
+
+## No retaliation after death
+
+If player attack reduces monster to zero:
+
+```text
+monster does not attack
+combat = WON
+```
+
+---
+
+## Defeat
+
+If monster attack reduces player to zero:
+
+```text
+combat = LOST
+```
+
+---
+
+## Determinism
+
+The same state plus:
+
+```text
+ATTACK
+```
+
+must produce the same result.
+
+---
+
+# 44. CombatService tests
+
+At minimum cover:
+
+## Valid encounter starts combat
+
+```text
+available HuntEncounter
+→ ACTIVE Combat
+```
+
+---
+
+## Arbitrary monster cannot start combat
+
+There must be no public API accepting an arbitrary monster definition as the combat source.
+
+---
+
+## Encounter can only be consumed once
+
+Two attempts using the same encounter must not produce two combats.
+
+---
+
+## Active combat restriction
+
+Character with an ACTIVE combat cannot create another.
+
+---
+
+## Persistence
+
+After an action:
+
+```text
+HP changes persisted
+round persisted
+CombatEvents persisted
+```
+
+---
+
+## Finished combat
+
+Further actions after:
+
+```text
+WON
+```
+
+or:
+
+```text
+LOST
+```
+
+must fail.
+
+---
+
+## Transaction/concurrency
+
+Where feasible, verify concurrent or repeated requests cannot resolve the same combat round twice.
+
+---
+
+# 45. Frontend tests
+
+At minimum cover:
+
+## Combat creation
+
+Clicking:
+
+```text
+Angreifen
+```
+
+on the Hunt page:
+
+```text
+uses HuntEncounter.id
+calls combat creation
+navigates to /combat/:combatId
+```
+
+---
+
+## Combat load
+
+Opening:
+
+```text
+/combat/:combatId
+```
+
+loads the authoritative combat state.
+
+---
+
+## Combat presentation
+
+Verify visibility of:
+
+```text
+player
+monster
+both HP bars
+round
+Angriff
+combat log
+```
+
+---
+
+## Combat action
+
+Click:
+
+```text
+Angriff
+```
+
+and verify the frontend sends only:
+
+```json
+{
+  "action": "ATTACK"
+}
+```
+
+---
+
+## Action lock
+
+While the action request is unresolved:
+
+```text
+Angriff disabled
+```
+
+---
+
+## Event rendering
+
+Structured DAMAGE events are rendered as readable combat-log entries.
+
+---
+
+## Victory
+
+When API returns:
+
+```text
+WON
+```
+
+the UI shows victory and disables combat actions.
+
+---
+
+## Defeat
+
+When API returns:
+
+```text
+LOST
+```
+
+the UI shows defeat and disables combat actions.
+
+---
+
+# 46. Visual requirements
+
+Follow the existing Ashen Realms visual design.
+
+Combat should emphasize:
+
+```text
+large character artwork
+large monster artwork
+dark fantasy location background
+clear HP bars
+clear action area
+strong confrontation
+dark metal/stone panels
+bronze detail
+restrained functional colors
+```
+
+Do not use:
+
+```text
+generic cards
+SaaS dashboard layout
+white panels
+Material defaults
+Bootstrap defaults
+glassmorphism
+neon-heavy effects
+```
+
+---
+
+# 47. Animation scope
+
+Simple presentation effects are allowed:
+
+```text
+small hit reaction
+short damage number
+subtle impact animation
+HP-bar transition
+```
+
+But animations must be driven from server-returned events.
+
+Do not delay or alter authoritative combat resolution for presentation.
+
+Do not introduce a complex combat animation queue unless the existing frontend architecture already supports one cleanly.
+
+Respect:
+
+```css
+prefers-reduced-motion
+```
+
+---
+
+# 48. Server-authority checklist
+
+Server decides:
+
+```text
+whether combat can start
+which monster belongs to encounter
+combat starting stats
+player HP
+monster HP
+damage
+round progression
+monster retaliation
+victory
+defeat
+combat status
+combat events
+```
+
+Client decides only:
+
+```text
+which valid HuntEncounter to attack
+when to submit ATTACK during an active combat
+```
+
+---
+
+# 49. Security/domain constraints
+
+The client must never be able to submit:
+
+```text
+monsterId
+damage
+target HP
+player HP
+armor
+attack
+weapon damage
+victory
+defeat
+reward
+round number
+```
+
+as authoritative combat inputs.
+
+Do not trust disabled frontend buttons as domain validation.
+
+Every action must be validated server-side.
+
+---
+
+# 50. Definition of Done
+
+Playable Slice 0.3 is complete when this complete browser flow works:
+
+```text
+Südtor
+↓
+travel to Verbrannte Straße
+↓
+Jagd
+↓
+Jagd beginnen
+↓
+select Aschenratte or Straßenräuber
+↓
+Angreifen
+↓
+server creates Combat from HuntEncounter
+↓
+navigate to /combat/:combatId
+↓
+player and monster appear
+↓
+both HP bars visible
+↓
+Runde 1 visible
+↓
+player clicks Angriff
+↓
+server resolves complete round
+↓
+combat events appear
+↓
+HP changes
+↓
+continue attacking
+↓
+combat reaches WON or LOST
+↓
+finished state displayed
+```
+
+---
+
+# 51. Required verification
+
+Before considering the slice complete, run all relevant:
+
+```text
+API unit tests
+API integration tests
+Angular tests
+API build
+Angular build
+migration compilation
+migration execution
+seed verification
+```
+
+Perform browser walkthroughs for at least:
+
+```text
+Aschenratte combat
+Straßenräuber combat
+victory
+defeat or deterministic forced-loss test setup
+browser refresh during ACTIVE combat
+browser refresh after finished combat
+reusing consumed HuntEncounter
+attempting second combat while one is ACTIVE
+```
+
+---
+
+# 52. Acceptance criteria
+
+The implementation is accepted when:
+
+- Combat starts only from persisted HuntEncounter IDs
+- one encounter cannot create multiple combats
+- one character cannot have multiple active combats
+- combat state is stored in PostgreSQL
+- player and monster HP are server-owned
+- ATTACK is resolved server-side
+- damage follows the defined formula
+- minimum damage is 1
+- monster attacks only if still alive
+- combat progresses round by round
+- CombatEvents are persisted
+- events are ordered
+- combat can reach WON
+- combat can reach LOST
+- finished combat rejects further actions
+- page refresh restores combat state
+- Angular never calculates authoritative damage
+- Angular displays player and monster visually
+- HP bars, round and combat log work
+- combat visually matches the existing Ashen Realms UI
+- no rewards are granted yet
+- all relevant tests pass
+- frontend and backend builds succeed
+
+---
+
+# 53. Handoff to Playable Slice 0.4
+
+The exact output boundary of this slice is:
+
+```text
+Combat.status = WON
+```
+
+with a persisted finished combat.
+
+Playable Slice 0.4 will begin from that state and implement:
+
+```text
+WON Combat
+↓
+reward resolution
+↓
+XP
+↓
+silver
+↓
+loot roll
+↓
+reward persistence
+↓
+loot summary
+```
+
+The combat system must therefore finish a fight cleanly without granting rewards itself.
+
+Reward calculation belongs to the next slice.
+
+---
+
+# 54. Architectural boundary
+
+The final separation should be:
+
+```text
+HuntingService
+    ↓
+valid HuntEncounter
+
+CombatService
+    ↓
+persistent combat orchestration
+
+CombatEngineService
+    ↓
+pure deterministic round resolution
+
+Slice 0.4
+    ↓
+reward / loot processing
+```
+
+Do not let these responsibilities collapse into a single service.
+
+The combat engine resolves combat.
+
+It does not know about:
+
+```text
+TypeORM
+loot tables
+inventory
+XP progression
+shops
+quests
+Angular
+```
+
+---
+
+# 55. Summary
+
+Playable Slice 0.3 proves the second major gameplay pillar of Ashen Realms:
+
+> **A server-generated encounter becomes a real visual, deterministic, persistent turn-based fight.**
+
+The player can now:
+
+```text
+travel
+→ hunt
+→ choose an enemy
+→ fight
+→ win or lose
+```
+
+The next slice adds the reason to keep doing it:
+
+```text
+loot and progression
+```
\ No newline at end of file
diff --git a/docs/playable-slices/Ashen Realms – Playable Slice 0.4_ First Loot.md b/docs/playable-slices/Ashen Realms – Playable Slice 0.4_ First Loot.md
new file mode 100644
index 0000000..7d1675f
--- /dev/null
+++ b/docs/playable-slices/Ashen Realms – Playable Slice 0.4_ First Loot.md	
@@ -0,0 +1,1641 @@
+# Ashen Realms – Playable Slice 0.4: First Loot
+
+**Status:** Ready for implementation  
+**Prerequisite:** Playable Slice 0.3 – First Combat  
+**Scope:** First server-authoritative reward and loot flow  
+**Primary Enemies:** Aschenratte, Straßenräuber  
+**Next Slice:** Playable Slice 0.5 – First Upgrade
+
+---
+
+# 1. Goal
+
+Playable Slice 0.4 extends the existing gameplay loop:
+
+```text
+World
+→ Travel
+→ Hunt
+→ Encounter
+→ Combat
+→ Victory
+```
+
+to:
+
+```text
+World
+→ Travel
+→ Hunt
+→ Encounter
+→ Combat
+→ Victory
+→ XP
+→ Silver
+→ Loot
+→ Reward Summary
+```
+
+This slice must prove that:
+
+- rewards are generated only by the backend
+- rewards originate only from a valid won combat
+- each combat can grant rewards at most once
+- XP and silver are persisted
+- loot is rolled server-side
+- item rewards are persisted
+- loot generation is deterministic in tests
+- the frontend only presents server-generated rewards
+- refreshing the result screen does not reroll loot
+
+This slice deliberately stops before equipment management.
+
+The next slice will implement:
+
+```text
+Playable Slice 0.5 – First Upgrade
+
+Loot
+→ Inventory
+→ compare item
+→ equip item
+→ effective stats increase
+```
+
+---
+
+# 2. Core player flow
+
+The intended flow is:
+
+```text
+Verbrannte Straße
+↓
+Jagd beginnen
+↓
+choose encounter
+↓
+combat
+↓
+monster reaches 0 HP
+↓
+Combat = WON
+↓
+server resolves rewards
+↓
+XP granted
+↓
+silver granted
+↓
+loot table rolled
+↓
+reward persisted
+↓
+frontend shows reward summary
+```
+
+Example:
+
+```text
+Sieg
+
+Aschenratte besiegt
+
++8 XP
++6 Silber
+
+Beute:
+Aschenfell
+```
+
+or:
+
+```text
+Sieg
+
+Straßenräuber besiegt
+
++16 XP
++12 Silber
+
+Beute:
+Räuberklinge
+```
+
+---
+
+# 3. Scope
+
+Implement:
+
+```text
+persistent character XP
+persistent character silver
+
+ItemDefinition where needed
+CharacterItem minimal inventory persistence
+
+LootTable
+LootTableEntry
+
+LootService
+Reward/CombatReward persistence
+
+server-side silver roll
+server-side loot roll
+
+reward resolution after won combat
+
+reward idempotency
+
+reward summary API data
+
+victory reward presentation
+```
+
+---
+
+# 4. Explicit non-goals
+
+Do not implement:
+
+```text
+equipment
+equip/unequip actions
+effective equipment stats
+item comparison UI
+full inventory management
+24-slot inventory restrictions
+selling items
+merchants
+area currencies
+sets
+boss guaranteed loot
+pity systems
+crafting
+item upgrades
+random affixes
+quest rewards
+```
+
+Slice 0.4 is about obtaining rewards.
+
+Slice 0.5 is about using equipment.
+
+---
+
+# 5. Reward ownership
+
+Rewards are entirely server-authoritative.
+
+The backend decides:
+
+```text
+whether the combat qualifies for rewards
+XP amount
+silver amount
+loot rolls
+item definitions
+item quantities
+whether rewards were already granted
+```
+
+The frontend must never submit:
+
+```text
+XP
+silver
+itemId
+drop result
+drop chance
+loot-table result
+reward quantity
+```
+
+as authoritative data.
+
+---
+
+# 6. Reward source
+
+Rewards may only originate from a Combat with:
+
+```text
+status = WON
+```
+
+A combat with:
+
+```text
+ACTIVE
+```
+
+or:
+
+```text
+LOST
+```
+
+must never grant normal victory rewards.
+
+---
+
+# 7. Reward idempotency
+
+A won combat may grant rewards exactly once.
+
+This is a critical invariant.
+
+The following must never happen:
+
+```text
+win combat
+↓
+receive loot
+↓
+refresh browser
+↓
+receive loot again
+```
+
+or:
+
+```text
+repeat reward endpoint
+↓
+farm duplicate rewards from one combat
+```
+
+Protect this using persistent reward state and a database uniqueness constraint where practical.
+
+---
+
+# 8. Recommended reward persistence
+
+Introduce a persisted reward record.
+
+Conceptually:
+
+```text
+CombatReward
+```
+
+Required fields may include:
+
+```ts
+id: uuid;
+
+combatId: uuid;
+characterId: uuid;
+
+experienceGranted: number;
+silverGranted: number;
+
+createdAt: timestamptz;
+```
+
+The relation:
+
+```text
+Combat → CombatReward
+```
+
+must effectively be one-to-one.
+
+`combatId` should therefore be unique.
+
+This record acts as proof that the combat has already been rewarded.
+
+---
+
+# 9. Character progression fields
+
+The character needs persistent values for:
+
+```text
+experience
+silver
+```
+
+If `experience` already exists, reuse it.
+
+If silver already exists in another persistent player-state structure, reuse that instead of adding duplicate fields.
+
+Do not create competing currency models.
+
+For this slice:
+
+```text
+experience += reward XP
+silver += reward silver
+```
+
+---
+
+# 10. Leveling scope
+
+XP must be persisted.
+
+However, do not expand this slice into a full progression system unless a minimal level-up path is already present.
+
+The existing XP curve is:
+
+```text
+Level 1 → 2: 100 XP
+Level 2 → 3: 180 XP
+Level 3 → 4: 300 XP
+Level 4 → 5: 450 XP
+Level 5 → 6: 650 XP
+Level 6 → 7: 900 XP
+```
+
+If the project already supports level-up calculations, use the existing implementation.
+
+Otherwise Slice 0.4 may persist XP without implementing the complete later-level progression architecture.
+
+The public reward contract should remain compatible with future level-up information.
+
+---
+
+# 11. ItemDefinition
+
+Reuse the project's existing `ItemDefinition` if already implemented.
+
+For this slice, at least the following item content is needed:
+
+```text
+worn-short-sword
+bandit-blade
+bandit-hood
+```
+
+depending on the existing seed.
+
+Required loot-relevant fields should already support or conceptually include:
+
+```ts
+id
+key
+name
+description
+
+type
+equipmentSlot
+rarity
+tier
+requiredLevel
+
+weaponDamage
+bonusHp
+bonusAttack
+bonusArmor
+
+sellPrice
+iconPath
+```
+
+Do not create a parallel item entity.
+
+---
+
+# 12. CharacterItem
+
+Introduce or reuse minimal persistent player-owned item state.
+
+Conceptually:
+
+```ts
+id: uuid;
+
+characterId: uuid;
+itemDefinitionId: uuid;
+
+quantity: number;
+
+createdAt: timestamptz;
+updatedAt: timestamptz;
+```
+
+For equipment items, quantity may normally be:
+
+```text
+1
+```
+
+If the existing architecture treats equipment instances separately instead of stacking them, preserve that convention.
+
+Do not redesign the inventory model unnecessarily for this slice.
+
+---
+
+# 13. LootTable
+
+Create or reuse:
+
+```text
+LootTable
+```
+
+Conceptual fields:
+
+```ts
+id: uuid;
+
+key: string;
+name: string;
+
+createdAt: timestamptz;
+updatedAt: timestamptz;
+```
+
+Monster definitions should reference their loot table through the project's chosen data model.
+
+Stable keys are preferred.
+
+Example:
+
+```text
+ash-rat-loot
+road-bandit-loot
+```
+
+---
+
+# 14. LootTableEntry
+
+Create:
+
+```text
+LootTableEntry
+```
+
+Conceptual fields:
+
+```ts
+id: uuid;
+
+lootTableId: uuid;
+itemDefinitionId: uuid;
+
+dropChance: decimal;
+
+minQuantity: number;
+maxQuantity: number;
+
+enabled: boolean;
+```
+
+The model should support future guaranteed drops cleanly.
+
+Do not add complex conditional loot scripting in this slice.
+
+---
+
+# 15. First Aschenratte rewards
+
+According to the existing balancing specification:
+
+## Guaranteed
+
+```text
+4–7 Silver
+8 XP
+```
+
+## Material
+
+```text
+60 % Aschenfell / Tierrest
+```
+
+## Equipment
+
+```text
+8 % simple starter-slot equipment
+```
+
+For this technical slice, the minimal useful implementation should preserve those documented probabilities where the necessary item definitions exist.
+
+If `Aschenfell` has not yet been modeled as an item and introducing generic material items would unnecessarily expand scope, equipment loot may be prioritized first.
+
+Any deliberate omission must be documented.
+
+Do not silently invent replacement probabilities.
+
+---
+
+# 16. First Straßenräuber rewards
+
+According to the balancing specification:
+
+## Guaranteed
+
+```text
+9–15 Silver
+16 XP
+```
+
+## Equipment
+
+```text
+18 % Räuberklinge
+12 % Räuberhaube
+8 % Plündererhandschuhe
+10 % Kleiner Heiltrank
+```
+
+For Slice 0.4, only already-supported item types need to be persisted.
+
+At minimum the slice should support:
+
+```text
+Räuberklinge
+Räuberhaube
+```
+
+if these are already part of the technical mini-slice content.
+
+Do not implement potions or combat consumables solely because the final loot table contains them.
+
+Unsupported entries may be deferred explicitly.
+
+---
+
+# 17. Loot rolls are independent
+
+Unless the existing design specifies otherwise, separate listed drops are independent rolls.
+
+Conceptually for Straßenräuber:
+
+```text
+roll Räuberklinge
+roll Räuberhaube
+```
+
+This means one combat may produce:
+
+```text
+nothing
+one item
+multiple items
+```
+
+depending on the configured loot entries.
+
+Do not force exactly one item drop.
+
+---
+
+# 18. Silver roll
+
+Silver is guaranteed but variable.
+
+Example for Aschenratte:
+
+```text
+min = 4
+max = 7
+```
+
+The backend rolls an inclusive integer:
+
+```text
+4
+5
+6
+or
+7
+```
+
+For Straßenräuber:
+
+```text
+9–15
+```
+
+The silver roll must use the same testable randomness abstraction approach already used for hunting where appropriate.
+
+Do not make reward tests flaky.
+
+---
+
+# 19. Random abstraction
+
+Reuse the existing injectable `RandomSource` from Slice 0.2 if available.
+
+Do not create another independent random abstraction.
+
+The same infrastructure should be usable for:
+
+```text
+encounter selection
+silver roll
+loot rolls
+```
+
+Tests must be able to inject fixed random values.
+
+---
+
+# 20. LootService
+
+Create or extend:
+
+```text
+LootService
+```
+
+The LootService should be responsible for deterministic reward calculation from content definitions.
+
+Conceptual API:
+
+```ts
+rollLoot(
+  monsterDefinitionId: string,
+): Promise<LootRollResult>
+```
+
+The result may contain:
+
+```ts
+{
+  items: [
+    {
+      itemDefinitionId: string;
+      quantity: number;
+    }
+  ]
+}
+```
+
+Do not grant items inside the pure roll portion if that makes deterministic unit testing difficult.
+
+Prefer separating:
+
+```text
+roll
+```
+
+from:
+
+```text
+grant/persist
+```
+
+where that matches existing architecture.
+
+---
+
+# 21. RewardService or orchestration boundary
+
+Reward resolution should be orchestrated in one clear service boundary.
+
+Possible name:
+
+```text
+CombatRewardService
+```
+
+or equivalent existing architecture.
+
+Responsibilities:
+
+```text
+validate won combat
+↓
+ensure reward not already granted
+↓
+load monster reward definition
+↓
+determine XP
+↓
+roll silver
+↓
+roll loot
+↓
+persist Character XP
+↓
+persist Character silver
+↓
+persist CharacterItem rewards
+↓
+persist CombatReward
+↓
+commit
+↓
+return reward DTO
+```
+
+All persistence must happen transactionally.
+
+---
+
+# 22. Reward transaction
+
+The reward operation must be atomic.
+
+Conceptually:
+
+```text
+lock Combat
+↓
+verify WON
+↓
+verify no CombatReward exists
+↓
+calculate rewards
+↓
+update character XP
+↓
+update character silver
+↓
+grant items
+↓
+create CombatReward
+↓
+commit
+```
+
+If persistence fails midway:
+
+```text
+no partial reward should remain
+```
+
+---
+
+# 23. When rewards are resolved
+
+Preferred behavior:
+
+When a combat action changes:
+
+```text
+ACTIVE
+```
+
+to:
+
+```text
+WON
+```
+
+the backend may immediately resolve rewards in the same higher-level combat completion flow.
+
+Alternatively, a dedicated reward-resolution endpoint may be used if the project architecture strongly favors that.
+
+However:
+
+> reward resolution must remain idempotent and server-owned.
+
+Do not rely on the frontend calling a special endpoint exactly once for correctness.
+
+If a separate endpoint exists, repeated calls must return the already-created result rather than grant new rewards.
+
+---
+
+# 24. Preferred API behavior
+
+The cleanest player-facing result is for the final combat response to contain or reference reward information after victory.
+
+Example:
+
+```json
+{
+  "id": "combat-uuid",
+  "status": "WON",
+  "round": 4,
+
+  "player": {
+    "currentHp": 82,
+    "maxHp": 100
+  },
+
+  "monster": {
+    "name": "Aschenratte",
+    "currentHp": 0,
+    "maxHp": 45
+  },
+
+  "rewards": {
+    "experience": 8,
+    "silver": 6,
+    "items": []
+  }
+}
+```
+
+If rewards are represented as a separate resource, the API should still make retrieval straightforward.
+
+---
+
+# 25. Reward retrieval
+
+A browser refresh after victory must not lose the reward summary.
+
+Therefore:
+
+```text
+GET /api/combats/:combatId
+```
+
+should either include the persisted reward or provide a stable reference to it.
+
+Do not keep victory rewards only in transient Angular state.
+
+---
+
+# 26. Reward DTO
+
+Conceptually:
+
+```ts
+interface CombatRewardDto {
+  experience: number;
+  silver: number;
+
+  items: Array<{
+    characterItemId: string;
+    item: {
+      key: string;
+      name: string;
+      rarity: string;
+      iconPath: string;
+    };
+    quantity: number;
+  }>;
+}
+```
+
+Do not expose:
+
+```text
+drop chance
+random roll result
+loot-table internal ID
+```
+
+to the normal player-facing DTO.
+
+---
+
+# 27. Item persistence
+
+When an item drops, the item must exist as actual persistent player state before the response is returned.
+
+The frontend must not merely show a cosmetic reward card.
+
+Example:
+
+```text
+Räuberklinge dropped
+↓
+CharacterItem created
+↓
+reward DTO references CharacterItem
+```
+
+Slice 0.5 will use that persisted item.
+
+---
+
+# 28. Duplicate items
+
+Duplicate equipment drops are allowed.
+
+The existing design explicitly allows duplicate items.
+
+Do not add:
+
+```text
+duplicate protection
+salvaging
+automatic conversion
+pity system
+```
+
+in this slice.
+
+---
+
+# 29. No boss guarantee logic yet
+
+The full balancing design later includes:
+
+```text
+guaranteed boss progression item
++
+special boss roll
+```
+
+Do not implement that system for Slice 0.4.
+
+The initial monsters are:
+
+```text
+Aschenratte
+Straßenräuber
+```
+
+Keep the implementation sufficient for normal-monster loot while allowing future extension.
+
+---
+
+# 30. Combat completion integration
+
+Modify the Slice 0.3 victory flow.
+
+Previously:
+
+```text
+Combat = WON
+↓
+no rewards
+```
+
+Now:
+
+```text
+Combat = WON
+↓
+reward resolution
+↓
+Combat response contains persisted rewards
+```
+
+The combat engine itself must remain unaware of loot.
+
+Keep this boundary:
+
+```text
+CombatEngineService
+    ↓
+returns WON
+
+CombatService / orchestration
+    ↓
+persists combat completion
+
+Reward service
+    ↓
+grants rewards
+```
+
+Do not add loot logic to `CombatEngineService`.
+
+---
+
+# 31. Frontend victory screen
+
+Replace the temporary Slice 0.3 victory placeholder with a real reward summary.
+
+Example:
+
+```text
+SIEG
+
+Aschenratte wurde besiegt.
+
+Belohnungen
+
++8 XP
++6 Silber
+
+Keine besondere Beute gefunden.
+
+[ Zur Jagd ]
+```
+
+If an item drops:
+
+```text
+SIEG
+
+Straßenräuber wurde besiegt.
+
+Belohnungen
+
++16 XP
++12 Silber
+
+Beute
+
+[Räuberklinge Icon]
+Räuberklinge
+Selten
+
+[ Zur Jagd ]
+```
+
+---
+
+# 32. Reward presentation
+
+Reward priority:
+
+```text
+Victory
+↓
+XP
+↓
+Silver
+↓
+Item loot
+```
+
+Equipment drops should receive stronger visual emphasis than routine currency.
+
+The UI should make a meaningful item drop feel valuable without using excessive mobile-game celebration effects.
+
+---
+
+# 33. Item cards
+
+For dropped equipment, reuse or introduce a compact reusable item presentation.
+
+Show:
+
+```text
+icon
+name
+rarity
+quantity if relevant
+```
+
+Do not implement the full comparison tooltip yet.
+
+Do not show:
+
+```text
+equip button
+stat comparison
+slot replacement
+```
+
+Those belong to Slice 0.5.
+
+---
+
+# 34. No-loot state
+
+A victory without an item drop is valid.
+
+The reward screen must still feel complete because XP and silver are guaranteed.
+
+Example:
+
+```text
+Keine besondere Beute gefunden.
+```
+
+Do not frame this as an error.
+
+---
+
+# 35. Character UI updates
+
+After reward resolution, global UI elements showing character resources should refresh appropriately.
+
+If the TopBar already displays XP or silver:
+
+```text
+update from authoritative server data
+```
+
+Do not mutate those values optimistically without confirming the backend result.
+
+---
+
+# 36. Hunt return
+
+After reviewing rewards:
+
+```text
+Zur Jagd
+```
+
+returns to:
+
+```text
+/hunt
+```
+
+The previous selected/consumed encounter must not become attackable again.
+
+The player can start:
+
+```text
+Neu suchen
+```
+
+for another hunt.
+
+---
+
+# 37. Database changes
+
+Create or extend the migration for:
+
+```text
+combat_reward
+loot_table
+loot_table_entry
+character_item
+```
+
+and character currency fields where not already present.
+
+Migration requirements:
+
+- preserve all existing data
+- use UUID primary keys
+- create proper foreign keys
+- enforce one reward per combat
+- create unique content keys
+- create useful indexes
+- do not drop unrelated tables
+- keep `synchronize` disabled
+
+---
+
+# 38. Seed changes
+
+Extend the existing idempotent seed.
+
+At minimum seed required loot configuration for:
+
+```text
+Aschenratte
+Straßenräuber
+```
+
+Seed relevant item definitions that do not already exist.
+
+The seed must remain idempotent.
+
+Running it repeatedly must not:
+
+```text
+duplicate loot tables
+duplicate loot entries
+duplicate item definitions
+reset player XP
+reset silver
+delete player items
+delete combat rewards
+```
+
+---
+
+# 39. Backend tests – reward eligibility
+
+Test:
+
+```text
+ACTIVE combat
+→ rewards rejected
+```
+
+Test:
+
+```text
+LOST combat
+→ rewards rejected
+```
+
+Test:
+
+```text
+WON combat
+→ rewards granted
+```
+
+---
+
+# 40. Backend tests – idempotency
+
+Given one won combat:
+
+```text
+resolve rewards
+↓
+resolve rewards again
+```
+
+Verify:
+
+```text
+XP only granted once
+silver only granted once
+items only granted once
+single CombatReward exists
+```
+
+This is one of the most important tests of the slice.
+
+---
+
+# 41. Backend tests – Aschenratte
+
+Using deterministic randomness, verify:
+
+```text
+XP = 8
+silver is within 4–7
+```
+
+Where implemented, verify expected item roll behavior.
+
+---
+
+# 42. Backend tests – Straßenräuber
+
+Verify:
+
+```text
+XP = 16
+silver is within 9–15
+```
+
+With deterministic random values, verify known item outcomes such as:
+
+```text
+Räuberklinge drops
+```
+
+and:
+
+```text
+Räuberklinge does not drop
+```
+
+No statistical/flaky tests.
+
+---
+
+# 43. Backend tests – transaction
+
+Simulate or test failure during reward persistence where practical.
+
+Verify no state like:
+
+```text
+XP granted
+but reward record missing
+```
+
+or:
+
+```text
+item granted twice
+```
+
+can result.
+
+---
+
+# 44. Backend tests – CharacterItem
+
+When an item is rolled:
+
+```text
+CharacterItem persisted
+correct character
+correct ItemDefinition
+correct quantity
+```
+
+---
+
+# 45. Frontend tests – victory rewards
+
+Given:
+
+```text
+status = WON
+rewards.experience = 8
+rewards.silver = 6
+```
+
+verify:
+
+```text
+victory shown
+8 XP shown
+6 silver shown
+```
+
+---
+
+# 46. Frontend tests – item drop
+
+Given reward:
+
+```text
+Räuberklinge
+```
+
+verify:
+
+```text
+item icon rendered
+item name rendered
+rarity rendered
+```
+
+Do not require an equip action yet.
+
+---
+
+# 47. Frontend tests – no item
+
+Given:
+
+```text
+items = []
+```
+
+verify a valid no-special-loot state.
+
+---
+
+# 48. Frontend tests – refresh
+
+Opening an already won combat must reload its persisted rewards.
+
+The frontend must not reroll or reconstruct them.
+
+---
+
+# 49. Server-authority checklist
+
+The server owns:
+
+```text
+reward eligibility
+reward idempotency
+XP amount
+silver roll
+loot tables
+drop probabilities
+random loot rolls
+item granting
+currency persistence
+reward persistence
+```
+
+The client owns only:
+
+```text
+displaying the reward
+navigating away after the player reviews it
+```
+
+---
+
+# 50. Visual requirements
+
+The reward summary should remain part of the established Ashen Realms combat presentation.
+
+Use:
+
+```text
+dark metal / stone panels
+bronze details
+large readable reward values
+high-quality item icons
+restrained rarity emphasis
+```
+
+Do not introduce:
+
+```text
+loot-box presentation
+slot-machine effects
+large flashing reward popups
+bright mobile-game confetti
+generic ecommerce cards
+```
+
+A valuable item should feel valuable primarily because of:
+
+```text
+icon
+rarity
+name
+presentation hierarchy
+```
+
+---
+
+# 51. Definition of Done
+
+Playable Slice 0.4 is complete when this full browser flow works:
+
+```text
+Südtor
+↓
+Verbrannte Straße
+↓
+Jagd
+↓
+choose encounter
+↓
+combat
+↓
+win
+↓
+Combat = WON
+↓
+backend grants XP
+↓
+backend rolls and grants silver
+↓
+backend rolls loot
+↓
+any dropped item is persisted
+↓
+CombatReward persisted
+↓
+Angular shows reward summary
+↓
+refresh page
+↓
+same reward still shown
+↓
+no duplicate rewards granted
+↓
+return to hunt
+```
+
+---
+
+# 52. Required verification
+
+Before completion, run:
+
+```text
+API unit tests
+API integration tests
+Angular tests
+API build
+Angular build
+migration compilation
+migration execution
+seed execution
+```
+
+Perform browser walkthroughs for:
+
+```text
+Aschenratte victory with no item
+Aschenratte victory with forced deterministic item roll where supported
+Straßenräuber victory
+Straßenräuber with Räuberklinge drop
+reward screen refresh
+repeated reward request
+return to hunt
+```
+
+---
+
+# 53. Acceptance criteria
+
+The slice is accepted when:
+
+- only WON combats receive victory rewards
+- one combat grants rewards at most once
+- XP is persisted
+- silver is persisted
+- silver ranges match the content definitions
+- loot rolls happen only on the backend
+- loot probabilities are data-driven
+- reward randomness is deterministic in tests
+- dropped items become persistent CharacterItems
+- reward data survives browser refresh
+- reward results never reroll on reload
+- Angular only renders server-provided reward state
+- item drops are visibly presented
+- a no-item victory is handled cleanly
+- CombatEngineService contains no reward logic
+- no equipment functionality is implemented prematurely
+- all tests pass
+- backend and frontend builds succeed
+
+---
+
+# 54. Handoff to Playable Slice 0.5
+
+The exact handoff from Slice 0.4 is:
+
+```text
+WON Combat
++
+persisted CombatReward
++
+persisted CharacterItem
+```
+
+For example:
+
+```text
+Character owns:
+Räuberklinge
+```
+
+but cannot yet equip it.
+
+Playable Slice 0.5 will implement:
+
+```text
+Inventory
+→ inspect Räuberklinge
+→ compare against Abgenutztes Kurzschwert
+→ equip Räuberklinge
+→ effective weapon damage increases
+→ next combat becomes easier
+```
+
+---
+
+# 55. Why Slice 0.5 matters
+
+Slice 0.4 gives the player a reward.
+
+Slice 0.5 makes that reward meaningful.
+
+Together they complete the central progression loop:
+
+```text
+hunt
+→ fight
+→ loot
+→ equip
+→ become stronger
+```
+
+That is the first real proof of the Ashen Realms item-driven progression philosophy.
+
+---
+
+# 56. Architectural boundary
+
+Keep responsibilities separated:
+
+```text
+CombatEngineService
+    ↓
+decides combat result
+
+CombatService
+    ↓
+persists combat
+
+Reward service
+    ↓
+decides and grants rewards
+
+LootService
+    ↓
+rolls configured loot
+
+CharacterItem
+    ↓
+stores player-owned loot
+
+Slice 0.5
+    ↓
+uses that loot as equipment
+```
+
+Do not let the combat engine know about:
+
+```text
+XP
+silver
+loot tables
+inventory
+equipment
+item rarity
+```
+
+---
+
+# 57. Summary
+
+Playable Slice 0.4 proves that defeating an enemy produces real, persistent progression resources.
+
+After this slice the player can:
+
+```text
+travel
+→ hunt
+→ choose enemy
+→ fight
+→ win
+→ receive XP
+→ receive silver
+→ find an item
+```
+
+The next slice completes the loop by allowing the player to actually use that item.
\ No newline at end of file
diff --git a/docs/playable-slices/Ashen Realms – Playable Slice 0.5_ First Upgrade.md b/docs/playable-slices/Ashen Realms – Playable Slice 0.5_ First Upgrade.md
new file mode 100644
index 0000000..d158666
--- /dev/null
+++ b/docs/playable-slices/Ashen Realms – Playable Slice 0.5_ First Upgrade.md	
@@ -0,0 +1,1929 @@
+# Ashen Realms – Playable Slice 0.5: First Upgrade
+
+**Status:** Ready for implementation  
+**Prerequisite:** Playable Slice 0.4 – First Loot  
+**Scope:** First usable inventory and equipment upgrade  
+**Primary Upgrade:** Abgenutztes Kurzschwert → Räuberklinge  
+**Primary Goal:** A looted item can be equipped and measurably changes the character's effective combat stats.
+
+---
+
+# 1. Goal
+
+Playable Slice 0.5 completes the first full Ashen Realms progression loop.
+
+The existing playable flow:
+
+```text
+World
+→ Travel
+→ Hunt
+→ Encounter
+→ Combat
+→ Victory
+→ Reward
+```
+
+becomes:
+
+```text
+World
+→ Travel
+→ Hunt
+→ Combat
+→ Loot
+→ Inventory
+→ Equip upgrade
+→ Character becomes stronger
+→ next combat becomes easier
+```
+
+This slice must prove that:
+
+- player-owned items are persistent
+- inventory is server-authoritative
+- equipment is server-authoritative
+- equipment slots are enforced
+- item ownership is validated
+- required level is validated
+- effective character stats are derived from character base stats plus equipment
+- equipping an upgrade changes combat-relevant stats
+- the frontend does not calculate authoritative character power
+- a newly obtained weapon produces a visibly meaningful improvement
+
+The primary demonstration is:
+
+```text
+Abgenutztes Kurzschwert
+8 Waffenschaden
+```
+
+becomes:
+
+```text
+Räuberklinge
+11 Waffenschaden
++1 Angriff
+```
+
+and the next combat deals more damage.
+
+---
+
+# 2. Core player flow
+
+The intended flow is:
+
+```text
+Straßenräuber besiegen
+↓
+Räuberklinge erhalten
+↓
+Reward screen
+↓
+Inventar öffnen
+↓
+Räuberklinge auswählen
+↓
+current item and new item compared
+↓
+Ausrüsten
+↓
+server validates item
+↓
+server equips Räuberklinge in Waffe slot
+↓
+effective stats recalculated
+↓
+Topbar / character UI updates
+↓
+return to hunt
+↓
+fight another enemy
+↓
+player deals more damage
+```
+
+This moment is the first real proof of item-driven progression.
+
+---
+
+# 3. Scope
+
+Implement:
+
+```text
+Inventory API
+
+Equipment API
+
+CharacterEquipment persistence
+
+CharacterStatsService
+
+effective character stats
+
+weapon equipment slot
+
+basic armor equipment slots where already supported
+
+inventory page
+
+item selection
+
+item detail presentation
+
+simple equipped-item comparison
+
+equip action
+
+unequip/replace behavior as required
+
+equipped state display
+
+effective stat refresh
+```
+
+At minimum, the system must support:
+
+```text
+Abgenutztes Kurzschwert
+Räuberklinge
+Räuberhaube
+```
+
+where those items already exist in content.
+
+---
+
+# 4. Explicit non-goals
+
+Do not implement:
+
+```text
+item selling
+merchants
+item durability
+repairs
+salvaging
+crafting
+socketing
+random affixes
+item upgrades +1 to +10
+transmog
+set bonuses
+complex tooltips
+drag-and-drop inventory
+inventory sorting systems
+filters
+search
+bank/storage
+stash
+equipment presets
+multiple builds
+comparison against every possible slot
+```
+
+Do not expand the slice into a complete MMO inventory system.
+
+The goal is only:
+
+> obtain item → inspect item → equip item → become stronger.
+
+---
+
+# 5. Equipment philosophy
+
+Ashen Realms uses equipment as the primary source of character power.
+
+The Vertical Slice targets roughly:
+
+```text
+20 % strength from level/base stats
+80 % strength from equipment
+```
+
+Therefore equipment changes must be noticeable.
+
+The player should immediately understand:
+
+```text
+old weapon
+↓
+new weapon
+↓
+more damage
+```
+
+Do not hide the effect behind tiny percentage changes.
+
+---
+
+# 6. Equipment slots
+
+The final Vertical Slice uses:
+
+```text
+WEAPON
+HEAD
+CHEST
+HANDS
+LEGS
+FEET
+AMULET
+```
+
+Slice 0.5 should support this enum/data model cleanly.
+
+However, the actual playable demonstration only requires:
+
+```text
+WEAPON
+```
+
+and optionally:
+
+```text
+HEAD
+```
+
+if Räuberhaube is already part of the first loot implementation.
+
+Do not build seven complex UI workflows if only one or two slots currently have content.
+
+---
+
+# 7. ItemDefinition
+
+Reuse the existing `ItemDefinition`.
+
+Do not create a second item model.
+
+Relevant conceptual fields:
+
+```ts
+id: uuid;
+
+key: string;
+name: string;
+description: string;
+
+type: ItemType;
+equipmentSlot?: EquipmentSlot;
+
+rarity: ItemRarity;
+tier: number;
+
+requiredLevel: number;
+
+weaponDamage: number;
+bonusHp: number;
+bonusAttack: number;
+bonusArmor: number;
+
+sellPrice: number;
+iconPath: string;
+```
+
+Only fields already supported by the existing architecture should be introduced.
+
+Do not add speculative attributes.
+
+---
+
+# 8. Initial item content
+
+## Abgenutztes Kurzschwert
+
+Stable key:
+
+```text
+worn-short-sword
+```
+
+Stats:
+
+```text
+equipmentSlot: WEAPON
+requiredLevel: 1
+
+weaponDamage: 8
+bonusAttack: 0
+bonusHp: 0
+bonusArmor: 0
+```
+
+This is the starting weapon.
+
+---
+
+# 9. Räuberklinge
+
+Stable key:
+
+```text
+bandit-blade
+```
+
+Stats:
+
+```text
+equipmentSlot: WEAPON
+requiredLevel: 1
+
+weaponDamage: 11
+bonusAttack: 1
+```
+
+This item must be a clear upgrade from the starting weapon.
+
+If finalized content in the repository differs, preserve the established project values.
+
+---
+
+# 10. Räuberhaube
+
+Stable key:
+
+```text
+bandit-hood
+```
+
+Stats:
+
+```text
+equipmentSlot: HEAD
+
+bonusArmor: 3
+bonusHp: 5
+```
+
+Only include this in the playable inventory if it already exists in Slice 0.4 content.
+
+The weapon upgrade remains the required core test.
+
+---
+
+# 11. CharacterItem
+
+Reuse the persistent player-owned item entity introduced in Slice 0.4.
+
+Conceptually:
+
+```ts
+id: uuid;
+
+characterId: uuid;
+itemDefinitionId: uuid;
+
+quantity: number;
+
+createdAt: timestamptz;
+updatedAt: timestamptz;
+```
+
+Equipment ownership must originate from `CharacterItem`.
+
+The frontend must not be able to equip arbitrary `ItemDefinition.id` values.
+
+---
+
+# 12. CharacterEquipment
+
+Create or reuse:
+
+```text
+apps/api/src/equipment/entities/character-equipment.entity.ts
+```
+
+Conceptual fields:
+
+```ts
+id: uuid;
+
+characterId: uuid;
+
+slot: EquipmentSlot;
+
+characterItemId: uuid;
+
+createdAt: timestamptz;
+updatedAt: timestamptz;
+```
+
+Important invariants:
+
+```text
+one equipped item per character per slot
+```
+
+and:
+
+```text
+one CharacterItem cannot occupy multiple equipment slots simultaneously
+```
+
+Protect these through service validation and appropriate database constraints.
+
+---
+
+# 13. Ownership rule
+
+The server must validate:
+
+```text
+CharacterItem belongs to current character
+```
+
+before equipment changes.
+
+Never accept:
+
+```text
+ItemDefinition.id
+```
+
+alone as sufficient proof of ownership.
+
+Equip requests should identify the owned item:
+
+```text
+CharacterItem.id
+```
+
+---
+
+# 14. Equip validation
+
+Before equipping:
+
+```text
+CharacterItem exists
+↓
+belongs to current character
+↓
+ItemDefinition is equippable
+↓
+equipmentSlot exists
+↓
+requiredLevel <= character level
+↓
+item is valid for target slot
+```
+
+The client must not choose an arbitrary target slot if the item already defines its slot.
+
+Prefer:
+
+```http
+POST /api/equipment
+```
+
+with:
+
+```json
+{
+  "characterItemId": "uuid"
+}
+```
+
+The server derives:
+
+```text
+slot
+```
+
+from the item definition.
+
+---
+
+# 15. Equip replacement behavior
+
+If the slot already contains an item:
+
+```text
+current item
+↓
+new item equipped
+↓
+old item becomes unequipped
+↓
+old item remains in inventory
+```
+
+Do not destroy or delete the old CharacterItem.
+
+Example:
+
+```text
+WEAPON:
+Abgenutztes Kurzschwert
+```
+
+then equip:
+
+```text
+Räuberklinge
+```
+
+result:
+
+```text
+WEAPON:
+Räuberklinge
+
+Inventory:
+Abgenutztes Kurzschwert still owned
+```
+
+---
+
+# 16. Unequip behavior
+
+For Slice 0.5, an explicit unequip endpoint is optional.
+
+If implemented:
+
+```http
+DELETE /api/equipment/:slot
+```
+
+It must remove only the equipped relation.
+
+The item remains owned.
+
+Do not make explicit unequip necessary for replacing an item.
+
+---
+
+# 17. Starting equipment
+
+The demo character must begin with:
+
+```text
+Abgenutztes Kurzschwert
+```
+
+actually represented through the same inventory/equipment model used for future loot.
+
+Do not keep the starting weapon as an unrelated hardcoded combat constant once equipment is implemented.
+
+The goal is to remove temporary Slice 0.3 combat-stat shortcuts where possible.
+
+---
+
+# 18. CharacterStatsService
+
+Introduce or complete:
+
+```text
+CharacterStatsService
+```
+
+This becomes the single authoritative source for effective character stats.
+
+Conceptual return type:
+
+```ts
+interface EffectiveCharacterStats {
+  maxHp: number;
+  currentHp: number;
+
+  attack: number;
+  weaponDamage: number;
+  armor: number;
+
+  combatPower: number;
+}
+```
+
+The service calculates values from:
+
+```text
+Character base stats
++
+equipped ItemDefinitions
+```
+
+Do not calculate effective stats in:
+
+```text
+Angular
+CombatController
+InventoryController
+```
+
+---
+
+# 19. Base stats
+
+The starting level-1 character uses:
+
+```text
+baseHp = 100
+baseAttack = 6
+```
+
+Equipment supplies:
+
+```text
+weaponDamage
+armor
+bonusHp
+bonusAttack
+```
+
+Starting equipment target:
+
+```text
+100 HP
+6 base attack
+8 weapon damage
+6 armor
+```
+
+if the corresponding starting armor pieces are already modeled.
+
+If not all armor items currently exist, do not fabricate an entire starter gear set merely for Slice 0.5.
+
+Preserve the existing demo balance as closely as the implemented content allows.
+
+---
+
+# 20. Effective stat calculation
+
+Conceptually:
+
+```text
+maxHp =
+baseHp
++ sum equipped bonusHp
+
+attack =
+baseAttack
++ sum equipped bonusAttack
+
+weaponDamage =
+equipped weapon weaponDamage
+
+armor =
+sum equipped bonusArmor
+```
+
+If no weapon is equipped:
+
+```text
+weaponDamage = 0
+```
+
+or use another existing explicit project rule.
+
+Do not silently inject a fake weapon value.
+
+---
+
+# 21. Combat Power
+
+Calculate internal Combat Power using the established formula:
+
+```text
+Combat Power =
+HP / 10
++ Attack × 2
++ Weapon Damage × 2
++ Armor × 1.5
+```
+
+This value remains internal for balancing unless the existing UI already exposes it.
+
+Do not add Combat Power to the player-facing UI just because the service now calculates it.
+
+---
+
+# 22. Combat integration
+
+Slice 0.3 combat snapshots player stats when combat begins.
+
+After Slice 0.5:
+
+```text
+Combat creation
+↓
+CharacterStatsService.calculate(...)
+↓
+snapshot current effective equipment-derived stats
+```
+
+Therefore equipping Räuberklinge affects:
+
+```text
+future combats
+```
+
+but must not retroactively alter:
+
+```text
+already-active combat
+```
+
+This snapshot behavior is important.
+
+---
+
+# 23. Example power change
+
+Before upgrade:
+
+```text
+Base attack: 6
+Weapon damage: 8
+```
+
+Raw attack damage:
+
+```text
+14
+```
+
+After equipping Räuberklinge:
+
+```text
+Attack:
+6 + 1 = 7
+
+Weapon damage:
+11
+```
+
+Raw attack damage:
+
+```text
+18
+```
+
+Therefore the upgrade should be clearly noticeable.
+
+---
+
+# 24. Inventory API
+
+Implement:
+
+```http
+GET /api/inventory
+```
+
+The server resolves the current character.
+
+Do not send:
+
+```text
+characterId
+```
+
+from Angular.
+
+Example response:
+
+```json
+{
+  "items": [
+    {
+      "id": "character-item-uuid",
+      "quantity": 1,
+      "equipped": false,
+      "item": {
+        "key": "bandit-blade",
+        "name": "Räuberklinge",
+        "rarity": "COMMON",
+        "equipmentSlot": "WEAPON",
+        "requiredLevel": 1,
+        "weaponDamage": 11,
+        "bonusAttack": 1,
+        "bonusHp": 0,
+        "bonusArmor": 0,
+        "iconPath": "/assets/items/bandit-blade.webp"
+      }
+    }
+  ]
+}
+```
+
+Do not expose unnecessary persistence details.
+
+---
+
+# 25. Equipment API
+
+Implement:
+
+```http
+GET /api/equipment
+```
+
+Response conceptually:
+
+```json
+{
+  "slots": {
+    "WEAPON": {
+      "characterItemId": "uuid",
+      "item": {
+        "key": "worn-short-sword",
+        "name": "Abgenutztes Kurzschwert"
+      }
+    },
+    "HEAD": null
+  },
+  "stats": {
+    "maxHp": 100,
+    "attack": 6,
+    "weaponDamage": 8,
+    "armor": 6
+  }
+}
+```
+
+Only expose slots supported by the current shared enum.
+
+---
+
+# 26. Equip API
+
+Implement:
+
+```http
+POST /api/equipment
+```
+
+Request:
+
+```json
+{
+  "characterItemId": "uuid"
+}
+```
+
+Server determines:
+
+```text
+character
+item
+equipment slot
+validity
+```
+
+Response should return authoritative updated equipment and effective stats.
+
+Do not require the frontend to manually reload multiple unrelated resources if one coherent response can provide the changed state.
+
+---
+
+# 27. Domain errors
+
+Use stable errors.
+
+Examples:
+
+```text
+CHARACTER_ITEM_NOT_FOUND
+
+ITEM_NOT_OWNED
+
+ITEM_NOT_EQUIPPABLE
+
+ITEM_LEVEL_REQUIREMENT_NOT_MET
+
+INVALID_EQUIPMENT_SLOT
+```
+
+If another item occupies the slot, replacement is valid and should not be an error.
+
+---
+
+# 28. Transaction
+
+Equip operations must be transactional.
+
+Conceptually:
+
+```text
+load/lock CharacterItem
+↓
+validate ownership
+↓
+load ItemDefinition
+↓
+validate level/slot
+↓
+remove/replace current CharacterEquipment relation
+↓
+create/update equipment relation
+↓
+commit
+```
+
+Concurrent equip requests must not create duplicate slot occupancy.
+
+---
+
+# 29. Inventory page route
+
+Activate or create:
+
+```text
+/inventory
+```
+
+Enable:
+
+```text
+Inventar
+```
+
+in the left navigation.
+
+The screen must remain inside the existing AppShell.
+
+---
+
+# 30. Inventory page layout
+
+The inventory page should preserve the Ashen Realms visual language.
+
+Recommended desktop composition:
+
+```text
+left / center:
+inventory item slots/grid
+
+right:
+selected item details / comparison
+```
+
+Avoid:
+
+```text
+generic ecommerce product grid
+admin table
+SaaS data table
+```
+
+The inventory should feel like RPG equipment management.
+
+---
+
+# 31. Inventory grid
+
+The full Vertical Slice concept allows approximately:
+
+```text
+24 slots
+```
+
+However Slice 0.5 does not require enforcing capacity yet unless this already exists.
+
+The UI may visually establish a slot-based inventory.
+
+At minimum display:
+
+```text
+item icon
+quantity
+rarity
+equipped indicator
+```
+
+Empty slots may be displayed for visual structure.
+
+---
+
+# 32. Item selection
+
+Clicking an owned item selects it.
+
+Selected item details show:
+
+```text
+name
+icon
+rarity
+equipment slot
+required level
+stats
+equipped state
+```
+
+Example:
+
+```text
+Räuberklinge
+
+Waffe
+Stufe 1
+
+11 Waffenschaden
++1 Angriff
+```
+
+---
+
+# 33. Item comparison
+
+When selecting an equippable item, compare it to the currently equipped item in the same slot.
+
+Example:
+
+```text
+Räuberklinge
+
+11 Waffenschaden    +3
++1 Angriff          +1
+```
+
+compared to:
+
+```text
+Abgenutztes Kurzschwert
+
+8 Waffenschaden
+```
+
+The comparison exists for player clarity only.
+
+The backend remains authoritative over actual stat calculations.
+
+---
+
+# 34. Comparison rules
+
+Use simple deterministic numeric comparison.
+
+For Slice 0.5, show only direct fixed stats:
+
+```text
+weaponDamage
+bonusAttack
+bonusHp
+bonusArmor
+```
+
+Do not invent an opaque overall item score.
+
+Do not use Combat Power as the item comparison metric.
+
+---
+
+# 35. Equip action
+
+Selected equippable, owned, level-valid items show:
+
+```text
+Ausrüsten
+```
+
+Clicking it calls:
+
+```http
+POST /api/equipment
+```
+
+After success:
+
+```text
+inventory state refreshes
+equipment state refreshes
+effective stats refresh
+equipped indicator updates
+```
+
+---
+
+# 36. Already equipped state
+
+If the selected item is already equipped:
+
+```text
+Ausgerüstet
+```
+
+should be clearly visible.
+
+Do not show another active:
+
+```text
+Ausrüsten
+```
+
+button for the same item.
+
+---
+
+# 37. Required-level state
+
+If the player's level is too low:
+
+Display:
+
+```text
+Benötigt Stufe X
+```
+
+and disable the equip action.
+
+Backend must still enforce the same validation.
+
+---
+
+# 38. Equipment overview
+
+The inventory or right context area should show current equipped slots.
+
+At minimum:
+
+```text
+Waffe
+Kopf
+Brust
+Handschuhe
+Beine
+Stiefel
+Amulett
+```
+
+Slots without items should clearly show:
+
+```text
+Leer
+```
+
+Do not add fake starter gear to fill every visual slot.
+
+---
+
+# 39. Effective stats presentation
+
+Display a small character stat summary:
+
+```text
+Leben
+Angriff
+Waffenschaden
+Rüstung
+```
+
+These values must come from the backend.
+
+Example before:
+
+```text
+Angriff: 6
+Waffenschaden: 8
+```
+
+after:
+
+```text
+Angriff: 7
+Waffenschaden: 11
+```
+
+The visual update is important to make the upgrade obvious.
+
+---
+
+# 40. Topbar integration
+
+If the TopBar displays HP or other affected values, refresh its authoritative character state after equipment changes.
+
+Do not create a second conflicting stat representation.
+
+Reuse the existing character/world store architecture where appropriate.
+
+---
+
+# 41. Reward screen integration
+
+Slice 0.4 currently presents dropped items.
+
+Add a useful navigation path:
+
+```text
+Inventar öffnen
+```
+
+when equipment loot is obtained.
+
+Example:
+
+```text
+Räuberklinge erhalten
+
+[ Inventar öffnen ]
+[ Zur Jagd ]
+```
+
+Do not equip loot directly from the reward screen in this slice.
+
+The player should consciously inspect and equip the item.
+
+---
+
+# 42. CharacterStatsService tests
+
+At minimum test:
+
+## Starting weapon
+
+Given:
+
+```text
+baseAttack = 6
+baseHp = 100
+
+worn-short-sword:
+weaponDamage = 8
+```
+
+verify:
+
+```text
+attack = 6
+weaponDamage = 8
+```
+
+---
+
+## Räuberklinge
+
+Given:
+
+```text
+bandit-blade:
+weaponDamage = 11
+bonusAttack = 1
+```
+
+verify:
+
+```text
+attack = 7
+weaponDamage = 11
+```
+
+---
+
+## Armor aggregation
+
+Given multiple armor items:
+
+```text
+sum bonusArmor
+```
+
+must be correct.
+
+---
+
+## HP aggregation
+
+Given equipment with:
+
+```text
+bonusHp
+```
+
+verify:
+
+```text
+maxHp = baseHp + bonuses
+```
+
+---
+
+## Combat Power
+
+Verify formula:
+
+```text
+HP / 10
++ attack × 2
++ weaponDamage × 2
++ armor × 1.5
+```
+
+---
+
+# 43. Equipment service tests
+
+At minimum test:
+
+## Equip owned weapon
+
+```text
+owned Räuberklinge
+↓
+equip
+↓
+WEAPON = Räuberklinge
+```
+
+---
+
+## Replace weapon
+
+Given:
+
+```text
+WEAPON = Abgenutztes Kurzschwert
+```
+
+equip Räuberklinge.
+
+Verify:
+
+```text
+WEAPON = Räuberklinge
+old sword still owned
+```
+
+---
+
+## Item not owned
+
+Attempt to equip another character's item.
+
+Expected:
+
+```text
+ITEM_NOT_OWNED
+```
+
+---
+
+## Required level
+
+Attempt to equip an item above character level.
+
+Expected rejection.
+
+---
+
+## Not equippable
+
+Attempt to equip material/trade good.
+
+Expected rejection.
+
+---
+
+## Duplicate slot protection
+
+Concurrent or repeated operations must not produce two equipped weapons.
+
+---
+
+# 44. Inventory API tests
+
+Verify:
+
+```text
+only current character items returned
+```
+
+and each item correctly reports:
+
+```text
+definition data
+quantity
+equipped state
+```
+
+---
+
+# 45. Combat integration tests
+
+This is a critical Slice 0.5 proof.
+
+Test:
+
+```text
+combat with Abgenutztes Kurzschwert
+↓
+record player damage
+```
+
+then:
+
+```text
+equip Räuberklinge
+↓
+start new combat
+↓
+record player damage
+```
+
+Expected:
+
+```text
+new combat deals more damage
+```
+
+Do not assert only that a stat number changed.
+
+Prove the upgrade actually affects gameplay.
+
+---
+
+# 46. Existing combat snapshots
+
+Also verify:
+
+```text
+start combat with old weapon
+↓
+equip change occurs outside combat if technically possible
+```
+
+must not alter the already-created combat snapshot.
+
+Prefer preventing equipment changes while an active combat exists.
+
+This is simpler and fits the game model.
+
+Recommended rule:
+
+> Equipment cannot be changed during an active combat.
+
+Return:
+
+```text
+CHARACTER_IN_COMBAT
+```
+
+if attempted.
+
+---
+
+# 47. Travel restriction
+
+Prefer also preventing equipment changes while travelling if the current product design considers travelling an unavailable interaction state.
+
+However, do not introduce this rule solely by assumption if existing UI already permits inventory management during travel.
+
+Follow the established behavior of the application.
+
+---
+
+# 48. Frontend tests
+
+At minimum cover:
+
+## Inventory load
+
+Opening:
+
+```text
+/inventory
+```
+
+loads server inventory and equipment.
+
+---
+
+## Item rendering
+
+Räuberklinge displays:
+
+```text
+icon
+name
+weapon damage
+bonus attack
+```
+
+---
+
+## Comparison
+
+Given equipped:
+
+```text
+Abgenutztes Kurzschwert
+```
+
+and selected:
+
+```text
+Räuberklinge
+```
+
+show the direct stat improvements.
+
+---
+
+## Equip request
+
+Click:
+
+```text
+Ausrüsten
+```
+
+verify request contains only:
+
+```json
+{
+  "characterItemId": "uuid"
+}
+```
+
+---
+
+## Updated state
+
+After success:
+
+```text
+Räuberklinge marked equipped
+Abgenutztes Kurzschwert marked unequipped
+effective attack updated
+weapon damage updated
+```
+
+---
+
+## Invalid item
+
+Server validation errors display in-shell.
+
+No browser alerts.
+
+---
+
+# 49. Visual requirements
+
+Follow the established Ashen Realms UI:
+
+```text
+dark metal
+stone
+leather
+bronze borders
+high-quality item icons
+clear rarity styling
+large selected-item detail
+```
+
+The inventory must feel like an RPG screen.
+
+Avoid:
+
+```text
+spreadsheet table
+white cards
+generic admin UI
+Material default list
+Bootstrap grid
+```
+
+---
+
+# 50. Item rarity
+
+Use the established rarity levels:
+
+```text
+COMMON / Basis
+RARE / Selten
+EPIC / Besonders
+```
+
+or the actual enum names already present in the repository.
+
+Do not add more rarity tiers.
+
+Rarity may affect:
+
+```text
+border treatment
+name emphasis
+small accent
+```
+
+but must not override readability.
+
+---
+
+# 51. Item icons
+
+Item icons are an important progression signal.
+
+Use the existing generated Ashen Realms item assets.
+
+Do not replace them with generic icon libraries if appropriate game-specific icons already exist.
+
+A weapon upgrade should visually feel valuable before reading every number.
+
+---
+
+# 52. Accessibility
+
+Required:
+
+```text
+keyboard-accessible item selection
+real buttons
+visible focus states
+textual equipped indicator
+textual rarity
+readable stat changes
+disabled action explanation
+```
+
+Do not encode improvements only through green/red color.
+
+Example:
+
+```text
+Waffenschaden 11 (+3)
+```
+
+is preferable to color alone.
+
+---
+
+# 53. Server-authority checklist
+
+Server decides:
+
+```text
+which items character owns
+which item is equipped
+which equipment slot an item uses
+whether level requirement is met
+effective HP
+effective attack
+effective weapon damage
+effective armor
+Combat Power
+combat snapshot stats
+```
+
+Client decides only:
+
+```text
+which owned item the player selects
+whether the player requests to equip it
+```
+
+---
+
+# 54. Database changes
+
+Create or extend migrations for:
+
+```text
+character_equipment
+```
+
+and any missing indexes/constraints for `character_item`.
+
+Required constraints include conceptually:
+
+```text
+unique(characterId, slot)
+```
+
+and appropriate ownership relations.
+
+Do not drop or recreate existing loot/combat/hunt/world data.
+
+---
+
+# 55. Seed changes
+
+Ensure the demo character starts with:
+
+```text
+Abgenutztes Kurzschwert
+```
+
+as a real CharacterItem and equipped WEAPON item.
+
+The seed must remain idempotent.
+
+Re-running must not:
+
+```text
+duplicate starting sword
+duplicate equipment row
+delete earned Räuberklinge
+reset player inventory
+reset rewards
+reset XP
+reset silver
+```
+
+Be especially careful not to turn the seed into a player-state reset.
+
+---
+
+# 56. Definition of Done
+
+Playable Slice 0.5 is complete when this complete flow works:
+
+```text
+start with Abgenutztes Kurzschwert
+↓
+travel to Verbrannte Straße
+↓
+hunt Straßenräuber
+↓
+win combat
+↓
+Räuberklinge drops
+↓
+reward persists
+↓
+open Inventar
+↓
+see Abgenutztes Kurzschwert equipped
+↓
+select Räuberklinge
+↓
+see stat comparison
+↓
+click Ausrüsten
+↓
+server replaces weapon
+↓
+Räuberklinge becomes equipped
+↓
+effective stats increase
+↓
+return to hunt
+↓
+start another combat
+↓
+player deals more damage than before
+```
+
+---
+
+# 57. Required verification
+
+Before completion run:
+
+```text
+API unit tests
+API integration tests
+Angular tests
+API build
+Angular build
+migration compilation
+migration execution
+seed execution
+```
+
+Perform manual browser walkthroughs for:
+
+```text
+inventory with starting weapon
+
+inventory after item drop
+
+select Räuberklinge
+
+comparison against starting sword
+
+equip Räuberklinge
+
+refresh inventory page
+
+equipped state survives refresh
+
+start new combat
+
+verify increased player damage
+```
+
+Also verify error cases:
+
+```text
+equip item not owned
+equip invalid item
+equip level-locked item
+equip while active combat exists
+```
+
+where applicable.
+
+---
+
+# 58. Acceptance criteria
+
+The slice is accepted when:
+
+- inventory is backed by persistent CharacterItem data
+- starting weapon uses the same item/equipment model as loot
+- equipment state is persisted
+- only owned items can be equipped
+- equipment slots are validated server-side
+- required level is validated server-side
+- replacing an item does not delete the previous item
+- CharacterStatsService is the authoritative effective-stat source
+- combat creation uses CharacterStatsService
+- active combat keeps its stat snapshot
+- Räuberklinge increases weapon damage
+- Räuberklinge increases attack
+- next combat demonstrably deals more damage
+- Angular does not calculate authoritative stats
+- inventory screen matches the existing Ashen Realms visual language
+- item comparison is understandable
+- refresh preserves equipment state
+- all tests pass
+- frontend and backend builds succeed
+
+---
+
+# 59. Handoff after Slice 0.5
+
+At the end of Slice 0.5, Ashen Realms has proven its first complete gameplay loop:
+
+```text
+Travel
+↓
+Hunt
+↓
+Choose enemy
+↓
+Combat
+↓
+Victory
+↓
+Loot
+↓
+Inventory
+↓
+Equip upgrade
+↓
+Become stronger
+↓
+Fight again
+```
+
+This is the first major Vertical Slice milestone.
+
+Before dramatically expanding the content, the next development step should build on this verified loop rather than introducing unrelated systems.
+
+Possible next slices include:
+
+```text
+0.6 – Full First Combat Actions
+```
+
+with:
+
+```text
+Schwerer Hieb
+Schildstoß
+Verteidigen
+Trank
+```
+
+or:
+
+```text
+0.6 – Complete Verbrannte Straße
+```
+
+with additional enemies, content and first progression pacing.
+
+The decision should be based on which aspect of the core loop should be validated next.
+
+---
+
+# 60. Key gameplay proof
+
+The most important acceptance test is not simply:
+
+```text
+Räuberklinge is equipped.
+```
+
+It is:
+
+```text
+Before:
+the enemy takes X damage.
+
+Player equips Räuberklinge.
+
+After:
+the same type of enemy takes visibly more damage.
+```
+
+If that works correctly, the first central Ashen Realms progression promise has been proven:
+
+> **A good item makes the player meaningfully stronger.**
\ No newline at end of file