beginwebdev2002 · beginwebdev2002 · Mar 29, 2026
diff --git a/.agents/rules/github-seo.md b/.agents/rules/github-seo.md
@@ -1,14 +1,22 @@
 ---
 trigger: model_decision
 description: This document serves as the primary "Memory" and governance file for the `best-practise` repository.
----
+technology: TypeScript
+domain: Documentation
+level: Senior/Architect
+version: Latest
+tags: [typescript, documentation, best-practices, architecture]
+ai_role: Senior TypeScript Expert
+last_updated: 2026-03-29
+topic: TypeScript
+complexity: Architect
+last_evolution: 2026-03-29
+vibe_coding_ready: true---
 
 # GitHub SEO & AI-Context Master Strategy: `best-practise`
 
  It defines the standards for generating high-performance instructions optimized for both GitHub’s search algorithms and "Vibe Coding" AI tools (Cursor, Windsurf, Copilot).
-
 ---
-
 ## 1. Indexing Strategy & Keyword Optimization
 
 To ensure the repository ranks at the top of GitHub search results and search engines, every document must adhere to specific semantic rules.
@@ -24,9 +32,7 @@ To ensure the repository ranks at the top of GitHub search results and search en
 - **LSI Keywords:** Naturally integrate terms like *production-ready*, *enterprise-grade*, *scalable architecture*, *clean code*, and *software design patterns*.
 - **Initial Context:** The first 200 characters of every file must contain the primary technology and the keyword "best practices".
 - **Density:** Maintain a 1-3% keyword density for the main topic to avoid "keyword stuffing" while remaining relevant to GitHub's search indexer.
-
 ---
-
 ## 2. Structure for AI-Context (Vibe Coding Optimization)
 
 Documentation must be structured to allow LLMs to ingest "system prompts" and "project rules" with zero ambiguity.
@@ -41,9 +47,7 @@ Every file must start with a `# Context & Scope` section that defines:
 - **Checklists:** Use `- [ ]` for actionable verification steps. LLMs respond better to checklist-style instructions.
 - **Strict Constraints:** Use a `> [!IMPORTANT]` or `> [!CAUTION]` block to list "Never" and "Always" rules.
 - **Code Annotations:** Use comments within code blocks to explain *why* a pattern is used, not just *what* it does.
-
 ---
-
 ## 3. Technical Text Standard
 
 ### Tone and Style
@@ -70,19 +74,15 @@ Every file must start with a `# Context & Scope` section that defines:
 ### Code Standards
 - **Naming Conventions:** Enforce `PascalCase` for classes/components, `camelCase` for functions/variables, and `kebab-case` for file names.
 - **Folder Structure:** Define a clear directory hierarchy (e.g., `src/features/*`, `src/shared/ui/*`).
-
 ---
-
 ## 4. Internal Linking Rules
 
 To build a "Knowledge Graph" within the repository, files must be cross-referenced using relative Markdown links.
 
 - **Dependency Linking:** If a TypeScript guide is used, it must link to the `Architecture` guide (e.g., `[View Architecture Standards](../../architectures/fsd.md)`).
 - **Pattern Inheritance:** Link specialized patterns (e.g., Factory) to general programming principles (e.g., SOLID).
 - **Navigation:** Every sub-folder should have a `readme.md` that maps out the local files and their relationship to the repository root.
-
 ---
-
 ## 5. Repository Metadata
 
 ### About Section (GitHub Sidebar)

diff --git a/.agents/rules/project-architecture.md b/.agents/rules/project-architecture.md
@@ -1,12 +1,21 @@
 ---
 trigger: glob
 description: Architectural guidelines and taxonomy for navigating the Vibe Coding meta-instruction base repository.
----
+technology: Angular
+domain: Documentation
+level: Senior/Architect
+version: Latest
+tags: [angular, documentation, best-practices, architecture]
+ai_role: Senior Angular Expert
+last_updated: 2026-03-29
+topic: Angular
+complexity: Architect
+last_evolution: 2026-03-29
+vibe_coding_ready: true---
 
 # Project Architecture: Context Deep-Dive
 
 This document outlines the architectural pattern of the meta-instruction base repository (Vibe Coding). The architecture is built on the "Context Deep-Dive" principle (from general to specific), ensuring predictable navigation for both developers and AI agents.
