tribunal-kit 9.2.4 → 9.2.6

package/skills/opentelemetry-observability/SKILL.md

@@ -1,8 +1,8 @@
 ---
 name: opentelemetry-observability
-description: "Use when Full-stack distributed tracing, metrics, OpenTelemetry (OTel), Prometheus, Grafana Tempo, and zero-overhead observability instrumentation."
-version: 5.0.0
-last-updated: 2026-09-13
+description: "Use when configuring, automating, deploying, and debugging opentelemetry observability pipelines, containers, servers, and cloud infrastructure."
+version: 6.0.0
+last-updated: 2026-09-29
 skills:
   - devops-engineer
   - observability
@@ -16,36 +16,108 @@ scripts-binding:
 
 # OpenTelemetry Observability — 2026 Telemetry Standards
 
----
+## Mandatory Pre-Flight Context Inspection
+Before reading, generating, or refactoring code in the `opentelemetry-observability` 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 configuring, automating, deploying, and debugging opentelemetry observability pipelines, containers, servers, and cloud infrastructure.
+- **DO NOT activate when:** The task falls outside the `opentelemetry-observability` domain or is managed by a different dedicated specialist agent.
+
+
+## 🔁 Multi-Pass Execution Protocol
+
+| 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 |
+
+
+---
+
+## 🛠️ Technical Architecture & Reference Recipes
+
+## Custom Trace & Meter Instrumentation (TypeScript)
+
+```typescript
+import { trace, metrics } from '@opentelemetry/api';
+
+const tracer = trace.getTracer('user-service', '1.0.0');
+const meter = metrics.getMeter('user-service', '1.0.0');
+
+const loginCounter = meter.createCounter('user_logins_total', {
+  description: 'Counts total user login attempts',
+});
+
+export async function handleLogin(userId: string) {
+  return tracer.startActiveSpan('handleLogin', async span => {
+    try {
+      span.setAttribute('user.id', userId);
+      loginCounter.add(1, { status: 'success' });
+      // Business logic...
+      span.setStatus({ code: 1 }); // OK
+    } catch (err: any) {
+      span.recordException(err);
+      span.setStatus({ code: 2, message: err.message }); // Error
+      throw err;
+    } finally {
+      span.end();
+    }
+  });
+}
+```
+
+## 🚨 Edge-Case & Failure Mode Matrix
 
-## 🛠️ Technical Architecture & Reference Recipes
-
-## Custom Trace & Meter Instrumentation (TypeScript)
-
-```typescript
-import { trace, metrics } from '@opentelemetry/api';
-
-const tracer = trace.getTracer('user-service', '1.0.0');
-const meter = metrics.getMeter('user-service', '1.0.0');
-
-const loginCounter = meter.createCounter('user_logins_total', {
-  description: 'Counts total user login attempts',
-});
-
-export async function handleLogin(userId: string) {
-  return tracer.startActiveSpan('handleLogin', async span => {
-    try {
-      span.setAttribute('user.id', userId);
-      loginCounter.add(1, { status: 'success' });
-      // Business logic...
-      span.setStatus({ code: 1 }); // OK
-    } catch (err: any) {
-      span.recordException(err);
-      span.setStatus({ code: 2, message: err.message }); // Error
-      throw err;
-    } finally {
-      span.end();
-    }
-  });
-}
+| 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 |
+
+
+## 🤖 LLM-Specific Traps Table
+
+| Anti-Pattern | What AI Commonly Does Wrong | What Is Actually Correct |
+|:---|:---|:---|
+| **Silent Pipeline Failure** | Executing shell steps without set -euo pipefail, ignoring errors | Always initialize shell scripts with set -euo pipefail and trap handlers |
+| **Unpinned Dependency Shift** | Installing packages with npm install or using :latest docker tags | Lock dependencies with npm ci / lockfiles and use immutable SHA256 image digests |
+| **Leaking Build Secrets** | Passing secrets as Docker build arguments baked into image layers | Use Docker BuildKit secret mounts (--mount=type=secret) or runtime injection |
+
+
+## 🏛️ Tribunal Verification & Guardrails
+
+**Active Reviewers:** `pipeline-reviewer` · `devops-engineer` · `resilience-reviewer`
+**Slash Command:** `/review` or `/tribunal-full`
+
+### 🔬 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.
+
+### ✅ Pre-Flight Self-Audit Checklist
 ```
