mindforge-cc 10.0.3 → 11.0.0

package/.mindforge/skills/build-vs-buy/SKILL.md

@@ -0,0 +1,80 @@
+---
+name: build-vs-buy
+version: 1.0.0
+min_mindforge_version: 10.1.0
+status: stable
+triggers: build vs buy, make or buy, vendor evaluation, total cost ownership, buy decision, vendor lock-in assessment, outsource vs build, third-party evaluation, SaaS vs self-hosted, dependency vs custom, commercial vs open-source, build internally
+---
+
+# Build vs Buy Decision Framework
+
+## When this skill activates
+
+This skill activates when the team faces a decision about whether to build a capability
+internally or acquire it from an external vendor, open-source project, or SaaS provider.
+It provides a structured framework for evaluating total cost of ownership, strategic
+alignment, and long-term maintainability of both paths.
+
+## Mandatory actions when this skill is active
+
+### Before
+
+1. **Identify the capability boundary** — Define exactly what the system needs to do.
+   Separate the core problem from adjacent concerns.
+2. **Gather constraints** — Timeline pressure, team capacity, budget ceiling, compliance
+   requirements, and existing technology stack compatibility.
+3. **Catalog candidates** — List all viable buy options (commercial SaaS, open-source
+   libraries, managed services) alongside the build option.
+
+### During
+
+4. **Calculate Total Cost of Ownership (TCO) for BUY path:**
+   - License/subscription fees (year 1 + projected 3-year)
+   - Integration effort (API adapters, data transformation, auth hookup)
+   - Ongoing maintenance (version upgrades, breaking changes, support tickets)
+   - Opportunity cost of vendor limitations (features you cannot customize)
+   - Exit cost (data migration, API decoupling, replacement timeline)
+
+5. **Calculate Total Cost of Ownership (TCO) for BUILD path:**
+   - Initial development effort (design + implementation + testing)
+   - Ongoing maintenance (bug fixes, feature requests, security patches)
+   - Ownership benefit (full control, no per-seat pricing, no vendor roadmap dependency)
+   - Knowledge investment (team learns the domain deeply)
+
+6. **Assess vendor lock-in risk:**
+   - Data portability — Can you export all data in standard formats?
+   - API coupling — How deeply does the vendor API penetrate your codebase?
+   - Exit cost — What is the realistic effort to replace this vendor?
+   - Contractual traps — Auto-renewal, price escalation clauses, minimum commitments.
+
+7. **Apply the decision matrix:**
+   - Strategic importance HIGH + Competitive advantage = **BUILD**
+   - Strategic importance LOW + Commodity capability = **BUY**
+   - Timeline pressure HIGH + Team capacity LOW = **BUY** (short-term), plan migration
+   - Timeline pressure LOW + Team capacity HIGH = **BUILD**
+   - Differentiating capability = **BUILD** (never outsource your moat)
+   - Undifferentiated heavy lifting = **BUY**
+
+8. **Evaluate team capacity:**
+   - Does the team have domain expertise to build and maintain this?
+   - Will building this distract from higher-priority work?
+   - Is there a realistic staffing plan for long-term ownership?
+
+### After
+
+9. **Document the decision** — Record the rationale, TCO comparison, and risk assessment
+   as an Architecture Decision Record (ADR).
+10. **Define review triggers** — Set conditions that would cause re-evaluation (e.g.,
+    vendor price increase >30%, team growth enabling build, vendor acquisition).
+11. **Plan the exit path** — Even when buying, design integration layers that allow
+    future replacement without full rewrite.
+
+## Self-check before task completion
+
+- [ ] TCO calculated for both paths with 3-year projection
+- [ ] Vendor lock-in risk explicitly assessed with exit cost estimate
+- [ ] Decision matrix applied with clear justification
+- [ ] Team capacity and opportunity cost considered
+- [ ] ADR written with rationale and review triggers
+- [ ] Integration designed with abstraction layer regardless of buy/build choice
+- [ ] Stakeholders informed of trade-offs, not just the recommendation

package/.mindforge/skills/bundle-optimization/SKILL.md

