mindforge-cc 10.0.3 → 10.7.0

package/.mindforge/skills/migration-platform/SKILL.md

@@ -0,0 +1,61 @@
+---
+name: migration-platform
+version: 1.0.0
+min_mindforge_version: 10.7.0
+status: stable
+triggers: migration platform design, schema migration orchestration, data migration tooling, zero-downtime migration automation, migration validation, migration rollback platform, database migration service, migration state machine, migration dry-run, migration scheduling, migration dependency graph, migration progress tracking
+compose: migration-strategies
+---
+
+# Skill — Migration Platform
+
+## When this skill activates
+
+This skill activates when the user is designing or implementing a migration platform. This includes schema migration orchestration, data migration tooling, zero-downtime migration automation, migration validation, rollback capabilities, database migration services, migration state machines, dry-run testing, migration scheduling, dependency graph management, and progress tracking.
+
+## Mandatory actions when this skill is active
+
+### Before writing any code
+
+1. Inventory all systems requiring migration: databases, APIs, services, data pipelines, infrastructure. Quantify: data volume, traffic volume, number of tables/services.
+2. Define migration success criteria: zero downtime, data consistency, performance impact under 10%, rollback time under 5 minutes.
+3. Identify dependencies: which services depend on the system being migrated. Build dependency graph to determine migration order.
+4. Assess risk: classify migrations by risk (low, medium, high, critical). High-risk migrations require dry-run, shadow traffic, and manual approval gates.
+5. Establish rollback strategy: forward-compatible schema changes, dual-write period, automated rollback triggers (error rate > 5%).
+
+### During implementation
+
+- **Migration State Machine:** Define states: pending → dry-run → scheduled → in-progress → validating → completed / failed / rolled-back. Track state per migration in database. Expose state via API and dashboard.
+- **Schema Migration Orchestration:** Use tools like Liquibase, Flyway, or Alembic. Migrations should be: idempotent, forward-compatible, backward-compatible during rollout. Apply migrations in stages: additive changes → data migration → breaking changes.
+- **Zero-Downtime Patterns:**
+  - **Expand-Contract:** Add new column/table (expand), dual-write to old and new (transition), switch reads to new (cutover), remove old (contract).
+  - **Blue-Green:** Deploy new version alongside old, switch traffic atomically, keep old version for quick rollback.
+  - **Shadow Traffic:** Mirror production traffic to new system, compare results, cutover when validation passes.
+- **Data Migration Tooling:** Build ETL pipelines for bulk data migration. Include: checkpointing (resume from failure), batching (avoid overwhelming target), validation (row counts, checksums), rate limiting (avoid impacting production). Migrations should be resumable and idempotent.
+- **Migration Validation:** Automated validation checks: data integrity (row counts, checksums), functional correctness (run test suite against new system), performance (latency, throughput within 10% of baseline). Fail migration if any check fails.
+- **Migration Rollback:** Automate rollback when error rate exceeds threshold (5% or 1% for critical systems). Rollback should: revert traffic to old system, preserve data written during migration (dual-write), alert on-call team. Rollback time target: under 5 minutes.
+- **Dry-Run Testing:** Run migrations in staging environment first. Use production-like data volume and traffic patterns. Validate performance, correctness, and rollback. Dry-run should be mandatory for high-risk migrations.
+- **Migration Scheduling:** Schedule migrations during low-traffic windows. Provide manual approval gates for critical migrations. Include: notification to stakeholders, runbook link, on-call team assignment.
+- **Dependency Graph Management:** Build migration dependency graph (service A depends on service B). Enforce migration order: migrate dependencies first, then dependents. Detect circular dependencies and fail early.
+- **Progress Tracking:** Real-time dashboard showing: migration state, percentage complete, error rate, performance metrics, estimated time remaining. Include logs and alerts for anomalies.
+
+### After implementation
+
+- Verify migration state machine tracks all migrations with state transitions logged.
+- Confirm schema migrations are idempotent, forward-compatible, and backward-compatible during rollout.
+- Validate zero-downtime patterns (expand-contract, blue-green, shadow traffic) are implemented.
+- Ensure data migration tooling includes checkpointing, batching, validation, and rate limiting.
+- Check that migration rollback is automated with under 5-minute rollback time.
+
+## Self-check before task completion
+
+- [ ] Migration state machine tracks pending, in-progress, completed, failed, rolled-back states.
+- [ ] Schema migrations are idempotent, forward-compatible, and backward-compatible.
+- [ ] Zero-downtime patterns (expand-contract, blue-green, shadow traffic) are implemented.
+- [ ] Data migration tooling is resumable, idempotent, and includes validation.
+- [ ] Migration validation checks data integrity, functional correctness, and performance.
+- [ ] Migration rollback is automated and completes in under 5 minutes.
+- [ ] Dry-run testing is mandatory for high-risk migrations in production-like staging.
+- [ ] Migration scheduling supports manual approval gates and stakeholder notifications.
+- [ ] Dependency graph enforces migration order and detects circular dependencies.
+- [ ] Progress tracking dashboard shows real-time state, percentage complete, and error rate.

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

