description	Vibe coding guidelines and architectural constraints for NestJS within the Documentation domain.
tags	nestjs documentation best-practices architecture
topic	NestJS
complexity	Architect
last_evolution	2026-03-29
vibe_coding_ready	true
technology	NestJS
domain	Documentation
level	Senior/Architect
version	Latest
ai_role	Senior NestJS Expert
last_updated	2026-03-29

🇺🇸 English | 🇷🇺 Русский

🛡️ Security Policy

Welcome to the official security policy for the best-practise project. Our goal is to ensure the maximum security and reliability of meta-instructions (Vibe Coding) for AI agents (Cursor, Windsurf, Copilot, Antigravity, Aider).

Since this repository serves as an "AI Knowledge Base," our security model differs from traditional software development projects.

📅 Supported Versions

We actively support and update only the latest major versions of our architectural and technological rules.

Version / Branch	Security Support	Support Status
main (Current)	✅ Supported
v1.x	❌ Unsupported
Legacy Branches / PRs	❌ Unsupported

---

🚨 Reporting a Vulnerability

Please DO NOT create public issues if you discover a critical vulnerability or potentially dangerous AI instructions in the repository (e.g., instructions that open backdoors via agents).

Secure Reporting Process:

1. Navigate to the Security Advisories tab or contact the maintainers directly.
2. Describe the issue in detail: specify the exact .md file containing the vulnerability.
3. Explain how an AI agent might incorrectly or destructively interpret the instruction.
4. Attach a Proof of Concept (PoC prompt) if possible, demonstrating the exploitation of the "flawed" rule in Cursor or Windsurf.

We are committed to acknowledging your report within 48 hours and providing a remediation plan.

🤖 AI Security Context

This project focuses on Context Injection. Therefore, we classify threats specifically for LLMs and agentic IDEs:

• Prompt Injections: Hidden or "poisonous" instructions in rule files that force the agent to write malicious code or ignore other project security policies.
• Insecure Architectural Patterns: Instructions recommending the use of vulnerable dependencies, disabling CORS in production-ready examples, or exposing APIs without proper authentication.
• Data Leaks: Code examples or AI configuration rules that encourage agents (or developers) to leave API keys and tokens in the codebase.

Severity Levels

Severity	Incident Description within Vibe Coding	Priority
🔴 Critical	Malicious injections guaranteed to lead to code compromise or RCE executed by the agent.	P0
🟠 High	Recommendations grossly violating basic security principles (e.g., eval, unvalidated innerHTML in Frontend rules).	P1
🟡 Medium	Instructions leading to the creation of logical bugs (Bad Smells, Race conditions) in the agent-generated code.	P2
🟢 Low	Typos in linters, broken or outdated minor style rules.	P3

---

🔄 Incident Response Lifecycle

Below is a visual flowchart of our standard process for handling discovered threats in meta-instructions:

graph TD
    A(["User finds dangerous rule"]) --> B{"Is it critical?"}
    B -->|"Yes (P0, P1)"| C["Submit private Security Advisory"]
    B -->|"No (P2, P3)"| D["Open standard Issue / Pull Request"]
    
    C --> E["Threat analysis by maintainers"]
    E --> F["Vulnerability isolation, disable rule"]
    F --> G["Patch MD file and update instructions"]
    G --> H["Publish Security Release & Notify"]
    H --> I(["Vulnerability resolved"])
    
    D --> G
    
    classDef critical fill:#ffebeb,stroke:#ff0000,stroke-width:2px;
    classDef safe fill:#ebffeb,stroke:#00aa00,stroke-width:2px;
    class C critical;
    class D safe;
    %% Added Design Token Styles for Mermaid Diagrams
    classDef default fill:#e1f5fe,stroke:#03a9f4,stroke-width:2px,color:#000;
    classDef component fill:#e8f5e9,stroke:#4caf50,stroke-width:2px,color:#000;
    classDef layout fill:#f3e5f5,stroke:#9c27b0,stroke-width:2px,color:#000;

    class E component;
    class F component;
    class G component;
    class H component;
    class I component;
    class B component;

Loading

---

🛡️ Best Practices for Contributors

If you propose new instructions or architectural standards (via PR), strictly adhere to the security rules:

• No Binary Files: Never add executable scripts if their code cannot be verified directly.
• Security Annotations: Any code examples for authentication or configuration must be accompanied by // SECURE: comments or explanations of why this approach is standard and secure.
• Path Restrictions: Absolute paths and hardcoded test secrets are strictly forbidden in rules (e.g., inside backend/nestjs/security.md). Always use placeholders like <YOUR_SECRET_KEY>.

Thank you for contributing to the security and quality of AI-driven development (Vibe Coding)! 🚀

---

🛡️ Security Policy

Добро пожаловать в официальную политику безопасности репозитория best-practise. Наша задача — гарантировать максимальную безопасность и стабильность мета-инструкций (Vibe Coding) для ИИ-агентов (Cursor, Windsurf, Copilot, Antigravity, Aider).

