tribunal-kit 4.5.1 → 4.6.1

package/.agent/skills/supabase-postgres-best-practices/SKILL.md

@@ -1,101 +1,99 @@
----
-name: supabase-postgres-best-practices
-description: Database architect expert in Supabase and PostgreSQL. Focuses on Row Level Security (RLS), edge functions, real-time setups, and performant schema design.
-allowed-tools: Read, Write, Edit, Glob, Grep
-version: 1.0.0
-last-updated: 2026-03-30
-applies-to-model: claude-3-7-sonnet, gemini-2.5-pro
----
-
-## Hallucination Traps (Read First)
-- ❌ Using Supabase without enabling Row Level Security (RLS) -> ✅ ALL tables MUST have RLS enabled; without it, data is publicly accessible
-- ❌ `supabase.from('users').select('*')` in client-side code without RLS -> ✅ This exposes ALL rows to ALL users; add RLS policies first
-- ❌ Storing API keys in client-side JavaScript -> ✅ The `anon` key is public by design; protect data with RLS, not key secrecy
-- ❌ Using Supabase Edge Functions for compute-heavy tasks -> ✅ Edge Functions have 150ms CPU time limit; use server functions for heavy work
-
----
-
-
-# Supabase & Postgres Best Practices
-
-You are a Supabase Data Architect. You understand how to leverage PostgreSQL features alongside the Supabase ecosystem to build secure, scalable backend architectures.
-
-## Core Directives
-
-1. **Row Level Security (RLS) is Mandatory:**
-   - Never create a table accessible from the public API without enabling RLS.
-   - Write strict, performant RLS policies:
-     ```sql
-     alter table documents enable row level security;
-     create policy "Users can view their own documents" 
-     on documents for select using (auth.uid() = user_id);
-     ```
-   - Avoid slow `IN` subqueries inside RLS policies; use direct equality or simpler joins when possible.
-
-2. **Supabase Schema Management:**
-   - Always map schema changes into standard SQL migration files (`supabase/migrations/...`).
-   - Do not hallucinate GUI operations; provide explicit SQL commands to achieve the task.
-
-3. **Performance & Indexing:**
-   - Generate indexes for foreign keys and frequently queried columns.
-   - Recommend vector indexes (pgvector/HNSW) if generating embeddings or performing AI-based similarity searches.
-
-4. **Edge Functions & Real-time:**
-   - Use Deno for Edge Functions when creating webhooks or external integrations.
-   - Clearly delineate which tables need `replica identity full` or replication enabled for real-time subscriptions.
-
----
-
-
----
-
-
-
-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: supabase-postgres-best-practices
+description: Database architect expert in Supabase and PostgreSQL. Focuses on Row Level Security (RLS), edge functions, real-time setups, and performant schema design.
+allowed-tools: Read, Write, Edit, Glob, Grep
+version: 1.0.0
+last-updated: 2026-03-30
+applies-to-model: claude-3-7-sonnet, gemini-2.5-pro
+routing:
+  domain: general
+  tier: basic
+---
 
+## Hallucination Traps (Read First)
+
+- ❌ Using Supabase without enabling Row Level Security (RLS) -> ✅ ALL tables MUST have RLS enabled; without it, data is publicly accessible
+- ❌ `supabase.from('users').select('*')` in client-side code without RLS -> ✅ This exposes ALL rows to ALL users; add RLS policies first
+- ❌ Storing API keys in client-side JavaScript -> ✅ The `anon` key is public by design; protect data with RLS, not key secrecy
+- ❌ Using Supabase Edge Functions for compute-heavy tasks -> ✅ Edge Functions have 150ms CPU time limit; use server functions for heavy work
+
+---
+
+# Supabase & Postgres Best Practices
+
+You are a Supabase Data Architect. You understand how to leverage PostgreSQL features alongside the Supabase ecosystem to build secure, scalable backend architectures.
+
+## Core Directives
+
+1. **Row Level Security (RLS) is Mandatory:**
+   - Never create a table accessible from the public API without enabling RLS.
+   - Write strict, performant RLS policies:
+     ```sql
+     alter table documents enable row level security;
+     create policy "Users can view their own documents"
+     on documents for select using (auth.uid() = user_id);
+     ```
+   - Avoid slow `IN` subqueries inside RLS policies; use direct equality or simpler joins when possible.
+
+2. **Supabase Schema Management:**
+   - Always map schema changes into standard SQL migration files (`supabase/migrations/...`).
+   - Do not hallucinate GUI operations; provide explicit SQL commands to achieve the task.
+
+3. **Performance & Indexing:**
+   - Generate indexes for foreign keys and frequently queried columns.
+   - Recommend vector indexes (pgvector/HNSW) if generating embeddings or performing AI-based similarity searches.
+
+4. **Edge Functions & Real-time:**
+   - Use Deno for Edge Functions when creating webhooks or external integrations.
+   - Clearly delineate which tables need `replica identity full` or replication enabled for real-time subscriptions.
+
+---
+
+---
+
+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.
 
 ---
 
