claudeos-core 2.4.1 → 2.4.2
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/CHANGELOG.md +17 -0
- package/README.de.md +172 -174
- package/README.es.md +161 -163
- package/README.fr.md +159 -161
- package/README.hi.md +166 -168
- package/README.ja.md +166 -168
- package/README.ko.md +139 -141
- package/README.md +55 -57
- package/README.ru.md +173 -175
- package/README.vi.md +169 -171
- package/README.zh-CN.md +168 -170
- package/package.json +1 -1
package/README.de.md
CHANGED
|
@@ -7,58 +7,40 @@
|
|
|
7
7
|
[](LICENSE)
|
|
8
8
|
[](https://www.npmjs.com/package/claudeos-core)
|
|
9
9
|
|
|
10
|
-
**
|
|
11
|
-
|
|
12
|
-
Ein deterministischer Node.js-Scanner liest zuerst Ihren Code; eine 4-Pass-Claude-Pipeline schreibt anschließend den vollständigen Satz — `CLAUDE.md` + automatisch geladenes `.claude/rules/` + Standards + Skills + L4-Memory. 10 Ausgabesprachen, 5 Post-Generation-Validatoren und eine explizite Pfad-Allowlist, die das LLM daran hindert, Dateien oder Frameworks zu erfinden, die nicht in Ihrem Code stehen.
|
|
13
|
-
|
|
14
|
-
Funktioniert auf [**12 Stacks**](#supported-stacks) (inklusive Monorepos) — ein einziger `npx`-Befehl, ohne Konfiguration, resume-sicher, idempotent.
|
|
10
|
+
**Ein CLI, das `CLAUDE.md` und `.claude/rules/` direkt aus dem Quellcode deines Projekts erzeugt. Bei gleichem Input liefert es immer das gleiche Output. Unter der Haube arbeiten ein Node.js-Scanner, eine 4-Pass-Pipeline mit Claude und fünf Validatoren zusammen. 12 Stacks, 10 Sprachen, und es erfindet keine Pfade, die im Code nicht existieren.**
|
|
15
11
|
|
|
16
12
|
```bash
|
|
17
13
|
npx claudeos-core init
|
|
18
14
|
```
|
|
19
15
|
|
|
16
|
+
Läuft auf [**12 Stacks**](#supported-stacks), inklusive Monorepos. Ein Befehl reicht, ohne Konfiguration. Bricht ein Lauf ab, kannst du nahtlos fortsetzen, und mehrfaches Ausführen bleibt sicher.
|
|
17
|
+
|
|
20
18
|
[🇺🇸 English](README.md) · [🇰🇷 한국어](README.ko.md) · [🇨🇳 中文](README.zh-CN.md) · [🇯🇵 日本語](README.ja.md) · [🇪🇸 Español](README.es.md) · [🇻🇳 Tiếng Việt](README.vi.md) · [🇮🇳 हिन्दी](README.hi.md) · [🇷🇺 Русский](README.ru.md) · [🇫🇷 Français](README.fr.md)
|
|
21
19
|
|
|
22
20
|
---
|
|
23
21
|
|
|
24
|
-
##
|
|
25
|
-
|
|
26
|
-
Sie nutzen Claude Code. Es ist mächtig, aber jede Sitzung beginnt von vorn — es hat keine Erinnerung daran, wie _Ihr_ Projekt aufgebaut ist. Also fällt es auf „allgemein gute" Defaults zurück, die selten zu dem passen, was Ihr Team tatsächlich tut:
|
|
22
|
+
## Was ist das?
|
|
27
23
|
|
|
28
|
-
|
|
29
|
-
- Ihr Response-Wrapper ist `ApiResponse.ok()`, aber Claude schreibt `ResponseEntity.success()`.
|
|
30
|
-
- Ihre Pakete sind layer-first (`controller/order/`), aber Claude erstellt domain-first (`order/controller/`).
|
|
31
|
-
- Ihre Fehler laufen durch zentrale Middleware, aber Claude verstreut `try/catch` in jedem Endpoint.
|
|
24
|
+
Claude Code greift bei jeder neuen Session auf die Standardwerte des jeweiligen Frameworks zurück. Dein Team setzt **MyBatis** ein, Claude schreibt trotzdem JPA. Euer Wrapper heißt `ApiResponse.ok()`, Claude tippt aber `ResponseEntity.success()`. Eure Pakete sind layer-first organisiert, generiert wird trotzdem domain-first. Per Hand geschriebene `.claude/rules/` lösen das Problem zwar, doch sobald sich der Code weiterentwickelt, driften die Regeln davon weg.
|
|
32
25
|
|
|
33
|
-
|
|
26
|
+
**ClaudeOS-Core erzeugt diese Regeln deterministisch neu, direkt aus dem Quellcode.** Zuerst liest ein Node.js-Scanner alles aus: Stack, ORM, Paket-Layout und Dateipfade. Anschließend schreibt eine 4-Pass-Pipeline mit Claude den kompletten Dokumentensatz: `CLAUDE.md`, die automatisch geladenen `.claude/rules/`, dazu Standards und Skills. Eine explizite Pfad-Allowlist hält das LLM dabei in der Spur, aus ihr kann es nicht ausbrechen. Fünf Validatoren prüfen das Ergebnis, bevor es ausgeliefert wird.
|
|
34
27
|
|
|
35
|
-
|
|
28
|
+
Das Resultat: Bei gleichem Input bekommst du byte-identische Ausgabe, in jeder der 10 Sprachen, ohne erfundene Pfade. (Details findest du weiter unten unter [Was es anders macht](#was-es-anders-macht).)
|
|
36
29
|
|
|
37
|
-
|
|
38
|
-
- **`.claude/rules/`** — automatisch geladene Regeln pro Kategorie (`00.core` / `10.backend` / `20.frontend` / `30.security-db` / `40.infra` / `60.memory` / `70.domains` / `80.verification`)
|
|
39
|
-
- **`claudeos-core/standard/`** — Referenz-Dokumente (das „Warum" hinter jeder Regel)
|
|
40
|
-
- **`claudeos-core/skills/`** — wiederverwendbare Muster (CRUD-Scaffolding, Seitentemplates)
|
|
41
|
-
- **`claudeos-core/memory/`** — Decision-Log + Failure-Patterns, die mit dem Projekt mitwachsen
|
|
42
|
-
|
|
43
|
-
Weil der Scanner Claude eine explizite Pfad-Allowlist übergibt, **kann das LLM keine Dateien oder Frameworks erfinden, die nicht in Ihrem Code stehen**. Fünf Post-Generation-Validatoren (`claude-md-validator`, `content-validator`, `pass-json-validator`, `plan-validator`, `sync-checker`) verifizieren die Ausgabe, bevor sie ausgeliefert wird — sprachunabhängig, sodass dieselben Regeln gelten, ob Sie auf Englisch, Deutsch oder in einer von 8 weiteren Sprachen generieren.
|
|
44
|
-
|
|
45
|
-
```
|
|
46
|
-
Vorher: Sie → Claude Code → "allgemein guter" Code → manuelle Korrekturen
|
|
47
|
-
Nachher: Sie → Claude Code → Code, der zu IHREM Projekt passt → einsetzbar
|
|
48
|
-
```
|
|
30
|
+
Für langlebige Projekte legt das Tool außerdem einen separaten [Memory Layer](#memory-layer-optional-für-langlebige-projekte) an.
|
|
49
31
|
|
|
50
32
|
---
|
|
51
33
|
|
|
52
|
-
##
|
|
34
|
+
## Auf einem echten Projekt sehen
|
|
53
35
|
|
|
54
|
-
|
|
36
|
+
Hier ein Lauf auf [`spring-boot-realworld-example-app`](https://github.com/gothinkster/spring-boot-realworld-example-app): Java 11, Spring Boot 2.6, MyBatis, SQLite und 187 Quelldateien. Ergebnis: **75 generierte Dateien**, Gesamtdauer **53 Minuten**, alle Validatoren grün.
|
|
55
37
|
|
|
56
38
|
<p align="center">
|
|
57
39
|
<img src="docs/assets/spring-boot-realworld-demo.gif" alt="ClaudeOS-Core init running on spring-boot-realworld-example-app — stack detection, 4-pass pipeline, validators, completion summary" width="769">
|
|
58
40
|
</p>
|
|
59
41
|
|
|
60
42
|
<details>
|
|
61
|
-
<summary><strong
|
|
43
|
+
<summary><strong>Terminalausgabe (Textfassung, zum Suchen und Kopieren)</strong></summary>
|
|
62
44
|
|
|
63
45
|
```text
|
|
64
46
|
╔════════════════════════════════════════════════════╗
|
|
@@ -93,18 +75,18 @@ Ausgeführt auf [`spring-boot-realworld-example-app`](https://github.com/gothink
|
|
|
93
75
|
[██████████░░░░░░░░░░] 50% (2/4)
|
|
94
76
|
|
|
95
77
|
[6] Pass 3 — Generating all files...
|
|
96
|
-
|
|
78
|
+
Pass 3 split mode (3a → 3b → 3c → 3d-aux)
|
|
97
79
|
✅ 3a complete (2m 57s) — pass3a-facts.md (187-path allowlist)
|
|
98
80
|
✅ 3b complete (18m 49s) — CLAUDE.md + 19 standards + 20 rules
|
|
99
81
|
✅ 3c complete (12m 35s) — 13 skills + 9 guides
|
|
100
82
|
✅ 3d-aux complete (3m 18s) — database/ + mcp-guide/
|
|
101
|
-
|
|
83
|
+
Pass 3 split complete: 4/4 stages successful
|
|
102
84
|
[███████████████░░░░░] 75% (3/4)
|
|
103
85
|
|
|
104
86
|
[7] Pass 4 — Memory scaffolding...
|
|
105
|
-
|
|
87
|
+
Pass 4 staged-rules: 6 rule files moved to .claude/rules/
|
|
106
88
|
✅ Pass 4 complete (5m)
|
|
107
|
-
|
|
89
|
+
Gap-fill: all 12 expected files already present
|
|
108
90
|
[████████████████████] 100% (4/4)
|
|
109
91
|
|
|
110
92
|
╔═══════════════════════════════════════╗
|
|
@@ -133,7 +115,7 @@ Ausgeführt auf [`spring-boot-realworld-example-app`](https://github.com/gothink
|
|
|
133
115
|
</details>
|
|
134
116
|
|
|
135
117
|
<details>
|
|
136
|
-
<summary><strong
|
|
118
|
+
<summary><strong>Was tatsächlich in deiner <code>CLAUDE.md</code> landet (echter Auszug, Section 1 + 2)</strong></summary>
|
|
137
119
|
|
|
138
120
|
```markdown
|
|
139
121
|
# CLAUDE.md — spring-boot-realworld-example-app
|
|
@@ -142,7 +124,7 @@ Ausgeführt auf [`spring-boot-realworld-example-app`](https://github.com/gothink
|
|
|
142
124
|
> Java 11 + Spring Boot 2.6, exposing both REST and GraphQL endpoints
|
|
143
125
|
> over a hexagonal MyBatis persistence layer.
|
|
144
126
|
|
|
145
|
-
|
|
127
|
+
#### 1. Role Definition
|
|
146
128
|
|
|
147
129
|
As the senior developer for this repository, you are responsible for
|
|
148
130
|
writing, modifying, and reviewing code. Responses must be written in English.
|
|
@@ -150,7 +132,7 @@ A Java Spring Boot REST + GraphQL API server organized around a hexagonal
|
|
|
150
132
|
(ports & adapters) architecture, with a CQRS-lite read/write split inside
|
|
151
133
|
an XML-driven MyBatis persistence layer and JWT-based authentication.
|
|
152
134
|
|
|
153
|
-
|
|
135
|
+
#### 2. Project Overview
|
|
154
136
|
|
|
155
137
|
| Item | Value |
|
|
156
138
|
|---|---|
|
|
@@ -166,12 +148,12 @@ an XML-driven MyBatis persistence layer and JWT-based authentication.
|
|
|
166
148
|
| Test Stack | JUnit Jupiter 5, Mockito, AssertJ, rest-assured, spring-mock-mvc |
|
|
167
149
|
```
|
|
168
150
|
|
|
169
|
-
|
|
151
|
+
Sämtliche Werte in dieser Tabelle stammen aus dem Code selbst: die exakten Dependency-Koordinaten, der Dateiname `dev.db`, der Migrationsname `V1__create_tables.sql` und auch das "no JPA". Der Scanner liest sie aus `build.gradle`, `application.properties` und dem Source-Tree, bevor Claude die Datei überhaupt anfasst. Geraten wird hier nichts.
|
|
170
152
|
|
|
171
153
|
</details>
|
|
172
154
|
|
|
173
155
|
<details>
|
|
174
|
-
<summary><strong
|
|
156
|
+
<summary><strong>Eine echte, automatisch geladene Rule (<code>.claude/rules/10.backend/01.controller-rules.md</code>)</strong></summary>
|
|
175
157
|
|
|
176
158
|
````markdown
|
|
177
159
|
---
|
|
@@ -179,9 +161,9 @@ paths:
|
|
|
179
161
|
- "**/*"
|
|
180
162
|
---
|
|
181
163
|
|
|
182
|
-
|
|
164
|
+
#### Controller Rules
|
|
183
165
|
|
|
184
|
-
|
|
166
|
+
##### REST (`io.spring.api.*`)
|
|
185
167
|
|
|
186
168
|
- Controllers are the SOLE response wrapper for HTTP — no aggregator/facade above them.
|
|
187
169
|
Return `ResponseEntity<?>` or a body Spring serializes via `JacksonCustomizations`.
|
|
@@ -194,13 +176,13 @@ paths:
|
|
|
194
176
|
- Let exceptions propagate to `io.spring.api.exception.CustomizeExceptionHandler`
|
|
195
177
|
(`@ControllerAdvice`). Do NOT `try/catch` business exceptions inside the controller.
|
|
196
178
|
|
|
197
|
-
|
|
179
|
+
##### GraphQL (`io.spring.graphql.*`)
|
|
198
180
|
|
|
199
181
|
- DGS components (`@DgsComponent`) are the sole GraphQL response wrappers.
|
|
200
182
|
Use `@DgsQuery` / `@DgsData` / `@DgsMutation`.
|
|
201
183
|
- Resolve the current user via `io.spring.graphql.SecurityUtil.getCurrentUser()`.
|
|
202
184
|
|
|
203
|
-
|
|
185
|
+
##### Examples
|
|
204
186
|
|
|
205
187
|
✅ Correct:
|
|
206
188
|
```java
|
|
@@ -228,15 +210,15 @@ public ResponseEntity<?> create(@RequestBody NewArticleParam p) {
|
|
|
228
210
|
```
|
|
229
211
|
````
|
|
230
212
|
|
|
231
|
-
Der Glob `paths: ["**/*"]`
|
|
213
|
+
Der Glob `paths: ["**/*"]` sorgt dafür, dass Claude Code diese Rule lädt, sobald du irgendeine Datei im Projekt bearbeitest. Jeder Klassenname, jeder Paketpfad und jeder Exception-Handler in der Rule kommt unverändert aus dem gescannten Quellcode. Auch der reale `CustomizeExceptionHandler` und `JacksonCustomizations` des Projekts tauchen genau so auf, wie sie tatsächlich existieren.
|
|
232
214
|
|
|
233
215
|
</details>
|
|
234
216
|
|
|
235
217
|
<details>
|
|
236
|
-
<summary><strong
|
|
218
|
+
<summary><strong>Ein automatisch erzeugter Seed für <code>decision-log.md</code> (echter Auszug)</strong></summary>
|
|
237
219
|
|
|
238
220
|
```markdown
|
|
239
|
-
|
|
221
|
+
#### 2026-04-26 — Hexagonal ports & adapters with MyBatis-only persistence
|
|
240
222
|
|
|
241
223
|
- **Context:** `io.spring.core.*` exposes `*Repository` ports (e.g.,
|
|
242
224
|
`io.spring.core.article.ArticleRepository`) implemented by
|
|
@@ -255,260 +237,276 @@ Der Glob `paths: ["**/*"]` bedeutet, dass Claude Code diese Regel automatisch l
|
|
|
255
237
|
split the persistence model.
|
|
256
238
|
```
|
|
257
239
|
|
|
258
|
-
Pass 4
|
|
240
|
+
Pass 4 füllt `decision-log.md` mit den Architekturentscheidungen aus `pass2-merged.json`. Spätere Sessions wissen dadurch nicht nur, *wie* die Codebasis aussieht, sondern auch, *warum* sie so aussieht. Jede erwogene Option ("JPA/Hibernate", "MyBatis-Plus") und jede Konsequenz lässt sich direkt im Dependency-Block der `build.gradle` nachvollziehen.
|
|
259
241
|
|
|
260
242
|
</details>
|
|
261
243
|
|
|
262
244
|
---
|
|
263
245
|
|
|
264
|
-
##
|
|
246
|
+
## Getestet auf
|
|
265
247
|
|
|
266
|
-
|
|
248
|
+
ClaudeOS-Core wird mit Referenz-Benchmarks auf realen OSS-Projekten ausgeliefert. Hast du es selbst auf einem öffentlichen Repo laufen lassen, [eröffne gern ein Issue](https://github.com/claudeos-core/claudeos-core/issues). Wir nehmen den Eintrag dann in diese Tabelle auf.
|
|
249
|
+
|
|
250
|
+
| Projekt | Stack | Scanned → Generated | Status |
|
|
251
|
+
|---|---|---|---|
|
|
252
|
+
| [`spring-boot-realworld-example-app`](https://github.com/gothinkster/spring-boot-realworld-example-app) | Java 11 · Spring Boot 2.6 · MyBatis · SQLite | 187 → 75 files | ✅ alle 5 Validatoren bestanden |
|
|
253
|
+
|
|
254
|
+
---
|
|
255
|
+
|
|
256
|
+
## Schnellstart
|
|
257
|
+
|
|
258
|
+
**Voraussetzungen:** Node.js 18 oder neuer und ein installiertes, authentifiziertes [Claude Code](https://docs.anthropic.com/en/docs/claude-code).
|
|
267
259
|
|
|
268
260
|
```bash
|
|
269
|
-
# 1. In
|
|
261
|
+
# 1. In den Projekt-Root wechseln
|
|
270
262
|
cd my-spring-boot-project
|
|
271
263
|
|
|
272
|
-
# 2. init
|
|
264
|
+
# 2. init starten (analysiert deinen Code und lässt Claude die Rules schreiben)
|
|
273
265
|
npx claudeos-core init
|
|
274
266
|
|
|
275
|
-
# 3. Fertig. Claude Code
|
|
267
|
+
# 3. Fertig. Öffne Claude Code und leg los — die Rules sind bereits geladen.
|
|
276
268
|
```
|
|
277
269
|
|
|
278
|
-
|
|
270
|
+
Nach Abschluss von `init` findest du folgende Struktur vor:
|
|
279
271
|
|
|
280
272
|
```
|
|
281
273
|
your-project/
|
|
282
274
|
├── .claude/
|
|
283
|
-
│ └── rules/ ←
|
|
284
|
-
│ ├── 00.core/ (
|
|
285
|
-
│ ├── 10.backend/ (
|
|
286
|
-
│ ├── 20.frontend/ (
|
|
287
|
-
│ ├── 30.security-db/ (
|
|
288
|
-
│ ├── 40.infra/ (env,
|
|
289
|
-
│ ├── 50.sync/ (
|
|
290
|
-
│ ├── 60.memory/ (
|
|
291
|
-
│ ├── 70.domains/{type}/ (
|
|
292
|
-
│ └── 80.verification/ (
|
|
275
|
+
│ └── rules/ ← wird von Claude Code automatisch geladen
|
|
276
|
+
│ ├── 00.core/ (allgemeine Rules: Naming, Architektur)
|
|
277
|
+
│ ├── 10.backend/ (Backend-Stack-Rules, falls vorhanden)
|
|
278
|
+
│ ├── 20.frontend/ (Frontend-Stack-Rules, falls vorhanden)
|
|
279
|
+
│ ├── 30.security-db/ (Konventionen für Security und Datenbank)
|
|
280
|
+
│ ├── 40.infra/ (env, Logging, CI/CD)
|
|
281
|
+
│ ├── 50.sync/ (Hinweise zur Doc-Synchronisation, nur in rules)
|
|
282
|
+
│ ├── 60.memory/ (Memory-Rules aus Pass 4, nur in rules)
|
|
283
|
+
│ ├── 70.domains/{type}/ (Rules pro Domäne, type = backend|frontend)
|
|
284
|
+
│ └── 80.verification/ (Teststrategie und Hinweise zur Build-Verifikation)
|
|
293
285
|
├── claudeos-core/
|
|
294
|
-
│ ├── standard/ ←
|
|
295
|
-
│ │ ├── 00.core/ (
|
|
296
|
-
│ │ ├── 10.backend/ (
|
|
297
|
-
│ │ ├── 20.frontend/ (
|
|
298
|
-
│ │ ├── 30.security-db/ (
|
|
299
|
-
│ │ ├── 40.infra/ (env /
|
|
300
|
-
│ │ ├── 70.domains/{type}/ (
|
|
301
|
-
│ │ ├── 80.verification/ (
|
|
302
|
-
│ │ └── 90.optional/ (stack-
|
|
303
|
-
│ ├── skills/ (
|
|
304
|
-
│ ├── guide/ (
|
|
305
|
-
│ ├── database/ (
|
|
306
|
-
│ ├── mcp-guide/ (
|
|
307
|
-
│ └── memory/ (
|
|
308
|
-
└── CLAUDE.md (
|
|
286
|
+
│ ├── standard/ ← Referenzdokumente, gespiegelt zur Kategoriestruktur
|
|
287
|
+
│ │ ├── 00.core/ (Projektübersicht, Architektur, Naming)
|
|
288
|
+
│ │ ├── 10.backend/ (Backend-Referenz, sofern Backend-Stack vorhanden)
|
|
289
|
+
│ │ ├── 20.frontend/ (Frontend-Referenz, sofern Frontend-Stack vorhanden)
|
|
290
|
+
│ │ ├── 30.security-db/ (Referenz für Security und Datenbank)
|
|
291
|
+
│ │ ├── 40.infra/ (env / Logging / CI-CD-Referenz)
|
|
292
|
+
│ │ ├── 70.domains/{type}/ (Referenz pro Domäne)
|
|
293
|
+
│ │ ├── 80.verification/ (Referenz zu Build, Startup, Tests, nur in standard)
|
|
294
|
+
│ │ └── 90.optional/ (stack-spezifische Extras, nur in standard)
|
|
295
|
+
│ ├── skills/ (wiederverwendbare Patterns, die Claude anwenden kann)
|
|
296
|
+
│ ├── guide/ (How-to-Guides für gängige Aufgaben)
|
|
297
|
+
│ ├── database/ (Schema-Übersicht, Migrationsleitfaden)
|
|
298
|
+
│ ├── mcp-guide/ (Notizen zur MCP-Integration)
|
|
299
|
+
│ └── memory/ (Decision-Log, Failure-Patterns, Compaction)
|
|
300
|
+
└── CLAUDE.md (der Index, den Claude zuerst liest)
|
|
309
301
|
```
|
|
310
302
|
|
|
311
|
-
Kategorien
|
|
303
|
+
Kategorien mit demselben Nummern-Präfix in `rules/` und `standard/` decken denselben Themenbereich ab. So gehören etwa die Rules unter `10.backend` zu den Standards unter `10.backend`. Nur in `rules/` existieren `50.sync` (Hinweise zur Doc-Synchronisation) und `60.memory` (Memory aus Pass 4). Nur in `standard/` liegt `90.optional` (stack-spezifische Extras ohne Enforcement). Alle übrigen Präfixe (`00`, `10`, `20`, `30`, `40`, `70`, `80`) tauchen in BEIDEN Bäumen auf. Damit kennt Claude Code dein Projekt.
|
|
312
304
|
|
|
313
305
|
---
|
|
314
306
|
|
|
315
307
|
## Für wen ist das?
|
|
316
308
|
|
|
317
|
-
|
|
|
309
|
+
| Rolle | Schmerzpunkt, der wegfällt |
|
|
318
310
|
|---|---|
|
|
319
|
-
| **Solo-Entwickler**, der ein neues Projekt mit Claude Code
|
|
320
|
-
| **Team-Lead**, der gemeinsame Standards über mehrere Repos
|
|
321
|
-
| **
|
|
322
|
-
| **Onboarding in ein neues Repo** (
|
|
323
|
-
| **
|
|
324
|
-
| **
|
|
325
|
-
| **
|
|
311
|
+
| **Solo-Entwickler**, der ein neues Projekt mit Claude Code startet | "Claude in jeder Session die eigenen Konventionen erklären" entfällt komplett. `CLAUDE.md` und die `.claude/rules/` mit acht Kategorien entstehen in einem einzigen Durchlauf. |
|
|
312
|
+
| **Team-Lead**, der gemeinsame Standards über mehrere Repos pflegt | `.claude/rules/` driften, sobald jemand Pakete umbenennt, das ORM tauscht oder den Response-Wrapper anpasst. ClaudeOS-Core synchronisiert deterministisch nach. Gleicher Input liefert byte-identisches Output, also kein Diff-Rauschen. |
|
|
313
|
+
| **Du nutzt Claude Code bereits**, hast aber genug davon, generierten Code immer wieder zu reparieren | Falscher Response-Wrapper, falsches Paket-Layout, JPA, obwohl ihr MyBatis fahrt, verstreute `try/catch`-Blöcke trotz zentraler Middleware. Der Scanner liest die echten Konventionen aus, und jeder Claude-Pass läuft gegen eine explizite Pfad-Allowlist. |
|
|
314
|
+
| **Onboarding in ein neues Repo** (Bestandsprojekt, neues Team) | Einmal `init` im Repo ausführen, und du hast eine lebendige Architekturkarte: Stack-Tabelle in der CLAUDE.md, Rules pro Layer mit ✅/❌-Beispielen, dazu ein Decision-Log mit dem "Warum" hinter den großen Entscheidungen wie JPA gegen MyBatis oder REST gegen GraphQL. Fünf Dateien lesen schlägt 5.000 Quelldateien wälzen. |
|
|
315
|
+
| **Du arbeitest auf Koreanisch, Japanisch, Chinesisch oder in 7 weiteren Sprachen** | Die meisten Rule-Generatoren für Claude Code beherrschen nur Englisch. ClaudeOS-Core schreibt das vollständige Set in **10 Sprachen** (`en/ko/ja/zh-CN/es/vi/hi/ru/fr/de`). Die strukturelle Validierung bleibt dabei byte-identisch: Der `claude-md-validator` urteilt unabhängig von der Ausgabesprache gleich. |
|
|
316
|
+
| **Du arbeitest in einem Monorepo** (Turborepo, pnpm/yarn-Workspaces, Lerna) | Backend- und Frontend-Domänen werden in einem Lauf mit getrennten Prompts analysiert. `apps/*/` und `packages/*/` durchläuft das Tool automatisch, und die Rules pro Stack landen unter `70.domains/{type}/`. |
|
|
317
|
+
| **Beitrag zu OSS oder einfach Experimentieren** | Die Ausgabe ist gitignore-freundlich: `claudeos-core/` ist dein lokales Arbeitsverzeichnis, ausgeliefert werden nur `CLAUDE.md` und `.claude/`. Bricht ein Lauf ab, kannst du fortsetzen. Erneutes Ausführen ist idempotent, und manuelle Edits an Rules überleben ohne `--force`. |
|
|
326
318
|
|
|
327
|
-
**Nicht passend, wenn
|
|
319
|
+
**Nicht passend, wenn** du ein One-size-fits-all-Bundle aus Agents, Skills und Rules erwartest, das ohne Scan-Schritt sofort einsatzfähig ist (welches Tool wozu passt, beleuchtet [docs/de/comparison.md](docs/de/comparison.md)). Ebenfalls unpassend, wenn dein Projekt zu keinem der [unterstützten Stacks](#supported-stacks) gehört oder du nur eine einzelne `CLAUDE.md` brauchst. Im letzten Fall reicht das eingebaute `claude /init`; ein zusätzliches Tool zu installieren lohnt sich nicht.
|
|
328
320
|
|
|
329
321
|
---
|
|
330
322
|
|
|
331
|
-
## Wie funktioniert
|
|
323
|
+
## Wie funktioniert es?
|
|
332
324
|
|
|
333
|
-
ClaudeOS-Core
|
|
325
|
+
ClaudeOS-Core dreht den üblichen Claude-Code-Workflow um:
|
|
334
326
|
|
|
335
327
|
```
|
|
336
|
-
Üblich:
|
|
337
|
-
Hier: Code
|
|
328
|
+
Üblich: You describe project → Claude guesses your stack → Claude writes docs
|
|
329
|
+
Hier: Code reads your stack → Code passes confirmed facts to Claude → Claude writes docs from facts
|
|
338
330
|
```
|
|
339
331
|
|
|
340
|
-
Die Pipeline läuft in **drei
|
|
332
|
+
Die Pipeline läuft in **drei Phasen**; vor und nach dem LLM-Aufruf übernimmt jeweils Code:
|
|
341
333
|
|
|
342
|
-
**1.
|
|
334
|
+
**1. Step A — Scanner (deterministisch, ohne LLM).** Ein Node.js-Scanner durchläuft den Projekt-Root, liest `package.json`, `build.gradle`, `pom.xml` und `pyproject.toml`, parst `.env*`-Dateien und maskiert dabei sensible Variablen wie `PASSWORD/SECRET/TOKEN/JWT_SECRET/...`. Anschließend klassifiziert er das Architekturmuster (5 Java-Patterns A/B/C/D/E, Kotlin CQRS oder Multi-Module, Next.js App- gegenüber Pages-Router, FSD, Components-Pattern), erkennt Domänen und baut eine explizite Allowlist aller tatsächlich existierenden Quellpfade. Das Ergebnis landet in `project-analysis.json`, der Single Source of Truth für alles, was danach kommt.
|
|
343
335
|
|
|
344
|
-
**2.
|
|
345
|
-
- **Pass 1** liest repräsentative Dateien
|
|
346
|
-
- **Pass 2**
|
|
347
|
-
- **Pass 3** schreibt `CLAUDE.md
|
|
348
|
-
- **Pass 4**
|
|
336
|
+
**2. Step B — 4-Pass-Pipeline mit Claude (gebunden an die Fakten aus Step A).**
|
|
337
|
+
- **Pass 1** liest pro Domain-Gruppe repräsentative Dateien und extrahiert dort jeweils etwa 50 bis 100 Konventionen: Response-Wrapper, Logging-Bibliotheken, Error-Handling, Naming-Konventionen, Test-Patterns. Der Pass läuft einmal pro Domain-Gruppe (`max 4 domains, 40 files per group`), dadurch läuft der Kontext nie über.
|
|
338
|
+
- **Pass 2** fasst alle Domain-Analysen zu einem projektweiten Bild zusammen. Bei Widersprüchen gewinnt jeweils die dominante Konvention.
|
|
339
|
+
- **Pass 3** schreibt `CLAUDE.md`, `.claude/rules/`, `claudeos-core/standard/`, Skills und Guides. Der Pass ist in Stages aufgeteilt (`3a` Facts → `3b-core/3b-N` Rules und Standards → `3c-core/3c-N` Skills und Guides → `3d-aux` Database und MCP-Guide), damit jeder Stage-Prompt ins Kontextfenster des LLM passt, auch bei großer `pass2-merged.json`. Hat ein Projekt mindestens 16 Domänen, werden 3b und 3c zusätzlich in Batches mit höchstens 15 Domänen unterteilt.
|
|
340
|
+
- **Pass 4** legt den L4-Memory-Layer an (`decision-log.md`, `failure-patterns.md`, `compaction.md`, `auto-rule-update.md`) und ergänzt die universellen Scaffold-Rules. Pass 4 darf `CLAUDE.md` **unter keinen Umständen verändern**. Maßgeblich bleibt Section 8 aus Pass 3.
|
|
349
341
|
|
|
350
|
-
**3.
|
|
351
|
-
- `claude-md-validator`
|
|
352
|
-
- `content-validator`
|
|
353
|
-
- `pass-json-validator`
|
|
354
|
-
- `plan-validator`
|
|
355
|
-
- `sync-checker`
|
|
342
|
+
**3. Step C — Verifikation (deterministisch, ohne LLM).** Fünf Validatoren prüfen das Ergebnis:
|
|
343
|
+
- `claude-md-validator` führt 25 strukturelle Checks an `CLAUDE.md` durch (8 Sections, H3/H4-Counts, Eindeutigkeit der Memory-Dateien, T1-Invariante für die kanonischen Headings). Der Validator ist sprachunabhängig und liefert unabhängig von `--lang` dasselbe Urteil.
|
|
344
|
+
- `content-validator` deckt 10 inhaltliche Checks ab. Dazu zählen die Pfad-Verifikation (`STALE_PATH` fängt erfundene `src/...`-Referenzen ab) und die Erkennung von MANIFEST-Drift.
|
|
345
|
+
- `pass-json-validator` prüft die JSON-Wohlgeformtheit der Pässe 1, 2, 3 und 4 sowie die stack-abhängige Section-Anzahl.
|
|
346
|
+
- `plan-validator` deckt die Konsistenz zwischen Plan und Disk ab. Der Validator ist Legacy und ist seit v2.1.0 weitgehend ein No-op.
|
|
347
|
+
- `sync-checker` prüft über sieben getrackte Verzeichnisse hinweg, ob Disk und `sync-map.json` übereinstimmen.
|
|
356
348
|
|
|
357
|
-
|
|
349
|
+
Die drei Severity-Stufen `fail`, `warn` und `advisory` sorgen dafür, dass Warnings die CI nicht wegen LLM-Halluzinationen blockieren, die du selbst beheben kannst.
|
|
358
350
|
|
|
359
|
-
Die Invariante, die alles zusammenhält: **Claude darf nur Pfade zitieren, die
|
|
351
|
+
Die zentrale Invariante, die alles zusammenhält: **Claude darf nur Pfade zitieren, die im Code tatsächlich existieren**, weil Step A eine endliche Allowlist übergibt. Versucht das LLM trotzdem, etwas zu erfinden (selten, aber bei manchen Seeds zu beobachten), fängt Step C es ab, bevor die Docs ausgeliefert werden.
|
|
360
352
|
|
|
361
|
-
Pass-Details, Marker-basiertes Resume, der Staged-Rules-Workaround für
|
|
353
|
+
Pro-Pass-Details, Marker-basiertes Resume, der Staged-Rules-Workaround für die `.claude/`-Sperre in Claude Code und die Interna der Stack-Erkennung stehen in [docs/de/architecture.md](docs/de/architecture.md).
|
|
362
354
|
|
|
363
355
|
---
|
|
364
356
|
|
|
365
357
|
## Supported Stacks
|
|
366
358
|
|
|
367
|
-
12 Stacks,
|
|
359
|
+
12 Stacks, automatisch aus deinen Projektdateien erkannt:
|
|
368
360
|
|
|
369
361
|
**Backend:** Java/Spring Boot · Kotlin/Spring Boot · Node/Express · Node/Fastify · Node/NestJS · Python/Django · Python/FastAPI · Python/Flask
|
|
370
362
|
|
|
371
363
|
**Frontend:** Node/Next.js · Node/Vite · Angular · Vue/Nuxt
|
|
372
364
|
|
|
373
|
-
Multi-Stack-Projekte
|
|
365
|
+
Auch Multi-Stack-Projekte funktionieren ohne Zusatzaufwand, etwa ein Spring-Boot-Backend zusammen mit einem Next.js-Frontend.
|
|
374
366
|
|
|
375
|
-
Erkennungsregeln und
|
|
367
|
+
Erkennungsregeln und die Felder, die jeder Scanner extrahiert, beschreibt [docs/de/stacks.md](docs/de/stacks.md).
|
|
376
368
|
|
|
377
369
|
---
|
|
378
370
|
|
|
379
371
|
## Täglicher Workflow
|
|
380
372
|
|
|
381
|
-
Drei Befehle decken
|
|
373
|
+
Drei Befehle decken rund 95 Prozent aller Anwendungsfälle ab:
|
|
382
374
|
|
|
383
375
|
```bash
|
|
384
|
-
#
|
|
376
|
+
# Erstmals auf einem Projekt
|
|
385
377
|
npx claudeos-core init
|
|
386
378
|
|
|
387
|
-
#
|
|
379
|
+
# Nach manuellen Änderungen an Standards oder Rules
|
|
388
380
|
npx claudeos-core lint
|
|
389
381
|
|
|
390
|
-
# Health-Check (vor Commits oder in CI
|
|
382
|
+
# Health-Check (vor Commits oder in der CI)
|
|
391
383
|
npx claudeos-core health
|
|
392
384
|
```
|
|
393
385
|
|
|
394
|
-
|
|
395
|
-
|
|
396
|
-
```bash
|
|
397
|
-
# Failure-Patterns-Log verdichten (regelmäßig ausführen)
|
|
398
|
-
npx claudeos-core memory compact
|
|
399
|
-
|
|
400
|
-
# Häufige Failure-Patterns zu Vorschlagsregeln hochstufen
|
|
401
|
-
npx claudeos-core memory propose-rules
|
|
402
|
-
```
|
|
403
|
-
|
|
404
|
-
Die vollständigen Optionen jedes Befehls finden Sie in [docs/de/commands.md](docs/de/commands.md).
|
|
386
|
+
Die vollständigen Optionen pro Befehl listet [docs/de/commands.md](docs/de/commands.md). Die Memory-Layer-Befehle (`memory compact`, `memory propose-rules`) beschreibt der Abschnitt [Memory Layer](#memory-layer-optional-für-langlebige-projekte) weiter unten.
|
|
405
387
|
|
|
406
388
|
---
|
|
407
389
|
|
|
408
|
-
## Was
|
|
390
|
+
## Was es anders macht
|
|
409
391
|
|
|
410
|
-
Die meisten Claude
|
|
392
|
+
Die meisten Documentation-Tools für Claude Code generieren aus einer Beschreibung: Du erzählst dem Tool, was zu tun ist, und das Tool sagt es Claude weiter. ClaudeOS-Core geht direkt vom Quellcode aus. Erst liest das Tool, dann reicht es nur die bestätigten Fakten an Claude durch, und Claude schreibt ausschließlich darüber.
|
|
411
393
|
|
|
412
|
-
|
|
394
|
+
Daraus folgen drei konkrete Effekte:
|
|
413
395
|
|
|
414
|
-
1. **Deterministische Stack-Erkennung.** Gleiches Projekt
|
|
415
|
-
2. **Keine erfundenen Pfade.** Der Pass-3-Prompt
|
|
416
|
-
3. **Multi-Stack-fähig.** Backend- und Frontend-Domänen verwenden im selben Lauf
|
|
396
|
+
1. **Deterministische Stack-Erkennung.** Gleiches Projekt plus gleicher Code ergibt gleiche Ausgabe. Es gibt kein "diesmal hat Claude anders gewürfelt".
|
|
397
|
+
2. **Keine erfundenen Pfade.** Der Pass-3-Prompt führt jeden erlaubten Quellpfad explizit auf, deshalb kann Claude nichts zitieren, was im Code nicht existiert.
|
|
398
|
+
3. **Multi-Stack-fähig.** Backend- und Frontend-Domänen verwenden im selben Lauf jeweils eigene Analyse-Prompts.
|
|
417
399
|
|
|
418
|
-
Einen
|
|
400
|
+
Einen Side-by-Side-Vergleich zum Scope anderer Tools liefert [docs/de/comparison.md](docs/de/comparison.md). Es geht dort um **was jedes Tool tut**, nicht um **welches besser ist**. Die meisten ergänzen sich gegenseitig.
|
|
419
401
|
|
|
420
402
|
---
|
|
421
403
|
|
|
422
|
-
## Verifikation (nach
|
|
404
|
+
## Verifikation (nach Generierung)
|
|
423
405
|
|
|
424
|
-
|
|
406
|
+
Sobald Claude die Docs geschrieben hat, übernimmt wieder der Code und prüft sie. Fünf separate Validatoren stehen bereit:
|
|
425
407
|
|
|
426
|
-
| Validator |
|
|
408
|
+
| Validator | Prüfgegenstand | Ausgeführt von |
|
|
427
409
|
|---|---|---|
|
|
428
|
-
| `claude-md-validator` |
|
|
429
|
-
| `content-validator` |
|
|
430
|
-
| `pass-json-validator` | Pass
|
|
431
|
-
| `plan-validator` |
|
|
432
|
-
| `sync-checker` |
|
|
410
|
+
| `claude-md-validator` | strukturelle Invarianten der CLAUDE.md (8 Sections, sprachunabhängig) | `claudeos-core lint` |
|
|
411
|
+
| `content-validator` | Pfadangaben existieren tatsächlich; Konsistenz des Manifests | `health` (advisory) |
|
|
412
|
+
| `pass-json-validator` | Ausgaben aus Pass 1 / 2 / 3 / 4 sind wohlgeformtes JSON | `health` (warn) |
|
|
413
|
+
| `plan-validator` | gespeicherter Plan stimmt mit dem Stand auf der Disk überein | `health` (fail-on-error) |
|
|
414
|
+
| `sync-checker` | Dateien auf der Disk passen zu den Einträgen in `sync-map.json` (Erkennung von verwaisten oder unregistrierten Dateien) | `health` (fail-on-error) |
|
|
433
415
|
|
|
434
|
-
Ein `health-checker` orchestriert die vier
|
|
416
|
+
Ein `health-checker` orchestriert die vier Runtime-Validatoren in den drei Severity-Stufen fail, warn und advisory und liefert einen für die CI passenden Exit-Code zurück. Den `claude-md-validator` startest du separat über den `lint`-Befehl, denn struktureller Drift ist keine weiche Warnung, sondern ein Signal für ein Re-Init. Du kannst den Check jederzeit auslösen:
|
|
435
417
|
|
|
436
418
|
```bash
|
|
437
419
|
npx claudeos-core health
|
|
438
420
|
```
|
|
439
421
|
|
|
440
|
-
|
|
422
|
+
Was jeder einzelne Validator im Detail prüft, beschreibt [docs/de/verification.md](docs/de/verification.md).
|
|
441
423
|
|
|
442
424
|
---
|
|
443
425
|
|
|
444
|
-
## Memory Layer (optional, für
|
|
426
|
+
## Memory Layer (optional, für langlebige Projekte)
|
|
445
427
|
|
|
446
|
-
|
|
428
|
+
Über die Scaffolding-Pipeline hinaus legt ClaudeOS-Core einen `claudeos-core/memory/`-Ordner an, sobald der Projektkontext über eine einzelne Session hinaus tragen soll. Der Layer ist optional. Wenn dir `CLAUDE.md` plus Rules genügen, kannst du ihn ignorieren.
|
|
447
429
|
|
|
448
|
-
|
|
449
|
-
- `failure-patterns.md` — wiederkehrende Fehler mit Frequenz-/Wichtigkeitswerten
|
|
450
|
-
- `compaction.md` — wie Memory mit der Zeit automatisch verdichtet wird
|
|
451
|
-
- `auto-rule-update.md` — Muster, die zu neuen Regeln werden sollten
|
|
430
|
+
Vier Dateien, alle von Pass 4 geschrieben:
|
|
452
431
|
|
|
453
|
-
|
|
432
|
+
- `decision-log.md`: Append-only-Log nach dem Muster "warum X statt Y", geseedet aus `pass2-merged.json`.
|
|
433
|
+
- `failure-patterns.md`: wiederkehrende Fehler mit Frequenz- und Importance-Scores.
|
|
434
|
+
- `compaction.md`: wie der Memory-Bereich im Lauf der Zeit automatisch komprimiert wird.
|
|
435
|
+
- `auto-rule-update.md`: Patterns, die später eigene Rules werden sollten.
|
|
454
436
|
|
|
455
|
-
|
|
437
|
+
Zwei Befehle pflegen diesen Layer auf Dauer:
|
|
438
|
+
|
|
439
|
+
```bash
|
|
440
|
+
# Failure-Patterns-Log komprimieren (regelmäßig ausführen)
|
|
441
|
+
npx claudeos-core memory compact
|
|
442
|
+
|
|
443
|
+
# Häufige Failure-Patterns zu Rule-Vorschlägen befördern
|
|
444
|
+
npx claudeos-core memory propose-rules
|
|
445
|
+
```
|
|
446
|
+
|
|
447
|
+
Memory-Modell und Lifecycle erläutert [docs/de/memory-layer.md](docs/de/memory-layer.md).
|
|
456
448
|
|
|
457
449
|
---
|
|
458
450
|
|
|
459
451
|
## FAQ
|
|
460
452
|
|
|
461
453
|
**F: Brauche ich einen Claude-API-Key?**
|
|
462
|
-
A: Nein. ClaudeOS-Core
|
|
454
|
+
A: Nein. ClaudeOS-Core greift auf deine bestehende Claude-Code-Installation zurück und schickt Prompts an `claude -p` auf deinem Rechner. Zusätzliche Accounts sind nicht nötig.
|
|
463
455
|
|
|
464
|
-
**F: Überschreibt das meine
|
|
465
|
-
A:
|
|
456
|
+
**F: Überschreibt das Tool meine vorhandene CLAUDE.md oder die `.claude/rules/`?**
|
|
457
|
+
A: Beim ersten Lauf auf einem frischen Projekt werden sie angelegt. Ohne `--force` bleiben deine Edits beim erneuten Ausführen erhalten, weil das Tool die Pass-Marker des vorherigen Laufs erkennt und die jeweiligen Pässe überspringt. Mit `--force` wird alles gelöscht und neu erzeugt, deine Änderungen gehen dabei verloren. Genau das ist die Bedeutung von `--force`. Mehr dazu in [docs/de/safety.md](docs/de/safety.md).
|
|
466
458
|
|
|
467
|
-
**F: Mein Stack wird nicht unterstützt. Kann ich einen
|
|
468
|
-
A: Ja.
|
|
459
|
+
**F: Mein Stack wird nicht unterstützt. Kann ich einen ergänzen?**
|
|
460
|
+
A: Ja. Für einen neuen Stack brauchst du etwa drei Prompt-Templates und einen Domain-Scanner. Den 8-Schritt-Leitfaden findest du in [CONTRIBUTING.md](CONTRIBUTING.md).
|
|
469
461
|
|
|
470
|
-
**F: Wie
|
|
471
|
-
A: `npx claudeos-core init --lang de`. 10 Sprachen
|
|
462
|
+
**F: Wie erzeuge ich Docs auf Deutsch (oder in einer anderen Sprache)?**
|
|
463
|
+
A: Über `npx claudeos-core init --lang de`. Unterstützt sind 10 Sprachen: en, ko, ja, zh-CN, es, vi, hi, ru, fr, de.
|
|
472
464
|
|
|
473
465
|
**F: Funktioniert das mit Monorepos?**
|
|
474
|
-
A: Ja
|
|
466
|
+
A: Ja. Der Stack-Detector erkennt Turborepo (`turbo.json`), pnpm-Workspaces (`pnpm-workspace.yaml`), Lerna (`lerna.json`) sowie npm- und yarn-Workspaces (`package.json#workspaces`). Jede App bekommt ihre eigene Analyse. Andere Monorepo-Layouts wie NX werden nicht eigens erkannt, doch die generischen Patterns `apps/*/` und `packages/*/` greifen die Stack-Scanner trotzdem auf.
|
|
475
467
|
|
|
476
|
-
**F: Was, wenn Claude Code
|
|
477
|
-
A:
|
|
468
|
+
**F: Was, wenn Claude Code Rules schreibt, mit denen ich nicht einverstanden bin?**
|
|
469
|
+
A: Bearbeite sie direkt. Anschließend lässt du `npx claudeos-core lint` laufen, um zu prüfen, ob die CLAUDE.md weiterhin strukturell gültig ist. Bei späteren `init`-Läufen ohne `--force` bleiben deine Änderungen erhalten, denn der Resume-Mechanismus überspringt jeden Pass, dessen Marker bereits existiert.
|
|
478
470
|
|
|
479
471
|
**F: Wo melde ich Bugs?**
|
|
480
|
-
A: [GitHub Issues](https://github.com/claudeos-core/claudeos-core/issues).
|
|
472
|
+
A: Über die [GitHub Issues](https://github.com/claudeos-core/claudeos-core/issues). Sicherheitsrelevante Themen behandelt [SECURITY.md](SECURITY.md).
|
|
473
|
+
|
|
474
|
+
---
|
|
475
|
+
|
|
476
|
+
## Wenn das Zeit gespart hat
|
|
477
|
+
|
|
478
|
+
Ein ⭐ auf GitHub erhöht die Sichtbarkeit des Projekts und hilft anderen, es zu finden. Issues, PRs und Beiträge zu Stack-Templates sind alle willkommen. Details stehen in [CONTRIBUTING.md](CONTRIBUTING.md).
|
|
481
479
|
|
|
482
480
|
---
|
|
483
481
|
|
|
484
|
-
##
|
|
482
|
+
## Dokumentation
|
|
485
483
|
|
|
486
|
-
| Thema |
|
|
484
|
+
| Thema | Hier nachlesen |
|
|
487
485
|
|---|---|
|
|
488
486
|
| Wie die 4-Pass-Pipeline funktioniert (tiefer als das Diagramm) | [docs/de/architecture.md](docs/de/architecture.md) |
|
|
489
|
-
| Visuelle Diagramme (Mermaid)
|
|
487
|
+
| Visuelle Diagramme der Architektur (Mermaid) | [docs/de/diagrams.md](docs/de/diagrams.md) |
|
|
490
488
|
| Stack-Erkennung — wonach jeder Scanner sucht | [docs/de/stacks.md](docs/de/stacks.md) |
|
|
491
|
-
| Memory Layer — Decision
|
|
489
|
+
| Memory Layer — Decision-Logs und Failure-Patterns | [docs/de/memory-layer.md](docs/de/memory-layer.md) |
|
|
492
490
|
| Alle 5 Validatoren im Detail | [docs/de/verification.md](docs/de/verification.md) |
|
|
493
|
-
|
|
|
491
|
+
| Sämtliche CLI-Befehle und ihre Optionen | [docs/de/commands.md](docs/de/commands.md) |
|
|
494
492
|
| Manuelle Installation (ohne `npx`) | [docs/de/manual-installation.md](docs/de/manual-installation.md) |
|
|
495
493
|
| Scanner-Overrides — `.claudeos-scan.json` | [docs/de/advanced-config.md](docs/de/advanced-config.md) |
|
|
496
|
-
| Sicherheit:
|
|
497
|
-
| Vergleich mit ähnlichen Tools (Scope,
|
|
498
|
-
| Fehler und
|
|
494
|
+
| Sicherheit: was bei einem Re-Init erhalten bleibt | [docs/de/safety.md](docs/de/safety.md) |
|
|
495
|
+
| Vergleich mit ähnlichen Tools (Scope, keine Qualitätsbewertung) | [docs/de/comparison.md](docs/de/comparison.md) |
|
|
496
|
+
| Fehler und Recovery | [docs/de/troubleshooting.md](docs/de/troubleshooting.md) |
|
|
499
497
|
|
|
500
498
|
---
|
|
501
499
|
|
|
502
500
|
## Mitwirken
|
|
503
501
|
|
|
504
|
-
Beiträge willkommen
|
|
502
|
+
Beiträge sind willkommen, sei es durch zusätzliche Stack-Unterstützung, bessere Prompts oder Bugfixes. Details stehen in [CONTRIBUTING.md](CONTRIBUTING.md).
|
|
505
503
|
|
|
506
|
-
Verhaltenskodex und Sicherheitsrichtlinie
|
|
504
|
+
Verhaltenskodex und Sicherheitsrichtlinie liegen in [CODE_OF_CONDUCT.md](CODE_OF_CONDUCT.md) und [SECURITY.md](SECURITY.md).
|
|
507
505
|
|
|
508
|
-
##
|
|
506
|
+
## Lizenz
|
|
509
507
|
|
|
510
|
-
[ISC](LICENSE)
|
|
508
|
+
[ISC License](LICENSE). Frei für jeden Einsatzzweck, einschließlich kommerzieller Nutzung. © 2025–2026 ClaudeOS-Core contributors.
|
|
511
509
|
|
|
512
510
|
---
|
|
513
511
|
|
|
514
|
-
<sub>
|
|
512
|
+
<sub>Gepflegt vom Team [claudeos-core](https://github.com/claudeos-core). Issues und PRs landen unter <https://github.com/claudeos-core/claudeos-core>.</sub>
|