tribunal-kit 9.2.4 → 9.2.6

package/.agent/skills/apple-design/SKILL.md

@@ -1,8 +1,8 @@
 ---
 name: apple-design
-description: "Use when Apple's approach to interface design and fluid, physical motion, translated for the web. Use when building or reviewing gesture-driven UI, spring animations, drag/swipe/sheet interactions, momentum and interruptible transitions, translucent materials and depth, typography (optical sizing, tracking, leading), reduced-motion, or the design foundations behind Apple-style interfaces."
-version: 5.0.0
-last-updated: 2026-09-13
+description: "Use when building, styling, optimizing, and auditing apple design components, responsive layouts, design systems, and frontend state."
+version: 6.0.0
+last-updated: 2026-09-29
 skills:
   - soft-skill
   - emil-design-eng
@@ -15,75 +15,145 @@ scripts-binding:
 
 # Apple Design — Fluid Motion, Physicality & Translucent Depth
 
----
+## Mandatory Pre-Flight Context Inspection
+Before reading, generating, or refactoring code in the `apple-design` 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 building, styling, optimizing, and auditing apple design components, responsive layouts, design systems, and frontend state.
+- **DO NOT activate when:** The task falls outside the `apple-design` domain or is managed by a different dedicated specialist agent.
 
----
 
-## 1. Physics-Based Spring Animations
+## 🔁 Multi-Pass Execution Protocol
 
-Apple interfaces do NOT use fixed-duration cubic-beziers for interactive elements; they use **physics-based springs**.
+| 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 |
 
-- **Interruptibility**: Animations MUST be interruptible. If a user taps or drags mid-animation, the spring seamlessly absorbs current velocity without snapping to standard origin.
-- **Spring Parameters**:
-  - **Overdamped (Solid/Restrained)**: `mass: 1, stiffness: 200, damping: 25` (Modals, Sheets, Drawers)
-  - **Snappy (Buttons/Toggles)**: `mass: 0.5, stiffness: 350, damping: 20` (Pills, Switches, Keypad)
-  - **Bouncy (Micro-delight)**: `mass: 0.8, stiffness: 400, damping: 15` (Badges, Tooltips, Success Checkmarks)
 
-```javascript
-// Framer Motion / Motion React Spring Config
-const appleSpring = {
-  type: 'spring',
-  stiffness: 300,
-  damping: 24,
-  mass: 0.8,
-};
-```
+---
+
+## 🛠️ Technical Architecture & Reference Recipes
 
----
+---
+
+## 1. Physics-Based Spring Animations
+
+Apple interfaces do NOT use fixed-duration cubic-beziers for interactive elements; they use **physics-based springs**.
+
+- **Interruptibility**: Animations MUST be interruptible. If a user taps or drags mid-animation, the spring seamlessly absorbs current velocity without snapping to standard origin.
+- **Spring Parameters**:
+  - **Overdamped (Solid/Restrained)**: `mass: 1, stiffness: 200, damping: 25` (Modals, Sheets, Drawers)
+  - **Snappy (Buttons/Toggles)**: `mass: 0.5, stiffness: 350, damping: 20` (Pills, Switches, Keypad)
+  - **Bouncy (Micro-delight)**: `mass: 0.8, stiffness: 400, damping: 15` (Badges, Tooltips, Success Checkmarks)
+
+```javascript
+// Framer Motion / Motion React Spring Config
+const appleSpring = {
+  type: 'spring',
+  stiffness: 300,
+  damping: 24,
+  mass: 0.8,
+};
+```
+
+---
+
+## 2. Translucent Materials & Multi-Layer Blur
+
+Apple depth relies on subtle, multi-layered backdrop blur and border highlights:
+
+```css
+.apple-glass-panel {
+  background: rgba(255, 255, 255, 0.72);
+  backdrop-filter: blur(20px) saturate(180%);
+  -webkit-backdrop-filter: blur(20px) saturate(180%);
+  border: 1px solid rgba(255, 255, 255, 0.3);
+  box-shadow:
+    0 1px 2px 0 rgba(0, 0, 0, 0.05),
+    0 8px 24px -4px rgba(0, 0, 0, 0.08);
+}
+
+@media (prefers-color-scheme: dark) {
+  .apple-glass-panel {
+    background: rgba(26, 26, 32, 0.75);
+    border: 1px solid rgba(255, 255, 255, 0.08);
+    box-shadow:
+      0 1px 2px 0 rgba(0, 0, 0, 0.2),
+      0 12px 32px -8px rgba(0, 0, 0, 0.4);
+  }
+}
+```
+
+---
+
+## 3. Optical Typography & Dynamic Tracking
+
+- **Optical Letter-Spacing (SF Pro Standard)**: Larger titles require tighter tracking (`-0.025em`), while caption text requires positive tracking (`+0.015em`).
+- **Dynamic Line Heights**: `1.1` for large titles, `1.4` to `1.5` for body text.
+
+---
+
+## Anti-Slop Table
+
+| Anti-Pattern                  | Apple Design Solution                                         | Rationale                                       |
+| ----------------------------- | ------------------------------------------------------------- | ----------------------------------------------- |
+| Rigid linear/ease transitions | Physics-based spring curves (`stiffness: 300, damping: 24`)   | Simulates real-world physical momentum          |
+| Opaque static dropdowns       | Translucent backdrop blur panel (`blur(20px) saturate(180%)`) | Preserves spatial context beneath UI            |
+| Sudden state jumps            | Interruptible velocity-preserving spring animations           | Prevents visual jarring during rapid user input |
 
