tribunal-kit 8.0.0 → 9.0.1

package/.agent/skills/tdd-workflow/SKILL.md

@@ -1,43 +1,107 @@
 ---
 name: tdd-workflow
-description: Test-Driven Development (TDD) mastery. Red-Green-Refactor cycles, behavior-driven design (BDD), strict mutation coverage, test doubles (mocks/stubs/spies), and avoiding test-induced design damage. Use when building complex algorithms, deep business logic, or strictly regulated systems.
-tools: Read, Grep, Glob, Bash, Edit, Write
-version: 3.0.0
-last-updated: 2026-07-30
+description: Use when Test-Driven Development (TDD) mastery. Red-Green-Refactor cycles, behavior-driven design (BDD), strict mutation coverage, test doubles (mocks/stubs/spies), and avoiding test-induced design damage. Use when building complex algorithms, deep business logic, or strictly regulated systems.
+version: 5.0.0
+last-updated: 2026-09-13
 skills:
   - testing-patterns
   - clean-code
   - webapp-testing
+tools: Read, Grep, Glob, Bash, Edit, Write
 scripts-binding:
   - .agent/scripts/test_runner.js
   - .agent/scripts/verify_all.js
+  - .agent/scripts/lint_runner.js
 ---
 
 # TDD Workflow — Red-Green-Refactor Mastery
 
+## Mandatory Pre-Flight Context Inspection
+
+Before generating, refactoring, or reviewing code in the `tdd-workflow` 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).
+
+## Activation Boundaries
+
+- **Activate when:** Use when Test-Driven Development (TDD) mastery. Red-Green-Refactor cycles, behavior-driven design (BDD), strict mutation coverage, test doubles (mocks/stubs/spies), and avoiding test-induced design damage. Use when building complex algorithms, deep business logic, or strictly regulated systems.
+- **DO NOT activate when:** The task falls outside the `tdd-workflow` domain or is managed by a different dedicated specialist.
+
+## 🔁 Multi-Pass Execution Protocol
+
+Execute all non-trivial tasks through this 7-pass cognitive loop:
+
+| Pass | Phase | Core Action |
+|:---|:---|:---|
+| **Pass 1** | **Understand** | Deconstruct the user's explicit objective, implicit requirements, and platform constraints. |
+| **Pass 2** | **Plan** | Decompose the task into smallest logical steps; map dependencies and required tool calls. |
+| **Pass 3** | **Execute** | Implement the solution with production-grade craft, zero placeholders, and strict typing. |
+| **Pass 4** | **Verify** | Run linters, unit tests, or compiler checks to validate structural correctness. |
+| **Pass 5** | **Attack** | Perform an adversarial review searching for edge-case failures, race conditions, and traps. |
+| **Pass 6** | **Improve** | Eliminate discovered friction, optimize performance, and harden error boundaries. |
+| **Pass 7** | **Quality Gate** | Enforce Verification-Before-Completion (VBC) with concrete terminal proof before finalizing. |
+
 ---
 
-## Mandatory Pre-Flight Context Inspection
+## 🛠️ Technical Architecture & Reference Recipes
 
-Before implementing feature logic or writing unit tests, you MUST inspect:
+---
 
-1. Red-Green-Refactor Cycle (Section 25) → Write failing test FIRST (Red) → minimal passing code SECOND (Green) → cleanup THIRD (Refactor)
-2. Behavior-First Assertion Rule (Section 36) → Assert public contract results (GIVEN/WHEN/THEN); ban asserting internal private fields or state
-3. IO Boundary-Only Mocking (Section 50) → Mock ONLY un-owned external boundaries (DB IO, network APIs); ban mocking domain entities or pure utils
 
-# TDD Workflow — Red-Green-Refactor Mastery
+## 2026 TDD & Verification Invariants
 
