secufusion-mcp 2.1.1 → 2.1.2
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/README.md +43 -5
- package/agents/AGENTS.md +6 -5
- package/package.json +1 -1
package/README.md
CHANGED
|
@@ -15,16 +15,18 @@
|
|
|
15
15
|
| Tool | Phase | What it does |
|
|
16
16
|
|---|---|---|
|
|
17
17
|
| `manage_project_spec` | **Phase 00** — Session Start | Loads `.secufusion-project-spec.json` — full project DNA (ports, repos, domains, coding patterns, golden rules) |
|
|
18
|
-
| `manage_task` | **Phase 0.7 / 1 / 2 / 4** — Task Lifecycle | Creates dynamically named `.secufusion/tasks/{id}-{slug}/` folder
|
|
18
|
+
| `manage_task` | **Phase 0.7 / 1 / 2 / 4** — Task Lifecycle | Creates dynamically named `.secufusion/tasks/{id}-{slug}/` folder (the HOW layer: spec, progress, decisions, files-touched). |
|
|
19
|
+
| `spec_create_intent` | **Phase 1** — Planning | **NEW in v2.1** — Creates the Markdown intent file (the WHY layer: business goal, PM, ACs, polyglot service map). |
|
|
20
|
+
| `spec_read_intent` | **Phase 0 / 1** — Session Start | **NEW in v2.1** — Reads the Markdown intent file and ticks AC checkboxes. |
|
|
21
|
+
| `spec_next_number` | **Phase 1** — Planning | **NEW in v2.1** — Generates the next sequential ID for intent files. |
|
|
19
22
|
| `get_task_history` | **Phase 0 / 1** — Cross-Task Intelligence | Retrieves the full history of a past task before starting similar work |
|
|
20
23
|
| `search_tasks` | **Phase 0 / 1** — Cross-Task Intelligence | Keyword search across all past task files — prevents re-solving solved problems |
|
|
21
24
|
| `get_pattern_from_task` | **Phase 1** — Cross-Task Intelligence | Extracts reusable decisions, file patterns, and test scenarios from a completed task |
|
|
22
25
|
| `manage_branch_state` | Legacy — Branch State | Backward-compatible branch-scoped JSON state tracker (for tasks before `manage_task`) |
|
|
23
26
|
| `log_rejected_pattern` | **Phase 3** — Course Correction | Records bad patterns to `.rejected-patterns.json` so they are never repeated |
|
|
24
|
-
| `(Removed)` | **Phase 4** — PR Handoff | *Replaced by native MD generation protocol in v1.0.58* |
|
|
25
27
|
| `run_pre_pr_checks_with_reviewer_agent` | **Phase 4** — PR Handoff | **NEW** — Unified 3-tier PR gate. Runs mechanical checks, AI file reviews, and context-aware task evaluation in a single pass. |
|
|
26
28
|
| `get_secufusion_rules` | **Setup** | Returns the `AGENTS.md` rules for AI clients that don't natively support MCP Resources |
|
|
27
|
-
| `classify_task` | **Phase 0.5** — Task Classification | **NEW** — Deep multi-pass analysis engine. Classifies any task as `BACKEND_ONLY`, `FRONTEND_ONLY`,
|
|
29
|
+
| `classify_task` | **Phase 0.5** — Task Classification | **NEW** — Deep multi-pass analysis engine. Classifies any task as `BACKEND_ONLY`, `FRONTEND_ONLY`, etc. based on root cause. |
|
|
28
30
|
| `prime_session` | **Phase 0** — Session Start | **NEW** — Hyper-efficient session startup. Combines Phase 00 (spec) and Phase 0 (task) into one call using Thin Indexes to optimize context tokens. |
|
|
29
31
|
| `skill_recommend` | **Phase 1** — Planning | **NEW** — Dynamically recommends and retrieves domain-specific coding skills from `skills-catalog.json`. |
|
|
30
32
|
|
|
@@ -53,9 +55,45 @@ A new standalone Claude plugin has been introduced: **SecuFusion DNA Discovery M
|
|
|
53
55
|
|
|
54
56
|
---
|
|
55
57
|
|
|
56
|
-
## ⚡ The Shift:
|
|
58
|
+
## ⚡ The Shift: "WHY before HOW" Spec-Driven Workflow (v2.1)
|
|
59
|
+
|
|
60
|
+
This is the biggest architectural upgrade to the SecuFusion MCP, fundamentally changing how the AI approaches a new task.
|
|
61
|
+
|
|
62
|
+
### The Problem
|
|
63
|
+
Previously, the AI acted as a blind code-generator. When given a task (e.g. "Add MFA"), it would immediately jump into writing code or initializing tracking infrastructure (`.secufusion/tasks/`), without understanding **why** the feature was being built, who requested it, or the business risk. Furthermore, its AST parsers were limited to Java/TypeScript, leaving Go, Python, or Rust services completely invisible.
|
|
64
|
+
|
|
65
|
+
### The v2.1 Solution: The Two-Layer Architecture
|
|
66
|
+
Every task now requires **two complementary files** that the AI reads together:
|
|
67
|
+
|
|
68
|
+
```
|
|
69
|
+
.secufusion/
|
|
70
|
+
├── tasks/WI-2847/ ← HOW layer (code truth, AST-driven, JSON)
|
|
71
|
+
│ ├── progress.json ← pending/completed ACs
|
|
72
|
+
│ └── decisions.json ← architectural decisions log
|
|
73
|
+
│
|
|
74
|
+
└── intents/ ← WHY layer (business truth, human-driven, Markdown)
|
|
75
|
+
└── 0001-WI-2847-add-mfa-enforcement.md
|
|
76
|
+
├── Business Goal ← why is this being built?
|
|
77
|
+
├── PM Owner ← who owns it?
|
|
78
|
+
├── Acceptance Criteria ← tickable checkboxes
|
|
79
|
+
├── Service Map ← polyglot bridge (Go, Python, Rust...)
|
|
80
|
+
└── Risk Assessment ← what breaks if we don't ship?
|
|
81
|
+
```
|
|
82
|
+
|
|
83
|
+
### The Polyglot Bridge
|
|
84
|
+
The new `spec_create_intent` tool captures a `services_involved` array that is **language-agnostic**. You can list a Go microservice, a Python Lambda, or a COBOL batch job. The AI reads this declaration and knows those services are in scope without needing a custom AST parser.
|
|
85
|
+
|
|
86
|
+
### The New `/sfn:plan` Flow
|
|
87
|
+
When you type `/sfn:plan WI-2847 Add MFA`:
|
|
88
|
+
1. **The Pushback (Phase 1):** The AI will **NOT** immediately start planning. It will stop and ask you: *"Why are we building this? What business problem does it solve? What is the risk if we don't?"*
|
|
89
|
+
2. **The WHY (Phase 1.5):** You answer, and the AI generates the Markdown intent file (`spec_create_intent`).
|
|
90
|
+
3. **The HOW (Phase 2):** Only then does it initialize the code tracking infrastructure (`manage_task`).
|
|
91
|
+
4. **Context & Classify (Phase 3/4):** The AI loads the AST (`prime_session`), flags architectural risks (`classify_task`), and yields for your approval.
|
|
92
|
+
5. **The Plan (Phase 5):** The AI outputs the strict implementation plan.
|
|
57
93
|
|
|
58
|
-
|
|
94
|
+
---
|
|
95
|
+
|
|
96
|
+
## ⚡ The Shift: Problem-Statement Driven → Project-Level Spec Driven
|
|
59
97
|
|
|
60
98
|
### Before (problem-statement driven)
|
|
61
99
|
The AI started every session **cold**. It had zero knowledge of the codebase and relied entirely on the developer feeding context through a work item description. Every session began with implicit questions:
|
package/agents/AGENTS.md
CHANGED
|
@@ -19,10 +19,11 @@ Do not attempt to load all instructions into memory. Based on the current SDLC p
|
|
|
19
19
|
**DYNAMIC ENFORCEMENT**: You must dynamically adhere to these rules at all times. Whether you are starting a fresh task, resuming an interrupted session, or answering a mid-task prompt, you must strictly respect this sequence and never skip ahead.
|
|
20
20
|
|
|
21
21
|
1. **Rule 0 (Pre-requisite to all rules) — Load Project DNA First**: Before ANY other action, call `prime_session(work_item_id: <id>)`. This is Phase 00. Without the project DNA loaded, you are not allowed to reason, classify, plan, or code. Period.
|
|
22
|
-
2. **Rule 1 -
|
|
23
|
-
3. **Rule 2 -
|
|
24
|
-
4. **Rule 3 -
|
|
25
|
-
5. **Rule 4 -
|
|
26
|
-
6. **Rule 5 -
|
|
22
|
+
2. **Rule 1 - Clarify Business Intent (WHY before HOW)**: For any new task, you MUST pause and ask the user for the business intent, goal, and risk. YIELD until this is clarified, then call `spec_create_intent`. Do not initialize task tracking (`manage_task`) until the WHY is captured.
|
|
23
|
+
3. **Rule 2 - ReAct (Reason, Observe, Act) First**: After intent is clarified and DNA is loaded, you MUST deeply reason about the problem statement. Apply the ReAct framework: analyze the problem, observe context, and formulate a high-level solution hypothesis.
|
|
24
|
+
4. **Rule 3 - Classify Second**: Only after you have reasoned through the problem statement, you MUST call the `classify_task` tool. This will formally categorize the task and lock in architectural boundaries.
|
|
25
|
+
5. **Rule 4 - STRICT YIELD (Stop and Wait)**: Immediately after classifying the task, you MUST YIELD YOUR TURN. **DO NOT CHAIN TOOL CALLS.** Output the classification, ask the user for the "green signal," and STOP.
|
|
26
|
+
6. **Rule 5 - Plan Only After Approval**: Only after receiving the "green signal" for the classification are you allowed to propose a detailed implementation plan.
|
|
27
|
+
7. **Rule 6 - Code is the Last Resort (Universal)**: Modifying source code is the absolute final step and may only occur after the implementation plan is approved.
|
|
27
28
|
|
|
28
29
|
---
|