Add release notes and project prompts

.idea/.gitignore

@@ -0,0 +1,10 @@
+# Default ignored files
+/shelf/
+/workspace.xml
+# Ignored default folder with query files
+/queries/
+# Datasource local storage ignored files
+/dataSources/
+/dataSources.local.xml
+# Editor-based HTTP Client requests
+/httpRequests/

.idea/Projects.iml

@@ -0,0 +1,8 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<module type="WEB_MODULE" version="4">
+  <component name="NewModuleRootManager">
+    <content url="file://$MODULE_DIR$" />
+    <orderEntry type="inheritedJdk" />
+    <orderEntry type="sourceFolder" forTests="false" />
+  </component>
+</module>

.idea/changes.md

@@ -0,0 +1,39 @@
+# Changes Log
+
+## 2026-03-23
+
+### Added
+- Created `.idea/start prompt.md` as a persistent project working prompt for future sessions.
+- Added `.idea/changes.md` as the preferred in-project location for the detailed session change log.
+- Added release notes support in the active Bahmcloud Store runtime path: backend provider fetching, a dedicated API endpoint, and panel display for the currently selected version when provider release notes are available.
+- Bumped the Home Assistant panel asset cache-buster from `v=109` to `v=110` so the updated frontend loads reliably after deployment.
+
+### 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.
+- Recorded the actual active architecture from source analysis, including the config-entry-only setup, the fixed Bahmcloud store index, delayed startup refresh, periodic refresh, repo merge flow, cache usage, install/update/uninstall pipeline, backup/restore pipeline, update entities, and Repairs-based restart handling.
+- Recorded the current provider reality from code: GitHub, GitLab, and Gitea-compatible repositories are the concrete supported paths today, while truly generic "all git providers" support is still an intention and must be validated case by case.
+- Recorded the public API endpoints exposed by `views.py` so future work preserves the current backend contract unless a deliberate breaking change is approved.
+- Recorded storage facts from `storage.py`, including the `bcs_store` Home Assistant storage key and the persisted sections for custom repositories, installed repositories, settings, HACS cache, and repo enrichment cache.
+- Recorded frontend facts from the active panel registration in `__init__.py` and the active frontend implementation in `panel/panel.js`, including the cache-busting panel asset version query.
+- Updated the persistent start prompt to point future work to `.idea/changes.md` as the canonical detailed work log.
+- Release notes are intentionally tied to provider release objects, so tags or branches without release bodies now return a clear "not available" state instead of misleading fallback text.
+
+### Important findings from code analysis
+- Identified `custom_components/bahmcloud_store/panel/panel.js` as the active Home Assistant panel script currently loaded by the integration.
+- Identified `custom_components/bahmcloud_store/panel/app.js`, `custom_components/bahmcloud_store/panel/index.html`, and `custom_components/bahmcloud_store/panel/styles.css` as likely legacy or secondary assets that should not be treated as authoritative without verification.
+- Identified `custom_components/bahmcloud_store/store.py` as an older implementation with a different data model and API shape than the active `BCSCore` runtime.
+- Identified `custom_components/bahmcloud_store/custom_repo_view.py` as duplicate or legacy API code because the active custom-repo handling already exists in `views.py`.
+- Noted that the README set is directionally useful but not fully authoritative where it conflicts with current code behavior.
+- Noted that some repository files contain encoding or mojibake artifacts, so future edits should preserve valid UTF-8 and avoid spreading broken text.
+
+### Project rules written into the start prompt
+- Never push, commit, tag, or create a release without explicit user approval.
+- Always append a dated and detailed entry to `.idea/changes.md` for every change made.
+- When a release is created, collect all relevant changes since the last release into `CHANGELOG.md`.
+
+### Verification
+- Reviewed repository structure and current git status.
+- Read `README.md`, `README_DEVELOPER.md`, `README_FULL.md`, `bcs.yaml`, and the current `CHANGELOG.md`.
+- Analyzed the active backend files: `__init__.py`, `const.py`, `core.py`, `providers.py`, `metadata.py`, `storage.py`, `views.py`, `config_flow.py`, `update.py`, and `repairs.py`.
+- Checked panel and legacy-related files to distinguish the currently active UI path from older or duplicated files.
+- Verified that the active panel (`panel/panel.js`) now requests release notes from the new backend route and reloads them when the selected install version changes.

.idea/modules.xml

@@ -0,0 +1,8 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<project version="4">
+  <component name="ProjectModuleManager">
+    <modules>
+      <module fileurl="file://$PROJECT_DIR$/.idea/Projects.iml" filepath="$PROJECT_DIR$/.idea/Projects.iml" />
+    </modules>
+  </component>
+</project>

.idea/start prompt.md

