mindforge-cc 9.0.0 → 10.0.1

package/docs/ci-cd.md

@@ -1,92 +0,0 @@
-# 🚀 MindForge 5-Layer Plane Architecture (CI/CD)
-
-MindForge v2.0.0 uses a sophisticated Control + Execution Plane architecture for its GitHub Actions, ensuring enterprise-grade governance and autonomous execution capabilities.
-
-## 🏗️ The 5 Planes
-
-| Plane | Purpose | Trigger |
-| --- | --- | --- |
-| **Control Plane** | Change classification & Routing | `push`, `pull_request` |
-| **Execution Plane** | Headless agent runtime | `workflow_call` |
-| **AI Intelligence** | Multi-model code validation | PRs (reusable) |
-| **Release Plane** | Packaging & Deployment | Tags (`v*`) |
-| **Observability** | Run metrics & Analytics | Post-run |
-
----
-
-## 🔄 PR Workflow Lifecycle
-
-When you open or update a Pull Request, MindForge triggers the following "Enterprise" sequence:
-
-1. **🔍 Classify**: Analyzes diffs to assign a **Governance Tier (1, 2, or 3)**.
-2. **⚖️ Govern**:
-    - **Tier 3 Enforcement**: Blocks the PR if sensitive changes are detected without an approval file.
-    - **Security Scan**: Automatically validates `MINDFORGE.md` and project configurations.
-3. **⚡ Execute**:
-    - Runs **Headless Agent** to verify autonomous logic.
-    - Executes full **Test Suite** and **Linter**.
-4. **🤖 Review**:
-    - Triggers **AI Intelligence Layer** (Claude + GPT-4o).
-    - Posts architectural/security findings as a **PR Comment**.
-5. **📊 Observe**: Generates a performance and audit trace report.
-
----
-
-## 🔍 Control Plane & Tiers
-
-Every change is automatically classified into a governance tier:
-
-- **Tier 1 (Trivial)**: Auto-approves and executes basic verification.
-- **Tier 2 (Logic)**: Executes full test suites and AI review.
-- **Tier 3 (Sensitive)**: Blocks the pipeline unless a manual approval is found in `.planning/approvals/`.
-
----
-
-## 🛠️ MindForge CLI (`bin/mindforge-cli.js`)
-
-All planes interact with MindForge via a centralized CLI router:
-
-- `health`: Validates project integrity.
-- `security-scan`: Scans for secrets and PII.
-- `headless`: Executes agents in non-interactive mode.
-- `pr-review`: Standard code review.
-- `cross-review`: Multi-model architecture validation.
-
----
-
-## 🛡️ Governance Enforcement
-
-If a PR touches sensitive components (Auth, Payments, Security):
-1. The **Control Plane** identifies it as **Tier 3**.
-2. The **Governance Gate** fails unless a valid `.planning/approvals/*.json` file exists.
-3. Once approved, the **Execution Plane** resumes the workflow.
-
-
-
----
-
-## 📦 Automated Releases
-
-Releases are triggered by pushing a semver tag:
-
-```bash
-git tag v2.0.0
-git push origin v2.0.0
-```
-
-This will automatically:
-
-- Run the full test suite.
-- Generate a CHANGELOG.
-- Publish to npm.
-- Create a GitHub Release with build artifacts.
-
----
-
-## 📊 Observability
-
-MindForge tracks every CI execution:
-
-- **Success Rate**: Phase completion status.
-- **Token Usage**: AI cost monitoring.
-- **Audit Trace**: Full execution history in `AUDIT.jsonl`.

package/docs/ci-quickstart.md

