ashen-realms/docs/playable-slices/0.12.5-Ashen_Realms_Character_Page_Reputation_Implementation_Plan.md

Ashen Realms – Character Page & Reputation Progress Implementation Plan

For agentic workers: REQUIRED SUB-SKILL: Use superpowers:subagent-driven-development (recommended) or superpowers:executing-plans to implement this plan task-by-task. Steps use checkbox (- [ ]) syntax for tracking.

Goal: Implement the Ashen Realms character page based on the approved character-page reference screenshot, with equipment, effective character stats, and a prominent Fame/Reputation progression section that gives the player the same continuous motivational feedback a classic XP bar would provide.

Architecture: Reuse the existing Angular AppShell, TopBar, SideNavigation, Footer, panel components, UI assets, and existing reputation/fame backend/domain model. The character page is presentation-first: the server remains authoritative for character values and progression, while Angular composes the data into a dedicated character-page view model. Do not introduce a second reputation system or calculate authoritative progress values in the browser.

Tech Stack: Angular 22.x, TypeScript, SCSS, NestJS 11.x, REST, TypeORM/PostgreSQL, existing Ashen Realms design tokens/assets/components.

Spec:

• docs/ui-visual-design-specification.md
• docs/design-manifest.md
• the repository's current Fame/Reputation (Ruhm / Ruf) specification and implementation
• the approved character-page reference screenshot from the design discussion

---

1. Non-negotiable visual requirement

The approved screenshot and the existing Ashen Realms screens are not inspiration only. They are the visual target.

The implementation must look as if it was built by the same UI team as the existing world, hunting, combat, inventory, and shell screens.

Mandatory rules

• Reuse the existing AppShell, TopBar, SideNavigation, Footer, frame assets, panel assets, typography, colors, button styles, icon style, spacing tokens, and border treatments wherever they already exist.
• Before writing new SCSS, inspect the current components and apps/web/public/assets/ui/ for reusable assets and styles.
• Do not replace the fantasy UI with generic Angular Material cards, Bootstrap-like panels, SaaS cards, glassmorphism, flat grey boxes, rounded mobile cards, or modern dashboard styling.
• Do not invent a new design system for this screen.
• Do not use a different gold, blue, green, border thickness, font hierarchy, or panel material when the project already defines one.
• The screen must preserve the dark metal / stone / leather material world and restrained gold trim used by the current Ashen Realms UI.
• Decorative elements must remain subordinate to information and interaction.
• Desktop is the primary target. Do not compromise the desktop composition to make it look like a mobile game.
• The final implementation must be visually compared side-by-side with the approved screenshot before the task is considered complete.

Visual acceptance target

At a 16:9 desktop viewport, the screen must read as one coherent Ashen Realms screen:

TopBar
┌─────────────┬──────────────────────────────────────────────────────────────┐
│             │ Character                                                   │
│             │                                                            │
│ Side        │ ┌──────────────────────────┐ ┌────────────────────────────┐ │
│ Navigation  │ │ Character + Equipment    │ │ Effective Character Stats  │ │
│             │ │                          │ ├────────────────────────────┤ │
│             │ │                          │ │ Fame / Reputation Progress │ │
│             │ └──────────────────────────┘ └────────────────────────────┘ │
│             │                                                            │
└─────────────┴──────────────────────────────────────────────────────────────┘
Footer

The character artwork is the visual anchor. The statistics and progression panels support it; they must not turn the page into a spreadsheet/dashboard.

---

2. Important progression semantics

The current Ashen Realms progression model is authoritative.

The project has moved away from a classic "kill monster → gain XP → level up" loop. The character page must therefore make Fame / Renown (Ruhm) and regional Reputation (Ruf) visibly replace the motivational role of the XP bar.

Do not reintroduce XP as the primary progression display if the current repository has already migrated to the Fame/Reputation model.

Required distinction

Global Fame / Renown (Ruhm)

