tribunal-kit 4.5.1 → 4.6.1

package/.agent/skills/authentication-best-practices/SKILL.md

@@ -1,193 +1,199 @@
----
-name: authentication-best-practices
-description: 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.
-allowed-tools: Read, Write, Edit, Glob, Grep
-version: 2.0.0
-last-updated: 2026-04-02
-applies-to-model: gemini-2.5-pro, claude-3-7-sonnet
----
-
-# Authentication & Authorization — Identity Mastery
-
----
-
-## 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;
-}
-```
-
----
-
-
----
-
-
-
-AI coding assistants often fall into specific bad habits when dealing with this domain. These are strictly forbidden:
-
-1. **Over-engineering:** Proposing complex abstractions or distributed systems when a simpler approach suffices.
-2. **Hallucinated Libraries/Methods:** Using non-existent methods or packages. Always `// VERIFY` or check `package.json` / `requirements.txt`.
-3. **Skipping Edge Cases:** Writing the "happy path" and ignoring error handling, timeouts, or data validation.
-4. **Context Amnesia:** Forgetting the user's constraints and offering generic advice instead of tailored solutions.
-5. **Silent Degradation:** Catching and suppressing errors without logging or re-raising.
-
----
-
-
-
-**Slash command: `/review` or `/tribunal-full`**
-**Active reviewers: `logic-reviewer` · `security-auditor`**
-
-### ❌ Forbidden AI Tropes
-
-1. **Blind Assumptions:** Never make an assumption without documenting it clearly with `// VERIFY: [reason]`.
-2. **Silent Degradation:** Catching and suppressing errors without logging or handling.
-3. **Context Amnesia:** Forgetting the user's constraints and offering generic advice instead of tailored solutions.
-
-
-
-Review these questions before confirming output:
-```
-✅ Did I rely ONLY on real, verified tools and methods?
-✅ Is this solution appropriately scoped to the user's constraints?
-✅ Did I handle potential failure modes and edge cases?
-✅ Have I avoided generic boilerplate that doesn't add value?
-```
-
-### 🛑 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 tests, compile success, or equivalent proof) that your output works as intended.
-
-
-## Pre-Flight Checklist
-- [ ] Have I reviewed the user's specific constraints and requests?
-- [ ] Have I checked the environment for relevant existing implementations?
-
-## VBC Protocol (Verification-Before-Completion)
-You MUST verify existing code signatures and variables before attempting to modify or call them. No hallucination is permitted.
+---
+name: authentication-best-practices
+description: 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.
+allowed-tools: Read, Write, Edit, Glob, Grep
+version: 2.0.0
+last-updated: 2026-04-02
+applies-to-model: gemini-2.5-pro, claude-3-7-sonnet
+routing:
+  domain: general
+  tier: basic
+---
+
+# Authentication & Authorization — Identity Mastery
+
+---
+
+## 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;
+}
+```
+
+---
+
+---
+
+AI coding assistants often fall into specific bad habits when dealing with this domain. These are strictly forbidden:
+
+1. **Over-engineering:** Proposing complex abstractions or distributed systems when a simpler approach suffices.
+2. **Hallucinated Libraries/Methods:** Using non-existent methods or packages. Always `// VERIFY` or check `package.json` / `requirements.txt`.
+3. **Skipping Edge Cases:** Writing the "happy path" and ignoring error handling, timeouts, or data validation.
+4. **Context Amnesia:** Forgetting the user's constraints and offering generic advice instead of tailored solutions.
+5. **Silent Degradation:** Catching and suppressing errors without logging or re-raising.
+
+---
+
+**Slash command: `/review` or `/tribunal-full`**
+**Active reviewers: `logic-reviewer` · `security-auditor`**
+
+### ❌ Forbidden AI Tropes
+
+1. **Blind Assumptions:** Never make an assumption without documenting it clearly with `// VERIFY: [reason]`.
+2. **Silent Degradation:** Catching and suppressing errors without logging or handling.
+3. **Context Amnesia:** Forgetting the user's constraints and offering generic advice instead of tailored solutions.
+
+Review these questions before confirming output:
+
+```
+✅ Did I rely ONLY on real, verified tools and methods?
+✅ Is this solution appropriately scoped to the user's constraints?
+✅ Did I handle potential failure modes and edge cases?
+✅ Have I avoided generic boilerplate that doesn't add value?
+```
+
+### 🛑 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 tests, compile success, or equivalent proof) that your output works as intended.
+
+## Pre-Flight Checklist
+
+- [ ] Have I reviewed the user's specific constraints and requests?
+- [ ] Have I checked the environment for relevant existing implementations?
+
+## VBC Protocol (Verification-Before-Completion)
+
+You MUST verify existing code signatures and variables before attempting to modify or call them. No hallucination is permitted.
 
 ---
 
