claudeos-core 2.1.0 → 2.1.1

package/CHANGELOG.md

@@ -1,5 +1,35 @@
 # Changelog
 
+## [2.1.1] — 2026-04-20
+
+Docs-only maintenance release. No runtime behavior or API changes.
+
+### Changed
+
+- **README: dropped `What's New in v2.1.0` section** from all 10 language
+  READMEs (`README.md`, `README.ko.md`, `README.ja.md`, `README.zh-CN.md`,
+  `README.es.md`, `README.vi.md`, `README.hi.md`, `README.ru.md`,
+  `README.fr.md`, `README.de.md`). Post-release cleanup — the section's
+  job is done once the release ships, and the same content is preserved
+  in `CHANGELOG.md` for anyone who wants the historical detail.
+
+- **README: dropped the `Real production case: 18-domain admin frontend
+  (2026-04-20)` subsection** under _Auto-scaling by Project Size_ across
+  all 10 language READMEs. The per-stage breakdown table (9 rows) and its
+  surrounding prose are removed. The trailing empirical reference in the
+  FAQ "What is Pass 3 split mode" answer (the `Empirically verified up
+  to 18 domains × 101 files × 102 minutes …` sentence with its now-dead
+  link) is also removed so no orphan reference remains.
+
+### Notes
+
+- Each README drops ~33 lines; total net change across translations is
+  ~330 lines removed. No code, tests, prompts, or generated artifacts
+  are touched — `npm pack` contents are identical to v2.1.0 apart from
+  the README files and `package.json`/`package-lock.json` version bump.
+
+---
+
 ## [2.1.0] — 2026-04-20
 
 This release addresses the primary cause of `Prompt is too long` failures in

package/README.de.md

@@ -12,20 +12,6 @@ ClaudeOS-Core liest Ihre Codebasis, extrahiert jedes Muster, das es findet, und
 
 ---
 
-## Neuerungen in v2.1.0
-
-v2.1.0 architektiert Pass 3 neu, um `Prompt is too long`-Fehler bei mittleren bis großen Projekten zu eliminieren. Zuvor musste ein einzelner Pass-3-Aufruf den gesamten Dokumentationsbaum in einem Rutsch ausgeben — Dutzende von Dateien über `CLAUDE.md`, Rules, Standards, Skills und Guides hinweg — und der akkumulierte Output überschritt ab ca. 5 Domains zuverlässig das Context-Fenster. Die Lösung ist strukturell, kein Prompt-Tuning:
-
-- **Pass 3 Split-Mode** (immer aktiv) — Pass 3 wird in sequenzielle `claude -p`-Aufrufe aufgeteilt (`3a` → `3b-core` → `3b-N` → `3c-core` → `3c-N` → `3d-aux`). Jede Stage startet mit einem **frischen Context-Fenster**, sodass Output-Akkumulations-Overflows unabhängig von der Projektgröße strukturell unmöglich sind.
-- **Fact Sheet zwischen Stages** — Stage `3a` liest die Pass-2-Analyse einmal und destilliert sie in ein 5–10 KB großes `pass3a-facts.md`. Alle späteren Stages referenzieren diese Fact Sheet anstatt die 100–500 KB große `pass2-merged.json` neu zu lesen, wodurch die Konsistenz über Dateien und frische Contexts hinweg erhalten bleibt.
-- **Batch-Unterteilung** (automatisch ab 16 Domains) — Stages 3b/3c werden zusätzlich in Batches von je 15 Domains aufgeteilt, sodass jede Stage unter ~50 Ausgabedateien bleibt. Ein 18-Domain-Admin-Frontend (React 19 + Vite 6) läuft in **102 Minuten mit 101 generierten Dateien über 8 Stages durch, null Overflow-Fehler** (echter Produktionslauf, 2026-04-20).
-- **Master-Plan-Generierung entfernt** — `claudeos-core/plan/*-master.md`-Dateien werden nicht mehr generiert. Master Plans waren ein internes Backup, das Claude Code zur Laufzeit nicht konsumierte, und ihre Aggregation in Pass 3d war ein primärer Overflow-Auslöser. Verwenden Sie stattdessen `git` für Backup/Restore.
-- **Pass 4 Gap-Fill: `skills/00.shared/MANIFEST.md`** — Wenn Pass 3c das Skill-Register auslässt (skill-spärliche Projekte), erstellt Pass 4 jetzt automatisch einen Stub, damit `.claude/rules/50.sync/03.skills-sync.md` niemals auf eine nicht existierende Datei zeigt.
-
-Ein paar kleinere Fixes: `memory --help` zeigt nun die Memory-Subcommand-Hilfe an (zuvor wurde die Top-Level-Hilfe gezeigt); `memory score` hinterlässt keine doppelten `importance`-Zeilen mehr; die `memory compact`-Summary-Marker sind jetzt korrekte Markdown-Listenelemente. Volle Details: [CHANGELOG.md](./CHANGELOG.md).
-
----
-
 ## Warum ClaudeOS-Core?
 
 Jedes andere Claude-Code-Tool funktioniert so:
@@ -591,24 +577,6 @@ Stage-Anzahl-Formel (bei aktivierter Batch-Teilung): `1 (3a) + 1 (3b-core) + N (
 
 Pass 4 (Memory-Scaffolding) fügt je nach Ausführungspfad (Claude-getriebene Generierung oder statischer Fallback) ~30 Sekunden bis 5 Minuten hinzu. Für Multi-Stack-Projekte (z. B. Java + React) werden Backend- und Frontend-Domains zusammen gezählt. Ein Projekt mit 6 Backend- + 4 Frontend-Domains = 10 gesamt = Stufe Mittel.
 
-### Reale Produktions-Fallstudie: 18-Domain-Admin-Frontend (2026-04-20)
-
-Ein React-19- + Vite-6- + TypeScript-Admin-Frontend mit 18 Domains und 6 Domain-Gruppen lief End-to-End in **102 Minuten mit 101 generierten Dateien** durch. Stage-Aufschlüsselung:
-
-| Stage | Dateien | Zeit | Dateien/min |
-|---|---|---|---|
-| `3a` (Fakten-Extraktion) | 1 (`pass3a-facts.md`) | 8m 44s | — |
-| `3b-core` (CLAUDE.md + gemeinsam) | 24 | 22m 10s | 1,1 |
-| `3b-1` (15 Domains) | 30 | 10m 6s | **3,0** |
-| `3b-2` (3 Domains) | 6 | 4m 34s | 1,3 |
-| `3c-core` (Guides + geteilt) | 11 | 8m 31s | 1,3 |
-| `3c-1` (15 Domains) | 8 | 5m 11s | **1,5** |
-| `3c-2` (3 Domains) | 3 | 3m 50s | 0,8 |
-| `3d-aux` (database + mcp) | 3 | 2m 52s | 1,0 |
-| Pass 4 | 12 | 5m 36s | 2,1 |
-
-Der Durchsatz ist bei den batched Domain-Stages deutlich höher (3b-1: 3,0 Dateien/min vs. 3b-core: 1,1 Dateien/min), weil Stages mit frischem Context von engen, wiederholbaren Per-Domain-Mustern profitieren. Verifikation komplett grün: `plan-validator`, `sync-checker`, `content-validator`, `pass-json-validator` — null Overflow-Fehler, null Abschneidungen.
-
 ---
 
 ## Verifikations-Tools
@@ -811,8 +779,7 @@ Nein. Es erstellt nur `CLAUDE.md`, `.claude/rules/` und `claudeos-core/`. Ihr be
 Es ruft `claude -p` mehrfach über die 4 Passes hinweg auf. Im v2.1.0-Split-Mode expandiert allein Pass 3 je nach Projektgröße in 4–14+ Stages (siehe [Auto-Scaling](#auto-scaling-nach-projektgröße)). Ein typisches kleines Projekt (1–15 Domains) verwendet insgesamt 8–9 `claude -p`-Aufrufe; ein 18-Domain-Projekt 11; ein 60-Domain-Projekt 15–17. Jede Stage läuft mit einem frischen Context-Fenster — die Token-Kosten pro Aufruf sind sogar niedriger als beim früheren Single-Call-Pass-3, weil keine Stage den gesamten Datei-Baum in einem Context halten muss. Wenn `--lang` nicht-englisch ist, kann der statische Fallback-Pfad einige zusätzliche `claude -p`-Aufrufe für Übersetzungen auslösen; Ergebnisse werden in `claudeos-core/generated/.i18n-cache-<lang>.json` gecacht, sodass nachfolgende Läufe sie wiederverwenden. Das liegt im Rahmen der normalen Claude-Code-Nutzung.
 
 **F: Was ist der Pass-3-Split-Mode und warum wurde er in v2.1.0 eingeführt?**
-Vor v2.1.0 führte Pass 3 einen einzigen `claude -p`-Aufruf aus, der den gesamten generierten Datei-Baum (`CLAUDE.md`, Standards, Rules, Skills, Guides — typischerweise 30–60 Dateien) in einer Antwort ausgeben musste. Das funktionierte bei kleinen Projekten, traf aber bei ca. 5 Domains zuverlässig auf `Prompt is too long`-Output-Akkumulations-Fehler. Der Fehler war nicht aus der Input-Größe vorhersagbar — er hing davon ab, wie ausführlich jede generierte Datei ausfiel, und konnte dasselbe Projekt intermittierend treffen. Der Split-Mode umgeht das Problem strukturell: Pass 3 wird in sequenzielle Stages aufgeteilt (`3a` → `3b-core` → `3b-N` → `3c-core` → `3c-N` → `3d-aux`), jede ein separater `claude -p`-Aufruf mit frischem Context-Fenster. Die Konsistenz über Stages hinweg wird durch `pass3a-facts.md` erhalten, eine 5–10 KB große destillierte Fact Sheet, die jede spätere Stage referenziert, anstatt `pass2-merged.json` erneut zu lesen. Der `pass3-complete.json`-Marker trägt ein `groupsCompleted`-Array, sodass ein Crash während `3c-2` ab `3c-2` fortgesetzt wird (nicht ab `3a`), was doppelte Token-Kosten vermeidet. Empirisch verifiziert bis 18 Domains × 101 Dateien × 102 Minuten ohne Overflow — siehe [Auto-Scaling](#auto-scaling-nach-projektgröße) für die reale Produktionsaufschlüsselung.
-
+Vor v2.1.0 führte Pass 3 einen einzigen `claude -p`-Aufruf aus, der den gesamten generierten Datei-Baum (`CLAUDE.md`, Standards, Rules, Skills, Guides — typischerweise 30–60 Dateien) in einer Antwort ausgeben musste. Das funktionierte bei kleinen Projekten, traf aber bei ca. 5 Domains zuverlässig auf `Prompt is too long`-Output-Akkumulations-Fehler. Der Fehler war nicht aus der Input-Größe vorhersagbar — er hing davon ab, wie ausführlich jede generierte Datei ausfiel, und konnte dasselbe Projekt intermittierend treffen. Der Split-Mode umgeht das Problem strukturell: Pass 3 wird in sequenzielle Stages aufgeteilt (`3a` → `3b-core` → `3b-N` → `3c-core` → `3c-N` → `3d-aux`), jede ein separater `claude -p`-Aufruf mit frischem Context-Fenster. Die Konsistenz über Stages hinweg wird durch `pass3a-facts.md` erhalten, eine 5–10 KB große destillierte Fact Sheet, die jede spätere Stage referenziert, anstatt `pass2-merged.json` erneut zu lesen. Der `pass3-complete.json`-Marker trägt ein `groupsCompleted`-Array, sodass ein Crash während `3c-2` ab `3c-2` fortgesetzt wird (nicht ab `3a`), was doppelte Token-Kosten vermeidet.
 **F: Soll ich die generierten Dateien in Git committen?**
 Ja, empfohlen. Ihr Team kann dieselben Claude-Code-Standards teilen. Erwägen Sie, `claudeos-core/generated/` in `.gitignore` aufzunehmen (Analyse-JSON ist regenerierbar).
 

package/README.es.md

@@ -12,20 +12,6 @@ ClaudeOS-Core lee tu codebase, extrae cada patrón que encuentra y genera un con
 
 ---
 
-## Novedades en v2.1.0
-
-v2.1.0 rediseña Pass 3 para eliminar los fallos `Prompt is too long` en proyectos medianos y grandes. Anteriormente, una única llamada de Pass 3 debía emitir todo el árbol de documentación de golpe — decenas de archivos entre `CLAUDE.md`, reglas, standards, skills y guides — y la salida acumulada superaba de forma confiable la ventana de contexto a partir de ~5 dominios. El fix es **estructural**, no un ajuste de prompt:
-
-- **Modo split de Pass 3** (siempre activo) — Pass 3 se descompone en llamadas `claude -p` secuenciales (`3a` → `3b-core` → `3b-N` → `3c-core` → `3c-N` → `3d-aux`). Cada etapa arranca con una **ventana de contexto nueva**, así que el overflow por acumulación de salida deja de ser posible sin importar el tamaño del proyecto.
-- **Fact sheet entre etapas** — La etapa `3a` lee el análisis de Pass 2 una sola vez y lo destila en un `pass3a-facts.md` de 5–10 KB. Todas las etapas posteriores referencian ese fact sheet en lugar de releer el `pass2-merged.json` de 100–500 KB, preservando la consistencia entre archivos a través de contextos nuevos.
-- **Sub-división por lotes** (automática a partir de ≥16 dominios) — Las etapas 3b/3c se subdividen en lotes de 15 dominios cada uno, manteniendo cada etapa por debajo de ~50 archivos de salida. Un admin frontend React 19 + Vite 6 con 18 dominios se completó en **102 minutos con 101 archivos generados en 8 etapas, cero fallos por overflow** (ejecución real de producción, 2026-04-20).
-- **Generación de Master plan eliminada** — Los archivos `claudeos-core/plan/*-master.md` ya no se generan. Los master plans eran un backup interno que Claude Code no consumía en runtime, y agregarlos en Pass 3d era una causa principal de overflow. Usa `git` para backup/restore en su lugar.
-- **Gap-fill de Pass 4: `skills/00.shared/MANIFEST.md`** — Si Pass 3c omite el registro de skills (proyectos skill-sparse), Pass 4 ahora auto-crea un stub para que `.claude/rules/50.sync/03.skills-sync.md` nunca apunte a un archivo colgante.
-
-También hay algunos fixes menores: `memory --help` ahora muestra la ayuda del subcomando memory (antes mostraba el top-level); `memory score` ya no deja líneas `importance` duplicadas; los marcadores de resumen de `memory compact` son ahora elementos de lista markdown propiamente formateados. Detalles completos: [CHANGELOG.md](./CHANGELOG.md).
-
----
-
 ## ¿Por qué ClaudeOS-Core?
 
 Cualquier otra herramienta de Claude Code funciona así:
@@ -591,24 +577,6 @@ Fórmula de conteo de etapas (cuando hay lotes): `1 (3a) + 1 (3b-core) + N (3b-1
 
 Pass 4 (memory scaffolding) añade ~30 segundos a 5 minutos encima según si se ejecuta la generación dirigida por Claude o el fallback estático. Para proyectos multi-stack (ej: Java + React), los dominios backend y frontend se cuentan juntos. Un proyecto con 6 dominios backend + 4 frontend = 10 en total = tier Medio.
 
-### Caso real de producción: admin frontend de 18 dominios (2026-04-20)
-
-Un admin frontend React 19 + Vite 6 + TypeScript con 18 dominios y 6 grupos de dominios se completó de principio a fin en **102 minutos con 101 archivos generados**. Desglose por etapa:
-
-| Etapa | Archivos | Tiempo | Archivos/min |
-|---|---|---|---|
-| `3a` (extracción de hechos) | 1 (`pass3a-facts.md`) | 8m 44s | — |
-| `3b-core` (CLAUDE.md + común) | 24 | 22m 10s | 1.1 |
-| `3b-1` (15 dominios) | 30 | 10m 6s | **3.0** |
-| `3b-2` (3 dominios) | 6 | 4m 34s | 1.3 |
-| `3c-core` (guides + compartidos) | 11 | 8m 31s | 1.3 |
-| `3c-1` (15 dominios) | 8 | 5m 11s | **1.5** |
-| `3c-2` (3 dominios) | 3 | 3m 50s | 0.8 |
-| `3d-aux` (database + mcp) | 3 | 2m 52s | 1.0 |
-| Pass 4 | 12 | 5m 36s | 2.1 |
-
-El throughput es notablemente más alto en las etapas de dominio por lote (3b-1: 3.0 archivos/min vs. 3b-core: 1.1 archivos/min) porque las etapas con contexto nuevo se benefician de patrones ajustados y repetibles por dominio. Verificación todo-verde: `plan-validator`, `sync-checker`, `content-validator`, `pass-json-validator` — cero fallos por overflow, cero truncados.
-
 ---
 
 ## Herramientas de Verificación
@@ -810,8 +778,7 @@ No. Solo crea `CLAUDE.md`, `.claude/rules/` y `claudeos-core/`. Tu código exist
 Llama a `claude -p` varias veces a lo largo de 4 passes. En el modo split de v2.1.0, Pass 3 por sí solo se expande en 4–14+ etapas según el tamaño del proyecto (ver [Auto-escalado](#auto-escalado-por-tamaño-del-proyecto)). Un proyecto pequeño típico (1–15 dominios) usa 8–9 llamadas `claude -p` en total; un proyecto de 18 dominios usa 11; un proyecto de 60 dominios usa 15–17. Cada etapa se ejecuta con una ventana de contexto nueva — el coste en tokens por llamada es en realidad más bajo que el del Pass 3 de llamada única, porque ninguna etapa tiene que sostener el árbol de archivos completo en un único contexto. Cuando `--lang` no es inglés, el path de fallback estático puede invocar algunas llamadas adicionales a `claude -p` para traducir; los resultados se cachean en `claudeos-core/generated/.i18n-cache-<lang>.json` para que las ejecuciones posteriores los reutilicen. Esto entra dentro del uso normal de Claude Code.
 
 **P: ¿Qué es el modo split de Pass 3 y por qué se añadió en v2.1.0?**
-Antes de v2.1.0, Pass 3 hacía una única llamada `claude -p` que debía emitir todo el árbol de archivos generados (`CLAUDE.md`, standards, reglas, skills, guides — típicamente 30–60 archivos) en una sola respuesta. Esto funcionaba en proyectos pequeños pero chocaba de forma confiable con fallos `Prompt is too long` por acumulación de salida a ~5 dominios. El fallo no era predecible desde el tamaño de entrada — dependía de lo verboso que resultara cada archivo generado, y podía darse en el mismo proyecto de forma intermitente. El modo split esquiva el problema de forma estructural: Pass 3 se descompone en etapas secuenciales (`3a` → `3b-core` → `3b-N` → `3c-core` → `3c-N` → `3d-aux`), cada una una llamada `claude -p` separada con una ventana de contexto nueva. La consistencia entre etapas se preserva mediante `pass3a-facts.md`, un fact sheet destilado de 5–10 KB que cada etapa posterior referencia en lugar de releer `pass2-merged.json`. El marcador `pass3-complete.json` lleva un array `groupsCompleted` para que un crash durante `3c-2` reanude desde `3c-2` (no desde `3a`), evitando doblar el coste en tokens. Verificado empíricamente hasta 18 dominios × 101 archivos × 102 minutos sin ningún overflow — ver [Auto-escalado](#auto-escalado-por-tamaño-del-proyecto) para el desglose real de producción.
-
+Antes de v2.1.0, Pass 3 hacía una única llamada `claude -p` que debía emitir todo el árbol de archivos generados (`CLAUDE.md`, standards, reglas, skills, guides — típicamente 30–60 archivos) en una sola respuesta. Esto funcionaba en proyectos pequeños pero chocaba de forma confiable con fallos `Prompt is too long` por acumulación de salida a ~5 dominios. El fallo no era predecible desde el tamaño de entrada — dependía de lo verboso que resultara cada archivo generado, y podía darse en el mismo proyecto de forma intermitente. El modo split esquiva el problema de forma estructural: Pass 3 se descompone en etapas secuenciales (`3a` → `3b-core` → `3b-N` → `3c-core` → `3c-N` → `3d-aux`), cada una una llamada `claude -p` separada con una ventana de contexto nueva. La consistencia entre etapas se preserva mediante `pass3a-facts.md`, un fact sheet destilado de 5–10 KB que cada etapa posterior referencia en lugar de releer `pass2-merged.json`. El marcador `pass3-complete.json` lleva un array `groupsCompleted` para que un crash durante `3c-2` reanude desde `3c-2` (no desde `3a`), evitando doblar el coste en tokens.
 **P: ¿Debería commitear los archivos generados a Git?**
 Sí, recomendado. Tu equipo puede compartir los mismos standards de Claude Code. Considera añadir `claudeos-core/generated/` a `.gitignore` (el JSON de análisis es regenerable).
 

package/README.fr.md

@@ -12,20 +12,6 @@ ClaudeOS-Core lit votre codebase, extrait chaque pattern qu'il y trouve et gén
 
 ---
 
-## Nouveautés de la v2.1.0
-
-La v2.1.0 réarchitecture Pass 3 pour éliminer les échecs `Prompt is too long` sur les projets moyens à gros. Auparavant, un seul appel Pass 3 devait émettre tout l'arbre de documentation d'un coup — des dizaines de fichiers couvrant `CLAUDE.md`, les règles, les standards, les skills et les guides — et la sortie accumulée dépassait de façon fiable la fenêtre de contexte au-delà de ~5 domaines. La correction est structurelle, pas un simple ajustement de prompt :
-
-- **Mode Pass 3 split** (toujours actif) — Pass 3 est découpé en appels `claude -p` séquentiels (`3a` → `3b-core` → `3b-N` → `3c-core` → `3c-N` → `3d-aux`). Chaque stage démarre avec une **fenêtre de contexte fraîche**, donc l'overflow par accumulation de sortie n'est structurellement plus possible, quelle que soit la taille du projet.
-- **Fiche de faits entre stages** — Le stage `3a` lit l'analyse de Pass 2 une seule fois et la distille en un `pass3a-facts.md` de 5 à 10 Ko. Tous les stages suivants référencent cette fiche au lieu de relire le `pass2-merged.json` de 100 à 500 Ko, préservant la cohérence inter-fichiers à travers les contextes frais.
-- **Sous-division en batches** (automatique à partir de 16 domaines) — Les stages 3b/3c sont en outre divisés en batches de 15 domaines, gardant chaque stage sous ~50 fichiers de sortie. Un admin frontend React 19 + Vite 6 de 18 domaines se termine en **102 minutes avec 101 fichiers générés sur 8 stages, zéro échec d'overflow** (exécution de production réelle, 2026-04-20).
-- **Génération de master plan supprimée** — Les fichiers `claudeos-core/plan/*-master.md` ne sont plus générés. Les master plans étaient un backup interne que Claude Code ne consommait pas à l'exécution, et leur agrégation dans Pass 3d était l'un des principaux déclencheurs d'overflow. Utilisez `git` pour le backup/restore à la place.
-- **Pass 4 gap-fill : `skills/00.shared/MANIFEST.md`** — Si Pass 3c omet le registre des skills (projets skill-sparse), Pass 4 crée désormais automatiquement un stub pour que `.claude/rules/50.sync/03.skills-sync.md` ne pointe jamais sur un fichier fantôme.
-
-Quelques corrections plus petites : `memory --help` affiche maintenant l'aide des sous-commandes memory (auparavant, c'était l'aide top-level) ; `memory score` ne laisse plus de lignes `importance` dupliquées ; les marqueurs de résumé de `memory compact` sont de vrais items de liste markdown. Détails complets : [CHANGELOG.md](./CHANGELOG.md).
-
----
-
 ## Pourquoi ClaudeOS-Core ?
 
 Tous les autres outils Claude Code fonctionnent ainsi :
@@ -591,24 +577,6 @@ Formule du nombre de stages (quand batché) : `1 (3a) + 1 (3b-core) + N (3b-1..N
 
 Pass 4 (memory scaffolding) ajoute ~30 secondes à 5 minutes par-dessus selon que la génération pilotée par Claude ou le fallback statique tourne. Pour les projets multi-stack (ex : Java + React), les domaines backend et frontend sont comptés ensemble. Un projet avec 6 domaines backend + 4 frontend = 10 au total = palier Moyen.
 
-### Cas de production réel : admin frontend de 18 domaines (2026-04-20)
-
-Un admin frontend React 19 + Vite 6 + TypeScript de 18 domaines et 6 groupes de domaines s'est terminé de bout en bout en **102 minutes avec 101 fichiers générés**. Détail par stage :
-
-| Stage | Fichiers | Temps | Fichiers/min |
-|---|---|---|---|
-| `3a` (extraction de faits) | 1 (`pass3a-facts.md`) | 8m 44s | — |
-| `3b-core` (CLAUDE.md + commun) | 24 | 22m 10s | 1.1 |
-| `3b-1` (15 domaines) | 30 | 10m 6s | **3.0** |
-| `3b-2` (3 domaines) | 6 | 4m 34s | 1.3 |
-| `3c-core` (guides + partagés) | 11 | 8m 31s | 1.3 |
-| `3c-1` (15 domaines) | 8 | 5m 11s | **1.5** |
-| `3c-2` (3 domaines) | 3 | 3m 50s | 0.8 |
-| `3d-aux` (database + mcp) | 3 | 2m 52s | 1.0 |
-| Pass 4 | 12 | 5m 36s | 2.1 |
-
-Le débit est nettement plus élevé sur les stages de domaines batchés (3b-1 : 3.0 fichiers/min contre 3b-core : 1.1 fichiers/min) car les stages à contexte frais bénéficient de patterns par-domaine serrés et répétables. Vérification tout vert : `plan-validator`, `sync-checker`, `content-validator`, `pass-json-validator` — zéro échec d'overflow, zéro troncation.
-
 ---
 
 ## Outils de Vérification
@@ -810,8 +778,7 @@ Non. Il crée uniquement `CLAUDE.md`, `.claude/rules/` et `claudeos-core/`. Votr
 Il appelle `claude -p` plusieurs fois à travers les 4 passes. En mode split v2.1.0, Pass 3 seul se développe en 4–14+ stages selon la taille du projet (voir [Auto-scaling](#auto-scaling-selon-la-taille-du-projet)). Un petit projet typique (1–15 domaines) utilise 8–9 appels `claude -p` au total ; un projet de 18 domaines en utilise 11 ; un projet de 60 domaines en utilise 15–17. Chaque stage tourne avec une fenêtre de contexte fraîche — le coût en tokens par appel est en fait plus bas qu'avec le Pass 3 monolithique, parce qu'aucun stage n'a à retenir l'arbre de fichiers entier dans un seul contexte. Quand `--lang` n'est pas l'anglais, le chemin de fallback statique peut invoquer quelques appels supplémentaires à `claude -p` pour traduire ; les résultats sont cachés dans `claudeos-core/generated/.i18n-cache-<lang>.json` pour que les exécutions suivantes les réutilisent. Cela reste dans l'usage normal de Claude Code.
 
 **Q : Qu'est-ce que le mode split de Pass 3 et pourquoi a-t-il été ajouté en v2.1.0 ?**
-Avant la v2.1.0, Pass 3 faisait un seul appel `claude -p` qui devait émettre tout l'arbre de fichiers généré (`CLAUDE.md`, standards, règles, skills, guides — typiquement 30–60 fichiers) en une seule réponse. Cela fonctionnait sur les petits projets mais se heurtait de façon fiable à des échecs `Prompt is too long` par accumulation de sortie autour de 5 domaines. L'échec n'était pas prédictible à partir de la taille d'entrée — il dépendait de la verbosité des fichiers générés et pouvait frapper le même projet de façon intermittente. Le mode split contourne le problème structurellement : Pass 3 est découpé en stages séquentiels (`3a` → `3b-core` → `3b-N` → `3c-core` → `3c-N` → `3d-aux`), chacun un appel `claude -p` séparé avec une fenêtre de contexte fraîche. La cohérence inter-stages est préservée par `pass3a-facts.md`, une fiche de faits distillée de 5 à 10 Ko que chaque stage suivant référence au lieu de relire `pass2-merged.json`. Le marqueur `pass3-complete.json` porte un array `groupsCompleted` pour qu'un crash pendant `3c-2` reprenne à `3c-2` (pas à `3a`), évitant de doubler le coût en tokens. Vérifié empiriquement jusqu'à 18 domaines × 101 fichiers × 102 minutes avec zéro overflow — voir [Auto-scaling](#auto-scaling-selon-la-taille-du-projet) pour le détail de production réel.
-
+Avant la v2.1.0, Pass 3 faisait un seul appel `claude -p` qui devait émettre tout l'arbre de fichiers généré (`CLAUDE.md`, standards, règles, skills, guides — typiquement 30–60 fichiers) en une seule réponse. Cela fonctionnait sur les petits projets mais se heurtait de façon fiable à des échecs `Prompt is too long` par accumulation de sortie autour de 5 domaines. L'échec n'était pas prédictible à partir de la taille d'entrée — il dépendait de la verbosité des fichiers générés et pouvait frapper le même projet de façon intermittente. Le mode split contourne le problème structurellement : Pass 3 est découpé en stages séquentiels (`3a` → `3b-core` → `3b-N` → `3c-core` → `3c-N` → `3d-aux`), chacun un appel `claude -p` séparé avec une fenêtre de contexte fraîche. La cohérence inter-stages est préservée par `pass3a-facts.md`, une fiche de faits distillée de 5 à 10 Ko que chaque stage suivant référence au lieu de relire `pass2-merged.json`. Le marqueur `pass3-complete.json` porte un array `groupsCompleted` pour qu'un crash pendant `3c-2` reprenne à `3c-2` (pas à `3a`), évitant de doubler le coût en tokens.
 **Q : Dois-je commiter les fichiers générés dans Git ?**
 Oui, recommandé. Votre équipe peut partager les mêmes standards Claude Code. Pensez à ajouter `claudeos-core/generated/` à `.gitignore` (le JSON d'analyse est régénérable).
 

package/README.hi.md

@@ -12,20 +12,6 @@ ClaudeOS-Core आपका कोडबेस पढ़ता है, हर प
 
 ---
 
-## v2.1.0 में नया क्या है
-
-v2.1.0 मध्यम-से-बड़े प्रोजेक्ट्स पर `Prompt is too long` विफलताओं को हटाने के लिए Pass 3 को फिर से डिज़ाइन करता है। पहले, एक सिंगल Pass 3 कॉल को पूरे डॉक्यूमेंटेशन ट्री को एक साथ emit करना होता था — `CLAUDE.md`, rules, standards, skills, और guides के बीच दर्जनों फ़ाइलें — और संचित आउटपुट ~5 डोमेन के बाद विश्वसनीय रूप से context window को पार कर जाता था। यह फ़िक्स संरचनात्मक है, prompt tweak नहीं:
-
-- **Pass 3 split mode** (हमेशा सक्रिय) — Pass 3 को क्रमिक `claude -p` कॉल्स में तोड़ दिया गया है (`3a` → `3b-core` → `3b-N` → `3c-core` → `3c-N` → `3d-aux`)। हर stage एक **नए context window** के साथ शुरू होता है, इसलिए प्रोजेक्ट आकार की परवाह किए बिना output-accumulation overflow अब संरचनात्मक रूप से असंभव है।
-- **Stages के बीच fact sheet** — Stage `3a` Pass 2 विश्लेषण को एक बार पढ़ता है और उसे 5–10 KB के `pass3a-facts.md` में distil करता है। बाद के सभी stages 100–500 KB `pass2-merged.json` को दोबारा पढ़ने के बजाय इस fact sheet को reference करते हैं, जिससे नए contexts के बीच cross-file consistency संरक्षित रहती है।
-- **Batch sub-division** (≥16 डोमेन पर automatic) — Stages 3b/3c को आगे 15 डोमेन प्रति batch में विभाजित किया जाता है, जिससे हर stage का output ~50 फ़ाइलें से नीचे रहता है। 18-डोमेन React 19 + Vite 6 admin frontend **102 मिनट में 101 फ़ाइलें 8 stages पर जेनरेट, शून्य overflow विफलता** के साथ पूर्ण (वास्तविक production run, 2026-04-20)।
-- **Master plan generation हटाया गया** — `claudeos-core/plan/*-master.md` फ़ाइलें अब जेनरेट नहीं होतीं। Master plans एक आंतरिक backup थे जिन्हें Claude Code runtime पर नहीं पढ़ता था, और Pass 3d में उन्हें aggregate करना overflow का एक प्रमुख कारण था। इसके बजाय backup/restore के लिए `git` का उपयोग करें।
-- **Pass 4 gap-fill: `skills/00.shared/MANIFEST.md`** — यदि Pass 3c skill registry को omit कर देता है (skill-sparse प्रोजेक्ट्स), तो Pass 4 अब स्वतः एक stub बनाता है ताकि `.claude/rules/50.sync/03.skills-sync.md` कभी dangling फ़ाइल को न point करे।
-
-कुछ छोटे फ़िक्स: `memory --help` अब memory subcommand help दिखाता है (पहले top-level दिखता था); `memory score` अब duplicate `importance` लाइनें नहीं छोड़ता; `memory compact` summary markers अब proper markdown list items हैं। पूरी जानकारी: [CHANGELOG.md](./CHANGELOG.md)।
-
----
-
 ## ClaudeOS-Core क्यों?
 
 हर दूसरा Claude Code टूल ऐसे काम करता है:
@@ -591,24 +577,6 @@ Stage count सूत्र (batch होने पर): `1 (3a) + 1 (3b-core) +
 
 Pass 4 (memory scaffolding) ऊपर से ~30 सेकंड से 5 मिनट जोड़ता है, इस पर निर्भर करता है कि Claude-driven generation या static fallback चलता है। Multi-stack प्रोजेक्ट्स (जैसे Java + React) के लिए, backend और frontend डोमेन एक साथ गिने जाते हैं। 6 backend + 4 frontend डोमेन वाला प्रोजेक्ट = 10 कुल = मध्यम tier।
 
-### वास्तविक production केस: 18-डोमेन admin frontend (2026-04-20)
-
-18 डोमेन और 6 डोमेन समूहों वाले एक React 19 + Vite 6 + TypeScript admin frontend ने **102 मिनट में 101 फ़ाइलें जेनरेट के साथ** end-to-end पूरा किया। Stage breakdown:
-
-| Stage | फ़ाइलें | समय | फ़ाइलें/मिनट |
-|---|---|---|---|
-| `3a` (fact extraction) | 1 (`pass3a-facts.md`) | 8m 44s | — |
-| `3b-core` (CLAUDE.md + common) | 24 | 22m 10s | 1.1 |
-| `3b-1` (15 डोमेन) | 30 | 10m 6s | **3.0** |
-| `3b-2` (3 डोमेन) | 6 | 4m 34s | 1.3 |
-| `3c-core` (guides + shared) | 11 | 8m 31s | 1.3 |
-| `3c-1` (15 डोमेन) | 8 | 5m 11s | **1.5** |
-| `3c-2` (3 डोमेन) | 3 | 3m 50s | 0.8 |
-| `3d-aux` (database + mcp) | 3 | 2m 52s | 1.0 |
-| Pass 4 | 12 | 5m 36s | 2.1 |
-
-Throughput batched domain stages (3b-1: 3.0 फ़ाइलें/मिनट बनाम 3b-core: 1.1 फ़ाइलें/मिनट) पर उल्लेखनीय रूप से अधिक है क्योंकि fresh-context stages tight, repeatable per-domain patterns से लाभ उठाते हैं। सत्यापन all-green: `plan-validator`, `sync-checker`, `content-validator`, `pass-json-validator` — शून्य overflow विफलता, शून्य truncation।
-
 ---
 
 ## सत्यापन टूल्स
@@ -810,8 +778,7 @@ ClaudeOS-Core **प्रोजेक्ट-विशिष्ट rules और s
 यह 4 passes में `claude -p` को कई बार कॉल करता है। v2.1.0 split mode में, Pass 3 अकेले प्रोजेक्ट आकार के आधार पर 4–14+ stages में विस्तारित होता है ([ऑटो-स्केलिंग](#प्रोजेक्ट-आकार-द्वारा-ऑटो-स्केलिंग) देखें)। एक विशिष्ट छोटा प्रोजेक्ट (1–15 डोमेन) कुल 8–9 `claude -p` कॉल्स का उपयोग करता है; एक 18-डोमेन प्रोजेक्ट 11 का उपयोग करता है; एक 60-डोमेन प्रोजेक्ट 15–17 का उपयोग करता है। हर stage fresh context window के साथ चलता है — per-call token cost वास्तव में single-call Pass 3 से कम है, क्योंकि किसी भी stage को पूरे फ़ाइल tree को एक context में रखना नहीं पड़ता। जब `--lang` गैर-अंग्रेज़ी होता है, तो static fallback path अनुवाद के लिए कुछ अतिरिक्त `claude -p` कॉल invoke कर सकता है; परिणाम `claudeos-core/generated/.i18n-cache-<lang>.json` में cached होते हैं ताकि बाद के runs उन्हें पुनः उपयोग करें। यह सामान्य Claude Code उपयोग के भीतर है।
 
 **Q: Pass 3 split mode क्या है और इसे v2.1.0 में क्यों जोड़ा गया?**
-v2.1.0 से पहले, Pass 3 एक सिंगल `claude -p` कॉल बनाता था जिसे पूरे जेनरेट किए गए फ़ाइल tree (`CLAUDE.md`, standards, rules, skills, guides — आमतौर पर 30–60 फ़ाइलें) को एक response में emit करना होता था। यह छोटे प्रोजेक्ट्स पर काम करता था लेकिन ~5 डोमेन पर विश्वसनीय रूप से `Prompt is too long` output-accumulation विफलताओं को hit करता था। विफलता input size से predictable नहीं थी — यह इस पर निर्भर करती थी कि हर जेनरेट की गई फ़ाइल कितनी verbose हो, और एक ही प्रोजेक्ट को intermittently strike कर सकती थी। Split mode समस्या को संरचनात्मक रूप से bypass करता है: Pass 3 को क्रमिक stages (`3a` → `3b-core` → `3b-N` → `3c-core` → `3c-N` → `3d-aux`) में तोड़ दिया गया है, हर एक fresh context window के साथ एक अलग `claude -p` कॉल। Cross-stage consistency `pass3a-facts.md` द्वारा संरक्षित होती है, एक 5–10 KB distilled fact sheet जिसे हर बाद का stage `pass2-merged.json` को दोबारा पढ़ने के बजाय reference करता है। `pass3-complete.json` marker एक `groupsCompleted` array carry करता है ताकि `3c-2` के दौरान crash `3c-2` से resume हो (not `3a` से), token cost को दोगुना करने से बचाते हुए। 18 डोमेन × 101 फ़ाइलें × 102 मिनट तक शून्य overflow के साथ empirically verified — वास्तविक production breakdown के लिए [ऑटो-स्केलिंग](#प्रोजेक्ट-आकार-द्वारा-ऑटो-स्केलिंग) देखें।
-
+v2.1.0 से पहले, Pass 3 एक सिंगल `claude -p` कॉल बनाता था जिसे पूरे जेनरेट किए गए फ़ाइल tree (`CLAUDE.md`, standards, rules, skills, guides — आमतौर पर 30–60 फ़ाइलें) को एक response में emit करना होता था। यह छोटे प्रोजेक्ट्स पर काम करता था लेकिन ~5 डोमेन पर विश्वसनीय रूप से `Prompt is too long` output-accumulation विफलताओं को hit करता था। विफलता input size से predictable नहीं थी — यह इस पर निर्भर करती थी कि हर जेनरेट की गई फ़ाइल कितनी verbose हो, और एक ही प्रोजेक्ट को intermittently strike कर सकती थी। Split mode समस्या को संरचनात्मक रूप से bypass करता है: Pass 3 को क्रमिक stages (`3a` → `3b-core` → `3b-N` → `3c-core` → `3c-N` → `3d-aux`) में तोड़ दिया गया है, हर एक fresh context window के साथ एक अलग `claude -p` कॉल। Cross-stage consistency `pass3a-facts.md` द्वारा संरक्षित होती है, एक 5–10 KB distilled fact sheet जिसे हर बाद का stage `pass2-merged.json` को दोबारा पढ़ने के बजाय reference करता है। `pass3-complete.json` marker एक `groupsCompleted` array carry करता है ताकि `3c-2` के दौरान crash `3c-2` से resume हो (not `3a` से), token cost को दोगुना करने से बचाते हुए।
 **Q: क्या मुझे जेनरेट की गई फ़ाइलों को Git पर commit करना चाहिए?**
 हाँ, अनुशंसित। आपकी टीम समान Claude Code standards साझा कर सकती है। `claudeos-core/generated/` को `.gitignore` में जोड़ने पर विचार करें (विश्लेषण JSON पुनर्जेनरेट करने योग्य है)।
 

package/README.ja.md

@@ -12,20 +12,6 @@ ClaudeOS-Core はコードベースを読み取り、見つけたすべてのパ
 
 ---
 
-## v2.1.0 の新機能
-
-v2.1.0 は Pass 3 を再設計し、中規模〜大規模プロジェクトで発生していた `Prompt is too long` 失敗を解消します。従来、単一の Pass 3 呼び出しが `CLAUDE.md`、rules、standards、skills、guides にまたがる数十ファイルを一度にすべて出力する必要があり、出力の累積が 5 ドメインを超えるあたりで確実にコンテキストウィンドウを超えていました。今回の修正はプロンプトの調整ではなく**構造的な変更**です:
-
-- **Pass 3 split モード**（常時有効） — Pass 3 は順次実行される `claude -p` 呼び出し（`3a` → `3b-core` → `3b-N` → `3c-core` → `3c-N` → `3d-aux`）に分割されます。各ステージは**新しいコンテキストウィンドウ**で開始するため、プロジェクトの規模にかかわらず出力累積によるオーバーフローは構造的に発生しません。
-- **ステージ間のファクトシート** — ステージ `3a` が Pass 2 の分析を一度だけ読み、5〜10 KB の `pass3a-facts.md` に蒸留します。以降のすべてのステージは 100〜500 KB の `pass2-merged.json` を再読み込みせず、このファクトシートを参照するため、新しいコンテキストをまたいでもファイル間の整合性が保たれます。
-- **バッチのサブ分割**（16 ドメイン以上で自動適用） — ステージ 3b/3c はさらに 15 ドメインずつのバッチに分割され、各ステージの出力を ~50 ファイル以下に抑えます。18 ドメインの React 19 + Vite 6 管理画面フロントエンドで、**102 分で 101 ファイル生成・8 ステージ・オーバーフロー 0 件**を実測で確認しました（2026-04-20 の本番実行）。
-- **Master plan の生成を廃止** — `claudeos-core/plan/*-master.md` ファイルは生成されなくなりました。Master plan は Claude Code がランタイムで読み込まない内部バックアップであり、Pass 3d でそれらを集約することがオーバーフローの主要因でした。バックアップ/復元には `git` を使用してください。
-- **Pass 4 gap-fill: `skills/00.shared/MANIFEST.md`** — Pass 3c がスキルレジストリを省略した場合（スキルが少ないプロジェクト）、Pass 4 が自動的にスタブを作成し、`.claude/rules/50.sync/03.skills-sync.md` がぶら下がった参照先を指さないようにします。
-
-細かな修正もあります: `memory --help` が memory サブコマンドのヘルプを表示するようになりました（以前はトップレベルが表示されていました）；`memory score` が `importance` 行を重複して残さなくなりました；`memory compact` のサマリーマーカーが正しい Markdown のリスト項目になりました。詳細: [CHANGELOG.md](./CHANGELOG.md)。
-
----
-
 ## なぜ ClaudeOS-Core なのか？
 
 他のすべての Claude Code ツールはこう動作します：
@@ -591,24 +577,6 @@ Pass 3 の split モードはステージ数をドメイン数に応じてスケ
 
 Pass 4（メモリスキャフォールディング）は、Claude 主導の生成または静的フォールバックのいずれが走るかによって、上に ~30 秒〜5 分を追加します。マルチスタックプロジェクト（例：Java + React）では、backend と frontend のドメインが合算されます。backend 6 + frontend 4 ドメイン = 合計 10 で中規模ティアになります。
 
-### 実本番ケース：18 ドメインの管理画面フロントエンド（2026-04-20）
-
-18 ドメイン・6 ドメイングループの React 19 + Vite 6 + TypeScript 管理画面フロントエンドは、エンドツーエンドで **102 分・101 ファイル生成**で完走しました。ステージ別内訳：
-
-| ステージ | ファイル | 時間 | Files/min |
-|---|---|---|---|
-| `3a`（ファクト抽出） | 1（`pass3a-facts.md`） | 8m 44s | — |
-| `3b-core`（CLAUDE.md + 共通） | 24 | 22m 10s | 1.1 |
-| `3b-1`（15 ドメイン） | 30 | 10m 6s | **3.0** |
-| `3b-2`（3 ドメイン） | 6 | 4m 34s | 1.3 |
-| `3c-core`（guides + 共有） | 11 | 8m 31s | 1.3 |
-| `3c-1`（15 ドメイン） | 8 | 5m 11s | **1.5** |
-| `3c-2`（3 ドメイン） | 3 | 3m 50s | 0.8 |
-| `3d-aux`（database + mcp） | 3 | 2m 52s | 1.0 |
-| Pass 4 | 12 | 5m 36s | 2.1 |
-
-バッチ化されたドメインステージではスループットが顕著に高くなります（3b-1：3.0 files/min 対 3b-core：1.1 files/min） — これは、フレッシュなコンテキストのステージが、タイトで反復的なドメインごとのパターンから恩恵を受けるためです。検証はすべてパス：`plan-validator`、`sync-checker`、`content-validator`、`pass-json-validator` — オーバーフロー失敗 0 件、切り詰め 0 件。
-
 ---
 
 ## 検証ツール
@@ -810,8 +778,7 @@ ClaudeOS-Core を使ってプロジェクトのルールを生成し、その上
 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 使用量の範囲内です。
 
 **Q：Pass 3 split モードとは何ですか？なぜ v2.1.0 で追加されたのですか？**
-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 件 — 実本番内訳は [自動スケーリング](#プロジェクトサイズによる自動スケーリング) を参照してください。
-
+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` から再開するため、トークンコストの倍増を避けられます。
 **Q：生成されたファイルを Git にコミットすべきですか？**
 はい、推奨します。チームが同じ Claude Code スタンダードを共有できます。`claudeos-core/generated/` を `.gitignore` に追加することを検討してください（分析 JSON は再生成可能）。
 

package/README.ko.md

@@ -12,20 +12,6 @@ ClaudeOS-Core는 코드베이스를 읽고, 발견한 모든 패턴을 추출하
 
 ---
 
-## v2.1.0 신규 변경사항
-
-v2.1.0은 Pass 3를 재설계하여 중·대규모 프로젝트에서 발생하던 `Prompt is too long` 실패를 제거합니다. 이전에는 단일 Pass 3 호출이 전체 문서 트리(CLAUDE.md, rules, standards, skills, guides — 수십 개 파일)를 한 번에 출력해야 했고, 누적 출력이 5도메인 즈음부터 컨텍스트 윈도우를 초과했습니다. 이번 수정은 프롬프트 튜닝이 아니라 **구조적** 변경입니다:
-
-- **Pass 3 split 모드** (항상 활성) — Pass 3가 순차 `claude -p` 호출들로 분할됩니다 (`3a` → `3b-core` → `3b-N` → `3c-core` → `3c-N` → `3d-aux`). 각 스테이지는 **새 컨텍스트 윈도우**에서 시작하므로 프로젝트 크기와 무관하게 출력 누적 오버플로우가 구조적으로 불가능합니다.
-- **스테이지 간 팩트 시트** — `3a` 스테이지가 Pass 2 분석을 한 번만 읽고 5–10 KB의 `pass3a-facts.md`로 증류합니다. 이후 모든 스테이지는 100–500 KB의 `pass2-merged.json` 대신 이 팩트 시트를 참조하여, 새 컨텍스트 사이에서도 파일 간 일관성을 유지합니다.
-- **배치 하위 분할** (16도메인 이상에서 자동) — 3b/3c 스테이지가 15도메인 단위 배치로 추가 분할되어, 각 스테이지의 출력이 ~50 파일 이하로 제한됩니다. 18도메인 React 19 + Vite 6 admin 프론트엔드 실전 실행에서 **102분에 101파일 생성 / 8스테이지 / 오버플로우 0건** 완주를 확인했습니다 (실측 2026-04-20).
-- **Master plan 생성 제거** — `claudeos-core/plan/*-master.md` 파일은 더 이상 생성되지 않습니다. Master plan은 Claude Code가 런타임에 읽지 않는 내부 백업이었고, Pass 3d에서 이를 집계하는 것이 오버플로우 주요 원인이었습니다. 백업·복원은 `git`을 사용하세요.
-- **Pass 4 gap-fill: `skills/00.shared/MANIFEST.md`** — Pass 3c가 skill 레지스트리를 생성하지 못한 경우(skill-sparse 프로젝트), Pass 4가 스텁을 자동 생성하여 `.claude/rules/50.sync/03.skills-sync.md`가 존재하지 않는 파일을 가리키는 상황을 방지합니다.
-
-소소한 수정도 포함됩니다: `memory --help`가 이제 memory 서브커맨드 help를 표시합니다 (이전엔 top-level이 표시됨); `memory score`가 `importance` 라인을 중복 남기지 않습니다; `memory compact` summary 마커가 올바른 markdown 리스트 항목 형식입니다. 전체 내역: [CHANGELOG.md](./CHANGELOG.md).
-
----
-
 ## 왜 ClaudeOS-Core인가?
 
 다른 모든 Claude Code 도구는 이렇게 작동합니다:
@@ -591,24 +577,6 @@ Pass 3 split 모드는 도메인 수에 비례하여 스테이지 수가 증가
 
 Pass 4(메모리 스캐폴딩)는 Claude-driven 생성 또는 정적 폴백 중 어느 것이 실행되는지에 따라 ~30초–5분을 추가합니다. 멀티스택 프로젝트(예: Java + React)에서는 백엔드와 프론트엔드 도메인이 합산됩니다. 백엔드 6개 + 프론트엔드 4개 = 총 10개로 중규모 등급입니다.
 
-### 실전 프로덕션 케이스: 18도메인 admin 프론트엔드 (2026-04-20)
-
-18개 도메인과 6개 도메인 그룹을 가진 React 19 + Vite 6 + TypeScript admin 프론트엔드가 **102분에 101개 파일 생성**으로 end-to-end 완주했습니다. 스테이지별 내역:
-
-| 스테이지 | 파일 수 | 소요 시간 | 파일/분 |
-|---|---|---|---|
-| `3a` (팩트 추출) | 1 (`pass3a-facts.md`) | 8분 44초 | — |
-| `3b-core` (CLAUDE.md + 공통) | 24 | 22분 10초 | 1.1 |
-| `3b-1` (15도메인) | 30 | 10분 6초 | **3.0** |
-| `3b-2` (3도메인) | 6 | 4분 34초 | 1.3 |
-| `3c-core` (가이드 + 공유) | 11 | 8분 31초 | 1.3 |
-| `3c-1` (15도메인) | 8 | 5분 11초 | **1.5** |
-| `3c-2` (3도메인) | 3 | 3분 50초 | 0.8 |
-| `3d-aux` (database + mcp) | 3 | 2분 52초 | 1.0 |
-| Pass 4 | 12 | 5분 36초 | 2.1 |
-
-배치된 도메인 스테이지에서 처리량이 눈에 띄게 높습니다 (3b-1: 3.0 파일/분 vs. 3b-core: 1.1 파일/분). 이는 새 컨텍스트 스테이지가 도메인별로 반복 가능한 패턴을 유지하기 때문입니다. 검증 전부 green: `plan-validator`, `sync-checker`, `content-validator`, `pass-json-validator` — 오버플로우 0건, 트렁케이션 0건.
-
 ---
 
 ## 검증 도구
@@ -809,8 +777,7 @@ ClaudeOS-Core로 프로젝트 규칙을 생성한 뒤, ECC나 Harness를 그 위
 4 Pass에 걸쳐 `claude -p`를 여러 번 호출합니다. v2.1.0 split 모드에서는 Pass 3만 해도 프로젝트 크기에 따라 4–14+ 스테이지로 확장됩니다 (자세히는 [프로젝트 규모별 자동 스케일링](#프로젝트-규모별-자동-스케일링) 참조). 일반적으로 소규모 프로젝트(1–15 도메인)는 총 8–9회, 18 도메인 프로젝트는 11회, 60 도메인 프로젝트는 15–17회의 `claude -p` 호출을 사용합니다. 각 스테이지는 새 컨텍스트 윈도우에서 실행되므로 호출당 토큰 비용은 실제로 단일 호출 Pass 3보다 낮습니다 — 어떤 스테이지도 전체 파일 트리를 한 컨텍스트에 담지 않기 때문입니다. `--lang`이 비영어이면 정적 폴백 경로가 번역을 위해 추가로 몇 번 호출할 수 있지만, 결과는 `claudeos-core/generated/.i18n-cache-<lang>.json`에 캐시되어 이후 실행에서 재사용됩니다. 일반적인 Claude Code 사용량 내에서 처리됩니다.
 
 **Q: Pass 3 split 모드가 무엇이고 왜 v2.1.0에 추가됐나요?**
-v2.1.0 이전에는 Pass 3가 전체 생성 파일 트리(`CLAUDE.md`, standards, rules, skills, guides — 보통 30–60개 파일)를 한 응답에 출력해야 하는 단일 `claude -p` 호출이었습니다. 소규모 프로젝트에서는 동작했지만 ~5도메인부터 `Prompt is too long` 출력 누적 실패가 안정적으로 발생했습니다. 이 실패는 입력 크기로부터 예측 불가능 — 각 생성 파일이 얼마나 verbose한지에 따라 달라졌고, 같은 프로젝트에서도 간헐적으로 발생할 수 있었습니다. Split 모드는 이를 구조적으로 회피합니다: Pass 3가 순차 스테이지들(`3a` → `3b-core` → `3b-N` → `3c-core` → `3c-N` → `3d-aux`)로 분할되고, 각각은 새 컨텍스트 윈도우를 가진 별개의 `claude -p` 호출입니다. 스테이지 간 일관성은 `pass3a-facts.md`(5–10 KB 증류 팩트 시트)로 보존되며, 이후 모든 스테이지가 `pass2-merged.json` 재독 대신 이를 참조합니다. `pass3-complete.json` 마커는 `groupsCompleted` 배열을 가지므로 `3c-2`에서 크래시되어도 `3c-2`부터 재개되어(`3a`가 아니라) 토큰 비용 두 배 증가를 방지합니다. 18도메인 × 101파일 × 102분 실증 — [프로젝트 규모별 자동 스케일링](#프로젝트-규모별-자동-스케일링)에서 실측 내역 참조.
-
+v2.1.0 이전에는 Pass 3가 전체 생성 파일 트리(`CLAUDE.md`, standards, rules, skills, guides — 보통 30–60개 파일)를 한 응답에 출력해야 하는 단일 `claude -p` 호출이었습니다. 소규모 프로젝트에서는 동작했지만 ~5도메인부터 `Prompt is too long` 출력 누적 실패가 안정적으로 발생했습니다. 이 실패는 입력 크기로부터 예측 불가능 — 각 생성 파일이 얼마나 verbose한지에 따라 달라졌고, 같은 프로젝트에서도 간헐적으로 발생할 수 있었습니다. Split 모드는 이를 구조적으로 회피합니다: Pass 3가 순차 스테이지들(`3a` → `3b-core` → `3b-N` → `3c-core` → `3c-N` → `3d-aux`)로 분할되고, 각각은 새 컨텍스트 윈도우를 가진 별개의 `claude -p` 호출입니다. 스테이지 간 일관성은 `pass3a-facts.md`(5–10 KB 증류 팩트 시트)로 보존되며, 이후 모든 스테이지가 `pass2-merged.json` 재독 대신 이를 참조합니다. `pass3-complete.json` 마커는 `groupsCompleted` 배열을 가지므로 `3c-2`에서 크래시되어도 `3c-2`부터 재개되어(`3a`가 아니라) 토큰 비용 두 배 증가를 방지합니다.
 **Q: 생성된 파일을 Git에 커밋해야 하나요?**
 네, 권장합니다. 팀원 전체가 동일한 Claude Code 표준을 공유할 수 있습니다. `claudeos-core/generated/`는 `.gitignore`에 추가하는 것을 권장합니다 (분석 JSON은 재생성 가능).
 
@@ -950,10 +917,10 @@ my-monorepo/                    ← 여기서 실행: npx claudeos-core init
 
 **"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-only 또는 공백만 있는 파일에서도 발동 (헤딩은 작성됐으나 본문이 잘림). 이 가드 없으면 완료 마커가 작성되어 이후 실행에서 `guide/`가 영구히 비어 있음. 마커 미작성이므로 다음 `init` 실행이 동일 Pass 2 결과에서 Pass 3 재시도. 계속 반복되면 `npx claudeos-core init --force`로 처음부터 재생성.
 
-**"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/`에 ≥1 비어있지 않은 `.md`. `database/`와 `mcp-guide/`는 의도적으로 제외 (일부 스택은 정당하게 0 파일 생성). v2.1.0부터 `plan/`은 검사하지 않음 (master plan 제거됨). Guard 3 (H2)와 동일 복구 경로: `init` 재실행, 지속되면 `--force`.
-
-**"Pass 3 split 스테이지가 중간에 크래시됨 (v2.1.0)"** — split 스테이지 중 하나(예: `3b-1`, `3c-2`)가 실행 중 실패하면 해당 스테이지 마커는 작성되지 **않지만**, 완료된 스테이지는 `pass3-complete.json.groupsCompleted`에 기록**됩니다**. 다음 `init` 실행이 이 배열을 읽고 첫 미완료 스테이지부터 재개하며, 이전 완료 작업을 스킵합니다. 수동 조치 불필요 — 그냥 `npx claudeos-core init`을 재실행하세요. 같은 스테이지에서 재개가 계속 실패하면 `claudeos-core/generated/pass3-prompt.md`를 검사하여 malformed content가 있는지 확인 후 전체 재시작을 위해 `--force`를 시도하세요. `pass3-complete.json` 형식(`mode: "split"`, `groupsCompleted: [...]`)은 안정적 — 마커가 없거나 malformed이면 전체 Pass 3가 `3a`부터 재실행됩니다.
-
+**"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/`에 ≥1 비어있지 않은 `.md`. `database/`와 `mcp-guide/`는 의도적으로 제외 (일부 스택은 정당하게 0 파일 생성). v2.1.0부터 `plan/`은 검사하지 않음 (master plan 제거됨). Guard 3 (H2)와 동일 복구 경로: `init` 재실행, 지속되면 `--force`.
+
+**"Pass 3 split 스테이지가 중간에 크래시됨 (v2.1.0)"** — split 스테이지 중 하나(예: `3b-1`, `3c-2`)가 실행 중 실패하면 해당 스테이지 마커는 작성되지 **않지만**, 완료된 스테이지는 `pass3-complete.json.groupsCompleted`에 기록**됩니다**. 다음 `init` 실행이 이 배열을 읽고 첫 미완료 스테이지부터 재개하며, 이전 완료 작업을 스킵합니다. 수동 조치 불필요 — 그냥 `npx claudeos-core init`을 재실행하세요. 같은 스테이지에서 재개가 계속 실패하면 `claudeos-core/generated/pass3-prompt.md`를 검사하여 malformed content가 있는지 확인 후 전체 재시작을 위해 `--force`를 시도하세요. `pass3-complete.json` 형식(`mode: "split"`, `groupsCompleted: [...]`)은 안정적 — 마커가 없거나 malformed이면 전체 Pass 3가 `3a`부터 재실행됩니다.
+
 **"Pass 3 stale 마커 (형식 불일치) — incomplete로 처리" (v2.1.0)** — v2.1.0 이전의 단일 호출 실행에서 생성된 `pass3-complete.json`이 새 split 모드 규칙으로 해석되고 있습니다. 형식 체크가 `mode: "split"`와 `groupsCompleted` 배열을 찾으며, 둘 중 하나라도 없으면 마커를 partial로 간주하고 Pass 3가 split 모드로 재실행됩니다. v2.0.x에서 업그레이드했다면 한 번 예상되는 동작 — 다음 실행이 올바른 마커 형식을 작성합니다. 조치 불필요.
 
 **"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` 임계값 미러링). 이전 크래시 실행에서 남은 skeleton `{}` 또는 malformed JSON은 자동 삭제되고 Pass 2 재실행. 수동 조치 불필요 — 파이프라인 자가 치유. 계속 반복되면 `claudeos-core/generated/pass2-prompt.md` 검사 후 `--force`로 재시도.

package/README.md

@@ -12,20 +12,6 @@ ClaudeOS-Core reads your codebase, extracts every pattern it finds, and generate
 
 ---
 
-## What's New in v2.1.0
-
-v2.1.0 re-architects Pass 3 to eliminate `Prompt is too long` failures on medium-to-large projects. Previously, a single Pass 3 call had to emit the entire documentation tree at once — dozens of files across `CLAUDE.md`, rules, standards, skills, and guides — and the accumulated output reliably exceeded the context window past ~5 domains. The fix is structural, not a prompt tweak:
-
-- **Pass 3 split mode** (always on) — Pass 3 is broken into sequential `claude -p` calls (`3a` → `3b-core` → `3b-N` → `3c-core` → `3c-N` → `3d-aux`). Each stage starts with a **fresh context window**, so output-accumulation overflow is no longer possible regardless of project size.
-- **Fact sheet between stages** — Stage `3a` reads the Pass 2 analysis once and distills it into a 5–10 KB `pass3a-facts.md`. All later stages reference that fact sheet instead of re-reading the 100–500 KB `pass2-merged.json`, preserving cross-file consistency across fresh contexts.
-- **Batch sub-division** (automatic at ≥16 domains) — Stages 3b/3c are further split into batches of 15 domains each, keeping each stage under ~50 files of output. An 18-domain React 19 + Vite 6 admin frontend completes in **102 minutes with 101 files generated across 8 stages, zero overflow failures** (real production run, 2026-04-20).
-- **Master plan generation removed** — `claudeos-core/plan/*-master.md` files are no longer generated. Master plans were an internal backup not consumed by Claude Code at runtime, and aggregating them in Pass 3d was a primary overflow trigger. Use `git` for backup/restore instead.
-- **Pass 4 gap-fill: `skills/00.shared/MANIFEST.md`** — If Pass 3c omits the skill registry (skill-sparse projects), Pass 4 now auto-creates a stub so `.claude/rules/50.sync/03.skills-sync.md` never points at a dangling file.
-
-A few smaller fixes: `memory --help` now shows the memory subcommand help (previously top-level was shown); `memory score` no longer leaves duplicate `importance` lines; `memory compact` summary markers are proper markdown list items. Full details: [CHANGELOG.md](./CHANGELOG.md).
-
----
-
 ## Why ClaudeOS-Core?
 
 Every other Claude Code tool works like this:
@@ -591,24 +577,6 @@ Stage count formula (when batched): `1 (3a) + 1 (3b-core) + N (3b-1..N) + 1 (3c-
 
 Pass 4 (memory scaffolding) adds ~30 seconds to 5 minutes on top depending on whether Claude-driven generation or static fallback runs. For multi-stack projects (e.g., Java + React), backend and frontend domains are counted together. A project with 6 backend + 4 frontend domains = 10 total = Medium tier.
 
-### Real production case: 18-domain admin frontend (2026-04-20)
-
-A React 19 + Vite 6 + TypeScript admin frontend with 18 domains and 6 domain groups completed end-to-end in **102 minutes with 101 files generated**. Stage breakdown:
-
-| Stage | Files | Time | Files/min |
-|---|---|---|---|
-| `3a` (fact extraction) | 1 (`pass3a-facts.md`) | 8m 44s | — |
-| `3b-core` (CLAUDE.md + common) | 24 | 22m 10s | 1.1 |
-| `3b-1` (15 domains) | 30 | 10m 6s | **3.0** |
-| `3b-2` (3 domains) | 6 | 4m 34s | 1.3 |
-| `3c-core` (guides + shared) | 11 | 8m 31s | 1.3 |
-| `3c-1` (15 domains) | 8 | 5m 11s | **1.5** |
-| `3c-2` (3 domains) | 3 | 3m 50s | 0.8 |
-| `3d-aux` (database + mcp) | 3 | 2m 52s | 1.0 |
-| Pass 4 | 12 | 5m 36s | 2.1 |
-
-Throughput is noticeably higher on the batched domain stages (3b-1: 3.0 files/min vs. 3b-core: 1.1 files/min) because fresh-context stages benefit from tight, repeatable per-domain patterns. Verification all-green: `plan-validator`, `sync-checker`, `content-validator`, `pass-json-validator` — zero overflow failures, zero truncation.
-
 ---
 
 ## Verification Tools
@@ -810,8 +778,7 @@ No. It only creates `CLAUDE.md`, `.claude/rules/`, and `claudeos-core/`. Your ex
 It calls `claude -p` several times across 4 passes. In v2.1.0 split mode, Pass 3 alone expands into 4–14+ stages depending on project size (see [Auto-scaling](#auto-scaling-by-project-size)). A typical small project (1–15 domains) uses 8–9 `claude -p` calls total; an 18-domain project uses 11; a 60-domain project uses 15–17. Each stage runs with a fresh context window — the per-call token cost is actually lower than single-call Pass 3 was, because no stage has to hold the entire file tree in one context. When `--lang` is non-English, the static fallback path may invoke a few additional `claude -p` calls for translation; results are cached in `claudeos-core/generated/.i18n-cache-<lang>.json` so subsequent runs reuse them. This is within normal Claude Code usage.
 
 **Q: What is Pass 3 split mode and why was it added in v2.1.0?**
-Before v2.1.0, Pass 3 made a single `claude -p` call that had to emit the entire generated file tree (`CLAUDE.md`, standards, rules, skills, guides — typically 30–60 files) in one response. This worked on small projects but reliably hit `Prompt is too long` output-accumulation failures at ~5 domains. The failure was not predictable from input size — it depended on how verbose each generated file happened to be, and could strike the same project intermittently. Split mode sidesteps the problem structurally: Pass 3 is broken into sequential stages (`3a` → `3b-core` → `3b-N` → `3c-core` → `3c-N` → `3d-aux`), each a separate `claude -p` call with a fresh context window. Cross-stage consistency is preserved by `pass3a-facts.md`, a 5–10 KB distilled fact sheet that every later stage references instead of re-reading `pass2-merged.json`. The `pass3-complete.json` marker carries a `groupsCompleted` array so a crash during `3c-2` resumes from `3c-2` (not from `3a`), avoiding double token cost. Empirically verified up to 18 domains × 101 files × 102 minutes with zero overflow — see [Auto-scaling](#auto-scaling-by-project-size) for the real production breakdown.
-
+Before v2.1.0, Pass 3 made a single `claude -p` call that had to emit the entire generated file tree (`CLAUDE.md`, standards, rules, skills, guides — typically 30–60 files) in one response. This worked on small projects but reliably hit `Prompt is too long` output-accumulation failures at ~5 domains. The failure was not predictable from input size — it depended on how verbose each generated file happened to be, and could strike the same project intermittently. Split mode sidesteps the problem structurally: Pass 3 is broken into sequential stages (`3a` → `3b-core` → `3b-N` → `3c-core` → `3c-N` → `3d-aux`), each a separate `claude -p` call with a fresh context window. Cross-stage consistency is preserved by `pass3a-facts.md`, a 5–10 KB distilled fact sheet that every later stage references instead of re-reading `pass2-merged.json`. The `pass3-complete.json` marker carries a `groupsCompleted` array so a crash during `3c-2` resumes from `3c-2` (not from `3a`), avoiding double token cost.
 **Q: Should I commit the generated files to Git?**
 Yes, recommended. Your team can share the same Claude Code standards. Consider adding `claudeos-core/generated/` to `.gitignore` (analysis JSON is regeneratable).
 
@@ -951,10 +918,10 @@ my-monorepo/                    ← Run here: npx claudeos-core init
 
 **"Pass 3 produced CLAUDE.md and rules but N/9 guide files are missing or empty" (v2.0.0)** — Guard 3 (H2) fired: Claude truncated mid-response after writing CLAUDE.md + rules but before finishing (or starting) the `claudeos-core/guide/` section (9 files expected). Also fires on a BOM-only or whitespace-only file (heading was written but the body was truncated). Without this guard the completion marker would still be written, leaving `guide/` permanently empty on subsequent runs. The marker is NOT written here, so the next `init` run retries Pass 3 from the same Pass 2 results. If it keeps repeating, re-run with `npx claudeos-core init --force` to regenerate from scratch.
 
-**"Pass 3 finished but the following required output(s) are missing or empty" (v2.0.0, updated v2.1.0)** — Guard 3 (H1) fired: Claude truncated AFTER `claudeos-core/guide/` but before (or during) `claudeos-core/standard/` or `claudeos-core/skills/`. Requirements: (a) `standard/00.core/01.project-overview.md` exists and is non-empty (sentinel written by every stack's Pass 3 prompt), (b) `skills/` has ≥1 non-empty `.md`. `database/` and `mcp-guide/` are intentionally excluded (some stacks legitimately produce zero files). `plan/` is no longer checked as of v2.1.0 (master plans were removed). Same recovery path as Guard 3 (H2): re-run `init`, or `--force` if it persists.
-
-**"Pass 3 split stage crashed partway through (v2.1.0)"** — When one of the split stages (e.g., `3b-1`, `3c-2`) fails mid-run, the stage-level marker is NOT written, but completed stages ARE recorded in `pass3-complete.json.groupsCompleted`. The next `init` run reads this array and resumes from the first uncompleted stage, skipping all earlier completed work. You don't need to do anything manually — just re-run `npx claudeos-core init`. If resume keeps failing at the same stage, inspect `claudeos-core/generated/pass3-prompt.md` for malformed content, then try `--force` for a full restart. The `pass3-complete.json` shape (`mode: "split"`, `groupsCompleted: [...]`) is stable; a missing or malformed marker causes the full Pass 3 to re-run from `3a`.
-
+**"Pass 3 finished but the following required output(s) are missing or empty" (v2.0.0, updated v2.1.0)** — Guard 3 (H1) fired: Claude truncated AFTER `claudeos-core/guide/` but before (or during) `claudeos-core/standard/` or `claudeos-core/skills/`. Requirements: (a) `standard/00.core/01.project-overview.md` exists and is non-empty (sentinel written by every stack's Pass 3 prompt), (b) `skills/` has ≥1 non-empty `.md`. `database/` and `mcp-guide/` are intentionally excluded (some stacks legitimately produce zero files). `plan/` is no longer checked as of v2.1.0 (master plans were removed). Same recovery path as Guard 3 (H2): re-run `init`, or `--force` if it persists.
+
+**"Pass 3 split stage crashed partway through (v2.1.0)"** — When one of the split stages (e.g., `3b-1`, `3c-2`) fails mid-run, the stage-level marker is NOT written, but completed stages ARE recorded in `pass3-complete.json.groupsCompleted`. The next `init` run reads this array and resumes from the first uncompleted stage, skipping all earlier completed work. You don't need to do anything manually — just re-run `npx claudeos-core init`. If resume keeps failing at the same stage, inspect `claudeos-core/generated/pass3-prompt.md` for malformed content, then try `--force` for a full restart. The `pass3-complete.json` shape (`mode: "split"`, `groupsCompleted: [...]`) is stable; a missing or malformed marker causes the full Pass 3 to re-run from `3a`.
+
 **"Pass 3 stale marker (shape mismatch) — treating as incomplete" (v2.1.0)** — A `pass3-complete.json` from a pre-v2.1.0 single-call run is being interpreted under the new split-mode rules. The shape check looks for `mode: "split"` and a `groupsCompleted` array; if either is missing, the marker is treated as partial and Pass 3 re-runs in split mode. If you upgraded from v2.0.x, this is expected once — the next run will write the correct marker shape. No action needed.
 
 **"pass2-merged.json exists but is malformed or incomplete (<5 top-level keys), re-running" (v2.0.0)** — Info log, not an error. On resume, `init` now parses and validates `pass2-merged.json` (≥5 top-level keys required, mirroring `pass-json-validator`'s `INSUFFICIENT_KEYS` threshold). Skeleton `{}` or malformed JSON from a prior crashed run is automatically deleted and Pass 2 re-runs. No manual action needed — the pipeline self-heals. If it keeps recurring, inspect `claudeos-core/generated/pass2-prompt.md` and retry with `--force`.

package/README.ru.md

@@ -12,20 +12,6 @@ ClaudeOS-Core читает вашу кодовую базу, извлекает
 
 ---
 
-## Что нового в v2.1.0
-
-v2.1.0 переархитектурирует Pass 3, чтобы устранить отказы `Prompt is too long` на средних и крупных проектах. Раньше единственный вызов Pass 3 должен был выдать всё дерево документации за раз — десятки файлов в `CLAUDE.md`, rules, standards, skills и guides — и накопленный вывод стабильно превышал context window после ~5 доменов. Исправление — структурное, а не настройка промпта:
-
-- **Pass 3 split-режим** (всегда включён) — Pass 3 разбивается на последовательные вызовы `claude -p` (`3a` → `3b-core` → `3b-N` → `3c-core` → `3c-N` → `3d-aux`). Каждая стадия стартует с **свежим context window**, поэтому переполнение из-за накопления вывода структурно невозможно независимо от размера проекта.
-- **Фактологический лист между стадиями** — Стадия `3a` один раз читает анализ Pass 2 и дистиллирует его в `pass3a-facts.md` размером 5–10 KB. Все последующие стадии ссылаются на этот fact sheet вместо повторного чтения 100–500 KB `pass2-merged.json`, что сохраняет межфайловую согласованность даже при свежих контекстах.
-- **Разбиение на батчи** (автоматически при ≥16 доменов) — Стадии 3b/3c дополнительно делятся на батчи по 15 доменов, удерживая вывод каждой стадии под ~50 файлами. 18-доменный admin-фронтенд на React 19 + Vite 6 завершается за **102 минуты со 101 сгенерированным файлом по 8 стадиям и нулевыми отказами переполнения** (реальный production-прогон, 2026-04-20).
-- **Генерация master plan удалена** — Файлы `claudeos-core/plan/*-master.md` больше не генерируются. Master plans были внутренним бэкапом, который Claude Code не читал в рантайме, и их агрегация в Pass 3d была основным триггером переполнения. Используйте `git` для бэкапа/восстановления.
-- **Pass 4 gap-fill: `skills/00.shared/MANIFEST.md`** — Если Pass 3c пропускает skill-реестр (проекты с малым количеством skills), Pass 4 теперь автоматически создаёт заглушку, чтобы `.claude/rules/50.sync/03.skills-sync.md` никогда не ссылался на несуществующий файл.
-
-Несколько более мелких фиксов: `memory --help` теперь показывает справку подкоманды memory (раньше показывался top-level); `memory score` больше не оставляет дублирующие строки `importance`; маркеры summary в `memory compact` теперь корректные markdown-элементы списка. Полные детали: [CHANGELOG.md](./CHANGELOG.md).
-
----
-
 ## Почему ClaudeOS-Core?
 
 Любой другой инструмент для Claude Code работает так:
@@ -591,24 +577,6 @@ Split-режим Pass 3 масштабирует количество стади
 
 Pass 4 (memory scaffolding) добавляет от ~30 секунд до 5 минут сверху, в зависимости от того, запускается ли Claude-driven генерация или статический фолбэк. Для мульти-стек проектов (например, Java + React) backend- и frontend-домены считаются вместе. Проект с 6 backend + 4 frontend доменами = 10 суммарно = уровень «Средний».
 
-### Реальный production-кейс: 18-доменный admin-фронтенд (2026-04-20)
-
-Admin-фронтенд на React 19 + Vite 6 + TypeScript с 18 доменами и 6 доменными группами завершился end-to-end за **102 минуты со 101 сгенерированным файлом**. Разбивка по стадиям:
-
-| Стадия | Файлы | Время | Файлов/мин |
-|---|---|---|---|
-| `3a` (извлечение фактов) | 1 (`pass3a-facts.md`) | 8м 44с | — |
-| `3b-core` (CLAUDE.md + общее) | 24 | 22м 10с | 1.1 |
-| `3b-1` (15 доменов) | 30 | 10м 6с | **3.0** |
-| `3b-2` (3 домена) | 6 | 4м 34с | 1.3 |
-| `3c-core` (гайды + общее) | 11 | 8м 31с | 1.3 |
-| `3c-1` (15 доменов) | 8 | 5м 11с | **1.5** |
-| `3c-2` (3 домена) | 3 | 3м 50с | 0.8 |
-| `3d-aux` (database + mcp) | 3 | 2м 52с | 1.0 |
-| Pass 4 | 12 | 5м 36с | 2.1 |
-
-Пропускная способность заметно выше на доменных батчевых стадиях (3b-1: 3.0 файлов/мин vs. 3b-core: 1.1 файлов/мин), потому что стадии со свежим контекстом выигрывают от компактных повторяющихся per-domain паттернов. Верификация вся зелёная: `plan-validator`, `sync-checker`, `content-validator`, `pass-json-validator` — ноль отказов переполнения, ноль усечений.
-
 ---
 
 ## Инструменты верификации
@@ -810,8 +778,7 @@ ClaudeOS-Core фокусируется на **проектно-специфич
 Он вызывает `claude -p` несколько раз на протяжении 4 проходов. В split-режиме v2.1.0 только Pass 3 разворачивается в 4–14+ стадий в зависимости от размера проекта (см. [Автомасштабирование](#автомасштабирование-по-размеру-проекта)). Типичный малый проект (1–15 доменов) использует в сумме 8–9 вызовов `claude -p`; 18-доменный проект использует 11; 60-доменный проект использует 15–17. Каждая стадия запускается со свежим context window — per-call стоимость токенов в действительности ниже, чем была у single-call Pass 3, потому что ни одна стадия не должна удерживать всё дерево файлов в одном контексте. Когда `--lang` не английский, путь статического фолбэка может вызвать несколько дополнительных `claude -p` для перевода; результаты кэшируются в `claudeos-core/generated/.i18n-cache-<lang>.json`, так что последующие запуски их переиспользуют. Это в пределах нормального использования Claude Code.
 
 **В: Что такое Pass 3 split-режим и зачем он был добавлен в v2.1.0?**
-До v2.1.0 Pass 3 делал один вызов `claude -p`, который должен был выдать всё сгенерированное дерево файлов (`CLAUDE.md`, стандарты, правила, skills, гайды — обычно 30–60 файлов) в одном ответе. Это работало на малых проектах, но стабильно падало с ошибкой `Prompt is too long` (переполнение из-за накопления вывода) около 5 доменов. Отказ не был предсказуем по размеру входа — он зависел от того, насколько многословным оказался каждый сгенерированный файл, и мог случаться на одном и том же проекте эпизодически. Split-режим структурно обходит проблему: Pass 3 разбивается на последовательные стадии (`3a` → `3b-core` → `3b-N` → `3c-core` → `3c-N` → `3d-aux`), каждая из которых — отдельный вызов `claude -p` со свежим context window. Кросс-стейджевая согласованность сохраняется через `pass3a-facts.md` — дистиллированный fact sheet размером 5–10 KB, на который ссылается каждая последующая стадия вместо повторного чтения `pass2-merged.json`. Маркер `pass3-complete.json` несёт массив `groupsCompleted`, так что краш во время `3c-2` возобновляется с `3c-2` (а не с `3a`), избегая двойного расхода токенов. Эмпирически проверено до 18 доменов × 101 файл × 102 минут с нулевыми переполнениями — см. [Автомасштабирование](#автомасштабирование-по-размеру-проекта) для реальной production-разбивки.
-
+До v2.1.0 Pass 3 делал один вызов `claude -p`, который должен был выдать всё сгенерированное дерево файлов (`CLAUDE.md`, стандарты, правила, skills, гайды — обычно 30–60 файлов) в одном ответе. Это работало на малых проектах, но стабильно падало с ошибкой `Prompt is too long` (переполнение из-за накопления вывода) около 5 доменов. Отказ не был предсказуем по размеру входа — он зависел от того, насколько многословным оказался каждый сгенерированный файл, и мог случаться на одном и том же проекте эпизодически. Split-режим структурно обходит проблему: Pass 3 разбивается на последовательные стадии (`3a` → `3b-core` → `3b-N` → `3c-core` → `3c-N` → `3d-aux`), каждая из которых — отдельный вызов `claude -p` со свежим context window. Кросс-стейджевая согласованность сохраняется через `pass3a-facts.md` — дистиллированный fact sheet размером 5–10 KB, на который ссылается каждая последующая стадия вместо повторного чтения `pass2-merged.json`. Маркер `pass3-complete.json` несёт массив `groupsCompleted`, так что краш во время `3c-2` возобновляется с `3c-2` (а не с `3a`), избегая двойного расхода токенов.
 **В: Стоит ли коммитить сгенерированные файлы в Git?**
 Да, рекомендуется. Ваша команда может использовать одинаковые стандарты Claude Code. Подумайте о добавлении `claudeos-core/generated/` в `.gitignore` (JSON анализа регенерируется).
 

package/README.vi.md

@@ -12,20 +12,6 @@ ClaudeOS-Core đọc codebase của bạn, trích xuất mọi pattern tìm th
 
 ---
 
-## Có Gì Mới Trong v2.1.0
-
-v2.1.0 tái kiến trúc Pass 3 để loại bỏ lỗi `Prompt is too long` trên các dự án cỡ trung bình đến lớn. Trước đây, một lời gọi Pass 3 đơn lẻ phải phát ra toàn bộ cây tài liệu cùng lúc — hàng chục file trải dài qua `CLAUDE.md`, rules, standards, skills và guides — và output tích lũy luôn vượt context window khi vượt quá ~5 domain. Fix này mang tính **cấu trúc**, không phải tinh chỉnh prompt:
-
-- **Pass 3 split mode** (luôn bật) — Pass 3 được tách thành các lời gọi `claude -p` tuần tự (`3a` → `3b-core` → `3b-N` → `3c-core` → `3c-N` → `3d-aux`). Mỗi stage bắt đầu với **context window mới**, nên tràn output do tích lũy không còn khả thi bất kể kích thước dự án.
-- **Fact sheet giữa các stage** — Stage `3a` đọc kết quả phân tích Pass 2 một lần và chắt lọc thành `pass3a-facts.md` kích thước 5–10 KB. Tất cả stage sau tham chiếu fact sheet này thay vì đọc lại `pass2-merged.json` 100–500 KB, giữ tính nhất quán xuyên file qua các context mới.
-- **Chia batch tự động** (tự động ở ≥16 domain) — Stage 3b/3c được chia thêm thành các batch 15 domain mỗi cái, giữ output của mỗi stage dưới ~50 file. Admin frontend React 19 + Vite 6 với 18 domain hoàn thành trong **102 phút với 101 file được tạo qua 8 stage, 0 lỗi tràn output** (chạy thực tế production, 2026-04-20).
-- **Loại bỏ tạo master plan** — Các file `claudeos-core/plan/*-master.md` không còn được tạo nữa. Master plan là backup nội bộ mà Claude Code không đọc lúc runtime, và việc tổng hợp chúng trong Pass 3d là nguyên nhân tràn chính. Dùng `git` để backup/restore thay thế.
-- **Pass 4 gap-fill: `skills/00.shared/MANIFEST.md`** — Nếu Pass 3c bỏ sót skill registry (dự án ít skill), Pass 4 giờ tự động tạo stub để `.claude/rules/50.sync/03.skills-sync.md` không bao giờ trỏ tới file không tồn tại.
-
-Một vài fix nhỏ: `memory --help` giờ hiển thị help của subcommand memory (trước đây hiển thị top-level); `memory score` không còn để lại các dòng `importance` trùng lặp; marker summary của `memory compact` giờ là markdown list item đúng định dạng. Chi tiết đầy đủ: [CHANGELOG.md](./CHANGELOG.md).
-
----
-
 ## Tại sao chọn ClaudeOS-Core?
 
 Mọi công cụ Claude Code khác hoạt động như sau:
@@ -591,24 +577,6 @@ Công thức số stage (khi chia batch): `1 (3a) + 1 (3b-core) + N (3b-1..N) +
 
 Pass 4 (memory scaffolding) thêm khoảng ~30 giây đến 5 phút lên trên tùy thuộc vào việc chạy tạo qua Claude hay fallback tĩnh. Với dự án multi-stack (ví dụ Java + React), domain backend và frontend được đếm cộng lại. Dự án 6 backend + 4 frontend = 10 tổng = tier Vừa.
 
-### Thực tế production: admin frontend 18 domain (2026-04-20)
-
-Một admin frontend React 19 + Vite 6 + TypeScript với 18 domain và 6 domain group hoàn thành end-to-end trong **102 phút với 101 file được tạo**. Phân bổ stage:
-
-| Stage | File | Thời gian | File/phút |
-|---|---|---|---|
-| `3a` (trích xuất fact) | 1 (`pass3a-facts.md`) | 8m 44s | — |
-| `3b-core` (CLAUDE.md + chung) | 24 | 22m 10s | 1.1 |
-| `3b-1` (15 domain) | 30 | 10m 6s | **3.0** |
-| `3b-2` (3 domain) | 6 | 4m 34s | 1.3 |
-| `3c-core` (guide + chung) | 11 | 8m 31s | 1.3 |
-| `3c-1` (15 domain) | 8 | 5m 11s | **1.5** |
-| `3c-2` (3 domain) | 3 | 3m 50s | 0.8 |
-| `3d-aux` (database + mcp) | 3 | 2m 52s | 1.0 |
-| Pass 4 | 12 | 5m 36s | 2.1 |
-
-Throughput cao rõ rệt ở các stage domain theo batch (3b-1: 3.0 file/phút vs. 3b-core: 1.1 file/phút) vì các stage context mới được hưởng lợi từ các pattern chặt chẽ, lặp lại cho từng domain. Xác minh toàn xanh: `plan-validator`, `sync-checker`, `content-validator`, `pass-json-validator` — 0 lỗi tràn, 0 file bị cắt.
-
 ---
 
 ## Công Cụ Xác Minh
@@ -810,8 +778,7 @@ Không. Nó chỉ tạo `CLAUDE.md`, `.claude/rules/`, và `claudeos-core/`. Cod
 Nó gọi `claude -p` vài lần qua 4 pass. Ở split mode v2.1.0, chỉ riêng Pass 3 đã mở rộng thành 4–14+ stage tùy theo kích thước dự án (xem [Tự Động Mở Rộng](#tự-động-mở-rộng-theo-kích-thước-dự-án)). Một dự án nhỏ điển hình (1–15 domain) dùng tổng cộng 8–9 lời gọi `claude -p`; dự án 18 domain dùng 11; dự án 60 domain dùng 15–17. Mỗi stage chạy với context window mới — chi phí token mỗi lời gọi thực ra thấp hơn Pass 3 lời-gọi-đơn, vì không stage nào phải giữ toàn bộ cây file trong một context. Khi `--lang` khác tiếng Anh, đường fallback tĩnh có thể gọi thêm vài `claude -p` để dịch; kết quả được cache trong `claudeos-core/generated/.i18n-cache-<lang>.json` nên các lần chạy sau dùng lại. Vẫn nằm trong mức sử dụng Claude Code bình thường.
 
 **Q: Pass 3 split mode là gì và tại sao được thêm ở v2.1.0?**
-Trước v2.1.0, Pass 3 thực hiện một lời gọi `claude -p` đơn phải phát ra toàn bộ cây file được tạo (`CLAUDE.md`, standards, rules, skills, guides — thường 30–60 file) trong một response. Điều này hoạt động trên dự án nhỏ nhưng luôn gặp lỗi `Prompt is too long` do tích lũy output ở ~5 domain. Lỗi không thể dự đoán từ kích thước input — nó phụ thuộc vào mức độ dài dòng của mỗi file được tạo, và có thể ập đến cùng một dự án một cách không ổn định. Split mode né vấn đề này về cấu trúc: Pass 3 được chia thành các stage tuần tự (`3a` → `3b-core` → `3b-N` → `3c-core` → `3c-N` → `3d-aux`), mỗi cái là một lời gọi `claude -p` riêng với context window mới. Tính nhất quán xuyên stage được bảo tồn bởi `pass3a-facts.md`, fact sheet đã chắt lọc 5–10 KB mà mọi stage sau tham chiếu thay vì đọc lại `pass2-merged.json`. Marker `pass3-complete.json` mang mảng `groupsCompleted` để crash trong `3c-2` resume từ `3c-2` (không phải từ `3a`), tránh chi phí token gấp đôi. Đã xác minh thực nghiệm lên tới 18 domain × 101 file × 102 phút với 0 tràn — xem [Tự Động Mở Rộng](#tự-động-mở-rộng-theo-kích-thước-dự-án) cho phân tích production thực tế.
-
+Trước v2.1.0, Pass 3 thực hiện một lời gọi `claude -p` đơn phải phát ra toàn bộ cây file được tạo (`CLAUDE.md`, standards, rules, skills, guides — thường 30–60 file) trong một response. Điều này hoạt động trên dự án nhỏ nhưng luôn gặp lỗi `Prompt is too long` do tích lũy output ở ~5 domain. Lỗi không thể dự đoán từ kích thước input — nó phụ thuộc vào mức độ dài dòng của mỗi file được tạo, và có thể ập đến cùng một dự án một cách không ổn định. Split mode né vấn đề này về cấu trúc: Pass 3 được chia thành các stage tuần tự (`3a` → `3b-core` → `3b-N` → `3c-core` → `3c-N` → `3d-aux`), mỗi cái là một lời gọi `claude -p` riêng với context window mới. Tính nhất quán xuyên stage được bảo tồn bởi `pass3a-facts.md`, fact sheet đã chắt lọc 5–10 KB mà mọi stage sau tham chiếu thay vì đọc lại `pass2-merged.json`. Marker `pass3-complete.json` mang mảng `groupsCompleted` để crash trong `3c-2` resume từ `3c-2` (không phải từ `3a`), tránh chi phí token gấp đôi.
 **Q: Tôi có nên commit các file được tạo vào Git không?**
 Có, khuyến nghị. Team của bạn có thể chia sẻ cùng standard Claude Code. Hãy xem xét thêm `claudeos-core/generated/` vào `.gitignore` (JSON phân tích có thể tạo lại).
 

package/README.zh-CN.md

@@ -12,20 +12,6 @@ ClaudeOS-Core 读取你的代码库，提取所发现的每一个模式，生成
 
 ---
 
-## v2.1.0 新增内容
-
-v2.1.0 重新设计了 Pass 3，消除了中大型项目上出现的 `Prompt is too long` 失败。在此之前，单次 Pass 3 调用必须一次性输出整个文档树 — 分布在 `CLAUDE.md`、rules、standards、skills 和 guides 中的数十个文件 — 累积输出在约 5 个领域以上时可靠地超出上下文窗口。这次修复是**结构性的**，而不是提示词微调：
-
-- **Pass 3 split 模式**（始终启用）— Pass 3 被拆分为顺序执行的 `claude -p` 调用（`3a` → `3b-core` → `3b-N` → `3c-core` → `3c-N` → `3d-aux`）。每个阶段都以**全新的上下文窗口**开始，因此无论项目规模如何，输出累积溢出在结构上都不再可能发生。
-- **阶段间事实表** — `3a` 阶段读取一次 Pass 2 分析，并将其蒸馏为 5–10 KB 的 `pass3a-facts.md`。之后的所有阶段都引用该事实表，而不是重新读取 100–500 KB 的 `pass2-merged.json`，从而在新上下文之间保留跨文件一致性。
-- **批次子分割**（≥16 领域时自动）— 3b/3c 阶段进一步按每批 15 个领域进行分割，使每个阶段的输出保持在 ~50 个文件以内。一个 18 领域的 React 19 + Vite 6 admin 前端在**102 分钟内生成 101 个文件，跨 8 个阶段，零溢出失败**（实测生产运行，2026-04-20）。
-- **Master plan 生成移除** — `claudeos-core/plan/*-master.md` 文件不再生成。Master plan 是 Claude Code 在运行时不消费的内部备份，而在 Pass 3d 中聚合这些文件是溢出的主要触发因素。请使用 `git` 进行备份/恢复。
-- **Pass 4 gap-fill：`skills/00.shared/MANIFEST.md`** — 如果 Pass 3c 省略了 skill 注册表（skill-sparse 项目），Pass 4 现在会自动创建一个 stub，使 `.claude/rules/50.sync/03.skills-sync.md` 永远不会指向悬空文件。
-
-一些较小的修复：`memory --help` 现在显示 memory 子命令帮助（之前显示的是顶层）；`memory score` 不再留下重复的 `importance` 行；`memory compact` 的 summary 标记现在是正确的 markdown 列表项。完整详情：[CHANGELOG.md](./CHANGELOG.md)。
-
----
-
 ## 为什么选择 ClaudeOS-Core？
 
 其他所有 Claude Code 工具都是这样工作的：
@@ -591,24 +577,6 @@ Pass 3 的 split 模式会随领域数扩展阶段数。批次子分割在 16
 
 Pass 4（内存脚手架）根据运行 Claude 驱动的生成还是静态回退，额外增加 ~30 秒到 5 分钟。对于多技术栈项目（例如 Java + React），backend 和 frontend 领域一起计数。6 个 backend + 4 个 frontend 领域的项目 = 总共 10 个 = 中型层级。
 
-### 实际生产案例：18 领域 admin 前端（2026-04-20）
-
-一个具有 18 个领域和 6 个领域分组的 React 19 + Vite 6 + TypeScript admin 前端端到端**在 102 分钟内生成 101 个文件**完成。阶段分解：
-
-| 阶段 | 文件 | 时间 | 文件/分钟 |
-|---|---|---|---|
-| `3a`（事实提取） | 1（`pass3a-facts.md`） | 8m 44s | — |
-| `3b-core`（CLAUDE.md + 通用） | 24 | 22m 10s | 1.1 |
-| `3b-1`（15 个领域） | 30 | 10m 6s | **3.0** |
-| `3b-2`（3 个领域） | 6 | 4m 34s | 1.3 |
-| `3c-core`（指南 + 共享） | 11 | 8m 31s | 1.3 |
-| `3c-1`（15 个领域） | 8 | 5m 11s | **1.5** |
-| `3c-2`（3 个领域） | 3 | 3m 50s | 0.8 |
-| `3d-aux`（database + mcp） | 3 | 2m 52s | 1.0 |
-| Pass 4 | 12 | 5m 36s | 2.1 |
-
-在分批领域阶段上吞吐量明显更高（3b-1：3.0 文件/分钟 vs. 3b-core：1.1 文件/分钟），因为全新上下文的阶段受益于紧凑的、可重复的每领域模式。验证全部通过：`plan-validator`、`sync-checker`、`content-validator`、`pass-json-validator` — 零溢出失败，零截断。
-
 ---
 
 ## 验证工具
@@ -809,8 +777,7 @@ ClaudeOS-Core 专注于**项目特定规则和标准**。
 它跨 4 个 pass 多次调用 `claude -p`。在 v2.1.0 split 模式中，仅 Pass 3 就根据项目规模展开为 4–14+ 个阶段（参见[按项目规模自动扩展](#按项目规模自动扩展)）。一个典型的小型项目（1–15 领域）总共使用 8–9 次 `claude -p` 调用；18 领域项目使用 11 次；60 领域项目使用 15–17 次。每个阶段都以全新的上下文窗口运行 — 每次调用的 token 成本实际上比过去的单次调用 Pass 3 还低，因为没有任何阶段需要将整个文件树保存在一个上下文中。当 `--lang` 是非英语时，静态回退路径可能会调用几个额外的 `claude -p` 进行翻译；结果会缓存在 `claudeos-core/generated/.i18n-cache-<lang>.json` 中，以便后续运行重用。这在 Claude Code 的正常使用范围内。
 
 **Q：什么是 Pass 3 split 模式，为什么在 v2.1.0 中添加？**
-在 v2.1.0 之前，Pass 3 进行一次 `claude -p` 调用，必须在一次响应中输出整个生成文件树（`CLAUDE.md`、standards、rules、skills、guides — 通常 30–60 个文件）。这在小型项目上有效，但在约 5 个领域时就会可靠地触发 `Prompt is too long` 输出累积失败。失败无法从输入规模预测 — 它取决于每个生成文件碰巧多么冗长，并且可能间歇性地击中同一个项目。Split 模式在结构上绕开了这个问题：Pass 3 被拆分为顺序阶段（`3a` → `3b-core` → `3b-N` → `3c-core` → `3c-N` → `3d-aux`），每个都是具有全新上下文窗口的独立 `claude -p` 调用。跨阶段一致性通过 `pass3a-facts.md` 保留，这是一个 5–10 KB 的蒸馏事实表，之后每个阶段都引用它而不是重新读取 `pass2-merged.json`。`pass3-complete.json` 标记携带一个 `groupsCompleted` 数组，因此 `3c-2` 期间的崩溃会从 `3c-2` 恢复（而不是从 `3a`），避免 token 成本翻倍。实测已在 18 领域 × 101 文件 × 102 分钟且零溢出的条件下验证 — 实际生产分解见[按项目规模自动扩展](#按项目规模自动扩展)。
-
+在 v2.1.0 之前，Pass 3 进行一次 `claude -p` 调用，必须在一次响应中输出整个生成文件树（`CLAUDE.md`、standards、rules、skills、guides — 通常 30–60 个文件）。这在小型项目上有效，但在约 5 个领域时就会可靠地触发 `Prompt is too long` 输出累积失败。失败无法从输入规模预测 — 它取决于每个生成文件碰巧多么冗长，并且可能间歇性地击中同一个项目。Split 模式在结构上绕开了这个问题：Pass 3 被拆分为顺序阶段（`3a` → `3b-core` → `3b-N` → `3c-core` → `3c-N` → `3d-aux`），每个都是具有全新上下文窗口的独立 `claude -p` 调用。跨阶段一致性通过 `pass3a-facts.md` 保留，这是一个 5–10 KB 的蒸馏事实表，之后每个阶段都引用它而不是重新读取 `pass2-merged.json`。`pass3-complete.json` 标记携带一个 `groupsCompleted` 数组，因此 `3c-2` 期间的崩溃会从 `3c-2` 恢复（而不是从 `3a`），避免 token 成本翻倍。
 **Q：我应该将生成的文件提交到 Git 吗？**
 是的，推荐。你的团队可以共享相同的 Claude Code 标准。考虑将 `claudeos-core/generated/` 添加到 `.gitignore`（分析 JSON 可以重新生成）。
 

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "claudeos-core",
-  "version": "2.1.0",
+  "version": "2.1.1",
   "description": "Auto-generate Claude Code documentation from your actual source code — Standards, Rules, Skills, and Guides tailored to your project",
   "main": "bin/cli.js",
   "bin": {