@@ -1,78 +0,0 @@
-# MindForge CI Quickstart (v1.0.0)
-
-This page shows how to run MindForge in real pipelines with non-interactive
-behavior and reliable outputs.
-
-## 1. Basic CI run (GitHub Actions)
-
-```yaml
-name: MindForge CI
-on:
-  pull_request:
-  push:
-    branches: [main]
-
-jobs:
-  mindforge:
-    runs-on: ubuntu-latest
-    steps:
-      - uses: actions/checkout@v4
-      - uses: actions/setup-node@v4
-        with:
-          node-version: 20
-
-      - name: Install MindForge
-        run: npx mindforge-cc@latest --claude --local
-
-      - name: Run MindForge suite
-        run: node tests/install.test.js
-```
-
-## 2. CI mode behavior
-Set `CI=true` to enable non-interactive operation.
-
-MindForge in CI:
-- Skips interactive prompts
-- Emits structured output (if configured)
-- Blocks Tier 3 changes
-- Logs all gate results
-
-## 3. Recommended env settings
-```bash
-CI=true
-MINDFORGE_CI=true
-```
-
-## 4. Add full test battery (v1.0.0)
-```bash
-SUITES=(install wave-engine audit compaction skills-platform \
-        integrations governance intelligence metrics \
-        distribution ci-mode sdk production migration e2e)
-
-for SUITE in "${SUITES[@]}"; do
-  node tests/${SUITE}.test.js
-done
-```
-
-## 5. Reporting
-If you want JSON output in CI, set in `MINDFORGE.md`:
-```
-CI_OUTPUT_FORMAT=json
-```
-
-## 6. Common CI pitfalls
-- Missing Node 18+ → install newer Node
-- CI failing on Tier 3 changes → approvals required
-- Missing `.planning/` in CI → run `/mindforge:init-project` or `map-codebase`
-
-## 7. GitLab CI example
-```yaml
-stages: [test]
-
-mindforge:
-  stage: test
-  image: node:20
-  script:
-    - npx mindforge-cc@latest --claude --local
-    - node tests/install.test.js
-```

package/docs/commands-skills/DISCOVERED_SKILLS.md

@@ -1,21 +0,0 @@
-# 🎯 Discovered Skills Registry
-
-*Generated at: 12/04/2026, 17:03:52*
-
-This document is automatically updated when AAVA refreshes its command engine. It lists all skills discovered across the workspace and system.
-
-## 📂 Project Skills (`.aava/skills/`)
-_No skills discovered in this tier._
-
-## 🌎 Global Skills (`~/.aava/skills/`)
-_No skills discovered in this tier._
-
-## 📦 Plugin Skills (Bundled)
-| Skill | Description | Argument Hint |
-| :--- | :--- | :--- |
-| `$debug` | Debug skill | `` |
-
----
-## 💡 Tips
-- Use `$` in the chat to trigger these skills.
-- To add a new skill, create a `.md` file in `.aava/skills/` in your project root.

package/docs/contributing/CONTRIBUTING.md

@@ -1,38 +0,0 @@
-# Contributing to MindForge
-
-Thanks for contributing. MindForge prioritizes reliability, security, and
-repeatability. Please follow the guidelines below.
-
-## Workflow
-1. Fork the repo and create a branch from `main`
-2. Use branch prefix `feat/`, `fix/`, `chore/`, `docs/`, `test/`
-3. Make small, focused commits with clear messages
-4. Run tests before opening a PR
-
-## Local setup
-```bash
-npm install
-npm test
-```
-
-## Commit guidance
-- One logical change per commit
-- Avoid formatting-only changes mixed with functional changes
-- No TODO comments in committed code
-
-## Tests
-Run the relevant suite for your change:
-```bash
-node tests/install.test.js
-# plus any affected suites
-```
-
-## PR checklist
-- [ ] Tests pass locally
-- [ ] Docs updated (if behavior changed)
-- [ ] New commands added to command reference
-- [ ] Security-sensitive changes reviewed
-
-## Security
-If you find a vulnerability, do not open a public issue. Report via
-`docs/security/SECURITY.md`.

package/docs/contributing/plugin-authoring.md

