claudeos-core 1.7.0 → 2.0.0

package/README.ja.md

@@ -1,12 +1,12 @@
 # ClaudeOS-Core
 
-**ソースコードを先に読み、スタックとパターンを決定論的分析で確定してから、プロジェクトに正確に合った Claude Code ルールを生成する唯一のツール。**
+**ソースコードを先に読み、決定論的分析でスタックとパターンを確定してから、プロジェクトに正確に合った Claude Code ルールを生成する唯一のツール。**
 
 ```bash
 npx claudeos-core init
 ```
 
-ClaudeOS-Core はコードベースを読み取り、すべてのパターンを抽出し、_あなたの_ プロジェクトに最適化された Standards、Rules、Skills、Guides の完全なセットを生成します。その後、Claude Code に「注文の CRUD を作成して」と伝えると、既存のパターンに完全に一致するコードが生成されます。
+ClaudeOS-Core はコードベースを読み取り、見つけたすべてのパターンを抽出して、_あなたの_ プロジェクトに合わせた Standards、Rules、Skills、Guides の完全なセットを生成します。その後、Claude Code に「注文の CRUD を作成して」と伝えると、既存のパターンに完全に一致するコードが生成されます。
 
 [🇺🇸 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)
 
@@ -22,41 +22,41 @@ ClaudeOS-Core はこう動作します：
 
 > **コードがソースを分析 → コードがカスタムプロンプトを構築 → LLM がドキュメントを生成 → コードが出力を検証**
 
-これは小さな違いではありません。
+これは小さな違いではありません。なぜ重要なのか説明します：
 
-### 核心的な問題：LLM は推測する。コードは確定する。
+### 核心的な問題：LLM は推測する。コードは推測しない。
 
 Claude に「このプロジェクトを分析して」と頼むと、スタック、ORM、ドメイン構造を**推測**します。
-`build.gradle` で `spring-boot` を見ても、MyBatis ではなく JPA と誤認する可能性があります。
-`user/` ディレクトリを見ても、layer-first（Pattern A）か domain-first（Pattern B）か間違える可能性があります。
+`build.gradle` で `spring-boot` を見ても、MyBatis を使っていること（JPA ではない）を見逃すかもしれません。
+`user/` ディレクトリを検出しても、プロジェクトが layer-first パッケージング（Pattern A）を使っていて domain-first（Pattern B）ではないことに気付かないかもしれません。
 
-**ClaudeOS-Core は推測しません。** Claude がプロジェクトを見る前に、Node.js コードがすでに：
+**ClaudeOS-Core は推測しません。** Claude がプロジェクトを見る前に、Node.js コードがすでに以下を実行済みです：
 
-- `build.gradle` / `package.json` / `pyproject.toml` をパースしてスタック、ORM、DB、パッケージマネージャーを**確定**
-- ディレクトリ構造をスキャンしてドメインリストとファイル数を**確定**
-- プロジェクト構造を Java 5パターン、Kotlin CQRS/BFF、Next.js App Router/FSD のいずれかに**分類**
-- Claude のコンテキストウィンドウに収まるようドメインを最適グループに**分割**
-- 確定した事実が注入されたスタック固有のプロンプトを**構築**
+- `build.gradle` / `package.json` / `pyproject.toml` をパースしてスタック、ORM、DB、パッケージマネージャを**確定**
+- ディレクトリ構造をスキャンしてファイル数付きのドメインリストを**確定**
+- プロジェクト構造を Java 5 パターン、Kotlin CQRS/BFF、Next.js App Router/FSD のいずれかに**分類**
+- Claude のコンテキストウィンドウに収まる最適サイズのグループにドメインを**分割**
+- 確定された事実がすべて注入されたスタック固有のプロンプトを**組み立て**
 
-Claude がプロンプトを受け取る時点で、推測の余地はありません。スタック確定。ドメイン確定。構造パターン確定。Claude は**確定された事実**に沿ったドキュメントを生成するだけです。
+Claude がプロンプトを受け取る時点で、推測の余地はありません。スタック確定。ドメイン確定。構造パターン確定。Claude の仕事は、これらの**確定された事実**に合ったドキュメントを生成することだけです。
 
 ### 結果
 
 他のツールは「一般的に良い」ドキュメントを生成します。
-ClaudeOS-Core は、プロジェクトが `ApiResponse.ok()` を使用していること、MyBatis XML マッパーが `src/main/resources/mybatis/mappers/` にあること、パッケージ構造が `com.company.module.{domain}.controller` であることを知っているドキュメントを生成します — 実際のコードを読んだからです。
+ClaudeOS-Core は、プロジェクトが `ApiResponse.ok()`（`ResponseEntity.success()` ではない）を使っていること、MyBatis XML マッパーが `src/main/resources/mybatis/mappers/` にあること、パッケージ構造が `com.company.module.{domain}.controller` であることを知っているドキュメントを生成します — 実際のコードを読んだからです。
 
 ### Before & After
 
 **ClaudeOS-Core なし** — Claude Code に注文 CRUD の作成を依頼すると：
 ```
 ❌ JPA スタイルの repository を使用（プロジェクトは MyBatis）
-❌ ResponseEntity.success() を生成（ラッパーは ApiResponse.ok()）
-❌ order/controller/ にファイルを配置（プロジェクトは controller/order/）
-❌ 英語コメントを生成（チームは日本語を使用）
-→ 生成ファイルごとに20分の修正
+❌ ResponseEntity.success() を生成（あなたのラッパーは ApiResponse.ok()）
+❌ order/controller/ にファイルを配置（プロジェクトは controller/order/ 構造）
+❌ 英語コメントを生成（チームは日本語コメント）
+→ 生成ファイルごとに 20 分の修正
 ```
 
-**ClaudeOS-Core 適用後** — `.claude/rules/` に確定されたパターンが存在：
+**ClaudeOS-Core あり** — `.claude/rules/` に確定されたパターンがすでに存在：
 ```
 ✅ MyBatis マッパー + XML を生成（build.gradle から検出）
 ✅ ApiResponse.ok() を使用（実際のソースから抽出）
@@ -65,7 +65,7 @@ ClaudeOS-Core は、プロジェクトが `ApiResponse.ok()` を使用してい
 → 生成コードがプロジェクト規約と即座に一致
 ```
 
-この差は蓄積されます。1日10タスク × 20分節約 = **1日3時間以上**。
+この差は積み重なります。1 日 10 タスク × 20 分節約 = **1 日 3 時間以上**。
 
 ---
 
@@ -73,8 +73,8 @@ ClaudeOS-Core は、プロジェクトが `ApiResponse.ok()` を使用してい
 
 | スタック | 検出方法 | 分析深度 |
 |---|---|---|
-| **Java / Spring Boot** | `build.gradle`、`pom.xml`、5パッケージパターン | 10 大分類、59 小項目 |
-| **Kotlin / Spring Boot** | `build.gradle.kts`, kotlin plugin, `settings.gradle.kts`, CQRS/BFF auto-detect | 12 大分類, 95 小項目 |
+| **Java / Spring Boot** | `build.gradle`、`pom.xml`、5 パッケージパターン | 10 大分類、59 小項目 |
+| **Kotlin / Spring Boot** | `build.gradle.kts`、kotlin plugin、`settings.gradle.kts`、CQRS/BFF 自動検出 | 12 大分類、95 小項目 |
 | **Node.js / Express** | `package.json` | 9 大分類、57 小項目 |
 | **Node.js / NestJS** | `package.json` (`@nestjs/core`) | 10 大分類、68 小項目 |
 | **Next.js / React** | `package.json`、`next.config.*`、FSD サポート | 9 大分類、55 小項目 |
@@ -85,12 +85,11 @@ ClaudeOS-Core は、プロジェクトが `ApiResponse.ok()` を使用してい
 | **Vite / React SPA** | `package.json`、`vite.config.*` | 9 大分類、55 小項目 |
 | **Angular** | `package.json`、`angular.json` | 12 大分類、78 小項目 |
 
-自動検出対象：言語とバージョン、フレームワークとバージョン（Vite を SPA フレームワークとして含む）、ORM（MyBatis、JPA、Exposed、Prisma、TypeORM、SQLAlchemy 等）、データベース（PostgreSQL、MySQL、Oracle、MongoDB、SQLite）、パッケージマネージャー（Gradle、Maven、npm、yarn、pnpm、pip、poetry）、アーキテクチャ（CQRS、BFF — モジュール名から検出）、マルチモジュール構造（settings.gradleから検出）、モノレポ（Turborepo、pnpm-workspace、Lerna、npm/yarn workspaces）。
+自動検出対象：言語とバージョン、フレームワークとバージョン（SPA フレームワークとしての Vite を含む）、ORM（MyBatis、JPA、Exposed、Prisma、TypeORM、SQLAlchemy など）、データベース（PostgreSQL、MySQL、Oracle、MongoDB、SQLite）、パッケージマネージャ（Gradle、Maven、npm、yarn、pnpm、pip、poetry）、アーキテクチャ（CQRS、BFF — モジュール名から）、マルチモジュール構造（settings.gradle から）、モノレポ（Turborepo、pnpm-workspace、Lerna、npm/yarn workspaces）。
 
-**何も指定する必要はありません。すべて自動検出されます。**
+**何も指定する必要はありません。すべて自動的に検出されます。**
 
-
-### Java ドメイン検出（5パターン、フォールバック付き）
+### Java ドメイン検出（5 パターン、フォールバック付き）
 
 | 優先度 | パターン | 構造 | 例 |
 |---|---|---|---|
@@ -100,8 +99,7 @@ ClaudeOS-Core は、プロジェクトが `ApiResponse.ok()` を使用してい
 | E | DDD/ヘキサゴナル | `{domain}/adapter/in/web/` | `user/adapter/in/web/UserController.java` |
 | C | フラット | `controller/*.java` | `controller/UserController.java` → クラス名から `user` を抽出 |
 
-Controller のないサービスのみのドメインも `service/`、`dao/`、`aggregator/`、`facade/`、`usecase/`、`orchestrator/`、`mapper/`、`repository/` ディレクトリを通じて検出されます。スキップ：`common`、`config`、`util`、`core`、`front`、`admin`、`v1`、`v2` など。
-
+Controller を持たない Service 専用ドメインも、`service/`、`dao/`、`aggregator/`、`facade/`、`usecase/`、`orchestrator/`、`mapper/`、`repository/` ディレクトリを通じて検出されます。スキップ：`common`、`config`、`util`、`core`、`front`、`admin`、`v1`、`v2` など。
 
 ### Kotlin マルチモジュールドメイン検出
 
@@ -109,23 +107,49 @@ Gradle マルチモジュール構造の Kotlin プロジェクト（例：CQRS
 
 | ステップ | 動作 | 例 |
 |---|---|---|
-| 1 | `settings.gradle.kts` から `include()` をスキャン | 14 モジュール検出 |
+| 1 | `settings.gradle.kts` から `include()` をスキャン | 14 モジュールを検出 |
 | 2 | モジュール名からタイプを検出 | `reservation-command-server` → type: `command` |
 | 3 | モジュール名からドメインを抽出 | `reservation-command-server` → domain: `reservation` |
-| 4 | 同じドメインをモジュール間でグループ化 | `reservation-command-server` + `common-query-server` → 1ドメイン |
-| 5 | アーキテクチャを検出 | `command` + `query` モジュールあり → CQRS |
+| 4 | モジュール間で同じドメインをグループ化 | `reservation-command-server` + `common-query-server` → 1 ドメイン |
+| 5 | アーキテクチャ検出 | `command` + `query` モジュール存在 → CQRS |
 
