@fewangsit/wangsvue 1.5.229-alpha.44 → 1.5.229-alpha.46

package/mcp/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@fewangsit/wangsvue-mcp",
-  "version": "1.5.229-alpha.43",
+  "version": "1.5.229-alpha.45",
   "description": "MCP Server for @fewangsit/wangsvue",
   "main": "main.js",
   "type": "module",
@@ -10,18 +10,18 @@
   "buildContext": {
     "package": {
       "name": "@fewangsit/wangsvue",
-      "version": "1.5.229-alpha.43",
+      "version": "1.5.229-alpha.45",
       "description": "Wangsit VueJS Component Library",
       "repository": "https://github.com/fewangsit/wangsvue",
       "workspace": "wangsvue"
     },
     "build": {
-      "timestamp": "2026-02-02T02:30:02.894Z",
+      "timestamp": "2026-02-04T02:10:13.889Z",
       "gitInfo": {
-        "head": "c2a592c74ff1056b8ff8f5db07d463974d11c684",
+        "head": "bb6a3e23c4e436eb20ba4b0eefcdc49b4f53386a",
         "branch": "feat/mcp",
         "repository": "https://github.com/fewangsit/wangsvue.git",
-        "timestamp": "2026-02-02T02:30:02.652Z"
+        "timestamp": "2026-02-04T02:10:13.698Z"
       }
     }
   }

package/mcp/skills/api-service-generator/SKILL.md

@@ -0,0 +1,93 @@
+---
+name: 'api-service-generator'
+description: 'Generates production-ready API Services, DTOs, and Response Types from OpenAPI specifications. Invoke when user provides an OpenAPI spec or asks to create API services.'
+---
+
+# API Service Generator
+
+This skill automates the creation of API services, request DTOs, and response types based on an OpenAPI (Swagger) specification, following the project's architectural standards.
+
+## When to Use
+
+- Invoke when the user provides an OpenAPI specification (YAML or JSON).
+- Invoke when the user asks to "create API services" or "implement endpoints" from a spec.
+- Invoke when updating existing services based on a new API version.
+
+## Standards & Patterns
+
+### 1. File Structure
+
+- **Services**: `src/services/<serviceName>.service.ts`
+- **Request DTOs**: `src/dto/<serviceName>.dto.ts`
+- **Response Types**: `src/types/<serviceName>.type.ts`
+
+### 2. Service Object
+
+- Use **PascalCase** for the service object name (e.g., `AuthService`).
+- Use **camelCase** for methods (e.g., `postLogin`).
+- Methods should follow the naming: `[httpMethod][ActionName]` (e.g., `getDetail`, `postCreate`).
+- Return type: `Promise<AxiosResponse<ResponseType>>`.
+- Single line spacing between methods.
+
+### 3. Instance Creation
+
+```typescript
+import { AxiosResponse } from 'axios';
+import createAxiosInstance from './createInstance';
+
+const API = createAxiosInstance({
+  env: 'VITE_API_BASE_URL',
+  prefix: '/v2/iam',
+});
+```
+
+### 4. DTOs & Types
+
+- **DTOs**: Interfaces for request bodies and query params.
+- **Types**: Interfaces for response bodies.
+- Use clear, descriptive noun-based names (e.g., `LoginBody`, `LoginResponse`).
+- Use `UserProfileResponse` instead of `GetUserProfileResponse`.
+
+## Workflow
+
+1. **Parse the Spec**: Identify paths, methods, request schemas, and response schemas.
+2. **Group by Module**: Group endpoints by their primary path segment (e.g., `/auth/*` -> `AuthService`).
+3. **Generate Interfaces**:
+   - Create `src/dto/<module>.dto.ts` for all request-related interfaces.
+   - Create `src/types/<module>.type.ts` for all response-related interfaces.
+4. **Generate Service**:
+   - Create `src/services/<module>.service.ts`.
+   - Implement methods for each endpoint in the group.
+5. **Register Service**:
+   - Export the service from `src/main.ts` for global availability.
+
+## Example Transformation
+
+**Input (OpenAPI):**
+
+```yaml
+/auth/login:
+  post:
+    summary: Login
+    requestBody:
+      content:
+        application/json:
+          schema:
+            $ref: '#/components/schemas/LoginRequest'
+    responses:
+      '200':
+        content:
+          application/json:
+            schema:
+              $ref: '#/components/schemas/LoginResponse'
+```
+
+**Output (Service):**
+
+```typescript
+const AuthService = {
+  postLogin: (body: LoginRequest): Promise<AxiosResponse<LoginResponse>> => {
+    return API.post('/auth/login', body);
+  },
+};
+```

