[rules score] add tool requirements and documentation for AoU forwarding

Tool requirements (TRLC):
- Add Forward_AoU_To_Dependees use case
- Add potential errors: AoU_Silently_Dropped, Invalid_Forwarding_YAML_Accepted
- Add tool requirements: Forward_Own_AoUs_To_Dependees,
  Chain_Forward_Received_AoUs, Reject_Unknown_AoU_In_Forwarding_YAML,
  Include_Forwarded_AoUs_In_Traceability

User documentation:
- Extend requirements.md with AoU Forwarding section explaining both
  automatic and chain-forwarding mechanisms
- Add aou_forwarding attribute to dependable_element in rule_reference.rst
- Add Forwarded AoUs to the dependable element concept in general.md

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

Author: castler

bazel/rules/rules_score/docs/requirements/potential_errors.trlc

@@ -97,4 +97,30 @@ section "Potential Errors" {
 
     }
 
+    section "AoU Forwarding" {
+
+        ToolQualification.PotentialError AoU_Silently_Dropped {
+            description = '''
+                An assumption of use defined by a dependency is not forwarded
+                to the dependee, causing the integrating project to be unaware
+                of a condition it must satisfy.
+            '''
+            impacts = ["Safety-relevant assumption not communicated to integrator"]
+            affects = [Forward_AoU_To_Dependees, Gate_Traceability_At_Test_Time]
+            impact_type = ToolQualification.Impact_Type.Safety
+        }
+
+        ToolQualification.PotentialError Invalid_Forwarding_YAML_Accepted {
+            description = '''
+                A chain-forwarding YAML file that references a non-existent
+                AoU identifier is accepted without error, causing the build to
+                succeed while the intended forwarding does not take effect.
+            '''
+            impacts = ["Chain-forwarded AoU missing from traceability report"]
+            affects = [Forward_AoU_To_Dependees]
+            impact_type = ToolQualification.Impact_Type.Safety
+        }
+
+    }
+
 }

bazel/rules/rules_score/docs/requirements/tool_requirements.trlc

@@ -123,4 +123,57 @@ section "Tool Requirements" {
 
     }
 
+    section "AoU Forwarding" {
+
+        ToolQualification.ToolRequirement Forward_Own_AoUs_To_Dependees {
+            description = '''
+                The dependable_element rule shall automatically include lobster
+                traceability entries for all assumptions of use defined by its
+                direct dependencies in the dependee's traceability report as
+                a "Forwarded AoUs" tier.
+            '''
+            mitigates = [AoU_Silently_Dropped]
+            derived_from = [Forward_AoU_To_Dependees]
+            satisfied_by = Tools.Bazel
+        }
+
+        ToolQualification.ToolRequirement Chain_Forward_Received_AoUs {
+            description = '''
+                The dependable_element rule shall support an aou_forwarding
+                attribute pointing to a YAML file that selects which received
+                AoUs are forwarded further to elements that depend on this
+                element. Each entry in the YAML shall require a mandatory
+                justification field.
+            '''
+            mitigates = [AoU_Silently_Dropped]
+            derived_from = [Forward_AoU_To_Dependees]
+            satisfied_by = Tools.Bazel
+        }
+
+        ToolQualification.ToolRequirement Reject_Unknown_AoU_In_Forwarding_YAML {
+            description = '''
+                The AoU forwarding tool shall exit with a non-zero return code
+                when the forwarding YAML references an AoU identifier that does
+                not exist in the set of received AoUs, preventing silent
+                misconfiguration.
+            '''
+            mitigates = [Invalid_Forwarding_YAML_Accepted]
+            derived_from = [Forward_AoU_To_Dependees]
+            satisfied_by = Tools.Bazel
+        }
+
+        ToolQualification.ToolRequirement Include_Forwarded_AoUs_In_Traceability {
+            description = '''
+                The lobster traceability report of a dependee shall include
+                forwarded AoUs as traceable items so that the existing
+                lobster-ci-report test fails when forwarded AoUs are not
+                handled (linked to a requirement, test, or justification).
+            '''
+            mitigates = [AoU_Silently_Dropped]
+            derived_from = [Forward_AoU_To_Dependees, Gate_Traceability_At_Test_Time]
+            satisfied_by = Tools.Lobster
+        }
+
+    }
+
 }

bazel/rules/rules_score/docs/requirements/use_cases.trlc

@@ -142,6 +142,17 @@ section "Use Cases" {
         affected_tools = [Tools.Docs, Tools.Bazel]
     }
 
