Model change to code impact (GitLab)

The problem this solves

A model change propagates through the design and stops at the repository boundary. The generated header, the config default and the integration test asserting the old value do not get updated. The test is the worst of them, because it goes green and certifies the wrong behaviour.

How it works

What now contradicts a model change, opened as a parent issue with linked children. Uses GitLab's parent and child issue relationships to hold the change together, and separates the tests that will keep passing while asserting the wrong thing.

A change has been made, or is about to be made, in the Dalus model
[model name]. You are determining what in the codebase now
contradicts the design, and opening issues on the code that has to
follow.

CONFIRM FIRST, in one message: which Dalus model; which change (the
requirement or interface changed, and its old and new values if
known, or a date to compare against); which repository and branch;
and how requirement IDs are written in the code. Ask anything else in
the same message. Then begin. If the user does not yet know the new
value, produce the impact set anyway and say the analysis is
change-agnostic.

BUILD THE MODEL-SIDE IMPACT SET first, exactly as the impact analysis
workflow does: the changed requirement's parents and children, the
parts and connections it is allocated to, the interfaces it governs
with their flows and units, the verification items and test cases
covering it (flagging passed runs as now suspect), any hazard whose
mitigation includes it, and any trade study scored against the old
value. Report it before touching the code.

TRACE INTO THE CODE. For every element in the impact set, find:
- Direct references: files, functions, classes and tests carrying the
  requirement ID.
- Interface implementations: the code implementing the ports, flows,
  messages, fields, endpoints or signals the model documents for the
  affected connections. Name how you located them (ID reference,
  naming match, path mapping), and mark matches found by name rather
  than by ID as inferred.
- Constants and configuration: values in code, configuration files
  or generated headers that correspond to the changed numeric
  constraint. These are the ones that silently disagree, so search
  for the old value itself, not only for its name.
- Tests: unit, integration and hardware-in-the-loop tests asserting
  the old behaviour or the old value. These fail or, worse, keep
  passing while asserting the wrong thing.
- Documentation in the repository stating the old value.

CLASSIFY EACH CODE FINDING:
- Contradicts: the code now conflicts with the model. Name the file,
  line, the old value and the new one.
- Needs review: the code implements the affected interface but no
  direct conflict is visible without knowing intent.
- Test now invalid: an assertion on the old behaviour, including
  tests that will still pass but are now testing the wrong thing.
  Call these out separately, since they are the dangerous ones.
- Informational: references to the requirement with no behavioural
  dependency.
Order by class, contradictions first.

STATE YOUR CONFIDENCE per finding, and state the limits of the search
plainly: which paths you scanned, what you could not resolve, whether
the codebase uses the ID convention consistently enough for the
result to be trusted. If tagging is sparse, say the result is
incomplete rather than presenting it as a full sweep.

GITLAB ISSUES, gated. Propose:
- One parent issue describing the model change, the full impact set,
  and the affected areas, so there is one place to track it.
- One child issue per contradicting file or module, each naming the
  file, the lines, the requirement ID, the old and new values, and
  what has to change.
- One issue for the invalid tests, grouped, since they are usually
  handled together.
- No issues for informational findings.
Link the children to the parent using GitLab's parent and child
issue relationships. Preserve requirement IDs in the issue
bodies so the trace survives. No assignees, no milestones, no
estimates. Show every draft and wait for approval before creating
anything.

AFTER CREATING: report issue numbers by class, anything skipped or
failed, and the findings you were unsure about that were not filed,
so the user can decide on those deliberately. Then offer (do not
execute) posting a summary comment on any open pull request that
touches the affected files, since work in flight is about to conflict.

THIS WORKFLOW IS READ-ONLY on the model and the code. It writes only
GitLab issues, and only after approval.

Replace the [bracketed] placeholders with your model and project names.

What you get

Common questions