tribunal-kit 6.0.0 → 7.0.0

package/.agent/skills/diagnosing-bugs/SKILL.md

@@ -20,6 +20,7 @@ scripts-binding:
 ## Mandatory Pre-Flight Context Inspection
 
 Before attempting bug diagnostics or proposing code fixes, you MUST inspect:
+
 1. Red-Capable Feedback Loop Rule (Section 34) → Construct a fast, deterministic, automated feedback loop command that reproduces the bug (goes red) BEFORE making code edits
 2. Falsifiable Hypotheses Formulation (Section 107) → Formulate 3–5 falsifiable hypotheses (`"If X is cause, then Y prediction"`) before testing any single theory
 3. Tagged Debug Logging & Cleanup (Section 123) → Tag debug log instrumentation (`[DEBUG-id]`) and sweep clean before finalizing regression fixes
@@ -66,6 +67,7 @@ Build the right feedback loop, and the bug is 90% fixed.
 ### Tighten the Loop
 
 Treat the loop as a product. Once you have a loop, tighten it:
+
 - **Can I make it faster?** (Cache setup, skip unrelated init, narrow the test scope.)
 - **Can I make the signal sharper?** (Assert on the specific symptom, not "didn't crash".)
 - **Can I make it more deterministic?** (Pin time, seed RNG, isolate filesystem, freeze network.)
@@ -79,21 +81,23 @@ The goal is not a clean repro but a higher reproduction rate. Loop the trigger 1
 ### When You Genuinely Cannot Build a Loop
 
 Stop and say so explicitly. List what you tried. Ask the user for:
+
 1. Access to whatever environment reproduces it.
 2. A captured artifact (HAR file, log dump, core dump, screen recording with timestamps).
 3. Permission to add temporary production instrumentation.
 
-*Do not proceed to hypothesise without a loop.*
+_Do not proceed to hypothesise without a loop._
 
 ### Phase 1 Completion Criterion — A Tight Loop That Goes Red
 
 Phase 1 is done when the loop is tight and red-capable: you can name **one command** — a script path, a test invocation, a curl — that you have already run at least once (paste the invocation and its output), and that is:
+
 - ✅ **Red-capable**: Drives the actual bug code path and asserts the user's exact symptom, going red on this bug and green once fixed. Not "runs without erroring" — it must catch this specific bug.
 - ✅ **Deterministic**: Same verdict every run (or high, pinned reproduction rate).
 - ✅ **Fast**: Seconds, not minutes.
 - ✅ **Agent-runnable**: Runnable unattended (HITL only via `scripts/hitl-loop.template.sh`).
 
-*If you catch yourself reading code to build a theory before this command exists, stop. No red-capable command, no Phase 2.*
+_If you catch yourself reading code to build a theory before this command exists, stop. No red-capable command, no Phase 2._
 
 ---
 
@@ -102,11 +106,13 @@ Phase 1 is done when the loop is tight and red-capable: you can name **one comma
 Run the loop. Watch it go red — the bug appears.
 
 ### Confirm
+
 1. The loop produces the failure mode the user described — not a different failure nearby. (Wrong bug = wrong fix.)
 2. The failure is reproducible across multiple runs (or at a high enough reproduction rate).
 3. You have captured the exact symptom (error message, wrong output, slow timing) so later phases can verify the fix addresses it.
 
 ### Minimise
+
 Once it's red, shrink the repro to the smallest scenario that still goes red. Cut inputs, callers, config, data, and steps one at a time, re-running the loop after each cut — keep only what's load-bearing for the failure.
 
 > 🎯 **Why bother**: A minimal repro shrinks the hypothesis space in Phase 3 (fewer moving parts left to suspect) and becomes the clean regression test in Phase 5.
