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.fr.md
CHANGED
|
@@ -1,880 +1,993 @@
|
|
|
1
|
-
# ClaudeOS-Core
|
|
2
|
-
|
|
3
|
-
**Le seul outil qui lit d'abord votre code source, confirme votre stack et vos patterns par une analyse déterministe, puis génère des règles Claude Code adaptées exactement à votre projet.**
|
|
4
|
-
|
|
5
|
-
```bash
|
|
6
|
-
npx claudeos-core init
|
|
7
|
-
```
|
|
8
|
-
|
|
9
|
-
ClaudeOS-Core lit votre codebase, extrait chaque pattern qu'il y trouve et génère un ensemble complet de Standards, Rules, Skills et Guides adaptés à _votre_ projet. Ensuite, quand vous dites à Claude Code « Crée un CRUD pour les commandes », il produit du code qui correspond exactement à vos patterns existants.
|
|
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) · [🇩🇪 Deutsch](./README.de.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
|
-
### Détection des Domaines
|
|
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
|
-
Le
|
|
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
|
+
**Le seul outil qui lit d'abord votre code source, confirme votre stack et vos patterns par une analyse déterministe, puis génère des règles Claude Code adaptées exactement à votre projet.**
|
|
4
|
+
|
|
5
|
+
```bash
|
|
6
|
+
npx claudeos-core init
|
|
7
|
+
```
|
|
8
|
+
|
|
9
|
+
ClaudeOS-Core lit votre codebase, extrait chaque pattern qu'il y trouve et génère un ensemble complet de Standards, Rules, Skills et Guides adaptés à _votre_ projet. Ensuite, quand vous dites à Claude Code « Crée un CRUD pour les commandes », il produit du code qui correspond exactement à vos patterns existants.
|
|
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) · [🇩🇪 Deutsch](./README.de.md)
|
|
12
|
+
|
|
13
|
+
---
|
|
14
|
+
|
|
15
|
+
## Nouveautés de la v2.1.0
|
|
16
|
+
|
|
17
|
+
La v2.1.0 réarchitecture Pass 3 pour éliminer les échecs `Prompt is too long` sur les projets moyens à gros. Auparavant, un seul appel Pass 3 devait émettre tout l'arbre de documentation d'un coup — des dizaines de fichiers couvrant `CLAUDE.md`, les règles, les standards, les skills et les guides — et la sortie accumulée dépassait de façon fiable la fenêtre de contexte au-delà de ~5 domaines. La correction est structurelle, pas un simple ajustement de prompt :
|
|
18
|
+
|
|
19
|
+
- **Mode Pass 3 split** (toujours actif) — Pass 3 est découpé en appels `claude -p` séquentiels (`3a` → `3b-core` → `3b-N` → `3c-core` → `3c-N` → `3d-aux`). Chaque stage démarre avec une **fenêtre de contexte fraîche**, donc l'overflow par accumulation de sortie n'est structurellement plus possible, quelle que soit la taille du projet.
|
|
20
|
+
- **Fiche de faits entre stages** — Le stage `3a` lit l'analyse de Pass 2 une seule fois et la distille en un `pass3a-facts.md` de 5 à 10 Ko. Tous les stages suivants référencent cette fiche au lieu de relire le `pass2-merged.json` de 100 à 500 Ko, préservant la cohérence inter-fichiers à travers les contextes frais.
|
|
21
|
+
- **Sous-division en batches** (automatique à partir de 16 domaines) — Les stages 3b/3c sont en outre divisés en batches de 15 domaines, gardant chaque stage sous ~50 fichiers de sortie. Un admin frontend React 19 + Vite 6 de 18 domaines se termine en **102 minutes avec 101 fichiers générés sur 8 stages, zéro échec d'overflow** (exécution de production réelle, 2026-04-20).
|
|
22
|
+
- **Génération de master plan supprimée** — Les fichiers `claudeos-core/plan/*-master.md` ne sont plus générés. Les master plans étaient un backup interne que Claude Code ne consommait pas à l'exécution, et leur agrégation dans Pass 3d était l'un des principaux déclencheurs d'overflow. Utilisez `git` pour le backup/restore à la place.
|
|
23
|
+
- **Pass 4 gap-fill : `skills/00.shared/MANIFEST.md`** — Si Pass 3c omet le registre des skills (projets skill-sparse), Pass 4 crée désormais automatiquement un stub pour que `.claude/rules/50.sync/03.skills-sync.md` ne pointe jamais sur un fichier fantôme.
|
|
24
|
+
|
|
25
|
+
Quelques corrections plus petites : `memory --help` affiche maintenant l'aide des sous-commandes memory (auparavant, c'était l'aide top-level) ; `memory score` ne laisse plus de lignes `importance` dupliquées ; les marqueurs de résumé de `memory compact` sont de vrais items de liste markdown. Détails complets : [CHANGELOG.md](./CHANGELOG.md).
|
|
26
|
+
|
|
27
|
+
---
|
|
28
|
+
|
|
29
|
+
## Pourquoi ClaudeOS-Core ?
|
|
30
|
+
|
|
31
|
+
Tous les autres outils Claude Code fonctionnent ainsi :
|
|
32
|
+
|
|
33
|
+
> **Un humain décrit le projet → le LLM génère la documentation**
|
|
34
|
+
|
|
35
|
+
ClaudeOS-Core fonctionne ainsi :
|
|
36
|
+
|
|
37
|
+
> **Le code analyse vos sources → le code construit un prompt sur mesure → le LLM génère la documentation → le code vérifie la sortie**
|
|
38
|
+
|
|
39
|
+
Ce n'est pas une petite différence. Voici pourquoi c'est important :
|
|
40
|
+
|
|
41
|
+
### Le problème fondamental : les LLMs devinent. Le code, non.
|
|
42
|
+
|
|
43
|
+
Quand vous demandez à Claude d'« analyser ce projet », il **devine** votre stack, votre ORM, votre structure de domaines.
|
|
44
|
+
Il peut voir `spring-boot` dans votre `build.gradle` mais ne pas réaliser que vous utilisez MyBatis (et non JPA).
|
|
45
|
+
Il peut détecter un répertoire `user/` sans comprendre que votre projet utilise le packaging layer-first (Pattern A), pas domain-first (Pattern B).
|
|
46
|
+
|
|
47
|
+
**ClaudeOS-Core ne devine pas.** Avant même que Claude ne voie votre projet, le code Node.js a déjà :
|
|
48
|
+
|
|
49
|
+
- Parsé `build.gradle` / `package.json` / `pyproject.toml` et **confirmé** votre stack, ORM, BD et gestionnaire de paquets
|
|
50
|
+
- Scanné votre structure de répertoires et **confirmé** votre liste de domaines avec le nombre de fichiers
|
|
51
|
+
- Classifié la structure de votre projet selon l'un des 5 patterns Java, Kotlin CQRS/BFF, ou Next.js App Router/FSD
|
|
52
|
+
- Divisé les domaines en groupes de taille optimale qui rentrent dans la fenêtre de contexte de Claude
|
|
53
|
+
- Assemblé un prompt spécifique au stack avec tous les faits confirmés injectés
|
|
54
|
+
|
|
55
|
+
Au moment où Claude reçoit le prompt, il n'y a plus rien à deviner. Le stack est confirmé. Les domaines sont confirmés. Le pattern structurel est confirmé. Le seul travail de Claude est de générer une documentation qui correspond à ces **faits confirmés**.
|
|
56
|
+
|
|
57
|
+
### Le résultat
|
|
58
|
+
|
|
59
|
+
Les autres outils produisent une documentation « globalement correcte ».
|
|
60
|
+
ClaudeOS-Core produit une documentation qui sait que votre projet utilise `ApiResponse.ok()` (pas `ResponseEntity.success()`), que vos mappers MyBatis XML vivent dans `src/main/resources/mybatis/mappers/`, et que votre structure de packages est `com.company.module.{domain}.controller` — parce qu'il a lu votre code réel.
|
|
61
|
+
|
|
62
|
+
### Avant et après
|
|
63
|
+
|
|
64
|
+
**Sans ClaudeOS-Core** — vous demandez à Claude Code de créer un CRUD Order :
|
|
65
|
+
```
|
|
66
|
+
❌ Utilise un repository style JPA (votre projet utilise MyBatis)
|
|
67
|
+
❌ Crée ResponseEntity.success() (votre wrapper est ApiResponse.ok())
|
|
68
|
+
❌ Place les fichiers dans order/controller/ (votre projet utilise controller/order/)
|
|
69
|
+
❌ Génère des commentaires en anglais (votre équipe écrit des commentaires en français)
|
|
70
|
+
→ Vous passez 20 minutes à corriger chaque fichier généré
|
|
71
|
+
```
|
|
72
|
+
|
|
73
|
+
**Avec ClaudeOS-Core** — `.claude/rules/` contient déjà vos patterns confirmés :
|
|
74
|
+
```
|
|
75
|
+
✅ Génère un mapper MyBatis + XML (détecté depuis build.gradle)
|
|
76
|
+
✅ Utilise ApiResponse.ok() (extrait de votre vraie source)
|
|
77
|
+
✅ Place les fichiers dans controller/order/ (Pattern A confirmé par le scan structurel)
|
|
78
|
+
✅ Commentaires en français (--lang fr appliqué)
|
|
79
|
+
→ Le code généré correspond immédiatement aux conventions de votre projet
|
|
80
|
+
```
|
|
81
|
+
|
|
82
|
+
Cette différence se cumule. 10 tâches/jour × 20 minutes économisées = **plus de 3 heures/jour**.
|
|
83
|
+
|
|
84
|
+
---
|
|
85
|
+
|
|
86
|
+
## Stacks Supportés
|
|
87
|
+
|
|
88
|
+
| Stack | Détection | Profondeur d'analyse |
|
|
89
|
+
|---|---|---|
|
|
90
|
+
| **Java / Spring Boot** | `build.gradle`, `pom.xml`, 5 patterns de package | 10 catégories, 59 sous-éléments |
|
|
91
|
+
| **Kotlin / Spring Boot** | `build.gradle.kts`, kotlin plugin, `settings.gradle.kts`, auto-détection CQRS/BFF | 12 catégories, 95 sous-éléments |
|
|
92
|
+
| **Node.js / Express** | `package.json` | 9 catégories, 57 sous-éléments |
|
|
93
|
+
| **Node.js / NestJS** | `package.json` (`@nestjs/core`) | 10 catégories, 68 sous-éléments |
|
|
94
|
+
| **Next.js / React** | `package.json`, `next.config.*`, support FSD | 9 catégories, 55 sous-éléments |
|
|
95
|
+
| **Vue / Nuxt** | `package.json`, `nuxt.config.*`, Composition API | 9 catégories, 58 sous-éléments |
|
|
96
|
+
| **Python / Django** | `requirements.txt`, `pyproject.toml` | 10 catégories, 55 sous-éléments |
|
|
97
|
+
| **Python / FastAPI** | `requirements.txt`, `pyproject.toml` | 10 catégories, 58 sous-éléments |
|
|
98
|
+
| **Node.js / Fastify** | `package.json` | 10 catégories, 62 sous-éléments |
|
|
99
|
+
| **Vite / React SPA** | `package.json`, `vite.config.*` | 9 catégories, 55 sous-éléments |
|
|
100
|
+
| **Angular** | `package.json`, `angular.json` | 12 catégories, 78 sous-éléments |
|
|
101
|
+
|
|
102
|
+
Auto-détecté : langage et version, framework et version (y compris Vite en tant que framework SPA), ORM (MyBatis, JPA, Exposed, Prisma, TypeORM, SQLAlchemy, etc.), base de données (PostgreSQL, MySQL, Oracle, MongoDB, SQLite), gestionnaire de paquets (Gradle, Maven, npm, yarn, pnpm, pip, poetry), architecture (CQRS, BFF — à partir des noms de modules), structure multi-module (depuis settings.gradle), monorepo (Turborepo, pnpm-workspace, Lerna, npm/yarn workspaces).
|
|
103
|
+
|
|
104
|
+
**Vous n'avez rien à spécifier. Tout est détecté automatiquement.**
|
|
105
|
+
|
|
106
|
+
### Détection des Domaines Java (5 patterns avec fallback)
|
|
107
|
+
|
|
108
|
+
| Priorité | Pattern | Structure | Exemple |
|
|
109
|
+
|---|---|---|---|
|
|
110
|
+
| A | Layer d'abord | `controller/{domain}/` | `controller/user/UserController.java` |
|
|
111
|
+
| B | Domaine d'abord | `{domain}/controller/` | `user/controller/UserController.java` |
|
|
112
|
+
| D | Préfixe de module | `{module}/{domain}/controller/` | `front/member/controller/MemberController.java` |
|
|
113
|
+
| E | DDD/Hexagonal | `{domain}/adapter/in/web/` | `user/adapter/in/web/UserController.java` |
|
|
114
|
+
| C | Plat | `controller/*.java` | `controller/UserController.java` → extrait `user` du nom de classe |
|
|
115
|
+
|
|
116
|
+
Les domaines uniquement service (sans contrôleurs) sont également détectés via les répertoires `service/`, `dao/`, `aggregator/`, `facade/`, `usecase/`, `orchestrator/`, `mapper/`, `repository/`. Ignorés : `common`, `config`, `util`, `core`, `front`, `admin`, `v1`, `v2`, etc.
|
|
117
|
+
|
|
118
|
+
### Détection des Domaines Kotlin Multi-Module
|
|
119
|
+
|
|
120
|
+
Pour les projets Kotlin avec structure Gradle multi-module (ex : monorepo CQRS) :
|
|
121
|
+
|
|
122
|
+
| Étape | Ce que fait l'outil | Exemple |
|
|
123
|
+
|---|---|---|
|
|
124
|
+
| 1 | Scanne `settings.gradle.kts` pour trouver les `include()` | Trouve 14 modules |
|
|
125
|
+
| 2 | Détecte le type de module depuis le nom | `reservation-command-server` → type : `command` |
|
|
126
|
+
| 3 | Extrait le domaine du nom de module | `reservation-command-server` → domaine : `reservation` |
|
|
127
|
+
| 4 | Regroupe le même domaine à travers les modules | `reservation-command-server` + `common-query-server` → 1 domaine |
|
|
128
|
+
| 5 | Détecte l'architecture | Contient modules `command` + `query` → CQRS |
|
|
129
|
+
|
|
130
|
+
Types de module supportés : `command`, `query`, `bff`, `integration`, `standalone`, `library`. Les bibliothèques partagées (`shared-lib`, `integration-lib`) sont détectées comme domaines spéciaux.
|
|
131
|
+
|
|
132
|
+
### Détection des Domaines Frontend
|
|
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
|
+
- **Split RSC/Client** : Détecte le pattern `client.tsx`, suit la séparation Server/Client des composants
|
|
138
|
+
- **Chemins imbriqués non standards** : Détecte pages, components et couches FSD sous les chemins `src/*/` (ex : `src/admin/pages/dashboard/`, `src/admin/components/form/`, `src/admin/features/billing/`)
|
|
139
|
+
- **Détection platform/tier-split (v2.0.0)** : Reconnaît les layouts `src/{platform}/{subapp}/` — `{platform}` peut être un mot-clé de device/cible (`desktop`, `pc`, `web`, `mobile`, `mc`, `mo`, `sp`, `tablet`, `tab`, `pwa`, `tv`, `ctv`, `ott`, `watch`, `wear`) ou un mot-clé de niveau d'accès (`admin`, `cms`, `backoffice`, `back-office`, `portal`). Émet un domaine par paire `(platform, subapp)` nommé `{platform}-{subapp}` avec des compteurs par domaine pour routes/components/layouts/hooks. Tourne simultanément sur Angular, Next.js, React et Vue (glob multi-extensions `{tsx,jsx,ts,js,vue}`). Nécessite ≥2 fichiers source par subapp pour éviter des domaines bruyants à 1 seul fichier.
|
|
140
|
+
- **Split plateforme en monorepo (v2.0.0)** : Le scan de plateforme matche aussi `{apps,packages}/*/src/{platform}/{subapp}/` (Turborepo/pnpm workspace avec `src/`) et `{apps,packages}/{platform}/{subapp}/` (workspaces sans wrapper `src/`).
|
|
141
|
+
- **Fallback E — fichier de routes (v2.0.0)** : Quand les scanners primaires + Fallbacks A–D renvoient tous 0, glob `**/routes/*.{tsx,jsx,ts,js,vue}` et regroupe par le nom du répertoire parent de `routes`. Capture les projets à routage par fichiers React Router (CRA/Vite + `react-router`) qui ne matchent ni `page.tsx` de Next.js ni les layouts FSD. Les noms de parent génériques (`src`, `app`, `pages`) sont filtrés.
|
|
142
|
+
- **Fallback de config** : Détecte Next.js/Vite/Nuxt depuis les fichiers de config quand ils ne sont pas dans `package.json` (support monorepo)
|
|
143
|
+
- **Fallback répertoire profond** : Pour les projets React/CRA/Vite/Vue/RN, scanne `**/components/*/`, `**/views/*/`, `**/screens/*/`, `**/containers/*/`, `**/pages/*/`, `**/routes/*/`, `**/modules/*/`, `**/domains/*/` à n'importe quelle profondeur
|
|
144
|
+
- **Listes d'ignore partagées (v2.0.0)** : Tous les scanners partagent `BUILD_IGNORE_DIRS` (`node_modules`, `build`, `dist`, `out`, `.next`, `.nuxt`, `.svelte-kit`, `.angular`, `.turbo`, `.cache`, `.parcel-cache`, `coverage`, `storybook-static`, `.vercel`, `.netlify`) et `TEST_FILE_IGNORE` (spec/test/stories/e2e/cy + `__snapshots__`/`__tests__`) pour que les sorties de build et les fixtures de test ne gonflent pas les compteurs par domaine.
|
|
145
|
+
|
|
146
|
+
### Overrides de scanner (v2.0.0)
|
|
147
|
+
|
|
148
|
+
Déposez un `.claudeos-scan.json` optionnel à la racine de votre projet pour étendre les valeurs par défaut du scanner sans modifier le toolkit. Tous les champs sont **additifs** — les entrées utilisateur étendent les valeurs par défaut, ne les remplacent jamais :
|
|
149
|
+
|
|
150
|
+
```json
|
|
151
|
+
{
|
|
152
|
+
"frontendScan": {
|
|
153
|
+
"platformKeywords": ["kiosk"],
|
|
154
|
+
"skipSubappNames": ["legacy"],
|
|
155
|
+
"minSubappFiles": 3
|
|
156
|
+
}
|
|
157
|
+
}
|
|
158
|
+
```
|
|
159
|
+
|
|
160
|
+
| Champ | Par défaut | But |
|
|
161
|
+
|---|---|---|
|
|
162
|
+
| `platformKeywords` | liste intégrée ci-dessus | Mots-clés `{platform}` supplémentaires pour le scan de plateforme (ex : `kiosk`, `vr`, `embedded`) |
|
|
163
|
+
| `skipSubappNames` | répertoires structurels uniquement | Noms de subapp supplémentaires à exclure de l'émission de domaines du scan de plateforme |
|
|
164
|
+
| `minSubappFiles` | `2` | Remplace le nombre minimum de fichiers requis avant qu'un subapp ne devienne un domaine |
|
|
165
|
+
|
|
166
|
+
Fichier manquant ou JSON mal formé → retombe silencieusement aux valeurs par défaut (pas de crash). Usage typique : activer une abréviation courte (`adm`, `bo`) que la liste intégrée exclut comme trop ambiguë, ou augmenter `minSubappFiles` pour des monorepos bruyants.
|
|
167
|
+
|
|
168
|
+
---
|
|
169
|
+
|
|
170
|
+
## Démarrage Rapide
|
|
171
|
+
|
|
172
|
+
### Prérequis
|
|
173
|
+
|
|
174
|
+
- **Node.js** v18+
|
|
175
|
+
- **CLI Claude Code** (installée et authentifiée)
|
|
176
|
+
|
|
177
|
+
### Installation
|
|
178
|
+
|
|
179
|
+
```bash
|
|
180
|
+
cd /your/project/root
|
|
181
|
+
|
|
182
|
+
# Option A : npx (recommandé — pas d'installation nécessaire)
|
|
183
|
+
npx claudeos-core init
|
|
184
|
+
|
|
185
|
+
# Option B : installation globale
|
|
186
|
+
npm install -g claudeos-core
|
|
187
|
+
claudeos-core init
|
|
188
|
+
|
|
189
|
+
# Option C : devDependency du projet
|
|
190
|
+
npm install --save-dev claudeos-core
|
|
191
|
+
npx claudeos-core init
|
|
192
|
+
|
|
193
|
+
# Option D : git clone (pour développement/contribution)
|
|
194
|
+
git clone https://github.com/claudeos-core/claudeos-core.git claudeos-core-tools
|
|
195
|
+
|
|
196
|
+
# Cross-plateforme (PowerShell, CMD, Bash, Zsh — n'importe quel terminal)
|
|
197
|
+
node claudeos-core-tools/bin/cli.js init
|
|
198
|
+
|
|
199
|
+
# Linux/macOS (Bash uniquement)
|
|
200
|
+
bash claudeos-core-tools/bootstrap.sh
|
|
201
|
+
```
|
|
202
|
+
|
|
203
|
+
### Langue de sortie (10 langues)
|
|
204
|
+
|
|
205
|
+
Quand vous lancez `init` sans `--lang`, un sélecteur interactif apparaît — utilisez les flèches ou les touches numériques pour choisir :
|
|
206
|
+
|
|
207
|
+
```
|
|
208
|
+
╔══════════════════════════════════════════════════╗
|
|
209
|
+
║ Select generated document language (required) ║
|
|
210
|
+
╚══════════════════════════════════════════════════╝
|
|
211
|
+
|
|
212
|
+
Les fichiers générés (CLAUDE.md, Standards, Rules,
|
|
213
|
+
Skills, Guides) seront écrits en français.
|
|
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
|
+
↑↓ Move 1-0 Jump Enter Select ESC Cancel
|
|
227
|
+
```
|
|
228
|
+
|
|
229
|
+
La description change vers la langue sélectionnée au fur et à mesure que vous naviguez. Pour sauter le sélecteur, passez directement `--lang` :
|
|
230
|
+
|
|
231
|
+
```bash
|
|
232
|
+
npx claudeos-core init --lang ko # Coréen
|
|
233
|
+
npx claudeos-core init --lang ja # Japonais
|
|
234
|
+
npx claudeos-core init --lang en # Anglais (par défaut)
|
|
235
|
+
```
|
|
236
|
+
|
|
237
|
+
> **Remarque :** Cela définit la langue uniquement pour les fichiers de documentation générés. L'analyse du code (Pass 1–2) tourne toujours en anglais ; la sortie générée (Pass 3) est écrite dans la langue choisie. Les exemples de code à l'intérieur des fichiers générés gardent la syntaxe de leur langage de programmation d'origine.
|
|
238
|
+
|
|
239
|
+
C'est tout. Après 10 minutes (petit projet) à 2 heures (monorepo de 60+ domaines), toute la documentation est générée et prête à l'emploi. La CLI affiche une barre de progression avec pourcentage, temps écoulé et ETA pour chaque pass. Voir [Auto-scaling selon la Taille du Projet](#auto-scaling-selon-la-taille-du-projet) pour des timings détaillés par taille de projet.
|
|
240
|
+
|
|
241
|
+
### Installation Manuelle Pas à Pas
|
|
242
|
+
|
|
243
|
+
Si vous voulez un contrôle total sur chaque phase — ou si le pipeline automatisé échoue à une étape — vous pouvez exécuter chaque étape manuellement. Cela sert également à comprendre le fonctionnement interne de ClaudeOS-Core.
|
|
244
|
+
|
|
245
|
+
#### Étape 1 : Cloner et installer les dépendances
|
|
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
|
+
#### Étape 2 : Créer la structure de répertoires
|
|
255
|
+
|
|
256
|
+
```bash
|
|
257
|
+
# Rules (v2.0.0 : ajout de 60.memory)
|
|
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 : ajout de memory ; v2.1.0 : suppression de plan)
|
|
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
|
+
> **Remarque v2.1.0 :** Le répertoire `claudeos-core/plan/` n'est plus créé. La génération de master plan a été supprimée parce que les master plans étaient un backup interne que Claude Code ne lisait jamais à l'exécution, et leur agrégation déclenchait des échecs `Prompt is too long`. Utilisez `git` pour le backup/restore.
|
|
272
|
+
|
|
273
|
+
#### Étape 3 : Lancer plan-installer (analyse du projet)
|
|
274
|
+
|
|
275
|
+
Cela scanne votre projet, détecte le stack, trouve les domaines, les divise en groupes et génère les prompts.
|
|
276
|
+
|
|
277
|
+
```bash
|
|
278
|
+
node claudeos-core-tools/plan-installer/index.js
|
|
279
|
+
```
|
|
280
|
+
|
|
281
|
+
**Sortie (dans `claudeos-core/generated/`) :**
|
|
282
|
+
- `project-analysis.json` — stack détecté, domaines, info frontend
|
|
283
|
+
- `domain-groups.json` — groupes de domaines pour Pass 1
|
|
284
|
+
- `pass1-backend-prompt.md` / `pass1-frontend-prompt.md` — prompts d'analyse
|
|
285
|
+
- `pass2-prompt.md` — prompt de merge
|
|
286
|
+
- `pass3-prompt.md` — template de prompt Pass 3 avec le bloc Phase 1 « Read Once, Extract Facts » préfixé (Règles A–E). Le pipeline automatisé découpe Pass 3 en plusieurs stages à l'exécution ; ce template alimente chaque stage.
|
|
287
|
+
- `pass3-context.json` — résumé projet allégé (< 5 Ko, construit après Pass 2) que les prompts Pass 3 préfèrent au `pass2-merged.json` complet (v2.1.0)
|
|
288
|
+
- `pass4-prompt.md` — prompt de scaffolding memory L4 (v2.0.0 ; utilise le même `staging-override.md` pour les écritures de règles `60.memory/`)
|
|
289
|
+
|
|
290
|
+
Vous pouvez inspecter ces fichiers pour vérifier la précision de détection avant de continuer.
|
|
291
|
+
|
|
292
|
+
#### Étape 4 : Pass 1 — Analyse profonde du code (par groupe de domaines)
|
|
293
|
+
|
|
294
|
+
Lancez Pass 1 pour chaque groupe de domaines. Consultez `domain-groups.json` pour connaître le nombre de groupes.
|
|
295
|
+
|
|
296
|
+
```bash
|
|
297
|
+
# Vérifier combien de groupes
|
|
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
|
+
# Lancer Pass 1 pour chaque groupe (remplacer les domaines et le numéro de groupe)
|
|
304
|
+
# Note : v1.6.1+ utilise String.replace() de Node.js au lieu de perl — perl n'est
|
|
305
|
+
# plus nécessaire, et la sémantique de fonction de remplacement empêche l'injection
|
|
306
|
+
# regex des caractères $/&/$1 susceptibles d'apparaître dans les noms de domaine.
|
|
307
|
+
#
|
|
308
|
+
# Pour le groupe 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
|
+
# Pour le groupe 2 (si présent) :
|
|
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
|
+
# Pour les groupes frontend, remplacez pass1-backend-prompt.md → pass1-frontend-prompt.md
|
|
329
|
+
```
|
|
330
|
+
|
|
331
|
+
**Vérifier :** `ls claudeos-core/generated/pass1-*.json` devrait afficher un JSON par groupe.
|
|
332
|
+
|
|
333
|
+
#### Étape 5 : Pass 2 — Merger les résultats d'analyse
|
|
334
|
+
|
|
335
|
+
```bash
|
|
336
|
+
cat claudeos-core/generated/pass2-prompt.md \
|
|
337
|
+
| claude -p --dangerously-skip-permissions
|
|
338
|
+
```
|
|
339
|
+
|
|
340
|
+
**Vérifier :** `claudeos-core/generated/pass2-merged.json` doit exister avec 9+ clés de niveau supérieur.
|
|
341
|
+
|
|
342
|
+
#### Étape 6 : Pass 3 — Générer toute la documentation (divisée en plusieurs stages)
|
|
343
|
+
|
|
344
|
+
**Remarque v2.1.0 :** Pass 3 est **toujours exécuté en mode split** par le pipeline automatisé. Chaque stage est un appel `claude -p` séparé avec une fenêtre de contexte fraîche, donc l'overflow par accumulation de sortie est structurellement impossible quelle que soit la taille du projet. Le template `pass3-prompt.md` est assemblé par stage avec une directive `STAGE:` qui indique à Claude quel sous-ensemble de fichiers émettre. En mode manuel, le chemin le plus simple reste d'alimenter le template complet et de laisser Claude tout générer en un seul appel — mais cela n'est fiable que sur les petits projets (≤5 domaines). Pour toute taille supérieure, utilisez `npx claudeos-core init` pour que le runner split s'occupe de l'orchestration des stages.
|
|
345
|
+
|
|
346
|
+
**Mode appel unique (petits projets uniquement, ≤5 domaines) :**
|
|
347
|
+
|
|
348
|
+
```bash
|
|
349
|
+
cat claudeos-core/generated/pass3-prompt.md \
|
|
350
|
+
| claude -p --dangerously-skip-permissions
|
|
351
|
+
```
|
|
352
|
+
|
|
353
|
+
**Mode stage par stage (recommandé pour toutes les tailles de projet) :**
|
|
354
|
+
|
|
355
|
+
Le pipeline automatisé exécute ces stages. La liste des stages est :
|
|
356
|
+
|
|
357
|
+
| Stage | Écrit | Notes |
|
|
358
|
+
|---|---|---|
|
|
359
|
+
| `3a` | `pass3a-facts.md` (fiche de faits distillée 5–10 Ko) | Lit `pass2-merged.json` une seule fois ; les stages suivants référencent ce fichier |
|
|
360
|
+
| `3b-core` | `CLAUDE.md`, `standard/` communs, `.claude/rules/` communs | Fichiers inter-projet ; pas de sortie spécifique à un domaine |
|
|
361
|
+
| `3b-1..N` | `standard/60.domains/*.md` spécifiques aux domaines + règles de domaine | Batch de ≤15 domaines par stage (auto-divisé à partir de 16 domaines) |
|
|
362
|
+
| `3c-core` | `guide/` (9 fichiers), `skills/00.shared/MANIFEST.md`, orchestrateurs `skills/*/` | Skills partagés et tous les guides destinés à l'utilisateur |
|
|
363
|
+
| `3c-1..N` | Sous-skills de domaine sous `skills/20.frontend-page/scaffold-page-feature/` | Batch de ≤15 domaines par stage |
|
|
364
|
+
| `3d-aux` | `database/`, `mcp-guide/` | Taille fixe, indépendante du nombre de domaines |
|
|
365
|
+
|
|
366
|
+
Pour un projet de 1 à 15 domaines, cela se développe en 4 stages (`3a`, `3b-core`, `3c-core`, `3d-aux` — pas de sous-division en batches). Pour 16 à 30 domaines, 8 stages (`3b` et `3c` chacun sous-divisés en 2 batches). Voir [Auto-scaling selon la Taille du Projet](#auto-scaling-selon-la-taille-du-projet) pour le tableau complet.
|
|
367
|
+
|
|
368
|
+
**Vérifier :** `CLAUDE.md` doit exister à la racine de votre projet, et le marqueur `claudeos-core/generated/pass3-complete.json` doit être écrit. En mode split, le marqueur contient `mode: "split"` et un array `groupsCompleted` listant chaque stage terminé — la logique de marqueur partiel s'en sert pour reprendre au bon stage après un crash plutôt que de redémarrer depuis `3a` (qui doublerait le coût en tokens).
|
|
369
|
+
|
|
370
|
+
> **Remarque staging :** Pass 3 écrit les fichiers de règles d'abord dans `claudeos-core/generated/.staged-rules/` car la politique de chemins sensibles de Claude Code bloque les écritures directes dans `.claude/`. Le pipeline automatisé gère le déplacement automatiquement après chaque stage. Si vous exécutez un stage manuellement, vous devrez déplacer l'arbre staged vous-même : `mv claudeos-core/generated/.staged-rules/* .claude/rules/` (en préservant les sous-chemins).
|
|
371
|
+
|
|
372
|
+
#### Étape 7 : Pass 4 — Scaffolding memory
|
|
373
|
+
|
|
374
|
+
```bash
|
|
375
|
+
cat claudeos-core/generated/pass4-prompt.md \
|
|
376
|
+
| claude -p --dangerously-skip-permissions
|
|
377
|
+
```
|
|
378
|
+
|
|
379
|
+
**Vérifier :** `claudeos-core/memory/` doit contenir 4 fichiers (`decision-log.md`, `failure-patterns.md`, `compaction.md`, `auto-rule-update.md`), `.claude/rules/60.memory/` doit contenir 4 fichiers de règles, et `CLAUDE.md` doit désormais avoir une section `## Memory (L4)` ajoutée. Marqueur : `claudeos-core/generated/pass4-memory.json`.
|
|
380
|
+
|
|
381
|
+
> **Gap-fill v2.1.0 :** Pass 4 garantit aussi que `claudeos-core/skills/00.shared/MANIFEST.md` existe. Si Pass 3c l'a omis (possible sur les projets skill-sparse car les templates `pass3.md` par stack listent `MANIFEST.md` parmi les cibles de génération sans le marquer REQUIRED), le gap-fill crée un stub minimal pour que `.claude/rules/50.sync/03.skills-sync.md` ait toujours une cible de référence valide. Idempotent : saute si le fichier a déjà du contenu réel (>20 caractères).
|
|
382
|
+
|
|
383
|
+
> **Remarque :** Si `claude -p` échoue ou si `pass4-prompt.md` est absent, le pipeline automatisé retombe sur un scaffold statique via `lib/memory-scaffold.js` (avec traduction pilotée par Claude quand `--lang` n'est pas l'anglais). Le fallback statique ne tourne qu'à l'intérieur de `npx claudeos-core init` — le mode manuel exige que Pass 4 réussisse.
|
|
384
|
+
|
|
385
|
+
#### Étape 8 : Lancer les outils de vérification
|
|
386
|
+
|
|
387
|
+
```bash
|
|
388
|
+
# Générer les métadonnées (requis avant les autres vérifications)
|
|
389
|
+
node claudeos-core-tools/manifest-generator/index.js
|
|
390
|
+
|
|
391
|
+
# Lancer toutes les vérifications
|
|
392
|
+
node claudeos-core-tools/health-checker/index.js
|
|
393
|
+
|
|
394
|
+
# Ou lancer des vérifications individuelles :
|
|
395
|
+
node claudeos-core-tools/plan-validator/index.js --check # Cohérence Plan ↔ disque
|
|
396
|
+
node claudeos-core-tools/sync-checker/index.js # Fichiers non enregistrés/orphelins
|
|
397
|
+
node claudeos-core-tools/content-validator/index.js # Vérifications qualité (incl. section memory/ [9/9])
|
|
398
|
+
node claudeos-core-tools/pass-json-validator/index.js # Vérifications JSON Pass 1–4 + marqueur de complétion
|
|
399
|
+
```
|
|
400
|
+
|
|
401
|
+
#### Étape 9 : Vérifier les résultats
|
|
402
|
+
|
|
403
|
+
```bash
|
|
404
|
+
# Compter les fichiers générés
|
|
405
|
+
find .claude claudeos-core -type f | grep -v node_modules | grep -v '/generated/' | wc -l
|
|
406
|
+
|
|
407
|
+
# Regarder CLAUDE.md
|
|
408
|
+
head -30 CLAUDE.md
|
|
409
|
+
|
|
410
|
+
# Regarder un fichier standard
|
|
411
|
+
cat claudeos-core/standard/00.core/01.project-overview.md | head -20
|
|
412
|
+
|
|
413
|
+
# Regarder les règles
|
|
414
|
+
ls .claude/rules/*/
|
|
415
|
+
```
|
|
416
|
+
|
|
417
|
+
> **Astuce :** Si une étape échoue, vous pouvez corriger le problème et relancer uniquement cette étape. Les résultats de Pass 1/2 sont cachés — si `pass1-N.json` ou `pass2-merged.json` existe déjà, le pipeline automatisé les saute. Utilisez `npx claudeos-core init --force` pour supprimer les résultats précédents et repartir de zéro.
|
|
418
|
+
|
|
419
|
+
### Commencer à Utiliser
|
|
420
|
+
|
|
421
|
+
```
|
|
422
|
+
# Dans Claude Code — demandez simplement naturellement :
|
|
423
|
+
« Crée un CRUD pour le domaine order »
|
|
424
|
+
« Ajoute une API d'authentification utilisateur »
|
|
425
|
+
« Refactorise ce code pour qu'il matche les patterns du projet »
|
|
426
|
+
|
|
427
|
+
# Claude Code référence automatiquement vos Standards, Rules et Skills générés.
|
|
428
|
+
```
|
|
429
|
+
|
|
430
|
+
---
|
|
431
|
+
|
|
432
|
+
## Comment ça marche — Pipeline à 4 Passes
|
|
433
|
+
|
|
434
|
+
```
|
|
435
|
+
npx claudeos-core init
|
|
436
|
+
│
|
|
437
|
+
├── [1] npm install ← Dépendances (~10s)
|
|
438
|
+
├── [2] Structure de répertoires ← Créer les dossiers (~1s)
|
|
439
|
+
├── [3] plan-installer (Node.js) ← Scan du projet (~5s)
|
|
440
|
+
│ ├── Auto-détecte le stack (multi-stack aware)
|
|
441
|
+
│ ├── Extrait la liste de domaines (tagged : backend/frontend)
|
|
442
|
+
│ ├── Divise en groupes de domaines (par type)
|
|
443
|
+
│ ├── Construit pass3-context.json (résumé allégé, v2.1.0)
|
|
444
|
+
│ └── Sélectionne des prompts spécifiques au stack (par type)
|
|
445
|
+
│
|
|
446
|
+
├── [4] Pass 1 × N (claude -p) ← Analyse profonde du code (~2-8min)
|
|
447
|
+
│ ├── ⚙️ Groupes backend → prompt spécifique backend
|
|
448
|
+
│ └── 🎨 Groupes frontend → prompt spécifique frontend
|
|
449
|
+
│
|
|
450
|
+
├── [5] Pass 2 × 1 (claude -p) ← Merge d'analyse (~1min)
|
|
451
|
+
│ └── Consolide TOUS les résultats de Pass 1 dans pass2-merged.json
|
|
452
|
+
│
|
|
453
|
+
├── [6] Pass 3 (mode split, v2.1.0) ← Génère tout
|
|
454
|
+
│ │
|
|
455
|
+
│ ├── 3a × 1 (claude -p) ← Extraction de faits (~5-10min)
|
|
456
|
+
│ │ └── Lit pass2-merged.json une fois → pass3a-facts.md
|
|
457
|
+
│ │
|
|
458
|
+
│ ├── 3b-core × 1 (claude -p) ← CLAUDE.md + standard/rules communs
|
|
459
|
+
│ ├── 3b-1..N × N (claude -p) ← Standards/règles de domaine (≤15 domaines/batch)
|
|
460
|
+
│ │
|
|
461
|
+
│ ├── 3c-core × 1 (claude -p) ← Guides + skills partagés + MANIFEST.md
|
|
462
|
+
│ ├── 3c-1..N × N (claude -p) ← Sous-skills de domaine (≤15 domaines/batch)
|
|
463
|
+
│ │
|
|
464
|
+
│ └── 3d-aux × 1 (claude -p) ← Stubs database/ + mcp-guide/
|
|
465
|
+
│
|
|
466
|
+
├── [7] Pass 4 × 1 (claude -p) ← Memory scaffolding (~30s-5min)
|
|
467
|
+
│ ├── Seed memory/ (decision-log, failure-patterns, …)
|
|
468
|
+
│ ├── Génère les règles 60.memory/
|
|
469
|
+
│ ├── Ajoute la section « Memory (L4) » à CLAUDE.md
|
|
470
|
+
│ └── Gap-fill : garantit skills/00.shared/MANIFEST.md (v2.1.0)
|
|
471
|
+
│
|
|
472
|
+
└── [8] Vérification ← Auto-exécute le health checker
|
|
473
|
+
```
|
|
474
|
+
|
|
475
|
+
### Pourquoi 4 Passes ?
|
|
476
|
+
|
|
477
|
+
**Pass 1** est le seul pass qui lit votre code source. Il sélectionne des fichiers représentatifs par domaine et extrait des patterns à travers 55–95 catégories d'analyse (selon le stack). Pour les gros projets, Pass 1 tourne plusieurs fois — une par groupe de domaines. Dans les projets multi-stack (ex : Java backend + React frontend), les domaines backend et frontend utilisent des **prompts d'analyse différents** adaptés à chaque stack.
|
|
478
|
+
|
|
479
|
+
**Pass 2** merge tous les résultats de Pass 1 en une analyse unifiée : patterns communs (100% partagés), patterns majoritaires (50%+ partagés), patterns spécifiques à un domaine, anti-patterns par sévérité et préoccupations transverses (naming, sécurité, BD, testing, logging, performance). Les résultats backend et frontend sont mergés ensemble.
|
|
480
|
+
|
|
481
|
+
**Pass 3** (mode split, v2.1.0) prend l'analyse mergée et génère tout l'écosystème de fichiers (CLAUDE.md, règles, standards, skills, guides) à travers plusieurs appels `claude -p` séquentiels. L'intuition clé est que l'overflow par accumulation de sortie n'est pas prédictible à partir de la taille d'entrée : le Pass 3 en appel unique fonctionnait bien sur les projets à 2 domaines et échouait de façon fiable autour de 5 domaines, et la frontière d'échec bougeait selon la verbosité de chaque fichier. Le mode split contourne cela entièrement — chaque stage démarre avec une fenêtre de contexte fraîche et écrit un sous-ensemble borné de fichiers. La cohérence inter-stages (qui était le principal avantage de l'approche monolithique) est préservée par `pass3a-facts.md`, une fiche de faits distillée de 5 à 10 Ko que tous les stages suivants référencent.
|
|
482
|
+
|
|
483
|
+
Le template de prompt Pass 3 inclut également un **bloc Phase 1 « Read Once, Extract Facts »** avec cinq règles qui contraignent encore le volume de sortie :
|
|
484
|
+
|
|
485
|
+
- **Règle A** — Référencer la table de faits ; ne pas relire `pass2-merged.json`.
|
|
486
|
+
- **Règle B** — Écriture de fichiers idempotente (skip si la cible existe avec du contenu réel), rendant Pass 3 sûrement rejouable après interruption.
|
|
487
|
+
- **Règle C** — Cohérence inter-fichiers imposée via la table de faits comme unique source de vérité.
|
|
488
|
+
- **Règle D** — Concision de sortie : une seule ligne (`[WRITE]`/`[SKIP]`) entre chaque écriture de fichier, pas de recopie de la table de faits, pas d'écho du contenu des fichiers.
|
|
489
|
+
- **Règle E** — Vérification idempotente par batch : un seul `Glob` au début de PHASE 2 plutôt que des appels `Read` par cible.
|
|
490
|
+
|
|
491
|
+
**Pass 4** scaffolde la couche Memory L4 : fichiers persistants de connaissance d'équipe (decision-log, failure-patterns, politique de compaction, auto-rule-update) plus les règles `60.memory/` qui indiquent aux futures sessions quand et comment lire/écrire ces fichiers. La couche memory est ce qui permet à Claude Code d'accumuler des leçons entre les sessions au lieu de les redécouvrir à chaque fois. Quand `--lang` n'est pas l'anglais, le contenu statique de fallback est traduit via Claude avant d'être écrit. v2.1.0 ajoute un gap-fill pour `skills/00.shared/MANIFEST.md` au cas où Pass 3c l'aurait omis.
|
|
492
|
+
|
|
493
|
+
---
|
|
494
|
+
|
|
495
|
+
## Structure des Fichiers Générés
|
|
496
|
+
|
|
497
|
+
```
|
|
498
|
+
your-project/
|
|
499
|
+
│
|
|
500
|
+
├── CLAUDE.md ← Point d'entrée Claude Code
|
|
501
|
+
│
|
|
502
|
+
├── .claude/
|
|
503
|
+
│ └── rules/ ← Règles déclenchées par glob
|
|
504
|
+
│ ├── 00.core/
|
|
505
|
+
│ ├── 10.backend/
|
|
506
|
+
│ ├── 20.frontend/
|
|
507
|
+
│ ├── 30.security-db/
|
|
508
|
+
│ ├── 40.infra/
|
|
509
|
+
│ ├── 50.sync/ ← Règles de rappel de sync
|
|
510
|
+
│ └── 60.memory/ ← Règles de scope on-demand de la memory L4 (v2.0.0)
|
|
511
|
+
│
|
|
512
|
+
├── claudeos-core/ ← Répertoire principal de sortie
|
|
513
|
+
│ ├── generated/ ← JSON d'analyse + prompts dynamiques + marqueurs de Pass (mettre en gitignore)
|
|
514
|
+
│ │ ├── project-analysis.json ← Info du stack (multi-stack aware)
|
|
515
|
+
│ │ ├── domain-groups.json ← Groupes avec type : backend/frontend
|
|
516
|
+
│ │ ├── pass1-backend-prompt.md ← Prompt d'analyse backend
|
|
517
|
+
│ │ ├── pass1-frontend-prompt.md ← Prompt d'analyse frontend (si détecté)
|
|
518
|
+
│ │ ├── pass2-prompt.md ← Prompt de merge
|
|
519
|
+
│ │ ├── pass2-merged.json ← Sortie Pass 2 (consommée par Pass 3a uniquement)
|
|
520
|
+
│ │ ├── pass3-context.json ← Résumé allégé (< 5 Ko) pour Pass 3 (v2.1.0)
|
|
521
|
+
│ │ ├── pass3-prompt.md ← Template de prompt Pass 3 (bloc Phase 1 préfixé)
|
|
522
|
+
│ │ ├── pass3a-facts.md ← Fiche de faits écrite par Pass 3a, lue par 3b/3c/3d (v2.1.0)
|
|
523
|
+
│ │ ├── pass4-prompt.md ← Prompt de scaffolding memory (v2.0.0)
|
|
524
|
+
│ │ ├── pass3-complete.json ← Marqueur de complétion Pass 3 (mode split : inclut groupsCompleted, v2.1.0)
|
|
525
|
+
│ │ ├── pass4-memory.json ← Marqueur de complétion Pass 4 (skip au resume)
|
|
526
|
+
│ │ ├── rule-manifest.json ← Index de fichiers pour les outils de vérification
|
|
527
|
+
│ │ ├── sync-map.json ← Mapping Plan ↔ disque (vide en v2.1.0 ; conservé pour compat sync-checker)
|
|
528
|
+
│ │ ├── stale-report.json ← Résultats de vérification consolidés
|
|
529
|
+
│ │ ├── .i18n-cache-<lang>.json ← Cache de traduction (non-anglais `--lang`)
|
|
530
|
+
│ │ └── .staged-rules/ ← Répertoire de staging transitoire pour les écritures `.claude/rules/` (auto-déplacé + nettoyé)
|
|
531
|
+
│ ├── standard/ ← Standards de codage (15-19 fichiers + par-domaine dans 60.domains/)
|
|
532
|
+
│ │ ├── 00.core/ ← Vue d'ensemble, architecture, naming
|
|
533
|
+
│ │ ├── 10.backend-api/ ← Patterns API (spécifiques au stack)
|
|
534
|
+
│ │ ├── 20.frontend-ui/ ← Patterns frontend (si détecté)
|
|
535
|
+
│ │ ├── 30.security-db/ ← Sécurité, schéma BD, utilitaires
|
|
536
|
+
│ │ ├── 40.infra/ ← Config, logging, CI/CD
|
|
537
|
+
│ │ ├── 50.verification/ ← Vérification de build, testing
|
|
538
|
+
│ │ ├── 60.domains/ ← Standards par-domaine (écrits par Pass 3b-N, v2.1.0)
|
|
539
|
+
│ │ └── 90.optional/ ← Conventions optionnelles (extras spécifiques au stack)
|
|
540
|
+
│ ├── skills/ ← Skills de scaffolding CRUD/page
|
|
541
|
+
│ │ └── 00.shared/MANIFEST.md ← Source unique de vérité pour les skills enregistrés
|
|
542
|
+
│ ├── guide/ ← Onboarding, FAQ, troubleshooting (9 fichiers)
|
|
543
|
+
│ ├── database/ ← Schéma BD, guide de migration
|
|
544
|
+
│ ├── mcp-guide/ ← Guide d'intégration de serveur MCP
|
|
545
|
+
│ └── memory/ ← L4 : connaissance d'équipe (4 fichiers) — commitez-les
|
|
546
|
+
│ ├── decision-log.md ← Le « pourquoi » derrière les décisions de conception
|
|
547
|
+
│ ├── failure-patterns.md ← Erreurs récurrentes et fixes (auto-scoré — `npx claudeos-core memory score`)
|
|
548
|
+
│ ├── compaction.md ← Stratégie de compaction en 4 étapes (lancez `npx claudeos-core memory compact`)
|
|
549
|
+
│ └── auto-rule-update.md ← Propositions d'amélioration de règles (`npx claudeos-core memory propose-rules`)
|
|
550
|
+
│
|
|
551
|
+
└── claudeos-core-tools/ ← Ce toolkit (ne pas modifier)
|
|
552
|
+
```
|
|
553
|
+
|
|
554
|
+
Chaque fichier standard inclut ✅ des exemples corrects, ❌ des exemples incorrects et une table récapitulative des règles — tout dérivé des vrais patterns de votre code, pas de templates génériques.
|
|
555
|
+
|
|
556
|
+
> **Remarque v2.1.0 :** `claudeos-core/plan/` n'est plus généré. Les master plans étaient un backup interne que Claude Code ne consommait pas à l'exécution, et leur agrégation dans Pass 3 était une cause majeure d'overflow par accumulation de sortie. Utilisez `git` pour le backup/restore à la place. Les projets qui migrent depuis la v2.0.x peuvent supprimer sans risque un éventuel répertoire `claudeos-core/plan/` existant.
|
|
557
|
+
|
|
558
|
+
### Recommandations de gitignore
|
|
559
|
+
|
|
560
|
+
**À commiter** (connaissance d'équipe — destinée au partage) :
|
|
561
|
+
- `CLAUDE.md` — point d'entrée Claude Code
|
|
562
|
+
- `.claude/rules/**` — règles auto-chargées
|
|
563
|
+
- `claudeos-core/standard/**`, `skills/**`, `guide/**`, `database/**`, `mcp-guide/**`, `plan/**` — documentation générée
|
|
564
|
+
- `claudeos-core/memory/**` — historique de décisions, patterns d'échec, propositions de règles
|
|
565
|
+
|
|
566
|
+
**À NE PAS commiter** (artefacts de build régénérables) :
|
|
567
|
+
|
|
568
|
+
```gitignore
|
|
569
|
+
# ClaudeOS-Core — analyse générée et cache de traduction
|
|
570
|
+
claudeos-core/generated/
|
|
571
|
+
```
|
|
572
|
+
|
|
573
|
+
Le répertoire `generated/` contient le JSON d'analyse (`pass1-*.json`, `pass2-merged.json`), les prompts (`pass1/2/3/4-prompt.md`), les marqueurs de complétion de Pass (`pass3-complete.json`, `pass4-memory.json`), le cache de traduction (`.i18n-cache-<lang>.json`) et le répertoire transitoire de staging (`.staged-rules/`) — tout reconstruisible en relançant `npx claudeos-core init`.
|
|
574
|
+
|
|
575
|
+
---
|
|
576
|
+
|
|
577
|
+
## Auto-scaling selon la Taille du Projet
|
|
578
|
+
|
|
579
|
+
Le mode split de Pass 3 adapte le nombre de stages au nombre de domaines. La sous-division en batches se déclenche à 16 domaines pour garder chaque stage sous ~50 fichiers de sortie, qui est la plage empiriquement sûre pour `claude -p` avant que l'overflow par accumulation de sortie ne commence.
|
|
580
|
+
|
|
581
|
+
| Taille du projet | Domaines | Stages Pass 3 | Total `claude -p` | Temps est. |
|
|
582
|
+
|---|---|---|---|---|
|
|
583
|
+
| Petit | 1–4 | 4 (`3a`, `3b-core`, `3c-core`, `3d-aux`) | 7 (Pass 1 + 2 + 4 stages de Pass 3 + Pass 4) | ~10–15 min |
|
|
584
|
+
| Moyen | 5–15 | 4 | 8–9 | ~25–45 min |
|
|
585
|
+
| Grand | 16–30 | **8** (3b, 3c chacun divisé en 2 batches) | 11–12 | **~60–105 min** |
|
|
586
|
+
| X-Grand | 31–45 | 10 | 13–14 | ~100–150 min |
|
|
587
|
+
| XX-Grand | 46–60 | 12 | 15–16 | ~150–200 min |
|
|
588
|
+
| XXX-Grand | 61+ | 14+ | 17+ | 200 min+ |
|
|
589
|
+
|
|
590
|
+
Formule du nombre de stages (quand batché) : `1 (3a) + 1 (3b-core) + N (3b-1..N) + 1 (3c-core) + N (3c-1..N) + 1 (3d-aux) = 2N + 4`, où `N = ceil(totalDomains / 15)`.
|
|
591
|
+
|
|
592
|
+
Pass 4 (memory scaffolding) ajoute ~30 secondes à 5 minutes par-dessus selon que la génération pilotée par Claude ou le fallback statique tourne. Pour les projets multi-stack (ex : Java + React), les domaines backend et frontend sont comptés ensemble. Un projet avec 6 domaines backend + 4 frontend = 10 au total = palier Moyen.
|
|
593
|
+
|
|
594
|
+
### Cas de production réel : admin frontend de 18 domaines (2026-04-20)
|
|
595
|
+
|
|
596
|
+
Un admin frontend React 19 + Vite 6 + TypeScript de 18 domaines et 6 groupes de domaines s'est terminé de bout en bout en **102 minutes avec 101 fichiers générés**. Détail par stage :
|
|
597
|
+
|
|
598
|
+
| Stage | Fichiers | Temps | Fichiers/min |
|
|
599
|
+
|---|---|---|---|
|
|
600
|
+
| `3a` (extraction de faits) | 1 (`pass3a-facts.md`) | 8m 44s | — |
|
|
601
|
+
| `3b-core` (CLAUDE.md + commun) | 24 | 22m 10s | 1.1 |
|
|
602
|
+
| `3b-1` (15 domaines) | 30 | 10m 6s | **3.0** |
|
|
603
|
+
| `3b-2` (3 domaines) | 6 | 4m 34s | 1.3 |
|
|
604
|
+
| `3c-core` (guides + partagés) | 11 | 8m 31s | 1.3 |
|
|
605
|
+
| `3c-1` (15 domaines) | 8 | 5m 11s | **1.5** |
|
|
606
|
+
| `3c-2` (3 domaines) | 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
|
+
Le débit est nettement plus élevé sur les stages de domaines batchés (3b-1 : 3.0 fichiers/min contre 3b-core : 1.1 fichiers/min) car les stages à contexte frais bénéficient de patterns par-domaine serrés et répétables. Vérification tout vert : `plan-validator`, `sync-checker`, `content-validator`, `pass-json-validator` — zéro échec d'overflow, zéro troncation.
|
|
611
|
+
|
|
612
|
+
---
|
|
613
|
+
|
|
614
|
+
## Outils de Vérification
|
|
615
|
+
|
|
616
|
+
ClaudeOS-Core inclut 5 outils de vérification intégrés qui tournent automatiquement après la génération :
|
|
617
|
+
|
|
618
|
+
```bash
|
|
619
|
+
# Lancer toutes les vérifications d'un coup (recommandé)
|
|
620
|
+
npx claudeos-core health
|
|
621
|
+
|
|
622
|
+
# Commandes individuelles
|
|
623
|
+
npx claudeos-core validate # Comparaison Plan ↔ disque
|
|
624
|
+
npx claudeos-core refresh # Sync Disque → Plan
|
|
625
|
+
npx claudeos-core restore # Restore Plan → Disque
|
|
626
|
+
|
|
627
|
+
# Ou utiliser node directement (utilisateurs git clone)
|
|
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
|
+
| Outil | Ce qu'il fait |
|
|
635
|
+
|---|---|
|
|
636
|
+
| **manifest-generator** | Construit le JSON de métadonnées (`rule-manifest.json`, `sync-map.json`, initialise `stale-report.json`) ; indexe 7 répertoires dont `memory/` (`totalMemory` dans summary). v2.1.0 : `plan-manifest.json` n'est plus généré puisque les master plans ont été supprimés. |
|
|
637
|
+
| **plan-validator** | Valide les blocs `<file>` du master plan par rapport au disque pour les projets qui ont encore `claudeos-core/plan/` (cas de migration legacy). v2.1.0 : saute l'émission de `plan-sync-status.json` quand `plan/` est absent ou vide — `stale-report.json` enregistre quand même un no-op réussi. |
|
|
638
|
+
| **sync-checker** | Détecte les fichiers non enregistrés (sur disque mais pas dans le plan) et les entrées orphelines — couvre 7 répertoires (ajout de `memory/` en v2.0.0). Se termine proprement quand `sync-map.json` n'a aucun mapping (état par défaut v2.1.0). |
|
|
639
|
+
| **content-validator** | Vérification qualité en 9 sections — fichiers vides, exemples ✅/❌ manquants, sections requises, plus intégrité du scaffold memory L4 (dates de headings de decision-log, champs requis de failure-pattern, parsing fence-aware) |
|
|
640
|
+
| **pass-json-validator** | Valide la structure JSON de Pass 1–4 plus les marqueurs de complétion `pass3-complete.json` (forme mode split, v2.1.0) et `pass4-memory.json` |
|
|
641
|
+
|
|
642
|
+
---
|
|
643
|
+
|
|
644
|
+
## Comment Claude Code Utilise Votre Documentation
|
|
645
|
+
|
|
646
|
+
ClaudeOS-Core génère une documentation que Claude Code lit réellement — voici comment :
|
|
647
|
+
|
|
648
|
+
### Ce que Claude Code lit automatiquement
|
|
649
|
+
|
|
650
|
+
| Fichier | Quand | Garanti |
|
|
651
|
+
|---|---|---|
|
|
652
|
+
| `CLAUDE.md` | À chaque début de conversation | Toujours |
|
|
653
|
+
| `.claude/rules/00.core/*` | Quand n'importe quel fichier est édité (`paths: ["**/*"]`) | Toujours |
|
|
654
|
+
| `.claude/rules/10.backend/*` | Quand n'importe quel fichier est édité (`paths: ["**/*"]`) | Toujours |
|
|
655
|
+
| `.claude/rules/20.frontend/*` | Quand un fichier frontend est édité (limité aux chemins component/page/style) | Conditionnel |
|
|
656
|
+
| `.claude/rules/30.security-db/*` | Quand n'importe quel fichier est édité (`paths: ["**/*"]`) | Toujours |
|
|
657
|
+
| `.claude/rules/40.infra/*` | Uniquement lors de l'édition de fichiers config/infra (chemins limités) | Conditionnel |
|
|
658
|
+
| `.claude/rules/50.sync/*` | Uniquement lors de l'édition de fichiers claudeos-core (chemins limités) | Conditionnel |
|
|
659
|
+
| `.claude/rules/60.memory/*` | Quand `claudeos-core/memory/*` est édité (limité aux chemins memory) — indique **comment** lire/écrire la couche memory on-demand | Conditionnel (v2.0.0) |
|
|
660
|
+
|
|
661
|
+
### Ce que Claude Code lit on-demand via les références de règles
|
|
662
|
+
|
|
663
|
+
Chaque fichier de règle lie à son standard correspondant via une section `## Reference`. Claude lit uniquement le standard pertinent pour la tâche courante :
|
|
664
|
+
|
|
665
|
+
- `claudeos-core/standard/**` — patterns de codage, exemples ✅/❌, conventions de naming
|
|
666
|
+
- `claudeos-core/database/**` — schéma BD (pour queries, mappers, migrations)
|
|
667
|
+
- `claudeos-core/memory/**` (v2.0.0) — couche de connaissance d'équipe L4 ; **pas** auto-chargée (serait trop bruyante à chaque conversation). À la place, les règles `60.memory/*` indiquent à Claude *quand* Read ces fichiers : au début de session (skim du `decision-log.md` récent + `failure-patterns.md` à haute importance), et append-on-demand lors de décisions ou d'erreurs récurrentes.
|
|
668
|
+
|
|
669
|
+
Le `00.standard-reference.md` sert d'annuaire de tous les fichiers standard pour découvrir des standards qui n'ont pas de règle correspondante.
|
|
670
|
+
|
|
671
|
+
### Ce que Claude Code NE lit PAS (économise du contexte)
|
|
672
|
+
|
|
673
|
+
Ces dossiers sont explicitement exclus via la section `DO NOT Read` de la règle standard-reference :
|
|
674
|
+
|
|
675
|
+
| Dossier | Pourquoi exclu |
|
|
676
|
+
|---|---|
|
|
677
|
+
| `claudeos-core/plan/` | Backups de master plan des projets legacy (v2.0.x et antérieurs). Non généré en v2.1.0. Si présent, Claude Code ne le charge pas automatiquement — lecture on-demand uniquement. |
|
|
678
|
+
| `claudeos-core/generated/` | JSON de métadonnées de build, prompts, marqueurs de Pass, cache de traduction, `.staged-rules/`. Pas pour coder. |
|
|
679
|
+
| `claudeos-core/guide/` | Guides d'onboarding pour humains. |
|
|
680
|
+
| `claudeos-core/mcp-guide/` | Docs de serveur MCP. Pas pour coder. |
|
|
681
|
+
| `claudeos-core/memory/` (auto-load) | **Auto-load désactivé** par design — gonflerait le contexte à chaque conversation. Lu on-demand via les règles `60.memory/*` à la place (ex : scan de début de session de `failure-patterns.md`). Commitez toujours ces fichiers. |
|
|
682
|
+
|
|
683
|
+
---
|
|
684
|
+
|
|
685
|
+
## Workflow Quotidien
|
|
686
|
+
|
|
687
|
+
### Après l'installation
|
|
688
|
+
|
|
689
|
+
```
|
|
690
|
+
# Utilisez simplement Claude Code normalement — il référence vos standards automatiquement :
|
|
691
|
+
« Crée un CRUD pour le domaine order »
|
|
692
|
+
« Ajoute une API de mise à jour de profil utilisateur »
|
|
693
|
+
« Refactorise ce code pour qu'il matche les patterns du projet »
|
|
694
|
+
```
|
|
695
|
+
|
|
696
|
+
### Après édition manuelle des Standards
|
|
697
|
+
|
|
698
|
+
```bash
|
|
699
|
+
# Après avoir édité des fichiers de standards ou de règles :
|
|
700
|
+
npx claudeos-core refresh
|
|
701
|
+
|
|
702
|
+
# Vérifiez que tout est cohérent
|
|
703
|
+
npx claudeos-core health
|
|
704
|
+
```
|
|
705
|
+
|
|
706
|
+
### Quand les docs sont corrompues
|
|
707
|
+
|
|
708
|
+
```bash
|
|
709
|
+
# Recommandation v2.1.0 : utilisez git pour restaurer (puisque les master plans
|
|
710
|
+
# ne sont plus générés). Commitez vos docs générés régulièrement pour pouvoir
|
|
711
|
+
# revenir en arrière sur des fichiers spécifiques sans tout régénérer :
|
|
712
|
+
git checkout HEAD -- .claude/rules/ claudeos-core/
|
|
713
|
+
|
|
714
|
+
# Legacy (projets v2.0.x avec claudeos-core/plan/ encore présent) :
|
|
715
|
+
npx claudeos-core restore
|
|
716
|
+
```
|
|
717
|
+
|
|
718
|
+
### Maintenance de la couche Memory (v2.0.0)
|
|
719
|
+
|
|
720
|
+
La couche Memory L4 (`claudeos-core/memory/`) accumule la connaissance d'équipe à travers les sessions. Trois sous-commandes CLI la maintiennent en bonne santé :
|
|
721
|
+
|
|
722
|
+
```bash
|
|
723
|
+
# Compact : applique la politique de compaction en 4 étapes (à lancer périodiquement — ex : mensuellement)
|
|
724
|
+
npx claudeos-core memory compact
|
|
725
|
+
# Étape 1 : résume les entrées anciennes (>30 jours, corps → une ligne)
|
|
726
|
+
# Étape 2 : merge les headings dupliqués (fréquence sommée, dernier fix conservé)
|
|
727
|
+
# Étape 3 : drop basse-importance + anciennes (importance <3 ET lastSeen >60 jours)
|
|
728
|
+
# Étape 4 : applique le plafond de 400 lignes par fichier (la plus ancienne basse-importance est supprimée en premier)
|
|
729
|
+
|
|
730
|
+
# Score : re-classe les entrées de failure-patterns.md par importance
|
|
731
|
+
npx claudeos-core memory score
|
|
732
|
+
# importance = round(frequency × 1.5 + recency × 5), plafonné à 10
|
|
733
|
+
# À lancer après avoir ajouté plusieurs nouveaux failure patterns
|
|
734
|
+
|
|
735
|
+
# Propose-rules : fait remonter des candidats d'ajouts de règles depuis les échecs récurrents
|
|
736
|
+
npx claudeos-core memory propose-rules
|
|
737
|
+
# Lit les entrées de failure-patterns.md avec frequency ≥ 3
|
|
738
|
+
# Calcule la confiance (sigmoïde sur evidence pondérée × multiplicateur d'anchor)
|
|
739
|
+
# Écrit les propositions dans memory/auto-rule-update.md (PAS auto-appliqué)
|
|
740
|
+
# Confiance ≥ 0.70 mérite une revue sérieuse ; accepter → éditer la règle + loguer la décision
|
|
741
|
+
|
|
742
|
+
# v2.1.0 : `memory --help` route désormais vers l'aide des sous-commandes (auparavant top-level)
|
|
743
|
+
npx claudeos-core memory --help
|
|
744
|
+
```
|
|
745
|
+
|
|
746
|
+
> **Corrections v2.1.0 :** `memory score` ne laisse plus de lignes `importance` dupliquées après la première exécution (auparavant la ligne auto-scorée était ajoutée au-dessus tandis que la ligne plate d'origine restait en dessous). Le marqueur de résumé de l'Étape 1 de `memory compact` est désormais un vrai item de liste markdown (`- _Summarized on ..._`) pour qu'il s'affiche proprement et soit correctement re-parsé lors des compactions suivantes.
|
|
747
|
+
|
|
748
|
+
Quand écrire dans memory (Claude le fait on-demand, mais vous pouvez aussi éditer manuellement) :
|
|
749
|
+
- **`decision-log.md`** — ajoutez une nouvelle entrée quand vous choisissez entre des patterns concurrents, sélectionnez une bibliothèque, définissez une convention d'équipe ou décidez de NE PAS faire quelque chose. Append-only ; n'éditez jamais les entrées historiques.
|
|
750
|
+
- **`failure-patterns.md`** — ajoutez à la **deuxième occurrence** d'une erreur récurrente ou d'une root cause non évidente. Les erreurs de première fois n'ont pas besoin d'entrée.
|
|
751
|
+
- `compaction.md` et `auto-rule-update.md` — générés/gérés par les sous-commandes CLI ci-dessus ; ne pas éditer à la main.
|
|
752
|
+
|
|
753
|
+
### Intégration CI/CD
|
|
754
|
+
|
|
755
|
+
```yaml
|
|
756
|
+
# Exemple GitHub Actions
|
|
757
|
+
- run: npx claudeos-core validate
|
|
758
|
+
# Exit code 1 bloque la PR
|
|
759
|
+
|
|
760
|
+
# Optionnel : housekeeping mensuel de memory (workflow cron séparé)
|
|
761
|
+
- run: npx claudeos-core memory compact
|
|
762
|
+
- run: npx claudeos-core memory score
|
|
763
|
+
```
|
|
764
|
+
|
|
765
|
+
---
|
|
766
|
+
|
|
767
|
+
## En Quoi Est-ce Différent ?
|
|
768
|
+
|
|
769
|
+
### vs autres outils Claude Code
|
|
770
|
+
|
|
771
|
+
| | ClaudeOS-Core | Everything Claude Code (50K+ ⭐) | Harness | specs-generator | Claude `/init` |
|
|
772
|
+
|---|---|---|---|---|---|
|
|
773
|
+
| **Approche** | Code analyse d'abord, puis LLM génère | Presets de config pré-construits | Le LLM conçoit des équipes d'agents | Le LLM génère des docs de spec | Le LLM écrit CLAUDE.md |
|
|
774
|
+
| **Lit votre code source** | ✅ Analyse statique déterministe | ❌ | ❌ | ❌ (le LLM lit) | ❌ (le LLM lit) |
|
|
775
|
+
| **Détection de stack** | Le code confirme (ORM, BD, build tool, pkg manager) | N/A (stack-agnostic) | Le LLM devine | Le LLM devine | Le LLM devine |
|
|
776
|
+
| **Détection de domaines** | Le code confirme (Java 5 patterns, Kotlin CQRS, Next.js FSD) | N/A | Le LLM devine | N/A | N/A |
|
|
777
|
+
| **Même projet → Même résultat** | ✅ Analyse déterministe | ✅ (fichiers statiques) | ❌ (le LLM varie) | ❌ (le LLM varie) | ❌ (le LLM varie) |
|
|
778
|
+
| **Gestion des gros projets** | Split en groupes de domaines (4 domaines / 40 fichiers par groupe) | N/A | Pas de split | Pas de split | Limite de fenêtre de contexte |
|
|
779
|
+
| **Sortie** | CLAUDE.md + Rules + Standards + Skills + Guides + Plans (40-50+ fichiers) | Agents + Skills + Commands + Hooks | Agents + Skills | 6 documents de spec | CLAUDE.md (1 fichier) |
|
|
780
|
+
| **Emplacement de sortie** | `.claude/rules/` (auto-chargé par Claude Code) | `.claude/` divers | `.claude/agents/` + `.claude/skills/` | `.claude/steering/` + `specs/` | `CLAUDE.md` |
|
|
781
|
+
| **Vérification post-génération** | ✅ 5 validateurs automatiques | ❌ | ❌ | ❌ | ❌ |
|
|
782
|
+
| **Sortie multi-langue** | ✅ 10 langues | ❌ | ❌ | ❌ | ❌ |
|
|
783
|
+
| **Multi-stack** | ✅ Backend + Frontend simultanés | ❌ Stack-agnostic | ❌ | ❌ | Partiel |
|
|
784
|
+
| **Couche memory persistante** | ✅ L4 — decision log + failure patterns + propositions de règles auto-scorées (v2.0.0) | ❌ | ❌ | ❌ | ❌ |
|
|
785
|
+
| **Orchestration d'agents** | ❌ | ✅ 28 agents | ✅ 6 patterns | ❌ | ❌ |
|
|
786
|
+
|
|
787
|
+
### La différence clé en une phrase
|
|
788
|
+
|
|
789
|
+
**Les autres outils donnent à Claude « des instructions globalement correctes ». ClaudeOS-Core donne à Claude « des instructions extraites de votre code réel ».**
|
|
790
|
+
|
|
791
|
+
C'est pourquoi Claude Code arrête de générer du code JPA dans votre projet MyBatis,
|
|
792
|
+
arrête d'utiliser `success()` quand votre codebase utilise `ok()`,
|
|
793
|
+
et arrête de créer des répertoires `user/controller/` quand votre projet utilise `controller/user/`.
|
|
794
|
+
|
|
795
|
+
### Complémentaires, pas concurrents
|
|
796
|
+
|
|
797
|
+
ClaudeOS-Core se concentre sur les **règles et standards spécifiques au projet**.
|
|
798
|
+
Les autres outils se concentrent sur **l'orchestration d'agents et les workflows**.
|
|
799
|
+
|
|
800
|
+
Vous pouvez utiliser ClaudeOS-Core pour générer les règles de votre projet, puis utiliser ECC ou Harness par-dessus pour les équipes d'agents et l'automatisation des workflows. Ils résolvent des problèmes différents.
|
|
801
|
+
|
|
802
|
+
---
|
|
803
|
+
|
|
804
|
+
## FAQ
|
|
805
|
+
|
|
806
|
+
**Q : Est-ce que ça modifie mon code source ?**
|
|
807
|
+
Non. Il crée uniquement `CLAUDE.md`, `.claude/rules/` et `claudeos-core/`. Votre code existant n'est jamais modifié.
|
|
808
|
+
|
|
809
|
+
**Q : Combien ça coûte ?**
|
|
810
|
+
Il appelle `claude -p` plusieurs fois à travers les 4 passes. En mode split v2.1.0, Pass 3 seul se développe en 4–14+ stages selon la taille du projet (voir [Auto-scaling](#auto-scaling-selon-la-taille-du-projet)). Un petit projet typique (1–15 domaines) utilise 8–9 appels `claude -p` au total ; un projet de 18 domaines en utilise 11 ; un projet de 60 domaines en utilise 15–17. Chaque stage tourne avec une fenêtre de contexte fraîche — le coût en tokens par appel est en fait plus bas qu'avec le Pass 3 monolithique, parce qu'aucun stage n'a à retenir l'arbre de fichiers entier dans un seul contexte. Quand `--lang` n'est pas l'anglais, le chemin de fallback statique peut invoquer quelques appels supplémentaires à `claude -p` pour traduire ; les résultats sont cachés dans `claudeos-core/generated/.i18n-cache-<lang>.json` pour que les exécutions suivantes les réutilisent. Cela reste dans l'usage normal de Claude Code.
|
|
811
|
+
|
|
812
|
+
**Q : Qu'est-ce que le mode split de Pass 3 et pourquoi a-t-il été ajouté en v2.1.0 ?**
|
|
813
|
+
Avant la v2.1.0, Pass 3 faisait un seul appel `claude -p` qui devait émettre tout l'arbre de fichiers généré (`CLAUDE.md`, standards, règles, skills, guides — typiquement 30–60 fichiers) en une seule réponse. Cela fonctionnait sur les petits projets mais se heurtait de façon fiable à des échecs `Prompt is too long` par accumulation de sortie autour de 5 domaines. L'échec n'était pas prédictible à partir de la taille d'entrée — il dépendait de la verbosité des fichiers générés et pouvait frapper le même projet de façon intermittente. Le mode split contourne le problème structurellement : Pass 3 est découpé en stages séquentiels (`3a` → `3b-core` → `3b-N` → `3c-core` → `3c-N` → `3d-aux`), chacun un appel `claude -p` séparé avec une fenêtre de contexte fraîche. La cohérence inter-stages est préservée par `pass3a-facts.md`, une fiche de faits distillée de 5 à 10 Ko que chaque stage suivant référence au lieu de relire `pass2-merged.json`. Le marqueur `pass3-complete.json` porte un array `groupsCompleted` pour qu'un crash pendant `3c-2` reprenne à `3c-2` (pas à `3a`), évitant de doubler le coût en tokens. Vérifié empiriquement jusqu'à 18 domaines × 101 fichiers × 102 minutes avec zéro overflow — voir [Auto-scaling](#auto-scaling-selon-la-taille-du-projet) pour le détail de production réel.
|
|
814
|
+
|
|
815
|
+
**Q : Dois-je commiter les fichiers générés dans Git ?**
|
|
816
|
+
Oui, recommandé. Votre équipe peut partager les mêmes standards Claude Code. Pensez à ajouter `claudeos-core/generated/` à `.gitignore` (le JSON d'analyse est régénérable).
|
|
817
|
+
|
|
818
|
+
**Q : Qu'en est-il des projets stack mixte (ex : Java backend + React frontend) ?**
|
|
819
|
+
Totalement supporté. ClaudeOS-Core auto-détecte les deux stacks, tagge les domaines comme `backend` ou `frontend`, et utilise des prompts d'analyse spécifiques au stack pour chacun. Pass 2 merge tout, et Pass 3 génère les standards backend et frontend à travers ses stages split — les domaines backend vont dans certains batches 3b/3c, les domaines frontend dans d'autres, tous référençant le même `pass3a-facts.md` pour la cohérence.
|
|
820
|
+
|
|
821
|
+
**Q : Est-ce que ça marche avec les monorepos Turborepo / pnpm workspaces / Lerna ?**
|
|
822
|
+
Oui. ClaudeOS-Core détecte `turbo.json`, `pnpm-workspace.yaml`, `lerna.json`, ou `package.json#workspaces` et scanne automatiquement les `package.json` des sous-packages pour les dépendances framework/ORM/BD. Le scan de domaines couvre les patterns `apps/*/src/` et `packages/*/src/`. Lancez depuis la racine du monorepo.
|
|
823
|
+
|
|
824
|
+
**Q : Que se passe-t-il en cas de re-lancement ?**
|
|
825
|
+
Si des résultats précédents de Pass 1/2 existent, un prompt interactif vous laisse choisir : **Continue** (reprendre là où ça s'est arrêté) ou **Fresh** (tout supprimer et repartir de zéro). Utilisez `--force` pour sauter le prompt et toujours repartir de zéro. En mode split v2.1.0, le resume de Pass 3 fonctionne à la granularité du stage — si l'exécution a crashé pendant `3c-2`, le prochain `init` reprend à `3c-2` plutôt que de redémarrer depuis `3a` (ce qui doublerait le coût en tokens). Le marqueur `pass3-complete.json` enregistre `mode: "split"` plus un array `groupsCompleted` pour piloter cette logique.
|
|
826
|
+
|
|
827
|
+
**Q : NestJS a-t-il son propre template ou utilise-t-il celui d'Express ?**
|
|
828
|
+
NestJS utilise un template dédié `node-nestjs` avec des catégories d'analyse spécifiques à NestJS : decorators `@Module`, `@Injectable`, `@Controller`, Guards, Pipes, Interceptors, container DI, patterns CQRS et `Test.createTestingModule`. Les projets Express utilisent le template séparé `node-express`.
|
|
829
|
+
|
|
830
|
+
**Q : Qu'en est-il des projets Vue / Nuxt ?**
|
|
831
|
+
Vue/Nuxt utilise un template dédié `vue-nuxt` couvrant Composition API, `<script setup>`, defineProps/defineEmits, Pinia stores, `useFetch`/`useAsyncData`, routes serveur Nitro et `@nuxt/test-utils`. Les projets Next.js/React utilisent le template `node-nextjs`.
|
|
832
|
+
|
|
833
|
+
**Q : Supporte-t-il Kotlin ?**
|
|
834
|
+
Oui. ClaudeOS-Core auto-détecte Kotlin depuis `build.gradle.kts` ou le plugin kotlin dans `build.gradle`. Il utilise un template dédié `kotlin-spring` avec une analyse spécifique Kotlin (data classes, sealed classes, coroutines, extension functions, MockK, etc.).
|
|
835
|
+
|
|
836
|
+
**Q : Qu'en est-il de l'architecture CQRS / BFF ?**
|
|
837
|
+
Totalement supporté pour les projets Kotlin multi-module. ClaudeOS-Core lit `settings.gradle.kts`, détecte les types de module (command, query, bff, integration) depuis les noms de module, et regroupe le même domaine à travers les modules Command/Query. Les standards générés incluent des règles séparées pour command controllers vs query controllers, patterns BFF/Feign et conventions de communication inter-modules.
|
|
838
|
+
|
|
839
|
+
**Q : Qu'en est-il des monorepos Gradle multi-module ?**
|
|
840
|
+
ClaudeOS-Core scanne tous les sous-modules (`**/src/main/kotlin/**/*.kt`) indépendamment de la profondeur d'imbrication. Les types de module sont inférés des conventions de naming (ex : `reservation-command-server` → domaine : `reservation`, type : `command`). Les bibliothèques partagées (`shared-lib`, `integration-lib`) sont également détectées.
|
|
841
|
+
|
|
842
|
+
**Q : Qu'est-ce que la couche Memory L4 (v2.0.0) ? Dois-je commiter `claudeos-core/memory/` ?**
|
|
843
|
+
Oui — **commitez toujours** `claudeos-core/memory/`. C'est une connaissance d'équipe persistante : `decision-log.md` enregistre le *pourquoi* des choix architecturaux (append-only), `failure-patterns.md` enregistre les erreurs récurrentes avec des scores d'importance pour que les futures sessions les évitent, `compaction.md` définit la politique de compaction en 4 étapes, et `auto-rule-update.md` collecte les propositions d'amélioration de règles générées par la machine. Contrairement aux règles (auto-chargées par chemin), les fichiers memory sont **on-demand** — Claude ne les lit que quand les règles `60.memory/*` le lui indiquent (ex : scan de début de session des échecs à haute importance). Cela maintient le coût de contexte bas tout en préservant la connaissance à long terme.
|
|
844
|
+
|
|
845
|
+
**Q : Et si Pass 4 échoue ?**
|
|
846
|
+
Le pipeline automatisé (`npx claudeos-core init`) a un fallback statique : si `claude -p` échoue ou si `pass4-prompt.md` est absent, il scaffolde la couche memory directement via `lib/memory-scaffold.js`. Quand `--lang` n'est pas l'anglais, le fallback statique **doit** traduire via la CLI `claude` — si ça échoue aussi, l'exécution s'avorte avec `InitError` (pas de fallback silencieux vers l'anglais). Relancez quand `claude` est authentifié, ou utilisez `--lang en` pour sauter la traduction. Les résultats de traduction sont cachés dans `claudeos-core/generated/.i18n-cache-<lang>.json` pour que les exécutions suivantes les réutilisent.
|
|
847
|
+
|
|
848
|
+
**Q : Que font `memory compact` / `memory score` / `memory propose-rules` ?**
|
|
849
|
+
Voir la section [Maintenance de la couche Memory](#maintenance-de-la-couche-memory-v200) ci-dessus. Version courte : `compact` lance la politique en 4 étapes (résumer anciennes, merger duplicats, drop basse-importance anciennes, appliquer plafond 400 lignes) ; `score` re-classe `failure-patterns.md` par importance (fréquence × récence) ; `propose-rules` fait remonter les candidats d'ajouts de règles depuis les échecs récurrents dans `auto-rule-update.md` (pas auto-appliqué — revoyez et acceptez/rejetez manuellement).
|
|
850
|
+
|
|
851
|
+
**Q : Pourquoi `--force` (ou le mode resume « fresh ») supprime-t-il `.claude/rules/` ?**
|
|
852
|
+
v2.0.0 a ajouté trois guards de silent-failure à Pass 3 (Guard 3 couvre deux variantes de sortie incomplète : H2 pour `guide/` et H1 pour `standard/skills`). Guard 1 (« déplacement partiel de staged-rules ») et Guard 3 (« sortie incomplète — fichiers guide manquants/vides ou sentinel standard manquant / skills vide ») ne dépendent pas des règles existantes, mais Guard 2 (« zéro règles détectées ») si — il se déclenche quand Claude a ignoré la directive `staging-override.md` et a tenté d'écrire directement dans `.claude/` (où la politique de chemins sensibles de Claude Code bloque). Des règles obsolètes d'une exécution précédente feraient que Guard 2 produise un faux négatif — donc `--force`/`fresh` efface `.claude/rules/` pour assurer une détection propre. **Les éditions manuelles des fichiers de règles seront perdues** sous `--force`/`fresh` ; sauvegardez d'abord si besoin. (Remarque v2.1.0 : Guard 3 H1 ne vérifie plus `plan/` puisque les master plans ne sont plus générés.)
|
|
853
|
+
|
|
854
|
+
**Q : Qu'est-ce que `claudeos-core/generated/.staged-rules/` et pourquoi existe-t-il ?**
|
|
855
|
+
La politique de chemins sensibles de Claude Code refuse les écritures directes dans `.claude/` depuis le sous-processus `claude -p` (même avec `--dangerously-skip-permissions`). v2.0.0 contourne cela en faisant que les prompts Pass 3/4 redirigent toutes les écritures `.claude/rules/` vers le répertoire de staging ; l'orchestrateur Node.js (qui n'est pas soumis à cette politique) déplace ensuite l'arbre staged dans `.claude/rules/` après chaque pass. C'est transparent pour l'utilisateur — le répertoire est auto-créé, auto-nettoyé et auto-déplacé. Si une exécution précédente a crashé en plein milieu du déplacement, la suivante efface le répertoire de staging avant de réessayer. En mode split v2.1.0, le runner de stage déplace les règles staged dans `.claude/rules/` après chaque stage (pas seulement à la fin), donc un crash en plein Pass 3 laisse en place les règles des stages déjà terminés.
|
|
856
|
+
|
|
857
|
+
**Q : Puis-je lancer Pass 3 manuellement au lieu de `npx claudeos-core init` ?**
|
|
858
|
+
Oui pour les petits projets (≤5 domaines) — les instructions manuelles en appel unique de l'[Étape 6](#étape-6--pass-3--générer-toute-la-documentation-divisée-en-plusieurs-stages) fonctionnent toujours. Pour les projets plus gros vous devriez utiliser `npx claudeos-core init` parce que c'est le runner split qui orchestre l'exécution stage par stage avec des contextes frais, gère la sous-division en batches à partir de 16 domaines, écrit la bonne forme de marqueur `pass3-complete.json` (`mode: "split"` + `groupsCompleted`), et déplace les règles staged entre les stages. Reproduire cette orchestration à la main est possible mais fastidieux. Si vous avez une raison d'exécuter des stages manuellement (ex : débogage d'un stage spécifique), vous pouvez templater `pass3-prompt.md` avec la bonne directive `STAGE:` et l'alimenter à `claude -p` directement — mais pensez à déplacer `.staged-rules/` après chaque stage et à mettre à jour le marqueur vous-même.
|
|
859
|
+
|
|
860
|
+
**Q : Mon projet est une migration depuis la v2.0.x et a un répertoire `claudeos-core/plan/` existant. Que faire ?**
|
|
861
|
+
Rien de requis — les outils v2.1.0 ignorent `plan/` quand il est absent ou vide, et `plan-validator` gère toujours les projets legacy avec des répertoires `plan/` peuplés pour la rétrocompatibilité. Vous pouvez supprimer sans risque `claudeos-core/plan/` si vous n'avez pas besoin des backups de master plan (l'historique git est un meilleur backup de toute façon). Si vous gardez `plan/`, lancer `npx claudeos-core init` ne le mettra pas à jour — le nouveau contenu n'est plus agrégé dans les master plans en v2.1.0. Les outils de vérification gèrent les deux cas proprement.
|
|
862
|
+
|
|
863
|
+
---
|
|
864
|
+
|
|
865
|
+
## Structure des Templates
|
|
866
|
+
|
|
867
|
+
```
|
|
868
|
+
pass-prompts/templates/
|
|
869
|
+
├── common/ # Header/footer partagés + pass4 + staging-override
|
|
870
|
+
├── java-spring/ # Java / Spring Boot
|
|
871
|
+
├── kotlin-spring/ # Kotlin / Spring Boot (CQRS, BFF, multi-module)
|
|
872
|
+
├── node-express/ # Node.js / Express
|
|
873
|
+
├── node-nestjs/ # Node.js / NestJS (Module, DI, Guard, Pipe, Interceptor)
|
|
874
|
+
├── node-fastify/ # Node.js / Fastify
|
|
875
|
+
├── node-nextjs/ # Next.js / React (App Router, RSC)
|
|
876
|
+
├── node-vite/ # Vite SPA (React, client-side routing, VITE_ env, Vitest)
|
|
877
|
+
├── vue-nuxt/ # Vue / Nuxt (Composition API, Pinia, Nitro)
|
|
878
|
+
├── angular/ # Angular
|
|
879
|
+
├── python-django/ # Python / Django (DRF)
|
|
880
|
+
├── python-fastapi/ # Python / FastAPI
|
|
881
|
+
└── python-flask/ # Python / Flask (Blueprint, app factory, Jinja2)
|
|
882
|
+
```
|
|
883
|
+
|
|
884
|
+
`plan-installer` auto-détecte votre(vos) stack(s), puis assemble des prompts spécifiques au type. NestJS, Vue/Nuxt, Vite SPA et Flask utilisent chacun des templates dédiés avec des catégories d'analyse spécifiques au framework (ex : `@Module`/`@Injectable`/Guards pour NestJS ; `<script setup>`/Pinia/useFetch pour Vue ; client-side routing/`VITE_` env pour Vite ; Blueprint/`app.factory`/Flask-SQLAlchemy pour Flask). Pour les projets multi-stack, des `pass1-backend-prompt.md` et `pass1-frontend-prompt.md` séparés sont générés, tandis que `pass3-prompt.md` combine les cibles de génération des deux stacks. En v2.1.0, le template Pass 3 est préfixé par `common/pass3-phase1.md` (le bloc « Read Once, Extract Facts » avec les Règles A–E) avant d'être tranché par stage en mode split. Pass 4 utilise le template partagé `common/pass4.md` (memory scaffolding) quel que soit le stack.
|
|
885
|
+
|
|
886
|
+
---
|
|
887
|
+
|
|
888
|
+
## Support Monorepo
|
|
889
|
+
|
|
890
|
+
ClaudeOS-Core auto-détecte les setups de monorepo JS/TS et scanne les sous-packages à la recherche de dépendances.
|
|
891
|
+
|
|
892
|
+
**Marqueurs de monorepo supportés** (auto-détectés) :
|
|
893
|
+
- `turbo.json` (Turborepo)
|
|
894
|
+
- `pnpm-workspace.yaml` (pnpm workspaces)
|
|
895
|
+
- `lerna.json` (Lerna)
|
|
896
|
+
- `package.json#workspaces` (npm/yarn workspaces)
|
|
897
|
+
|
|
898
|
+
**Lancez depuis la racine du monorepo** — ClaudeOS-Core lit `apps/*/package.json` et `packages/*/package.json` pour découvrir les dépendances framework/ORM/BD entre sous-packages :
|
|
899
|
+
|
|
900
|
+
```bash
|
|
901
|
+
cd my-monorepo
|
|
902
|
+
npx claudeos-core init
|
|
903
|
+
```
|
|
904
|
+
|
|
905
|
+
**Ce qui est détecté :**
|
|
906
|
+
- Dépendances de `apps/web/package.json` (ex : `next`, `react`) → stack frontend
|
|
907
|
+
- Dépendances de `apps/api/package.json` (ex : `express`, `prisma`) → stack backend
|
|
908
|
+
- Dépendances de `packages/db/package.json` (ex : `drizzle-orm`) → ORM/BD
|
|
909
|
+
- Chemins de workspace personnalisés depuis `pnpm-workspace.yaml` (ex : `services/*`)
|
|
910
|
+
|
|
911
|
+
**Le scan de domaines couvre aussi les layouts monorepo :**
|
|
912
|
+
- `apps/api/src/modules/*/` et `apps/api/src/*/` pour les domaines backend
|
|
913
|
+
- `apps/web/app/*/`, `apps/web/src/app/*/`, `apps/web/pages/*/` pour les domaines frontend
|
|
914
|
+
- `packages/*/src/*/` pour les domaines de packages partagés
|
|
915
|
+
|
|
916
|
+
```
|
|
917
|
+
my-monorepo/ ← Lancez ici : npx claudeos-core init
|
|
918
|
+
├── turbo.json ← Auto-détecté comme Turborepo
|
|
919
|
+
├── apps/
|
|
920
|
+
│ ├── web/ ← Next.js détecté depuis apps/web/package.json
|
|
921
|
+
│ │ ├── app/dashboard/ ← Domaine frontend détecté
|
|
922
|
+
│ │ └── package.json ← { "dependencies": { "next": "^14" } }
|
|
923
|
+
│ └── api/ ← Express détecté depuis apps/api/package.json
|
|
924
|
+
│ ├── src/modules/users/ ← Domaine backend détecté
|
|
925
|
+
│ └── package.json ← { "dependencies": { "express": "^4" } }
|
|
926
|
+
├── packages/
|
|
927
|
+
│ ├── db/ ← Drizzle détecté depuis packages/db/package.json
|
|
928
|
+
│ └── ui/
|
|
929
|
+
└── package.json ← { "workspaces": ["apps/*", "packages/*"] }
|
|
930
|
+
```
|
|
931
|
+
|
|
932
|
+
> **Remarque :** Pour les monorepos Kotlin/Java, la détection multi-module utilise `settings.gradle.kts` (voir [Détection des Domaines Kotlin Multi-Module](#détection-des-domaines-kotlin-multi-module) ci-dessus) et ne nécessite pas de marqueurs de monorepo JS.
|
|
933
|
+
|
|
934
|
+
## Troubleshooting
|
|
935
|
+
|
|
936
|
+
**« claude: command not found »** — La CLI Claude Code n'est pas installée ou pas dans le PATH. Voir [docs Claude Code](https://code.claude.com/docs/en/overview).
|
|
937
|
+
|
|
938
|
+
**« npm install failed »** — La version de Node.js est peut-être trop basse. Requiert v18+.
|
|
939
|
+
|
|
940
|
+
**« 0 domains detected »** — La structure de votre projet peut être non standard. Voir les patterns de détection ci-dessus pour votre stack.
|
|
941
|
+
|
|
942
|
+
**« 0 domains detected » sur projet Kotlin** — Assurez-vous que votre projet a `build.gradle.kts` (ou `build.gradle` avec plugin kotlin) à la racine, et que les fichiers source sont sous `**/src/main/kotlin/`. Pour les projets multi-module, assurez-vous que `settings.gradle.kts` contient des instructions `include()`. Les projets Kotlin single-module (sans `settings.gradle`) sont aussi supportés — les domaines sont extraits de la structure package/classe sous `src/main/kotlin/`.
|
|
943
|
+
|
|
944
|
+
**« Language detected as java instead of kotlin »** — ClaudeOS-Core vérifie d'abord le `build.gradle(.kts)` racine, puis les fichiers build des sous-modules. Si le fichier de build racine utilise le plugin `java` sans `kotlin`, mais que les sous-modules utilisent Kotlin, l'outil vérifie jusqu'à 5 fichiers de build de sous-modules en fallback. Si toujours pas détecté, assurez-vous qu'au moins un `build.gradle.kts` contient `kotlin("jvm")` ou `org.jetbrains.kotlin`.
|
|
945
|
+
|
|
946
|
+
**« CQRS not detected »** — La détection d'architecture dépend du fait que les noms de module contiennent les mots-clés `command` et `query`. Si vos modules utilisent un naming différent (ex : `write-server`, `read-server`), l'architecture CQRS ne sera pas auto-détectée. Vous pouvez ajuster manuellement les prompts générés après l'exécution de plan-installer.
|
|
947
|
+
|
|
948
|
+
**« Pass 3 produced 0 rule files under .claude/rules/ » (v2.0.0)** — Guard 2 s'est déclenché : Claude a ignoré la directive `staging-override.md` et a essayé d'écrire directement dans `.claude/`, où la politique de chemins sensibles de Claude Code bloque les écritures. Relancez avec `npx claudeos-core init --force`. Si l'erreur persiste, inspectez `claudeos-core/generated/pass3-prompt.md` pour vérifier que le bloc `staging-override.md` est en haut.
|
|
949
|
+
|
|
950
|
+
**« Pass 3 finished but N rule file(s) could not be moved from staging » (v2.0.0)** — Guard 1 s'est déclenché : le déplacement depuis staging a heurté un file lock transitoire (typiquement antivirus Windows ou file-watcher). Le marqueur n'est PAS écrit, donc l'exécution `init` suivante réessaie Pass 3 automatiquement. Relancez simplement `npx claudeos-core init`.
|
|
951
|
+
|
|
952
|
+
**« Pass 3 produced CLAUDE.md and rules but N/9 guide files are missing or empty » (v2.0.0)** — Guard 3 (H2) s'est déclenché : Claude a tronqué sa réponse au milieu après avoir écrit CLAUDE.md + règles mais avant de finir (ou de commencer) la section `claudeos-core/guide/` (9 fichiers attendus). Se déclenche aussi sur un fichier uniquement BOM ou uniquement whitespace (le heading a été écrit mais le corps a été tronqué). Sans ce guard, le marqueur de complétion serait quand même écrit, laissant `guide/` vide de façon permanente aux exécutions suivantes. Ici le marqueur n'est PAS écrit, donc l'exécution `init` suivante réessaie Pass 3 à partir des mêmes résultats de Pass 2. Si ça continue de se répéter, relancez avec `npx claudeos-core init --force` pour régénérer depuis zéro.
|
|
953
|
+
|
|
954
|
+
**« Pass 3 finished but the following required output(s) are missing or empty » (v2.0.0, mis à jour en v2.1.0)** — Guard 3 (H1) s'est déclenché : Claude a tronqué APRÈS `claudeos-core/guide/` mais avant (ou pendant) `claudeos-core/standard/` ou `claudeos-core/skills/`. Exigences : (a) `standard/00.core/01.project-overview.md` existe et n'est pas vide (sentinel écrit par le prompt Pass 3 de chaque stack), (b) `skills/` a ≥1 `.md` non vide. `database/` et `mcp-guide/` sont intentionnellement exclus (certains stacks produisent légitimement zéro fichier). `plan/` n'est plus vérifié depuis la v2.1.0 (les master plans ont été supprimés). Même chemin de récupération que Guard 3 (H2) : relancez `init`, ou `--force` si ça persiste.
|
|
955
|
+
|
|
956
|
+
**« Pass 3 split stage crashed partway through (v2.1.0) »** — Quand l'un des stages split (ex : `3b-1`, `3c-2`) échoue en cours d'exécution, le marqueur au niveau stage n'est PAS écrit, mais les stages terminés SONT enregistrés dans `pass3-complete.json.groupsCompleted`. L'exécution `init` suivante lit cet array et reprend au premier stage non terminé, sautant tout le travail terminé précédemment. Vous n'avez rien à faire manuellement — relancez simplement `npx claudeos-core init`. Si le resume échoue au même stage de façon répétée, inspectez `claudeos-core/generated/pass3-prompt.md` pour du contenu mal formé, puis essayez `--force` pour un redémarrage complet. La forme de `pass3-complete.json` (`mode: "split"`, `groupsCompleted: [...]`) est stable ; un marqueur manquant ou mal formé fait que tout Pass 3 redémarre depuis `3a`.
|
|
957
|
+
|
|
958
|
+
**« Pass 3 stale marker (shape mismatch) — treating as incomplete » (v2.1.0)** — Un `pass3-complete.json` d'une exécution monolithique pré-v2.1.0 est interprété sous les nouvelles règles du mode split. Le check de forme cherche `mode: "split"` et un array `groupsCompleted` ; si l'un ou l'autre manque, le marqueur est traité comme partiel et Pass 3 est relancé en mode split. Si vous avez migré depuis la v2.0.x, c'est attendu une fois — l'exécution suivante écrira la bonne forme de marqueur. Aucune action nécessaire.
|
|
959
|
+
|
|
960
|
+
**« pass2-merged.json exists but is malformed or incomplete (<5 top-level keys), re-running » (v2.0.0)** — Log info, pas une erreur. Au resume, `init` parse et valide désormais `pass2-merged.json` (≥5 clés de niveau supérieur requises, reflétant le seuil `INSUFFICIENT_KEYS` de `pass-json-validator`). Un squelette `{}` ou un JSON mal formé d'une exécution précédente crashée est automatiquement supprimé et Pass 2 est relancé. Pas d'action manuelle nécessaire — le pipeline s'auto-répare. Si ça récurre, inspectez `claudeos-core/generated/pass2-prompt.md` et réessayez avec `--force`.
|
|
961
|
+
|
|
962
|
+
**« Static fallback failed while translating to lang='ko' » (v2.0.0)** — Quand `--lang` n'est pas l'anglais, Pass 4 / fallback statique / gap-fill requièrent tous la CLI `claude` pour traduire. Si la traduction échoue (CLI non authentifiée, timeout réseau, ou la validation stricte a rejeté la sortie : longueur <40%, code fences cassés, frontmatter perdu, etc.), l'exécution s'avorte plutôt que d'écrire silencieusement en anglais. Fix : assurez-vous que `claude` est authentifié, ou relancez avec `--lang en` pour sauter la traduction.
|
|
963
|
+
|
|
964
|
+
**« pass4-memory.json exists but memory/ is empty » (v2.0.0)** — Une exécution précédente a écrit le marqueur mais l'utilisateur (ou un script de nettoyage) a supprimé `claudeos-core/memory/`. La CLI auto-détecte ce marqueur obsolète et relance Pass 4 au prochain `init`. Pas d'action manuelle nécessaire.
|
|
965
|
+
|
|
966
|
+
**« pass4-memory.json exists but is malformed (missing passNum/memoryFiles) — re-running Pass 4 » (v2.0.0)** — Log info, pas une erreur. Le contenu du marqueur de Pass 4 est désormais validé (`passNum === 4` + array `memoryFiles` non vide), pas seulement son existence. Un échec partiel de Claude qui aurait émis quelque chose comme `{"error":"timeout"}` comme corps du marqueur était précédemment accepté comme succès pour toujours ; maintenant le marqueur est supprimé et Pass 4 est relancé automatiquement.
|
|
967
|
+
|
|
968
|
+
**« Could not delete stale pass3-complete.json / pass4-memory.json » InitError (v2.0.0)** — `init` a détecté un marqueur obsolète (Pass 3 : CLAUDE.md a été supprimé extérieurement ; Pass 4 : memory/ vide ou corps de marqueur mal formé) et a tenté de le supprimer, mais l'appel `unlinkSync` a échoué — typiquement parce qu'un antivirus Windows ou un file-watcher (éditeur, indexeur IDE) retient le handle du fichier. Auparavant ceci était silencieusement ignoré, faisant que le pipeline sautait le pass et réutilisait le marqueur obsolète. Maintenant il échoue bruyamment. Fix : fermez tout éditeur/scanner AV qui pourrait avoir le fichier ouvert, puis relancez `npx claudeos-core init`.
|
|
969
|
+
|
|
970
|
+
**« CLAUDEOS_SKIP_TRANSLATION=1 is set but --lang='ko' requires translation » InitError (v2.0.0)** — Vous avez la variable d'environnement réservée aux tests `CLAUDEOS_SKIP_TRANSLATION=1` définie dans votre shell (probablement un reste de setup CI/test) ET vous avez choisi un `--lang` non-anglais. Cette variable d'environnement court-circuite le chemin de traduction dont dépendent le fallback statique et le gap-fill de Pass 4 pour la sortie non-anglaise. `init` détecte le conflit au moment de la sélection de langue et s'avorte immédiatement (plutôt que de crasher en plein Pass 4 avec une erreur imbriquée confuse). Fix : soit `unset CLAUDEOS_SKIP_TRANSLATION` avant de lancer, soit utilisez `npx claudeos-core init --lang en`.
|
|
971
|
+
|
|
972
|
+
---
|
|
973
|
+
|
|
974
|
+
## Contribuer
|
|
975
|
+
|
|
976
|
+
Les contributions sont les bienvenues ! Les domaines où l'aide est la plus nécessaire :
|
|
977
|
+
|
|
978
|
+
- **Nouveaux templates de stack** — Ruby/Rails, Go (Gin/Fiber/Echo), PHP (Laravel/Symfony), Rust (Axum/Actix), Svelte/SvelteKit, Remix
|
|
979
|
+
- **Intégration IDE** — extension VS Code, plugin IntelliJ
|
|
980
|
+
- **Templates CI/CD** — GitLab CI, CircleCI, exemples Jenkins (GitHub Actions déjà livré — voir `.github/workflows/test.yml`)
|
|
981
|
+
- **Couverture de test** — Étendre la suite de tests (actuellement 563 tests à travers 29 fichiers de test couvrant scanners, stack detection, domain grouping, plan parsing, prompt generation, CLI selectors, monorepo detection, Vite SPA detection, outils de vérification, memory scaffold L4, validation de resume de Pass 2, Pass 3 Guards 1/2/3 (H1 sentinel + H2 BOM-aware empty-file + strict stale-marker unlink), sous-division en batches du mode split Pass 3, resume de marqueur partiel Pass 3 (v2.1.0), validation du contenu du marqueur Pass 4 + rigueur du stale-marker unlink + gap-fill scaffoldSkillsManifest (v2.1.0), guard d'env-skip de traduction + early fail-fast + workflow CI, déplacement de staged-rules, fallback lang-aware de traduction, suite de régression de suppression des master plans (v2.1.0), régression de formatage memory score/compact (v2.1.0), et structure du template AI Work Rules)
|
|
982
|
+
|
|
983
|
+
Voir [`CONTRIBUTING.md`](./CONTRIBUTING.md) pour la liste complète des domaines, le style de code, la convention de commit et le guide pas à pas pour ajouter un nouveau template de stack.
|
|
984
|
+
|
|
985
|
+
---
|
|
986
|
+
|
|
987
|
+
## Auteur
|
|
988
|
+
|
|
989
|
+
Créé par **claudeos-core** — [GitHub](https://github.com/claudeos-core) · [Email](mailto:claudeoscore@gmail.com)
|
|
990
|
+
|
|
991
|
+
## Licence
|
|
992
|
+
|
|
993
|
+
ISC
|