| 1 |
<!-- AI guardrail: Do not run `git commit` or `git push`. You may only suggest a commit message. --> |
| 2 |
|
| 3 |
# Description |
| 4 |
|
| 5 |
Fixes #(issue number) |
| 6 |
*Explain how this code impacts users.* |
| 7 |
|
| 8 |
## Type of change |
| 9 |
|
| 10 |
- [ ] New feature (non-breaking change which adds functionality). |
| 11 |
- [ ] Bug fix (non-breaking change which fixes an issue). |
| 12 |
- [ ] Enhancement (non-breaking change which improves an existing functionality). |
| 13 |
- [ ] Breaking change (fix or feature that would cause existing functionality to not work as before). |
| 14 |
- [ ] Sub-task of #(issue number) |
| 15 |
- [ ] Chore |
| 16 |
- [ ] Release |
| 17 |
|
| 18 |
## Detailed scenario |
| 19 |
|
| 20 |
### What was tested |
| 21 |
|
| 22 |
*Describe the scenarios that you tested, and specify if it is automated or manual. For manual scenarios, provide a screenshot of the results.* |
| 23 |
|
| 24 |
### How to test |
| 25 |
|
| 26 |
*Describe how the PR can be tested so that the validator can be autonomous: environment, dependencies, specific setup, steps to perform, API requests, etc.* |
| 27 |
|
| 28 |
### Affected Features & Quality Assurance Scope |
| 29 |
|
| 30 |
*Please specify which existing features or modules are impacted by the changes in this Pull Request. This information is crucial for the QA team to properly define the testing scope and ensure comprehensive test coverage.* |
| 31 |
|
| 32 |
## Technical description |
| 33 |
|
| 34 |
### Documentation |
| 35 |
|
| 36 |
*Explain how this code works. Diagrams & drawings are welcome.* |
| 37 |
|
| 38 |
### New dependencies |
| 39 |
|
| 40 |
*List any new dependencies that are required for this change.* |
| 41 |
|
| 42 |
### Risks |
| 43 |
|
| 44 |
*List possible performance & security issues or risks, and explain how they have been mitigated.* |
| 45 |
|
| 46 |
# Mandatory Checklist |
| 47 |
|
| 48 |
## Code validation |
| 49 |
|
| 50 |
- [ ] I validated all the Acceptance Criteria. If possible, provide screenshots or videos. |
| 51 |
- [ ] I triggered all changed lines of code at least once without new errors/warnings/notices. |
| 52 |
- [ ] I implemented built-in tests to cover the new/changed code. |
| 53 |
|
| 54 |
## Code style |
| 55 |
|
| 56 |
- [ ] I wrote a self-explanatory code about what it does. |
| 57 |
- [ ] I protected entry points against unexpected inputs. |
| 58 |
- [ ] I did not introduce unnecessary complexity. |
| 59 |
- [ ] Output messages (errors, notices, logs) are explicit enough for users to understand the issue and are actionnable. |
| 60 |
|
| 61 |
## Unticked items justification |
| 62 |
|
| 63 |
*If some mandatory items are not relevant, explain why in this section.* |
| 64 |
|
| 65 |
# Additional Checks |
| 66 |
- [ ] In the case of complex code, I wrote comments to explain it. |
| 67 |
- [ ] When possible, I prepared ways to observe the implemented system (logs, data, etc.) |
| 68 |
- [ ] I added error handling logic when using functions that could throw errors (HTTP/API request, filesystem, etc.) |
| 69 |
|