@@ -0,0 +1,119 @@
+## Bahmcloud Store Start Prompt
+
+You are working in the `Bahmcloud Store` repository.
+
+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.
+
+Working rules:
+- Never push, commit, tag, or create a release without explicit user approval.
+- Always document every change in `.idea/changes.md` with the current date and a detailed description of what changed, why it changed, and any verification done.
+- If a new release is created, update `CHANGELOG.md` with all relevant changes since the last released version.
+- Prefer changing the real active code paths, not legacy or duplicate files.
+- When docs and code disagree, trust the current code first, then update docs to match verified behavior.
+- Do not remove user changes or perform destructive git actions unless the user explicitly asks for them.
+
+Repository facts to keep in mind:
+- Main integration path: `custom_components/bahmcloud_store/`
+- Entry point: `__init__.py`
+- Main runtime/service layer: `core.py`
+- HTTP API layer: `views.py`
+- Provider detection and remote version/readme fetching: `providers.py`
+- Repo metadata loading (`bcs.yaml`, `hacs.yaml`, `hacs.json`): `metadata.py`
+- Persistent storage: `storage.py`
+- Update entities: `update.py`
+- Repairs restart flow: `repairs.py`
+- Frontend panel actually loaded by Home Assistant: `panel/panel.js`
+- Panel registration uses `/api/bahmcloud_store_static/panel.js?v=109`; if frontend assets change in a real release, bump the version query to break HA browser cache.
+
+Current architecture summary:
+- Setup is config-entry only. YAML configuration is intentionally unsupported and only logs a warning if present.
+- Only one integration instance is allowed.
+- The official store index URL is fixed in `const.py`:
+  `https://git.bahmcloud.de/bahmcloud/ha_store/raw/branch/main/store.yaml`
+- The store index format currently used by the active code is a YAML mapping with:
+  - `refresh_seconds`
+  - `repos`
+  - each repo entry contains at least `url`, optionally `name` and `category`
+- Refresh flow:
+  - integration initializes storage and caches
+  - after `homeassistant_started`, a delayed refresh runs
+  - periodic refresh also runs on an interval from the store index
+  - refresh merges official index repos, optional HACS repos, and user custom repos
+  - cached enrichment is applied first, installed repos are refreshed eagerly, and the rest are enriched in the background
+- Optional HACS support exists behind the `hacs_enabled` setting and currently loads the official HACS integration list from `data-v2.hacs.xyz`. That path is GitHub-only metadata, not a general provider abstraction.
+- Install/update flow:
+  - picks a ref from selected version, latest version, or default branch
+  - downloads a ZIP from the provider-specific archive endpoint
+  - extracts the repository
+  - finds `custom_components`
+  - installs every integration folder inside `custom_components/*` that contains `manifest.json`
+  - stores the installed ref and manifest version in HA storage
+  - creates backups before overwriting existing domains
+  - marks restart required through Repairs
+- Backup/restore behavior:
+  - backups live under `/config/.bcs_backups/<domain>/<timestamp>/`
+  - restore updates stored installed-version info so the UI and update entities reflect the restored state
+  - retention is currently 5 backups per domain
+- Installed-state reconciliation exists:
+  - if folders are deleted from `/config/custom_components`, stale installed entries are removed from storage
+  - BCS also tries to self-reconcile as installed when it was deployed externally
+
+Public/API contract to preserve unless intentionally changed:
+- `GET /api/bcs`
+- `POST /api/bcs?action=refresh`
+- `GET /api/bcs/settings`
+- `POST /api/bcs/settings`
+- `GET /api/bcs/readme?repo_id=...`
+- `GET /api/bcs/versions?repo_id=...`
+- `GET /api/bcs/repo?repo_id=...`
+- `POST /api/bcs/install?repo_id=...&version=...`
+- `POST /api/bcs/update?repo_id=...&version=...`
+- `POST /api/bcs/uninstall?repo_id=...`
+- `GET /api/bcs/backups?repo_id=...`
+- `POST /api/bcs/restore?repo_id=...&backup_id=...`
+- `POST /api/bcs/restart`
+- `DELETE /api/bcs/custom_repo?id=...`
+
+Storage model:
+- Home Assistant storage key: `bcs_store`
+- Stored sections:
+  - `custom_repos`
+  - `installed_repos`
+  - `settings`
+  - `hacs_cache`
+  - `repo_cache`
+
+Frontend/UI facts:
+- The active HA panel script is `custom_components/bahmcloud_store/panel/panel.js`.
+- The richer UI is implemented there: source filtering, HACS toggle, repo detail loading, version selection, backups restore modal, restart action, and history handling.
+- `panel/app.js`, `panel/index.html`, and `panel/styles.css` look like older standalone or legacy panel assets. Treat them as secondary unless you confirm they are still used for a real path.
+
+Code-analysis findings that should influence future work:
+- `store.py` represents an older store implementation with a different data model (`packages`, `source_path`, older API routes). It does not appear to be the active runtime path for the current integration flow.
+- `custom_repo_view.py` duplicates logic that already exists in `views.py` and looks legacy/unreferenced.
+- README files describe the project direction correctly at a high level, but some wording overstates provider generality. The actual code is provider-neutral in intent, but concretely implemented around GitHub, GitLab, and Gitea-style endpoints.
+- 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.
+
+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.
+- Preserve repo-cache and HACS-cache behavior unless intentionally redesigning refresh logic.
+- Preserve backup-before-overwrite safety for install/update/restore flows.
+- Preserve update-entity behavior for installed repos.
+- Keep the integration UI-admin-only and config-entry-based.
+
+Recommended workflow for future tasks:
+1. Read `README.md`, `README_DEVELOPER.md`, and relevant source files.
+2. Verify whether the requested change belongs in active code or in legacy files.
+3. Implement the change in the active runtime path.
+4. Update documentation if behavior changed.
+5. Append a detailed dated entry to `.idea/changes.md`.
+6. If and only if a release is being prepared with user approval, fold release-worthy changes into `CHANGELOG.md`.
+
+Current release baseline:
+- `manifest.json` version is `0.7.2`
+- Latest documented release in `CHANGELOG.md` is `0.7.2` dated `2026-01-20`

.idea/vcs.xml

@@ -0,0 +1,6 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<project version="4">
+  <component name="VcsDirectoryMappings">
+    <mapping directory="" vcs="Git" />
+  </component>
+</project>