This is the player's broad long-term progression track / world standing.

It must be shown prominently and continuously, similar to a classic XP bar:

RUHM
Ruhmstufe 4 – Bewährt
[██████████████████░░░░░░░░░░] 1,250 / 2,000
750 Ruhm bis Ruhmstufe 5

The exact rank names, thresholds, current values, and unlocks must come from the existing game data. The example above is presentation only.

Regional Reputation (Ruf)

Regional reputation is separate from global Fame and shows how trusted/respected the character is in individual regions or reputation domains.

Example presentation:

Aschenfelder
Respektiert
[██████████████░░░░░░░░] 720 / 1,000
Next: new Quartermaster offers

Again, the exact data and rank naming must come from the existing reputation system.

Motivation requirement

The player must be able to answer these questions at a glance:

1. What is my current Fame/Renown rank?
2. How far am I from the next Fame rank?
3. How much progress did I make since the last turn-in/session?
4. What regional reputation ranks do I currently have?
5. Which regional track is closest to the next rank?
6. What meaningful unlock comes next, if the current system exposes unlock information?

The page must therefore show exact current/required values in addition to the graphical bars. A bar without numbers is insufficient.

---

3. Screen layout

3.1 Existing shell

Do not create a special full-screen shell for the character page.

Keep the existing persistent structure:

• global TopBar
• left SideNavigation
• central main content
• Footer / status bar

Character is the active navigation item and must use the project's existing active-state treatment.

3.2 Main content proportions

For desktop, use a two-column composition inside the content area:

Left:  approximately 55–62 %
Right: approximately 38–45 %

The exact percentages may be adjusted to match existing shell dimensions, but the character must remain visually dominant.

3.3 Left column – character and equipment

The left panel contains:

• page title: Character / current localized equivalent
• full-body character artwork
• equipment slots arranged around the character
• item rarity/quality borders using the existing item visual language
• equipped-item tooltips using the existing item tooltip component if present

V1 equipment slots

The current V1 design defines these core slots:

Weapon
Helmet
Chest
Gloves
Legs
Boots
Amulet

Do not add Ring, Belt, Shoulder, Cape, or other slots only because they appeared in an early visual mockup. If the current repository's authoritative equipment model has changed since V1, use that model instead of duplicating slots.

Character artwork

• Use the existing player artwork for the selected character/sex/model.
• Keep the figure large enough that it remains one of the strongest elements on the page.
• Do not crop the weapon, feet, head, or silhouette unnecessarily.
• The background may use a subtle world/stone/dark atmospheric treatment, but it must not compete with the character.

3.4 Right column – effective stats

The upper right panel shows actual effective character values returned by the server.

Minimum values if present in the current model:

Health / Max Health
Attack
Weapon Damage
Armor

If the newer combat implementation already includes additional derived values such as Block Chance, Critical Chance, Dodge Chance, Counter effects, or similar set-derived combat stats, display them in a secondary Details group rather than hardcoding obsolete V1 assumptions.

Combat Power

The older balancing documentation describes Combat Power as an internal balancing tool. Do not expose Combat Power or invent an "equipment score" on this page unless the current authoritative design explicitly decided to make such a value player-facing.

3.5 Right column – Fame/Reputation panel

This is a core feature, not a footer detail.

Place it directly below the effective stats panel and keep at least the global Fame bar visible without scrolling at the primary desktop target.

Section A – Global Fame

The global Fame block must contain:

• progression icon / crest
• Fame / Renown / current localized term
• current Fame rank number
• current Fame rank title, if defined
• full-width progress bar
• exact current / required value
• exact remaining amount to next rank
• next rank title if available
• next unlock summary if the existing system provides one

Recommended visual weight:

• stronger than an individual regional reputation row
• gold / prestige accent from existing design tokens
• subtle highlight, no neon glow

Section B – Regional Reputation

