mindforge-cc 9.0.0 → 10.0.0

package/.mindforge/skills-builder/learn-protocol.md

@@ -1,161 +0,0 @@
-# MindForge v2 — Learn Protocol
-
-## Purpose
-Convert any knowledge source (URL, local file/dir, or current session) into a
-reusable, validated, committed MindForge SKILL.md file.
-
-## Activation sources
-
-### Source type: URL
-```
-/mindforge:learn https://docs.prisma.io/concepts/components/prisma-schema
-```
-Use RESEARCH_MODEL (default: gemini-2.5-pro with 1M context) to ingest and
-analyse the documentation. For large documentation sets, Gemini 2.5 Pro can
-read the entire page including all examples at once.
-
-### Source type: local file or directory
-```
-/mindforge:learn ./docs/api-conventions.md
-/mindforge:learn ./docs/internal/
-```
-Read file(s) directly (no model call needed for reading). Use EXECUTOR_MODEL
-to analyse content and extract patterns.
-
-### Source type: session
-```
-/mindforge:learn --session
-```
-Analyse the current session's SUMMARY files, ADR files, debug reports, and
-HANDOFF.json implicit_knowledge to find patterns worth capturing.
-
-### Source type: npm package docs
-```
-/mindforge:learn npm:zod
-/mindforge:learn npm:prisma
-```
-Fetch from npmjs.com/package/[name] and read the README + linked docs.
-
-## Step-by-step learn protocol
-
-### Step 1: Read and understand the source
-For URLs: use `source-loader.js` to fetch content (with SSRF protection).
-For local: use `source-loader.js` to read file(s) with walkDir().
-For session: read all SUMMARY-*.md and HANDOFF.json implicit_knowledge.
-For npm: fetch README from npmjs.com API.
-
-Maximum context: 900K chars for Gemini (1M context); 50K chars for other models.
-
-### Step 2: Identify the top 10 reusable patterns or rules
-Ask the analysis model:
-```
-You are an expert at reading technical documentation and extracting reusable
-engineering rules and patterns.
-
-Read this documentation carefully:
-[source content]
-
-Identify exactly 10 reusable patterns, rules, or best practices that would
-be most valuable to inject into an AI agent before it works with this technology.
-
-For each pattern:
-- Give it a short title (≤ 60 chars)
-- Write a concise rule statement (≤ 150 chars, actionable)
-- Include a code example showing correct usage (TypeScript/JavaScript preferred)
-- Identify if there is a common anti-pattern to warn against
-- Rate importance: CRITICAL | HIGH | MEDIUM | LOW
-
-Format as JSON array: [{ title, rule, example, anti_pattern, importance }]
-```
-
-### Step 3: Identify 15-25 trigger keywords
-Ask the analysis model:
-```
-Based on the patterns above, identify 15-25 keywords that, if found in a
-task description or code file path, should trigger this skill to load.
-
-Rules for good trigger keywords:
-- 2-4 words each (single-word triggers are too broad)
-- Specific to this technology (not generic like "database" or "model")
-- Cover: package names, file extensions, common function names, config file names
-- Include both noun and verb forms where applicable
-
-Return as JSON array of strings: ["keyword1", "keyword2", ...]
-```
-
-### Step 4: Write the SKILL.md following the authoring template
-Use the standard MindForge SKILL.md format from `docs/skills-authoring-guide.md`.
-Populate all sections:
-- Frontmatter (name, version, status, triggers, description)
-- Purpose (why this skill exists)
-- Key patterns (from Step 2 — the 10 patterns)
-- Anti-patterns to avoid
-- Code examples (at least 3 complete, working examples)
-- Self-check checklist (5-10 items)
-- Version history
-
-### Step 5: Run Level 1 + Level 2 validation
-Level 1 (schema): frontmatter complete, triggers present, mandatory sections exist.
-Level 2 (content): no placeholder text, code examples parse, triggers are specific.
-
-Use `skill-scorer.js` to compute the quality score (target: ≥ 60 for register,
-≥ 80 for community publish).
-
-If score < 60: report the specific gaps and ask user whether to fix or discard.
-
-### Step 6: Present to user for review and approval
-
-Display:
-```
-📚 Skill Generated: [skill-name]
-─────────────────────────────────────────────────────
-Source:        [source type and location]
-Quality score: [score]/100 ([breakdown])
-Patterns:      [N] extracted
-Triggers:      [K] keywords
-Tier:          [Core/Org/Project]
-
-Preview (first 3 patterns):
-  1. [title]: [rule]
-  2. [title]: [rule]
-  3. [title]: [rule]
-
-Skill file: .mindforge/skills/[name]/SKILL.md
-
-[ y ] Register and commit
-[ n ] Discard
-[ e ] Edit before registering
-[ p ] Publish to community marketplace (requires quality score ≥ 80)
-```
-
-### Step 7: If approved — register and commit
-```bash
-# Register in MANIFEST.md (tier determined by target: project=T3, org=T2, core=T1)
-# Default for learned skills: Project tier (T3) unless explicitly set
-node bin/skills-builder/skill-registrar.js --tier project --name [skill-name]
-
-# Write AUDIT entry
-{
-  "event": "skill_learned",
-  "source_type": "url|local|session|npm",
-  "source": "[url or path]",
-  "skill_name": "[name]",
-  "quality_score": [score],
-  "pattern_count": [N],
-  "trigger_count": [K]
-}
-
-# Commit
-git add .mindforge/skills/[name]/SKILL.md .mindforge/org/skills/MANIFEST.md
-git commit -m "feat(skills): learn [skill-name] from [source type]"
-```
-
-## Session-based learning (`--session` flag)
-Analyse these sources in order:
-1. All SUMMARY-*.md files in .planning/phases/[current phase]/
-2. HANDOFF.json implicit_knowledge array (Level 2+ compaction entries)
-3. All ADR-*.md files created in the current phase
-4. RETROSPECTIVE-*.md if it exists in the current phase
-
-Ask: "What patterns emerged that would have been useful to know before this phase?"
-Generate up to 3 skills from this analysis (not more — quality over quantity).

