tribunal-kit 9.2.4 → 9.2.6

package/skills/edge-computing/SKILL.md

@@ -1,8 +1,8 @@
 ---
 name: edge-computing
-description: "Use when 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."
-version: 5.0.0
-last-updated: 2026-09-13
+description: "Use when designing, implementing, auditing, and hardening edge computing server logic, APIs, background jobs, and error boundaries."
+version: 6.0.0
+last-updated: 2026-09-29
 skills:
   - nextjs-react-expert
   - local-first-architecture
@@ -15,129 +15,187 @@ scripts-binding:
 
 # Edge Computing — Global Latency Mastery
 
----
-
-## 🛠️ Technical Architecture & Reference Recipes
-
----
-
-## Hallucination Traps (Read First)
-
-- ❌ Importing Node.js-only APIs (fs, net, child_process) in edge functions -> ✅ Edge runtime has NO Node.js APIs; use Web APIs only
-- ❌ Using `global` or module-level mutable state in edge -> ✅ Edge functions are stateless across requests; use KV/Durable Objects for state
-- ❌ Assuming edge functions have unlimited execution time -> ✅ Cloudflare Workers: 30s, Vercel Edge: 25s; design for millisecond responses
-
----
+## Mandatory Pre-Flight Context Inspection
+Before reading, generating, or refactoring code in the `edge-computing` domain, inspect these 5 critical parameters:
+1. **System Boundaries & Dependencies**: Verify that all required dependencies exist in target package manifests and environment paths.
+2. **Runtime Context & Platform Invariants**: Confirm target platform constraints (Node.js, Browser, Mobile OS, Edge runtime) before applying APIs.
+3. **Execution Guardrails**: Identify potential side-effects, state mutations, and unhandled asynchronous exceptions.
+4. **Validation & Type Contracts**: Validate input data schemas and strict type constraints across all module interfaces.
+5. **Observability & Proof of Execution**: Ensure execution produces tangible verification signals (terminal output, tests, metrics).
 
----
 
-## 1. The Edge Model (V8 Isolates vs Node.js)
+## Activation Boundaries
+- **Activate when:** Use when designing, implementing, auditing, and hardening edge computing server logic, APIs, background jobs, and error boundaries.
+- **DO NOT activate when:** The task falls outside the `edge-computing` domain or is managed by a different dedicated specialist agent.
 
-Edge functions (Cloudflare Workers, Vercel Edge) run on V8 Isolates, NOT standard Node.js environments.
 
-**What This Means:**
+## 🔁 Multi-Pass Execution Protocol
 
-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`).
+| Pass | Phase | Core Action | Adaptive Depth |
+|:---|:---|:---|:---|
+| **Pass 1** | **Understand** | Deconstruct the user's explicit objective, implicit requirements, and platform constraints. | Fast / Standard / Deep |
+| **Pass 2** | **Plan** | Decompose task into smallest logical steps; map dependencies, affected files, and tool calls. | Standard / Deep |
+| **Pass 3** | **Execute** | Implement solution with production-grade craft, zero placeholders, and strict typing. | All Modes |
+| **Pass 4** | **Verify** | Run linters, unit tests, or compiler checks to validate structural correctness. | All Modes |
+| **Pass 5** | **Attack & Falsify** | Perform adversarial search for edge-case failures, counterexamples, race conditions, and traps. | Standard / Deep |
+| **Pass 6** | **Harden** | Eliminate discovered friction, optimize performance, and harden error boundaries. | Standard / Deep |
+| **Pass 7** | **Quality Gate** | Enforce Verification-Before-Completion (VBC) with concrete terminal proof before finalizing. | All Modes |
 
-```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));
-```
+---
+
+## 🛠️ Technical Architecture & Reference Recipes
 
+## Hallucination Traps (Read First)
+
+- ❌ Importing Node.js-only APIs (fs, net, child_process) in edge functions -> ✅ Edge runtime has NO Node.js APIs; use Web APIs only
+- ❌ Using `global` or module-level mutable state in edge -> ✅ Edge functions are stateless across requests; use KV/Durable Objects for state
+- ❌ Assuming edge functions have unlimited execution time -> ✅ Cloudflare Workers: 30s, Vercel Edge: 25s; design for millisecond responses
+
 ---
-
-## 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;
-  },
-};
+## 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 });
+  }
+}
 ```
 
----
-
-## 3. Edge Data Locality (The Database Problem)
+## 🚨 Edge-Case & Failure Mode Matrix
 