@@ -1,50 +0,0 @@
-# Plugin Authoring Guide (v1.0.0)
-
-## Overview
-Plugins extend MindForge with commands and skills. They are installed from npm
-under the `mindforge-plugin-*` namespace.
-
-## Structure
-```
-my-plugin/
-  plugin.json
-  commands/
-    my-command.md
-  skills/
-    my-skill/
-      SKILL.md
-```
-
-## plugin.json (required)
-```json
-{
-  "name": "mindforge-plugin-example",
-  "version": "1.0.0",
-  "mindforge_plugin_api_version": "1.0.0",
-  "min_mindforge_version": "1.0.0",
-  "commands": ["commands/my-command.md"],
-  "skills": ["skills/my-skill/SKILL.md"],
-  "permissions": {
-    "read_state": true,
-    "write_state": false,
-    "network": false
-  }
-}
-```
-
-## Command authoring
-Command files are standard MindForge command markdown. The first non-empty line
-is used as the command description.
-
-## Compatibility
-- `mindforge_plugin_api_version` must be `1.0.0` for MindForge v1.x.x
-- Command name conflicts are auto-renamed per `plugin-loader.md`
-
-## Security guidelines
-- Keep permissions minimal
-- Never exfiltrate project data without explicit user approval
-- Pass injection guard (no override or jailbreak phrases)
-
-## Test locally
-Use `/mindforge:plugins validate` and `/mindforge:plugins install --local` to
-validate and install into a test project.

package/docs/contributing/skill-authoring.md

@@ -1,41 +0,0 @@
-# Skill Authoring Guide (v1.0.0)
-
-## Purpose
-Skills capture repeatable domain expertise. They are loaded by keyword triggers.
-
-## Create a skill
-1. Create a directory under `.mindforge/skills/<skill-name>/`
-2. Add `SKILL.md` with frontmatter
-3. Add optional `assets/` or `references/`
-
-## SKILL.md template
-```markdown
----
-name: my-skill
-version: 1.0.0
-description: One-line description of the skill
-triggers: ["keyword1", "keyword2"]
-owner: my-team
-scope: project
----
-
-# Skill content
-- Guidance
-- Checklists
-- Examples
-```
-
-## Validation
-Run:
-```
-/mindforge:skills validate
-```
-
-## Publishing (optional)
-Publish to npm under `mindforge-skill-*`.
-See `docs/skills-publishing-guide.md` for full steps.
-
-## Security rules
-- No instructions that override system policies
-- No credentials or secrets in content
-- Avoid excessive prompts that expand tokens without value

package/docs/enterprise-setup.md

@@ -1,25 +0,0 @@
-# MindForge Enterprise Setup
-
-## Goal
-Configure Jira, Confluence, Slack, and SCM governance safely without storing
- credentials in the repository.
-
-## Setup sequence
-1. Fill non-sensitive values in
-   `.mindforge/org/integrations/INTEGRATIONS-CONFIG.md`
-2. Export credentials as environment variables
-3. Validate connectivity through `connection-manager.md`
-4. Run `/mindforge:sync-jira` and `/mindforge:sync-confluence`
-5. Confirm Slack notification behaviour and undelivered-alert fallback
-
-## Security rules
-- never commit tokens
-- never run credential-bearing calls with `set -x`
-- never use `curl -v` with Authorization headers
-- rotate credentials by updating the environment, not config files
-
-## Supported outputs
-- Jira epics and stories for phases/plans
-- Confluence architecture and ADR publishing
-- Slack notifications and thread tracking
-- milestone health and completion workflow

package/docs/feature-dashboard.md

