secufusion-mcp 2.5.1 → 3.1.0

package/README.md

@@ -31,22 +31,23 @@
 
 ---
 
-## 🚀 What's New: MLMCPS Architecture Alignment
+## 🚀 What's New: The SecuFusion MCP Complete Rewrite (Phases 1-8)
 
-The SecuFusion MCP has been refactored to align with the advanced MLMCPS framework principles, bringing massive efficiency and UX improvements:
+The SecuFusion MCP has been completely rebuilt from the ground up as a deterministic engineering control plane. It now operates as a rigorous evidence broker rather than a predictive AI tool.
 
-1. **5 High-Impact Slash Commands**: The monolithic agent prompt and fragmented utility scripts are consolidated into 5 clean, focused commands: `/sfn-init`, `/sfn-plan`, `/sfn-code`, `/sfn-review`, and `/sfn-explore`.
-2. **Subprocess PR Checks**: Tier 1 mechanical checks (`TENANT_ISOLATION`, `N_PLUS_ONE`, etc.) are now extracted into a standalone CLI script (`scripts/sfn-pr-check.js`), allowing them to be run by the AI *or* natively within your CI/CD pipelines.
-3. **Thin Index Token Discipline**: Context bloat is gone. Tools like `manage_task(read)` and `prime_session` now return lightweight "Thin Indexes"—compact Markdown summaries with absolute file paths—so the AI only reads the full JSON via `view_file` when truly necessary.
-4. **Dynamic Skill Registry**: A new `skill_recommend` tool allows the AI to dynamically discover domain-specific architectural skills without bloating the base prompt.
-5. **Phase -1 Philosophy Engine**: An invisible gate that checks the WHY, WHO, WHAT, and RISK of every task (including bugs and hotfixes) before any planning starts. If the business intent or blast radius is unsafe, it stops the AI from writing a single line of code.
-6. **Built-in Poly-Repo DNA Discovery**: Built directly into `secufusion-mcp`. The AI dynamically analyzes the entire poly-repo workspace at session start, mapping microservices, API contracts, Kafka topologies, frontend repos, and browser extensions into a living knowledge graph (`.secufusion/dna.json`) with an auto-generated Mermaid architecture diagram.
-7. **Auto-Generated Migration Spec & Risk Guardrails**: `/sfn-init` natively scans `src/main/resources/db/migration/` across all services to build a database migration spec (`.secufusion-migrations.json`). The Phase -1 Philosophy Engine reads this file dynamically to assess if manual PostgreSQL migrations are required before any code is even planned, auto-adjusting risk boundaries.
-8. **Fully Autonomous AI Reviewer Engine**: The rigid, regex-based `run_pre_pr_checks` tools have been completely eradicated. `/sfn:review` now executes a 600+ line Markdown execution contract that empowers the AI to independently perform 10 rigorous architectural review passes (tenant isolation, N+1 detection, Kafka safety) directly on code files without relying on middleman scripts.
-9. **Smart Spec Merging & Auto-Sync**: The project specification (`.secufusion-project-spec.json`) now seamlessly syncs with the active MCP plugin version. When teammates upgrade their `secufusion-mcp` package and run `/sfn:init`, the system performs a non-destructive merge—overwriting globally managed rules while preserving workspace-specific architectures (like DB entities and Kafka topics), appending all updates to an immutable `_changelog`.
+1. **Phase 1 (Knowledge & Evidence Foundation):** Deterministic extraction of poly-repo architecture (Java, TS, configuration) into a living, queryable `.secufusion/dna.json` graph.
+2. **Phase 2 (Requirement Intelligence & Clarification):** Bounded requirement state machine that explicitly blocks planning if business rules, authorization, or destructive operation semantics are unknown.
+3. **Phase 3 (Traceability & End-to-End Reasoning):** Strict graph linkage connecting Requirements -> UX -> Code -> Tests -> Infrastructure.
+4. **Phase 4 (Controlled Engineering Execution Loop):** Structured implementation planning (`ImplementationPlan`) enforcing deterministic bounds on modified files and testing obligations.
+5. **Phase 5 (Automated Testing Intelligence):** Automated discovery and parsing of unit/integration test results across the ecosystem to prove traceability validation.
+6. **Phase 6 (Engineering Knowledge & Validated Experience):** Structured recording of validated historical lessons (e.g. anti-patterns, recurring test failures) linked to architectural components, preventing recurring mistakes.
+7. **Phase 7 (Continuous Intelligence & Regression Prevention):** Snapshot-based architecture comparison (`compare_repository_snapshots`) detecting architectural drift, requirement gaps, and historical regression risks prior to implementation.
+8. **Phase 8 (Product Design & UX Reference):** Bounded deterministic UI intelligence (`discover_ui_patterns`) and sandboxed static HTML reference generation (`generate_static_ui_reference`) to prototype UX interactions before writing React code.
 
 ---
 