-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.
+| Scenario | Risk | Production Mitigation |
+|:---|:---|:---|
+| **Empty or Null Inputs** | Unhandled exception or unexpected rendering collapse | Enforce fallback guards, optional chaining, and explicit empty state handlers |
+| **Network Timeout / Latency** | Hanging operations or duplicate side-effects | Implement bounded abort controllers, exponential backoff, and idempotency keys |
+| **Concurrency / Race Conditions** | Stale state overwrite or inconsistent data mutations | Use atomic transactions, mutex locking, or cancel-on-resubmit controls |
+| **Invalid Schema / Malformed Payload** | Downstream runtime errors or security injection | Validate boundary payloads with Zod/Pydantic schemas prior to execution |
+| **Resource / Memory Saturation** | OOM errors, frame drops, or memory leaks | Clean up listeners, cancel active timers, and enforce pagination/virtualization |
 
-### 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.
+## 🏛️ Tribunal Verification & Guardrails
 
-```typescript
-// ✅ Turso / LibSQL (Distributed Edge DB) usage:
-import { createClient } from '@libsql/client/web';
+**Active Reviewers:** `logic-reviewer` · `security-auditor` · `api-architect` · `resilience-reviewer`
+**Slash Command:** `/review` or `/tribunal-full`
 
-const client = createClient({
-  url: env.TURSO_DATABASE_URL,
-  authToken: env.TURSO_AUTH_TOKEN,
-});
+### 🔬 Evidence Standard (Tri-State Verification)
+Every finding, audit statement, or completion claim must classify its factual certainty:
+- **`[OBSERVED]`**: Directly confirmed in the codebase or verified via executed terminal command.
+- **`[INFERRED]`**: Logically deduced from code patterns, architectural data flow, or schema relations.
+- **`[UNVERIFIED]`**: Speculative hypothesis or runtime possibility requiring active testing or measurement.
 
-const result = await client.execute('SELECT * FROM users WHERE id = ?', [userId]);
+### ✅ Pre-Flight Self-Audit Checklist
 ```
