From 27e45bb2575d19620f722592da7b616f9f4b243c Mon Sep 17 00:00:00 2001 From: bob Date: Fri, 10 Apr 2026 22:02:11 -0500 Subject: [PATCH] remove CLAUDE.md from cache as well --- CLAUDE.md | 35 ----------------------------------- 1 file changed, 35 deletions(-) delete mode 100644 CLAUDE.md diff --git a/CLAUDE.md b/CLAUDE.md deleted file mode 100644 index f6f485d..0000000 --- a/CLAUDE.md +++ /dev/null @@ -1,35 +0,0 @@ -# Project: ProxmoxInfra - -Terraform infrastructure-as-code for a homelab Proxmox environment. - -## Context - -This repo was started *after* the Proxmox server was already set up manually. -Existing infrastructure was provisioned by hand and must not be touched by -Terraform. Only new resources going forward are managed here. - -## Key rules for this project - -- **Never import or manage existing Proxmox resources** unless the junior - explicitly decides to and understands the risk of state drift. -- **Credentials never go in version control.** `.tfvars` files are gitignored. - Always use `terraform.tfvars.example` as the template pattern. -- **No resources in root module.** As the repo grows, push toward a - `environments/` layout with reusable modules under `modules/`. -- **State is not yet remote.** When a backend is introduced, make it a - deliberate decision with a knowledge transfer on why remote state matters - (locking, team access, DR). - -## Stack - -- Provider: `bpg/proxmox` (not the deprecated Telmate provider) -- Terraform >= 1.0 -- Target: single-node Proxmox VE homelab - -## Learning goals for this project - -- Understand Terraform's core workflow (init / plan / apply / destroy) -- Understand provider authentication and least-privilege API tokens -- Understand state — what it is, why it matters, what happens when it drifts -- Build intuition for when to use a VM vs an LXC container in Proxmox -- Learn to structure a Terraform repo that can scale without becoming a mess