-サポートモジュールタイプ：`command`、`query`、`bff`、`integration`、`standalone`、`library`。共有ライブラリ（`shared-lib`、`integration-lib`）は特殊ドメインとして検出されます。
+対応モジュールタイプ：`command`、`query`、`bff`、`integration`、`standalone`、`library`。共有ライブラリ（`shared-lib`、`integration-lib`）は特殊ドメインとして検出されます。
 
 ### フロントエンドドメイン検出
 
 - **App Router**：`app/{domain}/page.tsx`（Next.js）
 - **Pages Router**：`pages/{domain}/index.tsx`
-- **FSD（Feature-Sliced Design）**：`features/*/`、`widgets/*/`、`entities/*/`
-- **RSC/Client分離**：`client.tsx` パターンを検出、サーバー/クライアントコンポーネントの分離を追跡
-- **非標準ネストパス**：`src/*/pages/`、`src/*/components/`、`src/*/features/` 配下のページ、コンポーネント、FSD レイヤーを検出（例：`src/admin/pages/dashboard/`）
-- **設定ファイルフォールバック**：`package.json` になくても設定ファイルから Next.js/Vite/Nuxt を検出（monorepo対応）
-- **深層ディレクトリフォールバック**：React/CRA/Vite/Vue/RNプロジェクトで `**/components/*/`、`**/views/*/`、`**/screens/*/`、`**/containers/*/`、`**/pages/*/`、`**/routes/*/`、`**/modules/*/`、`**/domains/*/` を任意の深さでスキャン
+- **FSD (Feature-Sliced Design)**：`features/*/`、`widgets/*/`、`entities/*/`
+- **RSC/Client 分離**：`client.tsx` パターンを検出、Server/Client コンポーネント分離を追跡
+- **非標準ネストパス**：`src/*/` 配下のページ、コンポーネント、FSD レイヤーを検出（例：`src/admin/pages/dashboard/`、`src/admin/components/form/`、`src/admin/features/billing/`）
+- **プラットフォーム/ティア分割検出 (v2.0.0)**：`src/{platform}/{subapp}/` レイアウトを認識 — `{platform}` はデバイス/ターゲットキーワード（`desktop`、`pc`、`web`、`mobile`、`mc`、`mo`、`sp`、`tablet`、`tab`、`pwa`、`tv`、`ctv`、`ott`、`watch`、`wear`）またはアクセスティアキーワード（`admin`、`cms`、`backoffice`、`back-office`、`portal`）を指定できます。`(platform, subapp)` ペアごとに `{platform}-{subapp}` という名前のドメインを 1 つ生成し、ドメインごとの routes/components/layouts/hooks のカウントを提供します。Angular、Next.js、React、Vue で同時に動作（マルチ拡張子 glob `{tsx,jsx,ts,js,vue}`）。subapp あたり 2 ファイル以上必要（1 ファイルのノイジーなドメインを回避）。
+- **モノレポプラットフォーム分割 (v2.0.0)**：プラットフォームスキャンは `{apps,packages}/*/src/{platform}/{subapp}/`（`src/` を持つ Turborepo/pnpm workspace）および `{apps,packages}/{platform}/{subapp}/`（`src/` ラッパーなしの workspaces）にもマッチします。
+- **Fallback E — routes ファイル (v2.0.0)**：主要スキャナ + Fallback A–D がすべて 0 を返した場合、`**/routes/*.{tsx,jsx,ts,js,vue}` を glob し、`routes` の親ディレクトリ名でグループ化。Next.js の `page.tsx` や FSD レイアウトにマッチしない React Router ファイルルーティングプロジェクト（CRA/Vite + `react-router`）を捕捉します。汎用的な親名（`src`、`app`、`pages`）はフィルタアウトされます。
+- **Config フォールバック**：`package.json` になくても、設定ファイルから Next.js/Vite/Nuxt を検出（モノレポ対応）
+- **Deep ディレクトリフォールバック**：React/CRA/Vite/Vue/RN プロジェクトで、`**/components/*/`、`**/views/*/`、`**/screens/*/`、`**/containers/*/`、`**/pages/*/`、`**/routes/*/`、`**/modules/*/`、`**/domains/*/` をどの深さでもスキャン
+- **共有無視リスト (v2.0.0)**：すべてのスキャナが `BUILD_IGNORE_DIRS`（`node_modules`、`build`、`dist`、`out`、`.next`、`.nuxt`、`.svelte-kit`、`.angular`、`.turbo`、`.cache`、`.parcel-cache`、`coverage`、`storybook-static`、`.vercel`、`.netlify`）と `TEST_FILE_IGNORE`（spec/test/stories/e2e/cy + `__snapshots__`/`__tests__`）を共有し、ビルド成果物とテストフィクスチャがドメインごとのファイル数を膨張させないようにします。
+
+### スキャナオーバーライド (v2.0.0)
+
+プロジェクトルートにオプションの `.claudeos-scan.json` を配置すると、ツールキットを編集せずにスキャナのデフォルトを拡張できます。すべてのフィールドは**加算的** — ユーザーエントリはデフォルトを置き換えず、拡張します：
+
+```json
+{
+  "frontendScan": {
+    "platformKeywords": ["kiosk"],
+    "skipSubappNames": ["legacy"],
+    "minSubappFiles": 3
+  }
+}
+```
+
+| フィールド | デフォルト | 用途 |
+|---|---|---|
+| `platformKeywords` | 上記の組み込みリスト | プラットフォームスキャン用の追加 `{platform}` キーワード（例：`kiosk`、`vr`、`embedded`） |
+| `skipSubappNames` | 構造的ディレクトリのみ | プラットフォームスキャンのドメイン生成から除外する追加 subapp 名 |
+| `minSubappFiles` | `2` | subapp がドメインになるために必要な最小ファイル数の上書き |
+
+ファイル欠損または JSON 不正 → 静かにデフォルトにフォールバック（クラッシュなし）。典型的な用途：組み込みリストが曖昧すぎるとして除外する短縮形（`adm`、`bo`）を opt-in する、またはノイジーなモノレポで `minSubappFiles` を引き上げる。
 
 ---
 
@@ -134,37 +158,37 @@ Gradle マルチモジュール構造の Kotlin プロジェクト（例：CQRS
 ### 前提条件
 
 - **Node.js** v18+
-- **Claude Code CLI**（インストール・認証済み）
+- **Claude Code CLI**（インストール & 認証済み）
 
 ### インストール
 
 ```bash
 cd /your/project/root
 
-# 方法 A：npx（推奨 — インストール不要）
+# オプション A：npx（推奨 — インストール不要）
 npx claudeos-core init
 
-# 方法 B：グローバルインストール
+# オプション B：グローバルインストール
 npm install -g claudeos-core
 claudeos-core init
 
-# 方法 C：プロジェクト devDependency
+# オプション C：プロジェクト devDependency
 npm install --save-dev claudeos-core
 npx claudeos-core init
 
-# 方法 D：git clone（開発・コントリビューション用）
+# オプション D：git clone（開発/貢献用）
 git clone https://github.com/claudeos-core/claudeos-core.git claudeos-core-tools
 
-# クロスプラットフォーム（PowerShell、CMD、Bash、Zsh — すべてのターミナル）
+# クロスプラットフォーム（PowerShell、CMD、Bash、Zsh — どのターミナルでも）
 node claudeos-core-tools/bin/cli.js init
 
-# Linux/macOS のみ（Bash のみ）
+# Linux/macOS（Bash のみ）
 bash claudeos-core-tools/bootstrap.sh
 ```
 
 ### 出力言語（10 言語対応）
 
-`--lang` なしで `init` を実行すると、矢印キーまたは数字キーで言語を選択するインタラクティブ画面が表示されます：
+`--lang` なしで `init` を実行すると、インタラクティブセレクタが表示されます — 矢印キーまたは数字キーで選択：
 
 ```
 ╔══════════════════════════════════════════════════╗
@@ -172,32 +196,37 @@ bash claudeos-core-tools/bootstrap.sh
 ╚══════════════════════════════════════════════════╝
 
   生成されるファイル（CLAUDE.md、Standards、Rules、
-  Skills、Guides）は日本語で作成されます。
+  Skills、Guides）は日本語で記述されます。
 
      1. en     — English
      2. ko     — 한국어 (Korean)
      3. zh-CN  — 简体中文 (Chinese Simplified)
   ❯  4. ja     — 日本語 (Japanese)
-     ...
+     5. es     — Español (Spanish)
+     6. vi     — Tiếng Việt (Vietnamese)
+     7. hi     — हिन्दी (Hindi)
+     8. ru     — Русский (Russian)
+     9. fr     — Français (French)
+    10. de     — Deutsch (German)
 
   ↑↓ Move  1-0 Jump  Enter Select  ESC Cancel
 ```
 
-選択を移動すると、説明が該当言語に切り替わります。セレクターをスキップするには `--lang` を直接指定してください：
+カーソル移動に応じて、説明が選択した言語に切り替わります。セレクタをスキップするには `--lang` を直接指定：
 
 ```bash
-npx claudeos-core init --lang ja    # 日本語
-npx claudeos-core init --lang en    # English
 npx claudeos-core init --lang ko    # 한국어
+npx claudeos-core init --lang ja    # 日本語
+npx claudeos-core init --lang en    # English（デフォルト）
 ```
 
-> **注意：** この設定は生成されるドキュメントファイルの言語のみを変更します。コード分析（Pass 1–2）は常に英語で実行され、生成結果（Pass 3）のみ選択した言語で作成されます。コード例は元のプログラミング言語構文のまま維持されます。
+> **注意：** この設定は生成されるドキュメントファイルの言語のみを変更します。コード分析（Pass 1–2）は常に英語で実行され、生成結果（Pass 3）のみが選択した言語で記述されます。生成ファイル内のコード例は元のプログラミング言語構文のまま維持されます。
 
-これだけです。5–18 分後、すべてのドキュメントが生成され、すぐに使えます。CLI は各 Pass 実行時にパーセント、経過時間、推定残り時間を含むプログレスバーを表示します。
+以上です。5–20 分後（Pass 1×N + Pass 2 + Pass 3 + Pass 4 メモリスキャフォールディング）、すべてのドキュメントが生成され、すぐに使用できます。CLI は各 Pass のパーセンテージ、経過時間、ETA 付きのプログレスバーを表示します。
 
 ### 手動ステップバイステップインストール
 
-各フェーズを完全に制御したい場合、または自動パイプラインが途中で失敗した場合、各ステージを手動で実行できます。ClaudeOS-Core の内部動作を理解するのにも役立ちます。
+各フェーズを完全に制御したい場合や、自動化パイプラインが任意のステップで失敗した場合、各ステージを手動で実行できます。ClaudeOS-Core の内部動作を理解するのにも役立ちます。
 
 #### Step 1：クローンと依存関係のインストール
 
@@ -211,8 +240,8 @@ cd claudeos-core-tools && npm install && cd ..
 #### Step 2：ディレクトリ構造の作成
 
 ```bash
-# Rules
-mkdir -p .claude/rules/{00.core,10.backend,20.frontend,30.security-db,40.infra,50.sync}
+# Rules（v2.0.0：60.memory を追加）
+mkdir -p .claude/rules/{00.core,10.backend,20.frontend,30.security-db,40.infra,50.sync,60.memory}
 
 # Standards
 mkdir -p claudeos-core/standard/{00.core,10.backend-api,20.frontend-ui,30.security-db,40.infra,50.verification,90.optional}
@@ -220,140 +249,189 @@ mkdir -p claudeos-core/standard/{00.core,10.backend-api,20.frontend-ui,30.securi
 # Skills
 mkdir -p claudeos-core/skills/{00.shared,10.backend-crud/scaffold-crud-feature,20.frontend-page/scaffold-page-feature,50.testing,90.experimental}
 
-# Guide, Plan, Database, MCP, Generated
+# Guide、Plan、Database、MCP、Generated、Memory（v2.0.0：memory を追加）
 mkdir -p claudeos-core/guide/{01.onboarding,02.usage,03.troubleshooting,04.architecture}
-mkdir -p claudeos-core/{plan,database,mcp-guide,generated}
+mkdir -p claudeos-core/{plan,database,mcp-guide,generated,memory}
 ```
 
 #### Step 3：plan-installer の実行（プロジェクト分析）
 
