Story: Risk module extraction
Table of Contents
This page documents a story in Sprint 02. It captures the goal, current status, acceptance criteria, and the tasks that compose it.
Goal
The core module was named for what it was, not what it does.
Rename it to risk to reflect its actual responsibility and refactor
the internals so the module name is also a guide to its content.
This is the first explicit domain module; later sprints add more.
Status
| Field | Value |
|---|---|
| State | DONE |
| Parent sprint | Sprint 02 |
| Now | Story closed; core renamed to risk, dependencies updated, no references remain to the old name. |
| Waiting on | None. |
| Next | None. |
| Last touched | 2025-10-05 |
Acceptance
core→riskrename complete across CMake, source, headers, and documentation.- No references to
coreremain in the codebase. - The
riskmodule compiles and tests pass.
Tasks
| Task | State | Start | End | Description |
|---|---|---|---|---|
Rename core to risk |
DONE | 2025-10-01 | 2025-10-02 | Pure rename of the core module to risk — no semantic changes. |
Refactor core into risk |
DONE | 2025-10-03 | 2025-10-05 | Refactor the contents of the renamed risk module so the structure reflects the new name. |
Decisions
- Two tasks, not one
- a pure rename PR first, then a refactor PR on top. Keeps the rename diff reviewable (no semantic changes).
Out of scope
- Splitting risk further into subdomains (deferred).
- Renaming other modules (each gets its own story when motivated).
See also
- Add messaging for risk (this sprint) — first consumer of the renamed module across the comms boundary.