mindforge-cc 8.2.0 → 9.0.0

package/.mindforge/mirrors/mirror-sre-776a1cf9/docs/Templates/System/CONTEXT.md

@@ -1,352 +0,0 @@
-# Phase Context Template
-
-Template for `.planning/phases/XX-name/{phase_num}-CONTEXT.md` - captures implementation decisions for a phase.
-
-**Purpose:** Document decisions that downstream agents need. Researcher uses this to know WHAT to investigate. Planner uses this to know WHAT choices are locked vs flexible.
-
-**Key principle:** Categories are NOT predefined. They emerge from what was actually discussed for THIS phase. A CLI phase has CLI-relevant sections, a UI phase has UI-relevant sections.
-
-**Downstream consumers:**
-- `mindforge-phase-researcher` — Reads decisions to focus research (e.g., "card layout" → research card component patterns)
-- `mindforge-planner` — Reads decisions to create specific tasks (e.g., "infinite scroll" → task includes virtualization)
-
----
-
-## File Template
-
-```markdown
-# Phase [X]: [Name] - Context
-
-**Gathered:** [date]
-**Status:** Ready for planning
-
-<domain>
-## Phase Boundary
-
-[Clear statement of what this phase delivers — the scope anchor. This comes from ROADMAP.md and is fixed. Discussion clarifies implementation within this boundary.]
-
-</domain>
-
-<decisions>
-## Implementation Decisions
-
-### [Area 1 that was discussed]
-- **D-01:** [Specific decision made]
-- **D-02:** [Another decision if applicable]
-
-### [Area 2 that was discussed]
-- **D-03:** [Specific decision made]
-
-### [Area 3 that was discussed]
-- **D-04:** [Specific decision made]
-
-### the agent's Discretion
-[Areas where user explicitly said "you decide" — the agent has flexibility here during planning/implementation]
-
-</decisions>
-
-<specifics>
-## Specific Ideas
-
-[Any particular references, examples, or "I want it like X" moments from discussion. Product references, specific behaviors, interaction patterns.]
-
-[If none: "No specific requirements — open to standard approaches"]
-
-</specifics>
-
-<canonical_refs>
-## Canonical References
-
-**Downstream agents MUST read these before planning or implementing.**
-
-[List every spec, ADR, feature doc, or design doc that defines requirements or constraints for this phase. Use full relative paths so agents can read them directly. Group by topic area when the phase has multiple concerns.]
-
-### [Topic area 1]
-- `path/to/spec-or-adr.md` — [What this doc decides/defines that's relevant]
-- `path/to/doc.md` §N — [Specific section and what it covers]
-
-### [Topic area 2]
-- `path/to/feature-doc.md` — [What capability this defines]
-
-[If the project has no external specs: "No external specs — requirements are fully captured in decisions above"]
-
-</canonical_refs>
-
-<code_context>
-## Existing Code Insights
-
-### Reusable Assets
-- [Component/hook/utility]: [How it could be used in this phase]
-
-### Established Patterns
-- [Pattern]: [How it constrains/enables this phase]
-
-### Integration Points
-- [Where new code connects to existing system]
-
-</code_context>
-
-<deferred>
-## Deferred Ideas
-
-[Ideas that came up during discussion but belong in other phases. Captured here so they're not lost, but explicitly out of scope for this phase.]
-
-[If none: "None — discussion stayed within phase scope"]
-
-</deferred>
-
----
-
-*Phase: XX-name*
-*Context gathered: [date]*
-```
-
-<good_examples>
-
-**Example 1: Visual feature (Post Feed)**
-
-```markdown
-# Phase 3: Post Feed - Context
-
-**Gathered:** 2025-01-20
-**Status:** Ready for planning
-
-<domain>
-## Phase Boundary
-
-Display posts from followed users in a scrollable feed. Users can view posts and see engagement counts. Creating posts and interactions are separate phases.
-
-</domain>
-
-<decisions>
-## Implementation Decisions
-
-### Layout style
-- Card-based layout, not timeline or list
-- Each card shows: author avatar, name, timestamp, full post content, reaction counts
-- Cards have subtle shadows, rounded corners — modern feel
-
-### Loading behavior
-- Infinite scroll, not pagination
-- Pull-to-refresh on mobile
-- New posts indicator at top ("3 new posts") rather than auto-inserting
-
-### Empty state
-- Friendly illustration + "Follow people to see posts here"
-- Suggest 3-5 accounts to follow based on interests
-
-### the agent's Discretion
-- Loading skeleton design
-- Exact spacing and typography
-- Error state handling
-
-</decisions>
-
-<canonical_refs>
-## Canonical References
-
-### Feed display
-- `docs/features/social-feed.md` — Feed requirements, post card fields, engagement display rules
-- `docs/decisions/adr-012-infinite-scroll.md` — Scroll strategy decision, virtualization requirements
-
-### Empty states
-- `docs/design/empty-states.md` — Empty state patterns, illustration guidelines
-
-</canonical_refs>
-
-<specifics>
-## Specific Ideas
-
-- "I like how Twitter shows the new posts indicator without disrupting your scroll position"
-- Cards should feel like Linear's issue cards — clean, not cluttered
-
-</specifics>
-
-<deferred>
-## Deferred Ideas
-
-- Commenting on posts — Phase 5
-- Bookmarking posts — add to backlog
-
-</deferred>
-
----
-
-*Phase: 03-post-feed*
-*Context gathered: 2025-01-20*
-```
-
-**Example 2: CLI tool (Database backup)**
-
-```markdown
-# Phase 2: Backup Command - Context
-
-**Gathered:** 2025-01-20
-**Status:** Ready for planning
-
-<domain>
-## Phase Boundary
-
-CLI command to backup database to local file or S3. Supports full and incremental backups. Restore command is a separate phase.
-
-</domain>
-
-<decisions>
-## Implementation Decisions
-
-### Output format
-- JSON for programmatic use, table format for humans
-- Default to table, --json flag for JSON
-- Verbose mode (-v) shows progress, silent by default
-
-### Flag design
-- Short flags for common options: -o (output), -v (verbose), -f (force)
-- Long flags for clarity: --incremental, --compress, --encrypt
-- Required: database connection string (positional or --db)
-
-### Error recovery
-- Retry 3 times on network failure, then fail with clear message
-- --no-retry flag to fail fast
-- Partial backups are deleted on failure (no corrupt files)
-
-### the agent's Discretion
-- Exact progress bar implementation
-- Compression algorithm choice
-- Temp file handling
-
-</decisions>
-
-<canonical_refs>
-## Canonical References
-
-### Backup CLI
-- `docs/features/backup-restore.md` — Backup requirements, supported backends, encryption spec
-- `docs/decisions/adr-007-cli-conventions.md` — Flag naming, exit codes, output format standards
-
-</canonical_refs>
-
-<specifics>
-## Specific Ideas
-
-- "I want it to feel like pg_dump — familiar to database people"
-- Should work in CI pipelines (exit codes, no interactive prompts)
-
-</specifics>
-
-<deferred>
-## Deferred Ideas
-
-- Scheduled backups — separate phase
-- Backup rotation/retention — add to backlog
-
-</deferred>
-
----
-
-*Phase: 02-backup-command*
-*Context gathered: 2025-01-20*
-```
-
-**Example 3: Organization task (Photo library)**
-
-```markdown
-# Phase 1: Photo Organization - Context
-
-**Gathered:** 2025-01-20
-**Status:** Ready for planning
-
-<domain>
-## Phase Boundary
-
-Organize existing photo library into structured folders. Handle duplicates and apply consistent naming. Tagging and search are separate phases.
-
-</domain>
-
-<decisions>
-## Implementation Decisions
-
-### Grouping criteria
-- Primary grouping by year, then by month
-- Events detected by time clustering (photos within 2 hours = same event)
-- Event folders named by date + location if available
-
-### Duplicate handling
-- Keep highest resolution version
-- Move duplicates to _duplicates folder (don't delete)
-- Log all duplicate decisions for review
-
-### Naming convention
-- Format: YYYY-MM-DD_HH-MM-SS_originalname.ext
-- Preserve original filename as suffix for searchability
-- Handle name collisions with incrementing suffix
-
-### the agent's Discretion
-- Exact clustering algorithm
-- How to handle photos with no EXIF data
-- Folder emoji usage
-
-</decisions>
-
-<canonical_refs>
-## Canonical References
-
-### Organization rules
-- `docs/features/photo-organization.md` — Grouping rules, duplicate policy, naming spec
-- `docs/decisions/adr-003-exif-handling.md` — EXIF extraction strategy, fallback for missing metadata
-
-</canonical_refs>
-
-<specifics>
-## Specific Ideas
-
-- "I want to be able to find photos by roughly when they were taken"
-- Don't delete anything — worst case, move to a review folder
-
-</specifics>
-
-<deferred>
-## Deferred Ideas
-
-- Face detection grouping — future phase
-- Cloud sync — out of scope for now
-
-</deferred>
-
----
-
-*Phase: 01-photo-organization*
-*Context gathered: 2025-01-20*
-```
-
-</good_examples>
-
-<guidelines>
-**This template captures DECISIONS for downstream agents.**
-
-The output should answer: "What does the researcher need to investigate? What choices are locked for the planner?"
-
-**Good content (concrete decisions):**
-- "Card-based layout, not timeline"
-- "Retry 3 times on network failure, then fail"
-- "Group by year, then by month"
-- "JSON for programmatic use, table for humans"
-
-**Bad content (too vague):**
-- "Should feel modern and clean"
-- "Good user experience"
-- "Fast and responsive"
-- "Easy to use"
-
-**After creation:**
-- File lives in phase directory: `.planning/phases/XX-name/{phase_num}-CONTEXT.md`
-- `mindforge-phase-researcher` uses decisions to focus investigation AND reads canonical_refs to know WHAT docs to study
-- `mindforge-planner` uses decisions + research to create executable tasks AND reads canonical_refs to verify alignment
-- Downstream agents should NOT need to ask the user again about captured decisions
-
-**CRITICAL — Canonical references:**
-- The `<canonical_refs>` section is MANDATORY. Every CONTEXT.md must have one.
-- If your project has external specs, ADRs, or design docs, list them with full relative paths grouped by topic
-- If ROADMAP.md lists `Canonical refs:` per phase, extract and expand those
-- Inline mentions like "see ADR-019" scattered in decisions are useless to downstream agents — they need full paths and section references in a dedicated section they can find
-- If no external specs exist, say so explicitly — don't silently omit the section
-</guidelines>