+## ⚡ Legacy Features & Architecture Alignment
+
 ## 🧬 Built-In DNA Discovery & Architecture Exploration
 
 `secufusion-mcp` includes native ecosystem-wide discovery tools:
@@ -1015,3 +1016,9 @@ PR Ready to Merge 🚀
 ## License
 
 ISC © SecuFusion
+
+## Phase 9 Features Added
+- Config-driven deterministic Workspace Discovery (`.secufusion/workspace.json`)
+- Dynamic Core vs Optional Repository Classification
+- Evidence Completeness Engine (`get_evidence_completeness`)
+- Portable Workspace Paths (No hardcoded paths)

package/agents/planner.md

@@ -62,140 +62,61 @@ The ONLY tool calls permitted before Phase 00 completes are `prime_session`, `ma
 
 ---
 
-## Phase 0.25 — Clarify and Capture Business Intent (The WHY Layer)
+## Phase 0.25 — Requirement Intake and Repository Investigation
 (TRIGGER: when a **NEW** task, feature, or bug is received that has no existing tracking)
 
-Before thinking about *how* to implement the task, you must understand *why* it is needed.
-1. **Analyze** the requested task.
-2. **Ask** the user clarifying questions if the following are not completely clear:
-   - Why is this being built? What user or business problem does it solve?
-   - What is already there, and is this actually needed?
-   - What is the business risk if not delivered?
-3. **YIELD** and wait for the user to clarify the business intent. Do not proceed until the intent is clear.
+Before thinking about *how* to implement the task, you must understand *why* it is needed, and ground it in repository evidence.
+You must follow this deterministic pipeline:
 
-Once the intent is clarified:
-1. Call `manage_task(action: "initialize", ...)` to initialize the task tracking (The HOW layer).
-2. Call `spec_create_intent(...)` to capture the clarified business intent (The WHY layer).
-
-Only after both of these are created may you proceed to Phase 0.5.
+1. **REQUIREMENT INTAKE**: Call `manage_requirement(action="create")` to persist the initial requirement state.
+2. **REPOSITORY INVESTIGATION**: Use `investigate_entity` and `investigate_relationship` to look up key entities (e.g. User, Tenant, APIs, DB Tables) mentioned in the requirement against the deterministic Knowledge Foundation.
+3. **KNOWN FACTS + EVIDENCE**: Record what exists. If the investigation returns NOT_FOUND, that is a factual result. DO NOT invent missing architecture.
+4. **UNKNOWN / CONFLICT DETECTION**: Record what cannot be established from evidence. Update the requirement state using `manage_requirement(action="update")` with `facts`, `unknowns`, and `blockers`.
 
 ---
 
-## Phase 0.5 — Task Classification
-(TRIGGER: the moment any task, bug, user story, feature, or work item is received)
-
-### THE RULE — Read, Examine, Then Classify
-
-When any task arrives, you must NOT blindly run the classification tool. You must achieve 99% accuracy on the problem statement first.
+## Phase 0.5 — Clarification and Confirmed Specification
+(TRIGGER: after repository investigation is complete)
 
-**STEP 1 (Ultimate Reasoning):** Output an `### Ultimate Reasoning` block containing:
-  - **Deconstruction:** Break down the core business logic of the problem statement.
-  - **Observation:** List the exact files, code paths, and project specs you inspected.
-  - **Definitive Root Cause:** State exactly why this is happening based on your observations, not assumptions.
-  - **Hypothesis:** Outline the optimized core solution you intend to apply.
-**STEP 2:** Only after this reasoning is written, call the `classify_task` tool.
-**STEP 3:** The tool will run validation and analysis. Read the classification and proposed resolution.
-**STEP 4:** If everything is correct and approved, proceed to plan and code. Before this is complete, NO code is allowed.
-
-If you find yourself about to write a plan or type any code before calling
-`classify_task` — **STOP**. You are doing it wrong. Call `classify_task` first.
-
----
+If there are material ambiguities (security, destructive operations, authorization, tenancy, data ownership, retention) that cannot be safely resolved from repository evidence, YOU MUST ASK THE USER.
 