@@ -0,0 +1,129 @@
+---
+name: migration-strategies
+version: 1.0.0
+min_mindforge_version: 0.1.0
+status: stable
+compose: database-patterns
+triggers: zero downtime migration, expand contract migration, shadow table, backfill pattern, feature flag migration, online schema change, blue green migration, migration rollback, data migration, schema migration pattern, migration verification, dual write
+---
+
+# Skill — Migration Strategies
+
+## When this skill activates
+Any task involving database schema migrations, data migrations, zero-downtime
+deployments requiring data changes, or expand-contract patterns.
+
+## Mandatory actions when this skill is active
+
+### Before writing any code
+1. Assess the migration risk (table size, lock duration, rollback complexity).
+2. Choose the migration pattern appropriate to the risk level.
+3. Design the rollback path before implementing the forward migration.
+
+### During implementation
+- Ensure backward compatibility at every intermediate step.
+- Implement batched processing with rate limiting for data backfills.
+- Add verification queries to confirm migration correctness.
+
+### After implementation
+- Run verification (row counts, checksums, sample validation).
+- Confirm rollback path works in staging.
+- Document the migration in the changelog with rollback instructions.
+
+## Expand-Contract Pattern
+
+The safest approach for schema changes in production:
+
+### Phase 1: Expand
+- Add new column/table (nullable or with default).
+- Deploy code that writes to BOTH old and new locations.
+- No reads from new location yet.
+
+### Phase 2: Migrate
+- Backfill existing data from old location to new.
+- Batched, rate-limited, resumable, idempotent.
+- Verify all data migrated correctly.
+
+### Phase 3: Switch Reads
+- Deploy code that reads from new location.
+- Old location still being written (safety net).
+- Monitor for correctness issues.
+
+### Phase 4: Contract
+- Remove writes to old location.
+- Drop old column/table after grace period.
+- Final verification and cleanup.
+
+## Shadow Tables
+
+- Create new table with desired schema.
+- Dual-write: every mutation hits both old and new table.
+- Compare outputs periodically to verify consistency.
+- Switch reads to new table when confidence is high.
+- Drop old table after grace period.
+
+## Zero-Downtime Online Schema Changes
+
+For large tables where ALTER TABLE would lock:
+
+### Tools
+- **pt-online-schema-change** (Percona): creates shadow table, syncs via triggers.
+- **gh-ost** (GitHub): triggerless, uses binary log replication.
+- **pg_repack** (PostgreSQL): repacks tables without locks.
+
+### Principles
+- Never run ALTER on tables > 1M rows in production without online tools.
+- Test migration duration in staging with production-sized data.
+- Schedule during low-traffic windows even with online tools.
+- Monitor replication lag during migration.
+
+## Backfill Patterns
+
+### Batched Processing
+```
+loop:
+  SELECT batch WHERE not_migrated LIMIT 1000
+  UPDATE batch SET new_column = transform(old_column)
+  SLEEP(rate_limit_interval)
+  IF no_more_rows: BREAK
+```
+
+### Requirements
+- **Resumable**: track progress (last processed ID), restart from checkpoint.
+- **Idempotent**: running twice produces same result (use upserts).
+- **Rate-limited**: don't overwhelm the database (pause between batches).
+- **Observable**: log progress, ETA, error counts.
+
+## Migration Verification
+
+### Row Count Comparison
+- Count rows in source and target (should match for 1:1 migrations).
+- Account for in-flight writes during comparison.
+
+### Checksum Validation
+- Hash critical columns in both source and target.
+- Compare checksums batch by batch.
+
+### Sample Validation
+- Randomly sample N rows from source.
+- Verify each exists in target with correct values.
+- Catch edge cases that aggregate checks miss.
+
+## Rollback Strategy
+
+- Every migration must have a documented rollback path.
+- Intermediate states must be backward-compatible (old code can still run).
+- Keep old columns/tables for a grace period (minimum 7 days in production).
+- Test rollback in staging before executing forward migration in production.
+- Feature flags to switch between old and new code paths instantly.
+
+## 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 the migration zero-downtime (no table locks on large tables)?
+- [ ] Is there a documented rollback path?
+- [ ] Are backfills batched, resumable, and idempotent?
+- [ ] Did I verify with row counts, checksums, or sample validation?
+- [ ] Is every intermediate state backward-compatible?

