48 lines
1.3 KiB
Markdown
48 lines
1.3 KiB
Markdown
# MinerOps v0.2: Repair Workflow
|
|
|
|
## Status
|
|
|
|
Planning document. The version label and remaining scope are provisional and do
|
|
not override the current version summary in `README.md` or phase ordering in
|
|
`docs/ROADMAP.md`.
|
|
|
|
## Goal
|
|
|
|
Deliver a complete, auditable repair lifecycle based on durable miner identity
|
|
and immutable history.
|
|
|
|
## Completed
|
|
|
|
- [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
|
|
|
|
- [ ] Repair Parts Tracking
|
|
|
|
These planned items refer to explicit workflows in the modular Repairs domain.
|
|
Existing legacy repair, maintenance, location, and parts-summary behavior does
|
|
not make these workflows complete.
|
|
|
|
## Definition of Done
|
|
|
|
- all planned tasks are implemented
|
|
- repair actions are atomic
|
|
- history is immutable
|
|
- actor and timestamps are authoritative
|
|
- critical invariants are enforced in PostgreSQL
|
|
- migration lifecycle tests pass
|
|
- repair and inventory regressions pass
|
|
- no generic repair CRUD is introduced
|
|
- operator behavior is documented
|
|
- the release candidate is built from a clean, reproducible repository state
|
|
|
|
## Remaining Task
|
|
|
|
1. `005-repair-parts-tracking.md`
|
|
|
|
This task is specified under `docs/tasks/`, but remains a planned workflow and
|
|
must not be treated as implemented.
|