Development checklist

Go through this list before you commit. The pull request template asks you to confirm it, and reviewers check it.

• The code is formatted with Ruff (ruff format), and the Git hooks pass.
• The tests pass, and new code has tests.
• There is no commented out code.
• You understand every line, and you can explain it. This also applies to code an AI tool wrote for you.
• If a module is fully typed, it is listed in .strict-typing.

All communication with devices and services goes through a Python library published on PyPI. The integration itself contains no protocol code.

• The library has a source distribution on PyPI, not only prebuilt wheels.
• The source of the library is public, under an OSI-approved open source license that is compatible with Apache 2.0, the license of core. CI checks the licenses of the requirements with script/licenses.py, and fails when it finds no OSI-approved license. A few packages are on its list of exceptions, so a pass is not proof for every requirement. Compatibility with Apache 2.0 is checked by reviewers.
• The issue tracker of the library is enabled.
• New or updated requirements are in requirements_all.txt. Run python3 -m script.gen_requirements_all to update it.

If you maintain the library mainly for Home Assistant and you own the integration, consider an issue template picker that points users to the core issue tracker, like zwave-js-server-python does.

• The manifest.json is complete and correct.
• New integration owners are in CODEOWNERS. Run python3 -m script.hassfest to update it.
• Everything the user sees is in strings.json, not in the code. See making strings translatable.

• Anything that removes or changes existing behavior follows the deprecation process.
• Backward-incompatible changes are described in the pull request, for the people who use Home Assistant.
• If users can see the change, the documentation on home-assistant.io is updated in a pull request of its own. See writing documentation.