mindforge-cc 11.2.1 → 11.3.1

package/.agent/mindforge/evolve-skills.md

@@ -0,0 +1,49 @@
+---
+description: Review mature instincts and promote qualifying ones to full skills. Usage - /mindforge:evolve-skills [--dry-run] [--threshold 0.85] [--min-applications 5]
+---
+
+<objective>
+Scan the instinct store for entries that have proven themselves through repeated
+successful application, and promote them to full MindForge skills.
+</objective>
+
+<execution_context>
+@.mindforge/engine/instincts/promotion-engine.md
+@.mindforge/engine/instincts/instinct-schema.md
+@.mindforge/skills/continuous-learning/SKILL.md
+@.mindforge/org/skills/MANIFEST.md
+</execution_context>
+
+<context>
+$ARGUMENTS
+</context>
+
+<process>
+1. Parse flags: --dry-run (show candidates without acting), --threshold (confidence minimum, default 0.85), --min-applications (default 5).
+2. Read `.mindforge/engine/instincts/instinct-store.jsonl`.
+3. **Identify candidates** meeting ALL criteria:
+   - confidence >= threshold
+   - times_applied >= min-applications
+   - times_succeeded >= 80% of times_applied
+   - status == "active"
+   - No existing skill covers same behavior (check MANIFEST.md triggers)
+4. **Rank candidates** by impact score: confidence * times_applied.
+5. **Present candidates** to user:
+   ```
+   Promotion Candidates (ranked by impact):
+   1. [observation] — confidence: 0.92, applied: 12x, success: 11/12
+   2. [observation] — confidence: 0.88, applied: 7x, success: 6/7
+   ```
+6. If --dry-run: stop here, report what would be promoted.
+7. **For each approved candidate:**
+   a. Generate SKILL.md draft:
+      - name: derived from instinct tags
+      - triggers: derived from observation keywords
+      - content: expanded from behavior field
+   b. Create `.mindforge/skills/[name]/SKILL.md`
+   c. Add entry to MANIFEST.md (Project tier by default)
+   d. Mark instinct as promoted: `"status": "promoted", "promoted_to_skill": "[name]"`
+8. Report: "Promoted [N] instincts to skills. New skills: [list]."
+9. Log in AUDIT: skill_promoted events with instinct_id and skill_name.
+10. Remind: "Monitor promoted skills — if they prove unhelpful, they can be reverted."
+</process>

package/.agent/mindforge/execute-phase.md

