feat: add control board replacement workflow

docs/ROADMAP.md

@@ -99,11 +99,12 @@ durable asset record. Repairs, maintenance, work orders, parts usage, equipment
 movement, testing, and return-to-service history become coherent operational
 records rather than disconnected actions.
 
-The Begin Repair, read-only Repair Timeline, and Return to Service workflows are
-complete. An authorized actor can open a repair against a durable miner UUID,
-record sequenced events, and move the miner into or out of repair atomically.
-Authorized readers can inspect the repair and its ordered immutable events.
-Later repair lifecycle workflows remain planned.
+The Begin Repair, read-only Repair Timeline, Return to Service, and Control Board
+Replacement workflows are complete. An authorized actor can open a repair
+against a durable miner UUID, record sequenced events, move the miner into or out
+of repair atomically, and replace a control board without changing the durable
+asset identity. Authorized readers can inspect the repair and its ordered
+immutable events. Later repair lifecycle workflows remain planned.
 
 Technician experience is a priority. Responsive and QR-assisted workflows may
 reduce lookup and data-entry effort where they reinforce the same asset record.

docs/releases/v0.2-repair-workflow.md

@@ -16,10 +16,10 @@ and immutable history.
 - [x] Begin Repair (`POST /api/repairs`)
 - [x] Repair detail and timeline read APIs
 - [x] Return to Service (`POST /api/repairs/{repair_id}/complete`)
+- [x] Control Board Replacement
 
 ## Planned
 
-- [ ] Control Board Replacement
 - [ ] Repair Parts Tracking
 
 These planned items refer to explicit workflows in the modular Repairs domain.
@@ -39,11 +39,9 @@ not make these workflows complete.
 - operator behavior is documented
 - the release candidate is built from a clean, reproducible repository state
 
-## Candidate Task Order
+## Remaining Task
 
-1. `004-control-board-replacement.md`
-2. `005-repair-parts-tracking.md`
+1. `005-repair-parts-tracking.md`
 
-These are proposed future files under `docs/tasks/`. They do not exist yet and
-must not be treated as approved specifications until they are created and
-reviewed.
+This task is specified under `docs/tasks/`, but remains a planned workflow and
+must not be treated as implemented.