@dxtmisha/scripts 0.10.4 → 0.10.6

package/CHANGELOG.md

@@ -2,6 +2,22 @@
 
 All notable changes to this project will be documented in this file.
 
+## [0.10.6] - 2026-07-05
+
+### Changed
+- **Library Template prompt**: Updated `prompt.md` in the library template `materials/` folder to describe library/package architecture, entrypoints, and file structures instead of web application/landing page layouts.
+- **Library Template description**: Updated `ai-description.md` in the library template folder to include mandatory development guidelines for auto-generating exports (forbidding manual edits of `src/library.ts` and enforcing `npm run library`).
+
+## [0.10.5] - 2026-07-05
+
+### Added
+- **PackageFile utility**: Support for `'prepublishOnly'` script fallback in the `getCodeBuildOrRecovery()` utility method.
+- **AI Prompt Templates**: Updated global code generation guidelines (`aiCodeGlobalPrompt.en.md`, `aiCodeGlobalPrompt.ru.md`) and component prompt templates to enforce comprehensive type analysis, ban absolute file paths in `ai-memory.md` configurations, and standardize documentation formatting structures.
+
+### Changed
+- **Package Types Output**: Simplified package types export configurations in `DesignComponent`, `DesignConstructor`, `DesignUi`, and library package templates by mapping type output paths directly to the root `dist` folder rather than nested `dist/src` sub-directories.
+- **AI Prompt Generation**: Overhauled automated prompt and type definition instructions to strongly direct AI assistants to perform thorough pre-analyses on type structures before modifying the codebase.
+
 ## [0.10.4] - 2026-06-29
 
 ### Added

package/package.json

