tribunal-kit 4.5.1 → 4.6.1

package/.agent/skills/red-team-tactics/SKILL.md

@@ -1,222 +1,233 @@
----
-name: red-team-tactics
-description: Red team tactics principles based on MITRE ATT&CK. Attack phases, detection evasion, reporting.
-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
----
-
-## Hallucination Traps (Read First)
-- ❌ Testing only happy-path authentication -> ✅ Red teaming must test token reuse, expired tokens, forged tokens, and privilege escalation
-- ❌ Reporting vulnerabilities without proof-of-concept -> ✅ Every finding needs a reproducible PoC and severity rating (CVSS)
-- ❌ Stopping after finding the first vulnerability -> ✅ Real attackers chain multiple low-severity issues; test for escalation paths
-
----
-
-
-# Red Team & Penetration Testing Principles
-
-A red team engagement is a controlled attack.
-The goal is to find what a real attacker would find — before they do.
-
-⚠️ **These techniques are for authorized security testing only. Unauthorized use is illegal.**
-
----
-
-## Engagement Scope First
-
-Before any testing activity:
-
-1. **Written authorization** — who authorized this engagement and in what scope?
-2. **Scope definition** — which systems, IPs, domains, time windows are in scope?
-3. **Rules of engagement** — what is prohibited? (production data access, social engineering of specific roles, DDoS)
-4. **Emergency contact** — who do you call if you discover a critical live breach mid-engagement?
-5. **Deconfliction** — does the blue team know an engagement is running, or is it blind?
-
-No authorization = no testing.
-
----
-
-## Attack Phases (Based on MITRE ATT&CK)
-
-### 1. Reconnaissance
-Passive and active information gathering before touching the target.
-
-**Passive (no target contact):**
-- DNS lookup: `nslookup`, `dig`, certificate transparency logs
-- OSINT: LinkedIn for employee names/roles, GitHub for leaked configs, Shodan for exposed infrastructure
-
-**Active (target is contacted):**
-- Port scanning: `nmap -sV -sC <target>`
-- Web tech detection: `whatweb`, `wappalyzer`
-- Subdomain enumeration: `amass`, `subfinder`
-
-### 2. Initial Access
-How does an attacker get their first foothold?
-
-Common vectors:
-- Phishing (credential harvest or malicious attachment)
-- Exposed admin interfaces with default or weak credentials
-- Publicly exposed vulnerable services (`searchsploit`, `nuclei`)
-- Supply chain compromise (malicious npm package, CI/CD injection)
-
-### 3. Persistence
-Maintaining access after initial compromise:
-
-- Scheduled tasks / cron jobs
-- Web shells on compromised web servers
-- New user accounts with admin rights
-- SSH authorized_keys injection
-
-### 4. Lateral Movement
-Moving from initial foothold to higher-value targets:
-
-- Pass-the-hash / pass-the-ticket (Active Directory)
-- SSH key reuse across hosts
-- Credential reuse (if one service is compromised, others sharing the password are vulnerable)
-- Internal network scanning to map new targets
-
-### 5. Exfiltration
-Getting data out without triggering alerts:
-
-- Small, slow transfers to blend with normal traffic
-- Staging data in cloud storage linked to attacker-controlled accounts
-- DNS exfiltration (for heavily monitored networks)
-
----
-
-## Common Vulnerability Targets
-
-|Target|What to Test|
-|---|---|
-|Web applications|OWASP Top 10, auth bypass, IDOR, SSRF|
-|APIs|Object-level authorization, mass assignment, rate limiting|
-|Authentication|Brute force protection, token entropy, password reset flow|
-|Secrets|Exposed env files, git history, CI/CD environment variables|
-|Third-party integrations|Webhook validation, OAuth redirect URI validation|
-|Infrastructure|Open S3 buckets, exposed admin ports, default credentials|
-
----
-
-## Detection Evasion (for Authorized Testing)
-
-When testing detection capabilities:
-
-- Slow scan rates to stay under IDS thresholds
-- Use legitimate user agents and headers
-- Blend with normal traffic patterns
-- Test from IP ranges the organization wouldn't expect
-
----
-
-## Reporting Format
-
-```markdown
-# Red Team Report: [Engagement Name]
-
-## Executive Summary
-[2–3 sentences: what was tested, biggest risk found, business impact]
-
-## Scope
-[Systems tested, date range, authorization reference]
-
-## Critical Findings
-
-### CRIT-01: [Title]
-**Risk:** Critical
-**CVSS:** 9.8
-**Description:** [What the vulnerability is]
-**Evidence:** [Screenshot, payload, response]
-**Impact:** [What an attacker could do]
-**Remediation:** [Specific fix with code or config example]
-
-## Attack Narrative
-[Chronological story of the full attack path from initial access to objective]
-
-## Remediation Priority
-|Finding|Severity|Fix By|
-|---|---|---|
-```
-
----
-
-## Ethical Boundaries
-
-- Stop immediately if you discover evidence of an active breach by a real attacker — report it, don't continue testing
-- Don't access, copy, or delete real user data even if you can
-- Document everything — every command run, every finding noted
-- Brief the client team before leaving — no surprises in the report
-
----
-
-## Output Format
-
-When this skill produces a recommendation or design decision, structure your output as:
-
-```
-━━━ Red Team Tactics Recommendation ━━━━━━━━━━━━━━━━
-Decision:    [what was chosen / proposed]
-Rationale:   [why — one concise line]
-Trade-offs:  [what is consciously accepted]
-Next action: [concrete next step for the user]
-─────────────────────────────────────────────────
-Pre-Flight:  ✅ All checks passed
-             or ❌ [blocking item that must be resolved first]
-```
-
----
-
-
----
-
-
-
-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: red-team-tactics
+description: Red team tactics principles based on MITRE ATT&CK. Attack phases, detection evasion, reporting.
+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
+routing:
+  domain: general
+  tier: basic
+---
+
+## Hallucination Traps (Read First)
+
+- ❌ Testing only happy-path authentication -> ✅ Red teaming must test token reuse, expired tokens, forged tokens, and privilege escalation
+- ❌ Reporting vulnerabilities without proof-of-concept -> ✅ Every finding needs a reproducible PoC and severity rating (CVSS)
+- ❌ Stopping after finding the first vulnerability -> ✅ Real attackers chain multiple low-severity issues; test for escalation paths
+
+---
+
+# Red Team & Penetration Testing Principles
+
+A red team engagement is a controlled attack.
+The goal is to find what a real attacker would find — before they do.
 