@@ -0,0 +1,174 @@
+---
+name: bundle-optimization
+version: 1.0.0
+min_mindforge_version: 0.3.0
+status: stable
+triggers: bundle optimization, tree shaking, code splitting strategy, dynamic import, chunk naming, preload hint, prefetch strategy, bundle analyzer, unused code elimination, lazy module, vendor splitting, entry point optimization
+compose: performance
+---
+
+# Skill — Bundle Optimization
+
+## When this skill activates
+Any task involving JavaScript/TypeScript bundle size reduction, tree shaking,
+code splitting, lazy loading, or front-end performance budgets.
+
+## Mandatory actions when this skill is active
+
+### Before optimizing
+1. Run bundle analyzer to identify what is currently large.
+2. Set a performance budget (target numbers, not "make it smaller").
+3. Measure current metrics: total bundle size, initial load size, LCP impact.
+
+### Performance budgets
+
+| Metric | Target |
+|--------|--------|
+| Main bundle (gzipped) | < 100KB |
+| Total initial JS (gzipped) | < 300KB |
+| Largest single chunk | < 150KB |
+| Time to Interactive (3G) | < 5s |
+
+### Tree shaking
+
+**Requirements for tree shaking to work:**
+- Use ESM (import/export), not CommonJS (require/module.exports).
+- Mark packages as side-effect-free: `"sideEffects": false` in package.json.
+- Avoid re-exporting everything via barrel files (index.ts with `export * from`).
+- Import specific functions: `import { debounce } from 'lodash-es'` not `import _ from 'lodash'`.
+
+**Common tree-shaking failures:**
+- CommonJS modules (cannot be statically analyzed).
+- Barrel files that import everything regardless of usage.
+- Side effects in module top-level scope (global CSS imports, polyfills).
+- Dynamic property access: `lib[method]()` prevents dead code elimination.
+
+**Fix barrel file problem:**
+```javascript
+// BAD: barrel imports everything
+import { Button } from '@/components';
+
+// GOOD: direct import only loads Button
+import { Button } from '@/components/Button';
+```
+
+### Code splitting
+
+**Route-based splitting (most impactful):**
+```javascript
+// React
+const Dashboard = React.lazy(() => import('./pages/Dashboard'));
+const Settings = React.lazy(() => import('./pages/Settings'));
+
+// Next.js: automatic per-page splitting (built-in)
+```
+
+**Component-based splitting (for heavy components):**
+```javascript
+// Only load chart library when chart is rendered
+const Chart = React.lazy(() => import('./Chart'));
+
+// With loading state
+<Suspense fallback={<ChartSkeleton />}>
+  <Chart data={data} />
+</Suspense>
+```
+
+**Library-based splitting:**
+- Heavy libraries (moment, chart.js, monaco-editor) should never be in the main bundle.
+- Dynamic import at point of use.
+- Consider lighter alternatives (date-fns vs moment, lightweight chart libs).
+
+### Vendor splitting
+
+**Strategy: separate stable code from frequently changing code.**
+
+```javascript
+// webpack config
+optimization: {
+  splitChunks: {
+    cacheGroups: {
+      vendor: {
+        test: /[\\/]node_modules[\\/]/,
+        name: 'vendor',
+        chunks: 'all',
+      },
+      framework: {
+        test: /[\\/]node_modules[\\/](react|react-dom)[\\/]/,
+        name: 'framework',
+        priority: 10,
+      },
+    },
+  },
+}
+```
+
+**Benefits:**
+- Vendor chunk changes rarely → long cache lifetime.
+- Application chunk changes often → short cache lifetime.
+- Framework chunk (React) changes almost never → very long cache.
+
+### Preload and prefetch hints
+
+**Preload (critical, needed NOW):**
+```html
+<link rel="preload" href="/fonts/main.woff2" as="font" crossorigin>
+<link rel="preload" href="/critical.js" as="script">
+```
+- Use for: fonts, above-the-fold images, critical JS/CSS.
+- Preload too much = competing bandwidth = slower overall.
+
+**Prefetch (likely needed SOON):**
+```html
+<link rel="prefetch" href="/next-page-bundle.js">
+```
+- Use for: next route the user is likely to navigate to.
+- Loads during idle time, does not compete with critical resources.
+- React Router / Next.js: prefetch on link hover or viewport intersection.
+
+### Analysis tools
+
+**webpack-bundle-analyzer:**
+```bash
+npx webpack-bundle-analyzer stats.json
+```
+- Treemap visualization of all chunks.
+- Identify unexpectedly large modules.
+
+**source-map-explorer:**
+```bash
+npx source-map-explorer dist/main.js
+```
+- Shows byte-level contribution of each module.
+- Works with any bundler that produces source maps.
+
+**bundlephobia.com:**
+- Check package size before adding a dependency.
+- Shows gzipped size, tree-shakeable status, download time.
+
+### Unused code elimination
+
+- **dead code:** code that is never executed (if-false branches, unreachable after return).
+- **unused exports:** functions exported but never imported anywhere.
+- Detect with: `knip`, `ts-prune`, or bundler warnings.
+- Remove aggressively — version control has the history if you need it back.
+
+### Dynamic imports best practices
+
+- Name chunks for debugging: `import(/* webpackChunkName: "chart" */ './Chart')`.
+- Error boundary around lazy components (handle load failures gracefully).
+- Retry failed chunk loads (network errors) with exponential backoff.
+- Use `webpackPreload` / `webpackPrefetch` magic comments where appropriate.
+
+### Monitoring
+
+- CI check: fail build if bundle exceeds budget (bundlesize, size-limit).
+- Track bundle size over time in dashboard.
+- Alert on sudden increases (new dependency or misconfigured import).
+- Compare bundle size in PR comments (relative to main branch).
+
+## Self-check before task completion
+- [ ] Did I follow the mandatory actions for this skill?
+- [ ] Did I apply the patterns appropriate to the context?
+- [ ] Did I verify the implementation meets the criteria above?
+- [ ] Did I document decisions and trade-offs made?