-## 2. Translucent Materials & Multi-Layer Blur
-
-Apple depth relies on subtle, multi-layered backdrop blur and border highlights:
-
-```css
-.apple-glass-panel {
-  background: rgba(255, 255, 255, 0.72);
-  backdrop-filter: blur(20px) saturate(180%);
-  -webkit-backdrop-filter: blur(20px) saturate(180%);
-  border: 1px solid rgba(255, 255, 255, 0.3);
-  box-shadow:
-    0 1px 2px 0 rgba(0, 0, 0, 0.05),
-    0 8px 24px -4px rgba(0, 0, 0, 0.08);
-}
-
-@media (prefers-color-scheme: dark) {
-  .apple-glass-panel {
-    background: rgba(26, 26, 32, 0.75);
-    border: 1px solid rgba(255, 255, 255, 0.08);
-    box-shadow:
-      0 1px 2px 0 rgba(0, 0, 0, 0.2),
-      0 12px 32px -8px rgba(0, 0, 0, 0.4);
-  }
-}
-```
+## 🚨 Edge-Case & Failure Mode Matrix
 
----
+| 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 |
 
-## 3. Optical Typography & Dynamic Tracking
 
-- **Optical Letter-Spacing (SF Pro Standard)**: Larger titles require tighter tracking (`-0.025em`), while caption text requires positive tracking (`+0.015em`).
-- **Dynamic Line Heights**: `1.1` for large titles, `1.4` to `1.5` for body text.
+## 🤖 LLM-Specific Traps Table
 
----
+| Anti-Pattern | What AI Commonly Does Wrong | What Is Actually Correct |
+|:---|:---|:---|
+| **Uncontrolled Re-render Loop** | Mutating state inside render bodies or omitting hook dependencies | Wrap effects with explicit deps and isolate reactive derivations in useMemo |
+| **Accessibility Neglect** | Interactive <div> without role="button", tabIndex, or onKeyDown | Use semantic <button> or provide ARIA role, keyboard handlers, and focus ring |
+| **Layout Shift Flash** | Images/dynamic content without aspect-ratio or explicit dimensions | Enforce aspect-ratio or skeleton placeholders to guarantee zero CLS |
 
-## Anti-Slop Table
 
-| Anti-Pattern                  | Apple Design Solution                                         | Rationale                                       |
-| ----------------------------- | ------------------------------------------------------------- | ----------------------------------------------- |
-| Rigid linear/ease transitions | Physics-based spring curves (`stiffness: 300, damping: 24`)   | Simulates real-world physical momentum          |
-| Opaque static dropdowns       | Translucent backdrop blur panel (`blur(20px) saturate(180%)`) | Preserves spatial context beneath UI            |
-| Sudden state jumps            | Interruptible velocity-preserving spring animations           | Prevents visual jarring during rapid user input |
+## 🏛️ Tribunal Verification & Guardrails
+
+**Active Reviewers:** `frontend-reviewer` · `type-safety` · `ui-ux-auditor` · `complexity-reviewer`
+**Slash Command:** `/review` or `/tribunal-full`
+
+### 🔬 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.
+
+### ✅ Pre-Flight Self-Audit Checklist
+```
+✅ Are all component props strictly typed with zero implicit "any"?
+✅ Are responsive breakpoints, fluid typography, and optical balance verified?
+✅ Is accessibility (ARIA labels, keyboard navigation, contrast ratio >= 4.5:1) validated?
+✅ Are re-renders minimized and state lifecycles cleanly separated?
+✅ Did I verify all imported UI components and icon sets actually exist?
+```
+
+### 🛑 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/architecture/SKILL.md

