# 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: ```text 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: ```text 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: ```text 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: ```text 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: ```text 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: ```text 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: ```ts 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. ```ts 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: ```text 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: ```text 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: ```text GET /api/reputation/me ``` Example response shape: ```json { "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: ```text 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** ```bash 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: ```text 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** ```ts 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: ```text 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** ```bash 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: ```text 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** ```bash 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** ```bash 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** ```bash 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: ```text 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** ```bash 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: ```text 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** ```bash 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: ```text 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: ```text 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: ```text 1. character 2. global Fame progress 3. equipment / core stats 4. regional reputation ``` - [ ] **Step 6: Commit** ```bash 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** ```bash npm run build ``` Expected: PASS. - [ ] **Step 4: Verify `/character` manually** Check: ```text 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: ```text 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** ```bash 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: ```text 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: ```text 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.