# 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`)

## Planned

- [ ] Control Board Replacement
- [ ] 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

## Candidate Task Order

1. `004-control-board-replacement.md`
2. `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.