mindforge-cc 8.1.0 → 8.2.0

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

@@ -0,0 +1,111 @@
+# 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

@@ -0,0 +1,285 @@
+# 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

@@ -0,0 +1,17 @@
+# 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

@@ -0,0 +1,37 @@
+# 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

@@ -0,0 +1,63 @@
+# 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

@@ -0,0 +1,31 @@
+# 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

@@ -0,0 +1,16 @@
+{
+  "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

@@ -0,0 +1,27 @@
+# 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`.