# UI.md — Admin Panel UI Redesign and Full Style Migration Prompt

## Role

Act as a Senior Laravel 12 Frontend Architect, UI/UX Designer, Bootstrap 5 Expert, Tailwind CSS Expert, and Code Auditor.

Inspect my existing Laravel Admin Panel and completely migrate its current user interface to a new reusable design system based on this reference website:

```text
https://piseth.phpcode.shop/home
```

Reference login:

```text
Email: owner@gmail.com
Password: 123456
```

Use the account only to log in and visually review the reference UI. Do not create, edit, delete, approve, cancel, or otherwise modify any records on the reference website.

Use the reference website only for visual and UX guidance. Do not copy proprietary source code.

---

# Project Stack

```text
Backend Framework: Laravel 12
Backend Language: PHP 8.2+
Frontend: Laravel Blade
CSS Framework: Bootstrap 5 or Tailwind CSS

Framework selection rule:
- Inspect the current project and select only one framework for the redesigned admin panel.
- Use Bootstrap 5 when the project already depends mainly on Bootstrap, jQuery, Yajra DataTables, or Bootstrap plugins.
- Use Tailwind CSS when the project already depends mainly on Tailwind and converting to Bootstrap would create unnecessary risk.
- Do not mix Bootstrap 5 and Tailwind CSS in the redesigned admin interface.
- Do not keep two competing utility or component systems.
- Clearly state which framework was selected before implementation and explain why.
JavaScript: Vanilla JavaScript, jQuery, and AJAX where required
Data Tables: Yajra Laravel DataTables
Charts: Chart.js
Authentication: Existing authentication system or Laravel Sanctum
Icons: Bootstrap Icons or Lucide Icons
```

Do not mix Bootstrap and Tailwind in the same admin interface unless the current project already requires both and removing one would break existing functionality.

---

# Main Objective

Completely remove the existing admin-panel layout and visual style, then rebuild the interface with one new, clean, consistent, responsive, and reusable UI system.

The old layout must not remain active underneath the new design. Do not merely override the current theme with additional CSS. Replace the old layout structure, old component markup, old theme classes, and old visual assets after their functionality has been safely migrated.

The new UI must follow the reference website in:

- Layout
- Sidebar
- Top navigation
- Typography
- Colors
- Spacing
- Cards
- Forms
- Inputs
- Select boxes
- Searchable selects
- Search boxes
- Date and date-time controls
- Buttons
- Dropdowns
- DataTables
- Filters
- Badges
- Modals
- Alerts
- Pagination
- Empty states
- Loading states
- Hover states
- Focus states
- Active menu states
- Responsive behavior

The final application must look like one unified admin template instead of separate pages with different styles.

# Reference Page Matching Requirements

The reference page is the primary visual source of truth.

Codex must review and reproduce the reference page's design direction, including:

- Primary color
- Secondary and neutral colors
- Background colors
- Text colors
- Sidebar colors
- Active menu colors
- Button colors
- Border colors
- Status colors
- Typography appearance
- Font weights
- Font sizes
- Spacing rhythm
- Border radius
- Card style
- Shadow intensity
- Input appearance
- Table appearance
- Navigation hierarchy
- Responsive behavior

Do not invent an unrelated color palette when the reference page can be inspected.

Before implementation:

1. Review the reference login and authenticated admin pages.
2. Extract the visible design characteristics.
3. Document the observed colors and component styles.
4. Create centralized design tokens based on those observations.
5. Use those tokens across all pages and reusable components.

When an exact color cannot be reliably determined, select the closest accessible color that visually matches the reference page and document the approximation.

The reference website must only be reviewed. Do not create, edit, delete, approve, cancel, publish, or modify any data.

---

# Critical Full Layout and Style Replacement Rule

Remove the existing layout and visual design, then replace them with the new reusable design system based on the reference page.

This means:

1. Audit every existing stylesheet, JavaScript UI plugin, Blade layout, partial, and component.
2. Identify all old theme classes, legacy UI utilities, duplicated component styles, inline CSS, and page-specific styling.
3. Remove the old master layout structure after mapping all dependencies.
4. Replace the old sidebar, topbar, footer, page wrapper, content wrapper, and authentication layout.
5. Replace old layout markup with the new reusable admin layout.
6. Replace old component markup with reusable Blade components.
5. Remove obsolete styles only after all references have been safely migrated.
6. Do not leave old and new design systems active at the same time.
7. Do not keep unused theme CSS, duplicate Bootstrap overrides, abandoned component classes, or dead UI JavaScript.
8. Do not remove functional JavaScript that is required by AJAX, DataTables, forms, modals, validation, permissions, or business logic.
9. Do not blindly delete CSS or JavaScript before checking where it is used.
10. Preserve backend behavior while replacing frontend presentation.

The goal is a controlled migration, not an unsafe deletion.

After migration, no admin page may extend the old layout, load the old theme stylesheet, use the old sidebar or topbar, or depend on obsolete theme classes.

---

# Legacy Style Removal Process

Before removing existing styles, perform these steps.

## Step 1: Inventory

Find and list:

- Main admin layout files
- Authentication layout files
- Sidebar partials
- Topbar partials
- Footer partials
- Existing Blade components
- Theme CSS files
- Custom CSS files
- Page-specific CSS
- Inline `<style>` blocks
- Inline `style=""` attributes
- JavaScript UI files
- DataTable initialization scripts
- Select2, Choices.js, Tom Select, date-picker, modal, toast, and chart plugins
- Vite entry files
- Mix entry files if the project still uses Laravel Mix
- CDN styles and scripts
- Repeated UI markup

## Step 2: Usage Mapping

For each existing style or script:

- Find all files that reference it.
- Determine whether it is visual-only or functionally required.
- Mark it as:
  - Keep
  - Refactor
  - Replace
  - Remove after migration

## Step 3: Migration

- Build the new shared design foundation first.
- Migrate layouts before individual pages.
- Migrate reusable components before page-specific markup.
- Replace legacy classes page by page.
- Confirm each migrated page works before removing old assets.

## Step 4: Cleanup

After all pages are migrated:

- Remove unused CSS files.
- Remove unused JavaScript UI files.
- Remove obsolete CDN imports.
- Remove duplicated component styles.
- Remove dead Blade partials.
- Remove unused classes.
- Remove old theme assets.
- Remove unnecessary `!important`.
- Remove inline CSS.
- Confirm that no removed asset is still referenced.

## Step 5: Verification

Run searches for:

```text
old theme class names
old stylesheet filenames
old JavaScript filenames
inline style=
<style>
unused component names
obsolete asset paths
```

Do not declare cleanup complete until these searches are reviewed.

---

# Safety Rules

1. Do not change backend business logic.
2. Do not change database tables or columns.
3. Do not break routes, controllers, models, services, policies, middleware, validation, or API responses.
4. Do not remove features.
5. Do not remove permission checks.
6. Do not remove CSRF protection.
7. Do not change form methods.
8. Do not change route names unless required and approved.
9. Preserve all existing CRUD behavior.
10. Preserve AJAX behavior.
11. Preserve Yajra DataTable server-side processing.
12. Preserve filters, exports, and bulk actions that already exist.
13. Preserve authentication and authorization.
14. Do not add fake data.
15. Do not use placeholder implementations.
16. Do not modify records on the reference website.
17. Create a backup or Git checkpoint before deleting legacy assets.
18. Use small, reviewable changes.

---

# Design Direction

The new UI must be:

```text
Modern
Clean
Minimal
Professional
Lightweight
Spacious
Enterprise-ready
SaaS-style
Consistent
Accessible
Responsive
Reusable
Maintainable
```

Primary inspiration:

- Provided reference website
- Linear
- Stripe Dashboard
- Vercel Dashboard
- TailAdmin
- Flowbite Admin
- Notion

The provided reference website remains the main visual guide.

---

# Typography

Use:

```css
font-family: Inter, "Segoe UI", Roboto, Helvetica, Arial, sans-serif;
```

Font weights:

```text
Page title: 700
Section title: 600
Card title: 600
Table header: 600
Form label: 500
Sidebar menu: 500
Button: 600
Body: 400
Helper text: 400
```

Font sizes:

```text
Page title: 26px–28px
Section title: 20px–22px
Card title: 16px–18px
Dashboard value: 28px–32px
Body: 14px
Sidebar: 14px
Input: 14px
Table: 14px
Description: 13px
Small text: 12px
```

---

# Centralized Design Tokens

Create one central token source.

```css
:root {
    --admin-primary: #2563eb;
    --admin-primary-hover: #1d4ed8;
    --admin-primary-light: #eff6ff;

    --admin-background: #f8fafc;
    --admin-surface: #ffffff;
    --admin-surface-muted: #f1f5f9;

    --admin-text-primary: #0f172a;
    --admin-text-secondary: #64748b;
    --admin-text-muted: #94a3b8;
    --admin-placeholder: #9ca3af;

    --admin-border: #e2e8f0;
    --admin-divider: #f1f5f9;

    --admin-success: #22c55e;
    --admin-success-light: #dcfce7;
    --admin-warning: #f59e0b;
    --admin-warning-light: #fef3c7;
    --admin-danger: #ef4444;
    --admin-danger-light: #fee2e2;
    --admin-info: #0ea5e9;
    --admin-info-light: #dbeafe;

    --admin-radius-sm: 6px;
    --admin-radius-md: 8px;
    --admin-radius-lg: 12px;

    --admin-shadow-sm: 0 1px 3px rgba(15, 23, 42, 0.06);
    --admin-shadow-md: 0 4px 12px rgba(15, 23, 42, 0.08);

    --admin-transition: 0.2s ease;
}
```

Never hardcode repeated design values across page files.

All reusable components must consume the same tokens.

---

# Reusable Architecture

Create reusable Blade components under:

```text
resources/views/components/admin/
```

Required components:

```text
layout
sidebar
sidebar-item
sidebar-group
topbar
page-header
breadcrumb
card
dashboard-card
chart-card
button
icon-button
action-button
form-group
form-error
input
textarea
select
searchable-select
search-box
date-picker
date-time-picker
checkbox
radio
switch
badge
status-badge
alert
toast
modal
confirm-delete
dropdown
actions-dropdown
datatable
datatable-toolbar
filter-panel
pagination
empty-state
loading-spinner
image-upload
file-upload
```

Every component must support, where applicable:

- Attributes
- Slots
- Variants
- Sizes
- Required state
- Disabled state
- Read-only state
- Validation errors
- Helper text
- Icons
- Loading state
- Accessibility attributes
- Responsive behavior

Do not duplicate the same button, input, card, badge, modal, dropdown, or DataTable markup across multiple pages.

---

# Reusability Enforcement

When the same UI pattern appears two or more times, create or reuse a shared component.

Do not:

- Copy and paste form controls.
- Create page-specific button styles.
- Create separate select styles for each module.
- Create different card markup for every page.
- Repeat modal HTML.
- Repeat action dropdown HTML.
- Repeat DataTable toolbars.
- Repeat validation error markup.
- Repeat status badge conditions across views.

Prefer:

```blade
<x-admin.button />
<x-admin.input />
<x-admin.select />
<x-admin.searchable-select />
<x-admin.card />
<x-admin.status-badge />
<x-admin.actions-dropdown />
<x-admin.modal />
<x-admin.datatable-toolbar />
```

Use PHP enums, view models, helpers, or component properties when status presentation logic is repeated.

---

# Layout Structure