package/.mindforge/mirrors/mirror-sre-776a1cf9/docs/adr/ADR-024-browser-localhost-only.md

@@ -1,17 +0,0 @@
-# ADR-024: Browser Daemon Localhost Binding
-
-## Status
-Accepted
-
-## Context
-The MindForge v2 Browser Runtime exposes an HTTP API for controlling a Chromium instance. This API allows for powerful actions like navigation, interaction, and data extraction, which could be exploited if exposed to the network.
-
-## Decision
-We will strictly bind the Browser Daemon to `127.0.0.1` (localhost) only.
-
-1. The HTTP server will only listen on `127.0.0.1`.
-2. The server will perform a secondary check on `req.socket.remoteAddress` to reject any requests not originating from `127.0.0.1`, `::1`, or `::ffff:127.0.0.1`.
-
-## Consequences
-- The daemon cannot be controlled remotely by default, significantly reducing the attack surface.
-- Developers needing remote control must use an explicit SSH tunnel or reverse proxy with authentication.

package/.mindforge/mirrors/mirror-sre-776a1cf9/docs/adr/ADR-025-visual-verify-failure-treatment.md

@@ -1,19 +0,0 @@
-# ADR-025: <verify-visual> Failure Treatment
-
-## Status
-Accepted
-
-## Context
-Visual verification is a critical part of the UI development lifecycle in MindForge v2. Failures in visual verification often indicate broken layouts or missing components that standard unit/integration tests might miss.
-
-## Decision
-Failures within a `<verify-visual>` block in a PLAN file will be treated as fatal errors, equivalent to a `<verify>` (shell command) failure.
-
-1. The wave executor will stop immediately if a visual verification fails.
-2. The user will be notified of the specific failure (e.g., "Element not visible").
-3. Subsequent waves or phase-level verification will not proceed until the failure is resolved.
-
-## Consequences
-- High confidence in UI integrity.
-- Prevents "broken" UI states from being committed to the codebase.
-- May slightly increase development time if visual selectors are brittle.