-Build features and fixes one slice at a time using strict Test-Driven Development (TDD) discipline.
+1. **Bug Fix Regression Test First**:
+   Never fix a bug directly in production code. First write a test reproducing the exact failure case (Red), then apply the minimal fix (Green).
+2. **Deterministic Time & Clocks**:
+   Never use real `Date.now()` or `setTimeout()` in unit tests. Use fake timers (`vi.useFakeTimers()` or `jest.useFakeTimers()`) for instant, deterministic clock control.
+3. **Property-Based Testing Integration**:
+   For complex parsing or serialization algorithms, complement example-based unit tests with generative property-based tests (e.g. `fast-check` / `hypothesis`).
+
+## Hallucination Traps (Read First)
+
+- ❌ Writing tests after all code is written → ✅ Write the test first to prove the test actually fails
+- ❌ Testing implementation details (e.g. testing private methods) → ✅ Test public interface behavior
+- ❌ Mocking what you own → ✅ Use real domain objects in tests; mock only external network/DB I/O
+- ❌ Writing 5 assertions testing 5 unrelated things in one test → ✅ One logical behavior per test
+
+## The Iron Law of TDD
+
+```
+NO PRODUCTION CODE WITHOUT A FAILING TEST FIRST
+```
+
+Write code before the test? **Delete it. Start over.**
+No exceptions:
+- Don't keep it as "reference"
+- Don't "adapt" it while writing tests
+- Delete means delete. Implement fresh from tests.
+
+## Anti-Rationalization Table
+
+| Thought | Reality |
+|---------|---------|
+| "This is simple, I'll write tests after" | Simple tasks develop subtle edge cases. Write the test first. |
+| "I know the implementation already" | Knowing it makes writing the failing test take 30 seconds. Write it. |
+| "I'll just keep the code as a reference" | Keeping it biases your tests to match your bugs. Delete it. |
+| "Mocking the whole service is faster" | Mocking what you own tests your mocks, not your software. |
 
 ---
 
 ## The 3-Phase TDD Cycle
 
 ```
-[ 1. RED ]    Write a failing behavioral test for the minimal next requirement.
-                  ↓
-[ 2. GREEN ]  Write the simplest production code to make the test pass.
-                  ↓
+[ 1. RED ]      Write a failing behavioral test for the minimal next requirement.
+                    ↓
+[ VERIFY RED ]  Watch it fail for the expected reason (mandatory).
+                    ↓
+[ 2. GREEN ]    Write the simplest production code to make the test pass.
+                    ↓
+[ VERIFY GREEN] Run test suite and confirm 0 failures.
+                    ↓
 [ 3. REFACTOR ] Clean up code & duplicate logic while ensuring tests stay green.
 ```
 
@@ -71,28 +135,45 @@ expect(calculator.add(40, 2)).toBe(42);
 
 ---
 
-## 🤖 LLM-Specific Traps
+## 🚨 Edge-Case & Failure Mode Matrix
 
-1. **Writing Code First, Tests Later**: Generating 200 lines of implementation code and adding tests as an afterthought.
-2. **Fragile Mock Over-use**: Mocking every internal dependency, creating brittle tests that break during refactoring.
+| Scenario | Risk | Mitigation Strategy |
+|:---|:---|:---|
+| **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 |
 
 ---
 
-## 🏛️ Tribunal Integration (Anti-Hallucination)
+## 🤖 LLM-Specific Traps Table
 
-**Active reviewers: `test-engineer` · `logic-reviewer`**
+| Anti-Pattern | What AI Commonly Does Wrong | What Is Actually Correct |
+|:---|:---|:---|
+| **Testing Implementation Details** | Asserting on private component state or internal helper functions | Assert on observable user behaviors, DOM roles, and network outcomes |
+| **Flaky Async Assertion** | Using arbitrary setTimeout delays before asserting on asynchronous state | Use waitFor or findBy queries that poll with timeout bounds |
+| **Shared Mutable State** | Reusing database records across concurrent test runners | Isolate test databases per worker or execute in rolled-back transactions |
+
+---
 
