Copilot instructions

1<!-- Automatically generated by gen_copilot_instructions.py, do not edit -->
2 
3 
4 
5# Copilot code review instructions
6 
7- Start review comments with a short, one-sentence summary of the suggested fix.
8- Do not comment on code style, formatting or linting issues.
9- Flag comments that over-explain straightforward code, narrate the obvious, or read like AI commentary (multi-sentence justifications for a single line).
10- A Pull Request with a dependency version bump should only contain changes required for the version bump. If the PR includes other changes, request that they are removed from the PR.
11- Check that the PR description is complete and filled in according to the PR template included below. Every section and checklist item from the template must be present, except the `## Breaking change` section which is optional. No content from the template should be missing, except for HTML comments and Markdown link reference definitions (lines of the form `[name]: url`), which do not render and cannot be verified from the description. Even unchecked checkboxes or empty sections must be present. This is a hard requirement.
12 
13## Pull Request template
14 
15The PR description must follow this template (from `.github/PULL_REQUEST_TEMPLATE.md`):
16 
17```markdown
18<!--
19  You are amazing! Thanks for contributing to our project!
20  Please, DO NOT DELETE ANY TEXT from this template! (unless instructed).
21-->
22## Breaking change
23<!--
24  If your PR contains a breaking change for existing users, it is important
25  to tell them what breaks, how to make it work again and why we did this.
26  This piece of text is published with the release notes, so it helps if you
27  write it towards our users, not us.
28  Note: Remove this section if this PR is NOT a breaking change.
29-->
30 
31 
32## Proposed change
33<!--
34  Describe the big picture of your changes here to communicate to the
35  maintainers why we should accept this pull request. If it fixes a bug
36  or resolves a feature request, be sure to link to that issue in the
37  additional information section.
38-->
39 
40 
41## Type of change
42<!--
43  What type of change does your PR introduce to Home Assistant?
44  NOTE: Please, check only 1! box!
45  If your PR requires multiple boxes to be checked, you'll most likely need to
46  split it into multiple PRs. This makes things easier and faster to code review.
47-->
48 
49- [ ] Dependency upgrade
50- [ ] Bugfix (non-breaking change which fixes an issue)
51- [ ] New integration (thank you!)
52- [ ] New feature (which adds functionality to an existing integration)
53- [ ] Deprecation (breaking change to happen in the future)
54- [ ] Breaking change (fix/feature causing existing functionality to break)
55- [ ] Code quality improvements to existing code or addition of tests
56 
57## Additional information
58<!--
59  Details are important, and help maintainers processing your PR.
60  Please be sure to fill out additional details, if applicable.
61-->
62 
63- This PR fixes or closes issue: fixes #
64- This PR is related to issue: 
65- Link to documentation pull request: 
66- Link to developer documentation pull request: 
67- Link to frontend pull request: 
68 
69## Checklist
70<!--
71  Put an `x` in the boxes that apply. You can also fill these out after
72  creating the PR. If you're unsure about any of them, don't hesitate to ask.
73  We're here to help! This is simply a reminder of what we are going to look
74  for before merging your code.
75 
76  AI tools are welcome, but contributors are responsible for *fully*
77  understanding the code before submitting a PR. Please follow our AI policy:
78  https://developers.home-assistant.io/docs/ai_policy
79-->
80 
81- [ ] I understand the code I am submitting and can explain how it works.
82- [ ] The code change is tested and works locally.
83- [ ] Local tests pass. **Your PR cannot be merged unless tests pass**
84- [ ] There is no commented out code in this PR.
85- [ ] I have followed the [development checklist][dev-checklist]
86- [ ] I have followed the [perfect PR recommendations][perfect-pr]
87- [ ] The code has been formatted using Ruff (`ruff format homeassistant tests`)
88- [ ] Tests have been added to verify that the new code works.
89- [ ] Any generated code has been carefully reviewed for correctness and compliance with project standards.
90 
91If user exposed functionality or configuration variables are added/changed:
92 
93- [ ] Documentation added/updated for [www.home-assistant.io][docs-repository]
94 
95If the code communicates with devices, web services, or third-party tools:
96 
97- [ ] The [manifest file][manifest-docs] has all fields filled out correctly.  
98      Updated and included derived files by running: `python3 -m script.hassfest`.
99- [ ] New or updated dependencies have been added to `requirements_all.txt`.  
100      Updated by running `python3 -m script.gen_requirements_all`.
101- [ ] For the updated dependencies a diff between library versions and ideally a link to the changelog/release notes is added to the PR description.
102 
103<!--
104  This project is very active and we have a high turnover of pull requests.
105 
106  Unfortunately, the number of incoming pull requests is higher than what our
107  reviewers can review and merge so there is a long backlog of pull requests
108  waiting for review. You can help here!
109  
110  By reviewing another pull request, you will help raise the code quality of
111  that pull request and the final review will be faster. This way the general
112  pace of pull request reviews will go up and your wait time will go down.
113  
114  When picking a pull request to review, try to choose one that hasn't yet
115  been reviewed.
116 
117  Thanks for helping out!
118-->
119 
120To help with the load of incoming pull requests:
121 
122- [ ] I have reviewed two other [open pull requests][prs] in this repository.
123 
124[prs]: https://github.com/home-assistant/core/pulls?q=is%3Aopen+is%3Apr+-author%3A%40me+-draft%3Atrue+-label%3Awaiting-for-upstream+sort%3Acreated-desc+review%3Anone+-status%3Afailure
125 
126<!--
127  Thank you for contributing <3
128 
129  Below, some useful links you could explore:
130-->
131[dev-checklist]: https://developers.home-assistant.io/docs/development_checklist/
132[manifest-docs]: https://developers.home-assistant.io/docs/creating_integration_manifest/
133[quality-scale]: https://developers.home-assistant.io/docs/integration_quality_scale_index/
134[docs-repository]: https://github.com/home-assistant/home-assistant.io
135[perfect-pr]: https://developers.home-assistant.io/docs/review-process/#creating-the-perfect-pr
136```
137 
138# GitHub Copilot & Claude Code Instructions
139 
140This repository contains the core of Home Assistant, a Python 3 based home automation application.
141 
142## Git Commit Guidelines
143 
144- **Do NOT amend, squash, or rebase commits that have already been pushed to the PR branch after the PR is opened** - Reviewers need to follow the commit history, as well as see what changed since their last review
145 
146## Pull Requests
147 
148- When opening a pull request, use the repository's PR template (`.github/PULL_REQUEST_TEMPLATE.md`). NEVER REMOVE ANYTHING from the template.
149- Do not remove checkboxes that are not checked — leave all unchecked checkboxes in place so reviewers can see which options were not selected.
150 
151## Development Commands
152 
153- Run "python3" in current virtual environment to ensure the correct Python version is used for testing.
154- When entering a new environment or worktree, run `script/setup` to set up the virtual environment with all development dependencies (pylint, pre-commit hooks, etc.). This is required before committing. If uv reports that no download was found for the required Python version, the environment is running an outdated version of uv; upgrade it with `curl -LsSf https://astral.sh/uv/install.sh | sh` and run `script/setup` again.
155- .vscode/tasks.json contains useful commands used for development.
156- After finishing a code session, run `uv run prek run --all-files` to check for linting and formatting issues.
157 
158## Python Syntax Notes
159 
160- Home Assistant officially supports Python 3.14 as its minimum version. Do not flag syntax or features that require Python 3.14 as issues, and do not suggest workarounds for older Python versions.
161- Python 3.14 explicitly allows `except TypeA, TypeB:` without parentheses. Never flag this as an issue.
162- Python 3.14 evaluates annotations lazily (PEP 649). Forward references in annotations do not need to be quoted — annotations can reference names defined later in the module without quoting them or using `from __future__ import annotations`. Do not flag unquoted forward references in annotations as issues.
163 
164## Testing
165 
166- Use `uv run pytest` to run tests
167- After modifying `strings.json` for an integration, regenerate the English translation file before running tests: `python3 -m script.translations develop --integration <integration_name>`. Tests load translations from the generated `translations/en.json`, not directly from `strings.json`.
168- When writing or modifying tests, ensure all test function parameters have type annotations.
169- Prefer concrete types (for example, `HomeAssistant`, `MockConfigEntry`, etc.) over `Any`.
170- Prefer `@pytest.mark.usefixtures` over arguments, if the argument is not going to be used.
171- Avoid using conditions/branching in tests. Instead, either split tests or adjust the test parametrization to cover all cases without branching.
172- If multiple tests share most of their code, use `pytest.mark.parametrize` to merge them into a single parameterized test instead of duplicating the body. Use `pytest.param` with an `id` parameter to name the test cases clearly.
173- We use Syrupy for snapshot testing. Leverage `.ambr` snapshots instead of repetitive and exhaustive generation of test data within Python code itself.
174- Hardcoded `entity_id`s in tests are fine. If the same one is repeated, use a constant.
175 
176## Good practices
177 
178- Integrations with Platinum or Gold level in the Integration Quality Scale reflect a high standard of code quality and maintainability. When looking for examples of something, these are good places to start. The level is indicated in the manifest.json of the integration.
179- When reviewing entity actions, do not suggest extra defensive checks for input fields that are already validated by Home Assistant's service/action schemas and entity selection filters. Suggest additional guards only when data bypasses those validators or is transformed into a less-safe form.
180- When validation guarantees a dict key exists, prefer direct key access (`data["key"]`) instead of `.get("key")` so contract violations are surfaced instead of silently masked.
181- Keep comments concise. Prefer one short line stating the non-obvious constraint, or no comment at all.
182- Do not add comments that just restate the code on the following line(s) (e.g. `# Check if initialized` above `if self.initialized:`). Comments should only explain why (non-obvious constraints, surprising behavior, or workarounds), never what. Never add comments that justify a change by referencing what the code looked like before. Comments in tests that explain why a function call or assertion is made are ok.
183- Do not add section or divider comments (e.g. `# --- XYZ Triggers ---`) inside or outside of functions, since those can easily become stale and be misleading.
184- When catching exceptions, try-clauses should be as small as possible, i.e. avoid wrapping large blocks of code in a try-clause, and avoid catching exceptions from functions that are not expected to raise them.
185 
186## AI policy
187 
188This project follows the [Open Home Foundation AI Policy](AI_POLICY.md).
189Autonomous contributions are not accepted: a human must review, understand,
190and be able to explain every change before it is submitted. Do not open
191issues or pull requests autonomously, and do not post comments on behalf of
192a user without their review.
193