tribunal-kit 2.4.6 → 3.1.0

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

@@ -1,98 +1,79 @@
 ---
 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.
+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: 1.0.0
-last-updated: 2026-03-12
+version: 2.0.0
+last-updated: 2026-04-02
 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
+# Incident Responder — Production Stabilization Mastery
 
 ---
 
-## 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
+## 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.
 
-## Core Architecture Decision Framework
+**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."
 
-### 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.
+## 2. Isolating Cascading Failures
 
-### 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.
+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.
 
-## Output Format
+```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
+  }
+}
 
-When this skill completes a task, structure your output as:
+// ✅ 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
+});
 
-```
-━━━ 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]
+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.
 
 ---
 
-## 🏛️ Tribunal Integration (Anti-Hallucination)
+## 3. The Investigative Triage Routine
 
-**Slash command: `/tribunal-backend`**
-**Active reviewers: `logic` · `security`**
+Once the bleeding is stopped (or if you are investigating a non-fatal anomaly), follow the data strictly:
 
-### ❌ 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.
+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.
 
-### ✅ 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?
-```
+## 4. The Blameless Post-Mortem
 
-### 🛑 Verification-Before-Completion (VBC) Protocol
+Incident response does not end when the system recovers. It ends when the system is architected to survive the same failure tomorrow automatically.
 
-**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.
+**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").
+
+---

package/.agent/skills/doc.md

@@ -1,6 +1,6 @@
 # Antigravity Skills
 
-> **Guide to creating and using Skills in the Antigravity Kit**
+**Guide to creating and using Skills in the Antigravity Kit**
 
 ---
 
@@ -16,9 +16,9 @@ While Antigravity's base models (like Gemini) are powerful generalists, they don
 
 Skills are folder-based packages. You can define these scopes based on your needs:
 
-| Scope         | Path                              | Description                          |
-| ------------- | --------------------------------- | ------------------------------------ |
-| **Workspace** | `<workspace-root>/.agent/skills/` | Available only in a specific project |
+|Scope|Path|Description|
+|-------------|---------------------------------|------------------------------------|
+|**Workspace**|`<workspace-root>/.agent/skills/`|Available only in a specific project|
 
 ### Skill Directory Structure
 
@@ -68,7 +68,7 @@ When reviewing code, follow these steps:
 - Suggest alternatives when possible
 ```
 
-> **Note**: The `SKILL.md` file contains metadata (name, description) at the top, followed by the instructions. The agent will only read the metadata and load the full instructions only when needed.
+**Note**: The `SKILL.md` file contains metadata (name, description) at the top, followed by the instructions. The agent will only read the metadata and load the full instructions only when needed.
 
 ### Try it out
 

package/.agent/skills/documentation-templates/SKILL.md

@@ -9,20 +9,17 @@ applies-to-model: gemini-2.5-pro, claude-3-7-sonnet
 
 # Documentation Standards
 
-> Documentation is a product. It has users. Those users are often future-you,
-> three months from now, having completely forgotten how this works.
-
 ---
 
 ## Documentation Types and Their Audiences
 
-| Type | Audience | Goal |
+|Type|Audience|Goal|
 |---|---|---|
-| README | New developer joining the project | "Get me running in 10 minutes" |
-| API docs | External integrator or frontend dev | "Tell me exactly what I can call and what I'll get back" |
-| Architecture decision (ADR) | Future engineer inheriting the codebase | "Tell me why it works this way, not just how" |
-| Code comment | Reviewer, maintainer | "Explain the non-obvious; skip the obvious" |
-| Runbook | On-call engineer at 2am | "Tell me what to do, not what to think about" |
+|README|New developer joining the project|"Get me running in 10 minutes"|
+|API docs|External integrator or frontend dev|"Tell me exactly what I can call and what I'll get back"|
+|Architecture decision (ADR)|Future engineer inheriting the codebase|"Tell me why it works this way, not just how"|
+|Code comment|Reviewer, maintainer|"Explain the non-obvious; skip the obvious"|
+|Runbook|On-call engineer at 2am|"Tell me what to do, not what to think about"|
 
 ---
 
