speccrew 0.7.45 → 0.7.46
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/.speccrew/agents/speccrew-team-leader.md +6 -6
- package/README.ar.md +5 -17
- package/README.de.md +5 -17
- package/README.en.md +5 -17
- package/README.es.md +5 -17
- package/README.fr.md +5 -17
- package/README.hi.md +384 -0
- package/README.ja.md +5 -17
- package/README.md +5 -17
- package/README.pt-BR.md +5 -17
- package/README.ru.md +5 -17
- package/docs/GETTING-STARTED.ar.md +39 -40
- package/docs/GETTING-STARTED.de.md +39 -40
- package/docs/GETTING-STARTED.en.md +39 -40
- package/docs/GETTING-STARTED.es.md +39 -40
- package/docs/GETTING-STARTED.fr.md +39 -40
- package/docs/GETTING-STARTED.hi.md +636 -0
- package/docs/GETTING-STARTED.ja.md +39 -40
- package/docs/GETTING-STARTED.md +39 -40
- package/docs/GETTING-STARTED.pt-BR.md +25 -26
- package/docs/GETTING-STARTED.ru.md +37 -38
- package/lib/commands/init.js +3 -3
- package/package.json +1 -1
- package/README.bn.md +0 -174
- package/README.bs.md +0 -394
- package/README.da.md +0 -394
- package/README.el.md +0 -174
- package/README.it.md +0 -394
- package/README.ko.md +0 -394
- package/README.no.md +0 -394
- package/README.pl.md +0 -394
- package/README.th.md +0 -311
- package/README.tr.md +0 -306
- package/README.uk.md +0 -306
- package/README.vi.md +0 -174
- package/README.zh-TW.md +0 -394
- package/docs/GETTING-STARTED.bn.md +0 -219
- package/docs/GETTING-STARTED.bs.md +0 -219
- package/docs/GETTING-STARTED.da.md +0 -637
- package/docs/GETTING-STARTED.el.md +0 -633
- package/docs/GETTING-STARTED.it.md +0 -639
- package/docs/GETTING-STARTED.ko.md +0 -639
- package/docs/GETTING-STARTED.no.md +0 -563
- package/docs/GETTING-STARTED.pl.md +0 -597
- package/docs/GETTING-STARTED.th.md +0 -219
- package/docs/GETTING-STARTED.tr.md +0 -597
- package/docs/GETTING-STARTED.uk.md +0 -597
- package/docs/GETTING-STARTED.vi.md +0 -217
- package/docs/GETTING-STARTED.zh-TW.md +0 -639
|
@@ -1,633 +0,0 @@
|
|
|
1
|
-
# Οδηγός Γρήγορης Εκκίνησης SpecCrew
|
|
2
|
-
|
|
3
|
-
<p align="center">
|
|
4
|
-
<a href="./GETTING-STARTED.md">简体中文</a> |
|
|
5
|
-
<a href="./GETTING-STARTED.zh-TW.md">繁體中文</a> |
|
|
6
|
-
<a href="./GETTING-STARTED.en.md">English</a> |
|
|
7
|
-
<a href="./GETTING-STARTED.ko.md">한국어</a> |
|
|
8
|
-
<a href="./GETTING-STARTED.de.md">Deutsch</a> |
|
|
9
|
-
<a href="./GETTING-STARTED.es.md">Español</a> |
|
|
10
|
-
<a href="./GETTING-STARTED.fr.md">Français</a> |
|
|
11
|
-
<a href="./GETTING-STARTED.it.md">Italiano</a> |
|
|
12
|
-
<a href="./GETTING-STARTED.da.md">Dansk</a> |
|
|
13
|
-
<a href="./GETTING-STARTED.ja.md">日本語</a> |
|
|
14
|
-
<a href="./GETTING-STARTED.ar.md">العربية</a>
|
|
15
|
-
</p>
|
|
16
|
-
|
|
17
|
-
Αυτό το έγγραφο σας βοηθά να κατανοήσετε γρήγορα πώς να χρησιμοποιήσετε την ομάδα Agent του SpecCrew για να ολοκληρώσετε την πλήρη ανάπτυξη από τις απαιτήσεις έως την παράδοση σύμφωνα με τυπικές διαδικασίες μηχανικής.
|
|
18
|
-
|
|
19
|
-
---
|
|
20
|
-
|
|
21
|
-
## 1. Προαπαιτούμενα
|
|
22
|
-
|
|
23
|
-
### Εγκατάσταση SpecCrew
|
|
24
|
-
|
|
25
|
-
```bash
|
|
26
|
-
npm install -g speccrew
|
|
27
|
-
```
|
|
28
|
-
|
|
29
|
-
### Αρχικοποίηση Έργου
|
|
30
|
-
|
|
31
|
-
```bash
|
|
32
|
-
speccrew init --ide qoder
|
|
33
|
-
```
|
|
34
|
-
|
|
35
|
-
Υποστηριζόμενα IDE: `qoder`, `cursor`, `claude`, `codex`
|
|
36
|
-
|
|
37
|
-
### Δομή Καταλόγων Μετά την Αρχικοποίηση
|
|
38
|
-
|
|
39
|
-
```
|
|
40
|
-
.
|
|
41
|
-
├── .qoder/
|
|
42
|
-
│ ├── agents/ # Αρχεία ορισμού Agents
|
|
43
|
-
│ └── skills/ # Αρχεία ορισμού Skills
|
|
44
|
-
├── speccrew-workspace/ # Workspace
|
|
45
|
-
│ ├── docs/ # Διαμορφώσεις, κανόνες, πρότυπα, λύσεις
|
|
46
|
-
│ ├── iterations/ # Τρέχουσες επαναλήψεις
|
|
47
|
-
│ ├── iteration-archives/ # Αρχειοθετημένες επαναλήψεις
|
|
48
|
-
│ └── knowledges/ # Βάση γνώσεων
|
|
49
|
-
│ ├── base/ # Βασικές πληροφορίες (εκθέσεις διάγνωσης, τεχνικό χρέος)
|
|
50
|
-
│ ├── bizs/ # Επιχειρηματική βάση γνώσεων
|
|
51
|
-
│ └── techs/ # Τεχνική βάση γνώσεων
|
|
52
|
-
```
|
|
53
|
-
|
|
54
|
-
### Γρήγορη Αναφορά Εντολών CLI
|
|
55
|
-
|
|
56
|
-
| Εντολή | Περιγραφή |
|
|
57
|
-
|------|------|
|
|
58
|
-
| `speccrew list` | Λίστα όλων των διαθέσιμων Agents και Skills |
|
|
59
|
-
| `speccrew doctor` | Έλεγχος ακεραιότητας εγκατάστασης |
|
|
60
|
-
| `speccrew update` | Ενημέρωση διαμόρφωσης έργου στην τελευταία έκδοση |
|
|
61
|
-
| `speccrew uninstall` | Απεγκατάσταση SpecCrew |
|
|
62
|
-
|
|
63
|
-
---
|
|
64
|
-
|
|
65
|
-
## 2. Γρήγορη Εκκίνηση σε 5 Λεπτά Μετά την Εγκατάσταση
|
|
66
|
-
|
|
67
|
-
Μετά την εκτέλεση `speccrew init`, ακολουθήστε αυτά τα βήματα για γρήγορη μετάβαση σε κατάσταση εργασίας:
|
|
68
|
-
|
|
69
|
-
### Βήμα 1: Επιλέξτε το IDE σας
|
|
70
|
-
|
|
71
|
-
| IDE | Εντολή Αρχικοποίησης | Σενάριο Εφαρμογής |
|
|
72
|
-
|-----|-----------|----------|
|
|
73
|
-
| **Qoder** (Συνιστάται) | `speccrew init --ide qoder` | Πλήρης ενορχήστρωση agents, παράλληλοι workers |
|
|
74
|
-
| **Cursor** | `speccrew init --ide cursor` | Ροές εργασίας βασισμένες σε Composer |
|
|
75
|
-
| **Claude Code** | `speccrew init --ide claude` | Ανάπτυξη CLI-first |
|
|
76
|
-
| **Codex** | `speccrew init --ide codex` | Ενσωμάτωση οικοσυστήματος OpenAI |
|
|
77
|
-
|
|
78
|
-
### Βήμα 2: Αρχικοποίηση Βάσης Γνώσεων (Συνιστάται)
|
|
79
|
-
|
|
80
|
-
Για έργα με υπάρχοντα πηγαίο κώδικα, συνιστάται η αρχικοποίηση της βάσης γνώσεων πρώτα ώστε οι agents να κατανοήσουν τη βάση κώδικά σας:
|
|
81
|
-
|
|
82
|
-
```
|
|
83
|
-
@speccrew-team-leader αρχικοποίηση τεχνικής βάσης γνώσεων
|
|
84
|
-
```
|
|
85
|
-
|
|
86
|
-
Στη συνέχεια:
|
|
87
|
-
|
|
88
|
-
```
|
|
89
|
-
@speccrew-team-leader αρχικοποίηση επιχειρηματικής βάσης γνώσεων
|
|
90
|
-
```
|
|
91
|
-
|
|
92
|
-
### Βήμα 3: Ξεκινήστε την Πρώτη σας Εργασία
|
|
93
|
-
|
|
94
|
-
```
|
|
95
|
-
@speccrew-product-manager Έχω μια νέα απαίτηση: [περιγράψτε τη λειτουργική απαίτησή σας]
|
|
96
|
-
```
|
|
97
|
-
|
|
98
|
-
> **Συμβουλή**: Αν δεν είστε σίγουροι τι να κάνετε, απλά πείτε `@speccrew-team-leader βοηθήστε με να ξεκινήσω` — ο Team Leader θα ανιχνεύσει αυτόματα την κατάσταση του έργου σας και θα σας καθοδηγήσει.
|
|
99
|
-
|
|
100
|
-
---
|
|
101
|
-
|
|
102
|
-
## 3. Γρήγορο Δέντρο Αποφάσεων
|
|
103
|
-
|
|
104
|
-
Δεν είστε σίγουροι τι να κάνετε; Βρείτε το σενάριό σας παρακάτω:
|
|
105
|
-
|
|
106
|
-
- **Έχω μια νέα λειτουργική απαίτηση**
|
|
107
|
-
→ `@speccrew-product-manager Έχω μια νέα απαίτηση: [περιγράψτε τη λειτουργική απαίτησή σας]`
|
|
108
|
-
|
|
109
|
-
- **Θέλω να σαρώσω τη γνώση υπάρχοντος έργου**
|
|
110
|
-
→ `@speccrew-team-leader αρχικοποίηση τεχνικής βάσης γνώσεων`
|
|
111
|
-
→ Στη συνέχεια: `@speccrew-team-leader αρχικοποίηση επιχειρηματικής βάσης γνώσεων`
|
|
112
|
-
|
|
113
|
-
- **Θέλω να συνεχίσω την προηγούμενη εργασία**
|
|
114
|
-
→ `@speccrew-team-leader ποια είναι η τρέχουσα πρόοδος;`
|
|
115
|
-
|
|
116
|
-
- **Θέλω να ελέγξω την κατάσταση υγείας του συστήματος**
|
|
117
|
-
→ Εκτέλεση στο τερματικό: `speccrew doctor`
|
|
118
|
-
|
|
119
|
-
- **Δεν είμαι σίγουρος τι να κάνω**
|
|
120
|
-
→ `@speccrew-team-leader βοηθήστε με να ξεκινήσω`
|
|
121
|
-
→ Ο Team Leader θα ανιχνεύσει αυτόματα την κατάσταση του έργου σας και θα σας καθοδηγήσει
|
|
122
|
-
|
|
123
|
-
---
|
|
124
|
-
|
|
125
|
-
## 4. Γρήγορη Αναφορά Agents
|
|
126
|
-
|
|
127
|
-
| Ρόλος | Agent | Ευθύνες | Παράδειγμα Εντολής |
|
|
128
|
-
|------|-------|-----------------|-----------------|
|
|
129
|
-
| Αρχηγός Ομάδας | `@speccrew-team-leader` | Πλοήγηση έργου, αρχικοποίηση βάσης γνώσης, έλεγχος κατάστασης | "Βοηθήστε με να ξεκινήσω" |
|
|
130
|
-
| Διαχειριστής Προϊόντος | `@speccrew-product-manager` | Ανάλυση απαιτήσεων, δημιουργία PRD | "Έχω μια νέα απαίτηση: ..." |
|
|
131
|
-
| Σχεδιαστής Λειτουργιών | `@speccrew-feature-designer` | Ανάλυση λειτουργιών, σχεδιασμός προδιαγραφών, συμβάσεις API | "Έναρξη σχεδιασμού λειτουργιών για επανάληψη X" |
|
|
132
|
-
| Σχεδιαστής Συστήματος | `@speccrew-system-designer` | Σχεδιασμός αρχιτεκτονικής, λεπτομερής σχεδιασμός πλατφόρμας | "Έναρξη σχεδιασμού συστήματος για επανάληψη X" |
|
|
133
|
-
| Προγραμματιστής Συστήματος | `@speccrew-system-developer` | Συντονισμός ανάπτυξης, δημιουργία κώδικα | "Έναρξη ανάπτυξης για επανάληψη X" |
|
|
134
|
-
| Διαχειριστής Δοκιμών | `@speccrew-test-manager` | Σχεδιασμός δοκιμών, σχεδιασμός περιπτώσεων, εκτέλεση | "Έναρξη δοκιμών για επανάληψη X" |
|
|
135
|
-
|
|
136
|
-
> **Σημείωση**: Δεν χρειάζεται να θυμάστε όλους τους agents. Απλά μιλήστε με `@speccrew-team-leader` και θα δρομολογήσει το αίτημά σας στον σωστό agent.
|
|
137
|
-
|
|
138
|
-
---
|
|
139
|
-
|
|
140
|
-
## 5. Επισκόπηση Ροής Εργασίας
|
|
141
|
-
|
|
142
|
-
### Πλήρες Διάγραμμα Ροής
|
|
143
|
-
|
|
144
|
-
```mermaid
|
|
145
|
-
flowchart LR
|
|
146
|
-
PRD[Φάση 1<br/>Ανάλυση Απαιτήσεων<br/>Product Manager] --> FD[Φάση 2<br/>Feature Design<br/>Feature Designer]
|
|
147
|
-
FD --> SD[Φάση 3<br/>System Design<br/>System Designer]
|
|
148
|
-
SD --> DEV[Φάση 4<br/>Ανάπτυξη<br/>System Developer]
|
|
149
|
-
DEV --> DEPLOY[Φάση 5<br/>Ανάπτυξη<br/>System Deployer]
|
|
150
|
-
DEPLOY --> TEST[Φάση 6<br/>Συστημικές Δοκιμές<br/>Test Manager]
|
|
151
|
-
TEST --> ARCHIVE[Φάση 7<br/>Αρχειοθέτηση]
|
|
152
|
-
|
|
153
|
-
KB[(Βάση Γνώσης<br/>Όλη η Διαδικασία)] -.-> PRD
|
|
154
|
-
KB -.-> FD
|
|
155
|
-
KB -.-> SD
|
|
156
|
-
KB -.-> DEV
|
|
157
|
-
KB -.-> DEPLOY
|
|
158
|
-
KB -.-> TEST
|
|
159
|
-
```
|
|
160
|
-
|
|
161
|
-
### Βασικές Αρχές
|
|
162
|
-
|
|
163
|
-
1. **Εξαρτήσεις Φάσεων**: Το παράγωγο κάθε φάσης είναι η είσοδος για την επόμενη φάση
|
|
164
|
-
2. **Επιβεβαίωση Checkpoint**: Κάθε φάση έχει σημείο επιβεβαίωσης που απαιτεί έγκριση χρήστη πριν προχωρήσει στην επόμενη φάση
|
|
165
|
-
3. **Οδηγούμενο από Βάση Γνώσης**: Η βάση γνώσης διατρέχει όλη τη διαδικασία, παρέχοντας_context για όλες τις φάσεις
|
|
166
|
-
|
|
167
|
-
---
|
|
168
|
-
|
|
169
|
-
## 6. Βήμα Μηδέν: Αρχικοποίηση Βάσης Γνώσης
|
|
170
|
-
|
|
171
|
-
Πριν ξεκινήσετε την επίσημη διαδικασία μηχανικής, πρέπει να αρχικοποιήσετε τη βάση γνώσης του έργου.
|
|
172
|
-
|
|
173
|
-
### 6.1 Αρχικοποίηση Τεχνικής Βάσης Γνώσης
|
|
174
|
-
|
|
175
|
-
**Παράδειγμα Συνομιλίας**:
|
|
176
|
-
```
|
|
177
|
-
@speccrew-team-leader αρχικοποίηση τεχνικής βάσης γνώσης
|
|
178
|
-
```
|
|
179
|
-
|
|
180
|
-
**Τριφασική Διαδικασία**:
|
|
181
|
-
1. Ανίχνευση Πλατφόρμας — Αναγνώριση τεχνικών πλατφορμών στο έργο
|
|
182
|
-
2. Δημιουργία Τεχνικής Τεκμηρίωσης — Δημιουργία εγγράφων τεχνικών προδιαγραφών για κάθε πλατφόρμα
|
|
183
|
-
3. Δημιουργία Ευρετηρίου — Δημιουργία ευρετηρίου βάσης γνώσης
|
|
184
|
-
|
|
185
|
-
**Παράγωγο**:
|
|
186
|
-
```
|
|
187
|
-
speccrew-workspace/knowledges/techs/{platform-id}/
|
|
188
|
-
├── tech-stack.md # Ορισμός τεχνολογικού stack
|
|
189
|
-
├── architecture.md # Αρχιτεκτονικές συμβάσεις
|
|
190
|
-
├── dev-spec.md # Προδιαγραφές ανάπτυξης
|
|
191
|
-
├── test-spec.md # Προδιαγραφές δοκιμών
|
|
192
|
-
└── INDEX.md # Αρχείο ευρετηρίου
|
|
193
|
-
```
|
|
194
|
-
|
|
195
|
-
### 6.2 Αρχικοποίηση Επιχειρηματικής Βάσης Γνώσης
|
|
196
|
-
|
|
197
|
-
**Παράδειγμα Συνομιλίας**:
|
|
198
|
-
```
|
|
199
|
-
@speccrew-team-leader αρχικοποίηση επιχειρηματικής βάσης γνώσης
|
|
200
|
-
```
|
|
201
|
-
|
|
202
|
-
**Τετραφασική Διαδικασία**:
|
|
203
|
-
1. Καταγραφή Λειτουργιών — Σάρωση κώδικα για αναγνώριση όλων των λειτουργιών
|
|
204
|
-
2. Ανάλυση Λειτουργιών — Ανάλυση επιχειρηματικής λογικής για κάθε λειτουργία
|
|
205
|
-
3. Σύνοψη Ενότητας — Σύνοψη λειτουργιών ανά ενότητα
|
|
206
|
-
4. Συνοπτική Παρουσίαση Συστήματος — Δημιουργία επιχειρηματικής επισκόπησης σε επίπεδο συστήματος
|
|
207
|
-
|
|
208
|
-
**Παράγωγο**:
|
|
209
|
-
```
|
|
210
|
-
speccrew-workspace/knowledges/bizs/
|
|
211
|
-
├── {platform-type}/
|
|
212
|
-
│ └── {module-name}/
|
|
213
|
-
│ └── feature-spec.md
|
|
214
|
-
└── system-overview.md
|
|
215
|
-
```
|
|
216
|
-
|
|
217
|
-
---
|
|
218
|
-
|
|
219
|
-
## 7. Οδηγός Συνομιλίας Ανά Φάση
|
|
220
|
-
|
|
221
|
-
### 7.1 Φάση 1: Ανάλυση Απαιτήσεων (Product Manager)
|
|
222
|
-
|
|
223
|
-
**Πώς να ξεκινήσετε**:
|
|
224
|
-
```
|
|
225
|
-
@speccrew-product-manager Έχω μια νέα απαίτηση: [περιγράψτε την απαίτησή σας]
|
|
226
|
-
```
|
|
227
|
-
|
|
228
|
-
**Ροή Εργασίας Agent**:
|
|
229
|
-
1. Διαβάστε την επισκόπηση συστήματος για κατανόηση υπαρχόντων ενοτήτων
|
|
230
|
-
2. Αναλύστε τις απαιτήσεις χρήστη
|
|
231
|
-
3. Δημιουργήστε δομημένο έγγραφο PRD
|
|
232
|
-
|
|
233
|
-
**Παράγωγο**:
|
|
234
|
-
```
|
|
235
|
-
iterations/{αριθμός}-{τύπος}-{όνομα}/01.product-requirement/
|
|
236
|
-
├── [feature-name]-prd.md # Έγγραφο Απαιτήσεων Προϊόντος
|
|
237
|
-
└── [feature-name]-bizs-modeling.md # Επιχειρηματική μοντελοποίηση (για σύνθετες απαιτήσεις)
|
|
238
|
-
```
|
|
239
|
-
|
|
240
|
-
**Λίστα Ελέγχου Επιβεβαίωσης**:
|
|
241
|
-
- [ ] Η περιγραφή απαίτησης αντικατοπτρίζει ακριβώς την πρόθεση του χρήστη;
|
|
242
|
-
- [ ] Οι επιχειρηματικοί κανόνες είναι πλήρεις;
|
|
243
|
-
- [ ] Τα σημεία ενσωμάτωσης με υπάρχοντα συστήματα είναι ξεκάθαρα;
|
|
244
|
-
- [ ] Τα κριτήρια αποδοχής είναι μετρήσιμα;
|
|
245
|
-
|
|
246
|
-
---
|
|
247
|
-
|
|
248
|
-
### 7.2 Φάση 2: Feature Design (Feature Designer)
|
|
249
|
-
|
|
250
|
-
**Πώς να ξεκινήσετε**:
|
|
251
|
-
```
|
|
252
|
-
@speccrew-feature-designer έναρξη feature design
|
|
253
|
-
```
|
|
254
|
-
|
|
255
|
-
**Ροή Εργασίας Agent**:
|
|
256
|
-
1. Αυτόματος εντοπισμός επιβεβαιωμένου εγγράφου PRD
|
|
257
|
-
2. Φόρτωση επιχειρηματικής βάσης γνώσης
|
|
258
|
-
3. Δημιουργία feature design (συμπεριλαμβανομένων UI wireframes, ροών αλληλεπίδρασης, ορισμών δεδομένων, συμβάσεων API)
|
|
259
|
-
4. Για πολλαπλά PRD, χρησιμοποιήστε Task Worker για παράλληλο σχεδιασμό
|
|
260
|
-
|
|
261
|
-
**Παράγωγο**:
|
|
262
|
-
```
|
|
263
|
-
iterations/{iter}/02.feature-design/
|
|
264
|
-
└── [feature-name]-feature-spec.md # Έγγραφο feature design
|
|
265
|
-
```
|
|
266
|
-
|
|
267
|
-
**Λίστα Ελέγχου Επιβεβαίωσης**:
|
|
268
|
-
- [ ] Όλα τα σενάρια χρήστη καλύπτονται;
|
|
269
|
-
- [ ] Οι ροές αλληλεπίδρασης είναι ξεκάθαρες;
|
|
270
|
-
- [ ] Οι ορισμοί πεδίων δεδομένων είναι πλήρεις;
|
|
271
|
-
- [ ] Η διαχείριση εξαιρέσεων είναι περιεκτική;
|
|
272
|
-
|
|
273
|
-
---
|
|
274
|
-
|
|
275
|
-
### 7.3 Φάση 3: System Design (System Designer)
|
|
276
|
-
|
|
277
|
-
**Πώς να ξεκινήσετε**:
|
|
278
|
-
```
|
|
279
|
-
@speccrew-system-designer έναρξη system design
|
|
280
|
-
```
|
|
281
|
-
|
|
282
|
-
**Ροή Εργασίας Agent**:
|
|
283
|
-
1. Εντοπισμός Feature Spec και API Contract
|
|
284
|
-
2. Φόρτωση τεχνικής βάσης γνώσης (τεχνολογικό stack, αρχιτεκτονική, προδιαγραφές για κάθε πλατφόρμα)
|
|
285
|
-
3. **Checkpoint A**: Αξιολόγηση Framework — Ανάλυση τεχνικών κενών, σύσταση νέων frameworks (εάν απαιτείται), αναμονή επιβεβαίωσης χρήστη
|
|
286
|
-
4. Δημιουργία DESIGN-OVERVIEW.md
|
|
287
|
-
5. Χρήση Task Worker για παράλληλη διανομή σχεδιασμού για κάθε πλατφόρμα (frontend/backend/mobile/desktop)
|
|
288
|
-
6. **Checkpoint B**: Κοινή Επιβεβαίωση — Εμφάνιση σύνοψης όλων των σχεδιασμών πλατφορμών, αναμονή επιβεβαίωσης χρήστη
|
|
289
|
-
|
|
290
|
-
**Παράγωγο**:
|
|
291
|
-
```
|
|
292
|
-
iterations/{iter}/03.system-design/
|
|
293
|
-
├── DESIGN-OVERVIEW.md # Επισκόπηση σχεδιασμού
|
|
294
|
-
├── {platform-id}/
|
|
295
|
-
│ ├── INDEX.md # Ευρετήριο σχεδιασμού πλατφόρμας
|
|
296
|
-
│ └── {module}-design.md # Σχεδιασμός ενότητας επιπέδου ψευδοκώδικα
|
|
297
|
-
```
|
|
298
|
-
|
|
299
|
-
**Λίστα Ελέγχου Επιβεβαίωσης**:
|
|
300
|
-
- [ ] Ο ψευδοκώδικας χρησιμοποιεί την πραγματική σύνταξη framework;
|
|
301
|
-
- [ ] Οι δια-πλατφορμικές συμβάσεις API είναι συνεπείς;
|
|
302
|
-
- [ ] Η στρατηγική διαχείρισης σφαλμάτων είναι ενοποιημένη;
|
|
303
|
-
|
|
304
|
-
---
|
|
305
|
-
|
|
306
|
-
### 7.4 Φάση 4: Ανάπτυξη (System Developer)
|
|
307
|
-
|
|
308
|
-
**Πώς να ξεκινήσετε**:
|
|
309
|
-
```
|
|
310
|
-
@speccrew-system-developer έναρξη ανάπτυξης
|
|
311
|
-
```
|
|
312
|
-
|
|
313
|
-
**Ροή Εργασίας Agent**:
|
|
314
|
-
1. Ανάγνωση εγγράφων σχεδιασμού συστήματος
|
|
315
|
-
2. Φόρτωση τεχνικών γνώσεων για κάθε πλατφόρμα
|
|
316
|
-
3. **Checkpoint A**: Προ-έλεγχος Περιβάλλοντος — Έλεγχος εκδόσεων runtime, εξαρτήσεων, διαθεσιμότητας υπηρεσιών; αναμονή επίλυσης χρήστη εάν αποτύχει
|
|
317
|
-
4. Χρήση Task Worker για παράλληλη διανομή ανάπτυξης για κάθε πλατφόρμα
|
|
318
|
-
5. Έλεγχος ενσωμάτωσης: στοίχιση συμβάσεων API, συνέπεια δεδομένων
|
|
319
|
-
6. Έξοδος αναφοράς παράδοσης
|
|
320
|
-
|
|
321
|
-
**Παράγωγο**:
|
|
322
|
-
```
|
|
323
|
-
# Ο πηγαίος κώδικας γράφεται στον πραγματικό κατάλογο πηγαίου κώδικα του έργου
|
|
324
|
-
iterations/{iter}/04.development/
|
|
325
|
-
├── {platform-id}/
|
|
326
|
-
│ └── tasks/ # Καταγραφές εργασιών ανάπτυξης
|
|
327
|
-
└── delivery-report.md
|
|
328
|
-
```
|
|
329
|
-
|
|
330
|
-
**Λίστα Ελέγχου Επιβεβαίωσης**:
|
|
331
|
-
- [ ] Το περιβάλλον είναι έτοιμο;
|
|
332
|
-
- [ ] Τα προβλήματα ενσωμάτωσης είναι σε αποδεκτό εύρος;
|
|
333
|
-
- [ ] Ο κώδικας συμμορφώνεται με τις προδιαγραφές ανάπτυξης;
|
|
334
|
-
|
|
335
|
-
---
|
|
336
|
-
|
|
337
|
-
### 7.5 Φάση 5: Ανάπτυξη (System Deployer)
|
|
338
|
-
|
|
339
|
-
**Πώς να ξεκινήσετε**:
|
|
340
|
-
```
|
|
341
|
-
@speccrew-system-deployer έναρξη ανάπτυξης
|
|
342
|
-
```
|
|
343
|
-
|
|
344
|
-
**Ροή Εργασίας Agent**:
|
|
345
|
-
1. Επαληθεύστε ότι η φάση ανάπτυξης έχει ολοκληρωθεί (Stage Gate)
|
|
346
|
-
2. Φόρτωση τεχνικής βάσης γνώσης (διαμόρφωση build, διαμόρφωση μεταφοράς βάσης δεδομένων, εντολές εκκίνησης υπηρεσίας)
|
|
347
|
-
3. **Checkpoint**: Προ-έλεγχος περιβάλλοντος — Επαλήθευση εργαλείων build, εκδόσεων runtime, διαθεσιμότητας εξαρτήσεων
|
|
348
|
-
4. Εκτέλεση δεξιοτήτων ανάπτυξης με τη σειρά: Build → Μεταφορά Βάσης Δεδομένων → Εκκίνηση Υπηρεσίας → Smoke Test
|
|
349
|
-
5. Έξοδος αναφοράς ανάπτυξης
|
|
350
|
-
|
|
351
|
-
> 💡 **Συμβουλή**: Για έργα χωρίς βάση δεδομένων, το βήμα μεταφοράς παρακάμπτεται αυτόματα; για εφαρμογές πελάτη (desktop/mobil), χρησιμοποιείται λειτουργία επαλήθευσης διεργασίας αντί για έλεγχο υγείας HTTP.
|
|
352
|
-
|
|
353
|
-
**Παράγωγο**:
|
|
354
|
-
```
|
|
355
|
-
iterations/{iter}/05.deployment/
|
|
356
|
-
├── {platform-id}/
|
|
357
|
-
│ ├── deployment-plan.md # Σχέδιο ανάπτυξης
|
|
358
|
-
│ └── deployment-log.md # Αρχείο εκτέλεσης ανάπτυξης
|
|
359
|
-
└── deployment-report.md # Αναφορά ολοκλήρωσης ανάπτυξης
|
|
360
|
-
```
|
|
361
|
-
|
|
362
|
-
**Λίστα Ελέγχου Επιβεβαίωσης**:
|
|
363
|
-
- [ ] Το build ολοκληρώθηκε επιτυχώς;
|
|
364
|
-
- [ ] Όλα τα σενάρια μεταφοράς βάσης δεδομένων εκτελέστηκαν επιτυχώς (αν υπάρχουν);
|
|
365
|
-
- [ ] Η εφαρμογή ξεκίνησε και πέρασε τον έλεγχο υγείας;
|
|
366
|
-
- [ ] Όλα τα smoke tests πέρασαν;
|
|
367
|
-
|
|
368
|
-
---
|
|
369
|
-
|
|
370
|
-
### 7.6 Φάση 6: Συστημικές Δοκιμές (Test Manager)
|
|
371
|
-
|
|
372
|
-
**Πώς να ξεκινήσετε**:
|
|
373
|
-
```
|
|
374
|
-
@speccrew-test-manager έναρξη δοκιμών
|
|
375
|
-
```
|
|
376
|
-
|
|
377
|
-
**Τριφασική Διαδικασία Δοκιμών**:
|
|
378
|
-
|
|
379
|
-
| Φάση | Περιγραφή | Checkpoint |
|
|
380
|
-
|-------|-------------|------------|
|
|
381
|
-
| Σχεδιασμός Περιπτώσεων Δοκιμής | Δημιουργία περιπτώσεων δοκιμής βάσει PRD και Feature Spec | A: Εμφάνιση στατιστικών κάλυψης περιπτώσεων και πίνακα ιχνηλασιμότητας, αναμονή επιβεβαίωσης χρήστη επαρκούς κάλυψης |
|
|
382
|
-
| Δημιουργία Κώδικα Δοκιμής | Δημιουργία εκτελέσιμου κώδικα δοκιμής | B: Εμφάνιση δημιουργημένων αρχείων δοκιμής και αντιστοίχισης περιπτώσεων, αναμονή επιβεβαίωσης χρήστη |
|
|
383
|
-
| Εκτέλεση Δοκιμών και Αναφορά Σφαλμάτων | Αυτόματη εκτέλεση δοκιμών και δημιουργία αναφορών | Καμία (αυτόματη εκτέλεση) |
|
|
384
|
-
|
|
385
|
-
**Παράγωγο**:
|
|
386
|
-
```
|
|
387
|
-
iterations/{iter}/06.system-test/
|
|
388
|
-
├── cases/
|
|
389
|
-
│ └── {platform-id}/ # Έγγραφα περιπτώσεων δοκιμής
|
|
390
|
-
├── code/
|
|
391
|
-
│ └── {platform-id}/ # Σχέδιο κώδικα δοκιμής
|
|
392
|
-
├── reports/
|
|
393
|
-
│ └── test-report-{date}.md # Αναφορά δοκιμής
|
|
394
|
-
└── bugs/
|
|
395
|
-
└── BUG-{id}-{title}.md # Αναφορές σφαλμάτων (ένα αρχείο ανά σφάλμα)
|
|
396
|
-
```
|
|
397
|
-
|
|
398
|
-
**Λίστα Ελέγχου Επιβεβαίωσης**:
|
|
399
|
-
- [ ] Η κάλυψη περιπτώσεων είναι πλήρης;
|
|
400
|
-
- [ ] Ο κώδικας δοκιμής είναι εκτελέσιμος;
|
|
401
|
-
- [ ] Η αξιολόγηση σοβαρότητας σφαλμάτων είναι ακριβής;
|
|
402
|
-
|
|
403
|
-
---
|
|
404
|
-
|
|
405
|
-
### 7.7 Φάση 7: Αρχειοθέτηση
|
|
406
|
-
|
|
407
|
-
Οι επαναλήψεις αρχειοθετούνται αυτόματα μετά την ολοκλήρωση:
|
|
408
|
-
|
|
409
|
-
```
|
|
410
|
-
speccrew-workspace/iteration-archives/
|
|
411
|
-
└── {αριθμός}-{τύπος}-{όνομα}-{ημερομηνία}/
|
|
412
|
-
├── 01.product-requirement/
|
|
413
|
-
├── 02.feature-design/
|
|
414
|
-
├── 03.system-design/
|
|
415
|
-
├── 04.development/
|
|
416
|
-
├── 05.deployment/
|
|
417
|
-
└── 06.system-test/
|
|
418
|
-
```
|
|
419
|
-
|
|
420
|
-
---
|
|
421
|
-
|
|
422
|
-
## 8. Επισκόπηση Βάσης Γνώσης
|
|
423
|
-
|
|
424
|
-
### 8.1 Επιχειρηματική Βάση Γνώσης (bizs)
|
|
425
|
-
|
|
426
|
-
**Σκοπός**: Αποθήκευση περιγραφών επιχειρηματικών λειτουργιών έργου, διαιρέσεων ενοτήτων, χαρακτηριστικών API
|
|
427
|
-
|
|
428
|
-
**Δομή Καταλόγων**:
|
|
429
|
-
```
|
|
430
|
-
knowledges/bizs/
|
|
431
|
-
├── {platform-type}/
|
|
432
|
-
│ └── {module-name}/
|
|
433
|
-
│ └── feature-spec.md
|
|
434
|
-
└── system-overview.md
|
|
435
|
-
```
|
|
436
|
-
|
|
437
|
-
**Σενάρια Χρήσης**: Product Manager, Feature Designer
|
|
438
|
-
|
|
439
|
-
### 8.2 Τεχνική Βάση Γνώσης (techs)
|
|
440
|
-
|
|
441
|
-
**Σκοπός**: Αποθήκευση τεχνολογικού stack έργου, αρχιτεκτονικών συμβάσεων, προδιαγραφών ανάπτυξης, προδιαγραφών δοκιμών
|
|
442
|
-
|
|
443
|
-
**Δομή Καταλόγων**:
|
|
444
|
-
```
|
|
445
|
-
knowledges/techs/{platform-id}/
|
|
446
|
-
├── tech-stack.md
|
|
447
|
-
├── architecture.md
|
|
448
|
-
├── dev-spec.md
|
|
449
|
-
├── test-spec.md
|
|
450
|
-
└── INDEX.md
|
|
451
|
-
```
|
|
452
|
-
|
|
453
|
-
**Σενάρια Χρήσης**: System Designer, System Developer, Test Manager
|
|
454
|
-
|
|
455
|
-
---
|
|
456
|
-
|
|
457
|
-
## 9. Διαχείριση Προόδου Ροής Εργασίας
|
|
458
|
-
|
|
459
|
-
Η εικονική ομάδα SpecCrew ακολουθεί αυστηρό μηχανισμό stage-gating όπου κάθε φάση πρέπει να επιβεβαιωθεί από τον χρήστη πριν προχωρήσει στην επόμενη. Υποστηρίζει επίσης επανεκκινήσιμη εκτέλεση — όταν επανεκκινείται μετά από διακοπή, συνεχίζει αυτόματα από όπου σταμάτησε.
|
|
460
|
-
|
|
461
|
-
### 9.1 Τριών Επιπέδων Αρχεία Προόδου
|
|
462
|
-
|
|
463
|
-
Η ροή εργασίας διατηρεί αυτόματα τρεις τύπους αρχείων προόδου JSON, που βρίσκονται στον κατάλογο επανάληψης:
|
|
464
|
-
|
|
465
|
-
| Αρχείο | Τοποθεσία | Σκοπός |
|
|
466
|
-
|------|----------|---------|
|
|
467
|
-
| `WORKFLOW-PROGRESS.json` | `iterations/{iter}/` | Καταγράφει την κατάσταση κάθε φάσης pipeline |
|
|
468
|
-
| `.checkpoints.json` | Κάτω από κάθε κατάλογο φάσης | Καταγράφει την κατάσταση επιβεβαίωσης checkpoint χρήστη |
|
|
469
|
-
| `DISPATCH-PROGRESS.json` | Κάτω από κάθε κατάλογο φάσης | Καταγράφει την πρόοδο ανά στοιχείο για παράλληλες εργασίες (multi-platform/multi-module) |
|
|
470
|
-
|
|
471
|
-
### 9.2 Ροή Κατάστασης Φάσης
|
|
472
|
-
|
|
473
|
-
Κάθε φάση ακολουθεί αυτή τη ροή κατάστασης:
|
|
474
|
-
|
|
475
|
-
```
|
|
476
|
-
pending → in_progress → completed → confirmed
|
|
477
|
-
```
|
|
478
|
-
|
|
479
|
-
- **pending**: Δεν έχει ξεκινήσει ακόμη
|
|
480
|
-
- **in_progress**: Σε εκτέλεση
|
|
481
|
-
- **completed**: Η εκτέλεση agent ολοκληρώθηκε, αναμονή επιβεβαίωσης χρήστη
|
|
482
|
-
- **confirmed**: Ο χρήστης επιβεβαίωσε μέσω τελικού checkpoint, η επόμενη φάση μπορεί να ξεκινήσει
|
|
483
|
-
|
|
484
|
-
### 9.3 Επανεκκινήσιμη Εκτέλεση
|
|
485
|
-
|
|
486
|
-
Κατά την επανεκκίνηση Agent για φάση:
|
|
487
|
-
|
|
488
|
-
1. **Αυτόματος έλεγχος upstream**: Επαληθεύει εάν η προηγούμενη φάση έχει επιβεβαιωθεί, μπλοκάρει και ζητά εάν όχι
|
|
489
|
-
2. **Ανάκτηση Checkpoint**: Διαβάζει `.checkpoints.json`, παρακάμπτει περασμένα checkpoints, συνεχίζει από το τελευταίο σημείο διακοπής
|
|
490
|
-
3. **Ανάκτηση Παράλληλων Εργασιών**: Διαβάζει `DISPATCH-PROGRESS.json`, επανεκτελεί μόνο εργασίες με κατάσταση `pending` ή `failed`, παρακάμπτει εργασίες `completed`
|
|
491
|
-
|
|
492
|
-
### 9.4 Προβολή Τρέχουσας Προόδου
|
|
493
|
-
|
|
494
|
-
Προβολή κατάστασης panorama pipeline μέσω Agent Team Leader:
|
|
495
|
-
|
|
496
|
-
```
|
|
497
|
-
@speccrew-team-leader προβολή τρέχουσας προόδου επανάληψης
|
|
498
|
-
```
|
|
499
|
-
|
|
500
|
-
Ο Team Leader θα διαβάσει τα αρχεία προόδου και θα εμφανίζει επισκόπηση κατάστασης παρόμοια με:
|
|
501
|
-
|
|
502
|
-
```
|
|
503
|
-
Pipeline Status: i001-user-management
|
|
504
|
-
01 PRD: ✅ Confirmed
|
|
505
|
-
02 Feature Design: 🔄 In Progress (Checkpoint A passed)
|
|
506
|
-
03 System Design: ⏳ Pending
|
|
507
|
-
04 Development: ⏳ Pending
|
|
508
|
-
05 System Test: ⏳ Pending
|
|
509
|
-
```
|
|
510
|
-
|
|
511
|
-
### 9.5 Πίσω Συμβατότητα
|
|
512
|
-
|
|
513
|
-
Ο μηχανισμός αρχείων προόδου είναι πλήρως πίσω συμβατός — εάν τα αρχεία προόδου δεν υπάρχουν (π.χ. σε legacy έργα ή νέες επαναλήψεις), όλοι οι Agents θα εκτελούνται κανονικά σύμφωνα με την αρχική λογική.
|
|
514
|
-
|
|
515
|
-
---
|
|
516
|
-
|
|
517
|
-
## 10. Συχνές Ερωτήσεις (FAQ)
|
|
518
|
-
|
|
519
|
-
### Ε1: Τι κάνω εάν ο Agent δεν λειτουργεί όπως αναμενόταν;
|
|
520
|
-
|
|
521
|
-
1. Εκτελέστε `speccrew doctor` για έλεγχο ακεραιότητας εγκατάστασης
|
|
522
|
-
2. Επιβεβαιώστε ότι η βάση γνώσης έχει αρχικοποιηθεί
|
|
523
|
-
3. Επιβεβαιώστε ότι το παράγωγο της προηγούμενης φάσης υπάρχει στον τρέχοντα κατάλογο επανάληψης
|
|
524
|
-
|
|
525
|
-
### Ε2: Πώς παραλείπω μια φάση;
|
|
526
|
-
|
|
527
|
-
**Δεν συνιστάται** — Η έξοδος κάθε φάσης είναι η είσοδος για την επόμενη φάση.
|
|
528
|
-
|
|
529
|
-
Εάν πρέπει να παραλείψετε, προετοιμάστε χειροκίνητα το έγγραφο εισόδου της αντίστοιχης φάσης και βεβαιωθείτε ότι συμμορφώνεται με τις προδιαγραφές μορφής.
|
|
530
|
-
|
|
531
|
-
### Ε3: Πώς χειρίζομαι πολλαπλές παράλληλες απαιτήσεις;
|
|
532
|
-
|
|
533
|
-
Δημιουργήστε ανεξάρτητους καταλόγους επανάληψης για κάθε απαίτηση:
|
|
534
|
-
```
|
|
535
|
-
iterations/
|
|
536
|
-
├── 001-feature-xxx/
|
|
537
|
-
├── 002-feature-yyy/
|
|
538
|
-
└── 003-feature-zzz/
|
|
539
|
-
```
|
|
540
|
-
|
|
541
|
-
Κάθε επανάληψη είναι πλήρως απομονωμένη και δεν επηρεάζει τις άλλες.
|
|
542
|
-
|
|
543
|
-
### Ε4: Πώς ενημερώνω την έκδοση SpecCrew;
|
|
544
|
-
|
|
545
|
-
Η ενημέρωση απαιτεί δύο βήματα:
|
|
546
|
-
|
|
547
|
-
```bash
|
|
548
|
-
# Βήμα 1: Ενημέρωση παγκόσμιου εργαλείου CLI
|
|
549
|
-
npm install -g speccrew@latest
|
|
550
|
-
|
|
551
|
-
# Βήμα 2: Συγχρονισμός Agents και Skills στον κατάλογο έργου σας
|
|
552
|
-
cd /path/to/your-project
|
|
553
|
-
speccrew update
|
|
554
|
-
```
|
|
555
|
-
|
|
556
|
-
- `npm install -g speccrew@latest`: Ενημερώνει το ίδιο το εργαλείο CLI (νέες εκδόσεις μπορεί να περιλαμβάνουν νέους ορισμούς Agent/Skill, διορθώσεις σφαλμάτων κ.λπ.)
|
|
557
|
-
- `speccrew update`: Συγχρονίζει τα αρχεία ορισμού Agent και Skill του έργου σας στην τελευταία έκδοση
|
|
558
|
-
- `speccrew update --ide cursor`: Ενημερώνει τη διαμόρφωση μόνο για συγκεκριμένο IDE
|
|
559
|
-
|
|
560
|
-
> **Σημείωση**: Και τα δύο βήματα απαιτούνται. Η εκτέλεση μόνο `speccrew update` δεν θα ενημερώσει το ίδιο το εργαλείο CLI· η εκτέλεση μόνο `npm install` δεν θα ενημερώσει τα αρχεία του έργου.
|
|
561
|
-
|
|
562
|
-
### Ε5: Το `speccrew update` δείχνει νέα έκδοση διαθέσιμη αλλά το `npm install -g speccrew@latest` εξακολουθεί να εγκαθιστά την παλιά έκδοση;
|
|
563
|
-
|
|
564
|
-
Αυτό συνήθως προκαλείται από την κρυφή μνήμη npm. Λύση:
|
|
565
|
-
|
|
566
|
-
```bash
|
|
567
|
-
# Εκκαθάριση κρυφής μνήμης npm και επανεγκατάσταση
|
|
568
|
-
npm cache clean --force
|
|
569
|
-
npm install -g speccrew@latest
|
|
570
|
-
|
|
571
|
-
# Επαλήθευση έκδοσης
|
|
572
|
-
npm list -g speccrew
|
|
573
|
-
```
|
|
574
|
-
|
|
575
|
-
Εάν εξακολουθεί να μην λειτουργεί, δοκιμάστε εγκατάσταση με συγκεκριμένο αριθμό έκδοσης:
|
|
576
|
-
```bash
|
|
577
|
-
npm install -g speccrew@0.5.6
|
|
578
|
-
```
|
|
579
|
-
|
|
580
|
-
### Ε6: Πώς προβάλλω ιστορικές επαναλήψεις;
|
|
581
|
-
|
|
582
|
-
Μετά την αρχειοθέτηση, προβολή σε `speccrew-workspace/iteration-archives/`, οργανωμένο ανά μορφή `{αριθμός}-{τύπος}-{όνομα}-{ημερομηνία}/`.
|
|
583
|
-
|
|
584
|
-
### Ε7: Χρειάζεται η βάση γνώσης τακτικές ενημερώσεις;
|
|
585
|
-
|
|
586
|
-
Επαναρχικοποίηση απαιτείται στις ακόλουθες καταστάσεις:
|
|
587
|
-
- Σημαντικές αλλαγές στη δομή του έργου
|
|
588
|
-
- Αναβάθμιση ή αντικατάσταση τεχνολογικού stack
|
|
589
|
-
- Προσθήκη/αφαίρεση επιχειρηματικών ενοτήτων
|
|
590
|
-
|
|
591
|
-
---
|
|
592
|
-
|
|
593
|
-
## 11. Γρήγορη Αναφορά
|
|
594
|
-
|
|
595
|
-
### Γρήγορη Αναφορά Εκκίνησης Agents
|
|
596
|
-
|
|
597
|
-
| Φάση | Agent | Συνομιλία Εκκίνησης |
|
|
598
|
-
|-------|-------|-------------------|
|
|
599
|
-
| Αρχικοποίηση | Team Leader | `@speccrew-team-leader αρχικοποίηση τεχνικής βάσης γνώσης` |
|
|
600
|
-
| Ανάλυση Απαιτήσεων | Product Manager | `@speccrew-product-manager Έχω μια νέα απαίτηση: [περιγραφή]` |
|
|
601
|
-
| Feature Design | Feature Designer | `@speccrew-feature-designer έναρξη feature design` |
|
|
602
|
-
| System Design | System Designer | `@speccrew-system-designer έναρξη system design` |
|
|
603
|
-
| Ανάπτυξη | System Developer | `@speccrew-system-developer έναρξη ανάπτυξης` |
|
|
604
|
-
| Συστημικές Δοκιμές | Test Manager | `@speccrew-test-manager έναρξη δοκιμών` |
|
|
605
|
-
|
|
606
|
-
### Λίστα Ελέγχου Checkpoint
|
|
607
|
-
|
|
608
|
-
| Φάση | Αριθμός Checkpoint | Βασικά Στοιχεία Ελέγχου |
|
|
609
|
-
|-------|----------------------|-----------------|
|
|
610
|
-
| Ανάλυση Απαιτήσεων | 1 | Ακρίβεια απαιτήσεων, πληρότητα επιχειρηματικών κανόνων, μετρησιμότητα κριτηρίων αποδοχής |
|
|
611
|
-
| Feature Design | 1 | Κάλυψη σεναρίων, σαφήνεια αλληλεπίδρασης, πληρότητα δεδομένων, διαχείριση εξαιρέσεων |
|
|
612
|
-
| System Design | 2 | A: Αξιολόγηση framework; B: Σύνταξη ψευδοκώδικα, δια-πλατφορμική συνέπεια, διαχείριση σφαλμάτων |
|
|
613
|
-
| Ανάπτυξη | 1 | A: Ετοιμότητα περιβάλλοντος, προβλήματα ενσωμάτωσης, προδιαγραφές κώδικα |
|
|
614
|
-
| Συστημικές Δοκιμές | 2 | A: Κάλυψη περιπτώσεων; B: Εκτελεσιμότητα κώδικα δοκιμής |
|
|
615
|
-
|
|
616
|
-
### Γρήγορη Αναφορά Διαδρομών Παραγώγων
|
|
617
|
-
|
|
618
|
-
| Φάση | Κατάλογος Εξόδου | Μορφή Αρχείου |
|
|
619
|
-
|-------|-----------------|-------------|
|
|
620
|
-
| Ανάλυση Απαιτήσεων | `iterations/{iter}/01.product-requirement/` | `[name]-prd.md`, `[name]-bizs-modeling.md` |
|
|
621
|
-
| Feature Design | `iterations/{iter}/02.feature-design/` | `[name]-feature-spec.md` |
|
|
622
|
-
| System Design | `iterations/{iter}/03.system-design/` | `DESIGN-OVERVIEW.md`, `{platform}/INDEX.md`, `{platform}/{module}-design.md` |
|
|
623
|
-
| Ανάπτυξη | `iterations/{iter}/04.development/` | Πηγαίος κώδικας + `delivery-report.md` |
|
|
624
|
-
| Συστημικές Δοκιμές | `iterations/{iter}/05.system-test/` | `cases/`, `code/`, `reports/`, `bugs/` |
|
|
625
|
-
| Αρχειοθέτηση | `iteration-archives/{iter}-{date}/` | Πλήρες αντίγραφο επανάληψης |
|
|
626
|
-
|
|
627
|
-
---
|
|
628
|
-
|
|
629
|
-
## Επόμενα Βήματα
|
|
630
|
-
|
|
631
|
-
1. Εκτελέστε `speccrew init --ide qoder` για αρχικοποίηση του έργου σας
|
|
632
|
-
2. Εκτελέστε Βήμα Μηδέν: Αρχικοποίηση Βάσης Γνώσης
|
|
633
|
-
3. Προχωρήστε φάση ανά φάση σύμφωνα με τη ροή εργασίας, απολαύστε την εμπειρία ανάπτυξης βάσει προδιαγραφών!
|