@@ -1,63 +0,0 @@
-# Feature: Real-time Dashboard (v5.10.0)
-
-The MindForge Real-time Dashboard provides a high-fidelity, web-based control center for your agentic workflows. It leverages **Server-Sent Events (SSE)** to push live updates from your codebase directly to your browser with zero performance overhead.
-
-## 🚀 Getting Started
-
-To launch the dashboard:
-```bash
-/mindforge:dashboard --start --open
-```
-
-Default access: `http://localhost:7339` (Strictly bound to `127.0.0.1` for security).
-
-## 🛠 Key Features
-
-### 1. Live Audit Stream
-- Real-time rolling feed of all `AUDIT.jsonl` events.
-- Color-coded status indicators (Success, Failure, Security Warning).
-- Detailed JSON inspection for every action.
-
-### 2. Performance Metrics
-- **Token Costs**: Cumulative and session-based cost tracking across all providers.
-- **Quality Score**: Real-time graphing of verify-pass-rates.
-- **Compaction Health**: Monitoring of context management efficiency.
-
-### 3. Web-based Governance
-- **Tier 2/3 Approvals**: Review pending architectural or security changes.
-- **Tier 3 Confirmation**: Mandatory plan ID typing for high-risk approvals is enforced in the UI.
-- **Decision History**: Interactive timeline of past approvals and rejections.
-
-### 4. Team & Agent Activity
-- **Wave Progress**: Track multiple agents executing parallel waves.
-- **Persona Context**: See which agent personas are currently active.
-- **Steerage Feed**: View steering instructions as they are applied.
-
-### 5. MindForge Nexus (v5.10+)
-- **ART Trace Explorer**: Drill down into hierarchical reasoning spans and thought chains.
-- **Temporal Control Center**: Dynamic slider-based navigation of reasoning history.
-- **Hindsight Injection**: Rollback project state to any previous `auditId` and inject steering instructions to correct drift.
-- **Reasoning Heatmaps**: Identifying areas of adversarial disagreement and drift in real-time.
-
-### 6. AgRevOps Financial Hub (v5.10+)
-- **ROI Hub**: Real-time tracking of developer-hour value ($100/hr) vs. token expenditure.
-- **Velocity Forecaster**: Predictive analytics for milestone completion ETAs based on live task throughput.
-- **Security Health Score (SHS)**: Dynamic 0-100 score reflecting governance debt and policy compliance.
-
-## 🛡 Hardened Security
-- **Localhost Binding**: The server refuses connections from external IPs.
-- **CORS Lock-down**: Only allows requests from the local control plane.
-- **Integrity First**: Audit logs are written by the backend *before* changes are committed, ensuring a bulletproof trail.
-
-## 📟 Command Reference
-
-| Flag | Action |
-| :--- | :--- |
-| `--start` | Launch the dashboard server process. |
-| `--stop` | Gracefully shut down the server. |
-| `--status` | Check if the dashboard is running and get PID. |
-| `--open` | Open the UI in your default browser. |
-| `--port [N]` | Change the default port (7339). |
-
----
-*For technical implementation details, see `.mindforge/dashboard/dashboard-spec.md`.*

package/docs/governance-guide.md

