tribunal-kit 3.0.0 → 3.1.0

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

@@ -1,113 +1,79 @@
----
-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?
-```
+---
+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
+
+---
+
+## 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").
+
+---

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,157 +1,123 @@
----
-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?
-```
+---
+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
+
+---
+
+## 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 });
+  }
+}
+```
+
+---