package/.mindforge/skills/ml-feature-store/SKILL.md

@@ -0,0 +1,56 @@
+---
+name: ml-feature-store
+version: 1.0.0
+min_mindforge_version: 10.5.0
+status: stable
+triggers: ML feature store, feature engineering pipeline, feature serving architecture, offline online feature store, feature reuse pattern, feature registry, feature computation, point-in-time feature, feature freshness, feature monitoring, feature discovery, feature lineage tracking
+compose:
+---
+
+# ML Feature Store Architecture
+
+## When this skill activates
+
+This skill activates when designing feature stores, implementing feature engineering pipelines, serving features for real-time inference, or managing feature versioning and lineage. It applies to ML systems where features must be computed consistently across training (offline) and inference (online) to avoid training-serving skew.
+
+## Mandatory actions when this skill is active
+
+### Before writing any code
+
+1. **Define feature taxonomy** — Categorize features by computation type: static (user demographics, product attributes), slowly-changing (credit score, updated monthly), fast-changing (session activity, updated per event), and on-demand (real-time aggregations computed at query time). Different types require different storage and serving strategies.
+2. **Design offline/online split** — Offline store (data warehouse, S3/GCS, Parquet files) for batch training. Online store (Redis, DynamoDB, Cassandra) for low-latency serving (<10ms). Define synchronization strategy: batch precompute and copy, streaming updates, or hybrid (precompute slow features, compute fast features on-demand).
+3. **Establish point-in-time correctness** — Features for training must reflect the state of the world at the time the label was created. Implement temporal joins: match feature values to label timestamps within a tolerance window (e.g., use features from up to 1 hour before the event). Incorrect temporal joins cause label leakage and inflated training accuracy.
+4. **Plan for feature versioning** — Features evolve (new aggregations, bug fixes, redefinitions). Version features with semantic versioning (user_clicks_v1, user_clicks_v2). Models must specify which feature versions they depend on. Changing feature definitions without versioning breaks deployed models.
+
+### During implementation
+
+- **Implement feature registry** — Centralized catalog of all features: name, description, data type, computation logic, dependencies, owner, and version. Registry enables feature discovery (find existing features before building new ones) and governance (track who uses which features). Use tools like Feast, Tecton, or build custom with a metadata database.
+- **Build batch feature computation pipelines** — Compute features on historical data using batch processing (Spark, Dask, BigQuery). Optimize for cost: materialize expensive aggregations (rolling windows, joins) rather than recomputing on every training run. Schedule pipelines with orchestrators (Airflow, Prefect, Dagster).
+- **Implement streaming feature updates** — For fast-changing features (session activity, real-time aggregations), use stream processing (Kafka + Flink, Kinesis, Spark Streaming). Update online store as events arrive. Validate that streaming logic matches batch logic (same SQL query should produce same results on batch and streaming data).
+- **Design feature serving API** — Provide low-latency API to fetch features by entity key (user_id, product_id). Batch fetch for efficiency (fetch 100 user features in one call, not 100 individual calls). Return features in consistent schema (names, data types) to avoid model breakage.
+- **Handle missing features gracefully** — Features may be missing (new user without history, sensor failure, data pipeline delay). Define default values (zero, mean, median, or a special sentinel value). Document defaults explicitly. Train models with synthetic missing data to ensure robustness.
+- **Track feature lineage** — Record dependencies: which raw data sources produce which features, which features are used by which models. Lineage enables impact analysis: if a data source changes, which models are affected? Use metadata graphs or lineage tools (DataHub, Marquez).
+
+### After implementation
+
+- **Validate training-serving consistency** — Compute features offline (for training) and online (for serving) on the same input data. Compare outputs. Divergence >1% indicates a bug in feature logic. Common causes: timezone mismatches, different null handling, floating-point precision differences.
+- **Measure feature freshness** — Track lag between event time and feature availability. For streaming features, target <1 minute lag. For batch features, document update frequency (hourly, daily). Stale features degrade model accuracy in production.
+- **Benchmark serving latency** — Measure p50, p95, p99 latency for feature retrieval under realistic load. Target: p95 <10ms for online serving. If higher, optimize online store (better indexes, caching, denormalization) or reduce feature count.
+- **Monitor feature drift** — Track feature distributions over time. If distributions shift significantly (mean, variance, or cardinality changes), model accuracy may degrade. Set up alerts for distribution drift (Kolmogorov-Smirnov test, Population Stability Index).
+
+## Self-check before task completion
+
+- [ ] Feature taxonomy categorizes features by computation type (static, slowly-changing, fast-changing, on-demand)
+- [ ] Offline/online storage split is designed with synchronization strategy documented
+- [ ] Point-in-time correctness is implemented with temporal joins (tolerance window defined)
+- [ ] Feature versioning uses semantic versioning and models declare feature version dependencies
+- [ ] Feature registry catalogs all features with name, description, data type, logic, dependencies, owner, version
+- [ ] Batch feature pipelines materialize expensive aggregations and are scheduled with orchestrators
+- [ ] Streaming feature updates match batch logic (validated with same SQL queries on batch and streaming data)
+- [ ] Feature serving API supports batch fetch and returns consistent schema
+- [ ] Missing features are handled with explicit defaults documented per feature
+- [ ] Feature lineage tracks raw data sources → features → models for impact analysis
+- [ ] Training-serving consistency is validated (offline and online feature outputs differ by <1%)
+- [ ] Feature freshness is measured and documented (lag <1 minute for streaming, update frequency for batch)
+- [ ] Serving latency p95 is <10ms under realistic load
+- [ ] Feature drift monitoring is implemented with distribution tracking and alerts

