tribunal-kit 9.2.4 → 9.2.6

package/.agent/skills/webapp-testing/SKILL.md

@@ -1,8 +1,8 @@
 ---
 name: webapp-testing
-description: "Use when Comprehensive Web Application Testing strategy. Test Pyramid, Vitest/Jest for unit logic, React Testing Library for component integrity, MSW (Mock Service Worker) for API layer simulation, and visual regression. Use when setting up testing environments or defining global test strategies across a web stack."
-version: 5.0.0
-last-updated: 2026-09-13
+description: "Use when writing, maintaining, executing, and auditing webapp testing test suites, assertions, mocks, and verification gates."
+version: 6.0.0
+last-updated: 2026-09-29
 skills:
   - testing-patterns
   - playwright-best-practices
@@ -16,113 +16,171 @@ scripts-binding:
 
 # Webapp Testing — Full Stack Pipeline Mastery
 
----
-
-## 🛠️ Technical Architecture & Reference Recipes
+## Mandatory Pre-Flight Context Inspection
+Before reading, generating, or refactoring code in the `webapp-testing` 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 writing, maintaining, executing, and auditing webapp testing test suites, assertions, mocks, and verification gates.
+- **DO NOT activate when:** The task falls outside the `webapp-testing` domain or is managed by a different dedicated specialist agent.
 
-- ❌ Mocking everything in integration tests -> ✅ Integration tests verify real interactions; mock only external services (APIs, DBs)
-- ❌ Testing Library: using `getByTestId` as the primary selector -> ✅ Prefer `getByRole`, `getByLabelText`, `getByText` for user-centric testing
-- ❌ Writing E2E tests that depend on seed data -> ✅ Each test should create its own data in setup and clean up in teardown
 
----
-
----
+## 🔁 Multi-Pass Execution Protocol
 
-## 1. The Strategy (The Testing Trophy)
+| Pass | Phase | Core Action | Adaptive Depth |
+|:---|:---|:---|:---|
+| **Pass 1** | **Understand** | Deconstruct the user's explicit objective, implicit requirements, and platform constraints. | Fast / Standard / Deep |
+| **Pass 2** | **Plan** | Decompose task into smallest logical steps; map dependencies, affected files, and tool calls. | Standard / Deep |
+| **Pass 3** | **Execute** | Implement solution with production-grade craft, zero placeholders, and strict typing. | All Modes |
+| **Pass 4** | **Verify** | Run linters, unit tests, or compiler checks to validate structural correctness. | All Modes |
+| **Pass 5** | **Attack & Falsify** | Perform adversarial search for edge-case failures, counterexamples, race conditions, and traps. | Standard / Deep |
+| **Pass 6** | **Harden** | Eliminate discovered friction, optimize performance, and harden error boundaries. | Standard / Deep |
+| **Pass 7** | **Quality Gate** | Enforce Verification-Before-Completion (VBC) with concrete terminal proof before finalizing. | All Modes |
 
-The traditional "Testing Pyramid" (lots of Unit, little E2E) is outdated for rich UI applications. Use the **Testing Trophy**:
 
-1. **Static Analysis (10%)**: TypeScript, ESLint, Prettier (Catches typos and type mismatches instantly).
-2. **Unit Tests (20%)**: Vitest (Tests complex pure functions: math, formatting, data mapping).
-3. **Integration Tests (60%)**: React Testing Library + MSW (Tests components and network mock interactions together).
-4. **End-to-End Tests (10%)**: Playwright (Tests the critical path: Login, Checkout, Account Creation on a real browser).
+---
+
+## 🛠️ Technical Architecture & Reference Recipes
 
+## Hallucination Traps (Read First)
+
+- ❌ Mocking everything in integration tests -> ✅ Integration tests verify real interactions; mock only external services (APIs, DBs)
+- ❌ Testing Library: using `getByTestId` as the primary selector -> ✅ Prefer `getByRole`, `getByLabelText`, `getByText` for user-centric testing
+- ❌ Writing E2E tests that depend on seed data -> ✅ Each test should create its own data in setup and clean up in teardown
+
 ---
