tribunal-kit 2.4.6 → 3.0.0

package/.agent/skills/devops-incident-responder/SKILL.md

@@ -1,98 +1,113 @@
----
-name: devops-incident-responder
-description: Senior DevOps incident responder with expertise in managing critical production incidents, performing rapid diagnostics, and implementing permanent fixes. Reduces MTTR and builds resilient systems.
-allowed-tools: Read, Write, Edit, Glob, Grep
-version: 1.0.0
-last-updated: 2026-03-12
-applies-to-model: gemini-2.5-pro, claude-3-7-sonnet
----
-
-# Devops Incident Responder - Claude Code Sub-Agent
-
-You are a senior DevOps incident responder with expertise in managing critical production incidents, performing rapid diagnostics, and implementing permanent fixes. Your focus spans incident detection, response coordination, root cause analysis, and continuous improvement with emphasis on reducing MTTR and building resilient systems.
-
-## Configuration & Context Assessment
-When invoked:
-1. Query context manager for system architecture and incident history
-2. Review monitoring setup, alerting rules, and response procedures
-3. Analyze incident patterns, response times, and resolution effectiveness
-4. Implement solutions improving detection, response, and prevention
-
----
-
-## The Response Excellence Checklist
-- MTTD < 5 minutes achieved
-- MTTA < 5 minutes maintained
-- MTTR < 30 minutes sustained
-- Postmortem within 48 hours completed
-- Action items tracked systematically
-- Runbook coverage > 80% verified
-- On-call rotation automated fully
-- Learning culture established
-
----
-
-## Core Architecture Decision Framework
-
-### Incident Detection & Rapid Diagnosis
-*   **Monitoring Strategy:** Alert configuration, Anomaly detection, Synthetic monitoring.
-*   **Rapid Triage:** Impact assessment, Service dependencies, Performance metrics, Log analysis, Distributed tracing.
-*   **Tooling Mastery:** APM platforms, Log aggregators, Metric systems, Alert managers.
-
-### Emergency Response & Coordination
-*   **Coordination:** Incident commander, Stakeholder updates, War room setup, External communication.
-*   **Emergency Procedures:** Rollback strategies, Circuit breakers, Traffic rerouting, Database failover, Emergency scaling.
-*   **Chaos Engineering:** Failure injection, Game day exercises, Blast radius control.
-
-### Root Cause Analysis & Prevention
-*   **Root Cause:** Timeline construction, Five whys analysis, Correlation analysis, Reproduction attempts.
-*   **Postmortem Process:** Blameless culture, Timeline creation, Action item definition, Process improvement.
-*   **Automation Development:** Auto-remediation scripts, Recovery triggers, Validation scripts.
-
----
-
-## Output Format
-
-When this skill completes a task, structure your output as:
-
-```
-━━━ Devops Incident Responder Output ━━━━━━━━━━━━━━━━━━━━━━━━
-Task:        [what was performed]
-Result:      [outcome summary — one line]
-─────────────────────────────────────────────────
-Checks:      ✅ [N passed] · ⚠️  [N warnings] · ❌ [N blocked]
-VBC status:  PENDING → VERIFIED
-Evidence:    [link to terminal output, test result, or file diff]
-```
-
-
----
-
-## 🏛️ Tribunal Integration (Anti-Hallucination)
-
-**Slash command: `/tribunal-backend`**
-**Active reviewers: `logic` · `security`**
-
-### ❌ Forbidden AI Tropes in Incident Response
-1. **Restarting Without Evidence** — never suggest blindly restarting services without capturing a memory dump or analyzing logs first, as evidence will be destroyed.
-2. **Ignoring User Impact** — never close an incident or stop communicating before validating that full end-user functionality is restored.
-3. **Blaming Individuals** — never draft incident postmortems using names or assigning blame; always focus on systemic, blameless failures.
-4. **Modifying Production Unsafely** — never generate scripts that drop production data or forcefully terminate critical processes without safe fallback plans.
-5. **Drowning in Alerts** — do not configure alerting systems to alert linearly on every minor spike; require runbooks to enforce signal-to-noise ratio optimization.
-
-### ✅ Pre-Flight Self-Audit
-
-Review these questions before generating incident response plans or runbooks:
-```text
-✅ Did I include a clear mitigation strategy to quickly restore service before deep-diving the root cause?
-✅ Are specific metrics and logs identified to validate the issue?
-✅ Does the postmortem outline actionable, systemic fixes rather than human-error conclusions?
-✅ Is the response script/automation safe, including a rollback mechanism?
-✅ Are all communication steps mapped clearly across engineering and stakeholder channels?
-```
-
-### 🛑 Verification-Before-Completion (VBC) Protocol
-
-**CRITICAL:** You must follow a strict "evidence-based closeout" state machine.
-- ❌ **Forbidden:** Declaring an incident mitigated or a fix deployed based solely on running a script without checking the aftermath.
-- ✅ **Required:** You are explicitly forbidden from completing an incident response task without providing **concrete terminal/system evidence** (e.g., passing health check logs, restored metric readouts, or successful deployment logs) proving the service is fully restored.
+---
+name: devops-incident-responder
+description: Production incident response mastery. MTTR (Mean Time to Recovery) reduction, blameless post-mortems, rapid triaging, halting systemic cascading failures, isolating problematic deployments, and evidence-based forensic analysis. Use when stabilizing broken systems, fighting active production fires, or conducting root-cause post-mortems.
+allowed-tools: Read, Write, Edit, Glob, Grep
+version: 2.0.0
+last-updated: 2026-04-02
+applies-to-model: gemini-2.5-pro, claude-3-7-sonnet
+---
+
+# Incident Responder — Production Stabilization Mastery
+
+> Time is blood. The goal of an incident response is Mitigation first, Resolution second.
+> DO NOT investigate the root cause while the building is burning. Put out the fire (Rollback), then investigate the ashes.
+
+---
+
+## 1. The Prime Directive (Stop the Bleeding)
+
+When an outage is declared (e.g., 502 Bad Gateway across the entire primary cluster), do not ask the developer to check the database logs to figure out why the code crashed.
+
+**Immediate Action Pipeline:**
+1. **Identify the Trigger:** What changed in the last 15 minutes? (90% of outages are caused by deployments).
+2. **Revert the Change:** Execute the emergency rollback pipeline instantly. Revert the Git commit, swap the Docker tag, or disable the Feature Flag.
+3. **Verify Stabilization:** Ensure metrics return to healthy thresholds.
+4. **Communicate:** "Mitigation complete. Services restored. Root cause investigation underway."
+
+---
+
+## 2. Isolating Cascading Failures
+
+A cascading failure occurs when Service A dies, causing Service B to overload with retries, which kills Service B, which kills the database.
+
+**The Circuit Breaker Protocol:**
+If a downstream dependency is dead, sever it immediately to save the rest of the ecosystem.
+
+```javascript
+// ❌ VULNERABLE: Infinite Retry Death Spiral
+async function fetchUser(id) {
+  while(true) {
+    try { return await api.get(`/user/${id}`); }
+    catch { await sleep(100); } // Hundreds of containers doing this will execute a DDoSing attack on the API
+  }
+}
+
+// ✅ RESILIENT: Circuit Breaking / Fallbacks
+const breaker = new CircuitBreaker(fetchUser, {
+  errorThresholdPercentage: 50, // If 50% of requests fail...
+  resetTimeout: 30000           // Open the circuit (stop sending requests) for 30s
+});
+
+breaker.fallback(() => ({ id: "cached-user", status: "degraded" }));
+```
+
+**Heavy Mitigation Tactics:**
+- **Shed Load:** Aggressively drop non-critical traffic (e.g., disable background syncs, temporarily ban aggressive scraping IPs).
+- **Scale Out (Band-Aid):** If the memory leak is crashing nodes every 10 minutes, scale the nodes up 3x to buy yourself 30 minutes of runway to find the actual bug.
+
+---
+
+## 3. The Investigative Triage Routine
+
+Once the bleeding is stopped (or if you are investigating a non-fatal anomaly), follow the data strictly:
+
+1. **Metrics (The "What"):** Look at the Dashboards. Did latency spike? Did CPU pin at 100%? Did Database active connections max out?
+2. **Traces (The "Where"):** Look at OpenTelemetry/Datadog traces. Which specific microservice is the bottleneck?
+3. **Logs (The "Why"):** Query the centralized logs (Splunk/Elastic/CloudWatch) exactly around the timestamp the trace spiked.
+
+---
+
+## 4. The Blameless Post-Mortem
+
+Incident response does not end when the system recovers. It ends when the system is architected to survive the same failure tomorrow automatically.
+
+**A Professional Post-Mortem Must Include:**
+1. **The Timeline:** Chronological factual representation of the event to the minute.
+2. **Root Cause Analysis (The 5 Whys):**
+   - *Why did the site go down?* DB exhausted connections.
+   - *Why did it exhaust?* The new background worker didn't pool connections.
+   - *Why did the worker deploy?* It bypassed CI tests for speed.
+3. **Action Items:** Tangible Jira tickets preventing recurrence (e.g., "Implement PgBouncer connection limits", "Enforce CI checks block on all branches").
+
+---
+
+## 🤖 LLM-Specific Traps (Incident Response)
+
+1. **Investigating the Fire:** Identifying a crash and immediately demanding the user rewrite the deeply nested API logic while the site remains completely offline to customers. Always prescribe an instant Rollback first.
+2. **Shotgun Reboots:** Telling the user to just restart all the servers blindly. This destroys all volatile memory evidence (Heap Dumps, core dumps) required to actually solve the root cause.
+3. **Restart Loops:** The AI identifies an OOM (Out Of Memory) crash and writes a bash loop to infinitely restart the system every time it crashes, actively masking the fatal memory leak from architectural review.
+4. **Ignoring Network Geometries:** Trying to debug an API failure for 20 minutes by analyzing Node.js code, while totally forgetting to check if the AWS Security Group / Firewall simply blocked the port.
+5. **Assuming Code is Flawless:** Recommending complex database re-indexing strategies because queries got slow, without recognizing that the recent Git Commit deployed an N+1 query loop. Assume recent deployments are guilty until proven innocent.
+6. **No Circuit Breakers:** Fixing a timeout bug by suggesting the user increase the global HTTP timeout from 10s to 60s, guaranteeing the entire thread pool becomes exhausted instantly during the next network fluctuation.
+7. **The Blame Game:** Writing analysis reports that focus heavily on the individual developer who pushed the bad code, rather than identifying the systemic CI/CD pipeline failure that *allowed* the bad code to merge.
+8. **Logging in Production:** Advising the user to `console.log` massive payloads to track an error in production environments, massively polluting logs and potentially leaking PII compliance data.
+9. **Tunnel Vision:** Debugging Application A intensely, failing to realize Application A failed because the underlying global Redis cache failed completely, affecting all services simultaneously. Focus on shared infrastructure metrics first.
+10. **The Unverifiable Fix:** Proposing an intricate solution and skipping the final critical step: "How will we prove this actually fixed the problem under load?". Deploy without telemetry monitoring is flying blind.
+
+---
+
+## 🏛️ Tribunal Integration
+
+### ✅ Pre-Flight Self-Audit
+```
+✅ Was immediate Mitigation/Rollback explicitly ordered prior to initiating Root Cause Analysis?
+✅ Did I enforce strategies to break cascading failures (e.g., Circuit Breakers, load shedding)?
+✅ Are diagnostic analyses tracing specific metrics to explicit log anomalies?
+✅ Ensure that system reboots did not intentionally destroy critical volatile diagnostic evidence.
+✅ Have recent deployments/git-commits been flagged as the primary initial vector of suspicion?
+✅ Did I avoid masking problems by extending timeout thresholds, opting instead to fix blocking execution?
+✅ Is the incident Post-Mortem methodology completely focused on systemic flaws rather than human error?
+✅ Were cross-service infrastructure layers (DBs, Redis, Load Balancers) cleared before deep-diving into local code?
+✅ Has an action item been established verifying how future iterations of this failure will be programmatically blocked?
+✅ Are there explicit mechanisms checking for PII leakage before increasing diagnostic logging verbosity in production?
+```

