tribunal-kit 9.2.4 → 9.2.5

package/.agent/skills/architecture/SKILL.md

@@ -1,188 +1,188 @@
----
-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
-
----
-
-## 🛠️ 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
-```
+---
+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
+
+---
+
+## 🛠️ 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
+```

package/.agent/skills/architecture-drift/SKILL.md

@@ -0,0 +1,45 @@
+---
+name: architecture-drift
+description: 'Identifies when the implemented code deviates from the intended architecture documented in system-model.yml.'
+version: 1.1.0
+last-updated: 2026-09-26
+skills:
+  - fabel-protocol
+---
+
+# Architecture Drift Skill
+
+Use this skill to detect when an implementation violates intended architectural boundaries.
+
+## 🔴 Hallucination Traps
+
+- ❌ **Assuming Drift = Bug** → ✅ Drift might be an intentional feature addition. Ask for clarification before rejecting.
+- ❌ **Guessing Boundaries** → ✅ Only use boundaries explicitly defined in `.agent/architecture/system-model.yml`.
+- ❌ **Keyword Matching** → ✅ Verify actual AST/Imports. Just because a file has "redis" in a comment doesn't mean it uses Redis.
+
+## 📋 Mandatory Pre-Flight Checklist
+
+1. Inspect `.agent/architecture/system-model.yml`.
+2. Inspect the current `review-<base>..<head>.diff` or the modified files.
+3. Cross-reference new dependencies against the System Model components.
+
+## 🔍 Analysis Steps
+
+1. **Dependency Drift**: Check if new external dependencies are introduced (e.g., imports of a new DB client) outside of the declared model.
+2. **Data Boundary Drift**: Check if data boundaries are crossed (e.g., Service A writing directly to Service B's database instead of using an API).
+3. **Interface Drift**: Check for circumvention of designated APIs or contracts.
+
+## 🛡️ Verification-Before-Completion (VBC)
+
+Before producing your final report, you MUST structure your findings using the Tribunal evidence model:
+
+```yaml
+finding:
+  category: 'Architecture Drift'
+  severity: 'High'
+  claim: '[Claim]'
+  evidence:
+    - file: '[File Path]'
+      observation: '[Exact Import or Function Call]'
+  recommendation: '[Fix]'
+```

package/.agent/skills/audit-and-fix/SKILL.md

@@ -1,100 +1,100 @@
----
-name: audit-and-fix
-description: "Use when Use for dual-purpose remediation: Accessibility auditing (WCAG 2.2 AA) and Deep Backend Security Remediation (Cloudflare protocols, Auth, CSRF, JWT)."
-version: 5.0.0
-last-updated: 2026-09-13
-skills:
-  - fixing-accessibility
-  - build-primitive
-  - baseline-ui
-  - cf-security-audit-core
-  - cf-web-protocol-and-auth
-  - cf-attack-classes
-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
-
----
-
-## 🛠️ Technical Architecture & Reference Recipes
-
----
-
----
-
-## 4-Step Remediation Pipeline
-
-### 1. Automated Violation Detection
-
-Scan component code for **Accessibility**:
-
-- 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}`.
-
-Scan backend code for **Security (Cloudflare Protocols)**:
-
-- JWTs lacking explicit `alg`, `aud`, and `exp` validation.
-- Missing CSRF tokens on state-mutating HTTP methods (`POST`, `PUT`, `DELETE`).
-- Improper request framing or missing cache control headers.
-- Hardcoded secrets or unsanitized user inputs at boundaries.
-
-### 2. Prioritization Matrix
-
-| Severity Level             | Violation Type                                                                    | Remediation Action                                                      |
-| -------------------------- | --------------------------------------------------------------------------------- | ----------------------------------------------------------------------- |
-| 🔴 **Blocker (Level A)**   | Inaccessible form inputs, zero keyboard access, **Auth Bypass**, **Missing CSRF** | Add explicit `<label>`, focus trap, validate JWT `aud`/`exp`, add CSRF. |
-| 🟠 **Critical (Level AA)** | Low text contrast ratio ($< 4.5:1$), **Broken Cache**, **Weak Framing**           | Adjust colors to OKLCH targets; harden cache-control & framing.         |
-| 🟡 **Moderate (Level AA)** | Missing landmark regions (`<main>`, `<nav>`), heading hierarchy gaps              | Wrap layout blocks in semantic HTML5 tags.                              |
-
-### 3. Concrete Code Fix Examples
-
-#### Accessibility 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>
-```
-
-#### Security Examples
-
-```ts
-// BEFORE (Insecure JWT Validation)
-const decoded = jwt.verify(token, secret);
-
-// AFTER (Secure JWT Validation - Enforce Audience & Alg)
-const decoded = jwt.verify(token, secret, {
-  algorithms: ['HS256'],
-  audience: 'https://api.example.com',
-  maxAge: '1h',
-});
-```
-
-```tsx
-// BEFORE (Missing CSRF)
-<form action="/api/update-profile" method="POST">
-  <input name="email" type="email" />
-</form>
-
-// AFTER (Secure with CSRF Token)
-<form action="/api/update-profile" method="POST">
-  <input type="hidden" name="csrfToken" value={csrfToken} />
-  <input name="email" type="email" />
-</form>
-```
+---
+name: audit-and-fix
+description: "Use when Use for dual-purpose remediation: Accessibility auditing (WCAG 2.2 AA) and Deep Backend Security Remediation (Cloudflare protocols, Auth, CSRF, JWT)."
+version: 5.0.0
+last-updated: 2026-09-13
+skills:
+  - fixing-accessibility
+  - build-primitive
+  - baseline-ui
+  - cf-security-audit-core
+  - cf-web-protocol-and-auth
+  - cf-attack-classes
+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
+
+---
+
+## 🛠️ Technical Architecture & Reference Recipes
+
+---
+
+---
+
+## 4-Step Remediation Pipeline
+
+### 1. Automated Violation Detection
+
+Scan component code for **Accessibility**:
+
+- 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}`.
+
+Scan backend code for **Security (Cloudflare Protocols)**:
+
+- JWTs lacking explicit `alg`, `aud`, and `exp` validation.
+- Missing CSRF tokens on state-mutating HTTP methods (`POST`, `PUT`, `DELETE`).
+- Improper request framing or missing cache control headers.
+- Hardcoded secrets or unsanitized user inputs at boundaries.
+
+### 2. Prioritization Matrix
+
+| Severity Level             | Violation Type                                                                    | Remediation Action                                                      |
+| -------------------------- | --------------------------------------------------------------------------------- | ----------------------------------------------------------------------- |
+| 🔴 **Blocker (Level A)**   | Inaccessible form inputs, zero keyboard access, **Auth Bypass**, **Missing CSRF** | Add explicit `<label>`, focus trap, validate JWT `aud`/`exp`, add CSRF. |
+| 🟠 **Critical (Level AA)** | Low text contrast ratio ($< 4.5:1$), **Broken Cache**, **Weak Framing**           | Adjust colors to OKLCH targets; harden cache-control & framing.         |
+| 🟡 **Moderate (Level AA)** | Missing landmark regions (`<main>`, `<nav>`), heading hierarchy gaps              | Wrap layout blocks in semantic HTML5 tags.                              |
+
+### 3. Concrete Code Fix Examples
+
+#### Accessibility 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>
+```
+
+#### Security Examples
+
+```ts
+// BEFORE (Insecure JWT Validation)
+const decoded = jwt.verify(token, secret);
+
+// AFTER (Secure JWT Validation - Enforce Audience & Alg)
+const decoded = jwt.verify(token, secret, {
+  algorithms: ['HS256'],
+  audience: 'https://api.example.com',
+  maxAge: '1h',
+});
+```
+
+```tsx
+// BEFORE (Missing CSRF)
+<form action="/api/update-profile" method="POST">
+  <input name="email" type="email" />
+</form>
+
+// AFTER (Secure with CSRF Token)
+<form action="/api/update-profile" method="POST">
+  <input type="hidden" name="csrfToken" value={csrfToken} />
+  <input name="email" type="email" />
+</form>
+```