@@ -0,0 +1,200 @@
+---
+description: 1. Read STATE.md — confirm phase [N] is in "planned" status.
+---
+
+# MindForge — Execute Phase Command
+# Usage: /mindforge:execute-phase [N]
+
+## Pre-checks (all must pass before execution starts)
+
+1. Read STATE.md — confirm phase [N] is in "planned" status.
+   If STATE.md shows phase [N] as already "complete": ask user to confirm re-execution.
+
+2. Verify plan files exist:
+   ```
+   .planning/phases/[N]/PLAN-[N]-01.md   (minimum one plan required)
+   ```
+   If missing: stop. Tell user: "No plans found for Phase [N]. Run /mindforge:plan-phase [N] first."
+
+3. Verify REQUIREMENTS.md exists and has content.
+   If empty: warn user but allow continuation.
+
+4. Run the dependency parser (`.mindforge/engine/dependency-parser.md`).
+   If validation fails (circular deps, missing deps): stop and report. Do not execute.
+
+## Step 1 — Build and display the execution plan
+
+After dependency parsing succeeds, display the wave plan to the user:
+
+```
+Phase [N] Execution Plan
+━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
+
+  Wave 1 (parallel)     Wave 2 (parallel)     Wave 3
+  ┌─────────────┐       ┌─────────────┐       ┌─────────────┐
+  │ Plan 01     │       │ Plan 03     │       │ Plan 05     │
+  │ User model  │──┐    │ User API    │──┐    │ Checkout UI │
+  └─────────────┘  │    └─────────────┘  │    └─────────────┘
+  ┌─────────────┐  │    ┌─────────────┐  │
+  │ Plan 02     │──┘    │ Plan 04     │──┘
+  │ Product     │       │ Product API │
+  └─────────────┘       └─────────────┘
+
+  Total tasks: 5    Waves: 3    Est. time: depends on model speed
+
+Proceed? (yes/no)
+```
+
+If the user says no: stop. Do not execute anything.
+
+## Step 2 — Write pre-execution audit entry
+
+Append to `.planning/AUDIT.jsonl`:
+```json
+{
+  "id": "[uuid-v4]",
+  "timestamp": "[ISO-8601]",
+  "event": "phase_execution_started",
+  "phase": [N],
+  "wave_count": [total waves],
+  "task_count": [total tasks],
+  "agent": "mindforge-orchestrator",
+  "session_id": "[session identifier]"
+}
+```
+
+## Step 3 — Execute waves using the wave executor
+
+Follow the complete protocol in `.mindforge/engine/wave-executor.md`.
+
+For each wave:
+
+### Wave start
+Write to console:
+```
+━━━ Wave [W] of [total] ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
+  Starting [X] tasks in parallel...
+```
+
+### Per-task execution (inject context per `context-injector.md`)
+For each plan in the wave:
+1. Load context package (per `context-injector.md`)
+2. Execute the plan instructions
+   - Run `<verify>` — capture exact output
+   - If verify PASSES:
+     - Run `<verify-visual>` via `visual-verify-executor.js`
+     - If visual verify FAILS: stop and report (treat as verify failure)
+     - Write SUMMARY-[N]-[M].md
+   - Execute commit: `git add [files] && git commit -m "[type]([scope]): [task name]"`
+   - Capture git SHA
+   - Write AUDIT entry for task completion
+5. If verify FAILS:
+   - Write SUMMARY-[N]-[M].md with failure details
+   - Write AUDIT entry for task failure
+   - STOP this wave immediately
+   - Report: "Task [plan ID] failed: [verify output]. Stopping Phase [N]."
+   - Do not start next wave
+   - Ask user: "Spawn debug agent to diagnose? (yes/no)"
+
+### Wave completion (before starting next wave)
+After all tasks in wave complete:
+1. Run: `[project test command]`
+2. If tests fail:
+   - Identify failing tests
+   - Run `git log --oneline -[wave-task-count]` to see wave commits
+   - Report which commit likely introduced the failure
+   - Stop. Ask user how to proceed.
+3. If tests pass:
+   - Report: "Wave [W] complete. All [X] tasks passed. Tests passing. ✅"
+   - Run `/mindforge:record-learning` if any architectural "Aha!" moments or significant anti-patterns were discovered during this wave.
+   - Write WAVE-REPORT update
+
+## Step 4 — Phase-level verification
+
+After all waves complete, run the verification pipeline:
+
+1. Read every v1 requirement from REQUIREMENTS.md for this phase
+2. For each requirement, verify it is implemented:
+   - Search the codebase for the implementation
+   - Check if a test covers it
+   - Mark: ✅ implemented + tested | ⚠️ implemented, no test | ❌ not found
+3. Write `.planning/phases/[N]/VERIFICATION.md`
+4. Run the full test suite one final time
+5. If any requirement is ❌: create a fix plan and report to user
+
+## Step 5 — Update state and write wave report
+
+Write `.planning/phases/[N]/WAVE-REPORT-[N].md` (per template in wave-executor.md)
+
+Update STATE.md:
+```markdown
+## Current phase
+[N] — Execution complete ✅
+
+## Last completed task
+Phase [N]: All [X] tasks completed across [W] waves.
+
+## Next action
+Run /mindforge:verify-phase [N] for human acceptance testing.
+```
+
+Update HANDOFF.json with completed phase info.
+
+## Step 5.1 — Final Intelligence Sync
+1. Read `AGENTS_LEARNING.md` one last time.
+2. Run `/mindforge:record-learning` to capture the final phase-level learnings (Mistakes discovered during UAT, architectural refinements).
+3. Commit `AGENTS_LEARNING.md` if updated.
+
+Write final AUDIT entry:
+```json
+{
+  "id": "[uuid-v4]",
+  "timestamp": "[ISO-8601]",
+  "event": "phase_execution_completed",
+  "phase": [N],
+  "tasks_completed": [X],
+  "waves_executed": [W],
+  "commits": ["sha1", "sha2", "..."],
+  "test_result": "passing",
+  "agent": "mindforge-orchestrator"
+}
+```
+
+## Step 6 — Report to user
+
+```
+━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
+✅ Phase [N] execution complete
+
+  Tasks completed : [X] / [X]
+  Waves executed  : [W]
+  Commits made    : [X]
+  Tests           : All passing
+  Requirements    : [X] / [X] implemented
+
+Next step: Run /mindforge:verify-phase [N] for UAT sign-off.
+━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
+
+## Step 7 — Auto-capture check (when AUTO_CAPTURE_SKILLS=true)
+
+After all gates pass and the phase is verified:
+
+```bash
+# Check if auto-capture is enabled
+CAPTURE=$(grep -m1 "^AUTO_CAPTURE_SKILLS=" MINDFORGE.md 2>/dev/null | cut -d= -f2 | tr -d ' ')
+if [ "$CAPTURE" = "true" ]; then
+  node -e "
+    const { detectPatterns, formatForPresentation } = require('./bin/skills-builder/pattern-detector');
+    detectPatterns(${PHASE_NUM}).then(result => {
+      const display = formatForPresentation(result);
+      console.log(display);
+    }).catch(err => console.error('[auto-capture] Error:', err.message));
+  "
+fi
+```
+
+If patterns are found: display the prompt and await user input.
+If user selects yes: run `/mindforge:learn --session` targeting this phase's SUMMARY files.
+If user selects no: write AUDIT entry `auto_capture_skipped` and continue.
+If no patterns found: exit silently (no noise in the output).
+```

