Replace ANTI_DRIFT_GUARDRAIL.md with frontend-specific guardrails for AI agents - control surface mentality, terminal isolation
This commit is contained in:
parent
a5dd707144
commit
6179812519
@ -1,52 +1,25 @@
|
|||||||
# Anti-Drift Guardrail – zlh-grind
|
# ZLH Frontend Guardrails
|
||||||
|
|
||||||
This document exists to prevent "helpful" changes that cause operational drift.
|
This file is intended for Codex / AI agents and human contributors.
|
||||||
|
|
||||||
---
|
## Primary Objective
|
||||||
|
ZeroLagHub's frontend is a **control surface**, not a game UI.
|
||||||
## Purpose
|
|
||||||
Protect working pipelines by enforcing hard rules:
|
|
||||||
- Keep step visibility
|
|
||||||
- Preserve contracts
|
|
||||||
- Avoid unnecessary template churn
|
|
||||||
- Don't silently change wire formats
|
|
||||||
|
|
||||||
---
|
|
||||||
|
|
||||||
## Guardrails
|
## Guardrails
|
||||||
|
- Prefer boring, predictable UI over clever abstractions
|
||||||
|
- Do not introduce new visual metaphors without removing an old one
|
||||||
|
- No "sci-fi" effects unless strictly informational
|
||||||
|
- Avoid abstractions that hide client/server boundaries
|
||||||
|
|
||||||
### 1) Preserve provisioning step output
|
## Terminal & Realtime UI Rules
|
||||||
The step-by-step orchestration logs are required.
|
- Terminal components must be isolated and client-only
|
||||||
Do not remove, collapse, or reorder them casually.
|
- No terminal logic in shared utilities
|
||||||
|
- No implicit socket initialization at import time
|
||||||
|
|
||||||
### 2) Single-template is intentional
|
## When Unsure
|
||||||
We use exactly one base template (`AGENT_TEMPLATE_VMID`).
|
Default to:
|
||||||
The agent installs roles at runtime based on payload.
|
- Removing code
|
||||||
|
- Leaving a comment
|
||||||
|
- Asking for review
|
||||||
|
|
||||||
### 3) Template churn is expensive
|
Silence is better than instability.
|
||||||
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
|
|
||||||
|
|||||||
Loading…
Reference in New Issue
Block a user