-プロジェクトをスキャンし、スタックを検出、ドメインを発見、グループに分割、プロンプトを生成します。
+プロジェクトをスキャンし、スタックを検出し、ドメインを見つけ、グループに分割し、プロンプトを生成します。
 
 ```bash
 node claudeos-core-tools/plan-installer/index.js
 ```
 
-**出力（`claudeos-core/generated/`）：**
+**出力（`claudeos-core/generated/` 内）：**
 - `project-analysis.json` — 検出されたスタック、ドメイン、フロントエンド情報
 - `domain-groups.json` — Pass 1 用ドメイングループ
 - `pass1-backend-prompt.md` / `pass1-frontend-prompt.md` — 分析プロンプト
-- `pass2-prompt.md` — 統合プロンプト
-- `pass3-prompt.md` — 生成プロンプト
+- `pass2-prompt.md` — マージプロンプト
+- `pass3-prompt.md` — 生成プロンプト（`staging-override.md` ディレクティブでラップ — Step 6 の注意参照）
+- `pass4-prompt.md` — L4 メモリスキャフォールディングプロンプト（v2.0.0；`60.memory/` ルール書き込みにも同じ `staging-override.md` を使用）
 
-続行する前に、これらのファイルを確認して検出精度を検証できます。
+これらのファイルを検査して、進める前に検出精度を確認できます。
 
-#### Step 4：Pass 1 — ドメイングループごとの深層コード分析
+#### Step 4：Pass 1 — 深層コード分析（ドメイングループごと）
 
-各ドメイングループに対して Pass 1 を実行します。`domain-groups.json` でグループ数を確認してください。
+各ドメイングループに対して Pass 1 を実行します。グループ数は `domain-groups.json` で確認してください。
 
 ```bash
-# Check groups
+# グループ数を確認
 cat claudeos-core/generated/domain-groups.json | node -e "
   const g = JSON.parse(require('fs').readFileSync('/dev/stdin','utf-8'));
   g.groups.forEach((g,i) => console.log('Group '+(i+1)+': ['+g.domains.join(', ')+'] ('+g.type+', ~'+g.estimatedFiles+' files)'));
 "
 
-# Run Pass 1 for group 1:
-cp claudeos-core/generated/pass1-backend-prompt.md /tmp/_pass1.md
-DOMAIN_LIST="user, order, product" PASS_NUM=1 \
-  perl -pi -e 's/\{\{DOMAIN_GROUP\}\}/$ENV{DOMAIN_LIST}/g; s/\{\{PASS_NUM\}\}/$ENV{PASS_NUM}/g' /tmp/_pass1.md
-cat /tmp/_pass1.md | claude -p --dangerously-skip-permissions
+# 各グループに対して Pass 1 を実行（ドメインとグループ番号を置き換え）
+# 注：v1.6.1+ は perl の代わりに Node.js の String.replace() を使用 — perl は
+# 不要になり、replacement-function セマンティクスにより、ドメイン名に現れる可能性のある
+# $/&/$1 文字からの regex インジェクションを防止。
+#
+# Group 1：
+DOMAIN_LIST="user, order, product" PASS_NUM=1 node -e "
+  const fs = require('fs');
+  const tpl = fs.readFileSync('claudeos-core/generated/pass1-backend-prompt.md','utf-8');
+  const out = tpl
+    .replace(/\{\{DOMAIN_GROUP\}\}/g, () => process.env.DOMAIN_LIST)
+    .replace(/\{\{PASS_NUM\}\}/g, () => process.env.PASS_NUM);
+  process.stdout.write(out);
+" | claude -p --dangerously-skip-permissions
+
+# Group 2（存在する場合）：
+DOMAIN_LIST="payment, system, delivery" PASS_NUM=2 node -e "
+  const fs = require('fs');
+  const tpl = fs.readFileSync('claudeos-core/generated/pass1-backend-prompt.md','utf-8');
+  const out = tpl
+    .replace(/\{\{DOMAIN_GROUP\}\}/g, () => process.env.DOMAIN_LIST)
+    .replace(/\{\{PASS_NUM\}\}/g, () => process.env.PASS_NUM);
+  process.stdout.write(out);
+" | claude -p --dangerously-skip-permissions
+
+# フロントエンドグループの場合、pass1-backend-prompt.md → pass1-frontend-prompt.md に置き換え
+```
+
+**確認：** `ls claudeos-core/generated/pass1-*.json` でグループごとに 1 つの JSON が表示されるはずです。
+
+#### Step 5：Pass 2 — 分析結果のマージ
 
-# フロントエンドグループは pass1-frontend-prompt.md を使用してください
+```bash
+cat claudeos-core/generated/pass2-prompt.md \
+  | claude -p --dangerously-skip-permissions
 ```
 
-**確認：** `ls claudeos-core/generated/pass1-*.json` でグループごとに1つの JSON があることを確認。
+**確認：** `claudeos-core/generated/pass2-merged.json` が存在し、最上位キーが 9 個以上あるはずです。
 
-#### Step 5：Pass 2 — 分析結果の統合
+#### Step 6：Pass 3 — すべてのドキュメントを生成
 
 ```bash
-cat claudeos-core/generated/pass2-prompt.md \
+cat claudeos-core/generated/pass3-prompt.md \
   | claude -p --dangerously-skip-permissions
 ```
 
-**確認：** `claudeos-core/generated/pass2-merged.json` が存在し、9つ以上のトップレベルキーがあること。
+**確認：** プロジェクトルートに `CLAUDE.md` が存在し、`claudeos-core/generated/pass3-complete.json` マーカーが書き込まれているはずです。
 
-#### Step 6：Pass 3 — 全ドキュメント生成
+> **注意（v2.0.0）：** Claude Code の sensitive-path ポリシーが `.claude/` への直接書き込みをブロックするため、Pass 3 はルールファイルを最初に `claudeos-core/generated/.staged-rules/` に書き込みます。自動化パイプライン（`npx claudeos-core init`）は移動を自動的に処理します。このステップを手動で実行する場合、staged ツリーを自分で移動する必要があります：`mv claudeos-core/generated/.staged-rules/* .claude/rules/`（サブパスを保持）。
+
+#### Step 7：Pass 4 — メモリスキャフォールディング
 
 ```bash
-cat claudeos-core/generated/pass3-prompt.md \
+cat claudeos-core/generated/pass4-prompt.md \
   | claude -p --dangerously-skip-permissions
 ```
 
-**確認：** プロジェクトルートに `CLAUDE.md` が存在すること。
+**確認：** `claudeos-core/memory/` に 4 ファイル（`decision-log.md`、`failure-patterns.md`、`compaction.md`、`auto-rule-update.md`）、`.claude/rules/60.memory/` に 4 ルールファイル、`claudeos-core/plan/50.memory-master.md` が存在し、`CLAUDE.md` に `## Memory (L4)` セクションが追加されているはずです。マーカー：`claudeos-core/generated/pass4-memory.json`。
+
+> **注意：** `claude -p` が失敗したり `pass4-prompt.md` が欠損している場合、自動化パイプラインは `lib/memory-scaffold.js` を経由した静的スキャフォールドにフォールバックします（`--lang` が非英語の場合は Claude 主導の翻訳付き）。静的フォールバックは `npx claudeos-core init` 内でのみ実行されます — 手動モードでは Pass 4 が成功する必要があります。
 
-#### Step 7：検証ツールの実行
+#### Step 8：検証ツールの実行
 
 ```bash
-# メタデータ生成（他のチェックの前に必須）
+# メタデータを生成（他のチェック前に必須）
 node claudeos-core-tools/manifest-generator/index.js
 
-# 全チェック実行
+# すべてのチェックを実行
 node claudeos-core-tools/health-checker/index.js
 
-# または個別チェック：
-node claudeos-core-tools/plan-validator/index.js --check # Plan ↔ disk
-node claudeos-core-tools/sync-checker/index.js          # Sync status
-node claudeos-core-tools/content-validator/index.js     # Content quality
-node claudeos-core-tools/pass-json-validator/index.js   # JSON format
+# または個別にチェックを実行：
+node claudeos-core-tools/plan-validator/index.js --check # Plan ↔ disk 整合性
+node claudeos-core-tools/sync-checker/index.js          # 未登録/孤児ファイル
+node claudeos-core-tools/content-validator/index.js     # ファイル品質チェック（memory/ セクション [9/9] を含む）
+node claudeos-core-tools/pass-json-validator/index.js   # Pass 1–4 JSON + 完了マーカーチェック
 ```
 
-#### Step 8：結果の確認
+#### Step 9：結果の確認
 
 ```bash
+# 生成されたファイル数をカウント
 find .claude claudeos-core -type f | grep -v node_modules | grep -v '/generated/' | wc -l
+
+# CLAUDE.md を確認
 head -30 CLAUDE.md
+
+# standard ファイルを確認
+cat claudeos-core/standard/00.core/01.project-overview.md | head -20
+
+# rules を確認
 ls .claude/rules/*/
 ```
 
-> **ヒント：** 特定のステップで失敗した場合、そのステップだけを再実行できます。Pass 1/2 の結果はキャッシュされます — `pass1-N.json` や `pass2-merged.json` が既に存在する場合、自動パイプラインはスキップします。`npx claudeos-core init --force` を使用すると、以前の結果を削除して最初からやり直します。
+> **ヒント：** 任意のステップが失敗した場合、問題を修正してそのステップだけを再実行できます。Pass 1/2 の結果はキャッシュされます — `pass1-N.json` または `pass2-merged.json` がすでに存在する場合、自動化パイプラインはそれらをスキップします。`npx claudeos-core init --force` で以前の結果を削除して最初から実行します。
 
 ### 使い始める
 
 ```
-# Claude Code で自然言語で話しかけるだけ：
-「注文ドメインの CRUD を作成して」
-「ユーザー認証 API を追加して」
-「このコードをプロジェクトのパターンに合わせてリファクタリングして」
+# Claude Code で — 自然に依頼するだけ：
+"order ドメインの CRUD を作成して"
+"ユーザー認証 API を追加して"
+"このコードをプロジェクトのパターンに合わせてリファクタリングして"
 
-# Claude Code が生成された Standards、Rules、Skills を自動参照します。
+# Claude Code が生成された Standards、Rules、Skills を自動的に参照します。
 ```
 
 ---
 
