Prepare blueprint install support

This commit is contained in:
2026-03-23 16:31:16 +01:00
parent 9448176ff4
commit 48f8ef6265
7 changed files with 200 additions and 48 deletions

11
.idea/start prompt.md generated
View File

@@ -6,6 +6,7 @@ Project identity:
- This is a Home Assistant custom integration named `bahmcloud_store`.
- The product goal is a provider-neutral store for Home Assistant custom integrations, similar in spirit to HACS, but not limited to GitHub.
- Current real provider implementation is strongest for GitHub, GitLab, and Gitea-compatible providers. Unknown providers currently fall through the Gitea-style code paths, so do not assume every arbitrary Git provider works without verification.
- The long-term product direction is broader than integrations only: the store should evolve into a Home Assistant content store that can manage integrations, blueprints, templates, Lovelace designs, and additional future categories from multiple git providers.
Working rules:
- All project-facing work must be done in English only, regardless of the language the user speaks in chat. This applies to code comments, documentation, changelog entries, release notes, commit messages, PR text, UI text, issue text, and any other project artifacts unless the user explicitly requests a specific exception for repository content.
@@ -102,6 +103,16 @@ Code-analysis findings that should influence future work:
- The end-user and full READMEs contain some stale or inconsistent details compared with the current UI and code. Verify behavior in source before using README text as specification.
- There are visible encoding/mojibake issues in some documentation and older UI assets. Preserve valid UTF-8 when editing.
Planned product expansion:
1. Add support for Home Assistant blueprints and install them directly into the correct Home Assistant blueprint location from the store.
2. Add templates and Lovelace designs to the store so they can be discovered and installed from the same UI.
3. Add support for more categories beyond integrations and design the architecture so category-specific install targets and validation rules are explicit.
Implications for future architecture:
- The current install pipeline is integration-centric because it assumes repository content under `custom_components/`.
- Future category support should move toward category-aware install strategies instead of one universal install path.
- Store metadata and index entries will likely need stronger category typing, install-target definitions, and validation rules per category.
Project constraints to respect in future edits:
- Keep async I/O non-blocking in Home Assistant.
- Avoid startup-heavy network work before HA is fully started.