tribunal-kit 9.0.0 → 9.0.2

package/.agents/skills/architecture/SKILL.md

@@ -0,0 +1,263 @@
+---
+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
+skills:
+  - domain-modeling
+  - codebase-design
+  - clean-code
+tools: Read, Grep, Glob, Bash, Edit, Write
+scripts-binding:
+  - .agent/scripts/lint_runner.js
+  - .agent/scripts/verify_all.js
+---
+
+# Architecture — System Design Mastery
+
+## Mandatory Pre-Flight Context Inspection
+
+Before generating, refactoring, or reviewing 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).
+
+## Activation Boundaries
+
+- **Activate when:** 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.
+- **DO NOT activate when:** The task falls outside the `architecture` domain or is managed by a different dedicated specialist.
+
+## 🔁 Multi-Pass Execution Protocol
+
+Execute all non-trivial tasks through this 7-pass cognitive loop:
+
+| Pass | Phase | Core Action |
+|:---|:---|:---|
+| **Pass 1** | **Understand** | Deconstruct the user's explicit objective, implicit requirements, and platform constraints. |
+| **Pass 2** | **Plan** | Decompose the task into smallest logical steps; map dependencies and required tool calls. |
+| **Pass 3** | **Execute** | Implement the solution with production-grade craft, zero placeholders, and strict typing. |
+| **Pass 4** | **Verify** | Run linters, unit tests, or compiler checks to validate structural correctness. |
+| **Pass 5** | **Attack** | Perform an adversarial review searching for edge-case failures, race conditions, and traps. |
+| **Pass 6** | **Improve** | Eliminate discovered friction, optimize performance, and harden error boundaries. |
+| **Pass 7** | **Quality Gate** | Enforce Verification-Before-Completion (VBC) with concrete terminal proof before finalizing. |
+
+---
+
+## 🛠️ 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
+```
+
+---
+
+## 🚨 Edge-Case & Failure Mode Matrix
+
+| Scenario | Risk | Mitigation Strategy |
+|:---|:---|:---|
+| **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 |
+
+---
+
+## 🤖 LLM-Specific Traps Table
+
+| 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 |
+
+---
+
+## 🏛️ Tribunal Verification & Guardrails
+
+**Active Reviewers:** `orchestrator` · `agent-organizer` · `logic-reviewer`
+**Slash Command:** `/review` or `/tribunal-full`
+
+### ✅ 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?
+```
+
+### 🛑 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/.agents/skills/audit-and-fix/SKILL.md