package/.mindforge/skills/business-analyst/SKILL.md

@@ -0,0 +1,82 @@
+---
+name: business-analyst
+version: 1.0.0
+min_mindforge_version: 10.0.6
+status: stable
+triggers: business requirements, BRD, stakeholder analysis, RACI matrix, gap analysis, swimlane diagram, use case, requirements elicitation, business process, stakeholder mapping, as-is to-be, requirement gathering
+---
+
+# Skill — Business Analyst
+
+## When this skill activates
+Any task involving business requirements gathering, stakeholder analysis, process mapping,
+gap analysis, use case documentation, or translating business needs into specifications.
+
+## Mandatory actions when this skill is active
+
+### Before
+
+1. **State the business problem** — One sentence, no solution referenced. If unclear, more discovery is needed.
+2. **Map stakeholders** — Register with name, role, influence, and communication preference.
+3. **Define scope** — Explicitly state IN scope and OUT of scope to prevent creep.
+
+### During
+
+#### Stakeholder power-interest grid
+```
+High Power + High Interest = Manage Closely (co-create requirements)
+High Power + Low Interest  = Keep Satisfied (executive summaries only)
+Low Power + High Interest  = Keep Informed (regular updates)
+Low Power + Low Interest   = Monitor (minimal engagement)
+```
+
+#### Elicitation techniques (use 2+ per requirement set)
+1. Structured interviews (10-15 open questions, 45-60 min per group)
+2. Requirements workshops (3-8 cross-functional participants, affinity mapping)
+3. Observation / contextual inquiry (shadow users, document workarounds)
+4. Document analysis (SOPs, training materials, support tickets)
+5. Prototyping (low-fidelity mockups to validate understanding)
+
+#### BRD sections (mandatory 10)
+1. Executive Summary | 2. Business Objectives + KPIs | 3. Scope (in/out/assumptions/constraints) | 4. Stakeholders + RACI | 5. Current State (AS-IS) | 6. Future State (TO-BE) | 7. Functional Requirements (numbered, prioritized) | 8. Non-Functional Requirements | 9. Risks + Mitigations | 10. Approval + Sign-off
+
+#### RACI matrix rules
+- Exactly ONE Accountable (A) per row — the final decision-maker
+- At least one Responsible (R) per row — does the work
+- Consulted (C) — input before decision; Informed (I) — notified after
+
+#### AS-IS / TO-BE process mapping
+- Swimlane format: one lane per actor/system
+- Mark pain points with quantified impact (time wasted, error rate, cost)
+- TO-BE shows measurable improvement for each pain point
+- Calculate improvement metrics (e.g., "3 days to same-day, 93% reduction")
+
+#### Gap analysis matrix
+```
+| Current State | Desired State | Gap Type | Action Required | Priority |
+Gap types: Process | System | Automation | Data | People | Compliance
+Every gap maps to a concrete, assignable action.
+```
+
+#### Use case template
+- Actor, Precondition, Postcondition
+- Main flow (numbered steps, system responses)
+- Alternative flows (branching scenarios)
+- Exception flows (error handling, edge cases)
+
+### After
+
+1. **Validate with stakeholders** — Walk through BRD with each group, confirm understanding.
+2. **Trace to objectives** — Every requirement links to a business objective. Orphans = scope creep.
+3. **Confirm testability** — Every functional requirement has a verifiable acceptance criterion.
+4. **Version and baseline** — Lock approved requirements. Track changes via formal CR process.
+
+## Self-check before task completion
+- [ ] Business problem articulated without referencing a solution
+- [ ] Stakeholder register complete with power-interest classification
+- [ ] RACI defined for key decisions (exactly one A per row)
+- [ ] AS-IS process documented with quantified pain points
+- [ ] TO-BE shows measurable improvement over AS-IS
+- [ ] Gap analysis maps every gap to a concrete action
+- [ ] Requirements numbered, prioritized, traceable to objectives
+- [ ] Use cases cover main, alternative, and exception flows

