docs: add development and release standards

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

@@ -0,0 +1,50 @@
+# 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
+
+## Planned
+
+- [ ] Return to Service
+- [ ] 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. `003-return-to-service.md`
+2. `004-control-board-replacement.md`
+3. `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.