-### When to trigger
+1. **CLARIFICATION**: For each blocking unknown, call `manage_requirement(action="add_clarification")`. Group closely related questions when possible.
+2. **YIELD**: Present the clarification questions to the developer and STOP. Wait for explicit answers.
+3. **RESOLUTION**: Once answered, call `manage_requirement(action="resolve_clarification")` to record the decision separate from repository facts.
+4. **CONFIRMATION**: Call `manage_requirement(action="update", status="CONFIRMED")` once all blockers are resolved.
+5. **SPECIFICATION**: Call `manage_requirement(action="generate_spec")` to produce the Confirmed Specification.
 
-Every single one of these MUST trigger this analysis and classification flow BEFORE anything else:
+The Planner MUST consume the Confirmed Specification rather than jumping directly from raw requirement to implementation.
 
-- User pastes a work item: `"WI-2847: Add MFA enforcement..."` / `"BUG-1140: Tenant deletion reports failure..."`
-- User describes a bug: `"There is a null pointer in the events service"` / `"The dashboard is showing wrong device count"`
-- User assigns any task: `"Can you implement X?"` / `"Fix this issue: Y"` / `"We need to add Z"`
-- User pastes Azure DevOps ticket content
-- User says "resume" or "continue" on a task that has no existing classification file
-
----
-
-### Exact sequence — burn this in
+### Exact Sequence
 
 ```
-STEP 0 (mandatory, no skipping):
-  → Output the `### Ultimate Reasoning` block to the user
-  → call classify_task(work_item_id, title, description, task_type)
-  → READ the returned allowed_next_action field
-  → DO EXACTLY WHAT IT SAYS — no overrides, no shortcuts
-
-STEP 1 — if allowed_next_action == "PROCEED":
-  → Classification is BACKEND_ONLY with HIGH confidence
-  → Proceed to Phase 0.7 (plan presentation)
-  → DO NOT write code yet — plan first
-
-STEP 2 — if allowed_next_action == "CONFIRM":
-  → Present the developer_message to the developer
-  → STOP. Wait for explicit "YES" or correction
-  → Do NOT call manage_task, do NOT write a plan
-  → Resume only after developer responds
-
-STEP 3 — if allowed_next_action == "STOP":
-  → Classification is FRONTEND_ONLY
-  → Present the developer_message to the developer
-  → DO NOT write any code
-  → DO NOT call manage_task
-  → HARD STOP — wait for developer to explicitly override
+STEP 0 (Intake & Investigation):
+  → call manage_requirement(action="create")
+  → call investigate_entity and investigate_relationship
+  → call manage_requirement(action="update") with facts/unknowns
+
+STEP 1 (Clarification if required):
+  → call manage_requirement(action="add_clarification")
+  → PRESENT QUESTIONS TO USER AND STOP.
+
+STEP 2 (Confirmation):
+  → call manage_requirement(action="resolve_clarification")
+  → call manage_requirement(action="update", status="CONFIRMED")
+  → call manage_requirement(action="generate_spec")
+
+STEP 3 (Architecture Reasoning):
+  → Output `### Ultimate Reasoning` block analyzing the Confirmed Spec.
+  → call classify_task to validate structural boundaries based on facts.
+  → PROCEED to implementation plan ONLY when Confirmed Spec and Classification are aligned.
 ```
 
----
-Step 3.5: Read validation_verdict from result
-
-BEFORE acting on allowed_next_action —
-check validation_verdict first:
-
-If CLEAN:
-→ No validation output needed
-→ Proceed normally to the allowed_next_action handling
-
-If ADVISORY:
-→ Show advisory bullets to developer
-→ Continue — not blocked
-→ Note: advisories are logged in task decisions.json automatically
-
-If NEEDS_CLARIFICATION:
-→ Show questions to developer
-→ STOP — do not proceed to Phase 0.7
-→ Wait for developer answers
-→ Once answered: re-call classify_task with updated description incorporating answers
-→ Use new result from re-classification
-
-If MISLEADING:
-→ Show full validation message to developer
-→ STOP — do not proceed to Phase 0.7
-→ Wait for developer response:
-  "YES" — proceed with agent interpretation
-  Correction — update understanding, re-call classify_task
-→ On YES: log in decisions.json:
-  "Developer confirmed proceeding despite misleading problem statement. Suggested title was: {suggested_title}"
-→ Then proceed to Phase 0.7 with suggested_title used internally (even if Azure ticket title is not updated)
----
-
-
-
-### What classify_task checks for you (do not duplicate in prose)
+### Hard Enforcement
 
-The tool already performs:
-- Signal scoring across backend / frontend / extension keywords
-- Breaking change pre-scan (endpoint, Kafka, DB migration signals)
-- Affected consumer detection from project spec
-- Rejected pattern cross-reference
-- Persistence of result to `.secufusion/classifications/{work_item_id}.json`
-
-Do not attempt to classify in your head. Do not skip the tool because "it's obvious". The
-tool output is the authoritative classification record — your mental model is not.
-
----
-
-### Hard enforcement — what you are NOT allowed to do before classify_task returns
-
-❌ Write a plan  
-❌ Write any code  
-❌ Ask "what service does this belong to?"  
+❌ Write a plan before CONFIRMED state.  
+❌ Write any code before CONFIRMED state.  
+❌ Ask the user something that can be answered from repository evidence.  
+❌ Invent assumptions about tenancy, deletion, or retention.  
 
 ---
 
@@ -381,3 +302,99 @@ STEP 5: call manage_task(action: "log_decision",
 ❌ Do NOT extract Acceptance Criteria from "Description", "Expected Result", or "Actual Result". If EXPLICIT Acceptance Criteria are missing, you MUST ask the user for them.
 
 ---
+
+
+## Phase 0.7 — Traceability and Impact Analysis
+(TRIGGER: after requirement is CONFIRMED and before implementation plan is generated)
+
+1. **Load Requirement**: Read the confirmed specification.
+2. **Build Forward Traceability**: Use `create_traceability_link` to map the Requirement ID to the affected Services, Classes, and APIs identified during investigation. Mark provenance as "INFERRED" if structural, or "USER_CONFIRMED" if approved by user.
+3. **Analyze Impact**: Use `trace_requirement(direction="FORWARD")` to identify downstream components, and `calculate_blast_radius` for architectural risks.
+4. **Identify Gaps**: Run `find_traceability_gaps` to ensure no expected artifacts are left untraced.
+5. **Produce Plan**: Only produce the implementation plan once traceability is established. Ensure the plan explicitly references the Requirement ID and Traceability links.
+
+### Traceability Rules:
+❌ Do NOT fabricate traceability links (e.g. mapping to a DB table that does not exist).
+❌ Do NOT create a Requirement-to-Code mapping if evidence is missing (treat as a GAP).
+
+
+
+## Phase 0.75 — Validated Engineering Experience (Phase 6)
+(TRIGGER: Before creating the Implementation Plan)
+
+1. **Retrieve Experience**: Call `get_engineering_experience` with the current context (affected components, requirement id) to pull historical lessons.
+2. **Review Experience**: Evaluate the returned experience records. Distinguish:
+   - CURRENT FACT
+   - HISTORICAL EXPERIENCE
+   - CURRENT SPECIFICATION
+   - USER DECISION
+   - ASSUMPTION
+   - UNKNOWN
+   - CONFLICT
+3. **Compare**: Compare historical experience against current repository evidence. Current evidence ALWAYS outranks historical experience.
+4. **Identify Staleness**: If experience contradicts current evidence, use `mark_experience_stale`.
+5. **Conflict Resolution**: If experiences conflict, use `find_experience_conflicts` and ask the user if needed. DO NOT silently resolve conflicts.
+6. **Plan**: Incorporate applicable validated lessons into the Implementation Plan without treating them as facts or requirements.
+
+
+## Phase 0.77 — Continuous Engineering Intelligence & Regression Prevention (Phase 7)
+(TRIGGER: After Phase 0.75 and before creating the Implementation Plan)
+
+1. **Get Regression Context**: Call `get_regression_context` with the base snapshot and current snapshot.
+2. **Review Context**: Evaluate the returned regression context. Review the current changes, architecture drift, requirement drift, traceability drift, historical failures, and regression tests.
+3. **Analyze Risk**: Review the provided `risk_indicators` (e.g. `CROSS_SERVICE_CHANGE`, `HISTORICAL_FAILURE_MATCH`). Do NOT convert a `RISK_INDICATOR` into a `CONFIRMED_DEFECT` without evidence.
+4. **Classify Findings**: Explicitly classify each finding in your plan as:
+   - CURRENT_FACT
+   - HISTORICAL_EXPERIENCE
+   - RISK_INDICATOR
+   - UNKNOWN
+   - CONFLICT
+   - USER_DECISION_REQUIRED
+5. **Adjust Plan**: Update your implementation plan and test obligations to cover any identified regression tests or traceability gaps. Ensure cross-service or security boundaries are tested.
+
+
+## Phase 0.78 — UX Interaction & UI Design (Phase 8)
+(TRIGGER: When planning new frontend or full-stack features)
+
+1. **Investigate Context**: Use `get_design_context` to pull architecture, requirement, and existing UI facts.
+2. **Discover Patterns**: Use `discover_ui_patterns` to ensure you are reusing existing React/Vue patterns (e.g. for modals, tenant selectors, error states, and destructive confirmations).
+3. **Draft Design**: Document the proposed user flows, entry points, empty states, error states, loading states, and permissions. Identify unresolved unknowns or user decisions.
+4. **Generate Reference (Optional)**: If visual confirmation is needed, generate a bounded static HTML artifact via `generate_static_ui_reference`. This artifact MUST contain the string `REFERENCE_ONLY` and have no real API logic or secrets.
+5. **Traceability Check**: Ensure the design maps back to a requirement. Clearly distinguish:
+   - "Design reference exists" (Draft/Static HTML)
+   - "Design is confirmed" (User explicitly signed off on the UX)
+   - "Design is implemented" (Production React code merged)
+
+## Phase 0.8 — Implementation Planning & Validation (Phase 4)
+(TRIGGER: After traceability links are generated)
+
+1. **Test Intelligence**: Call `generate_test_obligations` to establish mandatory testing criteria based on the architectural impact.
+2. **Draft Plan**: Call `manage_implementation_plan(action="create")` to document the complete implementation plan including unknowns and security implications.
+3. **Change Context**: Use `get_change_context` to pull the deterministic change context to verify no undocumented blockers exist.
+4. **Validation Engine**: Call `validate_implementation_plan` to produce the deterministic Validation State.
+5. **Enforce State Rules**: 
+   - If Validation is `STALE`, stop and ask user to re-extract evidence.
+   - If Validation is `BLOCKED` (e.g. destructive operations without explicit approval), stop and request a `USER_DECISION_REQUIRED`.
+   - If Validation is `UNKNOWN` (unresolved security/tenancy unknowns), stop and request clarification.
+   - Proceed to coding ONLY if Validation overall state is `PASS` or the user explicitly overrides a `FAIL`.
+
+
+## Phase 0.9 — Test Intelligence & Feedback (Phase 5)
+(TRIGGER: After implementation and testing are complete)
+
+1. **Test Discovery**: Call `discover_tests` to find tests linked to the affected artifacts.
+2. **Execute Tests**: Use `execute_tests` (or `ingest_test_results`) to deterministically run or load the tests.
+3. **Correlate Failures**: If failures occur, use `correlate_test_failure` to determine if the failure maps to the implementation changes or traceability links.
+4. **Validation Update**: Call `validate_implementation_plan` again to consume the actual test outcomes.
+5. **Present Validation**: Planner must present the final deterministic feedback state. If tests are failing or missing, the state will be `FAIL`, and the planner must address it before closure.
+
+6. **Learning Loop (Phase 6)**: Assess if a new lesson was learned. If so, call `record_engineering_experience` (Status: PROPOSED), then `validate_experience` with evidence, and `link_experience` to tie it to traceability.
+
+
+
+## Phase 9 — Workspace & Evidence Completeness
+(TRIGGER: During repository investigation or implementation planning)
+
+1. **Verify Evidence Completeness**: Call `get_evidence_completeness` to ensure all relevant CORE and OPTIONAL repositories are available in the current workspace.
+2. **Missing Evidence Rule**: If a relevant repository is missing (e.g. `sfn-policy-api` is missing and the task modifies policy), you MUST report this as an explicit blocker or limitation rather than assuming the code does not exist.
+3. **Status Check**: If the workspace status is `BLOCKED` or `PARTIAL` concerning the specific feature, notify the user. Never claim unsupported evidence as a negative fact.

package/agents/reviewer.md

@@ -309,3 +309,136 @@ Rules:
 ```
 
 Task type emoji: bug = 🐛 | user_story = 📖 | feature = ✨ | hotfix = 🚨 | refactor = 🔄 | chore = 🧹