package/.mindforge/skills/caching-strategies/SKILL.md

@@ -0,0 +1,132 @@
+---
+name: caching-strategies
+version: 1.0.0
+min_mindforge_version: 0.1.0
+status: stable
+compose: performance
+triggers: caching strategy, cache aside, write through cache, write behind cache, cache invalidation pattern, TTL design, cache warming, cache stampede, cache eviction, distributed cache pattern, cache coherence, cache layer design
+---
+
+# Skill — Caching Strategies
+
+## When this skill activates
+Any task involving cache layer design, cache invalidation, stampede prevention,
+TTL configuration, or distributed caching patterns.
+
+## Mandatory actions when this skill is active
+
+### Before writing any code
+1. Identify the data access pattern (read-heavy, write-heavy, mixed).
+2. Select the appropriate caching pattern for the use case.
+3. Define the invalidation strategy before implementing the cache.
+
+### During implementation
+- Implement stampede prevention for all high-traffic cache keys.
+- Set TTLs appropriate to data volatility.
+- Add cache hit/miss metrics instrumentation.
+
+### After implementation
+- Verify cache hit rate meets target (>90% for hot paths).
+- Document the caching layer in ARCHITECTURE.md.
+- Add monitoring alerts for cache exhaustion and low hit rates.
+
+## Caching Patterns
+
+### Cache-Aside (Lazy Loading)
+- Application manages the cache explicitly.
+- Read: check cache → miss → read DB → populate cache → return.
+- Write: update DB → invalidate cache (not update).
+- Best for: read-heavy workloads with tolerance for occasional stale data.
+- Risk: thundering herd on cold start or mass invalidation.
+
+### Write-Through
+- Application writes to cache and DB synchronously.
+- Every write updates both cache and store atomically.
+- Read: always from cache (guaranteed fresh).
+- Best for: data that is read immediately after write.
+- Trade-off: higher write latency, but reads are always consistent.
+
+### Write-Behind (Write-Back)
+- Application writes to cache; cache asynchronously flushes to DB.
+- Dramatically reduces write latency.
+- Best for: high write throughput where eventual consistency is acceptable.
+- Risk: data loss if cache node crashes before flush.
+
+## Invalidation Strategies
+
+### Event-Based Invalidation
+- Publish cache invalidation events on data mutation.
+- Consumers invalidate specific keys on receipt.
+- Most precise — invalidates only what changed.
+
+### TTL-Based Expiration
+- Set time-to-live on every cache entry.
+- Safety net, not a primary strategy.
+- Short TTL for volatile data (30s-5m), long TTL for static data (1h-24h).
+
+### Version-Based Invalidation
+- Include version number in cache key.
+- Increment version on data change — old key naturally expires.
+- Good for configuration and template caching.
+
+## Stampede Prevention
+
+### Lock/Mutex Pattern
+- First request acquires lock, fetches from DB, populates cache.
+- Subsequent requests wait on lock, then read from cache.
+- Prevents N simultaneous DB queries for same key.
+
+### Stale-While-Revalidate
+- Serve stale cached data immediately.
+- Trigger background refresh asynchronously.
+- User gets fast response; cache refreshes in background.
+
+### Pre-Computation
+- Refresh cache entries before they expire.
+- Background job renews popular keys proactively.
+- Eliminates cold-cache scenarios entirely.
+
+## TTL Design Guidelines
+
+| Data Type | Recommended TTL | Rationale |
+|-----------|----------------|-----------|
+| User session | 15-30 minutes | Security balance |
+| Product catalog | 1-4 hours | Changes infrequently |
+| Static assets | 24h-7 days | Immutable after deploy |
+| Real-time prices | 5-30 seconds | High volatility |
+| Configuration | 5-15 minutes | Moderate change rate |
+
+## Cache Warming
+
+- Pre-populate cache on deployment with known hot data.
+- Run warming job during maintenance windows.
+- Prioritize by access frequency (top 20% of keys = 80% of traffic).
+- Warm incrementally to avoid overwhelming the data store.
+
+## Cache Layers (Multi-Tier)
+
+### L1: In-Process Cache
+- Fastest (nanoseconds), limited by application memory.
+- Use for: config, feature flags, frequently accessed reference data.
+- Examples: Caffeine (Java), node-cache (Node.js), lru-cache.
+
+### L2: Distributed Cache
+- Shared across instances, millisecond latency.
+- Use for: session data, computed results, API responses.
+- Examples: Redis, Memcached, Hazelcast.
+
+### L3: CDN Cache
+- Edge-cached, global distribution.
+- Use for: static assets, public API responses, media.
+- Examples: CloudFront, Cloudflare, Fastly.
+
+## 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)
+- [ ] Did I define an invalidation strategy for every cached entity?
+- [ ] Did I implement stampede prevention for high-traffic keys?
+- [ ] Did I set appropriate TTLs with documented rationale?
+- [ ] Did I add cache hit/miss metrics?
+- [ ] Did I document the caching layer in ARCHITECTURE.md?

