@dxtmisha/scripts 0.9.1 → 0.10.3

package/src/library.ts

@@ -1,54 +1,67 @@
-// Classes
-export * from './classes/Ai/AiAbstract'
-export * from './classes/Ai/AiClaude'
-export * from './classes/Ai/AiClaudeCli'
-export * from './classes/Ai/AiClaudeCliLite'
-export * from './classes/Ai/AiClaudeLite'
-export * from './classes/Ai/AiDoc'
-export * from './classes/Ai/AiDocItem'
-export * from './classes/Ai/AiDocItemAbstract'
-export * from './classes/Ai/AiDocItemClasses'
-export * from './classes/Ai/AiDocItemComposables'
-export * from './classes/Ai/AiDocType'
-export * from './classes/Ai/AiGoogle'
-export * from './classes/Ai/AiGoogleCli'
-export * from './classes/Ai/AiGoogleCliLite'
-export * from './classes/Ai/AiGoogleLite'
-export * from './classes/BrowserItem'
-export * from './classes/Build/BuildFunctional'
-export * from './classes/BuildItem'
-export * from './classes/Design/DesignFigma'
-export * from './classes/Design/DesignScreenshot'
-export * from './classes/Design/DesignTypes'
-export * from './classes/Design/DesignTypescript'
-export * from './classes/Design/DesignWikiStorm'
-export * from './classes/Design/DesignWikiStormItem'
-export * from './classes/FigmaApi'
-export * from './classes/Git/GitRead'
-export * from './classes/Library/LibraryAiWiki'
-export * from './classes/Library/LibraryAiWikiItem'
-export * from './classes/Library/LibraryExport'
-export * from './classes/Library/LibraryList'
-export * from './classes/Library/LibraryPlugin'
-export * from './classes/Library/LibraryTypes'
-export * from './classes/Properties/PropertiesFile'
-
-// Composables
-export * from './composables/useAi'
-
-// Functions
-export * from './functions/getConfigAi'
-export * from './functions/getDirname'
-export * from './functions/getPackageJson'
-export * from './functions/hasNativeDirname'
-
-// Types
-export * from './types/aiTypes'
-export * from './types/configTypes'
-export * from './types/designTypes'
-export * from './types/figmaApiTypes'
-export * from './types/gitTypes'
-export * from './types/libraryTypes'
-export * from './types/propertyTypes'
-export * from './types/screenshotTypes'
-export * from './types/webTypes'
+// Classes
+export * from './classes/Ai/AiAbstract'
+export * from './classes/Ai/AiClaude'
+export * from './classes/Ai/AiClaudeAgent'
+export * from './classes/Ai/AiClaudeAgentLite'
+export * from './classes/Ai/AiClaudeCli'
+export * from './classes/Ai/AiClaudeCliLite'
+export * from './classes/Ai/AiClaudeLite'
+export * from './classes/Ai/AiDoc'
+export * from './classes/Ai/AiDocItem'
+export * from './classes/Ai/AiDocItemAbstract'
+export * from './classes/Ai/AiDocItemClasses'
+export * from './classes/Ai/AiDocItemComposables'
+export * from './classes/Ai/AiDocType'
+export * from './classes/Ai/AiGoogle'
+export * from './classes/Ai/AiGoogleCli'
+export * from './classes/Ai/AiGoogleCliLite'
+export * from './classes/Ai/AiGoogleLite'
+export * from './classes/Ai/AiOpenAi'
+export * from './classes/Ai/AiOpenAiLite'
+export * from './classes/Ai/AiZAi'
+export * from './classes/Ai/AiZAiLite'
+export * from './classes/Ai/ApiTmp'
+export * from './classes/BrowserItem'
+export * from './classes/Build/BuildFunctional'
+export * from './classes/Build/BuildPackages'
+export * from './classes/Build/BuildPublishPackages'
+export * from './classes/BuildItem'
+export * from './classes/Design/DesignFigma'
+export * from './classes/Design/DesignScreenshot'
+export * from './classes/Design/DesignTypes'
+export * from './classes/Design/DesignTypescript'
+export * from './classes/Design/DesignWikiStorm'
+export * from './classes/Design/DesignWikiStormItem'
+export * from './classes/FigmaApi'
+export * from './classes/Git/GitRead'
+export * from './classes/Library/LibraryAiPrompt'
+export * from './classes/Library/LibraryAiPromptItem'
+export * from './classes/Library/LibraryAiWiki'
+export * from './classes/Library/LibraryAiWikiItem'
+export * from './classes/Library/LibraryExport'
+export * from './classes/Library/LibraryList'
+export * from './classes/Library/LibraryPlugin'
+export * from './classes/Library/LibraryTypes'
+export * from './classes/Package/PackageFile'
+export * from './classes/Properties/PropertiesFile'
+
+// Composables
+export * from './composables/useAi'
+
+// Functions
+export * from './functions/getConfigAi'
+export * from './functions/getDirname'
+export * from './functions/getPackageJson'
+export * from './functions/hasNativeDirname'
+export * from './functions/run'
+
+// Types
+export * from './types/aiTypes'
+export * from './types/configTypes'
+export * from './types/designTypes'
+export * from './types/figmaApiTypes'
+export * from './types/gitTypes'
+export * from './types/libraryTypes'
+export * from './types/propertyTypes'
+export * from './types/screenshotTypes'
+export * from './types/webTypes'