-## 仕組み — 3-Pass パイプライン
+## 仕組み — 4-Pass パイプライン
 
 ```
 npx claudeos-core init
     │
-    ├── [1] npm install                    ← 依存関係インストール（~10秒）
-    ├── [2] ディレクトリ構造作成            ← フォルダ作成（~1秒）
-    ├── [3] plan-installer (Node.js)       ← プロジェクトスキャン（~5秒）
+    ├── [1] npm install                    ← 依存関係（~10 秒）
+    ├── [2] ディレクトリ構造                 ← フォルダ作成（~1 秒）
+    ├── [3] plan-installer (Node.js)       ← プロジェクトスキャン（~5 秒）
     │       ├── スタック自動検出（マルチスタック対応）
-    │       ├── ドメインリスト抽出（backend/frontend タグ付き）
-    │       ├── タイプ別にドメイングループ分割
-    │       └── スタック固有のプロンプト選択（タイプ別）
+    │       ├── ドメインリスト抽出（タグ付け：backend/frontend）
+    │       ├── ドメイングループに分割（タイプ別）
+    │       └── スタック固有のプロンプトを選択（タイプ別）
+    │
+    ├── [4] Pass 1 × N  (claude -p)       ← 深層コード分析（~2-8 分）
+    │       ├── ⚙️ バックエンドグループ → バックエンド固有プロンプト
+    │       └── 🎨 フロントエンドグループ → フロントエンド固有プロンプト
     │
-    ├── [4] Pass 1 × N  (claude -p)       ← コードディープ分析（~2-8分）
-    │       ├── ⚙️ バックエンドグループ → バックエンド専用分析プロンプト
-    │       └── 🎨 フロントエンドグループ → フロントエンド専用分析プロンプト
+    ├── [5] Pass 2 × 1  (claude -p)       ← 分析マージ（~1 分）
+    │       └── すべての Pass 1 結果を統合（backend + frontend）
     │
-    ├── [5] Pass 2 × 1  (claude -p)       ← 分析結果の統合（~1分）
-    │       └── すべての Pass 1 結果を統合（バックエンド + フロントエンド）
+    ├── [6] Pass 3 × 1  (claude -p)       ← すべてを生成（~3-5 分）
+    │       └── 結合プロンプト（backend + frontend ターゲット）
     │
-    ├── [6] Pass 3 × 1  (claude -p)       ← 全ファイル生成（~3-5分）
-    │       └── 統合プロンプト（バックエンド + フロントエンドターゲット）
+    ├── [7] Pass 4 × 1  (claude -p)       ← メモリスキャフォールディング（~30 秒）
+    │       ├── memory/ をシード（decision-log、failure-patterns、…）
+    │       ├── 60.memory/ ルールを生成
+    │       ├── CLAUDE.md に "Memory (L4)" セクションを追加
+    │       └── 50.memory-master.md プランを構築
     │
-    └── [7] 検証                           ← ヘルスチェッカー自動実行
+    └── [8] 検証                           ← health checker を自動実行
 ```
 
-### なぜ 3 Pass なのか？
+### なぜ 4 Pass なのか？
 
-**Pass 1** はソースコードを読む唯一のパスです。ドメインごとに代表ファイルを選択し、55–95 の分析カテゴリにわたってパターンを抽出します。大規模プロジェクトでは、Pass 1 はドメイングループごとに複数回実行されます。マルチスタックプロジェクト（例：Java バックエンド + React フロントエンド）では、バックエンドとフロントエンドに**それぞれ専用の分析プロンプト**が使用されます。
+**Pass 1** はソースコードを読む唯一の Pass です。ドメインごとに代表ファイルを選択し、55–95 分析カテゴリ（スタック別）全体でパターンを抽出します。大規模プロジェクトでは、Pass 1 はドメイングループごとに 1 回ずつ複数回実行されます。マルチスタックプロジェクト（例：Java backend + React frontend）では、backend と frontend のドメインは各スタックに合わせた**異なる分析プロンプト**を使用します。
 
-**Pass 2** はすべての Pass 1 結果を統合分析に統合します：共通パターン（100% 共有）、多数派パターン（50%+ 共有）、ドメイン固有パターン、重大度別アンチパターン、横断的関心事（命名、セキュリティ、DB、テスト、ロギング、パフォーマンス）。
+**Pass 2** はすべての Pass 1 結果を統一された分析にマージします：共通パターン（100% 共有）、多数派パターン（50%+ 共有）、ドメイン固有パターン、重大度別のアンチパターン、横断的関心事（命名、セキュリティ、DB、テスト、ロギング、パフォーマンス）。backend と frontend の結果は一緒にマージされます。
 
-**Pass 3** は統合された分析結果を基にファイルエコシステム全体を生成します。ソースコードは一切読みません — 分析 JSON のみを参照します。マルチスタックモードでは、生成プロンプトがバックエンドとフロントエンドのターゲットを統合し、一回のパスで両方の標準ドキュメントを生成します。
+**Pass 3** は統合された分析を受け取り、ファイルエコシステム全体（CLAUDE.md、rules、standards、skills、guides）を生成します。ソースコードは決して読まず、分析 JSON のみを参照します。マルチスタックモードでは、生成プロンプトは backend と frontend のターゲットを結合するため、両方のスタンダードセットが 1 回のパスで生成されます。
+
+**Pass 4** は L4 メモリレイヤをスキャフォールディングします：永続的なチーム知識ファイル（decision-log、failure-patterns、compaction ポリシー、auto-rule-update）に加えて、これらのファイルをいつどのように読み書きするかを将来のセッションに指示する `60.memory/` ルール。メモリレイヤこそが、Claude Code がセッションごとに学びを再発見するのではなく、セッション間で蓄積することを可能にします。`--lang` が非英語の場合、フォールバック静的コンテンツは書き込み前に Claude を経由して翻訳されます。
 
 ---
 
@@ -371,132 +449,217 @@ your-project/
 │       ├── 20.frontend/
 │       ├── 30.security-db/
 │       ├── 40.infra/
-│       └── 50.sync/                   ← 同期リマインダールール
+│       ├── 50.sync/                   ← 同期リマインダールール
+│       └── 60.memory/                 ← L4 メモリオンデマンドスコープルール（v2.0.0）
 │
 ├── claudeos-core/                     ← メイン出力ディレクトリ
-│   ├── generated/                     ← 分析 JSON + 動的プロンプト
-│   ├── standard/                      ← コーディング標準（15-19 ファイル）
+│   ├── generated/                     ← 分析 JSON + 動的プロンプト + Pass マーカー（gitignore 対象）
+│   │   ├── project-analysis.json      ← スタック情報（マルチスタック対応）
+│   │   ├── domain-groups.json         ← type: backend/frontend 付きグループ
+│   │   ├── pass1-backend-prompt.md    ← バックエンド分析プロンプト
+│   │   ├── pass1-frontend-prompt.md   ← フロントエンド分析プロンプト（検出時）
+│   │   ├── pass2-prompt.md            ← マージプロンプト
+│   │   ├── pass3-prompt.md            ← 生成プロンプト（結合）
+│   │   ├── pass4-prompt.md            ← メモリスキャフォールディングプロンプト（v2.0.0）
+│   │   ├── pass3-complete.json        ← Pass 3 完了マーカー（再実行時スキップ）
+│   │   ├── pass4-memory.json          ← Pass 4 完了マーカー（再実行時スキップ）
+│   │   ├── .i18n-cache-<lang>.json    ← 翻訳キャッシュ（非英語 `--lang`）
+│   │   └── .staged-rules/             ← `.claude/rules/` 書き込み用一時ステージングディレクトリ（自動移動 + クリーン）
+│   ├── standard/                      ← コーディングスタンダード（15-19 ファイル）
+│   │   ├── 00.core/                   ← 概要、アーキテクチャ、命名
+│   │   ├── 10.backend-api/            ← API パターン（スタック固有）
+│   │   ├── 20.frontend-ui/            ← フロントエンドパターン（検出時）
+│   │   ├── 30.security-db/            ← セキュリティ、DB スキーマ、ユーティリティ
+│   │   ├── 40.infra/                  ← 設定、ロギング、CI/CD
+│   │   ├── 50.verification/           ← ビルド検証、テスト
+│   │   └── 90.optional/               ← オプション規約（スタック固有エクストラ）
 │   ├── skills/                        ← CRUD スキャフォールディングスキル
 │   ├── guide/                         ← オンボーディング、FAQ、トラブルシューティング（9 ファイル）
-│   ├── plan/                          ← Master Plans（バックアップ/リストア）
+│   ├── plan/                          ← マスタープラン（バックアップ/リストア）
 │   ├── database/                      ← DB スキーマ、マイグレーションガイド
-│   └── mcp-guide/                     ← MCP サーバー連携ガイド
+│   ├── mcp-guide/                     ← MCP サーバ統合ガイド
+│   └── memory/                        ← L4：チーム知識（4 ファイル）— コミットする
+│       ├── decision-log.md            ← 設計決定の「なぜ」
+│       ├── failure-patterns.md        ← 再発エラー & 修正（自動スコアリング — `npx claudeos-core memory score`）
+│       ├── compaction.md              ← 4 ステージコンパクション戦略（`npx claudeos-core memory compact` で実行）
+│       └── auto-rule-update.md        ← ルール改善提案（`npx claudeos-core memory propose-rules`）
 │
