Add module inspection report aggregator with completeness check

[FScholPer]

📌 Description

Relates to #611

Adds an aggregator on top of mod_insp (from #661) that makes inspection completeness machine-checkable, grounded in the process concept (Review and Inspection Concept), which defines inspections over three checklist types: requirements / architecture / implementation.

Based on inspection_needs (#661) because it depends on the mod_insp need type, which is not yet on main. Retarget to main once #661 merges.

mod_insp is the atomic record (one per inspected work product). To prove that a module's report actually contains every inspection it is expected to have, we need an element that aggregates the records and a check that gates coverage. The existing config-driven graph_checks can only assert conditions on a linked need — they cannot express coverage/cardinality — so this adds a small Python @graph_check.

• metamodel.yaml: new mod_insp_report need type (prefix: mod_ispr__):
  • mandatory_options: safety/security/status + expected_inspections (comma-separated subset of requirements|architecture|implementation — the checklist categories the module must cover).
  • mandatory_links: belongs_to: mod, contains: mod_insp; optional evidence.
• checks/graph_checks.py: new check_inspection_report_completeness. For each mod_insp_report, a declared expected_inspections type counts as covered only if a contains-linked need is a mod_insp with inspection_state == approved and status == valid. Missing types produce a warning, e.g.:

  Inspection report is missing approved inspection(s) for: architecture
  

• requirements.rst: tool_req__docs_inspection_report_need.
• Tests: rst/options/test_options_inspection_report.rst (valid report + invalid expected_inspections), rst/graph/test_inspection_report.rst (incomplete → warns, complete → clean), and unit tests in test_graph_checks.py.

Design note (open for review): the completeness rule is intentionally the declared expected set (expected_inspections) vs. the contained approved records — deterministic and testable. Auto-deriving the expected set from the module's own work products (its comp_req/comp_arc/… needs) is a possible level-2 follow-up.

🚨 Impact Analysis

• This change does not violate any tool requirements and is covered by existing tool requirements
• This change does not violate any design decisions
• Otherwise I have created a ticket for new tool qualification

✅ Checklist

• Added/updated documentation for new or changed features
• Added/updated tests to cover the changes
• Followed project coding standards and guidelines

• Assisted by Copilot

Frank Scholter Peres frank.scholter_peres@mercedes-benz.com, Mercedes-Benz Tech Innovation GmbH
Provider Information

[github-actions]

License Check Results

🚀 The license check job ran with the Bazel command:

bazel run --lockfile_mode=error //src:license-check

Status: ⚠️ Needs Review

Click to expand output

[License Check Output]
Extracting Bazel installation...
Starting local Bazel server (8.6.0) and connecting to it...
INFO: Invocation ID: 6d3f63da-0bb8-40b2-8383-b13cba19ae90
Computing main repo mapping: 
Computing main repo mapping: 
Loading: 
Loading: 0 packages loaded
Loading: 0 packages loaded
Loading: 0 packages loaded
    currently loading: src
WARNING: Target pattern parsing failed.
ERROR: Skipping '//src:license-check': no such target '//src:license-check': target 'license-check' not declared in package 'src' defined by /home/runner/work/docs-as-code/docs-as-code/src/BUILD
ERROR: no such target '//src:license-check': target 'license-check' not declared in package 'src' defined by /home/runner/work/docs-as-code/docs-as-code/src/BUILD
INFO: Elapsed time: 5.759s
INFO: 0 processes.
ERROR: Build did NOT complete successfully
ERROR: Build failed. Not running target

[github-actions]

The created documentation from the pull request is available at: docu-html

[a-zw]

This PR is using an outdated method for file-based tests. See https://eclipse-score.github.io/docs-as-code/main/internals/extensions/rst_filebased_testing.html

[FScholPer]

yeah I will fix..

[aschemmel-tech]

See inline comments

[aschemmel-tech]

So you want to select which inspection types are needed because we may tailor this for some modules? So the template would have ":expected_inspections: requirements, architecture, implementation" pre-filled?

[aschemmel-tech]

evidence for what should this be?

[aschemmel-tech]

does this make sense to have? This would only cover completeness (for requirements) if you have only one component in the module, for architecture it is never complete because you have feature and component architecture inspections ... So rather you need to do this check with the knowledge of what documents (or even better workproduct) needs you created. Every inspected needs workproduct should have a "inspected" tag or status according to our process.