Model change to code impact
The model moved. Somewhere in the repository a constant, an interface and a test still describe the old design. This finds them, separates the tests that will keep passing while asserting the wrong thing, and opens the issues.
GitHubWrites · gated
The problem this solves
A model change propagates through the design and stops at the repository boundary. The obvious code gets updated by whoever made the change; the generated header, the config default and the integration test asserting the old value do not. The test is the worst of them, because it goes green and certifies the wrong behaviour.
How it works
What in the codebase now contradicts a model change, opened as linked issues. Builds the model-side impact set, traces it into direct references, interface implementations, constants and tests, and separates out the tests that will keep passing while asserting the wrong thing.
01
Build the model side first
Parents and children, allocation, interfaces and their flows, verification items with passed runs flagged as suspect, hazards, and trade studies scored against the old value. Reported before any code is touched.
02
Trace into the repository
Direct ID references, the code implementing the affected interfaces, constants and configuration carrying the old value, tests asserting the old behaviour, and documentation in the repo stating it.
03
Classify, contradictions first
Contradicts, needs review, test now invalid, informational. Invalid tests are called out on their own, including the ones that will still pass.
04
State the limits, then file
Which paths were scanned, what could not be resolved, whether the ID convention is consistent enough to trust the sweep. Then a parent issue with linked children, shown in full before anything is created.
The prompt
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. GITHUB 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 children to the parent. 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 GitHub issues, and only after approval.
Replace the [bracketed] placeholders with your model and project names.
What you get
Model-side impact set, reported before the code search
Code findings classified, contradictions first, each with its confidence
Invalid tests grouped separately, including ones that still pass
A parent issue with linked children, gated on your approval
Dalus + GitHub
Searches for the old value itself, not only for the name of the constant, since that is what silently disagrees. Proposes a parent issue for the change with one child per contradicting file or module and one grouped issue for the invalid tests, links them, and preserves requirement IDs in the bodies so the trace survives. Nothing is created before you approve.
Nothing is written until you approve it. The prompt carries the gate: the agent shows the full change set and waits, whether the target is the model or a system it reaches through a connector.
Common questions
What if we do not know the new value yet?
It still runs. The impact set is change-agnostic in that case and says so, rather than implying it assessed a change it was not given.
Why are tests treated separately?
Because a test asserting the old value either fails, which you notice, or keeps passing while certifying behaviour the design no longer wants, which you do not. The second kind is why the class exists.
How much can it actually find?
That depends on how consistently your code carries requirement IDs, and the report says so. Matches found by naming rather than by ID are marked inferred, and if tagging is sparse the result is presented as incomplete rather than as a full sweep.