package/mcp/skills/committing-changes/SKILL.md

@@ -0,0 +1,38 @@
+---
+name: 'committing-changes'
+description: 'Guidelines for Git Conventional Commits. Invoke when user asks for commit message rules or when committing code.'
+---
+
+# Committing Changes
+
+When making commits, follow these guidelines for clear communication about the nature of the changes.
+
+## Commit Types
+
+- **fix**: Resolve an error or bug.
+- **feat**: Add a new feature.
+- **docs**: Documentation-related changes.
+- **chore**: Changes related to project configurations.
+- **refactor**: Restructure the code.
+- **ci**: Changes related to continuous integration scripts/files.
+- **test**: Changes related to testing.
+- **style**: Changes related to design, such as background color.
+
+## Commit Format
+
+```bash
+<type>(Commit Scope): <short description>
+
+[Optional Commit Body]
+
+[Optional Footer or Breaking Change Note]
+```
+
+## Example
+
+```bash
+fix(datatable): bulk action not properly works
+
+- Bulk action should applying the selected action on Apply button clicked.
+- The label should be back into 'Bulk Action' on Apply button clicked.
+```

package/mcp/skills/figma-datatable-generator/SKILL.md

@@ -0,0 +1,93 @@
+---
+name: 'figma-datatable-generator'
+description: 'Generates Wangsvue DataTables from Figma, including toolbars, bulk actions, search, filter, and pagination. Invoke when converting complex table designs from Figma.'
+---
+
+# Figma DataTable Generator
+
+This skill specializes in converting Figma design into feature-rich Wangsvue `DataTable` modules. It handles toolbar button integration, bulk actions, and server-side table configurations.
+
+## 🚨 Mandatory Architectural Principles
+
+- **Business Logic Placement**: All table logic (columns, fetch functions, state) MUST be in `components/modules/`.
+- **Component Exclusivity**: ONLY use WangsVue components.
+
+## 🛠️ Figma Metadata Interpretation
+
+### 1. Toolbar Generation
+
+When frames contain lists of buttons/instances (e.g., `Button Search`, `Button Filter`, `Button View Log`):
+
+#### Toolbar Layout (Right Side)
+
+Group the buttons identified in the Figma context in a flex container on the right side. These buttons are **optional** and should only be generated if they exist in the metadata:
+
+- **Search**: `<ButtonSearch :table-name="tableName" />` (Invoke if `Button Search` or `Input Search` instance is found).
+- **Filter**: `<ButtonFilter :table-name="tableName" />` (Invoke if `Button Filter` instance is found).
+- **Download**: `<ButtonDownload :table-name="tableName" file-name="[EntityName]" />` (Invoke if `Button Download` or `Export` instance is found).
+- **View Log**: `<ButtonViewLog />` (Invoke if `Button View Log` instance is found).
+- **Primary Action**: A generic `<Button />` (e.g., "Add", "Create"). Map the `label`, `icon`, and `severity` based on the Figma instance properties (e.g., `severity="primary"` for main actions).
+
+#### Toolbar Layout (Left Side) - ButtonBulkAction
+
+Include `<ButtonBulkAction />` on the left side of the toolbar if:
+
+1. A frame named **"Bulk action"** or similar exists in the metadata.
+2. **OR** the first column of the table contains a checkbox selection (TH with checkbox or Table Data with checkbox).
+
+### 2. DataTable Configuration
+
+Identify all table headers by finding instances named **"TH"** in the Figma metadata. For each "TH" instance, invoke `get_design_context` to extract precise configuration:
+
+- **Column Mapping**:
+
+  - `header`: The text content found within the `<p>` tag (e.g., "Device Name").
+  - `field`: camelCase version of the `header` text (e.g., `deviceName`).
+  - `sortable`: Set to `true` if the `get_design_context` code contains an element with `data-name="arrow-up-down-line"`. Otherwise, set to `false` or omit.
+  - `dateFormatOptions`: For columns containing date/time values, provide this object. Set `showDate: true` to display the date and `showTime: true` if time values are present in the design. Omit for non-date columns.
+  - `bodyComponent`:
+    - Use `BadgeGroup` if a column contains multiple `Badge` instances or text like `+% more`. Reference the `template` section in `DataTable` documentation via `mcp_wangsvue-docs` and `BadgeGroup` for correct implementation.
+    - Use `Badge` if a column contains a single `Badge` instance. Especially for Badge contains Statuses value, set the `format` to `nowrap`.
+    - Use `Image` if a column contains an image. Provide the src from the specified field, e.g., `:src="item.imageUrl"` and set the `size` to `small`.
+
+- **Table Props**:
+  - `lazy`: Always `true` for table with pagination, unless the user specifies otherwise.
+  - `use-paginator`: Set to `true` if the Figma metadata contains a pagination component (e.g., `Pagination`). Otherwise, set to `false`.
+  - `v-model:selected-data`: Required if `ButtonBulkAction` is present.
+  - `fetch-function`: Map to a service method from the API services package (e.g., `@fewangsit/api-services-template` or as provided by the user in the prompt).
+  - `data-key`: Use `_id` by default.
+  - `use-option`: Set to `false` if you DO NOT find an element with `data-name="more-line"` or an ellipsis button in the Figma context. If found, leave as default (`true`) and provide the `:options` prop bound to a computed property or variable initialized with an empty array `[]`.
+
+## 📋 Implementation Checklist
+
+1. **Service Integration**: Import the relevant service and DTOs from the API services package (e.g., `@fewangsit/api-services-template` or as specified).
+2. **State Management**:
+   - `tableName`: Unique string (e.g., `entity-table`).
+   - `selectedData`: Ref for bulk selection.
+   - `columns`: Typed as `TableColumn<T>[]`.
+3. **Template Structure**:
+   ```html
+   <div class="flex flex-col gap-4" data-wv-name="[module-name]">
+     <div class="flex items-center justify-between gap-2">
+       <ButtonBulkAction ... />
+       <!-- Left Side -->
+       <div class="flex items-center gap-2 ml-auto">
+         <!-- Right Side Buttons -->
+         <ButtonSearch ... />
+         <ButtonFilter ... />
+         <ButtonDownload ... />
+         <ButtonViewLog ... />
+         <button ... />
+       </div>
+     </div>
+     <DataTable ... />
+   </div>
+   ```
+
+## 🔍 Discovery Protocol
+
+1. **Call `get_metadata`** to identify the overall structure and find all instances named **"TH"**.
+2. **Call `get_design_context`** for each identified **"TH"** node ID to extract the header text and sortable state.
+3. **Call `list_all_components`** to verify toolbar components.
+4. **Call `analyze_component`** for `datatable` and toolbar buttons to check prop requirements.
+5. **Call `resolve_type_definition`** for DTOs and item types from the API service package.