-
-## 2. Integration Layer (React Testing Library + MSW)
-
-Do not mock child components. Render the specific DOM tree and interact with it as a user would.
-
-To prevent network calls, utilize Mock Service Worker (MSW) which intercepts requests at the network layer natively.
-
-```typescript
-// ❌ BAD: Mocking implementation details
-jest.mock('axios');
-axios.get.mockResolvedValue({ data: { users: [] } });
-
-// ✅ GOOD: MSW (Mock Service Worker) network level interception
-// The component functions EXACTLY as it would in production
-import { http, HttpResponse } from 'msw';
-import { setupServer } from 'msw/node';
-
-export const handlers = [
-  http.get('/api/users', () => {
-    return HttpResponse.json([{ id: 1, name: 'John Appleseed' }]);
-  }),
-];
-const server = setupServer(...handlers);
-
-beforeAll(() => server.listen());
-afterEach(() => server.resetHandlers());
-afterAll(() => server.close());
+## 1. The Strategy (The Testing Trophy)
+
+The traditional "Testing Pyramid" (lots of Unit, little E2E) is outdated for rich UI applications. Use the **Testing Trophy**:
+
+1. **Static Analysis (10%)**: TypeScript, ESLint, Prettier (Catches typos and type mismatches instantly).
+2. **Unit Tests (20%)**: Vitest (Tests complex pure functions: math, formatting, data mapping).
+3. **Integration Tests (60%)**: React Testing Library + MSW (Tests components and network mock interactions together).
+4. **End-to-End Tests (10%)**: Playwright (Tests the critical path: Login, Checkout, Account Creation on a real browser).
+
+---
+
+## 2. Integration Layer (React Testing Library + MSW)
+
+Do not mock child components. Render the specific DOM tree and interact with it as a user would.
+
+To prevent network calls, utilize Mock Service Worker (MSW) which intercepts requests at the network layer natively.
+
+```typescript
+// ❌ BAD: Mocking implementation details
+jest.mock('axios');
+axios.get.mockResolvedValue({ data: { users: [] } });
+
+// ✅ GOOD: MSW (Mock Service Worker) network level interception
+// The component functions EXACTLY as it would in production
+import { http, HttpResponse } from 'msw';
+import { setupServer } from 'msw/node';
+
+export const handlers = [
+  http.get('/api/users', () => {
+    return HttpResponse.json([{ id: 1, name: 'John Appleseed' }]);
+  }),
+];
+const server = setupServer(...handlers);
+
+beforeAll(() => server.listen());
+afterEach(() => server.resetHandlers());
+afterAll(() => server.close());
+```
+
+### Component Testing (RTL)
+
+```typescript
+import { render, screen, waitFor } from '@testing-library/react';
+import userEvent from '@testing-library/user-event';
+
+test('Should load users and render names', async () => {
+  // userEvent closely replicates real browser physics (focusing, keystrokes)
+  const user = userEvent.setup();
+
+  render(<UserDashboard />);
+
+  // Initial State
+  expect(screen.getByText('Loading...')).toBeInTheDocument();
+
+  // Async Resolution (Auto-waits for the MSW mock to return)
+  const johnNode = await screen.findByText('John Appleseed');
+  expect(johnNode).toBeInTheDocument();
+
+  // Interaction
+  const deleteBtn = screen.getByRole('button', { name: "Delete John" });
+  await user.click(deleteBtn);
+
+  // Verification
+  expect(johnNode).not.toBeInTheDocument();
+});
+```
+
+---
+
+## 3. Pure Unit Testing (Vitest)
+
+Isolate business logic entirely from React.
+
+```typescript
+// ✅ Move complex logic OUT of the React component entirely
+export function calculateTax(subtotal: number, state: string): number {
+  if (subtotal < 0) throw new Error('Subtotal cannot be negative');
+  if (state === 'CA') return subtotal * 0.0825;
+  return 0; // Default
+}
+
+// ✅ Test with extreme precision and coverage
+import { describe, it, expect } from 'vitest';
+
+describe('calculateTax()', () => {
+  it('applies CA tax correctly', () => {
+    expect(calculateTax(100, 'CA')).toBe(8.25);
+  });
+
+  it('throws on negative input', () => {
+    expect(() => calculateTax(-50, 'CA')).toThrowError('negative');
+  });
+});
 ```
 
-### Component Testing (RTL)
-
-```typescript
-import { render, screen, waitFor } from '@testing-library/react';
-import userEvent from '@testing-library/user-event';
+## 🚨 Edge-Case & Failure Mode Matrix
 
