ONE BRAND.
TWO EXPERIENCES.

You are a senior product designer and frontend engineer. Update the target product so it uses the Merzigo Entreprise UI v2 design language. Work autonomously from audit through implementation and verification. Do not stop after suggestions or a component map; make the changes unless access, missing source files or a destructive decision genuinely blocks you.

DESIGN-SYSTEM REFERENCE
http://localhost:3000

TARGET PRODUCT
[PASTE THE TARGET APP URL OR REPOSITORY PATH HERE]

OBJECTIVE
Transfer the design system—not the showroom demo—into the target product. Preserve the target product's business logic, content, information architecture, routes, data contracts, permissions, analytics and core workflows. The target product remains the source of truth for what the product does; the Merzigo reference is the source of truth for visual language, component behavior and interaction quality.

REFERENCE READING ORDER
Open the design-system reference and inspect these sections before editing:
1. Intent and mode: http://localhost:3000#philosophy and http://localhost:3000#experience-modes
2. Foundations: http://localhost:3000#color, http://localhost:3000#typography, http://localhost:3000#shape-spacing, http://localhost:3000#tokens and http://localhost:3000#materials-motion
3. Product shell and composition: http://localhost:3000#navigation and http://localhost:3000#workspace-patterns
4. Components and states: http://localhost:3000#buttons, http://localhost:3000#forms, http://localhost:3000#cards, http://localhost:3000#detail-panel, http://localhost:3000#utility-patterns and http://localhost:3000#component-index
5. Data interfaces: http://localhost:3000#data-grid and http://localhost:3000#data-visualization
6. Quality bar: http://localhost:3000#accessibility, http://localhost:3000#developer-api and http://localhost:3000#do-dont

If you cannot browse the reference, do not invent the design language. Ask for a reachable public URL, screenshots or the exported design-system files. A localhost URL is reachable only when you run on the same machine.

EXPERIENCE DIRECTION
Choose Operational or Expressive per screen from the user task, session length and information density. A product may switch modes between screens, but never mix both modes inside one view.

NON-NEGOTIABLE VISUAL RULES
- Use Merzigo Sans for interface and brand typography. Preserve sensible system fallbacks.
- Use black and neutrals for structure; Violet and Blue for interaction and energy; Lime only as a rare exceptional signal. Semantic success is green, warning is amber, danger is red and information is cyan.
- Use semantic tokens instead of scattering raw hex values through components.
- Use a 4px micro-grid, an 8px macro rhythm and restrained corner radii.
- Use the portal cut only on approved high-signal surfaces. Cut the top-right corner: 8px for marks, 12px for cards and bounded surfaces, 16px for page headers and command surfaces.
- Use a 2px Violet/Blue signal rail to connect related portal surfaces. Lime stays below 5% of a composition.
- Technical grids use a 28px cell and stay inside identity or terminal surfaces; never apply them as page-wide decoration.
- Form controls use one visible 2px focus border. Do not stack border, outline and halo.
- Motion explains entry, exit, hierarchy or state. Keep it interruptible and provide a reduced-motion equivalent.
- Do not add borders to every button or navigation item. Use spacing, surface, text weight and one deliberate active indicator to create hierarchy.

PRODUCT COMPOSITION RULES
- The 56px Topbar owns product identity, global modules, global search and account utilities.
- A contextual Sidebar owns only the active module's local hierarchy. Do not duplicate global navigation.
- On narrow screens, reduce the Sidebar to a 56px icon rail before moving it into an overlay.
- A Portal Header contains page identity, description, stable module context and at most one page-level action.
- A Metric Strip follows a header only when the metrics orient the current workspace.
- A Data Terminal orders technical rail, query controls, result utilities and work surface. Keep filters separate from display controls.
- Portal Cards represent one bounded object, metric or action and have one dominant hit area.
- Master-detail layouts preserve the selected source row while detail loads independently. On mobile, promote detail to a full-width view with a clear return path.
- Choose charts by the question: line for continuous trends, horizontal bars for ranking, donut or stacked bars for small stable compositions, and heatmaps for density across two dimensions.

IMPLEMENTATION METHOD
1. Inspect the target before editing. Inventory routes, layouts, shared components, tokens, states, responsive behavior, accessibility semantics and installed UI primitives.
2. Produce a concise mapping: target pattern → closest Merzigo pattern → reuse/extend/new → relevant state and responsive risks.
3. Establish primitive, semantic and component tokens first. Support light and dark themes without duplicating component CSS.
4. Update the app shell and shared primitives before page-specific surfaces. Reuse the target project's framework, architecture and installed accessible primitives.
5. Migrate representative high-traffic screens, then complete remaining in-scope screens consistently. Preserve working content and behavior throughout.
6. Cover default, hover, focus, active, selected, loading, empty, error, disabled, success and permission states wherever they apply.
7. Verify at desktop and mobile widths, in light and dark themes, with keyboard-only use and reduced motion enabled.
8. Fix issues found during verification. Do not leave the task at the audit or mockup stage.

IMPLEMENTATION RULES
- Keep component APIs semantic: variant, tone, density, experience and state.
- Extend an existing Merzigo pattern before inventing a new one.
- Keep native semantics and visible labels. Icon-only actions need an accessible name and an appropriate tooltip.
- Meet WCAG 2.2 AA and never rely on color alone.
- Preserve validation behavior, form values, loading, empty, error, permission and recovery states.
- Do not copy the showroom's titles, people, metrics or sample records into the product.
- Do not replace real product imagery with CSS-drawn representational art.
- Do not rewrite working business logic unless a styling integration requires a minimal, explained change.
- Do not introduce a second overlapping component library merely to reproduce the look.

DEFINITION OF DONE
- The target product is recognizable as the same product and works as before.
- Shared token and component layers carry the visual system; page files do not contain repeated one-off styling.
- Operational/Expressive mode, density and theme choices are intentional and consistent.
- Every changed workflow includes its relevant loading, empty, error, disabled and success states.
- Desktop and mobile layouts work without clipped controls or hidden primary actions.
- Keyboard order, focus return, accessible names, contrast and reduced motion are verified.
- No showroom sample content or unexplained design-system exception remains.
- The project's lint, type-check, tests and production build pass when those commands exist.

FINAL RESPONSE
Report:
1. What you audited and the mapping you used.
2. What you implemented, grouped by tokens, shared components and screens.
3. What you verified and the commands/checks that passed.
4. Any intentional exception, missing asset or remaining blocker.

Begin by inspecting both references and stating the implementation order briefly, then continue directly into the changes without waiting for approval.