@@ -1,8 +1,8 @@
 ---
 name: architecture
-description: "Use when Software architecture mastery. System design patterns, clean architecture, hexagonal/ports-and-adapters, event-driven architecture, microservices vs monolith decision framework, CQRS, domain-driven design, Architecture Decision Records (ADRs), and scalability patterns. Use when making architecture decisions, designing systems, or documenting technical decisions."
-version: 5.0.0
-last-updated: 2026-09-13
+description: "Use when executing, coordinating, planning, or reviewing architecture agent workflows, cognitive loops, and architecture standards."
+version: 6.0.0
+last-updated: 2026-09-29
 skills:
   - domain-modeling
   - codebase-design
@@ -15,174 +15,235 @@ scripts-binding:
 
 # Architecture — System Design Mastery
 
----
-
-## 🛠️ Technical Architecture & Reference Recipes
-
----
-
-## Hallucination Traps (Read First)
-
-- ❌ Choosing microservices for a team of 1-3 developers -> ✅ Start monolith, extract services only when team/scale demands it
-- ❌ Using event-driven architecture without understanding eventual consistency -> ✅ Events mean data will be stale; design for it
-- ❌ Skipping ADRs (Architecture Decision Records) -> ✅ Every non-obvious decision needs a written 'why' for future maintainers
-
----
-
-## Architecture Selection
-
-```
-Team size?           Scale?                  Cadence?
-1–5   → Monolith     <10K RPM  → Monolith     Weekly → Monolith
-5–20  → Mod. Mono    <100K RPM → Mono+CDN     Daily  → Modular Mono
-20+   → Microsvcs    >100K RPM → Microsvcs    Per-svc → Microsvcs
-
-❌ Microservices are NOT inherently better.
-   A well-structured monolith beats a poorly designed microservice system.
-   Start monolith. Extract services only when proven necessary.
-```
-
-**3 Questions Before Any Pattern:**
-
-1. What SPECIFIC problem does this pattern solve?
-2. Is there a simpler solution?
-3. Can we add this LATER when proven needed?
-
----
-
-## Clean Architecture (Dependency Rule)
+## Mandatory Pre-Flight Context Inspection
+Before reading, generating, or refactoring code in the `architecture` 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).
 
-```
-Presentation → Application → Domain ← Infrastructure
-              (Controllers)  (Use Cases)  (Entities)  (DB, APIs)
 
-Dependency Rule: arrows point INWARD. Domain knows NOTHING about infra.
-Application defines interfaces (ports). Infrastructure implements them (adapters).
-```
+## Activation Boundaries
+- **Activate when:** Use when executing, coordinating, planning, or reviewing architecture agent workflows, cognitive loops, and architecture standards.
+- **DO NOT activate when:** The task falls outside the `architecture` domain or is managed by a different dedicated specialist agent.
 
-```typescript
-// Domain — pure business logic, zero external dependencies
-interface UserRepository {
-  findById(id: string): Promise<User | null>;
-}
-class User {
-  promote(): void {
-    if (this._role === UserRole.ADMIN) throw new DomainError('Already admin');
-    this._role = UserRole.ADMIN;
-  }
-}
-
-// Application — orchestrates use cases
-class PromoteUserUseCase {
-  async execute(userId: string): Promise<void> {
-    const user = await this.userRepo.findById(userId);
-    if (!user) throw new NotFoundError('User', userId);
-    user.promote();
-    await this.userRepo.save(user);
-    await this.eventBus.publish(new UserPromotedEvent(userId));
-  }
-}
-
-// Infrastructure — concrete implementations of ports
-class PostgresUserRepository implements UserRepository {
-  async findById(id: string) {
-    /* db.query(...) */
-  }
-}
-```
 
----
+## 🔁 Multi-Pass Execution Protocol
 
-## CQRS
+| 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 |
 
-```
-Commands (Write) → Normalized Write DB
-Queries  (Read)  → Denormalized/Cached Read Model
 
-When to use:  ✅ Read/write patterns diverge  ✅ 10:1+ read:write ratio  ✅ Event sourcing
-When NOT to:  ❌ Simple CRUD  ❌ Team < 3 devs  ❌ Read/write models are identical
-```
-
----
-
-## Event-Driven Architecture
+---
+
+## 🛠️ Technical Architecture & Reference Recipes
 