package/.mindforge/skills-builder/quality-scoring.md

@@ -1,120 +0,0 @@
-# MindForge v2 — Skill Quality Scoring
-
-## Purpose
-Every SKILL.md gets a quality score from 0-100 before registration.
-This score determines: whether it can be registered (≥ 60), whether it can
-be published to the community marketplace (≥ 80), and how prominently it
-is featured in search results.
-
-## Scoring dimensions (total: 100 points)
-
-### Dimension 1: Trigger Coverage (30 points)
-Measures: How many unique, specific trigger keywords the skill has.
-- 25-30 triggers: 30 points (full score)
-- 20-24 triggers: 24 points
-- 15-19 triggers: 18 points
-- 10-14 triggers: 12 points
-- 5-9 triggers: 6 points
-- < 5 triggers: 0 points
-
-Penalty: -2 points per generic trigger (words like "database", "api", "model"
-that would fire for almost any project). Triggers must be technology-specific.
-
-### Dimension 2: Mandatory Actions Completeness (25 points)
-Measures: Whether the skill has complete, actionable mandatory actions.
-Check for these mandatory sections:
-- [ ] At least 5 concrete "always do X" rules (5 pts)
-- [ ] At least 3 concrete "never do Y" rules (5 pts)
-- [ ] Security consideration section (5 pts)
-- [ ] Performance consideration section (5 pts)
-- [ ] Error handling guidance (5 pts)
-
-### Dimension 3: Code Examples (20 points)
-Measures: Quality and completeness of code examples.
-- 5+ complete, working code examples: 20 points
-- 3-4 examples: 14 points
-- 1-2 examples: 7 points
-- No examples: 0 points
-
-Bonus: +2 points if examples show both correct pattern AND anti-pattern side-by-side.
-
-### Dimension 4: Self-Check Checklist (15 points)
-Measures: Does the skill include a checklist an agent can use to verify its work?
-- 10+ checklist items: 15 points
-- 7-9 items: 10 points
-- 4-6 items: 7 points
-- 1-3 items: 3 points
-- No checklist: 0 points
-
-### Dimension 5: Injection Safety (10 points)
-Measures: Does the skill pass all injection guard checks?
-- No injection patterns detected: 10 points (full score)
-- Any injection pattern detected: 0 points (FAIL — skill cannot be registered)
-
-Injection patterns checked (same 8 as in skill-loader.md):
-IGNORE ALL PREVIOUS INSTRUCTIONS, DISREGARD YOUR INSTRUCTIONS, etc.
-
-### Dimension 6: No Placeholders (10 points)
-Measures: Absence of placeholder/template text that was never filled in.
-- Zero placeholders: 10 points
-- 1-2 placeholders: 5 points
-- 3+ placeholders: 0 points
-
-Placeholder patterns:
-`[your description here]`, `TODO`, `FIXME`, `<description>`, `...fill in...`
-
-### Dimension 7: Version History (10 points)
-Measures: Whether the skill has a changelog / version history.
-- Has ## Version History section with at least v1.0.0 entry: 10 points
-- Has frontmatter version but no history section: 5 points
-- No version information: 0 points
-
-Bonus: +2 points if skill has been updated more than once (shows maintenance).
-
-## Quality thresholds
-
-| Score | Status | Allowed actions |
-|---|---|---|
-| 90-100 | Excellent | Register, publish, featured in marketplace |
-| 80-89 | Good | Register, eligible to publish |
-| 70-79 | Acceptable | Register, not eligible for marketplace |
-| 60-69 | Minimum | Register with warning |
-| < 60 | Insufficient | Cannot register — must improve first |
-
-## `session_quality_lift` metric
-After a skill has been used in ≥ 5 sessions, compute:
-```
-lift = avg(session_quality_score when skill active)
-     - avg(session_quality_score when skill not active)
-```
-This is the most honest signal of skill value. A skill with quality_score=94
-but session_quality_lift=-2 is a misleading skill (it sounds good but hurts results).
-
-## Scoring output format
-```json
-{
-  "skill_name": "prisma-schema",
-  "version": "1.0.0",
-  "quality_score": 84,
-  "threshold_status": "good",
-  "can_register": true,
-  "can_publish": true,
-  "score_breakdown": {
-    "trigger_coverage": 27,
-    "mandatory_actions": 22,
-    "code_examples": 17,
-    "self_check": 12,
-    "injection_safe": 10,
-    "no_placeholders": 9,
-    "version_history": 8
-  },
-  "penalties_applied": [
-    { "dimension": "trigger_coverage", "reason": "1 generic trigger 'database'", "penalty": -2 }
-  ],
-  "improvement_suggestions": [
-    "Add 3 more trigger keywords to reach 25+ (currently 22)",
-    "Add performance considerations section (currently missing)",
-    "Add 3 more checklist items to reach 10+ (currently 7)"
-  ]
-}
-```

