mindforge-cc 8.2.0 → 9.0.0

package/.mindforge/mirrors/mirror-sre-776a1cf9/.mindforge/dashboard/dashboard-spec.md

@@ -1,96 +0,0 @@
-# MindForge v2 — Dashboard Specification
-
-## Overview
-
-The MindForge dashboard is a real-time web UI that reflects the live state of
-the MindForge agent and all project artifacts. It serves as the team's window
-into what the agent is doing — designed for standup visibility, not agent control
-(though it does support approval actions for Tier 2/3 governance).
-
-## Architecture
-
-```
-Browser clients
-     ↑ SSE (push)     ↑ REST (pull on load)
-     │                │
-  bin/dashboard/server.js  (Express.js, localhost:7339)
-     │                │
-  sse-bridge.js       api-router.js
-     │ (tails files)  │ (reads files)
-     │                │
-  AUDIT.jsonl         HANDOFF.json
-  auto-state.json     session-quality.jsonl
-  APPROVAL-*.json     token-usage.jsonl
-  HANDOFF.json        knowledge-base.jsonl
-  TEAM-STATE.jsonl    .planning/phases/
-```
-
-## Port and binding
-
-- **Port:** 7339 (Dashboard = 7337+2, after SSE at 7337 and Browser Daemon at 7338)
-- **Binding:** 127.0.0.1 ONLY — never 0.0.0.0 (ADR-017 policy)
-- **Protocol:** HTTP/1.1 with SSE for live events
-- **Process lifecycle:**
-  - Started by: `/mindforge:dashboard` command or `bin/dashboard/server.js`
-  - Stopped by: `CTRL+C`, `/mindforge:dashboard --stop`, or SIGTERM
-  - Auto-stop: when MindForge session ends (watches for HANDOFF.json inactivity)
-
-## Dashboard pages (5 tabs)
-
-### Page 1 — Live Activity (default view)
-Shows real-time execution state:
-- Project name and current phase description
-- Auto mode status indicator (RUNNING/PAUSED/ESCALATED/IDLE)
-- Wave progress bar (current wave / total waves)
-- Current task name and elapsed time
-- Live AUDIT event feed (last 50 events, newest at top)
-- Steering input box (sends to steering queue if auto mode active)
-
-### Page 2 — Quality Metrics
-Charts powered by session-quality.jsonl and token-usage.jsonl:
-- Session quality score trend (last 20 sessions, sparkline)
-- Verify pass rate over time (last 20 sessions)
-- Security findings by severity (bar chart: CRITICAL/HIGH/MEDIUM/LOW)
-- Token cost per session trend
-- Node repair frequency (auto mode health signal)
-
-### Page 3 — Pending Approvals
-Governance queue visible to the whole team:
-- Shows all APPROVAL-*.json files with status: pending
-- For each: tier, phase/plan, change description, time since requested, expiry
-- [Approve] and [Reject] buttons that call POST /api/approve/:id
-- Expired approvals shown separately with red indicator
-
-### Page 4 — Knowledge Graph
-Visual representation of the knowledge base:
-- Force-directed graph: nodes = knowledge entries, edges = ADR links
-- Color by type: blue=decision, green=preference, red=bug_pattern, yellow=domain
-- Node size = confidence × 30px radius
-- Click node → side panel with full content
-- Filter by type, tags, or confidence threshold
-
-### Page 5 — Team Activity
-Multi-developer visibility:
-- Active developers (git email → last AUDIT event timestamp)
-- What each developer is working on (last task from AUDIT.jsonl)
-- File conflict detection (two developers recently touching the same file)
-- Session history (list of sessions, quality scores, costs)
-
-## Security model
-
-1. Localhost-only binding (127.0.0.1) — consistent with all MindForge servers
-2. No authentication — local dev tool, not exposed to network
-3. CORS policy: only allow requests from localhost
-4. Approval actions (POST /api/approve/:id) require the approval file to exist
-   in `.planning/approvals/` — cannot fabricate approvals from browser
-5. Steering (POST /api/steer) only works when auto-state.json shows `status: running`
-6. All file reads are restricted to `.planning/` and `.mindforge/` directories —
-   no arbitrary filesystem access from the API
-
-## SCREENSHARE MODE (recommended team use)
-The dashboard is designed to be screenshared during standups:
-- Product managers see live progress without CLI access
-- Designers see when their UI implementation tasks are running
-- Stakeholders see real estimates of completion time
-- On-call engineers see security findings as they're detected
-Never expose the dashboard URL externally — it contains project details.

package/.mindforge/mirrors/mirror-sre-776a1cf9/.mindforge/distribution/marketplace.md

@@ -1,53 +0,0 @@
-# MindForge v2 — Community Skills Marketplace
-
-## Purpose
-The MindForge Marketplace is a distribution network for reusable AI skills.
-It leverages the `mindforge-skill-` npm package prefix for discovery.
-
-## Naming conventions
-Skills published to the marketplace MUST follow this naming convention:
-`mindforge-skill-[technology-or-pattern]`
-
-Example:
-- `mindforge-skill-prisma-schema`
-- `mindforge-skill-zod-api-contracts`
-- `mindforge-skill-stripe-webhooks`
-
-## Marketplace categories
-Skills are grouped into these canonical categories:
-1. **Engines & Runtimes** (Node.js, Python, Go, Rust)
-2. **Databases & ORMs** (Prisma, Drizzle, Kysely, Sequelize)
-3. **API & Integration** (Stripe, Twilio, OpenAI, Anthropic)
-4. **UI & Frontend** (React, Next.js, Tailwind, Radix)
-5. **Patterns & Security** (Auth, RBAC, Validation, Error Handling)
-
-## Quality requirements
-To be listed in the marketplace, a skill MUST:
-- Achieve a quality score of ≥ 80/100
-- Pass all level 1 + level 2 validation checks
-- Include at least 5 complete, working code examples
-- Be free of any placeholder text
-- Be licensed under MIT or Apache-2.0
-
-## Publishing process
-1. Run `/mindforge:learn` to generate/update the skill.
-2. Achieve score ≥ 80 using `skill-scorer.js`.
-3. Fill in the optional `author`, `license`, and `category` fields in frontmatter.
-4. Run `/mindforge:marketplace publish [skill-name]`.
-   - This prepares the `package.json`.
-   - Runs final verification.
-   - Prompts for `npm publish`.
-
-## Interaction interface
-```
-/mindforge:marketplace search [query]       # Search the marketplace
-/mindforge:marketplace featured             # Show featured skills
-/mindforge:marketplace trending             # Show trending skills
-/mindforge:marketplace info [name]           # Show skill details and quality score
-/mindforge:marketplace install [name]        # Install a community skill
-/mindforge:marketplace publish [name]        # Publish your skill
-```
-
-## Marketplace Registry
-By default, the marketplace uses the global npm registry with the `mindforge-skill-` prefix.
-Private registries can be configured via `MARKETPLACE_REGISTRY` in MINDFORGE.md.

package/.mindforge/mirrors/mirror-sre-776a1cf9/.mindforge/distribution/registry-client.md