package/.mindforge/skills/ml-monitoring/SKILL.md

@@ -0,0 +1,42 @@
+---
+name: ml-monitoring
+version: 1.0.0
+min_mindforge_version: 10.6.0
+status: stable
+triggers: ML model monitoring, model drift detection, data quality monitoring, performance degradation alert, retraining trigger, model decay detection, prediction monitoring, feature drift, concept drift detection, model health dashboard, ML observability, model performance SLA
+---
+
+# Skill — ML Monitoring
+
+## When this skill activates
+This skill activates when implementing production ML observability, drift detection systems, or automated retraining pipelines. Use when models are deployed and require continuous performance tracking and health monitoring.
+
+## Mandatory actions when this skill is active
+
+### Before writing any code
+1. Define model performance SLAs with business stakeholders: accuracy thresholds, latency requirements, prediction volume expectations, and acceptable degradation rates
+2. Establish baseline distributions for all features, predictions, and evaluation metrics from training data and initial production period
+3. Select drift detection methods appropriate to data types: KS test for continuous, chi-square for categorical, PSI for binned distributions
+4. Design alerting strategy with severity levels: critical (immediate intervention), warning (investigate within 24h), informational (track trend)
+
+### During implementation
+- Log 100% of predictions with model version, feature values, timestamp, and prediction context for forensic analysis
+- Implement statistical drift detection on feature distributions comparing rolling windows to baseline (typically 7d vs 30d trailing)
+- Track concept drift by monitoring model performance metrics on recent predictions with ground truth labels when available
+- Calculate prediction drift metrics: distribution shifts, confidence score changes, class imbalance variations over time
+- Monitor data quality indicators: missing value rates, out-of-range values, schema violations, duplicate records, freshness delays
+- Implement shadow scoring for challenger models to compare performance against production champion model continuously
+- Create automated retraining triggers based on drift thresholds, performance degradation, or calendar schedule with approval gates
+
+### After implementation
+- Build real-time dashboards showing model health: prediction volume, latency p95/p99, error rates, drift scores, and performance metrics
+- Set up alerting channels integrated with on-call rotation: PagerDuty, Slack, email with runbook links for common issues
+- Generate weekly model health reports with drift analysis, performance trends, data quality issues, and recommended actions
+- Document incident response procedures: model rollback process, emergency retraining workflow, and escalation paths
+
+## Self-check before task completion
+- [ ] All predictions logged with sufficient context for debugging and audit requirements
+- [ ] Drift detection implemented for top 10 most important features with statistical significance testing
+- [ ] Performance monitoring tracks all business-critical metrics with automated alerting on degradation
+- [ ] Retraining pipeline tested end-to-end with rollback capability and A/B testing framework
+- [ ] Dashboard provides visibility into model health for both technical teams and business stakeholders

