pyhaseiq 0.1.0__tar.gz

pyhaseiq-0.1.0/.github/ISSUE_TEMPLATE/bug_report.yml

@@ -0,0 +1,58 @@
+name: Rapport de bug
+description: Un comportement inattendu de la bibliothèque ou du poêle
+labels: [bug]
+body:
+  - type: markdown
+    attributes:
+      value: |
+        ⚠️ **Deux générations de poêles portent le nom « Hase iQ ».** Cette bibliothèque ne
+        parle qu'à **l'ancienne**, celle pilotée par l'application `flamemonitor`. Si votre
+        poêle se pilote avec l'application `HASE iQ`, elle ne fonctionnera pas — ce n'est pas
+        un bug.
+  - type: dropdown
+    id: generation
+    attributes:
+      label: Application de pilotage
+      description: Celle que vous utilisez habituellement avec votre poêle.
+      options:
+        - flamemonitor (ancienne génération — supportée)
+        - Hase iQ (nouvelle génération — non supportée)
+        - Je ne sais pas
+    validations:
+      required: true
+  - type: textarea
+    id: description
+    attributes:
+      label: Description
+      description: Ce qui se passe, et ce que vous attendiez.
+    validations:
+      required: true
+  - type: textarea
+    id: reproduction
+    attributes:
+      label: Reproduction
+      description: Les étapes, et le code minimal qui déclenche le problème.
+    validations:
+      required: true
+  - type: input
+    id: versions
+    attributes:
+      label: Versions du poêle
+      description: >-
+        Sortie de `uv run demo.py <ip> --request _oemver --request _wversion --request _oemdev`.
+      placeholder: _oemver = AAF_5815=9, _wversion = 1.4, _oemdev = 2
+    validations:
+      required: true
+  - type: input
+    id: environment
+    attributes:
+      label: Environnement
+      placeholder: macOS 15.4, Python 3.13, pyhaseiq 0.1.0
+    validations:
+      required: true
+  - type: textarea
+    id: logs
+    attributes:
+      label: Logs
+      description: Le dialogue WebSocket si vous l'avez (`demo.py --debug`). Rendu en bloc de code.
+      render: text

pyhaseiq-0.1.0/.github/ISSUE_TEMPLATE/config.yml

@@ -0,0 +1,5 @@
+blank_issues_enabled: false
+contact_links:
+  - name: Faille de sécurité
+    url: https://github.com/bbayszczak/pyhaseiq/security/advisories/new
+    about: Signalement privé — n'ouvrez jamais d'issue publique pour une vulnérabilité.

pyhaseiq-0.1.0/.github/ISSUE_TEMPLATE/feature_request.yml

@@ -0,0 +1,29 @@
+name: Proposition
+description: Une évolution de la bibliothèque
+labels: [enhancement]
+body:
+  - type: markdown
+    attributes:
+      value: |
+        `pyhaseiq` est une bibliothèque **en lecture seule** et **sans état** : elle interroge
+        le poêle, rien d'autre. Historisation, seuils, notifications et toute écriture
+        appartiennent à la couche appelante. Voir [CONTRIBUTING.md](../blob/main/CONTRIBUTING.md).
+  - type: textarea
+    id: besoin
+    attributes:
+      label: Besoin
+      description: Le problème concret que cela résout, pas la solution envisagée.
+    validations:
+      required: true
+  - type: textarea
+    id: proposition
+    attributes:
+      label: Proposition
+      description: Ce que vous imaginez, et l'état de validation du protocole s'il est concerné.
+  - type: checkboxes
+    id: perimetre
+    attributes:
+      label: Périmètre
+      options:
+        - label: Cette proposition n'écrit rien sur le poêle et ne conserve aucun état dans la bibliothèque.
+          required: true

pyhaseiq-0.1.0/.github/dependabot.yml

@@ -0,0 +1,12 @@
+# Les actions sont épinglées sur des SHA complets dans .github/workflows (protection contre
+# le redéplacement d'un tag). Dependabot est donc indispensable : sans lui, ces SHA figés ne
+# recevraient jamais les correctifs de sécurité amont.
+version: 2
+updates:
+  - package-ecosystem: github-actions
+    directory: /
+    schedule:
+      interval: weekly
+    commit-message:
+      # Conventional Commits : `ci` n'entraîne pas de release (cf. release-please).
+      prefix: ci