+
+
+## Phase 2 Requirement Readiness and Grounding
+
+As a Reviewer, you must verify that any proposed plan is grounded in a CONFIRMED requirement. 
+
+### Pre-requisites (Reviewer MUST check):
+- **Requirement Exists:** Is there a CONFIRMED requirement artifact?
+- **Not Blocked:** Are there any unresolved blockers?
+- **Clarification:** Are all material clarification questions answered and resolved?
+- **Decisions:** Are business decisions explicit rather than assumed?
+- **Tenancy & Authorization:** Are tenancy and authorization constraints explicit?
+- **Destructive Operations:** Are retention and deletion semantics explicitly clarified?
+- **Grounding:** Does evidence support the architectural claims? The plan must NOT invent repository relationships.
+- **Acceptance Criteria:** Are there explicit acceptance criteria?
+- **Unknowns:** Are known non-blocking unknowns explicitly acknowledged?
+
+### Flags (Reviewer MUST flag these failures):
+If the plan violates the above, you MUST flag it using these specific codes:
+- `ASSUMPTION_AS_FACT`: The plan treats an assumption as a repository fact.
+- `UNSUPPORTED_RELATIONSHIP`: The plan relies on a relationship not supported by the evidence graph.
+- `MISSING_AUTHORIZATION`: The plan lacks explicit authorization constraints.
+- `MISSING_TENANCY_SCOPE`: The plan lacks explicit tenancy logic.
+- `UNSPECIFIED_DELETION_SEMANTICS`: A deletion operation is planned without explicit confirmed scope.
+- `UNSPECIFIED_RETENTION_SEMANTICS`: Data is persisted without confirmed retention rules.
+- `MISSING_EVENT_IMPACT`: Event producers/consumers are implied but missing from the plan.
+- `MISSING_PERSISTENCE_IMPACT`: DB implications are implied but missing.
+- `MISSING_FRONTEND_IMPACT`: UI implications are implied but missing.
+- `MISSING_ACCEPTANCE_CRITERIA`: The requirement lacks ACs.
+- `UNRESOLVED_BLOCKER`: The plan proceeds despite an active blocker or open clarification.
+
+
+
+### Traceability Validation (Phase 3)
+The Reviewer MUST ensure the Plan is fully traced.
+Flag these if the plan violates traceability constraints:
+- `REQUIREMENT_NOT_TRACED`: The plan does not link the implementation back to the confirmed Requirement ID.
+- `IMPLEMENTATION_NOT_TRACED`: The plan introduces new code/APIs without a traceability link back to the requirement.
+- `UNSUPPORTED_IMPACT`: The plan claims to affect a downstream system but trace analysis does not show a relationship.
+- `MISSING_API_IMPACT`: The plan modifies an API without tracing its frontend or consumer impact.
+- `MISSING_EVENT_IMPACT`: The plan adds an event producer without tracing it to a consumer.
+- `MISSING_DATABASE_IMPACT`: The plan changes DB semantics without tracing repository flow.
+- `STALE_TRACEABILITY`: The plan relies on a traceability link that is stale or no longer matches the current repository graph.
+
+
+### Execution Loop Validation (Phase 4)
+Reviewers must validate the final state before closing a task.
+- `STALE_PLAN`: The implementation plan evidence became stale during coding.
+- `MISSING_TEST_EVIDENCE`: The code does not fulfill the `test_obligations` identified in the implementation plan.
+- `DESTRUCTIVE_VIOLATION`: Code performs a literal or semantic destruction without explicit `CONFIRMED` requirement approval.
+
+### Engineering Experience (Phase 4)
+After successful review, the Reviewer MUST evaluate if a durable engineering lesson was learned.
+- Call `record_engineering_experience` to save explicit decisions, anti-patterns, or architectural constraints discovered during the task.
+- NEVER record specific file locations or variable names as durable experience; only record architectural or semantic lessons.
+
+
+### Actual Execution Validation (Phase 5)
+Reviewers must validate the ACTUAL execution state, not just the plan.
+- Check that `validate_implementation_plan` produced a `PASS`.
+- `MISSING_TEST_EXECUTION`: Required tests were identified but not executed.
+- `FAILED_EXECUTION_EVIDENCE`: Test results show `FAIL` for a requirement constraint.
+- Reviewer is blocked from closing tasks if execution evidence prevents a `PASS`.
+
+
+### Phase 6 Experience Verification
+When reviewing an implementation plan or code changes, verify:
+- Experience used by the plan has provenance.
+- Experience is NOT treated as current fact or requirement.
+- Stale or conflicting experience is properly identified.
+- Current repository evidence was checked.
+- User decisions remain authoritative.
+- No unsupported generalized rule was introduced.
+
+Flag the following if found:
+- `UNPROVEN_EXPERIENCE`
+- `STALE_EXPERIENCE`
+- `CONFLICTING_EXPERIENCE`
+- `EXPERIENCE_USED_AS_FACT`
+- `EXPERIENCE_USED_AS_REQUIREMENT`
+- `UNSUPPORTED_GENERALIZATION`
+- `MISSING_PROVENANCE`
+- `OUTDATED_REPOSITORY_CONTEXT`
+
+
+### Phase 7 Regression & Drift Verification
+When reviewing an implementation plan or code changes, verify:
+- Current repository snapshot was considered.
+- Architecture drift and requirement drift were evaluated.
+- Traceability drift and regression tests were considered.
+- Cross-service impacts and security-sensitive changes were evaluated.
+- Risk indicators have evidence and are NOT presented as confirmed defects.
+- No historical lesson became an implicit requirement.
+
+Flag the following if found:
+- `HISTORICAL_RISK_NOT_REVIEWED`
+- `REGRESSION_TEST_GAP`
+- `TRACEABILITY_DRIFT`
+- `ARCHITECTURE_DRIFT`
+- `REQUIREMENT_DRIFT`
+- `UNSUPPORTED_RISK_CLAIM`
+- `CROSS_SERVICE_IMPACT_NOT_VALIDATED`
+- `SECURITY_REGRESSION_GAP`
+- `DESTRUCTIVE_OPERATION_GAP`
+
+
+### Phase 8 UI Design & UX Interaction Verification
+When reviewing frontend implementation plans or code changes, verify:
+- UI changes map back to a confirmed design and requirement.
+- Static HTML generated during planning is NOT copied verbatim into production.
+- Production UI changes were explicitly outlined in the plan.
+- UI patterns used are supported by evidence (discovered from the repository).
+
+Flag the following if found:
+- `DESIGN_WITHOUT_REQUIREMENT`
+- `DESIGN_WITHOUT_EVIDENCE`
+- `DESIGN_USED_AS_FACT`
+- `UNCONFIRMED_DESIGN`
+- `STALE_DESIGN`
+- `UI_PATTERN_WITHOUT_SOURCE`
+- `PRODUCTION_UI_CHANGED_WITHOUT_PLAN`
+- `CONFIRMED_DESIGN_WITHOUT_TRACEABILITY`
+- `IMPLEMENTATION_DEVIATES_FROM_CONFIRMED_DESIGN`
+
+
+### Phase 9 Workspace & Evidence Verification
+When reviewing an implementation plan or code changes, verify:
+- The implementation does not assume facts based on missing repositories.
+- `get_evidence_completeness` was considered if cross-service impacts are suspected.
+
+Flag the following if found:
+- `EVIDENCE_TREATED_AS_FACT_WHEN_MISSING`
+- `WORKSPACE_PARTIAL_RESTRICTION_IGNORED`

