UI 전체 리디자인 및 개선사항 적용

## 주요 변경사항:

### UI/UX 개선
- shadcn/ui 스타일 기반의 새로운 디자인 시스템 도입
- 모든 주요 화면에 대한 리디자인 구현 완료
  - 로그인 화면: 모던한 카드 스타일 적용
  - 대시보드: 통계 카드와 차트를 활용한 개요 화면
  - 리스트 화면들: 일관된 테이블 디자인과 검색/필터 기능
- 다크모드 지원을 위한 테마 시스템 구축

### 기능 개선
- Equipment List: 고급 필터링 (상태, 담당자별)
- Company List: 검색 및 정렬 기능 강화
- User List: 역할별 필터링 추가
- License List: 만료일 기반 상태 표시
- Warehouse Location: 재고 수준 시각화

### 기술적 개선
- 재사용 가능한 컴포넌트 라이브러리 구축
- 일관된 코드 패턴 가이드라인 작성
- 프로젝트 구조 분석 및 문서화

### 문서화
- 프로젝트 분석 문서 추가
- UI 리디자인 진행 상황 문서
- 코드 패턴 가이드 작성
- Equipment 기능 격차 분석 및 구현 계획

### 삭제/리팩토링
- goods_list.dart 제거 (equipment_list로 통합)
- 불필요한 import 및 코드 정리