package/.mindforge/mirrors/mirror-sre-776a1cf9/docs/adr/ADR-026-session-persistence-security.md

@@ -1,20 +0,0 @@
-# ADR-026: Browser Session Persistence and Security
-
-## Status
-Accepted
-
-## Context
-MindForge v2 persists browser sessions (cookies, localStorage) to allow for seamless multi-phase development without re-authentication.
-
-## Decision
-1. Session files will be stored in `.mindforge/browser/sessions/`.
-2. All files in this directory will be explicitly ignored by Git to prevent leaking sensitive credentials (auth tokens).
-3. Session files are JSON-formatted and map directly to Playwright's state format.
-
-## Implementation
-- Update `.gitignore` to include `.mindforge/browser/sessions/`.
-- `session-manager.js` will handle the logic for atomic file writes and reads.
-
-## Consequences
-- Security: Credentials are kept local to the developer's machine.
-- Dev Experience: Sessions persist across restarts of the tool or the daemon.

package/.mindforge/mirrors/mirror-sre-776a1cf9/docs/adr/ADR-042-ads-protocol.md

@@ -1,30 +0,0 @@
-# ADR-042: Adversarial Decision Synthesis (ADS) Protocol
-
-## Status
-
-Accepted (2026-03-26)
-
-## Context
-
-As MindForge moves into the v2.4.0 architectural cycle, architectural planning requires a more robust vetting mechanism than single-agent output. Complex systems require adversarial critique to surface "invisible" flaws in maintainability, security, and scalability.
-
-## Decision
-
-We have implemented the **Adversarial Decision Synthesis (ADS)** protocol. This involves a standardized 3-model loop integrated into the `plan-phase` workflow:
-
-1.  **Blue Team (Architect)**: Generates the initial technical proposal.
-2.  **Red Team (Auditor)**: Performs a high-fidelity critique. Hardened via a "jailbreak" prompt to force the identification of at least 3 critical system flaws.
-3.  **Gold Team (Synthesizer)**: Consolidates the two perspectives and provides an objective **SOUL Score**.
-
-### SOUL Scoring Formula
-
-`Score = (Impact * Leverage * Reversibility) / (Effort * Risk * Cost)`
-
-- **Score > 1.0**: Proceed with implementation.
-- **Score < 1.0**: Requires revision or alternate approach.
-
-## Consequences
-
-- **Improved Quality**: Decisions are vetted by two independent perspectives.
-- **Auditability**: Every synthesis is persisted as a SOUL-scored artifact in `.planning/decisions/`.
-- **Latency/Cost**: Increased token usage and execution time per planning phase (3 models instead of 1).

