Instructions Update

.github/commit-instructions.md

@@ -1,36 +1,86 @@
-# Commit Message Instructions
+# Commit Message Instructions (Conventional Commits)
+
+Commit messages should follow the [Conventional Commits specification](https://www.conventionalcommits.org/en/v1.0.0/). This provides a standardized format for commit messages, making it easier to understand changes, automate changelog generation, and trigger build/publish processes.
 
 ## Format
 
-Each commit message should follow this structure:
-
-1. **Short Summary**: A brief summary of the changes (max 72 characters).
-2. **List of Changes**: A detailed list of changes with icons to indicate the type of change.
-
----
-
-### Example
+The commit message structure is as follows:
 
 ```
-Added a new module to handle user authentication, including login and registration.
+<type>[optional scope]: <description>
 
-- ✨ **Feature**: Implemented user login functionality
-- 🐛 **Fix**: Resolved session timeout issue
-- 🛠️ **Refactor**: Improved error handling in auth service
-- 🧪 **Test**: Added unit tests for login component
+[optional body]
+
+[optional footer(s)]
 ```
 
 ---
 
-## Icons for Change Types
+### Components
 
-- ✨ **Feature**: New features or functionality
-- 🐛 **Fix**: Bug fixes
-- 🛠️ **Refactor**: Code improvements without changing functionality
-- 🧪 **Test**: Adding or updating tests
-- 📚 **Docs**: Documentation updates
-- 🗑️ **Chore**: Maintenance tasks (e.g., dependency updates)
-- 🚀 **Performance**: Performance improvements
-- 🎨 **Style**: Code style changes (e.g., formatting)
-- 🔒 **Security**: Security-related changes
-- ⚙️ **Config**: Configuration changes
+1.  **Type**: Indicates the kind of change introduced by the commit. Must be one of the allowed types (see below).
+2.  **Scope (Optional)**: A noun describing the section of the codebase affected by the change (e.g., `auth`, `ui`, `build`). Enclosed in parentheses.
+3.  **Description**: A concise summary of the change in the imperative, present tense (e.g., "add login feature", not "added login feature" or "adds login feature"). Starts with a lowercase letter and should not end with a period. Max 72 characters recommended for the entire header line (`<type>[optional scope]: <description>`).
+4.  **Body (Optional)**: A more detailed explanation of the changes. Use the imperative, present tense. Explain the _what_ and _why_ vs. _how_. Separate from the description by a blank line. Wrap lines at 72 characters.
+5.  **Footer(s) (Optional)**: Contains additional metadata. Common footers include:
+    - `BREAKING CHANGE:` followed by a description of the breaking change. A `!` can also be appended to the type/scope (`feat!:`) to indicate a breaking change.
+    - Issue references (e.g., `Refs: #123`, `Closes: #456`). Separate from the body by a blank line.
+
+---
+
+### Allowed Types
+
+- **feat**: A new feature for the user.
+- **fix**: A bug fix for the user.
+- **build**: Changes that affect the build system or external dependencies (e.g., gulp, broccoli, npm).
+- **chore**: Other changes that don't modify src or test files (e.g., updating dependencies, build tasks).
+- **ci**: Changes to CI configuration files and scripts (e.g., Travis, Circle, BrowserStack, SauceLabs).
+- **docs**: Documentation only changes.
+- **perf**: A code change that improves performance.
+- **refactor**: A code change that neither fixes a bug nor adds a feature.
+- **style**: Changes that do not affect the meaning of the code (white-space, formatting, missing semi-colons, etc).
+- **test**: Adding missing tests or correcting existing tests.
+
+---
+
+### Examples
+
+**Commit with description only:**
+
+```
+fix: correct minor typos in code
+```
+
+**Commit with scope:**
+
+```
+feat(lang): add polish language
+```
+
+**Commit with body and breaking change footer:**
+
+```
+refactor: drop support for Node 6
+
+The new implementation relies on async/await and other features
+introduced in Node 8+.
+
+BREAKING CHANGE: refactor to use JavaScript features not available in Node 6.
+```
+
+**Commit with scope, body, and issue footer:**
+
+```
+docs(readme): improve installation instructions
+
+Provide clearer steps for setting up the development environment.
+Add links to prerequisite tools.
+
+Closes: #12
+```
+
+**Commit with `!` for breaking change:**
+
+```
+feat(api)!: send an email to the customer when a product is shipped
+```

.github/copilot-instructions.md

@@ -1,17 +1,21 @@
-# Spark Instructions
+# Mentor Instructions
 
 ## Introduction
 
-You are Spark, a mentor designed to help me with coding, preview my work, and assist me in improving by pointing out areas for enhancement.
+You are Mentor, an AI assistant focused on ensuring code quality, strict adherence to best practices, and development efficiency. **Your core function is to enforce the coding standards and guidelines established in this workspace.** Your goal is to help me produce professional, maintainable, and high-performing code.
 
 ## Tone and Personality
 
-You are a mentor with a dual approach: when I make a mistake or my work needs improvement, you adopt a strict and technical tone to clearly explain what’s wrong and how to fix it. In all other cases, you are casual and friendly, like a supportive coding buddy, keeping the vibe light and encouraging.
+Maintain a professional, objective, and direct tone consistently:
+
+- **Guideline Enforcement & Error Correction:** When code deviates from guidelines or contains errors, provide precise, technical feedback. Clearly state the issue, cite the relevant guideline or principle, and explain the required correction for optimal, maintainable results.
+- **Technical Consultation:** In discussions about architecture, best practices, or complex coding inquiries, remain formal and analytical. Provide clear, well-reasoned explanations and recommendations grounded in industry standards and the project's specific guidelines.
 
 ## Behavioral Guidelines
 
-- Focus on constructive feedback; avoid simply rewriting my code unless I ask for it.
-- If my question or code is unclear, ask me for clarification or more details.
-- Do not discourage me; always frame suggestions as opportunities for growth.
-- Avoid giving generic answers—tailor your advice to my specific code or problem.
-- Keep my preferences in mind: prioritize Type safety, follow Clean Code principles and emphasize good documentation.
+- **Actionable Feedback:** Prioritize constructive, actionable feedback aimed at improving code quality, maintainability, and adherence to standards. Avoid rewriting code; focus on explaining the necessary changes and their rationale based on guidelines.
+- **Strict Guideline Adherence:** Base _all_ feedback, suggestions, and explanations rigorously on the guidelines documented within this workspace. Cite specific rules and principles consistently.
+- **Demand Clarity:** If a query or code snippet lacks sufficient detail for a thorough, professional analysis, request clarification.
+- **Professional Framing:** Frame all feedback objectively, focusing on the technical aspects and the importance of meeting project standards for long-term success.
+- **Context-Specific Expertise:** Provide specific, context-aware advice tailored to the code or problem, always within the framework of our established guidelines.
+- **Enforce Standards:** Actively enforce project preferences for Type safety, Clean Code principles, and thorough documentation, as mandated by the workspace guidelines.

.github/review-instructions.md

@@ -36,8 +36,9 @@ When conducting a code review, follow these steps to ensure a thorough and const
 
 ## Additional Informations
 
-- Treat missing tests and JSDocs as warnings
-- Tread missing unit test as warnings
+- Missing tests and JSDocs are minor issues
+- Missing unit test are minor issues
+- Missing End-to-End (E2E) Testing Attributes (`data-what`, `data-which`) are warnings
 
 ### Review Template
 

.github/testing-instructions.md

@@ -1,10 +1,12 @@
 # Testing Instructions
 
 ## Framework and Tools
+
 - Use **Jest** as the testing framework.
 - For unit tests, utilize **Spectator** to simplify Angular component testing.
 
 ## Guidelines
+
 1. **Error Case Testing**: Ensure all edge cases and error scenarios are thoroughly tested.
 2. **Arrange-Act-Assert Pattern**: Follow the Arrange-Act-Assert pattern for structuring your tests:
    - **Arrange**: Set up the testing environment and initialize required variables.
@@ -12,12 +14,14 @@
    - **Assert**: Verify the expected outcomes.
 
 ## Best Practices
+
 - Write clear and descriptive test names.
 - Ensure tests are isolated and do not depend on each other.
 - Mock external dependencies to avoid side effects.
 - Aim for high code coverage without compromising test quality.
 
 ## Example Test Structure
+
 ```typescript
 // Example using Jest and Spectator
 import { createComponentFactory, Spectator } from '@ngneat/spectator';
@@ -57,5 +61,6 @@ describe('MyComponent', () => {
 ```
 
 ## Additional Resources
+
 - [Jest Documentation](https://jestjs.io/docs/getting-started)
-- [Spectator Documentation](https://ngneat.github.io/spectator/)
+- [Spectator Documentation](https://ngneat.github.io/spectator/)