package/mcp/skills/figma-to-code/SKILL.md

@@ -0,0 +1,117 @@
+---
+name: 'figma-to-code'
+description: 'Converts Figma designs to Wangsvue code following strict mapping rules and color system. Invoke when user provides Figma section link or node ID'
+---
+
+# Figma to Code Logic
+
+This skill provides strict guidelines for converting Figma designs or React/JSX code into Wangsvue Vue 3 components.
+
+## 0. Figma Discovery Protocol (Link/Node ID)
+
+**Invoke this protocol when a Figma URL or Node ID is provided:**
+
+1. **Extract Node ID:** If a URL is provided (e.g., `...node-id=1-2`), extract the ID (e.g., `1:2`).
+2. **Call `mcp_figma-dev_get_design_context`:** Use the `nodeId` to get the design metadata and code.
+3. **Analyze Variables:** Call `mcp_figma-dev_get_variable_defs` for the node to map any design tokens to the Wangsvue color system.
+
+## 1. Core Conversion Logic
+
+When converting from Figma or React:
+
+1. **Strict Conversion:** Convert all React hooks/JSX into Vue 3 Composition API.
+2. **Component Mapping:** You MUST identify and use the correct **Wangsvue Component** from the MCP. Do not use generic HTML if a Wangsvue component exists.
+3. **Style Abstraction:** **DO NOT** convert Figma color variables or design system tokens manually. Trust the Wangsvue components to provide and handle the design system.
+4. **Layout Focus:** Concentrate exclusively on:
+   - **Layout Structure:** Component hierarchy and nesting.
+   - **Layout Style:** Flex/Grid positioning, spacing, alignment, and sizing.
+   - **Custom Style:** Apply only to non-Wangsvue elements where layout-specific CSS is required.
+   - You MUST use tailwind css class instead of css in `<style>` block.
+5. **Architecture:** You MUST break flat code into the appropriate folder defined in the **Project Structure**. Logic in `components/modules/`, NOT in views.
+
+## 2. Component Discovery Protocol
+
+**ALWAYS ASK BEFORE USING GENERIC COMPONENTS OR MANUAL STYLING:**
+
+1. **Search First:** If you need functionality (Filter, Download, Bulk action, Search, Upload, Copy), search the component list first.
+2. **Structural Components:** If you need a container, card, form, modal, panel, or loading state, check if Wangsvue has a specialized component (e.g., `Card`, `Dialog`, `Form`, `Loading`).
+3. **Mental Shift:**
+   - ❌ OLD: `<div class="bg-white p-4">` → ✅ NEW: `<Card>`
+   - ❌ OLD: `<Button>` for download → ✅ NEW: `<ButtonDownload>`
+
+## 3. Figma Conversion Rules
+
+### Component Replacement Logic
+
+- **`data-name="ComponentName"`** = Replace this entire element with `<ComponentName>`
+- **NOT** wrap `<ComponentName>` inside this element.
+- **Example:** `<div data-name="Breadcrumb">...</div>` → `<Breadcrumb />`
+- **Exception:** If `data-name` is NOT in Wangsvue component list, it may be a custom layout name - keep as div with appropriate classes.
+
+### No Double Wrapping
+
+- ❌ **WRONG:** `<div><Breadcrumb /></div>` (when div only contains 1 component)
+- ✅ **CORRECT:** `<Breadcrumb />` (every Vue component has root element)
+- **Rule:** If container has only 1 component, remove the container.
+
+### Trust Component Styling
+
+- ❌ **NEVER:** Add styling to Wangsvue components.
+- ✅ **ALWAYS:** Trust component's built-in design system.
+- **Exception:** Layout positioning only (margin, positioning).
+- **Example:** `<Breadcrumb class="mb-4" />` (spacing OK), `<Breadcrumb class="flex gap-2" />` (styling NOT OK).
+
+### Figma Data-Name Decision Tree
+
+```
+Figma element has data-name="SomeName"
+    ↓
+Check: Is "SomeName" in Wangsvue component list?
+    ↓
+YES → Replace: <div data-name="Button"> → <Button />
+    ↓
+NO → Keep as layout: <div data-name="HeaderSection"> → <div class="...">
+```
+
+### Exact Value Preservation
+
+- ❌ **WRONG:** `h-[21px]` → `h-5` (20px ≠ 21px)
+- ✅ **CORRECT:** Keep exact values `h-[21px]`
+- **Rule:** 1px difference matters for pixel-perfect design.
+
+## 4. Color System Protocol
+
+**WANGSVUE COLOR SYSTEM RULES:**
+
+- ❌ **NEVER use CSS variables**: `bg-[var(--general/content,#ebeaf0)]`
+- ✅ **ALWAYS use Tailwind color tokens**: `bg-general-50`
+- ❌ **NEVER use hex colors directly**: `bg-[#ebeaf0]`
+- ✅ **ALWAYS map hex to color palette**: `#ebeaf0` → `general-50`
+
+### Color Palette Mapping Process
+
+1. **Find hex color** in Figma code or design.
+2. **Check `tailwind.config.js`** for the color config path.
+3. **Match hex to color token** in the referenced JSON config (e.g., `general-50`, `grayscale-50`, `primary-500`).
+
+## 5. Synthesis & Structure
+
+- **Vue SFC Structure:** Script → Template → Style.
+- **Script Organization:** Imports → Props/Emits → Lifecycle → Variables → Methods.
+- **Views Architecture:** Views are lightweight, only import and compose from modules.
+- **Logic Placement:** Business logic, data, columns, and handlers belong in modules, NOT in view components.
+- **Testing Attributes:** Always include `data-wv-name` and `data-wv-section`.
+
+## 6. Critical Failure Indicators (STOP IF ANY OCCUR)
+
+- Using generic Button when specialized component exists.
+- Using manual CSS when structural component exists.
+- Using CSS variables or hex colors instead of Tailwind color tokens.
+- Writing `<div class="bg-white p-4">` instead of `<Card>`.
+- Writing component usage without checking examples.
+- Guessing icon names or enum values.
+- Creating custom solutions when documented patterns exist.
+- Double wrapping components.
+- Adding styling to Wangsvue components.
+- Converting exact pixel values incorrectly (e.g., 21px → 20px).
+- Putting business logic in view components.

