@wazir-dev/cli 1.0.0

package/expertise/performance/foundations/index.md

@@ -0,0 +1,24 @@
+# Directory Purpose
+
+The `foundations` performance directory establishes the theoretical and practical basics of writing efficient code and measuring system speed.
+
+# Key Concepts
+
+- Identifying computational complexity
+- Implementing caching correctly
+- Setting limits and tracking regressions
+
+# File Map
+
+- `algorithmic-complexity.md` — Big O notation and choosing the right data structures
+- `caching-strategies.md` — read-through, write-behind, and cache invalidation
+- `concurrency-and-parallelism.md` — threads, async, locks, and race conditions
+- `measuring-and-profiling.md` — flame graphs, tracing, and identifying bottlenecks
+- `memory-management.md` — garbage collection, memory leaks, and object pools
+- `performance-budgets.md` — setting CI/CD limits on bundle sizes and latency
+
+# Reading Guide
+
+If code is generally inefficient → read `algorithmic-complexity.md`
+If experiencing OOM errors → read `memory-management.md`
+If unsure where the app is slow → read `measuring-and-profiling.md`

package/expertise/performance/foundations/measuring-and-profiling.md

@@ -0,0 +1,440 @@
+# Measuring & Profiling — Performance Expertise Module
+
+> You cannot optimize what you cannot measure. Profiling is the foundation of all performance work — it separates data-driven optimization from superstition. Every performance improvement must start with measurement and end with verification.
+
+> **Impact:** Critical
+> **Applies to:** All (Web, Mobile, Backend, Infrastructure)
+> **Key metrics:** Response Time (p50/p95/p99), Throughput (RPS), CPU/Memory utilization, Frame Rate
+
+---
+
+## Why This Matters
+
+Performance work without measurement is guesswork. Teams routinely waste weeks optimizing the wrong bottleneck because they relied on intuition instead of profiling data.
+
+**Knight Capital: $440M in 45 Minutes.** On August 1, 2012, Knight Capital deployed a routine update to the NYSE's Retail Liquidity Program. A dormant router function from 2005 was accidentally re-activated, sending over 4 million orders to fill just 212 customer orders. The $440 million loss was 3x the company's annual earnings; Knight's stock lost 75% of its value in two days. A proper load test simulating real market conditions would have exposed the runaway order generation immediately.
+
+**Common measurement failures:**
+1. **Optimizing the wrong layer.** A team spends 3 weeks on database queries; the actual bottleneck is a synchronous HTTP call adding 800ms per request. Profiling would have found it in 15 minutes.
+2. **Averaging away the problem.** Average response time is 120ms, but p99 is 4,200ms — 1% of users (thousands per hour at scale) experience 35x worse performance.
+3. **Premature optimization.** Code that runs 0.001% of the time does not warrant optimization. Profile first — the actual bottleneck is elsewhere 70-90% of the time.
+
+**Business case:** Google found 500ms of added load time reduced traffic by 20%. Amazon reported every 100ms of latency cost 1% in sales. At Meta-scale, regressions of 0.005-0.01% in CPU waste thousands of servers (FBDetect, SOSP 2024).
+
+---
+
+## Performance Budgets & Targets
+
+### Latency Percentiles
+
+| Percentile | Meaning | Why It Matters |
+|-----------|---------|----------------|
+| p50 | 50% of requests faster | General baseline |
+| p95 | 95% of requests faster | Standard SLO target |
+| p99 | 99% of requests faster | Reveals tail latency; systemic bottlenecks surface here |
+| p99.9 | 99.9% of requests faster | Critical for high-throughput services |
+
+**Why p99 > average:** Mean latency can look stable while p99 spikes from GC pauses, cache evictions, or lock contention. At 10,000 RPM, a 4s p99 means 100 users/minute get unacceptable latency.
+
+### Apdex Scores
+
+Formula: `Apdex = (Satisfied + Tolerating/2) / Total` where Satisfied <= T, Tolerating <= 4T. Scores: 0.94-1.00 excellent, 0.85-0.93 good, 0.70-0.84 fair, < 0.70 poor.
+
+### Platform-Specific Budgets
+
+**Web (Core Web Vitals — INP replaced FID in March 2024):**
+
+| Metric | Good | Needs Improvement | Poor |
+|--------|------|--------------------|------|
+| LCP | <= 2.5s | 2.5-4.0s | > 4.0s |
+| INP | <= 200ms | 200-500ms | > 500ms |
+| CLS | <= 0.1 | 0.1-0.25 | > 0.25 |
+
+2025 Web Almanac: only 48% of mobile pages pass all three CWVs. LCP is hardest (62% pass), then INP (77%), then CLS (81%).
+
+**Backend API:** p50 < 50ms (good), p95 < 200ms, p99 < 500ms, error rate < 0.1%.
+**Mobile:** Cold start < 1s, frame rate 60fps (16.7ms/frame), jank frames < 1%.
+**Database:** Query p95 < 10ms, cache hit rate > 95%, connection pool utilization < 60%.
+
+---
+
+## Measurement & Profiling
+
+### Frontend Profiling
+
+#### Chrome DevTools Performance Panel
+
+1. Open DevTools > **Performance** tab
+2. Enable **CPU throttling** (4x-6x) — mobile CPUs are far weaker than dev machines
+3. Record (Cmd+Shift+E for reload profile), interact, stop
+4. **Flame chart:** x-axis = time (wider = longer), y-axis = call stack. Yellow = JS, Purple = layout, Green = paint. Red triangles mark Long Tasks (> 50ms)
+5. **Call Tree tab:** top-down view of root activities. **Bottom-Up tab:** find where time is directly spent
+6. Chrome 124+: right-click functions to **Hide function/children** and focus on actionable entries
+
+```javascript
+// Custom Performance API marks (appear in the Timings track)
+performance.mark('render-start');
+renderComponent();
+performance.mark('render-end');
+performance.measure('Component Render', 'render-start', 'render-end');
+
+// Production measurement with PerformanceObserver
+const observer = new PerformanceObserver((list) => {
+  for (const entry of list.getEntries()) {
+    navigator.sendBeacon('/analytics', JSON.stringify({
+      metric: entry.name, value: entry.duration, timestamp: Date.now()
+    }));
+  }
+});
+observer.observe({ entryTypes: ['measure', 'largest-contentful-paint', 'event'] });
+```
+
+#### Lighthouse: Lab vs. Field Data
+
+- **Lab** (Lighthouse): Fixed device/network, CPU throttled 4x, reproducible. Use in development and CI/CD.
+- **Field** (CrUX): Real Chrome users, rolling 28-day window, reported at 75th percentile. Reflects actual conditions.
+- **A perfect Lighthouse 100 does not guarantee passing CWVs.** CWVs are exclusively field data. Use Lighthouse for relative comparisons; CrUX/RUM for real impact.
+
+#### Core Web Vitals in Production
+
+```javascript
+import { onLCP, onINP, onCLS } from 'web-vitals';
+function send(metric) {
+  navigator.sendBeacon('/api/vitals', JSON.stringify({
+    name: metric.name, value: metric.value, rating: metric.rating, id: metric.id
+  }));
+}
+onLCP(send); onINP(send); onCLS(send);
+```
+
+### Backend Profiling
+
+#### Node.js
+
+```bash
+# V8 built-in profiler
+node --prof app.js && node --prof-process isolate-0x*.log > profile.txt
+
+# clinic.js — production-grade suite
+clinic doctor -- node app.js    # Event loop delays, I/O issues, GC overhead
+clinic flame -- node app.js     # Interactive flame graph
+
+# 0x — instant flame graphs
+npx 0x app.js                   # Opens interactive flamegraph in browser
+```
+
+#### Python
+
+```bash
+# py-spy: zero code changes, <5% overhead, production-safe
+py-spy top --pid 12345                              # Live top-like view
+py-spy record -o profile.svg --pid 12345 --duration 30  # Flame graph SVG
+
+# Scalene: CPU + memory + GPU (separates Python vs C time, ~50% fewer false positives)
+scalene your_script.py
+```
+
+**cProfile** adds 30-50% overhead (deterministic tracing). Use only in development.
+
+#### How to Read Flame Graphs
+
+Invented by Brendan Gregg. **Width** = proportion of samples (not time order) — wider = more CPU. **Y-axis** = call stack depth — bottom is entry, top is leaf. **Look for plateaus** — wide flat bars at top are hotspots. Color is random (for contrast only). **Inverted flame graphs** (icicle charts) flip Y-axis to find which callers contribute to a hot leaf.
+
+#### Distributed Tracing
+
+For microservices, use OpenTelemetry (vendor-neutral) with Jaeger/Zipkin/Datadog as backends.
+
+**Overhead:** Up to 15% on response times in Java; exporting is the main contributor. **Sampling is essential:**
+- **Head sampling** (at agent): Decide at request start. 0.1-1% typical rate. Simple, low overhead.
+- **Tail sampling** (at collector): Keep only errors/slow requests. Higher value but more overhead.
+- CPU overhead drops from 17.8% to 3.6% as fewer traces are sampled. Tracing reduces MTTR by up to 70%.
+
+### Mobile Profiling
+
+**Android:** Android Studio Profiler (CPU, Memory, Energy). Use "Sample Java/Kotlin Methods" (~5% overhead) not "Trace" (20-50%). Perfetto for system-level analysis.
+
+**iOS:** Xcode Instruments — Time Profiler (CPU sampling, 1ms intervals), Allocations (memory leaks), Core Animation (GPU frame rate). Use "Invert Call Tree" + "Hide System Libraries" to find hotspots.
+
+**Flutter:** `showPerformanceOverlay: true` in MaterialApp. Both UI and GPU thread bars must stay below 16ms (60fps).
+
+```kotlin
+// Android custom trace sections
+android.os.Trace.beginSection("processData")
+try { /* work */ } finally { android.os.Trace.endSection() }
+```
+
+```swift
+// iOS signposts for Instruments
+let log = OSLog(subsystem: "com.app", category: "Perf")
+os_signpost(.begin, log: log, name: "LoadDashboard")
+// ... work ...
+os_signpost(.end, log: log, name: "LoadDashboard")
+```
+
+### Database Profiling
+
+```sql
+-- EXPLAIN ANALYZE (wrap in transaction for UPDATE/DELETE)
+BEGIN;
+EXPLAIN (ANALYZE, BUFFERS) SELECT o.id, c.name FROM orders o
+  JOIN customers c ON c.id = o.customer_id
+  WHERE o.created_at > NOW() - INTERVAL '7 days';
+ROLLBACK;
+-- Look for: Seq Scan on large tables, actual vs planned row mismatch (>10x = stale stats),
+-- shared_blks_read (cache misses = disk I/O), Nested Loop with high rows (N+1)
+
+-- pg_stat_statements: top queries by total impact
+SELECT calls, round(total_exec_time::numeric, 2) AS total_ms,
+  round(mean_exec_time::numeric, 2) AS avg_ms, query
+FROM pg_stat_statements ORDER BY total_exec_time DESC LIMIT 10;
+-- Sort by total_exec_time, not mean. 5ms * 100K calls/hr > 2s * 10 calls/hr.
+```
+
+### RUM vs. Synthetic Monitoring
+
+| Dimension | Synthetic | RUM |
+|-----------|----------|-----|
+| Data source | Scripted agents, emulated devices | Actual user sessions |
+| When it works | 24/7, even with zero users | Only when users are active |
+| Best for | Regression detection, SLA, CI/CD gates | Real impact, business correlation |
+
+**Best practice:** Synthetics to block regressions before release; RUM to validate real-world impact after deployment.
+
+---
+
+## Common Bottlenecks
+
+10 measurement mistakes that lead to wrong conclusions:
+
+1. **Averages instead of percentiles** — p99 of 4.2s hides behind a 120ms average
+2. **Measuring in dev, not prod** — dev has 10-100x more CPU, 1ms network latency, warm caches
+3. **Observer effect** — deterministic profilers add 30-50% overhead; use sampling profilers (<5%) in production
+4. **Battery vs. plugged in** — laptops throttle CPU 20-60% on battery
+5. **Browser extensions active** — ad blockers and DevTools inject JS that distorts results
+6. **Ignoring GC pauses** — Java 10-200ms, Node.js 5-50ms, Go <1ms; invisible in averages
+7. **Cold cache only** — real users have mixed cache states; test both First View and Repeat View
+8. **Single-run benchmarks** — run 10+ times, report median with confidence intervals
+9. **Ignoring JIT warm-up** — first 100-1000 invocations are 2-10x slower; discard warm-up iterations
+10. **Wall-clock time only** — 500ms wall / 50ms CPU = I/O-bound, not CPU-bound
+
+---
+
+## Anti-Patterns
+
+1. **`console.log` timestamps** — variable overhead (0.1-5ms/call). Use `performance.now()` (microsecond precision).
+2. **Gut-feeling optimization** — the actual bottleneck is elsewhere 70-90% of the time. Profile first.
+3. **Micro-benchmarking without context** — `Map` 15% faster than `Object` is meaningless if lookups are 0.01% of request time.
+4. **Benchmarking in a debugger** — disables JIT, adds breakpoint overhead; 50ms in debugger may be 2ms in production.
+5. **Cross-machine benchmark comparison** — benchmark on target deployment hardware or identical instance types.
+6. **`Date.now()` for sub-ms timing** — millisecond resolution, affected by clock adjustments. Use `performance.now()` or `process.hrtime.bigint()`.
+7. **Flame graphs without source maps** — minified names (`a`, `t`, `n`) are unreadable. Enable source maps.
+8. **Lighthouse score as absolute truth** — simulated device; use for relative comparisons only.
+9. **Over-instrumenting production** — 91% of orgs actively reduce observability spend. Instrument critical paths; sample the rest.
+10. **Not resetting state between runs** — caches, JIT state, connection pools from prior runs contaminate results.
+
+---
+
+## Architecture-Level Decisions
+
+### Observability Architecture
+
+| Layer | What to measure | Overhead budget |
+|-------|----------------|-----------------|
+| Edge/CDN | Cache hit rate, TTFB | Near zero (built-in) |
+| Application | Latency percentiles, error rate | 1-5% CPU |
+| Database | Query time, cache hit rate | < 1% CPU |
+| Infrastructure | CPU, memory, disk I/O | < 0.5% CPU |
+
+**Sampling strategies:**
+
+| Strategy | Rate | Overhead | Use Case |
+|----------|------|----------|----------|
+| No sampling | 100% | 15-20% CPU | Low-traffic (< 100 RPS) |
+| Fixed head sampling | 1-10% | 3-5% CPU | Medium traffic |
+| Probabilistic head | 0.1-1% | 1-2% CPU | High traffic (> 10K RPS) |
+| Tail sampling | Varies | 5-10% at collector | Error/latency investigation |
+
+**Cost rule of thumb:** Keep total observability overhead below 5% of application CPU and 3% of infrastructure cost. Grafana 2024 Survey: 91% of organizations actively reduce observability spend.
+
+---
+
+## Testing & Regression Prevention
+
+### Statistical Regression Detection
+
+- Use **Wilcoxon rank-sum test** (non-parametric) at 5% significance level
+- Supplement with **Cliff's Delta** effect size: small (< 0.33), medium (0.33-0.47), large (> 0.47)
+- Run benchmarks **10+ times** (30+ preferred) for reliable distributions
+- A regression requires BOTH statistical significance (p < 0.05) AND meaningful effect size (Cliff's Delta > 0.33)
+
+Application benchmarks reliably detect meaningful regressions; microbenchmarks tend toward false positives.
+
+```yaml
+# Lighthouse CI performance gate (.lighthouserc.json)
+{ "ci": { "collect": { "numberOfRuns": 5, "url": ["http://localhost:3000/"] },
+  "assert": { "assertions": {
+    "categories:performance": ["error", { "minScore": 0.85 }],
+    "largest-contentful-paint": ["error", { "maxNumericValue": 2500 }],
+    "cumulative-layout-shift": ["error", { "maxNumericValue": 0.1 }]
+}}}}
+```
+
+### Reducing Benchmark Noise
+
+1. **Dedicated runners** — shared CI has unpredictable CPU contention
+2. **CPU pinning** — `taskset -c 0-3 node benchmark.js`
+3. **Disable frequency scaling** — `cpupower frequency-set --governor performance`
+4. **Relative comparisons** — % change is more stable than absolute values across hardware
+5. **Discard outliers** — remove top/bottom 5% before comparing
+
+---
+
+## Decision Trees
+
+### "My App is Slow" Diagnostic
+
+```
+Is it slow for ALL users or SOME?
+  SOME → Check RUM: specific region (CDN), device, or browser?
+  ALL → Continue
+
+Slow on FIRST load or SUBSEQUENT?
+  FIRST → Caching, code splitting, asset optimization
+  SUBSEQUENT → Memory leak, state accumulation, connection pool exhaustion
+
+Where is time spent? (waterfall / flame graph)
+  NETWORK (TTFB > 600ms)?
+    → DNS (prefetch) / TLS (session resumption) / Server (see Backend) / Download (CDN, compression)
+  BACKEND (> 200ms)?
+    CPU-bound (CPU > 80%)? → Flame graph → optimize hot functions
+    I/O-bound (CPU < 30%)? → DB queries (EXPLAIN) / External APIs (cache, circuit breaker)
+    Memory-bound? → Heap profiling → reduce allocation rate
+  FRONTEND (rendering > 100ms)?
+    JS Long Tasks (> 50ms)? → Code splitting, Web Workers
+    Layout/Reflow (purple)? → Batch DOM reads/writes
+    Paint (green)? → contain, will-change, composite layers
+```
+
+### Which Profiling Tool?
+
+| Platform | Quick Check | Deep Analysis | Production-Safe | CI/CD |
+|----------|-------------|---------------|-----------------|-------|
+| Web | Lighthouse | DevTools Perf | RUM (Datadog, Sentry) | Lighthouse CI |
+| Node.js | `npx 0x` | clinic.js | `node --prof` | autocannon |
+| Python | cProfile | Scalene | py-spy | pytest-benchmark |
+| Android | Studio Profiler | Perfetto | Firebase Perf | Macrobenchmark |
+| iOS | Time Profiler | Instruments | MetricKit | XCTest Perf |
+| PostgreSQL | EXPLAIN ANALYZE | pg_stat_statements | auto_explain | pgbench |
+
+---
+
+## Code Examples
+
+### N+1 Query Fix (Before/After with Measurements)
+
+```python
+# BEFORE: 502 queries, mean response 1,847ms
+def get_orders_slow(user_id):
+    orders = db.execute("SELECT * FROM orders WHERE user_id = %s", (user_id,))
+    for order in orders:
+        order['items'] = db.execute(
+            "SELECT * FROM order_items WHERE order_id = %s", (order['id'],))
+    return orders  # 1 + N queries
+
+# AFTER: 1 query, mean response 23ms (80x faster)
+def get_orders_fast(user_id):
+    rows = db.execute("""
+        SELECT o.*, oi.product_id, oi.quantity, oi.price
+        FROM orders o LEFT JOIN order_items oi ON oi.order_id = o.id
+        WHERE o.user_id = %s ORDER BY o.id""", (user_id,))
+    orders = {}
+    for row in rows:
+        orders.setdefault(row['id'], {**row, 'items': []})['items'].append(
+            {k: row[k] for k in ('product_id', 'quantity', 'price')})
+    return list(orders.values())  # 1 query total
+```
+
+### Load Test with SLO Thresholds (k6)
+
+```javascript
+import http from 'k6/http';
+import { check } from 'k6';
+export const options = {
+  stages: [
+    { duration: '2m', target: 50 }, { duration: '5m', target: 200 },
+    { duration: '3m', target: 200 }, { duration: '2m', target: 0 },
+  ],
+  thresholds: {
+    http_req_duration: ['p(50)<200', 'p(95)<500', 'p(99)<1000'],
+    http_req_failed: ['rate<0.01'],
+  },
+};
+export default function () {
+  check(http.get('https://app.example.com/api/products'),
+    { 'status 200': (r) => r.status === 200 });
+}
+```
+
+### React Render Profiling
+
+```jsx
+import { Profiler, memo, useMemo } from 'react';
+
+// Before: 45ms/render. After (memoized): 3ms/render
+const ProductList = memo(({ products, filters }) => {
+  const filtered = useMemo(
+    () => products.filter(p => matchesFilters(p, filters)), [products, filters]);
+  return filtered.map(p => <MemoizedCard key={p.id} product={p} />);
+});
+
+function onRender(id, phase, actualDuration) {
+  if (actualDuration > 16) // Exceeds 60fps budget
+    sendMetric('slow_render', { component: id, duration: actualDuration });
+}
+<Profiler id="ProductList" onRender={onRender}><ProductList {...props} /></Profiler>
+```
+
+### Proper Benchmarking with JIT Warm-up
+
+```javascript
+function benchmark(fn, iterations = 10000) {
+  for (let i = 0; i < 1000; i++) fn();  // Warm-up: let JIT compile
+  const start = performance.now();       // NOT Date.now()
+  for (let i = 0; i < iterations; i++) fn();
+  return (performance.now() - start) / iterations;  // ms per iteration
+}
+```
+
+---
+
+## Quick Reference
+
+| Metric | Good | Acceptable | Needs Work |
+|--------|------|------------|------------|
+| LCP | < 2.5s | 2.5-4.0s | > 4.0s |
+| INP | < 200ms | 200-500ms | > 500ms |
+| CLS | < 0.1 | 0.1-0.25 | > 0.25 |
+| TTFB | < 200ms | 200-600ms | > 600ms |
+| API p50 | < 50ms | 50-200ms | > 200ms |
+| API p95 | < 200ms | 200-500ms | > 500ms |
+| API p99 | < 500ms | 500ms-1s | > 1s |
+| Error rate | < 0.1% | 0.1-1% | > 1% |
+| Mobile FPS | 60 fps | 45-59 fps | < 45 fps |
+| Cold start | < 1s | 1-2s | > 2s |
+| DB query p95 | < 10ms | 10-100ms | > 100ms |
+| Cache hit rate | > 95% | 85-95% | < 85% |
+| Apdex | > 0.94 | 0.85-0.93 | < 0.85 |
+
+### Overhead Budget
+
+| Instrumentation | Typical | Max Acceptable |
+|----------------|---------|----------------|
+| Metrics (counters) | < 0.1% CPU | 0.5% |
+| Structured logging | 0.1-1% | 2% |
+| Distributed tracing (sampled) | 1-5% | 5% |
+| Continuous profiling | 2-5% | 5% |
+| Full tracing (100%) | 10-20% | Low traffic only |
+
+---
+
+*Researched: 2026-03-08 | Sources: [Chrome DevTools Performance](https://developer.chrome.com/docs/devtools/performance), [Chrome Flame Graphs Guide](https://medium.com/slalom-blog/flame-graphs-in-chrome-devtools-a-guide-for-front-end-developers-b9503ff4a4d), [MDN RUM vs Synthetic](https://developer.mozilla.org/en-US/docs/Web/Performance/Guides/Rum-vs-Synthetic), [DebugBear Synthetic vs RUM](https://www.debugbear.com/blog/synthetic-vs-rum), [Brendan Gregg Flame Graphs](https://www.brendangregg.com/flamegraphs.html), [Profiling in Production](https://www.caduh.com/blog/profiling-in-production), [Clinic.js](https://medium.com/@connect.hashblock/profiling-node-js-in-production-with-flamegraphs-clinic-js-9125e236d770), [Python Profiling](https://roman.pt/posts/python-performance-profiling/), [Scalene & py-spy 2025](https://johal.in/profiling-scalene-py-spy-memory-cpu-flamegraphs-2025/), [Core Web Vitals 2026](https://www.corewebvitals.io/core-web-vitals), [CWV Thresholds](https://web.dev/articles/defining-core-web-vitals-thresholds), [Knight Capital](https://www.henricodolfing.com/2019/06/project-failure-case-study-knight-capital.html), [P99 Latency](https://www.baeldung.com/cs/whats-the-p99-latency), [Apdex Score](https://coralogix.com/docs/user-guides/apm/features/apdex-score/), [pg_stat_statements](https://www.tigerdata.com/blog/using-pg-stat-statements-to-optimize-queries), [EXPLAIN ANALYZE](https://www.enterprisedb.com/blog/postgresql-query-optimization-performance-tuning-with-explain-analyze), [Lab vs Field Data](https://web.dev/articles/lab-and-field-data-differences), [FBDetect SOSP 2024](https://tangchq74.github.io/FBDetect-SOSP24.pdf), [Grafana Observability Survey 2024](https://grafana.com/observability-survey/2024/), [Tracing Overhead](https://atlarge-research.com/pdfs/2024-msc-anders_tracing_overhead.pdf), [Perfetto](https://perfetto.dev/), [BrowserStack iOS Tools](https://www.browserstack.com/guide/ios-app-performance-testing-tools), [Sentry Profiling](https://sentry.io/product/profiling/), [Performance Regression CI/CD](https://www.in-com.com/blog/performance-regression-testing-in-ci-cd-pipelines-a-strategic-framework/)*