ESP-IDF CI / Host Tests (Unity) (push) Successful in 1m8s
CI / firmware-native (push) Successful in 2m57s
Rust Protection Tests / Cargo test (host) (push) Failing after 3m21s
ESP-IDF CI / ESP-IDF Build (v5.4) (push) Failing after 6m55s
ESP-IDF CI / Memory Budget Gate (push) Has been skipped
qa-cicd-environments / qa-kxkm-s3-build (push) Successful in 8m53s
qa-cicd-environments / qa-sim-host (push) Successful in 2m2s
qa-cicd-environments / qa-kxkm-s3-memory-budget (push) Successful in 11m17s
Context: the project archive (KXKM_Batterie_Parallelator-main) had no git history locally; a fresh repository is needed to host it on git.saillant.cc (electron/KXKM_Batterie_Parallelator). Approach: initialize a new repo on branch main, stage the archive content, and harden .gitignore before the first commit. Changes: - Import the full project tree: firmware/, firmware-idf/, firmware-rs/, iosApp/, kxkm-bmu-app/, kxkm-api/, hardware/, docs/, specs/, scripts/, models/, tests/ - Keep project dotfiles tracked despite the trailing '.*' ignore rule: .github/, .claude/, .superpowers/, .gitattributes, .markdownlint.json - Extend .gitignore: firmware/src/credentials.h (local secrets, template kept), kxkm-bmu-app/**/build/ (66 MB compiled iOS framework), .remember/ (session data) Impact: the project can now be maintained on the self-hosted Gitea forge with a clean, secret-free initial history.
38 lines
1.4 KiB
Markdown
38 lines
1.4 KiB
Markdown
# Data Contract Versioning Policy
|
|
|
|
Statut: draft v0.1
|
|
Scope: telemetry + inference schemas used by BMU edge and cloud analytics
|
|
|
|
## 1. SemVer rules
|
|
|
|
- Version format: `MAJOR.MINOR.PATCH`
|
|
- `MAJOR`: breaking schema change (field removed/renamed, type changed, semantic change)
|
|
- `MINOR`: backward-compatible addition (optional field, enum extension if explicitly tolerated)
|
|
- `PATCH`: non-structural fixes (description, examples, typo)
|
|
|
|
## 2. Compatibility policy
|
|
|
|
- Producers must always emit an explicit `schema_version` field.
|
|
- Consumers must reject unknown `MAJOR` versions.
|
|
- Consumers may accept higher `MINOR` versions only if unknown fields are optional and safely ignored.
|
|
- `PATCH` updates must not change runtime behavior.
|
|
|
|
## 3. Change control
|
|
|
|
For each schema update, include:
|
|
- Changelog entry with rationale and migration notes.
|
|
- Updated JSON schema files under `docs/data-contracts/`.
|
|
- Validation evidence from CI or local checks.
|
|
- Impact note on firmware, cloud ingestion, and dashboards.
|
|
|
|
## 4. Deprecation window
|
|
|
|
- Deprecated fields are announced in one `MINOR` release before removal.
|
|
- Removal is only allowed in the next `MAJOR` release.
|
|
- During deprecation window, both old and new fields may coexist.
|
|
|
|
## 5. Ownership
|
|
|
|
- Firmware lead validates edge compatibility.
|
|
- ML lead validates feature/inference contract compatibility.
|
|
- QA lead validates acceptance tests and evidence before release. |