package/mcp/dist/benchmark_fixture.js

@@ -0,0 +1,46 @@
+import fs from 'fs';
+import path from 'path';
+import { buildGraph } from './graph_builder.js';
+import { fileURLToPath } from 'url';
+export function createFixture(ecosystemRoot) {
+    const spec = {
+        microservices: {
+            "sfn-iam-api": { calls_services: ["sfn-events-api"], owns_tables: ["users", "tenant_mapping", "user_groups"], kafka_consumes: [] },
+            "sfn-events-api": { calls_services: [], owns_tables: ["events", "audit_records"], kafka_consumes: ["user-deleted"] }
+        }
+    };
+    const dna = {
+        domains: [
+            { name: "UserEntity", type: "Entity", repository: "sfn-iam-api", filePath: "src/main/UserEntity.java", violations: [] },
+            { name: "TenantEntity", type: "Entity", repository: "sfn-iam-api", filePath: "src/main/TenantEntity.java", violations: [] },
+            { name: "EventEntity", type: "Entity", repository: "sfn-events-api", filePath: "src/main/EventEntity.java", violations: [] },
+            { name: "RetentionPolicy", type: "Entity", repository: "sfn-events-api", filePath: "src/main/RetentionPolicy.java", violations: [] }
+        ],
+        events: [
+            { className: "UserDeletedListener", repository: "sfn-events-api", filePath: "src/main/UserDeletedListener.java", topicsConsumed: ["user-deleted"], topicsProduced: [] },
+            { className: "RetentionCleanupJob", repository: "sfn-events-api", filePath: "src/main/RetentionCleanupJob.java", topicsConsumed: [], topicsProduced: [] }
+        ],
+        apis: [
+            { method: "DELETE", path: "/api/users/{id}", repository: "sfn-iam-api", controllerName: "UserController", filePath: "src/main/UserController.java" },
+            { method: "PUT", path: "/api/tenants/{id}/retention", repository: "sfn-events-api", controllerName: "RetentionController", filePath: "src/main/RetentionController.java" }
+        ],
+        databases: [
+            { table: "users", repository: "sfn-iam-api", filePath: "src/main/resources/db/migration/V1__users.sql" },
+            { table: "events", repository: "sfn-events-api", filePath: "src/main/resources/db/migration/V1__events.sql" }
+        ]
+    };
+    // Write spec
+    fs.writeFileSync(path.join(ecosystemRoot, ".secufusion-project-spec.json"), JSON.stringify(spec, null, 2));
+    // Generate graph
+    const graph = buildGraph(dna, spec);
+    dna.graph = graph;
+    const secDir = path.join(ecosystemRoot, ".secufusion");
+    if (!fs.existsSync(secDir))
+        fs.mkdirSync(secDir, { recursive: true });
+    fs.writeFileSync(path.join(secDir, "dna.json"), JSON.stringify(dna, null, 2));
+    console.log("Mock fixture generated successfully.");
+}
+const isMain = process.argv[1] && fileURLToPath(import.meta.url) === process.argv[1];
+if (isMain) {
+    createFixture("c:\\Users\\Yash\\Desktop\\mcp");
+}