@@ -0,0 +1,136 @@
+---
+name: audit-and-fix
+description: Use when Accessibility auditing and remediation workflow combining detection, prioritization, and practical code fixes for WCAG 2.2 AA compliance issues.
+version: 5.0.0
+last-updated: 2026-09-13
+skills:
+  - fixing-accessibility
+  - build-primitive
+  - baseline-ui
+tools: Read, Grep, Glob, Bash, Edit, Write
+scripts-binding:
+  - .agent/scripts/lint_runner.js
+  - .agent/scripts/verify_all.js
+---
+
+# Audit and Fix — Accessibility Remediation Workflow
+
+## Mandatory Pre-Flight Context Inspection
+
+Before generating, refactoring, or reviewing code in the `audit-and-fix` 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 Accessibility auditing and remediation workflow combining detection, prioritization, and practical code fixes for WCAG 2.2 AA compliance issues.
+- **DO NOT activate when:** The task falls outside the `audit-and-fix` domain or is managed by a different dedicated specialist.
+
+## 🔁 Multi-Pass Execution Protocol
+
+Execute all non-trivial tasks through this 7-pass cognitive loop:
+
+| Pass | Phase | Core Action |
+|:---|:---|:---|
+| **Pass 1** | **Understand** | Deconstruct the user's explicit objective, implicit requirements, and platform constraints. |
+| **Pass 2** | **Plan** | Decompose the task into smallest logical steps; map dependencies and required tool calls. |
+| **Pass 3** | **Execute** | Implement the solution with production-grade craft, zero placeholders, and strict typing. |
+| **Pass 4** | **Verify** | Run linters, unit tests, or compiler checks to validate structural correctness. |
+| **Pass 5** | **Attack** | Perform an adversarial review searching for edge-case failures, race conditions, and traps. |
+| **Pass 6** | **Improve** | Eliminate discovered friction, optimize performance, and harden error boundaries. |
+| **Pass 7** | **Quality Gate** | Enforce Verification-Before-Completion (VBC) with concrete terminal proof before finalizing. |
+
+---
+
+## 🛠️ Technical Architecture & Reference Recipes
+
+---
+
+
+---
+
+## 4-Step Remediation Pipeline
+
+### 1. Automated Violation Detection
+
+Scan component code for:
+
+- Missing `alt` tags on `<img>` elements.
+- Form controls (`<input>`, `<select>`) missing associated `<label>` or `aria-label`.
+- Buttons with icon-only content missing `aria-label`.
+- Non-interactive elements (`<div>`, `<span>`) with `onClick` handlers missing `role="button"` and `tabIndex={0}`.
+
+### 2. Prioritization Matrix
+
+| Severity Level             | Violation Type                                                                   | Remediation Action                                                     |
+| -------------------------- | -------------------------------------------------------------------------------- | ---------------------------------------------------------------------- |
+| 🔴 **Blocker (Level A)**   | Inaccessible form inputs, un-trapped focus in modal, zero keyboard access        | Add explicit `<label>`, focus trap, and keyboard handlers immediately. |
+| 🟠 **Critical (Level AA)** | Low text contrast ratio ($< 4.5:1$), missing ARIA states on custom dropdowns     | Adjust text colors to OKLCH contrast targets; add `aria-expanded`.     |
+| 🟡 **Moderate (Level AA)** | Missing landmark regions (`<main>`, `<nav>`, `<header>`), heading hierarchy gaps | Wrap layout blocks in semantic HTML5 tags.                             |
+
+### 3. Concrete Code Fix Examples
+
+```tsx
+// BEFORE (Inaccessible)
+<div onClick={submitForm} className="btn">Submit</div>
+
+// AFTER (Accessible)
+<button type="submit" onClick={submitForm} className="btn">Submit</button>
+```
+
+```tsx
+// BEFORE (Icon Only Button)
+<button onClick={openSettings}><SettingsIcon /></button>
+
+// AFTER (Accessible Icon Button)
+<button onClick={openSettings} aria-label="Open settings"><SettingsIcon aria-hidden="true" /></button>
+```
+
+---
+
+## 🚨 Edge-Case & Failure Mode Matrix
+
+| Scenario | Risk | Mitigation Strategy |
+|:---|:---|:---|
+| **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 |
+
+---
+
+## 🤖 LLM-Specific Traps Table
+
+| Anti-Pattern | What AI Commonly Does Wrong | What Is Actually Correct |
+|:---|:---|:---|
+| **Hardcoded Secret Pattern** | Committing API keys, tokens, or private salts into source code | Load credentials strictly via runtime environment variables and secret stores |
+| **Prompt Injection Surface** | Directly concatenating untrusted user input into LLM system prompts | Wrap user content in isolated delimiters and strip injection control sequences |
+| **Missing Authorization Check** | Relying only on authentication token presence without checking tenant/object RBAC | Verify user permissions against the specific target record ID before mutation |
+
+---
+
+## 🏛️ Tribunal Verification & Guardrails
+
+**Active Reviewers:** `security-auditor` · `penetration-tester` · `backend-security-expert`
+**Slash Command:** `/review` or `/tribunal-full`
+
+### ✅ Pre-Flight Self-Audit Checklist
+
+```
+✅ Are user inputs sanitized and treated as untrusted at system boundaries?
+✅ Are secrets loaded strictly via environment variables with zero hardcoding?
+✅ Is least-privilege enforcement active on APIs, tokens, and storage buckets?
+✅ Are prompt-injection delimiters and sanitizers wrapped around LLM inputs?
+✅ Did I verify encryption in transit and at rest for sensitive customer data?
+```
+
+### 🛑 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/.agents/skills/authentication-best-practices/SKILL.md

