mindforge-cc 9.0.0 → 10.0.1

package/.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/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/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/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/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/governance/GOVERNANCE-CONFIG.md

@@ -1,17 +0,0 @@
-# MindForge Governance Configuration
-
-## Tier policy
-- Tier 1: low-risk documentation or isolated code cleanup
-- Tier 2: broader product or operational changes
-- Tier 3: security, privacy, auth, secrets, payments, compliance, or emergency
-
-## Enforcement rules
-- Tier 3 signals have higher priority than file-count heuristics
-- Compliance gates are blocking
-- Integration failures are non-fatal unless they prevent a required approval or
-  compliance decision from being observed
-
-## Record locations
-- Approval files: `.planning/approvals/`
-- Audit archive: `.planning/audit-archive/`
-- Milestones: `.planning/milestones/`

package/.mindforge/governance/approval-workflow.md

@@ -1,37 +0,0 @@
-# MindForge Governance — Approval Workflow
-
-## Purpose
-Define the human approval process for Tier 2 peer review, Tier 3
- security/compliance review, and emergency override handling.
-
-## Approval sources
-Approvals are represented as files in `.planning/approvals/`. Commands must list
- only `status: pending` approval requests by default.
-
-## Identity model
-Current approver identity is derived from `git config user.email` or `$USER`.
-This is convenient but spoofable. For higher-assurance environments, integrate
- the approval flow with your IdP or SCM identity provider.
-
-## Standard workflow
-1. Classifier determines tier
-2. Create approval file with reason, scope, diff summary, and expiry time
-3. Notify configured approvers
-4. Record approval or rejection
-5. On rejection, create a fix task that carries the rejection reason forward
-6. Re-request approval only after the rejection reason has been addressed
-
-## Expiry and SLA handling
-Expiry processing is session-dependent. If no MindForge session is active, an
- expired approval will be detected the next time the approval command runs.
-
-Use config-driven values from `INTEGRATIONS-CONFIG.md`:
-- `TIER2_APPROVERS`
-- `TIER3_APPROVERS`
-- `EMERGENCY_APPROVERS`
-- SLA and expiry hour settings
-
-## Emergency override
-Emergency approval requires the `--emergency` flag and an approver identity that
- appears in `EMERGENCY_APPROVERS`. Log the approver identity and rationale in
- AUDIT. Emergency override bypass is never implicit.

package/.mindforge/governance/change-classifier.md

@@ -1,63 +0,0 @@
-# MindForge Governance — Change Classifier
-
-## Purpose
-Assign each change a governance tier before execution and again before release.
-Tier 3 signals always override lower-risk heuristics.
-
-## Trigger points
-- Before each plan executes
-- Before PR or merge request creation
-- Before emergency override requests are processed
-
-## Tier model
-
-| Tier | Meaning | Approval requirement |
-|---|---|---|
-| 1 | Low-risk documentation or isolated refactor | none |
-| 2 | Broad change, cross-cutting impact, or moderate operational risk | peer approval |
-| 3 | Security, privacy, auth, payment, secrets, or compliance-sensitive | security/compliance approval |
-
-## Step 1 — Base heuristics
-- More than 10 files or more than 300 lines changed defaults to Tier 2
-- Infra, deployment, or schema changes default to at least Tier 2
-- File count is only a signal; it never downgrades a Tier 3 match
-
-## Step 2 — Apply Tier 3 rules first
-Tier 3 uses three independent signals. Any one match makes the change Tier 3.
-
-### Signal A — File path patterns
-Security-critical directories and files:
-`auth/`, `security/`, `payment/`, `billing/`, `privacy/`, `crypto/`, `secrets/`
-
-Security-critical names:
-`login.ts`, `logout.ts`, `token.ts`, `password.ts`, `credentials.ts`,
-`session.ts`, `oauth.ts`, `jwt.ts`, `hash.ts`, `encrypt.ts`, `stripe.ts`,
-`payment.ts`, `billing.ts`, `pii.ts`, `consent.ts`
-
-### Signal B — Code content patterns
-Scan the actual diff content, not only filenames, for patterns such as:
-`bcrypt`, `argon2`, `jwt.sign`, `jwt.verify`, `jose.sign`, `jose.verify`,
-`stripe.`, `paypal.`, `createCipheriv`, `createDecipheriv`, `crypto.subtle`,
-`hashPassword`, `verifyPassword`, `encrypt(`, `decrypt(`, `role.*permission`,
-`hasPermission`, `SET ROLE`, `GRANT`
-
-This protects against security-critical code being added to innocuous filenames
- like `src/utils/helper.ts`.
-
-### Signal C — AUDIT history patterns
-If the current phase has a recent HIGH or CRITICAL `security_finding`, the next
- change in that phase is elevated to Tier 3 automatically.
-
-## Classification audit entry
-Record why the tier was selected:
-
-```json
-{
-  "event": "change_classified",
-  "tier": 3,
-  "classification_reason": "code pattern: jwt.sign found in src/utils/helper.ts",
-  "signals_checked": ["file_path", "code_content", "audit_history"],
-  "signal_triggered": "code_content",
-  "pattern_matched": "jwt.sign"
-}
-```