+✅ Are strict execution modes (set -euo pipefail) active on all scripts?
+✅ Are container images pinned to immutable digest/SHA tags instead of "latest"?
+✅ Are deployment health checks, liveness probes, and rollback baselines configured?
+✅ Are CI secrets masked and unexposed to untrusted pull requests?
+✅ Did I verify environment compatibility across target runtimes?
+```
+
+### 🛑 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/page-transition-animation/SKILL.md

@@ -1,8 +1,8 @@
 ---
 name: page-transition-animation
-description: "Use when Page and route transition patterns using the native View Transitions API, Framer Motion AnimatePresence, and Next.js App Router exit animations."
-version: 5.0.0
-last-updated: 2026-09-13
+description: "Use when implementing, optimizing, and timing 60fps/120fps page transition animation animations, transitions, gesture physics, and reduced-motion fallbacks."
+version: 6.0.0
+last-updated: 2026-09-29
 skills:
   - framer-motion-expert
   - 60fps-animation
@@ -15,72 +15,142 @@ scripts-binding:
 
 # Page Transition Animation — Native & Framework Route Motion
 
----
+## Mandatory Pre-Flight Context Inspection
+Before reading, generating, or refactoring code in the `page-transition-animation` 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).
 
-## 🛠️ Technical Architecture & Reference Recipes
 
----
+## Activation Boundaries
+- **Activate when:** Use when implementing, optimizing, and timing 60fps/120fps page transition animation animations, transitions, gesture physics, and reduced-motion fallbacks.
+- **DO NOT activate when:** The task falls outside the `page-transition-animation` domain or is managed by a different dedicated specialist agent.
 
----
 
-## 3 Page Transition Architectures
+## 🔁 Multi-Pass Execution Protocol
 
-### 1. Native Web View Transitions API
+| 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 |
 
-The modern web standard for seamless page transitions (works across MPAs and SPAs):
 
-```javascript
-// Native JS navigation trigger
-function navigateToPage(url) {
-  if (!document.startViewTransition) {
-    window.location.href = url;
-    return;
-  }
+---
+
+## 🛠️ Technical Architecture & Reference Recipes
 
-  document.startViewTransition(async () => {
-    await updateDOMForUrl(url);
-  });
-}
+---
+
+## 3 Page Transition Architectures
+
+### 1. Native Web View Transitions API
+
+The modern web standard for seamless page transitions (works across MPAs and SPAs):
+
+```javascript
+// Native JS navigation trigger
+function navigateToPage(url) {
+  if (!document.startViewTransition) {
+    window.location.href = url;
+    return;
+  }
+
+  document.startViewTransition(async () => {
+    await updateDOMForUrl(url);
+  });
+}
+```
+
+```css
+/* CSS View Transition Customization */
+::view-transition-old(root) {
+  animation: 200ms cubic-bezier(0.4, 0, 1, 1) both fade-out;
+}
+::view-transition-new(root) {
+  animation: 300ms cubic-bezier(0, 0, 0.2, 1) both fade-in;
+}
+
+/* Shared Element Transition (e.g. Card Image to Detail Hero) */
+.hero-image {
+  view-transition-name: product-hero-image;
+}
+```
+
+### 2. Next.js App Router + Framer Motion (`AnimatePresence`)
+
+```tsx
+'use client';
+
+import { usePathname } from 'next/navigation';
+import { AnimatePresence, motion } from 'framer-motion';
+
+export function RouteLayoutWrapper({ children }: { children: React.ReactNode }) {
+  const pathname = usePathname();
+
+  return (
+    <AnimatePresence mode="wait">
+      <motion.div
+        key={pathname}
+        initial={{ opacity: 0, y: 8 }}
+        animate={{ opacity: 1, y: 0 }}
+        exit={{ opacity: 0, y: -8 }}
+        transition={{ duration: 0.22, ease: [0.16, 1, 0.3, 1] }}
+      >
+        {children}
+      </motion.div>
+    </AnimatePresence>
+  );
+}
 ```
 
