@dxtmisha/scripts 0.10.6 → 0.10.8

package/CHANGELOG.md

@@ -2,6 +2,18 @@
 
 All notable changes to this project will be documented in this file.
 
+## [0.10.8] - 2026-07-28
+
+### Added / Updated
+- **AI Prompt Templates**: Overhauled global AI prompt templates (`aiCodeGlobalPrompt.en.md`, `aiCodeGlobalPrompt.ru.md`) with streamlined rules, mandatory deep study workflows (`view_file`), prohibition of superficial code scans, and full-file self-audit requirements.
+- **DesignReplace**: Escaped dollar sign (`$`) characters in replacement value strings in `DesignReplace` to prevent regex capture group interpolation issues during template processing.
+- **DesignTypes**: Added JavaScript File Validator and improved TypeScript schema generation and translation logic.
+
+## [0.10.7] - 2026-07-06
+
+### Changed
+- **DesignTypes**: Updated the AI prompt in `DesignTypes.toAiEdit` to translate Russian JSDocs/comments to English instead of just removing them, if an English version is missing.
+
 ## [0.10.6] - 2026-07-05
 
 ### Changed

package/package.json

@@ -1,7 +1,7 @@
 {
   "name": "@dxtmisha/scripts",
   "private": false,
-  "version": "0.10.6",
+  "version": "0.10.8",
   "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/Design/DesignReplace.ts

@@ -132,6 +132,7 @@ export class DesignReplace {
       const value = data
         .join(`${end}${inString}`)
         .replace(/\[space]/g, inString)
+        .replace(/\$/g, '$$$$')
 
       if (value.trim() !== '') {
         this.sample = this.sample

package/src/classes/Design/DesignTypes.ts

@@ -45,9 +45,12 @@ export class DesignTypes {
     console.log('DesignTypes: making AI types...')
 
     const files = this.getListByFilter()
+    const jsFiles = this.getListByFilterJs()
+
     const fullContent = this.toOneFile(files)
+    const fullJsContent = this.toOneFile(jsFiles)
 
-    const aiContent = await this.toAiEdit(fullContent)
+    const aiContent = await this.toAiEdit(fullContent, fullJsContent)
     this.save(aiContent)
 
     const aiDescription = await this.toAiDescription(fullContent)
@@ -75,6 +78,16 @@ export class DesignTypes {
       )
   }
 
+  /**
+   * Checks if the file is a valid JavaScript or TypeScript file.
+   *
+   * Проверяет, является ли файл валидным JavaScript или TypeScript файлом.
+   * @param file file name / имя файла
+   */
+  protected isFileJs(file: string): boolean {
+    return file.endsWith('.js')
+  }
+
   /**
    * Checks if the content contains type definitions.
    *
@@ -108,15 +121,16 @@ export class DesignTypes {
   }
 
   /**
-   * Gets a list of files filtered by criteria.
+   * Gets a list of files filtered by a provided checker function.
    *
-   * Получает список файлов, отфильтрованный по критериям.
+   * Получает список файлов, отфильтрованный переданной функцией проверки.
+   * @param checkFile function to check if the file matches criteria / функция проверки соответствия файла критериям
    */
-  protected getListByFilter(): DesignTypesList {
+  protected getListBy(checkFile: (file: string) => boolean): DesignTypesList {
     return forEach(
       this.getList(),
       (file) => {
-        if (this.isFile(file)) {
+        if (checkFile(file)) {
           const content = this.readFile(file)
 
           if (this.isContent(content)) {
@@ -132,6 +146,24 @@ export class DesignTypes {
     ) as DesignTypesList
   }
 
+  /**
+   * Gets a list of files filtered by criteria.
+   *
+   * Получает список файлов, отфильтрованный по критериям.
+   */
+  protected getListByFilter(): DesignTypesList {
+    return this.getListBy(file => this.isFile(file))
+  }
+
+  /**
+   * Gets a list of JS files filtered by criteria.
+   *
+   * Получает список JS файлов, отфильтрованный по критериям.
+   */
+  protected getListByFilterJs(): DesignTypesList {
+    return this.getListBy(file => this.isFileJs(file))
+  }
+
   /**
    * Reads the content of a file.
    *
@@ -201,14 +233,23 @@ export class DesignTypes {
    * Отправляет контент и промпт ИИ для обработки.
    * @param content content for processing / контент для обработки
    * @param prompt instructions for the AI / инструкции для ИИ
+   * @param code code to optimize / код для оптимизации
    */
-  protected async toAi(content: string, prompt: string): Promise<string | undefined> {
+  protected async toAi(
+    content: string,
+    prompt: string,
+    code?: string
+  ): Promise<string | undefined> {
     const ai = useAi()
 
     if (ai) {
       ai.addPrompt(prompt)
       ai.addPrompt(`File Content: ${content}`)
 
+      if (code) {
+        ai.addPrompt(`File JS Code: ${code}`)
+      }
+
       const generate = await ai.generate('go!')
 
       if (generate) {
@@ -224,14 +265,18 @@ export class DesignTypes {
    *
    * Отправляет контент ИИ для оптимизации.
    * @param content content to optimize / контент для оптимизации
+   * @param code code to optimize / код для оптимизации
    */
-  protected async toAiEdit(content: string): Promise<string> {
+  protected async toAiEdit(content: string, code: string): Promise<string> {
     const generate = await this.toAi(
       content,
-      'Remove all Russian comments from this code. '
-      + 'Shorten English comments for AI; keep context but be brief. Do not delete obvious comments. '
-      + 'Always keep All JSDoc "@example", "@remarks", "@note", and any other notes or warnings. '
-      + 'Remove all imports. '
+      'TRANSLATE all non-English comments (including JSDocs and inline comments) to English. '
+      + 'Optimize the provided type definitions, improve and supplement them if necessary. '
+      + 'Carefully study the provided JS code to understand its logic and what the code does. '
+      + 'Remove redundant or self-explanatory JSDoc comments for any entity (types, properties, variables, functions, methods, etc.) if their meaning is obvious from their name or signature and does not require documentation. '
+      + 'Keep or add clear English JSDoc comments for entities that are complex, non-obvious, or require explanation. '
+      + 'CRITICAL: Always keep all JSDoc "@example", "@remarks", "@note", and any other notes or warnings. Their contents must NOT be modified, altered, or rewritten—keep them exactly as written, only translating them to English if they are not in English. '
+      + 'CRITICAL: Remove all imports. Remove all local internal re-exports (e.g., `export * from "./..."`), but strictly KEEP any exports from external libraries or packages. '
       + 'Remove all non-public content: delete all private and protected class methods and properties, and any non-exported elements. The final output must contain only the members and entities that are accessible from outside. '
       + 'Remove any code segments or data that do not provide useful information for an AI assistant. '
       + 'You may remove abstract classes or other structures that provide no practical value for code generation, but do so with extreme caution. Maintain a strict balance: if there is even a 5% chance the item might be relevant for understanding the API or generating code, keep it. Think carefully before every deletion. '
@@ -239,9 +284,12 @@ export class DesignTypes {
       + 'Your goal is to create a compact, context-rich file that enables any AI coding assistant to generate high-quality code for a developer. '
       + 'Ensure that no public API surface, essential data types, or required logic is lost. '
       + 'Do not delete any "type" definitions; they are strictly required. '
-      + 'Do not delete file paths (labels starting with "// File:"). '
+      + 'Remove all regular comments and inline comments (lines starting with "//" or "/* ... */"). '
+      + 'Do not include empty lines; keep the output compact and tight without blank lines. '
+      + 'CRITICAL: Do NOT return the provided JS code in your response. '
       + 'All instructions are mandatory and must be executed perfectly. '
-      + 'Return ONLY the resulting code. No markdown code blocks, no tags, no explanations, and no additional comments from the AI. NOTHING but the pure code.'
+      + 'Return ONLY the resulting optimized type definitions code. No markdown code blocks, no tags, no explanations, and no additional comments from the AI. NOTHING but the pure code.',
+      code
     )
 
     return generate ?? content

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

@@ -1,78 +1,21 @@
 ### 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 (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.
-   - 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.
-    - 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.
-
+Strictly follow these rules for flawless dxt-ui code:
+
+0. **Mandatory Deep Study (CHRONOLOGICAL GUARD)**:
+   - **Step 1**: Read/create local `ai-memory.md` strictly in the current package root (e.g., `packages/constructor/`). Using repository root `ai-memory.md` for package files is FORBIDDEN.
+   - **Step 2**: Read root `ai-prompt.md` and study descriptions of all mentioned libraries.
+   - **Step 3**: Read all linked `ai-types.md` and `ai-developer.md` BEFORE proposing plans, calling `list_dir`, or writing code. If a package is in `node_modules/` but exists locally (e.g., `packages/`), resolve and study the local source instead.
+   - Fully read files via `view_file` before modifying. Superficial scans (grep only) are strictly forbidden. Always check existing infrastructure before writing custom logic.
+
+1. **"Copy-Paste Ready"**: Generate complete, runnable files with correct imports. No placeholders (e.g., `// rest of code`).
+2. **Zero Hallucinations**: Strictly use `package.json` dependencies. No invented APIs. Ask if unsure.
+3. **Clean Code (DRY/KISS/SOLID)**: Declarative style. Single responsibility (1 task = 1 function). No abbreviations (`el`, `val`, etc. are forbidden). Optimized and legible.
+4. **Uncompromising TS**: No `any` (use `unknown` or generics). Interfaces for all I/O. `as const`, `readonly`, enums. Use `@ts-expect-error` with comments, never `@ts-ignore`.
+5. **Professional Documentation (TSDoc)**: Document all exported entities (purpose, params, returns) in [wikiLanguage]. Include examples for complex logic.
+6. **Architectural Consistency**: Respect project structure. Reuse existing infrastructure (always check `ai-types.md` first). Do not modify global/base UI styles unless explicitly requested.
+7. **Security & Performance**: Error-proof code (`?.`, `??`, guard clauses). Use explicit `try-catch` for async. Never swallow errors. Avoid heavy ops in loops/reactivity.
+8. **Aesthetics & Conciseness**: Group logically. Save tokens by avoiding redundant comments if code is self-explanatory.
+9. **Strict Adherence & Optimization**: Follow instructions precisely without guessing. Propose relevant technical optimizations while strictly adhering to plans.
+10. **AI Workspace Memory (`ai-memory.md`)**: Actively APPLY its rules (highest priority). Update it on developer feedback. Do NOT store change logs or absolute paths (use relative). Keep it focused strictly on architectural constraints.
+11. **Mandatory Full-File Self-Audit**: When creating new entities, you MUST audit the ENTIRE file (not just modified parts) to ensure no logic duplication (DRY) and full compliance with project rules. *Exception: minor bug fixes to existing code do not require a full audit.*

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

@@ -1,79 +1,21 @@
 ### Глобальные принципы разработки (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. Выпиши все пути к вспомогательным файлам типов и руководств (таким как `ai-types.md` или `ai-developer.md`), упомянутые в этих секциях.
-     6. Ты ОБЯЗАН использовать инструмент `view_file` для чтения и изучения ВСЕХ этих файлов (в частности, если для пакетов, с которыми ты работаешь, указаны файлы типов `ai-types.md` или руководств `ai-developer.md`, ты ОБЯЗАН прочитать их полностью) ДО ТОГО, как вызывать `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»). Файл должен содержать только актуальные стандарты, правила разработки и конструктивные требования к коду.
-    - ЗАПРЕЩЕНО указывать абсолютные пути к файлам (например, file:///... или локальные пути вроде /Users/...) в файле памяти. Все ссылки на файлы внутри проекта должны использовать относительные пути (например, src/types/textTypes.ts), чтобы этот файл корректно работал у других разработчиков на разных компьютерах и операционных системах.
+Строго следуй этим правилам для создания безупречного кода dxt-ui:
+
+0. **Обязательное глубокое изучение (БЛОКИРУЮЩИЙ КОНТРОЛЬ)**:
+   - **Шаг 1**: Читай/создавай локальный `ai-memory.md` СТРОГО в корне текущего пакета (напр., `packages/constructor/`). Использовать корневой `ai-memory.md` репозитория для файлов пакета ЗАПРЕЩЕНО.
+   - **Шаг 2**: Прочитай корневой `ai-prompt.md` и изучи описания всех упомянутых библиотек.
+   - **Шаг 3**: Прочитай все связанные `ai-types.md` и `ai-developer.md` ДО вызова `list_dir`, планирования или написания кода. Если пакет в `node_modules/` существует локально (в `packages/`), изучай/изменяй локальные исходники.
+   - Полностью читай файлы через `view_file` перед изменением. Поверхностное изучение (только grep) запрещено. Всегда проверяй существующую инфраструктуру перед написанием кастомной логики.
+
+1. **Готовность к использованию (Copy-Paste Ready)**: Генерируй полные, рабочие файлы с правильными импортами. Никаких заглушек (напр., `// остальной код`).
+2. **Нулевая толерантность к галлюцинациям**: Используй только зависимости из `package.json`. Не выдумывай API. Не знаешь — спроси.
+3. **Чистый код (DRY/KISS/SOLID)**: Декларативный стиль. Единая ответственность (1 задача = 1 функция). Запрет на сокращения (никаких `el`, `val`, `temp` и т.д.). Оптимизация и читаемость.
+4. **Бескомпромиссный TS**: Никаких `any` (используй `unknown` или generics). Интерфейсы для всех I/O. `as const`, `readonly`, enums. Только `@ts-expect-error` с комментариями, никогда `@ts-ignore`.
+5. **TSDoc документирование**: Документируй все экспорты (назначение, параметры, возвраты) на языке [wikiLanguage]. Примеры для сложной логики.
+6. **Архитектурная консистентность**: Соблюдай структуру. Переиспользуй инфраструктуру (сначала всегда читай `ai-types.md`). Не меняй глобальные/базовые UI стили без явного запроса.
+7. **Безопасность и Производительность**: Защищенный код (`?.`, `??`, guard clauses). Явный `try-catch` для асинхронности. Не скрывай ошибки. Избегай тяжелых операций в циклах/реактивности.
+8. **Эстетика и Лаконичность**: Логическая группировка. Экономь токены, избегая избыточных комментариев, если код очевиден.
+9. **Строгое следование инструкциям**: Выполняй команды без додумывания, но предлагай уместные технические оптимизации, придерживаясь плана.
+10. **Память ИИ (`ai-memory.md`)**: Активно ПРИМЕНЯЙ ее правила (высший приоритет). Обновляй при правках от разработчика. ЗАПРЕЩЕНО хранить историю изменений (changelogs) и абсолютные пути (только относительные). Только актуальные стандарты.
+11. **Обязательный полный самоаудит**: При создании новых сущностей ОБЯЗАТЕЛЬНО проверяй ВЕСЬ файл целиком. Строго контролируй отсутствие дублирования (DRY) и соблюдение всех правил проекта. *Исключение: мелкие правки существующего кода не требуют полного аудита.*