mindforge-cc 10.0.2 → 10.7.0

package/.mindforge/skills/quality-audit/SKILL.md

@@ -0,0 +1,171 @@
+---
+name: quality-audit
+version: 1.0.0
+min_mindforge_version: 10.0.4
+status: stable
+triggers: quality audit, quality score, clarity score, completeness check, accuracy check, usefulness score, four-dimension, weighted scoring, quality scoring, output quality, quality threshold, quality comparison
+---
+
+# Skill — Quality Audit (Four-Dimension Weighted Scoring)
+
+## When this skill activates
+When evaluating the quality of any output — code, documentation, architecture
+decisions, generated content, or deliverables. Use to enforce a consistent,
+evidence-based quality bar across all work products. Especially valuable when
+"good enough" is ambiguous and you need a defensible, repeatable score.
+
+Three modes of operation:
+- **Quick mode**: Accuracy dimension only (fast gate check)
+- **Full mode**: All 4 dimensions scored (standard quality gate)
+- **Comparative mode**: Score artifact A vs artifact B on all dimensions
+
+## Mandatory actions when this skill is active
+
+### Before scoring
+
+1. **Identify the artifact type** — code, documentation, API design, generated output, architecture decision, etc.
+2. **Select scoring mode:**
+   - Quick: when you need a fast go/no-go on factual correctness
+   - Full: standard quality gate for all deliverables
+   - Comparative: when choosing between alternatives
+3. **Load custom rubric** (if exists): check `validation/rubric.yaml` in project root or `.mindforge/validation/rubric.yaml`
+4. **Establish context**: what is this artifact supposed to accomplish? Who is the audience?
+
+### During scoring
+
+**The Four Dimensions:**
+
+| Dimension | Weight | Definition | Measures |
+|-----------|--------|------------|----------|
+| Clarity | 25% | How easily understood is the output? | Structure, naming, formatting, progressive disclosure, lack of ambiguity |
+| Completeness | 25% | Does it cover all requirements? | Missing cases, TODOs, partial implementations, unstated assumptions |
+| Accuracy | 30% | Is it factually and logically correct? | Bugs, wrong behavior, incorrect statements, logic errors, type mismatches |
+| Usefulness | 20% | Does it solve the actual problem? | User value, practical applicability, appropriate scope, actionability |
+
+**5-Point Scale (apply consistently):**
+
+| Score | Label | Meaning |
+|-------|-------|---------|
+| 1 | Poor | Fundamentally broken, requires complete rewrite |
+| 2 | Below Average | Significant issues, multiple major fixes needed |
+| 3 | Acceptable | Meets minimum bar, minor issues remain |
+| 4 | Good | Solid work, only cosmetic improvements possible |
+| 5 | Excellent | Exemplary, could serve as a reference implementation |
+
+**Scoring Protocol:**
+1. Read the entire artifact before scoring any dimension
+2. Score each dimension independently (don't let one influence others)
+3. Provide specific evidence for each score (line numbers, examples, quotes)
+4. Calculate weighted average: `(Clarity * 0.25) + (Completeness * 0.25) + (Accuracy * 0.30) + (Usefulness * 0.20)`
+
+**Passing Thresholds:**
+- **Weighted average >= 3.0** — artifact passes overall quality gate
+- **Accuracy >= 3.0 (BLOCKING)** — accuracy must independently meet this bar regardless of other scores
+- An artifact with Clarity=5, Completeness=5, Accuracy=2, Usefulness=5 still FAILS (accuracy blocking gate)
+
+**Scoring Output Format:**
+```json
+{
+  "mode": "quick" | "full" | "comparative",
+  "artifact": "description",
+  "timestamp": "ISO-8601",
+  "scores": {
+    "clarity": {
+      "score": 1-5,
+      "weight": 0.25,
+      "evidence": ["specific observation 1", "specific observation 2"],
+      "improvements": ["actionable suggestion"]
+    },
+    "completeness": {
+      "score": 1-5,
+      "weight": 0.25,
+      "evidence": ["..."],
+      "improvements": ["..."]
+    },
+    "accuracy": {
+      "score": 1-5,
+      "weight": 0.30,
+      "evidence": ["..."],
+      "improvements": ["..."],
+      "blocking_gate": true
+    },
+    "usefulness": {
+      "score": 1-5,
+      "weight": 0.20,
+      "evidence": ["..."],
+      "improvements": ["..."]
+    }
+  },
+  "weighted_average": 0.0,
+  "accuracy_gate_passed": true | false,
+  "overall_verdict": "PASS" | "FAIL",
+  "fail_reason": "null | description"
+}
+```
+
+**Quick Mode (accuracy only):**
+- Score only the Accuracy dimension
+- Pass if Accuracy >= 3.0
+- Use when you need a fast gate check and other dimensions are less relevant
+- Output: simplified JSON with only accuracy scores
+
+**Comparative Mode:**
+- Score both artifacts A and B on all 4 dimensions
+- Report per-dimension winner and overall winner
+- Tie-breaking: Accuracy wins ties, then Usefulness, then Completeness, then Clarity
+- Output includes side-by-side comparison table
+
+**Custom Rubric Support:**
+If `validation/rubric.yaml` exists, it overrides default dimension definitions:
+```yaml
+dimensions:
+  clarity:
+    weight: 0.20  # can adjust weights (must sum to 1.0)
+    criteria:
+      - "Code uses consistent naming conventions"
+      - "Comments explain WHY, not WHAT"
+    passing_score: 3
+  accuracy:
+    weight: 0.35
+    criteria:
+      - "All edge cases handled"
+      - "No logic errors in conditional paths"
+    passing_score: 4  # can raise the bar per-dimension
+    blocking: true
+```
+
+### After scoring
+
+1. **Determine verdict:**
+   - If `accuracy_gate_passed == false` → FAIL (regardless of other scores)
+   - If `weighted_average < 3.0` → FAIL
+   - Otherwise → PASS
+
+2. **If FAIL:**
+   - List all dimensions below threshold
+   - Provide specific, actionable improvements for each
+   - Prioritize: fix accuracy issues first (blocking), then lowest-scoring dimension
+   - Re-score after fixes (don't assume the fix worked)
+
+3. **If PASS:**
+   - Log the score to `.mindforge/quality/[artifact-name]-[timestamp].json`
+   - Note any dimensions at exactly 3.0 (borderline — flag for future improvement)
+   - Record the weighted average as the artifact's quality score
+
+4. **Track trends:**
+   - Compare current score to previous scores for same artifact type
+   - If quality trending downward: flag in session report
+   - If quality consistently above 4.0: consider raising the threshold
+
+## Self-check before task completion
+
+Before marking a task done when this skill was active:
+
+- [ ] Did I score all 4 dimensions (unless using quick mode)?
+- [ ] Did I check the accuracy blocking gate independently?
+- [ ] Did I provide specific evidence (not just scores) for each dimension?
+- [ ] Did I calculate the weighted average correctly?
+- [ ] If the artifact failed: did I provide actionable improvements?
+- [ ] If using custom rubric: did I load it from validation/rubric.yaml?
+- [ ] Is the scoring output in structured JSON format?
+- [ ] Did I avoid letting one dimension's score influence another?

package/.mindforge/skills/queue-design/SKILL.md

@@ -0,0 +1,85 @@
+---
+name: queue-design
+version: 1.0.0
+min_mindforge_version: 10.0.9
+status: stable
+triggers: queue design, message broker selection, kafka vs rabbitmq, queue topology, consumer pattern, message TTL, priority queue, dead letter queue design, queue partitioning, message ordering queue, queue scaling, broker architecture
+compose: event-driven-architecture
+---
+
+# Skill — Queue Design
+
+## When this skill activates
+Any task involving message broker selection, queue topology, consumer patterns,
+TTL policies, priority queues, dead letter queues, or partition strategies.
+
+## Mandatory actions when this skill is active
+
+### Before writing any code
+1. Identify throughput requirements (messages/sec peak and sustained).
+2. Determine ordering and delivery guarantee requirements.
+3. Select broker based on the decision matrix.
+
+### During implementation
+- Configure DLQ for every consumer with retry limits.
+- Set TTL on messages to prevent unbounded queue growth.
+- Implement consumer health checks and graceful shutdown.
+- Use partition keys for ordering-sensitive flows.
+
+### After implementation
+- Set up queue depth monitoring with alerting thresholds.
+- Document topology, routing rules, and consumer ownership.
+- Verify DLQ workflow (inspect, fix, replay, discard).
+
+## Broker Selection
+
+| Broker | Strength | Ordering | Use For |
+|--------|----------|----------|---------|
+| Kafka | Extreme throughput, replay, retention | Per-partition | Event sourcing, stream processing, audit logs |
+| RabbitMQ | Flexible routing, per-message ack | Per-queue FIFO | Task queues, RPC, complex routing |
+| SQS | Zero ops, infinite scale, built-in DLQ | FIFO queues (limited) | Decoupling services, background jobs |
+
+## Queue Topologies
+
+- **Point-to-Point**: one queue, competing consumers. Each message consumed once.
+- **Fan-Out**: one message to multiple queues/groups. Use for event broadcasting.
+- **Topic-Based**: route by pattern matching. Use for selective subscription.
+
+## Consumer Patterns
+
+- **Competing Consumers**: multiple instances share workload, scale by adding consumers.
+- **Exclusive Consumer**: one active at a time, failover pattern for ordered processing.
+
+## TTL and Expiration
+- Queue-level TTL: all messages expire after N seconds if unconsumed.
+- Per-message TTL: individual expiration. Typical: notifications 5min, business 24h, audit 7d.
+- Expired messages route to DLQ or silently drop (configure explicitly).
+
+## Priority Queues
+- Limited levels (1-10 max, typically 3: high/normal/low).
+- Risk: starvation of low-priority. Mitigate with aging or separate queues.
+
+## Dead Letter Queue Design
+
+```
+message → consumer → FAIL → retry (3x exponential) → FAIL → DLQ → alert
+```
+
+- Retain original body, headers, error details, retry count.
+- Alert on first DLQ arrival. Never auto-replay without root-cause fix.
+- Replay tool moves DLQ → original queue in small monitored batches.
+
+## Partition Strategies
+- Partition key = entity ID ensures per-entity ordering.
+- Start with 2x expected consumer count as partition count.
+- Monitor for hot partitions (skewed key distribution).
+
+## Self-check before task completion
+
+- [ ] Is the right broker selected for throughput and routing needs?
+- [ ] Are DLQs configured with alerting for every consumer?
+- [ ] Is TTL set to prevent unbounded growth?
+- [ ] Are ordering guarantees maintained where business logic requires?
+- [ ] Is the consumer pattern correct (competing vs exclusive)?
+- [ ] Are queue depth and consumer lag monitored?
+- [ ] Is the DLQ replay workflow documented?

package/.mindforge/skills/rag-architecture/SKILL.md

@@ -0,0 +1,176 @@
+---
+name: rag-architecture
+version: 1.0.0
+min_mindforge_version: 0.1.0
+status: stable
+triggers: rag architecture, chunking strategy, embedding model selection, retrieval pipeline, dense retrieval, sparse retrieval, hybrid retrieval, re-ranking, context packing, semantic chunking, overlap strategy, retrieval evaluation
+---
+
+# Skill — RAG Architecture
+
+## When this skill activates
+Any task involving Retrieval-Augmented Generation pipeline design, document
+chunking, embedding model selection, retrieval strategies, re-ranking, or
+RAG evaluation metrics.
+
+## Mandatory actions when this skill is active
+
+### Before writing any code
+1. Define the corpus characteristics (document types, sizes, update frequency).
+2. Choose chunking strategy based on content structure.
+3. Select embedding model based on accuracy vs cost vs latency trade-offs.
+
+### During implementation
+- Implement hybrid retrieval (dense + sparse) with score fusion.
+- Add re-ranking stage for precision improvement.
+- Instrument retrieval metrics (latency, recall, relevance scores).
+
+### After implementation
+- Evaluate with ground-truth Q&A pairs (recall@k, MRR, answer correctness).
+- Document the RAG pipeline in ARCHITECTURE.md.
+- Set up monitoring for retrieval quality degradation.
+
+## Chunking Strategies
+
+### Fixed-Size Chunking
+- Split at token/character boundary (e.g., 512 tokens per chunk).
+- Add overlap between chunks (50-100 tokens) to preserve context at boundaries.
+- Simplest approach, works well for homogeneous content.
+- Trade-off: may split mid-sentence or mid-concept.
+
+### Semantic Chunking
+- Split on topic/meaning boundaries (not arbitrary positions).
+- Use embedding similarity: when similarity drops between sentences, split there.
+- Better for: heterogeneous documents, technical content.
+- More expensive to compute but produces coherent chunks.
+
+### Recursive/Hierarchical Chunking
+- Split by document structure: headers → paragraphs → sentences.
+- Respect document hierarchy (never split a heading from its content).
+- Best for: well-structured documents (markdown, HTML, documentation).
+- Preserves context and organizational meaning.
+
+### Chunking Parameters
+| Parameter | Recommended Range | Trade-off |
+|-----------|------------------|-----------|
+| Chunk size | 256-1024 tokens | Larger = more context, less precise retrieval |
+| Overlap | 10-20% of chunk size | More overlap = fewer boundary issues, more storage |
+| Min chunk size | 50 tokens | Avoid tiny fragments that lack meaning |
+
+## Embedding Models
+
+### Commercial Models
+| Model | Dimensions | Context | Best For |
+|-------|-----------|---------|----------|
+| OpenAI text-embedding-3-large | 3072 | 8191 tokens | Highest accuracy, general purpose |
+| OpenAI text-embedding-3-small | 1536 | 8191 tokens | Good accuracy, lower cost |
+| Cohere embed-v3 | 1024 | 512 tokens | Multilingual, search-optimized |
+
+### Open-Source Models
+| Model | Dimensions | Context | Best For |
+|-------|-----------|---------|----------|
+| bge-large-en-v1.5 | 1024 | 512 tokens | English, self-hosted |
+| e5-large-v2 | 1024 | 512 tokens | Instruction-tuned retrieval |
+| GTE-large | 1024 | 512 tokens | General text embeddings |
+
+### Selection Criteria
+- **Accuracy**: benchmark on your domain data (MTEB leaderboard as starting point).
+- **Cost**: per-token pricing for commercial, compute cost for self-hosted.
+- **Latency**: batch encoding speed matters for ingestion pipeline.
+- **Dimensions**: higher = more accurate but more storage and slower search.
+
+## Retrieval Strategies
+
+### Dense Retrieval (Vector Search)
+- Embed query → find nearest neighbors in vector space.
+- Good for: semantic similarity, paraphrase matching.
+- Weak for: exact keyword matching, rare terms, proper nouns.
+- Indexes: HNSW (fast, approximate), IVF (memory-efficient), flat (exact).
+
+### Sparse Retrieval (BM25/TF-IDF)
+- Term frequency-based scoring.
+- Good for: exact keyword matching, rare/specific terms, proper nouns.
+- Weak for: semantic similarity, paraphrases.
+- Fast, no GPU needed, works out-of-the-box.
+
+### Hybrid Retrieval (Recommended)
+- Run both dense and sparse retrieval.
+- Combine results using Reciprocal Rank Fusion (RRF):
+```
+RRF_score = sum(1 / (k + rank_i)) for each retrieval method
+k = 60 (standard constant)
+```
+- Gets best of both worlds: semantic understanding + keyword precision.
+
+## Re-Ranking
+
+### Cross-Encoder Re-Ranking
+- Take top-k results from retrieval (e.g., top 20-50).
+- Score each (query, document) pair with a cross-encoder model.
+- Re-order by cross-encoder score, return top-n (e.g., top 5).
+- Much more accurate than bi-encoder similarity, but slower.
+
+### Models for Re-Ranking
+- Cohere Rerank v3 (commercial, high quality).
+- bge-reranker-large (open-source, good quality).
+- ms-marco-MiniLM (lightweight, fast).
+
+### When to Re-Rank
+- Always (unless latency budget is extremely tight).
+- Especially valuable when initial retrieval returns many marginal results.
+- Cost: adds 50-200ms per query (for 20-50 candidates).
+
+## Context Packing
+
+### Strategies
+- Fill LLM context window efficiently with retrieved chunks.
+- Order by relevance (most relevant first).
+- Deduplicate overlapping chunks (remove redundant content).
+- Include source metadata (document title, section heading) for grounding.
+
+### Context Window Management
+```
+[System prompt] + [Retrieved chunks] + [User query] + [Generation buffer]
+     ~500 tokens    ~3000-6000 tokens    ~100 tokens     ~1000 tokens
+```
+
+### Diminishing Returns
+- More context is not always better.
+- After ~5-8 highly relevant chunks, quality often plateaus or degrades.
+- "Lost in the middle" effect: LLMs pay less attention to middle of context.
+- Place most relevant chunks at beginning and end.
+
+## Evaluation Metrics
+
+### Retrieval Quality
+| Metric | Description | Target |
+|--------|-------------|--------|
+| Recall@k | % of relevant docs in top-k results | > 0.85 at k=10 |
+| MRR (Mean Reciprocal Rank) | Average 1/rank of first relevant result | > 0.7 |
+| NDCG@k | Normalized discounted cumulative gain | > 0.75 |
+| Precision@k | % of top-k results that are relevant | > 0.5 at k=5 |
+
+### End-to-End Quality
+| Metric | Description | Target |
+|--------|-------------|--------|
+| Answer correctness | Does the answer match ground truth? | > 0.8 |
+| Faithfulness | Is the answer supported by retrieved context? | > 0.9 |
+| Relevance | Are retrieved documents relevant to query? | > 0.85 |
+
+### Evaluation Process
+1. Create ground-truth dataset: 50-200 Q&A pairs with source documents.
+2. Run queries through pipeline, measure retrieval metrics.
+3. Generate answers, measure end-to-end metrics.
+4. Iterate on chunking/retrieval/prompting based on results.
+
+## Self-check before task completion
+
+Before marking a task done when this skill was active:
+
+- [ ] Did I read the full SKILL.md before starting? (Not just the triggers)
+- [ ] Is chunking strategy appropriate for the content type?
+- [ ] Is hybrid retrieval implemented (dense + sparse)?
+- [ ] Is re-ranking applied to improve precision?
+- [ ] Is context packing efficient (deduplication, relevance ordering)?
+- [ ] Are evaluation metrics defined with ground-truth data?
+- [ ] Is retrieval quality monitored in production?

package/.mindforge/skills/rate-limiting-design/SKILL.md

@@ -0,0 +1,94 @@
+---
+name: rate-limiting-design
+version: 1.0.0
+min_mindforge_version: 10.0.9
+status: stable
+triggers: rate limiting design, token bucket algorithm, leaky bucket, sliding window counter, distributed rate limit, per-tenant quota, rate limit header, throttling strategy, quota management, burst allowance, rate limit bypass, adaptive rate limit
+compose: api-gateway-patterns
+---
+
+# Skill — Rate Limiting Design
+
+## When this skill activates
+Any task involving rate limiting, algorithm selection, distributed rate limits,
+per-tenant quotas, throttling, burst allowance, or adaptive limiting.
+
+## Mandatory actions when this skill is active
+
+### Before writing any code
+1. Define limits per endpoint based on expected usage and resource cost.
+2. Choose algorithm for traffic pattern (bursty vs smooth).
+3. Determine scope (per-user, per-API-key, per-IP, per-tenant).
+
+### During implementation
+- Return standard rate limit headers on every response.
+- Implement distributed limiting if multi-instance (Redis + Lua).
+- Configure per-plan tier limits (free/pro/enterprise).
+- Add bypass for internal services and health checks.
+
+### After implementation
+- Test under burst and sustained high load.
+- Verify distributed consistency (same user, different instances).
+- Document limits in API docs with examples.
+
+## Algorithm Selection
+
+| Algorithm | Behavior | Best For |
+|-----------|----------|----------|
+| Token Bucket | Allows bursts up to bucket size, smooth sustained rate | Most APIs (general purpose) |
+| Leaky Bucket | Perfectly smooth output, no bursts | Outgoing rate limiting, pipelines |
+| Sliding Window | Accurate counting, no boundary spikes | Precise per-minute/hour limits |
+| Fixed Window | Simple INCR+EXPIRE, boundary spike risk | Simple cases, acceptable edge spikes |
+
+## Distributed Implementation (Redis Lua)
+- Atomic token bucket via Lua script (read + compute + write in one round-trip).
+- Key format: `{user:123}:ratelimit` (hash tags for Redis Cluster slot).
+- Fail-open if Redis unreachable (prefer availability) or fail-closed (prefer safety).
+
+## Per-Tenant Quotas
+
+```
+Plan        Req/min   Req/day     Burst
+Free        60        10,000      10
+Pro         600       100,000     100
+Enterprise  6,000     1,000,000   1,000
+```
+
+- Store plan in cache. Key includes tenant: `ratelimit:{tenant}:{endpoint}`.
+- Separate limits per endpoint if resource cost varies.
+
+## Response Headers
+
+```
+X-RateLimit-Limit: 100
+X-RateLimit-Remaining: 73
+X-RateLimit-Reset: 1704067260   (Unix timestamp)
+```
+
+429 response must include: `Retry-After` header, error message, and remaining=0.
+
+## Adaptive Rate Limiting
+- Normal (<60% load): relax limits 1.2x. High (80-90%): tighten to 0.5x.
+- Emergency (>90%): tighten to 0.2x. Gradual steps over 30-60s (avoid thundering herd).
+- Always return `Retry-After` so clients back off gracefully.
+
+## Bypass Rules
+- Exempt: health checks, internal mTLS calls, admin endpoints, webhook receivers.
+- Bypass requires authentication. Log bypassed requests for audit.
+- Decision happens BEFORE rate limit check (zero overhead path).
+
+## Scope
+
+- **Per-User**: by user ID or API key. Most common for SaaS.
+- **Per-IP**: for unauthenticated (login, public). Risk: shared NAT IPs.
+- **Per-Endpoint**: expensive ops (search, export) get lower limits.
+
+## Self-check before task completion
+
+- [ ] Is the algorithm appropriate for the traffic pattern?
+- [ ] Are rate limit headers returned on every response?
+- [ ] Is the implementation distributed-safe (no race conditions)?
+- [ ] Are per-tenant quotas configured with tier differentiation?
+- [ ] Is 429 response informative (Retry-After, error details)?
+- [ ] Are bypass rules defined for health checks and internal services?
+- [ ] Is adaptive limiting considered for overload protection?

package/.mindforge/skills/react-native-patterns/SKILL.md

@@ -0,0 +1,42 @@
+---
+name: react-native-patterns
+version: 1.0.0
+min_mindforge_version: 10.4.0
+status: stable
+triggers: react native architecture, react native navigation, native module bridge, react native performance, Hermes engine optimization, react native debugging, new architecture react native, JSI bridge, react native state management, turbo modules, fabric renderer, react native app design
+---
+
+# Skill — React Native Architecture Patterns
+
+## When this skill activates
+This skill activates when designing or implementing React Native applications, including navigation architecture, native module bridges, performance optimization with Hermes, or adopting the new architecture (Fabric/TurboModules).
+
+## Mandatory actions when this skill is active
+
+### Before writing any code
+1. Verify Hermes engine is enabled in `android/app/build.gradle` and iOS build settings for optimal performance
+2. Determine if new architecture (Fabric + TurboModules) should be enabled based on library compatibility
+3. Establish navigation strategy (React Navigation vs native navigation) and state management approach (Context, Redux, Zustand, Jotai)
+4. Review native module requirements and platform-specific functionality needs
+
+### During implementation
+- Use `React.memo()` and `useMemo`/`useCallback` strategically to prevent unnecessary re-renders in lists and heavy components
+- Implement FlatList with `getItemLayout`, `removeClippedSubviews`, and proper `keyExtractor` for large datasets
+- Keep JavaScript bridge crossings minimal — batch updates and avoid rapid state changes from native side
+- Use JSI-based libraries (Reanimated 2+, react-native-mmkv) for performance-critical operations
+- Follow platform-specific design patterns (Material Design for Android, Human Interface Guidelines for iOS)
+- Leverage TurboModules for new native module implementations when new architecture is enabled
+- Implement proper error boundaries and crash reporting (Sentry, Bugsnag) with sourcemap upload
+
+### After implementation
+- Profile with React DevTools Profiler and Flipper to identify performance bottlenecks
+- Test on physical devices (not just simulators) across both platforms and multiple OS versions
+- Verify memory leaks using Xcode Instruments and Android Studio Profiler
+- Measure app startup time and optimize bundle size with bundle analyzer
+
+## Self-check before task completion
+- [ ] Navigation flows work correctly on both platforms with proper back button handling
+- [ ] No performance warnings in Metro bundler or runtime (e.g., non-serializable values in navigation params)
+- [ ] Native modules include proper error handling and type safety (TypeScript + Codegen if using new arch)
+- [ ] Platform-specific code uses proper conditionals (`Platform.select`, `.ios.js`/`.android.js` files)
+- [ ] Frame rate maintains 60fps during animations and list scrolling (use Perf Monitor)