mdan-cli 2.2.0
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 +223 -0
- package/agents/AGENTS-REGISTRY.md +215 -0
- package/agents/architect.md +160 -0
- package/agents/dev.md +166 -0
- package/agents/devops.md +230 -0
- package/agents/doc.md +189 -0
- package/agents/learn.md +377 -0
- package/agents/product.md +124 -0
- package/agents/security.md +168 -0
- package/agents/test.md +151 -0
- package/agents/ux.md +207 -0
- package/cli/mdan.js +505 -0
- package/cli/mdan.py +259 -0
- package/cli/mdan.sh +724 -0
- package/cli/postinstall.js +4 -0
- package/core/orchestrator.md +238 -0
- package/core/universal-envelope.md +160 -0
- package/install.sh +228 -0
- package/integrations/all-integrations.md +300 -0
- package/integrations/claude.md +46 -0
- package/integrations/cursor.md +74 -0
- package/integrations/windsurf.md +48 -0
- package/memory/MDAN-STATE.template.json +44 -0
- package/memory/MEMORY-SYSTEM.md +197 -0
- package/package.json +48 -0
- package/phases/01-discover.md +136 -0
- package/phases/02-design.md +147 -0
- package/phases/03-build.md +113 -0
- package/phases/04-verify.md +101 -0
- package/phases/05-ship.md +156 -0
- package/skills/find-skills/skill.md +133 -0
- package/templates/ARCHITECTURE.md +186 -0
- package/templates/CHANGELOG.md +41 -0
- package/templates/MDAN-KNOWLEDGE.md +73 -0
- package/templates/PRD.md +120 -0
- package/templates/SECURITY-REVIEW.md +99 -0
- package/templates/TEST-PLAN.md +97 -0
package/package.json
ADDED
|
@@ -0,0 +1,48 @@
|
|
|
1
|
+
{
|
|
2
|
+
"name": "mdan-cli",
|
|
3
|
+
"version": "2.2.0",
|
|
4
|
+
"description": "Multi-Agent Development Agentic Network - A modern, adaptive, LLM-agnostic methodology for building software",
|
|
5
|
+
"main": "cli/mdan.js",
|
|
6
|
+
"bin": {
|
|
7
|
+
"mdan": "cli/mdan.js"
|
|
8
|
+
},
|
|
9
|
+
"scripts": {
|
|
10
|
+
"postinstall": "node cli/postinstall.js"
|
|
11
|
+
},
|
|
12
|
+
"keywords": [
|
|
13
|
+
"ai",
|
|
14
|
+
"agents",
|
|
15
|
+
"llm",
|
|
16
|
+
"development",
|
|
17
|
+
"methodology",
|
|
18
|
+
"cursor",
|
|
19
|
+
"claude",
|
|
20
|
+
"windsurf",
|
|
21
|
+
"copilot"
|
|
22
|
+
],
|
|
23
|
+
"author": "khalilbenaz",
|
|
24
|
+
"license": "MIT",
|
|
25
|
+
"repository": {
|
|
26
|
+
"type": "git",
|
|
27
|
+
"url": "https://github.com/khalilbenaz/MDAN.git"
|
|
28
|
+
},
|
|
29
|
+
"homepage": "https://github.com/khalilbenaz/MDAN#readme",
|
|
30
|
+
"engines": {
|
|
31
|
+
"node": ">=14.0.0"
|
|
32
|
+
},
|
|
33
|
+
"files": [
|
|
34
|
+
"cli/",
|
|
35
|
+
"core/",
|
|
36
|
+
"agents/",
|
|
37
|
+
"phases/",
|
|
38
|
+
"templates/",
|
|
39
|
+
"integrations/",
|
|
40
|
+
"memory/",
|
|
41
|
+
"skills/",
|
|
42
|
+
"install.sh"
|
|
43
|
+
],
|
|
44
|
+
"dependencies": {
|
|
45
|
+
"@clack/prompts": "^1.0.1",
|
|
46
|
+
"picocolors": "^1.1.1"
|
|
47
|
+
}
|
|
48
|
+
}
|
|
@@ -0,0 +1,136 @@
|
|
|
1
|
+
# MDAN Phase 1 — DISCOVER
|
|
2
|
+
|
|
3
|
+
> **Goal:** Deeply understand the user's need before touching any solution.
|
|
4
|
+
> **Agents:** Product Agent
|
|
5
|
+
> **Output:** Validated PRD
|
|
6
|
+
|
|
7
|
+
---
|
|
8
|
+
|
|
9
|
+
## Phase Overview
|
|
10
|
+
|
|
11
|
+
The DISCOVER phase is the foundation of every MDAN project. A rushed discovery means everything
|
|
12
|
+
built on top of it will be wrong. MDAN Core enforces a thorough discovery before ANY technical
|
|
13
|
+
work begins.
|
|
14
|
+
|
|
15
|
+
**Duration:** As long as it takes to answer every question with confidence.
|
|
16
|
+
**Shortcut:** Never. Discovery shortcuts are the #1 cause of failed software projects.
|
|
17
|
+
|
|
18
|
+
---
|
|
19
|
+
|
|
20
|
+
## MDAN Core Behavior in DISCOVER
|
|
21
|
+
|
|
22
|
+
When the user presents a project idea, MDAN Core ALWAYS:
|
|
23
|
+
|
|
24
|
+
1. **Acknowledges** the project idea warmly
|
|
25
|
+
2. **Announces** Phase 1: DISCOVER
|
|
26
|
+
3. **Asks the 5 Discovery Questions** (see below)
|
|
27
|
+
4. **Activates the Product Agent** with the user's answers
|
|
28
|
+
5. **Presents the PRD** to the user for validation
|
|
29
|
+
6. **Runs the Phase Gate check** before proceeding
|
|
30
|
+
|
|
31
|
+
---
|
|
32
|
+
|
|
33
|
+
## The 5 Essential Discovery Questions
|
|
34
|
+
|
|
35
|
+
MDAN Core asks these questions every time, without exception:
|
|
36
|
+
|
|
37
|
+
```
|
|
38
|
+
🔍 MDAN — Phase 1: DISCOVER
|
|
39
|
+
|
|
40
|
+
Before we build anything, I need to understand what we're actually solving.
|
|
41
|
+
Please answer these 5 questions as completely as you can:
|
|
42
|
+
|
|
43
|
+
1. WHAT is the core problem you're solving?
|
|
44
|
+
(Not the solution — the actual problem users face today)
|
|
45
|
+
|
|
46
|
+
2. WHO are your users?
|
|
47
|
+
(Be specific: roles, technical level, context of use)
|
|
48
|
+
|
|
49
|
+
3. HOW will you know if it's successful?
|
|
50
|
+
(Concrete metrics: "X users per month", "reduces time from Y to Z", etc.)
|
|
51
|
+
|
|
52
|
+
4. WHAT are your constraints?
|
|
53
|
+
(Timeline, budget, team size, existing tech, non-negotiables)
|
|
54
|
+
|
|
55
|
+
5. WHAT have you already tried?
|
|
56
|
+
(Existing solutions, past attempts, why they didn't work)
|
|
57
|
+
```
|
|
58
|
+
|
|
59
|
+
---
|
|
60
|
+
|
|
61
|
+
## Discovery Depth Guide
|
|
62
|
+
|
|
63
|
+
| Answer Quality | MDAN Core Response |
|
|
64
|
+
|---|---|
|
|
65
|
+
| Vague ("I want an app") | Ask follow-up until specific |
|
|
66
|
+
| Partial (3/5 questions) | Ask for missing answers |
|
|
67
|
+
| Contradictory | Point out the contradiction, resolve first |
|
|
68
|
+
| Complete and clear | Activate Product Agent |
|
|
69
|
+
|
|
70
|
+
---
|
|
71
|
+
|
|
72
|
+
## Product Agent Activation Script
|
|
73
|
+
|
|
74
|
+
Once discovery answers are complete, MDAN Core activates the Product Agent with this brief:
|
|
75
|
+
|
|
76
|
+
```
|
|
77
|
+
[ACTIVATING: Product Agent]
|
|
78
|
+
|
|
79
|
+
Task: Create a complete PRD based on the following discovery information.
|
|
80
|
+
|
|
81
|
+
Project: [Project Name]
|
|
82
|
+
Problem: [User's answer to Q1]
|
|
83
|
+
Users: [User's answer to Q2]
|
|
84
|
+
Success Metrics: [User's answer to Q3]
|
|
85
|
+
Constraints: [User's answer to Q4]
|
|
86
|
+
Prior Attempts: [User's answer to Q5]
|
|
87
|
+
|
|
88
|
+
Additional Context: [Any other relevant information from the conversation]
|
|
89
|
+
|
|
90
|
+
Expected Output: Complete PRD following the MDAN PRD template.
|
|
91
|
+
```
|
|
92
|
+
|
|
93
|
+
---
|
|
94
|
+
|
|
95
|
+
## Phase 1 Quality Gate
|
|
96
|
+
|
|
97
|
+
Before exiting DISCOVER and entering DESIGN, MDAN Core checks:
|
|
98
|
+
|
|
99
|
+
```
|
|
100
|
+
✅ DISCOVER → DESIGN Quality Gate
|
|
101
|
+
|
|
102
|
+
[ ] Problem is clearly and specifically defined
|
|
103
|
+
[ ] At least one user persona is fully defined
|
|
104
|
+
[ ] Success metrics are measurable (numbers, not "better" or "faster")
|
|
105
|
+
[ ] Project constraints are documented
|
|
106
|
+
[ ] PRD is complete with MoSCoW prioritization
|
|
107
|
+
[ ] MVP scope is defined and realistic
|
|
108
|
+
[ ] User stories have acceptance criteria
|
|
109
|
+
[ ] Risks are identified with mitigation plans
|
|
110
|
+
[ ] Out of scope items are explicitly listed
|
|
111
|
+
[ ] User has reviewed and validated the PRD
|
|
112
|
+
```
|
|
113
|
+
|
|
114
|
+
**If any box is unchecked:** MDAN Core does NOT proceed. It identifies the gap and works with the user to fill it.
|
|
115
|
+
|
|
116
|
+
**If all boxes are checked:** MDAN Core announces Phase 2: DESIGN.
|
|
117
|
+
|
|
118
|
+
---
|
|
119
|
+
|
|
120
|
+
## Common Discovery Anti-Patterns
|
|
121
|
+
|
|
122
|
+
| Anti-Pattern | Why It's Dangerous | MDAN Response |
|
|
123
|
+
|---|---|---|
|
|
124
|
+
| "Just build a Twitter clone" | No clear differentiation or problem | Ask: what specific problem does this solve for which users? |
|
|
125
|
+
| "I want all the features" | Scope creep from day one | Enforce MoSCoW, define MVP |
|
|
126
|
+
| "The tech is already decided" | Solution before problem | Document constraint, still validate need |
|
|
127
|
+
| "Trust me, users need this" | Assumptions not validated | Ask for user research or at least specific examples |
|
|
128
|
+
| "We'll figure out metrics later" | No way to know if it worked | Define metrics now or they'll never be defined |
|
|
129
|
+
|
|
130
|
+
---
|
|
131
|
+
|
|
132
|
+
## DISCOVER Phase Artifacts
|
|
133
|
+
|
|
134
|
+
| Artifact | Template | Owner | Status Needed |
|
|
135
|
+
|---|---|---|---|
|
|
136
|
+
| PRD | `templates/PRD.md` | Product Agent | Validated |
|
|
@@ -0,0 +1,147 @@
|
|
|
1
|
+
# MDAN Phase 2 — DESIGN
|
|
2
|
+
|
|
3
|
+
> **Goal:** Architect the complete solution before writing a single line of code.
|
|
4
|
+
> **Agents:** Architect Agent, UX Agent
|
|
5
|
+
> **Output:** Architecture Document + UX Specification
|
|
6
|
+
|
|
7
|
+
---
|
|
8
|
+
|
|
9
|
+
## Phase Overview
|
|
10
|
+
|
|
11
|
+
DESIGN is where the solution takes shape. By the end of this phase, every technical and
|
|
12
|
+
interface decision should be made. The BUILD phase should have zero architectural surprises.
|
|
13
|
+
|
|
14
|
+
**Duration:** Until every design question is answered.
|
|
15
|
+
**Rule:** If you're still making architecture decisions during BUILD, DESIGN failed.
|
|
16
|
+
|
|
17
|
+
---
|
|
18
|
+
|
|
19
|
+
## MDAN Core Behavior in DESIGN
|
|
20
|
+
|
|
21
|
+
1. **Announces** Phase 2: DESIGN
|
|
22
|
+
2. **Reviews** the validated PRD
|
|
23
|
+
3. **Activates Architect Agent** first — system design before interface design
|
|
24
|
+
4. **Reviews** the Architecture Document with the user
|
|
25
|
+
5. **Activates UX Agent** — interface design aligned to architecture
|
|
26
|
+
6. **Reviews** the UX Specification with the user
|
|
27
|
+
7. **Runs Phase Gate check** before proceeding
|
|
28
|
+
|
|
29
|
+
---
|
|
30
|
+
|
|
31
|
+
## Architect Agent Activation Script
|
|
32
|
+
|
|
33
|
+
```
|
|
34
|
+
[ACTIVATING: Architect Agent]
|
|
35
|
+
|
|
36
|
+
Task: Design the complete system architecture for this project.
|
|
37
|
+
|
|
38
|
+
PRD: [Paste validated PRD]
|
|
39
|
+
Technical constraints: [From discovery]
|
|
40
|
+
Team profile: [Size, skill level]
|
|
41
|
+
Deployment preferences: [Cloud provider, on-prem, etc.]
|
|
42
|
+
|
|
43
|
+
Expected outputs:
|
|
44
|
+
1. Architecture diagram (Mermaid)
|
|
45
|
+
2. Technology stack with justifications
|
|
46
|
+
3. Data models
|
|
47
|
+
4. API design
|
|
48
|
+
5. Security architecture
|
|
49
|
+
6. Non-functional requirements strategy
|
|
50
|
+
7. Project structure
|
|
51
|
+
8. Coding conventions
|
|
52
|
+
9. Architecture Decision Records
|
|
53
|
+
```
|
|
54
|
+
|
|
55
|
+
---
|
|
56
|
+
|
|
57
|
+
## UX Agent Activation Script
|
|
58
|
+
|
|
59
|
+
```
|
|
60
|
+
[ACTIVATING: UX Agent]
|
|
61
|
+
|
|
62
|
+
Task: Design the complete user interface specification for this project.
|
|
63
|
+
|
|
64
|
+
PRD: [Paste validated PRD — personas and user stories]
|
|
65
|
+
Architecture constraints: [Tech stack, limitations]
|
|
66
|
+
Existing brand/design system: [If any, else "None — create from scratch"]
|
|
67
|
+
|
|
68
|
+
Expected outputs:
|
|
69
|
+
1. Design system (colors, typography, spacing)
|
|
70
|
+
2. Navigation structure
|
|
71
|
+
3. User flows for all key user stories
|
|
72
|
+
4. Screen specifications with all states
|
|
73
|
+
5. Component specifications
|
|
74
|
+
6. Accessibility requirements
|
|
75
|
+
7. UI copy guidelines
|
|
76
|
+
```
|
|
77
|
+
|
|
78
|
+
---
|
|
79
|
+
|
|
80
|
+
## Design Review Process
|
|
81
|
+
|
|
82
|
+
After each agent delivers its output, MDAN Core:
|
|
83
|
+
|
|
84
|
+
1. **Checks completeness** against the quality gate
|
|
85
|
+
2. **Cross-checks consistency** — does the UX spec align with the architecture?
|
|
86
|
+
3. **Presents to user** with key decisions highlighted
|
|
87
|
+
4. **Asks for explicit validation** before continuing
|
|
88
|
+
|
|
89
|
+
```
|
|
90
|
+
📐 Design Review: [Document Name]
|
|
91
|
+
|
|
92
|
+
Key decisions made in this document:
|
|
93
|
+
1. [Decision]: [Choice made] — Rationale: [Why]
|
|
94
|
+
2. [Decision]: [Choice made] — Rationale: [Why]
|
|
95
|
+
3. [Decision]: [Choice made] — Rationale: [Why]
|
|
96
|
+
|
|
97
|
+
Please review and confirm:
|
|
98
|
+
[ ] I agree with the technology choices
|
|
99
|
+
[ ] I agree with the data model design
|
|
100
|
+
[ ] I agree with the API design
|
|
101
|
+
[ ] I have no unresolved concerns
|
|
102
|
+
|
|
103
|
+
Type "DESIGN APPROVED" to proceed to Phase 3: BUILD
|
|
104
|
+
Or describe your concerns and we'll revise.
|
|
105
|
+
```
|
|
106
|
+
|
|
107
|
+
---
|
|
108
|
+
|
|
109
|
+
## Phase 2 Quality Gate
|
|
110
|
+
|
|
111
|
+
```
|
|
112
|
+
✅ DESIGN → BUILD Quality Gate
|
|
113
|
+
|
|
114
|
+
Architecture:
|
|
115
|
+
[ ] System architecture diagram is complete
|
|
116
|
+
[ ] All PRD requirements are addressed in the architecture
|
|
117
|
+
[ ] Technology stack is fully specified with justifications
|
|
118
|
+
[ ] All data entities and relationships are defined
|
|
119
|
+
[ ] All API endpoints are specified
|
|
120
|
+
[ ] Security architecture is defined (auth, authz, encryption)
|
|
121
|
+
[ ] Non-functional requirements are addressed
|
|
122
|
+
[ ] Project structure is defined
|
|
123
|
+
[ ] Coding conventions are documented
|
|
124
|
+
[ ] At least one ADR is written
|
|
125
|
+
|
|
126
|
+
UX:
|
|
127
|
+
[ ] Design system is complete (colors, typography, spacing, breakpoints)
|
|
128
|
+
[ ] Navigation structure covers all app sections
|
|
129
|
+
[ ] User flows cover all user stories from PRD
|
|
130
|
+
[ ] Every screen has all states (default, loading, empty, error)
|
|
131
|
+
[ ] Accessibility requirements are defined
|
|
132
|
+
[ ] Mobile behavior is specified
|
|
133
|
+
|
|
134
|
+
Cross-check:
|
|
135
|
+
[ ] UX spec is consistent with architecture (no impossible requirements)
|
|
136
|
+
[ ] Performance requirements are reflected in both arch and UX
|
|
137
|
+
[ ] Both documents are validated by the user
|
|
138
|
+
```
|
|
139
|
+
|
|
140
|
+
---
|
|
141
|
+
|
|
142
|
+
## DESIGN Phase Artifacts
|
|
143
|
+
|
|
144
|
+
| Artifact | Template | Owner | Status Needed |
|
|
145
|
+
|---|---|---|---|
|
|
146
|
+
| Architecture Document | `templates/ARCHITECTURE.md` | Architect Agent | Validated |
|
|
147
|
+
| UX Specification | *(in-line document)* | UX Agent | Validated |
|
|
@@ -0,0 +1,113 @@
|
|
|
1
|
+
# MDAN Phase 3 — BUILD
|
|
2
|
+
|
|
3
|
+
> **Goal:** Implement the solution with precision, security, and quality.
|
|
4
|
+
> **Agents:** Dev Agent, Security Agent (concurrent)
|
|
5
|
+
> **Output:** Working, tested, reviewed code
|
|
6
|
+
|
|
7
|
+
---
|
|
8
|
+
|
|
9
|
+
## Phase Overview
|
|
10
|
+
|
|
11
|
+
BUILD is where the code is written. But in MDAN, BUILD is not "just coding" — it's a structured
|
|
12
|
+
process where every feature is implemented against a spec, reviewed, and security-checked before
|
|
13
|
+
moving on.
|
|
14
|
+
|
|
15
|
+
**Rule:** No feature is "done" until it has tests and passes a security check.
|
|
16
|
+
|
|
17
|
+
---
|
|
18
|
+
|
|
19
|
+
## BUILD Workflow (per feature)
|
|
20
|
+
|
|
21
|
+
```
|
|
22
|
+
For each feature in the PRD (MVP scope):
|
|
23
|
+
|
|
24
|
+
1. MDAN Core prepares a Feature Brief
|
|
25
|
+
2. Dev Agent implements the feature
|
|
26
|
+
3. Security Agent reviews the implementation
|
|
27
|
+
4. MDAN Core reviews the combined output
|
|
28
|
+
5. User validates (or flags issues)
|
|
29
|
+
6. Move to next feature
|
|
30
|
+
```
|
|
31
|
+
|
|
32
|
+
---
|
|
33
|
+
|
|
34
|
+
## Feature Brief Template
|
|
35
|
+
|
|
36
|
+
MDAN Core creates this before activating the Dev Agent:
|
|
37
|
+
|
|
38
|
+
```
|
|
39
|
+
[ACTIVATING: Dev Agent]
|
|
40
|
+
|
|
41
|
+
Feature: [US-XXX: User story title]
|
|
42
|
+
Acceptance Criteria:
|
|
43
|
+
- Given [context], When [action], Then [outcome]
|
|
44
|
+
- [Additional criteria]
|
|
45
|
+
|
|
46
|
+
Architecture context:
|
|
47
|
+
- Tech stack: [Stack]
|
|
48
|
+
- Relevant data models: [Models]
|
|
49
|
+
- Relevant API endpoints: [Endpoints]
|
|
50
|
+
- Coding conventions: [Link/summary]
|
|
51
|
+
|
|
52
|
+
UX context:
|
|
53
|
+
- Relevant screens: [Screen names]
|
|
54
|
+
- Relevant components: [Component names]
|
|
55
|
+
|
|
56
|
+
Definition of Done:
|
|
57
|
+
- [ ] All acceptance criteria met
|
|
58
|
+
- [ ] Unit tests written and passing
|
|
59
|
+
- [ ] No critical security issues
|
|
60
|
+
- [ ] Code follows project conventions
|
|
61
|
+
```
|
|
62
|
+
|
|
63
|
+
---
|
|
64
|
+
|
|
65
|
+
## Concurrent Security Review
|
|
66
|
+
|
|
67
|
+
After Dev Agent delivers code, Security Agent reviews immediately:
|
|
68
|
+
|
|
69
|
+
```
|
|
70
|
+
[ACTIVATING: Security Agent]
|
|
71
|
+
|
|
72
|
+
Task: Security review of the following implementation.
|
|
73
|
+
Feature: [Feature name]
|
|
74
|
+
Code: [Dev Agent output]
|
|
75
|
+
|
|
76
|
+
Focus areas:
|
|
77
|
+
- Input validation
|
|
78
|
+
- Authentication/authorization
|
|
79
|
+
- Data exposure
|
|
80
|
+
- Error handling (no sensitive data in errors)
|
|
81
|
+
- Dependency risks
|
|
82
|
+
```
|
|
83
|
+
|
|
84
|
+
---
|
|
85
|
+
|
|
86
|
+
## Phase 3 Quality Gate
|
|
87
|
+
|
|
88
|
+
```
|
|
89
|
+
✅ BUILD → VERIFY Quality Gate
|
|
90
|
+
|
|
91
|
+
For each feature:
|
|
92
|
+
[ ] All acceptance criteria are implemented
|
|
93
|
+
[ ] Unit tests exist and pass
|
|
94
|
+
[ ] No CRITICAL or HIGH security findings unresolved
|
|
95
|
+
[ ] Code follows project conventions
|
|
96
|
+
[ ] Error handling is complete
|
|
97
|
+
[ ] No hardcoded secrets
|
|
98
|
+
|
|
99
|
+
Overall:
|
|
100
|
+
[ ] All MVP features are implemented
|
|
101
|
+
[ ] Code is in version control
|
|
102
|
+
[ ] Environment is reproducible (setup script or Docker)
|
|
103
|
+
```
|
|
104
|
+
|
|
105
|
+
---
|
|
106
|
+
|
|
107
|
+
## BUILD Phase Artifacts
|
|
108
|
+
|
|
109
|
+
| Artifact | Owner | Status Needed |
|
|
110
|
+
|---|---|---|
|
|
111
|
+
| Feature implementations | Dev Agent | Reviewed |
|
|
112
|
+
| Unit tests | Dev Agent | Passing |
|
|
113
|
+
| Security findings (per feature) | Security Agent | Resolved or accepted |
|
|
@@ -0,0 +1,101 @@
|
|
|
1
|
+
# MDAN Phase 4 — VERIFY
|
|
2
|
+
|
|
3
|
+
> **Goal:** Validate that what was built works correctly, securely, and completely.
|
|
4
|
+
> **Agents:** Test Agent, Security Agent
|
|
5
|
+
> **Output:** Validated test suite, security report, signed-off quality gate
|
|
6
|
+
|
|
7
|
+
---
|
|
8
|
+
|
|
9
|
+
## Phase Overview
|
|
10
|
+
|
|
11
|
+
VERIFY is where MDAN proves the software works — not assumes it does. Every acceptance criterion
|
|
12
|
+
is tested. Every security finding from BUILD is verified as resolved. Performance is measured.
|
|
13
|
+
|
|
14
|
+
**Rule:** "It works on my machine" is not verification. Repeatable, automated tests are.
|
|
15
|
+
|
|
16
|
+
---
|
|
17
|
+
|
|
18
|
+
## MDAN Core Behavior in VERIFY
|
|
19
|
+
|
|
20
|
+
1. **Announces** Phase 4: VERIFY
|
|
21
|
+
2. **Activates Test Agent** for full test suite creation
|
|
22
|
+
3. **Activates Security Agent** for final security review
|
|
23
|
+
4. **Validates all findings** are resolved or explicitly accepted
|
|
24
|
+
5. **Runs Phase Gate check**
|
|
25
|
+
|
|
26
|
+
---
|
|
27
|
+
|
|
28
|
+
## Test Agent Activation Script
|
|
29
|
+
|
|
30
|
+
```
|
|
31
|
+
[ACTIVATING: Test Agent]
|
|
32
|
+
|
|
33
|
+
Task: Create and execute the full test suite for this project.
|
|
34
|
+
|
|
35
|
+
PRD (acceptance criteria): [Link/paste]
|
|
36
|
+
Architecture: [Link/paste]
|
|
37
|
+
Implemented features: [List of completed features]
|
|
38
|
+
|
|
39
|
+
Expected output:
|
|
40
|
+
1. Complete test plan
|
|
41
|
+
2. Unit tests for all features
|
|
42
|
+
3. Integration tests for critical flows
|
|
43
|
+
4. E2E test scenarios
|
|
44
|
+
5. Performance test criteria
|
|
45
|
+
6. Test results summary
|
|
46
|
+
```
|
|
47
|
+
|
|
48
|
+
---
|
|
49
|
+
|
|
50
|
+
## Final Security Review Activation
|
|
51
|
+
|
|
52
|
+
```
|
|
53
|
+
[ACTIVATING: Security Agent]
|
|
54
|
+
|
|
55
|
+
Task: Final security review of the complete application.
|
|
56
|
+
|
|
57
|
+
Previous security findings: [List with resolution status]
|
|
58
|
+
Full codebase: [Context/summary]
|
|
59
|
+
Deployment configuration: [From DevOps Agent if available]
|
|
60
|
+
|
|
61
|
+
Expected output:
|
|
62
|
+
1. Verification that previous findings are resolved
|
|
63
|
+
2. Any new findings discovered
|
|
64
|
+
3. Final security sign-off (or list of blockers)
|
|
65
|
+
```
|
|
66
|
+
|
|
67
|
+
---
|
|
68
|
+
|
|
69
|
+
## Phase 4 Quality Gate
|
|
70
|
+
|
|
71
|
+
```
|
|
72
|
+
✅ VERIFY → SHIP Quality Gate
|
|
73
|
+
|
|
74
|
+
Testing:
|
|
75
|
+
[ ] All acceptance criteria have corresponding tests
|
|
76
|
+
[ ] All tests pass (0 failures)
|
|
77
|
+
[ ] Test coverage meets target (e.g., 80%)
|
|
78
|
+
[ ] Integration tests pass
|
|
79
|
+
[ ] At least 3 E2E scenarios pass
|
|
80
|
+
[ ] Performance criteria are met
|
|
81
|
+
|
|
82
|
+
Security:
|
|
83
|
+
[ ] All CRITICAL findings resolved
|
|
84
|
+
[ ] All HIGH findings resolved or explicitly accepted with rationale
|
|
85
|
+
[ ] Final security review completed
|
|
86
|
+
[ ] No new CRITICAL findings
|
|
87
|
+
|
|
88
|
+
Quality:
|
|
89
|
+
[ ] No known bugs that affect MVP functionality
|
|
90
|
+
[ ] Error messages are user-friendly (no stack traces exposed)
|
|
91
|
+
[ ] Application handles edge cases gracefully
|
|
92
|
+
```
|
|
93
|
+
|
|
94
|
+
---
|
|
95
|
+
|
|
96
|
+
## VERIFY Phase Artifacts
|
|
97
|
+
|
|
98
|
+
| Artifact | Template | Owner | Status Needed |
|
|
99
|
+
|---|---|---|---|
|
|
100
|
+
| Test Plan | `templates/TEST-PLAN.md` | Test Agent | Complete |
|
|
101
|
+
| Security Report | `templates/SECURITY-REVIEW.md` | Security Agent | Signed off |
|
|
@@ -0,0 +1,156 @@
|
|
|
1
|
+
# MDAN Phase 5 — SHIP
|
|
2
|
+
|
|
3
|
+
> **Goal:** Deploy with confidence. Document completely. Celebrate responsibly.
|
|
4
|
+
> **Agents:** DevOps Agent, Doc Agent
|
|
5
|
+
> **Output:** Live deployment, complete documentation, changelog
|
|
6
|
+
|
|
7
|
+
---
|
|
8
|
+
|
|
9
|
+
## Phase Overview
|
|
10
|
+
|
|
11
|
+
SHIP is the final phase. But shipping is not just "deploying" — it's making sure the product
|
|
12
|
+
is live, stable, observable, and documented. A product that ships without documentation or
|
|
13
|
+
monitoring isn't done.
|
|
14
|
+
|
|
15
|
+
**Rule:** You haven't shipped until users can use it AND you can maintain it.
|
|
16
|
+
|
|
17
|
+
---
|
|
18
|
+
|
|
19
|
+
## MDAN Core Behavior in SHIP
|
|
20
|
+
|
|
21
|
+
1. **Announces** Phase 5: SHIP
|
|
22
|
+
2. **Activates DevOps Agent** for deployment pipeline
|
|
23
|
+
3. **Activates Doc Agent** for complete documentation
|
|
24
|
+
4. **Conducts pre-deployment checklist**
|
|
25
|
+
5. **Validates deployment**
|
|
26
|
+
6. **Celebrates the launch** 🚀
|
|
27
|
+
|
|
28
|
+
---
|
|
29
|
+
|
|
30
|
+
## DevOps Agent Activation Script
|
|
31
|
+
|
|
32
|
+
```
|
|
33
|
+
[ACTIVATING: DevOps Agent]
|
|
34
|
+
|
|
35
|
+
Task: Prepare and execute deployment for this project.
|
|
36
|
+
|
|
37
|
+
Architecture: [Link/paste]
|
|
38
|
+
Tech stack: [Stack details]
|
|
39
|
+
Deployment target: [Cloud/infrastructure]
|
|
40
|
+
Environments needed: [dev/staging/prod]
|
|
41
|
+
|
|
42
|
+
Expected output:
|
|
43
|
+
1. Dockerfile(s)
|
|
44
|
+
2. CI/CD pipeline configuration
|
|
45
|
+
3. Infrastructure as Code
|
|
46
|
+
4. Monitoring and alerting setup
|
|
47
|
+
5. Health check configuration
|
|
48
|
+
6. Deployment runbook
|
|
49
|
+
```
|
|
50
|
+
|
|
51
|
+
---
|
|
52
|
+
|
|
53
|
+
## Doc Agent Activation Script
|
|
54
|
+
|
|
55
|
+
```
|
|
56
|
+
[ACTIVATING: Doc Agent]
|
|
57
|
+
|
|
58
|
+
Task: Create complete documentation for this project.
|
|
59
|
+
|
|
60
|
+
PRD: [Link/paste]
|
|
61
|
+
Architecture: [Link/paste]
|
|
62
|
+
API spec: [Link/paste]
|
|
63
|
+
Implemented features: [List]
|
|
64
|
+
|
|
65
|
+
Expected output:
|
|
66
|
+
1. README.md (installation, configuration, quick start)
|
|
67
|
+
2. API documentation
|
|
68
|
+
3. CHANGELOG.md (initial release)
|
|
69
|
+
4. CONTRIBUTING.md
|
|
70
|
+
5. Any user guides needed
|
|
71
|
+
```
|
|
72
|
+
|
|
73
|
+
---
|
|
74
|
+
|
|
75
|
+
## Pre-Deployment Checklist
|
|
76
|
+
|
|
77
|
+
MDAN Core runs this before any production deployment:
|
|
78
|
+
|
|
79
|
+
```
|
|
80
|
+
🚀 Pre-Deployment Checklist
|
|
81
|
+
|
|
82
|
+
Infrastructure:
|
|
83
|
+
[ ] Staging deployment successful and validated
|
|
84
|
+
[ ] Database migrations tested on staging
|
|
85
|
+
[ ] Environment variables configured in production
|
|
86
|
+
[ ] SSL/TLS certificates configured
|
|
87
|
+
[ ] Domain DNS configured
|
|
88
|
+
|
|
89
|
+
Quality:
|
|
90
|
+
[ ] All VERIFY phase gates passed
|
|
91
|
+
[ ] No open CRITICAL or HIGH issues
|
|
92
|
+
[ ] Load test passed on staging
|
|
93
|
+
|
|
94
|
+
Operations:
|
|
95
|
+
[ ] Monitoring dashboards configured
|
|
96
|
+
[ ] Alerting configured and tested
|
|
97
|
+
[ ] Rollback procedure documented and tested
|
|
98
|
+
[ ] On-call engineer identified
|
|
99
|
+
[ ] Status page ready (if applicable)
|
|
100
|
+
|
|
101
|
+
Documentation:
|
|
102
|
+
[ ] README is complete and accurate
|
|
103
|
+
[ ] API documentation is published
|
|
104
|
+
[ ] CHANGELOG reflects current release
|
|
105
|
+
[ ] Runbook is complete
|
|
106
|
+
|
|
107
|
+
Sign-off:
|
|
108
|
+
[ ] User approves production deployment
|
|
109
|
+
```
|
|
110
|
+
|
|
111
|
+
---
|
|
112
|
+
|
|
113
|
+
## Post-Deployment Validation
|
|
114
|
+
|
|
115
|
+
After deployment, MDAN Core checks:
|
|
116
|
+
|
|
117
|
+
```
|
|
118
|
+
✅ Post-Deployment Validation
|
|
119
|
+
|
|
120
|
+
[ ] Application is accessible at production URL
|
|
121
|
+
[ ] Health check endpoint returns 200
|
|
122
|
+
[ ] Key user flows work end-to-end in production
|
|
123
|
+
[ ] No spike in error rates
|
|
124
|
+
[ ] No unexpected latency
|
|
125
|
+
[ ] Monitoring shows healthy metrics
|
|
126
|
+
|
|
127
|
+
If all pass: SHIP phase complete. Project delivered. 🎉
|
|
128
|
+
If any fail: Immediate rollback + investigate
|
|
129
|
+
```
|
|
130
|
+
|
|
131
|
+
---
|
|
132
|
+
|
|
133
|
+
## SHIP Phase Artifacts
|
|
134
|
+
|
|
135
|
+
| Artifact | Template | Owner | Status Needed |
|
|
136
|
+
|---|---|---|---|
|
|
137
|
+
| Dockerfile(s) | — | DevOps Agent | Complete |
|
|
138
|
+
| CI/CD Pipeline | — | DevOps Agent | Active |
|
|
139
|
+
| Infrastructure code | — | DevOps Agent | Applied |
|
|
140
|
+
| README | `templates/` | Doc Agent | Published |
|
|
141
|
+
| API Docs | — | Doc Agent | Published |
|
|
142
|
+
| CHANGELOG | `templates/CHANGELOG.md` | Doc Agent | Published |
|
|
143
|
+
| Runbook | — | DevOps Agent | Complete |
|
|
144
|
+
|
|
145
|
+
---
|
|
146
|
+
|
|
147
|
+
## After SHIP: What's Next?
|
|
148
|
+
|
|
149
|
+
MDAN ends with SHIP — but software doesn't end there. After a successful ship:
|
|
150
|
+
|
|
151
|
+
1. **Monitor** the first 48 hours closely
|
|
152
|
+
2. **Gather feedback** from real users
|
|
153
|
+
3. **Prioritize** next sprint from "Should Have" backlog
|
|
154
|
+
4. **Start a new MDAN cycle** for the next iteration
|
|
155
|
+
|
|
156
|
+
MDAN is designed for iterative development. Each cycle strengthens the product.
|