package/src/media/templates/componentDoc/materials/{prompt.txt → prompt.md}

@@ -13,13 +13,13 @@ The target parent directory (one level up from this "materials" directory) repre
 - `wiki/`: Storybook playground configuration and documentation files:
   - `[ComponentName].mdx`: MDX documentation tab/documentation configuration for Storybook.
   - `[ComponentName].stories.ts`: Storybook stories/scenarios configuration.
-  - `prompt.txt`: The system prompt directing how to generate MDX/Storybook documentation.
-  - `run.ts`: A script running `npx dxt-component-wiki` to write the MDX files automatically using `wiki/prompt.txt`.
+  - `prompt.md`: The system prompt directing how to generate MDX/Storybook documentation.
+  - `run.ts`: A script running `npx dxt-component-wiki` to write the MDX files automatically using `wiki/prompt.md`.
 
 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.txt` 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.txt`) to ensure perfect compatibility with the local package architecture.
+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.
 
 ---

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

@@ -0,0 +1,21 @@
+Task Goal:
+The primary goal is to write comprehensive, high-quality documentation for the Vue 3 component.
+
+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.
+
+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
+
+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).
+
+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.)
+
+---
+CRITICAL PRIORITY RULE:
+Everything below this line has a higher priority than the text above it.

package/src/media/templates/componentDoc/wiki/run.ts

