mirror of
https://github.com/azaion/gps-denied-onboard.git
synced 2026-04-22 07:16:38 +00:00
Oleksandr Bezdieniezhnykh
238 lines
11 KiB
Markdown
238 lines
11 KiB
Markdown
# Greenfield Workflow
|
||
|
||
Workflow for new projects built from scratch. Flows linearly: Problem → Research → Plan → UI Design (if applicable) → Decompose → Implement → Run Tests → Security Audit (optional) → Performance Test (optional) → Deploy → Retrospective.
|
||
|
||
## Step Reference Table
|
||
|
||
| Step | Name | Sub-Skill | Internal SubSteps |
|
||
|------|------|-----------|-------------------|
|
||
| 1 | Problem | problem/SKILL.md | Phase 1–4 |
|
||
| 2 | Research | research/SKILL.md | Mode A: Phase 1–4 · Mode B: Step 0–8 |
|
||
| 3 | Plan | plan/SKILL.md | Step 1–6 + Final |
|
||
| 4 | UI Design | ui-design/SKILL.md | Phase 0–8 (conditional — UI projects only) |
|
||
| 5 | Decompose | decompose/SKILL.md | Step 1–4 |
|
||
| 6 | Implement | implement/SKILL.md | (batch-driven, no fixed sub-steps) |
|
||
| 7 | Run Tests | test-run/SKILL.md | Steps 1–4 |
|
||
| 8 | Security Audit | security/SKILL.md | Phase 1–5 (optional) |
|
||
| 9 | Performance Test | test-run/SKILL.md (perf mode) | Steps 1–5 (optional) |
|
||
| 10 | Deploy | deploy/SKILL.md | Step 1–7 |
|
||
| 11 | Retrospective | retrospective/SKILL.md (cycle-end mode) | Steps 1–4 |
|
||
|
||
## Detection Rules
|
||
|
||
**Resolution**: when a state file exists, `state.step` + `state.status` drive detection and the conditions below are not consulted. When no state file exists (cold start), walk the rules in order — first folder-probe match wins. Steps without a folder probe are state-driven only; they can only be reached by auto-chain from a prior step.
|
||
|
||
---
|
||
|
||
**Step 1 — Problem Gathering**
|
||
Condition: `_docs/00_problem/` does not exist, OR any of these are missing/empty:
|
||
- `problem.md`
|
||
- `restrictions.md`
|
||
- `acceptance_criteria.md`
|
||
- `input_data/` (must contain at least one file)
|
||
|
||
Action: Read and execute `.cursor/skills/problem/SKILL.md`
|
||
|
||
---
|
||
|
||
**Step 2 — Research (Initial)**
|
||
Condition: `_docs/00_problem/` is complete AND `_docs/01_solution/` has no `solution_draft*.md` files
|
||
|
||
Action: Read and execute `.cursor/skills/research/SKILL.md` (will auto-detect Mode A)
|
||
|
||
---
|
||
|
||
**Research Decision** (inline gate between Step 2 and Step 3)
|
||
Condition: `_docs/01_solution/` contains `solution_draft*.md` files AND `_docs/01_solution/solution.md` does not exist AND `_docs/02_document/architecture.md` does not exist
|
||
|
||
Action: Present the current research state to the user:
|
||
- How many solution drafts exist
|
||
- Whether tech_stack.md and security_analysis.md exist
|
||
- One-line summary from the latest draft
|
||
|
||
Then present using the **Choose format**:
|
||
|
||
```
|
||
══════════════════════════════════════
|
||
DECISION REQUIRED: Research complete — next action?
|
||
══════════════════════════════════════
|
||
A) Run another research round (Mode B assessment)
|
||
B) Proceed to planning with current draft
|
||
══════════════════════════════════════
|
||
Recommendation: [A or B] — [reason based on draft quality]
|
||
══════════════════════════════════════
|
||
```
|
||
|
||
- If user picks A → Read and execute `.cursor/skills/research/SKILL.md` (will auto-detect Mode B)
|
||
- If user picks B → auto-chain to Step 3 (Plan)
|
||
|
||
---
|
||
|
||
**Step 3 — Plan**
|
||
Condition: `_docs/01_solution/` has `solution_draft*.md` files AND `_docs/02_document/architecture.md` does not exist
|
||
|
||
Action:
|
||
1. The plan skill's Prereq 2 will rename the latest draft to `solution.md` — this is handled by the plan skill itself
|
||
2. Read and execute `.cursor/skills/plan/SKILL.md`
|
||
|
||
If `_docs/02_document/` exists but is incomplete (has some artifacts but no `FINAL_report.md`), the plan skill's built-in resumability handles it.
|
||
|
||
---
|
||
|
||
**Step 4 — UI Design (conditional)**
|
||
Condition (folder fallback): `_docs/02_document/architecture.md` exists AND `_docs/02_tasks/todo/` does not exist or has no task files.
|
||
State-driven: reached by auto-chain from Step 3.
|
||
|
||
Action: Read and execute `.cursor/skills/ui-design/SKILL.md`. The skill runs its own **Applicability Check**, which handles UI project detection and the user's A/B choice. It returns one of:
|
||
|
||
- `outcome: completed` → mark Step 4 as `completed`, auto-chain to Step 5 (Decompose).
|
||
- `outcome: skipped, reason: not-a-ui-project` → mark Step 4 as `skipped`, auto-chain to Step 5.
|
||
- `outcome: skipped, reason: user-declined` → mark Step 4 as `skipped`, auto-chain to Step 5.
|
||
|
||
The autodev no longer inlines UI detection heuristics — they live in `ui-design/SKILL.md` under "Applicability Check".
|
||
|
||
---
|
||
|
||
**Step 5 — Decompose**
|
||
Condition: `_docs/02_document/` contains `architecture.md` AND `_docs/02_document/components/` has at least one component AND `_docs/02_tasks/todo/` does not exist or has no task files
|
||
|
||
Action: Read and execute `.cursor/skills/decompose/SKILL.md`
|
||
|
||
If `_docs/02_tasks/` subfolders have some task files already, the decompose skill's resumability handles it.
|
||
|
||
---
|
||
|
||
**Step 6 — Implement**
|
||
Condition: `_docs/02_tasks/todo/` contains task files AND `_dependencies_table.md` exists AND `_docs/03_implementation/` does not contain any `implementation_report_*.md` file
|
||
|
||
Action: Read and execute `.cursor/skills/implement/SKILL.md`
|
||
|
||
If `_docs/03_implementation/` has batch reports, the implement skill detects completed tasks and continues. The FINAL report filename is context-dependent — see implement skill documentation for naming convention.
|
||
|
||
---
|
||
|
||
**Step 7 — Run Tests**
|
||
Condition (folder fallback): `_docs/03_implementation/` contains an `implementation_report_*.md` file.
|
||
State-driven: reached by auto-chain from Step 6.
|
||
|
||
Action: Read and execute `.cursor/skills/test-run/SKILL.md`
|
||
|
||
---
|
||
|
||
**Step 8 — Security Audit (optional)**
|
||
State-driven: reached by auto-chain from Step 7.
|
||
|
||
Action: Apply the **Optional Skill Gate** (`protocols.md` → "Optional Skill Gate") with:
|
||
- question: `Run security audit before deploy?`
|
||
- option-a-label: `Run security audit (recommended for production deployments)`
|
||
- option-b-label: `Skip — proceed directly to deploy`
|
||
- recommendation: `A — catches vulnerabilities before production`
|
||
- target-skill: `.cursor/skills/security/SKILL.md`
|
||
- next-step: Step 9 (Performance Test)
|
||
|
||
---
|
||
|
||
**Step 9 — Performance Test (optional)**
|
||
State-driven: reached by auto-chain from Step 8.
|
||
|
||
Action: Apply the **Optional Skill Gate** (`protocols.md` → "Optional Skill Gate") with:
|
||
- question: `Run performance/load tests before deploy?`
|
||
- option-a-label: `Run performance tests (recommended for latency-sensitive or high-load systems)`
|
||
- option-b-label: `Skip — proceed directly to deploy`
|
||
- recommendation: `A or B — base on whether acceptance criteria include latency, throughput, or load requirements`
|
||
- target-skill: `.cursor/skills/test-run/SKILL.md` in **perf mode** (the skill handles runner detection, threshold comparison, and its own A/B/C gate on threshold failures)
|
||
- next-step: Step 10 (Deploy)
|
||
|
||
---
|
||
|
||
**Step 10 — Deploy**
|
||
State-driven: reached by auto-chain from Step 9 (after Step 9 is completed or skipped).
|
||
|
||
Action: Read and execute `.cursor/skills/deploy/SKILL.md`.
|
||
|
||
After the deploy skill completes successfully, mark Step 10 as `completed` and auto-chain to Step 11 (Retrospective).
|
||
|
||
---
|
||
|
||
**Step 11 — Retrospective**
|
||
State-driven: reached by auto-chain from Step 10.
|
||
|
||
Action: Read and execute `.cursor/skills/retrospective/SKILL.md` in **cycle-end mode**. This closes the cycle's feedback loop by folding metrics into `_docs/06_metrics/retro_<date>.md` and appending the top-3 lessons to `_docs/LESSONS.md`.
|
||
|
||
After retrospective completes, mark Step 11 as `completed` and enter "Done" evaluation.
|
||
|
||
---
|
||
|
||
**Done**
|
||
State-driven: reached by auto-chain from Step 11. (Sanity check: `_docs/04_deploy/` should contain all expected artifacts — containerization.md, ci_cd_pipeline.md, environment_strategy.md, observability.md, deployment_procedures.md, deploy_scripts.md.)
|
||
|
||
Action: Report project completion with summary. Then **rewrite the state file** so the next `/autodev` invocation enters the feature-cycle loop in the existing-code flow:
|
||
|
||
```
|
||
flow: existing-code
|
||
step: 9
|
||
name: New Task
|
||
status: not_started
|
||
sub_step:
|
||
phase: 0
|
||
name: awaiting-invocation
|
||
detail: ""
|
||
retry_count: 0
|
||
cycle: 1
|
||
```
|
||
|
||
On the next invocation, Flow Resolution rule 1 reads `flow: existing-code` and re-entry flows directly into existing-code Step 9 (New Task).
|
||
|
||
## Auto-Chain Rules
|
||
|
||
| Completed Step | Next Action |
|
||
|---------------|-------------|
|
||
| Problem (1) | Auto-chain → Research (2) |
|
||
| Research (2) | Auto-chain → Research Decision (ask user: another round or proceed?) |
|
||
| Research Decision → proceed | Auto-chain → Plan (3) |
|
||
| Plan (3) | Auto-chain → UI Design detection (4) |
|
||
| UI Design (4, done or skipped) | Auto-chain → Decompose (5) |
|
||
| Decompose (5) | **Session boundary** — suggest new conversation before Implement |
|
||
| Implement (6) | Auto-chain → Run Tests (7) |
|
||
| Run Tests (7, all pass) | Auto-chain → Security Audit choice (8) |
|
||
| Security Audit (8, done or skipped) | Auto-chain → Performance Test choice (9) |
|
||
| Performance Test (9, done or skipped) | Auto-chain → Deploy (10) |
|
||
| Deploy (10) | Auto-chain → Retrospective (11) |
|
||
| Retrospective (11) | Report completion; rewrite state to existing-code flow, step 9 |
|
||
|
||
## Status Summary — Step List
|
||
|
||
Flow name: `greenfield`. Render using the banner template in `protocols.md` → "Banner Template (authoritative)". No header-suffix, current-suffix, or footer-extras — all empty for this flow.
|
||
|
||
| # | Step Name | Extra state tokens (beyond the shared set) |
|
||
|---|--------------------|--------------------------------------------|
|
||
| 1 | Problem | — |
|
||
| 2 | Research | `DONE (N drafts)` |
|
||
| 3 | Plan | — |
|
||
| 4 | UI Design | — |
|
||
| 5 | Decompose | `DONE (N tasks)` |
|
||
| 6 | Implement | `IN PROGRESS (batch M of ~N)` |
|
||
| 7 | Run Tests | `DONE (N passed, M failed)` |
|
||
| 8 | Security Audit | — |
|
||
| 9 | Performance Test | — |
|
||
| 10 | Deploy | — |
|
||
| 11 | Retrospective | — |
|
||
|
||
All rows also accept the shared state tokens (`DONE`, `IN PROGRESS`, `NOT STARTED`, `FAILED (retry N/3)`); rows 4, 8, 9 additionally accept `SKIPPED`.
|
||
|
||
Row rendering format (step-number column is right-padded to 2 characters for alignment):
|
||
|
||
```
|
||
Step 1 Problem [<state token>]
|
||
Step 2 Research [<state token>]
|
||
Step 3 Plan [<state token>]
|
||
Step 4 UI Design [<state token>]
|
||
Step 5 Decompose [<state token>]
|
||
Step 6 Implement [<state token>]
|
||
Step 7 Run Tests [<state token>]
|
||
Step 8 Security Audit [<state token>]
|
||
Step 9 Performance Test [<state token>]
|
||
Step 10 Deploy [<state token>]
|
||
Step 11 Retrospective [<state token>]
|
||
```
|