mindforge-cc 8.2.0 → 10.0.0

package/.mindforge/mirrors/mirror-sre-776a1cf9/.mindforge/engine/verification-pipeline.md

@@ -1,111 +0,0 @@
-# MindForge Engine — Verification Pipeline
-
-## Purpose
-Automatically verify that a completed phase has actually delivered what it
-promised in REQUIREMENTS.md. This is the agent's self-audit before human UAT.
-
-## Four verification stages
-
-### Stage 1 — Automated test suite
-```bash
-# Run the project's test suite (adapt command to project)
-npm test
-# or
-pytest
-# or
-cargo test
-```
-
-Pass criteria: ALL tests pass, zero failures.
-If any fail: stop. Do not proceed to Stage 2.
-Create fix plans for the failing tests before continuing (e.g., `PLAN-[N]-FIX-01.md`).
-Record in VERIFICATION.md: "Stage 1: FAILED — [X] tests failing"
-
-### Stage 2 — Requirement traceability
-For each functional requirement tagged v1 for this phase in REQUIREMENTS.md:
-
-1. Read the requirement and its acceptance criterion
-2. Search the codebase for the implementation:
-   ```bash
-   grep -r "[key term from requirement]" src/ --include="*.ts"
-   ```
-3. Find a test that covers this requirement:
-   ```bash
-   grep -r "[acceptance criterion term]" tests/ --include="*.test.ts"
-   ```
-4. Classify:
-   - ✅ Implemented and tested
-   - ⚠️  Implemented but no test
-   - ❌ Not found
-
-Any ❌ result: create a fix plan before proceeding to Stage 3.
-Any ⚠️  result: create a test task for the next phase backlog.
-
-### Stage 3 — Type safety and linting (TypeScript/Python projects)
-```bash
-# TypeScript
-npx tsc --noEmit
-npx eslint . --ext .ts,.tsx --max-warnings 0
-
-# Python
-mypy .
-ruff check .
-```
-
-Pass criteria: Zero errors, zero warnings.
-If any errors: create targeted fix tasks. Do not proceed to Stage 4 with errors.
-
-### Stage 4 — Security regression check
-Activate `security-reviewer.md` persona.
-Run the OWASP checklist from `security-review/SKILL.md` against all files
-modified in this phase.
-
-Specifically look for:
-- Any new endpoints without authentication (if the project uses auth)
-- Any new database queries without parameterisation
-- Any new file handling without MIME type validation
-- Any new environment variables without validation at startup
-
-Write findings to `.planning/phases/[N]/SECURITY-REVIEW-[N].md`.
-
-## VERIFICATION.md template
-
-Write to `.planning/phases/[N]/VERIFICATION.md`:
-
-```markdown
-# Phase [N] Verification Report
-
-## Date
-[ISO-8601]
-
-## Stage 1 — Test suite
-- Command: `[test command]`
-- Result: [X] tests passing, [Y] failing
-- Status: ✅ PASS / ❌ FAIL
-
-## Stage 2 — Requirement traceability
-
-| FR ID | Requirement                   | Status | Evidence                        |
-|-------|-------------------------------|--------|---------------------------------|
-| FR-01 | [requirement text]            | ✅     | `src/auth/login.ts:47` + test   |
-| FR-02 | [requirement text]            | ✅     | `src/auth/register.ts:23` + test|
-| FR-03 | [requirement text]            | ⚠️     | `src/auth/reset.ts:15`, no test |
-
-## Stage 3 — Static analysis
-- TypeScript errors: [0 / N]
-- ESLint warnings: [0 / N]
-- Status: ✅ PASS / ❌ FAIL
-
-## Stage 4 — Security regression
-- New endpoints reviewed: [X]
-- New database queries reviewed: [X]
-- Findings: [None / see SECURITY-REVIEW-[N].md]
-- Status: ✅ PASS / ❌ FAIL
-
-## Overall status
-✅ All stages passed — ready for human UAT
-❌ [N] stages failed — fix plans created
-
-## Fix plans created (if any)
-- `PLAN-[N]-FIX-01.md`: [what it fixes]
-```