@@ -1,134 +0,0 @@
-# MindForge Governance Guide (v9.0.0)
-
-Autonomous Site Reliability & Self-Healing Governance
-
-## 1. Goal
-
-MindForge v9.0.0 builds on the **Autonomous SRE Layer** introduced in v8.2.0, adding grounded execution semantics and model topology updates across the governance stack. The framework continues its transition from a proactive coding assistant to a self-healing production reliability engine, now with hardened input validation, updated trust primitives, and tighter integration between the CADIA engine and the new execution model. This release hardens the governance framework to handle autonomous production remediation with deterministic safety, adversarial auditing, and SLI-based verification.
-
-## 2. Post-Quantum Agentic Security (Pillar XI)
-
-MindForge implements Pillar XI to harden the identity layer against future quantum computing threats.
-
-### A. Lattice-Based Cryptography
-- **Signature Algorithm**: Dilithium-5 (Lattice-based).
-- **Key Exchange**: Kyber-1024 (Lattice-based).
-- **Hardening**: Every Tier 4 agent action is signed with quantum-safe primitives, ensuring non-repudiation in the post-quantum era.
-
-### B. ZK-Proof Compliance Bypasses
-For high-leverage architectural changes, Tier 3+ agents can generate a **Zero-Knowledge Proof** (simulated SNARK) to verify policy adherence without exposing confidential reasoning logic.
-
-## 3. Proactive Semantic Homing (Pillar XII)
-
-Pillar XII transitions the autonomous swarm from reactive wave-processing to proactive, self-healing "Homing" behavior.
-
-### A. Intent Harvesting
-Agents in an idle state proactively scan the **Federated Intelligence Mesh (FIM)** for unassigned tasks, claiming them based on **Skill-Affinity** scores to eliminate idle latency.
-
-### B. Mesh Self-Healing
-When an agent experiences critical logic drift (>80), peer agents in the mesh proactively "home in" on the node to provide collaborative reasoning and recovery vectors.
-
-## 4. Agentic Policy Orchestrator (APO) — CADIA Engine
-
-The APO is a decentralized governance engine that intercepts every autonomous intent before it is executed.
-
-### A. Intent Interception
-Before the `AutoRunner` begins a new execution wave, it extracts the acting agent's **Intent**:
-- **DID**: The unique identity of the agent.
-- **Action**: The operation being attempted (e.g., `WRITE`, `DELETE`, `EXECUTE`, `REMEDIATE`).
-- **Resource**: The target of the action (e.g., specific directories, files, or API endpoints).
-- **Tier**: The ZTAI Trust Tier assigned to the agent.
-- **SessionId**: The unique identifier for the current autonomous session.
-- **Reasoning Proof**: (Tier 3 Only) A justification for high-risk architectural actions.
-
-### B. Policy Evaluation (v9.0.0)
-The upgraded `PolicyEngine` evaluates the intent using the CADIA scoring model:
-1.  **Blast Radius Calculation**: The `ImpactAnalyzer` computes a risk score (0-100) based on architectural influence, session history, and goal alignment.
-2.  **Tier-Based Enforcement**: 
-    - **Score > 25 (LOW)**: Permitted for Tier 1+.
-    - **Score > 50 (MEDIUM)**: Permitted for Tier 2+.
-    - **Score > 80 (CRITICAL)**: **Denied** (Default) for Tier 0-2.
-    - **Tier 3 Bypass**: Senior agents can override a CRITICAL score if a valid `reasoning_proof` is provided.
-
-## 5. CADIA: Dynamic Impact Analysis Logic
-
-The **ImpactAnalyzer** calculates a precision-weighted score using the follow heuristics:
-
-### A. Architectural Influence Engine (x2.5)
-High-influence files (Core, Governance, Models, and Project State) increase the blast radius score significantly.
-- **Paths**: `bin/governance/*`, `bin/engine/*`, `package.json`, `.planning/*`.
-
-### B. Sensitive Namespace Protection (x4.0)
-Strict multipliers for mission-critical directories:
-- **Namespaces**: `.mindforge/`, `bin/`, `config/`, `.agent/`, `bin/sre/`.
-
-### C. Session Entropy Tracker (+15 per file)
-To prevent "Rogue Wave" mass-corruption, the risk score increases for every file touched in a single session after the 5th modification.
-- **Penalty**: `(session_count - 5) * 15`.
-
-### D. Goal-to-Path Alignment (+40 penalty)
-The system cross-references targets against the **Current Phase** in `.planning/STATE.md`.
-- **Anomalous Behavior**: If an agent tasked with "Fixing UI" attempts to modify `bin/models/cloud-broker.js`, a large penalty is applied.
-
-### E. ZTAI-Trust Scaling (Risk Buffers)
-Trust Tiers (0-3) provide a risk "overhead" buffer:
-- **Tier 1**: -10 points.
-- **Tier 2**: -20 points.
-- **Tier 3**: -30 points (Sovereign Trust).
-
-## 6. Trust Tier Architecture (ZTAI Hardened)
-
-V9.0.0 maps ZTAI Trust Tiers to explicit project roles through the `RBACManager`.
-
-| Tier | Role | Scope | Hardening |
-| :--- | :--- | :--- | :--- |
-| **0** | Informational | Research/Query only. | Read-only. No CADIA bypass. |
-| **1** | Implementation| Standard feature dev. | Write to `/src`, `/tests`. Session limit: 5 files. |
-| **2** | Specialized | Security/Ops Specialist. | Access to `/security`, `/infra`. Higher risk cap (60). |
-| **3** | Principal | Lead Architect / CEO / SRE Auditor. | **Full CADIA Bypass** (with Reasoning Proof). |
-
-## 7. Autonomous SRE Sovereignty (v9.0.0)
-
-Specialized governance for self-healing remediation waves.
-
-### A. The Opus-4.5 Hardening Rule
-Every SRE Remediation Verdict MUST be signed by a Tier 3 Auditor bound to the **Claude 4.5 Opus** model. This prevents "Intelligence Decay" in high-stakes production hotfixes.
-
-### B. Shadow-State Verification
-No remediation can be applied to the master environment until it has achieved **100% SLI Verification** in the `ShadowMirror` (Level 1 or Level 2) isolation layer.
-
-## 8. Operational Blast Radius & Self-Healing Guardrails
-
-- **Incident Lock**: When an SRE incident is active, all non-essential Tier 1 implementation work is automatically throttled or paused to reduce system entropy.
-- **Circuit Breakers**: If an autonomous remediation fails to improve SLIs in the Shadow Mirror after 3 attempts, the system generates an `EMERGENCY_ESCALATION` audit signal and freezes all SRE activities for that namespace.
-- **Entropy Gating**: The CADIA engine applies a **x5.0 multiplier** to any file modifications within `bin/sre/` itself to prevent the self-healing system from being tampered with by non-SRE agents.
-
-## 9. Enterprise Audit & Compliance (RISK-AUDIT)
-
-Every governance evaluation is persistently recorded in `.planning/RISK-AUDIT.jsonl`. This log provides a high-fidelity trail for enterprise compliance:
-- **requestId**: Unique ID for every evaluation.
-- **impactScore**: The final CADIA risk score (0-100).
-- **verdict**: PERMIT or DENY.
-- **reason**: Detailed explanation for the decision (e.g., "Violation: Max Impact Exceeded").
-
-## 10. Enterprise Policies
-
-MindForge v9.0.0 ships with default policies including:
-- **`gate_tier_3_engine`**: Blocks all modifications to `bin/autonomous/` unless signed by a Tier 3 DID.
-- **`protect_sre_namespace`**: Limits access to `/bin/sre` to the `sre-auditor` and `sre-engineer` roles.
-- **`enforce_blast_radius` (v9.0.0)**: Dynamic policy that enforces a strict 65-point cap for non-Sovereign agents.
-- **`require_sli_verification`**: Prevents the release of `REMEDIATION_WAVES` unless the `SLIVerifier` returns a `CONFIRMED_PASS` status.
-
-## 11. Security Hardening (v9.0.0)
-
-V9.0.0 introduces four targeted security hardening measures across the governance and execution layers:
-
-- **Phase Input Validation**: All phase transition inputs are now schema-validated before reaching the CADIA engine. Malformed or unexpected payloads are rejected at the boundary, preventing state corruption from ill-formed autonomous intents.
-- **Prototype Pollution Protection**: Object construction paths in the policy engine, config loaders, and shard controller sanitize incoming keys to block `__proto__`, `constructor`, and `prototype` injection vectors.
-- **API Key Redaction**: All audit log writers, event stream emitters, and diagnostic outputs now pass through a redaction layer that strips API keys, tokens, and credential fragments before they reach any persisted or transmitted surface.
-- **FTS5 Query Sanitization**: Full-text search queries against the MindForge SQLite knowledge store are parameterized and escaped to prevent FTS5 syntax injection, eliminating a class of search-based data exfiltration risks.
-
----
-
-*Status: V9.0.0 Autonomous SRE Governance Implemented & Verified (2026-04-30)*
-

