### 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.