+⚠️ **These techniques are for authorized security testing only. Unauthorized use is illegal.**
+
+---
+
+## Engagement Scope First
+
+Before any testing activity:
+
+1. **Written authorization** — who authorized this engagement and in what scope?
+2. **Scope definition** — which systems, IPs, domains, time windows are in scope?
+3. **Rules of engagement** — what is prohibited? (production data access, social engineering of specific roles, DDoS)
+4. **Emergency contact** — who do you call if you discover a critical live breach mid-engagement?
+5. **Deconfliction** — does the blue team know an engagement is running, or is it blind?
+
+No authorization = no testing.
+
+---
+
+## Attack Phases (Based on MITRE ATT&CK)
+
+### 1. Reconnaissance
+
+Passive and active information gathering before touching the target.
+
+**Passive (no target contact):**
+
+- DNS lookup: `nslookup`, `dig`, certificate transparency logs
+- OSINT: LinkedIn for employee names/roles, GitHub for leaked configs, Shodan for exposed infrastructure
+
+**Active (target is contacted):**
+
+- Port scanning: `nmap -sV -sC <target>`
+- Web tech detection: `whatweb`, `wappalyzer`
+- Subdomain enumeration: `amass`, `subfinder`
+
+### 2. Initial Access
+
+How does an attacker get their first foothold?
+
+Common vectors:
+
+- Phishing (credential harvest or malicious attachment)
+- Exposed admin interfaces with default or weak credentials
+- Publicly exposed vulnerable services (`searchsploit`, `nuclei`)
+- Supply chain compromise (malicious npm package, CI/CD injection)
+
+### 3. Persistence
+
+Maintaining access after initial compromise:
+
+- Scheduled tasks / cron jobs
+- Web shells on compromised web servers
+- New user accounts with admin rights
+- SSH authorized_keys injection
+
+### 4. Lateral Movement
+
+Moving from initial foothold to higher-value targets:
+
+- Pass-the-hash / pass-the-ticket (Active Directory)
+- SSH key reuse across hosts
+- Credential reuse (if one service is compromised, others sharing the password are vulnerable)
+- Internal network scanning to map new targets
+
+### 5. Exfiltration
+
+Getting data out without triggering alerts:
+
+- Small, slow transfers to blend with normal traffic
+- Staging data in cloud storage linked to attacker-controlled accounts
+- DNS exfiltration (for heavily monitored networks)
+
+---
+
+## Common Vulnerability Targets
+
+| Target                   | What to Test                                                |
+| ------------------------ | ----------------------------------------------------------- |
+| Web applications         | OWASP Top 10, auth bypass, IDOR, SSRF                       |
+| APIs                     | Object-level authorization, mass assignment, rate limiting  |
+| Authentication           | Brute force protection, token entropy, password reset flow  |
+| Secrets                  | Exposed env files, git history, CI/CD environment variables |
+| Third-party integrations | Webhook validation, OAuth redirect URI validation           |
+| Infrastructure           | Open S3 buckets, exposed admin ports, default credentials   |
+
+---
+
+## Detection Evasion (for Authorized Testing)
+
+When testing detection capabilities:
+
+- Slow scan rates to stay under IDS thresholds
+- Use legitimate user agents and headers
+- Blend with normal traffic patterns
+- Test from IP ranges the organization wouldn't expect
+
+---
+
+## Reporting Format
+
+```markdown
+# Red Team Report: [Engagement Name]
+
+## Executive Summary
+
+[2–3 sentences: what was tested, biggest risk found, business impact]
+
+## Scope
+
+[Systems tested, date range, authorization reference]
+
+## Critical Findings
+
+### CRIT-01: [Title]
+
+**Risk:** Critical
+**CVSS:** 9.8
+**Description:** [What the vulnerability is]
+**Evidence:** [Screenshot, payload, response]
+**Impact:** [What an attacker could do]
+**Remediation:** [Specific fix with code or config example]
+
+## Attack Narrative
+
+[Chronological story of the full attack path from initial access to objective]
+
+## Remediation Priority
+
+| Finding | Severity | Fix By |
+| ------- | -------- | ------ |
+```
+
+---
+
+## Ethical Boundaries
+
+- Stop immediately if you discover evidence of an active breach by a real attacker — report it, don't continue testing
+- Don't access, copy, or delete real user data even if you can
+- Document everything — every command run, every finding noted
+- Brief the client team before leaving — no surprises in the report
+
+---
+
+## Output Format
+
+When this skill produces a recommendation or design decision, structure your output as:
+
+```
+━━━ Red Team Tactics Recommendation ━━━━━━━━━━━━━━━━
+Decision:    [what was chosen / proposed]
+Rationale:   [why — one concise line]
+Trade-offs:  [what is consciously accepted]
+Next action: [concrete next step for the user]
+─────────────────────────────────────────────────
+Pre-Flight:  ✅ All checks passed
+             or ❌ [blocking item that must be resolved first]
+```
+
+---
+
+---
+
+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.
 
 ---
 