package/.mindforge/skills/mobile-performance/SKILL.md

@@ -0,0 +1,44 @@
+---
+name: mobile-performance
+version: 1.0.0
+min_mindforge_version: 10.4.0
+status: stable
+triggers: mobile app performance, app startup optimization, mobile memory management, battery usage optimization, frame rate optimization, mobile rendering performance, mobile network optimization, app size reduction, mobile profiling, jank reduction, mobile CPU optimization, smooth scrolling mobile
+---
+
+# Skill — Mobile Performance Optimization
+
+## When this skill activates
+This skill activates when optimizing mobile app performance, including startup time, memory usage, battery consumption, frame rate, network efficiency, or app size reduction.
+
+## Mandatory actions when this skill is active
+
+### Before writing any code
+1. Establish performance baselines using profiling tools (Xcode Instruments, Android Studio Profiler, React DevTools)
+2. Identify performance targets: startup time (<2s to interactive), frame rate (60fps), memory budget, battery impact
+3. Profile existing app to find bottlenecks — CPU hotspots, memory leaks, excessive network calls, unnecessary renders
+4. Determine which optimizations provide highest impact for lowest effort (focus on hot paths first)
+
+### During implementation
+- Defer non-critical initialization to after app becomes interactive (lazy loading, background threads)
+- Implement virtualized lists for large datasets (RecyclerView, UICollectionView, FlatList with proper optimization props)
+- Optimize images: compress, use appropriate formats (WebP, HEIF), implement progressive loading and caching
+- Minimize JavaScript bridge traffic in hybrid apps — batch calls, use native implementations for performance-critical code
+- Implement proper pagination and infinite scroll to avoid loading excessive data
+- Use release builds for performance testing — debug builds have significant overhead
+- Profile memory allocations, fix retain cycles, implement proper cleanup in component unmount/dispose
+
+### After implementation
+- Measure startup time from app launch to first interactive frame using platform tools
+- Profile with production-like data volume and network conditions (throttle to 3G/4G)
+- Test on low-end devices (not just flagship phones) to catch performance issues
+- Monitor frame rate during animations, scrolling, and transitions using on-device FPS counters
+- Use battery profiling tools to identify energy-intensive operations (location, background processing, wake locks)
+
+## Self-check before task completion
+- [ ] App startup time meets target (<2s to interactive on mid-range device)
+- [ ] Frame rate stays at 60fps during scrolling and animations (no jank or dropped frames)
+- [ ] Memory usage is stable with no leaks (test with extended usage, multiple navigation cycles)
+- [ ] App size is minimized (proper ProGuard/R8, asset optimization, code splitting)
+- [ ] Battery impact is acceptable (no excessive background processing, location polling, or wake locks)
+- [ ] Network usage is optimized (request batching, proper caching, compression, avoid polling)

package/.mindforge/skills/mobile-security/SKILL.md

