zlh-grind/ANTI_DRIFT.md

Anti-Drift Rules – ZLH Frontend

ZeroLagHub has historically suffered from "cool idea creep." This document exists to stop that from happening again.

Known Drift Patterns

• Adding visual effects to compensate for unfinished features
• Layering multiple aesthetic ideas (HUD + glow + 3D)
• Treating the UI as a showcase instead of a tool
• Reintroducing browser-only logic into shared utilities

Drift Prevention Rules

1. Subtraction First

If something feels off:

• Remove an effect
• Simplify a color
• Flatten a component

Never add effects to "balance" other effects.

2. One Idea Per Layer

At most:

• One accent color family
• One subtle animation
• One background texture

If more than one exists, drift has begun.

3. Control Plane Mental Model

Ask before merging:

"Would this feel appropriate in a production admin console at 2AM?"

If no, remove it.

4. Marketing ≠ Dashboard

• Marketing pages may be expressive.
• Dashboard and terminals must be calm and utilitarian.
• Product UI must never feel like a demo reel.

Drift Response

If drift is detected:

1. Revert the change
2. Document why it was tempting
3. Re-apply only what serves usability

Auth & Portal Drift Guardrails

The following are explicitly disallowed:

• Reintroducing APIv1 endpoints
• Reintroducing Pterodactyl-based auth
• CSRF token logic
• Cookie-based authentication
• Server-side portal sessions

All auth must flow: Portal → JWT → APIv2

Console Anti-Drift Rule

The interactive console MUST remain:

• PTY-backed
• Agent-owned
• WebSocket-based
• Full duplex (input + output)

🚫 Disallowed:

• Log tailing as "console"
• Exec-per-command models
• Frontend-owned processes
• Proxmox console passthrough

Any deviation requires explicit architectural review.