@@ -246,6 +257,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?
@@ -256,5 +268,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/review-animations/SKILL.md

@@ -0,0 +1,72 @@
+---
+name: review-animations
+description: Reviews animation and motion code against a high craft bar derived from Emil Kowalski's design engineering philosophy. Default to flagging; approval is earned.
+version: 1.0.0
+last-updated: 2026-06-26
+applies-to-model: gemini-3-1-pro, claude-3-7-sonnet
+disable-model-invocation: true
+routing:
+  domain: review
+  tier: specialized
+  trigger-signals:
+    strong: [review animations, motion review, ui animation craft, 60fps, animation standards, evaluate motion]
+    weak: [review UI, check transitions, smooth animation]
+---
+
+# Reviewing Animations
+
+A specialized review skill. It does ONE thing: review animation and motion code against a high craft bar. It does not write features, fix unrelated bugs, or review non-motion code. If asked to review general code, decline and point to a general review skill.
+
+## Operating Posture
+
+You are a senior motion-design reviewer with a brutal eye for craft. Your bias is toward **motion that feels right**, not motion that merely runs. A transition that "works" but feels sluggish, lands from the wrong origin, fires too often, or drops frames is a regression, not a pass. Default to flagging. Approval is earned, not assumed.
+
+The substantive bar comes from Emil Kowalski's animation philosophy (animations.dev). The review *method* — non-negotiable standards, escalation triggers, a remedial hierarchy, tiered output, and explicit approval criteria — is adapted from aggressive code-quality review.
+
+For the full rule catalog (easing curves, duration tables, spring config, gestures, clip-path, performance, a11y), see [STANDARDS.md](STANDARDS.md). Load it whenever a finding needs a precise value or citation.
+
+## The Ten Non-Negotiable Standards
+
+Every animation in the diff is measured against these. A violation is a finding.
+
+1. **Justified motion.** Every animation must answer "why does this animate?" — spatial consistency, state indication, feedback, explanation, or preventing a jarring change. "It looks cool" on a frequently-seen element is a block.
+2. **Frequency-appropriate.** Match motion to how often it's seen. Keyboard-initiated and 100+/day actions get **no** animation. Tens/day gets reduced motion. Occasional gets standard. Rare/first-time can have delight.
+3. **Responsive easing.** Entering/exiting elements use `ease-out` or a strong custom curve. `ease-in` on UI is a block — it delays the moment the user watches most. Built-in CSS easings are too weak; expect custom cubic-beziers.
+4. **Sub-300ms UI.** UI animations stay under 300ms; anything slower on a UI element needs justification or it's a finding.
+5. **Origin & physical correctness.** Popovers/dropdowns/tooltips scale from their trigger (`transform-origin`), not center. Never animate from `scale(0)` — start from `scale(0.9–0.97)` + opacity. (Modals are exempt — they stay centered.)
+6. **Interruptibility.** Rapidly-triggered or gesture-driven motion (toasts, toggles, drags) must be interruptible — CSS transitions or springs that retarget from current state, not keyframes that restart from zero.
+7. **GPU-only properties.** Animate `transform` and `opacity` only. Animating `width`/`height`/`margin`/`padding`/`top`/`left` is a performance finding.
+8. **Accessibility.** `prefers-reduced-motion` is honored (gentler, not zero — keep opacity/color, drop movement). Hover animations are gated behind `@media (hover: hover) and (pointer: fine)`.
+9. **Asymmetric enter/exit.** Deliberate actions (a press, a hold, a destructive confirm) animate slower; system responses snap. Symmetric timing on a press-and-release or hold interaction is a finding.
+10. **Cohesion.** Motion matches the component's personality and the rest of the product — playful can be appropriate for consumer apps, but not for enterprise dashboards. Verify the motion fits the context.
+
+---
+
+## 🤖 LLM-Specific Traps
+
+1. **Passive Approval:** Approving animations just because the syntax is correct. You must evaluate the *feel* and *performance* against the Standards.
+2. **Ignoring Physics:** Failing to flag elements appearing from nothing (`scale(0)`) or scaling from the wrong origin point.
+3. **Overlooking Duration:** Missing sluggish transitions that exceed the 300ms budget for UI elements.
+4. **Accepting Default Easings:** Approving `ease-in` or generic `ease` on entering UI elements instead of demanding strong `ease-out` curves.
+
+## 🏛️ Tribunal Integration (Anti-Hallucination)
+
+**Slash command: `/review` or `/tribunal-full`**
+**Active reviewers: `frontend-reviewer` · `performance-reviewer`**
+
+### ✅ Pre-Flight Self-Audit
+
+Review these questions before confirming output:
+```
+✅ Did I measure the diff against all 10 non-negotiable standards?
+✅ Did I flag any UI animations exceeding 300ms?
+✅ Did I reject any `ease-in` usage on entering elements?
+✅ Did I verify GPU-only properties (`transform` and `opacity`)?
+✅ Did I check for interruptibility and physical correctness?
+```
+
+### 🛑 Verification-Before-Completion (VBC) Protocol
+
+**CRITICAL:** You must follow a strict "evidence-based closeout" state machine.
+- ❌ **Forbidden:** Marking the review as "Pass" without explicitly evaluating against the STANDARDS.md criteria.
+- ✅ **Required:** Output the review in the standard table format (`| Before | After | Why |`) highlighting all violations, and explicitly stating why approval is earned or withheld.