package/.mindforge/mirrors/mirror-sre-776a1cf9/docs/architecture/NEXUS-DASHBOARD.md

@@ -1,35 +0,0 @@
-# MindForge Nexus: Observability Dashboard
-
-## Vision
-The Nexus Dashboard provides real-time visibility into the "thought chains" of the agentic mesh. It transforms the linear `AUDIT.jsonl` into a hierarchical, interactive visualization of reasoning and execution waves.
-
-## Core Views
-
-### 1. Mesh Trace View (Gantt/Waterfall)
-- **Trace Visualization:** Displays hierarchical spans (Waves -> Clusters -> Tasks).
-- **Critical Path Highlighting:** Identifies bottlenecks in parallel wave execution.
-- **Span Metadata:** Hovering over a span reveals the agent persona, trust tier, and execution time.
-
-### 2. Reasoning Heatmap (ART)
-- **Density Maps:** Visualizes where the agents are performing the most "Thinking" (debate cycles).
-- **ADS Breakdown:** Highlights Adversarial Decision Synthesis debates between specialists (e.g., Security vs Dev).
-- **Thought Stream:** Real-time feed of `reasoning_trace` events.
-
-### 3. ZTAI Trust Heatmap
-- **Security Posture:** Real-time visibility into which tasks are running in which Trust Tier (0-3).
-- **Policy Violations:** Instant alerts when an agent attempts to bypass a HITL decision gate.
-
-## Technical Stack
-- **Engine:** Next.js (React) + D3.js for complex tree visualizations.
-- **Data Source:** Tail-following parser for `.planning/AUDIT.jsonl`.
-- **State Management:** Zustand for real-time trace aggregation.
-
-## API Hooks
-```javascript
-// Example Dashboard Feed Hook
-const useNexusFeed = () => {
-  // Listen for new AUDIT.jsonl entries
-  // Reconstruct span hierarchy on the fly
-  // Return nodes and edges for D3 renderer
-};
-```

