docs: replace with consolidated anti-drift policy (upload, console, auth, filesystem)

ANTI_DRIFT.md

@@ -1,63 +1,35 @@
-# Anti-Drift Rules – ZLH Frontend
+# Anti-Drift Policy
 
-ZeroLagHub has historically suffered from "cool idea creep."
-This document exists to stop that from happening again.
+The grind repo must reflect real implementation.
 
-## 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
+## Do NOT
 
-### 1. Subtraction First
-If something feels off:
-- Remove an effect
-- Simplify a color
-- Flatten a component
+- Document future features as complete
+- Leave outdated architecture notes in any doc
+- Allow staging/symlink model references to remain
+- Duplicate filesystem rules outside the agent
+- Add CORS to agents
+- Expose agent ports through Caddy
+- Reintroduce APIv1 endpoints
+- Reintroduce Pterodactyl-based auth
+- Use cookie-based authentication
+- Use server-side portal sessions
 
-Never add effects to "balance" other effects.
+---
 
-### 2. One Idea Per Layer
-At most:
-- One accent color family
-- One subtle animation
-- One background texture
+## When Architecture Changes
 
-If more than one exists, drift has begun.
+1. Update `README.md`
+2. Update `CONSTRAINTS.md`
+3. Update the relevant architecture doc under `docs/architecture/`
+4. Update `SESSION_LOG.md`
+5. Close thread in `OPEN_THREADS.md` if resolved
 
-### 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
+## Console Anti-Drift
 
 The interactive console **MUST** remain:
 
@@ -66,10 +38,45 @@ The interactive console **MUST** remain:
 - WebSocket-based
 - Full duplex (input + output)
 
-🚫 Disallowed:
+Disallowed:
 - Log tailing as "console"
 - Exec-per-command models
 - Frontend-owned processes
 - Proxmox console passthrough
 
-Any deviation requires explicit architectural review.
+---
+
+## Upload Anti-Drift
+
+The upload pipeline **MUST** remain:
+
+- Streamed via raw `http.request` piping in the API
+- Direct runtime write in the agent (no staging, no symlinks)
+- Enforced by agent allowlist only (portal does not enforce security)
+
+Disallowed:
+- `fetch()` for upload proxy
+- Staging folders
+- Symlink-based deployment
+- API re-implementing agent filesystem policy
+
+---
+
+## Auth Anti-Drift
+
+All auth must flow: `Portal → JWT → API`
+
+Disallowed:
+- CSRF token logic
+- Cookie-based authentication
+- APIv1 patterns
+- Pterodactyl auth patterns
+
+---
+
+## Drift Response
+
+If drift is detected:
+1. Revert the change
+2. Document why it was tempting
+3. Re-apply only what serves usability and real architecture