Поскольку данный репозиторий выступает «Базой знаний ИИ» (AI Knowledge Base), наша модель безопасности имеет существенные отличия от классических проектов разработки программного обеспечения.

📅 Supported Versions

Мы осуществляем поддержку и апдейт исключительно последних мажорных версий архитектурных и технологических стандартов.

Version / Branch	Security Support	Support Status
main (Current)	✅ Поддерживается
v1.x	❌ Не поддерживается
Legacy Branches / PRs	❌ Не поддерживается

---

🚨 Reporting a Vulnerability

ЗАПРЕЩАЕТСЯ создавать публичные Issue при обнаружении критической уязвимости или деструктивных инструкций для ИИ (например, инструкций, провоцирующих внедрение бэкдоров силами агентов).

Протокол безопасного репортинга:

1. Перейдите в раздел Security Advisories или свяжитесь с мейнтейнерами напрямую.
2. Подробно задокументируйте проблему: укажите конкретный .md файл, содержащий уязвимый паттерн.
3. Опишите вектор потенциальной некорректной или деструктивной интерпретации инструкции ИИ-агентом.
4. Предоставьте Proof of Concept (PoC prompt), демонстрирующий эксплуатацию дефектного правила в Cursor или Windsurf.

Мы обязуемся подтвердить получение репорта в течение 48 часов с предоставлением плана митигации.

🤖 AI Security Context

Ядром проекта является AI Context Injection. В связи с этим классификация угроз адаптирована под специфику LLM и агентных IDE:

• Prompt Injections: Скрытые или «отравленные» инструкции в файлах правил, инициирующие генерацию вредоносного кода или обход других политик безопасности проекта.
• Insecure Architectural Patterns: Инструкции, легитимизирующие использование уязвимых зависимостей, отключение CORS в production-ready примерах или публикацию API без надлежащей аутентификации.
• Data Leaks: Примеры кода или конфигурации ИИ, провоцирующие агентов (или разработчиков) на публикацию API-ключей и токенов в кодовую базу.

Severity Levels

Severity	Incident Description within Vibe Coding	Priority
🔴 Critical	Вредоносные инъекции, гарантированно приводящие к компрометации кода или исполнению RCE силами агента.	P0
🟠 High	Рекомендации, критически нарушающие фундаментальные принципы безопасности (использование eval, отсутствие санации innerHTML в правилах Frontend).	P1
🟡 Medium	Инструкции, провоцирующие возникновение логических дефектов (Bad Smells, Race conditions) в коде, сгенерированном агентом.	P2
🟢 Low	Ошибки конфигурации линтеров, нерабочие или устаревшие минорные правила стилизации.	P3

---

🔄 Incident Response Lifecycle

Формализованный процесс обработки обнаруженных угроз в мета-инструкциях представлен на схеме:

graph TD
    A(["Пользователь обнаружил опасное правило"]) --> B{"Оно критично?"}
    B -->|"Да (P0, P1)"| C["Отправить частное Security Advisory"]
    B -->|"Нет (P2, P3)"| D["Открыть стандартный Issue / Pull Request"]
    
    C --> E["Анализ угроз мейнтейнерами"]
    E --> F["Изоляция уязвимости, отключение правила"]
    F --> G["Исправление MD файла и обновление инструкций"]
    G --> H["Публикация Security Release & Уведомление"]
    H --> I(["Уязвимость устранена"])
    
    D --> G
    
    classDef critical fill:#ffebeb,stroke:#ff0000,stroke-width:2px;
    classDef safe fill:#ebffeb,stroke:#00aa00,stroke-width:2px;
    class C critical;
    class D safe;
    %% Added Design Token Styles for Mermaid Diagrams
    classDef default fill:#e1f5fe,stroke:#03a9f4,stroke-width:2px,color:#000;
    classDef component fill:#e8f5e9,stroke:#4caf50,stroke-width:2px,color:#000;
    classDef layout fill:#f3e5f5,stroke:#9c27b0,stroke-width:2px,color:#000;

    class E component;
    class F component;
    class G component;
    class H component;
    class I component;
    class B component;

Loading

---

🛡️ Best Practices for Contributors

При контрибьюции новых инструкций или архитектурных стандартов (через Pull Request) требуется неукоснительное следование правилам безопасности:

• No Binary Files: Запрет на коммит бинарных и исполняемых скриптов, не поддающихся прямому аудиту исходного кода.
• Security Annotations: Архитектурные паттерны аутентификации и конфигурации надлежит размечать комментариями // SECURE: с инженерным обоснованием надежности используемого подхода.
• Path Restrictions: Абсолютные пути и захардкоженные тестовые секреты строго запрещены в правилах (например, внутри backend/nestjs/security.md). Обязательно использование плейсхолдеров, таких как <YOUR_SECRET_KEY>.

Благодарим за вклад в архитектурную целостность и безопасность AI-инжиниринга (Vibe Coding)! 🚀