tribunal-kit 4.5.1 → 4.6.1

package/.agent/skills/webapp-testing/SKILL.md

@@ -1,173 +1,169 @@
----
-name: webapp-testing
-description: Comprehensive Web Application Testing strategy. Test Pyramid, Vitest/Jest for unit logic, React Testing Library for component integrity, MSW (Mock Service Worker) for API layer simulation, and visual regression. Use when setting up testing environments or defining global test strategies across a web stack.
-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
----
-
-## Hallucination Traps (Read First)
-- ❌ Mocking everything in integration tests -> ✅ Integration tests verify real interactions; mock only external services (APIs, DBs)
-- ❌ Testing Library: using `getByTestId` as the primary selector -> ✅ Prefer `getByRole`, `getByLabelText`, `getByText` for user-centric testing
-- ❌ Writing E2E tests that depend on seed data -> ✅ Each test should create its own data in setup and clean up in teardown
-
----
-
-
-# Webapp Testing — Full Stack Pipeline Mastery
-
----
-
-## 1. The Strategy (The Testing Trophy)
-
-The traditional "Testing Pyramid" (lots of Unit, little E2E) is outdated for rich UI applications. Use the **Testing Trophy**:
-
-1. **Static Analysis (10%)**: TypeScript, ESLint, Prettier (Catches typos and type mismatches instantly).
-2. **Unit Tests (20%)**: Vitest (Tests complex pure functions: math, formatting, data mapping).
-3. **Integration Tests (60%)**: React Testing Library + MSW (Tests components and network mock interactions together).
-4. **End-to-End Tests (10%)**: Playwright (Tests the critical path: Login, Checkout, Account Creation on a real browser).
-
----
-
-## 2. Integration Layer (React Testing Library + MSW)
-
-Do not mock child components. Render the specific DOM tree and interact with it as a user would. 
-
-To prevent network calls, utilize Mock Service Worker (MSW) which intercepts requests at the network layer natively.
-
-```typescript
-// ❌ BAD: Mocking implementation details
-jest.mock('axios');
-axios.get.mockResolvedValue({ data: { users: [] } });
-
-// ✅ GOOD: MSW (Mock Service Worker) network level interception
-// The component functions EXACTLY as it would in production
-import { http, HttpResponse } from 'msw'
-import { setupServer } from 'msw/node'
-
-export const handlers = [
-  http.get('/api/users', () => {
-    return HttpResponse.json([
-      { id: 1, name: 'John Appleseed' },
-    ])
-  }),
-]
-const server = setupServer(...handlers)
-
-beforeAll(() => server.listen())
-afterEach(() => server.resetHandlers())
-afterAll(() => server.close())
-```
-
-### Component Testing (RTL)
-
-```typescript
-import { render, screen, waitFor } from '@testing-library/react';
-import userEvent from '@testing-library/user-event';
-
-test('Should load users and render names', async () => {
-  // userEvent closely replicates real browser physics (focusing, keystrokes)
-  const user = userEvent.setup();
-  
-  render(<UserDashboard />);
-
-  // Initial State
-  expect(screen.getByText('Loading...')).toBeInTheDocument();
-
-  // Async Resolution (Auto-waits for the MSW mock to return)
-  const johnNode = await screen.findByText('John Appleseed');
-  expect(johnNode).toBeInTheDocument();
-
-  // Interaction
-  const deleteBtn = screen.getByRole('button', { name: "Delete John" });
-  await user.click(deleteBtn);
-
-  // Verification 
-  expect(johnNode).not.toBeInTheDocument();
-});
-```
-
----
-
-## 3. Pure Unit Testing (Vitest)
-
-Isolate business logic entirely from React.
-
-```typescript
-// ✅ Move complex logic OUT of the React component entirely
-export function calculateTax(subtotal: number, state: string): number {
-  if (subtotal < 0) throw new Error("Subtotal cannot be negative");
-  if (state === "CA") return subtotal * 0.0825;
-  return 0; // Default
-}
-
-// ✅ Test with extreme precision and coverage
-import { describe, it, expect } from 'vitest';
-
-describe('calculateTax()', () => {
-  it('applies CA tax correctly', () => {
-    expect(calculateTax(100, 'CA')).toBe(8.25);
-  });
-  
-  it('throws on negative input', () => {
-    expect(() => calculateTax(-50, 'CA')).toThrowError('negative');
-  });
-});
-```
-
----
-
-
----
-
-
-
-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.
-
----
-
-
-
-**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.
-
-
-
-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.
-
-
-## Pre-Flight Checklist
-- [ ] Have I reviewed the user's specific constraints and requests?
-- [ ] Have I checked the environment for relevant existing implementations?
-
-## VBC Protocol (Verification-Before-Completion)
-You MUST verify existing code signatures and variables before attempting to modify or call them. No hallucination is permitted.
+---
+name: webapp-testing
+description: Comprehensive Web Application Testing strategy. Test Pyramid, Vitest/Jest for unit logic, React Testing Library for component integrity, MSW (Mock Service Worker) for API layer simulation, and visual regression. Use when setting up testing environments or defining global test strategies across a web stack.
+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
+routing:
+  domain: general
+  tier: basic
+---
+
+## Hallucination Traps (Read First)
+
+- ❌ Mocking everything in integration tests -> ✅ Integration tests verify real interactions; mock only external services (APIs, DBs)
+- ❌ Testing Library: using `getByTestId` as the primary selector -> ✅ Prefer `getByRole`, `getByLabelText`, `getByText` for user-centric testing
+- ❌ Writing E2E tests that depend on seed data -> ✅ Each test should create its own data in setup and clean up in teardown
+
+---
+
+# Webapp Testing — Full Stack Pipeline Mastery
+
+---
+
+## 1. The Strategy (The Testing Trophy)
+
+The traditional "Testing Pyramid" (lots of Unit, little E2E) is outdated for rich UI applications. Use the **Testing Trophy**:
+
+1. **Static Analysis (10%)**: TypeScript, ESLint, Prettier (Catches typos and type mismatches instantly).
+2. **Unit Tests (20%)**: Vitest (Tests complex pure functions: math, formatting, data mapping).
+3. **Integration Tests (60%)**: React Testing Library + MSW (Tests components and network mock interactions together).
+4. **End-to-End Tests (10%)**: Playwright (Tests the critical path: Login, Checkout, Account Creation on a real browser).
+
+---
+
+## 2. Integration Layer (React Testing Library + MSW)
+
+Do not mock child components. Render the specific DOM tree and interact with it as a user would.
+
+To prevent network calls, utilize Mock Service Worker (MSW) which intercepts requests at the network layer natively.
+
+```typescript
+// ❌ BAD: Mocking implementation details
+jest.mock("axios");
+axios.get.mockResolvedValue({ data: { users: [] } });
+
+// ✅ GOOD: MSW (Mock Service Worker) network level interception
+// The component functions EXACTLY as it would in production
+import { http, HttpResponse } from "msw";
+import { setupServer } from "msw/node";
+
+export const handlers = [
+  http.get("/api/users", () => {
+    return HttpResponse.json([{ id: 1, name: "John Appleseed" }]);
+  }),
+];
+const server = setupServer(...handlers);
+
+beforeAll(() => server.listen());
+afterEach(() => server.resetHandlers());
+afterAll(() => server.close());
+```
+
+### Component Testing (RTL)
+
+```typescript
+import { render, screen, waitFor } from '@testing-library/react';
+import userEvent from '@testing-library/user-event';
+
+test('Should load users and render names', async () => {
+  // userEvent closely replicates real browser physics (focusing, keystrokes)
+  const user = userEvent.setup();
+
+  render(<UserDashboard />);
+
+  // Initial State
+  expect(screen.getByText('Loading...')).toBeInTheDocument();
+
+  // Async Resolution (Auto-waits for the MSW mock to return)
+  const johnNode = await screen.findByText('John Appleseed');
+  expect(johnNode).toBeInTheDocument();
+
+  // Interaction
+  const deleteBtn = screen.getByRole('button', { name: "Delete John" });
+  await user.click(deleteBtn);
+
+  // Verification
+  expect(johnNode).not.toBeInTheDocument();
+});
+```
+
+---
+
+## 3. Pure Unit Testing (Vitest)
+
+Isolate business logic entirely from React.
+
+```typescript
+// ✅ Move complex logic OUT of the React component entirely
+export function calculateTax(subtotal: number, state: string): number {
+  if (subtotal < 0) throw new Error("Subtotal cannot be negative");
+  if (state === "CA") return subtotal * 0.0825;
+  return 0; // Default
+}
+
+// ✅ Test with extreme precision and coverage
+import { describe, it, expect } from "vitest";
+
+describe("calculateTax()", () => {
+  it("applies CA tax correctly", () => {
+    expect(calculateTax(100, "CA")).toBe(8.25);
+  });
+
+  it("throws on negative input", () => {
+    expect(() => calculateTax(-50, "CA")).toThrowError("negative");
+  });
+});
+```
+
+---
 