-└── claudeos-core-tools/               ← 本ツールキット（変更不要）
+└── claudeos-core-tools/               ← このツールキット（変更しない）
 ```
 
-すべての標準ファイルに ✅ 正しい例、❌ 誤った例、ルールサマリーテーブルが含まれます — すべてあなたの実際のコードパターンから導出され、汎用テンプレートではありません。
+すべての standard ファイルは ✅ 正しい例、❌ 間違った例、ルール要約テーブルを含みます — すべて汎用テンプレートではなく、実際のコードパターンから導出されます。
+
+### Gitignore 推奨事項
+
+**コミットする**（チーム知識 — 共有が目的）：
+- `CLAUDE.md` — Claude Code エントリーポイント
+- `.claude/rules/**` — 自動ロードルール
+- `claudeos-core/standard/**`、`skills/**`、`guide/**`、`database/**`、`mcp-guide/**`、`plan/**` — 生成されたドキュメント
+- `claudeos-core/memory/**` — 決定履歴、失敗パターン、ルール提案
+
+**コミットしない**（再生成可能なビルド成果物）：
+
+```gitignore
+# ClaudeOS-Core — 生成された分析 & 翻訳キャッシュ
+claudeos-core/generated/
+```
+
+`generated/` ディレクトリには分析 JSON（`pass1-*.json`、`pass2-merged.json`）、プロンプト（`pass1/2/3/4-prompt.md`）、Pass 完了マーカー（`pass3-complete.json`、`pass4-memory.json`）、翻訳キャッシュ（`.i18n-cache-<lang>.json`）、一時ステージングディレクトリ（`.staged-rules/`）が含まれます — すべて `npx claudeos-core init` を再実行することで再構築可能です。
 
 ---
 
-## プロジェクト規模による自動スケーリング
+## プロジェクトサイズによる自動スケーリング
 
-| 規模 | ドメイン数 | Pass 1 回数 | `claude -p` 合計 | 推定時間 |
+| サイズ | ドメイン | Pass 1 実行回数 | 合計 `claude -p` | 推定時間 |
 |---|---|---|---|---|
-| 小規模 | 1–4 | 1 | 3 | ~5分 |
-| 中規模 | 5–8 | 2 | 4 | ~8分 |
-| 大規模 | 9–16 | 3–4 | 5–6 | ~12分 |
-| 超大規模 | 17+ | 5+ | 7+ | ~18分+ |
+| 小規模 | 1–4 | 1 | 4 (Pass 1 + 2 + 3 + 4) | ~5–6 分 |
+| 中規模 | 5–8 | 2 | 5 | ~8–9 分 |
+| 大規模 | 9–16 | 3–4 | 6–7 | ~12–13 分 |
+| 超大規模 | 17+ | 5+ | 8+ | ~18 分+ |
 
-マルチスタックプロジェクト（例：Java + React）では、バックエンドとフロントエンドのドメインを合算してカウントします。バックエンド 6 + フロントエンド 4 = 合計 10 ドメインで「大規模」としてスケーリングします。
+Pass 4（メモリスキャフォールディング）は分析 Pass の上に ~30 秒を追加します。マルチスタックプロジェクト（例：Java + React）では、backend と frontend のドメインが合算されます。backend 6 + frontend 4 ドメイン = 合計 10 で「大規模」としてスケーリングされます。
 
 ---
 
 ## 検証ツール
 
-ClaudeOS-Core には生成後に自動実行される 5 つの組み込み検証ツールがあります：
+ClaudeOS-Core には生成後に自動的に実行される 5 つの組み込み検証ツールが含まれています：
 
 ```bash
-# 全チェックを一括実行（推奨）
+# すべてのチェックを一度に実行（推奨）
 npx claudeos-core health
 
 # 個別コマンド
-npx claudeos-core validate     # Plan ↔ ディスク比較
-npx claudeos-core refresh      # ディスク → Plan 同期
-npx claudeos-core restore      # Plan → ディスク復元
+npx claudeos-core validate     # Plan ↔ disk 比較
+npx claudeos-core refresh      # Disk → Plan 同期
+npx claudeos-core restore      # Plan → Disk リストア
+
+# または node を直接使用（git clone ユーザー）
+node claudeos-core-tools/health-checker/index.js
+node claudeos-core-tools/manifest-generator/index.js
+node claudeos-core-tools/plan-validator/index.js --check
+node claudeos-core-tools/sync-checker/index.js
 ```
 
-| ツール | 機能 |
+| ツール | 役割 |
 |---|---|
-| **manifest-generator** | メタデータ JSON を構築（rule-manifest、sync-map、plan-manifest） |
-| **plan-validator** | Master Plan の `<file>` ブロックとディスクを比較 — 3 モード：check、refresh、restore |
-| **sync-checker** | 未登録ファイル（ディスク上にあるがプランにない）と孤立エントリを検出 |
-| **content-validator** | ファイル品質を検証 — 空ファイル、✅/❌ 例の欠落、必須セクション |
-| **pass-json-validator** | Pass 1–3 JSON 構造、必須キー、セクション完全性を検証 |
+| **manifest-generator** | メタデータ JSON を構築（rule-manifest、sync-map、plan-manifest）；`memory/` を含む 7 ディレクトリをインデックス化（要約の `totalMemory`） |
+| **plan-validator** | Master Plan の `<file>` ブロックを disk と比較 — 3 モード：check、refresh、restore |
+| **sync-checker** | 未登録ファイル（disk 上にあるが plan にない）と孤児エントリを検出 — 7 ディレクトリをカバー（v2.0.0 で `memory/` を追加） |
+| **content-validator** | 9 セクションの品質チェック — 空ファイル、✅/❌ 例の欠損、必須セクション、加えて L4 メモリスキャフォールドの整合性（decision-log 見出し日付、failure-pattern 必須フィールド、フェンス認識パース） |
+| **pass-json-validator** | Pass 1–4 JSON 構造に加えて `pass3-complete.json` と `pass4-memory.json` 完了マーカーを検証 |
 
 ---
 
-## Claude Code がドキュメントを使用する仕組み
+## Claude Code がドキュメントを使う仕組み
 
-ClaudeOS-Core が生成したドキュメントを Claude Code が実際に読み取る仕組みです：
+ClaudeOS-Core が生成するドキュメントは、Claude Code が実際に読み取るドキュメントです — その方法は以下のとおりです：
 
-### 自動的に読み取るファイル
+### Claude Code が自動的に読むファイル
 
 | ファイル | タイミング | 保証 |
 |---|---|---|
-| `CLAUDE.md` | 毎回の会話開始時 | 常に |
-| `.claude/rules/00.core/*` | ファイル編集時（`paths: ["**/*"]`） | 常に |
-| `.claude/rules/10.backend/*` | ファイル編集時（`paths: ["**/*"]`） | 常に |
-| `.claude/rules/30.security-db/*` | ファイル編集時（`paths: ["**/*"]`） | 常に |
-| `.claude/rules/40.infra/*` | config/infraファイル編集時のみ（スコープ付きpaths） | 条件付き |
-| `.claude/rules/50.sync/*` | claudeos-coreファイル編集時のみ（スコープ付きpaths） | 条件付き |
+| `CLAUDE.md` | すべての会話開始時 | 常時 |
+| `.claude/rules/00.core/*` | 任意のファイル編集時（`paths: ["**/*"]`） | 常時 |
+| `.claude/rules/10.backend/*` | 任意のファイル編集時（`paths: ["**/*"]`） | 常時 |
+| `.claude/rules/20.frontend/*` | フロントエンドファイル編集時（component/page/style パスにスコープ） | 条件付き |
+| `.claude/rules/30.security-db/*` | 任意のファイル編集時（`paths: ["**/*"]`） | 常時 |
+| `.claude/rules/40.infra/*` | config/infra ファイル編集時のみ（スコープ付き paths） | 条件付き |
+| `.claude/rules/50.sync/*` | claudeos-core ファイル編集時のみ（スコープ付き paths） | 条件付き |
+| `.claude/rules/60.memory/*` | `claudeos-core/memory/*` 編集時（memory パスにスコープ） — オンデマンドメモリレイヤを**どのように**読み書きするかを指示 | 条件付き（v2.0.0） |
 
-### ルール参照によるオンデマンド読み取り
+### Claude Code がルール参照経由でオンデマンドで読むもの
 
-各ルールファイル末尾の `## Reference` セクションが対応するstandardをリンクします。Claudeは現在のタスクに関連するstandardのみ読み取ります：
+各ルールファイルは `## Reference` セクションを通じて対応する standard にリンクします。Claude は現在のタスクに関連する standard のみを読みます：
 
-- `claudeos-core/standard/**` — コーディングパターン、✅/❌ 例、命名規則
+- `claudeos-core/standard/**` — コーディングパターン、✅/❌ 例、命名規約
 - `claudeos-core/database/**` — DB スキーマ（クエリ、マッパー、マイグレーション用）
+- `claudeos-core/memory/**`（v2.0.0）— L4 チーム知識レイヤ；**自動ロードされない**（すべての会話でノイジーになりすぎる）。代わりに、`60.memory/*` ルールが Claude にこれらのファイルを*いつ* Read するかを指示：セッション開始時（最近の `decision-log.md` + 重要度の高い `failure-patterns.md` をスキム）、決定を下すか再発エラーに遭遇したときにオンデマンドで追記。
 
-`00.standard-reference.md` は対応ルールのないstandardを発見するためのディレクトリです。
+`00.standard-reference.md` は、対応するルールがない standard を発見するためのすべての standard ファイルのディレクトリとして機能します。
 
-### 読み取らないファイル（コンテキスト節約）
+### Claude Code が読まないもの（コンテキスト節約）
 
-standard-reference ルールの `DO NOT Read` セクションで明示的に除外されます：
+これらのフォルダは standard-reference ルールの `DO NOT Read` セクションを通じて明示的に除外されます：
 
 | フォルダ | 除外理由 |
 |---|---|
 | `claudeos-core/plan/` | Master Plan バックアップ（~340KB）。`npx claudeos-core refresh` で同期。 |
-| `claudeos-core/generated/` | ビルドメタデータ JSON。コーディング参照不要。 |
+| `claudeos-core/generated/` | ビルドメタデータ JSON、プロンプト、Pass マーカー、翻訳キャッシュ、`.staged-rules/`。コーディング用ではありません。 |
 | `claudeos-core/guide/` | 人間向けオンボーディングガイド。 |
-| `claudeos-core/mcp-guide/` | MCP サーバードキュメント。コーディング参照不要。 |
+| `claudeos-core/mcp-guide/` | MCP サーバドキュメント。コーディング用ではありません。 |
+| `claudeos-core/memory/`（自動ロード） | **自動ロード無効化**設計 — すべての会話でコンテキストが肥大化。代わりに `60.memory/*` ルール経由でオンデマンド読み込み（例：セッション開始時の `failure-patterns.md` スキャン）。常にコミットする。 |
 
 ---
 
-## 日常ワークフロー
+## 日常のワークフロー
 
 ### インストール後
 
 ```
-# 通常通り Claude Code を使うだけ — 標準を自動参照します：
-「注文ドメインの CRUD を作成して」
-「ユーザープロフィール更新 API を追加して」
-「このコードをプロジェクトのパターンに合わせてリファクタリングして」
+# Claude Code を通常通り使用するだけ — スタンダードを自動的に参照します：
+"order ドメインの CRUD を作成して"
+"ユーザープロファイル更新 API を追加して"
+"このコードをプロジェクトのパターンに合わせてリファクタリングして"
 ```
 
-### 標準ファイルを手動編集した後
+### スタンダードを手動編集した後
 
 ```bash
 # standard や rules ファイルを編集した後：
 npx claudeos-core refresh
 
-# 整合性を検証
+# すべての整合性を確認
 npx claudeos-core health
 ```
 
-### ドキュメントが破損した場合
+### ドキュメントが壊れたとき
 
 ```bash
-# Master Plan からすべて復元
+# Master Plan からすべてをリストア
 npx claudeos-core restore
 ```
 
+### メモリレイヤメンテナンス（v2.0.0）
+
+L4 メモリレイヤ（`claudeos-core/memory/`）はセッション間でチーム知識を蓄積します。3 つの CLI サブコマンドが健全性を維持します：
+
+```bash
+# Compact：4 ステージコンパクションポリシーを適用（定期的 — 例：月次）
+npx claudeos-core memory compact
+#   Stage 1：古いエントリを要約（>30 日、本文 → 一行）
+#   Stage 2：重複見出しをマージ（frequency 合算、最新の fix を保持）
+#   Stage 3：低重要度 + 古いものをドロップ（importance <3 AND lastSeen >60 日）
+#   Stage 4：ファイルあたり 400 行の上限を強制（最も古い低重要度から先にドロップ）
+
+# Score：failure-patterns.md エントリを重要度で再ランク付け
+npx claudeos-core memory score
+#   importance = round(frequency × 1.5 + recency × 5)、最大 10
+#   複数の新しい失敗パターンを追加後に実行
+
+# Propose-rules：再発する失敗から候補ルール追加を提示
+npx claudeos-core memory propose-rules
+#   frequency ≥ 3 の failure-patterns.md エントリを読み込み
+#   confidence を計算（重み付けエビデンスに sigmoid × アンカー倍率）
+#   memory/auto-rule-update.md に提案を書き込み（自動適用されない）
+#   Confidence ≥ 0.70 は真剣な検討に値する；受諾 → ルール編集 + 決定を記録
+```
+
+メモリに書くタイミング（Claude がオンデマンドで行いますが、手動編集も可能）：
+- **`decision-log.md`** — 競合するパターン間で選択するとき、ライブラリを選ぶとき、チーム規約を定義するとき、または何かを*やらない*と決めるときに新しいエントリを追記。追記のみ；履歴エントリは決して編集しない。
+- **`failure-patterns.md`** — 再発エラーまたは自明でない根本原因の**2 回目の発生時**に追記。初回エラーはエントリ不要。
+- `compaction.md` と `auto-rule-update.md` — 上記の CLI サブコマンドが生成/管理；手動編集しない。
+
 ### CI/CD 統合
 
 ```yaml
 # GitHub Actions の例
 - run: npx claudeos-core validate
-# 終了コード 1 で PR をブロック
+# Exit code 1 で PR がブロックされる
+
+# オプション：月次メモリハウスキーピング（別 cron ワークフロー）
+- run: npx claudeos-core memory compact
+- run: npx claudeos-core memory score
 ```
 
 ---
@@ -507,69 +670,86 @@ npx claudeos-core restore
 
 | | ClaudeOS-Core | Everything Claude Code (50K+ ⭐) | Harness | specs-generator | Claude `/init` |
 |---|---|---|---|---|---|