Create a reusable master layout:

```text
resources/views/layouts/admin.blade.php
```

Structure:

```text
Admin Wrapper
├── Sidebar
├── Main Area
│   ├── Top Navigation
│   ├── Page Content
│   │   ├── Breadcrumb
│   │   ├── Page Header
│   │   └── Page Body
│   └── Footer
```

Example:

```blade
<div class="admin-layout">
    <x-admin.sidebar />

    <div class="admin-main">
        <x-admin.topbar />

        <main class="admin-content">
            @yield('content')
        </main>
    </div>
</div>
```

All admin pages must extend or use the same layout.

---

# Component Style Standards

## Buttons

```text
Height: 42px–44px
Padding: 10px 16px
Font size: 14px
Font weight: 600
Border radius: 8px
Transition: 0.2s ease
```

Variants:

```text
primary
secondary
success
warning
danger
light
outline
```

Sizes:

```text
sm
md
lg
```

Support icons, loading, disabled, links, and submit buttons through one component.

## Form Controls

```text
Height: 44px
Border: 1px solid #D1D5DB
Border radius: 8px
Background: #FFFFFF
Text: #0F172A
Placeholder: #9CA3AF
Font size: 14px
Padding: 10px 12px
```

Focus:

```text
Border: #2563EB
Box shadow: 0 0 0 3px rgba(37, 99, 235, 0.12)
```

Error:

```text
Border: #EF4444
Error text: #DC2626
Error size: 12px
```

Normal select and searchable select must share the same visual style.

## Cards

```text
Background: #FFFFFF
Border: 1px solid #E2E8F0
Border radius: 12px
Shadow: 0 1px 3px rgba(15, 23, 42, 0.06)
Padding: 20px–24px
```

## Badges

```text
Font size: 12px
Font weight: 600
Padding: 4px 9px
Border radius: 999px
```

## DataTables

All Yajra DataTables must use one reusable structure for:

- Toolbar
- Search
- Page size
- Filters
- Reset filters
- Export actions
- Add action
- Bulk actions
- Loading state
- Empty state
- Error state
- Pagination
- Responsive overflow
- Row actions

Table style:

```text
Header background: #F8FAFC
Header text: #334155
Header weight: 600
Row text: #475569
Border: #E2E8F0
Cell padding: 14px–16px
Row hover: #F8FAFC
```

## Sidebar

```text
Expanded width: 250px–270px
Collapsed width: 72px–80px
Background: #FFFFFF
Border right: 1px solid #E2E8F0
Menu height: 42px–44px
Menu radius: 8px
Menu font: 14px / 500
Icon size: 18px–20px
```

Active menu:

```text
Background: #EFF6FF
Text and icon: #2563EB
```

## Topbar

```text
Height: 68px–72px
Background: #FFFFFF
Border bottom: 1px solid #E2E8F0
Position: sticky
Top: 0
```

---

# Framework Implementation Rules

## When Bootstrap 5 Is Selected

Use:

- Bootstrap 5 grid
- Bootstrap spacing and display utilities
- Bootstrap offcanvas for mobile sidebar where appropriate
- Bootstrap dropdowns and modals
- Bootstrap-compatible Yajra DataTables styling
- Custom CSS variables for the reference-page colors and dimensions
- Reusable Blade components wrapping Bootstrap markup

Do not rely on the default Bootstrap appearance alone. Customize Bootstrap through centralized variables and component styles so the result matches the reference page.

## When Tailwind CSS Is Selected

Use:

- Tailwind configuration for colors, typography, spacing, shadows, radius, and breakpoints
- Reusable Blade components
- Extracted component classes where repeated patterns exist
- Accessible headless behavior for dropdowns, dialogs, and searchable selects
- Tailwind-compatible DataTable wrappers and controls

Do not place large repeated utility strings throughout every page. Encapsulate recurring patterns in Blade components.

## Prohibited