package/.agent/mindforge/experiment.md

@@ -0,0 +1,28 @@
+---
+description: "Design A/B test with statistical rigor. Usage: /mindforge:experiment [feature] [--metric conversion|engagement|revenue] [--duration 2w]"
+---
+
+<objective>
+Design a statistically rigorous A/B experiment with proper hypothesis formation, sample size calculation, guardrail metrics, and pre-registered decision rules to avoid p-hacking and ensure valid conclusions.
+</objective>
+
+<execution_context>
+@.mindforge/skills/experiment-design/SKILL.md
+</execution_context>
+
+<context>
+Arguments: $ARGUMENTS (feature or change being tested, optional --metric, optional --duration)
+Knowledge: Current baseline metrics, traffic volume, previous experiment results, business goals.
+</context>
+
+<process>
+1. **Form Hypothesis**: Write a falsifiable hypothesis in the format: "If we [change X], then [metric Y] will [increase/decrease] by [minimum detectable effect Z%], because [theory]." Distinguish between exploratory and confirmatory experiments.
+2. **Define Primary Metric and Guardrails**: Select one primary metric (the decision metric) and 2-4 guardrail metrics that must not degrade. Define what "degradation" means quantitatively for each guardrail.
+3. **Calculate Required Sample Size**: Using baseline conversion rate, minimum detectable effect, significance level (default alpha=0.05), and power (default 0.8), calculate the required sample size per variant. Account for multiple comparisons if testing more than 2 variants.
+4. **Choose Randomization Unit**: Select the randomization unit (user, session, device, organization). Consider: consistency of experience, network effects, and statistical independence. Document why.
+5. **Set Experiment Duration**: Run for at least 1 full business cycle (typically 1-2 weeks minimum). Account for day-of-week effects, novelty effects, and learning effects. Never peek at results before predetermined end date.
+6. **Design Variants**: Define control and treatment(s) precisely. Document the exact user experience for each variant. Ensure only one variable changes between variants (isolation).
+7. **Configure Analysis Plan**: Pre-register the statistical test (t-test, chi-squared, Mann-Whitney), correction method for multiple comparisons (Bonferroni, Holm), and segmentation plan. Document before launching.
+8. **Define Success Criteria**: Specify the exact threshold for shipping: primary metric improvement is statistically significant AND guardrails are not violated AND practical significance (effect size) justifies the complexity.
+9. **Document Decision Rules**: Pre-commit to outcomes: if significant positive = ship; if significant negative = kill; if inconclusive = extend duration or iterate on treatment. Define "inconclusive" precisely.
+</process>

package/.agent/mindforge/feature-flags.md

