tribunal-kit 9.2.3 → 9.2.5

package/.agent/skills/frontend-security-expert/SKILL.md

@@ -1,56 +1,56 @@
----
-name: frontend-security-expert
-description: "Use when Frontend security auditing for modern meta-frameworks. Focuses on React/Next.js UI paradigms, hydration poisoning, third-party script supply chain, local storage security, and XSS prevention in modern environments."
-version: 5.0.0
-last-updated: 2026-09-13
-skills:
-  - backend-security-expert
-  - api-security-auditor
-  - vulnerability-scanner
-tools: Read, Grep, Glob, Bash, Edit, Write
-scripts-binding:
-  - .agent/scripts/lint_runner.js
-  - .agent/scripts/verify_all.js
----
-
-# Frontend Security Expert — Modern Meta-Frameworks
-
----
-
-## 🛠️ Technical Architecture & Reference Recipes
-
----
-
-## Hallucination Traps (Read First)
-
-- ❌ Focusing on generic OWASP top 10 (SQLi, IDOR) → ✅ This is the _frontend_ skill. Focus strictly on client-side boundaries, SSR hydration, and DOM.
-- ❌ Treating React `useEffect` data fetching as secure → ✅ Data fetched client-side can be intercepted or manipulated.
-- ❌ Recommending LocalStorage for JWTs → ✅ JWTs must go in HttpOnly, Secure, SameSite cookies.
-- ❌ Assuming Next.js SSR is immune to XSS → ✅ Hydration mismatch or dangerouslySetInnerHTML can inject payloads.
-
----
-
-## 1. React & Next.js Specific Vulnerabilities
-
-Modern frameworks handle basic XSS by escaping text, but specific APIs bypass this.
-
-- **`dangerouslySetInnerHTML`**: Never use this with unsanitized user input. If required, mandate the use of DOMPurify.
-- **Hydration Poisoning**: Ensure that data rendered on the server matches the client to prevent malicious hydration states.
-- **`javascript:` URIs**: React does not automatically prevent `javascript:` URIs in `href` tags. Audit all dynamic links.
-
-## 2. Token & State Storage (Web Storage API)
-
-- **Local/Session Storage**: Do not store sensitive PII, Auth Tokens (JWTs), or API keys here. They are accessible via any XSS attack.
-- **Cookies**: Use `HttpOnly`, `Secure`, and `SameSite=Strict` (or `Lax`) for all authentication cookies.
-- **In-Memory State**: Store temporary sensitive data in React state/Zustand, recognizing it clears on refresh.
-
-## 3. Third-Party Supply Chain
-
-- **External Scripts**: Any `<script src="...">` has full access to the DOM and global window.
-- **Subresource Integrity (SRI)**: Ensure all CDN-loaded scripts use the `integrity` attribute.
-- **Next.js `<Script>` Component**: Use appropriate strategies (`beforeInteractive`, `afterInteractive`) and audit what is loaded.
-
-## 4. Cross-Origin & PostMessage
-
-- **`postMessage`**: Never use `targetOrigin: '*'` when sending messages. Always validate `event.origin` when receiving messages.
-- **Iframes**: Use the `sandbox` attribute for any user-generated iframes to restrict script execution and top-level navigation.
+---
+name: frontend-security-expert
+description: "Use when Frontend security auditing for modern meta-frameworks. Focuses on React/Next.js UI paradigms, hydration poisoning, third-party script supply chain, local storage security, and XSS prevention in modern environments."
+version: 5.0.0
+last-updated: 2026-09-13
+skills:
+  - backend-security-expert
+  - api-security-auditor
+  - vulnerability-scanner
+tools: Read, Grep, Glob, Bash, Edit, Write
+scripts-binding:
+  - .agent/scripts/lint_runner.js
+  - .agent/scripts/verify_all.js
+---
+
+# Frontend Security Expert — Modern Meta-Frameworks
+
+---
+
+## 🛠️ Technical Architecture & Reference Recipes
+
+---
+
+## Hallucination Traps (Read First)
+
+- ❌ Focusing on generic OWASP top 10 (SQLi, IDOR) → ✅ This is the _frontend_ skill. Focus strictly on client-side boundaries, SSR hydration, and DOM.
+- ❌ Treating React `useEffect` data fetching as secure → ✅ Data fetched client-side can be intercepted or manipulated.
+- ❌ Recommending LocalStorage for JWTs → ✅ JWTs must go in HttpOnly, Secure, SameSite cookies.
+- ❌ Assuming Next.js SSR is immune to XSS → ✅ Hydration mismatch or dangerouslySetInnerHTML can inject payloads.
+
+---
+
+## 1. React & Next.js Specific Vulnerabilities
+
+Modern frameworks handle basic XSS by escaping text, but specific APIs bypass this.
+
+- **`dangerouslySetInnerHTML`**: Never use this with unsanitized user input. If required, mandate the use of DOMPurify.
+- **Hydration Poisoning**: Ensure that data rendered on the server matches the client to prevent malicious hydration states.
+- **`javascript:` URIs**: React does not automatically prevent `javascript:` URIs in `href` tags. Audit all dynamic links.
+
+## 2. Token & State Storage (Web Storage API)
+
+- **Local/Session Storage**: Do not store sensitive PII, Auth Tokens (JWTs), or API keys here. They are accessible via any XSS attack.
+- **Cookies**: Use `HttpOnly`, `Secure`, and `SameSite=Strict` (or `Lax`) for all authentication cookies.
+- **In-Memory State**: Store temporary sensitive data in React state/Zustand, recognizing it clears on refresh.
+
+## 3. Third-Party Supply Chain
+
+- **External Scripts**: Any `<script src="...">` has full access to the DOM and global window.
+- **Subresource Integrity (SRI)**: Ensure all CDN-loaded scripts use the `integrity` attribute.
+- **Next.js `<Script>` Component**: Use appropriate strategies (`beforeInteractive`, `afterInteractive`) and audit what is loaded.
+
+## 4. Cross-Origin & PostMessage
+
+- **`postMessage`**: Never use `targetOrigin: '*'` when sending messages. Always validate `event.origin` when receiving messages.
+- **Iframes**: Use the `sandbox` attribute for any user-generated iframes to restrict script execution and top-level navigation.

