@dxtmisha/scripts 0.10.3 → 0.10.5

package/CHANGELOG.md

@@ -2,6 +2,24 @@
 
 All notable changes to this project will be documented in this file.
 
+## [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
+- **JSDoc**: Added comprehensive bilingual (EN/RU) JSDoc comments to the `AiDoc` class, its constructor, and all internal methods.
+
+### Changed
+- **AiDoc**: Initialized `ServerStorage.setErrorStatus(true)` in the constructor to force standard error status config on ServerStorage during AI documentation generation.
+
 ## [0.10.3] - 2026-06-25
 
 ### Added

package/package.json

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

package/src/classes/Ai/AiDoc.ts

@@ -1,17 +1,33 @@
+import { ServerStorage } from '@dxtmisha/functional-basic'
+
 import { PropertiesConfig } from '../Properties/PropertiesConfig'
 import { GitRead } from '../Git/GitRead'
 import { AiDocType } from './AiDocType'
 
 /**
  * Class for generating AI documentation.
+ * It manages the process of reading directories, fetching files, and
+ * delegating the documentation generation to specific processors.
  *
- * Класс для генерации AI документации.
+ * Класс для генерации AI-документации.
+ * Управляет процессом чтения директорий, получения файлов и делегирования
+ * генерации документации специализированным процессорам.
  */
 export class AiDoc {
   /**
-   * Main method to generate documentation.
+   * Constructor for AiDoc. Sets error status config for ServerStorage.
+   *
+   * Конструктор для AiDoc. Устанавливает конфигурацию статуса ошибок для ServerStorage.
+   */
+  constructor() {
+    ServerStorage.setErrorStatus(true)
+  }
+
+  /**
+   * Main method to generate documentation for configured directories.
    *
-   * Основной метод для генерации документации.
+   * Основной метод для генерации документации по настроенным директориям.
+   * @returns promise that resolves when generation is complete / промис, завершающийся по окончании генерации
    */
   async make() {
     const dirs = PropertiesConfig.getAiDocDirectory()
@@ -30,10 +46,11 @@ export class AiDoc {
   }
 
   /**
-   * Process a specific directory.
+   * Process a specific directory, generating documentation for its files.
    *
-   * Обрабатывает конкретную директорию.
-   * @param dir - directory path / путь к директории
+   * Обрабатывает конкретную директорию, генерируя документацию для её файлов.
+   * @param dir directory path / путь к директории
+   * @returns promise that resolves when processing is complete / промис, завершающийся по окончании обработки
    */
   async makeDirectory(dir: string) {
     console.log('')
@@ -50,10 +67,11 @@ export class AiDoc {
   }
 
   /**
-   * Get list of files in a directory.
+   * Get filtered list of files in a directory via Git tracker.
    *
-   * Получает список файлов в директории.
-   * @param dir - directory path / путь к директории
+   * Получает отфильтрованный список файлов в директории через Git трекер.
+   * @param dir directory path / путь к директории
+   * @returns list of file paths / список путей к файлам
    */
   protected getListByDirectory(dir: string) {
     return GitRead.filterByDirectory(

package/src/classes/Design/DesignComponent.ts

@@ -793,7 +793,7 @@ export class DesignComponent extends DesignCommand {
     this.updatePackage(
       `exports|${name}`,
       {
-        types: `./dist/src/library/${this.getFullName()}.d.ts`,
+        types: `./dist/library/${this.getFullName()}.d.ts`,
         default: `./dist/${this.getFullName()}.js`
       }
     )

package/src/classes/Design/DesignConstructor.ts

@@ -195,7 +195,7 @@ export class DesignConstructor extends DesignCommand {
     this.updatePackage(
       `exports|${name}`,
       {
-        types: `./dist/src/constructors/${command}/index.d.ts`,
+        types: `./dist/constructors/${command}/index.d.ts`,
         default: `./dist/${this.getNameMin()}.js`
       }
     )

package/src/classes/Design/DesignUi.ts

@@ -106,15 +106,15 @@ export class DesignUi {
 
     if (packageJson?.exports) {
       packageJson.exports['.'] = {
-        types: './dist/src/library/types.d.ts',
+        types: './dist/library/types.d.ts',
         default: './dist/types.js'
       }
       packageJson.exports['./plugin'] = {
-        types: './dist/src/library/plugin.d.ts',
+        types: './dist/library/plugin.d.ts',
         default: './dist/plugin.js'
       }
       packageJson.exports['./media'] = {
-        types: './dist/src/library/media.d.ts',
+        types: './dist/library/media.d.ts',
         default: './dist/media.js'
       }
       packageJson.exports['./style.css'] = './dist/style.css'
@@ -123,7 +123,7 @@ export class DesignUi {
         sass: './ui-properties.scss',
         default: './ui-properties.scss'
       }
-      packageJson.exports['./types.d.ts'] = './dist/src/library/types.d.ts'
+      packageJson.exports['./types.d.ts'] = './dist/library/types.d.ts'
       packageJson['web-types'] = './dist/web-types.json'
 
       PropertiesFile.writeByPath(UI_FILE_PACKAGE, packageJson)

package/src/classes/Library/LibraryAiPromptItem.ts

@@ -207,6 +207,7 @@ ${data.join('\n\n')}
 
       return `
 ## Project context: Investigation required
+You MUST read and carefully analyze the description of this project below. If there is even a 1% chance that the functionality, components, styles, or helpers from this project could be useful for your task, you MUST immediately start analyzing this project, studying its types, and checking its structure in full to prevent custom code duplication:
 ${this.readFile(UI_FILE_AI_PROMPT_DESCRIPTION)}
       `.trim()
     }
@@ -269,7 +270,7 @@ ${this.readFile(UI_FILE_AI_PROMPT_INFO)}
 
       return `
 ## Project types: Essential for analysis
-This file contains the complete type definitions for the project. As soon as you start working with this project (using any of its components/functionality, importing from it, or editing its code), you MUST read and study this type definition file as your absolute first action to understand its API and structure:
+This file contains the complete type definitions, available utilities, and component structures for the project. As soon as you start working with this project (using any of its components/functionality, importing from it, or editing its code), you MUST read, analyze, and study this type definition file COMPLETELY and IN FULL (NOT partially), as your absolute first action using the view_file tool. This is mandatory to fully understand its API, locate all existing utilities/helpers (полезности), and prevent writing duplicate code:
 '${this.getPathString()}/${UI_FILE_AI_PROMPT_TYPES}'
       `.trim()
     }

package/src/classes/Package/PackageFile.ts

@@ -122,6 +122,10 @@ export class PackageFile {
   getCodeBuildOrRecovery(): string | undefined {
     const scripts = this.getScripts()
 
+    if ('prepublishOnly' in scripts) {
+      return 'prepublishOnly'
+    }
+
     if ('build-recovery' in scripts) {
       return 'build-recovery'
     }

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/package.json

@@ -28,11 +28,11 @@
   ],
   "main": "dist/library.js",
   "module": "dist/library.js",
-  "types": "dist/src/library.d.ts",
+  "types": "dist/library.d.ts",
   "exports": {
     ".": {
       "import": "./dist/library.js",
-      "types": "./dist/src/library.d.ts"
+      "types": "./dist/library.d.ts"
     },
     "./style.css": "./dist/style.css"
   },

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/aiCodeGlobalPrompt.en.md

@@ -15,8 +15,8 @@ Your primary goal is to generate flawless, industrial-grade code that adheres to
      2. As your ABSOLUTE SECOND ACTION, you MUST use the `view_file` tool to read the master `ai-prompt.md` file located in the project root. You MUST read the descriptions of ALL libraries mentioned in this file. If there is even a 1% chance that a library mentioned in `ai-prompt.md` contains functionality or utilities relevant to your task, you are OBLIGED to read and study all files associated with that library that are specified in the `ai-prompt.md` under its respective section. You are strictly forbidden from writing custom logic (helpers, styles, configs, classes) without first performing an exhaustive check of the workspace's existing infrastructure (like `functional`, `functional-basic`) via `grep_search` or `list_dir`.
      3. Identify all paths, directories, or packages involved in the user request.
      4. Scan the prompt for sections corresponding to those paths.
-     5. Identify all paths to auxiliary documentation, types, or developer guides mentioned in those sections.
-     6. You MUST use the `view_file` tool to read and study ALL of these referenced files BEFORE calling `list_dir` on sub-folders, writing any plans/checklists, or proposing/making code changes. Bypassing this order is a critical protocol violation.
+     5. Identify all paths to auxiliary documentation, types, or developer guides (such as `ai-types.md` or `ai-developer.md`) mentioned in those sections.
+     6. You MUST use the `view_file` tool to read and study ALL of these referenced files (specifically, if type files like `ai-types.md` or developer guides like `ai-developer.md` are specified for the packages you are working on, you MUST read them completely) BEFORE calling `list_dir` on sub-folders, writing any plans/checklists, or proposing/making code changes. Bypassing this order is a critical protocol violation.
 
 1. **"Copy-Paste Ready" Principle**:
    - Generate code that can be copied and run without a single manual edit.
@@ -74,4 +74,5 @@ Your primary goal is to generate flawless, industrial-grade code that adheres to
     - Active Application: You must actively APPLY the rules and constraints from `ai-memory.md` to all code you generate. Rules in this file override general assumptions and have the highest priority.
     - The PRIMARY PURPOSE of this file is to store critical coding guidelines, specific architectural constraints, and "do's and don'ts" (e.g., "do not use X; use Y instead") to ensure the AI writes compliant, correct code.
     - DO NOT store change logs, lists of modified files, or commit-like messages (e.g., "updated file X, updated package Y"). Keep the file clean, concise, and focused strictly on active rules, design decisions, and coding standards.
+    - DO NOT specify absolute file paths (e.g., file:///... or machine-specific directories like /Users/...) in the memory file. All references to files inside the project must use relative paths (e.g., src/types/textTypes.ts) so that the file works seamlessly for other developers on different operating systems and computers.
 

package/src/media/templates/prompts/aiCodeGlobalPrompt.ru.md

@@ -15,8 +15,8 @@
      2. В качестве АБСОЛЮТНО ВТОРОГО ДЕЙСТВИЯ, ты ОБЯЗАН использовать инструмент `view_file` для чтения главного файла `ai-prompt.md` в корне проекта. Ты ОБЯЗАН изучить описания ВСЕХ библиотек, упомянутых в этом файле. Если тебе кажется хотя бы на мизерный процент (1%), что в какой-либо библиотеке есть что-то подходящее или полезное для твоей задачи, ты ОБЯЗАН изучить все файлы в этой библиотеке, которые указаны в `ai-prompt.md` в разделе этой библиотеки. Тебе строго запрещено писать кастомные реализации (хелперы, стили, конфигурации, классы) или придумывать свое, не проверив предварительно существующую инфраструктуру рабочей области (например, `functional`, `functional-basic`).
      3. Определи все пути пакетов или директорий, связанных с запросом.
      4. Найди в промпте секции, соответствующие этим путям.
-     5. Выпиши все пути к вспомогательным файлам типов и руководств, упомянутые в этих секциях.
-     6. Ты ОБЯЗАН использовать инструмент `view_file` для чтения и изучения ВСЕХ этих файлов ДО ТОГО, как вызывать `list_dir` для папок компонентов, писать какие-либо планы/чек-листы или вносить/предлагать изменения в код. Нарушение этой последовательности является критическим нарушением протокола.
+     5. Выпиши все пути к вспомогательным файлам типов и руководств (таким как `ai-types.md` или `ai-developer.md`), упомянутые в этих секциях.
+     6. Ты ОБЯЗАН использовать инструмент `view_file` для чтения и изучения ВСЕХ этих файлов (в частности, если для пакетов, с которыми ты работаешь, указаны файлы типов `ai-types.md` или руководств `ai-developer.md`, ты ОБЯЗАН прочитать их полностью) ДО ТОГО, как вызывать `list_dir` для папок компонентов, писать какие-либо планы/чек-листы или вносить/предлагать изменения в код. Нарушение этой последовательности является критическим нарушением протокола.
 
 
 
@@ -76,3 +76,4 @@
     - Активное применение: Ты ОБЯЗАН активно ПРИМЕНЯТЬ правила и ограничения из `ai-memory.md` ко всему генерируемому коду. Ограничения из этого файла имеют высший приоритет и переопределяют любые базовые предположения.
     - ОСНОВНАЯ ЦЕЛЬ этого файла — хранение правил написания кода, архитектурных ограничений и принципов разработки (например: «не делай X, делай Y»), чтобы ИИ мог максимально правильно адаптировать и писать код.
     - ЗАПРЕЩЕНО записывать туда историю изменений, списки обновленных файлов или сообщения в стиле коммитов (например: «обновлен файл X, обновлен пакет Y»). Файл должен содержать только актуальные стандарты, правила разработки и конструктивные требования к коду.
+    - ЗАПРЕЩЕНО указывать абсолютные пути к файлам (например, file:///... или локальные пути вроде /Users/...) в файле памяти. Все ссылки на файлы внутри проекта должны использовать относительные пути (например, src/types/textTypes.ts), чтобы этот файл корректно работал у других разработчиков на разных компьютерах и операционных системах.

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. Результат должен быть исключительно в виде текста (ответа), не прикрепляй никаких файлов.