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.

docs/releases/v0.3-operations.md

@@ -0,0 +1,38 @@
+# MinerOps v0.3: Operations
+
+## Status
+
+Planning document. The version label and candidate scope are provisional and do
+not override the current version summary in `README.md` or phase ordering in
+`docs/ROADMAP.md`.
+
+## Goal
+
+Add safe operational control for individual miners and groups while preserving
+guardrails and auditability.
+
+## Candidate Scope
+
+- [ ] Miner move workflow
+- [ ] Maintenance mode
+- [ ] Bulk tagging and location updates
+- [ ] Safe reboot and shutdown
+- [ ] Scheduled actions
+- [ ] Staggering and cooldown controls
+- [ ] Action history
+- [ ] Partial-failure reporting
+- [ ] Role-based action permissions
+
+This scope spans the roadmap's Operations and Fleet Control phases. Inventory,
+identity, maintenance context, and monitoring dependencies remain governed by
+`docs/ROADMAP.md`.
+
+The repository already contains early-stage legacy movement, command,
+scheduling, and action-status behavior. Unchecked items mean the modular,
+permissioned, fully validated product workflow remains planned; they do not
+claim that no related code exists.
+
+## Definition of Done
+
+Actions are explicit, permissioned, audited, safety-limited, recoverable, and
+tested for authorization, concurrency, retries, and partial failure.

docs/releases/v0.4-monitoring.md

@@ -0,0 +1,38 @@
+# MinerOps v0.4: Monitoring
+
+## Status
+
+Planning document. The version label and candidate scope are provisional and do
+not override the current version summary in `README.md` or phase ordering in
+`docs/ROADMAP.md`.
+
+## Goal
+
+Provide reliable current-state and historical visibility across the fleet.
+
+## Candidate Scope
+
+- [ ] Configurable discovery
+- [ ] MAC-based asset reconciliation
+- [ ] Miner status and telemetry
+- [ ] Historical retention
+- [ ] Fleet dashboard
+- [ ] Room, rack, model, and electrical summaries
+- [ ] Alert generation and lifecycle
+- [ ] Notification integrations
+
+Discovery and network reconciliation depend on the roadmap's Inventory &
+Identity phase, while electrical summaries depend on Infrastructure. Their
+presence here does not change those dependencies.
+
+The repository already contains early-stage discovery, telemetry, retention,
+dashboard, and infrastructure-summary foundations. Unchecked items describe
+work needed for a coherent, supported monitoring product rather than an absence
+of related implementation.
+
+## Definition of Done
+
+Observations remain distinct from authoritative inventory, stale data is
+explicit, discovery does not blindly create assets, retention is documented,
+alerts are auditable, and monitoring failures cannot corrupt inventory or
+repair history.

docs/releases/v1.0.md

@@ -0,0 +1,34 @@
+# MinerOps v1.0
+
+## Status
+
+Planning document. The version label is provisional. This file describes release criteria, not current
+capabilities or a delivery commitment. It does not override the current version
+summary in `README.md` or phase ordering and completion status in
+`docs/ROADMAP.md`.
+
+## Goal
+
+Deliver a production-ready, self-hosted operating platform for cryptocurrency
+mining operations.
+
+## Release Themes
+
+- durable inventory and identity
+- complete repair workflow
+- safe operational controls
+- monitoring and alerting
+- work orders and maintenance
+- spare parts and component history
+- electrical mapping
+- backup, restore, and migration
+- security, roles, and auditability
+- documented deployment and upgrades
+
+## Production Readiness
+
+v1.0 requires tested backup and restore, safe migrations, health checks,
+reproducible deployment, encrypted credential handling, HTTPS guidance,
+database-backed integrity, documented regression coverage for critical
+workflows, performance testing at representative fleet size, release notes, and
+documented limitations.