Below the global track, show the player's currently relevant regional tracks.

Each row contains:

• region/reputation icon
• region/reputation name
• current reputation rank/title
• progress bar
• exact current / required
• optional next-unlock line

Order:

1. current region first
2. then other known/unlocked regions
3. locked/unknown regions should not be presented as fake progress rows unless the existing reputation system explicitly exposes them

Long lists

Do not allow 10+ reputation rows to destroy the screen composition.

For more tracks than fit comfortably:

• show the current region plus the next 2–4 most relevant tracks
• provide View all reputation / localized equivalent
• open a dedicated reputation view, drawer, or existing details screen if one exists

Do not solve this by making the entire character page an endlessly scrolling dashboard.

---

4. Progress bar visual specification

The progress bars are intentionally reminiscent of classic RPG XP progression while remaining within Ashen Realms' material language.

Global Fame bar

Target characteristics:

• dark recessed metal/stone track
• thin aged-metal border
• subtle inner shadow
• filled portion uses muted prestige gold / warm amber from existing design tokens
• optional very subtle textured fill
• no bright mobile-game gradient
• no rounded pill shape unless the existing UI already uses it
• exact numbers remain readable at all fill percentages

Regional Reputation bars

Use the same component and structure with lower visual emphasis.

If the project already defines reputation-specific colors, use them. Otherwise:

• positive/established reputation can use restrained green/gold accents
• neutral reputation can use muted bronze/grey
• hostile/negative reputation can use restrained red

Colors must never be the only indication of reputation state; always show the text rank/title.

Progress calculation

The client may calculate only the visual percentage from authoritative server values:

percentage = max > min
  ? Math.min(100, Math.max(0, ((current - min) / (max - min)) * 100))
  : 100;

Do not let the client decide rank thresholds, unlocks, or earned reputation.

---

5. Data model for the character page UI

Create a UI-facing view model so the template does not directly coordinate multiple raw API payloads.

export interface CharacterPageVm {
  character: CharacterSummaryVm;
  stats: EffectiveCharacterStatsVm;
  equipment: EquipmentSlotVm[];
  progression: CharacterProgressionVm;
}

export interface CharacterSummaryVm {
  id: string;
  name: string;
  portraitUrl: string;
  artworkUrl: string;
  currentHp: number;
  maxHp: number;
}

export interface EffectiveCharacterStatsVm {
  currentHp: number;
  maxHp: number;
  attack: number;
  weaponDamage: number;
  armor: number;
  details: CharacterDerivedStatVm[];
}

export interface CharacterDerivedStatVm {
  key: string;
  label: string;
  formattedValue: string;
}

export interface EquipmentSlotVm {
  slot: string;
  label: string;
  item: EquippedItemVm | null;
}

export interface EquippedItemVm {
  itemId: string;
  name: string;
  iconUrl: string;
  rarity: string;
}

export interface CharacterProgressionVm {
  fame: ProgressTrackVm;
  regionalReputation: ProgressTrackVm[];
}

export interface ProgressTrackVm {
  key: string;
  name: string;
  iconUrl?: string;
  rank: number;
  rankTitle: string;
  currentValue: number;
  rankStartValue: number;
  nextRankValue: number;
  nextRankTitle?: string;
  nextUnlockLabel?: string;
  state?: 'positive' | 'neutral' | 'negative';
}

If the current reputation implementation already exposes equivalent DTOs, map those DTOs into the view model instead of changing the domain model to match this UI type.

---

6. Data flow and server authority

Preferred flow:

CharacterPageComponent
        |
        v
CharacterPageFacade
   |       |       |
   v       v       v
Character  Equipment  Reputation/Fame services
   \       |       /
    \      |      /
     v     v     v
      CharacterPageVm
           |
           v
       Template

Rules:

