@dxtmisha/scripts 0.10.0 → 0.10.3

package/CHANGELOG.md

@@ -2,6 +2,24 @@
 
 All notable changes to this project will be documented in this file.
 
+## [0.10.3] - 2026-06-25
+
+### Added
+- **Web-Types Generation**: Modernized component Web-Types generation to support modern IDE contributions structure:
+  - Switched output generation schema from legacy HTML `'tags'` to the new `'vue-components'` syntax standard.
+  - Implemented typescript types (`WebTypesPropItem`, `WebTypesVueComponentItem`) to map components, slots, properties, symbols, events, descriptions, and JS interfaces.
+
+## [0.10.2] - 2026-06-18
+
+### Changed
+- **AI Documentation Support**: Migrated template files from `.txt` to `.md` extensions (prompts, rules, and helper templates) to align with standard markdown format.
+- **Developer Instructions**: Expanded default prompts with stricter code rules (banned `@ts-ignore`, mandated active usage of `ai-memory.md`).
+
+## [0.10.1] - 2026-06-17
+
+### Added
+- **AI Guidelines**: Integrated package-scoped memory rules to instruct the AI assistant to read or create the package-level `ai-memory.md` files for persistent guidelines.
+
 ## [0.10.0] - 2026-05-20
 
 ### Added

package/package.json