+---
+
+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.
+
+---
+
+**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.
+
+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.
+
+## Pre-Flight Checklist
+
+- [ ] Have I reviewed the user's specific constraints and requests?
+- [ ] Have I checked the environment for relevant existing implementations?
+
+## VBC Protocol (Verification-Before-Completion)
+
+You MUST verify existing code signatures and variables before attempting to modify or call them. No hallucination is permitted.
 
 ---
 
@@ -197,6 +193,7 @@ AI coding assistants often fall into specific bad habits when dealing with this
 ### ✅ 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?
@@ -207,5 +204,6 @@ Review these questions before confirming output:
 ### 🛑 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/webgpu-performance/SKILL.md

@@ -1,6 +1,9 @@
 ---
 name: webgpu-performance
 description: High-performance browser graphics and compute mastery. Transitioning from WebGL to WebGPU API, WGSL compute shaders, explicit GPU memory management, and browser-side tensor calculations.
+routing:
+  domain: general
+  tier: basic
 ---
 
 # WebGPU Performance Mastery
@@ -8,11 +11,13 @@ description: High-performance browser graphics and compute mastery. Transitionin
 You are an expert in writing low-level, high-performance browser graphics and compute pipelines using WebGPU and WGSL (WebGPU Shading Language). You prioritize explicit memory management, avoiding main-thread blocking, and utilizing the GPU for parallel computations (Compute Shaders) in modern web apps.
 
 ## 1. Core Principles