package/.agent/skills/game-design-expert/SKILL.md

@@ -1,92 +1,92 @@
----
-name: game-design-expert
-description: "Use when Game Design, UX, and Flow State mastery. Replaces fragmented legacy skills. Core gameplay loop design, 3Cs (Character, Camera, Controls), input buffering, coyote time, juice (game feel), telemetry tracking, narrative alignment, and audio spatialization integration. Use when crafting player experience, progression arcs, or systemic balance."
-version: 5.0.0
-last-updated: 2026-09-13
-skills:
-  - game-engineering-expert
-  - 12-principles-of-animation
-  - sounds-on-the-web
-tools: Read, Grep, Glob, Bash, Edit, Write
-scripts-binding:
-  - .agent/scripts/lint_runner.js
-  - .agent/scripts/verify_all.js
----
-
-# Game Design Expert — Player Experience & Flow Mastery
-
----
-
-## 🛠️ Technical Architecture & Reference Recipes
-
----
-
-## Hallucination Traps (Read First)
-
-- ❌ Designing reward systems without testing for compulsion loops -> ✅ Playtesting must verify engagement without addiction patterns
-- ❌ Assuming all players have the same skill level -> ✅ Design difficulty curves that adapt or offer accessibility options
-- ❌ Adding mechanics without testing the core loop first -> ✅ Core loop must be fun in isolation before adding complexity
-
----
-
----
-
-## 1. The 3Cs (Character, Camera, Controls)
-
-Before designing enemies, levels, or UI, the foundation of the player's interaction MUST feel flawless. If the player cannot intrinsically trust the controls, the entire system collapses.
-
-### Input Buffering
-
-Humans cannot click buttons flawlessly on the exact required frame.
-If a player presses "Jump" 3 frames _before_ they hit the ground, a naïve engine ignores it. A designed engine _buffers_ the input in memory for 150ms and instantly executes the jump the millisecond the character's feet touch the dirt.
-
-### Coyote Time
-
-Named after Wile E. Coyote hovering off a cliff.
-If a player runs off a ledge, a rigid physics engine drops them instantly.
-A forgiving design allows the player to still press 'Jump' for exactly ~100ms _after_ walking off the ledge. It prevents extreme frustration on close platforming jumps.
-
----
-
-## 2. The Core Gameplay Loop
-
-Every action a player takes must feed into a reinforcing psychological loop.
-
-**The Macro Loop (e.g., Destiny, Monster Hunter)**
-
-1. **Action:** Fight complex monsters.
-2. **Reward:** Collect physical parts and resources.
-3. **Pacing:** Return to base.
-4. **Upgrade:** Convert parts into stronger weapons.
-5. **Goal:** Fight stronger, unkillable monsters (Back to Step 1).
-
-_If step 4 (Upgrading) does not heavily alter step 1 (Fights are now faster, visually different, mechanically superior), the loop is broken and players churn._
-
----
-
-## 3. "Juice" and Game Feel
-
-"Juice" is the non-functional audiovisual feedback that makes an interaction feel heavy and satisfying.
-
-1. **Screen Shake:** A minor, mathematically decaying camera displacement when heavy impacts occur. (Needs toggles for accessibility).
-2. **Hitstop (Sleep Frames):** When a sword hits an enemy, freeze the entire game engine for exactly 3 frames (50ms). This creates an immense perceptual illusion of resistance and friction.
-3. **Squash and Stretch:** A character jumping should stretch vertically. A character landing should squash horizontally. It breaks rigidity and infuses life.
-4. **Particle Explosions:** Simple box collisions must be masked by explosive localized particle systems (dust kicks, sparks).
-
----
-
-## 4. Narrative & Audio Synergies
-
-Game design is not segregated from Audio. Audio is the primary vector for temporal feedback.
-
-1. **Spatialization (HRTF):** Sound objects emit audio localized strictly to 3D space, heavily attenuated by environmental occlusions (muffled behind walls).
-2. **Telegraphing State:** If an enemy swings a heavy axe, it MUST have a 300ms audio "wind-up" queue. The player relies on audio rhythm far faster than visual recognition to dodge.
-3. **Dynamic Mixing (Ducking):** Essential dialogue or UI pings must automatically compress (lower the volume of) ambient music underneath to prevent cognitive overload.
-
----
-
-## 5. Telemetry & Analytics Deficiencies
-
-Design is hypotheses. Playtests are the reality.
-
-Never rely on developers "feeling" the game. You must systematically log death coordinates (heatmaps). If 80% of players die at Level 2 Trap B, your design intent (teaching the mechanic) has failed.
+---
+name: game-design-expert
+description: "Use when Game Design, UX, and Flow State mastery. Replaces fragmented legacy skills. Core gameplay loop design, 3Cs (Character, Camera, Controls), input buffering, coyote time, juice (game feel), telemetry tracking, narrative alignment, and audio spatialization integration. Use when crafting player experience, progression arcs, or systemic balance."
+version: 5.0.0
+last-updated: 2026-09-13
+skills:
+  - game-engineering-expert
+  - 12-principles-of-animation
+  - sounds-on-the-web
+tools: Read, Grep, Glob, Bash, Edit, Write
+scripts-binding:
+  - .agent/scripts/lint_runner.js
+  - .agent/scripts/verify_all.js
+---
+
+# Game Design Expert — Player Experience & Flow Mastery
+
+---
+
+## 🛠️ Technical Architecture & Reference Recipes
+
+---
+
+## Hallucination Traps (Read First)
+
+- ❌ Designing reward systems without testing for compulsion loops -> ✅ Playtesting must verify engagement without addiction patterns
+- ❌ Assuming all players have the same skill level -> ✅ Design difficulty curves that adapt or offer accessibility options
+- ❌ Adding mechanics without testing the core loop first -> ✅ Core loop must be fun in isolation before adding complexity
+
+---
+
+---
+
+## 1. The 3Cs (Character, Camera, Controls)
+
+Before designing enemies, levels, or UI, the foundation of the player's interaction MUST feel flawless. If the player cannot intrinsically trust the controls, the entire system collapses.
+
+### Input Buffering
+
+Humans cannot click buttons flawlessly on the exact required frame.
+If a player presses "Jump" 3 frames _before_ they hit the ground, a naïve engine ignores it. A designed engine _buffers_ the input in memory for 150ms and instantly executes the jump the millisecond the character's feet touch the dirt.
+
+### Coyote Time
+
+Named after Wile E. Coyote hovering off a cliff.
+If a player runs off a ledge, a rigid physics engine drops them instantly.
+A forgiving design allows the player to still press 'Jump' for exactly ~100ms _after_ walking off the ledge. It prevents extreme frustration on close platforming jumps.
+
+---
+
+## 2. The Core Gameplay Loop
+
+Every action a player takes must feed into a reinforcing psychological loop.
+
+**The Macro Loop (e.g., Destiny, Monster Hunter)**
+
+1. **Action:** Fight complex monsters.
+2. **Reward:** Collect physical parts and resources.
+3. **Pacing:** Return to base.
+4. **Upgrade:** Convert parts into stronger weapons.
+5. **Goal:** Fight stronger, unkillable monsters (Back to Step 1).
+
+_If step 4 (Upgrading) does not heavily alter step 1 (Fights are now faster, visually different, mechanically superior), the loop is broken and players churn._
+
+---
+
+## 3. "Juice" and Game Feel
+
+"Juice" is the non-functional audiovisual feedback that makes an interaction feel heavy and satisfying.
+
+1. **Screen Shake:** A minor, mathematically decaying camera displacement when heavy impacts occur. (Needs toggles for accessibility).
+2. **Hitstop (Sleep Frames):** When a sword hits an enemy, freeze the entire game engine for exactly 3 frames (50ms). This creates an immense perceptual illusion of resistance and friction.
+3. **Squash and Stretch:** A character jumping should stretch vertically. A character landing should squash horizontally. It breaks rigidity and infuses life.
+4. **Particle Explosions:** Simple box collisions must be masked by explosive localized particle systems (dust kicks, sparks).
+
+---
+
+## 4. Narrative & Audio Synergies
+
+Game design is not segregated from Audio. Audio is the primary vector for temporal feedback.
+
+1. **Spatialization (HRTF):** Sound objects emit audio localized strictly to 3D space, heavily attenuated by environmental occlusions (muffled behind walls).
+2. **Telegraphing State:** If an enemy swings a heavy axe, it MUST have a 300ms audio "wind-up" queue. The player relies on audio rhythm far faster than visual recognition to dodge.
+3. **Dynamic Mixing (Ducking):** Essential dialogue or UI pings must automatically compress (lower the volume of) ambient music underneath to prevent cognitive overload.
+
+---
+
+## 5. Telemetry & Analytics Deficiencies
+
+Design is hypotheses. Playtests are the reality.
+
+Never rely on developers "feeling" the game. You must systematically log death coordinates (heatmaps). If 80% of players die at Level 2 Trap B, your design intent (teaching the mechanic) has failed.