@@ -1,7 +1,7 @@
 {
   "name": "@dxtmisha/scripts",
   "private": false,
-  "version": "0.10.0",
+  "version": "0.10.3",
   "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/DesignTypes.ts

@@ -256,13 +256,14 @@ export class DesignTypes {
   protected async toAiDescription(content: string): Promise<string> {
     const generate = await this.toAi(
       content,
-      'Analyze the provided code and generate a highly technical, concise project overview for another AI coding assistant. '
-      + 'Your goal is to help the AI decide whether it needs to study this library to fulfill a user request. '
-      + 'The description must be objective, factual, and free of marketing fluff. '
+      'Analyze the provided code and generate a highly technical, structured, and concise project overview specifically designed for another AI coding assistant. '
+      + 'The description must enable the reading AI to immediately evaluate whether this library contains code, components, classes, or utilities useful for its current task, and when it is mandatory to read and analyze "ai-types.md". '
+      + 'The description must be objective, factual, precise, and free of marketing fluff. '
       + 'Include: '
-      + '1. Core Purpose: What is the primary function of this library? (e.g., UI component library, state management, utility for X). '
-      + '2. Usage Scenarios: In what specific cases and scenarios is this library indispensable? When should an AI study its API? '
-      + '3. Integration Context: How does it relate to other technologies in the stack (if evident)? '
+      + '1. Core Purpose: What is the primary technical function of this library? '
+      + '2. Key Expositions: What are the main classes, hooks, utilities, or components exposed by this project, and what specific tasks do they perform? '
+      + '3. Triggers for Studying ai-types.md: Under what specific conditions, keywords, or coding requirements is this library indispensable, making it mandatory for the AI to study its "ai-types.md" file? '
+      + '4. Integration Context: How does it connect with other technologies in the system stack? '
       + 'Ensure the structure is clean and enables immediate context retrieval. '
       + 'Return ONLY the resulting description text. No markdown, no labels like "Description:", no explanations. NOTHING but the pure content.'
     )

package/src/classes/Design/DesignWikiStorm.ts

@@ -6,7 +6,7 @@ import { PropertiesFile } from '../Properties/PropertiesFile'
 import { LibraryItems } from '../Library/LibraryItems'
 import { DesignWikiStormItem } from './DesignWikiStormItem'
 
-import type { WebTypesTags, WebTypesVueJson } from '../../types/webTypes'
+import type { WebTypesVueComponentItem, WebTypesVueJson } from '../../types/webTypes'
 
 /**
  * Engine for generating `web-types.json` to provide rich metadata and IDE support (IntelliSense) for the design system components in JetBrains editors (IntelliJ IDEA, WebStorm).
@@ -43,15 +43,15 @@ export class DesignWikiStorm {
 
     if (packageFile) {
       const data: WebTypesVueJson = {
-        $schema: 'https://json.schemastore.org/web-types',
+        $schema: 'https://raw.githubusercontent.com/JetBrains/web-types/master/schema/web-types.json',
         framework: 'vue',
         name: toCamelCaseFirst(PropertiesConfig.getDesignName()),
         version: packageFile.version,
+        'js-types-syntax': 'typescript',
         contributions: {
           html: {
-            'types-syntax': 'typescript',
             'description-markup': 'markdown',
-            'tags': await this.getComponents()
+            'vue-components': await this.getComponents()
           }
         }
       }
@@ -68,9 +68,9 @@ export class DesignWikiStorm {
    *
    * Создает или обновляет список компонентов.
    */
-  protected async getComponents(): Promise<WebTypesTags> {
+  protected async getComponents(): Promise<WebTypesVueComponentItem[]> {
     const packageFile = getPackageJson()
-    const tags: WebTypesTags = []
+    const tags: WebTypesVueComponentItem[] = []
 
     if (packageFile) {
       for (const component of this.components.getComponentList()) {
@@ -85,7 +85,7 @@ export class DesignWikiStorm {
         const tag = await item.get()
 
         if (tag) {
-          tags.push(tag)
+          tags.push(tag as any)
         }
       }
     }

package/src/classes/Design/DesignWikiStormItem.ts

@@ -6,7 +6,7 @@ import { PropertiesConfig } from '../Properties/PropertiesConfig'
 import { PropertiesFile } from '../Properties/PropertiesFile'
 
 import type { LibraryData } from '../../types/libraryTypes'
-import type { WebTypesAttributeItem, WebTypesAttributes, WebTypesEvents, WebTypesSlots, WebTypesTagItem } from '../../types/webTypes'
+import type { WebTypesVueComponentItem, WebTypesPropItem, WebTypesSlots, WebTypesEventItem, WebTypesProperty } from '../../types/webTypes'
 import { forEach } from '@dxtmisha/functional-basic'
 
 /**
@@ -46,73 +46,73 @@ export class DesignWikiStormItem {
    *
    * Возвращает определение тега для web-types.
    */
-  async get(): Promise<WebTypesTagItem | undefined> {
+  async get(): Promise<WebTypesVueComponentItem | undefined> {
     if (this.wiki) {
       const name = `${toCamelCaseFirst(PropertiesConfig.getDesignName())}${this.wiki.getName()}`
 
-      const tag: WebTypesTagItem = {
+      const component: WebTypesVueComponentItem = {
         name,
         description: this.wiki.getDescription(),
         source: {
           module: `${this.project}/${name}`,
           symbol: name
         },
-        attributes: this.getAttributes()
+        props: this.getProps()
       }
 
       const slots = await this.getSlots()
 
       if (slots) {
-        tag.slots = slots
+        component.slots = slots
       }
 
       const events = await this.getEvents()
 
-      if (events) {
-        tag.events = events
+      if (events && events.length > 0) {
+        component.js = {
+          events
+        }
       }
 
-      return tag
+      return component
     }
 
     return undefined
   }
 
   /**
-   * Returns the attribute definition.
+   * Returns the prop definition.
    *
-   * Возвращает определение атрибута.
+   * Возвращает определение свойства.
    * @param item prop item / элемент свойства
    */
-  getAttribute(item: WikiStorybookProp): WebTypesAttributeItem {
+  getProp(item: WikiStorybookProp): WebTypesPropItem {
     const type = this.prepareType(item.getType())
+    const cleaned = type ? this.cleanType(type) : undefined
     return {
       name: item.getName(),
       description: item.getDescription(),
-      // default: item.getDefaultValue(),
-      value: {
-        kind: 'expression',
-        type
-      }
+      default: item.getDefaultValue() ?? undefined,
+      type: cleaned
     }
   }
 
   /**
-   * Returns a list of attributes.
+   * Returns a list of props.
    *
-   * Возвращает список атрибутов.
+   * Возвращает список свойств.
    */
-  getAttributes(): WebTypesAttributes {
-    const attributes: WebTypesAttributes = []
+  getProps(): WebTypesPropItem[] {
+    const props: WebTypesPropItem[] = []
 
     if (this.wiki) {
       this.wiki.getWikiObject()
         .forEach(
-          props => attributes.push(this.getAttribute(props))
+          item => props.push(this.getProp(item))
         )
     }
 
-    return attributes
+    return props
   }
 
   /**
@@ -127,11 +127,19 @@ export class DesignWikiStormItem {
       const slots: WebTypesSlots = []
 
       data.slots.forEach(
-        props => slots.push({
-          'name': props.name,
-          'description': props.description,
-          'vue-properties': props.properties ?? []
-        })
+        slot => {
+          const vueProperties: WebTypesProperty[] = (slot.properties ?? []).map(p => ({
+            name: p.name,
+            type: p.type ? this.cleanType(p.type) : undefined,
+            description: p.description
+          }))
+
+          slots.push({
+            'name': slot.name,
+            'description': slot.description,
+            'vue-properties': vueProperties
+          })
+        }
       )
 
       return slots
@@ -145,18 +153,28 @@ export class DesignWikiStormItem {
    *
    * Возвращает список событий.
    */
-  async getEvents(): Promise<WebTypesEvents | undefined> {
+  async getEvents(): Promise<WebTypesEventItem[] | undefined> {
     const data = await this.getData()
 
     if (data && data.events) {
-      const events: WebTypesEvents = []
+      const events: WebTypesEventItem[] = []
 
       data.events.forEach(
-        event => events.push({
-          name: event.name,
-          description: event.description,
-          arguments: event.properties ?? []
-        })
+        event => {
+          let typeString = '() => void'
+          if (event.properties && event.properties.length > 0) {
+            const args = event.properties
+              .map(p => `${p.name}: ${p.type ? this.cleanType(p.type) : 'any'}`)
+              .join(', ')
+            typeString = `(${args}) => void`
+          }
+
+          events.push({
+            name: event.name,
+            description: event.description,
+            type: typeString
+          })
+        }
       )
 
       return events
@@ -262,6 +280,18 @@ export class DesignWikiStormItem {
     return type
   }
 
+  /**
+   * Cleans a type string by removing redundant parentheses, e.g., (CellClassesSub) | undefined -> CellClassesSub | undefined
+   *
+   * Очищает строку типа, удаляя лишние скобки, например: (CellClassesSub) | undefined -> CellClassesSub | undefined
+   */
+  protected cleanType(type: string): string {
+    return type
+      .replace(/^\(([^()]+)\)$/, '$1')
+      .replace(/^\(([^()]+)\)\s*\|\s*undefined$/, '$1 | undefined')
+      .trim()
+  }
+
   /**
    * Initializes the wiki object.
    *

package/src/classes/Library/LibraryAiPrompt.ts

@@ -7,8 +7,8 @@ import {
 import { PropertiesFile } from '../Properties/PropertiesFile'
 import { LibraryAiPromptItem } from './LibraryAiPromptItem'
 
-import vuePromptText from '../../media/templates/prompts/aiCodeVuePrompt.en.txt?raw'
-import globalPromptText from '../../media/templates/prompts/aiCodeGlobalPrompt.en.txt?raw'
+import vuePromptText from '../../media/templates/prompts/aiCodeVuePrompt.en.md?raw'
+import globalPromptText from '../../media/templates/prompts/aiCodeGlobalPrompt.en.md?raw'
 
 const LIBRARY_AI_PROMPT_LIST_DIRS = [
   UI_MODULES

package/src/classes/Library/LibraryAiPromptItem.ts

@@ -227,7 +227,7 @@ ${this.readFile(UI_FILE_AI_PROMPT_DESCRIPTION)}
 
       return `
 ## Mandatory Study Before Development
-Before developing, modifying, or implementing any code for /${this.getPathString()}, you MUST first study the architectural rules and instructions located in the following file:
+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 the architectural rules and instructions in this file as your absolute first action:
 '${this.getPathString()}/${UI_FILE_AI_PROMPT_DEVELOPER}'
       `.trim()
     }
@@ -269,7 +269,7 @@ ${this.readFile(UI_FILE_AI_PROMPT_INFO)}
 
       return `
 ## Project types: Essential for analysis
-This file contains the complete type definitions for the project. It is mandatory to study this file to perform an accurate analysis of the project structure and logic:
+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.getPathString()}/${UI_FILE_AI_PROMPT_TYPES}'
       `.trim()
     }

package/src/config.ts

@@ -81,17 +81,17 @@ export const UI_FILE_PACKAGE = 'package.json'
 export const UI_FILE_PROPERTY = 'properties.json'
 
 /** AI prompt description file name / Название файла с описанием промпта AI */
-export const UI_FILE_AI_PROMPT_DESCRIPTION = 'ai-description.txt'
+export const UI_FILE_AI_PROMPT_DESCRIPTION = 'ai-description.md'
 /** AI prompt info file name / Название файла с информацией промпта AI */
-export const UI_FILE_AI_PROMPT_INFO = 'ai-doc.txt'
+export const UI_FILE_AI_PROMPT_INFO = 'ai-doc.md'
 /** AI prompt instruction file name / Название файла с инструкцией промпта AI */
-export const UI_FILE_AI_PROMPT_INSTRUCTION = 'ai-instruction.txt'
+export const UI_FILE_AI_PROMPT_INSTRUCTION = 'ai-instruction.md'
 /** AI prompt result file name / Название файла с результатом промпта AI */
-export const UI_FILE_AI_PROMPT_PROMPT = 'ai-prompt.txt'
+export const UI_FILE_AI_PROMPT_PROMPT = 'ai-prompt.md'
 /** AI prompt types file name / Название файла с типами промпта AI */
-export const UI_FILE_AI_PROMPT_TYPES = 'ai-types.txt'
+export const UI_FILE_AI_PROMPT_TYPES = 'ai-types.md'
 /** AI prompt developer file name / Название файла для разработчика AI */
-export const UI_FILE_AI_PROMPT_DEVELOPER = 'ai-developer.txt'
+export const UI_FILE_AI_PROMPT_DEVELOPER = 'ai-developer.md'
 
 /** File name for storing the list of flags/ Название файла для хранения списка флагов */
 export const UI_FILE_NAME_FLAGS = 'flags'
@@ -117,9 +117,9 @@ export const UI_FILE_NAME_VITE_WORKERS = 'vite-workers.config.ts'
 export const UI_FILE_INDEX = 'index.ts'
 
 /** AI types file name / Название файла с типами AI */
-export const UI_FILE_AI_TYPES = 'ai-types.txt'
+export const UI_FILE_AI_TYPES = 'ai-types.md'
 /** AI description file name / Название файла с описанием AI */
-export const UI_FILE_AI_DESCRIPTION = 'ai-description.txt'
+export const UI_FILE_AI_DESCRIPTION = 'ai-description.md'
 /** Style SCSS file name / Название файла стилей SCSS */
 export const UI_FILE_STYLE_SCSS = 'style.scss'
 /** UI properties SCSS file name / Название файла свойств UI в SCSS */

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/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/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/media/templates/prompts/aiCodeGlobalPrompt.en.txt

@@ -1,59 +0,0 @@
-### 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. Identify all package paths involved in the user request (e.g. `/packages/constructor/...` maps to `@dxtmisha/constructor`).
-     2. Scan the prompt for sections corresponding to those packages.
-     3. Identify all paths to auxiliary documentation/types mentioned in those sections (e.g., `ai-types.txt`, `ai-developer.txt`).
-     4. You MUST use the `view_file` tool to read and study ALL of these referenced files BEFORE calling `list_dir` on component 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.
-   - 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.
-   - 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 `??`).
-   - 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**:
-   - Perform all operations strictly in accordance with the provided commands and instructions.
-   - Avoid guessing, improvisation, or performing any unrequested or extra actions.
-   - Strictly adhere to the plan, checklists, and execution steps.

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

@@ -1,61 +0,0 @@
-### Глобальные принципы разработки (AI Code Promise)
-
-Твоя главная цель — генерировать безупречный, промышленный код, который соответствует стандартам dxt-ui. Ты обещаешь следовать этим правилам неукоснительно:
-
-0. **Обязательное глубокое изучение**:
-   - Прежде чем разрабатывать что-либо для любого проекта или пакета, ты ОБЯЗАН полностью изучить его, чтобы детально понять его архитектуру и стилистику.
-   - Прежде чем изменять или исправлять любой файл, ты ОБЯЗАН полностью изучить его внутреннюю структуру и логику.
-   - Если в инструкциях, путях или файлах указано расположение внутри `node_modules/` или любой другой внешней/привязанной директории, ты ОБЯЗАН сначала проверить, существует ли этот пакет локально в рабочей области (например, в каталоге `packages/`). Если пакет существует локально, ты ОБЯЗАН переопределить пути на локальный каталог пакета рабочей области и изучать/изменять локальные исходные файлы вместо указанных.
-    - **КРИТИЧЕСКИЙ ПЕРВЫЙ ШАГ:** Если какой-либо проект, модуль или инструкция содержит ссылки или пути к конкретным файлам (например, типы, руководства для разработчиков, описания), ты ОБЯЗАН подробно изучить все эти файлы по ссылкам в первую очередь. Как только ты начинаешь работу с проектом или видишь, что он импортируется/используется в коде, над которым ты работаешь, ты должен незамедлительно прочитать и изучить все эти файлы по ссылкам, прежде чем приступать к планированию, предложению изменений или написанию кода. Это требование обязательно и распространяется в том числе на файлы, находящиеся в `node_modules/` (всегда сначала переопределяй пути на локальный каталог рабочей области, если они существуют локально).
-   - **БЛОКИРУЮЩИЙ КОНТРОЛЬ ПОСЛЕДОВАТЕЛЬНОСТИ (ПРАВИЛО ХРОНОЛОГИИ):**
-     1. Определи все пути пакетов, связанных с запросом (например, `/packages/constructor/...` относится к `@dxtmisha/constructor`).
-     2. Найди в промпте секции, соответствующие этим пакетам.
-     3. Выпиши все пути к вспомогательным файлам типов и руководств, упомянутые в этих секциях (например, `ai-types.txt`, `ai-developer.txt`).
-     4. Ты ОБЯЗАН использовать инструмент `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-типы.
-   - Всегда определяй интерфейсы для входных и выходных данных.
-   - Используй `as const`, `readonly` и перечисления (enums/union types) для повышения надежности.
-
-5. **Профессиональное документирование (TSDoc)**:
-   - Сопровождай все экспортируемые сущности комментариями TSDoc на [wikiLanguage] языке.
-   - Описывай назначение, параметры, возвращаемые значения и возможные исключения.
-   - Примеры использования в комментариях приветствуются для сложных функций.
-
-6. **Архитектурная консистентность**:
-   - Соблюдай структуру проекта. Если в проекте принято выносить логику в `composables` или `utils` — следуй этому паттерну.
-   - Не изменяй глобальные стили или стили базовых UI-компонентов, если это не было явно запрошено.
-
-7. **Безопасность и Производительность**:
-   - Пиши код, защищенный от ошибок (guard clauses, опциональная цепочка `?.`, nullish coalescing `??`).
-   - Избегай лишних вычислений в циклах и тяжелых операций в реактивных зависимостях.
-
-8. **Эстетика и Лаконичность**:
-   - Код должен быть красивым. Используй логические отступы и группировку кода по смыслу.
-   - Экономь токены, избегая избыточных комментариев там, где код говорит сам за себя.
-
-9. **Строгое следование инструкциям**:
-   - Выполняй все действия строго в соответствии с предоставленными командами и инструкциями.
-   - Никакой самодеятельности, додумывания или выполнения лишних/незапрошенных действий.
-   - Строго придерживайся планов, чек-листов и шагов выполнения.