• The backend owns character values, equipped items, Fame, regional reputation, rank thresholds, and unlock conditions.
• Angular only displays them and derives presentation-only percentages/formatting.
• Never award Fame/Reputation from the character page.
• Never duplicate rank threshold tables in the frontend.
• Never infer reputation from inventory contents or killed monsters in the client.

---

7. File structure

Before implementation, inspect the repository and reuse equivalent files that already exist. Do not create duplicates with slightly different names.

Target structure if the feature is not yet organized:

apps/web/src/app/features/character/
├── character-page/
│   ├── character-page.component.ts
│   ├── character-page.component.html
│   ├── character-page.component.scss
│   └── character-page.component.spec.ts
├── components/
│   ├── character-equipment-panel/
│   ├── character-stats-panel/
│   ├── reputation-progress-panel/
│   └── progress-track/
├── data-access/
│   ├── character-page.facade.ts
│   └── character-page.facade.spec.ts
└── models/
    └── character-page.vm.ts

Backend changes are only required if the current implemented Fame/Reputation system does not already expose the read data needed by this screen.

If a read endpoint is missing, place it in the existing reputation/fame module rather than in the Angular-specific character module.

Recommended read contract if no equivalent endpoint exists:

GET /api/reputation/me

Example response shape:

{
  "fame": {
    "key": "world-fame",
    "name": "Fame",
    "rank": 4,
    "rankTitle": "Proven",
    "currentValue": 1250,
    "rankStartValue": 1000,
    "nextRankValue": 2000,
    "nextRankTitle": "Known",
    "nextUnlockLabel": "New world reputation tier"
  },
  "regionalReputation": [
    {
      "key": "ashen-fields",
      "name": "Ashen Fields",
      "rank": 2,
      "rankTitle": "Respected",
      "currentValue": 720,
      "rankStartValue": 500,
      "nextRankValue": 1000,
      "nextRankTitle": "Trusted",
      "nextUnlockLabel": "Quartermaster offers"
    }
  ]
}

The example values and labels are placeholders for shape only; production data must come from the existing Fame/Reputation definitions.

---

8. Implementation tasks

Task 1: Audit existing character UI and design system

Files:

• Inspect: apps/web/src/app/layout/**
• Inspect: apps/web/src/app/shared/**
• Inspect: apps/web/src/app/features/character/**
• Inspect: apps/web/public/assets/ui/**
• Inspect: current reputation/fame frontend and backend modules
• Inspect: existing world, hunt, combat, and inventory SCSS/components

Interfaces:

• Consumes: existing AppShell/design system/reputation implementation

• Produces: a concrete reuse map before new UI code is added

• Step 1: Identify reusable shell components

Record the actual component selectors/classes for TopBar, SideNavigation, Footer, base Panel, button, tooltip, health bar, and item slot.

• Step 2: Identify design tokens and assets

Record the existing token names and file paths for panel backgrounds, borders, gold accents, text colors, active navigation treatment, and item rarity borders.

• Step 3: Identify existing Fame/Reputation APIs and DTOs

Search the repository for:

reputation
fame
renown
Ruhm
Ruf
world reputation
regional reputation

Use the existing implementation as source of truth.

• Step 4: Verify language strategy

Use the project's current localization/content language. Do not hardcode the German labels from the concept screenshot if the production UI has already moved to English.

• Step 5: Commit only if the audit required documentation changes

No production code should be changed just to complete the audit.

---

Task 2: Add character-page view model and facade

Files:

• Create or modify: apps/web/src/app/features/character/models/character-page.vm.ts
• Create or modify: apps/web/src/app/features/character/data-access/character-page.facade.ts
• Test: apps/web/src/app/features/character/data-access/character-page.facade.spec.ts

Interfaces:

• Consumes: current character/equipment/reputation data services

• Produces: CharacterPageFacade.vm$ or equivalent signal returning CharacterPageVm

• Step 1: Write the failing facade test

The test must verify that character, equipment, effective stats, global Fame, and regional reputation are combined into one CharacterPageVm.

• Step 2: Run the test and verify failure

Run the project's established Angular unit-test command for the character facade.

Expected: FAIL because the facade/view model does not yet exist or does not expose all required data.

• Step 3: Implement the minimal view-model mapping

Use the interfaces in section 5, adapted only where the existing domain model has authoritative names.

• Step 4: Keep authority on the server

Only format values and calculate visual percentages in the UI layer. Do not move reputation thresholds into the facade.

• Step 5: Run tests

Expected: PASS.

• Step 6: Commit

git add apps/web/src/app/features/character
git commit -m "feat: add character page view model"

---

Task 3: Implement reusable progress-track component

Files:

• Create or modify: apps/web/src/app/features/character/components/progress-track/progress-track.component.ts
• Create or modify: apps/web/src/app/features/character/components/progress-track/progress-track.component.html
• Create or modify: apps/web/src/app/features/character/components/progress-track/progress-track.component.scss
• Test: corresponding component spec

Interfaces:

• Consumes: ProgressTrackVm

• Produces: reusable visual track for global Fame and regional Reputation

• Step 1: Write tests for progress percentage

Cover at least:

current below start -> 0 %
current midway -> correct percentage
current above next threshold -> 100 %
next threshold equal to start -> 100 %

• Step 2: Implement clamped percentage calculation

const range = track.nextRankValue - track.rankStartValue;
const percentage = range <= 0
  ? 100
  : Math.min(
      100,
      Math.max(
        0,
        ((track.currentValue - track.rankStartValue) / range) * 100,
      ),
    );

• Step 3: Implement semantic template

The rendered component must expose:

track name
rank title
current / next threshold
remaining amount
visual bar
optional next unlock

• Step 4: Style with existing Ashen Realms assets/tokens

Do not invent a new generic progress bar. Reuse existing frame/background assets and token values where possible.

• Step 5: Verify visual states

Check 0 %, 5 %, 50 %, 95 %, and 100 % fills; text must remain readable.

• Step 6: Commit

git add apps/web/src/app/features/character/components/progress-track
git commit -m "feat: add fame reputation progress track"

---

Task 4: Implement Fame/Reputation panel

Files:

• Create or modify: apps/web/src/app/features/character/components/reputation-progress-panel/**
• Test: corresponding component spec

Interfaces:

• Consumes: CharacterProgressionVm

• Produces: prominent global Fame display plus regional reputation summary

• Step 1: Write rendering tests

Verify:

global Fame is rendered first
current Fame rank is visible
current/required values are visible
remaining amount is visible
current region reputation is first
more-than-limit case shows View all reputation action

• Step 2: Implement global Fame hero row

The global track must be visually stronger than individual regional rows.

• Step 3: Implement regional reputation rows

Use the reusable ProgressTrackComponent in compact mode.

• Step 4: Implement ordering

Current region first; then remaining relevant unlocked tracks.

• Step 5: Implement overflow behavior

Do not render an unbounded list in the main page. Use the existing details navigation/drawer pattern if one exists.

• Step 6: Commit

git add apps/web/src/app/features/character/components/reputation-progress-panel
git commit -m "feat: add character reputation panel"

---

Task 5: Implement character equipment composition

Files:

• Create or modify: apps/web/src/app/features/character/components/character-equipment-panel/**
• Reuse: existing item slot / tooltip components
• Test: corresponding component spec

Interfaces:

• Consumes: CharacterSummaryVm, EquipmentSlotVm[]

• Produces: character-artwork-centered equipment presentation

• Step 1: Write slot rendering tests

Verify that every authoritative equipment slot renders exactly once and empty slots render in the existing empty-slot style.

• Step 2: Render full-body character artwork

Preserve the visual prominence and silhouette from the approved screenshot.

• Step 3: Position equipment slots around the character

Use CSS Grid/absolute slot anchors only inside the equipment panel; do not disturb the global shell layout.

• Step 4: Reuse rarity borders and tooltips

No duplicate rarity styling.

• Step 5: Verify common viewport sizes

At the primary desktop viewport the artwork and all equipment slots must remain visible without overlap.

• Step 6: Commit

git add apps/web/src/app/features/character/components/character-equipment-panel
git commit -m "feat: add character equipment presentation"

---

Task 6: Implement effective character stats panel

Files:

• Create or modify: apps/web/src/app/features/character/components/character-stats-panel/**
• Test: corresponding component spec

Interfaces:

• Consumes: EffectiveCharacterStatsVm

• Produces: server-authoritative stat summary

• Step 1: Write rendering test

Verify HP, Attack, Weapon Damage, and Armor are rendered from inputs.

• Step 2: Add secondary derived-stat section

Render only values delivered by the current effective-stat model; no fake zeros for systems that do not exist.

• Step 3: Ensure no client-side stat authority

The component formats values only.

• Step 4: Ensure Combat Power remains hidden by default

Do not add Combat Power unless the current design explicitly exposes it.

• Step 5: Commit

git add apps/web/src/app/features/character/components/character-stats-panel
git commit -m "feat: add character stats panel"

---

Task 7: Compose the final character page

Files:

• Create or modify: apps/web/src/app/features/character/character-page/character-page.component.ts
• Create or modify: apps/web/src/app/features/character/character-page/character-page.component.html
• Create or modify: apps/web/src/app/features/character/character-page/character-page.component.scss
• Modify: route configuration only if /character does not already exist
• Test: character-page.component.spec.ts

Interfaces:

• Consumes: CharacterPageFacade, equipment panel, stats panel, reputation panel

• Produces: /character screen

• Step 1: Write page integration test

Verify the page contains all three major sections:

character/equipment
stats
Fame/Reputation

• Step 2: Compose the two-column desktop layout

Do not create nested dashboard cards beyond the visual hierarchy in the approved reference.

• Step 3: Reuse the existing AppShell

The character feature must occupy only the shell's main content outlet.

• Step 4: Add loading state

Use the existing Ashen Realms loading treatment; avoid generic Material spinners if they are not part of the established UI.

• Step 5: Add error state

Use the existing panel/message treatment and provide a retry action if the page data fails to load.

• Step 6: Run component tests

Expected: PASS.

• Step 7: Commit

git add apps/web/src/app/features/character
git commit -m "feat: implement character page"

---

Task 8: Add or adapt reputation read API only if required

Files:

• Prefer modify: existing reputation/fame controller/service/DTO files
• Test: existing reputation integration test location

Interfaces:

• Consumes: existing authoritative Fame/Reputation domain model

• Produces: read model required by CharacterPageFacade

• Step 1: Confirm whether existing API already provides all required fields

Required fields:

current Fame rank/title
current Fame value
current rank lower threshold
next Fame threshold/title
regional reputation current ranks
regional current values
regional thresholds
optional next unlock labels

• Step 2: If complete, make no backend change

Map the existing response in the frontend.

• Step 3: If incomplete, write a failing API test for the missing read fields

Do not change progression rules; expose existing authoritative data only.

• Step 4: Extend the existing read DTO/service minimally

Avoid a second reputation calculation path.

• Step 5: Run backend tests

Expected: PASS.

• Step 6: Commit only if backend code changed

git add apps/api
git commit -m "feat: expose character reputation progress"

---

Task 9: Visual fidelity pass

Files:

• Modify only the character feature SCSS/templates and shared design tokens/assets when justified

Interfaces:

• Consumes: approved reference screenshot and existing live Ashen Realms screens

• Produces: visually consistent final page

• Step 1: Open the implemented /character page at desktop resolution

Use the same browser zoom as the existing screenshots.

• Step 2: Compare side-by-side with the approved reference

Check:

shell proportions
panel materials
border style
font hierarchy
character scale
slot scale
right-column density
Fame bar prominence
regional reputation density
footer/topbar continuity

• Step 3: Compare side-by-side with at least one existing world/hunt/combat screen

The question is not only "does it match the mockup?" but also "does it still look like the same application?"

• Step 4: Remove generic-web artifacts

Reject and replace any element that looks like:

Material card
SaaS dashboard panel
mobile-game pill
flat grey button
neon progress bar
default HTML progress element

• Step 5: Verify information hierarchy

At first glance the eye should land on:

1. character
2. global Fame progress
3. equipment / core stats
4. regional reputation

• Step 6: Commit

git add apps/web
git commit -m "style: align character page with ashen realms ui"

---

Task 10: Final verification

Files:

• No new production files expected

Interfaces:

• Consumes: complete character page

• Produces: verified feature

• Step 1: Run frontend unit tests

Run the repository's complete web test suite.

Expected: PASS.

• Step 2: Run backend tests if the reputation API changed

Expected: PASS.

• Step 3: Run production build

npm run build

Expected: PASS.

• Step 4: Verify /character manually

Check:

active Character navigation
character artwork renders
equipment matches server state
item tooltips work
stats match server values
Fame progress numbers are exact
Fame percentage is correct
regional reputation is ordered correctly
no XP bar is shown as primary progression if XP has been replaced
no horizontal overflow
no important content overlap

• Step 5: Verify progression edge cases

Test with data representing:

0 % progress
nearly complete rank
exact rank threshold
newly entered rank
no regional reputation yet
one region
many regions
negative/hostile reputation if supported

• Step 6: Final commit

git add .
git commit -m "feat: complete character fame reputation page"

---

9. Acceptance criteria

The feature is complete only when all of the following are true:

• /character uses the existing Ashen Realms AppShell.
• Character is visibly active in the existing left navigation.
• The page uses the same material, border, icon, typography, spacing, and accent language as the approved screenshots.
• The character remains the primary visual element of the left half of the page.
• Equipped items use the actual server equipment state.
• The page displays the authoritative effective combat values; it does not recalculate them independently.
• Global Fame/Renown has a prominent XP-like progress bar with exact numbers.
• The player can see current rank, current progress, next threshold, and remaining progress without opening another screen.
• Regional Reputation is shown separately from global Fame.
• Current-region reputation is prioritized.
• Large reputation lists do not turn the page into a scrolling dashboard.
• No obsolete XP progression is reintroduced if the current Fame/Reputation system replaced it.
• No player-facing Combat Power/gear score is added unless the current game design explicitly requires it.
• No duplicate reputation domain logic exists in Angular.
• The page looks like the same product as the world, hunting, combat, and inventory screens when compared side-by-side.
• Frontend tests pass.
• Backend tests pass if backend code changed.
• Production build passes.

---

10. Explicit visual anti-goals

The implementation is rejected if it drifts into any of these directions:

Generic Angular Material dashboard
Bootstrap card grid
SaaS admin UI
Mobile-game character sheet
Bright glossy fantasy UI
Neon cyberpunk UI
Flat minimal black-and-grey UI
Retro 2000s browsergame table layout
Independent new design system just for Character

The target remains:

A modern premium dark-fantasy browser RPG, with classic MMORPG information density and a coherent Ashen Realms visual identity.

---

11. Implementation note for the coding agent

Before changing code, inspect the existing application and treat the current implementation as authoritative for:

component names
API paths
reputation domain names
rank thresholds
equipment slots
localization
combat stats
design tokens
shared assets

This plan defines the required behavior, information hierarchy, and visual result. It does not authorize replacing existing working systems merely because an example type or filename in this document differs from the current repository.

When the current repository and this document differ in naming but not in intent, adapt this plan to the existing architecture. When they differ in gameplay semantics, follow the current approved Fame/Reputation specification and preserve the visual/UX requirements defined here.