claudeos-core 2.4.1 → 2.4.3

package/README.ja.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)
 
-**Claude Code が初回の試行から _あなたのプロジェクトの_ コンベンションに従うようにします — generic な既定値ではなく。**
-
-deterministic な Node.js scanner がコードを先に読み、4-pass の Claude パイプラインが抽出された事実を基に完全なドキュメントセットを書き込みます — `CLAUDE.md` + 自動ロードされる `.claude/rules/` + standards + skills + L4 memory。10 種の出力言語、5 つの post-generation validator、LLM がコードに存在しないファイルや framework をでっち上げないようにする明示的な path allowlist。
-
-[**12 stacks**](#supported-stacks) で即座に動作 (monorepo 含む) — `npx` コマンド一つ、設定不要、中断時 resume-safe、再実行 idempotent。
+**プロジェクトのソースコードを直接読み取り、`CLAUDE.md` と `.claude/rules/` を自動生成する CLI ツールです。Node.js のスキャナ、4-pass の Claude パイプライン、5 つの validator が連動して動きます。12 スタックと 10 言語に対応し、コードに存在しないパスを作り出すことはありません。**
 
 ```bash
 npx claudeos-core init
 ```
 
+[**12 スタック**](#supported-stacks)に対応しており、モノレポでもそのまま動きます。コマンド 1 行で完結し、設定ファイルは不要、途中で止まっても再開でき、何度実行しても安全です。
+
 [🇺🇸 English](README.md) · [🇰🇷 한국어](README.ko.md) · [🇨🇳 中文](README.zh-CN.md) · [🇪🇸 Español](README.es.md) · [🇻🇳 Tiếng Việt](README.vi.md) · [🇮🇳 हिन्दी](README.hi.md) · [🇷🇺 Русский](README.ru.md) · [🇫🇷 Français](README.fr.md) · [🇩🇪 Deutsch](README.de.md)
 
 ---
 
-## このツールは何ですか？
-
-あなたは Claude Code を使っています。強力なツールですが、毎セッションが新しく始まります — _あなたの_ プロジェクトがどう構成されているかの記憶がありません。そのため、チームが実際に行っているパターンとほとんどマッチしない「generally good」な既定値に fallback します:
+## これは何?
 
-- チームでは **MyBatis** を使っているのに、Claude は JPA repository を生成する。
-- 応答 wrapper は `ApiResponse.ok()` なのに、Claude は `ResponseEntity.success()` と書く。
-- パッケージは layer-first (`controller/order/`) なのに、Claude は domain-first (`order/controller/`) を作る。
-- エラーは centralized middleware を通すのに、Claude はあらゆる endpoint に `try/catch` を撒き散らす。
+Claude Code は新しいセッションを始めるたびに、フレームワークの一般的なデフォルト値に戻ります。チームでは **MyBatis** を使っているのに JPA のコードを書いてしまったり、レスポンスラッパーが `ApiResponse.ok()` なのに `ResponseEntity.success()` で書いたりします。パッケージを layer-first で組んでいるのに、生成されるのは domain-first というケースも珍しくありません。リポジトリごとに `.claude/rules/` を手書きすれば解決はしますが、コードが育つにつれてルールのほうが追いつかなくなります。
 
-プロジェクトごとに `.claude/rules/` セットがあれば良いのですが — Claude Code が毎セッション自動ロードしてくれる — 新しい repo ごとに手で書くのは何時間もかかり、コードが進化するにつれ drift していきます。
+**ClaudeOS-Core は、実際のソースコードから一貫した結果でこれを再生成します。** まず Node.js のスキャナがプロジェクトを読み、スタック・ORM・パッケージ構成・ファイルパスを把握します。次に 4-pass の Claude パイプラインがドキュメント一式を書き上げます。`CLAUDE.md`、自動ロードされる `.claude/rules/`、standards、skills のすべてが、明示的なパス allowlist の範囲内に収まります。LLM はこの範囲を超えられません。最後に 5 つの validator が、出力する前に結果を検証します。
 
-**ClaudeOS-Core は実際のソースコードからそれをあなたの代わりに書きます。** deterministic な Node.js scanner がプロジェクトを先に読み (スタック、ORM、パッケージ layout、コンベンション、ファイルパス)、4-pass の Claude パイプラインが抽出された事実を完全なドキュメントセットに変換します:
+そのため、同じ入力からは常に同じ出力が返ります。10 言語のどれを選んでも byte 単位で完全に一致し、コードに存在しないパスが紛れ込むこともありません。(詳しくは下の[何が違うのか](#何が違うのか)を参照。)
 
-- **`CLAUDE.md`** — Claude が毎セッション最初に読むプロジェクトインデックス
-- **`.claude/rules/`** — カテゴリごとに自動ロードされる rules (`00.core` / `10.backend` / `20.frontend` / `30.security-db` / `40.infra` / `60.memory` / `70.domains` / `80.verification`)
-- **`claudeos-core/standard/`** — 参照ドキュメント (各 rule の「なぜ」)
-- **`claudeos-core/skills/`** — 再利用可能なパターン (CRUD scaffolding、ページテンプレート)
-- **`claudeos-core/memory/`** — プロジェクトと共に成長する decision log + failure pattern
-
-scanner が Claude に明示的な path allowlist を渡すため、LLM は **コードに存在しないファイルや framework をでっち上げることができません**。5 つの post-generation validator (`claude-md-validator`, `content-validator`, `pass-json-validator`, `plan-validator`, `sync-checker`) が出力を ship 前に検証します — language-invariant なので、英語で生成しても、日本語で生成しても、他の 8 言語のいずれで生成しても同じルールが適用されます。
-
-```
-Before:  あなた → Claude Code → 「概ね良い」コード → 毎回手作業で修正
-After:   あなた → Claude Code → あなたのプロジェクトに一致するコード → そのまま使える
-```
+長く運用するプロジェクトには、[Memory Layer](#memory-layer-任意長期プロジェクト向け) も合わせて生成されます。
 
 ---
 
-## 実際のプロジェクトでのデモ
+## 実プロジェクトで動かしてみる
 
-[`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。結果: **75 generated files**、合計時間 **53 分**、すべての validator ✅。
+[`spring-boot-realworld-example-app`](https://github.com/gothinkster/spring-boot-realworld-example-app) で実行してみました。Java 11 · Spring Boot 2.6 · MyBatis · SQLite · 187 個のソースファイル。結果は **75 ファイル生成**、所要時間 **53 分**、すべての validator が ✅ でした。
 
 <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>📺 ターミナル出力 (テキスト版、検索・コピー用)</strong></summary>
+<summary><strong>ターミナル出力 (テキスト版、検索とコピー用)</strong></summary>
 
 ```text
 ╔════════════════════════════════════════════════════╗
@@ -93,18 +75,18 @@ After:   あなた → Claude Code → あなたのプロジェクトに一致
     [██████████░░░░░░░░░░] 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 @@ After:   あなた → Claude Code → あなたのプロジェクトに一致
 </details>
 
 <details>
-<summary><strong>📄 生成された <code>CLAUDE.md</code> の抜粋 (実際の出力 — Section 1 + 2)</strong></summary>
+<summary><strong>実際の <code>CLAUDE.md</code> に入る内容 (実例の抜粋 — Section 1 + 2)</strong></summary>
 
 ```markdown
 # CLAUDE.md — spring-boot-realworld-example-app
@@ -142,7 +124,7 @@ After:   あなた → Claude Code → あなたのプロジェクトに一致
 > 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 |
 ```
 
-上の値はすべて — 正確な依存関係の coordinates、`dev.db` のファイル名、`V1__create_tables.sql` のマイグレーション名、「no JPA」まで — Claude がファイルを書く前に scanner が `build.gradle` / `application.properties` / ソースツリーから抽出したものです。何一つ推測されていません。
+上の表の値はすべて、正確な dependency の座標も、`dev.db` というファイル名も、`V1__create_tables.sql` というマイグレーション名も、「no JPA」という事実も、Claude がファイルを書く前にスキャナが `build.gradle`、`application.properties`、ソースツリーから直接読み取った内容です。推測した値は 1 つも入っていません。
 
 </details>
 
 <details>
-<summary><strong>🛡️ 自動ロードされる実際の rule ファイル (<code>.claude/rules/10.backend/01.controller-rules.md</code>)</strong></summary>
+<summary><strong>実際に自動ロードされるルール (<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) {
 ```
 ````
 
-`paths: ["**/*"]` の glob は、プロジェクト内のいずれかのファイルを編集するたびに Claude Code がこの rule を自動ロードすることを意味します。rule 内のクラス名、パッケージパス、exception handler はすべて scan されたソースから直接抽出されています — プロジェクトの実際の `CustomizeExceptionHandler` と `JacksonCustomizations` を含めて。
+`paths: ["**/*"]` の glob は、プロジェクト内のどのファイルを編集しても Claude Code がこのルールを自動でロードする、という意味です。ルール内のクラス名、パッケージパス、exception handler はすべてスキャン済みのソースから直接持ってきたもので、プロジェクトの実際の `CustomizeExceptionHandler` や `JacksonCustomizations` がそのまま反映されています。
 
 </details>
 
 <details>
-<summary><strong>🧠 自動生成された <code>decision-log.md</code> シード (実際の出力)</strong></summary>
+<summary><strong>自動生成された <code>decision-log.md</code> のシード (実例の抜粋)</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 @@ public ResponseEntity<?> create(@RequestBody NewArticleParam p) {
   split the persistence model.
 ```
 
-Pass 4 は `pass2-merged.json` から抽出したアーキテクチャ上の決定事項で `decision-log.md` を seed します — その後のセッションでもコードベースが _このように見える_ という事実だけでなく、_なぜ_ そう見えるのかも記憶できるように。すべての選択肢 (「JPA/Hibernate」「MyBatis-Plus」) と帰結は実際の `build.gradle` の dependency ブロックに基づいています。
+Pass 4 は `pass2-merged.json` から取り出したアーキテクチャ上の決定事項を `decision-log.md` にあらかじめ書き込んでおきます。次のセッションが始まったときに、コードベースが _なぜ今の形になっているのか_ まで思い出せるようにするためです。並んでいる選択肢 ("JPA/Hibernate"、"MyBatis-Plus") もその帰結も、すべて実際の `build.gradle` の dependency ブロックから拾ってきた内容です。
 
 </details>
 
 ---
 
-## Quick Start
+## テスト済みプロジェクト
 
-**前提条件:** Node.js 18+、[Claude Code](https://docs.anthropic.com/en/docs/claude-code) がインストール済みかつ認証済み。
+ClaudeOS-Core は実際の OSS プロジェクトで測定したリファレンスベンチマークを同梱しています。公開リポジトリで使ってみた方は、ぜひ [issue を開いてください](https://github.com/claudeos-core/claudeos-core/issues)。表に追加します。
+
+| プロジェクト | スタック | Scanned → Generated | ステータス |
+|---|---|---|---|
+| [`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 | ✅ 5 つの validator すべて通過 |
+
+---
+
+## クイックスタート
+
+**前提条件:** Node.js 18+、[Claude Code](https://docs.anthropic.com/en/docs/claude-code) がインストール済みで認証済みであること。
 
 ```bash
 # 1. プロジェクトのルートに移動
 cd my-spring-boot-project
 
-# 2. init を実行 (コードを解析し、Claude にルール作成を依頼します)
+# 2. init を実行 (コードを解析し、ルール作成を Claude に依頼します)
 npx claudeos-core init
 
-# 3. 完了。Claude Code を開いてコーディングを開始 — ルールは既にロード済みです。
+# 3. 完了。Claude Code を開いて作業を始めれば、ルールはすでにロードされています。
 ```
 
-`init` 完了後に **得られるもの**:
+`init` が終わると、次のようなファイル群ができあがります。
 
 ```
 your-project/
 ├── .claude/
-│   └── rules/                    ← Claude Code が自動ロード
+│   └── rules/                    ← Claude Code が自動でロード
 │       ├── 00.core/              (共通ルール — 命名、アーキテクチャ)
-│       ├── 10.backend/           (バックエンドスタックのルール、該当する場合)
-│       ├── 20.frontend/           (フロントエンドスタックのルール、該当する場合)
-│       ├── 30.security-db/       (セキュリティ & DB のコンベンション)
+│       ├── 10.backend/           (バックエンドのスタックルール、該当する場合)
+│       ├── 20.frontend/          (フロントエンドのスタックルール、該当する場合)
+│       ├── 30.security-db/       (セキュリティと DB のコンベンション)
 │       ├── 40.infra/             (env、ロギング、CI/CD)
-│       ├── 50.sync/              (ドキュメント同期のリマインダ — rules only)
-│       ├── 60.memory/            (memory rules — Pass 4、rules only)
+│       ├── 50.sync/              (ドキュメント同期のリマインダー — rules のみ)
+│       ├── 60.memory/            (メモリのルール — Pass 4、rules のみ)
 │       ├── 70.domains/{type}/    (ドメイン別ルール、type = backend|frontend)
-│       └── 80.verification/      (テスト戦略 + ビルド検証のリマインダ)
+│       └── 80.verification/      (テスト戦略 + ビルド検証のリマインダー)
 ├── claudeos-core/
-│   ├── standard/                 ← 参照ドキュメント (カテゴリ構造をミラー)
+│   ├── standard/                 ← リファレンスドキュメント (カテゴリ構成をミラー)
 │   │   ├── 00.core/              (プロジェクト概要、アーキテクチャ、命名)
-│   │   ├── 10.backend/           (バックエンド reference — バックエンドスタック時)
-│   │   ├── 20.frontend/          (フロントエンド reference — フロントエンドスタック時)
-│   │   ├── 30.security-db/       (セキュリティ & DB の reference)
-│   │   ├── 40.infra/             (env / ロギング / CI-CD の reference)
-│   │   ├── 70.domains/{type}/    (ドメイン別 reference)
-│   │   ├── 80.verification/      (ビルド / 起動 / テスト reference — standard only)
-│   │   └── 90.optional/          (スタック固有の追加 — standard only)
-│   ├── skills/                   (Claude が適用可能な再利用パターン)
-│   ├── guide/                    (一般的なタスク用 how-to ガイド)
+│   │   ├── 10.backend/           (バックエンドのリファレンス — バックエンドスタック時)
+│   │   ├── 20.frontend/          (フロントエンドのリファレンス — フロントエンドスタック時)
+│   │   ├── 30.security-db/       (セキュリティ & DB のリファレンス)
+│   │   ├── 40.infra/             (env / ロギング / CI-CD のリファレンス)
+│   │   ├── 70.domains/{type}/    (ドメイン別リファレンス)
+│   │   ├── 80.verification/      (ビルド / 起動 / テストのリファレンス — standard のみ)
+│   │   └── 90.optional/          (スタック別の追加資料 — standard のみ)
+│   ├── skills/                   (Claude が適用できる再利用可能パターン)
+│   ├── guide/                    (よくあるタスクの how-to ガイド)
 │   ├── database/                 (スキーマ概要、マイグレーションガイド)
-│   ├── mcp-guide/                (MCP 統合のメモ)
+│   ├── mcp-guide/                (MCP 連携メモ)
 │   └── memory/                   (decision log、failure patterns、compaction)
 └── CLAUDE.md                     (Claude が最初に読むインデックス)
 ```
 
-`rules/` と `standard/` で同じ番号 prefix を共有するカテゴリは、同一の概念領域を表します (例: `10.backend` rules ↔ `10.backend` standards)。Rules-only カテゴリ: `50.sync` (ドキュメント同期リマインダ)、`60.memory` (Pass 4 memory)。Standard-only カテゴリ: `90.optional` (強制力のないスタック固有の追加)。それ以外の prefix (`00`、`10`、`20`、`30`、`40`、`70`、`80`) は `rules/` と `standard/` の **両方** に存在します。これで Claude Code はあなたのプロジェクトを把握できます。
+同じ番号 prefix を持つカテゴリは、`rules/` と `standard/` の両方で同じ概念領域を指します (例: `10.backend` ルール ↔ `10.backend` standard)。rules にしかないカテゴリは `50.sync` (ドキュメント同期のリマインダー) と `60.memory` (Pass 4 メモリ)、standard にしかないカテゴリは `90.optional` (強制力のないスタック別の追加資料) です。それ以外の prefix (`00`、`10`、`20`、`30`、`40`、`70`、`80`) は両方に存在します。ここまで終われば、Claude Code はもうプロジェクトを把握した状態です。
 
 ---
 
-## 誰のためのツールですか？
+## 誰のためのツール?
 
-| あなたが... | このツールが取り除く pain |
+| こんな方に | このツールが解消する痛み |
 |---|---|
-| **Claude Code で新規プロジェクトを始めるソロ開発者** | 「毎セッション Claude にコンベンションを教える」が消える。`CLAUDE.md` + 8 カテゴリの `.claude/rules/` が一回の pass で生成される。 |
-| **複数 repo にまたがる共有標準を維持するチームリード** | パッケージ名変更、ORM 切り替え、response wrapper 変更で `.claude/rules/` が drift。ClaudeOS-Core は deterministic に再同期 — 同じ入力 → byte-identical な出力、diff noise なし。 |
-| **既に Claude Code を使っているが生成コードの修正に疲れた人** | 間違った response wrapper、間違ったパッケージ layout、MyBatis を使っているのに JPA、centralized middleware なのに `try/catch` 撒き散らし。scanner が本物のコンベンションを抽出し、すべての Claude pass が明示的な path allowlist に対して走ります。 |
-| **新しい repo への onboarding** (既存プロジェクト、チームに参加) | repo で `init` を実行するだけで、生きた architecture map が手に入る: CLAUDE.md のスタック表、レイヤごとのルール (✅/❌ 例つき)、主要な選択 ("なぜ") を seed した decision log (JPA vs MyBatis、REST vs GraphQL など)。5 ファイルを読む方が 5,000 ソースファイルを読むより速い。 |
-| **日本語 / 韓国語 / 中国語 / 他 7 言語で作業** | 大半の Claude Code rule generator は英語のみ。ClaudeOS-Core は **10 言語** (`en/ko/ja/zh-CN/es/vi/hi/ru/fr/de`) で完全なセットを書き、**byte-identical な構造検証** — 出力言語に関係なく同じ `claude-md-validator` の verdict。 |
-| **monorepo で作業** (Turborepo、pnpm/yarn workspaces、Lerna) | 1 回の実行で backend + frontend のドメインが個別 prompt で解析される。`apps/*/` と `packages/*/` は自動的に walk され、スタック別のルールが `70.domains/{type}/` 配下に emit される。 |
-| **OSS 貢献または実験** | 出力は gitignore-friendly — `claudeos-core/` はローカル作業ディレクトリ、ship が必要なのは `CLAUDE.md` + `.claude/` のみ。中断時 resume-safe、再実行 idempotent (`--force` なしなら手動編集は保持される)。 |
+| **Claude Code で新規プロジェクトを始める個人開発者** | セッションのたびに Claude へコンベンションを教え直す手間がなくなります。`CLAUDE.md` と 8 カテゴリの `.claude/rules/` を一発で生成します。 |
+| **複数リポジトリで共有標準を維持するチームリード** | パッケージ名の変更や ORM の差し替え、レスポンスラッパーの変更があるたびに `.claude/rules/` がついていけずズレていく問題。ClaudeOS-Core ならいつ走らせても同じ手順で再同期できます。同じ入力からは byte 単位で同じ出力が出るので、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` の判定はどの言語でも同じです。 |
+| **モノレポで作業する方** (Turborepo、pnpm/yarn workspaces、Lerna) | 1 回の実行でバックエンドとフロントエンドのドメインを別々の prompt で解析します。`apps/*/` と `packages/*/` も自動で巡回し、スタック別ルールは `70.domains/{type}/` の下に書き出します。 |
+| **OSS への貢献や検証用途で使う方** | 出力は gitignore に優しい構成です。`claudeos-core/` はローカルの作業ディレクトリで、リポジトリに含めるのは `CLAUDE.md` と `.claude/` だけで足ります。途中で止まっても再開でき、再実行しても安全です (手で編集したルールは `--force` を付けない限りそのまま残ります)。 |
 
-**適していないケース:** scan 段階を経ずに day-one から動く agents/skills/rules の one-size-fits-all なプリセットバンドルが欲しい場合 (どのツールがどこに適しているかは [docs/comparison.md](docs/ja/comparison.md) を参照)、もしくはプロジェクトが [サポート対象スタック](#supported-stacks) のいずれにもまだ該当しない場合、または単一の `CLAUDE.md` だけ欲しい場合 (ビルトインの `claude /init` で十分 — 別ツールを入れる必要はありません)。
+**向かないケース:** スキャンを挟まずに初日からそのまま使える万能なプリセット詰め合わせが欲しい場合 (どの道具がどこに合うかは [docs/ja/comparison.md](docs/ja/comparison.md) を参照)、プロジェクトが[サポート対象スタック](#supported-stacks)のいずれにもまだ当てはまらない場合、もしくは `CLAUDE.md` が 1 つあれば足りる場合。最後のケースなら標準搭載の `claude /init` で十分で、別のツールを入れる必要はありません。
 
 ---
 
-## どのように動作しますか？
+## 仕組み
 
-ClaudeOS-Core は通常の Claude Code ワークフローを反転させます:
+ClaudeOS-Core は、よくある Claude Code のワークフローの順序をひっくり返します。
 
 ```
-通常:    人がプロジェクトを説明 → Claude がスタックを推測 → Claude が docs を作成
-このツール: コードがスタックを読む → コードが確定した事実を Claude に渡す → Claude が事実から docs を作成
+通常:    ユーザがプロジェクトを説明 → Claude がスタックを推測 → Claude が文書を作成
+本ツール: コードがスタックを解析     → 確定した事実を Claude に渡す → Claude は事実だけで文書を作成
 ```
 
-パイプラインは **3 段階** で実行され、LLM 呼び出しの両側にコードがあります:
+パイプラインは **3 段階**で動きます。LLM を呼ぶ前にも後にも、コードが間に挟まる構成です。
 
-**1. Step A — Scanner (deterministic、LLM なし)。** Node.js scanner がプロジェクトルートを walk し、`package.json` / `build.gradle` / `pom.xml` / `pyproject.toml` を読み、`.env*` ファイルをパースし (`PASSWORD/SECRET/TOKEN/JWT_SECRET/...` のような sensitive な変数は redaction)、architecture pattern を分類し (Java の 5 パターン A/B/C/D/E、Kotlin CQRS / multi-module、Next.js App vs Pages Router、FSD、components-pattern)、ドメインを発見し、存在するすべてのソースファイルパスの明示的 allowlist を構築します。出力: `project-analysis.json` — 以降のすべての段階の単一の source of truth です。
+**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 として扱います。
 
-**2. Step B — 4-Pass Claude パイプライン (Step A の事実によって制約される)。**
-- **Pass 1** はドメイングループごとに代表ファイルを読み、ドメインあたり ~50–100 のコンベンションを抽出します — response wrapper、logging library、error handling、naming convention、test pattern。ドメイングループごとに 1 回実行される (`max 4 domains, 40 files per group`) ため context が overflow しません。
-- **Pass 2** はドメインごとの解析をすべてプロジェクト全体の像にマージし、ドメイン間で意見が割れたときは支配的なコンベンションを選びます。
-- **Pass 3** は `CLAUDE.md` + `.claude/rules/` + `claudeos-core/standard/` + skills + guides を書きます — stage に分割 (`3a` facts → `3b-core/3b-N` rules+standards → `3c-core/3c-N` skills+guides → `3d-aux` database+mcp-guide) されるため、`pass2-merged.json` が大きい場合でも各 stage の prompt が LLM の context window に収まります。≥16 ドメインのプロジェクトでは 3b/3c を ≤15 ドメインの batch に sub-divide します。
-- **Pass 4** は L4 memory layer (`decision-log.md`、`failure-patterns.md`、`compaction.md`、`auto-rule-update.md`) を seed し、universal な scaffold rules を追加します。Pass 4 は **`CLAUDE.md` の修正を禁止** されています — Pass 3 の Section 8 が authoritative です。
+**2. Step B — 4-pass の Claude パイプライン (Step A の事実を制約として動作)。**
+- **Pass 1** はドメイングループごとに代表ファイルを読み、ドメインあたり 50 〜 100 個のコンベンション (レスポンスラッパー、ロギングライブラリ、エラー処理、命名規則、テストパターンなど) を抽出します。ドメイングループごとに 1 回ずつ実行する設計 (`max 4 domains, 40 files per group`) なので、context があふれることはありません。
+- **Pass 2** はドメインごとの解析結果をプロジェクト全体の像にまとめます。ドメイン間で食い違いがあれば、最も多く使われているコンベンションを採用します。
+- **Pass 3** は `CLAUDE.md`、`.claude/rules/`、`claudeos-core/standard/`、skills、guides を書き上げます。段階を分けて (`3a` facts → `3b-core/3b-N` rules+standards → `3c-core/3c-N` skills+guides → `3d-aux` database+mcp-guide) 進めるので、`pass2-merged.json` が大きくなっても各段階の prompt が LLM の context window に収まります。ドメインが 16 個以上ある場合は、3b/3c をさらに 15 ドメイン以下のバッチへ分割します。
+- **Pass 4** は L4 メモリレイヤー (`decision-log.md`、`failure-patterns.md`、`compaction.md`、`auto-rule-update.md`) をシードし、共通の scaffold ルールを追加します。Pass 4 は **`CLAUDE.md` を絶対に変更しません**。Pass 3 の Section 8 が唯一の権限を持ちます。
 
-**3. Step C — Verification (deterministic、LLM なし)。** 5 つの validator が出力を検査します:
-- `claude-md-validator` — `CLAUDE.md` に対する 25 個の構造チェック (8 sections、H3/H4 count、memory file uniqueness、T1 canonical heading invariant)。Language-invariant: `--lang` に関係なく同じ verdict。
-- `content-validator` — 10 個の content チェック。path-claim 検証 (`STALE_PATH` が捏造された `src/...` 参照を検出) と MANIFEST drift 検出を含む。
-- `pass-json-validator` — Pass 1/2/3/4 JSON well-formedness + stack-aware section count。
-- `plan-validator` — plan ↔ disk の整合性 (legacy、v2.1.0 以降ほぼ no-op)。
-- `sync-checker` — 7 個の追跡対象ディレクトリにわたる disk ↔ `sync-map.json` 登録の整合性。
+**3. Step C — 検証 (LLM なしの決定論的処理)。** 5 つの validator が結果を検査します。
+- `claude-md-validator` — `CLAUDE.md` に対する 25 種類の構造チェック (8 sections、H3/H4 の個数、メモリファイルの一意性、T1 canonical heading の不変条件)。language-invariant なので、`--lang` が何であっても判定は同じです。
+- `content-validator` — 10 種類のコンテンツチェック。パス参照の存在確認 (`STALE_PATH` が捏造の `src/...` 参照を捕捉) や MANIFEST drift の検知も含まれます。
+- `pass-json-validator` — Pass 1/2/3/4 の JSON well-formedness と stack-aware なセクション数チェック。
+- `plan-validator` — plan ↔ disk の整合性 (legacy。v2.1.0 以降はほぼ no-op)。
+- `sync-checker` — 追跡対象 7 ディレクトリにおける disk ↔ `sync-map.json` の登録整合性。
 
-3-tier severity (`fail` / `warn` / `advisory`) なので、ユーザが手動で直せる LLM hallucination について warning が CI を deadlock させることはありません。
+severity は 3 段階 (`fail` / `warn` / `advisory`) に分かれており、ユーザが手で直せる程度の LLM hallucination で warning が CI を止めてしまうことはありません。
 
-すべてを結びつける invariant: **Claude はコードに実在するパスしか引用できない** — Step A が finite な allowlist を渡しているからです。それでも LLM が何かをでっち上げようとしたら (まれですが特定の seed で起きます)、Step C が docs を ship する前に捕まえます。
+これらすべてを束ねる根本原則は、**Claude が引用できるのはコードに実在するパスだけ**ということです。Step A が有限の allowlist を渡すので、そもそも逸脱できない設計になっています。それでも LLM が何かを作り出そうとすることはありますが (特定の seed でごくたまに発生)、Step C が出力前にしっかり捕捉します。
 
-per-pass の詳細、marker ベースの resume、Claude Code の `.claude/` sensitive-path block を回避する staged-rules の仕組み、stack 検出の internals は [docs/architecture.md](docs/ja/architecture.md) を参照。
+各 pass の詳細、marker ベースの再開、Claude Code の `.claude/` 機密パス制限を回避する staged-rules の挙動、スタック検出の内部ロジックは [docs/ja/architecture.md](docs/ja/architecture.md) を参照してください。
 
 ---
 
 ## Supported Stacks
 
-12 種のスタック、プロジェクトファイルから自動検出:
+12 スタックを、プロジェクトのファイルから自動で検出します。
 
 **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
 
-マルチスタックのプロジェクト (例: Spring Boot バックエンド + Next.js フロントエンド) もそのまま動作します。
+マルチスタックのプロジェクト (例: Spring Boot バックエンド + Next.js フロントエンド) もそのまま動きます。
 
-検出ルールと各 scanner が抽出する内容は [docs/ja/stacks.md](docs/ja/stacks.md) を参照。
+検出ルールと各スキャナが取り出す情報については [docs/ja/stacks.md](docs/ja/stacks.md) を参照してください。
 
 ---
 
 ## 日常のワークフロー
 
-3 つのコマンドで使用量の約 95% をカバーします:
+普段の使い方は、ほぼこの 3 つのコマンドで済みます。
 
 ```bash
-# プロジェクトでの初回実行
+# プロジェクトで初めて実行するとき
 npx claudeos-core init
 
-# standards や rules を手動編集した後
+# standards やルールを手で編集した後
 npx claudeos-core lint
 
-# ヘルスチェック (コミット前または CI で実行)
+# ヘルスチェック (コミット前や CI で実行)
 npx claudeos-core health
 ```
 
-memory layer のメンテナンス用にもう 2 つ:
-
-```bash
-# failure-patterns ログのコンパクション (定期的に実行)
-npx claudeos-core memory compact
-
-# 頻発する failure pattern を提案ルールへ昇格
-npx claudeos-core memory propose-rules
-```
-
-各コマンドの全オプションは [docs/ja/commands.md](docs/ja/commands.md) を参照。
+各コマンドのオプション全体は [docs/ja/commands.md](docs/ja/commands.md) を参照してください。メモリレイヤーのコマンド (`memory compact`、`memory propose-rules`) は下の [Memory Layer](#memory-layer-任意長期プロジェクト向け) セクションで扱います。
 
 ---
 
 ## 何が違うのか
 
-ほとんどの Claude Code ドキュメント生成ツールは「説明」から始まります (人がツールに伝え、ツールが Claude に伝える)。ClaudeOS-Core は「実際のソースコード」から始まります (ツールが読み、確定した事実を Claude に伝え、Claude は確定した内容だけを書く)。
+Claude Code 向けのドキュメント生成ツールはほとんど、ユーザの説明から出発します。ユーザがツールに伝え、ツールがそれを Claude に伝える流れです。ClaudeOS-Core は実際のソースコードから出発します。ツールが直接コードを読み、確定した事実を Claude に渡し、Claude はその事実だけでドキュメントを書きます。
 
-具体的な 3 つの帰結:
+具体的な違いは 3 つあります。
 
-1. **Deterministic stack detection.** 同じプロジェクト + 同じコード = 同じ出力。「今回は Claude のサイコロが違った」現象がない。
-2. **No invented paths.** Pass 3 のプロンプトは許可されたソースパスをすべて明示的に列挙 — Claude は存在しないパスを引用できない。
-3. **Multi-stack aware.** バックエンドとフロントエンドのドメインが同一実行内でそれぞれ異なる解析プロンプトを使用。
+1. **決定論的なスタック検出。** 同じプロジェクト + 同じコード = 同じ出力。「今回の Claude はちょっと違う出力を出してきた」がありません。
+2. **存在しないパスを作らない。** Pass 3 の prompt に許可済みのソースパスがすべて明示されているため、Claude はそこに無いパスを引用できません。
+3. **マルチスタックを意識した解析。** 同じ実行の中で、バックエンドとフロントエンドのドメインがそれぞれ別の解析 prompt を使います。
 
-他ツールとの scope 比較は [docs/ja/comparison.md](docs/ja/comparison.md) を参照。比較は **各ツールが何をするか** に関するもので、**どれが優れているか** ではありません — ほとんどは相補的です。
+他のツールとのスコープ比較は [docs/ja/comparison.md](docs/ja/comparison.md) を参照してください。この比較は **各ツールが何をするか** を整理した内容で、**どれが優れているか** を評価したものではありません。多くは互いに補完関係にあります。
 
 ---
 
-## 検証 (post-generation)
+## 検証 (生成後)
 
-Claude が docs を書いた後、コードがそれを検証します。5 つの独立した validator:
+Claude がドキュメントを書き終えたら、今度はコードがそれを検証します。独立した validator は 5 つあります。
 
-| Validator | 検査内容 | 実行元 |
+| Validator | チェック内容 | 実行元 |
 |---|---|---|
-| `claude-md-validator` | CLAUDE.md の構造的不変条件 (8 sections、language-invariant) | `claudeos-core lint` |
-| `content-validator` | パスクレームが実在するか、manifest の整合性 | `health` (advisory) |
+| `claude-md-validator` | CLAUDE.md の構造的な不変条件 (8 sections、language-invariant) | `claudeos-core lint` |
+| `content-validator` | パス参照が実際に存在するか、manifest が整合しているか | `health` (advisory) |
 | `pass-json-validator` | Pass 1 / 2 / 3 / 4 の出力が well-formed JSON か | `health` (warn) |
-| `plan-validator` | 保存された plan がディスクと一致するか | `health` (fail-on-error) |
-| `sync-checker` | ディスク上のファイルが `sync-map.json` の登録と一致するか (orphaned/unregistered の検出) | `health` (fail-on-error) |
+| `plan-validator` | 保存された plan がディスクの内容と一致するか | `health` (fail-on-error) |
+| `sync-checker` | `sync-map.json` の登録項目とディスク上のファイルが一致するか (orphaned/unregistered の検出) | `health` (fail-on-error) |
 
-`health-checker` が 4 つのランタイム validator を 3 段階の severity (fail / warn / advisory) でオーケストレーションし、CI に適した exit code で終了します。`claude-md-validator` は構造的な drift が soft warning ではなく re-init のシグナルなので、`lint` コマンドで個別に実行されます。いつでも実行可能:
+`health-checker` がランタイム validator 4 つを 3 段階の severity (fail / warn / advisory) でまとめて実行し、CI に適した終了コードで締めくくります。`claude-md-validator` だけは `lint` コマンドで個別に走らせる構成にしてあります。構造のズレは「軽い警告」ではなく「再 init すべきシグナル」だからです。いつでも実行できます。
 
 ```bash
 npx claudeos-core health
 ```
 
-各 validator の検査項目は [docs/ja/verification.md](docs/ja/verification.md) を参照。
+各 validator のチェック項目の詳細は [docs/ja/verification.md](docs/ja/verification.md) を参照してください。
 
 ---
 
 ## Memory Layer (任意、長期プロジェクト向け)
 
-v2.0 以降、ClaudeOS-Core は 4 つのファイルが入った `claudeos-core/memory/` フォルダを書き込みます:
+上の scaffolding パイプラインに加えて、単一セッションを超えて context を引き継ぎたいプロジェクト向けに、`claudeos-core/memory/` フォルダも併せて用意します。任意機能なので、`CLAUDE.md` とルールだけで足りる場合は無視してかまいません。
 
-- `decision-log.md` — append-only な「なぜ Y ではなく X を選んだのか」
-- `failure-patterns.md` — frequency/importance スコア付きの繰り返し発生するエラー
-- `compaction.md` — 時間とともに memory がどのように自動コンパクションされるか
-- `auto-rule-update.md` — 新ルールに昇格すべきパターン
+ファイルは 4 つで、すべて Pass 4 が書き出します。
 
-`npx claudeos-core memory propose-rules` を実行すると、Claude に最近の failure pattern を見せて新しいルールを提案させることができます。
+- `decision-log.md` — append-only 形式の「なぜ X ではなく Y を選んだか」の記録。`pass2-merged.json` からシード。
+- `failure-patterns.md` — frequency / importance のスコアが付いた、繰り返し起きるエラーの一覧。
+- `compaction.md` — 時間の経過とともにメモリが自動圧縮される仕組み。
+- `auto-rule-update.md` — 新しいルールに昇格させるべきパターン。
 
-memory モデルとライフサイクルは [docs/ja/memory-layer.md](docs/ja/memory-layer.md) を参照。
+このレイヤーを長く運用するためのコマンドが 2 つあります。
+
+```bash
+# failure-patterns ログを圧縮 (定期的に実行)
+npx claudeos-core memory compact
+
+# よく出る failure pattern を提案ルールに昇格
+npx claudeos-core memory propose-rules
+```
+
+メモリモデルとライフサイクルについては [docs/ja/memory-layer.md](docs/ja/memory-layer.md) を参照してください。
 
 ---
 
 ## FAQ
 
-**Q: Claude API キーが必要ですか?**
-A: 不要です。ClaudeOS-Core は既存の Claude Code インストールを利用します — マシン上の `claude -p` にプロンプトを流すだけです。追加のアカウントは不要です。
+**Q: Claude API キーは必要ですか?**
+A: 不要です。ClaudeOS-Core は手元にインストール済みの Claude Code をそのまま利用します。ローカルの `claude -p` に prompt を流す方式なので、追加のアカウントは要りません。
 
 **Q: 既存の CLAUDE.md や `.claude/rules/` を上書きしますか?**
-A: 新しいプロジェクトでの初回実行: 新規作成します。`--force` なしの再実行: 編集内容を保持 — 前回実行の pass marker が検出されると該当 pass はスキップされます。`--force` での再実行: すべてを wipe して再生成 (編集内容は失われます — それが `--force` の意味です)。詳しくは [docs/ja/safety.md](docs/ja/safety.md) を参照。
+A: 新規プロジェクトで初めて実行したときは新しく作ります。`--force` を付けずに再実行した場合は編集内容が残ります。前回実行の pass marker を検知して、その pass をスキップする仕組みです。`--force` を付けて再実行すると全部消して作り直します (編集内容も一緒に消える、というのが `--force` の意味です)。詳しくは [docs/ja/safety.md](docs/ja/safety.md) を参照してください。
 
-**Q: 自分のスタックがサポート対象外です。追加できますか?**
-A: できます。新しいスタックには ~3 個のプロンプトテンプレートとドメイン scanner が必要です。8 ステップガイドは [CONTRIBUTING.md](CONTRIBUTING.md) を参照。
+**Q: 自分のスタックがサポートされていません。追加できますか?**
+A: できます。新しいスタックには prompt テンプレート 3 種類とドメインスキャナ 1 つがあれば足ります。8 ステップのガイドは [CONTRIBUTING.md](CONTRIBUTING.md) にあります。
 
-**Q: 日本語 (または別言語) で docs を生成するには?**
-A: `npx claudeos-core init --lang ja`. 10 言語をサポート: en, ko, ja, zh-CN, es, vi, hi, ru, fr, de.
+**Q: 日本語 (またはその他の言語) でドキュメントを生成するには?**
+A: `npx claudeos-core init --lang ja` を実行してください。対応言語は 10 種類です: en, ko, ja, zh-CN, es, vi, hi, ru, fr, de。
 
-**Q: monorepo でも動作しますか?**
-A: 動作します — Turborepo (`turbo.json`)、pnpm workspaces (`pnpm-workspace.yaml`)、Lerna (`lerna.json`)、npm/yarn workspaces (`package.json#workspaces`) は stack-detector が検出します。各 app が独自の解析を受けます。それ以外の monorepo レイアウト (例: NX) は明示的には検出されませんが、汎用的な `apps/*/` と `packages/*/` のパターンはスタック別 scanner が拾います。
+**Q: モノレポでも動きますか?**
+A: 動きます。Turborepo (`turbo.json`)、pnpm workspaces (`pnpm-workspace.yaml`)、Lerna (`lerna.json`)、npm/yarn workspaces (`package.json#workspaces`) は stack-detector が検出します。app ごとに個別に解析します。それ以外のモノレポレイアウト (例: NX) は明示的に検出はしませんが、一般的な `apps/*/` や `packages/*/` のパターンならスタック別スキャナがそのまま拾います。
 
-**Q: Claude Code が同意できないルールを生成したら?**
-A: 直接編集してください。その後 `npx claudeos-core lint` を実行して CLAUDE.md が構造的に有効なままか確認します。以後の `init` 実行 (`--force` なし) では編集内容が保持されます — resume メカニズムが marker のある pass をスキップするためです。
+**Q: Claude Code が同意しがたいルールを作ってきたら?**
+A: 直接編集してください。そのあと `npx claudeos-core lint` を走らせて、CLAUDE.md の構造がまだ有効かを確認します。`--force` を付けずに以降の `init` を実行する限り、編集内容はそのまま残ります。再開ロジックが marker のある pass を飛ばすからです。
 
 **Q: バグはどこに報告すれば?**
-A: [GitHub Issues](https://github.com/claudeos-core/claudeos-core/issues). セキュリティ問題は [SECURITY.md](SECURITY.md) を参照。
+A: [GitHub Issues](https://github.com/claudeos-core/claudeos-core/issues) へ。セキュリティ関連は [SECURITY.md](SECURITY.md) を参照してください。
+
+---
+
+## 時間が節約できたなら
+
+GitHub の ⭐ 1 つで、プロジェクトの可視性が上がり、他の人にも見つけてもらいやすくなります。issue、PR、スタックテンプレートの貢献はすべて歓迎します。詳細は [CONTRIBUTING.md](CONTRIBUTING.md) を参照してください。
 
 ---
 
-## Documentation
+## ドキュメント
 
-| トピック | 読むもの |
+| トピック | 読むファイル |
 |---|---|
-| 4-pass パイプラインの仕組み (図解より深く) | [docs/ja/architecture.md](docs/ja/architecture.md) |
-| アーキテクチャの視覚的ダイアグラム (Mermaid) | [docs/ja/diagrams.md](docs/ja/diagrams.md) |
-| Stack 検出 — 各 scanner が見るもの | [docs/ja/stacks.md](docs/ja/stacks.md) |
-| Memory layer — decision log と failure pattern | [docs/ja/memory-layer.md](docs/ja/memory-layer.md) |
+| 4-pass パイプラインの動き (図より深い説明) | [docs/ja/architecture.md](docs/ja/architecture.md) |
+| アーキテクチャの図解 (Mermaid) | [docs/ja/diagrams.md](docs/ja/diagrams.md) |
+| スタック検出 — 各スキャナが何を見ているか | [docs/ja/stacks.md](docs/ja/stacks.md) |
+| メモリレイヤー — decision log と failure pattern | [docs/ja/memory-layer.md](docs/ja/memory-layer.md) |
 | 5 つの validator の詳細 | [docs/ja/verification.md](docs/ja/verification.md) |
 | すべての CLI コマンドとオプション | [docs/ja/commands.md](docs/ja/commands.md) |
-| 手動インストール (`npx` なし) | [docs/ja/manual-installation.md](docs/ja/manual-installation.md) |
-| Scanner override — `.claudeos-scan.json` | [docs/ja/advanced-config.md](docs/ja/advanced-config.md) |
-| 安全性: re-init で保持されるもの | [docs/ja/safety.md](docs/ja/safety.md) |
-| 類似ツールとの比較 (scope であり品質ではない) | [docs/ja/comparison.md](docs/ja/comparison.md) |
+| 手動インストール (`npx` を使わない方法) | [docs/ja/manual-installation.md](docs/ja/manual-installation.md) |
+| スキャナの override — `.claudeos-scan.json` | [docs/ja/advanced-config.md](docs/ja/advanced-config.md) |
+| 安全性: 再実行時に保持されるもの | [docs/ja/safety.md](docs/ja/safety.md) |
+| 似たツールとの比較 (品質ではなくスコープの観点) | [docs/ja/comparison.md](docs/ja/comparison.md) |
 | エラーと復旧 | [docs/ja/troubleshooting.md](docs/ja/troubleshooting.md) |
 
 ---
 
-## Contributing
+## 貢献
 
-コントリビューション歓迎です — スタック対応の追加、プロンプトの改善、バグ修正など。詳しくは [CONTRIBUTING.md](CONTRIBUTING.md) を参照。
+貢献は歓迎します。スタック対応の追加、prompt の改善、バグ修正、どれも大歓迎です。詳細は [CONTRIBUTING.md](CONTRIBUTING.md) を参照してください。
 
-行動規範とセキュリティポリシーは [CODE_OF_CONDUCT.md](CODE_OF_CONDUCT.md) と [SECURITY.md](SECURITY.md) を参照。
+行動規範とセキュリティポリシーは [CODE_OF_CONDUCT.md](CODE_OF_CONDUCT.md)、[SECURITY.md](SECURITY.md) を参照してください。
 
-## License
+## ライセンス
 
-[ISC](LICENSE) — 商用を含めあらゆる用途で自由に利用可能。
+[ISC License](LICENSE)。商用利用を含めて、あらゆる用途に自由に利用できます。© 2025–2026 ClaudeOS-Core contributors.
 
 ---
 
-<sub>[@claudeos-core](https://github.com/claudeos-core) が手をかけて作成しました。時間を節約できたなら、GitHub の ⭐ がプロジェクトの可視性を保ちます。</sub>
+<sub>[claudeos-core](https://github.com/claudeos-core) チームがメンテナンスしています。issue や PR は <https://github.com/claudeos-core/claudeos-core> までお寄せください。</sub>