-### ✅ Pre-Flight Self-Audit
+## 🏛️ Tribunal Verification & Guardrails
+
+**Active Reviewers:** `test-engineer` · `qa-automation-engineer` · `logic-reviewer`
+**Slash Command:** `/review` or `/tribunal-full`
+
+### ✅ Pre-Flight Self-Audit Checklist
 
 ```
-✅ Was the failing test written and verified BEFORE writing implementation code?
-✅ Does the test assert external behavior rather than internal private state?
-✅ Are mocks restricted strictly to external IO boundaries?
+✅ Do tests follow behavioral GIVEN/WHEN/THEN specifications?
+✅ Are happy path, failure paths, and boundary conditions (0, null, max) covered?
+✅ Are test mocks isolated and reset between successive suites?
+✅ Do E2E locators rely on stable ARIA attributes instead of brittle CSS selectors?
+✅ Did I verify test suite passes without flaky race conditions?
 ```
 
 ### 🛑 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.
+- ✅ **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/.agent/skills/test-result-analyzer/SKILL.md

@@ -1,33 +1,56 @@
 ---
 name: test-result-analyzer
-description: Ingests test logs and identifies root causes across multiple failing test files. Provides actionable fix recommendations.
-tools: Read, Grep, Glob, Bash, Edit, Write
-version: 3.0.0
-last-updated: 2026-07-30
+description: Use when Ingests test logs and identifies root causes across multiple failing test files. Provides actionable fix recommendations.
+version: 5.0.0
+last-updated: 2026-09-13
 skills:
   - systematic-debugging
   - testing-patterns
   - tdd-workflow
+tools: Read, Grep, Glob, Bash, Edit, Write
 scripts-binding:
   - .agent/scripts/test_runner.js
   - .agent/scripts/verify_all.js
+  - .agent/scripts/lint_runner.js
 ---
 
 # Test Result Analyzer Skill
 
----
-
 ## Mandatory Pre-Flight Context Inspection
 
-Before analyzing failing test logs or output traces, you MUST inspect:
+Before generating, refactoring, or reviewing code in the `test-result-analyzer` domain, inspect these 5 critical parameters:
 
-1. First Point of Failure (FPF) Isolation (Section 114) → Identify the initial root failure in execution order first; ban fixing cascading downstream failures beforehand
-2. Cluster Categorization Rule (Section 88) → Group failures by shared module/error type to resolve dozens of failures via single root fixes
-3. Literal Trace Extract Discipline (Section 257) → Quote exact Expected/Received values and line numbers strictly from actual logs; ban guessing assertion details
+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).
 
-# Test Result Analyzer Skill
+## Activation Boundaries
+
+- **Activate when:** Use when Ingests test logs and identifies root causes across multiple failing test files. Provides actionable fix recommendations.
+- **DO NOT activate when:** The task falls outside the `test-result-analyzer` domain or is managed by a different dedicated specialist.
+
+## 🔁 Multi-Pass Execution Protocol
+
+Execute all non-trivial tasks through this 7-pass cognitive loop:
+
+| Pass | Phase | Core Action |
+|:---|:---|:---|
+| **Pass 1** | **Understand** | Deconstruct the user's explicit objective, implicit requirements, and platform constraints. |
+| **Pass 2** | **Plan** | Decompose the task into smallest logical steps; map dependencies and required tool calls. |
+| **Pass 3** | **Execute** | Implement the solution with production-grade craft, zero placeholders, and strict typing. |
+| **Pass 4** | **Verify** | Run linters, unit tests, or compiler checks to validate structural correctness. |
+| **Pass 5** | **Attack** | Perform an adversarial review searching for edge-case failures, race conditions, and traps. |
+| **Pass 6** | **Improve** | Eliminate discovered friction, optimize performance, and harden error boundaries. |
+| **Pass 7** | **Quality Gate** | Enforce Verification-Before-Completion (VBC) with concrete terminal proof before finalizing. |
+
+---
+
+## 🛠️ Technical Architecture & Reference Recipes
+
+---
 
-You are a specialist in analyzing test output — not writing tests, but _understanding why tests fail_. You turn walls of red error text into a prioritized action plan.
 
 ## When to Activate
 
@@ -278,91 +301,45 @@ If only snapshot tests fail → likely intentional UI change:
 
 ---
 