+
 - **Explicit > Implicit:** Unlike WebGL, WebGPU doesn't hide state. You must explicitly configure Pipelines, BindGroups, and CommandEncoders.
 - **Compute First:** Leverage Compute Shaders (`@compute @workgroup_size(X, Y)`) for heavy array manipulation, physics, or ML tensor operations, keeping the CPU entirely free.
 - **Buffer Alignment:** WGSL requires strict 4-byte or 16-byte alignment (`vec4<f32>`, `mat4x4<f32>`). Always pad structs exactly to prevent silent memory corruption.
 
 ## 2. WGSL Compute Shader Pattern
+
 When performing parallel calculations (e.g., particle physics or ML matrix multiplication):
 
 ```wgsl
@@ -28,7 +33,7 @@ struct SystemData {
 fn main(@builtin(global_invocation_id) global_id: vec3<u32>) {
     let index = global_id.x;
     if (index >= data.particleCount) { return; }
-    
+
     var pos = particles[index];
     pos.y -= 9.8 * data.deltaTime; // Gravity
     particles[index] = pos;
@@ -36,12 +41,14 @@ fn main(@builtin(global_invocation_id) global_id: vec3<u32>) {
 ```
 
 ## 3. WebGPU Execution Pipeline
+
 To run the above compute shader from TypeScript:
+
 1. **Initialize:** `navigator.gpu.requestAdapter()` -> `requestDevice()`.
 2. **Create Buffers:** `device.createBuffer({ size, usage: GPUBufferUsage.STORAGE | GPUBufferUsage.COPY_DST })`.
 3. **Write Data:** `device.queue.writeBuffer(buffer, 0, float32Array)`.
 4. **Bind Group:** Group buffers into a `GPUBindGroup`.
-5. **Command Encoder:** 
+5. **Command Encoder:**
    ```typescript
    const encoder = device.createCommandEncoder();
    const pass = encoder.beginComputePass();
@@ -53,6 +60,7 @@ To run the above compute shader from TypeScript:
    ```
 
 ## 4. LLM Traps & Pre-Flight Checks
+
 - **TRAP:** Assuming WebGPU works everywhere.
 - **FIX:** Always feature-detect with `if (!navigator.gpu) { fallbackToWebGL(); }`.
 - **TRAP:** Struct alignment issues in WGSL.
@@ -61,7 +69,9 @@ To run the above compute shader from TypeScript:
 - **FIX:** Use `mapAsync(GPUMapMode.READ)` and await it. Do not block the main thread.
 
 ## Verification Protocol
+
 Before submitting code, ensure:
+
 1. Devices and adapters are properly null-checked.
 2. WGSL workgroup sizes align with the dispatch sizes dynamically.
 3. GPUBuffers used for compute have `GPUBufferUsage.STORAGE` flags.
@@ -69,5 +79,49 @@ Before submitting code, ensure:
 ### 🛑 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.
+
+---
+
+## 🤖 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.