- Mixing Bootstrap buttons with Tailwind form components
- Loading both complete frameworks for the same admin UI
- Keeping old theme CSS as a fallback
- Creating separate styling systems for different modules
- Using page-specific design palettes
- Overriding the old layout instead of replacing it

---

# CSS Organization

Preferred structure:

```text
resources/css/admin/
    variables.css
    reset.css
    layout.css
    sidebar.css
    topbar.css
    components.css
    forms.css
    tables.css
    dashboard.css
    utilities.css
    responsive.css
```

Alternatively, use one structured `admin.css` when appropriate.

Rules:

- No page-level duplicated styles.
- No inline CSS.
- No repeated color values.
- No unnecessary `!important`.
- No legacy theme overrides after migration.
- No multiple competing button or input systems.
- No unused styles in production bundles.

---

# JavaScript Organization

Create reusable modules for:

```text
Sidebar toggle
Responsive navigation
Dropdowns
Searchable selects
Date pickers
DataTable filters
Delete confirmation
Modal lifecycle
Button loading states
Form submission
Image preview
File upload
AJAX requests
Toast messages
Chart initialization
```

Do not duplicate initialization scripts inside every Blade view.

Use `data-*` attributes and reusable initializers where practical.

---

# Page Migration Order

Migrate in this order:

```text
1. Authentication layout
2. Master admin layout
3. Sidebar
4. Topbar
5. Page header and breadcrumb
6. Shared buttons
7. Shared form controls
8. Shared cards
9. Shared badges
10. Shared modals and dropdowns
11. Shared DataTable system
12. Dashboard
13. Category
14. Subcategory
15. Brand
16. Unit
17. Product
18. Shipping Method
19. Order
20. Payment
21. User
22. Role and Permission
23. CMS
24. FAQ
25. Slider
26. Reports
27. Profile
28. Settings
```

Only migrate modules that exist.

---

# Required Implementation Phases

## Phase 1: Audit

Produce:

- Existing layout map
- Current asset list
- Legacy style list
- Existing component list
- Duplicate UI report
- Functional JavaScript dependencies
- Files safe to remove later
- Migration risks

Do not delete files in this phase.

## Phase 2: New Design Foundation

Create:

- Design tokens
- Typography
- Spacing system
- New admin layout
- New sidebar
- New topbar
- Base responsive behavior

## Phase 3: Reusable Components

Create and test all shared components before broad page migration.

## Phase 4: Page Migration

Migrate one module at a time.

For each module:

1. Preserve its backend integration.
2. Replace legacy markup.
3. Use shared components.
4. Remove its page-specific styling.
5. Test desktop, tablet, and mobile.
6. Test validation, AJAX, permissions, and DataTables.

## Phase 5: Legacy Cleanup

Only after migration:

- Remove old theme CSS.
- Remove old theme JavaScript.
- Remove unused plugins.
- Remove duplicate assets.
- Remove dead Blade files.
- Remove inline styles.
- Remove obsolete classes.
- Update Vite entry points.

## Phase 6: Regression Testing

Verify:

- Login
- Logout
- Permissions
- Navigation
- CRUD
- Validation
- AJAX
- DataTables
- Filters
- Search
- Pagination
- Modals
- File uploads
- Charts
- Responsive layout
- Browser console
- Build process

---

# Definition of Done

The migration is complete only when:

- All admin pages use one new master layout.
- Authentication pages use the new authentication layout.
- The old sidebar, topbar, footer, wrappers, and page structure are removed.
- All repeated UI is implemented through reusable components.
- Exactly one CSS framework is used for the redesigned admin interface.
- No page uses the old theme styling.
- No old theme CSS is loaded.
- No obsolete UI JavaScript is loaded.
- No important backend behavior is changed.
- No broken routes exist.
- No JavaScript errors exist.
- No console errors exist.
- No missing assets exist.
- All forms show consistent validation.
- All tables follow the same style.
- All pages are responsive.
- Accessibility focus states are visible.
- The production asset build succeeds.
- Unused legacy files are removed.
- A final list of removed files is provided.