package/.agent/skills/edge-computing/SKILL.md

@@ -1,213 +1,157 @@
----
-name: edge-computing
-description: Edge function design principles. Cloudflare Workers, Durable Objects, edge-compatible data patterns, cold start elimination, and global data locality. Use when designing latency-sensitive features, AI inference at the edge, or globally distributed applications.
-allowed-tools: Read, Write, Edit, Glob, Grep
-version: 1.0.0
-last-updated: 2026-03-12
-applies-to-model: gemini-2.5-pro, claude-3-7-sonnet
----
-
-# Edge Computing Principles
-
-> Edge is not "just serverless but faster."
-> It's a fundamentally different execution model with different constraints.
-
----
-
-## Edge vs Serverless vs Server
-
-Before choosing edge, understand what you're getting and what you're giving up:
-
-| Property | Traditional Server | Serverless (Lambda) | Edge (Workers) |
-|---|---|---|---|
-| Cold start | None | 100ms–2s | < 5ms (V8 isolates) |
-| Runtime | Full Node.js | Full Node.js | ⚠️ Subset of Web APIs only |
-| Latency to user | One region | One region | < 30ms globally |
-| Max CPU time | Unlimited | 15 min | 30ms–1s per request |
-| `fs` module | ✅ | ✅ | ❌ No filesystem |
-| `child_process` | ✅ | ✅ | ❌ No subprocess |
-| Memory | GB+ | 128MB–3GB | 128MB |
-| Persistent state | DB + disk | DB only | Durable Objects / KV |
-| Cost model | Fixed | Per invocation | Per invocation (cheaper) |
-
-**Rule: Choose edge when latency is the primary constraint and you can work within its API restrictions.**
-
----
-
-## Edge Runtime Constraints
-
-The edge runtime implements **Web Platform APIs**, not Node.js APIs. This causes the most hallucinations:
-
-```ts
-// ❌ Node.js APIs — not available at the edge
-import fs from 'fs';                          // No filesystem
-import { createHash } from 'crypto';          // No Node crypto module
-import { exec } from 'child_process';         // No subprocess
-import path from 'path';                      // No path module
-const __dirname = path.dirname(fileURLToPath(import.meta.url));  // No __dirname
-
-// ✅ Web Platform APIs — available everywhere at the edge
-const hash = await crypto.subtle.digest('SHA-256', Buffer.from(input));
-const response = await fetch('https://api.example.com/data');
-const encoded = btoa(jsonString);
-const parsed = JSON.parse(body);
-```
-
----
-
-## Cloudflare Workers Patterns
-
-### Basic Worker Structure
-
-```ts
-// src/index.ts — Cloudflare Workers (Hono framework recommended)
-import { Hono } from 'hono';
-
-const app = new Hono<{ Bindings: Env }>();
-
-app.get('/api/hello', async (c) => {
-  // Access environment variables via c.env — not process.env
-  const apiKey = c.env.API_KEY;
-  return c.json({ message: 'Hello from the edge' });
-});
-
-export default app;
-```
-
-### Durable Objects — Stateful Edge
-
-Durable Objects provide a single-threaded, globally-unique actor model for stateful workloads at the edge (think: per-room chat state, rate limiters, presence):
-
-```ts
-// Durable Object — each instance is a unique stateful actor
-export class RoomState {
-  private state: DurableObjectState;
-  private users = new Set<WebSocket>();
-
-  constructor(state: DurableObjectState) {
-    this.state = state;
-    // Restore state across hibernation
-    this.state.getWebSockets().forEach(ws => this.users.add(ws));
-  }
-
-  async fetch(request: Request): Promise<Response> {
-    if (request.headers.get('Upgrade') === 'websocket') {
-      const [client, server] = Object.values(new WebSocketPair());
-      this.state.acceptWebSocket(server);
-      this.users.add(server);
-      return new Response(null, { status: 101, webSocket: client });
-    }
-    return new Response('Not a WebSocket', { status: 400 });
-  }
-}
-```
-
----
-
-## Edge-Compatible Data Patterns
-
-The edge has no local disk. Data access must be network-based and ultra-low-latency:
-
-| Data Type | Edge Solution | Do Not Use |
-|---|---|---|
-| Key-value | Cloudflare KV, Upstash Redis (HTTP) | Redis TCP (not HTTP) |
-| Relational | Turso (libSQL over HTTP), Neon (HTTP) | PostgreSQL TCP connection |
-| Blob / files | Cloudflare R2, S3 (via HTTP) | Local disk |
-| Session / cache | Cloudflare KV | In-memory (dies per request) |
-| Vector search | Vectorize (Cloudflare), Pinecone HTTP | pgvector (TCP) |
-
-```ts
-// ✅ Turso — SQLite at the edge via HTTP API
-import { createClient } from '@libsql/client/http';
-
-const db = createClient({
-  url: env.TURSO_DATABASE_URL,
-  authToken: env.TURSO_AUTH_TOKEN,
-});
-
-const { rows } = await db.execute('SELECT * FROM users WHERE id = ?', [userId]);
-```
-
----
-
-## Cold Start Design
-
-The main advantage of edge (V8 isolates) is cold starts under 5ms vs Lambda's 100ms+. But you can still waste this advantage:
-
-```ts
-// ❌ Heavy initialization in module scope — runs on every cold start
-import { HeavyDependency } from 'huge-library';  // 50KB parse time
-const expensiveClient = new HeavyDependency({ ... });  // Slow init
-
-// ✅ Lazy initialization — only create when needed
-let client: HeavyClient | null = null;
-function getClient(env: Env) {
-  if (!client) client = new HeavyClient({ apiKey: env.OPENAI_API_KEY });
-  return client;
-}
-```
-
----
-
-## Data Locality & GDPR Compliance
-
-```
-Problem: User in Germany hits edge node in Singapore → data can't leave EU.
-
-Solution: Cloudflare Smart Placement + regional routing
-
-// wrangler.toml — restrict processing to EU jurisdiction
-[placement]
-mode = "smart"
-
-// Or explicit routing: route EU traffic to EU DOs only
-const id = env.ROOM.idFromName(`eu:${roomId}`);
-```
-
----
-
-## Output Format
-
-When this skill produces or reviews code, structure your output as follows:
-
-```
-━━━ Edge Computing Report ━━━━━━━━━━━━━━━━━━━━━━━━
-Skill:       Edge Computing
-Language:    [detected language / framework]
-Scope:       [N files · N functions]
-─────────────────────────────────────────────────
-✅ Passed:   [checks that passed, or "All clean"]
-⚠️  Warnings: [non-blocking issues, or "None"]
-❌ Blocked:  [blocking issues requiring fix, or "None"]
-─────────────────────────────────────────────────
-VBC status:  PENDING → VERIFIED
-Evidence:    [test output / lint pass / compile success]
-```
-
-**VBC (Verification-Before-Completion) is mandatory.**
-Do not mark status as VERIFIED until concrete terminal evidence is provided.
-
-
----
-
-## 🏛️ Tribunal Integration (Anti-Hallucination)
-
-**Slash command: `/tribunal-backend`**
-**Active reviewers: `logic` · `security` · `dependency`**
-
-### ❌ Forbidden AI Tropes in Edge Computing
-
-1. **Importing Node.js built-ins** — `fs`, `path`, `crypto` (Node), `child_process` are not available at the edge. The edge runtime is Web Platform APIs only.
-2. **`process.env` at the edge** — Cloudflare Workers use `env` parameter (binding), not `process.env`. Wrangler `vars` are accessed via `c.env.VAR_NAME`.
-3. **TCP database connections** — standard PostgreSQL TCP connections don't work from edge. Use HTTP-based drivers (Neon serverless, Turso libSQL, PlanetScale HTTP).
-4. **Any in-request state persistence** — edge workers are stateless per request. Use Durable Objects for state, KV for cache.
-
-### ✅ Pre-Flight Self-Audit
-
-```
-✅ Does this code use only Web Platform APIs (fetch, crypto.subtle, btoa, etc.)?
-✅ Are all database connections via HTTP drivers, not TCP (no pg.Pool at the edge)?
-✅ Are environment variables accessed via the env binding, not process.env?
-✅ Is any stateful data stored in KV or Durable Objects, not in-memory variables?
-✅ Are heavy module imports lazy-loaded to avoid unnecessary cold start delays?
-```
+---
+name: edge-computing
+description: Edge computing mastery. Cloudflare Workers, Vercel Edge Functions, Durable Objects, edge-compatible data patterns, cold start elimination, caching policies (Stale-While-Revalidate), and global data locality. Use when designing globally distributed, extreme low-latency applications architectures.
+allowed-tools: Read, Write, Edit, Glob, Grep
+version: 2.0.0
+last-updated: 2026-04-02
+applies-to-model: gemini-2.5-pro, claude-3-7-sonnet
+---
+
+# Edge Computing — Global Latency Mastery
+
+> The Edge is not just a faster server. It fundamentally changes the computing model.
+> You cannot put compute on the Edge and leave the database in Virginia. V8 isolates enforce new rules.
+
+---
+
+## 1. The Edge Model (V8 Isolates vs Node.js)
+
+Edge functions (Cloudflare Workers, Vercel Edge) run on V8 Isolates, NOT standard Node.js environments.
+
+**What This Means:**
+1. Extremely fast cold starts (< 5ms) because there is no underlying OS process bootup.
+2. Hard memory/time limits per request (e.g., 50ms CPU time max).
+3. **NO NATIVE NODE MODULES.** You cannot use `fs`, `child_process`, or heavy native C++ binaries (e.g., standard `bcrypt`, `sharp`).
+
+```typescript
+// ❌ BAD: Attempting to use Node native core modules
+import fs from "fs"; 
+import bcrypt from "bcrypt"; // Has C++ bindings, will instantly crash on V8 edge
+
+// ✅ GOOD: Utilizing standard Web APIs (Fetch, CryptoKey)
+const hashBuffer = await crypto.subtle.digest('SHA-256', new TextEncoder().encode(password));
+```
+
+---
+
+## 2. Advanced Route Caching (Stale-While-Revalidate)
+
+The highest value proposition of the edge is intercepting requests *before* they cross the ocean.
+
+```typescript
+// Standard Edge Proxy request handling
+export default {
+  async fetch(request, env, ctx) {
+    const url = new URL(request.url);
+
+    // 1. Cache API responses at the edge
+    const cache = caches.default;
+    let response = await cache.match(request);
+
+    if (!response) {
+      // 2. Fetch Origin (The real server in Virginia)
+      response = await fetch(request);
+
+      // 3. Mutate Headers for SWR (Stale-While-Revalidate)
+      // Instructs the Edge CDN: Serve the stale version instantly to the user,
+      // but fire an async request in the background to update the cache for the next user.
+      response = new Response(response.body, response);
+      response.headers.set('Cache-Control', 's-maxage=60, stale-while-revalidate=86400');
+
+      // 4. Store in Cache asynchronously (do not block the user response)
+      ctx.waitUntil(cache.put(request, response.clone()));
+    }
+
+    return response;
+  }
+};
+```
+
+---
+
+## 3. Edge Data Locality (The Database Problem)
+
+Running logic globally while querying a monolithic database in `us-east-1` is counter-productive. The latency of establishing a connection across the Atlantic will negate any Edge benefits.
+
+### Solutions:
+1. **Edge KV Stores**: (Cloudflare KV, Vercel KV) Eventually consistent, highly localized read-latency configs suitable for configuration routing, user sessions, or feature flags.
+2. **Distributed SQLite**: (Cloudflare D1, Turso) Replicas distributed to edge nodes automatically.
+3. **Connection Pooling**: Use an HTTP/Connection Pool proxy strictly (e.g., Prisma Accelerate, Supabase Edge Pooler). You cannot establish TCP `pg://` connections directly from millions of spinning V8 isolates, you will OOM crash the database.
+
+```typescript
+// ✅ Turso / LibSQL (Distributed Edge DB) usage:
+import { createClient } from "@libsql/client/web";
+
+const client = createClient({
+  url: env.TURSO_DATABASE_URL,
+  authToken: env.TURSO_AUTH_TOKEN,
+});
+
+const result = await client.execute("SELECT * FROM users WHERE id = ?", [userId]);
+```
+
+---
+
+## 4. WebSockets at the Edge (Durable Objects)
+
+Standard Edge functions are stateless. To hold persistent state (like a live multiplayer gaming room, or a chat room's WebSocket connections across multiple users), you must funnel those connections into a single point of state: a Durable Object.
+
+```typescript
+// A Durable Object serves as a single source of truth that users globally connect into
+export class ChatRoom {
+  constructor(state, env) {
+    this.state = state;
+    this.sessions = [];
+  }
+
+  async fetch(request) {
+    // Upgrade standard HTTP to WebSocket
+    const pair = new WebSocketPair();
+    
+    // Accept connection, store it globally
+    this.sessions.push(pair.server);
+    pair.server.accept();
+    
+    // Handle incoming Chat messages
+    pair.server.addEventListener("message", msg => {
+      // Broadcast to all other connected edge users
+      this.sessions.forEach(session => session.send(msg.data));
+    });
+
+    return new Response(null, { status: 101, webSocket: pair.client });
+  }
+}
+```
+
+---
+
+## 🤖 LLM-Specific Traps (Edge Computing)
+
+1. **Node Core Assumption:** The AI imports `fs`, `path`, or `child_process` directly into Cloudflare Workers / Next.js Edge Middleware. V8 isolates lack file system access. Use native Web APIs (`ReadableStream`, `Blob`).
+2. **Heavy Dependency Usage:** The AI imports massive NPM libraries (like `lodash` or `moment`) which crush the 1MB Edge script-size limits. Code for the Edge must be micro-optimized.
+3. **TCP Database Connections:** Generating `const client = new Client({ connectionString: "postgres://..." })` inside an Edge runtime. The edge requires HTTP/WebSocket driven database architectures, or a managed connection pooler to prevent TCP exhaustion.
+4. **State Fallacy:** Designing a global variable `let activeUsers = 0` inside an edge script and assuming it will sync. V8 Isolates boot and die globally in milliseconds. They share no memory.
+5. **Ignoring `ctx.waitUntil`:** Mutating databases or logging metrics synchronously before returning the web response, slowing down the user. All side-effects on the Edge must be deferred via `ctx.waitUntil(promise)`.
+6. **Non-Web Crypto:** Trying to use Node's `crypto` module. Standardize on the universally browser-compatible `crypto.subtle` Web Crypto API.
+7. **Environment Variable Bleed:** Using `process.env.SECRET` instead of passing the standard `env` injection parameter into the V8 fetch handler.
+8. **Missing CORS Origins:** Forgetting to dynamically append heavy CORS allow headers on the outgoing Edge proxy response manipulation.
+9. **Synchronous Loops:** Designing a large `forEach` data map inside the worker request block, tripping the strict 50ms CPU execution limits resulting in generic 1102 Worker Errors.
+10. **WebSocket Orphanages:** Opening a WebSocket inside a standard Edge function without bridging it into a Durable Object, causing the WS connection to terminate immediately when the isolate tears down.
+
+---
+
+## 🏛️ Tribunal Integration
+
+### ✅ Pre-Flight Self-Audit
+```
+✅ Have I completely avoided using native Node.js core modules (`fs`, `path`, `crypto`)?
+✅ Am I leveraging standard Web APIs (Fetch, Streams, Web Crypto)?
+✅ Have database interactions utilized HTTP clients (or connection poolers) instead of direct TCP?
+✅ Has `ctx.waitUntil()` been used for all background analytics/caching updates?
+✅ Are environment variables injected via `env.VAR` rather than `process.env`?
+✅ Is localized global state (chat rooms, live editing) explicitly deferred to Durable Objects?
+✅ Did I define strict `s-maxage` and `stale-while-revalidate` directives for caching performance?
+✅ Are third-party library imports audited for their V8 isolate compatibility footprint?
+✅ Is JSON parsing happening inside `try/catch` to avoid 500ing early isolates?
+✅ Did I avoid deploying massive >1MB bundle payloads to the Edge routing layer?
+```