tribunal-kit 2.4.6 → 3.1.0

package/.agent/skills/web-accessibility-auditor/SKILL.md

@@ -1,76 +1,159 @@
----
-name: web-accessibility-auditor
-description: Hardcore digital accessibility (a11y) auditor and WCAG 2.2 expert. Enforces semantic HTML, keyboard operability, screen reader support, and robust contrast.
-allowed-tools: Read, Write, Edit, Glob, Grep
-version: 1.0.0
-last-updated: 2026-03-30
-applies-to-model: claude-3-7-sonnet, gemini-2.5-pro
----
-
-# Web Accessibility (A11y) Auditor
-
-You are a WCAG 2.2 strict compliance auditor. Your sole purpose is to ruthlessly critique HTML and React codebases for accessibility violations, ensuring digital products remain usable for all individuals, including those operating assistive technologies.
-
-## Core Directives
-
-1. **Semantic HTML is Law:**
-   - Do not replace `<button>` with a `<div onClick={...}>`.
-   - Ensure proper `<label>` to `id` mapping for every single form input.
-   - Verify correct heading hierarchies (`<h1>` followed by `<h2>`, no skipped levels).
-
-2. **Keyboard Operability:**
-   - All interactive elements must be reachable via the `Tab` key (have a `tabindex="0"` or natively support it).
-   - Ensure visible focus states are present (`:focus-visible`). Provide highly contrasted outlines; never apply `outline: none` without a fallback visual indicator.
-
-3. **Screen Reader (ARIA) Usage:**
-   - *First rule of ARIA: No ARIA is better than bad ARIA.* Rely on native elements before resorting to `role="..."`.
-   - Clearly dictate states for dynamic components using `aria-expanded`, `aria-hidden`, `aria-current`, and `aria-live` for notifications.
-
-4. **Meaningful Contrast & Media:**
-   - Ensure text has a minimum contrast ratio of 4.5:1 against its background.
-   - All `<img>` tags must include descriptive `alt` text. Decorative images must explicitly set `alt=""`.
-
-## Execution
-When auditing a file, explicitly point out any `onClick` handlers on non-interactive elements, missing `aria-labels` on icon-only buttons, and bad color pairings. Write the exact React/HTML delta needed to pass a strict automated Axe-core scan.
+---
+name: web-accessibility-auditor
+description: Web Accessibility (a11y) mastery. WCAG 2.2 AA standards, semantic HTML, ARIA attributes, keyboard navigation, focus management, screen reader compatibility, color contrast, and dynamic content announcements. Use when building UI components or auditing frontend code for accessibility compliance.
+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
+---
 
+# Web Accessibility (a11y) — Inclusive UI Mastery
 
 ---
 
-## 🤖 LLM-Specific Traps
+## 1. Semantic HTML over `<div>` Soup
+
+The first rule of ARIA: **Use native HTML elements whenever possible.**
+
+```html
+<!-- ❌ BAD: Meaningless markup, screen readers see nothing, no keyboard focus -->
+<div class="submit-button" onclick="submit()">Submit</div>
 
-AI coding assistants often fall into specific bad habits when dealing with this domain. These are strictly forbidden:
+<!-- ✅ GOOD: Native semantic element (inherits focus, Enter/Space key behavior) -->
+<button type="submit" class="button">Submit</button>
 
-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.
+<!-- ❌ BAD: Div as a link -->
+<div onclick="goToPath('/about')">About Us</div>
+
+<!-- ✅ GOOD: Native anchor -->
+<a href="/about">About Us</a>
+```
+
+### Layout Semantics
+Replace `<div class="x">` with meaning:
+- `<header>` / `<footer>`
+- `<nav>` (Main navigations)
+- `<main>` (The primary content)
+- `<article>` (Self-contained content blocks)
+- `<aside>` (Sidebars, callouts)
 
 ---
 
-## 🏛️ Tribunal Integration (Anti-Hallucination)
+## 2. Keyboard Navigation & Focus Management
 