package/.agent/skills/game-engineering-expert/SKILL.md

@@ -1,108 +1,108 @@
----
-name: game-engineering-expert
-description: "Use when Game Engineering and Systems Architecture mastery. Replaces fragmented legacy skills. Entity Component Systems (ECS), Unity (C#) / Godot (GDScript) integration, physics calculations, deterministic engine state, WebGL memory management, multiplayer sync architectures (deterministic lockstep vs traditional authoritative), spatial partitioning, and rendering pipelines."
-version: 5.0.0
-last-updated: 2026-09-13
-skills:
-  - game-design-expert
-  - csharp-developer
-  - 60fps-animation
-tools: Read, Grep, Glob, Bash, Edit, Write
-scripts-binding:
-  - .agent/scripts/lint_runner.js
-  - .agent/scripts/verify_all.js
----
-
-# Game Engineering Expert — Performance & State Mastery
-
----
-
-## 🛠️ Technical Architecture & Reference Recipes
-
----
-
-## Hallucination Traps (Read First)
-
-- ❌ Using deltaTime without clamping -> ✅ Unclamped deltaTime causes physics explosions on frame spikes; clamp to max 0.05s
-- ❌ Allocating memory in the game loop (new objects, arrays) -> ✅ Pre-allocate and pool objects to avoid GC pauses during gameplay
-- ❌ Using floating-point equality checks for game state -> ✅ Use epsilon comparisons or integer-based fixed-point for deterministic logic
-
----
-
----
-
-## 1. Frame Rate Architecture (The Update Loop)
-
-In web development, we await Promises. In game development, we calculate Delta Time continuously.
-
-```csharp
-// ❌ BAD: Frame-rate dependent logic
-// If the game runs at 120 FPS, the character moves twice as fast as on 60 FPS
-void Update() {
-    transform.position += currentSpeed;
-}
-
-// ✅ GOOD: Frame-independent physics (Unity C# Example)
-void Update() {
-    // DeltaTime is the time elapsed since the last frame
-    transform.position += currentVelocity * Time.deltaTime;
-}
-```
-
-### FixedUpdate vs Update (The Physics Boundary)
-
-- `Update()` fires as fast as the GPU/CPU can draw. Used for User Input and visual animation interpolations.
-- `FixedUpdate()` fires at absolute strict mathematical intervals (e.g., 50 times a second exactly). ALL Physics interactions (`AddForce()`, collision sweeps) MUST live here to prevent tearing and tunneling.
-
----
-
-## 2. Memory Pooling (Garbage Collection Death)
-
-In Node.js, V8 cleans up objects eventually. In Game Engines, allocating memory creates "Garbage", which forces the Garbage Collector (GC) to pause the entire game to clean up, causing massive micro-stutters.
-
-```csharp
-// ❌ FATAL (in Update loops): Creating new objects 60x a second
-void Update() {
-    Instantiate(bulletPrefab, gun.position, gun.rotation); // Kills the CPU
-}
-
-// ✅ EFFICIENT: Object Pooling
-// Pre-allocate 100 bullets during the Loading Screen.
-// Then simply toggle their active state natively.
-void Fire() {
-    Bullet b = bulletPool.GetDisabledBullet();
-    b.transform.position = gun.position;
-    b.gameObject.SetActive(true);
-}
-```
-
----
-
-## 3. Entity Component Systems (ECS)
-
-Traditional Object-Oriented Programming (OOP) inheritance hierarchies break down in game engines.
-(e.g., `Enemy` inherits from `Character` which inherits from `Renderable`). What happens when you want a `Renderable` that isn't a `Character` but acts like an `Enemy` (like a deadly spike trap)?
-
-**Use ECS.**
-
-1. **Entities:** Just a meaningless ID (e.g., `Entity 304`).
-2. **Components:** Pure localized data structs attached to an ID (e.g., `Position {x: 5, y: 10}`, `Health {hp: 100}`).
-3. **Systems:** Logic that maps continuously over structs (e.g., `MovementSystem` iterates over ALL Entities that specifically have both a `Position` AND `Velocity` component).
-
----
-
-## 4. Multiplayer Architectures
-
-Never trust the client. A multiplayer architecture dictates latency fundamentally.
-
-1. **Deterministic Lockstep (RTS / Fighting Games):**
-   - Transmits absolute ZERO game state (coordinates).
-   - Only transmits _inputs_ (Player A clicked Coordinate X).
-   - Both machines run the identical physics frame simultaneously.
-   - Extremely bandwidth efficient, but requires identical CPU math output (impossible in JS floating point Math).
-
-2. **Server Authoritative with Client Prediction (Modern FPS/Action):**
-   - The Server runs the "Real" game.
-   - The Client tells the server "I fired."
-   - Because Ping takes 50ms, the Client _predicts_ the shot landing locally (optimistic UI) so the player doesn't feel lag.
-   - If the server eventually disagrees, the Client aggressively rewinds and snaps the state to match the Server reality (Rubber-banding).
+---
+name: game-engineering-expert
+description: "Use when Game Engineering and Systems Architecture mastery. Replaces fragmented legacy skills. Entity Component Systems (ECS), Unity (C#) / Godot (GDScript) integration, physics calculations, deterministic engine state, WebGL memory management, multiplayer sync architectures (deterministic lockstep vs traditional authoritative), spatial partitioning, and rendering pipelines."
+version: 5.0.0
+last-updated: 2026-09-13
+skills:
+  - game-design-expert
+  - csharp-developer
+  - 60fps-animation
+tools: Read, Grep, Glob, Bash, Edit, Write
+scripts-binding:
+  - .agent/scripts/lint_runner.js
+  - .agent/scripts/verify_all.js
+---
+
+# Game Engineering Expert — Performance & State Mastery
+
+---
+
+## 🛠️ Technical Architecture & Reference Recipes
+
+---
+
+## Hallucination Traps (Read First)
+
+- ❌ Using deltaTime without clamping -> ✅ Unclamped deltaTime causes physics explosions on frame spikes; clamp to max 0.05s
+- ❌ Allocating memory in the game loop (new objects, arrays) -> ✅ Pre-allocate and pool objects to avoid GC pauses during gameplay
+- ❌ Using floating-point equality checks for game state -> ✅ Use epsilon comparisons or integer-based fixed-point for deterministic logic
+
+---
+
+---
+
+## 1. Frame Rate Architecture (The Update Loop)
+
+In web development, we await Promises. In game development, we calculate Delta Time continuously.
+
+```csharp
+// ❌ BAD: Frame-rate dependent logic
+// If the game runs at 120 FPS, the character moves twice as fast as on 60 FPS
+void Update() {
+    transform.position += currentSpeed;
+}
+
+// ✅ GOOD: Frame-independent physics (Unity C# Example)
+void Update() {
+    // DeltaTime is the time elapsed since the last frame
+    transform.position += currentVelocity * Time.deltaTime;
+}
+```
+
+### FixedUpdate vs Update (The Physics Boundary)
+
+- `Update()` fires as fast as the GPU/CPU can draw. Used for User Input and visual animation interpolations.
+- `FixedUpdate()` fires at absolute strict mathematical intervals (e.g., 50 times a second exactly). ALL Physics interactions (`AddForce()`, collision sweeps) MUST live here to prevent tearing and tunneling.
+
+---
+
+## 2. Memory Pooling (Garbage Collection Death)
+
+In Node.js, V8 cleans up objects eventually. In Game Engines, allocating memory creates "Garbage", which forces the Garbage Collector (GC) to pause the entire game to clean up, causing massive micro-stutters.
+
+```csharp
+// ❌ FATAL (in Update loops): Creating new objects 60x a second
+void Update() {
+    Instantiate(bulletPrefab, gun.position, gun.rotation); // Kills the CPU
+}
+
+// ✅ EFFICIENT: Object Pooling
+// Pre-allocate 100 bullets during the Loading Screen.
+// Then simply toggle their active state natively.
+void Fire() {
+    Bullet b = bulletPool.GetDisabledBullet();
+    b.transform.position = gun.position;
+    b.gameObject.SetActive(true);
+}
+```
+
+---
+
+## 3. Entity Component Systems (ECS)
+
+Traditional Object-Oriented Programming (OOP) inheritance hierarchies break down in game engines.
+(e.g., `Enemy` inherits from `Character` which inherits from `Renderable`). What happens when you want a `Renderable` that isn't a `Character` but acts like an `Enemy` (like a deadly spike trap)?
+
+**Use ECS.**
+
+1. **Entities:** Just a meaningless ID (e.g., `Entity 304`).
+2. **Components:** Pure localized data structs attached to an ID (e.g., `Position {x: 5, y: 10}`, `Health {hp: 100}`).
+3. **Systems:** Logic that maps continuously over structs (e.g., `MovementSystem` iterates over ALL Entities that specifically have both a `Position` AND `Velocity` component).
+
+---
+
+## 4. Multiplayer Architectures
+
+Never trust the client. A multiplayer architecture dictates latency fundamentally.
+
+1. **Deterministic Lockstep (RTS / Fighting Games):**
+   - Transmits absolute ZERO game state (coordinates).
+   - Only transmits _inputs_ (Player A clicked Coordinate X).
+   - Both machines run the identical physics frame simultaneously.
+   - Extremely bandwidth efficient, but requires identical CPU math output (impossible in JS floating point Math).
+
+2. **Server Authoritative with Client Prediction (Modern FPS/Action):**
+   - The Server runs the "Real" game.
+   - The Client tells the server "I fired."
+   - Because Ping takes 50ms, the Client _predicts_ the shot landing locally (optimistic UI) so the player doesn't feel lag.
+   - If the server eventually disagrees, the Client aggressively rewinds and snaps the state to match the Server reality (Rubber-banding).