-| **アプローチ** | コードが先に分析、LLMが生成 | 既製設定プリセット | LLMがエージェントチーム設計 | LLMがスペック文書生成 | LLMがCLAUDE.md作成 |
-| **ソースコード直接分析** | ✅ Deterministic 静的分析 | ❌ | ❌ | ❌ (LLMが読む) | ❌ (LLMが読む) |
-| **スタック検出** | コードが確定 (ORM, DB, ビルドツール, パッケージマネージャー) | N/A (スタック非依存) | LLMが推測 | LLMが推測 | LLMが推測 |
-| **ドメイン検出** | コードが確定 (Java 5パターン, Kotlin CQRS, Next.js FSD) | N/A | LLMが推測 | N/A | N/A |
-| **同じプロジェクト → 同じ結果** | ✅ Deterministic 分析 | ✅ (静的ファイル) | ❌ (LLM結果が変動) | ❌ (LLM結果が変動) | ❌ (LLM結果が変動) |
-| **大規模プロジェクト** | ドメイングループ分割 (4 ドメイン / 40 ファイル) | N/A | 分割なし | 分割なし | コンテキストウィンドウ制限 |
-| **出力** | CLAUDE.md + Rules + Standards + Skills + Guides + Plans (40-50+ ファイル) | Agents + Skills + Commands + Hooks | Agents + Skills | 6 スペック文書 | CLAUDE.md (1 ファイル) |
-| **出力場所** | `.claude/rules/` (Claude Code自動ロード) | `.claude/` 各所 | `.claude/agents/` + `.claude/skills/` | `.claude/steering/` + `specs/` | `CLAUDE.md` |
-| **生成後検証** | ✅ 5 自動検証ツール | ❌ | ❌ | ❌ | ❌ |
+| **アプローチ** | コードが先に分析、次に LLM が生成 | 事前構築された設定プリセット | LLM がエージェントチームを設計 | LLM がスペックドキュメントを生成 | LLM が CLAUDE.md を書く |
+| **ソースコードを読む** | ✅ 決定論的静的解析 | ❌ | ❌ | ❌ (LLM が読む) | ❌ (LLM が読む) |
+| **スタック検出** | コードが確定（ORM、DB、ビルドツール、pkg manager） | N/A（スタック非依存） | LLM が推測 | LLM が推測 | LLM が推測 |
+| **ドメイン検出** | コードが確定（Java 5 patterns、Kotlin CQRS、Next.js FSD） | N/A | LLM が推測 | N/A | N/A |
+| **同じプロジェクト → 同じ結果** | ✅ 決定論的分析 | ✅（静的ファイル） | ❌（LLM は揺れる） | ❌（LLM は揺れる） | ❌（LLM は揺れる） |
+| **大規模プロジェクトへの対応** | ドメイングループ分割（4 ドメイン / 40 ファイル / グループ） | N/A | 分割なし | 分割なし | コンテキストウィンドウ制限 |
+| **出力** | CLAUDE.md + Rules + Standards + Skills + Guides + Plans（40-50+ ファイル） | Agents + Skills + Commands + Hooks | Agents + Skills | 6 スペックドキュメント | CLAUDE.md（1 ファイル） |
+| **出力場所** | `.claude/rules/`（Claude Code が自動ロード） | `.claude/` 各種 | `.claude/agents/` + `.claude/skills/` | `.claude/steering/` + `specs/` | `CLAUDE.md` |
+| **生成後検証** | ✅ 5 つの自動バリデータ | ❌ | ❌ | ❌ | ❌ |
 | **多言語出力** | ✅ 10 言語 | ❌ | ❌ | ❌ | ❌ |
-| **マルチスタック** | ✅ バックエンド + フロントエンド同時 | ❌ スタック非依存 | ❌ | ❌ | 部分的 |
-| **エージェントオーケストレーション** | ❌ | ✅ 28 エージェント | ✅ 6 パターン | ❌ | ❌ |
+| **マルチスタック** | ✅ Backend + Frontend 同時 | ❌ スタック非依存 | ❌ | ❌ | 部分的 |
+| **永続メモリレイヤ** | ✅ L4 — 決定ログ + 失敗パターン + 自動スコア付きルール提案（v2.0.0） | ❌ | ❌ | ❌ | ❌ |
+| **エージェントオーケストレーション** | ❌ | ✅ 28 agents | ✅ 6 patterns | ❌ | ❌ |
 
-### 核心的な違い一言
+### 一文にまとめた重要な違い
 
-**他のツールは Claude に「一般的に良い指示」を与えます。ClaudeOS-Core は Claude に「実際のコードから抽出した指示」を与えます。**
+**他のツールは Claude に「一般的に良い指示」を与えます。ClaudeOS-Core は Claude に「あなたの実際のコードから抽出された指示」を与えます。**
 
-だから Claude Code が MyBatis プロジェクトで JPA コードを生成することがなくなり、
-`success()` の代わりに `ok()` を使うミスがなくなり、
-`controller/user/` 構造なのに `user/controller/` を作ることがなくなります。
+だから Claude Code は MyBatis プロジェクトで JPA コードを生成しなくなり、
+コードベースが `ok()` を使っているときに `success()` を使わなくなり、
+プロジェクトが `controller/user/` を使うときに `user/controller/` ディレクトリを作成しなくなるのです。
 
 ### 競合ではなく補完
 
-ClaudeOS-Core は**プロジェクト固有のルールと標準**に集中します。
-他のツールは**エージェントオーケストレーションとワークフロー**に集中します。
+ClaudeOS-Core は**プロジェクト固有のルールとスタンダード**にフォーカスします。
+他のツールは**エージェントオーケストレーションとワークフロー**にフォーカスします。
 
-ClaudeOS-Core でプロジェクトルールを生成し、その上に ECC や Harness を載せてエージェントチームとワークフロー自動化を構成できます。異なる問題を解決するツールです。
+ClaudeOS-Core を使ってプロジェクトのルールを生成し、その上に ECC や Harness を乗せてエージェントチームとワークフロー自動化を構築できます。異なる問題を解決しています。
 
 ---
+
 ## FAQ
 
-**Q：ソースコードは変更されますか？**
-いいえ。`CLAUDE.md`、`.claude/rules/`、`claudeos-core/` のみ作成します。既存のコードは一切変更されません。
+**Q：ソースコードを変更しますか？**
+いいえ。`CLAUDE.md`、`.claude/rules/`、`claudeos-core/` を作成するだけです。既存のコードは決して変更されません。
 
 **Q：コストはどのくらいですか？**
-`claude -p` を 3–7 回呼び出します。Claude Code の通常使用範囲内です。
+`claude -p` を 4–8 回呼び出します（Pass 1 × N + Pass 2 + Pass 3 + Pass 4）。これは通常の Claude Code 使用量の範囲内です。`--lang` が非英語の場合、静的フォールバックパスは翻訳のために追加の `claude -p` 呼び出しを数回行うことがあります；結果は `claudeos-core/generated/.i18n-cache-<lang>.json` にキャッシュされ、その後の実行で再利用されます。
 
 **Q：生成されたファイルを Git にコミットすべきですか？**
-推奨します。チームで同じ Claude Code 標準を共有できます。`claudeos-core/generated/` は `.gitignore` に追加することを検討してください（分析 JSON は再生成可能です）。
+はい、推奨します。チームが同じ Claude Code スタンダードを共有できます。`claudeos-core/generated/` を `.gitignore` に追加することを検討してください（分析 JSON は再生成可能）。
 
-**Q：混合スタックプロジェクト（例：Java バックエンド + React フロントエンド）はどうなりますか？**
-完全対応しています。ClaudeOS-Core は両方のスタックを自動検出し、ドメインを `backend` または `frontend` としてタグ付けし、それぞれにスタック固有の分析プロンプトを使用します。Pass 2 がすべてを統合し、Pass 3 がバックエンドとフロントエンドの標準を一回のパスで生成します。
+**Q：混合スタックプロジェクト（例：Java backend + React frontend）はどうですか？**
+完全にサポートされています。ClaudeOS-Core は両方のスタックを自動検出し、ドメインを `backend` または `frontend` としてタグ付けし、それぞれにスタック固有の分析プロンプトを使用します。Pass 2 がすべてをマージし、Pass 3 が 1 回のパスで backend と frontend の両方のスタンダードを生成します。
 
-**Q：再実行するとどうなりますか？**
-以前の Pass 1/2 の結果が存在する場合、インタラクティブプロンプトが表示されます：**Continue**（中断した箇所から再開）または **Fresh**（すべて削除して最初からやり直し）。`--force` を使用するとプロンプトをスキップし、常に最初からやり直します。Pass 3 は常に再実行されます。以前のバージョンは Master Plans から復元できます。
+**Q：Turborepo / pnpm workspaces / Lerna モノレポで動作しますか？**
+はい。ClaudeOS-Core は `turbo.json`、`pnpm-workspace.yaml`、`lerna.json`、または `package.json#workspaces` を検出し、サブパッケージの `package.json` ファイルをスキャンして framework/ORM/DB 依存関係を自動検索します。ドメインスキャンは `apps/*/src/` と `packages/*/src/` パターンをカバーします。モノレポのルートから実行してください。
 
-**Q：NestJSはExpressと同じテンプレートを使用しますか？**
-NestJSは専用の`node-nestjs`テンプレートを使用し、NestJS固有の分析カテゴリ（`@Module`、`@Injectable`、`@Controller`デコレータ、Guards、Pipes、Interceptors、DIコンテナ、CQRSパターン、`Test.createTestingModule`）を含みます。Expressプロジェクトは別の`node-express`テンプレートを使用します。
+**Q：再実行すると何が起きますか？**
+以前の Pass 1/2 結果が存在する場合、インタラクティブプロンプトが選択を提示します：**Continue**（停止した場所から再開）または **Fresh**（すべて削除して最初からやり直し）。`--force` でプロンプトをスキップして常に Fresh で開始します。Pass 3 は常に再実行されます。以前のバージョンは Master Plans から復元可能です。
 
-**Q：Vue/Nuxtプロジェクトはどうですか？**
-Vue/Nuxtは専用の`vue-nuxt`テンプレートを使用し、Composition API、`<script setup>`、defineProps/defineEmits、Piniaストア、`useFetch`/`useAsyncData`、Nitroサーバールート、`@nuxt/test-utils`をカバーします。Next.js/Reactプロジェクトは`node-nextjs`テンプレートを使用します。
+**Q：NestJS は独自のテンプレートを使用するか、それとも Express のものを使用しますか？**
+NestJS は NestJS 固有の分析カテゴリを備えた専用の `node-nestjs` テンプレートを使用します：`@Module`、`@Injectable`、`@Controller` デコレータ、Guards、Pipes、Interceptors、DI コンテナ、CQRS パターン、`Test.createTestingModule`。Express プロジェクトは別の `node-express` テンプレートを使用します。
 
-**Q：Turborepo/pnpm workspaces/Lernaモノレポで動作しますか？**
-はい。ClaudeOS-Coreは`turbo.json`、`pnpm-workspace.yaml`、`lerna.json`、または`package.json#workspaces`を検出し、サブパッケージの`package.json`ファイルからフレームワーク/ORM/DB依存関係を自動スキャンします。ドメインスキャンは`apps/*/src/`と`packages/*/src/`パターンに対応します。モノレポルートから実行してください。
+**Q：Vue / Nuxt プロジェクトは？**
+Vue/Nuxt は Composition API、`<script setup>`、defineProps/defineEmits、Pinia ストア、`useFetch`/`useAsyncData`、Nitro サーバルート、`@nuxt/test-utils` をカバーする専用の `vue-nuxt` テンプレートを使用します。Next.js/React プロジェクトは `node-nextjs` テンプレートを使用します。
 
-**Q：Kotlinはサポートしていますか？**
-はい。ClaudeOS-Coreは`build.gradle.kts`またはkotlinプラグインのある`build.gradle`からKotlinを自動検出します。Kotlin専用の`kotlin-spring`テンプレートを使用して、data class、sealed class、コルーチン、拡張関数、MockKなどKotlin固有のパターンを分析します。
+**Q：Kotlin をサポートしていますか？**
+はい。ClaudeOS-Core は `build.gradle.kts` または `build.gradle` の kotlin plugin から Kotlin を自動検出します。Kotlin 固有の分析（data classes、sealed classes、coroutines、拡張関数、MockK など）を備えた専用の `kotlin-spring` テンプレートを使用します。
 
