@dv.nghiem/flowdeck 0.3.1 → 0.3.3
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 +11 -7
- package/dist/hooks/patch-trust.d.ts.map +1 -1
- package/dist/index.d.ts.map +1 -1
- package/dist/index.js +201 -108
- package/dist/tools/memory-status.d.ts +3 -0
- package/dist/tools/memory-status.d.ts.map +1 -0
- package/docs/commands.md +102 -9
- package/docs/quick-start.md +44 -23
- package/docs/workflows.md +10 -8
- package/package.json +1 -1
- package/src/commands/fd-execute.md +192 -0
- package/src/commands/fd-new-feature.md +44 -157
- package/src/commands/fd-new-project.md +1 -2
- package/src/commands/fd-plan.md +1 -1
- package/src/commands/fd-suggest.md +84 -0
- package/src/commands/fd-verify.md +126 -0
- package/src/rules/common/agent-orchestration.md +5 -5
- package/src/rules/common/coding-style.md +17 -0
package/docs/commands.md
CHANGED
|
@@ -7,18 +7,20 @@ Commands are slash commands registered in OpenCode. Run them by typing `/command
|
|
|
7
7
|
| Command | Arguments | Description |
|
|
8
8
|
|---------|-----------|-------------|
|
|
9
9
|
| `/fd-new-project` | `[project-name]` | Initialize project with planning structure and default config |
|
|
10
|
+
| `/fd-new-feature` | `[feature-description]` | Define a new feature and initialize feature context |
|
|
10
11
|
| `/fd-discuss` | `[topic]` | Structured Q&A to capture decisions for a phase |
|
|
11
12
|
| `/fd-plan` | `[--phase=N]` | Generate detailed implementation plan from decisions |
|
|
12
|
-
| `/fd-
|
|
13
|
+
| `/fd-execute` | `[--phase=N] [--override]` | Implement feature with TDD pipeline and parallel agents |
|
|
14
|
+
| `/fd-verify` | `[--phase=N] [--env=staging\|production]` | Verify feature completion: tests, review, security, deploy check |
|
|
13
15
|
| `/fd-fix-bug` | `[bug-description]` | Debug, fix, and verify bug with regression test |
|
|
14
16
|
| `/fd-deploy-check` | `[--check=deploy,review,analysis]` | Pre-deploy checks, code review, or pre-change analysis |
|
|
15
|
-
| `/fd-status` | `[--roadmap
|
|
17
|
+
| `/fd-status` | `[--roadmap \| --workspace \| --phase=N]` | Combined status, roadmap, and workspace view |
|
|
16
18
|
| `/fd-resume` | `[--yes]` | Reload STATE.md and PLAN.md to continue interrupted session |
|
|
17
19
|
| `/fd-checkpoint` | — | Persist current state to STATE.md |
|
|
18
20
|
| `/fd-reflect` | `[--mode=reflect,learn]` | Post-session reflection or capture skill from session |
|
|
19
21
|
| `/fd-map-codebase` | `[--incremental]` | Map codebase into structured `.codebase/` files |
|
|
20
22
|
| `/fd-write-docs` | `[--scope=path]` | Explore APIs and generate documentation |
|
|
21
|
-
| `/fd-multi-repo` | `[list
|
|
23
|
+
| `/fd-multi-repo` | `[list \| add <path> [name] \| remove <name> \| status]` | Multi-repo orchestration |
|
|
22
24
|
| `/fd-translate-intent` | `[vague intent]` | Convert vague request into ranked implementation options |
|
|
23
25
|
| `/fd-ask` | `[question]` | Route question to specialist agent (architect, security, etc.) |
|
|
24
26
|
| `/fd-quick` | `[task description]` | Quick focused task with automatic agent selection |
|
|
@@ -47,12 +49,38 @@ Commands are slash commands registered in OpenCode. Run them by typing `/command
|
|
|
47
49
|
```
|
|
48
50
|
|
|
49
51
|
**What Next?**
|
|
50
|
-
1. Run `/fd-
|
|
52
|
+
1. Run `/fd-new-feature` to define your first feature
|
|
51
53
|
2. Run `/fd-map-codebase` if this is an existing codebase
|
|
52
54
|
3. Edit `.planning/config.json` directly to change settings
|
|
53
55
|
|
|
54
56
|
---
|
|
55
57
|
|
|
58
|
+
## /fd-new-feature
|
|
59
|
+
|
|
60
|
+
**Description:** Define a new feature and initialize feature context. This is the first step of the feature workflow after project setup.
|
|
61
|
+
|
|
62
|
+
**Arguments:**
|
|
63
|
+
- `[feature-description]` — name or short description of the feature
|
|
64
|
+
|
|
65
|
+
**What it does:**
|
|
66
|
+
1. Reads `.planning/STATE.md` to determine current phase
|
|
67
|
+
2. Creates `.planning/phases/phase-N/FEATURE.md` with feature context
|
|
68
|
+
3. Updates STATE.md with feature definition
|
|
69
|
+
4. Displays the workflow steps ahead: discuss → plan → execute → verify
|
|
70
|
+
|
|
71
|
+
**Example:**
|
|
72
|
+
```
|
|
73
|
+
/fd-new-feature user authentication
|
|
74
|
+
```
|
|
75
|
+
|
|
76
|
+
**What Next?**
|
|
77
|
+
1. Run `/fd-discuss` to capture requirements
|
|
78
|
+
2. Run `/fd-plan` to create implementation plan
|
|
79
|
+
3. Run `/fd-execute` to implement with TDD
|
|
80
|
+
4. Run `/fd-verify` to confirm all checks pass
|
|
81
|
+
|
|
82
|
+
---
|
|
83
|
+
|
|
56
84
|
## /fd-discuss
|
|
57
85
|
|
|
58
86
|
**Description:** Opens a structured Q&A session to capture decisions for a phase. Saves decisions to `.planning/phases/phase-N/DISCUSS.md` with D-XX numbering.
|
|
@@ -61,14 +89,14 @@ Commands are slash commands registered in OpenCode. Run them by typing `/command
|
|
|
61
89
|
- `[topic]` — optional topic to focus the discussion
|
|
62
90
|
|
|
63
91
|
**What it does:**
|
|
64
|
-
1. Loads `.planning/
|
|
92
|
+
1. Loads `.planning/FEATURE.md` and `.planning/STATE.md` for context
|
|
65
93
|
2. Invokes `@discusser` agent which asks targeted questions one at a time
|
|
66
94
|
3. Records decisions with D-XX numbering (D-01, D-02, …)
|
|
67
95
|
4. Saves to `.planning/phases/phase-N/DISCUSS.md`
|
|
68
96
|
|
|
69
97
|
**Example:**
|
|
70
98
|
```
|
|
71
|
-
/fd-discuss
|
|
99
|
+
/fd-discuss
|
|
72
100
|
```
|
|
73
101
|
|
|
74
102
|
**What Next?**
|
|
@@ -93,19 +121,84 @@ Commands are slash commands registered in OpenCode. Run them by typing `/command
|
|
|
93
121
|
|
|
94
122
|
**Example:**
|
|
95
123
|
```
|
|
124
|
+
/fd-plan
|
|
96
125
|
/fd-plan --phase=1
|
|
97
126
|
```
|
|
98
127
|
|
|
99
128
|
**What Next?**
|
|
100
|
-
1. Run `/fd-
|
|
129
|
+
1. Run `/fd-execute` to implement the plan
|
|
101
130
|
2. Run `/fd-plan --phase=2` for next phase
|
|
102
131
|
|
|
103
132
|
---
|
|
104
133
|
|
|
105
|
-
## /fd-
|
|
134
|
+
## /fd-execute
|
|
135
|
+
|
|
136
|
+
**Description:** Implement the current phase's plan using TDD discipline with parallel agents. This is the execution step after planning is confirmed.
|
|
137
|
+
|
|
138
|
+
**Arguments:**
|
|
139
|
+
- `[--phase=N]` — target specific phase
|
|
140
|
+
- `[--override]` — bypass guards and proceed anyway
|
|
141
|
+
|
|
142
|
+
**What it does:**
|
|
143
|
+
1. Reads `.planning/phases/phase-N/PLAN.md` for implementation steps
|
|
144
|
+
2. For each step, enforces TDD cycle: BEHAVIOR → RED → GREEN → REFACTOR
|
|
145
|
+
3. `@tester` writes failing tests first
|
|
146
|
+
4. `@coder` implements minimum to pass
|
|
147
|
+
5. `@reviewer` confirms quality
|
|
148
|
+
6. Updates `STATE.md` with completed steps
|
|
149
|
+
7. Waves execute in order, with parallel tasks within each wave
|
|
150
|
+
|
|
151
|
+
**Example:**
|
|
152
|
+
```
|
|
153
|
+
/fd-execute
|
|
154
|
+
/fd-execute --phase=1
|
|
155
|
+
```
|
|
156
|
+
|
|
157
|
+
**What Next?**
|
|
158
|
+
1. Run `/fd-verify` to confirm all checks pass
|
|
159
|
+
2. Commit changes and create pull request
|
|
160
|
+
3. Run `/fd-checkpoint` to save session state
|
|
161
|
+
|
|
162
|
+
---
|
|
163
|
+
|
|
164
|
+
## /fd-verify
|
|
165
|
+
|
|
166
|
+
**Description:** Verify feature completion with full test suite, code review, security scan, and deploy check.
|
|
167
|
+
|
|
168
|
+
**Arguments:**
|
|
169
|
+
- `[--phase=N]` — target specific phase
|
|
170
|
+
- `[--env=staging|production]` — environment for deploy check (default: staging)
|
|
171
|
+
|
|
172
|
+
**What it does:**
|
|
173
|
+
1. Runs test suite — all tests must pass
|
|
174
|
+
2. Runs code review — `@reviewer` checks quality, security, conventions
|
|
175
|
+
3. Runs security scan — `@security-auditor` checks for vulnerabilities
|
|
176
|
+
4. Runs deploy check — build verification, CVE audit, readiness
|
|
177
|
+
5. Aggregates all findings into a verification report
|
|
178
|
+
6. Updates STATE.md if all checks pass
|
|
179
|
+
|
|
180
|
+
**Example:**
|
|
181
|
+
```
|
|
182
|
+
/fd-verify
|
|
183
|
+
/fd-verify --phase=1 --env=production
|
|
184
|
+
```
|
|
185
|
+
|
|
186
|
+
**Verdict:**
|
|
187
|
+
- ✅ **VERIFIED** — all checks pass, feature is ready
|
|
188
|
+
- ❌ **NOT VERIFIED** — one or more checks failed; review report and fix issues
|
|
189
|
+
|
|
190
|
+
**What Next?**
|
|
191
|
+
1. If VERIFIED: merge changes, deploy, or move to next phase
|
|
192
|
+
2. If NOT VERIFIED: fix issues and run `/fd-verify` again
|
|
193
|
+
|
|
194
|
+
---
|
|
195
|
+
|
|
196
|
+
## /fd-new-feature (old — now use /fd-execute)
|
|
106
197
|
|
|
107
198
|
**Description:** Implements a new feature end-to-end using TDD discipline with parallel agents. Reads active PLAN.md for context.
|
|
108
199
|
|
|
200
|
+
**DEPRECATED:** Use `/fd-execute` instead. The `/fd-new-feature` command is now the entry point for defining features (step 1 of 6).
|
|
201
|
+
|
|
109
202
|
**Arguments:**
|
|
110
203
|
- `[feature-description]` — plain-language description of the feature
|
|
111
204
|
|
|
@@ -118,7 +211,7 @@ Commands are slash commands registered in OpenCode. Run them by typing `/command
|
|
|
118
211
|
|
|
119
212
|
**Example:**
|
|
120
213
|
```
|
|
121
|
-
/fd-
|
|
214
|
+
/fd-execute "user authentication with JWT"
|
|
122
215
|
```
|
|
123
216
|
|
|
124
217
|
---
|
package/docs/quick-start.md
CHANGED
|
@@ -71,12 +71,28 @@ All subsequent agents read these files for context. Skip this step for brand-new
|
|
|
71
71
|
|
|
72
72
|
---
|
|
73
73
|
|
|
74
|
-
## Step 4:
|
|
74
|
+
## Step 4: Define a New Feature
|
|
75
75
|
|
|
76
|
-
|
|
76
|
+
Before discussing requirements, initialize the feature:
|
|
77
77
|
|
|
78
78
|
```
|
|
79
|
-
/fd-
|
|
79
|
+
/fd-new-feature user authentication
|
|
80
|
+
```
|
|
81
|
+
|
|
82
|
+
`@orchestrator` creates `.planning/phases/phase-1/FEATURE.md` and updates `STATE.md`. This establishes the feature context and shows you the next steps in the workflow:
|
|
83
|
+
1. /fd-discuss
|
|
84
|
+
2. /fd-plan
|
|
85
|
+
3. /fd-execute
|
|
86
|
+
4. /fd-verify
|
|
87
|
+
|
|
88
|
+
---
|
|
89
|
+
|
|
90
|
+
## Step 5: Start a Discussion
|
|
91
|
+
|
|
92
|
+
Requirements gathering comes next. Run:
|
|
93
|
+
|
|
94
|
+
```
|
|
95
|
+
/fd-discuss
|
|
80
96
|
```
|
|
81
97
|
|
|
82
98
|
`@discusser` asks structured questions about your goals, constraints, and success criteria — one question at a time. Each answer is numbered and tracked as a decision (`D-01`, `D-02`, …).
|
|
@@ -90,17 +106,17 @@ When you finish answering, the decisions are saved to `.planning/phases/phase-1/
|
|
|
90
106
|
|
|
91
107
|
---
|
|
92
108
|
|
|
93
|
-
## Step
|
|
109
|
+
## Step 6: Create an Implementation Plan
|
|
94
110
|
|
|
95
111
|
With requirements captured, generate the plan:
|
|
96
112
|
|
|
97
113
|
```
|
|
98
|
-
/fd-plan
|
|
114
|
+
/fd-plan
|
|
99
115
|
```
|
|
100
116
|
|
|
101
117
|
`@planner` reads `DISCUSS.md` and produces a wave-structured `PLAN.md` in `.planning/phases/phase-1/`. Then `@plan-checker` reviews it for quality — checking that task sizes are reasonable, success criteria are specific, and wave dependencies are correct.
|
|
102
118
|
|
|
103
|
-
You are shown the plan and prompted for confirmation. **Type `
|
|
119
|
+
You are shown the plan and prompted for confirmation. **Type `CONFIRM` to allow execution to proceed.** Review carefully before confirming:
|
|
104
120
|
|
|
105
121
|
- Are success criteria observable and specific?
|
|
106
122
|
- Are individual tasks sized to 1–3 hours?
|
|
@@ -108,40 +124,45 @@ You are shown the plan and prompted for confirmation. **Type `CONFIRMED` to allo
|
|
|
108
124
|
|
|
109
125
|
---
|
|
110
126
|
|
|
111
|
-
## Step
|
|
127
|
+
## Step 7: Execute the Feature
|
|
112
128
|
|
|
113
129
|
Once the plan is confirmed, start implementation:
|
|
114
130
|
|
|
115
131
|
```
|
|
116
|
-
/fd-
|
|
132
|
+
/fd-execute
|
|
117
133
|
```
|
|
118
134
|
|
|
119
|
-
`@orchestrator` reads `STATE.md` and `PLAN.md`, then delegates work to specialist agents in wave order:
|
|
135
|
+
`@orchestrator` reads `STATE.md` and `PLAN.md`, then delegates work to specialist agents in wave order via a TDD cycle (RED → GREEN → REFACTOR):
|
|
120
136
|
|
|
121
|
-
1. **
|
|
122
|
-
2. **
|
|
123
|
-
3. **
|
|
124
|
-
4. **
|
|
137
|
+
1. **Behavior** — Define acceptance cases from PLAN.md
|
|
138
|
+
2. **RED** — Write failing tests covering each behavior
|
|
139
|
+
3. **GREEN** — Implement minimum code to pass tests
|
|
140
|
+
4. **REFACTOR** — Clean up code while tests remain green
|
|
141
|
+
5. **Review** — `@reviewer` checks code quality and TDD discipline
|
|
125
142
|
|
|
126
|
-
You see progress updates as each
|
|
143
|
+
You see progress updates as each task completes. Independent tasks within a wave run simultaneously.
|
|
127
144
|
|
|
128
145
|
---
|
|
129
146
|
|
|
130
|
-
## Step
|
|
147
|
+
## Step 8: Verify Feature Completion
|
|
131
148
|
|
|
132
|
-
After implementation, run the
|
|
149
|
+
After implementation, run the full verification pipeline:
|
|
133
150
|
|
|
134
151
|
```
|
|
135
|
-
/fd-
|
|
152
|
+
/fd-verify
|
|
136
153
|
```
|
|
137
154
|
|
|
138
|
-
|
|
155
|
+
This runs four checks in parallel:
|
|
156
|
+
- **Tests** — Full test suite must pass
|
|
157
|
+
- **Code Review** — `@reviewer` checks quality, security, conventions
|
|
158
|
+
- **Security Scan** — `@security-auditor` checks for vulnerabilities
|
|
159
|
+
- **Deploy Check** — Build verification, CVE audit, readiness assessment
|
|
139
160
|
|
|
140
|
-
|
|
161
|
+
If all checks pass, the phase is marked **VERIFIED**. If any check fails, the report shows what needs fixing.
|
|
141
162
|
|
|
142
163
|
---
|
|
143
164
|
|
|
144
|
-
## Step
|
|
165
|
+
## Step 9: Review the Results
|
|
145
166
|
|
|
146
167
|
Before closing OpenCode, checkpoint your progress:
|
|
147
168
|
|
|
@@ -161,13 +182,13 @@ This writes the current execution state to `.planning/STATE.md`. To reload conte
|
|
|
161
182
|
|
|
162
183
|
## Tips
|
|
163
184
|
|
|
164
|
-
> **Check status at any time** — `/fd-
|
|
185
|
+
> **Check status at any time** — `/fd-status` prints the current state, active plan, and a summary of recent results without modifying anything.
|
|
165
186
|
|
|
166
187
|
> **Context after a restart** — always run `/fd-resume` at the start of a new OpenCode session on a project that was previously active. Agents have no memory between sessions without it.
|
|
167
188
|
|
|
168
|
-
> **Follow the
|
|
189
|
+
> **Follow the workflow order** — the cycle `/fd-new-feature → /fd-discuss → /fd-plan → /fd-execute → /fd-verify` ensures requirements are captured before implementation and verification happens at the end.
|
|
169
190
|
|
|
170
|
-
> **Skip
|
|
191
|
+
> **Skip to execute for small tasks** — for a quick bug fix, you do not need to run `/fd-discuss` and `/fd-plan`. Use `/fd-fix-bug` directly and let `@debug-specialist` handle the full cycle.
|
|
171
192
|
|
|
172
193
|
---
|
|
173
194
|
|
package/docs/workflows.md
CHANGED
|
@@ -15,20 +15,20 @@ FlowDeck commands are the single entry point for all operations. Each command em
|
|
|
15
15
|
```
|
|
16
16
|
/fd-new-project
|
|
17
17
|
↓
|
|
18
|
-
|
|
18
|
+
/fd-new-feature → .planning/phases/phase-N/FEATURE.md (feature defined)
|
|
19
19
|
↓
|
|
20
|
-
|
|
20
|
+
/fd-discuss → .planning/phases/phase-N/DISCUSS.md (locked decisions)
|
|
21
21
|
↓
|
|
22
|
-
|
|
22
|
+
/fd-plan → .planning/phases/phase-N/PLAN.md (confirmed plan)
|
|
23
23
|
↓
|
|
24
|
-
|
|
24
|
+
/fd-execute → implemented, tested, reviewed code (via TDD)
|
|
25
25
|
↓
|
|
26
|
-
|
|
26
|
+
/fd-verify → verification report (tests, review, security, deploy check)
|
|
27
27
|
↓
|
|
28
|
-
|
|
28
|
+
/fd-checkpoint → .planning/STATE.md saved
|
|
29
29
|
```
|
|
30
30
|
|
|
31
|
-
Each step gates the next. `/fd-
|
|
31
|
+
Each step gates the next. `/fd-discuss` requires a defined feature. `/fd-plan` requires confirmed decisions from `DISCUSS.md`. `/fd-execute` requires a confirmed `PLAN.md`. `/fd-verify` confirms all checks pass before marking the feature as complete.
|
|
32
32
|
|
|
33
33
|
---
|
|
34
34
|
|
|
@@ -39,12 +39,14 @@ Each step gates the next. `/fd-plan` will not proceed without a confirmed `DISCU
|
|
|
39
39
|
| `/fd-new-project` | Bootstrap a new project | @orchestrator |
|
|
40
40
|
| `/fd-map-codebase` | Analyse and index the codebase | @mapper (×6 parallel) |
|
|
41
41
|
| `/fd-settings` | Configure FlowDeck settings | @orchestrator |
|
|
42
|
+
| `/fd-new-feature` | Initialize a new feature | @orchestrator |
|
|
42
43
|
| `/fd-discuss` | Pre-planning discussion | @discusser |
|
|
43
44
|
| `/fd-plan` | Generate a phase plan | @planner, @plan-checker |
|
|
44
45
|
| `/fd-roadmap` | View / update project roadmap | @orchestrator |
|
|
45
46
|
| `/fd-dashboard` | Visual progress dashboard | — |
|
|
46
47
|
| `/fd-ask` | Smart agent dispatch | various |
|
|
47
|
-
| `/fd-
|
|
48
|
+
| `/fd-execute` | Implement feature via TDD | @orchestrator, @coder, @tester, @reviewer |
|
|
49
|
+
| `/fd-verify` | Verify feature completion | @tester, @reviewer, @security-auditor |
|
|
48
50
|
| `/fd-fix-bug` | Fix a bug with TDD | @debug-specialist, @tester, @coder |
|
|
49
51
|
| `/fd-review-code` | Code review | @reviewer, @researcher, @tester |
|
|
50
52
|
| `/fd-write-docs` | Generate documentation | @writer, @reviewer |
|
package/package.json
CHANGED
|
@@ -0,0 +1,192 @@
|
|
|
1
|
+
---
|
|
2
|
+
description: Execute feature implementation from PLAN.md — TDD pipeline with coder, tester, reviewer, and STATE.md update
|
|
3
|
+
argument-hint: [--phase=N] [--override]
|
|
4
|
+
---
|
|
5
|
+
|
|
6
|
+
# Execute
|
|
7
|
+
|
|
8
|
+
Implement the current phase's plan using the full FlowDeck TDD agent pipeline.
|
|
9
|
+
|
|
10
|
+
**Input:** $ARGUMENTS — optional `--phase=N` to target a specific phase, `--override` to bypass guards
|
|
11
|
+
|
|
12
|
+
## Pre-flight
|
|
13
|
+
|
|
14
|
+
1. Check `.planning/` exists — if not, error: "Run /fd-new-project first."
|
|
15
|
+
2. Check `plan_confirmed: true` in STATE.md — if not, error: "Confirm plan first with /fd-plan."
|
|
16
|
+
3. Read `.planning/phases/phase-<N>/PLAN.md` to get implementation steps.
|
|
17
|
+
4. Read `.codebase/ARCHITECTURE.md` if it exists — pass as context.
|
|
18
|
+
|
|
19
|
+
## TDD Cycle Per Step
|
|
20
|
+
|
|
21
|
+
Each plan step follows the TDD cycle:
|
|
22
|
+
|
|
23
|
+
```
|
|
24
|
+
BEHAVIOR → RED → GREEN → REFACTOR → next step
|
|
25
|
+
↑_________| |
|
|
26
|
+
(loop if needed) Only if GREEN
|
|
27
|
+
```
|
|
28
|
+
|
|
29
|
+
## Process
|
|
30
|
+
|
|
31
|
+
### Step 1: Guard Check
|
|
32
|
+
|
|
33
|
+
Verify prerequisites:
|
|
34
|
+
- `.planning/` directory exists
|
|
35
|
+
- `.codebase/` directory exists
|
|
36
|
+
- `STATE.md` has `plan_confirmed: true`
|
|
37
|
+
- `PLAN.md` exists in current phase directory
|
|
38
|
+
|
|
39
|
+
Initialize TDD state:
|
|
40
|
+
```yaml
|
|
41
|
+
tdd:
|
|
42
|
+
stage: behavior
|
|
43
|
+
cycle: 1
|
|
44
|
+
behaviors: []
|
|
45
|
+
regression_test_links: []
|
|
46
|
+
```
|
|
47
|
+
|
|
48
|
+
### Step 2: Load Plan
|
|
49
|
+
|
|
50
|
+
Read the active PLAN.md from the current phase directory.
|
|
51
|
+
Parse the tasks list and identify which steps are complete.
|
|
52
|
+
|
|
53
|
+
### Step 3: Define Behaviors
|
|
54
|
+
|
|
55
|
+
Spawn `@orchestrator` to generate behavior checklist from PLAN.md:
|
|
56
|
+
- Acceptance cases for each step
|
|
57
|
+
- Edge cases to test
|
|
58
|
+
- Expected behaviors
|
|
59
|
+
|
|
60
|
+
Store in TDD state.
|
|
61
|
+
|
|
62
|
+
### Step 4: Identify Next Step
|
|
63
|
+
|
|
64
|
+
From PLAN.md, find the first step NOT in `steps_complete`.
|
|
65
|
+
Check TDD stage — only proceed if stage is appropriate for the step.
|
|
66
|
+
|
|
67
|
+
### Step 5: Write Failing Tests (RED)
|
|
68
|
+
|
|
69
|
+
Spawn `@tester` to write tests for the step's behavior:
|
|
70
|
+
- **Tests MUST fail** before implementation
|
|
71
|
+
- Cover acceptance cases and edge cases
|
|
72
|
+
- Use AAA pattern (Arrange-Act-Assert)
|
|
73
|
+
|
|
74
|
+
### Step 6: Confirm RED
|
|
75
|
+
|
|
76
|
+
Run failing tests:
|
|
77
|
+
- **GUARD: Do NOT proceed to Step 7 until tests fail**
|
|
78
|
+
- If tests pass unexpectedly, tests don't correctly describe behavior
|
|
79
|
+
|
|
80
|
+
### Step 7: Implement Minimum (GREEN)
|
|
81
|
+
|
|
82
|
+
Spawn `@coder` to implement:
|
|
83
|
+
- **Minimum code** to make failing tests pass
|
|
84
|
+
- No speculative features
|
|
85
|
+
- No over-engineering
|
|
86
|
+
|
|
87
|
+
### Step 8: Confirm GREEN
|
|
88
|
+
|
|
89
|
+
Run tests:
|
|
90
|
+
- **GUARD: Do NOT proceed to Step 9 until tests pass**
|
|
91
|
+
- If tests fail, return to Step 7
|
|
92
|
+
|
|
93
|
+
### Step 9: Refactor (REFACTOR)
|
|
94
|
+
|
|
95
|
+
Only if GREEN:
|
|
96
|
+
- Clean up code for this step
|
|
97
|
+
- Remove dead code
|
|
98
|
+
- Improve readability
|
|
99
|
+
- **GUARD: Do not refactor if not GREEN**
|
|
100
|
+
|
|
101
|
+
### Step 10: Verify
|
|
102
|
+
|
|
103
|
+
Run full test suite:
|
|
104
|
+
- All tests must pass
|
|
105
|
+
- If any fails, revert refactoring
|
|
106
|
+
|
|
107
|
+
### Step 11: Review Step
|
|
108
|
+
|
|
109
|
+
Spawn `@reviewer` to check:
|
|
110
|
+
- Code quality, security, conventions
|
|
111
|
+
- TDD discipline followed
|
|
112
|
+
- Test coverage >= 80%
|
|
113
|
+
- No missing or weak tests (flag as major finding)
|
|
114
|
+
|
|
115
|
+
### Step 12: Update State
|
|
116
|
+
|
|
117
|
+
Mark step complete via planning-state tool:
|
|
118
|
+
```yaml
|
|
119
|
+
steps_complete: [N, ...]
|
|
120
|
+
last_action: "Step N complete via TDD: [behavior]"
|
|
121
|
+
tdd:
|
|
122
|
+
stage: behavior # Ready for next step
|
|
123
|
+
```
|
|
124
|
+
|
|
125
|
+
### Step 13: Loop or Complete
|
|
126
|
+
|
|
127
|
+
If more steps pending:
|
|
128
|
+
- Return to Step 3 (define behaviors for next step)
|
|
129
|
+
|
|
130
|
+
If all steps complete:
|
|
131
|
+
- Update phase status to "complete"
|
|
132
|
+
- Update ROADMAP.md progress
|
|
133
|
+
- Present completion summary
|
|
134
|
+
|
|
135
|
+
## Wave-Based Execution
|
|
136
|
+
|
|
137
|
+
WF-03 respects wave structure from PLAN.md:
|
|
138
|
+
- Wave 1 steps execute first (with TDD cycle per step)
|
|
139
|
+
- Wave 2 steps execute after Wave 1 completes
|
|
140
|
+
- Wave 3 steps execute after Wave 2 completes
|
|
141
|
+
- No intra-wave dependencies (parallel execution)
|
|
142
|
+
|
|
143
|
+
## Guards Summary
|
|
144
|
+
|
|
145
|
+
| Transition | Guard | If Violated |
|
|
146
|
+
|-----------|-------|-------------|
|
|
147
|
+
| behavior → red | Test written and fails | Block until test fails |
|
|
148
|
+
| red → green | Test exists and fails | Block until test passes |
|
|
149
|
+
| green → refactor | Tests are green | Block until green |
|
|
150
|
+
| refactor → verify | All tests pass | Block until all pass |
|
|
151
|
+
|
|
152
|
+
## Override Mechanism
|
|
153
|
+
|
|
154
|
+
User can override with `/fd-execute --override`:
|
|
155
|
+
- Every override is logged in `override_log`
|
|
156
|
+
- Surface override in next review
|
|
157
|
+
- Flag in deploy check
|
|
158
|
+
|
|
159
|
+
## Error Handling
|
|
160
|
+
|
|
161
|
+
D-03: Fail fast with clear error
|
|
162
|
+
- If guard check fails: abort with clear error and remediation
|
|
163
|
+
- If @coder fails: report failure, offer retry or skip
|
|
164
|
+
- If @reviewer finds critical issues: return to Step 7 for fixes
|
|
165
|
+
- No partial state saved on error
|
|
166
|
+
|
|
167
|
+
## State Updates
|
|
168
|
+
|
|
169
|
+
STATE.md updates after each step:
|
|
170
|
+
```yaml
|
|
171
|
+
steps_complete: [1, 2] # Added after step 2
|
|
172
|
+
steps_pending: [3, 4, 5] # Removed step 2
|
|
173
|
+
last_action: "Step 2 TDD complete: [behavior] (RED→GREEN→REFACTOR)"
|
|
174
|
+
tdd:
|
|
175
|
+
stage: behavior
|
|
176
|
+
cycle: 2
|
|
177
|
+
behaviors_completed: 2
|
|
178
|
+
```
|
|
179
|
+
|
|
180
|
+
Full phase completion:
|
|
181
|
+
```yaml
|
|
182
|
+
status: complete
|
|
183
|
+
last_action: "Phase N TDD complete — all steps finished"
|
|
184
|
+
tdd:
|
|
185
|
+
stage: complete
|
|
186
|
+
cycles_used: N
|
|
187
|
+
behaviors_completed: M
|
|
188
|
+
```
|
|
189
|
+
|
|
190
|
+
## Completion
|
|
191
|
+
|
|
192
|
+
Report: feature implemented, tests status, reviewer findings, files changed. Suggest running `/fd-verify`.
|