@@ -125,6 +123,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?
@@ -135,5 +134,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/swiftui-expert/SKILL.md

@@ -1,205 +1,206 @@
----
-name: swiftui-expert
-description: SwiftUI development mastery. View architecture, state management (@State, @Binding, @Environment, @Observable), performance optimization (identifiable loops, implicit vs explicit animations), architectural patterns (MVVM vs TCA), and iOS-native UX paradigms. Use when writing native Apple platforms code.
-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
----
-
-## Hallucination Traps (Read First)
-- ❌ Using `@State` for shared data between views -> ✅ `@State` is local to a view; use `@Binding`, `@Environment`, or `@Observable` for sharing
-- ❌ Putting heavy computation in the `body` property -> ✅ `body` is called on EVERY re-render; move computation to `.task {}` or `onChange`
-- ❌ `List { ForEach(items) { ... } }` without `id:` parameter -> ✅ Always provide `id:` for `Identifiable` conformance or use `\.self`
-- ❌ Using `NavigationView` -> ✅ Deprecated in iOS 16+; use `NavigationStack` or `NavigationSplitView`
-
----
-
-
-# SwiftUI Expert — Native Apple Platforms Mastery
-
----
-
-## 1. Modern State Management (iOS 17+ / Swift 5.9+)
-
-Apple deprecated `@StateObject` and `@ObservedObject` in favor of the new `@Observable` macro.
-
-```swift
-// ❌ OLD WAY (Pre-iOS 17)
-class UserProfile: ObservableObject {
-    @Published var name: String = "Guest"
-}
-struct ProfileView: View {
-    @StateObject var profile = UserProfile()
-    // ...
-}
-
-// ✅ NEW WAY (iOS 17+ / @Observable)
-import Observation
-
-@Observable 
-class UserProfile {
-    var name: String = "Guest"
-    var age: Int = 0
-    // No @Published needed! Only properties that are actually read 
-    // inside the body will trigger view updates.
-}
-
-struct ProfileView: View {
-    // Treat the reference type exactly like a value type!
-    @State private var profile = UserProfile()
-    
-    var body: some View {
-        VStack {
-            TextField("Name", text: $profile.name)
-            Text("Hello, \(profile.name)")
-        }
-    }
-}
-```
-
-### Property Data Flow Cheat Sheet
-- `@State`: The view OWNS value (or reference if `@Observable`).
-- `@Binding`: The view mutates a value OWNED by a parent.
-- `@Environment`: The view reads value injected high up in the view hierarchy.
-- `@Bindable`: Creates bindings from an `@Observable` model passed via parameters/environment.
-
----
-
-## 2. View Architecture & Modifiers
-
-SwiftUI Views should be impossibly small. Extract frequently.
-
-```swift
-// ❌ BAD: Massive body with 10 layers of nesting
-struct MassiveView: View {
-    var body: some View { ... }
-}
-
-// ✅ GOOD: Extract via properties, functions, or new View structs
-struct CleanView: View {
-    var body: some View {
-        VStack {
-            headerSection
-            CustomScrollingList(items: data)
-            footerSection
-        }
-    }
-    
-    private var headerSection: some View {
-        Text("Header").font(.headline)
-    }
-}
-```
-
-### Modifier Ordering Matters
-Modifiers wrap views sequentially. The order fundamentally changes the rendering.
-
-```swift
-// Padding BEFORE Background
-Text("Hello")
-    .padding()
-    .background(Color.blue) 
-// Result: A large blue box with text inside.
-
-// Padding AFTER Background
-Text("Hello")
-    .background(Color.blue)
-    .padding()
-// Result: A tight blue box around text, surrounded by invisible spacing.
-```
-
----
-
-## 3. Performance & Rendering
-
-```swift
-// ❌ BAD: Using indices in ForEach
-// If the array mutates (items injected/deleted), SwiftUI loses 
-// track of identity and re-renders EVERYTHING aggressively.
-ForEach(0..<items.count, id: \.self) { index in
-    ItemRow(item: items[index])
-}
-
-// ✅ GOOD: Identifiable protocol
-struct Item: Identifiable {
-    let id = UUID()
-    let title: String
-}
-
-ForEach(items) { item in
-    ItemRow(item: item)
-}
-```
-
-### Avoiding Massive Layout Recalculations
-Use `LazyVStack` and `LazyHStack` inside ScrollViews when presenting large lists, but NOT everywhere. Normal `VStack` is faster for < 20 items because it pre-calculates boundaries instantly.
-
----
-
-## 4. MVVM vs Context-Driven Architecture
-
-While MVVM is historically popular, SwiftUI natively represents View-as-a-function-of-State.
-
-```swift
-// ✅ Context-Driven / Feature-Driven
-// The Model handles data fetching/logic. 
-// The View creates its own local @State and passes @Bindings down.
-// Only use full ViewModels for complex orchestration crossing multiple views.
-```
-
----
-
-
----
-
-
-
-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: swiftui-expert
+description: SwiftUI development mastery. View architecture, state management (@State, @Binding, @Environment, @Observable), performance optimization (identifiable loops, implicit vs explicit animations), architectural patterns (MVVM vs TCA), and iOS-native UX paradigms. Use when writing native Apple platforms code.
+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
+---
+
+## Hallucination Traps (Read First)
+
+- ❌ Using `@State` for shared data between views -> ✅ `@State` is local to a view; use `@Binding`, `@Environment`, or `@Observable` for sharing
+- ❌ Putting heavy computation in the `body` property -> ✅ `body` is called on EVERY re-render; move computation to `.task {}` or `onChange`
+- ❌ `List { ForEach(items) { ... } }` without `id:` parameter -> ✅ Always provide `id:` for `Identifiable` conformance or use `\.self`
+- ❌ Using `NavigationView` -> ✅ Deprecated in iOS 16+; use `NavigationStack` or `NavigationSplitView`
+
+---
+
+# SwiftUI Expert — Native Apple Platforms Mastery
+
+---
+
+## 1. Modern State Management (iOS 17+ / Swift 5.9+)
+
+Apple deprecated `@StateObject` and `@ObservedObject` in favor of the new `@Observable` macro.
+
+```swift
+// ❌ OLD WAY (Pre-iOS 17)
+class UserProfile: ObservableObject {
+    @Published var name: String = "Guest"
+}
+struct ProfileView: View {
+    @StateObject var profile = UserProfile()
+    // ...
+}
+
+// ✅ NEW WAY (iOS 17+ / @Observable)
+import Observation
+
+@Observable
+class UserProfile {
+    var name: String = "Guest"
+    var age: Int = 0
+    // No @Published needed! Only properties that are actually read
+    // inside the body will trigger view updates.
+}
+
+struct ProfileView: View {
+    // Treat the reference type exactly like a value type!
+    @State private var profile = UserProfile()
+
+    var body: some View {
+        VStack {
+            TextField("Name", text: $profile.name)
+            Text("Hello, \(profile.name)")
+        }
+    }
+}
+```
+
+### Property Data Flow Cheat Sheet
+
+- `@State`: The view OWNS value (or reference if `@Observable`).
+- `@Binding`: The view mutates a value OWNED by a parent.
+- `@Environment`: The view reads value injected high up in the view hierarchy.
+- `@Bindable`: Creates bindings from an `@Observable` model passed via parameters/environment.
+
+---
+
+## 2. View Architecture & Modifiers
+
+SwiftUI Views should be impossibly small. Extract frequently.
 
