claudeos-core 2.0.2 → 2.1.0

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
Files changed (42) hide show
  1. package/CHANGELOG.md +178 -0
  2. package/README.de.md +994 -880
  3. package/README.es.md +993 -880
  4. package/README.fr.md +993 -880
  5. package/README.hi.md +993 -880
  6. package/README.ja.md +993 -880
  7. package/README.ko.md +159 -47
  8. package/README.md +159 -46
  9. package/README.ru.md +993 -880
  10. package/README.vi.md +161 -48
  11. package/README.zh-CN.md +992 -880
  12. package/bin/cli.js +7 -2
  13. package/bin/commands/init.js +733 -143
  14. package/bin/commands/memory.js +17 -5
  15. package/bootstrap.sh +81 -81
  16. package/lib/expected-outputs.js +6 -7
  17. package/lib/memory-scaffold.js +84 -46
  18. package/lib/plan-parser.js +12 -0
  19. package/manifest-generator/index.js +16 -18
  20. package/package.json +1 -1
  21. package/pass-prompts/templates/angular/pass3.md +2 -10
  22. package/pass-prompts/templates/common/pass3-phase1.md +131 -0
  23. package/pass-prompts/templates/common/pass3a-facts.md +143 -0
  24. package/pass-prompts/templates/common/pass3b-core-header.md +58 -0
  25. package/pass-prompts/templates/common/pass3c-skills-guide-header.md +53 -0
  26. package/pass-prompts/templates/common/pass3d-plan-aux-header.md +57 -0
  27. package/pass-prompts/templates/common/pass4.md +4 -19
  28. package/pass-prompts/templates/java-spring/pass3.md +5 -15
  29. package/pass-prompts/templates/kotlin-spring/pass3.md +5 -15
  30. package/pass-prompts/templates/node-express/pass3.md +5 -14
  31. package/pass-prompts/templates/node-fastify/pass3.md +2 -10
  32. package/pass-prompts/templates/node-nestjs/pass3.md +5 -13
  33. package/pass-prompts/templates/node-nextjs/pass3.md +5 -14
  34. package/pass-prompts/templates/node-vite/pass3.md +95 -103
  35. package/pass-prompts/templates/python-django/pass3.md +5 -14
  36. package/pass-prompts/templates/python-fastapi/pass3.md +5 -14
  37. package/pass-prompts/templates/python-flask/pass3.md +95 -103
  38. package/pass-prompts/templates/vue-nuxt/pass3.md +2 -10
  39. package/plan-installer/pass3-context-builder.js +258 -0
  40. package/plan-installer/prompt-generator.js +9 -1
  41. package/plan-validator/index.js +23 -8
  42. package/sync-checker/index.js +44 -0
package/README.ja.md CHANGED
@@ -1,880 +1,993 @@
1
- # ClaudeOS-Core
2
-
3
- **ソースコードを先に読み、決定論的分析でスタックとパターンを確定してから、プロジェクトに正確に合った Claude Code ルールを生成する唯一のツール。**
4
-
5
- ```bash
6
- npx claudeos-core init
7
- ```
8
-
9
- ClaudeOS-Core はコードベースを読み取り、見つけたすべてのパターンを抽出して、_あなたの_ プロジェクトに合わせた Standards、Rules、Skills、Guides の完全なセットを生成します。その後、Claude Code に「注文の CRUD を作成して」と伝えると、既存のパターンに完全に一致するコードが生成されます。
10
-
11
- [🇺🇸 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)
12
-
13
- ---
14
-
15
- ## なぜ ClaudeOS-Core なのか?
16
-
17
- 他のすべての Claude Code ツールはこう動作します:
18
-
19
- > **人間がプロジェクトを説明LLM がドキュメントを生成**
20
-
21
- ClaudeOS-Core はこう動作します:
22
-
23
- > **コードがソースを分析 コードがカスタムプロンプトを構築 LLM がドキュメントを生成 コードが出力を検証**
24
-
25
- これは小さな違いではありません。なぜ重要なのか説明します:
26
-
27
- ### 核心的な問題:LLM は推測する。コードは推測しない。
28
-
29
- Claude に「このプロジェクトを分析して」と頼むと、スタック、ORM、ドメイン構造を**推測**します。
30
- `build.gradle` で `spring-boot` を見ても、MyBatis を使っていること(JPA ではない)を見逃すかもしれません。
31
- `user/` ディレクトリを検出しても、プロジェクトが layer-first パッケージング(Pattern A)を使っていて domain-first(Pattern B)ではないことに気付かないかもしれません。
32
-
33
- **ClaudeOS-Core は推測しません。** Claude がプロジェクトを見る前に、Node.js コードがすでに以下を実行済みです:
34
-
35
- - `build.gradle` / `package.json` / `pyproject.toml` をパースしてスタック、ORM、DB、パッケージマネージャを**確定**
36
- - ディレクトリ構造をスキャンしてファイル数付きのドメインリストを**確定**
37
- - プロジェクト構造を Java 5 パターン、Kotlin CQRS/BFF、Next.js App Router/FSD のいずれかに**分類**
38
- - Claude のコンテキストウィンドウに収まる最適サイズのグループにドメインを**分割**
39
- - 確定された事実がすべて注入されたスタック固有のプロンプトを**組み立て**
40
-
41
- Claude がプロンプトを受け取る時点で、推測の余地はありません。スタック確定。ドメイン確定。構造パターン確定。Claude の仕事は、これらの**確定された事実**に合ったドキュメントを生成することだけです。
42
-
43
- ### 結果
44
-
45
- 他のツールは「一般的に良い」ドキュメントを生成します。
46
- ClaudeOS-Core は、プロジェクトが `ApiResponse.ok()`(`ResponseEntity.success()` ではない)を使っていること、MyBatis XML マッパーが `src/main/resources/mybatis/mappers/` にあること、パッケージ構造が `com.company.module.{domain}.controller` であることを知っているドキュメントを生成します — 実際のコードを読んだからです。
47
-
48
- ### Before & After
49
-
50
- **ClaudeOS-Core なし** — Claude Code に注文 CRUD の作成を依頼すると:
51
- ```
52
- JPA スタイルの repository を使用(プロジェクトは MyBatis)
53
- ResponseEntity.success() を生成(あなたのラッパーは ApiResponse.ok())
54
- ❌ order/controller/ にファイルを配置(プロジェクトは controller/order/ 構造)
55
- 英語コメントを生成(チームは日本語コメント)
56
- → 生成ファイルごとに 20 分の修正
57
- ```
58
-
59
- **ClaudeOS-Core あり** — `.claude/rules/` に確定されたパターンがすでに存在:
60
- ```
61
- ✅ MyBatis マッパー + XML を生成(build.gradle から検出)
62
- ApiResponse.ok() を使用(実際のソースから抽出)
63
- ✅ controller/order/ にファイルを配置(構造スキャンで Pattern A 確定)
64
- 日本語コメント(--lang ja 適用)
65
- → 生成コードがプロジェクト規約と即座に一致
66
- ```
67
-
68
- この差は積み重なります。1 10 タスク × 20 分節約 = **1 日 3 時間以上**。
69
-
70
- ---
71
-
72
- ## 対応スタック
73
-
74
- | スタック | 検出方法 | 分析深度 |
75
- |---|---|---|
76
- | **Java / Spring Boot** | `build.gradle`、`pom.xml`、5 パッケージパターン | 10 大分類、59 小項目 |
77
- | **Kotlin / Spring Boot** | `build.gradle.kts`、kotlin plugin、`settings.gradle.kts`、CQRS/BFF 自動検出 | 12 大分類、95 小項目 |
78
- | **Node.js / Express** | `package.json` | 9 大分類、57 小項目 |
79
- | **Node.js / NestJS** | `package.json` (`@nestjs/core`) | 10 大分類、68 小項目 |
80
- | **Next.js / React** | `package.json`、`next.config.*`、FSD サポート | 9 大分類、55 小項目 |
81
- | **Vue / Nuxt** | `package.json`、`nuxt.config.*`、Composition API | 9 大分類、58 小項目 |
82
- | **Python / Django** | `requirements.txt`、`pyproject.toml` | 10 大分類、55 小項目 |
83
- | **Python / FastAPI** | `requirements.txt`、`pyproject.toml` | 10 大分類、58 小項目 |
84
- | **Node.js / Fastify** | `package.json` | 10 大分類、62 小項目 |
85
- | **Vite / React SPA** | `package.json`、`vite.config.*` | 9 大分類、55 小項目 |
86
- | **Angular** | `package.json`、`angular.json` | 12 大分類、78 小項目 |
87
-
88
- 自動検出対象:言語とバージョン、フレームワークとバージョン(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)。
89
-
90
- **何も指定する必要はありません。すべて自動的に検出されます。**
91
-
92
- ### Java ドメイン検出(5 パターン、フォールバック付き)
93
-
94
- | 優先度 | パターン | 構造 | |
95
- |---|---|---|---|
96
- | A | レイヤー優先 | `controller/{domain}/` | `controller/user/UserController.java` |
97
- | B | ドメイン優先 | `{domain}/controller/` | `user/controller/UserController.java` |
98
- | D | モジュールプレフィックス | `{module}/{domain}/controller/` | `front/member/controller/MemberController.java` |
99
- | E | DDD/ヘキサゴナル | `{domain}/adapter/in/web/` | `user/adapter/in/web/UserController.java` |
100
- | C | フラット | `controller/*.java` | `controller/UserController.java` クラス名から `user` を抽出 |
101
-
102
- Controller を持たない Service 専用ドメインも、`service/`、`dao/`、`aggregator/`、`facade/`、`usecase/`、`orchestrator/`、`mapper/`、`repository/` ディレクトリを通じて検出されます。スキップ:`common`、`config`、`util`、`core`、`front`、`admin`、`v1`、`v2` など。
103
-
104
- ### Kotlin マルチモジュールドメイン検出
105
-
106
- Gradle マルチモジュール構造の Kotlin プロジェクト(例:CQRS モノレポ)向け:
107
-
108
- | ステップ | 動作 | 例 |
109
- |---|---|---|
110
- | 1 | `settings.gradle.kts` から `include()` をスキャン | 14 モジュールを検出 |
111
- | 2 | モジュール名からタイプを検出 | `reservation-command-server` type: `command` |
112
- | 3 | モジュール名からドメインを抽出 | `reservation-command-server` domain: `reservation` |
113
- | 4 | モジュール間で同じドメインをグループ化 | `reservation-command-server` + `common-query-server` → 1 ドメイン |
114
- | 5 | アーキテクチャ検出 | `command` + `query` モジュール存在 CQRS |
115
-
116
- 対応モジュールタイプ:`command`、`query`、`bff`、`integration`、`standalone`、`library`。共有ライブラリ(`shared-lib`、`integration-lib`)は特殊ドメインとして検出されます。
117
-
118
- ### フロントエンドドメイン検出
119
-
120
- - **App Router**:`app/{domain}/page.tsx`(Next.js)
121
- - **Pages Router**:`pages/{domain}/index.tsx`
122
- - **FSD (Feature-Sliced Design)**:`features/*/`、`widgets/*/`、`entities/*/`
123
- - **RSC/Client 分離**:`client.tsx` パターンを検出、Server/Client コンポーネント分離を追跡
124
- - **非標準ネストパス**:`src/*/` 配下のページ、コンポーネント、FSD レイヤーを検出(例:`src/admin/pages/dashboard/`、`src/admin/components/form/`、`src/admin/features/billing/`)
125
- - **プラットフォーム/ティア分割検出 (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 ファイルのノイジーなドメインを回避)。
126
- - **モノレポプラットフォーム分割 (v2.0.0)**:プラットフォームスキャンは `{apps,packages}/*/src/{platform}/{subapp}/`(`src/` を持つ Turborepo/pnpm workspace)および `{apps,packages}/{platform}/{subapp}/`(`src/` ラッパーなしの workspaces)にもマッチします。
127
- - **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`)はフィルタアウトされます。
128
- - **Config フォールバック**:`package.json` になくても、設定ファイルから Next.js/Vite/Nuxt を検出(モノレポ対応)
129
- - **Deep ディレクトリフォールバック**:React/CRA/Vite/Vue/RN プロジェクトで、`**/components/*/`、`**/views/*/`、`**/screens/*/`、`**/containers/*/`、`**/pages/*/`、`**/routes/*/`、`**/modules/*/`、`**/domains/*/` をどの深さでもスキャン
130
- - **共有無視リスト (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__`)を共有し、ビルド成果物とテストフィクスチャがドメインごとのファイル数を膨張させないようにします。
131
-
132
- ### スキャナオーバーライド (v2.0.0)
133
-
134
- プロジェクトルートにオプションの `.claudeos-scan.json` を配置すると、ツールキットを編集せずにスキャナのデフォルトを拡張できます。すべてのフィールドは**加算的** — ユーザーエントリはデフォルトを置き換えず、拡張します:
135
-
136
- ```json
137
- {
138
- "frontendScan": {
139
- "platformKeywords": ["kiosk"],
140
- "skipSubappNames": ["legacy"],
141
- "minSubappFiles": 3
142
- }
143
- }
144
- ```
145
-
146
- | フィールド | デフォルト | 用途 |
147
- |---|---|---|
148
- | `platformKeywords` | 上記の組み込みリスト | プラットフォームスキャン用の追加 `{platform}` キーワード(例:`kiosk`、`vr`、`embedded`) |
149
- | `skipSubappNames` | 構造的ディレクトリのみ | プラットフォームスキャンのドメイン生成から除外する追加 subapp 名 |
150
- | `minSubappFiles` | `2` | subapp がドメインになるために必要な最小ファイル数の上書き |
151
-
152
- ファイル欠損または JSON 不正 → 静かにデフォルトにフォールバック(クラッシュなし)。典型的な用途:組み込みリストが曖昧すぎるとして除外する短縮形(`adm`、`bo`)を opt-in する、またはノイジーなモノレポで `minSubappFiles` を引き上げる。
153
-
154
- ---
155
-
156
- ## クイックスタート
157
-
158
- ### 前提条件
159
-
160
- - **Node.js** v18+
161
- - **Claude Code CLI**(インストール & 認証済み)
162
-
163
- ### インストール
164
-
165
- ```bash
166
- cd /your/project/root
167
-
168
- # オプション A:npx(推奨 — インストール不要)
169
- npx claudeos-core init
170
-
171
- # オプション B:グローバルインストール
172
- npm install -g claudeos-core
173
- claudeos-core init
174
-
175
- # オプション C:プロジェクト devDependency
176
- npm install --save-dev claudeos-core
177
- npx claudeos-core init
178
-
179
- # オプション D:git clone(開発/貢献用)
180
- git clone https://github.com/claudeos-core/claudeos-core.git claudeos-core-tools
181
-
182
- # クロスプラットフォーム(PowerShell、CMD、Bash、Zshどのターミナルでも)
183
- node claudeos-core-tools/bin/cli.js init
184
-
185
- # Linux/macOS(Bash のみ)
186
- bash claudeos-core-tools/bootstrap.sh
187
- ```
188
-
189
- ### 出力言語(10 言語対応)
190
-
191
- `--lang` なしで `init` を実行すると、インタラクティブセレクタが表示されます — 矢印キーまたは数字キーで選択:
192
-
193
- ```
194
- ╔══════════════════════════════════════════════════╗
195
- ║ Select generated document language (required) ║
196
- ╚══════════════════════════════════════════════════╝
197
-
198
- 生成されるファイル(CLAUDE.md、Standards、Rules、
199
- Skills、Guides)は日本語で記述されます。
200
-
201
- 1. en — English
202
- 2. ko — 한국어 (Korean)
203
- 3. zh-CN — 简体中文 (Chinese Simplified)
204
- ❯ 4. ja — 日本語 (Japanese)
205
- 5. es Español (Spanish)
206
- 6. vi — Tiếng Việt (Vietnamese)
207
- 7. hi — हिन्दी (Hindi)
208
- 8. ru — Русский (Russian)
209
- 9. fr — Français (French)
210
- 10. de — Deutsch (German)
211
-
212
- ↑↓ Move 1-0 Jump Enter Select ESC Cancel
213
- ```
214
-
215
- カーソル移動に応じて、説明が選択した言語に切り替わります。セレクタをスキップするには `--lang` を直接指定:
216
-
217
- ```bash
218
- npx claudeos-core init --lang ko # 한국어
219
- npx claudeos-core init --lang ja # 日本語
220
- npx claudeos-core init --lang en # English(デフォルト)
221
- ```
222
-
223
- > **注意:** この設定は生成されるドキュメントファイルの言語のみを変更します。コード分析(Pass 1–2)は常に英語で実行され、生成結果(Pass 3)のみが選択した言語で記述されます。生成ファイル内のコード例は元のプログラミング言語構文のまま維持されます。
224
-
225
- 以上です。5–20 分後(Pass 1×N + Pass 2 + Pass 3 + Pass 4 メモリスキャフォールディング)、すべてのドキュメントが生成され、すぐに使用できます。CLI は各 Pass のパーセンテージ、経過時間、ETA 付きのプログレスバーを表示します。
226
-
227
- ### 手動ステップバイステップインストール
228
-
229
- 各フェーズを完全に制御したい場合や、自動化パイプラインが任意のステップで失敗した場合、各ステージを手動で実行できます。ClaudeOS-Core の内部動作を理解するのにも役立ちます。
230
-
231
- #### Step 1:クローンと依存関係のインストール
232
-
233
- ```bash
234
- cd /your/project/root
235
-
236
- git clone https://github.com/claudeos-core/claudeos-core.git claudeos-core-tools
237
- cd claudeos-core-tools && npm install && cd ..
238
- ```
239
-
240
- #### Step 2:ディレクトリ構造の作成
241
-
242
- ```bash
243
- # Rules(v2.0.0:60.memory を追加)
244
- mkdir -p .claude/rules/{00.core,10.backend,20.frontend,30.security-db,40.infra,50.sync,60.memory}
245
-
246
- # Standards
247
- mkdir -p claudeos-core/standard/{00.core,10.backend-api,20.frontend-ui,30.security-db,40.infra,50.verification,90.optional}
248
-
249
- # Skills
250
- mkdir -p claudeos-core/skills/{00.shared,10.backend-crud/scaffold-crud-feature,20.frontend-page/scaffold-page-feature,50.testing,90.experimental}
251
-
252
- # Guide、Plan、Database、MCP、Generated、Memory(v2.0.0:memory を追加)
253
- mkdir -p claudeos-core/guide/{01.onboarding,02.usage,03.troubleshooting,04.architecture}
254
- mkdir -p claudeos-core/{plan,database,mcp-guide,generated,memory}
255
- ```
256
-
257
- #### Step 3plan-installer の実行(プロジェクト分析)
258
-
259
- プロジェクトをスキャンし、スタックを検出し、ドメインを見つけ、グループに分割し、プロンプトを生成します。
260
-
261
- ```bash
262
- node claudeos-core-tools/plan-installer/index.js
263
- ```
264
-
265
- **出力(`claudeos-core/generated/` 内):**
266
- - `project-analysis.json` 検出されたスタック、ドメイン、フロントエンド情報
267
- - `domain-groups.json` — Pass 1 用ドメイングループ
268
- - `pass1-backend-prompt.md` / `pass1-frontend-prompt.md` — 分析プロンプト
269
- - `pass2-prompt.md` — マージプロンプト
270
- - `pass3-prompt.md` — 生成プロンプト(`staging-override.md` ディレクティブでラップ — Step 6 の注意参照)
271
- - `pass4-prompt.md` L4 メモリスキャフォールディングプロンプト(v2.0.0;`60.memory/` ルール書き込みにも同じ `staging-override.md` を使用)
272
-
273
- これらのファイルを検査して、進める前に検出精度を確認できます。
274
-
275
- #### Step 4:Pass 1 — 深層コード分析(ドメイングループごと)
276
-
277
- 各ドメイングループに対して Pass 1 を実行します。グループ数は `domain-groups.json` で確認してください。
278
-
279
- ```bash
280
- # グループ数を確認
281
- cat claudeos-core/generated/domain-groups.json | node -e "
282
- const g = JSON.parse(require('fs').readFileSync('/dev/stdin','utf-8'));
283
- g.groups.forEach((g,i) => console.log('Group '+(i+1)+': ['+g.domains.join(', ')+'] ('+g.type+', ~'+g.estimatedFiles+' files)'));
284
- "
285
-
286
- # 各グループに対して Pass 1 を実行(ドメインとグループ番号を置き換え)
287
- # 注:v1.6.1+ perl の代わりに Node.js String.replace() を使用 perl
288
- # 不要になり、replacement-function セマンティクスにより、ドメイン名に現れる可能性のある
289
- # $/&/$1 文字からの regex インジェクションを防止。
290
- #
291
- # Group 1:
292
- DOMAIN_LIST="user, order, product" PASS_NUM=1 node -e "
293
- const fs = require('fs');
294
- const tpl = fs.readFileSync('claudeos-core/generated/pass1-backend-prompt.md','utf-8');
295
- const out = tpl
296
- .replace(/\{\{DOMAIN_GROUP\}\}/g, () => process.env.DOMAIN_LIST)
297
- .replace(/\{\{PASS_NUM\}\}/g, () => process.env.PASS_NUM);
298
- process.stdout.write(out);
299
- " | claude -p --dangerously-skip-permissions
300
-
301
- # Group 2(存在する場合):
302
- DOMAIN_LIST="payment, system, delivery" PASS_NUM=2 node -e "
303
- const fs = require('fs');
304
- const tpl = fs.readFileSync('claudeos-core/generated/pass1-backend-prompt.md','utf-8');
305
- const out = tpl
306
- .replace(/\{\{DOMAIN_GROUP\}\}/g, () => process.env.DOMAIN_LIST)
307
- .replace(/\{\{PASS_NUM\}\}/g, () => process.env.PASS_NUM);
308
- process.stdout.write(out);
309
- " | claude -p --dangerously-skip-permissions
310
-
311
- # フロントエンドグループの場合、pass1-backend-prompt.md → pass1-frontend-prompt.md に置き換え
312
- ```
313
-
314
- **確認:** `ls claudeos-core/generated/pass1-*.json` でグループごとに 1 つの JSON が表示されるはずです。
315
-
316
- #### Step 5:Pass 2 — 分析結果のマージ
317
-
318
- ```bash
319
- cat claudeos-core/generated/pass2-prompt.md \
320
- | claude -p --dangerously-skip-permissions
321
- ```
322
-
323
- **確認:** `claudeos-core/generated/pass2-merged.json` が存在し、最上位キーが 9 個以上あるはずです。
324
-
325
- #### Step 6:Pass 3 — すべてのドキュメントを生成
326
-
327
- ```bash
328
- cat claudeos-core/generated/pass3-prompt.md \
329
- | claude -p --dangerously-skip-permissions
330
- ```
331
-
332
- **確認:** プロジェクトルートに `CLAUDE.md` が存在し、`claudeos-core/generated/pass3-complete.json` マーカーが書き込まれているはずです。
333
-
334
- > **注意(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/`(サブパスを保持)。
335
-
336
- #### Step 7:Pass 4 — メモリスキャフォールディング
337
-
338
- ```bash
339
- cat claudeos-core/generated/pass4-prompt.md \
340
- | claude -p --dangerously-skip-permissions
341
- ```
342
-
343
- **確認:** `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`。
344
-
345
- > **注意:** `claude -p` が失敗したり `pass4-prompt.md` が欠損している場合、自動化パイプラインは `lib/memory-scaffold.js` を経由した静的スキャフォールドにフォールバックします(`--lang` が非英語の場合は Claude 主導の翻訳付き)。静的フォールバックは `npx claudeos-core init` 内でのみ実行されます — 手動モードでは Pass 4 が成功する必要があります。
346
-
347
- #### Step 8:検証ツールの実行
348
-
349
- ```bash
350
- # メタデータを生成(他のチェック前に必須)
351
- node claudeos-core-tools/manifest-generator/index.js
352
-
353
- # すべてのチェックを実行
354
- node claudeos-core-tools/health-checker/index.js
355
-
356
- # または個別にチェックを実行:
357
- node claudeos-core-tools/plan-validator/index.js --check # Plan disk 整合性
358
- node claudeos-core-tools/sync-checker/index.js # 未登録/孤児ファイル
359
- node claudeos-core-tools/content-validator/index.js # ファイル品質チェック(memory/ セクション [9/9] を含む)
360
- node claudeos-core-tools/pass-json-validator/index.js # Pass 1–4 JSON + 完了マーカーチェック
361
- ```
362
-
363
- #### Step 9:結果の確認
364
-
365
- ```bash
366
- # 生成されたファイル数をカウント
367
- find .claude claudeos-core -type f | grep -v node_modules | grep -v '/generated/' | wc -l
368
-
369
- # CLAUDE.md を確認
370
- head -30 CLAUDE.md
371
-
372
- # standard ファイルを確認
373
- cat claudeos-core/standard/00.core/01.project-overview.md | head -20
374
-
375
- # rules を確認
376
- ls .claude/rules/*/
377
- ```
378
-
379
- > **ヒント:** 任意のステップが失敗した場合、問題を修正してそのステップだけを再実行できます。Pass 1/2 の結果はキャッシュされます `pass1-N.json` または `pass2-merged.json` がすでに存在する場合、自動化パイプラインはそれらをスキップします。`npx claudeos-core init --force` で以前の結果を削除して最初から実行します。
380
-
381
- ### 使い始める
382
-
383
- ```
384
- # Claude Code で — 自然に依頼するだけ:
385
- "order ドメインの CRUD を作成して"
386
- "ユーザー認証 API を追加して"
387
- "このコードをプロジェクトのパターンに合わせてリファクタリングして"
388
-
389
- # Claude Code が生成された Standards、Rules、Skills を自動的に参照します。
390
- ```
391
-
392
- ---
393
-
394
- ## 仕組み — 4-Pass パイプライン
395
-
396
- ```
397
- npx claudeos-core init
398
-
399
- ├── [1] npm install ← 依存関係(~10 秒)
400
- ├── [2] ディレクトリ構造 ← フォルダ作成(~1 秒)
401
- ├── [3] plan-installer (Node.js) ← プロジェクトスキャン(~5 秒)
402
- │ ├── スタック自動検出(マルチスタック対応)
403
- │ ├── ドメインリスト抽出(タグ付け:backend/frontend)
404
- │ ├── ドメイングループに分割(タイプ別)
405
- │ └── スタック固有のプロンプトを選択(タイプ別)
406
-
407
- ├── [4] Pass 1 × N (claude -p) ← 深層コード分析(~2-8 分)
408
- │ ├── ⚙️ バックエンドグループ → バックエンド固有プロンプト
409
- │ └── 🎨 フロントエンドグループ → フロントエンド固有プロンプト
410
-
411
- ├── [5] Pass 2 × 1 (claude -p) ← 分析マージ(~1 分)
412
- │ └── すべての Pass 1 結果を統合(backend + frontend)
413
-
414
- ├── [6] Pass 3 × 1 (claude -p) ← すべてを生成(~3-5 分)
415
- │ └── 結合プロンプト(backend + frontend ターゲット)
416
-
417
- ├── [7] Pass 4 × 1 (claude -p) ← メモリスキャフォールディング(~30 秒)
418
- │ ├── memory/ をシード(decision-log、failure-patterns、…)
419
- │ ├── 60.memory/ ルールを生成
420
- │ ├── CLAUDE.md に "Memory (L4)" セクションを追加
421
- │ └── 50.memory-master.md プランを構築
422
-
423
- └── [8] 検証 ← health checker を自動実行
424
- ```
425
-
426
- ### なぜ 4 Pass なのか?
427
-
428
- **Pass 1** はソースコードを読む唯一の Pass です。ドメインごとに代表ファイルを選択し、55–95 分析カテゴリ(スタック別)全体でパターンを抽出します。大規模プロジェクトでは、Pass 1 はドメイングループごとに 1 回ずつ複数回実行されます。マルチスタックプロジェクト(例:Java backend + React frontend)では、backend と frontend のドメインは各スタックに合わせた**異なる分析プロンプト**を使用します。
429
-
430
- **Pass 2** はすべての Pass 1 結果を統一された分析にマージします:共通パターン(100% 共有)、多数派パターン(50%+ 共有)、ドメイン固有パターン、重大度別のアンチパターン、横断的関心事(命名、セキュリティ、DB、テスト、ロギング、パフォーマンス)。backend と frontend の結果は一緒にマージされます。
431
-
432
- **Pass 3** は統合された分析を受け取り、ファイルエコシステム全体(CLAUDE.md、rules、standards、skills、guides)を生成します。ソースコードは決して読まず、分析 JSON のみを参照します。マルチスタックモードでは、生成プロンプトは backend と frontend のターゲットを結合するため、両方のスタンダードセットが 1 回のパスで生成されます。
433
-
434
- **Pass 4** は L4 メモリレイヤをスキャフォールディングします:永続的なチーム知識ファイル(decision-log、failure-patterns、compaction ポリシー、auto-rule-update)に加えて、これらのファイルをいつどのように読み書きするかを将来のセッションに指示する `60.memory/` ルール。メモリレイヤこそが、Claude Code がセッションごとに学びを再発見するのではなく、セッション間で蓄積することを可能にします。`--lang` が非英語の場合、フォールバック静的コンテンツは書き込み前に Claude を経由して翻訳されます。
435
-
436
- ---
437
-
438
- ## 生成されるファイル構造
439
-
440
- ```
441
- your-project/
442
-
443
- ├── CLAUDE.md ← Claude Code エントリーポイント
444
-
445
- ├── .claude/
446
- │ └── rules/ Glob トリガールール
447
- │ ├── 00.core/
448
- ├── 10.backend/
449
- ├── 20.frontend/
450
- ├── 30.security-db/
451
- ├── 40.infra/
452
- ├── 50.sync/ ← 同期リマインダールール
453
- │ └── 60.memory/ ← L4 メモリオンデマンドスコープルール(v2.0.0)
454
-
455
- ├── claudeos-core/ メイン出力ディレクトリ
456
- ├── generated/ ← 分析 JSON + 動的プロンプト + Pass マーカー(gitignore 対象)
457
- ├── project-analysis.json ← スタック情報(マルチスタック対応)
458
- ├── domain-groups.json type: backend/frontend 付きグループ
459
- ├── pass1-backend-prompt.md バックエンド分析プロンプト
460
- ├── pass1-frontend-prompt.md ← フロントエンド分析プロンプト(検出時)
461
- ├── pass2-prompt.md ← マージプロンプト
462
- ├── pass3-prompt.md 生成プロンプト(結合)
463
- ├── pass4-prompt.md ← メモリスキャフォールディングプロンプト(v2.0.0)
464
- │ ├── pass3-complete.json Pass 3 完了マーカー(再実行時スキップ)
465
- │ ├── pass4-memory.json ← Pass 4 完了マーカー(再実行時スキップ)
466
- │ │ ├── .i18n-cache-<lang>.json 翻訳キャッシュ(非英語 `--lang`)
467
- │ └── .staged-rules/ `.claude/rules/` 書き込み用一時ステージングディレクトリ(自動移動 + クリーン)
468
- ├── standard/ コーディングスタンダード(15-19 ファイル)
469
- ├── 00.core/ ← 概要、アーキテクチャ、命名
470
- │ ├── 10.backend-api/ API パターン(スタック固有)
471
- │ ├── 20.frontend-ui/ ← フロントエンドパターン(検出時)
472
- │ │ ├── 30.security-db/ セキュリティ、DB スキーマ、ユーティリティ
473
- │ │ ├── 40.infra/ ← 設定、ロギング、CI/CD
474
- │ │ ├── 50.verification/ ← ビルド検証、テスト
475
- │ │ └── 90.optional/ ← オプション規約(スタック固有エクストラ)
476
- │ ├── skills/ ← CRUD スキャフォールディングスキル
477
- │ ├── guide/ ← オンボーディング、FAQ、トラブルシューティング(9 ファイル)
478
- │ ├── plan/ ← マスタープラン(バックアップ/リストア)
479
- │ ├── database/ ← DB スキーマ、マイグレーションガイド
480
- │ ├── mcp-guide/ ← MCP サーバ統合ガイド
481
- │ └── memory/ ← L4:チーム知識(4 ファイル)— コミットする
482
- │ ├── decision-log.md ← 設計決定の「なぜ」
483
- │ ├── failure-patterns.md ← 再発エラー & 修正(自動スコアリング `npx claudeos-core memory score`)
484
- │ ├── compaction.md ← 4 ステージコンパクション戦略(`npx claudeos-core memory compact` で実行)
485
- │ └── auto-rule-update.md ← ルール改善提案(`npx claudeos-core memory propose-rules`)
486
-
487
- └── claudeos-core-tools/ ← このツールキット(変更しない)
488
- ```
489
-
490
- すべての standard ファイルは ✅ 正しい例、❌ 間違った例、ルール要約テーブルを含みます — すべて汎用テンプレートではなく、実際のコードパターンから導出されます。
491
-
492
- ### Gitignore 推奨事項
493
-
494
- **コミットする**(チーム知識 — 共有が目的):
495
- - `CLAUDE.md` — Claude Code エントリーポイント
496
- - `.claude/rules/**` — 自動ロードルール
497
- - `claudeos-core/standard/**`、`skills/**`、`guide/**`、`database/**`、`mcp-guide/**`、`plan/**` — 生成されたドキュメント
498
- - `claudeos-core/memory/**` — 決定履歴、失敗パターン、ルール提案
499
-
500
- **コミットしない**(再生成可能なビルド成果物):
501
-
502
- ```gitignore
503
- # ClaudeOS-Core 生成された分析 & 翻訳キャッシュ
504
- claudeos-core/generated/
505
- ```
506
-
507
- `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` を再実行することで再構築可能です。
508
-
509
- ---
510
-
511
- ## プロジェクトサイズによる自動スケーリング
512
-
513
- | サイズ | ドメイン | Pass 1 実行回数 | 合計 `claude -p` | 推定時間 |
514
- |---|---|---|---|---|
515
- | 小規模 | 1–4 | 1 | 4 (Pass 1 + 2 + 3 + 4) | ~5–6 分 |
516
- | 中規模 | 5–8 | 2 | 5 | ~8–9 分 |
517
- | 大規模 | 9–16 | 3–4 | 6–7 | ~12–13 分 |
518
- | 超大規模 | 17+ | 5+ | 8+ | ~18 分+ |
519
-
520
- Pass 4(メモリスキャフォールディング)は分析 Pass の上に ~30 秒を追加します。マルチスタックプロジェクト(例:Java + React)では、backend と frontend のドメインが合算されます。backend 6 + frontend 4 ドメイン = 合計 10 で「大規模」としてスケーリングされます。
521
-
522
- ---
523
-
524
- ## 検証ツール
525
-
526
- ClaudeOS-Core には生成後に自動的に実行される 5 つの組み込み検証ツールが含まれています:
527
-
528
- ```bash
529
- # すべてのチェックを一度に実行(推奨)
530
- npx claudeos-core health
531
-
532
- # 個別コマンド
533
- npx claudeos-core validate # Plan ↔ disk 比較
534
- npx claudeos-core refresh # Disk → Plan 同期
535
- npx claudeos-core restore # Plan → Disk リストア
536
-
537
- # または node を直接使用(git clone ユーザー)
538
- node claudeos-core-tools/health-checker/index.js
539
- node claudeos-core-tools/manifest-generator/index.js
540
- node claudeos-core-tools/plan-validator/index.js --check
541
- node claudeos-core-tools/sync-checker/index.js
542
- ```
543
-
544
- | ツール | 役割 |
545
- |---|---|
546
- | **manifest-generator** | メタデータ JSON を構築(rule-manifest、sync-map、plan-manifest);`memory/` を含む 7 ディレクトリをインデックス化(要約の `totalMemory`) |
547
- | **plan-validator** | Master Plan `<file>` ブロックを disk と比較 — 3 モード:check、refresh、restore |
548
- | **sync-checker** | 未登録ファイル(disk 上にあるが plan にない)と孤児エントリを検出 — 7 ディレクトリをカバー(v2.0.0 で `memory/` を追加) |
549
- | **content-validator** | 9 セクションの品質チェック — 空ファイル、✅/❌ 例の欠損、必須セクション、加えて L4 メモリスキャフォールドの整合性(decision-log 見出し日付、failure-pattern 必須フィールド、フェンス認識パース) |
550
- | **pass-json-validator** | Pass 1–4 JSON 構造に加えて `pass3-complete.json` と `pass4-memory.json` 完了マーカーを検証 |
551
-
552
- ---
553
-
554
- ## Claude Code がドキュメントを使う仕組み
555
-
556
- ClaudeOS-Core が生成するドキュメントは、Claude Code が実際に読み取るドキュメントです その方法は以下のとおりです:
557
-
558
- ### Claude Code が自動的に読むファイル
559
-
560
- | ファイル | タイミング | 保証 |
561
- |---|---|---|
562
- | `CLAUDE.md` | すべての会話開始時 | 常時 |
563
- | `.claude/rules/00.core/*` | 任意のファイル編集時(`paths: ["**/*"]`) | 常時 |
564
- | `.claude/rules/10.backend/*` | 任意のファイル編集時(`paths: ["**/*"]`) | 常時 |
565
- | `.claude/rules/20.frontend/*` | フロントエンドファイル編集時(component/page/style パスにスコープ) | 条件付き |
566
- | `.claude/rules/30.security-db/*` | 任意のファイル編集時(`paths: ["**/*"]`) | 常時 |
567
- | `.claude/rules/40.infra/*` | config/infra ファイル編集時のみ(スコープ付き paths) | 条件付き |
568
- | `.claude/rules/50.sync/*` | claudeos-core ファイル編集時のみ(スコープ付き paths) | 条件付き |
569
- | `.claude/rules/60.memory/*` | `claudeos-core/memory/*` 編集時(memory パスにスコープ) オンデマンドメモリレイヤを**どのように**読み書きするかを指示 | 条件付き(v2.0.0) |
570
-
571
- ### Claude Code がルール参照経由でオンデマンドで読むもの
572
-
573
- 各ルールファイルは `## Reference` セクションを通じて対応する standard にリンクします。Claude は現在のタスクに関連する standard のみを読みます:
574
-
575
- - `claudeos-core/standard/**` — コーディングパターン、✅/❌ 例、命名規約
576
- - `claudeos-core/database/**` — DB スキーマ(クエリ、マッパー、マイグレーション用)
577
- - `claudeos-core/memory/**`(v2.0.0)— L4 チーム知識レイヤ;**自動ロードされない**(すべての会話でノイジーになりすぎる)。代わりに、`60.memory/*` ルールが Claude にこれらのファイルを*いつ* Read するかを指示:セッション開始時(最近の `decision-log.md` + 重要度の高い `failure-patterns.md` をスキム)、決定を下すか再発エラーに遭遇したときにオンデマンドで追記。
578
-
579
- `00.standard-reference.md` は、対応するルールがない standard を発見するためのすべての standard ファイルのディレクトリとして機能します。
580
-
581
- ### Claude Code が読まないもの(コンテキスト節約)
582
-
583
- これらのフォルダは standard-reference ルールの `DO NOT Read` セクションを通じて明示的に除外されます:
584
-
585
- | フォルダ | 除外理由 |
586
- |---|---|
587
- | `claudeos-core/plan/` | Master Plan バックアップ(~340KB)。`npx claudeos-core refresh` で同期。 |
588
- | `claudeos-core/generated/` | ビルドメタデータ JSON、プロンプト、Pass マーカー、翻訳キャッシュ、`.staged-rules/`。コーディング用ではありません。 |
589
- | `claudeos-core/guide/` | 人間向けオンボーディングガイド。 |
590
- | `claudeos-core/mcp-guide/` | MCP サーバドキュメント。コーディング用ではありません。 |
591
- | `claudeos-core/memory/`(自動ロード) | **自動ロード無効化**設計 — すべての会話でコンテキストが肥大化。代わりに `60.memory/*` ルール経由でオンデマンド読み込み(例:セッション開始時の `failure-patterns.md` スキャン)。常にコミットする。 |
592
-
593
- ---
594
-
595
- ## 日常のワークフロー
596
-
597
- ### インストール後
598
-
599
- ```
600
- # Claude Code を通常通り使用するだけスタンダードを自動的に参照します:
601
- "order ドメインの CRUD を作成して"
602
- "ユーザープロファイル更新 API を追加して"
603
- "このコードをプロジェクトのパターンに合わせてリファクタリングして"
604
- ```
605
-
606
- ### スタンダードを手動編集した後
607
-
608
- ```bash
609
- # standard や rules ファイルを編集した後:
610
- npx claudeos-core refresh
611
-
612
- # すべての整合性を確認
613
- npx claudeos-core health
614
- ```
615
-
616
- ### ドキュメントが壊れたとき
617
-
618
- ```bash
619
- # Master Plan からすべてをリストア
620
- npx claudeos-core restore
621
- ```
622
-
623
- ### メモリレイヤメンテナンス(v2.0.0)
624
-
625
- L4 メモリレイヤ(`claudeos-core/memory/`)はセッション間でチーム知識を蓄積します。3 つの CLI サブコマンドが健全性を維持します:
626
-
627
- ```bash
628
- # Compact:4 ステージコンパクションポリシーを適用(定期的 — 例:月次)
629
- npx claudeos-core memory compact
630
- # Stage 1:古いエントリを要約(>30 日、本文 → 一行)
631
- # Stage 2:重複見出しをマージ(frequency 合算、最新の fix を保持)
632
- # Stage 3:低重要度 + 古いものをドロップ(importance <3 AND lastSeen >60 日)
633
- # Stage 4:ファイルあたり 400 行の上限を強制(最も古い低重要度から先にドロップ)
634
-
635
- # Score:failure-patterns.md エントリを重要度で再ランク付け
636
- npx claudeos-core memory score
637
- # importance = round(frequency × 1.5 + recency × 5)、最大 10
638
- # 複数の新しい失敗パターンを追加後に実行
639
-
640
- # Propose-rules:再発する失敗から候補ルール追加を提示
641
- npx claudeos-core memory propose-rules
642
- # frequency ≥ 3 の failure-patterns.md エントリを読み込み
643
- # confidence を計算(重み付けエビデンスに sigmoid × アンカー倍率)
644
- # memory/auto-rule-update.md に提案を書き込み(自動適用されない)
645
- # Confidence ≥ 0.70 は真剣な検討に値する;受諾 → ルール編集 + 決定を記録
646
- ```
647
-
648
- メモリに書くタイミング(Claude がオンデマンドで行いますが、手動編集も可能):
649
- - **`decision-log.md`** — 競合するパターン間で選択するとき、ライブラリを選ぶとき、チーム規約を定義するとき、または何かを*やらない*と決めるときに新しいエントリを追記。追記のみ;履歴エントリは決して編集しない。
650
- - **`failure-patterns.md`** 再発エラーまたは自明でない根本原因の**2 回目の発生時**に追記。初回エラーはエントリ不要。
651
- - `compaction.md` と `auto-rule-update.md` — 上記の CLI サブコマンドが生成/管理;手動編集しない。
652
-
653
- ### CI/CD 統合
654
-
655
- ```yaml
656
- # GitHub Actions の例
657
- - run: npx claudeos-core validate
658
- # Exit code 1 PR がブロックされる
659
-
660
- # オプション:月次メモリハウスキーピング(別 cron ワークフロー)
661
- - run: npx claudeos-core memory compact
662
- - run: npx claudeos-core memory score
663
- ```
664
-
665
- ---
666
-
667
- ## 何が違うのか?
668
-
669
- ### 他の Claude Code ツールとの比較
670
-
671
- | | ClaudeOS-Core | Everything Claude Code (50K+ ⭐) | Harness | specs-generator | Claude `/init` |
672
- |---|---|---|---|---|---|
673
- | **アプローチ** | コードが先に分析、次に LLM が生成 | 事前構築された設定プリセット | LLM がエージェントチームを設計 | LLM がスペックドキュメントを生成 | LLM が CLAUDE.md を書く |
674
- | **ソースコードを読む** | ✅ 決定論的静的解析 | ❌ | ❌ | ❌ (LLM が読む) | ❌ (LLM が読む) |
675
- | **スタック検出** | コードが確定(ORM、DB、ビルドツール、pkg manager) | N/A(スタック非依存) | LLM が推測 | LLM が推測 | LLM が推測 |
676
- | **ドメイン検出** | コードが確定(Java 5 patterns、Kotlin CQRS、Next.js FSD) | N/A | LLM が推測 | N/A | N/A |
677
- | **同じプロジェクト → 同じ結果** | 決定論的分析 | ✅(静的ファイル) | ❌(LLM は揺れる) | ❌(LLM は揺れる) | ❌(LLM は揺れる) |
678
- | **大規模プロジェクトへの対応** | ドメイングループ分割(4 ドメイン / 40 ファイル / グループ) | N/A | 分割なし | 分割なし | コンテキストウィンドウ制限 |
679
- | **出力** | CLAUDE.md + Rules + Standards + Skills + Guides + Plans(40-50+ ファイル) | Agents + Skills + Commands + Hooks | Agents + Skills | 6 スペックドキュメント | CLAUDE.md(1 ファイル) |
680
- | **出力場所** | `.claude/rules/`(Claude Code が自動ロード) | `.claude/` 各種 | `.claude/agents/` + `.claude/skills/` | `.claude/steering/` + `specs/` | `CLAUDE.md` |
681
- | **生成後検証** | 5 つの自動バリデータ | | | ❌ | ❌ |
682
- | **多言語出力** | ✅ 10 言語 | ❌ | ❌ | ❌ | ❌ |
683
- | **マルチスタック** | ✅ Backend + Frontend 同時 | ❌ スタック非依存 | ❌ | ❌ | 部分的 |
684
- | **永続メモリレイヤ** | ✅ L4 — 決定ログ + 失敗パターン + 自動スコア付きルール提案(v2.0.0) | ❌ | ❌ | ❌ | ❌ |
685
- | **エージェントオーケストレーション** | ❌ | ✅ 28 agents | ✅ 6 patterns | ❌ | ❌ |
686
-
687
- ### 一文にまとめた重要な違い
688
-
689
- **他のツールは Claude に「一般的に良い指示」を与えます。ClaudeOS-Core は Claude に「あなたの実際のコードから抽出された指示」を与えます。**
690
-
691
- だから Claude Code は MyBatis プロジェクトで JPA コードを生成しなくなり、
692
- コードベースが `ok()` を使っているときに `success()` を使わなくなり、
693
- プロジェクトが `controller/user/` を使うときに `user/controller/` ディレクトリを作成しなくなるのです。
694
-
695
- ### 競合ではなく補完
696
-
697
- ClaudeOS-Core は**プロジェクト固有のルールとスタンダード**にフォーカスします。
698
- 他のツールは**エージェントオーケストレーションとワークフロー**にフォーカスします。
699
-
700
- ClaudeOS-Core を使ってプロジェクトのルールを生成し、その上に ECC や Harness を乗せてエージェントチームとワークフロー自動化を構築できます。異なる問題を解決しています。
701
-
702
- ---
703
-
704
- ## FAQ
705
-
706
- **Q:ソースコードを変更しますか?**
707
- いいえ。`CLAUDE.md`、`.claude/rules/`、`claudeos-core/` を作成するだけです。既存のコードは決して変更されません。
708
-
709
- **Q:コストはどのくらいですか?**
710
- `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` にキャッシュされ、その後の実行で再利用されます。
711
-
712
- **Q:生成されたファイルを Git にコミットすべきですか?**
713
- はい、推奨します。チームが同じ Claude Code スタンダードを共有できます。`claudeos-core/generated/` を `.gitignore` に追加することを検討してください(分析 JSON は再生成可能)。
714
-
715
- **Q:混合スタックプロジェクト(例:Java backend + React frontend)はどうですか?**
716
- 完全にサポートされています。ClaudeOS-Core は両方のスタックを自動検出し、ドメインを `backend` または `frontend` としてタグ付けし、それぞれにスタック固有の分析プロンプトを使用します。Pass 2 がすべてをマージし、Pass 3 が 1 回のパスで backend と frontend の両方のスタンダードを生成します。
717
-
718
- **Q:Turborepo / pnpm workspaces / Lerna モノレポで動作しますか?**
719
- はい。ClaudeOS-Core は `turbo.json`、`pnpm-workspace.yaml`、`lerna.json`、または `package.json#workspaces` を検出し、サブパッケージの `package.json` ファイルをスキャンして framework/ORM/DB 依存関係を自動検索します。ドメインスキャンは `apps/*/src/` と `packages/*/src/` パターンをカバーします。モノレポのルートから実行してください。
720
-
721
- **Q:再実行すると何が起きますか?**
722
- 以前の Pass 1/2 結果が存在する場合、インタラクティブプロンプトが選択を提示します:**Continue**(停止した場所から再開)または **Fresh**(すべて削除して最初からやり直し)。`--force` でプロンプトをスキップして常に Fresh で開始します。Pass 3 は常に再実行されます。以前のバージョンは Master Plans から復元可能です。
723
-
724
- **Q:NestJS は独自のテンプレートを使用するか、それとも Express のものを使用しますか?**
725
- NestJS NestJS 固有の分析カテゴリを備えた専用の `node-nestjs` テンプレートを使用します:`@Module`、`@Injectable`、`@Controller` デコレータ、Guards、Pipes、Interceptors、DI コンテナ、CQRS パターン、`Test.createTestingModule`。Express プロジェクトは別の `node-express` テンプレートを使用します。
726
-
727
- **Q:Vue / Nuxt プロジェクトは?**
728
- Vue/Nuxt Composition API、`<script setup>`、defineProps/defineEmits、Pinia ストア、`useFetch`/`useAsyncData`、Nitro サーバルート、`@nuxt/test-utils` をカバーする専用の `vue-nuxt` テンプレートを使用します。Next.js/React プロジェクトは `node-nextjs` テンプレートを使用します。
729
-
730
- **QKotlin をサポートしていますか?**
731
- はい。ClaudeOS-Core `build.gradle.kts` または `build.gradle` の kotlin plugin から Kotlin を自動検出します。Kotlin 固有の分析(data classes、sealed classes、coroutines、拡張関数、MockK など)を備えた専用の `kotlin-spring` テンプレートを使用します。
732
-
733
- **Q:CQRS / BFF アーキテクチャは?**
734
- Kotlin マルチモジュールプロジェクトで完全にサポートされています。ClaudeOS-Core は `settings.gradle.kts` を読み取り、モジュール名からモジュールタイプ(command、query、bff、integration)を検出し、Command/Query モジュール間で同じドメインをグループ化します。生成されるスタンダードには、command controllers と query controllers の別々のルール、BFF/Feign パターン、モジュール間通信規約が含まれます。
735
-
736
- **Q:Gradle マルチモジュールモノレポは?**
737
- ClaudeOS-Core はネスト深度に関係なくすべてのサブモジュール(`**/src/main/kotlin/**/*.kt`)をスキャンします。モジュールタイプは命名規約から推論されます(例:`reservation-command-server` domain: `reservation`、type: `command`)。共有ライブラリ(`shared-lib`、`integration-lib`)も検出されます。
738
-
739
- **Q:L4 メモリレイヤ(v2.0.0)とは?`claudeos-core/memory/` をコミットすべきですか?**
740
- はい `claudeos-core/memory/` を**常にコミット**してください。これは永続的なチーム知識です:`decision-log.md` はアーキテクチャ選択の*理由*を記録(追記のみ)、`failure-patterns.md` は再発エラーを重要度スコアとともに登録して将来のセッションで回避できるようにし、`compaction.md` 4 ステージコンパクションポリシーを定義し、`auto-rule-update.md` は機械生成されたルール改善提案を収集します。ルール(パスごとに自動ロード)とは異なり、メモリファイルは**オンデマンド** — `60.memory/*` ルールがそう指示したときにのみ Claude が読みます(例:セッション開始時の重要度の高い失敗のスキャン)。これによりコンテキストコストを低く保ちながら、長期的な知識を保持します。
741
-
742
- **Q:Pass 4 が失敗したらどうなりますか?**
743
- 自動化パイプライン(`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` にキャッシュされ、その後の実行で再利用されます。
744
-
745
- **Q:`memory compact` / `memory score` / `memory propose-rules` は何をしますか?**
746
- 上記の [メモリレイヤメンテナンス](#メモリレイヤメンテナンスv200) セクションを参照してください。要約:`compact` は 4 ステージポリシー(古いものを要約、重複をマージ、低重要度の古いものをドロップ、400 行上限を強制)を実行;`score` `failure-patterns.md` を重要度(frequency × recency)で再ランク付け;`propose-rules` は再発する失敗から `auto-rule-update.md` への候補ルール追加を提示(自動適用されない 手動で検討して受諾/拒否)。
747
-
748
- **Q:なぜ `--force`(または "fresh" 再開モード)は `.claude/rules/` を削除するのですか?**
749
- 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` では失われます**;必要ならば事前にバックアップしてください。
750
-
751
- **Q:`claudeos-core/generated/.staged-rules/` とは何ですか、そしてなぜ存在するのですか?**
752
- Claude Code の sensitive-path ポリシーは `claude -p` サブプロセスから `.claude/` への直接書き込みを拒否します(`--dangerously-skip-permissions` を使用してもです)。v2.0.0 は Pass 3/4 プロンプトにすべての `.claude/rules/` 書き込みをステージングディレクトリにリダイレクトさせることでこれを回避します;その後 Node.js オーケストレータ(このポリシーの対象外)が各パス後に staged ツリーを `.claude/rules/` に移動します。これはユーザーに透過的です — ディレクトリは自動作成、自動クリーン、自動移動されます。以前の実行が移動途中でクラッシュした場合、次の実行はリトライ前にステージングディレクトリを消去します。
753
-
754
- ---
755
-
756
- ## テンプレート構造
757
-
758
- ```
759
- pass-prompts/templates/
760
- ├── common/ # 共有 header/footer + pass4 + staging-override
761
- ├── java-spring/ # Java / Spring Boot
762
- ├── kotlin-spring/ # Kotlin / Spring Boot (CQRS, BFF, multi-module)
763
- ├── node-express/ # Node.js / Express
764
- ├── node-nestjs/ # Node.js / NestJS (Module, DI, Guard, Pipe, Interceptor)
765
- ├── node-fastify/ # Node.js / Fastify
766
- ├── node-nextjs/ # Next.js / React (App Router, RSC)
767
- ├── node-vite/ # Vite SPA (React, client-side routing, VITE_ env, Vitest)
768
- ├── vue-nuxt/ # Vue / Nuxt (Composition API, Pinia, Nitro)
769
- ├── angular/ # Angular
770
- ├── python-django/ # Python / Django (DRF)
771
- ├── python-fastapi/ # Python / FastAPI
772
- └── python-flask/ # Python / Flask (Blueprint, app factory, Jinja2)
773
- ```
774
-
775
- `plan-installer` がスタックを自動検出し、タイプ固有のプロンプトを組み立てます。NestJS、Vue/Nuxt、Vite SPAFlask はそれぞれフレームワーク固有の分析カテゴリを備えた専用テンプレートを使用します(例: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` テンプレート(メモリスキャフォールディング)を使用します。
776
-
777
- ---
778
-
779
- ## モノレポサポート
780
-
781
- ClaudeOS-Core JS/TS モノレポ構成を自動検出し、サブパッケージの依存関係をスキャンします。
782
-
783
- **サポートされているモノレポマーカー**(自動検出):
784
- - `turbo.json`(Turborepo
785
- - `pnpm-workspace.yaml`(pnpm workspaces)
786
- - `lerna.json`(Lerna)
787
- - `package.json#workspaces`(npm/yarn workspaces)
788
-
789
- **モノレポのルートから実行してください** ClaudeOS-Core は `apps/*/package.json` と `packages/*/package.json` を読み取って、サブパッケージ全体の framework/ORM/DB 依存関係を発見します:
790
-
791
- ```bash
792
- cd my-monorepo
793
- npx claudeos-core init
794
- ```
795
-
796
- **検出されるもの:**
797
- - `apps/web/package.json` からの依存関係(例:`next`、`react`)→ frontend スタック
798
- - `apps/api/package.json` からの依存関係(例:`express`、`prisma`)→ backend スタック
799
- - `packages/db/package.json` からの依存関係(例:`drizzle-orm`)→ ORM/DB
800
- - `pnpm-workspace.yaml` からのカスタムワークスペースパス(例:`services/*`)
801
-
802
- **ドメインスキャンもモノレポレイアウトをカバーします:**
803
- - backend ドメイン向け `apps/api/src/modules/*/` と `apps/api/src/*/`
804
- - frontend ドメイン向け `apps/web/app/*/`、`apps/web/src/app/*/`、`apps/web/pages/*/`
805
- - 共有パッケージドメイン向け `packages/*/src/*/`
806
-
807
- ```
808
- my-monorepo/ ← ここで実行:npx claudeos-core init
809
- ├── turbo.json ← Turborepo として自動検出
810
- ├── apps/
811
- │ ├── web/ ← apps/web/package.json から Next.js を検出
812
- │ │ ├── app/dashboard/ ← フロントエンドドメインを検出
813
- │ │ └── package.json { "dependencies": { "next": "^14" } }
814
- │ └── api/ ← apps/api/package.json から Express を検出
815
- │ ├── src/modules/users/ ← バックエンドドメインを検出
816
- │ └── package.json ← { "dependencies": { "express": "^4" } }
817
- ├── packages/
818
- │ ├── db/ ← packages/db/package.json から Drizzle を検出
819
- │ └── ui/
820
- └── package.json ← { "workspaces": ["apps/*", "packages/*"] }
821
- ```
822
-
823
- > **注意:** Kotlin/Java モノレポでは、マルチモジュール検出は `settings.gradle.kts` を使用します(上記の [Kotlin マルチモジュールドメイン検出](#kotlin-マルチモジュールドメイン検出) を参照)。JS モノレポマーカーは不要です。
824
-
825
- ## トラブルシューティング
826
-
827
- **"claude: command not found"** — Claude Code CLI がインストールされていないか、PATH にありません。[Claude Code ドキュメント](https://code.claude.com/docs/en/overview)を参照してください。
828
-
829
- **"npm install failed"** — Node.js バージョンが低すぎる可能性があります。v18+ が必要です。
830
-
831
- **"0 domains detected"** プロジェクト構造が非標準かもしれません。スタック別の検出パターンは上記を参照してください。
832
-
833
- **Kotlin プロジェクトで "0 domains detected"** — プロジェクトのルートに `build.gradle.kts`(または kotlin plugin を含む `build.gradle`)があり、ソースファイルが `**/src/main/kotlin/` 配下にあることを確認してください。マルチモジュールプロジェクトでは、`settings.gradle.kts` に `include()` ステートメントが含まれていることを確認してください。単一モジュールの Kotlin プロジェクト(`settings.gradle` なし)もサポートされています — ドメインは `src/main/kotlin/` 配下のパッケージ/クラス構造から抽出されます。
834
-
835
- **"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` が含まれていることを確認してください。
836
-
837
- **"CQRS not detected"** アーキテクチャ検出はモジュール名に `command``query` キーワードが含まれていることに依存します。モジュールが異なる命名(例:`write-server`、`read-server`)を使用している場合、CQRS アーキテクチャは自動検出されません。plan-installer 実行後、生成されたプロンプトを手動で調整できます。
838
-
839
- **"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` ブロックが最上部にあることを確認してください。
840
-
841
- **"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` を再実行するだけです。
842
-
843
- **"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` を使用して最初から再生成してください。
844
-
845
- **"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`。
846
-
847
- **"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` でリトライしてください。
848
-
849
- **"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` で再実行して翻訳をスキップ。
850
-
851
- **"pass4-memory.json exists but memory/ is empty"(v2.0.0)** 以前の実行がマーカーを書き込みましたが、ユーザー(またはクリーンアップスクリプト)が `claudeos-core/memory/` を削除しました。CLI はこの古いマーカーを自動検出し、次の `init` で Pass 4 を再実行します。手動操作は不要です。
852
-
853
- **"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 が自動的に再実行されます。
854
-
855
- **"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` を再実行してください。
856
-
857
- **"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` を使用してください。
858
-
859
- ---
860
-
861
- ## 貢献
862
-
863
- 貢献は歓迎します!最も必要とされている領域:
864
-
865
- - **新しいスタックテンプレート** — Ruby/Rails、Go (Gin/Fiber/Echo)、PHP (Laravel/Symfony)、Rust (Axum/Actix)、Svelte/SvelteKit、Remix
866
- - **IDE 統合** — VS Code 拡張機能、IntelliJ プラグイン
867
- - **CI/CD テンプレート** — GitLab CI、CircleCI、Jenkins の例(GitHub Actions はすでに付属 — `.github/workflows/test.yml` 参照)
868
- - **テストカバレッジ** — テストスイートの拡張(現在 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 テンプレート構造をカバー)
869
-
870
- 領域の完全なリスト、コードスタイル、コミット規約、新しいスタックテンプレートを追加するためのステップバイステップガイドについては、[`CONTRIBUTING.md`](./CONTRIBUTING.md) を参照してください。
871
-
872
- ---
873
-
874
- ## 作者
875
-
876
- **claudeos-core** によって作成 [GitHub](https://github.com/claudeos-core) · [Email](mailto:claudeoscore@gmail.com)
877
-
878
- ## ライセンス
879
-
880
- ISC
1
+ # ClaudeOS-Core
2
+
3
+ **ソースコードを先に読み、決定論的分析でスタックとパターンを確定してから、プロジェクトに正確に合った Claude Code ルールを生成する唯一のツール。**
4
+
5
+ ```bash
6
+ npx claudeos-core init
7
+ ```
8
+
9
+ ClaudeOS-Core はコードベースを読み取り、見つけたすべてのパターンを抽出して、_あなたの_ プロジェクトに合わせた Standards、Rules、Skills、Guides の完全なセットを生成します。その後、Claude Code に「注文の CRUD を作成して」と伝えると、既存のパターンに完全に一致するコードが生成されます。
10
+
11
+ [🇺🇸 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)
12
+
13
+ ---
14
+
15
+ ## v2.1.0 の新機能
16
+
17
+ v2.1.0 Pass 3 を再設計し、中規模〜大規模プロジェクトで発生していた `Prompt is too long` 失敗を解消します。従来、単一の Pass 3 呼び出しが `CLAUDE.md`、rules、standards、skills、guides にまたがる数十ファイルを一度にすべて出力する必要があり、出力の累積が 5 ドメインを超えるあたりで確実にコンテキストウィンドウを超えていました。今回の修正はプロンプトの調整ではなく**構造的な変更**です:
18
+
19
+ - **Pass 3 split モード**(常時有効) — Pass 3 は順次実行される `claude -p` 呼び出し(`3a` `3b-core` → `3b-N` → `3c-core` → `3c-N` → `3d-aux`)に分割されます。各ステージは**新しいコンテキストウィンドウ**で開始するため、プロジェクトの規模にかかわらず出力累積によるオーバーフローは構造的に発生しません。
20
+ - **ステージ間のファクトシート** — ステージ `3a` が Pass 2 の分析を一度だけ読み、5〜10 KB の `pass3a-facts.md` に蒸留します。以降のすべてのステージは 100〜500 KB の `pass2-merged.json` を再読み込みせず、このファクトシートを参照するため、新しいコンテキストをまたいでもファイル間の整合性が保たれます。
21
+ - **バッチのサブ分割**(16 ドメイン以上で自動適用) — ステージ 3b/3c はさらに 15 ドメインずつのバッチに分割され、各ステージの出力を ~50 ファイル以下に抑えます。18 ドメインの React 19 + Vite 6 管理画面フロントエンドで、**102 分で 101 ファイル生成・8 ステージ・オーバーフロー 0 件**を実測で確認しました(2026-04-20 の本番実行)。
22
+ - **Master plan の生成を廃止** — `claudeos-core/plan/*-master.md` ファイルは生成されなくなりました。Master plan は Claude Code がランタイムで読み込まない内部バックアップであり、Pass 3d でそれらを集約することがオーバーフローの主要因でした。バックアップ/復元には `git` を使用してください。
23
+ - **Pass 4 gap-fill: `skills/00.shared/MANIFEST.md`** Pass 3c がスキルレジストリを省略した場合(スキルが少ないプロジェクト)、Pass 4 が自動的にスタブを作成し、`.claude/rules/50.sync/03.skills-sync.md` がぶら下がった参照先を指さないようにします。
24
+
25
+ 細かな修正もあります: `memory --help` が memory サブコマンドのヘルプを表示するようになりました(以前はトップレベルが表示されていました);`memory score` が `importance` 行を重複して残さなくなりました;`memory compact` のサマリーマーカーが正しい Markdown のリスト項目になりました。詳細: [CHANGELOG.md](./CHANGELOG.md)。
26
+
27
+ ---
28
+
29
+ ## なぜ ClaudeOS-Core なのか?
30
+
31
+ 他のすべての Claude Code ツールはこう動作します:
32
+
33
+ > **人間がプロジェクトを説明 LLM がドキュメントを生成**
34
+
35
+ ClaudeOS-Core はこう動作します:
36
+
37
+ > **コードがソースを分析 コードがカスタムプロンプトを構築 LLM がドキュメントを生成 コードが出力を検証**
38
+
39
+ これは小さな違いではありません。なぜ重要なのか説明します:
40
+
41
+ ### 核心的な問題:LLM は推測する。コードは推測しない。
42
+
43
+ Claude に「このプロジェクトを分析して」と頼むと、スタック、ORM、ドメイン構造を**推測**します。
44
+ `build.gradle` で `spring-boot` を見ても、MyBatis を使っていること(JPA ではない)を見逃すかもしれません。
45
+ `user/` ディレクトリを検出しても、プロジェクトが layer-first パッケージング(Pattern A)を使っていて domain-first(Pattern B)ではないことに気付かないかもしれません。
46
+
47
+ **ClaudeOS-Core は推測しません。** Claude がプロジェクトを見る前に、Node.js コードがすでに以下を実行済みです:
48
+
49
+ - `build.gradle` / `package.json` / `pyproject.toml` をパースしてスタック、ORM、DB、パッケージマネージャを**確定**
50
+ - ディレクトリ構造をスキャンしてファイル数付きのドメインリストを**確定**
51
+ - プロジェクト構造を Java 5 パターン、Kotlin CQRS/BFF、Next.js App Router/FSD のいずれかに**分類**
52
+ - Claude のコンテキストウィンドウに収まる最適サイズのグループにドメインを**分割**
53
+ - 確定された事実がすべて注入されたスタック固有のプロンプトを**組み立て**
54
+
55
+ Claude がプロンプトを受け取る時点で、推測の余地はありません。スタック確定。ドメイン確定。構造パターン確定。Claude の仕事は、これらの**確定された事実**に合ったドキュメントを生成することだけです。
56
+
57
+ ### 結果
58
+
59
+ 他のツールは「一般的に良い」ドキュメントを生成します。
60
+ ClaudeOS-Core は、プロジェクトが `ApiResponse.ok()`(`ResponseEntity.success()` ではない)を使っていること、MyBatis XML マッパーが `src/main/resources/mybatis/mappers/` にあること、パッケージ構造が `com.company.module.{domain}.controller` であることを知っているドキュメントを生成します — 実際のコードを読んだからです。
61
+
62
+ ### Before & After
63
+
64
+ **ClaudeOS-Core なし** Claude Code に注文 CRUD の作成を依頼すると:
65
+ ```
66
+ ❌ JPA スタイルの repository を使用(プロジェクトは MyBatis)
67
+ ❌ ResponseEntity.success() を生成(あなたのラッパーは ApiResponse.ok())
68
+ order/controller/ にファイルを配置(プロジェクトは controller/order/ 構造)
69
+ ❌ 英語コメントを生成(チームは日本語コメント)
70
+ → 生成ファイルごとに 20 分の修正
71
+ ```
72
+
73
+ **ClaudeOS-Core あり** — `.claude/rules/` に確定されたパターンがすでに存在:
74
+ ```
75
+ ✅ MyBatis マッパー + XML を生成(build.gradle から検出)
76
+ ApiResponse.ok() を使用(実際のソースから抽出)
77
+ controller/order/ にファイルを配置(構造スキャンで Pattern A 確定)
78
+ 日本語コメント(--lang ja 適用)
79
+ 生成コードがプロジェクト規約と即座に一致
80
+ ```
81
+
82
+ この差は積み重なります。1 10 タスク × 20 分節約 = **1 3 時間以上**。
83
+
84
+ ---
85
+
86
+ ## 対応スタック
87
+
88
+ | スタック | 検出方法 | 分析深度 |
89
+ |---|---|---|
90
+ | **Java / Spring Boot** | `build.gradle`、`pom.xml`、5 パッケージパターン | 10 大分類、59 小項目 |
91
+ | **Kotlin / Spring Boot** | `build.gradle.kts`、kotlin plugin、`settings.gradle.kts`、CQRS/BFF 自動検出 | 12 大分類、95 小項目 |
92
+ | **Node.js / Express** | `package.json` | 9 大分類、57 小項目 |
93
+ | **Node.js / NestJS** | `package.json` (`@nestjs/core`) | 10 大分類、68 小項目 |
94
+ | **Next.js / React** | `package.json`、`next.config.*`、FSD サポート | 9 大分類、55 小項目 |
95
+ | **Vue / Nuxt** | `package.json`、`nuxt.config.*`、Composition API | 9 大分類、58 小項目 |
96
+ | **Python / Django** | `requirements.txt`、`pyproject.toml` | 10 大分類、55 小項目 |
97
+ | **Python / FastAPI** | `requirements.txt`、`pyproject.toml` | 10 大分類、58 小項目 |
98
+ | **Node.js / Fastify** | `package.json` | 10 大分類、62 小項目 |
99
+ | **Vite / React SPA** | `package.json`、`vite.config.*` | 9 大分類、55 小項目 |
100
+ | **Angular** | `package.json`、`angular.json` | 12 大分類、78 小項目 |
101
+
102
+ 自動検出対象:言語とバージョン、フレームワークとバージョン(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)。
103
+
104
+ **何も指定する必要はありません。すべて自動的に検出されます。**
105
+
106
+ ### Java ドメイン検出(5 パターン、フォールバック付き)
107
+
108
+ | 優先度 | パターン | 構造 | 例 |
109
+ |---|---|---|---|
110
+ | A | レイヤー優先 | `controller/{domain}/` | `controller/user/UserController.java` |
111
+ | B | ドメイン優先 | `{domain}/controller/` | `user/controller/UserController.java` |
112
+ | D | モジュールプレフィックス | `{module}/{domain}/controller/` | `front/member/controller/MemberController.java` |
113
+ | E | DDD/ヘキサゴナル | `{domain}/adapter/in/web/` | `user/adapter/in/web/UserController.java` |
114
+ | C | フラット | `controller/*.java` | `controller/UserController.java` → クラス名から `user` を抽出 |
115
+
116
+ Controller を持たない Service 専用ドメインも、`service/`、`dao/`、`aggregator/`、`facade/`、`usecase/`、`orchestrator/`、`mapper/`、`repository/` ディレクトリを通じて検出されます。スキップ:`common`、`config`、`util`、`core`、`front`、`admin`、`v1`、`v2` など。
117
+
118
+ ### Kotlin マルチモジュールドメイン検出
119
+
120
+ Gradle マルチモジュール構造の Kotlin プロジェクト(例:CQRS モノレポ)向け:
121
+
122
+ | ステップ | 動作 | 例 |
123
+ |---|---|---|
124
+ | 1 | `settings.gradle.kts` から `include()` をスキャン | 14 モジュールを検出 |
125
+ | 2 | モジュール名からタイプを検出 | `reservation-command-server` type: `command` |
126
+ | 3 | モジュール名からドメインを抽出 | `reservation-command-server` domain: `reservation` |
127
+ | 4 | モジュール間で同じドメインをグループ化 | `reservation-command-server` + `common-query-server` 1 ドメイン |
128
+ | 5 | アーキテクチャ検出 | `command` + `query` モジュール存在 → CQRS |
129
+
130
+ 対応モジュールタイプ:`command`、`query`、`bff`、`integration`、`standalone`、`library`。共有ライブラリ(`shared-lib`、`integration-lib`)は特殊ドメインとして検出されます。
131
+
132
+ ### フロントエンドドメイン検出
133
+
134
+ - **App Router**:`app/{domain}/page.tsx`(Next.js)
135
+ - **Pages Router**:`pages/{domain}/index.tsx`
136
+ - **FSD (Feature-Sliced Design)**:`features/*/`、`widgets/*/`、`entities/*/`
137
+ - **RSC/Client 分離**:`client.tsx` パターンを検出、Server/Client コンポーネント分離を追跡
138
+ - **非標準ネストパス**:`src/*/` 配下のページ、コンポーネント、FSD レイヤーを検出(例:`src/admin/pages/dashboard/`、`src/admin/components/form/`、`src/admin/features/billing/`)
139
+ - **プラットフォーム/ティア分割検出 (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 ファイルのノイジーなドメインを回避)。
140
+ - **モノレポプラットフォーム分割 (v2.0.0)**:プラットフォームスキャンは `{apps,packages}/*/src/{platform}/{subapp}/`(`src/` を持つ Turborepo/pnpm workspace)および `{apps,packages}/{platform}/{subapp}/`(`src/` ラッパーなしの workspaces)にもマッチします。
141
+ - **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`)はフィルタアウトされます。
142
+ - **Config フォールバック**:`package.json` になくても、設定ファイルから Next.js/Vite/Nuxt を検出(モノレポ対応)
143
+ - **Deep ディレクトリフォールバック**:React/CRA/Vite/Vue/RN プロジェクトで、`**/components/*/`、`**/views/*/`、`**/screens/*/`、`**/containers/*/`、`**/pages/*/`、`**/routes/*/`、`**/modules/*/`、`**/domains/*/` をどの深さでもスキャン
144
+ - **共有無視リスト (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__`)を共有し、ビルド成果物とテストフィクスチャがドメインごとのファイル数を膨張させないようにします。
145
+
146
+ ### スキャナオーバーライド (v2.0.0)
147
+
148
+ プロジェクトルートにオプションの `.claudeos-scan.json` を配置すると、ツールキットを編集せずにスキャナのデフォルトを拡張できます。すべてのフィールドは**加算的** ユーザーエントリはデフォルトを置き換えず、拡張します:
149
+
150
+ ```json
151
+ {
152
+ "frontendScan": {
153
+ "platformKeywords": ["kiosk"],
154
+ "skipSubappNames": ["legacy"],
155
+ "minSubappFiles": 3
156
+ }
157
+ }
158
+ ```
159
+
160
+ | フィールド | デフォルト | 用途 |
161
+ |---|---|---|
162
+ | `platformKeywords` | 上記の組み込みリスト | プラットフォームスキャン用の追加 `{platform}` キーワード(例:`kiosk`、`vr`、`embedded`) |
163
+ | `skipSubappNames` | 構造的ディレクトリのみ | プラットフォームスキャンのドメイン生成から除外する追加 subapp 名 |
164
+ | `minSubappFiles` | `2` | subapp がドメインになるために必要な最小ファイル数の上書き |
165
+
166
+ ファイル欠損または JSON 不正 → 静かにデフォルトにフォールバック(クラッシュなし)。典型的な用途:組み込みリストが曖昧すぎるとして除外する短縮形(`adm`、`bo`)を opt-in する、またはノイジーなモノレポで `minSubappFiles` を引き上げる。
167
+
168
+ ---
169
+
170
+ ## クイックスタート
171
+
172
+ ### 前提条件
173
+
174
+ - **Node.js** v18+
175
+ - **Claude Code CLI**(インストール & 認証済み)
176
+
177
+ ### インストール
178
+
179
+ ```bash
180
+ cd /your/project/root
181
+
182
+ # オプション A:npx(推奨 インストール不要)
183
+ npx claudeos-core init
184
+
185
+ # オプション B:グローバルインストール
186
+ npm install -g claudeos-core
187
+ claudeos-core init
188
+
189
+ # オプション C:プロジェクト devDependency
190
+ npm install --save-dev claudeos-core
191
+ npx claudeos-core init
192
+
193
+ # オプション D:git clone(開発/貢献用)
194
+ git clone https://github.com/claudeos-core/claudeos-core.git claudeos-core-tools
195
+
196
+ # クロスプラットフォーム(PowerShell、CMD、Bash、Zsh — どのターミナルでも)
197
+ node claudeos-core-tools/bin/cli.js init
198
+
199
+ # Linux/macOS(Bash のみ)
200
+ bash claudeos-core-tools/bootstrap.sh
201
+ ```
202
+
203
+ ### 出力言語(10 言語対応)
204
+
205
+ `--lang` なしで `init` を実行すると、インタラクティブセレクタが表示されます 矢印キーまたは数字キーで選択:
206
+
207
+ ```
208
+ ╔══════════════════════════════════════════════════╗
209
+ ║ Select generated document language (required)
210
+ ╚══════════════════════════════════════════════════╝
211
+
212
+ 生成されるファイル(CLAUDE.md、Standards、Rules、
213
+ Skills、Guides)は日本語で記述されます。
214
+
215
+ 1. en — English
216
+ 2. ko — 한국어 (Korean)
217
+ 3. zh-CN — 简体中文 (Chinese Simplified)
218
+ ❯ 4. ja — 日本語 (Japanese)
219
+ 5. es — Español (Spanish)
220
+ 6. vi — Tiếng Việt (Vietnamese)
221
+ 7. hi — हिन्दी (Hindi)
222
+ 8. ru — Русский (Russian)
223
+ 9. fr — Français (French)
224
+ 10. de — Deutsch (German)
225
+
226
+ ↑↓ Move 1-0 Jump Enter Select ESC Cancel
227
+ ```
228
+
229
+ カーソル移動に応じて、説明が選択した言語に切り替わります。セレクタをスキップするには `--lang` を直接指定:
230
+
231
+ ```bash
232
+ npx claudeos-core init --lang ko # 한국어
233
+ npx claudeos-core init --lang ja # 日本語
234
+ npx claudeos-core init --lang en # English(デフォルト)
235
+ ```
236
+
237
+ > **注意:** この設定は生成されるドキュメントファイルの言語のみを変更します。コード分析(Pass 1–2)は常に英語で実行され、生成結果(Pass 3)のみが選択した言語で記述されます。生成ファイル内のコード例は元のプログラミング言語構文のまま維持されます。
238
+
239
+ 以上です。10 分(小規模プロジェクト)から 2 時間(60 ドメイン超のモノレポ)後、すべてのドキュメントが生成され、すぐに使用できます。CLI は各 Pass のパーセンテージ、経過時間、ETA 付きのプログレスバーを表示します。プロジェクトサイズごとの詳細な所要時間は [プロジェクトサイズによる自動スケーリング](#プロジェクトサイズによる自動スケーリング) を参照してください。
240
+
241
+ ### 手動ステップバイステップインストール
242
+
243
+ 各フェーズを完全に制御したい場合や、自動化パイプラインが任意のステップで失敗した場合、各ステージを手動で実行できます。ClaudeOS-Core の内部動作を理解するのにも役立ちます。
244
+
245
+ #### Step 1:クローンと依存関係のインストール
246
+
247
+ ```bash
248
+ cd /your/project/root
249
+
250
+ git clone https://github.com/claudeos-core/claudeos-core.git claudeos-core-tools
251
+ cd claudeos-core-tools && npm install && cd ..
252
+ ```
253
+
254
+ #### Step 2:ディレクトリ構造の作成
255
+
256
+ ```bash
257
+ # Rules(v2.0.060.memory を追加)
258
+ mkdir -p .claude/rules/{00.core,10.backend,20.frontend,30.security-db,40.infra,50.sync,60.memory}
259
+
260
+ # Standards
261
+ mkdir -p claudeos-core/standard/{00.core,10.backend-api,20.frontend-ui,30.security-db,40.infra,50.verification,90.optional}
262
+
263
+ # Skills
264
+ mkdir -p claudeos-core/skills/{00.shared,10.backend-crud/scaffold-crud-feature,20.frontend-page/scaffold-page-feature,50.testing,90.experimental}
265
+
266
+ # Guide、Database、MCP、Generated、Memory(v2.0.0:memory を追加 / v2.1.0:plan を削除)
267
+ mkdir -p claudeos-core/guide/{01.onboarding,02.usage,03.troubleshooting,04.architecture}
268
+ mkdir -p claudeos-core/{database,mcp-guide,generated,memory}
269
+ ```
270
+
271
+ > **v2.1.0 注意:** `claudeos-core/plan/` ディレクトリはもう作成されません。Master plan は Claude Code がランタイムで一度も読まない内部バックアップであり、それらを集約することが `Prompt is too long` 失敗の引き金になっていたため、生成は廃止されました。バックアップ/復元には `git` を使用してください。
272
+
273
+ #### Step 3:plan-installer の実行(プロジェクト分析)
274
+
275
+ プロジェクトをスキャンし、スタックを検出し、ドメインを見つけ、グループに分割し、プロンプトを生成します。
276
+
277
+ ```bash
278
+ node claudeos-core-tools/plan-installer/index.js
279
+ ```
280
+
281
+ **出力(`claudeos-core/generated/` 内):**
282
+ - `project-analysis.json` 検出されたスタック、ドメイン、フロントエンド情報
283
+ - `domain-groups.json` Pass 1 用ドメイングループ
284
+ - `pass1-backend-prompt.md` / `pass1-frontend-prompt.md` — 分析プロンプト
285
+ - `pass2-prompt.md` — マージプロンプト
286
+ - `pass3-prompt.md` Phase 1 "Read Once, Extract Facts" ブロック(Rule A–E)が先頭に追加された Pass 3 プロンプトテンプレート。自動化パイプラインはランタイムで Pass 3 を複数ステージに分割し、このテンプレートが各ステージに供給されます。
287
+ - `pass3-context.json` Pass 2 後に生成されるスリムなプロジェクト要約(< 5 KB)。Pass 3 プロンプトは完全な `pass2-merged.json` よりこちらを優先して参照します(v2.1.0)
288
+ - `pass4-prompt.md` — L4 メモリスキャフォールディングプロンプト(v2.0.0;`60.memory/` ルール書き込みにも同じ `staging-override.md` を使用)
289
+
290
+ これらのファイルを検査して、進める前に検出精度を確認できます。
291
+
292
+ #### Step 4:Pass 1 深層コード分析(ドメイングループごと)
293
+
294
+ 各ドメイングループに対して Pass 1 を実行します。グループ数は `domain-groups.json` で確認してください。
295
+
296
+ ```bash
297
+ # グループ数を確認
298
+ cat claudeos-core/generated/domain-groups.json | node -e "
299
+ const g = JSON.parse(require('fs').readFileSync('/dev/stdin','utf-8'));
300
+ g.groups.forEach((g,i) => console.log('Group '+(i+1)+': ['+g.domains.join(', ')+'] ('+g.type+', ~'+g.estimatedFiles+' files)'));
301
+ "
302
+
303
+ # 各グループに対して Pass 1 を実行(ドメインとグループ番号を置き換え)
304
+ # 注:v1.6.1+ perl の代わりに Node.js の String.replace() を使用 — perl は
305
+ # 不要になり、replacement-function セマンティクスにより、ドメイン名に現れる可能性のある
306
+ # $/&/$1 文字からの regex インジェクションを防止。
307
+ #
308
+ # Group 1:
309
+ DOMAIN_LIST="user, order, product" PASS_NUM=1 node -e "
310
+ const fs = require('fs');
311
+ const tpl = fs.readFileSync('claudeos-core/generated/pass1-backend-prompt.md','utf-8');
312
+ const out = tpl
313
+ .replace(/\{\{DOMAIN_GROUP\}\}/g, () => process.env.DOMAIN_LIST)
314
+ .replace(/\{\{PASS_NUM\}\}/g, () => process.env.PASS_NUM);
315
+ process.stdout.write(out);
316
+ " | claude -p --dangerously-skip-permissions
317
+
318
+ # Group 2(存在する場合):
319
+ DOMAIN_LIST="payment, system, delivery" PASS_NUM=2 node -e "
320
+ const fs = require('fs');
321
+ const tpl = fs.readFileSync('claudeos-core/generated/pass1-backend-prompt.md','utf-8');
322
+ const out = tpl
323
+ .replace(/\{\{DOMAIN_GROUP\}\}/g, () => process.env.DOMAIN_LIST)
324
+ .replace(/\{\{PASS_NUM\}\}/g, () => process.env.PASS_NUM);
325
+ process.stdout.write(out);
326
+ " | claude -p --dangerously-skip-permissions
327
+
328
+ # フロントエンドグループの場合、pass1-backend-prompt.md → pass1-frontend-prompt.md に置き換え
329
+ ```
330
+
331
+ **確認:** `ls claudeos-core/generated/pass1-*.json` でグループごとに 1 つの JSON が表示されるはずです。
332
+
333
+ #### Step 5:Pass 2 — 分析結果のマージ
334
+
335
+ ```bash
336
+ cat claudeos-core/generated/pass2-prompt.md \
337
+ | claude -p --dangerously-skip-permissions
338
+ ```
339
+
340
+ **確認:** `claudeos-core/generated/pass2-merged.json` が存在し、最上位キーが 9 個以上あるはずです。
341
+
342
+ #### Step 6:Pass 3 — すべてのドキュメントを生成(複数ステージに分割)
343
+
344
+ **v2.1.0 注意:** Pass 3 は自動化パイプラインで**常に split モードで実行**されます。各ステージはフレッシュなコンテキストウィンドウを持つ独立した `claude -p` 呼び出しであるため、プロジェクトの規模にかかわらず出力累積によるオーバーフローは構造的に発生しません。`pass3-prompt.md` テンプレートはステージごとに `STAGE:` ディレクティブと共に組み立てられ、どのサブセットのファイルを出力するかを Claude に伝えます。手動モードでは、完全なテンプレートを投入して 1 回の呼び出しで Claude にすべて生成させるのが最もシンプルですが、これは小規模プロジェクト(≤5 ドメイン)でのみ信頼できます。それより大きいプロジェクトでは `npx claudeos-core init` を使用し、split ランナーにステージオーケストレーションを任せてください。
345
+
346
+ **単一呼び出しモード(小規模プロジェクト専用、≤5 ドメイン):**
347
+
348
+ ```bash
349
+ cat claudeos-core/generated/pass3-prompt.md \
350
+ | claude -p --dangerously-skip-permissions
351
+ ```
352
+
353
+ **ステージ別モード(すべての規模で推奨):**
354
+
355
+ 自動化パイプラインは以下のステージを実行します。ステージ一覧:
356
+
357
+ | ステージ | 書き込むもの | 備考 |
358
+ |---|---|---|
359
+ | `3a` | `pass3a-facts.md`(5–10 KB の蒸留されたファクトシート) | `pass2-merged.json` を一度読み込み、以降のステージはこのファイルを参照 |
360
+ | `3b-core` | `CLAUDE.md`、共通 `standard/`、共通 `.claude/rules/` | プロジェクト横断ファイル;ドメイン固有の出力なし |
361
+ | `3b-1..N` | ドメイン固有の `standard/60.domains/*.md` + ドメインルール | ステージあたり ≤15 ドメインのバッチ(16 ドメイン以上で自動分割) |
362
+ | `3c-core` | `guide/`(9 ファイル)、`skills/00.shared/MANIFEST.md`、`skills/*/` オーケストレータ | 共有スキルとユーザー向けガイド全体 |
363
+ | `3c-1..N` | `skills/20.frontend-page/scaffold-page-feature/` 配下のドメインサブスキル | ステージあたり ≤15 ドメインのバッチ |
364
+ | `3d-aux` | `database/`、`mcp-guide/` | 固定サイズ、ドメイン数とは独立 |
365
+
366
+ 1〜15 ドメインのプロジェクトでは 4 ステージ(`3a`、`3b-core`、`3c-core`、`3d-aux` — バッチ分割なし)に展開されます。16〜30 ドメインでは 8 ステージ(`3b` と `3c` がそれぞれ 2 バッチにサブ分割)に展開されます。完全な表は [プロジェクトサイズによる自動スケーリング](#プロジェクトサイズによる自動スケーリング) を参照してください。
367
+
368
+ **確認:** プロジェクトルートに `CLAUDE.md` が存在し、`claudeos-core/generated/pass3-complete.json` マーカーが書き込まれているはずです。split モードではこのマーカーに `mode: "split"` と、完了したすべてのステージを列挙する `groupsCompleted` 配列が含まれます — 部分マーカーのロジックはこれを使い、クラッシュ後に `3a` から再実行する(トークンコストが倍増する)のではなく、正しいステージから再開します。
369
+
370
+ > **ステージング注意:** Claude Code の sensitive-path ポリシーが `.claude/` への直接書き込みをブロックするため、Pass 3 はまず `claudeos-core/generated/.staged-rules/` にルールファイルを書き込みます。自動化パイプラインは各ステージ後に移動を自動的に処理します。ステージを手動で実行する場合、staged ツリーを自分で移動する必要があります:`mv claudeos-core/generated/.staged-rules/* .claude/rules/`(サブパスを保持)。
371
+
372
+ #### Step 7:Pass 4 — メモリスキャフォールディング
373
+
374
+ ```bash
375
+ cat claudeos-core/generated/pass4-prompt.md \
376
+ | claude -p --dangerously-skip-permissions
377
+ ```
378
+
379
+ **確認:** `claudeos-core/memory/` 4 ファイル(`decision-log.md`、`failure-patterns.md`、`compaction.md`、`auto-rule-update.md`)、`.claude/rules/60.memory/` 4 ルールファイルが存在し、`CLAUDE.md` `## Memory (L4)` セクションが追加されているはずです。マーカー:`claudeos-core/generated/pass4-memory.json`。
380
+
381
+ > **v2.1.0 gap-fill:** Pass 4 は `claudeos-core/skills/00.shared/MANIFEST.md` の存在も保証します。Pass 3c がこれを省略した場合(スキルが少ないプロジェクトで、スタックの `pass3.md` テンプレートは `MANIFEST.md` を生成ターゲットに挙げているものの REQUIRED としてマークしていないため起こり得ます)、gap-fill が最小限のスタブを作成し、`.claude/rules/50.sync/03.skills-sync.md` の参照ターゲットが常に有効である状態を保ちます。冪等:ファイルがすでに実体のある内容(>20 文字)を持っている場合はスキップします。
382
+
383
+ > **注意:** `claude -p` が失敗したり `pass4-prompt.md` が欠損している場合、自動化パイプラインは `lib/memory-scaffold.js` を経由した静的スキャフォールドにフォールバックします(`--lang` が非英語の場合は Claude 主導の翻訳付き)。静的フォールバックは `npx claudeos-core init` 内でのみ実行されます — 手動モードでは Pass 4 が成功する必要があります。
384
+
385
+ #### Step 8:検証ツールの実行
386
+
387
+ ```bash
388
+ # メタデータを生成(他のチェック前に必須)
389
+ node claudeos-core-tools/manifest-generator/index.js
390
+
391
+ # すべてのチェックを実行
392
+ node claudeos-core-tools/health-checker/index.js
393
+
394
+ # または個別にチェックを実行:
395
+ node claudeos-core-tools/plan-validator/index.js --check # Plan ↔ disk 整合性
396
+ node claudeos-core-tools/sync-checker/index.js # 未登録/孤児ファイル
397
+ node claudeos-core-tools/content-validator/index.js # ファイル品質チェック(memory/ セクション [9/9] を含む)
398
+ node claudeos-core-tools/pass-json-validator/index.js # Pass 1–4 JSON + 完了マーカーチェック
399
+ ```
400
+
401
+ #### Step 9:結果の確認
402
+
403
+ ```bash
404
+ # 生成されたファイル数をカウント
405
+ find .claude claudeos-core -type f | grep -v node_modules | grep -v '/generated/' | wc -l
406
+
407
+ # CLAUDE.md を確認
408
+ head -30 CLAUDE.md
409
+
410
+ # standard ファイルを確認
411
+ cat claudeos-core/standard/00.core/01.project-overview.md | head -20
412
+
413
+ # rules を確認
414
+ ls .claude/rules/*/
415
+ ```
416
+
417
+ > **ヒント:** 任意のステップが失敗した場合、問題を修正してそのステップだけを再実行できます。Pass 1/2 の結果はキャッシュされます `pass1-N.json` または `pass2-merged.json` がすでに存在する場合、自動化パイプラインはそれらをスキップします。`npx claudeos-core init --force` で以前の結果を削除して最初から実行します。
418
+
419
+ ### 使い始める
420
+
421
+ ```
422
+ # Claude Code で — 自然に依頼するだけ:
423
+ "order ドメインの CRUD を作成して"
424
+ "ユーザー認証 API を追加して"
425
+ "このコードをプロジェクトのパターンに合わせてリファクタリングして"
426
+
427
+ # Claude Code が生成された Standards、Rules、Skills を自動的に参照します。
428
+ ```
429
+
430
+ ---
431
+
432
+ ## 仕組み 4-Pass パイプライン
433
+
434
+ ```
435
+ npx claudeos-core init
436
+
437
+ ├── [1] npm install ← 依存関係(~10 秒)
438
+ ├── [2] ディレクトリ構造 ← フォルダ作成(~1 秒)
439
+ ├── [3] plan-installer (Node.js) ← プロジェクトスキャン(~5 秒)
440
+ │ ├── スタック自動検出(マルチスタック対応)
441
+ │ ├── ドメインリスト抽出(タグ付け:backend/frontend)
442
+ ├── ドメイングループに分割(タイプ別)
443
+ ├── pass3-context.json をビルド(スリム要約、v2.1.0)
444
+ └── スタック固有のプロンプトを選択(タイプ別)
445
+
446
+ ├── [4] Pass 1 × N (claude -p) 深層コード分析(~2-8 分)
447
+ │ ├── ⚙️ バックエンドグループ → バックエンド固有プロンプト
448
+ └── 🎨 フロントエンドグループ → フロントエンド固有プロンプト
449
+
450
+ ├── [5] Pass 2 × 1 (claude -p) ← 分析マージ(~1 分)
451
+ └── すべての Pass 1 結果を pass2-merged.json に統合
452
+
453
+ ├── [6] Pass 3(split モード、v2.1.0) ← すべてを生成
454
+
455
+ ├── 3a × 1 (claude -p) ファクト抽出(~5-10 分)
456
+ │ └── pass2-merged.json を一度読んで pass3a-facts.md
457
+
458
+ ├── 3b-core × 1 (claude -p) CLAUDE.md + 共通 standard/rules
459
+ ├── 3b-1..N × N (claude -p) ドメイン standard/rules(≤15 ドメイン/バッチ)
460
+
461
+ ├── 3c-core × 1 (claude -p) ← Guides + 共有 skills + MANIFEST.md
462
+ ├── 3c-1..N × N (claude -p) ドメインサブスキル(≤15 ドメイン/バッチ)
463
+
464
+ └── 3d-aux × 1 (claude -p) database/ + mcp-guide/ スタブ
465
+
466
+ ├── [7] Pass 4 × 1 (claude -p) メモリスキャフォールディング(~30 秒-5 分)
467
+ ├── memory/ をシード(decision-log、failure-patterns、…)
468
+ ├── 60.memory/ ルールを生成
469
+ ├── CLAUDE.md に "Memory (L4)" セクションを追加
470
+ └── Gap-fill:skills/00.shared/MANIFEST.md の存在を保証(v2.1.0)
471
+
472
+ └── [8] 検証 health checker を自動実行
473
+ ```
474
+
475
+ ### なぜ 4 Pass なのか?
476
+
477
+ **Pass 1** はソースコードを読む唯一の Pass です。ドメインごとに代表ファイルを選択し、55–95 分析カテゴリ(スタック別)全体でパターンを抽出します。大規模プロジェクトでは、Pass 1 はドメイングループごとに 1 回ずつ複数回実行されます。マルチスタックプロジェクト(例:Java backend + React frontend)では、backend と frontend のドメインは各スタックに合わせた**異なる分析プロンプト**を使用します。
478
+
479
+ **Pass 2** はすべての Pass 1 結果を統一された分析にマージします:共通パターン(100% 共有)、多数派パターン(50%+ 共有)、ドメイン固有パターン、重大度別のアンチパターン、横断的関心事(命名、セキュリティ、DB、テスト、ロギング、パフォーマンス)。backend と frontend の結果は一緒にマージされます。
480
+
481
+ **Pass 3**(split モード、v2.1.0)は統合された分析を受け取り、ファイルエコシステム全体(CLAUDE.md、rules、standards、skills、guides)を複数の順次 `claude -p` 呼び出しをまたいで生成します。ポイントは、出力累積によるオーバーフローが入力サイズから予測できない、という事実です:単一呼び出しの Pass 3 は 2 ドメインプロジェクトでは問題なく動作し、~5 ドメインで確実に失敗し、失敗境界は各ファイルの冗長度合いによって変動していました。Split モードはこれを構造的に回避します — 各ステージはフレッシュなコンテキストウィンドウで開始し、限定されたファイルサブセットを書き込みます。ステージをまたいだ整合性(単一呼び出しアプローチの主な利点)は `pass3a-facts.md` によって保持されます。これは 5–10 KB の蒸留されたファクトシートで、以降のすべてのステージが参照します。
482
+
483
+ Pass 3 プロンプトテンプレートには、出力量をさらに抑制する **Phase 1「Read Once, Extract Facts」ブロック**(5 つのルール)も含まれます:
484
+
485
+ - **Rule A** ファクトテーブルを参照する;`pass2-merged.json` を再読み込みしない。
486
+ - **Rule B** — 冪等なファイル書き込み(ターゲットが実体のある内容で存在する場合はスキップ)により、Pass 3 は中断後も安全に再実行できます。
487
+ - **Rule C** — ファクトテーブルを単一の真実の源として、ファイル間の整合性を強制。
488
+ - **Rule D** — 出力の簡潔さ:ファイル書き込みの合間は 1 行(`[WRITE]`/`[SKIP]`)のみ、ファクトテーブルの再掲やファイル内容のエコーをしない。
489
+ - **Rule E** — バッチ冪等チェック:ターゲットごとの `Read` 呼び出しの代わりに、PHASE 2 開始時に `Glob` を 1 回だけ実行。
490
+
491
+ **Pass 4** は L4 メモリレイヤをスキャフォールディングします:永続的なチーム知識ファイル(decision-log、failure-patterns、compaction ポリシー、auto-rule-update)に加えて、これらのファイルをいつどのように読み書きするかを将来のセッションに指示する `60.memory/` ルール。メモリレイヤこそが、Claude Code がセッションごとに学びを再発見するのではなく、セッション間で蓄積することを可能にします。`--lang` が非英語の場合、フォールバック静的コンテンツは書き込み前に Claude を経由して翻訳されます。v2.1.0 では、Pass 3c が省略した場合に備えて `skills/00.shared/MANIFEST.md` の gap-fill が追加されました。
492
+
493
+ ---
494
+
495
+ ## 生成されるファイル構造
496
+
497
+ ```
498
+ your-project/
499
+
500
+ ├── CLAUDE.md ← Claude Code エントリーポイント
501
+
502
+ ├── .claude/
503
+ │ └── rules/ ← Glob トリガールール
504
+ │ ├── 00.core/
505
+ │ ├── 10.backend/
506
+ │ ├── 20.frontend/
507
+ │ ├── 30.security-db/
508
+ │ ├── 40.infra/
509
+ │ ├── 50.sync/ ← 同期リマインダールール
510
+ │ └── 60.memory/ ← L4 メモリオンデマンドスコープルール(v2.0.0)
511
+
512
+ ├── claudeos-core/ ← メイン出力ディレクトリ
513
+ │ ├── generated/ ← 分析 JSON + 動的プロンプト + Pass マーカー(gitignore 対象)
514
+ │ │ ├── project-analysis.json ← スタック情報(マルチスタック対応)
515
+ │ │ ├── domain-groups.json ← type: backend/frontend 付きグループ
516
+ │ │ ├── pass1-backend-prompt.md ← バックエンド分析プロンプト
517
+ │ │ ├── pass1-frontend-prompt.md ← フロントエンド分析プロンプト(検出時)
518
+ │ │ ├── pass2-prompt.md ← マージプロンプト
519
+ │ │ ├── pass2-merged.json ← Pass 2 出力(Pass 3a のみが消費)
520
+ │ │ ├── pass3-context.json ← Pass 3 用のスリム要約(< 5 KB、v2.1.0)
521
+ │ │ ├── pass3-prompt.md ← Pass 3 プロンプトテンプレート(Phase 1 ブロック先頭追加)
522
+ │ │ ├── pass3a-facts.md ← Pass 3a が書き、3b/3c/3d が読むファクトシート(v2.1.0)
523
+ │ │ ├── pass4-prompt.md ← メモリスキャフォールディングプロンプト(v2.0.0)
524
+ │ │ ├── pass3-complete.json ← Pass 3 完了マーカー(split モード:groupsCompleted を含む、v2.1.0)
525
+ │ │ ├── pass4-memory.json ← Pass 4 完了マーカー(再実行時スキップ)
526
+ │ │ ├── rule-manifest.json ← 検証ツール用ファイルインデックス
527
+ │ │ ├── sync-map.json ← Plan ↔ disk マッピング(v2.1.0 では空;sync-checker 互換のため保持)
528
+ │ │ ├── stale-report.json ← 統合検証結果
529
+ │ │ ├── .i18n-cache-<lang>.json ← 翻訳キャッシュ(非英語 `--lang`)
530
+ │ │ └── .staged-rules/ ← `.claude/rules/` 書き込み用一時ステージングディレクトリ(自動移動 + クリーン)
531
+ │ ├── standard/ ← コーディングスタンダード(15-19 ファイル + 60.domains/ 内のドメイン別)
532
+ │ │ ├── 00.core/ ← 概要、アーキテクチャ、命名
533
+ │ │ ├── 10.backend-api/ ← API パターン(スタック固有)
534
+ │ │ ├── 20.frontend-ui/ ← フロントエンドパターン(検出時)
535
+ │ │ ├── 30.security-db/ ← セキュリティ、DB スキーマ、ユーティリティ
536
+ │ │ ├── 40.infra/ ← 設定、ロギング、CI/CD
537
+ │ │ ├── 50.verification/ ← ビルド検証、テスト
538
+ │ │ ├── 60.domains/ ← ドメイン別スタンダード(Pass 3b-N が書き込む、v2.1.0)
539
+ │ │ └── 90.optional/ ← オプション規約(スタック固有エクストラ)
540
+ │ ├── skills/ CRUD/ページスキャフォールディングスキル
541
+ │ │ └── 00.shared/MANIFEST.md ← 登録済みスキルの単一の真実の源
542
+ │ ├── guide/ ← オンボーディング、FAQ、トラブルシューティング(9 ファイル)
543
+ │ ├── database/ ← DB スキーマ、マイグレーションガイド
544
+ │ ├── mcp-guide/ ← MCP サーバ統合ガイド
545
+ │ └── memory/ ← L4:チーム知識(4 ファイル)— コミットする
546
+ │ ├── decision-log.md ← 設計決定の「なぜ」
547
+ │ ├── failure-patterns.md ← 再発エラー & 修正(自動スコアリング `npx claudeos-core memory score`)
548
+ │ ├── compaction.md ← 4 ステージコンパクション戦略(`npx claudeos-core memory compact` で実行)
549
+ │ └── auto-rule-update.md ← ルール改善提案(`npx claudeos-core memory propose-rules`)
550
+
551
+ └── claudeos-core-tools/ ← このツールキット(変更しない)
552
+ ```
553
+
554
+ すべての standard ファイルは ✅ 正しい例、❌ 間違った例、ルール要約テーブルを含みます — すべて汎用テンプレートではなく、実際のコードパターンから導出されます。
555
+
556
+ > **v2.1.0 注意:** `claudeos-core/plan/` はもう生成されません。Master plan は Claude Code がランタイムで消費しない内部バックアップで、それらを Pass 3 で集約することが出力累積オーバーフローの主要因でした。バックアップ/復元には `git` を使用してください。v2.0.x からアップグレードするプロジェクトは、既存の `claudeos-core/plan/` ディレクトリを安全に削除できます。
557
+
558
+ ### Gitignore 推奨事項
559
+
560
+ **コミットする**(チーム知識 共有が目的):
561
+ - `CLAUDE.md` — Claude Code エントリーポイント
562
+ - `.claude/rules/**` 自動ロードルール
563
+ - `claudeos-core/standard/**`、`skills/**`、`guide/**`、`database/**`、`mcp-guide/**`、`plan/**` 生成されたドキュメント
564
+ - `claudeos-core/memory/**` 決定履歴、失敗パターン、ルール提案
565
+
566
+ **コミットしない**(再生成可能なビルド成果物):
567
+
568
+ ```gitignore
569
+ # ClaudeOS-Core生成された分析 & 翻訳キャッシュ
570
+ claudeos-core/generated/
571
+ ```
572
+
573
+ `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` を再実行することで再構築可能です。
574
+
575
+ ---
576
+
577
+ ## プロジェクトサイズによる自動スケーリング
578
+
579
+ Pass 3 split モードはステージ数をドメイン数に応じてスケールさせます。バッチのサブ分割は 16 ドメインから発動し、各ステージの出力を ~50 ファイル以下に抑えます。これは出力累積オーバーフローが始まる前の、`claude -p` にとって経験的に安全な範囲です。
580
+
581
+ | プロジェクトサイズ | ドメイン | Pass 3 ステージ数 | 合計 `claude -p` | 推定時間 |
582
+ |---|---|---|---|---|
583
+ | 小規模 | 1–4 | 4(`3a`、`3b-core`、`3c-core`、`3d-aux`) | 7(Pass 1 + 2 + Pass 3 4 ステージ + Pass 4) | ~10–15 分 |
584
+ | 中規模 | 5–15 | 4 | 8–9 | ~25–45 分 |
585
+ | 大規模 | 16–30 | **8**(3b、3c がそれぞれ 2 バッチに分割) | 11–12 | **~60–105 分** |
586
+ | 超大規模 | 31–45 | 10 | 13–14 | ~100–150 分 |
587
+ | 超超大規模 | 46–60 | 12 | 15–16 | ~150–200 分 |
588
+ | 超超超大規模 | 61+ | 14+ | 17+ | 200 分+ |
589
+
590
+ バッチ分割時のステージ数公式:`1 (3a) + 1 (3b-core) + N (3b-1..N) + 1 (3c-core) + N (3c-1..N) + 1 (3d-aux) = 2N + 4`(`N = ceil(totalDomains / 15)`)。
591
+
592
+ Pass 4(メモリスキャフォールディング)は、Claude 主導の生成または静的フォールバックのいずれが走るかによって、上に ~30 秒〜5 分を追加します。マルチスタックプロジェクト(例:Java + React)では、backend と frontend のドメインが合算されます。backend 6 + frontend 4 ドメイン = 合計 10 で中規模ティアになります。
593
+
594
+ ### 実本番ケース:18 ドメインの管理画面フロントエンド(2026-04-20)
595
+
596
+ 18 ドメイン・6 ドメイングループの React 19 + Vite 6 + TypeScript 管理画面フロントエンドは、エンドツーエンドで **102 分・101 ファイル生成**で完走しました。ステージ別内訳:
597
+
598
+ | ステージ | ファイル | 時間 | Files/min |
599
+ |---|---|---|---|
600
+ | `3a`(ファクト抽出) | 1(`pass3a-facts.md`) | 8m 44s | |
601
+ | `3b-core`(CLAUDE.md + 共通) | 24 | 22m 10s | 1.1 |
602
+ | `3b-1`(15 ドメイン) | 30 | 10m 6s | **3.0** |
603
+ | `3b-2`(3 ドメイン) | 6 | 4m 34s | 1.3 |
604
+ | `3c-core`(guides + 共有) | 11 | 8m 31s | 1.3 |
605
+ | `3c-1`(15 ドメイン) | 8 | 5m 11s | **1.5** |
606
+ | `3c-2`(3 ドメイン) | 3 | 3m 50s | 0.8 |
607
+ | `3d-aux`(database + mcp) | 3 | 2m 52s | 1.0 |
608
+ | Pass 4 | 12 | 5m 36s | 2.1 |
609
+
610
+ バッチ化されたドメインステージではスループットが顕著に高くなります(3b-1:3.0 files/min 対 3b-core:1.1 files/min) — これは、フレッシュなコンテキストのステージが、タイトで反復的なドメインごとのパターンから恩恵を受けるためです。検証はすべてパス:`plan-validator`、`sync-checker`、`content-validator`、`pass-json-validator` — オーバーフロー失敗 0 件、切り詰め 0 件。
611
+
612
+ ---
613
+
614
+ ## 検証ツール
615
+
616
+ ClaudeOS-Core には生成後に自動的に実行される 5 つの組み込み検証ツールが含まれています:
617
+
618
+ ```bash
619
+ # すべてのチェックを一度に実行(推奨)
620
+ npx claudeos-core health
621
+
622
+ # 個別コマンド
623
+ npx claudeos-core validate # Plan ↔ disk 比較
624
+ npx claudeos-core refresh # Disk → Plan 同期
625
+ npx claudeos-core restore # Plan → Disk リストア
626
+
627
+ # または node を直接使用(git clone ユーザー)
628
+ node claudeos-core-tools/health-checker/index.js
629
+ node claudeos-core-tools/manifest-generator/index.js
630
+ node claudeos-core-tools/plan-validator/index.js --check
631
+ node claudeos-core-tools/sync-checker/index.js
632
+ ```
633
+
634
+ | ツール | 役割 |
635
+ |---|---|
636
+ | **manifest-generator** | メタデータ JSON を構築(`rule-manifest.json`、`sync-map.json`、`stale-report.json` を初期化);`memory/` を含む 7 ディレクトリをインデックス化(要約の `totalMemory`)。v2.1.0:master plan が廃止されたため `plan-manifest.json` は生成されなくなりました。 |
637
+ | **plan-validator** | 依然として `claudeos-core/plan/` を持つプロジェクト(レガシーアップグレードケース)向けに、master plan の `<file>` ブロックを disk と照合します。v2.1.0:`plan/` が存在しないか空の場合は `plan-sync-status.json` の出力をスキップします `stale-report.json` はパスする no-op を引き続き記録します。 |
638
+ | **sync-checker** | 未登録ファイル(disk 上にあるが plan にない)と孤児エントリを検出 — 7 ディレクトリをカバー(v2.0.0 で `memory/` を追加)。`sync-map.json` にマッピングがない場合(v2.1.0 のデフォルト状態)でもクリーンに終了します。 |
639
+ | **content-validator** | 9 セクションの品質チェック — 空ファイル、✅/❌ 例の欠損、必須セクション、加えて L4 メモリスキャフォールドの整合性(decision-log 見出し日付、failure-pattern 必須フィールド、フェンス認識パース) |
640
+ | **pass-json-validator** | Pass 1–4 JSON 構造に加えて `pass3-complete.json`(split モード形状、v2.1.0)と `pass4-memory.json` 完了マーカーを検証 |
641
+
642
+ ---
643
+
644
+ ## Claude Code がドキュメントを使う仕組み
645
+
646
+ ClaudeOS-Core が生成するドキュメントは、Claude Code が実際に読み取るドキュメントです — その方法は以下のとおりです:
647
+
648
+ ### Claude Code が自動的に読むファイル
649
+
650
+ | ファイル | タイミング | 保証 |
651
+ |---|---|---|
652
+ | `CLAUDE.md` | すべての会話開始時 | 常時 |
653
+ | `.claude/rules/00.core/*` | 任意のファイル編集時(`paths: ["**/*"]`) | 常時 |
654
+ | `.claude/rules/10.backend/*` | 任意のファイル編集時(`paths: ["**/*"]`) | 常時 |
655
+ | `.claude/rules/20.frontend/*` | フロントエンドファイル編集時(component/page/style パスにスコープ) | 条件付き |
656
+ | `.claude/rules/30.security-db/*` | 任意のファイル編集時(`paths: ["**/*"]`) | 常時 |
657
+ | `.claude/rules/40.infra/*` | config/infra ファイル編集時のみ(スコープ付き paths) | 条件付き |
658
+ | `.claude/rules/50.sync/*` | claudeos-core ファイル編集時のみ(スコープ付き paths) | 条件付き |
659
+ | `.claude/rules/60.memory/*` | `claudeos-core/memory/*` 編集時(memory パスにスコープ) — オンデマンドメモリレイヤを**どのように**読み書きするかを指示 | 条件付き(v2.0.0) |
660
+
661
+ ### Claude Code がルール参照経由でオンデマンドで読むもの
662
+
663
+ 各ルールファイルは `## Reference` セクションを通じて対応する standard にリンクします。Claude は現在のタスクに関連する standard のみを読みます:
664
+
665
+ - `claudeos-core/standard/**` — コーディングパターン、✅/❌ 例、命名規約
666
+ - `claudeos-core/database/**` — DB スキーマ(クエリ、マッパー、マイグレーション用)
667
+ - `claudeos-core/memory/**`(v2.0.0)— L4 チーム知識レイヤ;**自動ロードされない**(すべての会話でノイジーになりすぎる)。代わりに、`60.memory/*` ルールが Claude にこれらのファイルを*いつ* Read するかを指示:セッション開始時(最近の `decision-log.md` + 重要度の高い `failure-patterns.md` をスキム)、決定を下すか再発エラーに遭遇したときにオンデマンドで追記。
668
+
669
+ `00.standard-reference.md` は、対応するルールがない standard を発見するためのすべての standard ファイルのディレクトリとして機能します。
670
+
671
+ ### Claude Code が読まないもの(コンテキスト節約)
672
+
673
+ これらのフォルダは standard-reference ルールの `DO NOT Read` セクションを通じて明示的に除外されます:
674
+
675
+ | フォルダ | 除外理由 |
676
+ |---|---|
677
+ | `claudeos-core/plan/` | レガシープロジェクト(v2.0.x 以前)の master plan バックアップ。v2.1.0 では生成されません。存在しても Claude Code は自動ロードしません オンデマンド読み込みのみ。 |
678
+ | `claudeos-core/generated/` | ビルドメタデータ JSON、プロンプト、Pass マーカー、翻訳キャッシュ、`.staged-rules/`。コーディング用ではありません。 |
679
+ | `claudeos-core/guide/` | 人間向けオンボーディングガイド。 |
680
+ | `claudeos-core/mcp-guide/` | MCP サーバドキュメント。コーディング用ではありません。 |
681
+ | `claudeos-core/memory/`(自動ロード) | **自動ロード無効化**設計 すべての会話でコンテキストが肥大化。代わりに `60.memory/*` ルール経由でオンデマンド読み込み(例:セッション開始時の `failure-patterns.md` スキャン)。常にコミットする。 |
682
+
683
+ ---
684
+
685
+ ## 日常のワークフロー
686
+
687
+ ### インストール後
688
+
689
+ ```
690
+ # Claude Code を通常通り使用するだけ — スタンダードを自動的に参照します:
691
+ "order ドメインの CRUD を作成して"
692
+ "ユーザープロファイル更新 API を追加して"
693
+ "このコードをプロジェクトのパターンに合わせてリファクタリングして"
694
+ ```
695
+
696
+ ### スタンダードを手動編集した後
697
+
698
+ ```bash
699
+ # standard や rules ファイルを編集した後:
700
+ npx claudeos-core refresh
701
+
702
+ # すべての整合性を確認
703
+ npx claudeos-core health
704
+ ```
705
+
706
+ ### ドキュメントが壊れたとき
707
+
708
+ ```bash
709
+ # v2.1.0 推奨:master plan が生成されなくなったため、git を使って復元します。
710
+ # 生成ドキュメントを定期的にコミットしておけば、再生成せずに特定ファイルだけ
711
+ # ロールバックできます:
712
+ git checkout HEAD -- .claude/rules/ claudeos-core/
713
+
714
+ # レガシー(claudeos-core/plan/ が残っている v2.0.x プロジェクト):
715
+ npx claudeos-core restore
716
+ ```
717
+
718
+ ### メモリレイヤメンテナンス(v2.0.0)
719
+
720
+ L4 メモリレイヤ(`claudeos-core/memory/`)はセッション間でチーム知識を蓄積します。3 つの CLI サブコマンドが健全性を維持します:
721
+
722
+ ```bash
723
+ # Compact:4 ステージコンパクションポリシーを適用(定期的 — 例:月次)
724
+ npx claudeos-core memory compact
725
+ # Stage 1:古いエントリを要約(>30 日、本文 一行)
726
+ # Stage 2:重複見出しをマージ(frequency 合算、最新の fix を保持)
727
+ # Stage 3:低重要度 + 古いものをドロップ(importance <3 AND lastSeen >60 日)
728
+ # Stage 4:ファイルあたり 400 行の上限を強制(最も古い低重要度から先にドロップ)
729
+
730
+ # Scorefailure-patterns.md エントリを重要度で再ランク付け
731
+ npx claudeos-core memory score
732
+ # importance = round(frequency × 1.5 + recency × 5)、最大 10
733
+ # 複数の新しい失敗パターンを追加後に実行
734
+
735
+ # Propose-rules:再発する失敗から候補ルール追加を提示
736
+ npx claudeos-core memory propose-rules
737
+ # frequency 3 failure-patterns.md エントリを読み込み
738
+ # confidence を計算(重み付けエビデンスに sigmoid × アンカー倍率)
739
+ # memory/auto-rule-update.md に提案を書き込み(自動適用されない)
740
+ # Confidence 0.70 は真剣な検討に値する;受諾 ルール編集 + 決定を記録
741
+
742
+ # v2.1.0:`memory --help` はサブコマンドのヘルプを表示するようになりました(以前はトップレベルが表示されていました)
743
+ npx claudeos-core memory --help
744
+ ```
745
+
746
+ > **v2.1.0 修正:** `memory score` は初回実行後に `importance` 行を重複して残さなくなりました(以前は自動スコアリング行が上に追加され、元のプレーン行が下に残っていました)。`memory compact` Stage 1 サマリーマーカーは正しい Markdown のリスト項目(`- _Summarized on ..._`)になったため、きれいにレンダリングされ、以降のコンパクションでも正しく再パースされます。
747
+
748
+ メモリに書くタイミング(Claude がオンデマンドで行いますが、手動編集も可能):
749
+ - **`decision-log.md`**競合するパターン間で選択するとき、ライブラリを選ぶとき、チーム規約を定義するとき、または何かを*やらない*と決めるときに新しいエントリを追記。追記のみ;履歴エントリは決して編集しない。
750
+ - **`failure-patterns.md`** — 再発エラーまたは自明でない根本原因の**2 回目の発生時**に追記。初回エラーはエントリ不要。
751
+ - `compaction.md` と `auto-rule-update.md` — 上記の CLI サブコマンドが生成/管理;手動編集しない。
752
+
753
+ ### CI/CD 統合
754
+
755
+ ```yaml
756
+ # GitHub Actions の例
757
+ - run: npx claudeos-core validate
758
+ # Exit code 1 で PR がブロックされる
759
+
760
+ # オプション:月次メモリハウスキーピング(別 cron ワークフロー)
761
+ - run: npx claudeos-core memory compact
762
+ - run: npx claudeos-core memory score
763
+ ```
764
+
765
+ ---
766
+
767
+ ## 何が違うのか?
768
+
769
+ ### 他の Claude Code ツールとの比較
770
+
771
+ | | ClaudeOS-Core | Everything Claude Code (50K+ ⭐) | Harness | specs-generator | Claude `/init` |
772
+ |---|---|---|---|---|---|
773
+ | **アプローチ** | コードが先に分析、次に LLM が生成 | 事前構築された設定プリセット | LLM がエージェントチームを設計 | LLM がスペックドキュメントを生成 | LLM が CLAUDE.md を書く |
774
+ | **ソースコードを読む** | ✅ 決定論的静的解析 | ❌ | ❌ | ❌ (LLM が読む) | ❌ (LLM が読む) |
775
+ | **スタック検出** | コードが確定(ORMDB、ビルドツール、pkg manager) | N/A(スタック非依存) | LLM が推測 | LLM が推測 | LLM が推測 |
776
+ | **ドメイン検出** | コードが確定(Java 5 patterns、Kotlin CQRS、Next.js FSD) | N/A | LLM が推測 | N/A | N/A |
777
+ | **同じプロジェクト → 同じ結果** | ✅ 決定論的分析 | ✅(静的ファイル) | ❌(LLM は揺れる) | ❌(LLM は揺れる) | ❌(LLM は揺れる) |
778
+ | **大規模プロジェクトへの対応** | ドメイングループ分割(4 ドメイン / 40 ファイル / グループ) | N/A | 分割なし | 分割なし | コンテキストウィンドウ制限 |
779
+ | **出力** | CLAUDE.md + Rules + Standards + Skills + Guides + Plans(40-50+ ファイル) | Agents + Skills + Commands + Hooks | Agents + Skills | 6 スペックドキュメント | CLAUDE.md(1 ファイル) |
780
+ | **出力場所** | `.claude/rules/`(Claude Code が自動ロード) | `.claude/` 各種 | `.claude/agents/` + `.claude/skills/` | `.claude/steering/` + `specs/` | `CLAUDE.md` |
781
+ | **生成後検証** | ✅ 5 つの自動バリデータ | ❌ | ❌ | ❌ | ❌ |
782
+ | **多言語出力** | ✅ 10 言語 | ❌ | ❌ | ❌ | ❌ |
783
+ | **マルチスタック** | ✅ Backend + Frontend 同時 | ❌ スタック非依存 | ❌ | ❌ | 部分的 |
784
+ | **永続メモリレイヤ** | ✅ L4 — 決定ログ + 失敗パターン + 自動スコア付きルール提案(v2.0.0 | ❌ | ❌ | ❌ | ❌ |
785
+ | **エージェントオーケストレーション** | ❌ | ✅ 28 agents | ✅ 6 patterns | ❌ | ❌ |
786
+
787
+ ### 一文にまとめた重要な違い
788
+
789
+ **他のツールは Claude に「一般的に良い指示」を与えます。ClaudeOS-Core は Claude に「あなたの実際のコードから抽出された指示」を与えます。**
790
+
791
+ だから Claude Code は MyBatis プロジェクトで JPA コードを生成しなくなり、
792
+ コードベースが `ok()` を使っているときに `success()` を使わなくなり、
793
+ プロジェクトが `controller/user/` を使うときに `user/controller/` ディレクトリを作成しなくなるのです。
794
+
795
+ ### 競合ではなく補完
796
+
797
+ ClaudeOS-Core は**プロジェクト固有のルールとスタンダード**にフォーカスします。
798
+ 他のツールは**エージェントオーケストレーションとワークフロー**にフォーカスします。
799
+
800
+ ClaudeOS-Core を使ってプロジェクトのルールを生成し、その上に ECC や Harness を乗せてエージェントチームとワークフロー自動化を構築できます。異なる問題を解決しています。
801
+
802
+ ---
803
+
804
+ ## FAQ
805
+
806
+ **Q:ソースコードを変更しますか?**
807
+ いいえ。`CLAUDE.md`、`.claude/rules/`、`claudeos-core/` を作成するだけです。既存のコードは決して変更されません。
808
+
809
+ **Q:コストはどのくらいですか?**
810
+ 4 つの Pass をまたいで `claude -p` を複数回呼び出します。v2.1.0 の split モードでは、Pass 3 だけでもプロジェクトサイズに応じて 4〜14+ ステージに展開されます([自動スケーリング](#プロジェクトサイズによる自動スケーリング) を参照)。典型的な小規模プロジェクト(1〜15 ドメイン)で合計 8〜9 回の `claude -p` 呼び出し;18 ドメインのプロジェクトで 11 回;60 ドメインのプロジェクトで 15〜17 回。各ステージはフレッシュなコンテキストウィンドウで実行されます — 呼び出しあたりのトークンコストは、どのステージも全体のファイルツリーを 1 つのコンテキストに保持する必要がないため、単一呼び出しの Pass 3 時代より実際は低くなっています。`--lang` が非英語の場合、静的フォールバックパスは翻訳のために追加の `claude -p` 呼び出しを数回行うことがあります;結果は `claudeos-core/generated/.i18n-cache-<lang>.json` にキャッシュされ、その後の実行で再利用されます。これは通常の Claude Code 使用量の範囲内です。
811
+
812
+ **Q:Pass 3 split モードとは何ですか?なぜ v2.1.0 で追加されたのですか?**
813
+ v2.1.0 より前の Pass 3 は、生成されたファイルツリー全体(`CLAUDE.md`、standards、rules、skills、guides — 通常 30〜60 ファイル)を 1 回のレスポンスで出力しなければならない単一の `claude -p` 呼び出しでした。小規模プロジェクトでは機能しましたが、~5 ドメインで確実に `Prompt is too long` の出力累積失敗にぶつかっていました。失敗は入力サイズから予測できず、生成される各ファイルの冗長度合いに依存し、同じプロジェクトでも断続的に発生しました。Split モードはこの問題を構造的に回避します:Pass 3 は順次ステージ(`3a` → `3b-core` → `3b-N` → `3c-core` → `3c-N` → `3d-aux`)に分割され、それぞれがフレッシュなコンテキストウィンドウを持つ独立した `claude -p` 呼び出しです。ステージをまたいだ整合性は `pass3a-facts.md` — 以降のすべてのステージが `pass2-merged.json` を再読み込みせずに参照する 5〜10 KB の蒸留されたファクトシート によって保持されます。`pass3-complete.json` マーカーは `groupsCompleted` 配列を持ち、`3c-2` 実行中のクラッシュは `3a` からではなく `3c-2` から再開するため、トークンコストの倍増を避けられます。最大 18 ドメイン × 101 ファイル × 102 分で実証済み、オーバーフロー 0 件 — 実本番内訳は [自動スケーリング](#プロジェクトサイズによる自動スケーリング) を参照してください。
814
+
815
+ **Q:生成されたファイルを Git にコミットすべきですか?**
816
+ はい、推奨します。チームが同じ Claude Code スタンダードを共有できます。`claudeos-core/generated/` `.gitignore` に追加することを検討してください(分析 JSON は再生成可能)。
817
+
818
+ **Q:混合スタックプロジェクト(例:Java backend + React frontend)はどうですか?**
819
+ 完全にサポートされています。ClaudeOS-Core は両方のスタックを自動検出し、ドメインを `backend` または `frontend` としてタグ付けし、それぞれにスタック固有の分析プロンプトを使用します。Pass 2 がすべてをマージし、Pass 3 は split ステージ群全体で backend と frontend の両方のスタンダードを生成します — backend ドメインはいくつかの 3b/3c バッチに、frontend ドメインは別のバッチに入り、すべてが同じ `pass3a-facts.md` を参照して整合性を保ちます。
820
+
821
+ **Q:Turborepo / pnpm workspaces / Lerna モノレポで動作しますか?**
822
+ はい。ClaudeOS-Core は `turbo.json`、`pnpm-workspace.yaml`、`lerna.json`、または `package.json#workspaces` を検出し、サブパッケージの `package.json` ファイルをスキャンして framework/ORM/DB 依存関係を自動検索します。ドメインスキャンは `apps/*/src/` と `packages/*/src/` パターンをカバーします。モノレポのルートから実行してください。
823
+
824
+ **Q:再実行すると何が起きますか?**
825
+ 以前の Pass 1/2 結果が存在する場合、インタラクティブプロンプトが選択を提示します:**Continue**(停止した場所から再開)または **Fresh**(すべて削除して最初からやり直し)。`--force` でプロンプトをスキップして常に Fresh で開始します。v2.1.0 の split モードでは、Pass 3 の再開はステージ粒度で動作します — 実行が `3c-2` 中にクラッシュした場合、次の `init` は `3a` から再実行する(トークンコストが倍増する)のではなく `3c-2` から再開します。`pass3-complete.json` マーカーはこのロジックを駆動するため `mode: "split"` に加えて `groupsCompleted` 配列を記録します。
826
+
827
+ **Q:NestJS は独自のテンプレートを使用するか、それとも Express のものを使用しますか?**
828
+ NestJS は NestJS 固有の分析カテゴリを備えた専用の `node-nestjs` テンプレートを使用します:`@Module`、`@Injectable`、`@Controller` デコレータ、Guards、Pipes、Interceptors、DI コンテナ、CQRS パターン、`Test.createTestingModule`。Express プロジェクトは別の `node-express` テンプレートを使用します。
829
+
830
+ **Q:Vue / Nuxt プロジェクトは?**
831
+ Vue/Nuxt Composition API、`<script setup>`、defineProps/defineEmits、Pinia ストア、`useFetch`/`useAsyncData`、Nitro サーバルート、`@nuxt/test-utils` をカバーする専用の `vue-nuxt` テンプレートを使用します。Next.js/React プロジェクトは `node-nextjs` テンプレートを使用します。
832
+
833
+ **Q:Kotlin をサポートしていますか?**
834
+ はい。ClaudeOS-Core は `build.gradle.kts` または `build.gradle` の kotlin plugin から Kotlin を自動検出します。Kotlin 固有の分析(data classes、sealed classes、coroutines、拡張関数、MockK など)を備えた専用の `kotlin-spring` テンプレートを使用します。
835
+
836
+ **Q:CQRS / BFF アーキテクチャは?**
837
+ Kotlin マルチモジュールプロジェクトで完全にサポートされています。ClaudeOS-Core `settings.gradle.kts` を読み取り、モジュール名からモジュールタイプ(command、query、bff、integration)を検出し、Command/Query モジュール間で同じドメインをグループ化します。生成されるスタンダードには、command controllers と query controllers の別々のルール、BFF/Feign パターン、モジュール間通信規約が含まれます。
838
+
839
+ **Q:Gradle マルチモジュールモノレポは?**
840
+ ClaudeOS-Core はネスト深度に関係なくすべてのサブモジュール(`**/src/main/kotlin/**/*.kt`)をスキャンします。モジュールタイプは命名規約から推論されます(例:`reservation-command-server` → domain: `reservation`、type: `command`)。共有ライブラリ(`shared-lib`、`integration-lib`)も検出されます。
841
+
842
+ **Q:L4 メモリレイヤ(v2.0.0)とは?`claudeos-core/memory/` をコミットすべきですか?**
843
+ はい`claudeos-core/memory/` を**常にコミット**してください。これは永続的なチーム知識です:`decision-log.md` はアーキテクチャ選択の*理由*を記録(追記のみ)、`failure-patterns.md` は再発エラーを重要度スコアとともに登録して将来のセッションで回避できるようにし、`compaction.md` 4 ステージコンパクションポリシーを定義し、`auto-rule-update.md` は機械生成されたルール改善提案を収集します。ルール(パスごとに自動ロード)とは異なり、メモリファイルは**オンデマンド** `60.memory/*` ルールがそう指示したときにのみ Claude が読みます(例:セッション開始時の重要度の高い失敗のスキャン)。これによりコンテキストコストを低く保ちながら、長期的な知識を保持します。
844
+
845
+ **Q:Pass 4 が失敗したらどうなりますか?**
846
+ 自動化パイプライン(`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` にキャッシュされ、その後の実行で再利用されます。
847
+
848
+ **Q:`memory compact` / `memory score` / `memory propose-rules` は何をしますか?**
849
+ 上記の [メモリレイヤメンテナンス](#メモリレイヤメンテナンスv200) セクションを参照してください。要約:`compact` 4 ステージポリシー(古いものを要約、重複をマージ、低重要度の古いものをドロップ、400 行上限を強制)を実行;`score` `failure-patterns.md` を重要度(frequency × recency)で再ランク付け;`propose-rules` は再発する失敗から `auto-rule-update.md` への候補ルール追加を提示(自動適用されない 手動で検討して受諾/拒否)。
850
+
851
+ **Q:なぜ `--force`(または "fresh" 再開モード)は `.claude/rules/` を削除するのですか?**
852
+ v2.0.0 で Pass 3 の silent-failure ガードが 3 つ追加されました(Guard 3 は 2 つの不完全出力のバリアントをカバー:`guide/` 向けの H2 と `standard/skills` 向けの H1)。Guard 1(「部分 staged-rules 移動」)と Guard 3(「不完全出力 — guide ファイル欠損/空または standard センチネル欠損 / skills 空」)は既存ルールに依存しませんが、Guard 2(「ゼロルール検出」)は依存します — Claude が `staging-override.md` ディレクティブを無視して `.claude/` に直接書き込もうとしたときに発動します(Claude Code の sensitive-path ポリシーがブロックする場所)。以前の実行からの古いルールが Guard 2 を false-negative にする可能性があるため — `--force`/`fresh` は `.claude/rules/` を消去してクリーンな検出を保証します。**ルールファイルへの手動編集は `--force`/`fresh` では失われます**;必要ならば事前にバックアップしてください。(v2.1.0 注意:Guard 3 H1 は master plan が生成されなくなったため `plan/` をもうチェックしません。)
853
+
854
+ **Q:`claudeos-core/generated/.staged-rules/` とは何ですか、そしてなぜ存在するのですか?**
855
+ Claude Code sensitive-path ポリシーは `claude -p` サブプロセスから `.claude/` への直接書き込みを拒否します(`--dangerously-skip-permissions` を使用してもです)。v2.0.0 Pass 3/4 プロンプトにすべての `.claude/rules/` 書き込みをステージングディレクトリにリダイレクトさせることでこれを回避します;その後 Node.js オーケストレータ(このポリシーの対象外)が各パス後に staged ツリーを `.claude/rules/` に移動します。これはユーザーに透過的ですディレクトリは自動作成、自動クリーン、自動移動されます。以前の実行が移動途中でクラッシュした場合、次の実行はリトライ前にステージングディレクトリを消去します。v2.1.0 split モードでは、ステージランナーは staged rules を終了時だけでなく**各ステージ後**に `.claude/rules/` に移動するため、Pass 3 の途中でクラッシュしても以前に完了したステージのルールはそのまま残ります。
856
+
857
+ **Q:`npx claudeos-core init` の代わりに Pass 3 を手動で実行できますか?**
858
+ 小規模プロジェクト(≤5 ドメイン)ならはい — [Step 6](#step-6pass-3--すべてのドキュメントを生成複数ステージに分割) の単一呼び出し手動手順は引き続き動作します。それより大きいプロジェクトでは `npx claudeos-core init` を使用すべきです。split ランナーこそが、フレッシュなコンテキストでのステージ単位実行をオーケストレーションし、16 ドメイン以上でのバッチサブ分割を処理し、正しい `pass3-complete.json` マーカー形状(`mode: "split"` + `groupsCompleted`)を書き込み、ステージ間の staged rules を移動するからです。このオーケストレーションを手で再現することは可能ですが、手間がかかります。ステージを手動で実行する理由がある場合(例:特定ステージのデバッグ)、適切な `STAGE:` ディレクティブで `pass3-prompt.md` をテンプレート化して直接 `claude -p` に投入できます — ただし、各ステージ後に `.staged-rules/` を移動し、マーカーを自分で更新することを忘れないでください。
859
+
860
+ **Q:私のプロジェクトは v2.0.x からのアップグレードで、既存の `claudeos-core/plan/` ディレクトリがあります。どうすれば良いですか?**
861
+ 特に何もする必要はありません — v2.1.0 のツールは `plan/` が存在しないか空の場合それを無視し、`plan-validator` は後方互換性のために plan/ が入っているレガシープロジェクトを引き続き処理します。master plan バックアップが不要なら `claudeos-core/plan/` を安全に削除できます(いずれにせよ git 履歴の方がバックアップとして優れています)。`plan/` を残す場合、`npx claudeos-core init` を実行してもそれは更新されません — v2.1.0 では新しい内容は master plan に集約されません。検証ツールは両方のケースをクリーンに扱います。
862
+
863
+ ---
864
+
865
+ ## テンプレート構造
866
+
867
+ ```
868
+ pass-prompts/templates/
869
+ ├── common/ # 共有 header/footer + pass4 + staging-override
870
+ ├── java-spring/ # Java / Spring Boot
871
+ ├── kotlin-spring/ # Kotlin / Spring Boot (CQRS, BFF, multi-module)
872
+ ├── node-express/ # Node.js / Express
873
+ ├── node-nestjs/ # Node.js / NestJS (Module, DI, Guard, Pipe, Interceptor)
874
+ ├── node-fastify/ # Node.js / Fastify
875
+ ├── node-nextjs/ # Next.js / React (App Router, RSC)
876
+ ├── node-vite/ # Vite SPA (React, client-side routing, VITE_ env, Vitest)
877
+ ├── vue-nuxt/ # Vue / Nuxt (Composition API, Pinia, Nitro)
878
+ ├── angular/ # Angular
879
+ ├── python-django/ # Python / Django (DRF)
880
+ ├── python-fastapi/ # Python / FastAPI
881
+ └── python-flask/ # Python / Flask (Blueprint, app factory, Jinja2)
882
+ ```
883
+
884
+ `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` は両方のスタックの生成ターゲットを結合します。v2.1.0 では、Pass 3 テンプレートの先頭に `common/pass3-phase1.md`(Rule A–E を含む「Read Once, Extract Facts」ブロック)が追加された後、split モードのステージごとにスライスされます。Pass 4 はスタックに関係なく共有の `common/pass4.md` テンプレート(メモリスキャフォールディング)を使用します。
885
+
886
+ ---
887
+
888
+ ## モノレポサポート
889
+
890
+ ClaudeOS-Core は JS/TS モノレポ構成を自動検出し、サブパッケージの依存関係をスキャンします。
891
+
892
+ **サポートされているモノレポマーカー**(自動検出):
893
+ - `turbo.json`(Turborepo)
894
+ - `pnpm-workspace.yaml`(pnpm workspaces)
895
+ - `lerna.json`(Lerna)
896
+ - `package.json#workspaces`(npm/yarn workspaces)
897
+
898
+ **モノレポのルートから実行してください** — ClaudeOS-Core は `apps/*/package.json` と `packages/*/package.json` を読み取って、サブパッケージ全体の framework/ORM/DB 依存関係を発見します:
899
+
900
+ ```bash
901
+ cd my-monorepo
902
+ npx claudeos-core init
903
+ ```
904
+
905
+ **検出されるもの:**
906
+ - `apps/web/package.json` からの依存関係(例:`next`、`react`)→ frontend スタック
907
+ - `apps/api/package.json` からの依存関係(例:`express`、`prisma`)→ backend スタック
908
+ - `packages/db/package.json` からの依存関係(例:`drizzle-orm`)→ ORM/DB
909
+ - `pnpm-workspace.yaml` からのカスタムワークスペースパス(例:`services/*`)
910
+
911
+ **ドメインスキャンもモノレポレイアウトをカバーします:**
912
+ - backend ドメイン向け `apps/api/src/modules/*/` と `apps/api/src/*/`
913
+ - frontend ドメイン向け `apps/web/app/*/`、`apps/web/src/app/*/`、`apps/web/pages/*/`
914
+ - 共有パッケージドメイン向け `packages/*/src/*/`
915
+
916
+ ```
917
+ my-monorepo/ ← ここで実行:npx claudeos-core init
918
+ ├── turbo.json ← Turborepo として自動検出
919
+ ├── apps/
920
+ │ ├── web/ ← apps/web/package.json から Next.js を検出
921
+ │ │ ├── app/dashboard/ ← フロントエンドドメインを検出
922
+ │ │ └── package.json ← { "dependencies": { "next": "^14" } }
923
+ │ └── api/ ← apps/api/package.json から Express を検出
924
+ │ ├── src/modules/users/ ← バックエンドドメインを検出
925
+ │ └── package.json ← { "dependencies": { "express": "^4" } }
926
+ ├── packages/
927
+ │ ├── db/ ← packages/db/package.json から Drizzle を検出
928
+ │ └── ui/
929
+ └── package.json ← { "workspaces": ["apps/*", "packages/*"] }
930
+ ```
931
+
932
+ > **注意:** Kotlin/Java モノレポでは、マルチモジュール検出は `settings.gradle.kts` を使用します(上記の [Kotlin マルチモジュールドメイン検出](#kotlin-マルチモジュールドメイン検出) を参照)。JS モノレポマーカーは不要です。
933
+
934
+ ## トラブルシューティング
935
+
936
+ **"claude: command not found"** — Claude Code CLI がインストールされていないか、PATH にありません。[Claude Code ドキュメント](https://code.claude.com/docs/en/overview)を参照してください。
937
+
938
+ **"npm install failed"** — Node.js バージョンが低すぎる可能性があります。v18+ が必要です。
939
+
940
+ **"0 domains detected"** — プロジェクト構造が非標準かもしれません。スタック別の検出パターンは上記を参照してください。
941
+
942
+ **Kotlin プロジェクトで "0 domains detected"** — プロジェクトのルートに `build.gradle.kts`(または kotlin plugin を含む `build.gradle`)があり、ソースファイルが `**/src/main/kotlin/` 配下にあることを確認してください。マルチモジュールプロジェクトでは、`settings.gradle.kts` に `include()` ステートメントが含まれていることを確認してください。単一モジュールの Kotlin プロジェクト(`settings.gradle` なし)もサポートされています — ドメインは `src/main/kotlin/` 配下のパッケージ/クラス構造から抽出されます。
943
+
944
+ **"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` が含まれていることを確認してください。
945
+
946
+ **"CQRS not detected"** — アーキテクチャ検出はモジュール名に `command` と `query` キーワードが含まれていることに依存します。モジュールが異なる命名(例:`write-server`、`read-server`)を使用している場合、CQRS アーキテクチャは自動検出されません。plan-installer 実行後、生成されたプロンプトを手動で調整できます。
947
+
948
+ **"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` ブロックが最上部にあることを確認してください。
949
+
950
+ **"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` を再実行するだけです。
951
+
952
+ **"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` を使用して最初から再生成してください。
953
+
954
+ **"Pass 3 finished but the following required output(s) are missing or empty"(v2.0.0、v2.1.0 で更新)** — Guard 3 (H1) が発動しました:Claude は `claudeos-core/guide/` の後、しかし `claudeos-core/standard/` または `claudeos-core/skills/` の前(または途中)で切り詰められました。要件:(a) `standard/00.core/01.project-overview.md` が存在し空でない(すべてのスタックの Pass 3 プロンプトが書き込むセンチネル)、(b) `skills/` に空でない `.md` が 1 つ以上。`database/` と `mcp-guide/` は意図的に除外されています(一部のスタックは正当にゼロファイルを生成します)。`plan/` は v2.1.0 以降チェックされません(master plan が廃止されたため)。Guard 3 (H2) と同じ復旧パス:`init` を再実行、または持続する場合は `--force`。
955
+
956
+ **"Pass 3 split stage crashed partway through (v2.1.0)"** — split ステージのいずれか(例:`3b-1`、`3c-2`)が実行途中で失敗すると、ステージレベルのマーカーは書き込まれませんが、完了したステージは `pass3-complete.json.groupsCompleted` に記録されます。次の `init` 実行はこの配列を読み、完了済みの作業をすべてスキップして、最初の未完了ステージから再開します。手動操作は不要です — `npx claudeos-core init` を再実行するだけです。同じステージで resume が繰り返し失敗する場合、`claudeos-core/generated/pass3-prompt.md` の内容不正を検査し、それから `--force` で完全再起動を試みてください。`pass3-complete.json` の形状(`mode: "split"`、`groupsCompleted: [...]`)は安定しています;マーカー欠損または形状不正の場合、Pass 3 全体が `3a` から再実行されます。
957
+
958
+ **"Pass 3 stale marker (shape mismatch) — treating as incomplete"(v2.1.0)** — pre-v2.1.0 の単一呼び出し実行による `pass3-complete.json` が新しい split モードのルールで解釈されています。形状チェックは `mode: "split"` と `groupsCompleted` 配列の有無を確認します;いずれかが欠損していればマーカーは部分的とみなされ、Pass 3 は split モードで再実行されます。v2.0.x からアップグレードした場合、これは一度だけ想定される挙動です — 次の実行で正しいマーカー形状が書き込まれます。操作は不要です。
959
+
960
+ **"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` でリトライしてください。
961
+
962
+ **"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` で再実行して翻訳をスキップ。
963
+
964
+ **"pass4-memory.json exists but memory/ is empty"(v2.0.0)** — 以前の実行がマーカーを書き込みましたが、ユーザー(またはクリーンアップスクリプト)が `claudeos-core/memory/` を削除しました。CLI はこの古いマーカーを自動検出し、次の `init` で Pass 4 を再実行します。手動操作は不要です。
965
+
966
+ **"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 が自動的に再実行されます。
967
+
968
+ **"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` を再実行してください。
969
+
970
+ **"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` を使用してください。
971
+
972
+ ---
973
+
974
+ ## 貢献
975
+
976
+ 貢献は歓迎します!最も必要とされている領域:
977
+
978
+ - **新しいスタックテンプレート** — Ruby/Rails、Go (Gin/Fiber/Echo)、PHP (Laravel/Symfony)、Rust (Axum/Actix)、Svelte/SvelteKit、Remix
979
+ - **IDE 統合** — VS Code 拡張機能、IntelliJ プラグイン
980
+ - **CI/CD テンプレート** — GitLab CI、CircleCI、Jenkins の例(GitHub Actions はすでに付属 — `.github/workflows/test.yml` 参照)
981
+ - **テストカバレッジ** — テストスイートの拡張(現在 29 のテストファイルで 563 テスト、スキャナ、スタック検出、ドメイングループ化、プランパーシング、プロンプト生成、CLI セレクタ、モノレポ検出、Vite SPA 検出、検証ツール、L4 メモリスキャフォールド、Pass 2 再開検証、Pass 3 Guards 1/2/3(H1 センチネル + H2 BOM-aware 空ファイル + strict stale-marker unlink)、Pass 3 split モードのバッチサブ分割、Pass 3 部分マーカー再開(v2.1.0)、Pass 4 マーカーコンテンツ検証 + stale-marker unlink strictness + scaffoldSkillsManifest gap-fill(v2.1.0)、翻訳 env-skip ガード + early fail-fast + CI ワークフロー、staged-rules 移動、言語対応翻訳フォールバック、master plan 廃止のリグレッションスイート(v2.1.0)、memory score/compact フォーマッティングのリグレッション(v2.1.0)、AI Work Rules テンプレート構造をカバー)
982
+
983
+ 領域の完全なリスト、コードスタイル、コミット規約、新しいスタックテンプレートを追加するためのステップバイステップガイドについては、[`CONTRIBUTING.md`](./CONTRIBUTING.md) を参照してください。
984
+
985
+ ---
986
+
987
+ ## 作者
988
+
989
+ **claudeos-core** によって作成 — [GitHub](https://github.com/claudeos-core) · [Email](mailto:claudeoscore@gmail.com)
990
+
991
+ ## ライセンス
992
+
993
+ ISC