tribunal-kit 9.2.4 → 9.2.6

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

@@ -1,8 +1,8 @@
 ---
 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
+description: "Use when executing, coordinating, planning, or reviewing game engineering expert agent workflows, cognitive loops, and architecture standards."
+version: 6.0.0
+last-updated: 2026-09-29
 skills:
   - game-design-expert
   - csharp-developer
@@ -15,94 +15,152 @@ scripts-binding:
 
 # Game Engineering Expert — Performance & State Mastery
 
----
-
-## 🛠️ Technical Architecture & Reference Recipes
+## Mandatory Pre-Flight Context Inspection
+Before reading, generating, or refactoring code in the `game-engineering-expert` 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).
 
----
 
-## Hallucination Traps (Read First)
+## Activation Boundaries
+- **Activate when:** Use when executing, coordinating, planning, or reviewing game engineering expert agent workflows, cognitive loops, and architecture standards.
+- **DO NOT activate when:** The task falls outside the `game-engineering-expert` domain or is managed by a different dedicated specialist agent.
 
-- ❌ 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
 
----
-
----
+## 🔁 Multi-Pass Execution Protocol
 
-## 1. Frame Rate Architecture (The Update Loop)
+| 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 |
 
-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);
-}
-```
+---
+
+## 🛠️ 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).
 
-## 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)?
+## 🚨 Edge-Case & Failure Mode Matrix
 
-**Use ECS.**
+| 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 |
 
-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).
 
----
+## 🏛️ Tribunal Verification & Guardrails
 
-## 4. Multiplayer Architectures
+**Active Reviewers:** `orchestrator` · `agent-organizer` · `logic-reviewer`
+**Slash Command:** `/review` or `/tribunal-full`
 
-Never trust the client. A multiplayer architecture dictates latency fundamentally.
+### 🔬 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.
 
-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).
+### ✅ 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?
+```
 
-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).
+### 🛑 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/generative-ui-expert/SKILL.md

@@ -1,8 +1,8 @@
 ---
 name: generative-ui-expert
-description: "Use when 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."
-version: 5.0.0
-last-updated: 2026-09-13
+description: "Use when designing, implementing, auditing, and hardening generative ui expert server logic, APIs, background jobs, and error boundaries."
+version: 6.0.0
+last-updated: 2026-09-29
 skills:
   - nextjs-react-expert
   - react-specialist
@@ -15,86 +15,156 @@ scripts-binding:
 
 # Generative UI Expert (Vercel AI SDK)
 
----
+## Mandatory Pre-Flight Context Inspection
+Before reading, generating, or refactoring code in the `generative-ui-expert` 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 designing, implementing, auditing, and hardening generative ui expert server logic, APIs, background jobs, and error boundaries.
+- **DO NOT activate when:** The task falls outside the `generative-ui-expert` 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
 
----
+## 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`).
 
-## 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} />;
-            }
-          }
-        }
-      });
-    }
-  }
-});
-```
+## 🚨 Edge-Case & Failure Mode Matrix
 
-### B. Structured Output (`streamObject`)
+| 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 |
 
-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
-```
+## 🤖 LLM-Specific Traps Table
 
-## 3. Client-Side State Management
+| Anti-Pattern | What AI Commonly Does Wrong | What Is Actually Correct |
+|:---|:---|:---|
+| **Unchecked Payload Cast** | Casting request bodies to TypeScript types without runtime schema validation | Parse request payloads through Zod/Pydantic schemas before business logic |
+| **Silent Error Swallowing** | Catching errors with empty catch blocks or logging without rethrowing | Propagate structured errors with status codes and contextual stack traces |
+| **Unparameterized Query** | Concatenating user inputs into SQL/Prisma query strings | Always use parameterized bindings or type-safe ORM query builders |
 
-- 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
+## 🏛️ Tribunal Verification & Guardrails
 
-- **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.
+**Active Reviewers:** `logic-reviewer` · `security-auditor` · `api-architect` · `resilience-reviewer`
+**Slash Command:** `/review` or `/tribunal-full`
 
-## Verification Protocol
+### 🔬 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.
 
-Before submitting code, ensure:
+### ✅ Pre-Flight Self-Audit Checklist
+```
+✅ Are all inputs and boundary payloads validated against schemas (Zod/Pydantic)?
+✅ Are SQL and database queries parameterized with zero string concatenation?
+✅ Are error boundaries and timeout/retry policies explicitly declared?
+✅ Are authentication and object-level authorization (IDOR/BOLA) checked before business logic?
+✅ Did I verify that imported dependencies exist in package manifests?
+```
 
-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 test suites, compiler success, or equivalent operational proof) that your output works as intended.