package/.mindforge/mirrors/mirror-sre-776a1cf9/docs/architecture/PAR-ZTS-SURVEY.md

@@ -1,43 +0,0 @@
-# PAR & ZTS Architectural Survey — MindForge v5
-
-## Pillar III: Predictive Agentic Reliability (PAR)
-
-Predictive Agentic Reliability (PAR) addresses the "Reasoning Decay" problem in long-running autonomous sessions. It implements proactive monitoring and self-healing at the reasoning layer.
-
-### 1. Stuck Detection (S03 & S04)
-The `StuckMonitor` has been extended to detect advanced reasoning loop patterns:
-- **S03 (Semantic Mirroring)**: Detects when the agent paraphrases its own previous thoughts without taking new actions.
-- **S04 (Infinite Decomposition)**: Detects when the agent breaks sub-tasks into smaller and smaller pieces indefinitely without resolving the parent task.
-
-### 2. Context Refactoring
-The `ContextRefactorer` monitors "Context Density" (the ratio of implementation actions to reasoning thoughts).
-- When density falls below 30%, it triggers a proactive **Refactor Event**.
-- This encourages the agent to summarize its progress and reset its active context window, preventing bloat.
-
-### 3. C2C Arbitrage
-Confidence-to-Cost (C2C) arbitrage ensures that the agent only continues execution when the expected value (confidence) exceeds the operational cost (tokens/compute).
-
----
-
-## Pillar IV: Supply Chain Trust (ZTS)
-
-Supply Chain Trust (ZTS) ensures that every asset (skill, model, tool) used by MindForge is authenticated and verified against enterprise standards.
-
-### 1. Agentic SBOM (Software Bill of Materials)
-MindForge now generates a real-time `MANIFEST.sbom.json` during every autonomous run.
-- **Model Tracking**: Logs the exact model version used for every reasoning span.
-- **Skill Telemetry**: Tracks which skills were invoked and their specific versions.
-- **Timestamping**: Captures full start/end telemetry for supply chain auditing.
-
-### 2. 7-Dimension Certification (7D)
-Skills are now evaluated across 7 weighted dimensions:
-1. **Schema Compliance (15%)**
-2. **Trigger Density (15%)**
-3. **Mandatory Coverage (20%)**
-4. **Security Sanitization (20%)**
-5. **Doc Clarity (10%)**
-6. **Edge Case Handling (10%)**
-7. **Example Fidelity (10%)**
-
-> [!IMPORTANT]
-> In `--enterprise` mode, skills must achieve a minimum score of **7.0/10.0** to be loaded.