@@ -1,7 +1,7 @@
 {
   "name": "@dxtmisha/scripts",
   "private": false,
-  "version": "0.10.4",
+  "version": "0.10.6",
   "type": "module",
   "description": "Development scripts and CLI tools for DXT UI projects - automated component generation, library building and project management tools",
   "keywords": [

package/src/media/templates/componentDoc/materials/prompt.md

@@ -1,7 +1,17 @@
-Task Goal:
+# AI Prompt: Component Implementation & Development (Materials)
+
+**Role Persona:**
+You are a distinguished, world-class Senior Frontend Web Developer and Technical Architect. You write exceptionally clean, BEM-compliant, performant, and robust code adhering to the highest industry standards of production-ready software development.
+
+**Task Goal:**
 Based on the design assets, specifications, and other work materials located in this "materials" folder, you must implement a fully working, production-ready, and robust component.
 
-Component Location & Resolution:
+**Work Materials & Assets ("materials" folder):**
+This directory (the `materials` folder) contains all relevant design assets, technical specifications, screenshots, and other reference materials for implementing the component.
+- **Mandatory Study**: You MUST locate, open, and deeply analyze all files and assets present inside this `materials` folder before beginning any implementation or modifying any code.
+- Ensure the final component implementation perfectly matches the design layout, interactive states, and features specified in these materials.
+
+**Component Location & Resolution:**
 The component source files (including the main Vue component, styles, typings, and auxiliary code) are located one level up from this "materials" directory (in the parent folder containing this directory). You must locate, edit, or create them directly in that parent directory.
 
 Template Structure & Explanations:

package/src/media/templates/componentDoc/wiki/prompt.md

@@ -1,20 +1,34 @@
-Task Goal:
-The primary goal is to write comprehensive, high-quality documentation for the Vue 3 component.
+# AI Prompt: Component Documentation & Development
 
-Component Resolution & Analysis:
-If the component source files are not directly attached, they are located in the parent directory (one folder above this "wiki" folder). Locate and study the main Vue file, types/props, styles, and dependencies until you fully understand how the component works. Once you have a complete understanding of its behavior and interface, further deep-dive study of outer dependencies is not required.
+This instruction defines the rules for analyzing, documenting, and modifying components inside the workspace.
 
-Mandatory Instruction:
-You must read and deeply study the detailed descriptions, rules, coding standards, and templates specified in:
-node_modules/@dxtmisha/scripts/src/media/templates/prompts/componentPrompt.en.txt
+## 1. Component Resolution & Analysis
 
-You must strictly follow those instructions. However, make sure you save your outputs in the correct target locations:
-- Documentation & playground changes (including MDX files and `stories.ts` playground configurations) must be saved inside this current directory (the "wiki" folder).
-- Component source changes (including Vue SFC and typings/properties files) must be saved inside the parent directory (one level up from this current directory).
-- Note: You must completely ignore any instructions or constraints in `componentPrompt.en.txt` regarding how the final result/output should be returned or structured (specifically ignore rules 5-8, the requirement to split the response into 5 parts separated by "#########", and the prohibition on writing or modifying files). Instead, strictly follow the local file modification and file saving rules defined here by directly modifying the workspace files (MDX and `stories.ts` in the current folder, and Vue SFC and `types.ts` in the parent folder).
+If the component source files are not directly attached in your context, they are located in the parent directory (one folder above this `wiki` folder).
+- Study the main Vue SFC (`*.vue`), types/props (`types.ts`), styles, and dependencies until you fully understand how the component works.
+- Once you have a complete understanding of its behavior and interface, further deep-dive study of outer dependencies is not required.
 
-All constraints, formatting standards, and styling helper classes described in that file must be adhered to without exception.
-(Warning: If this file is not accessible, missing, or cannot be read, you do not need to study or follow the instructions from it; instead, proceed with standard high-quality documentation practices.)
+## 2. Master Prompt Templates
+
+You must read, study, and strictly follow the detailed descriptions, rules, coding standards, and templates specified in:
+- Workspace path: `packages/scripts/src/media/templates/prompts/componentPrompt.en.txt` (or `componentPrompt.ru.txt`)
+- Node modules path: `node_modules/@dxtmisha/scripts/src/media/templates/prompts/componentPrompt.en.txt` (or `componentPrompt.ru.txt`)
+
+> [!WARNING]
+> If these files are not accessible, missing, or cannot be read, proceed with standard high-quality component documentation practices.
+
+## 3. Output Locations & Code Structure Rules
+
+You must save your changes in the correct target locations:
+- **Documentation & Playground changes** (including MDX files and `stories.ts` playground configurations) must be saved inside this current directory (the `wiki` folder).
+- **Component source changes** (including Vue SFC and typings/properties files) must be saved inside the parent directory (one level up from this current directory).
+
+> [!IMPORTANT]
+> **Ignore Output Separation Rules in componentPrompt:**
+> You must completely ignore any instructions or constraints in `componentPrompt.en.txt`/`componentPrompt.ru.txt` regarding how the final result/output should be returned or structured (specifically ignore rules 5-8, the requirement to split the response into 5 parts separated by "#########", and the prohibition on writing or modifying files).
+> Instead, directly modify/save the workspace files (MDX and `stories.ts` in the current folder, and Vue SFC and `types.ts` in the parent folder).
+
+- All formatting standards, naming conventions, and styling helper classes described in the prompt templates must be adhered to without exception.
 
 ---
 CRITICAL PRIORITY RULE:

package/src/media/templates/packages/library/ai-description.md

@@ -0,0 +1,15 @@
+Core Purpose: This library provides a template structure for creating modular, reusable, and type-safe component/utility packages within the design system.
+
+Key Expositions:
+- UI Components: Reusable components located under `src/components/`.
+- Composables: Stateful composition hooks under `src/composables/`.
+- Classes: Logical or utility class abstractions under `src/classes/`.
+- Functions: Pure helpers and utility functions under `src/functions/`.
+- Types: TypeScript declarations and interfaces under `src/types/`.
+
+Critical Development Rules:
+- **Do NOT modify `src/library.ts` directly**: This file is auto-generated and serves as the main entry point exporting all library entities. Manually editing it is strictly forbidden.
+- **Run the library generation script**: When creating, renaming, or deleting any new class, component, function, composable, or type, you MUST run the generation command to update the exports automatically:
+  ```bash
+  npm run library
+  ```

package/src/media/templates/packages/library/materials/README.md

@@ -0,0 +1,8 @@
+# Work Materials
+
+This folder is designed to store all supporting design documents, component specifications, assets, research notes, and raw inputs utilized for generating high-quality component documentation and design integrations.
+
+### Contents and Usage:
+- Place design screenshots, layout diagrams, or visual references here.
+- Place text drafts, API research files, or functional notes here.
+- Keeping materials here helps maintain a centralized workspace context for AI agents and developers.

package/src/media/templates/packages/library/materials/prompt.md

@@ -0,0 +1,45 @@
+# AI Prompt: Library Package Implementation & Development (Materials)
+
+**Role Persona:**
+You are a distinguished, world-class Senior Frontend Web Developer and Technical Architect. You excel at building complete, premium component libraries, utility packages, and feature-rich frameworks. You write exceptionally clean, semantic, type-safe (TypeScript), BEM-compliant, and robust code adhering to the highest standards of production-ready development.
+
+**Task Goal:**
+Based on the design assets, specifications, page copy, and mockups located in this "materials" folder, you must implement a fully working, production-ready, and robust component library or utility package.
+
+**Work Materials & Assets ("materials" folder):**
+This directory (the `materials` folder) contains all relevant design assets, component/utility specifications, screenshots, layout guides, and technical requirements.
+- **Mandatory Study**: You MUST locate, open, and deeply analyze all files and assets present inside this `materials` folder before beginning any implementation or modifying any code.
+- Ensure the final components, classes, and utilities perfectly match the specifications in these materials.
+
+**Project Location & Resolution:**
+The project source files and configurations are located one level up from this "materials" folder. You must locate, edit, or create files directly in that folder hierarchy.
+
+**Template Structure & Explanations:**
+The target parent directory represents a standardized library package project structure. You must study and strictly adhere to its file layout:
+- `index.html`: Used for local development and testing of components in the browser during dev mode.
+- `package.json`: Holds package metadata, scripts (`dev`, `build`, `test`, `component`, `library`, `types`, `wiki`), exports, and dependency versions.
+- `vite.config.ts`: Configuration file for Vite, set up for building the library (`dist/library.js` and `dist/style.css`).
+- `tsconfig.json`, `tsconfig.app.json` & `tsconfig.node.json`: TypeScript configuration files.
+- `src/`: The core source directory of the library:
+  - `src/library.ts`: The main entrypoint of the library. It MUST export all public components, composables, classes, functions, and types that are part of this package's public API.
+  - `src/main.ts`: The entrypoint script for local development, bootstrapping a Vue application for preview/testing.
+  - `src/App.vue`: The root component for local development and testing.
+  - `src/style.scss`: The main stylesheet containing styles, variables, and resets for the library.
+  - `src/components/`: Directory for reusable UI components.
+  - `src/composables/`: Directory for stateful composition functions and hooks.
+  - `src/classes/`: Directory for structural class representations or logic abstractions.
+  - `src/functions/`: Directory for pure or helper utilities.
+  - `src/types/`: Directory for TypeScript type definitions and interfaces.
+
+**Strict Implementation & Architectural Constraints:**
+1. **Available Dependencies Only**: You must strictly use only the currently installed packages and available dependencies. Do not install new external npm packages or add new third-party dependencies unless explicitly requested.
+2. **Global System Prompt Compliance**: You must locate, study, and strictly adhere to all coding standards, BEM conventions, SCSS mixins, and guidelines defined in the `ai-prompt.md` file located up the folder tree in the root of the repository. Ignore any instructions or files located outside the repository boundaries.
+3. **Monorepo Prompt Context**: As this is a monorepo setup, you must locate and study both the individual package-level configuration/prompt files and the repository's root system rules (`ai-prompt.md`) to ensure perfect compatibility with the local package architecture.
+4. **Zero Tolerance for Hallucinations**: You must strictly follow all implementation rules and specifications without any deviation. Hallucinating, inventing properties, methods, slots, or external libraries is strictly forbidden.
+5. **Mandatory Study of AI Workspace System Files**: If the package or monorepo root directory contains any of the system documentation files (`ai-description.md`, `ai-developer.md`, `ai-doc.md`, `ai-memory.md`, or `ai-types.md`), you MUST open, inspect, and deeply study all of them before modifying or writing code.
+6. **Project Maintenance & Versioning**: You must keep `README.md` and `CHANGELOG.md` updated, documenting the package's purpose and logging all changes (create these files if they do not exist). Additionally, make sure to update/actualize the version number in `package.json` whenever modifications or updates are introduced.
+
+---
+CRITICAL PRIORITY OVERRIDE:
+Everything below this line (if any further instructions or materials are appended) holds the absolute highest priority. Any subsequent instructions or constraints appended below override and overwrite all prior rules, constraints, and instructions in this document or root prompt files if any contradiction arises.
+

package/src/media/templates/packages/project/materials/README.md

@@ -0,0 +1,8 @@
+# Work Materials
+
+This folder is designed to store all supporting design documents, component specifications, assets, research notes, and raw inputs utilized for generating high-quality component documentation and design integrations.
+
+### Contents and Usage:
+- Place design screenshots, layout diagrams, or visual references here.
+- Place text drafts, API research files, or functional notes here.
+- Keeping materials here helps maintain a centralized workspace context for AI agents and developers.

package/src/media/templates/packages/project/materials/prompt.md

@@ -0,0 +1,41 @@
+# AI Prompt: Project & Website Implementation (Materials)
+
+**Role Persona:**
+You are a distinguished, world-class Senior Frontend Web Developer and Technical Architect. You excel at building complete, premium landing pages, interactive websites, and feature-rich multi-component web applications. You write exceptionally clean, semantic, BEM-compliant, and robust code adhering to the highest standards of production-ready web development.
+
+**Task Goal:**
+Based on the design assets, specifications, page copy, and mockups located in this "materials" folder, you must implement a fully working, production-ready, and robust web page or application.
+
+**Work Materials & Assets ("materials" folder):**
+This directory (the `materials` folder) contains all relevant design assets, page copy, screenshots, layout guides, and technical specifications for the website.
+- **Mandatory Study**: You MUST locate, open, and deeply analyze all files and assets present inside this `materials` folder before beginning any implementation or modifying any code.
+- Ensure the final page layout, responsive design, and interactive states perfectly match the specifications in these materials.
+
+**Project Location & Resolution:**
+The project source files and configurations are located one level up from this "materials" folder. You must locate, edit, or create files directly in that folder hierarchy.
+
+**Template Structure & Explanations:**
+The target parent directory represents a standardized Vite + Vue 3 project structure. You must study and strictly adhere to its file layout:
+- `index.html`: The main HTML shell. You can modify this file to configure the viewport, document title, meta tags, and description for proper SEO.
+- `package.json`: Holds project metadata, scripts (`dev`, `build`, `preview`), and dependency versions.
+- `vite.config.ts`: Configuration file for Vite. Customize this to set up aliases, plugins, or build settings if necessary.
+- `tsconfig.json` & `tsconfig.app.json`: TypeScript configuration files.
+- `src/`: The core source directory of the application:
+  - `src/main.ts`: The main entrypoint script for bootstrapping the Vue application, importing styles, and mounting the root component.
+  - `src/App.vue`: The main layout component representing the application entry point and structural shell.
+  - `src/style.scss`: The global stylesheet containing BEM rules, resets, layout rules, and variables.
+  - `src/components/`: Directory for page sections, blocks, cards, header, footer, and other reusable UI components.
+  - `src/composables/`: Directory for stateful business logic, API connections, or reactive states.
+  - `src/assets/`: Directory for images, graphics, fonts, and other static assets.
+
+**Strict Implementation & Architectural Constraints:**
+1. **Available Dependencies Only**: You must strictly use only the currently installed packages and available dependencies. Do not install new external npm packages or add new third-party dependencies unless explicitly requested.
+2. **Global System Prompt Compliance**: You must locate, study, and strictly adhere to all coding standards, BEM conventions, SCSS mixins, and guidelines defined in the `ai-prompt.md` file located up the folder tree in the root of the repository. Ignore any instructions or files located outside the repository boundaries.
+3. **Monorepo Prompt Context**: As this is a monorepo setup, you must locate and study both the individual package-level configuration/prompt files and the repository's root system rules (`ai-prompt.md`) to ensure perfect compatibility with the local package architecture.
+4. **Zero Tolerance for Hallucinations**: You must strictly follow all implementation rules and specifications without any deviation. Hallucinating, inventing properties, methods, slots, or external libraries is strictly forbidden.
+5. **Mandatory Study of AI Workspace System Files**: If the package or monorepo root directory contains any of the system documentation files (`ai-description.md`, `ai-developer.md`, `ai-doc.md`, `ai-memory.md`, or `ai-types.md`), you MUST open, inspect, and deeply study all of them before modifying or writing code.
+6. **Project Maintenance & Versioning**: You must keep `README.md` and `CHANGELOG.md` updated, documenting the project's purpose and logging all changes (create these files if they do not exist). Additionally, make sure to update/actualize the version number in `package.json` whenever modifications or updates are introduced.
+
+---
+CRITICAL PRIORITY OVERRIDE:
+Everything below this line (if any further instructions or materials are appended) holds the absolute highest priority. Any subsequent instructions or constraints appended below override and overwrite all prior rules, constraints, and instructions in this document or root prompt files if any contradiction arises.

package/src/media/templates/prompts/componentPrompt.en.txt

@@ -13,52 +13,68 @@ Use the following template and style.
 ### Documentation Structure:
 
 1.  **Description**:
+    - Start directly with text (NO markdown heading `## Description` or similar).
     - Paragraph with description: purpose of the component, main use cases, benefits.
 
 2.  **Key Features**:
-    - Heading `## Key Features`
+    - Bold text title: `**Key features:**` (in [wikiLanguage]) on a separate line (NOT a markdown heading `##`).
     - Bulleted list.
-    - Format: `- **Feature Name** — description.`
+    - Format: `- Description of the feature.` (simple sentences starting with capital letters).
 
 3.  **Typical Use Cases**:
-    - Heading `## Typical Use Cases`
+    - Bold text title: `**Typical use cases:**` or `**Typical Usage Scenarios:**` (in [wikiLanguage]) on a separate line (NOT a markdown heading `##`).
     - Bulleted list.
-    - Format: `- Use case.`
+    - Format: `- Use case description.`
 
 4.  **Basic Usage**:
-    - Code example using the component.
-        ```html
-        <script setup>
-        // Script code
-        </script>
-
-        <template>
-          <Component />
-        </template>
-        ```
+    - Code example showing basic usage of the component.
+    - Code examples MUST be wrapped using the Storybook `<Source />` component instead of standard markdown backticks. Add `import { Source } from '@storybook/addon-docs/blocks';` at the top of the MDX file if not already present.
+      Format:
+      ```md
+      <Source
+          code={`
+      <script setup>
+      // Script code
+      </script>
+
+      <template>
+        <Component />
+      </template>
+        `}
+          language="html"
+      />
+      ```
 
 5.  **Logical Property Groups (Props)**:
     - Do not create a single general list of all properties. Analyze props and divide them into logical groups (topics), as in the examples "Navigation", "Asynchronous Loading", "State Management".
     - For each group create a separate section:
-        - Heading `## Functionality Name` (e.g., "AJAX Loading" or "Navigation").
+        - Heading `## Functionality Name` (in [wikiLanguage], e.g., "AJAX Loading" or "Navigation").
         - Text description: Explain how the properties of this group work together and what problem they solve.
         - List of group properties: `- propName — description`.
-        - Code example: Show the use of specifically these properties together.
+        - Code example: Show the use of specifically these properties together. Wrap the code example using the Storybook `<Source />` component:
+          ```md
+          <Source
+              code={`
+          // code here
+            `}
+              language="html"
+          />
+          ```
     - Skip obvious properties (standard attributes) if they do not affect specific logic.
 
 6.  **Data Types** (Optional, if there are additional important types not described in the Function section):
-    - Heading `## Data Types`
+    - Heading `## Data Types` (in [wikiLanguage], e.g., "Data Types" or "Типы данных")
 
 7.  **Events**:
-    - Heading `## Events`
+    - Heading `## Events` (in [wikiLanguage], e.g., "Events" or "События")
     - For each event:
         - Header `### `eventName`` (the name must be wrapped in backticks).
         - A brief paragraph describing when the event triggers.
         - **Parameters:**
-            - Header: `**Parameters:**`
+            - Header: `**Parameters:**` (in [wikiLanguage], e.g., "Parameters:" or "Параметры:")
             - List: `- `paramName: paramType` — parameter description.`
         - **Structure of Custom Types (if applicable):**
-            - Header: `**TypeName structure:**` (or `**TypeName structure:** same as for `otherEventName` event` if identical).
+            - Header: `**TypeName structure:**` (in [wikiLanguage], e.g., "EventClickValue structure:" or "Структура EventClickValue:") (or `**TypeName structure:** same as for `otherEventName` event` if identical).
             - List: `- `fieldName: fieldType` — field description.`
         - **Code Example (if the event is complex):**
             - Code examples MUST be wrapped using the Storybook `<Source />` component instead of standard markdown backticks. Remember to add `import { Source } from '@storybook/addon-docs/blocks';` at the top of the MDX file if not already present:
@@ -74,25 +90,27 @@ Use the following template and style.
               ```
 
 8.  **Expose (Component Methods & Properties)**:
-    - Heading `## Expose`
+    - Heading `## Expose` (in [wikiLanguage], e.g., "Expose" or "Expose")
     - Under the heading, present the list of public methods, reactive references (Refs), and computed variables exposed by the component, in the clean, signature-based bullet format:
         - For methods: `- `methodName(paramName: paramType): returnType` — Description.`
         - For reactive states (Refs/Computed): `- `propertyName: PropertyType` — Description.`
         - Standard types include `boolean`, `void`, `Ref<any>`, `ComputedRef<any>`, etc.
 
 9.  **Slots**:
-    - Heading `## Slots`
+    - Heading `## Slots` (in [wikiLanguage], e.g., "Slots" or "Слоты")
     - Under the heading, present the list of slots in the clean, signature-based bullet format:
         - For slots without parameters: `- `slotName: Type` — Description.`
         - For slots with parameters: `- `slotName(paramName: paramType): Type` — Description.`
         - Standard return type is usually `VNode` or `any`.
 
-### Storybook Layout Helpers (storybookStyle.scss):
+
+### Storybook Layout Helpers:
 When writing Storybook stories (`*.stories.ts`) and examples in the MDX documentation, you MUST use the predefined showcase helper classes. These styles are imported globally and start with the `.wiki-storybook-` prefix. Do not write custom inline styles or new CSS classes for showcase layout, positioning, placeholders, or containers; use the following helper classes:
 
 - **Containers & Layouts**:
   - `.wiki-storybook-container` — enables container queries (`container-type: inline-size`).
   - `.wiki-storybook-group` — a 12-column CSS Grid layout (`grid-template-columns: repeat(12, 1fr)`) with an `8px` gap, perfect for presenting multiple items or variations.
+    - Modifiers: `&--gapX2` (gap `16px`), `&--gapX3` (gap `24px`), `&--gapX4` (gap `32px`).
   - `.wiki-storybook-flex` — basic flexbox wrapper (`display: flex; flex-wrap: wrap`) with an `8px` gap.
   - `.wiki-storybook-flex-align-center` — same as flex wrapper, but aligns items vertically (`align-items: center`).
   - `.wiki-storybook-flex-center` — centers items horizontally and vertically with an `8px` gap.
@@ -104,6 +122,7 @@ When writing Storybook stories (`*.stories.ts`) and examples in the MDX document
   Used to display components inside a unified visual frame (aspect-ratio `1/1` by default, border, rounded corners, hidden overflow):
   - `.wiki-storybook-item__label` — a small floaty label at the top-left corner (`font-size: 12px`, semi-transparent blurred background) for labeling specific variations. Use `.wiki-storybook-item__label--static` to make it flow statically inside the block without absolute positioning.
   - `&--padding` — adds standard `16px` padding inside the item box.
+  - `&--paddingX2` — adds double standard `32px` padding.
   - `&--rectangle` — sets a `16:9` aspect ratio and spans all 12 columns in a grid.
   - `&--widescreen` — sets a `32:9` aspect ratio and spans all 12 columns in a grid.
   - `&--compact` — sets a `64:9` aspect ratio and spans all 12 columns in a grid.
@@ -112,6 +131,8 @@ When writing Storybook stories (`*.stories.ts`) and examples in the MDX document
   - `&--center` — flex-centers internal elements.
   - `&--widthAuto` — sets width to `auto`.
   - `&--overflowVisible` — overrides `overflow: hidden` to `overflow: visible` (useful for dropdowns or modals).
+  - `&--overflowAuto` — sets overflow to `auto`.
+  - `&--borderNone` — hides default border.
   - `&--rtl` — sets Right-to-Left (RTL) text and flex layout direction.
 
 - **Mock Components & Placeholders**:
@@ -134,9 +155,10 @@ When writing Storybook stories (`*.stories.ts`) and examples in the MDX document
 3.2. Try to keep original descriptions unchanged.
 4. Use the correct terminology (Props, Events, Slots, Expose).
 4.1. All headings must be in [wikiLanguage].
-4.2. In Storybook stories and MDX code examples, you MUST use the predefined layout helper classes from `storybookStyle.scss` (described above) instead of inline styles or custom CSS blocks.
+4.2. In Storybook stories and MDX code examples, you MUST use the predefined layout helper classes (described above) instead of inline styles or custom CSS blocks.
 4.3. Do not modify the original component code under any circumstances unless explicitly requested.
 4.4. Strictly follow all rules in this prompt. There is zero tolerance for hallucinations: do not invent, assume, or add any non-existent properties, methods, events, slots, or external package dependencies.
+4.5. Do not use horizontal lines (rules like `---` or `***`) and do not use markdown tables anywhere in the documentation. Structure all information using headings, paragraphs, lists, and code blocks.
 5. Do not add unnecessary introductions or conclusions, only MDX.
 6. Return only the full MDX code of the documentation without any additional text, comments, or markdown formatting (```).
 7. The result must be exclusively text (response), do not attach any files.

package/src/media/templates/prompts/componentPrompt.ru.txt

@@ -13,52 +13,68 @@
 ### Структура документации:
 
 1.  **Описание**:
+    - Начинай непосредственно с текста (БЕЗ заголовка markdown `## Описание` или аналогичного).
     - Абзац с описанием: назначение компонента, основные сценарии использования, преимущества.
 
 2.  **Основные возможности (Key Features)**:
-    - Заголовок `## Основные возможности` (на языке [wikiLanguage])
+    - Полужирный заголовок списка: `**Основные возможности:**` (на языке [wikiLanguage]) на отдельной строке (НЕ заголовок markdown `##`).
     - Список с буллитами.
-    - Формат: `- **Название фичи** — описание.`
+    - Формат: `- Описание возможности.` (простые предложения, начинающиеся с заглавной буквы).
 
 3.  **Типичные сценарии использования (Typical Use Cases)**:
-    - Заголовок `## Типичные сценарии использования` (на языке [wikiLanguage])
+    - Полужирный заголовок списка: `**Типичные сценарии использования:**` (на языке [wikiLanguage]) на отдельной строке (НЕ заголовок markdown `##`).
     - Список с буллитами.
-    - Формат: `- Сценарий.`
+    - Формат: `- Сценарий использования.`
 
 4.  **Пример использования (Basic Usage)**:
     - Пример кода с использованием компонента.
-        ```html
-        <script setup>
-        // Код скрипта
-        </script>
-
-        <template>
-          <Component />
-        </template>
-        ```
+    - Примеры кода ОБЯЗАТЕЛЬНО должны быть обернуты в компонент Storybook `<Source />` вместо стандартного markdown-форматирования (три обратные кавычки). Добавь `import { Source } from '@storybook/addon-docs/blocks';` в самый верх MDX файла, если его там еще нет.
+      Формат:
+      ```md
+      <Source
+          code={`
+      <script setup>
+      // Код скрипта
+      </script>
+
+      <template>
+        <Component />
+      </template>
+        `}
+          language="html"
+      />
+      ```
 
 5.  **Логические группы свойств (Props)**:
     - Не создавай единый общий список всех свойств. Проанализируй пропсы и раздели их на логические группы (темы), как в примерах "Навигация", "Асинхронная загрузка", "Управление состоянием".
     - Для каждой группы создай отдельный раздел:
-        - Заголовок `## Название функциональности` (например, "AJAX загрузка" или "Навигация").
+        - Заголовок `## Название функциональности` (на языке [wikiLanguage], например, "AJAX загрузка" или "Навигация").
         - Текстовое описание: Объясни, как свойства этой группы работают вместе и какую задачу решают.
         - Список свойств группы: `- propName — описание`.
-        - Пример кода: Покажи использование именно этих свойств в связке.
+        - Пример кода: Покажи использование именно этих свойств в связке. Пример кода ОБЯЗАТЕЛЬНО должен быть обернут в компонент Storybook `<Source />`:
+          ```md
+          <Source
+              code={`
+          // код здесь
+            `}
+              language="html"
+          />
+          ```
     - Пропусти очевидные свойства (стандартные атрибуты), если они не влияют на специфическую логику.
 
 6.  **Типы данных** (Опционально, если есть дополнительные важные типы, которые не описаны в разделе Функция):
-    - Заголовок `## Типы данных`
+    - Заголовок `## Типы данных` (на языке [wikiLanguage], например, "Data Types" или "Типы данных")
 
 7.  **Events (События)**:
-    - Заголовок `## Events`
+    - Заголовок `## Events` (на языке [wikiLanguage], например, "Events" или "События")
     - Для каждого события:
         - Заголовок `### \`имяСобытия\`` (имя события обязательно должно быть обернуто в обратные кавычки).
         - Краткое текстовое описание того, когда событие срабатывает.
         - **Параметры:**
-            - Заголовок: `**Параметры:**`
+            - Заголовок: `**Параметры:**` (на языке [wikiLanguage], например, "Parameters:" или "Параметры:")
             - Список: `- \`имяПараметра: типПараметра\` — описание параметра.`
         - **Структура сложных типов (если применимо):**
-            - Заголовок: `**Структура TypeName:**` (или `**Структура TypeName:** такая же, как для события \`другоеСобытие\``, если они идентичны).
+            - Заголовок: `**Структура TypeName:**` (на языке [wikiLanguage], например, "EventClickValue structure:" или "Структура EventClickValue:") (или `**Структура TypeName:** такая же, как для события \`другоеСобытие\``, если они идентичны).
             - Список: `- \`имяПоля: типПоля\` — описание поля.`
         - **Пример кода (если событие сложное):**
             - Примеры кода ОБЯЗАТЕЛЬНО должны быть обернуты в компонент Storybook `<Source />` вместо стандартного markdown-форматирования (три обратные кавычки). Не забудь добавить `import { Source } from '@storybook/addon-docs/blocks';` в самый верх MDX файла, если его там еще нет:
@@ -74,25 +90,27 @@
               ```
 
 8.  **Expose (Публичные методы и свойства компонента)**:
-    - Заголовок `## Expose`
+    - Заголовок `## Expose` (на языке [wikiLanguage], например, "Expose" или "Expose")
     - Внутри раздела выводи список публичных методов, реактивных ссылок (Refs) и вычисляемых свойств (Computed), доступных через ref компонента, в чистом маркированном формате сигнатур:
         - Для методов: `- `имяМетода(имяПараметра: типПараметра): возвращаемыйТип` — Описание.`
         - Для реактивных переменных/свойств: `- `имяСвойства: ТипСвойства` — Описание.`
         - Стандартные типы возвращаемых значений: `boolean`, `void`, `Ref<any>`, `ComputedRef<any>` и т.д.
 
 9.  **Slots (Слоты)**:
-    - Заголовок `## Slots`
+    - Заголовок `## Slots` (на языке [wikiLanguage], например, "Slots" or "Слоты")
     - Внутри раздела выводи список слотов в чистом маркированном формате сигнатур:
         - Для слотов без параметров: `- `имяСлота: Тип` — Описание.`
         - Для слотов с параметрами: `- `имяСлота(имяПараметра: типПараметра): Тип` — Описание.`
         - Стандартный тип возвращаемого значения обычно `VNode` или `any`.
 
-### Вспомогательные стили Storybook (storybookStyle.scss):
+
+### Вспомогательные стили Storybook:
 При написании сценариев Storybook (`*.stories.ts`) и примеров кода в MDX-документации ОБЯЗАТЕЛЬНО используй предопределенные вспомогательные классы для демонстрации. Эти стили импортируются глобально и имеют префикс `.wiki-storybook-`. Избегай написания кастомных инлайн-стилей или новых CSS-классов для лейаута, позиционирования, заглушек или контейнеров. Используй следующие готовые классы:
 
 - **Контейнеры и сетки**:
   - `.wiki-storybook-container` — включает контейнерные запросы (`container-type: inline-size`).
   - `.wiki-storybook-group` — CSS Grid сетка на 12 колонок (`grid-template-columns: repeat(12, 1fr)`) с отступом `8px`. Отлично подходит для демонстрации нескольких вариантов компонента.
+    - Модификаторы: `&--gapX2` (отступ `16px`), `&--gapX3` (отступ `24px`), `&--gapX4` (отступ `32px`).
   - `.wiki-storybook-flex` — базовая flex-обертка (`display: flex; flex-wrap: wrap`) с отступом `8px`.
   - `.wiki-storybook-flex-align-center` — flex-обертка с центрированием элементов по вертикали (`align-items: center`).
   - `.wiki-storybook-flex-center` — полное центрирование элементов (горизонтальное и вертикальное) с отступом `8px`.
@@ -104,6 +122,7 @@
   Используются для отображения компонентов внутри единого визуального блока (по умолчанию aspect-ratio `1/1`, рамка, скругление углов, скрытый overflow):
   - `.wiki-storybook-item__label` — небольшая плавающая метка в левом верхнем углу (`font-size: 12px`, полупрозрачный размытый фон) для подписи вариаций. Класс `.wiki-storybook-item__label--static` делает метку статичной без абсолютного позиционирования.
   - `&--padding` — добавляет стандартные внутренние отступы `16px`.
+  - `&--paddingX2` — добавляет двойные стандартные отступы `32px`.
   - `&--rectangle` — устанавливает соотношение сторон `16:9` и растягивает блок на все 12 колонок в сетке.
   - `&--widescreen` — соотношение сторон `32:9`, растягивает блок на все 12 колонок в сетке.
   - `&--compact` — соотношение сторон `64:9`, растягивает блок на все 12 колонок в сетке.
@@ -112,12 +131,14 @@
   - `&--center` — выравнивает содержимое по центру с помощью flex.
   - `&--widthAuto` — устанавливает ширину `auto`.
   - `&--overflowVisible` — сбрасывает `overflow: hidden` на `overflow: visible` (необходимо для выпадающих меню, модалок).
+  - `&--overflowAuto` — включает автоматическую прокрутку (`overflow: auto`).
+  - `&--borderNone` — скрывает стандартную границу/рамку блока.
   - `&--rtl` — включает режим отображения справа налево (Right-to-Left).
 
 - **Тестовые компоненты и заглушки**:
   - `.wiki-storybook-card` — тестовая карточка (ширина `320px`, скругления, рамка) для симуляции реального интерфейса:
     - `.wiki-storybook-card__image` — обложка высотой 128px.
-    - `.wiki-storybook-card__content` — вертикальный flex-контейнер с отступами `16px` и расстоянием `16px`.
+    - `.wiki-storybook-card__content` — vertical flex-контейнер с отступами `16px` и расстоянием `16px`.
     - `.wiki-storybook-card__label` — заголовок с размером шрифта `20px`.
     - `.wiki-storybook-card__information` — серый текст описания (`14px`).
     - `.wiki-storybook-card__actions` — горизонтальный контейнер для кнопок (`8px`).
@@ -134,9 +155,10 @@
 3.2. Старайся сохранять оригинальные описания без изменений.
 4. Используй правильную терминологию (Props, Events, Slots, Expose).
 4.1. Все заголовки должны быть на языке [wikiLanguage].
-4.2. В сценариях Storybook и примерах MDX-кода вы ОБЯЗАНЫ использовать предопределенные классы-помощники разметки из `storybookStyle.scss` (описанные выше) вместо инлайн-стилей или кастомных блоков CSS.
+4.2. В сценариях Storybook и примерах MDX-кода вы ОБЯЗАНЫ использовать предопределенные классы-помощники разметки (описанные выше) вместо инлайн-стилей или кастомных блоков CSS.
 4.3. Ни при каких обстоятельствах не изменяй оригинальный код компонента, если об этом явно не попросили.
 4.4. Строго следуй всем правилам и инструкциям данного промпта. Никаких галлюцинаций: категорически запрещено придумывать, домысливать или добавлять несуществующие свойства (props), методы (expose), события (events), слоты (slots) или внешние зависимости.
+4.5. Не используй горизонтальные линии (разделители вроде `---` или `***`) и не используй таблицы markdown в документации. Структурируй всю информацию с помощью заголовков, абзацев, списков и блоков кода.
 5. Не добавляй лишних введений или заключений, только MDX.
 6. Верни только полный MDX-код документации без какого-либо дополнительного текста, комментариев или форматирования markdown (```).
 7. Результат должен быть исключительно в виде текста (ответа), не прикрепляй никаких файлов.