# Ticket: DevOps QRSPI coordination framework

## Metadata
- Type: Ticket
- Status: Done
- Project: Nimrod / Homelab Operations
- Created: 2026-06-06
- Updated: 2026-06-06
- Priority: High

## Goal

Create a lightweight DevOps operating framework that applies QRSPI principles to infrastructure work, especially shared Proxmox operations performed by multiple agents.

## Why

Multiple agents creating VMs/LXCs in Proxmox can collide over VM IDs, IPs, DNS names, storage, network settings, credentials, backups, and service ownership. Infrastructure work needs stronger coordination than ordinary code-only work.

## Scope

Included:
- Define DevOps QRSPI phases and controls
- Add Proxmox mutation lock convention
- Add local Proxmox resource registry
- Define preflight and completion checklists
- Define how hybrid DevOps/software tasks are split and verified

Not included:
- Full Proxmox automation
- Dashboard implementation
- Ansible/update automation
- DNS/TLS automation

## Acceptance Criteria

This ticket is done when:
- [x] `docs/devops-qrspi-framework.md` exists and documents the operating model
- [x] `infra/proxmox-registry.yaml` exists as an initial registry scaffold
- [x] `state/locks/README.md` documents lock usage
- [x] A first Proxmox inventory pass populates known VMs/LXCs/IPs/resources — registry has all 6 services documented
- [x] Future VM/LXC creation uses the framework before mutation — enforced via AGENTS.md DevOps rules

## Questions

- What VMID ranges should be reserved for infrastructure, experiments, templates, and temporary agents?
- Which agent currently owns each active Proxmox task?
- Should locks be purely file-based, or later backed by a small service/API?

All ACs satisfied.

## Notes

- This ticket intentionally creates documentation/scaffolding first, without touching live Proxmox.