-test('Should load users and render names', async () => {
-  // userEvent closely replicates real browser physics (focusing, keystrokes)
-  const user = userEvent.setup();
+| 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 |
 
-  render(<UserDashboard />);
 
-  // Initial State
-  expect(screen.getByText('Loading...')).toBeInTheDocument();
+## 🏛️ Tribunal Verification & Guardrails
 
-  // Async Resolution (Auto-waits for the MSW mock to return)
-  const johnNode = await screen.findByText('John Appleseed');
-  expect(johnNode).toBeInTheDocument();
+**Active Reviewers:** `test-engineer` · `qa-automation-engineer` · `logic-reviewer`
+**Slash Command:** `/review` or `/tribunal-full`
 
-  // Interaction
-  const deleteBtn = screen.getByRole('button', { name: "Delete John" });
-  await user.click(deleteBtn);
+### 🔬 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.
 
-  // Verification
-  expect(johnNode).not.toBeInTheDocument();
-});
+### ✅ Pre-Flight Self-Audit Checklist
 ```
-
----
-
-## 3. Pure Unit Testing (Vitest)
-
-Isolate business logic entirely from React.
-
-```typescript
-// ✅ Move complex logic OUT of the React component entirely
-export function calculateTax(subtotal: number, state: string): number {
-  if (subtotal < 0) throw new Error('Subtotal cannot be negative');
-  if (state === 'CA') return subtotal * 0.0825;
-  return 0; // Default
-}
-
-// ✅ Test with extreme precision and coverage
-import { describe, it, expect } from 'vitest';
-
-describe('calculateTax()', () => {
-  it('applies CA tax correctly', () => {
-    expect(calculateTax(100, 'CA')).toBe(8.25);
-  });
-
-  it('throws on negative input', () => {
-    expect(() => calculateTax(-50, 'CA')).toThrowError('negative');
-  });
-});
+✅ Do tests follow behavioral GIVEN/WHEN/THEN specifications?
+✅ Are happy path, failure paths, and boundary conditions (0, null, max, unicode) covered?
+✅ Are test mocks isolated and reset between successive test cases?
+✅ Do E2E locators rely on stable ARIA attributes instead of brittle CSS selectors?
+✅ Did I verify test suite passes deterministically without flaky race conditions?
 ```
+
+### 🛑 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/.agent/skills/webgpu-performance/SKILL.md

@@ -1,8 +1,8 @@
 ---
 name: webgpu-performance
-description: "Use when 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."
-version: 5.0.0
-last-updated: 2026-09-13
+description: "Use when executing, coordinating, planning, or reviewing webgpu performance agent workflows, cognitive loops, and architecture standards."
+version: 6.0.0
+last-updated: 2026-09-29
 skills:
   - 60fps-animation
   - fixing-motion-performance
@@ -15,74 +15,144 @@ scripts-binding:
 
 # WebGPU Performance Mastery
 
----
+## Mandatory Pre-Flight Context Inspection
+Before reading, generating, or refactoring code in the `webgpu-performance` domain, inspect these 5 critical parameters:
+1. **System Boundaries & Dependencies**: Verify that all required dependencies exist in target package manifests and environment paths.
+2. **Runtime Context & Platform Invariants**: Confirm target platform constraints (Node.js, Browser, Mobile OS, Edge runtime) before applying APIs.
+3. **Execution Guardrails**: Identify potential side-effects, state mutations, and unhandled asynchronous exceptions.
+4. **Validation & Type Contracts**: Validate input data schemas and strict type constraints across all module interfaces.
+5. **Observability & Proof of Execution**: Ensure execution produces tangible verification signals (terminal output, tests, metrics).
 
-## 🛠️ Technical Architecture & Reference Recipes
 
----
+## Activation Boundaries
+- **Activate when:** Use when executing, coordinating, planning, or reviewing webgpu performance agent workflows, cognitive loops, and architecture standards.
+- **DO NOT activate when:** The task falls outside the `webgpu-performance` domain or is managed by a different dedicated specialist agent.
 
-## 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.
+## 🔁 Multi-Pass Execution Protocol
 
-## 2. WGSL Compute Shader Pattern
+| 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 |
 
-When performing parallel calculations (e.g., particle physics or ML matrix multiplication):
 
-```wgsl
-struct SystemData {
-    deltaTime: f32,
-    particleCount: u32,
-}
+---
+
+## 🛠️ Technical Architecture & Reference Recipes
+
+## 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.
 
-@group(0) @binding(0) var<uniform> data: SystemData;
-@group(0) @binding(1) var<storage, read_write> particles: array<vec4<f32>>;
+## 🚨 Edge-Case & Failure Mode Matrix
 
-@compute @workgroup_size(64)
-fn main(@builtin(global_invocation_id) global_id: vec3<u32>) {
-    let index = global_id.x;
-    if (index >= data.particleCount) { return; }
+| 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 |
 
-    var pos = particles[index];
-    pos.y -= 9.8 * data.deltaTime; // Gravity
-    particles[index] = pos;
-}
-```
 
-## 3. WebGPU Execution Pipeline
+## 🤖 LLM-Specific Traps Table
 
-To run the above compute shader from TypeScript:
+| Anti-Pattern | What AI Commonly Does Wrong | What Is Actually Correct |
+|:---|:---|:---|
+| **Hallucinated Tool Capabilities** | Assuming an external library or CLI command exists without verification | Run a verification check or verify package.json before referencing tools |
+| **Premature Completion Claim** | Declaring a task finished because code was generated without verification | Execute tests, linters, or terminal commands to provide concrete proof |
+| **Context Bloat Dumping** | Pasting entire multi-thousand-line files into prompt context | Extract targeted excerpts, symbols, and signatures to preserve tokens |
 
-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
+## 🏛️ Tribunal Verification & Guardrails
 
-- **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.
+**Active Reviewers:** `orchestrator` · `agent-organizer` · `logic-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
+```
+✅ 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?
+```
 
-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 test suites, compiler success, or equivalent operational proof) that your output works as intended.