package/mcp/skills/import-validator/SKILL.md

@@ -0,0 +1,54 @@
+---
+name: 'import-validator'
+description: 'Enforces strict import protocols for Wangsvue components and types. Invoke when writing imports or fixing import errors.'
+---
+
+# Import Protocol Validator
+
+This skill ensures that all imports follow the strict Wangsvue Import Protocol.
+
+## The Golden Rules
+
+1.  **NEVER Guess:** Always use `mcp_wangsvue_mcp_analyze_component` and `mcp_wangsvue_mcp_resolve_type_definition` to get the correct paths.
+2.  **Exact Paths:** Do not modify the import paths returned by MCP tools.
+3.  **Type Keyword:** Always add `type` keyword for type imports.
+
+## Common Mistakes & Corrections
+
+### 1. Component Imports
+
+**❌ WRONG:** `import { Button } from '@fewangsit/wangsvue/button';`
+**✅ RIGHT:** `import { Button } from '@fewangsit/wangsvue';`
+_Rule: Components usually come from the main package._
+
+### 2. Type Imports
+
+**❌ WRONG:** `import { MenuItem } from '@fewangsit/wangsvue/menuitem';`
+**✅ RIGHT:** `import type { MenuItem } from '@fewangsit/wangsvue/menuitem';`
+_Rule: Types usually come from specific modules and MUST use `import type`._
+
+### 3. Mixing Imports
+
+**❌ WRONG:** `import { Button, ButtonProps } from '@fewangsit/wangsvue';`
+**✅ RIGHT:** Separate them.
+
+```typescript
+import { Button } from '@fewangsit/wangsvue';
+import type { ButtonProps } from '@fewangsit/wangsvue/button'; // Verify path with MCP!
+```
+
+## Verification Process
+
+Before writing any import:
+
+1.  **Call MCP Tools:** `analyze_component` for components, `resolve_type_definition` for types.
+2.  **Copy Exact Paths:** Use the path provided in the MCP result.
+3.  **Add 'type':** If it is a type definition, ensure `type` keyword is used.
+4.  **Group Properly:** Keep components and types separate.
+
+## Checklist
+
+- [ ] Did I get this path from MCP tools?
+- [ ] Is this a component? (Use main package path)
+- [ ] Is this a type? (Use specific module path + `type`)
+- [ ] Did I copy the exact path?

