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,597 +0,0 @@
|
|
|
1
|
-
# SpecCrew - Przewodnik Szybkiego Startu
|
|
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
|
-
Ten dokument pomaga szybko zrozumieć, jak korzystać z zespołu Agentów SpecCrew do ukończenia kompletnego rozwoju od wymagań do dostarczenia zgodnie ze standardowymi procesami inżynieryjnymi.
|
|
18
|
-
|
|
19
|
-
---
|
|
20
|
-
|
|
21
|
-
## 1. Wymagania wstępne
|
|
22
|
-
|
|
23
|
-
### Instalacja SpecCrew
|
|
24
|
-
|
|
25
|
-
```bash
|
|
26
|
-
npm install -g speccrew
|
|
27
|
-
```
|
|
28
|
-
|
|
29
|
-
### Inicjalizacja projektu
|
|
30
|
-
|
|
31
|
-
```bash
|
|
32
|
-
speccrew init --ide qoder
|
|
33
|
-
```
|
|
34
|
-
|
|
35
|
-
Obsługiwane IDE: `qoder`, `cursor`, `claude`, `codex`
|
|
36
|
-
|
|
37
|
-
### Struktura katalogów po inicjalizacji
|
|
38
|
-
|
|
39
|
-
```
|
|
40
|
-
.
|
|
41
|
-
├── .qoder/
|
|
42
|
-
│ ├── agents/ # Pliki definicji Agentów
|
|
43
|
-
│ └── skills/ # Pliki definicji Skills
|
|
44
|
-
├── speccrew-workspace/ # Przestrzeń robocza
|
|
45
|
-
│ ├── docs/ # Konfiguracje, zasady, szablony, rozwiązania
|
|
46
|
-
│ ├── iterations/ # Bieżące iteracje
|
|
47
|
-
│ ├── iteration-archives/ # Zarchiwizowane iteracje
|
|
48
|
-
│ └── knowledges/ # Baza wiedzy
|
|
49
|
-
│ ├── base/ # Podstawowe informacje (raporty diagnostyczne, długi techniczne)
|
|
50
|
-
│ ├── bizs/ # Baza wiedzy biznesowej
|
|
51
|
-
│ └── techs/ # Baza wiedzy technicznej
|
|
52
|
-
```
|
|
53
|
-
|
|
54
|
-
### Szybki podgląd poleceń CLI
|
|
55
|
-
|
|
56
|
-
| Polecenie | Opis |
|
|
57
|
-
|------|------|
|
|
58
|
-
| `speccrew list` | Wyświetl wszystkich dostępnych Agentów i Skills |
|
|
59
|
-
| `speccrew doctor` | Sprawdź integralność instalacji |
|
|
60
|
-
| `speccrew update` | Aktualizuj konfigurację projektu do najnowszej wersji |
|
|
61
|
-
| `speccrew uninstall` | Odinstaluj SpecCrew |
|
|
62
|
-
|
|
63
|
-
---
|
|
64
|
-
|
|
65
|
-
## 2. Szybki start w 5 minut po instalacji
|
|
66
|
-
|
|
67
|
-
Po wykonaniu `speccrew init`, postępuj zgodnie z tymi krokami, aby szybko przejść do stanu pracy:
|
|
68
|
-
|
|
69
|
-
### Krok 1: Wybierz swoje IDE
|
|
70
|
-
|
|
71
|
-
| IDE | Polecenie inicjalizacji | Scenariusz zastosowania |
|
|
72
|
-
|-----|-----------|----------|
|
|
73
|
-
| **Qoder** (Zalecane) | `speccrew init --ide qoder` | Pełna orkiestracja agentów, równoległe workery |
|
|
74
|
-
| **Cursor** | `speccrew init --ide cursor` | Workflows oparte na Composer |
|
|
75
|
-
| **Claude Code** | `speccrew init --ide claude` | Rozwój CLI-first |
|
|
76
|
-
| **Codex** | `speccrew init --ide codex` | Integracja ekosystemu OpenAI |
|
|
77
|
-
|
|
78
|
-
### Krok 2: Inicjalizacja bazy wiedzy (Zalecane)
|
|
79
|
-
|
|
80
|
-
W przypadku projektów z istniejącym kodem źródłowym zaleca się najpierw zainicjowanie bazy wiedzy, aby agenci zrozumieli Twoją bazę kodu:
|
|
81
|
-
|
|
82
|
-
```
|
|
83
|
-
@speccrew-team-leader zainicjuj techniczną bazę wiedzy
|
|
84
|
-
```
|
|
85
|
-
|
|
86
|
-
Następnie:
|
|
87
|
-
|
|
88
|
-
```
|
|
89
|
-
@speccrew-team-leader zainicjuj biznesową bazę wiedzy
|
|
90
|
-
```
|
|
91
|
-
|
|
92
|
-
### Krok 3: Rozpocznij swoje pierwsze zadanie
|
|
93
|
-
|
|
94
|
-
```
|
|
95
|
-
@speccrew-product-manager Mam nowe wymaganie: [opisz swoje wymaganie funkcjonalne]
|
|
96
|
-
```
|
|
97
|
-
|
|
98
|
-
> **Wskazówka**: Jeśli nie jesteś pewien, co zrobić, po prostu powiedz `@speccrew-team-leader pomóż mi rozpocząć` — Team Leader automatycznie wykryje status projektu i Cię poprowadzi.
|
|
99
|
-
|
|
100
|
-
---
|
|
101
|
-
|
|
102
|
-
## 3. Szybkie drzewo decyzyjne
|
|
103
|
-
|
|
104
|
-
Nie jesteś pewien, co zrobić? Znajdź swój scenariusz poniżej:
|
|
105
|
-
|
|
106
|
-
- **Mam nowe wymaganie funkcjonalne**
|
|
107
|
-
→ `@speccrew-product-manager Mam nowe wymaganie: [opisz swoje wymaganie funkcjonalne]`
|
|
108
|
-
|
|
109
|
-
- **Chcę zeskanować wiedzę istniejącego projektu**
|
|
110
|
-
→ `@speccrew-team-leader zainicjuj techniczną bazę wiedzy`
|
|
111
|
-
→ Następnie: `@speccrew-team-leader zainicjuj biznesową bazę wiedzy`
|
|
112
|
-
|
|
113
|
-
- **Chcę kontynuować poprzednią pracę**
|
|
114
|
-
→ `@speccrew-team-leader jaki jest obecny postęp?`
|
|
115
|
-
|
|
116
|
-
- **Chcę sprawdzić stan zdrowia systemu**
|
|
117
|
-
→ Uruchom w terminalu: `speccrew doctor`
|
|
118
|
-
|
|
119
|
-
- **Nie jestem pewien, co zrobić**
|
|
120
|
-
→ `@speccrew-team-leader pomóż mi rozpocząć`
|
|
121
|
-
→ Team Leader automatycznie wykryje status projektu i Cię poprowadzi
|
|
122
|
-
|
|
123
|
-
---
|
|
124
|
-
|
|
125
|
-
## 4. Szybki podgląd Agentów
|
|
126
|
-
|
|
127
|
-
| Rola | Agent | Odpowiedzialności | Przykład polecenia |
|
|
128
|
-
|------|-------|-----------------|-----------------|
|
|
129
|
-
| Lider zespołu | `@speccrew-team-leader` | Nawigacja projektu, inicjalizacja bazy wiedzy, sprawdzanie statusu | "Pomóż mi rozpocząć" |
|
|
130
|
-
| Kierownik produktu | `@speccrew-product-manager` | Analiza wymagań, generowanie PRD | "Mam nowe wymaganie: ..." |
|
|
131
|
-
| Projektant funkcji | `@speccrew-feature-designer` | Analiza funkcji, projektowanie specyfikacji, kontrakty API | "Rozpocznij projektowanie funkcji dla iteracji X" |
|
|
132
|
-
| Projektant systemu | `@speccrew-system-designer` | Projektowanie architektury, szczegółowe projektowanie platformy | "Rozpocznij projektowanie systemu dla iteracji X" |
|
|
133
|
-
| Deweloper systemu | `@speccrew-system-developer` | Koordynacja rozwoju, generowanie kodu | "Rozpocznij rozwój dla iteracji X" |
|
|
134
|
-
| Kierownik testów | `@speccrew-test-manager` | Planowanie testów, projektowanie przypadków, wykonanie | "Rozpocznij testy dla iteracji X" |
|
|
135
|
-
|
|
136
|
-
> **Uwaga**: Nie musisz pamiętać wszystkich agentów. Po prostu porozmawiaj z `@speccrew-team-leader`, a on skieruje Twoje żądanie do odpowiedniego agenta.
|
|
137
|
-
|
|
138
|
-
---
|
|
139
|
-
|
|
140
|
-
## 5. Przegląd przepływu pracy
|
|
141
|
-
|
|
142
|
-
### Pełny diagram przepływu
|
|
143
|
-
|
|
144
|
-
```mermaid
|
|
145
|
-
flowchart LR
|
|
146
|
-
PRD[Faza 1<br/>Analiza wymagań<br/>Product Manager] --> FD[Faza 2<br/>Projektowanie funkcji<br/>Feature Designer]
|
|
147
|
-
FD --> SD[Faza 3<br/>Projektowanie systemu<br/>System Designer]
|
|
148
|
-
SD --> DEV[Faza 4<br/>Rozwój<br/>System Developer]
|
|
149
|
-
DEV --> TEST[Faza 5<br/>Testowanie systemu<br/>Test Manager]
|
|
150
|
-
TEST --> ARCHIVE[Faza 6<br/>Archiwizacja]
|
|
151
|
-
|
|
152
|
-
KB[(Baza wiedzy<br/>Przez cały proces)] -.-> PRD
|
|
153
|
-
KB -.-> FD
|
|
154
|
-
KB -.-> SD
|
|
155
|
-
KB -.-> DEV
|
|
156
|
-
KB -.-> TEST
|
|
157
|
-
```
|
|
158
|
-
|
|
159
|
-
### Podstawowe zasady
|
|
160
|
-
|
|
161
|
-
1. **Zależności faz**: Wynik każdej fazy jest wejściem dla następnej fazy
|
|
162
|
-
2. **Potwierdzenie punktu kontrolnego**: Każda faza ma punkt potwierdzenia wymagający zatwierdzenia użytkownika przed przejściem dalej
|
|
163
|
-
3. **Sterowanie bazą wiedzy**: Baza wiedzy przechodzi przez cały proces, zapewniając kontekst dla wszystkich faz
|
|
164
|
-
|
|
165
|
-
---
|
|
166
|
-
|
|
167
|
-
## 6. Krok zerowy: Inicjalizacja bazy wiedzy
|
|
168
|
-
|
|
169
|
-
Przed rozpoczęciem formalnego procesu inżynieryjnego musisz zainicjować bazę wiedzy projektu.
|
|
170
|
-
|
|
171
|
-
### 6.1 Inicjalizacja technicznej bazy wiedzy
|
|
172
|
-
|
|
173
|
-
**Przykład rozmowy**:
|
|
174
|
-
```
|
|
175
|
-
@speccrew-team-leader zainicjuj techniczną bazę wiedzy
|
|
176
|
-
```
|
|
177
|
-
|
|
178
|
-
**Trójfazowy proces**:
|
|
179
|
-
1. Wykrywanie platformy — Zidentyfikuj platformy technologiczne w projekcie
|
|
180
|
-
2. Generowanie dokumentacji technicznej — Generuj dokumenty specyfikacji technicznej dla każdej platformy
|
|
181
|
-
3. Generowanie indeksu — Utwórz indeks bazy wiedzy
|
|
182
|
-
|
|
183
|
-
**Produkt**:
|
|
184
|
-
```
|
|
185
|
-
speccrew-workspace/knowledges/techs/{platform-id}/
|
|
186
|
-
├── tech-stack.md # Definicja stosu technologicznego
|
|
187
|
-
├── architecture.md # Konwencje architektoniczne
|
|
188
|
-
├── dev-spec.md # Specyfikacje rozwoju
|
|
189
|
-
├── test-spec.md # Specyfikacje testów
|
|
190
|
-
└── INDEX.md # Plik indeksu
|
|
191
|
-
```
|
|
192
|
-
|
|
193
|
-
### 6.2 Inicjalizacja biznesowej bazy wiedzy
|
|
194
|
-
|
|
195
|
-
**Przykład rozmowy**:
|
|
196
|
-
```
|
|
197
|
-
@speccrew-team-leader zainicjuj biznesową bazę wiedzy
|
|
198
|
-
```
|
|
199
|
-
|
|
200
|
-
**Czterofazowy proces**:
|
|
201
|
-
1. Inwentaryzacja funkcji — Skanuj kod, aby zidentyfikować wszystkie funkcje
|
|
202
|
-
2. Analiza funkcji — Analizuj logikę biznesową dla każdej funkcji
|
|
203
|
-
3. Podsumowanie modułu — Podsumuj funkcje według modułu
|
|
204
|
-
4. Podsumowanie systemu — Generuj przegląd biznesowy na poziomie systemu
|
|
205
|
-
|
|
206
|
-
**Produkt**:
|
|
207
|
-
```
|
|
208
|
-
speccrew-workspace/knowledges/bizs/
|
|
209
|
-
├── {platform-type}/
|
|
210
|
-
│ └── {module-name}/
|
|
211
|
-
│ └── feature-spec.md
|
|
212
|
-
└── system-overview.md
|
|
213
|
-
```
|
|
214
|
-
|
|
215
|
-
---
|
|
216
|
-
|
|
217
|
-
## 7. Przewodnik rozmowy fazowej
|
|
218
|
-
|
|
219
|
-
### 7.1 Faza 1: Analiza wymagań (Product Manager)
|
|
220
|
-
|
|
221
|
-
**Jak rozpocząć**:
|
|
222
|
-
```
|
|
223
|
-
@speccrew-product-manager Mam nowe wymaganie: [opisz swoje wymaganie]
|
|
224
|
-
```
|
|
225
|
-
|
|
226
|
-
**Workflow Agenta**:
|
|
227
|
-
1. Przeczytaj przegląd systemu, aby zrozumieć istniejące moduły
|
|
228
|
-
2. Analizuj wymagania użytkownika
|
|
229
|
-
3. Generuj strukturyzowany dokument PRD
|
|
230
|
-
|
|
231
|
-
**Produkt**:
|
|
232
|
-
```
|
|
233
|
-
iterations/{numer}-{typ}-{nazwa}/01.product-requirement/
|
|
234
|
-
├── [feature-name]-prd.md # Dokument wymagań produktu
|
|
235
|
-
└── [feature-name]-bizs-modeling.md # Modelowanie biznesowe (dla złożonych wymagań)
|
|
236
|
-
```
|
|
237
|
-
|
|
238
|
-
**Lista kontrolna potwierdzenia**:
|
|
239
|
-
- [ ] Czy opis wymagania dokładnie odzwierciedla intencję użytkownika?
|
|
240
|
-
- [ ] Czy reguły biznesowe są kompletne?
|
|
241
|
-
- [ ] Czy punkty integracji z istniejącymi systemami są jasne?
|
|
242
|
-
- [ ] Czy kryteria akceptacji są mierzalne?
|
|
243
|
-
|
|
244
|
-
---
|
|
245
|
-
|
|
246
|
-
### 7.2 Faza 2: Projektowanie funkcji (Feature Designer)
|
|
247
|
-
|
|
248
|
-
**Jak rozpocząć**:
|
|
249
|
-
```
|
|
250
|
-
@speccrew-feature-designer rozpocznij projektowanie funkcji
|
|
251
|
-
```
|
|
252
|
-
|
|
253
|
-
**Workflow Agenta**:
|
|
254
|
-
1. Automatycznie zlokalizuj potwierdzony dokument PRD
|
|
255
|
-
2. Załaduj biznesową bazę wiedzy
|
|
256
|
-
3. Generuj projekt funkcji (w tym wireframe'y UI, przepływy interakcji, definicje danych, kontrakty API)
|
|
257
|
-
4. Dla wielu PRD użyj Task Worker do równoległego projektowania
|
|
258
|
-
|
|
259
|
-
**Produkt**:
|
|
260
|
-
```
|
|
261
|
-
iterations/{iter}/02.feature-design/
|
|
262
|
-
└── [feature-name]-feature-spec.md # Dokument projektowania funkcji
|
|
263
|
-
```
|
|
264
|
-
|
|
265
|
-
**Lista kontrolna potwierdzenia**:
|
|
266
|
-
- [ ] Czy wszystkie scenariusze użytkownika są objęte?
|
|
267
|
-
- [ ] Czy przepływy interakcji są jasne?
|
|
268
|
-
- [ ] Czy definicje pól danych są kompletne?
|
|
269
|
-
- [ ] Czy obsługa wyjątków jest kompleksowa?
|
|
270
|
-
|
|
271
|
-
---
|
|
272
|
-
|
|
273
|
-
### 7.3 Faza 3: Projektowanie systemu (System Designer)
|
|
274
|
-
|
|
275
|
-
**Jak rozpocząć**:
|
|
276
|
-
```
|
|
277
|
-
@speccrew-system-designer rozpocznij projektowanie systemu
|
|
278
|
-
```
|
|
279
|
-
|
|
280
|
-
**Workflow Agenta**:
|
|
281
|
-
1. Zlokalizuj Feature Spec i API Contract
|
|
282
|
-
2. Załaduj techniczną bazę wiedzy (stos technologiczny, architektura, specyfikacje dla każdej platformy)
|
|
283
|
-
3. **Checkpoint A**: Ewaluacja frameworka — Analizuj luki techniczne, rekomenduj nowe frameworki (jeśli potrzeba), czekaj na potwierdzenie użytkownika
|
|
284
|
-
4. Generuj DESIGN-OVERVIEW.md
|
|
285
|
-
5. Użyj Task Worker do równoległego rozprowadzania projektowania dla każdej platformy (frontend/backend/mobile/desktop)
|
|
286
|
-
6. **Checkpoint B**: Wspólne potwierdzenie — Wyświetl podsumowanie wszystkich projektów platform, czekaj na potwierdzenie użytkownika
|
|
287
|
-
|
|
288
|
-
**Produkt**:
|
|
289
|
-
```
|
|
290
|
-
iterations/{iter}/03.system-design/
|
|
291
|
-
├── DESIGN-OVERVIEW.md # Przegląd projektowania
|
|
292
|
-
├── {platform-id}/
|
|
293
|
-
│ ├── INDEX.md # Indeks projektowania platformy
|
|
294
|
-
│ └── {module}-design.md # Projektowanie modułu na poziomie pseudokodu
|
|
295
|
-
```
|
|
296
|
-
|
|
297
|
-
**Lista kontrolna potwierdzenia**:
|
|
298
|
-
- [ ] Czy pseudokod używa rzeczywistej składni frameworka?
|
|
299
|
-
- [ ] Czy kontrakty API między platformami są spójne?
|
|
300
|
-
- [ ] Czy strategia obsługi błędów jest ujednolicona?
|
|
301
|
-
|
|
302
|
-
---
|
|
303
|
-
|
|
304
|
-
### 7.4 Faza 4: Rozwój (System Developer)
|
|
305
|
-
|
|
306
|
-
**Jak rozpocząć**:
|
|
307
|
-
```
|
|
308
|
-
@speccrew-system-developer rozpocznij rozwój
|
|
309
|
-
```
|
|
310
|
-
|
|
311
|
-
**Workflow Agenta**:
|
|
312
|
-
1. Przeczytaj dokumenty projektowania systemu
|
|
313
|
-
2. Załaduj wiedzę techniczną dla każdej platformy
|
|
314
|
-
3. **Checkpoint A**: Wstępna kontrola środowiska — Sprawdź wersje runtime, zależności, dostępność usług; czekaj na rozwiązanie użytkownika jeśli nie powiedzie się
|
|
315
|
-
4. Użyj Task Worker do równoległego rozprowadzania rozwoju dla każdej platformy
|
|
316
|
-
5. Kontrola integracji: wyrównanie kontraktów API, spójność danych
|
|
317
|
-
6. Wygeneruj raport dostawy
|
|
318
|
-
|
|
319
|
-
**Produkt**:
|
|
320
|
-
```
|
|
321
|
-
# Kod źródłowy zapisywany w rzeczywistym katalogu źródłowym projektu
|
|
322
|
-
iterations/{iter}/04.development/
|
|
323
|
-
├── {platform-id}/
|
|
324
|
-
│ └── tasks/ # Rejestry zadań rozwoju
|
|
325
|
-
└── delivery-report.md
|
|
326
|
-
```
|
|
327
|
-
|
|
328
|
-
**Lista kontrolna potwierdzenia**:
|
|
329
|
-
- [ ] Czy środowisko jest gotowe?
|
|
330
|
-
- [ ] Czy problemy integracyjne są w akceptowalnym zakresie?
|
|
331
|
-
- [ ] Czy kod jest zgodny ze specyfikacjami rozwoju?
|
|
332
|
-
|
|
333
|
-
---
|
|
334
|
-
|
|
335
|
-
### 7.5 Faza 5: Testowanie systemu (Test Manager)
|
|
336
|
-
|
|
337
|
-
**Jak rozpocząć**:
|
|
338
|
-
```
|
|
339
|
-
@speccrew-test-manager rozpocznij testy
|
|
340
|
-
```
|
|
341
|
-
|
|
342
|
-
**Trójfazowy proces testowania**:
|
|
343
|
-
|
|
344
|
-
| Faza | Opis | Checkpoint |
|
|
345
|
-
|-------|-------------|------------|
|
|
346
|
-
| Projektowanie przypadków testowych | Generuj przypadki testowe na podstawie PRD i Feature Spec | A: Wyświetl statystyki pokrycia przypadków i macierz śledzenia, czekaj na potwierdzenie użytkownika wystarczającego pokrycia |
|
|
347
|
-
| Generowanie kodu testowego | Generuj wykonywalny kod testowy | B: Wyświetl wygenerowane pliki testowe i mapowanie przypadków, czekaj na potwierdzenie użytkownika |
|
|
348
|
-
| Wykonanie testów i raportowanie błędów | Automatycznie wykonuj testy i generuj raporty | Brak (automatyczne wykonanie) |
|
|
349
|
-
|
|
350
|
-
**Produkt**:
|
|
351
|
-
```
|
|
352
|
-
iterations/{iter}/05.system-test/
|
|
353
|
-
├── cases/
|
|
354
|
-
│ └── {platform-id}/ # Dokumenty przypadków testowych
|
|
355
|
-
├── code/
|
|
356
|
-
│ └── {platform-id}/ # Plan kodu testowego
|
|
357
|
-
├── reports/
|
|
358
|
-
│ └── test-report-{date}.md # Raport testu
|
|
359
|
-
└── bugs/
|
|
360
|
-
└── BUG-{id}-{title}.md # Raporty błędów (jeden plik na błąd)
|
|
361
|
-
```
|
|
362
|
-
|
|
363
|
-
**Lista kontrolna potwierdzenia**:
|
|
364
|
-
- [ ] Czy pokrycie przypadków jest kompletne?
|
|
365
|
-
- [ ] Czy kod testowy jest wykonywalny?
|
|
366
|
-
- [ ] Czy ocena poważności błędów jest dokładna?
|
|
367
|
-
|
|
368
|
-
---
|
|
369
|
-
|
|
370
|
-
### 7.6 Faza 6: Archiwizacja
|
|
371
|
-
|
|
372
|
-
Iteracje są automatycznie archiwizowane po ukończeniu:
|
|
373
|
-
|
|
374
|
-
```
|
|
375
|
-
speccrew-workspace/iteration-archives/
|
|
376
|
-
└── {numer}-{typ}-{nazwa}-{data}/
|
|
377
|
-
├── 01.product-requirement/
|
|
378
|
-
├── 02.feature-design/
|
|
379
|
-
├── 03.system-design/
|
|
380
|
-
├── 04.development/
|
|
381
|
-
└── 05.system-test/
|
|
382
|
-
```
|
|
383
|
-
|
|
384
|
-
---
|
|
385
|
-
|
|
386
|
-
## 8. Przegląd bazy wiedzy
|
|
387
|
-
|
|
388
|
-
### 8.1 Biznesowa baza wiedzy (bizs)
|
|
389
|
-
|
|
390
|
-
**Cel**: Przechowuj opisy funkcji biznesowych projektu, podziały modułów, cechy API
|
|
391
|
-
|
|
392
|
-
**Struktura katalogów**:
|
|
393
|
-
```
|
|
394
|
-
knowledges/bizs/
|
|
395
|
-
├── {platform-type}/
|
|
396
|
-
│ └── {module-name}/
|
|
397
|
-
│ └── feature-spec.md
|
|
398
|
-
└── system-overview.md
|
|
399
|
-
```
|
|
400
|
-
|
|
401
|
-
**Scenariusze użycia**: Product Manager, Feature Designer
|
|
402
|
-
|
|
403
|
-
### 8.2 Techniczna baza wiedzy (techs)
|
|
404
|
-
|
|
405
|
-
**Cel**: Przechowuj stos technologiczny projektu, konwencje architektoniczne, specyfikacje rozwoju, specyfikacje testów
|
|
406
|
-
|
|
407
|
-
**Struktura katalogów**:
|
|
408
|
-
```
|
|
409
|
-
knowledges/techs/{platform-id}/
|
|
410
|
-
├── tech-stack.md
|
|
411
|
-
├── architecture.md
|
|
412
|
-
├── dev-spec.md
|
|
413
|
-
├── test-spec.md
|
|
414
|
-
└── INDEX.md
|
|
415
|
-
```
|
|
416
|
-
|
|
417
|
-
**Scenariusze użycia**: System Designer, System Developer, Test Manager
|
|
418
|
-
|
|
419
|
-
---
|
|
420
|
-
|
|
421
|
-
## 9. Zarządzanie postępem przepływu pracy
|
|
422
|
-
|
|
423
|
-
Wirtualny zespół SpecCrew przestrzega ścisłego mechanizmu bramowania etapów, gdzie każda faza musi zostać potwierdzona przez użytkownika przed przejściem do następnej. Obsługuje również wznawialne wykonanie — po ponownym uruchomieniu po przerwaniu automatycznie kontynuuje od miejsca, w którym przerwał.
|
|
424
|
-
|
|
425
|
-
### 9.1 Trzywarstwowe pliki postępu
|
|
426
|
-
|
|
427
|
-
Workflow automatycznie utrzymuje trzy typy plików postępu JSON, zlokalizowane w katalogu iteracji:
|
|
428
|
-
|
|
429
|
-
| Plik | Lokalizacja | Cel |
|
|
430
|
-
|------|----------|---------|
|
|
431
|
-
| `WORKFLOW-PROGRESS.json` | `iterations/{iter}/` | Rejestruje status każdej fazy pipeline'u |
|
|
432
|
-
| `.checkpoints.json` | Pod każdym katalogiem fazy | Rejestruje status potwierdzenia checkpointów użytkownika |
|
|
433
|
-
| `DISPATCH-PROGRESS.json` | Pod każdym katalogiem fazy | Rejestruje postęp element po elemencie dla równoległych zadań (multi-platforma/multi-moduł) |
|
|
434
|
-
|
|
435
|
-
### 9.2 Przepływ statusu fazy
|
|
436
|
-
|
|
437
|
-
Każda faza następuje po tym przepływie statusu:
|
|
438
|
-
|
|
439
|
-
```
|
|
440
|
-
pending → in_progress → completed → confirmed
|
|
441
|
-
```
|
|
442
|
-
|
|
443
|
-
- **pending**: Jeszcze nie rozpoczęte
|
|
444
|
-
- **in_progress**: W trakcie wykonania
|
|
445
|
-
- **completed**: Wykonanie agenta zakończone, oczekiwanie na potwierdzenie użytkownika
|
|
446
|
-
- **confirmed**: Użytkownik potwierdził przez końcowy checkpoint, następna faza może się rozpocząć
|
|
447
|
-
|
|
448
|
-
### 9.3 Wznawialne wykonanie
|
|
449
|
-
|
|
450
|
-
Podczas ponownego uruchamiania Agenta dla fazy:
|
|
451
|
-
|
|
452
|
-
1. **Automatyczne sprawdzanie upstream**: Weryfikuje czy poprzednia faza jest potwierdzona, blokuje i monituje jeśli nie
|
|
453
|
-
2. **Odzyskiwanie Checkpoint**: Odczytuje `.checkpoints.json`, pomija przejście checkpoints, kontynuuje od ostatniego punktu przerwania
|
|
454
|
-
3. **Odzyskiwanie równoległych zadań**: Odczytuje `DISPATCH-PROGRESS.json`, ponownie wykonuje tylko zadania ze statusem `pending` lub `failed`, pomija zadania `completed`
|
|
455
|
-
|
|
456
|
-
### 9.4 Wyświetlanie bieżącego postępu
|
|
457
|
-
|
|
458
|
-
Wyświetl panoramiczny status pipeline'u przez Agenta Team Leader:
|
|
459
|
-
|
|
460
|
-
```
|
|
461
|
-
@speccrew-team-leader wyświetl bieżący postęp iteracji
|
|
462
|
-
```
|
|
463
|
-
|
|
464
|
-
Team Leader odczyta pliki postępu i wyświetli przegląd statusu podobny do:
|
|
465
|
-
|
|
466
|
-
```
|
|
467
|
-
Pipeline Status: i001-user-management
|
|
468
|
-
01 PRD: ✅ Confirmed
|
|
469
|
-
02 Feature Design: 🔄 In Progress (Checkpoint A passed)
|
|
470
|
-
03 System Design: ⏳ Pending
|
|
471
|
-
04 Development: ⏳ Pending
|
|
472
|
-
05 System Test: ⏳ Pending
|
|
473
|
-
```
|
|
474
|
-
|
|
475
|
-
### 9.5 Wsteczna kompatybilność
|
|
476
|
-
|
|
477
|
-
Mechanizm plików postępu jest w pełni wstecznie kompatybilny — jeśli pliki postępu nie istnieją (np. w starszych projektach lub nowych iteracjach), wszyscy Agenci będą wykonywać normalnie zgodnie z oryginalną logiką.
|
|
478
|
-
|
|
479
|
-
---
|
|
480
|
-
|
|
481
|
-
## 10. Często zadawane pytania (FAQ)
|
|
482
|
-
|
|
483
|
-
### P1: Co zrobić jeśli Agent nie działa zgodnie z oczekiwaniami?
|
|
484
|
-
|
|
485
|
-
1. Uruchom `speccrew doctor` aby sprawdzić integralność instalacji
|
|
486
|
-
2. Potwierdź że baza wiedzy została zainicjowana
|
|
487
|
-
3. Potwierdź że produkt poprzedniej fazy istnieje w bieżącym katalogu iteracji
|
|
488
|
-
|
|
489
|
-
### P2: Jak pominąć fazę?
|
|
490
|
-
|
|
491
|
-
**Nie zalecane** — Wynik każdej fazy jest wejściem dla następnej fazy.
|
|
492
|
-
|
|
493
|
-
Jeśli musisz pominąć, ręcznie przygotuj dokument wejściowy odpowiedniej fazy i upewnij się, że jest zgodny ze specyfikacjami formatu.
|
|
494
|
-
|
|
495
|
-
### P3: Jak obsługiwać wiele równoległych wymagań?
|
|
496
|
-
|
|
497
|
-
Utwórz niezależne katalogi iteracji dla każdego wymagania:
|
|
498
|
-
```
|
|
499
|
-
iterations/
|
|
500
|
-
├── 001-feature-xxx/
|
|
501
|
-
├── 002-feature-yyy/
|
|
502
|
-
└── 003-feature-zzz/
|
|
503
|
-
```
|
|
504
|
-
|
|
505
|
-
Każda iteracja jest całkowicie izolowana i nie wpływa na inne.
|
|
506
|
-
|
|
507
|
-
### P4: Jak zaktualizować wersję SpecCrew?
|
|
508
|
-
|
|
509
|
-
Aktualizacja wymaga dwóch kroków:
|
|
510
|
-
|
|
511
|
-
```bash
|
|
512
|
-
# Krok 1: Zaktualizuj globalne narzędzie CLI
|
|
513
|
-
npm install -g speccrew@latest
|
|
514
|
-
|
|
515
|
-
# Krok 2: Synchronizuj Agents i Skills w katalogu projektu
|
|
516
|
-
cd /path/to/your-project
|
|
517
|
-
speccrew update
|
|
518
|
-
```
|
|
519
|
-
|
|
520
|
-
- `npm install -g speccrew@latest`: Aktualizuje samo narzędzie CLI (nowe wersje mogą zawierać nowe definicje Agent/Skill, poprawki błędów itp.)
|
|
521
|
-
- `speccrew update`: Synchronizuje pliki definicji Agent i Skill w Twoim projekcie do najnowszej wersji
|
|
522
|
-
- `speccrew update --ide cursor`: Aktualizuje konfigurację tylko dla określonego IDE
|
|
523
|
-
|
|
524
|
-
> **Uwaga**: Oba kroki są wymagane. Uruchomienie samego `speccrew update` nie zaktualizuje samego narzędzia CLI; uruchomienie samego `npm install` nie zaktualizuje plików projektu.
|
|
525
|
-
|
|
526
|
-
### P5: `speccrew update` pokazuje nową wersję dostępną ale `npm install -g speccrew@latest` nadal instaluje starą wersję?
|
|
527
|
-
|
|
528
|
-
Jest to zwykle spowodowane pamięcią podręczną npm. Rozwiązanie:
|
|
529
|
-
|
|
530
|
-
```bash
|
|
531
|
-
# Wyczyść pamięć podręczną npm i zainstaluj ponownie
|
|
532
|
-
npm cache clean --force
|
|
533
|
-
npm install -g speccrew@latest
|
|
534
|
-
|
|
535
|
-
# Zweryfikuj wersję
|
|
536
|
-
npm list -g speccrew
|
|
537
|
-
```
|
|
538
|
-
|
|
539
|
-
Jeśli nadal nie działa, spróbuj zainstalować z określonym numerem wersji:
|
|
540
|
-
```bash
|
|
541
|
-
npm install -g speccrew@0.5.6
|
|
542
|
-
```
|
|
543
|
-
|
|
544
|
-
### P6: Jak wyświetlić historyczne iteracje?
|
|
545
|
-
|
|
546
|
-
Po archiwizacji wyświetl w `speccrew-workspace/iteration-archives/`, zorganizowane według formatu `{numer}-{typ}-{nazwa}-{data}/`.
|
|
547
|
-
|
|
548
|
-
### P7: Czy baza wiedzy wymaga regularnych aktualizacji?
|
|
549
|
-
|
|
550
|
-
Ponowna inicjalizacja jest wymagana w następujących sytuacjach:
|
|
551
|
-
- Znaczące zmiany w strukturze projektu
|
|
552
|
-
- Aktualizacja lub wymiana stosu technologicznego
|
|
553
|
-
- Dodanie/usunięcie modułów biznesowych
|
|
554
|
-
|
|
555
|
-
---
|
|
556
|
-
|
|
557
|
-
## 11. Szybki podgląd
|
|
558
|
-
|
|
559
|
-
### Szybki podgląd uruchamiania Agentów
|
|
560
|
-
|
|
561
|
-
| Faza | Agent | Rozpocznij rozmowę |
|
|
562
|
-
|-------|-------|-------------------|
|
|
563
|
-
| Inicjalizacja | Team Leader | `@speccrew-team-leader zainicjuj techniczną bazę wiedzy` |
|
|
564
|
-
| Analiza wymagań | Product Manager | `@speccrew-product-manager Mam nowe wymaganie: [opis]` |
|
|
565
|
-
| Projektowanie funkcji | Feature Designer | `@speccrew-feature-designer rozpocznij projektowanie funkcji` |
|
|
566
|
-
| Projektowanie systemu | System Designer | `@speccrew-system-designer rozpocznij projektowanie systemu` |
|
|
567
|
-
| Rozwój | System Developer | `@speccrew-system-developer rozpocznij rozwój` |
|
|
568
|
-
| Testowanie systemu | Test Manager | `@speccrew-test-manager rozpocznij testy` |
|
|
569
|
-
|
|
570
|
-
### Lista kontrolna Checkpointów
|
|
571
|
-
|
|
572
|
-
| Faza | Liczba Checkpointów | Kluczowe elementy kontrolne |
|
|
573
|
-
|-------|----------------------|-----------------|
|
|
574
|
-
| Analiza wymagań | 1 | Dokładność wymagań, kompletność reguł biznesowych, mierzalność kryteriów akceptacji |
|
|
575
|
-
| Projektowanie funkcji | 1 | Pokrycie scenariuszy, jasność interakcji, kompletność danych, obsługa wyjątków |
|
|
576
|
-
| Projektowanie systemu | 2 | A: Ewaluacja frameworka; B: Składnia pseudokodu, spójność między platformami, obsługa błędów |
|
|
577
|
-
| Rozwój | 1 | A: Gotowość środowiska, problemy integracyjne, specyfikacje kodu |
|
|
578
|
-
| Testowanie systemu | 2 | A: Pokrycie przypadków; B: Wykonywalność kodu testowego |
|
|
579
|
-
|
|
580
|
-
### Szybki podgląd ścieżek produktów
|
|
581
|
-
|
|
582
|
-
| Faza | Katalog wyjściowy | Format pliku |
|
|
583
|
-
|-------|-----------------|-------------|
|
|
584
|
-
| Analiza wymagań | `iterations/{iter}/01.product-requirement/` | `[name]-prd.md`, `[name]-bizs-modeling.md` |
|
|
585
|
-
| Projektowanie funkcji | `iterations/{iter}/02.feature-design/` | `[name]-feature-spec.md` |
|
|
586
|
-
| Projektowanie systemu | `iterations/{iter}/03.system-design/` | `DESIGN-OVERVIEW.md`, `{platform}/INDEX.md`, `{platform}/{module}-design.md` |
|
|
587
|
-
| Rozwój | `iterations/{iter}/04.development/` | Kod źródłowy + `delivery-report.md` |
|
|
588
|
-
| Testowanie systemu | `iterations/{iter}/05.system-test/` | `cases/`, `code/`, `reports/`, `bugs/` |
|
|
589
|
-
| Archiwizacja | `iteration-archives/{iter}-{date}/` | Kompletna kopia iteracji |
|
|
590
|
-
|
|
591
|
-
---
|
|
592
|
-
|
|
593
|
-
## Następne kroki
|
|
594
|
-
|
|
595
|
-
1. Uruchom `speccrew init --ide qoder` aby zainicjować swój projekt
|
|
596
|
-
2. Wykonaj Krok Zerowy: Inicjalizacja bazy wiedzy
|
|
597
|
-
3. Postępuj zgodnie z workflowem faza po fazie, ciesz się rozwojem opartym na specyfikacjach!
|