docs(roadmap): refine PI1 work breakdown for Release Gate v0.8

- Clarify automation checks are part of docs-as-code toolchain (//:docs)
- Add CI/CD workflow item for requirement/architecture validation
- Add inspection checklist completion item with team and process area
- Add Module Verification Report completion item (pa5_verification)
- Add outstanding implementation tickets item (pa4_impl)
- Replace 'component' attribute references with 'team'
- Remove Feasibility Check section

Author: antonkri

docs/s_core_v_1/roadmap/pi1.rst

@@ -23,15 +23,15 @@ Focus: Requirements Engineering (PA2) + Architecture Design (PA3)
 - Complete feature and component requirements for all modules (no open TBDs, status ``valid``)
 - Fill in and approve ``chklst_req_inspection.rst`` for all modules and features — each checklist point
   is either completed or the finding is noted in the checklist with a tracked issue;
-  each tracked issue must have the **component** set and the **milestone** set
+  each tracked issue must have the **team** set and the **milestone** set
 - Complete feature and component architecture for all modules (no open TBDs, status ``valid``)
 - Fill in and approve ``chklst_arc_inspection.rst`` for all modules and features — each checklist point
   is either completed or the finding is noted in the checklist with a tracked issue;
-  each tracked issue must have the **component** set and the **milestone** set
+  each tracked issue must have the **team** set and the **milestone** set
 - All requirements relevant for v1.0 must be explicitly marked as such
 - 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 **component** set and the **milestone** set
+  each ticket must have the **team** set and the **milestone** set
 - A Module Verification Report must be created for every module, tracking at minimum
   that unit-test coverage (C0/C1) reaches at least **90%** and dynamic code analysis
   (sanitizers: ASan/UBSan/LSan, TSan) passes with **0 findings**
@@ -45,38 +45,47 @@ See the relevant tables in :doc:`overall_status`:
 - :ref:`overall_status_pa3` — Architecture Design
 - :ref:`overall_status_pa5` — Verification / Coverage
 
-Feasibility Check
------------------
-
-Do we have everything in place to deliver the Release Gate v0.8 focus items?
-
-**Tooling & Process**
-
-- [ ] The S-CORE process templates (requirement, architecture, inspection checklists) are finalised and available
-- [ ] sphinx-needs / docs-as-code toolchain supports the required requirement types and attributes
-- [ ] CI pipeline enforces ``valid`` status and broken-link checks on requirements and architecture documents
-
-**Inputs & Dependencies**
-
-- [ ] Stakeholder requirements are stable enough to derive component requirements (no major scope changes expected)
-- [ ] Inter-module interfaces are sufficiently defined to allow architecture sign-off
-- [ ] External dependencies (e.g. AUTOSAR, SOME/IP specs) needed for requirements are accessible
-
-**Definition of Done clarity**
-
-- [ ] Acceptance criteria for "requirements complete" and "architecture complete" are agreed upon by all module owners
-- [ ] It is clear what "no open TBDs" means — a shared definition exists
-
-**Verification — how do we ensure it was done?**
-
-- [ ] Every module's ``chklst_req_inspection.rst`` and ``chklst_arc_inspection.rst`` are reviewed and merged into the module repo
-- [ ] The overall status tracker (``overall_status.rst``) reflects the current state for each module
-- [ ] All tracked findings from inspections have a linked GitHub issue with component + milestone set
-- [ ] A final Release Gate v0.8 review meeting confirms sign-off by module owners and process responsible
-
-**Integration in Reference Integration**
-
-- [ ] All modules with completed requirements and architecture are integrated in this reference integration repository
-- [ ] The reference integration build passes (no broken imports, no unresolved need IDs)
-- [ ] The documentation (this site) builds without warnings for all Release Gate v0.8 modules
-- [ ] The Release Gate v0.8 status table in ``overall_status.rst`` is updated to reflect the final state
+Work Breakdown
+--------------
+
+- Mark every **feature requirement** that is in scope for v1.0 with the
+  `valid_from <https://github.com/eclipse-score/docs-as-code/blob/main/src/extensions/score_metamodel/metamodel.yaml>`__
+  attribute, set to one of the predefined release versions: ``v0.5``,
+  ``v0.7``, ``v0.8``, ``v0.9``, ``v0.10`` or ``v1.0`` (semantics: see
+  `tool_req__docs_req_attr_validity_correctness
+  <https://github.com/eclipse-score/docs-as-code/blob/main/docs/internals/requirements/requirements.rst>`__).
+  Only feature requirements with ``valid_from`` set are considered relevant
+  for v1.0; together with **all elements linked to them** — component
+  requirements, AoUs, feature architecture and component architecture — they
+  form the v1.0 scope and are the only elements counted in the roadmap
+  statistics.
+- All in-scope feature requirements and the elements linked to them
+  (component requirements, AoUs, feature architecture, component architecture)
+  are in status ``valid``.
+- Implement all missing automation checks for requirement and architecture
+  elements as part of the docs-as-code toolchain used for generation of the
+  documentation (``//:docs``), as depicted in the *Process Status* pies on
+  :doc:`overall_status` (PA2 / PA3 *Req. verification status*)
+- Provide a standardized CI/CD workflow for all implementation modules to
+  validate requirements and architecture artifacts in compliance with the
+  S-CORE process. The workflow shall be executed in the
+  ``reference_integration`` repository to verify, across all integrated
+  modules, that the artifacts conform to the defined process and that the
+  resulting documentation can be successfully generated.
+- Create and fully complete the inspection checklists for requirements and
+  architecture. All findings shall be documented as tickets assigned to a
+  milestone less than or equal to ``v1.0``, with the corresponding
+  **team** attribute set and the **process area** set to ``pa2_req_eng``
+  (for requirement findings) or ``pa3_arch_design`` (for architecture
+  findings) respectively. Any alternative approach to the inspection
+  checklists must first be agreed upon with the process community, and the
+  decision must be documented.
+- All outstanding implementations of requirements relevant for ``v1.0``
+  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``.
+- 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
+  **team** attribute set and the **process area** set to
+  ``pa5_verification``.