claudeos-core 2.4.1 → 2.4.3

package/README.de.md

@@ -7,58 +7,40 @@
 [![license](https://img.shields.io/npm/l/claudeos-core.svg?color=blue)](LICENSE)
 [![downloads](https://img.shields.io/npm/dm/claudeos-core.svg?logo=npm&color=blue&label=downloads)](https://www.npmjs.com/package/claudeos-core)
 
-**Sorgen Sie dafür, dass Claude Code beim ersten Versuch den Konventionen IHRES Projekts folgt — nicht generischen Defaults.**
-
-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.
-
-Funktioniert auf [**12 Stacks**](#supported-stacks) (inklusive Monorepos) — ein einziger `npx`-Befehl, ohne Konfiguration, resume-sicher, idempotent.
+**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.**
 
 ```bash
 npx claudeos-core init
 ```
 
+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.
+
 [🇺🇸 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)
 
 ---
 
-## Worum geht es?
-
-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:
+## Was ist das?
 
-- Ihr Team verwendet **MyBatis**, aber Claude generiert JPA-Repositories.
-- Ihr Response-Wrapper ist `ApiResponse.ok()`, aber Claude schreibt `ResponseEntity.success()`.
-- Ihre Pakete sind layer-first (`controller/order/`), aber Claude erstellt domain-first (`order/controller/`).
-- Ihre Fehler laufen durch zentrale Middleware, aber Claude verstreut `try/catch` in jedem Endpoint.
+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.
 
-Sie hätten gerne pro Projekt einen `.claude/rules/`-Satz — Claude Code lädt ihn automatisch in jeder Sitzung — aber diese Regeln für jedes neue Repo per Hand zu schreiben dauert Stunden, und sie driften, sobald sich der Code weiterentwickelt.
+**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.
 
-**ClaudeOS-Core schreibt sie für Sie, aus Ihrem tatsächlichen Quellcode.** Ein deterministischer Node.js-Scanner liest zuerst Ihr Projekt (Stack, ORM, Paket-Layout, Konventionen, Dateipfade). Anschließend verwandelt eine 4-Pass-Claude-Pipeline die extrahierten Fakten in einen vollständigen Dokumentationssatz:
+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).)
 
-- **`CLAUDE.md`** — der Projekt-Index, den Claude in jeder Sitzung liest
-- **`.claude/rules/`** — automatisch geladene Regeln pro Kategorie (`00.core` / `10.backend` / `20.frontend` / `30.security-db` / `40.infra` / `60.memory` / `70.domains` / `80.verification`)
-- **`claudeos-core/standard/`** — Referenz-Dokumente (das „Warum" hinter jeder Regel)
-- **`claudeos-core/skills/`** — wiederverwendbare Muster (CRUD-Scaffolding, Seitentemplates)
-- **`claudeos-core/memory/`** — Decision-Log + Failure-Patterns, die mit dem Projekt mitwachsen
-
-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.
-
-```
-Vorher:  Sie → Claude Code → "allgemein guter" Code → manuelle Korrekturen
-Nachher: Sie → Claude Code → Code, der zu IHREM Projekt passt → einsetzbar
-```
+Für langlebige Projekte legt das Tool außerdem einen separaten [Memory Layer](#memory-layer-optional-für-langlebige-projekte) an.
 
 ---
 
-## In einem realen Projekt sehen
+## Auf einem echten Projekt sehen
 
-Ausgeführt auf [`spring-boot-realworld-example-app`](https://github.com/gothinkster/spring-boot-realworld-example-app) — Java 11 · Spring Boot 2.6 · MyBatis · SQLite · 187 source files. Ergebnis: **75 generated files**, Gesamtdauer **53 Minuten**, alle Validatoren ✅.
+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.
 
 <p align="center">
   <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">
 </p>
 
 <details>
-<summary><strong>📺 Terminal-Ausgabe (Textversion, zum Suchen & Kopieren)</strong></summary>
+<summary><strong>Terminalausgabe (Textfassung, zum Suchen und Kopieren)</strong></summary>
 
 ```text
 ╔════════════════════════════════════════════════════╗
@@ -93,18 +75,18 @@ Ausgeführt auf [`spring-boot-realworld-example-app`](https://github.com/gothink
     [██████████░░░░░░░░░░] 50% (2/4)
 
 [6] Pass 3 — Generating all files...
-    🚀 Pass 3 split mode (3a → 3b → 3c → 3d-aux)
+    Pass 3 split mode (3a → 3b → 3c → 3d-aux)
     ✅ 3a complete (2m 57s)            — pass3a-facts.md (187-path allowlist)
     ✅ 3b complete (18m 49s)           — CLAUDE.md + 19 standards + 20 rules
     ✅ 3c complete (12m 35s)           — 13 skills + 9 guides
     ✅ 3d-aux complete (3m 18s)        — database/ + mcp-guide/
-    🎉 Pass 3 split complete: 4/4 stages successful
+    Pass 3 split complete: 4/4 stages successful
     [███████████████░░░░░] 75% (3/4)
 
 [7] Pass 4 — Memory scaffolding...
-    📦 Pass 4 staged-rules: 6 rule files moved to .claude/rules/
+    Pass 4 staged-rules: 6 rule files moved to .claude/rules/
     ✅ Pass 4 complete (5m)
-       📋 Gap-fill: all 12 expected files already present
+       Gap-fill: all 12 expected files already present
     [████████████████████] 100% (4/4)
 
 ╔═══════════════════════════════════════╗
@@ -133,7 +115,7 @@ Ausgeführt auf [`spring-boot-realworld-example-app`](https://github.com/gothink
 </details>
 
 <details>
-<summary><strong>📄 Was in Ihrer <code>CLAUDE.md</code> landet (echter Auszug — Section 1 + 2)</strong></summary>
+<summary><strong>Was tatsächlich in deiner <code>CLAUDE.md</code> landet (echter Auszug, Section 1 + 2)</strong></summary>
 
 ```markdown
 # CLAUDE.md — spring-boot-realworld-example-app
@@ -142,7 +124,7 @@ Ausgeführt auf [`spring-boot-realworld-example-app`](https://github.com/gothink
 > Java 11 + Spring Boot 2.6, exposing both REST and GraphQL endpoints
 > over a hexagonal MyBatis persistence layer.
 
-## 1. Role Definition
+#### 1. Role Definition
 
 As the senior developer for this repository, you are responsible for
 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
 (ports & adapters) architecture, with a CQRS-lite read/write split inside
 an XML-driven MyBatis persistence layer and JWT-based authentication.
 
-## 2. Project Overview
+#### 2. Project Overview
 
 | Item | Value |
 |---|---|
@@ -166,12 +148,12 @@ an XML-driven MyBatis persistence layer and JWT-based authentication.
 | Test Stack | JUnit Jupiter 5, Mockito, AssertJ, rest-assured, spring-mock-mvc |
 ```
 
-Jeder Wert oben — die genauen Dependency-Koordinaten, der Dateiname `dev.db`, der Migrationsname `V1__create_tables.sql`, „no JPA" — wird vom Scanner aus `build.gradle` / `application.properties` / dem Quellbaum extrahiert, bevor Claude die Datei schreibt. Nichts wird geraten.
+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.
 
 </details>
 
 <details>
-<summary><strong>🛡️ Eine real automatisch geladene Regel (<code>.claude/rules/10.backend/01.controller-rules.md</code>)</strong></summary>
+<summary><strong>Eine echte, automatisch geladene Rule (<code>.claude/rules/10.backend/01.controller-rules.md</code>)</strong></summary>
 
 ````markdown
 ---
@@ -179,9 +161,9 @@ paths:
   - "**/*"
 ---
 
-# Controller Rules
+#### Controller Rules
 
-## REST (`io.spring.api.*`)
+##### REST (`io.spring.api.*`)
 
 - Controllers are the SOLE response wrapper for HTTP — no aggregator/facade above them.
   Return `ResponseEntity<?>` or a body Spring serializes via `JacksonCustomizations`.
@@ -194,13 +176,13 @@ paths:
 - Let exceptions propagate to `io.spring.api.exception.CustomizeExceptionHandler`
   (`@ControllerAdvice`). Do NOT `try/catch` business exceptions inside the controller.
 
-## GraphQL (`io.spring.graphql.*`)
+##### GraphQL (`io.spring.graphql.*`)
 
 - DGS components (`@DgsComponent`) are the sole GraphQL response wrappers.
   Use `@DgsQuery` / `@DgsData` / `@DgsMutation`.
 - Resolve the current user via `io.spring.graphql.SecurityUtil.getCurrentUser()`.
 
-## Examples
+##### Examples
 
 ✅ Correct:
 ```java
@@ -228,15 +210,15 @@ public ResponseEntity<?> create(@RequestBody NewArticleParam p) {
 ```
 ````
 
-Der Glob `paths: ["**/*"]` bedeutet, dass Claude Code diese Regel automatisch lädt, sobald Sie eine beliebige Datei im Projekt bearbeiten. Jeder Klassenname, Paketpfad und Exception-Handler in der Regel stammt direkt aus dem gescannten Quellcode — einschließlich des tatsächlichen `CustomizeExceptionHandler` und `JacksonCustomizations` des Projekts.
+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.
 
 </details>
 
 <details>
-<summary><strong>🧠 Ein automatisch generierter <code>decision-log.md</code>-Seed (echter Auszug)</strong></summary>
+<summary><strong>Ein automatisch erzeugter Seed für <code>decision-log.md</code> (echter Auszug)</strong></summary>
 
 ```markdown
-## 2026-04-26 — Hexagonal ports & adapters with MyBatis-only persistence
+#### 2026-04-26 — Hexagonal ports & adapters with MyBatis-only persistence
 
 - **Context:** `io.spring.core.*` exposes `*Repository` ports (e.g.,
   `io.spring.core.article.ArticleRepository`) implemented by
@@ -255,260 +237,276 @@ Der Glob `paths: ["**/*"]` bedeutet, dass Claude Code diese Regel automatisch l
   split the persistence model.
 ```
 
-Pass 4 befüllt `decision-log.md` mit den aus `pass2-merged.json` extrahierten Architekturentscheidungen, damit zukünftige Sitzungen sich daran erinnern, _warum_ die Codebasis so aussieht, wie sie aussieht — nicht nur _wie_ sie aussieht. Jede Option („JPA/Hibernate", „MyBatis-Plus") und jede Konsequenz ist im tatsächlichen Dependency-Block der `build.gradle` verankert.
+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.
 
 </details>
 
 ---
 
-## Quick Start
+## Getestet auf
 
-**Voraussetzungen:** Node.js 18+, [Claude Code](https://docs.anthropic.com/en/docs/claude-code) installiert und authentifiziert.
+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.
+
+| Projekt | Stack | Scanned → Generated | Status |
+|---|---|---|---|
+| [`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 |
+
+---
+
+## Schnellstart
+
+**Voraussetzungen:** Node.js 18 oder neuer und ein installiertes, authentifiziertes [Claude Code](https://docs.anthropic.com/en/docs/claude-code).
 
 ```bash
-# 1. In das Projekt-Root wechseln
+# 1. In den Projekt-Root wechseln
 cd my-spring-boot-project
 
-# 2. init ausführen (analysiert den Code und bittet Claude, die Regeln zu schreiben)
+# 2. init starten (analysiert deinen Code und lässt Claude die Rules schreiben)
 npx claudeos-core init
 
-# 3. Fertig. Claude Code öffnen und loslegen — Ihre Regeln sind bereits geladen.
+# 3. Fertig. Öffne Claude Code und leg los — die Rules sind bereits geladen.
 ```
 
-**Was Sie nach Abschluss von `init` erhalten:**
+Nach Abschluss von `init` findest du folgende Struktur vor:
 
 ```
 your-project/
 ├── .claude/
-│   └── rules/                    ← Auto-loaded by Claude Code
-│       ├── 00.core/              (general rules — naming, architecture)
-│       ├── 10.backend/           (backend stack rules, if any)
-│       ├── 20.frontend/          (frontend stack rules, if any)
-│       ├── 30.security-db/       (security & DB conventions)
-│       ├── 40.infra/             (env, logging, CI/CD)
-│       ├── 50.sync/              (doc-sync reminders — rules only)
-│       ├── 60.memory/            (memory rules — Pass 4, rules only)
-│       ├── 70.domains/{type}/    (per-domain rules, type = backend|frontend)
-│       └── 80.verification/      (testing strategy + build verification reminders)
+│   └── rules/                    ← wird von Claude Code automatisch geladen
+│       ├── 00.core/              (allgemeine Rules: Naming, Architektur)
+│       ├── 10.backend/           (Backend-Stack-Rules, falls vorhanden)
+│       ├── 20.frontend/          (Frontend-Stack-Rules, falls vorhanden)
+│       ├── 30.security-db/       (Konventionen für Security und Datenbank)
+│       ├── 40.infra/             (env, Logging, CI/CD)
+│       ├── 50.sync/              (Hinweise zur Doc-Synchronisation, nur in rules)
+│       ├── 60.memory/            (Memory-Rules aus Pass 4, nur in rules)
+│       ├── 70.domains/{type}/    (Rules pro Domäne, type = backend|frontend)
+│       └── 80.verification/      (Teststrategie und Hinweise zur Build-Verifikation)
 ├── claudeos-core/
-│   ├── standard/                 ← Reference docs (mirror category structure)
-│   │   ├── 00.core/              (project overview, architecture, naming)
-│   │   ├── 10.backend/           (backend reference — if backend stack)
-│   │   ├── 20.frontend/          (frontend reference — if frontend stack)
-│   │   ├── 30.security-db/       (security & DB reference)
-│   │   ├── 40.infra/             (env / logging / CI-CD reference)
-│   │   ├── 70.domains/{type}/    (per-domain reference)
-│   │   ├── 80.verification/      (build / startup / testing reference — standard only)
-│   │   └── 90.optional/          (stack-specific extras — standard only)
-│   ├── skills/                   (reusable patterns Claude can apply)
-│   ├── guide/                    (how-to guides for common tasks)
-│   ├── database/                 (schema overview, migration guide)
-│   ├── mcp-guide/                (MCP integration notes)
-│   └── memory/                   (decision log, failure patterns, compaction)
-└── CLAUDE.md                     (the index Claude reads first)
+│   ├── standard/                 ← Referenzdokumente, gespiegelt zur Kategoriestruktur
+│   │   ├── 00.core/              (Projektübersicht, Architektur, Naming)
+│   │   ├── 10.backend/           (Backend-Referenz, sofern Backend-Stack vorhanden)
+│   │   ├── 20.frontend/          (Frontend-Referenz, sofern Frontend-Stack vorhanden)
+│   │   ├── 30.security-db/       (Referenz für Security und Datenbank)
+│   │   ├── 40.infra/             (env / Logging / CI-CD-Referenz)
+│   │   ├── 70.domains/{type}/    (Referenz pro Domäne)
+│   │   ├── 80.verification/      (Referenz zu Build, Startup, Tests, nur in standard)
+│   │   └── 90.optional/          (stack-spezifische Extras, nur in standard)
+│   ├── skills/                   (wiederverwendbare Patterns, die Claude anwenden kann)
+│   ├── guide/                    (How-to-Guides für gängige Aufgaben)
+│   ├── database/                 (Schema-Übersicht, Migrationsleitfaden)
+│   ├── mcp-guide/                (Notizen zur MCP-Integration)
+│   └── memory/                   (Decision-Log, Failure-Patterns, Compaction)
+└── CLAUDE.md                     (der Index, den Claude zuerst liest)
 ```
 
-Kategorien, die zwischen `rules/` und `standard/` denselben Zahlen-Präfix teilen, repräsentieren denselben konzeptuellen Bereich (z. B. `10.backend` rules ↔ `10.backend` standards). Nur in `rules/` vorhandene Kategorien: `50.sync` (Doc-Sync-Erinnerungen) und `60.memory` (Pass 4 Memory). Nur in `standard/` vorhandene Kategorie: `90.optional` (stackspezifische Ergänzungen ohne Durchsetzung). Alle übrigen Präfixe (`00`, `10`, `20`, `30`, `40`, `70`, `80`) tauchen sowohl in `rules/` als auch in `standard/` auf. Claude Code kennt jetzt Ihr Projekt.
+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.
 
 ---
 
 ## Für wen ist das?
 
-| Sie sind... | Der Schmerzpunkt, den das Tool beseitigt |
+| Rolle | Schmerzpunkt, der wegfällt |
 |---|---|
-| **Solo-Entwickler**, der ein neues Projekt mit Claude Code beginnt | „Claude in jeder Sitzung meine Konventionen beibringen" — vorbei. `CLAUDE.md` + 8-Kategorien-`.claude/rules/` in einem einzigen Lauf generiert. |
-| **Team-Lead**, der gemeinsame Standards über mehrere Repos hinweg pflegt | `.claude/rules/` driften, wenn Leute Pakete umbenennen, ORMs wechseln oder Response-Wrapper ändern. ClaudeOS-Core synchronisiert deterministisch — gleicher Input, byte-identische Ausgabe, kein Diff-Rauschen. |
-| **Bereits Claude-Code-Nutzer**, aber das Korrigieren generierten Codes leid | Falscher Response-Wrapper, falsches Paket-Layout, JPA wo Sie MyBatis nutzen, verstreutes `try/catch` während Ihr Projekt zentrale Middleware verwendet. Der Scanner extrahiert Ihre echten Konventionen; jeder Claude-Pass läuft gegen eine explizite Pfad-Allowlist. |
-| **Onboarding in ein neues Repo** (bestehendes Projekt, Team-Beitritt) | `init` auf dem Repo ausführen und eine lebendige Architekturkarte erhalten: Stack-Tabelle in CLAUDE.md, schichtenweise Regeln mit ✅/❌-Beispielen, Decision-Log mit dem „Warum" hinter wesentlichen Entscheidungen (JPA vs. MyBatis, REST vs. GraphQL etc.). 5 Dateien lesen schlägt 5.000 Quelldateien lesen. |
-| **Arbeiten auf Koreanisch / Japanisch / Chinesisch / 7 weiteren Sprachen** | Die meisten Claude-Code-Regelgeneratoren sind Englisch-only. ClaudeOS-Core schreibt den vollständigen Satz in **10 Sprachen** (`en/ko/ja/zh-CN/es/vi/hi/ru/fr/de`) mit **byte-identischer struktureller Validierung** — gleiches `claude-md-validator`-Verdikt unabhängig von der Ausgabesprache. |
-| **Auf einem Monorepo arbeiten** (Turborepo, pnpm/yarn-Workspaces, Lerna) | Backend- und Frontend-Domänen werden in einem Lauf mit separaten Prompts analysiert; `apps/*/` und `packages/*/` werden automatisch durchlaufen; stackspezifische Regeln werden unter `70.domains/{type}/` emittiert. |
-| **OSS-Beitrag oder Experimente** | Die Ausgabe ist gitignore-freundlich — `claudeos-core/` ist Ihr lokales Arbeitsverzeichnis, nur `CLAUDE.md` + `.claude/` müssen ausgeliefert werden. Resume-sicher bei Unterbrechungen; idempotent bei erneutem Aufruf (Ihre manuellen Regeländerungen überleben ohne `--force`). |
+| **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. |
+| **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. |
+| **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. |
+| **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. |
+| **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. |
+| **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}/`. |
+| **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`. |
 
-**Nicht passend, wenn:** Sie ein One-Size-Fits-All-Preset-Bundle aus Agents/Skills/Rules wollen, das ohne Scan-Schritt am ersten Tag funktioniert (siehe [docs/de/comparison.md](docs/de/comparison.md), wo was hinpasst), Ihr Projekt noch nicht zu einem der [unterstützten Stacks](#supported-stacks) passt, oder Sie nur eine einzelne `CLAUDE.md` benötigen (das eingebaute `claude /init` reicht — keine Notwendigkeit, ein weiteres Tool zu installieren).
+**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.
 
 ---
 
-## Wie funktioniert das?
+## Wie funktioniert es?
 
-ClaudeOS-Core kehrt den üblichen Claude-Code-Workflow um:
+ClaudeOS-Core dreht den üblichen Claude-Code-Workflow um:
 
 ```
-Üblich:    Sie beschreiben das Projekt → Claude rät den Stack → Claude schreibt Docs
-Hier:      Code liest Ihren Stack → Code übergibt bestätigte Fakten an Claude → Claude schreibt Docs aus Fakten
+Üblich:    You describe project → Claude guesses your stack → Claude writes docs
+Hier:      Code reads your stack → Code passes confirmed facts to Claude → Claude writes docs from facts
 ```
 
-Die Pipeline läuft in **drei Stufen**, mit Code auf beiden Seiten des LLM-Aufrufs:
+Die Pipeline läuft in **drei Phasen**; vor und nach dem LLM-Aufruf übernimmt jeweils Code:
 
-**1. Schritt A — Scanner (deterministisch, kein LLM).** Ein Node.js-Scanner durchläuft Ihr Projekt-Root, liest `package.json` / `build.gradle` / `pom.xml` / `pyproject.toml`, parst `.env*`-Dateien (mit Sensitive-Variable-Redaction für `PASSWORD/SECRET/TOKEN/JWT_SECRET/...`), klassifiziert Ihr Architekturmuster (Javas 5 Muster A/B/C/D/E, Kotlin CQRS / Multi-Module, Next.js App- vs. Pages-Router, FSD, Components-Pattern), entdeckt Domänen und baut eine explizite Allowlist jedes existierenden Quelldateipfads. Ausgabe: `project-analysis.json` — die einzige Quelle der Wahrheit für alles, was folgt.
+**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.
 
-**2. Schritt B — 4-Pass-Claude-Pipeline (eingeschränkt durch die Fakten aus Schritt A).**
-- **Pass 1** liest repräsentative Dateien pro Domänengruppe und extrahiert ~50–100 Konventionen pro Domäne — Response-Wrapper, Logging-Bibliotheken, Error-Handling, Naming-Konventionen, Test-Pattern. Läuft einmal pro Domänengruppe (`max 4 domains, 40 files per group`), sodass der Kontext nie überläuft.
-- **Pass 2** führt alle domänenspezifischen Analysen zu einem projektweiten Bild zusammen und löst Widersprüche durch Wahl der dominanten Konvention auf.
-- **Pass 3** schreibt `CLAUDE.md` + `.claude/rules/` + `claudeos-core/standard/` + Skills + Guides — aufgeteilt in Stages (`3a` Facts → `3b-core/3b-N` Rules+Standards → `3c-core/3c-N` Skills+Guides → `3d-aux` Database+MCP-Guide), sodass jeder Stage-Prompt ins LLM-Context-Window passt, selbst wenn `pass2-merged.json` groß ist. Bei ≥16-Domänen-Projekten werden 3b/3c in Batches von ≤15 Domänen unterteilt.
-- **Pass 4** seedet die L4-Memory-Schicht (`decision-log.md`, `failure-patterns.md`, `compaction.md`, `auto-rule-update.md`) und ergänzt universelle Scaffold-Regeln. Pass 4 ist es **untersagt, `CLAUDE.md` zu modifizieren** — Section 8 von Pass 3 ist autoritativ.
+**2. Step B — 4-Pass-Pipeline mit Claude (gebunden an die Fakten aus Step A).**
+- **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.
+- **Pass 2** fasst alle Domain-Analysen zu einem projektweiten Bild zusammen. Bei Widersprüchen gewinnt jeweils die dominante Konvention.
+- **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.
+- **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.
 
-**3. Schritt C — Verifikation (deterministisch, kein LLM).** Fünf Validatoren prüfen die Ausgabe:
-- `claude-md-validator` — 25 strukturelle Prüfungen auf `CLAUDE.md` (8 Sections, H3/H4-Counts, Memory-File-Eindeutigkeit, T1-Canonical-Heading-Invariante). Sprachunabhängig: gleiches Verdikt unabhängig von `--lang`.
-- `content-validator` — 10 Content-Prüfungen, einschließlich Path-Claim-Verifikation (`STALE_PATH` fängt fabrizierte `src/...`-Referenzen ab) und MANIFEST-Drift-Erkennung.
-- `pass-json-validator` — Pass-1/2/3/4-JSON-Wohlgeformtheit + stack-bewusste Section-Counts.
-- `plan-validator` — Plan-↔-Disk-Konsistenz (Legacy, seit v2.1.0 weitgehend No-Op).
-- `sync-checker` — Disk-↔-`sync-map.json`-Registrierungskonsistenz über 7 nachverfolgte Verzeichnisse hinweg.
+**3. Step C — Verifikation (deterministisch, ohne LLM).** Fünf Validatoren prüfen das Ergebnis:
+- `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.
+- `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.
+- `pass-json-validator` prüft die JSON-Wohlgeformtheit der Pässe 1, 2, 3 und 4 sowie die stack-abhängige Section-Anzahl.
+- `plan-validator` deckt die Konsistenz zwischen Plan und Disk ab. Der Validator ist Legacy und ist seit v2.1.0 weitgehend ein No-op.
+- `sync-checker` prüft über sieben getrackte Verzeichnisse hinweg, ob Disk und `sync-map.json` übereinstimmen.
 
-Drei Schweregrad-Stufen (`fail` / `warn` / `advisory`), damit Warnungen CI niemals wegen LLM-Halluzinationen blockieren, die der Nutzer manuell beheben kann.
+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.
 
-Die Invariante, die alles zusammenhält: **Claude darf nur Pfade zitieren, die tatsächlich in Ihrem Code existieren**, weil Schritt A eine endliche Allowlist übergibt. Versucht das LLM trotzdem etwas zu erfinden (selten, aber bei bestimmten Seeds möglich), fängt Schritt C es ab, bevor die Docs ausgeliefert werden.
+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.
 
-Pass-Details, Marker-basiertes Resume, der Staged-Rules-Workaround für den Sensitive-Path-Block von Claude Codes `.claude/` und Stack-Erkennungs-Internals finden Sie in [docs/de/architecture.md](docs/de/architecture.md).
+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).
 
 ---
 
 ## Supported Stacks
 
-12 Stacks, die automatisch aus Ihren Projektdateien erkannt werden:
+12 Stacks, automatisch aus deinen Projektdateien erkannt:
 
 **Backend:** Java/Spring Boot · Kotlin/Spring Boot · Node/Express · Node/Fastify · Node/NestJS · Python/Django · Python/FastAPI · Python/Flask
 
 **Frontend:** Node/Next.js · Node/Vite · Angular · Vue/Nuxt
 
-Multi-Stack-Projekte (z. B. Spring-Boot-Backend + Next.js-Frontend) funktionieren ohne weitere Konfiguration.
+Auch Multi-Stack-Projekte funktionieren ohne Zusatzaufwand, etwa ein Spring-Boot-Backend zusammen mit einem Next.js-Frontend.
 
-Erkennungsregeln und welche Fakten jeder Scanner extrahiert, finden Sie in [docs/de/stacks.md](docs/de/stacks.md).
+Erkennungsregeln und die Felder, die jeder Scanner extrahiert, beschreibt [docs/de/stacks.md](docs/de/stacks.md).
 
 ---
 
 ## Täglicher Workflow
 
-Drei Befehle decken etwa 95 % der Nutzung ab:
+Drei Befehle decken rund 95 Prozent aller Anwendungsfälle ab:
 
 ```bash
-# Erstmaliger Aufruf in einem Projekt
+# Erstmals auf einem Projekt
 npx claudeos-core init
 
-# Nachdem Sie Standards oder Rules manuell bearbeitet haben
+# Nach manuellen Änderungen an Standards oder Rules
 npx claudeos-core lint
 
-# Health-Check (vor Commits oder in CI ausführen)
+# Health-Check (vor Commits oder in der CI)
 npx claudeos-core health
 ```
 
-Zwei weitere für die Wartung der Memory-Schicht:
-
-```bash
-# Failure-Patterns-Log verdichten (regelmäßig ausführen)
-npx claudeos-core memory compact
-
-# Häufige Failure-Patterns zu Vorschlagsregeln hochstufen
-npx claudeos-core memory propose-rules
-```
-
-Die vollständigen Optionen jedes Befehls finden Sie in [docs/de/commands.md](docs/de/commands.md).
+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.
 
 ---
 
-## Was unterscheidet das hier
+## Was es anders macht
 
-Die meisten Claude-Code-Dokumentationstools generieren aus einer Beschreibung (Sie sagen es dem Tool, das Tool sagt es Claude). ClaudeOS-Core generiert aus Ihrem tatsächlichen Quellcode (das Tool liest, das Tool sagt Claude, was bestätigt ist, Claude schreibt nur das Bestätigte).
+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.
 
-Drei konkrete Konsequenzen:
+Daraus folgen drei konkrete Effekte:
 
-1. **Deterministische Stack-Erkennung.** Gleiches Projekt + gleicher Code = gleiche Ausgabe. Kein „Claude hat dieses Mal anders gewürfelt."
-2. **Keine erfundenen Pfade.** Der Pass-3-Prompt nennt explizit jeden zulässigen Quellpfad; Claude kann keine Pfade zitieren, die nicht existieren.
-3. **Multi-Stack-fähig.** Backend- und Frontend-Domänen verwenden im selben Lauf unterschiedliche Analyse-Prompts.
+1. **Deterministische Stack-Erkennung.** Gleiches Projekt plus gleicher Code ergibt gleiche Ausgabe. Es gibt kein "diesmal hat Claude anders gewürfelt".
+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.
+3. **Multi-Stack-fähig.** Backend- und Frontend-Domänen verwenden im selben Lauf jeweils eigene Analyse-Prompts.
 
-Einen seitlichen Scope-Vergleich mit anderen Tools finden Sie in [docs/de/comparison.md](docs/de/comparison.md). Der Vergleich beschreibt **was jedes Tool tut**, nicht **welches besser ist** — die meisten ergänzen sich.
+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.
 
 ---
 
-## Verifikation (nach der Generierung)
+## Verifikation (nach Generierung)
 
-Nachdem Claude die Docs geschrieben hat, verifiziert Code sie. Fünf separate Validatoren:
+Sobald Claude die Docs geschrieben hat, übernimmt wieder der Code und prüft sie. Fünf separate Validatoren stehen bereit:
 
-| Validator | Was er prüft | Aufruf durch |
+| Validator | Prüfgegenstand | Ausgeführt von |
 |---|---|---|
-| `claude-md-validator` | Strukturelle Invarianten von CLAUDE.md (8 Sektionen, sprachunabhängig) | `claudeos-core lint` |
-| `content-validator` | Behauptete Pfade existieren wirklich; Manifest-Konsistenz | `health` (advisory) |
-| `pass-json-validator` | Pass-1/2/3/4-Ausgaben sind wohlgeformtes JSON | `health` (warn) |
-| `plan-validator` | Gespeicherter Plan stimmt mit der Festplatte überein | `health` (fail-on-error) |
-| `sync-checker` | Festplattendateien stimmen mit `sync-map.json`-Registrierungen überein (Erkennung verwaister/nicht registrierter Einträge) | `health` (fail-on-error) |
+| `claude-md-validator` | strukturelle Invarianten der CLAUDE.md (8 Sections, sprachunabhängig) | `claudeos-core lint` |
+| `content-validator` | Pfadangaben existieren tatsächlich; Konsistenz des Manifests | `health` (advisory) |
+| `pass-json-validator` | Ausgaben aus Pass 1 / 2 / 3 / 4 sind wohlgeformtes JSON | `health` (warn) |
+| `plan-validator` | gespeicherter Plan stimmt mit dem Stand auf der Disk überein | `health` (fail-on-error) |
+| `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) |
 
-Ein `health-checker` orchestriert die vier Laufzeit-Validatoren mit drei Schweregrad-Stufen (fail / warn / advisory) und beendet sich mit dem passenden Code für CI. `claude-md-validator` läuft separat über den `lint`-Befehl, weil strukturelle Drift ein Re-init-Signal ist und keine weiche Warnung. Jederzeit ausführbar:
+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:
 
 ```bash
 npx claudeos-core health
 ```
 
-Die Prüfungen jedes Validators im Detail finden Sie in [docs/de/verification.md](docs/de/verification.md).
+Was jeder einzelne Validator im Detail prüft, beschreibt [docs/de/verification.md](docs/de/verification.md).
 
 ---
 
-## Memory Layer (optional, für lang laufende Projekte)
+## Memory Layer (optional, für langlebige Projekte)
 
-Seit v2.0 schreibt ClaudeOS-Core einen `claudeos-core/memory/`-Ordner mit vier Dateien:
+Ü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.
 
-- `decision-log.md` — append-only-Historie „warum wir X statt Y gewählt haben"
-- `failure-patterns.md` — wiederkehrende Fehler mit Frequenz-/Wichtigkeitswerten
-- `compaction.md` — wie Memory mit der Zeit automatisch verdichtet wird
-- `auto-rule-update.md` — Muster, die zu neuen Regeln werden sollten
+Vier Dateien, alle von Pass 4 geschrieben:
 
-Sie können `npx claudeos-core memory propose-rules` ausführen, um Claude die jüngsten Failure-Patterns prüfen und neue Regeln vorschlagen zu lassen.
+- `decision-log.md`: Append-only-Log nach dem Muster "warum X statt Y", geseedet aus `pass2-merged.json`.
+- `failure-patterns.md`: wiederkehrende Fehler mit Frequenz- und Importance-Scores.
+- `compaction.md`: wie der Memory-Bereich im Lauf der Zeit automatisch komprimiert wird.
+- `auto-rule-update.md`: Patterns, die später eigene Rules werden sollten.
 
-Das Memory-Modell und seinen Lebenszyklus beschreibt [docs/de/memory-layer.md](docs/de/memory-layer.md).
+Zwei Befehle pflegen diesen Layer auf Dauer:
+
+```bash
+# Failure-Patterns-Log komprimieren (regelmäßig ausführen)
+npx claudeos-core memory compact
+
+# Häufige Failure-Patterns zu Rule-Vorschlägen befördern
+npx claudeos-core memory propose-rules
+```
+
+Memory-Modell und Lifecycle erläutert [docs/de/memory-layer.md](docs/de/memory-layer.md).
 
 ---
 
 ## FAQ
 
 **F: Brauche ich einen Claude-API-Key?**
-A: Nein. ClaudeOS-Core nutzt Ihre vorhandene Claude-Code-Installation — es leitet Prompts an `claude -p` auf Ihrem Rechner weiter. Keine zusätzlichen Konten.
+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.
 
-**F: Überschreibt das meine bestehende CLAUDE.md oder `.claude/rules/`?**
-A: Erstaufruf in einem frischen Projekt: Es legt sie an. Wiederaufruf ohne `--force` bewahrt Ihre Änderungen — Pass-Marker des vorherigen Laufs werden erkannt und die Passes übersprungen. Wiederaufruf mit `--force` löscht alles und generiert neu (Ihre Änderungen gehen verloren — genau das bedeutet `--force`). Siehe [docs/de/safety.md](docs/de/safety.md).
+**F: Überschreibt das Tool meine vorhandene CLAUDE.md oder die `.claude/rules/`?**
+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).
 
-**F: Mein Stack wird nicht unterstützt. Kann ich einen hinzufügen?**
-A: Ja. Neue Stacks brauchen ~3 Prompt-Templates und einen Domain-Scanner. Den 8-Schritte-Leitfaden finden Sie in [CONTRIBUTING.md](CONTRIBUTING.md).
+**F: Mein Stack wird nicht unterstützt. Kann ich einen ergänzen?**
+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).
 
-**F: Wie generiere ich Docs auf Deutsch (oder einer anderen Sprache)?**
-A: `npx claudeos-core init --lang de`. 10 Sprachen werden unterstützt: en, ko, ja, zh-CN, es, vi, hi, ru, fr, de.
+**F: Wie erzeuge ich Docs auf Deutsch (oder in einer anderen Sprache)?**
+A: Über `npx claudeos-core init --lang de`. Unterstützt sind 10 Sprachen: en, ko, ja, zh-CN, es, vi, hi, ru, fr, de.
 
 **F: Funktioniert das mit Monorepos?**
-A: Ja — Turborepo (`turbo.json`), pnpm-Workspaces (`pnpm-workspace.yaml`), Lerna (`lerna.json`) und npm/yarn-Workspaces (`package.json#workspaces`) werden vom Stack-Detector erkannt. Jede App erhält ihre eigene Analyse. Andere Monorepo-Layouts (z. B. NX) werden nicht spezifisch erkannt, aber die generischen Muster `apps/*/` und `packages/*/` werden trotzdem von den stackspezifischen Scannern erfasst.
+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.
 
-**F: Was, wenn Claude Code Regeln generiert, mit denen ich nicht einverstanden bin?**
-A: Bearbeiten Sie sie direkt. Führen Sie dann `npx claudeos-core lint` aus, um zu prüfen, ob CLAUDE.md noch strukturell gültig ist. Ihre Änderungen bleiben bei späteren `init`-Aufrufen (ohne `--force`) erhalten — der Resume-Mechanismus überspringt Passes, deren Marker existieren.
+**F: Was, wenn Claude Code Rules schreibt, mit denen ich nicht einverstanden bin?**
+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.
 
 **F: Wo melde ich Bugs?**
-A: [GitHub Issues](https://github.com/claudeos-core/claudeos-core/issues). Sicherheitsprobleme bitte in [SECURITY.md](SECURITY.md) nachlesen.
+A: Über die [GitHub Issues](https://github.com/claudeos-core/claudeos-core/issues). Sicherheitsrelevante Themen behandelt [SECURITY.md](SECURITY.md).
+
+---
+
+## Wenn das Zeit gespart hat
+
+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).
 
 ---
 
-## Documentation
+## Dokumentation
 
-| Thema | Lesen Sie |
+| Thema | Hier nachlesen |
 |---|---|
 | Wie die 4-Pass-Pipeline funktioniert (tiefer als das Diagramm) | [docs/de/architecture.md](docs/de/architecture.md) |
-| Visuelle Diagramme (Mermaid) der Architektur | [docs/de/diagrams.md](docs/de/diagrams.md) |
+| Visuelle Diagramme der Architektur (Mermaid) | [docs/de/diagrams.md](docs/de/diagrams.md) |
 | Stack-Erkennung — wonach jeder Scanner sucht | [docs/de/stacks.md](docs/de/stacks.md) |
-| Memory Layer — Decision Logs und Failure Patterns | [docs/de/memory-layer.md](docs/de/memory-layer.md) |
+| Memory Layer — Decision-Logs und Failure-Patterns | [docs/de/memory-layer.md](docs/de/memory-layer.md) |
 | Alle 5 Validatoren im Detail | [docs/de/verification.md](docs/de/verification.md) |
-| Jeder CLI-Befehl und jede Option | [docs/de/commands.md](docs/de/commands.md) |
+| Sämtliche CLI-Befehle und ihre Optionen | [docs/de/commands.md](docs/de/commands.md) |
 | Manuelle Installation (ohne `npx`) | [docs/de/manual-installation.md](docs/de/manual-installation.md) |
 | Scanner-Overrides — `.claudeos-scan.json` | [docs/de/advanced-config.md](docs/de/advanced-config.md) |
-| Sicherheit: Was bei Re-init erhalten bleibt | [docs/de/safety.md](docs/de/safety.md) |
-| Vergleich mit ähnlichen Tools (Scope, nicht Qualität) | [docs/de/comparison.md](docs/de/comparison.md) |
-| Fehler und Wiederherstellung | [docs/de/troubleshooting.md](docs/de/troubleshooting.md) |
+| Sicherheit: was bei einem Re-Init erhalten bleibt | [docs/de/safety.md](docs/de/safety.md) |
+| Vergleich mit ähnlichen Tools (Scope, keine Qualitätsbewertung) | [docs/de/comparison.md](docs/de/comparison.md) |
+| Fehler und Recovery | [docs/de/troubleshooting.md](docs/de/troubleshooting.md) |
 
 ---
 
 ## Mitwirken
 
-Beiträge willkommen — Stack-Unterstützung hinzufügen, Prompts verbessern, Bugs beheben. Siehe [CONTRIBUTING.md](CONTRIBUTING.md).
+Beiträge sind willkommen, sei es durch zusätzliche Stack-Unterstützung, bessere Prompts oder Bugfixes. Details stehen in [CONTRIBUTING.md](CONTRIBUTING.md).
 
-Verhaltenskodex und Sicherheitsrichtlinie finden Sie in [CODE_OF_CONDUCT.md](CODE_OF_CONDUCT.md) und [SECURITY.md](SECURITY.md).
+Verhaltenskodex und Sicherheitsrichtlinie liegen in [CODE_OF_CONDUCT.md](CODE_OF_CONDUCT.md) und [SECURITY.md](SECURITY.md).
 
-## License
+## Lizenz
 
-[ISC](LICENSE) — frei für jede Nutzung, einschließlich kommerziell.
+[ISC License](LICENSE). Frei für jeden Einsatzzweck, einschließlich kommerzieller Nutzung. © 2025–2026 ClaudeOS-Core contributors.
 
 ---
 
-<sub>Mit Sorgfalt gebaut von [@claudeos-core](https://github.com/claudeos-core). Wenn Ihnen das Tool Zeit gespart hat, hält ein ⭐ auf GitHub die Sichtbarkeit aufrecht.</sub>
+<sub>Gepflegt vom Team [claudeos-core](https://github.com/claudeos-core). Issues und PRs landen unter <https://github.com/claudeos-core/claudeos-core>.</sub>