@@ -31,13 +28,13 @@ applies-to-model: gemini-2.5-pro, claude-3-7-sonnet
 The Tribunal Agent Kit supports 5 standard Agent Design Kit (ADK) base patterns. 
 To build a skill using a robust, tested agent behavior model, add `pattern: [pattern-name]` to the YAML frontmatter of your `SKILL.md`.
 
-| Pattern | Value | When to use |
+|Pattern|Value|When to use|
 |---|---|---|
-| **Inversion** | `pattern: inversion` | Forces the agent to interview the user (Socratic Gate) before acting. |
-| **Reviewer** | `pattern: reviewer` | Evaluates artifacts against a checklist and severity levels. |
-| **Tool Wrapper** | `pattern: tool-wrapper` | Strictly executes external CLI tools via provided documentation without guessing. |
-| **Generator** | `pattern: generator` | Produces structured output (docs, boilerplate) by filling a rigid template. |
-| **Pipeline** | `pattern: pipeline` | Executes sequential tasks with strict halting gates between steps. |
+|**Inversion**|`pattern: inversion`|Forces the agent to interview the user (Socratic Gate) before acting.|
+|**Reviewer**|`pattern: reviewer`|Evaluates artifacts against a checklist and severity levels.|
+|**Tool Wrapper**|`pattern: tool-wrapper`|Strictly executes external CLI tools via provided documentation without guessing.|
+|**Generator**|`pattern: generator`|Produces structured output (docs, boilerplate) by filling a rigid template.|
+|**Pipeline**|`pattern: pipeline`|Executes sequential tasks with strict halting gates between steps.|
 
 *Templates defining the specific rules for these patterns live in `.agent/patterns/`.*
 
@@ -79,10 +76,10 @@ src/
 
 ## Environment Variables
 
-| Variable | Required | Description |
+|Variable|Required|Description|
 |---|---|---|
-| DATABASE_URL | Yes | PostgreSQL connection string |
-| JWT_SECRET | Yes | Secret for signing JWTs |
+|DATABASE_URL|Yes|PostgreSQL connection string|
+|JWT_SECRET|Yes|Secret for signing JWTs|
 
 ## Running Tests
 
@@ -118,11 +115,11 @@ Creates a new user account.
 
 **Responses**
 
-| Status | Meaning | Body |
+|Status|Meaning|Body|
 |---|---|---|
-| 201 | User created | `{ data: User }` |
-| 400 | Validation failed | `{ error: string, details: string[] }` |
-| 409 | Email already exists | `{ error: string }` |
+|201|User created|`{ data: User }`|
+|400|Validation failed|`{ error: string, details: string[] }`|
+|409|Email already exists|`{ error: string }`|
 
 **Example**
 \`\`\`bash
@@ -221,45 +218,4 @@ VBC status:  PENDING → VERIFIED
 Evidence:    [link to terminal output, test result, or file diff]
 ```
 
-
-
 ---
-
-## 🤖 LLM-Specific Traps
-
-AI coding assistants often fall into specific bad habits when dealing with this domain. These are strictly forbidden:
-
-1. **Over-engineering:** Proposing complex abstractions or distributed systems when a simpler approach suffices.
-2. **Hallucinated Libraries/Methods:** Using non-existent methods or packages. Always `// VERIFY` or check `package.json` / `requirements.txt`.
-3. **Skipping Edge Cases:** Writing the "happy path" and ignoring error handling, timeouts, or data validation.
-4. **Context Amnesia:** Forgetting the user's constraints and offering generic advice instead of tailored solutions.
-5. **Silent Degradation:** Catching and suppressing errors without logging or re-raising.
-
----
-
-## 🏛️ Tribunal Integration (Anti-Hallucination)
-
-**Slash command: `/review` or `/tribunal-full`**
-**Active reviewers: `logic-reviewer` · `security-auditor`**
-
-### ❌ Forbidden AI Tropes
-
-1. **Blind Assumptions:** Never make an assumption without documenting it clearly with `// VERIFY: [reason]`.
-2. **Silent Degradation:** Catching and suppressing errors without logging or handling.
-3. **Context Amnesia:** Forgetting the user's constraints and offering generic advice instead of tailored solutions.
-
-### ✅ Pre-Flight Self-Audit
-
-Review these questions before confirming output:
-```
-✅ Did I rely ONLY on real, verified tools and methods?
-✅ Is this solution appropriately scoped to the user's constraints?
-✅ Did I handle potential failure modes and edge cases?
-✅ Have I avoided generic boilerplate that doesn't add value?
-```
-
-### 🛑 Verification-Before-Completion (VBC) Protocol
-
-**CRITICAL:** You must follow a strict "evidence-based closeout" state machine.
-- ❌ **Forbidden:** Declaring a task complete because the output "looks correct."
-- ✅ **Required:** You are explicitly forbidden from finalizing any task without providing **concrete evidence** (terminal output, passing tests, compile success, or equivalent proof) that your output works as intended.

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