package/docs/monorepo-guide.md

@@ -1,26 +0,0 @@
-# MindForge Monorepo Guide
-
-## Overview
-MindForge detects common monorepo setups (npm workspaces, pnpm, Nx, Turborepo, Lerna)
-and builds a workspace manifest for multi-package planning.
-
-## Detect workspace
-Run:
-```
-/mindforge:workspace detect
-```
-This writes `.planning/WORKSPACE-MANIFEST.json` and prints package order.
-
-## Plan across packages
-Use:
-```
-/mindforge:workspace plan phase N
-```
-Each PLAN file includes `<package>` and `<working-dir>` fields.
-
-## Test across packages
-Use:
-```
-/mindforge:workspace test
-```
-Tests run in dependency order, then root integration tests if configured.

package/docs/persona-customisation.md

@@ -1,56 +0,0 @@
-# MindForge Persona Customisation
-
-## Overview
-MindForge personas are shared and versioned. To tailor them for a specific
-project or phase, use the override system rather than editing the core persona
-files. Overrides are additive and safe to maintain across upgrades.
-
-## Where overrides live
-- Project overrides: `.mindforge/personas/overrides/[persona].md`
-- Phase overrides: `.planning/phases/[N]/persona-overrides/[persona].md`
-
-Priority order:
-1. Phase override
-2. Project override
-3. Core persona
-
-## Override format
-Overrides extend, modify, or remove sections from the base persona.
-Use the following directives:
-
-- `## Additional [section]` — append content to the base persona section
-- `## Modified [section]` — replace the base persona section
-- `## Removed [section]` — remove the base persona section
-- `KEY: VALUE` — override specific parameters (e.g., `MAX_FUNCTION_LINES: 60`)
-
-## Example override
-
-```markdown
-# Developer Persona Override — Payments Service
-# Scope: project
-# Author: Jane Doe
-# Created: 2026-03-20
-
-## Additional coding standards
-- All payment flows must be idempotent.
-- All monetary values use integer cents.
-
-## Modified conventions
-# Override: "Functions ≤ 40 lines" → allow 60 lines for orchestrators.
-MAX_FUNCTION_LINES: 60
-
-## Project-specific forbidden patterns
-- Never call Stripe directly from controllers — use PaymentService only.
-```
-
-## Best practices
-- Keep overrides minimal and specific.
-- Prefer new personas only when the cognitive mode is fundamentally different.
-- Document why an override exists so future maintainers understand its intent.
-- Review overrides at the end of each phase; prune what is no longer relevant.
-
-## Validation checklist
-- [ ] Override file is scoped correctly (project vs. phase)
-- [ ] Sections are clearly labeled (Additional / Modified / Removed)
-- [ ] Conflicts are resolved (phase overrides win)
-- [ ] Overrides do not contradict SECURITY.md

