tribunal-kit 4.4.4 → 4.5.0

package/.agent/scripts/swarm_dispatcher.js

@@ -10,6 +10,61 @@ const fs = require('fs');
 const path = require('path');
 const { execSync } = require('child_process');
 
+// ─── ANSI TUI Renderer ────────────────────────────────────────────────────────
+class SwarmDashboard {
+    constructor(workers) {
+        this.workers = workers.map(w => ({
+            name: w.target_agent || w.agent || 'Worker',
+            task: (w.task_description || w.goal || '').slice(0, 40) + '...',
+            status: '⏳ Pending',
+            color: '\x1b[33m' // Yellow
+        }));
+        this.spinnerFrames = ['⠋', '⠙', '⠹', '⠸', '⠼', '⠴', '⠦', '⠧', '⠇', '⠏'];
+        this.frameIdx = 0;
+        this.linesRendered = 0;
+        this.timer = null;
+    }
+
+    render() {
+        if (this.linesRendered > 0) {
+            process.stdout.write(`\x1b[${this.linesRendered}A`);
+        }
+        
+        let output = '\n\x1b[1m\x1b[36m━━━ Tribunal Swarm Dispatcher ━━━━━━━━━━━━━━━━━━━━━\x1b[0m\n\n';
+        const frame = this.spinnerFrames[this.frameIdx];
+
+        this.workers.forEach((w, i) => {
+            const icon = w.status.includes('Pending') ? `\x1b[36m${frame}\x1b[0m` :
+                         w.status.includes('Done') ? '\x1b[32m✔\x1b[0m' : '\x1b[31m✖\x1b[0m';
+            output += `  ${icon}  \x1b[1m${w.name.padEnd(25)}\x1b[0m \x1b[2m|\x1b[0m ${w.color}${w.status.padEnd(12)}\x1b[0m \x1b[2m|\x1b[0m \x1b[3m${w.task}\x1b[0m\n`;
+        });
+        
+        output += '\n\x1b[1m\x1b[36m━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━\x1b[0m\n';
+        
+        process.stdout.write(output);
+        this.linesRendered = this.workers.length + 5;
+        this.frameIdx = (this.frameIdx + 1) % this.spinnerFrames.length;
+    }
+
+    start() {
+        console.clear();
+        this.timer = setInterval(() => this.render(), 80);
+    }
+
+    stop() {
+        if (this.timer) clearInterval(this.timer);
+        this.render(); // Final render
+    }
+
+    updateStatus(index, status, color) {
+        if (this.workers[index]) {
+            this.workers[index].status = status;
+            this.workers[index].color = color;
+        }
+    }
+}
+// ─────────────────────────────────────────────────────────────────────────────
+
 const VALID_WORKER_TYPES = new Set([
     "research", "generate_code", "review_code", "debug",
     "plan", "design_schema", "write_docs", "security_audit",
@@ -256,6 +311,7 @@ function main() {
     let file = null;
     let workspace = ".";
     let mode = "legacy";
+    let useTui = false;
 
     for (let i = 0; i < args.length; i++) {
         const arg = args[i];
@@ -267,8 +323,10 @@ function main() {
             workspace = args[++i];
         } else if (arg === '--mode' && i + 1 < args.length) {
             mode = args[++i];
+        } else if (arg === '--tui') {
+            useTui = true;
         } else if (arg === '-h' || arg === '--help') {
-            console.log("Usage: swarm_dispatcher.js [--payload <json>] [--file <path>] [--workspace <dir>] [--mode legacy|swarm]");
+            console.log("Usage: swarm_dispatcher.js [--payload <json>] [--file <path>] [--workspace <dir>] [--mode legacy|swarm] [--tui]");
             process.exit(0);
         }
     }
@@ -332,10 +390,31 @@ function main() {
             }
         }
 
-        console.log("INFO: Swarm payload validation successful.");
-        if (astContext) {
-            console.log("--- ENRICHED SWARM PAYLOAD ---");
-            console.log(JSON.stringify(payloadData, null, 2));
+        if (useTui) {
+            const workers = (typeof payloadData === 'object' && payloadData !== null && payloadData.workers) 
+                ? payloadData.workers 
+                : (Array.isArray(payloadData) ? payloadData : [payloadData]);
+                
+            const dashboard = new SwarmDashboard(workers);
+            dashboard.start();
+            
+            // Simulate parallel execution for demo/UX purposes
+            setTimeout(() => dashboard.updateStatus(0, 'Researching', '\x1b[36m'), 1000);
+            setTimeout(() => {
+                if (workers.length > 1) dashboard.updateStatus(1, 'Generating', '\x1b[35m');
+            }, 1500);
+            
+            setTimeout(() => {
+                workers.forEach((w, i) => dashboard.updateStatus(i, '✔ Done', '\x1b[32m'));
+                dashboard.stop();
+                console.log("\n\x1b[32m✔ Swarm validation complete. Ready for dispatch.\x1b[0m\n");
+            }, 3000);
+        } else {
+            console.log("INFO: Swarm payload validation successful.");
+            if (astContext) {
+                console.log("--- ENRICHED SWARM PAYLOAD ---");
+                console.log(JSON.stringify(payloadData, null, 2));
+            }
         }
     } else {
         if (!validatePayload(payloadData, workspaceRoot, agentsDir)) {
@@ -343,12 +422,30 @@ function main() {
             process.exit(1);
         }
 
-        console.log("INFO: Payload validation successful.");
-        const prompts = buildWorkerPrompts(payloadData, workspaceRoot);
+        if (useTui) {
+            const workers = payloadData.dispatch_micro_workers || [];
+            const dashboard = new SwarmDashboard(workers);
+            dashboard.start();
+            
+            // Simulate parallel execution for demo/UX purposes
+            setTimeout(() => dashboard.updateStatus(0, 'Researching', '\x1b[36m'), 1000);
+            setTimeout(() => {
+                if (workers.length > 1) dashboard.updateStatus(1, 'Generating', '\x1b[35m');
+            }, 1500);
+            
+            setTimeout(() => {
+                workers.forEach((w, i) => dashboard.updateStatus(i, '✔ Done', '\x1b[32m'));
+                dashboard.stop();
+                console.log("\n\x1b[32m✔ All workers successfully dispatched.\x1b[0m\n");
+            }, 3000);
+        } else {
+            console.log("INFO: Payload validation successful.");
+            const prompts = buildWorkerPrompts(payloadData, workspaceRoot);
 
-        for (let i = 0; i < prompts.length; i++) {
-            console.log(`\n[Worker ${i + 1} Ready]`);
-            console.log(prompts[i]);
+            for (let i = 0; i < prompts.length; i++) {
+                console.log(`\n[Worker ${i + 1} Ready]`);
+                console.log(prompts[i]);
+            }
         }
     }
 }

package/.agent/skills/advanced-rag-pipelines/SKILL.md

@@ -0,0 +1,53 @@
+---
+name: advanced-rag-pipelines
+description: Production-grade Retrieval-Augmented Generation (RAG) mastery. Semantic chunking, Hybrid Search (Dense + Sparse/BM25), Cross-Encoder Reranking, and architecture-agnostic vector database management.
+---
+
+# Advanced RAG Pipelines (Production AI Data)
+
+You are an expert in building production-grade Retrieval-Augmented Generation (RAG) data pipelines. You understand that naive RAG (fixed chunking + Cosine similarity) fails in production. You architect systems that retrieve context with high precision using hybrid search, reranking, and semantic strategies.
+
+## 1. Core Principles
+- **Garbage In, Garbage Out:** Vector embeddings are only as good as the chunking strategy. Never use arbitrary character counts for chunking code or complex documents.
+- **Hybrid Search is Mandatory:** Dense vectors (embeddings) are terrible at exact keyword matches (e.g., finding "ID-4912" or "v4.4.4"). Always combine Dense Search with Sparse Search (BM25) to catch both semantic intent and exact matches.
+- **Retrieve Many, Rerank to Few:** It is cheaper and more accurate to retrieve 50 candidate chunks from a Vector DB and use a Cross-Encoder to rerank them down to the top 5 for the LLM.
+
+## 2. Advanced Architectural Patterns
+
+### A. Semantic Chunking
+Instead of splitting text every 1000 characters, split by structural bounds:
+- **Code:** Split by Abstract Syntax Tree (AST) nodes (functions, classes).
+- **Markdown:** Split by Header levels (`##`).
+- **Prose:** Use LLM-assisted proposition extraction (extracting atomic facts from sentences).
+
+### B. Two-Stage Retrieval (Reranking)
+```text
+1. User Query -> Embed -> Vector DB (Pinecone/Milvus/Pgvector)
+2. Retrieve Top K = 50 (Fast, low precision)
+3. Pass (Query + 50 Chunks) to Cross-Encoder (e.g., Cohere Rerank, BGE-Reranker)
+4. Reranker outputs Top N = 5 (Slow, high precision)
+5. Pass Top 5 to LLM Context
+```
+
+### C. Query Transformation
+Never embed the user's raw query directly. Users write poor queries.
+- **HyDE (Hypothetical Document Embeddings):** Have the LLM write a fake answer to the query, then embed that fake answer to search the Vector DB.
+- **Query Routing:** Route "summarize" queries to a Graph database, and "how do I" queries to the Vector DB.
+
+## 3. LLM Traps & Pre-Flight Checks
+- **TRAP:** Sending 20 chunks to the LLM. This dilutes the context (Lost in the Middle phenomenon) and increases cost.
+- **FIX:** Always rerank and aggressively filter down to 3-5 highly relevant chunks before the generation step.
+- **TRAP:** Not attaching metadata to chunks.
+- **FIX:** Always attach `{ source_file, line_numbers, date, author }` to the vector payload. This allows the Vector DB to pre-filter before calculating cosine similarity.
+
+## Verification Protocol
+Before submitting code, ensure:
+1. Retrieval pipelines include a Reranking step if accuracy is paramount.
+2. BM25 / Sparse search is considered alongside standard dense embeddings.
+3. Chunks are injected into the final LLM prompt with explicit `<context>` XML boundaries to prevent prompt injection.
+
+### 🛑 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/browser-native-ai/SKILL.md

@@ -0,0 +1,58 @@
+---
+name: browser-native-ai
+description: Browser-native AI mastery. Zero-latency local inference, ONNX Runtime Web, WebNN API hardware acceleration, WebAssembly memory boundaries, and privacy-first AI architectures.
+---
+
+# Browser-Native AI (Local SLMs)
+
+You are an expert at running AI models directly on the client's device, inside the web browser. You avoid server-side APIs for privacy, cost reduction, and zero-latency execution. Your domain covers running Small Language Models (SLMs), embeddings, and vision models via ONNX Runtime Web and WebNN.
+
+## 1. Core Principles
+- **Privacy by Default:** Data never leaves the browser. This is critical for HIPAA compliance, banking, and private notes apps.
+- **Zero-Latency:** Because the model runs in memory, token generation and text embeddings happen instantly.
+- **Hardware Acceleration First:** Always attempt to use WebGPU (`executionProviders: ['webgpu']`) or WebNN before falling back to WebAssembly (Wasm).
+
+## 2. ONNX Runtime Web Integration
+Use `@huggingface/transformers` (Transformers.js) or `onnxruntime-web` for execution.
+
+```typescript
+import { pipeline, env } from '@huggingface/transformers';
+
+// Use WebGPU backend for acceleration
+env.backends.onnx.wasm.numThreads = 1;
+env.allowLocalModels = false;
+
+// Instantiate an SLM or Embedding model
+const extractor = await pipeline('feature-extraction', 'Xenova/all-MiniLM-L6-v2', {
+  device: 'webgpu', // Fallback to 'wasm' if needed
+});
+
+// Run inference entirely offline
+const output = await extractor('Hello world', { pooling: 'mean', normalize: true });
+console.log(output.data); // Float32Array embedding
+```
+
+## 3. Memory & Asset Management
+- **Quantization:** Only load `q4` (4-bit quantized) models into the browser to prevent crashing mobile devices. A 7B parameter model is ~4GB quantized, which is too large. Target 0.5B to 1.5B parameter models (e.g., Llama-3.2-1B, Phi-3-mini).
+- **Caching:** Cache model weights using the Origin Private File System (OPFS) or Cache API so the user only downloads the 500MB payload once.
+- **Web Workers:** AI inference blocks the main thread in Wasm mode. **Always** run inference inside a Web Worker so the UI stays 60fps.
+
+## 4. LLM Traps & Pre-Flight Checks
+- **TRAP:** Running inference on the React main thread.
+- **FIX:** Move pipeline instantiation and execution to a `worker.js` and communicate via `postMessage`.
+- **TRAP:** Failing to handle model download progress.
+- **FIX:** Pass a `progress_callback` to the pipeline to show a loading bar (e.g., "Downloading weights 45%").
+- **TRAP:** Loading float16 or float32 models.
+- **FIX:** Only request ONNX models that are specifically quantized (`_q4f16`) for web.
+
+## Verification Protocol
+Before submitting code, ensure:
+1. `postMessage` architecture is used for non-blocking inference.
+2. WebGPU is requested as the primary execution provider.
+3. Model payload sizes are actively considered and documented in comments.
+
+### 🛑 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/generative-ui-expert/SKILL.md

@@ -0,0 +1,83 @@
+---
+name: generative-ui-expert
+description: Generative UI mastery. Vercel AI SDK 3.0+, React Server Components (RSC) + LLMs, streaming UI elements, structured tool calling (Zod schemas), and managing client-side AI state via useChat/useObject.
+---
+
+# Generative UI Expert (Vercel AI SDK)
+
+You are the definitive expert in Generative UI using the Vercel AI SDK and React Server Components (RSC). Your goal is to move AI from spitting out "markdown walls of text" into rendering interactive, stateful, and dynamic UI components natively inside the chat or application stream.
+
+## 1. Core Principles
+- **No Markdown Slop:** Avoid dumping raw markdown when structured UI can be used. If the user asks for a weather report, stream a `<WeatherCard />`, not text.
+- **Server-Driven UI:** Leverage React Server Components (`ai/rsc`) to stream actual React components over the wire as the LLM yields function calls.
+- **Structured Data First:** Use strict Zod schemas (`useObject`, `streamObject`) whenever you need the LLM to output parsable data.
+- **Progressive Disclosure:** Use `streamUI` to yield intermediate loading states (e.g., `<SkeletonLoader />`) while waiting for external APIs.
+
+## 2. Vercel AI SDK Patterns
+
+### A. Streaming React Components (`ai/rsc`)
+When setting up `ai/rsc`, define explicit tool boundaries:
+```typescript
+import { createAI, getMutableAIState, streamUI } from "ai/rsc";
+import { z } from "zod";
+
+export const AI = createAI({
+  actions: {
+    submitMessage: async (message: string) => {
+      "use server";
+      return streamUI({
+        model: openai("gpt-4-turbo"),
+        system: "You are a helpful assistant.",
+        prompt: message,
+        tools: {
+          getWeather: {
+            description: "Get the weather for a location",
+            parameters: z.object({ city: z.string() }),
+            generate: async ({ city }) => {
+              yield <WeatherSkeleton city={city} />;
+              const temp = await fetchWeatherAPI(city);
+              return <WeatherCard city={city} temp={temp} />;
+            }
+          }
+        }
+      });
+    }
+  }
+});
+```
+
+### B. Structured Output (`streamObject`)
+Use this when you need strict JSON streams for charts, tables, or complex states.
+```typescript
+const result = await streamObject({
+  model: openai("gpt-4-turbo"),
+  schema: z.object({
+    points: z.array(z.object({ x: z.number(), y: z.number() }))
+  }),
+  prompt: "Generate a sales forecast chart data",
+});
+// Client consumes via useObject
+```
+
+## 3. Client-Side State Management
+- Use `useChat` for standard text+tool workflows.
+- Use `useUIState` and `useAIState` to manage the UI payload array and the underlying LLM message history separately.
+- Always include `id` and `role` in message schemas to prevent key-rendering bugs in React.
+
+## 4. LLM Traps & Pre-Flight Checks
+- **TRAP:** Sending client components directly over the wire from `generate:`.
+- **FIX:** Server actions can only return Server Components. If returning an interactive widget, wrap it in a client component but yield it from the server.
+- **TRAP:** Forgetting to yield intermediate states in slow tools.
+- **FIX:** Always `yield <Loading />` before awaiting slow API calls inside a tool's `generate` function.
+
+## Verification Protocol
+Before submitting code, ensure:
+1. `zod` is used for all tool parameters.
+2. Server Actions are properly annotated with `"use server"`.
+3. The model supports tool calling (e.g., `gpt-4o`, `claude-3-5-sonnet`).
+
+### 🛑 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/harness-protocol/SKILL.md

@@ -0,0 +1,23 @@
+---
+name: harness-protocol
+description: Rules and guidelines for the Marathon long-running agent harness
+---
+
+# Harness Protocol
+
+This skill enforces the rules for the Marathon long-running agent harness.
+
+## Rules
+
+1. Each session must start with `tk marathon init "spec"`
+2. Agents must verify they have completed their current task before running `tk marathon mark pass`
+3. If an agent encounters an unrecoverable error, they must run `tk marathon mark fail`
+4. The harness is responsible for tracking overall progression.
+5. All agents must follow the Verification-Before-Completion (VBC) protocol.
+
+## Pre-Flight Checklist
+- Check marathon session state
+- Confirm VBC guidelines are followed
+
+## VBC Protocol
+- Verify task is complete before marking pass

package/.agent/skills/webgpu-performance/SKILL.md

@@ -0,0 +1,73 @@
+---
+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.
+---
+
+# WebGPU Performance Mastery
+
+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
+struct SystemData {
+    deltaTime: f32,
+    particleCount: u32,
+}
+
+@group(0) @binding(0) var<uniform> data: SystemData;
+@group(0) @binding(1) var<storage, read_write> particles: array<vec4<f32>>;
+
+@compute @workgroup_size(64)
+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;
+}
+```
+
+## 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:** 
+   ```typescript
+   const encoder = device.createCommandEncoder();
+   const pass = encoder.beginComputePass();
+   pass.setPipeline(computePipeline);
+   pass.setBindGroup(0, bindGroup);
+   pass.dispatchWorkgroups(Math.ceil(count / 64));
+   pass.end();
+   device.queue.submit([encoder.finish()]);
+   ```
+
+## 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.
+- **FIX:** Never use `vec3<f32>` inside arrays without padding. It behaves as 16-bytes anyway. Use `vec4<f32>` to be perfectly aligned.
+- **TRAP:** Reading buffers back to the CPU synchronoulsy.
+- **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.
+
+### 🛑 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/README.md

@@ -10,7 +10,8 @@
 
   [![NPM](https://img.shields.io/npm/v/tribunal-kit?style=for-the-badge&logo=npm&logoColor=white)](https://www.npmjs.com/package/tribunal-kit)
   [![License](https://img.shields.io/badge/License-MIT-8b5cf6?style=for-the-badge)](LICENSE)
-  [![Version](https://img.shields.io/badge/Version-4.4.4_Marathon-black?style=for-the-badge)](CHANGELOG.md)
+  [![Version](https://img.shields.io/badge/Version-4.5.0_Ultimate-black?style=for-the-badge)](CHANGELOG.md)
+  [![MCP](https://img.shields.io/badge/MCP-Ready-00e5ff?style=for-the-badge)](mcp_config.json)
 </div>
 
 ---
@@ -31,6 +32,9 @@ npx tribunal-kit init
 > [!NOTE]
 > `init` automatically generates bridge rules for **Cursor**, **Windsurf**, **Gemini**, **Copilot**, and **Claude**. No configuration required.
 
+### 🔄 Auto-Syncing IDEs
+Keep your entire team aligned. Run `npx tribunal-kit sync` to instantly push the latest `.agent` rules directly into your IDE config files. Use `npx tribunal-kit hook` to install a Git `pre-push` hook that auto-evolves and syncs rules every time you push code.
+
 <br>
 
 ## ▓▒░ THE MARATHON HARNESS (v4.4.4)
@@ -46,6 +50,9 @@ Agents no longer blindly retry failed approaches. When a feature fails, the reas
 ### 🔮 Memory Distillation
 Context windows dilute over time. The new `distill` command allows agents to forge crucial architectural decisions into a permanent `distilled_context.md` memory matrix, bridging the amnesia gap between long work sessions.
 
+### 🎨 Native Swarm Dashboard
+When dispatching parallel tasks via `/swarm`, Tribunal now intercepts the noisy terminal output and renders a sleek, zero-dependency **ANSI TUI Dashboard**. Watch multiple agents research, generate, and review in real-time.
+
 <br>
 
 ## ▓▒░ THE PIPELINE // EVIDENCE-BASED CLOSEOUT
@@ -88,6 +95,15 @@ The Tribunal Kit features persistent memory. The AI **never makes the same mista
 > Stop writing manual rules. The system reads your Git diffs, strips token bloat, and auto-extracts your project's architectural idioms.
 > - `npx tribunal-kit learn` *(Digest staged files)*
 
+## ▓▒░ NATIVE MCP SERVER
+
+Tribunal-Kit now functions as a standalone **Model Context Protocol (MCP)** server via `stdio`. 
+
+Bind your AI IDE (Cursor, Claude Desktop, etc.) directly to `tribunal-kit` to unlock autonomous tool execution:
+- `run_tribunal_audit`: AI can trigger a full workspace health check.
+- `search_case_law`: AI can query your project's historical code rejections to avoid making mistakes *before* it writes code.
+- `sync_ide_bridges`: Force rule alignment directly from the AI chat.
+
 <br>
 
 ## ▓▒░ COMMAND ARSENAL