pyhaseiq-0.1.0/.github/workflows/ci.yml

@@ -0,0 +1,44 @@
+name: CI
+
+on:
+  push:
+    branches: [main]
+  pull_request:
+
+permissions:
+  contents: read
+
+concurrency:
+  group: ${{ github.workflow }}-${{ github.ref }}
+  cancel-in-progress: true
+
+jobs:
+  lint:
+    name: Lint
+    runs-on: ubuntu-latest
+    steps:
+      - uses: actions/checkout@3d3c42e5aac5ba805825da76410c181273ba90b1 # v7.0.1
+      - uses: astral-sh/setup-uv@bec219d24cd3e171d82865faccec33120bb574f4 # v10.1.0
+        with:
+          enable-cache: true
+      - name: ruff check
+        run: uv run ruff check --output-format=github .
+      - name: ruff format
+        run: uv run ruff format --check --diff .
+
+  test:
+    name: Test (Python ${{ matrix.python-version }})
+    runs-on: ubuntu-latest
+    strategy:
+      fail-fast: false
+      matrix:
+        python-version: ["3.13", "3.14"]
+    steps:
+      - uses: actions/checkout@3d3c42e5aac5ba805825da76410c181273ba90b1 # v7.0.1
+      - uses: astral-sh/setup-uv@bec219d24cd3e171d82865faccec33120bb574f4 # v10.1.0
+        with:
+          enable-cache: true
+          python-version: ${{ matrix.python-version }}
+      # The test suite runs against a fake stove, so no hardware is required.
+      - name: pytest
+        run: uv run --python ${{ matrix.python-version }} pytest

pyhaseiq-0.1.0/.github/workflows/release.yml