@@ -0,0 +1,30 @@
+---
+description: Design feature flag strategy with lifecycle management. Usage - /mindforge:feature-flags [feature] [--type release|experiment|operational] [--rollout 5%]
+---
+
+<objective>
+Design a feature flag strategy with full lifecycle management — from creation
+through gradual rollout to cleanup. Covers flag typing, targeting rules,
+kill switches, success metrics, and mandatory flag removal deadlines.
+</objective>
+
+<execution_context>
+@.mindforge/skills/feature-flag-management/SKILL.md
+</execution_context>
+
+<context>
+$ARGUMENTS
+</context>
+
+<process>
+1. Classify the flag type based on --type flag: release (temporary, gates incomplete feature, remove after launch), experiment (A/B test with metrics, remove after decision), or operational (long-lived, controls system behavior like rate limits or circuit breakers).
+2. Define targeting rules: percentage rollout (--rollout flag), user segment targeting (beta users, internal, enterprise), geographic targeting, or device/platform targeting. Use consistent hashing on user ID for sticky assignment.
+3. Set the rollout percentage and define the rollout plan: 5% (canary) -> 25% (early adopters) -> 50% (half) -> 100% (GA). Define success criteria for each stage gate (error rate, latency, business metrics).
+4. Configure kill switch: every flag must have an emergency off switch that immediately disables the feature for all users. Kill switch activation should not require a deploy — remote config only.
+5. Define success metrics that determine whether the flag should be fully enabled or rolled back: conversion rate, error rate delta, latency impact, user engagement, and business KPIs specific to the feature.
+6. Set cleanup deadline: release flags must be removed within 90 days of 100% rollout. Experiment flags within 30 days of decision. Create a tracking ticket for flag removal at flag creation time.
+7. Implement flag evaluation in code: use SDK with local caching (no network call per evaluation), provide sensible defaults for SDK initialization failure, and log flag evaluations for debugging.
+8. Plan flag removal process: remove flag check from code, remove flag from configuration, verify no references remain (grep), and deploy. Ensure removal is atomic (single PR, not split across deploys).
+9. Set up flag hygiene tooling: dashboard showing all active flags with age, lint rules that warn on flags past deadline, automated Slack notifications for stale flags, and quarterly flag audit.
+10. Log feature-flags invocation in AUDIT with: feature name, flag type, initial rollout percentage, cleanup deadline, targeting rules.
+</process>

package/.agent/mindforge/feature-store.md

@@ -0,0 +1,31 @@
+---
+name: mindforge:feature-store
+description: "Design ML feature store. Usage: /mindforge:feature-store [domain] [--store feast|tecton|vertex] [--type batch|realtime|both]"
+argument-hint: "[domain] [--store feast|tecton|vertex] [--type batch|realtime|both]"
+allowed-tools:
+  - list_dir
+  - view_file
+---
+
+<objective>
+Design comprehensive feature-store system architecture.
+</objective>
+
+<execution_context>
+@.mindforge/skills/ml-feature-store/SKILL.md
+</execution_context>
+
+<context>
+Skills Directory: `.mindforge/skills/ml-feature-store/`
+State: Analyzes requirements and constraints to generate feature-store architecture.
+</context>
+
+<process>
+1. **Requirement Analysis**: Analyze domain-specific requirements and constraints.
+2. **Architecture Design**: Design scalable system architecture with best practices.
+3. **Component Selection**: Select appropriate technologies and tools for implementation.
+4. **Integration Strategy**: Define integration patterns with existing systems.
+5. **Optimization Approach**: Implement performance and cost optimization strategies.
+6. **Monitoring Framework**: Design observability and alerting mechanisms.
+7. **Deployment Planning**: Create deployment strategy with rollback procedures.
+</process>

package/.agent/mindforge/finops.md