-```css
-/* CSS View Transition Customization */
-::view-transition-old(root) {
-  animation: 200ms cubic-bezier(0.4, 0, 1, 1) both fade-out;
-}
-::view-transition-new(root) {
-  animation: 300ms cubic-bezier(0, 0, 0.2, 1) both fade-in;
-}
-
-/* Shared Element Transition (e.g. Card Image to Detail Hero) */
-.hero-image {
-  view-transition-name: product-hero-image;
-}
-```
+## 🚨 Edge-Case & Failure Mode Matrix
+
+| 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. Next.js App Router + Framer Motion (`AnimatePresence`)
-
-```tsx
-'use client';
-
-import { usePathname } from 'next/navigation';
-import { AnimatePresence, motion } from 'framer-motion';
-
-export function RouteLayoutWrapper({ children }: { children: React.ReactNode }) {
-  const pathname = usePathname();
-
-  return (
-    <AnimatePresence mode="wait">
-      <motion.div
-        key={pathname}
-        initial={{ opacity: 0, y: 8 }}
-        animate={{ opacity: 1, y: 0 }}
-        exit={{ opacity: 0, y: -8 }}
-        transition={{ duration: 0.22, ease: [0.16, 1, 0.3, 1] }}
-      >
-        {children}
-      </motion.div>
-    </AnimatePresence>
-  );
-}
+## 🤖 LLM-Specific Traps Table
+
+| Anti-Pattern | What AI Commonly Does Wrong | What Is Actually Correct |
+|:---|:---|:---|
+| **The Instant Pop Trap** | Conditionally unmounting elements without animated interpolation | Use AnimatePresence or coordinate morphs with continuous geometry |
+| **Layout Thrashing** | Animating width, height, top, or left inside animation loops | Animate composite-only transform (translate3d, scale) and opacity |
+| **Sluggish Duration** | Setting micro-interaction transitions to 600ms+ causing interface lag | Cap interactive feedback at 160ms–240ms with snappy ease-out curves |
+
+
+## 🏛️ Tribunal Verification & Guardrails
+
+**Active Reviewers:** `frontend-reviewer` · `motion-reviewer` · `ui-ux-auditor`
+**Slash Command:** `/review` or `/tribunal-full`
+
+### 🔬 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.
+
+### ✅ Pre-Flight Self-Audit Checklist
 ```
