Requirements work

[a-zw]

No description provided.

[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: fbb24264-d082-42b3-ba12-44656c2089e7
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: 6.229s
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

[Copilot]

Pull request overview

This PR updates the project’s requirements/traceability documentation and metamodel annotations to improve linkage traceability for architecture elements.

Changes:

• Added a new tooling requirement (tool_req__arch_linkage_safety) documenting allowed/required architecture link relations.
• Annotated architecture link definitions in the SCORE metamodel with req-Id: tool_req__arch_linkage_safety for traceability.
• Expanded the :satisfies: list for the validity-attribute correctness tool requirement.

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated 3 comments.

File	Description
src/extensions/score_metamodel/metamodel.yaml	Adds req-Id annotations on architecture link definitions to tie them back to the new tooling requirement.
docs/internals/requirements/requirements.rst	Updates :satisfies: formatting and introduces a new tooling requirement section for architecture linkage safety.

[Copilot]

Pull request overview

Copilot reviewed 2 out of 2 changed files in this pull request and generated 3 comments.

[Copilot]

Pull request overview

Copilot reviewed 2 out of 2 changed files in this pull request and generated 3 comments.

[AlexanderLanin]

AI-assisted review (Claude):

Critical: 0 | Important: 2 | Suggestions: 1

Overall: two logically separate changes bundled in one PR — the satisfies hard-deprecation for feat_req/comp_req (commit 46cfe04) and the new tool_req__arch_linkage_safety requirement. The metamodel changes are clean and the traceability annotations look correct. The main concerns are a silent safety-check gap introduced by the graph_check change and a consistency issue in the requirement table itself.

The existing Copilot inline comments (on consist_of vs consists_of, included by vs included_by, grammar) are correct and should be addressed before merge.

[AlexanderLanin]

AI-assisted review (Claude):

Important — graph_check silently narrows safety enforcement

Removing satisfies: safety == QM from tool_req__docs_common_attr_safety_link_check is safe if and only if no feat_req/comp_req in any downstream repo still uses :satisfies: instead of :derived_from:. But issue #594 is still open, meaning the downstream migration may not be complete.

If a downstream repo has:

.. feat_req:: ...
   :safety: QM
   :satisfies: some_asil_gd_req

that repo will now pass the graph check silently — it used to be rejected by the satisfies: safety == QM clause.

Before this merges, either:

1. Confirm all downstream repos (score, module_template) have migrated to derived_from, then close Hard-deprecate :satisfies: for feat_req/comp_req after migration to :derived_from #594; or
2. Keep satisfies: safety == QM in the graph check until migration is confirmed complete.

The test added in test_options_extra_option.rst only verifies that satisfies is rejected as an extra option for feat_req in this repo's own metamodel tests — it doesn't cover the graph_check enforcement for downstream repos that still emit :satisfies:.

[AlexanderLanin]

AI-assisted review (Claude):

Important — requirement table row 1 documents a non-existent link

The row feat, consist_of, comp, yes, no says this link is mandatory but not yet implemented. However feat has no consists_of (or consist_of) in its optional_links or mandatory_links in metamodel.yaml — the link simply doesn't exist yet, not just unimplemented.

The warning below acknowledges the consist_of vs consists_of spelling discrepancy against gd_req__arch_linkage_safety, but the more fundamental issue is that this row documents a planned-but-absent link with no corresponding metamodel entry or req-Id annotation on feat.

Consider either:

1. Adding a # TODO comment under feat.optional_links annotated with req-Id: tool_req__arch_linkage_safety to make the gap traceable in the metamodel (even if the link target type is TBD), or
2. Noting explicitly in the table that this row is aspirational (documenting gd_req__arch_linkage_safety's intent, not the current implementation).

As written, a reader auditing feat's metamodel definition will find no evidence of this mandatory link.

[AlexanderLanin]

AI-assisted review (Claude):

Suggestion — add version to :satisfies: entries for valid_from/valid_until

The existing requirement tool_req__docs_req_attr_validity_correctness was already satisfying gd_req__req_validity[version==1]. The two new entries added here:

gd_req__req_attr_valid_from[version==1],
gd_req__req_attr_valid_until[version==1],

look correct. Just confirming the [version==1] pin is intentional here (locking to the current version of those GD reqs). If those GD reqs are expected to evolve this may need updating, but that's not unusual for this codebase.