package/.mindforge/governance/compliance-gates.md

@@ -1,31 +0,0 @@
-# MindForge Governance — Compliance Gates
-
-## Purpose
-Apply non-bypassable release gates for secrets, approvals, and privacy controls.
-
-## Gate 1 — Required verification
-The plan's verify step and the project test suite must pass.
-
-## Gate 2 — Required approvals
-Tier 2 and Tier 3 changes must have approved, non-expired approval records.
-
-## Gate 3 — Secret detection
-No real secrets may enter the diff, audit log, or published docs.
-Override is not permitted.
-
-For tests that exercise secret detection, use clearly fake patterns that do not
- match production secret regexes, for example `TEST_ONLY_FAKE_KEY_abc123`.
-
-## Gate 4 — GDPR/PII compliance check
-This gate runs independently of skill loading.
-
-Trigger if the diff adds fields or columns resembling:
-`email`, `phone`, `mobile`, `address`, `postcode`, `zip`, `ssn`, `dob`,
-`birth_date`, `first_name`, `last_name`, `national_id`, `passport`,
-`credit_card`, `bank_account`, `iban`, `bic`
-
-If triggered, verify `.planning/ARCHITECTURE.md` documents retention policy for
- the relevant data. If retention is missing:
-- block completion
-- write `compliance_gate_failed` to AUDIT
-- require Tier 3 compliance approval for override

package/.mindforge/governance/policies/sovereign-default.json

@@ -1,16 +0,0 @@
-{
-  "id": "SOV-001",
-  "name": "Sovereign Default Policy",
-  "description": "Enables Sovereign Intelligence v8.1.1 features by default.",
-  "effect": "PERMIT",
-  "max_impact": 100,
-  "conditions": {
-    "did": "agent:*",
-    "min_tier": 1
-  },
-  "sovereign_config": {
-    "pqas": "ENABLED",
-    "proactive_homing": "ENABLED",
-    "biometric_threshold": 95
-  }
-}

package/.mindforge/integrations/confluence.md

@@ -1,27 +0,0 @@
-# MindForge — Confluence Integration
-
-## Purpose
-Publish architecture snapshots, ADRs, and milestone/phase documentation to a
- shared wiki without making Confluence the execution source of truth.
-
-## Published artifacts
-
-| MindForge artifact | Confluence target |
-|---|---|
-| `.planning/ARCHITECTURE.md` | Architecture overview page |
-| `.planning/decisions/ADR-*.md` | ADR child pages |
-| Phase verification summaries | Sprint or phase pages |
-| Milestone reports | Release or program pages |
-
-## Publishing rules
-Use update-by-title or update-by-page-ID so repeated publishes are idempotent.
-Do not create duplicate pages on re-run. If the target exists, update in place
- and preserve the page history.
-
-## Data safety
-Confluence publishing must exclude secrets, tokens, raw audit log content, and
- internal-only approver notes. Publish curated summaries, not raw machine state.
-
-## Failure handling
-Publishing failures are non-fatal. Log them, append a pending manual action to
- `.planning/STATE.md`, and provide a retry command via `/mindforge:sync-confluence`.