package/docs/publishing-guide.md

@@ -1,43 +0,0 @@
-# MindForge Publishing Guide
-
-This guide outlines the standard procedure for publishing a new version of `mindforge-cc` and its associated SDK to npm. Following this process ensures stability, correct versioning, and structural integrity.
-
-## Prerequisites
-
-1. **NPM Permissions**: You must have publish access to the `mindforge-cc` and `@mindforge/sdk` packages.
-2. **Clean State**: Ensure all changes are committed and your working directory is clean.
-3. **Authentication**: Run `npm whoami` to verify you are logged into the correct account.
-
-## Step-by-Step Workflow
-
-### 1. Pre-Flight Verification & Adversarial Review
-Before any release, ensure the following is completed:
-
-- **Structural Integrity**: Run `npm test` to verify layout and command mirroring.
-- **Security Check**: Run `/mindforge:security-scan` to ensure no keys or CVEs are present.
-- **Mult-Model Review**: Run `/mindforge:cross-review` to have multiple models (Claude, GPT, Gemini) audit the new features for edge cases.
-
-### 2. Versioning Strategy
-MindForge follows SemVer. Update `package.json` and `CHANGELOG.md` first.
-
-### 3. Automated Release Workflow
-MindForge provides a built-in workflow to handle the heavy lifting:
-
-1. Run the slash command: `/publish-release`
-2. Follow the interactive prompts to execute tests and dry runs.
-
-### 4. Manual Publishing (Fallback)
-If the workflow is unavailable:
-
-```bash
-npm publish --tag alpha --access public
-```
-
-### 5. Git Tagging & Origin Sync
-```bash
-git tag v[version]
-git push origin --tags
-```
-
----
-*Last Updated: 2026-03-22*