@@ -0,0 +1,31 @@
+---
+description: Estimate and optimize cloud infrastructure costs. Usage - /mindforge:finops [service] [--forecast 6m] [--target-savings 20%]
+---
+
+<objective>
+Estimate current cloud infrastructure costs, identify optimization opportunities,
+model cost reduction alternatives, and create an actionable implementation plan
+that achieves the target savings percentage without degrading service reliability
+or performance within the forecast period.
+</objective>
+
+<execution_context>
+@.mindforge/skills/cost-estimation/SKILL.md
+</execution_context>
+
+<context>
+$ARGUMENTS
+</context>
+
+<process>
+1. Inventory current resources by category: compute (instances, containers, serverless), storage (block, object, database), network (egress, load balancers, CDN), and managed services (queues, caches, search). Tag each with monthly cost and owner team.
+2. Measure utilization for each resource: CPU average/peak, memory average/peak, storage used vs provisioned, network bandwidth vs capacity. Flag resources with average utilization below 30% as candidates for right-sizing.
+3. Identify waste across categories: unused resources (no traffic for 7+ days), oversized instances (peak utilization < 50% of capacity), idle load balancers, unattached volumes, orphaned snapshots, and over-provisioned databases.
+4. Model cost alternatives based on --target-savings: reserved instances (1yr/3yr commitment for steady-state), spot/preemptible for fault-tolerant workloads, smaller instance families, ARM-based options, and serverless conversion for spiky workloads. Calculate break-even for each.
+5. Estimate savings per optimization: calculate monthly/annual savings, implementation effort (hours), risk level (low/medium/high), and payback period. Rank by savings-to-effort ratio.
+6. Create implementation plan with phases: Phase 1 (quick wins, <1 day, no risk), Phase 2 (right-sizing, 1 week, low risk), Phase 3 (architectural changes, 1 month, medium risk). Include rollback plan for each phase.
+7. Set up cost alerts and budgets: configure alerts at 80%/100%/120% of monthly budget, per-team cost allocation tags, anomaly detection for unexpected spikes (>20% day-over-day), and weekly cost reports to stakeholders.
+8. Track reduction over --forecast period: establish baseline month, measure actual vs projected savings, identify new cost growth areas, and adjust plan quarterly. Report ROI of optimization effort (hours saved in cost / hours invested).
+9. Design cost governance policies: mandatory resource tagging, auto-shutdown for dev/staging outside business hours, maximum instance size without approval, and reserved instance utilization monitoring.
+10. Log FinOps analysis in AUDIT with: service, current monthly cost, identified savings, target savings percentage, implementation phases, and forecast period.
+</process>

package/.agent/mindforge/fintech.md

@@ -0,0 +1,31 @@
+---
+name: mindforge:fintech
+description: "Design fintech payment/ledger architecture. Usage: /mindforge:fintech [service] [--domain payments|ledger|kyc] [--compliance pci|sox]"
+argument-hint: "[service] [--domain payments|ledger|kyc] [--compliance pci|sox]"
+allowed-tools:
+  - list_dir
+  - view_file
+---
+
+<objective>
+Designs secure, compliant fintech architectures for payment processing, double-entry ledgers, and KYC/AML systems. Produces PCI-DSS and SOX-compliant designs with idempotency guarantees, audit trails, and fraud detection patterns for financial service applications.
+</objective>
+
+<execution_context>
+@.mindforge/skills/fintech-patterns/SKILL.md
+</execution_context>
+
+<context>
+Skills Directory: `.mindforge/skills/fintech-patterns/`
+State: Evaluates fintech service requirements, compliance domains (PCI-DSS, SOX, KYC/AML), and produces architectures with transaction integrity, idempotency, reconciliation, and fraud prevention mechanisms.
+</context>
+
+<process>
+1. **Domain Analysis**: Identify fintech domain (payment gateway, ledger system, KYC verification, lending platform) and classify transaction types, monetary precision requirements, and regulatory scope.
+2. **Compliance Framework**: Map compliance requirements (PCI-DSS SAQ levels, SOX control objectives, KYC/AML screening) to architectural layers and define cardholder data environments, change control procedures, and audit evidence collection.
+3. **Transaction Architecture**: Design idempotent transaction processing with unique transaction IDs, state machines for payment flows (authorized → captured → settled), and distributed transaction patterns (Saga, 2PC) with compensation logic.
+4. **Ledger Design**: Implement double-entry bookkeeping with immutable transaction logs, account balance reconciliation, and temporal consistency guarantees using event sourcing or append-only ledgers.
+5. **Security Controls**: Define tokenization for card data, encryption key hierarchies, secure key storage (HSM), mTLS for inter-service communication, and fraud detection rules (velocity checks, geolocation, device fingerprinting).
+6. **Reconciliation Pipeline**: Design automated reconciliation workflows comparing internal ledger against external payment processors, bank statements, and third-party APIs with alerting for discrepancies.
+7. **Audit and Reporting**: Generate immutable audit logs for all financial transactions, access to sensitive data, and configuration changes with compliance report generation (PCI quarterly scans, SOX control testing evidence).
+</process>

package/.agent/mindforge/flutter.md