package/.agent/skills/review-animations/STANDARDS.md

@@ -0,0 +1,73 @@
+# Animation Standards Reference
+
+The precise values, curves, and rules behind the review. Cite these in findings instead of approximating. Distilled from Emil Kowalski's design engineering philosophy ([animations.dev](https://animations.dev/)).
+
+## Should it animate? (frequency table)
+
+| 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, celebrations) | Can add delight |
+
+**Never animate keyboard-initiated actions** — they repeat hundreds of times daily; animation makes them feel slow and disconnected. 
+Valid purposes for motion: spatial consistency, state indication, explanation, feedback, preventing jarring change. "It looks cool" on a frequently-seen element is not valid.
+
+## Easing
+
+Decision order:
+- Entering or exiting → **`ease-out`** (starts fast, feels responsive)
+- Moving / morphing on screen → **`ease-in-out`**
+- Hover / color change → **`ease`**
+- Constant motion (marquee, progress) → **`linear`**
+- Default → **`ease-out`**
+
+**Never `ease-in` on UI.** It starts slow, delaying the exact moment the user is watching. `ease-out` at 200ms *feels* faster than `ease-in` at 200ms.
+
+Built-in CSS easings are too weak. Use strong custom curves:
+```css
+--ease-out: cubic-bezier(0.23, 1, 0.32, 1);        /* strong ease-out for UI */
+--ease-in-out: cubic-bezier(0.77, 0, 0.175, 1);    /* strong ease-in-out for on-screen movement */
+--ease-drawer: cubic-bezier(0.32, 0.72, 0, 1);     /* iOS-like drawer curve (Ionic) */
+```
+
+## Duration
+
+| Element | Duration |
+| --- | --- |
+| Button press feedback | 100–160ms |
+| Tooltips, small popovers | 125–200ms |
+| Dropdowns, selects | 150–250ms |
+| Modals, drawers | 200–500ms |
+| Marketing / explanatory | Can be longer |
+
+**Rule: UI animations stay under 300ms.** A 180ms dropdown feels more responsive than a 400ms one. 
+
+## Physicality
+
+- **Never `scale(0)`.** Start from `scale(0.9–0.97)` + `opacity: 0`. Nothing in the real world appears from nothing.
+- **Origin-aware popovers.** Scale from the trigger, not center.
+- **Button press feedback.** `transform: scale(0.97)` on `:active`, `transition: transform 160ms ease-out`. Subtle (0.95–0.98).
+
+## Springs
+
+Feel natural because they simulate physics; no fixed duration. Use for drag with momentum, interruptible gestures.
+```js
+// Apple-style (easier to reason about) — recommended
+{ type: "spring", duration: 0.5, bounce: 0.2 }
+```
+Keep bounce subtle (0.1–0.3); avoid bounce in most UI. 
+
+## Interruptibility
+
+CSS **transitions** can be interrupted and retargeted mid-animation; **keyframes** restart from zero. For anything triggered rapidly, transitions are smoother.
+```css
+/* Interruptible — good for dynamic UI */
+.toast { transition: transform 400ms ease; }
+
+/* Not interruptible — avoid for dynamic UI */
+@keyframes slideIn { from { transform: translateY(100%); } to { transform: translateY(0); } }
+```
+
+Use `@starting-style` for entry without JS.