-**Slash command: `/review` or `/tribunal-full`**
-**Active reviewers: `logic-reviewer` · `security-auditor`**
+Every interactive element MUST be keyboard accessible.
 
-### ❌ Forbidden AI Tropes
+```css
+/* ❌ BAD: Removing focus outlines ruins keyboard navigation */
+*:focus { outline: none; }
 
-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.
+/* ✅ GOOD: Using :focus-visible for keyboard users only */
+*:focus { outline: none; } /* Hide for click */
+*:focus-visible { outline: 2px solid var(--accent-color); outline-offset: 2px; }
+```
 
-### ✅ Pre-Flight Self-Audit
+### Managing Focus in Modals (Dialogs)
+When a modal opens:
+1. Focus must move into the modal (first focusable element).
+2. Focus must be trapped inside the modal (Tabbing loops inside it).
+3. Background must be hidden from screen readers (`aria-hidden="true"`).
+4. `Escape` key must close it.
+5. When closed, focus returns to the button that opened it.
 
-Review these questions before confirming output:
+```html
+<!-- ✅ BEST: Use the native <dialog> element. It handles focus trapping automatically! -->
+<dialog id="myModal">
+  <h2>Settings</h2>
+  <button formmethod="dialog">Close</button>
+</dialog>
+<script>document.getElementById('myModal').showModal();</script>
 ```
-✅ 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?
+
+---
+
+## 3. ARIA Roles & Attributes
+
+When you build complex custom widgets (like tabs or accordions), you must apply ARIA attributes to tell screen readers what it is and what state it's in.
+
+```html
+<!-- Example: Custom Accordion/Disclosure -->
+<!-- ❌ BAD: Screen reader sees plain text, doesn't know it's expandable -->
+<div class="accordion">
+  <div class="header">Advanced Settings</div>
+  <div class="content" style="display: none;">...</div>
+</div>
+
+<!-- ✅ GOOD: ARIA provides context -->
+<div class="accordion">
+  <button 
+    aria-expanded="false" 
+    aria-controls="panel-id"
+    id="header-id"
+  >
+    Advanced Settings
+  </button>
+  <div 
+    id="panel-id" 
+    role="region" 
+    aria-labelledby="header-id" 
+    hidden
+  >
+    ...
+  </div>
+</div>
 ```
 
-### 🛑 Verification-Before-Completion (VBC) Protocol
+**Crucial ARIA states:**
+- `aria-expanded="true/false"`: For accordions, dropdowns, menus.
+- `aria-hidden="true"`: Removes decorative icons/containers from the screen reader tree.
+- `aria-pressed="true/false"`: For toggle buttons.
+- `aria-invalid="true"`: For invalid form fields.
+
+---
 
-**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.
+## 4. Forms & Labels
+
+**Every input must have an associated label.** `placeholder` is NOT a label (it disappears when typing, causing cognitive loss).
+
+```html
+<!-- ❌ BAD -->
+<input type="text" placeholder="Email Address">
+
+<!-- ✅ GOOD: Explicit linking via id/for -->
+<label for="email">Email Address</label>
+<input type="email" id="email" name="email">
+
+<!-- ✅ GOOD: Implicit wrapping -->
+<label>
+  Email Address
+  <input type="email" name="email">
+</label>
+
+<!-- Accessible Error Messages -->
+<label for="username">Username</label>
+<input 
+  type="text" 
+  id="username" 
+  aria-invalid="true" 
+  aria-describedby="username-error"
+
+<span id="username-error" role="alert" class="error-msg">Username is already taken</span>
+```
+
+---
+
+## 5. Live Regions (Dynamic Updates)
+
+When content changes dynamically without a page reload (e.g., Toast notifications, AI responding, search results updating), the screen reader needs to be notified.
+
+```html
+<!-- 
+  role="alert": Interrupts the user immediately (e.g., error).
+  role="status" (or aria-live="polite"): Waits until the user pauses, then announces.
+-->
+<div aria-live="polite" class="sr-only">
+  <!-- JavaScript injects: "3 items found" here, screen reader reads it aloud -->
+</div>
+```
+
+---

