# Anti-Drift Guardrail – zlh-grind

This document exists to prevent "helpful" changes that cause operational drift.

---

## Purpose
Protect working pipelines by enforcing hard rules:
- Keep step visibility
- Preserve contracts
- Avoid unnecessary template churn
- Don't silently change wire formats

---

## Guardrails

### 1) Preserve provisioning step output
The step-by-step orchestration logs are required.
Do not remove, collapse, or reorder them casually.

### 2) Single-template is intentional
We use exactly one base template (`AGENT_TEMPLATE_VMID`).
The agent installs roles at runtime based on payload.

### 3) Template churn is expensive
In this workflow:
- Changing zlh-agent requires building + copying into the template container.
- That means "agent change" effectively becomes a template rev.

Therefore:
- Prefer API-side compatibility fixes unless we intentionally plan a template update.

### 4) Wire contract is explicit
Agent currently expects:
- `container_type` (snake_case) on JSON decode

Until the next intentional template rev:
- API must emit `container_type`
- Do not switch to `containerType` / `ctype` on the wire

---

## Allowed Changes Here
- Session logs
- Open threads
- Constraints / guardrails
- Upstream pointers

Not allowed:
- "Better architecture" rewrites
- Re-documenting canonical upstream specs