package/.mindforge/skills/capacity-planning/SKILL.md

@@ -0,0 +1,96 @@
+---
+name: capacity-planning
+version: 1.0.0
+min_mindforge_version: 10.0.9
+status: stable
+triggers: capacity planning, growth forecasting, resource scaling trigger, headroom calculation, degradation curve, saturation point, scaling threshold, load projection, capacity model, bottleneck forecast, resource budget, traffic forecast
+---
+
+# Skill — Capacity Planning
+
+## When this skill activates
+Any task involving capacity modeling, growth forecasting, scaling triggers,
+headroom calculation, saturation point analysis, or bottleneck forecasting.
+
+## Mandatory actions when this skill is active
+
+### Before writing any code
+1. Measure current utilization across all system components.
+2. Model growth using historical data and planned launches.
+3. Identify the first bottleneck (component that saturates first).
+
+### During implementation
+- Define scaling triggers with thresholds and cooldown periods.
+- Implement capacity metrics (utilization, queue depth, latency).
+- Configure auto-scaling aligned with the capacity model.
+- Maintain 30-40% headroom above expected peak.
+
+### After implementation
+- Validate model with load testing at projected future load.
+- Set alerts for approaching saturation (70%, 85%, 95%).
+- Schedule quarterly capacity review to recalibrate.
+
+## Methodology
+
+1. **Measure**: baseline CPU, memory, disk IO, network, app-level metrics (p50/p95/p99).
+2. **Model**: organic growth + step functions (launches) + seasonal patterns.
+3. **Identify**: map each component to its saturation point, find the first bottleneck.
+4. **Plan**: define scaling triggers, budget infrastructure, document runbook.
+
+## Growth Forecasting
+
+```
+projected_month_N = current * (1 + growth_rate)^N + planned_launch_impact
+```
+
+- Historical trend: last 3-6 months. Seasonal patterns: daily/weekly/yearly peaks.
+- Peak-to-average ratio determines required vs baseline capacity.
+
+## Headroom Calculation
+
+```
+Required Capacity = Expected Peak / (1 - headroom_fraction)
+Example: 700 RPS peak, 30% headroom → 700/0.70 = 1000 RPS provisioned
+```
+
+- Fast auto-scaling (<2 min): 20-30% headroom.
+- Slow scaling (>10 min): 40-50% headroom.
+- No auto-scaling: 50%+ or accept degradation risk.
+
+## Saturation Point
+- The load at which p99 latency exceeds SLA or error rate exceeds threshold.
+- Find via incremental load test (ramp 0 → 2x peak), plot load vs latency.
+- The "knee" where the curve bends sharply = saturation. Operate well below it.
+
+## Scaling Triggers
+
+| Metric | Threshold | Action |
+|--------|-----------|--------|
+| CPU > 70% for 5 min | Scale out application tier |  |
+| Memory > 80% | Scale up or out |  |
+| Queue depth > 1000 for 3 min | Add consumers |  |
+| p99 > 500ms for 2 min | Scale application |  |
+| Error rate > 1% for 1 min | Investigate + possibly scale |  |
+
+- Cooldown after scale-out: 5 min. After scale-in: 15 min (prevent flapping).
+- Predictive: pre-scale before known peaks (Monday AM, campaign launch).
+
+## Bottleneck Forecasting
+
+| Component | Current Util | Saturation | Time to Sat |
+|-----------|-------------|------------|-------------|
+| API servers | 45% | 80% | 4 months |
+| Database | 62% | 75% | 6 weeks |
+| Cache | 30% | 85% | 8 months |
+
+Focus on shortest time-to-saturation first.
+
+## Self-check before task completion
+
+- [ ] Is current utilization measured across all critical components?
+- [ ] Is growth model based on historical data plus planned launches?
+- [ ] Is the first bottleneck identified with time-to-saturation?
+- [ ] Are scaling triggers defined with thresholds and cooldowns?
+- [ ] Is 30-40% headroom maintained above expected peak?
+- [ ] Has the model been validated with load testing?
+- [ ] Are alerts configured for approaching saturation?