package/.mindforge/team/TEAM-PROFILE.md

@@ -1,42 +0,0 @@
-# MindForge Team Profile
-# Auto-generated by /mindforge:profile-team
-
-## IMPORTANT: Metrics usage policy
-Per ADR-014, data in this file and `.mindforge/metrics/` is for system
-improvement only, not developer performance evaluation.
-
-Use data for:
-- response personalization
-- skill loading improvements
-- compaction and planning tuning
-- process retrospectives (not people scoring)
-
-## Team composition
-| Name | Email | Primary role | Timezone | Experience |
-|---|---|---|---|---|
-| [Name] | [email] | [role] | [UTC+X] | [level] |
-
-## Tech stack preferences
-| Layer | Preferred | Comfortable | Learning |
-|---|---|---|---|
-| Backend | TypeScript/Node.js | Python | Go |
-| Frontend | React/Next.js | Vue | Svelte |
-| Database | PostgreSQL | MySQL | MongoDB |
-| Testing | Vitest | Jest | Playwright |
-
-## Working patterns
-- Average session length: [N] minutes
-- Peak working hours: [N-N]
-- Verify pass rate: [N%]
-- Common failure type: [from AUDIT]
-
-## Personalization rules
-- Verbosity: concise
-- Review style: direct
-- Preferred code organization: feature-based
-
-## Known strengths
-- [area]
-
-## Known growth areas
-- [area]

package/.mindforge/team/multi-handoff.md

@@ -1,23 +0,0 @@
-# MindForge Team — Multi-Developer HANDOFF
-
-## Purpose
-Allow multiple developers or agent sessions to collaborate without silently
- stomping shared state.
-
-## Shared coordination rules
-When a developer starts a plan, first check shared `HANDOFF.json` state. If the
- same plan already appears under `active_developers`, stop and ask for
- clarification before proceeding.
-
-Developers with `last_seen` older than 4 hours are considered stale and may be
- removed automatically on the next session start.
-
-## Required shared state fields
-- `active_developers`
-- current phase and plan ownership
-- recent files
-- blockers and decisions needed
-
-## Audit discipline
-Each task completion or failure commit must include any new AUDIT entries so
- shared history is not stranded in an uncommitted worktree.

package/.mindforge/team/profiles/README.md

