claudeos-core 2.3.1 → 2.4.0

package/pass-json-validator/index.js

@@ -70,10 +70,17 @@ async function main() {
 
   // ─── 1. project-analysis.json ──────────────────────────
   console.log("  [1/5] project-analysis.json...");
+  // v2.4.0 — `template` (singular, legacy single-stack form) removed from
+  // recommended-keys list. `templates` (plural object {backend, frontend})
+  // is the canonical form since multi-stack support landed; the consumer
+  // at line ~88 already does `pa.templates || pa.template` fallback for
+  // back-compat. Listing `template` as recommended caused a false-positive
+  // MISSING_KEY WARNING on every healthy multi-stack-aware project where
+  // only `templates` exists.
   const pa = validateJson(
     path.join(GEN_DIR, "project-analysis.json"),
     ["analyzedAt", "stack", "domains", "frontend", "summary"],
-    ["lang", "template", "templates", "rootPackage", "activeDomains"]
+    ["lang", "templates", "rootPackage", "activeDomains"]
   );
   if (pa) {
     if (!pa.stack || !pa.stack.language) {
@@ -167,6 +174,32 @@ async function main() {
         "codeQuality",         // 12. Code quality tools
       ];
 
+      // v2.4.0 — Semantic alias map for sections.
+      //
+      // Pass 2 LLM frequently emits section keys with numeric prefixes
+      // ("1_universalPatterns") or alternate vocabulary ("majorityPatterns"
+      // instead of "sharedPatterns"). The fuzzy normalizer can't catch
+      // these because the stems don't overlap. This alias map adds known
+      // semantic equivalents so the existence check matches when ANY of
+      // the canonical name OR its aliases is present.
+      //
+      // Each entry: canonical name → [...alternate keys (case/separator
+      // insensitive — normalized identically to keys at check time)].
+      const SECTION_ALIASES = {
+        commonPatterns:    ["universalPatterns", "1_universalPatterns", "1universalPatterns", "patterns_universal"],
+        sharedPatterns:    ["majorityPatterns", "2_majorityPatterns", "2majorityPatterns", "patterns_majority"],
+        domainSpecific:    ["domainSpecificPatterns", "3_domainSpecific", "perDomain", "domains"],
+        antiPatterns:      ["antipatternSummary", "4_antiPatterns", "5_antiPatternSummary", "antiPatternSummary"],
+        namingConventions: ["naming", "5_namingConventions", "6_namingConventions"],
+        commonUtilities:   ["sharedUtilities", "utilities", "6_commonUtilities", "7_commonUtilities"],
+        security:          ["securityPatterns", "auth", "authentication", "7_security", "8_security"],
+        testing:           ["testStrategy", "testingStrategy", "9_testing", "10_testing"],
+        logging:           ["loggingStrategy", "monitoring", "loggingMonitoring", "10_logging", "11_logging"],
+        codeQuality:       ["quality", "codeQualityTools", "12_codeQuality", "13_codeQuality"],
+        database:          ["dbPatterns", "8_database"],
+        performance:       ["perfPatterns", "11_performance"],
+      };
+
       // Sections only in backend stacks (java/node-express/django/fastapi/kotlin)
       const BACKEND_SECTIONS = [
         "database",            // 8. DB patterns
@@ -208,15 +241,19 @@ async function main() {
         ...(isKotlinCqrs ? KOTLIN_CQRS_SECTIONS : []),
       ];
 
-      // Key existence validation (case-insensitive fuzzy matching)
+      // Key existence validation (case-insensitive fuzzy matching + alias map)
       // Normalize a key to a comparable form: lowercase, strip separators
-      const normalize = (s) => s.toLowerCase().replace(/[_\-\s]/g, "");
+      const normalize = (s) => s.toLowerCase().replace(/[_\-\s\.]/g, "");
       const normalizedKeys = keys.map(normalize);
       for (const section of sectionsToCheck) {
         const sectionNorm = normalize(section);
-        // Exact normalized match first, then check if any key contains the section name (one-direction only to avoid false positives)
+        // (1) Exact normalized match
+        // (2) Substring match on canonical (one-direction, length >= 6 to avoid false positives)
+        // (3) v2.4.0 — Alias map: any aliased name (normalized) matches a key (normalized)
+        const aliases = (SECTION_ALIASES[section] || []).map(normalize);
         const found = normalizedKeys.some(k => k === sectionNorm)
-          || (sectionNorm.length >= 6 && normalizedKeys.some(k => k.includes(sectionNorm)));
+          || (sectionNorm.length >= 6 && normalizedKeys.some(k => k.includes(sectionNorm)))
+          || aliases.some(a => normalizedKeys.some(k => k === a || (a.length >= 6 && k.includes(a))));
         if (!found) {
           warnings.push({
             file: "pass2-merged.json",
@@ -270,7 +307,13 @@ async function main() {
   console.log("  [5a/5] pass3-complete.json (optional)...");
   const p3path = path.join(GEN_DIR, "pass3-complete.json");
   if (fs.existsSync(p3path)) {
-    const p3 = validateJson(p3path, ["completedAt"], ["backfilled", "reason"]);
+    // v2.4.0 — `backfilled` and `reason` removed from recommended-keys list.
+    // Both are scenario-specific: `backfilled: true` is set only when init.js
+    // backfilled the marker for a pre-v1.7 CLAUDE.md (rare upgrade path),
+    // and `reason` documents that backfill source. Normal Claude-driven
+    // Pass 3 completion never has either — listing them as "recommended"
+    // produced a false-positive MISSING_KEY WARNING on every healthy run.
+    const p3 = validateJson(p3path, ["completedAt"], []);
     if (p3) {
       if (typeof p3.completedAt !== "string" || !/^\d{4}-\d{2}-\d{2}T/.test(p3.completedAt)) {
         warnings.push({ file: "pass3-complete.json", type: "INVALID_TIMESTAMP", msg: `completedAt should be ISO 8601 (got ${JSON.stringify(p3.completedAt)})` });
@@ -286,9 +329,17 @@ async function main() {
   console.log("  [5b/5] pass4-memory.json (optional)...");
   const p4path = path.join(GEN_DIR, "pass4-memory.json");
   if (fs.existsSync(p4path)) {
+    // v2.4.0 — `planFiles` removed from optional list because master plan
+    // generation was removed in v2.1.0. Pass 4 normal completion never has
+    // it, so the recommendation produced a false-positive WARNING on every
+    // healthy run. Same for `fallback` (only set when Claude-driven Pass 4
+    // failed and static fallback ran) — its absence is the SUCCESS path.
+    // `seededDecisions` (only when initial decision-log is seeded) and
+    // `ruleFiles` (only when Pass 4 emits rules outside scaffold) are also
+    // scenario-specific; demoted from "recommended" to "purely optional".
     const p4 = validateJson(p4path,
       ["analyzedAt", "passNum", "memoryFiles"],
-      ["planFiles", "ruleFiles", "seededDecisions", "fallback"]
+      [] // No recommended optional keys; all scenario-specific (see comment above)
     );
     if (p4) {
       if (typeof p4.passNum !== "number" || p4.passNum !== 4) {

package/pass-prompts/templates/angular/pass3.md

@@ -47,26 +47,26 @@ Generation targets:
    - 00.core/01.project-overview.md — Stack (Angular version, TypeScript version), project structure
    - 00.core/02.architecture.md — Module hierarchy, DI tree, data flow, lazy loading map
    - 00.core/03.naming-conventions.md — File/class/selector/module naming conventions
-   - 20.frontend-ui/01.component-patterns.md — Component structure, lifecycle, OnPush, Signals, I/O
-   - 20.frontend-ui/02.routing-patterns.md — Route config, lazy loading, guards, resolvers
-   - 20.frontend-ui/03.service-di-patterns.md — Injectable, providers, injection tokens, inject()
-   - 20.frontend-ui/04.rxjs-patterns.md — Observable management, operators, subscription cleanup
-   - 20.frontend-ui/05.template-patterns.md — Directives, content projection, control flow (@if/@for)
-   - 20.frontend-ui/06.form-patterns.md — Reactive/Template forms, validators, error handling
-   - 20.frontend-ui/07.state-management.md — NgRx/NGXS/Signal Store patterns
-   - 20.frontend-ui/08.http-patterns.md — HttpClient, interceptors, caching, error handling
-   - 20.frontend-ui/09.styling-patterns.md — ViewEncapsulation, theming, responsive
-   - 10.backend-api/01.api-integration.md — API service abstraction, interceptors (if backend exists)
+   - 20.frontend/01.component-patterns.md — Component structure, lifecycle, OnPush, Signals, I/O
+   - 20.frontend/02.routing-patterns.md — Route config, lazy loading, guards, resolvers
+   - 20.frontend/03.service-di-patterns.md — Injectable, providers, injection tokens, inject()
+   - 20.frontend/04.rxjs-patterns.md — Observable management, operators, subscription cleanup
+   - 20.frontend/05.template-patterns.md — Directives, content projection, control flow (@if/@for)
+   - 20.frontend/06.form-patterns.md — Reactive/Template forms, validators, error handling
+   - 20.frontend/07.state-management.md — NgRx/NGXS/Signal Store patterns
+   - 20.frontend/08.http-patterns.md — HttpClient, interceptors, caching, error handling
+   - 20.frontend/09.styling-patterns.md — ViewEncapsulation, theming, responsive
+   - 10.backend/01.api-integration.md — API service abstraction, interceptors (if backend exists)
    - 30.security-db/01.security-auth.md — Auth guards, JWT interceptor, route protection
    - 40.infra/01.environment-config.md — environment.ts, angular.json, build configuration
    - 40.infra/02.logging-monitoring.md — Error tracking, performance monitoring
    - 40.infra/03.cicd-deployment.md — CI/CD pipeline, ng build --configuration, Docker
-   - 50.verification/01.development-verification.md — ng serve, ng build, Lighthouse
-   - 50.verification/02.testing-strategy.md — TestBed, component harness, E2E strategy
+   - 80.verification/01.development-verification.md — ng serve, ng build, Lighthouse
+   - 80.verification/02.testing-strategy.md — TestBed, component harness, E2E strategy
 
    Each file MUST include:
-   - Correct examples (code blocks in TypeScript)
-   - Incorrect examples (code blocks showing common Angular mistakes)
+   - Correct examples (✅ code blocks in TypeScript)
+   - Incorrect examples (❌ code blocks showing common Angular mistakes)
    - Key rules summary table
 
 3. .claude/rules/ (active domains only)
@@ -83,6 +83,7 @@ Generation targets:
      - `40.infra/03.cicd-deployment-rules.md` paths: `["**/*.yml", "**/*.yaml", "**/Dockerfile*", "**/*.ts"]` — CI config + source
      - `50.sync/*` rules: `paths: ["**/claudeos-core/**", "**/.claude/**"]`
      - `60.memory/*` rules: forward reference — Pass 4 will generate 4 files (01.decision-log, 02.failure-patterns, 03.compaction, 04.auto-rule-update), each with file-specific `paths`. Pass 3 must STILL list ```.claude/rules/60.memory/*``` as a row in CLAUDE.md Section 6 Rules table so developers/Claude see the category exists.
+     - `70.domains/*` rules (multi-domain projects only): per-domain rules at `.claude/rules/70.domains/{type}/{domain}-rules.md` (where `{type}` is `backend` or `frontend`, ALWAYS present even in single-stack projects for uniform layout + zero-migration future-proofing), each with a `paths:` glob scoped to that domain's source directories so the rule auto-loads only when editing files within the relevant domain. Folder name is PLURAL (`domains/`) — collection of N per-domain files — and each file inside uses the SINGULAR domain name (`{domain}-rules.md`). DO NOT use `60.domains/` (collides with `60.memory/`) and DO NOT skip the `{type}/` sub-folder. See pass3-footer.md "Per-domain folder convention" for the full rationale.
    - MUST generate `.claude/rules/00.core/00.standard-reference.md` as a directory of all standard files
 
 4. .claude/rules/50.sync/ (2 sync rules)

package/pass-prompts/templates/common/claude-md-scaffold.md

@@ -52,38 +52,73 @@ DO NOT:
 The 8 canonical section headings below (`## 1. Role Definition` through
 `## 8. Common Rules & Memory (L4)`) use English as their canonical form.
 When generating CLAUDE.md in a non-English output language, the English
-canonical heading MUST remain the primary heading text. A native-language
-translation MAY be appended in parentheses, but is optional.
-
-This rule exists because multiple projects in the same organization will
-have their CLAUDE.md files consumed together (multi-repo grep, cross-repo
-navigation, side-by-side review). When every project uses a different
-native-language translation for the same section, even when the structure
-is otherwise identical, discoverability breaks: `grep "## 7. DO NOT Read"`
-no longer matches all siblings.
+canonical heading MUST remain the primary heading text AND a
+native-language translation MUST be appended in parentheses.
+
+This dual requirement exists for two reasons. First, multiple projects
+in the same organization will have their CLAUDE.md files consumed
+together (multi-repo grep, cross-repo navigation, side-by-side review).
+When every project uses a different native-language translation for the
+same section, even when the structure is otherwise identical,
+discoverability breaks: `grep "## 7. DO NOT Read"` no longer matches
+all siblings. Second, when the CONTENT below the heading is written in
+the target language (e.g., Korean body), a Korean reader scanning the
+document benefits from seeing a Korean gloss next to the English
+canonical token — the heading reads both as a stable grep target AND as
+an intelligible label. Run-to-run consistency matters too: gloss
+inclusion must not vary between generations of the same project.
 
 Format rule:
-- Primary (required): English canonical heading exactly as listed.
-- Parenthetical (optional): native-language translation, added at the end.
+- Primary (REQUIRED): English canonical heading exactly as listed.
+- Parenthetical (REQUIRED when `{OUTPUT_LANG}` != `en`, OMITTED when
+  `{OUTPUT_LANG}` == `en`): native-language translation, added at the
+  end in parentheses.
+
+Canonical translations — use these verbatim when `{OUTPUT_LANG}` matches:
+
+| Code  | §1 | §2 | §3 | §4 | §5 | §6 | §7 | §8 |
+|-------|----|----|----|----|----|----|----|----|
+| `en`  | (no gloss — English is canonical) |
+| `ko`  | (역할 정의) | (프로젝트 개요) | (빌드 및 실행 명령어) | (핵심 아키텍처) | (디렉터리 구조) | (Standard / Rules / Skills 참조) | (직접 읽지 말아야 할 파일) | (공통 규칙 및 메모리 (L4)) |
+| `zh-CN` | (角色定义) | (项目概述) | (构建和运行命令) | (核心架构) | (目录结构) | (Standard / Rules / Skills 参考) | (请勿直接读取的文件) | (通用规则与内存 (L4)) |
+| `ja`  | (役割定義) | (プロジェクト概要) | (ビルド＆実行コマンド) | (コアアーキテクチャ) | (ディレクトリ構造) | (Standard / Rules / Skills 参照) | (直接読まないファイル) | (共通ルール＆メモリ (L4)) |
+| `es`  | (Definición del rol) | (Resumen del proyecto) | (Comandos de compilación y ejecución) | (Arquitectura central) | (Estructura de directorios) | (Referencia Standard / Rules / Skills) | (Archivos que NO se deben leer) | (Reglas comunes y memoria (L4)) |
+| `vi`  | (Định nghĩa vai trò) | (Tổng quan dự án) | (Lệnh build và chạy) | (Kiến trúc cốt lõi) | (Cấu trúc thư mục) | (Tham chiếu Standard / Rules / Skills) | (Tệp KHÔNG được đọc) | (Quy tắc chung & bộ nhớ (L4)) |
+| `hi`  | (भूमिका परिभाषा) | (परियोजना अवलोकन) | (बिल्ड और रन कमांड) | (मुख्य आर्किटेक्चर) | (निर्देशिका संरचना) | (Standard / Rules / Skills संदर्भ) | (न पढ़ने योग्य फ़ाइलें) | (सामान्य नियम और मेमोरी (L4)) |
+| `ru`  | (Определение роли) | (Обзор проекта) | (Команды сборки и запуска) | (Основная архитектура) | (Структура каталогов) | (Справочник Standard / Rules / Skills) | (Файлы, которые НЕ следует читать) | (Общие правила и память (L4)) |
+| `fr`  | (Définition du rôle) | (Aperçu du projet) | (Commandes de build et d'exécution) | (Architecture principale) | (Structure des répertoires) | (Référence Standard / Rules / Skills) | (Fichiers à NE PAS lire) | (Règles communes & mémoire (L4)) |
+| `de`  | (Rollendefinition) | (Projektübersicht) | (Build- und Ausführungsbefehle) | (Kernarchitektur) | (Verzeichnisstruktur) | (Standard / Rules / Skills-Referenz) | (Nicht zu lesende Dateien) | (Gemeinsame Regeln & Speicher (L4)) |
 
 Examples (ko output):
 
-    ✅ `## 7. DO NOT Read`
+    ✅ `## 1. Role Definition (역할 정의)`
     ✅ `## 7. DO NOT Read (직접 읽지 말아야 할 파일)`
+    ❌ `## 1. Role Definition`
+        — gloss is required when OUTPUT_LANG != en
     ❌ `## 7. 읽지 말 것 (Files Not to Be Read Directly)`
         — English must be primary, not parenthetical
     ❌ `## 7. 읽지 말 것`
-        — English canonical must appear
+        — English canonical must appear as primary
 
 Examples (ja output):
 
     ✅ `## 7. DO NOT Read (直接読まないファイル)`
+    ❌ `## 7. DO NOT Read`
+        — gloss is required when OUTPUT_LANG != en
     ❌ `## 7. 直接読まないファイル (DO NOT Read)`
+        — English must be primary, not parenthetical
+
+Examples (en output):
 
-The same rule applies to all 8 sections. When in doubt, emit only the
-English canonical heading; the parenthetical translation is a courtesy,
-not a requirement. The CONTENT below the heading is still written
-entirely in the target language.
+    ✅ `## 7. DO NOT Read`
+    ❌ `## 7. DO NOT Read (Files Not to Be Read Directly)`
+        — gloss must be OMITTED when OUTPUT_LANG == en
+        (the English canonical already serves as the label)
+
+For `{OUTPUT_LANG}` codes not in the table above, translate each
+canonical heading semantically into the target language and append in
+parentheses following the same pattern. The CONTENT below the heading
+is written entirely in the target language regardless of the gloss.
 
 DO:
 - Adapt content within each section to project facts from pass2-merged.json
@@ -101,8 +136,20 @@ Use the following structure EXACTLY:
 
 > {1-2 line project intro}
 
+{!-- SECTION HEADING RULE (applies to all 8 ## headings below):
+     The heading format "## N. English Canonical" shown in this scaffold
+     is the en (English) form. For non-English OUTPUT_LANG, APPEND the
+     canonical gloss in parentheses per the "Section heading format"
+     table earlier in this scaffold.
+     Example (ko): `## 1. Role Definition (역할 정의)`
+     Example (en): `## 1. Role Definition`  (no gloss)
+     --}
+
 ## 1. Role Definition
 
+{!-- Line 1 below is in English for reference only. When OUTPUT_LANG != en,
+     REPLACE with the canonical translation from "Section 1: Role Definition"
+     rules further down in this scaffold. See the 10-language canonical list. --}
 As the senior developer for this repository, you are responsible for writing, modifying, and reviewing code. Responses must be written in {OUTPUT_LANG}.
 {PROJECT_CONTEXT}.
 
@@ -232,6 +279,12 @@ Unlike rules that auto-load via `paths` glob, this layer is referenced **on-dema
 4. **Record repeated errors**: If the same error occurs ≥2 times and the root cause is non-obvious, register it in `failure-patterns.md` with a new pattern-id.
 5. **Periodic compaction**: When a memory file approaches 400 lines or has not been tidied up for over a month, run `npx claudeos-core memory compact`.
 6. **Review rule-update proposals**: Review proposals in `auto-rule-update.md` with confidence ≥ 0.70. When accepting, edit the corresponding rule file and log the decision in `decision-log.md`.
+
+**Session Resume (after auto-compact or restart)**: Claude Code's auto-compact feature may truncate session context mid-work, and a restarted session starts with a fresh context window. When resuming work:
+
+- **Re-scan** `failure-patterns.md` — error patterns referenced pre-compact may have been dropped from context.
+- **Re-read the 3 most recent entries** of `decision-log.md` — new decisions may have been recorded during the truncated portion of the session.
+- **Re-match rules by `paths` glob** for the current working files — CLAUDE.md is always loaded, but `paths`-conditional rules may not have been re-loaded after compact. Explicitly Read the relevant rule files if needed.
 ```
 
 ---
@@ -242,11 +295,45 @@ Unlike rules that auto-load via `paths` glob, this layer is referenced **on-dema
 
 **Structure**: EXACTLY 2 lines.
 
-**Line 1** (fixed text with `{OUTPUT_LANG}` substitution; emit in the target output language):
+**Line 1** (fixed meaning, EMIT IN THE TARGET OUTPUT LANGUAGE — do NOT copy the English reference verbatim unless `{OUTPUT_LANG}` is English):
+
+The sentence below is the **semantic reference in English**. Translate it
+fully into `{OUTPUT_LANG}`. The English text is NOT a literal template —
+copying it verbatim for a non-English target produces the ironic bug of
+writing "Responses must be written in Korean" in English.
+
+English reference (semantic, for `en` output only):
 ```
 As the senior developer for this repository, you are responsible for writing, modifying, and reviewing code. Responses must be written in {OUTPUT_LANG}.
 ```
 
+**Canonical translations** — emit these VERBATIM when `{OUTPUT_LANG}` matches
+the target language. If `{OUTPUT_LANG}` is some other language not listed
+here, translate the English reference following the same semantic
+structure (senior developer + write/modify/review code + respond in target
+language):
+
+- `en` →
+  `As the senior developer for this repository, you are responsible for writing, modifying, and reviewing code. Responses must be written in English.`
+- `ko` (한국어) →
+  `이 리포지토리의 시니어 개발자로서 코드 작성, 수정, 리뷰를 책임진다. 응답은 한국어로 작성해야 한다.`
+- `zh-CN` (简体中文) →
+  `作为此仓库的高级开发者，负责代码的编写、修改和审查。回答必须使用简体中文。`
+- `ja` (日本語) →
+  `このリポジトリのシニア開発者として、コードの記述、修正、レビューを担当する。回答は日本語で記述すること。`
+- `es` (Español) →
+  `Como desarrollador senior de este repositorio, eres responsable de escribir, modificar y revisar código. Las respuestas deben estar escritas en español.`
+- `vi` (Tiếng Việt) →
+  `Với tư cách là lập trình viên cấp cao của kho lưu trữ này, bạn chịu trách nhiệm viết, sửa đổi và đánh giá mã. Các câu trả lời phải được viết bằng tiếng Việt.`
+- `hi` (हिन्दी) →
+  `इस रिपॉजिटरी के वरिष्ठ डेवलपर के रूप में, आप कोड लिखने, संशोधित करने और समीक्षा करने के लिए ज़िम्मेदार हैं। उत्तर हिन्दी में लिखे जाने चाहिए।`
+- `ru` (Русский) →
+  `Как старший разработчик этого репозитория, вы отвечаете за написание, изменение и проверку кода. Ответы должны быть написаны на русском языке.`
+- `fr` (Français) →
+  `En tant que développeur senior de ce dépôt, vous êtes responsable de l'écriture, de la modification et de la révision du code. Les réponses doivent être rédigées en français.`
+- `de` (Deutsch) →
+  `Als Senior-Entwickler dieses Repositorys sind Sie für das Schreiben, Ändern und Überprüfen von Code verantwortlich. Antworten müssen auf Deutsch verfasst werden.`
+
 **Line 2** (`{PROJECT_CONTEXT}` — dynamically generated, Level 2 abstraction):
 
 Generate `{PROJECT_CONTEXT}` as a single sentence combining:
@@ -474,6 +561,63 @@ Format: `**{category}**: {explanation}`
   Example row for 60.memory:
   `.claude/rules/60.memory/*` | Auto-loaded when editing L4 memory
   files (decision-log · failure-patterns · compaction · auto-rule-update) |
+  Example row for 70.domains (only when the project has multi-batch
+  domain output — see "Per-domain folder convention" below):
+  `.claude/rules/70.domains/*` | Auto-loaded when editing files within
+  a specific domain (paths-scoped, one rule file per domain) |
+
+**Per-domain folder convention (canonical, v2.4.0+)**:
+
+When a project has multiple distinct domains and Pass 3 emits per-domain
+output (typical for backends with ≥4 domains, multi-batch runs, or
+projects where rules need domain-specific `paths` glob scoping), the
+canonical folder is **`70.domains/{type}/`** (PLURAL collection +
+ALWAYS-typed sub-folder), and each file inside uses the singular
+domain name:
+
+  - `claudeos-core/standard/70.domains/{type}/{domain}.md` — `{type}`
+    is `backend` or `frontend`
+  - `.claude/rules/70.domains/{type}/{domain}-rules.md` — per-domain rule
+    (with `paths` frontmatter scoping to that domain's source directories)
+
+The `{type}/` sub-folder is ALWAYS present, even in single-stack
+projects (backend-only or frontend-only). Reasons: (1) zero file moves
+when a single-stack project later adds the other stack, (2) no LLM
+probabilistic drift between Pass 3 runs (one pattern always), (3) one
+pattern for validators to recognize, (4) future-proof for new stack
+types (mobile/cli/agent).
+
+The Pass 3 orchestrator (`bin/commands/init.js`) classifies each domain
+via `project-analysis.json` and emits per-domain target paths
+explicitly in the batch scope note — you (the LLM) should follow the
+explicit paths shown there.
+  - `claudeos-core/skills/{category}/domains/{domain}.md` — per-domain
+    skill notes (sub-folder under skill category, no number prefix
+    because skills/ is a separate namespace from standard/rules)
+  - `claudeos-core/skills/{category}/02.domains.md` — sibling
+    ORCHESTRATOR for the `domains/` sub-folder (REQUIRED whenever
+    `domains/` is populated). Mirrors the canonical pattern
+    `01.scaffold-*-feature.md` ↔ `scaffold-*-feature/`: orchestrator
+    file at category root + sub-folder of the same stem. Stem
+    (`domains`) MUST match sub-folder name so `content-validator`'s
+    standard orchestrator-stem matching covers the sub-skills
+    directly without depending on the global-MANIFEST coverage
+    fallback. The per-domain note files INSIDE `domains/` carry NO
+    numeric prefix (`payment.md`, not `01.payment.md`) — domains are
+    independent siblings without execution order, unlike the
+    sequenced CRUD sub-skills (`01.dto.md` → `08.test.md`) where
+    numbers encode the scaffolding step order.
+
+The `70.` prefix sits AFTER `60.memory` (which is regression-guarded to
+60) and BEFORE `90.optional`, giving per-domain content its own clean
+slot in the rules numbering. The folder name is plural (`domains/`)
+because it holds N files, one per project domain — matching the standard
+filesystem convention `users/user.md`, `posts/post.md`. The other
+numbered category folders (`00.core/`, `10.backend/`, etc.) are singular
+because each represents ONE topic, not a collection.
+
+DO NOT use `60.domains/` (collides with `60.memory/`) and DO NOT use
+`70.domain/` (singular folder is incorrect for a collection).
 
 **Sub-section 3**: `### Skills (Automated Repeated-task Procedures)`
 - Bullet list
@@ -563,6 +707,24 @@ Workflow: `#### Memory Workflow` — FIXED 6-step numbered list
 5. Periodic compaction — memory compact command
 6. Review rule-update proposals — auto-rule-update review
 
+**Session Resume block** (RECOMMENDED, follows the 6-step numbered list
+as prose — not a new H4 subsection). Opens with bold label
+`**Session Resume (after auto-compact or restart)**:` followed by a
+3-bullet list covering: re-scan `failure-patterns.md`, re-read the 3
+most recent entries of `decision-log.md`, and re-match rules by `paths`
+glob for current working files. This block addresses Claude Code's
+auto-compact behavior that may truncate session context mid-work.
+
+New CLAUDE.md generation (`npx claudeos-core init`) emits this block
+by default. Existing CLAUDE.md files without it remain structurally
+valid — the validator does not enforce Session Resume presence, only
+that if present it follows the prose-not-H4 form.
+
+The Session Resume block MUST NOT be a `####` subsection — the Section
+8 structural validator enforces EXACTLY 2 `####` headings (L4 Memory
+Files + Memory Workflow). Session Resume is prose inside the Memory
+Workflow section, not a sibling heading.
+
 **Section 8 single-occurrence rule** (enforces the "one canonical home"
 principle):
 - The L4 Memory Files table appears EXACTLY ONCE in the entire document
@@ -624,10 +786,27 @@ Before finalizing, verify:
       Structure, Standard / Rules / Skills Reference, DO NOT Read,
       Common Rules & Memory (L4)) — rendered in the target output
       language with equivalent meaning and order
+- [ ] **Section heading gloss rule:**
+      If `{OUTPUT_LANG}` != `en`, EVERY one of the 8 `##` headings MUST
+      carry the parenthetical native-language gloss from the canonical
+      table in "Section heading format". Example (ko):
+      `## 1. Role Definition (역할 정의)`, `## 7. DO NOT Read (직접 읽지 말아야 할 파일)`.
+      If any heading is missing its gloss while `{OUTPUT_LANG}` != `en`,
+      the output is NON-COMPLIANT — add the gloss before finalizing.
+- [ ] **English gloss-absence rule:**
+      If `{OUTPUT_LANG}` == `en`, headings MUST NOT carry a parenthetical
+      gloss (the English canonical already serves as the label).
+      `## 7. DO NOT Read` is correct; `## 7. DO NOT Read (Files Not to Be
+      Read Directly)` is incorrect for `en` output.
 - [ ] Section order is correct
 - [ ] No sections renamed, merged, or split
 - [ ] No sections added beyond the 8
 - [ ] Section 1 is 2 lines
+- [ ] Section 1 Line 1 is in `{OUTPUT_LANG}` — matches the canonical
+      translation in "Section 1: Role Definition" rules (if
+      `{OUTPUT_LANG}` is one of the 10 canonical codes). If Line 1
+      contains the English phrase "As the senior developer" while
+      `{OUTPUT_LANG}` is NOT `en`, the translation was skipped — fix it.
 - [ ] Section 2 is 8-12 rows table
 - [ ] Section 5 has at most 3 emphasis bullets below tree
 - [ ] Section 6 has EXACTLY 3 sub-sections (Standard / Rules / Skills)
@@ -648,8 +827,12 @@ Before finalizing, verify:
 
 ### Example: Section 1 for different stacks
 
-Examples below are shown in English. Emit the final output in the
-target output language; the semantic content should match.
+⚠️ **Language note:** The English examples below show the SEMANTIC
+structure only. Line 1 of Section 1 MUST be emitted in `{OUTPUT_LANG}` —
+use the canonical translations from "Section 1: Role Definition" rules
+above. Line 2 (PROJECT_CONTEXT) should also be written in
+`{OUTPUT_LANG}`, keeping technical identifiers (framework names, pattern
+names, stack labels) in their standard English form where idiomatic.
 
 **Java Spring Boot backend**:
 ```