​

Change-Impact Workflow

​

What change-impact analysis does

1. Computes the file diff.
2. Maps changed files to the modules they implement.
3. For each module, looks up the requirements whose acceptance tests exercise that module.
4. Posts a Check Run summarising the impact.

✓ Roboticks · 12 requirements touched · 12/12 still confirmed

  REQ-014 Protective stop response time      ✓ tests passing
  REQ-021 Encoder reading sanity             ✓ tests passing
  REQ-032 Safe-state on power loss           ✓ tests passing
  REQ-041 PFL upper-arm quasi-static         ✓ tests passing
  …

✗ Roboticks · 12 requirements touched · 11/12 still confirmed · 1 regression

  REQ-014 Protective stop response time      ✓ tests passing
  REQ-021 Encoder reading sanity             ✗ test_encoder_response_under_100ms (was passing on main)
  …

​

Setup

change_impact:
  block_merge_on_regression: true
  block_merge_on_unexpected_impact: false
  notify_on_safety_impact: ["#safety-team"]
  triage_required_for_severity: ["safety"]

​

How modules map to requirements

1. Test execution coverage — when a test runs, Roboticks records which source files it loaded and executed. The requirements that test confirms are now known to depend on those files.
2. Explicit annotation — requirements can declare a realised_by list of module paths:
   - id: REQ-014
     realised_by:
       - src/safety/estop_controller.cpp
       - src/safety/estop_controller.hpp
       - src/drivers/motor_driver.cpp
   

​

Per-PR triage flow

​

Safety-impact escalation

• Slack message to a configured channel.
• Required reviewer added to the PR (e.g., the safety engineer).
• Block-on-regression for safety requirements specifically, even if other requirement types are non-blocking.

​

Integration into code review

​

Triage hygiene

• Keep requirement-to-module mappings up to date. When you move a file, update the realised_by. The execution-coverage backstop catches misses, but explicit annotation is faster.
• Acknowledge unexpected impacts promptly. A growing backlog of un-acknowledged impacts degrades the signal-to-noise.
• Don’t paper over regressions. Acknowledging a failing safety test as “acknowledged gap” should be a deliberate decision with sign-off, not a routine action.
• Use the LLM-suggested derivations and triages cautiously. Useful as a draft; the human is the authority.

​

Worked example

• Roboticks identifies 4 requirements whose realised_by or execution-coverage includes these files: REQ-014 (protective stop), REQ-021 (encoder sanity), REQ-032 (safe-state on power loss), REQ-041 (PFL upper-arm).
• Roboticks runs the 11 tests across the 4 requirements.
• REQ-021’s test_encoder_overflow_handling fails — the refactor moved overflow detection one stack frame deeper and lost a microsecond on the response time.
• Check Run reports the regression.
• PR author identifies the cause, restores the overflow handler in the original location, pushes again.
• Re-run: 11/11 pass. Check Run goes green. PR merges.

​

Next steps