speccrew 0.7.44 → 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/workspace-template/scripts/update-progress.js +5 -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,563 +0,0 @@
|
|
|
1
|
-
# SpecCrew - Rask Startguide
|
|
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.no.md">Norsk</a>
|
|
16
|
-
</p>
|
|
17
|
-
|
|
18
|
-
Dette dokumentet hjelper deg med raskt å forstå hvordan du bruker SpecCrew Agent-teamet for å fullføre hele utviklingssyklusen fra krav til levering, etter standard ingeniørprosesser.
|
|
19
|
-
|
|
20
|
-
---
|
|
21
|
-
|
|
22
|
-
## 1. Forutsetninger
|
|
23
|
-
|
|
24
|
-
### Installer SpecCrew
|
|
25
|
-
|
|
26
|
-
```bash
|
|
27
|
-
npm install -g speccrew
|
|
28
|
-
```
|
|
29
|
-
|
|
30
|
-
### Initialiser Prosjekt
|
|
31
|
-
|
|
32
|
-
```bash
|
|
33
|
-
speccrew init --ide qoder
|
|
34
|
-
```
|
|
35
|
-
|
|
36
|
-
Støttede IDE-er: `qoder`, `cursor`, `claude`, `codex`
|
|
37
|
-
|
|
38
|
-
### Katalogstruktur Etter Initialisering
|
|
39
|
-
|
|
40
|
-
```
|
|
41
|
-
.
|
|
42
|
-
├── .qoder/
|
|
43
|
-
│ ├── agents/ # Agent-definisjonsfiler
|
|
44
|
-
│ └── skills/ # Skill-definisjonsfiler
|
|
45
|
-
├── speccrew-workspace/ # Arbeidsområde
|
|
46
|
-
│ ├── docs/ # Konfigurasjoner, regler, maler, løsninger
|
|
47
|
-
│ ├── iterations/ # Gjeldende iterasjoner
|
|
48
|
-
│ ├── iteration-archives/ # Arkiverte iterasjoner
|
|
49
|
-
│ └── knowledges/ # Kunnskapsbase
|
|
50
|
-
│ ├── base/ # Grunnleggende informasjon (diagnoserapporter, teknisk gjeld)
|
|
51
|
-
│ ├── bizs/ # Forretningskunnskapsbase
|
|
52
|
-
│ └── techs/ # Teknisk kunnskapsbase
|
|
53
|
-
```
|
|
54
|
-
|
|
55
|
-
### CLI-kommando Hurtigreferanse
|
|
56
|
-
|
|
57
|
-
| Kommando | Beskrivelse |
|
|
58
|
-
|---------|-------------|
|
|
59
|
-
| `speccrew list` | List opp alle tilgjengelige Agenter og Skills |
|
|
60
|
-
| `speccrew doctor` | Sjekk installasjonsintegritet |
|
|
61
|
-
| `speccrew update` | Oppdater prosjektkonfigurasjon til nyeste versjon |
|
|
62
|
-
| `speccrew uninstall` | Avinstaller SpecCrew |
|
|
63
|
-
|
|
64
|
-
---
|
|
65
|
-
|
|
66
|
-
## 2. Arbeidsflytoversikt
|
|
67
|
-
|
|
68
|
-
### Full Flytdiagram
|
|
69
|
-
|
|
70
|
-
```mermaid
|
|
71
|
-
flowchart LR
|
|
72
|
-
PRD[Fase 1<br/>Kravanalyse<br/>Product Manager] --> FD[Fase 2<br/>Funksjonsdesign<br/>Feature Designer]
|
|
73
|
-
FD --> SD[Fase 3<br/>Systemdesign<br/>System Designer]
|
|
74
|
-
SD --> DEV[Fase 4<br/>Utvikling<br/>System Developer]
|
|
75
|
-
DEV --> DEPLOY[Fase 5<br/>Utrulling<br/>System Deployer]
|
|
76
|
-
DEPLOY --> TEST[Fase 6<br/>Systemtesting<br/>Test Manager]
|
|
77
|
-
TEST --> ARCHIVE[Fase 7<br/>Arkivering]
|
|
78
|
-
|
|
79
|
-
KB[(Kunnskapsbase<br/>Gjennom Hele Prosessen)] -.-> PRD
|
|
80
|
-
KB -.-> FD
|
|
81
|
-
KB -.-> SD
|
|
82
|
-
KB -.-> DEV
|
|
83
|
-
KB -.-> DEPLOY
|
|
84
|
-
KB -.-> TEST
|
|
85
|
-
```
|
|
86
|
-
|
|
87
|
-
### Grunnleggende Prinsipper
|
|
88
|
-
|
|
89
|
-
1. **Faseavhengigheter**: Hver fases output er input for neste fase
|
|
90
|
-
2. **Kontrollpunkt-bekreftelse**: Hver fase har et bekreftelsespunkt som krever brukergodkjenning før du fortsetter
|
|
91
|
-
3. **Kunnskapsbase-drevet**: Kunnskapsbasen strømmer gjennom hele prosessen, gir kontekst for alle faser
|
|
92
|
-
|
|
93
|
-
---
|
|
94
|
-
|
|
95
|
-
## 3. Null Steg: Kunnskapsbase-initialisering
|
|
96
|
-
|
|
97
|
-
Før du starter den formelle ingeniørprosessen, må du initialisere prosjektets kunnskapsbase.
|
|
98
|
-
|
|
99
|
-
### 3.1 Initialiser Teknisk Kunnskapsbase
|
|
100
|
-
|
|
101
|
-
**Eksempel på Dialog**:
|
|
102
|
-
```
|
|
103
|
-
@speccrew-team-leader initialiser teknisk kunnskapsbase
|
|
104
|
-
```
|
|
105
|
-
|
|
106
|
-
**Tre-fase Prosess**:
|
|
107
|
-
1. Plattformoppdagelse — Identifiser teknologiplattformer i prosjektet
|
|
108
|
-
2. Teknisk Dokumentasjonsgenerering — Generer tekniske spesifikasjonsdokumenter for hver plattform
|
|
109
|
-
3. Indeksgenerering — Etabler kunnskapsbase-indeks
|
|
110
|
-
|
|
111
|
-
**Leveranse**:
|
|
112
|
-
```
|
|
113
|
-
speccrew-workspace/knowledges/techs/{platform-id}/
|
|
114
|
-
├── tech-stack.md # Teknologistabeldefinisjon
|
|
115
|
-
├── architecture.md # Arkitekturkonvensjoner
|
|
116
|
-
├── dev-spec.md # Utviklingsspesifikasjoner
|
|
117
|
-
├── test-spec.md # Testspesifikasjoner
|
|
118
|
-
└── INDEX.md # Indeksfil
|
|
119
|
-
```
|
|
120
|
-
|
|
121
|
-
### 3.2 Initialiser Forretningskunnskapsbase
|
|
122
|
-
|
|
123
|
-
**Eksempel på Dialog**:
|
|
124
|
-
```
|
|
125
|
-
@speccrew-team-leader initialiser forretningskunnskapsbase
|
|
126
|
-
```
|
|
127
|
-
|
|
128
|
-
**Fire-fase Prosess**:
|
|
129
|
-
1. Funksjonsinventar — Skann kode for å identifisere alle funksjoner
|
|
130
|
-
2. Funksjonsanalyse — Analyser forretningslogikk for hver funksjon
|
|
131
|
-
3. Modulsammendrag — Oppsummer funksjoner etter modul
|
|
132
|
-
4. Systemsammendrag — Generer forretningsoversikt på systemnivå
|
|
133
|
-
|
|
134
|
-
**Leveranse**:
|
|
135
|
-
```
|
|
136
|
-
speccrew-workspace/knowledges/bizs/
|
|
137
|
-
├── {platform-type}/
|
|
138
|
-
│ └── {module-name}/
|
|
139
|
-
│ └── feature-spec.md
|
|
140
|
-
└── system-overview.md
|
|
141
|
-
```
|
|
142
|
-
|
|
143
|
-
---
|
|
144
|
-
|
|
145
|
-
## 4. Fase-for-Fase Dialogguide
|
|
146
|
-
|
|
147
|
-
### 4.1 Fase 1: Kravanalyse (Product Manager)
|
|
148
|
-
|
|
149
|
-
**Hvordan Starte**:
|
|
150
|
-
```
|
|
151
|
-
@speccrew-product-manager jeg har et nytt krav: [beskriv kravet ditt]
|
|
152
|
-
```
|
|
153
|
-
|
|
154
|
-
**Agent Arbeidsflyt**:
|
|
155
|
-
1. Les systemoversikt for å forstå eksisterende moduler
|
|
156
|
-
2. Analyser brukerkrav
|
|
157
|
-
3. Generer strukturert PRD-dokument
|
|
158
|
-
|
|
159
|
-
**Leveranse**:
|
|
160
|
-
```
|
|
161
|
-
iterations/{nummer}-{type}-{navn}/01.product-requirement/
|
|
162
|
-
├── [feature-name]-prd.md # Produktkravdokument
|
|
163
|
-
└── [feature-name]-bizs-modeling.md # Forretningsmodellering (for komplekse krav)
|
|
164
|
-
```
|
|
165
|
-
|
|
166
|
-
**Bekreftelseskontrollliste**:
|
|
167
|
-
- [ ] Reflekterer kravbeskrivelsen brukerens intensjon nøyaktig?
|
|
168
|
-
- [ ] Er forretningsregler komplette?
|
|
169
|
-
- [ ] Er integrasjonspunkter med eksisterende systemer klare?
|
|
170
|
-
- [ ] Er akseptkriterier målbare?
|
|
171
|
-
|
|
172
|
-
---
|
|
173
|
-
|
|
174
|
-
### 4.2 Fase 2: Funksjonsdesign (Feature Designer)
|
|
175
|
-
|
|
176
|
-
**Hvordan Starte**:
|
|
177
|
-
```
|
|
178
|
-
@speccrew-feature-designer start funksjonsdesign
|
|
179
|
-
```
|
|
180
|
-
|
|
181
|
-
**Agent Arbeidsflyt**:
|
|
182
|
-
1. Finn automatisk bekreftet PRD-dokument
|
|
183
|
-
2. Last inn forretningskunnskapsbase
|
|
184
|
-
3. Generer funksjonsdesign (inkludert UI-wireframes, interaksjonsflyter, datadefinisjoner, API-kontrakter)
|
|
185
|
-
4. For flere PRD-er, bruk Task Worker for parallell design
|
|
186
|
-
|
|
187
|
-
**Leveranse**:
|
|
188
|
-
```
|
|
189
|
-
iterations/{iter}/02.feature-design/
|
|
190
|
-
└── [feature-name]-feature-spec.md # Funksjonsdesigndokument
|
|
191
|
-
```
|
|
192
|
-
|
|
193
|
-
**Bekreftelseskontrollliste**:
|
|
194
|
-
- [ ] Er alle brukerscenarier dekket?
|
|
195
|
-
- [ ] Er interaksjonsflyter klare?
|
|
196
|
-
- [ ] Er datafeltdefinisjoner komplette?
|
|
197
|
-
- [ ] Er unntakshåndtering omfattende?
|
|
198
|
-
|
|
199
|
-
---
|
|
200
|
-
|
|
201
|
-
### 4.3 Fase 3: Systemdesign (System Designer)
|
|
202
|
-
|
|
203
|
-
**Hvordan Starte**:
|
|
204
|
-
```
|
|
205
|
-
@speccrew-system-designer start systemdesign
|
|
206
|
-
```
|
|
207
|
-
|
|
208
|
-
**Agent Arbeidsflyt**:
|
|
209
|
-
1. Finn Feature Spec og API Contract
|
|
210
|
-
2. Last inn teknisk kunnskapsbase (teknologistabel, arkitektur, spesifikasjoner for hver plattform)
|
|
211
|
-
3. **Kontrollpunkt A**: Rammeverkvurdering — Analyser tekniske gap, anbefal nye rammeverk (om nødvendig), vent på brukerbekreftelse
|
|
212
|
-
4. Generer DESIGN-OVERVIEW.md
|
|
213
|
-
5. Bruk Task Worker for parallell designdistribusjon for hver plattform (frontend/backend/mobil/skrivebord)
|
|
214
|
-
6. **Kontrollpunkt B**: Felles Bekreftelse — Vis oppsummering av alle plattformdesign, vent på brukerbekreftelse
|
|
215
|
-
|
|
216
|
-
**Leveranse**:
|
|
217
|
-
```
|
|
218
|
-
iterations/{iter}/03.system-design/
|
|
219
|
-
├── DESIGN-OVERVIEW.md # Designoversikt
|
|
220
|
-
├── {platform-id}/
|
|
221
|
-
│ ├── INDEX.md # Plattformdesign-indeks
|
|
222
|
-
│ └── {module}-design.md # Moduldesign på pseudokodenivå
|
|
223
|
-
```
|
|
224
|
-
|
|
225
|
-
**Bekreftelseskontrollliste**:
|
|
226
|
-
- [ ] Bruker pseudokoden faktisk rammeverksyntaks?
|
|
227
|
-
- [ ] Er cross-plattform API-kontrakter konsistente?
|
|
228
|
-
- [ ] Er feilhåndteringsstrategi unified?
|
|
229
|
-
|
|
230
|
-
---
|
|
231
|
-
|
|
232
|
-
### 4.4 Fase 4: Utviklingsimplementering (System Developer)
|
|
233
|
-
|
|
234
|
-
**Hvordan Starte**:
|
|
235
|
-
```
|
|
236
|
-
@speccrew-system-developer start utvikling
|
|
237
|
-
```
|
|
238
|
-
|
|
239
|
-
**Agent Arbeidsflyt**:
|
|
240
|
-
1. Les systemdesigndokumenter
|
|
241
|
-
2. Last inn teknisk kunnskap for hver plattform
|
|
242
|
-
3. **Kontrollpunkt A**: Miljø-forhåndsverifisering — Verifiser runtime-versjoner, avhengigheter, tjenestetilgjengelighet; hvis mislykkes, vent på brukerløsning
|
|
243
|
-
4. Bruk Task Worker for parallell utviklingsdistribusjon for hver plattform
|
|
244
|
-
5. Integrasjonsverifisering: API-kontraktsjustering, datakonsistens
|
|
245
|
-
6. Output leveranserapport
|
|
246
|
-
|
|
247
|
-
**Leveranse**:
|
|
248
|
-
```
|
|
249
|
-
# Kildekode skrives til prosjektets faktiske kildekodekatalog
|
|
250
|
-
iterations/{iter}/04.development/
|
|
251
|
-
├── {platform-id}/
|
|
252
|
-
│ └── tasks/ # Utviklingsopptegnelser
|
|
253
|
-
└── delivery-report.md
|
|
254
|
-
```
|
|
255
|
-
|
|
256
|
-
**Bekreftelseskontrollliste**:
|
|
257
|
-
- [ ] Er miljøet klart?
|
|
258
|
-
- [ ] Er integrasjonsproblemer innen akseptabelt område?
|
|
259
|
-
- [ ] Følger koden utviklingsspesifikasjoner?
|
|
260
|
-
|
|
261
|
-
---
|
|
262
|
-
|
|
263
|
-
### 4.5 Fase 5: Utrulling (System Deployer)
|
|
264
|
-
|
|
265
|
-
**Hvordan Starte**:
|
|
266
|
-
|
|
267
|
-
```
|
|
268
|
-
@speccrew-system-deployer start utrulling
|
|
269
|
-
```
|
|
270
|
-
|
|
271
|
-
**Agent Arbeidsflyt**:
|
|
272
|
-
1. Verifiser at utviklingsfasen er fullført (Stage Gate)
|
|
273
|
-
2. Last inn teknisk kunnskapsbase (byggekonfigurasjon, databasemigreringskonfigurasjon, tjenestestart-kommandoer)
|
|
274
|
-
3. **Kontrollpunkt**: Miljø-forhåndsverifisering — Verifiser byggeverktøy, runtime-versjoner, avhengighetstilgjengelighet
|
|
275
|
-
4. Utfør utrullingsskills i rekkefølge: Bygging (Build) → Databasemigrering (Migrate) → Tjenestestart (Startup) → Røyktest (Smoke Test)
|
|
276
|
-
5. Output utrullingsrapport
|
|
277
|
-
|
|
278
|
-
> 💡 **Tips**: For prosjekter uten database, blir migreringstrinnet automatisk hoppet over; for klientapplikasjoner (desktop/mobil), brukes prosessverifiseringsmodus i stedet for HTTP-helsesjekk.
|
|
279
|
-
|
|
280
|
-
**Leveranse**:
|
|
281
|
-
|
|
282
|
-
```
|
|
283
|
-
iterations/{iter}/05.deployment/
|
|
284
|
-
├── {platform-id}/
|
|
285
|
-
│ ├── deployment-plan.md # Utrullingsplan
|
|
286
|
-
│ └── deployment-log.md # Utrulling gjennomføringslogg
|
|
287
|
-
└── deployment-report.md # Utrulling fullført rapport
|
|
288
|
-
```
|
|
289
|
-
|
|
290
|
-
**Bekreftelseskontrollliste**:
|
|
291
|
-
- [ ] Er byggingen fullført vellykket?
|
|
292
|
-
- [ ] Er alle databasemigreringsskript utført vellykket (hvis aktuelt)?
|
|
293
|
-
- [ ] Startet applikasjonen normalt og passerte helsesjekk?
|
|
294
|
-
- [ ] Er alle røyktester bestått?
|
|
295
|
-
|
|
296
|
-
---
|
|
297
|
-
|
|
298
|
-
### 4.6 Fase 6: Systemtesting (Test Manager)
|
|
299
|
-
|
|
300
|
-
**Hvordan Starte**:
|
|
301
|
-
```
|
|
302
|
-
@speccrew-test-manager start testing
|
|
303
|
-
```
|
|
304
|
-
|
|
305
|
-
**Tre-fase Testprosess**:
|
|
306
|
-
|
|
307
|
-
| Fase | Beskrivelse | Kontrollpunkt |
|
|
308
|
-
|------|----------|-------------------|
|
|
309
|
-
| Testtilfelldesign | Generer testtilfeller basert på PRD og Feature Spec | A: Vis testtilfelde-dekningsstatistikk og sporbarhetsmatrise, vent på brukerbekreftelse på tilstrekkelig dekning |
|
|
310
|
-
| Testkodegenerering | Generer kjørbart testkode | B: Vis genererte testfiler og用例-mapping, vent på brukerbekreftelse |
|
|
311
|
-
| Testutførelse og Feilrapport | Utfør tester automatisk og generer rapporter | Ingen (automatisk utførelse) |
|
|
312
|
-
|
|
313
|
-
**Leveranse**:
|
|
314
|
-
```
|
|
315
|
-
iterations/{iter}/06.system-test/
|
|
316
|
-
├── cases/
|
|
317
|
-
│ └── {platform-id}/ # Testtilfelldokumenter
|
|
318
|
-
├── code/
|
|
319
|
-
│ └── {platform-id}/ # Testkodeplan
|
|
320
|
-
├── reports/
|
|
321
|
-
│ └── test-report-{date}.md # Testrapport
|
|
322
|
-
└── bugs/
|
|
323
|
-
└── BUG-{id}-{title}.md # Feilrapporter (én fil per feil)
|
|
324
|
-
```
|
|
325
|
-
|
|
326
|
-
**Bekreftelseskontrollliste**:
|
|
327
|
-
- [ ] Er testtilfelledekning komplett?
|
|
328
|
-
- [ ] Er testkoden kjørbar?
|
|
329
|
-
- [ ] Er feilalvorlighetsvurdering nøyaktig?
|
|
330
|
-
|
|
331
|
-
---
|
|
332
|
-
|
|
333
|
-
### 4.7 Fase 7: Arkivering
|
|
334
|
-
|
|
335
|
-
Iterasjoner arkiveres automatisk når de er fullført:
|
|
336
|
-
|
|
337
|
-
```
|
|
338
|
-
speccrew-workspace/iteration-archives/
|
|
339
|
-
└── {nummer}-{type}-{navn}-{dato}/
|
|
340
|
-
├── 01.product-requirement/
|
|
341
|
-
├── 02.feature-design/
|
|
342
|
-
├── 03.system-design/
|
|
343
|
-
├── 04.development/
|
|
344
|
-
├── 05.deployment/
|
|
345
|
-
└── 06.system-test/
|
|
346
|
-
```
|
|
347
|
-
|
|
348
|
-
---
|
|
349
|
-
|
|
350
|
-
## 5. Kunnskapsbaseoversikt
|
|
351
|
-
|
|
352
|
-
### 5.1 Forretningskunnskapsbase (bizs)
|
|
353
|
-
|
|
354
|
-
**Formål**: Lagre prosjektets forretningsfunksjonsbeskrivelser, moduloppdelinger, API-kjennetegn
|
|
355
|
-
|
|
356
|
-
**Katalogstruktur**:
|
|
357
|
-
```
|
|
358
|
-
knowledges/bizs/
|
|
359
|
-
├── {platform-type}/
|
|
360
|
-
│ └── {module-name}/
|
|
361
|
-
│ └── feature-spec.md
|
|
362
|
-
└── system-overview.md
|
|
363
|
-
```
|
|
364
|
-
|
|
365
|
-
**Bruksscenarier**: Product Manager, Feature Designer
|
|
366
|
-
|
|
367
|
-
### 5.2 Teknisk Kunnskapsbase (techs)
|
|
368
|
-
|
|
369
|
-
**Formål**: Lagre prosjektets teknologistabel, arkitekturkonvensjoner, utviklingsspesifikasjoner, testspesifikasjoner
|
|
370
|
-
|
|
371
|
-
**Katalogstruktur**:
|
|
372
|
-
```
|
|
373
|
-
knowledges/techs/{platform-id}/
|
|
374
|
-
├── tech-stack.md
|
|
375
|
-
├── architecture.md
|
|
376
|
-
├── dev-spec.md
|
|
377
|
-
├── test-spec.md
|
|
378
|
-
└── INDEX.md
|
|
379
|
-
```
|
|
380
|
-
|
|
381
|
-
**Bruksscenarier**: System Designer, System Developer, Test Manager
|
|
382
|
-
|
|
383
|
-
---
|
|
384
|
-
|
|
385
|
-
## 6. Arbeidsflytforløpsstyring
|
|
386
|
-
|
|
387
|
-
Det virtuelle SpecCrew-teamet følger en streng fase-port-mekanisme hvor hver fase må bekreftes av brukeren før man fortsetter til den neste. Det støtter også gjenopptakbar utførelse — når det startes på nytt etter avbrudd, fortsetter det automatisk fra hvor det slapp.
|
|
388
|
-
|
|
389
|
-
### 6.1 Trelagsforløpsfiler
|
|
390
|
-
|
|
391
|
-
Arbeidsflyten vedlikeholder automatisk tre typer JSON-forløpsfiler, plassert i iterasjonskatalogen:
|
|
392
|
-
|
|
393
|
-
| Fil | Plassering | Formål |
|
|
394
|
-
|------|----------|---------|
|
|
395
|
-
| `WORKFLOW-PROGRESS.json` | `iterations/{iter}/` | Registrerer status for hver pipeline-fase |
|
|
396
|
-
| `.checkpoints.json` | Under hver fasekatalog | Registrerer brukerens sjekkpunkt-bekreftelsesstatus |
|
|
397
|
-
| `DISPATCH-PROGRESS.json` | Under hver fasekatalog | Registrerer punkt-for-punkt forløp for parallelle oppgaver (multi-plattform/multi-modul) |
|
|
398
|
-
|
|
399
|
-
### 6.2 Fasestatusforløp
|
|
400
|
-
|
|
401
|
-
Hver fase følger dette statusforløpet:
|
|
402
|
-
|
|
403
|
-
```
|
|
404
|
-
pending → in_progress → completed → confirmed
|
|
405
|
-
```
|
|
406
|
-
|
|
407
|
-
- **pending**: Ikke startet ennå
|
|
408
|
-
- **in_progress**: Utføres for øyeblikket
|
|
409
|
-
- **completed**: Agent-utførelse fullført, venter på brukerbekreftelse
|
|
410
|
-
- **confirmed**: Bruker bekreftet gjennom siste sjekkpunkt, neste fase kan starte
|
|
411
|
-
|
|
412
|
-
### 6.3 Gjenopptakbar Utførelse
|
|
413
|
-
|
|
414
|
-
Når en Agent startes på nytt for en fase:
|
|
415
|
-
|
|
416
|
-
1. **Automatisk oppstrømskontroll**: Verifiserer om den forrige fasen er bekreftet, blokkerer og varsler hvis ikke
|
|
417
|
-
2. **Sjekkpunkt-gjenoppretting**: Leser `.checkpoints.json`, hopper over passerte sjekkpunkter, fortsetter fra det siste avbruddspunktet
|
|
418
|
-
3. **Parallell oppgave-gjenoppretting**: Leser `DISPATCH-PROGRESS.json`, utfører kun oppgaver med `pending` eller `failed` status på nytt, hopper over `completed` oppgaver
|
|
419
|
-
|
|
420
|
-
### 6.4 Vise Nåværende Forløp
|
|
421
|
-
|
|
422
|
-
Vis pipeline-panorama-status gjennom Team Leader Agent:
|
|
423
|
-
|
|
424
|
-
```
|
|
425
|
-
@speccrew-team-leader vis nåværende iterasjonsforløp
|
|
426
|
-
```
|
|
427
|
-
|
|
428
|
-
Team Leader vil lese forløpsfilene og vise en statusoversikt som ligner på:
|
|
429
|
-
|
|
430
|
-
```
|
|
431
|
-
Pipeline Status: i001-user-management
|
|
432
|
-
01 PRD: ✅ Bekreftet
|
|
433
|
-
02 Feature Design: 🔄 Pågår (Sjekkpunkt A passert)
|
|
434
|
-
03 System Design: ⏳ Avventer
|
|
435
|
-
04 Development: ⏳ Avventer
|
|
436
|
-
05 Deployment: ⏳ Avventer
|
|
437
|
-
06 System Test: ⏳ Avventer
|
|
438
|
-
```
|
|
439
|
-
|
|
440
|
-
### 6.5 Bakoverkompatibilitet
|
|
441
|
-
|
|
442
|
-
Forløpsfil-mekanismen er fullstendig bakoverkompatibel — hvis forløpsfiler ikke finnes (f.eks. i eldre prosjekter eller nye iterasjoner), vil alle Agenter utføre normalt i henhold til den opprinnelige logikken.
|
|
443
|
-
|
|
444
|
-
---
|
|
445
|
-
|
|
446
|
-
## 7. Ofte Stilte Spørsmål (FAQ)
|
|
447
|
-
|
|
448
|
-
### S1: Hva gjør jeg hvis Agenten ikke fungerer som forventet?
|
|
449
|
-
|
|
450
|
-
1. Kjør `speccrew doctor` for å sjekke installasjonsintegritet
|
|
451
|
-
2. Bekreft at kunnskapsbasen er initialisert
|
|
452
|
-
3. Bekreft at forrige fases leveranse finnes i gjeldende iterasjonskatalog
|
|
453
|
-
|
|
454
|
-
### S2: Hvordan hoppe over en fase?
|
|
455
|
-
|
|
456
|
-
**Anbefales ikke** — Hver fases output er input for neste fase.
|
|
457
|
-
|
|
458
|
-
Hvis du må hoppe over, forbered manuelt input-dokumentet for den tilsvarende fasen og sørg for at det følger formatspesifikasjoner.
|
|
459
|
-
|
|
460
|
-
### S3: Hvordan håndtere flere parallelle krav?
|
|
461
|
-
|
|
462
|
-
Opprett uavhengige iterasjonskataloger for hvert krav:
|
|
463
|
-
```
|
|
464
|
-
iterations/
|
|
465
|
-
├── 001-feature-xxx/
|
|
466
|
-
├── 002-feature-yyy/
|
|
467
|
-
└── 003-feature-zzz/
|
|
468
|
-
```
|
|
469
|
-
|
|
470
|
-
Hver iterasjon er fullstendig isolert og påvirker ikke hverandre.
|
|
471
|
-
|
|
472
|
-
### S4: Hvordan oppdatere SpecCrew-versjonen?
|
|
473
|
-
|
|
474
|
-
Oppdatering krever to trinn:
|
|
475
|
-
|
|
476
|
-
```bash
|
|
477
|
-
# Trinn 1: Oppdater globalt CLI-verktøy
|
|
478
|
-
npm install -g speccrew@latest
|
|
479
|
-
|
|
480
|
-
# Trinn 2: Synkroniser Agenter og Skills i prosjektkatalogen din
|
|
481
|
-
cd /path/to/your-project
|
|
482
|
-
speccrew update
|
|
483
|
-
```
|
|
484
|
-
|
|
485
|
-
- `npm install -g speccrew@latest`: Oppdaterer selve CLI-verktøyet (nye versjoner kan inkludere nye Agent/Skill-definisjoner, feilrettelser osv.)
|
|
486
|
-
- `speccrew update`: Synkroniserer Agent- og Skill-definisjonsfiler i prosjektet ditt til den nyeste versjonen
|
|
487
|
-
- `speccrew update --ide cursor`: Oppdaterer konfigurasjon kun for en spesifikk IDE
|
|
488
|
-
|
|
489
|
-
> **Merk**: Begge trinnene er nødvendige. Hvis du bare kjører `speccrew update`, oppdateres ikke selve CLI-verktøyet; hvis du bare kjører `npm install`, oppdateres ikke prosjektfilene.
|
|
490
|
-
|
|
491
|
-
### S5: `speccrew update` viser at ny versjon er tilgjengelig, men `npm install -g speccrew@latest` installerer fortsatt den gamle versjonen?
|
|
492
|
-
|
|
493
|
-
Årsak: npm cache-problem. Løsning:
|
|
494
|
-
|
|
495
|
-
```bash
|
|
496
|
-
npm cache clean --force
|
|
497
|
-
npm install -g speccrew@latest
|
|
498
|
-
npm list -g speccrew
|
|
499
|
-
```
|
|
500
|
-
|
|
501
|
-
Hvis det fortsatt ikke fungerer, spesifiser versjon:
|
|
502
|
-
|
|
503
|
-
```bash
|
|
504
|
-
npm install -g speccrew@0.5.6
|
|
505
|
-
```
|
|
506
|
-
|
|
507
|
-
### S6: Hvordan se historiske iterasjoner?
|
|
508
|
-
|
|
509
|
-
Etter arkivering, se i `speccrew-workspace/iteration-archives/`, organisert i formatet `{nummer}-{type}-{navn}-{dato}/`.
|
|
510
|
-
|
|
511
|
-
### S6: Trenger kunnskapsbasen regelmessig oppdatering?
|
|
512
|
-
|
|
513
|
-
Re-initialisering kreves i følgende situasjoner:
|
|
514
|
-
- Betydelige endringer i prosjektstruktur
|
|
515
|
-
- Oppdatering eller erstatning av teknologistabel
|
|
516
|
-
- Legge til/fjerne forretningsmoduler
|
|
517
|
-
|
|
518
|
-
---
|
|
519
|
-
|
|
520
|
-
## 8. Hurtigreferanse
|
|
521
|
-
|
|
522
|
-
### Agent-start Hurtigreferanse
|
|
523
|
-
|
|
524
|
-
| Fase | Agent | Startdialog |
|
|
525
|
-
|------|-------|-------------------|
|
|
526
|
-
| Initialisering | Team Leader | `@speccrew-team-leader initialiser teknisk kunnskapsbase` |
|
|
527
|
-
| Kravanalyse | Product Manager | `@speccrew-product-manager jeg har et nytt krav: [beskrivelse]` |
|
|
528
|
-
| Funksjonsdesign | Feature Designer | `@speccrew-feature-designer start funksjonsdesign` |
|
|
529
|
-
| Systemdesign | System Designer | `@speccrew-system-designer start systemdesign` |
|
|
530
|
-
| Utvikling | System Developer | `@speccrew-system-developer start utvikling` |
|
|
531
|
-
| Utrulling | System Deployer | `@speccrew-system-deployer start utrulling` |
|
|
532
|
-
| Systemtesting | Test Manager | `@speccrew-test-manager start testing` |
|
|
533
|
-
|
|
534
|
-
### Kontrollpunkter Kontrollliste
|
|
535
|
-
|
|
536
|
-
| Fase | Antall Kontrollpunkter | Nøkkelelementer for Verifisering |
|
|
537
|
-
|------|------------------------|--------------------------------|
|
|
538
|
-
| Kravanalyse | 1 | Kravnøyaktighet, forretningsregler kompletthet, akseptkriterier målbarhet |
|
|
539
|
-
| Funksjonsdesign | 1 | Szenariedekning, interaksjonsklarhet, datakompletthet, unntakshåndtering |
|
|
540
|
-
| Systemdesign | 2 | A: Rammeverkvurdering; B: Pseudokodesyntaks, cross-plattform konsistens, feilhåndtering |
|
|
541
|
-
| Utvikling | 1 | A: Miljøklarhet, integrasjonsproblemer, kodespesifikasjoner |
|
|
542
|
-
| Utrulling | 1 | Bygging vellykket, migrering fullført, tjenestestart, røyktest bestått |
|
|
543
|
-
| Systemtesting | 2 | A: Tilfelledekning; B: Testkodekjørbarhet |
|
|
544
|
-
|
|
545
|
-
### Leveransesti Hurtigreferanse
|
|
546
|
-
|
|
547
|
-
| Fase | Output-katalog | Filformat |
|
|
548
|
-
|------|------------------|-------------|
|
|
549
|
-
| Kravanalyse | `iterations/{iter}/01.product-requirement/` | `[name]-prd.md`, `[name]-bizs-modeling.md` |
|
|
550
|
-
| Funksjonsdesign | `iterations/{iter}/02.feature-design/` | `[name]-feature-spec.md` |
|
|
551
|
-
| Systemdesign | `iterations/{iter}/03.system-design/` | `DESIGN-OVERVIEW.md`, `{platform}/INDEX.md`, `{platform}/{module}-design.md` |
|
|
552
|
-
| Utvikling | `iterations/{iter}/04.development/` | Kildekode + `delivery-report.md` |
|
|
553
|
-
| Utrulling | `iterations/{iter}/05.deployment/` | `deployment-plan.md`, `deployment-log.md`, `deployment-report.md` |
|
|
554
|
-
| Systemtesting | `iterations/{iter}/06.system-test/` | `cases/`, `code/`, `reports/`, `bugs/` |
|
|
555
|
-
| Arkivering | `iteration-archives/{iter}-{dato}/` | Fullstendig kopi av iterasjonen |
|
|
556
|
-
|
|
557
|
-
---
|
|
558
|
-
|
|
559
|
-
## Neste Steg
|
|
560
|
-
|
|
561
|
-
1. Kjør `speccrew init --ide qoder` for å initialisere prosjektet ditt
|
|
562
|
-
2. Utfør Null Steg: Kunnskapsbase-initialisering
|
|
563
|
-
3. Beveg deg gjennom hver fase etter arbeidsflyten, nyt spesifikasjonsdrevet utviklingserfaring!
|