-
 ## 1. Directory Hierarchy (The Taxonomy)
 
 The project uses a strict three-level structure: `[Root] -> [Type of Technology] -> [Technology]`.
@@ -16,7 +25,6 @@ The project uses a strict three-level structure: `[Root] -> [Type of Technology]
 | **`[Root]`** | Repository root. Contains the global configuration and architectural rules (this file). | `/` |
 | **`[Type of Technology]`** | Domain categorization. Groups technologies based on their role in the system. | `frontend/`, `backend/`, `security/`, `devops/` |
 | **`[Technology]`** | A specific tool, framework, or methodology. Acts as a container for instruction sets. | `frontend/angular/`, `backend/mongodb/`, `architecture/fsd/` |
-
 ## 2. Role of `readme.md` (Entry Points)
 
 The `readme.md` files act as Entry Points for AI agents at various hierarchy levels:
@@ -26,7 +34,6 @@ The `readme.md` files act as Entry Points for AI agents at various hierarchy lev
   *(Example: `security/readme.md` describes fundamental security principles applicable to all tools within).*
 * **`[Technology]` Level (Tool):**
   The `readme.md` here is the primary entry point for a specific technology. It contains basic, global rules applied by default when working with this technology.
-
 ## 3. Specific Modules (Specific `.md` files)
 
 To prevent the main technology `readme.md` from becoming overloaded, detailed instructions are extracted into isolated specific modules.
@@ -35,7 +42,6 @@ To prevent the main technology `readme.md` from becoming overloaded, detailed in
 1. The file is created within the `[Technology]` folder.
 2. The filename must reflect a narrow context (e.g., `performance.md`, `testing.md`, `naming-convention.md`).
 3. The module must be entirely focused on its stated topic. The AI agent will only include this file when the task overlaps with this specific context.
-
 ## 4. AI Agent Path (Visualization)
 
 Below is a diagram of the AI agent's navigation when searching for context for a task:
@@ -78,7 +84,6 @@ graph TD
     class B component;
 
 ```
-
 ## 5. Rules for Adding New Technologies
 
 When adding a new technology, contributors must follow this algorithm:

diff --git a/.agents/rules/rules.md b/.agents/rules/rules.md
@@ -1,18 +1,26 @@
 ---
 trigger: glob
 globs: (frontend|backend|architectures)/**/*.md
----
+technology: TypeScript
+domain: Documentation
+level: Senior/Architect
+version: Latest
+tags: [typescript, documentation, best-practices, architecture]
+ai_role: Senior TypeScript Expert
+last_updated: 2026-03-29
+description: Vibe coding guidelines and architectural constraints for TypeScript within the Documentation domain.
+topic: TypeScript
+complexity: Architect
+last_evolution: 2026-03-29
+vibe_coding_ready: true---
 
 ---
-
 ## 🌟 Our Pledge
 
 In the interest of fostering an open, welcoming, and safe environment, we as contributors and maintainers of the **best-practise** project pledge to make participation in our project and our community a harassment-free experience for everyone, regardless of age, body size, visible or invisible disability, ethnicity, sex characteristics, gender identity and expression, level of experience, education, socio-economic status, nationality, personal appearance, race, caste, color, religion, or sexual orientation.
 
 We pledge to act and interact in ways that contribute to an open, welcoming, diverse, inclusive, and healthy community.
-
 ---
-
 ## ⚖️ Our Standards
 
 In our repository dedicated to *Vibe Coding* and architectural AI instructions, we value constructive dialogue and professionalism.
@@ -24,9 +32,7 @@ In our repository dedicated to *Vibe Coding* and architectural AI instructions,
 | 💡 Gracefully accepting constructive criticism on code or rules. | 🛑 Public or private harassment of project members. |
 | 🌍 Focusing on what is best for the community and accommodating for programming beginners. | 📢 Publishing others' private information without explicit permission. |
 | 🧠 Sharing knowledge and experience in development and AI architecture. | 🚫 Other conduct which could reasonably be considered inappropriate in a professional setting. |
