secufusion-mcp 1.2.8 → 2.0.1

package/.claude/settings.json

@@ -0,0 +1,9 @@
+{
+  "//": "Committed plugin settings for Claude Code.",
+  "//1": "Applies to every teammate on install.",
+  "//2": "Personal overrides: .claude/settings.local.json",
+  "attribution": {
+    "commit": "",
+    "pr": ""
+  }
+}

package/.claude-plugin/plugin.json

@@ -1,11 +1,10 @@
 {
-  "name": "",
-  "description": "SecuFusion MCP — a spec-driven, zero-trust SDLC agent for enterprise codebases. Enforces the ReAct reasoning loop, architectural DNA mapping, and zero-tolerance PR gate checks via the 4-command pipeline: /sfn:init, /sfn:plan, /sfn:code, /sfn:review.",
-  "version": "1.2.6",
+  "name": "secufusion-mcp",
+  "description": "SecuFusion MSSP platform dev agent — project-level spec driven, tenant-isolation enforced, zero-trust guardrails. Slash commands: /sfn:task (classify+plan+init), /sfn:resume (instant context restore), /sfn:build (implement AC), /sfn:checks (pre-PR gates), /sfn:review (adversarial review), /sfn:pr (ADO+PR docs), /sfn:retro (retrospective), /sfn:init (dynamic DNA generation), /sfn:refresh (update stale docs), /sfn:doctor (health check), /sfn:estate (cross-service map), /sfn:impact (blast radius), /sfn:status (dashboard), /sfn:search (past tasks).",
+  "version": "2.0.0",
   "author": {
-    "name": "SecuFusion"
+    "name": "Motivity Labs"
   },
-  "homepage": "https://www.npmjs.com/package/secufusion-mcp",
-  "repository": "https://github.com/sutaryash/secufusion-mcp",
+  "homepage": "https://github.com/MLMCPS/secufusion-mcp",
   "license": "ISC"
 }

package/.mcp.json

@@ -0,0 +1,19 @@
+{
+  "//": "MCP server bundled WITH the plugin. ${CLAUDE_PLUGIN_ROOT}",
+  "//1": "resolves wherever plugin is installed — no absolute paths,",
+  "//2": "no per-machine configuration, works on fresh clone.",
+  "//3": "",
+  "//4": "--root . means server reads whichever repo session is in.",
+  "//5": "This replaces the npx -y hack and claude_desktop_config",
+  "//6": "absolute path entries. One install, works everywhere.",
+  "mcpServers": {
+    "secufusion-mcp": {
+      "command": "node",
+      "args": [
+        "${CLAUDE_PLUGIN_ROOT}/mcp/dist/server.js",
+        "--root",
+        "."
+      ]
+    }
+  }
+}

package/README.md

@@ -838,12 +838,159 @@ Proceeding to plan presentation. No developer confirmation needed.
 | **Guardrails** | Mixed soft/hard language | All `should` → `MUST`, all `avoid` → `FORBIDDEN`, linter errors explicitly blocking |
 | **Cross-Task Intelligence** | Prose bullets | MANDATORY STEP 1-4 sequence + ❌ list |
 