+## Hallucination Traps (Read First)
+
+- ❌ Choosing microservices for a team of 1-3 developers -> ✅ Start monolith, extract services only when team/scale demands it
+- ❌ Using event-driven architecture without understanding eventual consistency -> ✅ Events mean data will be stale; design for it
+- ❌ Skipping ADRs (Architecture Decision Records) -> ✅ Every non-obvious decision needs a written 'why' for future maintainers
+
+---
+
+## Architecture Selection
+
+```
+Team size?           Scale?                  Cadence?
+1–5   → Monolith     <10K RPM  → Monolith     Weekly → Monolith
+5–20  → Mod. Mono    <100K RPM → Mono+CDN     Daily  → Modular Mono
+20+   → Microsvcs    >100K RPM → Microsvcs    Per-svc → Microsvcs
+
+❌ Microservices are NOT inherently better.
+   A well-structured monolith beats a poorly designed microservice system.
+   Start monolith. Extract services only when proven necessary.
+```
+
+**3 Questions Before Any Pattern:**
+
+1. What SPECIFIC problem does this pattern solve?
+2. Is there a simpler solution?
+3. Can we add this LATER when proven needed?
+
+---
+
+## Clean Architecture (Dependency Rule)
+
+```
+Presentation → Application → Domain ← Infrastructure
+              (Controllers)  (Use Cases)  (Entities)  (DB, APIs)
+
+Dependency Rule: arrows point INWARD. Domain knows NOTHING about infra.
+Application defines interfaces (ports). Infrastructure implements them (adapters).
+```
+
+```typescript
+// Domain — pure business logic, zero external dependencies
+interface UserRepository {
+  findById(id: string): Promise<User | null>;
+}
+class User {
+  promote(): void {
+    if (this._role === UserRole.ADMIN) throw new DomainError('Already admin');
+    this._role = UserRole.ADMIN;
+  }
+}
+
+// Application — orchestrates use cases
+class PromoteUserUseCase {
+  async execute(userId: string): Promise<void> {
+    const user = await this.userRepo.findById(userId);
+    if (!user) throw new NotFoundError('User', userId);
+    user.promote();
+    await this.userRepo.save(user);
+    await this.eventBus.publish(new UserPromotedEvent(userId));
+  }
+}
+
+// Infrastructure — concrete implementations of ports
+class PostgresUserRepository implements UserRepository {
+  async findById(id: string) {
+    /* db.query(...) */
+  }
+}
+```
+
+---
+
+## CQRS
+
+```
+Commands (Write) → Normalized Write DB
+Queries  (Read)  → Denormalized/Cached Read Model
+
+When to use:  ✅ Read/write patterns diverge  ✅ 10:1+ read:write ratio  ✅ Event sourcing
+When NOT to:  ❌ Simple CRUD  ❌ Team < 3 devs  ❌ Read/write models are identical
+```
+
+---
+
+## Event-Driven Architecture
+
+```
+Event Types:
+  Domain Events      → "OrderPlaced" within a bounded context
+  Integration Events → Cross-service via message queue
+  Notification Events → Fire-and-forget (logging, analytics)
+
+Broker Selection:
+  BullMQ / Redis Streams → Simple, single-service queues
+  RabbitMQ               → Complex routing, dead-letter queues
+  Apache Kafka           → High throughput, replay, event log
+  AWS SQS/SNS            → Managed, serverless-friendly
+
+Outbox Pattern (reliable publishing):
+  1. Save entity + event in ONE DB transaction
+  2. Background worker polls outbox → publishes to broker
+  3. Mark as published → guarantees at-least-once delivery
+```
+
+---
+
+## Anti-Patterns Reference
+
+| Pattern         | When it's an Anti-Pattern                   | Simpler Alternative              |
+| --------------- | ------------------------------------------- | -------------------------------- |
+| Microservices   | Before team or scale justifies it           | Modular monolith                 |
+| Clean/Hexagonal | Over-abstraction for simple CRUD            | Concrete first, interfaces later |
+| Event Sourcing  | No business requirement for audit/replay    | Append-only audit log            |
+| CQRS            | Simple data model, no read/write divergence | Single model                     |
+| Repository      | Simple CRUD, single database                | ORM direct access                |
+
+---
+
+## Architecture Decision Records (ADRs)
+
+```markdown
+## ADR-001: [Decision Title]
+
+**Status:** Proposed | Accepted | Deprecated | Superseded by ADR-XXX
+
+**Context:** [Problem + constraints: team, scale, timeline]
+
+**Decision:** [What was chosen — be specific]
+
+**Rationale:** [Why — tied to requirements]
+
+**Trade-offs:** [What we consciously give up]
+
+**Consequences:**
+
+- Positive: [Benefits]
+- Negative: [Costs/Risks]
+- Mitigation: [How to address negatives]
+
+**Revisit when:** [Trigger conditions]
+```
+
+ADR storage: `docs/architecture/adr-001-title.md`
+
+---
+
+## Scalability Patterns
+
+```
+Read scaling:   Redis cache → Read replicas → CDN for static assets
+Write scaling:  Queue writes → Partition data → Event sourcing
+Stateless:      Sessions in Redis → JWT → No server affinity
+DB scaling:     Connection pooling → Read replicas → Partitioning → Sharding (last resort)
+Cache layers:   L1: In-memory (process) L2: Redis (shared) L3: CDN (edge)
+```
+
+## Scale-to-Architecture Matrix
+
+```
+                MVP           SaaS          Enterprise
+Scale:          <1K           1K–100K       100K+
+Team:           Solo          2–10          10+
+Architecture:   Simple Mono   Modular Mono  Distributed
+Framework:      Next.js API   NestJS        Microservices
 ```