@@ -1,13 +0,0 @@
-# MindForge Per-Developer Profiles
-
-Use `PROFILE-[dev-id].md` files to store per-developer preferences and observed
-patterns. `dev-id` is a sanitized email.
-
-Template fields:
-- Identity (name/email/role/timezone)
-- Communication preferences
-- Technical preferences
-- Observed session metrics
-- Strengths and growth areas
-
-Privacy: include only professional, collaboration-relevant data.

package/.mindforge/team/session-merger.md

@@ -1,18 +0,0 @@
-# MindForge Team — Session Merger
-
-## Purpose
-Merge concurrent session state safely after parallel work or multi-developer
- execution.
-
-## Merge strategy
-1. Merge `HANDOFF.json` through git, not ad hoc overwrite
-2. Resolve conflicts explicitly when two sessions claim the same plan
-3. Preserve both sides' blockers and decisions until reconciled
-4. Keep AUDIT append-only; ensure entries were committed with the task commits
-
-Git merge conflicts are the correct mechanism for contested shared state.
-
-## Conflict rules
-- Same plan claimed by two developers: escalate for human resolution
-- Different plans touching shared files: merge carefully, then rerun verification
-- Stale active developer entry: prune if `last_seen` is older than 4 hours

package/.planning/HANDOFF.json

@@ -1,8 +0,0 @@
-{
-  "_warning": "DO NOT ADD SECRETS OR SENSITIVE DATA TO THIS FILE. IT IS SYNCED ACROSS SESSIONS.",
-  "schema_type": "HANDOFF",
-  "schema_version": "2.0.0",
-  "handoffs": [],
-  "current_context": "",
-  "last_updated": "2026-03-25T00:00:00Z"
-}

package/.planning/PROJECT.md

