Prepare blueprint install support
This commit is contained in:
3
.idea/changes.md
generated
3
.idea/changes.md
generated
@@ -15,6 +15,9 @@
|
||||
- Added a persistent language rule that all project-facing repository content must stay in English regardless of the chat language.
|
||||
- Added persistent pinned repositories support: favorites are stored in settings, exposed by the backend, filterable and sortable in the store view, and toggleable from the detail view without forcing a full repository refresh.
|
||||
- Bumped the integration version from `0.7.3` to `0.7.4` and added the `0.7.4` release entry to `CHANGELOG.md` for the pinned-repositories feature.
|
||||
- Added the broader product roadmap to the persistent project prompt: blueprints, templates, Lovelace designs, and more category support as future store targets.
|
||||
- Started the blueprint/category-aware installer preparation: installation metadata now distinguishes install type and installed paths, repo payloads expose install targets, and the active panel shows install-target context for future non-integration categories.
|
||||
- Added initial blueprint install-path handling groundwork so the codebase is no longer fully hard-wired to `custom_components/`.
|
||||
|
||||
### Documented
|
||||
- Captured the verified project identity from the repository and README files: Bahmcloud Store is a Home Assistant custom integration intended to behave like a provider-neutral store for custom integrations, similar to HACS but broader than GitHub-only workflows.
|
||||
|
||||
11
.idea/start prompt.md
generated
11
.idea/start prompt.md
generated
@@ -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.
|
||||
|
||||
Reference in New Issue
Block a user