mddd-cli 3.3.1 → 4.0.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/bin/cli.js +1 -1
- package/bin/cli.spec.md +9 -3
- package/package.json +2 -1
- package/src/commands/init.js +28 -300
- package/src/skills/md-audit/content.js +52 -0
- package/src/skills/md-edit/content.js +73 -0
- package/src/skills/md-impl/content.js +87 -0
- package/src/skills/md-new/content.js +45 -0
- package/src/workflows/mddd-preview.yml.js +61 -0
- package/src/commands/init.spec.md +0 -265
package/bin/cli.js
CHANGED
|
@@ -16,7 +16,7 @@ const program = new Command();
|
|
|
16
16
|
program
|
|
17
17
|
.name('md')
|
|
18
18
|
.description('Manager for co-located specifications for Mermaid Diagram Driven Development (MDDD)')
|
|
19
|
-
.version('
|
|
19
|
+
.version('4.0.0');
|
|
20
20
|
|
|
21
21
|
// ==========================================
|
|
22
22
|
// COMMAND: md init
|
package/bin/cli.spec.md
CHANGED
|
@@ -1,11 +1,11 @@
|
|
|
1
|
-
# CLI Module | v4.
|
|
1
|
+
# CLI Module | v4.2.0 (Stable)
|
|
2
2
|
|
|
3
3
|
## 1. Flow Contract (Mermaid)
|
|
4
4
|
|
|
5
5
|
### 1.1 Topologia Atual (As-Is)
|
|
6
6
|
|
|
7
7
|
```mermaid
|
|
8
|
-
%% @spec-version v4.
|
|
8
|
+
%% @spec-version v4.2.0
|
|
9
9
|
graph TD
|
|
10
10
|
subgraph "CLI Entry (bin/cli.js)"
|
|
11
11
|
A[bin/cli.js: Commander Router] --> B[delegate to ./commands/init.js]
|
|
@@ -21,9 +21,13 @@ graph TD
|
|
|
21
21
|
D --> E
|
|
22
22
|
E --> F[fs/promises]
|
|
23
23
|
end
|
|
24
|
+
|
|
25
|
+
subgraph "External Dependencies"
|
|
26
|
+
F --> G["@mermaid-js/mermaid-cli"]
|
|
27
|
+
end
|
|
24
28
|
```
|
|
25
29
|
|
|
26
|
-
O diagrama acima reflete a arquitetura final e estável pós-refatoração: separação clara entre CLI Entry, Commands Layer e Shared Services, com injeção de dependência do `FileSystemService`.
|
|
30
|
+
O diagrama acima reflete a arquitetura final e estável pós-refatoração: separação clara entre CLI Entry, Commands Layer e Shared Services, com injeção de dependência do `FileSystemService`. O `@mermaid-js/mermaid-cli` é uma dependência externa instalada junto com o pacote para renderização de diagramas Mermaid.
|
|
27
31
|
|
|
28
32
|
## 2. Decision Matrix
|
|
29
33
|
|
|
@@ -33,6 +37,7 @@ O diagrama acima reflete a arquitetura final e estável pós-refatoração: sepa
|
|
|
33
37
|
| `src/commands/init.js` | ✅ YES | Modular / Co-located | Contém prompts + delega para `InitService` | ✅ **ALLOW** | `v3.0.0` |
|
|
34
38
|
| `src/services/InitService.js` | ✅ YES | Clean / Service | Orquestra criação de system_prompt e skills | ✅ **ALLOW** | `v3.0.0` |
|
|
35
39
|
| `src/services/FileSystemService.js` | ✅ YES | Clean / Service | Abstrai `fs/promises` com DI | ✅ **ALLOW** | `v3.0.0` |
|
|
40
|
+
| `@mermaid-js/mermaid-cli` | N/A | External Dependency | Renderização de diagramas Mermaid via CLI | ✅ **ALLOW** | `v4.2.0` |
|
|
36
41
|
|
|
37
42
|
### Fatores Primitivos de Qualidade
|
|
38
43
|
|
|
@@ -57,6 +62,7 @@ O diagrama acima reflete a arquitetura final e estável pós-refatoração: sepa
|
|
|
57
62
|
| 2026-05-27 | Cline (Agent-Actor) | v3.0.0 | **MAJOR Mutation (v2.0.0 → v3.0.0):** Removidos comandos `new`, `edit`, `audit` e `impl` do escopo do CLI. Diagramas As-Is e To-Be simplificados para refletir apenas o comando `init` restante. Matriz de decisão e fatores de acoplamento atualizados. |
|
|
58
63
|
| 2026-05-28 | Cline (Agent-Actor) | v4.0.0 | **MAJOR Mutation (v3.0.0 → v4.0.0):** Refatoração concluída e estabilizada. Diagrama As-Is e To-Be unificados em um único diagrama estável refletindo a arquitetura real: `bin/cli.js` (37 linhas) → `src/commands/init.js` → `src/services/InitService.js` + `src/services/FileSystemService.js`. Título alterado de "Refactoring Plan" para "CLI Module (Stable)". Matriz de decisão e fatores de qualidade atualizados para refletir o estado modular final. |
|
|
59
64
|
| 2026-05-28 | Cline (md-audit) | v4.1.0 | **MINOR Mutation (v4.0.0 → v4.1.0):** Criados specs faltantes `src/services/FileSystemService.spec.md` e `src/services/InitService.spec.md` via `md-audit`. A Matriz de Decisão, que já declarava ✅ `YES` para ambos, agora reflete a realidade do filesystem. Nenhuma alteração em código de produção. |
|
|
65
|
+
| 2026-05-30 | Cline (Agent-Actor) | v4.2.0 | **MINOR Mutation (v4.1.0 → v4.2.0):** Adicionado `@mermaid-js/mermaid-cli@^11.15.0` como dependência no `package.json`. Diagrama atualizado para incluir o subgraph "External Dependencies" com referência ao mermaid-cli. Matriz de decisão estendida com linha para a dependência externa. |
|
|
60
66
|
|
|
61
67
|
### Análise de Qualidade
|
|
62
68
|
|
package/package.json
CHANGED
|
@@ -1,6 +1,6 @@
|
|
|
1
1
|
{
|
|
2
2
|
"name": "mddd-cli",
|
|
3
|
-
"version": "
|
|
3
|
+
"version": "4.0.0",
|
|
4
4
|
"description": "Official CLI for modular, co-located, and versioned Mermaid Diagram Driven Development (MDDD).",
|
|
5
5
|
"type": "module",
|
|
6
6
|
"exports": "./bin/cli.js",
|
|
@@ -38,6 +38,7 @@
|
|
|
38
38
|
},
|
|
39
39
|
"homepage": "https://github.com/JulioCRFilho/mermaid-diagram-driven-development#readme",
|
|
40
40
|
"dependencies": {
|
|
41
|
+
"@mermaid-js/mermaid-cli": "^11.15.0",
|
|
41
42
|
"commander": "^12.0.0",
|
|
42
43
|
"picocolors": "^1.0.0"
|
|
43
44
|
}
|
package/src/commands/init.js
CHANGED
|
@@ -1,319 +1,47 @@
|
|
|
1
1
|
#!/usr/bin/env node
|
|
2
2
|
|
|
3
|
+
import { readFileSync } from 'node:fs';
|
|
4
|
+
import { fileURLToPath } from 'node:url';
|
|
5
|
+
import path from 'node:path';
|
|
3
6
|
import pc from 'picocolors';
|
|
4
7
|
|
|
5
|
-
|
|
6
|
-
|
|
7
|
-
|
|
8
|
-
|
|
9
|
-
|
|
10
|
-
|
|
11
|
-
You are an engineering agent operating strictly under MDDD. Your cognitive processing is guided by visual topologies and truth tables, completely eliminating text-based specification ambiguity.
|
|
12
|
-
|
|
13
|
-
\`\`\`mermaid
|
|
14
|
-
%% @spec-version v1.0.0
|
|
15
|
-
stateDiagram-v2
|
|
16
|
-
[*] --> ReadSpecification: User Trigger Fired
|
|
17
|
-
ReadSpecification --> CheckDecisionMatrix: Evaluate Primitive Factors
|
|
18
|
-
CheckDecisionMatrix --> HaltWithConflict: Constraint Violation / Feature Creep
|
|
19
|
-
CheckDecisionMatrix --> ExecuteAction: Strict Match Confirmed
|
|
20
|
-
ExecuteAction --> MutateState: Apply File/Code Changes
|
|
21
|
-
MutateState --> UpdateVersionHeader: Apply Semantic Version Rules
|
|
22
|
-
UpdateVersionHeader --> [*]
|
|
23
|
-
\`\`\`
|
|
24
|
-
|
|
25
|
-
## 1. Co-location Architecture Tree
|
|
26
|
-
|
|
27
|
-
src/
|
|
28
|
-
└── [domain]/
|
|
29
|
-
├── [domain_name].spec.md # 🌎 Macro Module Domain
|
|
30
|
-
└── [feature_name]/
|
|
31
|
-
├── [feature_name].spec.md # 🔬 Micro Flow Contract + Decision Matrix
|
|
32
|
-
└── [feature_name].* # 💻 Target Production Code File (Any Extension)
|
|
33
|
-
|
|
34
|
-
## 2. Parent Interaction Logic
|
|
35
|
-
|
|
36
|
-
\`\`\`mermaid
|
|
37
|
-
graph TD
|
|
38
|
-
A[Create/Change Sub-Feature] --> B[Open Indicated Parent File]
|
|
39
|
-
B --> C[Locate Bifurcation Node in Parent Mermaid]
|
|
40
|
-
C --> D[Modify Parent Graph: Point Arrow to New State]
|
|
41
|
-
D --> E[Child File: Inherit Parent Context in Entry Node]
|
|
42
|
-
\`\`\`
|
|
43
|
-
|
|
44
|
-
## 3. Core Behavioral Framework Matrix
|
|
45
|
-
|
|
46
|
-
| User Context | Target Spec Header | Human Request Path | Diagram Change Impact | AI Core Rule / Mandate / Ironclad Clause |
|
|
47
|
-
| :---: | :---: | :---: | :---: | :--- |
|
|
48
|
-
| | | | - | **MISSING** | - | - | Never remove, omit, or bypass the version tag from files. |
|
|
49
|
-
| | | | Code Change Needed | **SIGNED** | Contradicts Matrix | - | 🛑 **HALT**: Refuse code generation. Demand \`md edit\` to align design first. |
|
|
50
|
-
| | | | Feature Writing | - | Continuous Text Block | - | 📊 **STRUCTURE**: Convert text into tables of primitive factors (yes/no/rigid values). |
|
|
51
|
-
| | | | Command Executed | \`SPEC_VERSION\` | - | Typo / Label Only | Increment Patch (\`X.Y.Z\` -> \`X.Y.Z+1\`) |
|
|
52
|
-
| | | | Command Executed | \`SPEC_VERSION\` | - | New State / Arrow / Matrix Column | Increment Minor (\`X.Y.Z\` -> \`X.Y+1.0\`) |
|
|
53
|
-
| | | | Command Executed | \`SPEC_VERSION\` | - | Structural Breaking / Flow Overhaul | Increment Major (\`X.Y.Z\` -> \`X+1.0.0\`) |
|
|
54
|
-
|
|
55
|
-
## 4. Anti-Hallucination Guardrails
|
|
56
|
-
1. **No Spec, No Code:** You are strictly forbidden from writing a single line of production code or unit tests if the corresponding \`.spec.md\` file does not exist or does not contain a populated Decision Matrix.
|
|
57
|
-
2. **Implicit Logic Ban:** If a business condition, validation check, or outcome branch is not explicitly listed as a row or column in the Decision Matrix, it does not exist. Do not assume, extrapolate, or invent fallback behaviors.
|
|
58
|
-
3. **Strict State Isolation:** When handling a micro feature, you cannot introduce global states or modify sibling domains unless instructed via explicit macro architectural mapping updates.
|
|
59
|
-
4. **Idempotent Full-File Output Mandate:** You are completely forbidden from using code placeholders, truncating files, or emitting partial snippets (e.g., "// rest of class unchanged", "/* TODO */"). Every code generation action must output the entire, clean, compile-ready file from scratch, ensuring perfect context preservation.
|
|
60
|
-
5. **Spec-First Ordering Mandate:** You are strictly forbidden from editing, modifying, or generating any production code file (.js, .ts, .py, .go, etc.) before the corresponding co-located \`.spec.md\` file has been created or updated to reflect the intended changes. The \`.spec.md\` must always be written or updated first — the spec is the source of truth, and code is derived from it. Violating this ordering constitutes a direct MDDD protocol breach and invalidates the entire change cycle.`;
|
|
8
|
+
import mdNewContent from '../skills/md-new/content.js';
|
|
9
|
+
import mdEditContent from '../skills/md-edit/content.js';
|
|
10
|
+
import mdAuditContent from '../skills/md-audit/content.js';
|
|
11
|
+
import mdImplContent from '../skills/md-impl/content.js';
|
|
12
|
+
import { GITHUB_WORKFLOW_CONTENT } from '../workflows/mddd-preview.yml.js';
|
|
61
13
|
|
|
62
14
|
/**
|
|
63
|
-
*
|
|
15
|
+
* Build the SKILLS map from co-located modules.
|
|
16
|
+
* @type {Record<string, string>}
|
|
64
17
|
*/
|
|
65
|
-
|
|
66
|
-
'md-new':
|
|
67
|
-
|
|
68
|
-
|
|
69
|
-
|
|
70
|
-
stateDiagram-v2
|
|
71
|
-
[*] --> TargetVerification
|
|
72
|
-
TargetVerification --> StopAndSwitchToEdit: .spec.md File Already Exists
|
|
73
|
-
TargetVerification --> EvaluateContext: File Does Not Exist
|
|
74
|
-
|
|
75
|
-
state EvaluateContext {
|
|
76
|
-
[*] --> CheckDirectoryDepth
|
|
77
|
-
CheckDirectoryDepth --> InferMacro: Target is Domain Root (e.g., src/domain)
|
|
78
|
-
CheckDirectoryDepth --> InferMicro: Target is Sub-Feature (e.g., src/domain/feature)
|
|
79
|
-
}
|
|
80
|
-
|
|
81
|
-
InferMacro --> ExecCliNew: Apply stateDiagram-v2 Template
|
|
82
|
-
InferMicro --> ExecCliNew: Apply graph LR + Matrix Template
|
|
83
|
-
|
|
84
|
-
ExecCliNew --> AwaitHumanReview: Run "md new [path]" & Populate Blueprint
|
|
85
|
-
AwaitHumanReview --> [*]: Pause Code & Test Generation
|
|
86
|
-
\`\`\`
|
|
87
|
-
|
|
88
|
-
### Operational Execution Matrix
|
|
89
|
-
|
|
90
|
-
| File Exists? | Path Depth Type | Parent Indicated? | CLI Execution Syntax | Target Payload Blueprint | Next AI Action |
|
|
91
|
-
| :---: | :---: | :---: | :--- | :--- | :---: |
|
|
92
|
-
| ✅ YES | - | - | *None* (Aborted) | *None* | 🛑 **STOP** (Call md-edit instead) |
|
|
93
|
-
| ❌ NO | Domain Root | ❌ NO | \`md new [domain_path]\` | \`stateDiagram-v2\` Placeholder Domain Map | ⏳ **AWAIT_VISUAL_APPROVAL** |
|
|
94
|
-
| ❌ NO | Sub-Feature | ❌ NO | \`md new [feature_path]\` | \`graph LR\` + Auto-scanned parent link reference | ⏳ **AWAIT_VISUAL_APPROVAL** |
|
|
95
|
-
| ❌ NO | Sub-Feature | ✅ YES | \`md new [feature_path] -p[parent]\` | \`graph LR\` + Explicit link injected to designated Parent | ⏳ **AWAIT_VISUAL_APPROVAL** |
|
|
96
|
-
|
|
97
|
-
### Automation & Inference Ironclad Rules
|
|
98
|
-
1. **Deterministic Inference:** You must strictly follow the directory depth. If the target path is a top-level domain folder inside your source root, treat it as a Module Macro. If it is nested inside a domain, it is a Micro Feature. Never ask the user to declare this.
|
|
99
|
-
2. **Implicit Parent Binding:** When creating a Sub-Feature without an explicit \`-p\` parameter, acknowledge that the CLI tool will automatically scan and mutate the nearest parent macro file via recursive climbing. You must read the updated parent immediately after execution to synchronize your internal context map.
|
|
100
|
-
3. Agnostic Blueprint Initialization: When generating the initial blueprint files, you must scan the neighboring files in the target domain directory to identify the current programming language and framework conventions. Adapt your placeholder references to strictly pair with the localized file architecture.`,
|
|
101
|
-
|
|
102
|
-
'md-edit': `[ROLE: ARCHITECT] [STRICT CONTRACT]
|
|
103
|
-
|
|
104
|
-
\`\`\`mermaid
|
|
105
|
-
%% @spec-version v1.2.0
|
|
106
|
-
graph LR
|
|
107
|
-
A[Read Target .spec.md] --> B[Parse Current SPEC_VERSION]
|
|
108
|
-
B --> C[Apply Mermaid/Matrix Adjustments]
|
|
109
|
-
C --> D{Evaluate Mutation Scope}
|
|
110
|
-
|
|
111
|
-
D -->|Typo / Label Fix| E[Increment Patch: Bump Z in X.Y.Z]
|
|
112
|
-
D -->|New Node / Flow Path / Factor| F[Increment Minor: Bump Y in X.Y.Z]
|
|
113
|
-
D -->|Breaking Overhaul / Restructure| G[Increment Major: Bump X in X.Y.Z]
|
|
114
|
-
|
|
115
|
-
E --> H[Validate Mermaid Syntax]
|
|
116
|
-
F --> H
|
|
117
|
-
G --> H
|
|
118
|
-
|
|
119
|
-
H -->|Syntax Valid| I[Write .spec.md to Disk with Updated Version]
|
|
120
|
-
H -->|Syntax Invalid| J[🛑 HALT: Abort & Ask Human]
|
|
121
|
-
I --> K{Spec Status Assessment}
|
|
122
|
-
K -->|Is draft| L[Tag as draft proposal - AWAIT_USER_VALIDATION]
|
|
123
|
-
K -->|Is stable| M[Tag as stable - STALE_LOCKED]
|
|
124
|
-
L --> N[Append Audit History Entry]
|
|
125
|
-
M --> N
|
|
126
|
-
N --> O[Persist Updated File]
|
|
127
|
-
O --> [*]
|
|
128
|
-
\`\`\`
|
|
129
|
-
|
|
130
|
-
### Evolution Versioning Matrix
|
|
131
|
-
|
|
132
|
-
| Structural Change Type | Adds Factor Column? | Adds Transition Node/Arrow? | Label / Typo Corrections Only? | Semantic Version Modification | Spec Status After Edit | Target AI State |
|
|
133
|
-
| :--- | :---: | :---: | :---: | :---: | :---: | :---: |
|
|
134
|
-
| Complete Business Overhaul | - | - | - | **MAJOR Mutation (X.Y.Z -> X+1.0.0)** | **draft** (proposal) | ⏳ **AWAIT_USER_VALIDATION** |
|
|
135
|
-
| New Context Conditional Branch | ✅ YES | - | - | **MINOR Mutation (X.Y.Z -> X.Y+1.0)** | **draft** (proposal) | ⏳ **AWAIT_USER_VALIDATION** |
|
|
136
|
-
| New UI Flow Step / Lifecycle State | ❌ NO | ✅ YES | - | **MINOR Mutation (X.Y.Z -> X.Y+1.0)** | **draft** (proposal) | ⏳ **AWAIT_USER_VALIDATION** |
|
|
137
|
-
| Visual Spacing / Text Refinement | ❌ NO | ❌ NO | ✅ YES | **PATCH Mutation (X.Y.Z -> X.Y.Z+1)** | **stable** (locked) | ✅ **STABLE_LOCKED** |
|
|
138
|
-
|
|
139
|
-
### Mutation Integrity Ironclad Rules
|
|
140
|
-
1. **Incremental SemVer Locking:** You must read the existing \`SPEC_VERSION\` from the file header before modifying it. Never reset, guess, or overwrite the version to a lower state. Bumping Minor explicitly drops the patch version to zero (\`X.Y.Z\` -> \`X.Y+1.0\`). Bumping Major explicitly drops both minor and patch to zero (\`X.Y.Z\` -> \`X+1.0.0\`).
|
|
141
|
-
2. **Strict Syntax Guard:** Before writing the modifications to disk, execute an internal mental compilation of the Mermaid syntax. If any arrow (\`-->\`), state connector, or label syntax breaks the official Mermaid spec, immediately halt execution and report the error to the user without modifying the file.
|
|
142
|
-
3. **Audit History Log Requirement:** Every time you perform an edit, you must append a new row to the markdown table inside the \`<details><summary>Click to expand</summary>...</details>\` block at the bottom of the file, containing the current date, your agent identity, the new version number, and a concise summary of the changes made.
|
|
143
|
-
4. **Node ID Immutability:** When adding new transitions or nodes to an existing graph, you are strictly forbidden from altering, renaming, or refactoring the identifiers (IDs) of existing states/nodes unless explicitly requested by the user.
|
|
144
|
-
5. **Draft vs Stable Status Tagging:** Every edited \`.spec.md\` file MUST have its status explicitly declared after the \`SPEC_VERSION\` header. Structural changes (major/minor) that alter behavior MUST be tagged as \`draft\` (proposal) until the corresponding code is implemented and verified. Non-structural changes (patch/typographical) may remain or become \`stable\` (locked) immediately. The status format is: \`**SPEC_VERSION: vX.Y.Z — [draft|stable]**\`.
|
|
145
|
-
6. **Spec File Write Mandate:** After computing the new version and validating syntax, you **MUST** write the updated \`.spec.md\` file to disk. The edit cycle is not complete until the file is persisted with the updated version header, modified diagram/matrix, and audit history entry.`,
|
|
146
|
-
|
|
147
|
-
'md-audit': `[ROLE: SECURITY & QUALITY AUDITOR] [STRICT CONTRACT]
|
|
148
|
-
|
|
149
|
-
\`\`\`mermaid
|
|
150
|
-
%% @spec-version v1.2.0
|
|
151
|
-
stateDiagram-v2
|
|
152
|
-
[*] --> AnalyzeLegacyCode: Evaluate code quality, conciseness, and coupling
|
|
153
|
-
AnalyzeLegacyCode --> FileSystemCheck
|
|
154
|
-
|
|
155
|
-
state FileSystemCheck {
|
|
156
|
-
[*] --> CheckCoLocation
|
|
157
|
-
CheckCoLocation --> CreateMissingSpec: Target Co-located .spec.md Missing
|
|
158
|
-
CheckCoLocation --> AppendToExisting: Target Co-located .spec.md Exists
|
|
159
|
-
}
|
|
160
|
-
|
|
161
|
-
CreateMissingSpec --> RenderTopology: Create new co-located .spec.md
|
|
162
|
-
AppendToExisting --> InjectAuditBlock: Target Existing File Preservation Map
|
|
163
|
-
|
|
164
|
-
state RenderTopology {
|
|
165
|
-
[*] --> CodeIsClean: Map exact architecture as-is (v1.0.0 - stable)
|
|
166
|
-
[*] --> CodeIsChaotic: Draw BOTH current real logic AND ideal target refactored graph (v1.0.0 - draft)
|
|
167
|
-
}
|
|
168
|
-
|
|
169
|
-
RenderTopology --> WriteToAuditTag: Inject payloads inside <details> block
|
|
170
|
-
InjectAuditBlock --> WriteToAuditTag: Append to existing <details> block without overwriting business specs
|
|
171
|
-
WriteToAuditTag --> EnforceImmutability: Lock Production Code File
|
|
172
|
-
EnforceImmutability --> SpecFileGuaranteed: Validate .spec.md Exists and Is Populated
|
|
173
|
-
SpecFileGuaranteed --> [*]
|
|
174
|
-
\`\`\`
|
|
175
|
-
|
|
176
|
-
### Reverse Engineering & Auto-Repair Decision Matrix
|
|
177
|
-
|
|
178
|
-
| Source File State | Co-located .spec.md Exists? | Code Design Assessment | Target Output Destination | Code File Manipulation Allowed? | Initial Compiled Version | .spec.md Creation Guarantee |
|
|
179
|
-
| :--- | :---: | :---: | :--- | :---: | :---: | :---: |
|
|
180
|
-
| Legacy Code Active | ✅ YES | Clean / Modular | Append to existing \`<details><summary>Audit History</summary>\` | ❌ **FORBIDDEN (Immutability)** | Retain Current | ✅ **GUARANTEED** (Updated) |
|
|
181
|
-
| Legacy Code Active | ✅ YES | Chaotic / Coupled | Append to existing \`<details><summary>Audit History</summary>\` | ❌ **FORBIDDEN (Immutability)** | Retain Current | ✅ **GUARANTEED** (Updated) |
|
|
182
|
-
| Legacy Code Active | ❌ NO | Clean / Modular | Generate Spec File + Map Current Logic | ❌ **FORBIDDEN (Immutability)** | \`v1.0.0 - stable\` | ✅ **GUARANTEED** (Created) |
|
|
183
|
-
| Legacy Code Active | ❌ NO | Chaotic / Coupled | Generate Spec File + Map Current Logic AND Proposed Refactoring | ❌ **FORBIDDEN (Immutability)** | \`v1.0.0 - draft\` | ✅ **GUARANTEED** (Created) |
|
|
184
|
-
|
|
185
|
-
### Missing Spec Auto-Repair Blueprint Requirements
|
|
186
|
-
* **Enforce Section Injections:** Every generated specification file must structurally enforce:
|
|
187
|
-
1. \`SPEC_VERSION: v1.0.0\` metadata header at the very top.
|
|
188
|
-
2. \`stateDiagram-v2\` or \`graph LR\` derived exactly from code logic behaviors.
|
|
189
|
-
3. \`Decision Matrix\` tables filled if the code contains conditional execution branches.
|
|
190
|
-
4. An isolated \`<details><summary>Audit History</summary>...</details>\` block at the bottom containing the specific code review analytics.
|
|
191
|
-
|
|
192
|
-
### Quality Assurance & Immutability Ironclad Rules
|
|
193
|
-
1. **Absolute Immutability Command:** Under no circumstances are you allowed to patch, alter, or modify the target production code file during the \`md-audit\` cycle. Your execution scope is strictly limited to observation and documentation within the Markdown specification file.
|
|
194
|
-
2. **Preservation Guarantee:** When appending an audit report to an existing \`.spec.md\` file, you must read the file completely and guarantee that the business requirements, main diagrams, and current decision matrices are left untouched. You are only allowed to inject rows inside the \`<details>\` audit history block.
|
|
195
|
-
3. **Chaotic Code Double-Mapping:** If you evaluate the legacy code as chaotic or highly coupled, you must not replace the current reality with your ideal version. You are required to draw the current graph (flawed as it is) to serve as a baseline, and then provide a separate, clearly labeled Mermaid graph showing the suggested refactored topology.
|
|
196
|
-
4. **Spec Creation Guarantee:** Regardless of whether the co-located \`.spec.md\` file existed before the audit cycle or not, you **MUST** ensure that at the end of the \`md-audit\` process a valid \`.spec.md\` file exists in the target directory. If it did not exist: create it from scratch with all required sections. If it did exist: update it by appending the audit block. Never leave the audit target without a \`.spec.md\` file.
|
|
197
|
-
|
|
198
|
-
**Rule:** UNDER NO CIRCUMSTANCES MAY YOU COMPLETE AN \`md-audit\` CYCLE WITHOUT A CO-LOCATED \`.spec.md\` FILE.
|
|
199
|
-
`,
|
|
200
|
-
|
|
201
|
-
'md-impl': `[ROLE: SOFTWARE ENGINEER] [STRICT CONTRACT]
|
|
202
|
-
|
|
203
|
-
\`\`\`mermaid
|
|
204
|
-
%% @spec-version v1.2.0
|
|
205
|
-
graph TD
|
|
206
|
-
A[Ingest Signed .spec.md] --> B[Parse Matrix Rows & Version Header]
|
|
207
|
-
B --> C{Verify Code/Chat Request}
|
|
208
|
-
|
|
209
|
-
C -->|Matches Decision Matrix Rows 100%| D[Check File Target State]
|
|
210
|
-
C -->|Human Asks to Skip/Add Extraneous Scope| E[Trigger Prompt Injection Defense]
|
|
211
|
-
|
|
212
|
-
D -->|New File| F[Generate Full Structural Code from Scratch]
|
|
213
|
-
D -->|Existing File| G[Idempotent Overwrite: Read & Output Full File]
|
|
214
|
-
|
|
215
|
-
F --> H[Generate Truth-Table Unit Tests]
|
|
216
|
-
G --> H
|
|
217
|
-
|
|
218
|
-
H --> I{Tests Pass 100%?}
|
|
219
|
-
I -->|Yes| J[Promote .spec.md from draft to stable]
|
|
220
|
-
I -->|No| K[Fix Code/Tests & Retry]
|
|
221
|
-
|
|
222
|
-
J --> L[Update SPEC_VERSION to vSameVersion - stable]
|
|
223
|
-
L --> M[Append Audit History: impl complete]
|
|
224
|
-
M --> N[Persist Updated .spec.md to Disk]
|
|
225
|
-
N --> [*]
|
|
226
|
-
|
|
227
|
-
E --> O[Refuse Coding & Demand Spec Refinement via md-edit]
|
|
228
|
-
O --> [*]
|
|
229
|
-
\`\`\`
|
|
230
|
-
|
|
231
|
-
### Injection Defense & Execution Guard Matrix
|
|
232
|
-
|
|
233
|
-
| Spec Contract Signed? | Chat Prompt Code Alignment | Human Requests Bypassing Spec Matrix? | Core AI Action Authorized | Error Response Pattern |
|
|
234
|
-
| :---: | :---: | :---: | :--- | :--- |
|
|
235
|
-
| ❌ NO | - | - | ❌ **DENY GENERATION** | Demand invocation of \`md-new\` or \`md-audit\` |
|
|
236
|
-
| ✅ YES | ❌ Out-of-bounds | - | ❌ **DENY GENERATION** | "Please use the md-edit command to update the diagram..." |
|
|
237
|
-
| ✅ YES | - | ✅ YES (Feature Creep) | ❌ **DENY GENERATION** | "Please use the md-edit command to update the diagram..." |
|
|
238
|
-
| ✅ YES | ✅ 100% Rigid Match| ❌ NO | ✅ **ALLOW SOLID CODEGEN** | Complete compliance code + 100% matrix row unit tests |
|
|
239
|
-
|
|
240
|
-
### Production Implementation & Codegen Ironclad Rules
|
|
241
|
-
1. **The Matrix Test Alignment Mandate:** Your unit test suite must match the Decision Matrix row by row. For every single row present in the specification's truth table, you are strictly required to build at least one explicit, dedicated unit test case mapping those precise primitive factors to that exact outcome.
|
|
242
|
-
2. **Anti-Placeholder Clause:** You are absolutely forbidden from generating incomplete code structures, omitting code sections, or using placeholders like \`// TODO\`, \`// implementation goes here\`, or \`// rest of the class remains unchanged\`. You must always output the complete, compile-ready, and production-grade file layout.
|
|
243
|
-
3. **Strict SOLID Compliance:** Every piece of logic generated under this cycle must follow strict Clean Architecture principles and SOLID patterns. If the specification implies a new conditional branch, you must implement it using polymorphism or structured strategies rather than compounding nested \`if-else\` or pattern-matching anti-patterns unless explicitly dictated by the diagram topology.
|
|
244
|
-
4. **Draft-to-Stable Promotion Duty:** After all implementation and tests pass successfully, you **MUST** update the co-located \`.spec.md\` file to promote its status from \`draft\` to \`stable\`. The version number stays the same — only the status suffix changes. This marks the spec as implemented and locked.
|
|
245
|
-
5. **Spec File Lock After Implementation:** The \`.spec.md\` file version header must reflect the final implemented state: \`**SPEC_VERSION: vX.Y.Z — stable**\`. This signals to all downstream agents that the design is no longer a proposal and the code matches the spec.`,
|
|
18
|
+
const SKILLS = {
|
|
19
|
+
'md-new': mdNewContent,
|
|
20
|
+
'md-edit': mdEditContent,
|
|
21
|
+
'md-audit': mdAuditContent,
|
|
22
|
+
'md-impl': mdImplContent,
|
|
246
23
|
};
|
|
247
24
|
|
|
248
25
|
/**
|
|
249
|
-
*
|
|
250
|
-
*
|
|
251
|
-
*/
|
|
252
|
-
|
|
253
|
-
|
|
254
|
-
|
|
255
|
-
|
|
256
|
-
|
|
257
|
-
|
|
258
|
-
" - '**/*.spec.md'",
|
|
259
|
-
"",
|
|
260
|
-
"jobs:",
|
|
261
|
-
" render-preview:",
|
|
262
|
-
" runs-on: ubuntu-latest",
|
|
263
|
-
" permissions:",
|
|
264
|
-
" pull-requests: write",
|
|
265
|
-
" contents: read",
|
|
266
|
-
"",
|
|
267
|
-
" steps:",
|
|
268
|
-
" - name: ⬇️ Checkout Repository",
|
|
269
|
-
" uses: actions/checkout@v4",
|
|
270
|
-
" with:",
|
|
271
|
-
" fetch-depth: 0", // CRUCIAL: Traz o histórico completo para o git diff funcionar
|
|
272
|
-
"",
|
|
273
|
-
" - name: 📸 Build Preview Comment",
|
|
274
|
-
" id: build-comment",
|
|
275
|
-
' run: |',
|
|
276
|
-
' echo "comment<<EOF" >> "$GITHUB_OUTPUT"',
|
|
277
|
-
' echo "### 🗺️ MDDD - Design Changes Detected!" >> "$GITHUB_OUTPUT"',
|
|
278
|
-
' echo "Review the proposed specification and visual topology below before approving." >> "$GITHUB_OUTPUT"',
|
|
279
|
-
' echo "" >> "$GITHUB_OUTPUT"',
|
|
280
|
-
"",
|
|
281
|
-
' # Busca os arquivos modificados comparando dinamicamente com a branch destino do PR',
|
|
282
|
-
' CHANGED=$(git diff --name-only "origin/${{ github.base_ref }}...HEAD" -- "*.spec.md" 2>/dev/null || echo "")',
|
|
283
|
-
"",
|
|
284
|
-
" for file in $CHANGED; do",
|
|
285
|
-
' [ -f "$file" ] || continue',
|
|
286
|
-
' echo "" >> "$GITHUB_OUTPUT"',
|
|
287
|
-
' echo "#### 📄 File: \`${file}\`" >> "$GITHUB_OUTPUT"',
|
|
288
|
-
' echo "" >> "$GITHUB_OUTPUT"',
|
|
289
|
-
' echo "<details open>" >> "$GITHUB_OUTPUT"',
|
|
290
|
-
' echo "<summary>Click to collapse full specification preview</summary>" >> "$GITHUB_OUTPUT"',
|
|
291
|
-
' echo "" >> "$GITHUB_OUTPUT"',
|
|
292
|
-
"",
|
|
293
|
-
' # Injeta o conteúdo completo do arquivo markdown',
|
|
294
|
-
' cat "$file" >> "$GITHUB_OUTPUT"',
|
|
295
|
-
' echo "" >> "$GITHUB_OUTPUT"',
|
|
296
|
-
"",
|
|
297
|
-
' echo "</details>" >> "$GITHUB_OUTPUT"',
|
|
298
|
-
' echo "" >> "$GITHUB_OUTPUT"',
|
|
299
|
-
" done",
|
|
300
|
-
"",
|
|
301
|
-
' echo "EOF" >> "$GITHUB_OUTPUT"',
|
|
302
|
-
"",
|
|
303
|
-
" - name: 💬 Comment Preview on PR",
|
|
304
|
-
" uses: thollander/actions-comment-pull-request@v2",
|
|
305
|
-
" with:",
|
|
306
|
-
' message: "${{ steps.build-comment.outputs.comment }}"',
|
|
307
|
-
" comment_tag: 'mddd-design-preview'",
|
|
308
|
-
].join('\n');
|
|
26
|
+
* Resolve and read system_prompt.md from the project root.
|
|
27
|
+
* @returns {string}
|
|
28
|
+
*/
|
|
29
|
+
function readSystemPrompt() {
|
|
30
|
+
const currentFile = fileURLToPath(import.meta.url);
|
|
31
|
+
const rootDir = path.resolve(path.dirname(currentFile), '..', '..');
|
|
32
|
+
const promptPath = path.join(rootDir, 'system_prompt.md');
|
|
33
|
+
return readFileSync(promptPath, 'utf-8');
|
|
34
|
+
}
|
|
309
35
|
|
|
310
36
|
/**
|
|
311
|
-
* Executes the
|
|
37
|
+
* Executes the `md init` command.
|
|
312
38
|
* @param {import('../services/InitService.js').InitService} initService
|
|
313
39
|
* @returns {Promise<void>}
|
|
314
40
|
*/
|
|
315
41
|
export async function execute(initService) {
|
|
316
|
-
|
|
42
|
+
const systemPrompt = readSystemPrompt();
|
|
43
|
+
|
|
44
|
+
await initService.createSystemPrompt(systemPrompt);
|
|
317
45
|
await initService.createSkills(SKILLS, (msg) => console.log(msg));
|
|
318
46
|
await initService.createGitHubWorkflow(GITHUB_WORKFLOW_CONTENT, (msg) => console.log(msg));
|
|
319
47
|
|
|
@@ -0,0 +1,52 @@
|
|
|
1
|
+
export default `[ROLE: SECURITY & QUALITY AUDITOR] [STRICT CONTRACT]
|
|
2
|
+
|
|
3
|
+
\`\`\`mermaid
|
|
4
|
+
%% @spec-version v1.3.0
|
|
5
|
+
stateDiagram-v2
|
|
6
|
+
[*] --> Evaluation: Quality Assessment
|
|
7
|
+
Evaluation --> MakeSpec: Co-located .spec.md
|
|
8
|
+
|
|
9
|
+
state MakeSpec {
|
|
10
|
+
[*] --> SpecExists: Check for existing .spec.md
|
|
11
|
+
SpecNotFound --> CreateSpec: Create new .spec.md
|
|
12
|
+
SpecExists --> Break: Audit only.
|
|
13
|
+
Break --> [*]
|
|
14
|
+
}
|
|
15
|
+
|
|
16
|
+
CreateSpec --> RenderTopology: Create new co-located .spec.md
|
|
17
|
+
|
|
18
|
+
state RenderTopology {
|
|
19
|
+
[*] --> CheckCode: Analyze current code structure and dependencies
|
|
20
|
+
CheckCode --> EvaluatedCodeIsClean: Map exact architecture as-is (v1.0.0 - stable)
|
|
21
|
+
CheckCode --> EvaluatedCodeIsChaotic: Draw BOTH current chaotic logic AND ideal target refactored graph (v1.0.0 - draft)
|
|
22
|
+
}
|
|
23
|
+
|
|
24
|
+
RenderTopology --> CheckDiagram: Use npx @mermaid-js/mermaid-cli to Validate Syntax
|
|
25
|
+
|
|
26
|
+
state CheckDiagram {
|
|
27
|
+
[*] --> DiagramValid: Proceed to next step
|
|
28
|
+
DiagramInvalid --> RenderTopology: Re-render until valid
|
|
29
|
+
}
|
|
30
|
+
|
|
31
|
+
CheckDiagram --> WriteToAuditTag: Inject payloads inside <details> block
|
|
32
|
+
WriteToAuditTag --> EnforceImmutability: Lock Production Code File
|
|
33
|
+
EnforceImmutability --> [*]
|
|
34
|
+
\`\`\`
|
|
35
|
+
|
|
36
|
+
\`\`\`mermaid
|
|
37
|
+
%% @spec-version v1.3.0
|
|
38
|
+
%% Decision Matrix for EvaluatedCodeIsClean vs EvaluatedCodeIsChaotic
|
|
39
|
+
flowchart TD
|
|
40
|
+
M[Measure Cyclomatic Complexity] --> A{Aggregate Results}
|
|
41
|
+
C[Measure Module Coupling] --> A
|
|
42
|
+
H[Measure Module Cohesion LCOM] --> A
|
|
43
|
+
V[Count Lint/Code Violations] --> A
|
|
44
|
+
|
|
45
|
+
A -->|Complexity < 10 AND Coupling < 3 AND Cohesion > 0.9 AND Violations == 0| Clean[EvaluatedCodeIsClean]
|
|
46
|
+
A -->|Complexity >= 10 OR Coupling >= 3 OR Cohesion <= 0.9 OR Violations > 0| Chaotic[EvaluatedCodeIsChaotic]
|
|
47
|
+
|
|
48
|
+
style Clean fill:#1b5e20,color:#fff
|
|
49
|
+
style Chaotic fill:#b71c1c,color:#fff
|
|
50
|
+
\`\`\`
|
|
51
|
+
|
|
52
|
+
`;
|
|
@@ -0,0 +1,73 @@
|
|
|
1
|
+
export default `[ROLE: ARCHITECT] [STRICT CONTRACT]
|
|
2
|
+
|
|
3
|
+
\`\`\`mermaid
|
|
4
|
+
%% @spec-version v1.3.0
|
|
5
|
+
stateDiagram-v2
|
|
6
|
+
[*] --> Read TargetSpec: Read Target .spec.md
|
|
7
|
+
Read TargetSpec --> ParseVersion: Parse Current SPEC_VERSION
|
|
8
|
+
ParseVersion --> ApplyAdjustments: Apply requested Mermaid/Matrix Adjustments
|
|
9
|
+
ApplyAdjustments --> EvaluateScope: Evaluate Mutation Scope
|
|
10
|
+
|
|
11
|
+
state EvaluateScope {
|
|
12
|
+
[*] --> TypoFix: Typo / Label Fix
|
|
13
|
+
[*] --> NewNode: New Node / Flow Path / Factor
|
|
14
|
+
[*] --> BreakingChange: Breaking Overhaul / Restructure
|
|
15
|
+
}
|
|
16
|
+
|
|
17
|
+
EvaluateScope --> IncrementVersion: Increment Version Based on Scope
|
|
18
|
+
|
|
19
|
+
state IncrementVersion {
|
|
20
|
+
[*] --> IncrementPatch: Increment Patch: Bump Z in X.Y.Z
|
|
21
|
+
[*] --> IncrementMinor: Increment Minor: Bump Y in X.Y.Z
|
|
22
|
+
[*] --> IncrementMajor: Increment Major: Bump X in X.Y.Z
|
|
23
|
+
}
|
|
24
|
+
|
|
25
|
+
IncrementVersion --> CheckDiagram: Use npx @mermaid-js/mermaid-cli to Validate Syntax
|
|
26
|
+
|
|
27
|
+
state CheckDiagram {
|
|
28
|
+
[*] --> TryRender
|
|
29
|
+
TryRender --> DiagramValid: Render succeeded
|
|
30
|
+
TryRender --> IncrementRetry: Render failed
|
|
31
|
+
IncrementRetry --> TryRender: Retry count < 3
|
|
32
|
+
IncrementRetry --> RenderFailed: Retry count >= 3
|
|
33
|
+
}
|
|
34
|
+
|
|
35
|
+
CheckDiagram --> WriteToFile: Write validated .spec.md to target path
|
|
36
|
+
WriteToFile --> VerifyWrite
|
|
37
|
+
state VerifyWrite {
|
|
38
|
+
[*] --> WriteSuccess: File written successfully
|
|
39
|
+
[*] --> WriteError: File write failed (permissions / disk / path)
|
|
40
|
+
}
|
|
41
|
+
WriteError --> AwaitHumanReview: Error: manual intervention required
|
|
42
|
+
|
|
43
|
+
WriteSuccess --> AwaitHumanReview
|
|
44
|
+
RenderFailed --> AwaitHumanReview: Error: Mermaid CLI validation failed after 3 attempts
|
|
45
|
+
|
|
46
|
+
state AwaitHumanReview {
|
|
47
|
+
[*] --> Approved: Resume CI/CD pipeline
|
|
48
|
+
[*] --> ChangesRequested: Loop back to ApplyAdjustments
|
|
49
|
+
[*] --> Aborted: Terminate session
|
|
50
|
+
}
|
|
51
|
+
|
|
52
|
+
AwaitHumanReview --> [*]: Pause Code & Test Generation
|
|
53
|
+
\`\`\`
|
|
54
|
+
|
|
55
|
+
\`\`\`mermaid
|
|
56
|
+
%% @spec-version v1.3.0
|
|
57
|
+
%% Decision Matrix for EvaluateScope: TypoFix vs NewNode vs BreakingChange
|
|
58
|
+
flowchart TD
|
|
59
|
+
M[Mutation Request Contains...] --> A{Evaluate Factors}
|
|
60
|
+
|
|
61
|
+
T[Only label / text changes] --> A
|
|
62
|
+
N[New states / flows / factors added] --> A
|
|
63
|
+
B[Existing states / flows removed or restructured] --> A
|
|
64
|
+
|
|
65
|
+
A -->|"T == true AND N == false AND B == false"| Patch[TypoFix → IncrementPatch]
|
|
66
|
+
A -->|"N == true AND B == false"| Minor[NewNode → IncrementMinor]
|
|
67
|
+
A -->|"B == true"| Major[BreakingChange → IncrementMajor]
|
|
68
|
+
|
|
69
|
+
style Patch fill:#1b5e20,color:#fff
|
|
70
|
+
style Minor fill:#0d47a1,color:#fff
|
|
71
|
+
style Major fill:#b71c1c,color:#fff
|
|
72
|
+
\`\`\`
|
|
73
|
+
`;
|
|
@@ -0,0 +1,87 @@
|
|
|
1
|
+
export default `[ROLE: SOFTWARE ENGINEER] [STRICT CONTRACT]
|
|
2
|
+
|
|
3
|
+
\`\`\`mermaid
|
|
4
|
+
%% @spec-version v1.3.1
|
|
5
|
+
stateDiagram-v2
|
|
6
|
+
state ImplWorkflow {
|
|
7
|
+
[*] --> IngestSpec: [Inherits Parent Context] Ingest Signed .spec.md
|
|
8
|
+
IngestSpec --> ParseVersion: Parse Matrix Rows & Version Header
|
|
9
|
+
ParseVersion --> VerifyRequest: Verify Code/Chat Request Against Decision Matrix
|
|
10
|
+
VerifyRequest -->|Matches 100%| CheckTarget: Check File Target State
|
|
11
|
+
VerifyRequest -->|Human Asks to Skip/Add Extraneous Scope| TriggerDefense: Trigger Prompt Injection Defense
|
|
12
|
+
|
|
13
|
+
CheckTarget -->|New File| GenerateCode: Generate Full Structural Code from Scratch
|
|
14
|
+
CheckTarget -->|Existing File| IdempotentOverwrite: Idempotent Overwrite - Read & Output Full File
|
|
15
|
+
|
|
16
|
+
GenerateCode --> GenerateTests: Generate Truth-Table Unit Tests
|
|
17
|
+
IdempotentOverwrite --> DataLossCheck: Check for Data Loss Risk
|
|
18
|
+
DataLossCheck -->|No Risk| GenerateTests
|
|
19
|
+
DataLossCheck -->|Risk Detected| AlertUser: Alert User & Pause Generation
|
|
20
|
+
|
|
21
|
+
GenerateTests --> RunTests: Run Generated Tests
|
|
22
|
+
RunTests -->|All Pass| PromoteSpec: Promote .spec.md from draft to stable
|
|
23
|
+
RunTests -->|Any Fail| FixCode: Fix Code/Tests & Retry
|
|
24
|
+
|
|
25
|
+
PromoteSpec --> UpdateVersion: Update SPEC_VERSION to vSameVersion - stable
|
|
26
|
+
UpdateVersion --> AppendHistory: Append Audit History: impl complete
|
|
27
|
+
AppendHistory --> PersistSpec: Persist Updated .spec.md to Disk
|
|
28
|
+
PersistSpec --> AwaitHumanReview: Pause for User Approval Before Lock
|
|
29
|
+
}
|
|
30
|
+
|
|
31
|
+
state AwaitHumanReview {
|
|
32
|
+
[*] --> LockApproved: User approves immutability lock
|
|
33
|
+
[*] --> ChangesRequested: User requests changes → loop back to GenerateCode/IdempotentOverwrite
|
|
34
|
+
[*] --> Aborted: Terminate session without lock
|
|
35
|
+
}
|
|
36
|
+
|
|
37
|
+
LockApproved --> LockCodeImmutability: Lock Code Immutability for Stable Version
|
|
38
|
+
|
|
39
|
+
state LockCodeImmutability {
|
|
40
|
+
[*] --> SetGitHook: Install pre-commit hook blocking edits to stable files
|
|
41
|
+
SetGitHook --> SetSpecFlag: Set .spec.md immutable flag (SPEC_IMMUTABLE: true)
|
|
42
|
+
SetGitHook --> SetFilePermissions: chmod 444 on production code files
|
|
43
|
+
SetFilePermissions --> VerifyLock: Verify git diff shows no modifications
|
|
44
|
+
VerifyLock --> LockComplete: Lock verified & confirmed
|
|
45
|
+
LockComplete --> [*]
|
|
46
|
+
}
|
|
47
|
+
|
|
48
|
+
LockCodeImmutability --> [*]
|
|
49
|
+
|
|
50
|
+
TriggerDefense --> RefuseCoding: Refuse Coding & Demand Spec Refinement via md-edit
|
|
51
|
+
RefuseCoding --> [*]
|
|
52
|
+
\`\`\`
|
|
53
|
+
|
|
54
|
+
\`\`\`mermaid
|
|
55
|
+
%% @spec-version v1.3.1
|
|
56
|
+
%% Decision Matrix for CheckTarget: NewFile vs ExistingFile
|
|
57
|
+
flowchart TD
|
|
58
|
+
R[Check Target Path...] --> A{Evaluate Factors}
|
|
59
|
+
|
|
60
|
+
P[Path does not exist on disk] --> A
|
|
61
|
+
E[Path exists on disk] --> A
|
|
62
|
+
|
|
63
|
+
A -->|"P == true"| NewFile[CheckTarget → NewFile]
|
|
64
|
+
A -->|"E == true"| ExistingFile[CheckTarget → ExistingFile]
|
|
65
|
+
|
|
66
|
+
style NewFile fill:#0d47a1,color:#fff
|
|
67
|
+
style ExistingFile fill:#e65100,color:#fff
|
|
68
|
+
\`\`\`
|
|
69
|
+
|
|
70
|
+
\`\`\`mermaid
|
|
71
|
+
%% @spec-version v1.3.1
|
|
72
|
+
%% Decision Matrix for DataLossCheck: No Risk vs Risk Detected
|
|
73
|
+
flowchart TD
|
|
74
|
+
M[Evaluate Data Loss Risk Factors...] --> A{Aggregate Risk Conditions}
|
|
75
|
+
|
|
76
|
+
FF[File exists on disk AND will be overwritten] --> A
|
|
77
|
+
C[Code changes detected outside spec scope] --> A
|
|
78
|
+
B[No recent git backup / uncommitted changes] --> A
|
|
79
|
+
V[User confirmation flag not set] --> A
|
|
80
|
+
|
|
81
|
+
A -->|"FF == true OR C == true OR B == true OR V == true"| Risk[Risk Detected → Alert User]
|
|
82
|
+
A -->|"FF == false AND C == false AND B == false AND V == false"| NoRisk[No Risk → Proceed to GenerateTests]
|
|
83
|
+
|
|
84
|
+
style NoRisk fill:#1b5e20,color:#fff
|
|
85
|
+
style Risk fill:#b71c1c,color:#fff
|
|
86
|
+
\`\`\`
|
|
87
|
+
`;
|
|
@@ -0,0 +1,45 @@
|
|
|
1
|
+
export default `[ROLE: ARCHITECT] [STRICT CONTRACT]
|
|
2
|
+
|
|
3
|
+
\`\`\`mermaid
|
|
4
|
+
%% @spec-version v1.3.0
|
|
5
|
+
stateDiagram-v2
|
|
6
|
+
[*] --> TargetVerification
|
|
7
|
+
|
|
8
|
+
state TargetVerification {
|
|
9
|
+
[*] --> CheckFileExistence: Does .spec.md already exist at target path?
|
|
10
|
+
FileExists --> Break: Existing .specs are immutable. Switch to edit mode.
|
|
11
|
+
FileNotFound --> EvaluateContext: File Does Not Exist
|
|
12
|
+
}
|
|
13
|
+
|
|
14
|
+
state EvaluateContext {
|
|
15
|
+
[*] --> DeepAnalysis: Evaluate target context and goal
|
|
16
|
+
DeepAnalysis --> DiagramTypeInference: Infer appropriate diagram type and template
|
|
17
|
+
DiagramTypeInference --> InferNodes: Identify key nodes and relationships to be represented
|
|
18
|
+
}
|
|
19
|
+
|
|
20
|
+
EvaluateContext --> GenerateBlueprint: Create .spec.md Blueprint with placeholders
|
|
21
|
+
GenerateBlueprint --> FormatSpecOutput: Format blueprint into target .spec.md structure
|
|
22
|
+
FormatSpecOutput --> CheckDiagram: Use npx @mermaid-js/mermaid-cli to Validate Syntax
|
|
23
|
+
|
|
24
|
+
state CheckDiagram {
|
|
25
|
+
[*] --> DiagramValid: Proceed to next step
|
|
26
|
+
DiagramInvalid --> GenerateBlueprint: Re-generate blueprint with adjustments until valid
|
|
27
|
+
}
|
|
28
|
+
|
|
29
|
+
CheckDiagram --> WriteToFile: Write validated .spec.md to target path
|
|
30
|
+
WriteToFile --> InitializeVersion: Set initial SPEC_VERSION
|
|
31
|
+
|
|
32
|
+
state InitializeVersion {
|
|
33
|
+
[*] --> SetDraftVersion: Set SPEC_VERSION to v1.0.0-draft
|
|
34
|
+
}
|
|
35
|
+
|
|
36
|
+
InitializeVersion --> AppendCreationAudit: Record creation metadata
|
|
37
|
+
|
|
38
|
+
state AppendCreationAudit {
|
|
39
|
+
[*] --> LogCreation: Append audit entry: "Created via md-new" with timestamp
|
|
40
|
+
}
|
|
41
|
+
|
|
42
|
+
AppendCreationAudit --> AwaitHumanReview: Pause for user to review and adjust generated diagram
|
|
43
|
+
AwaitHumanReview --> [*]: Pause Code & Test Generation
|
|
44
|
+
\`\`\`
|
|
45
|
+
`;
|
|
@@ -0,0 +1,61 @@
|
|
|
1
|
+
/**
|
|
2
|
+
* GitHub Actions workflow YAML for automated full specification and native Mermaid preview on PRs.
|
|
3
|
+
* Extracted from init.js v1.5.0 domain extraction.
|
|
4
|
+
*/
|
|
5
|
+
export const GITHUB_WORKFLOW_CONTENT = [
|
|
6
|
+
"name: 🗺️ MDDD Full Spec Preview",
|
|
7
|
+
"",
|
|
8
|
+
"on:",
|
|
9
|
+
" pull_request:",
|
|
10
|
+
" paths:",
|
|
11
|
+
" - '**/*.spec.md'",
|
|
12
|
+
"",
|
|
13
|
+
"jobs:",
|
|
14
|
+
" render-preview:",
|
|
15
|
+
" runs-on: ubuntu-latest",
|
|
16
|
+
" permissions:",
|
|
17
|
+
" pull-requests: write",
|
|
18
|
+
" contents: read",
|
|
19
|
+
"",
|
|
20
|
+
" steps:",
|
|
21
|
+
" - name: ⬇️ Checkout Repository",
|
|
22
|
+
" uses: actions/checkout@v4",
|
|
23
|
+
" with:",
|
|
24
|
+
" fetch-depth: 0", // CRUCIAL: Traz o histórico completo para o git diff funcionar
|
|
25
|
+
"",
|
|
26
|
+
" - name: 📸 Build Preview Comment",
|
|
27
|
+
" id: build-comment",
|
|
28
|
+
' run: |',
|
|
29
|
+
' echo "comment<<EOF" >> "$GITHUB_OUTPUT"',
|
|
30
|
+
' echo "### 🗺️ MDDD - Design Changes Detected!" >> "$GITHUB_OUTPUT"',
|
|
31
|
+
' echo "Review the proposed specification and visual topology below before approving." >> "$GITHUB_OUTPUT"',
|
|
32
|
+
' echo "" >> "$GITHUB_OUTPUT"',
|
|
33
|
+
"",
|
|
34
|
+
' # Busca os arquivos modificados comparando dinamicamente com a branch destino do PR',
|
|
35
|
+
' CHANGED=$(git diff --name-only "origin/${{ github.base_ref }}...HEAD" -- "*.spec.md" 2>/dev/null || echo "")',
|
|
36
|
+
"",
|
|
37
|
+
" for file in $CHANGED; do",
|
|
38
|
+
' [ -f "$file" ] || continue',
|
|
39
|
+
' echo "" >> "$GITHUB_OUTPUT"',
|
|
40
|
+
' echo "#### 📄 File: \`${file}\`" >> "$GITHUB_OUTPUT"',
|
|
41
|
+
' echo "" >> "$GITHUB_OUTPUT"',
|
|
42
|
+
' echo "<details open>" >> "$GITHUB_OUTPUT"',
|
|
43
|
+
' echo "<summary>Click to collapse full specification preview</summary>" >> "$GITHUB_OUTPUT"',
|
|
44
|
+
' echo "" >> "$GITHUB_OUTPUT"',
|
|
45
|
+
"",
|
|
46
|
+
' # Injeta o conteúdo completo do arquivo markdown',
|
|
47
|
+
' cat "$file" >> "$GITHUB_OUTPUT"',
|
|
48
|
+
' echo "" >> "$GITHUB_OUTPUT"',
|
|
49
|
+
"",
|
|
50
|
+
' echo "</details>" >> "$GITHUB_OUTPUT"',
|
|
51
|
+
' echo "" >> "$GITHUB_OUTPUT"',
|
|
52
|
+
" done",
|
|
53
|
+
"",
|
|
54
|
+
' echo "EOF" >> "$GITHUB_OUTPUT"',
|
|
55
|
+
"",
|
|
56
|
+
" - name: 💬 Comment Preview on PR",
|
|
57
|
+
" uses: thollander/actions-comment-pull-request@v2",
|
|
58
|
+
" with:",
|
|
59
|
+
' message: "${{ steps.build-comment.outputs.comment }}"',
|
|
60
|
+
" comment_tag: 'mddd-design-preview'",
|
|
61
|
+
].join('\n');
|
|
@@ -1,265 +0,0 @@
|
|
|
1
|
-
# init.js — Command Specification
|
|
2
|
-
|
|
3
|
-
**SPEC_VERSION: v1.4.0 — stable**
|
|
4
|
-
|
|
5
|
-
## Overview
|
|
6
|
-
|
|
7
|
-
The `init.js` module implements the `md init` CLI command. It holds the canonical MDDD universal system prompt and the full skill library (`md-new`, `md-edit`, `md-audit`, `md-impl`), delegating file-system persistence to an injected `InitService`.
|
|
8
|
-
|
|
9
|
-
---
|
|
10
|
-
|
|
11
|
-
## Behavioral Flow (Reverse Engineered)
|
|
12
|
-
|
|
13
|
-
```mermaid
|
|
14
|
-
%% @spec-version v1.3.0
|
|
15
|
-
stateDiagram-v2
|
|
16
|
-
[*] --> ExecuteCommand: User runs "md init"
|
|
17
|
-
ExecuteCommand --> CreateSystemPrompt: initService.createSystemPrompt(content)
|
|
18
|
-
CreateSystemPrompt --> CreateSkills: initService.createSkills(skillMap, logger)
|
|
19
|
-
CreateSkills --> CreateGitHubWorkflow: initService.createGitHubWorkflow(workflowYaml)
|
|
20
|
-
CreateGitHubWorkflow --> ReportSuccess: console.log(…) green messages
|
|
21
|
-
ReportSuccess --> [*]
|
|
22
|
-
```
|
|
23
|
-
|
|
24
|
-
---
|
|
25
|
-
|
|
26
|
-
## GitHub Actions Preview Workflow
|
|
27
|
-
|
|
28
|
-
A partir da v1.3.0, o `md init` também cria/atualiza um workflow do GitHub Actions em `.github/workflows/mddd-preview.yml`. Esse workflow gera previews visuais dos diagramas Mermaid alterados em pull requests que tocam arquivos `.spec.md`.
|
|
29
|
-
|
|
30
|
-
> **Idempotência garantida:** Se o arquivo `.github/workflows/mddd-preview.yml` já existir, ele será sobrescrito com o conteúdo canônico atual. Isso garante que todos os projetos inicializados com `md init` tenham a versão mais recente do workflow de preview.
|
|
31
|
-
|
|
32
|
-
```yaml
|
|
33
|
-
name: 🗺️ MDDD Diagram Preview
|
|
34
|
-
|
|
35
|
-
on:
|
|
36
|
-
pull_request:
|
|
37
|
-
paths:
|
|
38
|
-
- '**/*.spec.md'
|
|
39
|
-
|
|
40
|
-
jobs:
|
|
41
|
-
render-preview:
|
|
42
|
-
runs-on: ubuntu-latest
|
|
43
|
-
permissions:
|
|
44
|
-
pull-requests: write
|
|
45
|
-
contents: read
|
|
46
|
-
|
|
47
|
-
steps:
|
|
48
|
-
- name: ⬇️ Checkout Repository
|
|
49
|
-
uses: actions/checkout@v4
|
|
50
|
-
with:
|
|
51
|
-
fetch-depth: 0
|
|
52
|
-
|
|
53
|
-
- name: 📦 Setup Node.js
|
|
54
|
-
uses: actions/setup-node@v4
|
|
55
|
-
with:
|
|
56
|
-
node-version: 20
|
|
57
|
-
|
|
58
|
-
- name: 📸 Render Mermaid Diagrams to PNG
|
|
59
|
-
run: |
|
|
60
|
-
mkdir -p .github/mddd-previews
|
|
61
|
-
npm install --no-save @mermaid-js/mermaid-cli puppeteer 2>&1 | tail -2
|
|
62
|
-
|
|
63
|
-
# Find changed .spec.md files in this PR
|
|
64
|
-
CHANGED=$(git diff --name-only "origin/${{ github.base_ref }}...${{ github.sha }}" -- '*.spec.md' 2>/dev/null || echo "")
|
|
65
|
-
|
|
66
|
-
for file in $CHANGED; do
|
|
67
|
-
[ -f "$file" ] || continue
|
|
68
|
-
echo "📄 Processing: $file"
|
|
69
|
-
|
|
70
|
-
# Extract each ```mermaid block to a .mmd temp file using node inline
|
|
71
|
-
# Note: single-quote heredoc prevents shell expansion of $ and backticks
|
|
72
|
-
node -e '
|
|
73
|
-
const fs=require("fs"),p=require("path");
|
|
74
|
-
const c=fs.readFileSync(process.argv[1],"utf8");
|
|
75
|
-
const v=c.match(/SPEC_VERSION: v?([\d.]+)/)?.[1]||"0";
|
|
76
|
-
const r=/```mermaid\n?([\s\S]*?)```/g;
|
|
77
|
-
let m,i=0;
|
|
78
|
-
while((m=r.exec(c))!==null){
|
|
79
|
-
let d=m[1].replace(/^%%.*$/gm,"").trim();
|
|
80
|
-
if(!d)continue;
|
|
81
|
-
const n=p.basename(process.argv[1],".spec.md")+"-"+i+".mmd";
|
|
82
|
-
fs.writeFileSync("/tmp/"+n,"%% @spec-version v"+v+"\n"+d);
|
|
83
|
-
console.log(" Extracted diagram "+(i+1)+" -> "+n);
|
|
84
|
-
i++;
|
|
85
|
-
}
|
|
86
|
-
' "$file"
|
|
87
|
-
done
|
|
88
|
-
|
|
89
|
-
for mmd in /tmp/*.mmd; do
|
|
90
|
-
[ -f "$mmd" ] || continue
|
|
91
|
-
base=$(basename "$mmd" .mmd)
|
|
92
|
-
echo "🎨 Rendering $base..."
|
|
93
|
-
npx -p @mermaid-js/mermaid-cli mmdc -i "$mmd" -o ".github/mddd-previews/$base.png" -b white -w 1200 2>&1 | tail -1 || echo " ⚠️ Render failed for $base"
|
|
94
|
-
done
|
|
95
|
-
|
|
96
|
-
- name: 💬 Comment Preview on PR
|
|
97
|
-
uses: thollander/actions-comment-pull-request@v2
|
|
98
|
-
with:
|
|
99
|
-
message: |
|
|
100
|
-
### 🗺️ MDDD - Alterações de Design Detectadas!
|
|
101
|
-
Revise a topologia visual proposta abaixo antes de aprovar o código.
|
|
102
|
-
|
|
103
|
-
> Os diagramas renderizados estão disponíveis como artefatos da workflow run (seção \"Summary\").
|
|
104
|
-
comment_tag: 'mddd-design-preview'
|
|
105
|
-
```
|
|
106
|
-
|
|
107
|
-
---
|
|
108
|
-
|
|
109
|
-
## Embedded Skill Inventory
|
|
110
|
-
|
|
111
|
-
The `SKILLS` map in `init.js` contains four behavioral sub-specifications. The table below tracks their individual versions and key contract guarantees:
|
|
112
|
-
|
|
113
|
-
| Skill | Role | Current Version | Key Contract Update |
|
|
114
|
-
| :--- | :--- | :---: | :--- |
|
|
115
|
-
| `md-new` | Architect | v1.1.0 | Domain depth inference + parent binding |
|
|
116
|
-
| `md-edit` | Architect | **v1.2.0** | **Draft vs Stable tagging + Spec file write mandate** |
|
|
117
|
-
| `md-audit` | Security & Quality Auditor | **v1.2.0** | **Spec Creation Guarantee** — .spec.md MUST exist at end of cycle |
|
|
118
|
-
| `md-impl` | Software Engineer | **v1.2.0** | **Draft-to-Stable promotion + Spec lock after implementation** |
|
|
119
|
-
|
|
120
|
-
> **md-edit v1.2.0 highlights:**
|
|
121
|
-
> - New `Write .spec.md to Disk with Updated Version` node in topology — edit cycle persists the file
|
|
122
|
-
> - New `Spec Status Assessment` branch: structural changes (major/minor) tagged as **draft** (proposal), typographical fixes tagged as **stable** (locked)
|
|
123
|
-
> - New column `Spec Status After Edit` in Evolution Versioning Matrix
|
|
124
|
-
> - New Ironclad Rule #5 (Draft vs Stable Status Tagging): explicit `draft` or `stable` suffix after SPEC_VERSION
|
|
125
|
-
> - New Ironclad Rule #6 (Spec File Write Mandate): edit cycle only complete after file persisted
|
|
126
|
-
|
|
127
|
-
> **md-audit v1.2.0 highlights:**
|
|
128
|
-
> - New `SpecFileGuaranteed` terminal state in topology: validates that a co-located `.spec.md` exists and is populated before the flow reaches `[*]`
|
|
129
|
-
> - New column `.spec.md Creation Guarantee` in the Reverse Engineering Decision Matrix — all four scenario rows marked `✅ GUARANTEED`
|
|
130
|
-
> - New Ironclad Rule #4 (Spec Creation Guarantee): the agent **must** ensure a valid `.spec.md` file exists after every audit cycle
|
|
131
|
-
> - Final imperative rule: `UNDER NO CIRCUMSTANCES MAY YOU COMPLETE AN md-audit CYCLE WITHOUT A CO-LOCATED .spec.md FILE`
|
|
132
|
-
|
|
133
|
-
> **md-impl v1.2.0 highlights:**
|
|
134
|
-
> - New test verification gate (`Tests Pass 100%?`) before completion — implementation must pass before promotion
|
|
135
|
-
> - New `Promote .spec.md from draft to stable` state after successful tests
|
|
136
|
-
> - New `Persist Updated .spec.md to Disk` step — the impl cycle writes the promoted spec
|
|
137
|
-
> - New Ironclad Rule #4 (Draft-to-Stable Promotion Duty): after tests pass, promote spec to `stable`
|
|
138
|
-
|
|
139
|
-
---
|
|
140
|
-
|
|
141
|
-
## System Prompt Guardrails (Section 4)
|
|
142
|
-
|
|
143
|
-
The `SYSTEM_PROMPT_CONTENT` embedded in `init.js` defines five Anti-Hallucination Guardrails that govern all agent behavior under MDDD:
|
|
144
|
-
|
|
145
|
-
| # | Guardrail | Purpose |
|
|
146
|
-
| :---: | :--- | :--- |
|
|
147
|
-
| 1 | **No Spec, No Code** | No production code without a `.spec.md` with populated Decision Matrix |
|
|
148
|
-
| 2 | **Implicit Logic Ban** | Business conditions must be explicit in the Matrix |
|
|
149
|
-
| 3 | **Strict State Isolation** | No cross-domain state mutation without macro mapping |
|
|
150
|
-
| 4 | **Idempotent Full-File Output Mandate** | No placeholders, truncations, or partial snippets |
|
|
151
|
-
| 5 | **Spec-First Ordering Mandate** | `.spec.md` MUST be created/updated **before** any production code file — code is derived from spec |
|
|
152
|
-
|
|
153
|
-
> **Guardrail #5 (v1.2.0):** This guardrail was added to prevent the exact protocol violation that occurred when `init.js` was edited before its `.spec.md`. It explicitly requires that the `.spec.md` file be written or updated first, making the spec the source of truth and code a derived artifact. Violation constitutes a direct MDDD protocol breach.
|
|
154
|
-
|
|
155
|
-
---
|
|
156
|
-
|
|
157
|
-
## Mermaid Diagram Validation Rules
|
|
158
|
-
|
|
159
|
-
### 5.1 Forbidden Characters Per Diagram Type
|
|
160
|
-
|
|
161
|
-
| Diagram Type | Context | Forbidden Characters | Reason |
|
|
162
|
-
| :--- | :--- | :--- | :--- |
|
|
163
|
-
| `stateDiagram-v2` | State/Transition Labels | `:` (colon) | Breaks transition arrow syntax (`-->`). Use `-` or words instead. |
|
|
164
|
-
| `stateDiagram-v2` | State Names | `[]` `()` `{}` `<>` | Reserved delimiters for notes, composities, and forks. Wrap in quotes if unavoidable. |
|
|
165
|
-
| `stateDiagram-v2` | Any Label | `"` `'` (unescaped quotes) | Breaks string parsing inside directives like `%%` comments and labels. |
|
|
166
|
-
| `graph TD/LR/BT/RL` | Node IDs | `()` `[]` `{}` `<>` | Reserved bracket syntax for node shapes. Causes parse failure or shape corruption. |
|
|
167
|
-
| `graph TD/LR/BT/RL` | Node Text Labels | `"` (double quote) | Terminates the label string early if the label itself is quoted. Use single-character alternatives. |
|
|
168
|
-
| `graph TD/LR/BT/RL` | Edge Labels | `\|` (pipe) | `\|` terminates the edge label in `--\|label\|-->` syntax. |
|
|
169
|
-
| `graph TD/LR/BT/RL` | Any Text | `,` `;` | Acts as statement separator in Mermaid parser. Unexpected splits. |
|
|
170
|
-
| `graph TD/LR/BT/RL` | Any Text | `` ` `` (backtick) | Reserved for Markdown code span parsing in newer Mermaid versions. |
|
|
171
|
-
| All Diagram Types | `%%` comment blocks | `{` `}` inside inline comments | Can be misinterpreted as Mermaid directive blocks. |
|
|
172
|
-
| All Diagram Types | Raw Unicode Control Chars | `\u0000`-`\u001F` (except `\n`, `\t`) | Invisible control characters corrupt the SVG renderer output. |
|
|
173
|
-
|
|
174
|
-
### 5.2 Safe Alternatives Table
|
|
175
|
-
|
|
176
|
-
| Instead of… | Use… | Example |
|
|
177
|
-
| :--- | :--- | :--- |
|
|
178
|
-
| `:` in state name | `-` or whitespace | `ProcessingComplete` ✅ instead of `Processing:Complete` ❌ |
|
|
179
|
-
| `()` in node label | Wrap entire label in `["..."]` | `A["Process Data (v2)"]` ✅ |
|
|
180
|
-
| `"` inside a label | Remove quotes or use `#quot;` HTML entity | `A["Status is #quot;OK#quot;"]` ✅ |
|
|
181
|
-
| `,` in text | Replace with ` - ` or `&` | `Validate & Transform` ✅ instead of `Validate, Transform` ❌ |
|
|
182
|
-
| Complex special chars | Enclose node text in double-quote brackets `["..."]` | `B["Node with (special) chars & stuff"]` ✅ |
|
|
183
|
-
|
|
184
|
-
### 5.3 Post-Creation Review Checklist
|
|
185
|
-
|
|
186
|
-
After writing **every** `.spec.md` file containing a Mermaid diagram block, you **MUST** perform this review:
|
|
187
|
-
|
|
188
|
-
1. ✅ **Bracket Balance Check**: Count every `[` `]` `(` `)` `{` `}` — each opening must have a matching closing bracket.
|
|
189
|
-
2. ✅ **Colon-Free State Names**: Verify no `:` exists inside state names (exception: `%%` directives and `[*]` pseudo-states).
|
|
190
|
-
3. ✅ **Edge Label Pipes**: Confirm every `|` in edge label syntax is properly paired (`--|label|-->`).
|
|
191
|
-
4. ✅ **Quote Consistency**: Ensure quote marks are balanced and not breaking string boundaries.
|
|
192
|
-
5. ✅ **No Trailing Backslashes**: Check no line ends with `\` unless it is an intentional line continuation.
|
|
193
|
-
6. ✅ **Render Test Mental Simulation**: Trace the diagram visually in your mind — do the arrows point to real nodes? Are all states reachable? No floating edges?
|
|
194
|
-
|
|
195
|
-
If any of the above checks fail, **correct the diagram before proceeding** to code generation.
|
|
196
|
-
|
|
197
|
-
### 5.4 Forbidden Pattern Examples
|
|
198
|
-
|
|
199
|
-
```mermaid
|
|
200
|
-
%% ❌ BAD: Colon in state name breaks transition
|
|
201
|
-
stateDiagram-v2
|
|
202
|
-
Processing:Data --> Complete ← BROKEN: colon interpreted as state:description syntax
|
|
203
|
-
|
|
204
|
-
%% ✅ GOOD: No colon, clear naming
|
|
205
|
-
stateDiagram-v2
|
|
206
|
-
ProcessingData --> Complete
|
|
207
|
-
```
|
|
208
|
-
|
|
209
|
-
```mermaid
|
|
210
|
-
%% ❌ BAD: Unescaped comma and parentheses in graph
|
|
211
|
-
graph TD
|
|
212
|
-
A[Validate, Transform (v2)] --> B ← BROKEN: comma splits, parens confuse parser
|
|
213
|
-
|
|
214
|
-
%% ✅ GOOD: Wrapped in double-quote brackets
|
|
215
|
-
graph TD
|
|
216
|
-
A["Validate, Transform (v2)"] --> B
|
|
217
|
-
```
|
|
218
|
-
|
|
219
|
-
### 5.5 Enforcement Rule
|
|
220
|
-
|
|
221
|
-
> **🛑 HALT**: If after review you detect any forbidden character in a Mermaid diagram block, refuse to proceed with code generation. Fix the diagram first. This rule supersedes all other productivity directives.
|
|
222
|
-
|
|
223
|
-
---
|
|
224
|
-
|
|
225
|
-
## Decision Matrix
|
|
226
|
-
|
|
227
|
-
| Step | Operation | I/O | Conditional Branch? | Error Handling |
|
|
228
|
-
| :--- | :--- | :--- | :---: | :--- |
|
|
229
|
-
| 1 | `initService.createSystemPrompt(SYSTEM_PROMPT_CONTENT)` | Writes `system_prompt.md` | ❌ No | Delegated to InitService |
|
|
230
|
-
| 2 | `initService.createSkills(SKILLS, logFn)` | Writes `SKILLS/*.md` files | ❌ No | Delegated to InitService |
|
|
231
|
-
| 3 | `initService.createGitHubWorkflow(GITHUB_WORKFLOW_CONTENT)` | Writes `.github/workflows/mddd-preview.yml` | ❌ No | Delegated to InitService |
|
|
232
|
-
| 4 | `console.log(pc.green(…))` | stdout — success report | ❌ No | N/A |
|
|
233
|
-
|
|
234
|
-
> **Note:** The `SKILLS` map contains four embedded behavioral sub-specifications (`md-new`, `md-edit`, `md-audit`, `md-impl`), each with its own internal topology and decision logic. Those are documented within their respective string values and are not re-instantiated here to avoid duplication. For details on the `md-audit` v1.2.0 updates, see the [Embedded Skill Inventory](#embedded-skill-inventory) section above.
|
|
235
|
-
|
|
236
|
-
---
|
|
237
|
-
|
|
238
|
-
## Exported Symbols
|
|
239
|
-
|
|
240
|
-
| Export | Type | Purpose |
|
|
241
|
-
| :--- | :--- | :--- |
|
|
242
|
-
| `SYSTEM_PROMPT_CONTENT` | `string` | Full MDDD protocol prompt text (now includes Guardrail #5: Spec-First Ordering Mandate) |
|
|
243
|
-
| `SKILLS` | `Record<string, string>` | Skill-name → SKILL.md content mapping |
|
|
244
|
-
| `GITHUB_WORKFLOW_CONTENT` | `string` | GitHub Actions workflow YAML for Mermaid diagram preview on PRs |
|
|
245
|
-
| `execute(initService)` | `async function` | Command entry point |
|
|
246
|
-
|
|
247
|
-
---
|
|
248
|
-
|
|
249
|
-
## Audit History
|
|
250
|
-
|
|
251
|
-
<details><summary>Click to expand</summary>
|
|
252
|
-
|
|
253
|
-
| Date | Agent | Version | Change Summary |
|
|
254
|
-
| :--- | :--- | :---: | :--- |
|
|
255
|
-
| 2026-05-28 | Cline (md-audit) | v1.0.0 | Initial reverse-engineered spec from production code. Code classified as **Clean / Modular**. No modifications to `init.js`. |
|
|
256
|
-
| 2026-05-28 | Cline (md-impl) | v1.0.1 | Idempotent full-file overwrite of `init.js`. No behavioral changes — same 3-step flow preserved. Unit tests created under `tests/commands/init.spec.js` with 6/6 passing. SPEC_VERSION bumped from v1.0.0 to v1.0.1 (patch). |
|
|
257
|
-
| 2026-05-28 | Cline (md-edit) | v1.1.0 | Updated `md-audit` skill embedded in `init.js` to v1.2.0: added `SpecFileGuaranteed` terminal state in topology diagram, added `.spec.md Creation Guarantee` column to Decision Matrix, added Ironclad Rule #4 (Spec Creation Guarantee), and reinforced the final imperative rule mandating .spec.md creation on every audit cycle. SPEC_VERSION bumped from v1.0.1 to v1.1.0 (minor — new contract enforcement). |
|
|
258
|
-
| 2026-05-28 | Cline (md-edit) | **v1.2.0** | Added **Guardrail #5 (Spec-First Ordering Mandate)** to `SYSTEM_PROMPT_CONTENT` in `init.js`: explicitly forbids editing production code before the corresponding `.spec.md` file has been created or updated. This prevents the protocol violation of editing `.js` files before `.spec.md` files. Updated `md-edit` skill to v1.2.0 with draft vs stable tagging, spec file write mandate, and evolution matrix update. Updated `md-impl` skill to v1.2.0 with draft-to-stable promotion duty, test verification gate, and spec lock after implementation. SPEC_VERSION bumped from v1.1.0 to v1.3.0 (minor — new GITHUB_WORKFLOW content and createGitHubWorkflow step added). |
|
|
259
|
-
| 2026-05-28 | Cline (md-edit) | **v1.4.0** | **Fix: `xanmanning/mermaid-render-action` removed from GitHub** — substituído por `@mermaid-js/mermaid-cli` (official Mermaid CLI). Workflow agora extrai blocos ```mermaid de arquivos `.spec.md` alterados no PR e renderiza com `mmdc`. Adicionado `actions/setup-node@v4` para Node.js 20. SPEC_VERSION bumped from v1.3.0 to v1.4.0 (minor — structural change to workflow YAML). Status set to **draft** pending implementation. |
|
|
260
|
-
|
|
261
|
-
> **v1.4.0 (current):** Replaced broken `xanmanning/mermaid-render-action` (repository removed) with official `@mermaid-js/mermaid-cli`. The workflow now: (1) detects changed `.spec.md` files in the PR, (2) extracts Mermaid code blocks using a Node.js inline script, (3) renders each block to PNG using `mmdc` with `-b white -w 1200`. Added `actions/setup-node@v4` step. Comment message updated to reference workflow artifacts instead of raw.githubusercontent.com URLs. SPEC_VERSION bumped from v1.3.0 to v1.4.0 (minor — structural breaking change to workflow topology). Status promoted from **draft** to **stable** — implementation and tests verified. |
|
|
262
|
-
|
|
263
|
-
> **v1.3.0 (previous):** Added `CreateGitHubWorkflow` state to the behavioral flow diagram. New `GITHUB_WORKFLOW_CONTENT` exported constant containing the GitHub Actions YAML for automated Mermaid diagram preview on PRs. New step 3 in Decision Matrix: `initService.createGitHubWorkflow(GITHUB_WORKFLOW_CONTENT)` writes `.github/workflows/mddd-preview.yml`. Status promoted from **draft** to **stable**. |
|
|
264
|
-
|
|
265
|
-
</details>
|