@@ -217,6 +223,7 @@ AI coding assistants often fall into specific bad habits when dealing with this
 ### ✅ Pre-Flight Self-Audit
 
 Review these questions before confirming output:
+
 ```
 ✅ Did I rely ONLY on real, verified tools and methods?
 ✅ Is this solution appropriately scoped to the user's constraints?
@@ -227,5 +234,6 @@ Review these questions before confirming output:
 ### 🛑 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 tests, compile success, or equivalent proof) that your output works as intended.

package/.agent/skills/backend-security-expert/SKILL.md

@@ -5,11 +5,15 @@ allowed-tools: Read, Write, Edit, Glob, Grep
 version: 1.0.0
 last-updated: 2026-05-22
 applies-to-model: gemini-3-1-pro, claude-3-7-sonnet
+routing:
+  domain: general
+  tier: basic
 ---
 
 # Backend Security Expert — Modern Server Architectures
 
 ## Hallucination Traps (Read First)
+
 - ❌ Recommending session tokens without algorithm enforcement → ✅ Always verify JWT algorithms (`alg: "HS256"`) to prevent "None" attacks.
 - ❌ Treating ORMs as automatically secure → ✅ Prisma and Drizzle can still be vulnerable if raw SQL/queries are dynamically interpolated.
 - ❌ Assuming Next.js Server Actions are private APIs → ✅ Server Actions are public endpoints and must be authenticated and rate-limited.
@@ -18,22 +22,27 @@ applies-to-model: gemini-3-1-pro, claude-3-7-sonnet
 ---
 
 ## 1. Next.js Server Actions & Edge APIs
+
 Server Actions create implicit API endpoints. They must be treated like raw REST routes.
-- **Authentication**: Validate the session ID/token at the very top of *every* Server Action.
+
+- **Authentication**: Validate the session ID/token at the very top of _every_ Server Action.
 - **Input Validation**: Parse all inputs using Zod. Do not trust TypeScript types, as they do not exist at runtime.
 - **Rate Limiting**: Apply `@upstash/ratelimit` or similar to prevent brute force and abuse on public-facing actions.
 
 ## 2. Authentication & Authorization (RBAC)
+
 - **Role-Based Access**: Check if the authenticated user has permission to perform the specific action, not just if they are logged in.
 - **IDOR Prevention**: Always verify that the resource being modified belongs to the user requesting the modification (e.g., `WHERE userId = session.userId`).
 - **Secrets Management**: Never hardcode API keys. Ensure they are loaded from `.env` and fail loudly if missing.
 
 ## 3. Database & ORM Security
+
 - **NoSQL/ORM Injection**: Avoid passing raw JSON or objects directly into query constraints (e.g., MongoDB `$where` or Prisma raw queries).
 - **Mass Assignment**: Never destructure user input directly into a database create/update call. Explicitly pick the fields allowed to be updated.
 - **Query Depth**: For GraphQL backends, always implement depth limiting and cost analysis to prevent query-based DDoS.
 
 ## 4. Headers & Server Hardening
+
 - **CORS**: Never use wildcard `Access-Control-Allow-Origin: *` for authenticated routes.
 - **Security Headers**: Ensure Helmet (or equivalent Next.js headers config) is active for HSTS, X-Frame-Options, and Content-Type-Options.
 
@@ -59,6 +68,7 @@ AI coding assistants often fall into specific bad habits when dealing with this
 3. **Context Amnesia:** Forgetting the user's constraints and offering generic advice instead of tailored solutions.
 
 Review these questions before confirming output:
+
 ```
 ✅ Did I rely ONLY on real, verified tools and methods?
 ✅ Is this solution appropriately scoped to the user's constraints?
@@ -69,16 +79,18 @@ Review these questions before confirming output:
 ### 🛑 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 tests, compile success, or equivalent proof) that your output works as intended.
 
 ## Pre-Flight Checklist
+
 - [ ] Have I reviewed the user's specific constraints and requests?
 - [ ] Have I checked the environment for relevant existing implementations?
 
 ## VBC Protocol (Verification-Before-Completion)
-You MUST verify existing code signatures and variables before attempting to modify or call them. No hallucination is permitted.
 
+You MUST verify existing code signatures and variables before attempting to modify or call them. No hallucination is permitted.
 
 ---
 
@@ -108,6 +120,7 @@ AI coding assistants often fall into specific bad habits when dealing with this
 ### ✅ Pre-Flight Self-Audit
 
 Review these questions before confirming output:
+
 ```
 ✅ Did I rely ONLY on real, verified tools and methods?
 ✅ Is this solution appropriately scoped to the user's constraints?
@@ -118,5 +131,6 @@ Review these questions before confirming output:
 ### 🛑 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 tests, compile success, or equivalent proof) that your output works as intended.