claudeos-core 2.1.1 → 2.3.0

package/pass-prompts/templates/common/pass3-footer.md

@@ -1,39 +1,402 @@
-
-CRITICAL — No Hallucination Guard:
-You may ONLY reference technologies that are explicitly present in the two files you read:
-project-analysis.json (stack detection results) and pass2-merged.json (code analysis results).
-If a library, framework, tool, or pattern does NOT appear in either of these files,
-you MUST NOT mention it, generate code examples for it, or assume it exists — not in
-standards, rules, skills, guides, database docs, or CLAUDE.md.
-Do NOT infer or guess technologies from other detected technologies.
-Examples of violations:
-- Writing "React Query caching" when pass2-merged.json has no TanStack Query / React Query entry
-- Adding "Zustand store pattern" when pass2-merged.json has no Zustand usage
-- Generating "Prisma schema" examples when project-analysis.json ORM is not Prisma
-- Assuming React Query exists because Orval was detected (inference is NOT detection)
-When in doubt, omit. Missing content is fixable; hallucinated content erodes trust.
-
-CRITICAL — No Domain-Specific Hardcoding:
-All generated documentation in claudeos-core/standard/, .claude/rules/, and claudeos-core/skills/
-MUST use generic, reusable patterns — NEVER hardcode project-specific domain names, table names,
-URL paths, or class names as examples.
-Use placeholder patterns instead:
-- Table names: `{prefix}_{table_name}` not a specific table like `user_account`
-- URL paths: `{domain}/{resource}` not a specific path like `/notice/getList`
-- DTO names: `{Action}{Entity}ReqDto` not a specific class like `GetNoticeListReqDto`
-- Domain keys: `{DOMAIN_KEY}` not a specific code like `NOTICE`
-Allowed exceptions:
-- Project-wide common fields that appear across ALL domains (e.g., audit columns, base classes)
-- Framework/infrastructure names (e.g., `BaseEntity`, `SecurityConfig`)
-- Listing existing domain names only when explaining how to ADD NEW ones (configuration examples)
-Reason: These documents are project-wide COMMON rules. If specific domain names appear,
-developers working on other domains may ignore the rules as irrelevant to them.
-
-CRITICAL — Skill Orchestrator Completeness:
-The orchestrator file (e.g., 01.scaffold-page-feature.md, 01.scaffold-crud-feature.md)
-MUST list ALL sub-skill files in its execution order table with no gaps.
-Every sub-skill file generated in the scaffold directory MUST have a corresponding row.
-Do NOT skip any number in the sequence.
-
-After completion, run the following commands in order:
-1. npx claudeos-core health
+
+CRITICAL — No Hallucination Guard:
+You may ONLY reference technologies that are explicitly present in the two files you read:
+project-analysis.json (stack detection results) and pass2-merged.json (code analysis results).
+If a library, framework, tool, or pattern does NOT appear in either of these files,
+you MUST NOT mention it, generate code examples for it, or assume it exists — not in
+standards, rules, skills, guides, database docs, or CLAUDE.md.
+Do NOT infer or guess technologies from other detected technologies.
+Examples of violations:
+- Writing "React Query caching" when pass2-merged.json has no TanStack Query / React Query entry
+- Adding "Zustand store pattern" when pass2-merged.json has no Zustand usage
+- Generating "Prisma schema" examples when project-analysis.json ORM is not Prisma
+- Assuming React Query exists because Orval was detected (inference is NOT detection)
+When in doubt, omit. Missing content is fixable; hallucinated content erodes trust.
+
+CRITICAL — No Domain-Specific Hardcoding:
+All generated documentation in claudeos-core/standard/, .claude/rules/, and claudeos-core/skills/
+MUST use generic, reusable patterns — NEVER hardcode project-specific domain names, table names,
+URL paths, or class names as examples.
+Use placeholder patterns instead:
+- Table names: `{prefix}_{table_name}` not a specific table like `user_account`
+- URL paths: `{domain}/{resource}` not a specific path like `/notice/getList`
+- DTO names: `{Action}{Entity}ReqDto` not a specific class like `GetNoticeListReqDto`
+- Domain keys: `{DOMAIN_KEY}` not a specific code like `NOTICE`
+Allowed exceptions:
+- Project-wide common fields that appear across ALL domains (e.g., audit columns, base classes)
+- Framework/infrastructure names (e.g., `BaseEntity`, `SecurityConfig`)
+- Listing existing domain names only when explaining how to ADD NEW ones (configuration examples)
+Reason: These documents are project-wide COMMON rules. If specific domain names appear,
+developers working on other domains may ignore the rules as irrelevant to them.
+
+CRITICAL — Skill Orchestrator Completeness:
+The orchestrator file (e.g., 01.scaffold-page-feature.md, 01.scaffold-crud-feature.md)
+MUST list ALL sub-skill files in its execution order table with no gaps.
+Every sub-skill file generated in the scaffold directory MUST have a corresponding row.
+Do NOT skip any number in the sequence.
+
+CRITICAL — Sync Rule Economy:
+For 50.sync/*, generate AT MOST 2 files:
+- One doc-sync rule covering BOTH directions (standard ↔ rules) as a single bidirectional rule.
+- One skills-sync rule covering the skills ↔ MANIFEST relationship.
+Do NOT generate separate "A → B" and "B → A" files for the same mirror relationship —
+they are redundant and multiply self-maintenance cost.
+
+Inside sync rules:
+- Do NOT hardcode file-to-file mapping tables (e.g., "standard/X.md → rules/X-rules.md"
+  listed for every pair). Express the relationship as a NAMING CONVENTION instead
+  (e.g., "standard/<N>.<dir>/<M>.<name>.md ↔ .claude/rules/<N>.<dir>/<M>.<name>-rules.md").
+- The master mapping index lives in .claude/rules/00.core/00.standard-reference.md —
+  sync rules should reference it, not duplicate it.
+- Hardcoded mapping tables rot fast: every new standard file forces an edit.
+  Naming conventions are self-describing and maintenance-free.
+
+CRITICAL — `00.standard-reference.md` Composition:
+This file is the mechanical standards index loaded on every edit via
+`paths: ["**/*"]`. Its role is to let Claude Code locate a standard file
+quickly without enumerating the whole tree. Scope it strictly:
+
+INCLUDE:
+- Every file that will exist under `claudeos-core/standard/` after Pass 3 + Pass 4.
+  This includes FORWARD REFERENCES to Pass 4 outputs — specifically
+  `claudeos-core/standard/00.core/04.doc-writing-guide.md` (generated by Pass 4's
+  Required output #12). Omitting it creates an index gap the moment Pass 4 runs.
+  If Pass 4 lands a file at `claudeos-core/standard/00.core/04.doc-writing-guide.md`,
+  it must already appear in Pass 3's `00.standard-reference.md` under `## Core`.
+
+DO NOT INCLUDE:
+- "DO NOT Read" / "context waste" / "Avoid reading" sections listing
+  `claudeos-core/generated/`, `claudeos-core/guide/`, `claudeos-core/mcp-guide/`,
+  `build/`, `internal/`, or any "negative list". CLAUDE.md Section 7
+  (DO NOT Read) is the single source of truth for that information, and it
+  is more complete (includes project-specific paths like `build/` and
+  external modules). Replicating this list inside `00.standard-reference.md`
+  creates a duplicate maintenance point that drifts over time.
+- Rule files (`.claude/rules/*`), skill files (`claudeos-core/skills/*`), or
+  memory files (`claudeos-core/memory/*`). The index is for standards only.
+- Inline descriptions per file (1-line summaries). Those live in CLAUDE.md
+  Section 6's Standard sub-section, which is loaded once per session
+  (session-time budget), while this file is reloaded on every edit
+  (per-edit budget). Keep the per-edit payload minimal — paths only.
+
+CRITICAL — `.env` Is the Source of Truth for Runtime Configuration:
+When pass2-merged.json contains `stack.envInfo` (parsed from the project's
+`.env.example` or `.env`), treat that data as authoritative for:
+
+- Port numbers (dev server, API server, alternate ports like mobile/storybook)
+- Host names (dev host, API host)
+- API target URLs (backend proxy target, external service endpoints)
+- Any other runtime configuration the project explicitly declares
+
+Do NOT override these with framework defaults (Vite 5173, Next.js 3000,
+Django 8000, etc.) when the project's env file says otherwise. Framework
+defaults are only valid when `stack.envInfo` is absent or the specific
+field is null.
+
+This affects:
+- CLAUDE.md Section 2 (Project Overview table) — port / host / API target rows
+- CLAUDE.md Section 3 (Build & Run Commands) — inline comments next to run commands
+- Any generated rule that references port values (e.g., 30.security-db/
+  auth rules that mention CORS origins)
+
+When in doubt, read `.env.example` directly and cross-check against
+`stack.envInfo.vars`. If they disagree, trust `.env.example` as the
+canonical declaration.
+
+CRITICAL — Rule `paths` Must Match Rule Content:
+Each `.claude/rules/*` file's `paths` frontmatter MUST match the file types
+that the rule's guardrails actually target, NOT the category's default.
+
+- A logging rule's guardrails apply to source code (e.g., `console.log` use,
+  PII in logs, `catch {}` empty blocks). Its `paths` MUST include source code
+  extensions (`**/*.ts`, `**/*.py`, `**/*.java`, etc.), not just config files.
+- An environment-config rule's guardrails apply to `.env*`, `*.config.*`,
+  and similar. Its `paths` must include those.
+- A CI/CD rule's guardrails often span both — CI YAML AND source code
+  (e.g., "no hardcoded API origin in source", "no direct edits to generated
+  client"). Its `paths` must include both categories.
+
+Do NOT copy `paths` verbatim across sibling rule files in the same category.
+Each file is evaluated independently based on what it enforces. The Pass 3
+prompt now specifies per-file paths for `40.infra/*` — follow those EXACTLY,
+do not substitute a category-level shortcut.
+
+When generating a rule file, re-read the file's own guardrail content and
+verify: "When should Claude Code auto-load this rule?" The answer determines
+paths. If the answer is "when editing TypeScript source", paths must include
+`**/*.ts` / `**/*.tsx` — not `**/*.json`.
+
+CRITICAL — CLAUDE.md Scaffold Compliance:
+CLAUDE.md generation MUST follow the scaffold at:
+`pass-prompts/templates/common/claude-md-scaffold.md`
+
+The scaffold enforces EXACTLY 8 top-level (##) sections with FIXED
+titles and order (canonical English names below — emit each heading
+in the target output language with equivalent meaning):
+1. Role Definition
+2. Project Overview
+3. Build & Run Commands
+4. Core Architecture
+5. Directory Structure
+6. Standard / Rules / Skills Reference
+7. DO NOT Read (Files Not to Be Read Directly)
+8. Common Rules & Memory (L4)
+
+Before finalizing, verify:
+- Exactly 8 `##` sections (no more, no less)
+- Section titles match the scaffold's FIXED names (in the target output language)
+- Section order matches
+- Section 1 is exactly 2 lines (role + PROJECT_CONTEXT)
+- Section 6 has EXACTLY 3 sub-sections (Standard / Rules / Skills — no "Guide" sub-section)
+- Section 7 includes the 3 common claudeos-core/* entries 
+  (guide/, generated/, mcp-guide/)
+- Section 8 has EXACTLY 2 sub-sections:
+  - `### Common Rules (auto-loaded on every edit)` — meta-summary table
+    of `paths: ["**/*"]` rules (typically
+    `00.core/51.doc-writing-rules.md` and `00.core/52.ai-work-rules.md`)
+  - `### L4 Memory (on-demand reference)` — intro + 4-row memory file
+    table + 6-step workflow, EACH APPEARING EXACTLY ONCE
+
+FORBIDDEN `##`-level sections (beyond the canonical 8):
+
+RULE: No `##` section may have a title whose semantic category is "rules",
+"memory", "L4", "guardrails", or any rephrasing thereof. The 8 canonical
+sections above are the COMPLETE set of allowed top-level headings.
+
+This rule is LANGUAGE-INVARIANT. When generating in a non-English output
+language, apply this rule to the translated heading, not just the English
+one. The LLM's task is NOT to match a finite blocklist of English strings;
+it is to reject ANY 9th `##` section regardless of wording.
+
+Examples of forbidden `##` sections (canonical English label → common
+translated variants that are ALSO forbidden):
+
+- "Memory Layer (L4)" →
+  Korean (ko):    "메모리 (L4)", "메모리 레이어 (L4)", "L4 메모리"
+  Japanese (ja):  "メモリ (L4)", "メモリレイヤー (L4)", "L4 メモリ"
+  Chinese (zh):   "记忆层 (L4)", "内存 (L4)", "L4 记忆", "记忆 (L4)"
+  Spanish (es):   "Capa de Memoria (L4)", "Memoria (L4)", "L4 Memoria"
+  Vietnamese (vi):"Lớp Bộ nhớ (L4)", "Bộ nhớ (L4)", "L4 Bộ nhớ"
+  Hindi (hi):     "मेमोरी लेयर (L4)", "मेमोरी (L4)", "L4 मेमोरी"
+  Russian (ru):   "Слой памяти (L4)", "Память (L4)", "L4 Память"
+  French (fr):    "Couche Mémoire (L4)", "Mémoire (L4)", "L4 Mémoire"
+  German (de):    "Speicherebene (L4)", "Speicher (L4)", "L4 Speicher"
+  All forbidden; L4 memory belongs as a SUB-SECTION inside Section 8.
+
+- "Common Rules" →
+  Korean (ko):    "공통 규칙", "공통 가드레일"
+  Japanese (ja):  "共通ルール", "共通ガードレール"
+  Chinese (zh):   "通用规则", "公共规则"
+  Spanish (es):   "Reglas Comunes", "Guardarraíles Comunes"
+  Vietnamese (vi):"Quy tắc Chung", "Lan can Chung"
+  Hindi (hi):     "सामान्य नियम", "सामान्य गार्डरेल"
+  Russian (ru):   "Общие правила", "Общие ограждения"
+  French (fr):    "Règles Communes", "Garde-fous Communs"
+  German (de):    "Allgemeine Regeln", "Allgemeine Leitplanken"
+  All forbidden; common rules belong as a SUB-SECTION inside Section 8.
+
+- "L4 Memory Files (Re-declaration)" or any restated memory table →
+  Any heading in any language under which the L4 Memory Files table is
+  restated is forbidden. The table appears EXACTLY ONCE in the whole
+  document (inside Section 8 sub-section 2).
+
+- "Documentation Writing Rules", "AI Work Rules", "Required to Observe
+  While Working", "Rules Summary" →
+  Same prohibition across all 10 output languages (ko, ja, zh-CN, es,
+  vi, hi, ru, fr, de, en). These are rule content, not CLAUDE.md
+  content; move their bodies to `.claude/rules/*`.
+
+DECISION RULE (apply before writing any `##` heading):
+1. Is this heading one of the 8 canonical sections? → Proceed.
+2. Does this heading's meaning fall under "rules", "memory", "L4",
+   "guardrails", or "procedures to follow"? → STOP. The content belongs
+   in `.claude/rules/*` or inside Section 8 as a sub-section.
+3. Anything else → Re-check whether this content actually belongs in
+   CLAUDE.md at all; most extra `##` sections are signs that the content
+   should live in `.claude/rules/*`, `claudeos-core/standard/*`, or
+   `claudeos-core/memory/*`.
+
+Where common-rule information DOES belong:
+- `##`-level: Section 8 sub-section 1 (`### Common Rules (auto-loaded
+  on every edit)`). Include a meta-summary table with columns
+  `| Rule File | Role | Core Enforcement |` (column labels emitted in
+  target output language). The "Core Enforcement" column is a ONE-LINE
+  meta summary of each rule, NOT a copy of the rule body. Example:
+    `| 00.core/51.doc-writing-rules.md | Documentation writing rules
+     | paths required, no domain/absolute-path hardcoding, ## Reference
+     section required |`
+- The rule BODY itself lives in `.claude/rules/00.core/51.*.md` and is
+  auto-loaded; CLAUDE.md only summarizes "what this rule enforces",
+  one line per rule.
+
+POST-GENERATION CHECK (MANDATORY — execute as the last step before
+declaring CLAUDE.md generation complete):
+
+STEP 1 — Count. Run a mental grep for `^## ` in your generated CLAUDE.md.
+Record the count.
+
+STEP 2 — Assert. The count MUST equal 8. Not 7. Not 9. Exactly 8.
+This is LANGUAGE-INVARIANT and TITLE-INVARIANT: a 9th `##` section is
+forbidden regardless of its title, in any of the 10 supported output
+languages.
+
+STEP 3 — Repair (only if count ≠ 8). Locate the deviation and apply:
+- Count = 9 or more → identify the surplus section(s); for EACH surplus:
+  - If it contains memory-file references (`decision-log.md`,
+    `failure-patterns.md`, `compaction.md`, `auto-rule-update.md`) →
+    DELETE the entire section; its content already lives in Section 8
+    sub-section 2
+  - If it contains rule-summary content → MERGE into Section 8
+    sub-section 1 (not as a new section)
+  - If it contains procedural/enforcement content → MOVE to
+    `.claude/rules/*`, not CLAUDE.md
+  - Otherwise → MERGE into the best-fitting Section 1-7
+- Count = 7 or fewer → a required section is missing; add it following
+  the scaffold's canonical order
+
+STEP 4 — Verify repair. Re-count `^## `. If still ≠ 8, repeat STEP 3.
+Do NOT declare CLAUDE.md generation complete until count = 8 AND
+Section 8 contains exactly 2 `###` sub-sections.
+
+STEP 4b — Title determinism check. For each of the 8 `## N.` headings,
+confirm that the English canonical phrase is present as the primary
+heading text (a native-language translation may follow in parentheses).
+This rule is LANGUAGE-INVARIANT — applied regardless of `{OUTPUT_LANG}`:
+
+    ✅ `## 7. DO NOT Read`
+    ✅ `## 7. DO NOT Read (직접 읽지 말아야 할 파일)`
+    ❌ `## 7. 읽지 말 것 (Files Not to Be Read Directly)`
+       — English canonical must be PRIMARY, not parenthetical
+
+Required canonical tokens by section number:
+    §1 → "Role Definition"
+    §2 → "Project Overview"
+    §3 → "Build" (as in "Build & Run Commands")
+    §4 → "Core Architecture"
+    §5 → "Directory Structure"
+    §6 → "Standard" (as in "Standard / Rules / Skills Reference")
+    §7 → "DO NOT Read"
+    §8 → "Memory" (as in "Common Rules & Memory (L4)")
+
+WHY: Multi-repo consumers (Claude Code sessions spanning sibling
+projects, organization-wide grep, cross-repo navigation) must be able
+to find Section N in every CLAUDE.md by a single English keyword search.
+Without this invariant, one project's §7 reads "DO NOT Read (읽지 말 것)"
+and a sibling's reads "읽지 말 것 (DO NOT Read)" — identical meaning,
+but `grep "## 7. DO NOT Read"` silently misses the second.
+
+If any heading lacks its canonical token, rewrite it before finalizing.
+
+STEP 5 — External validation available. After saving CLAUDE.md, the
+user can run `npx claudeos-core lint` to independently verify structure
+via the language-invariant validator (v2.3.0+). This is purely a safety
+net; the LLM should not rely on it — the structure must be correct at
+write time.
+
+CRITICAL — Path fact grounding (MANDATORY):
+
+Every `src/...` (or equivalent language-specific source root) path you
+write in rules, standard, or CLAUDE.md MUST be a literal, verbatim path
+from `pass2-merged.json` / `project-analysis.json` / `pass1-*.json`.
+Do not invent, augment, or "normalize" filenames.
+
+The single most common Pass 3 hallucination pattern is inferring a
+filename from its parent directory:
+
+    Directory seen in facts:  src/feature/routers/
+    File seen in facts:       src/feature/routers/routePath.ts
+                              src/feature/routers/routeComponentMap.ts
+
+    ❌ WRONG: write `src/feature/routers/featureRoutePath.ts`
+                       (prepended "feature" because the dir is `feature/`)
+    ❌ WRONG: write `src/feature/routers/FEATURE_COMPONENT_MAP.ts`
+                       (uppercased to match the TS constant name)
+    ✅ RIGHT: write `src/feature/routers/routePath.ts`
+
+Mechanism of the error: the model sees a constant named
+`FEATURE_ROUTE_PATH` (a TypeScript identifier) and "renormalizes" the
+filename to match it. TypeScript identifiers and filenames are
+independent — do NOT let the constant's name drive the filename you
+write. The filename in `pass2-merged.json` is authoritative.
+
+Same rule applies to domain prefixes in general:
+- `src/feature/X.ts` is the correct reference even when the file's
+  exported symbols start with `Feature*` or `FEATURE_*`.
+- Do NOT prepend the parent directory name to the filename as a
+  disambiguator. The directory path is already the scope.
+
+Library-convention hallucination class (equally important):
+
+When generating a standard file about testing, mocking, styling,
+state management, or similar library-centric topics, do NOT reach
+for "the canonical file location" from the library's own docs. There
+is no canonical location — every project chooses its own.
+
+    ❌ WRONG: writing `testing-strategy.md` and referencing
+       `src/__mocks__/handlers.ts`, `src/test/setup.ts`,
+       `src/setupTests.ts`, or `src/test-utils.tsx` because MSW,
+       Vitest, or Jest docs show these paths.
+    ❌ WRONG: writing `styling-patterns.md` and referencing a
+       `src/styles/globals.css` or `src/theme.ts` because the
+       framework's quick-start uses them.
+
+    ✅ RIGHT: if pass3a-facts.md lists no test setup file (e.g.,
+       the project has 0% coverage with vitest installed but
+       no tests), write the testing guidance in abstract terms
+       ("a shared setup module in a test directory of your
+       choice") without naming a specific path.
+    ✅ RIGHT: for any library-centric standard, if the specific
+       file is not in pass3a-facts.md, describe the pattern
+       by role (what the file does) rather than by name (what
+       it is called).
+
+Critical triggers for this class:
+- `testing-strategy.md` / `testing-patterns.md` — almost always
+  tries to name a mock handler file or test setup file.
+- `styling-patterns.md` — almost always tries to name a global
+  stylesheet or theme file.
+- `state-management.md` — almost always tries to name a store
+  bootstrap file (Redux, Zustand, etc.) even when the project
+  uses only React Context.
+
+The rule in all cases: if pass3a-facts.md has the concrete path,
+use it verbatim; if not, describe the role without naming a file.
+
+This rule is enforced post-generation by `content-validator [10/10]
+path-claim verification`. Fabricated paths will be flagged as
+`STALE_PATH` errors with the path quoted back, forcing re-generation.
+
+CRITICAL — MANIFEST ↔ CLAUDE.md §6 Skills consistency:
+
+If `claudeos-core/skills/00.shared/MANIFEST.md` registers skill files
+under its skill table, CLAUDE.md §6 Skills sub-section MUST mention
+every one of those skill paths (at minimum a bullet reference is
+enough; the full description may live in MANIFEST itself). Likewise,
+every skill listed in CLAUDE.md §6 MUST exist in MANIFEST.
+
+Asymmetry breaks the "single source of truth" claim and is detected by
+`content-validator [10/10]` as `MANIFEST_DRIFT`. When in doubt, sync
+both directions when Pass 3 finishes — do not defer.
+
+CRITICAL — CLAUDE.md Does Not Duplicate Rules:
+CLAUDE.md describes STRUCTURE (overview, architecture, directory, references),
+not enforcement rules. It MUST NOT list or restate rules that are already
+(or should be) enforced by .claude/rules/* or documented in claudeos-core/standard/*.
+
+Examples of what does NOT belong in CLAUDE.md:
+- Coding rules (hardcoding prohibition, `any` casting, naming conventions)
+  → these go in .claude/rules/00.core/* or 03.naming-conventions.md
+- Domain-specific rules (XSS prevention in specific components, response envelope)
+  → these go in .claude/rules/{domain}/* or standard/{domain}/
+- Multi-file sync rules (routePath + routeComponentMap sync)
+  → these go in .claude/rules/{domain}/* with paths glob
+- Work procedures (Entity → DTO → Controller order)
+  → these go in claudeos-core/skills/* or claudeos-core/guide/02.usage/
+
+Section 1 "Role Definition" may reference that rules exist at a high
+level (the scaffold's PROJECT_CONTEXT mentions architecture style),
+but it does NOT enumerate rules. Section 6 "Standard / Rules / Skills
+Reference" provides a REFERENCE INDEX (what exists), not rule content.
+
+After completion, run the following commands in order:
+1. npx claudeos-core health

package/pass-prompts/templates/common/pass3b-core-header.md

@@ -51,6 +51,49 @@ MUST match the fact sheet exactly. If `pass3a-facts.md` says
 `controller-patterns.md`, `response-exception.md`, and
 `controller-rules.md` MUST all show Controller wrapping the response.
 
+## CLAUDE.md Section 6 — Skills sub-section (entry point only)
+
+The Skills sub-section inside CLAUDE.md Section 6 is an **entry point**,
+not a full registry. Pass 3c has not yet run when Section 6 is being
+written, so the specific sub-skill filenames (e.g. `01.dto.md`,
+`02.mapper-read.md`) do not exist and must NOT be predicted. Listing
+sub-skills here by name always produces one of two bugs:
+
+1. Hallucinated filenames when Pass 3c picks a different breakdown than
+   the one predicted (e.g. `01.entity.md` written here, `01.dto.md`
+   generated by Pass 3c → mismatch → MANIFEST_DRIFT).
+
+2. Silent staleness when Pass 3c adds or removes a sub-skill later and
+   CLAUDE.md is not regenerated — the listed names diverge from
+   MANIFEST and the drift is user-visible.
+
+### What to write in Section 6 — Skills
+
+List ONLY:
+- `claudeos-core/skills/00.shared/MANIFEST.md` — the skill registry
+- The orchestrator file(s) for any skill that has sub-skills, with a
+  short one-line role description. Example:
+  `claudeos-core/skills/10.backend-crud/01.scaffold-crud-feature.md`
+  — CRUD scaffolding orchestrator (sub-skills registered in MANIFEST).
+- Standalone skills (skills without sub-skills), if any exist and can
+  be verified from the Pass 3c scope described in the stack template.
+
+### What NOT to write in Section 6 — Skills
+
+- Do NOT list individual sub-skill files
+  (`scaffold-crud-feature/01.dto.md`,
+  `scaffold-crud-feature/02.mapper-read.md`, …). They belong in
+  MANIFEST only. The orchestrator row in Section 6 covers them via
+  indirection — the v2.3.0 validator recognizes this pattern and
+  suppresses MANIFEST_DRIFT for sub-skills under a mentioned
+  orchestrator.
+- Do NOT predict sub-skill names, counts, or ordering. Write
+  "sub-skills registered in MANIFEST" instead of enumerating them.
+
+This single-source-of-truth split (CLAUDE.md §6 = entry; MANIFEST =
+full registry) keeps the two documents independently correct as Pass
+3c iterates on the sub-skill set.
+
 ---
 
 Below is the stack-specific generation guide. Apply these instructions within