@@ -1,33 +0,0 @@
-# [Project Name]
-
-> One sentence describing what this project does and for whom.
-
-## Status
-🚧 In development — Phase 0 (not started)
-
-## Problem statement
-[What pain does this solve? Be specific.]
-
-## Target users
-[Who uses this? Describe them precisely. Avoid "developers" — say "solo developers
-building production apps with Claude Code who want structured AI workflows."]
-
-## Tech stack
-| Layer      | Technology  | Version | Rationale                        |
-|------------|-------------|---------|----------------------------------|
-|            |             |         |                                  |
-
-## v1 Scope — IN
-- [ ] [Feature 1]
-- [ ] [Feature 2]
-
-## v1 Scope — OUT (explicitly excluded)
-- [Item 1] — reason: [why not v1]
-- [Item 2] — reason: [why not v1]
-
-## Success criteria
-[How will you know v1 is done? Be specific and measurable.]
-
-## Key constraints
-- [Constraint 1]
-- [Constraint 2]

package/.planning/RELEASE-CHECKLIST.md

@@ -1,68 +0,0 @@
-# MindForge v1.0.0 — Release Checklist
-
-Use this file to record verification results for the 50-point production
-readiness checklist in `.mindforge/production/production-checklist.md`.
-
-## Metadata
-- Target version: v1.0.0
-- Release date: 2026-03-22
-- Release manager: [name]
-
-## Verification log
-| Item | Result | Verified by | Date | Notes |
-|---|---|---|---|---|
-| A01 |  |  |  |  |
-| A02 |  |  |  |  |
-| A03 |  |  |  |  |
-| A04 |  |  |  |  |
-| A05 |  |  |  |  |
-| A06 |  |  |  |  |
-| A07 |  |  |  |  |
-| A08 |  |  |  |  |
-| A09 |  |  |  |  |
-| A10 |  |  |  |  |
-| B01 |  |  |  |  |
-| B02 |  |  |  |  |
-| B03 |  |  |  |  |
-| B04 |  |  |  |  |
-| B05 |  |  |  |  |
-| B06 |  |  |  |  |
-| B07 |  |  |  |  |
-| B08 |  |  |  |  |
-| B09 |  |  |  |  |
-| B10 |  |  |  |  |
-| C01 |  |  |  |  |
-| C02 |  |  |  |  |
-| C03 |  |  |  |  |
-| C04 |  |  |  |  |
-| C05 |  |  |  |  |
-| C06 |  |  |  |  |
-| C07 |  |  |  |  |
-| C08 |  |  |  |  |
-| C09 |  |  |  |  |
-| C10 |  |  |  |  |
-| D01 |  |  |  |  |
-| D02 |  |  |  |  |
-| D03 |  |  |  |  |
-| D04 |  |  |  |  |
-| D05 |  |  |  |  |
-| D06 |  |  |  |  |
-| D07 |  |  |  |  |
-| D08 |  |  |  |  |
-| D09 |  |  |  |  |
-| D10 |  |  |  |  |
-| E01 |  |  |  |  |
-| E02 |  |  |  |  |
-| E03 |  |  |  |  |
-| E04 |  |  |  |  |
-| E05 |  |  |  |  |
-| E06 |  |  |  |  |
-| E07 |  |  |  |  |
-| E08 |  |  |  |  |
-| E09 |  |  |  |  |
-| E10 |  |  |  |  |
-| F01 |  |  |  |  |
-| F02 |  |  |  |  |
-| F03 |  |  |  |  |
-| F04 |  |  |  |  |
-| F05 |  |  |  |  |

package/.planning/REQUIREMENTS.md

@@ -1,35 +0,0 @@
-# Core Requirements Registry (MindForge v9.0.0)
-
-This registry contains the canonical requirements that all autonomous reasoning waves must align with. This file is parsed by the `ReasonSourceAligner` (RSA).
-
-## [REQ-001] Component Isolation
-
-All newly created engine components must be contained within the `bin/engine/` directory and follow a single-responsibility modular architecture.
-
-## [REQ-002] Intelligence-Drift Coupling (IDC)
-
-The system must proactively detect "logic loops" or reasoning stagnation and trigger compute resource upgrades (MIR tier elevation) when drift exceeds a critical threshold.
-
-## [REQ-003] Context Entropy Guard (CEG)
-
-The framework must actively suppress redundant reasoning thoughts (>85% similarity) and compress stagnant loops into high-density semantic digests before session handoff.
-
-## [REQ-004] Reason-Source Alignment (RSA)
-
-Every reasoning thought in an autonomous wave must be traceable back to at least one REQUIREMENT ID. Waves with <60% alignment must be flagged for refocusing.
-
-## [REQ-005] Zero-Trust Verification
-
-Implementation plans must include a verification phase with automated shell scripts or browser-based UAT to confirm success before claiming feature completion.
-
-## [REQ-006] Grounded Wave Execution
-
-The AutoRunner must parse HANDOFF.json wave groups and dispatch tasks with full audit trail persistence. Resume from auto-state.json must restore completed task state.
-
-## [REQ-007] Model Topology Currency
-
-All model references must use current-generation identifiers. Provider routing must use prefix matching, not substring matching.
-
-## [REQ-008] Unified Persistence
-
-All knowledge and graph data must be queryable via a single SQLite database with FTS5 search indexes.

package/.planning/ROADMAP.md

@@ -1,12 +0,0 @@
-# MindForge Roadmap
-
-### Phase 1: MindForge Enterprise Stabilization
-
-**Goal:** [To be planned]
-**Requirements**: TBD
-**Depends on:** Phase 0
-**Plans:** 0 plans
-
-Plans:
-
-- [ ] TBD (run /mindforge-plan-phase 1 to break down)

package/.planning/STATE.md

@@ -1,36 +0,0 @@
-# MindForge — Project State
-
-## Status
-🟢 Active — v9.0.0 (Bedrock Meridian Era)
-
-## IMPORTANT
-HANDOFF.json is committed to git. Never write secrets or credentials into it.
-Write "see .env" or "stored in secrets manager" if a note needs to reference credentials.
-
-
-## Current version
-v9.0.0 — Bedrock Meridian release. Pillars XXIV–XXVIII delivered.
-
-## Current phase
-Bedrock Meridian stabilisation and documentation updates.
-
-## Last completed task
-v9.0.0 release — Grounded Wave Execution, Model Topology Modernization, Unified Memory Architecture, Schema Migration Engine, Integration Test Chain.
-
-## Next action
-Verify all documentation artifacts reflect v9.0.0 state. Run `/mindforge:health` to confirm installation integrity.
-
-## Decisions made
-- Unified persistence layer on SQLite with FTS5 (Pillar XXVI).
-- All model references updated to current-generation identifiers (Pillar XXV).
-- Provider routing switched from substring to prefix matching (Pillar XXV).
-
-## Active blockers
-None.
-
-## Context for next session
-MindForge v9.0.0 shipped. All five Bedrock Meridian pillars (XXIV–XXVIII) are integrated.
-Config, context docs, and requirements updated for the v9.0.0 release.
-
-## Last updated
-2026-04-30T00:00:00Z

package/.planning/approvals/.gitkeep

@@ -1 +0,0 @@
-

package/.planning/archive/.gitkeep

@@ -1 +0,0 @@
-

package/.planning/audit-archive/.gitkeep

@@ -1 +0,0 @@
-

package/.planning/jira-sync.json

@@ -1 +0,0 @@
-{}

package/.planning/milestones/.gitkeep

@@ -1 +0,0 @@
-

package/.planning/slack-threads.json

@@ -1 +0,0 @@
-{}

package/docs/CAPABILITIES-MANIFEST.md

@@ -1,64 +0,0 @@
-# MindForge v6.2.0-alpha — Capabilities Manifest
-
-This manifest provides a line-item inventory of every engine, protocol, and feature available in the MindForge "Enterprise-Grade" installation.
-
-## 🛡️ 1. Sovereign Intelligence (Pillars IX-XII)
-The latest advancement in agentic security and proactivity.
-- **Post-Quantum Agentic Security (PQAS)**: 
-    - `QuantumCrypto`: Lattice-based (Dilithium-5) signature simulation for framework integrity.
-    - `ZK-Audit`: Zero-Knowledge proof generation for policy-compliant reasoning.
-    - `Integrity-Verify`: Constant-time manifest verification of framework files.
-- **Proactive Homing**:
-    - `IntentHarvester`: Idle-state task claiming from the Intelligence Mesh.
-    - `MeshSelfHealer`: Peer-to-peer drift detection and recovery logic.
-    - `DriftSense`: Repetition and density-aware loop detection (NDR).
-
-## 🌊 2. Autonomous Swarms (Nexus Engine)
-The core asynchronous execution environment.
-- **NexusTracer**: High-fidelity, async-first reasoning capture and tracing.
-- **WaveExecutor**: Parallel, dependency-aware task execution with prioritized queuing.
-- **TemporalProtocols**: Time-travel debugging, state versioning, and hindsight injection.
-- **ContextInjector**: Dynamic prompt-injection based on environmental signals.
-- **ShardController**: Support for distributed project state across multiple workspaces.
-
-## ⚖️ 3. Enterprise Governance (AgRevOps)
-Tiered security and value attribution for large-scale operations.
-- **Tiered Compliance Gates**:
-    - **Tier 1 (Core)**: Standard operations.
-    - **Tier 2 (Sensitive)**: Requires impact analysis.
-    - **Tier 3 (High-Impact)**: Requires executive/biometric approval (>95 blast radius).
-- **AgRevOps ROI Engine**: 
-    - `MarketEvaluator`: Real-time token arbitrage and model steering.
-    - `ROIAuditor`: Automated value attribution for completed waves.
-- **RBAC Manager**: Role-Based Access Control for persona identities and skill execution.
-
-## 🧠 4. Memory & Knowledge Hub
-The semantic foundation for long-term intelligence.
-- **Global Knowledge Graph**: Multi-project semantic index of decisions and patterns.
-- **SemanticHub**: Federated memory synchronization across distributed enclaves.
-- **GhostPatternDetector**: Identifies emerging antipatterns and optimized workflows autonomously.
-- **SessionMemoryLoader**: Fast-start context restoration from previous sessions.
-
-## 🤝 5. Enterprise Integrations
-Native adapters for the modern engineering stack.
-- **Jira Sync**: Bidirectional issue and milestone synchronization.
-- **Confluence Sync**: Automated architecture and roadmap documentation mirroring.
-- **Slack/Discord Hubs**: Real-time event notifications and approval requests.
-- **GitHub Actions Support**: CI-integrated validation and PR review pipelines.
-
-## 👤 6. Persona Library (30+ Identities)
-Specialized agent essences available via `node bin/spawn-agent.js`.
-- **Strategic**: `mf-planner`, `architect`, `tech-writer`.
-- **Implementation**: `mf-executor`, `developer`, `ui-checker`.
-- **Quality**: `mf-reviewer`, `nyquist-auditor`, `security-reviewer`.
-- **Specialized**: `debug-specialist`, `research-synthesizer`, `user-profiler`.
-
-## 🛠 7. CLI Command Suite (64+ Commands)
-Comprehensive control via `mindforge-cli.js`.
-- **Strategic**: `init-project`, `milestone`, `plan-phase`, `ship`.
-- **Operational**: `auto`, `headless`, `steer`, `stuck-monitor`.
-- **Governance**: `security-scan`, `approve`, `audit`, `metrics`, `tokens`.
-- **Sovereign**: `harvest`, `self-heal`, `quantum-verify`.
-
----
-*MindForge v6.2.0-alpha "Production-Grade" — Empowering the Autonomous Enterprise.*