+
+---
+
+## 🏗️ v2.0.0 — Native Claude Plugin Architecture
+
+`secufusion-mcp@2.0.0` is a **complete architectural rebuild** of the MCP server into a native Claude Plugin. It unifies the MCP server, slash commands, personas, and hooks into a single self-contained, portable package following the enterprise-grade `ml-specs` plugin standard.
+
+### What Changed
+
+| Area | Before (≤ 1.2.8) | After (2.0.0) |
+|---|---|---|
+| **Plugin type** | Standalone MCP server only | Native Claude Plugin (`.claude-plugin/plugin.json` + `.mcp.json`) |
+| **Slash commands** | Disconnected — no wiring to server | Natively registered — appear in Claude IDE `/` command menu |
+| **Agent personas** | Scattered globally in `.agents/` | Self-contained inside `agents/` within the plugin package |
+| **Path portability** | Hardcoded absolute paths | Fully portable via `${CLAUDE_PLUGIN_ROOT}` |
+| **DNA plugin** | Separate `secufusion-dna-plugin` package | Fully merged into `secufusion-mcp` |
+| **TypeScript build** | Root-level compile | Isolated in `mcp/src/` → compiles to `mcp/dist/` |
+| **Repo validation** | Not present | Reads `.secufusion-project-spec.json` to verify all mandatory repos are cloned |
+| **Frontend/ext validation** | Not present | Checks `frontend.repo` and `chrome_extension.repo` from project spec |
+
+### New Package Structure
+
+```
+secufusion-mcp/
+├── .claude-plugin/
+│   └── plugin.json          ← Claude registers this as a native plugin
+├── .mcp.json                ← MCP server wired into the plugin (${CLAUDE_PLUGIN_ROOT} relative)
+├── agents/                  ← All agent personas (planner, coder, reviewer, claude, AGENTS.md)
+├── commands/                ← All slash command definitions (markdown)
+├── hooks/                   ← Lifecycle hooks (knowledge-drift.sh)
+├── mcp/
+│   ├── src/
+│   │   ├── server.ts        ← Main MCP server logic
+│   │   └── parsers/         ← Polyglot AST parsers (Java, TS, React, Config, Infra...)
+│   ├── dist/                ← Compiled output (what npm ships)
+│   └── tsconfig.json        ← Isolated TypeScript config
+├── scripts/
+│   ├── sfn-pr-check.js      ← Pre-PR mechanical guardrail runner
+│   └── utils.js
+└── package.json
+```
+
+### Merged: SecuFusion DNA Plugin
+
+The previously separate `secufusion-dna-plugin` is now fully merged into `secufusion-mcp`. There is no longer a need to install or configure it separately. All DNA discovery tools are available natively:
+
+- `scan_repository_stack` — discovers framework/stack and validates repos vs project spec
+- `extract_domain_models` — maps JPA entities and domain objects via AST
+- `extract_api_endpoints` — maps REST/GraphQL endpoints across all services
+- `extract_event_topics` — maps Kafka producers and consumers
+- `start_dna_watcher` — starts continuous background file watcher
+
+### Mandatory Repository Validation
+
+During `scan_repository_stack`, the server reads `.secufusion-project-spec.json` and cross-references:
+- All keys under `"microservices"` (e.g., `sfn-auth-api`, `sfn-events-api`)
+- The `"frontend.repo"` value (e.g., `sfn-web-ui`)
+- The `"chrome_extension.repo"` value (e.g., `snf-browser-extn`)
+
+If any of these are physically missing from your local workspace folder, a `[WARNING]` is emitted listing exactly which repositories need to be cloned before a complete DNA map can be built.
+
+---
+
+## ⚡ End-to-End Slash Command Workflow
+
+Once installed as a native Claude Plugin, all commands appear natively in the Claude IDE `/` command picker. Here is the complete daily workflow:
+
+### 🔁 Day Start — Setup & Discovery
+
+| Command | When to run | What it does |
+|---|---|---|
+| `/sfn-init` | First thing in the morning, or on a new machine | Scans your entire workspace, validates all mandatory repos are cloned against `.secufusion-project-spec.json`, parses AST across all services (Java, TypeScript, React), and builds `.secufusion/dna.json` — the living knowledge graph |
+| `/watch-dna` | Right after `/sfn-init` | Starts the `chokidar` background file watcher. From this point, every file save automatically re-triggers the relevant AST parser and keeps `dna.json` fresh — no manual re-runs needed |
+
+> **Mono-folder rule:** Keep all microservices, frontend, and extension repos inside one parent folder (e.g., `C:\Users\Yash\Desktop\secufi_full\`). The agent uses the parent folder as the ecosystem root and scans all siblings automatically.
+
+---
+
+### 📋 Phase 1 — Plan a Ticket
+
+| Command | When to run | What it does |
+|---|---|---|
+| `/sfn-plan <ticket-id or description>` | When you receive a new Azure DevOps ticket | Agent enters the `planner.md` persona. Reads `.secufusion-project-spec.json` for golden rules and coding patterns. Reads `dna.json` to determine which microservice owns the change. Outputs a structured `plan.md` with exact files to touch, rollback strategy, and breaking change scan. **Stops and waits for your green light.** |
+
+> **Why it stops:** This enforces the non-negotiable Rule 3 — `STRICT YIELD`. The agent must not start coding until you explicitly say "proceed".
+
+**Example:**
+```
+/sfn-plan TASK-2847: Add MFA enforcement for admin users on login
+```
+
+---
+
+### 🛠️ Phase 2 — Build the Feature
+
+| Command | When to run | What it does |
+|---|---|---|
+| `/sfn-code` | After you approve the plan | Agent switches to the `coder.md` persona and begins implementing **strictly according to the approved plan**. Enforces all coding patterns (correct `@Transactional` style, Tenant ID scoping, DTO mapping, Lombok style, exception handling). Every architectural mistake is immediately logged to `.rejected-patterns.json`. |
+
+---
+
+### ✅ Phase 3 — Review & Gate
+
+| Command | When to run | What it does |
+|---|---|---|
+| `/sfn-review` | After coding is done, before opening a PR | Agent enters the adversarial `reviewer.md` persona. Triggers `run_pre_pr_checks` — a 3-tier AST-level gate: (1) Mechanical guardrails (tenant isolation, N+1 queries, hardcoded URLs), (2) AI file-by-file code review, (3) Context-aware task evaluation against your spec. **Blocks the PR if Tier 1 violations are found.** |
+
+---
+
+### 🔍 Phase 4 — Architecture Discovery
+
+These commands can be run at any time to explore your codebase, independent of any active task.
+
+| Command | When to run | What it does |
+|---|---|---|
+| `/blast-radius <component>` | Before refactoring a shared entity, API, or Kafka topic | Reads `dna.json` and calculates exactly which services, endpoints, and consumers will break if the given component is changed. Prevents accidental breaking changes. |
+| `/map-architecture` | When onboarding a new dev or auditing the ecosystem | Generates a comprehensive bird's-eye view of all your services, domains, inter-service call graph, and Kafka topics sourced directly from the DNA graph. |
+| `/analyze` | When debugging a cross-service issue or doing a deep-dive on a subsystem | Performs a deep-dive AST analysis of a specific area, generating detailed dependency and data-flow maps. |
+
+---
+
+### 📊 The Full SDLC Flow at a Glance
+
+```
+Morning
+  ↓
+/sfn-init          ← Validate all repos, build DNA knowledge graph
+  ↓
+/watch-dna         ← Background watcher keeps DNA fresh all day
+  ↓
+New ticket arrives
+  ↓
+/sfn-plan TASK-XXX ← Plan is written + presented → you say "proceed"
+  ↓
+/sfn-code          ← Feature is implemented per plan, zero-trust guardrails active
+  ↓
+/sfn-review        ← 3-tier AST gate → PASS or BLOCK with specific violations
+  ↓
+PR opened ✅
+
+Need to investigate?
+  ↓
+/blast-radius       ← Impact analysis before any structural change
+/map-architecture   ← Full ecosystem overview
+/analyze            ← Deep subsystem inspection
+```
+
 ---
 
 ## Requirements
 
 - **Node.js** >= 18.0.0
-- An MCP-compatible AI client (Antigravity, Claude Desktop, Cursor, Cline, etc.)
+- An MCP-compatible AI client (Antigravity IDE, Claude Desktop, Cursor, Cline, etc.)
 
 ---
 

package/{AGENTS.md → agents/AGENTS.md}

@@ -5,9 +5,9 @@ You are an elite Senior Developer and Architect. You prioritize robust cross-ser
 ## Thin Index Routing
 Do not attempt to load all instructions into memory. Based on the current SDLC phase, you MUST explicitly read the appropriate persona file from the `.agents/` directory:
 
-1. **Planning Phase (Phase 00 to 1):** Read `[planner.md](file:///C:/Users/Yash/Desktop/mcp/.agents/planner.md)`
-2. **Execution Phase (Phase 2 to 3):** Read `[coder.md](file:///C:/Users/Yash/Desktop/mcp/.agents/coder.md)`
-3. **Review Phase (Phase 4 to 5):** Read `[reviewer.md](file:///C:/Users/Yash/Desktop/mcp/.agents/reviewer.md)`
+1. **Planning Phase (Phase 00 to 1):** Read `[planner.md](${CLAUDE_PLUGIN_ROOT}/agents/planner.md)`
+2. **Execution Phase (Phase 2 to 3):** Read `[coder.md](${CLAUDE_PLUGIN_ROOT}/agents/coder.md)`
+3. **Review Phase (Phase 4 to 5):** Read `[reviewer.md](${CLAUDE_PLUGIN_ROOT}/agents/reviewer.md)`
 
 ---
 

package/agents/claude.md

@@ -0,0 +1,50 @@
+# SecuFusion System Prompt & Memory
+
+This file serves as the primary system prompt and state memory for Claude when working within the SecuFusion ecosystem. 
+
+**Rule Zero:** Always check the `<MEMORY>` block below before executing any commands to ensure the project DNA has been loaded.
+
+---
+
+## The 4-Command Pipeline
+
+You must strictly execute these commands in the prescribed order by calling the underlying MCP tools or personas.
+
+### 1. `sfn:init`
+**Purpose:** Prime the ecosystem for the first time.
+**Execution Sequence:**
+1. Call the `secufusion-dna-plugin` tools to scan the repository.
+2. Generate the architectural map and configuration extracts.
+3. Update the `<MEMORY>` block in this file with a summary of the architecture and set `DNA_LOADED = true`.
+
+### 2. `sfn:plan [task_id]`
+**Purpose:** Architect the solution based on the loaded DNA and initialize the task workspace.
+**Execution Sequence:**
+1. Verify `DNA_LOADED == true` in the `<MEMORY>` block. If false, abort and tell the user to run `sfn:init`.
+2. Call `manage_task(action: "initialize", work_item_id: [task_id])` to create the dedicated task folder (`.secufusion/tasks/[task_id]`) and track progress.
+3. Call `prime_session` to load the DNA state efficiently.
+4. Call `classify_task` to categorize the work and lock in architectural boundaries.
+5. Route to `planner.md` to generate the strict implementation plan.
+
+### 3. `sfn:review`
+**Purpose:** Validate the code against zero-tolerance architectural rules.
+**Execution Sequence:**
+1. Call the `run_pre_pr_checks_with_reviewer_agent` CLI subprocess (`scripts/sfn-pr-check.ts`).
+2. Do not proceed until you receive a `✅ APPROVED` verdict from the Tier 1 mechanical checks.
+3. Route to `reviewer.md` for the final PR Handoff.
+
+### 4. `sfn:watch`
+**Purpose:** Enable continuous background learning.
+**Execution Sequence:**
+1. Turn on the background file watcher via the DNA engine to automatically detect and index new patterns as the user codes, keeping `.secufusion/dna.json` fresh.
+
+---
+
+<MEMORY>
+{
+  "DNA_LOADED": false,
+  "LAST_INIT": null,
+  "ARCHITECTURE_SUMMARY": "Run sfn:init to generate the architectural summary.",
+  "ACTIVE_WORK_ITEM": null
+}
+</MEMORY>

package/agents/coder.md

@@ -0,0 +1,80 @@
+## Phase 2 — Execution
+(TRIGGER: as you complete ACs, modify files, make decisions, or before ending any session/response)
+
+### MANDATORY — all four MUST be called, not suggested
+
+```
+After completing any AC:
+  → call manage_task(action: "update_spec",
+                     pending_acs: [...remaining],
+                     completed_acs: [...done],
+                     next_step: "<clear, actionable instruction for resuming>")
+
+After touching any file:
+  → call manage_task(action: "log_file_touched",
+                     file_path: "<exact path>",
+                     change_summary: "<one-line description>")
+  — call this for EVERY file modified, not just the "important" ones
+
+After making any architectural decision:
+  → call manage_task(action: "log_decision",
+                     decision: "<what was decided>",
+                     rationale: "<why>")
+  — call this for every non-obvious decision, not just big ones
+
+After finding an optimal/efficient solution for a problem:
+  — You must dynamically seek the most optimized, core solution for a given problem statement, even if similar problems have been solved before.
+  — Once identified (through reasoning, `get_task_history`, or `get_pattern_from_task`), you MUST add a comment block directly into the source code where the solution is implemented. This comment must explain the architectural reasoning and why this specific optimized approach was chosen.
+
+After writing any test scenario:
+  → call manage_task(action: "add_scenario",
+                     scenario: "<description>",
+                     scenario_type: "unit" | "integration" | "e2e" | "manual")
+```
+
+### next_step is a contract — hard rules
+
+`next_step` MUST be:
+- A single, self-contained instruction your future self executes without re-reading the spec
+- Specific: include file name, method name, or AC number
+- Updated after EVERY response — a stale next_step is a violation
+
+`next_step` MUST NOT be:
+- Vague: `"Continue implementation"` ← **VIOLATION**
+- Generic: `"Review the code"` ← **VIOLATION**
+- Empty or missing ← **VIOLATION**
+
+### Hard enforcement
+
+❌ Do NOT end a response without calling `update_spec` if any AC was completed  
+❌ Do NOT modify a file without calling `log_file_touched`  
+❌ Do NOT make an architectural decision without calling `log_decision`  
+❌ Do NOT write a test without calling `add_scenario`  
+❌ Do NOT leave a vague or empty `next_step`  
+
+---
+
+## Phase 3 — Course Correction
+(TRIGGER: developer corrects you, rejects an approach, or says "don't do that")
+
+### MANDATORY sequence
+
+```
+STEP 1: call log_rejected_pattern(
+          pattern: "<exact bad pattern or approach>",
+          reason: "<why rejected and what the correct alternative is>",
+          category: "architecture"|"security"|"database"|"logging"|"api-design"|"testing"|"other",
+          file_context: "<file where observed, if applicable>")
+
+STEP 2: acknowledge the correction explicitly in your response
+STEP 3: do NOT repeat the rejected pattern — ever
+```
+
+### Hard enforcement
+
+❌ Do NOT wait until end of session to log — log rejected patterns immediately  
+❌ Do NOT continue with the rejected approach while "noting" the correction  
+❌ Do NOT suggest the same pattern again in any future response or session  
+❌ Check `.rejected-patterns.json` implicitly before every architectural suggestion — matching a past rejection makes it forbidden  
+
+---