tribunal-kit 2.4.6 → 3.0.0

package/.agent/skills/swiftui-expert/SKILL.md

@@ -1,75 +1,176 @@
 ---
 name: swiftui-expert
-description: Dedicated Apple-ecosystem App UI architect. Focuses on idiomatic SwiftUI, @State property wrappers, fluid Combine integrations, and native transitions.
+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: 1.0.0
-last-updated: 2026-03-30
-applies-to-model: claude-3-7-sonnet, gemini-2.5-pro
+version: 2.0.0
+last-updated: 2026-04-02
+applies-to-model: gemini-2.5-pro, claude-3-7-sonnet
 ---
 
-# SwiftUI Expert
-
-You are a top-tier iOS / macOS Application Developer who primarily utilizes SwiftUI to build fast, declarative, and highly native application interfaces.
-
-## Core Directives
-
-1. **State Ownership & Data Flow:**
-   - Use `@State` *strictly* for simple, local, internal view state that isn't shared. 
-   - Inject dependencies properly throughout the view hierarchy using `@Environment` and push complex controller logic to `@StateObject` or `Observable` architectures. Avoid gigantic God-views passing `@Binding` down ten levels.
-
-2. **Semantic View Modifiers:**
-   - Respect modifier ordering! In SwiftUI, sequence matters greatly (e.g., `.padding().background(Color.red)` produces drastically different results than `.background(Color.red).padding()`).
-   - Build smaller, composable views rather than monolithic structural scopes. Extract components liberally.
-
-3. **Animation Idioms:**
-   - Prefer native implicit `.animation(.spring())` and explicit `withAnimation { }` blocks over complex timers or geometric transforms.
-   - Attach transitions properly during state changes to manage view insertion/removal gracefully.
-
-4. **Layout Foundations:**
-   - Maximize the usage of `VStack`, `HStack`, `ZStack`, and raw `Grid` components safely over inflexible absolute positions.
-   - Accommodate spatial layouts properly by respecting `SafeAreaInsets` and `presentationDetents` for half-sheets.
-
-## Execution
-When creating SwiftUI interfaces, avoid UIKit overrides like `UIViewRepresentable` unless absolutely dictated. Deliver pristine `.swift` View structures maximizing Apple's human interface guidelines (HIG).
-
-
----
-
-## 🤖 LLM-Specific Traps
-
-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.
-
----
-
-## 🏛️ Tribunal Integration (Anti-Hallucination)
-
-**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.
-
-### ✅ 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?
-✅ 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.
+# SwiftUI Expert — Native Apple Platforms Mastery
+
+> SwiftUI views are a description of your UI, not the UI itself. They are cheap.
+> State drives the UI. If the UI is wrong, your State is wrong.
+
+---
+
+## 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.
+```
+
+---
+
+## 🤖 LLM-Specific Traps (SwiftUI)
+
+1. **Using `@StateObject` in new iOS projects:** AI reverts to pre-iOS 17 patterns. Use the `@Observable` macro and standard `@State` going forward.
+2. **Modifier Order Chaos:** AI randomly orders `.frame()`, `.padding()`, `.background()`, leading to clipped layouts. Padding must precede background to expand the fill.
+3. **`ForEach` with `id: \.self` on Objects:** AI uses `\.self` on Non-Hashable structural data, leading to severe rendering bugs during list animation. Use the `Identifiable` protocol.
+4. **Massive View Bodies:** AI writes 300-line `var body: some View` blobs. Extract subviews.
+5. **Ignoring Target Environment:** Generating MacOS specific APIs (like `NSWindow`) inside simple iOS structural requests.
+6. **GeometryReader Abuse:** AI uses `GeometryReader` to set standard widths. `GeometryReader` breaks auto-sizing layout and should only be used for complex dynamic calculations or parallax.
+7. **Implicit Animation Madness:** AI attaches `.animation(.spring())` haphazardly. In modern SwiftUI this is deprecated. Demand `.animation(.spring(), value: observedState)`.
+8. **Forgetting MainActor:** Network callbacks mutaing `@State` without `await @MainActor` dispatch, causing immediate UI thread crashes.
+9. **AnyView Usage:** AI uses `AnyView` to return different view types from a function. `AnyView` destroys structural identity and severely hurts performance. Use `@ViewBuilder`.
+10. **EnvironmentObject injection failure:** Generating views requiring an `@Environment` model without providing the `.environment()` injection in the Preview block, crashing the Xcode preview.
+
+---
+
+## 🏛️ Tribunal Integration
+
+### ✅ Pre-Flight Self-Audit
+```
+✅ Is state management utilizing the modern `@Observable` macro?
+✅ Are array elements in `ForEach` conforming to `Identifiable`?
+✅ Is UI threading safe (mutating state on `@MainActor`)?
+✅ Are view modifiers logically ordered (e.g., padding before background)?
+✅ Is `GeometryReader` avoided unless strictly necessary for dynamic math?
+✅ Are functions returning dynamic views marked with `@ViewBuilder` (avoiding `AnyView`)?
+✅ Are animations value-bound (`.animation(..., value: x)`)?
+✅ Has the `body` property been kept small and readable via sub-view extraction?
+✅ Are Xcode Previews populated with the necessary Environment mock data?
+✅ Did I use `LazyVStack` appropriately for large scrolling datasets?
+```

package/.agent/skills/systematic-debugging/SKILL.md

@@ -1,186 +1,118 @@
----
-name: systematic-debugging
-description: 4-phase systematic debugging methodology with root cause analysis and evidence-based verification. Use when debugging complex issues.
-allowed-tools: Read, Write, Edit, Glob, Grep
-version: 1.0.0
-last-updated: 2026-03-12
-applies-to-model: gemini-2.5-pro, claude-3-7-sonnet
----
-
-# Systematic Debugging
-
-> Debugging is not guessing. It is the scientific method applied to broken software.
-> Every guess without evidence is just noise. Every change without verification extends the outage.
-
----
-
-## The 4-Phase Method
-
-### Phase 1 — Reproduce
-
-A bug you can't reproduce consistently is a bug you can't safely fix.
-
-**Steps:**
-1. Document the exact sequence that triggers the bug (input → action → observed result)
-2. Identify the environment: OS, browser, Node version, database version, network conditions
-3. Determine if the bug is consistent or intermittent
-4. Find the smallest reproduction case
-
-```
-# Reproduction template
-Trigger:      [Exact steps]
-Environment:  [Runtime, OS, version]
-Expected:     [What should happen]
-Observed:     [What actually happens]
-Consistent:   [Yes / No / Only under load / Only for specific users]
-```
-
-If you cannot reproduce — collect more data before attempting a fix.
-
-### Phase 2 — Locate
-
-Find where the code breaks, not what you think broke.
-
-**Tools by layer:**
-
-| Layer | Locating Tools |
-|---|---|
-| Network | Browser DevTools → Network tab, curl, Wireshark |
-| API | Response body + status code, request logs |
-| Application logic | Debugger, `console.log` with structured context |
-| Database | Query logs, `EXPLAIN ANALYZE`, slow query log |
-| Memory | Heap snapshot, `--inspect` with Chrome DevTools |
-
-**Technique: Binary search the call stack**
-
-When the bug could be anywhere, divide the execution in half:
-- Does the bug exist before line 100? Add a checkpoint.
-- Does it exist before line 50? Add another.
-- Continue halving until you've isolated the broken unit.
-
-### Phase 3 — Hypothesize and Test
-
-Form one specific hypothesis. Test it. Do not form multiple and fix them all simultaneously.
-
-```
-Hypothesis: "The JWT is expiring before the renewal code runs because 
-             the token TTL and the renewal check interval are both set to 1 hour,  
-             with no buffer."
-
-Test: Reduce token TTL to 5 minutes in dev. Does the error appear in 5 minutes?
-
-Result: Yes → hypothesis confirmed
-        No  → discard and form a new hypothesis
-```
-
-**One change at a time.** Two changes at once = you don't know which one fixed it.
-
-### Phase 4 — Fix and Verify
-
-Fix the root cause — not the symptom.
-
-**Root cause vs. symptom:**
-```
-Symptom:    Users are getting logged out
-Cause:      Token TTL is shorter than session duration
-Root cause: TTL and renewal interval were set by two different teams without coordination
-
-Symptom fix:    Increase TTL
-Root cause fix: Establish a single config source for auth timing values + document the relationship
-```
-
-**Verification checklist:**
-- [ ] Bug no longer reproduces with the specific steps from Phase 1
-- [ ] Adjacent behavior still works (no regression)
-- [ ] Fix works in the environment where the bug was first reported
-- [ ] A test is added that would have caught this bug before it reached production
-
----
-
-## Common Debugging Patterns
-
-### Intermittent Bug
-
-- Likely cause: race condition, network timeout, missing error handling on async code
-- Add structured logging with request IDs and timestamps
-- Reproduce under load (`k6`, `ab`)
-- Look for shared mutable state
-
-### Works Locally, Fails in Production
-
-- Likely cause: environment difference (env vars, feature flags, database version, data volume)
-- Compare env vars between local and production (`printenv | sort`)
-- Test with production-scale data
-- Check for hardcoded localhost URLs or conditions
-
-### Only Fails for Specific Users
-
-- Likely cause: data-specific edge case, permission issue, locale-specific formatting
-- Reproduce using the same user ID/session in a lower environment
-- Query the specific user's data against the code path
-- Check for branching logic that depends on user properties
-
----
-
-## Evidence Log Template
-
-Keep a running log during complex debugging:
-
-```
-[Time] Hypothesis: ...
-[Time] Test: ...
-[Time] Result: ...
-[Time] Conclusion: ...
-[Time] New hypothesis: ...
-```
-
-This prevents circular reasoning and gives you a record if you hand off to someone else.
-
----
-
-## Output Format
-
-When this skill completes a task, structure your output as:
-
-```
-━━━ Systematic Debugging Output ━━━━━━━━━━━━━━━━━━━━━━━━
-Task:        [what was performed]
-Result:      [outcome summary — one line]
-─────────────────────────────────────────────────
-Checks:      ✅ [N passed] · ⚠️  [N warnings] · ❌ [N blocked]
-VBC status:  PENDING → VERIFIED
-Evidence:    [link to terminal output, test result, or file diff]
-```
-
-
----
-
-## 🏛️ Tribunal Integration (Anti-Hallucination)
-
-**Slash command: `/debug`**
-**Active reviewers: `debugger` · `logic-reviewer`**
-
-### ❌ Forbidden AI Tropes in Debugging
-
-1. **"Have you tried turning it off and on again?"** — do not suggest blind restarts without understanding the state.
-2. **Hallucinating stack traces** — never guess the line number or the contents of an error log. Use tools to read it.
-3. **"Rewrite the whole function"** — never suggest rewriting working code just to fix a single bug, unless the structure is the root cause.
-4. **Assuming the fix worked** — always provide a way to verify the fix.
-5. **Changing multiple variables at once** — never provide fixes that change 5 different things simultaneously. Identify ONE root cause.
-
-### ✅ Pre-Flight Self-Audit
-
-Review these questions before proposing a bug fix:
-```
-✅ Do I have the exact error message and stack trace? (If no, ASK the user to provide it or let me look for it).
-✅ Did I isolate the exact line or block of code causing the issue?
-✅ Is my proposed fix addressing the root cause, or just suppressing a symptom?
-✅ Did I only change ONE thing to test the hypothesis?
-✅ Can I explain exactly WHY the code broke in the first place?
-```
-
-### 🛑 Verification-Before-Completion (VBC) Protocol
-
-**CRITICAL:** You must follow a strict "evidence-based closeout" state machine.
-- ❌ **Forbidden:** Declaring a bug "fixed" or completing a task because your updated code "looks correct" to you.
-- ✅ **Required:** You are explicitly forbidden from completing your debug task until you have produced **concrete, observable evidence** (e.g., terminal output, compiler success, passing test logs, network trace results, or CLI execution results) proving the fix works. If you lack a direct test environment, you must attempt to write a focused script to verify the logic.
+---
+name: systematic-debugging
+description: Systematic debugging framework. Root-cause isolation, 4-phase methodology, hypothesis testing, log tracing, avoiding shotgun-surgery, memory allocation analysis, and empirical evidence gathering. Use when debugging complex, highly-coupled, or elusive bugs across mixed execution environments.
+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
+---
+
+# Systematic Debugging — Root Cause Mastery
+
+> A bug is not a mystery; it is a manifestation of misplaced assumptions.
+> Shotgun debugging (changing random things until it works) guarantees that you will introduce two new bugs for every one you "fix."
+
+---
+
+## 1. The 4-Phase Debugging Methodology
+
+Never jump straight into modifying code when a bug is reported. 
+
+### Phase 1: Replication & Isolation
+**Goal:** Prove the bug exists continuously and isolate the execution path.
+1. Write a failing deterministic unit/integration test that replicates the exact condition.
+2. Strip away all unnecessary layers (If the UI button fails to delete a user, curl the endpoint directly. Does the API fail? If yes, UI is fine, bug is in the backend/database).
+
+### Phase 2: Hypothesis Generation
+**Goal:** Formulate logical explanations for the anomaly based on data, not guesses.
+- "Because the log shows `auth: false` even after successful token parse, the RBAC middleware must be overwriting the session."
+
+### Phase 3: Evidence-Based Testing (The Probe)
+**Goal:** Prove or disprove the hypothesis without mutating the actual program functionality.
+- Insert strict logging probes: `logger.debug("Executing line 45. User.permissions:", user.permissions)`.
+- If the logs match your hypothesis, proceed. If they do not, discard the hypothesis.
+
+### Phase 4: Resolution & Verification
+**Goal:** Apply the minimal surgical change required, then verify via tests.
+- Re-run the deterministic failing test created in Phase 1. It must now pass.
+
+---
+
+## 2. Advanced Diagnostic Vectors
+
+When pure logic errors are ruled out, look for environmental factors.
+
+**1. Race Conditions / Timing Bugs**
+- *Symptom:* The bug only happens 30% of the time, or depends on network speed.
+- *Cause:* Missing `await` statements, relying on asynchronous callbacks returning in a specific order, or concurrent database transacting.
+
+**2. State Leakage**
+- *Symptom:* The first operation works perfectly. The second consecutive operation fails mysteriously.
+- *Cause:* Global variables, cached HTTP clients, or React state lacking proper cleanup functions between unmounts.
+
+**3. Silent Failures (Swallowed Errors)**
+- *Symptom:* The application stops processing midway through an operation, but nothing is in the error logs.
+- *Cause:* Empty `catch (e) {}` blocks, unhandled promise rejections, or frontend elements conditionally rendering `null` on missing datasets.
+
+---
+
+## 3. The Bisection Method (Git Bisect)
+
+When a catastrophic bug appears in production but worked fine last week, use algorithmic isolation across the git history.
+
+```bash
+git bisect start
+git bisect bad HEAD           # The current state is broken
+git bisect good v1.4.0        # It worked fine in the last release
+
+# Git will now jump you exactly halfway between those commits.
+# Run your tests...
+git bisect bad   # (If it failed)
+# Or...
+git bisect good  # (If it passed)
+
+# Git will isolate the exact commit that introduced the bug in O(log N) steps.
+```
+
+---
+
+## 4. Reading the Stack Trace Properly
+
+Do not skim. Stack traces tell the exact sequence of destruction.
+
+1. **Top line:** The final fatal blow (e.g., `TypeError: Cannot read properties of undefined (reading 'map')`).
+2. **First Application Function:** Scroll down past `node_modules` and framework internals. Find the absolute top-most function call that YOU wrote (e.g., `at UserList (src/components/UserList.tsx:45)`).
+3. **The Parameter Conclusion:** Therefore, line 45 invoked `.map` on a variable that was `undefined`. Why did the parent layer pass `undefined` instead of `[]`?
+
+---
+
+## 🤖 LLM-Specific Traps (Systematic Debugging)
+
+1. **Shotgun Surgery:** Hallucinating massive 5-file refactors to "fix" a bug instead of altering the exact single mathematical operator that caused the mathematical flaw.
+2. **Ignoring the Logs:** Assuming the cause based on the user's plain-text description instead of heavily demanding the user provide exact stack traces, HTTP status codes, or container logs.
+3. **Band-Aid Logging:** Replacing the buggy code logic with simple `console.log` arrays instead of using integrated structured loggers, then failing to revert the probe code upon completion.
+4. **Variable Masking:** Attempting to fix "undefined" errors by blindly inserting `?.` (Optional Chaining) everywhere. This hides the error deeper; it does not solve *why* the data was missing.
+5. **Caching Blindness:** Debugging API mismatches for 20 minutes without ever considering that the browser, CDN, Next.js intermediate layer, or Service Worker is serving stale cached iterations of the file.
+6. **Async Assumption:** Believing that writing `console.log(1)` then `await fetch()` then `console.log(2)` guarantees sequential execution if there are unhandled Promise rejections hanging the event loop.
+7. **Environment Sync Decay:** Attempting to debug complex routing flaws without first verifying the `.env` configuration file contains the required `PUBLIC_URL` or `API_ENDPOINT` keys.
+8. **Syntax Tyranny:** Believing an obscure framework configuration bug is actually a typo, wasting tokens tweaking parentheses and brackets instead of reading the framework documentation.
+9. **No Regression Verification:** The AI generates the fix but completely neglects to write the corresponding unit test ensuring the bug is permanently eliminated from future releases.
+10. **The "Everything is Fine" Trap:** Stating "The code looks perfectly correct" because the individual function appears logically sound, entirely ignoring that the *data being passed into it* by the upstream parent component is catastrophically malformed.
+
+---
+
+## 🏛️ Tribunal Integration
+
+### ✅ Pre-Flight Self-Audit
+```
+✅ Was the bug physically isolated using rigorous replication scenarios before modifying code?
+✅ Has a hypothesis been formulated based on specific log outputs or empirical data traces?
+✅ Were structural boundaries stripped away to test absolute core logic independently?
+✅ Did I rely on analyzing the complete stack trace rather than making "common sense" guesses?
+✅ Was optional chaining (`?.`) avoided as a band-aid if fundamental strict data contracts were broken?
+✅ Have external factors (database latency, browser cache, CORS rules) been evaluated?
+✅ Is the proposed surgical fix absolutely minimized (preventing shotgun surgery)?
+✅ Did I write a deterministic test that permanently flags this specific regression going forward?
+✅ Are environmental configurations (.env variables) synchronized and verified?
+✅ Upon confirming the root cause, were any temporary diagnostic probes cleanly rolled back?
+```