no-mistakes(ci): Hassfest CI failure diagnosed and fixed (2 files). ROOT CAUSE (confirmed against real upstream source, not inferred): the hassfest image discovers integrations from WORKDIR /github/workspace, and Integration.domain is self.path.name (script/hassfest/model.py); script/hassfest/manifest.py:355 errors when manifest["domain"] != path.name. This repo deliberately keeps the integration at the repo root (hacs.json content_in_root: true, since commit 3ab6ae4), so the discovered directory is the checkout dir ("workspace" in the container) and can never equal "lumentree". hassfest has NO content_in_root exemption anywhere, so the error is unsatisfiable for a root layout. Reproduced with a 1:1 port of entrypoint discovery + Integration.domain + the manifest check: BEFORE -> path.name='workspace' vs domain='lumentree' -> FAIL. Docker is unavailable locally, so the validator logic was ported and executed directly rather than guessed. SECOND (MASKED) DEFECT found while verifying: manifest.py's validate() only calls sort_manifest if not integration.errors, so the domain error was hiding a key-order error. Fixing only the path would just move the failure to "[MANIFEST] Manifest keys are not sorted correctly: domain, name, then alphabetical order". Required order (script/util.py _sort_manifest_keys) is domain, name, then alphabetical. Both had to be fixed. FIX (minimal, 2 files): 1. manifest.json - reordered keys to domain, name, then alphabetical. Semantically identical to HEAD (json.load(old)==json.load(new) -> True); only key order changed. 2. .github/workflows/ci.yml - the hassfest job's actions/checkout@v5 now uses path: custom_components/lumentree, so hassfest discovers a directory actually named after its domain. This is the workaround endorsed in home-assistant/core#152942 (closed not_planned). It relocates only the checkout: no plugin skipped, no check suppressed, no continue-on-error, and the validated file set is unchanged (.github holds no .json/.py, so the json/dependencies plugins see no new input). VERIFICATION: simulated the exact post-fix CI layout -> discovered integration-path=/custom_components/lumentree, domain='lumentree', dir.name='lumentree' -> match -> Hassfest PASS (exit 0). pytest tests/ -q -> 48 passed; ruff check . -> All checks passed; hacs.json untouched (HACS job already passing). The "[CONFIG_SCHEMA]" line in the log is a warning, not an error (hassfest exits 0 with warnings), so it was never the cause. Evidence written to C:\Users\Vokupt\.no-mistakes\evidence\hassfest-diagnosis.md

Author: ngoviet

.github/workflows/ci.yml

@@ -45,7 +45,18 @@ jobs:
     name: Hassfest
     runs-on: ubuntu-latest
     steps:
+      # hassfest compares manifest["domain"] against the *integration
+      # directory name*, and has no notion of hacs.json's content_in_root.
+      # This repo deliberately keeps the integration at the repository root
+      # (hacs.json "content_in_root": true), so a plain checkout presents
+      # hassfest with a directory named after the runner workspace and the
+      # domain check can never pass. Checking out into custom_components/,
+      # the layout hassfest expects, gives it a directory whose name matches
+      # the domain. This only relocates the checkout: the mounted workspace
+      # and the set of files hassfest validates are unchanged.
       - uses: actions/checkout@v5
+        with:
+          path: custom_components/lumentree
       - uses: home-assistant/actions/hassfest@master
 
   hacs:

manifest.json

@@ -1,22 +1,22 @@
 {
     "domain": "lumentree",
     "name": "Lumentree Inverter",
+    "codeowners": [
+        "@ngoviet"
+    ],
     "config_flow": true,
     "documentation": "https://github.com/ngoviet/lumentreeHA",
+    "integration_type": "device",
+    "iot_class": "cloud_polling",
     "issue_tracker": "https://github.com/ngoviet/lumentreeHA/issues",
+    "loggers": [
+        "paho",
+        "custom_components.lumentree"
+    ],
     "requirements": [
         "aiohttp>=3.8.0",
         "paho-mqtt>=1.6.0",
         "crcmod>=1.7"
     ],
-    "codeowners": [
-        "@ngoviet"
-    ],
-    "version": "5.1.3",
-    "iot_class": "cloud_polling",
-    "integration_type": "device",
-    "loggers": [
-        "paho",
-        "custom_components.lumentree"
-    ]
+    "version": "5.1.3"
 }