claudeos-core 2.4.4 → 2.5.1

package/README.hi.md

@@ -2,7 +2,7 @@
 
 [![npm version](https://img.shields.io/npm/v/claudeos-core.svg?logo=npm&label=npm)](https://www.npmjs.com/package/claudeos-core)
 [![CI](https://img.shields.io/github/actions/workflow/status/claudeos-core/claudeos-core/test.yml?branch=master&logo=github&label=CI)](https://github.com/claudeos-core/claudeos-core/actions/workflows/test.yml)
-[![tests](https://img.shields.io/badge/tests-736%20passing-brightgreen?logo=node.js&logoColor=white)](https://github.com/claudeos-core/claudeos-core/actions/workflows/test.yml)
+[![tests](https://img.shields.io/badge/tests-974%20passing-brightgreen?logo=node.js&logoColor=white)](https://github.com/claudeos-core/claudeos-core/actions/workflows/test.yml)
 [![node](https://img.shields.io/node/v/claudeos-core.svg?logo=node.js&logoColor=white&label=node)](https://nodejs.org/)
 [![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)
@@ -25,7 +25,7 @@ Claude Code हर नए session पर framework के generic defaults प
 
 **ClaudeOS-Core यही काम deterministically करता है, सीधे आपके actual source code से।** पहले एक Node.js scanner project को पढ़ता है, यानी stack, ORM, package layout और file paths सब निकाल लेता है। उसके बाद 4-pass Claude pipeline पूरा set generate करती है। `CLAUDE.md`, auto-load होने वाले `.claude/rules/`, standards, skills — ये सब एक explicit path allowlist के अंदर ही बनते हैं, और LLM इस दायरे से बाहर नहीं जा सकता। आखिर में 5 validators output को ship होने से पहले verify कर लेते हैं।
 
-नतीजा यह है कि same input के लिए हमेशा byte-identical output मिलता है, चाहे 10 भाषाओं में से कोई भी चुनी जाए, और कभी invented path नहीं आएगा। (विस्तार से नीचे [क्या इसे अलग बनाता है](#क्या-इसे-अलग-बनाता-है) में।)
+नतीजा यह है कि same input के लिए हमेशा वही 8-section वाला `CLAUDE.md` structure मिलता है, जो चाहे 10 भाषाओं में से कोई भी चुनी जाए, उन्हीं 25 structural checks से validate होता है, और cite किया गया हर source path disk पर verify होता है। (विस्तार से नीचे [क्या इसे अलग बनाता है](#क्या-इसे-अलग-बनाता-है) में।)
 
 लंबे चलने वाले projects के लिए एक अलग [Memory Layer](#memory-layer-वैकल्पिक-दीर्घकालिक-प्रोजेक्ट्स-के-लिए) भी seed होता है।
 
@@ -115,7 +115,7 @@ Claude Code हर नए session पर framework के generic defaults प
 </details>
 
 <details>
-<summary><strong>असली <code>CLAUDE.md</code> में आखिर क्या लिखा जाता है (वास्तविक excerpt — Section 1 + 2)</strong></summary>
+<summary><strong>असली <code>CLAUDE.md</code> में आखिर क्या लिखा जाता है (वास्तविक excerpt — Section 1 + 2; README rendering के लिए headings को <code>####</code> पर demote किया गया है, असली file में <code>## N.</code> होता है)</strong></summary>
 
 ```markdown
 # CLAUDE.md — spring-boot-realworld-example-app
@@ -148,7 +148,7 @@ an XML-driven MyBatis persistence layer and JWT-based authentication.
 | Test Stack | JUnit Jupiter 5, Mockito, AssertJ, rest-assured, spring-mock-mvc |
 ```
 
-ऊपर table में जो भी value है — exact dependency coordinates, `dev.db` filename, `V1__create_tables.sql` migration नाम, "no JPA" तक — वो सब Claude के file लिखने से पहले scanner ने `build.gradle`, `application.properties` और source tree से सीधे निकाला है। एक भी value guess नहीं की गई।
+Stack वाली rows (Java 11, Spring Boot 2.6.3, Gradle, MyBatis, SQLite, port 8080) deterministic scanner से आती हैं। बारीक details — exact dependency coordinates, `dev.db` filename, `V1__create_tables.sql` migration नाम, "no JPA" — Pass 1 scanner के facts को constraint मानकर `build.gradle`, `application.properties` और source tree से पढ़ता है, और फिर validators उन्हें cross-check करते हैं। एक भी value framework defaults से नहीं ली गई।
 
 </details>
 
@@ -309,7 +309,7 @@ your-project/
 | आप कौन हैं... | यह जो pain हटाता है |
 |---|---|
 | **Solo dev जो Claude Code से नया project शुरू कर रहा है** | "हर session में Claude को conventions फिर से सिखाओ" — यह झंझट खत्म। `CLAUDE.md` और 8-category `.claude/rules/` एक ही pass में बन जाते हैं। |
-| **Team lead जो कई repos में shared standards maintain करता है** | जब लोग packages rename करते हैं, ORMs बदलते हैं, या response wrappers switch करते हैं, तब `.claude/rules/` drift करने लगते हैं। ClaudeOS-Core इन्हें deterministically फिर से sync कर देता है। Same input = byte-identical output, कोई diff noise नहीं। |
+| **Team lead जो कई repos में shared standards maintain करता है** | जब लोग packages rename करते हैं, ORMs बदलते हैं, या response wrappers switch करते हैं, तब `.claude/rules/` drift करने लगते हैं। ClaudeOS-Core इन्हें एक fixed 8-section scaffold के हिसाब से फिर से generate करता है। हर repo में same structure, same validator verdict, इसलिए diff में layout noise नहीं बल्कि convention के बदलाव दिखते हैं। |
 | **पहले से Claude Code use कर रहे हैं लेकिन generated code ठीक करते-करते थक चुके हैं** | गलत response wrapper, गलत package layout, MyBatis project में JPA code, centralized middleware के बावजूद बिखरा हुआ `try/catch` — यह सब scanner आपके असली conventions निकालकर रोकता है, और हर Claude pass एक explicit path allowlist पर ही चलता है। |
 | **नए repo पर onboarding कर रहे हैं** (existing project, team join कर रहे हैं) | Repo पर `init` चलाइए, एक living architecture map मिल जाता है — CLAUDE.md में stack table, ✅/❌ examples के साथ per-layer rules, और बड़े decisions के पीछे "why" से seed किया हुआ decision log (JPA vs MyBatis, REST vs GraphQL, वगैरह)। 5 files पढ़ना 5,000 source files पढ़ने से कहीं तेज़ है। |
 | **हिन्दी / कोरियाई / जापानी / चीनी समेत 7 अन्य भाषाओं में काम कर रहे हैं** | अधिकांश Claude Code rule generators सिर्फ English में लिखते हैं। ClaudeOS-Core पूरा set **10 भाषाओं** (`en/ko/ja/zh-CN/es/vi/hi/ru/fr/de`) में लिखता है, और structural validation **byte-identical** रहता है — output language कोई भी हो, `claude-md-validator` का verdict same रहता है। |
@@ -331,7 +331,7 @@ ClaudeOS-Core typical Claude Code workflow को उल्टा करके
 
 Pipeline **तीन stages** में चलती है, और LLM call के दोनों तरफ code रहता है।
 
-**1. Step A — Scanner (deterministic, कोई LLM नहीं)।** एक Node.js scanner project root को walk करता है, `package.json` / `build.gradle` / `pom.xml` / `pyproject.toml` पढ़ता है, `.env*` files parse करता है (`PASSWORD/SECRET/TOKEN/JWT_SECRET/...` जैसी sensitive variables को redact करते हुए), architecture pattern classify करता है (Java के 5 patterns A/B/C/D/E, Kotlin CQRS / multi-module, Next.js App vs Pages Router, FSD, components-pattern), domains discover करता है, और मौजूदा हर source file path का explicit allowlist बनाता है। इसका output है `project-analysis.json`, जो आगे की हर चीज़ के लिए single source of truth बन जाता है।
+**1. Step A — Scanner (deterministic, कोई LLM नहीं)।** एक Node.js scanner project root को walk करता है, `package.json` / `build.gradle` / `build.gradle.kts` / `pom.xml` / `pyproject.toml` पढ़ता है, `.env*` files parse करता है (`PASSWORD/SECRET/TOKEN/JWT_SECRET/...` जैसी sensitive variables को redact करते हुए), architecture pattern classify करता है (Java के 5 patterns A/B/C/D/E, Kotlin CQRS / multi-module, Next.js App vs Pages Router, FSD, components-pattern), domains discover करता है, और मौजूदा हर source file path का explicit allowlist बनाता है। इसका output है `project-analysis.json`, जो आगे की हर चीज़ के लिए single source of truth बन जाता है।
 
 **2. Step B — 4-Pass Claude pipeline (Step A के facts के दायरे में)।**
 - **Pass 1** हर domain group के representative files पढ़ता है और प्रति domain करीब 50–100 conventions निकालता है — response wrappers, logging libraries, error handling, naming conventions, test patterns वगैरह। यह domain group पर एक बार चलता है (`max 4 domains, 40 files per group`), इसलिए context कभी overflow नहीं होता।
@@ -358,12 +358,14 @@ Pipeline **तीन stages** में चलती है, और LLM call क
 
 12 stacks, project files से auto-detected।
 
-**Backend:** Java/Spring Boot · Kotlin/Spring Boot · Node/Express · Node/Fastify · Node/NestJS · Python/Django · Python/FastAPI · Python/Flask
+**Backend:** Java/Spring Boot (और Boot के बिना Spring Framework, नीचे देखें) · 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 projects (जैसे Spring Boot backend + Next.js frontend) भी out of the box चलते हैं।
 
+**Legacy Java अब first-class target है (v2.5.1).** Boot के बिना Spring 1.x–6.x detect होता है: Gradle (`apply plugin:` युग, किसी भी क्रम में `group:/name:/version:` notation, `gradle.properties` / `apply from:` / buildSrc से resolution, version catalogs, सिर्फ़ `settings.gradle` वाले root), Maven (Maven-2 POM, `${spring.version}` properties, `spring-framework-bom`, multi-module root, बिना root POM के sibling projects), **Ant + Ivy**, **Eclipse / IntelliJ / NetBeans metadata** (`.classpath` — बिना commit किए JAR references सहित, `.settings` का compliance level, `.idea/misc.xml`, `nbproject`), `WebContent/WEB-INF/lib/**/*.jar`, `WEB-INF/web.xml`, Spring XSD schema versions और **eGovFrame** — framework, Spring Framework version, Java level, `war`/`ear` packaging, JDBC driver और ORM के साथ। `src/`-rooted source tree भी उन्हीं domain patterns से scan होते हैं जो `src/main/java` पर लगते हैं। बताई गई हर version किसी build file, JAR के नाम या project में define की गई property से पढ़ी जाती है; framework के default से कुछ भी नहीं माना जाता। जिन JVM projects में Spring है ही नहीं (`java-library`, `application`, सिर्फ़ servlet वाला `war`) उन्हें `framework: null` के साथ Java बताया जाता है, Spring कभी नहीं।
+
 Detection rules और हर scanner क्या निकालता है, यह [docs/hi/stacks.md](docs/hi/stacks.md) में है।
 
 ---
@@ -393,7 +395,7 @@ npx claudeos-core health
 
 इसके तीन ठोस नतीजे हैं।
 
-1. **Deterministic stack detection.** Same project + same code = same output। "इस बार Claude थोड़ा अलग roll हो गया" वाली बात नहीं होती।
+1. **Deterministic stack detection और structure.** Same project + same code = same scan result और वही 8-section `CLAUDE.md` layout। Sections के अंदर की wording अब भी LLM लिखता है; fixed सिर्फ वे facts हैं जो उसे दिए जाते हैं और वह shape जो उसे भरनी है।
 2. **No invented paths.** Pass 3 prompt में हर allowed source path explicitly listed होता है, इसलिए Claude ऐसे paths cite ही नहीं कर सकता जो मौजूद नहीं हैं।
 3. **Multi-stack aware.** एक ही run में backend और frontend domains अलग-अलग analysis prompts use करते हैं।
 
@@ -429,7 +431,7 @@ npx claudeos-core health
 
 चार files हैं, और सब Pass 4 लिखता है।
 
-- `decision-log.md` — append-only "हमने X की जगह Y क्यों चुना", `pass2-merged.json` से seed होता है
+- `decision-log.md` — append-only "हमने X की जगह Y क्यों चुना", `pass2-merged.json` से seed होता है (कभी compact नहीं होता)
 - `failure-patterns.md` — frequency / importance scores के साथ बार-बार आने वाली errors
 - `compaction.md` — समय के साथ memory कैसे auto-compact होती है
 - `auto-rule-update.md` — वो patterns जिन्हें नए rules बनना चाहिए
@@ -437,7 +439,7 @@ npx claudeos-core health
 इस layer को समय के साथ maintain करने के लिए दो commands हैं।
 
 ```bash
-# Failure-patterns log compact करें (समय-समय पर चलाएँ)
+# Failure-patterns log compact करें (समय-समय पर चलाएँ; decision-log.md को छुआ नहीं जाता)
 npx claudeos-core memory compact
 
 # बार-बार आने वाले failure patterns को proposed rules में promote करें

package/README.ja.md

@@ -2,7 +2,7 @@
 
 [![npm version](https://img.shields.io/npm/v/claudeos-core.svg?logo=npm&label=npm)](https://www.npmjs.com/package/claudeos-core)
 [![CI](https://img.shields.io/github/actions/workflow/status/claudeos-core/claudeos-core/test.yml?branch=master&logo=github&label=CI)](https://github.com/claudeos-core/claudeos-core/actions/workflows/test.yml)
-[![tests](https://img.shields.io/badge/tests-736%20passing-brightgreen?logo=node.js&logoColor=white)](https://github.com/claudeos-core/claudeos-core/actions/workflows/test.yml)
+[![tests](https://img.shields.io/badge/tests-974%20passing-brightgreen?logo=node.js&logoColor=white)](https://github.com/claudeos-core/claudeos-core/actions/workflows/test.yml)
 [![node](https://img.shields.io/node/v/claudeos-core.svg?logo=node.js&logoColor=white&label=node)](https://nodejs.org/)
 [![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)
@@ -25,7 +25,7 @@ Claude Code は新しいセッションを始めるたびに、フレームワ
 
 **ClaudeOS-Core は、実際のソースコードから一貫した結果でこれを再生成します。** まず Node.js のスキャナがプロジェクトを読み、スタック・ORM・パッケージ構成・ファイルパスを把握します。次に 4-pass の Claude パイプラインがドキュメント一式を書き上げます。`CLAUDE.md`、自動ロードされる `.claude/rules/`、standards、skills のすべてが、明示的なパス allowlist の範囲内に収まります。LLM はこの範囲を超えられません。最後に 5 つの validator が、出力する前に結果を検証します。
 
-そのため、同じ入力からは常に同じ出力が返ります。10 言語のどれを選んでも byte 単位で完全に一致し、コードに存在しないパスが紛れ込むこともありません。(詳しくは下の[何が違うのか](#何が違うのか)を参照。)
+そのため、同じ入力からは常に同じ 8 セクション構造の `CLAUDE.md` が返ります。10 言語のどれを選んでも同じ 25 項目の構造チェックで検証され、引用されたソースパスはすべてディスク上に実在するか確認されます。(詳しくは下の[何が違うのか](#何が違うのか)を参照。)
 
 長く運用するプロジェクトには、[Memory Layer](#memory-layer-任意長期プロジェクト向け) も合わせて生成されます。
 
@@ -115,7 +115,7 @@ Claude Code は新しいセッションを始めるたびに、フレームワ
 </details>
 
 <details>
-<summary><strong>実際の <code>CLAUDE.md</code> に入る内容 (実例の抜粋 — Section 1 + 2)</strong></summary>
+<summary><strong>実際の <code>CLAUDE.md</code> に入る内容 (実例の抜粋 — Section 1 + 2。README の表示用に見出しを <code>####</code> に下げています。実ファイルでは <code>## N.</code> です)</strong></summary>
 
 ```markdown
 # CLAUDE.md — spring-boot-realworld-example-app
@@ -148,7 +148,7 @@ an XML-driven MyBatis persistence layer and JWT-based authentication.
 | Test Stack | JUnit Jupiter 5, Mockito, AssertJ, rest-assured, spring-mock-mvc |
 ```
 
-上の表の値はすべて、正確な dependency の座標も、`dev.db` というファイル名も、`V1__create_tables.sql` というマイグレーション名も、「no JPA」という注記も、Claude がファイルを書く前にスキャナが `build.gradle`、`application.properties`、ソースツリーから直接読み取った内容です。推測した値は 1 つも入っていません。
+スタック表の各行 (Java 11、Spring Boot 2.6.3、Gradle、MyBatis、SQLite、ポート 8080) は決定論的なスキャナが読み取った値です。より細かい情報 (正確な dependency の座標、`dev.db` というファイル名、`V1__create_tables.sql` というマイグレーション名、「no JPA」という注記) は、スキャナが確定した事実を制約として Pass 1 が `build.gradle`、`application.properties`、ソースツリーから読み取り、その後 validator が照合します。フレームワークのデフォルト値から取った値は 1 つもありません。
 
 </details>
 
@@ -309,7 +309,7 @@ your-project/
 | こんな方に | このツールが解消する痛み |
 |---|---|
 | **Claude Code で新規プロジェクトを始める個人開発者** | セッションのたびに Claude へコンベンションを教え直す手間がなくなります。`CLAUDE.md` と 8 カテゴリの `.claude/rules/` を一発で生成します。 |
-| **複数リポジトリで共有標準を維持するチームリード** | パッケージ名の変更や ORM の差し替え、レスポンスラッパーの変更があるたびに `.claude/rules/` がついていけずズレていく問題。ClaudeOS-Core ならいつ走らせても同じ手順で再同期できます。同じ入力からは byte 単位で同じ出力が出るので、diff にノイズが乗りません。 |
+| **複数リポジトリで共有標準を維持するチームリード** | パッケージ名の変更や ORM の差し替え、レスポンスラッパーの変更があるたびに `.claude/rules/` がついていけずズレていく問題。ClaudeOS-Core は固定された 8 セクションの scaffold を基準に再生成します。どのリポジトリでも同じ構造、同じ validator の判定になるため、diff に現れるのはレイアウトのノイズではなく規約の変更だけです。 |
 | **Claude Code を使っているが生成コードの修正に疲れた方** | 違うレスポンスラッパー、違うパッケージ構成、MyBatis のプロジェクトなのに JPA、共通 middleware があるのに `try/catch` が散らばっている、といった出力。スキャナが実際のコンベンションを抽出し、Claude のすべての pass は明示的なパス allowlist の中だけで動きます。 |
 | **新しいリポジトリにジョインしたばかりの方** (既存プロジェクト、新しいチーム) | リポジトリで `init` を一度走らせれば、生きたアーキテクチャマップが手に入ります。CLAUDE.md のスタック表、レイヤーごとのルールと ✅/❌ の例、主要な決定の「なぜ」が書き込まれた decision log (JPA vs MyBatis、REST vs GraphQL など)。5,000 個のソースファイルを読むより、5 つのドキュメントを読むほうが速いです。 |
 | **韓国語、日本語、中国語など英語以外の言語で作業する方** | Claude Code 向けのルール生成ツールはほとんどが英語のみです。ClaudeOS-Core は **10 言語** (`en/ko/ja/zh-CN/es/vi/hi/ru/fr/de`) でドキュメント一式を生成し、出力言語が何であっても同じ構造検証を適用します。`claude-md-validator` の判定はどの言語でも同じです。 |
@@ -331,7 +331,7 @@ ClaudeOS-Core は、よくある Claude Code のワークフローの順序を
 
 パイプラインは **3 段階**で動きます。LLM を呼ぶ前にも後にも、コードが間に挟まる構成です。
 
-**1. Step A — スキャナ (LLM なしの決定論的処理)。** Node.js のスキャナがプロジェクトルートを巡回し、`package.json` / `build.gradle` / `pom.xml` / `pyproject.toml` を読み、`.env*` ファイルをパースします (`PASSWORD/SECRET/TOKEN/JWT_SECRET/...` などの機密変数は自動でマスクします)。続いてアーキテクチャパターンを分類し (Java の 5 パターン A/B/C/D/E、Kotlin の CQRS / マルチモジュール、Next.js の App Router と Pages Router、FSD、components パターン)、ドメインを抽出し、存在するすべてのソースファイルパスを明示的な allowlist にまとめます。結果は `project-analysis.json` 1 ファイルに集約され、以降の工程はこれを single source of truth として扱います。
+**1. Step A — スキャナ (LLM なしの決定論的処理)。** Node.js のスキャナがプロジェクトルートを巡回し、`package.json` / `build.gradle` / `build.gradle.kts` / `pom.xml` / `pyproject.toml` を読み、`.env*` ファイルをパースします (`PASSWORD/SECRET/TOKEN/JWT_SECRET/...` などの機密変数は自動でマスクします)。続いてアーキテクチャパターンを分類し (Java の 5 パターン A/B/C/D/E、Kotlin の CQRS / マルチモジュール、Next.js の App Router と Pages Router、FSD、components パターン)、ドメインを抽出し、存在するすべてのソースファイルパスを明示的な allowlist にまとめます。結果は `project-analysis.json` 1 ファイルに集約され、以降の工程はこれを single source of truth として扱います。
 
 **2. Step B — 4-pass の Claude パイプライン (Step A の事実を制約として動作)。**
 - **Pass 1** はドメイングループごとに代表ファイルを読み、ドメインあたり 50 〜 100 個のコンベンション (レスポンスラッパー、ロギングライブラリ、エラー処理、命名規則、テストパターンなど) を抽出します。ドメイングループごとに 1 回ずつ実行する設計 (`max 4 domains, 40 files per group`) なので、context があふれることはありません。
@@ -358,12 +358,14 @@ severity は 3 段階 (`fail` / `warn` / `advisory`) に分かれており、ユ
 
 12 スタックを、プロジェクトのファイルから自動で検出します。
 
-**Backend:** Java/Spring Boot · Kotlin/Spring Boot · Node/Express · Node/Fastify · Node/NestJS · Python/Django · Python/FastAPI · Python/Flask
+**Backend:** Java/Spring Boot (Boot なしの Spring Framework も。下記参照) · Kotlin/Spring Boot · Node/Express · Node/Fastify · Node/NestJS · Python/Django · Python/FastAPI · Python/Flask
 
 **Frontend:** Node/Next.js · Node/Vite · Angular · Vue/Nuxt
 
 マルチスタックのプロジェクト (例: Spring Boot バックエンド + Next.js フロントエンド) もそのまま動きます。
 
+**レガシー Java は第一級の対象です (v2.5.1)。** Boot なしの Spring 1.x–6.x を検出します。Gradle (`apply plugin:` 時代、順序を問わない `group:/name:/version:` 記法、`gradle.properties` / `apply from:` / buildSrc による解決、バージョンカタログ、`settings.gradle` だけのルート)、Maven (Maven 2 の POM、`${spring.version}` プロパティ、`spring-framework-bom`、マルチモジュールのルート、ルート POM のない兄弟プロジェクト)、**Ant + Ivy**、**Eclipse / IntelliJ / NetBeans のメタデータ** (コミットされていない JAR への参照を含む `.classpath`、`.settings` のコンプライアンスレベル、`.idea/misc.xml`、`nbproject`)、`WebContent/WEB-INF/lib/**/*.jar`、`WEB-INF/web.xml`、Spring XSD のスキーマバージョン、そして **eGovFrame** — フレームワーク、Spring Framework のバージョン、Java レベル、`war`/`ear` パッケージング、JDBC ドライバ、ORM まで取得します。`src/` をルートとするソースツリーも `src/main/java` と同じドメインパターンでスキャンされます。報告されるバージョンはすべてビルドファイル・JAR 名・プロジェクト内で定義されたプロパティから読み取ったもので、フレームワークのデフォルトから推測することはありません。Spring をまったく使わない JVM プロジェクト (`java-library`、`application`、サーブレットのみの `war`) は `framework: null` の Java として報告され、Spring とされることはありません。
+
 検出ルールと各スキャナが取り出す情報については [docs/ja/stacks.md](docs/ja/stacks.md) を参照してください。
 
 ---
@@ -393,7 +395,7 @@ Claude Code 向けのドキュメント生成ツールはほとんど、ユー
 
 具体的な違いは 3 つあります。
 
-1. **決定論的なスタック検出。** 同じプロジェクト + 同じコード = 同じ出力。「今回の Claude はちょっと違う出力を出してきた」がありません。
+1. **決定論的なスタック検出と構造。** 同じプロジェクト + 同じコード = 同じスキャン結果、同じ 8 セクション構造の `CLAUDE.md`。セクション内の文章は引き続き LLM が書きますが、渡される事実と埋めるべき形は固定されています。
 2. **存在しないパスを作らない。** Pass 3 の prompt に許可済みのソースパスがすべて明示されているため、Claude はそこに無いパスを引用できません。
 3. **マルチスタックを意識した解析。** 同じ実行の中で、バックエンドとフロントエンドのドメインがそれぞれ別の解析 prompt を使います。
 
@@ -429,7 +431,7 @@ npx claudeos-core health
 
 ファイルは 4 つで、すべて Pass 4 が書き出します。
 
-- `decision-log.md` — append-only 形式の「なぜ X ではなく Y を選んだか」の記録。`pass2-merged.json` からシード。
+- `decision-log.md` — append-only 形式の「なぜ X ではなく Y を選んだか」の記録。`pass2-merged.json` からシード。(圧縮の対象外)
 - `failure-patterns.md` — frequency / importance のスコアが付いた、繰り返し起きるエラーの一覧。
 - `compaction.md` — 時間の経過とともにメモリが自動圧縮される仕組み。
 - `auto-rule-update.md` — 新しいルールに昇格させるべきパターン。
@@ -437,7 +439,7 @@ npx claudeos-core health
 このレイヤーを長く運用するためのコマンドが 2 つあります。
 
 ```bash
-# failure-patterns ログを圧縮 (定期的に実行)
+# failure-patterns ログを圧縮 (定期的に実行。decision-log.md には触れません)
 npx claudeos-core memory compact
 
 # よく出る failure pattern を提案ルールに昇格

package/README.ko.md

@@ -2,7 +2,7 @@
 
 [![npm version](https://img.shields.io/npm/v/claudeos-core.svg?logo=npm&label=npm)](https://www.npmjs.com/package/claudeos-core)
 [![CI](https://img.shields.io/github/actions/workflow/status/claudeos-core/claudeos-core/test.yml?branch=master&logo=github&label=CI)](https://github.com/claudeos-core/claudeos-core/actions/workflows/test.yml)
-[![tests](https://img.shields.io/badge/tests-736%20passing-brightgreen?logo=node.js&logoColor=white)](https://github.com/claudeos-core/claudeos-core/actions/workflows/test.yml)
+[![tests](https://img.shields.io/badge/tests-974%20passing-brightgreen?logo=node.js&logoColor=white)](https://github.com/claudeos-core/claudeos-core/actions/workflows/test.yml)
 [![node](https://img.shields.io/node/v/claudeos-core.svg?logo=node.js&logoColor=white&label=node)](https://nodejs.org/)
 [![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)
@@ -25,7 +25,7 @@ Claude Code는 새 세션을 시작할 때마다 일반적인 프레임워크
 
 **ClaudeOS-Core는 실제 소스 코드를 분석해서 일관된 결과로 다시 만들어 줍니다.** 먼저 Node.js scanner가 프로젝트를 읽고 스택, ORM, 패키지 구조, 파일 경로를 파악합니다. 그 다음 4-pass Claude 파이프라인이 전체 문서 세트를 작성합니다. `CLAUDE.md`, 자동 로드되는 `.claude/rules/`, standards, skills 모두 명시적인 경로 allowlist 안에서만 만들어지고, LLM은 이 범위 밖으로 나갈 수 없습니다. 마지막으로 5개 validator가 결과를 내보내기 전에 한 번 더 검증합니다.
 
-덕분에 같은 입력에는 항상 같은 출력이 나옵니다. 10개 언어 중 무엇을 골라도 결과는 byte 단위로 동일하고, 코드에 존재하지 않는 경로는 절대 등장하지 않습니다. (자세한 내용은 아래 [무엇이 다른가](#무엇이-다른가) 참고.)
+덕분에 같은 입력에는 항상 같은 8개 섹션 구조의 `CLAUDE.md`가 나옵니다. 10개 언어 중 무엇을 골라도 동일한 25개 구조 검사를 통과해야 하고, 인용된 모든 소스 경로는 디스크에 실제로 존재하는지 확인됩니다. (자세한 내용은 아래 [무엇이 다른가](#무엇이-다른가) 참고.)
 
 오래 운영되는 프로젝트라면 [Memory Layer](#memory-layer-선택-장기-프로젝트용)도 함께 만들어집니다.
 
@@ -115,7 +115,7 @@ Claude Code는 새 세션을 시작할 때마다 일반적인 프레임워크
 </details>
 
 <details>
-<summary><strong>실제 <code>CLAUDE.md</code>에 들어가는 내용 (실제 발췌 — Section 1 + 2)</strong></summary>
+<summary><strong>실제 <code>CLAUDE.md</code>에 들어가는 내용 (실제 발췌 — Section 1 + 2; README 렌더링을 위해 제목을 <code>####</code>로 낮췄고, 실제 파일은 <code>## N.</code>을 사용)</strong></summary>
 
 ```markdown
 # CLAUDE.md — spring-boot-realworld-example-app
@@ -148,7 +148,7 @@ an XML-driven MyBatis persistence layer and JWT-based authentication.
 | Test Stack | JUnit Jupiter 5, Mockito, AssertJ, rest-assured, spring-mock-mvc |
 ```
 
-위 표의 모든 값(정확한 dependency 좌표, `dev.db` 파일명, `V1__create_tables.sql` 마이그레이션명, "no JPA"까지)은 Claude가 파일을 만들기 전에 scanner가 `build.gradle`, `application.properties`, 소스 트리에서 직접 읽어 온 사실입니다. 추측한 값이 하나도 없습니다.
+스택 표의 행(Java 11, Spring Boot 2.6.3, Gradle, MyBatis, SQLite, 포트 8080)은 결정론적 scanner가 읽어 온 값입니다. 더 세부적인 값(정확한 dependency 좌표, `dev.db` 파일명, `V1__create_tables.sql` 마이그레이션명, "no JPA")은 Pass 1이 scanner의 사실을 제약 조건으로 삼아 `build.gradle`, `application.properties`, 소스 트리에서 읽어 오고, validator가 다시 교차 검증합니다. 프레임워크 기본값에서 가져온 값은 하나도 없습니다.
 
 </details>
 
@@ -309,7 +309,7 @@ your-project/
 | 사용자 | 해결되는 문제 |
 |---|---|
 | **Claude Code로 새 프로젝트를 시작하는 1인 개발자** | 매 세션마다 Claude에게 컨벤션을 다시 가르쳐야 하는 부담이 사라집니다. `CLAUDE.md`와 8개 카테고리의 `.claude/rules/`를 한 번에 만들어 줍니다. |
-| **여러 repo의 공유 표준을 유지하는 팀 리드** | 패키지 이름이 바뀌거나 ORM이 교체되거나 response wrapper가 변경될 때마다 `.claude/rules/`가 따라가지 못해 어긋나는 문제. ClaudeOS-Core가 일관된 방식으로 다시 동기화합니다. 같은 입력에는 byte 단위로 동일한 출력이 나오기 때문에 diff 노이즈가 없습니다. |
+| **여러 repo의 공유 표준을 유지하는 팀 리드** | 패키지 이름이 바뀌거나 ORM이 교체되거나 response wrapper가 변경될 때마다 `.claude/rules/`가 따라가지 못해 어긋나는 문제. ClaudeOS-Core는 고정된 8개 섹션 scaffold를 기준으로 다시 생성합니다. 모든 repo가 같은 구조, 같은 validator 판정을 받기 때문에 diff에는 레이아웃 노이즈가 아니라 컨벤션 변경만 드러납니다. |
 | **Claude Code를 이미 쓰지만 생성된 코드를 수정하는 데 지친 사용자** | 잘못된 response wrapper, 잘못된 패키지 구조, MyBatis 프로젝트인데 JPA 코드, 중앙 middleware가 있는데도 `try/catch`가 흩뿌려진 출력. scanner가 실제 컨벤션을 추출하고, 모든 Claude pass는 명시적인 경로 allowlist 안에서만 동작합니다. |
 | **새 repo에 합류한 경우** (기존 프로젝트, 팀 합류) | repo에서 `init`만 돌리면 살아 있는 아키텍처 지도가 생깁니다. CLAUDE.md의 스택 표, 레이어별 룰과 ✅/❌ 예제, 주요 결정의 "왜"가 미리 채워진 decision log (JPA vs MyBatis, REST vs GraphQL 등). 파일 5개 훑는 쪽이 소스 파일 5,000개를 읽는 것보다 훨씬 빠릅니다. |
 | **한국어, 일본어, 중국어 등 영어 외의 언어로 작업** | 대부분의 Claude Code 룰 생성기는 영어만 지원합니다. ClaudeOS-Core는 **10개 언어** (`en/ko/ja/zh-CN/es/vi/hi/ru/fr/de`)로 전체 세트를 만들고, 출력 언어와 무관하게 동일한 구조 검증을 적용합니다. `claude-md-validator`의 판정은 어느 언어든 똑같습니다. |
@@ -331,7 +331,7 @@ ClaudeOS-Core는 일반적인 Claude Code 워크플로를 거꾸로 뒤집습니
 
 파이프라인은 **3단계**로 동작합니다. LLM 호출 앞뒤 모두에 코드가 자리잡고 있습니다:
 
-**1. Step A — Scanner (일관된 동작, LLM 없음).** Node.js scanner가 프로젝트 루트를 순회하면서 `package.json`, `build.gradle`, `pom.xml`, `pyproject.toml`을 읽고, `.env*` 파일을 파싱합니다 (`PASSWORD/SECRET/TOKEN/JWT_SECRET/...` 같은 민감 변수는 자동으로 가립니다). 그런 다음 아키텍처 패턴을 분류하고 (Java 5개 패턴 A/B/C/D/E, Kotlin CQRS / 멀티모듈, Next.js App vs Pages Router, FSD, components 패턴), 도메인을 찾고, 존재하는 모든 소스 파일 경로의 명시적 allowlist를 만듭니다. 결과는 `project-analysis.json` 한 파일에 모이고, 이후 모든 단계는 이걸 단일 source of truth로 삼습니다.
+**1. Step A — Scanner (일관된 동작, LLM 없음).** Node.js scanner가 프로젝트 루트를 순회하면서 `package.json`, `build.gradle`, `build.gradle.kts`, `pom.xml`, `pyproject.toml`을 읽고, `.env*` 파일을 파싱합니다 (`PASSWORD/SECRET/TOKEN/JWT_SECRET/...` 같은 민감 변수는 자동으로 가립니다). 그런 다음 아키텍처 패턴을 분류하고 (Java 5개 패턴 A/B/C/D/E, Kotlin CQRS / 멀티모듈, Next.js App vs Pages Router, FSD, components 패턴), 도메인을 찾고, 존재하는 모든 소스 파일 경로의 명시적 allowlist를 만듭니다. 결과는 `project-analysis.json` 한 파일에 모이고, 이후 모든 단계는 이걸 단일 source of truth로 삼습니다.
 
 **2. Step B — 4-Pass Claude 파이프라인 (Step A의 사실을 기반으로 동작).**
 - **Pass 1**은 도메인 그룹별로 대표 파일을 읽고 도메인당 50–100개 정도의 컨벤션을 뽑아냅니다 (response wrapper, 로깅 라이브러리, 에러 처리, 네이밍 규칙, 테스트 패턴 등). 도메인 그룹마다 한 번씩 실행하기 때문에 (`max 4 domains, 40 files per group`) context가 절대 넘치지 않습니다.
@@ -358,12 +358,14 @@ ClaudeOS-Core는 일반적인 Claude Code 워크플로를 거꾸로 뒤집습니
 
 12개 스택을 프로젝트 파일에서 자동으로 감지합니다:
 
-**Backend:** Java/Spring Boot · Kotlin/Spring Boot · Node/Express · Node/Fastify · Node/NestJS · Python/Django · Python/FastAPI · Python/Flask
+**Backend:** Java/Spring Boot (Boot 없는 Spring Framework 포함, 아래 참고) · Kotlin/Spring Boot · Node/Express · Node/Fastify · Node/NestJS · Python/Django · Python/FastAPI · Python/Flask
 
 **Frontend:** Node/Next.js · Node/Vite · Angular · Vue/Nuxt
 
 멀티 스택 프로젝트 (예: Spring Boot 백엔드 + Next.js 프론트엔드)도 그대로 동작합니다.
 
+**레거시 Java도 1급 대상입니다 (v2.5.1).** Boot 없는 Spring 1.x–6.x를 탐지합니다. Gradle (`apply plugin:` 시절, 순서 무관한 `group:/name:/version:` 표기, `gradle.properties` / `apply from:` / buildSrc를 통한 변수 해석, 버전 카탈로그, `settings.gradle`만 있는 루트), Maven (Maven 2 POM, `${spring.version}` 프로퍼티, `spring-framework-bom`, 멀티 모듈 루트, 루트 POM 없는 형제 프로젝트), **Ant + Ivy**, **Eclipse / IntelliJ / NetBeans 메타데이터** (커밋되지 않은 JAR 참조를 포함한 `.classpath`, `.settings`의 compliance 레벨, `.idea/misc.xml`, `nbproject`), `WebContent/WEB-INF/lib/**/*.jar`, `WEB-INF/web.xml`, Spring XSD 스키마 버전, 그리고 **eGovFrame (전자정부 표준프레임워크)** 까지 — 프레임워크, Spring Framework 버전, Java 레벨, `war`/`ear` 패키징, JDBC 드라이버, ORM을 뽑아냅니다. `src/`를 루트로 하는 소스 트리도 `src/main/java`와 동일한 도메인 패턴으로 스캔합니다. 보고되는 모든 버전은 빌드 파일, JAR 이름, 또는 프로젝트 안에 정의된 프로퍼티에서 읽은 값이며 프레임워크 기본값으로 추정하지 않습니다. Spring을 전혀 쓰지 않는 JVM 프로젝트 (`java-library`, `application`, 서블릿만 쓰는 `war`)는 `framework: null`인 Java로 보고되며 Spring으로 잡히지 않습니다.
+
 감지 규칙과 각 scanner가 추출하는 내용은 [docs/ko/stacks.md](docs/ko/stacks.md) 참고.
 
 ---
@@ -393,7 +395,7 @@ npx claudeos-core health
 
 그 결과는 구체적으로 세 가지 차이로 이어집니다:
 
-1. **결정론적 스택 감지.** 같은 프로젝트 + 같은 코드 = 같은 출력. "이번엔 Claude가 다르게 나왔네"가 없습니다.
+1. **결정론적 스택 감지와 구조.** 같은 프로젝트 + 같은 코드 = 같은 스캔 결과, 같은 8개 섹션 `CLAUDE.md` 레이아웃. 섹션 안의 문장은 여전히 LLM이 쓰지만, LLM에게 주어지는 사실과 채워야 할 형태는 고정되어 있습니다.
 2. **존재하지 않는 경로를 만들지 않음.** Pass 3 prompt에 허용된 모든 소스 경로가 명시적으로 들어가기 때문에, Claude는 없는 경로를 인용할 수 없습니다.
 3. **멀티 스택 인지.** 같은 실행 안에서 백엔드와 프론트엔드 도메인이 서로 다른 분석 prompt를 사용합니다.
 
@@ -429,7 +431,7 @@ npx claudeos-core health
 
 파일은 4개, 모두 Pass 4가 작성합니다:
 
-- `decision-log.md` — append-only 형식의 "X 대신 Y를 선택한 이유" 기록. `pass2-merged.json`에서 시드.
+- `decision-log.md` — append-only 형식의 "X 대신 Y를 선택한 이유" 기록. `pass2-merged.json`에서 시드. (압축 대상 아님)
 - `failure-patterns.md` — frequency / importance 점수가 매겨진 반복 오류 모음.
 - `compaction.md` — 시간이 흐르면서 메모리가 자동으로 압축되는 방식.
 - `auto-rule-update.md` — 새 룰로 승격되어야 할 패턴.
@@ -437,7 +439,7 @@ npx claudeos-core health
 이 레이어를 시간이 흘러도 유지하기 위한 두 가지 명령어:
 
 ```bash
-# failure-patterns 로그 압축 (주기적으로 실행)
+# failure-patterns 로그 압축 (주기적으로 실행; decision-log.md는 건드리지 않음)
 npx claudeos-core memory compact
 
 # 자주 발생하는 failure pattern을 제안 룰로 승격

package/README.md

@@ -2,7 +2,7 @@
 
 [![npm version](https://img.shields.io/npm/v/claudeos-core.svg?logo=npm&label=npm)](https://www.npmjs.com/package/claudeos-core)
 [![CI](https://img.shields.io/github/actions/workflow/status/claudeos-core/claudeos-core/test.yml?branch=master&logo=github&label=CI)](https://github.com/claudeos-core/claudeos-core/actions/workflows/test.yml)
-[![tests](https://img.shields.io/badge/tests-736%20passing-brightgreen?logo=node.js&logoColor=white)](https://github.com/claudeos-core/claudeos-core/actions/workflows/test.yml)
+[![tests](https://img.shields.io/badge/tests-974%20passing-brightgreen?logo=node.js&logoColor=white)](https://github.com/claudeos-core/claudeos-core/actions/workflows/test.yml)
 [![node](https://img.shields.io/node/v/claudeos-core.svg?logo=node.js&logoColor=white&label=node)](https://nodejs.org/)
 [![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)
@@ -25,7 +25,7 @@ Claude Code falls back to framework defaults every session. Your team uses **MyB
 
 **ClaudeOS-Core regenerates them deterministically, from your actual source code.** A Node.js scanner reads first (stack, ORM, package layout, file paths). A 4-pass Claude pipeline then writes the full set — `CLAUDE.md` + auto-loaded `.claude/rules/` + standards + skills — constrained by an explicit path allowlist that the LLM cannot escape. Five validators verify the output before it ships.
 
-The result: same input → byte-identical output, in any of 10 languages, with no invented paths. (Detail in [What makes this different](#what-makes-this-different) below.)
+The result: same input → the same 8-section `CLAUDE.md` structure, validated by the same 25 structural checks in any of 10 languages, with every cited source path verified against disk. (Detail in [What makes this different](#what-makes-this-different) below.)
 
 A separate [Memory Layer](#memory-layer-optional-for-long-running-projects) is seeded for long-running projects.
 
@@ -115,7 +115,7 @@ Run on [`spring-boot-realworld-example-app`](https://github.com/gothinkster/spri
 </details>
 
 <details>
-<summary><strong>What ends up in your <code>CLAUDE.md</code> (real excerpt — Section 1 + 2)</strong></summary>
+<summary><strong>What ends up in your <code>CLAUDE.md</code> (real excerpt — Section 1 + 2; headings demoted to <code>####</code> for README rendering, the real file uses <code>## N.</code>)</strong></summary>
 
 ```markdown
 # CLAUDE.md — spring-boot-realworld-example-app
@@ -148,7 +148,7 @@ an XML-driven MyBatis persistence layer and JWT-based authentication.
 | Test Stack | JUnit Jupiter 5, Mockito, AssertJ, rest-assured, spring-mock-mvc |
 ```
 
-Every value above — exact dependency coordinates, the `dev.db` filename, the `V1__create_tables.sql` migration name, "no JPA" — is extracted by the scanner from `build.gradle` / `application.properties` / source tree before Claude writes the file. Nothing is guessed.
+The stack rows (Java 11, Spring Boot 2.6.3, Gradle, MyBatis, SQLite, port 8080) come from the deterministic scanner. The finer details — exact dependency coordinates, the `dev.db` filename, the `V1__create_tables.sql` migration name, "no JPA" — are read from `build.gradle` / `application.properties` / the source tree by Pass 1 with the scanner's facts as constraints, then cross-checked by the validators. Nothing is taken from framework defaults.
 
 </details>
 
@@ -309,7 +309,7 @@ Categories sharing the same number prefix between `rules/` and `standard/` repre
 | You are... | The pain this removes |
 |---|---|
 | **A solo dev** starting a new project with Claude Code | "Teach Claude my conventions every session" — gone. `CLAUDE.md` + 8-category `.claude/rules/` generated in one pass. |
-| **A team lead** maintaining shared standards across repos | `.claude/rules/` drift as people rename packages, switch ORMs, or change response wrappers. ClaudeOS-Core re-syncs deterministically — same input, byte-identical output, no diff noise. |
+| **A team lead** maintaining shared standards across repos | `.claude/rules/` drift as people rename packages, switch ORMs, or change response wrappers. ClaudeOS-Core regenerates against a fixed 8-section scaffold — same structure in every repo, same validator verdict, so diffs show convention changes rather than layout noise. |
 | **Already using Claude Code** but tired of fixing generated code | Wrong response wrapper, wrong package layout, JPA when you use MyBatis, `try/catch` scattered when your project uses centralized middleware. The scanner extracts your real conventions; every Claude pass runs against an explicit path allowlist. |
 | **Onboarding to a new repo** (existing project, joining a team) | Run `init` on the repo, get a living architecture map: stack table in CLAUDE.md, per-layer rules with ✅/❌ examples, decision log seeded with "why" behind major choices (JPA vs MyBatis, REST vs GraphQL, etc.). Reading 5 files beats reading 5,000 source files. |
 | **Working in Korean / Japanese / Chinese / 7 more languages** | Most Claude Code rule generators are English-only. ClaudeOS-Core writes the full set in **10 languages** (`en/ko/ja/zh-CN/es/vi/hi/ru/fr/de`) with **byte-identical structural validation** — same `claude-md-validator` verdict regardless of output language. |
@@ -331,7 +331,7 @@ This:     Code reads your stack → Code passes confirmed facts to Claude → Cl
 
 The pipeline runs in **three stages**, with code on both sides of the LLM call:
 
-**1. Step A — Scanner (deterministic, no LLM).** A Node.js scanner walks your project root, reads `package.json` / `build.gradle` / `pom.xml` / `pyproject.toml`, parses `.env*` files (with sensitive-variable redaction for `PASSWORD/SECRET/TOKEN/JWT_SECRET/...`), classifies your architecture pattern (Java's 5 patterns A/B/C/D/E, Kotlin CQRS / multi-module, Next.js App vs. Pages Router, FSD, components-pattern), discovers domains, and builds an explicit allowlist of every source file path that exists. Output: `project-analysis.json` — the single source of truth for what follows.
+**1. Step A — Scanner (deterministic, no LLM).** A Node.js scanner walks your project root, reads `package.json` / `build.gradle` / `build.gradle.kts` / `pom.xml` / `pyproject.toml`, parses `.env*` files (with sensitive-variable redaction for `PASSWORD/SECRET/TOKEN/JWT_SECRET/...`), classifies your architecture pattern (Java's 5 patterns A/B/C/D/E, Kotlin CQRS / multi-module, Next.js App vs. Pages Router, FSD, components-pattern), discovers domains, and builds an explicit allowlist of every source file path that exists. Output: `project-analysis.json` — the single source of truth for what follows.
 
 **2. Step B — 4-Pass Claude pipeline (constrained by Step A's facts).**
 - **Pass 1** reads representative files per domain group and extracts ~50–100 conventions per domain — response wrappers, logging libraries, error handling, naming conventions, test patterns. Runs once per domain group (`max 4 domains, 40 files per group`) so context never overflows.
@@ -358,12 +358,14 @@ For per-pass details, marker-based resume, the staged-rules workaround for Claud
 
 12 stacks, auto-detected from your project files:
 
-**Backend:** Java/Spring Boot · Kotlin/Spring Boot · Node/Express · Node/Fastify · Node/NestJS · Python/Django · Python/FastAPI · Python/Flask
+**Backend:** Java/Spring Boot (and non-Boot Spring Framework, see below) · 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 projects (e.g., Spring Boot backend + Next.js frontend) work out of the box.
 
+**Legacy Java is a first-class target (v2.5.1).** Pre-Boot Spring 1.x–6.x on Gradle (`apply plugin:` era, `group:/name:/version:` notation in any order, `gradle.properties` / `apply from:` / buildSrc indirection, version catalogs, settings-only roots), Maven (Maven-2 poms, `${spring.version}` properties, `spring-framework-bom`, multi-module roots, sibling projects with no root pom), **Ant + Ivy**, **Eclipse / IntelliJ / NetBeans metadata** (`.classpath` incl. uncommitted jar references, `.settings` compliance level, `.idea/misc.xml`, `nbproject`), `WebContent/WEB-INF/lib/**/*.jar`, `WEB-INF/web.xml`, Spring XSD schema versions and **eGovFrame** are detected — framework, Spring Framework version, Java level, `war`/`ear` packaging, JDBC driver and ORM — and `src/`-rooted source trees are scanned with the same domain patterns as `src/main/java`. Every version reported is read from a build file, a jar name or a property defined in the project; nothing is assumed from a framework default. JVM projects with no Spring at all (`java-library`, `application`, servlet-only `war`) are reported as Java with `framework: null`, never as Spring.
+
 For detection rules and what each scanner extracts, see [docs/stacks.md](docs/stacks.md).
 
 ---
@@ -393,7 +395,7 @@ Most Claude Code documentation tools generate from a description (you tell the t
 
 Three concrete consequences:
 
-1. **Deterministic stack detection.** Same project + same code = same output. No "Claude rolled differently this time."
+1. **Deterministic stack detection and structure.** Same project + same code = same scan result and the same 8-section `CLAUDE.md` layout. Wording inside sections is still LLM-written; what's fixed is the facts it's given and the shape it must fill.
 2. **No invented paths.** The Pass 3 prompt explicitly lists every allowed source path; Claude can't cite paths that don't exist.
 3. **Multi-stack aware.** Backend and frontend domains use different analysis prompts in the same run.
 
@@ -429,7 +431,7 @@ Beyond the scaffolding pipeline above, ClaudeOS-Core seeds a `claudeos-core/memo
 
 Four files, all written by Pass 4:
 
-- `decision-log.md` — append-only "why we chose X over Y", seeded from `pass2-merged.json`
+- `decision-log.md` — append-only "why we chose X over Y", seeded from `pass2-merged.json` (never compacted)
 - `failure-patterns.md` — recurring errors with frequency/importance scores
 - `compaction.md` — how memory is auto-compacted over time
 - `auto-rule-update.md` — patterns that should become new rules
@@ -437,7 +439,7 @@ Four files, all written by Pass 4:
 Two commands maintain this layer over time:
 
 ```bash
-# Compact the failure-patterns log (run periodically)
+# Compact the failure-patterns log (run periodically; decision-log.md is left untouched)
 npx claudeos-core memory compact
 
 # Promote frequent failure patterns into proposed rules

package/README.ru.md

@@ -2,7 +2,7 @@
 
 [![npm version](https://img.shields.io/npm/v/claudeos-core.svg?logo=npm&label=npm)](https://www.npmjs.com/package/claudeos-core)
 [![CI](https://img.shields.io/github/actions/workflow/status/claudeos-core/claudeos-core/test.yml?branch=master&logo=github&label=CI)](https://github.com/claudeos-core/claudeos-core/actions/workflows/test.yml)
-[![tests](https://img.shields.io/badge/tests-736%20passing-brightgreen?logo=node.js&logoColor=white)](https://github.com/claudeos-core/claudeos-core/actions/workflows/test.yml)
+[![tests](https://img.shields.io/badge/tests-974%20passing-brightgreen?logo=node.js&logoColor=white)](https://github.com/claudeos-core/claudeos-core/actions/workflows/test.yml)
 [![node](https://img.shields.io/node/v/claudeos-core.svg?logo=node.js&logoColor=white&label=node)](https://nodejs.org/)
 [![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)
@@ -25,7 +25,7 @@ npx claudeos-core init
 
 **ClaudeOS-Core пересобирает их предсказуемо, прямо из исходного кода проекта.** Сначала сканер на Node.js разбирает проект и вытаскивает стек, ORM, раскладку пакетов, реальные пути к файлам. Затем четырёхпроходный пайплайн на Claude пишет полный комплект документации: `CLAUDE.md`, автоматически подгружаемые `.claude/rules/`, стандарты, навыки. Всё это происходит строго внутри явного allowlist путей — за его пределы LLM выйти не может. И прежде чем результат окажется у вас, его проверяют пять валидаторов.
 
-В итоге одинаковый вход даёт побайтово одинаковый выход на любом из 10 языков, а пути, которых нет в коде, в документации не появляются. Подробности — ниже, в разделе [В чём отличие](#в-чём-отличие).
+В итоге одинаковый вход даёт один и тот же `CLAUDE.md` из 8 фиксированных секций, проверенный одними и теми же 25 структурными проверками на любом из 10 языков, а каждый упомянутый путь к исходникам сверяется с диском. Подробности — ниже, в разделе [В чём отличие](#в-чём-отличие).
 
 Для долгоживущих проектов рядом разворачивается [Memory Layer](#memory-layer-опционально-для-долгосрочных-проектов).
 
@@ -115,7 +115,7 @@ npx claudeos-core init
 </details>
 
 <details>
-<summary><strong>Что в итоге попадает в ваш <code>CLAUDE.md</code> (реальный фрагмент — Section 1 + 2)</strong></summary>
+<summary><strong>Что в итоге попадает в ваш <code>CLAUDE.md</code> (реальный фрагмент — Section 1 + 2; заголовки понижены до <code>####</code> ради отображения в README, в настоящем файле используется <code>## N.</code>)</strong></summary>
 
 ```markdown
 # CLAUDE.md — spring-boot-realworld-example-app
@@ -148,7 +148,7 @@ an XML-driven MyBatis persistence layer and JWT-based authentication.
 | Test Stack | JUnit Jupiter 5, Mockito, AssertJ, rest-assured, spring-mock-mvc |
 ```
 
-Каждое значение в этой таблице — точные координаты зависимостей, имя файла `dev.db`, название миграции `V1__create_tables.sql`, пометка «no JPA» — сканер вычитал из `build.gradle`, `application.properties` и дерева исходников ещё до того, как Claude взялся за файл. Ничего не угадано.
+Строки о стеке (Java 11, Spring Boot 2.6.3, Gradle, MyBatis, SQLite, порт 8080) даёт детерминированный сканер. Более тонкие детали — точные координаты зависимостей, имя файла `dev.db`, название миграции `V1__create_tables.sql`, пометка «no JPA» — Pass 1 вычитывает из `build.gradle`, `application.properties` и дерева исходников, опираясь на факты сканера как на ограничения, а затем валидаторы перепроверяют их. Из умолчаний фреймворка не взято ничего.
 
 </details>
 
@@ -309,7 +309,7 @@ your-project/
 | Вы... | Какую боль это снимает |
 |---|---|
 | **Соло-разработчик**, начинающий новый проект на Claude Code | «Объяснять Claude свои соглашения каждую сессию» — больше не надо. `CLAUDE.md` и `.claude/rules/` из 8 категорий собираются за один проход. |
-| **Тимлид**, отвечающий за общие стандарты в нескольких репозиториях | Правила в `.claude/rules/` устаревают, как только переименовываются пакеты, меняются ORM или обёртки ответов. ClaudeOS-Core пересобирает их детерминированно: на одном входе всегда побайтово одинаковый выход, поэтому в diff нет шума. |
+| **Тимлид**, отвечающий за общие стандарты в нескольких репозиториях | Правила в `.claude/rules/` устаревают, как только переименовываются пакеты, меняются ORM или обёртки ответов. ClaudeOS-Core пересобирает их по фиксированному scaffold из 8 секций: одна и та же структура в каждом репозитории, один и тот же вердикт валидатора, поэтому в diff видны изменения конвенций, а не шум раскладки. |
 | **Уже использует Claude Code**, но устал чинить сгенерированный код | Не та обёртка ответа, не та раскладка пакетов, JPA вместо MyBatis, `try/catch` россыпью при том, что в проекте есть централизованный middleware. Сканер достаёт ваши настоящие соглашения, а каждый проход Claude работает только в рамках явного allowlist путей. |
 | **Подключается к новому репозиторию** (готовый проект, выход в команду) | Запустите `init` — и получите живую карту архитектуры: таблицу стека в CLAUDE.md, правила по слоям с примерами ✅/❌, decision log с ответом на вопрос «почему» по ключевым решениям (JPA vs MyBatis, REST vs GraphQL и т. д.). Прочитать пять файлов быстрее, чем пять тысяч исходников. |
 | **Пишет на корейском, японском, китайском или ещё на 7 языках** | Большинство генераторов правил для Claude Code умеют только в английский. ClaudeOS-Core выпускает полный комплект на **10 языках** (`en/ko/ja/zh-CN/es/vi/hi/ru/fr/de`) и применяет одинаковую структурную проверку независимо от языка вывода — `claude-md-validator` выдаёт один и тот же вердикт на всех. |
@@ -331,7 +331,7 @@ ClaudeOS-Core переворачивает привычный сценарий
 
 Пайплайн состоит из **трёх стадий**: детерминированный код стоит и до LLM, и после неё.
 
-**1. Step A — Scanner (детерминированно, без LLM).** Сканер на Node.js обходит корень проекта, читает `package.json`, `build.gradle`, `pom.xml`, `pyproject.toml`, разбирает файлы `.env*` (чувствительные переменные `PASSWORD/SECRET/TOKEN/JWT_SECRET/...` при этом редактируются), классифицирует архитектурный паттерн (5 паттернов Java A/B/C/D/E, Kotlin CQRS / multi-module, Next.js App vs Pages Router, FSD, components-pattern), находит домены и собирает явный allowlist путей всех существующих исходных файлов. На выходе — `project-analysis.json`, единый источник истины для всех последующих шагов.
+**1. Step A — Scanner (детерминированно, без LLM).** Сканер на Node.js обходит корень проекта, читает `package.json`, `build.gradle`, `build.gradle.kts`, `pom.xml`, `pyproject.toml`, разбирает файлы `.env*` (чувствительные переменные `PASSWORD/SECRET/TOKEN/JWT_SECRET/...` при этом редактируются), классифицирует архитектурный паттерн (5 паттернов Java A/B/C/D/E, Kotlin CQRS / multi-module, Next.js App vs Pages Router, FSD, components-pattern), находит домены и собирает явный allowlist путей всех существующих исходных файлов. На выходе — `project-analysis.json`, единый источник истины для всех последующих шагов.
 
 **2. Step B — четырёхпроходный пайплайн на Claude (опирается на факты из Step A).**
 - **Pass 1** читает по группе доменов представительные файлы и достаёт по 50–100 соглашений на домен: обёртки ответов, библиотеки логирования, обработку ошибок, нейминг, паттерны тестов. Запускается по разу на каждую группу доменов (`max 4 domains, 40 files per group`), поэтому контекст не переполняется.
@@ -358,12 +358,14 @@ ClaudeOS-Core переворачивает привычный сценарий
 
 12 стеков, которые определяются автоматически по файлам проекта:
 
-**Backend:** Java/Spring Boot · Kotlin/Spring Boot · Node/Express · Node/Fastify · Node/NestJS · Python/Django · Python/FastAPI · Python/Flask
+**Backend:** Java/Spring Boot (а также Spring Framework без 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
 
 Многостековые проекты (например, Spring Boot на бэкенде и Next.js на фронтенде) поддерживаются из коробки.
 
+**Legacy-Java — полноценная цель (v2.5.1).** Распознаётся Spring 1.x–6.x без Boot: Gradle (эпоха `apply plugin:`, нотация `group:/name:/version:` в любом порядке, разрешение переменных через `gradle.properties` / `apply from:` / buildSrc, каталоги версий, корни только с `settings.gradle`), Maven (POM времён Maven 2, свойства `${spring.version}`, `spring-framework-bom`, многомодульные корни, соседние проекты без корневого POM), **Ant + Ivy**, **метаданные Eclipse / IntelliJ / NetBeans** (`.classpath`, включая ссылки на JAR, которых нет в репозитории, уровень compliance из `.settings`, `.idea/misc.xml`, `nbproject`), `WebContent/WEB-INF/lib/**/*.jar`, `WEB-INF/web.xml`, версии XSD-схем Spring и **eGovFrame** — вместе с фреймворком, версией Spring Framework, уровнем Java, упаковкой `war`/`ear`, JDBC-драйвером и ORM. Деревья исходников с корнем `src/` сканируются теми же доменными шаблонами, что и `src/main/java`. Любая выводимая версия прочитана из файла сборки, имени JAR или свойства, определённого в самом проекте; ничего не берётся из значений по умолчанию фреймворка. JVM-проекты вовсе без Spring (`java-library`, `application`, чисто сервлетный `war`) выводятся как Java с `framework: null` и никогда как Spring.
+
 Правила детекции и то, что вытаскивает каждый сканер, описаны в [docs/ru/stacks.md](docs/ru/stacks.md).
 
 ---
@@ -393,7 +395,7 @@ npx claudeos-core health
 
 На практике это даёт три конкретных эффекта:
 
-1. **Детерминированная детекция стека.** Тот же проект и тот же код всегда дают тот же результат. Никаких «в этот раз Claude как-то иначе всё интерпретировал».
+1. **Детерминированная детекция стека и структуры.** Тот же проект и тот же код всегда дают тот же результат сканирования и ту же раскладку `CLAUDE.md` из 8 секций. Формулировки внутри секций по-прежнему пишет LLM; зафиксированы факты, которые он получает, и форма, которую он обязан заполнить.
 2. **Выдуманных путей не появляется.** В промпте Pass 3 явно перечислены все разрешённые пути в исходниках, поэтому Claude не может сослаться на то, чего нет.
 3. **Учёт нескольких стеков сразу.** В рамках одного запуска бэкенд- и фронтенд-домены анализируются разными промптами.
 
@@ -429,7 +431,7 @@ npx claudeos-core health
 
 Внутри четыре файла, и все их пишет Pass 4:
 
-- `decision-log.md` — append-only журнал «почему выбрали X, а не Y»; засевается из `pass2-merged.json`.
+- `decision-log.md` — append-only журнал «почему выбрали X, а не Y»; засевается из `pass2-merged.json` (никогда не уплотняется).
 - `failure-patterns.md` — повторяющиеся ошибки с оценками frequency / importance.
 - `compaction.md` — описание того, как память автоматически уплотняется со временем.
 - `auto-rule-update.md` — паттерны, которые стоит превратить в новые правила.
@@ -437,7 +439,7 @@ npx claudeos-core health
 Поддерживать слой со временем помогают две команды:
 
 ```bash
-# Уплотнить лог failure-patterns (запускайте периодически)
+# Уплотнить лог failure-patterns (запускайте периодически; decision-log.md не трогается)
 npx claudeos-core memory compact
 
 # Превратить часто встречающиеся failure-паттерны в предложенные правила