-**Q：CQRS / BFFアーキテクチャは？**
-Kotlinマルチモジュールプロジェクトで完全にサポートされています。`settings.gradle.kts`を読み取り、モジュール名からモジュールタイプ（command、query、bff、integration）を検出し、同じドメインのCommand/Queryモジュールをグループ化します。生成される標準には、commandコントローラーとqueryコントローラーの個別ルール、BFF/Feignパターン、モジュール間通信規約が含まれます。
+**Q：CQRS / BFF アーキテクチャは？**
+Kotlin マルチモジュールプロジェクトで完全にサポートされています。ClaudeOS-Core は `settings.gradle.kts` を読み取り、モジュール名からモジュールタイプ（command、query、bff、integration）を検出し、Command/Query モジュール間で同じドメインをグループ化します。生成されるスタンダードには、command controllers と query controllers の別々のルール、BFF/Feign パターン、モジュール間通信規約が含まれます。
 
-**Q：Gradleマルチモジュールmonorepoは？**
-ClaudeOS-Coreはネストの深さに関係なく、すべてのサブモジュール（`**/src/main/kotlin/**/*.kt`）をスキャンします。モジュールタイプは命名規則から推測されます（例：`reservation-command-server` → ドメイン：`reservation`、タイプ：`command`）。共有ライブラリ（`shared-lib`、`integration-lib`）も検出されます。
+**Q：Gradle マルチモジュールモノレポは？**
+ClaudeOS-Core はネスト深度に関係なくすべてのサブモジュール（`**/src/main/kotlin/**/*.kt`）をスキャンします。モジュールタイプは命名規約から推論されます（例：`reservation-command-server` → domain: `reservation`、type: `command`）。共有ライブラリ（`shared-lib`、`integration-lib`）も検出されます。
+
+**Q：L4 メモリレイヤ（v2.0.0）とは？`claudeos-core/memory/` をコミットすべきですか？**
+はい — `claudeos-core/memory/` を**常にコミット**してください。これは永続的なチーム知識です：`decision-log.md` はアーキテクチャ選択の*理由*を記録（追記のみ）、`failure-patterns.md` は再発エラーを重要度スコアとともに登録して将来のセッションで回避できるようにし、`compaction.md` は 4 ステージコンパクションポリシーを定義し、`auto-rule-update.md` は機械生成されたルール改善提案を収集します。ルール（パスごとに自動ロード）とは異なり、メモリファイルは**オンデマンド** — `60.memory/*` ルールがそう指示したときにのみ Claude が読みます（例：セッション開始時の重要度の高い失敗のスキャン）。これによりコンテキストコストを低く保ちながら、長期的な知識を保持します。
+
+**Q：Pass 4 が失敗したらどうなりますか？**
+自動化パイプライン（`npx claudeos-core init`）には静的フォールバックがあります：`claude -p` が失敗するか `pass4-prompt.md` が欠損している場合、`lib/memory-scaffold.js` を通じてメモリレイヤを直接スキャフォールディングします。`--lang` が非英語の場合、静的フォールバックは `claude` CLI 経由で**必ず**翻訳する必要があります — それも失敗すれば、実行は `InitError` で中止されます（静かな英語フォールバックはなし）。`claude` が認証されているときに再実行するか、`--lang en` を使用して翻訳をスキップしてください。翻訳結果は `claudeos-core/generated/.i18n-cache-<lang>.json` にキャッシュされ、その後の実行で再利用されます。
+
+**Q：`memory compact` / `memory score` / `memory propose-rules` は何をしますか？**
+上記の [メモリレイヤメンテナンス](#メモリレイヤメンテナンスv200) セクションを参照してください。要約：`compact` は 4 ステージポリシー（古いものを要約、重複をマージ、低重要度の古いものをドロップ、400 行上限を強制）を実行；`score` は `failure-patterns.md` を重要度（frequency × recency）で再ランク付け；`propose-rules` は再発する失敗から `auto-rule-update.md` への候補ルール追加を提示（自動適用されない — 手動で検討して受諾/拒否）。
+
+**Q：なぜ `--force`（または "fresh" 再開モード）は `.claude/rules/` を削除するのですか？**
+v2.0.0 で Pass 3 の silent-failure ガードが 3 つ追加されました（Guard 3 は 2 つの不完全出力のバリアントをカバー：`guide/` 向けの H2 と `standard/skills/plan` 向けの H1）。Guard 1（「部分 staged-rules 移動」）と Guard 3（「不完全出力 — guide ファイル欠損/空または standard センチネル欠損 / skills 空 / plan 空」）は既存ルールに依存しませんが、Guard 2（「ゼロルール検出」）は依存します — Claude が `staging-override.md` ディレクティブを無視して `.claude/` に直接書き込もうとしたときに発動します（Claude Code の sensitive-path ポリシーがブロックする場所）。以前の実行からの古いルールが Guard 2 を false-negative にする可能性があるため — `--force`/`fresh` は `.claude/rules/` を消去してクリーンな検出を保証します。**ルールファイルへの手動編集は `--force`/`fresh` では失われます**；必要ならば事前にバックアップしてください。
+
+**Q：`claudeos-core/generated/.staged-rules/` とは何ですか、そしてなぜ存在するのですか？**
+Claude Code の sensitive-path ポリシーは `claude -p` サブプロセスから `.claude/` への直接書き込みを拒否します（`--dangerously-skip-permissions` を使用してもです）。v2.0.0 は Pass 3/4 プロンプトにすべての `.claude/rules/` 書き込みをステージングディレクトリにリダイレクトさせることでこれを回避します；その後 Node.js オーケストレータ（このポリシーの対象外）が各パス後に staged ツリーを `.claude/rules/` に移動します。これはユーザーに透過的です — ディレクトリは自動作成、自動クリーン、自動移動されます。以前の実行が移動途中でクラッシュした場合、次の実行はリトライ前にステージングディレクトリを消去します。
 
 ---
 
@@ -577,50 +757,52 @@ ClaudeOS-Coreはネストの深さに関係なく、すべてのサブモジュ
 
 ```
 pass-prompts/templates/
-├── common/                  # 共有ヘッダー/フッター
+├── common/                  # 共有 header/footer + pass4 + staging-override
 ├── java-spring/             # Java / Spring Boot
 ├── kotlin-spring/           # Kotlin / Spring Boot (CQRS, BFF, multi-module)
 ├── node-express/            # Node.js / Express
 ├── node-nestjs/             # Node.js / NestJS (Module, DI, Guard, Pipe, Interceptor)
-├── node-nextjs/             # Next.js / React
-├── vue-nuxt/                # Vue / Nuxt (Composition API, Pinia, Nitro)
-├── python-django/           # Python / Django (DRF)
 ├── node-fastify/            # Node.js / Fastify
+├── node-nextjs/             # Next.js / React (App Router, RSC)
+├── node-vite/               # Vite SPA (React, client-side routing, VITE_ env, Vitest)
+├── vue-nuxt/                # Vue / Nuxt (Composition API, Pinia, Nitro)
 ├── angular/                 # Angular
-└── python-fastapi/          # Python / FastAPI
+├── python-django/           # Python / Django (DRF)
+├── python-fastapi/          # Python / FastAPI
+└── python-flask/            # Python / Flask (Blueprint, app factory, Jinja2)
 ```
 
-`plan-installer` がスタックを自動検出し、タイプ固有のプロンプトを組み立てます。NestJSとVue/Nuxtはフレームワーク固有の分析カテゴリを含む専用テンプレートを使用します（例：NestJSの`@Module`/`@Injectable`/Guards、Vueの`<script setup>`/Pinia/useFetch）。マルチスタックプロジェクトでは、`pass1-backend-prompt.md` と `pass1-frontend-prompt.md` が個別に生成され、`pass3-prompt.md` は両方のスタックの生成ターゲットを統合します。
+`plan-installer` がスタックを自動検出し、タイプ固有のプロンプトを組み立てます。NestJS、Vue/Nuxt、Vite SPA、Flask はそれぞれフレームワーク固有の分析カテゴリを備えた専用テンプレートを使用します（例：NestJS の `@Module`/`@Injectable`/Guards；Vue の `<script setup>`/Pinia/useFetch；Vite の client-side routing/`VITE_` env；Flask の Blueprint/`app.factory`/Flask-SQLAlchemy）。マルチスタックプロジェクトでは、`pass1-backend-prompt.md` と `pass1-frontend-prompt.md` が別々に生成され、`pass3-prompt.md` は両方のスタックの生成ターゲットを結合します。Pass 4 はスタックに関係なく共有の `common/pass4.md` テンプレート（メモリスキャフォールディング）を使用します。
 
 ---
 
-## Monorepo サポート
+## モノレポサポート
 
-ClaudeOS-Core はJS/TSモノレポ構成を自動検出し、サブパッケージの依存関係をスキャンします。
+ClaudeOS-Core は JS/TS モノレポ構成を自動検出し、サブパッケージの依存関係をスキャンします。
 
-**サポートされるモノレポマーカー**（自動検出）：
+**サポートされているモノレポマーカー**（自動検出）：
 - `turbo.json`（Turborepo）
 - `pnpm-workspace.yaml`（pnpm workspaces）
 - `lerna.json`（Lerna）
 - `package.json#workspaces`（npm/yarn workspaces）
 
-**モノレポルートから実行してください** — ClaudeOS-Core は `apps/*/package.json` と `packages/*/package.json` を読み取り、サブパッケージ全体のフレームワーク/ORM/DB依存関係を検出します：
+**モノレポのルートから実行してください** — ClaudeOS-Core は `apps/*/package.json` と `packages/*/package.json` を読み取って、サブパッケージ全体の framework/ORM/DB 依存関係を発見します：
 
 ```bash
 cd my-monorepo
 npx claudeos-core init
 ```
 
-**検出される内容：**
-- `apps/web/package.json` の依存関係（例：`next`、`react`）→ フロントエンドスタック
-- `apps/api/package.json` の依存関係（例：`express`、`prisma`）→ バックエンドスタック
-- `packages/db/package.json` の依存関係（例：`drizzle-orm`）→ ORM/DB
-- `pnpm-workspace.yaml` のカスタムワークスペースパス（例：`services/*`）
+**検出されるもの：**
+- `apps/web/package.json` からの依存関係（例：`next`、`react`）→ frontend スタック
+- `apps/api/package.json` からの依存関係（例：`express`、`prisma`）→ backend スタック
+- `packages/db/package.json` からの依存関係（例：`drizzle-orm`）→ ORM/DB
+- `pnpm-workspace.yaml` からのカスタムワークスペースパス（例：`services/*`）
 
-**ドメインスキャンもモノレポレイアウトに対応：**
-- `apps/api/src/modules/*/` と `apps/api/src/*/` でバックエンドドメインを検出
-- `apps/web/app/*/`、`apps/web/src/app/*/`、`apps/web/pages/*/` でフロントエンドドメインを検出
-- `packages/*/src/*/` で共有パッケージドメインを検出
+**ドメインスキャンもモノレポレイアウトをカバーします：**
+- backend ドメイン向け `apps/api/src/modules/*/` と `apps/api/src/*/`
+- frontend ドメイン向け `apps/web/app/*/`、`apps/web/src/app/*/`、`apps/web/pages/*/`
+- 共有パッケージドメイン向け `packages/*/src/*/`
 
 ```
 my-monorepo/                    ← ここで実行：npx claudeos-core init
@@ -638,37 +820,60 @@ my-monorepo/                    ← ここで実行：npx claudeos-core init
 └── package.json                ← { "workspaces": ["apps/*", "packages/*"] }
 ```
 
-> **注意：** Kotlin/Javaモノレポの場合、マルチモジュール検出は `settings.gradle.kts` を使用します（上記の[Kotlin マルチモジュールドメイン検出](#kotlin-マルチモジュールドメイン検出)を参照）。JSモノレポマーカーは不要です。
+> **注意：** Kotlin/Java モノレポでは、マルチモジュール検出は `settings.gradle.kts` を使用します（上記の [Kotlin マルチモジュールドメイン検出](#kotlin-マルチモジュールドメイン検出) を参照）。JS モノレポマーカーは不要です。
 
 ## トラブルシューティング
 
-**"claude: command not found"** — Claude Code CLI がインストールされていないか、PATH に含まれていません。[Claude Code ドキュメント](https://code.claude.com/docs/en/overview)を参照してください。
+**"claude: command not found"** — Claude Code CLI がインストールされていないか、PATH にありません。[Claude Code ドキュメント](https://code.claude.com/docs/en/overview)を参照してください。
+
+**"npm install failed"** — Node.js バージョンが低すぎる可能性があります。v18+ が必要です。
+
+**"0 domains detected"** — プロジェクト構造が非標準かもしれません。スタック別の検出パターンは上記を参照してください。
+
+**Kotlin プロジェクトで "0 domains detected"** — プロジェクトのルートに `build.gradle.kts`（または kotlin plugin を含む `build.gradle`）があり、ソースファイルが `**/src/main/kotlin/` 配下にあることを確認してください。マルチモジュールプロジェクトでは、`settings.gradle.kts` に `include()` ステートメントが含まれていることを確認してください。単一モジュールの Kotlin プロジェクト（`settings.gradle` なし）もサポートされています — ドメインは `src/main/kotlin/` 配下のパッケージ/クラス構造から抽出されます。
+
+**"Language detected as java instead of kotlin"** — ClaudeOS-Core は最初にルートの `build.gradle(.kts)` をチェックし、次にサブモジュールビルドファイルをチェックします。ルートビルドファイルが `kotlin` なしで `java` plugin を使用していても、サブモジュールが Kotlin を使用する場合、ツールはフォールバックとして最大 5 つのサブモジュールビルドファイルをチェックします。それでも検出されない場合、少なくとも 1 つの `build.gradle.kts` に `kotlin("jvm")` または `org.jetbrains.kotlin` が含まれていることを確認してください。
+
+**"CQRS not detected"** — アーキテクチャ検出はモジュール名に `command` と `query` キーワードが含まれていることに依存します。モジュールが異なる命名（例：`write-server`、`read-server`）を使用している場合、CQRS アーキテクチャは自動検出されません。plan-installer 実行後、生成されたプロンプトを手動で調整できます。
 
-**"npm install failed"** — Node.js のバージョンが低い可能性があります。v18+ が必要です。
+**"Pass 3 produced 0 rule files under .claude/rules/"（v2.0.0）** — Guard 2 が発動しました：Claude は `staging-override.md` ディレクティブを無視して `.claude/` に直接書き込もうとしましたが、そこは Claude Code の sensitive-path ポリシーが書き込みをブロックする場所です。`npx claudeos-core init --force` で再実行してください。エラーが続く場合、`claudeos-core/generated/pass3-prompt.md` を調べて `staging-override.md` ブロックが最上部にあることを確認してください。
 
-**"0 domains detected"** — プロジェクト構造が非標準の可能性があります。[韓国語ドキュメント](./README.ko.md#트러블슈팅)であなたのスタックの検出パターンを確認してください。
+**"Pass 3 finished but N rule file(s) could not be moved from staging"（v2.0.0）** — Guard 1 が発動しました：ステージング移動が一時的なファイルロック（通常 Windows のアンチウィルスまたはファイルウォッチャ）にヒットしました。マーカーは書き込まれないので、次の `init` 実行は Pass 3 を自動的にリトライします。`npx claudeos-core init` を再実行するだけです。
 
-**Kotlin プロジェクトで「0 ドメイン検出」** — プロジェクトルートに `build.gradle.kts`（または kotlin プラグインのある `build.gradle`）が存在し、ソースファイルが `**/src/main/kotlin/` 配下にあることを確認してください。マルチモジュールプロジェクトの場合、`settings.gradle.kts` に `include()` 文が含まれている必要があります。単一モジュールの Kotlin プロジェクト（`settings.gradle` なし）もサポートされます — `src/main/kotlin/` 配下のパッケージ/クラス構造からドメインを抽出します。
+**"Pass 3 produced CLAUDE.md and rules but N/9 guide files are missing or empty"（v2.0.0）** — Guard 3 (H2) が発動しました：Claude は CLAUDE.md + rules を書き込んだ後、`claudeos-core/guide/` セクション（9 ファイル期待）の完了前（または開始前）に応答途中で切り詰められました。BOM のみまたは空白のみのファイルでも発動します（見出しは書かれたが本文が切り詰められた）。このガードがなければ完了マーカーが書き込まれ、その後の実行で `guide/` は永続的に空のままになります。マーカーはここでは書き込まれないので、次の `init` 実行は同じ Pass 2 結果から Pass 3 をリトライします。繰り返し発生する場合、`npx claudeos-core init --force` を使用して最初から再生成してください。
 
-**「言語が kotlin ではなく java として検出される」** — ClaudeOS-Core はまずルートの `build.gradle(.kts)` を確認し、次にサブモジュールのビルドファイルを確認します。少なくとも1つの `build.gradle.kts` に `kotlin("jvm")` または `org.jetbrains.kotlin` が含まれていることを確認してください。
+**"Pass 3 finished but the following required output(s) are missing or empty"（v2.0.0）** — Guard 3 (H1) が発動しました：Claude は `claudeos-core/guide/` の後、しかし `claudeos-core/standard/`、`claudeos-core/skills/`、または `claudeos-core/plan/` の前（または途中）で切り詰められました。要件：(a) `standard/00.core/01.project-overview.md` が存在し空でない（すべてのスタックの Pass 3 プロンプトが書き込むセンチネル）、(b) `skills/` に空でない `.md` が 1 つ以上、(c) `plan/` に空でない `.md` が 1 つ以上。`database/` と `mcp-guide/` は意図的に除外されています（一部のスタックは正当にゼロファイルを生成します）。Guard 3 (H2) と同じ復旧パス：`init` を再実行、または持続する場合は `--force`。
 
-**「CQRS が検出されない」** — アーキテクチャ検出はモジュール名に `command` と `query` キーワードが含まれている必要があります。モジュールが異なる命名を使用している場合、plan-installer 実行後に生成されたプロンプトを手動で調整できます。
+**"pass2-merged.json exists but is malformed or incomplete (<5 top-level keys), re-running"（v2.0.0）** — エラーではなく情報ログです。再開時、`init` は `pass2-merged.json` をパースして検証するようになりました（最上位キー 5 個以上必要、`pass-json-validator` の `INSUFFICIENT_KEYS` しきい値をミラー）。以前のクラッシュした実行からのスケルトン `{}` または不正な JSON は自動的に削除され、Pass 2 が再実行されます。手動操作は不要 — パイプラインは自己修復します。繰り返し発生する場合、`claudeos-core/generated/pass2-prompt.md` を検査して `--force` でリトライしてください。
+
+**"Static fallback failed while translating to lang='ko'"（v2.0.0）** — `--lang` が非英語の場合、Pass 4 / 静的フォールバック / gap-fill はすべて `claude` CLI で翻訳する必要があります。翻訳が失敗した場合（CLI が未認証、ネットワークタイムアウト、または strict validation が出力を拒否：<40% 長さ、壊れたコードフェンス、失われた frontmatter など）、実行は静かに英語を書き込むのではなく中止されます。修正：`claude` が認証されていることを確認するか、`--lang en` で再実行して翻訳をスキップ。
+
+**"pass4-memory.json exists but memory/ is empty"（v2.0.0）** — 以前の実行がマーカーを書き込みましたが、ユーザー（またはクリーンアップスクリプト）が `claudeos-core/memory/` を削除しました。CLI はこの古いマーカーを自動検出し、次の `init` で Pass 4 を再実行します。手動操作は不要です。
+
+**"pass4-memory.json exists but is malformed (missing passNum/memoryFiles) — re-running Pass 4"（v2.0.0）** — エラーではなく情報ログです。Pass 4 マーカーコンテンツは検証されるようになりました（`passNum === 4` + 空でない `memoryFiles` 配列、存在だけでなく）。`{"error":"timeout"}` のようなマーカー本文として出力した Claude の部分的失敗は、以前は永続的に成功として受理されましたが、現在はマーカーが削除され、Pass 4 が自動的に再実行されます。
+
+**"Could not delete stale pass3-complete.json / pass4-memory.json" InitError（v2.0.0）** — `init` は古いマーカーを検出し（Pass 3：CLAUDE.md が外部で削除された；Pass 4：memory/ が空またはマーカー本文が不正）、それを削除しようとしましたが、`unlinkSync` 呼び出しが失敗しました — 通常 Windows のアンチウィルスまたはファイルウォッチャ（エディタ、IDE インデクサ）がファイルハンドルを保持しているためです。以前はこれが静かに無視され、パイプラインがパスをスキップして古いマーカーを再利用していました。現在は明確に失敗します。修正：ファイルを開いている可能性のあるエディタ/AV スキャナを閉じて、`npx claudeos-core init` を再実行してください。
+
+**"CLAUDEOS_SKIP_TRANSLATION=1 is set but --lang='ko' requires translation" InitError（v2.0.0）** — シェルでテスト専用の環境変数 `CLAUDEOS_SKIP_TRANSLATION=1` が設定されており（おそらく CI/テスト設定の残り物）、かつ非英語 `--lang` を選択しました。この環境変数は、Pass 4 の静的フォールバックと gap-fill が非英語出力のために依存する翻訳パスをショートサーキットします。`init` は言語選択時に競合を検出し、即座に中止します（Pass 4 の途中で紛らわしいネストされたエラーでクラッシュするのではなく）。修正：実行前に `unset CLAUDEOS_SKIP_TRANSLATION` するか、`npx claudeos-core init --lang en` を使用してください。
 
 ---
 
-## コントリビューション
+## 貢献
+
+貢献は歓迎します！最も必要とされている領域：
 
-コントリビューションを歓迎します！最も支援が必要な領域：
+- **新しいスタックテンプレート** — Ruby/Rails、Go (Gin/Fiber/Echo)、PHP (Laravel/Symfony)、Rust (Axum/Actix)、Svelte/SvelteKit、Remix
+- **IDE 統合** — VS Code 拡張機能、IntelliJ プラグイン
+- **CI/CD テンプレート** — GitLab CI、CircleCI、Jenkins の例（GitHub Actions はすでに付属 — `.github/workflows/test.yml` 参照）
+- **テストカバレッジ** — テストスイートの拡張（現在 24 のテストファイルで 489 テスト、スキャナ、スタック検出、ドメイングループ化、プランパーシング、プロンプト生成、CLI セレクタ、モノレポ検出、Vite SPA 検出、検証ツール、L4 メモリスキャフォールド、Pass 2 再開検証、Pass 3 Guards 1/2/3（H1 センチネル + H2 BOM-aware 空ファイル + strict stale-marker unlink）、Pass 4 マーカーコンテンツ検証 + stale-marker unlink strictness、翻訳 env-skip ガード + early fail-fast + CI ワークフロー、staged-rules 移動、言語対応翻訳フォールバック、AI Work Rules テンプレート構造をカバー）
 
-- **新しいスタックテンプレート** — Ruby/Rails、Go/Gin、PHP/Laravel、Rust/Axum
-- **Monorepo の深いサポート** — 独立したサブプロジェクトルート、ワークスペース検出
-- **テストカバレッジ** — テストスイート拡大中（現在 269 テスト、全スキャナー、スタック検出、ドメイングルーピング、プラン解析、プロンプト生成、CLIセレクター、モノレポ検出、検証ツール、Vite SPA 検出をカバー）
+領域の完全なリスト、コードスタイル、コミット規約、新しいスタックテンプレートを追加するためのステップバイステップガイドについては、[`CONTRIBUTING.md`](./CONTRIBUTING.md) を参照してください。
 
 ---
 
 ## 作者
 
-**claudeos-core** が作成 — [GitHub](https://github.com/claudeos-core) · [Email](mailto:claudeoscore@gmail.com)
+**claudeos-core** によって作成 — [GitHub](https://github.com/claudeos-core) · [Email](mailto:claudeoscore@gmail.com)
 
 ## ライセンス