package/.mindforge/mirrors/mirror-sre-776a1cf9/docs/architecture/README.md

@@ -1,78 +0,0 @@
-# MindForge Architecture Overview
-
-MindForge v6.0.0 is built on a distributed "Agentic OS" architecture, designed for enterprise-scale intelligence sharing and absolute governance.
-
----
-
-## 1. Core Architectural Pillars (v6.0.0)
-
-The framework is focused on eight major pillars, with V6 introducing the **Neural Blast Radius Optimizer (CADIA)**:
-
-1. **Federated Intelligence Mesh (FIM)**: Distributed knowledge sharing with delta-sync and cryptographic provenance. [V5-ENTERPRISE.md](./V5-ENTERPRISE.md)
-2. **CADIA Engine (v6.0.0 Alpha)**: Neural Blast Radius Optimizer that calculates real-time architectural risk based on influence, entropy, and alignment.
-3. **Predictive Agentic Reliability (PAR)**: Self-healing reasoning loops and context refactoring. [PAR-ZTS-SURVEY.md](./PAR-ZTS-SURVEY.md)
-4. **Supply Chain Trust (ZTS)**: Agentic SBOM and 7-dimension skill certification. [PAR-ZTS-SURVEY.md](./PAR-ZTS-SURVEY.md)
-5. **Zero-Trust Agentic Identity (ZTAI)**: DID-based cryptographic signing for all agentic actions and tiered trust enforcement.
-6. **Adversarial Decision Synthesis (ADS)**: 3-model synthesis loop ensuring architectural integrity.
-7. **Semantic Context Sharding**: Tri-tier memory (Hot/Warm/Cold) for high-fidelity context management.
-8. **Autonomous Execution Engine**: Self-healing wave execution with stuck-detection and repair hierarchies.
-
----
-
-## 2. Directory Hierarchy
-
-MindForge uses a "Tiered Configuration" model allowing for global, organizational, and project-specific rules.
-
-| Directory | Scope | Purpose |
-| :--- | :--- | :--- |
-| **EIS / Mesh** | `bin/memory` | Core FIM implementation (eis-client, federated-sync). |
-| **Governance** | `bin/governance` | Core APO implementation (policy-engine, rbac-manager). |
-| `.mindforge/` | System/Global | Core personas, core skills, and engine protocols. |
-| `.agent/` | Project/Local | Project-specific configuration, hooks, and local skill overrides. |
-| `.planning/` | Session/State | Ephemeral state, task blocks, and session handoffs. |
-
----
-
-## 3. The Unified Registry (`file-manifest.json`)
-
-The `file-manifest.json` file in `.agent/` is the single source of truth for the framework's file system mapping. It allows MindForge to resolve command paths, skills, and templates regardless of whether it's running in Claude Code, Antigravity, or Cursor.
-
----
-
-## 4. Runtime Execution Flow (V5 Hardened)
-
-1.  **Context Loading**: Load `MINDFORGE.md` and `file-manifest.json`.
-2.  **Identity Verification**: Resolve the agent's ZTAI identity and trust tier.
-3.  **Policy Interception**: The `APO` evaluates the task intent. If not **PERMIT**, the session is halted.
-4.  **Skill Discovery**: Match task intent against the 3-tier skill registry.
-5.  **Execution Wave**: Parallel task execution with continuous FIM synchronization.
-6.  **Audit Pulse**: All actions are cryptographically signed and appended to `.planning/AUDIT.jsonl`.
-
----
-
-## 5. Decision Records & Stability
-
-MindForge provides stable interfaces for extension while documenting every major design shift via ADRs.
-
-- **ADR Index**: See [decision-records-index.md](./decision-records-index.md).
-- **V3 Core**: See [V3-CORE.md](./V3-CORE.md).
-- **V4 Mesh**: See [V4-SWARM-MESH.md](./V4-SWARM-MESH.md).
-- **V5 Enterprise**: See [V5-ENTERPRISE.md](./V5-ENTERPRISE.md).
-
----
-
-## 6. Semantic Memory Tiering (V3/V4)
-
-| Tier | Storage | Purpose | Retrieval |
-| :--- | :--- | :--- | :--- |
-| **HOT** | `HANDOFF.json` | Immediate task state and core ADRs (SRD > 0.8). | Loaded every session. |
-| **WARM** | `.planning/memories/` | Phase-specific shards and active project context (SRD 0.5-0.8). | Proactive retrieval. |
-| **COLD** | `.mindforge/memory` | Global knowledge base and historical logs (SRD < 0.5). | Federated search (FIM). |
-
----
-
-## 7. Adversarial Decision Synthesis (ADS)
-
-MindForge v3.0.0 introduces **Adversarial Decision Synthesis (ADS)**, a 3-model synthesis loop that ensures every architectural decision is battle-tested using the **SOUL.md** scoring algorithm.
-
----