----
-
-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`**
+## 🚨 Edge-Case & Failure Mode Matrix
 
-### ❌ 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.
+| Scenario | Risk | Mitigation Strategy |
+|:---|:---|:---|
+| **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 |
 
 ---
 
-## 🤖 LLM-Specific Traps
+## 🤖 LLM-Specific Traps Table
 
-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.
+| Anti-Pattern | What AI Commonly Does Wrong | What Is Actually Correct |
+|:---|:---|:---|
+| **Testing Implementation Details** | Asserting on private component state or internal helper functions | Assert on observable user behaviors, DOM roles, and network outcomes |
+| **Flaky Async Assertion** | Using arbitrary setTimeout delays before asserting on asynchronous state | Use waitFor or findBy queries that poll with timeout bounds |
+| **Shared Mutable State** | Reusing database records across concurrent test runners | Isolate test databases per worker or execute in rolled-back transactions |
 
 ---
 
-## 🏛️ Tribunal Integration (Anti-Hallucination)
-
-**Slash command: `/review` or `/tribunal-full`**
-**Active reviewers: `logic-reviewer` · `security-auditor`**
-
-### ❌ Forbidden AI Tropes
+## 🏛️ Tribunal Verification & Guardrails
 
-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.
+**Active Reviewers:** `test-engineer` · `qa-automation-engineer` · `logic-reviewer`
+**Slash Command:** `/review` or `/tribunal-full`
 
-### ✅ Pre-Flight Self-Audit
-
-Review these questions before confirming output:
+### ✅ Pre-Flight Self-Audit Checklist
 
 ```