@@ -0,0 +1,141 @@
+name: Release
+
+on:
+  push:
+    branches: [main]
+
+permissions:
+  contents: read
+
+concurrency:
+  group: release-${{ github.ref }}
+  cancel-in-progress: false
+
+jobs:
+  # Maintient une PR de release à partir des Conventional Commits : elle accumule le
+  # CHANGELOG et le bump de version, et déclenche tag + GitHub Release une fois fusionnée.
+  release-please:
+    name: Release PR
+    runs-on: ubuntu-latest
+    permissions:
+      # Le GITHUB_TOKEN ne porte plus aucune écriture : le token de l'App s'en charge.
+      contents: read
+    outputs:
+      release_created: ${{ steps.release.outputs.release_created }}
+      tag_name: ${{ steps.release.outputs.tag_name }}
+    steps:
+      # release-please s'authentifie en GitHub App plutôt qu'avec le GITHUB_TOKEN, pour deux
+      # raisons. Ce dernier se voit refuser la création de PR tant que le réglage « Allow
+      # GitHub Actions to create and approve pull requests » du dépôt est décoché ; et surtout
+      # ses écritures ne déclenchent aucun workflow, si bien que la PR de release n'obtiendrait
+      # jamais les checks que le ruleset de main exige et resterait infusionnable. Une App est
+      # une identité distincte : ses événements déclenchent la CI, et le token d'installation
+      # qu'on en dérive expire au bout d'une heure.
+      - name: Mint a GitHub App token
+        id: app-token
+        uses: actions/create-github-app-token@bcd2ba49218906704ab6c1aa796996da409d3eb1 # v3.2.0
+        with:
+          client-id: ${{ secrets.RELEASE_PLEASE_CLIENT_ID }}
+          private-key: ${{ secrets.RELEASE_PLEASE_PRIVATE_KEY }}
+
+      - uses: googleapis/release-please-action@45996ed1f6d02564a971a2fa1b5860e934307cf7 # v5.0.0
+        id: release
+        with:
+          token: ${{ steps.app-token.outputs.token }}
+          config-file: release-please-config.json
+          manifest-file: .release-please-manifest.json
+
+      # release-please bump la version dans pyproject.toml mais ignore uv.lock, qui porte lui
+      # aussi la version du paquet. Sans resynchronisation, le lockfile est périmé dès la
+      # release et le premier `uv run` venu le réécrit. On corrige sur la branche de la PR de
+      # release, avant sa fusion, pour que main ne reçoive jamais de lockfile désaligné.
+      # `uv lock` relit pyproject.toml : la règle survit à tout changement de schéma de version.
+      - name: Check out the release pull request branch
+        if: steps.release.outputs.pr
+        uses: actions/checkout@3d3c42e5aac5ba805825da76410c181273ba90b1 # v7.0.1
+        with:
+          ref: ${{ fromJson(steps.release.outputs.pr).headBranchName }}
+
+      - name: Set up uv
+        if: steps.release.outputs.pr
+        uses: astral-sh/setup-uv@bec219d24cd3e171d82865faccec33120bb574f4 # v10.1.0
+
+      - name: Sync uv.lock with the bumped version
+        if: steps.release.outputs.pr
+        env:
+          GH_TOKEN: ${{ steps.app-token.outputs.token }}
+          # Le court-circuit n'est pas décoratif : les expressions d'un bloc `env:` de step
+          # sont évaluées avant son `if:`, à la différence de celles d'un `with:`. Sur les runs
+          # qui publient une release au lieu d'ouvrir une PR, `steps.release.outputs.pr` est
+          # vide ; sans garde, `fromJson` recevrait la chaîne vide et ferait échouer le step
+          # alors même qu'il doit être sauté.
+          BRANCH: ${{ steps.release.outputs.pr && fromJson(steps.release.outputs.pr).headBranchName || '' }}
+        run: |
+          uv lock
+          if git diff --quiet uv.lock; then
+            echo "uv.lock already in sync"
+            exit 0
+          fi
+          # Le commit passe par l'API et non par `git commit` : le ruleset de main exige des
+          # signatures vérifiées, or un commit fabriqué dans le runner n'est pas signé et
+          # bloquerait la fusion de la PR de release (« Commits must have verified
+          # signatures »). GitHub signe de lui-même les commits créés via son API, comme il
+          # le fait déjà pour ceux de release-please. `sha` est le blob du fichier tel qu'il
+          # est sur la branche : `uv lock` a modifié la copie de travail, pas HEAD.
+          gh api -X PUT "repos/${{ github.repository }}/contents/uv.lock" \
+            -f message="chore: sync uv.lock with the release version" \
+            -f branch="$BRANCH" \
+            -f sha="$(git rev-parse HEAD:uv.lock)" \
+            -f content="$(base64 -w0 uv.lock)"
+
+  # `uv build` exécute le backend hatchling et ses dépendances, soit du code tiers. Ce job
+  # est donc volontairement dépourvu de `id-token: write` : une dépendance de build
+  # compromise n'y trouve aucun jeton OIDC dont elle pourrait se servir pour publier.
+  # Les distributions sont aussi attachées à la GitHub Release, d'où elles restent
+  # installables hors index (`pip install <url du .whl>`).
+  build:
+    name: Build distributions
+    needs: release-please
+    if: needs.release-please.outputs.release_created == 'true'
+    runs-on: ubuntu-latest
+    permissions:
+      contents: write
+    steps:
+      - uses: actions/checkout@3d3c42e5aac5ba805825da76410c181273ba90b1 # v7.0.1
+      - uses: astral-sh/setup-uv@bec219d24cd3e171d82865faccec33120bb574f4 # v10.1.0
+        with:
+          enable-cache: true
+      - name: Build sdist and wheel
+        run: uv build
+      - name: Attach them to the release
+        env:
+          GH_TOKEN: ${{ github.token }}
+          TAG_NAME: ${{ needs.release-please.outputs.tag_name }}
+        run: gh release upload "$TAG_NAME" dist/*
+      - name: Hand the distributions over to the publishing job
+        uses: actions/upload-artifact@043fb46d1a93c77aae656e7c1c64a875d1fc6a0a # v7.0.1
+        with:
+          name: dist
+          path: dist/
+          if-no-files-found: error
+
+  # Trusted Publishing : PyPI authentifie le workflow sur le jeton OIDC que GitHub lui
+  # délivre, il n'y a donc aucun token d'API à stocker en secret.
+  # Ce job détient ce jeton, il est donc réduit au strict minimum : pas de checkout, pas de
+  # dépendance, aucun code du dépôt — seulement les distributions déjà construites et
+  # l'action de publication. Rien de ce qui s'y exécute ne provient d'une PR.
+  publish:
+    name: Publish to PyPI
+    needs: build
+    runs-on: ubuntu-latest
+    permissions:
+      id-token: write
+    steps:
+      - uses: actions/download-artifact@3e5f45b2cfb9172054b4087a40e8e0b5a5461e7c # v8.0.1
+        with:
+          name: dist
+          path: dist/
+      # L'action refuse de réécrire une version déjà présente sur PyPI : un rejeu du
+      # workflow échoue au lieu de corrompre.
+      - name: Publish to PyPI
+        uses: pypa/gh-action-pypi-publish@dc37677b2e1c63e2034f94d8a5b11f265b73ba33 # v1.14.2

pyhaseiq-0.1.0/.gitignore

@@ -0,0 +1,222 @@
+# Byte-compiled / optimized / DLL files
+__pycache__/
+*.py[codz]
+*$py.class
+
+# C extensions
+*.so
+
+# Distribution / packaging
+.Python
+build/
+develop-eggs/
+dist/
+downloads/
+eggs/
+.eggs/
+lib/
+lib64/
+parts/
+sdist/
+var/
+wheels/
+share/python-wheels/
+*.egg-info/
+.installed.cfg
+*.egg
+MANIFEST
+
+# PyInstaller
+#   Usually these files are written by a python script from a template
+#   before PyInstaller builds the exe, so as to inject date/other infos into it.
+*.manifest
+*.spec
+
+# Installer logs
+pip-log.txt
+pip-delete-this-directory.txt
+
+# Unit test / coverage reports
+htmlcov/
+.tox/
+.nox/
+.coverage
+.coverage.*
+.cache
+nosetests.xml
+coverage.xml
+*.cover
+*.py.cover
+.hypothesis/
+.pytest_cache/
+cover/
+
+# Translations
+*.mo
+*.pot
+
+# Django stuff:
+*.log
+local_settings.py
+db.sqlite3
+db.sqlite3-journal
+
+# Flask stuff:
+instance/
+.webassets-cache
+
+# Scrapy stuff:
+.scrapy
+
+# Sphinx documentation
+docs/_build/
+
+# PyBuilder
+.pybuilder/
+target/
+
+# Jupyter Notebook
+.ipynb_checkpoints
+
+# IPython
+profile_default/
+ipython_config.py
+
+# pyenv
+#   For a library or package, you might want to ignore these files since the code is
+#   intended to run in multiple environments; otherwise, check them in:
+# .python-version
+
+# pipenv
+#   According to pypa/pipenv#598, it is recommended to include Pipfile.lock in version control.
+#   However, in case of collaboration, if having platform-specific dependencies or dependencies
+#   having no cross-platform support, pipenv may install dependencies that don't work, or not
+#   install all needed dependencies.
+# Pipfile.lock
+
+# UV
+#   Similar to Pipfile.lock, it is generally recommended to include uv.lock in version control.
+#   This is especially recommended for binary packages to ensure reproducibility, and is more
+#   commonly ignored for libraries.
+# uv.lock
+
+# poetry
+#   Similar to Pipfile.lock, it is generally recommended to include poetry.lock in version control.
+#   This is especially recommended for binary packages to ensure reproducibility, and is more
+#   commonly ignored for libraries.
+#   https://python-poetry.org/docs/basic-usage/#commit-your-poetrylock-file-to-version-control
+# poetry.lock
+# poetry.toml
+
+# pdm
+#   Similar to Pipfile.lock, it is generally recommended to include pdm.lock in version control.
+#   pdm recommends including project-wide configuration in pdm.toml, but excluding .pdm-python.
+#   https://pdm-project.org/en/latest/usage/project/#working-with-version-control
+# pdm.lock
+# pdm.toml
+.pdm-python
+.pdm-build/
+
+# pixi
+#   Similar to Pipfile.lock, it is generally recommended to include pixi.lock in version control.
+# pixi.lock
+#   Pixi creates a virtual environment in the .pixi directory, just like venv module creates one
+#   in the .venv directory. It is recommended not to include this directory in version control.
+.pixi
+
+# PEP 582; used by e.g. github.com/David-OConnor/pyflow and github.com/pdm-project/pdm
+__pypackages__/
+
+# Celery stuff
+celerybeat-schedule
+celerybeat.pid
+
+# Redis
+*.rdb
+*.aof
+*.pid
+
+# RabbitMQ
+mnesia/
+rabbitmq/
+rabbitmq-data/
+
+# ActiveMQ
+activemq-data/
+
+# SageMath parsed files
+*.sage.py
+
+# Environments
+.env
+.envrc
+.venv
+env/
+venv/
+ENV/
+env.bak/
+venv.bak/
+
+# Spyder project settings
+.spyderproject
+.spyproject
+
+# Rope project settings
+.ropeproject
+
+# mkdocs documentation
+/site
+
+# mypy
+.mypy_cache/
+.dmypy.json
+dmypy.json
+
+# Pyre type checker
+.pyre/
+
+# pytype static type analyzer
+.pytype/
+
+# Cython debug symbols
+cython_debug/
+
+# PyCharm
+#   JetBrains specific template is maintained in a separate JetBrains.gitignore that can
+#   be found at https://github.com/github/gitignore/blob/main/Global/JetBrains.gitignore
+#   and can be added to the global gitignore or merged into this file.  For a more nuclear
+#   option (not recommended) you can uncomment the following to ignore the entire idea folder.
+# .idea/
+
+# Abstra
+#   Abstra is an AI-powered process automation framework.
+#   Ignore directories containing user credentials, local state, and settings.
+#   Learn more at https://abstra.io/docs
+.abstra/
+
+# Visual Studio Code
+#   Visual Studio Code specific template is maintained in a separate VisualStudioCode.gitignore 
+#   that can be found at https://github.com/github/gitignore/blob/main/Global/VisualStudioCode.gitignore
+#   and can be added to the global gitignore or merged into this file. However, if you prefer, 
+#   you could uncomment the following to ignore the entire vscode folder
+# .vscode/
+# Temporary file for partial code execution
+tempCodeRunnerFile.py
+
+# Ruff stuff:
+.ruff_cache/
+
+# PyPI configuration file
+.pypirc
+
+# Marimo
+marimo/_static/
+marimo/_lsp/
+__marimo__/
+
+# Streamlit
+.streamlit/secrets.toml
+
+# Captures réseau brutes : elles portent les adresses MAC du matériel réel.
+# Elles restent en local, jamais dans le dépôt. Voir la section « Méthode » de la spec.
+records/

pyhaseiq-0.1.0/.release-please-manifest.json

@@ -0,0 +1,3 @@
+{
+  ".": "0.1.0"
+}

pyhaseiq-0.1.0/CHANGELOG.md

@@ -0,0 +1,17 @@
+# Changelog
+
+## 0.1.0 (2026-09-21)
+
+
+### ⚠ BREAKING CHANGES
+
+* the package is now `pyhaseiq`, not `haseiq_connect`, and its API is asynchronous. `get_minimal_temp_percent()` is now `get_heat_up_percent()`, and `get_phase()` returns a `Phase` enum.
+
+### Features
+
+* rewrite as pyhaseiq, a read-only asynchronous library ([5957084](https://github.com/bbayszczak/pyhaseiq/commit/59570847858d51b1fe2591e22260dca1cff2fe84))
+
+
+### Documentation
+
+* use the manufacturer's own spelling for its name and products ([#2](https://github.com/bbayszczak/pyhaseiq/issues/2)) ([dbd12c4](https://github.com/bbayszczak/pyhaseiq/commit/dbd12c46514735a6c388027a10e0d08e7718dc9e))

pyhaseiq-0.1.0/CLAUDE.md

@@ -0,0 +1,143 @@
+# CLAUDE.md
+
+Contexte pour Claude Code sur ce dépôt.
+
+## Le projet
+
+`pyhaseiq` est une bibliothèque **en lecture seule** pour les poêles à bois **Hase iQ de la
+génération `flamemonitor`**, via leur WebSocket local. Rien d'autre.
+
+⚠️ **Deux générations portent le nom « Hase iQ ».** Seule l'ancienne, pilotée par l'application
+`flamemonitor`, est supportée ; celle de l'application `HASE iQ` n'a jamais été observée. Ne
+jamais laisser entendre dans la documentation ou le code que la nouvelle fonctionne.
+
+Le protocole est intégralement décrit dans [`docs/SPEC-PROTOCOLE-WS.md`](docs/SPEC-PROTOCOLE-WS.md),
+reconstitué par rétro-ingénierie à partir de captures réseau qui **ne sont pas versionnées** :
+elles portent les adresses MAC du matériel réel. Chaque affirmation y porte un statut ✅ validé / 🟡 partiel / ❓ supposé : s'y référer avant
+d'implémenter quoi que ce soit, et ne jamais coder sur la foi d'un point ❓.
+
+## Structure
+
+```
+src/pyhaseiq/
+  protocol.py    encodage base64 et parsing — fonctions pures, aucune I/O
+  client.py      client asynchrone, sérialise le dialogue
+  models.py      Phase
+  exceptions.py
+tests/
+  fake.py        faux poêle (serveur WebSocket) rejouant les réponses réelles
+docs/
+  SPEC-PROTOCOLE-WS.md
+tools/
+  extract.py     décode un export Wireshark en dialogue lisible
+demo.py          script de démonstration, lecture seule
+```
+
+## Commandes
+
+```bash
+uv run ruff check .      # lint
+uv run ruff format .     # formatage
+uv run pytest            # tests, sans matériel
+uv run demo.py <ip>      # lecture live sur un vrai poêle
+```
+
+Toujours passer par `uv`. Python ≥ 3.13, CI sur 3.13 et 3.14.
+
+## Conventions
+
+- **Commits en Conventional Commits**, en anglais. `release-please` s'en sert pour produire le
+  CHANGELOG et la version : seuls `feat:` et `fix:` déclenchent une release.
+- Documentation en français, code et docstrings en anglais.
+- **Logging** : `logging` standard, un `_LOGGER = logging.getLogger(__name__)` par module et
+  **aucune configuration** (ni handler, ni niveau, ni format) — l'hôte, typiquement Home
+  Assistant, possède les handlers et filtre sur `pyhaseiq.<module>`. Tout en `DEBUG`, en
+  formatage paresseux (`_LOGGER.debug("%s = %s", name, value)`), jamais de f-string — les
+  règles ruff `LOG` et `G` le vérifient. Les erreurs se lèvent, elles ne se loguent pas :
+  loguer *et* lever produit un doublon dans les journaux de l'appelant.
+- Le linter est strict (docstrings et annotations obligatoires dans `src/`) ; les tests en sont
+  dispensés via `per-file-ignores`.
+- Les actions GitHub sont **épinglées sur des SHA complets** (un tag comme `@v4` peut être
+  redéplacé sur un autre commit). Dependabot les met à jour ; ne jamais revenir à un tag mobile.
+- Dépôt public : `CONTRIBUTING.md` et `SECURITY.md` font foi côté contributeurs, les garder
+  cohérents avec ce fichier — notamment la liste des interdits ci-dessous.
+- `uv.lock` porte la version du paquet : le workflow de release le resynchronise sur la branche
+  de la PR de release. Ne pas l'éditer à la main, lancer `uv lock` après tout changement de
+  version ou de dépendance.
+- La fusion d'une PR de release publie le paquet sur **PyPI** via le *Trusted Publishing*
+  (OIDC) : aucun token d'API n'est stocké, l'autorisation vit dans le *publisher* déclaré côté
+  PyPI (dépôt `bbayszczak/pyhaseiq`, workflow `release.yml`). Renommer ce fichier ou le dépôt
+  casse la publication tant que le *publisher* n'est pas mis à jour.
+- Le workflow de release sépare volontairement `build` et `publish` : `uv build` exécute du
+  code tiers (hatchling et ses dépendances) et ne doit jamais tourner dans le job qui porte
+  `id-token: write`, sans quoi une dépendance de build compromise pourrait publier sur PyPI.
+  Ne pas refusionner ces deux jobs.
+- `release-please` tourne sous l'identité d'une **GitHub App** dédiée, jamais sous le
+  `GITHUB_TOKEN` : celui-ci ne peut pas ouvrir de PR tant que le réglage « Allow GitHub Actions
+  to create and approve pull requests » du dépôt est décoché, et ses écritures ne déclenchent
+  aucun workflow — la PR de release n'obtiendrait donc jamais les checks que le ruleset de
+  `main` exige et resterait infusionnable. Ses identifiants vivent dans les secrets
+  `RELEASE_PLEASE_CLIENT_ID` et `RELEASE_PLEASE_PRIVATE_KEY`. Le premier porte le **Client
+  ID** de l'App (`Iv23li…`), pas son App ID numérique : l'entrée `app-id` de l'action est
+  dépréciée et `client-id` attend l'autre valeur.
+- Le commit qui resynchronise `uv.lock` est créé par **l'API GitHub**, jamais par un
+  `git commit` dans le *runner* : `main` exige des signatures vérifiées, or un commit fabriqué
+  sur le *runner* n'est pas signé et bloque la fusion de la PR de release. GitHub signe les
+  commits passés par son API, et l'appel porte le token de l'App, donc la CI se redéclenche.
+
+## Principes de conception
+
+- **Lecture seule, définitivement.** Aucune commande d'écriture n'a été observée dans le
+  protocole et aucune n'est implémentée. C'est la garantie centrale du projet : une
+  bibliothèque qui ne fait que lire ne peut rien casser sur un appareil à combustion installé
+  chez quelqu'un. Ne jamais l'entamer, même « juste pour tester ».
+- **Le client ne connaît aucun état.** Pas de cache, pas d'historique, pas de reconnexion
+  automatique. Une connexion perdue reste perdue et l'appelant en ouvre une neuve. Toute
+  historisation, moyenne ou politique de reprise appartient à la couche appelante.
+- **Dialogue strictement sérialisé.** Le protocole n'a aucun identifiant de corrélation : rien
+  ne rattache une réponse à sa requête sinon l'ordre. D'où le verrou dans `Client.get()`. Le
+  test `test_concurrent_readings_are_serialised_and_never_swap_answers` garde la propriété — il
+  échoue si on retire le verrou.
+- **Cœur asynchrone assumé** : le poêle est un serveur WebSocket et la cible est Home
+  Assistant. Pas de façade synchrone.
+
+## Pièges du protocole
+
+- **Le préfixe se retire avec `removeprefix`, jamais avec `lstrip`.** `lstrip` prend un
+  *ensemble de caractères* : `"appT=appT".lstrip("appT=")` rend `""`. C'est un bug réel corrigé
+  ici, gardé par `test_the_prefix_is_removed_as_a_prefix_not_as_a_character_set`.
+- **La valeur peut contenir un `=`** : `_oemver` répond `_oemver=AAF_5815=9`. Ne découper que
+  sur le premier.
+- **Toutes les mesures ne sont pas lisibles dans toutes les phases.** L'application
+  constructeur ne demande `appT` et `appAufheiz` qu'en phase `HEATING_UP`, `appP` qu'en phase
+  `NOMINAL`. On ignore si le poêle répond hors phase ou se tait — auquel cas l'appel part au
+  `ResponseTimeoutError`. Tester la phase avant de lire.
+- **La phase `4` n'a jamais été observée** : elle vient de la documentation du poêle.
+
+## À ne pas faire
+
+- ⛔ **Ne jamais implémenter ni envoyer de commande d'écriture** vers le poêle.
+- ⛔ **Ne pas balayer de noms de requêtes au hasard** sur un poêle réel : on ignore ce qu'un
+  `_req=` inconnu déclenche dans le micrologiciel.
+- ⛔ **Ne pas recalculer `appAufheiz` à partir de `appT`.** La corrélation est forte
+  (R² = 0,992) mais pas exacte : le poêle y mêle autre chose.
+- ⛔ **Ne pas présenter les valeurs lues comme un dispositif de sécurité** — ni dans le code,
+  ni dans la documentation. Elles sont indicatives.
+- ⛔ **Ne jamais committer de capture réseau brute** — `.pcap`, export Wireshark, ou sortie de
+  `tools/extract.py`. Une capture Ethernet porte les **adresses MAC** du poêle et du téléphone,
+  qui sont des identifiants matériels permanents. `records/` est dans `.gitignore` pour cette
+  raison ; ne pas l'en retirer.
+
+## Sécurité
+
+Le poêle n'a **aucune authentification** : son WebSocket est ouvert à tout le réseau local.
+C'est un fait matériel, pas une faille de cette bibliothèque. La documentation doit le dire et
+rappeler de ne jamais exposer le port `8080` sur Internet.
+
+Les traces ne contiennent ni identifiant, ni clé, ni donnée personnelle : il n'y a rien à
+masquer dans les logs, contrairement à d'autres protocoles domotiques. Si une requête porteuse
+de secret apparaissait un jour, ce constat serait à revoir.
+
+Cela vaut pour les traces de la bibliothèque, **pas pour les captures réseau** dont la spec est
+issue : au niveau Ethernet, elles portent les adresses MAC du matériel. Elles restent hors du
+dépôt.