claudeos-core 2.0.2 → 2.1.0
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/CHANGELOG.md +178 -0
- package/README.de.md +994 -880
- package/README.es.md +993 -880
- package/README.fr.md +993 -880
- package/README.hi.md +993 -880
- package/README.ja.md +993 -880
- package/README.ko.md +159 -47
- package/README.md +159 -46
- package/README.ru.md +993 -880
- package/README.vi.md +161 -48
- package/README.zh-CN.md +992 -880
- package/bin/cli.js +7 -2
- package/bin/commands/init.js +733 -143
- package/bin/commands/memory.js +17 -5
- package/bootstrap.sh +81 -81
- package/lib/expected-outputs.js +6 -7
- package/lib/memory-scaffold.js +84 -46
- package/lib/plan-parser.js +12 -0
- package/manifest-generator/index.js +16 -18
- package/package.json +1 -1
- package/pass-prompts/templates/angular/pass3.md +2 -10
- package/pass-prompts/templates/common/pass3-phase1.md +131 -0
- package/pass-prompts/templates/common/pass3a-facts.md +143 -0
- package/pass-prompts/templates/common/pass3b-core-header.md +58 -0
- package/pass-prompts/templates/common/pass3c-skills-guide-header.md +53 -0
- package/pass-prompts/templates/common/pass3d-plan-aux-header.md +57 -0
- package/pass-prompts/templates/common/pass4.md +4 -19
- package/pass-prompts/templates/java-spring/pass3.md +5 -15
- package/pass-prompts/templates/kotlin-spring/pass3.md +5 -15
- package/pass-prompts/templates/node-express/pass3.md +5 -14
- package/pass-prompts/templates/node-fastify/pass3.md +2 -10
- package/pass-prompts/templates/node-nestjs/pass3.md +5 -13
- package/pass-prompts/templates/node-nextjs/pass3.md +5 -14
- package/pass-prompts/templates/node-vite/pass3.md +95 -103
- package/pass-prompts/templates/python-django/pass3.md +5 -14
- package/pass-prompts/templates/python-fastapi/pass3.md +5 -14
- package/pass-prompts/templates/python-flask/pass3.md +95 -103
- package/pass-prompts/templates/vue-nuxt/pass3.md +2 -10
- package/plan-installer/pass3-context-builder.js +258 -0
- package/plan-installer/prompt-generator.js +9 -1
- package/plan-validator/index.js +23 -8
- package/sync-checker/index.js +44 -0
package/README.de.md
CHANGED
|
@@ -1,880 +1,994 @@
|
|
|
1
|
-
# ClaudeOS-Core
|
|
2
|
-
|
|
3
|
-
**Das einzige Tool, das zuerst Ihren Quellcode liest, Ihren Stack und Ihre Muster mit deterministischer Analyse bestätigt und dann Claude-Code-Regeln generiert, die exakt auf Ihr Projekt zugeschnitten sind.**
|
|
4
|
-
|
|
5
|
-
```bash
|
|
6
|
-
npx claudeos-core init
|
|
7
|
-
```
|
|
8
|
-
|
|
9
|
-
ClaudeOS-Core liest Ihre Codebasis, extrahiert jedes Muster, das es findet, und generiert einen vollständigen Satz von Standards, Rules, Skills und Guides, die auf _Ihr_ Projekt zugeschnitten sind. Wenn Sie danach Claude Code sagen „Erstelle ein CRUD für Bestellungen", erzeugt er Code, der exakt Ihren bestehenden Mustern entspricht.
|
|
10
|
-
|
|
11
|
-
[🇺🇸 English](./README.md) · [🇰🇷 한국어](./README.ko.md) · [🇨🇳 中文](./README.zh-CN.md) · [🇯🇵 日本語](./README.ja.md) · [🇪🇸 Español](./README.es.md) · [🇻🇳 Tiếng Việt](./README.vi.md) · [🇮🇳 हिन्दी](./README.hi.md) · [🇷🇺 Русский](./README.ru.md) · [🇫🇷 Français](./README.fr.md)
|
|
12
|
-
|
|
13
|
-
---
|
|
14
|
-
|
|
15
|
-
##
|
|
16
|
-
|
|
17
|
-
|
|
18
|
-
|
|
19
|
-
|
|
20
|
-
|
|
21
|
-
|
|
22
|
-
|
|
23
|
-
|
|
24
|
-
|
|
25
|
-
|
|
26
|
-
|
|
27
|
-
|
|
28
|
-
|
|
29
|
-
|
|
30
|
-
|
|
31
|
-
|
|
32
|
-
|
|
33
|
-
**
|
|
34
|
-
|
|
35
|
-
-
|
|
36
|
-
|
|
37
|
-
|
|
38
|
-
|
|
39
|
-
|
|
40
|
-
|
|
41
|
-
|
|
42
|
-
|
|
43
|
-
|
|
44
|
-
|
|
45
|
-
|
|
46
|
-
|
|
47
|
-
|
|
48
|
-
|
|
49
|
-
|
|
50
|
-
|
|
51
|
-
|
|
52
|
-
|
|
53
|
-
|
|
54
|
-
|
|
55
|
-
|
|
56
|
-
|
|
57
|
-
|
|
58
|
-
|
|
59
|
-
|
|
60
|
-
|
|
61
|
-
|
|
62
|
-
|
|
63
|
-
|
|
64
|
-
|
|
65
|
-
|
|
66
|
-
|
|
67
|
-
|
|
68
|
-
|
|
69
|
-
|
|
70
|
-
|
|
71
|
-
|
|
72
|
-
|
|
73
|
-
|
|
74
|
-
|
|
75
|
-
|
|
76
|
-
|
|
77
|
-
|
|
78
|
-
|
|
79
|
-
|
|
80
|
-
|
|
81
|
-
|
|
82
|
-
|
|
83
|
-
|
|
84
|
-
|
|
85
|
-
|
|
86
|
-
|
|
87
|
-
|
|
88
|
-
|
|
89
|
-
|
|
90
|
-
**
|
|
91
|
-
|
|
92
|
-
|
|
93
|
-
|
|
94
|
-
|
|
|
95
|
-
|
|
96
|
-
|
|
|
97
|
-
|
|
|
98
|
-
|
|
|
99
|
-
|
|
|
100
|
-
|
|
|
101
|
-
|
|
102
|
-
|
|
103
|
-
|
|
104
|
-
|
|
105
|
-
|
|
106
|
-
|
|
107
|
-
|
|
108
|
-
|
|
|
109
|
-
|
|
110
|
-
|
|
|
111
|
-
|
|
|
112
|
-
|
|
|
113
|
-
|
|
|
114
|
-
|
|
|
115
|
-
|
|
116
|
-
|
|
117
|
-
|
|
118
|
-
###
|
|
119
|
-
|
|
120
|
-
-
|
|
121
|
-
|
|
122
|
-
|
|
123
|
-
|
|
124
|
-
|
|
125
|
-
|
|
126
|
-
|
|
127
|
-
|
|
128
|
-
|
|
129
|
-
|
|
130
|
-
|
|
131
|
-
|
|
132
|
-
###
|
|
133
|
-
|
|
134
|
-
|
|
135
|
-
|
|
136
|
-
|
|
137
|
-
|
|
138
|
-
|
|
139
|
-
|
|
140
|
-
|
|
141
|
-
|
|
142
|
-
|
|
143
|
-
|
|
144
|
-
|
|
145
|
-
|
|
146
|
-
|
|
147
|
-
|
|
148
|
-
|
|
149
|
-
|
|
150
|
-
|
|
151
|
-
|
|
152
|
-
|
|
153
|
-
|
|
154
|
-
|
|
155
|
-
|
|
156
|
-
|
|
157
|
-
|
|
158
|
-
|
|
159
|
-
|
|
160
|
-
|
|
161
|
-
|
|
162
|
-
|
|
163
|
-
|
|
164
|
-
|
|
165
|
-
|
|
166
|
-
|
|
167
|
-
|
|
168
|
-
|
|
169
|
-
|
|
170
|
-
|
|
171
|
-
|
|
172
|
-
|
|
173
|
-
|
|
174
|
-
|
|
175
|
-
|
|
176
|
-
|
|
177
|
-
|
|
178
|
-
|
|
179
|
-
|
|
180
|
-
|
|
181
|
-
|
|
182
|
-
#
|
|
183
|
-
|
|
184
|
-
|
|
185
|
-
#
|
|
186
|
-
|
|
187
|
-
|
|
188
|
-
|
|
189
|
-
|
|
190
|
-
|
|
191
|
-
|
|
192
|
-
|
|
193
|
-
|
|
194
|
-
|
|
195
|
-
|
|
196
|
-
|
|
197
|
-
|
|
198
|
-
|
|
199
|
-
|
|
200
|
-
|
|
201
|
-
|
|
202
|
-
|
|
203
|
-
|
|
204
|
-
|
|
205
|
-
|
|
206
|
-
|
|
207
|
-
|
|
208
|
-
|
|
209
|
-
|
|
210
|
-
|
|
211
|
-
|
|
212
|
-
|
|
213
|
-
|
|
214
|
-
|
|
215
|
-
|
|
216
|
-
|
|
217
|
-
|
|
218
|
-
|
|
219
|
-
|
|
220
|
-
|
|
221
|
-
|
|
222
|
-
|
|
223
|
-
|
|
224
|
-
|
|
225
|
-
|
|
226
|
-
|
|
227
|
-
|
|
228
|
-
|
|
229
|
-
|
|
230
|
-
|
|
231
|
-
|
|
232
|
-
|
|
233
|
-
|
|
234
|
-
|
|
235
|
-
|
|
236
|
-
|
|
237
|
-
|
|
238
|
-
|
|
239
|
-
|
|
240
|
-
|
|
241
|
-
|
|
242
|
-
|
|
243
|
-
|
|
244
|
-
|
|
245
|
-
|
|
246
|
-
|
|
247
|
-
|
|
248
|
-
|
|
249
|
-
|
|
250
|
-
|
|
251
|
-
|
|
252
|
-
|
|
253
|
-
|
|
254
|
-
|
|
255
|
-
|
|
256
|
-
|
|
257
|
-
|
|
258
|
-
|
|
259
|
-
|
|
260
|
-
|
|
261
|
-
|
|
262
|
-
|
|
263
|
-
|
|
264
|
-
|
|
265
|
-
|
|
266
|
-
|
|
267
|
-
-
|
|
268
|
-
-
|
|
269
|
-
|
|
270
|
-
|
|
271
|
-
|
|
272
|
-
|
|
273
|
-
|
|
274
|
-
|
|
275
|
-
|
|
276
|
-
|
|
277
|
-
|
|
278
|
-
|
|
279
|
-
```
|
|
280
|
-
|
|
281
|
-
|
|
282
|
-
|
|
283
|
-
|
|
284
|
-
|
|
285
|
-
|
|
286
|
-
|
|
287
|
-
|
|
288
|
-
|
|
289
|
-
|
|
290
|
-
|
|
291
|
-
|
|
292
|
-
|
|
293
|
-
|
|
294
|
-
|
|
295
|
-
|
|
296
|
-
|
|
297
|
-
|
|
298
|
-
|
|
299
|
-
|
|
300
|
-
|
|
301
|
-
|
|
302
|
-
|
|
303
|
-
|
|
304
|
-
|
|
305
|
-
|
|
306
|
-
|
|
307
|
-
|
|
308
|
-
|
|
309
|
-
"
|
|
310
|
-
|
|
311
|
-
|
|
312
|
-
|
|
313
|
-
|
|
314
|
-
|
|
315
|
-
|
|
316
|
-
|
|
317
|
-
|
|
318
|
-
|
|
319
|
-
|
|
320
|
-
|
|
321
|
-
|
|
322
|
-
|
|
323
|
-
|
|
324
|
-
|
|
325
|
-
|
|
326
|
-
|
|
327
|
-
|
|
328
|
-
|
|
329
|
-
|
|
330
|
-
|
|
331
|
-
|
|
332
|
-
|
|
333
|
-
|
|
334
|
-
|
|
335
|
-
|
|
336
|
-
|
|
337
|
-
|
|
338
|
-
```
|
|
339
|
-
|
|
340
|
-
|
|
341
|
-
|
|
342
|
-
|
|
343
|
-
|
|
344
|
-
|
|
345
|
-
|
|
346
|
-
|
|
347
|
-
|
|
348
|
-
|
|
349
|
-
|
|
350
|
-
|
|
351
|
-
|
|
352
|
-
|
|
353
|
-
|
|
354
|
-
|
|
355
|
-
|
|
356
|
-
|
|
357
|
-
|
|
358
|
-
|
|
359
|
-
|
|
360
|
-
|
|
361
|
-
|
|
362
|
-
|
|
363
|
-
|
|
364
|
-
|
|
365
|
-
|
|
366
|
-
#
|
|
367
|
-
|
|
368
|
-
|
|
369
|
-
|
|
370
|
-
|
|
371
|
-
|
|
372
|
-
|
|
373
|
-
|
|
374
|
-
|
|
375
|
-
|
|
376
|
-
|
|
377
|
-
```
|
|
378
|
-
|
|
379
|
-
|
|
380
|
-
|
|
381
|
-
|
|
382
|
-
|
|
383
|
-
|
|
384
|
-
|
|
385
|
-
|
|
386
|
-
|
|
387
|
-
|
|
388
|
-
|
|
389
|
-
|
|
390
|
-
|
|
391
|
-
|
|
392
|
-
|
|
393
|
-
|
|
394
|
-
|
|
395
|
-
|
|
396
|
-
|
|
397
|
-
|
|
398
|
-
|
|
399
|
-
|
|
400
|
-
|
|
401
|
-
|
|
402
|
-
|
|
403
|
-
|
|
404
|
-
|
|
405
|
-
|
|
406
|
-
|
|
407
|
-
|
|
408
|
-
|
|
409
|
-
|
|
410
|
-
|
|
411
|
-
|
|
412
|
-
|
|
413
|
-
|
|
414
|
-
|
|
415
|
-
|
|
416
|
-
|
|
417
|
-
|
|
418
|
-
|
|
419
|
-
|
|
420
|
-
|
|
421
|
-
|
|
422
|
-
|
|
423
|
-
|
|
424
|
-
|
|
425
|
-
|
|
426
|
-
|
|
427
|
-
|
|
428
|
-
|
|
429
|
-
|
|
430
|
-
|
|
431
|
-
|
|
432
|
-
|
|
433
|
-
|
|
434
|
-
|
|
435
|
-
|
|
436
|
-
|
|
437
|
-
|
|
438
|
-
|
|
439
|
-
|
|
440
|
-
|
|
441
|
-
|
|
442
|
-
│
|
|
443
|
-
├──
|
|
444
|
-
│
|
|
445
|
-
|
|
446
|
-
|
|
447
|
-
│ ├──
|
|
448
|
-
│
|
|
449
|
-
│
|
|
450
|
-
|
|
451
|
-
│
|
|
452
|
-
│
|
|
453
|
-
|
|
454
|
-
│
|
|
455
|
-
├──
|
|
456
|
-
│
|
|
457
|
-
│
|
|
458
|
-
│
|
|
459
|
-
│
|
|
460
|
-
│
|
|
461
|
-
│
|
|
462
|
-
│
|
|
463
|
-
│
|
|
464
|
-
│
|
|
465
|
-
│
|
|
466
|
-
|
|
467
|
-
│
|
|
468
|
-
│
|
|
469
|
-
│
|
|
470
|
-
│
|
|
471
|
-
│
|
|
472
|
-
|
|
473
|
-
|
|
474
|
-
|
|
475
|
-
|
|
476
|
-
|
|
477
|
-
|
|
478
|
-
|
|
479
|
-
|
|
480
|
-
|
|
481
|
-
|
|
482
|
-
|
|
483
|
-
|
|
484
|
-
|
|
485
|
-
|
|
486
|
-
|
|
487
|
-
|
|
488
|
-
|
|
489
|
-
|
|
490
|
-
|
|
491
|
-
|
|
492
|
-
|
|
493
|
-
|
|
494
|
-
|
|
495
|
-
|
|
496
|
-
|
|
497
|
-
|
|
498
|
-
-
|
|
499
|
-
|
|
500
|
-
|
|
501
|
-
|
|
502
|
-
|
|
503
|
-
|
|
504
|
-
|
|
505
|
-
|
|
506
|
-
|
|
507
|
-
|
|
508
|
-
|
|
509
|
-
|
|
510
|
-
|
|
511
|
-
|
|
512
|
-
|
|
513
|
-
|
|
514
|
-
|
|
515
|
-
|
|
516
|
-
|
|
517
|
-
|
|
518
|
-
|
|
519
|
-
|
|
520
|
-
|
|
521
|
-
|
|
522
|
-
|
|
523
|
-
|
|
524
|
-
|
|
525
|
-
|
|
526
|
-
|
|
527
|
-
|
|
528
|
-
|
|
529
|
-
|
|
530
|
-
|
|
531
|
-
|
|
532
|
-
|
|
533
|
-
|
|
534
|
-
|
|
535
|
-
|
|
536
|
-
|
|
537
|
-
|
|
538
|
-
|
|
539
|
-
|
|
540
|
-
|
|
541
|
-
|
|
542
|
-
|
|
543
|
-
|
|
544
|
-
|
|
545
|
-
|
|
546
|
-
|
|
547
|
-
|
|
548
|
-
|
|
549
|
-
|
|
550
|
-
|
|
551
|
-
|
|
552
|
-
|
|
553
|
-
|
|
554
|
-
|
|
555
|
-
|
|
556
|
-
|
|
557
|
-
|
|
558
|
-
###
|
|
559
|
-
|
|
560
|
-
|
|
561
|
-
|
|
562
|
-
|
|
563
|
-
|
|
564
|
-
|
|
565
|
-
|
|
566
|
-
|
|
567
|
-
|
|
568
|
-
|
|
569
|
-
|
|
570
|
-
|
|
571
|
-
|
|
572
|
-
|
|
573
|
-
|
|
574
|
-
|
|
575
|
-
|
|
576
|
-
|
|
577
|
-
|
|
578
|
-
|
|
579
|
-
|
|
580
|
-
|
|
581
|
-
|
|
582
|
-
|
|
583
|
-
|
|
584
|
-
|
|
585
|
-
|
|
|
586
|
-
|
|
587
|
-
|
|
|
588
|
-
|
|
|
589
|
-
|
|
590
|
-
|
|
591
|
-
|
|
592
|
-
|
|
593
|
-
|
|
594
|
-
|
|
595
|
-
|
|
596
|
-
|
|
597
|
-
|
|
598
|
-
|
|
599
|
-
|
|
600
|
-
|
|
601
|
-
|
|
602
|
-
|
|
603
|
-
|
|
604
|
-
|
|
605
|
-
|
|
606
|
-
|
|
607
|
-
|
|
608
|
-
|
|
609
|
-
|
|
610
|
-
|
|
611
|
-
|
|
612
|
-
|
|
613
|
-
|
|
614
|
-
|
|
615
|
-
|
|
616
|
-
|
|
617
|
-
|
|
618
|
-
```bash
|
|
619
|
-
#
|
|
620
|
-
npx claudeos-core
|
|
621
|
-
|
|
622
|
-
|
|
623
|
-
|
|
624
|
-
|
|
625
|
-
|
|
626
|
-
|
|
627
|
-
|
|
628
|
-
|
|
629
|
-
|
|
630
|
-
|
|
631
|
-
|
|
632
|
-
|
|
633
|
-
|
|
634
|
-
|
|
635
|
-
|
|
636
|
-
|
|
637
|
-
|
|
638
|
-
|
|
639
|
-
|
|
640
|
-
|
|
641
|
-
|
|
642
|
-
|
|
643
|
-
|
|
644
|
-
|
|
645
|
-
|
|
646
|
-
|
|
647
|
-
|
|
648
|
-
|
|
649
|
-
|
|
650
|
-
|
|
651
|
-
|
|
652
|
-
|
|
653
|
-
|
|
654
|
-
|
|
655
|
-
|
|
656
|
-
|
|
657
|
-
|
|
658
|
-
|
|
659
|
-
|
|
660
|
-
|
|
661
|
-
|
|
662
|
-
|
|
663
|
-
|
|
664
|
-
|
|
665
|
-
|
|
666
|
-
|
|
667
|
-
|
|
668
|
-
|
|
669
|
-
|
|
670
|
-
|
|
671
|
-
|
|
672
|
-
|
|
673
|
-
|
|
674
|
-
|
|
675
|
-
|
|
|
676
|
-
|
|
677
|
-
|
|
|
678
|
-
|
|
|
679
|
-
|
|
|
680
|
-
|
|
|
681
|
-
|
|
|
682
|
-
|
|
683
|
-
|
|
684
|
-
|
|
685
|
-
|
|
686
|
-
|
|
687
|
-
###
|
|
688
|
-
|
|
689
|
-
|
|
690
|
-
|
|
691
|
-
|
|
692
|
-
|
|
693
|
-
|
|
694
|
-
|
|
695
|
-
|
|
696
|
-
|
|
697
|
-
|
|
698
|
-
|
|
699
|
-
|
|
700
|
-
|
|
701
|
-
|
|
702
|
-
|
|
703
|
-
|
|
704
|
-
|
|
705
|
-
|
|
706
|
-
|
|
707
|
-
|
|
708
|
-
|
|
709
|
-
|
|
710
|
-
|
|
711
|
-
|
|
712
|
-
|
|
713
|
-
|
|
714
|
-
|
|
715
|
-
|
|
716
|
-
|
|
717
|
-
|
|
718
|
-
|
|
719
|
-
|
|
720
|
-
|
|
721
|
-
|
|
722
|
-
|
|
723
|
-
|
|
724
|
-
|
|
725
|
-
|
|
726
|
-
|
|
727
|
-
|
|
728
|
-
|
|
729
|
-
|
|
730
|
-
|
|
731
|
-
|
|
732
|
-
|
|
733
|
-
|
|
734
|
-
|
|
735
|
-
|
|
736
|
-
|
|
737
|
-
|
|
738
|
-
|
|
739
|
-
|
|
740
|
-
|
|
741
|
-
|
|
742
|
-
|
|
743
|
-
|
|
744
|
-
|
|
745
|
-
|
|
746
|
-
|
|
747
|
-
|
|
748
|
-
|
|
749
|
-
|
|
750
|
-
|
|
751
|
-
**
|
|
752
|
-
|
|
753
|
-
|
|
754
|
-
|
|
755
|
-
|
|
756
|
-
|
|
757
|
-
|
|
758
|
-
|
|
759
|
-
|
|
760
|
-
|
|
761
|
-
|
|
762
|
-
|
|
763
|
-
|
|
764
|
-
|
|
765
|
-
|
|
766
|
-
|
|
767
|
-
|
|
768
|
-
|
|
769
|
-
|
|
770
|
-
|
|
771
|
-
|
|
772
|
-
|
|
773
|
-
|
|
774
|
-
|
|
775
|
-
|
|
776
|
-
|
|
777
|
-
|
|
778
|
-
|
|
779
|
-
|
|
780
|
-
|
|
781
|
-
|
|
782
|
-
|
|
783
|
-
**
|
|
784
|
-
-
|
|
785
|
-
-
|
|
786
|
-
-
|
|
787
|
-
|
|
788
|
-
|
|
789
|
-
|
|
790
|
-
|
|
791
|
-
|
|
792
|
-
|
|
793
|
-
|
|
794
|
-
|
|
795
|
-
|
|
796
|
-
|
|
797
|
-
|
|
798
|
-
-
|
|
799
|
-
|
|
800
|
-
|
|
801
|
-
|
|
802
|
-
|
|
803
|
-
|
|
804
|
-
|
|
805
|
-
|
|
806
|
-
|
|
807
|
-
|
|
808
|
-
|
|
809
|
-
|
|
810
|
-
|
|
811
|
-
|
|
812
|
-
|
|
813
|
-
|
|
814
|
-
|
|
815
|
-
|
|
816
|
-
|
|
817
|
-
|
|
818
|
-
|
|
819
|
-
|
|
820
|
-
|
|
821
|
-
|
|
822
|
-
|
|
823
|
-
|
|
824
|
-
|
|
825
|
-
|
|
826
|
-
|
|
827
|
-
|
|
828
|
-
|
|
829
|
-
|
|
830
|
-
|
|
831
|
-
|
|
832
|
-
|
|
833
|
-
|
|
834
|
-
|
|
835
|
-
|
|
836
|
-
|
|
837
|
-
|
|
838
|
-
|
|
839
|
-
|
|
840
|
-
|
|
841
|
-
|
|
842
|
-
|
|
843
|
-
|
|
844
|
-
|
|
845
|
-
|
|
846
|
-
|
|
847
|
-
|
|
848
|
-
|
|
849
|
-
|
|
850
|
-
|
|
851
|
-
|
|
852
|
-
|
|
853
|
-
|
|
854
|
-
|
|
855
|
-
|
|
856
|
-
|
|
857
|
-
|
|
858
|
-
|
|
859
|
-
|
|
860
|
-
|
|
861
|
-
|
|
862
|
-
|
|
863
|
-
|
|
864
|
-
|
|
865
|
-
|
|
866
|
-
|
|
867
|
-
|
|
868
|
-
|
|
869
|
-
|
|
870
|
-
|
|
871
|
-
|
|
872
|
-
|
|
873
|
-
|
|
874
|
-
|
|
875
|
-
|
|
876
|
-
|
|
877
|
-
|
|
878
|
-
|
|
879
|
-
|
|
880
|
-
|
|
1
|
+
# ClaudeOS-Core
|
|
2
|
+
|
|
3
|
+
**Das einzige Tool, das zuerst Ihren Quellcode liest, Ihren Stack und Ihre Muster mit deterministischer Analyse bestätigt und dann Claude-Code-Regeln generiert, die exakt auf Ihr Projekt zugeschnitten sind.**
|
|
4
|
+
|
|
5
|
+
```bash
|
|
6
|
+
npx claudeos-core init
|
|
7
|
+
```
|
|
8
|
+
|
|
9
|
+
ClaudeOS-Core liest Ihre Codebasis, extrahiert jedes Muster, das es findet, und generiert einen vollständigen Satz von Standards, Rules, Skills und Guides, die auf _Ihr_ Projekt zugeschnitten sind. Wenn Sie danach Claude Code sagen „Erstelle ein CRUD für Bestellungen", erzeugt er Code, der exakt Ihren bestehenden Mustern entspricht.
|
|
10
|
+
|
|
11
|
+
[🇺🇸 English](./README.md) · [🇰🇷 한국어](./README.ko.md) · [🇨🇳 中文](./README.zh-CN.md) · [🇯🇵 日本語](./README.ja.md) · [🇪🇸 Español](./README.es.md) · [🇻🇳 Tiếng Việt](./README.vi.md) · [🇮🇳 हिन्दी](./README.hi.md) · [🇷🇺 Русский](./README.ru.md) · [🇫🇷 Français](./README.fr.md)
|
|
12
|
+
|
|
13
|
+
---
|
|
14
|
+
|
|
15
|
+
## Neuerungen in v2.1.0
|
|
16
|
+
|
|
17
|
+
v2.1.0 architektiert Pass 3 neu, um `Prompt is too long`-Fehler bei mittleren bis großen Projekten zu eliminieren. Zuvor musste ein einzelner Pass-3-Aufruf den gesamten Dokumentationsbaum in einem Rutsch ausgeben — Dutzende von Dateien über `CLAUDE.md`, Rules, Standards, Skills und Guides hinweg — und der akkumulierte Output überschritt ab ca. 5 Domains zuverlässig das Context-Fenster. Die Lösung ist strukturell, kein Prompt-Tuning:
|
|
18
|
+
|
|
19
|
+
- **Pass 3 Split-Mode** (immer aktiv) — Pass 3 wird in sequenzielle `claude -p`-Aufrufe aufgeteilt (`3a` → `3b-core` → `3b-N` → `3c-core` → `3c-N` → `3d-aux`). Jede Stage startet mit einem **frischen Context-Fenster**, sodass Output-Akkumulations-Overflows unabhängig von der Projektgröße strukturell unmöglich sind.
|
|
20
|
+
- **Fact Sheet zwischen Stages** — Stage `3a` liest die Pass-2-Analyse einmal und destilliert sie in ein 5–10 KB großes `pass3a-facts.md`. Alle späteren Stages referenzieren diese Fact Sheet anstatt die 100–500 KB große `pass2-merged.json` neu zu lesen, wodurch die Konsistenz über Dateien und frische Contexts hinweg erhalten bleibt.
|
|
21
|
+
- **Batch-Unterteilung** (automatisch ab 16 Domains) — Stages 3b/3c werden zusätzlich in Batches von je 15 Domains aufgeteilt, sodass jede Stage unter ~50 Ausgabedateien bleibt. Ein 18-Domain-Admin-Frontend (React 19 + Vite 6) läuft in **102 Minuten mit 101 generierten Dateien über 8 Stages durch, null Overflow-Fehler** (echter Produktionslauf, 2026-04-20).
|
|
22
|
+
- **Master-Plan-Generierung entfernt** — `claudeos-core/plan/*-master.md`-Dateien werden nicht mehr generiert. Master Plans waren ein internes Backup, das Claude Code zur Laufzeit nicht konsumierte, und ihre Aggregation in Pass 3d war ein primärer Overflow-Auslöser. Verwenden Sie stattdessen `git` für Backup/Restore.
|
|
23
|
+
- **Pass 4 Gap-Fill: `skills/00.shared/MANIFEST.md`** — Wenn Pass 3c das Skill-Register auslässt (skill-spärliche Projekte), erstellt Pass 4 jetzt automatisch einen Stub, damit `.claude/rules/50.sync/03.skills-sync.md` niemals auf eine nicht existierende Datei zeigt.
|
|
24
|
+
|
|
25
|
+
Ein paar kleinere Fixes: `memory --help` zeigt nun die Memory-Subcommand-Hilfe an (zuvor wurde die Top-Level-Hilfe gezeigt); `memory score` hinterlässt keine doppelten `importance`-Zeilen mehr; die `memory compact`-Summary-Marker sind jetzt korrekte Markdown-Listenelemente. Volle Details: [CHANGELOG.md](./CHANGELOG.md).
|
|
26
|
+
|
|
27
|
+
---
|
|
28
|
+
|
|
29
|
+
## Warum ClaudeOS-Core?
|
|
30
|
+
|
|
31
|
+
Jedes andere Claude-Code-Tool funktioniert so:
|
|
32
|
+
|
|
33
|
+
> **Mensch beschreibt das Projekt → LLM generiert Dokumentation**
|
|
34
|
+
|
|
35
|
+
ClaudeOS-Core funktioniert so:
|
|
36
|
+
|
|
37
|
+
> **Code analysiert Ihren Quellcode → Code erstellt einen maßgeschneiderten Prompt → LLM generiert Dokumentation → Code verifiziert den Output**
|
|
38
|
+
|
|
39
|
+
Das ist kein kleiner Unterschied. Hier ist, warum das wichtig ist:
|
|
40
|
+
|
|
41
|
+
### Das Kernproblem: LLMs raten. Code rät nicht.
|
|
42
|
+
|
|
43
|
+
Wenn Sie Claude bitten, „dieses Projekt zu analysieren", **rät** er Ihren Stack, Ihr ORM, Ihre Domain-Struktur.
|
|
44
|
+
Er sieht möglicherweise `spring-boot` in Ihrer `build.gradle`, übersieht aber, dass Sie MyBatis verwenden (nicht JPA).
|
|
45
|
+
Er erkennt vielleicht ein `user/`-Verzeichnis, bemerkt aber nicht, dass Ihr Projekt layer-first-Paketierung (Pattern A) verwendet, nicht domain-first (Pattern B).
|
|
46
|
+
|
|
47
|
+
**ClaudeOS-Core rät nicht.** Bevor Claude Ihr Projekt überhaupt sieht, hat Node.js-Code bereits:
|
|
48
|
+
|
|
49
|
+
- `build.gradle` / `package.json` / `pyproject.toml` geparst und Ihren Stack, ORM, DB und Paketmanager **bestätigt**
|
|
50
|
+
- Ihre Verzeichnisstruktur gescannt und Ihre Domain-Liste mit Dateianzahl **bestätigt**
|
|
51
|
+
- Ihre Projektstruktur in eines der 5 Java-Muster, Kotlin CQRS/BFF oder Next.js App Router/FSD klassifiziert
|
|
52
|
+
- Domains in optimal dimensionierte Gruppen aufgeteilt, die in Claudes Context-Fenster passen
|
|
53
|
+
- Einen stack-spezifischen Prompt mit allen bestätigten Fakten zusammengestellt
|
|
54
|
+
|
|
55
|
+
Wenn Claude den Prompt erhält, bleibt nichts mehr zu raten. Der Stack ist bestätigt. Die Domains sind bestätigt. Das Strukturmuster ist bestätigt. Claudes einzige Aufgabe besteht darin, Dokumentation zu generieren, die diesen **bestätigten Fakten** entspricht.
|
|
56
|
+
|
|
57
|
+
### Das Ergebnis
|
|
58
|
+
|
|
59
|
+
Andere Tools produzieren „allgemein gute" Dokumentation.
|
|
60
|
+
ClaudeOS-Core produziert Dokumentation, die weiß, dass Ihr Projekt `ApiResponse.ok()` verwendet (nicht `ResponseEntity.success()`), dass Ihre MyBatis-XML-Mapper in `src/main/resources/mybatis/mappers/` liegen und dass Ihre Paketstruktur `com.company.module.{domain}.controller` lautet — weil es Ihren tatsächlichen Code gelesen hat.
|
|
61
|
+
|
|
62
|
+
### Vorher & Nachher
|
|
63
|
+
|
|
64
|
+
**Ohne ClaudeOS-Core** — Sie bitten Claude Code, ein Order-CRUD zu erstellen:
|
|
65
|
+
```
|
|
66
|
+
❌ Verwendet JPA-Style-Repository (Ihr Projekt verwendet MyBatis)
|
|
67
|
+
❌ Erstellt ResponseEntity.success() (Ihr Wrapper ist ApiResponse.ok())
|
|
68
|
+
❌ Platziert Dateien in order/controller/ (Ihr Projekt nutzt controller/order/)
|
|
69
|
+
❌ Generiert englische Kommentare (Ihr Team schreibt deutsche Kommentare)
|
|
70
|
+
→ Sie verbringen 20 Minuten damit, jede generierte Datei zu korrigieren
|
|
71
|
+
```
|
|
72
|
+
|
|
73
|
+
**Mit ClaudeOS-Core** — `.claude/rules/` enthält bereits Ihre bestätigten Muster:
|
|
74
|
+
```
|
|
75
|
+
✅ Generiert MyBatis-Mapper + XML (aus build.gradle erkannt)
|
|
76
|
+
✅ Verwendet ApiResponse.ok() (aus Ihrem tatsächlichen Quellcode extrahiert)
|
|
77
|
+
✅ Platziert Dateien in controller/order/ (Pattern A durch Struktur-Scan bestätigt)
|
|
78
|
+
✅ Deutsche Kommentare (--lang de angewendet)
|
|
79
|
+
→ Der generierte Code entspricht sofort Ihren Projektkonventionen
|
|
80
|
+
```
|
|
81
|
+
|
|
82
|
+
Dieser Unterschied summiert sich. 10 Aufgaben/Tag × 20 Minuten gespart = **über 3 Stunden/Tag**.
|
|
83
|
+
|
|
84
|
+
---
|
|
85
|
+
|
|
86
|
+
## Unterstützte Stacks
|
|
87
|
+
|
|
88
|
+
| Stack | Erkennung | Analysetiefe |
|
|
89
|
+
|---|---|---|
|
|
90
|
+
| **Java / Spring Boot** | `build.gradle`, `pom.xml`, 5 Paketmuster | 10 Kategorien, 59 Unterpunkte |
|
|
91
|
+
| **Kotlin / Spring Boot** | `build.gradle.kts`, kotlin plugin, `settings.gradle.kts`, CQRS/BFF Auto-Erkennung | 12 Kategorien, 95 Unterpunkte |
|
|
92
|
+
| **Node.js / Express** | `package.json` | 9 Kategorien, 57 Unterpunkte |
|
|
93
|
+
| **Node.js / NestJS** | `package.json` (`@nestjs/core`) | 10 Kategorien, 68 Unterpunkte |
|
|
94
|
+
| **Next.js / React** | `package.json`, `next.config.*`, FSD-Unterstützung | 9 Kategorien, 55 Unterpunkte |
|
|
95
|
+
| **Vue / Nuxt** | `package.json`, `nuxt.config.*`, Composition API | 9 Kategorien, 58 Unterpunkte |
|
|
96
|
+
| **Python / Django** | `requirements.txt`, `pyproject.toml` | 10 Kategorien, 55 Unterpunkte |
|
|
97
|
+
| **Python / FastAPI** | `requirements.txt`, `pyproject.toml` | 10 Kategorien, 58 Unterpunkte |
|
|
98
|
+
| **Node.js / Fastify** | `package.json` | 10 Kategorien, 62 Unterpunkte |
|
|
99
|
+
| **Vite / React SPA** | `package.json`, `vite.config.*` | 9 Kategorien, 55 Unterpunkte |
|
|
100
|
+
| **Angular** | `package.json`, `angular.json` | 12 Kategorien, 78 Unterpunkte |
|
|
101
|
+
|
|
102
|
+
Automatisch erkannt: Sprache und Version, Framework und Version (einschließlich Vite als SPA-Framework), ORM (MyBatis, JPA, Exposed, Prisma, TypeORM, SQLAlchemy usw.), Datenbank (PostgreSQL, MySQL, Oracle, MongoDB, SQLite), Paketmanager (Gradle, Maven, npm, yarn, pnpm, pip, poetry), Architektur (CQRS, BFF — aus Modulnamen), Multi-Modul-Struktur (aus settings.gradle), Monorepo (Turborepo, pnpm-workspace, Lerna, npm/yarn workspaces).
|
|
103
|
+
|
|
104
|
+
**Sie geben nichts an. Alles wird automatisch erkannt.**
|
|
105
|
+
|
|
106
|
+
### Java-Domain-Erkennung (5 Muster mit Fallback)
|
|
107
|
+
|
|
108
|
+
| Priorität | Muster | Struktur | Beispiel |
|
|
109
|
+
|---|---|---|---|
|
|
110
|
+
| A | Layer-first | `controller/{domain}/` | `controller/user/UserController.java` |
|
|
111
|
+
| B | Domain-first | `{domain}/controller/` | `user/controller/UserController.java` |
|
|
112
|
+
| D | Modul-Präfix | `{module}/{domain}/controller/` | `front/member/controller/MemberController.java` |
|
|
113
|
+
| E | DDD/Hexagonal | `{domain}/adapter/in/web/` | `user/adapter/in/web/UserController.java` |
|
|
114
|
+
| C | Flach | `controller/*.java` | `controller/UserController.java` → extrahiert `user` aus Klassenname |
|
|
115
|
+
|
|
116
|
+
Service-only-Domains (ohne Controller) werden ebenfalls über die Verzeichnisse `service/`, `dao/`, `aggregator/`, `facade/`, `usecase/`, `orchestrator/`, `mapper/`, `repository/` erkannt. Übersprungen: `common`, `config`, `util`, `core`, `front`, `admin`, `v1`, `v2` usw.
|
|
117
|
+
|
|
118
|
+
### Kotlin Multi-Modul Domain-Erkennung
|
|
119
|
+
|
|
120
|
+
Für Kotlin-Projekte mit Gradle-Multi-Modul-Struktur (z. B. CQRS-Monorepo):
|
|
121
|
+
|
|
122
|
+
| Schritt | Aktion | Beispiel |
|
|
123
|
+
|---|---|---|
|
|
124
|
+
| 1 | Scan von `settings.gradle.kts` nach `include()` | Findet 14 Module |
|
|
125
|
+
| 2 | Modultyp aus dem Namen ableiten | `reservation-command-server` → Typ: `command` |
|
|
126
|
+
| 3 | Domain aus dem Modulnamen extrahieren | `reservation-command-server` → Domain: `reservation` |
|
|
127
|
+
| 4 | Gleiche Domain über Module gruppieren | `reservation-command-server` + `common-query-server` → 1 Domain |
|
|
128
|
+
| 5 | Architektur erkennen | Besitzt `command`- + `query`-Module → CQRS |
|
|
129
|
+
|
|
130
|
+
Unterstützte Modultypen: `command`, `query`, `bff`, `integration`, `standalone`, `library`. Geteilte Bibliotheken (`shared-lib`, `integration-lib`) werden als spezielle Domains erkannt.
|
|
131
|
+
|
|
132
|
+
### Frontend-Domain-Erkennung
|
|
133
|
+
|
|
134
|
+
- **App Router**: `app/{domain}/page.tsx` (Next.js)
|
|
135
|
+
- **Pages Router**: `pages/{domain}/index.tsx`
|
|
136
|
+
- **FSD (Feature-Sliced Design)**: `features/*/`, `widgets/*/`, `entities/*/`
|
|
137
|
+
- **RSC/Client-Split**: Erkennt das `client.tsx`-Muster, verfolgt die Trennung von Server-/Client-Komponenten
|
|
138
|
+
- **Nicht-standardisierte verschachtelte Pfade**: Erkennt Pages, Components und FSD-Layer unter `src/*/`-Pfaden (z. B. `src/admin/pages/dashboard/`, `src/admin/components/form/`, `src/admin/features/billing/`)
|
|
139
|
+
- **Plattform-/Tier-Split-Erkennung (v2.0.0)**: Erkennt `src/{platform}/{subapp}/`-Layouts — `{platform}` kann ein Device-/Target-Keyword sein (`desktop`, `pc`, `web`, `mobile`, `mc`, `mo`, `sp`, `tablet`, `tab`, `pwa`, `tv`, `ctv`, `ott`, `watch`, `wear`) oder ein Zugriffsebenen-Keyword (`admin`, `cms`, `backoffice`, `back-office`, `portal`). Liefert pro `(platform, subapp)`-Paar eine Domain mit dem Namen `{platform}-{subapp}` und pro Domain Zählungen für Routes/Components/Layouts/Hooks. Läuft parallel für Angular, Next.js, React und Vue (Multi-Extension-Glob `{tsx,jsx,ts,js,vue}`). Erfordert ≥2 Quelldateien pro Subapp, um rauschende 1-Datei-Domains zu vermeiden.
|
|
140
|
+
- **Monorepo-Plattform-Split (v2.0.0)**: Der Plattform-Scan matched zusätzlich `{apps,packages}/*/src/{platform}/{subapp}/` (Turborepo/pnpm-Workspace mit `src/`) und `{apps,packages}/{platform}/{subapp}/` (Workspaces ohne `src/`-Wrapper).
|
|
141
|
+
- **Fallback E — routes-Datei (v2.0.0)**: Wenn primäre Scanner + Fallbacks A–D alle 0 zurückgeben, wird `**/routes/*.{tsx,jsx,ts,js,vue}` geglobbt und nach dem Parent-of-`routes`-Verzeichnisnamen gruppiert. Erfasst React-Router-File-Routing-Projekte (CRA/Vite + `react-router`), die weder Next.js-`page.tsx` noch FSD-Layouts entsprechen. Generische Parent-Namen (`src`, `app`, `pages`) werden herausgefiltert.
|
|
142
|
+
- **Config-Fallback**: Erkennt Next.js/Vite/Nuxt aus Config-Dateien, wenn nicht in `package.json` (Monorepo-Unterstützung)
|
|
143
|
+
- **Deep-Directory-Fallback**: Für React-/CRA-/Vite-/Vue-/RN-Projekte scannt `**/components/*/`, `**/views/*/`, `**/screens/*/`, `**/containers/*/`, `**/pages/*/`, `**/routes/*/`, `**/modules/*/`, `**/domains/*/` in beliebiger Tiefe
|
|
144
|
+
- **Geteilte Ignore-Listen (v2.0.0)**: Alle Scanner teilen sich `BUILD_IGNORE_DIRS` (`node_modules`, `build`, `dist`, `out`, `.next`, `.nuxt`, `.svelte-kit`, `.angular`, `.turbo`, `.cache`, `.parcel-cache`, `coverage`, `storybook-static`, `.vercel`, `.netlify`) und `TEST_FILE_IGNORE` (spec/test/stories/e2e/cy + `__snapshots__`/`__tests__`), damit Build-Outputs und Test-Fixtures die Datei-Zähler pro Domain nicht aufblähen.
|
|
145
|
+
|
|
146
|
+
### Scanner-Overrides (v2.0.0)
|
|
147
|
+
|
|
148
|
+
Legen Sie optional eine `.claudeos-scan.json` im Projekt-Root ab, um Scanner-Defaults zu erweitern, ohne das Toolkit zu editieren. Alle Felder sind **additiv** — User-Einträge erweitern die Defaults, ersetzen sie niemals:
|
|
149
|
+
|
|
150
|
+
```json
|
|
151
|
+
{
|
|
152
|
+
"frontendScan": {
|
|
153
|
+
"platformKeywords": ["kiosk"],
|
|
154
|
+
"skipSubappNames": ["legacy"],
|
|
155
|
+
"minSubappFiles": 3
|
|
156
|
+
}
|
|
157
|
+
}
|
|
158
|
+
```
|
|
159
|
+
|
|
160
|
+
| Feld | Default | Zweck |
|
|
161
|
+
|---|---|---|
|
|
162
|
+
| `platformKeywords` | eingebaute Liste oben | Zusätzliche `{platform}`-Keywords für den Platform-Scan (z. B. `kiosk`, `vr`, `embedded`) |
|
|
163
|
+
| `skipSubappNames` | nur strukturelle Dirs | Zusätzliche Subapp-Namen, die von der Platform-Scan-Domain-Emission ausgeschlossen werden |
|
|
164
|
+
| `minSubappFiles` | `2` | Überschreibt die Mindestdateianzahl, bevor eine Subapp zur Domain wird |
|
|
165
|
+
|
|
166
|
+
Fehlende Datei oder fehlerhaftes JSON → fällt stillschweigend auf Defaults zurück (kein Crash). Typischer Einsatz: Opt-in für eine kurze Abkürzung (`adm`, `bo`), die die eingebaute Liste als zu mehrdeutig ausschließt, oder Erhöhung von `minSubappFiles` für rauschende Monorepos.
|
|
167
|
+
|
|
168
|
+
---
|
|
169
|
+
|
|
170
|
+
## Schnellstart
|
|
171
|
+
|
|
172
|
+
### Voraussetzungen
|
|
173
|
+
|
|
174
|
+
- **Node.js** v18+
|
|
175
|
+
- **Claude Code CLI** (installiert & authentifiziert)
|
|
176
|
+
|
|
177
|
+
### Installation
|
|
178
|
+
|
|
179
|
+
```bash
|
|
180
|
+
cd /your/project/root
|
|
181
|
+
|
|
182
|
+
# Option A: npx (empfohlen — keine Installation nötig)
|
|
183
|
+
npx claudeos-core init
|
|
184
|
+
|
|
185
|
+
# Option B: globale Installation
|
|
186
|
+
npm install -g claudeos-core
|
|
187
|
+
claudeos-core init
|
|
188
|
+
|
|
189
|
+
# Option C: Projekt-devDependency
|
|
190
|
+
npm install --save-dev claudeos-core
|
|
191
|
+
npx claudeos-core init
|
|
192
|
+
|
|
193
|
+
# Option D: git clone (für Entwicklung/Beiträge)
|
|
194
|
+
git clone https://github.com/claudeos-core/claudeos-core.git claudeos-core-tools
|
|
195
|
+
|
|
196
|
+
# Cross-Platform (PowerShell, CMD, Bash, Zsh — beliebiges Terminal)
|
|
197
|
+
node claudeos-core-tools/bin/cli.js init
|
|
198
|
+
|
|
199
|
+
# Linux/macOS (nur Bash)
|
|
200
|
+
bash claudeos-core-tools/bootstrap.sh
|
|
201
|
+
```
|
|
202
|
+
|
|
203
|
+
### Ausgabesprache (10 Sprachen)
|
|
204
|
+
|
|
205
|
+
Wenn Sie `init` ohne `--lang` ausführen, erscheint ein interaktiver Selector — verwenden Sie Pfeiltasten oder Zahlentasten zur Auswahl:
|
|
206
|
+
|
|
207
|
+
```
|
|
208
|
+
╔══════════════════════════════════════════════════╗
|
|
209
|
+
║ Sprache der generierten Dokumente wählen ║
|
|
210
|
+
╚══════════════════════════════════════════════════╝
|
|
211
|
+
|
|
212
|
+
Generierte Dateien (CLAUDE.md, Standards, Rules,
|
|
213
|
+
Skills, Guides) werden auf Deutsch geschrieben.
|
|
214
|
+
|
|
215
|
+
1. en — English
|
|
216
|
+
2. ko — 한국어 (Korean)
|
|
217
|
+
3. zh-CN — 简体中文 (Chinese Simplified)
|
|
218
|
+
4. ja — 日本語 (Japanese)
|
|
219
|
+
5. es — Español (Spanish)
|
|
220
|
+
6. vi — Tiếng Việt (Vietnamese)
|
|
221
|
+
7. hi — हिन्दी (Hindi)
|
|
222
|
+
8. ru — Русский (Russian)
|
|
223
|
+
9. fr — Français (French)
|
|
224
|
+
❯ 10. de — Deutsch (German)
|
|
225
|
+
|
|
226
|
+
↑↓ Bewegen 1-0 Springen Enter Auswählen ESC Abbrechen
|
|
227
|
+
```
|
|
228
|
+
|
|
229
|
+
Die Beschreibung ändert sich je nach Navigation zur ausgewählten Sprache. Um den Selector zu überspringen, übergeben Sie `--lang` direkt:
|
|
230
|
+
|
|
231
|
+
```bash
|
|
232
|
+
npx claudeos-core init --lang ko # Koreanisch
|
|
233
|
+
npx claudeos-core init --lang ja # Japanisch
|
|
234
|
+
npx claudeos-core init --lang en # Englisch (Default)
|
|
235
|
+
```
|
|
236
|
+
|
|
237
|
+
> **Hinweis:** Dies setzt die Sprache nur für die generierten Dokumentationsdateien. Die Code-Analyse (Pass 1–2) läuft immer auf Englisch; der generierte Output (Pass 3) wird in Ihrer gewählten Sprache geschrieben. Code-Beispiele in den generierten Dateien behalten ihre ursprüngliche Programmiersprachen-Syntax.
|
|
238
|
+
|
|
239
|
+
Das war's. Nach 10 Minuten (kleines Projekt) bis 2 Stunden (60+-Domain-Monorepo) ist die gesamte Dokumentation generiert und einsatzbereit. Die CLI zeigt einen Fortschrittsbalken mit Prozentwert, verstrichener Zeit und ETA für jeden Pass. Siehe [Auto-Scaling nach Projektgröße](#auto-scaling-nach-projektgröße) für detaillierte Zeiten je nach Projektgröße.
|
|
240
|
+
|
|
241
|
+
### Manuelle Schritt-für-Schritt-Installation
|
|
242
|
+
|
|
243
|
+
Wenn Sie volle Kontrolle über jede Phase wünschen — oder wenn die automatisierte Pipeline an einem Schritt scheitert — können Sie jede Phase manuell ausführen. Dies ist auch nützlich, um zu verstehen, wie ClaudeOS-Core intern funktioniert.
|
|
244
|
+
|
|
245
|
+
#### Schritt 1: Klonen und Abhängigkeiten installieren
|
|
246
|
+
|
|
247
|
+
```bash
|
|
248
|
+
cd /your/project/root
|
|
249
|
+
|
|
250
|
+
git clone https://github.com/claudeos-core/claudeos-core.git claudeos-core-tools
|
|
251
|
+
cd claudeos-core-tools && npm install && cd ..
|
|
252
|
+
```
|
|
253
|
+
|
|
254
|
+
#### Schritt 2: Verzeichnisstruktur erstellen
|
|
255
|
+
|
|
256
|
+
```bash
|
|
257
|
+
# Rules (v2.0.0: 60.memory hinzugefügt)
|
|
258
|
+
mkdir -p .claude/rules/{00.core,10.backend,20.frontend,30.security-db,40.infra,50.sync,60.memory}
|
|
259
|
+
|
|
260
|
+
# Standards
|
|
261
|
+
mkdir -p claudeos-core/standard/{00.core,10.backend-api,20.frontend-ui,30.security-db,40.infra,50.verification,90.optional}
|
|
262
|
+
|
|
263
|
+
# Skills
|
|
264
|
+
mkdir -p claudeos-core/skills/{00.shared,10.backend-crud/scaffold-crud-feature,20.frontend-page/scaffold-page-feature,50.testing,90.experimental}
|
|
265
|
+
|
|
266
|
+
# Guide, Database, MCP, Generated, Memory (v2.0.0: memory hinzugefügt; v2.1.0: plan entfernt)
|
|
267
|
+
mkdir -p claudeos-core/guide/{01.onboarding,02.usage,03.troubleshooting,04.architecture}
|
|
268
|
+
mkdir -p claudeos-core/{database,mcp-guide,generated,memory}
|
|
269
|
+
```
|
|
270
|
+
|
|
271
|
+
> **Hinweis zu v2.1.0:** Das Verzeichnis `claudeos-core/plan/` wird nicht mehr angelegt. Die Master-Plan-Generierung wurde entfernt, weil Master Plans ein internes Backup waren, das Claude Code zur Laufzeit nie liest, und ihre Aggregation `Prompt is too long`-Fehler auslöste. Verwenden Sie `git` für Backup/Restore.
|
|
272
|
+
|
|
273
|
+
#### Schritt 3: plan-installer ausführen (Projektanalyse)
|
|
274
|
+
|
|
275
|
+
Dies scannt Ihr Projekt, erkennt den Stack, findet Domains, teilt sie in Gruppen auf und generiert Prompts.
|
|
276
|
+
|
|
277
|
+
```bash
|
|
278
|
+
node claudeos-core-tools/plan-installer/index.js
|
|
279
|
+
```
|
|
280
|
+
|
|
281
|
+
**Output (in `claudeos-core/generated/`):**
|
|
282
|
+
- `project-analysis.json` — erkannter Stack, Domains, Frontend-Infos
|
|
283
|
+
- `domain-groups.json` — Domain-Gruppen für Pass 1
|
|
284
|
+
- `pass1-backend-prompt.md` / `pass1-frontend-prompt.md` — Analyse-Prompts
|
|
285
|
+
- `pass2-prompt.md` — Merge-Prompt
|
|
286
|
+
- `pass3-prompt.md` — Pass-3-Prompt-Template mit vorangestelltem Phase-1-Block „Read Once, Extract Facts" (Rules A–E). Die automatisierte Pipeline teilt Pass 3 zur Laufzeit in mehrere Stages auf; dieses Template wird jeder Stage zugeführt.
|
|
287
|
+
- `pass3-context.json` — schlanke Projekt-Zusammenfassung (< 5 KB, nach Pass 2 erstellt), die Pass-3-Prompts gegenüber der vollen `pass2-merged.json` bevorzugen (v2.1.0)
|
|
288
|
+
- `pass4-prompt.md` — L4-Memory-Scaffolding-Prompt (v2.0.0; verwendet dasselbe `staging-override.md` für `60.memory/`-Rule-Schreibvorgänge)
|
|
289
|
+
|
|
290
|
+
Sie können diese Dateien inspizieren, um die Erkennungsgenauigkeit zu überprüfen, bevor Sie fortfahren.
|
|
291
|
+
|
|
292
|
+
#### Schritt 4: Pass 1 — Tiefe Code-Analyse (pro Domain-Gruppe)
|
|
293
|
+
|
|
294
|
+
Führen Sie Pass 1 für jede Domain-Gruppe aus. Prüfen Sie `domain-groups.json` für die Anzahl der Gruppen.
|
|
295
|
+
|
|
296
|
+
```bash
|
|
297
|
+
# Anzahl der Gruppen prüfen
|
|
298
|
+
cat claudeos-core/generated/domain-groups.json | node -e "
|
|
299
|
+
const g = JSON.parse(require('fs').readFileSync('/dev/stdin','utf-8'));
|
|
300
|
+
g.groups.forEach((g,i) => console.log('Group '+(i+1)+': ['+g.domains.join(', ')+'] ('+g.type+', ~'+g.estimatedFiles+' files)'));
|
|
301
|
+
"
|
|
302
|
+
|
|
303
|
+
# Pass 1 für jede Gruppe ausführen (Domains und Gruppennummer ersetzen)
|
|
304
|
+
# Hinweis: v1.6.1+ verwendet Node.js String.replace() statt perl — perl
|
|
305
|
+
# wird nicht mehr benötigt, und die Replacement-Function-Semantik verhindert
|
|
306
|
+
# Regex-Injection durch $/&/$1-Zeichen, die in Domain-Namen auftauchen können.
|
|
307
|
+
#
|
|
308
|
+
# Für Gruppe 1:
|
|
309
|
+
DOMAIN_LIST="user, order, product" PASS_NUM=1 node -e "
|
|
310
|
+
const fs = require('fs');
|
|
311
|
+
const tpl = fs.readFileSync('claudeos-core/generated/pass1-backend-prompt.md','utf-8');
|
|
312
|
+
const out = tpl
|
|
313
|
+
.replace(/\{\{DOMAIN_GROUP\}\}/g, () => process.env.DOMAIN_LIST)
|
|
314
|
+
.replace(/\{\{PASS_NUM\}\}/g, () => process.env.PASS_NUM);
|
|
315
|
+
process.stdout.write(out);
|
|
316
|
+
" | claude -p --dangerously-skip-permissions
|
|
317
|
+
|
|
318
|
+
# Für Gruppe 2 (falls vorhanden):
|
|
319
|
+
DOMAIN_LIST="payment, system, delivery" PASS_NUM=2 node -e "
|
|
320
|
+
const fs = require('fs');
|
|
321
|
+
const tpl = fs.readFileSync('claudeos-core/generated/pass1-backend-prompt.md','utf-8');
|
|
322
|
+
const out = tpl
|
|
323
|
+
.replace(/\{\{DOMAIN_GROUP\}\}/g, () => process.env.DOMAIN_LIST)
|
|
324
|
+
.replace(/\{\{PASS_NUM\}\}/g, () => process.env.PASS_NUM);
|
|
325
|
+
process.stdout.write(out);
|
|
326
|
+
" | claude -p --dangerously-skip-permissions
|
|
327
|
+
|
|
328
|
+
# Für Frontend-Gruppen pass1-backend-prompt.md → pass1-frontend-prompt.md tauschen
|
|
329
|
+
```
|
|
330
|
+
|
|
331
|
+
**Verifikation:** `ls claudeos-core/generated/pass1-*.json` sollte eine JSON-Datei pro Gruppe zeigen.
|
|
332
|
+
|
|
333
|
+
#### Schritt 5: Pass 2 — Analyseergebnisse zusammenführen
|
|
334
|
+
|
|
335
|
+
```bash
|
|
336
|
+
cat claudeos-core/generated/pass2-prompt.md \
|
|
337
|
+
| claude -p --dangerously-skip-permissions
|
|
338
|
+
```
|
|
339
|
+
|
|
340
|
+
**Verifikation:** `claudeos-core/generated/pass2-merged.json` sollte existieren und 9+ Top-Level-Keys enthalten.
|
|
341
|
+
|
|
342
|
+
#### Schritt 6: Pass 3 — Gesamte Dokumentation generieren (aufgeteilt in mehrere Stages)
|
|
343
|
+
|
|
344
|
+
**Hinweis zu v2.1.0:** Pass 3 wird von der automatisierten Pipeline **immer im Split-Mode** ausgeführt. Jede Stage ist ein separater `claude -p`-Aufruf mit frischem Context-Fenster, sodass Output-Akkumulations-Overflows unabhängig von der Projektgröße strukturell unmöglich sind. Das `pass3-prompt.md`-Template wird pro Stage mit einer `STAGE:`-Direktive assembliert, die Claude anweist, welche Teilmenge der Dateien zu emittieren ist. Für den manuellen Modus ist der einfachste Weg immer noch, das volle Template zuzuführen und Claude alles in einem Aufruf generieren zu lassen — aber das ist nur für kleine Projekte (≤5 Domains) zuverlässig. Für größere Projekte verwenden Sie `npx claudeos-core init`, damit der Split-Runner die Stage-Orchestrierung übernimmt.
|
|
345
|
+
|
|
346
|
+
**Single-Call-Modus (nur kleine Projekte, ≤5 Domains):**
|
|
347
|
+
|
|
348
|
+
```bash
|
|
349
|
+
cat claudeos-core/generated/pass3-prompt.md \
|
|
350
|
+
| claude -p --dangerously-skip-permissions
|
|
351
|
+
```
|
|
352
|
+
|
|
353
|
+
**Stage-für-Stage-Modus (empfohlen für alle Projektgrößen):**
|
|
354
|
+
|
|
355
|
+
Die automatisierte Pipeline führt diese Stages aus. Die Stage-Liste lautet:
|
|
356
|
+
|
|
357
|
+
| Stage | Schreibt | Anmerkungen |
|
|
358
|
+
|---|---|---|
|
|
359
|
+
| `3a` | `pass3a-facts.md` (5–10 KB destillierte Fact Sheet) | Liest `pass2-merged.json` einmal; spätere Stages referenzieren diese Datei |
|
|
360
|
+
| `3b-core` | `CLAUDE.md`, gemeinsame `standard/`, gemeinsame `.claude/rules/` | Projektübergreifende Dateien; kein domain-spezifischer Output |
|
|
361
|
+
| `3b-1..N` | Domain-spezifische `standard/60.domains/*.md` + Domain-Rules | Batch von ≤15 Domains pro Stage (automatisch geteilt ab 16 Domains) |
|
|
362
|
+
| `3c-core` | `guide/` (9 Dateien), `skills/00.shared/MANIFEST.md`, `skills/*/`-Orchestratoren | Geteilte Skills und alle nutzerorientierten Guides |
|
|
363
|
+
| `3c-1..N` | Domain-Sub-Skills unter `skills/20.frontend-page/scaffold-page-feature/` | Batch von ≤15 Domains pro Stage |
|
|
364
|
+
| `3d-aux` | `database/`, `mcp-guide/` | Fixe Größe, unabhängig von der Domain-Anzahl |
|
|
365
|
+
|
|
366
|
+
Für ein 1–15-Domain-Projekt expandiert das zu 4 Stages (`3a`, `3b-core`, `3c-core`, `3d-aux` — keine Batch-Unterteilung). Für 16–30 Domains sind es 8 Stages (`3b` und `3c` jeweils in 2 Batches unterteilt). Siehe [Auto-Scaling nach Projektgröße](#auto-scaling-nach-projektgröße) für die vollständige Tabelle.
|
|
367
|
+
|
|
368
|
+
**Verifikation:** `CLAUDE.md` sollte im Projekt-Root existieren, und der Marker `claudeos-core/generated/pass3-complete.json` sollte geschrieben sein. Im Split-Mode enthält der Marker `mode: "split"` und ein `groupsCompleted`-Array, das jede abgeschlossene Stage auflistet — die Partial-Marker-Logik verwendet das, um nach einem Crash von der richtigen Stage aus fortzusetzen, anstatt von `3a` neu zu starten (was die Token-Kosten verdoppeln würde).
|
|
369
|
+
|
|
370
|
+
> **Staging-Hinweis:** Pass 3 schreibt Rule-Dateien zuerst in `claudeos-core/generated/.staged-rules/`, weil die Sensitive-Path-Policy von Claude Code direkte Schreibzugriffe auf `.claude/` blockiert. Die automatisierte Pipeline übernimmt das Verschieben nach jeder Stage automatisch. Wenn Sie eine Stage manuell ausführen, müssen Sie den Staging-Baum selbst verschieben: `mv claudeos-core/generated/.staged-rules/* .claude/rules/` (Unterpfade erhalten).
|
|
371
|
+
|
|
372
|
+
#### Schritt 7: Pass 4 — Memory-Scaffolding
|
|
373
|
+
|
|
374
|
+
```bash
|
|
375
|
+
cat claudeos-core/generated/pass4-prompt.md \
|
|
376
|
+
| claude -p --dangerously-skip-permissions
|
|
377
|
+
```
|
|
378
|
+
|
|
379
|
+
**Verifikation:** `claudeos-core/memory/` sollte 4 Dateien enthalten (`decision-log.md`, `failure-patterns.md`, `compaction.md`, `auto-rule-update.md`), `.claude/rules/60.memory/` sollte 4 Rule-Dateien enthalten, und `CLAUDE.md` sollte einen angehängten Abschnitt `## Memory (L4)` haben. Marker: `claudeos-core/generated/pass4-memory.json`.
|
|
380
|
+
|
|
381
|
+
> **v2.1.0 Gap-Fill:** Pass 4 stellt zudem sicher, dass `claudeos-core/skills/00.shared/MANIFEST.md` existiert. Wenn Pass 3c die Datei ausgelassen hat (möglich bei skill-spärlichen Projekten, weil die Stack-`pass3.md`-Templates `MANIFEST.md` unter den Generierungszielen listen, aber nicht als REQUIRED markieren), erzeugt das Gap-Fill einen minimalen Stub, damit `.claude/rules/50.sync/03.skills-sync.md` stets ein gültiges Referenzziel hat. Idempotent: wird übersprungen, wenn die Datei bereits echten Inhalt hat (>20 Zeichen).
|
|
382
|
+
|
|
383
|
+
> **Hinweis:** Wenn `claude -p` fehlschlägt oder `pass4-prompt.md` fehlt, fällt die automatisierte Pipeline auf ein statisches Scaffold über `lib/memory-scaffold.js` zurück (mit Claude-getriebener Übersetzung, wenn `--lang` nicht-englisch ist). Der statische Fallback läuft nur innerhalb von `npx claudeos-core init` — der manuelle Modus erfordert, dass Pass 4 erfolgreich ist.
|
|
384
|
+
|
|
385
|
+
#### Schritt 8: Verifikations-Tools ausführen
|
|
386
|
+
|
|
387
|
+
```bash
|
|
388
|
+
# Metadaten generieren (vor anderen Checks erforderlich)
|
|
389
|
+
node claudeos-core-tools/manifest-generator/index.js
|
|
390
|
+
|
|
391
|
+
# Alle Checks ausführen
|
|
392
|
+
node claudeos-core-tools/health-checker/index.js
|
|
393
|
+
|
|
394
|
+
# Oder einzelne Checks ausführen:
|
|
395
|
+
node claudeos-core-tools/plan-validator/index.js --check # Plan ↔ Disk-Konsistenz
|
|
396
|
+
node claudeos-core-tools/sync-checker/index.js # Nicht registrierte/verwaiste Dateien
|
|
397
|
+
node claudeos-core-tools/content-validator/index.js # Dateiqualitäts-Checks (inkl. memory/-Sektion [9/9])
|
|
398
|
+
node claudeos-core-tools/pass-json-validator/index.js # Pass-1–4-JSON + Completion-Marker-Checks
|
|
399
|
+
```
|
|
400
|
+
|
|
401
|
+
#### Schritt 9: Ergebnisse überprüfen
|
|
402
|
+
|
|
403
|
+
```bash
|
|
404
|
+
# Generierte Dateien zählen
|
|
405
|
+
find .claude claudeos-core -type f | grep -v node_modules | grep -v '/generated/' | wc -l
|
|
406
|
+
|
|
407
|
+
# CLAUDE.md prüfen
|
|
408
|
+
head -30 CLAUDE.md
|
|
409
|
+
|
|
410
|
+
# Eine Standard-Datei prüfen
|
|
411
|
+
cat claudeos-core/standard/00.core/01.project-overview.md | head -20
|
|
412
|
+
|
|
413
|
+
# Rules prüfen
|
|
414
|
+
ls .claude/rules/*/
|
|
415
|
+
```
|
|
416
|
+
|
|
417
|
+
> **Tipp:** Wenn ein Schritt fehlschlägt, können Sie das Problem beheben und nur diesen Schritt erneut ausführen. Pass-1/2-Ergebnisse sind gecacht — wenn `pass1-N.json` oder `pass2-merged.json` bereits existiert, überspringt die automatisierte Pipeline diese. Verwenden Sie `npx claudeos-core init --force`, um vorherige Ergebnisse zu löschen und neu zu beginnen.
|
|
418
|
+
|
|
419
|
+
### Nutzung beginnen
|
|
420
|
+
|
|
421
|
+
```
|
|
422
|
+
# In Claude Code — einfach natürlich fragen:
|
|
423
|
+
"Erstelle ein CRUD für die order-Domain"
|
|
424
|
+
"Füge eine User-Authentifizierungs-API hinzu"
|
|
425
|
+
"Refactore diesen Code, um den Projektmustern zu entsprechen"
|
|
426
|
+
|
|
427
|
+
# Claude Code referenziert automatisch Ihre generierten Standards, Rules und Skills.
|
|
428
|
+
```
|
|
429
|
+
|
|
430
|
+
---
|
|
431
|
+
|
|
432
|
+
## Wie es funktioniert — 4-Pass-Pipeline
|
|
433
|
+
|
|
434
|
+
```
|
|
435
|
+
npx claudeos-core init
|
|
436
|
+
│
|
|
437
|
+
├── [1] npm install ← Abhängigkeiten (~10s)
|
|
438
|
+
├── [2] Verzeichnisstruktur ← Ordner erstellen (~1s)
|
|
439
|
+
├── [3] plan-installer (Node.js) ← Projekt-Scan (~5s)
|
|
440
|
+
│ ├── Auto-Erkennung des Stacks (multi-stack-fähig)
|
|
441
|
+
│ ├── Domain-Liste extrahieren (getaggt: backend/frontend)
|
|
442
|
+
│ ├── In Domain-Gruppen aufteilen (pro Typ)
|
|
443
|
+
│ ├── pass3-context.json erstellen (schlanke Zusammenfassung, v2.1.0)
|
|
444
|
+
│ └── Stack-spezifische Prompts wählen (pro Typ)
|
|
445
|
+
│
|
|
446
|
+
├── [4] Pass 1 × N (claude -p) ← Tiefe Code-Analyse (~2-8min)
|
|
447
|
+
│ ├── ⚙️ Backend-Gruppen → backend-spezifischer Prompt
|
|
448
|
+
│ └── 🎨 Frontend-Gruppen → frontend-spezifischer Prompt
|
|
449
|
+
│
|
|
450
|
+
├── [5] Pass 2 × 1 (claude -p) ← Analyse-Merge (~1min)
|
|
451
|
+
│ └── Konsolidiert ALLE Pass-1-Ergebnisse zu pass2-merged.json
|
|
452
|
+
│
|
|
453
|
+
├── [6] Pass 3 (Split-Mode, v2.1.0) ← Alles generieren
|
|
454
|
+
│ │
|
|
455
|
+
│ ├── 3a × 1 (claude -p) ← Fakten-Extraktion (~5-10min)
|
|
456
|
+
│ │ └── pass2-merged.json einmal lesen → pass3a-facts.md
|
|
457
|
+
│ │
|
|
458
|
+
│ ├── 3b-core × 1 (claude -p) ← CLAUDE.md + gemeinsame standard/rules
|
|
459
|
+
│ ├── 3b-1..N × N (claude -p) ← Domain-Standards/-Rules (≤15 Domains/Batch)
|
|
460
|
+
│ │
|
|
461
|
+
│ ├── 3c-core × 1 (claude -p) ← Guides + geteilte Skills + MANIFEST.md
|
|
462
|
+
│ ├── 3c-1..N × N (claude -p) ← Domain-Sub-Skills (≤15 Domains/Batch)
|
|
463
|
+
│ │
|
|
464
|
+
│ └── 3d-aux × 1 (claude -p) ← database/ + mcp-guide/-Stubs
|
|
465
|
+
│
|
|
466
|
+
├── [7] Pass 4 × 1 (claude -p) ← Memory-Scaffolding (~30s-5min)
|
|
467
|
+
│ ├── Seeding von memory/ (decision-log, failure-patterns, …)
|
|
468
|
+
│ ├── 60.memory/-Regeln generieren
|
|
469
|
+
│ ├── "Memory (L4)"-Sektion an CLAUDE.md anhängen
|
|
470
|
+
│ └── Gap-Fill: skills/00.shared/MANIFEST.md sicherstellen (v2.1.0)
|
|
471
|
+
│
|
|
472
|
+
└── [8] Verifikation ← Health-Checker läuft automatisch
|
|
473
|
+
```
|
|
474
|
+
|
|
475
|
+
### Warum 4 Passes?
|
|
476
|
+
|
|
477
|
+
**Pass 1** ist der einzige Pass, der Ihren Quellcode liest. Er wählt repräsentative Dateien pro Domain und extrahiert Muster über 55–95 Analyse-Kategorien (pro Stack). Bei großen Projekten läuft Pass 1 mehrfach — einmal pro Domain-Gruppe. In Multi-Stack-Projekten (z. B. Java-Backend + React-Frontend) verwenden Backend- und Frontend-Domains **unterschiedliche Analyse-Prompts**, die auf jeden Stack zugeschnitten sind.
|
|
478
|
+
|
|
479
|
+
**Pass 2** führt alle Pass-1-Ergebnisse zu einer einheitlichen Analyse zusammen: gemeinsame Muster (100 % geteilt), Mehrheitsmuster (50 %+ geteilt), domain-spezifische Muster, Anti-Patterns nach Schweregrad und Cross-Cutting-Concerns (Naming, Security, DB, Testing, Logging, Performance). Backend- und Frontend-Ergebnisse werden zusammengeführt.
|
|
480
|
+
|
|
481
|
+
**Pass 3** (Split-Mode, v2.1.0) nimmt die zusammengeführte Analyse und generiert das gesamte Datei-Ökosystem (CLAUDE.md, Rules, Standards, Skills, Guides) über mehrere sequenzielle `claude -p`-Aufrufe. Die zentrale Einsicht: Output-Akkumulations-Overflow ist nicht aus der Input-Größe vorhersagbar — Single-Call-Pass-3 funktionierte auf 2-Domain-Projekten einwandfrei und scheiterte bei ca. 5 Domains zuverlässig, wobei die Fehler-Grenze davon abhing, wie ausführlich jede Datei ausfiel. Split-Mode umgeht das strukturell — jede Stage startet mit einem frischen Context-Fenster und schreibt eine beschränkte Teilmenge von Dateien. Datei-übergreifende Konsistenz (der Hauptvorteil des Single-Call-Ansatzes) bleibt durch `pass3a-facts.md` erhalten, eine 5–10 KB große destillierte Fact Sheet, die jede spätere Stage referenziert.
|
|
482
|
+
|
|
483
|
+
Das Pass-3-Prompt-Template enthält zudem einen **Phase-1-Block „Read Once, Extract Facts"** mit fünf Regeln, die den Output weiter begrenzen:
|
|
484
|
+
|
|
485
|
+
- **Rule A** — Referenziere die Fact-Tabelle; lies `pass2-merged.json` nicht erneut.
|
|
486
|
+
- **Rule B** — Idempotentes Datei-Schreiben (überspringe, wenn das Ziel mit echtem Inhalt existiert), macht Pass 3 nach Unterbrechungen sicher wiederausführbar.
|
|
487
|
+
- **Rule C** — Datei-übergreifende Konsistenz über die Fact-Tabelle als Single Source of Truth erzwungen.
|
|
488
|
+
- **Rule D** — Output-Knappheit: eine Zeile (`[WRITE]`/`[SKIP]`) zwischen Datei-Schreibvorgängen, keine Wiederholung der Fact-Tabelle, kein Echoing des Datei-Inhalts.
|
|
489
|
+
- **Rule E** — Batch-Idempotenz-Prüfung: ein `Glob` zu PHASE-2-Beginn statt Per-Target-`Read`-Aufrufe.
|
|
490
|
+
|
|
491
|
+
**Pass 4** baut die L4-Memory-Schicht auf: persistente Team-Wissensdateien (decision-log, failure-patterns, Compaction-Policy, auto-rule-update) plus die `60.memory/`-Regeln, die zukünftigen Sessions mitteilen, wann und wie diese Dateien gelesen/geschrieben werden sollen. Die Memory-Schicht ist das, was Claude Code erlaubt, Lehren über Sessions hinweg anzusammeln, anstatt sie jedes Mal neu zu entdecken. Wenn `--lang` nicht-englisch ist, wird der statische Fallback-Inhalt über Claude übersetzt, bevor er geschrieben wird. v2.1.0 fügt ein Gap-Fill für `skills/00.shared/MANIFEST.md` hinzu, falls Pass 3c es ausgelassen hat.
|
|
492
|
+
|
|
493
|
+
---
|
|
494
|
+
|
|
495
|
+
## Struktur der generierten Dateien
|
|
496
|
+
|
|
497
|
+
```
|
|
498
|
+
your-project/
|
|
499
|
+
│
|
|
500
|
+
├── CLAUDE.md ← Claude-Code-Einstiegspunkt
|
|
501
|
+
│
|
|
502
|
+
├── .claude/
|
|
503
|
+
│ └── rules/ ← Glob-getriggerte Regeln
|
|
504
|
+
│ ├── 00.core/
|
|
505
|
+
│ ├── 10.backend/
|
|
506
|
+
│ ├── 20.frontend/
|
|
507
|
+
│ ├── 30.security-db/
|
|
508
|
+
│ ├── 40.infra/
|
|
509
|
+
│ ├── 50.sync/ ← Sync-Erinnerungs-Regeln
|
|
510
|
+
│ └── 60.memory/ ← L4-Memory-On-Demand-Scope-Regeln (v2.0.0)
|
|
511
|
+
│
|
|
512
|
+
├── claudeos-core/ ← Hauptausgabeverzeichnis
|
|
513
|
+
│ ├── generated/ ← Analyse-JSON + dynamische Prompts + Pass-Marker (gitignore)
|
|
514
|
+
│ │ ├── project-analysis.json ← Stack-Infos (multi-stack-fähig)
|
|
515
|
+
│ │ ├── domain-groups.json ← Gruppen mit type: backend/frontend
|
|
516
|
+
│ │ ├── pass1-backend-prompt.md ← Backend-Analyse-Prompt
|
|
517
|
+
│ │ ├── pass1-frontend-prompt.md ← Frontend-Analyse-Prompt (falls erkannt)
|
|
518
|
+
│ │ ├── pass2-prompt.md ← Merge-Prompt
|
|
519
|
+
│ │ ├── pass2-merged.json ← Pass-2-Output (nur von Pass 3a konsumiert)
|
|
520
|
+
│ │ ├── pass3-context.json ← Schlanke Zusammenfassung (< 5 KB) für Pass 3 (v2.1.0)
|
|
521
|
+
│ │ ├── pass3-prompt.md ← Pass-3-Prompt-Template (Phase-1-Block vorangestellt)
|
|
522
|
+
│ │ ├── pass3a-facts.md ← Fact Sheet von Pass 3a geschrieben, von 3b/3c/3d gelesen (v2.1.0)
|
|
523
|
+
│ │ ├── pass4-prompt.md ← Memory-Scaffolding-Prompt (v2.0.0)
|
|
524
|
+
│ │ ├── pass3-complete.json ← Pass-3-Completion-Marker (Split-Mode: enthält groupsCompleted, v2.1.0)
|
|
525
|
+
│ │ ├── pass4-memory.json ← Pass-4-Completion-Marker (beim Resume überspringen)
|
|
526
|
+
│ │ ├── rule-manifest.json ← Datei-Index für Verifikations-Tools
|
|
527
|
+
│ │ ├── sync-map.json ← Plan ↔ Disk-Mapping (in v2.1.0 leer; aus Kompatibilitätsgründen für sync-checker erhalten)
|
|
528
|
+
│ │ ├── stale-report.json ← Konsolidierte Verifikations-Ergebnisse
|
|
529
|
+
│ │ ├── .i18n-cache-<lang>.json ← Übersetzungs-Cache (nicht-englisches `--lang`)
|
|
530
|
+
│ │ └── .staged-rules/ ← Transientes Staging-Verzeichnis für `.claude/rules/`-Schreibvorgänge (auto-verschoben + bereinigt)
|
|
531
|
+
│ ├── standard/ ← Coding-Standards (15–19 Dateien + pro Domain unter 60.domains/)
|
|
532
|
+
│ │ ├── 00.core/ ← Overview, Architektur, Naming
|
|
533
|
+
│ │ ├── 10.backend-api/ ← API-Muster (stack-spezifisch)
|
|
534
|
+
│ │ ├── 20.frontend-ui/ ← Frontend-Muster (falls erkannt)
|
|
535
|
+
│ │ ├── 30.security-db/ ← Security, DB-Schema, Utilities
|
|
536
|
+
│ │ ├── 40.infra/ ← Config, Logging, CI/CD
|
|
537
|
+
│ │ ├── 50.verification/ ← Build-Verifikation, Testing
|
|
538
|
+
│ │ ├── 60.domains/ ← Pro-Domain-Standards (von Pass 3b-N geschrieben, v2.1.0)
|
|
539
|
+
│ │ └── 90.optional/ ← Optionale Konventionen (stack-spezifische Extras)
|
|
540
|
+
│ ├── skills/ ← CRUD-/Page-Scaffolding-Skills
|
|
541
|
+
│ │ └── 00.shared/MANIFEST.md ← Single Source of Truth für registrierte Skills
|
|
542
|
+
│ ├── guide/ ← Onboarding, FAQ, Troubleshooting (9 Dateien)
|
|
543
|
+
│ ├── database/ ← DB-Schema, Migration-Guide
|
|
544
|
+
│ ├── mcp-guide/ ← MCP-Server-Integrations-Guide
|
|
545
|
+
│ └── memory/ ← L4: Team-Wissen (4 Dateien) — committen
|
|
546
|
+
│ ├── decision-log.md ← „Warum" hinter Design-Entscheidungen
|
|
547
|
+
│ ├── failure-patterns.md ← Wiederkehrende Fehler & Fixes (Auto-Score — `npx claudeos-core memory score`)
|
|
548
|
+
│ ├── compaction.md ← 4-Stage-Compaction-Strategie (`npx claudeos-core memory compact` ausführen)
|
|
549
|
+
│ └── auto-rule-update.md ← Rule-Verbesserungs-Vorschläge (`npx claudeos-core memory propose-rules`)
|
|
550
|
+
│
|
|
551
|
+
└── claudeos-core-tools/ ← Dieses Toolkit (nicht ändern)
|
|
552
|
+
```
|
|
553
|
+
|
|
554
|
+
Jede Standard-Datei enthält ✅-korrekte Beispiele, ❌-fehlerhafte Beispiele und eine Regel-Zusammenfassungstabelle — alles aus Ihren tatsächlichen Code-Mustern abgeleitet, nicht aus generischen Templates.
|
|
555
|
+
|
|
556
|
+
> **Hinweis zu v2.1.0:** `claudeos-core/plan/` wird nicht mehr generiert. Master Plans waren ein internes Backup, das Claude Code zur Laufzeit nicht konsumierte, und ihre Aggregation in Pass 3 war eine primäre Ursache für Output-Akkumulations-Overflows. Verwenden Sie stattdessen `git` für Backup/Restore. Projekte, die von v2.0.x upgraden, können ein bestehendes `claudeos-core/plan/`-Verzeichnis bedenkenlos löschen.
|
|
557
|
+
|
|
558
|
+
### Gitignore-Empfehlungen
|
|
559
|
+
|
|
560
|
+
**Committen** (Team-Wissen — zum Teilen gedacht):
|
|
561
|
+
- `CLAUDE.md` — Claude-Code-Einstiegspunkt
|
|
562
|
+
- `.claude/rules/**` — automatisch geladene Regeln
|
|
563
|
+
- `claudeos-core/standard/**`, `skills/**`, `guide/**`, `database/**`, `mcp-guide/**`, `plan/**` — generierte Dokumentation
|
|
564
|
+
- `claudeos-core/memory/**` — Entscheidungshistorie, Failure-Patterns, Rule-Vorschläge
|
|
565
|
+
|
|
566
|
+
**NICHT committen** (regenerierbare Build-Artefakte):
|
|
567
|
+
|
|
568
|
+
```gitignore
|
|
569
|
+
# ClaudeOS-Core — generierte Analyse & Übersetzungs-Cache
|
|
570
|
+
claudeos-core/generated/
|
|
571
|
+
```
|
|
572
|
+
|
|
573
|
+
Das `generated/`-Verzeichnis enthält Analyse-JSON (`pass1-*.json`, `pass2-merged.json`), Prompts (`pass1/2/3/4-prompt.md`), Pass-Completion-Marker (`pass3-complete.json`, `pass4-memory.json`), Übersetzungs-Cache (`.i18n-cache-<lang>.json`) und das transiente Staging-Verzeichnis (`.staged-rules/`) — alles durch erneutes Ausführen von `npx claudeos-core init` wiederherstellbar.
|
|
574
|
+
|
|
575
|
+
---
|
|
576
|
+
|
|
577
|
+
## Auto-Scaling nach Projektgröße
|
|
578
|
+
|
|
579
|
+
Der Split-Mode von Pass 3 skaliert die Stage-Anzahl mit der Domain-Anzahl. Die Batch-Unterteilung greift ab 16 Domains, um jede Stage unter ~50 Output-Dateien zu halten — dem empirischen Sicherheitsbereich für `claude -p`, bevor Output-Akkumulations-Overflows einsetzen.
|
|
580
|
+
|
|
581
|
+
| Projektgröße | Domains | Pass-3-Stages | Gesamt `claude -p` | Gesch. Zeit |
|
|
582
|
+
|---|---|---|---|---|
|
|
583
|
+
| Klein | 1–4 | 4 (`3a`, `3b-core`, `3c-core`, `3d-aux`) | 7 (Pass 1 + 2 + 4 Stages von Pass 3 + Pass 4) | ~10–15 min |
|
|
584
|
+
| Mittel | 5–15 | 4 | 8–9 | ~25–45 min |
|
|
585
|
+
| Groß | 16–30 | **8** (3b, 3c jeweils in 2 Batches aufgeteilt) | 11–12 | **~60–105 min** |
|
|
586
|
+
| X-Groß | 31–45 | 10 | 13–14 | ~100–150 min |
|
|
587
|
+
| XX-Groß | 46–60 | 12 | 15–16 | ~150–200 min |
|
|
588
|
+
| XXX-Groß | 61+ | 14+ | 17+ | 200 min+ |
|
|
589
|
+
|
|
590
|
+
Stage-Anzahl-Formel (bei aktivierter Batch-Teilung): `1 (3a) + 1 (3b-core) + N (3b-1..N) + 1 (3c-core) + N (3c-1..N) + 1 (3d-aux) = 2N + 4`, wobei `N = ceil(totalDomains / 15)`.
|
|
591
|
+
|
|
592
|
+
Pass 4 (Memory-Scaffolding) fügt je nach Ausführungspfad (Claude-getriebene Generierung oder statischer Fallback) ~30 Sekunden bis 5 Minuten hinzu. Für Multi-Stack-Projekte (z. B. Java + React) werden Backend- und Frontend-Domains zusammen gezählt. Ein Projekt mit 6 Backend- + 4 Frontend-Domains = 10 gesamt = Stufe Mittel.
|
|
593
|
+
|
|
594
|
+
### Reale Produktions-Fallstudie: 18-Domain-Admin-Frontend (2026-04-20)
|
|
595
|
+
|
|
596
|
+
Ein React-19- + Vite-6- + TypeScript-Admin-Frontend mit 18 Domains und 6 Domain-Gruppen lief End-to-End in **102 Minuten mit 101 generierten Dateien** durch. Stage-Aufschlüsselung:
|
|
597
|
+
|
|
598
|
+
| Stage | Dateien | Zeit | Dateien/min |
|
|
599
|
+
|---|---|---|---|
|
|
600
|
+
| `3a` (Fakten-Extraktion) | 1 (`pass3a-facts.md`) | 8m 44s | — |
|
|
601
|
+
| `3b-core` (CLAUDE.md + gemeinsam) | 24 | 22m 10s | 1,1 |
|
|
602
|
+
| `3b-1` (15 Domains) | 30 | 10m 6s | **3,0** |
|
|
603
|
+
| `3b-2` (3 Domains) | 6 | 4m 34s | 1,3 |
|
|
604
|
+
| `3c-core` (Guides + geteilt) | 11 | 8m 31s | 1,3 |
|
|
605
|
+
| `3c-1` (15 Domains) | 8 | 5m 11s | **1,5** |
|
|
606
|
+
| `3c-2` (3 Domains) | 3 | 3m 50s | 0,8 |
|
|
607
|
+
| `3d-aux` (database + mcp) | 3 | 2m 52s | 1,0 |
|
|
608
|
+
| Pass 4 | 12 | 5m 36s | 2,1 |
|
|
609
|
+
|
|
610
|
+
Der Durchsatz ist bei den batched Domain-Stages deutlich höher (3b-1: 3,0 Dateien/min vs. 3b-core: 1,1 Dateien/min), weil Stages mit frischem Context von engen, wiederholbaren Per-Domain-Mustern profitieren. Verifikation komplett grün: `plan-validator`, `sync-checker`, `content-validator`, `pass-json-validator` — null Overflow-Fehler, null Abschneidungen.
|
|
611
|
+
|
|
612
|
+
---
|
|
613
|
+
|
|
614
|
+
## Verifikations-Tools
|
|
615
|
+
|
|
616
|
+
ClaudeOS-Core enthält 5 eingebaute Verifikations-Tools, die automatisch nach der Generierung laufen:
|
|
617
|
+
|
|
618
|
+
```bash
|
|
619
|
+
# Alle Checks auf einmal ausführen (empfohlen)
|
|
620
|
+
npx claudeos-core health
|
|
621
|
+
|
|
622
|
+
# Einzelne Befehle
|
|
623
|
+
npx claudeos-core validate # Plan ↔ Disk-Vergleich
|
|
624
|
+
npx claudeos-core refresh # Disk → Plan-Sync
|
|
625
|
+
npx claudeos-core restore # Plan → Disk-Restore
|
|
626
|
+
|
|
627
|
+
# Oder node direkt verwenden (git-clone-User)
|
|
628
|
+
node claudeos-core-tools/health-checker/index.js
|
|
629
|
+
node claudeos-core-tools/manifest-generator/index.js
|
|
630
|
+
node claudeos-core-tools/plan-validator/index.js --check
|
|
631
|
+
node claudeos-core-tools/sync-checker/index.js
|
|
632
|
+
```
|
|
633
|
+
|
|
634
|
+
| Tool | Funktion |
|
|
635
|
+
|---|---|
|
|
636
|
+
| **manifest-generator** | Baut Metadaten-JSON (`rule-manifest.json`, `sync-map.json`, initialisiert `stale-report.json`); indexiert 7 Verzeichnisse einschließlich `memory/` (`totalMemory` in der Summary). v2.1.0: `plan-manifest.json` wird nicht mehr generiert, da Master Plans entfernt wurden. |
|
|
637
|
+
| **plan-validator** | Validiert Master-Plan-`<file>`-Blöcke gegen die Disk für Projekte, die noch ein `claudeos-core/plan/` besitzen (Legacy-Upgrade-Fall). v2.1.0: überspringt die Emission von `plan-sync-status.json`, wenn `plan/` fehlt oder leer ist — `stale-report.json` hält dennoch einen bestandenen No-op fest. |
|
|
638
|
+
| **sync-checker** | Erkennt nicht registrierte Dateien (auf Disk, aber nicht im Plan) und verwaiste Einträge — deckt 7 Verzeichnisse ab (in v2.0.0 `memory/` hinzugefügt). Beendet sich sauber, wenn `sync-map.json` keine Mappings hat (v2.1.0-Default-Zustand). |
|
|
639
|
+
| **content-validator** | 9-Sektionen-Qualitätscheck — leere Dateien, fehlende ✅/❌-Beispiele, erforderliche Sektionen plus L4-Memory-Scaffold-Integrität (decision-log-Heading-Dates, failure-pattern-Pflichtfelder, fence-aware Parsing) |
|
|
640
|
+
| **pass-json-validator** | Validiert Pass-1–4-JSON-Struktur plus die Completion-Marker `pass3-complete.json` (Split-Mode-Shape, v2.1.0) und `pass4-memory.json` |
|
|
641
|
+
|
|
642
|
+
---
|
|
643
|
+
|
|
644
|
+
## Wie Claude Code Ihre Dokumentation nutzt
|
|
645
|
+
|
|
646
|
+
ClaudeOS-Core generiert Dokumentation, die Claude Code tatsächlich liest — hier ist wie:
|
|
647
|
+
|
|
648
|
+
### Was Claude Code automatisch liest
|
|
649
|
+
|
|
650
|
+
| Datei | Wann | Garantiert |
|
|
651
|
+
|---|---|---|
|
|
652
|
+
| `CLAUDE.md` | Bei jedem Gesprächsbeginn | Immer |
|
|
653
|
+
| `.claude/rules/00.core/*` | Wenn eine beliebige Datei editiert wird (`paths: ["**/*"]`) | Immer |
|
|
654
|
+
| `.claude/rules/10.backend/*` | Wenn eine beliebige Datei editiert wird (`paths: ["**/*"]`) | Immer |
|
|
655
|
+
| `.claude/rules/20.frontend/*` | Wenn eine Frontend-Datei editiert wird (eingeschränkt auf Component-/Page-/Style-Pfade) | Bedingt |
|
|
656
|
+
| `.claude/rules/30.security-db/*` | Wenn eine beliebige Datei editiert wird (`paths: ["**/*"]`) | Immer |
|
|
657
|
+
| `.claude/rules/40.infra/*` | Nur beim Editieren von Config/Infra-Dateien (eingeschränkte Pfade) | Bedingt |
|
|
658
|
+
| `.claude/rules/50.sync/*` | Nur beim Editieren von claudeos-core-Dateien (eingeschränkte Pfade) | Bedingt |
|
|
659
|
+
| `.claude/rules/60.memory/*` | Wenn `claudeos-core/memory/*` editiert wird (eingeschränkt auf Memory-Pfade) — weist an, **wie** die On-Demand-Memory-Schicht gelesen/geschrieben wird | Bedingt (v2.0.0) |
|
|
660
|
+
|
|
661
|
+
### Was Claude Code bei Bedarf über Rule-Referenzen liest
|
|
662
|
+
|
|
663
|
+
Jede Rule-Datei verlinkt über einen `## Reference`-Abschnitt auf den zugehörigen Standard. Claude liest nur den für die aktuelle Aufgabe relevanten Standard:
|
|
664
|
+
|
|
665
|
+
- `claudeos-core/standard/**` — Coding-Muster, ✅/❌-Beispiele, Naming-Konventionen
|
|
666
|
+
- `claudeos-core/database/**` — DB-Schema (für Queries, Mapper, Migrationen)
|
|
667
|
+
- `claudeos-core/memory/**` (v2.0.0) — L4-Team-Wissensschicht; **nicht** auto-geladen (wäre bei jedem Gespräch zu rauschend). Stattdessen teilen die `60.memory/*`-Regeln Claude *wann* diese Dateien zu lesen sind: bei Session-Start (aktuelle `decision-log.md` überfliegen + High-Importance-`failure-patterns.md`), und append-on-demand bei Entscheidungen oder wiederkehrenden Fehlern.
|
|
668
|
+
|
|
669
|
+
Die `00.standard-reference.md` dient als Verzeichnis aller Standard-Dateien, um Standards zu finden, die keine entsprechende Regel haben.
|
|
670
|
+
|
|
671
|
+
### Was Claude Code NICHT liest (spart Context)
|
|
672
|
+
|
|
673
|
+
Diese Ordner werden explizit über den `DO NOT Read`-Abschnitt in der Standard-Reference-Rule ausgeschlossen:
|
|
674
|
+
|
|
675
|
+
| Ordner | Warum ausgeschlossen |
|
|
676
|
+
|---|---|
|
|
677
|
+
| `claudeos-core/plan/` | Master-Plan-Backups aus Legacy-Projekten (v2.0.x und älter). Wird in v2.1.0 nicht generiert. Falls vorhanden, lädt Claude Code es nicht automatisch — nur Read-on-Demand. |
|
|
678
|
+
| `claudeos-core/generated/` | Build-Metadaten-JSON, Prompts, Pass-Marker, Übersetzungs-Cache, `.staged-rules/`. Nicht zum Coden. |
|
|
679
|
+
| `claudeos-core/guide/` | Onboarding-Guides für Menschen. |
|
|
680
|
+
| `claudeos-core/mcp-guide/` | MCP-Server-Docs. Nicht zum Coden. |
|
|
681
|
+
| `claudeos-core/memory/` (Auto-Load) | **Auto-Load deaktiviert** by design — würde den Context bei jedem Gespräch aufblähen. Stattdessen on-demand über die `60.memory/*`-Regeln lesen (z. B. Session-Start-Scan von `failure-patterns.md`). Diese Dateien immer committen. |
|
|
682
|
+
|
|
683
|
+
---
|
|
684
|
+
|
|
685
|
+
## Täglicher Workflow
|
|
686
|
+
|
|
687
|
+
### Nach der Installation
|
|
688
|
+
|
|
689
|
+
```
|
|
690
|
+
# Claude Code einfach wie gewohnt benutzen — er referenziert Ihre Standards automatisch:
|
|
691
|
+
"Erstelle ein CRUD für die order-Domain"
|
|
692
|
+
"Füge eine User-Profile-Update-API hinzu"
|
|
693
|
+
"Refactore diesen Code, um den Projektmustern zu entsprechen"
|
|
694
|
+
```
|
|
695
|
+
|
|
696
|
+
### Nach manueller Bearbeitung von Standards
|
|
697
|
+
|
|
698
|
+
```bash
|
|
699
|
+
# Nach Bearbeitung von Standards- oder Rule-Dateien:
|
|
700
|
+
npx claudeos-core refresh
|
|
701
|
+
|
|
702
|
+
# Verifizieren, dass alles konsistent ist
|
|
703
|
+
npx claudeos-core health
|
|
704
|
+
```
|
|
705
|
+
|
|
706
|
+
### Wenn Docs beschädigt werden
|
|
707
|
+
|
|
708
|
+
```bash
|
|
709
|
+
# v2.1.0-Empfehlung: Wiederherstellung über git (da Master Plans nicht
|
|
710
|
+
# mehr generiert werden). Committen Sie Ihre generierten Dokumente
|
|
711
|
+
# regelmäßig, damit Sie einzelne Dateien zurücksetzen können, ohne
|
|
712
|
+
# neu zu generieren:
|
|
713
|
+
git checkout HEAD -- .claude/rules/ claudeos-core/
|
|
714
|
+
|
|
715
|
+
# Legacy (v2.0.x-Projekte mit noch vorhandenem claudeos-core/plan/):
|
|
716
|
+
npx claudeos-core restore
|
|
717
|
+
```
|
|
718
|
+
|
|
719
|
+
### Memory-Schicht-Pflege (v2.0.0)
|
|
720
|
+
|
|
721
|
+
Die L4-Memory-Schicht (`claudeos-core/memory/`) sammelt Team-Wissen über Sessions hinweg. Drei CLI-Subcommands halten sie gesund:
|
|
722
|
+
|
|
723
|
+
```bash
|
|
724
|
+
# Compact: 4-Stage-Compaction-Policy anwenden (regelmäßig — z. B. monatlich)
|
|
725
|
+
npx claudeos-core memory compact
|
|
726
|
+
# Stage 1: alte Einträge zusammenfassen (>30 Tage, Body → eine Zeile)
|
|
727
|
+
# Stage 2: doppelte Headings mergen (Frequency summiert, letzter Fix behalten)
|
|
728
|
+
# Stage 3: Low-Importance + alt droppen (importance <3 UND lastSeen >60 Tage)
|
|
729
|
+
# Stage 4: 400-Zeilen-Cap pro Datei erzwingen (ältestes Low-Importance zuerst gedroppt)
|
|
730
|
+
|
|
731
|
+
# Score: failure-patterns.md-Einträge nach Importance neu ranken
|
|
732
|
+
npx claudeos-core memory score
|
|
733
|
+
# importance = round(frequency × 1.5 + recency × 5), bei 10 gecapped
|
|
734
|
+
# Ausführen nach dem Anhängen mehrerer neuer Failure-Patterns
|
|
735
|
+
|
|
736
|
+
# Propose-rules: Kandidaten für Rule-Ergänzungen aus wiederkehrenden Failures herausarbeiten
|
|
737
|
+
npx claudeos-core memory propose-rules
|
|
738
|
+
# Liest failure-patterns.md-Einträge mit frequency ≥ 3
|
|
739
|
+
# Berechnet Confidence (Sigmoid auf gewichteter Evidenz × Anker-Multiplikator)
|
|
740
|
+
# Schreibt Vorschläge nach memory/auto-rule-update.md (NICHT auto-angewendet)
|
|
741
|
+
# Confidence ≥ 0.70 verdient ernsthafte Prüfung; akzeptieren → Rule editieren + Entscheidung loggen
|
|
742
|
+
|
|
743
|
+
# v2.1.0: `memory --help` leitet jetzt zur Subcommand-Hilfe weiter (zuvor wurde die Top-Level-Hilfe angezeigt)
|
|
744
|
+
npx claudeos-core memory --help
|
|
745
|
+
```
|
|
746
|
+
|
|
747
|
+
> **v2.1.0-Fixes:** `memory score` hinterlässt nach dem ersten Lauf keine doppelten `importance`-Zeilen mehr (zuvor wurde die auto-bewertete Zeile oben hinzugefügt, während die ursprüngliche Plain-Zeile darunter stehen blieb). Der Stage-1-Summary-Marker von `memory compact` ist nun ein korrektes Markdown-Listenelement (`- _Summarized on ..._`), sodass er sauber rendert und bei nachfolgenden Compactions korrekt neu geparst wird.
|
|
748
|
+
|
|
749
|
+
Wann in Memory schreiben (Claude macht das on-demand, aber Sie können auch manuell editieren):
|
|
750
|
+
- **`decision-log.md`** — neuen Eintrag anhängen, wenn Sie zwischen konkurrierenden Mustern wählen, eine Bibliothek auswählen, eine Team-Konvention definieren oder entscheiden, etwas NICHT zu tun. Append-only; historische Einträge niemals editieren.
|
|
751
|
+
- **`failure-patterns.md`** — beim **zweiten Auftreten** eines wiederkehrenden Fehlers oder einer nicht offensichtlichen Root-Cause anhängen. Erstmalige Fehler brauchen keinen Eintrag.
|
|
752
|
+
- `compaction.md` und `auto-rule-update.md` — werden von den CLI-Subcommands oben generiert/verwaltet; nicht von Hand editieren.
|
|
753
|
+
|
|
754
|
+
### CI/CD-Integration
|
|
755
|
+
|
|
756
|
+
```yaml
|
|
757
|
+
# GitHub-Actions-Beispiel
|
|
758
|
+
- run: npx claudeos-core validate
|
|
759
|
+
# Exit-Code 1 blockiert den PR
|
|
760
|
+
|
|
761
|
+
# Optional: monatliches Memory-Housekeeping (separater Cron-Workflow)
|
|
762
|
+
- run: npx claudeos-core memory compact
|
|
763
|
+
- run: npx claudeos-core memory score
|
|
764
|
+
```
|
|
765
|
+
|
|
766
|
+
---
|
|
767
|
+
|
|
768
|
+
## Wie unterscheidet sich das?
|
|
769
|
+
|
|
770
|
+
### vs. andere Claude-Code-Tools
|
|
771
|
+
|
|
772
|
+
| | ClaudeOS-Core | Everything Claude Code (50K+ ⭐) | Harness | specs-generator | Claude `/init` |
|
|
773
|
+
|---|---|---|---|---|---|
|
|
774
|
+
| **Ansatz** | Code analysiert zuerst, dann LLM generiert | Vorgefertigte Config-Presets | LLM designt Agent-Teams | LLM generiert Spec-Docs | LLM schreibt CLAUDE.md |
|
|
775
|
+
| **Liest Ihren Quellcode** | ✅ Deterministische statische Analyse | ❌ | ❌ | ❌ (LLM liest) | ❌ (LLM liest) |
|
|
776
|
+
| **Stack-Erkennung** | Code bestätigt (ORM, DB, Build-Tool, Pkg-Manager) | N/V (stack-agnostisch) | LLM rät | LLM rät | LLM rät |
|
|
777
|
+
| **Domain-Erkennung** | Code bestätigt (Java 5 Muster, Kotlin CQRS, Next.js FSD) | N/V | LLM rät | N/V | N/V |
|
|
778
|
+
| **Gleiches Projekt → gleiches Ergebnis** | ✅ Deterministische Analyse | ✅ (statische Dateien) | ❌ (LLM variiert) | ❌ (LLM variiert) | ❌ (LLM variiert) |
|
|
779
|
+
| **Handhabung großer Projekte** | Domain-Gruppen-Splitting (4 Domains / 40 Dateien pro Gruppe) | N/V | Kein Splitting | Kein Splitting | Context-Window-Limit |
|
|
780
|
+
| **Output** | CLAUDE.md + Rules + Standards + Skills + Guides + Plans (40–50+ Dateien) | Agents + Skills + Commands + Hooks | Agents + Skills | 6 Spec-Dokumente | CLAUDE.md (1 Datei) |
|
|
781
|
+
| **Output-Ort** | `.claude/rules/` (auto-geladen von Claude Code) | `.claude/` diverse | `.claude/agents/` + `.claude/skills/` | `.claude/steering/` + `specs/` | `CLAUDE.md` |
|
|
782
|
+
| **Post-Generierungs-Verifikation** | ✅ 5 automatisierte Validatoren | ❌ | ❌ | ❌ | ❌ |
|
|
783
|
+
| **Multi-Language-Output** | ✅ 10 Sprachen | ❌ | ❌ | ❌ | ❌ |
|
|
784
|
+
| **Multi-Stack** | ✅ Backend + Frontend simultan | ❌ Stack-agnostisch | ❌ | ❌ | Teilweise |
|
|
785
|
+
| **Persistente Memory-Schicht** | ✅ L4 — Decision-Log + Failure-Patterns + auto-bewertete Rule-Vorschläge (v2.0.0) | ❌ | ❌ | ❌ | ❌ |
|
|
786
|
+
| **Agent-Orchestrierung** | ❌ | ✅ 28 Agents | ✅ 6 Muster | ❌ | ❌ |
|
|
787
|
+
|
|
788
|
+
### Der Schlüsselunterschied in einem Satz
|
|
789
|
+
|
|
790
|
+
**Andere Tools geben Claude „allgemein gute Anweisungen". ClaudeOS-Core gibt Claude „Anweisungen, die aus Ihrem tatsächlichen Code extrahiert wurden".**
|
|
791
|
+
|
|
792
|
+
Deshalb hört Claude Code auf, JPA-Code in Ihrem MyBatis-Projekt zu generieren,
|
|
793
|
+
hört auf, `success()` zu verwenden, wenn Ihre Codebasis `ok()` nutzt,
|
|
794
|
+
und hört auf, `user/controller/`-Verzeichnisse zu erstellen, wenn Ihr Projekt `controller/user/` verwendet.
|
|
795
|
+
|
|
796
|
+
### Ergänzend, nicht konkurrierend
|
|
797
|
+
|
|
798
|
+
ClaudeOS-Core fokussiert sich auf **projektspezifische Regeln und Standards**.
|
|
799
|
+
Andere Tools fokussieren sich auf **Agent-Orchestrierung und Workflows**.
|
|
800
|
+
|
|
801
|
+
Sie können ClaudeOS-Core verwenden, um Ihre Projekt-Rules zu generieren, und darauf aufbauend ECC oder Harness für Agent-Teams und Workflow-Automatisierung. Sie lösen unterschiedliche Probleme.
|
|
802
|
+
|
|
803
|
+
---
|
|
804
|
+
|
|
805
|
+
## FAQ
|
|
806
|
+
|
|
807
|
+
**F: Modifiziert es meinen Quellcode?**
|
|
808
|
+
Nein. Es erstellt nur `CLAUDE.md`, `.claude/rules/` und `claudeos-core/`. Ihr bestehender Code wird niemals modifiziert.
|
|
809
|
+
|
|
810
|
+
**F: Wie viel kostet es?**
|
|
811
|
+
Es ruft `claude -p` mehrfach über die 4 Passes hinweg auf. Im v2.1.0-Split-Mode expandiert allein Pass 3 je nach Projektgröße in 4–14+ Stages (siehe [Auto-Scaling](#auto-scaling-nach-projektgröße)). Ein typisches kleines Projekt (1–15 Domains) verwendet insgesamt 8–9 `claude -p`-Aufrufe; ein 18-Domain-Projekt 11; ein 60-Domain-Projekt 15–17. Jede Stage läuft mit einem frischen Context-Fenster — die Token-Kosten pro Aufruf sind sogar niedriger als beim früheren Single-Call-Pass-3, weil keine Stage den gesamten Datei-Baum in einem Context halten muss. Wenn `--lang` nicht-englisch ist, kann der statische Fallback-Pfad einige zusätzliche `claude -p`-Aufrufe für Übersetzungen auslösen; Ergebnisse werden in `claudeos-core/generated/.i18n-cache-<lang>.json` gecacht, sodass nachfolgende Läufe sie wiederverwenden. Das liegt im Rahmen der normalen Claude-Code-Nutzung.
|
|
812
|
+
|
|
813
|
+
**F: Was ist der Pass-3-Split-Mode und warum wurde er in v2.1.0 eingeführt?**
|
|
814
|
+
Vor v2.1.0 führte Pass 3 einen einzigen `claude -p`-Aufruf aus, der den gesamten generierten Datei-Baum (`CLAUDE.md`, Standards, Rules, Skills, Guides — typischerweise 30–60 Dateien) in einer Antwort ausgeben musste. Das funktionierte bei kleinen Projekten, traf aber bei ca. 5 Domains zuverlässig auf `Prompt is too long`-Output-Akkumulations-Fehler. Der Fehler war nicht aus der Input-Größe vorhersagbar — er hing davon ab, wie ausführlich jede generierte Datei ausfiel, und konnte dasselbe Projekt intermittierend treffen. Der Split-Mode umgeht das Problem strukturell: Pass 3 wird in sequenzielle Stages aufgeteilt (`3a` → `3b-core` → `3b-N` → `3c-core` → `3c-N` → `3d-aux`), jede ein separater `claude -p`-Aufruf mit frischem Context-Fenster. Die Konsistenz über Stages hinweg wird durch `pass3a-facts.md` erhalten, eine 5–10 KB große destillierte Fact Sheet, die jede spätere Stage referenziert, anstatt `pass2-merged.json` erneut zu lesen. Der `pass3-complete.json`-Marker trägt ein `groupsCompleted`-Array, sodass ein Crash während `3c-2` ab `3c-2` fortgesetzt wird (nicht ab `3a`), was doppelte Token-Kosten vermeidet. Empirisch verifiziert bis 18 Domains × 101 Dateien × 102 Minuten ohne Overflow — siehe [Auto-Scaling](#auto-scaling-nach-projektgröße) für die reale Produktionsaufschlüsselung.
|
|
815
|
+
|
|
816
|
+
**F: Soll ich die generierten Dateien in Git committen?**
|
|
817
|
+
Ja, empfohlen. Ihr Team kann dieselben Claude-Code-Standards teilen. Erwägen Sie, `claudeos-core/generated/` in `.gitignore` aufzunehmen (Analyse-JSON ist regenerierbar).
|
|
818
|
+
|
|
819
|
+
**F: Was ist mit Mixed-Stack-Projekten (z. B. Java-Backend + React-Frontend)?**
|
|
820
|
+
Vollständig unterstützt. ClaudeOS-Core erkennt beide Stacks automatisch, taggt Domains als `backend` oder `frontend` und verwendet stack-spezifische Analyse-Prompts für jeden. Pass 2 merged alles, und Pass 3 generiert sowohl Backend- als auch Frontend-Standards über seine Split-Stages hinweg — Backend-Domains landen in manchen 3b/3c-Batches, Frontend-Domains in anderen, wobei alle dieselbe `pass3a-facts.md` für Konsistenz referenzieren.
|
|
821
|
+
|
|
822
|
+
**F: Funktioniert es mit Turborepo / pnpm-Workspaces / Lerna-Monorepos?**
|
|
823
|
+
Ja. ClaudeOS-Core erkennt `turbo.json`, `pnpm-workspace.yaml`, `lerna.json` oder `package.json#workspaces` und scannt automatisch Sub-Package-`package.json`-Dateien nach Framework/ORM/DB-Abhängigkeiten. Das Domain-Scanning deckt `apps/*/src/`- und `packages/*/src/`-Muster ab. Vom Monorepo-Root ausführen.
|
|
824
|
+
|
|
825
|
+
**F: Was passiert bei einem erneuten Lauf?**
|
|
826
|
+
Wenn vorherige Pass-1/2-Ergebnisse existieren, lässt Sie ein interaktiver Prompt wählen: **Continue** (von der Unterbrechungsstelle fortsetzen) oder **Fresh** (alles löschen und neu beginnen). Verwenden Sie `--force`, um den Prompt zu überspringen und immer frisch zu starten. Im v2.1.0-Split-Mode funktioniert der Pass-3-Resume auf Stage-Granularität — wenn der Lauf während `3c-2` crashte, setzt das nächste `init` ab `3c-2` fort, anstatt von `3a` neu zu starten (was die Token-Kosten verdoppeln würde). Der `pass3-complete.json`-Marker hält `mode: "split"` plus ein `groupsCompleted`-Array fest, um diese Logik zu steuern.
|
|
827
|
+
|
|
828
|
+
**F: Bekommt NestJS ein eigenes Template oder verwendet es das Express-Template?**
|
|
829
|
+
NestJS verwendet ein dediziertes `node-nestjs`-Template mit NestJS-spezifischen Analyse-Kategorien: `@Module`-, `@Injectable`-, `@Controller`-Decorators, Guards, Pipes, Interceptors, DI-Container, CQRS-Muster und `Test.createTestingModule`. Express-Projekte verwenden das separate `node-express`-Template.
|
|
830
|
+
|
|
831
|
+
**F: Was ist mit Vue-/Nuxt-Projekten?**
|
|
832
|
+
Vue/Nuxt verwendet ein dediziertes `vue-nuxt`-Template, das Composition API, `<script setup>`, defineProps/defineEmits, Pinia-Stores, `useFetch`/`useAsyncData`, Nitro-Server-Routes und `@nuxt/test-utils` abdeckt. Next.js-/React-Projekte verwenden das `node-nextjs`-Template.
|
|
833
|
+
|
|
834
|
+
**F: Unterstützt es Kotlin?**
|
|
835
|
+
Ja. ClaudeOS-Core erkennt Kotlin automatisch aus `build.gradle.kts` oder dem kotlin-Plugin in `build.gradle`. Es verwendet ein dediziertes `kotlin-spring`-Template mit Kotlin-spezifischer Analyse (Data Classes, Sealed Classes, Coroutines, Extension Functions, MockK usw.).
|
|
836
|
+
|
|
837
|
+
**F: Was ist mit CQRS- / BFF-Architektur?**
|
|
838
|
+
Für Kotlin-Multi-Modul-Projekte vollständig unterstützt. ClaudeOS-Core liest `settings.gradle.kts`, erkennt Modultypen (command, query, bff, integration) aus Modulnamen und gruppiert dieselbe Domain über Command-/Query-Module. Die generierten Standards enthalten separate Regeln für Command-Controller vs. Query-Controller, BFF-/Feign-Muster und Inter-Modul-Kommunikationskonventionen.
|
|
839
|
+
|
|
840
|
+
**F: Was ist mit Gradle-Multi-Modul-Monorepos?**
|
|
841
|
+
ClaudeOS-Core scannt alle Submodule (`**/src/main/kotlin/**/*.kt`) unabhängig von der Verschachtelungstiefe. Modultypen werden aus Naming-Konventionen abgeleitet (z. B. `reservation-command-server` → Domain: `reservation`, Typ: `command`). Geteilte Bibliotheken (`shared-lib`, `integration-lib`) werden ebenfalls erkannt.
|
|
842
|
+
|
|
843
|
+
**F: Was ist die L4-Memory-Schicht (v2.0.0)? Soll ich `claudeos-core/memory/` committen?**
|
|
844
|
+
Ja — `claudeos-core/memory/` **immer committen**. Es ist persistentes Team-Wissen: `decision-log.md` hält das *Warum* hinter architektonischen Entscheidungen fest (append-only), `failure-patterns.md` registriert wiederkehrende Fehler mit Importance-Scores, damit zukünftige Sessions sie vermeiden, `compaction.md` definiert die 4-Stage-Compaction-Policy, und `auto-rule-update.md` sammelt maschinell generierte Rule-Verbesserungs-Vorschläge. Anders als Rules (pfad-basiert auto-geladen) sind Memory-Dateien **on-demand** — Claude liest sie nur, wenn die `60.memory/*`-Regeln ihn dazu auffordern (z. B. Session-Start-Scan von High-Importance-Failures). Das hält Context-Kosten niedrig, während langfristiges Wissen erhalten bleibt.
|
|
845
|
+
|
|
846
|
+
**F: Was, wenn Pass 4 fehlschlägt?**
|
|
847
|
+
Die automatisierte Pipeline (`npx claudeos-core init`) hat einen statischen Fallback: Wenn `claude -p` fehlschlägt oder `pass4-prompt.md` fehlt, wird die Memory-Schicht direkt über `lib/memory-scaffold.js` aufgebaut. Wenn `--lang` nicht-englisch ist, **muss** der statische Fallback über die `claude`-CLI übersetzen — schlägt das ebenfalls fehl, bricht der Lauf mit `InitError` ab (kein stiller englischer Fallback). Erneut ausführen, wenn `claude` authentifiziert ist, oder `--lang en` verwenden, um die Übersetzung zu überspringen. Übersetzungsergebnisse werden in `claudeos-core/generated/.i18n-cache-<lang>.json` gecacht, sodass nachfolgende Läufe sie wiederverwenden.
|
|
848
|
+
|
|
849
|
+
**F: Was machen `memory compact` / `memory score` / `memory propose-rules`?**
|
|
850
|
+
Siehe den Abschnitt [Memory-Schicht-Pflege](#memory-schicht-pflege-v200) oben. Kurzfassung: `compact` führt die 4-Stage-Policy aus (alte zusammenfassen, Duplikate mergen, Low-Importance-alt droppen, 400-Zeilen-Cap erzwingen); `score` ranked `failure-patterns.md` neu nach Importance (frequency × recency); `propose-rules` bringt Kandidaten für Rule-Ergänzungen aus wiederkehrenden Failures in `auto-rule-update.md` (nicht auto-angewendet — manuell prüfen und akzeptieren/ablehnen).
|
|
851
|
+
|
|
852
|
+
**F: Warum löscht `--force` (oder „fresh"-Resume-Modus) `.claude/rules/`?**
|
|
853
|
+
v2.0.0 hat drei Pass-3-Silent-Failure-Guards hinzugefügt (Guard 3 deckt zwei Incomplete-Output-Varianten ab: H2 für `guide/` und H1 für `standard/skills`). Guard 1 („partieller staged-rules-Move") und Guard 3 („unvollständiger Output — fehlende/leere Guide-Dateien oder fehlender Standard-Sentinel / leere Skills") hängen nicht von bestehenden Regeln ab, aber Guard 2 („null Rules erkannt") schon — er feuert, wenn Claude die `staging-override.md`-Direktive ignoriert und direkt nach `.claude/` schreiben wollte (wo Claude Codes Sensitive-Path-Policy das blockiert). Stale-Rules aus einem früheren Lauf würden Guard 2 false-negative machen — daher wipet `--force`/`fresh` `.claude/rules/`, um eine saubere Erkennung sicherzustellen. **Manuelle Edits an Rule-Dateien gehen verloren** bei `--force`/`fresh`; vorher sichern, wenn nötig. (Hinweis zu v2.1.0: Guard 3 H1 prüft `plan/` nicht mehr, da Master Plans nicht mehr generiert werden.)
|
|
854
|
+
|
|
855
|
+
**F: Was ist `claudeos-core/generated/.staged-rules/` und warum existiert es?**
|
|
856
|
+
Claude Codes Sensitive-Path-Policy verweigert direkte Schreibzugriffe auf `.claude/` aus dem `claude -p`-Subprozess (selbst mit `--dangerously-skip-permissions`). v2.0.0 umgeht das, indem Pass-3/4-Prompts alle `.claude/rules/`-Schreibvorgänge auf das Staging-Verzeichnis umleiten; der Node.js-Orchestrator (nicht dieser Policy unterworfen) verschiebt den Staging-Baum dann nach jedem Pass nach `.claude/rules/`. Das ist für den Benutzer transparent — das Verzeichnis wird auto-erstellt, auto-bereinigt und auto-verschoben. Wenn ein vorheriger Lauf mitten im Move crashte, wipet der nächste Lauf das Staging-Dir vor dem Retry. Im v2.1.0-Split-Mode verschiebt der Stage-Runner die staged-rules nach jeder Stage nach `.claude/rules/` (nicht erst am Ende), sodass ein Crash mitten in Pass 3 die bereits abgeschlossenen Stage-Rules an Ort und Stelle belässt.
|
|
857
|
+
|
|
858
|
+
**F: Kann ich Pass 3 manuell statt über `npx claudeos-core init` ausführen?**
|
|
859
|
+
Ja für kleine Projekte (≤5 Domains) — die Single-Call-Manual-Anweisungen in [Schritt 6](#schritt-6-pass-3--gesamte-dokumentation-generieren-aufgeteilt-in-mehrere-stages) funktionieren weiterhin. Für größere Projekte sollten Sie `npx claudeos-core init` verwenden, weil der Split-Runner die Stage-für-Stage-Ausführung mit frischen Contexts orchestriert, die Batch-Unterteilung ab 16 Domains übernimmt, die korrekte `pass3-complete.json`-Marker-Form (`mode: "split"` + `groupsCompleted`) schreibt und staged-rules zwischen Stages verschiebt. Diese Orchestrierung händisch nachzubauen ist möglich, aber mühsam. Wenn Sie einen Grund haben, Stages manuell auszuführen (z. B. Debugging einer bestimmten Stage), können Sie `pass3-prompt.md` mit der passenden `STAGE:`-Direktive templaten und direkt an `claude -p` füttern — denken Sie aber daran, `.staged-rules/` nach jeder Stage zu verschieben und den Marker selbst zu aktualisieren.
|
|
860
|
+
|
|
861
|
+
**F: Mein Projekt wird von v2.0.x upgegradet und hat ein bestehendes `claudeos-core/plan/`-Verzeichnis. Was soll ich tun?**
|
|
862
|
+
Nichts erforderlich — v2.1.0-Tools ignorieren `plan/`, wenn es fehlt oder leer ist, und `plan-validator` handhabt Legacy-Projekte mit gefüllten `plan/`-Verzeichnissen weiterhin aus Abwärtskompatibilitätsgründen. Sie können `claudeos-core/plan/` bedenkenlos löschen, wenn Sie die Master-Plan-Backups nicht brauchen (die Git-History ist ohnehin das bessere Backup). Wenn Sie `plan/` behalten, aktualisiert `npx claudeos-core init` es nicht — neue Inhalte werden in v2.1.0 nicht mehr in Master Plans aggregiert. Die Verifikations-Tools handhaben beide Fälle sauber.
|
|
863
|
+
|
|
864
|
+
---
|
|
865
|
+
|
|
866
|
+
## Template-Struktur
|
|
867
|
+
|
|
868
|
+
```
|
|
869
|
+
pass-prompts/templates/
|
|
870
|
+
├── common/ # Gemeinsamer Header/Footer + pass4 + staging-override
|
|
871
|
+
├── java-spring/ # Java / Spring Boot
|
|
872
|
+
├── kotlin-spring/ # Kotlin / Spring Boot (CQRS, BFF, multi-module)
|
|
873
|
+
├── node-express/ # Node.js / Express
|
|
874
|
+
├── node-nestjs/ # Node.js / NestJS (Module, DI, Guard, Pipe, Interceptor)
|
|
875
|
+
├── node-fastify/ # Node.js / Fastify
|
|
876
|
+
├── node-nextjs/ # Next.js / React (App Router, RSC)
|
|
877
|
+
├── node-vite/ # Vite SPA (React, client-side routing, VITE_ env, Vitest)
|
|
878
|
+
├── vue-nuxt/ # Vue / Nuxt (Composition API, Pinia, Nitro)
|
|
879
|
+
├── angular/ # Angular
|
|
880
|
+
├── python-django/ # Python / Django (DRF)
|
|
881
|
+
├── python-fastapi/ # Python / FastAPI
|
|
882
|
+
└── python-flask/ # Python / Flask (Blueprint, app factory, Jinja2)
|
|
883
|
+
```
|
|
884
|
+
|
|
885
|
+
`plan-installer` erkennt Ihren Stack/Ihre Stacks automatisch und setzt dann typ-spezifische Prompts zusammen. NestJS, Vue/Nuxt, Vite SPA und Flask verwenden jeweils dedizierte Templates mit framework-spezifischen Analyse-Kategorien (z. B. `@Module`/`@Injectable`/Guards für NestJS; `<script setup>`/Pinia/useFetch für Vue; Client-Side-Routing/`VITE_`-Env für Vite; Blueprint/`app.factory`/Flask-SQLAlchemy für Flask). Für Multi-Stack-Projekte werden separate `pass1-backend-prompt.md` und `pass1-frontend-prompt.md` generiert, während `pass3-prompt.md` die Generierungsziele beider Stacks kombiniert. In v2.1.0 wird dem Pass-3-Template `common/pass3-phase1.md` (der „Read Once, Extract Facts"-Block mit Rules A–E) vorangestellt, bevor es pro Split-Mode-Stage zugeschnitten wird. Pass 4 verwendet unabhängig vom Stack das gemeinsame `common/pass4.md`-Template (Memory-Scaffolding).
|
|
886
|
+
|
|
887
|
+
---
|
|
888
|
+
|
|
889
|
+
## Monorepo-Unterstützung
|
|
890
|
+
|
|
891
|
+
ClaudeOS-Core erkennt JS/TS-Monorepo-Setups automatisch und scannt Sub-Packages nach Abhängigkeiten.
|
|
892
|
+
|
|
893
|
+
**Unterstützte Monorepo-Marker** (auto-erkannt):
|
|
894
|
+
- `turbo.json` (Turborepo)
|
|
895
|
+
- `pnpm-workspace.yaml` (pnpm-Workspaces)
|
|
896
|
+
- `lerna.json` (Lerna)
|
|
897
|
+
- `package.json#workspaces` (npm-/yarn-Workspaces)
|
|
898
|
+
|
|
899
|
+
**Vom Monorepo-Root ausführen** — ClaudeOS-Core liest `apps/*/package.json` und `packages/*/package.json`, um Framework-/ORM-/DB-Abhängigkeiten über Sub-Packages hinweg zu entdecken:
|
|
900
|
+
|
|
901
|
+
```bash
|
|
902
|
+
cd my-monorepo
|
|
903
|
+
npx claudeos-core init
|
|
904
|
+
```
|
|
905
|
+
|
|
906
|
+
**Was erkannt wird:**
|
|
907
|
+
- Abhängigkeiten aus `apps/web/package.json` (z. B. `next`, `react`) → Frontend-Stack
|
|
908
|
+
- Abhängigkeiten aus `apps/api/package.json` (z. B. `express`, `prisma`) → Backend-Stack
|
|
909
|
+
- Abhängigkeiten aus `packages/db/package.json` (z. B. `drizzle-orm`) → ORM/DB
|
|
910
|
+
- Benutzerdefinierte Workspace-Pfade aus `pnpm-workspace.yaml` (z. B. `services/*`)
|
|
911
|
+
|
|
912
|
+
**Domain-Scanning deckt auch Monorepo-Layouts ab:**
|
|
913
|
+
- `apps/api/src/modules/*/` und `apps/api/src/*/` für Backend-Domains
|
|
914
|
+
- `apps/web/app/*/`, `apps/web/src/app/*/`, `apps/web/pages/*/` für Frontend-Domains
|
|
915
|
+
- `packages/*/src/*/` für Shared-Package-Domains
|
|
916
|
+
|
|
917
|
+
```
|
|
918
|
+
my-monorepo/ ← Hier ausführen: npx claudeos-core init
|
|
919
|
+
├── turbo.json ← Als Turborepo auto-erkannt
|
|
920
|
+
├── apps/
|
|
921
|
+
│ ├── web/ ← Next.js erkannt aus apps/web/package.json
|
|
922
|
+
│ │ ├── app/dashboard/ ← Frontend-Domain erkannt
|
|
923
|
+
│ │ └── package.json ← { "dependencies": { "next": "^14" } }
|
|
924
|
+
│ └── api/ ← Express erkannt aus apps/api/package.json
|
|
925
|
+
│ ├── src/modules/users/ ← Backend-Domain erkannt
|
|
926
|
+
│ └── package.json ← { "dependencies": { "express": "^4" } }
|
|
927
|
+
├── packages/
|
|
928
|
+
│ ├── db/ ← Drizzle erkannt aus packages/db/package.json
|
|
929
|
+
│ └── ui/
|
|
930
|
+
└── package.json ← { "workspaces": ["apps/*", "packages/*"] }
|
|
931
|
+
```
|
|
932
|
+
|
|
933
|
+
> **Hinweis:** Für Kotlin-/Java-Monorepos verwendet die Multi-Modul-Erkennung `settings.gradle.kts` (siehe [Kotlin-Multi-Modul-Erkennung](#kotlin-multi-modul-domain-erkennung) oben) und benötigt keine JS-Monorepo-Marker.
|
|
934
|
+
|
|
935
|
+
## Fehlerbehebung
|
|
936
|
+
|
|
937
|
+
**„claude: command not found"** — Claude Code CLI ist nicht installiert oder nicht im PATH. Siehe [Claude-Code-Docs](https://code.claude.com/docs/en/overview).
|
|
938
|
+
|
|
939
|
+
**„npm install failed"** — Node.js-Version ist möglicherweise zu niedrig. Erfordert v18+.
|
|
940
|
+
|
|
941
|
+
**„0 domains detected"** — Ihre Projektstruktur ist möglicherweise nicht-standardisiert. Siehe die Erkennungsmuster oben für Ihren Stack.
|
|
942
|
+
|
|
943
|
+
**„0 domains detected" bei einem Kotlin-Projekt** — Stellen Sie sicher, dass Ihr Projekt `build.gradle.kts` (oder `build.gradle` mit kotlin-Plugin) im Root hat und dass Quelldateien unter `**/src/main/kotlin/` liegen. Für Multi-Modul-Projekte stellen Sie sicher, dass `settings.gradle.kts` `include()`-Statements enthält. Single-Modul-Kotlin-Projekte (ohne `settings.gradle`) werden ebenfalls unterstützt — Domains werden aus der Package-/Class-Struktur unter `src/main/kotlin/` extrahiert.
|
|
944
|
+
|
|
945
|
+
**„Language detected as java instead of kotlin"** — ClaudeOS-Core prüft zuerst die Root-`build.gradle(.kts)`, dann Submodul-Build-Dateien. Wenn die Root-Build-Datei das `java`-Plugin ohne `kotlin` verwendet, aber Submodule Kotlin verwenden, prüft das Tool als Fallback bis zu 5 Submodul-Build-Dateien. Wenn immer noch nicht erkannt, stellen Sie sicher, dass mindestens ein `build.gradle.kts` `kotlin("jvm")` oder `org.jetbrains.kotlin` enthält.
|
|
946
|
+
|
|
947
|
+
**„CQRS not detected"** — Die Architektur-Erkennung verlässt sich auf Modulnamen, die `command`- und `query`-Keywords enthalten. Wenn Ihre Module andere Namen verwenden (z. B. `write-server`, `read-server`), wird die CQRS-Architektur nicht auto-erkannt. Sie können die generierten Prompts nach dem plan-installer-Lauf manuell anpassen.
|
|
948
|
+
|
|
949
|
+
**„Pass 3 produced 0 rule files under .claude/rules/" (v2.0.0)** — Guard 2 hat ausgelöst: Claude hat die `staging-override.md`-Direktive ignoriert und versucht, direkt nach `.claude/` zu schreiben, wo Claude Codes Sensitive-Path-Policy Schreibvorgänge blockiert. Erneut mit `npx claudeos-core init --force` ausführen. Wenn der Fehler weiterhin auftritt, inspizieren Sie `claudeos-core/generated/pass3-prompt.md`, um zu verifizieren, dass der `staging-override.md`-Block ganz oben steht.
|
|
950
|
+
|
|
951
|
+
**„Pass 3 finished but N rule file(s) could not be moved from staging" (v2.0.0)** — Guard 1 hat ausgelöst: Der Staging-Move hat einen transienten Datei-Lock getroffen (typischerweise Windows-Antivirus oder ein File-Watcher). Der Marker wird NICHT geschrieben, also wird der nächste `init`-Lauf Pass 3 automatisch erneut versuchen. Einfach `npx claudeos-core init` erneut ausführen.
|
|
952
|
+
|
|
953
|
+
**„Pass 3 produced CLAUDE.md and rules but N/9 guide files are missing or empty" (v2.0.0)** — Guard 3 (H2) hat ausgelöst: Claude hat mitten in der Antwort abgeschnitten, nachdem CLAUDE.md + Rules geschrieben waren, aber vor dem Beenden (oder Starten) des `claudeos-core/guide/`-Abschnitts (9 Dateien erwartet). Löst auch bei BOM-only- oder Whitespace-only-Dateien aus (Heading wurde geschrieben, aber der Body wurde abgeschnitten). Ohne diesen Guard würde der Completion-Marker trotzdem geschrieben, was `guide/` auf nachfolgenden Läufen dauerhaft leer lassen würde. Der Marker wird hier NICHT geschrieben, also wird der nächste `init`-Lauf Pass 3 mit denselben Pass-2-Ergebnissen erneut versuchen. Wenn es sich weiter wiederholt, mit `npx claudeos-core init --force` erneut ausführen, um von Grund auf neu zu generieren.
|
|
954
|
+
|
|
955
|
+
**„Pass 3 finished but the following required output(s) are missing or empty" (v2.0.0, aktualisiert v2.1.0)** — Guard 3 (H1) hat ausgelöst: Claude hat NACH `claudeos-core/guide/` abgeschnitten, aber vor (oder während) `claudeos-core/standard/` oder `claudeos-core/skills/`. Anforderungen: (a) `standard/00.core/01.project-overview.md` existiert und ist nicht leer (Sentinel, der vom Pass-3-Prompt jedes Stacks geschrieben wird), (b) `skills/` hat ≥1 nicht-leere `.md`. `database/` und `mcp-guide/` sind bewusst ausgeschlossen (einige Stacks produzieren legitim null Dateien). `plan/` wird ab v2.1.0 nicht mehr geprüft (Master Plans wurden entfernt). Gleicher Recovery-Pfad wie Guard 3 (H2): `init` erneut ausführen, oder `--force`, wenn es weiter auftritt.
|
|
956
|
+
|
|
957
|
+
**„Pass 3 split stage crashed partway through (v2.1.0)"** — Wenn eine der Split-Stages (z. B. `3b-1`, `3c-2`) mittendrin fehlschlägt, wird der Stage-Level-Marker NICHT geschrieben, aber abgeschlossene Stages SIND in `pass3-complete.json.groupsCompleted` festgehalten. Der nächste `init`-Lauf liest dieses Array und setzt ab der ersten nicht abgeschlossenen Stage fort und überspringt alle früher abgeschlossenen Arbeiten. Sie müssen nichts manuell tun — einfach `npx claudeos-core init` erneut ausführen. Wenn das Resume bei derselben Stage wiederholt fehlschlägt, inspizieren Sie `claudeos-core/generated/pass3-prompt.md` auf fehlerhaften Inhalt, und versuchen Sie dann `--force` für einen vollständigen Neustart. Die `pass3-complete.json`-Form (`mode: "split"`, `groupsCompleted: [...]`) ist stabil; ein fehlender oder fehlerhafter Marker führt dazu, dass das gesamte Pass 3 ab `3a` erneut läuft.
|
|
958
|
+
|
|
959
|
+
**„Pass 3 stale marker (shape mismatch) — treating as incomplete" (v2.1.0)** — Eine `pass3-complete.json` aus einem pre-v2.1.0-Single-Call-Lauf wird unter den neuen Split-Mode-Regeln interpretiert. Der Form-Check sucht nach `mode: "split"` und einem `groupsCompleted`-Array; fehlt eines von beiden, wird der Marker als partiell behandelt und Pass 3 läuft im Split-Mode erneut. Wenn Sie von v2.0.x upgegradet haben, ist das einmalig zu erwarten — der nächste Lauf schreibt die korrekte Marker-Form. Keine Aktion erforderlich.
|
|
960
|
+
|
|
961
|
+
**„pass2-merged.json exists but is malformed or incomplete (<5 top-level keys), re-running" (v2.0.0)** — Info-Log, kein Fehler. Beim Resume parsed und validiert `init` nun `pass2-merged.json` (≥5 Top-Level-Keys erforderlich, spiegelt den `INSUFFICIENT_KEYS`-Schwellenwert des `pass-json-validator`). Skelett-`{}` oder fehlerhaftes JSON aus einem vorherigen gecrashten Lauf wird automatisch gelöscht und Pass 2 läuft erneut. Keine manuelle Aktion nötig — die Pipeline heilt sich selbst. Wenn es weiter auftritt, `claudeos-core/generated/pass2-prompt.md` inspizieren und mit `--force` erneut versuchen.
|
|
962
|
+
|
|
963
|
+
**„Static fallback failed while translating to lang='ko'" (v2.0.0)** — Wenn `--lang` nicht-englisch ist, erfordern Pass 4 / statischer Fallback / Gap-Fill alle die `claude`-CLI zur Übersetzung. Wenn die Übersetzung fehlschlägt (CLI nicht authentifiziert, Netzwerk-Timeout oder strikte Validierung hat den Output abgelehnt: <40 % Länge, kaputte Code-Fences, verlorenes Frontmatter usw.), bricht der Lauf ab, anstatt still Englisch zu schreiben. Fix: Sicherstellen, dass `claude` authentifiziert ist, oder mit `--lang en` erneut ausführen, um die Übersetzung zu überspringen.
|
|
964
|
+
|
|
965
|
+
**„pass4-memory.json exists but memory/ is empty" (v2.0.0)** — Ein vorheriger Lauf hat den Marker geschrieben, aber der Benutzer (oder ein Cleanup-Skript) hat `claudeos-core/memory/` gelöscht. Die CLI erkennt diesen Stale-Marker automatisch und führt Pass 4 beim nächsten `init` erneut aus. Keine manuelle Aktion nötig.
|
|
966
|
+
|
|
967
|
+
**„pass4-memory.json exists but is malformed (missing passNum/memoryFiles) — re-running Pass 4" (v2.0.0)** — Info-Log, kein Fehler. Der Pass-4-Marker-Inhalt wird nun validiert (`passNum === 4` + nicht-leeres `memoryFiles`-Array), nicht nur seine Existenz. Ein teilweiser Claude-Fehler, der etwas wie `{"error":"timeout"}` als Marker-Body ausgibt, würde zuvor für immer als Erfolg akzeptiert; jetzt wird der Marker gelöscht und Pass 4 läuft automatisch erneut.
|
|
968
|
+
|
|
969
|
+
**„Could not delete stale pass3-complete.json / pass4-memory.json" InitError (v2.0.0)** — `init` hat einen Stale-Marker erkannt (Pass 3: CLAUDE.md wurde extern gelöscht; Pass 4: memory/ leer oder Marker-Body fehlerhaft) und versucht, ihn zu entfernen, aber der `unlinkSync`-Aufruf schlug fehl — typischerweise weil Windows-Antivirus oder ein File-Watcher (Editor, IDE-Indexer) das File-Handle hält. Zuvor wurde das still ignoriert, was die Pipeline dazu brachte, den Pass zu überspringen und den Stale-Marker wiederzuverwenden. Jetzt scheitert es laut. Fix: Editor/AV-Scanner schließen, der die Datei möglicherweise offen hält, dann `npx claudeos-core init` erneut ausführen.
|
|
970
|
+
|
|
971
|
+
**„CLAUDEOS_SKIP_TRANSLATION=1 is set but --lang='ko' requires translation" InitError (v2.0.0)** — Sie haben die Test-only-Env-Var `CLAUDEOS_SKIP_TRANSLATION=1` in Ihrer Shell gesetzt (wahrscheinlich ein Rest aus CI-/Test-Setup) UND eine nicht-englische `--lang` gewählt. Diese Env-Var short-circuit den Übersetzungs-Pfad, von dem Pass 4's statischer Fallback und Gap-Fill für nicht-englischen Output abhängen. `init` erkennt den Konflikt beim Sprachwahl-Zeitpunkt und bricht sofort ab (anstatt mitten in Pass 4 mit einem verwirrenden verschachtelten Fehler zu crashen). Fix: Entweder `unset CLAUDEOS_SKIP_TRANSLATION` vor dem Ausführen oder `npx claudeos-core init --lang en` verwenden.
|
|
972
|
+
|
|
973
|
+
---
|
|
974
|
+
|
|
975
|
+
## Mitwirken
|
|
976
|
+
|
|
977
|
+
Beiträge sind willkommen! Bereiche, in denen Hilfe am meisten benötigt wird:
|
|
978
|
+
|
|
979
|
+
- **Neue Stack-Templates** — Ruby/Rails, Go (Gin/Fiber/Echo), PHP (Laravel/Symfony), Rust (Axum/Actix), Svelte/SvelteKit, Remix
|
|
980
|
+
- **IDE-Integration** — VS-Code-Extension, IntelliJ-Plugin
|
|
981
|
+
- **CI/CD-Templates** — GitLab CI, CircleCI, Jenkins-Beispiele (GitHub Actions bereits ausgeliefert — siehe `.github/workflows/test.yml`)
|
|
982
|
+
- **Testabdeckung** — Erweiterung der Test-Suite (derzeit 563 Tests über 29 Test-Dateien, die Scanner, Stack-Erkennung, Domain-Grouping, Plan-Parsing, Prompt-Generierung, CLI-Selectors, Monorepo-Erkennung, Vite-SPA-Erkennung, Verifikations-Tools, L4-Memory-Scaffold, Pass-2-Resume-Validierung, Pass-3-Guards 1/2/3 (H1-Sentinel + H2-BOM-aware-Empty-File + strikter Stale-Marker-Unlink), Pass-3-Split-Mode-Batch-Unterteilung, Pass-3-Partial-Marker-Resume (v2.1.0), Pass-4-Marker-Content-Validierung + Stale-Marker-Unlink-Striktheit + scaffoldSkillsManifest-Gap-Fill (v2.1.0), Translation-Env-Skip-Guard + Early-Fail-Fast + CI-Workflow, staged-rules-Move, lang-aware-Translation-Fallback, Master-Plan-Removal-Regressions-Suite (v2.1.0), Memory-Score/Compact-Formatting-Regression (v2.1.0) und AI-Work-Rules-Template-Struktur abdecken)
|
|
983
|
+
|
|
984
|
+
Siehe [`CONTRIBUTING.md`](./CONTRIBUTING.md) für die vollständige Liste der Bereiche, den Code-Style, die Commit-Konvention und die Schritt-für-Schritt-Anleitung zum Hinzufügen eines neuen Stack-Templates.
|
|
985
|
+
|
|
986
|
+
---
|
|
987
|
+
|
|
988
|
+
## Autor
|
|
989
|
+
|
|
990
|
+
Erstellt von **claudeos-core** — [GitHub](https://github.com/claudeos-core) · [E-Mail](mailto:claudeoscore@gmail.com)
|
|
991
|
+
|
|
992
|
+
## Lizenz
|
|
993
|
+
|
|
994
|
+
ISC
|