Add provisioning-request intake API for AI-driven client onboarding (!31) · Merge requests · Hop179 / Rax

Summary

Adds POST /api/v1/provision-requests: an AI assistant parses a client's Blesta ticket into structured fields (location, client identity, PTR, coarse OS choice, IXP interfaces/requests, extra hardware); Rax validates, records an internal ticket (browsable at /tickets), and best-effort emails dc.ops@hop179.net via Mailgun with a link back to the ticket.
New narrow Agent credential type (Bearer token, managed at /settings/agents) — can only ever call this one endpoint, never logs into the UI; kept orthogonal to the existing local-admin/OIDC "no role model".
Intake-only: no Proxmox writes; the only NetBox read validates shared ixp_interfaces against its ixp_interface-flagged VLANs. Actual provisioning — including resolving os.kind: "debian" to a real on-node ISO filename — is deferred to a follow-up MR.

go build ./..., go vet ./..., go test ./... all pass
Manual smoke test: booted the server, logged in as local-admin, created an agent via /settings/agents, called the API with its token — got a 200 + ticket id, ticket visible at /tickets/{id} with email_sent: not sent (Mailgun key was a dummy) and the "Provisioning plan: not yet implemented" placeholder
Verified 400 (bad location) and 401 (bad token) paths manually via curl
Operator: point a real MAILGUN_API_KEY at a sandbox domain and confirm the dc.ops email actually arrives with a working /tickets/{id} link

🤖 Generated with Claude Code

Edited Sep 17, 2026 by Aiho Tehisaru