@@ -0,0 +1,37 @@
+---
+name: mindforge:flutter
+description: "Flutter architecture and pattern guidance. Usage: /mindforge:flutter [feature] [--state riverpod|bloc|provider]"
+argument-hint: "[feature] [--state riverpod|bloc|provider]"
+allowed-tools:
+  - list_dir
+  - view_file
+---
+
+<objective>
+Design Flutter applications using BLoC or Riverpod patterns with platform channels for native integration, optimized widget trees, and Dart-native performance.
+</objective>
+
+<execution_context>
+@.mindforge/skills/flutter-architecture/SKILL.md
+</execution_context>
+
+<context>
+Skills Directory: `.mindforge/skills/flutter-architecture/`
+State: Recommends state management approach, widget composition patterns, platform channel design, and Flutter-specific performance optimizations.
+</context>
+
+<process>
+1. **State Management**: Riverpod 2.0 → type-safe, compile-time DI, async support, testing-friendly (recommended). BLoC → event-driven, good for complex flows, reactive streams. Provider → simple but verbose, being phased out. GetX → avoid (too much magic, hard to debug).
+
+2. **Widget Architecture**: Composition over inheritance. Extract reusable widgets. Use const constructors (performance win). Separate stateful logic from UI. Keys for list performance. Avoid deep widget trees (>10 levels).
+
+3. **Platform Channels**: Method channels for one-time calls. Event channels for streams. Use pigeon for type-safe codegen. Handle threading (iOS main thread requirement). Implement proper error handling across boundary.
+
+4. **Performance**: Use ListView.builder (lazy loading). DevTools for widget rebuild analysis. Avoid setState in loops. Use RepaintBoundary strategically. Profile with Observatory. Target 60fps (120fps on ProMotion).
+
+5. **Code Generation**: Freezed for immutable models. json_serializable for JSON parsing. built_value for value objects. auto_route for type-safe navigation. Run build_runner watch during development.
+
+6. **Testing**: Unit tests (business logic). Widget tests (UI components). Integration tests (full app flows). Golden tests (pixel-perfect UI). Mock platform channels. Aim for >80% coverage.
+
+7. **Release**: Obfuscate Dart code. Minimize app size (tree-shaking, deferred loading). Configure ProGuard rules. Test on min SDK version. Set up code push (Shorebird) for hotfixes.
+</process>

package/.agent/mindforge/gaming.md

@@ -0,0 +1,31 @@
+---
+name: mindforge:gaming
+description: "Design gaming backend architecture. Usage: /mindforge:gaming [feature] [--mode realtime|turn-based] [--scale small|massive]"
+argument-hint: "[feature] [--mode realtime|turn-based] [--scale small|massive]"
+allowed-tools:
+  - list_dir
+  - view_file
+---
+
+<objective>
+Designs high-performance gaming backend architectures for real-time multiplayer, turn-based games, and massively multiplayer systems. Produces designs for matchmaking, game state synchronization, leaderboards, anti-cheat systems, and live operations with low-latency requirements.
+</objective>
+
+<execution_context>
+@.mindforge/skills/gaming-backend/SKILL.md
+</execution_context>
+
+<context>
+Skills Directory: `.mindforge/skills/gaming-backend/`
+State: Evaluates game type, player concurrency requirements, and produces architecture with real-time communication (WebSocket/UDP), state synchronization, matchmaking algorithms, and operational analytics for live games.
+</context>
+
+<process>
+1. **Game Type Analysis**: Classify game mode (real-time shooter/MOBA, turn-based strategy, MMO, battle royale) and define latency requirements (<50ms for FPS, <200ms for turn-based), player concurrency (10s, 100s, 10000s), and session duration patterns.
+2. **Network Architecture**: Design network topology with dedicated game servers vs P2P hybrid, protocol selection (WebSocket for web, UDP for mobile/console), regional server distribution for latency optimization, and client-side prediction with server reconciliation.
+3. **Matchmaking System**: Implement matchmaking algorithms (skill-based rating like ELO/TrueSkill, latency-based region matching), queue management with backfill for in-progress games, and party system for group matchmaking with balanced team composition.
+4. **Game State Management**: Design authoritative server architecture with client input validation, tick-based simulation loops, state synchronization patterns (full snapshots, delta compression, interest management for MMOs), and cheat prevention with server-side validation.
+5. **Persistence Layer**: Architect player data storage (progression, inventory, achievements) with eventually consistent writes, caching for frequently accessed data (player profiles, loadouts), and leaderboard systems using sorted sets (Redis) or time-series databases.
+6. **Live Operations**: Implement event systems for limited-time challenges, A/B testing frameworks for game balance tuning, analytics pipelines for player behavior tracking (retention, engagement, monetization), and operational dashboards for server health monitoring.
+7. **Scalability Patterns**: Design horizontal scaling for game servers with auto-scaling based on player concurrency, stateful server migration for maintenance windows, database sharding by player ID or region, and CDN distribution for game assets and patches.
+</process>

