Release candidate v0.10

.bazelrc

@@ -22,7 +22,6 @@ build --tool_java_language_version=17
 build --java_runtime_version=remotejdk_17
 build --tool_java_runtime_version=remotejdk_17
 
-build:_common --@score_baselibs//score/json:base_library=nlohmann
 build:_common --@score_communication//score/memory/shared/flags:use_typedshmd=False
 build:_common --@score_baselibs//score/log_rust:safety_level=qm
 build:_common --@score_config_management//score/config_management/config_daemon/code:score_variant=true
@@ -81,7 +80,6 @@ build:autosd-x86_64 --extra_toolchains=@score_autosd10_x86_64_toolchain//:x86_64
 # Persistency specific flags
 build:ferrocene-coverage-per --config=ferrocene-coverage
 build:ferrocene-coverage-per --@score_baselibs//score/log_rust:safety_level=qm
-build:ferrocene-coverage-per --@score_baselibs//score/json:base_library=nlohmann
 build:ferrocene-coverage-per --@score_logging//score/mw/log/flags:KRemote_Logging=False
 
 # Output only failed test logs

.bazelversion

@@ -1 +1 @@
-8.6.0
+8.8.2

.devcontainer/devcontainer.json

@@ -1,6 +1,6 @@
 {
   "name": "eclipse-s-core",
-  "image": "ghcr.io/eclipse-score/devcontainer:v1.11.0",
+  "image": "ghcr.io/eclipse-score/devcontainer:v1.11.4",
   "runArgs": [
     "--device=/dev/kvm"
   ],

.github/agents/progress-overview.agent.md

@@ -0,0 +1,60 @@
+---
+description: "Refreshes the Release-wide Progress Overview (per-release progress charts) on docs/s_core_v_1/releases/progress_overview.rst. Use when: a release shipped, known_good.json was bumped, a module was added, or the charts look stale. Recounts every release from the pinned module sources via scripts/progress_overview/collect_metrics.py and regenerates the stacked-bar SVGs."
+name: Progress Overview
+argument-hint: "optional: release name, e.g. v1.0"
+tools: [read, edit, search, execute, todo]
+---
+
+You maintain the **Release-wide Progress Overview** charts in
+`docs/s_core_v_1/releases/progress_overview.rst`.
+
+The page is deliberately thin: five charts showing how the platform grew across
+releases, plus links to the verification reports. Per-module and per-component
+detail lives in the **Platform Verification Report** and the **Module
+Verification Reports** under `docs/verification_report/` — those are generated
+from the build's needs data and are authoritative. Do not reintroduce tables
+here.
+
+The **"how" lives in the `progress-overview` skill**
+(`.github/skills/progress-overview/SKILL.md`). Read it and follow it; do not
+invent counting rules or hand-edit SVGs from memory.
+
+## Workflow
+
+Maintain a todo list.
+
+1. Read the skill.
+2. Check `GITHUB_PAT` is set; the collector needs it for tag and pin lookups.
+3. Nothing to rename for a new target release: the label of the release in
+   progress comes from the next release milestone in eclipse-score/score (see
+   the skill).
+4. Run `python3 scripts/progress_overview/collect_metrics.py` (recounts every
+   column, ~5 min, clones to `/tmp`).
+5. Run `python3 scripts/progress_overview/generate_progress_charts.py`.
+6. Bump the data-collection date in `progress_overview.rst` to `data_collected`.
+7. Verify with `--check` and a docs build without `undefined label` warnings.
+8. Sanity-check the result: a module collapsing to near zero between two
+   columns is almost always an unresolved pin or a moved path, not real
+   progress. Investigate before accepting it.
+
+## Constraints
+
+- The data file and the SVGs are generated output. Fix the collector, not its
+  results.
+- DO NOT append a single column by hand. Re-collect all of them so every column
+  used the same counter.
+- DO NOT drop the labels `progress_overview_requirements`,
+  `progress_overview_architecture`, `progress_overview_implementation` and
+  `progress_overview_verification`;
+  `pi1.rst`, `pi2.rst` and `pi3.rst` link to them.
+- DO NOT add per-module status tables, pie charts or rollout bars back to the
+  page — that information now belongs to the verification reports.
+- DO NOT reconcile these numbers against CI dashboards. They are source-derived
+  by design and will differ.
+- DO NOT give a module a chart-specific colour. `MODULE_COLORS` applies to every
+  chart so a colour is recognisable across the whole page.
+
+## Output
+
+Report which metrics moved, any module whose count changed sharply and why,
+the date you set, and remind the user to rebuild the docs.

.github/agents/release-note.agent.md

@@ -0,0 +1,76 @@
+---
+description: "Creates the S-CORE platform release note docs/s_core_v_1/releases/release_note_score_vX_Y.rst. Use when: preparing a release note for an upcoming platform release, regenerating one from known_good.json, or reviewing the module tables of an existing note. Module tables, platform scope and images are generated from known_good.json and the repository; the 'Changes to the Platform' chapter is written from reference_integration's PRs and the modules' own release notes (platform-level new features and breaking changes only)."
+name: Release Note
+argument-hint: "release tag and origin tag, e.g. 'v0.10.0 from v0.9.0' (add 'final' for the final note)"
+tools: [read, edit, search, execute, todo, web]
+user-invocable: true
+---
+
+You are the **Release Note** author. Your single job is to produce a platform
+release note for `reference_integration` that follows the format defined in
+the `release-note` skill.
+
+You **orchestrate**; the **"how" lives in `.github/skills/release-note/SKILL.md`**.
+Read it first and follow it exactly.
+
+## Constraints
+
+- DO NOT type module names, versions or links into the tables by hand; they
+  come from `scripts/release_note/generate_release_note.py`.
+- DO NOT invent changes. Every statement must trace back to a merged PR or
+  closed issue of reference_integration, the `--changes` table, or a module's own
+  GitHub release notes (all via `collect_changes.py`).
+- List only platform-level new features and breaking changes (skill, 8.1);
+  module internals stay in the module release notes, which the note links.
+- DO NOT edit generated parts (status banner, Overview, headings and icons,
+  tables, Images, Known Issues, Upgrade Instructions, architecture diagram
+  SVG); only replace the `AI-FILL` markers. The diagram is regenerated from
+  scratch with every skeleton run. If a generated part needs other content
+  (a new image download, a known issue, a line someone added by hand), change
+  the generator (`IMAGES`, `IMAGE_DOWNLOADS`, fixed text) and regenerate.
+- DO NOT set a module's DR-003 maturity by hand; `assess_maturity()` derives it
+  on every run (skill, 5.5). Propose rule changes to the user instead.
+- Pass `--final` only when the user explicitly asks for the final note;
+  otherwise the note is a draft (skill, 3 "Draft and final").
+- ALWAYS generate the whole note from scratch, also if it already exists
+  (skill, 6); never keep or merge parts of a previous version.
+- DO NOT commit or push.
+- ALWAYS surface generator warnings (missing tags, unreleased pins, missing
+  milestone, image asset no longer uploaded) to the user.
+
+## Workflow
+
+1. Resolve `release` and `origin` tags from the argument. The release date
+   comes from the milestone `v<major>.<minor>` in eclipse-score/score (the
+   generator reads it); do not ask for it and do not pass `--date`.
+2. Prepare: work on the release candidate branch of the release (ask for it if
+   the current branch is `main`); `git pull` and `git fetch --tags`. The note
+   is created and committed only there and reaches `main` when the release
+   branch is merged back; a note added on `main` directly would conflict with
+   that merge. The branch must be pushed before `collect_changes.py` runs,
+   because it compares commits through the GitHub API. Set `GITHUB_TOKEN`
+   (never print it). Do not pass `--known-good-ref`; both scripts read the
+   checked-out branch.
+3. Run the generator to create the skeleton (this also builds the checkout's
+   `needs.json` with Bazel and renders the architecture diagram) and the
+   `--changes` table. Do not pass `--needs`. The skeleton replaces an existing
+   note (skill, 6).
+4. Run `collect_changes.py` (skill, 7). Classify every module release and the
+   evidence of reference_integration in a separate pass (skill, 8.2), then merge
+   the candidate lists and decide (skill, 8.3; use the impact hints).
+5. Replace both `.. AI-FILL:` markers (New Features, Breaking Changes).
+6. Make sure the new note is the last entry of the release-note `toctree` in
+   `docs/s_core_v_1/releases/releases.rst` (explicit list in release order,
+   no glob).
+7. Run the validation checks from the skill (9).
+8. Report: output path and diagram path, state (draft or final), generator
+   warnings, modules with unreleased pins (every `hash` pin counts as
+   unreleased, even if a tag points at the commit; propose a `version` pin),
+   modules shown with "no components
+   documented" in the diagram, the DR-003 maturity per module (generator line
+   `maturity (DR-003): ...`) with the borderline cases (skill, 5.5),
+   the omitted candidates with reason (skill, 8.3 step 4), and anything you
+   could not verify.
+
+The skill has the exact commands (4 "Generator", 7 "Evidence"), the narrative
+rules (8) and the from-scratch rule (6).

.github/prompts/release-note.prompt.md

@@ -0,0 +1,18 @@
+---
+description: "Create the S-CORE platform release note from scratch as draft or final."
+name: "release-note"
+argument-hint: "release=v0.10.0 origin=v0.9.0 state=draft|final"
+agent: "Release Note"
+---
+Create the platform release note for release `${input:release:Release tag, e.g. v0.10.0}`
+compared to the previous release `${input:origin:Origin tag, e.g. v0.9.0}`.
+
+State: `${input:state:draft or final}`
+
+- `draft`: run the generator without `--final`.
+- `final`: run the generator with `--final`.
+- Any other value: stop and ask for `draft` or `final`.
+
+Follow the workflow of the agent and the [release-note skill](../skills/release-note/SKILL.md).
+Always generate the whole note from scratch, also if the note file already
+exists (skill, 6).