speccrew 0.1.1 → 0.1.2
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.ar.md +98 -91
- package/README.bn.md +122 -0
- package/README.bs.md +321 -0
- package/README.da.md +321 -0
- package/README.de.md +321 -0
- package/README.el.md +122 -0
- package/README.en.md +92 -85
- package/README.es.md +96 -89
- package/README.fr.md +321 -0
- package/README.it.md +321 -0
- package/README.ja.md +321 -0
- package/README.ko.md +321 -0
- package/README.md +92 -109
- package/README.no.md +321 -0
- package/README.pl.md +321 -0
- package/README.pt-BR.md +321 -0
- package/README.ru.md +321 -0
- package/README.th.md +239 -0
- package/README.tr.md +239 -0
- package/README.uk.md +239 -0
- package/README.vi.md +122 -0
- package/README.zh-TW.md +321 -0
- package/bin/cli.js +5 -1
- package/bin/postinstall.js +157 -0
- package/docs/GETTING-STARTED.ar.md +452 -0
- package/docs/GETTING-STARTED.bn.md +449 -0
- package/docs/GETTING-STARTED.bs.md +449 -0
- package/docs/GETTING-STARTED.da.md +448 -0
- package/docs/GETTING-STARTED.de.md +448 -0
- package/docs/GETTING-STARTED.el.md +449 -0
- package/docs/GETTING-STARTED.en.md +448 -0
- package/docs/GETTING-STARTED.es.md +448 -0
- package/docs/GETTING-STARTED.fr.md +448 -0
- package/docs/GETTING-STARTED.it.md +448 -0
- package/docs/GETTING-STARTED.ja.md +448 -0
- package/docs/GETTING-STARTED.ko.md +448 -0
- package/docs/GETTING-STARTED.md +448 -0
- package/docs/GETTING-STARTED.no.md +449 -0
- package/docs/GETTING-STARTED.pl.md +449 -0
- package/docs/GETTING-STARTED.pt-BR.md +449 -0
- package/docs/GETTING-STARTED.ru.md +449 -0
- package/docs/GETTING-STARTED.th.md +449 -0
- package/docs/GETTING-STARTED.tr.md +449 -0
- package/docs/GETTING-STARTED.uk.md +449 -0
- package/docs/GETTING-STARTED.vi.md +449 -0
- package/docs/GETTING-STARTED.zh-TW.md +448 -0
- package/lib/commands/init.js +238 -41
- package/lib/commands/uninstall.js +150 -32
- package/lib/commands/update.js +159 -24
- package/lib/ide-adapters.js +257 -3
- package/lib/utils.js +23 -7
- package/package.json +7 -2
|
@@ -0,0 +1,449 @@
|
|
|
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
|
+
<a href="./GETTING-STARTED.el.md">Ελληνικά</a>
|
|
16
|
+
</p>
|
|
17
|
+
|
|
18
|
+
Αυτό το έγγραφο σας βοηθά να κατανοήσετε γρήγορα πώς να χρησιμοποιήσετε την ομάδα Agent του SpecCrew για να ολοκληρώσετε τον πλήρη κύκλο ανάπτυξης από τις απαιτήσεις έως την παράδοση, ακολουθώντας τυπικές διαδικασίες μηχανικής.
|
|
19
|
+
|
|
20
|
+
---
|
|
21
|
+
|
|
22
|
+
## 1. Προαπαιτούμενα
|
|
23
|
+
|
|
24
|
+
### Εγκατάσταση SpecCrew
|
|
25
|
+
|
|
26
|
+
```bash
|
|
27
|
+
npm install -g speccrew
|
|
28
|
+
```
|
|
29
|
+
|
|
30
|
+
### Αρχικοποίηση Έργου
|
|
31
|
+
|
|
32
|
+
```bash
|
|
33
|
+
speccrew init --ide qoder
|
|
34
|
+
```
|
|
35
|
+
|
|
36
|
+
Υποστηριζόμενα IDE: `qoder`, `cursor`, `claude`, `codex`
|
|
37
|
+
|
|
38
|
+
### Δομή Καταλόγων Μετά την Αρχικοποίηση
|
|
39
|
+
|
|
40
|
+
```
|
|
41
|
+
.
|
|
42
|
+
├── .qoder/
|
|
43
|
+
│ ├── agents/ # Αρχεία ορισμού Agent
|
|
44
|
+
│ └── skills/ # Αρχεία ορισμού Skill
|
|
45
|
+
├── speccrew-workspace/ # Χώρος εργασίας
|
|
46
|
+
│ ├── docs/ # Διαμορφώσεις, κανόνες, πρότυπα, λύσεις
|
|
47
|
+
│ ├── iterations/ # Τρέχουσες επαναλήψεις
|
|
48
|
+
│ ├── iteration-archives/ # Αρχειοθετημένες επαναλήψεις
|
|
49
|
+
│ └── knowledges/ # Βάση γνώσεων
|
|
50
|
+
│ ├── base/ # Βασικές πληροφορίες (διαγνωστικές αναφορές, τεχνικά χρέη)
|
|
51
|
+
│ ├── bizs/ # Επιχειρησιακή βάση γνώσεων
|
|
52
|
+
│ └── techs/ # Τεχνική βάση γνώσεων
|
|
53
|
+
```
|
|
54
|
+
|
|
55
|
+
### Αναφορά Εντολών CLI
|
|
56
|
+
|
|
57
|
+
| Εντολή | Περιγραφή |
|
|
58
|
+
|---------|-------------|
|
|
59
|
+
| `speccrew list` | Λίστα όλων των διαθέσιμων Agent και Skill |
|
|
60
|
+
| `speccrew doctor` | Έλεγχος ακεραιότητας εγκατάστασης |
|
|
61
|
+
| `speccrew update` | Ενημέρωση διαμόρφωσης έργου στην τελευταία έκδοση |
|
|
62
|
+
| `speccrew uninstall` | Απεγκατάσταση SpecCrew |
|
|
63
|
+
|
|
64
|
+
---
|
|
65
|
+
|
|
66
|
+
## 2. Επισκόπηση Ροής Εργασίας
|
|
67
|
+
|
|
68
|
+
### Πλήρες Διάγραμμα Ροής
|
|
69
|
+
|
|
70
|
+
```mermaid
|
|
71
|
+
flowchart LR
|
|
72
|
+
PRD[Φάση 1<br/>Ανάλυση Απαιτήσεων<br/>Product Manager] --> FD[Φάση 2<br/>Σχεδιασμός Χαρακτηριστικών<br/>Feature Designer]
|
|
73
|
+
FD --> SD[Φάση 3<br/>Σχεδιασμός Συστήματος<br/>System Designer]
|
|
74
|
+
SD --> DEV[Φάση 4<br/>Ανάπτυξη<br/>System Developer]
|
|
75
|
+
DEV --> TEST[Φάση 5<br/>Δοκιμή Συστήματος<br/>Test Manager]
|
|
76
|
+
TEST --> ARCHIVE[Φάση 6<br/>Αρχειοθέτηση]
|
|
77
|
+
|
|
78
|
+
KB[(Βάση Γνώσεων<br/>Σε Όλη τη Διαδικασία)] -.-> PRD
|
|
79
|
+
KB -.-> FD
|
|
80
|
+
KB -.-> SD
|
|
81
|
+
KB -.-> DEV
|
|
82
|
+
KB -.-> TEST
|
|
83
|
+
```
|
|
84
|
+
|
|
85
|
+
### Βασικές Αρχές
|
|
86
|
+
|
|
87
|
+
1. **Εξαρτήσεις Φάσεων**: Η έξοδος κάθε φάσης είναι η είσοδος για την επόμενη φάση
|
|
88
|
+
2. **Επιβεβαίωση Σημείου Ελέγχου**: Κάθε φάση έχει ένα σημείο επιβεβαίωσης που απαιτεί έγκριση χρήστη πριν συνεχίσει
|
|
89
|
+
3. **Οδηγούμενη από Βάση Γνώσεων**: Η βάση γνώσεων διατρέχει όλη τη διαδικασία, παρέχοντας контекστό για όλες τις φάσεις
|
|
90
|
+
|
|
91
|
+
---
|
|
92
|
+
|
|
93
|
+
## 3. Μηδενικό Βήμα: Διάγνωση Έργου και Αρχικοποίηση Βάσης Γνώσεων
|
|
94
|
+
|
|
95
|
+
Πριν ξεκινήσετε την επίσημη διαδικασία μηχανικής, πρέπει να αρχικοποιήσετε τη βάση γνώσεων του έργου.
|
|
96
|
+
|
|
97
|
+
### 3.1 Διάγνωση Έργου
|
|
98
|
+
|
|
99
|
+
**Παράδειγμα Διαλόγου**:
|
|
100
|
+
```
|
|
101
|
+
@speccrew-team-leader διάγνωση έργου
|
|
102
|
+
```
|
|
103
|
+
|
|
104
|
+
**Τι θα Κάνει ο Agent**:
|
|
105
|
+
- Σάρωση δομής έργου
|
|
106
|
+
- Ανίχνευση τεχνολογικής στοίβας
|
|
107
|
+
- Αναγνώριση επιχειρησιακών μονάδων
|
|
108
|
+
|
|
109
|
+
**Παραδοτέο**:
|
|
110
|
+
```
|
|
111
|
+
speccrew-workspace/knowledges/base/diagnosis-reports/diagnosis-report-{date}.md
|
|
112
|
+
```
|
|
113
|
+
|
|
114
|
+
### 3.2 Αρχικοποίηση Τεχνικής Βάσης Γνώσεων
|
|
115
|
+
|
|
116
|
+
**Παράδειγμα Διαλόγου**:
|
|
117
|
+
```
|
|
118
|
+
@speccrew-team-leader αρχικοποίηση τεχνικής βάσης γνώσεων
|
|
119
|
+
```
|
|
120
|
+
|
|
121
|
+
**Τριφασική Διαδικασία**:
|
|
122
|
+
1. Ανίχνευση Πλατφόρμας — Αναγνώριση τεχνολογικών πλατφορμών στο έργο
|
|
123
|
+
2. Δημιουργία Τεχνικής Τεκμηρίωσης — Δημιουργία εγγράφων τεχνικών προδιαγραφών για κάθε πλατφόρμα
|
|
124
|
+
3. Δημιουργία Ευρετηρίου — Δημιουργία ευρετηρίου βάσης γνώσεων
|
|
125
|
+
|
|
126
|
+
**Παραδοτέο**:
|
|
127
|
+
```
|
|
128
|
+
speccrew-workspace/knowledges/techs/{platform-id}/
|
|
129
|
+
├── tech-stack.md # Ορισμός τεχνολογικής στοίβας
|
|
130
|
+
├── architecture.md # Συμβάσεις αρχιτεκτονικής
|
|
131
|
+
├── dev-spec.md # Προδιαγραφές ανάπτυξης
|
|
132
|
+
├── test-spec.md # Προδιαγραφές δοκιμής
|
|
133
|
+
└── INDEX.md # Αρχείο ευρετηρίου
|
|
134
|
+
```
|
|
135
|
+
|
|
136
|
+
### 3.3 Αρχικοποίηση Επιχειρησιακής Βάσης Γνώσεων
|
|
137
|
+
|
|
138
|
+
**Παράδειγμα Διαλόγου**:
|
|
139
|
+
```
|
|
140
|
+
@speccrew-team-leader αρχικοποίηση επιχειρησιακής βάσης γνώσεων
|
|
141
|
+
```
|
|
142
|
+
|
|
143
|
+
**Τετραφασική Διαδικασία**:
|
|
144
|
+
1. Απογραφή Χαρακτηριστικών — Σάρωση κώδικα για αναγνώριση όλων των χαρακτηριστικών
|
|
145
|
+
2. Ανάλυση Χαρακτηριστικών — Ανάλυση επιχειρησιακής λογικής κάθε χαρακτηριστικού
|
|
146
|
+
3. Σύνοψη Μονάδας — Σύνοψη χαρακτηριστικών ανά μονάδα
|
|
147
|
+
4. Σύνοψη Συστήματος — Δημιουργία επιχειρησιακής επισκόπησης σε επίπεδο συστήματος
|
|
148
|
+
|
|
149
|
+
**Παραδοτέο**:
|
|
150
|
+
```
|
|
151
|
+
speccrew-workspace/knowledges/bizs/
|
|
152
|
+
├── {platform-type}/
|
|
153
|
+
│ └── {module-name}/
|
|
154
|
+
│ └── feature-spec.md
|
|
155
|
+
└── system-overview.md
|
|
156
|
+
```
|
|
157
|
+
|
|
158
|
+
---
|
|
159
|
+
|
|
160
|
+
## 4. Οδηγός Διαλόγου Φάση προς Φάση
|
|
161
|
+
|
|
162
|
+
### 4.1 Φάση 1: Ανάλυση Απαιτήσεων (Product Manager)
|
|
163
|
+
|
|
164
|
+
**Πώς να Ξεκινήσετε**:
|
|
165
|
+
```
|
|
166
|
+
@speccrew-product-manager έχω μια νέα απαίτηση: [περιγράψτε την απαίτησή σας]
|
|
167
|
+
```
|
|
168
|
+
|
|
169
|
+
**Ροή Εργασίας Agent**:
|
|
170
|
+
1. Διαβάστε την επισκόπηση συστήματος για να κατανοήσετε τις υπάρχουσες μονάδες
|
|
171
|
+
2. Αναλύστε τις απαιτήσεις χρήστη
|
|
172
|
+
3. Δημιουργήστε δομημένο έγγραφο PRD
|
|
173
|
+
|
|
174
|
+
**Παραδοτέο**:
|
|
175
|
+
```
|
|
176
|
+
iterations/{αριθμός}-{τύπος}-{όνομα}/01.product-requirement/
|
|
177
|
+
├── [feature-name]-prd.md # Έγγραφο Απαιτήσεων Προϊόντος
|
|
178
|
+
└── [feature-name]-bizs-modeling.md # Επιχειρησιακή μοντελοποίηση (για σύνθετες απαιτήσεις)
|
|
179
|
+
```
|
|
180
|
+
|
|
181
|
+
**Λίστα Ελέγχου Επιβεβαίωσης**:
|
|
182
|
+
- [ ] Η περιγραφή απαίτησης αντικατοπτρίζει με ακρίβεια την πρόθεση του χρήστη;
|
|
183
|
+
- [ ] Οι επιχειρησιακοί κανόνες είναι πλήρεις;
|
|
184
|
+
- [ ] Τα σημεία ενσωμάτωσης με υπάρχοντα συστήματα είναι ξεκάθαρα;
|
|
185
|
+
- [ ] Τα κριτήρια αποδοχής είναι μετρήσιμα;
|
|
186
|
+
|
|
187
|
+
---
|
|
188
|
+
|
|
189
|
+
### 4.2 Φάση 2: Σχεδιασμός Χαρακτηριστικών (Feature Designer)
|
|
190
|
+
|
|
191
|
+
**Πώς να Ξεκινήσετε**:
|
|
192
|
+
```
|
|
193
|
+
@speccrew-feature-designer έναρξη σχεδιασμού χαρακτηριστικών
|
|
194
|
+
```
|
|
195
|
+
|
|
196
|
+
**Ροή Εργασίας Agent**:
|
|
197
|
+
1. Εντοπίστε αυτόματα το επιβεβαιωμένο έγγραφο PRD
|
|
198
|
+
2. Φορτώστε την επιχειρησιακή βάση γνώσεων
|
|
199
|
+
3. Δημιουργήστε σχεδιασμό χαρακτηριστικών (συμπεριλαμβανομένων UI wireframes, ροών αλληλεπίδρασης, ορισμών δεδομένων, συμβολαίων API)
|
|
200
|
+
4. Για πολλαπλά PRD, χρησιμοποιήστε Task Worker για παράλληλο σχεδιασμό
|
|
201
|
+
|
|
202
|
+
**Παραδοτέο**:
|
|
203
|
+
```
|
|
204
|
+
iterations/{iter}/02.feature-design/
|
|
205
|
+
└── [feature-name]-feature-spec.md # Έγγραφο σχεδιασμού χαρακτηριστικών
|
|
206
|
+
```
|
|
207
|
+
|
|
208
|
+
**Λίστα Ελέγχου Επιβεβαίωσης**:
|
|
209
|
+
- [ ] Όλα τα σενάρια χρήστη καλύπτονται;
|
|
210
|
+
- [ ] Οι ροές αλληλεπίδρασης είναι ξεκάθαρες;
|
|
211
|
+
- [ ] Οι ορισμοί πεδίων δεδομένων είναι πλήρεις;
|
|
212
|
+
- [ ] Ο χειρισμός εξαιρέσεων είναι περιεκτικός;
|
|
213
|
+
|
|
214
|
+
---
|
|
215
|
+
|
|
216
|
+
### 4.3 Φάση 3: Σχεδιασμός Συστήματος (System Designer)
|
|
217
|
+
|
|
218
|
+
**Πώς να Ξεκινήσετε**:
|
|
219
|
+
```
|
|
220
|
+
@speccrew-system-designer έναρξη σχεδιασμού συστήματος
|
|
221
|
+
```
|
|
222
|
+
|
|
223
|
+
**Ροή Εργασίας Agent**:
|
|
224
|
+
1. Εντοπίστε Feature Spec και API Contract
|
|
225
|
+
2. Φορτώστε την τεχνική βάση γνώσεων (τεχνολογική στοίβα, αρχιτεκτονική, προδιαγραφές για κάθε πλατφόρμα)
|
|
226
|
+
3. **Σημείο Ελέγχου A**: Αξιολόγηση Πλαισίου — Ανάλυση τεχνικών κενών, σύσταση νέων πλαισίων (εάν χρειάζεται), αναμονή επιβεβαίωσης χρήστη
|
|
227
|
+
4. Δημιουργήστε DESIGN-OVERVIEW.md
|
|
228
|
+
5. Χρησιμοποιήστε Task Worker για παράλληλη αποστολή σχεδιασμού για κάθε πλατφόρμα (frontend/backend/mobile/desktop)
|
|
229
|
+
6. **Σημείο Ελέγχου B**: Κοινή Επιβεβαίωση — Εμφάνιση σύνοψης όλων των σχεδιασμών πλατφόρμας, αναμονή επιβεβαίωσης χρήστη
|
|
230
|
+
|
|
231
|
+
**Παραδοτέο**:
|
|
232
|
+
```
|
|
233
|
+
iterations/{iter}/03.system-design/
|
|
234
|
+
├── DESIGN-OVERVIEW.md # Επισκόπηση σχεδιασμού
|
|
235
|
+
├── {platform-id}/
|
|
236
|
+
│ ├── INDEX.md # Ευρετήριο σχεδιασμού πλατφόρμας
|
|
237
|
+
│ └── {module}-design.md # Σχεδιασμός μονάδας σε επίπεδο ψευδοκώδικα
|
|
238
|
+
```
|
|
239
|
+
|
|
240
|
+
**Λίστα Ελέγχου Επιβεβαίωσης**:
|
|
241
|
+
- [ ] Ο ψευδοκώδικας χρησιμοποιεί πραγματική σύνταξη πλαισίου;
|
|
242
|
+
- [ ] Τα διαπλατφορμικά συμβόλαια API είναι συνεπή;
|
|
243
|
+
- [ ] Η στρατηγική χειρισμού σφαλμάτων είναι ενοποιημένη;
|
|
244
|
+
|
|
245
|
+
---
|
|
246
|
+
|
|
247
|
+
### 4.4 Φάση 4: Υλοποίηση Ανάπτυξης (System Developer)
|
|
248
|
+
|
|
249
|
+
**Πώς να Ξεκινήσετε**:
|
|
250
|
+
```
|
|
251
|
+
@speccrew-system-developer έναρξη ανάπτυξης
|
|
252
|
+
```
|
|
253
|
+
|
|
254
|
+
**Ροή Εργασίας Agent**:
|
|
255
|
+
1. Διαβάστε τα έγγραφα σχεδιασμού συστήματος
|
|
256
|
+
2. Φορτώστε τεχνικές γνώσεις για κάθε πλατφόρμα
|
|
257
|
+
3. **Σημείο Ελέγχου A**: Προ-Επαλήθευση Περιβάλλοντος — Επαλήθευση εκδόσεων runtime, εξαρτήσεων, διαθεσιμότητας υπηρεσιών; εάν αποτύχει, αναμονή επίλυσης χρήστη
|
|
258
|
+
4. Χρησιμοποιήστε Task Worker για παράλληλη αποστολή ανάπτυξης για κάθε πλατφόρμα
|
|
259
|
+
5. Επαλήθευση ενσωμάτωσης: Στοίχιση συμβολαίων API, συνέπεια δεδομένων
|
|
260
|
+
6. Έξοδος αναφοράς παράδοσης
|
|
261
|
+
|
|
262
|
+
**Παραδοτέο**:
|
|
263
|
+
```
|
|
264
|
+
# Ο πηγαίος κώδικας γράφεται στον πραγματικό κατάλογο πηγαίου κώδικα του έργου
|
|
265
|
+
iterations/{iter}/04.development/
|
|
266
|
+
├── {platform-id}/
|
|
267
|
+
│ └── tasks/ # Αρχεία εργασιών ανάπτυξης
|
|
268
|
+
└── delivery-report.md
|
|
269
|
+
```
|
|
270
|
+
|
|
271
|
+
**Λίστα Ελέγχου Επιβεβαίωσης**:
|
|
272
|
+
- [ ] Το περιβάλλον είναι έτοιμο;
|
|
273
|
+
- [ ] Τα προβλήματα ενσωμάτωσης είναι σε αποδεκτό εύρος;
|
|
274
|
+
- [ ] Ο κώδικας συμμορφώνεται με τις προδιαγραφές ανάπτυξης;
|
|
275
|
+
|
|
276
|
+
---
|
|
277
|
+
|
|
278
|
+
### 4.5 Φάση 5: Δοκιμή Συστήματος (Test Manager)
|
|
279
|
+
|
|
280
|
+
**Πώς να Ξεκινήσετε**:
|
|
281
|
+
```
|
|
282
|
+
@speccrew-test-manager έναρξη δοκιμής
|
|
283
|
+
```
|
|
284
|
+
|
|
285
|
+
**Τριφασική Διαδικασία Δοκιμής**:
|
|
286
|
+
|
|
287
|
+
| Φάση | Περιγραφή | Σημείο Ελέγχου |
|
|
288
|
+
|------|----------|-------------------|
|
|
289
|
+
| Σχεδιασμός Περιπτώσεων Δοκιμής | Δημιουργία περιπτώσεων δοκιμής βάσει PRD και Feature Spec | A: Εμφάνιση στατιστικών κάλυψης περιπτώσεων και πίνακα ιχνηλασιμότητας, αναμονή επιβεβαίωσης χρήστη επαρκούς κάλυψης |
|
|
290
|
+
| Δημιουργία Κώδικα Δοκιμής | Δημιουργία εκτελέσιμου κώδικα δοκιμής | B: Εμφάνιση δημιουργημένων αρχείων δοκιμής και αντιστοίχισης περιπτώσεων, αναμονή επιβεβαίωσης χρήστη |
|
|
291
|
+
| Εκτέλεση Δοκιμής και Αναφορά Σφαλμάτων | Αυτόματη εκτέλεση δοκιμών και δημιουργία αναφορών | Κανένα (αυτόματη εκτέλεση) |
|
|
292
|
+
|
|
293
|
+
**Παραδοτέο**:
|
|
294
|
+
```
|
|
295
|
+
iterations/{iter}/05.system-test/
|
|
296
|
+
├── cases/
|
|
297
|
+
│ └── {platform-id}/ # Έγγραφα περιπτώσεων δοκιμής
|
|
298
|
+
├── code/
|
|
299
|
+
│ └── {platform-id}/ # Σχέδιο κώδικα δοκιμής
|
|
300
|
+
├── reports/
|
|
301
|
+
│ └── test-report-{date}.md # Αναφορά δοκιμής
|
|
302
|
+
└── bugs/
|
|
303
|
+
└── BUG-{id}-{title}.md # Αναφορές σφαλμάτων (ένα αρχείο ανά σφάλμα)
|
|
304
|
+
```
|
|
305
|
+
|
|
306
|
+
**Λίστα Ελέγχου Επιβεβαίωσης**:
|
|
307
|
+
- [ ] Η κάλυψη περιπτώσεων είναι πλήρης;
|
|
308
|
+
- [ ] Ο κώδικας δοκιμής είναι εκτελέσιμος;
|
|
309
|
+
- [ ] Η αξιολόγηση σοβαρότητας σφαλμάτων είναι ακριβής;
|
|
310
|
+
|
|
311
|
+
---
|
|
312
|
+
|
|
313
|
+
### 4.6 Φάση 6: Αρχειοθέτηση
|
|
314
|
+
|
|
315
|
+
Οι επαναλήψεις αρχειοθετούνται αυτόματα όταν ολοκληρωθούν:
|
|
316
|
+
|
|
317
|
+
```
|
|
318
|
+
speccrew-workspace/iteration-archives/
|
|
319
|
+
└── {αριθμός}-{τύπος}-{όνομα}-{ημερομηνία}/
|
|
320
|
+
├── 01.product-requirement/
|
|
321
|
+
├── 02.feature-design/
|
|
322
|
+
├── 03.system-design/
|
|
323
|
+
├── 04.development/
|
|
324
|
+
└── 05.system-test/
|
|
325
|
+
```
|
|
326
|
+
|
|
327
|
+
---
|
|
328
|
+
|
|
329
|
+
## 5. Επισκόπηση Βάσης Γνώσεων
|
|
330
|
+
|
|
331
|
+
### 5.1 Επιχειρησιακή Βάση Γνώσεων (bizs)
|
|
332
|
+
|
|
333
|
+
**Σκοπός**: Αποθήκευση περιγραφών επιχειρησιακών λειτουργιών έργου, διαιρέσεων μονάδων, χαρακτηριστικών API
|
|
334
|
+
|
|
335
|
+
**Δομή Καταλόγων**:
|
|
336
|
+
```
|
|
337
|
+
knowledges/bizs/
|
|
338
|
+
├── {platform-type}/
|
|
339
|
+
│ └── {module-name}/
|
|
340
|
+
│ └── feature-spec.md
|
|
341
|
+
└── system-overview.md
|
|
342
|
+
```
|
|
343
|
+
|
|
344
|
+
**Σενάρια Χρήσης**: Product Manager, Feature Designer
|
|
345
|
+
|
|
346
|
+
### 5.2 Τεχνική Βάση Γνώσεων (techs)
|
|
347
|
+
|
|
348
|
+
**Σκοπός**: Αποθήκευση τεχνολογικής στοίβας έργου, συμβάσεων αρχιτεκτονικής, προδιαγραφών ανάπτυξης, προδιαγραφών δοκιμής
|
|
349
|
+
|
|
350
|
+
**Δομή Καταλόγων**:
|
|
351
|
+
```
|
|
352
|
+
knowledges/techs/{platform-id}/
|
|
353
|
+
├── tech-stack.md
|
|
354
|
+
├── architecture.md
|
|
355
|
+
├── dev-spec.md
|
|
356
|
+
├── test-spec.md
|
|
357
|
+
└── INDEX.md
|
|
358
|
+
```
|
|
359
|
+
|
|
360
|
+
**Σενάρια Χρήσης**: System Designer, System Developer, Test Manager
|
|
361
|
+
|
|
362
|
+
---
|
|
363
|
+
|
|
364
|
+
## 6. Συχνές Ερωτήσεις (FAQ)
|
|
365
|
+
|
|
366
|
+
### Ε1: Τι να κάνω αν ο Agent δεν λειτουργεί όπως αναμένεται;
|
|
367
|
+
|
|
368
|
+
1. Εκτελέστε `speccrew doctor` για να ελέγξετε την ακεραιότητα της εγκατάστασης
|
|
369
|
+
2. Επιβεβαιώστε ότι η βάση γνώσεων έχει αρχικοποιηθεί
|
|
370
|
+
3. Επιβεβαιώστε ότι το παραδοτέο της προηγούμενης φάσης υπάρχει στον τρέχοντα κατάλογο επανάληψης
|
|
371
|
+
|
|
372
|
+
### Ε2: Πώς να παραλείψω μια φάση;
|
|
373
|
+
|
|
374
|
+
**Δεν συνιστάται** — Η έξοδος κάθε φάσης είναι η είσοδος για την επόμενη φάση.
|
|
375
|
+
|
|
376
|
+
Εάν πρέπει να παραλείψετε, προετοιμάστε χειροκίνητα το έγγραφο εισόδου της αντίστοιχης φάσης και βεβαιωθείτε ότι συμμορφώνεται με τις προδιαγραφές μορφής.
|
|
377
|
+
|
|
378
|
+
### Ε3: Πώς να χειριστώ πολλαπλές παράλληλες απαιτήσεις;
|
|
379
|
+
|
|
380
|
+
Δημιουργήστε ανεξάρτητους καταλόγους επανάληψης για κάθε απαίτηση:
|
|
381
|
+
```
|
|
382
|
+
iterations/
|
|
383
|
+
├── 001-feature-xxx/
|
|
384
|
+
├── 002-feature-yyy/
|
|
385
|
+
└── 003-feature-zzz/
|
|
386
|
+
```
|
|
387
|
+
|
|
388
|
+
Κάθε επανάληψη είναι πλήρως απομονωμένη και δεν επηρεάζει τις άλλες.
|
|
389
|
+
|
|
390
|
+
### Ε4: Πώς να ενημερώσω την έκδοση SpecCrew;
|
|
391
|
+
|
|
392
|
+
- **Καθολική Ενημέρωση**: `npm update -g speccrew`
|
|
393
|
+
- **Ενημέρωση Έργου**: Εκτελέστε `speccrew update` στον κατάλογο του έργου
|
|
394
|
+
|
|
395
|
+
### Ε5: Πώς να δω ιστορικές επαναλήψεις;
|
|
396
|
+
|
|
397
|
+
Μετά την αρχειοθέτηση, δείτε στο `speccrew-workspace/iteration-archives/`, οργανωμένο σε μορφή `{αριθμός}-{τύπος}-{όνομα}-{ημερομηνία}/`.
|
|
398
|
+
|
|
399
|
+
### Ε6: Η βάση γνώσεων χρειάζεται τακτική ενημέρωση;
|
|
400
|
+
|
|
401
|
+
Απαιτείται επανεκκίνηση στις ακόλουθες καταστάσεις:
|
|
402
|
+
- Σημαντικές αλλαγές στη δομή του έργου
|
|
403
|
+
- Ενημέρωση ή αντικατάσταση τεχνολογικής στοίβας
|
|
404
|
+
- Προσθήκη/αφαίρεση επιχειρησιακών μονάδων
|
|
405
|
+
|
|
406
|
+
---
|
|
407
|
+
|
|
408
|
+
## 7. Γρήγορη Αναφορά
|
|
409
|
+
|
|
410
|
+
### Γρήγορη Αναφορά Εκκίνησης Agent
|
|
411
|
+
|
|
412
|
+
| Φάση | Agent | Διάλογος Εκκίνησης |
|
|
413
|
+
|------|-------|-------------------|
|
|
414
|
+
| Διάγνωση | Team Leader | `@speccrew-team-leader διάγνωση έργου` |
|
|
415
|
+
| Αρχικοποίηση | Team Leader | `@speccrew-team-leader αρχικοποίηση τεχνικής βάσης γνώσεων` |
|
|
416
|
+
| Ανάλυση Απαιτήσεων | Product Manager | `@speccrew-product-manager έχω μια νέα απαίτηση: [περιγραφή]` |
|
|
417
|
+
| Σχεδιασμός Χαρακτηριστικών | Feature Designer | `@speccrew-feature-designer έναρξη σχεδιασμού χαρακτηριστικών` |
|
|
418
|
+
| Σχεδιασμός Συστήματος | System Designer | `@speccrew-system-designer έναρξη σχεδιασμού συστήματος` |
|
|
419
|
+
| Ανάπτυξη | System Developer | `@speccrew-system-developer έναρξη ανάπτυξης` |
|
|
420
|
+
| Δοκιμή Συστήματος | Test Manager | `@speccrew-test-manager έναρξη δοκιμής` |
|
|
421
|
+
|
|
422
|
+
### Λίστα Ελέγχου Σημείων Ελέγχου
|
|
423
|
+
|
|
424
|
+
| Φάση | Αριθμός Σημείων Ελέγχου | Βασικά Στοιχεία Επαλήθευσης |
|
|
425
|
+
|------|------------------------|------------------------|
|
|
426
|
+
| Ανάλυση Απαιτήσεων | 1 | Ακρίβεια απαίτησης, πληρότητα επιχειρησιακών κανόνων, μετρησιμότητα κριτηρίων αποδοχής |
|
|
427
|
+
| Σχεδιασμός Χαρακτηριστικών | 1 | Κάλυψη σεναρίων, σαφήνεια αλληλεπίδρασης, πληρότητα δεδομένων, χειρισμός εξαιρέσεων |
|
|
428
|
+
| Σχεδιασμός Συστήματος | 2 | A: Αξιολόγηση πλαισίου; B: Σύνταξη ψευδοκώδικα, διαπλατφορμική συνέπεια, χειρισμός σφαλμάτων |
|
|
429
|
+
| Ανάπτυξη | 1 | A: Ετοιμότητα περιβάλλοντος, προβλήματα ενσωμάτωσης, προδιαγραφές κώδικα |
|
|
430
|
+
| Δοκιμή Συστήματος | 2 | A: Κάλυψη περιπτώσεων; B: Εκτελεσιμότητα κώδικα δοκιμής |
|
|
431
|
+
|
|
432
|
+
### Γρήγορη Αναφορά Διαδρομών Παραδοτέων
|
|
433
|
+
|
|
434
|
+
| Φάση | Κατάλογος Εξόδου | Μορφή Αρχείου |
|
|
435
|
+
|------|------------------|-------------|
|
|
436
|
+
| Ανάλυση Απαιτήσεων | `iterations/{iter}/01.product-requirement/` | `[name]-prd.md`, `[name]-bizs-modeling.md` |
|
|
437
|
+
| Σχεδιασμός Χαρακτηριστικών | `iterations/{iter}/02.feature-design/` | `[name]-feature-spec.md` |
|
|
438
|
+
| Σχεδιασμός Συστήματος | `iterations/{iter}/03.system-design/` | `DESIGN-OVERVIEW.md`, `{platform}/INDEX.md`, `{platform}/{module}-design.md` |
|
|
439
|
+
| Ανάπτυξη | `iterations/{iter}/04.development/` | Πηγαίος κώδικας + `delivery-report.md` |
|
|
440
|
+
| Δοκιμή Συστήματος | `iterations/{iter}/05.system-test/` | `cases/`, `code/`, `reports/`, `bugs/` |
|
|
441
|
+
| Αρχειοθέτηση | `iteration-archives/{iter}-{ημερομηνία}/` | Πλήρες αντίγραφο επανάληψης |
|
|
442
|
+
|
|
443
|
+
---
|
|
444
|
+
|
|
445
|
+
## Επόμενα Βήματα
|
|
446
|
+
|
|
447
|
+
1. Εκτελέστε `speccrew init --ide qoder` για να αρχικοποιήσετε το έργο σας
|
|
448
|
+
2. Εκτελέστε το Μηδενικό Βήμα: Διάγνωση Έργου και Αρχικοποίηση Βάσης Γνώσεων
|
|
449
|
+
3. Προχωρήστε μέσα από κάθε φάση ακολουθώντας τη ροή εργασίας, απολαμβάνοντας την εμπειρία ανάπτυξης που καθοδηγείται από προδιαγραφές!
|