Developer Pre-PR Checklist

Complete this checklist before marking a pull request as ready for review. Place an x inside the brackets for each item you have verified. Leave items unchecked if they are not applicable and add a short comment why.

Branch & Commits

• [ ] Branch name follows the pattern feature/JIRA-123-short-description or the appropriate type prefix.
  (If not, rename the branch locally and force‑push after consulting the team lead.)

• [ ] Commit messages follow Conventional Commits with a Jira ticket reference when available.
  (Use git rebase -i to squash or reword if needed.)

Code Quality

• [ ] Code compiles without errors and warnings (warnings treated as errors).
  (Run dotnet build/ng build locally.)

• [ ] Formatting rules applied: dotnet format for C#, prettier and ng lint for Angular/TypeScript.
  (If the tools modify files, commit the formatted versions so CI sees no changes.)

• [ ] No commented‑out code or debug logging left in the changes.
  (Delete dead code; history is in version control. Remove console.log unless behind a log‑level guard.)

• [ ] No magic numbers or hardcoded strings – extracted to named constants, configuration, or SCSS variables.

• [ ] Imports/using statements are ordered and unused ones removed.

• [ ] (C#) async void is absent; all asynchronous methods return Task or Task<T>.

• [ ] (Angular) No any types added without justification and a Jira‑tagged TODO.

• [ ] (Angular) bypassSecurityTrust* functions are not used without explicit approval and documented reason.

Testing

• [ ] New logic is covered by unit tests (arrange‑act‑assert pattern).
  (Run dotnet test/ng test locally; verify no test project is skipped.)

• [ ] Test coverage has not decreased.
  (Check the coverage report; if threshold fails CI, add missing tests or document an approved exception.)

• [ ] Existing tests still pass.
  (Run the full test suite before pushing.)

• [ ] Edge cases, error paths, and boundary values are exercised.

• [ ] Mocked dependencies simulate realistic behavior; no direct database or network calls in unit tests.

Security

• [ ] No secrets, passwords, tokens, or connection strings are stored in code or configuration files.
  (Use environment variables / vault; if you added a development secret, ensure it is excluded via .gitignore.)

• [ ] User input is validated (data annotations, FluentValidation, reactive form validators).

• [ ] Authentication and authorization attributes are present on new endpoints / routes where required.

• [ ] Logging statements do not leak sensitive data.
  (Review all LogInformation/LogError calls and console output.)

Documentation

• [ ] Public API methods, classes, and interfaces carry XML/JSDoc comments.
  (Check that <summary>, <param>, <returns> are present for C#; @param, @returns for exported TypeScript functions.)

• [ ] Complicated algorithms or workarounds are explained with inline comments, and a Jira‑tagged TODO is added for temporary solutions.

• [ ] README.md or relevant Swagger descriptions are updated if the feature changes external behavior.

Configuration & Environment

• [ ] New environment variables or configuration keys are documented in the project’s deployment notes / Confluence.

• [ ] appsettings.json/environment.ts changes are correctly scoped (not affecting other environments unintentionally).

• [ ] CORS, CSP, or other security headers have been considered if new external access is introduced.

Manual Verification (if applicable)

• [ ] Feature has been tested manually in a running environment (attach screenshot / screen recording if complex).
  (Describe the steps you performed: …)

• [ ] UI renders correctly on supported browsers/viewports.