chore: update PR remplate, labels & copilot instructions (#7593)

* chore: update PR remplate & copilot instructions

* chore: add proper labels

* chore: use commit instead of master for sonarcloud

* chore: update labeler

Author: aweiss-dev

.github/PULL_REQUEST_TEMPLATE.md

@@ -1,20 +1,29 @@
-## Description
+# Pull Request
 
-<!-- Uncomment this section if your PR has UI changes -->
-<!--
-## Screenshots/Screencast (for UI changes)
--->
+## Summary
 
-## Checklist
+- What did I change and why?
+- Risks and how to roll out / roll back (e.g. feature flags):
 
-- [ ] mentions the JIRA issue in the PR name (Ex. [WPB-XXXX])
-- [ ] PR has been self reviewed by the author;
-- [ ] Hard-to-understand areas of the code have been commented;
-- [ ] If it is a core feature, unit tests have been added;
+---
 
-<!-- Uncomment this section if it is necessary to understand the PR -->
-<!-- ## Important Details for the Reviewers
+## Security Checklist (required)
 
-- use (x) data
-- can be reviewed commit-by-commit
-- be sure to look at ... -->
+- [ ] **External inputs are validated & sanitized** on client and/or server where applicable.
+- [ ] **API responses are validated**; unexpected shapes are handled safely (fallbacks or errors).
+- [ ] **No unsafe HTML is rendered**; if unavoidable, sanitization is applied **and** documented where it happens.
+- [ ] **Injection risks (XSS/SQL/command) are prevented** via safe APIs and/or escaping.
+
+## Standards Acknowledgement (required)
+
+- [ ] I have read and this PR **upholds** our [Coding Standards](https://github.com/wireapp/wire-web-packages/tree/docs/coding-standards.md) and [Tech Radar Choices](https://github.com/wireapp/wire-web-packages/tree/docs/tech-radar.md).
+
+---
+
+## Screenshots or demo (if the user interface changed)
+
+## Notes for reviewers
+
+- Trade-offs:
+- Follow-ups (linked issues):
+- Linked PRs (e.g. web-packages):

.github/copilot-instructions.md

@@ -0,0 +1,84 @@
+# Copilot — Repository Instructions (Security-first)
+
+## Goals & tone
+
+- Apply our **Web Coding Standards** during **PR description drafting** and **code review**.
+- Prefer **specific, actionable** comments with short code examples.
+- Use severities: **[Blocker]**, **[Important]**, **[Suggestion]**.
+- Do **not** nitpick items handled by automation (formatting, lint rules).
+
+Related docs (important):
+
+- **Coding Standards:** docs/coding-standards.md
+- **Tech Radar:** docs/tech-radar.md
+
+**Additional rules (open when relevant)**
+
+- Security: `.github/instructions/security.instructions.md`
+- Accessibility: `.github/instructions/accessibility.instructions.md`
+- React/UX: `.github/instructions/react.instructions.md`
+- TypeScript: `.github/instructions/typescript.instructions.md`
+
+---
+
+## PR description — Auto-checks Copilot should perform
+
+---
+
+## Security Checklist (required)
+
+- [ ] **External inputs validated & sanitised** (client/server as applicable). _Tick if_ validation/sanitisation is visible before use.
+- [ ] **API responses validated**; unexpected shapes handled (fallbacks/errors). _Tick if_ guards/schemas are present at boundaries.
+- [ ] **No unsafe HTML is rendered**; if unavoidable, sanitisation is applied **and** noted where it happens. _Fail signal:_ `dangerouslySetInnerHTML` without sanitiser (e.g., `DOMPurify.sanitize`).
+- [ ] **Injection risks (XSS/SQL/command) mitigated** via safe APIs/escaping. _Tick if_ sinks are avoided or safely wrapped.
+
+---
+
+## When reviewing pull requests (Copilot)
+
+**Scope & approach**
+
+- Review **from the code diff only**; do not assume runtime behavior.
+- Use severities: **[Blocker]**, **[Important]**, **[Suggestion]**.
+- Provide concise, actionable comments; include a minimal before/after snippet where useful.
+
+### Security (focus of inline review)
+
+- Avoid/flag `dangerouslySetInnerHTML`; if present, require sanitisation and name the sanitizer.
+- No raw DOM insertion into trusted contexts; validate URLs/redirect targets.
+- Validate untrusted inputs and API responses **before** use; prefer schemas/guards.
+- Check for secrets/tokens in code, configs, and tests.
+- Call out missing error/fallback paths on boundary failures.
+
+### Accessibility (minimum check)
+
+- Keyboard access (Esc closes dialogs), visible focus, correct roles/labels.
+- Use of `aria-live` for async status where appropriate.
+
+### Everything else
+
+- For imports/TS/React/testing/naming/readability: **refer to** the [Coding Standards](docs/coding-standards.md).
+  - If a standard is violated, link the relevant section and suggest a minimal change.
+
+### Technology choices
+
+- Compare any new dependencies in `package.json`/lockfiles to the [Tech Radar](docs/tech-radar.md).
+  - If not **Adopt**/**Trial**, mark **[Blocker]** and request an RFC/approval link.
+  - For **Trial**, ensure usage is narrowly scoped and success criteria exist.
+
+---
+
+## Comment format Copilot should use
+
+**Top-level summary**
+
+- Verdict: **Ready** / **Changes requested**, with counts of Blockers/Important/Suggestions.
+- Mini checklist (only items evidenced by diff): Security, Accessibility, Tech choices, (then link to Coding Standards for any non-security notes).
+
+**Inline comments**
+
+- One issue per comment with severity, file:line, brief reason, and (when helpful) a minimal suggested patch.
+
+**Approval**
+
+- Approve only if there are **no Blockers** and Important items are fixed or explicitly deferred with rationale.

.github/instructions/accessibility.instructions.md

@@ -0,0 +1,10 @@
+---
+appliesTo:
+  paths:
+    - 'src/**/*'
+---
+
+# Copilot — Accessibility
+
+- Ensure keyboard access is coded: focusable controls; Escape key closes dialogs; trap & restore focus in dialogs.
+- Use semantic elements; provide names/labels; add `aria-live` for async status updates where relevant.

.github/instructions/react.instructions.md

@@ -0,0 +1,13 @@
+---
+appliesTo:
+  paths:
+    - 'src/**/*.tsx'
+---
+
+# Copilot — React code review rules
+
+- Prefer event handlers or a data tool over `useEffect`.
+- If an effect is necessary, it must: (1) do one thing, (2) have stable deps, (3) avoid inline objects/functions in deps.
+- No derived state from props unless justified.
+- Keys in lists: stable unique ids; never array indexes.
+- Keep UI components “dumb”: render from props; move business logic to a separate module or hook.

.github/instructions/security.instructions.md

@@ -0,0 +1,11 @@
+---
+appliesTo:
+  paths:
+    - 'src/**/*'
+---
+
+# Copilot — Security hygiene
+
+- Validate and sanitise **all untrusted input** and **all API responses**.
+- Avoid `dangerouslySetInnerHTML`. If used, it must be sanitised and commented with the sanitizer reference.
+- Avoid raw DOM insertion and unvalidated URLs; suggest safe helpers.

.github/instructions/typescript.instructions.md

@@ -0,0 +1,12 @@
+---
+appliesTo:
+  paths:
+    - 'src/**/*.ts'
+    - 'src/**/*.tsx'
+---
+
+# Copilot — TypeScript safety
+
+- Do not use `any`, type casts (`as T`/`<T>`), or the non-null operator `!`.
+- Exported APIs must have explicit types. Narrow with type guards (or schemas) at boundaries.
+- Handle `null`/`undefined` explicitly; avoid `@ts-ignore` (unless narrowly scoped with a reason).

.github/labeler.yml

@@ -1,4 +1,4 @@
-# Labels based on PR title
+# Types
 'type: refactoring 🛠':
   title: '^refactor(\(.+\))?:.*'
 'type: bug / fix 🐞':
@@ -12,10 +12,53 @@
 'type: test 👷':
   title: '^test(\(.+\))?:.*'
 
+# Sizes
+'👕 size: XS':
+  size-below: 10
+'👕 size: S':
+  size-above: 9
+  size-below: 100
+'👕 size: M':
+  size-above: 99
+  size-below: 300
+'👕 size: L':
+  size-above: 299
+  size-below: 500
+'👕 size: XL':
+  size-above: 499
+  size-below: 1000
+'👕 size: XXL':
+  size-above: 999
+
 # Labels based on changed files
 'comp: infrastructure':
   files:
     - 'bin/.*'
     - '.github/.*'
     - '.travis.yml'
     - 'lerna.json'
+'comp: api-client':
+  files:
+    - 'packages/api-client/.*'
+'comp: core':
+  files:
+    - 'packages/core/.*'
+'comp: ui-kit':
+  files:
+    - 'packages/ui-kit/.*'
+'comp: store':
+  files:
+    - 'packages/store-engine/.*'
+    - 'packages/store-engine-dexie/.*'
+    - 'packages/store-engine-fs/.*'
+'comp: config':
+  files:
+    - 'packages/eslint-config/.*'
+    - 'packages/prettier-config/.*'
+    - 'packages/copy-config/.*'
+'comp: telemetry':
+  files:
+    - 'packages/telemetry/.*'
+'comp: events':
+  files:
+    - 'packages/webapp-events/.*'

.github/workflows/jira-lint-and-link.yml

@@ -0,0 +1,18 @@
+name: Link and Lint PR with Jira Ticket Number
+on:
+  pull_request:
+    types: [opened, edited, synchronize]
+jobs:
+  add-jira-description:
+    # avoid triggering this action on dependabot PRs
+    if: ${{ github.actor != 'dependabot[bot]' }}
+    runs-on: ubuntu-latest
+    steps:
+      - uses: cakeinpanic/jira-description-action@235b8296c8b4f88c564297246810f084f853dac1
+        name: jira-description-action
+        with:
+          github-token: ${{ secrets.GITHUB_TOKEN }}
+          jira-token: ${{ secrets.JIRA_TOKEN }}
+          jira-base-url: https://wearezeta.atlassian.net
+          skip-branches: '^(dev|master|release\/*)$'
+          fail-when-jira-issue-not-found: true

.github/workflows/label.yml

@@ -11,6 +11,6 @@ jobs:
     steps:
       # The settings for this action are in `.github/labeler.yml`.
       # See https://github.com/srvaroa/labeler.
-      - uses: srvaroa/labeler@v1.4
+      - uses: srvaroa/labeler@0a20eccb8c94a1ee0bed5f16859aece1c45c3e55
         env:
           GITHUB_TOKEN: ${{secrets.OTTO_THE_BOT_GH_TOKEN}}

docs/coding-standards.md

@@ -0,0 +1,81 @@
+# Coding Standards
+
+These standards guide everyday code contributions. They complement the Security Checklist in the PR template.
+
+## 1) Imports, Exports, and Module Boundaries
+
+- Use **named exports only**; avoid default exports.
+- Use **named imports only**; do not rename imports with `as`.
+- Avoid circular dependencies; keep module boundaries clear.
+
+## 2) TypeScript: Type Safety & Validation
+
+- Avoid `any`, type assertions/casts (`as`, `<Type>`) and the non-null `!` operator unless absolutely necessary and justified.
+- Prefer type guards for safe narrowing.
+- Validate external data (user input, API responses, storage) before use; handle unexpected shapes.
+
+## 3) Naming, Documentation, and Readability
+
+- Use descriptive names; avoid vague terms/abbreviations.
+- Add JSDoc-style comments for methods (purpose, parameters, returns).
+- Prefer one statement per line (including split chained calls).
+- Prefer modern TS/JS features (destructuring, spread/rest).
+
+## 4) Coding Style & Functionality
+
+- Minimize variable scope; declare variables near first use.
+- Prefer early returns over deep nesting.
+- Keep helper functions pure and side-effect free.
+- Prefer arrow functions unless `this/arguments` semantics are required.
+- Ensure no unhandled promises.
+
+## 5) React: Effects, State, and Components
+
+- Do **not** reach for `useEffect` by default; trigger actions from events.
+- Use declarative data tools instead of hand-wired effects where possible.
+- Each effect has a single responsibility with minimal, stable deps.
+- Avoid inline objects/functions that cause re-renders.
+- Keep components “dumb” and focused—render from props; move logic up.
+- Prefer functional components + hooks.
+- Use stable keys in lists (never array indexes).
+
+## 6) Abstraction and Duplication
+
+- Duplication is sometimes better than a wrong abstraction.
+- Inline first; abstract once patterns stabilize.
+- Be willing to delete/inline poor abstractions.
+
+## 7) Accessibility (a11y)
+
+- Full keyboard support; visible focus; Escape closes modals.
+- Use appropriate ARIA landmarks/roles; live regions for async updates.
+- Custom components follow accessible patterns (e.g., focus-trapped dialogs, proper labeling, sensible tab order).
+
+## 8) Testing
+
+- Component unit tests for new/changed logic (cover success & failure paths).
+- E2E tests for affected critical paths, or mark N/A with a reason.
+- For TS modules, include meaningful unit tests; emphasize public APIs; prefer pure functions.
+
+## 9) Technology Choices ([Tech Radar](./tech-radar.md))
+
+- Use well-understood, approved technologies.
+- If introducing experimental tech, keep usage limited, justify it.
+- Do not introduce unrecommended tech; prefer refactoring/migrating away.
+
+## 10) Documentation
+
+- Update documentation when behavior or usage changes.
+- Document migrations.
+- Keep PR title/description clear and consistent with the change.
+- Link the PR to the relevant Jira ticket.
+
+## 11) PR Formatting & Media
+
+- For UI/design changes, include screenshots or a short video.
+- For technical PRs, include a clear description of the problem, scope, and user impact.
+- Add inline comments on critical paths/logic to guide reviewers.
+
+---
+
+**Note:** Security-critical checks live in the PR template’s “Security Checklist” and must be explicitly acknowledged there.