-
 ---
-
 ##  Interaction Lifecycle
 
 Interaction within the **best-practise** project is built on mutual respect and continuous improvement of AI instructions. This visual graph demonstrates the stages of healthy communication in the project:
@@ -59,32 +65,28 @@ graph TD
     class B component;
 
 ```
-
 ---
-
 ## 📝 How to Write Instructions (Best Practices)
 
 In our repository, we adhere to a unified standard for writing instructions. You can study the `frontend/typescript/readme.md` file as a reference example.
 
 Each instruction must begin with the following metadata block (YAML frontmatter):
 
-```yaml
----
+```yaml---
 technology: [Inferred Tech]
 domain: [Inferred Domain]
 level: Senior/Architect
 version: [Inferred Version]
 tags: [tag1, tag2, tag3]
 ai_role: [Specific Persona]
-last_updated: YYYY-MM-DD
----
+last_updated: YYYY-MM-DD---
 ```
 
 Next, to describe each rule or pattern, you should use the following structure. **This structure is repeated as many times as necessary** to fully cover the topic. Here is one of the clearest and most popular examples:
 
 ### ❌ Bad Practice
 ```typescript
-function process(data: any) {
+function process(data: unknown) {
     console.log(data.name); // No error, but can fail at runtime
 }
 ```