@@ -1,166 +0,0 @@
-# MindForge Skills Registry — Client Protocol
-
-## Purpose
-Define how MindForge discovers, downloads, validates, and installs skills
-from the public or private npm-based registry.
-
-## Installation flow
-
-### Step 1 — Resolve package name
-```bash
-# From skill name to package name:
-SKILL_NAME="security-owasp"
-PACKAGE_NAME="mindforge-skill-${SKILL_NAME}"
-
-# Or if user provides full package name:
-PACKAGE_NAME="mindforge-skill-security-owasp"
-```
-
-### Step 2 — Check if already installed
-```bash
-# Check local MANIFEST.md
-grep "| ${SKILL_NAME} |" .mindforge/org/skills/MANIFEST.md && echo "Already installed"
-
-# Check if SKILL.md exists
-[ -f ".mindforge/skills/${SKILL_NAME}/SKILL.md" ] && echo "Skill file exists"
-```
-
-### Step 3 — Secure temp directory creation
-```bash
-# Create temp directory with user-only permissions (prevents TOCTOU attacks)
-TEMP_DIR=$(mktemp -d)
-chmod 700 "${TEMP_DIR}"
-
-# All subsequent operations in this directory are protected
-npm pack "${PACKAGE_NAME}@latest" --pack-destination "${TEMP_DIR}" --quiet
-
-# Verify the tarball was downloaded (not empty, not corrupted)
-TARBALL=$(ls "${TEMP_DIR}"/*.tgz 2>/dev/null | head -1)
-if [ -z "${TARBALL}" ]; then
-  rm -rf "${TEMP_DIR}"
-  echo "Error: Failed to download ${PACKAGE_NAME} — no tarball produced"
-  exit 1
-fi
-
-# Verify tarball size is reasonable (not 0 bytes, not suspiciously large)
-TARBALL_SIZE=$(wc -c < "${TARBALL}")
-if [ "${TARBALL_SIZE}" -lt 100 ]; then
-  rm -rf "${TEMP_DIR}"
-  echo "Error: Downloaded tarball is suspiciously small (${TARBALL_SIZE} bytes)"
-  exit 1
-fi
-
-tar -xzf "${TARBALL}" --strip-components=1 -C "${TEMP_DIR}"
-```
-
-### Step 4 — Validate the downloaded skill
-Run the full skill validator (see `skill-validator.md`) against the downloaded SKILL.md.
-If validation fails: abort installation. Never install a skill that fails validation.
-
-For public registry installs: run Level 3 validation as well. Warn on failures but do not
-block install. For private registry installs: Level 2 is sufficient.
-
-### Step 4.5 — Dependency audit (optional but recommended)
-If the skill package includes scripts with dependencies, run an audit:
-```bash
-if [ -f "${TEMP_DIR}/package.json" ]; then
-  npm audit --prefix "${TEMP_DIR}" --audit-level=high || {
-    echo "Warning: HIGH/CRITICAL vulnerabilities detected in skill dependencies"
-    SKILL_DEPENDENCY_VULN=true
-  }
-fi
-```
-If vulnerabilities were found, warn but allow install. Record in AUDIT:
-`"skill_dependency_vulnerability": true`.
-
-### Step 5 — Injection guard check
-Run the injection guard from Day 3 (`loader.md`) against the skill content.
-If injection patterns detected: abort, write AUDIT entry, alert user.
-
-### Step 6 — Install to correct tier location
-```bash
-# Determine target tier from user input or package.json tier-recommendation
-TIER="${USER_SPECIFIED_TIER:-2}"
-
-if [ "${TIER}" = "1" ]; then
-  TARGET_DIR=".mindforge/skills/${SKILL_NAME}"
-elif [ "${TIER}" = "2" ]; then
-  TARGET_DIR=".mindforge/org/skills/${SKILL_NAME}"
-else
-  TARGET_DIR=".mindforge/project-skills/${SKILL_NAME}"
-fi
-
-mkdir -p "${TARGET_DIR}"
-cp "${TEMP_DIR}/SKILL.md" "${TARGET_DIR}/SKILL.md"
-[ -d "${TEMP_DIR}/examples" ] && cp -r "${TEMP_DIR}/examples" "${TARGET_DIR}/"
-[ -d "${TEMP_DIR}/scripts" ]  && cp -r "${TEMP_DIR}/scripts"  "${TARGET_DIR}/"
-```
-
-### Step 7 — Register in MANIFEST.md
-```bash
-# Add entry to the correct tier section of MANIFEST.md
-SKILL_VERSION=$(node -e "console.log(require('${TEMP_DIR}/package.json').version)")
-
-# Insert into MANIFEST.md under the appropriate tier section
-# Format: | name | version | stable | min-mf-version | path |
-```
-
-### Step 8 — Clean up and report
-```bash
-rm -rf "${TEMP_DIR}"
-```
-
-Report to user:
-```
-✅ Skill installed: ${SKILL_NAME} v${SKILL_VERSION} (Tier ${TIER})
-   Triggers: [list from SKILL.md frontmatter]
-   Path: ${TARGET_DIR}/SKILL.md
-
-Run /mindforge:skills validate to confirm installation.
-```
-
-### Step 9 — Write AUDIT entry
-```json
-{
-  "event": "skill_installed",
-  "skill_name": "security-owasp",
-  "skill_version": "1.2.0",
-  "package_name": "mindforge-skill-security-owasp",
-  "tier": 2,
-  "source": "npm-registry | private-registry",
-  "validation_passed": true,
-  "skill_dependency_vulnerability": false
-}
-```
-
-## Update protocol
-
-### Check for updates
-```bash
-# Compare installed version against registry latest
-INSTALLED=$(grep "| ${SKILL_NAME} |" MANIFEST.md | awk -F'|' '{print $3}' | tr -d ' ')
-LATEST=$(npm info "${PACKAGE_NAME}" version --prefer-offline 2>/dev/null)
-
-if [ "${INSTALLED}" != "${LATEST}" ]; then
-  echo "Update available: ${SKILL_NAME} v${INSTALLED} → v${LATEST}"
-fi
-```
-
-### Update a skill
-```bash
-# Run install flow for latest version
-# If MAJOR version bump: show breaking changes, require confirmation
-# If MINOR/PATCH: update silently
-```
-
-## Uninstall protocol
-```bash
-# Remove skill files
-rm -rf "${TARGET_DIR}"
-
-# Remove from MANIFEST.md
-sed -i "/| ${SKILL_NAME} |/d" .mindforge/org/skills/MANIFEST.md
-
-# Write AUDIT entry
-# Commit: "chore(skills): uninstall ${SKILL_NAME}"
-```

package/.mindforge/mirrors/mirror-sre-776a1cf9/.mindforge/distribution/registry-schema.md

@@ -1,96 +0,0 @@
-# MindForge Skills Registry — Schema & Protocol
-
-## Registry concept
-The public MindForge Skills Registry is an npm-based distribution system.
-Skills are published as npm packages with the `mindforge-skill-` prefix.
-The registry leverages the existing npm ecosystem for versioning, discovery,
-and distribution.
-
-## Package naming convention
-```
-mindforge-skill-[category]-[name]
-```
-
-Examples:
-- `mindforge-skill-security-owasp`       — OWASP security review skill
-- `mindforge-skill-db-postgres-patterns` — PostgreSQL-specific patterns
-- `mindforge-skill-frontend-react-a11y`  — React accessibility patterns
-- `mindforge-skill-testing-playwright`   — Playwright E2E testing patterns
-- `mindforge-skill-api-graphql`          — GraphQL API design patterns
-
-## Package structure
-
-```
-mindforge-skill-[category]-[name]/
-├── SKILL.md              ← The skill file (required)
-├── package.json          ← npm metadata
-├── README.md             ← Human documentation
-├── CHANGELOG.md          ← Version history
-├── examples/             ← Optional usage examples
-│   └── example-task.md
-├── scripts/              ← Optional helper scripts
-│   └── helper.sh
-└── tests/
-    └── skill.test.js     ← Skill validation tests
-```
-
-## `package.json` for a skill package
-
-```json
-{
-  "name": "mindforge-skill-security-owasp",
-  "version": "1.2.0",
-  "description": "OWASP Top 10 security review skill for MindForge",
-  "keywords": [
-    "mindforge",
-    "mindforge-skill",
-    "security",
-    "owasp",
-    "agentic-framework"
-  ],
-  "mindforge": {
-    "type": "skill",
-    "skill-name": "security-owasp",
-    "category": "security",
-    "min-mindforge-version": "0.5.0",
-    "triggers": ["OWASP", "security review", "injection", "auth", "XSS"],
-    "tier-recommendation": 1
-  },
-  "files": ["SKILL.md", "README.md", "examples/", "scripts/"],
-  "license": "MIT",
-  "homepage": "https://mindforge.dev/skills/security-owasp",
-  "repository": { "type": "git", "url": "https://github.com/mindforge-dev/skill-security-owasp" }
-}
-```
-
-## Registry discovery
-
-The MindForge registry is the standard npm registry with keyword filtering:
-```bash
-# Search for skills
-npm search mindforge-skill [query]
-
-# Example searches:
-npm search mindforge-skill security    # Find security skills
-npm search mindforge-skill react       # Find React-specific skills
-npm search mindforge-skill testing     # Find testing skills
-```
-
-## Registry quality standards
-
-A skill package published to the MindForge registry must pass:
-1. Schema validation: `npx mindforge-cc validate-skill ./SKILL.md`
-2. Required metadata: package.json `mindforge` field fully populated
-3. No malicious content: npm security audit passes
-4. Version policy: follows semver with documented breaking changes
-5. License: MIT, Apache-2.0, or BSD (GPL derivatives not accepted)
-
-## Local registry (private skills)
-
-Organisations with private skills can use:
-- Private npm registry (Verdaccio, Artifactory, GitHub Packages)
-- Configure in `.mindforge/org/integrations/INTEGRATIONS-CONFIG.md`:
-  ```
-  MINDFORGE_SKILL_REGISTRY=https://npm.your-org.internal/
-  ```
-- Skills from private registry install with the same `npx mindforge-skills install` command

package/.mindforge/mirrors/mirror-sre-776a1cf9/.mindforge/distribution/skill-publisher.md

@@ -1,44 +0,0 @@
-# MindForge Skills Registry — Skill Publisher
-
-## Purpose
-Define the publish workflow for MindForge skills to npm (public or private).
-Used by `/mindforge:publish-skill`.
-
-## Publish workflow
-
-1. Validate SKILL.md (Levels 1, 2, and 3).
-2. Confirm `package.json` includes required `mindforge` metadata.
-3. Verify `CHANGELOG.md` has an entry for the current version.
-4. Check if version already exists on the registry.
-5. Preview files with `npm pack --dry-run`.
-6. Confirm with the user.
-7. Publish.
-8. Verify publish succeeded.
-9. Write AUDIT entry.
-
-## Commands
-
-```bash
-# Level 1 + 2 + 3 validation
-npx mindforge-cc validate-skill ./SKILL.md --quality
-
-# Version check
-npm info ${PACKAGE_NAME}@${VERSION}
-
-# Dry-run preview
-npm pack --dry-run
-
-# Publish
-npm publish --access public
-```
-
-## Audit entry
-
-```json
-{
-  "event": "skill_published",
-  "package": "mindforge-skill-security-owasp",
-  "version": "1.2.0",
-  "registry": "https://registry.npmjs.org/"
-}
-```

package/.mindforge/mirrors/mirror-sre-776a1cf9/.mindforge/distribution/skill-validator.md

@@ -1,74 +0,0 @@
-# MindForge Skills Registry — Skill Validator
-
-## Purpose
-Validate a SKILL.md file before installation or publication.
-Run as part of both `install-skill` and `publish-skill` commands.
-
-## Validation levels
-
-### Level 1 — Schema validation (always runs)
-```bash
-npx mindforge-cc validate-skill ./SKILL.md
-```
-
-Checks:
-- [ ] File starts with `---` (YAML frontmatter delimiter)
-- [ ] Frontmatter closes with `---`
-- [ ] `name:` field present and matches kebab-case pattern `[a-z][a-z0-9-]+`
-- [ ] `version:` field present and valid semver `\d+\.\d+\.\d+`
-- [ ] `status:` is one of: `stable`, `beta`, `alpha`, `deprecated`
-- [ ] `triggers:` field present and has >= 5 keywords
-- [ ] No trigger keyword is fewer than 3 characters (too generic)
-- [ ] `min_mindforge_version:` present and valid semver
-
-### Level 2 — Content validation (runs after schema passes)
-- [ ] File size between 1KB and 200KB (not too small, not too large)
-- [ ] Contains `## Mandatory actions` or `## When this skill is active` section
-- [ ] Contains at least one checklist item (`- [ ]`) for self-verification
-- [ ] Does not contain any injection patterns (from `loader.md` guard)
-- [ ] Code examples have language specifiers in code fences (not bare ```)
-- [ ] No placeholder text: `[placeholder]`, `[your-name]`, `TODO`, `FIXME`, `[fill this in]`
-
-### Level 3 — Quality validation (required for publish, recommended for public install)
-- [ ] At least 3 code examples
-- [ ] CHANGELOG in frontmatter has at least current version entry
-- [ ] `breaking_changes:` field present (even if empty list)
-- [ ] Examples directory has at least one example file
-- [ ] README.md exists in the package
-
-**Install rule:**
-- Public registry installs: run Level 3 and warn on failures (do not block)
-- Private registry installs: Level 2 is sufficient
-
-## Validator output
-
-```
-MindForge Skill Validator — SKILL.md
-──────────────────────────────────────────────────────────────
-
-Schema validation:
-  ✅ Frontmatter valid
-  ✅ name: security-owasp (valid)
-  ✅ version: 1.2.0 (valid semver)
-  ✅ status: stable
-  ✅ triggers: 31 keywords (min: 5)
-  ✅ min_mindforge_version: 0.5.0
-
-Content validation:
-  ✅ File size: 8.4KB (1KB-200KB range)
-  ✅ Mandatory actions section present
-  ✅ Self-check checklist present (7 items)
-  ✅ No injection patterns detected
-  ✅ Code examples have language specifiers
-  ✅ No placeholder text found
-
-Quality validation:
-  ✅ 5 code examples found
-  ✅ CHANGELOG has version 1.2.0 entry
-  ✅ Breaking changes documented
-  ⚠️  Examples directory has 1 file (recommend: 3+)
-
-──────────────────────────────────────────────────────────────
-Result: VALID with 1 warning
-Ready for: installation ✅ | publication ✅ (warning noted)
-```

package/.mindforge/mirrors/mirror-sre-776a1cf9/.mindforge/engine/ads-protocol.md

@@ -1,54 +0,0 @@
-# MindForge Engine — Adversarial Decision Synthesis (ADS) Protocol
-
-## Purpose
-Evolve the standard single-agent planning model into a high-fidelity Red-Team/Blue-Team architectural synthesis. This protocol ensures all major decisions are stress-tested for maintainability, security, and scalability before execution begins.
-
-## Core Roles
-
-### 1. The Architect (Blue Team — Performance & Complexity)
-- **Persona**: `mindforge-architect` or `mf-planner`
-- **Objective**: Propose the most technically superior, performant, and feature-complete solution.
-- **Bias**: "We should build for scale and future-proof the system."
-
-### 2. The Auditor (Red Team — Simplicity & Maintainability)
-- **Persona**: `mindforge-qa-engineer` or `mindforge-security-reviewer`
-- **Objective**: Find logic gaps, security flaws, and architectural "over-engineering".
-- **Bias**: "Do we really need this complexity? How will this break tomorrow?"
-
-### 3. The Synthesizer (Gold Team — Decision Merge)
-- **Persona**: `mindforge-decision-architect`
-- **Objective**: Mediate the debate, score proposals using `SOUL.md` metrics, and merge into a final `PLAN.md`.
-- **Bias**: "Objective leverage. Minimal risk. Maximum impact."
-
-## Synthesis Loop — Execution Order
-
-### Step 1: Blue Proposal (Propose)
-The **Architect** generates a detailed implementation plan (`PLAN-[P]-BLUE.md`).
-- Focus on: Data flow, performance, and API design.
-
-### Step 2: Red Critique (Challenge)
-The **Auditor** reviews the Blue plan and generates a critique (`PLAN-[P]-RED-CRITIQUE.md`).
-- **Pressure Rule**: Red *must* identify at least 3 potential failure modes or "Complexity Traps."
-- Red proposes a "Simpler Alternative" if the Blue plan is deemed over-engineered.
-
-### Step 3: Gold Verdict (Synthesize)
-The **Synthesizer** ingest both plans and the critique. 
-1. Calculates the **SOUL_SCORE** for each approach:
-   `Score = (Impact × Leverage × Reversibility) / (Effort × Risk × Cost)`
-2. Generates the final `PLAN.md` by adopting the best parts of both.
-3. Produces a `DECISION_ADS.md` (ADR) justifying the synthesis.
-
-## Synthesis Tossing (Iterative Loop)
-If the **SOUL_SCORE** difference between approaches is < 0.2, the Synthesizer can trigger one round of "Tossing":
-- Both teams are given the other's feedback and asked to refine their proposal.
-- Total iterations capped at 2 to avoid scope-paralysis.
-
-## Output Structure
-The final result must always move to the standard `.planning/` directory:
-- `.planning/PLAN.md` (Validated & Hardened)
-- `.planning/decisions/ADS-[UUID].md` (The Proof of Synthesis)
-
-## Trigger Conditions
-- Any phase marked "Architectural" in `ROADMAP.md`
-- Manual trigger via `/mindforge:plan-phase --ads`
-- When a `security-reviewer` flags a high-risk change