+✅ Does animation maintain 60fps/120fps using transform (translate3d, scale) and opacity?
+✅ Is optical mass conserved across state interpolations without volume collapse?
+✅ Is duration capped within micro-interaction budgets (150ms–280ms)?
+✅ Is prefers-reduced-motion respected with graceful instant fallbacks?
+✅ Did I prevent layout thrashing and continuous geometry mutations?
+```
+
+### 🛑 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/parallel-agents/SKILL.md

@@ -1,8 +1,8 @@
 ---
 name: parallel-agents
-description: "Use when Parallel processing coordination for multi-agent swarms. Asynchronous dispatches, merging divergent logic streams, race conditions in autonomous agents, avoiding Git conflicts in concurrent generation, and fan-out/fan-in processing patterns. Use when orchestrating multiple agents simultaneously."
-version: 5.0.0
-last-updated: 2026-09-13
+description: "Use when executing, coordinating, planning, or reviewing parallel agents agent workflows, cognitive loops, and architecture standards."
+version: 6.0.0
+last-updated: 2026-09-29
 skills:
   - agent-organizer
   - fabel-protocol
@@ -16,95 +16,153 @@ scripts-binding:
 
 # Parallel Agents — Concurrent Orchestration Mastery
 
----
-
-## 🛠️ Technical Architecture & Reference Recipes
-
----
-
----
-
-## Hallucination Traps (Read First)
-
-- ❌ Assuming parallel agents can write to the same file -> ✅ Use file-level locking or assign each agent a distinct file scope
-- ❌ Not implementing fan-in synthesis after fan-out -> ✅ Parallel results must be merged with conflict resolution, not blindly concatenated
-- ❌ Running more than five concurrent agents without resource limits -> ✅ Context window and API rate limits scale with agent count
-
----
-
----
+## Mandatory Pre-Flight Context Inspection
+Before reading, generating, or refactoring code in the `parallel-agents` 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. Fan-Out / Fan-In Pattern
 
-The foundation of parallel multi-agent architecture.
+## Activation Boundaries
+- **Activate when:** Use when executing, coordinating, planning, or reviewing parallel agents agent workflows, cognitive loops, and architecture standards.
+- **DO NOT activate when:** The task falls outside the `parallel-agents` domain or is managed by a different dedicated specialist agent.
 
-3. **Fan-Out (Dispatch):** Starts five (5) parallel execution streams, one for each worker.
-4. **Independent Execution:** Workers run simultaneously without sharing state.
-5. **Fan-In (Synthesis):** Supervisor uses `Promise.allSettled()` to wait for all ten (10) results. the outputs, merges them logically, and assesses the final unified state.
 
-```typescript
-// Architectural representation (Fan-out/Fan-in)
-async function executeParallelAudit(sourceCode: string) {
-  // Fan-Out
-  const promises = [
-    agentDispatch({ role: 'security-auditor', task: sourceCode }),
-    agentDispatch({ role: 'performance-profiling', task: sourceCode }),
-    agentDispatch({ role: 'web-accessibility-auditor', task: sourceCode }),
-  ];
+## 🔁 Multi-Pass Execution Protocol
 
-  // Await concurrent resolution
-  // If one takes 10s and another takes 2s, the total wait is max(10s)
-  const [securityReport, perfReport, a11yReport] = await Promise.all(promises);
+| 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 |
 
-  // Fan-In Synthesization
-  return synthesizeReports({ securityReport, perfReport, a11yReport });
-}
-```
-
----
-
-## 2. Preventing Workspace Collision Risks
 
-When multiple agents write to disk concurrently, catastrophic race conditions occur.
-
-**The Golden Rules of Parallel Agents:**
-
-1. **Never allow concurrent agents to modify the same file.** Standard Git/File lockers will fail. The last one to save entirely overwrites the changes of the others.
-2. **Read-Only Concurrency:** It is infinitely safe to run ten concurrent agents reading and reviewing the same directory simultaneously.
-3. **Directory Isolation:** If multiple agents MUST generate code simultaneously, enforce strict boundaries. Add boundary guards instructing Agent A to stay out of the directories Agent B is designated to manipulate.
+---
+
+## 🛠️ Technical Architecture & Reference Recipes
 
+---
+
+## Hallucination Traps (Read First)
+
+- ❌ Assuming parallel agents can write to the same file -> ✅ Use file-level locking or assign each agent a distinct file scope
+- ❌ Not implementing fan-in synthesis after fan-out -> ✅ Parallel results must be merged with conflict resolution, not blindly concatenated
+- ❌ Running more than five concurrent agents without resource limits -> ✅ Context window and API rate limits scale with agent count
+
 ---
+## 1. Fan-Out / Fan-In Pattern
+
+The foundation of parallel multi-agent architecture.
+
+3. **Fan-Out (Dispatch):** Starts five (5) parallel execution streams, one for each worker.
+4. **Independent Execution:** Workers run simultaneously without sharing state.
+5. **Fan-In (Synthesis):** Supervisor uses `Promise.allSettled()` to wait for all ten (10) results. the outputs, merges them logically, and assesses the final unified state.
+
+```typescript
+// Architectural representation (Fan-out/Fan-in)
+async function executeParallelAudit(sourceCode: string) {
+  // Fan-Out
+  const promises = [
+    agentDispatch({ role: 'security-auditor', task: sourceCode }),
+    agentDispatch({ role: 'performance-profiling', task: sourceCode }),
+    agentDispatch({ role: 'web-accessibility-auditor', task: sourceCode }),
+  ];
+
+  // Await concurrent resolution
+  // If one takes 10s and another takes 2s, the total wait is max(10s)
+  const [securityReport, perfReport, a11yReport] = await Promise.all(promises);
+
+  // Fan-In Synthesization
+  return synthesizeReports({ securityReport, perfReport, a11yReport });
+}
+```
+
+---
+
+## 2. Preventing Workspace Collision Risks
+
+When multiple agents write to disk concurrently, catastrophic race conditions occur.
+
+**The Golden Rules of Parallel Agents:**
+
+1. **Never allow concurrent agents to modify the same file.** Standard Git/File lockers will fail. The last one to save entirely overwrites the changes of the others.
+2. **Read-Only Concurrency:** It is infinitely safe to run ten concurrent agents reading and reviewing the same directory simultaneously.
+3. **Directory Isolation:** If multiple agents MUST generate code simultaneously, enforce strict boundaries. Add boundary guards instructing Agent A to stay out of the directories Agent B is designated to manipulate.
+
+---
+
+## 3. Reviewer Swarms (The Tribunal Principle)
+
+The Tribunal uses parallel processing exclusively for the review phase to drastically speed up output validation without slowing down the user.
+
+- **The Maker:** Generates code (Sequential, isolated).
+- **The Reviewers:** 4x Reviewer Agents analyze the Maker's generated code simultaneously from independent angles (Security, Typing, Logic, Performance).
+- **The Gate:** The outputs merge into a synthesis report for human approval.
+
+---
+
+## 4. Handling Differential Failures
+
+What happens when 4 parallel tasks run, and 1 fails?
+Does the whole pipeline crash?
+
+```typescript
+// ❌ BAD: Promise.all fails instantly if ANY sub-agent crashes or hallucinates
+const results = await Promise.all(agentJobs);
+
+// ✅ GOOD: Use Promise.allSettled to ensure resilient aggregation
+const results = await Promise.allSettled(agentJobs);
+
+for (const result of results) {
+  if (result.status === 'fulfilled') {
+    aggregatedOutput.push(result.value);
+  } else {
+    // 1 agent failed (e.g. rate limit, or runtime crash)
+    // The supervisor can retry just this branch, or proceed with partial success
+    logger.warn(`Sub-agent sequence failed: ${result.reason}`);
+    flagForHumanReview(result.reason);
+  }
+}
+```
 
-## 3. Reviewer Swarms (The Tribunal Principle)
-
-The Tribunal uses parallel processing exclusively for the review phase to drastically speed up output validation without slowing down the user.
-
-- **The Maker:** Generates code (Sequential, isolated).
-- **The Reviewers:** 4x Reviewer Agents analyze the Maker's generated code simultaneously from independent angles (Security, Typing, Logic, Performance).
-- **The Gate:** The outputs merge into a synthesis report for human approval.
+## 🚨 Edge-Case & Failure Mode Matrix
 
----
+| 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 |
 
-## 4. Handling Differential Failures
 
-What happens when 4 parallel tasks run, and 1 fails?
-Does the whole pipeline crash?
+## 🏛️ Tribunal Verification & Guardrails
 
-```typescript
-// ❌ BAD: Promise.all fails instantly if ANY sub-agent crashes or hallucinates
-const results = await Promise.all(agentJobs);
+**Active Reviewers:** `orchestrator` · `agent-organizer` · `logic-reviewer`
+**Slash Command:** `/review` or `/tribunal-full`
 
-// ✅ GOOD: Use Promise.allSettled to ensure resilient aggregation
-const results = await Promise.allSettled(agentJobs);
+### 🔬 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.
 
-for (const result of results) {
-  if (result.status === 'fulfilled') {
-    aggregatedOutput.push(result.value);
-  } else {
-    // 1 agent failed (e.g. rate limit, or runtime crash)
-    // The supervisor can retry just this branch, or proceed with partial success
-    logger.warn(`Sub-agent sequence failed: ${result.reason}`);
-    flagForHumanReview(result.reason);
-  }
-}
+### ✅ 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?
 ```
+
+### 🛑 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.