-Event Types:
-  Domain Events      → "OrderPlaced" within a bounded context
-  Integration Events → Cross-service via message queue
-  Notification Events → Fire-and-forget (logging, analytics)
-
-Broker Selection:
-  BullMQ / Redis Streams → Simple, single-service queues
-  RabbitMQ               → Complex routing, dead-letter queues
-  Apache Kafka           → High throughput, replay, event log
-  AWS SQS/SNS            → Managed, serverless-friendly
-
-Outbox Pattern (reliable publishing):
-  1. Save entity + event in ONE DB transaction
-  2. Background worker polls outbox → publishes to broker
-  3. Mark as published → guarantees at-least-once delivery
-```
-
----
-
-## Anti-Patterns Reference
-
-| Pattern         | When it's an Anti-Pattern                   | Simpler Alternative              |
-| --------------- | ------------------------------------------- | -------------------------------- |
-| Microservices   | Before team or scale justifies it           | Modular monolith                 |
-| Clean/Hexagonal | Over-abstraction for simple CRUD            | Concrete first, interfaces later |
-| Event Sourcing  | No business requirement for audit/replay    | Append-only audit log            |
-| CQRS            | Simple data model, no read/write divergence | Single model                     |
-| Repository      | Simple CRUD, single database                | ORM direct access                |
-
----
-
-## Architecture Decision Records (ADRs)
 
-```markdown
-## ADR-001: [Decision Title]
+## 🚨 Edge-Case & Failure Mode Matrix
 
-**Status:** Proposed | Accepted | Deprecated | Superseded by ADR-XXX
+| 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 |
 
-**Context:** [Problem + constraints: team, scale, timeline]
 
-**Decision:** [What was chosen — be specific]
+## 🏛️ Tribunal Verification & Guardrails
 
-**Rationale:** [Why — tied to requirements]
+**Active Reviewers:** `orchestrator` · `agent-organizer` · `logic-reviewer`
+**Slash Command:** `/review` or `/tribunal-full`
 
-**Trade-offs:** [What we consciously give up]
+### 🔬 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.
 
-**Consequences:**
-
-- Positive: [Benefits]
-- Negative: [Costs/Risks]
-- Mitigation: [How to address negatives]
-
-**Revisit when:** [Trigger conditions]
+### ✅ Pre-Flight Self-Audit Checklist
 ```
-
-ADR storage: `docs/architecture/adr-001-title.md`
-
----
-
-## Scalability Patterns
-
-```
-Read scaling:   Redis cache → Read replicas → CDN for static assets
-Write scaling:  Queue writes → Partition data → Event sourcing
-Stateless:      Sessions in Redis → JWT → No server affinity
-DB scaling:     Connection pooling → Read replicas → Partitioning → Sharding (last resort)
-Cache layers:   L1: In-memory (process) L2: Redis (shared) L3: CDN (edge)
+✅ 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?
 ```
 
-## Scale-to-Architecture Matrix
-
-```
-                MVP           SaaS          Enterprise
-Scale:          <1K           1K–100K       100K+
-Team:           Solo          2–10          10+
-Architecture:   Simple Mono   Modular Mono  Distributed
-Framework:      Next.js API   NestJS        Microservices
-```
+### 🛑 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.