---

# Required Codex Output

Before coding, provide:

```text
1. Audit findings
2. Current design-system problems
3. Legacy files and classes found
4. Functional dependencies that must remain
5. Proposed reusable component architecture
6. Migration plan
7. Risks
```

For every implementation step, provide:

```text
1. Files created
2. Files modified
3. Files removed
4. Reason for each change
5. Backend functionality preserved
6. Reusable components used
7. Testing completed
8. Remaining work
```

At completion, provide:

```text
1. Completed components
2. Completed pages
3. Legacy assets removed
4. Reusability improvements
5. Responsive improvements
6. Accessibility improvements
7. Known limitations
8. Manual testing checklist
9. Final file-change summary
```

---

# Start Task

Begin by auditing the existing project.

Do not immediately delete or rewrite everything.

First, inspect the project and select either Bootstrap 5 or Tailwind CSS. State the selected framework and the reason for the choice.

Then review the reference page and document its visible color system, typography, spacing, layout, cards, forms, tables, and navigation style.

After that:

1. Locate the current admin and authentication layouts.
2. Locate sidebar, topbar, footer, and shared partials.
3. Locate all CSS and JavaScript entry points.
4. Locate old theme files and third-party UI plugins.
5. Locate inline CSS and page-specific style blocks.
6. Locate reusable Blade components.
7. Locate repeated markup.
8. Locate all DataTable and form pages.
9. Map which styles and scripts are functionally required.
10. Create a safe removal and migration plan.
11. Create the new design foundation.
12. Migrate shared components.
13. Migrate the Dashboard first.
14. Continue module by module.
15. Remove old styles only after every reference has been replaced.

Do not stop after merely adding new CSS over the old theme.

The old visual design must be fully retired, and the application must use only the new reusable design system.

---

# Design System Specification (Selected: Option 1 - Clean Minimalist SaaS Style with Able Pro Preset-6 Color Theme)

The design system has been audited and finalized based on **Option 1 (Clean Minimalist SaaS Style)** styled with the **Able Pro Preset-6 Color Theme** audited from `http://127.0.0.1:8001/`.

## Visual Specifications
- **Framework:** Tailwind CSS
- **Theme Color Palette:**
  - Primary Accent: Deep Teal / Sea Green (`#2ca58d` / `var(--primary-color)`)
  - Primary Hover: Vibrant Dark Teal (`#21937a` / `var(--primary-hover-color)`)
  - Light Primary Tint: Teal Light Tint (`#eaf6f4` / `var(--primary-light-color)`)
  - Base Background: Light Slate / Blue-gray (`#eef2f6` / `var(--background-color)`)
  - Primary Headings: Deep Navy (`#0a2342` / `var(--heading-color)`)
  - Primary Text: Slate Gray (`#334155` / `var(--text-color)`)
  - Subtle Borders: Light Gray (`#E2E8F0` / `var(--border-color)`)
- **Key Layout & Component Rules:**
  - Input fields must share a height of `35px` with a border-radius of `6px` (`border-radius: 6px`), a white background (`#ffffff`), border line style (`1px solid #ced4da`), and light typography weight (`300`). Buttons share the `35px` height, `5px` border-radius, and light weight (`300`).
  - Cards use a border-radius of `8px` and a soft drop shadow (`shadow-soft`).
  - Search controls feature left-aligned magnifying glass prefix icons and right-aligned clear buttons.
  - Action buttons must adhere to the standardized semantic icons and backgrounds (Add/Success, Edit/Warning, Delete/Danger, Back/Info).
  - Toast alerts reside in a fixed top-right viewport stack.
  - Tables utilize dynamic, AJAX-driven DataTables with Excel export and Column Settings checkboxes togglers.
