docs(roadmap): add platform/toolchain bullet, ref-int integration item, and Terminology section

Author: antonkri

docs/s_core_v_1/roadmap/pi1.rst

@@ -29,6 +29,8 @@ Focus: Requirements Engineering (PA2) + Architecture Design (PA3)
   is either completed or the finding is noted in the checklist with a tracked issue;
   each tracked issue must have the **team** set and the **milestone** set
 - All requirements relevant for v1.0 must be explicitly marked as such
+- The current state of every module — including its implementation — must be
+  integrated into the ``reference_integration`` repository
 - Implementation of functionality must be planned via tickets in the
   `main S-CORE GitHub project <https://github.com/orgs/eclipse-score/projects>`__ —
   each ticket must have the **team** set and the **milestone** set
@@ -99,6 +101,16 @@ Work Breakdown
   shall be tracked by tickets. Each ticket must be assigned to a milestone
   less than or equal to ``v1.0``, have the dedicated **team** attribute set,
   and have its **process area** set to ``pa4_impl``.
+- Define the set of **target platforms** that S-CORE officially supports
+  for v1.0. For every supported platform there shall be an **official
+  toolchain**, and the ``reference_integration`` repository shall provide
+  a dedicated CI/CD workflow that compiles every module against that
+  platform's toolchain. Every implementation module must be **buildable
+  with this toolchain**, and it is **strongly recommended** that each
+  module reuses the same toolchain definition locally instead of
+  maintaining its own. The supported platforms together with their
+  official toolchains shall be **properly documented** so that every
+  module owner can refer to a single authoritative source.
 - Create and fully complete the Module Verification Report for every
   module. All findings shall be documented as tickets assigned to a
   milestone less than or equal to ``v1.0``, with the corresponding

docs/s_core_v_1/roadmap/planning_approach.rst

@@ -79,3 +79,28 @@ example ``pa1_req_eng``, ``pa2_arch_design``, ``pa3_implementation``,
 only **by time** (milestone / release gate) but also **by function**
 (process area), which is what feeds the per-process-area views on the
 :doc:`Overall Status <overall_status>` page.
+
+Terminology
+-----------
+
+To keep the planning vocabulary unambiguous, the following terms are used
+consistently throughout this section:
+
+- **Version** — A *version* refers to a software product version in the
+  classical sense: a defined, released state of the S-CORE platform with a
+  fixed scope and quality (e.g. ``v0.5``, ``v1.0``). It is the unit that is
+  shipped to and consumed by users of the platform.
+- **Release / Milestone** — A *release* (also called *milestone*, mapped
+  one-to-one to a `GitHub milestone
+  <https://github.com/eclipse-score/score/milestones>`__) is a planning
+  checkpoint that we use to **track our work on the way to a version**.
+  Several releases / milestones (e.g. ``v0.8``, ``v0.9``, ``v0.10``)
+  typically lead up to a single version (``v1.0``).
+- **Release Gate** — A *release gate* is the set of deliverables that, by
+  the corresponding release / milestone, **must be done for sure** in order
+  to keep the path to the target version on track. The release gate
+  documents the **mandatory minimum**; it does **not** restrict the teams
+  to working only on the items listed there. Teams are free to work on
+  additional topics in parallel — the release gate simply makes explicit
+  what is non-negotiable for that milestone.
+