feat: add infrastructure change approval workflow to BASELINE-PROMPT

Agents must get explicit human approval before executing infrastructure
changes (network configs, host tuning, VM settings, DNS, switches).
Workflow: prepare → Redmine ticket → human review → execute → verify.
Read-only audits do not require approval.

💘 Generated with Crush

Assisted-by: Crush:glm-5.2

BASELINE-PROMPT.md

@@ -34,7 +34,28 @@
 - **Cross-referencing is mandatory.** Every Redmine ticket links to its Discourse doc; every Discourse doc links to its Redmine ticket(s); every commit references `[#NNN]`; every PR links to both Redmine and Discourse. Keep them in sync at all times.
 - **Code, docs, and tests must be kept in sync at all times.** When you change code, update the corresponding docs (Discourse) and tests in the same commit. Never leave them out of sync.
 
-## 4. Git workflow
+## 4. Infrastructure change approval workflow
+
+For infrastructure (operations) work, agents do NOT execute changes
+without explicit human approval. The workflow is:
+
+1. **Prepare:** Agent creates scripts, configs, and a plan. Documents
+   the exact changes, blast radius, and rollback procedure in a
+   Redmine ticket.
+2. **Review:** Human reviews and approves (or rejects) via Redmine.
+3. **Execute:** Agent applies the change ONLY after approval.
+4. **Verify:** Agent verifies the change worked and documents results
+   in Discourse.
+
+This applies to all production infrastructure: network configs, host
+tuning, VM settings, DNS records, switch configs, etc. Read-only
+audits and probes do NOT require approval — only changes that alter
+system behavior.
+
+Code projects (software development) follow normal git/PR workflow and
+do not require per-change Redmine approval.
+
+## 5. Git workflow
 
 - **Use the `tea` CLI for pull requests.**
 - **Work smart off master** generally. Branches on the workstation are encouraged for moving fast, exploring ideas, and avoiding stash churn.
@@ -42,13 +63,13 @@
 - Branching strategy is open to per-project discussion.
 - **Commits and PRs must cross-link** to Redmine tickets (`[#NNN]` in subject or body) and Discourse docs (in PR body).
 
-## 5. CI/CD — shift left, keep in lockstep
+## 6. CI/CD — shift left, keep in lockstep
 
 - Strong preference that the **local workstation can run the same CI/CD** that the hosted infrastructure runs. Maintain them in lockstep across all projects.
 - **The further left CI/CD runs, the better.** Catch it before push, before PR, before merge.
 - We have a mix of developers and agents, some inside the hosted security boundary, some on beefy workstations. CI/CD must work for all of them.
 
-## 6. Docker and Kubernetes for everything
+## 7. Docker and Kubernetes for everything
 
 - Use Docker and Kubernetes for everything — a cluster of 1 or 100 is the same. Don't presume scale. Containers are containers; k8s is k8s.
 - **All development work happens in containers** — custom, off-the-shelf, or a mix. `docker pull` freely without asking.
@@ -58,7 +79,7 @@
   - **One-off utility needed?** `docker pull` a pinned image and run it ephemerally. Do not install on the host.
   - **Broadly useful tool?** Create a Redmine ticket requesting the human add it via the system package manager. Do not install it yourself.
 
-## 7. Infrastructure-as-Code testing
+## 8. Infrastructure-as-Code testing
 
 - When working on IAC, test against the corresponding **`sectestbed-` VM**. These are snapshot-able to a known base state (Tailscale-joined, Beszel-registered, SSH keys in place). The base state evolves; the delta of tested code shrinks over time.
 - A new functional-area VM starts in that ultra-basic base state and has roles applied on top.
@@ -66,7 +87,7 @@
 - Compliance mitigations may need to flow through both `sectestbed-` and `preprod-` testing, in lockstep. Redmine Gantt and dependency-relationship modeling are heavily used here.
 - **Portability and reproducibility by anyone** — do not require AWX as a prerequisite (optional nice-to-have; not mandatory for bootstrap).
 
-## 8. STATUS.md — scratchpad, not system of record
+## 9. STATUS.md — scratchpad, not system of record
 
 - **STATUS.md is a durable, git-tracked scratchpad for token efficiency.** It is not the system of record (Redmine is).
 - The agent fully owns STATUS.md; the human only consumes it.
@@ -74,24 +95,24 @@
 - The harness todo tool is fine for tracking *current* work; STATUS.md is the durable cross-session record.
 - **STATUS.md has an Inbox section.** When the human tosses new work mid-task in another conversation turn, do NOT pivot. Log it in the Inbox. If it's materially different, spin up a Redmine ticket.
 
-## 9. Questions file — `questions-v(N).md`
+## 10. Questions file — `questions-v(N).md`
 
 - Capture questions in a git-tracked, versioned file: `questions-v1.md`, `questions-v2.md`, …
 - The human reviews and edits it inline. Version it when a round of answers goes in.
 - Synthesize resolved Q&A into Discourse (decisions/rationale) and Redmine (work items).
 
-## 10. Belt-and-suspenders protocol enforcement
+## 11. Belt-and-suspenders protocol enforcement
 
 - Enforce the rules in **two layers**: prose policy in `AGENTS.md` and mechanical enforcement in git `pre-commit` / `pre-push` hooks. Harness-specific hooks (e.g. Crush `PreToolUse`) are avoided — keep enforcement portable so it works under any agent framework.
 - Never rely on memory or prose alone.
 
-## 11. Gardening — keep docs from sprawling
+## 12. Gardening — keep docs from sprawling
 
 - Run a routine **gardening loop.** Agents are disciplined with code but tend to sprawl `.md` files everywhere.
 - Keep docs, code, and tests in sync at all times.
 - `scripts/garden.sh` reports `.md` sprawl and files that should be migrated to Discourse.
 
-## 12. Sub-agents as subcontractors
+## 13. Sub-agents as subcontractors
 
 The owner has a quota; the driving context is the expensive one. The biggest
 token cost is prefix mutation, not per-call work — so keep the driving prefix
@@ -105,7 +126,7 @@ stable and push volatility into side-channels (sub-agents, STATUS.md).
 
 This is scoped, contract-style work with a clear handback — not staff augmentation.
 
-## 13. TDD and linting
+## 14. TDD and linting
 
 - **Red/green TDD for all code.** Write the failing test first.
 - **Linters on all code, as early as possible.** Be token-efficient — let deterministic tools find the issues.