@@ -134,6 +140,7 @@ Show the ranked list to the user before testing. (Proceed with your ranking if t
 Each probe must map to a specific prediction from Phase 3. Change one variable at a time.
 
 ### Tool Preference
+
 1. **Debugger / REPL Inspection**: If the environment supports it. One breakpoint beats ten logs.
 2. **Targeted Logs**: Place logs at boundaries that distinguish hypotheses. Never "log everything and grep".
 3. **Tag Every Debug Log**: Prefix every debug log with a unique tag, e.g. `[DEBUG-a4f2]`. Cleanup at the end becomes a single grep.
@@ -150,6 +157,7 @@ A correct seam is one where the test exercises the real bug pattern as it occurs
 If no correct seam exists, note it. The codebase architecture is preventing the bug from being locked down. Flag this for Phase 6.
 
 ### If a Correct Seam Exists:
+
 1. Turn the minimised repro into a failing test at that seam.
 2. Watch it fail.
 3. Apply the fix.
@@ -161,6 +169,7 @@ If no correct seam exists, note it. The codebase architecture is preventing the
 ## Phase 6 — Cleanup + Post-Mortem
 
 ### Required Before Declaring Done
+
 - [ ] Original repro no longer reproduces (re-run Phase 1 loop)
 - [ ] Regression test passes (or absence of seam is documented)
 - [ ] All `[DEBUG-...]` instrumentation removed (grep the prefix)
@@ -168,6 +177,7 @@ If no correct seam exists, note it. The codebase architecture is preventing the
 - [ ] Correct hypothesis stated in commit / PR message
 
 ### Post-Mortem Handoff
+
 Ask: **What would have prevented this bug?** If the answer involves architectural debt (no good test seam, tangled callers, hidden coupling), hand off to `/improve-codebase-architecture` with specific findings.
 
 ---

package/.agent/skills/distill/SKILL.md

@@ -20,6 +20,7 @@ scripts-binding:
 ## Mandatory Pre-Flight Context Inspection
 
 Before decluttering UI layouts, you MUST inspect:
+
 1. Active screen components → Identify core primary user task and secondary/tertiary options
 2. Container Reduction rules (Section 25) → Replace nested card containers and redundant borders with whitespace grid gaps
 3. Progressive Disclosure patterns (Section 30) → Move advanced parameters into collapsible accordions or popovers
@@ -31,18 +32,22 @@ Systematically strip away visual clutter, redundant controls, and cognitive fric
 ## The 4 Distillation Steps
 
 ### 1. Identify & Remove Visual Noise
+
 - **Container Reduction**: Eliminate unnecessary nested cards, boxes inside boxes, and decorative borders. Use whitespace instead of lines to separate content blocks.
 - **Icon Pruning**: Remove decorative icons that restate obvious text labels (e.g. an envelope icon next to a button that clearly says "Send Email").
 
 ### 2. Collapse Secondary Actions
+
 - **Primary vs Overflow**: Keep only 1 primary action button and max 1 secondary button visible. Hide tertiary actions inside an overflow dropdown (`...` menu).
 - **Progressive Disclosure**: Hide advanced settings or non-essential controls behind an "Advanced Settings" accordion or popover.
 
 ### 3. Trim Copy & Microcopy
-- **Cut Conversational Filler**: Strip verbose instructions. Change *"Please fill out the form below to register your account"* to *"Create account"*.
-- **Shorten Button Labels**: Change *"Click here to update your profile settings"* to *"Save profile"*.
+
+- **Cut Conversational Filler**: Strip verbose instructions. Change _"Please fill out the form below to register your account"_ to _"Create account"_.
+- **Shorten Button Labels**: Change _"Click here to update your profile settings"_ to _"Save profile"_.
 
 ### 4. Group Related Fields
+
 - **Consolidate Form Inputs**: Merge separate "First Name" and "Last Name" fields into "Full Name" if separate values aren't strictly required. Merge city/state/zip into single address lookup where possible.
 
 ---

package/.agent/skills/documentation-templates/SKILL.md

@@ -20,6 +20,7 @@ scripts-binding:
 ## Mandatory Pre-Flight Context Inspection
 
 Before creating or editing documentation, API references, or comments, you MUST inspect:
+
 1. Target Audience Identification (Section 27) → Match template strictly to audience (README for 10-min quickstart, API docs for payload contracts, Runbook for on-call triage)
 2. Explain "Why", Not "What" in Code Comments (Section 147) → Document non-obvious business rules or bug workarounds; ban restating obvious code syntax
 3. AI-Friendly Documentation Mapping (Section 171) → Maintain `ARCHITECTURE.md` and `@purpose:` annotations for codebase mental models and automated ingestion
@@ -149,8 +150,8 @@ Creates a new user account.
 **Example**
 \`\`\`bash
 curl -X POST /api/users \
- -H "Content-Type: application/json" \
- -d '{"email": "user@example.com", "name": "Jane"}'
+-H "Content-Type: application/json" \
+-d '{"email": "user@example.com", "name": "Jane"}'
 \`\`\`
 ```
 

package/.agent/skills/domain-modeling/SKILL.md

@@ -20,6 +20,7 @@ scripts-binding:
 ## Mandatory Pre-Flight Context Inspection
 
 Before designing domain entities or business modeling, you MUST inspect:
+
 1. Ubiquitous Language Uniformity (Section 25) → Standardize 1 explicit term across UI, code, and DB (e.g. Customer vs User); ban interchangeable synonyms
 2. Bounded Context Separation (Section 30) → Isolate models per context (e.g. Inventory Product vs Catalog Product); ban 60-column monolithic entities
 3. Aggregate Root Invariants (Section 34) → Mutate child entities strictly through Aggregate Root methods (`order.addItem(...)`); ban direct child mutations
@@ -33,30 +34,37 @@ Model business domain concepts cleanly before committing to database schemas or
 ## 4 Domain Modeling Rules
 
 ### 1. Establish Ubiquitous Language
+
 - Agree on strict, unambiguous terms used identically across domain experts, code variable names, database tables, and UI copy.
-  - ❌ *User*, *Account*, *Member*, *Client* used interchangeably for the same concept.
+  - ❌ _User_, _Account_, _Member_, _Client_ used interchangeably for the same concept.
   - ✅ Define 1 clear term: **Customer** (for billing context) vs **User** (for authentication context).
 
 ### 2. Define Bounded Contexts
-- Separate large systems into distinct bounded contexts. An entity named `Product` in the *Inventory Context* (stock level, warehouse bin) has different attributes than `Product` in the *Catalog Context* (hero image, pricing).
+
+- Separate large systems into distinct bounded contexts. An entity named `Product` in the _Inventory Context_ (stock level, warehouse bin) has different attributes than `Product` in the _Catalog Context_ (hero image, pricing).
 
 ### 3. Aggregates & Invariants
+
 - An **Aggregate Root** (e.g. `Order`) enforces internal business invariants across child entities (`OrderItem`).
 - Never mutate a child entity (`OrderItem`) directly without passing through the aggregate root method (`order.addItem(product, qty)`).
 
 ### 4. Value Objects Over Primitives
+
 - Wrap primitives into type-safe Value Objects to enforce validation logic:
+
 ```typescript
 // Value Object enforcing domain rule
 export class EmailAddress {
   private readonly value: string;
 
   constructor(email: string) {
-    if (!email.includes("@")) throw new Error("Invalid email domain");
+    if (!email.includes('@')) throw new Error('Invalid email domain');
     this.value = email.toLowerCase().trim();
   }
 
-  public toString(): string { return this.value; }
+  public toString(): string {
+    return this.value;
+  }
 }
 ```
 

package/.agent/skills/duckdb-analytical-sql/SKILL.md

@@ -0,0 +1,59 @@
+---
+name: duckdb-analytical-sql
+description: Embedded OLAP analytics, high-speed Parquet/JSON processing, in-memory analytical SQL, and DuckDB integrations in Node.js, Python, and WASM.
+tools: Read, Grep, Glob, Edit, Write
+version: 3.0.0
+last-updated: 2026-08-05
+script: .agent/scripts/schema_validator.js
+scripts-binding:
+  - .agent/scripts/schema_validator.js
+skills:
+  - sql-pro
+  - database-design
+  - performance-profiling
+---
+
+# DuckDB Analytical SQL — Embedded Analytics
+
+## Mandatory Pre-Flight Context Inspection
+
+Before writing analytical queries:
+
+1. Direct File Querying → Query Parquet/CSV/JSON directly without importing into a traditional DB
+2. Memory Allocation → Set explicit memory limit (`SET max_memory = '4GB'`) to prevent OOM
+3. Vectorized Engine Usage → Use column-oriented aggregation over line-by-line loops
+
+## Node.js DuckDB Parquet Query Pattern
+
+```typescript
+import { Database } from 'duckdb-async';
+
+export async function runAnalyticalReport(parquetGlobPath: string) {
+  const db = await Database.create(':memory:');
+
+  // Set memory limits for embedded execution
+  await db.exec("SET max_memory = '2GB'; SET threads = 4;");
+
+  const rows = await db.all(
+    `
+    SELECT 
+        date_trunc('day', timestamp) as event_day,
+        event_type,
+        COUNT(*) as total_count,
+        QUANTILE_CONT(duration_ms, 0.95) as p95_latency
+    FROM read_parquet(?)
+    GROUP BY 1, 2
+    ORDER BY 1 DESC
+    LIMIT 100
+  `,
+    [parquetGlobPath],
+  );
+
+  return rows;
+}
+```
+
+## 🛑 Verification-Before-Completion (VBC) Protocol
+
+- Verify query execution on sample Parquet dataset without loading entire file into RAM.
+- Benchmark query throughput against memory constraints.

package/.agent/skills/edge-ai-mobile/SKILL.md

@@ -0,0 +1,50 @@
+---
+name: edge-ai-mobile
+description: On-device mobile AI, CoreML, Android NNAPI, ONNX Runtime Web/Mobile, local LLM execution (SLMs), and sub-10ms privacy-first edge inference.
+tools: Read, Grep, Glob, Edit, Write
+version: 3.0.0
+last-updated: 2026-08-05
+script: .agent/scripts/bundle_analyzer.js
+scripts-binding:
+  - .agent/scripts/bundle_analyzer.js
+skills:
+  - mobile-developer
+  - browser-native-ai
+  - performance-profiling
+---
+
+# Edge AI & On-Device Mobile Machine Learning
+
+## Mandatory Pre-Flight Context Inspection
+
+Before deploying on-device AI models:
+
+1. Model Quantization → Use 4-bit/8-bit quantized models (GGUF/ONNX) to fit mobile RAM budgets (<500MB)
+2. Hardware Acceleration → Bind inference engine to Apple Neural Engine (ANE) or Android NPU
+3. Fallback Mechanism → Fall back gracefully to cloud LLM API if local inference exceeds latency budget (>200ms)
+
+## Mobile ONNX Edge Inference Pattern
+
+```typescript
+import * as ort from 'onnxruntime-react-native';
+
+export async function runLocalEmbeddings(textTokens: number[]): Promise<Float32Array> {
+  const session = await ort.InferenceSession.create('model_quantized.onnx', {
+    executionProviders: ['cpu'], // Accelerates via ANE/NNAPI internally
+  });
+
+  const tensor = new ort.Tensor('int64', new BigInt64Array(textTokens.map(BigInt)), [
+    1,
+    textTokens.length,
+  ]);
+  const feeds = { input_ids: tensor };
+
+  const results = await session.run(feeds);
+  return results.embedding.data as Float32Array;
+}
+```
+
+## 🛑 Verification-Before-Completion (VBC) Protocol
+
+- Verify local memory usage remains under 300MB during active model inference.
+- Measure battery consumption impact.

package/.agent/skills/edge-computing/SKILL.md

@@ -20,6 +20,7 @@ scripts-binding:
 ## Mandatory Pre-Flight Context Inspection
 
 Before engineering edge computing handlers or Cloudflare Workers, you MUST inspect:
+
 1. Edge Runtime Restrictions (Section 25) → Strictly ban Node.js native core modules (`fs`, `child_process`, native `bcrypt`); use Web APIs (`fetch`, `crypto.subtle`)
 2. Stale-While-Revalidate Caching (Section 47) → Use `Cache-Control: s-maxage=60, stale-while-revalidate=86400` and asynchronous `ctx.waitUntil()` cache puts
 3. Edge Database Access (Section 81) → Never open direct raw TCP connections to DBs; use HTTP connection poolers (Prisma Accelerate, LibSQL, Supabase Pooler)
@@ -48,11 +49,11 @@ Edge functions (Cloudflare Workers, Vercel Edge) run on V8 Isolates, NOT standar
 
 ```typescript
 // ❌ BAD: Attempting to use Node native core modules
-import fs from "fs";
-import bcrypt from "bcrypt"; // Has C++ bindings, will instantly crash on V8 edge
+import fs from 'fs';
+import bcrypt from 'bcrypt'; // Has C++ bindings, will instantly crash on V8 edge
 
 // ✅ GOOD: Utilizing standard Web APIs (Fetch, CryptoKey)
-const hashBuffer = await crypto.subtle.digest("SHA-256", new TextEncoder().encode(password));
+const hashBuffer = await crypto.subtle.digest('SHA-256', new TextEncoder().encode(password));
 ```
 
 ---
@@ -79,7 +80,7 @@ export default {
       // Instructs the Edge CDN: Serve the stale version instantly to the user,
       // but fire an async request in the background to update the cache for the next user.
       response = new Response(response.body, response);
-      response.headers.set("Cache-Control", "s-maxage=60, stale-while-revalidate=86400");
+      response.headers.set('Cache-Control', 's-maxage=60, stale-while-revalidate=86400');
 
       // 4. Store in Cache asynchronously (do not block the user response)
       ctx.waitUntil(cache.put(request, response.clone()));
@@ -104,14 +105,14 @@ Running logic globally while querying a monolithic database in `us-east-1` is co
 
 ```typescript
 // ✅ Turso / LibSQL (Distributed Edge DB) usage:
-import { createClient } from "@libsql/client/web";
+import { createClient } from '@libsql/client/web';
 
 const client = createClient({
   url: env.TURSO_DATABASE_URL,
   authToken: env.TURSO_AUTH_TOKEN,
 });
 
-const result = await client.execute("SELECT * FROM users WHERE id = ?", [userId]);
+const result = await client.execute('SELECT * FROM users WHERE id = ?', [userId]);
 ```
 
 ---
@@ -137,9 +138,9 @@ export class ChatRoom {
     pair.server.accept();
 
     // Handle incoming Chat messages
-    pair.server.addEventListener("message", (msg) => {
+    pair.server.addEventListener('message', msg => {
       // Broadcast to all other connected edge users
-      this.sessions.forEach((session) => session.send(msg.data));
+      this.sessions.forEach(session => session.send(msg.data));
     });
 
     return new Response(null, { status: 101, webSocket: pair.client });

package/.agent/skills/emil-design-eng/SKILL.md

@@ -20,6 +20,7 @@ scripts-binding:
 ## Mandatory Pre-Flight Context Inspection
 
 Before designing or reviewing UI micro-animations, you MUST inspect:
+
 1. Frequency Gate (Section 54) → Never animate keyboard actions or high-frequency controls (100+ times/day); keep UI animations under 300ms
 2. Easing Rule (Section 75) → Use strong `ease-out` (`cubic-bezier(0.23, 1, 0.32, 1)`) for entering UI elements; ban `ease-in`
 3. Origin-Aware Popovers (Section 114) → Never animate scale from `scale(0)`; start at `scale(0.95)` with origin bound to trigger coordinates
@@ -35,44 +36,50 @@ You are a design engineer with the craft sensibility. You build interfaces where
 ## Core Philosophy
 
 ### Taste is trained, not innate
+
 Good taste is not personal preference. It is a trained instinct: the ability to see beyond the obvious and recognize what elevates. Develop it by surrounding yourself with great work, thinking deeply about why something feels good, and practicing relentlessly.
 
 ### Unseen details compound
+
 Most details users never consciously notice. That is the point. When a feature functions exactly as someone assumes it should, they proceed without giving it a second thought. Every decision below exists because the aggregate of invisible correctness creates interfaces people love without knowing why.
 
 ### Beauty is leverage
+
 People select tools based on the overall experience, not just functionality. Good defaults and good animations are real differentiators. Use beauty as leverage to stand out.
 
 ## Review Format (Required)
 
 When reviewing UI code, you MUST use a markdown table with Before/After columns. Do NOT use a list with "Before:" and "After:" on separate lines. Always output an actual markdown table like this:
 
-| Before | After | Why |
-| --- | --- | --- |
-| `transition: all 300ms` | `transition: transform 200ms ease-out` | Specify exact properties; avoid `all` |
-| `transform: scale(0)` | `transform: scale(0.95); opacity: 0` | Nothing in the real world appears from nothing |
-| `ease-in` on dropdown | `ease-out` with custom curve | `ease-in` feels sluggish; `ease-out` gives instant feedback |
-| No `:active` state on button | `transform: scale(0.97)` on `:active` | Buttons must feel responsive to press |
-| `transform-origin: center` | `transform-origin: var(--radix-popover-content-transform-origin)` | Popovers should scale from their trigger |
+| Before                       | After                                                             | Why                                                         |
+| ---------------------------- | ----------------------------------------------------------------- | ----------------------------------------------------------- |
+| `transition: all 300ms`      | `transition: transform 200ms ease-out`                            | Specify exact properties; avoid `all`                       |
+| `transform: scale(0)`        | `transform: scale(0.95); opacity: 0`                              | Nothing in the real world appears from nothing              |
+| `ease-in` on dropdown        | `ease-out` with custom curve                                      | `ease-in` feels sluggish; `ease-out` gives instant feedback |
+| No `:active` state on button | `transform: scale(0.97)` on `:active`                             | Buttons must feel responsive to press                       |
+| `transform-origin: center`   | `transform-origin: var(--radix-popover-content-transform-origin)` | Popovers should scale from their trigger                    |
 
 ## The Animation Decision Framework
 
 Before writing any animation code, answer these questions in order:
 
 ### 1. Should this animate at all?
+
 **Ask:** How often will users see this animation?
 
-| Frequency | Decision |
-| --- | --- |
-| 100+ times/day (keyboard shortcuts, command palette) | No animation. Ever. |
-| Tens of times/day (hover effects, list navigation) | Remove or drastically reduce |
-| Occasional (modals, drawers, toasts) | Standard animation |
-| Rare/first-time (onboarding, feedback forms, celebrations) | Can add delight |
+| Frequency                                                  | Decision                     |
+| ---------------------------------------------------------- | ---------------------------- |
+| 100+ times/day (keyboard shortcuts, command palette)       | No animation. Ever.          |
+| Tens of times/day (hover effects, list navigation)         | Remove or drastically reduce |
+| Occasional (modals, drawers, toasts)                       | Standard animation           |
+| Rare/first-time (onboarding, feedback forms, celebrations) | Can add delight              |
 
 **Never animate keyboard-initiated actions.** These actions are repeated hundreds of times daily. Animation makes them feel slow and disconnected.
 
 ### 2. What is the purpose?
+
 Valid purposes:
+
 - **Spatial consistency**: toast enters/exits from the same direction.
 - **State indication**: a morphing feedback button shows state change.
 - **Explanation**: a marketing animation showing a feature.
@@ -82,45 +89,52 @@ Valid purposes:
 If the purpose is just "it looks cool" and the user sees it often, don't animate.
 
 ### 3. What easing should it use?
+
 Is the element entering or exiting?
-  Yes → ease-out (starts fast, feels responsive)
-  No →
-    Is it moving/morphing on screen?
-      Yes → ease-in-out (natural acceleration/deceleration)
-    Is it a hover/color change?
-      Yes → ease
-    Is it constant motion?
-      Yes → linear
-    Default → ease-out
+Yes → ease-out (starts fast, feels responsive)
+No →
+Is it moving/morphing on screen?
+Yes → ease-in-out (natural acceleration/deceleration)
+Is it a hover/color change?
+Yes → ease
+Is it constant motion?
+Yes → linear
+Default → ease-out
 
 **Critical: use custom easing curves.**
+
 ```css
 /* Strong ease-out for UI interactions */
 --ease-out: cubic-bezier(0.23, 1, 0.32, 1);
 /* Strong ease-in-out for on-screen movement */
 --ease-in-out: cubic-bezier(0.77, 0, 0.175, 1);
 ```
+
 **Never use ease-in for UI animations.** It makes the interface feel sluggish.
 
 ### 4. How fast should it be?
-| Element | Duration |
-| --- | --- |
-| Button press feedback | 100-160ms |
+
+| Element                  | Duration  |
+| ------------------------ | --------- |
+| Button press feedback    | 100-160ms |
 | Tooltips, small popovers | 125-200ms |
-| Dropdowns, selects | 150-250ms |
-| Modals, drawers | 200-500ms |
+| Dropdowns, selects       | 150-250ms |
+| Modals, drawers          | 200-500ms |
 
 **Rule: UI animations should stay under 300ms.** Perception of speed matters as much as actual speed.
 
 ## Component Building Principles
 
 ### Buttons must feel responsive
+
 Add `transform: scale(0.97)` on `:active` with subtle transition (160ms ease-out).
 
 ### Never animate from scale(0)
+
 Start from `scale(0.95)` or higher combined with opacity.
 
 ### Make popovers origin-aware
+
 Popovers should scale in from their trigger, not from center. Explicitly set `transform-origin` to the trigger coordinates (e.g., `var(--radix-popover-content-transform-origin)`). Modals are exempt as they are viewport-centered.
 
 ---
@@ -141,6 +155,7 @@ Popovers should scale in from their trigger, not from center. Explicitly set `tr
 ### ✅ Pre-Flight Self-Audit
 
 Review these questions before confirming output:
+
 ```
 ✅ Did I justify the animation's existence based on frequency?
 ✅ Are all UI animations under 300ms?
@@ -152,5 +167,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 animation work complete because the code compiles.
 - ✅ **Required:** Provide evidence that the animation executes flawlessly at 60fps in the browser, adhering to the 300ms budget and easing rules.

package/.agent/skills/error-resilience/SKILL.md

@@ -20,6 +20,7 @@ scripts-binding:
 ## Mandatory Pre-Flight Context Inspection
 
 Before writing retry logic, circuit breakers, or error handling routines, you MUST inspect:
+
 1. Idempotency Key Rule for Retries (Section 123) → Require explicit idempotency keys when retrying non-safe operations (POST/PUT); ban un-keyed retries
 2. Exponential Backoff with Jitter (Section 106) → Implement randomized full jitter with capped exponential delays; ban fixed-delay retry loops
 3. Operational vs Programmer Error Split (Section 28) → Catch and recover strictly from `OperationalError` instances; allow programmer bugs (`TypeError`) to crash fast
@@ -102,7 +103,12 @@ const DEFAULT_RETRY: RetryOptions = {
   maxRetries: 3,
   baseDelayMs: 500,
   maxDelayMs: 15_000,
-  retryableErrors: (err) => err instanceof Error && (err.message.includes("ECONNRESET") || err.message.includes("ETIMEDOUT") || err.message.includes("503") || err.message.includes("429")),
+  retryableErrors: err =>
+    err instanceof Error &&
+    (err.message.includes('ECONNRESET') ||
+      err.message.includes('ETIMEDOUT') ||
+      err.message.includes('503') ||
+      err.message.includes('429')),
 };
 
 async function withRetry<T>(fn: () => Promise<T>, options: Partial<RetryOptions> = {}): Promise<T> {
@@ -122,16 +128,19 @@ async function withRetry<T>(fn: () => Promise<T>, options: Partial<RetryOptions>
       const capped = Math.min(exponential, opts.maxDelayMs);
       const jitter = Math.random() * capped;
 
-      console.warn(`[RETRY] Attempt ${attempt + 1}/${opts.maxRetries} failed. ` + `Retrying in ${Math.round(jitter)}ms...`);
+      console.warn(
+        `[RETRY] Attempt ${attempt + 1}/${opts.maxRetries} failed. ` +
+          `Retrying in ${Math.round(jitter)}ms...`,
+      );
 
       await sleep(jitter);
     }
   }
-  throw new Error("Unreachable");
+  throw new Error('Unreachable');
 }
 
 function sleep(ms: number): Promise<void> {
-  return new Promise((resolve) => setTimeout(resolve, ms));
+  return new Promise(resolve => setTimeout(resolve, ms));
 }
 
 // ❌ NEVER retry non-idempotent operations without idempotency keys
@@ -145,9 +154,9 @@ function sleep(ms: number): Promise<void> {
 
 ```typescript
 enum CircuitState {
-  CLOSED = "CLOSED", // Normal — requests pass through
-  OPEN = "OPEN", // Tripped — requests fail immediately
-  HALF_OPEN = "HALF_OPEN", // Testing — one request allowed
+  CLOSED = 'CLOSED', // Normal — requests pass through
+  OPEN = 'OPEN', // Tripped — requests fail immediately
+  HALF_OPEN = 'HALF_OPEN', // Testing — one request allowed
 }
 
 class CircuitBreaker {
@@ -210,7 +219,7 @@ const paymentCircuit = new CircuitBreaker(5, 30_000);
 
 const result = await paymentCircuit.execute(
   () => paymentGateway.charge(amount),
-  () => ({ status: "deferred", message: "Payment queued for retry" }),
+  () => ({ status: 'deferred', message: 'Payment queued for retry' }),
 );
 ```
 
@@ -220,7 +229,7 @@ const result = await paymentCircuit.execute(
 
 ```tsx
 // ✅ Error boundary with recovery
-import { Component, type ReactNode } from "react";
+import { Component, type ReactNode } from 'react';
 
 interface Props {
   children: ReactNode;
@@ -251,7 +260,9 @@ class ErrorBoundary extends Component<Props, State> {
         this.props.fallback ?? (
           <div role="alert">
             <h2>Something went wrong</h2>
-            <button onClick={() => this.setState({ hasError: false, error: null })}>Try Again</button>
+            <button onClick={() => this.setState({ hasError: false, error: null })}>
+              Try Again
+            </button>
           </div>
         )
       );
@@ -273,7 +284,10 @@ class ErrorBoundary extends Component<Props, State> {
 
 ```typescript
 // ✅ AbortController-based timeout (modern, cancellable)
-async function withTimeout<T>(fn: (signal: AbortSignal) => Promise<T>, timeoutMs: number): Promise<T> {
+async function withTimeout<T>(
+  fn: (signal: AbortSignal) => Promise<T>,
+  timeoutMs: number,
+): Promise<T> {
   const controller = new AbortController();
   const timer = setTimeout(() => controller.abort(), timeoutMs);
 
@@ -290,7 +304,7 @@ async function withTimeout<T>(fn: (signal: AbortSignal) => Promise<T>, timeoutMs
 }
 
 // Usage
-const data = await withTimeout((signal) => fetch("https://api.example.com/data", { signal }), 5000);
+const data = await withTimeout(signal => fetch('https://api.example.com/data', { signal }), 5000);
 ```
 
 ---
@@ -318,8 +332,8 @@ async function getUserProfile(userId: string): Promise<UserProfile> {
   // Layer 3: Default
   return {
     id: userId,
-    name: "Unknown User",
-    avatar: "/default-avatar.png",
+    name: 'Unknown User',
+    avatar: '/default-avatar.png',
     _stale: true,
     _default: true,
   };
@@ -343,7 +357,11 @@ interface DeadLetter<T> {
   originalQueue: string;
 }
 
-async function processWithDLQ<T>(payload: T, processor: (item: T) => Promise<void>, dlqStore: { push: (item: DeadLetter<T>) => Promise<void> }): Promise<void> {
+async function processWithDLQ<T>(
+  payload: T,
+  processor: (item: T) => Promise<void>,
+  dlqStore: { push: (item: DeadLetter<T>) => Promise<void> },
+): Promise<void> {
   try {
     await withRetry(() => processor(payload), { maxRetries: 3 });
   } catch (error) {
@@ -353,7 +371,7 @@ async function processWithDLQ<T>(payload: T, processor: (item: T) => Promise<voi
       error: error instanceof Error ? error.message : String(error),
       failedAt: new Date().toISOString(),
       attempts: 4,
-      originalQueue: "main",
+      originalQueue: 'main',
     });
     // Don't throw — the message is preserved for manual review
   }