Thanks for improving SV Dashboard.
- Check the installation guide, entity catalog, and vehicle capability matrix.
- Confirm the issue also occurs with a supported version of Home Assistant and the upstream Stellantis Vehicles integration.
- Redact VINs, account IDs, exact home locations, GPS tracks, Notify recipient
names, tokens, and raw exports. Do not attach
.storagefiles. - Use Discussions for questions, early ideas, compatibility observations, and screenshots; reserve Issues for reproducible bugs and mature feature proposals.
See the community guide for the full reporting and discussion rules.
- Preserve the upstream boundary: this project consumes Home Assistant entities from Stellantis Vehicles and does not call the Stellantis API.
- Never hard-code a vehicle, VIN, entity ID, image URL, user, or notify target.
- New dashboard behaviour must handle unavailable or absent upstream entities.
- Add or update every user-facing string across all 18 supported languages in the same change, including config/options/entity text, frontend labels, notifications, push messages and Logbook text; see localisation.
- Keep third-party HACS cards as dependencies. Do not vendor or modify them.
- Use third-party product and brand names only where needed to describe compatibility or interoperability. Do not add manufacturer logos, official badges, brand artwork, promotional imagery, or other protected visual assets unless the applicable permission or licence is clearly documented. See TRADEMARKS.md.
Run the validation commands in AGENTS.md. Runtime acceptance uses
the designated Home Assistant instance and must deploy the exact candidate
develop SHA. Record that SHA and the result in the GitHub Issue. Test a newly
created config entry when onboarding/config-flow behavior changed and verify the
automatically created dashboard after frontend changes.
All implementation, documentation, tests and candidate version changes are
committed to develop. Do not develop or hotfix directly on main.
develop is the integration/acceptance branch. The designated Home Assistant
instance may intentionally run an exact develop commit for real-world
validation. main is the last accepted, publishable state.
After runtime acceptance and maintainer approval, main is moved forward to
the exact validated develop SHA using a fast-forward promotion. Do not
squash, rebase or cherry-pick the accepted change set during that promotion;
the stable commit must remain the same commit that was tested. Tags and GitHub
releases are created from that promoted main SHA.
At a healthy release boundary main and develop are identical. Between
releases, develop may be ahead of main; the two branches must not contain
independent lines of feature/fix commits. If they diverge, reconcile the
histories before the next release.
See Branch and deployment workflow for the complete contract.
Describe the user-visible change, the upstream entity/capability it relies on, and how it was tested. Update documentation whenever setup, an entity, a calculation, a notification, or a dependency changes.
Pull requests may be used for review of develop work, but the stable
promotion itself must preserve the exact accepted commit SHA. Do not create a
new squash/rebase commit merely to move validated code to main.