package/.mindforge/skills/causal-inference/SKILL.md

@@ -0,0 +1,42 @@
+---
+name: causal-inference
+version: 1.0.0
+min_mindforge_version: 10.6.0
+status: stable
+triggers: causal inference analysis, A/B test statistical analysis, uplift modeling, propensity score matching, counterfactual reasoning, treatment effect estimation, causal graph, instrumental variable, difference in differences, causal impact, experiment analysis methodology, selection bias correction
+---
+
+# Skill — Causal Inference
+
+## When this skill activates
+This skill activates when analyzing treatment effects, designing A/B tests with statistical rigor, building uplift models, or performing counterfactual reasoning. Use when you need to establish causation (not just correlation) between interventions and outcomes.
+
+## Mandatory actions when this skill is active
+
+### Before writing any code
+1. Define the causal estimand precisely (ATE, ATT, CATE) and document all causal assumptions (SUTVA, ignorability, positivity)
+2. Draw a Directed Acyclic Graph (DAG) identifying treatment, outcome, confounders, mediators, colliders, and instrumental variables
+3. Select the appropriate causal inference method (RCT analysis, propensity scoring, instrumental variables, diff-in-diff, RDD, synthetic control) based on data structure and identification strategy
+4. Calculate minimum detectable effect size and required sample size with power analysis (typically 80% power, 5% alpha)
+
+### During implementation
+- Validate the overlap/common support assumption by examining propensity score distributions across treatment groups
+- Test for balance on all confounders after matching/weighting (standardized mean differences <0.1, variance ratios 0.5-2.0)
+- Implement sensitivity analysis to assess robustness to unmeasured confounding (e.g., Rosenbaum bounds, E-values)
+- Use doubly robust estimators when possible (combining outcome regression and propensity scoring for consistent estimates)
+- Check for heterogeneous treatment effects across subgroups and report conditional average treatment effects (CATE)
+- Validate parallel trends assumption for difference-in-differences designs with pre-treatment period analysis
+- Report confidence intervals using robust standard errors (clustered at appropriate level) or bootstrap resampling
+
+### After implementation
+- Present results with effect sizes in original units (not just p-values) and practical significance interpretation
+- Document all assumptions made, sensitivity analysis results, and potential violations of causal identification
+- Create visualization showing treatment effect heterogeneity across covariates and subgroups
+- Generate reproducible analysis pipeline with versioned data, code, and randomization logs
+
+## Self-check before task completion
+- [ ] Causal DAG documented with clear identification strategy and testable implications
+- [ ] Balance diagnostics show adequate covariate balance (SMD <0.1) after adjustment
+- [ ] Sensitivity analysis demonstrates results are robust to reasonable violations of assumptions
+- [ ] Confidence intervals and effect sizes reported in interpretable units with business context
+- [ ] All code is reproducible with seed setting for randomization and resampling procedures