@@ -0,0 +1,232 @@
+---
+name: authentication-best-practices
+description: Use when Authentication and Authorization mastery. Best practices for OAuth2, OpenID Connect, JWT (JSON Web Tokens), session management, password hashing, MFA (Multi-Factor Authentication), RBAC/ABAC, SSO, and secure credential storage. Use when auditing or implementing login flows, identity systems, or access control.
+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
+---
+
+# Authentication & Authorization — Identity Mastery
+
+## Mandatory Pre-Flight Context Inspection
+
+Before generating, refactoring, or reviewing code in the `authentication-best-practices` 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 Authentication and Authorization mastery. Best practices for OAuth2, OpenID Connect, JWT (JSON Web Tokens), session management, password hashing, MFA (Multi-Factor Authentication), RBAC/ABAC, SSO, and secure credential storage. Use when auditing or implementing login flows, identity systems, or access control.
+- **DO NOT activate when:** The task falls outside the `authentication-best-practices` domain or is managed by a different dedicated specialist.
+
+## 🔁 Multi-Pass Execution Protocol
+
+Execute all non-trivial tasks through this 7-pass cognitive loop:
+
+| Pass | Phase | Core Action |
+|:---|:---|:---|
+| **Pass 1** | **Understand** | Deconstruct the user's explicit objective, implicit requirements, and platform constraints. |
+| **Pass 2** | **Plan** | Decompose the task into smallest logical steps; map dependencies and required tool calls. |
+| **Pass 3** | **Execute** | Implement the solution with production-grade craft, zero placeholders, and strict typing. |
+| **Pass 4** | **Verify** | Run linters, unit tests, or compiler checks to validate structural correctness. |
+| **Pass 5** | **Attack** | Perform an adversarial review searching for edge-case failures, race conditions, and traps. |
+| **Pass 6** | **Improve** | Eliminate discovered friction, optimize performance, and harden error boundaries. |
+| **Pass 7** | **Quality Gate** | Enforce Verification-Before-Completion (VBC) with concrete terminal proof before finalizing. |
+
+---
+
+## 🛠️ Technical Architecture & Reference Recipes
+
+---
+
+
+---
+
+## Passwords & Hashing
+
+```typescript
+// ❌ BAD: md5, sha1, sha256 (too fast, vulnerable to brute force/rainbow tables)
+const hash = crypto.createHash('sha256').update(password).digest('hex');
+
+// ✅ GOOD: Argon2 (memory-hard, ASIC resistant) or bcrypt
+import * as argon2 from 'argon2';
+
+async function hashPassword(password: string): Promise<string> {
+  // Argon2 hashes include the salt inherently in the resulting string
+  return await argon2.hash(password, {
+    type: argon2.argon2id, // recommended variant
+    memoryCost: 2 ** 16, // 64 MB
+    timeCost: 3, // iterations
+    parallelism: 1, // threads
+  });
+}
+
+async function verifyPassword(hash: string, password: string): Promise<boolean> {
+  return await argon2.verify(hash, password);
+}
+```
+
+### Password Policies
+
+- **Length over complexity**: Require minimum 12 characters. Stop requiring arbitrary symbols (e.g., `!@#`).
+- **Check against breaches**: Use HaveIBeenPwned API or similar to reject compromised passwords during signup.
+- **Never expire passwords arbitrarily**: Only force resets if there is evidence of a breach.
+
+---
+
+## Session Management vs. JWT
+
+### 1. Stateful Sessions (Cookies)
+
+**Best for**: Monolithic web apps, SSR apps (Next.js, Remix).
+
+- Server stores session ID mapped to user data in Redis/DB.
+- Client stores session ID in an `HttpOnly`, `Secure`, `SameSite=Lax/Strict` cookie.
+- **Pros**: Immediate revocation, server-side truth, invisible to XSS.
+- **Cons**: Requires DB lookup per request.
+
+### 2. Stateless JWT (JSON Web Tokens)
+
+**Best for**: Distributed APIs, Microservices, Native mobile apps.
+
+- Server signs a token containing user claims.
+- Client passes it in `Authorization: Bearer <token>` header.
+- **Pros**: No DB lookup needed, easy cross-origin sharing.
+- **Cons**: Cannot be easily revoked before expiration.
+
+### The JWT "Refresh Token" Pattern
+
+```typescript
+// Scenario: API authentication
+// 1. Access Token (Short-lived: 15 mins)
+const accessToken = jwt.sign({ userId: user.id }, JWT_SECRET, {
+  expiresIn: '15m',
+  algorithm: 'HS256', // ALWAYS explicitly specify
+});
+// 2. Refresh Token (Long-lived: 7 days, opaque string in DB)
+const refreshToken = crypto.randomBytes(40).toString('hex');
+await db.refreshTokens.create({ token: refreshToken, userId: user.id, expires: addDays(7) });
+
+// Client flow:
+// - Access token kept in memory (JS variable) to prevent XSS theft.
+// - Refresh token kept in HttpOnly cookie.
+// - When Access Token expires, endpoint reads cookie, validates DB, issues new Access Token.
+```
+
+---
+
+## OAuth2 & OIDC (OpenID Connect)
+
+```
+Roles:
+1. Resource Owner (User)
+2. Client (Your App)
+3. Authorization Server (Google/GitHub/Auth0)
+4. Resource Server (API)
+
+Flow (Authorization Code + PKCE):
+1. User clicks "Login with Google".
+2. App generates `code_verifier` and `code_challenge`.
+3. App redirects user to Google with `code_challenge`.
+4. User logs in, Google redirects back to App with an authorization `code`.
+5. App sends `code` + `code_verifier` to Google backend.
+6. Google returns `id_token` (OIDC identity) and `access_token` (OAuth permissions).
+
+// ❌ HALLUCINATION TRAP: Implicit Flow is deprecated.
+// Never use Implicit Flow (response_type=token) where the token is returned in the URL hash.
+// Always use Authorization Code Flow with PKCE, even for Single Page Apps (SPAs).
+```
+
+---
+
+## Multi-Factor Authentication (MFA)
+
+- **SMS**: Deprecated by NIST due to SIM swapping vulnerabilities. (Better than nothing, but avoid as primary MFA).
+- **TOTP (Authenticator Apps)**: Standard implementations use HMAC-SHA1. Keep the secret key heavily encrypted at rest.
+- **WebAuthn / Passkeys**: The modern gold standard. Replaces passwords entirely using hardware enclaves (FaceID, TouchID, YubiKey).
+
+---
+
+## Authorization Models
+
+### RBAC (Role-Based Access Control)
+
+- Users have Roles (`admin`, `editor`, `viewer`).
+- Roles have Permissions (`create:post`, `delete:user`).
+
+```typescript
+// ✅ Check permissions, not roles directly (more flexible)
+if (!user.permissions.includes('delete:user')) {
+  throw new ForbiddenError();
+}
+```
+
+### ABAC (Attribute-Based Access Control)
+
+- Access based on context (e.g., "User can edit Document if Document.department == User.department").
+
+```typescript
+// Example Policy
+function canEditPost(user: User, post: Post): boolean {
+  if (user.role === 'admin') return true;
+  if (post.authorId === user.id) return true;
+  if (post.status === 'draft' && user.department === 'content') return true;
+  return false;
+}
+```
+
+---
+
+## 🚨 Edge-Case & Failure Mode Matrix
+
+| Scenario | Risk | Mitigation Strategy |
+|:---|:---|:---|
+| **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 |
+
+---
+
+## 🤖 LLM-Specific Traps Table
+
+| 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 |
+
+---
+
+## 🏛️ Tribunal Verification & Guardrails
+
+**Active Reviewers:** `orchestrator` · `agent-organizer` · `logic-reviewer`
+**Slash Command:** `/review` or `/tribunal-full`
+
+### ✅ 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?
+```
+
+### 🛑 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.