package/.agent/skills/web-design-guidelines/SKILL.md

@@ -9,9 +9,6 @@ applies-to-model: gemini-2.5-pro, claude-3-7-sonnet
 
 # Next-Gen Web Interface Review Guidelines (Pro-Max Level)
 
-> Good UI is invisible. Users think about their task, not about the interface.
-> Great UI anticipates the task and reacts at the speed of thought.
-
 ---
 
 ## Review Trigger
@@ -30,23 +27,23 @@ Load this skill when asked to:
 
 Non-negotiable baseline for any public interface in 2026+:
 
-| Check | How to Verify |
+|Check|How to Verify|
 |---|---|
-| **APCA Contrast** | Ensure Lc (Lightness Contrast) is > 75 for body text, > 60 for large text. (Do not rely solely on old WCAG 2.1 4.5:1 math). |
-| **Cognitive Safety** | Check if `prefers-reduced-motion` is respected. No infinite spinning loaders. |
-| **Keyboard Fluidity** | Tab order must follow visual order. Focus states cannot be just a 1px dotted line; use `outline: 2px solid var(--focus-color); outline-offset: 2px;`. |
-| **Semantic AI Context** | Images must have `alt` tags, but complex charts need full `<details>` breakdowns for screen readers and AI agents crawling the site. |
-| **Interaction Buffers** | Are touch targets mathematically ≥48px (Fitts' Law)? |
+|**APCA Contrast**|Ensure Lc (Lightness Contrast) is > 75 for body text, > 60 for large text. (Do not rely solely on old WCAG 2.1 4.5:1 math).|
+|**Cognitive Safety**|Check if `prefers-reduced-motion` is respected. No infinite spinning loaders.|
+|**Keyboard Fluidity**|Tab order must follow visual order. Focus states cannot be just a 1px dotted line; use `outline: 2px solid var(--focus-color); outline-offset: 2px;`.|
+|**Semantic AI Context**|Images must have `alt` tags, but complex charts need full `<details>` breakdowns for screen readers and AI agents crawling the site.|
+|**Interaction Buffers**|Are touch targets mathematically ≥48px (Fitts' Law)?|
 
 ### 2. Extreme Core Web Vitals (CWV)
 
 Drop the old 2022 standards. The new baseline for premium web:
 
-| Metric | Premium Target | Common Failures |
+|Metric|Premium Target|Common Failures|
 |---|---|---|
-| **LCP** (Largest Contentful Paint) | **< 1.5s** | Missing `fetchpriority="high"` on hero images. Heavy client-side React rendering blocking the paint. |
-| **INP** (Interaction to Next Paint) | **< 100ms** | Main thread blocked by React hydrate. Use `startTransition` or Web Workers for heavy JS. |
-| **CLS** (Cumulative Layout Shift) | **0.00** | Missing `width` and `height` on images. Late-loading web fonts (use `font-display: optional`). |
+|**LCP** (Largest Contentful Paint)|**< 1.5s**|Missing `fetchpriority="high"` on hero images. Heavy client-side React rendering blocking the paint.|
+|**INP** (Interaction to Next Paint)|**< 100ms**|Main thread blocked by React hydrate. Use `startTransition` or Web Workers for heavy JS.|
+|**CLS** (Cumulative Layout Shift)|**0.00**|Missing `width` and `height` on images. Late-loading web fonts (use `font-display: optional`).|
 
 ### 3. Energy Efficiency & Sustainability
 
@@ -75,14 +72,14 @@ Evaluate these brutally honestly:
 
 ## Common Review Findings
 
-| Finding | Severity | Fix |
+|Finding|Severity|Fix|
 |---|---|---|
-| Missing/Weak focus styles | High | Add visible `:focus-visible` with offset |
-| `margin`/`padding` animated | High | Change to `transform: translate()` |
-| Touch targets under 48px | High | Increase padding/min-height |
-| Layout shifts on load (CLS > 0) | High | Pre-allocate space for async content/images |
-| Linear CSS transitions | Medium | Upgrade to spring-based `cubic-bezier` curves |
-| Purple as primary color | Low/Brand | Rethink palette — overused AI design cliché |
+|Missing/Weak focus styles|High|Add visible `:focus-visible` with offset|
+|`margin`/`padding` animated|High|Change to `transform: translate()`|
+|Touch targets under 48px|High|Increase padding/min-height|
+|Layout shifts on load (CLS > 0)|High|Pre-allocate space for async content/images|
+|Linear CSS transitions|Medium|Upgrade to spring-based `cubic-bezier` curves|
+|Purple as primary color|Low/Brand|Rethink palette — overused AI design cliché|
 
 ---
 
@@ -128,45 +125,4 @@ Pre-Flight:  ✅ All checks passed
              or ❌ [blocking item that must be resolved first]
 ```
 
-
-
 ---
-
-## 🤖 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/webapp-testing/SKILL.md

@@ -1,236 +1,111 @@
 ---
 name: webapp-testing
-description: Web application testing principles. E2E, Playwright, deep audit strategies.
+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: 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
 ---
 
-# Web Application Testing
-
-> E2E tests are the most expensive tests to write and maintain.
-> Write them for the flows that would wake someone up at 2am if they broke.
+# Webapp Testing — Full Stack Pipeline Mastery
 
 ---
 
-## What Belongs in E2E Tests
-
-E2E tests simulate a real user in a real browser. Use them selectively:
+## 1. The Strategy (The Testing Trophy)
 
-**Should be E2E:**
-- User can register and log in
-- User can complete a purchase / checkout flow
-- Critical form submission that triggers business logic
-- OAuth login flows
-- File upload and processing
+The traditional "Testing Pyramid" (lots of Unit, little E2E) is outdated for rich UI applications. Use the **Testing Trophy**:
 
-**Should NOT be E2E:**
-- Individual UI component appearance (use unit/visual tests)
-- API data validation (use API/integration tests)
-- Error message text (too brittle, too low value)
-- Every edge case (test edge cases at the service/unit level)
+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).
 
 ---
 
-## Playwright Patterns
+## 2. Integration Layer (React Testing Library + MSW)
 
-### Page Object Model
+Do not mock child components. Render the specific DOM tree and interact with it as a user would. 
 
-Encapsulate page interactions to keep tests maintainable:
+To prevent network calls, utilize Mock Service Worker (MSW) which intercepts requests at the network layer natively.
 
-```ts
-// page-objects/LoginPage.ts
-export class LoginPage {
-  constructor(private page: Page) {}
+```typescript
+// ❌ BAD: Mocking implementation details
+jest.mock('axios');
+axios.get.mockResolvedValue({ data: { users: [] } });
 
-  get emailInput() { return this.page.getByLabel('Email'); }
-  get passwordInput() { return this.page.getByLabel('Password'); }
-  get submitButton() { return this.page.getByRole('button', { name: 'Sign in' }); }
+// ✅ 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'
 
-  async login(email: string, password: string) {
-    await this.emailInput.fill(email);
-    await this.passwordInput.fill(password);
-    await this.submitButton.click();
-  }
-}
+export const handlers = [
+  http.get('/api/users', () => {
+    return HttpResponse.json([
+      { id: 1, name: 'John Appleseed' },
+    ])
+  }),
+]
+const server = setupServer(...handlers)
 
-// tests/auth.spec.ts
-test('user can log in with valid credentials', async ({ page }) => {
-  const loginPage = new LoginPage(page);
-  await page.goto('/login');
-  await loginPage.login('user@test.com', 'password123');
-  await expect(page).toHaveURL('/dashboard');
-});
+beforeAll(() => server.listen())
+afterEach(() => server.resetHandlers())
+afterAll(() => server.close())
 ```
 
-### Locator Strategy (Priority Order)
-
-Prefer locators that reflect how the user thinks about the element:
-
-```ts
-// 1. Role (most semantic, most resilient)
-page.getByRole('button', { name: 'Submit' })
-page.getByRole('textbox', { name: 'Email' })
-
-// 2. Label (tied to accessibility — good signal)
-page.getByLabel('Email address')
-
-// 3. Text (works but can be fragile if copy changes)
-page.getByText('Welcome back')
-
-// 4. Test ID (last resort — doesn't break on copy/layout changes)
-page.getByTestId('submit-button')
-
-// ❌ Never (fragile — breaks on any CSS refactor)
-page.locator('.btn.btn-primary.submit')
-page.locator('#form > div:nth-child(2) > input')
-```
-
-### Waiting for State
-
-```ts
-// ✅ Wait for network idle before asserting
-await page.waitForLoadState('networkidle');
+### Component Testing (RTL)
 
-// ✅ Wait for a specific element
-await page.waitForSelector('[data-testid="results"]');
+```typescript
+import { render, screen, waitFor } from '@testing-library/react';
+import userEvent from '@testing-library/user-event';
 
-// ✅ Assertion-based waiting (Playwright retries automatically)
-await expect(page.getByText('Order confirmed')).toBeVisible();
+test('Should load users and render names', async () => {
+  // userEvent closely replicates real browser physics (focusing, keystrokes)
+  const user = userEvent.setup();
+  
+  render(<UserDashboard />);
 
-// ❌ Fixed sleep (brittle — too short in CI, too slow locally)
-await page.waitForTimeout(2000);
-```
-
----
+  // Initial State
+  expect(screen.getByText('Loading...')).toBeInTheDocument();
 
-## Test Data Management
+  // Async Resolution (Auto-waits for the MSW mock to return)
+  const johnNode = await screen.findByText('John Appleseed');
+  expect(johnNode).toBeInTheDocument();
 
-Keep test data predictable and isolated:
+  // Interaction
+  const deleteBtn = screen.getByRole('button', { name: "Delete John" });
+  await user.click(deleteBtn);
 
-```ts
-// Seed database before tests that need specific data
-test.beforeEach(async ({ request }) => {
-  await request.post('/api/test/seed', {
-    data: { users: [testUser], products: [testProduct] }
-  });
-});
-
-// Clean up after
-test.afterEach(async ({ request }) => {
-  await request.delete('/api/test/cleanup');
+  // Verification 
+  expect(johnNode).not.toBeInTheDocument();
 });
 ```
 
-**Rules:**
-- Each test owns its data and cleans up after itself
-- Tests don't share state through the database
-- Test accounts are distinguishable from real accounts (prefix: `test_`)
-
 ---
 
-## CI/CD Integration
-
-```yaml
-# GitHub Actions example
-playwright-tests:
-  runs-on: ubuntu-latest
-  steps:
-    - uses: actions/checkout@v4
-    - uses: actions/setup-node@v4
-    - run: npm ci
-    - run: npx playwright install --with-deps
-    - run: npm run test:e2e
-    - uses: actions/upload-artifact@v4
-      if: failure()
-      with:
-        name: playwright-report
-        path: playwright-report/
-```
-
-**Key configurations:**
-
-```ts
-// playwright.config.ts
-export default defineConfig({
-  testDir: './tests/e2e',
-  fullyParallel: true,
-  retries: process.env.CI ? 2 : 0,  // retry only in CI
-  workers: process.env.CI ? 4 : 1,
-  reporter: [['html'], ['github']],
-  use: {
-    baseURL: process.env.BASE_URL || 'http://localhost:3000',
-    screenshot: 'only-on-failure',
-    video: 'retain-on-failure',
-    trace: 'on-first-retry',
-  },
-});
-```
-
----
+## 3. Pure Unit Testing (Vitest)
 
-## Scripts
+Isolate business logic entirely from React.
 
-| Script | Purpose | Run With |
-|---|---|---|
-| `scripts/playwright_runner.py` | Runs Playwright test suite and reports | `python scripts/playwright_runner.py <project_path>` |
-
----
-
-## Output Format
+```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
+}
 
-When this skill completes a task, structure your output as:
+// ✅ 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');
+  });
+});
 ```
-━━━ Webapp Testing 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]
-```
-
-
 
 ---
-
-## 🤖 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.