@@ -7,7 +7,7 @@ import { readFileSync } from 'node:fs'
 ;(async () => {
   try {
     // You can add prompt generation logic here
-    const prompt = readFileSync(new URL('./prompt.txt', import.meta.url), 'utf-8')
+    const prompt = readFileSync(new URL('./prompt.md', import.meta.url), 'utf-8')
 
     const child = spawn(
       'npx',

package/src/media/templates/packages/library/package.json

@@ -11,14 +11,16 @@
     "test": "vitest",
     "component": "dxt-component",
     "library": "dxt-library",
-    "wiki": "dxt-ai-doc"
+    "types": "npm run prepublishOnly && dxt-types",
+    "wiki": "dxt-ai-doc",
+    "prepublishOnly": "npm run library && npm run build",
+    "publish-to-npm": "npm publish --access public"
   },
   "files": [
     "dist",
-    "ai-description.txt",
-    "ai-doc.ru.txt",
-    "ai-doc.txt",
-    "ai-types.txt",
+    "ai-description.md",
+    "ai-doc.md",
+    "ai-types.md",
     "CHANGELOG.md",
     "LICENSE",
     "package.json",

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

@@ -0,0 +1,77 @@
+### Global Development Principles (AI Code Promise)
+
+Your primary goal is to generate flawless, industrial-grade code that adheres to dxt-ui standards. You promise to follow these rules strictly:
+
+0. **Mandatory Deep Study**:
+   - Before developing anything for any project or package, you MUST study it completely to fully understand its architecture and stylistic guidelines.
+   - Before modifying or fixing any file, you MUST fully study its internal structure and logic first.
+   - If any instructions, paths, or files are specified as located inside `node_modules/` or any other external/linked directory, you MUST first check if this package exists locally in the workspace (for example, under `packages/`). If it does exist locally, you MUST resolve the paths to the local workspace package directory and study/modify the local source files instead.
+   - **CRITICAL FIRST STEP:** If any project, module, or instruction contains links or references to specific files (e.g. types, developer guides, descriptions), you MUST study all these referenced files as your absolute first action. As soon as you start working with a project, or notice that it is imported/used in the code you are working with, you must immediately read and study all these referenced files before doing any planning, proposing code changes, or writing code. This is mandatory and applies even if the files are located in `node_modules/` (always resolve them to the local workspace directory first if they exist locally).
+   - **STRICT BLOCKING GUARD (CHRONOLOGICAL ORDER RULES):**
+     1. As your ABSOLUTE FIRST ACTION, before taking any other steps, you MUST check if the `ai-memory.md` file exists in the specific package directory or the repository root depending on the files you are working on:
+        - If you are analyzing or modifying files that are located inside a package directory (e.g., any subdirectory under `packages/` like `packages/constructor/`, `packages/scripts/`, etc.), you MUST read/write the `ai-memory.md` file ONLY within that specific package directory (e.g. `packages/constructor/ai-memory.md` or `packages/scripts/ai-memory.md`). You are strictly FORBIDDEN from using, reading, or writing the global `ai-memory.md` in the repository root in this case.
+        - If and only if the files you are working with are root-level configurations or not part of any package under `packages/`, you may read/write the `ai-memory.md` file in the repository root.
+        If the required local package-level `ai-memory.md` (or root `ai-memory.md` for root-level files) exists, you MUST read it using `view_file`. If it does NOT exist, you MUST CREATE IT immediately using `write_to_file` as an empty file with only a single newline (no placeholder text, comments, or intro text).
+     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.
+
+1. **"Copy-Paste Ready" Principle**:
+   - Generate code that can be copied and run without a single manual edit.
+   - All imports must be absolute or correct relative paths.
+   - No `// ... rest of the code`, no `// imports here`. Only the complete, working file.
+
+2. **Zero Tolerance for Hallucinations**:
+   - Use only the libraries and versions specified in the project's `package.json`.
+   - Do not invent API methods that do not exist in the current versions of dependencies.
+   - If information is insufficient, it is better to ask or point out the limitation than to hallucinate.
+
+3. **Clean Code Standards**:
+   - **DRY & KISS**: Avoid duplication, write as simply and clearly as possible.
+   - **SOLID**: Every module, class, or function must have one clear responsibility.
+   - **Declarative Approach**: Prefer a declarative programming style (array functional methods, composition).
+   - **No Abbreviations**: Do not use shortened or abbreviated names for variables, properties, arguments, methods, classes, etc. (e.g., do not use `el`, `rect1`/`r1`, `dx`/`dy`, `val`, `temp`). All identifiers must be descriptive, complete, and self-explanatory.
+   - **Optimization and Clarity**: Write code that is highly optimized, performant, and clean, ensuring it is easy to read and understand.
+   - **Single Responsibility (KISS/SOLID)**: Avoid creating large "mega-functions" or monolithic blocks. Each function must be concise and perform exactly one focused task (1 function = 1 functionality).
+
+4. **Uncompromising TypeScript**:
+   - No `any`. Use `unknown` if the type is truly unknown, or create generic types.
+   - Never use `@ts-ignore`. If a type check suppression is absolutely necessary due to external limitations, use `@ts-expect-error` with a descriptive comment explaining why.
+   - Always define interfaces for input and output data.
+   - Use `as const`, `readonly`, and enums/union types to increase reliability.
+
+5. **Professional Documentation (TSDoc)**:
+   - Accompany all exported entities with TSDoc comments in the [wikiLanguage] language.
+   - Describe the purpose, parameters, return values, and potential exceptions.
+   - Usage examples in comments are encouraged for complex functions.
+
+6. **Architectural Consistency**:
+   - Respect the project structure. If it is standard in the project to move logic into `composables` or `utils`, follow that pattern.
+   - Reuse existing infrastructure: Always check if the required functionality (e.g., API requests, state management, utilities) already exists in the project's core packages (like `@dxtmisha/functional` or `@dxtmisha/functional-basic`) before implementing it from scratch.
+   - Do not modify global styles or styles of base UI components unless explicitly requested.
+
+7. **Security and Performance**:
+   - Write error-proof code (guard clauses, optional chaining `?.`, nullish coalescing `??`).
+   - Use explicit `try-catch` blocks for asynchronous operations. Never swallow errors silently; handle them appropriately or throw meaningful error messages.
+   - Avoid redundant calculations in loops and heavy operations in reactive dependencies.
+
+8. **Aesthetics and Conciseness**:
+   - The code must be beautiful. Use logical indentation and group code by meaning.
+   - Save tokens by avoiding redundant comments where the code speaks for itself.
+
+9. **Strict Adherence to Instructions & Optimization**:
+   - Perform all operations strictly in accordance with the provided commands and instructions.
+   - Avoid guessing or performing unrelated extra actions. However, you are encouraged to analyze the requirements, optimize the code, and propose or implement better technical solutions directly related to achieving the task's goals.
+   - Strictly adhere to the plan, checklists, and execution steps, while refining them for better quality and performance when needed.
+
+10. **AI Workspace Memory (`ai-memory.md`)**:
+    - As enforced by the STRICT BLOCKING GUARD, `ai-memory.md` MUST be created and read locally inside the root of the specific package you are working with (e.g., `packages/constructor/ai-memory.md` for code in `packages/constructor`).
+    - Writing or reading `ai-memory.md` in the repository root when working on code inside a package is a critical violation of these rules.
+    - Whenever you receive feedback, corrections, or instructions from the developer, you MUST update that specific package's local `ai-memory.md` file.
+    - Explicit Memorization Requests: If the developer explicitly instructs you to "remember this", "keep this in mind", or makes a similar request regarding conventions or rules, you MUST immediately record this information in the relevant local `ai-memory.md` file.
+    - 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.
+

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

@@ -0,0 +1,78 @@
+### Глобальные принципы разработки (AI Code Promise)
+
+Твоя главная цель — генерировать безупречный, промышленный код, который соответствует стандартам dxt-ui. Ты обещаешь следовать этим правилам неукоснительно:
+
+0. **Обязательное глубокое изучение**:
+   - Прежде чем разрабатывать что-либо для любого проекта или пакета, ты ОБЯЗАН полностью изучить его, чтобы детально понять его архитектуру и стилистику.
+   - Прежде чем изменять или исправлять любой файл, ты ОБЯЗАН полностью изучить его внутреннюю структуру и логику.
+   - Если в инструкциях, путях или файлах указано расположение внутри `node_modules/` или любой другой внешней/привязанной директории, ты ОБЯЗАН сначала проверить, существует ли этот пакет локально в рабочей области (например, в каталоге `packages/`). Если пакет существует локально, ты ОБЯЗАН переопределить пути на локальный каталог пакета рабочей области и изучать/изменять локальные исходные файлы вместо указанных.
+   - **КРИТИЧЕСКИЙ ПЕРВЫЙ ШАГ:** Если какой-либо проект, модуль или инструкция содержит ссылки или пути к конкретным файлам (например, типы, руководства для разработчиков, описания), ты ОБЯЗАН подробно изучить все эти файлы по ссылкам в первую очередь. Как только ты начинаешь работу с проектом или видишь, что он импортируется/используется в коде, над которым ты работаешь, ты должен незамедлительно прочитать и изучить все эти файлы по ссылкам, прежде чем приступать к планированию, предложению изменений или написанию кода. Это требование обязательно и распространяется в том числе на файлы, находящиеся в `node_modules/` (всегда сначала переопределяй пути на локальный каталог рабочей области, если они существуют локально).
+   - **БЛОКИРУЮЩИЙ КОНТРОЛЬ ПОСЛЕДОВАТЕЛЬНОСТИ (ПРАВИЛО ХРОНОЛОГИИ):**
+     1. В качестве АБСОЛЮТНО ПЕРВОГО ДЕЙСТВИЯ, прежде чем выполнять любые другие шаги, ты ОБЯЗАН проверить, существует ли файл `ai-memory.md` в директории конкретного пакета или корня репозитория, в зависимости от файлов, с которыми ты работаешь:
+        - Если ты анализируешь или изменяешь файлы, находящиеся внутри каталога пакета (например, в любом подкаталоге внутри `packages/`, таком как `packages/constructor/`, `packages/scripts/` и т.д.), ты ОБЯЗАН читать/записывать файл `ai-memory.md` ИСКЛЮЧИТЕЛЬНО внутри каталога этого конкретного пакета (например, `packages/constructor/ai-memory.md` или `packages/scripts/ai-memory.md`). Тебе строго ЗАПРЕЩЕНО использовать, читать или записывать глобальный `ai-memory.md` в корне всего репозитория в этом случае.
+        - Если и только если файлы, с которыми ты работаешь, являются конфигурациями корневого уровня или не относятся к какому-либо пакету внутри `packages/`, ты можешь читать/записывать `ai-memory.md` в корне репозитория.
+        Если требуемый локальный файл `ai-memory.md` пакета (или корневой `ai-memory.md` для файлов корневого уровня) существует, ты ОБЯЗАН прочитать его с помощью `view_file`. Если его НЕТ, ты ОБЯЗАН НЕМЕДЛЕННО СОЗДАТЬ ЕГО с помощью `write_to_file` как пустой файл с одной лишь новой строкой (без плейсхолдеров, комментариев или вводного текста).
+     2. В качестве АБСОЛЮТНО ВТОРОГО ДЕЙСТВИЯ, ты ОБЯЗАН использовать инструмент `view_file` для чтения главного файла `ai-prompt.md` в корне проекта. Ты ОБЯЗАН изучить описания ВСЕХ библиотек, упомянутых в этом файле. Если тебе кажется хотя бы на мизерный процент (1%), что в какой-либо библиотеке есть что-то подходящее или полезное для твоей задачи, ты ОБЯЗАН изучить все файлы в этой библиотеке, которые указаны в `ai-prompt.md` в разделе этой библиотеки. Тебе строго запрещено писать кастомные реализации (хелперы, стили, конфигурации, классы) или придумывать свое, не проверив предварительно существующую инфраструктуру рабочей области (например, `functional`, `functional-basic`).
+     3. Определи все пути пакетов или директорий, связанных с запросом.
+     4. Найди в промпте секции, соответствующие этим путям.
+     5. Выпиши все пути к вспомогательным файлам типов и руководств, упомянутые в этих секциях.
+     6. Ты ОБЯЗАН использовать инструмент `view_file` для чтения и изучения ВСЕХ этих файлов ДО ТОГО, как вызывать `list_dir` для папок компонентов, писать какие-либо планы/чек-листы или вносить/предлагать изменения в код. Нарушение этой последовательности является критическим нарушением протокола.
+
+
+
+1. **Принцип «Copy-Paste Ready» (Готовность к использованию)**:
+   - Генерируй код, который можно скопировать и запустить без единой правки.
+   - Все импорты должны быть абсолютными или корректными относительными.
+   - Никаких `// ... остальной код`, никаких `// импорты здесь`. Только полный, рабочий файл.
+
+2. **Нулевая толерантность к галлюцинациям**:
+   - Используй только те библиотеки и версии, которые указаны в `package.json` проекта.
+   - Не выдумывай методы API, которых не существует в текущих версиях зависимостей.
+   - Если информации недостаточно — лучше спроси или укажи на ограничение, чем галлюцинируй.
+
+3. **Стандарты чистого кода (Clean Code)**:
+   - **DRY & KISS**: Избегай дублирования, пиши максимально просто и понятно.
+   - **SOLID**: Каждый модуль, класс или функция должны иметь одну четкую ответственность.
+   - **Декларативность**: Отдавай предпочтение декларативному стилю программирования (функциональные методы массивов, композиция).
+   - **Никаких сокращений**: Запрещено использовать сокращенные имена для переменных, свойств, аргументов, методов, классов и т. д. (например, нельзя использовать `el`, `rect1`/`r1`, `dx`/`dy`, `val`, `temp`). Все идентификаторы должны быть информативными, полными и самодокументируемыми.
+   - **Оптимизация и понятность**: Код должен быть максимально оптимизированным, производительным и понятным, обеспечивающим легкое чтение и поддержку.
+   - **Принцип единой ответственности**: Избегай создания больших «мега-функций» или монолитных блоков. Каждая функция должна быть лаконичной и решать ровно одну задачу (1 функция — 1 функционал).
+
+4. **Бескомпромиссный TypeScript**:
+   - Никаких `any`. Используй `unknown`, если тип действительно неизвестен, или создавай generic-типы.
+   - Никогда не используй `@ts-ignore`. Если подавление проверки типов абсолютно необходимо из-за внешних ограничений, используй `@ts-expect-error` с обязательным поясняющим комментарием.
+   - Всегда определяй интерфейсы для входных и выходных данных.
+   - Используй `as const`, `readonly` и перечисления (enums/union types) для повышения надежности.
+
+5. **Профессиональное документирование (TSDoc)**:
+   - Сопровождай все экспортируемые сущности комментариями TSDoc на [wikiLanguage] языке.
+   - Описывай назначение, параметры, возвращаемые значения и возможные исключения.
+   - Примеры использования в комментариях приветствуются для сложных функций.
+
+6. **Архитектурная консистентность**:
+   - Соблюдай структуру проекта. Если в проекте принято выносить логику в `composables` или `utils` — следуй этому паттерну.
+   - Переиспользование инфраструктуры: Всегда проверяй, существует ли необходимый функционал (например, API-запросы, управление состоянием, утилиты) в базовых пакетах проекта (таких как `@dxtmisha/functional` или `@dxtmisha/functional-basic`), прежде чем писать его с нуля.
+   - Не изменяй глобальные стили или стили базовых UI-компонентов, если это не было явно запрошено.
+
+7. **Безопасность и Производительность**:
+   - Пиши код, защищенный от ошибок (guard clauses, опциональная цепочка `?.`, nullish coalescing `??`).
+   - Используй явные блоки `try-catch` для асинхронных операций. Никогда не "проглатывай" ошибки молча; обрабатывай их корректно или выбрасывай информативные сообщения об ошибках.
+   - Избегай лишних вычислений в циклах и тяжелых операций в реактивных зависимостях.
+
+8. **Эстетика и Лаконичность**:
+   - Код должен быть красивым. Используй логические отступы и группировку кода по смыслу.
+   - Экономь токены, избегая избыточных комментариев там, где код говорит сам за себя.
+
+9. **Строгое следование инструкциям и оптимизация**:
+   - Выполняй все действия строго в соответствии с предоставленными командами и инструкциями.
+   - Избегай додумывания или выполнения не связанных с задачей лишних действий. Тем не менее, приветствуется глубокий анализ требований, оптимизация кода, а также поиск и реализация лучших технических решений, напрямую направленных на достижение целей поставленной задачи.
+   - Строго придерживайся планов, чек-листов и шагов выполнения, улучшая и дорабатывая их для повышения качества и производительности по мере необходимости.
+
+10. **Память ИИ Пространства (`ai-memory.md`)**:
+    - Как установлено в БЛОКИРУЮЩЕМ КОНТРОЛЕ ПОСЛЕДОВАТЕЛЬНОСТИ, `ai-memory.md` ОБЯЗАТЕЛЬНО должен быть создан и прочитан локально внутри корня того конкретного пакета, с которым ты работаешь (например, `packages/constructor/ai-memory.md` для кода в `packages/constructor`).
+    - Запись или чтение `ai-memory.md` в корне репозитория при работе с кодом внутри пакета является критическим нарушением правил.
+    - Каждый раз, когда ты получаешь замечания, исправления или инструкции от разработчика, ты ОБЯЗАН обновить локальный файл `ai-memory.md` именно этого конкретного пакета.
+    - Явные запросы на запоминание: Если разработчик явно просит «запомнить это», «иметь в виду» или делает аналогичный запрос касательно соглашений или правил, ты ОБЯЗАН немедленно зафиксировать эту информацию в соответствующем локальном файле `ai-memory.md`.
+    - Активное применение: Ты ОБЯЗАН активно ПРИМЕНЯТЬ правила и ограничения из `ai-memory.md` ко всему генерируемому коду. Ограничения из этого файла имеют высший приоритет и переопределяют любые базовые предположения.
+    - ОСНОВНАЯ ЦЕЛЬ этого файла — хранение правил написания кода, архитектурных ограничений и принципов разработки (например: «не делай X, делай Y»), чтобы ИИ мог максимально правильно адаптировать и писать код.
+    - ЗАПРЕЩЕНО записывать туда историю изменений, списки обновленных файлов или сообщения в стиле коммитов (например: «обновлен файл X, обновлен пакет Y»). Файл должен содержать только актуальные стандарты, правила разработки и конструктивные требования к коду.

package/src/types/configTypes.ts

@@ -1,5 +1,12 @@
 /** AI type for content generation / Тип ИИ для генерации контента */
-export type AiType = 'gemini' | 'gemini-cli'
+export type AiType
+  = | 'claude'
+    | 'claude-cli'
+    | 'claude-agent'
+    | 'gemini'
+    | 'gemini-cli'
+    | 'openai'
+    | 'zai'
 
 /** Configuration structure for the design system UI project / Структура конфигурации для проекта дизайн-системы UI */
 export type DesignUiConfig = {
@@ -40,7 +47,7 @@ export type DesignUiConfig = {
   packagePrefix?: string
 
   /** AI type for generating content / Тип ИИ для генерации контента */
-  aiType?: 'gemini'
+  aiType?: AiType
 
   /** AI model for generating content / Модель ИИ для генерации контента */
   aiModel?: string

package/src/types/webTypes.ts

@@ -17,6 +17,7 @@ export type WebTypesInfo = {
 export type WebTypesProperty = {
   name: string
   type?: string
+  description?: string
 }
 export type WebTypesProperties = WebTypesProperty[]
 
@@ -51,7 +52,8 @@ export type WebTypesAttributes = WebTypesAttributeItem[]
 export type WebTypesEventItem
   = WebTypesInfo
     & {
-      arguments: WebTypesProperties
+      arguments?: WebTypesProperties
+      type?: string
     }
 export type WebTypesEvents = WebTypesEventItem[]
 
@@ -85,21 +87,48 @@ export type WebTypesTagItem
     }
 export type WebTypesTags = WebTypesTagItem[]
 
+/**
+ * Prop definition for a Vue component.
+ *
+ * Определение свойства для Vue-компонента.
+ */
+export type WebTypesPropItem = WebTypesInfo & {
+  default?: string
+  type?: string
+}
+
+/**
+ * Vue component definition for Web-Types.
+ *
+ * Определение Vue-компонента для Web-Types.
+ */
+export type WebTypesVueComponentItem = WebTypesInfo & {
+  source?: {
+    module?: string
+    symbol?: string
+  }
+  props?: WebTypesPropItem[]
+  slots?: WebTypesSlots
+  js?: {
+    events?: WebTypesEventItem[]
+  }
+}
+
 /**
  * Root object for Web Types JSON.
  *
  * Корневой объект для JSON Web Types.
  */
 export type WebTypesVueJson = {
-  $schema: 'https://json.schemastore.org/web-types'
+  $schema: string
   framework: 'vue'
   name: string
   version: string
+  'js-types-syntax'?: 'typescript'
   contributions: {
     html: {
-      'types-syntax': 'typescript'
       'description-markup': 'markdown'
-      'tags': WebTypesTags
+      'vue-components': WebTypesVueComponentItem[]
     }
   }
 }

package/src/classes/Component/__tests__/ComponentCreator.test.ts

@@ -1,71 +0,0 @@
-import { describe, expect, it, vi, beforeEach } from 'vitest'
-import { ComponentCreator } from '../ComponentCreator'
-import { PropertiesFile } from '../../Properties/PropertiesFile'
-import { ComponentItem } from '../ComponentItem'
-import { getComponentPaths } from '../../../functions/getComponentPaths'
-import { UI_DIRS_COMPONENTS } from '../../../config'
-
-vi.mock('../../Properties/PropertiesFile', () => ({
-  PropertiesFile: {
-    readDirOnlyRecursive: vi.fn(),
-    readDir: vi.fn()
-  }
-}))
-
-vi.mock('../ComponentItem', () => ({
-  ComponentItem: vi.fn().mockImplementation(function () {
-    return {
-      make: vi.fn()
-    }
-  })
-}))
-
-vi.mock('../../../functions/getComponentPaths', () => ({
-  getComponentPaths: vi.fn(path => [path, 'full'])
-}))
-
-describe('ComponentCreator', () => {
-  let creator: ComponentCreator
-
-  beforeEach(() => {
-    vi.clearAllMocks()
-    creator = new ComponentCreator()
-  })
-
-  it('make should call ComponentItem.make for each empty directory', () => {
-    vi.mocked(PropertiesFile.readDirOnlyRecursive).mockReturnValue(['dir1', 'dir2', 'dir3'])
-    vi.mocked(PropertiesFile.readDir).mockImplementation((path) => {
-      if (Array.isArray(path) && path[0] === 'dir2') return ['file.ts']
-      return []
-    })
-
-    creator.make()
-
-    expect(ComponentItem).toHaveBeenCalledWith('dir1')
-    expect(ComponentItem).not.toHaveBeenCalledWith('dir2')
-    expect(ComponentItem).toHaveBeenCalledWith('dir3')
-
-    const mockInstance1 = vi.mocked(ComponentItem).mock.results[0]?.value
-    const mockInstance2 = vi.mocked(ComponentItem).mock.results[1]?.value
-
-    expect(mockInstance1?.make).toHaveBeenCalled()
-    expect(mockInstance2?.make).toHaveBeenCalled()
-  })
-
-  it('getDirs should return only empty directories', () => {
-    vi.mocked(PropertiesFile.readDirOnlyRecursive).mockReturnValue(['empty', 'not-empty'])
-    vi.mocked(PropertiesFile.readDir).mockImplementation((path) => {
-      if (Array.isArray(path) && path[0] === 'not-empty') return ['index.ts']
-      return []
-    })
-
-    // Access protected method for testing
-    const dirs = (creator as any).getDirs()
-
-    expect(dirs).toContain('empty')
-    expect(dirs).not.toContain('not-empty')
-    expect(dirs).toHaveLength(1)
-    expect(PropertiesFile.readDirOnlyRecursive).toHaveBeenCalledWith(UI_DIRS_COMPONENTS)
-    expect(getComponentPaths).toHaveBeenCalledWith('empty')
-  })
-})

package/src/classes/Component/__tests__/ComponentItem.test.ts

@@ -1,71 +0,0 @@
-import { describe, expect, it, vi, beforeEach } from 'vitest'
-import { ComponentItem } from '../ComponentItem'
-import { PropertiesFile } from '../../Properties/PropertiesFile'
-import { toKebabCase } from '@dxtmisha/functional-basic'
-
-vi.mock('../../Properties/PropertiesFile', () => ({
-  PropertiesFile: {
-    splitForDir: vi.fn(path => path.split('/')),
-    readFile: vi.fn(),
-    writeByPath: vi.fn(),
-    chmod: vi.fn(),
-    readDirRecursive: vi.fn()
-  }
-}))
-
-vi.mock('../../../functions/getComponentPaths', () => ({
-  getComponentPaths: vi.fn(path => [path, 'full'])
-}))
-
-describe('ComponentItem', () => {
-  let item: ComponentItem
-  const mockPath = 'src/components/TestComponent'
-
-  beforeEach(() => {
-    vi.clearAllMocks()
-    item = new ComponentItem(mockPath)
-  })
-
-  it('getName should return the last part of the path', () => {
-    const name = (item as any).getName()
-    expect(name).toBe('TestComponent')
-    expect(PropertiesFile.splitForDir).toHaveBeenCalledWith(mockPath)
-  })
-
-  it('getProjectName should return package name or "Project"', () => {
-    vi.mocked(PropertiesFile.readFile).mockReturnValue({ name: 'test-project' })
-    const projectName = (item as any).getProjectName()
-    expect(projectName).toBe('test-project')
-
-    vi.mocked(PropertiesFile.readFile).mockReturnValue(undefined)
-    expect((item as any).getProjectName()).toBe('Project')
-  })
-
-  it('replacement should replace placeholders correctly', () => {
-    vi.mocked(PropertiesFile.readFile).mockReturnValue({ name: 'test-project' })
-    const content = 'Name: ComponentDoc, kebab: component-doc, project: [project], path: [path]'
-    const result = (item as any).replacement(content)
-
-    expect(result).toContain('Name: TestComponent')
-    expect(result).toContain(`kebab: ${toKebabCase('TestComponent')}`)
-    expect(result).toContain('project: test-project')
-    expect(result).toContain(`path: ${mockPath}`)
-  })
-
-  it('make should read templates and write files with replacements', () => {
-    vi.mocked(PropertiesFile.readDirRecursive).mockReturnValue(['Template.ts'])
-    vi.mocked(PropertiesFile.readFile).mockImplementation((path) => {
-      if (Array.isArray(path) && path.includes('package.json')) return { name: 'test-project' }
-      return 'export class ComponentDoc {}'
-    })
-
-    item.make()
-
-    expect(PropertiesFile.readDirRecursive).toHaveBeenCalled()
-    expect(PropertiesFile.writeByPath).toHaveBeenCalledWith(
-      expect.arrayContaining([mockPath, 'Template.ts']),
-      'export class TestComponent {}'
-    )
-    expect(PropertiesFile.chmod).toHaveBeenCalled()
-  })
-})