@fewangsit/wangsvue-gsts 2.0.0-alpha.3 → 2.0.0-alpha.30

package/mcp/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@fewangsit/wangsvue-gsts-mcp",
-  "version": "2.0.0-alpha.2",
+  "version": "2.0.0-alpha.29",
   "description": "MCP Server for @fewangsit/wangsvue-gsts",
   "main": "main.js",
   "type": "module",
@@ -10,18 +10,18 @@
   "buildContext": {
     "package": {
       "name": "@fewangsit/wangsvue-gsts",
-      "version": "2.0.0-alpha.2",
+      "version": "2.0.0-alpha.29",
       "description": "Global Settings Tagsamurai VueJS Component Library",
       "repository": "https://github.com/fewangsit/wangsvue",
       "workspace": "wangsvue-gsts"
     },
     "build": {
-      "timestamp": "2026-02-09T18:17:30.351Z",
+      "timestamp": "2026-07-01T09:29:38.903Z",
       "gitInfo": {
-        "head": "225c9551f2f71c7c5f9ce394cc07a9d6d8b2560e",
+        "head": "857c300043feadf849a5134c5e433ea43b1cda8b",
         "branch": "dev",
-        "repository": "https://github.com/fewangsit/wangsvue.git",
-        "timestamp": "2026-02-09T18:17:30.132Z"
+        "repository": "git@github.com:fewangsit/wangsvue.git",
+        "timestamp": "2026-07-01T09:29:37.924Z"
       }
     }
   }

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

@@ -1,93 +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);
-  },
-};
-```
+---
+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

@@ -1,38 +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.
-```
+---
+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

@@ -1,93 +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.
+---
+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.