mindforge-cc 10.0.2 → 10.7.0

package/.mindforge/skills/feature-flag-management/SKILL.md

@@ -0,0 +1,183 @@
+---
+name: feature-flag-management
+version: 1.0.0
+min_mindforge_version: 0.1.0
+status: stable
+triggers: feature flag, flag lifecycle, targeting rules, percentage rollout, kill switch, flag debt, openfeature, flag evaluation, flag cleanup, flag dependency, experiment flag, operational flag
+---
+
+# Skill — Feature Flag Management
+
+## When this skill activates
+Any task involving feature flag implementation, progressive rollouts, kill
+switches, flag lifecycle management, or flag debt cleanup.
+
+## Mandatory actions when this skill is active
+
+### Before writing any code
+1. Classify the flag type (release, experiment, operational, permission).
+2. Define the flag lifecycle including planned cleanup date.
+3. Determine targeting rules (who sees what).
+
+### During implementation
+- Set expiration date on every flag (max 90 days for release flags).
+- Implement clean fallback behavior for both flag states.
+- Use server-side evaluation for security-sensitive flags.
+
+### After implementation
+- Register flag in the flag inventory with owner and cleanup date.
+- Add monitoring for flag evaluation metrics.
+- Schedule cleanup task for after 100% rollout.
+
+## Flag Types
+
+### Release Flags
+- Purpose: ship code behind a flag, enable when ready.
+- Lifecycle: short-lived (days to weeks).
+- Example: `enable_new_checkout_flow`
+- Cleanup: remove after 100% rollout is stable (max 90 days).
+
+### Experiment Flags
+- Purpose: A/B testing with controlled variants.
+- Lifecycle: duration of experiment (2-8 weeks).
+- Example: `experiment_pricing_page_v2`
+- Cleanup: remove after experiment concludes and winner is chosen.
+
+### Operational Flags (Kill Switches)
+- Purpose: disable features under load or during incidents.
+- Lifecycle: permanent (always present in codebase).
+- Example: `kill_switch_recommendations_engine`
+- Cleanup: never — these are infrastructure.
+
+### Permission Flags (Entitlements)
+- Purpose: gate features by user plan/tier.
+- Lifecycle: permanent (tied to business model).
+- Example: `entitlement_advanced_analytics`
+- Cleanup: only when business model changes.
+
+## Flag Lifecycle
+
+```
+CREATE → DEVELOP → TEST → ROLLOUT → STABLE → CLEANUP
+```
+
+### Create
+- Register flag with name, type, owner, description, planned cleanup date.
+- Default state: OFF (new flags start disabled).
+
+### Develop
+- Code both paths (flag ON and flag OFF).
+- Both paths must be tested and functional.
+
+### Test
+- Enable in staging/QA environments.
+- Test both variants thoroughly.
+- Verify fallback behavior when flag service is unavailable.
+
+### Rollout
+- Progressive: 1% → 5% → 25% → 50% → 100%.
+- Monitor error rates and performance at each stage.
+- Hold at each percentage for minimum observation period.
+
+### Stable
+- Flag at 100% for > 7 days with no issues.
+- Old code path is dead code.
+
+### Cleanup
+- Remove flag evaluation from code.
+- Remove dead code path (the OFF variant).
+- Delete flag from management system.
+- Remove from flag inventory.
+
+## Targeting Rules
+
+### User Attributes
+```json
+{
+  "flag": "new_dashboard",
+  "rules": [
+    {"attribute": "plan", "operator": "in", "values": ["enterprise", "pro"]},
+    {"attribute": "country", "operator": "equals", "value": "US"}
+  ]
+}
+```
+
+### Segments
+- Define reusable user groups: "beta_users", "internal_team", "enterprise_customers".
+- Target flags at segments rather than individual attributes.
+- Segments update independently of flag rules.
+
+### Percentage Rollout
+- Hash user_id to determine bucket (consistent — same user always in same bucket).
+- Increase percentage gradually: 1% → 5% → 25% → 50% → 100%.
+- Sticky: user in 5% group stays in 25% group (no flip-flopping).
+
+### Geographic Targeting
+- Enable by region/country for compliance or staged global rollout.
+- Example: launch in US first, then EU, then APAC.
+
+## Flag Evaluation
+
+### Server-Side (Preferred for Security)
+- Flag evaluated on server, client receives result.
+- Source code and flag rules not exposed to client.
+- Use for: payment features, access control, security-sensitive logic.
+
+### Client-Side (Better Performance)
+- Flag rules sent to client, evaluated locally.
+- Faster (no network round-trip for each evaluation).
+- Use for: UI changes, non-sensitive features.
+- Risk: rules visible in client bundle.
+
+### Default Values
+- Always provide a sensible default if flag service is unreachable.
+- Release flags default to OFF (safe — old behavior).
+- Kill switches default to ON (safe — feature stays enabled).
+
+## Flag Debt Management
+
+### Indicators of Flag Debt
+- Flags older than 90 days still in codebase.
+- Flags at 100% rollout not cleaned up.
+- Nested flag dependencies (flag A depends on flag B).
+- Dead code paths that will never execute.
+
+### Prevention
+- Automated reminders: alert owner when flag exceeds planned cleanup date.
+- Flag inventory review: monthly audit of all active flags.
+- CI check: warn on PR if modifying code with expired flags.
+- Metric: track total active flag count as a health metric.
+
+### Cleanup Process
+1. Verify flag is at 100% and stable for > 7 days.
+2. Remove flag evaluation from code.
+3. Remove dead code path.
+4. Delete flag from management system.
+5. Update tests (remove flag-variant test cases).
+
+## OpenFeature (Vendor-Neutral Standard)
+
+### Why OpenFeature
+- Standard SDK interface regardless of flag provider.
+- Switch providers (LaunchDarkly, Flagsmith, custom) without code changes.
+- Community-driven specification with official SDKs.
+
+### Usage Pattern
+```typescript
+import { OpenFeature } from '@openfeature/js-sdk';
+
+const client = OpenFeature.getClient();
+const showNewUI = await client.getBooleanValue('new_ui', false, context);
+```
+
+## 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)
+- [ ] Does every flag have a type classification?
+- [ ] Does every release/experiment flag have a cleanup date?
+- [ ] Are both code paths (ON and OFF) tested?
+- [ ] Is there a sensible default for flag service unavailability?
+- [ ] Is the flag registered in the inventory with owner?
+- [ ] Is server-side evaluation used for security-sensitive flags?