@@ -0,0 +1,45 @@
+---
+name: mobile-security
+version: 1.0.0
+min_mindforge_version: 10.4.0
+status: stable
+triggers: mobile security architecture, certificate pinning, secure storage mobile, biometric authentication, root detection, jailbreak detection, mobile encryption, mobile API security, keychain keystore, mobile OWASP, secure communication mobile, mobile token storage
+compose: auth-patterns
+---
+
+# Skill — Mobile Security Architecture
+
+## When this skill activates
+This skill activates when implementing security-sensitive mobile features, including certificate pinning, secure storage, biometric authentication, root/jailbreak detection, or protecting against mobile-specific attack vectors.
+
+## Mandatory actions when this skill is active
+
+### Before writing any code
+1. Review OWASP Mobile Top 10 and identify applicable threats to the application
+2. Determine data classification and storage requirements (keychain/keystore for sensitive data, never UserDefaults/SharedPreferences)
+3. Establish certificate pinning strategy (pin leaf certificate, intermediate, or public key hash)
+4. Plan authentication flow with biometric fallback, token refresh, and secure token storage
+
+### During implementation
+- Store sensitive data in platform secure storage (iOS Keychain with proper accessibility attributes, Android Keystore)
+- Implement certificate pinning for API communications to prevent man-in-the-middle attacks
+- Use biometric authentication (Face ID, Touch ID, Biometric Prompt) with proper fallback to passcode
+- Implement root/jailbreak detection (check for common indicators, but never rely solely on client-side checks)
+- Encrypt local databases and sensitive files using platform encryption APIs (SQLCipher, native encryption)
+- Obfuscate code (ProGuard/R8 for Android, native code for critical logic) to deter reverse engineering
+- Implement proper session management with token expiration, refresh tokens, and secure logout
+
+### After implementation
+- Test security implementation with security scanning tools (MobSF, QARK, or commercial tools)
+- Verify certificate pinning works correctly and fails on MITM attempts
+- Test biometric authentication edge cases: disabled biometrics, changed biometrics, hardware unavailability
+- Validate secure storage: data persists securely across app restarts, inaccessible without authentication
+- Test root/jailbreak detection on compromised devices, verify graceful degradation or blocking
+
+## Self-check before task completion
+- [ ] Sensitive data is never stored in plaintext (logs, UserDefaults, SharedPreferences, temp files)
+- [ ] Certificate pinning is implemented for all API endpoints with sensitive data
+- [ ] Biometric authentication follows platform best practices (keychain/keystore-backed, proper error handling)
+- [ ] Root/jailbreak detection is implemented with appropriate response (warn, degrade functionality, or block)
+- [ ] API tokens are stored securely (keychain/keystore) and transmitted securely (HTTPS only, proper headers)
+- [ ] App handles security failures gracefully (logout on tampering detection, clear sensitive data on uninstall)

package/.mindforge/skills/model-evaluation/SKILL.md

