zlh-grind/ANTI_DRIFT_GUARDRAIL.md

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