package/.mindforge/skills/fine-tuning-workflow/SKILL.md

@@ -0,0 +1,189 @@
+---
+name: fine-tuning-workflow
+version: 1.0.0
+min_mindforge_version: 0.1.0
+status: stable
+triggers: fine tuning, dataset preparation, training config, eval during training, model deployment, model A/B test, LoRA adapter, training data quality, hyperparameter tuning, model versioning, training pipeline, fine tune evaluation
+---
+
+# Skill — Fine-Tuning Workflow
+
+## When this skill activates
+Any task involving LLM fine-tuning, training dataset preparation, LoRA/QLoRA
+adaptation, model evaluation during training, or model deployment with A/B testing.
+
+## Mandatory actions when this skill is active
+
+### Before writing any code
+1. Define the fine-tuning objective (style adaptation, domain knowledge, task specialization).
+2. Audit training data quality (deduplication, format consistency, bias check).
+3. Establish baseline metrics with the un-tuned model.
+
+### During implementation
+- Run evaluation on held-out validation set at regular intervals during training.
+- Implement early stopping on quality degradation.
+- Track training metrics: loss, eval metrics, learning rate schedule.
+
+### After implementation
+- Compare fine-tuned model against baseline on the eval suite.
+- Deploy with canary traffic (shadow or A/B testing).
+- Document the model card with training details and performance.
+
+## Dataset Preparation
+
+### Data Requirements by Objective
+| Objective | Min Examples | Quality Requirement |
+|-----------|-------------|-------------------|
+| Style/tone adaptation | 100-500 | High quality exemplars of target style |
+| Domain knowledge | 1,000-10,000 | Accurate, diverse domain Q&A pairs |
+| Task specialization | 500-5,000 | Varied task examples with edge cases |
+| Instruction following | 1,000+ | Diverse instruction/response pairs |
+
+### Data Format (Instruction Tuning)
+```jsonl
+{"messages": [
+  {"role": "system", "content": "You are a helpful coding assistant."},
+  {"role": "user", "content": "Write a function to reverse a string in Python."},
+  {"role": "assistant", "content": "def reverse_string(s: str) -> str:\n    return s[::-1]"}
+]}
+```
+
+### Data Quality Checklist
+- [ ] Deduplicated (no exact or near-duplicate examples).
+- [ ] Consistent format across all examples.
+- [ ] Balanced across categories/topics.
+- [ ] No PII or sensitive data (unless intentional and consented).
+- [ ] Correct and high-quality responses (garbage in = garbage out).
+- [ ] Diverse inputs (length, complexity, edge cases).
+
+### Data Cleaning Pipeline
+1. **Deduplication**: hash-based exact dedup + embedding-based semantic dedup.
+2. **Format validation**: ensure all examples match expected schema.
+3. **Quality filtering**: remove low-quality examples (too short, incoherent).
+4. **Balance check**: verify distribution across categories.
+5. **Contamination check**: ensure eval data not in training set.
+
+## Training Approaches
+
+### Full Fine-Tuning
+- Updates all model parameters.
+- Use for: significant behavior changes, large datasets.
+- Cost: high (full model in GPU memory, long training time).
+- Risk: catastrophic forgetting of base model capabilities.
+
+### LoRA (Low-Rank Adaptation)
+- Adds small trainable matrices alongside frozen base model.
+- Use for: most fine-tuning tasks (efficient, less forgetting).
+- Cost: low (only adapter weights in GPU memory).
+- Benefit: merge adapter with base model for zero-overhead inference.
+
+### QLoRA (Quantized LoRA)
+- Base model quantized to 4-bit, LoRA adapters in 16-bit.
+- Use for: large models on limited GPU memory.
+- Cost: very low (fits 70B model on single GPU for training).
+- Trade-off: slight quality reduction from quantization.
+
+### Key Hyperparameters
+| Parameter | Typical Range | Notes |
+|-----------|--------------|-------|
+| Learning rate | 1e-5 to 5e-5 | Lower for larger models |
+| Batch size | 4-32 | Larger = more stable, needs more memory |
+| Epochs | 1-5 | More epochs risk overfitting |
+| LoRA rank | 8-64 | Higher = more capacity, more compute |
+| LoRA alpha | 16-128 | Usually 2x rank |
+| Warmup steps | 5-10% of total | Prevents early divergence |
+
+## Evaluation During Training
+
+### Validation Set
+- Hold out 10-20% of data as validation (never train on it).
+- Evaluate every N steps (e.g., every 100 steps or every epoch).
+- Track: validation loss, task-specific metrics.
+
+### Early Stopping
+- Stop training if validation metric doesn't improve for N evaluations.
+- Prevents overfitting (model memorizes training data).
+- Save checkpoint at best validation score, not last step.
+
+### Evaluation Metrics
+| Metric | Use Case | What It Measures |
+|--------|----------|-----------------|
+| Perplexity | General quality | Model confidence on held-out data |
+| ROUGE-L | Summarization | Overlap with reference summaries |
+| Exact Match | Q&A, classification | Correct answer percentage |
+| Human preference | Style/quality | A/B comparison by annotators |
+| Task-specific | Custom tasks | Domain-specific correctness |
+
+## Model Deployment
+
+### Deployment Pipeline
+```
+Train → Evaluate → Register → Shadow Test → Canary → Full Rollout
+```
+
+### Model Registry
+- Version every model with: training data hash, hyperparameters, eval scores.
+- Store model artifacts in versioned storage (S3, GCS, MLflow).
+- Link to training run for full reproducibility.
+
+### Shadow Traffic Testing
+- Deploy new model alongside production model.
+- Route production traffic to both (only serve old model's response).
+- Compare outputs offline (quality, latency, error rate).
+- Promote to canary only if shadow results are satisfactory.
+
+### Canary Rollout
+- Route 5% of traffic to new model.
+- Monitor: quality metrics, latency p99, error rate, user feedback.
+- If metrics are good after 24-48 hours: increase to 25% → 50% → 100%.
+- Rollback instantly if any metric degrades.
+
+## A/B Testing
+
+### Experiment Design
+- Split users randomly (not requests — same user should see same model).
+- Define primary metric (quality score, user satisfaction, task completion).
+- Define guardrail metrics (latency, error rate, cost).
+- Run for statistical significance (typically 1-2 weeks).
+
+### Analysis
+- Compare primary metric between control (old model) and treatment (new model).
+- Verify guardrail metrics haven't degraded.
+- Check for segment effects (does new model help some users but hurt others?).
+- Document results and decision in model card.
+
+## Model Versioning (Model Card)
+
+```yaml
+model_card:
+  name: customer-support-assistant-v3
+  base_model: llama-3-8b
+  adapter: LoRA (rank 32)
+  training_data:
+    source: customer_support_conversations_2024
+    examples: 5,432
+    hash: sha256:def456...
+  hyperparameters:
+    learning_rate: 2e-5
+    epochs: 3
+    batch_size: 16
+    lora_rank: 32
+  evaluation:
+    held_out_accuracy: 0.89
+    human_preference_win_rate: 0.72
+    latency_p99_ms: 340
+  deployed_at: 2024-01-20
+  parent_version: customer-support-assistant-v2
+```
+
+## 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 training data deduplicated, validated, and quality-checked?
+- [ ] Is evaluation running on held-out validation set during training?
+- [ ] Is early stopping configured to prevent overfitting?
+- [ ] Are baseline metrics established for comparison?
+- [ ] Is the model versioned with full training lineage?
+- [ ] Is deployment using canary/A/B testing (not instant full rollout)?

package/.mindforge/skills/fintech-patterns/SKILL.md

@@ -0,0 +1,41 @@
+---
+name: fintech-patterns
+version: 1.0.0
+min_mindforge_version: 10.2.0
+status: stable
+triggers: fintech architecture, payment processing system, PCI-DSS compliance, double-entry ledger, financial reconciliation, KYC workflow, AML detection, transaction processing, financial regulation, banking integration, money movement, payment rail design
+compose: payment-integration
+---
+
+# Skill — Fintech Patterns
+
+## When this skill activates
+This skill activates when building payment processing systems, implementing double-entry accounting ledgers, handling financial transactions, integrating with banking APIs, ensuring PCI-DSS compliance, or implementing KYC/AML regulatory workflows.
+
+## Mandatory actions when this skill is active
+
+### Before writing any code
+1. Design ledger architecture using double-entry accounting principles: every transaction creates equal and opposite debits/credits, with immutable transaction logs, balance snapshots for performance, and idempotency keys to prevent duplicate charges
+2. Map regulatory compliance requirements: PCI-DSS scope (SAQ-A for payment gateway, SAQ-D for card storage), KYC verification levels (identity document, address proof, sanctions screening), AML transaction monitoring thresholds (structuring patterns, velocity checks, geographic risk)
+3. Document money movement flows with state machines: pending → authorized → captured → settled (for cards), initiated → processing → completed → reconciled (for ACH), with explicit rollback/refund paths and partial capture support
+
+### During implementation
+- Implement financial primitives with arbitrary-precision arithmetic: use Decimal types (never floats) for all monetary amounts, store values in smallest currency unit (cents/paise), handle currency conversion with mid-market rates and spread transparency
+- Build idempotent transaction endpoints: require client-generated idempotency keys (UUID v4), cache results for 24 hours, return identical response for duplicate requests (201 for first, 200 for subsequent), prevent phantom charges during network retries
+- Design ledger tables with append-only semantics: never UPDATE transaction records, use compensating transactions for corrections, store audit trail with user attribution, implement row-level checksums for tamper detection
+- Implement three-phase commit for distributed transactions: reserve funds (pessimistic lock), execute payment processing (call external API), commit or rollback based on response, with automatic retry logic for transient failures and dead letter queue for manual review
+- Enforce PCI-DSS compliance boundaries: tokenize card data immediately (Stripe/Adyen tokens), never log full PAN, redact card numbers in UI (show last 4 digits), use TLS 1.2+ for payment gateway communication, implement network segmentation between card data environment and application servers
+
+### After implementation
+- Execute financial reconciliation: match internal ledger balances against bank statements (daily), payment gateway settlement reports (batch ID reconciliation), and third-party wallet providers, with automated alerting for discrepancies >$10 or >0.1%
+- Validate transaction integrity: sum of all debits equals sum of all credits (ledger balance proof), account balance equals sum of transaction deltas (aggregate consistency check), no orphaned transactions without matching counterparty entries
+- Conduct security testing specific to financial systems: SQL injection in payment search, authorization bypass for fund transfers, race conditions in balance checks (concurrent withdrawals), replay attacks on payment endpoints, and IDOR vulnerabilities in transaction history APIs
+
+## Self-check before task completion
+- [ ] All monetary amounts use Decimal/BigDecimal types with explicit currency codes (ISO 4217), never floating-point arithmetic
+- [ ] Transaction endpoints are idempotent with client-provided idempotency keys, cached responses for duplicate requests
+- [ ] Ledger implements double-entry accounting with immutable transaction records, audit trails, and balance proof validation
+- [ ] PCI-DSS scope is minimized: no full card numbers stored, tokenization at payment entry point, encryption for sensitive data (AES-256-GCM)
+- [ ] KYC/AML workflows implemented: identity verification (document upload + liveness check), sanctions screening (OFAC/EU lists), transaction monitoring (velocity limits, geographic risk scoring)
+- [ ] Financial reconciliation automated: daily bank statement matching, payment gateway settlement verification, alerting for discrepancies
+- [ ] State machine transitions documented: pending → processing → settled → reconciled, with explicit rollback/refund paths and timeout handling

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

@@ -0,0 +1,42 @@
+---
+name: flutter-architecture
+version: 1.0.0
+min_mindforge_version: 10.4.0
+status: stable
+triggers: flutter architecture, widget composition pattern, flutter state management, platform channel flutter, dart design pattern, flutter navigation, flutter performance optimization, riverpod provider, flutter plugin development, flutter build runner, flutter layout pattern, flutter app architecture
+---
+
+# Skill — Flutter Architecture & Widget Composition
+
+## When this skill activates
+This skill activates when building Flutter applications, including widget composition strategies, state management implementation, platform channel integration, or establishing scalable app architecture patterns.
+
+## Mandatory actions when this skill is active
+
+### Before writing any code
+1. Choose state management approach based on app complexity (Riverpod for large apps, Provider for medium, setState for simple)
+2. Define navigation strategy (GoRouter for declarative routing, Navigator 2.0 for complex flows)
+3. Establish platform channel contracts for native functionality and document method signatures
+4. Plan widget composition hierarchy to maximize reusability and minimize rebuild scope
+
+### During implementation
+- Keep widget `build()` methods pure and deterministic — move side effects to lifecycle methods or controllers
+- Use `const` constructors wherever possible to enable widget caching and reduce rebuild overhead
+- Implement proper widget keys (GlobalKey, ValueKey, ObjectKey) for stateful widgets in lists
+- Leverage code generation (`build_runner`, `freezed`, `json_serializable`) for data models and state classes
+- Separate business logic from UI using repositories, services, and view models (MVVM pattern)
+- Use platform channels with proper codec (StandardMethodCodec, JSONMethodCodec) and error handling
+- Implement proper dispose() methods to prevent memory leaks in StatefulWidgets and controllers
+
+### After implementation
+- Run Flutter DevTools to profile widget rebuilds, identify expensive builds, and check memory usage
+- Test on both iOS and Android with platform-specific behaviors (back button, system gestures, status bar)
+- Verify hot reload works correctly — stateful widgets preserve state, providers remain intact
+- Check widget test coverage for critical UI logic and integration tests for user flows
+
+## Self-check before task completion
+- [ ] State management solution scales appropriately (no global setState, proper scoping of providers)
+- [ ] Platform channels include both method calls and event channels where needed, with proper error codes
+- [ ] Widget tree depth is reasonable (use composition over deep nesting, extract widgets strategically)
+- [ ] Build performance is acceptable (use `flutter run --profile` to measure frame rendering times)
+- [ ] Navigation handles back button, deep links, and state restoration correctly

package/.mindforge/skills/gaming-backend/SKILL.md

@@ -0,0 +1,41 @@
+---
+name: gaming-backend
+version: 1.0.0
+min_mindforge_version: 10.2.0
+status: stable
+triggers: gaming backend, multiplayer architecture, matchmaking system, game leaderboard, game state synchronization, anti-cheat system, virtual economy design, game server architecture, real-time gaming, player session management, game lobby system, competitive ranking
+compose: real-time-sync
+---
+
+# Skill — Gaming Backend
+
+## When this skill activates
+This skill activates when building real-time multiplayer game servers, matchmaking systems, leaderboards, game state synchronization, anti-cheat systems, virtual economies, player session management, or competitive ranking systems.
+
+## Mandatory actions when this skill is active
+
+### Before writing any code
+1. Design game state synchronization strategy: authoritative server architecture (server validates all actions), client-side prediction with server reconciliation, delta compression for bandwidth optimization, lag compensation (rewind time for hit detection), and tick rate optimization (60 Hz for fast-paced, 20 Hz for strategy)
+2. Model matchmaking algorithm: skill-based rating (ELO/Glicko-2), queue time vs match quality tradeoff, party/premade handling (avoid unfair team compositions), region-based latency constraints (<50ms preferred), and backfill logic for mid-game joins
+3. Map virtual economy flows: currency earn rates (gameplay rewards, daily login, achievements), sinks (cosmetics, upgrades, gacha), faucets (freemium currency), conversion ratios (premium to free currency), and anti-inflation mechanisms (decay, seasonal resets)
+
+### During implementation
+- Implement authoritative game server: validate all player inputs server-side (movement, attacks, item usage), reject impossible actions (speed hacks, teleportation), maintain canonical game state, broadcast state updates to clients at fixed tick rate, handle client disconnects gracefully (AI takeover or pause)
+- Build matchmaking queue system: players enter queue with skill rating and region preferences, matchmaker runs periodically (every 1-5 seconds), expands search criteria over time (relax skill range after 60s, add regions after 90s), create balanced teams (sum of ratings similar), reserve game server instance, notify players
+- Design leaderboard with efficient ranking: use Redis sorted sets (ZADD for score updates, ZREVRANK for rank lookup, ZREVRANGE for top-N), store composite score (wins, kills, time), implement seasonal resets with archival, handle ties deterministically (timestamp tiebreaker), support filtering by region/mode
+- Implement anti-cheat detection: server-side validation (impossible speeds, impossible accuracy), statistical anomaly detection (headshot rate >90%, reaction time <50ms), behavioral fingerprinting (mouse movement patterns), report system with manual review queue, automated bans for blatant cheats with appeal process
+- Build session management: player login creates session token (JWT with short expiry), heartbeat every 30s to maintain session, detect duplicates (kick old session), handle region transfers (migrate session to nearest server), graceful shutdown notifications (5 min warning before maintenance)
+
+### After implementation
+- Load test game servers under realistic conditions: spawn 1000+ concurrent bots with realistic behavior (movement, combat, chat), measure tick rate stability (should not drop below target), validate state synchronization (all clients see same events within latency bounds), identify performance bottlenecks (physics, pathfinding, network I/O)
+- Validate matchmaking quality metrics: measure average queue time (should be <60s for 80th percentile), skill disparity in matches (std dev of player ratings <200), match abandonment rate (<5% pre-game), and player retention after first match
+- Test anti-cheat effectiveness: attempt common exploits (speed hacks via Cheat Engine, aim bots, packet manipulation), verify server rejects invalid actions, check detection latency (should flag anomaly within 3 minutes), test false positive rate (<0.1% of legit players)
+
+## Self-check before task completion
+- [ ] Game server is authoritative: validates all player inputs, rejects impossible actions, maintains canonical state, uses lag compensation for hit detection
+- [ ] Matchmaking balances skill vs queue time: expands search criteria gradually, creates balanced teams, respects region/latency constraints
+- [ ] Leaderboard performs at scale: Redis sorted sets for O(log N) updates, supports millions of players, handles seasonal resets with archival
+- [ ] Anti-cheat detects common exploits: speed hacks, aim bots, statistical anomalies (headshot rate, reaction time), with manual review queue
+- [ ] Session management robust: heartbeat mechanism, duplicate detection, graceful disconnects, region transfer support
+- [ ] Virtual economy balanced: currency earn rates tuned, inflation controls (sinks match faucets), gacha odds transparent and compliant with regulations
+- [ ] Real-time performance meets targets: tick rate stable under load (60 Hz for action, 20 Hz for strategy), latency <100ms for 95th percentile players

package/.mindforge/skills/git-workflow-design/SKILL.md

@@ -0,0 +1,129 @@
+---
+name: git-workflow-design
+version: 1.0.0
+min_mindforge_version: 0.3.0
+status: stable
+triggers: git workflow design, trunk based development, gitflow, branch policy, merge strategy, squash vs rebase, commit standard, branch naming, release branch, hotfix workflow, protected branch, merge queue
+---
+
+# Skill — Git Workflow Design
+
+## When this skill activates
+Any task involving git branching strategies, merge policies, commit standards,
+release workflows, or repository governance.
+
+## Mandatory actions when this skill is active
+
+### Before recommending a workflow
+1. Assess team size and release cadence.
+2. Identify deployment model (continuous vs scheduled releases).
+3. Consider CI/CD maturity and test coverage levels.
+
+### Trunk-Based Development
+
+**Characteristics:**
+- Main branch is always deployable.
+- Short-lived feature branches (< 2 days).
+- CI runs on every commit to main.
+- Feature flags for incomplete work.
+
+**Best for:** small-to-medium teams, continuous deployment, high CI maturity.
+
+**Rules:**
+- Branch from main, merge back to main.
+- No long-lived branches (except main).
+- Feature flags decouple deploy from release.
+- Revert fast if main breaks — don't "fix forward" under pressure.
+
+### GitFlow
+
+**Characteristics:**
+- develop branch for integration.
+- release/* branches for stabilization.
+- hotfix/* branches from main for urgent fixes.
+- Longer release cycles (weekly/monthly).
+
+**Best for:** teams with scheduled releases, multiple versions in production, regulatory requirements.
+
+**Rules:**
+- Feature branches from develop.
+- Release branch cut when ready — only bug fixes after cut.
+- Hotfix from main, merge back to both main AND develop.
+- Tag every release on main.
+
+### Merge strategies
+
+**Squash merge:**
+- Produces clean, linear history on main.
+- One commit per PR — easy to revert entire features.
+- Loses granular commit history from the branch.
+- Best for: feature branches with messy/WIP commits.
+
+**Rebase merge:**
+- Linear history, preserves individual commits.
+- Requires clean, meaningful commits on the branch.
+- Best for: teams that enforce atomic commits.
+
+**Merge commit:**
+- Preserves branch topology (merge bubbles visible).
+- Easy to see "this group of commits was one PR."
+- Best for: teams that value traceability over linearity.
+
+### Branch naming conventions
+
+**Format:** `type/ticket-description`
+
+**Examples:**
+- `feat/PROJ-123-add-oauth-login`
+- `fix/PROJ-456-null-pointer-checkout`
+- `chore/upgrade-react-19`
+- `hotfix/payment-timeout`
+
+**Rules:**
+- Lowercase, hyphen-separated.
+- Include ticket number when applicable.
+- Keep descriptions short but meaningful.
+- No personal names or dates in branch names.
+
+### Protected branch rules
+
+- **Require pull request** — no direct pushes to main/develop.
+- **Require CI pass** — all status checks green before merge.
+- **Require review** — at least 1 approval (2 for critical paths).
+- **Require up-to-date branch** — must be rebased on latest main.
+- **Restrict force-push** — disabled on main, develop, release/*.
+- **Require signed commits** — for regulated environments.
+
+### Merge queue
+
+- Batches multiple approved PRs together.
+- Tests the combined result before merging.
+- Automatically reverts PRs that break the batch.
+- Prevents "works individually, breaks together" scenarios.
+- Available: GitHub merge queue, Mergify, Bors.
+
+### Commit standards
+
+**Conventional Commits format:**
+```
+type(scope): description
+
+[optional body]
+
+[optional footer]
+```
+
+**Types:** feat, fix, refactor, docs, test, chore, perf, ci, build, revert.
+
+**Rules:**
+- Subject line < 72 characters.
+- Imperative mood ("add" not "added").
+- Body explains WHY, not WHAT (the diff shows what).
+- Footer for breaking changes: `BREAKING CHANGE: description`.
+- Enforce with commitlint + husky pre-commit hook.
+
+## 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?