package/.mindforge/mirrors/mirror-sre-776a1cf9/docs/architecture/V3-CORE.md

@@ -1,52 +0,0 @@
-# MindForge V3 Core Architecture: Reactive Autonomous Intelligence
-
-## Overview
-MindForge V3 represents a fundamental shift from a "disciplined workflow engine" to a **Reactive Autonomous Intelligence**. This document defines the four core systems that enable sub-second architectural reasoning and zero-waste context management.
-
----
-
-## 1. Tri-Tier Memory (Semantic Sharding)
-Instead of linear compaction, V3 manages context via **Semantic Relevance Density (SRD)**.
-
-- **Hot (Execution Log)**: Non-compressed RAM buffer for the current task sequence.
-- **Warm (Decision Mesh)**: Context-aware shards retrieved via vector matching (Local SSD).
-- **Cold (Architectural Core)**: Permanent project history and ADRs (Vector DB).
-
-**Mechanism**: When a task is initiated, the `ContextInjector` pulls "ghost patterns" from Warm/Cold tiers into the Hot buffer based on semantic overlap.
-
----
-
-## 2. Adversarial Decision Synthesis (ADS)
-Architectural drift is prevented through a three-model adversarial loop.
-
-| Role | Strategy | Objective |
-| :--- | :--- | :--- |
-| **Blue Team** | Optimal/Performant | Propose the most robust solution. |
-| **Red Team** | Minimal/Maintainable | Challenge complexity and bloat. |
-| **Synthesizer** | Balanced/Grounded | Score the debate against `SOUL.md` and merge. |
-
-**Output**: A `DECISION_SCORE` is assigned to every major change, ensuring zero logic-drift over long sessions.
-
----
-
-## 3. RAG 2.0 (Automatic Semantic Shadowing)
-Knowledge capture is now a background process.
-
-- **Auto-Shadowing**: Every `implicit_knowledge` item captured during compaction is automatically indexed by the local embedding engine.
-- **Reasoning Graph**: Interconnected nodes linking Decisions, Failures, and Skills are visible in the Dashboard for real-time observability.
-
----
-
-## 4. Temporal Vision (Observability & Hindsight)
-Full state-fidelity across the execution wave.
-
-- **Temporal Hub**: Synchronous snapshots of the entire `.planning/` state on every state-changing event.
-- **Hindsight Injection**: Enables precise rollback to any coordinate ($T_{coord}$) to inject corrections and re-generate the downstream dependency wave.
-- **Temporal API**: RESTful interface for the Dashboard's Temporal Slider.
-
----
-
-## V3 Governance Rules
-1. **Zero Watermark**: All documentation and code must be strictly MindForge-branded.
-2. **Context-First**: Execution cannot start without a `Semantic Shard` match.
-3. **Draft-Adversarial**: No code enters production without an ADS review.