@@ -0,0 +1,53 @@
+---
+name: model-evaluation
+version: 1.0.0
+min_mindforge_version: 10.5.0
+status: stable
+triggers: model evaluation framework, AI benchmark design, model A/B testing, quality metrics AI, model regression detection, evaluation dataset curation, model comparison methodology, LLM evaluation, model performance tracking, model evaluation harness, model scoring rubric, automated model eval
+compose:
+  - agent-evaluation-framework
+---
+
+# Model Evaluation & Benchmarking
+
+## When this skill activates
+
+This skill activates when designing evaluation frameworks for AI models, comparing multiple models, detecting performance regressions, or building automated evaluation pipelines. It applies to any system where model quality must be measured, tracked, or validated before deployment.
+
+## Mandatory actions when this skill is active
+
+### Before writing any code
+
+1. **Define evaluation objectives** — Identify what you're measuring: task accuracy (classification, generation quality), robustness (adversarial examples, distribution shift), efficiency (latency, throughput, cost), or fairness (demographic parity, equalized odds). Different objectives require different metrics.
+2. **Curate evaluation datasets** — Build a held-out test set that is representative (covers real-world distribution), diverse (includes edge cases and rare categories), and adversarial (contains challenging examples designed to expose weaknesses). Evaluation sets must never overlap with training data.
+3. **Select appropriate metrics** — Choose metrics aligned with business goals: accuracy/F1 for classification, BLEU/ROUGE for text generation, perplexity for language models, user preference for subjective tasks. Avoid vanity metrics (high accuracy on unrealistic data). Document why each metric matters.
+4. **Establish baseline performance** — Measure current production model or a simple heuristic baseline (random, majority class, rule-based). New models must beat the baseline by a meaningful margin (≥5% relative improvement) to justify deployment.
+
+### During implementation
+
+- **Implement metric computation pipelines** — Automate metric calculation with error handling: handle missing predictions, malformed outputs, and edge cases (division by zero, empty strings). Metrics should never crash on bad inputs.
+- **Design multi-dimensional scorecards** — Track multiple metrics simultaneously: accuracy, latency, cost, fairness. Optimize for trade-offs, not single metrics. A model with 99% accuracy but 10x latency may not be viable.
+- **Build pairwise comparison systems** — For subjective tasks (text quality, summarization), implement head-to-head comparisons: show two model outputs, ask humans which is better. Measure win rate and statistical significance (use bootstrap confidence intervals).
+- **Implement regression detection** — Run evaluation on every model checkpoint and compare to previous best. If any metric drops by >X% (threshold depends on metric), flag as regression and block deployment. Track metrics over time with time-series plots.
+- **Create stratified evaluations** — Break down performance by subgroups: per-category accuracy, per-demographic fairness, per-difficulty-level performance. Aggregate metrics hide disparities. A model may perform well overall but fail catastrophically on minority subgroups.
+- **Version evaluation datasets** — Evaluation sets evolve as model capabilities improve. Version datasets with semantic versioning (v1.0, v1.1) and track which model versions were evaluated on which dataset versions. Results are only comparable within the same dataset version.
+
+### After implementation
+
+- **Validate metric reliability** — Compute confidence intervals and statistical significance for all metrics. Use bootstrap resampling (1000+ iterations) to estimate variance. Report metrics as mean ± 95% CI, not point estimates.
+- **Test for overfitting to eval set** — If developers repeatedly tune models on the eval set, the eval set becomes a second training set. Periodically refresh eval sets with new examples. Monitor if performance on new eval sets drops significantly compared to old eval sets.
+- **Document evaluation methodology** — Write a technical report: dataset description, metric definitions, baseline performance, statistical tests used. Evaluation is only reproducible if methodology is explicit. Include code, dataset URLs, and random seeds.
+- **Publish results in standardized format** — Use community-standard formats: JSONL with task, model, dataset, metric, score, confidence_interval. Enable comparison across models and teams without manual data wrangling.
+
+## Self-check before task completion
+
+- [ ] Evaluation objectives (accuracy/robustness/efficiency/fairness) are explicitly defined
+- [ ] Evaluation dataset is held-out, representative, diverse, and versioned
+- [ ] Metrics are aligned with business goals and documented with justification
+- [ ] Baseline performance is established and new models beat baseline by ≥5% relative improvement
+- [ ] Multi-dimensional scorecards track accuracy, latency, cost, and fairness simultaneously
+- [ ] Regression detection flags performance drops >X% and blocks deployment
+- [ ] Performance is stratified by subgroups (categories, demographics, difficulty levels)
+- [ ] Confidence intervals are computed via bootstrap (1000+ iterations) and reported with all metrics
+- [ ] Evaluation methodology is documented with dataset, metrics, baselines, and statistical tests
+- [ ] Results are published in standardized format (JSONL) for cross-model comparison

package/.mindforge/skills/monorepo-management/SKILL.md