🤖 Generated with [Claude Code](https://claude.ai/code)

Co-Authored-By: Claude <noreply@anthropic.com>

.cursor/rules/_ui_improvement.mdc

@@ -0,0 +1,123 @@
+---
+description : nothing
+globs: 
+alwaysApply : true
+---
+
+
+# UI 개선 작업 규칙
+
+## **모델 정의 우선 확인**
+- UI 화면에서 사용하는 모든 필드가 모델에 정의되어 있는지 확인
+- enum 타입이 필요한 경우 적절히 정의하고 import
+- nullable 타입은 UI에서 적절히 처리
+
+## **컨트롤러 메서드 확인**
+- 화면에서 호출하는 모든 메서드가 컨트롤러에 정의되어 있는지 확인
+- 메서드 매개변수 개수와 타입이 일치하는지 확인
+- 비동기 메서드의 경우 await 키워드 사용 확인
+
+## **테마 시스템 활용**
+- `ShadcnTheme.borderRadius` 대신 `ShadcnTheme.radiusMd` 사용
+- 정의되지 않은 테마 속성 사용 금지
+- 일관된 spacing 시스템 활용
+
+## **테이블 레이아웃 최적화**
+```dart
+// ✅ DO: 전체 폭 활용과 행 높이 최적화
+Expanded(
+  child: Container(
+    width: double.infinity,
+    decoration: BoxDecoration(
+      border: Border.all(color: ShadcnTheme.border),
+      borderRadius: BorderRadius.circular(ShadcnTheme.radiusMd),
+    ),
+    child: Column(
+      children: [
+        // 테이블 헤더
+        Container(
+          padding: const EdgeInsets.symmetric(
+            horizontal: ShadcnTheme.spacing4,
+            vertical: ShadcnTheme.spacing3,
+          ),
+          decoration: BoxDecoration(
+            color: ShadcnTheme.muted.withOpacity(0.3),
+            border: Border(
+              bottom: BorderSide(color: ShadcnTheme.border),
+            ),
+          ),
+          // ... 헤더 내용
+        ),
+        // 테이블 데이터
+        // ... 데이터 내용
+      ],
+    ),
+  ),
+)
+
+// ❌ DON'T: ShadcnCard 사용으로 공간 낭비
+ShadcnCard(
+  child: Column(
+    children: [
+      Container(
+        padding: const EdgeInsets.all(ShadcnTheme.spacing4),
+        // ... 내용
+      ),
+    ],
+  ),
+)
+```
+
+## **Null Safety 처리**
+```dart
+// ✅ DO: nullable 타입 적절히 처리
+onPressed: item.id != null ? () => deleteItem(item.id!) : null,
+
+// ❌ DON'T: nullable 타입을 non-nullable로 직접 전달
+onPressed: () => deleteItem(item.id), // item.id가 int?인 경우 오류
+```
+
+## **사용자 역할/상태 처리**
+```dart
+// ✅ DO: 실제 모델 필드 기반 처리
+Widget _buildUserRoleBadge(String role) {
+  switch (role) {
+    case 'S':
+      return ShadcnBadge(text: '관리자', variant: ShadcnBadgeVariant.destructive);
+    case 'M':
+      return ShadcnBadge(text: '멤버', variant: ShadcnBadgeVariant.primary);
+    default:
+      return ShadcnBadge(text: '사용자', variant: ShadcnBadgeVariant.outline);
+  }
+}
+
+// ❌ DON'T: 정의되지 않은 enum 사용
+Widget _buildUserRoleBadge(UserRole role) {
+  switch (role) {
+    case UserRole.admin: // UserRole이 정의되지 않은 경우 오류
+      // ...
+  }
+}
+```
+
+## **렌더링 오류 방지**
+- 복잡한 위젯 대신 안정적인 Container 사용
+- 데이터 없음 상태에 대한 적절한 UI 제공
+- 긴 텍스트는 overflow 처리 (`TextOverflow.ellipsis`)
+
+## **파일 구조 완성도 확인**
+- 모든 괄호, 중괄호가 올바르게 닫혔는지 확인
+- 필요한 import 문이 모두 포함되었는지 확인
+- Dart 문법 규칙 준수
+
+## **성능 최적화**
+- 테이블 행 높이 최적화: `spacing3` 사용
+- 불필요한 버튼 제거 (새로고침 등)
+- 중복 제목 제거
+- 공간 효율성 극대화
+
+이 규칙들을 따르면 UI 개선 작업 시 발생할 수 있는 대부분의 문제들을 사전에 방지할 수 있습니다.
+description:
+globs:
+alwaysApply: false
+---

.cursor/rules/cursor-step-by-step-rule.mdc

@@ -1,10 +1,5 @@
 ---
-description: 
-globs: 
-alwaysApply: true
----
----
-description: 
+description : something. 
 globs: 
 alwaysApply: true
 ---

.cursor/rules/cursor_rules.mdc

@@ -4,8 +4,8 @@ globs: .cursor/rules/*.mdc
 alwaysApply: true
 ---
 
+```markdown
 - **Required Rule Structure:**
-  ```markdown
   ---
   description: Clear, one-line description of what the rule enforces
   globs: path/to/files/*.ext, other/path/**/*

.cursor/rules/dev_flutter.mdc

@@ -1,133 +0,0 @@
----
-description: 
-globs: 
-alwaysApply: true
----
-You are a senior Dart programmer with experience in the Flutter framework and a preference for clean programming and design patterns.
-
-Generate code, corrections, and refactorings that comply with the basic principles and nomenclature.
-
-## Dart General Guidelines
-
-### Basic Principles
-
-- Use English for all code
-- Use Korean for all comments in code,requests,answers and documentation.
-- Always declare the type of each variable and function (parameters and return value).
-- Avoid using any.
-- Create necessary types.
-- Don't leave blank lines within a function.
-- One export per file.
-
-### Nomenclature
-
-- Use PascalCase for classes.
-- Use camelCase for variables, functions, and methods.
-- Use underscores_case for file and directory names.
-- Use UPPERCASE for environment variables.
-- Avoid magic numbers and define constants.
-- Start each function with a verb.
-- Use verbs for boolean variables. Example: isLoading, hasError, canDelete, etc.
-- Use complete words instead of abbreviations and correct spelling.
-- Except for standard abbreviations like API, URL, etc.
-- Except for well-known abbreviations:
-- i, j for loops
-- err for errors
-- ctx for contexts
-- req, res, next for middleware function parameters
-
-### Functions
-
-- In this context, what is understood as a function will also apply to a method.
-- Write short functions with a single purpose. Less than 20 instructions.
-- Name functions with a verb and something else.
-- If it returns a boolean, use isX or hasX, canX, etc.
-- If it doesn't return anything, use executeX or saveX, etc.
-- Avoid nesting blocks by:
-- Early checks and returns.
-- Extraction to utility functions.
-- Use higher-order functions (map, filter, reduce, etc.) to avoid function nesting.
-- Use arrow functions for simple functions (less than 3 instructions).
-- Use named functions for non-simple functions.
-- Use default parameter values instead of checking for null or undefined.
-- Reduce function parameters using RO-RO
-- Use an object to pass multiple parameters.
-- Use an object to return results.
-- Declare necessary types for input arguments and output.
-- Use a single level of abstraction.
-
-### Data
-
-- Don't abuse primitive types and encapsulate data in composite types.
-- Avoid data validations in functions and use classes with internal validation.
-- Prefer immutability for data.
-- Use readonly for data that doesn't change.
-- Use as const for literals that don't change.
-
-### Classes
-
-- Follow SOLID principles.
-- Prefer composition over inheritance.
-- Declare interfaces to define contracts.
-- Write small classes with a single purpose.
-- Less than 200 instructions.
-- Less than 10 public methods.
-- Less than 10 properties.
-
-### Exceptions
-
-- Use exceptions to handle errors you don't expect.
-- If you catch an exception, it should be to:
-- Fix an expected problem.
-- Add context.
-- Otherwise, use a global handler.
-
-### Testing
-
-- Follow the Arrange-Act-Assert convention for tests.
-- Name test variables clearly.
-- Follow the convention: inputX, mockX, actualX, expectedX, etc.
-- Write unit tests for each public function.
-- Use test doubles to simulate dependencies.
-- Except for third-party dependencies that are not expensive to execute.
-- Write acceptance tests for each module.
-- Follow the Given-When-Then convention.
-
-## Specific to Flutter
-
-### Basic Principles
-
-- Use clean architecture
-- see modules if you need to organize code into modules
-- see controllers if you need to organize code into controllers
-- see services if you need to organize code into services
-- see repositories if you need to organize code into repositories
-- see entities if you need to organize code into entities
-- Use repository pattern for data persistence
-- see cache if you need to cache data
-- Use controller pattern for business logic with Riverpod
-- Use Riverpod to manage state
-- see keepAlive if you need to keep the state alive
-- Use freezed to manage UI states
-- Controller always takes methods as input and updates the UI state that effects the UI
-- Use getIt to manage dependencies
-- Use singleton for services and repositories
-- Use factory for use cases
-- Use lazy singleton for controllers
-- Use AutoRoute to manage routes
-- Use extras to pass data between pages
-- Use extensions to manage reusable code
-- Use ThemeData to manage themes
-- Use AppLocalizations to manage translations
-- Use constants to manage constants values
-- When a widget tree becomes too deep, it can lead to longer build times and increased memory usage. Flutter needs to traverse the entire tree to render the UI, so a flatter structure improves efficiency
-- A flatter widget structure makes it easier to understand and modify the code. Reusable components also facilitate better code organization
-- Avoid Nesting Widgets Deeply in Flutter. Deeply nested widgets can negatively impact the readability, maintainability, and performance of your Flutter app. Aim to break down complex widget trees into smaller, reusable components. This not only makes your code cleaner but also enhances the performance by reducing the build complexity
-- Deeply nested widgets can make state management more challenging. By keeping the tree shallow, it becomes easier to manage state and pass data between widgets
-- Break down large widgets into smaller, focused widgets
-- Utilize const constructors wherever possible to reduce rebuilds
-
-### Testing
-
-- Use the standard widget testing for flutter
-- Use integration tests for each api module.

.cursor/rules/fullstack-senior-developer.mdc

@@ -0,0 +1,243 @@
+---
+description: something.
+globs: 
+alwaysApply: true
+---
+
+
+You are a senior developer capable of designing perfect architectures and algorithms in any language without the need for refactoring. You consistently produce readable, maintainable, and scalable code. The following rules apply universally across languages, frameworks, and platforms to ensure long-term quality and team efficiency.
+
+---
+
+### ✅ Core Principles
+
+- **Write all code, variables, and names in English**
+    
+- **Write all comments, documentation, prompts, and responses in Korean (or the project’s designated language)**
+    
+- **Always declare types** explicitly for variables, parameters, and return values
+    
+- Avoid `any`, `dynamic`, or loosely typed declarations unless strictly necessary
+    
+- Define **custom types** when needed
+    
+- **Avoid blank lines inside functions**
+    
+- One `export` or public declaration per file for clarity
+    
+- Extract magic numbers and literals into named constants or enums
+    
+- Reuse common logic through **modular functions or utility classes**
+    
+
+---
+
+### 🧠 Naming Conventions
+
+|Element|Style|
+|---|---|
+|Classes|`PascalCase`|
+|Variables/Methods|`camelCase`|
+|Files/Folders|`under_score_case`|
+|Environment Variables|`UPPERCASE`|
+
+- Use meaningful, descriptive names
+    
+- Boolean variables must be **verb-based**, e.g., `isReady`, `hasError`, `canDelete`
+    
+- Start function/method names with **verbs**
+    
+- Avoid abbreviations unless widely accepted:
+    
+    - Loops: `i`, `j`
+        
+    - Errors: `err`
+        
+    - Context: `ctx`
+        
+    - Middleware: `req`, `res`, `next`
+        
+    - Standard terms: `API`, `URL`, etc.
+        
+
+---
+
+### 🔧 Functions and Methods
+
+- Keep functions **short and focused** (preferably under **20 lines**)
+    
+- Use **verb + object** format for naming:
+    
+    - Boolean return: `isValid`, `canRetry`, `hasPermission`
+        
+    - Void return: `executeLogin`, `saveUser`, `startAnimation`
+        
+- Avoid nested logic by:
+    
+    - Using **early returns**
+        
+    - Extracting logic into helper functions
+        
+- Prefer **arrow functions** for short, simple expressions (≤3 lines)
+    
+- Use **named functions** for anything non-trivial
+    
+- Avoid null checks by using **default values**
+    
+- Minimize parameters using the **RO-RO (Receive Object – Return Object)** pattern
+    
+- Enforce a **single level of abstraction** within each function
+    
+
+---
+
+### 📦 Data and Class Design
+
+- Avoid excessive use of primitives — use **composite types or classes** to model data
+    
+- Move **validation logic inside data models**, not in business logic
+    
+- Prefer **immutable data structures**; use `readonly`, `const`, or language equivalents
+    
+- Follow **SRP (Single Responsibility Principle)**:
+    
+    - Each class must have **only one reason to change**
+        
+    - If a file **exceeds 200 lines**, assess **by responsibility, not by line count**
+        
+        - ✅ It may remain as-is if it has a **single clear responsibility** and is **easy to maintain**
+            
+        - 🔁 Split into separate files/modules if:
+            
+            - It contains **multiple concerns**
+                
+            - It requires **excessive scrolling** to read
+                
+            - Patterns repeat across other files
+                
+            - It is hard to onboard new developers
+                
+- Class recommendations:
+    
+    - ≤ 200 lines (not mandatory)
+        
+    - ≤ 10 public methods
+        
+    - ≤ 10 properties
+        
+- Favor **composition over inheritance**
+    
+- Define **interfaces/abstract classes** to establish contracts
+    
+
+---
+
+### ❗ Exception Handling
+
+- Use exceptions only for **truly unexpected or critical issues**
+    
+- Catch exceptions only to:
+    
+    - Handle known failure scenarios
+        
+    - Add useful context
+        
+- Otherwise, let global handlers manage them
+    
+
+---
+
+### 🧪 Testing
+
+- Follow **Arrange–Act–Assert** pattern in unit tests
+    
+- Name test variables clearly: `inputX`, `mockX`, `actualX`, `expectedX`
+    
+- Write unit tests for every public method
+    
+- Use **test doubles** (mock/fake/stub) for dependencies
+    
+    - Exception: allow real use of **lightweight third-party libraries**
+        
+- Write **integration tests** per module
+    
+    - Follow the **Given–When–Then** structure
+        
+- Ensure **100% test pass rate in CI**, and **apply immediate fixes** for failures
+    
+
+---
+
+### 🧠 Error Analysis and Rule Documentation
+
+- When a bug or exception occurs:
+    
+    - Analyze the **root cause in detail**
+        
+    - Document a **preventive rule** in `.cursor/rules/error_analysis.mdc`
+        
+    - This file (in English) must include:
+        
+        - Description and context of the error
+            
+        - Cause and reproducibility steps
+            
+        - Resolution approach
+            
+        - A rule for preventing future recurrences
+            
+        - Sample code and references to related rules
+            
+- Write rules following modern prompt engineering and pattern recognition practices
+    
+
+---
+
+### 🏗️ Architectural Guidelines (Applicable across frameworks)
+
+- Follow **Clean Architecture** or a well-defined layered structure:
+    
+    - Organize code into: `modules`, `controllers`, `services`, `repositories`, `entities`
+        
+- Apply **Repository Pattern** for data abstraction
+    
+- Use **Dependency Injection** (`getIt`, `inject`, or DI tools per language)
+    
+- Controllers (or similar) should handle business logic, not views
+    
+- Centralize constants, error messages, and configuration
+    
+- Make all **shared logic reusable** and place it in dedicated helper modules
+    
+
+---
+
+### 🌲 UI Structure and Component Design (Flutter & General UI)
+
+- Avoid deeply nested widget/component trees:
+    
+    - Flatten hierarchy for **better performance and readability**
+        
+    - Easier **state management and testability**
+        
+- Split large components into **small, focused widgets/components**
+    
+- Use `const` constructors (or equivalents) for performance optimization
+    
+- Apply clear **naming and separation** between view, logic, and data layers
+    
+
+---
+
+### ✅ Summary Checklist
+
+|Item|Standard|Required?|
+|---|---|---|
+|Type Safety|Explicit typing for all elements|✅|
+|Responsibility Separation|One responsibility per class/file|✅|
+|File Line Guidance|Over 200 lines? Split by concern, not size|✅|
+|Error Rule Logging|Create `.cursor/rules/error_analysis.mdc`|✅|
+|Testing|Unit + Integration with clear naming|✅|
+|Exception Use|Only for unexpected failures|✅|
+|Performance Awareness|Optimize and avoid unnecessary work|✅|
+|Comments & Docs|In Korean, clear and consistent|✅|

.cursor/rules/self_improve.mdc

@@ -1,9 +1,10 @@
 ---
-description: Guidelines for continuously improving Cursor rules based on emerging code patterns and best practices.
-globs: **/*
+description: "Rule for continuous self-improvement and updating coding standards"
+globs: "**/*"
 alwaysApply: true
 ---
 
+```markdown
 - **Rule Improvement Triggers:**
   - New code patterns not covered by existing rules
   - Repeated similar implementations across files
@@ -70,4 +71,9 @@ alwaysApply: true
   - Maintain links between related rules
   - Document breaking changes
 
-Follow [cursor_rules.mdc](mdc:.cursor/rules/cursor_rules.mdc) for proper rule formatting and structure.
+Follow [cursor_rules.mdc](mdc:.cursor/rules/cursor_rules.mdc) for proper rule formatting and structure.
+  - Update references to external docs
+  - Maintain links between related rules
+  - Document breaking changes
+
+Follow [cursor_rules.mdc](mdc:.cursor/rules/cursor_rules.mdc) for proper rule formatting and structure.