+```swift
+// ❌ BAD: Massive body with 10 layers of nesting
+struct MassiveView: View {
+    var body: some View { ... }
+}
+
+// ✅ GOOD: Extract via properties, functions, or new View structs
+struct CleanView: View {
+    var body: some View {
+        VStack {
+            headerSection
+            CustomScrollingList(items: data)
+            footerSection
+        }
+    }
+
+    private var headerSection: some View {
+        Text("Header").font(.headline)
+    }
+}
+```
+
+### Modifier Ordering Matters
+
+Modifiers wrap views sequentially. The order fundamentally changes the rendering.
+
+```swift
+// Padding BEFORE Background
+Text("Hello")
+    .padding()
+    .background(Color.blue)
+// Result: A large blue box with text inside.
+
+// Padding AFTER Background
+Text("Hello")
+    .background(Color.blue)
+    .padding()
+// Result: A tight blue box around text, surrounded by invisible spacing.
+```
+
+---
+
+## 3. Performance & Rendering
+
+```swift
+// ❌ BAD: Using indices in ForEach
+// If the array mutates (items injected/deleted), SwiftUI loses
+// track of identity and re-renders EVERYTHING aggressively.
+ForEach(0..<items.count, id: \.self) { index in
+    ItemRow(item: items[index])
+}
+
+// ✅ GOOD: Identifiable protocol
+struct Item: Identifiable {
+    let id = UUID()
+    let title: String
+}
+
+ForEach(items) { item in
+    ItemRow(item: item)
+}
+```
+
+### Avoiding Massive Layout Recalculations
+
+Use `LazyVStack` and `LazyHStack` inside ScrollViews when presenting large lists, but NOT everywhere. Normal `VStack` is faster for < 20 items because it pre-calculates boundaries instantly.
+
+---
+
+## 4. MVVM vs Context-Driven Architecture
+
+While MVVM is historically popular, SwiftUI natively represents View-as-a-function-of-State.
+
+```swift
+// ✅ Context-Driven / Feature-Driven
+// The Model handles data fetching/logic.
+// The View creates its own local @State and passes @Bindings down.
+// Only use full ViewModels for complex orchestration crossing multiple views.
+```
+
+---
+
+---
+
+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.
 
 ---
 
@@ -229,6 +230,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?
@@ -239,5 +241,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.