@@ -0,0 +1,100 @@
+---
+name: monorepo-management
+version: 1.0.0
+min_mindforge_version: 10.0.8
+status: stable
+triggers: monorepo, nx workspace, turborepo, task pipeline, affected analysis, workspace dependency, publish strategy, monorepo structure, package boundary, workspace protocol, change detection, monorepo tooling
+---
+
+# Monorepo Management
+
+## When this skill activates
+
+This skill activates when setting up, restructuring, or optimizing a monorepo workspace. It applies to task orchestration, dependency management between packages, affected analysis for CI, publishing strategies, and enforcing package boundaries.
+
+## Mandatory actions when this skill is active
+
+### Before
+
+1. Identify the monorepo tool in use or to be adopted (Nx, Turborepo, Lerna, pnpm workspaces, Bazel).
+2. Map the dependency graph between packages (which packages depend on which).
+3. Determine the publishing model (unified versioning vs independent versioning).
+4. Assess current CI times and identify optimization opportunities.
+5. Review existing package boundaries (are internals leaking between packages?).
+
+### During
+
+**Tool Selection:**
+- **Nx**: Full-featured. Generators, dependency graph visualization, distributed task execution, plugins for frameworks. Best for large teams with complex dependency graphs.
+- **Turborepo**: Lightweight. Fast caching, simple pipeline config, minimal setup. Best for smaller monorepos or teams that want minimal tooling overhead.
+- **pnpm workspaces**: Package manager-level workspace support. Good foundation, pair with Turbo or Nx for task orchestration.
+- **Bazel**: Hermetic builds, language-agnostic, extreme scale. Steep learning curve. Best for very large codebases (1000+ packages).
+
+**Workspace Structure:**
+```
+/apps          — Deployable applications (web-app, api-server, mobile)
+/packages      — Shared libraries (ui-components, utils, types, config)
+/tools         — Build tools, scripts, generators, codemods
+/docs          — Documentation site (if applicable)
+```
+- Each package has its own `package.json`, `tsconfig.json`, and test config.
+- Shared config lives in root (ESLint, Prettier, TypeScript base config).
+- Apps import packages; packages never import apps.
+
+**Task Pipelines:**
+- Define build order from the dependency graph (if B depends on A, build A first).
+- Run independent tasks in parallel (lint all packages simultaneously).
+- Cache task outputs by input fingerprint (source files + deps + config).
+- Pipeline config example: `build` depends on `^build` (build deps first).
+
+**Affected Analysis:**
+- On PR: determine which packages changed (git diff against base branch).
+- Include transitive dependents (if `utils` changed, rebuild everything that imports `utils`).
+- Run only affected tests/builds/lints in CI to save time.
+- Full suite runs on merge to main (catch transitive issues).
+
+**Package Boundaries (Critical):**
+- Each package exports explicitly via `index.ts` or `exports` field in `package.json`.
+- NEVER import from internal paths (`@myorg/ui/src/internal/Button`). Only use public API.
+- Enforce with ESLint rules (`@nx/enforce-module-boundaries` or custom no-restricted-imports).
+- Circular dependencies between packages are FORBIDDEN. Detect with `madge` or Nx graph.
+- If two packages need each other, extract shared logic into a third package.
+
+**Caching Strategy:**
+- **Local cache**: Default. Store task outputs on developer machine (~/.turbo or .nx/cache).
+- **Remote cache**: Share cache across CI and team (Nx Cloud, Turborepo Remote Cache, custom S3).
+- **Fingerprint inputs**: source files, dependency versions, env vars, tool versions.
+- Cache hit = skip task entirely (return cached output in milliseconds).
+- Invalidate cache when: source changes, deps update, config changes, tool version bumps.
+
+**Publishing Strategy:**
+- **Changesets** (recommended): Developers declare changes in PRs, automated versioning on merge.
+- **Independent versioning**: Each package has its own semver. Publish only changed packages.
+- **Unified versioning**: All packages share one version number. Simpler but more publishes.
+- **Canary releases**: Publish from PR branches for pre-merge testing (`0.0.0-canary.abc123`).
+- Always publish from CI (never from local machines).
+
+**Dependency Management:**
+- Pin shared dependencies to same version across workspace (avoid version drift).
+- Use `pnpm` or `yarn` dedupe to eliminate duplicate installations.
+- Internal packages use `workspace:*` protocol (resolved at install, not publish).
+- External dependency updates: use Renovate/Dependabot with grouped PRs per scope.
+
+### After
+
+1. Dependency graph is acyclic and visualizable.
+2. Package boundaries are enforced (lint rule prevents deep imports).
+3. CI only runs affected tasks (measured improvement in pipeline time).
+4. Caching is configured and verified (cache hit rate > 70% on typical PRs).
+5. Publishing pipeline is automated and tested.
+
+## Self-check before task completion
+
+- [ ] Dependency graph has zero circular dependencies.
+- [ ] Package boundaries enforced via tooling (not just convention).
+- [ ] Task pipeline correctly orders builds based on dependency graph.
+- [ ] Affected analysis is configured for CI (not running everything on every PR).
+- [ ] Local and remote caching is operational with verified cache hits.
+- [ ] Publishing strategy is documented and automated.
+- [ ] New packages have a clear owner and explicit public API surface.
+- [ ] Workspace structure follows the apps/packages/tools convention.