package/.agent/mindforge/graphql.md

@@ -0,0 +1,31 @@
+---
+description: Design GraphQL schema and resolver architecture. Usage - /mindforge:graphql [domain] [--style code-first|schema-first] [--federation]
+---
+
+<objective>
+Design a GraphQL schema and resolver architecture that models the domain
+accurately, prevents N+1 queries via DataLoader, implements cursor-based
+pagination for all lists, and provides production-ready configuration with
+persisted queries, depth limiting, and cost analysis.
+</objective>
+
+<execution_context>
+@.mindforge/skills/graphql-patterns/SKILL.md
+</execution_context>
+
+<context>
+$ARGUMENTS
+</context>
+
+<process>
+1. Identify domain entities and their relationships: map core types (User, Order, Product), their fields, and connections between them (User has many Orders, Order has many LineItems). Determine which relationships are required vs optional, and identify aggregate roots.
+2. Design the type schema based on --style flag: code-first (TypeGraphQL/Nexus — types generated from code, better for rapid iteration) or schema-first (SDL files — explicit contract, better for API-first design). Follow naming conventions: PascalCase for types, camelCase for fields.
+3. Implement connections for all list fields using cursor-based pagination: define Connection/Edge/PageInfo types per Relay spec, use opaque cursors (base64-encoded id or timestamp), support first/after and last/before arguments, and include totalCount as optional expensive field.
+4. Add DataLoader for ALL nested resolvers to prevent N+1 queries: create one DataLoader per entity type per request (request-scoped), batch all IDs collected in a single event loop tick, implement caching within request lifecycle, and verify with query logging that batch queries fire.
+5. Design mutations with input types and meaningful returns: use Input suffix for mutation arguments (CreateUserInput), return the modified entity (not just ID), include userErrors field for domain validation errors (separate from GraphQL errors), and make mutations as specific as possible (updateUserEmail vs generic updateUser).
+6. Configure subscriptions if real-time is needed: use WebSocket transport (graphql-ws protocol), implement subscription resolvers with pub/sub backend (Redis), filter events per subscriber (only receive own tenant's events), and handle connection lifecycle (keepalive, reconnection).
+7. Set up persisted queries for production: extract all queries at build time into a query map (hash -> query text), reject arbitrary queries in production (allowlist mode), reduce bandwidth (client sends hash instead of full query), and prevent malicious query injection.
+8. Implement security and performance guards: query depth limiting (max 7 levels), query cost analysis (assign cost to each field/connection), rate limiting per operation complexity, disable introspection in production, and field-level authorization directives.
+9. Configure federation if --federation flag set: identify subgraph boundaries (one per domain team), define entity types with @key directives, implement reference resolvers for cross-subgraph lookups, and configure the gateway (Apollo Router or similar).
+10. Log GraphQL design in AUDIT with: domain entities, schema style, pagination approach, DataLoader coverage, subscription needs, persisted query strategy, and federation topology.
+</process>

package/.agent/mindforge/health.md

@@ -0,0 +1,31 @@
+---
+description: Run all seven health-engine categories from .mindforge/intelligence/health-engine.md.
+---
+
+# MindForge — Health Command
+# Usage: /mindforge:health [--repair] [--category C] [--verbose]
+
+Run all seven health-engine categories from `.mindforge/intelligence/health-engine.md`.
+
+## Output
+- category status summary
+- errors (must fix)
+- warnings (should fix)
+- informational signals
+
+## Sovereign Intelligence Checks (v6.2.0-alpha)
+- **PQAS Verification**: Check `bin/governance/quantum-crypto.js` presence
+- **Homing Verification**: Check `bin/autonomous/intent-harvester.js` presence
+- **Self-Healer Verification**: Check `bin/autonomous/mesh-self-healer.js` presence
+- **Policy Check**: Verify `bin/governance/policy-engine.js` is Sovereign-configured
+
+## Flags
+- `--repair`: apply safe auto-repair only
+- `--category`: one of `installation|context|skills|personas|state|integrations|security`
+- `--verbose`: include passing checks and exact inspected values
+
+## AUDIT
+Append:
+```json
+{ "event": "health_check_completed", "errors": 0, "warnings": 0, "repaired": 0 }
+```

package/.agent/mindforge/healthcare.md

@@ -0,0 +1,31 @@
+---
+name: mindforge:healthcare
+description: "Design HIPAA-compliant healthcare system architecture. Usage: /mindforge:healthcare [service] [--standard hipaa|hl7|fhir] [--scope full|audit]"
+argument-hint: "[service] [--standard hipaa|hl7|fhir] [--scope full|audit]"
+allowed-tools:
+  - list_dir
+  - view_file
+---
+
+<objective>
+Designs HIPAA-compliant healthcare system architectures with proper PHI handling, audit trails, and regulatory compliance. Produces architecture diagrams, data flow models, and compliance checklists for healthcare applications including EHR, telemedicine, patient portals, and health data exchanges.
+</objective>
+
+<execution_context>
+@.mindforge/skills/healthcare-systems/SKILL.md
+</execution_context>
+
+<context>
+Skills Directory: `.mindforge/skills/healthcare-systems/`
+State: Evaluates healthcare service requirements, compliance standards (HIPAA, HL7, FHIR), and produces compliant architecture with security controls, encryption strategies, and audit mechanisms.
+</context>
+
+<process>
+1. **Service Analysis**: Parse the healthcare service type (EHR, telemedicine, patient portal, HIE) and identify PHI touchpoints, user roles, and data sensitivity classification.
+2. **Compliance Mapping**: Map required compliance standards (HIPAA Security/Privacy Rules, HL7 messaging, FHIR resources) to architectural components and identify technical safeguards (encryption at rest/in transit, access controls, audit logs).
+3. **Architecture Design**: Design system architecture with secure zones (DMZ, application tier, data tier), authentication/authorization flows (RBAC, ABAC), and PHI access patterns with minimum necessary principle.
+4. **Data Flow Modeling**: Model PHI data flows across system boundaries, external integrations (labs, pharmacies, insurance), and patient data exchange patterns with encryption and consent management.
+5. **Audit Trail Design**: Design comprehensive audit logging for all PHI access (who, what, when, where, why), tamper-proof log storage, and automated compliance reporting mechanisms.
+6. **Security Controls**: Define encryption standards (AES-256, TLS 1.3), key management (HSM, KMS), session management, and incident response procedures for breach notification.
+7. **Documentation Generation**: Generate compliance documentation including Security Risk Assessment, BAA requirements, technical safeguards matrix, and architecture decision records for regulatory audits.
+</process>

package/.agent/mindforge/help.md

@@ -0,0 +1,33 @@
+---
+description: Show all available MindForge commands.
+---
+
+Show all available MindForge commands.
+
+## Pre-check
+If `.planning/STATE.md` exists, read it.
+If `.planning/PROJECT.md` is missing, treat the project as "Not initialised".
+
+1. Scan every .md file in `.claude/commands/mindforge/`
+2. For each file, extract the first non-empty line as the command description
+3. Display as a clean table:
+
+| Command                      | Description                                  |
+|------------------------------|----------------------------------------------|
+| /mindforge:help              | Show all available commands                  |
+| /mindforge:init-project      | ...                                          |
+| ...                          | ...                                          |
+
+## Sovereign Intelligence (v6.2.0-alpha)
+MindForge now operates with **Sovereign Intelligence** enabled by default:
+- **PQAS**: Post-Quantum Agentic Security is active. High-risk operations require biometric/executive bypass.
+- **Proactive Homing**: The swarm now proactively harvests intent and self-heals reasoning drifts.
+- **Integrity**: Every `security-scan` now verifies framework signatures using lattice-based cryptography.
+
+4. After the table, print:
+   "Current project: [read PROJECT.md first line, or 'Not initialised']"
+   "Current phase:   [read STATE.md current phase, or 'None']"
+   "Next step:       [read STATE.md next action]"
+
+5. If CLAUDE.md has not been read this session, remind the user to ensure
+   it is loaded as MindForge's system context.