@@ -103,25 +105,19 @@ function process(data: unknown) {
 
 ### 🚀 Solution
 Use `unknown` for values whose type is not yet determined. This obliges the developer to perform a type check before use, ensuring the safety of the data structure.
-
 ---
-
 ## 🛡️ Our Responsibilities
 
 Project maintainers, including the project founder **Jamoliddin Qodirov**, are responsible for clarifying the standards of acceptable behavior and are expected to take appropriate and fair corrective action in response to any instances of unacceptable behavior.
 
 Project maintainers have the right and responsibility to remove, edit, or reject comments, commits, code, wiki edits, issues, and other contributions (including AI instructions) that are not aligned with this Code of Conduct. Maintainers are also expected to explain the reasons for their moderation decisions when removing content or issuing bans.
-
 ---
-
 ## 🌐 Scope
 
 This Code of Conduct applies in the following scenarios:
 1. Within all **best-practise** project spaces (including the GitHub repository, branches, issue discussions, and pull request comments).
 2. In public spaces when an individual is representing the project or its community. Examples include using an official project e-mail address, posting via an official social media account, or acting as an appointed representative at an online or offline event.
-
 ---
-
 ## 🚨 Enforcement
 
 Instances of abusive, harassing, or otherwise unacceptable behavior may be reported to the project maintainers:
@@ -138,15 +134,12 @@ Project maintainers will follow these Community Impact Guidelines in determining
 2. **Warning:** A warning with consequences, such as a temporary suspension from communicating in the project or a ban on interacting with specific individuals for a set period.
 3. **Temporary Ban:** A temporary ban from any interaction with the project, including creating issues and pull requests.
 4. **Permanent Ban:** A complete and permanent ban from any sort of public interaction within the project for systematic, intentional, or severe violations (e.g., harassment or threats).
-
 ---
-
 ## 📜 Attribution
 
 This Code of Conduct is adapted from the [Contributor Covenant](https://www.contributor-covenant.org), version 2.1, available at [https://www.contributor-covenant.org/version/2/1/code_of_conduct.html](https://www.contributor-covenant.org/version/2/1/code_of_conduct.html).
 
 Answers to common questions about this code of conduct can be found in the official [FAQ](https://www.contributor-covenant.org/faq). Translations are available at [https://www.contributor-covenant.org/translations](https://www.contributor-covenant.org/translations).
-
 ---
 
 <a name="russian"></a>
@@ -162,5 +155,4 @@ Answers to common questions about this code of conduct can be found in the offic
 
   **Проектирование детерминированной кодовой базы для ИИ-агентов в условиях архитектурной целостности и взаимоуважения.**
 </div>
-
 ---
diff --git a/.agents/rules/system-documentation.md b/.agents/rules/system-documentation.md
@@ -1,10 +1,18 @@
 ---
 description: Instructions for the Jules AI agent on maintaining and updating core system documentation, AI rules, and repository guidelines.
 tags: [system documentation, AI agent rules, documentation quality, vibe coding, github-seo, repository management, clean documentation]
----
+technology: Vibe Coding
+domain: Documentation
+level: Senior/Architect
+version: Latest
+ai_role: Senior Vibe Coding Expert
+last_updated: 2026-03-29
+topic: Vibe Coding
+complexity: Architect
+last_evolution: 2026-03-29
+vibe_coding_ready: true---
 
 # ⚙️ System Documentation & AI Quality Rules for Jules
-
 ## 1. Context & Scope
 - **Primary Goal:** Ensure the continuous improvement and high **documentation quality** of the core system files that guide developers and AI agents.
 - **Target Tooling:** Jules AI agent (Vibe Coding, Automated Maintenance).
@@ -15,9 +23,7 @@ tags: [system documentation, AI agent rules, documentation quality, vibe coding,
 
   **Maintaining the Machine-Readable Intelligence Layer of the repository.**
 </div>
-
 ---
-
 ## 2. Core System Files and Directories
 
 > [!WARNING]
@@ -42,9 +48,7 @@ The following files are systemic for promoting high **documentation quality** an
 - `.agents/rules/github-seo.md` – Search Engine Optimization and metadata structures.
 - `.agents/rules/project-architecture.md` – Core architectural constraints.
 - `.agents/rules/rules.md` & `.agents/rules/system-markdown.md` – Specific constraints enforcing clean code and high documentation searchability.
-
 ---
-
 ## 3. Maintenance Protocol for Jules
 
 Jules must actively sync these files whenever a new global rule is adopted.
@@ -73,9 +77,7 @@ graph TD
     class UpdateSEO component;
 
 ```
-
 ---
-
 ## 4. Documentation Quality Standards
 
 When writing or updating **system documentation**, Jules must verify the following constraints:

diff --git a/.agents/rules/system-instruction.md b/.agents/rules/system-instruction.md
@@ -2,10 +2,19 @@
 trigger: glob
 description: Rules for making changes to system Markdown files in 2 languages (English/Russian).
 globs: "{README.md,.github/CONTRIBUTING.md,.github/SECURITY.md,.github/CODE_OF_CONDUCT.md}"
----
+technology: Vibe Coding
+domain: Documentation
+level: Senior/Architect
+version: Latest
+tags: [vibe-coding, documentation, best-practices, architecture]
+ai_role: Senior Vibe Coding Expert
+last_updated: 2026-03-29
+topic: Vibe Coding
+complexity: Architect
+last_evolution: 2026-03-29
+vibe_coding_ready: true---
 
 # System Markdown Files Formatting
-
 ## Applicability
 These rules apply STRICTLY and EXCLUSIVELY to the following files:
 - `README.md`
@@ -14,7 +23,6 @@ These rules apply STRICTLY and EXCLUSIVELY to the following files:
 - `.github/CODE_OF_CONDUCT.md`
 
 The glob pattern is configured so that it does not affect any other Markdown files in the project.
-
 ## Core Editing Rules
 
 1. **Bilingual Requirement**:

diff --git a/.gemini/commands/gen/instruction.md b/.gemini/commands/gen/instruction.md
@@ -0,0 +1,13 @@
+---
+description: Vibe coding guidelines and architectural constraints for Vibe Coding within the Documentation domain.
+tags: [vibe-coding, documentation, best-practices, architecture]
+topic: Vibe Coding
+complexity: Architect
+last_evolution: 2026-03-29
+vibe_coding_ready: true
+technology: Vibe Coding
+domain: Documentation
+level: Senior/Architect
+version: Latest
+ai_role: Senior Vibe Coding Expert
+last_updated: 2026-03-29---