package/mcp/skills/wangsvue-code-review/SKILL.md

@@ -0,0 +1,70 @@
+---
+name: 'wangsvue-code-review'
+description: 'Reviews generated Wangsvue code against mandatory architectural principles and enforcement checklists. Invoke after generating code or before completion.'
+---
+
+# Wangsvue Code Review Protocol
+
+This skill enforces the strict quality standards for Wangsvue code. Use this checklist to review any generated code before considering the task complete.
+
+## 🚨 Mandatory Architectural Principles
+
+### 1. Total Wangsvue Exclusivity
+
+- [ ] **Strict Prohibition:** NO usage of PrimeVue, Element Plus, Vuetify, or other libraries.
+- [ ] **Compliance:** ONLY use props, slots, events, and patterns defined in Wangsvue MCP or Knowledge Base.
+
+### 2. Zero Assumption Policy
+
+- [ ] **Verification:** Are all prop names, slot names, icon names, and enum values verified via MCP?
+- [ ] **No Guessing:** If it's not in the MCP result, it doesn't exist.
+
+### 3. MCP-First Verification
+
+- [ ] **Component Discovery:** Was `list_all_components()` called to find specialized components?
+- [ ] **Type Resolution:** Were all literal values (icons, severity, sizes) verified with `resolve_type_definition`?
+- [ ] **Example Check:** Did you check `get_example` for intended usage patterns?
+
+## ✅ Final Enforcement Checklist (Every File Must Pass)
+
+### 1. SFC Structure & Organization
+
+- [ ] **Structure:** `<script setup>` → `<template>` → `<style>` (only if needed).
+- [ ] **Script Order:** Imports → Props/Emits → Lifecycle → Variables → Methods (follows Vue Code Structure MD).
+- [ ] **Project Structure:** Business logic is in `components/modules/`, NOT in views.
+- [ ] **App.vue:** Only contains `<router-view />`, no business logic.
+
+### 2. Import Protocol
+
+- [ ] **Exact Paths:** ALL imports match MCP results EXACTLY (no modifications).
+- [ ] **Type Imports:** `type` keyword used for all type imports (from `resolve_type_definition`).
+- [ ] **Separation:** Component imports (main package) separated from Type imports (specific modules).
+
+### 3. Testing & Attributes
+
+- [ ] **Data Attributes:** `data-wv-name` on root element, `data-wv-section` on significant sections.
+
+### 4. Code Quality
+
+- [ ] **Linter:** `pnpm lint` must pass with exit code 0. After fixing ESLint errors, check editor `#problems_and_diagnostics` and fix any remaining issues.
+- [ ] **No Generic HTML:** specialized components used instead of `<div>` (e.g., `Card` instead of `div.bg-white`).
+- [ ] **No Manual CSS:** No styling on Wangsvue components (trust the design system).
+- [ ] **Exact Pixel Values:** 21px remains 21px, do not round to 20px (h-5).
+
+## ❌ Automatic Failure Indicators (IMMEDIATE STOP)
+
+If ANY of these are found, the code is rejected:
+
+- **Guessing:** Guessing icon names (`edit-line` vs `edit`) or enum values.
+- **Manual Styles:** Writing `<div class="bg-white p-4">` instead of `<Card>`.
+- **CSS Vars:** Using `bg-[var(--color)]` instead of Tailwind tokens (`bg-general-50`).
+- **Wrong Imports:** Mixing component and type paths, or forgetting `type` keyword.
+- **Double Wrapping:** `<div><Breadcrumb /></div>` (remove the div).
+- **Fat Views:** Putting data, columns, or handlers in view components instead of modules.
+- **Custom Patterns:** Implementing custom solutions when documentation provides a standard approach.
+- **Optimization:** "Optimizing" documented patterns instead of following them exactly.
+
+## Review Decision
+
+- **PASS:** All checklists checked, no failure indicators.
+- **FAIL:** Any unchecked item or presence of failure indicator. **Fix immediately.**