@@ -1,213 +1,123 @@
 ---
 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.
+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: 1.0.0
-last-updated: 2026-03-12
+version: 2.0.0
+last-updated: 2026-04-02
 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 Computing — Global Latency Mastery
 
 ---
 
-## 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.**
-
----
+## 1. The Edge Model (V8 Isolates vs Node.js)
 
-## Edge Runtime Constraints
+Edge functions (Cloudflare Workers, Vercel Edge) run on V8 Isolates, NOT standard Node.js environments.
 
-The edge runtime implements **Web Platform APIs**, not Node.js APIs. This causes the most hallucinations:
+**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`).
 
-```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
+```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
 
-// ✅ 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);
+// ✅ GOOD: Utilizing standard Web APIs (Fetch, CryptoKey)
+const hashBuffer = await crypto.subtle.digest('SHA-256', new TextEncoder().encode(password));
 ```
 
 ---
 
-## Cloudflare Workers Patterns
+## 2. Advanced Route Caching (Stale-While-Revalidate)
 
-### Basic Worker Structure
+The highest value proposition of the edge is intercepting requests *before* they cross the ocean.
 
-```ts
-// src/index.ts — Cloudflare Workers (Hono framework recommended)
-import { Hono } from 'hono';
+```typescript
+// Standard Edge Proxy request handling
+export default {
+  async fetch(request, env, ctx) {
+    const url = new URL(request.url);
 
-const app = new Hono<{ Bindings: Env }>();
+    // 1. Cache API responses at the edge
+    const cache = caches.default;
+    let response = await cache.match(request);
 
-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;
-```
+    if (!response) {
+      // 2. Fetch Origin (The real server in Virginia)
+      response = await fetch(request);
 
-### Durable Objects — Stateful Edge
+      // 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');
 
-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 });
+      // 4. Store in Cache asynchronously (do not block the user response)
+      ctx.waitUntil(cache.put(request, response.clone()));
     }
-    return new Response('Not a WebSocket', { status: 400 });
+
+    return response;
   }
-}
+};
 ```
 
 ---
 
-## Edge-Compatible Data Patterns
+## 3. Edge Data Locality (The Database Problem)
 
-The edge has no local disk. Data access must be network-based and ultra-low-latency:
+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.
 
-| 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) |
+### 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.
 
-```ts
-// ✅ Turso — SQLite at the edge via HTTP API
-import { createClient } from '@libsql/client/http';
+```typescript
+// ✅ Turso / LibSQL (Distributed Edge DB) usage:
+import { createClient } from "@libsql/client/web";
 
-const db = createClient({
+const client = createClient({
   url: env.TURSO_DATABASE_URL,
   authToken: env.TURSO_AUTH_TOKEN,
 });
 
-const { rows } = await db.execute('SELECT * FROM users WHERE id = ?', [userId]);
+const result = await client.execute("SELECT * FROM users WHERE id = ?", [userId]);
 ```
 
 ---
 
-## Cold Start Design
+## 4. WebSockets at the Edge (Durable Objects)
 
-The main advantage of edge (V8 isolates) is cold starts under 5ms vs Lambda's 100ms+. But you can still waste this advantage:
+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.
 
-```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
+```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 = [];
+  }
 
-// ✅ 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;
+  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 });
+  }
 }
 ```
 
 ---
-
-## 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?
-```