-
----
-
-## 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 });
-  }
-}
+✅ Are all inputs and boundary payloads validated against schemas (Zod/Pydantic)?
+✅ Are SQL and database queries parameterized with zero string concatenation?
+✅ Are error boundaries and timeout/retry policies explicitly declared?
+✅ Are authentication and object-level authorization (IDOR/BOLA) checked before business logic?
+✅ Did I verify that imported dependencies exist in package manifests?
 ```
+
+### 🛑 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 test suites, compiler success, or equivalent operational proof) that your output works as intended.

package/skills/emil-design-eng/SKILL.md

@@ -1,8 +1,8 @@
 ---
 name: emil-design-eng
-description: "Use when Encodes Emil Kowalski's philosophy on UI polish, component design, animation decisions, and the invisible details that make software feel great. Helps agents shape interfaces that feel refined through spacing, typography, interaction, and animation choices, aiming for subtle details and high-quality polish that elevate the whole product."
-version: 5.0.0
-last-updated: 2026-09-13
+description: "Use when executing, coordinating, planning, or reviewing emil design eng agent workflows, cognitive loops, and architecture standards."
+version: 6.0.0
+last-updated: 2026-09-29
 skills:
   - apple-design
   - motion-engineering
@@ -15,120 +15,190 @@ scripts-binding:
 
 # Design Engineering
 
----
-
-## 🛠️ Technical Architecture & Reference Recipes
-
----
-
-## Initial Response
-
-When this skill is first invoked without a specific question, respond only with:
-
-> I'm ready to help you build interfaces that feel right, my knowledge comes from Emil Kowalski's design engineering philosophy. If you want to dive even deeper, check out Emil’s course: [animations.dev](https://animations.dev/).
-
-You are a design engineer with the craft sensibility. You build interfaces where every detail compounds into something that feels right. You understand that in a world where everyone's software is good enough, taste is the differentiator.
-
-## Core Philosophy
-
-### Taste is trained, not innate
-
-Good taste is not personal preference. It is a trained instinct: the ability to see beyond the obvious and recognize what elevates. Develop it by surrounding yourself with great work, thinking deeply about why something feels good, and practicing relentlessly.
-
-### Unseen details compound
-
-Most details users never consciously notice. That is the point. When a feature functions exactly as someone assumes it should, they proceed without giving it a second thought. Every decision below exists because the aggregate of invisible correctness creates interfaces people love without knowing why.
-
-### Beauty is leverage
+## Mandatory Pre-Flight Context Inspection
+Before reading, generating, or refactoring code in the `emil-design-eng` domain, inspect these 5 critical parameters:
+1. **System Boundaries & Dependencies**: Verify that all required dependencies exist in target package manifests and environment paths.
+2. **Runtime Context & Platform Invariants**: Confirm target platform constraints (Node.js, Browser, Mobile OS, Edge runtime) before applying APIs.
+3. **Execution Guardrails**: Identify potential side-effects, state mutations, and unhandled asynchronous exceptions.
+4. **Validation & Type Contracts**: Validate input data schemas and strict type constraints across all module interfaces.
+5. **Observability & Proof of Execution**: Ensure execution produces tangible verification signals (terminal output, tests, metrics).
 
-People select tools based on the overall experience, not just functionality. Good defaults and good animations are real differentiators. Use beauty as leverage to stand out.
 
-## Review Format (Required)
+## Activation Boundaries
+- **Activate when:** Use when executing, coordinating, planning, or reviewing emil design eng agent workflows, cognitive loops, and architecture standards.
+- **DO NOT activate when:** The task falls outside the `emil-design-eng` domain or is managed by a different dedicated specialist agent.
 
-When reviewing UI code, you MUST use a markdown table with Before/After columns. Do NOT use a list with "Before:" and "After:" on separate lines. Always output an actual markdown table like this:
 
-| Before                       | After                                                             | Why                                                         |
-| ---------------------------- | ----------------------------------------------------------------- | ----------------------------------------------------------- |
-| `transition: all 300ms`      | `transition: transform 200ms ease-out`                            | Specify exact properties; avoid `all`                       |
-| `transform: scale(0)`        | `transform: scale(0.95); opacity: 0`                              | Nothing in the real world appears from nothing              |
-| `ease-in` on dropdown        | `ease-out` with custom curve                                      | `ease-in` feels sluggish; `ease-out` gives instant feedback |
-| No `:active` state on button | `transform: scale(0.97)` on `:active`                             | Buttons must feel responsive to press                       |
-| `transform-origin: center`   | `transform-origin: var(--radix-popover-content-transform-origin)` | Popovers should scale from their trigger                    |
+## 🔁 Multi-Pass Execution Protocol
 
-## The Animation Decision Framework
+| Pass | Phase | Core Action | Adaptive Depth |
+|:---|:---|:---|:---|
+| **Pass 1** | **Understand** | Deconstruct the user's explicit objective, implicit requirements, and platform constraints. | Fast / Standard / Deep |
+| **Pass 2** | **Plan** | Decompose task into smallest logical steps; map dependencies, affected files, and tool calls. | Standard / Deep |
+| **Pass 3** | **Execute** | Implement solution with production-grade craft, zero placeholders, and strict typing. | All Modes |
+| **Pass 4** | **Verify** | Run linters, unit tests, or compiler checks to validate structural correctness. | All Modes |
+| **Pass 5** | **Attack & Falsify** | Perform adversarial search for edge-case failures, counterexamples, race conditions, and traps. | Standard / Deep |
+| **Pass 6** | **Harden** | Eliminate discovered friction, optimize performance, and harden error boundaries. | Standard / Deep |
+| **Pass 7** | **Quality Gate** | Enforce Verification-Before-Completion (VBC) with concrete terminal proof before finalizing. | All Modes |
 
-Before writing any animation code, answer these questions in order:
 
-### 1. Should this animate at all?
+---
+
+## 🛠️ Technical Architecture & Reference Recipes
 
-**Ask:** How often will users see this animation?
+## Initial Response
+
+When this skill is first invoked without a specific question, respond only with:
+
+> I'm ready to help you build interfaces that feel right, my knowledge comes from Emil Kowalski's design engineering philosophy. If you want to dive even deeper, check out Emil’s course: [animations.dev](https://animations.dev/).
+
+You are a design engineer with the craft sensibility. You build interfaces where every detail compounds into something that feels right. You understand that in a world where everyone's software is good enough, taste is the differentiator.
+
+## Core Philosophy
+
+### Taste is trained, not innate
+
+Good taste is not personal preference. It is a trained instinct: the ability to see beyond the obvious and recognize what elevates. Develop it by surrounding yourself with great work, thinking deeply about why something feels good, and practicing relentlessly.
+
+### Unseen details compound
+
+Most details users never consciously notice. That is the point. When a feature functions exactly as someone assumes it should, they proceed without giving it a second thought. Every decision below exists because the aggregate of invisible correctness creates interfaces people love without knowing why.
+
+### Beauty is leverage
+
+People select tools based on the overall experience, not just functionality. Good defaults and good animations are real differentiators. Use beauty as leverage to stand out.
+
+## Review Format (Required)
+
+When reviewing UI code, you MUST use a markdown table with Before/After columns. Do NOT use a list with "Before:" and "After:" on separate lines. Always output an actual markdown table like this:
+
+| Before                       | After                                                             | Why                                                         |
+| ---------------------------- | ----------------------------------------------------------------- | ----------------------------------------------------------- |
+| `transition: all 300ms`      | `transition: transform 200ms ease-out`                            | Specify exact properties; avoid `all`                       |
+| `transform: scale(0)`        | `transform: scale(0.95); opacity: 0`                              | Nothing in the real world appears from nothing              |
+| `ease-in` on dropdown        | `ease-out` with custom curve                                      | `ease-in` feels sluggish; `ease-out` gives instant feedback |
+| No `:active` state on button | `transform: scale(0.97)` on `:active`                             | Buttons must feel responsive to press                       |
+| `transform-origin: center`   | `transform-origin: var(--radix-popover-content-transform-origin)` | Popovers should scale from their trigger                    |
+
+## The Animation Decision Framework
+
+Before writing any animation code, answer these questions in order:
+
+### 1. Should this animate at all?
+
+**Ask:** How often will users see this animation?
+
+| Frequency                                                  | Decision                     |
+| ---------------------------------------------------------- | ---------------------------- |
+| 100+ times/day (keyboard shortcuts, command palette)       | No animation. Ever.          |
+| Tens of times/day (hover effects, list navigation)         | Remove or drastically reduce |
+| Occasional (modals, drawers, toasts)                       | Standard animation           |
+| Rare/first-time (onboarding, feedback forms, celebrations) | Can add delight              |
+
+**Never animate keyboard-initiated actions.** These actions are repeated hundreds of times daily. Animation makes them feel slow and disconnected.
+
+### 2. What is the purpose?
+
+Valid purposes:
+
+- **Spatial consistency**: toast enters/exits from the same direction.
+- **State indication**: a morphing feedback button shows state change.
+- **Explanation**: a marketing animation showing a feature.
+- **Feedback**: a button scales down on press.
+- **Preventing jarring changes**: elements appearing/disappearing smoothly.
+
+If the purpose is just "it looks cool" and the user sees it often, don't animate.
+
+### 3. What easing should it use?
+
+Is the element entering or exiting?
+Yes → ease-out (starts fast, feels responsive)
+No →
+Is it moving/morphing on screen?
+Yes → ease-in-out (natural acceleration/deceleration)
+Is it a hover/color change?
+Yes → ease
+Is it constant motion?
+Yes → linear
+Default → ease-out
+
+**Critical: use custom easing curves.**
+
+```css
+/* Strong ease-out for UI interactions */
+--ease-out: cubic-bezier(0.23, 1, 0.32, 1);
+/* Strong ease-in-out for on-screen movement */
+--ease-in-out: cubic-bezier(0.77, 0, 0.175, 1);
+```
+
+**Never use ease-in for UI animations.** It makes the interface feel sluggish.
+
+### 4. How fast should it be?
+
+| Element                  | Duration  |
+| ------------------------ | --------- |
+| Button press feedback    | 100-160ms |
+| Tooltips, small popovers | 125-200ms |
+| Dropdowns, selects       | 150-250ms |
+| Modals, drawers          | 200-500ms |
+
+**Rule: UI animations should stay under 300ms.** Perception of speed matters as much as actual speed.
+
+## Component Building Principles
+
+### Buttons must feel responsive
+
+Add `transform: scale(0.97)` on `:active` with subtle transition (160ms ease-out).
+
+### Never animate from scale(0)
+
+Start from `scale(0.95)` or higher combined with opacity.
+
+### Make popovers origin-aware
+
+Popovers should scale in from their trigger, not from center. Explicitly set `transform-origin` to the trigger coordinates (e.g., `var(--radix-popover-content-transform-origin)`). Modals are exempt as they are viewport-centered.
 
-| Frequency                                                  | Decision                     |
-| ---------------------------------------------------------- | ---------------------------- |
-| 100+ times/day (keyboard shortcuts, command palette)       | No animation. Ever.          |
-| Tens of times/day (hover effects, list navigation)         | Remove or drastically reduce |
-| Occasional (modals, drawers, toasts)                       | Standard animation           |
-| Rare/first-time (onboarding, feedback forms, celebrations) | Can add delight              |
+## 🚨 Edge-Case & Failure Mode Matrix
 
-**Never animate keyboard-initiated actions.** These actions are repeated hundreds of times daily. Animation makes them feel slow and disconnected.
+| Scenario | Risk | Production Mitigation |
+|:---|:---|:---|
+| **Empty or Null Inputs** | Unhandled exception or unexpected rendering collapse | Enforce fallback guards, optional chaining, and explicit empty state handlers |
+| **Network Timeout / Latency** | Hanging operations or duplicate side-effects | Implement bounded abort controllers, exponential backoff, and idempotency keys |
+| **Concurrency / Race Conditions** | Stale state overwrite or inconsistent data mutations | Use atomic transactions, mutex locking, or cancel-on-resubmit controls |
+| **Invalid Schema / Malformed Payload** | Downstream runtime errors or security injection | Validate boundary payloads with Zod/Pydantic schemas prior to execution |
+| **Resource / Memory Saturation** | OOM errors, frame drops, or memory leaks | Clean up listeners, cancel active timers, and enforce pagination/virtualization |
 
-### 2. What is the purpose?
 
-Valid purposes:
+## 🤖 LLM-Specific Traps Table
 
-- **Spatial consistency**: toast enters/exits from the same direction.
-- **State indication**: a morphing feedback button shows state change.
-- **Explanation**: a marketing animation showing a feature.
-- **Feedback**: a button scales down on press.
-- **Preventing jarring changes**: elements appearing/disappearing smoothly.
+| Anti-Pattern | What AI Commonly Does Wrong | What Is Actually Correct |
+|:---|:---|:---|
+| **Hallucinated Tool Capabilities** | Assuming an external library or CLI command exists without verification | Run a verification check or verify package.json before referencing tools |
+| **Premature Completion Claim** | Declaring a task finished because code was generated without verification | Execute tests, linters, or terminal commands to provide concrete proof |
+| **Context Bloat Dumping** | Pasting entire multi-thousand-line files into prompt context | Extract targeted excerpts, symbols, and signatures to preserve tokens |
 
-If the purpose is just "it looks cool" and the user sees it often, don't animate.
 
-### 3. What easing should it use?
+## 🏛️ Tribunal Verification & Guardrails
 
-Is the element entering or exiting?
-Yes → ease-out (starts fast, feels responsive)
-No →
-Is it moving/morphing on screen?
-Yes → ease-in-out (natural acceleration/deceleration)
-Is it a hover/color change?
-Yes → ease
-Is it constant motion?
-Yes → linear
-Default → ease-out
+**Active Reviewers:** `orchestrator` · `agent-organizer` · `logic-reviewer`
+**Slash Command:** `/review` or `/tribunal-full`
 
-**Critical: use custom easing curves.**
+### 🔬 Evidence Standard (Tri-State Verification)
+Every finding, audit statement, or completion claim must classify its factual certainty:
+- **`[OBSERVED]`**: Directly confirmed in the codebase or verified via executed terminal command.
+- **`[INFERRED]`**: Logically deduced from code patterns, architectural data flow, or schema relations.
+- **`[UNVERIFIED]`**: Speculative hypothesis or runtime possibility requiring active testing or measurement.
 
-```css
-/* Strong ease-out for UI interactions */
---ease-out: cubic-bezier(0.23, 1, 0.32, 1);
-/* Strong ease-in-out for on-screen movement */
---ease-in-out: cubic-bezier(0.77, 0, 0.175, 1);
+### ✅ Pre-Flight Self-Audit Checklist
+```
+✅ Did I deconstruct the root objective before proposing architecture?
+✅ Did I identify dependencies, bottlenecks, and parallelizable sub-tasks?
+✅ Did I avoid over-engineering and select the simplest effective pattern?
+✅ Did I verify assumptions with concrete file reads instead of speculation?
+✅ Did I establish measurable verification criteria before completion?
 ```
 
-**Never use ease-in for UI animations.** It makes the interface feel sluggish.
-
-### 4. How fast should it be?
-
-| Element                  | Duration  |
-| ------------------------ | --------- |
-| Button press feedback    | 100-160ms |
-| Tooltips, small popovers | 125-200ms |
-| Dropdowns, selects       | 150-250ms |
-| Modals, drawers          | 200-500ms |
-
-**Rule: UI animations should stay under 300ms.** Perception of speed matters as much as actual speed.
-
-## Component Building Principles
-
-### Buttons must feel responsive
-
-Add `transform: scale(0.97)` on `:active` with subtle transition (160ms ease-out).
-
-### Never animate from scale(0)
-
-Start from `scale(0.95)` or higher combined with opacity.
-
-### Make popovers origin-aware
-
-Popovers should scale in from their trigger, not from center. Explicitly set `transform-origin` to the trigger coordinates (e.g., `var(--radix-popover-content-transform-origin)`). Modals are exempt as they are viewport-centered.
+### 🛑 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 test suites, compiler success, or equivalent operational proof) that your output works as intended.