package/mcp/skills/wangsvue-workflow/SKILL.md

@@ -0,0 +1,91 @@
+---
+name: 'wangsvue-workflow'
+description: 'Enforces the 5-step mandatory workflow for Wangsvue development, including component discovery protocols. Invoke when starting a new task, feature, or component implementation.'
+---
+
+# Wangsvue Mandatory Workflow
+
+This skill guides you through the 5 mandatory steps for any Wangsvue development task. You MUST follow these steps in order.
+
+## The 5-Step Workflow
+
+### Step 1: Standard Synchronization
+
+**Action:** Read relevant MD files before starting.
+
+- **Files to Check:** Vue Code Structure, Project Structure, Code Consistency Guidelines.
+- **Goal:** Ensure you are aligned with the latest architectural standards.
+
+### Step 2: Technical Discovery (MCP First)
+
+**Action:** Use MCP tools to find components and types.
+
+- **Command:** `mcp_wangsvue_mcp_list_all_components()`
+- **Command:** `mcp_wangsvue_mcp_analyze_component(componentId, format: "toon")`
+- **Command:** `mcp_wangsvue_mcp_resolve_type_definition(types: [...])`
+- **Goal:** Get the correct component ID, import paths, and TypeScript contracts.
+- **Rule:** NEVER write import statements without MCP verification.
+
+#### 🔍 Discovery Protocol (Detailed)
+
+**Always ask:** "Does Wangsvue have a specialized component for this?"
+
+**Keyword Search Guide:**
+
+- **Functional Components:**
+
+  - Filter? → Search "filter"
+  - Download? → Search "download" (e.g., `ButtonDownload`)
+  - Bulk actions? → Search "bulk" (e.g., `ButtonBulkAction`)
+  - Search? → Search "search" (e.g., `ButtonSearch`)
+  - Upload? → Search "upload" (e.g., `FileUpload`)
+  - Copy? → Search "copy" (e.g., `ButtonCopy`)
+
+- **Structural Components:**
+  - Card/Container? → Search "card" (for background, padding, border)
+  - Form wrapper? → Search "form"
+  - Modal/Popup? → Search "dialog", "dialogconfirm"
+  - Loading? → Search "loading"
+
+**Mental Shift Required:**
+
+- **❌ OLD:** "I need a container with background" → `<div class="bg-white p-4">`
+- **✅ NEW:** "I need a container" → Search components → Find `Card`
+- **❌ OLD:** "I need a button for download" → `<Button>`
+- **✅ NEW:** "I need download functionality" → Search components → Find `ButtonDownload`
+
+### Step 3: Pattern Extraction (Documentation)
+
+**Action:** Use MCP tools to see real usage patterns.
+
+1.  **Mandatory Discovery:** Call `mcp_wangsvue_docs_get_sections(component)` FIRST to see available section IDs.
+2.  **Extraction:** Call `mcp_wangsvue_docs_get_example(component, section)` using the exact ID found in step 1.
+
+- **Goal:** Understand intended usage, built-in features, and architecture.
+- **Rule:** NEVER guess a section name. NEVER assume an example exists without checking sections.
+- **Rule:** Follow examples EXACTLY. Do not create custom interpretations.
+
+**Questions to Ask:**
+
+- "Does this component handle its own state?" (e.g., `DataTable` handles pagination)
+- "Does it integrate with Router?" (e.g., `TabMenu`)
+- "Does it use a store?" (e.g., `Breadcrumb` uses `useBreadcrumbStore`)
+
+### Step 4: Synthesis (Strict Implementation)
+
+**Action:** Implement the code following strict structure rules.
+
+- **Structure:** Script → Template → Style.
+- **Organization:** Imports → Props/Emits → Lifecycle → Variables → Methods.
+- **Logic:** Business logic in `components/modules/`, NOT in views.
+- **Views:** Lightweight, only import and compose from modules.
+- **Attributes:** Ensure `data-wv-name` and `data-wv-section` are present.
+
+### Step 5: Validation (The "Black Box" Linter Rule)
+
+Launch skill `wangsvue-code-review`.
+
+## Repetition Protocol
+
+Before starting, affirm:
+"I WILL DISCOVER SPECIALIZED COMPONENTS FIRST. I WILL CALL GET_SECTIONS BEFORE GET_EXAMPLE. I WILL NOT GUESS SECTION NAMES OR IMPORTS. I WILL FOLLOW DOCUMENTED PATTERNS EXACTLY. I WILL RUN PNPM LINT."

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@fewangsit/wangsvue",
-  "version": "1.5.229-alpha.44",
+  "version": "1.5.229-alpha.46",
   "author": "Wangsit FE Developer",
   "description": "Wangsit VueJS Component Library",
   "type": "module",