package/.mindforge/mirrors/mirror-sre-776a1cf9/.mindforge/engine/wave-executor.md

@@ -1,285 +0,0 @@
-# MindForge Engine — Wave Execution Engine
-
-## Core Objective
-
-Orchestrate the parallel and sequential execution of a MindForge phase with atomic reliability and strict dependency enforcement.
-
-## Purpose
-
-Group tasks from the dependency graph into waves and execute each wave.
-Within a wave, all tasks are independent and can run in parallel.
-Between waves, execution is strictly sequential.
-
-## Wave grouping algorithm
-
-### Input
-
-The dependency graph from `dependency-parser.md`.
-
-### Algorithm — Kahn's topological sort (adapted for waves)
-
-```text
-Initialize:
-  remaining = all plan IDs
-  completed = empty set
-  waves = []
-
-Repeat until remaining is empty:
-  current_wave = []
-  for each plan in remaining:
-    if ALL of plan's dependencies are in completed:
-      add plan to current_wave
-  
-  if current_wave is empty AND remaining is not empty:
-    ERROR: circular dependency detected (should have been caught by parser)
-  
-  waves.append(current_wave)
-  completed.add(all plans in current_wave)
-  remaining.remove(all plans in current_wave)
-
-Return waves
-```
-
-### Example output for the 5-plan example above
-
-```text
-Wave 1: [01, 02]          ← No dependencies — run in parallel
-Wave 2: [03, 04]          ← Depend on Wave 1 — run in parallel after Wave 1
-Wave 3: [05]              ← Depends on both Wave 2 tasks — runs after Wave 2
-```
-
-## Wave execution protocol
-
-### Before starting a wave
-
-1. **Nexus Trace:** Call `NexusTracer.startSpan('wave_[W]')`.
-2. **Identity Verification (ZTAI):** 
-   - Call `TrustVerifier.verifyAuditLog('.planning/AUDIT.jsonl')`.
-   - Ensure all `span_completed` events from the previous wave have a valid cryptographic signature and DID.
-3. **Identity-Lock (Tier 3):**
-   - If any task in the upcoming wave involves Tier 3 actions (e.g., modifying `.mindforge/governance/`), ensure the assigned agent DID has `tier >= 3`.
-   - If verification fails or tier is insufficient: **STOP** the phase and report an `identity_lock_violation`.
-4. Confirm all plans in previous wave have:
-   - Status: Completed in SUMMARY file
-   - Git commit SHA recorded
-   - `<verify>` step passed
-   
-   If any plan in the previous wave failed: STOP the entire phase.
-   Do not start the next wave. Report which plan failed and why.
-
-### During a wave — parallel execution
-
-For each plan in the current wave, spawn a subagent with this exact context
-package (see `context-injector.md` for the injection protocol):
-
-### Subagent invocation protocol (runtime-agnostic)
-
-Use the runtime-specific mechanism, but keep the inputs identical:
-
-#### 1. Swarm Check (MindForge V4)
-
-Before spawning any subagent, the executor MUST call `swarm-controller.md`.
-- **Input:** The PLAN file, task name, and file list.
-- **Output:** `single_persona` OR `swarm_cluster(template, leader, members)`.
-
-#### 2. Single Persona Execution
-
-If `single_persona` is returned:
-- **Nexus Trace:** Call `NexusTracer.startSpan('task_[N]-[M]', { parent_span_id: 'wave_[W]' })`.
-- **Claude Code:** spawn a subagent with the context package and the PLAN file.
-- **Antigravity:** spawn an agent via `.agent/` command with the same context.
-- Target: `SUMMARY-[N]-[M].md`.
-
-#### 3. Swarm Cluster Execution (The "Mesh" Mode)
-
-If `swarm_cluster` is returned:
-- **Nexus Trace:** Call `NexusTracer.startSpan('swarm_[N]-[M]', { parent_span_id: 'wave_[W]', template: '[Template]' })`.
-- **Initialize Swarm State:** Create `.planning/phases/[N]/SWARM-STATE-[M].json`.
-- **Spawn Cluster:** Simultaneously spawn all members in the cluster (e.g., Architect, Dev, Security).
-- **Communication:** Agents in the swarm MUST read/write to `SWARM-STATE-[M].json` for coordination.
-- **Consolidation:** The **Swarm Leader** is responsible for collecting all findings and writing a unified `SWARM-SUMMARY-[N]-[M].md`.
-- **Context:** Each agent gets a specialized persona from `persona-factory.md` (weighted by Context7 insights).
-
-**Context package per subagent**
-
-```text
-REQUIRED (always inject):
-  .mindforge/org/CONVENTIONS.md
-  .mindforge/org/SECURITY.md
-  The specific PLAN file (PLAN-[N]-[M].md)
-  The persona file specified in <persona> field
-
-CONDITIONAL (inject only if referenced in plan):
-  .planning/ARCHITECTURE.md      ← if plan touches architecture
-  .planning/decisions/ADR-*.md   ← only ADRs referenced in plan's <context>
-  Relevant SKILL.md files        ← only skills listed in plan's <context>
-
-NEVER inject to subagents:
-  STATE.md        ← subagents do not need project-level state
-  ROADMAP.md      ← subagents do not need project-level roadmap
-  HANDOFF.json    ← subagents do not maintain session continuity
-  Other plans     ← subagents must not see sibling task plans
-```
-
-### After each plan in a wave completes
-
-The executing subagent must:
-1. Run the `<verify>` step and capture output
-2. Write SUMMARY-[N]-[M].md with verify output included
-3. Commit with: `git add [files-in-plan] && git commit -m "type(scope): task name"`
-4. Write an AUDIT entry (see `audit/AUDIT-SCHEMA.md`)
-5. Report completion status back to the orchestrator
-
-### Wave completion
-
-After all plans in a wave complete:
-1. Collect all SUMMARY files from this wave
-2. Run the project's full test suite
-3. If no test command exists yet: STOP and instruct the user to define it
-   in CONVENTIONS.md or add an initial test harness.
-4. If tests fail: identify which plan introduced the failure (use `git bisect`)
-5. Do not start the next wave until all tests pass
-
-## Failure handling
-
-### Task verify failure (mid-wave)
-
-When a task's `<verify>` step fails:
-
-1. **Stop the task immediately.** Do not attempt a second run automatically.
-2. **Write the SUMMARY file** with status `Failed ❌` and the full verify output.
-3. **Write a `task_failed` AUDIT entry** (see AUDIT-SCHEMA.md).
-4. **Stop the entire wave.** Other tasks in this wave that have not yet started:
-   do not start them. Tasks already running in parallel: let them complete
-   naturally, but do not start the next wave regardless of their outcome.
-5. **Report to the orchestrator**
-
-```text
-━━━ Wave [W] STOPPED — Task Failure ━━━━━━━━━━━━━━━━━━━━━━
-Failed task : Plan [N]-[M]: [task name]
-Verify output:
-[full verify output]
-━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
-```
-
-6. **Ask the user**
-
-```text
-Options:
-  1. Spawn debug agent to diagnose the failure
-  2. Show me the failing code and I'll fix it manually
-  3. Skip this task and continue the wave (not recommended)
-  4. Abort the entire phase
-
-Choose 1, 2, 3, or 4:
-```
-
-7. If user chooses 1: invoke `/mindforge:debug` with the failure context pre-loaded.
-8. If user chooses 3 (skip): write a `quality_gate_failed` AUDIT entry with
-   `"gate": "verify_skipped_by_user"` and continue. This is tracked.
-9. If user chooses 4: update STATE.md with `status: Phase [N] aborted` and stop.
-
-### Test suite failure (between waves)
-
-When the test suite fails after a wave completes:
-
-1. **Identify the failing tests** — capture the full test output.
-2. **Identify the likely causal commit**
-
-```bash
-git log --oneline -[number of tasks in this wave]
-```
-
-3. **Report specifically**
-
-```text
-━━━ Test Suite Failure After Wave [W] ━━━━━━━━━━━━━━━━━━━━━
-[N] tests failing.
-
-Likely cause: [commit sha] — [commit message]
-Failing tests:
-  - [test name]: [error]
-  - [test name]: [error]
-━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
-```
-
-4. **Write a `quality_gate_failed` AUDIT entry.**
-5. **Do not start the next wave.** This is absolute — no exceptions.
-6. **Ask the user**
-
-```text
-Options:
-  1. Debug the failing tests now
-  2. Revert the last wave's commits and re-plan
-  3. I'll fix the tests manually — notify me when done
-```
-
-### Subagent hang (no SUMMARY file after expected duration)
-
-When a subagent has been running for an unexpectedly long time:
-(Heuristic: if a task with < 5 files has no SUMMARY after 30 minutes of session time)
-
-1. Alert the user: "Task [N]-[M] appears to be taking longer than expected.
-   Check if the subagent is still running or has stalled."
-2. Provide the option to: wait longer | restart the task | skip the task.
-3. Never silently let a wave stall indefinitely.
-
-### Missing PLAN file detected at runtime
-
-When execute-phase discovers a PLAN file referenced in the dependency graph is missing:
-
-1. Stop immediately.
-2. Report: "PLAN-[N]-[M].md was referenced but does not exist.
-   Run /mindforge:plan-phase [N] to regenerate the missing plan."
-3. Do not continue with partial plan execution.
-
-### Phase completion
-
-After all waves complete:
-1. Run the phase verification pipeline (see `verification-pipeline.md`)
-2. Write VERIFICATION.md
-3. Update STATE.md: phase N = complete
-4. Update HANDOFF.json with next phase information
-
-## Wave execution report format
-
-Write to `.planning/phases/[N]/WAVE-REPORT-[N].md`:
-
-```markdown
-# Wave Execution Report — Phase [N]
-
-## Wave 1
-| Plan | Task Name           | Status | Duration | Commit     |
-| :--- | :--- | :--- | :--- | :--- |
-| 01   | Create user model   | ✅     | ~8 min   | abc1234    |
-| 02   | Create product model| ✅     | ~6 min   | def5678    |
-
-**Wave 1 test results:** All passing ✅
-
-## Wave 2
-| Plan | Task Name             | Status | Duration | Commit     |
-| :--- | :--- | :--- | :--- | :--- |
-| 03   | User API endpoints    | ✅     | ~12 min  | ghi9012    |
-| 04   | Product API endpoints | ✅     | ~10 min  | jkl3456    |
-
-**Wave 2 test results:** All passing ✅
-
-## Wave 3
-| Plan | Task Name     | Status | Duration | Commit     |
-| :--- | :--- | :--- | :--- | :--- |
-| 05   | Checkout UI   | ✅     | ~15 min  | mno7890    |
-
-**Wave 3 test results:** All passing ✅
-
-### Failure row format (if any task fails)
-| Plan | Task Name         | Status | Duration | Commit  | Error |
-| :--- | :--- | :--- | :--- | :--- | :--- |
-| 02   | Create product model | ❌  | ~4 min   | n/a     | Verify failed: TypeError ... |
-
-## Phase summary
-- Total tasks: 5
-- Total commits: 5
-- Elapsed: ~51 min
-- Test results: All passing
-- Status: Phase [N] complete ✅
-```

package/.mindforge/mirrors/mirror-sre-776a1cf9/.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/mirrors/mirror-sre-776a1cf9/.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/mirrors/mirror-sre-776a1cf9/.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/mirrors/mirror-sre-776a1cf9/.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/mirrors/mirror-sre-776a1cf9/.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/mirrors/mirror-sre-776a1cf9/.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`.