+    ToolQualification.UseCase Forward_AoU_To_Dependees {
+        description = '''
+            As a system integrator I want assumptions of use defined by a
+            dependable element to be automatically forwarded to the elements
+            that depend on it so that the integrating project is made aware
+            of all conditions it must satisfy — including those originating
+            from transitive dependencies.
+        '''
+        affected_tools = [Tools.Bazel, Tools.Lobster]
+    }
+
     ToolQualification.UseCase Validate_Architecture_Specification_Documents {
         description = '''
             As a software architect I want the build to verify that architectural

bazel/rules/rules_score/docs/rule_reference.rst

@@ -625,6 +625,10 @@ and scope checks at build/test time.
      - label list
      - no
      - Other ``dependable_element`` targets for cross-referencing and HTML merging (default ``[]``)
+   * - ``aou_forwarding``
+     - label
+     - no
+     - A YAML file selecting which *received* AoUs to chain-forward to elements that depend on this one. Each entry requires an ``aou_id`` and a ``justification``. Own AoUs (from ``assumptions_of_use``) are always forwarded automatically.
    * - ``maturity``
      - string
      - no

bazel/rules/rules_score/docs/user_guide/general.md

@@ -26,6 +26,7 @@ A *dependable element* is the top-level unit of certification work. It bundles:
 | Assumed System Requirements | System-level requirements given as constraints from the surrounding context |
 | Feature Requirements | Functional and safety requirements for this element |
 | Assumptions of Use | Conditions the integrating project must satisfy |
+| Forwarded AoUs | Assumptions of use received from dependencies that must be handled or forwarded further |
 | Architectural Design | Software Architectural Design in PlantUML |
 | Software Units and Components | Implementation targets linked to their design |
 | Dependability Analysis | FMEA, FTA diagrams and control measures |
@@ -60,6 +61,7 @@ dependable_element(
     name = "safety_software_seooc_example",
     architectural_design = ["//bazel/rules/rules_score/examples/seooc/design:sample_seooc_design"],
     assumptions_of_use = [],
+    aou_forwarding = "aou_forwarding.yaml",  # chain-forward selected received AoUs
     components = [":component_example"],
     dependability_analysis = [":sample_dependability_analysis"],
     integrity_level = "B",

bazel/rules/rules_score/docs/user_guide/requirements.md

@@ -129,6 +129,59 @@ ScoreReq.AoU AOU_001 {
 }
 ```
 
+### AoU Forwarding
+
+When a dependable element depends on another via `deps`, all **assumptions of use** defined by the dependency are automatically forwarded to the dependee. This ensures the integrating project is made aware of every condition it must satisfy — even those originating from transitive dependencies.
+
+There are two forwarding mechanisms:
+
+**Automatic forwarding (own AoUs)**
+All AoUs declared in a dependable element's `assumptions_of_use` attribute are automatically forwarded to every element that lists it in `deps`. No configuration is needed.
+
+**Chain-forwarding (received AoUs)**
+When a dependable element receives forwarded AoUs from its own dependencies, it can selectively forward them further by providing an `aou_forwarding` YAML file. Each entry requires a mandatory justification explaining *why* this AoU is forwarded rather than handled locally:
+
+```yaml
+# aou_forwarding.yaml
+forwarded_aous:
+  - aou_id: "OtherLibrary.TimingConstraint"
+    justification: >
+      This timing constraint originates from the underlying library and
+      must be satisfied by the final system integrator who controls scheduling.
+```
+
+**Handling forwarded AoUs in the dependee**
+Forwarded AoUs appear as a "Forwarded AoUs" tier in the dependee's lobster traceability report. The dependee must handle each forwarded AoU by one of:
+
+- Linking it to a component requirement that addresses the assumption
+- Linking it to a test that verifies the assumption is met
+- Chain-forwarding it further (with justification) to its own dependees
+
+If a forwarded AoU is not handled, the `bazel test` traceability check will fail.
+
+**Example: three-level forwarding chain**
+
+```
+other_seooc              → defines AoU: TimingConstraint
+    ↑ (deps)
+middle_seooc             → auto-forwards TimingConstraint
+    - also chain-forwards it via aou_forwarding.yaml
+    ↑ (deps)
+integrator_seooc         → receives TimingConstraint, must handle it
+```
+
+```{code-block} starlark
+:caption: middle_seooc/BUILD
+
+dependable_element(
+    name = "middle_seooc",
+    assumptions_of_use = [":my_aous"],
+    aou_forwarding = "aou_forwarding.yaml",
+    deps = ["//other:other_seooc"],
+    ...
+)
+```
+
 ## Allocation of Requirements to Architectural Elements
 
 Requirements are allocated to architectural elements differently depending on their level: