tribunal-kit 8.0.0 → 9.0.0

package/.agent/skills/readme-builder/SKILL.md

@@ -2,8 +2,8 @@
 name: readme-builder
 description: Interactive README.md generation specialist. Creates professional, structured README files with badges, installation guides, usage examples, screenshots, and contribution guidelines. Use when asked to create, update, or improve a README file.
 tools: Read, Grep, Glob, Bash, Edit, Write
-version: 3.0.0
-last-updated: 2026-07-30
+version: 4.0.0
+last-updated: 2026-09-07
 skills:
   - documentation-templates
   - geo-fundamentals
@@ -25,6 +25,12 @@ Before generating or updating a README file, you MUST inspect:
 2. Zero Placeholder Rule (Section 28) → Ban template placeholders (`[insert here]`); generate copy-paste ready code examples from actual project code
 3. Hero Section Lead-With-Value (Section 164) → Lead with a single-sentence value proposition and visual trust badges; ban starting with just the title
 
+
+## Activation Boundaries
+
+- **Activate when:** Operating in tasks requiring Interactive README.md generation specialist. Creates professional, structured README files with badges, installation guides, usage examples, screenshots, and contribution guidelines. Use when asked to create, update, or improve a README file..
+- **DO NOT activate when:** The task falls strictly outside readme-builder domain or belongs to a different dedicated specialist.
+
 ## Hallucination Traps (Read First)
 
 - ❌ Starting a README with the project name as the only heading -> ✅ Lead with what the project DOES, not just what it IS
@@ -33,8 +39,6 @@ Before generating or updating a README file, you MUST inspect:
 
 ---
 
-# README Builder Skill
-
 ---
 
 ## Ground Rules
@@ -289,69 +293,17 @@ AI coding assistants often fall into specific bad habits when dealing with this
 
 ---
 
-**Slash command: `/review` or `/tribunal-full`**
-**Active reviewers: `logic-reviewer` · `security-auditor`**
-
-### ❌ Forbidden AI Tropes
-
-1. **Blind Assumptions:** Never make an assumption without documenting it clearly with `// VERIFY: [reason]`.
-2. **Silent Degradation:** Catching and suppressing errors without logging or handling.
-3. **Context Amnesia:** Forgetting the user's constraints and offering generic advice instead of tailored solutions.
-
-Review these questions before confirming output:
-
-```
-✅ Did I rely ONLY on real, verified tools and methods?
-✅ Is this solution appropriately scoped to the user's constraints?
-✅ Did I handle potential failure modes and edge cases?
-✅ Have I avoided generic boilerplate that doesn't add value?
-```
-
-### 🛑 Verification-Before-Completion (VBC) Protocol
-
-**CRITICAL:** You must follow a strict "evidence-based closeout" state machine.
-
-- ❌ **Forbidden:** Declaring a task complete because the output "looks correct."
-- ✅ **Required:** You are explicitly forbidden from finalizing any task without providing **concrete evidence** (terminal output, passing tests, compile success, or equivalent proof) that your output works as intended.
-
-## Pre-Flight Checklist
-
-- [ ] Have I reviewed the user's specific constraints and requests?
-- [ ] Have I checked the environment for relevant existing implementations?
-
-## VBC Protocol (Verification-Before-Completion)
-
-You MUST verify existing code signatures and variables before attempting to modify or call them. No hallucination is permitted.
-
----
-
-## 🤖 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)
+## 🏛️ Tribunal Verification & Guardrails
 
 **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?
@@ -360,8 +312,6 @@ Review these questions before confirming output:
 ```
 
 ### 🛑 Verification-Before-Completion (VBC) Protocol
-
 **CRITICAL:** You must follow a strict "evidence-based closeout" state machine.
-
 - ❌ **Forbidden:** Declaring a task complete because the output "looks correct."
 - ✅ **Required:** You are explicitly forbidden from finalizing any task without providing **concrete evidence** (terminal output, passing tests, compile success, or equivalent proof) that your output works as intended.

package/.agent/skills/realtime-patterns/SKILL.md

@@ -2,8 +2,8 @@
 name: realtime-patterns
 description: Real-time application mastery. WebSockets, Server-Sent Events (SSE), CRDTs for conflict-free collaboration, presence systems, optimistic updates, live cursors, multiplayer state sync, reconnection strategies, and real-time database patterns (Supabase Realtime, Firebase). Use when building chat, live collaboration, dashboards, or multiplayer features.
 tools: Read, Grep, Glob, Bash, Edit, Write
-version: 3.0.0
-last-updated: 2026-07-30
+version: 4.0.0
+last-updated: 2026-09-07
 skills:
   - api-patterns
   - backend-security-expert
@@ -25,7 +25,11 @@ Before architecting real-time streaming or WebSocket infrastructure, you MUST in
 2. WebSocket Exponential Reconnection (Section 183) → Implement exponential backoff with random jitter for client reconnection loops to prevent thundering herd crashes
 3. Optimistic UI Rollback Handler (Section 207) → Capture previous state before optimistic mutations and implement explicit onError rollback logic
 
-# Real-Time Patterns — Live Application Mastery
+
+## Activation Boundaries
+
+- **Activate when:** Operating in tasks requiring Real-time application mastery. WebSockets, Server-Sent Events (SSE), CRDTs for conflict-free collaboration, presence systems, optimistic updates, live cursors, multiplayer state sync, reconnection strategies, and real-time database patterns (Supabase Realtime, Firebase). Use when building chat, live collaboration, dashboards, or multiplayer features..
+- **DO NOT activate when:** The task falls strictly outside realtime-patterns domain or belongs to a different dedicated specialist.
 
 ---
 
@@ -302,69 +306,17 @@ AI coding assistants often fall into specific bad habits when dealing with this
 
 ---
 
-**Slash command: `/review` or `/tribunal-full`**
-**Active reviewers: `logic-reviewer` · `security-auditor`**
-
-### ❌ Forbidden AI Tropes
-
-1. **Blind Assumptions:** Never make an assumption without documenting it clearly with `// VERIFY: [reason]`.
-2. **Silent Degradation:** Catching and suppressing errors without logging or handling.
-3. **Context Amnesia:** Forgetting the user's constraints and offering generic advice instead of tailored solutions.
-
-Review these questions before confirming output:
-
-```
-✅ Did I rely ONLY on real, verified tools and methods?
-✅ Is this solution appropriately scoped to the user's constraints?
-✅ Did I handle potential failure modes and edge cases?
-✅ Have I avoided generic boilerplate that doesn't add value?
-```
-
-### 🛑 Verification-Before-Completion (VBC) Protocol
-
-**CRITICAL:** You must follow a strict "evidence-based closeout" state machine.
-
-- ❌ **Forbidden:** Declaring a task complete because the output "looks correct."
-- ✅ **Required:** You are explicitly forbidden from finalizing any task without providing **concrete evidence** (terminal output, passing tests, compile success, or equivalent proof) that your output works as intended.
-
-## Pre-Flight Checklist
-
-- [ ] Have I reviewed the user's specific constraints and requests?
-- [ ] Have I checked the environment for relevant existing implementations?
-
-## VBC Protocol (Verification-Before-Completion)
-
-You MUST verify existing code signatures and variables before attempting to modify or call them. No hallucination is permitted.
-
----
-
-## 🤖 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)
+## 🏛️ Tribunal Verification & Guardrails
 
 **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?
@@ -373,8 +325,6 @@ Review these questions before confirming output:
 ```
 
 ### 🛑 Verification-Before-Completion (VBC) Protocol
-
 **CRITICAL:** You must follow a strict "evidence-based closeout" state machine.
-
 - ❌ **Forbidden:** Declaring a task complete because the output "looks correct."
 - ✅ **Required:** You are explicitly forbidden from finalizing any task without providing **concrete evidence** (terminal output, passing tests, compile success, or equivalent proof) that your output works as intended.

package/.agent/skills/red-team-tactics/SKILL.md

@@ -2,8 +2,8 @@
 name: red-team-tactics
 description: Red team tactics principles based on MITRE ATT&CK. Attack phases, detection evasion, reporting.
 tools: Read, Grep, Glob, Bash, Edit, Write
-version: 3.0.0
-last-updated: 2026-07-30
+version: 4.0.0
+last-updated: 2026-09-07
 skills:
   - vulnerability-scanner
   - backend-security-expert
@@ -25,6 +25,12 @@ Before performing red team assessments or security testing, you MUST inspect:
 2. Reproducible PoC Rule (Section 16) → Include a reproducible Proof-of-Concept, CVSS risk score, and explicit remediation snippet for every finding
 3. Breach Discovery Halt (Section 162) → Immediately halt security testing and report if evidence of an active real-world breach is discovered
 
+
+## Activation Boundaries
+
+- **Activate when:** Operating in tasks requiring Red team tactics principles based on MITRE ATT&CK. Attack phases, detection evasion, reporting..
+- **DO NOT activate when:** The task falls strictly outside red-team-tactics domain or belongs to a different dedicated specialist.
+
 ## Hallucination Traps (Read First)
 
 - ❌ Testing only happy-path authentication -> ✅ Red teaming must test token reuse, expired tokens, forged tokens, and privilege escalation
@@ -33,8 +39,6 @@ Before performing red team assessments or security testing, you MUST inspect:
 
 ---
 
-# Red Team & Penetration Testing Principles
-
 A red team engagement is a controlled attack.
 The goal is to find what a real attacker would find — before they do.
 
@@ -210,69 +214,17 @@ AI coding assistants often fall into specific bad habits when dealing with this
 
 ---
 
-**Slash command: `/review` or `/tribunal-full`**
-**Active reviewers: `logic-reviewer` · `security-auditor`**
-
-### ❌ Forbidden AI Tropes
-
-1. **Blind Assumptions:** Never make an assumption without documenting it clearly with `// VERIFY: [reason]`.
-2. **Silent Degradation:** Catching and suppressing errors without logging or handling.
-3. **Context Amnesia:** Forgetting the user's constraints and offering generic advice instead of tailored solutions.
-
-Review these questions before confirming output:
-
-```
-✅ Did I rely ONLY on real, verified tools and methods?
-✅ Is this solution appropriately scoped to the user's constraints?
-✅ Did I handle potential failure modes and edge cases?
-✅ Have I avoided generic boilerplate that doesn't add value?
-```
-
-### 🛑 Verification-Before-Completion (VBC) Protocol
-
-**CRITICAL:** You must follow a strict "evidence-based closeout" state machine.
-
-- ❌ **Forbidden:** Declaring a task complete because the output "looks correct."
-- ✅ **Required:** You are explicitly forbidden from finalizing any task without providing **concrete evidence** (terminal output, passing tests, compile success, or equivalent proof) that your output works as intended.
-
-## Pre-Flight Checklist
-
-- [ ] Have I reviewed the user's specific constraints and requests?
-- [ ] Have I checked the environment for relevant existing implementations?
-
-## VBC Protocol (Verification-Before-Completion)
-
-You MUST verify existing code signatures and variables before attempting to modify or call them. No hallucination is permitted.
-
----
-
-## 🤖 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)
+## 🏛️ Tribunal Verification & Guardrails
 
 **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?
@@ -281,8 +233,6 @@ Review these questions before confirming output:
 ```
 
 ### 🛑 Verification-Before-Completion (VBC) Protocol
-
 **CRITICAL:** You must follow a strict "evidence-based closeout" state machine.
-
 - ❌ **Forbidden:** Declaring a task complete because the output "looks correct."
 - ✅ **Required:** You are explicitly forbidden from finalizing any task without providing **concrete evidence** (terminal output, passing tests, compile success, or equivalent proof) that your output works as intended.

package/.agent/skills/redesign-skill/SKILL.md

@@ -1,8 +1,8 @@
 ---
 name: redesign-skill
 description: Audit and upgrade existing interfaces to premium visual quality while preserving product functionality and business logic.
-version: 3.0.0
-last-updated: 2026-07-30
+version: 4.0.0
+last-updated: 2026-09-07
 skills:
   - taste-skill
   - better-ui
@@ -27,6 +27,12 @@ Before executing interface redesigns, you MUST inspect:
 
 Audit legacy or unstyled user interfaces and transform them into modern, production-grade products without breaking underlying business logic.
 
+
+## Activation Boundaries
+
+- **Activate when:** Operating in tasks requiring Audit and upgrade existing interfaces to premium visual quality while preserving product functionality and business logic..
+- **DO NOT activate when:** The task falls strictly outside redesign-skill domain or belongs to a different dedicated specialist.
+
 ---
 
 ## 4 Redesign Upgrade Steps
@@ -53,28 +59,25 @@ Before touching CSS or HTML layout:
 
 ---
 
-## 🤖 LLM-Specific Traps
+## 🏛️ Tribunal Verification & Guardrails
 
-1. **Breaking Functionality During Redesign**: Deleting event handlers, state hooks, or form field inputs while redesigning the layout.
-2. **Generic Template Replacement**: Replacing a unique custom feature with a stock generic card grid.
-
----
+**Slash command: `/review` or `/tribunal-full`**
+**Active reviewers: `logic-reviewer` · `security-auditor`**
 
-## 🏛️ Tribunal Integration (Anti-Hallucination)
-
-**Active reviewers: `frontend-reviewer` · `ui-ux-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
-
 ```
-✅ Are all original props, event handlers, and state variables 100% preserved?
-✅ Is the visual hierarchy upgraded using OKLCH surface levels and multi-layer shadows?
-✅ Have interactive controls received tactile `:active` press feedback?
+✅ 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/review-animations/SKILL.md

@@ -2,8 +2,8 @@
 name: review-animations
 description: Reviews animation and motion code against a high craft bar derived from Emil Kowalski's design engineering philosophy. Default to flagging; approval is earned.
 tools: Read, Grep, Glob, Bash, Edit, Write
-version: 3.0.0
-last-updated: 2026-07-30
+version: 4.0.0
+last-updated: 2026-09-07
 skills:
   - emil-design-eng
   - 60fps-animation
@@ -25,10 +25,14 @@ Before auditing animation code or reviewing motion diffs, you MUST inspect:
 2. GPU-Only Property Constraint (Section 38) → Flag any animation of layout-heavy properties (`width`/`height`/`top`/`left`); require `transform` and `opacity`
 3. Physical Correctness & Origin (Section 36) → Flag `scale(0)` entrances; require `scale(0.9–0.97)` with `opacity` and accurate `transform-origin`
 
-# Reviewing Animations
-
 A specialized review skill. It does ONE thing: review animation and motion code against a high craft bar. It does not write features, fix unrelated bugs, or review non-motion code. If asked to review general code, decline and point to a general review skill.
 
+
+## Activation Boundaries
+
+- **Activate when:** Operating in tasks requiring Reviews animation and motion code against a high craft bar derived from Emil Kowalski's design engineering philosophy. Default to flagging; approval is earned..
+- **DO NOT activate when:** The task falls strictly outside review-animations domain or belongs to a different dedicated specialist.
+
 ## Operating Posture
 
 You are a senior motion-design reviewer with a brutal eye for craft. Your bias is toward **motion that feels right**, not motion that merely runs. A transition that "works" but feels sluggish, lands from the wrong origin, fires too often, or drops frames is a regression, not a pass. Default to flagging. Approval is earned, not assumed.
@@ -54,33 +58,25 @@ Every animation in the diff is measured against these. A violation is a finding.
 
 ---
 
-## 🤖 LLM-Specific Traps
-
-1. **Passive Approval:** Approving animations just because the syntax is correct. You must evaluate the _feel_ and _performance_ against the Standards.
-2. **Ignoring Physics:** Failing to flag elements appearing from nothing (`scale(0)`) or scaling from the wrong origin point.
-3. **Overlooking Duration:** Missing sluggish transitions that exceed the 300ms budget for UI elements.
-4. **Accepting Default Easings:** Approving `ease-in` or generic `ease` on entering UI elements instead of demanding strong `ease-out` curves.
-
-## 🏛️ Tribunal Integration (Anti-Hallucination)
+## 🏛️ Tribunal Verification & Guardrails
 
 **Slash command: `/review` or `/tribunal-full`**
-**Active reviewers: `frontend-reviewer` · `performance-reviewer`**
-
-### ✅ Pre-Flight Self-Audit
+**Active reviewers: `logic-reviewer` · `security-auditor`**
 
-Review these questions before confirming output:
+### ❌ 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
 ```
-✅ Did I measure the diff against all 10 non-negotiable standards?
-✅ Did I flag any UI animations exceeding 300ms?
-✅ Did I reject any `ease-in` usage on entering elements?
-✅ Did I verify GPU-only properties (`transform` and `opacity`)?
-✅ Did I check for interruptibility and physical correctness?
+✅ 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:** Marking the review as "Pass" without explicitly evaluating against the STANDARDS.md criteria.
-- ✅ **Required:** Output the review in the standard table format (`| Before | After | Why |`) highlighting all violations, and explicitly stating why approval is earned or withheld.
+- ❌ **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/rust-pro/SKILL.md

@@ -2,8 +2,8 @@
 name: rust-pro
 description: Master Rust 1.75+ with modern async patterns, ownership/borrowing, lifetimes, traits, error handling with thiserror/anyhow, async Tokio runtime, axum web framework, serde serialization, and systems programming. Use when building Rust services, CLI tools, WebAssembly, or performance-critical systems.
 tools: Read, Grep, Glob, Bash, Edit, Write
-version: 3.0.0
-last-updated: 2026-07-30
+version: 4.0.0
+last-updated: 2026-09-07
 skills:
   - clean-code
   - api-patterns
@@ -21,11 +21,34 @@ scripts-binding:
 
 Before writing Rust code or Axum handlers, you MUST inspect:
 
-1. Production Error Propagation (Section 130) → Use `?` operator and structured `Result<T, E>`; ban `.unwrap()` in production code
-2. Library vs App Error Strategy (Section 192) → Use `thiserror` for library crates to export structured errors; use `anyhow` only for application code
-3. Axum 0.7+ Route Parameters (Section 444) → Use `{id}` bracket syntax for path parameters (`/users/{id}`); ban legacy `:id` syntax
+1. Zero `.unwrap()` in Production → Use the `?` operator and typed `Result<T, E>`; use `.expect("invariant: explanation")` only if mathematically unreachable
+2. Standard Library `std::sync::LazyLock` → Use native `LazyLock` (Rust 1.80+); ban external `lazy_static` or `once_cell` dependencies
+3. Axum 0.7+ Route Parameters → Use `{id}` bracket syntax for path parameters (`/users/{id}`); ban legacy `:id` syntax
+4. Tokio Cancellation Safety → Ensure `tokio::select!` branches do not hold partially-completed state across cancellation points
 