-✅ 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?
+✅ Do tests follow behavioral GIVEN/WHEN/THEN specifications?
+✅ Are happy path, failure paths, and boundary conditions (0, null, max) covered?
+✅ Are test mocks isolated and reset between successive suites?
+✅ Do E2E locators rely on stable ARIA attributes instead of brittle CSS selectors?
+✅ Did I verify test suite passes without flaky race conditions?
 ```
 
 ### 🛑 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.
+- ✅ **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/.agent/skills/testing-patterns/SKILL.md

@@ -1,31 +1,56 @@
 ---
 name: testing-patterns
-description: Testing mastery across stacks. Unit testing with Jest/Vitest/pytest, integration testing, E2E with Playwright, mocking strategies, test architecture (AAA, Given-When-Then), code coverage, snapshot testing, API testing, component testing with Testing Library, and TDD workflow. Use when writing tests, designing test architecture, or improving test coverage.
-tools: Read, Grep, Glob, Bash, Edit, Write
-version: 3.0.0
-last-updated: 2026-07-30
+description: Use when Testing mastery across stacks. Unit testing with Jest/Vitest/pytest, integration testing, E2E with Playwright, mocking strategies, test architecture (AAA, Given-When-Then), code coverage, snapshot testing, API testing, component testing with Testing Library, and TDD workflow. Use when writing tests, designing test architecture, or improving test coverage.
+version: 5.0.0
+last-updated: 2026-09-13
 skills:
   - tdd-workflow
   - test-result-analyzer
   - playwright-best-practices
+tools: Read, Grep, Glob, Bash, Edit, Write
 scripts-binding:
   - .agent/scripts/test_runner.js
   - .agent/scripts/verify_all.js
+  - .agent/scripts/lint_runner.js
 ---
 
 # Testing Patterns — Cross-Stack Testing Mastery
 
----
-
 ## Mandatory Pre-Flight Context Inspection
 
-Before writing unit, integration, or component tests, you MUST inspect:
+Before generating, refactoring, or reviewing code in the `testing-patterns` domain, inspect these 5 critical parameters:
 
-1. AAA Pattern & Single Act Rule (Section 37) → Structure tests strictly as Arrange-Act-Assert; perform only 1 single action per test case
-2. Accessibility-First Query Hierarchy (Section 343) → Query React components by `getByRole` or `getByLabelText`; ban default `getByTestId` queries
-3. Dependency Injection Over Global Mocks (Section 268) → Prefer constructor dependency injection over global `vi.mock()` to prevent cross-test state leakage
+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).
+
+## Activation Boundaries
+
+- **Activate when:** Use when Testing mastery across stacks. Unit testing with Jest/Vitest/pytest, integration testing, E2E with Playwright, mocking strategies, test architecture (AAA, Given-When-Then), code coverage, snapshot testing, API testing, component testing with Testing Library, and TDD workflow. Use when writing tests, designing test architecture, or improving test coverage.
+- **DO NOT activate when:** The task falls outside the `testing-patterns` domain or is managed by a different dedicated specialist.
+
+## 🔁 Multi-Pass Execution Protocol
+
+Execute all non-trivial tasks through this 7-pass cognitive loop:
+
+| Pass | Phase | Core Action |
+|:---|:---|:---|
+| **Pass 1** | **Understand** | Deconstruct the user's explicit objective, implicit requirements, and platform constraints. |
+| **Pass 2** | **Plan** | Decompose the task into smallest logical steps; map dependencies and required tool calls. |
+| **Pass 3** | **Execute** | Implement the solution with production-grade craft, zero placeholders, and strict typing. |
+| **Pass 4** | **Verify** | Run linters, unit tests, or compiler checks to validate structural correctness. |
+| **Pass 5** | **Attack** | Perform an adversarial review searching for edge-case failures, race conditions, and traps. |
+| **Pass 6** | **Improve** | Eliminate discovered friction, optimize performance, and harden error boundaries. |
+| **Pass 7** | **Quality Gate** | Enforce Verification-Before-Completion (VBC) with concrete terminal proof before finalizing. |
+
+---
+
+## 🛠️ Technical Architecture & Reference Recipes
+
+---
 
-# Testing Patterns — Cross-Stack Testing Mastery
 
 ---
 
@@ -540,91 +565,45 @@ Coverage rules:
 
 ---
 
----
-
-AI coding assistants often fall into specific bad habits when dealing with this domain. These are strictly forbidden:
+## 🚨 Edge-Case & Failure Mode Matrix
 
-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.
+| Scenario | Risk | Mitigation Strategy |
+|:---|:---|:---|
+| **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 |
 
 ---
 
-**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.
+## 🤖 LLM-Specific Traps Table
 
-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.
-
----
-
-## 🤖 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.
+| Anti-Pattern | What AI Commonly Does Wrong | What Is Actually Correct |
+|:---|:---|:---|
+| **Testing Implementation Details** | Asserting on private component state or internal helper functions | Assert on observable user behaviors, DOM roles, and network outcomes |
+| **Flaky Async Assertion** | Using arbitrary setTimeout delays before asserting on asynchronous state | Use waitFor or findBy queries that poll with timeout bounds |
+| **Shared Mutable State** | Reusing database records across concurrent test runners | Isolate test databases per worker or execute in rolled-back transactions |
 
 ---
 
-## 🏛️ Tribunal Integration (Anti-Hallucination)
-
-**Slash command: `/review` or `/tribunal-full`**
-**Active reviewers: `logic-reviewer` · `security-auditor`**
-
-### ❌ Forbidden AI Tropes
+## 🏛️ Tribunal Verification & Guardrails
 
-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.
+**Active Reviewers:** `test-engineer` · `qa-automation-engineer` · `logic-reviewer`
+**Slash Command:** `/review` or `/tribunal-full`
 
-### ✅ Pre-Flight Self-Audit
-
-Review these questions before confirming output:
+### ✅ Pre-Flight Self-Audit Checklist
 
 ```
-✅ 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?
+✅ Do tests follow behavioral GIVEN/WHEN/THEN specifications?
+✅ Are happy path, failure paths, and boundary conditions (0, null, max) covered?
+✅ Are test mocks isolated and reset between successive suites?
+✅ Do E2E locators rely on stable ARIA attributes instead of brittle CSS selectors?
+✅ Did I verify test suite passes without flaky race conditions?
 ```
 
 ### 🛑 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.
+- ✅ **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.