-# Rust Pro — Rust 1.75+ Systems Mastery
+## Activation Boundaries
+
+- **Activate when:** Writing systems-level Rust, Tokio async services, Axum web backends, WebAssembly modules, and performance-critical native CLI engines.
+- **DO NOT activate when:** Writing frontend HTML/CSS, or rapid Python/Node.js glue scripts.
+
+## 2026 Rust Performance & Memory Invariants
+
+1. **Native `std::sync::LazyLock`**:
+   ```rust
+   use std::sync::LazyLock;
+   static REGEX: LazyLock<regex::Regex> = LazyLock::new(|| regex::Regex::new(r"^\d+$").unwrap());
+   ```
+2. **Async fn in Traits**: Use native `async fn` inside traits directly (Rust 1.75+ / 2024 edition) without the legacy `#[async_trait]` macro attribute.
+3. **Zero-Copy Borrowing**: Accept `&str` or `&[T]` instead of taking owned `String` or `Vec<T>` in function signatures unless ownership transfer is strictly required.
+4. **Tokio Task Spawning Budget**: Never spawn unbounded Tokio tasks inside request loops without a semaphore limit to prevent memory exhaustion.
+
+## Hallucination Traps (Read First)
+
+- ❌ Using `lazy_static!` or `once_cell::sync::Lazy` → ✅ Use `std::sync::LazyLock`
+- ❌ Using `#[async_trait]` macro for basic traits → ✅ Native `async fn` in traits (Rust 1.75+)
+- ❌ `.unwrap()` in production handlers → ✅ `?` operator with `thiserror` / `anyhow`
+- ❌ Axum `:id` path parameter syntax → ✅ Axum 0.7+: `{id}` bracket syntax
+- ❌ Allocating `String` just to pass to a reader → ✅ Pass `&str`
 
 ---
 
@@ -650,69 +673,17 @@ AI coding assistants often fall into specific bad habits when dealing with this
 
 ---
 
-**Slash command: `/review` or `/tribunal-full`**
-**Active reviewers: `logic-reviewer` · `security-auditor`**
-
-### ❌ Forbidden AI Tropes
-
-1. **Blind Assumptions:** Never make an assumption without documenting it clearly with `// VERIFY: [reason]`.
-2. **Silent Degradation:** Catching and suppressing errors without logging or handling.
-3. **Context Amnesia:** Forgetting the user's constraints and offering generic advice instead of tailored solutions.
-
-Review these questions before confirming output:
-
-```
-✅ Did I rely ONLY on real, verified tools and methods?
-✅ Is this solution appropriately scoped to the user's constraints?
-✅ Did I handle potential failure modes and edge cases?
-✅ Have I avoided generic boilerplate that doesn't add value?
-```
-
-### 🛑 Verification-Before-Completion (VBC) Protocol
-
-**CRITICAL:** You must follow a strict "evidence-based closeout" state machine.
-
-- ❌ **Forbidden:** Declaring a task complete because the output "looks correct."
-- ✅ **Required:** You are explicitly forbidden from finalizing any task without providing **concrete evidence** (terminal output, passing tests, compile success, or equivalent proof) that your output works as intended.
-
-## Pre-Flight Checklist
-
-- [ ] Have I reviewed the user's specific constraints and requests?
-- [ ] Have I checked the environment for relevant existing implementations?
-
-## VBC Protocol (Verification-Before-Completion)
-
-You MUST verify existing code signatures and variables before attempting to modify or call them. No hallucination is permitted.
-
----
-
-## 🤖 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)
+## 🏛️ Tribunal Verification & Guardrails
 
 **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?
@@ -721,8 +692,6 @@ Review these questions before confirming output:
 ```
 
 ### 🛑 Verification-Before-Completion (VBC) Protocol
-
 **CRITICAL:** You must follow a strict "evidence-based closeout" state machine.
-
 - ❌ **Forbidden:** Declaring a task complete because the output "looks correct."
 - ✅ **Required:** You are explicitly forbidden from finalizing any task without providing **concrete evidence** (terminal output, passing tests, compile success, or equivalent proof) that your output works as intended.